Compilation errors

Add new fix to compute force and torque due to electric potential

.github/CODEOWNERS

@@ -101,7 +101,8 @@ src/group.*               @sjplimp
 src/improper.*            @sjplimp
 src/info.*                @akohlmey
 src/kspace.*              @sjplimp
-src/lmptyp.h              @sjplimp
+src/lmptype.h             @sjplimp
+src/label_map.*           @jrgissing @akohlmey
 src/library.*             @sjplimp @akohlmey
 src/main.cpp              @sjplimp
 src/min_*.*               @sjplimp

.github/release_steps.md

@@ -0,0 +1,108 @@
+# LAMMPS Release Steps
+
+The following notes chronicle the current steps for preparing and publishing LAMMPS releases.  For
+definitions of LAMMPS versions and releases mean, please refer to [the corresponding section in the
+LAMMPS manual](https://docs.lammps.org/Manual_version.html).
+
+## LAMMPS Feature Release
+
+A LAMMPS feature release is currently prepared after about 500 to 750 commits to the 'develop'
+branch or after a period of four weeks up to two months.  This is not a fixed rule, though, since
+external circumstances can cause delays in preparing a release, or pull requests that are desired to
+be merged for the release are not yet completed.
+
+### Preparing a 'next\_release' branch
+
+Create a 'next\_release' branch off 'develop' and make the following changes:
+
+- set the LAMMPS\_VERSION define to the planned release date in src/version.h in the format
+  "D Mmm YYYY" or "DD Mmm YYYY"
+- remove the LAMMPS\_UPDATE define in src/version.h
+- update the release date in doc/lammps.1
+- update all TBD arguments for ..versionadded::, ..versionchanged:: ..deprecated:: to the
+  planned release date in the format "DMmmYYYY" or "DDMmmYYYY"
+- check release notes for merged new features and check if ..versionadded:: or ..versionchanged::
+  are missing and need to be added
+Submit this pull request, rebase if needed.  This is the last pull request merged for the release
+and should not contain any other changes. (Exceptions: this document, last minute trivial(!) changes).
+
+This PR shall not be merged before **all** pending tests have completed and cleared. If needed, a
+bugfix pull request should be created and merged to clear all tests.
+
+### Create release on GitHub
+
+When all pending pull requests for the release are merged and have cleared testing, the
+'next\_release' branch is merged into 'develop'.
+
+Check out 'develop' locally, pull the latest changes, merge them into 'release', apply a suitable
+release tag (for historical reasons the tag starts with "patch_" followed by the date, and finally
+push everything back to GitHub. Example:
+
+```
+git checkout develop
+git pull
+git checkout release
+git pull
+git merge --ff-only develop
+git tag -s -m "LAMMPS feature release 19 November 2024" patch_19Nov2024
+git push git@github.com:lammps/lammps.git --tags develop release
+```
+
+Go to https://github.com/lammps/lammps/releases and create a new (draft) release page or check the
+existing draft for any necessary changes from pull requests that were merged but are not listed.
+Then select the applied tag for the release in the "Choose a tag" dropdown list. Go to the bottom of
+the list and select the "Set as pre-release" checkbox.  The "Set as the latest release" button is
+reserved for stable releases and updates to them.
+
+If everything is in order, you can click on the "Publish release" button.  Otherwise, click on "Save
+draft" and finish pending tasks until you can return to edit the release page and publish it.
+
+### Update download website, prepare pre-compiled packages, update packages to GitHub
+
+Publishing the release on GitHub will trigger the Temple Jenkins cluster to update
+the https://docs.lammps.org/ website with the documentation for the new feature release
+and it will create a tarball for download (which contains the translated manual).
+
+Build a fully static LAMMPS installation using a musl-libc cross-compiler, install into a
+lammps-static folder, and create a tarball called lammps-linux-x86_64-19Nov2024.tar.gz (or using a
+corresponding date with a future release) from the lammps-static folder and upload it to GitHub
+with:
+
+```
+gh release upload patch_19Nov2024 ~/Downloads/lammps-linux-x86_64-19Nov2024.tar.gz
+```
+
+
+## LAMMPS Stable Release
+
+A LAMMPS stable release is prepared about once per year in the months July, August, or September.
+One (or two, if needed) feature releases before the stable release shall contain only bug fixes
+or minor feature updates in optional packages.  Also substantial changes to the core of the code
+shall be applied rather toward the beginning of a development cycle between two stable releases
+than toward the end.  The intention is to stablilize significant change to the core and have
+outside users and developers try them out during the development cycle; the sooner the changes
+are included, the better chances for spotting peripheral bugs and issues.
+
+### Prerequesites
+
+Before making a stable release all remaining backported bugfixes shall be released as a (final)
+stable update release (see below).
+
+A LAMMPS stable release process starts like a feature release (see above), only that this feature
+release is called a "Stable Release Candidate" and no assets are uploaded to GitHub.
+
+### Synchronize 'maintenance' branch with 'release'
+
+The state of the 'release' branch is then transferred to the 'maintenance' branch (which will
+have diverged significantly from 'release' due to the selectively backported bug fixes).
+
+### Fast-forward merge of 'maintenance' into 'stable' and apply tag
+
+At this point it should be possible to do a fast-forward merge of 'maintenance' to 'stable'
+and then apply the stable\_DMmmYYYY tag.
+
+### Push branches and tags
+
+
+
+## LAMMPS Stable Update Release

.github/workflows/check-cpp23.yml

@@ -0,0 +1,92 @@
+# GitHub action to build LAMMPS on Linux with gcc and C++23
+name: "Check for C++23 Compatibility"
+
+on:
+  push:
+    branches:
+      - develop
+  pull_request:
+    branches:
+      - develop
+
+  workflow_dispatch:
+
+jobs:
+  build:
+    name: Build with C++23 support enabled
+    if: ${{ github.repository == 'lammps/lammps' }}
+    runs-on: ubuntu-latest
+    env:
+      CCACHE_DIR: ${{ github.workspace }}/.ccache
+
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v4
+      with:
+        fetch-depth: 2
+
+    - name: Install extra packages
+      run: |
+        sudo apt-get update
+        sudo apt-get install -y ccache \
+                                libeigen3-dev \
+                                libcurl4-openssl-dev \
+                                mold \
+                                mpi-default-bin \
+                                mpi-default-dev \
+                                ninja-build \
+                                python3-dev
+
+    - name: Create Build Environment
+      run: mkdir build
+
+    - name: Set up ccache
+      uses: actions/cache@v4
+      with:
+        path: ${{ env.CCACHE_DIR }}
+        key: linux-cpp23-ccache-${{ github.sha }}
+        restore-keys: linux-cpp23-ccache-
+
+    - name: Building LAMMPS via CMake
+      shell: bash
+      run: |
+        ccache -z
+        python3 -m venv linuxenv
+        source linuxenv/bin/activate
+        python3 -m pip install numpy
+        python3 -m pip install pyyaml
+        cmake -S cmake -B build \
+              -C cmake/presets/most.cmake \
+              -C cmake/presets/kokkos-openmp.cmake \
+              -D CMAKE_CXX_STANDARD=23 \
+              -D CMAKE_CXX_COMPILER=g++ \
+              -D CMAKE_C_COMPILER=gcc \
+              -D CMAKE_CXX_COMPILER_LAUNCHER=ccache \
+              -D CMAKE_C_COMPILER_LAUNCHER=ccache \
+              -D CMAKE_BUILD_TYPE=Debug \
+              -D CMAKE_CXX_FLAGS_DEBUG="-Og -g" \
+              -D DOWNLOAD_POTENTIALS=off \
+              -D BUILD_MPI=on \
+              -D BUILD_SHARED_LIBS=on \
+              -D BUILD_TOOLS=off \
+              -D ENABLE_TESTING=off \
+              -D MLIAP_ENABLE_ACE=on \
+              -D MLIAP_ENABLE_PYTHON=off \
+              -D PKG_AWPMD=on \
+              -D PKG_GPU=on \
+              -D GPU_API=opencl \
+              -D PKG_KOKKOS=on \
+              -D PKG_LATBOLTZ=on \
+              -D PKG_MDI=on \
+              -D PKG_MANIFOLD=on \
+              -D PKG_ML-PACE=on \
+              -D PKG_ML-RANN=off \
+              -D PKG_MOLFILE=on \
+              -D PKG_RHEO=on \
+              -D PKG_PTM=on \
+              -D PKG_PYTHON=on \
+              -D PKG_QTB=on \
+              -D PKG_SMTBQ=on \
+              -G Ninja
+        cmake --build build
+        ccache -s

.github/workflows/check-vla.yml

@@ -0,0 +1,89 @@
+# GitHub action to build LAMMPS on Linux with gcc and -Werror=vla
+name: "Check for Variable Length Arrays"
+
+on:
+  push:
+    branches:
+      - develop
+  pull_request:
+    branches:
+      - develop
+
+  workflow_dispatch:
+
+jobs:
+  build:
+    name: Build with -Werror=vla
+    if: ${{ github.repository == 'lammps/lammps' }}
+    runs-on: ubuntu-latest
+    env:
+      CCACHE_DIR: ${{ github.workspace }}/.ccache
+
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v4
+      with:
+        fetch-depth: 2
+
+    - name: Install extra packages
+      run: |
+        sudo apt-get update
+        sudo apt-get install -y ccache \
+                                libeigen3-dev \
+                                libcurl4-openssl-dev \
+                                mold \
+                                mpi-default-bin \
+                                mpi-default-dev \
+                                ninja-build \
+                                python3-dev
+
+    - name: Create Build Environment
+      run: mkdir build
+
+    - name: Set up ccache
+      uses: actions/cache@v4
+      with:
+        path: ${{ env.CCACHE_DIR }}
+        key: linux-vla-ccache-${{ github.sha }}
+        restore-keys: linux-vla-ccache-
+
+    - name: Building LAMMPS via CMake
+      shell: bash
+      run: |
+        ccache -z
+        python3 -m venv linuxenv
+        source linuxenv/bin/activate
+        python3 -m pip install numpy
+        python3 -m pip install pyyaml
+        cmake -S cmake -B build \
+              -C cmake/presets/most.cmake \
+              -D CMAKE_CXX_COMPILER=g++ \
+              -D CMAKE_C_COMPILER=gcc \
+              -D CMAKE_CXX_COMPILER_LAUNCHER=ccache \
+              -D CMAKE_C_COMPILER_LAUNCHER=ccache \
+              -D CMAKE_BUILD_TYPE=Debug \
+              -D CMAKE_CXX_FLAGS_DEBUG="-Og -g -Werror=vla" \
+              -D DOWNLOAD_POTENTIALS=off \
+              -D BUILD_MPI=on \
+              -D BUILD_SHARED_LIBS=off \
+              -D BUILD_TOOLS=off \
+              -D ENABLE_TESTING=off \
+              -D MLIAP_ENABLE_ACE=on \
+              -D MLIAP_ENABLE_PYTHON=off \
+              -D PKG_AWPMD=on \
+              -D PKG_GPU=on \
+              -D GPU_API=opencl \
+              -D PKG_LATBOLTZ=on \
+              -D PKG_MDI=on \
+              -D PKG_MANIFOLD=on \
+              -D PKG_ML-PACE=on \
+              -D PKG_ML-RANN=off \
+              -D PKG_MOLFILE=on \
+              -D PKG_RHEO=on \
+              -D PKG_PTM=on \
+              -D PKG_PYTHON=on \
+              -D PKG_QTB=on \
+              -D PKG_SMTBQ=on \
+              -G Ninja
+        cmake --build build
+        ccache -s

.github/workflows/compile-msvc.yml

@@ -1,5 +1,5 @@
-# GitHub action to build LAMMPS on Windows with Visual C++
-name: "Native Windows Compilation and Unit Tests"
+# GitHub action to test LAMMPS on Windows with Visual C++
+name: "Windows Unit Tests"
 
 on:
   push:
@@ -11,11 +11,17 @@ on:
 
   workflow_dispatch:
 
+concurrency:
+  group: ${{ github.event_name }}-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: ${{github.event_name == 'pull_request'}}
+
 jobs:
   build:
     name: Windows Compilation Test
     if: ${{ github.repository == 'lammps/lammps' }}
     runs-on: windows-latest
+    env:
+      CCACHE_DIR: ${{ github.workspace }}/.ccache
 
     steps:
     - name: Checkout repository
@@ -23,36 +29,41 @@ jobs:
       with:
         fetch-depth: 2
 
+    - name: Enable MSVC++
+      uses: lammps/setup-msvc-dev@v3
+      with:
+        arch: x64
+
+    - name: Install Ccache
+      run: |
+        choco install ccache ninja -y
+
+    - name: Set up ccache
+      uses: actions/cache@v4
+      with:
+        path: ${{ env.CCACHE_DIR }}
+        key: win-unit-ccache-${{ github.sha }}
+        restore-keys: win-unit-ccache-
+
     - name: Select Python version
       uses: actions/setup-python@v5
       with:
         python-version: '3.11'
 
     - name: Building LAMMPS via CMake
-      shell: bash
       run: |
+        ccache -z
         python3 -m pip install numpy
         python3 -m pip install pyyaml
-        nuget install MSMPIsdk
-        nuget install MSMPIDIST
-        cmake -C cmake/presets/windows.cmake \
-              -D DOWNLOAD_POTENTIALS=off \
-              -D PKG_PYTHON=on \
-              -D WITH_PNG=off \
-              -D WITH_JPEG=off \
-              -S cmake -B build \
-              -D BUILD_SHARED_LIBS=on \
-              -D LAMMPS_EXCEPTIONS=on \
-              -D ENABLE_TESTING=on
-        cmake --build build --config Release --parallel 2
+        cmake -C cmake\presets\windows.cmake -D CMAKE_CXX_COMPILER=cl -D CMAKE_CXX_COMPILER_LAUNCHER=ccache -D CMAKE_C_COMPILER=cl -D CMAKE_C_COMPILER_LAUNCHER=ccache -D CMAKE_Fortran_COMPILER="" -D DOWNLOAD_POTENTIALS=off -D PKG_PYTHON=on -D WITH_PNG=off -D WITH_JPEG=off -S cmake -B build -D BUILD_SHARED_LIBS=on -D ENABLE_TESTING=on -D CMAKE_BUILD_TYPE=Release -G Ninja
+        cmake --build build
+        ccache -s
 
     - name: Run LAMMPS executable
-      shell: bash
       run: |
-        ./build/Release/lmp.exe -h
-        ./build/Release/lmp.exe -in bench/in.lj
+        build\lmp.exe -h
+        build\lmp.exe -in bench\in.lj
 
     - name: Run Unit Tests
       working-directory: build
-      shell: bash
-      run: ctest -V -C Release -E FixTimestep:python_move_nve
+      run: ctest -V -E FixTimestep:python_move_nve

.github/workflows/coverity.yml

@@ -67,7 +67,6 @@ jobs:
         -D PKG_MANIFOLD=on \
         -D PKG_MDI=on \
         -D PKG_MGPT=on \
-        -D PKG_ML-PACE=on \
         -D PKG_ML-RANN=on \
         -D PKG_MOLFILE=on \
         -D PKG_NETCDF=on \

.github/workflows/full-regression.yml

@@ -0,0 +1,109 @@
+# GitHub action to build LAMMPS on Linux and run regression tests
+name: "Full Regression Test"
+
+on:
+  push:
+    branches:
+      - develop
+
+  workflow_dispatch:
+
+jobs:
+  build:
+    name: Build LAMMPS
+    # restrict to official LAMMPS repository
+    if: ${{ github.repository == 'lammps/lammps' }}
+    runs-on: ubuntu-latest
+    env:
+      CCACHE_DIR: ${{ github.workspace }}/.ccache
+    strategy:
+      max-parallel: 8
+      matrix:
+        idx: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v4
+      with:
+        fetch-depth: 2
+        show-progress: false
+
+    - name: Install extra packages
+      run: |
+        sudo apt-get update
+        sudo apt-get install -y ccache ninja-build libeigen3-dev \
+                     libcurl4-openssl-dev python3-dev \
+                     mpi-default-bin mpi-default-dev
+
+    - name: Create Build Environment
+      run: mkdir build
+
+    - name: Set up ccache
+      uses: actions/cache@v4
+      with:
+        path: ${{ env.CCACHE_DIR }}
+        key: linux-full-ccache-${{ github.sha }}
+        restore-keys: linux-full-ccache-
+
+    - name: Building LAMMPS via CMake
+      shell: bash
+      run: |
+        ccache -z
+        python3 -m venv linuxenv
+        source linuxenv/bin/activate
+        python3 -m pip install --upgrade pip
+        python3 -m pip install numpy pyyaml junit_xml
+        cmake -S cmake -B build \
+              -C cmake/presets/gcc.cmake \
+              -C cmake/presets/most.cmake \
+              -D CMAKE_CXX_COMPILER_LAUNCHER=ccache \
+              -D CMAKE_C_COMPILER_LAUNCHER=ccache \
+              -D BUILD_SHARED_LIBS=off \
+              -D DOWNLOAD_POTENTIALS=off \
+              -D PKG_MANIFOLD=on \
+              -D PKG_ML-PACE=on \
+              -D PKG_ML-RANN=on \
+              -D PKG_RHEO=on \
+              -D PKG_PTM=on \
+              -D PKG_PYTHON=on \
+              -D PKG_QTB=on \
+              -D PKG_SMTBQ=on \
+              -G Ninja
+        cmake --build build
+        ccache -s
+
+    - name: Run Full Regression Tests
+      shell: bash
+      run: |
+        source linuxenv/bin/activate
+        python3 tools/regression-tests/run_tests.py \
+               --lmp-bin=build/lmp \
+               --config-file=tools/regression-tests/config_serial.yaml \
+               --examples-top-level=examples --analyze --num-workers=8
+
+        python3 tools/regression-tests/run_tests.py \
+               --lmp-bin=build/lmp \
+               --config-file=tools/regression-tests/config_serial.yaml \
+               --list-input=input-list-${{ matrix.idx }}.txt \
+               --output-file=output-${{ matrix.idx }}.xml \
+               --progress-file=progress-${{ matrix.idx }}.yaml \
+               --log-file=run-${{ matrix.idx }}.log
+
+        tar -cvf full-regression-test-${{ matrix.idx }}.tar run-${{ matrix.idx }}.log progress-${{ matrix.idx }}.yaml output-${{ matrix.idx }}.xml
+
+    - name: Upload artifacts
+      uses: actions/upload-artifact@v4
+      with:
+        name: full-regression-test-artifact-${{ matrix.idx }}
+        path: full-regression-test-${{ matrix.idx }}.tar
+
+  merge:
+    runs-on: ubuntu-latest
+    needs: build
+    steps:
+      - name: Merge Artifacts
+        uses: actions/upload-artifact/merge@v4
+        with:
+          name: merged-full-regresssion-artifact
+          pattern: full-regression-test-artifact-*
+

.github/workflows/kokkos-regression.yaml

@@ -0,0 +1,126 @@
+# GitHub action to build LAMMPS on Linux and run selected regression tests
+name: "Kokkos OpenMP Regression Test"
+
+on:
+  push:
+    branches:
+      - develop
+
+  workflow_dispatch:
+
+jobs:
+  build:
+    name: Build LAMMPS with Kokkos OpenMP
+    # restrict to official LAMMPS repository
+    if: ${{ github.repository == 'lammps/lammps' }}
+    runs-on: ubuntu-latest
+    env:
+      CCACHE_DIR: ${{ github.workspace }}/.ccache
+    strategy:
+      max-parallel: 6
+      matrix:
+        idx: [ 'pair-0', 'pair-1', 'fix-0', 'fix-1', 'compute', 'misc' ]
+
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v4
+      with:
+        fetch-depth: 2
+        show-progress: false
+
+    - name: Install extra packages
+      run: |
+        sudo apt-get update
+        sudo apt-get install -y ccache ninja-build libeigen3-dev \
+                     libcurl4-openssl-dev python3-dev \
+                     mpi-default-bin mpi-default-dev
+
+    - name: Create Build Environment
+      run: mkdir build
+
+    - name: Set up ccache
+      uses: actions/cache@v4
+      with:
+        path: ${{ env.CCACHE_DIR }}
+        key: linux-kokkos-ccache-${{ github.sha }}
+        restore-keys: linux-kokkos-ccache-
+
+    - name: Building LAMMPS via CMake
+      shell: bash
+      run: |
+        ccache -z
+        python3 -m venv linuxenv
+        source linuxenv/bin/activate
+        python3 -m pip install --upgrade pip
+        python3 -m pip install numpy pyyaml junit_xml
+        cmake -S cmake -B build \
+              -C cmake/presets/gcc.cmake \
+              -C cmake/presets/basic.cmake \
+              -C cmake/presets/kokkos-openmp.cmake \
+              -D CMAKE_CXX_COMPILER_LAUNCHER=ccache \
+              -D CMAKE_C_COMPILER_LAUNCHER=ccache \
+              -D BUILD_SHARED_LIBS=off \
+              -D DOWNLOAD_POTENTIALS=off \
+              -D PKG_AMOEBA=on \
+              -D PKG_ASPHERE=on \
+              -D PKG_BROWNIAN=on \
+              -D PKG_CLASS2=on \
+              -D PKG_COLLOID=on \
+              -D PKG_CORESHELL=on \
+              -D PKG_DIPOLE=on \
+              -D PKG_DPD-BASIC=on \
+              -D PKG_EXTRA-COMPUTE=on \
+              -D PKG_EXTRA-FIX=on \
+              -D PKG_EXTRA-MOLECULE=on \
+              -D PKG_EXTRA-PAIR=on \
+              -D PKG_GRANULAR=on \
+              -D PKG_LEPTON=on \
+              -D PKG_MC=on \
+              -D PKG_MEAM=on \
+              -D PKG_POEMS=on \
+              -D PKG_PYTHON=on \
+              -D PKG_QEQ=on \
+              -D PKG_REAXFF=on \
+              -D PKG_REPLICA=on \
+              -D PKG_SRD=on \
+              -D PKG_SPH=on \
+              -D PKG_VORONOI=on \
+              -G Ninja
+        cmake --build build
+        ccache -s
+
+    - name: Run Regression Tests for Selected Examples
+      shell: bash
+      run: |
+        source linuxenv/bin/activate
+        python3 tools/regression-tests/get_kokkos_input.py \
+               --examples-top-level=examples --batch-size=50 \
+               --filter-out="balance;fire;gcmc;granregion;hyper;mc;mdi;mliap;neb;pace;prd;pour;python;rigid;snap;streitz;shear;ttm"
+
+        export OMP_PROC_BIND=false
+        python3 tools/regression-tests/run_tests.py \
+               --lmp-bin=build/lmp \
+               --config-file=tools/regression-tests/config_kokkos_openmp.yaml \
+               --list-input=input-list-${{ matrix.idx }}-kk.txt \
+               --output-file=output-${{ matrix.idx }}.xml \
+               --progress-file=progress-${{ matrix.idx }}.yaml \
+               --log-file=run-${{ matrix.idx }}.log \
+               --quick-max=100
+
+        tar -cvf kokkos-regression-test-${{ matrix.idx }}.tar run-${{ matrix.idx }}.log progress-${{ matrix.idx }}.yaml output-${{ matrix.idx }}.xml
+
+    - name: Upload artifacts
+      uses: actions/upload-artifact@v4
+      with:
+        name: kokkos-regression-test-artifact-${{ matrix.idx }}
+        path: kokkos-regression-test-${{ matrix.idx }}.tar
+
+  merge:
+    runs-on: ubuntu-latest
+    needs: build
+    steps:
+      - name: Merge Artifacts
+        uses: actions/upload-artifact/merge@v4
+        with:
+          name: merged-kokkos-regresssion-artifact
+          pattern: kokkos-regression-test-artifact-*

.github/workflows/lammps-gui-flatpak.yml

@@ -0,0 +1,53 @@
+# GitHub action to build LAMMPS-GUI as a flatpak bundle
+name: "Build LAMMPS-GUI as flatpak bundle"
+
+on:
+  push:
+    branches:
+      - develop
+
+  workflow_dispatch:
+
+concurrency:
+  group: ${{ github.event_name }}-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: ${{github.event_name == 'pull_request'}}
+
+jobs:
+  build:
+    name: LAMMPS-GUI flatpak build
+    if: ${{ github.repository == 'lammps/lammps' }}
+    runs-on: ubuntu-latest
+
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v4
+      with:
+        fetch-depth: 2
+
+    - name: Install extra packages
+      run: |
+        sudo apt-get update
+        sudo apt-get install -y ccache \
+                                libeigen3-dev \
+                                libcurl4-openssl-dev \
+                                mold \
+                                ninja-build \
+                                python3-dev \
+                                flatpak \
+                                flatpak-builder
+
+    - name: Set up access to flatpak repo
+      run: flatpak --user remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
+
+    - name: Build flatpak
+      run: |
+        mkdir flatpack-state
+        sed -i -e 's/branch:.*/branch: develop/' tools/lammps-gui/org.lammps.lammps-gui.yml
+        flatpak-builder --force-clean --verbose --repo=flatpak-repo \
+                               --install-deps-from=flathub --state-dir=flatpak-state \
+                               --user --ccache --default-branch=${{ github.ref_name }} \
+                               flatpak-build tools/lammps-gui/org.lammps.lammps-gui.yml
+        flatpak build-bundle --runtime-repo=https://flathub.org/repo/flathub.flatpakrepo \
+                               --verbose  flatpak-repo LAMMPS-Linux-x86_64-GUI.flatpak \
+                               org.lammps.lammps-gui ${{ github.ref_name }}
+        flatpak install -y -v --user LAMMPS-Linux-x86_64-GUI.flatpak

.github/workflows/quick-regression.yml

@@ -0,0 +1,118 @@
+# GitHub action to build LAMMPS on Linux and run selected regression tests
+name: "Quick Regression Test"
+
+on:
+  pull_request:
+    branches:
+      - develop
+
+  workflow_dispatch:
+
+concurrency:
+  group: ${{ github.event_name }}-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: ${{github.event_name == 'pull_request'}}
+
+jobs:
+  build:
+    name: Build LAMMPS
+    # restrict to official LAMMPS repository
+    if: ${{ github.repository == 'lammps/lammps' }}
+    runs-on: ubuntu-latest
+    env:
+      CCACHE_DIR: ${{ github.workspace }}/.ccache
+    strategy:
+      max-parallel: 4
+      matrix:
+        idx: [ 0, 1, 2, 3 ]
+
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v4
+      with:
+        fetch-depth: 0
+        show-progress: false
+
+    - name: Install extra packages
+      run: |
+        sudo apt-get update
+        sudo apt-get install -y ccache ninja-build libeigen3-dev \
+                     libcurl4-openssl-dev python3-dev \
+                     mpi-default-bin mpi-default-dev
+
+    - name: Create Build Environment
+      run: mkdir build
+
+    - name: Set up ccache
+      uses: actions/cache@v4
+      with:
+        path: ${{ env.CCACHE_DIR }}
+        key: linux-quick-ccache-${{ github.sha }}
+        restore-keys: linux-quick-ccache-
+
+    - name: Building LAMMPS via CMake
+      shell: bash
+      run: |
+        ccache -z
+        python3 -m venv linuxenv
+        source linuxenv/bin/activate
+        python3 -m pip install --upgrade pip
+        python3 -m pip install numpy pyyaml junit_xml
+        cmake -S cmake -B build \
+              -C cmake/presets/gcc.cmake \
+              -C cmake/presets/most.cmake \
+              -D CMAKE_CXX_COMPILER_LAUNCHER=ccache \
+              -D CMAKE_C_COMPILER_LAUNCHER=ccache \
+              -D BUILD_SHARED_LIBS=off \
+              -D DOWNLOAD_POTENTIALS=off \
+              -D PKG_MANIFOLD=on \
+              -D PKG_ML-PACE=on \
+              -D PKG_ML-RANN=on \
+              -D PKG_RHEO=on \
+              -D PKG_PTM=on \
+              -D PKG_PYTHON=on \
+              -D PKG_QTB=on \
+              -D PKG_SMTBQ=on \
+              -G Ninja
+        cmake --build build
+        ccache -s
+
+    - name: Run Regression Tests for Modified Styles
+      shell: bash
+      run: |
+        source linuxenv/bin/activate
+        python3 tools/regression-tests/run_tests.py \
+               --lmp-bin=build/lmp \
+               --config-file=tools/regression-tests/config_quick.yaml \
+               --examples-top-level=examples \
+               --quick-reference=tools/regression-tests/reference.yaml \
+               --quick --quick-branch=origin/develop --quick-max=100 --num-workers=4
+
+        if [ -f input-list-${{ matrix.idx }}.txt ]
+        then \
+           python3 tools/regression-tests/run_tests.py \
+               --lmp-bin=build/lmp \
+               --config-file=tools/regression-tests/config_quick.yaml \
+               --list-input=input-list-${{ matrix.idx }}.txt \
+               --output-file=output-${{ matrix.idx }}.xml \
+               --progress-file=progress-${{ matrix.idx }}.yaml \
+               --log-file=run-${{ matrix.idx }}.log
+        fi
+
+        tar -cvf quick-regression-test-${{ matrix.idx }}.tar run-${{ matrix.idx }}.log progress-${{ matrix.idx }}.yaml output-${{ matrix.idx }}.xml
+
+    - name: Upload artifacts
+      uses: actions/upload-artifact@v4
+      with:
+        name: quick-regression-test-artifact-${{ matrix.idx }}
+        path: quick-regression-test-${{ matrix.idx }}.tar
+
+  merge:
+    runs-on: ubuntu-latest
+    needs: build
+    steps:
+      - name: Merge Artifacts
+        uses: actions/upload-artifact/merge@v4
+        with:
+          name: merged-quick-regresssion-artifact
+          pattern: quick-regression-test-artifact-*
+

.github/workflows/style-check.yml

@@ -0,0 +1,37 @@
+# GitHub action to run checks from tools/coding_standard
+name: "Check for Programming Style Conformance"
+
+on:
+  push:
+    branches:
+      - develop
+  pull_request:
+    branches:
+      - develop
+
+  workflow_dispatch:
+
+concurrency:
+  group: ${{ github.event_name }}-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: ${{github.event_name == 'pull_request'}}
+
+jobs:
+  build:
+    name: Programming Style Conformance
+    if: ${{ github.repository == 'lammps/lammps' }}
+    runs-on: ubuntu-latest
+
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v4
+      with:
+        fetch-depth: 1
+
+    - name: Run Tests
+      working-directory: src
+      shell: bash
+      run: |
+         make check-whitespace
+         make check-permissions
+         make check-homepage
+         make check-errordocs

.github/workflows/unittest-linux.yml

@@ -0,0 +1,86 @@
+# GitHub action to build LAMMPS on Linux and run standard unit tests
+name: "Unittest for Linux /w LAMMPS_BIGBIG"
+
+on:
+  push:
+    branches:
+      - develop
+  pull_request:
+    branches:
+      - develop
+
+  workflow_dispatch:
+
+concurrency:
+  group: ${{ github.event_name }}-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: ${{github.event_name == 'pull_request'}}
+
+jobs:
+  build:
+    name: Linux Unit Test
+    if: ${{ github.repository == 'lammps/lammps' }}
+    runs-on: ubuntu-latest
+    env:
+      CCACHE_DIR: ${{ github.workspace }}/.ccache
+
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v4
+      with:
+        fetch-depth: 2
+
+    - name: Install extra packages
+      run: |
+        sudo apt-get update
+        sudo apt-get install -y ccache \
+                                libeigen3-dev \
+                                libcurl4-openssl-dev \
+                                mold \
+                                ninja-build \
+                                python3-dev
+
+    - name: Create Build Environment
+      run: mkdir build
+
+    - name: Set up ccache
+      uses: actions/cache@v4
+      with:
+        path: ${{ env.CCACHE_DIR }}
+        key: linux-unit-ccache-${{ github.sha }}
+        restore-keys: linux-unit-ccache-
+
+    - name: Building LAMMPS via CMake
+      shell: bash
+      run: |
+        ccache -z
+        python3 -m venv linuxenv
+        source linuxenv/bin/activate
+        python3 -m pip install numpy
+        python3 -m pip install pyyaml
+        cmake -S cmake -B build \
+              -C cmake/presets/gcc.cmake \
+              -C cmake/presets/most.cmake \
+              -D CMAKE_CXX_COMPILER_LAUNCHER=ccache \
+              -D CMAKE_C_COMPILER_LAUNCHER=ccache \
+              -D BUILD_SHARED_LIBS=on \
+              -D LAMMPS_SIZES=bigbig \
+              -D DOWNLOAD_POTENTIALS=off \
+              -D ENABLE_TESTING=on \
+              -D MLIAP_ENABLE_ACE=on \
+              -D MLIAP_ENABLE_PYTHON=off \
+              -D PKG_MANIFOLD=on \
+              -D PKG_ML-PACE=on \
+              -D PKG_ML-RANN=on \
+              -D PKG_RHEO=on \
+              -D PKG_PTM=on \
+              -D PKG_PYTHON=on \
+              -D PKG_QTB=on \
+              -D PKG_SMTBQ=on \
+              -G Ninja
+        cmake --build build
+        ccache -s
+
+    - name: Run Tests
+      working-directory: build
+      shell: bash
+      run: ctest -V

.github/workflows/unittest-macos.yml

@@ -11,6 +11,10 @@ on:
 
   workflow_dispatch:
 
+concurrency:
+  group: ${{ github.event_name }}-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: ${{github.event_name == 'pull_request'}}
+
 jobs:
   build:
     name: MacOS Unit Test

cmake/CMakeLists.txt

@@ -3,6 +3,9 @@
 # CMake build system
 # This file is part of LAMMPS
 cmake_minimum_required(VERSION 3.16)
+if(CMAKE_VERSION VERSION_LESS 3.20)
+  message(WARNING "LAMMPS is planning to require at least CMake version 3.20 by Summer 2025. Please upgrade!")
+endif()
 ########################################
 # set policy to silence warnings about ignoring <PackageName>_ROOT but use it
 if(POLICY CMP0074)
@@ -95,30 +98,27 @@ check_for_autogen_files(${LAMMPS_SOURCE_DIR})
 #####################################################################
 include(CheckIncludeFileCXX)
 
-# set required compiler flags and compiler/CPU arch specific optimizations
+# set required compiler flags, apply checks, and compiler/CPU arch specific optimizations
 if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
+  # Intel classic compilers version 19 are broken and fail to compile the embedded fmtlib
+  if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS 20.0)
+    message(ERROR "Intel classic compiler version ${CMAKE_CXX_COMPILER_VERSION} is too old")
+  endif()
+
   if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
     if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
       set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /Qrestrict")
     endif()
-    if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
-      set(CMAKE_TUNE_DEFAULT "/QxCOMMON-AVX512")
-    else()
-      set(CMAKE_TUNE_DEFAULT "/QxHost")
-    endif()
+    set(CMAKE_TUNE_DEFAULT "/QxHost")
   else()
     set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
-    if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
-      set(CMAKE_TUNE_DEFAULT "-xCOMMON-AVX512")
-    else()
-      set(CMAKE_TUNE_DEFAULT "-xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=11074 -diag-disable=11076 -diag-disable=2196")
-    endif()
+    set(CMAKE_TUNE_DEFAULT "-xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=11074 -diag-disable=11076 -diag-disable=2196")
   endif()
 endif()
 
 # silence excessive warnings for new Intel Compilers
 if(CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM")
-  set(CMAKE_TUNE_DEFAULT "-Wno-tautological-constant-compare -Wno-unused-command-line-argument")
+  set(CMAKE_TUNE_DEFAULT "-fp-model precise -Wno-tautological-constant-compare -Wno-unused-command-line-argument")
 endif()
 
 # silence excessive warnings for PGI/NVHPC compilers
@@ -141,19 +141,31 @@ endif()
 
 # silence nvcc warnings
 if((PKG_KOKKOS) AND (Kokkos_ENABLE_CUDA) AND NOT (CMAKE_CXX_COMPILER_ID STREQUAL "Clang"))
-  set(CMAKE_TUNE_DEFAULT "${CMAKE_TUNE_DEFAULT} -Xcudafe --diag_suppress=unrecognized_pragma")
+  set(CMAKE_TUNE_DEFAULT "${CMAKE_TUNE_DEFAULT}" "-Xcudafe --diag_suppress=unrecognized_pragma,--diag_suppress=128")
 endif()
 
-# we require C++11 without extensions. Kokkos requires at least C++17 (currently)
+# we *require* C++11 without extensions but prefer C++17.
+# Kokkos requires at least C++17 (currently)
 if(NOT CMAKE_CXX_STANDARD)
-  set(CMAKE_CXX_STANDARD 11)
+  if(cxx_std_17 IN_LIST CMAKE_CXX_COMPILE_FEATURES)
+    set(CMAKE_CXX_STANDARD 17)
+  else()
+    set(CMAKE_CXX_STANDARD 11)
+  endif()
 endif()
 if(CMAKE_CXX_STANDARD LESS 11)
   message(FATAL_ERROR "C++ standard must be set to at least 11")
 endif()
+if(CMAKE_CXX_STANDARD LESS 17)
+  message(WARNING "Selecting C++17 standard is preferred over C++${CMAKE_CXX_STANDARD}")
+endif()
 if(PKG_KOKKOS AND (CMAKE_CXX_STANDARD LESS 17))
   set(CMAKE_CXX_STANDARD 17)
 endif()
+# turn off C++17 check in lmptype.h
+if(LAMMPS_CXX11)
+  add_compile_definitions(LAMMPS_CXX11)
+endif()
 set(CMAKE_CXX_STANDARD_REQUIRED ON)
 set(CMAKE_CXX_EXTENSIONS OFF CACHE BOOL "Use compiler extensions")
 # ugly hacks for MSVC which by default always reports an old C++ standard in the __cplusplus macro
@@ -165,6 +177,7 @@ if(MSVC)
     add_compile_options(/wd4267)
     add_compile_options(/wd4250)
     add_compile_options(/EHsc)
+    add_compile_options(/utf-8)
   endif()
   add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
 endif()
@@ -346,6 +359,17 @@ foreach(PKG ${STANDARD_PACKAGES} ${SUFFIX_PACKAGES})
   option(PKG_${PKG} "Build ${PKG} Package" OFF)
 endforeach()
 
+set(DEPRECATED_PACKAGES AWPMD ATC POEMS)
+foreach(PKG ${DEPRECATED_PACKAGES})
+  if(PKG_${PKG})
+    message(WARNING
+          "The ${PKG} package will be removed from LAMMPS in Summer 2025 due to lack of "
+          "maintenance and use of code constructs that conflict with modern C++ compilers "
+          "and standards.  Please contact developers@lammps.org if you have any concerns "
+          "about this step.")
+  endif()
+endforeach()
+
 ######################################################
 # packages with special compiler needs or external libs
 ######################################################
@@ -474,13 +498,13 @@ if(BUILD_OMP)
   if(CMAKE_VERSION VERSION_LESS 3.28)
     get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
     if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
-      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE} -fopenmp")
-      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE} -fopenmp")
+      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE}} -fopenmp")
+      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE}} -fopenmp")
     endif()
   else()
     if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
-      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE} -fopenmp")
-      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE} -fopenmp")
+      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE}} -fopenmp")
+      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE}} -fopenmp")
     endif()
   endif()
 endif()
@@ -497,7 +521,7 @@ if((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_STANDARD GREATER_EQUA
           PROPERTIES COMPILE_OPTIONS "-std=c++14")
 endif()
 
-if(PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_ML-POD OR PKG_ELECTRODE OR BUILD_TOOLS)
+if(PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_ML-POD OR PKG_ELECTRODE OR PKG_RHEO OR BUILD_TOOLS)
   enable_language(C)
   if (NOT USE_INTERNAL_LINALG)
     find_package(LAPACK)
@@ -515,14 +539,6 @@ if(PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_ML-POD OR PKG_ELECTRODE OR BUILD_T
   endif()
 endif()
 
-find_package(CURL QUIET COMPONENTS HTTP HTTPS)
-option(WITH_CURL "Enable libcurl support" ${CURL_FOUND})
-if(WITH_CURL)
-  find_package(CURL REQUIRED COMPONENTS HTTP HTTPS)
-  target_compile_definitions(lammps PRIVATE -DLAMMPS_CURL)
-  target_link_libraries(lammps PRIVATE CURL::libcurl)
-endif()
-
 # tweak jpeg library names to avoid linker errors with MinGW cross-compilation
 set(JPEG_NAMES libjpeg libjpeg-62)
 find_package(JPEG QUIET)
@@ -580,12 +596,22 @@ else()
 endif()
 
 foreach(PKG_WITH_INCL KSPACE PYTHON ML-IAP VORONOI COLVARS ML-HDNNP MDI MOLFILE NETCDF
-        PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM COMPRESS ML-PACE LEPTON RHEO)
+        PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM COMPRESS ML-PACE LEPTON EXTRA-COMMAND)
   if(PKG_${PKG_WITH_INCL})
     include(Packages/${PKG_WITH_INCL})
   endif()
 endforeach()
 
+# settings for misc packages and styles
+if(PKG_MISC)
+  option(LAMMPS_ASYNC_IMD "Asynchronous IMD processing" OFF)
+  mark_as_advanced(LAMMPS_ASYNC_IMD)
+  if(LAMMPS_ASYNC_IMD)
+    target_compile_definitions(lammps PRIVATE -DLAMMPS_ASYNC_IMD)
+    message(STATUS "Using IMD in asynchronous mode")
+  endif()
+endif()
+
 # optionally enable building script wrappers using swig
 option(WITH_SWIG "Build scripting language wrappers with SWIG" OFF)
 if(WITH_SWIG)
@@ -595,13 +621,8 @@ endif()
 
 set(CMAKE_TUNE_FLAGS "${CMAKE_TUNE_DEFAULT}" CACHE STRING "Compiler and machine specific optimization flags (compilation only)")
 separate_arguments(CMAKE_TUNE_FLAGS)
-foreach(_FLAG ${CMAKE_TUNE_FLAGS})
-  target_compile_options(lammps PRIVATE ${_FLAG})
-  # skip these flags when linking the main executable
-  if(NOT (("${_FLAG}" STREQUAL "-Xcudafe") OR (("${_FLAG}" STREQUAL "--diag_suppress=unrecognized_pragma"))))
-    target_compile_options(lmp PRIVATE ${_FLAG})
-  endif()
-endforeach()
+target_compile_options(lammps PRIVATE ${CMAKE_TUNE_FLAGS})
+target_compile_options(lmp PRIVATE ${CMAKE_TUNE_FLAGS})
 ########################################################################
 # Basic system tests (standard libraries, headers, functions, types)   #
 ########################################################################
@@ -830,9 +851,15 @@ foreach(_DEF ${LAMMPS_DEFINES})
   set(LAMMPS_API_DEFINES "${LAMMPS_API_DEFINES} -D${_DEF}")
 endforeach()
 if(BUILD_SHARED_LIBS)
-  install(TARGETS lammps EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
+  install(TARGETS lammps EXPORT LAMMPS_Targets
+          LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
+          ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
+          RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR})
   if(NOT BUILD_MPI)
-    install(TARGETS mpi_stubs EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
+    install(TARGETS mpi_stubs EXPORT LAMMPS_Targets
+            LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
+            ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
+            RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR})
   endif()
   configure_file(pkgconfig/liblammps.pc.in ${CMAKE_CURRENT_BINARY_DIR}/liblammps${LAMMPS_MACHINE}.pc @ONLY)
   install(FILES ${CMAKE_CURRENT_BINARY_DIR}/liblammps${LAMMPS_MACHINE}.pc DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
@@ -973,6 +1000,9 @@ message(STATUS "<<< Compilers and Flags: >>>
       C++ Standard:  ${CMAKE_CXX_STANDARD}
       C++ Flags:    ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_${BTYPE}}
       Defines:       ${DEFINES}")
+if(CMAKE_CXX_COMPILER_LAUNCHER)
+  message(STATUS "      Launcher:      ${CMAKE_CXX_COMPILER_LAUNCHER}")
+endif()
 get_target_property(OPTIONS lammps COMPILE_OPTIONS)
 if(OPTIONS)
   message("      Options:       ${OPTIONS}")
@@ -991,6 +1021,9 @@ if(_index GREATER -1)
       Type:          ${CMAKE_C_COMPILER_ID}
       Version:       ${CMAKE_C_COMPILER_VERSION}
       C Flags:      ${CMAKE_C_FLAGS} ${CMAKE_C_FLAGS_${BTYPE}}")
+  if(CMAKE_C_COMPILER_LAUNCHER)
+    message(STATUS "      Launcher:      ${CMAKE_C_COMPILER_LAUNCHER}")
+  endif()
 endif()
 message(STATUS "<<< Linker flags: >>>")
 message(STATUS "Executable name:  ${LAMMPS_BINARY}")
@@ -1078,12 +1111,15 @@ if(BUILD_TOOLS)
   message(STATUS "<<< Building Tools >>>")
 endif()
 if(BUILD_LAMMPS_GUI)
-  message(STATUS "<<< Building LAMMPS GUI >>>")
+  message(STATUS "<<< Building LAMMPS-GUI >>>")
   if(LAMMPS_GUI_USE_PLUGIN)
     message(STATUS "Loading LAMMPS library as plugin at run time")
   else()
     message(STATUS "Linking LAMMPS library at compile time")
   endif()
+  if(BUILD_WHAM)
+    message(STATUS "<<< Building WHAM >>>")
+  endif()
 endif()
 if(ENABLE_TESTING)
   message(STATUS "<<< Building Unit Tests >>>")

cmake/Modules/Documentation.cmake

@@ -4,6 +4,8 @@
 option(BUILD_DOC "Build LAMMPS HTML documentation" OFF)
 
 if(BUILD_DOC)
+  option(BUILD_DOC_VENV "Build LAMMPS documentation virtual environment" ON)
+  mark_as_advanced(BUILD_DOC_VENV)
   # Current Sphinx versions require at least Python 3.8
   # use default (or custom) Python executable, if version is sufficient
   if(Python_VERSION VERSION_GREATER_EQUAL 3.8)
@@ -18,14 +20,6 @@ if(BUILD_DOC)
   find_package(Doxygen 1.8.10 REQUIRED)
   file(GLOB DOC_SOURCES CONFIGURE_DEPENDS ${LAMMPS_DOC_DIR}/src/[^.]*.rst)
 
-  add_custom_command(
-    OUTPUT docenv
-    COMMAND ${VIRTUALENV} docenv
-  )
-
-  set(DOCENV_BINARY_DIR ${CMAKE_BINARY_DIR}/docenv/bin)
-  set(DOCENV_REQUIREMENTS_FILE ${LAMMPS_DOC_DIR}/utils/requirements.txt)
-
   set(SPHINX_CONFIG_DIR ${LAMMPS_DOC_DIR}/utils/sphinx-config)
   set(SPHINX_CONFIG_FILE_TEMPLATE ${SPHINX_CONFIG_DIR}/conf.py.in)
   set(SPHINX_STATIC_DIR  ${SPHINX_CONFIG_DIR}/_static)
@@ -44,14 +38,32 @@ if(BUILD_DOC)
   # configure paths in conf.py, since relative paths change when file is copied
   configure_file(${SPHINX_CONFIG_FILE_TEMPLATE} ${DOC_BUILD_CONFIG_FILE})
 
-  add_custom_command(
-    OUTPUT ${DOC_BUILD_DIR}/requirements.txt
-    DEPENDS docenv ${DOCENV_REQUIREMENTS_FILE}
-    COMMAND ${CMAKE_COMMAND} -E copy ${DOCENV_REQUIREMENTS_FILE} ${DOC_BUILD_DIR}/requirements.txt
-    COMMAND ${DOCENV_BINARY_DIR}/pip $ENV{PIP_OPTIONS} install --upgrade pip
-    COMMAND ${DOCENV_BINARY_DIR}/pip $ENV{PIP_OPTIONS} install --upgrade ${LAMMPS_DOC_DIR}/utils/converters
-    COMMAND ${DOCENV_BINARY_DIR}/pip $ENV{PIP_OPTIONS} install -r ${DOC_BUILD_DIR}/requirements.txt --upgrade
-  )
+  if(BUILD_DOC_VENV)
+    add_custom_command(
+      OUTPUT docenv
+      COMMAND ${VIRTUALENV} docenv
+    )
+
+    set(DOCENV_BINARY_DIR ${CMAKE_BINARY_DIR}/docenv/bin)
+    set(DOCENV_REQUIREMENTS_FILE ${LAMMPS_DOC_DIR}/utils/requirements.txt)
+
+    add_custom_command(
+      OUTPUT ${DOC_BUILD_DIR}/requirements.txt
+      DEPENDS docenv ${DOCENV_REQUIREMENTS_FILE}
+      COMMAND ${CMAKE_COMMAND} -E copy ${DOCENV_REQUIREMENTS_FILE} ${DOC_BUILD_DIR}/requirements.txt
+      COMMAND ${DOCENV_BINARY_DIR}/pip $ENV{PIP_OPTIONS} install --upgrade pip
+      COMMAND ${DOCENV_BINARY_DIR}/pip $ENV{PIP_OPTIONS} install --upgrade ${LAMMPS_DOC_DIR}/utils/converters
+      COMMAND ${DOCENV_BINARY_DIR}/pip $ENV{PIP_OPTIONS} install -r ${DOC_BUILD_DIR}/requirements.txt --upgrade
+    )
+
+    set(DOCENV_DEPS docenv ${DOC_BUILD_DIR}/requirements.txt)
+    if(NOT TARGET Sphinx::sphinx-build)
+      add_executable(Sphinx::sphinx-build IMPORTED GLOBAL)
+      set_target_properties(Sphinx::sphinx-build PROPERTIES IMPORTED_LOCATION "${DOCENV_BINARY_DIR}/sphinx-build")
+    endif()
+  else()
+    find_package(Sphinx)
+  endif()
 
   set(MATHJAX_URL "https://github.com/mathjax/MathJax/archive/3.1.3.tar.gz" CACHE STRING "URL for MathJax tarball")
   set(MATHJAX_MD5 "b81661c6e6ba06278e6ae37b30b0c492" CACHE STRING "MD5 checksum of MathJax tarball")
@@ -97,8 +109,9 @@ if(BUILD_DOC)
   endif()
   add_custom_command(
     OUTPUT html
-    DEPENDS ${DOC_SOURCES} docenv ${DOC_BUILD_DIR}/requirements.txt ${DOXYGEN_XML_DIR}/index.xml ${BUILD_DOC_CONFIG_FILE}
-    COMMAND ${DOCENV_BINARY_DIR}/sphinx-build ${SPHINX_EXTRA_OPTS} -b html -c ${DOC_BUILD_DIR} -d ${DOC_BUILD_DIR}/doctrees ${LAMMPS_DOC_DIR}/src ${DOC_BUILD_DIR}/html
+    DEPENDS ${DOC_SOURCES} ${DOCENV_DEPS} ${DOXYGEN_XML_DIR}/index.xml ${BUILD_DOC_CONFIG_FILE}
+    COMMAND ${Python3_EXECUTABLE} ${LAMMPS_DOC_DIR}/utils/make-globbed-tocs.py -d ${LAMMPS_DOC_DIR}/src
+    COMMAND Sphinx::sphinx-build ${SPHINX_EXTRA_OPTS} -b html -c ${DOC_BUILD_DIR} -d ${DOC_BUILD_DIR}/doctrees ${LAMMPS_DOC_DIR}/src ${DOC_BUILD_DIR}/html
     COMMAND ${CMAKE_COMMAND} -E create_symlink Manual.html ${DOC_BUILD_DIR}/html/index.html
     COMMAND ${CMAKE_COMMAND} -E copy_directory ${LAMMPS_DOC_DIR}/src/PDF ${DOC_BUILD_DIR}/html/PDF
     COMMAND ${CMAKE_COMMAND} -E remove -f ${DOXYGEN_XML_DIR}/run.stamp

cmake/Modules/FindSphinx.cmake

@@ -0,0 +1,29 @@
+# Find sphinx-build
+find_program(Sphinx_EXECUTABLE NAMES sphinx-build
+	                       PATH_SUFFIXES bin
+			       DOC "Sphinx documenation build executable")
+mark_as_advanced(Sphinx_EXECUTABLE)
+
+if(Sphinx_EXECUTABLE)
+  execute_process(COMMAND ${Sphinx_EXECUTABLE} --version
+                  OUTPUT_VARIABLE sphinx_version
+                  OUTPUT_STRIP_TRAILING_WHITESPACE
+                  RESULT_VARIABLE _sphinx_version_result)
+
+  if(_sphinx_version_result)
+    message(WARNING "Unable to determine sphinx-build verison: ${_sphinx_version_result}")
+  else()
+    string(REGEX REPLACE "sphinx-build ([0-9.]+).*"
+                         "\\1"
+                         Sphinx_VERSION
+                         "${sphinx_version}")
+  endif()
+
+  if(NOT TARGET Sphinx::sphinx-build)
+    add_executable(Sphinx::sphinx-build IMPORTED GLOBAL)
+    set_target_properties(Sphinx::sphinx-build PROPERTIES IMPORTED_LOCATION "${Sphinx_EXECUTABLE}")
+  endif()
+endif()
+
+include(FindPackageHandleStandardArgs)
+find_package_handle_standard_args(Sphinx REQUIRED_VARS Sphinx_EXECUTABLE VERSION_VAR Sphinx_VERSION)

cmake/Modules/FindVORO.cmake

@@ -21,9 +21,9 @@ if(VORO_FOUND)
   set(VORO_LIBRARIES ${VORO_LIBRARY})
   set(VORO_INCLUDE_DIRS ${VORO_INCLUDE_DIR})
 
-  if(NOT TARGET VORO::VORO)
-    add_library(VORO::VORO UNKNOWN IMPORTED)
-    set_target_properties(VORO::VORO PROPERTIES
+  if(NOT TARGET VORO::voro++)
+    add_library(VORO::voro++ UNKNOWN IMPORTED)
+    set_target_properties(VORO::voro++ PROPERTIES
       IMPORTED_LOCATION "${VORO_LIBRARY}"
       INTERFACE_INCLUDE_DIRECTORIES "${VORO_INCLUDE_DIR}")
   endif()

cmake/Modules/Packages/EXTRA-COMMAND.cmake

@@ -0,0 +1,10 @@
+# the geturl command needs libcurl
+
+find_package(CURL QUIET COMPONENTS HTTP HTTPS)
+option(WITH_CURL "Enable libcurl support" ${CURL_FOUND})
+if(WITH_CURL)
+  find_package(CURL REQUIRED COMPONENTS HTTP HTTPS)
+  target_compile_definitions(lammps PRIVATE -DLAMMPS_CURL)
+  target_link_libraries(lammps PRIVATE CURL::libcurl)
+endif()
+

cmake/Modules/Packages/H5MD.cmake

@@ -3,7 +3,7 @@ enable_language(C)
 # we don't use the parallel i/o interface.
 set(HDF5_PREFER_PARALLEL FALSE)
 
-find_package(HDF5 REQUIRED)
+find_package(HDF5 COMPONENTS C REQUIRED)
 
 # parallel HDF5 will import incompatible MPI headers with a serial build
 if((NOT BUILD_MPI) AND HDF5_IS_PARALLEL)

cmake/Modules/Packages/KOKKOS.cmake

@@ -7,10 +7,13 @@ endif()
 
 ########################################################################
 # consistency checks and Kokkos options/settings required by LAMMPS
-if(Kokkos_ENABLE_CUDA)
-  message(STATUS "KOKKOS: Enabling CUDA LAMBDA function support")
-  set(Kokkos_ENABLE_CUDA_LAMBDA ON CACHE BOOL "" FORCE)
+if(Kokkos_ENABLE_HIP)
+  option(Kokkos_ENABLE_HIP_MULTIPLE_KERNEL_INSTANTIATIONS "Enable multiple kernel instantiations with HIP" ON)
+  mark_as_advanced(Kokkos_ENABLE_HIP_MULTIPLE_KERNEL_INSTANTIATIONS)
+  option(Kokkos_ENABLE_ROCTHRUST "Use RoCThrust library" ON)
+  mark_as_advanced(Kokkos_ENABLE_ROCTHRUST)
 endif()
+
 # Adding OpenMP compiler flags without the checks done for
 # BUILD_OMP can result in compile failures. Enforce consistency.
 if(Kokkos_ENABLE_OPENMP)
@@ -18,6 +21,15 @@ if(Kokkos_ENABLE_OPENMP)
     message(FATAL_ERROR "Must enable BUILD_OMP with Kokkos_ENABLE_OPENMP")
   endif()
 endif()
+
+if(Kokkos_ENABLE_SERIAL)
+  if(NOT (Kokkos_ENABLE_OPENMP OR Kokkos_ENABLE_THREADS OR
+    Kokkos_ENABLE_CUDA OR Kokkos_ENABLE_HIP OR Kokkos_ENABLE_SYCL
+    OR Kokkos_ENABLE_OPENMPTARGET))
+  option(Kokkos_ENABLE_ATOMICS_BYPASS "Disable atomics for Kokkos Serial Backend" ON)
+  mark_as_advanced(Kokkos_ENABLE_ATOMICS_BYPASS)
+  endif()
+endif()
 ########################################################################
 
 option(EXTERNAL_KOKKOS "Build against external kokkos library" OFF)
@@ -45,8 +57,8 @@ if(DOWNLOAD_KOKKOS)
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
   include(ExternalProject)
-  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.3.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "243de871b3dc2cf3990c1c404032df83" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.5.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_MD5 "4d832aa0284169d9e3fbae3165286bc6" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   GetFallbackURL(KOKKOS_URL KOKKOS_FALLBACK)
@@ -71,7 +83,7 @@ if(DOWNLOAD_KOKKOS)
   add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
   add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 4.3.01 REQUIRED CONFIG)
+  find_package(Kokkos 4.5.01 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
 else()
   set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)
@@ -105,6 +117,7 @@ set(KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/atom_vec_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/comm_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/comm_tiled_kokkos.cpp
+                       ${KOKKOS_PKG_SOURCES_DIR}/group_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/min_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/min_linesearch_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/neighbor_kokkos.cpp
@@ -127,7 +140,7 @@ if(PKG_KSPACE)
                                  ${KOKKOS_PKG_SOURCES_DIR}/grid3d_kokkos.cpp
                                  ${KOKKOS_PKG_SOURCES_DIR}/remap_kokkos.cpp)
   set(FFT_KOKKOS "KISS" CACHE STRING "FFT library for Kokkos-enabled KSPACE package")
-  set(FFT_KOKKOS_VALUES KISS FFTW3 MKL HIPFFT CUFFT)
+  set(FFT_KOKKOS_VALUES KISS FFTW3 MKL NVPL HIPFFT CUFFT MKL_GPU)
   set_property(CACHE FFT_KOKKOS PROPERTY STRINGS ${FFT_KOKKOS_VALUES})
   validate_option(FFT_KOKKOS FFT_KOKKOS_VALUES)
   string(TOUPPER ${FFT_KOKKOS} FFT_KOKKOS)
@@ -137,10 +150,8 @@ if(PKG_KSPACE)
       message(FATAL_ERROR "The CUDA backend of Kokkos requires either KISS FFT or CUFFT.")
     elseif(FFT_KOKKOS STREQUAL "KISS")
       message(WARNING "Using KISS FFT with the CUDA backend of Kokkos may be sub-optimal.")
-      target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_KISS)
     elseif(FFT_KOKKOS STREQUAL "CUFFT")
       find_package(CUDAToolkit REQUIRED)
-      target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_CUFFT)
       target_link_libraries(lammps PRIVATE CUDA::cufft)
     endif()
   elseif(Kokkos_ENABLE_HIP)
@@ -152,10 +163,21 @@ if(PKG_KSPACE)
     elseif(FFT_KOKKOS STREQUAL "HIPFFT")
       include(DetectHIPInstallation)
       find_package(hipfft REQUIRED)
-      target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_HIPFFT)
       target_link_libraries(lammps PRIVATE hip::hipfft)
     endif()
+  elseif(FFT_KOKKOS STREQUAL "MKL_GPU")
+    if(NOT Kokkos_ENABLE_SYCL)
+      message(FATAL_ERROR "Using MKL_GPU FFT currently requires the SYCL backend of Kokkos.")
+    endif()
+    find_package(MKL REQUIRED)
+    target_link_libraries(lammps PRIVATE mkl_sycl_dft mkl_intel_ilp64 mkl_tbb_thread mkl_core tbb)
+  elseif(FFT_KOKKOS STREQUAL "MKL")
+    find_package(MKL REQUIRED)
+  elseif(FFT_KOKKOS STREQUAL "NVPL")
+      find_package(nvpl_fft REQUIRED)
+      target_link_libraries(lammps PRIVATE nvpl::fftw)
   endif()
+  target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_${FFT_KOKKOS})
 endif()
 
 if(PKG_ML-IAP)

cmake/Modules/Packages/KSPACE.cmake

@@ -10,7 +10,7 @@ if(${FFTW}_FOUND)
 else()
   set(FFT "KISS" CACHE STRING "FFT library for KSPACE package")
 endif()
-set(FFT_VALUES KISS FFTW3 MKL)
+set(FFT_VALUES KISS FFTW3 MKL NVPL)
 set_property(CACHE FFT PROPERTY STRINGS ${FFT_VALUES})
 validate_option(FFT FFT_VALUES)
 string(TOUPPER ${FFT} FFT)
@@ -41,6 +41,10 @@ elseif(FFT STREQUAL "MKL")
     target_compile_definitions(lammps PRIVATE -DFFT_MKL_THREADS)
   endif()
   target_link_libraries(lammps PRIVATE MKL::MKL)
+elseif(FFT STREQUAL "NVPL")
+  find_package(nvpl_fft REQUIRED)
+  target_compile_definitions(lammps PRIVATE -DFFT_NVPL)
+  target_link_libraries(lammps PRIVATE nvpl::fftw)
 else()
   # last option is KISSFFT
   target_compile_definitions(lammps PRIVATE -DFFT_KISS)

cmake/Modules/Packages/ML-PACE.cmake

@@ -1,50 +1,62 @@
 # PACE library support for ML-PACE package
+find_package(pace QUIET)
 
-# set policy to silence warnings about timestamps of downloaded files. review occasionally if it may be set to NEW
-if(POLICY CMP0135)
-  cmake_policy(SET CMP0135 OLD)
-endif()
-
-set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.11.25.fix.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
-set(PACELIB_MD5 "b45de9a633f42ed65422567e3ce56f9f" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
-mark_as_advanced(PACELIB_URL)
-mark_as_advanced(PACELIB_MD5)
-GetFallbackURL(PACELIB_URL PACELIB_FALLBACK)
-
-# LOCAL_ML-PACE points to top-level dir with local lammps-user-pace repo,
-# to make it easier to check local build without going through the public github releases
-if(LOCAL_ML-PACE)
- set(lib-pace "${LOCAL_ML-PACE}")
+if(pace_FOUND)
+    find_package(pace)
+    target_link_libraries(lammps PRIVATE pace::pace)
 else()
-  # download library sources to build folder
-  if(EXISTS ${CMAKE_BINARY_DIR}/libpace.tar.gz)
-    file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
-  endif()
-  if(NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}")
-    message(STATUS "Downloading ${PACELIB_URL}")
-    file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz STATUS DL_STATUS SHOW_PROGRESS)
-    file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
-    if((NOT DL_STATUS EQUAL 0) OR (NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}"))
-      message(WARNING "Download from primary URL ${PACELIB_URL} failed\nTrying fallback URL ${PACELIB_FALLBACK}")
-      file(DOWNLOAD ${PACELIB_FALLBACK} ${CMAKE_BINARY_DIR}/libpace.tar.gz EXPECTED_HASH MD5=${PACELIB_MD5} SHOW_PROGRESS)
+    # set policy to silence warnings about timestamps of downloaded files. review occasionally if it may be set to NEW
+    if(POLICY CMP0135)
+      cmake_policy(SET CMP0135 OLD)
     endif()
-  else()
-    message(STATUS "Using already downloaded archive ${CMAKE_BINARY_DIR}/libpace.tar.gz")
-  endif()
+
+    set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.11.25.fix2.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
+    set(PACELIB_MD5 "a53bd87cfee8b07d9f44bc17aad69c3f" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
+    mark_as_advanced(PACELIB_URL)
+    mark_as_advanced(PACELIB_MD5)
+    GetFallbackURL(PACELIB_URL PACELIB_FALLBACK)
+
+    # LOCAL_ML-PACE points to top-level dir with local lammps-user-pace repo,
+    # to make it easier to check local build without going through the public github releases
+    if(LOCAL_ML-PACE)
+     set(lib-pace "${LOCAL_ML-PACE}")
+    else()
+      # download library sources to build folder
+      if(EXISTS ${CMAKE_BINARY_DIR}/libpace.tar.gz)
+        file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
+      endif()
+      if(NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}")
+        message(STATUS "Downloading ${PACELIB_URL}")
+        file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz STATUS DL_STATUS SHOW_PROGRESS)
+        file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
+        if((NOT DL_STATUS EQUAL 0) OR (NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}"))
+          message(WARNING "Download from primary URL ${PACELIB_URL} failed\nTrying fallback URL ${PACELIB_FALLBACK}")
+          file(DOWNLOAD ${PACELIB_FALLBACK} ${CMAKE_BINARY_DIR}/libpace.tar.gz EXPECTED_HASH MD5=${PACELIB_MD5} SHOW_PROGRESS)
+        endif()
+      else()
+        message(STATUS "Using already downloaded archive ${CMAKE_BINARY_DIR}/libpace.tar.gz")
+      endif()
 
 
-  # uncompress downloaded sources
-  execute_process(
-    COMMAND ${CMAKE_COMMAND} -E remove_directory lammps-user-pace*
-    COMMAND ${CMAKE_COMMAND} -E tar xzf libpace.tar.gz
-    WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
-  )
-  get_newest_file(${CMAKE_BINARY_DIR}/lammps-user-pace-* lib-pace)
-endif()
-
-add_subdirectory(${lib-pace} build-pace)
-set_target_properties(pace PROPERTIES CXX_EXTENSIONS ON OUTPUT_NAME lammps_pace${LAMMPS_MACHINE})
-
-if(CMAKE_PROJECT_NAME STREQUAL "lammps")
-  target_link_libraries(lammps PRIVATE pace)
+      # uncompress downloaded sources
+      execute_process(
+        COMMAND ${CMAKE_COMMAND} -E remove_directory lammps-user-pace*
+        COMMAND ${CMAKE_COMMAND} -E tar xzf libpace.tar.gz
+        WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
+      )
+      get_newest_file(${CMAKE_BINARY_DIR}/lammps-user-pace-* lib-pace)
+    endif()
+
+    # some preinstalled yaml-cpp versions don't provide a namespaced target
+    find_package(yaml-cpp QUIET)
+    if(TARGET yaml-cpp AND NOT TARGET yaml-cpp::yaml-cpp)
+      add_library(yaml-cpp::yaml-cpp ALIAS yaml-cpp)
+    endif()
+
+    add_subdirectory(${lib-pace} build-pace)
+    set_target_properties(pace PROPERTIES CXX_EXTENSIONS ON OUTPUT_NAME lammps_pace${LAMMPS_MACHINE})
+
+    if(CMAKE_PROJECT_NAME STREQUAL "lammps")
+      target_link_libraries(lammps PRIVATE pace)
+    endif()
 endif()

cmake/Modules/Packages/PLUMED.cmake

@@ -32,9 +32,9 @@ endif()
 
 # Note: must also adjust check for supported API versions in
 # fix_plumed.cpp when version changes from v2.n.x to v2.n+1.y
-set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.9.1/plumed-src-2.9.1.tgz"
+set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.9.2/plumed-src-2.9.2.tgz"
   CACHE STRING "URL for PLUMED tarball")
-set(PLUMED_MD5 "c3b2d31479c1e9ce211719d40e9efbd7" CACHE STRING "MD5 checksum of PLUMED tarball")
+set(PLUMED_MD5 "04862602a372c1013bdfee2d6d03bace" CACHE STRING "MD5 checksum of PLUMED tarball")
 
 mark_as_advanced(PLUMED_URL)
 mark_as_advanced(PLUMED_MD5)

cmake/Modules/Packages/RHEO.cmake

@@ -1,2 +0,0 @@
-find_package(GSL 2.6 REQUIRED)
-target_link_libraries(lammps PRIVATE GSL::gsl)

cmake/Modules/Packages/VORONOI.cmake

@@ -54,5 +54,5 @@ else()
   if(NOT VORO_FOUND)
     message(FATAL_ERROR "Voro++ library not found. Help CMake to find it by setting VORO_LIBRARY and VORO_INCLUDE_DIR, or set DOWNLOAD_VORO=ON to download it")
   endif()
-  target_link_libraries(lammps PRIVATE VORO::VORO)
+  target_link_libraries(lammps PRIVATE VORO::voro++)
 endif()

cmake/Modules/Packages/VTK.cmake

@@ -1,3 +1,5 @@
+# FindVTK requires that C support is enabled when looking for MPI support
+enable_language(C)
 find_package(VTK REQUIRED NO_MODULE)
 target_compile_definitions(lammps PRIVATE -DLAMMPS_VTK)
 if (VTK_MAJOR_VERSION VERSION_LESS 9.0)

cmake/presets/kokkos-sycl-intel.cmake

@@ -0,0 +1,29 @@
+# preset that enables KOKKOS and selects SYCL compilation with OpenMP
+# enabled as well. Also sets some performance related compiler flags.
+set(PKG_KOKKOS ON CACHE BOOL "" FORCE)
+set(Kokkos_ENABLE_SERIAL ON CACHE BOOL "" FORCE)
+set(Kokkos_ENABLE_OPENMP ON CACHE BOOL "" FORCE)
+set(Kokkos_ENABLE_CUDA   OFF CACHE BOOL "" FORCE)
+set(Kokkos_ENABLE_SYCL   ON CACHE BOOL "" FORCE)
+
+set(FFT "MKL" CACHE STRING "" FORCE)
+set(FFT_KOKKOS "MKL_GPU" CACHE STRING "" FORCE)
+
+unset(USE_INTERNAL_LINALG)
+unset(USE_INTERNAL_LINALG CACHE)
+set(BLAS_VENDOR "Intel10_64_dyn")
+
+# hide deprecation warnings temporarily for stable release
+set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
+
+set(CMAKE_CXX_COMPILER icpx CACHE STRING "" FORCE)
+set(CMAKE_C_COMPILER icx CACHE STRING "" FORCE)
+set(CMAKE_Fortran_COMPILER "" CACHE STRING "" FORCE)
+set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
+set(CMAKE_CXX_STANDARD 17 CACHE STRING "" FORCE)
+# Silence everything
+set(CMAKE_CXX_FLAGS "-w" CACHE STRING "" FORCE)
+#set(CMAKE_EXE_LINKER_FLAGS "-fsycl -flink-huge-device-code -fsycl-targets=spir64_gen " CACHE STRING "" FORCE)
+#set(CMAKE_TUNE_FLAGS "-O3 -fsycl -fsycl-device-code-split=per_kernel -fsycl-targets=spir64_gen" CACHE STRING "" FORCE)
+set(CMAKE_EXE_LINKER_FLAGS "-fsycl -flink-huge-device-code " CACHE STRING "" FORCE)
+set(CMAKE_TUNE_FLAGS "-O3 -fsycl -fsycl-device-code-split=per_kernel " CACHE STRING "" FORCE)

cmake/presets/mingw-cross.cmake

@@ -67,6 +67,7 @@ set(WIN_PACKAGES
   REACTION
   REAXFF
   REPLICA
+  RHEO
   RIGID
   SHOCK
   SMTBQ

cmake/presets/most.cmake

@@ -60,6 +60,7 @@ set(ALL_PACKAGES
   REACTION
   REAXFF
   REPLICA
+  RHEO
   RIGID
   SHOCK
   SPH

cmake/presets/oneapi.cmake

@@ -3,26 +3,9 @@
 set(CMAKE_CXX_COMPILER "icpx" CACHE STRING "" FORCE)
 set(CMAKE_C_COMPILER "icx" CACHE STRING "" FORCE)
 set(CMAKE_Fortran_COMPILER "ifx" CACHE STRING "" FORCE)
-set(CMAKE_CXX_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
-set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
-set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
-set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
-set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
-set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
-set(CMAKE_C_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
-set(CMAKE_C_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
-set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
-
 set(MPI_CXX "icpx" CACHE STRING "" FORCE)
 set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
 
-unset(HAVE_OMP_H_INCLUDE CACHE)
-set(OpenMP_C "icx" CACHE STRING "" FORCE)
-set(OpenMP_C_FLAGS "-qopenmp;-qopenmp-simd" CACHE STRING "" FORCE)
-set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
-set(OpenMP_CXX "icpx" CACHE STRING "" FORCE)
-set(OpenMP_CXX_FLAGS "-qopenmp;-qopenmp-simd" CACHE STRING "" FORCE)
-set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
-set(OpenMP_Fortran_FLAGS "-qopenmp;-qopenmp-simd" CACHE STRING "" FORCE)
-set(OpenMP_omp_LIBRARY "libiomp5.so" CACHE PATH "" FORCE)
+# force using internal BLAS/LAPCK since external ones may not be ABI compatible
+set(USE_INTERNAL_LINALG ON CACHE BOOL "" FORCE)
 

cmake/presets/windows.cmake

@@ -60,6 +60,7 @@ set(WIN_PACKAGES
   REACTION
   REAXFF
   REPLICA
+  RHEO
   RIGID
   SHOCK
   SMTBQ

doc/.gitignore

@@ -17,3 +17,10 @@
 *.el
 /utils/sphinx-config/_static/mathjax
 /utils/sphinx-config/_static/polyfill.js
+/src/pairs.rst
+/src/bonds.rst
+/src/angles.rst
+/src/dihedrals.rst
+/src/impropers.rst
+/src/computes.rst
+/src/fixes.rst

doc/Makefile

@@ -83,7 +83,10 @@ $(SPHINXCONFIG)/conf.py: $(SPHINXCONFIG)/conf.py.in
 	    -e 's,@LAMMPS_PYTHON_DIR@,$(BUILDDIR)/../python,g' \
 	    -e 's,@LAMMPS_DOC_DIR@,$(BUILDDIR),g' $< > $@
 
-html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
+globbed-tocs:
+	$(PYTHON) $(BUILDDIR)/utils/make-globbed-tocs.py -d $(RSTDIR)
+
+html: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
 	@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
 	@$(MAKE) $(MFLAGS) -C graphviz all
 	@(\
@@ -113,7 +116,7 @@ html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
 	@rm -rf html/PDF/.[sg]*
 	@echo "Build finished. The HTML pages are in doc/html."
 
-fasthtml: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
+fasthtml: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
 	@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
 	@$(MAKE) $(MFLAGS) -C graphviz all
 	@mkdir -p fasthtml
@@ -132,7 +135,7 @@ fasthtml: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
 	@rm -rf fasthtml/PDF/.[sg]*
 	@echo "Fast HTML build finished. The HTML pages are in doc/fasthtml."
 
-spelling: xmlgen $(SPHINXCONFIG)/conf.py $(VENV) $(SPHINXCONFIG)/false_positives.txt
+spelling: xmlgen globbed-tocs $(SPHINXCONFIG)/conf.py $(VENV) $(SPHINXCONFIG)/false_positives.txt
 	@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
 	@(\
 		. $(VENV)/bin/activate ; \
@@ -143,7 +146,7 @@ spelling: xmlgen $(SPHINXCONFIG)/conf.py $(VENV) $(SPHINXCONFIG)/false_positives
 	)
 	@echo "Spell check finished."
 
-epub: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
+epub: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
 	@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
 	@$(MAKE) $(MFLAGS) -C graphviz all
 	@mkdir -p epub/JPG
@@ -166,7 +169,7 @@ mobi: epub
 	@ebook-convert LAMMPS.epub LAMMPS.mobi
 	@echo "Conversion finished. The MOBI manual file is created."
 
-pdf: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
+pdf: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
 	@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
 	@$(MAKE) $(MFLAGS) -C graphviz all
 	@if [ "$(HAS_PDFLATEX)" == "NO" ] ; then echo "PDFLaTeX or latexmk were not found! Please check README for further instructions" 1>&2; exit 1; fi

doc/documentation_conventions.md

@@ -10,7 +10,7 @@ Last change: 2022-12-30
 
 In fall 2019, the LAMMPS documentation file format has changed from a
 home grown markup designed to generate HTML format files only, to
-[reStructuredText](https://docutils.sourceforge.io/rst.html>.  For a
+[reStructuredText](https://docutils.sourceforge.io/rst.html>).  For a
 transition period all files in the old .txt format were transparently
 converted to .rst and then processed.  The `txt2rst tool` is still
 included in the distribution to obtain an initial .rst file for legacy
@@ -45,8 +45,7 @@ what kind of information and sections are needed.
 
 ## Formatting conventions
 
-For headlines we try to follow the conventions posted here:
-https://documentation-style-guide-sphinx.readthedocs.io/en/latest/style-guide.html#headings
+For headlines we try to follow the conventions posted [here](https://documentation-style-guide-sphinx.readthedocs.io/en/latest/style-guide.html#headings).
 It seems to be sufficient to have this consistent only within
 any single file and it is not (yet) enforced strictly, but making
 this globally consistent makes it easier to move sections around.
@@ -64,7 +63,7 @@ Groups of shell commands or LAMMPS input script or C/C++/Python source
 code should be typeset into a `.. code-block::` section. A syntax
 highlighting extension for LAMMPS input scripts is provided, so `LAMMPS`
 can be used to indicate the language in the code block in addition to
-`bash`, `c`, `c++`, `console`, `csh`, `diff', `fortran`, `json`, `make`,
+`bash`, `c`, `c++`, `console`, `csh`, `diff`, `fortran`, `json`, `make`,
 `perl`, `powershell`, `python`, `sh`, or `tcl`, `text`, or `yaml`.  When
 no syntax style is indicated, no syntax highlighting is performed.  When
 typesetting commands executed on the shell, please do not prefix
@@ -84,7 +83,7 @@ block can be used, followed by multiple `.. tab::` blocks, one
 for each alternative. This is only used for HTML output. For other
 outputs, the `.. tabs::` directive is transparently removed and
 the individual `.. tab::` blocks will be replaced with an
-`.. admonition::`` block. Thus in PDF and ePUB output those will
+`.. admonition::` block. Thus in PDF and ePUB output those will
 be realized as sequential and plain notes.
 
 Special remarks can be highlighted with a `.. note::` block and

doc/doxygen/Doxyfile.in

@@ -2,7 +2,7 @@
 
 DOXYFILE_ENCODING      = UTF-8
 PROJECT_NAME           = "LAMMPS Programmer's Guide"
-PROJECT_NUMBER         = "4 May 2022"
+PROJECT_NUMBER         = "19 November 2024"
 PROJECT_BRIEF          = "Documentation of the LAMMPS library interface and Python wrapper"
 PROJECT_LOGO           = lammps-logo.png
 CREATE_SUBDIRS         = NO

doc/github-development-workflow.md

@@ -6,7 +6,9 @@ choices the LAMMPS developers have agreed on. Git and GitHub provide the
 tools, but do not set policies, so it is up to the developers to come to
 an agreement as to how to define and interpret policies. This document
 is likely to change as our experiences and needs change, and we try to
-adapt it accordingly. Last change 2023-02-10.
+adapt it accordingly.
+
+Last change: 2023-02-10
 
 ## Table of Contents
 
@@ -72,7 +74,7 @@ be assigned to signal urgency to merge this pull request quickly.
 People can be assigned to review a pull request in two ways:
 
   * They can be assigned manually to review a pull request
-    by the submitter or a LAMMPS developer
+    by the submitter or a LAMMPS developer.
   * They can be automatically assigned, because a developer's GitHub
     handle matches a file pattern in the `.github/CODEOWNERS` file,
     which associates developers with the code they contributed and
@@ -86,9 +88,9 @@ required before merging, in addition to passing all automated
 compilation and unit tests.  Merging counts as implicit approval, so
 does submission of a pull request (by a LAMMPS developer). So the person
 doing the merge may not also submit an approving review.  The GitHub
-feature, that reviews from code owners are "hard" reviews (i.e. they
-must all approve before merging is allowed), is currently disabled.
-It is in the discretion of the merge maintainer to assess when a
+feature that reviews from code owners are "hard" reviews (i.e. they
+must all approve before merging is allowed) is currently disabled.
+It is at the discretion of the merge maintainer to assess when a
 sufficient degree of approval has been reached, especially from external
 collaborators.  Reviews may be (automatically) dismissed, when the
 reviewed code has been changed. Review may be requested a second time.
@@ -147,7 +149,8 @@ only contain bug fixes, feature additions to peripheral functionality,
 and documentation updates.  In between stable releases, bug fixes and
 infrastructure updates are back-ported from the "develop" branch to the
 "maintenance" branch and occasionally merged into "stable" and published
-as update releases.
+as update releases. Further explanation of LAMMPS versions can be found
+[in the documentation](https://docs.lammps.org/Manual_version.html).
 
 ## Project Management
 

doc/lammps.1

@@ -1,7 +1,7 @@
-.TH LAMMPS "1" "29 August 2024" "2024-08-29"
+.TH LAMMPS "1" "19 November 2024" "2024-11-19"
 .SH NAME
 .B LAMMPS
-\- Molecular Dynamics Simulator.  Version 29 August 2024
+\- Molecular Dynamics Simulator.  Version 19 November 2024
 
 .SH SYNOPSIS
 .B lmp

doc/msi2lmp.1

@@ -1,4 +1,4 @@
-.TH MSI2LMP "1" "v3.9.10" "2023-03-10"
+.TH MSI2LMP "1" "v3.9.11" "2024-09-06"
 .SH NAME
 .B MSI2LMP
 \- Converter for Materials Studio files to LAMMPS
@@ -101,7 +101,7 @@ msi2lmp decane -c 0 -f oplsaa
 
 
 .SH COPYRIGHT
-© 2003--2022 Sandia Corporation
+© 2003--2024 Sandia Corporation
 
 This package is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License version 2 as

doc/src/Build.rst

@@ -1,10 +1,14 @@
 Build LAMMPS
 ============
 
-LAMMPS is built as a library and an executable from source code using
-either traditional makefiles for use with GNU make (which may require
-manual editing), or using a build environment generated by CMake (Unix
-Makefiles, Ninja, Xcode, Visual Studio, KDevelop, CodeBlocks and more).
+LAMMPS is built as a library and an executable from source code using a
+build environment generated by CMake (Unix Makefiles, Ninja, Xcode,
+Visual Studio, KDevelop, CodeBlocks and more depending on the platform).
+Using CMake is the preferred way to build LAMMPS.  In addition, LAMMPS
+can be compiled using the legacy build system based on traditional
+makefiles for use with GNU make (which may require manual editing).
+Support for the legacy build system is slowly being phased out and may
+not be available for all optional features.
 
 As an alternative, you can download a package with pre-built executables
 or automated build trees, as described in the :doc:`Install <Install>`

doc/src/Build_basics.rst

@@ -160,7 +160,7 @@ with the OpenMP 3.1 semantics used in LAMMPS for maximal compatibility
 with compiler versions in use.  If compilation with OpenMP enabled fails
 because of your compiler requiring strict OpenMP 4.0 semantics, you can
 change the behavior by adding ``-D LAMMPS_OMP_COMPAT=4`` to the
-``LMP_INC`` variable in your makefile, or add it to the command line
+``LMP_INC`` variable in your makefile, or add it to the command-line flags
 while configuring with CMake.  LAMMPS will auto-detect a suitable setting
 for most GNU, Clang, and Intel compilers.
 
@@ -502,6 +502,8 @@ using CMake or Make.
                                       # chain.x, micelle2d.x, msi2lmp, phana,
                                       # stl_bin2txt
          -D BUILD_LAMMPS_GUI=value    # yes or no (default). Build LAMMPS-GUI
+         -D BUILD_WHAM=value          # yes (default). Download and build WHAM;
+                                      # only available for BUILD_LAMMPS_GUI=yes
 
       The generated binaries will also become part of the LAMMPS installation
       (see below).

doc/src/Build_cmake.rst

@@ -8,7 +8,7 @@ packages.  Links to those pages on the :doc:`Build overview <Build>`
 page.
 
 The following text assumes some familiarity with CMake and focuses on
-using the command line tool ``cmake`` and what settings are supported
+using the command-line tool ``cmake`` and what settings are supported
 for building LAMMPS.  A more detailed tutorial on how to use CMake
 itself, the text mode or graphical user interface, to change the
 generated output files for different build tools and development
@@ -16,7 +16,7 @@ environments is on a :doc:`separate page <Howto_cmake>`.
 
 .. note::
 
-   LAMMPS currently requires that CMake version 3.16 or later is available.
+   LAMMPS currently requires that CMake version 3.20 or later is available.
 
 .. warning::
 
@@ -32,22 +32,22 @@ environments is on a :doc:`separate page <Howto_cmake>`.
 Advantages of using CMake
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
-CMake is an alternative to compiling LAMMPS in the traditional way
-through :doc:`(manually customized) makefiles <Build_make>`.  Using
-CMake has multiple advantages that are specifically helpful for
-people with limited experience in compiling software or for people
-that want to modify or extend LAMMPS.
+CMake is the preferred way of compiling LAMMPS in contrast to the legacy
+build system based on GNU make and through :doc:`(manually customized)
+makefiles <Build_make>`.  Using CMake has multiple advantages that are
+specifically helpful for people with limited experience in compiling
+software or for people that want to modify or extend LAMMPS.
 
 - CMake can detect available hardware, tools, features, and libraries
   and adapt the LAMMPS default build configuration accordingly.
 - CMake can generate files for different build tools and integrated
   development environments (IDE).
-- CMake supports customization of settings with a command line, text
+- CMake supports customization of settings with a command-line, text
   mode, or graphical user interface.  No manual editing of files,
-  knowledge of file formats or complex command line syntax is required.
+  knowledge of file formats or complex command-line syntax is required.
 - All enabled components are compiled in a single build operation.
 - Automated dependency tracking for all files and configuration options.
-- Support for true out-of-source compilation. Multiple configurations
+- Support for true out-of-source compilation.  Multiple configurations
   and settings with different choices of LAMMPS packages, settings, or
   compilers can be configured and built concurrently from the same
   source tree.
@@ -68,7 +68,7 @@ that purpose you can use either the command-line utility ``cmake`` (or
 graphical utility ``cmake-gui``, or use them interchangeably.  The
 second step is then the compilation and linking of all objects,
 libraries, and executables using the selected build tool.  Here is a
-minimal example using the command line version of CMake to build LAMMPS
+minimal example using the command-line version of CMake to build LAMMPS
 with no add-on packages enabled and no customization:
 
 .. code-block:: bash
@@ -131,7 +131,7 @@ file called ``CMakeLists.txt`` (for LAMMPS it is located in the
 configuration step.  The cache file contains all current CMake settings.
 
 To modify settings, enable or disable features, you need to set
-*variables* with either the ``-D`` command line flag (``-D
+*variables* with either the ``-D`` command-line flag (``-D
 VARIABLE1_NAME=value``) or change them in the text mode of the graphical
 user interface.  The ``-D`` flag can be used several times in one command.
 
@@ -141,11 +141,11 @@ a different compiler tool chain.  Those are loaded with the ``-C`` flag
 (``-C ../cmake/presets/basic.cmake``).  This step would only be needed
 once, as the settings from the preset files are stored in the
 ``CMakeCache.txt`` file. It is also possible to customize the build
-by adding one or more ``-D`` flags to the CMake command line.
+by adding one or more ``-D`` flags to the CMake command.
 
 Generating files for alternate build tools (e.g. Ninja) and project files
 for IDEs like Eclipse, CodeBlocks, or Kate can be selected using the ``-G``
-command line flag.  A list of available generator settings for your
+command-line flag.  A list of available generator settings for your
 specific CMake version is given when running ``cmake --help``.
 
 .. _cmake_multiconfig:

doc/src/Build_development.rst

@@ -138,12 +138,27 @@ during development:
 The status of this automated testing can be viewed on `https://ci.lammps.org
 <https://ci.lammps.org>`_.
 
-The scripts and inputs for integration, run, and regression testing
-are maintained in a
-`separate repository <https://github.com/lammps/lammps-testing>`_
-of the LAMMPS project on GitHub.  A few tests are also run as GitHub
-Actions and their configuration files are in the ``.github/workflows/``
-folder of the LAMMPS git tree.
+The scripts and inputs for integration, run, and legacy regression
+testing are maintained in a `separate repository
+<https://github.com/lammps/lammps-testing>`_ of the LAMMPS project on
+GitHub.  A few tests are also run as GitHub Actions and their
+configuration files are in the ``.github/workflows/`` folder of the
+LAMMPS git tree.
+
+Regression tests can also be performed locally with the :ref:`regression
+tester tool <regression>`.  The tool checks if a given LAMMPS binary run
+with selected input examples produces thermo output that is consistent
+with the provided log files.  The script can be run in one pass over all
+available input files, but it can also first create multiple lists of
+inputs or folders that can then be run with multiple workers
+concurrently to speed things up.  Another mode allows to do a quick
+check of inputs that contain commands that have changes in the current
+checkout branch relative to a git branch.  This works similar to the two
+pass mode, but will select only shorter runs and no more than 100 inputs
+that are chosen randomly.  This ensures that this test runs
+significantly faster compared to the full test run.  These test runs can
+also be performed with instrumented LAMMPS binaries (see previous
+section).
 
 The unit testing facility is integrated into the CMake build process of
 the LAMMPS source code distribution itself.  It can be enabled by
@@ -248,9 +263,9 @@ will be skipped if prerequisite features are not available in LAMMPS.
    time.  Preference is given to parts of the code base that are easy to
    test or commonly used.
 
-Tests as shown by the ``ctest`` program are command lines defined in the
+Tests as shown by the ``ctest`` program are commands defined in the
 ``CMakeLists.txt`` files in the ``unittest`` directory tree.  A few
-tests simply execute LAMMPS with specific command line flags and check
+tests simply execute LAMMPS with specific command-line flags and check
 the output to the screen for expected content.  A large number of unit
 tests are special tests programs using the `GoogleTest framework
 <https://github.com/google/googletest/>`_ and linked to the LAMMPS
@@ -405,7 +420,7 @@ during MD timestepping and manipulate per-atom properties like
 positions, velocities, and forces.  For those fix styles, testing can be
 done in a very similar fashion as for force fields and thus there is a
 test program `test_fix_timestep` that shares a lot of code, properties,
-and command line flags with the force field style testers described in
+and command-line flags with the force field style testers described in
 the previous section.
 
 This tester will set up a small molecular system run with verlet run
@@ -627,14 +642,38 @@ The following target are available for both, GNU make and CMake:
 
 .. _gh-cli:
 
-GitHub command line interface
+GitHub command-line interface
 -----------------------------
 
-GitHub is developing a `tool for the command line
-<https://cli.github.com>`_ that interacts with the GitHub website via a
-command called ``gh``.  This can be extremely convenient when working
-with a Git repository hosted on GitHub (like LAMMPS).  It is thus highly
-recommended to install it when doing LAMMPS development.
+GitHub has developed a `command-line tool <https://cli.github.com>`_
+to interact with the GitHub website via a command called ``gh``.
+This is extremely convenient when working with a Git repository hosted
+on GitHub (like LAMMPS).  It is thus highly recommended to install it
+when doing LAMMPS development.  To use ``gh`` you must be within a git
+checkout of a repository and you must obtain an authentication token
+to connect your checkout with a GitHub user.  This is done with the
+command: ``gh auth login`` where you then have to follow the prompts.
+Here are some examples:
 
-The capabilities of the ``gh`` command is continually expanding, so
-please see the documentation at https://cli.github.com/manual/
+.. list-table::
+   :header-rows: 1
+   :widths: 34 66
+
+   * - Command
+     - Description
+   * - ``gh pr list``
+     - List currently open pull requests
+   * - ``gh pr checks 404``
+     - Shows the status of all checks for pull request #404
+   * - ``gh pr view 404``
+     - Shows the description and recent comments for pull request #404
+   * - ``gh co 404``
+     - Check out the branch from pull request #404; set up for pushing changes
+   * - ``gh issue list``
+     - List currently open issues
+   * - ``gh issue view 430 --comments``
+     - Shows the description and all comments for issue #430
+
+The capabilities of the ``gh`` command are continually expanding, so
+for more details please see the documentation at https://cli.github.com/manual/
+or use ``gh --help`` or ``gh <command> --help`` for embedded help.

doc/src/Build_extras.rst

@@ -7,6 +7,8 @@ in addition to
 .. list-table::
    :align: center
    :header-rows: 1
+   :widths: 50 50
+   :width: 80%
 
    * - CMake build
      - Traditional make
@@ -46,6 +48,7 @@ This is the list of packages that may require additional steps.
    * :ref:`LEPTON <lepton>`
    * :ref:`MACHDYN <machdyn>`
    * :ref:`MDI <mdi>`
+   * :ref:`MISC <misc>`
    * :ref:`ML-HDNNP <ml-hdnnp>`
    * :ref:`ML-IAP <mliap>`
    * :ref:`ML-PACE <ml-pace>`
@@ -115,7 +118,7 @@ GPU package
 
 To build with this package, you must choose options for precision and
 which GPU hardware to build for. The GPU package currently supports
-three different types of backends: OpenCL, CUDA and HIP.
+three different types of back ends: OpenCL, CUDA and HIP.
 
 CMake build
 ^^^^^^^^^^^
@@ -205,9 +208,9 @@ necessary for ``hipcc`` and the linker to work correctly.
 .. versionadded:: 3Aug2022
 
 Using the CHIP-SPV implementation of HIP is supported. It allows one to
-run HIP code on Intel GPUs via the OpenCL or Level Zero backends. To use
+run HIP code on Intel GPUs via the OpenCL or Level Zero back ends. To use
 CHIP-SPV, you must set ``-DHIP_USE_DEVICE_SORT=OFF`` in your CMake
-command line as CHIP-SPV does not yet support hipCUB. As of Summer 2022,
+command-line as CHIP-SPV does not yet support hipCUB. As of Summer 2022,
 the use of HIP for Intel GPUs is experimental. You should only use this
 option in preparations to run on Aurora system at Argonne.
 
@@ -230,7 +233,7 @@ option in preparations to run on Aurora system at Argonne.
 
 .. code:: bash
 
-   # CUDA target (not recommended, use GPU_ARCH=cuda)
+   # CUDA target (not recommended, use GPU_API=cuda)
    # !!! DO NOT set CMAKE_CXX_COMPILER !!!
    export HIP_PLATFORM=nvcc
    export HIP_PATH=/path/to/HIP/install
@@ -419,9 +422,10 @@ minutes to hours) to build.  Of course you only need to do that once.)
       cmake build system.  The ``lib/kim/Install.py`` script supports a
       ``CMAKE`` environment variable if the cmake executable is named other
       than ``cmake`` on your system.  Additional environment variables may be
-      provided on the command line for use by cmake.  For example, to use the
-      ``cmake3`` executable and tell it to use the gnu version 11 compilers
-      to build KIM, one could use the following command line.
+      set with the ``make`` command for use by cmake.  For example, to use the
+      ``cmake3`` executable and tell it to use the GNU version 11 compilers
+      called ``g++-11``, ``gcc-11`` and ``gfortran-11`` to build KIM, one
+      could use the following command.
 
       .. code-block:: bash
 
@@ -544,16 +548,7 @@ They must be specified in uppercase.
       - Local machine
    *  - AMDAVX
       - HOST
-      - AMD 64-bit x86 CPU (AVX 1)
-   *  - ZEN
-      - HOST
-      - AMD Zen class CPU (AVX 2)
-   *  - ZEN2
-      - HOST
-      - AMD Zen2 class CPU (AVX 2)
-   *  - ZEN3
-      - HOST
-      - AMD Zen3 class CPU (AVX 2)
+      - AMD chip
    *  - ARMV80
       - HOST
       - ARMv8.0 Compatible CPU
@@ -569,105 +564,126 @@ They must be specified in uppercase.
    *  - A64FX
       - HOST
       - ARMv8.2 with SVE Support
+   *  - ARMV9_GRACE
+      - HOST
+      - ARMv9 NVIDIA Grace CPU
    *  - SNB
       - HOST
-      - Intel Sandy/Ivy Bridge CPU (AVX 1)
+      - Intel Sandy/Ivy Bridge CPUs
    *  - HSW
       - HOST
-      - Intel Haswell CPU (AVX 2)
+      - Intel Haswell CPUs
    *  - BDW
       - HOST
-      - Intel Broadwell Xeon E-class CPU (AVX 2 + transactional mem)
-   *  - SKL
-      - HOST
-      - Intel Skylake Client CPU
-   *  - SKX
-      - HOST
-      - Intel Skylake Xeon Server CPU (AVX512)
+      - Intel Broadwell Xeon E-class CPUs
    *  - ICL
       - HOST
-      - Intel Ice Lake Client CPU (AVX512)
+      - Intel Ice Lake Client CPUs (AVX512)
    *  - ICX
       - HOST
-      - Intel Ice Lake Xeon Server CPU (AVX512)
-   *  - SPR
+      - Intel Ice Lake Xeon Server CPUs (AVX512)
+   *  - SKL
       - HOST
-      - Intel Sapphire Rapids Xeon Server CPU (AVX512)
+      - Intel Skylake Client CPUs
+   *  - SKX
+      - HOST
+      - Intel Skylake Xeon Server CPUs (AVX512)
    *  - KNC
       - HOST
       - Intel Knights Corner Xeon Phi
    *  - KNL
       - HOST
       - Intel Knights Landing Xeon Phi
+   *  - SPR
+      - HOST
+      - Intel Sapphire Rapids Xeon Server CPUs (AVX512)
    *  - POWER8
       - HOST
-      - IBM POWER8 CPU
+      - IBM POWER8 CPUs
    *  - POWER9
       - HOST
-      - IBM POWER9 CPU
+      - IBM POWER9 CPUs
+   *  - ZEN
+      - HOST
+      - AMD Zen architecture
+   *  - ZEN2
+      - HOST
+      - AMD Zen2 architecture
+   *  - ZEN3
+      - HOST
+      - AMD Zen3 architecture
    *  - RISCV_SG2042
       - HOST
-      - SG2042 (RISC-V) CPU
+      - SG2042 (RISC-V) CPUs
+   *  - RISCV_RVA22V
+      - HOST
+      - RVA22V (RISC-V) CPUs
    *  - KEPLER30
       - GPU
-      - NVIDIA Kepler generation CC 3.0 GPU
+      - NVIDIA Kepler generation CC 3.0
    *  - KEPLER32
       - GPU
-      - NVIDIA Kepler generation CC 3.2 GPU
+      - NVIDIA Kepler generation CC 3.2
    *  - KEPLER35
       - GPU
-      - NVIDIA Kepler generation CC 3.5 GPU
+      - NVIDIA Kepler generation CC 3.5
    *  - KEPLER37
       - GPU
-      - NVIDIA Kepler generation CC 3.7 GPU
+      - NVIDIA Kepler generation CC 3.7
    *  - MAXWELL50
       - GPU
-      - NVIDIA Maxwell generation CC 5.0 GPU
+      - NVIDIA Maxwell generation CC 5.0
    *  - MAXWELL52
       - GPU
-      - NVIDIA Maxwell generation CC 5.2 GPU
+      - NVIDIA Maxwell generation CC 5.2
    *  - MAXWELL53
       - GPU
-      - NVIDIA Maxwell generation CC 5.3 GPU
+      - NVIDIA Maxwell generation CC 5.3
    *  - PASCAL60
       - GPU
-      - NVIDIA Pascal generation CC 6.0 GPU
+      - NVIDIA Pascal generation CC 6.0
    *  - PASCAL61
       - GPU
-      - NVIDIA Pascal generation CC 6.1 GPU
+      - NVIDIA Pascal generation CC 6.1
    *  - VOLTA70
       - GPU
-      - NVIDIA Volta generation CC 7.0 GPU
+      - NVIDIA Volta generation CC 7.0
    *  - VOLTA72
       - GPU
-      - NVIDIA Volta generation CC 7.2 GPU
+      - NVIDIA Volta generation CC 7.2
    *  - TURING75
       - GPU
-      - NVIDIA Turing generation CC 7.5 GPU
+      - NVIDIA Turing generation CC 7.5
    *  - AMPERE80
       - GPU
-      - NVIDIA Ampere generation CC 8.0 GPU
+      - NVIDIA Ampere generation CC 8.0
    *  - AMPERE86
       - GPU
-      - NVIDIA Ampere generation CC 8.6 GPU
+      - NVIDIA Ampere generation CC 8.6
    *  - ADA89
       - GPU
-      - NVIDIA Ada Lovelace generation CC 8.9 GPU
+      - NVIDIA Ada generation CC 8.9
    *  - HOPPER90
       - GPU
-      - NVIDIA Hopper generation CC 9.0 GPU
+      - NVIDIA Hopper generation CC 9.0
    *  - AMD_GFX906
       - GPU
-      - AMD GPU MI50/MI60
+      - AMD GPU MI50/60
    *  - AMD_GFX908
       - GPU
       - AMD GPU MI100
    *  - AMD_GFX90A
       - GPU
       - AMD GPU MI200
+   *  - AMD_GFX940
+      - GPU
+      - AMD GPU MI300
    *  - AMD_GFX942
       - GPU
       - AMD GPU MI300
+   *  - AMD_GFX942_APU
+      - GPU
+      - AMD APU MI300A
    *  - AMD_GFX1030
       - GPU
       - AMD GPU V620/W6800
@@ -676,7 +692,7 @@ They must be specified in uppercase.
       - AMD GPU RX7900XTX
    *  - AMD_GFX1103
       - GPU
-      - AMD Phoenix APU with Radeon 740M/760M/780M/880M/890M
+      - AMD APU Phoenix
    *  - INTEL_GEN
       - GPU
       - SPIR64-based devices, e.g. Intel GPUs, using JIT
@@ -699,7 +715,7 @@ They must be specified in uppercase.
       - GPU
       - Intel GPU Ponte Vecchio
 
-This list was last updated for version 4.3.0 of the Kokkos library.
+This list was last updated for version 4.5.1 of the Kokkos library.
 
 .. tabs::
 
@@ -751,14 +767,27 @@ This list was last updated for version 4.3.0 of the Kokkos library.
       platform-appropriate vendor library: rocFFT on AMD GPUs or cuFFT on
       NVIDIA GPUs.
 
-      To simplify compilation, five preset files are included in the
+      For Intel GPUs using SYCL, set these variables:
+
+      .. code-block:: bash
+
+         -D Kokkos_ARCH_HOSTARCH=yes   # HOSTARCH = HOST from list above
+         -D Kokkos_ARCH_GPUARCH=yes    # GPUARCH = GPU from list above
+         -D Kokkos_ENABLE_SYCL=yes
+         -D Kokkos_ENABLE_OPENMP=yes
+         -D FFT_KOKKOS=MKL_GPU
+
+      This will enable FFTs on the GPU using the oneMKL library.
+
+      To simplify compilation, six preset files are included in the
       ``cmake/presets`` folder, ``kokkos-serial.cmake``,
       ``kokkos-openmp.cmake``, ``kokkos-cuda.cmake``,
-      ``kokkos-hip.cmake``, and ``kokkos-sycl.cmake``.  They will enable
-      the KOKKOS package and enable some hardware choices.  For GPU
-      support those preset files must be customized to match the
-      hardware used. So to compile with CUDA device parallelization with
-      some common packages enabled, you can do the following:
+      ``kokkos-hip.cmake``, ``kokkos-sycl-nvidia.cmake``, and
+      ``kokkos-sycl-intel.cmake``.  They will enable the KOKKOS
+      package and enable some hardware choices.  For GPU support those
+      preset files must be customized to match the hardware used. So
+      to compile with CUDA device parallelization with some common
+      packages enabled, you can do the following:
 
       .. code-block:: bash
 
@@ -830,6 +859,18 @@ This list was last updated for version 4.3.0 of the Kokkos library.
          FFT_INC = -DFFT_HIPFFT          # enable use of hipFFT (optional)
          FFT_LIB = -lhipfft              # link to hipFFT library
 
+      For Intel GPUs using SYCL:
+
+      .. code-block:: make
+
+         KOKKOS_DEVICES = SYCL
+         KOKKOS_ARCH = HOSTARCH,GPUARCH  # HOSTARCH = HOST from list above that is
+                                         #            hosting the GPU
+                                         # GPUARCH = GPU from list above
+         FFT_INC = -DFFT_KOKKOS_MKL_GPU  # enable use of oneMKL for Intel GPUs (optional)
+                                         # link to oneMKL FFT library
+         FFT_LIB = -lmkl_sycl_dft -lmkl_intel_ilp64 -lmkl_tbb_thread -mkl_core -ltbb
+
 Advanced KOKKOS compilation settings
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -1991,7 +2032,7 @@ TBB and MKL.
 .. _mdi:
 
 MDI package
------------------------------
+-----------
 
 .. tabs::
 
@@ -2018,6 +2059,37 @@ MDI package
 
 ----------
 
+.. _misc:
+
+MISC package
+------------
+
+The :doc:`fix imd <fix_imd>` style in this package can be run either
+synchronously (communication with IMD clients is done in the main
+process) or asynchronously (the fix spawns a separate thread that can
+communicate with IMD clients concurrently to the LAMMPS execution).
+
+.. tabs::
+
+   .. tab:: CMake build
+
+      .. code-block:: bash
+
+         -D LAMMPS_ASYNC_IMD=value  # Run IMD server asynchronously
+                                    # value = no (default) or yes
+
+   .. tab:: Traditional make
+
+      To enable asynchronous mode the ``-DLAMMPS_ASYNC_IMD`` define
+      needs to be added to the ``LMP_INC`` variable in the
+      ``Makefile.machine`` you are using.  For example:
+
+      .. code-block:: make
+
+         LMP_INC = -DLAMMPS_ASYNC_IMD -DLAMMPS_MEMALIGN=64
+
+----------
+
 .. _molfile:
 
 MOLFILE package
@@ -2164,7 +2236,7 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to
       from the sources in the *lib* folder (including the essential
       libqmmm.a) are not included in the static LAMMPS library and
       (currently) not installed, while their code is included in the
-      shared LAMMPS library.  Thus a typical command line to configure
+      shared LAMMPS library.  Thus a typical command to configure
       building LAMMPS for QMMM would be:
 
       .. code-block:: bash
@@ -2224,28 +2296,38 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to
 RHEO package
 ------------
 
-To build with this package you must have the `GNU Scientific Library
-(GSL) <https://www.gnu.org/software/gsl/>` installed in locations that
-are accessible in your environment.  The GSL library should be at least
-version 2.7.
+This package depends on the BPM package.
 
 .. tabs::
 
    .. tab:: CMake build
 
-      If CMake cannot find the GSL library or include files, you can set:
-
       .. code-block:: bash
 
-         -D GSL_ROOT_DIR=path    # path to root of GSL installation
+         -D PKG_RHEO=yes               # enable the package itself
+         -D PKG_BPM=yes                # the RHEO package requires BPM
+         -D USE_INTERNAL_LINALG=value  # prefer internal LAPACK if true
+
+      Some features in the RHEO package are dependent on code in the BPM
+      package so the latter one *must* be enabled as well.
+
+      The RHEO package also requires LAPACK (and BLAS) and CMake
+      can identify their locations and pass that info to the RHEO
+      build script.  But on some systems this may cause problems when
+      linking or the dependency is not desired.  By using the setting
+      ``-D USE_INTERNAL_LINALG=yes`` when running the CMake
+      configuration, you will select compiling and linking the bundled
+      linear algebra library and work around the limitations.
 
    .. tab:: Traditional make
 
-      LAMMPS will try to auto-detect the GSL compiler and linker flags
-      from the corresponding ``pkg-config`` file (``gsl.pc``), otherwise
-      you can edit the file ``lib/rheo/Makefile.lammps``
-      to specify the paths and library names where indicated by comments.
-      This must be done **before** the package is installed.
+      The RHEO package requires LAPACK (and BLAS) which can be either
+      a system provided library or the bundled "linalg" library. This
+      is a subset of LAPACK translated to C++.  For that, one of the
+      provided ``Makefile.lammps.<config>`` files needs to be copied
+      to ``Makefile.lammps`` and edited as needed.  The default file
+      uses the bundled "linalg" library, which can be built by
+      ``make lib-linalg args='-m serial'`` in the ``src`` folder.
 
 ----------
 

doc/src/Build_make.rst

@@ -8,6 +8,10 @@ Building LAMMPS with traditional makefiles requires that you have a
 for customizing your LAMMPS build with a number of global compilation
 options and features.
 
+This build system is slowly being phased out and may not support all
+optional features and packages in LAMMPS.  It is recommended to switch
+to the :doc:`CMake based build system <Build_cmake>`.
+
 Requirements
 ^^^^^^^^^^^^
 

doc/src/Build_package.rst

@@ -49,6 +49,7 @@ packages:
    * :ref:`LEPTON <lepton>`
    * :ref:`MACHDYN <machdyn>`
    * :ref:`MDI <mdi>`
+   * :ref:`MISC <misc>`
    * :ref:`ML-HDNNP <ml-hdnnp>`
    * :ref:`ML-IAP <mliap>`
    * :ref:`ML-PACE <ml-pace>`

doc/src/Build_settings.rst

@@ -67,10 +67,10 @@ libraries and better pipelining for packing and communication.
 
       .. code-block:: bash
 
-         -D FFT=value              # FFTW3 or MKL or KISS, default is FFTW3 if found,
-                                   # else KISS
-         -D FFT_KOKKOS=value       # FFTW3 or MKL or KISS or CUFFT or HIPFFT,
-                                   # default is KISS
+         -D FFT=value              # FFTW3 or MKL or NVPL or KISS,
+                                   # default is FFTW3 if found, else KISS
+         -D FFT_KOKKOS=value       # FFTW3 or MKL or NVPL or KISS or CUFFT
+                                   # or HIPFFT or MKL_GPU, default is KISS
          -D FFT_SINGLE=value       # yes or no (default), no = double precision
          -D FFT_PACK=value         # array (default) or pointer or memcpy
          -D FFT_USE_HEFFTE=value   # yes or no (default), yes links to heFFTe
@@ -103,6 +103,8 @@ libraries and better pipelining for packing and communication.
          -D FFT_HEFFTE_BACKEND=value # FFTW or MKL or empty/undefined for the stock
                                      # heFFTe back end
          -D Heffte_ROOT=path         # path to an existing heFFTe installation
+         -D nvpl_fft_INCLUDE_DIR=path # path to NVPL FFT include files
+         -D nvpl_fft_LIBRARY_DIR=path # path to NVPL FFT libraries
 
       .. note::
 
@@ -121,9 +123,10 @@ libraries and better pipelining for packing and communication.
       .. code-block:: make
 
          FFT_INC = -DFFT_<NAME>        # where <NAME> is KISS (default), FFTW3,
-                                       # FFTW (same as FFTW3), or MKL
+                                       # FFTW (same as FFTW3), NVPL, or MKL
          FFT_INC = -DFFT_KOKKOS_<NAME> # where <NAME> is KISS (default), FFTW3,
-                                       # FFTW (same as FFTW3), MKL, CUFFT, or HIPFFT
+                                       # FFTW (same as FFTW3), NVPL, MKL, CUFFT,
+                                       # HIPFFT, or MKL_GPU
          FFT_INC = -DFFT_SINGLE       # do not specify for double precision
          FFT_INC = -DFFT_FFTW_THREADS # enable using threaded FFTW3 libraries
          FFT_INC = -DFFT_MKL_THREADS  # enable using threaded FFTs with MKL libraries
@@ -141,6 +144,9 @@ libraries and better pipelining for packing and communication.
          # cuFFT either precision
          FFT_LIB =  -lcufft
 
+         # MKL_GPU either precision
+         FFT_LIB = -lmkl_sycl_dft -lmkl_intel_ilp64 -lmkl_tbb_thread -lmkl_core -ltbb
+
          # FFTW3 double precision
          FFT_LIB =  -lfftw3
 
@@ -165,6 +171,10 @@ libraries and better pipelining for packing and communication.
          # MKL with automatic runtime selection of interface libs
          FFT_LIB =  -lmkl_rt
 
+         # threaded NVPL FFT
+         FFT_LIB =  -lnvpl_fftw
+
+
       As with CMake, you do not need to set paths in ``FFT_INC`` or
       ``FFT_PATH``, if the compiler can find the FFT header and library
       files in its default search path.  You must specify ``FFT_LIB``
@@ -218,10 +228,15 @@ The Intel MKL math library is part of the Intel compiler suite.  It
 can be used with the Intel or GNU compiler (see the ``FFT_LIB`` setting
 above).
 
+The NVIDIA Performance Libraries (NVPL) FFT library is optimized for NVIDIA
+Grace Armv9.0 architecture. You can download it from https://docs.nvidia.com/nvpl/
+
 The cuFFT and hipFFT FFT libraries are packaged with NVIDIA's CUDA and
 AMD's HIP installations, respectively. These FFT libraries require the
 Kokkos acceleration package to be enabled and the Kokkos back end to be
-GPU-resident (i.e., HIP or CUDA).
+GPU-resident (i.e., HIP or CUDA). Similarly, GPU offload of FFTs on
+Intel GPUs with oneMKL currently requires the Kokkos acceleration
+package to be enabled with the SYCL back end.
 
 Performing 3d FFTs in parallel can be time-consuming due to data access
 and required communication.  This cost can be reduced by performing

doc/src/Build_windows.rst

@@ -100,9 +100,9 @@ procedure.
 
 It is possible to use both the integrated CMake support of the Visual
 Studio IDE or use an external CMake installation (e.g. downloaded from
-cmake.org) to create build files and compile LAMMPS from the command line.
+cmake.org) to create build files and compile LAMMPS from the command-line.
 
-Compilation via command line and unit tests are checked automatically
+Compilation via command-line and unit tests are checked automatically
 for the LAMMPS development branch through
 `GitHub Actions <https://github.com/lammps/lammps/actions/workflows/compile-msvc.yml>`_.
 
@@ -115,7 +115,7 @@ for the LAMMPS development branch through
 
 Please note, that for either approach CMake will create a so-called
 :ref:`"multi-configuration" build environment <cmake_multiconfig>`, and
-the command lines for building and testing LAMMPS must be adjusted
+the commands for building and testing LAMMPS must be adjusted
 accordingly.
 
 The LAMMPS cmake folder contains a ``CMakeSettings.json`` file with

doc/src/Classes_lammps.rst

@@ -4,7 +4,7 @@ LAMMPS Class
 The LAMMPS class is encapsulating an MD simulation state and thus it is
 the class that needs to be created when starting a new simulation system
 state.  The LAMMPS executable essentially creates one instance of this
-class and passes the command line flags and tells it to process the
+class and passes the command-line flags and tells it to process the
 provided input (a file or ``stdin``).  It shuts the class down when
 control is returned to it and then exits.  When using LAMMPS as a
 library from another code it is required to create an instance of this

doc/src/Commands_bond.rst

@@ -90,6 +90,7 @@ OPT.
    * :doc:`lepton (o) <angle_lepton>`
    * :doc:`mesocnt <angle_mesocnt>`
    * :doc:`mm3 <angle_mm3>`
+   * :doc:`mwlc <angle_mwlc>`
    * :doc:`quartic (o) <angle_quartic>`
    * :doc:`spica (ko) <angle_spica>`
    * :doc:`table (o) <angle_table>`

doc/src/Commands_fix.rst

@@ -43,7 +43,7 @@ OPT.
    * :doc:`brownian/asphere <fix_brownian>`
    * :doc:`brownian/sphere <fix_brownian>`
    * :doc:`charge/regulation <fix_charge_regulation>`
-   * :doc:`cmap <fix_cmap>`
+   * :doc:`cmap (k) <fix_cmap>`
    * :doc:`colvars <fix_colvars>`
    * :doc:`controller <fix_controller>`
    * :doc:`damping/cundall <fix_damping_cundall>`
@@ -58,6 +58,7 @@ OPT.
    * :doc:`dt/reset (k) <fix_dt_reset>`
    * :doc:`edpd/source <fix_dpd_source>`
    * :doc:`efield (k) <fix_efield>`
+   * :doc:`efield/lepton <fix_efield_lepton>`
    * :doc:`efield/tip4p <fix_efield>`
    * :doc:`ehex <fix_ehex>`
    * :doc:`electrode/conp (i) <fix_electrode>`
@@ -134,7 +135,7 @@ OPT.
    * :doc:`nve/dot <fix_nve_dot>`
    * :doc:`nve/dotc/langevin <fix_nve_dotc_langevin>`
    * :doc:`nve/eff <fix_nve_eff>`
-   * :doc:`nve/limit <fix_nve_limit>`
+   * :doc:`nve/limit (k) <fix_nve_limit>`
    * :doc:`nve/line <fix_nve_line>`
    * :doc:`nve/manifold/rattle <fix_nve_manifold_rattle>`
    * :doc:`nve/noforce <fix_nve_noforce>`
@@ -178,6 +179,7 @@ OPT.
    * :doc:`python/move <fix_python_move>`
    * :doc:`qbmsst <fix_qbmsst>`
    * :doc:`qeq/comb (o) <fix_qeq_comb>`
+   * :doc:`qeq/ctip <fix_qeq>`
    * :doc:`qeq/dynamic <fix_qeq>`
    * :doc:`qeq/fire <fix_qeq>`
    * :doc:`qeq/point <fix_qeq>`
@@ -186,10 +188,11 @@ OPT.
    * :doc:`qeq/slater <fix_qeq>`
    * :doc:`qmmm <fix_qmmm>`
    * :doc:`qtb <fix_qtb>`
+   * :doc:`qtpie/reaxff <fix_qtpie_reaxff>`
    * :doc:`rattle <fix_shake>`
    * :doc:`reaxff/bonds (k) <fix_reaxff_bonds>`
    * :doc:`reaxff/species (k) <fix_reaxff_species>`
-   * :doc:`recenter <fix_recenter>`
+   * :doc:`recenter (k) <fix_recenter>`
    * :doc:`restrain <fix_restrain>`
    * :doc:`rheo <fix_rheo>`
    * :doc:`rheo/oxidation <fix_rheo_oxidation>`
@@ -231,6 +234,8 @@ OPT.
    * :doc:`srd <fix_srd>`
    * :doc:`store/force <fix_store_force>`
    * :doc:`store/state <fix_store_state>`
+   * :doc:`surface/global <fix_surface_global>`
+   * :doc:`surface/local <fix_surface_local>`
    * :doc:`tdpd/source <fix_dpd_source>`
    * :doc:`temp/berendsen (k) <fix_temp_berendsen>`
    * :doc:`temp/csld <fix_temp_csvr>`
@@ -267,7 +272,7 @@ OPT.
    * :doc:`wall/piston <fix_wall_piston>`
    * :doc:`wall/reflect (k) <fix_wall_reflect>`
    * :doc:`wall/reflect/stochastic <fix_wall_reflect_stochastic>`
-   * :doc:`wall/region <fix_wall_region>`
+   * :doc:`wall/region (k) <fix_wall_region>`
    * :doc:`wall/region/ees <fix_wall_ees>`
    * :doc:`wall/srd <fix_wall_srd>`
    * :doc:`wall/table <fix_wall>`

doc/src/Commands_input.rst

@@ -69,7 +69,7 @@ WARNING message is printed.  The :doc:`Errors <Errors>` page gives
 more information on what errors mean.  The documentation for each
 command lists restrictions on how the command can be used.
 
-You can use the :ref:`-skiprun <skiprun>` command line flag
+You can use the :ref:`-skiprun <skiprun>` command-line flag
 to have LAMMPS skip the execution of any ``run``, ``minimize``, or similar
 commands to check the entire input for correct syntax to avoid crashes
 on typos or syntax errors in long runs.

doc/src/Commands_pair.rst

@@ -44,7 +44,7 @@ OPT.
    * :doc:`born/coul/wolf/cs (g) <pair_cs>`
    * :doc:`born/gauss <pair_born_gauss>`
    * :doc:`bpm/spring <pair_bpm_spring>`
-   * :doc:`brownian (o) <pair_brownian>`
+   * :doc:`brownian (ko) <pair_brownian>`
    * :doc:`brownian/poly (o) <pair_brownian>`
    * :doc:`buck (giko) <pair_buck>`
    * :doc:`buck/coul/cut (giko) <pair_buck>`
@@ -59,6 +59,7 @@ OPT.
    * :doc:`comb (o) <pair_comb>`
    * :doc:`comb3 <pair_comb>`
    * :doc:`cosine/squared <pair_cosine_squared>`
+   * :doc:`coul/ctip <pair_coul>`
    * :doc:`coul/cut (gko) <pair_coul>`
    * :doc:`coul/cut/dielectric <pair_dielectric>`
    * :doc:`coul/cut/global (o) <pair_coul>`
@@ -79,6 +80,7 @@ OPT.
    * :doc:`coul/tt <pair_coul_tt>`
    * :doc:`coul/wolf (ko) <pair_coul>`
    * :doc:`coul/wolf/cs <pair_cs>`
+   * :doc:`dispersion/d3 <pair_dispersion_d3>`
    * :doc:`dpd (giko) <pair_dpd>`
    * :doc:`dpd/coul/slater/long (g) <pair_dpd_coul_slater_long>`
    * :doc:`dpd/ext (ko) <pair_dpd_ext>`

doc/src/Commands_removed.rst

@@ -1,6 +1,10 @@
 Removed commands and packages
 =============================
 
+.. contents::
+
+------
+
 This page lists LAMMPS commands and packages that have been removed from
 the distribution and provides suggestions for alternatives or
 replacements.  LAMMPS has special dummy styles implemented, that will
@@ -8,47 +12,60 @@ stop LAMMPS and print a suitable error message in most cases, when a
 style/command is used that has been removed or will replace the command
 with the direct alternative (if available) and print a warning.
 
-restart2data tool
------------------
+LAMMPS shell
+------------
 
-.. versionchanged:: 23Nov2013
+.. versionchanged:: 29Aug2024
 
-The functionality of the restart2data tool has been folded into the
-LAMMPS executable directly instead of having a separate tool.  A
-combination of the commands :doc:`read_restart <read_restart>` and
-:doc:`write_data <write_data>` can be used to the same effect.  For
-added convenience this conversion can also be triggered by
-:doc:`command line flags <Run_options>`
+The LAMMPS shell has been removed from the LAMMPS distribution. Users
+are encouraged to use the :ref:`LAMMPS-GUI <lammps_gui>` tool instead.
 
-Fix ave/spatial and fix ave/spatial/sphere
-------------------------------------------
+i-PI tool
+---------
 
-.. deprecated:: 11Dec2015
+.. versionchanged:: 27Jun2024
 
-The fixes ave/spatial and ave/spatial/sphere have been removed from LAMMPS
-since they were superseded by the more general and extensible "chunk
-infrastructure".  Here the system is partitioned in one of many possible
-ways through the :doc:`compute chunk/atom <compute_chunk_atom>` command
-and then averaging is done using :doc:`fix ave/chunk <fix_ave_chunk>`.
-Please refer to the :doc:`chunk HOWTO <Howto_chunk>` section for an overview.
+The i-PI tool has been removed from the LAMMPS distribution.  Instead,
+instructions to install i-PI from PyPI via pip are provided.
 
-Box command
------------
+USER-REAXC package
+------------------
 
-.. deprecated:: 22Dec2022
+.. deprecated:: 7Feb2024
 
-The *box* command has been removed and the LAMMPS code changed so it won't
-be needed.  If present, LAMMPS will ignore the command and print a warning.
+The USER-REAXC package has been renamed to :ref:`REAXFF <PKG-REAXFF>`.
+In the process also the pair style and related fixes were renamed to use
+the "reaxff" string instead of "reax/c". For a while LAMMPS was maintaining
+backward compatibility by providing aliases for the styles.  These have
+been removed, so using "reaxff" is now *required*.
 
-Reset_ids, reset_atom_ids, reset_mol_ids commands
--------------------------------------------------
+MPIIO package
+-------------
 
-.. deprecated:: 22Dec2022
+.. deprecated:: 21Nov2023
 
-The *reset_ids*, *reset_atom_ids*, and *reset_mol_ids* commands have
-been folded into the :doc:`reset_atoms <reset_atoms>` command.  If
-present, LAMMPS will replace the commands accordingly and print a
-warning.
+The MPIIO package has been removed from LAMMPS since it was unmaintained
+for many years and thus not updated to incorporate required changes that
+had been applied to the corresponding non-MPIIO commands. As a
+consequence the MPIIO commands had become unreliable and sometimes
+crashing LAMMPS or corrupting data.  Similar functionality is available
+through the :ref:`ADIOS package <PKG-ADIOS>` and the :ref:`NETCDF
+package <PKG-NETCDF>`.  Also, the :doc:`dump_modify nfile or dump_modify
+fileper <dump_modify>` keywords may be used for an efficient way of
+writing out dump files when running on large numbers of processors.
+Similarly, the "nfile" and "fileper" keywords exist for restarts:
+see :doc:`restart <restart>`, :doc:`read_restart <read_restart>`,
+:doc:`write_restart <write_restart>`.
+
+MSCG package
+------------
+
+.. deprecated:: 21Nov2023
+
+The MSCG package has been removed from LAMMPS since it was unmaintained
+for many years and instead superseded by the `OpenMSCG software
+<https://software.rcc.uchicago.edu/mscg/>`_ of the Voth group at the
+University of Chicago, which can be used independent from LAMMPS.
 
 LATTE package
 -------------
@@ -64,18 +81,6 @@ packages, including LATTE.  See the ``examples/QUANTUM`` dir and the
 with LATTE as a plugin library (similar to the way fix latte worked), as
 well as on a different set of MPI processors.
 
-MEAM package
-------------
-
-The MEAM package in Fortran has been replaced by a C++ implementation.
-The code in the :ref:`MEAM package <PKG-MEAM>` is a translation of the
-Fortran code of MEAM into C++, which removes several restrictions
-(e.g. there can be multiple instances in hybrid pair styles) and allows
-for some optimizations leading to better performance.  The pair style
-:doc:`meam <pair_meam>` has the exact same syntax.  For a transition
-period the C++ version of MEAM was called USER-MEAMC so it could
-coexist with the Fortran version.
-
 Minimize style fire/old
 -----------------------
 
@@ -97,38 +102,38 @@ The same functionality is available through
 :doc:`bond style mesocnt <bond_mesocnt>` and
 :doc:`angle style mesocnt <angle_mesocnt>`.
 
-MPIIO package
--------------
+Box command
+-----------
 
-.. deprecated:: 21Nov2023
+.. deprecated:: 22Dec2022
 
-The MPIIO package has been removed from LAMMPS since it was unmaintained
-for many years and thus not updated to incorporate required changes that
-had been applied to the corresponding non-MPIIO commands. As a
-consequence the MPIIO commands had become unreliable and sometimes
-crashing LAMMPS or corrupting data.  Similar functionality is available
-through the :ref:`ADIOS package <PKG-ADIOS>` and the :ref:`NETCDF
-package <PKG-NETCDF>`.  Also, the :doc:`dump_modify nfile or dump_modify
-fileper <dump_modify>` keywords may be used for an efficient way of
-writing out dump files when running on large numbers of processors.
-Similarly, the "nfile" and "fileper" keywords exist for restarts:
-see :doc:`restart <restart>`, :doc:`read_restart <read_restart>`,
-:doc:`write_restart <write_restart>`.
+The *box* command has been removed and the LAMMPS code changed so it won't
+be needed.  If present, LAMMPS will ignore the command and print a warning.
 
+Reset_ids, reset_atom_ids, reset_mol_ids commands
+-------------------------------------------------
 
-MSCG package
-------------
+.. deprecated:: 22Dec2022
 
-.. deprecated:: 21Nov2023
+The *reset_ids*, *reset_atom_ids*, and *reset_mol_ids* commands have
+been folded into the :doc:`reset_atoms <reset_atoms>` command.  If
+present, LAMMPS will replace the commands accordingly and print a
+warning.
 
-The MSCG package has been removed from LAMMPS since it was unmaintained
-for many years and instead superseded by the `OpenMSCG software
-<https://software.rcc.uchicago.edu/mscg/>`_ of the Voth group at the
-University of Chicago, which can be used independent from LAMMPS.
+MESSAGE package
+---------------
+
+.. deprecated:: 4May2022
+
+The MESSAGE package has been removed since it was superseded by the
+:ref:`MDI package <PKG-MDI>`. MDI implements the same functionality
+and in a more general way with direct support for more applications.
 
 REAX package
 ------------
 
+.. deprecated:: 4Jan2019
+
 The REAX package has been removed since it was superseded by the
 :ref:`REAXFF package <PKG-REAXFF>`.  The REAXFF package has been tested
 to yield equivalent results to the REAX package, offers better
@@ -138,20 +143,25 @@ syntax compatible with the removed reax pair style, so input files will
 have to be adapted.  The REAXFF package was originally called
 USER-REAXC.
 
-USER-REAXC package
-------------------
+MEAM package
+------------
 
-.. deprecated:: 7Feb2024
+.. deprecated:: 4Jan2019
 
-The USER-REAXC package has been renamed to :ref:`REAXFF <PKG-REAXFF>`.
-In the process also the pair style and related fixes were renamed to use
-the "reaxff" string instead of "reax/c". For a while LAMMPS was maintaining
-backward compatibility by providing aliases for the styles.  These have
-been removed, so using "reaxff" is now *required*.
+The MEAM package in Fortran has been replaced by a C++ implementation.
+The code in the :ref:`MEAM package <PKG-MEAM>` is a translation of the
+Fortran code of MEAM into C++, which removes several restrictions
+(e.g. there can be multiple instances in hybrid pair styles) and allows
+for some optimizations leading to better performance.  The pair style
+:doc:`meam <pair_meam>` has the exact same syntax.  For a transition
+period the C++ version of MEAM was called USER-MEAMC so it could
+coexist with the Fortran version.
 
 USER-CUDA package
 -----------------
 
+.. deprecated:: 31May2016
+
 The USER-CUDA package had been removed, since it had been unmaintained
 for a long time and had known bugs and problems.  Significant parts of
 the design were transferred to the
@@ -160,19 +170,27 @@ performance characteristics on NVIDIA GPUs. Both, the KOKKOS
 and the :ref:`GPU package <PKG-GPU>` are maintained
 and allow running LAMMPS with GPU acceleration.
 
-i-PI tool
----------
+Fix ave/spatial and fix ave/spatial/sphere
+------------------------------------------
 
-.. versionchanged:: 27Jun2024
+.. deprecated:: 11Dec2015
 
-The i-PI tool has been removed from the LAMMPS distribution.  Instead,
-instructions to install i-PI from PyPI via pip are provided.
+The fixes ave/spatial and ave/spatial/sphere have been removed from LAMMPS
+since they were superseded by the more general and extensible "chunk
+infrastructure".  Here the system is partitioned in one of many possible
+ways through the :doc:`compute chunk/atom <compute_chunk_atom>` command
+and then averaging is done using :doc:`fix ave/chunk <fix_ave_chunk>`.
+Please refer to the :doc:`chunk HOWTO <Howto_chunk>` section for an overview.
 
-LAMMPS shell
-------------
+restart2data tool
+-----------------
 
-.. versionchanged:: 29Aug2024
+.. deprecated:: 23Nov2013
 
-The LAMMPS shell has been removed from the LAMMPS distribution. Users
-are encouraged to use the :ref:`LAMMPS-GUI <lammps_gui>` tool instead.
+The functionality of the restart2data tool has been folded into the
+LAMMPS executable directly instead of having a separate tool.  A
+combination of the commands :doc:`read_restart <read_restart>` and
+:doc:`write_data <write_data>` can be used to the same effect.  For
+added convenience this conversion can also be triggered by
+:doc:`command-line flags <Run_options>`
 

doc/src/Developer_comm_ops.rst

@@ -79,19 +79,19 @@ containing ``double`` values.  To correctly store integers that may be
 64-bit (bigint, tagint, imageint) in the buffer, you need to use the
 :ref:`ubuf union <communication_buffer_coding_with_ubuf>` construct.
 
-The *Fix*, *Compute*, and *Dump* classes can also invoke the same kind
-of forward and reverse communication operations using the same *Comm*
-class methods.  Likewise, the same pack/unpack methods and
+The *Fix*, *Bond*, *Compute*, and *Dump* classes can also invoke the
+same kind of forward and reverse communication operations using the
+same *Comm* class methods.  Likewise, the same pack/unpack methods and
 comm_forward/comm_reverse variables must be defined by the calling
-*Fix*, *Compute*, or *Dump* class.
+*Fix*, *Bond*, *Compute*, or *Dump* class.
 
-For *Fix* classes, there is an optional second argument to the
+For all of these classes, there is an optional second argument to the
 *forward_comm()* and *reverse_comm()* call which can be used when the
-fix performs multiple modes of communication, with different numbers
-of values per atom.  The fix should set the *comm_forward* and
+class performs multiple modes of communication, with different numbers
+of values per atom.  The class should set the *comm_forward* and
 *comm_reverse* variables to the maximum value, but can invoke the
 communication for a particular mode with a smaller value.  For this
-to work, the *pack_forward_comm()*, etc methods typically use a class
+to work, the *pack_forward_comm()*, etc. methods typically use a class
 member variable to choose which values to pack/unpack into/from the
 buffer.
 

doc/src/Developer_org.rst

@@ -94,12 +94,12 @@ represents what is generally referred to as an "instance of LAMMPS".  It
 is a composite holding pointers to instances of other core classes
 providing the core functionality of the MD engine in LAMMPS and through
 them abstractions of the required operations.  The constructor of the
-LAMMPS class will instantiate those instances, process the command line
+LAMMPS class will instantiate those instances, process the command-line
 flags, initialize MPI (if not already done) and set up file pointers for
 input and output.  The destructor will shut everything down and free all
 associated memory.  Thus code for the standalone LAMMPS executable in
 ``main.cpp`` simply initializes MPI, instantiates a single instance of
-LAMMPS while passing it the command line flags and input script. It
+LAMMPS while passing it the command-line flags and input script. It
 deletes the LAMMPS instance after the method reading the input returns
 and shuts down the MPI environment before it exits the executable.
 

doc/src/Developer_unittest.rst

@@ -227,12 +227,12 @@ Tests for the C-style library interface
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Tests for validating the LAMMPS C-style library interface are in the
-``unittest/c-library`` folder.  They are implemented either to be used
-for utility functions or for LAMMPS commands, but use the functions
-implemented in the ``src/library.cpp`` file as much as possible.  There
-may be some overlap with other tests, but only in as much as is required
-to test the C-style library API.  The tests are distributed over
-multiple test programs which try to match the grouping of the
+``unittest/c-library`` folder.  They text either utility functions or
+LAMMPS commands, but use the functions implemented in
+``src/library.cpp`` as much as possible.  There may be some overlap with
+other tests as far as the LAMMPS functionality is concerned, but the
+focus is on testing the C-style library API.  The tests are distributed
+over multiple test programs which try to match the grouping of the
 functions in the source code and :ref:`in the manual <lammps_c_api>`.
 
 This group of tests also includes tests invoking LAMMPS in parallel
@@ -258,7 +258,7 @@ Tests for the Python module and package
 
 The ``unittest/python`` folder contains primarily tests for classes and
 functions in the LAMMPS python module but also for commands in the
-PYTHON package.  These tests are only enabled if the necessary
+PYTHON package.  These tests are only enabled, if the necessary
 prerequisites are detected or enabled during configuration and
 compilation of LAMMPS (shared library build enabled, Python interpreter
 found, Python development files found).
@@ -272,29 +272,30 @@ Tests for the Fortran interface
 
 Tests for using the Fortran module are in the ``unittest/fortran``
 folder.  Since they are also using the GoogleTest library, they require
-implementing test wrappers in C++ that will call fortran functions
-which provide a C function interface through ISO_C_BINDINGS that will in
-turn call the functions in the LAMMPS Fortran module.
+test wrappers written in C++ that will call fortran functions with a C
+function interface through ISO_C_BINDINGS which will in turn call the
+functions in the LAMMPS Fortran module.
 
 Tests for the C++-style library interface
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The tests in the ``unittest/cplusplus`` folder are somewhat similar to
 the tests for the C-style library interface, but do not need to test the
-several convenience and utility functions that are only available through
-the C-style interface.  Instead it can focus on the more generic features
-that are used internally.  This part of the unit tests is currently still
-mostly in the planning stage.
+convenience and utility functions that are only available through the
+C-style library interface.  Instead they focus on the more generic
+features that are used in LAMMPS internally.  This part of the unit
+tests is currently still mostly in the planning stage.
 
 Tests for reading and writing file formats
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The ``unittest/formats`` folder contains test programs for reading and
-writing files like data files, restart files, potential files or dump files.
-This covers simple things like the file i/o convenience functions in the
-``utils::`` namespace to complex tests of atom styles where creating and
-deleting atoms with different properties is tested in different ways
-and through script commands or reading and writing of data or restart files.
+writing files like data files, restart files, potential files or dump
+files.  This covers simple things like the file i/o convenience
+functions in the ``utils::`` namespace to complex tests of atom styles
+where creating and deleting of atoms with different properties is tested
+in different ways and through script commands or reading and writing of
+data or restart files.
 
 Tests for styles computing or modifying forces
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -443,7 +444,7 @@ file for a style that is similar to one to be tested.  The file name should
 follow the naming conventions described above and after copying the file,
 the first step is to replace the style names where needed.  The coefficient
 values do not have to be meaningful, just in a reasonable range for the
-given system.  It does not matter if some forces are large, as long as
+given system.  It does not matter if some forces are large, for as long as
 they do not diverge.
 
 The template input files define a large number of index variables at the top
@@ -476,7 +477,7 @@ the tabulated coulomb, to test both code paths.  The reference results in the YA
 files then should be compared manually, if they agree well enough within the limits
 of those two approximations.
 
-The ``test_pair_style`` and equivalent programs have special command line options
+The ``test_pair_style`` and equivalent programs have special command-line options
 to update the YAML files. Running a command like
 
 .. code-block:: bash
@@ -531,19 +532,20 @@ Python module.
 Troubleshooting failed unit tests
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The are by default no unit tests for newly added features (e.g. pair, fix,
-or compute styles) unless your pull request also includes tests for the
-added features.  If you are modifying some features, you may see failures
-for existing tests, if your modifications have some unexpected side effects
-or your changes render the existing test invalid.  If you are adding an
-accelerated version of an existing style, then only tests for INTEL,
-KOKKOS (with OpenMP only), OPENMP, and OPT will be run automatically.
-Tests for the GPU package are time consuming and thus are only run
-*after* a merge, or when a special label, ``gpu_unit_tests`` is added
-to the pull request.  After the test has started, it is often best to
-remove the label since every PR activity will re-trigger the test (that
-is a limitation of triggering a test with a label).  Support for unit
-tests when using KOKKOS with GPU acceleration is currently not supported.
+There are by default no unit tests for newly added features (e.g. pair,
+fix, or compute styles) unless your pull request also includes tests for
+these added features.  If you are modifying some existing LAMMPS
+features, you may see failures for existing tests, if your modifications
+have some unexpected side effects or your changes render the existing
+test invalid.  If you are adding an accelerated version of an existing
+style, then only tests for INTEL, KOKKOS (with OpenMP only), OPENMP, and
+OPT will be run automatically.  Tests for the GPU package are time
+consuming and thus are only run *after* a merge, or when a special
+label, ``gpu_unit_tests`` is added to the pull request.  After the test
+has started, it is often best to remove the label since every PR
+activity will re-trigger the test (that is a limitation of triggering a
+test with a label).  Support for unit tests using KOKKOS with GPU
+acceleration is currently not supported.
 
 When you see a failed build on GitHub, click on ``Details`` to be taken
 to the corresponding LAMMPS Jenkins CI web page.  Click on the "Exit"
@@ -588,7 +590,7 @@ While the epsilon (relative precision) for a single, `IEEE 754 compliant
 <https://en.wikipedia.org/wiki/IEEE_754>`_, double precision floating
 point operation is at about 2.2e-16, the achievable precision for the
 tests is lower due to most numbers being sums over intermediate results
-and the non-associativity of floating point math leading to larger
+for which the non-associativity of floating point math leads to larger
 errors.  As a rule of thumb, the test epsilon can often be in the range
 5.0e-14 to 1.0e-13.  But for "noisy" force kernels, e.g. those a larger
 amount of arithmetic operations involving `exp()`, `log()` or `sin()`
@@ -602,14 +604,14 @@ of floating point operations or that some or most intermediate operations
 may be done using approximations or with single precision floating point
 math.
 
-To rerun the failed unit test individually, change to the ``build`` directory
+To rerun a failed unit test individually, change to the ``build`` directory
 and run the test with verbose output. For example,
 
 .. code-block:: bash
 
     env TEST_ARGS=-v ctest -R ^MolPairStyle:lj_cut_coul_long -V
 
-``ctest`` with the ``-V`` flag also shows the exact command line
+``ctest`` with the ``-V`` flag also shows the exact command
 of the test. One can then use ``gdb --args`` to further debug and
 catch exceptions with the test command, for example,
 

doc/src/Developer_write.rst

@@ -12,3 +12,4 @@ details are provided for writing code for LAMMPS.
 
    Developer_write_pair
    Developer_write_fix
+   Developer_write_command

doc/src/Developer_write_command.rst

@@ -0,0 +1,348 @@
+Writing a new command style
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Command styles allow to do system manipulations or interfaces to the
+operating system.
+
+In the text below, we will discuss the implementation of one example.  As
+shown on the page for :doc:`writing or extending command styles
+<Modify_command>`, in order to implement a new command style, a new class
+must be written that is either directly or indirectly derived from the
+``Command`` class.  There is just one method that must be implemented:
+``Command::command()``.  In addition, a custom constructor is needed to get
+access to the members of the ``LAMMPS`` class like the ``Error`` class to
+print out error messages.  The ``Command::command()`` method processes the
+arguments passed to the command in the input and executes it.  Any other
+methods would be for the convenience of implementation of the new command.
+
+In general, new command styles should be added to the :ref:`EXTRA-COMMAND
+package <PKG-EXTRA-COMMAND>`.  If you feel that your contribution should be
+added to a different package, please consult with the :doc:`LAMMPS
+developers <Intro_authors>` first.  The contributed code needs to support
+the :doc:`traditional GNU make build process <Build_make>` **and** the
+:doc:`CMake build process <Build_cmake>`.
+
+----
+
+Case 1: Implementing the geturl command
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In this section, we will describe the procedure of adding a simple command
+style to LAMMPS: the :doc:`geturl command <geturl>` that allows to download
+files directly without having to rely on an external program like "wget" or
+"curl".  The complete implementation can be found in the files
+``src/EXTRA-COMMAND/geturl.cpp`` and ``src/EXTRA-COMMAND/geturl.h`` of the
+LAMMPS source code.
+
+Interfacing the *libcurl* library
+"""""""""""""""""""""""""""""""""
+
+Rather than implementing the various protocols for downloading files, we
+rely on an external library: `libcurl library <https:://curl.se/libcurl/>`_.
+This requires that the library and its headers are installed.  For the
+traditional GNU make build system, this simply requires edits to the machine
+makefile to add compilation flags like for other libraries.  For the CMake
+based build system, we need to add some lines to the file
+``cmake/Modules/Packages/EXTRA-COMMAND.cmake``:
+
+.. code-block:: cmake
+
+   find_package(CURL QUIET COMPONENTS HTTP HTTPS)
+   option(WITH_CURL "Enable libcurl support" ${CURL_FOUND})
+   if(WITH_CURL)
+     find_package(CURL REQUIRED COMPONENTS HTTP HTTPS)
+     target_compile_definitions(lammps PRIVATE -DLAMMPS_CURL)
+     target_link_libraries(lammps PRIVATE CURL::libcurl)
+   endif()
+
+The first ``find_package()`` command uses a built-in CMake module to find
+an existing *libcurl* installation with development headers and support for
+using the HTTP and HTTPS protocols.  The "QUIET" flag ensures that there is
+no screen output and no error if the search fails.  The status of the search
+is recorded in the "${CURL_FOUND}" variable.  That variable sets the default
+of the WITH_CURL option, which toggles whether support for *libcurl* is included
+or not.
+
+The second ``find_package()`` uses the "REQUIRED" flag to produce an error
+if the WITH_CURL option was set to ``True``, but no suitable *libcurl*
+implementation with development support was found.  This construct is used
+so that the CMake script code inside the ``if(WITH_CURL)`` and ``endif()``
+block can be expanded later to download and compile *libcurl* as part of the
+LAMMPS build process, if it is not found locally.  The
+``target_compile_definitions()`` function added the define ``-DLAMMPS_CURL``
+to the compilation flags when compiling objects for the LAMMPS library.
+This allows to always compile the :doc:`geturl command <geturl>`, but use
+pre-processing to compile in the interface to *libcurl* only when it is
+present and usable and otherwise stop with an error message about the
+unavailability of *libcurl* to execute the functionality of the command.
+
+Header file
+"""""""""""
+
+The first segment of any LAMMPS source should be the copyright and
+license statement.  Note the marker in the first line to indicate to
+editors like emacs that this file is a C++ source, even though the .h
+extension suggests a C source (this is a convention inherited from the
+very beginning of the C++ version of LAMMPS).
+
+.. code-block:: c++
+
+   /* -*- c++ -*- ----------------------------------------------------------
+      LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+      https://www.lammps.org/, Sandia National Laboratories
+      LAMMPS development team: developers@lammps.org
+
+      Copyright (2003) Sandia Corporation.  Under the terms of Contract
+      DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+      certain rights in this software.  This software is distributed under
+      the GNU General Public License.
+
+      See the README file in the top-level LAMMPS directory.
+   ------------------------------------------------------------------------- */
+
+Every command style must be registered in LAMMPS by including the following
+lines of code in the second part of the header after the copyright
+message and before the include guards for the class definition:
+
+.. code-block:: c++
+
+   #ifdef COMMAND_CLASS
+   // clang-format off
+   CommandStyle(geturl,GetURL);
+   // clang-format on
+   #else
+
+This block between ``#ifdef COMMAND_CLASS`` and ``#else`` will be
+included by the ``Input`` class in ``input.cpp`` to build a map of
+"factory functions" that will create an instance of a Command class
+and call its ``command()`` method.  The map connects the name of the
+command ``geturl`` with the name of the class ``GetURL``.  During
+compilation, LAMMPS constructs a file ``style_command.h`` that contains
+``#include`` statements for all "installed" command styles.  Before
+including ``style_command.h`` into ``input.cpp``, the ``COMMAND_CLASS``
+define is set and the ``CommandStyle(name,class)`` macro defined.  The
+code of the macro adds the installed command styles to the "factory map"
+which enables the ``Input`` to execute the command.
+
+The list of header files to include in ``style_command.h`` is automatically
+updated by the build system if there are new files, so the presence of the
+new header file in the ``src/EXTRA-COMMAND`` folder and the enabling of the
+EXTRA-COMMAND package will trigger LAMMPS to include the new command style
+when it is (re-)compiled.  The "// clang-format" format comments are needed
+so that running :ref:`clang-format <clang-format>` on the file will not
+insert unwanted blanks which would break the ``CommandStyle`` macro.
+
+The third part of the header file is the actual class definition of the
+``GetURL`` class.  This has the custom constructor and the ``command()``
+method implemented by this command style.  For the constructor there is
+nothing to do but to pass the ``lmp`` pointer to the base class.  Since the
+``command()`` method is labeled "virtual" in the base class, it must be
+given the "override" property.
+
+.. code-block:: c++
+
+   #ifndef LMP_GETURL_H
+   #define LMP_GETURL_H
+
+   #include "command.h"
+
+   namespace LAMMPS_NS {
+
+   class GetURL : public Command {
+    public:
+     GetURL(class LAMMPS *lmp) : Command(lmp) {};
+     void command(int, char **) override;
+   };
+   }    // namespace LAMMPS_NS
+   #endif
+   #endif
+
+The "override" property helps to detect unexpected mismatches because
+compilation will stop with an error in case the signature of a function
+is changed in the base class without also changing it in all derived
+classes.
+
+Implementation file
+"""""""""""""""""""
+
+We move on to the implementation of the ``GetURL`` class in the
+``geturl.cpp`` file.  This file also starts with a LAMMPS copyright and
+license header.  Below that notice is typically the space where comments may
+be added with additional information about this specific file, the
+author(s), affiliation(s), and email address(es).  This way the contributing
+author(s) can be easily contacted, when there are questions about the
+implementation later.  Since the file(s) may be around for a long time, it
+is beneficial to use some kind of "permanent" email address, if possible.
+
+.. code-block:: c++
+
+   /* ----------------------------------------------------------------------
+      LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+      https://www.lammps.org/, Sandia National Laboratories
+      LAMMPS development team: developers@lammps.org
+
+      Copyright (2003) Sandia Corporation.  Under the terms of Contract
+      DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+      certain rights in this software.  This software is distributed under
+      the GNU General Public License.
+
+      See the README file in the top-level LAMMPS directory.
+   ------------------------------------------------------------------------- */
+
+   /* ----------------------------------------------------------------------
+      Contributing authors:  Axel Kohlmeyer (Temple U),
+   ------------------------------------------------------------------------- */
+
+   #include "geturl.h"
+
+   #include "comm.h"
+   #include "error.h"
+
+   #if defined(LAMMPS_CURL)
+   #include <curl/curl.h>
+   #endif
+
+   using namespace LAMMPS_NS;
+
+The second section of the implementation file has various include
+statements.  The include file for the class header has to come first, then a
+couple of LAMMPS classes (sorted alphabetically) followed by the header for
+the *libcurl* interface.  This is wrapped into an ``#ifdef`` block so that
+LAMMPS will compile this file without error when the *libcurl* header is not
+available and thus the define not set.  The final statement of this segment
+imports the ``LAMMPS_NS::`` namespace globally for this file.  This way, all
+LAMMPS specific functions and classes do not have to be prefixed with
+``LAMMPS_NS::``.
+
+The command() function (required)
+"""""""""""""""""""""""""""""""""
+
+Since the required custom constructor is trivial and implemented in the
+header, there is only one function that must be implemented for a command
+style and that is the ``command()`` function.
+
+.. code-block:: c++
+
+   void GetURL::command(int narg, char **arg)
+   {
+   #if !defined(LAMMPS_CURL)
+     error->all(FLERR, "LAMMPS has not been compiled with libcurl support");
+   #else
+     if (narg < 1) utils::missing_cmd_args(FLERR, "geturl", error);
+     int verify = 1;
+     int overwrite = 1;
+     int verbose = 0;
+
+This first part also has the ``#ifdef`` block depending on the LAMMPS_CURL
+define.  This way the command will simply print an error, if *libcurl* is
+not available but will not fail to compile.  Furthermore, it sets the
+defaults for the following optional arguments.
+
+.. code-block:: c++
+
+     // process arguments
+
+     std::string url = arg[0];
+
+     // sanity check
+
+     if ((url.find(':') == std::string::npos) || (url.find('/') == std::string::npos))
+       error->all(FLERR, "URL '{}' is not a supported URL", url);
+
+     std::string output = url.substr(url.find_last_of('/') + 1);
+     if (output.empty()) error->all(FLERR, "URL '{}' must end in a file string", url);
+
+This block stores the positional, i.e. non-optional argument of the URL to
+be downloaded and adds a couple of sanity checks on the string to make sure it is
+a valid URL.  Also it derives the default name of the output file from the URL.
+
+.. code-block:: c++
+
+     int iarg = 1;
+     while (iarg < narg) {
+       if (strcmp(arg[iarg], "output") == 0) {
+         if (iarg + 2 > narg) utils::missing_cmd_args(FLERR, "geturl output", error);
+         output = arg[iarg + 1];
+         ++iarg;
+       } else if (strcmp(arg[iarg], "overwrite") == 0) {
+         if (iarg + 2 > narg) utils::missing_cmd_args(FLERR, "geturl overwrite", error);
+         overwrite = utils::logical(FLERR, arg[iarg + 1], false, lmp);
+         ++iarg;
+       } else if (strcmp(arg[iarg], "verify") == 0) {
+         if (iarg + 2 > narg) utils::missing_cmd_args(FLERR, "geturl verify", error);
+         verify = utils::logical(FLERR, arg[iarg + 1], false, lmp);
+         ++iarg;
+       } else if (strcmp(arg[iarg], "verbose") == 0) {
+         if (iarg + 2 > narg) utils::missing_cmd_args(FLERR, "geturl verbose", error);
+         verbose = utils::logical(FLERR, arg[iarg + 1], false, lmp);
+         ++iarg;
+       } else {
+         error->all(FLERR, "Unknown geturl keyword: {}", arg[iarg]);
+       }
+       ++iarg;
+     }
+
+This block parses the optional arguments following the URL and stops with an
+error if there are arguments missing or an unknown argument is encountered.
+
+.. code-block:: c++
+
+     // only download files from rank 0
+
+     if (comm->me != 0) return;
+
+     if (!overwrite && platform::file_is_readable(output)) return;
+
+     // open output file for writing
+
+     FILE *out = fopen(output.c_str(), "wb");
+     if (!out)
+       error->all(FLERR, "Cannot open output file {} for writing: {}", output, utils::getsyserror());
+
+Here all MPI ranks other than 0 will return, so that the URL download will
+only happen from a single MPI rank. For that rank the output file is opened
+for writing using the C library function ``fopen()``.
+
+.. code-block:: c++
+
+     // initialize curl and perform download
+
+     CURL *curl;
+     curl_global_init(CURL_GLOBAL_DEFAULT);
+     curl = curl_easy_init();
+     if (curl) {
+       (void) curl_easy_setopt(curl, CURLOPT_URL, url.c_str());
+       (void) curl_easy_setopt(curl, CURLOPT_WRITEDATA, (void *) out);
+       (void) curl_easy_setopt(curl, CURLOPT_FILETIME, 1L);
+       (void) curl_easy_setopt(curl, CURLOPT_FAILONERROR, 1L);
+       if (verbose && screen) {
+         (void) curl_easy_setopt(curl, CURLOPT_VERBOSE, 1L);
+         (void) curl_easy_setopt(curl, CURLOPT_STDERR, (void *) screen);
+       }
+       if (!verify) {
+         (void) curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0L);
+         (void) curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0L);
+       }
+       auto res = curl_easy_perform(curl);
+       if (res != CURLE_OK) {
+         long response = 0L;
+         curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &response);
+         error->one(FLERR, "Download of {} failed with: {} {}", output, curl_easy_strerror(res),
+                    response);
+       }
+       curl_easy_cleanup(curl);
+
+This block now implements the actual URL download with the selected options
+via the "easy" interface of *libcurl*.  For the details of what these
+function calls do, please have a look at the `*libcurl documentation
+<https://curl.se/libcurl/c/allfuncs.html>`_.
+
+ .. code-block:: c++
+
+     }
+     curl_global_cleanup();
+     fclose(out);
+   #endif
+   }
+
+Finally, the previously opened file is closed and the command is complete.

doc/src/Developer_write_pair.rst

@@ -160,7 +160,7 @@ message and before the include guards for the class definition:
 
    #endif
 
-This block of between ``#ifdef PAIR_CLASS`` and ``#else`` will be
+This block between ``#ifdef PAIR_CLASS`` and ``#else`` will be
 included by the ``Force`` class in ``force.cpp`` to build a map of
 "factory functions" that will create an instance of these classes and
 return a pointer to it.  The map connects the name of the pair style,
@@ -310,7 +310,7 @@ the constructor and the destructor.
 
 Pair styles are different from most classes in LAMMPS that define a
 "style", as their constructor only uses the LAMMPS class instance
-pointer as an argument, but **not** the command line arguments of the
+pointer as an argument, but **not** the arguments of the
 :doc:`pair_style command <pair_style>`.  Instead, those arguments are
 processed in the ``Pair::settings()`` function (or rather the version in
 the derived class).  The constructor is the place where global defaults
@@ -891,7 +891,7 @@ originally created from mixing or not).
 These data file output functions are only useful for true pair-wise
 additive potentials, where the potential parameters can be entered
 through *multiple* :doc:`pair_coeff commands <pair_coeff>`.  Pair styles
-that require a single "pair_coeff \* \*" command line are not compatible
+that require a single "pair_coeff \* \*" command are not compatible
 with reading their parameters from data files.  For pair styles like
 *born/gauss* that do support writing to data files, the potential
 parameters will be read from the data file, if present, and
@@ -1122,7 +1122,7 @@ once.  Thus, the ``coeff()`` function has to do three tasks, each of
 which is delegated to a function in the ``PairTersoff`` class:
 
 #. map elements to atom types.  Those follow the potential file name in the
-   command line arguments and are processed by the ``map_element2type()`` function.
+   command arguments and are processed by the ``map_element2type()`` function.
 #. read and parse the potential parameter file in the ``read_file()`` function.
 #. Build data structures where the original and derived parameters are
    indexed by all possible triples of atom types and thus can be looked
@@ -1356,8 +1356,8 @@ either 0 or 1.
 
 The ``morseflag`` variable defaults to 0 and is set to 1 in the
 ``PairAIREBOMorse::settings()`` function which is called by the
-:doc:`pair_style <pair_style>` command.  This function delegates
-all command line processing and setting of other parameters to the
+:doc:`pair_style <pair_style>` command.  This function delegates all
+command argument processing and setting of other parameters to the
 ``PairAIREBO::settings()`` function of the base class.
 
 .. code-block:: c++

doc/src/Errors_debug.rst

@@ -83,7 +83,7 @@ Run LAMMPS from within the debugger
 Running LAMMPS under the control of the debugger as shown below only
 works for a single MPI rank (for debugging a program running in parallel
 you usually need a parallel debugger program).  A simple way to launch
-GDB is to prefix the LAMMPS command line with ``gdb --args`` and then
+GDB is to prefix the LAMMPS command-line with ``gdb --args`` and then
 type the command "run" at the GDB prompt.  This will launch the
 debugger, load the LAMMPS executable and its debug info, and then run
 it.  When it reaches the code causing the segmentation fault, it will
@@ -180,7 +180,7 @@ inspect the behavior of a compiled program by essentially emulating a
 CPU and instrumenting the program while running.  This slows down
 execution quite significantly, but can also report issues that are not
 resulting in a crash.  The default valgrind tool is a memory checker and
-you can use it by prefixing the normal command line with ``valgrind``.
+you can use it by prefixing the normal command-line with ``valgrind``.
 Unlike GDB, this will also work for parallel execution, but it is
 recommended to redirect the valgrind output to a file (e.g. with
 ``--log-file=crash-%p.txt``, the %p will be substituted with the
@@ -235,3 +235,53 @@ from GDB. In addition you get a more specific hint about what cause the
 segmentation fault, i.e. that it is a NULL pointer dereference.  To find
 out which pointer exactly was NULL, you need to use the debugger, though.
 
+Debugging when LAMMPS appears to be stuck
+=========================================
+
+Sometimes the LAMMPS calculation appears to be stuck, that is the LAMMPS
+process or processes are active, but there is no visible progress.  This
+can have multiple reasons:
+
+- The selected styles are slow and require a lot of CPU time and the
+  system is large. When extrapolating the expected speed from smaller
+  systems, one has to factor in that not all models scale linearly with
+  system size, e.g. :doc:`kspace styles like ewald or pppm
+  <kspace_style>`. There is very little that can be done in this case.
+- The output interval is not set or set to a large value with the
+  :doc:`thermo <thermo>` command. I the first case, there will be output
+  only at the first and last step.
+- The output is block-buffered and instead of line-buffered. The output
+  will only be written to the screen after 4096 or 8192 characters of
+  output have accumulated.  This most often happens for files but also
+  with MPI parallel executables for output to the screen, since the
+  output to the screen is handled by the MPI library so that output from
+  all processes can be shown.  This can be suppressed by using the
+  ``-nonblock`` or ``-nb`` command-line flag, which turns off buffering
+  for screen and logfile output.
+- An MPI parallel calculation has a bug where a collective MPI function
+  is called (e.g. ``MPI_Barrier()``, ``MPI_Bcast()``,
+  ``MPI_Allreduce()`` and so on) before pending point-to-point
+  communications are completed or when the collective function is only
+  called from a subset of the MPI processes.  This also applies to some
+  internal LAMMPS functions like ``Error::all()`` which uses
+  ``MPI_Barrier()`` and thus ``Error::one()`` must be called, if the
+  error condition does not happen on all MPI processes simultaneously.
+- Some function in LAMMPS has a bug where a ``for`` or ``while`` loop
+  does not trigger the exit condition and thus will loop forever.  This
+  can happen when the wrong variable is incremented or when one value in
+  a comparison becomes ``NaN`` due to an overflow.
+
+In the latter two cases, further information and stack traces (see above)
+can be obtain by attaching a debugger to a running process.  For that the
+process ID (PID) is needed; this can be found on Linux machines with the
+``top``, ``htop``, ``ps``, or ``pstree`` commands.
+
+Then running the (GNU) debugger ``gdb`` with the ``-p`` flag followed by
+the process id will attach the process to the debugger and stop
+execution of that specific process.  From there on it is possible to
+issue all debugger commands in the same way as when LAMMPS was started
+from the debugger (see above).  Most importantly it is possible to
+obtain a stack trace with the ``where`` command and thus determine where
+in the execution of a timestep this process is.  Also internal data can
+be printed and execution single stepped or continued.  When the debugger
+is exited, the calculation will resume normally.

doc/src/Errors_details.rst

@@ -54,3 +54,26 @@ header of a data file (e.g. the number of atoms) is larger than the
 number of lines provided (e.g. in the corresponding Atoms section)
 and then LAMMPS will continue reading into the next section and that
 would have a completely different format.
+
+.. _err0003:
+
+Illegal variable command: expected X arguments but found Y
+----------------------------------------------------------
+
+This error indicates that there are the wrong number of arguments for a
+specific variable command, but a common reason for that is a variable
+expression that has whitespace but is not enclosed in single or double
+quotes.
+
+To explain, the LAMMPS input parser reads and processes lines.  The
+resulting line is broken down into "words".  Those are usually
+individual commands, labels, names, values separated by whitespace (a
+space or tab character).  For "words" that may contain whitespace, they
+have to be enclosed in single (') or double (") quotes.  The parser will
+then remove the outermost pair of quotes and then pass that string as
+"word" to the variable command.
+
+Thus missing quotes or accidental extra whitespace will lead to the
+error shown in the header because the unquoted whitespace will result
+in the text being broken into more "words", i.e. the variable expression
+being split.

doc/src/Errors_messages.rst

@@ -7774,7 +7774,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
 *Too few values in body section of molecule file*
    Self-explanatory.
 
-*Too many -pk arguments in command line*
+*Too many -pk arguments in command-line*
    The string formed by concatenating the arguments is too long.  Use a
    package command in the input script instead.
 

doc/src/Examples.rst

@@ -146,6 +146,8 @@ Lowercase directories
 +-------------+------------------------------------------------------------------+
 | streitz     | use of Streitz/Mintmire potential with charge equilibration      |
 +-------------+------------------------------------------------------------------+
+| stress_vcm  | removing binned rigid body motion from binned stress profile     |
++-------------+------------------------------------------------------------------+
 | tad         | temperature-accelerated dynamics of vacancy diffusion in bulk Si |
 +-------------+------------------------------------------------------------------+
 | threebody   | regression test input for a variety of manybody potentials       |

doc/src/Fortran.rst

@@ -16,7 +16,7 @@ compiled alongside the code using it from the source code in
 ``fortran/lammps.f90`` *and* with the same compiler used to build the
 rest of the Fortran code that interfaces to LAMMPS.  When linking, you
 also need to :doc:`link to the LAMMPS library <Build_link>`.  A typical
-command line for a simple program using the Fortran interface would be:
+command for a simple program using the Fortran interface would be:
 
 .. code-block:: bash
 
@@ -91,12 +91,12 @@ function and triggered with the optional logical argument set to
      CALL lmp%close(.TRUE.)
    END PROGRAM testlib
 
-It is also possible to pass command line flags from Fortran to C/C++ and
+It is also possible to pass command-line flags from Fortran to C/C++ and
 thus make the resulting executable behave similarly to the standalone
 executable (it will ignore the `-in/-i` flag, though).  This allows
-using the command line to configure accelerator and suffix settings,
+using the command-line to configure accelerator and suffix settings,
 configure screen and logfile output, or to set index style variables
-from the command line and more.  Here is a correspondingly adapted
+from the command-line and more.  Here is a correspondingly adapted
 version of the previous example:
 
 .. code-block:: fortran
@@ -108,7 +108,7 @@ version of the previous example:
      CHARACTER(LEN=128), ALLOCATABLE :: command_args(:)
      INTEGER :: i, argc
 
-     ! copy command line flags to `command_args()`
+     ! copy command-line flags to `command_args()`
      argc = COMMAND_ARGUMENT_COUNT()
      ALLOCATE(command_args(0:argc))
      DO i=0, argc
@@ -321,6 +321,8 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
    :ftype set_string_variable: subroutine
    :f set_internal_variable: :f:subr:`set_internal_variable`
    :ftype set_internal_variable: subroutine
+   :f eval: :f:func:`eval`
+   :ftype eval: function
    :f gather_atoms: :f:subr:`gather_atoms`
    :ftype gather_atoms: subroutine
    :f gather_atoms_concat: :f:subr:`gather_atoms_concat`
@@ -448,7 +450,7 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
    compiled with MPI support, it will also initialize MPI, if it has
    not already been initialized before.
 
-   The *args* argument with the list of command line parameters is
+   The *args* argument with the list of command-line parameters is
    optional and so it the *comm* argument with the MPI communicator.
    If *comm* is not provided, ``MPI_COMM_WORLD`` is assumed. For
    more details please see the documentation of :cpp:func:`lammps_open`.

doc/src/Howto.rst

@@ -23,7 +23,6 @@ General howto
    Howto_library
    Howto_couple
    Howto_mdi
-   Howto_broken_bonds
 
 Settings howto
 ==============
@@ -49,6 +48,7 @@ Analysis howto
    :maxdepth: 1
 
    Howto_output
+   Howto_structured_data
    Howto_chunk
    Howto_grid
    Howto_temperature
@@ -56,7 +56,6 @@ Analysis howto
    Howto_kappa
    Howto_viscosity
    Howto_diffusion
-   Howto_structured_data
 
 Force fields howto
 ==================
@@ -65,6 +64,7 @@ Force fields howto
    :name: force_howto
    :maxdepth: 1
 
+   Howto_broken_bonds
    Howto_bioFF
    Howto_amoeba
    Howto_tip3p
@@ -81,6 +81,7 @@ Packages howto
 
    Howto_spherical
    Howto_granular
+   Howto_granular_surfaces
    Howto_body
    Howto_bpm
    Howto_polarizable
@@ -103,6 +104,7 @@ Tutorials howto
    Howto_github
    Howto_lammps_gui
    Howto_moltemplate
+   Howto_python
    Howto_pylammps
    Howto_wsl
 

doc/src/Howto_bioFF.rst

@@ -1,5 +1,5 @@
-CHARMM, AMBER, COMPASS, and DREIDING force fields
-=================================================
+CHARMM, AMBER, COMPASS, DREIDING, and OPLS force fields
+=======================================================
 
 A compact summary of the concepts, definitions, and properties of
 force fields with explicit bonded interactions (like the ones discussed
@@ -236,6 +236,40 @@ documentation for the formula it computes.
 
 * :doc:`special_bonds <special_bonds>` dreiding
 
+OPLS
+----
+
+OPLS (Optimized Potentials for Liquid Simulations) is a general force
+field for atomistic simulation of organic molecules in solvent.  It was
+developed by the `Jorgensen group
+<https://traken.chem.yale.edu/oplsaam.html>`_ at Purdue University and
+later at Yale University.  Multiple versions of the OPLS parameters
+exist for united atom representations (OPLS-UA) and for all-atom
+representations (OPLS-AA).
+
+This force field is based on atom types mapped to specific functional
+groups in organic and biological molecules.  Each atom includes a
+static, partial atomic charge reflecting the oxidation state of the
+element derived from its bonded neighbors :ref:`(Jorgensen)
+<howto-jorgensen>` and computed based on increments determined by the
+atom type of the atoms bond to it.
+
+The interaction styles listed below compute force field formulas that
+are fully or in part consistent with the OPLS style force fields.  See
+each command's documentation for the formula it computes.  Some are only
+compatible with a subset of OPLS interactions.
+
+* :doc:`bond_style <bond_harmonic>` harmonic
+* :doc:`angle_style <angle_harmonic>` harmonic
+* :doc:`dihedral_style <dihedral_opls>` opls
+* :doc:`improper_style <improper_cvff>` cvff
+* :doc:`improper_style <improper_fourier>` fourier
+* :doc:`improper_style <improper_harmonic>` harmonic
+* :doc:`pair_style <pair_lj_cut_coul>` lj/cut/coul/cut
+* :doc:`pair_style <pair_lj_cut_coul>` lj/cut/coul/long
+* :doc:`pair_modify <pair_modify>` geometric
+* :doc:`special_bonds <special_bonds>` lj/coul 0.0 0.0 0.5
+
 ----------
 
 .. _Typelabel2:
@@ -266,3 +300,6 @@ documentation for the formula it computes.
 
 **(Mayo)** Mayo, Olfason, Goddard III (1990). J Phys Chem, 94, 8897-8909. https://doi.org/10.1021/j100389a010
 
+.. _howto-Jorgensen:
+
+**(Jorgensen)** Jorgensen, Tirado-Rives (1988). J Am Chem Soc, 110, 1657-1666. https://doi.org/10.1021/ja00214a001

doc/src/Howto_bpm.rst

@@ -5,7 +5,11 @@ The BPM package implements bonded particle models which can be used to
 simulate mesoscale solids.  Solids are constructed as a collection of
 particles, which each represent a coarse-grained region of space much
 larger than the atomistic scale.  Particles within a solid region are
-then connected by a network of bonds to provide solid elasticity.
+then connected by a network of bonds to model solid elasticity.
+There are many names for methods that are based on similar (or
+equivalent) capabilities to those in this package, including, but not
+limited to, cohesive beam models, bonded DEMs, lattice spring models,
+mass spring models, and lattice particle methods.
 
 Unlike traditional bonds in molecular dynamics, the equilibrium bond
 length can vary between bonds. Bonds store the reference state.  This
@@ -42,7 +46,8 @@ Currently, there are two types of bonds included in the BPM package. The
 first bond style, :doc:`bond bpm/spring <bond_bpm_spring>`, only applies
 pairwise, central body forces. Point particles must have :doc:`bond atom
 style <atom_style>` and may be thought of as nodes in a spring
-network. Alternatively, the second bond style, :doc:`bond bpm/rotational
+network. An optional multibody term can be used to adjust the network's
+Poisson's ratio. Alternatively, the second bond style, :doc:`bond bpm/rotational
 <bond_bpm_rotational>`, resolves tangential forces and torques arising
 with the shearing, bending, and twisting of the bond due to rotation or
 displacement of particles.  Particles are similar to those used in the
@@ -55,8 +60,9 @@ orientation similar to :doc:`fix nve/asphere <fix_nve_asphere>`.
 
 In addition to bond styles, a new pair style :doc:`pair bpm/spring
 <pair_bpm_spring>` was added to accompany the bpm/spring bond
-style. This pair style is simply a hookean repulsion with similar
-velocity damping as its sister bond style.
+style. By default, this pair style is simply a hookean repulsion with
+similar velocity damping as its sister bond style, but optional
+arguments can be used to modify the force.
 
 ----------
 

doc/src/Howto_chunk.rst

@@ -58,28 +58,30 @@ chunk ID for an individual atom can also be static (e.g. a molecule
 ID), or dynamic (e.g. what spatial bin an atom is in as it moves).
 
 Note that this compute allows the per-atom output of other
-:doc:`computes <compute>`, :doc:`fixes <fix>`, and
-:doc:`variables <variable>` to be used to define chunk IDs for each
-atom.  This means you can write your own compute or fix to output a
-per-atom quantity to use as chunk ID.  See the :doc:`Modify <Modify>`
-doc pages for info on how to do this.  You can also define a :doc:`per-atom variable <variable>` in the input script that uses a formula to
-generate a chunk ID for each atom.
+:doc:`computes <compute>`, :doc:`fixes <fix>`, and :doc:`variables
+<variable>` to be used to define chunk IDs for each atom.  This means
+you can write your own compute or fix to output a per-atom quantity to
+use as chunk ID.  See the :doc:`Modify <Modify>` doc pages for info on
+how to do this.  You can also define a :doc:`per-atom variable
+<variable>` in the input script that uses a formula to generate a chunk
+ID for each atom.
 
 Fix ave/chunk command:
 ----------------------
 
-This fix takes the ID of a :doc:`compute chunk/atom <compute_chunk_atom>` command as input.  For each chunk,
-it then sums one or more specified per-atom values over the atoms in
-each chunk.  The per-atom values can be any atom property, such as
-velocity, force, charge, potential energy, kinetic energy, stress,
-etc.  Additional keywords are defined for per-chunk properties like
-density and temperature.  More generally any per-atom value generated
-by other :doc:`computes <compute>`, :doc:`fixes <fix>`, and :doc:`per-atom variables <variable>`, can be summed over atoms in each chunk.
+This fix takes the ID of a :doc:`compute chunk/atom
+<compute_chunk_atom>` command as input.  For each chunk, it then sums
+one or more specified per-atom values over the atoms in each chunk.  The
+per-atom values can be any atom property, such as velocity, force,
+charge, potential energy, kinetic energy, stress, etc.  Additional
+keywords are defined for per-chunk properties like density and
+temperature.  More generally any per-atom value generated by other
+:doc:`computes <compute>`, :doc:`fixes <fix>`, and :doc:`per-atom
+variables <variable>`, can be summed over atoms in each chunk.
 
 Similar to other averaging fixes, this fix allows the summed per-chunk
 values to be time-averaged in various ways, and output to a file.  The
-fix produces a global array as output with one row of values per
-chunk.
+fix produces a global array as output with one row of values per chunk.
 
 Compute \*/chunk commands:
 --------------------------
@@ -97,17 +99,20 @@ category:
 * :doc:`compute torque/chunk <compute_vcm_chunk>`
 * :doc:`compute vcm/chunk <compute_vcm_chunk>`
 
-They each take the ID of a :doc:`compute chunk/atom <compute_chunk_atom>` command as input.  As their names
-indicate, they calculate the center-of-mass, radius of gyration,
-moments of inertia, mean-squared displacement, temperature, torque,
-and velocity of center-of-mass for each chunk of atoms.  The :doc:`compute property/chunk <compute_property_chunk>` command can tally the
-count of atoms in each chunk and extract other per-chunk properties.
+They each take the ID of a :doc:`compute chunk/atom
+<compute_chunk_atom>` command as input.  As their names indicate, they
+calculate the center-of-mass, radius of gyration, moments of inertia,
+mean-squared displacement, temperature, torque, and velocity of
+center-of-mass for each chunk of atoms.  The :doc:`compute
+property/chunk <compute_property_chunk>` command can tally the count of
+atoms in each chunk and extract other per-chunk properties.
 
-The reason these various calculations are not part of the :doc:`fix ave/chunk command <fix_ave_chunk>`, is that each requires a more
+The reason these various calculations are not part of the :doc:`fix
+ave/chunk command <fix_ave_chunk>`, is that each requires a more
 complicated operation than simply summing and averaging over per-atom
-values in each chunk.  For example, many of them require calculation
-of a center of mass, which requires summing mass\*position over the
-atoms and then dividing by summed mass.
+values in each chunk.  For example, many of them require calculation of
+a center of mass, which requires summing mass\*position over the atoms
+and then dividing by summed mass.
 
 All of these computes produce a global vector or global array as
 output, with one or more values per chunk.  The output can be used in
@@ -118,9 +123,10 @@ various ways:
 * As input to the :doc:`fix ave/histo <fix_ave_histo>` command to
   histogram values across chunks.  E.g. a histogram of cluster sizes or
   molecule diffusion rates.
-* As input to special functions of :doc:`equal-style variables <variable>`, like sum() and max() and ave().  E.g. to
-  find the largest cluster or fastest diffusing molecule or average
-  radius-of-gyration of a set of molecules (chunks).
+* As input to special functions of :doc:`equal-style variables
+  <variable>`, like sum() and max() and ave().  E.g. to find the largest
+  cluster or fastest diffusing molecule or average radius-of-gyration of
+  a set of molecules (chunks).
 
 Other chunk commands:
 ---------------------
@@ -138,9 +144,10 @@ spatially average per-chunk values calculated by a per-chunk compute.
 
 The :doc:`compute reduce/chunk <compute_reduce_chunk>` command reduces a
 peratom value across the atoms in each chunk to produce a value per
-chunk.  When used with the :doc:`compute chunk/spread/atom <compute_chunk_spread_atom>` command it can
-create peratom values that induce a new set of chunks with a second
-:doc:`compute chunk/atom <compute_chunk_atom>` command.
+chunk.  When used with the :doc:`compute chunk/spread/atom
+<compute_chunk_spread_atom>` command it can create peratom values that
+induce a new set of chunks with a second :doc:`compute chunk/atom
+<compute_chunk_atom>` command.
 
 Example calculations with chunks
 --------------------------------

doc/src/Howto_cmake.rst

@@ -56,7 +56,7 @@ using a shell like Bash or Zsh.
    Visual Studio IDE with the bundled CMake or from the Windows command prompt using
    a separately installed CMake package, both using the native Microsoft Visual C++
    compilers and (optionally) the Microsoft MPI SDK.  This tutorial, however, only
-   covers unix-like command line interfaces.
+   covers unix-like command-line interfaces.
 
 We also assume that you have downloaded and unpacked a recent LAMMPS source code package
 or used Git to create a clone of the LAMMPS sources on your compilation machine.
@@ -277,7 +277,7 @@ Setting options
 ---------------
 
 Options that enable, disable or modify settings are modified by setting
-the value of CMake variables. This is done on the command line with the
+the value of CMake variables. This is done on the command-line with the
 *-D* flag in the format ``-D VARIABLE=value``, e.g. ``-D
 CMAKE_BUILD_TYPE=Release`` or ``-D BUILD_MPI=on``.  There is one quirk:
 when used before the CMake directory, there may be a space between the
@@ -348,7 +348,7 @@ Some common LAMMPS specific variables
    * - ``FFT``
      - select which FFT library to use: ``FFTW3``, ``MKL``, ``KISS`` (default, unless FFTW3 is found)
    * - ``FFT_KOKKOS``
-     - select which FFT library to use in Kokkos-enabled styles: ``FFTW3``, ``MKL``, ``HIPFFT``, ``CUFFT``, ``KISS`` (default)
+     - select which FFT library to use in Kokkos-enabled styles: ``FFTW3``, ``MKL``, ``HIPFFT``, ``CUFFT``, ``MKL_GPU``, ``KISS`` (default)
    * - ``FFT_SINGLE``
      - select whether to use single precision FFTs (default: ``off``)
    * - ``WITH_JPEG``
@@ -376,7 +376,7 @@ Using presets
 -------------
 
 Since LAMMPS has a lot of optional features and packages, specifying
-them all on the command line can be tedious. Or when selecting a
+them all on the command-line can be tedious. Or when selecting a
 different compiler toolchain, multiple options have to be changed
 consistently and that is rather error prone. Or when enabling certain
 packages, they require consistent settings to be operated in a
@@ -384,7 +384,7 @@ particular mode.  For this purpose, we are providing a selection of
 "preset files" for CMake in the folder ``cmake/presets``.  They
 represent a way to pre-load or override the CMake configuration cache by
 setting or changing CMake variables.  Preset files are loaded using the
-*-C* command line flag. You can combine loading multiple preset files or
+*-C* command-line flag. You can combine loading multiple preset files or
 change some variables later with additional *-D* flags.  A few examples:
 
 .. code-block:: bash

doc/src/Howto_github.rst

@@ -163,7 +163,7 @@ After everything is done, add the files to the branch and commit them:
    *git rm*, *git mv* for adding, removing, renaming individual files,
    respectively, and then *git commit* to finalize the commit.
    Carefully check all pending changes with *git status* before
-   committing them.  If you find doing this on the command line too
+   committing them.  If you find doing this on the command-line too
    tedious, consider using a GUI, for example the one included in git
    distributions written in Tk, i.e. use *git gui* (on some Linux
    distributions it may be required to install an additional package to

doc/src/Howto_granular.rst

@@ -1,10 +1,28 @@
 Granular models
 ===============
 
-Granular system are composed of spherical particles with a diameter,
+Granular systems are composed of spherical particles with a diameter,
 as opposed to point particles.  This means they have an angular
 velocity and torque can be imparted to them to cause them to rotate.
 
+The various atom, pair, fix, and compute styles listed below are
+useful for creaeting granular models.
+
+You can also define granular surfaces which are a collection of line
+segments (2d systems) or triangles (3d systems), which act as
+boundaries interacting with the particles.  Particle/surface
+interactions can be specified with similar options as the pair styles
+listed below.
+
+This Howto doc page and two fixes explain how to define and use
+granular surfaces:
+
+* :doc:`Howto granular surfaces <Howto_granular_surfaces>`
+* :doc:`fix surface/global <fix_surface_global>`
+* :doc:`fix surface/local <fix_surface_local>`
+
+----------
+
 To run a simulation of a granular model, you will want to use
 the following commands:
 
@@ -16,12 +34,15 @@ This compute
 
 * :doc:`compute erotate/sphere <compute_erotate_sphere>`
 
-calculates rotational kinetic energy which can be :doc:`output with thermodynamic info <Howto_output>`.
-The compute
+calculates rotational kinetic energy which can be :doc:`output with
+thermodynamic info <Howto_output>`.
+
+This compute
 
 * :doc:`compute fabric <compute_fabric>`
 
-calculates various versions of the fabric tensor for granular and non-granular pair styles.
+calculates various versions of the fabric tensor for granular and
+non-granular pair styles.
 
 Use one of these 4 pair potentials, which compute forces and torques
 between interacting pairs of particles:
@@ -31,8 +52,13 @@ between interacting pairs of particles:
 * :doc:`pair_style gran/hertzian <pair_gran>`
 * :doc:`pair_style granular <pair_granular>`
 
+To add your own custom granular contact model to the :doc:`pair_style
+granular <pair_granular>` command, see the :doc:`Modifying granular
+sub-models <Modify_gran_sub_mod>` doc page.
+
 These commands implement fix options specific to granular systems:
 
+* :doc:`fix freeze <fix_freeze>`
 * :doc:`fix freeze <fix_freeze>`
 * :doc:`fix pour <fix_pour>`
 * :doc:`fix viscous <fix_viscous>`
@@ -69,6 +95,3 @@ computations between frozen atoms by using this command:
    will be the same as in 3d.  If you wish to model granular particles in
    2d as 2d discs, see the note on this topic on the :doc:`Howto 2d <Howto_2d>`
    doc page, where 2d simulations are discussed.
-
-To add custom granular contact models, see the
-:doc:`modifying granular sub-models page <Modify_gran_sub_mod>`.

doc/src/Howto_granular_surfaces.rst

@@ -0,0 +1,289 @@
+Granular surfaces
+=================
+
+As explained on the :doc:`Howto granular <Howto_granular>` doc page,
+granular systems are composed of spherical particles with a diameter,
+as opposed to point particles.  This means they have an angular
+velocity and torque can be imparted to them to cause them to rotate.
+
+The :doc:`Howto granular <Howto_granular>` doc page lists various
+atom, pair, fix, and compute styles useful for creaeting granular
+models.
+
+This page explains how you can also define granular surfaces which are
+a collection of triangles (3d systems) or line segments (2d systems),
+which act as boundaries interacting with the particles.  Different
+kinds of particle/surface interactions can be specified with similar
+options as the pair styles listed on the :doc:`Howto granular
+<Howto_granular>` doc page.
+
+----------
+
+Global versus local surfaces
+""""""""""""""""""""""""""""
+A key point to understand is that LAMMPS supports two forms of
+granular surfaces.  You cannot use both in the same simulation.
+
+The first is *global* which means that each processor stores a copy of
+all the triangles/lines.  This is suitable when a modest number of
+triangles/lines is needed.  They can be large triangles/lines, any of
+which span a significant fraction of the simulation box size in one or
+more dimensions.
+
+The second is *local* which means that the collection of
+triangles/lines is distributed across processers in the same manner
+that particles are distributed.  Each processor is assigned to
+sub-domain of the simulation box and owns whichever triangles/lines
+have their center point in the processor's sub-domain.  Similar to
+particles, each processor may also own ghost copies of triangles/lines
+whose finite size overlaps with the processor's sub-domain.  The
+number of triangles/lines can now be very large.  For effective
+distribution and minimal communication all the triangles/lines should
+be small, no more than a few particle diameters in size.  If even one
+larger triangle or line is defined then the neighbor list cutoff and
+communication cutoff will be set correspondingly larger, which can
+slow down the simulation.
+
+One of these two commands must be specified to use *global* or *local*
+surfaces in your granular simulation:
+
+* :doc:`fix surface/global <fix_surface_global>`
+* :doc:`fix surface/local <fix_surface_local>`
+
+The :doc:`fix surface/global <fix_surface_global>` command reads in
+the global surfaces in one of two ways.  The first option is from a
+molecule file(s) previously defined by the :doc:`molecule <molecule>`
+command.  The file should define triangles or lines with header
+keywords and a Triangles or Lines section.  The second option is from
+a text or binary STL (strereolithogray) file which defines a set of
+triangles.  It can only be used with 3d simulations.
+
+The :doc:`fix surface/local <fix_surface_local>` command defines local
+surface in one of three ways.  The first two options are the same
+molecule and STL files explained in the previous paragraph.  In this
+case, the list of triangles/lines is distributed across processors
+based on the center point of each triangle/line.  The third option is
+to include them in a LAMMPS data file which has been previously read
+in via the :doc:`read_data <read_data>` command.  If the file has a
+Triangles or Lines section, then triangles/lines will be read in and
+distributed along with any particles the data file includes.
+
+----------
+
+Surface attributes
+""""""""""""""""""
+
+For both global and local surfaces, each triangle/line is assigned a
+*type* and a *molecule ID*.  This is done when surfaces are read-in
+from a molecule, STL, or data file.  Since STL files do not define
+types or molecule IDs, the :doc:`fix surface/global
+<fix_surface_global>` and :doc:`fix surface/local <fix_surface_local>`
+commands specify the type that will be assigned to the read-in
+triangles.  The molecule ID for each triangle is set to 1.  The
+:doc:`fix surface/global <fix_surface_global>` command also allows use
+of the :doc:`fix_modify type/region <fix_modify>` command to assign
+types based on a geometric region.  Since local surfaces are
+effectively particles, the :doc:`set <set>` command can be used to
+alter the *type* or *molecule ID* of any triangle or line.
+
+For both global and local surfaces, types are used to define the style
+of granular interactions for individual triangles/lines.  Different
+styles can be used within a single object consisting of connected
+triangles/lines.  See the Surface Connectivity section below.
+
+Molecule IDs are not currently used by granular surface interactions,
+though they may be in the future.  They are intended to be assigned
+uniquely to each inter-connected set of triangles/lines, as if each
+object were a "molecule".  However, this is not required, and LAMMPS
+does not check that this is the case.  LAMMPS will issue a warning if
+a set of inter-connected triangles/lines do not all have the same
+molecule ID, in case this was not intentional.
+
+For local surfaces, the molecule ID can be used to define groups and
+thus assign different motions to different surface objects.  See the
+Surface Motion section below.  Various other LAMMPS commands operate
+on groups or molecules and can thus be used to gather statistics about
+or output information about individual surface objects.
+
+----------
+
+Atom styles for granular surfaces
+"""""""""""""""""""""""""""""""""
+
+For all three ways of defining *local* surfaces, the triangles/lines
+are stored internally in LAMMPS as triangle-style or line-style
+particles.  This means you must use a hybrid atom style which includes
+one of these two sub-styles (for 3d or 2d):
+
+* :doc:`atom_style tri <atom_style>` for 3d simulations
+* :doc:`atom_style line <atom_style>` for 2d simulations
+
+Typically, the atom_style hybrid command will also define a
+:doc:`atom_style sphere <atom_style>` sub-style for the granular
+particles which interact with the surfaces.
+
+Note that for molecule or STL file input, the :doc:`fix surface/local
+<fix_surface_local>` command reads the file(s) and uses the values for
+each surface to creat a single new triangle or line particle.  For
+data file input, the triangle/line particles are created when the data
+file is read.
+
+For granular simluations with *global* surfaces, a hybrid atom style
+which defines triangle-style or line-style particles should NOT be
+used.  The triangles/lines are stored by the :doc:`fix surface/global
+<fix_surface_global>` command and not as triangle-style or line-style
+particles.
+
+----------
+
+Rules for surface topology
+""""""""""""""""""""""""""
+
+For both *global* and *local* surfaces, granular particles interact
+with both sides of each triangle or line segment.
+
+No check is made to see if two triangles or line segments intersect
+each other; this is allowed if it makes sense for the geometry of the
+collection of surfaces.
+
+As an example, consider a 2d simulation which mixes a container of
+granular particles.  *Global* line segments are used to define both
+the box-shaped container and the mixer in the center.  The 4 mixer
+blades are in the shape of a large X and are made to rotate using the
+:doc:`fix_modify <fix_modify>` command (see below).
+
+The 2 blades could be defined by 2 line segments which cross each
+other at their centers.  Or the 2 blades could be defined by 4 line
+segments, all of which have a common endpoint at the center of the
+mixer.  Or the 2 blades could be defined by 4 non-touching line
+segments, all of which have a distinct endpoint near the center of the
+mixer, but displaced from it by a distance less than the radius of a
+granular particle.  In any of these cases, when a particle gets very
+close to the center of the mixer it will interact with both nearby
+line segments as expected.
+
+See the next section on connectivity for how two triangles or line
+segemnts are treated if they share a common edge (triangle) or point
+(triange or line).
+
+----------
+
+Surface connectivity
+""""""""""""""""""""
+
+If multiple triangles/lines are used to define a contiguous surface
+which is flat or gently curved or has sharp edges or corners, LAMMPS
+will detect when two or more line segments (2d) share the same
+endpoint.  Or when two or more triangles (3d) share the same edge or
+same corner point.
+
+This connectivity is stored internally and is used when appropriate to
+calculate accurate forces on particles which simultaneously overlap
+with 2 or more connected triangles or line segments.
+
+Consider the simulation model of the previous section for a 2d mixer
+now defined by *local* line segments.  The flat surface of each mixer
+blade (and container box faces) is defined by multiple small line
+segments.  It is imporant that these line segments be "connected" so
+that when a particle contacts two adjacent line segments at the same
+time, the resulting force on the particle is the same as it would be
+if it were contacting the middle of a single long line segment.
+
+Here is how to ensure that LAMMPS detects the appropriate connections.
+
+For either *global* or *local* surfaces, if the triangles/lines are
+defined in a molecule or STL file, then 3 corner points (triangle) or
+2 end points (line) will be listed for each triangle/line in the file.
+LAMMPS will only make a connection between 2 triangles or lines if a
+shared point is EXACTLY the same in both.  This is a single point in
+both for a corner point or end point connection.  It is two points in
+both triangles for an edge connection.
+
+For *local* surfaces, if the triangles/lines are defined in a data
+file, then 3 corner points (triangle) or 2 end points (line) will be
+listed for each triangle/line in the file.  However in this case,
+LAMMPS will allow for an INEXACT match of a shared point to make a
+connection between 2 triangles or lines.  Again, this is a single
+point in both for a corner point or end point connection.  It is two
+points in both triangles for an edge connection.
+
+An INEXACT match means that the two points can be EPSILON apart.
+EPSILON is defined as a tiny fraction (1.0e-4) of the size of
+the smallest triangle or line in the system.
+
+The reason INEXACT matches are allowed is that data files can be
+created in a variety of manners, including by LAMMPS itself as a
+simulation runs via the :doc:`write_data <write_data>` command.
+Interally, triangle-style and line-style particles do not store their
+corner points directly.  Instead, the center point of the
+triangle/line is stored, along with an orientation of the
+triangle/line and a displacement vector from the center point for each
+corner point.  This means that when new corner points values are
+written to a data file for two different triangles/line, they may
+differ by epsilon due to round-offs in finite-precision arithmetic.
+
+Note that due to how connectivity is defined, two triangles/lines will
+not be connected if their corner points are separted by even small
+distances (greater than EPSILON).  Likewise they will not be connected
+if the corner point of one triangle/line is very close to (or even on)
+the surface of another triangle or middle of another line segment.  In
+general these kinds of granular surfaces could be problematic and
+should be avoided, but LAMMPS does not check for these conditions.
+
+NOTE: maybe add a picture of T-shaped surf with 2 line segments (not
+3).  Explain why it could be bad?
+
+Note that if a triangle or line segment has a free edge or free
+corner/end point (not connected to any other triangle/line), granular
+particles will still interact with the triangle/line if the nearest
+contact point to the spherical particle center is on the free edge or
+is the free corner/end point.
+
+----------
+
+Surface motion
+""""""""""""""
+
+By default, surface triangles/lines are motionless during a
+simulation, whether they are *global* or *local*.  Triangles/lines
+impart forces and torques to granular particles, but the inverse
+forces/torques on the triangles/lines do not cause them to move.
+
+However, triangles/lines can be made to move in a prescribed manner.
+E.g. the rotation of 2d mixer blades in the example described above.
+These two commands can be used for that purpose:
+
+* :doc:`fix_modify move <fix_modify>` for *global* surfaces
+* :doc:`fix move <fix_move>` for *local* surfaces
+
+For *global* surfaces, the :doc:`fix_modify move <fix_modify>` command
+can move a specified subest of the triangles/lines in various ways
+(translation, rotation, etc).  Which triangles move is specified based
+on the *type* of each triangle.  Types are specified when surfaces are
+defined by the :doc:`fix surface/global <fix_surface_global>` command.
+They can also be defined by the :doc:`fix_modify typre/region
+<fix_modify>` command.
+
+For *local* surfaces, the :doc:`fix move <fix_move>` command can move
+a specified subset of the triangles/lines in various ways
+(translation, rotation, etc).  Which triangles move is specified based
+on the group-ID argument to the :doc:`fix move <fix_move>` command.
+Groups can be defined by the :doc:`group <group>` command.
+
+Note that for an object defined by two or more connected
+triangles/lines, it is an error to assign a motion and not include all
+the connected triangles/lines, since this would break the connections.
+LAMMPS does NOT check that this requirement is met.
+
+----------
+
+Example scripts
+"""""""""""""""
+
+The examples/gransurf directory has example input scripts which use
+both *global* and *local* surfaces.  Both 2d and 3d models are included.
+
+Each script produces a series of snapshot images using the :doc:`dump
+image <dump_image>` command.  The snapshots visualize both the
+particles and granular surfaces.  The snaphost can be animated to view
+a movie of the simulation.

doc/src/Howto_lammps_gui.rst

@@ -20,8 +20,11 @@ to the online LAMMPS documentation for known LAMMPS commands and styles.
    (Ubuntu 20.04LTS or later and compatible), macOS (version 11 aka Big
    Sur or later), and Windows (version 10 or later) :ref:`are available
    <lammps_gui_install>` for download.  Non-MPI LAMMPS executables (as
-   ``lmp``) for running LAMMPS from the command line and :doc:`some
+   ``lmp``) for running LAMMPS from the command-line and :doc:`some
    LAMMPS tools <Tools>` compiled executables are also included.
+   Also, the pre-compiled LAMMPS-GUI packages include the WHAM executables
+   from http://membrane.urmc.rochester.edu/content/wham/ for use with
+   LAMMPS tutorials.
 
    The source code for LAMMPS-GUI is included in the LAMMPS source code
    distribution and can be found in the ``tools/lammps-gui`` folder.  It
@@ -29,16 +32,16 @@ to the online LAMMPS documentation for known LAMMPS commands and styles.
    <Build_cmake>`.
 
 LAMMPS-GUI tries to provide an experience similar to what people
-traditionally would have running LAMMPS using a command line window and
+traditionally would have running LAMMPS using a command-line window and
 the console LAMMPS executable but just rolled into a single executable:
 
 - writing & editing LAMMPS input files with a text editor
-- run LAMMPS on those input file with selected command line flags
+- run LAMMPS on those input file with selected command-line flags
 - extract data from the created files and visualize it with and
   external software
 
 That procedure is quite effective for people proficient in using the
-command line, as that allows them to use tools for the individual steps
+command-line, as that allows them to use tools for the individual steps
 that they are most comfortable with.  In fact, it is often *required* to
 adopt this workflow when running LAMMPS simulations on high-performance
 computing facilities.
@@ -61,13 +64,18 @@ simple LAMMPS simulations.  It is very suitable for tutorials on LAMMPS
 since you only need to learn how to use a single program for most tasks
 and thus time can be saved and people can focus on learning LAMMPS.
 The tutorials at https://lammpstutorials.github.io/ are specifically
-updated for use with LAMMPS-GUI.
+updated for use with LAMMPS-GUI and can their tutorial materials can
+be downloaded and loaded directly from the GUI.
 
 Another design goal is to keep the barrier low when replacing part of
 the functionality of LAMMPS-GUI with external tools.  That said, LAMMPS-GUI
 has some unique functionality that is not found elsewhere:
 
 - auto-adapting to features available in the integrated LAMMPS library
+- auto-completion for LAMMPS commands and options
+- context-sensitive online help
+- start and stop of simulations via mouse or keyboard
+- monitoring of simulation progress
 - interactive visualization using the :doc:`dump image <dump_image>`
   command with the option to copy-paste the resulting settings
 - automatic slide show generation from dump image out at runtime
@@ -100,10 +108,11 @@ MacOS 11 and later
 ^^^^^^^^^^^^^^^^^^
 
 After downloading the ``LAMMPS-macOS-multiarch-GUI-<version>.dmg``
-installer package, you need to double-click it and then, in the window
-that opens, drag the app bundle as indicated into the "Applications"
-folder.  The follow the instructions in the "README.txt" file to
-get access to the other included executables.
+application bundle disk image, you need to double-click it and then, in
+the window that opens, drag the app bundle as indicated into the
+"Applications" folder.  Afterwards, the disk image can be unmounted.
+Then follow the instructions in the "README.txt" file to get access to
+the other included command-line executables.
 
 Linux on x86\_64
 ^^^^^^^^^^^^^^^^
@@ -117,15 +126,25 @@ into the "LAMMPS_GUI" folder and execute "./lammps-gui" directly.
 
 The second variant uses `flatpak <https://www.flatpak.org>`_ and
 requires the flatpak management and runtime software to be installed.
-After downloading the ``LAMMPS-GUI-Linux-x86_64-GUI-<version>.tar.gz``
+After downloading the ``LAMMPS-GUI-Linux-x86_64-GUI-<version>.flatpak``
 flatpak bundle, you can install it with ``flatpak install --user
-LAMMPS-GUI-Linux-x86_64-GUI-<version>.tar.gz``.  After installation,
+LAMMPS-GUI-Linux-x86_64-GUI-<version>.flatpak``.  After installation,
 LAMMPS-GUI should be integrated into your desktop environment under
 "Applications > Science" but also can be launched from the console with
 ``flatpak run org.lammps.lammps-gui``.  The flatpak bundle also includes
 the console LAMMPS executable ``lmp`` which can be launched to run
-simulations with, for example: ``flatpak run --command=lmp
-org.lammps.lammps-gui -in in.melt``.
+simulations with, for example with:
+
+.. code-block:: sh
+
+   flatpak run --command=lmp org.lammps.lammps-gui -in in.melt
+
+Other bundled command-line executables are run the same way and can be
+listed with:
+
+.. code-block:: sh
+
+   ls $(flatpak info --show-location org.lammps.lammps-gui )/files/bin
 
 
 Compiling from Source
@@ -165,9 +184,9 @@ window is stored when exiting and restored when starting again.
 Opening Files
 ^^^^^^^^^^^^^
 
-The LAMMPS-GUI application can be launched without command line arguments
+The LAMMPS-GUI application can be launched without command-line arguments
 and then starts with an empty buffer in the *Editor* window.  If arguments
-are given LAMMPS will use first command line argument as the file name for
+are given LAMMPS will use first command-line argument as the file name for
 the *Editor* buffer and reads its contents into the buffer, if the file
 exists.  All further arguments are ignored.  Files can also be opened via
 the *File* menu, the `Ctrl-O` (`Command-O` on macOS) keyboard shortcut
@@ -261,14 +280,21 @@ Output Window
 
 By default, when starting a run, an *Output* window opens that displays
 the screen output of the running LAMMPS calculation, as shown below.
-This text would normally be seen in the command line window.
+This text would normally be seen in the command-line window.
 
 .. image:: JPG/lammps-gui-log.png
    :align: center
    :scale: 50%
 
 LAMMPS-GUI captures the screen output from LAMMPS as it is generated and
-updates the *Output* window regularly during a run.
+updates the *Output* window regularly during a run.  If there are any
+warnings or errors in the LAMMPS output, they are highlighted by using
+bold text colored in red.  There is a small panel at the bottom center
+of the *Output* window showing how many warnings and errors were
+detected and how many lines the entire output has.  By clicking on the
+button on the right with the warning symbol or by using the keyboard
+shortcut `Ctrl-N` (`Command-N` on macOS), you can jump to the next
+line with a warning or error.
 
 By default, the *Output* window is replaced each time a run is started.
 The runs are counted and the run number for the current run is displayed
@@ -398,7 +424,7 @@ below.
 Like for the *Output* and *Charts* windows, its content is continuously
 updated during a run.  It will show "(none)" if there are no variables
 defined.  Note that it is also possible to *set* :doc:`index style
-variables <variable>`, that would normally be set via command line
+variables <variable>`, that would normally be set via command-line
 flags, via the "Set Variables..." dialog from the *Run* menu.
 LAMMPS-GUI automatically defines the variable "gui_run" to the current
 value of the run counter.  That way it is possible to automatically
@@ -775,11 +801,11 @@ General Settings:
 
 - *Echo input to log:* when checked, all input commands, including
   variable expansions, are echoed to the *Output* window. This is
-  equivalent to using `-echo screen` at the command line.  There is no
+  equivalent to using `-echo screen` at the command-line.  There is no
   log *file* produced by default, since LAMMPS-GUI uses `-log none`.
 - *Include citation details:* when checked full citation info will be
   included to the log window.  This is equivalent to using `-cite
-  screen` on the command line.
+  screen` on the command-line.
 - *Show log window by default:* when checked, the screen output of a
   LAMMPS run will be collected in a log window during the run
 - *Show chart window by default:* when checked, the thermodynamic
@@ -828,7 +854,7 @@ Accelerators:
 
 This tab enables selection of an accelerator package for LAMMPS to use
 and is equivalent to using the `-suffix` and `-package` flags on the
-command line.  Only settings supported by the LAMMPS library and local
+command-line.  Only settings supported by the LAMMPS library and local
 hardware are available.  The `Number of threads` field allows setting
 the maximum number of threads for the accelerator packages that use
 threads.

doc/src/Howto_peri.rst

@@ -738,8 +738,8 @@ command.
 
 This can be done, for example, by using the built-in visualizer of the
 :doc:`dump image or dump movie <dump_image>` command to create snapshot
-images or a movie. Below are example command lines for using dump image
-with the :ref:`example listed below <periexample>` and a set of images
+images or a movie. Below are example command for using dump image with
+the :ref:`example listed below <periexample>` and a set of images
 created for steps 300, 600, and 2000 this way.
 
 .. code-block:: LAMMPS

doc/src/Howto_pylammps.rst

@@ -1,562 +1,6 @@
 PyLammps Tutorial
 =================
 
-.. contents::
-
-Overview
---------
-
-:py:class:`PyLammps <lammps.PyLammps>` is a Python wrapper class for
-LAMMPS which can be created on its own or use an existing
-:py:class:`lammps Python <lammps.lammps>` object.  It creates a simpler,
-more "pythonic" interface to common LAMMPS functionality, in contrast to
-the :py:class:`lammps <lammps.lammps>` wrapper for the LAMMPS :ref:`C
-language library interface API <lammps_c_api>` which is written using
-`Python ctypes <ctypes_>`_.  The :py:class:`lammps <lammps.lammps>`
-wrapper is discussed on the :doc:`Python_head` doc page.
-
-Unlike the flat `ctypes <ctypes_>`_ interface, PyLammps exposes a
-discoverable API.  It no longer requires knowledge of the underlying C++
-code implementation.  Finally, the :py:class:`IPyLammps
-<lammps.IPyLammps>` wrapper builds on top of :py:class:`PyLammps
-<lammps.PyLammps>` and adds some additional features for `IPython
-integration <ipython_>`_ into `Jupyter notebooks <jupyter_>`_, e.g. for
-embedded visualization output from :doc:`dump style image <dump_image>`.
-
-.. _ctypes: https://docs.python.org/3/library/ctypes.html
-.. _ipython: https://ipython.org/
-.. _jupyter: https://jupyter.org/
-
-Comparison of lammps and PyLammps interfaces
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-lammps.lammps
-"""""""""""""
-
-* uses `ctypes <ctypes_>`_
-* direct memory access to native C++ data with optional support for NumPy arrays
-* provides functions to send and receive data to LAMMPS
-* interface modeled after the LAMMPS :ref:`C language library interface API <lammps_c_api>`
-* requires knowledge of how LAMMPS internally works (C pointers, etc)
-* full support for running Python with MPI using `mpi4py <https://mpi4py.readthedocs.io>`_
-
-lammps.PyLammps
-"""""""""""""""
-
-* higher-level abstraction built on *top* of original :py:class:`ctypes based interface <lammps.lammps>`
-* manipulation of Python objects
-* communication with LAMMPS is hidden from API user
-* shorter, more concise Python
-* better IPython integration, designed for quick prototyping
-* designed for serial execution
-
-Quick Start
------------
-
-System-wide Installation
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-Step 1: Building LAMMPS as a shared library
-"""""""""""""""""""""""""""""""""""""""""""
-
-To use LAMMPS inside of Python it has to be compiled as shared
-library. This library is then loaded by the Python interface. In this
-example we enable the MOLECULE package and compile LAMMPS with PNG, JPEG
-and FFMPEG output support enabled.
-
-Step 1a: For the CMake based build system, the steps are:
-
-.. code-block:: bash
-
-   mkdir $LAMMPS_DIR/build-shared
-   cd  $LAMMPS_DIR/build-shared
-
-   # MPI, PNG, Jpeg, FFMPEG are auto-detected
-   cmake ../cmake -DPKG_MOLECULE=yes -DBUILD_LIB=yes -DBUILD_SHARED_LIBS=yes
-   make
-
-Step 1b: For the legacy, make based build system, the steps are:
-
-.. code-block:: bash
-
-   cd $LAMMPS_DIR/src
-
-   # add packages if necessary
-   make yes-MOLECULE
-
-   # compile shared library using Makefile
-   make mpi mode=shlib LMP_INC="-DLAMMPS_PNG -DLAMMPS_JPEG -DLAMMPS_FFMPEG" JPG_LIB="-lpng -ljpeg"
-
-Step 2: Installing the LAMMPS Python package
-""""""""""""""""""""""""""""""""""""""""""""
-
-PyLammps is part of the lammps Python package. To install it simply install
-that package into your current Python installation with:
-
-.. code-block:: bash
-
-   make install-python
-
-.. note::
-
-   Recompiling the shared library requires re-installing the Python package
-
-Installation inside of a virtualenv
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-You can use virtualenv to create a custom Python environment specifically tuned
-for your workflow.
-
-Benefits of using a virtualenv
-""""""""""""""""""""""""""""""
-
-* isolation of your system Python installation from your development installation
-* installation can happen in your user directory without root access (useful for HPC clusters)
-* installing packages through pip allows you to get newer versions of packages than e.g., through apt-get or yum package managers (and without root access)
-* you can even install specific old versions of a package if necessary
-
-**Prerequisite (e.g. on Ubuntu)**
-
-.. code-block:: bash
-
-   apt-get install python-virtualenv
-
-Creating a virtualenv with lammps installed
-"""""""""""""""""""""""""""""""""""""""""""
-
-.. code-block:: bash
-
-   # create virtualenv named 'testing'
-   virtualenv $HOME/python/testing
-
-   # activate 'testing' environment
-   source $HOME/python/testing/bin/activate
-
-Now configure and compile the LAMMPS shared library as outlined above.
-When using CMake and the shared library has already been build, you
-need to re-run CMake to update the location of the python executable
-to the location in the virtual environment with:
-
-.. code-block:: bash
-
-   cmake . -DPython_EXECUTABLE=$(which python)
-
-   # install LAMMPS package in virtualenv
-   (testing) make install-python
-
-   # install other useful packages
-   (testing) pip install matplotlib jupyter mpi4py
-
-   ...
-
-   # return to original shell
-   (testing) deactivate
-
-Creating a new instance of PyLammps
------------------------------------
-
-To create a PyLammps object you need to first import the class from the lammps
-module. By using the default constructor, a new *lammps* instance is created.
-
-.. code-block:: python
-
-   from lammps import PyLammps
-   L = PyLammps()
-
-You can also initialize PyLammps on top of this existing *lammps* object:
-
-.. code-block:: python
-
-   from lammps import lammps, PyLammps
-   lmp = lammps()
-   L = PyLammps(ptr=lmp)
-
-Commands
---------
-
-Sending a LAMMPS command with the existing library interfaces is done using
-the command method of the lammps object instance.
-
-For instance, let's take the following LAMMPS command:
-
-.. code-block:: LAMMPS
-
-   region box block 0 10 0 5 -0.5 0.5
-
-In the original interface this command can be executed with the following
-Python code if *L* was a lammps instance:
-
-.. code-block:: python
-
-   L.command("region box block 0 10 0 5 -0.5 0.5")
-
-With the PyLammps interface, any command can be split up into arbitrary parts
-separated by white-space, passed as individual arguments to a region method.
-
-.. code-block:: python
-
-   L.region("box block", 0, 10, 0, 5, -0.5, 0.5)
-
-Note that each parameter is set as Python literal floating-point number. In the
-PyLammps interface, each command takes an arbitrary parameter list and transparently
-merges it to a single command string, separating individual parameters by white-space.
-
-The benefit of this approach is avoiding redundant command calls and easier
-parameterization. In the original interface parameterization needed to be done
-manually by creating formatted strings.
-
-.. code-block:: python
-
-   L.command("region box block %f %f %f %f %f %f" % (xlo, xhi, ylo, yhi, zlo, zhi))
-
-In contrast, methods of PyLammps accept parameters directly and will convert
-them automatically to a final command string.
-
-.. code-block:: python
-
-   L.region("box block", xlo, xhi, ylo, yhi, zlo, zhi)
-
-System state
-------------
-
-In addition to dispatching commands directly through the PyLammps object, it
-also provides several properties which allow you to query the system state.
-
-L.system
-   Is a dictionary describing the system such as the bounding box or number of atoms
-
-L.system.xlo, L.system.xhi
-   bounding box limits along x-axis
-
-L.system.ylo, L.system.yhi
-   bounding box limits along y-axis
-
-L.system.zlo, L.system.zhi
-   bounding box limits along z-axis
-
-L.communication
-   configuration of communication subsystem, such as the number of threads or processors
-
-L.communication.nthreads
-   number of threads used by each LAMMPS process
-
-L.communication.nprocs
-   number of MPI processes used by LAMMPS
-
-L.fixes
-   List of fixes in the current system
-
-L.computes
-   List of active computes in the current system
-
-L.dump
-   List of active dumps in the current system
-
-L.groups
-   List of groups present in the current system
-
-Working with LAMMPS variables
------------------------------
-
-LAMMPS variables can be both defined and accessed via the PyLammps interface.
-
-To define a variable you can use the :doc:`variable <variable>` command:
-
-.. code-block:: python
-
-   L.variable("a index 2")
-
-A dictionary of all variables is returned by L.variables
-
-you can access an individual variable by retrieving a variable object from the
-L.variables dictionary by name
-
-.. code-block:: python
-
-   a = L.variables['a']
-
-The variable value can then be easily read and written by accessing the value
-property of this object.
-
-.. code-block:: python
-
-   print(a.value)
-   a.value = 4
-
-Retrieving the value of an arbitrary LAMMPS expressions
--------------------------------------------------------
-
-LAMMPS expressions can be immediately evaluated by using the eval method. The
-passed string parameter can be any expression containing global thermo values,
-variables, compute or fix data.
-
-.. code-block:: python
-
-   result = L.eval("ke") # kinetic energy
-   result = L.eval("pe") # potential energy
-
-   result = L.eval("v_t/2.0")
-
-Accessing atom data
--------------------
-
-All atoms in the current simulation can be accessed by using the L.atoms list.
-Each element of this list is an object which exposes its properties (id, type,
-position, velocity, force, etc.).
-
-.. code-block:: python
-
-   # access first atom
-   L.atoms[0].id
-   L.atoms[0].type
-
-   # access second atom
-   L.atoms[1].position
-   L.atoms[1].velocity
-   L.atoms[1].force
-
-Some properties can also be used to set:
-
-.. code-block:: python
-
-   # set position in 2D simulation
-   L.atoms[0].position = (1.0, 0.0)
-
-   # set position in 3D simulation
-   L.atoms[0].position = (1.0, 0.0, 1.)
-
-Evaluating thermo data
-----------------------
-
-Each simulation run usually produces thermo output based on system state,
-computes, fixes or variables. The trajectories of these values can be queried
-after a run via the L.runs list. This list contains a growing list of run data.
-The first element is the output of the first run, the second element that of
-the second run.
-
-.. code-block:: python
-
-   L.run(1000)
-   L.runs[0] # data of first 1000 time steps
-
-   L.run(1000)
-   L.runs[1] # data of second 1000 time steps
-
-Each run contains a dictionary of all trajectories. Each trajectory is
-accessible through its thermo name:
-
-.. code-block:: python
-
-   L.runs[0].thermo.Step # list of time steps in first run
-   L.runs[0].thermo.Ke   # list of kinetic energy values in first run
-
-Together with matplotlib plotting data out of LAMMPS becomes simple:
-
-.. code-block:: python
-
-   import matplotlib.plot as plt
-   steps = L.runs[0].thermo.Step
-   ke    = L.runs[0].thermo.Ke
-   plt.plot(steps, ke)
-
-Error handling with PyLammps
-----------------------------
-
-Using C++ exceptions in LAMMPS for errors allows capturing them on the
-C++ side and rethrowing them on the Python side.  This way you can handle
-LAMMPS errors through the Python exception handling mechanism.
-
-.. warning::
-
-   Capturing a LAMMPS exception in Python can still mean that the
-   current LAMMPS process is in an illegal state and must be
-   terminated. It is advised to save your data and terminate the Python
-   instance as quickly as possible.
-
-Using PyLammps in IPython notebooks and Jupyter
------------------------------------------------
-
-If the LAMMPS Python package is installed for the same Python interpreter as
-IPython, you can use PyLammps directly inside of an IPython notebook inside of
-Jupyter. Jupyter is a powerful integrated development environment (IDE) for
-many dynamic languages like Python, Julia and others, which operates inside of
-any web browser. Besides auto-completion and syntax highlighting it allows you
-to create formatted documents using Markup, mathematical formulas, graphics and
-animations intermixed with executable Python code. It is a great format for
-tutorials and showcasing your latest research.
-
-To launch an instance of Jupyter simply run the following command inside your
-Python environment (this assumes you followed the Quick Start instructions):
-
-.. code-block:: bash
-
-   jupyter notebook
-
-IPyLammps Examples
-------------------
-
-Examples of IPython notebooks can be found in the python/examples/pylammps
-subdirectory. To open these notebooks launch *jupyter notebook* inside this
-directory and navigate to one of them. If you compiled and installed
-a LAMMPS shared library with exceptions, PNG, JPEG and FFMPEG support
-you should be able to rerun all of these notebooks.
-
-Validating a dihedral potential
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This example showcases how an IPython Notebook can be used to compare a simple
-LAMMPS simulation of a harmonic dihedral potential to its analytical solution.
-Four atoms are placed in the simulation and the dihedral potential is applied on
-them using a datafile. Then one of the atoms is rotated along the central axis by
-setting its position from Python, which changes the dihedral angle.
-
-.. code-block:: python
-
-   phi = [d \* math.pi / 180 for d in range(360)]
-
-   pos = [(1.0, math.cos(p), math.sin(p)) for p in phi]
-
-   pe = []
-   for p in pos:
-       L.atoms[3].position = p
-       L.run(0)
-       pe.append(L.eval("pe"))
-
-By evaluating the potential energy for each position we can verify that
-trajectory with the analytical formula.  To compare both solutions, we plot
-both trajectories over each other using matplotlib, which embeds the generated
-plot inside the IPython notebook.
-
-.. image:: JPG/pylammps_dihedral.jpg
-   :align: center
-
-Running a Monte Carlo relaxation
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This second example shows how to use PyLammps to create a 2D Monte Carlo Relaxation
-simulation, computing and plotting energy terms and even embedding video output.
-
-Initially, a 2D system is created in a state with minimal energy.
-
-.. image:: JPG/pylammps_mc_minimum.jpg
-   :align: center
-
-It is then disordered by moving each atom by a random delta.
-
-.. code-block:: python
-
-   random.seed(27848)
-   deltaperturb = 0.2
-
-   for i in range(L.system.natoms):
-       x, y = L.atoms[i].position
-       dx = deltaperturb \* random.uniform(-1, 1)
-       dy = deltaperturb \* random.uniform(-1, 1)
-       L.atoms[i].position  = (x+dx, y+dy)
-
-   L.run(0)
-
-.. image:: JPG/pylammps_mc_disordered.jpg
-   :align: center
-
-Finally, the Monte Carlo algorithm is implemented in Python. It continuously
-moves random atoms by a random delta and only accepts certain moves.
-
-.. code-block:: python
-
-   estart = L.eval("pe")
-   elast = estart
-
-   naccept = 0
-   energies = [estart]
-
-   niterations = 3000
-   deltamove = 0.1
-   kT = 0.05
-
-   natoms = L.system.natoms
-
-   for i in range(niterations):
-       iatom = random.randrange(0, natoms)
-       current_atom = L.atoms[iatom]
-
-       x0, y0 = current_atom.position
-
-       dx = deltamove \* random.uniform(-1, 1)
-       dy = deltamove \* random.uniform(-1, 1)
-
-       current_atom.position = (x0+dx, y0+dy)
-
-       L.run(1, "pre no post no")
-
-       e = L.eval("pe")
-       energies.append(e)
-
-       if e <= elast:
-           naccept += 1
-           elast = e
-       elif random.random() <= math.exp(natoms\*(elast-e)/kT):
-           naccept += 1
-           elast = e
-       else:
-           current_atom.position = (x0, y0)
-
-The energies of each iteration are collected in a Python list and finally plotted using matplotlib.
-
-.. image:: JPG/pylammps_mc_energies_plot.jpg
-   :align: center
-
-The IPython notebook also shows how to use dump commands and embed video files
-inside of the IPython notebook.
-
-Using PyLammps and mpi4py (Experimental)
-----------------------------------------
-
-PyLammps can be run in parallel using `mpi4py
-<https://mpi4py.readthedocs.io>`_. This python package can be installed
-using
-
-.. code-block:: bash
-
-   pip install mpi4py
-
-.. warning::
-
-   Usually, any :py:class:`PyLammps <lammps.PyLammps>` command must be
-   executed by *all* MPI processes. However, evaluations and querying
-   the system state is only available on MPI rank 0.  Using these
-   functions from other MPI ranks will raise an exception.
-
-The following is a short example which reads in an existing LAMMPS input
-file and executes it in parallel.  You can find in.melt in the
-examples/melt folder.  Please take note that the
-:py:meth:`PyLammps.eval() <lammps.PyLammps.eval>` is called only from
-MPI rank 0.
-
-.. code-block:: python
-
-   from mpi4py import MPI
-   from lammps import PyLammps
-
-   L = PyLammps()
-   L.file("in.melt")
-
-   if MPI.COMM_WORLD.rank == 0:
-       print("Potential energy: ", L.eval("pe"))
-
-   MPI.Finalize()
-
-To run this script (melt.py) in parallel using 4 MPI processes we invoke the
-following mpirun command:
-
-.. code-block:: bash
-
-   mpirun -np 4 python melt.py
-
-Feedback and Contributing
--------------------------
-
-If you find this Python interface useful, please feel free to provide feedback
-and ideas on how to improve it to Richard Berger (richard.berger@outlook.com). We also
-want to encourage people to write tutorial style IPython notebooks showcasing LAMMPS usage
-and maybe their latest research results.
+The PyLammps interface is deprecated and will be removed in a future release of
+LAMMPS. As such, the PyLammps version of this tutorial has been removed and is
+replaced by the :doc:`Python_head`.

doc/src/Howto_python.rst

@@ -0,0 +1,441 @@
+LAMMPS Python Tutorial
+======================
+
+.. contents::
+
+-----
+
+Overview
+--------
+
+The :py:class:`lammps <lammps.lammps>` Python module is a wrapper class for the
+LAMMPS :ref:`C language library interface API <lammps_c_api>` which is written using
+`Python ctypes <ctypes_>`_.  The design choice of this wrapper class is to
+follow the C language API closely with only small changes related to Python
+specific requirements and to better accommodate object oriented programming.
+
+In addition to this flat `ctypes <ctypes_>`_ interface, the
+:py:class:`lammps <lammps.lammps>` wrapper class exposes a discoverable
+API that doesn't require as much knowledge of the underlying C language
+library interface or LAMMPS C++ code implementation.
+
+Finally, the API exposes some additional features for `IPython integration
+<ipython_>`_ into `Jupyter notebooks <jupyter_>`_, e.g. for embedded
+visualization output from :doc:`dump style image <dump_image>`.
+
+.. _ctypes: https://docs.python.org/3/library/ctypes.html
+.. _ipython: https://ipython.org/
+.. _jupyter: https://jupyter.org/
+
+-----
+
+Quick Start
+-----------
+
+System-wide or User Installation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Step 1: Building LAMMPS as a shared library
+"""""""""""""""""""""""""""""""""""""""""""
+
+To use LAMMPS inside of Python it has to be compiled as shared library.
+This library is then loaded by the Python interface.  In this example we
+enable the :ref:`MOLECULE package <PKG-MOLECULE>` and compile LAMMPS
+with :ref:`PNG, JPEG and FFMPEG output support <graphics>` enabled.
+
+.. tabs::
+
+   .. tab:: CMake build
+
+      .. code-block:: bash
+
+         mkdir $LAMMPS_DIR/build-shared
+         cd  $LAMMPS_DIR/build-shared
+
+         # MPI, PNG, Jpeg, FFMPEG are auto-detected
+         cmake ../cmake -DPKG_MOLECULE=yes -DPKG_PYTHON=on -DBUILD_SHARED_LIBS=yes
+         make
+
+   .. tab:: Traditional make
+
+      .. code-block:: bash
+
+         cd $LAMMPS_DIR/src
+
+         # add packages if necessary
+         make yes-MOLECULE
+         make yes-PYTHON
+
+         # compile shared library using Makefile
+         make mpi mode=shlib LMP_INC="-DLAMMPS_PNG -DLAMMPS_JPEG -DLAMMPS_FFMPEG" JPG_LIB="-lpng -ljpeg"
+
+Step 2: Installing the LAMMPS Python package
+""""""""""""""""""""""""""""""""""""""""""""
+
+Next install the LAMMPS Python package into your current Python installation with:
+
+.. code-block:: bash
+
+   make install-python
+
+This will create a so-called `"wheel"
+<https://packaging.python.org/en/latest/discussions/package-formats/#what-is-a-wheel>`_
+and then install the LAMMPS Python module from that "wheel" into either
+into a system folder (provided the command is executed with root
+privileges) or into your personal Python module folder.
+
+.. note::
+
+   Recompiling the shared library requires re-installing the Python
+   package.
+
+Installation inside of a virtual environment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+You can use virtual environments to create a custom Python environment
+specifically tuned for your workflow.
+
+Benefits of using a virtualenv
+""""""""""""""""""""""""""""""
+
+* isolation of your system Python installation from your development installation
+* installation can happen in your user directory without root access (useful for HPC clusters)
+* installing packages through pip allows you to get newer versions of packages than e.g., through apt-get or yum package managers (and without root access)
+* you can even install specific old versions of a package if necessary
+
+**Prerequisite (e.g. on Ubuntu)**
+
+.. code-block:: bash
+
+   apt-get install python-venv
+
+Creating a virtualenv with lammps installed
+"""""""""""""""""""""""""""""""""""""""""""
+
+.. code-block:: bash
+
+   # create virtual envrionment named 'testing'
+   python3 -m venv $HOME/python/testing
+
+   # activate 'testing' environment
+   source $HOME/python/testing/bin/activate
+
+Now configure and compile the LAMMPS shared library as outlined above.
+When using CMake and the shared library has already been build, you
+need to re-run CMake to update the location of the python executable
+to the location in the virtual environment with:
+
+.. code-block:: bash
+
+   cmake . -DPython_EXECUTABLE=$(which python)
+
+   # install LAMMPS package in virtualenv
+   (testing) make install-python
+
+   # install other useful packages
+   (testing) pip install matplotlib jupyter mpi4py pandas
+
+   ...
+
+   # return to original shell
+   (testing) deactivate
+
+-------
+
+Creating a new lammps instance
+------------------------------
+
+To create a lammps object you need to first import the class from the lammps
+module. By using the default constructor, a new :py:class:`lammps
+<lammps.lammps>` instance is created.
+
+.. code-block:: python
+
+   from lammps import lammps
+   L = lammps()
+
+See the :doc:`LAMMPS Python documentation <Python_create>` for how to customize
+the instance creation with optional arguments.
+
+-----
+
+Commands
+--------
+
+Sending a LAMMPS command with the library interface is done using
+the ``command`` method of the lammps object.
+
+For instance, let's take the following LAMMPS command:
+
+.. code-block:: LAMMPS
+
+   region box block 0 10 0 5 -0.5 0.5
+
+This command can be executed with the following Python code if ``L`` is a ``lammps``
+instance:
+
+.. code-block:: python
+
+   L.command("region box block 0 10 0 5 -0.5 0.5")
+
+For convenience, the ``lammps`` class also provides a command wrapper ``cmd``
+that turns any LAMMPS command into a regular function call:
+
+.. code-block:: python
+
+   L.cmd.region("box block", 0, 10, 0, 5, -0.5, 0.5)
+
+Note that each parameter is set as Python number literal. With
+the wrapper each command takes an arbitrary parameter list and transparently
+merges it to a single command string, separating individual parameters by
+white-space.
+
+The benefit of this approach is avoiding redundant command calls and easier
+parameterization. With the ``command`` function each call needs to be assembled
+manually using formatted strings.
+
+.. code-block:: python
+
+   L.command(f"region box block {xlo} {xhi} {ylo} {yhi} {zlo} {zhi}")
+
+The wrapper accepts parameters directly and will convert
+them automatically to a final command string.
+
+.. code-block:: python
+
+   L.cmd.region("box block", xlo, xhi, ylo, yhi, zlo, zhi)
+
+.. note::
+
+   When running in IPython you can use Tab-completion after ``L.cmd.`` to see
+   all available LAMMPS commands.
+
+-----
+
+Accessing atom data
+-------------------
+
+All per-atom properties that are part of the :doc:`atom style
+<atom_style>` in the current simulation can be accessed using the
+:py:meth:`extract_atoms() <lammps.lammps.extract_atoms()>` method.  This
+can be retrieved as ctypes objects or as NumPy arrays through the
+lammps.numpy module.  Those represent the *local* atoms of the
+individual sub-domain for the current MPI process and may contain
+information for the local ghost atoms or not depending on the property.
+Both can be accessed as lists, but for the ctypes list object the size
+is not known and hast to be retrieved first to avoid out-of-bounds
+accesses.
+
+.. code-block:: python
+
+   nlocal = L.extract_setting("nlocal")
+   nall = L.extract_setting("nall")
+   print("Number of local atoms ", nlocal, "  Number of local and ghost atoms ", nall);
+
+   # access via ctypes directly
+   atom_id = L.extract_atom("id")
+   print("Atom IDs", atom_id[0:nlocal])
+
+   # access through numpy wrapper
+   atom_type = L.numpy.extract_atom("type")
+   print("Atom types", atom_type)
+
+   x = L.numpy.extract_atom("x")
+   v = L.numpy.extract_atom("v")
+   print("positions array shape", x.shape)
+   print("velocity array shape", v.shape)
+   # turn on communicating velocities to ghost atoms
+   L.cmd.comm_modify("vel", "yes")
+   v = L.numpy.extract_atom('v')
+   print("velocity array shape", v.shape)
+
+Some properties can also be set from Python since internally the
+data of the C++ code is accessed directly:
+
+.. code-block:: python
+
+   # set position in 2D simulation
+   x[0] = (1.0, 0.0)
+
+   # set position in 3D simulation
+   x[0] = (1.0, 0.0, 1.)
+
+------
+
+Retrieving the values of thermodynamic data and variables
+---------------------------------------------------------
+
+To access thermodynamic data from the last completed timestep,
+you can use the :py:meth:`get_thermo() <lammps.lammps.get_thermo>`
+method, and to extract the value of (compatible) variables, you
+can use the :py:meth:`extract_variable() <lammps.lammps.extract_variable>`
+method.
+
+.. code-block:: python
+
+   result = L.get_thermo("ke") # kinetic energy
+   result = L.get_thermo("pe") # potential energy
+
+   result = L.extract_variable("t") / 2.0
+
+Error handling
+--------------
+
+We are using C++ exceptions in LAMMPS for errors and the C language
+library interface captures and records them.  This allows checking
+whether errors have happened in Python during a call into LAMMPS and
+then re-throw the error as a Python exception.  This way you can handle
+LAMMPS errors in the conventional way through the Python exception
+handling mechanism.
+
+.. warning::
+
+   Capturing a LAMMPS exception in Python can still mean that the
+   current LAMMPS process is in an illegal state and must be
+   terminated.  It is advised to save your data and terminate the Python
+   instance as quickly as possible.
+
+Using LAMMPS in IPython notebooks and Jupyter
+---------------------------------------------
+
+If the LAMMPS Python package is installed for the same Python
+interpreter as IPython, you can use LAMMPS directly inside of an IPython
+notebook inside of Jupyter. Jupyter is a powerful integrated development
+environment (IDE) for many dynamic languages like Python, Julia and
+others, which operates inside of any web browser.  Besides
+auto-completion and syntax highlighting it allows you to create
+formatted documents using Markup, mathematical formulas, graphics and
+animations intermixed with executable Python code.  It is a great format
+for tutorials and showcasing your latest research.
+
+To launch an instance of Jupyter simply run the following command inside your
+Python environment (this assumes you followed the Quick Start instructions):
+
+.. code-block:: bash
+
+   jupyter notebook
+
+Interactive Python Examples
+---------------------------
+
+Examples of IPython notebooks can be found in the ``python/examples/ipython``
+subdirectory. To open these notebooks launch ``jupyter notebook`` inside this
+directory and navigate to one of them. If you compiled and installed
+a LAMMPS shared library with PNG, JPEG and FFMPEG support
+you should be able to rerun all of these notebooks.
+
+Validating a dihedral potential
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This example showcases how an IPython Notebook can be used to compare a simple
+LAMMPS simulation of a harmonic dihedral potential to its analytical solution.
+Four atoms are placed in the simulation and the dihedral potential is applied on
+them using a datafile. Then one of the atoms is rotated along the central axis by
+setting its position from Python, which changes the dihedral angle.
+
+.. code-block:: python
+
+   phi = [d \* math.pi / 180 for d in range(360)]
+
+   pos = [(1.0, math.cos(p), math.sin(p)) for p in phi]
+
+   x = L.numpy.extract_atom("x")
+
+   pe = []
+   for p in pos:
+       x[3] = p
+       L.cmd.run(0, "post", "no")
+       pe.append(L.get_thermo("pe"))
+
+By evaluating the potential energy for each position we can verify that
+trajectory with the analytical formula.  To compare both solutions, we plot
+both trajectories over each other using matplotlib, which embeds the generated
+plot inside the IPython notebook.
+
+.. image:: JPG/pylammps_dihedral.jpg
+   :align: center
+
+Running a Monte Carlo relaxation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This second example shows how to use the `lammps` Python interface to create a
+2D Monte Carlo Relaxation simulation, computing and plotting energy terms and
+even embedding video output.
+
+Initially, a 2D system is created in a state with minimal energy.
+
+.. image:: JPG/pylammps_mc_minimum.jpg
+   :align: center
+
+It is then disordered by moving each atom by a random delta.
+
+.. code-block:: python
+
+   random.seed(27848)
+   deltaperturb = 0.2
+   x = L.numpy.extract_atom("x")
+   natoms = x.shape[0]
+
+   for i in range(natoms):
+       dx = deltaperturb \* random.uniform(-1, 1)
+       dy = deltaperturb \* random.uniform(-1, 1)
+       x[i][0] += dx
+       x[i][1] += dy
+
+   L.cmd.run(0, "post", "no")
+
+.. image:: JPG/pylammps_mc_disordered.jpg
+   :align: center
+
+Finally, the Monte Carlo algorithm is implemented in Python. It continuously
+moves random atoms by a random delta and only accepts certain moves.
+
+.. code-block:: python
+
+   estart = L.get_thermo("pe")
+   elast = estart
+
+   naccept = 0
+   energies = [estart]
+
+   niterations = 3000
+   deltamove = 0.1
+   kT = 0.05
+
+   for i in range(niterations):
+       x = L.numpy.extract_atom("x")
+       natoms = x.shape[0]
+       iatom = random.randrange(0, natoms)
+       current_atom = x[iatom]
+
+       x0 = current_atom[0]
+       y0 = current_atom[1]
+
+       dx = deltamove \* random.uniform(-1, 1)
+       dy = deltamove \* random.uniform(-1, 1)
+
+       current_atom[0] = x0 + dx
+       current_atom[1] = y0 + dy
+
+       L.cmd.run(1, "pre no post no")
+
+       e = L.get_thermo("pe")
+       energies.append(e)
+
+       if e <= elast:
+           naccept += 1
+           elast = e
+       elif random.random() <= math.exp(natoms\*(elast-e)/kT):
+           naccept += 1
+           elast = e
+       else:
+           current_atom[0] = x0
+           current_atom[1] = y0
+
+The energies of each iteration are collected in a Python list and finally plotted using matplotlib.
+
+.. image:: JPG/pylammps_mc_energies_plot.jpg
+   :align: center
+
+The IPython notebook also shows how to use dump commands and embed video files
+inside of the IPython notebook.

doc/src/Howto_rheo.rst

@@ -15,8 +15,9 @@ details of the system, or develop new capabilities. For instance, the numerics
 associated with calculating gradients, reproducing kernels, etc. are separated
 into distinct classes to simplify the development of new integration schemes
 which can call these calculations. Additional numerical details can be found in
-:ref:`(Clemmer) <howto_rheo_clemmer>`. Example movies illustrating some of these
-capabilities are found at https://www.lammps.org/movies.html#rheopackage.
+:ref:`(Palermo) <howto_rheo_palermo>` and :ref:`(Clemmer) <howto_rheo_clemmer>`.
+Example movies illustrating some of these capabilities are found at
+https://www.lammps.org/movies.html#rheopackage.
 
 Note, if you simply want to run a traditional SPH simulation, the :ref:`SPH package
 <PKG-SPH>` package is likely better suited for your application. It has fewer advanced
@@ -70,7 +71,7 @@ particles to solid (e.g. with the :doc:`set <set>` command), (b) create bpm
 bonds between the particles (see the :doc:`bpm howto <Howto_bpm>` page for
 more details), and (c) use :doc:`pair rheo/solid <pair_rheo_solid>` to
 apply repulsive contact forces between distinct solid bodies. Akin to pair rheo,
-pair rheo/solid considers a particles fluid/solid phase to determine whether to
+pair rheo/solid considers a particle's fluid/solid phase to determine whether to
 apply forces. However, unlike pair rheo, pair rheo/solid does obey special bond
 settings such that contact forces do not have to be calculated between two bonded
 solid particles in the same elastic body.
@@ -79,10 +80,10 @@ In systems with thermal evolution, fix rheo/thermal can optionally set a
 melting/solidification temperature allowing particles to dynamically swap their
 state between fluid and solid when the temperature exceeds or drops below the
 critical temperature, respectively. Using the *react* option, one can specify a maximum
-bond length and a bond type. Then, when solidifying, particles will search their
+bond length and a bond type. Then, when solidifying, particles search their
 local neighbors and automatically create bonds with any neighboring solid particles
-in range. For BPM bond styles, bonds will then use the immediate position of the two
-particles to calculate a reference state. When melting, particles will delete any
+in range. For BPM bond styles, bonds then use the immediate position of the two
+particles to calculate a reference state. When melting, particles delete any
 bonds of the specified type when reverting to a fluid state. Special bonds are updated
 as bonds are created/broken.
 
@@ -107,6 +108,10 @@ criteria for creating/deleting a bond or altering force calculations).
 
 ----------
 
+.. _howto_rheo_palermo:
+
+**(Palermo)** Palermo, Wolf, Clemmer, O'Connor, Phys. Fluids, 36, 113337 (2024).
+
 .. _howto_rheo_clemmer:
 
 **(Clemmer)** Clemmer, Pierce, O'Connor, Nevins, Jones, Lechman, Tencer, Appl. Math. Model., 130, 310-326 (2024).

doc/src/Howto_wsl.rst

@@ -260,7 +260,7 @@ Switch into the :code:`examples/melt` folder:
 
    cd ../examples/melt
 
-To run this example in serial, use the following command line:
+To run this example in serial, use the following command:
 
 .. code-block::
 

doc/src/Install_git.rst

@@ -60,7 +60,7 @@ between them at any time using "git checkout <branch name>".)
    files (mostly by accident).  If you do not need access to the entire
    commit history (most people don't), you can speed up the "cloning"
    process and reduce local disk space requirements by using the
-   ``--depth`` git command line flag.  That will create a "shallow clone"
+   ``--depth`` git command-line flag.  That will create a "shallow clone"
    of the repository, which contains only a subset of the git history.
    Using a depth of 1000 is usually sufficient to include the head
    commits of the *develop*, the *release*, and the *maintenance*

doc/src/Intro_authors.rst

@@ -8,6 +8,8 @@ send an email to all of them at this address: "developers at
 lammps.org".  General questions about LAMMPS should be posted in the
 `LAMMPS forum on MatSci <https://matsci.org/lammps/>`_.
 
+.. We need to keep this file in sync with https://www.lammps.org/authors.html
+
 .. raw:: latex
 
    \small
@@ -27,7 +29,7 @@ lammps.org".  General questions about LAMMPS should be posted in the
    * - `Steve Plimpton <sjp_>`_
      - SNL (retired)
      - sjplimp at gmail.com
-     - MD kernels, parallel algorithms & scalability, code structure and design
+     - original author, MD kernels, parallel algorithms & scalability, code structure and design
    * - `Aidan Thompson <at_>`_
      - SNL
      - athomps at sandia.gov
@@ -56,7 +58,7 @@ lammps.org".  General questions about LAMMPS should be posted in the
      - SNL
      - jmgoff at sandia.gov
      - machine learned potentials, QEq solvers, Python
-   * - Megan McCarthy
+   * - Meg McCarthy
      - SNL
      - megmcca at sandia.gov
      - alloys, micro-structure, machine learned potentials
@@ -67,7 +69,7 @@ lammps.org".  General questions about LAMMPS should be posted in the
    * - `Trung Nguyen <tn_>`_
      - U Chicago
      - ndactrung at gmail.com
-     - soft matter, GPU package
+     - soft matter, GPU package, DIELECTRIC package, regression testing
 
 .. _rb:  https://rbberger.github.io/
 .. _gc:  https://enthalpiste.fr/

doc/src/Intro_portability.rst

@@ -31,18 +31,19 @@ Operating systems
 ^^^^^^^^^^^^^^^^^
 
 The primary development platform for LAMMPS is Linux.  Thus, the chances
-for LAMMPS to compile without problems on Linux machines are the best.
+for LAMMPS to compile without problems are the best on Linux machines.
 Also, compilation and correct execution on macOS and Windows (using
-Microsoft Visual C++) is checked automatically for largest part of the
-source code.  Some (optional) features are not compatible with all
+Microsoft Visual C++) is checked automatically for the largest part of
+the source code.  Some (optional) features are not compatible with all
 operating systems, either through limitations of the corresponding
-LAMMPS source code or through source code or build system
-incompatibilities of required libraries.
+LAMMPS source code or through incompatibilities of source code or
+build system of required external libraries or packages.
 
 Executables for Windows may be created natively using either Cygwin or
 Visual Studio or with a Linux to Windows MinGW cross-compiler.
 
-Additionally, FreeBSD and Solaris have been tested successfully.
+Additionally, FreeBSD and Solaris have been tested successfully to
+run LAMMPS and produce results consistent with those on Linux.
 
 Compilers
 ^^^^^^^^^

doc/src/Library.rst

@@ -131,16 +131,15 @@ run LAMMPS in serial mode.
 
 .. _lammps_python_api:
 
-LAMMPS Python APIs
-==================
+LAMMPS Python API
+=================
 
 The LAMMPS Python module enables calling the LAMMPS C library API from
 Python by dynamically loading functions in the LAMMPS shared library through
 the `Python ctypes module <https://docs.python.org/3/library/ctypes.html>`_.
 Because of the dynamic loading, it is **required** that LAMMPS is compiled
 in :ref:`"shared" mode <exe>`.  The Python interface is object-oriented, but
-otherwise tries to be very similar to the C library API.  Three different
-Python classes to run LAMMPS are available and they build on each other.
+otherwise tries to be very similar to the C library API.
 More information on this is in the :doc:`Python_head`
 section of the manual.  Use of the LAMMPS Python module is described in
 :doc:`Python_module`.

doc/src/Library_atoms.rst

@@ -4,6 +4,7 @@ Per-atom properties
 This section documents the following functions:
 
 - :cpp:func:`lammps_extract_atom_datatype`
+- :cpp:func:`lammps_extract_atom_size`
 - :cpp:func:`lammps_extract_atom`
 
 -----------------------
@@ -13,6 +14,11 @@ This section documents the following functions:
 
 -----------------------
 
+.. doxygenfunction:: lammps_extract_atom_size
+   :project: progguide
+
+-----------------------
+
 .. doxygenfunction:: lammps_extract_atom
    :project: progguide
 

doc/src/Library_execute.rst

@@ -7,6 +7,7 @@ This section documents the following functions:
 - :cpp:func:`lammps_command`
 - :cpp:func:`lammps_commands_list`
 - :cpp:func:`lammps_commands_string`
+- :cpp:func:`lammps_expand`
 
 --------------------
 
@@ -79,3 +80,8 @@ Below is a short example using some of these functions.
 .. doxygenfunction:: lammps_commands_string
    :project: progguide
 
+-----------------------
+
+.. doxygenfunction:: lammps_expand
+   :project: progguide
+

doc/src/Library_objects.rst

@@ -1,5 +1,5 @@
-Compute, fixes, variables
-=========================
+Computes, fixes, variables
+==========================
 
 This section documents accessing or modifying data stored by computes,
 fixes, or variables in LAMMPS using the following functions:
@@ -12,6 +12,7 @@ fixes, or variables in LAMMPS using the following functions:
 - :cpp:func:`lammps_set_string_variable`
 - :cpp:func:`lammps_set_internal_variable`
 - :cpp:func:`lammps_variable_info`
+- :cpp:func:`lammps_eval`
 
 -----------------------
 
@@ -55,6 +56,11 @@ fixes, or variables in LAMMPS using the following functions:
 
 -----------------------
 
+.. doxygenfunction:: lammps_eval
+   :project: progguide
+
+-----------------------
+
 .. doxygenenum:: _LMP_DATATYPE_CONST
 
 .. doxygenenum:: _LMP_STYLE_CONST

doc/src/Modify_requirements.rst

@@ -208,20 +208,21 @@ Build system (strict)
 
 LAMMPS currently supports two build systems: one that is based on
 :doc:`traditional Makefiles <Build_make>` and one that is based on
-:doc:`CMake <Build_cmake>`.  Therefore, your contribution must be
-compatible with and support both build systems.
+:doc:`CMake <Build_cmake>`.  As of fall 2024, it is no longer required
+to support the traditional make build system.  New packages may choose
+to only support building with CMake.  Additions to existing packages
+must follow the requirements set by that package.
 
 For a single pair of header and implementation files that are an
 independent feature, it is usually only required to add them to
 ``src/.gitignore``.
 
 For traditional make, if your contributed files or package depend on
-other LAMMPS style files or packages also being installed
-(e.g. because your file is a derived class from the other LAMMPS
-class), then an ``Install.sh`` file is also needed to check for those
-dependencies and modifications to ``src/Depend.sh`` to trigger the checks.
-See other README and Install.sh files in other directories as
-examples.
+other LAMMPS style files or packages also being installed (e.g. because
+your file is a derived class from the other LAMMPS class), then an
+``Install.sh`` file is also needed to check for those dependencies and
+modifications to ``src/Depend.sh`` to trigger the checks.  See other
+README and Install.sh files in other directories as examples.
 
 Similarly, for CMake support, changes may need to be made to
 ``cmake/CMakeLists.txt``, some of the files in ``cmake/presets``, and

doc/src/Modify_style.rst

@@ -46,7 +46,7 @@ Include files (varied)
   but instead should be initialized either in the initializer list of
   the constructor or explicitly assigned in the body of the constructor.
   If the member variable is relevant to the functionality of a class
-  (for example when it stores a value from a command line argument), the
+  (for example when it stores a value from a command-line argument), the
   member variable declaration is followed by a brief comment explaining
   its purpose and what its values can be.  Class members that are
   pointers should always be initialized to ``nullptr`` in the

doc/src/Packages_details.rst

@@ -61,6 +61,7 @@ gives those details.
    * :ref:`FEP <PKG-FEP>`
    * :ref:`GPU <PKG-GPU>`
    * :ref:`GRANULAR <PKG-GRANULAR>`
+   * :ref:`GRANSURF <PKG-GRANSURF>`
    * :ref:`H5MD <PKG-H5MD>`
    * :ref:`INTEL <PKG-INTEL>`
    * :ref:`INTERLAYER <PKG-INTERLAYER>`
@@ -880,7 +881,7 @@ groups of atoms that interact with the remaining atoms as electrolyte.
 
 **Authors:** The ELECTRODE package is written and maintained by Ludwig
 Ahrens-Iwers (TUHH, Hamburg, Germany), Shern Tee (UQ, Brisbane, Australia) and
-Robert Meissner (TUHH, Hamburg, Germany).
+Robert Meissner (Helmholtz-Zentrum Hereon, Geesthacht and TUHH, Hamburg, Germany).
 
 .. versionadded:: 4May2022
 
@@ -994,6 +995,7 @@ Additional pair styles that are less commonly used.
 
 * ``src/EXTRA-PAIR``: filenames -> commands
 * :doc:`pair_style <pair_style>`
+* ``examples/PACKAGES/dispersion``
 
 ----------
 
@@ -1098,6 +1100,31 @@ potentials.
 
 ----------
 
+.. _PKG-GRANSURF:
+
+GRANSURF package
+----------------
+
+**Contents:**
+
+Granular surfaces consisting of triangles (3d) or line segments (2d).
+These interact with finite-size granular particles as static or moving
+boundary conditions and support the same kind of interaction models as
+granular pair styles do for particle/particle interactions.  The
+collection of triangles or lines can be "global" with each processor
+storing all of them.  Or it can be "local" where the triangles/lines
+are distributed across processors.
+
+**Supporting info:**
+
+* src/GRANSURF: filenames -> commands
+* :doc:`Howto granular surfaces <Howto_granular_surfaces>`
+* :doc:`fix surface/global <fix_surface_global>`
+* :doc:`fix surface_local <fix_surface_local>`
+* examples/gransurf
+
+----------
+
 .. _PKG-H5MD:
 
 H5MD package
@@ -2171,8 +2198,8 @@ the :doc:`Build extras <Build_extras>` page.
 * ``src/OPENMP/README``
 * :doc:`Accelerator packages <Speed_packages>`
 * :doc:`OPENMP package <Speed_omp>`
-* :doc:`Command line option -suffix/-sf omp <Run_options>`
-* :doc:`Command line option -package/-pk omp <Run_options>`
+* :doc:`Command-line option -suffix/-sf omp <Run_options>`
+* :doc:`Command-line option -package/-pk omp <Run_options>`
 * :doc:`package omp <package>`
 * Search the :doc:`commands <Commands_all>` pages (:doc:`fix <Commands_fix>`, :doc:`compute <Commands_compute>`,
   :doc:`pair <Commands_pair>`, :doc:`bond, angle, dihedral, improper <Commands_bond>`,
@@ -2789,14 +2816,15 @@ implements smoothed particle hydrodynamics (SPH) for liquids.  See the
 related :ref:`MACHDYN package <PKG-MACHDYN>` package for smooth Mach dynamics
 (SMD) for solids.
 
-This package contains ideal gas, Lennard-Jones equation of states,
-Tait, and full support for complete (i.e. internal-energy dependent)
-equations of state.  It allows for plain or Monaghans XSPH integration
-of the equations of motion.  It has options for density continuity or
-density summation to propagate the density field.  It has
-:doc:`set <set>` command options to set the internal energy and density
-of particles from the input script and allows the same quantities to
-be output with thermodynamic output or to dump files via the :doc:`compute property/atom <compute_property_atom>` command.
+This package contains ideal gas, Lennard-Jones equation of states, Tait,
+and full support for complete (i.e. internal-energy dependent) equations
+of state.  It allows for plain or Monaghans XSPH integration of the
+equations of motion.  It has options for density continuity or density
+summation to propagate the density field.  It has :doc:`set <set>`
+command options to set the internal energy and density of particles from
+the input script and allows the same quantities to be output with
+thermodynamic output or to dump files via the :doc:`compute
+property/atom <compute_property_atom>` command.
 
 **Author:** Georg Ganzenmuller (Fraunhofer-Institute for High-Speed
 Dynamics, Ernst Mach Institute, Germany).
@@ -2809,6 +2837,17 @@ Dynamics, Ernst Mach Institute, Germany).
 * ``examples/PACKAGES/sph``
 * https://www.lammps.org/movies.html#sph
 
+.. note::
+
+   Please note that the SPH PDF guide file has not been updated for
+   many years and thus does not reflect the current *syntax* of the
+   SPH package commands. For that please refer to the LAMMPS manual.
+
+.. note::
+
+   Please also note, that the :ref:`RHEO package <PKG-RHEO>` offers
+   similar functionality in a more modern and flexible implementation.
+
 ----------
 
 .. _PKG-SPIN:

doc/src/Packages_list.rst

@@ -203,6 +203,11 @@ whether an extra library is needed to build and use the package:
      - :doc:`Howto granular <Howto_granular>`
      - pour
      - no
+   * - :ref:`GRANSURF <PKG-GRANSURF>`
+     - granular surfaces
+     - :doc:`Howto granular surfaces <Howto_granular_surfaces>`
+     - pour
+     - no
    * - :ref:`H5MD <PKG-H5MD>`
      - dump output via HDF5
      - :doc:`dump h5md <dump_h5md>`

doc/src/Python_atoms.rst

@@ -2,14 +2,8 @@ Per-atom properties
 ===================
 
 Similar to what is described in :doc:`Library_atoms`, the instances of
-:py:class:`lammps <lammps.lammps>`, :py:class:`PyLammps <lammps.PyLammps>`, or
-:py:class:`IPyLammps <lammps.IPyLammps>` can be used to extract atom quantities
-and modify some of them. The main difference between the interfaces is how the information
-is exposed.
-
-While the :py:class:`lammps <lammps.lammps>` is just a thin layer that wraps C API calls,
-:py:class:`PyLammps <lammps.PyLammps>` and :py:class:`IPyLammps <lammps.IPyLammps>` expose
-information as objects and properties.
+:py:class:`lammps <lammps.lammps>` can be used to extract atom quantities
+and modify some of them.
 
 In some cases the data returned is a direct reference to the original data
 inside LAMMPS cast to ``ctypes`` pointers. Where possible, the wrappers will
@@ -25,57 +19,41 @@ against invalid accesses.
    accordingly. These arrays can change sizes and order at every neighbor list
    rebuild and atom sort event as atoms are migrating between subdomains.
 
-.. tabs::
+.. code-block:: python
 
-   .. tab:: lammps API
+   from lammps import lammps
 
-      .. code-block:: python
+   lmp = lammps()
+   lmp.file("in.sysinit")
 
-         from lammps import lammps
 
-         lmp = lammps()
-         lmp.file("in.sysinit")
+   # Read/Write access via ctypes
+   nlocal = lmp.extract_global("nlocal")
+   x = lmp.extract_atom("x")
 
-         nlocal = lmp.extract_global("nlocal")
-         x = lmp.extract_atom("x")
+   for i in range(nlocal):
+      print("(x,y,z) = (", x[i][0], x[i][1], x[i][2], ")")
 
-         for i in range(nlocal):
-            print("(x,y,z) = (", x[i][0], x[i][1], x[i][2], ")")
+   # Read/Write access via NumPy arrays
+   atom_id = L.numpy.extract_atom("id")
+   atom_type = L.numpy.extract_atom("type")
+   x = L.numpy.extract_atom("x")
+   v = L.numpy.extract_atom("v")
+   f = L.numpy.extract_atom("f")
 
-         lmp.close()
+   # set position in 2D simulation
+   x[0] = (1.0, 0.0)
 
-      **Methods**:
+   # set position in 3D simulation
+   x[0] = (1.0, 0.0, 1.)
 
-      * :py:meth:`extract_atom() <lammps.lammps.extract_atom()>`: extract a per-atom quantity
+   lmp.close()
 
-      **Numpy Methods**:
 
-      * :py:meth:`numpy.extract_atom() <lammps.numpy_wrapper.numpy_wrapper.extract_atom()>`: extract a per-atom quantity as numpy array
+**Methods**:
 
-   .. tab:: PyLammps/IPyLammps API
+* :py:meth:`extract_atom() <lammps.lammps.extract_atom()>`: extract a per-atom quantity
 
-      All atoms in the current simulation can be accessed by using the :py:attr:`PyLammps.atoms <lammps.PyLammps.atoms>` property.
-      Each element of this list is a :py:class:`Atom <lammps.Atom>` or :py:class:`Atom2D <lammps.Atom2D>` object. The attributes of
-      these objects provide access to their data (id, type, position, velocity, force, etc.):
-
-      .. code-block:: python
-
-         # access first atom
-         L.atoms[0].id
-         L.atoms[0].type
-
-         # access second atom
-         L.atoms[1].position
-         L.atoms[1].velocity
-         L.atoms[1].force
-
-      Some attributes can be changed:
-
-      .. code-block:: python
-
-         # set position in 2D simulation
-         L.atoms[0].position = (1.0, 0.0)
-
-         # set position in 3D simulation
-         L.atoms[0].position = (1.0, 0.0, 1.0)
+**Numpy Methods**:
 
+* :py:meth:`numpy.extract_atom() <lammps.numpy_wrapper.numpy_wrapper.extract_atom()>`: extract a per-atom quantity as numpy array

doc/src/Python_create.rst

@@ -6,11 +6,10 @@ Creating or deleting a LAMMPS object
 ====================================
 
 With the Python interface the creation of a :cpp:class:`LAMMPS
-<LAMMPS_NS::LAMMPS>` instance is included in the constructors for the
-:py:class:`lammps <lammps.lammps>`, :py:class:`PyLammps <lammps.PyLammps>`,
-and :py:class:`IPyLammps <lammps.IPyLammps>` classes.
-Internally it will call either :cpp:func:`lammps_open` or :cpp:func:`lammps_open_no_mpi` from the C
-library API to create the class instance.
+<LAMMPS_NS::LAMMPS>` instance is included in the constructor for the
+:py:class:`lammps <lammps.lammps>` class. Internally it will call either
+:cpp:func:`lammps_open` or :cpp:func:`lammps_open_no_mpi` from the C library
+API to create the class instance.
 
 All arguments are optional.  The *name* argument allows loading a
 LAMMPS shared library that is named ``liblammps_machine.so`` instead of
@@ -26,108 +25,25 @@ to run the Python module like the library interface on a subset of the
 MPI ranks after splitting the communicator.
 
 
-Here are simple examples using all three Python interfaces:
+Here is a simple example using the LAMMPS Python interface:
 
-.. tabs::
+.. code-block:: python
 
-   .. tab:: lammps API
+   from lammps import lammps
 
-      .. code-block:: python
+   # NOTE: argv[0] is set by the lammps class constructor
+   args = ["-log", "none"]
 
-         from lammps import lammps
+   # create LAMMPS instance
+   lmp = lammps(cmdargs=args)
 
-         # NOTE: argv[0] is set by the lammps class constructor
-         args = ["-log", "none"]
+   # get and print numerical version code
+   print("LAMMPS Version: ", lmp.version())
 
-         # create LAMMPS instance
-         lmp = lammps(cmdargs=args)
+   # explicitly close and delete LAMMPS instance (optional)
+   lmp.close()
 
-         # get and print numerical version code
-         print("LAMMPS Version: ", lmp.version())
-
-         # explicitly close and delete LAMMPS instance (optional)
-         lmp.close()
-
-   .. tab:: PyLammps API
-
-      The :py:class:`PyLammps <lammps.PyLammps>` class is a wrapper around the
-      :py:class:`lammps <lammps.lammps>` class and all of its lower level functions.
-      By default, it will create a new instance of :py:class:`lammps <lammps.lammps>` passing
-      along all arguments to the constructor of :py:class:`lammps <lammps.lammps>`.
-
-      .. code-block:: python
-
-         from lammps import PyLammps
-
-         # NOTE: argv[0] is set by the lammps class constructor
-         args = ["-log", "none"]
-
-         # create LAMMPS instance
-         L = PyLammps(cmdargs=args)
-
-         # get and print numerical version code
-         print("LAMMPS Version: ", L.version())
-
-         # explicitly close and delete LAMMPS instance (optional)
-         L.close()
-
-      :py:class:`PyLammps <lammps.PyLammps>` objects can also be created on top of an existing
-      :py:class:`lammps <lammps.lammps>` object:
-
-      .. code-block:: python
-
-         from lammps import lammps, PyLammps
-         ...
-         # create LAMMPS instance
-         lmp = lammps(cmdargs=args)
-
-         # create PyLammps instance using previously created LAMMPS instance
-         L = PyLammps(ptr=lmp)
-
-      This is useful if you have to create the :py:class:`lammps <lammps.lammps>`
-      instance is a specific way, but want to take advantage of the
-      :py:class:`PyLammps <lammps.PyLammps>` interface.
-
-   .. tab:: IPyLammps API
-
-      The :py:class:`IPyLammps <lammps.IPyLammps>` class is an extension of the
-      :py:class:`PyLammps <lammps.PyLammps>` class. It has the same construction behavior. By
-      default, it will create a new instance of :py:class:`lammps` passing
-      along all arguments to the constructor of :py:class:`lammps`.
-
-      .. code-block:: python
-
-         from lammps import IPyLammps
-
-         # NOTE: argv[0] is set by the lammps class constructor
-         args = ["-log", "none"]
-
-         # create LAMMPS instance
-         L = IPyLammps(cmdargs=args)
-
-         # get and print numerical version code
-         print("LAMMPS Version: ", L.version())
-
-         # explicitly close and delete LAMMPS instance (optional)
-         L.close()
-
-      You can also initialize IPyLammps on top of an existing :py:class:`lammps` or :py:class:`PyLammps` object:
-
-      .. code-block:: python
-
-         from lammps import lammps, IPyLammps
-         ...
-         # create LAMMPS instance
-         lmp = lammps(cmdargs=args)
-
-         # create PyLammps instance using previously created LAMMPS instance
-         L = PyLammps(ptr=lmp)
-
-      This is useful if you have to create the :py:class:`lammps <lammps.lammps>`
-      instance is a specific way, but want to take advantage of the
-      :py:class:`IPyLammps <lammps.IPyLammps>` interface.
-
-In all of the above cases, same as with the :ref:`C library API <lammps_c_api>`, this will use the
+Same as with the :ref:`C library API <lammps_c_api>`, this will use the
 ``MPI_COMM_WORLD`` communicator for the MPI library that LAMMPS was
 compiled with.
 

doc/src/Python_execute.rst

@@ -1,127 +1,123 @@
 Executing commands
 ==================
 
-Once an instance of the :py:class:`lammps <lammps.lammps>`,
-:py:class:`PyLammps <lammps.PyLammps>`, or
-:py:class:`IPyLammps <lammps.IPyLammps>` class is created, there are
+Once an instance of the :py:class:`lammps <lammps.lammps>` class is created, there are
 multiple ways to "feed" it commands. In a way that is not very different from
 running a LAMMPS input script, except that Python has many more facilities
 for structured programming than the LAMMPS input script syntax. Furthermore
 it is possible to "compute" what the next LAMMPS command should be.
 
-.. tabs::
+Same as in the equivalent :doc:`C library functions <Library_execute>`,
+commands can be read from a file, a single string, a list of strings and a
+block of commands in a single multi-line string. They are processed under the
+same boundary conditions as the C library counterparts.  The example below
+demonstrates the use of :py:func:`lammps.file()`, :py:func:`lammps.command()`,
+:py:func:`lammps.commands_list()`, and :py:func:`lammps.commands_string()`:
 
-   .. tab:: lammps API
+.. code-block:: python
 
-      Same as in the equivalent
-      :doc:`C library functions <Library_execute>`, commands can be read from a file, a
-      single string, a list of strings and a block of commands in a single
-      multi-line string. They are processed under the same boundary conditions
-      as the C library counterparts.  The example below demonstrates the use
-      of :py:func:`lammps.file()`, :py:func:`lammps.command()`,
-      :py:func:`lammps.commands_list()`, and :py:func:`lammps.commands_string()`:
+   from lammps import lammps
+   lmp = lammps()
 
-      .. code-block:: python
+   # read commands from file 'in.melt'
+   lmp.file('in.melt')
 
-         from lammps import lammps
-         lmp = lammps()
+   # issue a single command
+   lmp.command('variable zpos index 1.0')
 
-         # read commands from file 'in.melt'
-         lmp.file('in.melt')
+   # create 10 groups with 10 atoms each
+   cmds = [f"group g{i} id {10*i+1}:{10*(i+1)}" for i in range(10)]
+   lmp.commands_list(cmds)
 
-         # issue a single command
-         lmp.command('variable zpos index 1.0')
+   # run commands from a multi-line string
+   block = """
+   clear
+   region  box block 0 2 0 2 0 2
+   create_box 1 box
+   create_atoms 1 single 1.0 1.0 ${zpos}
+   """
+   lmp.commands_string(block)
 
-         # create 10 groups with 10 atoms each
-         cmds = ["group g{} id {}:{}".format(i,10*i+1,10*(i+1)) for i in range(10)]
-         lmp.commands_list(cmds)
+For convenience, the :py:class:`lammps <lammps.lammps>` class also provides a
+command wrapper ``cmd`` that turns any LAMMPS command into a regular function
+call.
 
-         # run commands from a multi-line string
-         block = """
-         clear
-         region  box block 0 2 0 2 0 2
-         create_box 1 box
-         create_atoms 1 single 1.0 1.0 ${zpos}
-         """
-         lmp.commands_string(block)
+For instance, the following LAMMPS command
 
-   .. tab:: PyLammps/IPyLammps API
+.. code-block:: LAMMPS
 
-      Unlike the lammps API, the PyLammps/IPyLammps APIs allow running LAMMPS
-      commands by calling equivalent member functions of :py:class:`PyLammps <lammps.PyLammps>`
-      and :py:class:`IPyLammps <lammps.IPyLammps>` instances.
+   region box block 0 10 0 5 -0.5 0.5
 
-      For instance, the following LAMMPS command
+would normally be executed with the following Python code:
 
-      .. code-block:: LAMMPS
+.. code-block:: python
 
-         region box block 0 10 0 5 -0.5 0.5
+   from lammps import lammps
 
-      can be executed using with the lammps API with the following Python code if ``lmp`` is an
-      instance of :py:class:`lammps <lammps.lammps>`:
+   lmp = lammps()
+   lmp.command("region box block 0 10 0 5 -0.5 0.5")
 
-      .. code-block:: python
+With the ``cmd`` wrapper, any LAMMPS command can be split up into arbitrary parts.
+These parts are then passed to a member function with the name of the :doc:`command <Commands_all>`.
+For the :doc:`region <region>` command that means the :code:`region()` method can be called.
+The arguments of the command can be passed as one string, or
+individually.
 
-         from lammps import lammps
+.. code-block:: python
 
-         lmp = lammps()
-         lmp.command("region box block 0 10 0 5 -0.5 0.5")
+   from lammps import lammps
 
-      With the PyLammps interface, any LAMMPS command can be split up into arbitrary parts.
-      These parts are then passed to a member function with the name of the :doc:`command <Commands_all>`.
-      For the :doc:`region <region>` command that means the :code:`region()` method can be called.
-      The arguments of the command can be passed as one string, or
-      individually.
+   L = lammps()
 
-      .. code-block:: python
+   # pass command parameters as one string
+   L.cmd.region("box block 0 10 0 5 -0.5 0.5")
 
-         from lammps import PyLammps
+   # OR pass them individually
+   L.cmd.region("box block", 0, 10, 0, 5, -0.5, 0.5)
 
-         L = PyLammps()
+In the latter example, all parameters except the first are Python floating-point literals. The
+member function takes the entire parameter list and transparently merges it to a single command
+string.
 
-         # pass command parameters as one string
-         L.region("box block 0 10 0 5 -0.5 0.5")
+The benefit of this approach is avoiding redundant command calls and easier
+parameterization. With `command`, `commands_list`, and `commands_string` the
+parameterization needed to be done manually by creating formatted command
+strings.
 
-         # OR pass them individually
-         L.region("box block", 0, 10, 0, 5, -0.5, 0.5)
+.. code-block:: python
 
-      In the latter example, all parameters except the first are Python floating-point literals. The
-      member function takes the entire parameter list and transparently merges it to a single command
-      string.
+   lmp.command("region box block %f %f %f %f %f %f" % (xlo, xhi, ylo, yhi, zlo, zhi))
 
-      The benefit of this approach is avoiding redundant command calls and easier
-      parameterization. In the lammps API parameterization needed to be done
-      manually by creating formatted command strings.
+In contrast, methods of the `cmd` wrapper accept parameters directly and will convert
+them automatically to a final command string.
 
-      .. code-block:: python
+.. code-block:: python
 
-         lmp.command("region box block %f %f %f %f %f %f" % (xlo, xhi, ylo, yhi, zlo, zhi))
+   L.cmd.region("box block", xlo, xhi, ylo, yhi, zlo, zhi)
 
-      In contrast, methods of PyLammps accept parameters directly and will convert
-      them automatically to a final command string.
+.. note::
 
-      .. code-block:: python
+   When running in IPython you can use Tab-completion after ``L.cmd.`` to see
+   all available LAMMPS commands.
 
-         L.region("box block", xlo, xhi, ylo, yhi, zlo, zhi)
+Using these facilities, the previous example shown above can be rewritten as follows:
 
-      Using these facilities, the example shown for the lammps API can be rewritten as follows:
+.. code-block:: python
 
-      .. code-block:: python
+   from lammps import lammps
+   L = lammps()
 
-         from lammps import PyLammps
-         L = PyLammps()
+   # read commands from file 'in.melt'
+   L.file('in.melt')
 
-         # read commands from file 'in.melt'
-         L.file('in.melt')
+   # issue a single command
+   L.cmd.variable('zpos', 'index', 1.0)
 
-         # issue a single command
-         L.variable('zpos', 'index', 1.0)
+   # create 10 groups with 10 atoms each
+   for i in range(10):
+      L.cmd.group(f"g{i}", "id", f"{10*i+1}:{10*(i+1)}")
 
-         # create 10 groups with 10 atoms each
-         for i in range(10):
-            L.group(f"g{i}", "id", f"{10*i+1}:{10*(i+1)}")
-
-         L.clear()
-         L.region("box block", 0, 2, 0, 2, 0, 2)
-         L.create_box(1, "box")
-         L.create_atoms(1, "single", 1.0, 1.0, "${zpos}")
+   L.cmd.clear()
+   L.cmd.region("box block", 0, 2, 0, 2, 0, 2)
+   L.cmd.create_box(1, "box")
+   L.cmd.create_atoms(1, "single", 1.0, 1.0, "${zpos}")

doc/src/Python_head.rst

@@ -15,6 +15,7 @@ together.
    Python_call
    Python_formats
    Python_examples
+   Python_jupyter
    Python_error
    Python_trouble
 

doc/src/Python_jupyter.rst

@@ -0,0 +1,45 @@
+Using LAMMPS in IPython notebooks and Jupyter
+=============================================
+
+If the LAMMPS Python package is installed for the same Python interpreter as
+`IPython <ipython>`_, you can use LAMMPS directly inside of an IPython notebook inside of
+Jupyter. `Jupyter <juypter>`_ is a powerful integrated development environment (IDE) for
+many dynamic languages like Python, Julia and others, which operates inside of
+any web browser. Besides auto-completion and syntax highlighting it allows you
+to create formatted documents using Markup, mathematical formulas, graphics and
+animations intermixed with executable Python code. It is a great format for
+tutorials and showcasing your latest research.
+
+The easiest way to install it is via ``pip``:
+
+.. code-block:: bash
+
+   pip install --user jupyter
+
+To launch an instance of Jupyter simply run the following command inside your
+Python environment:
+
+.. code-block:: bash
+
+   jupyter notebook
+
+Interactive Python Examples
+---------------------------
+
+Examples of IPython notebooks can be found in the ``python/examples/ipython``
+subdirectory. They require LAMMPS to be compiled as shared library with PYTHON,
+PNG, JPEG and FFMPEG support.
+
+To open these notebooks launch ``jupyter notebook index.ipynb`` inside this
+directory. The opened file provides an overview of the available examples.
+
+- Example 1: Using LAMMPS with Python (``simple.ipynb``)
+- Example 2: Analyzing LAMMPS thermodynamic data (``thermo.ipynb``)
+- Example 3: Working with Per-Atom Data (``atoms.ipynb``)
+- Example 4: Working with LAMMPS variables (``variables.ipynb``)
+- Example 5: Validating a dihedral potential (``dihedrals/dihedral.ipynb``)
+- Example 6: Running a Monte Carlo relaxation (``montecarlo/mc.ipynb``)
+
+.. note::
+
+   Typically clicking a link in Jupyter will open a new tab, which might be blocked by your pop-up blocker.

doc/src/Python_module.rst

@@ -10,19 +10,11 @@ be installed into a Python system folder or a user folder with ``make
 install-python``.  Components of the module can then loaded into a Python
 session with the ``import`` command.
 
-There are multiple Python interface classes in the :py:mod:`lammps` module:
+.. warning::
 
-- the :py:class:`lammps <lammps.lammps>` class. This is a wrapper around
-  the C-library interface and its member functions try to replicate the
-  :ref:`C-library API <lammps_c_api>` closely.  This is the most
-  feature-complete Python API.
-- the :py:class:`PyLammps <lammps.PyLammps>` class. This is a more high-level
-  and more Python style class implemented on top of the
-  :py:class:`lammps <lammps.lammps>` class.
-- the :py:class:`IPyLammps <lammps.IPyLammps>` class is derived from
-  :py:class:`PyLammps <lammps.PyLammps>` and adds embedded graphics
-  features to conveniently include LAMMPS into `Jupyter
-  <https://jupyter.org/>`_ notebooks.
+   Alternative interfaces such as :py:class:`PyLammps <lammps.PyLammps>` and
+   :py:class:`IPyLammps <lammps.IPyLammps>` classes have been deprecated and
+   will be removed in a future version of LAMMPS.
 
 .. _mpi4py_url: https://mpi4py.readthedocs.io
 
@@ -49,7 +41,7 @@ The ``lammps`` class API
 ========================
 
 The :py:class:`lammps <lammps.lammps>` class is the core of the LAMMPS
-Python interfaces.  It is a wrapper around the :ref:`LAMMPS C library
+Python interface.  It is a wrapper around the :ref:`LAMMPS C library
 API <lammps_c_api>` using the `Python ctypes module
 <https://docs.python.org/3/library/ctypes.html>`_ and a shared library
 compiled from the LAMMPS sources code.  The individual methods in this
@@ -64,40 +56,7 @@ functions. Below is a detailed documentation of the API.
 .. autoclass:: lammps.numpy_wrapper::numpy_wrapper
    :members:
 
-----------
-
-The ``PyLammps`` class API
-==========================
-
-The :py:class:`PyLammps <lammps.PyLammps>` class is a wrapper that creates a
-simpler, more "Pythonic" interface to common LAMMPS functionality. LAMMPS
-data structures are exposed through objects and properties. This makes Python
-scripts shorter and more concise. See the :doc:`PyLammps Tutorial
-<Howto_pylammps>` for an introduction on how to use this interface.
-
-.. autoclass:: lammps.PyLammps
-   :members:
-
-.. autoclass:: lammps.AtomList
-   :members:
-
-.. autoclass:: lammps.Atom
-   :members:
-
-.. autoclass:: lammps.Atom2D
-   :members:
-
-----------
-
-The ``IPyLammps`` class API
-===========================
-
-The :py:class:`IPyLammps <lammps.PyLammps>` class is an extension of
-:py:class:`PyLammps <lammps.PyLammps>`, adding additional functions to
-quickly display visualizations such as images and videos inside of IPython.
-See the :doc:`PyLammps Tutorial <Howto_pylammps>` for examples.
-
-.. autoclass:: lammps.IPyLammps
+.. autoclass:: lammps.ipython::wrapper
    :members:
 
 ----------

doc/src/Python_objects.rst

@@ -4,95 +4,52 @@ Compute, fixes, variables
 This section documents accessing or modifying data from objects like
 computes, fixes, or variables in LAMMPS using the :py:mod:`lammps` module.
 
-.. tabs::
+For :py:meth:`lammps.extract_compute() <lammps.lammps.extract_compute()>` and
+:py:meth:`lammps.extract_fix() <lammps.lammps.extract_fix()>`, the global, per-atom,
+or local data calculated by the compute or fix can be accessed. What is returned
+depends on whether the compute or fix calculates a scalar or vector or array.
+For a scalar, a single double value is returned.  If the compute or fix calculates
+a vector or array, a pointer to the internal LAMMPS data is returned, which you can
+use via normal Python subscripting.
 
-   .. tab:: lammps API
+The one exception is that for a fix that calculates a
+global vector or array, a single double value from the vector or array
+is returned, indexed by I (vector) or I and J (array).  I,J are
+zero-based indices.
+See the :doc:`Howto output <Howto_output>` page for a discussion of
+global, per-atom, and local data, and of scalar, vector, and array
+data types.  See the doc pages for individual :doc:`computes <compute>`
+and :doc:`fixes <fix>` for a description of what they calculate and
+store.
 
-      For :py:meth:`lammps.extract_compute() <lammps.lammps.extract_compute()>` and
-      :py:meth:`lammps.extract_fix() <lammps.lammps.extract_fix()>`, the global, per-atom,
-      or local data calculated by the compute or fix can be accessed. What is returned
-      depends on whether the compute or fix calculates a scalar or vector or array.
-      For a scalar, a single double value is returned.  If the compute or fix calculates
-      a vector or array, a pointer to the internal LAMMPS data is returned, which you can
-      use via normal Python subscripting.
+For :py:meth:`lammps.extract_variable() <lammps.lammps.extract_variable()>`,
+an :doc:`equal-style or atom-style variable <variable>` is evaluated and
+its result returned.
 
-      The one exception is that for a fix that calculates a
-      global vector or array, a single double value from the vector or array
-      is returned, indexed by I (vector) or I and J (array).  I,J are
-      zero-based indices.
-      See the :doc:`Howto output <Howto_output>` page for a discussion of
-      global, per-atom, and local data, and of scalar, vector, and array
-      data types.  See the doc pages for individual :doc:`computes <compute>`
-      and :doc:`fixes <fix>` for a description of what they calculate and
-      store.
+For equal-style variables a single ``c_double`` value is returned and the
+group argument is ignored.  For atom-style variables, a vector of
+``c_double`` is returned, one value per atom, which you can use via normal
+Python subscripting. The values will be zero for atoms not in the
+specified group.
 
-      For :py:meth:`lammps.extract_variable() <lammps.lammps.extract_variable()>`,
-      an :doc:`equal-style or atom-style variable <variable>` is evaluated and
-      its result returned.
+:py:meth:`lammps.numpy.extract_compute() <lammps.numpy_wrapper.numpy_wrapper.extract_compute()>`,
+:py:meth:`lammps.numpy.extract_fix() <lammps.numpy_wrapper.numpy_wrapper.extract_fix()>`, and
+:py:meth:`lammps.numpy.extract_variable() <lammps.numpy_wrapper.numpy_wrapper.extract_variable()>` are
+equivalent NumPy implementations that return NumPy arrays instead of ``ctypes`` pointers.
 
-      For equal-style variables a single ``c_double`` value is returned and the
-      group argument is ignored.  For atom-style variables, a vector of
-      ``c_double`` is returned, one value per atom, which you can use via normal
-      Python subscripting. The values will be zero for atoms not in the
-      specified group.
+The :py:meth:`lammps.set_variable() <lammps.lammps.set_variable()>` method sets an
+existing string-style variable to a new string value, so that subsequent LAMMPS
+commands can access the variable.
 
-      :py:meth:`lammps.numpy.extract_compute() <lammps.numpy_wrapper.numpy_wrapper.extract_compute()>`,
-      :py:meth:`lammps.numpy.extract_fix() <lammps.numpy_wrapper.numpy_wrapper.extract_fix()>`, and
-      :py:meth:`lammps.numpy.extract_variable() <lammps.numpy_wrapper.numpy_wrapper.extract_variable()>` are
-      equivalent NumPy implementations that return NumPy arrays instead of ``ctypes`` pointers.
+**Methods**:
 
-      The :py:meth:`lammps.set_variable() <lammps.lammps.set_variable()>` method sets an
-      existing string-style variable to a new string value, so that subsequent LAMMPS
-      commands can access the variable.
+* :py:meth:`lammps.extract_compute() <lammps.lammps.extract_compute()>`: extract value(s) from a compute
+* :py:meth:`lammps.extract_fix() <lammps.lammps.extract_fix()>`: extract value(s) from a fix
+* :py:meth:`lammps.extract_variable() <lammps.lammps.extract_variable()>`: extract value(s) from a variable
+* :py:meth:`lammps.set_variable() <lammps.lammps.set_variable()>`: set existing named string-style variable to value
 
-      **Methods**:
+**NumPy Methods**:
 
-      * :py:meth:`lammps.extract_compute() <lammps.lammps.extract_compute()>`: extract value(s) from a compute
-      * :py:meth:`lammps.extract_fix() <lammps.lammps.extract_fix()>`: extract value(s) from a fix
-      * :py:meth:`lammps.extract_variable() <lammps.lammps.extract_variable()>`: extract value(s) from a variable
-      * :py:meth:`lammps.set_variable() <lammps.lammps.set_variable()>`: set existing named string-style variable to value
-
-      **NumPy Methods**:
-
-      * :py:meth:`lammps.numpy.extract_compute() <lammps.numpy_wrapper.numpy_wrapper.extract_compute()>`: extract value(s) from a compute, return arrays as numpy arrays
-      * :py:meth:`lammps.numpy.extract_fix() <lammps.numpy_wrapper.numpy_wrapper.extract_fix()>`: extract value(s) from a fix, return arrays as numpy arrays
-      * :py:meth:`lammps.numpy.extract_variable() <lammps.numpy_wrapper.numpy_wrapper.extract_variable()>`: extract value(s) from a variable, return arrays as numpy arrays
-
-
-   .. tab:: PyLammps/IPyLammps API
-
-      PyLammps and IPyLammps classes currently do not add any additional ways of
-      retrieving information out of computes and fixes. This information can still be accessed by using the lammps API:
-
-      .. code-block:: python
-
-         L.lmp.extract_compute(...)
-         L.lmp.extract_fix(...)
-         # OR
-         L.lmp.numpy.extract_compute(...)
-         L.lmp.numpy.extract_fix(...)
-
-      LAMMPS variables can be both defined and accessed via the :py:class:`PyLammps <lammps.PyLammps>` interface.
-
-      To define a variable you can use the :doc:`variable <variable>` command:
-
-      .. code-block:: python
-
-         L.variable("a index 2")
-
-      A dictionary of all variables is returned by the :py:attr:`PyLammps.variables <lammps.PyLammps.variables>` property:
-
-      you can access an individual variable by retrieving a variable object from the
-      ``L.variables`` dictionary by name
-
-      .. code-block:: python
-
-         a = L.variables['a']
-
-      The variable value can then be easily read and written by accessing the value
-      property of this object.
-
-      .. code-block:: python
-
-         print(a.value)
-         a.value = 4
+* :py:meth:`lammps.numpy.extract_compute() <lammps.numpy_wrapper.numpy_wrapper.extract_compute()>`: extract value(s) from a compute, return arrays as numpy arrays
+* :py:meth:`lammps.numpy.extract_fix() <lammps.numpy_wrapper.numpy_wrapper.extract_fix()>`: extract value(s) from a fix, return arrays as numpy arrays
+* :py:meth:`lammps.numpy.extract_variable() <lammps.numpy_wrapper.numpy_wrapper.extract_variable()>`: extract value(s) from a variable, return arrays as numpy arrays

doc/src/Python_overview.rst

@@ -56,7 +56,7 @@ Below is an example output for Python version 3.8.5.
 
 ---------
 
-LAMMPS can work together with Python in three ways.  First, Python can
+LAMMPS can work together with Python in two ways.  First, Python can
 wrap LAMMPS through the its :doc:`library interface <Library>`, so
 that a Python script can create one or more instances of LAMMPS and
 launch one or more simulations.  In Python terms, this is referred to as
@@ -67,22 +67,7 @@ launch one or more simulations.  In Python terms, this is referred to as
 
    Launching LAMMPS via Python
 
-
-Second, the lower-level Python interface in the :py:class:`lammps Python
-class <lammps.lammps>` can be used indirectly through the provided
-:py:class:`PyLammps <lammps.PyLammps>` and :py:class:`IPyLammps
-<lammps.IPyLammps>` wrapper classes, also written in Python.  These
-wrappers try to simplify the usage of LAMMPS in Python by providing a
-more object-based interface to common LAMMPS functionality.  They also
-reduce the amount of code necessary to parameterize LAMMPS scripts
-through Python and make variables and computes directly accessible.
-
-.. figure:: JPG/pylammps-invoke-lammps.png
-   :figclass: align-center
-
-   Using the PyLammps / IPyLammps wrappers
-
-Third, LAMMPS can use the Python interpreter, so that a LAMMPS input
+Second, LAMMPS can use the Python interpreter, so that a LAMMPS input
 script or styles can invoke Python code directly, and pass information
 back-and-forth between the input script and Python functions you write.
 This Python code can also call back to LAMMPS to query or change its

doc/src/Python_properties.rst

@@ -2,14 +2,8 @@ System properties
 =================
 
 Similar to what is described in :doc:`Library_properties`, the instances of
-:py:class:`lammps <lammps.lammps>`, :py:class:`PyLammps <lammps.PyLammps>`, or
-:py:class:`IPyLammps <lammps.IPyLammps>` can be used to extract different kinds
-of information about the active LAMMPS instance and also to modify some of it. The
-main difference between the interfaces is how the information is exposed.
-
-While the :py:class:`lammps <lammps.lammps>` is just a thin layer that wraps C API calls,
-:py:class:`PyLammps <lammps.PyLammps>` and :py:class:`IPyLammps <lammps.IPyLammps>` expose
-information as objects and properties.
+:py:class:`lammps <lammps.lammps>` can be used to extract different kinds
+of information about the active LAMMPS instance and also to modify some of it.
 
 In some cases the data returned is a direct reference to the original data
 inside LAMMPS cast to ``ctypes`` pointers. Where possible, the wrappers will
@@ -25,113 +19,38 @@ against invalid accesses.
    accordingly. These arrays can change sizes and order at every neighbor list
    rebuild and atom sort event as atoms are migrating between subdomains.
 
-.. tabs::
+.. code-block:: python
 
-   .. tab:: lammps API
+   from lammps import lammps
 
-      .. code-block:: python
+   lmp = lammps()
+   lmp.file("in.sysinit")
 
-         from lammps import lammps
+   natoms = lmp.get_natoms()
+   print(f"running simulation with {natoms} atoms")
 
-         lmp = lammps()
-         lmp.file("in.sysinit")
+   lmp.command("run 1000 post no");
 
-         natoms = lmp.get_natoms()
-         print(f"running simulation with {natoms} atoms")
+   for i in range(10):
+      lmp.command("run 100 pre no post no")
+      pe = lmp.get_thermo("pe")
+      ke = lmp.get_thermo("ke")
+      print(f"PE = {pe}\nKE = {ke}")
 
-         lmp.command("run 1000 post no");
+   lmp.close()
 
-         for i in range(10):
-            lmp.command("run 100 pre no post no")
-            pe = lmp.get_thermo("pe")
-            ke = lmp.get_thermo("ke")
-            print(f"PE = {pe}\nKE = {ke}")
+**Methods**:
 
-         lmp.close()
+* :py:meth:`version() <lammps.lammps.version()>`: return the numerical version id, e.g. LAMMPS 2 Sep 2015 -> 20150902
+* :py:meth:`get_thermo() <lammps.lammps.get_thermo()>`: return current value of a thermo keyword
+* :py:meth:`last_thermo() <lammps.lammps.last_thermo()>`: return a dictionary of the last thermodynamic output
+* :py:meth:`get_natoms() <lammps.lammps.get_natoms()>`: total # of atoms as int
+* :py:meth:`reset_box() <lammps.lammps.reset_box()>`: reset the simulation box size
+* :py:meth:`extract_setting() <lammps.lammps.extract_setting()>`: return a global setting
+* :py:meth:`extract_global() <lammps.lammps.extract_global()>`: extract a global quantity
+* :py:meth:`extract_box() <lammps.lammps.extract_box()>`: extract box info
+* :py:meth:`create_atoms() <lammps.lammps.create_atoms()>`: create N atoms with IDs, types, x, v, and image flags
 
-      **Methods**:
+**Properties**:
 
-      * :py:meth:`version() <lammps.lammps.version()>`: return the numerical version id, e.g. LAMMPS 2 Sep 2015 -> 20150902
-      * :py:meth:`get_thermo() <lammps.lammps.get_thermo()>`: return current value of a thermo keyword
-      * :py:meth:`last_thermo() <lammps.lammps.last_thermo()>`: return a dictionary of the last thermodynamic output
-      * :py:meth:`get_natoms() <lammps.lammps.get_natoms()>`: total # of atoms as int
-      * :py:meth:`reset_box() <lammps.lammps.reset_box()>`: reset the simulation box size
-      * :py:meth:`extract_setting() <lammps.lammps.extract_setting()>`: return a global setting
-      * :py:meth:`extract_global() <lammps.lammps.extract_global()>`: extract a global quantity
-      * :py:meth:`extract_box() <lammps.lammps.extract_box()>`: extract box info
-      * :py:meth:`create_atoms() <lammps.lammps.create_atoms()>`: create N atoms with IDs, types, x, v, and image flags
-
-      **Properties**:
-
-      * :py:attr:`last_thermo_step <lammps.lammps.last_thermo_step>`: the last timestep thermodynamic output was computed
-
-   .. tab:: PyLammps/IPyLammps API
-
-      In addition to the functions provided by :py:class:`lammps <lammps.lammps>`, :py:class:`PyLammps <lammps.PyLammps>` objects
-      have several properties which allow you to query the system state:
-
-      L.system
-         Is a dictionary describing the system such as the bounding box or number of atoms
-
-      L.system.xlo, L.system.xhi
-         bounding box limits along x-axis
-
-      L.system.ylo, L.system.yhi
-         bounding box limits along y-axis
-
-      L.system.zlo, L.system.zhi
-         bounding box limits along z-axis
-
-      L.communication
-         configuration of communication subsystem, such as the number of threads or processors
-
-      L.communication.nthreads
-         number of threads used by each LAMMPS process
-
-      L.communication.nprocs
-         number of MPI processes used by LAMMPS
-
-      L.fixes
-         List of fixes in the current system
-
-      L.computes
-         List of active computes in the current system
-
-      L.dump
-         List of active dumps in the current system
-
-      L.groups
-         List of groups present in the current system
-
-      **Retrieving the value of an arbitrary LAMMPS expressions**
-
-      LAMMPS expressions can be immediately evaluated by using the ``eval`` method. The
-      passed string parameter can be any expression containing global :doc:`thermo` values,
-      variables, compute or fix data (see :doc:`Howto_output`):
-
-
-      .. code-block:: python
-
-         result = L.eval("ke") # kinetic energy
-         result = L.eval("pe") # potential energy
-
-         result = L.eval("v_t/2.0")
-
-      **Example**
-
-      .. code-block:: python
-
-         from lammps import PyLammps
-
-         L = PyLammps()
-         L.file("in.sysinit")
-
-         print(f"running simulation with {L.system.natoms} atoms")
-
-         L.run(1000, "post no");
-
-         for i in range(10):
-            L.run(100, "pre no post no")
-            pe = L.eval("pe")
-            ke = L.eval("ke")
-            print(f"PE = {pe}\nKE = {ke}")
+* :py:attr:`last_thermo_step <lammps.lammps.last_thermo_step>`: the last timestep thermodynamic output was computed