Merge branch 'develop' into group-bitmap-accessor

.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

@@ -27,9 +27,9 @@ jobs:
 
     - name: Install extra packages
       run: |
+        sudo apt-get update
         sudo apt-get install -y ccache \
                                 libeigen3-dev \
-                                libgsl-dev \
                                 libcurl4-openssl-dev \
                                 mold \
                                 mpi-default-bin \

.github/workflows/compile-msvc.yml

@@ -1,4 +1,4 @@
-# GitHub action to build LAMMPS on Windows with Visual C++
+# GitHub action to test LAMMPS on Windows with Visual C++
 name: "Windows Unit Tests"
 
 on:
@@ -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: Windows Compilation Test

.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/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

@@ -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: Linux Unit Test
@@ -27,9 +31,9 @@ jobs:
 
     - name: Install extra packages
       run: |
+        sudo apt-get update
         sudo apt-get install -y ccache \
                                 libeigen3-dev \
-                                libgsl-dev \
                                 libcurl4-openssl-dev \
                                 mold \
                                 ninja-build \

.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

@@ -118,7 +118,7 @@ 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,7 +141,7 @@ 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)
@@ -165,6 +165,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()
@@ -497,7 +498,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)
@@ -572,7 +573,7 @@ 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 EXTRA-COMMAND)
+        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()
@@ -587,13 +588,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)   #
 ########################################################################
@@ -822,9 +818,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)
@@ -1076,12 +1078,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/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

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

@@ -6,13 +6,24 @@ 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-max-parallel-link-jobs=32 -fsycl-targets=spir64_gen -Xsycl-target-backend \"-device 12.60.7\" " 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 -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/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
@@ -42,9 +42,9 @@ that want to modify or extend LAMMPS.
   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
@@ -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,10 +642,10 @@ The following target are available for both, GNU make and CMake:
 
 .. _gh-cli:
 
-GitHub command line interface
+GitHub command-line interface
 -----------------------------
 
-GitHub has developed a `command line tool <https://cli.github.com>`_
+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

doc/src/Build_extras.rst

@@ -209,7 +209,7 @@ necessary for ``hipcc`` and the linker to work correctly.
 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 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.
 
@@ -232,7 +232,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
@@ -421,9 +421,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
 
@@ -546,16 +547,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
@@ -571,105 +563,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
@@ -678,7 +691,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
@@ -701,7 +714,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::
 
@@ -2191,7 +2204,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
@@ -2251,28 +2264,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_settings.rst

@@ -229,8 +229,7 @@ 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/`_.
+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

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_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>`
@@ -134,7 +134,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 +178,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 +187,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>`
@@ -267,7 +269,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>`

doc/src/Commands_removed.rst

@@ -18,7 +18,7 @@ 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:`command-line flags <Run_options>`
 
 Fix ave/spatial and fix ave/spatial/sphere
 ------------------------------------------

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

@@ -476,7 +476,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
@@ -609,7 +609,7 @@ and run the test with verbose output. For example,
 
     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_pair.rst

@@ -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

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
@@ -448,7 +448,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_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
@@ -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_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.
@@ -100,10 +103,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 +121,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 +179,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 +275,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 +419,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 +796,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 +849,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_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/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

@@ -880,7 +880,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
 
@@ -2171,8 +2171,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 +2789,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 +2810,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/Run_basics.rst

@@ -1,8 +1,8 @@
 Basics of running LAMMPS
 ========================
 
-LAMMPS is run from the command line, reading commands from a file via
-the ``-in`` command line flag, or from standard input.  Using the ``-in
+LAMMPS is run from the command-line, reading commands from a file via
+the ``-in`` command-line flag, or from standard input.  Using the ``-in
 in.file`` variant is recommended (see note below).  The name of the
 LAMMPS executable is either ``lmp`` or ``lmp_<machine>`` with
 `<machine>` being the machine string used when compiling LAMMPS.  This
@@ -25,7 +25,7 @@ build LAMMPS:
 You normally run the LAMMPS command in the directory where your input
 script is located.  That is also where output files are produced by
 default, unless you provide specific other paths in your input script or
-on the command line.  As in some of the examples above, the LAMMPS
+on the command-line.  As in some of the examples above, the LAMMPS
 executable itself can be placed elsewhere.
 
 .. note::

doc/src/Run_options.rst

@@ -632,7 +632,7 @@ the ``-package omp`` command-line switch or the :doc:`package omp <package>` com
 
 The :doc:`suffix <suffix>` command can also be used within an input
 script to set a suffix, or to turn off or back on any suffix setting
-made via the command line.
+made via the command-line.
 
 ----------
 

doc/src/Run_windows.rst

@@ -3,71 +3,70 @@ Running LAMMPS on Windows
 
 To run a serial (non-MPI) executable, follow these steps:
 
-* Get a command prompt by going to Start->Run... ,
-  then typing "cmd".
-* Move to the directory where you have your input script,
+* Install a LAMMPS installer package from https://packages.lammps.org/windows.html
+* Open the "Command Prompt" or "Terminal" app.
+* Change to the directory where you have your input script,
   (e.g. by typing: cd "Documents").
-* At the command prompt, type "lmp -in in.file", where
-  in.file is the name of your LAMMPS input script.
+* At the command prompt, type "lmp -in in.file.lmp", where
+  ``in.file.lmp`` is the name of your LAMMPS input script.
 
 Note that the serial executable includes support for multi-threading
-parallelization from the styles in the OPENMP packages.  To run with
-4 threads, you can type this:
+parallelization from the styles in the OPENMP and KOKKOS packages.
+To run with 4 threads, you can type this:
 
 .. code-block:: bash
 
-   lmp -in in.lj -pk omp 4 -sf omp
+   lmp -in in.lj.lmp -pk omp 4 -sf omp
+   lmp -in in.lj.lmp -k on t 4 -sf kk
+
+Alternately, you can also install a package with LAMMPS-GUI included and
+open the LAMMPS-GUI app (the package includes the command-line version
+of LAMMPS as well) and open the input file in the GUI and run it from
+there.  For details on LAMMPS-GUI, see :doc:`Howto_lammps_gui`.
 
 ----------
 
-For the MPI executable, which allows you to run LAMMPS under Windows
-in parallel, follow these steps.
+For the MS-MPI executables, which allow you to run LAMMPS under Windows
+in parallel using MPI rather than multi-threading, follow these steps.
 
-Download and install a compatible MPI library binary package:
-
-* for 32-bit Windows: `mpich2-1.4.1p1-win-ia32.msi <https://download.lammps.org/thirdparty/mpich2-1.4.1p1-win-ia32.msi>`_
-* for 64-bit Windows: `mpich2-1.4.1p1-win-x86-64.msi <https://download.lammps.org/thirdparty/mpich2-1.4.1p1-win-x86-64.msi>`_
-
-The LAMMPS Windows installer packages will automatically adjust your
-path for the default location of this MPI package. After the
-installation of the MPICH2 software, it needs to be integrated into
-the system.  For this you need to start a Command Prompt in
-*Administrator Mode* (right click on the icon and select it). Change
-into the MPICH2 installation directory, then into the subdirectory
-**bin** and execute **smpd.exe -install**\ . Exit the command window.
-
-* Get a new, regular command prompt by going to Start->Run... ,
-  then typing "cmd".
-* Move to the directory where you have your input file
-  (e.g. by typing: cd "Documents").
+Download and install the MS-MPI runtime package ``msmpisetup.exe`` from
+https://www.microsoft.com/en-us/download/details.aspx?id=105289 (Note
+that the ``msmpisdk.msi`` is **only** required for **compilation** of
+LAMMPS from source on Windows using Microsoft Visual Studio). After
+installation of MS-MPI perform a reboot.
 
 Then you can run the executable in serial like in the example above
 or in parallel using MPI with one of the following commands:
 
 .. code-block:: bash
 
-   mpiexec -localonly 4 lmp -in in.file
-   mpiexec -np 4 lmp -in in.file
+   mpiexec -localonly 4 lmp -in in.file.lmp
+   mpiexec -np 4 lmp -in in.file.lmp
 
-where in.file is the name of your LAMMPS input script. For the latter
-case, you may be prompted to enter the password that you set during
-installation of the MPI library software.
+where ``in.file.lmp`` is the name of your LAMMPS input script. For the
+latter case, you may be prompted to enter the password that you set
+during installation of the MPI library software.
 
 In this mode, output may not immediately show up on the screen, so if
 your input script takes a long time to execute, you may need to be
 patient before the output shows up.
 
-The parallel executable can also run on a single processor by typing
-something like this:
+Note that the parallel executable also includes OpenMP multi-threading
+through both the OPENMP and the KOKKOS package, which can be combined
+with MPI using something like:
 
 .. code-block:: bash
 
-   lmp -in in.lj
+   mpiexec -localonly 2 lmp -in in.lj.lmp -pk omp 2 -sf omp
+   mpiexec -localonly 2 lmp -in in.lj.lmp -kokkos on t 2 -sf kk
 
-Note that the parallel executable also includes OpenMP
-multi-threading, which can be combined with MPI using something like:
-
-.. code-block:: bash
-
-   mpiexec -localonly 2 lmp -in in.lj -pk omp 2 -sf omp
+-------------
 
+MPI parallelization will work for *all* functionality in LAMMPS and in
+many cases the MPI parallelization is more efficient than
+multi-threading since LAMMPS was designed from ground up for MPI
+parallelization using domain decomposition.  Multi-threading is only
+available for selected styles and implemented on top of the MPI
+parallelization.  Multi-threading is most useful for systems with large
+load imbalances when using domain decomposition and a smaller number
+of threads (<= 8).

doc/src/Speed_gpu.rst

@@ -31,7 +31,8 @@ Coulombics.  It has the following general features:
   (for Nvidia GPUs, AMD GPUs, Intel GPUs, and multicore CPUs).
   so that the same functionality is supported on a variety of hardware.
 
-**Required hardware/software:**
+Required hardware/software
+""""""""""""""""""""""""""
 
 To compile and use this package in CUDA mode, you currently need
 to have an NVIDIA GPU and install the corresponding NVIDIA CUDA
@@ -69,12 +70,14 @@ To compile and use this package in HIP mode, you have to have the AMD ROCm
 software installed. Versions of ROCm older than 3.5 are currently deprecated
 by AMD.
 
-**Building LAMMPS with the GPU package:**
+Building LAMMPS with the GPU package
+""""""""""""""""""""""""""""""""""""
 
 See the :ref:`Build extras <gpu>` page for
 instructions.
 
-**Run with the GPU package from the command line:**
+Run with the GPU package from the command-line
+""""""""""""""""""""""""""""""""""""""""""""""
 
 The ``mpirun`` or ``mpiexec`` command sets the total number of MPI tasks
 used by LAMMPS (one or multiple per compute node) and the number of MPI
@@ -133,7 +136,8 @@ affect the setting for bonded interactions (LAMMPS default is "on").
 The "off" setting for pairwise interaction is currently required for
 GPU package pair styles.
 
-**Or run with the GPU package by editing an input script:**
+Run with the GPU package by editing an input script
+"""""""""""""""""""""""""""""""""""""""""""""""""""
 
 The discussion above for the ``mpirun`` or ``mpiexec`` command, MPI
 tasks/node, and use of multiple MPI tasks/GPU is the same.
@@ -149,7 +153,8 @@ You must also use the :doc:`package gpu <package>` command to enable the
 GPU package, unless the ``-sf gpu`` or ``-pk gpu`` :doc:`command-line switches <Run_options>` were used.  It specifies the number of
 GPUs/node to use, as well as other options.
 
-**Speed-ups to expect:**
+Speed-up to expect
+""""""""""""""""""
 
 The performance of a GPU versus a multicore CPU is a function of your
 hardware, which pair style is used, the number of atoms/GPU, and the
@@ -176,10 +181,13 @@ better with multiple OMP threads because the inter-process communication
 is higher for these styles with the GPU package in order to allow
 deterministic results.
 
-**Guidelines for best performance:**
+Guidelines for best performance
+"""""""""""""""""""""""""""""""
 
-* Using multiple MPI tasks per GPU will often give the best performance,
-  as allowed my most multicore CPU/GPU configurations.
+* Using multiple MPI tasks (2-10) per GPU will often give the best
+  performance, as allowed my most multicore CPU/GPU configurations.
+  Using too many MPI tasks will result in worse performance due to
+  growing overhead with the growing number of MPI tasks.
 * If the number of particles per MPI task is small (e.g. 100s of
   particles), it can be more efficient to run with fewer MPI tasks per
   GPU, even if you do not use all the cores on the compute node.
@@ -199,12 +207,13 @@ deterministic results.
   :doc:`angle <angle_style>`, :doc:`dihedral <dihedral_style>`,
   :doc:`improper <improper_style>`, and :doc:`long-range <kspace_style>`
   calculations will not be included in the "Pair" time.
-* Since only part of the pppm kspace style is GPU accelerated, it
-  may be faster to only use GPU acceleration for Pair styles with
-  long-range electrostatics.  See the "pair/only" keyword of the
-  package command for a shortcut to do that.  The work between kspace
-  on the CPU and non-bonded interactions on the GPU can be balanced
-  through adjusting the coulomb cutoff without loss of accuracy.
+* Since only part of the pppm kspace style is GPU accelerated, it may be
+  faster to only use GPU acceleration for Pair styles with long-range
+  electrostatics.  See the "pair/only" keyword of the :doc:`package
+  command <package>` for a shortcut to do that.  The distribution of
+  work between kspace on the CPU and non-bonded interactions on the GPU
+  can be balanced through adjusting the coulomb cutoff without loss of
+  accuracy.
 * When the *mode* setting for the package gpu command is force/neigh,
   the time for neighbor list calculations on the GPU will be added into
   the "Pair" time, not the "Neigh" time.  An additional breakdown of the
@@ -220,4 +229,6 @@ deterministic results.
 Restrictions
 """"""""""""
 
-None.
+When using :doc:`hybrid pair styles <pair_hybrid>`, the neighbor list
+must be generated on the host instead of the GPU and thus the potential
+GPU acceleration is reduced.

doc/src/Speed_intel.rst

@@ -1,5 +1,5 @@
 INTEL package
-==================
+=============
 
 The INTEL package is maintained by Mike Brown at Intel
 Corporation.  It provides two methods for accelerating simulations,
@@ -13,18 +13,18 @@ twice, once on the CPU and once with an offload flag. This allows
 LAMMPS to run on the CPU cores and co-processor cores simultaneously.
 
 Currently Available INTEL Styles
-"""""""""""""""""""""""""""""""""""""
+""""""""""""""""""""""""""""""""
 
 * Angle Styles: charmm, harmonic
-* Bond Styles: fene, fourier, harmonic
+* Bond Styles: fene, harmonic
 * Dihedral Styles: charmm, fourier, harmonic, opls
-* Fixes: nve, npt, nvt, nvt/sllod, nve/asphere
+* Fixes: nve, npt, nvt, nvt/sllod, nve/asphere, electrode/conp, electrode/conq, electrode/thermo
 * Improper Styles: cvff, harmonic
 * Pair Styles: airebo, airebo/morse, buck/coul/cut, buck/coul/long,
   buck, dpd, eam, eam/alloy, eam/fs, gayberne, lj/charmm/coul/charmm,
   lj/charmm/coul/long, lj/cut, lj/cut/coul/long, lj/long/coul/long,
-  rebo, sw, tersoff
-* K-Space Styles: pppm, pppm/disp
+  rebo, snap, sw, tersoff
+* K-Space Styles: pppm, pppm/disp, pppm/electrode
 
 .. warning::
 
@@ -33,7 +33,7 @@ Currently Available INTEL Styles
    input requires it, LAMMPS will abort with an error message.
 
 Speed-up to expect
-"""""""""""""""""""
+""""""""""""""""""
 
 The speedup will depend on your simulation, the hardware, which
 styles are used, the number of atoms, and the floating-point
@@ -312,21 +312,21 @@ almost all cases.
    recommended, especially when running on a machine with Intel
    Hyper-Threading technology disabled.
 
-Run with the INTEL package from the command line
-"""""""""""""""""""""""""""""""""""""""""""""""""""""
+Run with the INTEL package from the command-line
+""""""""""""""""""""""""""""""""""""""""""""""""
 
-To enable INTEL optimizations for all available styles used in
-the input script, the ``-sf intel`` :doc:`command-line switch <Run_options>` can be used without any requirement for
-editing the input script. This switch will automatically append
-"intel" to styles that support it. It also invokes a default command:
-:doc:`package intel 1 <package>`. This package command is used to set
-options for the INTEL package.  The default package command will
-specify that INTEL calculations are performed in mixed precision,
-that the number of OpenMP threads is specified by the OMP_NUM_THREADS
-environment variable, and that if co-processors are present and the
-binary was built with offload support, that 1 co-processor per node
-will be used with automatic balancing of work between the CPU and the
-co-processor.
+To enable INTEL optimizations for all available styles used in the input
+script, the ``-sf intel`` :doc:`command-line switch <Run_options>` can
+be used without any requirement for editing the input script. This
+switch will automatically append "intel" to styles that support it. It
+also invokes a default command: :doc:`package intel 1 <package>`. This
+package command is used to set options for the INTEL package.  The
+default package command will specify that INTEL calculations are
+performed in mixed precision, that the number of OpenMP threads is
+specified by the OMP_NUM_THREADS environment variable, and that if
+co-processors are present and the binary was built with offload support,
+that 1 co-processor per node will be used with automatic balancing of
+work between the CPU and the co-processor.
 
 You can specify different options for the INTEL package by using
 the ``-pk intel Nphi`` :doc:`command-line switch <Run_options>` with

doc/src/Speed_kokkos.rst

@@ -77,7 +77,7 @@ version 23 November 2023 and Kokkos version 4.2.
    rank.  When running with multiple MPI ranks, you may see segmentation
    faults without GPU-aware MPI support. These can be avoided by adding
    the flags :doc:`-pk kokkos gpu/aware off <Run_options>` to the
-   LAMMPS command line or by using the command :doc:`package kokkos
+   LAMMPS command-line or by using the command :doc:`package kokkos
    gpu/aware off <package>` in the input file.
 
 .. admonition:: Intel Data Center GPU support
@@ -423,7 +423,7 @@ in the ``kokkos-cuda.cmake`` CMake preset file.
    cmake -DKokkos_ENABLE_CUDA=yes -DKokkos_ENABLE_OPENMP=yes ../cmake
 
 The suffix "/kk" is equivalent to "/kk/device", and for Kokkos CUDA,
-using the ``-sf kk`` in the command line gives the default CUDA version
+using the ``-sf kk`` in the command-line gives the default CUDA version
 everywhere.  However, if the "/kk/host" suffix is added to a specific
 style in the input script, the Kokkos OpenMP (CPU) version of that
 specific style will be used instead.  Set the number of OpenMP threads
@@ -439,7 +439,7 @@ For example, the command to run with 1 GPU and 8 OpenMP threads is then:
 
    mpiexec -np 1 lmp_kokkos_cuda_openmpi -in in.lj -k on g 1 t 8 -sf kk
 
-Conversely, if the ``-sf kk/host`` is used in the command line and then
+Conversely, if the ``-sf kk/host`` is used in the command-line and then
 the "/kk" or "/kk/device" suffix is added to a specific style in your
 input script, then only that specific style will run on the GPU while
 everything else will run on the CPU in OpenMP mode. Note that the
@@ -451,7 +451,7 @@ on the host CPU can overlap with a pair style running on the
 GPU. First compile with ``--default-stream per-thread`` added to ``CCFLAGS``
 in the Kokkos CUDA Makefile.  Then explicitly use the "/kk/host"
 suffix for kspace and bonds, angles, etc.  in the input file and the
-"kk" suffix (equal to "kk/device") on the command line.  Also make
+"kk" suffix (equal to "kk/device") on the command-line.  Also make
 sure the environment variable ``CUDA_LAUNCH_BLOCKING`` is not set to "1"
 so CPU/GPU overlap can occur.
 

doc/src/Speed_omp.rst

@@ -21,7 +21,7 @@ Building LAMMPS with the OPENMP package
 See the :ref:`Build extras <openmp>` page for
 instructions.
 
-Run with the OPENMP package from the command line
+Run with the OPENMP package from the command-line
 """""""""""""""""""""""""""""""""""""""""""""""""""
 
 These examples assume one or more 16-core nodes.

doc/src/Speed_opt.rst

@@ -17,7 +17,7 @@ Building LAMMPS with the OPT package
 
 See the :ref:`Build extras <opt>` page for instructions.
 
-Run with the OPT package from the command line
+Run with the OPT package from the command-line
 """"""""""""""""""""""""""""""""""""""""""""""
 
 .. code-block:: bash

doc/src/Tools.rst

@@ -501,7 +501,7 @@ Here are a few highlights of LAMMPS-GUI
 - Indicator for line that caused an error
 - Visualization of current state in Image Viewer (via calling :doc:`write_dump image <dump_image>`)
 - Capture of images created via :doc:`dump image <dump_image>` in Slide show window
-- Dialog to set variables, similar to the LAMMPS command line flag '-v' / '-var'
+- Dialog to set variables, similar to the LAMMPS command-line flag '-v' / '-var'
 - Support for GPU, INTEL, KOKKOS/OpenMP, OPENMAP, and OPT and accelerator packages
 
 Parallelization
@@ -550,7 +550,7 @@ will be found automatically.  2) you can download the `Flatpak file
 *flatpak* command: ``flatpak install --user
 LAMMPS-Linux-x86_64-GUI-<version>.flatpak`` and run it with ``flatpak
 run org.lammps.lammps-gui``.  The flatpak bundle also includes the
-command line version of LAMMPS and some LAMMPS tools like msi2lmp.  The
+command-line version of LAMMPS and some LAMMPS tools like msi2lmp.  The
 can be launched by using the ``--command`` flag. For example to run
 LAMMPS directly on the ``in.lj`` benchmark input you would type in the
 ``bench`` folder: ``flatpak run --command=lmp -in in.lj`` The flatpak
@@ -608,10 +608,10 @@ would be the ``examples/COUPLE/plugin`` folder of the LAMMPS
 distribution.
 
 When compiling LAMMPS-GUI with plugin support, there is an additional
-command line flag (``-p <path>`` or ``--pluginpath <path>``) which
+command-line flag (``-p <path>`` or ``--pluginpath <path>``) which
 allows to override the path to LAMMPS shared library used by the GUI.
 This is usually auto-detected on the first run and can be changed in the
-LAMMPS-GUI *Preferences* dialog.  The command line flag allows to reset
+LAMMPS-GUI *Preferences* dialog.  The command-line flag allows to reset
 this path to a valid value in case the original setting has become
 invalid.  An empty path ("") as argument restores the default setting.
 
@@ -656,7 +656,7 @@ it will create a compressed ``LAMMPS-Win10-amd64.zip`` zip file with the
 executables and required dependent .dll files.  This zip file can be
 uncompressed and ``lammps-gui.exe`` run directly from there.  The
 uncompressed folder can be added to the ``PATH`` environment and LAMMPS
-and LAMMPS-GUI can be launched from anywhere from the command line.
+and LAMMPS-GUI can be launched from anywhere from the command-line.
 
 **MinGW64 Cross-compiler**
 
@@ -876,7 +876,7 @@ the same ``LAMMPS_CACHING_DIR``. This script does the following:
  #. Start a simple local HTTP server using Python to host files for CMake
 
 Afterwards, it will print out instruction on how to modify the CMake
-command line to make sure it uses the local HTTP server.
+commands to make sure it uses the local HTTP server.
 
 To undo the environment changes and shutdown the local HTTP server,
 run the ``deactivate_caches`` command.
@@ -1022,10 +1022,10 @@ regression tests with a given LAMMPS binary.  The tool launches the
 LAMMPS binary with any given input script under one of the `examples`
 subdirectories, and compares the thermo output in the generated log file
 with those in the provided log file with the same number of processors
-ub the same subdirectory. If the differences between the actual and
+in the same subdirectory. If the differences between the actual and
 reference values are within specified tolerances, the test is considered
 passed.  For each test batch, that is, a set of example input scripts,
-the mpirun command, the LAMMPS command line arguments, and the
+the mpirun command, the LAMMPS command-line arguments, and the
 tolerances for individual thermo quantities can be specified in a
 configuration file in YAML format.
 

doc/src/angles.rst

@@ -1,8 +0,0 @@
-Angle Styles
-############
-
-.. toctree::
-   :maxdepth: 1
-   :glob:
-
-   angle_*

doc/src/bond_bpm_rotational.rst

@@ -132,8 +132,8 @@ or :doc:`read_restart <read_restart>` commands:
 * :math:`k_b`           (force*distance/radians units)
 * :math:`f_{r,c}`       (force units)
 * :math:`f_{s,c}`       (force units)
-* :math:`\tau_{b,c}`    (force*distance units)
 * :math:`\tau_{t,c}`    (force*distance units)
+* :math:`\tau_{b,c}`    (force*distance units)
 * :math:`\gamma_n`      (force/velocity units)
 * :math:`\gamma_s`      (force/velocity units)
 * :math:`\gamma_r`      (force*distance/velocity units)
@@ -154,8 +154,11 @@ page on BPMs.
 
 If the *break* keyword is set to *no*, LAMMPS assumes bonds should not break
 during a simulation run. This will prevent some unnecessary calculation.
-However, if a bond reaches a damage criterion greater than one,
-it will trigger an error.
+The recommended bond communication distance no longer depends on bond failure
+coefficients (which are ignored) but instead corresponds to the typical heuristic
+maximum strain used by typical non-bpm bond styles. Similar behavior to *break no*
+can also be attained by setting arbitrarily high values for all four failure
+coefficients. One cannot use *break no* with *smooth yes*.
 
 If the *store/local* keyword is used, an internal fix will track bonds that
 break during the simulation. Whenever a bond breaks, data is processed

doc/src/bond_bpm_spring.rst

@@ -10,7 +10,7 @@ Syntax
 
    bond_style bpm/spring keyword value attribute1 attribute2 ...
 
-* optional keyword = *overlay/pair* or *store/local* or *smooth* or *break*
+* optional keyword = *overlay/pair* or *store/local* or *smooth* or *break* or *volume/factor*
 
   .. parsed-literal::
 
@@ -36,6 +36,9 @@ Syntax
        *break* value = *yes* or *no*
           indicates whether bonds break during a run
 
+       *volume/factor* value = *yes* or *no*
+          indicates whether forces include the volumetric contribution
+
 Examples
 """"""""
 
@@ -44,6 +47,9 @@ Examples
    bond_style bpm/spring
    bond_coeff 1 1.0 0.05 0.1
 
+   bond_style bpm/spring volume/factor yes
+   bond_coeff 1 1.0 0.05 0.1 0.5
+
    bond_style bpm/spring myfix 1000 time id1 id2
    dump 1 all local 1000 dump.broken f_myfix[1] f_myfix[2] f_myfix[3]
    dump_modify 1 write_header no
@@ -97,15 +103,6 @@ approach the critical strain
 
    w = 1.0 - \left( \frac{r - r_0}{r_0 \epsilon_c} \right)^8 .
 
-The following coefficients must be defined for each bond type via the
-:doc:`bond_coeff <bond_coeff>` command as in the example above, or in
-the data file or restart files read by the :doc:`read_data
-<read_data>` or :doc:`read_restart <read_restart>` commands:
-
-* :math:`k`             (force/distance units)
-* :math:`\epsilon_c`    (unit less)
-* :math:`\gamma`        (force/velocity units)
-
 If the *normalize* keyword is set to *yes*, the elastic bond force will be
 normalized by :math:`r_0` such that :math:`k` must be given in force units.
 
@@ -120,8 +117,48 @@ page on BPMs.
 
 If the *break* keyword is set to *no*, LAMMPS assumes bonds should not break
 during a simulation run. This will prevent some unnecessary calculation.
-However, if a bond reaches a strain greater than :math:`\epsilon_c`,
-it will trigger an error.
+The recommended bond communication distance no longer depends on the value of
+:math:`\epsilon_c` (which is ignored) but instead corresponds to the typical
+heuristic maximum strain used by typical non-bpm bond styles. Similar behavior
+to *break no* can also be attained by setting an arbitrarily high value of
+:math:`\epsilon_c`. One cannot use *break no* with *smooth yes*.
+
+.. versionadded:: TBD
+
+The *volume/factor* keyword toggles whether an additional multibody
+contribution is added to he force using the formulation in
+:ref:`(Clemmer2) <multibody-Clemmer>`,
+
+.. math::
+
+   \alpha_v \left(\left[\frac{V_i + V_j}{V_{0,i} + V_{0,j}}\right]^{1/3} - \frac{r_{ij}}{r_{0,ij}}\right)
+
+where :math:`\alpha_v` is a user specified coefficient and :math:`V_i`
+and :math:`V_{0,i}` are estimates of the current and local volume
+of atom :math:`i`. These volumes are calculated as the sum of current
+or initial bond lengths cubed. In 2D, the volume is replaced with an area
+calculated using bond lengths squared and the cube root in the above equation
+is accordingly replaced with a square root. This approximation assumes bonds
+are evenly distributed on a spherical surface and neglects constant prefactors
+which are irrelevant since only the ratio of volumes matters. This term may be
+used to adjust the Poisson's ratio.
+
+If a bond is broken (or created), :math:`V_{0,i}` is updated by subtracting
+(or adding) that bond's contribution.
+
+The following coefficients must be defined for each bond type via the
+:doc:`bond_coeff <bond_coeff>` command as in the example above, or in
+the data file or restart files read by the :doc:`read_data
+<read_data>` or :doc:`read_restart <read_restart>` commands:
+
+* :math:`k`             (force/distance units)
+* :math:`\epsilon_c`    (unit less)
+* :math:`\gamma`        (force/velocity units)
+
+Additionally, if *volume/factor* is set to *yes*, a fourth coefficient
+must be provided:
+
+* :math:`a_v`           (force units)
 
 If the *store/local* keyword is used, an internal fix will track bonds that
 break during the simulation. Whenever a bond breaks, data is processed
@@ -213,7 +250,7 @@ Related commands
 Default
 """""""
 
-The option defaults are *overlay/pair* = *no*, *smooth* = *yes*, *normalize* = *no*, and *break* = *yes*
+The option defaults are *overlay/pair* = *no*, *smooth* = *yes*, *normalize* = *no*, *break* = *yes*, and *volume/factor* = *no*
 
 ----------
 
@@ -224,3 +261,7 @@ The option defaults are *overlay/pair* = *no*, *smooth* = *yes*, *normalize* = *
 .. _Groot4:
 
 **(Groot)** Groot and Warren, J Chem Phys, 107, 4423-35 (1997).
+
+.. _multibody-Clemmer:
+
+**(Clemmer2)** Clemmer, Monti, Lechman, Soft Matter, 20, 1702 (2024).

doc/src/bonds.rst

@@ -1,8 +0,0 @@
-Bond Styles
-###########
-
-.. toctree::
-   :maxdepth: 1
-   :glob:
-
-   bond_*

doc/src/compute_angle_local.rst

@@ -78,7 +78,7 @@ system and output the statistics in various ways:
    compute 2 all angle/local eng theta v_cos v_cossq set theta t
    dump 1 all local 100 tmp.dump c_1[*] c_2[*]
 
-   compute 3 all reduce ave c_2[*]
+   compute 3 all reduce ave c_2[*] inputs local
    thermo_style custom step temp press c_3[*]
 
    fix 10 all ave/histo 10 10 100 -1 1 20 c_2[3] mode vector file tmp.histo

doc/src/compute_bond_local.rst

@@ -139,7 +139,7 @@ output the statistics in various ways:
    compute 2 all bond/local engpot dist v_dsq set dist d
    dump 1 all local 100 tmp.dump c_1[*] c_2[*]
 
-   compute 3 all reduce ave c_2[*]
+   compute 3 all reduce ave c_2[*] inputs local
    thermo_style custom step temp press c_3[*]
 
    fix 10 all ave/histo 10 10 100 0 6 20 c_2[3] mode vector file tmp.histo

doc/src/compute_composition_atom.rst

@@ -88,6 +88,10 @@ too frequently.
 
 ----------
 
+.. include:: accel_styles.rst
+
+----------
+
 Output info
 """""""""""
 

doc/src/compute_dihedral_local.rst

@@ -76,7 +76,7 @@ angle in the system and output the statistics in various ways:
    compute 2 all dihedral/local phi v_cos v_cossq set phi p
    dump 1 all local 100 tmp.dump c_1[*] c_2[*]
 
-   compute 3 all reduce ave c_2[*]
+   compute 3 all reduce ave c_2[*] inputs local
    thermo_style custom step temp press c_3[*]
 
    fix 10 all ave/histo 10 10 100 -1 1 20 c_2[2] mode vector file tmp.histo

doc/src/compute_pressure.rst

@@ -125,10 +125,6 @@ where thermo_temp is the ID of a similarly defined compute of style
 
 ----------
 
-.. include:: accel_styles.rst
-
-----------
-
 Output info
 """""""""""
 

doc/src/compute_reduce.rst

@@ -206,11 +206,13 @@ IDs and the bond stretch will be printed with thermodynamic output.
 
 The *inputs* keyword allows selection of whether all the inputs are
 per-atom or local quantities.  As noted above, all the inputs must be
-the same kind (per-atom or local).  Per-atom is the default setting.
-If a compute or fix is specified as an input, it must produce per-atom
-or local data to match this setting.  If it produces both, e.g. for
+the same kind (per-atom or local).  Per-atom is the default setting.  If
+a compute or fix is specified as an input, it must produce per-atom or
+local data to match this setting.  If it produces both, like for example
 the :doc:`compute voronoi/atom <compute_voronoi_atom>` command, then
-this keyword selects between them.
+this keyword selects between them.  If a compute *only* produces local
+data, like for example the :doc:`compute bond/local command
+<compute_bond_local>`, the setting "inputs local" is *required*.
 
 ----------
 

doc/src/compute_reduce_chunk.rst

@@ -37,55 +37,57 @@ Description
 
 Define a calculation that reduces one or more per-atom vectors into
 per-chunk values.  This can be useful for diagnostic output.  Or when
-used in conjunction with the :doc:`compute chunk/spread/atom <compute_chunk_spread_atom>` command it can be
-used to create per-atom values that induce a new set of chunks with a
-second :doc:`compute chunk/atom <compute_chunk_atom>` command.  An
-example is given below.
+used in conjunction with the :doc:`compute chunk/spread/atom
+<compute_chunk_spread_atom>` command it can be used to create per-atom
+values that induce a new set of chunks with a second :doc:`compute
+chunk/atom <compute_chunk_atom>` command.  An example is given below.
 
-In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
-to a single chunk (or no chunk).  The ID for this command is specified
-as chunkID.  For example, a single chunk could be the atoms in a
-molecule or atoms in a spatial bin.  See the :doc:`compute chunk/atom <compute_chunk_atom>` and :doc:`Howto chunk <Howto_chunk>`
-doc pages for details of how chunks can be defined and examples of how
-they can be used to measure properties of a system.
+In LAMMPS, chunks are collections of atoms defined by a :doc:`compute
+chunk/atom <compute_chunk_atom>` command, which assigns each atom to a
+single chunk (or no chunk).  The ID for this command is specified as
+chunkID.  For example, a single chunk could be the atoms in a molecule
+or atoms in a spatial bin.  See the :doc:`compute chunk/atom
+<compute_chunk_atom>` and :doc:`Howto chunk <Howto_chunk>` doc pages for
+details of how chunks can be defined and examples of how they can be
+used to measure properties of a system.
 
 For each atom, this compute accesses its chunk ID from the specified
-*chunkID* compute.  The per-atom value from an input contributes
-to a per-chunk value corresponding the the chunk ID.
+*chunkID* compute.  The per-atom value from an input contributes to a
+per-chunk value corresponding the chunk ID.
 
 The reduction operation is specified by the *mode* setting and is
 performed over all the per-atom values from the atoms in each chunk.
-The *sum* option adds the pre-atom values to a per-chunk total.  The
-*min* or *max* options find the minimum or maximum value of the
-per-atom values for each chunk.
+The *sum* option adds the per-atom values to a per-chunk total.  The
+*min* or *max* options find the minimum or maximum value of the per-atom
+values for each chunk.
 
-Note that only atoms in the specified group contribute to the
-reduction operation.  If the *chunkID* compute returns a 0 for the
-chunk ID of an atom (i.e., the atom is not in a chunk defined by the
-:doc:`compute chunk/atom <compute_chunk_atom>` command), that atom will
-also not contribute to the reduction operation.  An input that is a
-compute or fix may define its own group which affects the quantities
-it returns.  For example, a compute with return a zero value for atoms
-that are not in the group specified for that compute.
+Note that only atoms in the specified group contribute to the reduction
+operation.  If the *chunkID* compute returns a 0 for the chunk ID of an
+atom (i.e., the atom is not in a chunk defined by the :doc:`compute
+chunk/atom <compute_chunk_atom>` command), that atom will also not
+contribute to the reduction operation.  An input that is a compute or
+fix may define its own group which affects the quantities it returns.
+For example, a compute will return a zero value for atoms that are not
+in the group specified for that compute.
 
 Each listed input is operated on independently.  Each input can be the
-result of a :doc:`compute <compute>` or :doc:`fix <fix>` or the evaluation
-of an atom-style :doc:`variable <variable>`.
+result of a :doc:`compute <compute>` or :doc:`fix <fix>` or the
+evaluation of an atom-style :doc:`variable <variable>`.
 
-Note that for values from a compute or fix, the bracketed index I can
-be specified using a wildcard asterisk with the index to effectively
+Note that for values from a compute or fix, the bracketed index I can be
+specified using a wildcard asterisk with the index to effectively
 specify multiple values.  This takes the form "\*" or "\*n" or "m\*" or
-"m\*n".  If :math:`N` is the size of the vector (for *mode* = scalar) or the
-number of columns in the array (for *mode* = vector), then an asterisk
-with no numeric values means all indices from 1 to :math:`N`.  A leading
-asterisk means all indices from 1 to n (inclusive).  A trailing
-asterisk means all indices from n to :math:`N` (inclusive).  A middle asterisk
-means all indices from m to n (inclusive).
+"m\*n".  If :math:`N` is the size of the vector (for *mode* = scalar) or
+the number of columns in the array (for *mode* = vector), then an
+asterisk with no numeric values means all indices from 1 to :math:`N`.
+A leading asterisk means all indices from 1 to n (inclusive).  A
+trailing asterisk means all indices from n to :math:`N` (inclusive).  A
+middle asterisk means all indices from m to n (inclusive).
 
 Using a wildcard is the same as if the individual columns of the array
-had been listed one by one.  For example, the following two compute reduce/chunk
-commands are equivalent, since the
-:doc:`compute property/chunk <compute_property_chunk>` command creates a per-atom
+had been listed one by one.  For example, the following two compute
+reduce/chunk commands are equivalent, since the :doc:`compute
+property/chunk <compute_property_chunk>` command creates a per-atom
 array with 3 columns:
 
 .. code-block:: LAMMPS
@@ -164,13 +166,14 @@ Output info
 """""""""""
 
 This compute calculates a global vector if a single input value is
-specified, otherwise a global array is output.  The number of columns
-in the array is the number of inputs provided.  The length of the
-vector or the number of vector elements or array rows = the number of
-chunks *Nchunk* as calculated by the specified :doc:`compute chunk/atom <compute_chunk_atom>` command.  The vector or array can
-be accessed by any command that uses global values from a compute as
-input.  See the :doc:`Howto output <Howto_output>` page for an
-overview of LAMMPS output options.
+specified, otherwise a global array is output.  The number of columns in
+the array is the number of inputs provided.  The length of the vector or
+the number of vector elements or array rows = the number of chunks
+*Nchunk* as calculated by the specified :doc:`compute chunk/atom
+<compute_chunk_atom>` command.  The vector or array can be accessed by
+any command that uses global values from a compute as input.  See the
+:doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
+options.
 
 The per-atom values for the vector or each column of the array will be
 in whatever :doc:`units <units>` the corresponding input value is in.
@@ -183,7 +186,9 @@ Restrictions
 Related commands
 """"""""""""""""
 
-:doc:`compute chunk/atom <compute_chunk_atom>`, :doc:`compute reduce <compute_reduce>`, :doc:`compute chunk/spread/atom <compute_chunk_spread_atom>`
+:doc:`compute chunk/atom <compute_chunk_atom>`,
+:doc:`compute reduce <compute_reduce>`,
+:doc:`compute chunk/spread/atom <compute_chunk_spread_atom>`
 
 Default
 """""""

doc/src/compute_rheo_property_atom.rst

@@ -81,7 +81,7 @@ includes *xx*, *xy*, *yx*, and *yy*. In 3D, this includes *xx*, *xy*, *xz*,
 Many properties require their respective fixes, listed below in related
 commands, be defined. For instance, the *viscosity* attribute is the
 viscosity of a particle calculated by
-:doc:`fix rheo/viscous <fix_rheo_viscosity>`. The meaning of less obvious
+:doc:`fix rheo/viscosity <fix_rheo_viscosity>`. The meaning of less obvious
 properties is described below.
 
 The *phase* property indicates whether the particle is in a fluid state,

doc/src/compute_sph_e_atom.rst

@@ -33,6 +33,12 @@ particle.
 See `this PDF guide <PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in
 LAMMPS.
 
+.. 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.
+
 The value of the internal energy will be 0.0 for atoms not in the
 specified compute group.
 

doc/src/compute_sph_rho_atom.rst

@@ -32,6 +32,12 @@ kernel function interpolation using "pair style sph/rhosum".
 See `this PDF guide <PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in
 LAMMPS.
 
+.. 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.
+
 The value of the SPH density will be 0.0 for atoms not in the
 specified compute group.
 

doc/src/compute_sph_t_atom.rst

@@ -37,6 +37,12 @@ particles, i.e. a Smooth-Particle Hydrodynamics particle.
 See `this PDF guide <PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in
 LAMMPS.
 
+.. 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.
+
 The value of the internal energy will be 0.0 for atoms not in the
 specified compute group.
 

doc/src/compute_stress_curvilinear.rst

@@ -87,7 +87,7 @@ This array can be output with :doc:`fix ave/time <fix_ave_time>`,
 
 .. code-block:: LAMMPS
 
-  compute 1 all stress/spherical 0 0 0 0.1 10
+  compute p all stress/spherical 0 0 0 0.1 10
   fix 2 all ave/time 100 1 100 c_p[*] file dump_p.out mode vector
 
 The values calculated by this compute are "intensive".  The stress

doc/src/compute_stress_mop.rst

@@ -129,6 +129,9 @@ package <Build_package>` doc page on for more info.
 The method is implemented for orthogonal simulation boxes whose
 size does not change in time, and axis-aligned planes.
 
+Contributions from bonds, angles, and dihedrals are not compatible
+with MPI parallel runs.
+
 The method only works with two-body pair interactions, because it
 requires the class method ``Pair::single()`` to be implemented, which is
 not possible for manybody potentials.  In particular, compute

doc/src/compute_temp_chunk.rst

@@ -184,11 +184,24 @@ temp/chunk calculation to a file is to use the
 The keyword/value option pairs are used in the following ways.
 
 The *com* keyword can be used with a value of *yes* to subtract the
-velocity of the center-of-mass for each chunk from the velocity of the
-atoms in that chunk, before calculating either the global or per-chunk
-temperature.  This can be useful if the atoms are streaming or
+velocity of the center-of-mass (VCM) for each chunk from the velocity of
+the atoms in that chunk, before calculating either the global or per-chunk
+temperature. This can be useful if the atoms are streaming or
 otherwise moving collectively, and you wish to calculate only the
-thermal temperature.
+thermal temperature. This per-chunk VCM bias can be used in other fixes and
+computes that can incorporate a temperature bias. If this compute is used
+as a temperature bias in other commands then this bias is subtracted from
+each atom, the command runs with the remaining thermal velocities, and
+then the bias is added back in. This includes thermostatting
+fixes like :doc:`fix nvt <fix_nh>`,
+:doc:`fix temp/rescale <fix_temp_rescale>`,
+:doc:`fix temp/berendsen <fix_temp_berendsen>`, and
+:doc:`fix langevin <fix_langevin>`, and computes like
+:doc:`compute stress/atom <compute_stress_atom>` and
+:doc:`compute pressure <compute_pressure>`. See the input script in
+examples/stress_vcm for an example of how to use the *com* keyword in
+conjunction with compute stress/atom to create a stress profile of a rigid
+body while removing the overall motion of the rigid body.
 
 For the *bias* keyword, *bias-ID* refers to the ID of a temperature
 compute that removes a "bias" velocity from each atom.  This also

doc/src/compute_temp_deform.rst

@@ -128,6 +128,12 @@ See the :doc:`Howto thermostat <Howto_thermostat>` page for a
 discussion of different ways to compute temperature and perform
 thermostatting.
 
+----------
+
+.. include:: accel_styles.rst
+
+----------
+
 Output info
 """""""""""
 

doc/src/compute_temp_partial.rst

@@ -46,7 +46,7 @@ degrees of freedom.
 
 A symmetric tensor, stored as a six-element vector, is also calculated
 by this compute for use in the computation of a pressure tensor by the
-:doc:`compute pressue <compute_pressure>` command.  The formula for
+:doc:`compute pressure <compute_pressure>` command.  The formula for
 the components of the tensor is the same as the above expression for
 :math:`E_\mathrm{kin}`, except that the 1/2 factor is NOT included and
 the :math:`v_i^2` is replaced by :math:`v_{i,x} v_{i,y}` for the
@@ -82,12 +82,6 @@ See the :doc:`Howto thermostat <Howto_thermostat>` page for a
 discussion of different ways to compute temperature and perform
 thermostatting.
 
-----------
-
-.. include:: accel_styles.rst
-
-----------
-
 Output info
 """""""""""
 

doc/src/computes.rst

@@ -1,8 +0,0 @@
-Computes
-########
-
-.. toctree::
-   :maxdepth: 1
-   :glob:
-
-   compute_*

doc/src/dihedrals.rst

@@ -1,8 +0,0 @@
-Dihedral Styles
-###############
-
-.. toctree::
-   :maxdepth: 1
-   :glob:
-
-   dihedral_*

doc/src/dump_image.rst

@@ -681,7 +681,7 @@ MPEG or other movie file you can use:
 
 * c) Use FFmpeg
 
-  FFmpeg is a command line tool that is available on many platforms and
+  FFmpeg is a command-line tool that is available on many platforms and
   allows extremely flexible encoding and decoding of movies.
 
   .. code-block:: bash

doc/src/fix.rst

@@ -357,6 +357,7 @@ accelerated styles exist.
 * :doc:`python/move <fix_python_move>` - move particles using a Python function during a simulation run
 * :doc:`qbmsst <fix_qbmsst>` - quantum bath multi-scale shock technique time integrator
 * :doc:`qeq/comb <fix_qeq_comb>` - charge equilibration for COMB potential
+* :doc:`qeq/ctip <fix_qeq>` - charge equilibration for CTIP potential
 * :doc:`qeq/dynamic <fix_qeq>` - charge equilibration via dynamic method
 * :doc:`qeq/fire <fix_qeq>` - charge equilibration via FIRE minimizer
 * :doc:`qeq/point <fix_qeq>` - charge equilibration via point method
@@ -365,6 +366,7 @@ accelerated styles exist.
 * :doc:`qeq/slater <fix_qeq>` - charge equilibration via Slater method
 * :doc:`qmmm <fix_qmmm>` - functionality to enable a quantum mechanics/molecular mechanics coupling
 * :doc:`qtb <fix_qtb>` - implement quantum thermal bath scheme
+* :doc:`qtpie/reaxff <fix_qtpie_reaxff>` - apply QTPIE charge equilibration
 * :doc:`rattle <fix_shake>` - RATTLE constraints on bonds and/or angles
 * :doc:`reaxff/bonds <fix_reaxff_bonds>` - write out ReaxFF bond information
 * :doc:`reaxff/species <fix_reaxff_species>` - write out ReaxFF molecule information

doc/src/fix_acks2_reaxff.rst

@@ -111,7 +111,8 @@ LAMMPS was built with that package. See the :doc:`Build package
 
 This fix does not correctly handle interactions involving multiple
 periodic images of the same atom.  Hence, it should not be used for
-periodic cell dimensions less than :math:`10~\AA`.
+periodic cell dimensions smaller than the non-bonded cutoff radius,
+which is typically :math:`10~\AA` for ReaxFF simulations.
 
 This fix may be used in combination with :doc:`fix efield <fix_efield>`
 and will apply the external electric field during charge equilibration,
@@ -122,7 +123,8 @@ components in non-periodic directions.
 Related commands
 """"""""""""""""
 
-:doc:`pair_style reaxff <pair_reaxff>`, :doc:`fix qeq/reaxff <fix_qeq_reaxff>`
+:doc:`pair_style reaxff <pair_reaxff>`, :doc:`fix qeq/reaxff <fix_qeq_reaxff>`,
+:doc:`fix qtpi/reaxff <fix_qtpie_reaxff>`
 
 Default
 """""""