Merge pull request #4451 from akohlmey/next_release

Step version strings for next feature release

.github/CODEOWNERS

@@ -50,6 +50,7 @@ src/PTM/*             @pmla
 src/QMMM/*            @akohlmey
 src/REACTION/*        @jrgissing
 src/REAXFF/*          @hasanmetin @stanmoore1
+src/RHEO/*            @jtclemm
 src/SCAFACOS/*        @rhalver
 src/SNAP/*            @athomps
 src/SPIN/*            @julient31
@@ -65,6 +66,9 @@ src/MANYBODY/pair_vashishta_table.* @andeplane
 src/MANYBODY/pair_atm.*             @sergeylishchuk
 src/MANYBODY/pair_nb3b_screened.*   @flodesani
 src/REPLICA/*_grem.*                @dstelter92
+src/EXTRA-COMMAND/geturl.*          @akohlmey
+src/EXTRA-COMMAND/group_ndx.*       @akohlmey
+src/EXTRA-COMMAND/ndx_group.*       @akohlmey
 src/EXTRA-COMPUTE/compute_stress_mop*.* @RomainVermorel
 src/EXTRA-COMPUTE/compute_born_matrix.* @Bibobu @athomps
 src/EXTRA-FIX/fix_deform_pressure.* @jtclemm
@@ -95,9 +99,11 @@ src/fix.*                 @sjplimp
 src/force.*               @sjplimp
 src/group.*               @sjplimp
 src/improper.*            @sjplimp
+src/info.*                @akohlmey
 src/kspace.*              @sjplimp
-src/lmptyp.h              @sjplimp
-src/library.*             @sjplimp
+src/lmptype.h             @sjplimp
+src/label_map.*           @jrgissing @akohlmey
+src/library.*             @sjplimp @akohlmey
 src/main.cpp              @sjplimp
 src/min_*.*               @sjplimp
 src/memory.*              @sjplimp
@@ -105,12 +111,12 @@ src/modify.*              @sjplimp @stanmoore1
 src/molecule.*            @sjplimp
 src/my_page.h             @sjplimp
 src/my_pool_chunk.h       @sjplimp
-src/npair*.*              @sjplimp
-src/ntopo*.*              @sjplimp
-src/nstencil*.*           @sjplimp
-src/neighbor.*            @sjplimp
-src/nbin*.*               @sjplimp
-src/neigh_*.*             @sjplimp
+src/npair*.*              @sjplimp @jtclemm
+src/ntopo*.*              @sjplimp @jtclemm
+src/nstencil*.*           @sjplimp @jtclemm
+src/neighbor.*            @sjplimp @jtclemm
+src/nbin*.*               @sjplimp @jtclemm
+src/neigh_*.*             @sjplimp @jtclemm
 src/output.*              @sjplimp
 src/pair.*                @sjplimp
 src/rcb.*                 @sjplimp

.github/release_steps.md

@@ -0,0 +1,199 @@
+# LAMMPS Release Steps
+
+The following notes chronicle the current steps for preparing and
+publishing LAMMPS releases.  For definitions of LAMMPS versions and
+releases, 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.  We currently use a mix of automated tests running on
+either Temple's Jenkins cluster or GitHub workflows.  Those include time
+consuming tests not run on pull requests.  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 or update the 'develop' branch locally, pull the latest
+changes, merge them into 'release' with a fast forward(!) merge, and
+apply a suitable release tag (for historical reasons the tag starts with
+"patch_" followed by the date, and finally push everything back to
+GitHub.  There should be no commits made to 'release' but only
+fast forward merges.  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
+```
+
+Applying this tag will trigger two actions on the Temple Jenkins cluster:
+- The online manual at https://docs.lammps.org/ will be updated to the
+  state of the 'release' branch.  Merges to the 'develop' branch will
+  trigger updating https://docs.lammps.org/latest/ so by reviewing the
+  version of the manual under the "latest" URL, it is possible to preview
+  what the updated release documentation will look like.
+- A downloadable tar archive of the LAMMPS distribution that includes the
+  html format documentation and a PDF of the manual will be created and
+  uploaded to the download server at https://download.lammps.org/tars
+  Note that the file is added, but the `index.html` file is not updated,
+  so it is not yet publicly visible.
+
+Go to https://github.com/lammps/lammps/releases and create a new (draft)
+release page with a summary of all the changes included and references
+to the pull requests they were merged from 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.
+
+### Prepare pre-compiled packages, update packages to GitHub
+
+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.
+A suitable build environment is provided with the
+https://download.lammps.org/static/fedora37_musl.sif container image.
+
+``` sh
+rm -rf release-packages
+mkdir release-packages
+cd release-packages
+wget https://download.lammps.org/static/fedora41_musl.sif
+apptainer shell fedora41_musl.sif
+git clone -b release --depth 10 https://github.com/lammps/lammps.git lammps-release
+cmake -S lammps-release/cmake -B build-release -G Ninja -D CMAKE_INSTALL_PREFIX=$PWD/lammps-static -D CMAKE_TOOLCHAIN_FILE=/usr/musl/share/cmake/linux-musl.cmake -C lammps-release/cmake/presets/most.cmake -C lammps-release/cmake/presets/kokkos-openmp.cmake -D DOWNLOAD_POTENTIALS=OFF -D BUILD_MPI=OFF -D BUILD_TESTING=OFF -D CMAKE_BUILD_TYPE=Release -D PKG_ATC=ON -D PKG_AWPMD=ON -D PKG_MANIFOLD=ON -D PKG_MESONT=ON -D PKG_MGPT=ON -D PKG_ML-PACE=ON -D PKG_ML-RANN=ON -D PKG_MOLFILE=ON -D PKG_PTM=ON -D PKG_QTB=ON -D PKG_SMTBQ=ON
+cmake --build build-release --target all
+cmake --build build-release --target install
+/usr/musl/bin/x86_64-linux-musl-strip lammps-static/bin/*
+tar -czvvf lammps-linux-x86_64-19Nov2024.tar.gz lammps-static
+exit # fedora 41 container
+```
+
+The resulting tar archive can be uploaded to the GitHub release page with:
+
+```
+gh release upload patch_19Nov2024 lammps-linux-x86_64-19Nov2024.tar.gz
+```
+
+Make sure you have the `flatpak` and `flatpak-builder` packages
+installed locally (they cannot be used from the container) and build a
+LAMMPS and LAMMPS-GUI flatpak bundle in the `release-packages` folder
+with:
+
+``` sh
+flatpak --user remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
+flatpak-builder  --force-clean --verbose --repo=$PWD/flatpak-repo --install-deps-from=flathub --state-dir=$PWD --user --ccache --default-branch=release flatpak-build lammps-release/tools/lammps-gui/org.lammps.lammps-gui.yml
+flatpak build-bundle --runtime-repo=https://flathub.org/repo/flathub.flatpakrepo --verbose $PWD/flatpak-repo LAMMPS-Linux-x86_64-GUI-19Nov2024.flatpak org.lammps.lammps-gui release
+```
+
+The resulting flatpak bundle file can be uploaded to the GitHub release page with:
+
+```
+gh release upload patch_19Nov2024 LAMMPS-Linux-x86_64-GUI-19Nov2024.flatpak
+```
+
+Also build serial executable packages that also include LAMMPS-GUI for
+Linux, macOS, and Windows, and upload them to the GitHub release.
+
+Clean up:
+
+``` sh
+cd ..
+rm -r release-packages
+```
+
+TODO:
+- add detailed commands for building GUI packages on Ubuntu 20.04LTS (move to 22.04LTS?),
+  macOS, and Windows cross-compiler and upload to GitHub
+- build all Windows cross-compiled installer packages using lammps-packages repo
+
+### Update download website
+
+Check out the LAMMPS website repo
+https://github.com/lammps/lammps-website.git and edit the file
+`src/download.txt` for the new release.  Test translation with `make
+html` and review `html/download.html` Then add and commit to git and
+push the changes to GitHub.  The Temple Jenkis cluster will
+automatically update https://www.lammps.org/download.html accordingly.
+
+Notify Steve of the release so he can update `src/bug.txt` on the
+website from the available release notes.
+
+## LAMMPS Stable Release
+
+A LAMMPS stable release is prepared about once per year in the months
+July, August, or September.  One (or two, if needed) feature releases
+before the stable release shall contain only bug fixes or minor feature
+updates in optional packages.  Also substantial changes to the core of
+the code shall be applied rather toward the beginning of a development
+cycle between two stable releases than toward the end.  The intention is
+to stablilize significant change to the core and have outside users and
+developers try them out during the development cycle; the sooner the
+changes are included, the better chances for spotting peripheral bugs
+and issues.
+
+### Prerequesites
+
+Before making a stable release all remaining backported bugfixes shall
+be released as a (final) stable update release (see below).
+
+A LAMMPS stable release process starts like a feature release (see
+above), only that this feature release is called a "Stable Release
+Candidate" and no assets are uploaded to GitHub.
+
+### Synchronize 'maintenance' branch with 'release'
+
+The state of the 'release' branch is then transferred to the
+'maintenance' branch (which will have diverged significantly from
+'release' due to the selectively backported bug fixes).
+
+### Fast-forward merge of 'maintenance' into 'stable' and apply tag
+
+At this point it should be possible to do a fast-forward merge of
+'maintenance' to 'stable' and then apply the stable\_DMmmYYYY tag.
+
+### Push branches and tags
+
+
+
+## LAMMPS Stable Update Release

.github/workflows/check-cpp23.yml

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

.github/workflows/check-vla.yml

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

.github/workflows/compile-msvc.yml

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

.github/workflows/coverity.yml

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

.github/workflows/full-regression.yml

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

.github/workflows/kokkos-regression.yaml

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

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

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

.github/workflows/quick-regression.yml

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

.github/workflows/style-check.yml

@@ -0,0 +1,38 @@
+# 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
+         make check-fmtlib

.github/workflows/unittest-arm64.yml

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

.github/workflows/unittest-linux.yml

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

.github/workflows/unittest-macos.yml

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

cmake/CMakeLists.txt

@@ -3,6 +3,9 @@
 # CMake build system
 # This file is part of LAMMPS
 cmake_minimum_required(VERSION 3.16)
+if(CMAKE_VERSION VERSION_LESS 3.20)
+  message(WARNING "LAMMPS is planning to require at least CMake version 3.20 by Summer 2025. Please upgrade!")
+endif()
 ########################################
 # set policy to silence warnings about ignoring <PackageName>_ROOT but use it
 if(POLICY CMP0074)
@@ -12,6 +15,11 @@ endif()
 if(POLICY CMP0075)
   cmake_policy(SET CMP0075 NEW)
 endif()
+# set policy to silence warnings about requiring execute permission for find_program
+# we use OLD because the python-config script for the Fedora MinGW cross-compiler requires it currently
+if(POLICY CMP0109)
+  cmake_policy(SET CMP0109 OLD)
+endif()
 # set policy to silence warnings about timestamps of downloaded files. review occasionally if it may be set to NEW
 if(POLICY CMP0135)
   cmake_policy(SET CMP0135 OLD)
@@ -113,7 +121,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
@@ -136,19 +144,31 @@ endif()
 
 # silence nvcc warnings
 if((PKG_KOKKOS) AND (Kokkos_ENABLE_CUDA) AND NOT (CMAKE_CXX_COMPILER_ID STREQUAL "Clang"))
-  set(CMAKE_TUNE_DEFAULT "${CMAKE_TUNE_DEFAULT} -Xcudafe --diag_suppress=unrecognized_pragma")
+  set(CMAKE_TUNE_DEFAULT "${CMAKE_TUNE_DEFAULT}" "-Xcudafe --diag_suppress=unrecognized_pragma,--diag_suppress=128")
 endif()
 
-# we require C++11 without extensions. Kokkos requires at least C++17 (currently)
+# we *require* C++11 without extensions but prefer C++17.
+# Kokkos requires at least C++17 (currently)
 if(NOT CMAKE_CXX_STANDARD)
-  set(CMAKE_CXX_STANDARD 11)
+  if(cxx_std_17 IN_LIST CMAKE_CXX_COMPILE_FEATURES)
+    set(CMAKE_CXX_STANDARD 17)
+  else()
+    set(CMAKE_CXX_STANDARD 11)
+  endif()
 endif()
 if(CMAKE_CXX_STANDARD LESS 11)
   message(FATAL_ERROR "C++ standard must be set to at least 11")
 endif()
+if(CMAKE_CXX_STANDARD LESS 17)
+  message(WARNING "Selecting C++17 standard is preferred over C++${CMAKE_CXX_STANDARD}")
+endif()
 if(PKG_KOKKOS AND (CMAKE_CXX_STANDARD LESS 17))
   set(CMAKE_CXX_STANDARD 17)
 endif()
+# turn off C++17 check in lmptype.h
+if(LAMMPS_CXX11)
+  add_compile_definitions(LAMMPS_CXX11)
+endif()
 set(CMAKE_CXX_STANDARD_REQUIRED ON)
 set(CMAKE_CXX_EXTENSIONS OFF CACHE BOOL "Use compiler extensions")
 # ugly hacks for MSVC which by default always reports an old C++ standard in the __cplusplus macro
@@ -160,10 +180,27 @@ 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()
 
+# warn about potentially problematic GCC compiler versions
+if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
+  if (CMAKE_CXX_STANDARD GREATER_EQUAL 17)
+    if (CMAKE_CXX_COMPILER_VERSION VERSION_LESS 9.0)
+      message(WARNING "Using ${CMAKE_CXX_COMPILER_ID} compiler version ${CMAKE_CXX_COMPILER_VERSION} "
+        "with C++17 is not recommended. Please use ${CMAKE_CXX_COMPILER_ID} compiler version 9.x or later")
+    endif()
+  endif()
+  if (CMAKE_CXX_STANDARD GREATER_EQUAL 11)
+    if (CMAKE_CXX_COMPILER_VERSION VERSION_LESS 5.0)
+      message(WARNING "Using ${CMAKE_CXX_COMPILER_ID} compiler version ${CMAKE_CXX_COMPILER_VERSION} "
+        "with C++11 is not recommended. Please use ${CMAKE_CXX_COMPILER_ID} compiler version 5.x or later")
+    endif()
+  endif()
+endif()
+
 # export all symbols when building a .dll file on windows
 if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND BUILD_SHARED_LIBS)
   set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
@@ -198,13 +235,12 @@ set(LAMMPS_BINARY lmp${LAMMPS_MACHINE})
 option(BUILD_SHARED_LIBS "Build shared library" OFF)
 option(CMAKE_POSITION_INDEPENDENT_CODE "Create object compatible with shared libraries" ON)
 option(BUILD_TOOLS "Build and install LAMMPS tools (msi2lmp, binary2txt, chain)" OFF)
-option(BUILD_LAMMPS_SHELL "Build and install the LAMMPS shell" OFF)
 option(BUILD_LAMMPS_GUI "Build and install the LAMMPS GUI" OFF)
 
 # Support using clang-tidy for C++ files with selected options
 set(ENABLE_CLANG_TIDY OFF CACHE BOOL "Include clang-tidy processing when compiling")
 if(ENABLE_CLANG_TIDY)
-  set(CMAKE_CXX_CLANG_TIDY "clang-tidy;-checks=-*,performance-trivially-destructible,performance-unnecessary-copy-initialization,performance-unnecessary-value-param,readability-redundant-control-flow,readability-redundant-declaration,readability-redundant-function-ptr-dereference,readability-redundant-member-init,readability-redundant-string-cstr,readability-redundant-string-init,readability-simplify-boolean-expr,readability-static-accessed-through-instance,readability-static-definition-in-anonymous-namespace,modernize-use-override,modernize-use-bool-literals,modernize-use-emplace,modernize-return-braced-init-list,modernize-use-equals-default,modernize-use-equals-delete,modernize-replace-random-shuffle,modernize-deprecated-headers,modernize-use-nullptr,modernize-use-noexcept,modernize-redundant-void-arg;-fix;-header-filter=.*,header-filter=library.h,header-filter=fmt/*.h" CACHE STRING "clang-tidy settings")
+  set(CMAKE_CXX_CLANG_TIDY "clang-tidy;-checks=-*,performance-trivially-destructible,performance-unnecessary-copy-initialization,performance-unnecessary-value-param,readability-redundant-control-flow,readability-redundant-declaration,readability-redundant-function-ptr-dereference,readability-redundant-member-init,readability-redundant-string-cstr,readability-redundant-string-init,readability-simplify-boolean-expr,readability-static-accessed-through-instance,readability-static-definition-in-anonymous-namespace,readability-qualified-auto,misc-unused-parameters,modernize-deprecated-ios-base-aliases,modernize-loop-convert,modernize-shrink-to-fit,modernize-use-auto,modernize-use-using,modernize-use-override,modernize-use-bool-literals,modernize-use-emplace,modernize-return-braced-init-list,modernize-use-equals-default,modernize-use-equals-delete,modernize-replace-random-shuffle,modernize-deprecated-headers,modernize-use-nullptr,modernize-use-noexcept,modernize-redundant-void-arg;-fix;-header-filter=.*,header-filter=library.h,header-filter=fmt/*.h" CACHE STRING "clang-tidy settings")
 else()
   unset(CMAKE_CXX_CLANG_TIDY CACHE)
 endif()
@@ -306,6 +342,7 @@ set(STANDARD_PACKAGES
   REACTION
   REAXFF
   REPLICA
+  RHEO
   RIGID
   SCAFACOS
   SHOCK
@@ -325,6 +362,17 @@ foreach(PKG ${STANDARD_PACKAGES} ${SUFFIX_PACKAGES})
   option(PKG_${PKG} "Build ${PKG} Package" OFF)
 endforeach()
 
+set(DEPRECATED_PACKAGES AWPMD ATC POEMS)
+foreach(PKG ${DEPRECATED_PACKAGES})
+  if(PKG_${PKG})
+    message(WARNING
+          "The ${PKG} package will be removed from LAMMPS in Summer 2025 due to lack of "
+          "maintenance and use of code constructs that conflict with modern C++ compilers "
+          "and standards.  Please contact developers@lammps.org if you have any concerns "
+          "about this step.")
+  endif()
+endforeach()
+
 ######################################################
 # packages with special compiler needs or external libs
 ######################################################
@@ -410,6 +458,7 @@ pkg_depends(CG-DNA ASPHERE)
 pkg_depends(ELECTRODE KSPACE)
 pkg_depends(EXTRA-MOLECULE MOLECULE)
 pkg_depends(MESONT MOLECULE)
+pkg_depends(RHEO BPM)
 
 # detect if we may enable OpenMP support by default
 set(BUILD_OMP_DEFAULT OFF)
@@ -452,13 +501,13 @@ if(BUILD_OMP)
   if(CMAKE_VERSION VERSION_LESS 3.28)
     get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
     if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
-      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE} -fopenmp")
-      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE} -fopenmp")
+      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE}} -fopenmp")
+      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE}} -fopenmp")
     endif()
   else()
     if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
-      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE} -fopenmp")
-      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE} -fopenmp")
+      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE}} -fopenmp")
+      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE}} -fopenmp")
     endif()
   endif()
 endif()
@@ -475,7 +524,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)
@@ -550,12 +599,22 @@ else()
 endif()
 
 foreach(PKG_WITH_INCL KSPACE PYTHON ML-IAP VORONOI COLVARS ML-HDNNP MDI MOLFILE NETCDF
-        PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM COMPRESS ML-PACE LEPTON)
+        PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM COMPRESS ML-PACE LEPTON EXTRA-COMMAND)
   if(PKG_${PKG_WITH_INCL})
     include(Packages/${PKG_WITH_INCL})
   endif()
 endforeach()
 
+# settings for misc packages and styles
+if(PKG_MISC)
+  option(LAMMPS_ASYNC_IMD "Asynchronous IMD processing" OFF)
+  mark_as_advanced(LAMMPS_ASYNC_IMD)
+  if(LAMMPS_ASYNC_IMD)
+    target_compile_definitions(lammps PRIVATE -DLAMMPS_ASYNC_IMD)
+    message(STATUS "Using IMD in asynchronous mode")
+  endif()
+endif()
+
 # optionally enable building script wrappers using swig
 option(WITH_SWIG "Build scripting language wrappers with SWIG" OFF)
 if(WITH_SWIG)
@@ -565,13 +624,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)   #
 ########################################################################
@@ -800,9 +854,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)
@@ -870,7 +930,7 @@ endif()
 include(Testing)
 include(CodeCoverage)
 include(CodingStandard)
-find_package(ClangFormat 8.0)
+find_package(ClangFormat 11.0)
 
 if(ClangFormat_FOUND)
   add_custom_target(format-src
@@ -940,8 +1000,12 @@ message(STATUS "<<< Compilers and Flags: >>>
 -- C++ Compiler:     ${CMAKE_CXX_COMPILER}
       Type:          ${CMAKE_CXX_COMPILER_ID}
       Version:       ${CMAKE_CXX_COMPILER_VERSION}
+      C++ Standard:  ${CMAKE_CXX_STANDARD}
       C++ Flags:    ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_${BTYPE}}
       Defines:       ${DEFINES}")
+if(CMAKE_CXX_COMPILER_LAUNCHER)
+  message(STATUS "      Launcher:      ${CMAKE_CXX_COMPILER_LAUNCHER}")
+endif()
 get_target_property(OPTIONS lammps COMPILE_OPTIONS)
 if(OPTIONS)
   message("      Options:       ${OPTIONS}")
@@ -960,6 +1024,9 @@ if(_index GREATER -1)
       Type:          ${CMAKE_C_COMPILER_ID}
       Version:       ${CMAKE_C_COMPILER_VERSION}
       C Flags:      ${CMAKE_C_FLAGS} ${CMAKE_C_FLAGS_${BTYPE}}")
+  if(CMAKE_C_COMPILER_LAUNCHER)
+    message(STATUS "      Launcher:      ${CMAKE_C_COMPILER_LAUNCHER}")
+  endif()
 endif()
 message(STATUS "<<< Linker flags: >>>")
 message(STATUS "Executable name:  ${LAMMPS_BINARY}")
@@ -1046,16 +1113,16 @@ endif()
 if(BUILD_TOOLS)
   message(STATUS "<<< Building Tools >>>")
 endif()
-if(BUILD_LAMMPS_SHELL)
-  message(STATUS "<<< Building LAMMPS Shell >>>")
-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/FindClangFormat.cmake

@@ -1,5 +1,8 @@
 # Find clang-format
 find_program(ClangFormat_EXECUTABLE NAMES clang-format
+                                          clang-format-20.0
+                                          clang-format-19.0
+                                          clang-format-18.0
                                           clang-format-17.0
                                           clang-format-16.0
                                           clang-format-15.0

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

@@ -32,7 +32,13 @@ function(check_omp_h_include)
     set(CMAKE_REQUIRED_INCLUDES ${OpenMP_CXX_INCLUDE_DIRS})
     set(CMAKE_REQUIRED_LINK_OPTIONS ${OpenMP_CXX_FLAGS})
     set(CMAKE_REQUIRED_LIBRARIES ${OpenMP_CXX_LIBRARIES})
-    check_include_file_cxx(omp.h _have_omp_h)
+    # there are all kinds of problems with finding omp.h
+    # for Clang and derived compilers so we pretend it is there.
+    if(CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
+      set(_have_omp_h TRUE)
+    else()
+      check_include_file_cxx(omp.h _have_omp_h)
+    endif()
   else()
     set(_have_omp_h FALSE)
   endif()

cmake/Modules/Packages/COLVARS.cmake

@@ -24,6 +24,12 @@ target_include_directories(colvars PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/colvars)
 target_include_directories(colvars PRIVATE ${LAMMPS_SOURCE_DIR})
 target_link_libraries(lammps PRIVATE colvars)
 
+if(BUILD_OMP)
+  # Enable OpenMP for Colvars as well
+  target_compile_options(colvars PRIVATE ${OpenMP_CXX_FLAGS})
+  target_link_libraries(colvars PRIVATE OpenMP::OpenMP_CXX)
+endif()
+
 if(COLVARS_DEBUG)
   # Need to export the define publicly to be valid in interface code
   target_compile_definitions(colvars PUBLIC -DCOLVARS_DEBUG)

cmake/Modules/Packages/EXTRA-COMMAND.cmake

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

cmake/Modules/Packages/H5MD.cmake

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

cmake/Modules/Packages/INTEL.cmake

@@ -72,6 +72,10 @@ if(INTEL_ARCH STREQUAL "KNL")
   if(NOT CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
     message(FATAL_ERROR "Must use Intel compiler with INTEL for KNL architecture")
   endif()
+  message(WARNING, "Support for Intel Xeon Phi accelerators and Knight's Landing CPUs "
+          "will be removed from LAMMPS in Summer 2025 due to lack of available machines "
+          "in labs and HPC centers and removed support in recent compilers "
+          "Please contact developers@lammps.org if you have any concerns about this step.")
   set(CMAKE_EXE_LINKER_FLAGS  "${CMAKE_EXE_LINKER_FLAGS} -xHost -qopenmp -qoffload")
   set(MIC_OPTIONS "-qoffload-option,mic,compiler,\"-fp-model fast=2 -mGLOB_default_function_attrs=\\\"gather_scatter_loop_unroll=4\\\"\"")
   target_compile_options(lammps PRIVATE -xMIC-AVX512 -qoffload -fno-alias -ansi-alias -restrict -qoverride-limits ${MIC_OPTIONS})

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)
@@ -127,7 +139,7 @@ if(PKG_KSPACE)
                                  ${KOKKOS_PKG_SOURCES_DIR}/grid3d_kokkos.cpp
                                  ${KOKKOS_PKG_SOURCES_DIR}/remap_kokkos.cpp)
   set(FFT_KOKKOS "KISS" CACHE STRING "FFT library for Kokkos-enabled KSPACE package")
-  set(FFT_KOKKOS_VALUES KISS FFTW3 MKL HIPFFT CUFFT)
+  set(FFT_KOKKOS_VALUES KISS FFTW3 MKL NVPL HIPFFT CUFFT MKL_GPU)
   set_property(CACHE FFT_KOKKOS PROPERTY STRINGS ${FFT_KOKKOS_VALUES})
   validate_option(FFT_KOKKOS FFT_KOKKOS_VALUES)
   string(TOUPPER ${FFT_KOKKOS} FFT_KOKKOS)
@@ -137,10 +149,8 @@ if(PKG_KSPACE)
       message(FATAL_ERROR "The CUDA backend of Kokkos requires either KISS FFT or CUFFT.")
     elseif(FFT_KOKKOS STREQUAL "KISS")
       message(WARNING "Using KISS FFT with the CUDA backend of Kokkos may be sub-optimal.")
-      target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_KISS)
     elseif(FFT_KOKKOS STREQUAL "CUFFT")
       find_package(CUDAToolkit REQUIRED)
-      target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_CUFFT)
       target_link_libraries(lammps PRIVATE CUDA::cufft)
     endif()
   elseif(Kokkos_ENABLE_HIP)
@@ -152,10 +162,21 @@ if(PKG_KSPACE)
     elseif(FFT_KOKKOS STREQUAL "HIPFFT")
       include(DetectHIPInstallation)
       find_package(hipfft REQUIRED)
-      target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_HIPFFT)
       target_link_libraries(lammps PRIVATE hip::hipfft)
     endif()
+  elseif(FFT_KOKKOS STREQUAL "MKL_GPU")
+    if(NOT Kokkos_ENABLE_SYCL)
+      message(FATAL_ERROR "Using MKL_GPU FFT currently requires the SYCL backend of Kokkos.")
+    endif()
+    find_package(MKL REQUIRED)
+    target_link_libraries(lammps PRIVATE mkl_sycl_dft mkl_intel_ilp64 mkl_tbb_thread mkl_core tbb)
+  elseif(FFT_KOKKOS STREQUAL "MKL")
+    find_package(MKL REQUIRED)
+  elseif(FFT_KOKKOS STREQUAL "NVPL")
+      find_package(nvpl_fft REQUIRED)
+      target_link_libraries(lammps PRIVATE nvpl::fftw)
   endif()
+  target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_${FFT_KOKKOS})
 endif()
 
 if(PKG_ML-IAP)

cmake/Modules/Packages/KSPACE.cmake

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

cmake/Modules/Packages/ML-PACE.cmake

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

cmake/Modules/Packages/ML-QUIP.cmake

@@ -27,7 +27,7 @@ if(DOWNLOAD_QUIP)
   else()
     message(FATAL_ERROR "The ${CMAKE_Fortran_COMPILER_ID} Fortran compiler is not (yet) supported for building QUIP")
   endif()
-  set(temp "${temp}CFLAGS += -fPIC \nCPLUSPLUSFLAGS += -fPIC\nAR_ADD=src\n")
+  set(temp "${temp}CFLAGS += -fPIC -Wno-return-mismatch \nCPLUSPLUSFLAGS += -fPIC -Wno-return-mismatch\nAR_ADD=src\n")
   set(temp "${temp}MATH_LINKOPTS=")
   foreach(flag ${BLAS_LIBRARIES})
     set(temp "${temp} ${flag}")

cmake/Modules/Packages/PLUMED.cmake

@@ -1,5 +1,10 @@
 # Plumed2 support for PLUMED package
 
+# set policy to silence warnings about timestamps of downloaded files. review occasionally if it may be set to NEW
+if(POLICY CMP0135)
+  cmake_policy(SET CMP0135 OLD)
+endif()
+
 # for supporting multiple concurrent plumed2 installations for debugging and testing
 set(PLUMED_SUFFIX "" CACHE STRING "Suffix for Plumed2 library")
 mark_as_advanced(PLUMED_SUFFIX)
@@ -27,9 +32,9 @@ endif()
 
 # Note: must also adjust check for supported API versions in
 # fix_plumed.cpp when version changes from v2.n.x to v2.n+1.y
-set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.9.1/plumed-src-2.9.1.tgz"
+set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.9.3/plumed-src-2.9.3.tgz"
   CACHE STRING "URL for PLUMED tarball")
-set(PLUMED_MD5 "c3b2d31479c1e9ce211719d40e9efbd7" CACHE STRING "MD5 checksum of PLUMED tarball")
+set(PLUMED_MD5 "ee1249805fe94bccee17d10610d3f6f1" CACHE STRING "MD5 checksum of PLUMED tarball")
 
 mark_as_advanced(PLUMED_URL)
 mark_as_advanced(PLUMED_MD5)
@@ -81,6 +86,9 @@ if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND (CMAKE_CROSSCOMPILING))
     DEPENDS plumed_build
     COMMENT "Copying Plumed files"
   )
+  if(CMAKE_PROJECT_NAME STREQUAL "lammps")
+    target_link_libraries(lammps INTERFACE LAMMPS::PLUMED)
+  endif()
 
 else()
 
@@ -155,6 +163,9 @@ else()
     endif()
     set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_INCLUDE_DIRECTORIES ${INSTALL_DIR}/include)
     file(MAKE_DIRECTORY ${INSTALL_DIR}/include)
+    if(CMAKE_PROJECT_NAME STREQUAL "lammps")
+      target_link_libraries(lammps PRIVATE LAMMPS::PLUMED)
+    endif()
   else()
     find_package(PkgConfig REQUIRED)
     pkg_check_modules(PLUMED REQUIRED plumed${PLUMED_SUFFIX})
@@ -169,7 +180,9 @@ else()
     endif()
     set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_LINK_LIBRARIES "${PLUMED_LOAD}")
     set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${PLUMED_INCLUDE_DIRS}")
+    if(CMAKE_PROJECT_NAME STREQUAL "lammps")
+      target_link_libraries(lammps PUBLIC LAMMPS::PLUMED)
+    endif()
   endif()
 endif()
 
-target_link_libraries(lammps PRIVATE LAMMPS::PLUMED)

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/Modules/Testing.cmake

@@ -102,9 +102,9 @@ endif()
 #######################################
 # select code sanitizer options
 #######################################
-set(ENABLE_SANITIZER "none" CACHE STRING "Select a code sanitizer option (none (default), address, leak, thread, undefined)")
+set(ENABLE_SANITIZER "none" CACHE STRING "Select a code sanitizer option (none (default), address, hwaddress, leak, thread, undefined)")
 mark_as_advanced(ENABLE_SANITIZER)
-set(ENABLE_SANITIZER_VALUES none address leak thread undefined)
+set(ENABLE_SANITIZER_VALUES none address hwaddress leak thread undefined)
 set_property(CACHE ENABLE_SANITIZER PROPERTY STRINGS ${ENABLE_SANITIZER_VALUES})
 validate_option(ENABLE_SANITIZER ENABLE_SANITIZER_VALUES)
 string(TOLOWER ${ENABLE_SANITIZER} ENABLE_SANITIZER)

cmake/Modules/Tools.cmake

@@ -37,37 +37,6 @@ if(BUILD_TOOLS)
   add_subdirectory(${LAMMPS_TOOLS_DIR}/phonon ${CMAKE_BINARY_DIR}/phana_build)
 endif()
 
-find_package(PkgConfig QUIET)
-if(BUILD_LAMMPS_SHELL)
-  if(NOT PkgConfig_FOUND)
-    message(FATAL_ERROR "Must have pkg-config installed for building LAMMPS shell")
-  endif()
-  find_package(PkgConfig REQUIRED)
-  pkg_check_modules(READLINE IMPORTED_TARGET REQUIRED readline)
-
-  # include resource compiler to embed icons into the executable on Windows
-  if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
-    enable_language(RC)
-    set(ICON_RC_FILE ${LAMMPS_TOOLS_DIR}/lammps-shell/lmpicons.rc)
-  endif()
-
-  add_executable(lammps-shell ${LAMMPS_TOOLS_DIR}/lammps-shell/lammps-shell.cpp ${ICON_RC_FILE})
-  target_include_directories(lammps-shell PRIVATE ${LAMMPS_TOOLS_DIR}/lammps-shell)
-  target_link_libraries(lammps-shell PRIVATE lammps PkgConfig::READLINE)
-
-  # workaround for broken readline pkg-config file on FreeBSD
-  if(CMAKE_SYSTEM_NAME STREQUAL "FreeBSD")
-    target_include_directories(lammps-shell PRIVATE /usr/local/include)
-  endif()
-  if(CMAKE_SYSTEM_NAME STREQUAL "LinuxMUSL")
-    pkg_check_modules(TERMCAP IMPORTED_TARGET REQUIRED termcap)
-    target_link_libraries(lammps-shell PRIVATE lammps PkgConfig::TERMCAP)
-  endif()
-  install(TARGETS lammps-shell EXPORT LAMMPS_Targets DESTINATION ${CMAKE_INSTALL_BINDIR})
-  install(DIRECTORY ${LAMMPS_TOOLS_DIR}/lammps-shell/icons DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/)
-  install(FILES ${LAMMPS_TOOLS_DIR}/lammps-shell/lammps-shell.desktop DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/applications/)
-endif()
-
 if(BUILD_LAMMPS_GUI)
   get_filename_component(LAMMPS_GUI_DIR ${LAMMPS_SOURCE_DIR}/../tools/lammps-gui ABSOLUTE)
   get_filename_component(LAMMPS_GUI_BIN ${CMAKE_BINARY_DIR}/lammps-gui-build ABSOLUTE)

cmake/packaging/build_linux_tgz.sh

@@ -2,9 +2,10 @@
 
 APP_NAME=lammps-gui
 DESTDIR=${PWD}/../LAMMPS_GUI
+VERSION="$1"
 
 echo "Delete old files, if they exist"
-rm -rf ${DESTDIR} ../LAMMPS_GUI-Linux-amd64.tar.gz
+rm -rf ${DESTDIR} ../LAMMPS_GUI-Linux-amd64*.tar.gz
 
 echo "Create staging area for deployment and populate"
 DESTDIR=${DESTDIR} cmake --install .  --prefix "/"
@@ -71,7 +72,7 @@ do \
 done
 
 pushd ..
-tar -czvvf LAMMPS_GUI-Linux-amd64.tar.gz LAMMPS_GUI
+tar -czvvf LAMMPS_GUI-Linux-amd64-${VERSION}.tar.gz LAMMPS_GUI
 popd
 
 echo "Cleanup dir"

cmake/packaging/build_macos_dmg.sh

@@ -1,9 +1,10 @@
 #!/bin/bash
 
 APP_NAME=lammps-gui
+VERSION="$1"
 
 echo "Delete old files, if they exist"
-rm -f ${APP_NAME}.dmg ${APP_NAME}-rw.dmg LAMMPS_GUI-macOS-multiarch.dmg
+rm -f ${APP_NAME}.dmg ${APP_NAME}-rw.dmg LAMMPS_GUI-macOS-multiarch*.dmg
 
 echo "Create initial dmg file with macdeployqt"
 macdeployqt  lammps-gui.app -dmg
@@ -96,12 +97,12 @@ sync
 
 echo "Unmount modified disk image and convert to compressed read-only image"
 hdiutil detach "${DEVICE}"
-hdiutil convert "${APP_NAME}-rw.dmg" -format UDZO -o "LAMMPS_GUI-macOS-multiarch.dmg"
+hdiutil convert "${APP_NAME}-rw.dmg" -format UDZO -o "LAMMPS_GUI-macOS-multiarch-${VERSION}.dmg"
 
 echo "Attach icon to .dmg file"
 echo "read 'icns' (-16455) \"lammps-gui.app/Contents/Resources/lammps.icns\";" > icon.rsrc
-Rez -a icon.rsrc -o LAMMPS_GUI-macOS-multiarch.dmg
-SetFile -a C LAMMPS_GUI-macOS-multiarch.dmg
+Rez -a icon.rsrc -o LAMMPS_GUI-macOS-multiarch-${VERSION}.dmg
+SetFile -a C LAMMPS_GUI-macOS-multiarch-${VERSION}.dmg
 rm icon.rsrc
 
 echo "Delete temporary disk images"

cmake/packaging/build_windows_cross_zip.sh

@@ -3,9 +3,10 @@
 APP_NAME=lammps-gui
 DESTDIR=${PWD}/LAMMPS_GUI
 SYSROOT="$1"
+VERSION="$2"
 
 echo "Delete old files, if they exist"
-rm -rvf ${DESTDIR}/LAMMPS_GUI ${DESTDIR}/LAMMPS-Win10-amd64.zip
+rm -rvf ${DESTDIR}/LAMMPS_GUI ${DESTDIR}/LAMMPS-Win10-amd64*.zip
 
 echo "Create staging area for deployment and populate"
 DESTDIR=${DESTDIR} cmake --install .  --prefix "/"
@@ -60,5 +61,5 @@ cat > ${DESTDIR}/bin/qt.conf <<EOF
 [Paths]
 Plugins = ../qt5plugins
 EOF
-zip -9rvD LAMMPS-Win10-amd64.zip LAMMPS_GUI
+zip -9rvD LAMMPS-Win10-amd64-${VERSION}.zip LAMMPS_GUI
 

cmake/presets/all_off.cmake

@@ -82,6 +82,7 @@ set(ALL_PACKAGES
   REACTION
   REAXFF
   REPLICA
+  RHEO
   RIGID
   SCAFACOS
   SHOCK

cmake/presets/all_on.cmake

@@ -84,6 +84,7 @@ set(ALL_PACKAGES
   REACTION
   REAXFF
   REPLICA
+  RHEO
   RIGID
   SCAFACOS
   SHOCK

cmake/presets/clang.cmake

@@ -1,10 +1,10 @@
 # preset that will enable clang/clang++ with support for MPI and OpenMP (on Linux boxes)
 
 # prefer flang over gfortran, if available
-find_program(CLANG_FORTRAN NAMES flang gfortran f95)
+find_program(CLANG_FORTRAN NAMES flang-new flang gfortran f95)
 set(ENV{OMPI_FC} ${CLANG_FORTRAN})
 get_filename_component(_tmp_fc ${CLANG_FORTRAN} NAME)
-if (_tmp_fc STREQUAL "flang")
+if ((_tmp_fc STREQUAL "flang") OR (_tmp_fc STREQUAL "flang-new"))
   set(FC_STD_VERSION "-std=f2018")
   set(BUILD_MPI OFF)
 else()

cmake/presets/kokkos-sycl-intel.cmake

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

cmake/presets/mingw-cross.cmake

@@ -33,7 +33,6 @@ set(WIN_PACKAGES
   FEP
   GPU
   GRANULAR
-  INTEL
   INTERLAYER
   KSPACE
   LEPTON
@@ -68,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" "27 June 2024" "2024-06-27"
+.TH LAMMPS "1" "4 February 2025" "2025-02-04"
 .SH NAME
 .B LAMMPS
-\- Molecular Dynamics Simulator.  Version 27 June 2024
+\- Molecular Dynamics Simulator.  Version 4 February 2025
 
 .SH SYNOPSIS
 .B lmp
@@ -226,6 +226,20 @@ arguments of the "dump" command. See the
 .B LAMMPS
 manual for details on either of the two commands.
 .TP
+\fB\-r2info <restart file> <keyword> ...\fR or
+\fB\-restart2info <restart file> <keyword> ...\fR
+Write information about the <restart file> previously written by
+.B LAMMPS
+to the screen and immediately exit.  Following <restart file>
+argument, additional keywords for the
+.B LAMMPS
+"info" command may be added to increase the amount of information
+written. By default "system" "group" "fix" "compute" are already
+set. See the
+.B LAMMPS
+manual for details on the "info" command.
+.TP
+.TP
 \fB\-sc <file name>\fR or \fB\-screen <file name>\fR
 Specify a file for
 .B LAMMPS
@@ -297,7 +311,7 @@ the chapter on errors in the
 manual gives some additional information about error messages, if possible.
 
 .SH COPYRIGHT
-© 2003--2024 Sandia Corporation
+© 2003--2025 Sandia Corporation
 
 This package is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License version 2 as

doc/msi2lmp.1

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

doc/src/Bibliography.rst

@@ -1,6 +1,12 @@
 Bibliography
 ************
 
+**(Abascal1)**
+   Abascal, Sanz, Fernandez, Vega, J Chem Phys, 122, 234511 (2005)
+
+**(Abascal2)**
+   Abascal, J Chem Phys, 123, 234505 (2005)
+
 **(Ackland)**
    Ackland, Jones, Phys Rev B, 73, 054104 (2006).
 
@@ -22,21 +28,24 @@ Bibliography
 **(Agnolin and Roux 2007)**
    Agnolin, I. & Roux, J-N. (2007). Internal states of model isotropic granular packings. I. Assembling process, geometry, and contact networks. Phys. Rev. E, 76, 061302.
 
+**(Ahrens-Iwers2022)**
+   Ahrens-Iwers *et al.*, J. Chem. Phys. 157, 084801 (2022).
+
+**(Ahrens-Iwers)**
+   Ahrens-Iwers and Meissner, J. Chem. Phys. 155, 104104 (2021).
+
 **(Aktulga)**
    Aktulga, Fogarty, Pandit, Grama, Parallel Computing, 38, 245-259 (2012).
 
 **(Albe)**
    J.\  Nord, K. Albe, P. Erhart, and K. Nordlund, J. Phys.: Condens. Matter, 15, 5649(2003).
 
-**(Albe)**
+**(Albe1)**
    K.\  Albe, K. Nordlund, J. Nord, and A. Kuronen, Phys. Rev. B, 66, 035205 (2002).
 
 **(Allen)**
    Allen and Germano, Mol Phys 104, 3225-3235 (2006).
 
-**(Allen)**
-   Allen and Tildesley, Computer Simulation of Liquids, Clarendon Press, Oxford, 1987.
-
 **(AllenTildesley)**
    Allen and Tildesley, Computer Simulation of Liquids, Oxford University Press (1987)
 
@@ -49,6 +58,9 @@ Bibliography
 **(Anderson)**
    Anderson, Mukherjee, Critchley, Ziegler, and Lipton "POEMS: Parallelizable Open-source Efficient Multibody Software ", Engineering With Computers (2006).
 
+**(Appshaw)**
+   Appshaw, Seddon, Hanna, Soft. Matter,18, 1747(2022).
+
 **(Avendano)**
    C.\  Avendano, T. Lafitte, A. Galindo, C. S. Adjiman, G. Jackson, E. Muller, J Phys Chem B, 115, 11154 (2011).
 
@@ -58,7 +70,7 @@ Bibliography
 **(Babadi)**
    Babadi, Ejtehadi, Everaers, J Comp Phys, 219, 770-779 (2006).
 
-**(Babadi)**
+**(Babadi2)**
    Babadi and Ejtehadi, EPL, 77 (2007) 23002.
 
 **(Baczewski)**
@@ -73,23 +85,23 @@ Bibliography
 **(Ballenegger)**
    Ballenegger, Arnold, Cerda, J Chem Phys, 131, 094107 (2009).
 
-**(Banna)**
-   Volkov, Banna, Comp. Mater. Sci. 176, 109410 (2020).
-
 **(Barrat)**
    Barrat and Rodney, J. Stat. Phys, 144, 679 (2011).
 
 **(Barrett)**
    Barrett, Tschopp, El Kadiri, Scripta Mat. 66, p.666 (2012).
 
+**(Barros)**
+   Barros, Sinkovits, Luijten, J. Chem. Phys, 140, 064903 (2014)
+
 **(Bartok)**
    Bartok, Payne, Risi, Csanyi, Phys Rev Lett, 104, 136403 (2010).
 
 **(Bartok2010)**
    Bartok, Payne, Risi, Csanyi, Phys Rev Lett, 104, 136403 (2010).
 
-**(Bartok_2010)**
-   AP Bartok, MC Payne, R Kondor, and G Csanyi, Physical Review Letters 104, 136403 (2010).
+**(Bartok2013)**
+   Bartok, Kondor, Csanyi, Phys Rev B, 87, 184115 (2013).
 
 **(Bartok_PhD)**
    A Bartok-Partay, PhD Thesis, University of Cambridge, (2010).
@@ -97,36 +109,51 @@ Bibliography
 **(Baskes)**
    Baskes, Phys Rev B, 46, 2727-2742 (1992).
 
+**(Baskes2)**
+   Baskes, Phys Rev B, 75, 094113 (2007).
+
 **(Beck)**
    Beck, Molecular Physics, 14, 311 (1968).
 
+**(Becton)**
+   Becton, Averett, Wang, Biomech. Model. Mechanobiology, 18, 425-433(2019).
+
+**(Behler and Parrinello 2007)**
+   Behler, J.; Parrinello, M. Phys. Rev. Lett.  2007, 98 (14), 146401.
+
 **(Bennet)**
    Bennet, J Comput Phys, 22, 245 (1976)
 
 **(Berardi)**
    Berardi, Fava, Zannoni, Chem Phys Lett, 297, 8-14 (1998). Berardi, Muccioli, Zannoni, J Chem Phys, 128, 024905 (2008).
 
-**(Berendsen)**
-   Berendsen, Grigera, Straatsma, J Phys Chem, 91, 6269-6271 (1987).
-
 **(Berendsen)**
    Berendsen, Postma, van Gunsteren, DiNola, Haak, J Chem Phys, 81, 3684 (1984).
 
+**(Berendsen2)**
+   Berendsen, Grigera, Straatsma, J Phys Chem, 91, 6269-6271 (1987).
+
 **(Bessarab)**
    Bessarab, Uzdin, Jonsson, Comp Phys Comm, 196, 335-347 (2015).
 
 **(Beutler)**
    Beutler, Mark, van Schaik, Gerber, van Gunsteren, Chem Phys Lett, 222, 529 (1994).
 
-**(Bialke)**
-   J.\  Bialke, T. Speck, and H Loewen, Phys. Rev. Lett. 108, 168301, 2012.
-
 **(Bird)**
    G.\  A. Bird, "Molecular Gas Dynamics and the Direct Simulation of Gas Flows" (1994).
 
 **(Bitzek)**
    Bitzek, Koskinen, Gahler, Moseler, Gumbsch, Phys Rev Lett, 97, 170201 (2006).
 
+**(Bolintineanu1)**
+   Bolintineanu, Lechman, Plimpton, Grest, Phys Rev E, 86, 066703 (2012).
+
+**(Bolintineanu2)**
+  Bolintineanu, Grest, Lechman, Pierce, Plimpton, Schunk, Comp Particle Mechanics, 1, 321-356 (2014).
+
+**(Bomont)**
+   Bomont, Bretonnet, J. Chem. Phys. 124, 054504 (2006).
+
 **(Bond)**
    Bond and Leimkuhler, SIAM J Sci Comput, 30, p 134 (2007).
 
@@ -134,7 +161,7 @@ Bibliography
    Boone, Babaei, Wilmer, J Chem Theory Comput, 15, 5579--5587 (2019).
 
 **(BoreschKarplus)**
-   Boresch and Karplus, J Phys Chem A, 103, 103 (1999)
+   Boresch and Karplus, J Phys Chem A, 103, 103 (1999).
 
 **(Botu1)**
    V.\  Botu and R. Ramprasad, Int. J. Quant. Chem., 115(16), 1074 (2015).
@@ -169,8 +196,11 @@ Bibliography
 **(Buck)**
    Buck, Bouguet-Bonnet, Pastor, MacKerell Jr., Biophys J, 90, L36 (2006).
 
+**(Bulacu)**
+   Bulacu, Goga, Zhao, Rossi, Monticelli, Periole, Tieleman, Marrink, J Chem Theory Comput, 9, 3282-3292
+
 **(Bussi)**
-   G.\  Bussi, M. Parrinello, Phs. Rev. E 75, 056707 (2007)
+   G. Bussi, T. Zykova-Timan, M. Parrinello, J Chem Phys, 130, 074101 (2009).
 
 **(Bussi1)**
    Bussi, Donadio and Parrinello, J. Chem. Phys. 126, 014101(2007)
@@ -178,20 +208,20 @@ Bibliography
 **(Bussi2)**
    Bussi and Parrinello, Phys. Rev. E 75, 056707 (2007)
 
-**(COMB)**
+**(COMB_1)**
+   J.\  Yu, S. B. Sinnott, S. R. Phillpot, Phys Rev B, 75, 085311 (2007),
+
+**(COMB_2)**
    T.-R. Shan, B. D. Devine, T. W. Kemper, S. B. Sinnott, and S. R. Phillpot, Phys. Rev. B 81, 125328 (2010)
 
 **(COMB3)**
    T.\  Liang, T.-R. Shan, Y.-T. Cheng, B. D. Devine, M. Noordhoek, Y. Li, Z. Lu, S. R. Phillpot, and S. B. Sinnott, Mat. Sci. & Eng: R 74, 255-279 (2013).
 
-**(COMB_1)**
-   J.\  Yu, S. B. Sinnott, S. R. Phillpot, Phys Rev B, 75, 085311 (2007),
-
 **(Calhoun)**
    A.\  Calhoun, M. Pavese, G. Voth, Chem Phys Letters, 262, 415 (1996).
 
 **(Campana)**
-   C.\  Campana and M. H. Muser, *Practical Green's function approach to the simulation of elastic semi-infinite solids*, `Phys. Rev. B [74], 075420 (2006) <https://doi.org/10.1103/PhysRevB.74.075420>`_
+   C.\  Campana and M. H. Muser, Phys. Rev. B [74], 075420 (2006).
 
 **(Cao1)**
    J.\  Cao and B. Berne, J Chem Phys, 99, 2902 (1993).
@@ -215,6 +245,9 @@ Bibliography
    Cerda, Ballenegger, Lenz, Holm, J Chem Phys 129, 234104 (2008)
 
 **(Ceriotti)**
+   M. Ceriotti, M. Parrinello, T. Markland, D. Manolopoulos, J. Chem. Phys. 133, 124104 (2010).
+
+**(Ceriotti1)**
    Ceriotti, Bussi and Parrinello, J Chem Theory Comput 6, 1170-80 (2010)
 
 **(Ceriotti2)**
@@ -232,6 +265,18 @@ Bibliography
 **(Clarke)**
    Clarke and Smith, J Chem Phys, 84, 2290 (1986).
 
+**(Clavier)**
+   G. Clavier, N. Desbiens, E. Bourasseau, V. Lachet, N. Brusselle-Dupend and B. Rousseau, Mol Sim, 43, 1413 (2017).
+
+**(Clemmer)**
+   Clemmer and Robbins, Phys. Rev. Lett. (2022).
+
+**(Clemmer1)**
+   Clemmer, Monti, Lechman, Soft Matter, 20, 1702 (2024).
+
+**(Clemmer2)**
+   Clemmer, Pierce, O'Connor, Nevins, Jones, Lechman, Tencer, Appl. Math. Model., 130, 310-326 (2024).
+
 **(Coleman)**
    Coleman, Spearot, Capolungo, MSMSE, 21, 055020 (2013).
 
@@ -244,8 +289,17 @@ Bibliography
 **(Cornell)**
    Cornell, Cieplak, Bayly, Gould, Merz, Ferguson, Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
 
+**(Cundall, 1987)**
+   Cundall, P. A. Distinct Element Models of Rock and Soil
+
+**(Curk1)**
+   T. Curk, J. Yuan, and E. Luijten, JCP 156 (2022).
+
+**(Curk2)**
+   T. Curk and E. Luijten, PRL 126 (2021)
+
 **(Cusentino)**
-   Cusentino, Wood, and Thompson, J Phys Chem A, xxx, xxxxx, (2020)
+   Cusentino, Wood, Thompson, J Phys Chem A, 124, 5456, (2020)
 
 **(Daivis and Todd)**
    Daivis and Todd, J Chem Phys, 124, 194103 (2006).
@@ -268,6 +322,15 @@ Bibliography
 **(Daw2)**
    M.\  S. Daw, and M. I. Baskes, Phys. Rev. B, 29, 6443 (1984).
 
+**(de Buyl)**
+   de Buyl, Colberg and Hofling, Comp. Phys. Comm. 185(6), 1546-1553 (2014) -
+
+**(Deissenbeck)**
+   Deissenbeck *et al.*, Phys. Rev. Letters 126, 136803 (2021).
+
+**(de Koning)**
+   de Koning and Antonelli, Phys Rev E, 53, 465 (1996).
+
 **(DeVane)**
    Shinoda, DeVane, Klein, Soft Matter, 4, 2453-2462 (2008).
 
@@ -277,12 +340,24 @@ Bibliography
 **(Destree)**
    M.\  Destree, F. Laupretre, A. Lyulin, and J.-P.  Ryckaert, J Chem Phys, 112, 9632 (2000).
 
+**(Dickel)**
+   Dickel, Francis, and Barrett, Computational Materials Science 171 (2020): 109157.
+
+**(Dietz)**
+   Dietz and Hoy, J. Chem Phys, 156, 014103 (2022).
+
 **(Dobson)**
    Dobson, J Chem Phys, 141, 184103 (2014).
 
+**(Drautz)**
+   Drautz, Phys Rev B, 99, 014104 (2019).
+
 **(Duffy)**
    D M Duffy and A M Rutherford, J. Phys.: Condens. Matter, 19, 016207-016218 (2007).
 
+**(Dufils)**
+   Dufils *et al.*, Phys. Rev. Letters 123, 195501 (2019).
+
 **(Dullweber)**
    Dullweber, Leimkuhler and McLachlan, J Chem Phys, 107, 5840 (1997).
 
@@ -295,6 +370,9 @@ Bibliography
 **(Dunweg)**
    Dunweg and Paul, Int J of Modern Physics C, 2, 817-27 (1991).
 
+**(EcheverriRestrepo)**
+  Echeverri Restrepo, Andric, Comput Mater Sci, 218, 111978 (2023).
+
 **(EDIP)**
    J F Justo et al, Phys Rev B 58, 2539 (1998).
 
@@ -304,12 +382,21 @@ Bibliography
 **(Elliott)**
    Elliott, Tadmor and Bernstein, `https://openkim.org/kim-api <https://openkim.org/kim-api>`_ (2011) doi: `https://doi.org/10.25950/FF8F563A <https://doi.org/10.25950/FF8F563A>`_
 
+**(Ellis)**
+   Ellis, Fiedler, Popoola, Modine, Stephens, Thompson, Cangi, Rajamanickam,  Phys Rev B, 104, 035120, (2021)
+
+**(Emmrich)**
+   Emmrich, Weckner, Commun. Math. Sci., 5, 851-864 (2007),
+
 **(Elstner)**
    M.\  Elstner, D. Poresag, G. Jungnickel, J. Elsner, M. Haugk, T. Frauenheim, S. Suhai, and G. Seifert, Phys. Rev. B, 58, 7260 (1998).
 
 **(Erdmann)**
    U.\  Erdmann , W. Ebeling, L. Schimansky-Geier, and F. Schweitzer, Eur. Phys. J. B 15, 105-113, 2000.
 
+**(Eshelby)**
+  J.D. Eshelby, Philos. Trans. Royal Soc. London A, Math. Phys. Sci., Vol. 244, No. 877 (1951) pp. 87-112; J. Elasticity, Vol. 5, Nos. 3-4 (1975) pp. 321-335]
+
 **(Espanol and Revenga)**
    Espanol, Revenga, Physical Review E, 67, 026705 (2003).
 
@@ -328,9 +415,18 @@ Bibliography
 **(Faken)**
    Faken, Jonsson, Comput Mater Sci, 2, 279 (1994).
 
+**(Falk)**
+   Falk and Langer PRE, 57, 7192 (1998).
+
 **(Fath)**
    Fath, Hochbruck, Singh, J Comp Phys, 333, 180-198 (2017).
 
+**(Feng1)**
+   Z. Feng, ..., and W. Ouyang, J. Phys. Chem. C. 127(18), 8704-8713 (2023).
+
+**(Feng2)**
+   Z. Feng, ..., and W. Ouyang, Langmuir 39(50), 18198-18207 (2023).
+
 **(Fennell)**
    C.\  J. Fennell, J. D. Gezelter, J Chem Phys, 124, 234104 (2006).
 
@@ -367,18 +463,36 @@ Bibliography
 **(Frenkel)**
    Frenkel and Smit, Understanding Molecular Simulation, Academic Press, London, 2002.
 
-**(GLE4MD)**
-   `https://gle4md.org/ <https://gle4md.org/>`_
+**(Fu)**
+   Fu, Peng, Yuan, Kfoury, Young, Comput. Phys. Commun, 210, 193-203(2017).
 
 **(Gao)**
    Gao and Weber, Nuclear Instruments and Methods in Physics Research B 191 (2012) 504.
 
+**(Gingrich)**
+   Gingrich, `MSc thesis` <https://gingrich.chem.northwestern.edu/papers/ThesiswCorrections.pdf>` (2010).
+
+**(Gissinger2017)**
+   Gissinger, Jensen and Wise, Polymer, 128, 211-217 (2017).
+
+**(Gissinger2020)**
+   Gissinger, Jensen and Wise, Macromolecules, 53, 22, 9953-9961 (2020).
+
 **(Gissinger)**
-   Gissinger, Jensen and Wise, Polymer, 128, 211 (2017).
+   Jacob R. Gissinger, Scott R. Zavada, Joseph G. Smith, Josh Kemppainen, Ivan Gallegos, Gregory M. Odegard, Emilie J. Siochi, and Kristopher E. Wise, Carbon, 202, 336-347 (2023).
+
+**(Gissinger2024)**
+   J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).
+
+**(Gloor)**
+   Gloor, J Chem Phys, 123, 134703 (2005)
 
 **(Glosli)**
    Glosli, unpublished, 2005. Streitz, Glosli, Patel, Chan, Yates, de Supinski, Sexton and Gunnels, Journal of Physics: Conference Series, 46, 254 (2006).
 
+**(Goff)**
+   Goff, Zhang, Negre, Rohskopf, Niklasson, Journal of Chemical Theory and Computation 19, no. 13 (2023).
+
 **(Goldman1)**
    Goldman, Reed and Fried, J. Chem. Phys. 131, 204103 (2009)
 
@@ -412,6 +526,9 @@ Bibliography
 **(Guo)**
    Guo and Thirumalai, Journal of Molecular Biology, 263, 323-43 (1996).
 
+**(Gupta)**
+   Gupta ,Phys Rev. B, 23, 6265-6270 (1981).
+
 **(Hardy)**
    David Hardy thesis: Multilevel Summation for the Fast Evaluation of Forces for the Simulation of Biomolecules, University of Illinois at Urbana-Champaign, (2006).
 
@@ -433,6 +550,9 @@ Bibliography
 **(Henrich)**
    O.\  Henrich, Y. A. Gutierrez-Fosado, T. Curk, T. E. Ouldridge, Eur. Phys. J. E 41, 57 (2018).
 
+**(Herman)**
+   M. F. Herman, E. J. Bruskin, B. J. Berne, J Chem Phys, 76, 5150 (1982).
+
 **(Hess)**
    Hess, B. The Journal of Chemical Physics 2002, 116 (1), 209-217.
 
@@ -454,24 +574,42 @@ Bibliography
 **(Hoover)**
    Hoover, Phys Rev A, 31, 1695 (1985).
 
+**(Huang)**
+   Huang, Zhang, Yuan, Gao, Zhang, Nano Lett. 13, 4546(2013).
+
+**(Huang2014)**
+   X. Huang, "Exploring critical-state behavior using DEM", Doctoral dissertation, Imperial College. (2014). https://doi.org/10.25560/25316
+
+**(Hu)**
+   Hu, and Adams J. Comp. Physics, 213, 844-861 (2006).
+
+**(Hu)**
+   Hu, J. Chem. Theory Comput. 10, 5254 (2014).
+
 **(Hummer)**
    Hummer, Gronbech-Jensen, Neumann, J Chem Phys, 109, 2791 (1998)
 
 **(Hunt)**
    Hunt, Mol Simul, 42, 347 (2016).
 
+**(Ikeshoji)**
+   Ikeshoji and Hafskjold, Molecular Physics, 81, 251-261 (1994).
+
+**(Ikeshoji2)**
+   Ikeshoji, Hafskjold, Furuholt, Mol Sim, 29, 101-109, (2003).
+
+**(Ilie)**
+   Ilie, Briels, den Otter, Journal of Chemical Physics, 142, 114103 (2015).
+
+**(In 't Veld)**
+   In 't Veld, Ismail, Grest, J Chem Phys (accepted) (2007).
+
 **(IPI)**
    `https://ipi-code.org/ <https://ipi-code.org/>`
 
 **(IPI-CPC)**
    Ceriotti, More and Manolopoulos, Comp Phys Comm, 185, 1019-1026 (2014).
 
-**(Ikeshoji)**
-   Ikeshoji and Hafskjold, Molecular Physics, 81, 251-261 (1994).
-
-**(In 't Veld)**
-   In 't Veld, Ismail, Grest, J Chem Phys (accepted) (2007).
-
 **(Isele-Holder)**
    Isele-Holder, Mitchell, Ismail, J Chem Phys, 137, 174107 (2012).
 
@@ -490,6 +628,9 @@ Bibliography
 **(Izvekov)**
    Izvekov, Voth, J Chem Phys 123, 134105 (2005).
 
+**(Jadhao)**
+   Jadhao, Solis, Olvera de la Cruz, J Chem Phys, 138, 054119 (2013)
+
 **(Janssens)**
    Janssens, Olmsted, Holm, Foiles, Plimpton, Derlet, Nature Materials, 5, 124-127 (2006).
 
@@ -502,6 +643,15 @@ Bibliography
 **(Jiang)**
    Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux,  J Phys Chem Lett, 2, 87-92 (2011).
 
+**(Jiang1)**
+   Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux, J Phys Chem Lett, 2, 87-92 (2011).
+
+**(Jiang2)**
+   J.-W. Jiang, Nanotechnology 26, 315706 (2015).
+
+**(Jiang3)**
+   J.-W. Jiang, Acta Mech. Solida. Sin 32, 17 (2019).
+
 **(Johnson et al, 1971)**
    Johnson, K. L., Kendall, K., & Roberts, A. D. (1971).  Surface energy and the contact of elastic solids. Proc. R. Soc. Lond. A, 324(1558), 301-313.
 
@@ -571,21 +721,24 @@ Bibliography
 **(Lamoureux)**
    Lamoureux and Roux, J Chem Phys, 119, 3025-3039 (2003).
 
-**(Larentzos)**
-   J.P. Larentzos, J.K. Brennan, J.D. Moore, and W.D. Mattson, "LAMMPS Implementation of Constant Energy Dissipative Particle Dynamics (DPD-E)", ARL-TR-6863, U.S. Army Research
+**(Landsgesell)**
+   J. Landsgesell, P. Hebbeker, O. Rud, R. Lunkad, P. Kosovan, and C. Holm, Macromolecules 53, 3007-3020 (2020).
 
 **(Larentzos1)**
-   J.P. Larentzos, J.K. Brennan, J.D. Moore, M. Lisal and W.D. Mattson, "Parallel Implementation of Isothermal and Isoenergetic Dissipative Particle Dynamics Using Shardlow-Like Splitting
+   J.P. Larentzos, J.K. Brennan, J.D. Moore, M. Lisal and W.D. Mattson, Comput. Phys. Commun., 185, 1987-1998 (2014).
 
 **(Larentzos2)**
-   J.P. Larentzos, J.K. Brennan, J.D. Moore, and W.D. Mattson, "LAMMPS Implementation of Constant Energy Dissipative Particle Dynamics (DPD-E)", ARL-TR-6863, U.S. Army Research
+   J.P. Larentzos, J.K. Brennan, J.D. Moore, and W.D. Mattson, ARL-TR-6863, U.S. Army Research Laboratory, Aberdeen Proving Ground, MD (2014).
 
 **(Larsen)**
    Larsen, Schmidt, Schiotz, Modelling Simul Mater Sci Eng, 24, 055007 (2016).
 
-**(Lebedeva et al.)**
+**(Lebedeva1)**
    I.\  V. Lebedeva, A. A. Knizhnik, A. M. Popov, Y. E. Lozovik, B. V. Potapkin, Phys. Rev. B, 84, 245437 (2011)
 
+**(Lebedeva2)**
+  I. V. Lebedeva, A. A. Knizhnik, A. M. Popov, Y. E. Lozovik, B. V. Potapkin, Physica E: 44, 949-954 (2012)
+
 **(Lechman)**
    Lechman, et al, in preparation (2010).
 
@@ -595,6 +748,9 @@ Bibliography
 **(Lee2)**
    Lee, Baskes, Kim, Cho.  Phys. Rev. B, 64, 184102 (2001).
 
+**(Lee2020)**
+   C.W. Lee, et al. (2020) Physical Review B, 102(2), 024107.
+
 **(Lenart)**
    Lenart , Jusufi, and Panagiotopoulos, J Chem Phys, 126, 044509 (2007).
 
@@ -619,8 +775,11 @@ Bibliography
 **(Li2015_JCP)**
    Li, Yazdani, Tartakovsky, Karniadakis, J Chem Phys, 143: 014101 (2015).  DOI:10.1063/1.4923254.
 
+**(Liang)**
+   Liang, Phillpot, Sinnott Phys. Rev. B79 245110, (2009), Erratum: Phys. Rev. B85 199903(E), (2012)
+
 **(Lisal)**
-   M.\  Lisal, J.K. Brennan, J. Bonet Avalos, "Dissipative particle dynamics at isothermal, isobaric, isoenergetic, and isoenthalpic conditions using Shardlow-like splitting algorithms.",
+   M.\  Lisal, J.K. Brennan, J. Bonet Avalos, J. Chem. Phys., 135, 204105 (2011).
 
 **(Liu1)**
    L.\  Liu, Y. Liu, S. V. Zybin, H. Sun and W. A. Goddard, Journal of Physical Chemistry A, 115, 11016-11022 (2011).
@@ -637,6 +796,15 @@ Bibliography
 **(Luding, 2008)**
    Luding, S. (2008). Cohesive, frictional powders: contact models for tension. Granular matter, 10(4), 235.
 
+**(Lysogorskiy)**
+   Lysogorskiy, van der Oord, Bochkarev, Menon, Rinaldi, Hammerschmidt, Mrovec, Thompson, Csanyi, Ortner, Drautz, npj Comp Mat, 7, 97 (2021).
+
+**(Lysogorskiy21)**
+   Lysogorskiy, van der Oord, Bochkarev, Menon, Rinaldi, Hammerschmidt, Mrovec, Thompson, Csanyi, Ortner, Drautz, npj Comp Mat, 7, 97 (2021).
+
+**(Lysogorskiy23)**
+   Lysogorskiy, Bochkarev, Mrovec, Drautz, Phys Rev Mater, 7, 043801 (2023) / arXiv:2212.08716 (2022).
+
 **(Maaravi)**
    T.\  Maaravi et al, J. Phys. Chem. C 121, 22826-22835 (2017).
 
@@ -655,12 +823,18 @@ Bibliography
 **(Maginn)**
    Kelkar, Rafferty, Maginn, Siepmann, Fluid Phase Equilibria, 260, 218-231 (2007).
 
+**(Mahoney)**
+   Mahoney, Jorgensen, J Chem Phys 112, 8910 (2000)
+
 **(Malolepsza)**
    Malolepsza, Secor, Keyes, J Phys Chem B 119 (42), 13379-13384 (2015).
 
 **(Mandadapu)**
    Mandadapu, KK; Templeton, JA; Lee, JW, "Polarization as a field variable from molecular dynamics simulations." Journal of Chemical Physics (2013), 139:054115.  Please refer to the standard finite element (FE) texts, e.g. T.J.R Hughes " The finite element method ", Dover 2003, for the basics of FE simulation.
 
+**(Mandelli_1)**
+   D. Mandelli, W. Ouyang, M. Urbakh, and O. Hod, ACS Nano 13(7), 7603-7609 (2019).
+
 **(Maras)**
    Maras, Trushin, Stukowski, Ala-Nissila, Jonsson, Comp Phys Comm, 205, 13-21 (2016).
 
@@ -676,6 +850,9 @@ Bibliography
 **(Martyna1994)**
    Martyna, Tobias and Klein, J Chem Phys, 101, 4177 (1994).
 
+**(Martyna2)**
+  G. Martyna, A. Hughes, M. Tuckerman, J. Chem. Phys. 110, 3275 (1999).
+
 **(Mason)**
    J.\  K. Mason, Acta Cryst A65, 259 (2009).
 
@@ -715,6 +892,9 @@ Bibliography
 **(Mie)**
    G.\  Mie, Ann Phys, 316, 657 (1903).
 
+**(Milano)**
+   G. Milano, S. Goudeau, F. Mueller-Plathe, J. Polym. Sci. B Polym. Phys. 43, 871 (2005).
+
 **(Miller1)**
    T.\  F. Miller III, M. Eleftheriou, P. Pattnaik, A. Ndirango, G. J. Martyna, J. Chem. Phys., 116, 8649-8659 (2002).
 
@@ -745,12 +925,18 @@ Bibliography
 **(Mitchell2011a)**
    Mitchell. A Nonlocal, Ordinary, State-Based Plasticity Model for Peridynamics. Sandia National Lab Report, 3166:1-34 (2011).
 
+**(Miyazaki)**
+   Miyazaki, Okazaki, Shinoda, J Chem Theory Comput, 16, 782-793 (2020).
+
 **(Mniszewski)**
    S.\  M. Mniszewski, M. J. Cawkwell, M. E. Wall, J. Mohd-Yusof, N. Bock, T. C.  Germann, and A. M. N. Niklasson, J. Chem. Theory Comput., 11, 4644 (2015).
 
 **(Monaghan)**
    Monaghan and Gingold, Journal of Computational Physics, 52, 374-389 (1983).
 
+**(Monti)**
+   Monti, Clemmer, Srivastava, Silbert, Grest, and Lechman, Phys. Rev. E, (2022).
+
 **(Moore)**
    Moore, J Chem Phys, 144, 104501 (2016).
 
@@ -770,7 +956,7 @@ Bibliography
    Morris, Fox, Zhu, J Comp Physics, 136, 214-226 (1997).
 
 **(Moustafa)**
-   Sabry G. Moustafa, Andrew J. Schultz, and David A. Kofke, *Very fast averaging of thermal properties of crystals by molecular simulation*, `Phys. Rev. E [92], 043303 (2015) <https://link.aps.org/doi/10.1103/PhysRevE.92.043303>`_
+   Sabry G. Moustafa, Andrew J. Schultz, and David A. Kofke, `Phys. Rev. E [92], 043303 (2015) <https://link.aps.org/doi/10.1103/PhysRevE.92.043303>`_
 
 **(Muller-Plathe1)**
    Muller-Plathe, J Chem Phys, 106, 6082 (1997).
@@ -790,9 +976,6 @@ Bibliography
 **(Neelov)**
    Neelov, Holm, J Chem Phys 132, 234103 (2010)
 
-**(Negre2016)**
-   C.\  F. A. Negre, S. M. Mniszewski, M. J. Cawkwell, N. Bock, M. E. Wall, and A. M. N. Niklasson, J. Chem. Theory Comp., 12, 3063 (2016).
-
 **(Nelson)**
    Nelson, Halperin, Phys Rev B, 19, 2457 (1979).
 
@@ -802,12 +985,24 @@ Bibliography
 **(Neyts)**
    E.\  C. Neyts and A. Bogaerts, Theor. Chem. Acc. 132, 1320 (2013).
 
+**(Nguyen2023)**
+   Nguyen, Physical Review B, 107(14), 144103, (2023).
+
+**(Nguyen2024)**
+   Nguyen, Journal of Computational Physics, 113102, (2024).
+
+**(Nguyen and Rohskopf)**
+  Nguyen and Rohskopf,  Journal of Computational Physics, 480, 112030, (2023).
+
+**(Nguyen and Sema)**
+   Nguyen and Sema, https://arxiv.org/abs/2405.00306, (2024).
+
+**(NguyenTD)**
+   Nguyen, Li, Bagchi, Solis, Olvera de la Cruz, Comput Phys Commun 241, 80-19 (2019)
+
 **(Nicholson and Rutledge)**
    Nicholson and Rutledge, J Chem Phys, 145, 244903 (2016).
 
-**(Nicklas)**
-   The spline-based MEAM+SW format was first devised and used to develop potentials for bcc transition metals by Jeremy Nicklas, Michael Fellinger,
-
 **(Niklasson2002)**
    A.\  M. N. Niklasson, Phys. Rev. B, 66, 155115 (2002).
 
@@ -820,6 +1015,9 @@ Bibliography
 **(Niklasson2017)**
    A.\  M. N. Niklasson, J. Chem. Phys., 147, 054103 (2017).
 
+**(Nitol)**
+   Nitol, Dickel, and Barrett, Computational Materials Science 188 (2021): 110207.
+
 **(Noid)**
    Noid, Chu, Ayton, Krishna, Izvekov, Voth, Das, Andersen, J Chem Phys 128, 134105 (2008).
 
@@ -841,6 +1039,9 @@ Bibliography
 **(O'Connor)**
    O'Connor et al., J. Chem. Phys. 142, 024903 (2015).
 
+**(O'Hearn)**
+   O'Hearn, Alperen, Aktulga, SIAM J. Sci. Comput., 42(1), C1--C22 (2020).
+
 **(Okabe)**
    T.\  Okabe, M. Kawata, Y. Okamoto, M. Masuhiro, Chem. Phys. Lett., 335, 435-439 (2001).
 
@@ -850,6 +1051,8 @@ Bibliography
 **(Omelyan)**
    Omelyan, Mryglod, and Folk. Phys. Rev. Lett. 86(5), 898. (2001).
 
+**(OPLS-AA96)**  Jorgensen, Maxwell, Tirado-Rives, J Am Chem Soc, 118(45), 11225-11236 (1996).
+
 **(Oppelstrup)**
    Oppelstrup, unpublished, 2015. Oppelstrup and Moriarty, to be published.
 
@@ -871,14 +1074,17 @@ Bibliography
 **(Ouyang2)**
    W.\  Ouyang et al., J. Chem. Theory Comput. 16(1), 666-676 (2020).
 
-**(PASS)**
-   PASS webpage: https://www.sdu.dk/en/DPASS
+**(Ouyang_1)**
+   W. Ouyang et al., J. Chem. Theory Comput. 16(1), 666-676 (2020).
 
-**(PLUMED)**
-   G.A. Tribello, M. Bonomi, D. Branduardi, C. Camilloni and G. Bussi, Comp. Phys. Comm 185, 604 (2014)
+**(Ouyang6)**
+   W. Ouyang, O. Hod, and R. Guerra, J. Chem. Theory Comput. 17, 7215 (2021).
 
-**(Pavlov)**
-D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Journal of High Performance Computing Applications, 38, 34-49 (2024).
+**(Ouyang7)**
+   W. Ouyang, et al., J. Chem. Theory Comput. 17, 7237 (2021).
+
+**(Palkar)**
+   Palkar V, Kuksenok O, J. Phys. Chem. B, 126 (1), 336-346, 2022
 
 **(Paquay)**
    Paquay and Kusters, Biophys. J., 110, 6, (2016). preprint available at `arXiv:1411.3019 <https://arxiv.org/abs/1411.3019/>`_.
@@ -889,21 +1095,33 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Parks)**
    Parks, Lehoucq, Plimpton, Silling, Comp Phys Comm, 179(11), 777-783 (2008).
 
-**(Parrinello1981)**
+**(Parrinello)**
    Parrinello and Rahman, J Appl Phys, 52, 7182 (1981).
 
+**(PASS)**
+   PASS webpage: https://www.sdu.dk/en/DPASS
+
 **(Paula Leite2016)**
    Paula Leite , Freitas, Azevedo, and de Koning, J Chem Phys, 126, 044509 (2016).
 
 **(Paula Leite2017)**
    Paula Leite, Santos-Florez, and de Koning, Phys Rev E, 96, 32115 (2017).
 
+**(Pavlov1)**
+   D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Journal of High Performance Computing Applications, 38, 34-49 (2024).
+
+**(Pavlov2)**
+   Pavlov, Galigerov, Kolotinskii, Nikolskiy, Stegailov, "GPU-based Molecular Dynamics of Fluid Flows: Reaching for Turbulence", Int. J. High Perf. Comp. Appl., (2024)
+
 **(Pearlman)**
    Pearlman, J Chem Phys, 98, 1487 (1994)
 
 **(Pedersen)**
    Pedersen, J. Chem. Phys., 139, 104102 (2013).
 
+**(Pedone)**
+   A. Pedone, G. Malavasi, M. C. Menziani, A. N. Cormack, and U. Segre, J. Phys. Chem. B, 110, 11780 (2006)
+
 **(Peng)**
    Peng, Ren, Dudarev, Whelan, Acta Crystallogr. A, 52, 257-76 (1996).
 
@@ -925,6 +1143,9 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Pettifor_3)**
    D.G. Pettifor and I.I. Oleinik, Phys. Rev. B, 65, 172103 (2002).
 
+**(PFC)**
+   PFC Particle Flow Code 6.0 Documentation. Itasca Consulting Group.
+
 **(Phillips)**
    C.\  L. Phillips, J. A. Anderson, S. C. Glotzer, Comput Phys Comm, 230, 7191-7201 (2011).
 
@@ -934,9 +1155,21 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Pisarev)**
    V V Pisarev and S V Starikov, J. Phys.: Condens. Matter, 26, 475401 (2014).
 
+**(Plimpton)**
+   Plimpton and Knight, JPDC, 147, 184-195 (2021).
+
+**(PLUMED)**
+   G.A. Tribello, M. Bonomi, D. Branduardi, C. Camilloni and G. Bussi, Comp. Phys. Comm 185, 604 (2014)
+
 **(Pollock)**
    Pollock and Glosli, Comp Phys Comm, 95, 93 (1996).
 
+**(Ponder)**
+   Ponder, Wu, Ren, Pande, Chodera, Schnieders, Haque,  Mobley, Lambrecht, DiStasio Jr, M. Head-Gordon, Clark,  Johnson, T. Head-Gordon, J Phys Chem B, 114, 2549-2564 (2010).
+
+**(Popov1)**
+   A.M. Popov, I. V. Lebedeva, A. A. Knizhnik, Y. E. Lozovik and B. V. Potapkin, Chem. Phys. Lett. 536, 82-86 (2012).
+
 **(Price1)**
    Price and Brooks, J Chem Phys, 121, 10096 (2004).
 
@@ -976,6 +1209,12 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Rick)**
    S.\  W. Rick, S. J. Stuart, B. J. Berne, J Chem Phys 101, 16141 (1994).
 
+**(Rick2)**
+   S. W. Rick, S. J. Stuart, B. J. Berne, J Chem Phys 101, 6141
+
+**(Roberts)**
+   R. Roberts (2019) "Evenly Distributing Points in a Triangle." Extreme Learning.  `<http://extremelearning.com.au/evenly-distributing-points-in-a-triangle/>`_
+
 **(Rohart)**
    Rohart and Thiaville, Physical Review B, 88(18), 184422. (2013).
 
@@ -1012,9 +1251,18 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Sadigh)**
    B Sadigh, P Erhart, A Stukowski, A Caro, E Martinez, and L Zepeda-Ruiz, Phys. Rev. B, 85, 184203 (2012).
 
+**(Sadigh1)**
+   B. Sadigh, P. Erhart, A. Stukowski, A. Caro, E. Martinez, and L. Zepeda-Ruiz, Phys. Rev. B **85**, 184203 (2012)
+
+**(Sadigh2)**
+  B. Sadigh and P. Erhart, Phys. Rev. B **86**, 134204 (2012)
+
 **(Safran)**
    Safran, Statistical Thermodynamics of Surfaces, Interfaces, And Membranes, Westview Press, ISBN: 978-0813340791 (2003).
 
+**(Salanne)**
+   Salanne, Rotenberg, Jahn, Vuilleumier, Simon, Christian and Madden, Theor Chem Acc, 131, 1143 (2012).
+
 **(Salerno)**
    Salerno, Bernstein, J Chem Theory Comput, --, ---- (2018).
 
@@ -1024,9 +1272,18 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Sanyal2)**
    Sanyal and Shell, Journal of Physical Chemistry B, 122 (21), 5678-5693.
 
+**(Scalfi)**
+   Scalfi *et al.*, J. Chem. Phys., 153, 174704 (2020).
+
 **(Schelling)**
    Patrick K. Schelling, Comp. Mat. Science, 44, 274 (2008).
 
+**(Scherer1)**
+   C. Scherer and D. Andrienko, Phys. Chem. Chem. Phys. 20, 22387-22394 (2018).
+
+**(Scherer2)**
+   C. Scherer, R. Scheid, D. Andrienko, and T. Bereau, J. Chem. Theor. Comp. 16, 3194-3204 (2020).
+
 **(Schlitter1)**
    Schlitter, Swegat, Mulders, "Distance-type reaction coordinates for modelling activated processes", J Molecular Modeling, 7, 171-177 (2001).
 
@@ -1045,21 +1302,36 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Schroeder)**
    Schroeder and Steinhauser, J Chem Phys, 133, 154511 (2010).
 
+**(Seleson 2010)**
+   Seleson, Parks, Int J Mult Comp Eng 9(6), pp. 689-706, 2011.
+
 **(Semaev)**
    Semaev, Cryptography and Lattices, 181 (2001).
 
+**(Seo)**
+   Seo, Shinoda, J Chem Theory Comput, 15, 762-774 (2019).
+
 **(Sheppard)**
    Sheppard, Terrell, Henkelman, J Chem Phys, 128, 134106 (2008).  See ref 1 in this paper for original reference to Qmin in Jonsson, Mills, Jacobsen.
 
+**(Shi)**
+   Shi, Xia, Zhang, Best, Wu, Ponder, Ren, J Chem Theory Comp, 9, 4046, 2013.
+
 **(Shinoda)**
    Shinoda, DeVane, Klein, Mol Sim, 33, 27 (2007).
 
 **(Shinoda)**
    Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).
 
+**(Shire)**
+   Shire, Hanley and Stratford, Comp. Part. Mech., (2020).
+
 **(Sides)**
    Sides, Grest, Stevens, Plimpton, J Polymer Science B, 42, 199-208 (2004).
 
+**(Siepmann)**
+   Siepmann and Sprik, J. Chem. Phys. 102, 511 (1995).
+
 **(Silbert)**
    Silbert, Ertas, Grest, Halsey, Levine, Plimpton, Phys Rev E, 64, p 051302 (2001).
 
@@ -1069,12 +1341,21 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Silling 2000)**
    Silling, J Mech Phys Solids, 48, 175-209 (2000).
 
+**(Silling 2005)**
+   Silling Askari, Computer and Structures, 83, 1526-1535 (2005).
+
 **(Silling 2007)**
    Silling, Epton, Weckner, Xu, Askari, J Elasticity, 88, 151-184 (2007).
 
 **(Singh)**
    Singh and Warner, Acta Mater, 58, 5797-5805 (2010),
 
+**(Singraber, Behler and Dellago 2019)**
+   Singraber, A.; Behler, J.; Dellago, C. J., Chem.  Theory Comput. 2019, 15 (3), 1827-1840
+
+**(Singraber et al 2019)**
+   Singraber, A.; Morawietz, T.; Behler, J.; Dellago, C., J. Chem. Theory Comput.  2019, 15 (5), 3075-3092.
+
 **(Sirk1)**
    Sirk TW, Sliozberg YR, Brennan JK, Lisal M, Andzelm JW, J Chem Phys, 136 (13) 134903, 2012.
 
@@ -1087,6 +1368,9 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Snodin)**
    B.E. Snodin, F. Randisi, M. Mosayebi, et al., J. Chem. Phys. 142, 234901 (2015).
 
+**(Son)**
+   Son, McDaniel, Cui and Yethiraj, J Phys Chem Lett, 10, 7523 (2019).
+
 **(Srivastava)**
    Zhigilei, Wei, Srivastava, Phys. Rev. B 71, 165417 (2005).
 
@@ -1096,6 +1380,12 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Steinhardt)**
    P.\  Steinhardt, D. Nelson, and M. Ronchetti, Phys. Rev. B 28, 784 (1983).
 
+**(Steward)**
+   Stewart, Spearot, Modelling Simul. Mater. Sci. Eng. 21, 045003, (2013).
+
+**(Stewart2018)**
+   J.A. Stewart, et al. (2018) Journal of Applied Physics, 123(16), 165902.
+
 **(Stiles)**
    Stiles , Hubbard, and Kayser, J Chem Phys, 77, 6189 (1982).
 
@@ -1153,12 +1443,21 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Tainter 2015)**
    Tainter, Shi, and Skinner, 11, 2268 (2015)
 
+**(Tang and Toennies)**
+   J Chem Phys, 80, 3726 (1984).
+
+**(Tee)**
+   Tee and Searles, J. Chem. Phys. 156, 184101 (2022).
+
 **(Templeton2010)**
    Templeton, JA; Jones, RE; Wagner, GJ, "Application of a field-based method to spatially varying thermal transport problems in molecular dynamics." Modelling and Simulation in Materials Science and Engineering (2010), 18:085007.
 
 **(Templeton2011)**
    Templeton, JA; Jones, RE; Lee, JW; Zimmerman, JA; Wong, BM, "A long-range electric field solver for molecular dynamics based on atomistic-to-continuum modeling." Journal of Chemical Theory and Computation (2011), 7:1736.
 
+**(tenWolde)**
+   P.\  R. ten Wolde, M. J. Ruiz-Montero, D. Frenkel, J. Chem. Phys. 104, 9932 (1996).
+
 **(Tersoff_1)**
    J.\  Tersoff, Phys Rev B, 37, 6991 (1988).
 
@@ -1201,6 +1500,9 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Tranchida)**
    Tranchida, Plimpton, Thibaudeau and Thompson, Journal of Computational Physics, 372, 406-425, (2018).
 
+**(Tribello)**
+   G.A. Tribello, M. Bonomi, D. Branduardi, C. Camilloni and G. Bussi, Comp. Phys. Comm 185, 604 (2014)
+
 **(Tsuji et al, 1992)**
    Tsuji, Y., Tanaka, T., & Ishida, T. (1992). Lagrangian numerical simulation of plug flow of cohesionless particles in a horizontal pipe. Powder technology, 71(3),
 
@@ -1219,6 +1521,9 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Tuckerman4)**
    Tuckerman, Mundy, Balasubramanian, Klein, J Chem Phys, 106, 5615 (1997).
 
+**(Tyagi)**
+   Tyagi, Suzen, Sega, Barbosa, Kantorovich, Holm, J Chem Phys, 132, 154112 (2010)
+
 **(Ulomek)**
    Ulomek, Brien, Foiles, Mohles, Modelling Simul. Mater. Sci. Eng. 23 (2015) 025007
 
@@ -1228,6 +1533,15 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Valone)**
    Valone, Baskes, Martin, Phys. Rev. B, 73, 214209 (2006).
 
+**(vanWijk)**
+   M. M. van Wijk, A. Schuring, M. I. Katsnelson, and A. Fasolino, Physical Review Letters, 113, 135504 (2014)
+
+**(Van Workum)**
+   K. Van Workum et al., J. Chem. Phys. 125 144506 (2006)
+
+**(Vargas and McCarthy 2001)**
+   Vargas, W.L. and McCarthy, J.J. (2001).
+
 **(Varshalovich)**
    Varshalovich, Moskalev, Khersonskii, Quantum Theory of Angular Momentum, World Scientific, Singapore (1987).
 
@@ -1240,6 +1554,9 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Veld)**
    In 't Veld, Ismail, Grest, J Chem Phys, 127, 144711 (2007).
 
+**(Verstraelen)**
+   Verstraelen, Ayers, Speybroeck, Waroquier, J. Chem. Phys. 138, 074108 (2013).
+
 **(Volkov1)**
    Volkov and Zhigilei, J Phys Chem C, 114, 5513 (2010).
 
@@ -1264,6 +1581,9 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Wang et al, 2015)**
    Wang, Y., Alonso-Marroquin, F., & Guo, W. W. (2015).  Rolling and sliding in 3-D discrete element models. Particuology, 23, 49-55.
 
+**(Wang2020)**
+   X. Wang, S. Ramirez-Hinestrosa, J. Dobnikar, and D. Frenkel, Phys. Chem. Chem. Phys. 22, 10624 (2020).
+
 **(Wang1)**
    J.\  Wang, H. S. Yu, P. A. Langston, F. Y. Fraige, Granular Matter, 13, 1 (2011).
 
@@ -1303,6 +1623,9 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Wicaksono2)**
    Wicaksono, figshare, https://doi.org/10.6084/m9.figshare.1488628.v1 (2015).
 
+**(Winkler)**
+   Winkler, Wysocki, and Gompper, Soft Matter, 11, 6680 (2015).
+
 **(Wirnsberger)**
    Wirnsberger, Frenkel, and Dellago, J Chem Phys, 143, 124104 (2015).
 
@@ -1315,9 +1638,27 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Wood)**
    Wood and Thompson, J Chem Phys, 148, 241721, (2018)
 
+**(Xie23)**
+   Xie, S.R., Rupp, M. & Hennig, R.G. Ultra-fast interpretable machine-learning potentials. npj Comput Mater 9, 162 (2023). https://doi.org/10.1038/s41524-023-01092-7
+
+**(Yade-DEM)**
+   V. Smilauer et al. (2021), Yade Documentation 3rd ed.
+
+**(Yanxon2020)**
+   Yanxon, Zagaceta, Tang, Matteson, Zhu, Mach. Learn.: Sci. Technol. 2, 027001 (2020).
+
 **(Yeh)**
    Yeh and Berkowitz, J Chem Phys, 111, 3155 (1999).
 
+**(Yuan2010a)**
+   Yuan, Huang, Li, Lykotrafitis, Zhang, Phys. Rev. E, 82, 011905(2010).
+
+**(Yuan2010b)**
+   Yuan, Huang, Zhang, Soft. Matter, 6, 4571(2010).
+
+**(Zagaceta2020)**
+   Zagaceta, Yanxon, Zhu, J Appl Phys, 128, 045113 (2020).
+
 **(ZBL)**
    J.F. Ziegler, J.P. Biersack, U. Littmark, 'Stopping and Ranges of Ions in Matter' Vol 1, 1985, Pergamon Press.
 
@@ -1387,17 +1728,6 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo
 **(Zimmerman2010)**
    Zimmerman, JA; Jones, RE; Templeton, JA, "A material frame approach for evaluating continuum variables in atomistic simulations." Journal of Computational Physics (2010), 229:2364.
 
-**(de Buyl)**
-   de Buyl, Colberg and Hofling, H5MD: A structured, efficient, and portable file format for molecular data, Comp. Phys. Comm. 185(6), 1546-1553 (2014) -
-
-**(de Koning)**
-   de Koning and Antonelli, Phys Rev E, 53, 465 (1996).
-
 **(electronic stopping)**
    Wikipedia - Electronic Stopping Power: https://en.wikipedia.org/wiki/Stopping_power_%28particle_radiation%29
 
-**(tenWolde)**
-   P.\  R. ten Wolde, M. J. Ruiz-Montero, D. Frenkel, J. Chem. Phys. 104, 9932 (1996).
-
-**(vanWijk)**
-   M.\  M. van Wijk, A. Schuring, M. I. Katsnelson, and A. Fasolino, Physical Review Letters, 113, 135504 (2014)

doc/src/Build.rst

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

doc/src/Build_basics.rst

@@ -37,8 +37,9 @@ standard. A more detailed discussion of that is below.
 
       .. code-block:: bash
 
-         -D BUILD_MPI=value        # yes or no, default is yes if CMake finds MPI, else no
-         -D BUILD_OMP=value        # yes or no, default is yes if a compatible compiler is detected
+         -D BUILD_MPI=value        # yes or no, default is yes if CMake finds MPI
+         -D BUILD_OMP=value        # yes or no, default is yes if a compatible
+                                   # compiler is detected
          -D LAMMPS_MACHINE=name    # name = mpi, serial, mybox, titan, laptop, etc
                                    # no default value
 
@@ -54,9 +55,9 @@ standard. A more detailed discussion of that is below.
 
       .. code-block:: bash
 
-         make mpi                # parallel build, produces lmp_mpi using Makefile.mpi
-         make serial             # serial build, produces lmp_serial using Makefile/serial
-         make mybox              # uses Makefile.mybox to produce lmp_mybox
+         make mpi      # parallel build, produces lmp_mpi using Makefile.mpi
+         make serial   # serial build, produces lmp_serial using Makefile/serial
+         make mybox    # uses Makefile.mybox to produce lmp_mybox
 
       Any ``make machine`` command will look up the make settings from a
       file ``Makefile.machine`` in the folder ``src/MAKE`` or one of its
@@ -74,15 +75,15 @@ standard. A more detailed discussion of that is below.
       this is ``-fopenmp``\ , which can be added to the ``CC`` and
       ``LINK`` makefile variables.
 
-      For the serial build the following make variables are set (see src/MAKE/Makefile.serial):
+      For the serial build the following make variables are set (see ``src/MAKE/Makefile.serial``):
 
       .. code-block:: make
 
-         CC =            g++
-         LINK =          g++
-         MPI_INC =       -I../STUBS
-         MPI_PATH =      -L../STUBS
-         MPI_LIB =       -lmpi_stubs
+         CC =       g++
+         LINK =     g++
+         MPI_INC =  -I../STUBS
+         MPI_PATH = -L../STUBS
+         MPI_LIB =  -lmpi_stubs
 
       You also need to build the STUBS library for your platform before
       making LAMMPS itself.  A ``make serial`` build does this for you
@@ -159,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.
 
@@ -195,13 +196,18 @@ LAMMPS.
 
    .. tab:: CMake build
 
-      By default CMake will use the compiler it finds according to
+      By default CMake will use the compiler it finds according to its
       internal preferences, and it will add optimization flags
       appropriate to that compiler and any :doc:`accelerator packages
       <Speed_packages>` you have included in the build.  CMake will
       check if the detected or selected compiler is compatible with the
       C++ support requirements of LAMMPS and stop with an error, if this
-      is not the case.
+      is not the case.  A C++11 compatible compiler is currently
+      required, but a transition to require C++17 is in progress and
+      planned to be completed in Summer 2025. Currently, setting
+      ``-DLAMMPS_CXX11=yes`` is required when configuring with CMake while
+      using a C++11 compatible compiler that does not support C++17,
+      otherwise setting ``-DCMAKE_CXX_STANDARD=17`` is preferred.
 
       You can tell CMake to look for a specific compiler with setting
       CMake variables (listed below) during configuration.  For a few
@@ -222,6 +228,8 @@ LAMMPS.
          -D CMAKE_C_COMPILER=name              # name of C compiler
          -D CMAKE_Fortran_COMPILER=name        # name of Fortran compiler
 
+         -D CMAKE_CXX_STANDARD=17              # put compiler in C++17 mode
+         -D LAMMPS_CXX11=yes                   # enforce compilation in C++11 mode
          -D CMAKE_CXX_FLAGS=string             # flags to use with C++ compiler
          -D CMAKE_C_FLAGS=string               # flags to use with C compiler
          -D CMAKE_Fortran_FLAGS=string         # flags to use with Fortran compiler
@@ -231,24 +239,32 @@ LAMMPS.
       .. code-block:: bash
 
          # Building with GNU Compilers:
-         cmake ../cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran
-         # Building with Intel Compilers:
-         cmake ../cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort
+         cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ \
+               -DCMAKE_Fortran_COMPILER=gfortran ../cmake
+         # Building with Intel Classic Compilers:
+         cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc \
+               -DCMAKE_Fortran_COMPILER=ifort ../cmake
          # Building with Intel oneAPI Compilers:
-         cmake ../cmake -DCMAKE_C_COMPILER=icx -DCMAKE_CXX_COMPILER=icpx -DCMAKE_Fortran_COMPILER=ifx
+         cmake -DCMAKE_C_COMPILER=icx -DCMAKE_CXX_COMPILER=icpx \
+               -DCMAKE_Fortran_COMPILER=ifx ../cmake
          # Building with LLVM/Clang Compilers:
-         cmake ../cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_Fortran_COMPILER=flang
+         cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ \
+               -DCMAKE_Fortran_COMPILER=flang ../cmake
          # Building with PGI/Nvidia Compilers:
-         cmake ../cmake -DCMAKE_C_COMPILER=pgcc -DCMAKE_CXX_COMPILER=pgc++ -DCMAKE_Fortran_COMPILER=pgfortran
+         cmake -DCMAKE_C_COMPILER=pgcc -DCMAKE_CXX_COMPILER=pgc++ \
+               -DCMAKE_Fortran_COMPILER=pgfortran ../cmake
+         # Building with the NVHPC Compilers:
+         cmake -DCMAKE_C_COMPILER=nvc -DCMAKE_CXX_COMPILER=nvc++ \
+               -DCMAKE_Fortran_COMPILER=nvfortran ../cmake
 
       For compiling with the Clang/LLVM compilers a CMake preset is
       provided that can be loaded with
-      `-C ../cmake/presets/clang.cmake`.  Similarly,
-      `-C ../cmake/presets/intel.cmake` should switch the compiler
-      toolchain to the legacy Intel compilers, `-C ../cmake/presets/oneapi.cmake`
+      ``-C ../cmake/presets/clang.cmake``.  Similarly,
+      ``-C ../cmake/presets/intel.cmake`` should switch the compiler
+      toolchain to the legacy Intel compilers, ``-C ../cmake/presets/oneapi.cmake``
       will switch to the LLVM based oneAPI Intel compilers,
-      and `-C ../cmake/presets/pgi.cmake`
-      will switch the compiler to the PGI compilers.
+      ``-C ../cmake/presets/pgi.cmake`` will switch the compiler to the PGI compilers,
+      and ``-C ../cmake/presets/nvhpc.cmake`` will switch to the NVHPC compilers.
 
       Furthermore, you can set ``CMAKE_TUNE_FLAGS`` to specifically add
       compiler flags to tune for optimal performance on given hosts.
@@ -259,7 +275,7 @@ LAMMPS.
          When the cmake command completes, it prints a summary to the
          screen which compilers it is using and what flags and settings
          will be used for the compilation.  Note that if the top-level
-         compiler is mpicxx, it is simply a wrapper on a real compiler.
+         compiler is ``mpicxx``, it is simply a wrapper on a real compiler.
          The underlying compiler info is what CMake will try to
          determine and report.  You should check to confirm you are
          using the compiler and optimization flags you want.
@@ -278,19 +294,19 @@ LAMMPS.
 
       .. code-block:: make
 
-         CC =            mpicxx
-         CCFLAGS =       -g -O3
-         LINK =          mpicxx
-         LINKFLAGS =     -g -O
+         CC =        mpicxx
+         CCFLAGS =   -g -O3
+         LINK =      mpicxx
+         LINKFLAGS = -g -O
 
       Serial build with GNU gcc (see ``src/MAKE/Makefile.serial``):
 
       .. code-block:: make
 
-         CC =            g++
-         CCFLAGS =       -g -O3
-         LINK =          g++
-         LINKFLAGS =     -g -O
+         CC =        g++
+         CCFLAGS =   -g -O3
+         LINK =      g++
+         LINKFLAGS = -g -O
 
       .. note::
 
@@ -312,15 +328,23 @@ LAMMPS.
          you would have to install a newer compiler that supports C++11;
          either as a binary package or through compiling from source.
 
-         If you build LAMMPS with any :doc:`Speed_packages` included,
-         there may be specific compiler or linker flags that are either
-         required or recommended to enable required features and to
-         achieve optimal performance.  You need to include these in the
-         CCFLAGS and LINKFLAGS settings above.  For details, see the
-         documentation for the individual packages listed on the
-         :doc:`Speed_packages` page.  Or examine these files in the
-         src/MAKE/OPTIONS directory.  They correspond to each of the 5
-         accelerator packages and their hardware variants:
+      While a C++11 compatible compiler is currently sufficient to compile
+      LAMMPS, a transition to require C++17 is in progress and planned to
+      be completed in Summer 2025. Currently, setting ``-DLAMMPS_CXX11``
+      in the ``LMP_INC =`` line in the machine makefile is required when
+      using a C++11 compatible compiler that does not support C++17.
+      Otherwise, to enable C++17 support (if not enabled by default) using
+      a compiler flag like ``-std=c++17`` in CCFLAGS may needed.
+
+      If you build LAMMPS with any :doc:`Speed_packages` included,
+      there may be specific compiler or linker flags that are either
+      required or recommended to enable required features and to
+      achieve optimal performance.  You need to include these in the
+      ``CCFLAGS`` and ``LINKFLAGS`` settings above.  For details, see the
+      documentation for the individual packages listed on the
+      :doc:`Speed_packages` page.  Or examine these files in the
+      ``src/MAKE/OPTIONS`` directory.  They correspond to each of the 5
+      accelerator packages and their hardware variants:
 
          .. code-block:: bash
 
@@ -388,7 +412,8 @@ running LAMMPS from Python via its library interface.
 
          make machine               # build LAMMPS executable lmp_machine
          make mode=static machine   # same as "make machine"
-         make mode=shared machine   # build LAMMPS shared lib liblammps_machine.so instead
+         make mode=shared machine   # build LAMMPS shared lib liblammps_machine.so
+                                    # instead
 
       The "static" build will generate a static library called
       ``liblammps_machine.a`` and an executable named ``lmp_machine``\ ,
@@ -450,7 +475,7 @@ installation.
 Including or removing debug support
 -----------------------------------
 
-By default the compilation settings will include the *-g* flag which
+By default the compilation settings will include the ``-g`` flag which
 instructs the compiler to include debug information (e.g. which line of
 source code a particular instruction correspond to).  This can be
 extremely useful in case LAMMPS crashes and can help to provide crucial
@@ -463,7 +488,7 @@ If this is a concern, you can change the compilation settings or remove
 the debug information from the LAMMPS executable:
 
 - **Traditional make**: edit your ``Makefile.<machine>`` to remove the
-  *-g* flag from the ``CCFLAGS`` and ``LINKFLAGS`` definitions
+  ``-g`` flag from the ``CCFLAGS`` and ``LINKFLAGS`` definitions
 - **CMake**: use ``-D CMAKE_BUILD_TYPE=Release`` or explicitly reset
   the applicable compiler flags (best done using the text mode or
   graphical user interface).
@@ -488,9 +513,12 @@ using CMake or Make.
 
       .. code-block:: bash
 
-         -D BUILD_TOOLS=value         # yes or no (default). Build binary2txt, chain.x, micelle2d.x, msi2lmp, phana, stl_bin2txt
-         -D BUILD_LAMMPS_SHELL=value  # yes or no (default). Build lammps-shell
-         -D BUILD_LAMMPS_GUI=value    # yes or no (default). Build lammps-gui
+         -D BUILD_TOOLS=value         # yes or no (default). Build binary2txt,
+                                      # 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).
@@ -505,8 +533,9 @@ using CMake or Make.
          make chain            # build only chain tool
          make micelle2d        # build only micelle2d tool
 
-         cd lammps/tools/lammps-shell
-         make                  # build LAMMPS shell
+      .. note::
+
+         Building the LAMMPS-GUI *requires* building LAMMPS with CMake.
 
 ----------
 

doc/src/Build_cmake.rst

@@ -8,7 +8,7 @@ packages.  Links to those pages on the :doc:`Build overview <Build>`
 page.
 
 The following text assumes some familiarity with CMake and focuses on
-using the command line tool ``cmake`` and what settings are supported
+using the command-line tool ``cmake`` and what settings are supported
 for building LAMMPS.  A more detailed tutorial on how to use CMake
 itself, the text mode or graphical user interface, to change the
 generated output files for different build tools and development
@@ -16,7 +16,7 @@ environments is on a :doc:`separate page <Howto_cmake>`.
 
 .. note::
 
-   LAMMPS currently requires that CMake version 3.16 or later is available.
+   LAMMPS currently requires that CMake version 3.20 or later is available.
 
 .. warning::
 
@@ -32,22 +32,22 @@ environments is on a :doc:`separate page <Howto_cmake>`.
 Advantages of using CMake
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
-CMake is an alternative to compiling LAMMPS in the traditional way
-through :doc:`(manually customized) makefiles <Build_make>`.  Using
-CMake has multiple advantages that are specifically helpful for
-people with limited experience in compiling software or for people
-that want to modify or extend LAMMPS.
+CMake is the preferred way of compiling LAMMPS in contrast to the legacy
+build system based on GNU make and through :doc:`(manually customized)
+makefiles <Build_make>`.  Using CMake has multiple advantages that are
+specifically helpful for people with limited experience in compiling
+software or for people that want to modify or extend LAMMPS.
 
 - CMake can detect available hardware, tools, features, and libraries
   and adapt the LAMMPS default build configuration accordingly.
 - CMake can generate files for different build tools and integrated
   development environments (IDE).
-- CMake supports customization of settings with a command line, text
+- CMake supports customization of settings with a command-line, text
   mode, or graphical user interface.  No manual editing of files,
-  knowledge of file formats or complex command line syntax is required.
+  knowledge of file formats or complex command-line syntax is required.
 - All enabled components are compiled in a single build operation.
 - Automated dependency tracking for all files and configuration options.
-- Support for true out-of-source compilation. Multiple configurations
+- Support for true out-of-source compilation.  Multiple configurations
   and settings with different choices of LAMMPS packages, settings, or
   compilers can be configured and built concurrently from the same
   source tree.
@@ -68,7 +68,7 @@ that purpose you can use either the command-line utility ``cmake`` (or
 graphical utility ``cmake-gui``, or use them interchangeably.  The
 second step is then the compilation and linking of all objects,
 libraries, and executables using the selected build tool.  Here is a
-minimal example using the command line version of CMake to build LAMMPS
+minimal example using the command-line version of CMake to build LAMMPS
 with no add-on packages enabled and no customization:
 
 .. code-block:: bash
@@ -131,21 +131,21 @@ 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.
+user interface.  The ``-D`` flag can be used several times in one command.
 
 For your convenience, we provide :ref:`CMake presets <cmake_presets>`
 that combine multiple settings to enable optional LAMMPS packages or use
-a different compiler tool chain.  Those are loaded with the *-C* flag
+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
+for IDEs like Eclipse, CodeBlocks, or Kate can be selected using the ``-G``
+command-line flag.  A list of available generator settings for your
 specific CMake version is given when running ``cmake --help``.
 
 .. _cmake_multiconfig:
@@ -171,7 +171,7 @@ files. E.g.  with:
 In that case the resulting binaries are not in the build folder directly
 but in subdirectories corresponding to the build type (i.e. Release in
 the example from above).  Similarly, for running unit tests the
-configuration is selected with the *-C* flag:
+configuration is selected with the ``-C`` flag:
 
 .. code-block:: bash
 

doc/src/Build_development.rst

@@ -88,8 +88,8 @@ on recording all commands required to do the compilation.
 
 .. _sanitizer:
 
-Address, Undefined Behavior, and Thread Sanitizer Support (CMake only)
-----------------------------------------------------------------------
+Address, Leak, Undefined Behavior, and Thread Sanitizer Support (CMake only)
+----------------------------------------------------------------------------
 
 Compilers such as GCC and Clang support generating instrumented binaries
 which use different sanitizer libraries to detect problems in the code
@@ -110,6 +110,7 @@ compilation and linking stages.  This is done through setting the
 
    -D ENABLE_SANITIZER=none       # no sanitizer active (default)
    -D ENABLE_SANITIZER=address    # enable address sanitizer / memory leak checker
+   -D ENABLE_SANITIZER=hwaddress  # enable hardware assisted address sanitizer / memory leak checker
    -D ENABLE_SANITIZER=leak       # enable memory leak checker (only)
    -D ENABLE_SANITIZER=undefined  # enable undefined behavior sanitizer
    -D ENABLE_SANITIZER=thread     # enable thread sanitizer
@@ -137,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
@@ -152,7 +168,12 @@ development headers to compile (if those are not found locally a recent
 version of that library will be downloaded and compiled along with
 LAMMPS and the test programs) and will download and compile a specific
 version of the `GoogleTest <https://github.com/google/googletest/>`_ C++
-test framework that is used to implement the tests.
+test framework that is used to implement the tests.  Those unit tests
+may be combined with memory access and leak checking with valgrind
+(see below for how to enable it).  In that case, running so-called
+death tests will create a lot of false positives and thus they can be
+disabled by configuring compilation with the additional setting
+``-D SKIP_DEATH_TESTS=on``.
 
 .. admonition:: Software version and LAMMPS configuration requirements
    :class: note
@@ -175,24 +196,24 @@ The output of this command will be looking something like this:
     $ ctest
     Test project /home/akohlmey/compile/lammps/build-testing
          Start   1: RunLammps
-   1/563 Test   #1: RunLammps ..........................................   Passed    0.28 sec
+   1/563 Test   #1: RunLammps ..................................   Passed    0.28 sec
          Start   2: HelpMessage
-   2/563 Test   #2: HelpMessage ........................................   Passed    0.06 sec
+   2/563 Test   #2: HelpMessage ................................   Passed    0.06 sec
          Start   3: InvalidFlag
-   3/563 Test   #3: InvalidFlag ........................................   Passed    0.06 sec
+   3/563 Test   #3: InvalidFlag ................................   Passed    0.06 sec
          Start   4: Tokenizer
-   4/563 Test   #4: Tokenizer ..........................................   Passed    0.05 sec
+   4/563 Test   #4: Tokenizer ..................................   Passed    0.05 sec
          Start   5: MemPool
-   5/563 Test   #5: MemPool ............................................   Passed    0.05 sec
+   5/563 Test   #5: MemPool ....................................   Passed    0.05 sec
          Start   6: ArgUtils
-   6/563 Test   #6: ArgUtils ...........................................   Passed    0.05 sec
+   6/563 Test   #6: ArgUtils ...................................   Passed    0.05 sec
        [...]
          Start 561: ImproperStyle:zero
- 561/563 Test #561: ImproperStyle:zero .................................   Passed    0.07 sec
+ 561/563 Test #561: ImproperStyle:zero .........................   Passed    0.07 sec
          Start 562: TestMliapPyUnified
- 562/563 Test #562: TestMliapPyUnified .................................   Passed    0.16 sec
+ 562/563 Test #562: TestMliapPyUnified .........................   Passed    0.16 sec
          Start 563: TestPairList
- 563/563 Test #563: TestPairList .......................................   Passed    0.06 sec
+ 563/563 Test #563: TestPairList ...............................   Passed    0.06 sec
 
  100% tests passed, 0 tests failed out of 563
 
@@ -207,24 +228,25 @@ The output of this command will be looking something like this:
 The ``ctest`` command has many options, the most important ones are:
 
 .. list-table::
+   :widths: 20 80
 
    * - Option
      - Function
-   * - -V
+   * - ``-V``
      - verbose output: display output of individual test runs
-   * - -j <num>
+   * - ``-j <num>``
      - parallel run: run <num> tests in parallel
-   * - -R <regex>
+   * - ``-R <regex>``
      - run subset of tests matching the regular expression <regex>
-   * - -E <regex>
+   * - ``-E <regex>``
      - exclude subset of tests matching the regular expression <regex>
-   * - -L <regex>
+   * - ``-L <regex>``
      - run subset of tests with a label matching the regular expression <regex>
-   * - -LE <regex>
+   * - ``-LE <regex>``
      - exclude subset of tests with a label matching the regular expression <regex>
-   * - -N
+   * - ``-N``
      - dry-run: display list of tests without running them
-   * - -T memcheck
+   * - ``-T memcheck``
      - run tests with valgrind memory checker (if available)
 
 In its full implementation, the unit test framework will consist of multiple
@@ -241,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
@@ -330,16 +352,17 @@ paths in the individual source files.
 The force style test programs have a common set of options:
 
 .. list-table::
+   :widths: 25 75
 
    * - Option
      - Function
-   * - -g <newfile>
+   * - ``-g <newfile>``
      - regenerate reference data in new YAML file
-   * - -u
+   * - ``-u``
      - update reference data in the original YAML file
-   * - -s
+   * - ``-s``
      - print error statistics for each group of comparisons
-   * - -v
+   * - ``-v``
      - verbose output: also print the executed LAMMPS commands
 
 The ``ctest`` tool has no mechanism to directly pass flags to the individual
@@ -353,10 +376,10 @@ set in an environment variable ``TEST_ARGS``. Example:
 To add a test for a style that is not yet covered, it is usually best
 to copy a YAML file for a similar style to a new file, edit the details
 of the style (how to call it, how to set its coefficients) and then
-run test command with either the *-g* and the replace the initial
-test file with the regenerated one or the *-u* option.  The *-u* option
+run test command with either the ``-g`` and the replace the initial
+test file with the regenerated one or the ``-u`` option.  The ``-u`` option
 will destroy the original file, if the generation run does not complete,
-so using *-g* is recommended unless the YAML file is fully tested
+so using ``-g`` is recommended unless the YAML file is fully tested
 and working.
 
 Some of the force style tests are rather slow to run and some are very
@@ -397,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
@@ -506,27 +529,51 @@ After post-processing with ``gen_coverage_html`` the results are in
 a folder ``coverage_html`` and can be viewed with a web browser.
 The images below illustrate how the data is presented.
 
-.. list-table::
+.. only:: not latex
 
-      * - .. figure:: JPG/coverage-overview-top.png
-             :scale: 25%
+   .. list-table::
 
-          Top of the overview page
+         * - .. figure:: JPG/coverage-overview-top.png
+                :scale: 25%
 
-        - .. figure:: JPG/coverage-overview-manybody.png
-             :scale: 25%
+             Top of the overview page
 
-          Styles with good coverage
+           - .. figure:: JPG/coverage-overview-manybody.png
+                :scale: 25%
 
-        - .. figure:: JPG/coverage-file-top.png
-             :scale: 25%
+             Styles with good coverage
 
-          Top of individual source page
+           - .. figure:: JPG/coverage-file-top.png
+                :scale: 25%
 
-        - .. figure:: JPG/coverage-file-branches.png
-             :scale: 25%
+             Top of individual source page
 
-          Source page with branches
+           - .. figure:: JPG/coverage-file-branches.png
+                :scale: 25%
+
+             Source page with branches
+
+.. only:: latex
+
+   .. figure:: JPG/coverage-overview-top.png
+      :width: 60%
+
+      Top of the overview page
+
+   .. figure:: JPG/coverage-overview-manybody.png
+      :width: 60%
+
+      Styles with good coverage
+
+   .. figure:: JPG/coverage-file-top.png
+      :width: 60%
+
+      Top of individual source page
+
+   .. figure:: JPG/coverage-file-branches.png
+      :width: 60%
+
+      Source page with branches
 
 Coding style utilities
 ----------------------
@@ -595,14 +642,38 @@ The following target are available for both, GNU make and CMake:
 
 .. _gh-cli:
 
-GitHub command line interface
+GitHub command-line interface
 -----------------------------
 
-GitHub is developing a `tool for the command line
-<https://cli.github.com>`_ that interacts with the GitHub website via a
-command called ``gh``.  This can be extremely convenient when working
-with a Git repository hosted on GitHub (like LAMMPS).  It is thus highly
-recommended to install it when doing LAMMPS development.
+GitHub has developed a `command-line tool <https://cli.github.com>`_
+to interact with the GitHub website via a command called ``gh``.
+This is extremely convenient when working with a Git repository hosted
+on GitHub (like LAMMPS).  It is thus highly recommended to install it
+when doing LAMMPS development.  To use ``gh`` you must be within a git
+checkout of a repository and you must obtain an authentication token
+to connect your checkout with a GitHub user.  This is done with the
+command: ``gh auth login`` where you then have to follow the prompts.
+Here are some examples:
 
-The capabilities of the ``gh`` command is continually expanding, so
-please see the documentation at https://cli.github.com/manual/
+.. list-table::
+   :header-rows: 1
+   :widths: 34 66
+
+   * - Command
+     - Description
+   * - ``gh pr list``
+     - List currently open pull requests
+   * - ``gh pr checks 404``
+     - Shows the status of all checks for pull request #404
+   * - ``gh pr view 404``
+     - Shows the description and recent comments for pull request #404
+   * - ``gh co 404``
+     - Check out the branch from pull request #404; set up for pushing changes
+   * - ``gh issue list``
+     - List currently open issues
+   * - ``gh issue view 430 --comments``
+     - Shows the description and all comments for issue #430
+
+The capabilities of the ``gh`` command are continually expanding, so
+for more details please see the documentation at https://cli.github.com/manual/
+or use ``gh --help`` or ``gh <command> --help`` for embedded help.

doc/src/Build_link.rst

@@ -37,7 +37,7 @@ executable code from the library is copied into the calling executable.
    .. tab:: CMake build
 
       This assumes that LAMMPS has been configured without setting a
-      ``LAMMPS_MACHINE`` name, installed with "make install", and the
+      ``LAMMPS_MACHINE`` name, installed with ``make install``, and the
       ``PKG_CONFIG_PATH`` environment variable has been updated to
       include the ``liblammps.pc`` file installed into the configured
       destination folder.  The commands to compile and link a coupled
@@ -45,8 +45,8 @@ executable code from the library is copied into the calling executable.
 
       .. code-block:: bash
 
-         mpicc -c -O $(pkgconf liblammps --cflags) caller.c
-         mpicxx -o caller caller.o -$(pkgconf liblammps --libs)
+         mpicc -c -O $(pkg-config --cflags liblammps) caller.c
+         mpicxx -o caller caller.o -$(pkg-config --libs liblammps)
 
    .. tab:: Traditional make
 
@@ -59,10 +59,10 @@ executable code from the library is copied into the calling executable.
          mpicc -c -O -I${HOME}/lammps/src caller.c
          mpicxx -o caller caller.o -L${HOME}/lammps/src -llammps_mpi
 
-      The *-I* argument is the path to the location of the ``library.h``
+      The ``-I`` argument is the path to the location of the ``library.h``
       header file containing the interface to the LAMMPS C-style library
-      interface.  The *-L* argument is the path to where the
-      ``liblammps_mpi.a`` file is located.  The *-llammps_mpi* argument
+      interface.  The ``-L`` argument is the path to where the
+      ``liblammps_mpi.a`` file is located.  The ``-llammps_mpi`` argument
       is shorthand for telling the compiler to link the file
       ``liblammps_mpi.a``.  If LAMMPS has been built as a shared
       library, then the linker will use ``liblammps_mpi.so`` instead.
@@ -142,7 +142,7 @@ When linking to LAMMPS built as a shared library, the situation becomes
 much simpler, as all dependent libraries and objects are either included
 in the shared library or registered as a dependent library in the shared
 library file.  Thus, those libraries need not be specified when linking
-the calling executable.  Only the *-I* flags are needed.  So the example
+the calling executable.  Only the ``-I`` flags are needed.  So the example
 case from above of the serial version static LAMMPS library with the
 POEMS package installed becomes:
 
@@ -155,8 +155,8 @@ POEMS package installed becomes:
 
       .. code-block:: bash
 
-         mpicc -c -O $(pkgconf liblammps --cflags) caller.c
-         mpicxx -o caller caller.o -$(pkgconf --libs)
+         mpicc -c -O $(pkg-config --cflags liblammps) caller.c
+         mpicxx -o caller caller.o -$(pkg-config --libs liblammps)
 
    .. tab:: Traditional make
 

doc/src/Build_make.rst

@@ -8,6 +8,10 @@ Building LAMMPS with traditional makefiles requires that you have a
 for customizing your LAMMPS build with a number of global compilation
 options and features.
 
+This build system is slowly being phased out and may not support all
+optional features and packages in LAMMPS.  It is recommended to switch
+to the :doc:`CMake based build system <Build_cmake>`.
+
 Requirements
 ^^^^^^^^^^^^
 
@@ -25,7 +29,7 @@ additional tools to be available and functioning.
     require adding flags like ``-std=c++11`` to enable the C++11 mode.
   * A Bourne shell compatible "Unix" shell program (frequently this is ``bash``)
   * A few shell utilities: ``ls``, ``mv``, ``ln``, ``rm``, ``grep``, ``sed``, ``tr``, ``cat``, ``touch``, ``diff``, ``dirname``
-  * Python (optional, required for ``make lib-<pkg>`` in the src
+  * Python (optional, required for ``make lib-<pkg>`` in the ``src``
     folder).  Python scripts are currently tested with python 2.7 and
     3.6 to 3.11. The procedure for :doc:`building the documentation
     <Build_manual>` *requires* Python 3.5 or later.

doc/src/Build_package.rst

@@ -49,6 +49,7 @@ packages:
    * :ref:`LEPTON <lepton>`
    * :ref:`MACHDYN <machdyn>`
    * :ref:`MDI <mdi>`
+   * :ref:`MISC <misc>`
    * :ref:`ML-HDNNP <ml-hdnnp>`
    * :ref:`ML-IAP <mliap>`
    * :ref:`ML-PACE <ml-pace>`
@@ -62,6 +63,7 @@ packages:
    * :ref:`POEMS <poems>`
    * :ref:`PYTHON <python>`
    * :ref:`QMMM <qmmm>`
+   * :ref:`RHEO <rheo>`
    * :ref:`SCAFACOS <scafacos>`
    * :ref:`VORONOI <voronoi>`
    * :ref:`VTK <vtk>`
@@ -99,10 +101,10 @@ versus make.
       .. code-block:: bash
 
          cd lammps/src
-         make ps                    # check which packages are currently installed
-         make yes-name              # install a package with name
-         make no-name               # uninstall a package with name
-         make mpi                   # build LAMMPS with whatever packages are now installed
+         make ps        # check which packages are currently installed
+         make yes-name  # install a package with name
+         make no-name   # uninstall a package with name
+         make mpi       # build LAMMPS with whatever packages are now installed
 
       Examples:
 
@@ -171,18 +173,41 @@ make a copy of one of them and modify it to suit your needs.
 
 .. code-block:: bash
 
-    cmake -C ../cmake/presets/basic.cmake    [OPTIONS] ../cmake  # enable just a few core packages
-    cmake -C ../cmake/presets/most.cmake     [OPTIONS] ../cmake  # enable most packages
-    cmake -C ../cmake/presets/download.cmake [OPTIONS] ../cmake  # enable packages which download sources or potential files
-    cmake -C ../cmake/presets/nolib.cmake    [OPTIONS] ../cmake  # disable packages that do require extra libraries or tools
-    cmake -C ../cmake/presets/clang.cmake    [OPTIONS] ../cmake  # change settings to use the Clang compilers by default
-    cmake -C ../cmake/presets/gcc.cmake      [OPTIONS] ../cmake  # change settings to use the GNU compilers by default
-    cmake -C ../cmake/presets/intel.cmake    [OPTIONS] ../cmake  # change settings to use the Intel compilers by default
-    cmake -C ../cmake/presets/pgi.cmake      [OPTIONS] ../cmake  # change settings to use the PGI compilers by default
-    cmake -C ../cmake/presets/all_on.cmake   [OPTIONS] ../cmake  # enable all packages
-    cmake -C ../cmake/presets/all_off.cmake  [OPTIONS] ../cmake  # disable all packages
-    mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake  #  compile with MinGW cross-compilers
-    cmake -C ../cmake/presets/macos-multiarch.cmake [OPTIONS] ../cmake # compile serial multi-arch binaries on macOS
+    # enable just a few core packages
+    cmake -C ../cmake/presets/basic.cmake    [OPTIONS] ../cmake
+
+    # enable most packages
+    cmake -C ../cmake/presets/most.cmake     [OPTIONS] ../cmake
+
+    # enable packages which download sources or potential files
+    cmake -C ../cmake/presets/download.cmake [OPTIONS] ../cmake
+
+    # disable packages that do require extra libraries or tools
+    cmake -C ../cmake/presets/nolib.cmake    [OPTIONS] ../cmake
+
+    # change settings to use the Clang compilers by default
+    cmake -C ../cmake/presets/clang.cmake    [OPTIONS] ../cmake
+
+    # change settings to use the GNU compilers by default
+    cmake -C ../cmake/presets/gcc.cmake      [OPTIONS] ../cmake
+
+    # change settings to use the Intel compilers by default
+    cmake -C ../cmake/presets/intel.cmake    [OPTIONS] ../cmake
+
+    # change settings to use the PGI compilers by default
+    cmake -C ../cmake/presets/pgi.cmake      [OPTIONS] ../cmake
+
+    # enable all packages
+    cmake -C ../cmake/presets/all_on.cmake   [OPTIONS] ../cmake
+
+    # disable all packages
+    cmake -C ../cmake/presets/all_off.cmake  [OPTIONS] ../cmake
+
+    #  compile with MinGW cross-compilers
+    mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake
+
+    # compile serial multi-arch binaries on macOS
+    cmake -C ../cmake/presets/macos-multiarch.cmake [OPTIONS] ../cmake
 
 Presets that have names starting with "windows" are specifically for
 compiling LAMMPS :doc:`natively on Windows <Build_windows>` and
@@ -208,7 +233,8 @@ Example
    # GPU package and configure it for using CUDA. You can run.
    mkdir build
    cd build
-   cmake -C ../cmake/presets/most.cmake -C ../cmake/presets/nolib.cmake -D PKG_GPU=on -D GPU_API=cuda ../cmake
+   cmake -C ../cmake/presets/most.cmake -C ../cmake/presets/nolib.cmake \
+         -D PKG_GPU=on -D GPU_API=cuda ../cmake
 
    # to add another package, say BODY to the previous configuration you can run:
    cmake -D PKG_BODY=on .

doc/src/Build_settings.rst

@@ -1,3 +1,7 @@
+.. raw:: latex
+
+    \clearpage
+
 Optional build settings
 =======================
 
@@ -8,7 +12,8 @@ explains how to do this for building both with CMake and make.
 * `FFT library`_ for use with the :doc:`kspace_style pppm <kspace_style>` command
 * `Size of LAMMPS integer types and size limits`_
 * `Read or write compressed files`_
-* `Output of JPG, PNG, and move files` via the :doc:`dump image <dump_image>` or :doc:`dump movie <dump_image>` commands
+* `Output of JPEG, PNG, and movie files`_ via the :doc:`dump image <dump_image>` or :doc:`dump movie <dump_image>` commands
+* `Support for downloading files`_
 * `Memory allocation alignment`_
 * `Workaround for long long integers`_
 * `Exception handling when using LAMMPS as a library`_ to capture errors
@@ -19,7 +24,7 @@ explains how to do this for building both with CMake and make.
 .. _cxx11:
 
 C++11 standard compliance
-------------------------------------------
+-------------------------
 
 A C++11 standard compatible compiler is a requirement for compiling LAMMPS.
 LAMMPS version 3 March 2020 is the last version compatible with the previous
@@ -31,12 +36,16 @@ flags to enable C++11 compliance.  Example for GNU c++ 4.8.x:
 
    CCFLAGS = -g -O3 -std=c++11
 
+Individual packages may require compliance with a later C++ standard
+like C++14 or C++17.  These requirements will be documented with the
+:doc:`individual packages <Packages_details>`.
+
 ----------
 
 .. _fft:
 
 FFT library
----------------------
+-----------
 
 When the KSPACE package is included in a LAMMPS build, the
 :doc:`kspace_style pppm <kspace_style>` command performs 3d FFTs which
@@ -58,8 +67,10 @@ libraries and better pipelining for packing and communication.
 
       .. code-block:: bash
 
-         -D FFT=value              # FFTW3 or MKL or KISS, default is FFTW3 if found, else KISS
-         -D FFT_KOKKOS=value       # FFTW3 or MKL or KISS or CUFFT or HIPFFT, default is KISS
+         -D FFT=value              # FFTW3 or MKL or NVPL or KISS,
+                                   # default is FFTW3 if found, else KISS
+         -D FFT_KOKKOS=value       # FFTW3 or MKL or NVPL or KISS or CUFFT
+                                   # or HIPFFT or MKL_GPU, default is KISS
          -D FFT_SINGLE=value       # yes or no (default), no = double precision
          -D FFT_PACK=value         # array (default) or pointer or memcpy
          -D FFT_USE_HEFFTE=value   # yes or no (default), yes links to heFFTe
@@ -67,11 +78,11 @@ libraries and better pipelining for packing and communication.
       .. note::
 
          When the Kokkos variant of a package is compiled and selected at run time,
-         the FFT library selected by the FFT_KOKKOS variable applies. Otherwise,
+         the FFT library selected by the ``FFT_KOKKOS`` variable applies. Otherwise,
          the FFT library selected by the FFT variable applies.
-         The same FFT settings apply to both. FFT_KOKKOS must be compatible with the
+         The same FFT settings apply to both. ``FFT_KOKKOS`` must be compatible with the
          Kokkos back end - for example, when using the CUDA back end of Kokkos,
-         you must use either CUFFT or KISS.
+         you must use either ``CUFFT`` or ``KISS``.
 
       Usually these settings are all that is needed.  If FFTW3 is
       selected, then CMake will try to detect, if threaded FFTW
@@ -89,8 +100,11 @@ libraries and better pipelining for packing and communication.
          -D MKL_INCLUDE_DIR=path     # ditto for Intel MKL library
          -D FFT_MKL_THREADS=on       # enable using threaded FFTs with MKL libraries
          -D MKL_LIBRARY=path         # path to MKL libraries
-         -D FFT_HEFFTE_BACKEND=value # FFTW or MKL or empty/undefined for the stock heFFTe back end
+         -D FFT_HEFFTE_BACKEND=value # FFTW or MKL or empty/undefined for the stock
+                                     # heFFTe back end
          -D Heffte_ROOT=path         # path to an existing heFFTe installation
+         -D nvpl_fft_INCLUDE_DIR=path # path to NVPL FFT include files
+         -D nvpl_fft_LIBRARY_DIR=path # path to NVPL FFT libraries
 
       .. note::
 
@@ -108,30 +122,58 @@ libraries and better pipelining for packing and communication.
 
       .. code-block:: make
 
-         FFT_INC = -DFFT_FFTW3         # -DFFT_FFTW3, -DFFT_FFTW (same as -DFFT_FFTW3), -DFFT_MKL, or -DFFT_KISS
-                                       # default is KISS if not specified
-         FFT_INC = -DFFT_KOKKOS_CUFFT  # -DFFT_KOKKOS_{FFTW,FFTW3,MKL,CUFFT,HIPFFT,KISS}
-                                       # default is KISS if not specified
-         FFT_INC = -DFFT_SINGLE        # do not specify for double precision
-         FFT_INC = -DFFT_FFTW_THREADS  # enable using threaded FFTW3 libraries
-         FFT_INC = -DFFT_MKL_THREADS   # enable using threaded FFTs with MKL libraries
-         FFT_INC = -DFFT_PACK_ARRAY    # or -DFFT_PACK_POINTER or -DFFT_PACK_MEMCPY
-                                       # default is FFT_PACK_ARRAY if not specified
+         FFT_INC = -DFFT_<NAME>        # where <NAME> is KISS (default), FFTW3,
+                                       # FFTW (same as FFTW3), NVPL, or MKL
+         FFT_INC = -DFFT_KOKKOS_<NAME> # where <NAME> is KISS (default), FFTW3,
+                                       # FFTW (same as FFTW3), NVPL, MKL, CUFFT,
+                                       # HIPFFT, or MKL_GPU
+         FFT_INC = -DFFT_SINGLE       # do not specify for double precision
+         FFT_INC = -DFFT_FFTW_THREADS # enable using threaded FFTW3 libraries
+         FFT_INC = -DFFT_MKL_THREADS  # enable using threaded FFTs with MKL libraries
+         FFT_INC = -DFFT_PACK_ARRAY   # or -DFFT_PACK_POINTER or -DFFT_PACK_MEMCPY
+                                      # default is FFT_PACK_ARRAY if not specified
 
       .. code-block:: make
 
-         FFT_INC =       -I/usr/local/include
-         FFT_PATH =      -L/usr/local/lib
-         FFT_LIB =       -lhipfft            # hipFFT either precision
-         FFT_LIB =       -lcufft             # cuFFT either precision
-         FFT_LIB =       -lfftw3             # FFTW3 double precision
-         FFT_LIB =       -lfftw3 -lfftw3_omp # FFTW3 double precision with threads (needs -DFFT_FFTW_THREADS)
-         FFT_LIB =       -lfftw3 -lfftw3f    # FFTW3 single precision
-         FFT_LIB =       -lmkl_intel_lp64 -lmkl_sequential -lmkl_core   # MKL with Intel compiler, serial interface
-         FFT_LIB =       -lmkl_gf_lp64 -lmkl_sequential -lmkl_core      # MKL with GNU compiler, serial interface
-         FFT_LIB =       -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core # MKL with Intel compiler, threaded interface
-         FFT_LIB =       -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core      # MKL with GNU compiler, threaded interface
-         FFT_LIB =       -lmkl_rt            # MKL with automatic runtime selection of interface libs
+         FFT_INC =  -I/usr/local/include
+         FFT_PATH = -L/usr/local/lib
+
+         # hipFFT either precision
+         FFT_LIB =  -lhipfft
+
+         # cuFFT either precision
+         FFT_LIB =  -lcufft
+
+         # MKL_GPU either precision
+         FFT_LIB = -lmkl_sycl_dft -lmkl_intel_ilp64 -lmkl_tbb_thread -lmkl_core -ltbb
+
+         # FFTW3 double precision
+         FFT_LIB =  -lfftw3
+
+         # FFTW3 double precision with threads (needs -DFFT_FFTW_THREADS)
+         FFT_LIB =  -lfftw3 -lfftw3_omp
+
+         # FFTW3 single precision
+         FFT_LIB =  -lfftw3 -lfftw3f
+
+         # serial MKL with Intel compiler
+         FFT_LIB =  -lmkl_intel_lp64 -lmkl_sequential -lmkl_core
+
+         # serial MKL with GNU compiler
+         FFT_LIB =  -lmkl_gf_lp64 -lmkl_sequential -lmkl_core
+
+         # threaded MKL with Intel compiler
+         FFT_LIB =  -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core
+
+         # threaded MKL with GNU compiler
+         FFT_LIB =  -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core
+
+         # MKL with automatic runtime selection of interface libs
+         FFT_LIB =  -lmkl_rt
+
+         # threaded NVPL FFT
+         FFT_LIB =  -lnvpl_fftw
+
 
       As with CMake, you do not need to set paths in ``FFT_INC`` or
       ``FFT_PATH``, if the compiler can find the FFT header and library
@@ -147,11 +189,11 @@ libraries and better pipelining for packing and communication.
          FFT_PATH =
          FFT_LIB = $(heffte_link) $(heffte_libs)
 
-      The heFFTe install path will contain `HeffteMakefile.in`.
-      which will define the `heffte_` include variables needed to link to heFFTe from
+      The heFFTe install path will contain ``HeffteMakefile.in``.
+      which will define the ``heffte_`` include variables needed to link to heFFTe from
       an external project using traditional make.
-      The `-DFFT_HEFFTE` is required to switch to using heFFTe, while the optional `-DFFT_HEFFTE_FFTW`
-      selects the desired heFFTe back end, e.g., `-DFFT_HEFFTE_FFTW` or `-DFFT_HEFFTE_MKL`,
+      The ``-DFFT_HEFFTE`` is required to switch to using heFFTe, while the optional ``-DFFT_HEFFTE_FFTW``
+      selects the desired heFFTe back end, e.g., ``-DFFT_HEFFTE_FFTW`` or ``-DFFT_HEFFTE_MKL``,
       omitting the variable will default to the `stock` back end.
       The heFFTe `stock` back end is intended to be used for testing and debugging,
       but is not performance optimized for large scale production runs.
@@ -179,17 +221,22 @@ it from `www.fftw.org <https://www.fftw.org>`_.  LAMMPS requires version
 Building FFTW for your box should be as simple as ``./configure; make;
 make install``.  The install command typically requires root privileges
 (e.g. invoke it via sudo), unless you specify a local directory with
-the "--prefix" option of configure.  Type ``./configure --help`` to see
+the ``--prefix`` option of configure.  Type ``./configure --help`` to see
 various options.
 
 The Intel MKL math library is part of the Intel compiler suite.  It
 can be used with the Intel or GNU compiler (see the ``FFT_LIB`` setting
 above).
 
+The NVIDIA Performance Libraries (NVPL) FFT library is optimized for NVIDIA
+Grace Armv9.0 architecture. You can download it from https://docs.nvidia.com/nvpl/
+
 The cuFFT and hipFFT FFT libraries are packaged with NVIDIA's CUDA and
 AMD's HIP installations, respectively. These FFT libraries require the
 Kokkos acceleration package to be enabled and the Kokkos back end to be
-GPU-resident (i.e., HIP or CUDA).
+GPU-resident (i.e., HIP or CUDA). Similarly, GPU offload of FFTs on
+Intel GPUs with oneMKL currently requires the Kokkos acceleration
+package to be enabled with the SYCL back end.
 
 Performing 3d FFTs in parallel can be time-consuming due to data access
 and required communication.  This cost can be reduced by performing
@@ -215,7 +262,7 @@ produce the additional libraries ``libfftw3f.a`` and/or ``libfftw3f.so``\ .
 
 Performing 3d FFTs requires communication to transpose the 3d FFT
 grid.  The data packing/unpacking for this can be done in one of 3
-modes (ARRAY, POINTER, MEMCPY) as set by the FFT_PACK syntax above.
+modes (ARRAY, POINTER, MEMCPY) as set by the ``FFT_PACK`` syntax above.
 Depending on the machine, the size of the FFT grid, the number of
 processors used, one option may be slightly faster.  The default is
 ARRAY mode.
@@ -232,6 +279,10 @@ and those variables will be passed into the heFFTe build.
 
 ----------
 
+.. raw:: latex
+
+    \clearpage
+
 .. _size:
 
 Size of LAMMPS integer types and size limits
@@ -272,7 +323,7 @@ LAMMPS system size restrictions
 
 .. list-table::
    :header-rows: 1
-   :widths: auto
+   :widths: 18 27 28 27
    :align: center
 
    * -
@@ -341,8 +392,8 @@ in whichever ``lib/gpu/Makefile`` is used must be the same as above.
 
 .. _graphics:
 
-Output of JPG, PNG, and movie files
---------------------------------------------------
+Output of JPEG, PNG, and movie files
+------------------------------------
 
 The :doc:`dump image <dump_image>` command has options to output JPEG or
 PNG image files.  Likewise, the :doc:`dump movie <dump_image>` command
@@ -355,12 +406,13 @@ requires the following settings:
 
       .. code-block:: bash
 
-         -D WITH_JPEG=value      # yes or no
-                                 # default = yes if CMake finds JPEG files, else no
-         -D WITH_PNG=value       # yes or no
-                                 # default = yes if CMake finds PNG and ZLIB files, else no
-         -D WITH_FFMPEG=value    # yes or no
-                                 # default = yes if CMake can find ffmpeg, else no
+         -D WITH_JPEG=value    # yes or no
+                               # default = yes if CMake finds JPEG development files, else no
+         -D WITH_PNG=value     # yes or no
+                               # default = yes if CMake finds PNG and ZLIB development files,
+                               # else no
+         -D WITH_FFMPEG=value  # yes or no
+                               # default = yes if CMake can find ffmpeg, else no
 
       Usually these settings are all that is needed.  If CMake cannot
       find the graphics header, library, executable files, you can set
@@ -382,8 +434,10 @@ requires the following settings:
 
          LMP_INC = -DLAMMPS_JPEG -DLAMMPS_PNG -DLAMMPS_FFMPEG  <other LMP_INC settings>
 
-         JPG_INC = -I/usr/local/include   # path to jpeglib.h, png.h, zlib.h header files if make cannot find them
-         JPG_PATH = -L/usr/lib            # paths to libjpeg.a, libpng.a, libz.a (.so) files if make cannot find them
+         JPG_INC = -I/usr/local/include   # path to jpeglib.h, png.h, zlib.h headers
+                                          # if make cannot find them
+         JPG_PATH = -L/usr/lib            # paths to libjpeg.a, libpng.a, libz.a (.so)
+                                          # files if make cannot find them
          JPG_LIB = -ljpeg -lpng -lz       # library names
 
       As with CMake, you do not need to set ``JPG_INC`` or ``JPG_PATH``,
@@ -414,8 +468,8 @@ Read or write compressed files
 If this option is enabled, large files can be read or written with
 compression by ``gzip`` or similar tools by several LAMMPS commands,
 including :doc:`read_data <read_data>`, :doc:`rerun <rerun>`, and
-:doc:`dump <dump>`.  Supported compression tools are currently
-``gzip``, ``bzip2``, ``zstd``, and ``lzma``.
+:doc:`dump <dump>`.  Supported compression tools and algorithms are currently
+``gzip``, ``bzip2``, ``zstd``, ``xz``, ``lz4``, and ``lzma`` (via xz).
 
 .. tabs::
 
@@ -423,8 +477,8 @@ including :doc:`read_data <read_data>`, :doc:`rerun <rerun>`, and
 
       .. code-block:: bash
 
-         -D WITH_GZIP=value       # yes or no
-                                  # default is yes if CMake can find the gzip program, else no
+         -D WITH_GZIP=value  # yes or no
+                             # default is yes if CMake can find the gzip program
 
    .. tab:: Traditional make
 
@@ -446,18 +500,64 @@ during a run.
    available using a compression library instead, which is what the
    :ref:`COMPRESS package <PKG-COMPRESS>` enables.
 
+--------------------------------------------------
+
+.. _libcurl:
+
+Support for downloading files
+-----------------------------
+
+.. versionadded:: 29Aug2024
+
+The :doc:`geturl command <geturl>` command uses the `the libcurl library
+<https://curl.se/libcurl/>`_ to download files.  This requires that
+LAMMPS is compiled accordingly which needs the following settings:
+
+.. tabs::
+
+   .. tab:: CMake build
+
+      .. code-block:: bash
+
+         -D WITH_CURL=value      # yes or no
+                                 # default = yes if CMake finds CURL development files, else no
+
+      Usually these settings are all that is needed.  If CMake cannot
+      find the graphics header, library, executable files, you can set
+      these variables:
+
+      .. code-block:: bash
+
+         -D CURL_INCLUDE_DIR=path    # path to folder which contains curl.h header file
+         -D CURL_LIBRARY=path        # path to libcurls.a (.so) file
+
+   .. tab:: Traditional make
+
+      .. code-block:: make
+
+         LMP_INC = -DLAMMPS_CURL  <other LMP_INC settings>
+
+         CURL_INC = -I/usr/local/include   # path to curl folder with curl.h
+         CURL_PATH = -L/usr/lib            # paths to libcurl.a(.so) if make cannot find it
+         CURL_LIB = -lcurl                 # library names
+
+      As with CMake, you do not need to set ``CURL_INC`` or ``CURL_PATH``,
+      if make can find the libcurl header and library files in their
+      default system locations.  You must specify ``CURL_LIB`` with a
+      paths or linker flags to link to libcurl.
+
 ----------
 
 .. _align:
 
 Memory allocation alignment
----------------------------------------
+---------------------------
 
-This setting enables the use of the "posix_memalign()" call instead of
-"malloc()" when LAMMPS allocates large chunks of memory.  Vector
+This setting enables the use of the ``posix_memalign()`` call instead of
+``malloc()`` when LAMMPS allocates large chunks of memory.  Vector
 instructions on CPUs may become more efficient, if dynamically allocated
 memory is aligned on larger-than-default byte boundaries.  On most
-current operating systems, the "malloc()" implementation returns
+current operating systems, the ``malloc()`` implementation returns
 pointers that are aligned to 16-byte boundaries. Using SSE vector
 instructions efficiently, however, requires memory blocks being aligned
 on 64-byte boundaries.
@@ -471,9 +571,9 @@ on 64-byte boundaries.
          -D LAMMPS_MEMALIGN=value            # 0, 8, 16, 32, 64 (default)
 
       Use a ``LAMMPS_MEMALIGN`` value of 0 to disable using
-      "posix_memalign()" and revert to using the "malloc()" C-library
+      ``posix_memalign()`` and revert to using the ``malloc()`` C-library
       function instead.  When compiling LAMMPS for Windows systems,
-      "malloc()" will always be used and this setting is ignored.
+      ``malloc()`` will always be used and this setting is ignored.
 
    .. tab:: Traditional make
 
@@ -482,7 +582,7 @@ on 64-byte boundaries.
          LMP_INC = -DLAMMPS_MEMALIGN=value   # 8, 16, 32, 64
 
       Do not set ``-DLAMMPS_MEMALIGN``, if you want to have memory
-      allocated with the "malloc()" function call
+      allocated with the ``malloc()`` function call
       instead. ``-DLAMMPS_MEMALIGN`` **cannot** be used on Windows, as
       Windows different function calls with different semantics for
       allocating aligned memory, that are not compatible with how LAMMPS

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_all.rst

@@ -1,26 +1,30 @@
-.. table_from_list::
-   :columns: 3
+.. only:: html
 
-   * :doc:`General commands <Commands_all>`
-   * :doc:`Fix styles <Commands_fix>`
-   * :doc:`Compute styles <Commands_compute>`
-   * :doc:`Pair styles <Commands_pair>`
-   * :ref:`Bond styles <bond>`
-   * :ref:`Angle styles <angle>`
-   * :ref:`Dihedral styles <dihedral>`
-   * :ref:`Improper styles <improper>`
-   * :doc:`KSpace styles <Commands_kspace>`
-   * :doc:`Dump styles <Commands_dump>`
+   .. table_from_list::
+      :columns: 5
+
+      * :doc:`General commands <Commands_all>`
+      * :doc:`Fix styles <Commands_fix>`
+      * :doc:`Compute styles <Commands_compute>`
+      * :doc:`Pair styles <Commands_pair>`
+      * :ref:`Bond styles <bond>`
+      * :ref:`Angle styles <angle>`
+      * :ref:`Dihedral styles <dihedral>`
+      * :ref:`Improper styles <improper>`
+      * :doc:`KSpace styles <Commands_kspace>`
+      * :doc:`Dump styles <Commands_dump>`
+
+.. raw:: latex
+
+   \clearpage
 
 General commands
 ================
 
-An alphabetic list of general LAMMPS commands.  Note that style
-commands with many variants, can be more easily accessed via the small
-table above.
+An alphabetic list of general LAMMPS commands.
 
 .. table_from_list::
-   :columns: 5
+   :columns: 6
 
    * :doc:`angle_coeff <angle_coeff>`
    * :doc:`angle_style <angle_style>`
@@ -54,6 +58,7 @@ table above.
    * :doc:`echo <echo>`
    * :doc:`fix <fix>`
    * :doc:`fix_modify <fix_modify>`
+   * :doc:`geturl <geturl>`
    * :doc:`group <group>`
    * :doc:`if <if>`
    * :doc:`improper_coeff <improper_coeff>`
@@ -121,7 +126,7 @@ commands have accelerated versions.  This is indicated by an
 additional letter in parenthesis: k = KOKKOS.
 
 .. table_from_list::
-   :columns: 5
+   :columns: 6
 
    * :doc:`dynamical_matrix (k) <dynamical_matrix>`
    * :doc:`group2ndx <group2ndx>`

doc/src/Commands_bond.rst

@@ -1,21 +1,7 @@
-.. table_from_list::
-   :columns: 3
-
-   * :doc:`General commands <Commands_all>`
-   * :doc:`Fix styles <Commands_fix>`
-   * :doc:`Compute styles <Commands_compute>`
-   * :doc:`Pair styles <Commands_pair>`
-   * :ref:`Bond styles <bond>`
-   * :ref:`Angle styles <angle>`
-   * :ref:`Dihedral styles <dihedral>`
-   * :ref:`Improper styles <improper>`
-   * :doc:`KSpace styles <Commands_kspace>`
-   * :doc:`Dump styles <Commands_dump>`
-
 .. _bond:
 
-Bond_style potentials
-=====================
+Bond styles
+===========
 
 All LAMMPS :doc:`bond_style <bond_style>` commands.  Some styles have
 accelerated versions.  This is indicated by additional letters in
@@ -23,7 +9,7 @@ parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t =
 OPT.
 
 .. table_from_list::
-   :columns: 4
+   :columns: 5
 
    * :doc:`none <bond_none>`
    * :doc:`zero <bond_zero>`
@@ -33,6 +19,8 @@ OPT.
    *
    *
    *
+   *
+   *
    * :doc:`bpm/rotational <bond_bpm_rotational>`
    * :doc:`bpm/spring <bond_bpm_spring>`
    * :doc:`class2 (ko) <bond_class2>`
@@ -54,13 +42,14 @@ OPT.
    * :doc:`oxdna2/fene <bond_oxdna>`
    * :doc:`oxrna2/fene <bond_oxdna>`
    * :doc:`quartic (o) <bond_quartic>`
+   * :doc:`rheo/shell <bond_rheo_shell>`
    * :doc:`special <bond_special>`
    * :doc:`table (o) <bond_table>`
 
 .. _angle:
 
-Angle_style potentials
-======================
+Angle styles
+============
 
 All LAMMPS :doc:`angle_style <angle_style>` commands.  Some styles have
 accelerated versions.  This is indicated by additional letters in
@@ -68,11 +57,13 @@ parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t =
 OPT.
 
 .. table_from_list::
-   :columns: 4
+   :columns: 5
 
    * :doc:`none <angle_none>`
    * :doc:`zero <angle_zero>`
-   * :doc:`hybrid <angle_hybrid>`
+   * :doc:`hybrid (k) <angle_hybrid>`
+   *
+   *
    *
    *
    *
@@ -99,14 +90,15 @@ OPT.
    * :doc:`lepton (o) <angle_lepton>`
    * :doc:`mesocnt <angle_mesocnt>`
    * :doc:`mm3 <angle_mm3>`
+   * :doc:`mwlc <angle_mwlc>`
    * :doc:`quartic (o) <angle_quartic>`
-   * :doc:`spica (o) <angle_spica>`
+   * :doc:`spica (ko) <angle_spica>`
    * :doc:`table (o) <angle_table>`
 
 .. _dihedral:
 
-Dihedral_style potentials
-=========================
+Dihedral styles
+===============
 
 All LAMMPS :doc:`dihedral_style <dihedral_style>` commands.  Some styles
 have accelerated versions.  This is indicated by additional letters in
@@ -114,11 +106,13 @@ parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t =
 OPT.
 
 .. table_from_list::
-   :columns: 4
+   :columns: 5
 
    * :doc:`none <dihedral_none>`
    * :doc:`zero <dihedral_zero>`
-   * :doc:`hybrid <dihedral_hybrid>`
+   * :doc:`hybrid (k) <dihedral_hybrid>`
+   *
+   *
    *
    *
    *
@@ -143,8 +137,8 @@ OPT.
 
 .. _improper:
 
-Improper_style potentials
-=========================
+Improper styles
+===============
 
 All LAMMPS :doc:`improper_style <improper_style>` commands.  Some styles
 have accelerated versions.  This is indicated by additional letters in
@@ -152,11 +146,13 @@ parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t =
 OPT.
 
 .. table_from_list::
-   :columns: 4
+   :columns: 5
 
    * :doc:`none <improper_none>`
    * :doc:`zero <improper_zero>`
-   * :doc:`hybrid <improper_hybrid>`
+   * :doc:`hybrid (k) <improper_hybrid>`
+   *
+   *
    *
    *
    *

doc/src/Commands_category.rst

@@ -1,3 +1,7 @@
+.. raw:: latex
+
+   \clearpage
+
 Commands by category
 ====================
 
@@ -6,8 +10,8 @@ This page lists most of the LAMMPS commands, grouped by category.  The
 alphabetically.  Style options for entries like fix, compute, pair etc.
 have their own pages where they are listed alphabetically.
 
-Initialization:
-------------------------------
+Initialization
+--------------
 
 .. table_from_list::
    :columns: 5
@@ -18,8 +22,8 @@ Initialization:
    * :doc:`suffix <suffix>`
    * :doc:`units <units>`
 
-Setup simulation box:
-------------------------------
+Setup simulation box
+--------------------
 
 .. table_from_list::
    :columns: 4
@@ -31,8 +35,8 @@ Setup simulation box:
    * :doc:`lattice <lattice>`
    * :doc:`region <region>`
 
-Setup atoms:
-------------------------------
+Setup atoms
+-----------
 
 .. table_from_list::
    :columns: 4
@@ -55,8 +59,8 @@ Setup atoms:
    * :doc:`set <set>`
    * :doc:`velocity <velocity>`
 
-Force fields:
-------------------------------
+Force fields
+------------
 
 .. table_from_list::
    :columns: 4
@@ -79,8 +83,8 @@ Force fields:
    * :doc:`pair_write <pair_write>`
    * :doc:`special_bonds <special_bonds>`
 
-Settings:
-------------------------------
+Settings
+--------
 
 .. table_from_list::
    :columns: 4
@@ -98,8 +102,8 @@ Settings:
    * :doc:`timer <timer>`
    * :doc:`timestep <timestep>`
 
-Operations within timestepping (fixes) and diagnostics (computes):
-------------------------------------------------------------------------------------------
+Operations within timestepping (fixes) and diagnostics (computes)
+-----------------------------------------------------------------
 
 .. table_from_list::
    :columns: 4
@@ -111,8 +115,8 @@ Operations within timestepping (fixes) and diagnostics (computes):
    * :doc:`uncompute <uncompute>`
    * :doc:`unfix <unfix>`
 
-Output:
-------------------------------
+Output
+------
 
 .. table_from_list::
    :columns: 4
@@ -131,8 +135,8 @@ Output:
    * :doc:`write_dump <write_dump>`
    * :doc:`write_restart <write_restart>`
 
-Actions:
-------------------------------
+Actions
+-------
 
 .. table_from_list::
    :columns: 6
@@ -146,8 +150,8 @@ Actions:
    * :doc:`tad <tad>`
    * :doc:`temper <temper>`
 
-Input script control:
-------------------------------
+Input script control
+--------------------
 
 .. table_from_list::
    :columns: 7

doc/src/Commands_compute.rst

@@ -1,19 +1,5 @@
-.. table_from_list::
-   :columns: 3
-
-   * :doc:`General commands <Commands_all>`
-   * :doc:`Fix styles <Commands_fix>`
-   * :doc:`Compute styles <Commands_compute>`
-   * :doc:`Pair styles <Commands_pair>`
-   * :ref:`Bond styles <bond>`
-   * :ref:`Angle styles <angle>`
-   * :ref:`Dihedral styles <dihedral>`
-   * :ref:`Improper styles <improper>`
-   * :doc:`KSpace styles <Commands_kspace>`
-   * :doc:`Dump styles <Commands_dump>`
-
-Compute commands
-================
+Compute styles
+==============
 
 An alphabetic list of all LAMMPS :doc:`compute <compute>` commands.
 Some styles have accelerated versions.  This is indicated by
@@ -21,7 +7,7 @@ additional letters in parenthesis: g = GPU, i = INTEL, k =
 KOKKOS, o = OPENMP, t = OPT.
 
 .. table_from_list::
-   :columns: 5
+   :columns: 4
 
    * :doc:`ackland/atom <compute_ackland_atom>`
    * :doc:`adf <compute_adf>`
@@ -72,6 +58,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`fep/ta <compute_fep_ta>`
    * :doc:`force/tally <compute_tally>`
    * :doc:`fragment/atom <compute_cluster_atom>`
+   * :doc:`gaussian/grid/local (k) <compute_gaussian_grid_local>`
    * :doc:`global/atom <compute_global_atom>`
    * :doc:`group/group <compute_group_group>`
    * :doc:`gyration <compute_gyration>`
@@ -126,6 +113,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`reduce <compute_reduce>`
    * :doc:`reduce/chunk <compute_reduce_chunk>`
    * :doc:`reduce/region <compute_reduce>`
+   * :doc:`rheo/property/atom <compute_rheo_property_atom>`
    * :doc:`rigid/local <compute_rigid_local>`
    * :doc:`saed <compute_saed>`
    * :doc:`slcsa/atom <compute_slcsa_atom>`
@@ -153,8 +141,8 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`smd/vol <compute_smd_vol>`
    * :doc:`snap <compute_sna_atom>`
    * :doc:`sna/atom <compute_sna_atom>`
-   * :doc:`sna/grid <compute_sna_atom>`
-   * :doc:`sna/grid/local <compute_sna_atom>`
+   * :doc:`sna/grid (k) <compute_sna_atom>`
+   * :doc:`sna/grid/local (k) <compute_sna_atom>`
    * :doc:`snad/atom <compute_sna_atom>`
    * :doc:`snav/atom <compute_sna_atom>`
    * :doc:`sph/e/atom <compute_sph_e_atom>`

doc/src/Commands_dump.rst

@@ -1,24 +1,10 @@
-.. table_from_list::
-   :columns: 3
-
-   * :doc:`General commands <Commands_all>`
-   * :doc:`Fix styles <Commands_fix>`
-   * :doc:`Compute styles <Commands_compute>`
-   * :doc:`Pair styles <Commands_pair>`
-   * :ref:`Bond styles <bond>`
-   * :ref:`Angle styles <angle>`
-   * :ref:`Dihedral styles <dihedral>`
-   * :ref:`Improper styles <improper>`
-   * :doc:`KSpace styles <Commands_kspace>`
-   * :doc:`Dump styles <Commands_dump>`
-
-Dump commands
-=============
+Dump styles
+===========
 
 An alphabetic list of all LAMMPS :doc:`dump <dump>` commands.
 
 .. table_from_list::
-   :columns: 5
+   :columns: 6
 
    * :doc:`atom <dump>`
    * :doc:`atom/adios <dump_adios>`

doc/src/Commands_fix.rst

@@ -1,19 +1,5 @@
-.. table_from_list::
-   :columns: 3
-
-   * :doc:`General commands <Commands_all>`
-   * :doc:`Fix styles <Commands_fix>`
-   * :doc:`Compute styles <Commands_compute>`
-   * :doc:`Pair styles <Commands_pair>`
-   * :ref:`Bond styles <bond>`
-   * :ref:`Angle styles <angle>`
-   * :ref:`Dihedral styles <dihedral>`
-   * :ref:`Improper styles <improper>`
-   * :doc:`KSpace styles <Commands_kspace>`
-   * :doc:`Dump styles <Commands_dump>`
-
-Fix commands
-============
+Fix styles
+==========
 
 An alphabetic list of all LAMMPS :doc:`fix <fix>` commands.  Some styles
 have accelerated versions.  This is indicated by additional letters in
@@ -21,13 +7,14 @@ parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t =
 OPT.
 
 .. table_from_list::
-   :columns: 5
+   :columns: 4
 
    * :doc:`accelerate/cos <fix_accelerate_cos>`
    * :doc:`acks2/reaxff (k) <fix_acks2_reaxff>`
    * :doc:`adapt <fix_adapt>`
    * :doc:`adapt/fep <fix_adapt_fep>`
    * :doc:`addforce <fix_addforce>`
+   * :doc:`add/heat <fix_add_heat>`
    * :doc:`addtorque <fix_addtorque>`
    * :doc:`alchemy <fix_alchemy>`
    * :doc:`amoeba/bitorsion <fix_amoeba_bitorsion>`
@@ -56,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>`
@@ -71,6 +58,7 @@ OPT.
    * :doc:`dt/reset (k) <fix_dt_reset>`
    * :doc:`edpd/source <fix_dpd_source>`
    * :doc:`efield (k) <fix_efield>`
+   * :doc:`efield/lepton <fix_efield_lepton>`
    * :doc:`efield/tip4p <fix_efield>`
    * :doc:`ehex <fix_ehex>`
    * :doc:`electrode/conp (i) <fix_electrode>`
@@ -147,7 +135,7 @@ OPT.
    * :doc:`nve/dot <fix_nve_dot>`
    * :doc:`nve/dotc/langevin <fix_nve_dotc_langevin>`
    * :doc:`nve/eff <fix_nve_eff>`
-   * :doc:`nve/limit <fix_nve_limit>`
+   * :doc:`nve/limit (k) <fix_nve_limit>`
    * :doc:`nve/line <fix_nve_line>`
    * :doc:`nve/manifold/rattle <fix_nve_manifold_rattle>`
    * :doc:`nve/noforce <fix_nve_noforce>`
@@ -191,6 +179,7 @@ OPT.
    * :doc:`python/move <fix_python_move>`
    * :doc:`qbmsst <fix_qbmsst>`
    * :doc:`qeq/comb (o) <fix_qeq_comb>`
+   * :doc:`qeq/ctip <fix_qeq>`
    * :doc:`qeq/dynamic <fix_qeq>`
    * :doc:`qeq/fire <fix_qeq>`
    * :doc:`qeq/point <fix_qeq>`
@@ -199,11 +188,17 @@ 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>`
+   * :doc:`rheo/pressure <fix_rheo_pressure>`
+   * :doc:`rheo/thermal <fix_rheo_thermal>`
+   * :doc:`rheo/viscosity <fix_rheo_viscosity>`
    * :doc:`rhok <fix_rhok>`
    * :doc:`rigid (o) <fix_rigid>`
    * :doc:`rigid/meso <fix_rigid_meso>`
@@ -275,7 +270,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

@@ -10,14 +10,14 @@ for any commands that may be processed later. Commands may set an
 internal variable, read in a file, or run a simulation.  These actions
 can be grouped into three categories:
 
-a) commands that change a global setting (examples: timestep, newton,
-   echo, log, thermo, restart),
+a) commands that change a global setting (examples: :doc:`timestep <timestep>`, :doc:`newton <newton>`,
+   :doc:`echo <echo>`, :doc:`log <log>`, :doc:`thermo <thermo>`, :doc:`restart <restart>`),
 b) commands that add, modify, remove, or replace "styles" that are
-   executed during a "run" (examples: pair_style, fix, compute, dump,
-   thermo_style, pair_modify), and
+   executed during a "run" (examples: :doc:`pair_style <pair_style>`, :doc:`fix <fix>`, :doc:`compute <compute>`, :doc:`dump <dump>`,
+   :doc:`thermo_style <thermo_style>`, :doc:`pair_modify <pair_modify>`), and
 c) commands that execute a "run" or perform some other computation or
-   operation (examples: print, run, minimize, temper, write_dump, rerun,
-   read_data, read_restart)
+   operation (examples: :doc:`print <print>`, :doc:`run <run>`, :doc:`minimize <minimize>`, :doc:`temper <temper>`, :doc:`write_dump <write_dump>`, :doc:`rerun <rerun>`,
+   :doc:`read_data <read_data>`, :doc:`read_restart <read_restart>`)
 
 Commands in category a) have default settings, which means you only
 need to use the command if you wish to change the defaults.
@@ -61,7 +61,7 @@ between commands in the c) category. The following rules apply:
     <read_data>` command initializes the system by setting up the
     simulation box and assigning atoms to processors.  If default values
     are not desired, the :doc:`processors <processors>` and
-    :doc:`boundary <boundary>` commands need to be used before read_data
+    :doc:`boundary <boundary>` commands need to be used before ``read_data``
     to tell LAMMPS how to map processors to the simulation box.
 
 Many input script errors are detected by LAMMPS and an ERROR or
@@ -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
-to have LAMMPS skip the execution of any "run", "minimize", or similar
+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_kspace.rst

@@ -1,19 +1,5 @@
-.. table_from_list::
-   :columns: 3
-
-   * :doc:`General commands <Commands_all>`
-   * :doc:`Fix styles <Commands_fix>`
-   * :doc:`Compute styles <Commands_compute>`
-   * :doc:`Pair styles <Commands_pair>`
-   * :ref:`Bond styles <bond>`
-   * :ref:`Angle styles <angle>`
-   * :ref:`Dihedral styles <dihedral>`
-   * :ref:`Improper styles <improper>`
-   * :doc:`KSpace styles <Commands_kspace>`
-   * :doc:`Dump styles <Commands_dump>`
-
-KSpace solvers
-==============
+KSpace styles
+=============
 
 All LAMMPS :doc:`kspace_style <kspace_style>` solvers.  Some styles have
 accelerated versions.  This is indicated by additional letters in
@@ -21,7 +7,7 @@ parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t =
 OPT.
 
 .. table_from_list::
-   :columns: 4
+   :columns: 5
 
    * :doc:`ewald (o) <kspace_style>`
    * :doc:`ewald/disp <kspace_style>`

doc/src/Commands_pair.rst

@@ -1,19 +1,5 @@
-.. table_from_list::
-   :columns: 3
-
-   * :doc:`General commands <Commands_all>`
-   * :doc:`Fix styles <Commands_fix>`
-   * :doc:`Compute styles <Commands_compute>`
-   * :doc:`Pair styles <Commands_pair>`
-   * :ref:`Bond styles <bond>`
-   * :ref:`Angle styles <angle>`
-   * :ref:`Dihedral styles <dihedral>`
-   * :ref:`Improper styles <improper>`
-   * :doc:`KSpace styles <Commands_kspace>`
-   * :doc:`Dump styles <Commands_dump>`
-
-Pair_style potentials
-======================
+Pair styles
+===========
 
 All LAMMPS :doc:`pair_style <pair_style>` commands.  Some styles have
 accelerated versions.  This is indicated by additional letters in
@@ -21,7 +7,7 @@ parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t =
 OPT.
 
 .. table_from_list::
-   :columns: 4
+   :columns: 3
 
    * :doc:`none <pair_none>`
    * :doc:`zero <pair_zero>`
@@ -58,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>`
@@ -73,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>`
@@ -93,6 +80,7 @@ OPT.
    * :doc:`coul/tt <pair_coul_tt>`
    * :doc:`coul/wolf (ko) <pair_coul>`
    * :doc:`coul/wolf/cs <pair_cs>`
+   * :doc:`dispersion/d3 <pair_dispersion_d3>`
    * :doc:`dpd (giko) <pair_dpd>`
    * :doc:`dpd/coul/slater/long (g) <pair_dpd_coul_slater_long>`
    * :doc:`dpd/ext (ko) <pair_dpd_ext>`
@@ -127,7 +115,9 @@ OPT.
    * :doc:`gw/zbl <pair_gw>`
    * :doc:`harmonic/cut (o) <pair_harmonic_cut>`
    * :doc:`hbond/dreiding/lj (o) <pair_hbond_dreiding>`
+   * :doc:`hbond/dreiding/lj/angleoffset (o) <pair_hbond_dreiding>`
    * :doc:`hbond/dreiding/morse (o) <pair_hbond_dreiding>`
+   * :doc:`hbond/dreiding/morse/angleoffset (o) <pair_hbond_dreiding>`
    * :doc:`hdnnp <pair_hdnnp>`
    * :doc:`hippo (g) <pair_amoeba>`
    * :doc:`ilp/graphene/hbn (t) <pair_ilp_graphene_hbn>`
@@ -191,7 +181,7 @@ OPT.
    * :doc:`lj/mdf <pair_mdf>`
    * :doc:`lj/relres (o) <pair_lj_relres>`
    * :doc:`lj/spica (gko) <pair_spica>`
-   * :doc:`lj/spica/coul/long (go) <pair_spica>`
+   * :doc:`lj/spica/coul/long (gko) <pair_spica>`
    * :doc:`lj/spica/coul/msm (o) <pair_spica>`
    * :doc:`lj/sf/dipole/sf (go) <pair_dipole>`
    * :doc:`lj/smooth (go) <pair_lj_smooth>`
@@ -260,6 +250,8 @@ OPT.
    * :doc:`rebo (io) <pair_airebo>`
    * :doc:`rebomos (o) <pair_rebomos>`
    * :doc:`resquared (go) <pair_resquared>`
+   * :doc:`rheo <pair_rheo>`
+   * :doc:`rheo/solid <pair_rheo_solid>`
    * :doc:`saip/metal (t) <pair_saip_metal>`
    * :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>`
    * :doc:`smatb <pair_smatb>`

doc/src/Commands_parse.rst

@@ -42,8 +42,8 @@ LAMMPS:
    If the $ is followed by text in curly brackets '{}', then the
    variable name is the text inside the curly brackets.  If no curly
    brackets follow the $, then the variable name is the single character
-   immediately following the $.  Thus ${myTemp} and $x refer to variables
-   named "myTemp" and "x", while "$xx" will be interpreted as a variable
+   immediately following the $.  Thus ``${myTemp}`` and ``$x`` refer to variables
+   named "myTemp" and "x", while ``$xx`` will be interpreted as a variable
    named "x" followed by an "x" character.
 
    How the variable is converted to a text string depends on what style
@@ -79,10 +79,10 @@ LAMMPS:
 
    Additionally, the entire "immediate" variable expression may be
    followed by a colon, followed by a C-style format string,
-   e.g. ":%f" or ":%.10g".  The format string must be appropriate for
+   e.g. ``:%f`` or ``:%.10g``.  The format string must be appropriate for
    a double-precision floating-point value.  The format string is used
    to output the result of the variable expression evaluation.  If a
-   format string is not specified, a high-precision "%.20g" is used as
+   format string is not specified, a high-precision ``%.20g`` is used as
    the default format.
 
    This can be useful for formatting print output to a desired precision:
@@ -101,8 +101,8 @@ LAMMPS:
       variable        b2 equal 4
       print           "B2 = ${b$a}"
 
-   Nor can you specify an expression like "$($x-1.0)" for an immediate
-   variable, but you could use $(v_x-1.0), since the latter is valid
+   Nor can you specify an expression like ``$($x-1.0)`` for an immediate
+   variable, but you could use ``$(v_x-1.0)``, since the latter is valid
    syntax for an :doc:`equal-style variable <variable>`.
 
    See the :doc:`variable <variable>` command for more details of how

doc/src/Commands_removed.rst

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

doc/src/Commands_structure.rst

@@ -8,10 +8,10 @@ page.
 
 A LAMMPS input script typically has 4 parts:
 
-1. :ref:`Initialization <init>`
-2. :ref:`System definition <system>`
-3. :ref:`Simulation settings <settings>`
-4. :ref:`Run a simulation <run>`
+#. :ref:`Initialization <init>`
+#. :ref:`System definition <system>`
+#. :ref:`Simulation settings <settings>`
+#. :ref:`Run a simulation <run>`
 
 The last 2 parts can be repeated as many times as desired.  I.e. run a
 simulation, change some settings, run some more, etc.  Each of the 4

doc/src/Developer_atom.rst

@@ -2,7 +2,7 @@ Accessing per-atom data
 -----------------------
 
 This page discusses how per-atom data is managed in LAMMPS, how it can
-be accessed, what communication patters apply, and some of the utility
+be accessed, what communication patterns apply, and some of the utility
 functions that exist for a variety of purposes.
 
 
@@ -14,11 +14,11 @@ As described on the :doc:`parallel partitioning algorithms
 simulation domain, either in a *brick* or *tiled* manner.  Each MPI
 process *owns* exactly one subdomain and the atoms within it. To compute
 forces for tuples of atoms that are spread across sub-domain boundaries,
-also a "halo" of *ghost* atoms are maintained within a the communication
+also a "halo" of *ghost* atoms are maintained within the communication
 cutoff distance of its subdomain.
 
 The total number of atoms is stored in `Atom::natoms` (within any
-typical class this can be referred to at `atom->natoms`. The number of
+typical class this can be referred to at `atom->natoms`). The number of
 *owned* (or "local" atoms) are stored in `Atom::nlocal`; the number of
 *ghost* atoms is stored in `Atom::nghost`.  The sum of `Atom::nlocal`
 over all MPI processes should be `Atom::natoms`. This is by default
@@ -27,8 +27,8 @@ LAMMPS stops with a "lost atoms" error.  For convenience also the
 property `Atom::nmax` is available, this is the maximum of
 `Atom::nlocal + Atom::nghost` across all MPI processes.
 
-Per-atom properties are either managed by the atom style, or individual
-classes.  or as custom arrays by the individual classes. If only access
+Per-atom properties are either managed by the atom style, individual
+classes,  or as custom arrays by the individual classes. If only access
 to *owned* atoms is needed, they are usually allocated to be of size
 `Atom::nlocal`, otherwise of size `Atom::nmax`. Please note that not all
 per-atom properties are available or updated on *ghost* atoms. For
@@ -61,7 +61,7 @@ can be found via the `Atom::sametag` array. It points to the next atom
 index with the same tag or -1 if there are no more atoms with the same
 tag.  The list will be exhaustive when starting with an index of an
 *owned* atom, since the atom IDs are unique, so there can only be one
-such atom.  Example code to count atoms with same atom ID in subdomain:
+such atom.  Example code to count atoms with same atom ID in a subdomain:
 
 .. code-block:: c++
 

doc/src/Developer_code_design.rst

@@ -69,7 +69,7 @@ The basic LAMMPS class hierarchy which is created by the LAMMPS class
 constructor is shown in :ref:`class-topology`.  When input commands
 are processed, additional class instances are created, or deleted, or
 replaced.  Likewise, specific member functions of specific classes are
-called to trigger actions such creating atoms, computing forces,
+called to trigger actions such as creating atoms, computing forces,
 computing properties, time-propagating the system, or writing output.
 
 Compositing and Inheritance
@@ -110,9 +110,10 @@ As mentioned above, there can be multiple instances of classes derived
 from the ``Fix`` or ``Compute`` base classes.  They represent a
 different facet of LAMMPS' flexibility, as they provide methods which
 can be called at different points within a timestep, as explained in
-`Developer_flow`.  This allows the input script to tailor how a specific
-simulation is run, what diagnostic computations are performed, and how
-the output of those computations is further processed or output.
+the :doc:`How a timestep works <Developer_flow>` doc page.  This allows
+the input script to tailor how a specific simulation is run, what
+diagnostic computations are performed, and how the output of those
+computations is further processed or output.
 
 Additional code sharing is possible by creating derived classes from the
 derived classes (e.g., to implement an accelerated version of a pair
@@ -202,6 +203,7 @@ processed in the expected order before types are removed from dynamic
 dispatch.
 
 .. admonition:: Important Notes
+   :class: note
 
    In order to be able to detect incompatibilities at compile time and
    to avoid unexpected behavior, it is crucial that all member functions
@@ -299,18 +301,24 @@ Formatting with the {fmt} library
 
 The LAMMPS source code includes a copy of the `{fmt} library
 <https://fmt.dev>`_, which is preferred over formatting with the
-"printf()" family of functions.  The primary reason is that it allows
-a typesafe default format for any type of supported data.  This is
+"printf()" family of functions.  The primary reason is that it allows a
+typesafe default format for any type of supported data.  This is
 particularly useful for formatting integers of a given size (32-bit or
-64-bit) which may require different format strings depending on
-compile time settings or compilers/operating systems.  Furthermore,
-{fmt} gives better performance, has more functionality, a familiar
-formatting syntax that has similarities to ``format()`` in Python, and
-provides a facility that can be used to integrate format strings and a
-variable number of arguments into custom functions in a much simpler
-way than the varargs mechanism of the C library.  Finally, {fmt} has
-been included into the C++20 language standard, so changes to adopt it
-are future-proof.
+64-bit) which may require different format strings depending on compile
+time settings or compilers/operating systems.  Furthermore, {fmt} gives
+better performance, has more functionality, a familiar formatting syntax
+that has similarities to ``format()`` in Python, and provides a facility
+that can be used to integrate format strings and a variable number of
+arguments into custom functions in a much simpler way than the varargs
+mechanism of the C library.  Finally, {fmt} has been included into the
+C++20 language standard as ``std::format()``, so changes to adopt it are
+future-proof, for as long as they are not using any extensions that are
+not (yet) included into C++.
+
+The long-term plan is to switch to using ``std::format()`` instead of
+``fmt::format()`` when the minimum C++ standard required for LAMMPS will
+be set to C++20. See the :ref:`basic build instructions <compile>` for
+more details.
 
 Formatted strings are frequently created by calling the
 ``fmt::format()`` function, which will return a string as a
@@ -318,11 +326,13 @@ Formatted strings are frequently created by calling the
 ``printf()``, the {fmt} library uses ``{}`` to embed format descriptors.
 In the simplest case, no additional characters are needed, as {fmt} will
 choose the default format based on the data type of the argument.
-Otherwise, the ``fmt::print()`` function may be used instead of
-``printf()`` or ``fprintf()``.  In addition, several LAMMPS output
-functions, that originally accepted a single string as argument have
-been overloaded to accept a format string with optional arguments as
-well (e.g., ``Error::all()``, ``Error::one()``, ``utils::logmesg()``).
+Otherwise, the :cpp:func:`utils::print() <LAMMPS_NS::utils::print>`
+function may be used instead of ``printf()`` or ``fprintf()``.  In
+addition, several LAMMPS output functions, that originally accepted a
+single string as argument have been overloaded to accept a format string
+with optional arguments as well (e.g., ``Error::all()``,
+``Error::one()``, :cpp:func:`utils::logmesg()
+<LAMMPS_NS::utils::logmesg>`).
 
 Summary of the {fmt} format syntax
 ==================================

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_flow.rst

@@ -128,7 +128,7 @@ reflect particles off box boundaries in the :doc:`FixWallReflect class
 The ``decide()`` method in the Neighbor class determines whether
 neighbor lists need to be rebuilt on the current timestep (conditions
 can be changed using the :doc:`neigh_modify every/delay/check
-<neigh_modify>` command.  If not, coordinates of ghost atoms are
+<neigh_modify>` command).  If not, coordinates of ghost atoms are
 acquired by each processor via the ``forward_comm()`` method of the Comm
 class.  If neighbor lists need to be built, several operations within
 the inner if clause of the pseudocode are first invoked.  The
@@ -209,7 +209,7 @@ nve, nvt, npt.
 
 At the end of the timestep, fixes that contain an ``end_of_step()``
 method are invoked.  These typically perform a diagnostic calculation,
-e.g. the ave/time and ave/spatial fixes.  The final operation of the
+e.g. the ave/time and ave/chunk fixes.  The final operation of the
 timestep is to perform any requested output, via the ``write()`` method
 of the Output class.  There are 3 kinds of LAMMPS output: thermodynamic
 output to the screen and log file, snapshots of atom data to a dump

doc/src/Developer_grid.rst

@@ -433,7 +433,7 @@ from owned to ghost cells, or ghost to owned cells, respectively, as
 described above.  The *caller* argument should be one of these values
 -- Grid3d::COMPUTE, Grid3d::FIX, Grid3d::KSPACE, Grid3d::PAIR --
 depending on the style of the caller class.  The *ptr* argument is the
-"this" pointer to the caller class.  These 2 arguments are used to
+"this" pointer to the caller class.  These two arguments are used to
 call back to pack()/unpack() functions in the caller class, as
 explained below.
 

doc/src/Developer_notes.rst

@@ -7,20 +7,14 @@ typically document what a variable stores, what a small section of
 code does, or what a function does and its input/outputs.  The topics
 on this page are intended to document code functionality at a higher level.
 
-Available topics are:
-
-- `Reading and parsing of text and text files`_
-- `Requesting and accessing neighbor lists`_
-- `Choosing between a custom atom style, fix property/atom, and fix STORE/ATOM`_
-- `Fix contributions to instantaneous energy, virial, and cumulative energy`_
-- `KSpace PPPM FFT grids`_
+.. contents::
 
 ----
 
 Reading and parsing of text and text files
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-It is frequently required for a class in LAMMPS to read in additional
+Classes in LAMMPS frequently need to read in additional
 data from a file, e.g. potential parameters from a potential file for
 manybody potentials.  LAMMPS provides several custom classes and
 convenience functions to simplify the process.  They offer the
@@ -128,9 +122,8 @@ that determines the kind of neighbor list requested.  The default value
 used here asks for a perpetual "half" neighbor list.
 
 Non-default values of the second argument need to be used to adjust a
-neighbor list request to the specific needs of a style an additional
-request flag is needed.  The :doc:`tersoff <pair_tersoff>` pair style,
-for example, needs a "full" neighbor list:
+neighbor list request to the specific needs of a style.  The :doc:`tersoff
+<pair_tersoff>` pair style, for example, needs a "full" neighbor list:
 
 .. code-block:: c++
 
@@ -141,8 +134,8 @@ for example, needs a "full" neighbor list:
    }
 
 When a pair style supports r-RESPA time integration with different cutoff regions,
-the request flag may depend on the corresponding r-RESPA settings. Here an example
-from pair style lj/cut:
+the request flag may depend on the corresponding r-RESPA settings. Here is an
+example from pair style lj/cut:
 
 .. code-block:: c++
 
@@ -160,7 +153,7 @@ from pair style lj/cut:
    }
 
 Granular pair styles need neighbor lists based on particle sizes and not cutoff
-and also may require to have the list of previous neighbors available ("history").
+and also may need to store data across timesteps ("history").
 For example with:
 
 .. code-block:: c++
@@ -169,7 +162,7 @@ For example with:
    else neighbor->add_request(this, NeighConst::REQ_SIZE);
 
 In case a class would need to make multiple neighbor list requests with different
-settings each request can set an id which is then used in the corresponding
+settings, each request can set an id which is then used in the corresponding
 ``init_list()`` function to assign it to the suitable pointer variable. This is
 done for example by the :doc:`pair style meam <pair_meam>`:
 
@@ -219,6 +212,149 @@ command:
 
    neighbor->add_request(this, "delete_atoms", NeighConst::REQ_FULL);
 
+
+Errors, warnings, and informational messages
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+LAMMPS has specialized functionality to handle errors (which should
+terminate LAMMPS), warning messages (which should indicate possible
+problems *without* terminating LAMMPS), and informational text for
+messages about the progress and chosen settings.  We *strongly*
+encourage using these facilities and to *stay away* from using
+``printf()`` or ``fprintf()`` or ``std::cout`` or ``std::cerr`` and
+calling ``MPI_Abort()`` or ``exit()`` directly.  Warnings and
+informational messages should be printed only on MPI rank 0 to avoid
+flooding the output when running in parallel with many MPI processes.
+
+**Errors**
+
+When LAMMPS encounters an error, for example a syntax error in the
+input, then a suitable error message should be printed giving a brief,
+one line remark about the reason and then call either ``Error::all()``
+or ``Error::one()``.  ``Error::all()`` must be called when the failing
+code path is executed by *all* MPI processes and the error condition
+will appear for *all* MPI processes the same.  If desired, each MPI
+process may set a flag to either 0 or 1 and then MPI_Allreduce()
+searching for the maximum can be used to determine if there was an error
+on *any* of the MPI processes and make this information available to
+*all*.  ``Error::one()`` in contrast needs to be called when only one or
+a few MPI processes execute the code path or can have the error
+condition.  ``Error::all()`` is generally the preferred option.
+
+Calling these functions does not abort LAMMPS directly, but rather
+throws either a ``LAMMPSException`` (from ``Error::all()``) or a
+``LAMMPSAbortException`` (from ``Error::one()``).  These exceptions are
+caught by the LAMMPS ``main()`` program and then handled accordingly.
+The reason for this approach is to support applications, especially
+graphical applications like :ref:`LAMMPS-GUI <lammps_gui>`, that are
+linked to the LAMMPS library and have a mechanism to avoid that an error
+in LAMMPS terminates the application. By catching the exceptions, the
+application can delete the failing LAMMPS class instance and create a
+new one to try again.  In a similar fashion, the :doc:`LAMMPS Python
+module <Python_module>` checks for this and then re-throws corresponding
+Python exception, which in turn can be caught by the calling Python
+code.
+
+There are multiple "signatures" that can be called:
+
+- ``Error::all(FLERR, "Error message")``: this will abort LAMMPS with
+  the error message "Error message", followed by the last line of input
+  that was read and processed before the error condition happened.
+
+- ``Error::all(FLERR, Error::NOLASTLINE, "Error message")``: this is the
+  same as before but without the last line of input.  This is preferred
+  for errors that would happen *during* a :doc:`run <run>` or
+  :doc:`minimization <minimize>`, since showing the "run" or "minimize"
+  command would be the last line, but is unrelated to the error.
+
+- ``Error::all(FLERR, idx, "Error message")``: this is for argument
+  parsing where "idx" is the index (starting at 0) of the argument for a
+  LAMMPS command that is causing the failure (use -1 for the command
+  itself).  For index 0, you need to use the constant ``Error::ARGZERO``
+  to work around the inability of some compilers to disambiguate between
+  a NULL pointer and an integer constant 0, even with an added type cast.
+  The output may also include the last input line *before* and
+  *after*, if they differ due to substituting variables.  A textual
+  indicator is pointing to the specific word that failed.  Using the
+  constant ``Error::NOPOINTER`` in place of the *idx* argument will
+  suppress the marker and then the behavior is like the *idx* argument
+  is not provided.
+
+FLERR is a macro containing the filename and line where the Error class
+is called and that information is appended to the error message.  This
+allows to quickly find the relevant source code causing the error.  For
+all three signatures, the single string "Error message" may be replaced
+with a format string using '{}' placeholders and followed by a variable
+number of arguments, one for each placeholder. This format string and
+the arguments are then handed for formatting to the `{fmt} library
+<https://fmt.dev>`_ (which is bundled with LAMMPS) and thus allow
+processing similar to the "format()" functionality in Python.
+
+.. note::
+
+   For commands like :doc:`fix ave/time <fix_ave_time>` that accept
+   wildcard arguments, the :cpp:func:`utils::expand_args` function
+   may be passed as an optional argument where the function will provide
+   a map to the original arguments from the expanded argument indices.
+
+For complex errors, that can have multiple causes and which cannot be
+explained in a single line, you can append to the error message, the
+string created by :cpp:func:`utils::errorurl`, which then provides a
+URL pointing to a paragraph of the :doc:`Errors_details` that
+corresponds to the number provided. Example:
+
+.. code-block:: c++
+
+   error->all(FLERR, "Unknown identifier in data file: {}{}", keyword, utils::errorurl(1));
+
+This will output something like this:
+
+.. parsed-literal::
+
+   ERROR: Unknown identifier in data file: Massess
+   For more information see https://docs.lammps.org/err0001 (src/read_data.cpp:1482)
+   Last input line: read_data       data.peptide
+
+Where the URL points to the first paragraph with explanations on
+the :doc:`Errors_details` page in the manual.
+
+**Warnings**
+
+To print warnings, the ``Errors::warning()`` function should be used.
+It also requires the FLERR macros as first argument to easily identify
+the location of the warning in the source code.  Same as with the error
+functions above, the function has two variants: one just taking a single
+string as final argument and a second that uses the `{fmt} library
+<https://fmt.dev>`_ to make it similar to, say, ``fprintf()``.  One
+motivation to use this function is that it will output warnings with
+always the same capitalization of the leading "WARNING" string.  A
+second is that it has a built in rate limiter.  After a given number (by
+default 100), that can be set via the :doc:`thermo_modify command
+<thermo_modify>` no more warnings are printed.  Also, warnings are
+written consistently to both screen and logfile or not, depending on the
+settings for :ref:`screen <screen>` or :doc:`logfile <log>` output.
+
+.. note::
+
+   Unlike ``Error::all()``, the warning function will produce output on
+   *every* MPI process, so it typically would be prefixed with an if
+   statement testing for ``comm->me == 0``, i.e. limiting output to MPI
+   rank 0.
+
+**Informational messages**
+
+Finally, for informational message LAMMPS has the
+:cpp:func:`utils::logmesg() convenience function
+<LAMMPS_NS::utils::logmesg>`.  It also uses the `{fmt} library
+<https://fmt.dev>`_ to support using a format string followed by a
+matching number of arguments.  It will output the resulting formatted
+text to both, the screen and the logfile and will honor the
+corresponding settings about whether this output is active and to which
+file it should be send.  Same as for ``Error::warning()``, it would
+produce output for every MPI process and thus should usually be called
+only on MPI rank 0 to avoid flooding the output when running with many
+parallel processes.
+
 Choosing between a custom atom style, fix property/atom, and fix STORE/ATOM
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -279,8 +415,8 @@ And here is how the code operates:
 * The :doc:`thermo_style custom <thermo_style>` command defines
   *ecouple* and *econserve* keywords.
 * These keywords sum the energy contributions from all the
-  *ecouple_flag* = 1 fixes by invoking the energy_couple() method in
-  the Modify class, which calls the compute_scalar() method of each
+  *ecouple_flag* = 1 fixes by invoking the *energy_couple()* method in
+  the Modify class, which calls the *compute_scalar()* method of each
   fix in the list.
 
 ------------------
@@ -320,19 +456,19 @@ The fix must also do the following:
 
    The ev_init() and ev_tally() methods also account for global and
    peratom virial contributions.  Thus you do not need to invoke the
-   v_init() and v_tally() methods, if the fix also calculates peratom
+   v_init() and v_tally() methods if the fix also calculates peratom
    energies.
 
 The fix must also specify whether (by default) to include or exclude
 these contributions to the global/peratom energy/virial of the system.
-For the fix to include the contributions, set either of both of these
+For the fix to include the contributions, set either or both of these
 variables in the constructor:
 
 * *thermo_energy* = 1, for global and peratom energy
 * *thermo_virial* = 1, for global and peratom virial
 
 Note that these variables are zeroed in fix.cpp.  Thus if you don't
-set the variables, the contributions will be excluded (by default)
+set the variables, the contributions will be excluded (by default).
 
 However, the user has ultimate control over whether to include or
 exclude the contributions of the fix via the :doc:`fix modify
@@ -406,9 +542,11 @@ processor owns, within the global grid:
 
 .. parsed-literal::
 
-   nxlo_in,nxhi_in,nylo_in,nyhi_in,nzlo_in,nzhi_in = 3d decomposition brick
-   nxlo_fft,nxhi_fft,nylo_fft,nyhi_fft,nzlo_fft,nzhi_fft = FFT decomposition brick
-   nxlo_out,nxhi_out,nylo_out,nyhi_out,nzlo_out,nzhi_out = 3d decomposition brick + ghost cells
+   nFOO_in = 3d decomposition brick
+   nFOO_fft = FFT decomposition brick
+   nFOO_out = 3d decomposition brick + ghost cells
+
+where ``FOO`` corresponds to ``xlo, xhi, ylo, yhi, zlo,`` or ``zhi``.
 
 The ``in`` and ``fft`` indices are from 0 to N-1 inclusive in each
 dimension, where N is the grid size.

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_par_comm.rst

@@ -4,8 +4,7 @@ Communication
 Following the selected partitioning scheme, all per-atom data is
 distributed across the MPI processes, which allows LAMMPS to handle very
 large systems provided it uses a correspondingly large number of MPI
-processes.  Since The per-atom data (atom IDs, positions, velocities,
-types, etc.)  To be able to compute the short-range interactions, MPI
+processes.  To be able to compute the short-range interactions, MPI
 processes need not only access to the data of atoms they "own" but also
 information about atoms from neighboring subdomains, in LAMMPS referred
 to as "ghost" atoms.  These are copies of atoms storing required
@@ -37,7 +36,7 @@ be larger than half the simulation domain.
 
 Efficient communication patterns are needed to update the "ghost" atom
 data, since that needs to be done at every MD time step or minimization
-step.  The diagrams of the `ghost-atom-comm` figure illustrate how ghost
+step.  The diagrams of the :ref:`ghost-atom-comm` figure illustrate how ghost
 atom communication is performed in two stages for a 2d simulation (three
 in 3d) for both a regular and irregular partitioning of the simulation
 box.  For the regular case (left) atoms are exchanged first in the

doc/src/Developer_par_long.rst

@@ -93,7 +93,7 @@ processors, since each tile in the initial tiling overlaps with a
 handful of tiles in the final tiling.
 
 The transformations could also be done using collective communication
-across all $P$ processors with a single call to ``MPI_Alltoall()``, but
+across all :math:`P` processors with a single call to ``MPI_Alltoall()``, but
 this is typically much slower.  However, for the specialized brick and
 pencil tiling illustrated in :ref:`fft-parallel` figure, collective
 communication across the entire MPI communicator is not required.  In
@@ -138,7 +138,7 @@ grid/particle operations that LAMMPS supports:
   :math:`O(P^{\frac{1}{2}})`.
 
 - For efficiency in performing 1d FFTs, the grid transpose
-  operations illustrated in Figure \ref{fig:fft} also involve
+  operations illustrated in Figure :ref:`fft-parallel` also involve
   reordering the 3d data so that a different dimension is contiguous
   in memory.  This reordering can be done during the packing or
   unpacking of buffers for MPI communication.

doc/src/Developer_par_neigh.rst

@@ -149,7 +149,7 @@ supports:
 
 - Dependent on the "pair" setting of the :doc:`newton <newton>` command,
   the "half" neighbor lists may contain **all** pairs of atoms where
-  atom *j* is a ghost atom (i.e. when the newton pair setting is *off*)
+  atom *j* is a ghost atom (i.e. when the newton pair setting is *off*).
   For the newton pair *on* setting the atom *j* is only added to the
   list if its *z* coordinate is larger, or if equal the *y* coordinate
   is larger, and that is equal, too, the *x* coordinate is larger.  For

doc/src/Developer_par_openmp.rst

@@ -1,13 +1,13 @@
 OpenMP Parallelism
 ^^^^^^^^^^^^^^^^^^
 
-The styles in the INTEL, KOKKOS, and OPENMP package offer to use OpenMP
+The styles in the INTEL, KOKKOS, and OPENMP packages offer to use OpenMP
 thread parallelism to predominantly distribute loops over local data
 and thus follow an orthogonal parallelization strategy to the
 decomposition into spatial domains used by the :doc:`MPI partitioning
 <Developer_par_part>`.  For clarity, this section discusses only the
 implementation in the OPENMP package, as it is the simplest. The INTEL
-and KOKKOS package offer additional options and are more complex since
+and KOKKOS packages offer additional options and are more complex since
 they support more features and different hardware like co-processors
 or GPUs.
 
@@ -16,7 +16,7 @@ keep the changes to the source code small, so that it would be easier to
 maintain the code and keep it in sync with the non-threaded standard
 implementation.  This is achieved by a) making the OPENMP version a
 derived class from the regular version (e.g. ``PairLJCutOMP`` from
-``PairLJCut``) and overriding only methods that are multi-threaded or
+``PairLJCut``) and only overriding methods that are multi-threaded or
 need to be modified to support multi-threading (similar to what was done
 in the OPT package), b) keeping the structure in the modified code very
 similar so that side-by-side comparisons are still useful, and c)

doc/src/Developer_plugins.rst

@@ -53,7 +53,7 @@ Members of ``lammpsplugin_t``
 
 .. list-table::
    :header-rows: 1
-   :widths: auto
+   :widths: 15 85
 
    * - Member
      - Description
@@ -135,7 +135,7 @@ unique inside the entire LAMMPS executable.
 Fix style example
 ^^^^^^^^^^^^^^^^^
 
-If the factory function would be for a fix or compute, which take three
+If the factory function is for a fix or compute, which take three
 arguments (a pointer to the LAMMPS class, the number of arguments and the
 list of argument strings), then the pointer type is ``lammpsplugin_factory2``
 and it must be assigned to the *creator.v2* member of the plugin struct.
@@ -271,7 +271,7 @@ Plugins need to be compiled with the same compilers and libraries
 as the LAMMPS executable and library.  Otherwise the plugin will likely
 not load due to mismatches in the function signatures (LAMMPS is C++ so
 scope, type, and number of arguments are encoded into the symbol names
-and thus differences in them will lead to failed plugin load commands.
+and thus differences in them will lead to failed plugin load commands).
 Compilation of the plugin can be managed via both, CMake or traditional
 GNU makefiles.  Some examples that can be used as a template are in the
 ``examples/plugins`` folder.  The CMake script code has some small
@@ -283,7 +283,7 @@ in the ``examples/kim/plugin`` folder.  No changes to the sources of the
 KIM package themselves are needed; only the plugin interface and loader
 code needs to be added.  This example only supports building with CMake,
 but is probably a more typical example. To compile you need to run CMake
-with -DLAMMPS_SOURCE_DIR=<path/to/lammps/src/folder>.  Other
+with ``-DLAMMPS_SOURCE_DIR=<path/to/lammps/src/folder>``.  Other
 configuration setting are identical to those for compiling LAMMPS.
 
 A second example for a plugin from a package is in the

doc/src/Developer_unittest.rst

@@ -44,7 +44,7 @@ available:
 
 .. list-table::
    :header-rows: 1
-   :widths: auto
+   :widths: 32 18 50
    :align: left
 
    * - File name:
@@ -227,12 +227,12 @@ Tests for the C-style library interface
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Tests for validating the LAMMPS C-style library interface are in the
-``unittest/c-library`` folder.  They are implemented in either way used
-for utility functions and for LAMMPS commands, but use the functions
-implemented in the ``src/library.cpp`` file as much as possible.  There
-may be some overlap with other tests, but only in as much as is required
-to test the C-style library API.  The tests are distributed over
-multiple test programs which tries to match the grouping of the
+``unittest/c-library`` folder.  They text either utility functions or
+LAMMPS commands, but use the functions implemented in
+``src/library.cpp`` as much as possible.  There may be some overlap with
+other tests as far as the LAMMPS functionality is concerned, but the
+focus is on testing the C-style library API.  The tests are distributed
+over multiple test programs which try to match the grouping of the
 functions in the source code and :ref:`in the manual <lammps_c_api>`.
 
 This group of tests also includes tests invoking LAMMPS in parallel
@@ -272,29 +272,30 @@ Tests for the Fortran interface
 
 Tests for using the Fortran module are in the ``unittest/fortran``
 folder.  Since they are also using the GoogleTest library, they require
-to also implement test wrappers in C++ that will call fortran functions
-which provide a C function interface through ISO_C_BINDINGS that will in
-turn call the functions in the LAMMPS Fortran module.
+test wrappers written in C++ that will call fortran functions with a C
+function interface through ISO_C_BINDINGS which will in turn call the
+functions in the LAMMPS Fortran module.
 
 Tests for the C++-style library interface
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The tests in the ``unittest/cplusplus`` folder are somewhat similar to
 the tests for the C-style library interface, but do not need to test the
-several convenience and utility functions that are only available through
-the C-style interface.  Instead it can focus on the more generic features
-that are used internally.  This part of the unit tests is currently still
-mostly in the planning stage.
+convenience and utility functions that are only available through the
+C-style library interface.  Instead they focus on the more generic
+features that are used in LAMMPS internally.  This part of the unit
+tests is currently still mostly in the planning stage.
 
 Tests for reading and writing file formats
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The ``unittest/formats`` folder contains test programs for reading and
-writing files like data files, restart files, potential files or dump files.
-This covers simple things like the file i/o convenience functions in the
-``utils::`` namespace to complex tests of atom styles where creating and
-deleting of atoms with different properties is tested in different ways
-and through script commands or reading and writing of data or restart files.
+writing files like data files, restart files, potential files or dump
+files.  This covers simple things like the file i/o convenience
+functions in the ``utils::`` namespace to complex tests of atom styles
+where creating and deleting of atoms with different properties is tested
+in different ways and through script commands or reading and writing of
+data or restart files.
 
 Tests for styles computing or modifying forces
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -411,7 +412,7 @@ With this scheme a large fraction of the code of any tested pair style
 will be executed and consistent results are required for different
 settings and between different accelerated pair style variants and the
 base class, as well as for computing individual pairs through the
-``Pair::single()`` where supported.
+``Pair::single()`` method where supported.
 
 The ``test_pair_style`` tester is used with 4 categories of test inputs:
 
@@ -476,7 +477,7 @@ the tabulated coulomb, to test both code paths.  The reference results in the YA
 files then should be compared manually, if they agree well enough within the limits
 of those two approximations.
 
-The ``test_pair_style`` and equivalent programs have special command line options
+The ``test_pair_style`` and equivalent programs have special command-line options
 to update the YAML files. Running a command like
 
 .. code-block:: bash
@@ -531,19 +532,20 @@ Python module.
 Troubleshooting failed unit tests
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The are by default no unit tests for newly added features (e.g. pair, fix,
-or compute styles) unless your pull request also includes tests for the
-added features.  If you are modifying some features, you may see failures
-for existing tests, if your modifications have some unexpected side effects
-or your changes render the existing text invalid.  If you are adding an
-accelerated version of an existing style, then only tests for INTEL,
-KOKKOS (with OpenMP only), OPENMP, and OPT will be run automatically.
-Tests for the GPU package are time consuming and thus are only run
-*after* a merge, or when a special label, ``gpu_unit_tests`` is added
-to the pull request.  After the test has started, it is often best to
-remove the label since every PR activity will re-trigger the test (that
-is a limitation of triggering a test with a label).  Support for unit
-tests with using KOKKOS with GPU acceleration is currently not supported.
+There are by default no unit tests for newly added features (e.g. pair,
+fix, or compute styles) unless your pull request also includes tests for
+these added features.  If you are modifying some existing LAMMPS
+features, you may see failures for existing tests, if your modifications
+have some unexpected side effects or your changes render the existing
+test invalid.  If you are adding an accelerated version of an existing
+style, then only tests for INTEL, KOKKOS (with OpenMP only), OPENMP, and
+OPT will be run automatically.  Tests for the GPU package are time
+consuming and thus are only run *after* a merge, or when a special
+label, ``gpu_unit_tests`` is added to the pull request.  After the test
+has started, it is often best to remove the label since every PR
+activity will re-trigger the test (that is a limitation of triggering a
+test with a label).  Support for unit tests using KOKKOS with GPU
+acceleration is currently not supported.
 
 When you see a failed build on GitHub, click on ``Details`` to be taken
 to the corresponding LAMMPS Jenkins CI web page.  Click on the "Exit"
@@ -588,12 +590,11 @@ While the epsilon (relative precision) for a single, `IEEE 754 compliant
 <https://en.wikipedia.org/wiki/IEEE_754>`_, double precision floating
 point operation is at about 2.2e-16, the achievable precision for the
 tests is lower due to most numbers being sums over intermediate results
-and the non-associativity of floating point math leading to larger
-errors.  In some cases specific properties of the tested style.  As a
-rule of thumb, the test epsilon can often be in the range 5.0e-14 to
-1.0e-13.  But for "noisy" force kernels, e.g. those a larger amount of
-arithmetic operations involving `exp()`, `log()` or `sin()` functions,
-and also due to the effect of compiler optimization or differences
+for which the non-associativity of floating point math leads to larger
+errors.  As a rule of thumb, the test epsilon can often be in the range
+5.0e-14 to 1.0e-13.  But for "noisy" force kernels, e.g. those a larger
+amount of arithmetic operations involving `exp()`, `log()` or `sin()`
+functions, and also due to the effect of compiler optimization or differences
 between compilers or platforms, epsilon may need to be further relaxed,
 sometimes epsilon can be relaxed to 1.0e-12. If interpolation or lookup
 tables are used, epsilon may need to be set to 1.0e-10 or even higher.
@@ -603,14 +604,14 @@ of floating point operations or that some or most intermediate operations
 may be done using approximations or with single precision floating point
 math.
 
-To rerun the failed unit test individually, change to the ``build`` directory
+To rerun a failed unit test individually, change to the ``build`` directory
 and run the test with verbose output. For example,
 
 .. code-block:: bash
 
     env TEST_ARGS=-v ctest -R ^MolPairStyle:lj_cut_coul_long -V
 
-``ctest`` with the ``-V`` flag also shows the exact command line
+``ctest`` with the ``-V`` flag also shows the exact command
 of the test. One can then use ``gdb --args`` to further debug and
 catch exceptions with the test command, for example,
 

doc/src/Developer_updating.rst

@@ -52,10 +52,9 @@ Rename of pack/unpack_comm() to pack/unpack_forward_comm()
 
 .. versionchanged:: 8Aug2014
 
-In this change set the functions to pack data into communication buffers
-and to unpack data from communication buffers for :doc:`forward
-communications <Developer_comm_ops>` were renamed from ``pack_comm()``
-and ``unpack_comm()`` to ``pack_forward_comm()`` and
+In this change set, the functions to pack/unpack data into communication buffers
+for :doc:`forward communications <Developer_comm_ops>` were renamed from
+``pack_comm()`` and ``unpack_comm()`` to ``pack_forward_comm()`` and
 ``unpack_forward_comm()``, respectively.  Also the meaning of the return
 value of these functions was changed: rather than returning the number
 of items per atom stored in the buffer, now the total number of items
@@ -109,7 +108,7 @@ Use ev_init() to initialize variables derived from eflag and vflag
 There are several variables that need to be initialized based on
 the values of the "eflag" and "vflag" variables and since sometimes
 there are new bits added and new variables need to be set to 1 or 0.
-To make this consistent, across all styles, there is now an inline
+To make this consistent across all styles, there is now an inline
 function ``ev_init(eflag, vflag)`` that makes those settings
 consistently and calls either ``ev_setup()`` or ``ev_unset()``.
 Example from a pair style:
@@ -211,14 +210,14 @@ The :cpp:func:`utils::open_potential()
 calls to ``force->open_potential()`` and should be used to replace
 ``fopen()`` for opening potential files for reading.  The custom
 function does three additional steps compared to ``fopen()``: 1) it will
-try to parse the ``UNITS:`` and ``DATE:`` metadata will stop with an
+try to parse the ``UNITS:`` and ``DATE:`` metadata and will stop with an
 error on a units mismatch and will print the date info, if present, in
 the log file; 2) for pair styles that support it, it will set up
 possible automatic unit conversions based on the embedded unit
 information and LAMMPS' current units setting; 3) it will not only try
 to open a potential file at the given path, but will also search in the
 folders listed in the ``LAMMPS_POTENTIALS`` environment variable.  This
-allows to keep potential files in a common location instead of having to
+allows potential files to reside in a common location instead of having to
 copy them around for simulations.
 
 Old:
@@ -246,36 +245,38 @@ to use scoped enumerators instead.
 
 .. list-table::
    :header-rows: 1
-   :widths: auto
+   :widths: 23 10 23 10 23 10
 
    * - Symbolic Constant
      - Value
      - Symbolic Constant
      - Value
+     - Symbolic Constant
+     - Value
    * - Atom::GROW
+     - 0
+     - Atom::ATOMIC
      - 0
      - Atom::MAP_NONE
      - 0
    * - Atom::RESTART
+     - 1
+     - Atom::MOLECULAR
      - 1
      - Atom::MAP_ARRAY
      - 1
    * - Atom::BORDER
+     - 2
+     - Atom::TEMPLATE
      - 2
      - Atom::MAP_HASH
      - 2
-   * - Atom::ATOMIC
+   * - AtomVec::PER_ATOM
      - 0
-     - Atom::MAP_YES
-     - 3
-   * - Atom::MOLECULAR
-     - 1
-     - AtomVec::PER_ATOM
-     - 0
-   * - Atom::TEMPLATE
-     - 2
      - AtomVec::PER_TYPE
      - 1
+     - Atom::MAP_YES
+     - 3
 
 Old:
 
@@ -306,7 +307,7 @@ Simplify customized error messages
 
 Aided by features of the bundled {fmt} library, error messages now
 can have a variable number of arguments and the string will be interpreted
-as a {fmt} style format string so that custom error messages can be
+as a {fmt} style format string so that error messages can be
 easily customized without having to use temporary buffers and ``sprintf()``.
 Example:
 
@@ -332,7 +333,7 @@ Use of "override" instead of "virtual"
 
 .. versionchanged:: 17Feb2022
 
-Since LAMMPS requires C++11 we switched to use the "override" keyword
+Since LAMMPS requires C++11, we switched to use the "override" keyword
 instead of "virtual" to indicate polymorphism in derived classes.  This
 allows the C++ compiler to better detect inconsistencies when an
 override is intended or not.  Please note that "override" has to be
@@ -370,7 +371,7 @@ Simplified function names for forward and reverse communication
 
 .. versionchanged:: 24Mar2022
 
-Rather then using the function name to distinguish between the different
+Rather than using the function name to distinguish between the different
 forward and reverse communication functions for styles, LAMMPS now uses
 the type of the "this" pointer argument.
 

doc/src/Developer_utils.rst

@@ -133,6 +133,9 @@ and parsing files or arguments.
 .. doxygenfunction:: trim_comment
    :project: progguide
 
+.. doxygenfunction:: strcompress
+   :project: progguide
+
 .. doxygenfunction:: strip_style_suffix
    :project: progguide
 
@@ -166,6 +169,9 @@ and parsing files or arguments.
 .. doxygenfunction:: split_lines
    :project: progguide
 
+.. doxygenfunction:: strsame
+   :project: progguide
+
 .. doxygenfunction:: strmatch
    :project: progguide
 
@@ -232,12 +238,21 @@ Convenience functions
 .. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &mesg)
    :project: progguide
 
+.. doxygenfunction:: print(FILE *fp, const std::string &format, Args&&... args)
+   :project: progguide
+
+.. doxygenfunction:: print(FILE *fp, const std::string &mesg)
+   :project: progguide
+
 .. doxygenfunction:: errorurl
    :project: progguide
 
 .. doxygenfunction:: missing_cmd_args
    :project: progguide
 
+.. doxygenfunction:: point_to_error
+   :project: progguide
+
 .. doxygenfunction:: flush_buffers(LAMMPS *lmp)
    :project: progguide
 
@@ -622,7 +637,7 @@ classes:
    of a dense, symmetric, real matrix.
 
 #. The "PEigenDense" class only calculates the principal eigenvalue
-   (ie. the largest or smallest eigenvalue), and its corresponding
+   (i.e. the largest or smallest eigenvalue), and its corresponding
    eigenvector.  However it is much more efficient than "Jacobi" when
    applied to large matrices (larger than 13x13).  PEigenDense also can
    understand complex-valued Hermitian matrices.

doc/src/Developer_write.rst

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

doc/src/Developer_write_command.rst

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

doc/src/Developer_write_fix.rst

@@ -74,8 +74,7 @@ The next method we need to implement is ``setmask()``:
 
 Here the we specify which methods of the fix should be called during
 :doc:`execution of a timestep <Developer_flow>`.  The constant
-``END_OF_STEP`` corresponds to the ``end_of_step()`` method. The most
-important available methods that are called during a timestep.
+``END_OF_STEP`` corresponds to the ``end_of_step()`` method.
 
 .. code-block:: c++
 
@@ -97,8 +96,8 @@ important available methods that are called during a timestep.
      MPI_Allreduce(localAvgVel, globalAvgVel, 4, MPI_DOUBLE, MPI_SUM, world);
      scale3(1.0 / globalAvgVel[3], globalAvgVel);
      if ((comm->me == 0) && screen) {
-       fmt::print(screen,"{}, {}, {}\n",
-                  globalAvgVel[0], globalAvgVel[1], globalAvgVel[2]);
+       utils::print(screen, "{}, {}, {}\n",
+                    globalAvgVel[0], globalAvgVel[1], globalAvgVel[2]);
      }
    }
 
@@ -127,7 +126,7 @@ there is no need to inherit from it directly.
 The code above computes average velocity for all particles in the
 simulation.  Yet you have one unused parameter in fix call from the
 script: ``group_name``.  This parameter specifies the group of atoms
-used in the fix. So we should compute average for all particles in the
+used in the fix. So we should compute the average for all particles in the
 simulation only if ``group_name == "all"``, but it can be any group.
 The group membership information of an atom is contained in the *mask*
 property of an atom and the bit corresponding to a given group is
@@ -142,7 +141,7 @@ stored in the groupbit variable which is defined in Fix base class:
    }
 
 Class Atom encapsulates atoms positions, velocities, forces, etc. Users
-can access them using particle index. Note, that particle indexes are
+can access them using the particle index. Note, that particle indexes are
 usually changed every few timesteps because of neighbor list rebuilds
 and spatial sorting (to improve cache efficiency).
 
@@ -154,8 +153,8 @@ this situation there are several methods which should be implemented:
 - ``double memory_usage()``: return how much memory the fix uses (optional)
 - ``void grow_arrays(int)``: do reallocation of the per-particle arrays in your fix
 - ``void copy_arrays(int i, int j, int delflag)``: copy i-th per-particle
-  information to j-th. Used when atom sorting is performed. if delflag is set
-  and atom j owns a body, move the body information to atom i.
+  information to j-th particle position. Used when atom sorting is performed.
+  if delflag is set and atom j owns a body, move the body information to atom i.
 - ``void set_arrays(int i)``: sets i-th particle related information to zero
 
 Note, that if your class implements these methods, it must add calls of
@@ -230,11 +229,11 @@ is just a bunch of template functions for allocating 1D and 2D
 arrays. So you need to add include ``memory.h`` to have access to them.
 
 Finally, if you need to write/read some global information used in
-your fix to the restart file, you might do it by setting flag
-``restart_global = 1`` in the constructor and implementing methods void
-``write_restart(FILE *fp)`` and ``void restart(char *buf)``.
+your fix to the restart file, you might do it by setting the flag
+``restart_global = 1`` in the constructor and implementing methods
+``void write_restart(FILE *fp)`` and ``void restart(char *buf)``.
 If, in addition, you want to write the per-atom property to restart
-files additional settings and functions are needed:
+files then these additional settings and functions are needed:
 
 - a fix flag indicating this needs to be set ``restart_peratom = 1;``
 - ``atom->add_callback()`` and ``atom->delete_callback()`` must be called

doc/src/Developer_write_pair.rst

@@ -50,6 +50,30 @@ We are looking at the following cases:
 - `Case 3: a potential requiring communication`_
 - `Case 4: potentials without a compute() function`_
 
+Package and build system considerations
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In general, new pair styles should be added to the :ref:`EXTRA-PAIR
+package <PKG-EXTRA-PAIR>` unless they are an accelerated pair style and
+then they should be added to the corresponding accelerator package
+(:ref:`GPU <PKG-GPU>`, :ref:`INTEL <PKG-INTEL>`, :ref:`KOKKOS
+<PKG-KOKKOS>`, :ref:`OPENMP <PKG-OPENMP>`, :ref:`OPT <PKG-OPT>`).  If
+you feel that your contribution should be added to a different package,
+please consult with the LAMMPS developers first.
+
+The contributed code needs to support the :doc:`traditional GNU make
+build process <Build_make>` **and** the :doc:`CMake build process
+<Build_cmake>`.  For the GNU make process and if the package has an
+``Install.sh`` file, most likely that file needs to be updated to
+correctly copy the sources when installing the package and properly
+delete them when uninstalling.  This is particularly important when
+added a new pair style that is a derived class from an existing pair
+style in a package, so that its installation depends on the the
+installation status of the package of the derived class.  For the CMake
+process, it is sometimes necessary to make changes to the package
+specific CMake scripting in ``cmake/Modules/Packages``.
+
+
 ----
 
 Case 1: a pairwise additive model
@@ -136,7 +160,7 @@ message and before the include guards for the class definition:
 
    #endif
 
-This block of between ``#ifdef PAIR_CLASS`` and ``#else`` will be
+This block between ``#ifdef PAIR_CLASS`` and ``#else`` will be
 included by the ``Force`` class in ``force.cpp`` to build a map of
 "factory functions" that will create an instance of these classes and
 return a pointer to it.  The map connects the name of the pair style,
@@ -286,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
@@ -347,9 +371,9 @@ but moving this to a separate function allows users to change global
 settings like the default cutoff without having to reissue all
 pair_coeff commands or re-read the ``Pair Coeffs`` sections from the
 data file.  In the ``settings()`` function, also the arrays for storing
-parameters, to define cutoffs, track with pairs of parameters have been
-explicitly set are allocated and, if needed, initialized.  In this case,
-the memory allocation and initialization is moved to a function
+parameters, to define cutoffs, track which pairs of parameters have been
+explicitly set and allocated and, if needed, initialized.  In this case,
+the memory allocation and initialization are moved to a function
 ``allocate()``.
 
 .. code-block:: c++
@@ -564,17 +588,20 @@ loop atoms are also initialized.
        jnum = numneigh[i];
 
 The inner loop (index *j*) processes the neighbor lists.  The neighbor
-list code encodes in the upper 2 bits whether a pair is a regular pair
-of neighbor (= 0) or a pair of 1-2 (= 1), 1-3 (= 2), or 1-4 (= 3)
-:doc:`"special" neighbor <special_bonds>`.  The ``sbmask()`` inline
-function extracts those bits and converts them into a number.  This
-number is used to look up the corresponding scaling factor for the
-non-bonded interaction from the ``force->special_lj`` array and stores
-it in the `factor_lj` variable.  Due to the additional bits, the value
-of *j* would be out of range when accessing data from per-atom arrays,
-so we apply the NEIGHMASK constant with a bit-wise and operation to mask
-them out.  This step *must* be done, even if a pair style does not use
-special bond scaling of forces and energies to avoid segmentation faults.
+list code encodes extra information using the upper 3 bits. The 2
+highest bits encode whether a pair is a regular pair of neighbor (= 0)
+or a pair of 1-2 (= 1), 1-3 (= 2), or 1-4 (= 3) :doc:`"special" neighbor
+<special_bonds>`.  The next highest bit encodes whether the pair stores
+data in a ``fix neigh/history`` instance (an undocumented internal fix
+style).  The ``sbmask()`` inline function extracts those bits and
+converts them into a number.  This number is used to look up the
+corresponding scaling factor for the non-bonded interaction from the
+``force->special_lj`` array and stores it in the `factor_lj` variable.
+Due to the additional bits, the value of *j* would be out of range when
+accessing data from per-atom arrays, so we apply the NEIGHMASK constant
+with a bit-wise and operation to mask them out.  This step *must* be
+done, even if a pair style does not use special bond scaling of forces
+and energies to avoid segmentation faults.
 
 With the corrected *j* index, it is now possible to compute the distance
 of the pair.  For efficiency reasons, the square root is only taken
@@ -864,10 +891,10 @@ 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
+parameters will be read from the data file, if present, and
 :doc:`pair_coeff commands <pair_coeff>` may not be needed.
 
 The member variable ``writedata`` should be set to 1 in the constructor,
@@ -1095,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
@@ -1329,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_common.rst

@@ -39,7 +39,8 @@ figure out your physics or numerical mistakes, like choosing too big a
 timestep, specifying erroneous force field coefficients, or putting 2
 atoms on top of each other!  If you run into errors that LAMMPS
 does not catch that you think it should flag, please send an email to
-the `developers <https://www.lammps.org/authors.html>`_.
+the `developers <https://www.lammps.org/authors.html>`_ or create an new
+topic on the dedicated `MatSci forum section <https://matsci.org/lammps/>`_.
 
 If you get an error message about an invalid command in your input
 script, you can determine what command is causing the problem by

doc/src/Errors_debug.rst

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

doc/src/Errors_details.rst

@@ -4,9 +4,172 @@ Error and warning details
 Many errors or warnings are self-explanatory and thus straightforward to
 resolve.  However, there are also cases, where there is no single cause
 and explanation, where LAMMPS can only detect symptoms of an error but
-not the exact cause, or where the explanation needs to be more detailed than
-what can be fit into a message printed by the program.  The following are
-discussions of such cases.
+not the exact cause, or where the explanation needs to be more detailed
+than what can be fit into a message printed by the program.  The
+following are discussions of such cases.
+
+- :ref:`Unknown identifier in data file <err0001>`
+- :ref:`Incorrect format in ... section of data file <err0002>`
+- :ref:`Illegal variable command: expected X arguments but found Y <err0003>`
+- :ref:`Out of range atoms - cannot compute ... <err0004>`
+- :ref:`Too many neighbor bins <err0009>`
+- :ref:`Cannot use neighbor bins - box size \<\< cutoff <err0015>`
+- :ref:`Domain too large for neighbor bins <err0017>`
+- :ref:`Molecule topology/atom exceeds system topology/atom <err0024>`
+- :ref:`Molecule topology type exceeds system topology type <err0025>`
+- :ref:`Molecule attributes do not match system attributes <err0026>`
+
+------
+
+General troubleshooting advice
+------------------------------
+
+Below are suggestions that can help to understand the causes of problems
+with simulations leading to errors or unexpected results.
+
+Create a small test system
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Debugging problems often requires running a simulation many times with
+small modifications, thus it can be a huge time saver to first assemble
+a small test system input that has the same issue, but will take much
+time until it triggers the error condition.  Also, it will be easier to
+see what happens.
+
+Visualize your trajectory
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To better understand what is causing problems, it is often very useful
+to visualize the system close to the point of failure.  It may be
+necessary to have LAMMPS output trajectory frames rather frequently.  To
+avoid gigantic files, you can use :doc:`dump_modify delay <dump_modify>`
+to delay output until the critical section is reached, and you can use a
+smaller test system (see above).
+
+Parallel versus serial
+^^^^^^^^^^^^^^^^^^^^^^
+
+Issues where something is "lost" or "missing" often exhibit that issue
+only when running in parallel.  That doesn't mean there is no problem,
+only the symptoms are not triggering an error quickly.  Correspondingly,
+errors may be triggered faster with more processors and thus smaller
+sub-domains.
+
+Fast moving atoms
+^^^^^^^^^^^^^^^^^
+
+Fast moving atoms may be "lost" or "missing" when their velocity becomes
+so large that they can cross a sub-domain within one timestep.  This
+often happens when atoms are too close, but atoms may also "move" too
+fast from sub-domain to sub-domain if the box changes rapidly, e.g. when
+setting a large an initial box with :doc:`shrink-wrap boundary
+conditions <boundary>` that collapses on the first step (in this case
+the solution is often using 'm' instead of 's' as boundary condition).
+
+To reduce the impact of "close contacts", one can remove those atoms or
+molecules with something like :doc:`delete_atoms overlap 0.1 all all
+<delete_atoms>`.  With periodic boundaries, a close contact pair of atoms
+may be on opposite sides of the simulation box.  Another option would be
+to first run a minimization (aka quench) before starting the MD.  Reducing
+the time step can also help.  Many times, one just needs to "ease" the
+system into a balanced state and can then switch to more aggressive settings.
+
+The speed of atoms during an MD depends on the steepness of the
+potential function and their mass.  Since the positions and velocities
+of atoms are computed with finite timesteps, they choice of timestep can
+be too large for a stable numeric integration of the trajectory.  In
+those cases using (temporarily) :doc:`fix nve/limit <fix_nve_limit>` or
+:doc:`fix dt/reset <fix_dt_reset>` can help to avoid too large updates
+or adapt the timestep according to the displacements.
+
+
+Pressure, forces, positions becoming NaN of Inf
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Some potentials can overflow or have a division by zero with close contacts
+or bad geometries (for the given force styles in use) leading to forces
+that can no longer be represented as numbers.  Those will show as "NaN" or
+"Inf".  On most machines, the program will continue, but there is no way
+to recover from it and those NaN or Inf values will propagate.  So-called
+:doc:`"soft-core" potentials <pair_fep_soft>` or the :doc:`"soft" repulsive-only
+pair style <pair_soft>` are less prone for this behavior (depending on the
+settings in use) and can be used at the beginning of a simulation.  Also,
+single precision numbers can overflow much faster, so for the GPU or INTEL
+package it may be beneficial to run with double precision initially before
+switching to mixed or single precision for faster execution when the system
+has relaxed.
+
+Communication cutoff
+^^^^^^^^^^^^^^^^^^^^
+
+The communication cutoff determines the "overlap" between sub-domains
+and atoms in these regions are referred to in LAMMPS as "ghost atoms".
+This region has to be large enough to contain all atoms of a bond,
+angle, dihedral or improper with just one atom in the actual sub-domain.
+Typically, this cutoff is set to the largest cutoff from the :doc:`pair
+style(s) <pair_style>` plus the :doc:`neighbor list skin distance
+<neighbor>` and will be more than sufficient for all bonded
+interactions.  But if the pair style cutoff is small this may bot be
+enough.  LAMMPS will print a warning in this case using some heuristic
+based on the equilibrium bond length, but that may not be sufficient for
+cases where the force constants are small and thus bonds may be
+stretched very far.  The communication cutoff can be adjusted with
+:doc:`comm_modify cutoff \<value\> <comm_modify>`, but setting this too
+large will waste CPU time and memory.
+
+Neighbor list settings
+^^^^^^^^^^^^^^^^^^^^^^
+
+Every time LAMMPS rebuilds the neighbor lists, LAMMPS will also check
+for "lost" or "missing" atoms.  Thus it can help to use very
+conservative :doc:`neighbor list settings <neigh_modify>` and then
+examine the neighbor list statistics if the neighbor list rebuild can be
+safely delayed.  Rebuilding the neighbor list less frequently
+(i.e. through increasing the *delay* or *every* setting has diminishing
+returns and increasing risks).
+
+Ignoring lost atoms
+^^^^^^^^^^^^^^^^^^^
+
+It is tempting to use the :doc:`thermo_modify lost ignore <thermo_modify>`
+to avoid that LAMMPS stops with an error.  This setting should, however,
+*only* be used when atoms *should* leave the system.  In general, ignoring
+a problem does not solve it.
+
+Units
+^^^^^
+
+A frequent cause for a variety of problems is due to using the wrong
+:doc:`units <units>` settings for a particular potentials, especially
+when reading them from a potential file.  Most of the (example)
+potentials bundled with LAMMPS have a "UNITS:" tag that allows LAMMPS to
+check of the units are consistent with what is intended, but potential
+files from publications or potential parameter databases may lack this
+metadata information and thus will not error out or warn when using the
+wrong setting.  Most potential files usually use "metal" units, but some
+are parameterized for other settings, most notably :doc:`ReaxFF
+potentials <pair_reaxff>` that use "real" units.
+
+Also, individual parameters for :doc:`pair_coeff <pair_coeff>` commands
+taken from publications or other MD software, may need to be converted
+and sometimes in unexpected ways.  Thus some careful checking is
+recommended.
+
+No error message printed
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+In some cases - especially when running in parallel with MPI - LAMMPS
+may stop without displaying an error.  But that does not mean, that
+there was no error message, instead it is highly likely that the message
+was written to a buffer and LAMMPS was aborted before the buffer was
+output.  Usually, output buffers are output for every line of output,
+but sometimes, this is delayed until 4096 or 8192 bytes of output have
+been accumulated.  This buffering for screen and logfile output can be
+disabled by using the :ref:`-nb or -nonbuf <nonbuf>` command-line flag.
+This is most often needed when debugging crashing multi-replica
+calculations.
+
+------
 
 .. _err0001:
 
@@ -54,3 +217,153 @@ 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.
+
+.. _err0004:
+
+Out of range atoms - cannot compute ...
+---------------------------------------
+
+The PPPM (and also PPPMDisp and MSM) methods require to assemble a grid
+of electron density data derived from the (partial) charges assigned to
+the atoms.  This charges are smeared out across multiple grid points
+(see :doc:`kspace_modify order <kspace_modify>`).  When running in
+parallel with MPI, LAMMPS uses a :doc:`domain decomposition scheme
+<Developer_par_part>` where each processor manages a subset of atoms and
+thus also a grid representing the density, which covers the actual
+volume of the sub-domain and some extra space corresponding to the
+:doc:`neighbor list skin <neighbor>`.  These are then :doc:`combined and
+redistributed <Developer_par_long>` for parallel processing of the
+long-range component of the Coulomb interaction.
+
+The ``Out of range atoms`` error can happen, when atoms move too fast or
+the neighbor list skin is too small or the neighbor lists are not
+updated frequently enough.  Then the smeared charges cannot be fully
+assigned to the density grid for all atoms.  LAMMPS checks for this
+condition and stops with an error.  Most of the time, this is an
+indication of a system with very high forces, most often at the
+beginning of a simulation or when boundary conditions are changed.  The
+error becomes more likely with more MPI processes.
+
+There are multiple options to explore for avoiding the error.  The best
+choice depends strongly on the individual system, and often a
+combination of changes is required.  For example, more conservative MD
+parameter settings can be used (larger neighbor skin, shorter time step,
+more frequent neighbor list updates).  Sometimes, it helps to revisit
+the system generation and avoid close contacts when building it, or use
+the :doc:`delete_atoms overlap<delete_atoms>` command to delete those
+close contact atoms, or run a minimization before the MD.  It can also
+help to temporarily use a cutoff-Coulomb pair style and no kspace style
+until the system has somewhat equilibrated and then switch to the
+long-range solver.
+
+.. _err0009:
+
+Too many neighbor bins
+----------------------
+
+The simulation box has become too large relative to the size of a
+neighbor bin and LAMMPS is unable to store the needed number of
+bins. This typically implies the simulation box has expanded too far.
+This can happen when some atoms move rapidly apart with shrink-wrap
+boundaries or when a fix (like fix deform or a barostat) excessively
+grows the simulation box.
+
+.. _err0015:
+
+Cannot use neighbor bins - box size \<\< cutoff
+-----------------------------------------------
+
+LAMMPS is unable to build neighbor bins since the size of the box is
+much smaller than an interaction cutoff in at least one of its dimensions.
+Typically, this error is triggered when the simulation box has one very
+thin dimension. If a cubic neighbor bin had to fit exactly within
+the thin dimension, then an inordinate amount of bins would be created to
+fill space. This error can be avoided using the generally slower
+:doc:`nsq neighbor style <neighbor>` or by increasing the size of the
+smallest box lengths.
+
+.. _err0017:
+
+Domain too large for neighbor bins
+----------------------------------
+
+The domain has become extremely large so that neighbor bins cannot
+be used. Too many neighbor bins would need to be created to fill space
+Most likely, one or more atoms have been blown out of the simulation
+box to a great distance or a fix (like fix deform or a barostat) has
+excessively grown the simulation box.
+
+.. _err0024:
+
+Molecule topology/atom exceeds system topology/atom
+---------------------------------------------------
+
+LAMMPS uses :doc:`domain decomposition <Developer_par_part>` to
+distribute data (i.e. atoms) across the MPI processes in parallel runs.
+This includes topology data, that is data about bonds, angles,
+dihedrals, impropers and :doc:`"special" neighbors <special_bonds>`.
+This information is stored with either one or all atoms involved in such
+a topology entry (which of the two option applies depends on the
+:doc:`newton <newton>` setting for bonds. When reading a data file,
+LAMMPS analyzes the requirements for this file and then the values
+are "locked in" and cannot be extended.
+
+So loading a molecule file that requires more of the topology per atom
+storage or adding a data file with such needs will lead to an error.  To
+avoid the error, one or more of the `extra/XXX/per/atom` keywords are
+required to extend the corresponding storage.  It is no problem to
+choose those numbers generously and have more storage reserved than
+actually needed, but having these numbers set too small will lead to an
+error.
+
+.. _err0025:
+
+Molecule topology type exceeds system topology type
+---------------------------------------------------
+
+The total number of atom, bond, angle, dihedral, and improper types is
+"locked in" when LAMMPS creates the simulation box. This can happen
+through either the :doc:`create_box <create_box>`, the :doc:`read_data
+<read_data>`, or the :doc:`read_restart <read_restart>` command.  After
+this it is not possible to refer to an additional type. So loading a
+molecule file that uses additional types or adding a data file that
+would require additional types will lead to an error.  To avoid the
+error, one or more of the `extra/XXX/types` keywords are required to
+extend the maximum number of the individual types.
+
+.. _err0026:
+
+Molecule attributes do not match system attributes
+--------------------------------------------------
+
+Choosing an :doc:`atom_style <atom_style>` in LAMMPS determines which
+per-atom properties are available.  In a :doc:`molecule file
+<molecule>`, however, it is possible to add sections (for example Masses
+or Charges) that are not supported by the atom style.  Masses for
+example, are usually not a per-atom property, but defined through the
+atom type.  Thus it would not be required to have a Masses section and
+the included data would be ignored.  LAMMPS prints this warning to
+inform about this case.

doc/src/Errors_messages.rst

@@ -96,13 +96,13 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
    are too far apart to make a valid angle.
 
 *Angle atoms %d %d %d missing on proc %d at step %ld*
-   One or more of 3 atoms needed to compute a particular angle are
+   One or more of three atoms needed to compute a particular angle are
    missing on this processor.  Typically this is because the pairwise
    cutoff is set too short or the angle has blown apart and an atom is
    too far away.
 
 *Angle atoms missing on proc %d at step %ld*
-   One or more of 3 atoms needed to compute a particular angle are
+   One or more of three atoms needed to compute a particular angle are
    missing on this processor.  Typically this is because the pairwise
    cutoff is set too short or the angle has blown apart and an atom is
    too far away.
@@ -1932,7 +1932,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
    Self-explanatory.
 
 *Compute chunk/atom fix array is accessed out-of-range*
-   the index for the array is out of bounds.
+   The index for the array is out of bounds.
 
 *Compute chunk/atom fix does not calculate a per-atom array*
    Self-explanatory.
@@ -6073,9 +6073,9 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
 *New atom IDs exceed maximum allowed ID*
    See the setting for tagint in the src/lmptype.h file.
 
-*New bond exceeded bonds per atom in create_bonds*
-See the read_data command for info on using the "extra/bond/per/atom"
-keyword to allow for additional bonds to be formed
+*New bond exceeded bonds per atom in create\_bonds*
+   See the read_data command for info on using the "extra/bond/per/atom"
+   keyword to allow for additional bonds to be formed
 
 *New bond exceeded bonds per atom in fix bond/create*
    See the read_data command for info on using the "extra/bond/per/atom"
@@ -7310,12 +7310,12 @@ keyword to allow for additional bonds to be formed
    atom has moved too far.
 
 *Restrain atoms %d %d %d missing on proc %d at step %ld*
-   The 3 atoms in a restrain angle specified by the fix restrain
+   The three atoms in a restrain angle specified by the fix restrain
    command are not all accessible to a processor.  This probably means an
    atom has moved too far.
 
 *Restrain atoms %d %d missing on proc %d at step %ld*
-   The 2 atoms in a restrain bond specified by the fix restrain
+   The two atoms in a restrain bond specified by the fix restrain
    command are not all accessible to a processor.  This probably means an
    atom has moved too far.
 
@@ -7406,7 +7406,7 @@ keyword to allow for additional bonds to be formed
 *Shake angles have different bond types*
    All 3-atom angle-constrained SHAKE clusters specified by the fix shake
    command that are the same angle type, must also have the same bond
-   types for the 2 bonds in the angle.
+   types for the two bonds in the angle.
 
 *Shake atoms %d %d %d %d missing on proc %d at step %ld*
    The 4 atoms in a single shake cluster specified by the fix shake
@@ -7414,12 +7414,12 @@ keyword to allow for additional bonds to be formed
    an atom has moved too far.
 
 *Shake atoms %d %d %d missing on proc %d at step %ld*
-   The 3 atoms in a single shake cluster specified by the fix shake
+   The three atoms in a single shake cluster specified by the fix shake
    command are not all accessible to a processor.  This probably means
    an atom has moved too far.
 
 *Shake atoms %d %d missing on proc %d at step %ld*
-   The 2 atoms in a single shake cluster specified by the fix shake
+   The two atoms in a single shake cluster specified by the fix shake
    command are not all accessible to a processor.  This probably means
    an atom has moved too far.
 
@@ -7774,7 +7774,7 @@ keyword to allow for additional bonds to be formed
 *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.