Merge branch 'develop' into bond/react-molmap_option

2025-03-30 23:27:50 -04:00
parent 05521d38d9 285baf27b5
commit 935e323d08
2010 changed files with 177765 additions and 51686 deletions
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@ -72,6 +72,8 @@ 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
 src/EXTRA-PAIR/pair_dispersion_d3.* @soniasolomoni @arthurfl
 src/EXTRA-PAIR/d3_parameters.h      @soniasolomoni @arthurfl
 src/MISC/*_tracker.*                @jtclemm
 src/MC/fix_gcmc.*                   @athomps
 src/MC/fix_sgcmc.*                  @athomps
--- a/.github/release_steps.md
+++ b/.github/release_steps.md
@ -1,42 +1,54 @@
 # LAMMPS Release Steps
-The following notes chronicle the current steps for preparing and publishing LAMMPS releases.  For
+The following notes chronicle the current steps for preparing and
-definitions of LAMMPS versions and releases mean, please refer to [the corresponding section in the
+publishing LAMMPS releases.  For definitions of LAMMPS versions and
-LAMMPS manual](https://docs.lammps.org/Manual_version.html).
+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'
+A LAMMPS feature release is currently prepared after about 500 to 750
-branch or after a period of four weeks up to two months.  This is not a fixed rule, though, since
+commits to the 'develop' branch or after a period of four weeks up to
-external circumstances can cause delays in preparing a release, or pull requests that are desired to
+two months.  This is not a fixed rule, though, since external
-be merged for the release are not yet completed.
+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
+- set the LAMMPS\_VERSION define to the planned release date in
-  "D Mmm YYYY" or "DD Mmm YYYY"
+  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
+- update all TBD arguments for ..versionadded::, ..versionchanged::
-  planned release date in the format "DMmmYYYY" or "DDMmmYYYY"
+  ..deprecated:: to the planned release date in the format "DMmmYYYY" or
- check release notes for merged new features and check if ..versionadded:: or ..versionchanged::
+  "DDMmmYYYY"
-  are missing and need to be added
+- check release notes for merged new features and check if
-Submit this pull request, rebase if needed.  This is the last pull request merged for the release
+  ..versionadded:: or ..versionchanged:: are missing and need to be
-and should not contain any other changes. (Exceptions: this document, last minute trivial(!) changes).
+  added
-This PR shall not be merged before **all** pending tests have completed and cleared. If needed, a
+Submit this pull request.  This is the last pull request merged for the
-bugfix pull request should be created and merged to clear all tests.
+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 bug-fix 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
+When all pending pull requests for the release are merged and have
-'next\_release' branch is merged into 'develop'.
+cleared testing, the 'next\_release' branch is merged into 'develop'.
-Check out 'develop' locally, pull the latest changes, merge them into 'release', apply a suitable
+Check out or update the 'develop' branch locally, pull the latest
-release tag (for historical reasons the tag starts with "patch_" followed by the date, and finally
+changes, merge them into 'release' with a fast forward(!) merge, and
-push everything back to GitHub. Example:
+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
@ -44,65 +56,315 @@ 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 tag -s -m "LAMMPS feature release 4 February 2025" patch_4Feb2025
 git push git@github.com:lammps/lammps.git --tags develop release
 ```
-Go to https://github.com/lammps/lammps/releases and create a new (draft) release page or check the
+Applying this tag will trigger two actions on the Temple Jenkins cluster:
-existing draft for any necessary changes from pull requests that were merged but are not listed.
+- The online manual at https://docs.lammps.org/ will be updated to the
-Then select the applied tag for the release in the "Choose a tag" dropdown list. Go to the bottom of
+  state of the 'release' branch.  Merges to the 'develop' branch will
-the list and select the "Set as pre-release" checkbox.  The "Set as the latest release" button is
+  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" drop-down 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
+If everything is in order, you can click on the "Publish release"
-draft" and finish pending tasks until you can return to edit the release page and publish it.
+button.  Otherwise, click on "Save draft" and finish pending tasks until
 you can return to edit the release page and publish it.
-### Update download website, prepare pre-compiled packages, update packages to GitHub
+### Prepare pre-compiled packages, update packages to GitHub
-Publishing the release on GitHub will trigger the Temple Jenkins cluster to update
+A suitable build environment is provided with the
-the https://docs.lammps.org/ website with the documentation for the new feature release
+https://download.lammps.org/static/fedora41_musl_mingw.sif container
-and it will create a tarball for download (which contains the translated manual).
+image.  The corresponding container build definition file is maintained
 in the tools/singularity folder of the LAMMPS source distribution.
-Build a fully static LAMMPS installation using a musl-libc cross-compiler, install into a
+#### Fully portable static Linux x86_64 non-MPI binaries
-lammps-static folder, and create a tarball called lammps-linux-x86_64-19Nov2024.tar.gz (or using a
+
-corresponding date with a future release) from the lammps-static folder and upload it to GitHub
+The following commands use the Fedora container to build a fully static
 LAMMPS installation using a musl-libc cross-compiler, install it into a
 `lammps-static` folder, and create a tarball called
 `lammps-linux-x86_64-4Feb2025.tar.gz` (or using a corresponding date
 with a future release) from the `lammps-static` folder.
 ``` 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-4Feb2025.tar.gz lammps-static
 exit # fedora 41 container
 cd ..
 ```
 The resulting tar archive can be uploaded to the GitHub release page with:
 ``` sh
 gh release upload patch_4Feb2025 lammps-linux-x86_64-4Feb2025.tar.gz
 ```
 #### Linux x86_64 Flatpak bundle with GUI included
 Make sure you have the `flatpak` and `flatpak-builder` packages
 installed locally (they require binaries that run with elevated
 privileges and thus cannot be used from the container) and build a
 LAMMPS and LAMMPS-GUI flatpak bundle in the `release-packages` folder
 with:
-```
+``` sh
-gh release upload patch_19Nov2024 ~/Downloads/lammps-linux-x86_64-19Nov2024.tar.gz
+cd release-packages
 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-4Feb2025.flatpak org.lammps.lammps-gui release
 cd ..
 ```
 The resulting flatpak bundle file can be uploaded to the GitHub release page with:
 ``` sh
 gh release upload patch_4Feb2025 LAMMPS-Linux-x86_64-GUI-4Feb2025.flatpak
 ```
 #### LAMMPS Source tarball
 The container for the static binary can also be used to prepare the source
 tarball including the HTML and PDF manual (this is currently done automatically
 when the releases is created and the tarball uploaded to https://download.lammps.org/tars/).
 The steps are as follows:
 ``` sh
 cd release-packages
 apptainer shell fedora41_musl_mingw.sif
 cd lammps-release
 rm -f ../release.tar*
 git archive --output=../release.tar --prefix=lammps-4Feb2025/ HEAD
 cd doc
 make clean-all
 make html pdf
 tar -rf ../../release.tar --transform 's,^,lammps-4Feb2025/doc/,' html Manual.pdf
 gzip -9v ../../release.tar
 mv ../../release.tar.gz ../../lammps-src-4Feb2025.tar.gz
 exit # fedora41 container
 cd ..
 ```
 The resulting source tarball can be uploaded to the GitHub release page with:
 ``` sh
 gh release upload patch_4Feb2025 lammps-src-4Feb2025.tar.gz
 ```
 #### Build Windows Installer Packages with MinGW Linux-to-Windows Cross-compiler
 The various Windows installer packages can also be built with
 apptainer container image.
 ``` sh
 cd release-packages
 apptainer shell fedora41_musl_mingw.sif
 git clone --depth 10 https://github.com/lammps/lammps-packages.git lammps-packages
 cd lammps-packages/mingw-cross
 ln -sf ../../lammps-release lammps
 ./buildall.sh release >& mk.log & less +F mk.log
 ```
 The installer with the GUI included can be uploaded to the GitHub release page with:
 ``` sh
 ln -sf LAMMPS-64bit-GUI-4Feb2025.exe LAMMPS-Win10-64bit-GUI-4Feb2025.exe
 gh release upload patch_4Feb2025 LAMMPS-Win10-64bit-GUI-4Feb2025.exe
 ```
 The symbolic link is used to have a consistent naming scheme for the packages
 attached to the GitHub release page.
 #### Clean up:
 ``` sh
 cd ..
 rm -r release-packages
 ```
 #### Build Multi-arch App-bundle for macOS
 Building app-bundles for macOS is not as easily automated and portable
 as some of the other steps.  It requires a machine actually running
 macOS.  In that machine the Xcode compiler package needs to be
 installed. This also includes tools for building and manipulating disk
 images.  This compiler supports building executables for both, the
 x86_64 and the arm64 architectures.  This requires building with CMake
 and using the CMake settings:
 ``` sh
 -D CMAKE_OSX_ARCHITECTURES=arm64;x86_64
 -D CMAKE_OSX_DEPLOYMENT_TARGET=11.0
 ```
 This will add the compiler flags `-arch arm64 -arch x86_64
 -mmacosx-version-min=11.0` and thus produce object for both
 architectures and support for macOS versions back to version 11 (aka Big
 Sur).  With these settings the following libraries should be compiled
 and installed (e.g. to `$HOME/.local`) as static libraries only:
 - libomp taken from the LLVM/Clang source distribution (to support OpenMP)
 - jpeg
 - zlib
 - png
 - Qt (for LAMMPS-GUI)
 When configuring LAMMPS the `cmake/presets/clang.cmake` should be used
 and as many packages as possible enabled. For LAMMPS-GUI, MPI should be
 disabled with `-D BUILD_MPI=OFF` and LAMMPS-GUI enabled with 
 `-D BUILD_LAMMPS_GUI=ON`.  If the CMake configuration is successful,
 settings for building a macOS app-bundle are enabled and with `cmake
 --build build --target dmg` extra steps will be executed that will build
 a macOS application installer image under the name
 `LAMMPS_GUI-macOS-multiarch-4Feb2025.dmg`
 The application image can be uploaded to the GitHub release page with:
 ``` sh
 ln -sf LAMMPS_GUI-macOS-multiarch-4Feb2025.dmg LAMMPS-macOS-multiarch-GUI-4Feb2025.dmg
 gh release upload patch_4Feb2025 LAMMPS-macOS-multiarch-GUI-4Feb2025.dmg
 ```
 The symbolic link is used to have a consistent naming scheme for the packages
 attached to the GitHub release page.
 We are currently building the application images on macOS 12 (aka Monterey).
 #### Build Linux x86_64 binary tarball on Ubuntu 20.04LTS
 While the flatpak Linux version uses portable runtime libraries provided
 by the flatpak environment, we also build regular Linux executables that
 use a wrapper script and matching shared libraries in a tarball.  To be
 compatible with many Linux distributions, one has to build this on a
 very old Linux distribution, since most Linux system libraries are
 usually backward compatible but not forward compatible.  This is
 currently done on an Ubuntu 20.04LTS system. Once LAMMPS moves to
 require CMake 3.20 and C++17, we will have to move to Ubuntu 22.04LTS.
 This installation (either on a real or a virtual machine) should have
 the packages installed that are indicated in
 `tools/singularity/ubuntu20.04.def` plus Qt version 5.x with development
 headers, so that LAMMPS-GUI can be compiled.
 Also the building of the binary tarball and setup of the bundled
 libraries and wrapper scripts is automated and can executed with `cmake
 --build build --target tgz`.  This should produce a file
 `LAMMPS_GUI-Linux-amd64-4Feb2025.tar.gz` which can be uploaded to the
 GitHub release page with:
 ``` sh
 ln -sf LAMMPS_GUI-Linux-amd64-4Feb2025.tar.gz LAMMPS-Linux-x86_64-GUI-4Feb2025.tar.gz
 gh release upload patch_4Feb2025 LAMMPS-Linux-x86_64-GUI-4Feb2025.tar.gz
 ```
 ### Update download page on LAMMPS 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.
 Also 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.
+A LAMMPS stable release is prepared about once per year in the months
-One (or two, if needed) feature releases before the stable release shall contain only bug fixes
+July, August, or September.  One (or two, if needed) feature releases
-or minor feature updates in optional packages.  Also substantial changes to the core of the code
+before the stable release shall contain only bug fixes or minor feature
-shall be applied rather toward the beginning of a development cycle between two stable releases
+updates in optional packages.  Also substantial changes to the core of
-than toward the end.  The intention is to stablilize significant change to the core and have
+the code shall be applied rather toward the beginning of a development
-outside users and developers try them out during the development cycle; the sooner the changes
+cycle between two stable releases than toward the end.  The intention is
-are included, the better chances for spotting peripheral bugs and issues.
+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)
+Before making a stable release all remaining backported bugfixes shall
-stable update release (see below).
+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
+A LAMMPS stable release process starts like a feature release (see
-release is called a "Stable Release Candidate" and no assets are uploaded to GitHub.
+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
+The state of the 'release' branch is then transferred to the
-have diverged significantly from 'release' due to the selectively backported bug fixes).
+'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'
+At this point it should be possible to do a fast-forward merge of
-and then apply the stable\_DMmmYYYY tag.
+'maintenance' to 'stable' and then apply the stable\_DMmmYYYY tag.
 ### Push branches and tags
 ## LAMMPS Stable Update Release
 After making a stable release, bugfixes from the 'develop' branch
 are selectively backported to the 'maintenance' branch.  This is
 done with "git cherry-pick \<commit hash\>' wherever possible.
 The LAMMPS\_UPDATE define in "src/version.h" is set to "Maintenance".
 ### Prerequesites
 When a sufficient number of bugfixes has accumulated or an urgent
 or important bugfix needs to be distributed a new stable update
 release is made.  To make this publicly visible a pull request
 is submitted that will merge 'maintenance' into 'stable'.  Before
 merging, set LAMMPS\_UPDATE in "src/version.h" to "Update #" with
 "#" indicating the update count (1, 2, and so on).
 Also draft suitable release notes under https://github.com/lammps/lammps/releases
 ### Fast-forward merge of 'maintenance' into 'stable', apply tag, and publish
 Do a fast-forward merge of 'maintenance' to 'stable' and then
 apply the stable\_DMmmYYYY\_update# tag and push branch and tag
 to GitHub. The corresponding pull request will be automatically
 closed.   Example:
 ```
 git checkout maintenance
 git pull
 git checkout stable
 git pull
 git merge --ff-only maintenance
 git tag -s -m 'Update 2 for Stable LAMMPS version 29 August 2024' stable_29Aug2024_update2
 git push git@github.com:lammps/lammps.git --tags maintenance stable
 ```
 Associate draft release notes with new tag and publish as "latest release".
 On https://ci.lammps.org/ go to "dev", "stable" and manually execute
 the "update\_release" task. This will update https://docs.lammps.org/stable
 and prepare a stable tarball.
 ### Build and upload binary packages and source tarball to GitHub
 The build procedure is the same as for the feature releases, only
 that packages are built from the 'stable' branch.
--- a/.github/workflows/check-vla.yml
+++ b/.github/workflows/check-vla.yml
@ -77,7 +77,7 @@ jobs:
              -D PKG_MDI=on \
              -D PKG_MANIFOLD=on \
              -D PKG_ML-PACE=on \
-              -D PKG_ML-RANN=off \
+              -D PKG_ML-RANN=on \
              -D PKG_MOLFILE=on \
              -D PKG_RHEO=on \
              -D PKG_PTM=on \
--- a/.github/workflows/coverity.yml
+++ b/.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 \
--- a/.github/workflows/lammps-gui-flatpak.yml
+++ b/.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
--- a/.github/workflows/style-check.yml
+++ b/.github/workflows/style-check.yml
@ -35,3 +35,4 @@ jobs:
         make check-permissions
         make check-homepage
         make check-errordocs
         make check-fmtlib
--- a/.github/workflows/unittest-arm64.yml
+++ b/.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
--- a/15
+++ b/15
@ -23,17 +23,20 @@ more information about the code and its uses.
 The LAMMPS distribution includes the following files and directories:
 README                     this file
-LICENSE                    the GNU General Public License (GPL)
+LICENSE                    the GNU General Public License (GPLv2)
-bench                      benchmark problems
+CITATION.cff               Citation information for LAMMPS in CFF format
 bench                      benchmark inputs
 cmake                      CMake build files
 doc                        documentation
-examples                   simple test problems
+examples                   example inputs for many LAMMPS commands
-fortran                    Fortran wrapper for LAMMPS
+fortran                    Fortran 2003 module for LAMMPS
 lib                        additional provided or external libraries
 potentials                 interatomic potential files
-python                     Python wrappers for LAMMPS
+python                     Python module for LAMMPS
 src                        source files
 tools                      pre- and post-processing tools
 unittest                   test programs for use with CTest
 .github                    Git and GitHub related files and tools
 Point your browser at any of these files to get started:
@ -42,6 +45,8 @@ https://docs.lammps.org/Intro.html          hi-level introduction
 https://docs.lammps.org/Build.html          how to build LAMMPS
 https://docs.lammps.org/Run_head.html       how to run LAMMPS
 https://docs.lammps.org/Commands_all.html   Table of available commands
 https://docs.lammps.org/Howto.html          Short tutorials and HowTo discussions
 https://docs.lammps.org/Errors.html         How to interpret and debug errors
 https://docs.lammps.org/Library.html        LAMMPS library interfaces
 https://docs.lammps.org/Modify.html         how to modify and extend LAMMPS
 https://docs.lammps.org/Developer.html      LAMMPS developer info
--- a/cmake/CMakeLists.txt
+++ b/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)
@ -144,16 +147,28 @@ if((PKG_KOKKOS) AND (Kokkos_ENABLE_CUDA) AND NOT (CMAKE_CXX_COMPILER_ID STREQUAL
  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)
  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
@ -194,7 +209,7 @@ endif()
 ########################################################################
 # User input options                                                   #
 ########################################################################
-# backward compatibility with CMake before 3.12 and older LAMMPS documentation
+# backward compatibility with older LAMMPS documentation
 if (PYTHON_EXECUTABLE)
  set(Python_EXECUTABLE "${PYTHON_EXECUTABLE}")
 endif()
@ -210,6 +225,12 @@ if(DEFINED ENV{VIRTUAL_ENV} AND NOT Python_EXECUTABLE)
    "   Setting Python interpreter to: ${Python_EXECUTABLE}")
 endif()
 find_package(Python COMPONENTS Interpreter QUIET)
 # NOTE: RHEL 8.0 and Ubuntu 18.04LTS ship with Python 3.6, Python 3.8 was EOL in 2024
 if(Python_VERSION VERSION_LESS 3.6)
  message(FATAL_ERROR "LAMMPS requires Python 3.6 or later")
 endif()
 set(LAMMPS_MACHINE "" CACHE STRING "Suffix to append to lmp binary (WON'T enable any features automatically")
 mark_as_advanced(LAMMPS_MACHINE)
 if(LAMMPS_MACHINE)
@ -347,6 +368,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
 ######################################################
@ -399,8 +431,8 @@ else()
  target_link_libraries(lammps PUBLIC mpi_stubs)
 endif()
-set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallsmall: all 32-bit, smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
+set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
-set(LAMMPS_SIZES_VALUES smallbig bigbig smallsmall)
+set(LAMMPS_SIZES_VALUES smallbig bigbig)
 set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
 validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
 string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)
@ -579,6 +611,16 @@ foreach(PKG_WITH_INCL KSPACE PYTHON ML-IAP VORONOI COLVARS ML-HDNNP MDI MOLFILE
  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)
@ -894,7 +936,7 @@ endif()
 include(Testing)
 include(CodeCoverage)
 include(CodingStandard)
-find_package(ClangFormat 11.0)
+find_package(ClangFormat 11.0 QUIET)
 if(ClangFormat_FOUND)
  add_custom_target(format-src
--- a/cmake/Modules/CodingStandard.cmake
+++ b/cmake/Modules/CodingStandard.cmake
@ -1,11 +1,11 @@
-# use default (or custom) Python executable, if version is sufficient
+# use default (or custom) Python executable.
-if(Python_VERSION VERSION_GREATER_EQUAL 3.6)
+# Python version check is in main CMakeLists.txt file
 if(Python_EXECUTABLE)
  set(Python3_EXECUTABLE ${Python_EXECUTABLE})
 endif()
 find_package(Python3 COMPONENTS Interpreter)
 if(Python3_EXECUTABLE)
    if(Python3_VERSION VERSION_GREATER_EQUAL 3.6)
  add_custom_target(
    check-whitespace
    ${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/whitespace.py .
@ -37,4 +37,3 @@ if(Python3_EXECUTABLE)
    WORKING_DIRECTORY  ${LAMMPS_DIR}
    COMMENT "Fix permission errors")
 endif()
 endif()
--- a/cmake/Modules/Documentation.cmake
+++ b/cmake/Modules/Documentation.cmake
@ -13,7 +13,7 @@ if(BUILD_DOC)
  endif()
  find_package(Python3 REQUIRED COMPONENTS Interpreter)
  if(Python3_VERSION VERSION_LESS 3.8)
-    message(FATAL_ERROR "Python 3.8 and up is required to build the HTML documentation")
+    message(FATAL_ERROR "Python 3.8 and up is required to build the LAMMPS HTML documentation")
  endif()
  set(VIRTUALENV ${Python3_EXECUTABLE} -m venv)
@ -65,8 +65,8 @@ if(BUILD_DOC)
    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_URL "https://github.com/mathjax/MathJax/archive/3.2.2.tar.gz" CACHE STRING "URL for MathJax tarball")
-  set(MATHJAX_MD5 "b81661c6e6ba06278e6ae37b30b0c492" CACHE STRING "MD5 checksum of MathJax tarball")
+  set(MATHJAX_MD5 "08dd6ef33ca08870220d9aade2a62845" CACHE STRING "MD5 checksum of MathJax tarball")
  mark_as_advanced(MATHJAX_URL)
  GetFallbackURL(MATHJAX_URL MATHJAX_FALLBACK)
--- a/cmake/Modules/LAMMPSInterfacePlugin.cmake
+++ b/cmake/Modules/LAMMPSInterfacePlugin.cmake
@ -34,8 +34,26 @@ if(MSVC)
  add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
 endif()
-# C++11 is required
+if(NOT CMAKE_CXX_STANDARD)
  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)
 # Need -restrict with Intel compilers
@ -242,8 +260,8 @@ endif()
 ################
 # integer size selection
-set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallsmall: all 32-bit, smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
+set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
-set(LAMMPS_SIZES_VALUES smallbig bigbig smallsmall)
+set(LAMMPS_SIZES_VALUES smallbig bigbig)
 set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
 validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
 string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)
--- a/cmake/Modules/Packages/INTEL.cmake
+++ b/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})
--- a/cmake/Modules/Packages/KOKKOS.cmake
+++ b/cmake/Modules/Packages/KOKKOS.cmake
@ -7,26 +7,13 @@ endif()
 ########################################################################
 # consistency checks and Kokkos options/settings required by LAMMPS
 if(Kokkos_ENABLE_CUDA)
  option(Kokkos_ENABLE_IMPL_CUDA_MALLOC_ASYNC "CUDA asynchronous malloc support" OFF)
  mark_as_advanced(Kokkos_ENABLE_IMPL_CUDA_MALLOC_ASYNC)
  if(Kokkos_ENABLE_IMPL_CUDA_MALLOC_ASYNC)
    message(STATUS "KOKKOS: CUDA malloc async support enabled")
  else()
    message(STATUS "KOKKOS: CUDA malloc async support disabled")
  endif()
 endif()
 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()
  if(Kokkos_ARCH_AMD_GFX942 OR Kokkos_ARCH_AMD_GFX940)
    option(Kokkos_ENABLE_IMPL_HIP_UNIFIED_MEMORY "Enable unified memory with HIP" ON)
    mark_as_advanced(Kokkos_ENABLE_IMPL_HIP_UNIFIED_MEMORY)
  endif()
 endif()
 # Adding OpenMP compiler flags without the checks done for
 # BUILD_OMP can result in compile failures. Enforce consistency.
 if(Kokkos_ENABLE_OPENMP)
@ -70,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.4.01.tar.gz" CACHE STRING "URL for 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 "de6ee80d00b6212b02bfb7f1e71a8392" CACHE STRING "MD5 checksum of 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)
@ -96,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.4.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)
@ -130,7 +117,6 @@ set(KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/kokkos.cpp
                       ${KOKKOS_PKG_SOURCES_DIR}/atom_vec_kokkos.cpp
                       ${KOKKOS_PKG_SOURCES_DIR}/comm_kokkos.cpp
                       ${KOKKOS_PKG_SOURCES_DIR}/comm_tiled_kokkos.cpp
                       ${KOKKOS_PKG_SOURCES_DIR}/group_kokkos.cpp
                       ${KOKKOS_PKG_SOURCES_DIR}/min_kokkos.cpp
                       ${KOKKOS_PKG_SOURCES_DIR}/min_linesearch_kokkos.cpp
                       ${KOKKOS_PKG_SOURCES_DIR}/neighbor_kokkos.cpp
--- a/cmake/Modules/Packages/ML-IAP.cmake
+++ b/cmake/Modules/Packages/ML-IAP.cmake
@ -24,9 +24,7 @@ if(MLIAP_ENABLE_PYTHON)
  if(NOT PKG_PYTHON)
    message(FATAL_ERROR "Must enable PYTHON package for including Python support in ML-IAP")
  endif()
-  if(Python_VERSION VERSION_LESS 3.6)
+  # Python version check is in main CMakeLists.txt file
    message(FATAL_ERROR "Python support in ML-IAP requires Python 3.6 or later")
  endif()
  set(MLIAP_BINARY_DIR ${CMAKE_BINARY_DIR}/cython)
  file(GLOB MLIAP_CYTHON_SRC CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/ML-IAP/*.pyx)
--- a/cmake/Modules/Packages/ML-PACE.cmake
+++ b/cmake/Modules/Packages/ML-PACE.cmake
@ -1,12 +1,17 @@
 # PACE library support for ML-PACE package
 find_package(pace QUIET)
 if(pace_FOUND)
    find_package(pace)
    target_link_libraries(lammps PRIVATE pace::pace)
 else()
    # set policy to silence warnings about timestamps of downloaded files. review occasionally if it may be set to NEW
    if(POLICY CMP0135)
      cmake_policy(SET CMP0135 OLD)
    endif()
-set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.11.25.fix.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
+    set(PACELIB_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 "b45de9a633f42ed65422567e3ce56f9f" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
+    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)
@ -42,9 +47,16 @@ else()
      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()
--- a/cmake/Modules/Packages/ML-QUIP.cmake
+++ b/cmake/Modules/Packages/ML-QUIP.cmake
@ -37,7 +37,7 @@ if(DOWNLOAD_QUIP)
  endforeach()
  # Fix cmake crashing when MATH_LINKOPTS not set, required for e.g. recent Cray Programming Environment
  set(temp "${temp} -L/_DUMMY_PATH_\n")
-  set(temp "${temp}PYTHON=python\nPIP=pip\nEXTRA_LINKOPTS=\n")
+  set(temp "${temp}PYTHON=${Python_EXECUTABLE}\nPIP=pip\nEXTRA_LINKOPTS=\n")
  set(temp "${temp}HAVE_CP2K=0\nHAVE_VASP=0\nHAVE_TB=0\nHAVE_PRECON=1\nHAVE_LOTF=0\nHAVE_ONIOM=0\n")
  set(temp "${temp}HAVE_LOCAL_E_MIX=0\nHAVE_QC=0\nHAVE_GAP=1\nHAVE_DESCRIPTORS_NONCOMMERCIAL=1\n")
  set(temp "${temp}HAVE_TURBOGAP=0\nHAVE_QR=1\nHAVE_THIRDPARTY=0\nHAVE_FX=0\nHAVE_SCME=0\nHAVE_MTP=0\n")
--- a/cmake/Modules/Packages/PLUMED.cmake
+++ b/cmake/Modules/Packages/PLUMED.cmake
@ -32,14 +32,21 @@ 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.2/plumed-src-2.9.2.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 "04862602a372c1013bdfee2d6d03bace" 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)
 GetFallbackURL(PLUMED_URL PLUMED_FALLBACK)
 # adjust C++ standard support for self-compiled Plumed2
 if(CMAKE_CXX_STANDARD GREATER 11)
  set(PLUMED_CXX_STANDARD 14)
 else()
  set(PLUMED_CXX_STANDARD 11)
 endif()
 if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND (CMAKE_CROSSCOMPILING))
  if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
    set(CROSS_CONFIGURE mingw64-configure)
@ -55,7 +62,7 @@ if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND (CMAKE_CROSSCOMPILING))
    URL_MD5 ${PLUMED_MD5}
    BUILD_IN_SOURCE 1
    CONFIGURE_COMMAND ${CROSS_CONFIGURE} --disable-shared --disable-bsymbolic
-                                         --disable-python --enable-cxx=11
+                                         --disable-python --enable-cxx=${PLUMED_CXX_STANDARD}
                                         --enable-modules=-adjmat:+crystallization:-dimred:+drr:+eds:-fisst:+funnel:+logmfd:+manyrestraints:+maze:+opes:+multicolvar:-pamm:-piv:+s2cm:-sasa:-ves
                                         ${PLUMED_CONFIG_OMP}
                                         ${PLUMED_CONFIG_MPI}
@ -142,7 +149,7 @@ else()
      CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR>
                                             ${CONFIGURE_REQUEST_PIC}
                                             --enable-modules=all
-                                             --enable-cxx=11
+                                             --enable-cxx=${PLUMED_CXX_STANDARD}
                                             --disable-python
                                             ${PLUMED_CONFIG_MPI}
                                             ${PLUMED_CONFIG_OMP}
--- a/cmake/Modules/Packages/PYTHON.cmake
+++ b/cmake/Modules/Packages/PYTHON.cmake
@ -1,6 +1,6 @@
 if(NOT Python_INTERPRETER)
-  # backward compatibility with CMake before 3.12 and older LAMMPS documentation
+  # backward compatibility with older LAMMPS documentation
  if(PYTHON_EXECUTABLE)
    set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
  endif()
--- a/cmake/presets/kokkos-cuda.cmake
+++ b/cmake/presets/kokkos-cuda.cmake
@ -1,6 +1,5 @@
 # preset that enables KOKKOS and selects CUDA compilation with OpenMP
-# enabled as well. This preselects CC 5.0 as default GPU arch, since
+# enabled as well. The GPU architecture *must* match your hardware
 # that is compatible with all higher CC, but not the default CC 3.5
 set(PKG_KOKKOS ON CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_SERIAL ON CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_CUDA   ON CACHE BOOL "" FORCE)
--- a/doc/Makefile
+++ b/doc/Makefile
@ -17,9 +17,11 @@ MATHJAXTAG     = 3.2.2
 PYTHON         = $(word 3,$(shell type python3))
 DOXYGEN        = $(word 3,$(shell type doxygen))
 PANDOC         = $(word 3,$(shell type pandoc))
 HAS_PYTHON3    = NO
 HAS_DOXYGEN    = NO
 HAS_PDFLATEX   = NO
 HAS_PANDOC     = NO
 ifeq ($(shell type python3 >/dev/null 2>&1; echo $$?), 0)
 HAS_PYTHON3    = YES
@ -35,6 +37,10 @@ HAS_PDFLATEX = YES
 endif
 endif
 ifeq ($(shell type pandoc >/dev/null 2>&1; echo $$?), 0)
 HAS_PANDOC     = YES
 endif
 # override settings for PIP commands
 # PIP_OPTIONS = --cert /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt --proxy http://proxy.mydomain.org
@ -45,8 +51,9 @@ SPHINXEXTRA = -j $(shell $(PYTHON) -c 'import multiprocessing;print(multiprocess
 # we only want to use explicitly listed files.
 DOXYFILES      = $(shell sed -n -e 's/\#.*$$//' -e '/^ *INPUT \+=/,/^[A-Z_]\+ \+=/p' doxygen/Doxyfile.in | sed -e 's/@LAMMPS_SOURCE_DIR@/..\/src/g' -e 's/\\//g' -e 's/ \+/ /' -e 's/[A-Z_]\+ \+= *\(YES\|NO\|\)//') 
-.PHONY: help clean-all clean clean-spelling epub mobi html pdf spelling anchor_check style_check char_check role_check xmlgen fasthtml
+.PHONY: help clean-all clean clean-spelling epub mobi html pdf spelling anchor_check style_check char_check role_check xmlgen fasthtml fasthtml-init 
 FASTHTMLFILES = $(patsubst $(RSTDIR)/%.rst,fasthtml/%.html,$(wildcard $(RSTDIR)/*rst))
 # ------------------------------------------
 help:
@ -116,25 +123,23 @@ html: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJ
 	@rm -rf html/PDF/.[sg]*
 	@echo "Build finished. The HTML pages are in doc/html."
-fasthtml: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
+fasthtml: fasthtml-init $(FASTHTMLFILES)
 	@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
 	@(\
 		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/fasthtml/doctrees $(RSTDIR) fasthtml ;\
 		touch $(RSTDIR)/Fortran.rst ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/fasthtml/doctrees $(RSTDIR) fasthtml ;\
 		deactivate ;\
 	)
 	@rm -rf fasthtml/_sources
 	@rm -rf fasthtml/PDF
 	@rm -rf fasthtml/USER
 	@rm -rf fasthtml/JPG
 	@cp -r src/PDF fasthtml/PDF
 	@rm -rf fasthtml/PDF/.[sg]*
 	@echo "Fast HTML build finished. The HTML pages are in doc/fasthtml."
 fasthtml-init:
 	@mkdir -p fasthtml/JPG
 	@cp src/JPG/*.* fasthtml/JPG
 	@cp $(RSTDIR)/accel_styles.rst $(RSTDIR)/lepton_expression.rst fasthtml/
 	@cp $(BUILDDIR)/utils/pandoc.css fasthtml/
 fasthtml/%.html: $(RSTDIR)/%.rst
 	@if [ "$(HAS_PANDOC)" == "NO" ] ; then echo "Make 'fasthtml' requires the 'pandoc' software" 1>&2; exit 1; fi
 	@mkdir -p fasthtml
 	@echo converting $< to $@
 	@sed -e 's/\\AA/\\mathring{\\mathrm{A}}/g' $< > fasthtml/$*.temp.rst
 	@pandoc -s --mathml --css="pandoc.css" --template=$(BUILDDIR)/utils/pandoc.html --metadata title="$@" -o $@ fasthtml/$*.temp.rst
 	@rm -f fasthtml/$*.temp.rst
 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
 	@(\
--- a/doc/README
+++ b/doc/README
@ -22,12 +22,12 @@ doxygen-warn.log  logfile with warnings from running doxygen
 and:
 github-development-workflow.md   notes on the LAMMPS development workflow
 include-file-conventions.md      notes on LAMMPS' include file conventions
 documentation_conventions.md     notes on writing documentation for LAMMPS
 If you downloaded a LAMMPS tarball from www.lammps.org, then the html
 folder and the PDF manual should be included. If you downloaded LAMMPS
-from GitHub then you either need to build them.
+using GitHub then you either need to build them yourself or read the
 online version at https://docs.lammps.org/
 You can build the HTML and PDF files yourself, by typing "make html"
 or by "make pdf", respectively.  This requires various tools and files.
@ -39,10 +39,10 @@ environment and local folders.
 Installing prerequisites for the documentation build
-To run the HTML documention build toolchain, python 3.x, doxygen, git,
+To run the HTML documention build toolchain, python 3.8 or later,
-and the venv python module have to be installed if not already available.
+doxygen 1.8.10 or later, git, and the venv python module have to be
-Also internet access is initially required to download external files
+installed if not already available.  Also internet access is initially
-and tools.
+required to download external files and tools.
 Building the PDF format manual requires in addition a compatible LaTeX
 installation with support for PDFLaTeX and several add-on LaTeX packages
@ -52,16 +52,24 @@ installed.  This includes:
 - babel
 - capt-of
 - cmap
 - dvipng
 - ellipse
 - fncychap
 - fontawesom
 - framed
 - geometry
 - gyre
 - hyperref
 - hypcap
 - needspace
 - pict2e
 - times
 - tabulary
 - titlesec
 - upquote
 - wrapfig
 - xindy
 Also the latexmk script is required to run PDFLaTeX and related tools.
 the required number of times to have self-consistent output and include
 updated bibliography and indices.
--- a/doc/lammps.1
+++ b/doc/lammps.1
@ -1,7 +1,7 @@
-.TH LAMMPS "1" "19 November 2024" "2024-11-19"
+.TH LAMMPS "1" "4 February 2025" "2025-02-04"
 .SH NAME
 .B LAMMPS
-\- Molecular Dynamics Simulator.  Version 19 November 2024
+\- Molecular Dynamics Simulator.  Version 4 February 2025
 .SH SYNOPSIS
 .B lmp
@ -311,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
--- a/doc/src/Build.rst
+++ b/doc/src/Build.rst
@ -1,15 +1,42 @@
 Build LAMMPS
 ============
-LAMMPS is built as a library and an executable from source code using
+LAMMPS is built as a library and an executable from source code using a
-either traditional makefiles for use with GNU make (which may require
+build environment generated by CMake (Unix Makefiles, Ninja, Xcode,
-manual editing), or using a build environment generated by CMake (Unix
+Visual Studio, KDevelop, CodeBlocks and more depending on the platform).
-Makefiles, Ninja, Xcode, Visual Studio, KDevelop, CodeBlocks and more).
+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>`
 section of the manual.
 Prerequisites
 -------------
 Which software you need to compile and use LAMMPS strongly depends on
 which :doc:`features and settings <Build_settings>` and which
 :doc:`optional packages <Packages_list>` you are trying to include.
 Common to all is that you need a C++ and C compiler, where the C++
 compiler has to support at least the C++11 standard (note that some
 compilers require command-line flag to activate C++11 support).
 Furthermore, if you are building with CMake, you need at least CMake
 version 3.20 and a compatible build tool (make or ninja-build); if you
 are building the the legacy GNU make based build system you need GNU
 make (other make variants are not going to work since the build system
 uses features unique to GNU make) and a Unix-like build environment with
 a Bourne shell, and shell tools like "sed", "grep", "touch", "test",
 "tr", "cp", "mv", "rm", "ln", "diff" and so on. Parts of LAMMPS
 interface with or use Python version 3.6 or later.
 The LAMMPS developers aim to keep LAMMPS very portable and usable -
 at least in parts - on most operating systems commonly used for
 running MD simulations.  Please see the :doc:`section on portablility
 <Intro_portability>` for more details.
 .. toctree::
   :maxdepth: 1
--- a/doc/src/Build_basics.rst
+++ b/doc/src/Build_basics.rst
@ -196,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
@ -223,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
@ -321,6 +328,14 @@ LAMMPS.
         you would have to install a newer compiler that supports C++11;
         either as a binary package or through compiling from source.
      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
--- a/doc/src/Build_cmake.rst
+++ b/doc/src/Build_cmake.rst
@ -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,11 +32,11 @@ environments is on a :doc:`separate page <Howto_cmake>`.
 Advantages of using CMake
 ^^^^^^^^^^^^^^^^^^^^^^^^^
-CMake is an alternative to compiling LAMMPS in the traditional way
+CMake is the preferred way of compiling LAMMPS in contrast to the legacy
-through :doc:`(manually customized) makefiles <Build_make>`.  Using
+build system based on GNU make and through :doc:`(manually customized)
-CMake has multiple advantages that are specifically helpful for
+makefiles <Build_make>`.  Using CMake has multiple advantages that are
-people with limited experience in compiling software or for people
+specifically helpful for people with limited experience in compiling
-that want to modify or extend LAMMPS.
+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.
@ -52,9 +52,9 @@ that want to modify or extend LAMMPS.
  compilers can be configured and built concurrently from the same
  source tree.
 - Simplified packaging of LAMMPS for Linux distributions, environment
-  modules, or automated build tools like `Homebrew <https://brew.sh/>`_.
+  modules, or automated build tools like `Spack <https://spack.io>`_
- Integration of automated unit and regression testing (the LAMMPS side
+  or `Homebrew <https://brew.sh/>`_.
-  of this is still under active development).
+- Integration of automated unit and regression testing.
 .. _cmake_build:
@ -119,6 +119,13 @@ configured) and additional files like LAMMPS API headers, manpages,
 potential and force field files.  The location of the installation tree
 defaults to ``${HOME}/.local``.
 .. note::
   If you have set `-D CMAKE_INSTALL_PREFIX` to install LAMMPS into a
   system location on a Linux machine , you may also have to run (as
   root) the `ldconfig` program to update the cache file for fast lookup
   of system shared libraries.
 .. _cmake_options:
 Configuration and build options
--- a/doc/src/Build_extras.rst
+++ b/doc/src/Build_extras.rst
@ -48,6 +48,7 @@ This is the list of packages that may require additional steps.
   * :ref:`LEPTON <lepton>`
   * :ref:`MACHDYN <machdyn>`
   * :ref:`MDI <mdi>`
   * :ref:`MISC <misc>`
   * :ref:`ML-HDNNP <ml-hdnnp>`
   * :ref:`ML-IAP <mliap>`
   * :ref:`ML-PACE <ml-pace>`
@ -254,11 +255,10 @@ Traditional make
 Before building LAMMPS, you must build the GPU library in ``lib/gpu``\ .
 You can do this manually if you prefer; follow the instructions in
-``lib/gpu/README``.  Note that the GPU library uses MPI calls, so you must
+``lib/gpu/README``.  Note that the GPU library uses MPI calls, so you
-use the same MPI library (or the STUBS library) settings as the main
+must use the same MPI library (or the STUBS library) settings as the
-LAMMPS code.  This also applies to the ``-DLAMMPS_BIGBIG``\ ,
+main LAMMPS code.  This also applies to the ``-DLAMMPS_BIGBIG`` or
-``-DLAMMPS_SMALLBIG``\ , or ``-DLAMMPS_SMALLSMALL`` settings in whichever
+``-DLAMMPS_SMALLBIG`` settings in whichever Makefile you use.
 Makefile you use.
 You can also build the library in one step from the ``lammps/src`` dir,
 using a command like these, which simply invokes the ``lib/gpu/Install.py``
@ -547,16 +547,7 @@ They must be specified in uppercase.
      - Local machine
   *  - AMDAVX
      - HOST
-      - AMD 64-bit x86 CPU (AVX 1)
+      - AMD chip
   *  - ZEN
      - HOST
      - AMD Zen class CPU (AVX 2)
   *  - ZEN2
      - HOST
      - AMD Zen2 class CPU (AVX 2)
   *  - ZEN3
      - HOST
      - AMD Zen3 class CPU (AVX 2)
   *  - ARMV80
      - HOST
      - ARMv8.0 Compatible CPU
@ -572,105 +563,126 @@ They must be specified in uppercase.
   *  - A64FX
      - HOST
      - ARMv8.2 with SVE Support
   *  - ARMV9_GRACE
      - HOST
      - ARMv9 NVIDIA Grace CPU
   *  - SNB
      - HOST
-      - Intel Sandy/Ivy Bridge CPU (AVX 1)
+      - Intel Sandy/Ivy Bridge CPUs
   *  - HSW
      - HOST
-      - Intel Haswell CPU (AVX 2)
+      - Intel Haswell CPUs
   *  - BDW
      - HOST
-      - Intel Broadwell Xeon E-class CPU (AVX 2 + transactional mem)
+      - Intel Broadwell Xeon E-class CPUs
   *  - SKL
      - HOST
      - Intel Skylake Client CPU
   *  - SKX
      - HOST
      - Intel Skylake Xeon Server CPU (AVX512)
   *  - ICL
      - HOST
-      - Intel Ice Lake Client CPU (AVX512)
+      - Intel Ice Lake Client CPUs (AVX512)
   *  - ICX
      - HOST
-      - Intel Ice Lake Xeon Server CPU (AVX512)
+      - Intel Ice Lake Xeon Server CPUs (AVX512)
-   *  - SPR
+   *  - SKL
      - HOST
-      - Intel Sapphire Rapids Xeon Server CPU (AVX512)
+      - Intel Skylake Client CPUs
   *  - SKX
      - HOST
      - Intel Skylake Xeon Server CPUs (AVX512)
   *  - KNC
      - HOST
      - Intel Knights Corner Xeon Phi
   *  - KNL
      - HOST
      - Intel Knights Landing Xeon Phi
   *  - SPR
      - HOST
      - Intel Sapphire Rapids Xeon Server CPUs (AVX512)
   *  - POWER8
      - HOST
-      - IBM POWER8 CPU
+      - IBM POWER8 CPUs
   *  - POWER9
      - HOST
-      - IBM POWER9 CPU
+      - IBM POWER9 CPUs
   *  - ZEN
      - HOST
      - AMD Zen architecture
   *  - ZEN2
      - HOST
      - AMD Zen2 architecture
   *  - ZEN3
      - HOST
      - AMD Zen3 architecture
   *  - RISCV_SG2042
      - HOST
-      - SG2042 (RISC-V) CPU
+      - SG2042 (RISC-V) CPUs
   *  - RISCV_RVA22V
      - HOST
      - RVA22V (RISC-V) CPUs
   *  - KEPLER30
      - GPU
-      - NVIDIA Kepler generation CC 3.0 GPU
+      - NVIDIA Kepler generation CC 3.0
   *  - KEPLER32
      - GPU
-      - NVIDIA Kepler generation CC 3.2 GPU
+      - NVIDIA Kepler generation CC 3.2
   *  - KEPLER35
      - GPU
-      - NVIDIA Kepler generation CC 3.5 GPU
+      - NVIDIA Kepler generation CC 3.5
   *  - KEPLER37
      - GPU
-      - NVIDIA Kepler generation CC 3.7 GPU
+      - NVIDIA Kepler generation CC 3.7
   *  - MAXWELL50
      - GPU
-      - NVIDIA Maxwell generation CC 5.0 GPU
+      - NVIDIA Maxwell generation CC 5.0
   *  - MAXWELL52
      - GPU
-      - NVIDIA Maxwell generation CC 5.2 GPU
+      - NVIDIA Maxwell generation CC 5.2
   *  - MAXWELL53
      - GPU
-      - NVIDIA Maxwell generation CC 5.3 GPU
+      - NVIDIA Maxwell generation CC 5.3
   *  - PASCAL60
      - GPU
-      - NVIDIA Pascal generation CC 6.0 GPU
+      - NVIDIA Pascal generation CC 6.0
   *  - PASCAL61
      - GPU
-      - NVIDIA Pascal generation CC 6.1 GPU
+      - NVIDIA Pascal generation CC 6.1
   *  - VOLTA70
      - GPU
-      - NVIDIA Volta generation CC 7.0 GPU
+      - NVIDIA Volta generation CC 7.0
   *  - VOLTA72
      - GPU
-      - NVIDIA Volta generation CC 7.2 GPU
+      - NVIDIA Volta generation CC 7.2
   *  - TURING75
      - GPU
-      - NVIDIA Turing generation CC 7.5 GPU
+      - NVIDIA Turing generation CC 7.5
   *  - AMPERE80
      - GPU
-      - NVIDIA Ampere generation CC 8.0 GPU
+      - NVIDIA Ampere generation CC 8.0
   *  - AMPERE86
      - GPU
-      - NVIDIA Ampere generation CC 8.6 GPU
+      - NVIDIA Ampere generation CC 8.6
   *  - ADA89
      - GPU
-      - NVIDIA Ada Lovelace generation CC 8.9 GPU
+      - NVIDIA Ada generation CC 8.9
   *  - HOPPER90
      - GPU
-      - NVIDIA Hopper generation CC 9.0 GPU
+      - NVIDIA Hopper generation CC 9.0
   *  - AMD_GFX906
      - GPU
-      - AMD GPU MI50/MI60
+      - AMD GPU MI50/60
   *  - AMD_GFX908
      - GPU
      - AMD GPU MI100
   *  - AMD_GFX90A
      - GPU
      - AMD GPU MI200
   *  - AMD_GFX940
      - GPU
      - AMD GPU MI300
   *  - AMD_GFX942
      - GPU
      - AMD GPU MI300
   *  - AMD_GFX942_APU
      - GPU
      - AMD APU MI300A
   *  - AMD_GFX1030
      - GPU
      - AMD GPU V620/W6800
@ -679,7 +691,7 @@ They must be specified in uppercase.
      - AMD GPU RX7900XTX
   *  - AMD_GFX1103
      - GPU
-      - AMD Phoenix APU with Radeon 740M/760M/780M/880M/890M
+      - AMD APU Phoenix
   *  - INTEL_GEN
      - GPU
      - SPIR64-based devices, e.g. Intel GPUs, using JIT
@ -702,7 +714,7 @@ They must be specified in uppercase.
      - GPU
      - Intel GPU Ponte Vecchio
-This list was last updated for version 4.3.0 of the Kokkos library.
+This list was last updated for version 4.5.1 of the Kokkos library.
 .. tabs::
@ -1126,11 +1138,10 @@ POEMS package
 PYTHON package
 ---------------------------
-Building with the PYTHON package requires you have a the Python development
+Building with the PYTHON package requires you have a the Python
-headers and library available on your system, which needs to be a Python 2.7
+development headers and library available on your system, which
-version or a Python 3.x version.  Since support for Python 2.x has ended,
+needs to be Python version 3.6 or later.  See ``lib/python/README``
-using Python 3.x is strongly recommended. See ``lib/python/README`` for
+for additional details.
 additional details.
 .. tabs::
@ -1146,7 +1157,7 @@ additional details.
      set the Python_EXECUTABLE variable to specify which Python
      interpreter should be used.  Note note that you will also need to
      have the development headers installed for this version,
-      e.g. python2-devel.
+      e.g. python3-devel.
   .. tab:: Traditional make
@ -2019,7 +2030,7 @@ TBB and MKL.
 .. _mdi:
 MDI package
-----------------------------
+-----------
 .. tabs::
@ -2046,6 +2057,37 @@ MDI package
 ----------
 .. _misc:
 MISC package
 ------------
 The :doc:`fix imd <fix_imd>` style in this package can be run either
 synchronously (communication with IMD clients is done in the main
 process) or asynchronously (the fix spawns a separate thread that can
 communicate with IMD clients concurrently to the LAMMPS execution).
 .. tabs::
   .. tab:: CMake build
      .. code-block:: bash
         -D LAMMPS_ASYNC_IMD=value  # Run IMD server asynchronously
                                    # value = no (default) or yes
   .. tab:: Traditional make
      To enable asynchronous mode the ``-DLAMMPS_ASYNC_IMD`` define
      needs to be added to the ``LMP_INC`` variable in the
      ``Makefile.machine`` you are using.  For example:
      .. code-block:: make
         LMP_INC = -DLAMMPS_ASYNC_IMD -DLAMMPS_MEMALIGN=64
 ----------
 .. _molfile:
 MOLFILE package
--- a/doc/src/Build_make.rst
+++ b/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
 ^^^^^^^^^^^^
@ -26,9 +30,9 @@ additional tools to be available and functioning.
  * 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``
-    folder).  Python scripts are currently tested with python 2.7 and
+    folder).  Python scripts are currently tested with 3.6 to 3.11.
-    3.6 to 3.11. The procedure for :doc:`building the documentation
+    The procedure for :doc:`building the documentation <Build_manual>`
-    <Build_manual>` *requires* Python 3.5 or later.
+    *requires* Python 3.8 or later.
 Getting started
 ^^^^^^^^^^^^^^^
--- a/doc/src/Build_manual.rst
+++ b/doc/src/Build_manual.rst
@ -78,8 +78,7 @@ folder.  The following ``make`` commands are available:
   make epub          # generate LAMMPS.epub in ePUB format using Sphinx
   make mobi          # generate LAMMPS.mobi in MOBI format using ebook-convert
-   make fasthtml      # generate approximate HTML in fasthtml dir using Sphinx
+   make fasthtml      # generate approximate HTML in fasthtml dir using pandoc
                      # some Sphinx extensions do not work correctly with this
   make clean         # remove intermediate RST files created by HTML build
   make clean-all     # remove entire build folder and any cached data
@ -116,9 +115,9 @@ environment variable.
 Prerequisites for HTML
 ----------------------
-To run the HTML documentation build toolchain, python 3, git, doxygen,
+To run the HTML documentation build toolchain, Python 3.8 or later, git,
-and virtualenv have to be installed locally.  Here are instructions for
+doxygen, and virtualenv have to be installed locally.  Here are
-common setups:
+instructions for common setups:
 .. tabs::
@ -128,13 +127,7 @@ common setups:
         sudo apt-get install git doxygen
-   .. tab:: RHEL or CentOS (Version 7.x)
+   .. tab:: Fedora or RHEL/AlmaLinux/RockyLinux (8.x or later)
      .. code-block:: bash
         sudo yum install git doxygen
   .. tab:: Fedora or RHEL/CentOS (8.x or later)
      .. code-block:: bash
@ -154,7 +147,36 @@ Prerequisites for PDF
 In addition to the tools needed for building the HTML format manual,
 a working LaTeX installation with support for PDFLaTeX and a selection
-of LaTeX styles/packages are required.  To run the PDFLaTeX translation
+of LaTeX styles/packages are required.  Apart from LaTeX packages that
 are usually installed by default, the following packages are required:
 .. table_from_list::
   :columns: 11
   - amsmath
   - anysize
   - babel
   - capt-of
   - cmap
   - dvipng
   - ellipse
   - fncychap
   - fontawesome
   - framed
   - geometry
   - gyre
   - hyperref
   - hypcap
   - needspace
   - pict2e
   - times
   - tabulary
   - titlesec
   - upquote
   - wrapfig
   - xindy
 To run the PDFLaTeX translation
 the ``latexmk`` script needs to be installed as well.
 Prerequisites for ePUB and MOBI
@ -182,12 +204,42 @@ documentation is required and either existing files in the ``src``
 folder need to be updated or new files added. These files are written in
 `reStructuredText <rst_>`_ markup for translation with the Sphinx tool.
 Testing your contribution
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 Before contributing any documentation, please check that both the HTML
-and the PDF format documentation can translate without errors.  During
+and the PDF format documentation can translate without errors and that
-testing the html translation, you may use the ``make fasthtml`` command
+there are no spelling issues.  This is done with ``make html``, ``make pdf``,
-which does an approximate translation (i.e. not all Sphinx features and
+and ``make spelling``, respectively.
-extensions will work), but runs very fast because it will only translate
+
-files that have been changed since the last ``make fasthtml`` command.
+Fast and approximate translation to HTML
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Translating the full manual to HTML or PDF can take a long time.  Thus
 there is a fast and approximate way to translate the reStructuredText to
 HTML as a quick-n-dirty way of checking your manual page.
 This translation uses `Pandoc <https://pandoc.org>`_ instead of Sphinx
 and thus all special Sphinx features (cross-references, advanced tables,
 embedding of Python docstrings or doxygen documentation, and so on) will
 not render correctly.  Most embedded math should render correctly.  This
 is a **very fast** way to check the syntax and layout of a documentation
 file translated to HTML while writing or updating it.
 To translate **all** manual pages, you can type ``make fasthtml`` at the
 command line.  The translated HTML files are then in the ``fasthtml``
 folder. All subsequent ``make fasthtml`` commands will only translate
 ``.rst`` files that have been changed.  The ``make fasthtml`` command
 can be parallelized with make using the `-j` flag.  You can also
 directly translate only individual pages: e.g. to translate only the
 ``doc/src/pair_lj.rst`` page type ``make fasthtml/pair_lj.html``
 After writing the documentation is completed, you will still need
 to verify with ``make html`` and ``make pdf`` that it translates
 correctly in both formats.
 Tests for consistency, completeness, and other known issues
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Please also check the output to the console for any warnings or problems.  There will
 be multiple tests run automatically:
--- a/doc/src/Build_package.rst
+++ b/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>`
--- a/doc/src/Build_settings.rst
+++ b/doc/src/Build_settings.rst
@ -8,12 +8,13 @@ Optional build settings
 LAMMPS can be built with several optional settings.  Each subsection
 explains how to do this for building both with CMake and make.
-* `C++11 standard compliance`_ when building all of LAMMPS
+* `C++11 and C++17 standard compliance`_ when building all of LAMMPS
 * `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 JPEG, PNG, and movie files`_ via the :doc:`dump image <dump_image>` or :doc:`dump movie <dump_image>` commands
-* `Support for downloading files`_
+* `Support for downloading files from the input`_
 * `Prevent download of large potential files`_
 * `Memory allocation alignment`_
 * `Workaround for long long integers`_
 * `Exception handling when using LAMMPS as a library`_ to capture errors
@ -23,14 +24,15 @@ explains how to do this for building both with CMake and make.
 .. _cxx11:
-C++11 standard compliance
+C++11 and C++17 standard compliance
-------------------------
+-----------------------------------
-A C++11 standard compatible compiler is a requirement for compiling LAMMPS.
+A C++11 standard compatible compiler is currently the minimum
-LAMMPS version 3 March 2020 is the last version compatible with the previous
+requirement for compiling LAMMPS.  LAMMPS version 3 March 2020 is the
-C++98 standard for the core code and most packages. Most currently used
+last version compatible with the previous C++98 standard for the core
-C++ compilers are compatible with C++11, but some older ones may need extra
+code and most packages. Most currently used C++ compilers are compatible
-flags to enable C++11 compliance.  Example for GNU c++ 4.8.x:
+with C++11, but some older ones may need extra flags to enable C++11
 compliance.  Example for GNU c++ 4.8.x:
 .. code-block:: make
@ -40,6 +42,17 @@ 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>`.
 .. versionchanged:: 4Feb2025
 Starting with LAMMPS version 4 February 2025 we are starting a
 transition to require the C++17 standard.  Most current compilers are
 compatible and if the C++17 standard is available by default, LAMMPS
 will enable C++17 and will compile normally.  If the chosen compiler is
 not compatible with C++17, but only supports C++11, then the define
 -DLAMMPS_CXX11 is required to fall back to compiling with a C++11
 compiler.  After the next stable release of LAMMPS in summer 2025, the
 LAMMPS development branch and future releases will require C++17.
 ----------
 .. _fft:
@ -303,7 +316,7 @@ large counters can become before "rolling over".  The default setting of
      .. code-block:: bash
-         -D LAMMPS_SIZES=value   # smallbig (default) or bigbig or smallsmall
+         -D LAMMPS_SIZES=value   # smallbig (default) or bigbig
      If the variable is not set explicitly, "smallbig" is used.
@ -314,7 +327,7 @@ large counters can become before "rolling over".  The default setting of
      .. code-block:: make
-         LMP_INC = -DLAMMPS_SMALLBIG    # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL
+         LMP_INC = -DLAMMPS_SMALLBIG    # or -DLAMMPS_BIGBIG
      The default setting is ``-DLAMMPS_SMALLBIG`` if nothing is specified
@ -323,34 +336,27 @@ LAMMPS system size restrictions
 .. list-table::
   :header-rows: 1
-   :widths: 18 27 28 27
+   :widths: 27 36 37
   :align: center
   * -
     - smallbig
     - bigbig
     - smallsmall
   * - Total atom count
     - :math:`2^{63}` atoms (= :math:`9.223 \cdot 10^{18}`)
     - :math:`2^{63}` atoms (= :math:`9.223 \cdot 10^{18}`)
     - :math:`2^{31}` atoms (= :math:`2.147 \cdot 10^9`)
   * - Total timesteps
     - :math:`2^{63}` steps (= :math:`9.223 \cdot 10^{18}`)
     - :math:`2^{63}` steps (= :math:`9.223 \cdot 10^{18}`)
     - :math:`2^{31}` steps (= :math:`2.147 \cdot 10^9`)
   * - Atom ID values
     - :math:`1 \le i \le 2^{31} (= 2.147 \cdot 10^9)`
     - :math:`1 \le i \le 2^{63} (= 9.223 \cdot 10^{18})`
     - :math:`1 \le i \le 2^{31} (= 2.147 \cdot 10^9)`
   * - Image flag values
     - :math:`-512 \le i \le 511`
     - :math:`- 1\,048\,576 \le i \le 1\,048\,575`
     - :math:`-512 \le i \le 511`
 The "bigbig" setting increases the size of image flags and atom IDs over
-"smallbig" and the "smallsmall" setting is only needed if your machine
+the default "smallbig" setting.
 does not support 64-bit integers or incurs performance penalties when
 using them.
 These are limits for the core of the LAMMPS code, specific features or
 some styles may impose additional limits.  The :ref:`ATC
@ -504,8 +510,8 @@ during a run.
 .. _libcurl:
-Support for downloading files
+Support for downloading files from the input
-----------------------------
+--------------------------------------------
 .. versionadded:: 29Aug2024
@ -548,6 +554,25 @@ LAMMPS is compiled accordingly which needs the following settings:
 ----------
 .. _download_pot:
 Prevent download of large potential files
 -----------------------------------------
 .. versionadded:: 8Feb2023
 LAMMPS bundles a selection of potential files in the ``potentials``
 folder as examples of how those kinds of potential files look like and
 for use with the provided input examples in the ``examples`` tree.  To
 keep the size of the distributed LAMMPS source package small, very large
 potential files (> 5 MBytes) are not bundled, but only downloaded on
 demand when the :doc:`corresponding package <Packages_list>` is
 installed.  This automatic download can be prevented when :doc:`building
 LAMMPS with CMake <Build_cmake>` by adding the setting `-D
 DOWNLOAD_POTENTIALS=off` when configuring.
 ----------
 .. _align:
 Memory allocation alignment
--- a/doc/src/Commands_all.rst
+++ b/doc/src/Commands_all.rst
@ -140,6 +140,7 @@ additional letter in parenthesis: k = KOKKOS.
   * :doc:`plugin <plugin>`
   * :doc:`prd <prd>`
   * :doc:`python <python>`
   * :doc:`region2vmd <region2vmd>`
   * :doc:`tad <tad>`
   * :doc:`temper <temper>`
   * :doc:`temper/grem <temper_grem>`
--- a/doc/src/Commands_bond.rst
+++ b/doc/src/Commands_bond.rst
@ -23,6 +23,7 @@ OPT.
   *
   * :doc:`bpm/rotational <bond_bpm_rotational>`
   * :doc:`bpm/spring <bond_bpm_spring>`
   * :doc:`bpm/spring/plastic <bond_bpm_spring_plastic>`
   * :doc:`class2 (ko) <bond_class2>`
   * :doc:`fene (iko) <bond_fene>`
   * :doc:`fene/expand (o) <bond_fene_expand>`
@ -90,6 +91,7 @@ OPT.
   * :doc:`lepton (o) <angle_lepton>`
   * :doc:`mesocnt <angle_mesocnt>`
   * :doc:`mm3 <angle_mm3>`
   * :doc:`mwlc <angle_mwlc>`
   * :doc:`quartic (o) <angle_quartic>`
   * :doc:`spica (ko) <angle_spica>`
   * :doc:`table (o) <angle_table>`
--- a/doc/src/Commands_compute.rst
+++ b/doc/src/Commands_compute.rst
@ -58,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>`
@ -140,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 (k) <compute_sna_atom>`
-   * :doc:`sna/grid/local <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>`
@ -177,6 +178,7 @@ KOKKOS, o = OPENMP, t = OPT.
   * :doc:`ti <compute_ti>`
   * :doc:`torque/chunk <compute_torque_chunk>`
   * :doc:`vacf <compute_vacf>`
   * :doc:`vacf/chunk <compute_vacf_chunk>`
   * :doc:`vcm/chunk <compute_vcm_chunk>`
   * :doc:`viscosity/cos <compute_viscosity_cos>`
   * :doc:`voronoi/atom <compute_voronoi_atom>`
--- a/doc/src/Commands_fix.rst
+++ b/doc/src/Commands_fix.rst
@ -58,6 +58,7 @@ OPT.
   * :doc:`dt/reset (k) <fix_dt_reset>`
   * :doc:`edpd/source <fix_dpd_source>`
   * :doc:`efield (k) <fix_efield>`
   * :doc:`efield/lepton <fix_efield_lepton>`
   * :doc:`efield/tip4p <fix_efield>`
   * :doc:`ehex <fix_ehex>`
   * :doc:`electrode/conp (i) <fix_electrode>`
@ -161,6 +162,8 @@ OPT.
   * :doc:`phonon <fix_phonon>`
   * :doc:`pimd/langevin <fix_pimd>`
   * :doc:`pimd/nvt <fix_pimd>`
   * :doc:`pimd/langevin/bosonic <fix_pimd>`
   * :doc:`pimd/nvt/bosonic <fix_pimd>`
   * :doc:`planeforce <fix_planeforce>`
   * :doc:`plumed <fix_plumed>`
   * :doc:`poems <fix_poems>`
--- a/doc/src/Commands_pair.rst
+++ b/doc/src/Commands_pair.rst
@ -80,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>`
@ -114,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>`
--- a/doc/src/Commands_removed.rst
+++ b/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,94 +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.
-restart2data tool
+LAMMPS shell
 -----------------
 .. versionchanged:: 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>`
 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
 ------------
-The MEAM package in Fortran has been replaced by a C++ implementation.
+.. versionchanged:: 29Aug2024
 The code in the :ref:`MEAM package <PKG-MEAM>` is a translation of the
 Fortran code of MEAM into C++, which removes several restrictions
 (e.g. there can be multiple instances in hybrid pair styles) and allows
 for some optimizations leading to better performance.  The pair style
 :doc:`meam <pair_meam>` has the exact same syntax.  For a transition
 period the C++ version of MEAM was called USER-MEAMC so it could
 coexist with the Fortran version.
-Minimize style fire/old
+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
+.. versionchanged:: 27Jun2024
 reproduced with *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
+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
+.. deprecated:: 7Feb2024
-*mesont* have been removed from the :ref:`MESONT package <PKG-MESONT>`.
+
-The same functionality is available through
+The USER-REAXC package has been renamed to :ref:`REAXFF <PKG-REAXFF>`.
-:doc:`pair style mesocnt <pair_mesocnt>`,
+In the process also the pair style and related fixes were renamed to use
-:doc:`bond style mesocnt <bond_mesocnt>` and
+the "reaxff" string instead of "reax/c". For a while LAMMPS was maintaining
-:doc:`angle style mesocnt <angle_mesocnt>`.
+backward compatibility by providing aliases for the styles.  These have
 been removed, so using "reaxff" is now *required*.
 MPIIO package
 -------------
@ -115,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
 ------------
@ -126,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
@ -138,20 +143,25 @@ syntax compatible with the removed reax pair style, so input files will
 have to be adapted.  The REAXFF package was originally called
 USER-REAXC.
-USER-REAXC package
+MEAM package
------------------
+------------
-.. deprecated:: 7Feb2024
+.. deprecated:: 4Jan2019
-The USER-REAXC package has been renamed to :ref:`REAXFF <PKG-REAXFF>`.
+The MEAM package in Fortran has been replaced by a C++ implementation.
-In the process also the pair style and related fixes were renamed to use
+The code in the :ref:`MEAM package <PKG-MEAM>` is a translation of the
-the "reaxff" string instead of "reax/c". For a while LAMMPS was maintaining
+Fortran code of MEAM into C++, which removes several restrictions
-backward compatibility by providing aliases for the styles.  These have
+(e.g. there can be multiple instances in hybrid pair styles) and allows
-been removed, so using "reaxff" is now *required*.
+for some optimizations leading to better performance.  The pair style
 :doc:`meam <pair_meam>` has the exact same syntax.  For a transition
 period the C++ version of MEAM was called USER-MEAMC so it could
 coexist with the Fortran version.
 USER-CUDA package
 -----------------
 .. deprecated:: 31May2016
 The USER-CUDA package had been removed, since it had been unmaintained
 for a long time and had known bugs and problems.  Significant parts of
 the design were transferred to the
@ -160,19 +170,39 @@ 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
+Compute atom/molecule
---------
+_____________________
-.. versionchanged:: 27Jun2024
+.. deprecated:: 11 Dec2015
-The i-PI tool has been removed from the LAMMPS distribution.  Instead,
+The atom/molecule command has been removed from LAMMPS since it was superseded
-instructions to install i-PI from PyPI via pip are provided.
+by the more general and extensible "chunk infrastructure".  Here the system is
 partitioned in one of many possible ways - including using molecule IDs -
 through the :doc:`compute chunk/atom <compute_chunk_atom>` command and then
 summing is done using :doc:`compute reduce/chunk <compute_reduce_chunk>` Please
 refer to the :doc:`chunk HOWTO <Howto_chunk>` section for an overview.
-LAMMPS shell
+Fix ave/spatial and fix ave/spatial/sphere
------------
+------------------------------------------
-.. versionchanged:: 29Aug2024
+.. deprecated:: 11Dec2015
-The LAMMPS shell has been removed from the LAMMPS distribution. Users
+The fixes ave/spatial and ave/spatial/sphere have been removed from LAMMPS
-are encouraged to use the :ref:`LAMMPS-GUI <lammps_gui>` tool instead.
+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>`
--- a/doc/src/Developer.rst
+++ b/doc/src/Developer.rst
@ -24,4 +24,5 @@ of time and requests from the LAMMPS user community.
   Classes
   Developer_platform
   Developer_utils
   Developer_internal
   Developer_grid
--- a/doc/src/Developer_code_design.rst
+++ b/doc/src/Developer_code_design.rst
@ -203,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
@ -300,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
+"printf()" family of functions.  The primary reason is that it allows a
-a typesafe default format for any type of supported data.  This is
+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
+64-bit) which may require different format strings depending on compile
-compile time settings or compilers/operating systems.  Furthermore,
+time settings or compilers/operating systems.  Furthermore, {fmt} gives
-{fmt} gives better performance, has more functionality, a familiar
+better performance, has more functionality, a familiar formatting syntax
-formatting syntax that has similarities to ``format()`` in Python, and
+that has similarities to ``format()`` in Python, and provides a facility
-provides a facility that can be used to integrate format strings and a
+that can be used to integrate format strings and a variable number of
-variable number of arguments into custom functions in a much simpler
+arguments into custom functions in a much simpler way than the varargs
-way than the varargs mechanism of the C library.  Finally, {fmt} has
+mechanism of the C library.  Finally, {fmt} has been included into the
-been included into the C++20 language standard, so changes to adopt it
+C++20 language standard as ``std::format()``, so changes to adopt it are
-are future-proof.
+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
@ -319,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
+Otherwise, the :cpp:func:`utils::print() <LAMMPS_NS::utils::print>`
-``printf()`` or ``fprintf()``.  In addition, several LAMMPS output
+function may be used instead of ``printf()`` or ``fprintf()``.  In
-functions, that originally accepted a single string as argument have
+addition, several LAMMPS output functions, that originally accepted a
-been overloaded to accept a format string with optional arguments as
+single string as argument have been overloaded to accept a format string
-well (e.g., ``Error::all()``, ``Error::one()``, ``utils::logmesg()``).
+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
 ==================================
--- a/doc/src/Developer_flow.rst
+++ b/doc/src/Developer_flow.rst
@ -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
--- a/doc/src/Developer_internal.rst
+++ b/doc/src/Developer_internal.rst
@ -0,0 +1,113 @@
 Internal Styles
 ---------------
 LAMMPS has a number of styles that are not meant to be used in an input
 file and thus are not documented in the :doc:`LAMMPS command
 documentation <Commands_all>`.  The differentiation between user
 commands and internal commands is through the case of the command name:
 user commands and styles are all lower case, internal styles are all
 upper case.  Internal styles are not called from the input file, but
 their classes are instantiated by other styles.  Often they are
 created by other styles to store internal data or to perform actions
 regularly at specific steps of the simulation.
 The paragraphs below document some of those styles that have general
 utility and may be used to avoid redundant implementation.
 DEPRECATED Styles
 ^^^^^^^^^^^^^^^^^
 The styles called DEPRECATED (e.g. pair, bond, fix, compute, region, etc.)
 have the purpose to inform users that a specific style has been removed
 or renamed.  This is achieved by creating an alias for the deprecated
 style to the corresponding class.  For example, the fix style DEPRECATED
 is aliased to fix style ave/spatial and fix style ave/spatial/sphere with
 the following code:
 .. code-block:: c++
   FixStyle(DEPRECATED,FixDeprecated);
   FixStyle(ave/spatial,FixDeprecated);
   FixStyle(ave/spatial/sphere,FixDeprecated);
 The individual class will then determine based on the style name
 what action to perform:
 - inform that the style has been removed and what style replaces it, if any, and then error out
 - inform that the style has been renamed and then either execute the replacement or error out
 - inform that the style is no longer required, and it is thus ignored and continue
 There is also a section in the user's guide for :doc:`removed commands
 and packages <Commands_removed>` with additional explanations.
 Internal fix styles
 ^^^^^^^^^^^^^^^^^^^
 fix DUMMY
 """""""""
 Most fix classes cannot be instantiated before the simulation box has
 been created since they access data that is only available then.
 However, in some cases it is required that a fix must be at or close to
 the top of the list of all fixes.  In those cases an instance of the
 DUMMY fix style may be created by calling ``Modify::add_fix()`` and then
 later replaced by calling ``Modify::replace_fix()``.
 fix STORE/ATOM
 """"""""""""""
 Fix STORE/ATOM can be used as persistent storage of per-atom data.
 **Syntax**
 .. code-block:: LAMMPS
   fix ID group-ID STORE/ATOM N1 N2 gflag rflag
 * ID, group-ID are documented in :doc:`fix <fix>` command
 * STORE/ATOM = style name of this fix command
 * N1 = 1, N2 = 0 : data is per-atom vector = single value per atom
 * N1 > 1, N2 = 0 : data is per-atom array = N1 values per atom
 * N1 > 0, N2 > 0 : data is per-atom tensor = N1xN2 values per atom
 * gflag = 1 communicate per-atom values with ghost atoms, 0 do not update ghost atom data
 * rflag = 1 store per-atom value in restart file, 0 do not store data in restart
 Similar functionality is also available through using custom per-atom
 properties with :doc:`fix property/atom <fix_property_atom>`.  The
 choice between the two fixes should be based on whether the user should
 be able to access this per-atom data: if yes, then fix property/atom is
 preferred, otherwise fix STORE/ATOM.
 fix STORE/GLOBAL
 """"""""""""""""
 Fix STORE/GLOBAL can be used as persistent storage of global data with support for restarts
 **Syntax**
 .. code-block:: LAMMPS
   fix ID group-ID STORE/GLOBAL N1 N2
 * ID, group-ID are documented in :doc:`fix <fix>` command
 * STORE/GLOBAL = style name of this fix command
 * N1 >=1 : number of global items to store
 * N2 = 1 : data is global vector of length N1
 * N2 > 1 : data is global N1xN2 array
 fix STORE/LOCAL
 """""""""""""""
 Fix STORE/LOCAL can be used as persistent storage for local data
 **Syntax**
 .. code-block:: LAMMPS
   fix ID group-ID STORE/LOCAL Nreset Nvalues
 * ID, group-ID are documented in :doc:`fix <fix>` command
 * STORE/LOCAL = style name of this fix command
 * Nreset = frequency at which local data is available
 * Nvalues = number of values per local item, that is the number of columns
--- a/doc/src/Developer_notes.rst
+++ b/doc/src/Developer_notes.rst
@ -7,13 +7,7 @@ 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:
+.. contents::
 - `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`_
 ----
@ -218,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
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--- a/doc/src/Developer_unittest.rst
+++ b/doc/src/Developer_unittest.rst
@ -227,12 +227,12 @@ Tests for the C-style library interface
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Tests for validating the LAMMPS C-style library interface are in the
-``unittest/c-library`` folder.  They are implemented either to be used
+``unittest/c-library`` folder.  They text either utility functions or
-for utility functions or for LAMMPS commands, but use the functions
+LAMMPS commands, but use the functions implemented in
-implemented in the ``src/library.cpp`` file as much as possible.  There
+``src/library.cpp`` as much as possible.  There may be some overlap with
-may be some overlap with other tests, but only in as much as is required
+other tests as far as the LAMMPS functionality is concerned, but the
-to test the C-style library API.  The tests are distributed over
+focus is on testing the C-style library API.  The tests are distributed
-multiple test programs which try to match the grouping of the
+over multiple test programs which try to match the grouping of the
 functions in the source code and :ref:`in the manual <lammps_c_api>`.
 This group of tests also includes tests invoking LAMMPS in parallel
@ -258,7 +258,7 @@ Tests for the Python module and package
 The ``unittest/python`` folder contains primarily tests for classes and
 functions in the LAMMPS python module but also for commands in the
-PYTHON package.  These tests are only enabled if the necessary
+PYTHON package.  These tests are only enabled, if the necessary
 prerequisites are detected or enabled during configuration and
 compilation of LAMMPS (shared library build enabled, Python interpreter
 found, Python development files found).
@ -272,29 +272,30 @@ Tests for the Fortran interface
 Tests for using the Fortran module are in the ``unittest/fortran``
 folder.  Since they are also using the GoogleTest library, they require
-implementing test wrappers in C++ that will call fortran functions
+test wrappers written in C++ that will call fortran functions with a C
-which provide a C function interface through ISO_C_BINDINGS that will in
+function interface through ISO_C_BINDINGS which will in turn call the
-turn call the functions in the LAMMPS Fortran module.
+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
+convenience and utility functions that are only available through the
-the C-style interface.  Instead it can focus on the more generic features
+C-style library interface.  Instead they focus on the more generic
-that are used internally.  This part of the unit tests is currently still
+features that are used in LAMMPS internally.  This part of the unit
-mostly in the planning stage.
+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.
+writing files like data files, restart files, potential files or dump
-This covers simple things like the file i/o convenience functions in the
+files.  This covers simple things like the file i/o convenience
-``utils::`` namespace to complex tests of atom styles where creating and
+functions in the ``utils::`` namespace to complex tests of atom styles
-deleting atoms with different properties is tested in different ways
+where creating and deleting of atoms with different properties is tested
-and through script commands or reading and writing of data or restart files.
+in different ways and through script commands or reading and writing of
 data or restart files.
 Tests for styles computing or modifying forces
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -443,7 +444,7 @@ file for a style that is similar to one to be tested.  The file name should
 follow the naming conventions described above and after copying the file,
 the first step is to replace the style names where needed.  The coefficient
 values do not have to be meaningful, just in a reasonable range for the
-given system.  It does not matter if some forces are large, as long as
+given system.  It does not matter if some forces are large, for as long as
 they do not diverge.
 The template input files define a large number of index variables at the top
@ -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,
+There are by default no unit tests for newly added features (e.g. pair,
-or compute styles) unless your pull request also includes tests for the
+fix, or compute styles) unless your pull request also includes tests for
-added features.  If you are modifying some features, you may see failures
+these added features.  If you are modifying some existing LAMMPS
-for existing tests, if your modifications have some unexpected side effects
+features, you may see failures for existing tests, if your modifications
-or your changes render the existing test invalid.  If you are adding an
+have some unexpected side effects or your changes render the existing
-accelerated version of an existing style, then only tests for INTEL,
+test invalid.  If you are adding an accelerated version of an existing
-KOKKOS (with OpenMP only), OPENMP, and OPT will be run automatically.
+style, then only tests for INTEL, KOKKOS (with OpenMP only), OPENMP, and
-Tests for the GPU package are time consuming and thus are only run
+OPT will be run automatically.  Tests for the GPU package are time
-*after* a merge, or when a special label, ``gpu_unit_tests`` is added
+consuming and thus are only run *after* a merge, or when a special
-to the pull request.  After the test has started, it is often best to
+label, ``gpu_unit_tests`` is added to the pull request.  After the test
-remove the label since every PR activity will re-trigger the test (that
+has started, it is often best to remove the label since every PR
-is a limitation of triggering a test with a label).  Support for unit
+activity will re-trigger the test (that is a limitation of triggering a
-tests when using KOKKOS with GPU acceleration is currently not supported.
+test with a label).  Support for unit tests using KOKKOS with GPU
 acceleration is currently not supported.
 When you see a failed build on GitHub, click on ``Details`` to be taken
 to the corresponding LAMMPS Jenkins CI web page.  Click on the "Exit"
@ -588,7 +590,7 @@ While the epsilon (relative precision) for a single, `IEEE 754 compliant
 <https://en.wikipedia.org/wiki/IEEE_754>`_, double precision floating
 point operation is at about 2.2e-16, the achievable precision for the
 tests is lower due to most numbers being sums over intermediate results
-and the non-associativity of floating point math leading to larger
+for which the non-associativity of floating point math leads to larger
 errors.  As a rule of thumb, the test epsilon can often be in the range
 5.0e-14 to 1.0e-13.  But for "noisy" force kernels, e.g. those a larger
 amount of arithmetic operations involving `exp()`, `log()` or `sin()`
@ -602,7 +604,7 @@ 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
--- a/doc/src/Developer_utils.rst
+++ b/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
--- a/doc/src/Developer_write_fix.rst
+++ b/doc/src/Developer_write_fix.rst
@ -96,7 +96,7 @@ Here the we specify which methods of the fix should be called during
     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",
+       utils::print(screen, "{}, {}, {}\n",
                    globalAvgVel[0], globalAvgVel[1], globalAvgVel[2]);
     }
   }
--- a/doc/src/Errors_debug.rst
+++ b/doc/src/Errors_debug.rst
@ -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.
--- a/doc/src/Errors_details.rst
+++ b/doc/src/Errors_details.rst
@ -1,12 +1,244 @@
-Error and warning details
+Errors and warnings details
-=========================
+===========================
-Many errors or warnings are self-explanatory and thus straightforward to
+Many errors and warnings that LAMMPS outputs are self-explanatory and
-resolve.  However, there are also cases, where there is no single cause
+thus straightforward to resolve.  However, there are also cases where
-and explanation, where LAMMPS can only detect symptoms of an error but
+there is no single cause or simple explanation that can be provided in a
-not the exact cause, or where the explanation needs to be more detailed than
+short message printed by LAMMPS.  Therefore, more detailed discussions
-what can be fit into a message printed by the program.  The following are
+of such scenarios are provided here; first on a more general level and
-discussions of such cases.
+then for specific errors.  In the latter cases, LAMMPS will output a
 short message and then provide a URL that links to a specific section on
 this page.
 .. contents::
 ------
 General troubleshooting advice
 ------------------------------
 Below are suggestions that can help to understand the causes of problems
 with simulations leading to errors or unexpected results.
 .. _hint01:
 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.
 .. _hint02:
 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).
 .. _hint03:
 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.
 .. _hint04:
 Segmentation Fault
 ^^^^^^^^^^^^^^^^^^
 A segmentation fault is an error reported by the **operating system**
 and not LAMMPS itself.  It happens when a process tries to access a
 memory address that is not available.  This can have **many** reasons:
 memory has not been allocated, a memory buffer is not large enough, a
 memory address is computed from an incorrect index, a memory buffer is
 used after it has been freed, some general memory corruption.  When
 investigating a segmentation fault (aka segfault), it is important to
 determine which process is causing it; it may not always be LAMMPS.  For
 example, some MPI library implementations report a segmentation fault
 from their "mpirun" or "mpiexec" command when the application has been
 terminated unexpectedly.
 While a segmentation fault is likely an indication of a bug in LAMMPS,
 it need not always be; it can also be the consequence of too aggressive
 simulation settings.  For time critical code paths, LAMMPS will assume
 the user has chosen the settings carefully and will not make any checks
 to avoid to avoid performance penalties.
 A crucial step in resolving a segmentation fault is to identify the
 exact location in the code where it happens.  Please see `Errors_debug`
 for a couple of examples showing how to do this on a Linux machine.
 With this information -- a simple way to reproduce the segmentation
 fault and the exact :doc:`LAMMPS version <Manual_version>` and platform
 you are running on -- you can contact the LAMMPS developers or post in
 the LAMMPS forum to get assistance.
 .. _hint05:
 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 a 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 run depends on the steepness of the
 potential function and their mass.  Since the positions and velocities
 of atoms are computed with finite timesteps, the timestep needs to be
 small enough for stable numeric integration of the trajectory.  If the
 timestep is too large during initialization (or other instances of
 extreme dynamics), using :doc:`fix nve/limit <fix_nve_limit>` or
 :doc:`fix dt/reset <fix_dt_reset>` temporarily can help to avoid too
 large updates or adapt the timestep according to the displacements.
 .. _hint06:
 Ignoring lost atoms
 ^^^^^^^^^^^^^^^^^^^
 It is tempting to use the :doc:`thermo_modify lost ignore
 <thermo_modify>` to avoid LAMMPS aborting with an error on lost atoms.
 This setting should, however, *only* be used when atoms *should* leave
 the system.  In general, ignoring a problem does not solve it.
 .. _hint07:
 Pressure, forces, positions becoming NaN or 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.
 .. _hint08:
 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 typically be sufficient for all bonded
 interactions.  But if the pair style cutoff is small, this may not be
 enough.  LAMMPS will print a warning in this case using some heuristic
 based on the equilibrium bond length, but that still 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.
 .. _hint09:
 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.
 .. _hint10:
 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.
 .. _hint11:
 No error message printed
 ^^^^^^^^^^^^^^^^^^^^^^^^
 In some cases -- especially when running in parallel with MPI -- LAMMPS
 may stop without displaying an error.  But the fact that nothing was
 displayed does not mean there was not an 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.
 .. _hint12:
 Errors before or after the simulation box is created
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 As critical step in a LAMMPS input is when the simulation box is
 defined, either with a :doc:`create_box command <create_box>`, a
 :doc:`read_data command <read_data>`, or a :doc:`read_restart command
 <read_restart>`.  After this step, certain settings are locked in (e.g.
 units, or number of atom, bond, angle, dihedral, improper types) and
 cannot be changed after that.  Consequently, commands that change such
 settings (e.g. :doc:`units <units>`) are only allowed before the box is
 defined.  Very few commands can be used before and after, like
 :doc:`pair_style <pair_style>` (but not :doc:`pair_coeff <pair_coeff>`).
 Most LAMMPS commands must be used after the simulation box is created.
 Consequently, LAMMPS will stop with an error, if a command is used in
 the wrong place.  This is not always obvious.  So index or string style
 :doc:`variables <variable>` can be expanded anywhere in the input, but
 equal style (or similar) variables can only be expanded before the box
 is defined if they do not reference anything that cannot be defined
 before the box (e.g. a compute or fix reference or a thermo keyword).
 ------
 .. _err0001:
@ -23,19 +255,20 @@ The header section informs LAMMPS how many entries or lines are expected
 in the various sections (like Atoms, Masses, Pair Coeffs, *etc.*\ ) of
 the data file.  If there is a mismatch, LAMMPS will either keep reading
 beyond the end of a section or stop reading before the section has
-ended.  In that case the next line will not contain a recognized keyword.
+ended.  In that case the next line will not contain a recognized
 keyword.
-Such a mismatch can also happen when the first line of the data
+Such a mismatch can also happen when the first line of the data is *not*
-is *not* a comment as required by the format, but a line with a valid
+a comment as required by the format, but a line with a valid header
-header keyword.  That would result in LAMMPS expecting, for instance,
+keyword.  That would result in LAMMPS expecting, for instance, 0 atoms
-0 atoms because the "atoms" header line is the first line and thus
+because the "atoms" header line is the first line and thus treated as a
-treated as a comment.
+comment.
 Another possibility to trigger this error is to have a keyword in the
 data file that corresponds to a fix (e.g. :doc:`fix cmap <fix_cmap>`)
 but the :doc:`read_data <read_data>` command is missing the (optional)
-arguments that identify the fix and the header keyword and section
+arguments that identify the fix and its header and section keywords.
-keyword or those arguments are inconsistent with the keywords in the
+Alternatively, those arguments are inconsistent with the keywords in the
 data file.
 .. _err0002:
@ -45,35 +278,676 @@ Incorrect format in ... section of data file
 This error happens when LAMMPS reads the contents of a section of a
 :doc:`data file <read_data>` and the number of parameters in the line
-differs from what is expected.  This most commonly happens, when the
+differs from what is expected.  This most commonly happens when the atom
-atom style is different from what is expected for a specific data file
+style is different from what is expected for a specific data file since
-since changing the atom style usually changes the format of the line.
+changing the atom style usually changes the format of the line.
-This error can also happen when the number of entries indicated in the
+This error can also occur when the number of entries indicated in the
 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
+causing LAMMPS to continue reading into the next section which has a
-would have a completely different format.
+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
+This error indicates that a variable command has the wrong number of
-specific variable command, but a common reason for that is a variable
+arguments.  A common reason for this is that the variable expression has
-expression that has whitespace but is not enclosed in single or double
+whitespace, but is not enclosed in single or double quotes.
 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
+individual commands, labels, names, and values separated by whitespace
-space or tab character).  For "words" that may contain whitespace, they
+(a space or tab character).  For "words" that may contain whitespace,
-have to be enclosed in single (') or double (") quotes.  The parser will
+they have to be enclosed in single (') or double (") quotes.  The parser
-then remove the outermost pair of quotes and then pass that string as
+will then remove the outermost pair of quotes and pass that string as
 "word" to the variable command.
-Thus missing quotes or accidental extra whitespace will lead to the
+Thus missing quotes or accidental extra whitespace will trigger this
-error shown in the header because the unquoted whitespace will result
+error because the unquoted whitespace will result in the text being
-in the text being broken into more "words", i.e. the variable expression
+broken into more "words", i.e. the variable expression being split.
-being split.
+
 .. _err0004:
 Out of range atoms - cannot compute ...
 ---------------------------------------
 The PPPM (and also PPPMDisp and MSM) methods need to assemble a grid of
 electron density data derived from the (partial) charges assigned to the
 atoms.  These 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.  The processor's grid 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,
 the neighbor list skin is too small, or the neighbor lists are not
 updated frequently enough.  The smeared charges cannot then 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, 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.
 Otherwise one can 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.
 .. _err0005:
 Bond (or angle, dihedral, improper, cmap, or shake) atoms missing
 -----------------------------------------------------------------
 The second atom needed to compute a particular bond (or the third or
 fourth atom for angle, dihedral, or improper) is missing on the
 indicated timestep and processor.  Typically, this is because the two
 bonded atoms have become too far apart relative to the communication
 cutoff distance for ghost atoms.  By default, the communication cutoff
 is set by the pair cutoff.  However, to accommodate larger distances
 between topologically connected atoms, it can be manually adjusted using
 :doc:`comm_modify <comm_modify>` at the cost of increased communication
 and more ghost atoms.  However, missing bond atoms may also indicate
 that there are unstable dynamics which caused the atoms to blow apart.
 In this scenario, increasing the communication distance will not solve
 the underlying issue.  Rather, see :ref:`Fast moving atoms <hint05>` and
 :ref:`Neighbor list settings <hint09>` in the general troubleshooting
 section above for ideas to fix unstable dynamics.
 If atoms are intended to be lost during a simulation (e.g. due to open
 boundary conditions or :doc:`fix evaporate <fix_evaporate>`) such that
 two bonded atoms may be lost at different times from each other, this
 error can be converted to a warning or turned off using the *lost/bond*
 keyword in the :doc:`thermo_modify <thermo_modify>` command.
 .. _err0006:
 Non-numeric atom coords or pressure or box dimensions - simulation unstable
 ---------------------------------------------------------------------------
 This error usually occurs due to overly aggressive simulation settings
 or issues with the system geometry or the potential.  See
 :ref:`Pressure, forces, positions becoming NaN or Inf <hint07>` above in
 the general troubleshooting section.  This error is more likely to
 happen during equilibration, so it can help to do a minimization before
 or even add a second or third minimization after running a few
 equilibration MD steps.  It also is more likely when directly using a
 Nose-Hoover (or other) barostat, and thus it may be advisable to run
 with only a thermostat for a bit until the potential energy has
 stabilized.
 .. _err007:
 Fix used in ... not computed at compatible time
 -----------------------------------------------
 Many fix styles are invoked only every *nevery* timesteps, which means
 their data is only valid on those steps.  When data from a fix is used
 as input for a compute, a dump, another fix, or thermo output, it must
 read that data at timesteps when the fix in question was invoked, i.e.
 on timesteps that are multiples of its *nevery* setting.  If this is not
 the case, LAMMPS will stop with an error.  To remedy this, it may be
 required to change the output frequency or the *nevery* setting of the
 fix.
 .. _err0008:
 Lost atoms ...
 --------------
 A simulation stopping with an error due to lost atoms can have multiple
 causes.  By default, LAMMPS checks for whether the total number of atoms
 is consistent with the sum of atoms "owned" by MPI processors every time
 that thermodynamic output is written.  In the majority of cases, lost
 atoms are unexpected and a result of extremely high velocities causing
 instabilities in the system.  Such velocities can result from a variety
 of issues.  For ideas on how to track down issues with unexpected lost
 atoms, see :ref:`Fast moving atoms <hint05>` and :ref:`Neighbor list
 settings <hint09>` in the general troubleshooting section above.  In
 specific situations however, losing atoms is expected material behavior
 (e.g. with sputtering and surface evaporation simulations), and an
 unwanted crash can be avoided by changing the :doc:`thermo_modify lost
 <thermo_modify>` keyword from the default 'error' to 'warn' or 'ignore'
 (though heed the advice in :ref:`Ignoring lost atoms <hint06>` above!).
 .. _err0009:
 Too many neighbor bins
 ----------------------
 The simulation box is or has become too large relative to the size of a
 neighbor bin (which in turn depends on the largest pair-wise cutoff by
 default) such that LAMMPS is unable to store the needed number of bins.
 This typically implies the simulation box has expanded too far.  That
 can occur 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.  This can also happen if the largest pair-wise cutoff is
 small.  In this case, the error can be avoided by using the
 :doc:`neigh_modify command <neigh_modify>` to set the bin width to a
 suitably large value.
 .. _err0010:
 Unrecognized ... style ... is part of ... package which is not enabled in this LAMMPS binary
 --------------------------------------------------------------------------------------------
 The LAMMPS executable (binary) being used was not compiled with a
 package containing the specified style.  This indicates that the
 executable needs to be re-built after enabling the correct package in
 the relevant Makefile or CMake build directory.  See
 :doc:`Section 3. Build LAMMPS <Build>` for more details.  One can check
 if the expected package and pair style is present in the executable by
 running it with the ``-help`` (or ``-h``) flag on the command line.  One
 common oversight, especially for beginner LAMMPS users, is enabling the
 package but forgetting to run commands to rebuild (e.g., to run the
 final ``make`` or ``cmake`` command).
 If this error occurs with an executable that the user does not control
 (e.g., through a module on HPC clusters), the user will need to get in
 contact with the relevant person or people who can update the
 executable.
 .. _err011:
 Energy or stress was not tallied by pair style
 ----------------------------------------------
 This warning can be printed by computes from the :ref:`TALLY package
 <PKG-TALLY>`.  Those use a callback mechanism that only work for regular
 pair-wise additive pair styles like :doc:`Lennard-Jones <pair_lj>`,
 :doc:`Morse <pair_morse>`, :doc:`Born-Meyer-Huggins <pair_born>`, and
 similar.  Such required callbacks have not been implemented for
 many-body potentials so one would have to implement them to add
 compatibility with these computes (which may be difficult to do in a
 generic fashion).  Whether this warning indicates that contributions to
 the computed properties are missing depends on the groups used.  At any
 rate, careful testing of the results is advised when this warning
 appears.
 .. _err0012:
 fmt::format_error
 -----------------
 LAMMPS uses the `{fmt} library <https://fmt.dev>`_ for advanced string
 formatting tasks.  This is similar to the ``printf()`` family of
 functions from the standard C library, but more flexible.  If there is a
 bug in the LAMMPS code and the format string does not match the list of
 arguments or has some other error, this error message will be shown.
 You should contact the LAMMPS developers and report the bug as a `GitHub
 Bug Report Issue <https://github.com/lammps/lammps/issues>`_ along with
 sufficient information to easily reproduce it.
 .. _err0013:
 Substitution for illegal variable
 ---------------------------------
 A variable in an input script or a variable expression was not found in
 the list of valid variables.  The most common reason for this is a typo
 somewhere in the input file such that the expression uses an invalid
 variable name.  The second most common reason is omitting the curly
 braces for a direct variable with a name that is not a single letter.
 For example:
 .. code-block:: LAMMPS
   variable cutoff index 10.0
   pair_style lj/cut ${cutoff}  # this is correct
   pair_style lj/cut $cutoff    # this is incorrect, LAMMPS looks for 'c' instead of 'cutoff'
   variable c      index 5.0    # if $c is defined, LAMMPS subsitutes only '$c' and reads: 5utoff
 Another potential source of this error may be invalid command line
 variables (-var or -v argument) used when launching LAMMPS from an
 interactive shell or shell scripts.  An uncommon source for this error
 is using the :doc:`next command <next>` to advance through a list of
 values provided by an index style variable.  If there is no remaining
 element in the list, LAMMPS will delete the variable and any following
 expansion or reference attempt will trigger the error.
 Users with harder-to-track variable errors might also find reading the
 :doc:`Parsing rules for input scripts <Commands_parse>` helpful.
 .. _err0014:
 Bond atom missing in image check or box size check
 --------------------------------------------------
 This can be either an error or a warning depending on your
 :doc:`thermo_modify settings <thermo_modify>`.  It is flagged in a part
 of the LAMMPS code where it updates the domain decomposition and before
 it builds the neighbor lists.  It checks that both atoms of a bond are
 within the communication cutoff of a subdomain.  It is usually caused by
 atoms moving too fast (see the :ref:`paragraph on fast moving atoms
 <hint05>`), or by the :doc:`communication cutoff being too small
 <comm_modify>`, or by waiting too long between :doc:`sub-domain and
 neighbor list updates <neigh_modify>`.
 .. _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.
 .. _err0016:
 Did not assign all atoms correctly
 ----------------------------------
 This error happens most commonly when :doc:`reading a data file
 <read_data>` under :doc:`non-periodic boundary conditions<boundary>`.
 Only atoms with positions **inside** the simulation box will be read and
 thus any atoms outside the box will be skipped and the total atom count
 will not match, which triggers the error.  This does not happen with
 periodic boundary conditions where atoms outside the principal box will
 be "wrapped" into the principal box and their image flags set
 accordingly.
 Similar errors can happen with the :doc:`replicate command<replicate>`
 or the :doc:`read_restart command<read_restart>`.  In these cases the
 cause may be a problematic geometry, an insufficient communication
 cutoff, or a bug in the LAMMPS source code.  In these cases it is
 advisable to set up :ref:`small test case <hint01>` for testing and
 debugging.  This will be required in case you need to get help from a
 LAMMPS developer.
 .. _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 a great distance out of
 the simulation box or a fix (like fix deform or a barostat) has
 excessively grown the simulation box.
 .. _err0018:
 Step X: (h)bondchk failed
 -------------------------
 This error is a consequence of the heuristic memory allocations for
 buffers of the regular ReaxFF version.  In ReaxFF simulations, the lists
 of bonds and hydrogen bonds can change due to chemical reactions.  The
 default approach, however, assumes that these changes are not very
 large, so it allocates buffers for the current system setup plus a
 safety margin.  This can be adjusted with the :doc:`safezone, mincap,
 and minhbonds settings of the pair style <pair_reaxff>`, but only to
 some extent.  When equilibrating a new system, or simulating a sparse
 system in parallel, this can be difficult to control and become
 wasteful.  A simple workaround is often to break a simulation down in
 multiple chunks.  A better approach, however, is to compile and use the
 KOKKOS package version of ReaxFF (you do not need a GPU for that, but
 can also compile it in serial or OpenMP mode), which uses a more robust
 memory allocation approach.
 .. _err0019:
 Numeric index X is out of bounds
 --------------------------------
 This error most commonly happens when setting force field coefficients
 with either the :doc:`pair_coeff <pair_coeff>`, the :doc:`bond_coeff
 <bond_coeff>`, the :doc:`angle_coeff <angle_coeff>`, the
 :doc:`dihedral_coeff <dihedral_coeff>`, or the :doc:`improper_coeff
 <improper_coeff>` command.  These commands accept type labels, explicit
 numbers, and wildcards for ranges of numbers.  If the numeric value of
 any of these is outside the valid range (defined by the number of
 corresponding types), LAMMPS will stop with this error.  A few other
 commands and styles also allow ranges of numbers and check using the
 same method and thus print the same kind of error.
 The cause is almost always a typo in the input or a logic error when
 defining the values or ranges.  So one needs to carefully review the
 input.  Along with the error, LAMMPS will print the valid range as a
 hint.
 .. _err0020:
 Compute, fix, or variable vector or array is accessed out-of-range
 ------------------------------------------------------------------
 When accessing an individual element of a global vector or array or a
 per-atom vector or array provided by a compute or fix or atom-style or
 vector-style variable or data from a specific atom, an index in square
 brackets ("[ ]") (or two indices) must be provided to determine which
 element to access and it must be in a valid range or else LAMMPS would
 access invalid data or crash with a segmentation fault.  In the two most
 common cases, where this data is accessed, :doc:`variable expressions
 <variable>` and :doc:`thermodynamic output <thermo_style>`, LAMMPS will
 check for valid indices and stop with an error otherwise.
 While LAMMPS is written in C++ (which uses 0 based indexing) these
 indices start at 1 (i.e. similar to Fortran).  Any index smaller than 1
 or larger than the maximum allowed value should trigger this error.
 Since this kind of error frequently happens with rather complex
 expressions, it is recommended to test these with small test systems,
 where the values can be tracked with output files for all relevant
 properties at every step.
 .. _err0021:
 Incorrect args for pair coefficients (also bond/angle/dihedral/improper coefficients)
 -------------------------------------------------------------------------------------
 The parameters in the :doc:`pair_coeff <pair_coeff>` command for a
 specified :doc:`pair_style <pair_style>` have a missing or erroneous
 argument.  The same applies when seeing this error for :doc:`bond_coeff
 <bond_coeff>`, :doc:`angle_coeff <angle_coeff>`, :doc:`dihedral_coeff
 <dihedral_coeff>`, or :doc:`improper_coeff <improper_coeff>` and their
 respective style commands when using the MOLECULE or EXTRA-MOLECULE
 packages.  The cases below describe some ways to approach pair
 coefficient errors, but the same strategies apply to bonded systems as
 well.
 Outside of normal typos, this error can have several sources.  In all
 cases, the first step is to compare the command arguments to the
 expected format found in the corresponding :doc:`pair_style
 <pair_style>` page.  This can reveal cases where, for example, a pair
 style was changed, but the pair coefficients were not updated.  This can
 happen especially with pair style variants such as :doc:`pair_style eam
 <pair_eam>` vs. :doc:`pair_style eam/alloy <pair_style>` that look very
 similar but accept different parameters (the latter 'eam/alloy' variant
 takes element type names while 'eam' does not).
 Another common source of coefficient errors is when using multiple pair
 styles with commands such as :doc:`pair_style hybrid <pair_hybrid>`.
 Using hybrid pair styles requires adding an extra "label" argument in
 the coefficient commands that designates which pair style the command
 line refers to.  Moreover, if the same pair style is used multiple
 times, this label must be followed by an additional numeric argument.
 Also, different pair styles may require different arguments.
 This error message might also require a close look at other LAMMPS input
 files that are read in by the input script, such as data files or
 restart files.
 .. _err0022:
 Energy was not tallied on needed timestep (also virial, per-atom energy, per-atom virial)
 -----------------------------------------------------------------------------------------
 This error is generated when LAMMPS attempts to access an out-of-date or
 non-existent energy, pressure, or virial.  For efficiency reasons,
 LAMMPS does *not* calculate these quantities when the forces are
 calculated on every timestep or iteration.  Global quantities are only
 calculated when they are needed for :doc:`thermo <thermo_style>` output
 (at the beginning, end, and at regular intervals specified by the
 :doc:`thermo <thermo>` command).  Similarly, per-atom quantities are
 only calculated if they are needed to write per-atom energy or virial to
 a dump file.  This system works fine for simple input scripts.  However,
 the many user-specified `variable`, `fix`, and `compute` commands that
 LAMMPS provides make it difficult to anticipate when a quantity will be
 requested.  In some use cases, LAMMPS will figure out that a quantity is
 needed and arrange for it to be calculated on that timestep e.g. if it
 is requested by :doc:`fix ave/time <fix_ave_time>` or similar commands.
 If that fails, it can be detected by a mismatch between the current
 timestep and when a quantity was last calculated, in which case an error
 message of this type is generated.
 The most common cause of this type of error is requesting a quantity
 before the start of the simulation.
 .. code-block:: LAMMPS
   # run 0 post no               # this will fix the error
   variable e equal pe           # requesting energy compute
   print "Potential energy = $e" # this will generate the error
   run 1000                      # start of simulation
 This situation can be avoided by adding in a "run 0" command, as
 explained in more detail in the "Variable Accuracy" section of the
 :doc:`variable <variable>` doc page.
 Another cause is requesting a quantity on a timestep that is not a
 thermo or dump output timestep.  This can often be remedied by
 increasing the frequency of thermo or dump output.
 .. _err0023:
 Molecule auto special bond generation overflow
 ----------------------------------------------
 In order to correctly apply the :doc:`special_bonds <special_bonds>`
 settings (also known as "exclusions"), LAMMPS needs to maintain for each
 atom a list of atoms that are connected to this atom, either directly
 with a bond or indirectly through bonding with an intermediate atom(s).
 The purpose is to either remove or tag those pairs of atoms in the
 neighbor list.  This information is stored with individual atoms and
 thus the maximum number of such "special" neighbors is set when the
 simulation box is created.  When reading (relative) geometry and
 topology of a 'molecule' from a :doc:`molecule file <molecule>`, LAMMPS
 will build the list of such "special" neighbors for the molecule atom
 (if not given in the molecule file explicitly).  The error is triggered
 when the resulting list is too long for the space reserved when creating
 the simulation box.  The solution is to increase the corresponding
 setting.  Overestimating this value will only consume more memory, and
 is thus a safe choice.
 .. _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 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.
 .. _err0027:
 Inconsistent image flags
 ------------------------
 This warning happens when the distance between the *unwrapped* x-, y-,
 or z-components of the coordinates of a bond is larger than half the box
 with periodic boundaries or larger than the box with non-periodic
 boundaries.  It means that the positions and image flags have become
 inconsistent.  LAMMPS will still compute bonded interactions based on
 the closest periodic images of the atoms and thus in most cases the
 results will be correct.  However they can cause problems when such
 atoms are used with the fix rigid or replicate commands.  Thus, it is
 good practice to update the system so that the message does not appear.
 It will help with future manipulations of the system.
 There is one case where this warning *must* appear: when you have a
 chain of connected bonds that pass through the entire box and connect
 back to the first atom in the chain through periodic boundaries,
 i.e. some kind of "infinite polymer".  In that case, the bond image
 flags *must* be inconsistent for the one bond that reaches back to the
 beginning of the chain.
 .. _err0028:
 No fixes with time integration, atoms won't move
 ------------------------------------------------
 This warning will be issued if LAMMPS encounters a :doc:`run <run>`
 command that does not have a preceding :doc:`fix <fix>` command that
 updates atom/object positions and velocities per step.  In other words,
 there are no fixes detected that perform velocity-Verlet time
 integration, such as :doc:`fix nve <fix_nve>`.  Note that this alert
 does not mean that there are no active fixes.  LAMMPS has a very wide
 variety of fixes, many of which do not move objects but also operate
 through steps, such as printing outputs (e.g. :doc:`fix print
 <fix_print>`), performing calculations (e.g. :doc:`fix ave/time
 <fix_ave_time>`), or changing other system parameters (e.g. :doc:`fix
 dt/reset <fix_dt_reset>`).  It is up to the user to determine whether
 the lack of a time-integrating fix is intentional or not.
 .. _err0029:
 System is not charge neutral, net charge = ...
 ----------------------------------------------
 the sum of charges in the system is not zero.  When a system is not
 charge-neutral, methods that evolve/manipulate per-atom charges,
 evaluate Coulomb interactions, evaluate Coulomb forces, or
 evaluate/manipulate other properties relying on per-atom charges may
 raise this warning.  A non-zero net charge most commonly arises after
 setting per-atom charges :doc:`set <set>` such that the sum is non-zero
 or by reading in a system through :doc:`read_data <read_data>` where the
 per-atom charges do not sum to zero.  However, a loss of charge
 neutrality may occur in other less common ways, like when charge
 equilibration methods (e.g., :doc:`fix qeq <fix_qeq>`) fail.
 A similar warning/error may be raised when using certain charge
 equilibration methods: :doc:`fix qeq <fix_qeq>`, :doc:`fix qeq/comb
 <fix_qeq_comb>`, :doc:`fix qeq/reaxff <fix_qeq_reaxff>`, and :doc:`fix
 qtpie/reaxff <fix_qtpie_reaxff>`.  In such cases, this warning/error
 will be raised for the fix :doc:`group <group>` when the group has a
 non-zero net charge.
 When the system is expected to be charge-neutral, this warning often
 arises due to an error in the lammps input (e.g., an incorrect :doc:`set
 <set>` command, error in the data file read by :doc:`read_data
 <read_data>`, incorrectly grouping atoms with charge, etc.).  If the
 system is NOT expected to be charge-neutral, the user should make sure
 that the method(s) used are appropriate for systems with a non-zero net
 charge.  Some commonly used fixes for charge equilibration :doc:`fix qeq
 <fix_qeq>`, pair styles that include charge interactions
 :doc:`pair_style coul/XXX <pair_coul>`, and kspace methods
 :doc:`kspace_style <kspace_style>` can, in theory, support systems with
 non-zero net charge.  However, non-zero net charge can lead to spurious
 artifacts.  The severity of these artifacts depends on the magnitude of
 total charge, system size, and methods used.  Before running simulations
 or calculations for systems with non-zero net charge, users should test
 for artifacts and convergence of properties.
 .. _err0030:
 Variable evaluation before simulation box is defined
 ----------------------------------------------------
 This error happens, when trying to expand or use an equal- or atom-style
 variable (or an equivalent style), where the expression contains a
 reference to something (e.g. a compute reference, a property of an atom,
 or a thermo keyword) that is not allowed to be used before the
 simulation box is defined.  See the paragraph on :ref:`errors before or
 after the simulation box is created <hint12>` for additional
 information.
 .. _err0031:
 Invalid thermo keyword 'X' in variable formula
 ----------------------------------------------
 This error message is often misleading.  It is caused when evaluating a
 :doc:`variable command <variable>` expression and LAMMPS comes across a
 string that it does not recognize.  LAMMPS first checks if a string is a
 reference to a compute, fix, custom property, or another variable by
 looking at the first 2-3 characters (and if it is, it checks whether the
 referenced item exists).  Next LAMMPS checks if the string matches one
 of the available functions or constants.  If that fails, LAMMPS will
 assume that this string is a :doc:`thermo keyword <thermo_style>` and
 let the code for printing thermodynamic output return the corresponding
 value.  However, if this fails too, since the string is not a thermo
 keyword, LAMMPS stops with the 'Invalid thermo keyword' error.  But it
 is also possible, that there is just a typo in the name of a valid
 variable function.  Thus it is recommended to check the failing variable
 expression very carefully.
 .. _err0032:
 One or more atoms are time integrated more than once
 ----------------------------------------------------
 This is probably an error since you typically do not want to advance the
 positions or velocities of an atom more than once per timestep.  This
 typically happens when there are multiple fix commands that advance atom
 positions with overlapping groups.  Also, for some fix styles it is not
 immediately obvious that they include time integration.  Please check
 the documentation carefully.
 .. _err0033:
 XXX command before simulation box is defined
 --------------------------------------------
 This error occurs when trying to execute a LAMMPS command that requires
 information about the system dimensions, or the number atom, bond,
 angle, dihedral, or improper types, or the number of atoms or similar
 data that is only available *after* the simulation box has been created.
 See the paragraph on :ref:`errors before or after the simulation box is
 created <hint12>` for additional information.
 .. _err0034:
 XXX command after simulation box is defined
 --------------------------------------------
 This error occurs when trying to execute a LAMMPS command that changes a
 global setting *after* it is locked in when the simulation box is
 created (for instance defining the :doc:`atom style <atom_style>`,
 :doc:`dimension <dimension>`, :doc:`newton <newton>`, or :doc:`units
 <units>` setting).  These settings may only be changed *before* the
 simulation box has been created.  See the paragraph on :ref:`errors
 before or after the simulation box is created <hint12>` for additional
 information.
--- a/doc/src/Errors_messages.rst
+++ b/doc/src/Errors_messages.rst
--- a/doc/src/Errors_warnings.rst
+++ b/doc/src/Errors_warnings.rst
@ -1,11 +1,15 @@
 Warning messages
 ================
-This is an alphabetic list of the WARNING messages LAMMPS prints out
+This is an alphabetic list of some of the WARNING messages LAMMPS prints
-and the reason why.  If the explanation here is not sufficient, the
+out and the reason why.  If the explanation here is not sufficient, the
-documentation for the offending command may help.  Warning messages
+documentation for the offending command may help.  This is a historic
-also list the source file and line number where the warning was
+list and no longer updated.  Instead the LAMMPS developers are trying
-generated.  For example, a message like this:
+to provide more details right with the error message or link to a
 paragraph with :doc:`detailed explanations <Errors_details>`.
 Warning messages also list the source file and line number where the
 warning was generated.  For example, a message like this:
 .. parsed-literal::
@ -14,7 +18,7 @@ generated.  For example, a message like this:
 means that line #187 in the file src/domain.cpp generated the error.
 Looking in the source code may help you figure out what went wrong.
-Doc page with :doc:`ERROR messages <Errors_messages>`
+Please also see the page with :doc:`Error messages <Errors_messages>`
 ----------
@ -28,16 +32,10 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
   cutoff is set too short or the angle has blown apart and an atom is
   too far away.
 *Angle style in data file differs from currently defined angle style*
   Self-explanatory.
 *Angles are defined but no angle style is set*
   The topology contains angles, but there are no angle forces computed
   since there was no angle_style command.
 *Atom style in data file differs from currently defined atom style*
   Self-explanatory.
 *Bond atom missing in box size check*
   The second atom needed to compute a particular bond is missing on this
   processor.  Typically this is because the pairwise cutoff is set too
@ -53,9 +51,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
   processor.  Typically this is because the pairwise cutoff is set too
   short or the bond has blown apart and an atom is too far away.
 *Bond style in data file differs from currently defined bond style*
   Self-explanatory.
 *Bonds are defined but no bond style is set*
   The topology contains bonds, but there are no bond forces computed
   since there was no bond_style command.
@ -68,9 +63,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
   length, multiplying by the number of bonds in the interaction (e.g. 3
   for a dihedral) and adding a small amount of stretch.
 *Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero*
   Self-explanatory.
 *Calling write_dump before a full system init.*
   The write_dump command is used before the system has been fully
   initialized as part of a 'run' or 'minimize' command. Not all dump
@ -86,18 +78,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
   This means the temperature associated with the rigid bodies may be
   incorrect on this timestep.
 *Cannot include log terms without 1/r terms; setting flagHI to 1*
   Self-explanatory.
 *Cannot include log terms without 1/r terms; setting flagHI to 1.*
   Self-explanatory.
 *Charges are set, but coulombic solver is not used*
   Self-explanatory.
 *Charges did not converge at step %ld: %lg*
   Self-explanatory.
 *Communication cutoff is 0.0. No ghost atoms will be generated. Atoms may get lost*
   The communication cutoff defaults to the maximum of what is inferred from
   pair and bond styles (will be zero, if none are defined) and what is specified
@ -123,9 +103,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
   is not changed automatically and the warning may be ignored depending
   on the specific system being simulated.
 *Communication cutoff is too small for SNAP micro load balancing, increased to %lf*
   Self-explanatory.
 *Compute cna/atom cutoff may be too large to find ghost atom neighbors*
   The neighbor cutoff used may not encompass enough ghost atoms
   to perform this operation correctly.
@ -158,9 +135,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
   Conformation of the 4 listed dihedral atoms is extreme; you may want
   to check your simulation geometry.
 *Dihedral style in data file differs from currently defined dihedral style*
   Self-explanatory.
 *Dihedrals are defined but no dihedral style is set*
   The topology contains dihedrals, but there are no dihedral forces computed
   since there was no dihedral_style command.
@ -177,9 +151,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 *Estimated error in splitting of dispersion coeffs is %g*
   Error is greater than 0.0001 percent.
 *Ewald/disp Newton solver failed, using old method to estimate g_ewald*
   Self-explanatory. Choosing a different cutoff value may help.
 *FENE bond too long*
   A FENE bond has stretched dangerously far.  It's interaction strength
   will be truncated to attempt to prevent the bond from blowing up.
@ -192,9 +163,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
   A FENE bond has stretched dangerously far.  It's interaction strength
   will be truncated to attempt to prevent the bond from blowing up.
 *Fix halt condition for fix-id %s met on step %ld with value %g*
   Self explanatory.
 *Fix SRD walls overlap but fix srd overlap not set*
   You likely want to set this in your input script.
@ -238,21 +206,12 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 *Fix property/atom mol or charge w/out ghost communication*
   A model typically needs these properties defined for ghost atoms.
 *Fix qeq CG convergence failed (%g) after %d iterations at %ld step*
   Self-explanatory.
 *Fix qeq has non-zero lower Taper radius cutoff*
   Absolute value must be <= 0.01.
 *Fix qeq has very low Taper radius cutoff*
   Value should typically be >= 5.0.
 *Fix qeq/dynamic tolerance may be too small for damped dynamics*
   Self-explanatory.
 *Fix qeq/fire tolerance may be too small for damped fires*
   Self-explanatory.
 *Fix rattle should come after all other integration fixes*
   This fix is designed to work after all other integration fixes change
   atom positions.  Thus it should be the last integration fix specified.
@ -285,9 +244,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
   The user-specified force accuracy cannot be achieved unless the table
   feature is disabled by using 'pair_modify table 0'.
 *Geometric mixing assumed for 1/r\^6 coefficients*
   Self-explanatory.
 *Group for fix_modify temp != fix group*
   The fix_modify command is specifying a temperature computation that
   computes a temperature on a different group of atoms than the fix
@ -310,46 +266,14 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
   Conformation of the 4 listed improper atoms is extreme; you may want
   to check your simulation geometry.
 *Improper style in data file differs from currently defined improper style*
   Self-explanatory.
 *Impropers are defined but no improper style is set*
   The topology contains impropers, but there are no improper forces computed
   since there was no improper_style command.
 *Inconsistent image flags*
   The image flags for a pair on bonded atoms appear to be inconsistent.
   Inconsistent means that when the coordinates of the two atoms are
   unwrapped using the image flags, the two atoms are far apart.
   Specifically they are further apart than half a periodic box length.
   Or they are more than a box length apart in a non-periodic dimension.
   This is usually due to the initial data file not having correct image
   flags for the two atoms in a bond that straddles a periodic boundary.
   They should be different by 1 in that case.  This is a warning because
   inconsistent image flags will not cause problems for dynamics or most
   LAMMPS simulations.  However they can cause problems when such atoms
   are used with the fix rigid or replicate commands.  Note that if you
   have an infinite periodic crystal with bonds then it is impossible to
   have fully consistent image flags, since some bonds will cross
   periodic boundaries and connect two atoms with the same image
   flag.
 *Increasing communication cutoff for GPU style*
   The pair style has increased the communication cutoff to be consistent with
   the communication cutoff requirements for this pair style when run on the GPU.
 *KIM Model does not provide 'energy'; Potential energy will be zero*
   Self-explanatory.
 *KIM Model does not provide 'forces'; Forces will be zero*
   Self-explanatory.
 *KIM Model does not provide 'particleEnergy'; energy per atom will be zero*
   Self-explanatory.
 *KIM Model does not provide 'particleVirial'; virial per atom will be zero*
   Self-explanatory.
 *Kspace_modify slab param < 2.0 may cause unphysical behavior*
   The kspace_modify slab parameter should be larger to ensure periodic
   grids padded with empty space do not overlap.
@ -401,20 +325,10 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
   box, or moved further than one processor's subdomain away before
   reneighboring.
 *MSM mesh too small, increasing to 2 points in each direction*
   Self-explanatory.
 *Mismatch between velocity and compute groups*
   The temperature computation used by the velocity command will not be
   on the same group of atoms that velocities are being set for.
 *Mixing forced for lj coefficients*
   Self-explanatory.
 *Molecule attributes do not match system attributes*
   An attribute is specified (e.g. diameter, charge) that is
   not defined for the specified atom style.
 *Molecule has bond topology but no special bond settings*
   This means the bonded atoms will not be excluded in pairwise
   interactions.
@ -449,9 +363,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 *More than one compute damage/atom*
   It is not efficient to use compute ke/atom more than once.
 *More than one compute dilatation/atom*
   Self-explanatory.
 *More than one compute erotate/sphere/atom*
   It is not efficient to use compute erorate/sphere/atom more than once.
@ -464,24 +375,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 *More than one compute orientorder/atom*
   It is not efficient to use compute orientorder/atom more than once.
 *More than one compute plasticity/atom*
   Self-explanatory.
 *More than one compute sna/atom*
   Self-explanatory.
 *More than one compute sna/grid*
   Self-explanatory.
 *More than one compute sna/grid/local*
   Self-explanatory.
 *More than one compute snad/atom*
   Self-explanatory.
 *More than one compute snav/atom*
   Self-explanatory.
 *More than one fix poems*
   It is not efficient to use fix poems more than once.
@ -557,21 +450,12 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 *Pair COMB charge %.10f with force %.10f hit min barrier*
   Something is possibly wrong with your model.
 *Pair brownian needs newton pair on for momentum conservation*
   Self-explanatory.
 *Pair dpd needs newton pair on for momentum conservation*
   Self-explanatory.
 *Pair dsmc: num_of_collisions > number_of_A*
   Collision model in DSMC is breaking down.
 *Pair dsmc: num_of_collisions > number_of_B*
   Collision model in DSMC is breaking down.
 *Pair style in data file differs from currently defined pair style*
   Self-explanatory.
 *Pair style restartinfo set but has no restart support*
   This pair style has a bug, where it does not support reading and
   writing information to a restart file, but does not set the member
@ -681,9 +565,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
   cluster specified by the fix shake command is numerically suspect.  LAMMPS
   will set it to 0.0 and continue.
 *Shell command '%s' failed with error '%s'*
   Self-explanatory.
 *Shell command returned with non-zero status*
   This may indicate the shell command did not operate as expected.
@ -694,15 +575,9 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
   This will lead to invalid constraint forces in the SHAKE/RATTLE
   computation.
 *Simulations might be very slow because of large number of structure factors*
   Self-explanatory.
 *Slab correction not needed for MSM*
   Slab correction is intended to be used with Ewald or PPPM and is not needed by MSM.
 *Specifying an 'subset' value of '0' is equivalent to no 'subset' keyword*
   Self-explanatory.
 *System is not charge neutral, net charge = %g*
   The total charge on all atoms on the system is not 0.0.
   For some KSpace solvers this is only a warning.
@ -734,9 +609,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
   assumed to also be for all atoms.  Thus the pressure printed by thermo
   could be inaccurate.
 *The fix ave/spatial command has been replaced by the more flexible fix ave/chunk and compute chunk/atom commands -- fix ave/spatial will be removed in the summer of 2015*
   Self-explanatory.
 *The minimizer does not re-orient dipoles when using fix efield*
   This means that only the atom coordinates will be minimized,
   not the orientation of the dipoles.
@ -745,9 +617,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
   More than the maximum # of neighbors was found multiple times.  This
   was unexpected.
 *Too many inner timesteps in fix ttm*
   Self-explanatory.
 *Too many neighbors in CNA for %d atoms*
   More than the maximum # of neighbors was found multiple times.  This
   was unexpected.
@ -775,24 +644,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
   The deformation will heat the SRD particles so this can
   be dangerous.
 *Using kspace solver on system with no charge*
   Self-explanatory.
 *Using largest cut-off for lj/long/dipole/long long long*
   Self-explanatory.
 *Using largest cutoff for buck/long/coul/long*
   Self-explanatory.
 *Using largest cutoff for lj/long/coul/long*
   Self-explanatory.
 *Using largest cutoff for pair_style lj/long/tip4p/long*
   Self-explanatory.
 *Using package gpu without any pair style defined*
   Self-explanatory.
 *Using pair potential shift with pair_modify compute no*
   The shift effects will thus not be computed.
--- a/doc/src/Examples.rst
+++ b/doc/src/Examples.rst
@ -54,7 +54,7 @@ Lowercase directories
 +-------------+------------------------------------------------------------------+
 | body        | body particles, 2d system                                        |
 +-------------+------------------------------------------------------------------+
-| bpm         | BPM simulations of pouring elastic grains and plate impact       |
+| bpm         | simulations of solid elastic/plastic deformation and fracture    |
 +-------------+------------------------------------------------------------------+
 | cmap        | CMAP 5-body contributions to CHARMM force field                  |
 +-------------+------------------------------------------------------------------+
@ -146,6 +146,8 @@ Lowercase directories
 +-------------+------------------------------------------------------------------+
 | streitz     | use of Streitz/Mintmire potential with charge equilibration      |
 +-------------+------------------------------------------------------------------+
 | stress_vcm  | removing binned rigid body motion from binned stress profile     |
 +-------------+------------------------------------------------------------------+
 | tad         | temperature-accelerated dynamics of vacancy diffusion in bulk Si |
 +-------------+------------------------------------------------------------------+
 | threebody   | regression test input for a variety of manybody potentials       |
--- a/doc/src/Fortran.rst
+++ b/doc/src/Fortran.rst
@ -321,6 +321,14 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
   :ftype set_string_variable: subroutine
   :f set_internal_variable: :f:subr:`set_internal_variable`
   :ftype set_internal_variable: subroutine
   :f eval: :f:func:`eval`
   :ftype eval: function
   :f clearstep_compute: :f:subr:`clearstep_compute`
   :ftype clearstep_compute: subroutine
   :f addstep_compute: :f:subr:`addstep_compute`
   :ftype addstep_compute: subroutine
   :f addstep_compute_all: :f:subr:`addstep_compute_all`
   :ftype addstep_compute_all: subroutine
   :f gather_atoms: :f:subr:`gather_atoms`
   :ftype gather_atoms: subroutine
   :f gather_atoms_concat: :f:subr:`gather_atoms_concat`
@ -954,6 +962,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type
      :f:func:`extract_atom` between runs.
   .. admonition:: Array index order
      :class: tip
      Two-dimensional arrays returned from :f:func:`extract_atom` will be
      **transposed** from equivalent arrays in C, and they will be indexed
@ -1066,6 +1075,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type
   you based on data from the :cpp:class:`Compute` class.
   .. admonition:: Array index order
      :class: tip
      Two-dimensional arrays returned from :f:func:`extract_compute` will be
      **transposed** from equivalent arrays in C, and they will be indexed
@ -1324,6 +1334,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type
   :rtype data: polymorphic
   .. admonition:: Array index order
      :class: tip
      Two-dimensional global, per-atom, or local array data from
      :f:func:`extract_fix` will be **transposed** from equivalent arrays in
@ -1448,11 +1459,62 @@ Procedures Bound to the :f:type:`lammps` Derived Type
   an internal-style variable, an error is generated.
   :p character(len=*) name: name of the variable
-   :p read(c_double) val:  new value to assign to the variable
+   :p real(c_double) val:  new value to assign to the variable
   :to: :cpp:func:`lammps_set_internal_variable`
 --------
 .. f:function:: eval(expr)
   This function is a wrapper around :cpp:func:`lammps_eval` that takes a
   LAMMPS equal style variable string, evaluates it and returns the resulting
   scalar value as a floating-point number.
   .. versionadded:: 4Feb2025
   :p character(len=\*) expr: string to be evaluated
   :to: :cpp:func:`lammps_eval`
   :r value [real(c_double)]: result of the evaluated string
 --------
 .. f:subroutine:: clearstep_compute()
   Clear whether a compute has been invoked
   .. versionadded:: 4Feb2025
   :to: :cpp:func:`lammps_clearstep_compute`
 --------
 .. f:subroutine:: addstep_compute(nextstep)
   Add timestep to list of future compute invocations
   if the compute has been invoked on the current timestep
   .. versionadded:: 4Feb2025
   overloaded for 32-bit and 64-bit integer arguments
   :p integer(kind=8 or kind=4) nextstep: next timestep
   :to: :cpp:func:`lammps_addstep_compute`
 --------
 .. f:subroutine:: addstep_compute_all(nextstep)
   Add timestep to list of future compute invocations
   .. versionadded:: 4Feb2025
   overloaded for 32-bit and 64-bit integer arguments
   :p integer(kind=8 or kind=4) nextstep: next timestep
   :to: :cpp:func:`lammps_addstep_compute_all`
 --------
 .. f:subroutine:: gather_atoms(name, count, data)
   This function calls :cpp:func:`lammps_gather_atoms` to gather the named
@ -2711,8 +2773,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type
        END SUBROUTINE external_callback
      END INTERFACE
-   where ``c_bigint`` is ``c_int`` if ``-DLAMMPS_SMALLSMALL`` was used and
+   where ``c_bigint`` is ``c_int64_t`` and ``c_tagint`` is ``c_int64_t`` if
   ``c_int64_t`` otherwise; and ``c_tagint`` is ``c_int64_t`` if
   ``-DLAMMPS_BIGBIG`` was used and ``c_int`` otherwise.
   The argument *caller* to :f:subr:`set_fix_external_callback` is unlimited
--- a/doc/src/Howto.rst
+++ b/doc/src/Howto.rst
@ -40,6 +40,7 @@ Settings howto
   Howto_walls
   Howto_nemd
   Howto_dispersion
   Howto_bulk2slab
 Analysis howto
 ==============
@ -103,6 +104,7 @@ Tutorials howto
   Howto_github
   Howto_lammps_gui
   Howto_moltemplate
   Howto_python
   Howto_pylammps
   Howto_wsl
--- a/doc/src/Howto_barostat.rst
+++ b/doc/src/Howto_barostat.rst
@ -10,20 +10,21 @@ and/or pressure (P) is specified by the user, and the thermostat or
 barostat attempts to equilibrate the system to the requested T and/or
 P.
-Barostatting in LAMMPS is performed by :doc:`fixes <fix>`.  Two
+Barostatting in LAMMPS is performed by :doc:`fixes <fix>`.  Three
 barostatting methods are currently available: Nose-Hoover (npt and
-nph) and Berendsen:
+nph), Berendsen, and various linear controllers in deform/pressure:
 * :doc:`fix npt <fix_nh>`
 * :doc:`fix npt/sphere <fix_npt_sphere>`
 * :doc:`fix npt/asphere <fix_npt_asphere>`
 * :doc:`fix nph <fix_nh>`
 * :doc:`fix press/berendsen <fix_press_berendsen>`
 * :doc:`fix deform/pressure <fix_deform_pressure>`
 The :doc:`fix npt <fix_nh>` commands include a Nose-Hoover thermostat
 and barostat.  :doc:`Fix nph <fix_nh>` is just a Nose/Hoover barostat;
-it does no thermostatting.  Both :doc:`fix nph <fix_nh>` and :doc:`fix press/berendsen <fix_press_berendsen>` can be used in conjunction
+it does no thermostatting.  The fixes :doc:`nph <fix_nh>`, :doc:`press/berendsen <fix_press_berendsen>`, and :doc:`deform/pressure <fix_deform_pressure>`
-with any of the thermostatting fixes.
+can be used in conjunction with any of the thermostatting fixes.
 As with the :doc:`thermostats <Howto_thermostat>`, :doc:`fix npt <fix_nh>`
 and :doc:`fix nph <fix_nh>` only use translational motion of the
@ -44,9 +45,9 @@ a temperature or pressure compute to a barostatting fix.
 .. note::
   As with the thermostats, the Nose/Hoover methods (:doc:`fix npt <fix_nh>` and :doc:`fix nph <fix_nh>`) perform time integration.
-   :doc:`Fix press/berendsen <fix_press_berendsen>` does NOT, so it should
+   :doc:`Fix press/berendsen <fix_press_berendsen>` and :doc:`fix deform/pressure <fix_deform_pressure>`
-   be used with one of the constant NVE fixes or with one of the NVT
+   do NOT, so they should be used with one of the constant NVE fixes or with
-   fixes.
+   one of the NVT fixes.
 Thermodynamic output, which can be setup via the
 :doc:`thermo_style <thermo_style>` command, often includes pressure
--- a/doc/src/Howto_bpm.rst
+++ b/doc/src/Howto_bpm.rst
@ -42,12 +42,14 @@ such as those created by pouring grains using :doc:`fix pour
 ----------
-Currently, there are two types of bonds included in the BPM package. The
+Currently, there are three types of bonds included in the BPM package. The
 first bond style, :doc:`bond bpm/spring <bond_bpm_spring>`, only applies
 pairwise, central body forces. Point particles must have :doc:`bond atom
 style <atom_style>` and may be thought of as nodes in a spring
 network. An optional multibody term can be used to adjust the network's
-Poisson's ratio. Alternatively, the second bond style, :doc:`bond bpm/rotational
+Poisson's ratio. The :doc:`bpm/spring/plastic <bond_bpm_spring_plastic>`
 bond style is similar except it adds a plastic yield strain.
 Alternatively, the third bond style, :doc:`bond bpm/rotational
 <bond_bpm_rotational>`, resolves tangential forces and torques arising
 with the shearing, bending, and twisting of the bond due to rotation or
 displacement of particles.  Particles are similar to those used in the
--- a/doc/src/Howto_bulk2slab.rst
+++ b/doc/src/Howto_bulk2slab.rst
@ -0,0 +1,160 @@
 ===========================
 Convert bulk system to slab
 ===========================
 A regularly encountered simulation problem is how to convert a bulk
 system that has been run for a while to equilibrate into a slab system
 with some vacuum space and free surfaces.  The challenge here is that
 one cannot just change the box dimensions with the :doc:`change_box
 command <change_box>` or edit the box boundaries in a data file because
 some atoms will have non-zero image flags from diffusing around.
 Changing the box dimensions results in an undesired displacement of
 those atoms, since the image flags indicate how many times the box
 length in x-, y-, or z-direction needs to be added or subtracted to get
 the "unwrapped" coordinates.  By changing the box dimension this
 distance is changed and thus those atoms move unphysically relative to
 their neighbors with zero image flags.  Setting image flags forcibly to
 zero creates problems because that could break apart molecules by having
 one atom of a bond on the top of the system and the other at the bottom.
 .. _bulk2slab:
 .. figure:: JPG/rhodo-both.jpg
   :figwidth: 80%
   :figclass: align-center
   Snapshots of the bulk Rhodopsin in lipid layer and water system (right)
   and the generated slab geometry (left)
 .. admonition:: Disclaimer
   :class: note
   The following workflow will work for many bulk systems, but not all.
   Some systems cannot be converted (e.g. polymers with bonds to the
   same molecule across periodic boundaries, sometimes called "infinite
   polymers").  The amount of vacuum that needs to be added depends on
   the length of the molecules where the system is split (the example
   here splits where there is water with short molecules).  In some
   cases, the system may need to be re-centered in the box first using
   the :doc:`displace_atoms command <displace_atoms>`.  Also, the time
   spent on strong thermalization and equilibration will depend on the
   specific system and its thermodynamic conditions.
 Below is a suggested workflow using the :doc:`Rhodopsin benchmark input
 <Speed_bench>` for demonstration.  The figure shows the state *before*
 the procedure on the left (with unwrapped atoms that have diffused out
 of the box) and *after* on the right (with the vacuum added above and
 below).  The procedure is implemented by modifying a copy of the
 ``in.rhodo`` input file.  The first lines up to and including the
 :doc:`read_data command <read_data>` remain unchanged.  Then we insert
 the following lines to add vacuum to the z direction above and below the
 system:
 .. code-block:: LAMMPS
   variable       delta index 10.0
   reset_atoms    image all
   write_dump     all custom rhodo-unwrap.lammpstrj id xu yu zu
   change_box     all z final $(zlo-2.0*v_delta) $(zhi+2.0*v_delta) &
                      boundary p p f
   read_dump      rhodo-unwrap.lammpstrj 0 x y z box no replace yes
   kspace_modify  slab 3.0
 Specifically, the :doc:`variable delta <variable>` (set to 10.0)
 represents a distance that determines the amount of vacuum added: we add
 twice its value in each direction to the z-dimension; thus in total
 :math:`40 \AA` get added.  The :doc:`reset_atoms image all
 <reset_atoms>` command shall reset any image flags to become either 0 or
 :math:`\pm 1` and thus have the minimum distance from the center of the
 simulation box, but the correct relative distance for bonded atoms.
 The :doc:`write_dump command <write_dump>` then writes out the resulting
 *unwrapped* coordinates of the system.  After expanding the box,
 coordinates that were outside the box should now be inside and the
 unwrapped coordinates will become "wrapped", while atoms outside the
 periodic boundaries will be wrapped back into the box and their image
 flags in those directions restored.
 The :doc:`change_box command <change_box>` adds the desired
 distance to the low and high box boundary in z-direction and then changes
 the :doc:`boundary to "p p f" <boundary>` which will force the image
 flags in z-direction to zero and create an undesired displacement for
 the atoms with non-zero image flags.
 With the :doc:`read_dump command <read_dump>` we read back and replace
 partially incorrect coordinates with the previously saved, unwrapped
 coordinates.  It is important to ignore the box dimensions stored in the
 dump file.  We want to preserve the expanded box.  Finally, we turn on
 the slab correction for the PPPM long-range solver with the
 :doc:`kspace_modify command <kspace_modify>` as required when using a
 long range Coulomb solver for non-periodic z-dimension.
 Next we replace the :doc:`fix npt command <fix_nh>` with:
 .. code-block:: LAMMPS
   fix            2 nvt temp 300.0 300.0 10.0
 We now have an open system and thus the adjustment of the cell in
 z-direction is no longer required.  Since splitting the bulk water
 region where the vacuum is inserted, creates surface atoms with high
 potential energy, we reduce the thermostat time constant from 100.0 to
 10.0 to remove excess kinetic energy resulting from that change faster.
 Also the high potential energy of the surface atoms can cause that some
 of them are ejected from the slab.  In order to suppress that, we add
 soft harmonic walls to push back any atoms that want to leave the slab.
 To determine the position of the wall, we first need to to determine the
 extent of the atoms in z-direction and then place the harmonic walls
 based on that information:
 .. code-block:: LAMMPS
   compute         zmin all reduce min z
   compute         zmax all reduce max z
   thermo_style    custom zlo c_zmin zhi c_zmax
   run             0 post no
   fix             3 all wall/harmonic zhi $(c_zmax+v_delta) 10.0 0.0 ${delta} &
                                       zlo $(c_zmin-v_delta) 10.0 0.0 ${delta}
 The two :doc:`compute reduce <compute_reduce>` command determine the
 minimum and maximum z-coordinate across all atoms.  In order to trigger
 the execution of the compute commands we need to "consume" them.  This
 is done with the :doc:`thermo_style custom <thermo_style>` command
 followed by the :doc:`run 0 <run>` command.  This avoids and error
 accessing the min/max values determined by the compute commands to
 compute the location of the wall in lower and upper direction.  This
 uses the previously defined *delta* variable to determine the distance
 of the wall from the extent of the system and the cutoff for the wall
 interaction.  This way only atoms that move beyond the min/max values in
 z-direction will experience a restoring force, nudging them back to the
 slab.  The force constant of :math:`10.0 \frac{\mathrm{kcal/mol}}{\AA}`
 was determined empirically.
 Adding these "restoring" soft walls assist in making the free surfaces
 above and below the slab flat, instead of having rugged or ondulated
 surfaces.  The impact of the walls can be changed by adjusting the force
 constant, cutoff, and position of the wall.
 Finally, we replace the :doc:`run 100 <run>` of the original input with:
 .. code-block:: LAMMPS
   run             1000 post no
   unfix           3
   fix             2 all nvt temp 300.0 300.0 100.0
   run             1000 post no
   write_data      data.rhodo-slab
 This runs the system converted to a slab first for 1000 MD steps using
 the walls and stronger Nose-Hoover thermostat.  Then the walls are
 removed with :doc:`unfix 3 <unfix>` and the thermostat time constant
 reset to 100.0 and the system run for another 1000 steps.  Finally the
 resulting slab geometry is written to a new data file
 ``data.rhodo-slab`` with a :doc:`write_data command <write_data>`.  The
 number of MD steps required to reach a proper equilibrium state is very
 likely larger.  The number of 1000 steps (corresponding to 2
 picoseconds) was chosen for demonstration purposes, so that the
 procedure can be easily and quickly tested.
--- a/doc/src/Howto_github.rst
+++ b/doc/src/Howto_github.rst
@ -487,10 +487,10 @@ updates are back-ported from the *develop* branch to the *maintenance*
 branch and occasionally merged to *stable* as an update release.
 Furthermore, the naming of the release tags now follow the pattern
-"patch_<Day><Month><Year>" to simplify comparisons between releases.
+"patch\_<Day><Month><Year>" to simplify comparisons between releases.
-For stable releases additional "stable_<Day><Month><Year>" tags are
+For stable releases additional "stable\_<Day><Month><Year>" tags are
 applied and update releases are tagged with
-"stable_<Day><Month><Year>_update<Number>", Finally, all releases and
+"stable\_<Day><Month><Year>\_update<Number>", Finally, all releases and
 submissions are subject to automatic testing and code checks to make
 sure they compile with a variety of compilers and popular operating
 systems.  Some unit and regression testing is applied as well.
--- a/doc/src/Howto_lammps_gui.rst
+++ b/doc/src/Howto_lammps_gui.rst
@ -64,13 +64,18 @@ simple LAMMPS simulations.  It is very suitable for tutorials on LAMMPS
 since you only need to learn how to use a single program for most tasks
 and thus time can be saved and people can focus on learning LAMMPS.
 The tutorials at https://lammpstutorials.github.io/ are specifically
-updated for use with LAMMPS-GUI.
+updated for use with LAMMPS-GUI and can their tutorial materials can
 be downloaded and loaded directly from the GUI.
 Another design goal is to keep the barrier low when replacing part of
 the functionality of LAMMPS-GUI with external tools.  That said, LAMMPS-GUI
 has some unique functionality that is not found elsewhere:
 - auto-adapting to features available in the integrated LAMMPS library
 - auto-completion for LAMMPS commands and options
 - context-sensitive online help
 - start and stop of simulations via mouse or keyboard
 - monitoring of simulation progress
 - interactive visualization using the :doc:`dump image <dump_image>`
  command with the option to copy-paste the resulting settings
 - automatic slide show generation from dump image out at runtime
--- a/doc/src/Howto_moltemplate.rst
+++ b/doc/src/Howto_moltemplate.rst
@ -2,14 +2,18 @@ Moltemplate Tutorial
 ====================
 In this tutorial, we are going to use the tool :ref:`Moltemplate
-<moltemplate>` to set up a classical molecular dynamic simulation using
+<Moltemplate1>` from https://moltemplate.org/ to set up a classical
-the :ref:`OPLS-AA force field <OPLSAA96>`. The first
+molecular dynamic simulation using the :ref:`OPLS-AA force field
-task is to describe an organic compound and create a complete input deck
+<oplsaa2024>`. The first task is to describe an organic compound and
-for LAMMPS. The second task is to map the OPLS-AA force field to a
+create a complete input deck for LAMMPS.  The second task is to use
-molecular sample created with an external tool, e.g. PACKMOL, and
+moltemplate to build a polymer.  The third task is to map the OPLS-AA
-exported as a PDB file.  The files used in this tutorial can be found
+force field to a molecular sample created with an external tool,
-in the ``tools/moltemplate/tutorial-files`` folder of the LAMMPS
+e.g. PACKMOL, and exported as a PDB file.  The files used in this
-source code distribution.
+tutorial can be found in the ``tools/moltemplate/tutorial-files`` folder
 of the LAMMPS source code distribution.
 Many more examples can be found here: https://moltemplate.org/examples.html
 Simulating an organic solvent
 """""""""""""""""""""""""""""
@ -17,14 +21,13 @@ Simulating an organic solvent
 This example aims to create a cubic box of the organic solvent
 formamide.
-The first step is to create a molecular topology in the
+The first step is to create a molecular topology in the LAMMPS-template
-LAMMPS-template (LT) file format representing a single molecule, which
+(LT) file format representing a single molecule, which will be
-will be stored in a Moltemplate object called ``_FAM inherits OPLSAA {}``.
+stored in a Moltemplate object called ``_FAM inherits OPLSAA {}``.
 This command states that the object ``_FAM`` is based on an existing
 object called ``OPLSAA``, which contains OPLS-AA parameters, atom type
 definitions, partial charges, masses and bond-angle rules for many organic
 and biological compounds.
 The atomic structure is the starting point to populate the command
 ``write('Data Atoms') {}``, which will write the ``Atoms`` section in the
 LAMMPS data file. The OPLS-AA force field uses the ``atom_style full``,
@ -36,21 +39,23 @@ to the ``molID``, except that the same variable is used for the whole
 molecule. The atom types are assigned using ``@``-type variables. The
 assignment of atom types (e.g. ``@atom:177``, ``@atom:178``) is done using
 the OPLS-AA atom types defined in the "In Charges" section of the file
-``oplsaa.lt``, looking for a reasonable match with the description of the atom.
+``oplsaa2024.lt``, looking for a reasonable match with the description of the atom.
 The resulting file (``formamide.lt``) follows:
 .. code-block:: bash
   import /usr/local/moltemplate/moltemplate/force_fields/oplsaa2024.lt  # defines OPLSAA
   _FAM inherits OPLSAA {
     # atomID    molID  atomType  charge  coordX  coordY  coordZ
     write('Data Atoms') {
-       $atom:C00 $mol   @atom:177  0.00    0.100   0.490   0.0
+       $atom:C00  $mol  @atom:235  0.00    0.100   0.490   0.0
-       $atom:O01 $mol   @atom:178  0.00    1.091  -0.250   0.0
+       $atom:O01  $mol  @atom:236  0.00    1.091  -0.250   0.0
-       $atom:N02 $mol   @atom:179  0.00   -1.121  -0.181   0.0
+       $atom:N02  $mol  @atom:237  0.00   -1.121  -0.181   0.0
-       $atom:H03 $mol   @atom:182  0.00   -2.013   0.272   0.0
+       $atom:H03  $mol  @atom:240  0.00   -2.013   0.272   0.0
-       $atom:H04 $mol   @atom:182  0.00   -1.056  -1.190   0.0
+       $atom:H04  $mol  @atom:240  0.00   -1.056  -1.190   0.0
-       $atom:H05 $mol   @atom:221  0.00    0.144   1.570   0.0
+       $atom:H05  $mol  @atom:279  0.00    0.144   1.570   0.0
     }
     # A list of the bonds in the molecule:
@ -64,16 +69,17 @@ The resulting file (``formamide.lt``) follows:
     }
   }
-You don't have to specify the charge in this example because they will
+You don't have to specify the charge in this example because the OPLSAA
-be assigned according to the atom type. Analogously, only a
+force-field assigns charge according to the atom type.  (This is not true
-"Data Bond List" section is needed as the atom type will determine the
+when using other force fields.)  A "Data Bond List" section is needed as
-bond type. The other bonded interactions (e.g. angles,
+the atom type will determine the bond type. The other bonded interactions
-dihedrals, and impropers) will be automatically generated by
+(e.g. angles, dihedrals, and impropers) will be automatically generated by
 Moltemplate.
-If the simulation is non-neutral, or Moltemplate complains that you have
+If the simulation is not charge-neutral, or Moltemplate complains that
-missing bond, angle, or dihedral types, this means at least one of your
+you have missing bond, angle, or dihedral types, this probably means that
-atom types is incorrect.
+at least one of your atom types is incorrect (or that perhaps there is no
 suitable atom type currently defined in the ``oplsaa2024.lt`` file).
 The second step is to create a master file with instructions to build a
 starting structure and the LAMMPS commands to run an NPT simulation. The
@ -81,11 +87,9 @@ master file (``solv_01.lt``) follows:
 .. code-block:: bash
-   # Import the force field.
+   import formamide.lt  # Defines "_FAM" and OPLSAA
   import /usr/local/moltemplate/moltemplate/force_fields/oplsaa.lt
   import formamide.lt # after oplsaa.lt, as it depends on it.
-   # Create the input sample.
+   # Distribute the molecules on a 5x5x5 cubic grid with spacing 4.6
   solv = new _FAM [5].move( 4.6, 0, 0)
                   [5].move( 0, 4.6, 0)
                   [5].move( 0, 0, 4.6)
@ -98,8 +102,11 @@ master file (``solv_01.lt``) follows:
    -11.5 11.5 zlo zhi
   }
   # Note: The lines below in the "In Run" section are often omitted.
   write_once("In Run"){
    # Create an input deck for LAMMPS.
-   write_once("In Init"){
+    # Run an NPT simulation.
    # Input variables.
    variable run    string solv_01   # output name
    variable ts     equal  1         # timestep
@ -109,12 +116,6 @@ master file (``solv_01.lt``) follows:
    variable equi   equal  5000      # Equilibration steps
    variable prod   equal  30000     # Production steps
    # PBC (set them before the creation of the box).
    boundary p p p
   }
   # Run an NPT simulation.
   write_once("In Run"){
    # Derived variables.
    variable tcouple equal \$\{ts\}*100
    variable pcouple equal \$\{ts\}*1000
@ -143,7 +144,7 @@ master file (``solv_01.lt``) follows:
    unfix NPT
   }
-The first two commands insert the content of files ``oplsaa.lt`` and
+The first two commands insert the content of files ``oplsaa2024.lt`` and
 ``formamide.lt`` into the master file. At this point, we can use the
 command ``solv = new _FAM [N]`` to create N copies of a molecule of type
 ``_FAM``. In this case, we create an array of 5*5*5 molecules on a cubic
@ -153,21 +154,37 @@ the sample was created from scratch, we also specify the simulation box
 size in the "Data Boundary" section.
 The LAMMPS setting for the force field are specified in the file
-``oplsaa.lt`` and are written automatically in the input deck. We also
+``oplsaa2024.lt`` and are written automatically in the input deck. We also
 specify the boundary conditions and a set of variables in
-the "In Init" section. The remaining commands to run an NPT simulation
+the "In Init" section.
 The remaining commands to run an NPT simulation
 are written in the "In Run" section. Note that in this script, LAMMPS
 variables are protected with the escape character ``\`` to distinguish
 them from Moltemplate variables, e.g. ``\$\{run\}`` is a LAMMPS
 variable that is written in the input deck as ``${run}``.
 (Note: Moltemplate can be slow to run, so you need to change you run
 settings frequently, I recommended moving those commands (from "In Run")
 out of your .lt files and into a separate file.  Moltemplate creates a
 file named ``run.in.EXAMPLE`` for this purpose.  You can put your run
 settings and fixes that file and then invoke LAMMPS using
 ``mpirun -np 4 lmp -in run.in.EXAMPLE`` instead.)
 Compile the master file with:
 .. code-block:: bash
-   moltemplate.sh -overlay-all solv_01.lt
+   moltemplate.sh solv_01.lt
   cleanup_moltemplate.sh   # <-- optional: see below
-And execute the simulation with the following:
+(Note: The optional "cleanup_moltemplate.sh" command deletes
 unused atom types, which sometimes makes LAMMPS run faster.
 But it does not work with many-body pair styles or dreiding-style h-bonds.
 Fortunately most force fields, including OPLSAA, don't use those features.)
 Then execute the simulation with the following:
 .. code-block:: bash
@ -180,15 +197,116 @@ And execute the simulation with the following:
   Snapshot of the sample at the beginning and end of the simulation.
   Rendered with Ovito.
 Building a simple polymer
 """""""""""""""""""""""""
 Moltemplate is particularly useful for building polymers (and other molecules
 with sub-units).  As an simple example, consider butane:
 .. figure:: JPG/butane.jpg
 The ``butane.lt`` file below defines Butane as a polymer containing
 4 monomers (of type ``CH3``, ``CH2``, ``CH2``, ``CH3``).
 .. code-block:: bash
   import /usr/local/moltemplate/moltemplate/force_fields/oplsaa2024.lt  # defines OPLSAA
   CH3 inherits OPLSAA {
     # atomID    molID   atomType  charge   coordX   coordY    coordZ
     write("Data Atoms") {
       $atom:c  $mol:... @atom:54   0.0   0.000000  0.4431163  0.000000
       $atom:h1 $mol:... @atom:60   0.0   0.000000  1.0741603  0.892431
       $atom:h2 $mol:... @atom:60   0.0   0.000000  1.0741603 -0.892431
       $atom:h3 $mol:... @atom:60   0.0  -0.892431 -0.1879277  0.000000
     }
     # (Using "$mol:..." indicates this object ("CH3") is part of a larger
     #  molecule. Moltemplate will share the molecule-ID with that molecule.)
     # A list of the bonds within the "CH3" molecular sub-unit:
     # BondID   AtomID1   AtomID2
     write('Data Bond List') {
       $bond:ch1 $atom:c $atom:h1
       $bond:ch2 $atom:c $atom:h2
       $bond:ch3 $atom:c $atom:h3
     }
   }
   CH2 inherits OPLSAA {
     # atomID    molID   atomType  charge   coordX   coordY    coordZ
     write("Data Atoms") {
       $atom:c  $mol:... @atom:57   0.0   0.000000  0.4431163  0.000000
       $atom:h1 $mol:... @atom:60   0.0   0.000000  1.0741603  0.892431
       $atom:h2 $mol:... @atom:60   0.0   0.000000  1.0741603 -0.892431
     }
     # A list of the bonds within the "CH2" molecular sub-unit:
     # BondID   AtomID1   AtomID2
     write('Data Bond List') {
       $bond:ch1 $atom:c $atom:h1
       $bond:ch2 $atom:c $atom:h2
     }
   }
   Butane inherits OPLSAA {
     create_var {$mol}  # optional:force all monomers to share the same molecule-ID
     # - Create 4 monomers
     # - Move them along the X axis using ".move()",
     # - Rotate them 180 degrees with respect to the previous monomer
     monomer1 = new CH3
     monomer2 = new CH2.rot(180,1,0,0).move(1.2533223,0,0)
     monomer3 = new CH2.move(2.5066446,0,0)
     monomer4 = new CH3.rot(180,0,0,1).move(3.7599669,0,0)
     # A list of the bonds connecting different monomers together:
     write('Data Bond List') {
       $bond:b1  $atom:monomer1/c $atom:monomer2/c
       $bond:b2  $atom:monomer2/c $atom:monomer3/c
       $bond:b3  $atom:monomer3/c $atom:monomer4/c
     }
   }
 Again, you don't have to specify the charge in this example because OPLSAA
 assigns charges according to the atom type.
 This ``Butane`` object is a molecule which can be used anywhere other molecules
 can be used.  (You can arrange ``Butane`` molecules on a lattice, as we did previously.
 You can also modify individual butane molecules by adding or deleting atoms or bonds.
 You can add bonds between specific butane molecules or use ``Butane`` as a
 subunit to define even larger molecules.  See the moltemplate manual for details.)
 How to build a complex polymer
 """"""""""""""""""""""""""""""""""""""""""
 A similar procedure can be used to create more complicated polymers,
 such as the NIPAM polymer example shown below.  For details, see:
 https://github.com/jewettaij/moltemplate/tree/master/examples/all_atom/force_field_OPLSAA/NIPAM_polymer+water+ions
 Mapping an existing structure
 """""""""""""""""""""""""""""
 Another helpful way to use Moltemplate is mapping an existing molecular
-sample to a force field. This is useful when a complex sample is
+sample to a force field. This is useful when a complex sample is assembled
-assembled from different simulations or created with specialized
+from different simulations or created with specialized software (e.g. PACKMOL).
-software (e.g. PACKMOL). As in the previous example, all molecular
+(Note: The previous link shows how to build this entire system from scratch
-species in the sample must be defined using single-molecule Moltemplate
+using only moltemplate.  However here we will assume instead that we obtained
-objects.  For this example, we use a short polymer in a box containing
+a PDB file for this system using PACKMOL.)
 As in the previous examples, all molecular species in the sample
 are defined using single-molecule Moltemplate objects.
 For this example, we use a short polymer in a box containing
 water molecules and ions in the PDB file ``model.pdb``.
 It is essential to understand that the order of atoms in the PDB file
@ -246,25 +364,25 @@ The resulting master LT file defining short annealing at a fixed volume
 .. code-block:: bash
   # Use the OPLS-AA force field for all species.
-   import /usr/local/moltemplate/moltemplate/force_fields/oplsaa.lt
+   import /usr/local/moltemplate/moltemplate/force_fields/oplsaa2024.lt
   import PolyNIPAM.lt
   # Define the SPC water and ions as in the OPLS-AA
   Ca inherits OPLSAA {
     write("Data Atoms"){
-       $atom:a1  $mol:. @atom:354 0.0  0.00000 0.00000 0.000000
+       $atom:a1  $mol:. @atom:412 0.0  0.00000 0.00000 0.000000
     }
   }
   Cl inherits OPLSAA {
     write("Data Atoms"){
-       $atom:a1  $mol:. @atom:344 0.0  0.00000 0.00000 0.000000
+       $atom:a1  $mol:. @atom:401 0.0  0.00000 0.00000 0.000000
     }
   }
   SPC inherits OPLSAA {
     write("Data Atoms"){
-       $atom:O  $mol:. @atom:76 0.  0.0000000 0.00000 0.000000
+       $atom:O  $mol:. @atom:9991 0.  0.0000000 0.00000 0.0000000
-       $atom:H1 $mol:. @atom:77 0.  0.8164904 0.00000 0.5773590
+       $atom:H1 $mol:. @atom:9990 0.  0.8164904 0.00000 0.5773590
-       $atom:H2 $mol:. @atom:77 0. -0.8164904 0.00000 0.5773590
+       $atom:H2 $mol:. @atom:9990 0. -0.8164904 0.00000 0.5773590
     }
     write("Data Bond List") {
       $bond:OH1 $atom:O $atom:H1
@ -285,8 +403,15 @@ The resulting master LT file defining short annealing at a fixed volume
     0 26 zlo zhi
   }
   # Define the input variables.
   write_once("In Init"){
     boundary p p p  # "p p p" is the default. This line is optional.
     neighbor 3 bin  # (This line is also optional in this example.)
   }
   # Note: The lines below in the "In Run" section are often omitted.
   # Run an NVT simulation.
   write_once("In Run"){
     # Input variables.
     variable run    string sample01  # output name
     variable ts     equal  2         # timestep
@ -294,13 +419,6 @@ The resulting master LT file defining short annealing at a fixed volume
     variable p      equal  1.        # equilibrium pressure
     variable equi   equal  30000     # equilibration steps
     # PBC (set them before the creation of the box).
     boundary p p p
     neighbor        3 bin
   }
   # Run an NVT simulation.
   write_once("In Run"){
     # Set the output.
     thermo          1000
     thermo_style    custom step etotal evdwl ecoul elong ebond eangle &
@ -314,8 +432,8 @@ The resulting master LT file defining short annealing at a fixed volume
     write_data \$\{run\}.min
     # Set the constrains.
-     group watergroup type @atom:76 @atom:77
+     group watergroup type @atom:9991 @atom:9990
-     fix 0 watergroup shake 0.0001 10 0 b @bond:042_043 a @angle:043_042_043
+     fix 0 watergroup shake 0.0001 10 0 b @bond:spcO_spcH a @angle:spcH_spcO_spcH
     # Short annealing.
     timestep        \$\{ts\}
@ -327,7 +445,7 @@ The resulting master LT file defining short annealing at a fixed volume
 In this example, the water model is SPC and it is defined in the
-``oplsaa.lt`` file with atom types ``@atom:76`` and ``@atom:77``.  For
+``oplsaa2024.lt`` file with atom types ``@atom:9991`` and ``@atom:9990``.  For
 water we also use the ``group`` and ``fix shake`` commands with
 Moltemplate ``@``-type variables, to ensure consistency with the
 numerical values assigned during compilation. To identify the bond and
@ -336,19 +454,20 @@ are:
 .. code-block:: bash
-   replace{ @atom:76 @atom:76_b042_a042_d042_i042 }
+   replace{ @atom:9991 @atom:9991_bspcO_aspcO_dspcO_ispcO }
-   replace{ @atom:77 @atom:77_b043_a043_d043_i043 }
+   replace{ @atom:9990 @atom:9990_bspcH_aspcH_dspcH_ispcH }
 From which we can identify the following "Data Bonds By Type":
-``@bond:042_043 @atom:*_b042*_a*_d*_i* @atom:*_b043*_a*_d*_i*`` and
+``@bond:spcO_spcH @atom:*_bspcO*_a*_d*_i* @atom:*_bspcH*_a*_d*_i*``
-"Data Angles By Type": ``@angle:043_042_043 @atom:*_b*_a043*_d*_i*
+and "Data Angles By Type":
-@atom:*_b*_a042*_d*_i* @atom:*_b*_a043*_d*_i*``
+``@angle:spcH_spcO_spcH @atom:*_b*_aspcH*_d*_i* @atom:*_b*_aspcO*_d*_i* @atom:*_b*_aspcH*_d*_i*``
 Compile the master file with:
 .. code-block:: bash
-   moltemplate.sh -overlay-all -pdb model.pdb sample01.lt
+   moltemplate.sh -pdb model.pdb sample01.lt
   cleanup_moltemplate.sh
 And execute the simulation with the following:
@ -363,8 +482,13 @@ And execute the simulation with the following:
   Sample visualized with Ovito loading the trajectory into the DATA
   file written after minimization.
 ------------
-.. _OPLSAA96:
+.. _oplsaa2024:
-**(OPLS-AA)**  Jorgensen, Maxwell, Tirado-Rives, J Am Chem Soc, 118(45), 11225-11236 (1996).
+**(OPLS-AA)**  Jorgensen, W.L., Ghahremanpour, M.M., Saar, A., Tirado-Rives, J., J. Phys. Chem. B, 128(1), 250-262 (2024).
 .. _Moltemplate1:
 **(Moltemplate)**  Jewett et al., J. Mol. Biol., 433(11), 166841 (2021)
--- a/doc/src/Howto_peri.rst
+++ b/doc/src/Howto_peri.rst
@ -197,7 +197,7 @@ The LPS model has a force scalar state
 .. math::
   \underline{t} = \frac{3K\theta}{m}\underline{\omega}\,\underline{x} +
-   \alpha \underline{\omega}\,\underline{e}^{\rm d}, \qquad\qquad\textrm{(3)}
+   \alpha \underline{\omega}\,\underline{e}^\mathrm{d}, \qquad\qquad\textrm{(3)}
 with :math:`K` the bulk modulus and :math:`\alpha` related to the shear
 modulus :math:`G` as
@ -242,14 +242,14 @@ scalar state are defined, respectively, as
 .. math::
-   \underline{e}^{\rm i}=\frac{\theta \underline{x}}{3}, \qquad
+   \underline{e}^\mathrm{i}=\frac{\theta \underline{x}}{3}, \qquad
-   \underline{e}^{\rm d} = \underline{e}- \underline{e}^{\rm i},
+   \underline{e}^\mathrm{d} = \underline{e}- \underline{e}^\mathrm{i},
 where the arguments of the state functions and the vectors on which they
 operate are omitted for simplicity. We note that the LPS model is linear
 in the dilatation :math:`\theta`, and in the deviatoric part of the
-extension :math:`\underline{e}^{\rm d}`.
+extension :math:`\underline{e}^\mathrm{d}`.
 .. note::
--- a/doc/src/Howto_pylammps.rst
+++ b/doc/src/Howto_pylammps.rst
@ -1,564 +1,6 @@
 PyLammps Tutorial
 =================
-.. contents::
+The PyLammps interface is deprecated and will be removed in a future release of
-
+LAMMPS. As such, the PyLammps version of this tutorial has been removed and is
-Overview
+replaced by the :doc:`Python_head`.
 --------
 :py:class:`PyLammps <lammps.PyLammps>` is a Python wrapper class for
 LAMMPS which can be created on its own or use an existing
 :py:class:`lammps Python <lammps.lammps>` object.  It creates a simpler,
 more "pythonic" interface to common LAMMPS functionality, in contrast to
 the :py:class:`lammps <lammps.lammps>` wrapper for the LAMMPS :ref:`C
 language library interface API <lammps_c_api>` which is written using
 `Python ctypes <ctypes_>`_.  The :py:class:`lammps <lammps.lammps>`
 wrapper is discussed on the :doc:`Python_head` doc page.
 Unlike the flat `ctypes <ctypes_>`_ interface, PyLammps exposes a
 discoverable API.  It no longer requires knowledge of the underlying C++
 code implementation.  Finally, the :py:class:`IPyLammps
 <lammps.IPyLammps>` wrapper builds on top of :py:class:`PyLammps
 <lammps.PyLammps>` and adds some additional features for `IPython
 integration <ipython_>`_ into `Jupyter notebooks <jupyter_>`_, e.g. for
 embedded visualization output from :doc:`dump style image <dump_image>`.
 .. _ctypes: https://docs.python.org/3/library/ctypes.html
 .. _ipython: https://ipython.org/
 .. _jupyter: https://jupyter.org/
 Comparison of lammps and PyLammps interfaces
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 lammps.lammps
 """""""""""""
 * uses `ctypes <ctypes_>`_
 * direct memory access to native C++ data with optional support for NumPy arrays
 * provides functions to send and receive data to LAMMPS
 * interface modeled after the LAMMPS :ref:`C language library interface API <lammps_c_api>`
 * requires knowledge of how LAMMPS internally works (C pointers, etc)
 * full support for running Python with MPI using `mpi4py <https://mpi4py.readthedocs.io>`_
 * no overhead from creating a more Python-like interface
 lammps.PyLammps
 """""""""""""""
 * higher-level abstraction built on *top* of the original :py:class:`ctypes based interface <lammps.lammps>`
 * manipulation of Python objects
 * communication with LAMMPS is hidden from API user
 * shorter, more concise Python
 * better IPython integration, designed for quick prototyping
 * designed for serial execution
 * additional overhead from capturing and parsing the LAMMPS screen output
 Quick Start
 -----------
 System-wide Installation
 ^^^^^^^^^^^^^^^^^^^^^^^^
 Step 1: Building LAMMPS as a shared library
 """""""""""""""""""""""""""""""""""""""""""
 To use LAMMPS inside of Python it has to be compiled as shared
 library. This library is then loaded by the Python interface. In this
 example we enable the MOLECULE package and compile LAMMPS with PNG, JPEG
 and FFMPEG output support enabled.
 Step 1a: For the CMake based build system, the steps are:
 .. code-block:: bash
   mkdir $LAMMPS_DIR/build-shared
   cd  $LAMMPS_DIR/build-shared
   # MPI, PNG, Jpeg, FFMPEG are auto-detected
   cmake ../cmake -DPKG_MOLECULE=yes -DBUILD_LIB=yes -DBUILD_SHARED_LIBS=yes
   make
 Step 1b: For the legacy, make based build system, the steps are:
 .. code-block:: bash
   cd $LAMMPS_DIR/src
   # add packages if necessary
   make yes-MOLECULE
   # compile shared library using Makefile
   make mpi mode=shlib LMP_INC="-DLAMMPS_PNG -DLAMMPS_JPEG -DLAMMPS_FFMPEG" JPG_LIB="-lpng -ljpeg"
 Step 2: Installing the LAMMPS Python package
 """"""""""""""""""""""""""""""""""""""""""""
 PyLammps is part of the lammps Python package. To install it simply install
 that package into your current Python installation with:
 .. code-block:: bash
   make install-python
 .. note::
   Recompiling the shared library requires re-installing the Python package
 Installation inside of a virtualenv
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 You can use virtualenv to create a custom Python environment specifically tuned
 for your workflow.
 Benefits of using a virtualenv
 """"""""""""""""""""""""""""""
 * isolation of your system Python installation from your development installation
 * installation can happen in your user directory without root access (useful for HPC clusters)
 * installing packages through pip allows you to get newer versions of packages than e.g., through apt-get or yum package managers (and without root access)
 * you can even install specific old versions of a package if necessary
 **Prerequisite (e.g. on Ubuntu)**
 .. code-block:: bash
   apt-get install python-virtualenv
 Creating a virtualenv with lammps installed
 """""""""""""""""""""""""""""""""""""""""""
 .. code-block:: bash
   # create virtualenv named 'testing'
   virtualenv $HOME/python/testing
   # activate 'testing' environment
   source $HOME/python/testing/bin/activate
 Now configure and compile the LAMMPS shared library as outlined above.
 When using CMake and the shared library has already been build, you
 need to re-run CMake to update the location of the python executable
 to the location in the virtual environment with:
 .. code-block:: bash
   cmake . -DPython_EXECUTABLE=$(which python)
   # install LAMMPS package in virtualenv
   (testing) make install-python
   # install other useful packages
   (testing) pip install matplotlib jupyter mpi4py
   ...
   # return to original shell
   (testing) deactivate
 Creating a new instance of PyLammps
 -----------------------------------
 To create a PyLammps object you need to first import the class from the lammps
 module. By using the default constructor, a new *lammps* instance is created.
 .. code-block:: python
   from lammps import PyLammps
   L = PyLammps()
 You can also initialize PyLammps on top of this existing *lammps* object:
 .. code-block:: python
   from lammps import lammps, PyLammps
   lmp = lammps()
   L = PyLammps(ptr=lmp)
 Commands
 --------
 Sending a LAMMPS command with the existing library interfaces is done using
 the command method of the lammps object instance.
 For instance, let's take the following LAMMPS command:
 .. code-block:: LAMMPS
   region box block 0 10 0 5 -0.5 0.5
 In the original interface this command can be executed with the following
 Python code if *L* was a lammps instance:
 .. code-block:: python
   L.command("region box block 0 10 0 5 -0.5 0.5")
 With the PyLammps interface, any command can be split up into arbitrary parts
 separated by white-space, passed as individual arguments to a region method.
 .. code-block:: python
   L.region("box block", 0, 10, 0, 5, -0.5, 0.5)
 Note that each parameter is set as Python literal floating-point number. In the
 PyLammps interface, each command takes an arbitrary parameter list and transparently
 merges it to a single command string, separating individual parameters by white-space.
 The benefit of this approach is avoiding redundant command calls and easier
 parameterization. In the original interface parameterization needed to be done
 manually by creating formatted strings.
 .. code-block:: python
   L.command("region box block %f %f %f %f %f %f" % (xlo, xhi, ylo, yhi, zlo, zhi))
 In contrast, methods of PyLammps accept parameters directly and will convert
 them automatically to a final command string.
 .. code-block:: python
   L.region("box block", xlo, xhi, ylo, yhi, zlo, zhi)
 System state
 ------------
 In addition to dispatching commands directly through the PyLammps object, it
 also provides several properties which allow you to query the system state.
 L.system
   Is a dictionary describing the system such as the bounding box or number of atoms
 L.system.xlo, L.system.xhi
   bounding box limits along x-axis
 L.system.ylo, L.system.yhi
   bounding box limits along y-axis
 L.system.zlo, L.system.zhi
   bounding box limits along z-axis
 L.communication
   configuration of communication subsystem, such as the number of threads or processors
 L.communication.nthreads
   number of threads used by each LAMMPS process
 L.communication.nprocs
   number of MPI processes used by LAMMPS
 L.fixes
   List of fixes in the current system
 L.computes
   List of active computes in the current system
 L.dump
   List of active dumps in the current system
 L.groups
   List of groups present in the current system
 Working with LAMMPS variables
 -----------------------------
 LAMMPS variables can be both defined and accessed via the PyLammps interface.
 To define a variable you can use the :doc:`variable <variable>` command:
 .. code-block:: python
   L.variable("a index 2")
 A dictionary of all variables is returned by L.variables
 you can access an individual variable by retrieving a variable object from the
 L.variables dictionary by name
 .. code-block:: python
   a = L.variables['a']
 The variable value can then be easily read and written by accessing the value
 property of this object.
 .. code-block:: python
   print(a.value)
   a.value = 4
 Retrieving the value of an arbitrary LAMMPS expressions
 -------------------------------------------------------
 LAMMPS expressions can be immediately evaluated by using the eval method. The
 passed string parameter can be any expression containing global thermo values,
 variables, compute or fix data.
 .. code-block:: python
   result = L.eval("ke") # kinetic energy
   result = L.eval("pe") # potential energy
   result = L.eval("v_t/2.0")
 Accessing atom data
 -------------------
 All atoms in the current simulation can be accessed by using the L.atoms list.
 Each element of this list is an object which exposes its properties (id, type,
 position, velocity, force, etc.).
 .. code-block:: python
   # access first atom
   L.atoms[0].id
   L.atoms[0].type
   # access second atom
   L.atoms[1].position
   L.atoms[1].velocity
   L.atoms[1].force
 Some properties can also be used to set:
 .. code-block:: python
   # set position in 2D simulation
   L.atoms[0].position = (1.0, 0.0)
   # set position in 3D simulation
   L.atoms[0].position = (1.0, 0.0, 1.)
 Evaluating thermo data
 ----------------------
 Each simulation run usually produces thermo output based on system state,
 computes, fixes or variables. The trajectories of these values can be queried
 after a run via the L.runs list. This list contains a growing list of run data.
 The first element is the output of the first run, the second element that of
 the second run.
 .. code-block:: python
   L.run(1000)
   L.runs[0] # data of first 1000 time steps
   L.run(1000)
   L.runs[1] # data of second 1000 time steps
 Each run contains a dictionary of all trajectories. Each trajectory is
 accessible through its thermo name:
 .. code-block:: python
   L.runs[0].thermo.Step # list of time steps in first run
   L.runs[0].thermo.Ke   # list of kinetic energy values in first run
 Together with matplotlib plotting data out of LAMMPS becomes simple:
 .. code-block:: python
   import matplotlib.plot as plt
   steps = L.runs[0].thermo.Step
   ke    = L.runs[0].thermo.Ke
   plt.plot(steps, ke)
 Error handling with PyLammps
 ----------------------------
 Using C++ exceptions in LAMMPS for errors allows capturing them on the
 C++ side and rethrowing them on the Python side.  This way you can handle
 LAMMPS errors through the Python exception handling mechanism.
 .. warning::
   Capturing a LAMMPS exception in Python can still mean that the
   current LAMMPS process is in an illegal state and must be
   terminated. It is advised to save your data and terminate the Python
   instance as quickly as possible.
 Using PyLammps in IPython notebooks and Jupyter
 -----------------------------------------------
 If the LAMMPS Python package is installed for the same Python interpreter as
 IPython, you can use PyLammps directly inside of an IPython notebook inside of
 Jupyter. Jupyter is a powerful integrated development environment (IDE) for
 many dynamic languages like Python, Julia and others, which operates inside of
 any web browser. Besides auto-completion and syntax highlighting it allows you
 to create formatted documents using Markup, mathematical formulas, graphics and
 animations intermixed with executable Python code. It is a great format for
 tutorials and showcasing your latest research.
 To launch an instance of Jupyter simply run the following command inside your
 Python environment (this assumes you followed the Quick Start instructions):
 .. code-block:: bash
   jupyter notebook
 IPyLammps Examples
 ------------------
 Examples of IPython notebooks can be found in the python/examples/pylammps
 subdirectory. To open these notebooks launch *jupyter notebook* inside this
 directory and navigate to one of them. If you compiled and installed
 a LAMMPS shared library with exceptions, PNG, JPEG and FFMPEG support
 you should be able to rerun all of these notebooks.
 Validating a dihedral potential
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 This example showcases how an IPython Notebook can be used to compare a simple
 LAMMPS simulation of a harmonic dihedral potential to its analytical solution.
 Four atoms are placed in the simulation and the dihedral potential is applied on
 them using a datafile. Then one of the atoms is rotated along the central axis by
 setting its position from Python, which changes the dihedral angle.
 .. code-block:: python
   phi = [d \* math.pi / 180 for d in range(360)]
   pos = [(1.0, math.cos(p), math.sin(p)) for p in phi]
   pe = []
   for p in pos:
       L.atoms[3].position = p
       L.run(0)
       pe.append(L.eval("pe"))
 By evaluating the potential energy for each position we can verify that
 trajectory with the analytical formula.  To compare both solutions, we plot
 both trajectories over each other using matplotlib, which embeds the generated
 plot inside the IPython notebook.
 .. image:: JPG/pylammps_dihedral.jpg
   :align: center
 Running a Monte Carlo relaxation
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 This second example shows how to use PyLammps to create a 2D Monte Carlo Relaxation
 simulation, computing and plotting energy terms and even embedding video output.
 Initially, a 2D system is created in a state with minimal energy.
 .. image:: JPG/pylammps_mc_minimum.jpg
   :align: center
 It is then disordered by moving each atom by a random delta.
 .. code-block:: python
   random.seed(27848)
   deltaperturb = 0.2
   for i in range(L.system.natoms):
       x, y = L.atoms[i].position
       dx = deltaperturb \* random.uniform(-1, 1)
       dy = deltaperturb \* random.uniform(-1, 1)
       L.atoms[i].position  = (x+dx, y+dy)
   L.run(0)
 .. image:: JPG/pylammps_mc_disordered.jpg
   :align: center
 Finally, the Monte Carlo algorithm is implemented in Python. It continuously
 moves random atoms by a random delta and only accepts certain moves.
 .. code-block:: python
   estart = L.eval("pe")
   elast = estart
   naccept = 0
   energies = [estart]
   niterations = 3000
   deltamove = 0.1
   kT = 0.05
   natoms = L.system.natoms
   for i in range(niterations):
       iatom = random.randrange(0, natoms)
       current_atom = L.atoms[iatom]
       x0, y0 = current_atom.position
       dx = deltamove \* random.uniform(-1, 1)
       dy = deltamove \* random.uniform(-1, 1)
       current_atom.position = (x0+dx, y0+dy)
       L.run(1, "pre no post no")
       e = L.eval("pe")
       energies.append(e)
       if e <= elast:
           naccept += 1
           elast = e
       elif random.random() <= math.exp(natoms\*(elast-e)/kT):
           naccept += 1
           elast = e
       else:
           current_atom.position = (x0, y0)
 The energies of each iteration are collected in a Python list and finally plotted using matplotlib.
 .. image:: JPG/pylammps_mc_energies_plot.jpg
   :align: center
 The IPython notebook also shows how to use dump commands and embed video files
 inside of the IPython notebook.
 Using PyLammps and mpi4py (Experimental)
 ----------------------------------------
 PyLammps can be run in parallel using `mpi4py
 <https://mpi4py.readthedocs.io>`_. This python package can be installed
 using
 .. code-block:: bash
   pip install mpi4py
 .. warning::
   Usually, any :py:class:`PyLammps <lammps.PyLammps>` command must be
   executed by *all* MPI processes. However, evaluations and querying
   the system state is only available on MPI rank 0.  Using these
   functions from other MPI ranks will raise an exception.
 The following is a short example which reads in an existing LAMMPS input
 file and executes it in parallel.  You can find in.melt in the
 examples/melt folder.  Please take note that the
 :py:meth:`PyLammps.eval() <lammps.PyLammps.eval>` is called only from
 MPI rank 0.
 .. code-block:: python
   from mpi4py import MPI
   from lammps import PyLammps
   L = PyLammps()
   L.file("in.melt")
   if MPI.COMM_WORLD.rank == 0:
       print("Potential energy: ", L.eval("pe"))
   MPI.Finalize()
 To run this script (melt.py) in parallel using 4 MPI processes we invoke the
 following mpirun command:
 .. code-block:: bash
   mpirun -np 4 python melt.py
 Feedback and Contributing
 -------------------------
 If you find this Python interface useful, please feel free to provide feedback
 and ideas on how to improve it to Richard Berger (richard.berger@outlook.com). We also
 want to encourage people to write tutorial style IPython notebooks showcasing LAMMPS usage
 and maybe their latest research results.
--- a/doc/src/Howto_python.rst
+++ b/doc/src/Howto_python.rst
@ -0,0 +1,464 @@
 LAMMPS Python Tutorial
 ======================
 .. contents::
 -----
 Overview
 --------
 The :py:class:`lammps <lammps.lammps>` Python module is a wrapper class for the
 LAMMPS :ref:`C language library interface API <lammps_c_api>` which is written using
 `Python ctypes <ctypes_>`_.  The design choice of this wrapper class is to
 follow the C language API closely with only small changes related to Python
 specific requirements and to better accommodate object oriented programming.
 In addition to this flat `ctypes <ctypes_>`_ interface, the
 :py:class:`lammps <lammps.lammps>` wrapper class exposes a discoverable
 API that doesn't require as much knowledge of the underlying C language
 library interface or LAMMPS C++ code implementation.
 Finally, the API exposes some additional features for `IPython integration
 <ipython_>`_ into `Jupyter notebooks <jupyter_>`_, e.g. for embedded
 visualization output from :doc:`dump style image <dump_image>`.
 .. _ctypes: https://docs.python.org/3/library/ctypes.html
 .. _ipython: https://ipython.org/
 .. _jupyter: https://jupyter.org/
 -----
 Quick Start
 -----------
 System-wide or User Installation
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Step 1: Building LAMMPS as a shared library
 """""""""""""""""""""""""""""""""""""""""""
 To use LAMMPS inside of Python it has to be compiled as shared library.
 This library is then loaded by the Python interface.  In this example we
 enable the :ref:`MOLECULE package <PKG-MOLECULE>` and compile LAMMPS
 with :ref:`PNG, JPEG and FFMPEG output support <graphics>` enabled.
 .. tabs::
   .. tab:: CMake build
      .. code-block:: bash
         mkdir $LAMMPS_DIR/build-shared
         cd  $LAMMPS_DIR/build-shared
         # MPI, PNG, Jpeg, FFMPEG are auto-detected
         cmake ../cmake -DPKG_MOLECULE=yes -DPKG_PYTHON=on -DBUILD_SHARED_LIBS=yes
         make
   .. tab:: Traditional make
      .. code-block:: bash
         cd $LAMMPS_DIR/src
         # add LAMMPS packages if necessary
         make yes-MOLECULE
         make yes-PYTHON
         # compile shared library using Makefile
         make mpi mode=shlib LMP_INC="-DLAMMPS_PNG -DLAMMPS_JPEG -DLAMMPS_FFMPEG" JPG_LIB="-lpng -ljpeg"
 Step 2: Installing the LAMMPS Python module
 """""""""""""""""""""""""""""""""""""""""""
 Next install the LAMMPS Python module into your current Python installation with:
 .. code-block:: bash
   make install-python
 This will create a so-called `"wheel"
 <https://packaging.python.org/en/latest/discussions/package-formats/#what-is-a-wheel>`_
 and then install the LAMMPS Python module from that "wheel" into either
 into a system folder (provided the command is executed with root
 privileges) or into your personal Python module folder.
 .. note::
   Recompiling the shared library requires re-installing the Python
   package.
 .. _externally_managed:
 .. admonition:: Handling an "externally-managed-environment" Error
   :class: Hint
   Some Python installations made through Linux distributions
   (e.g. Ubuntu 24.04LTS or later) will prevent installing the LAMMPS
   Python module into a system folder or a corresponding folder of the
   individual user as attempted by ``make install-python`` with an error
   stating that an *externally managed* python installation must be only
   managed by the same package package management tool.  This is an
   optional setting, so not all Linux distributions follow it currently
   (Spring 2025).  The reasoning and explanations for this error can be
   found in the `Python Packaging User Guide
   <https://packaging.python.org/en/latest/specifications/externally-managed-environments/>`_
   These guidelines suggest to create a virtual environment and install
   the LAMMPS Python module there (see below).  This is generally a good
   idea and the LAMMPS developers recommend this, too.  If, however, you
   want to proceed and install the LAMMPS Python module regardless, you
   can install the "wheel" file (see above) manually with the ``pip``
   command by adding the ``--break-system-packages`` flag.
 Installation inside of a virtual environment
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 You can use virtual environments to create a custom Python environment
 specifically tuned for your workflow.
 Benefits of using a virtualenv
 """"""""""""""""""""""""""""""
 * isolation of your system Python installation from your development installation
 * installation can happen in your user directory without root access (useful for HPC clusters)
 * installing packages through pip allows you to get newer versions of packages than e.g., through apt-get or yum package managers (and without root access)
 * you can even install specific old versions of a package if necessary
 **Prerequisite (e.g. on Ubuntu)**
 .. code-block:: bash
   apt-get install python-venv
 Creating a virtualenv with lammps installed
 """""""""""""""""""""""""""""""""""""""""""
 .. code-block:: bash
   # create virtual envrionment named 'testing'
   python3 -m venv $HOME/python/testing
   # activate 'testing' environment
   source $HOME/python/testing/bin/activate
 Now configure and compile the LAMMPS shared library as outlined above.
 When using CMake and the shared library has already been build, you
 need to re-run CMake to update the location of the python executable
 to the location in the virtual environment with:
 .. code-block:: bash
   cmake . -DPython_EXECUTABLE=$(which python)
   # install LAMMPS package in virtualenv
   (testing) make install-python
   # install other useful packages
   (testing) pip install matplotlib jupyter mpi4py pandas
   ...
   # return to original shell
   (testing) deactivate
 -------
 Creating a new lammps instance
 ------------------------------
 To create a lammps object you need to first import the class from the lammps
 module. By using the default constructor, a new :py:class:`lammps
 <lammps.lammps>` instance is created.
 .. code-block:: python
   from lammps import lammps
   L = lammps()
 See the :doc:`LAMMPS Python documentation <Python_create>` for how to customize
 the instance creation with optional arguments.
 -----
 Commands
 --------
 Sending a LAMMPS command with the library interface is done using
 the ``command`` method of the lammps object.
 For instance, let's take the following LAMMPS command:
 .. code-block:: LAMMPS
   region box block 0 10 0 5 -0.5 0.5
 This command can be executed with the following Python code if ``L`` is a ``lammps``
 instance:
 .. code-block:: python
   L.command("region box block 0 10 0 5 -0.5 0.5")
 For convenience, the ``lammps`` class also provides a command wrapper ``cmd``
 that turns any LAMMPS command into a regular function call:
 .. code-block:: python
   L.cmd.region("box block", 0, 10, 0, 5, -0.5, 0.5)
 Note that each parameter is set as Python number literal. With
 the wrapper each command takes an arbitrary parameter list and transparently
 merges it to a single command string, separating individual parameters by
 white-space.
 The benefit of this approach is avoiding redundant command calls and easier
 parameterization. With the ``command`` function each call needs to be assembled
 manually using formatted strings.
 .. code-block:: python
   L.command(f"region box block {xlo} {xhi} {ylo} {yhi} {zlo} {zhi}")
 The wrapper accepts parameters directly and will convert
 them automatically to a final command string.
 .. code-block:: python
   L.cmd.region("box block", xlo, xhi, ylo, yhi, zlo, zhi)
 .. note::
   When running in IPython you can use Tab-completion after ``L.cmd.`` to see
   all available LAMMPS commands.
 -----
 Accessing atom data
 -------------------
 All per-atom properties that are part of the :doc:`atom style
 <atom_style>` in the current simulation can be accessed using the
 :py:meth:`extract_atoms() <lammps.lammps.extract_atoms()>` method.  This
 can be retrieved as ctypes objects or as NumPy arrays through the
 lammps.numpy module.  Those represent the *local* atoms of the
 individual sub-domain for the current MPI process and may contain
 information for the local ghost atoms or not depending on the property.
 Both can be accessed as lists, but for the ctypes list object the size
 is not known and hast to be retrieved first to avoid out-of-bounds
 accesses.
 .. code-block:: python
   nlocal = L.extract_setting("nlocal")
   nall = L.extract_setting("nall")
   print("Number of local atoms ", nlocal, "  Number of local and ghost atoms ", nall);
   # access via ctypes directly
   atom_id = L.extract_atom("id")
   print("Atom IDs", atom_id[0:nlocal])
   # access through numpy wrapper
   atom_type = L.numpy.extract_atom("type")
   print("Atom types", atom_type)
   x = L.numpy.extract_atom("x")
   v = L.numpy.extract_atom("v")
   print("positions array shape", x.shape)
   print("velocity array shape", v.shape)
   # turn on communicating velocities to ghost atoms
   L.cmd.comm_modify("vel", "yes")
   v = L.numpy.extract_atom('v')
   print("velocity array shape", v.shape)
 Some properties can also be set from Python since internally the
 data of the C++ code is accessed directly:
 .. code-block:: python
   # set position in 2D simulation
   x[0] = (1.0, 0.0)
   # set position in 3D simulation
   x[0] = (1.0, 0.0, 1.)
 ------
 Retrieving the values of thermodynamic data and variables
 ---------------------------------------------------------
 To access thermodynamic data from the last completed timestep,
 you can use the :py:meth:`get_thermo() <lammps.lammps.get_thermo>`
 method, and to extract the value of (compatible) variables, you
 can use the :py:meth:`extract_variable() <lammps.lammps.extract_variable>`
 method.
 .. code-block:: python
   result = L.get_thermo("ke") # kinetic energy
   result = L.get_thermo("pe") # potential energy
   result = L.extract_variable("t") / 2.0
 Error handling
 --------------
 We are using C++ exceptions in LAMMPS for errors and the C language
 library interface captures and records them.  This allows checking
 whether errors have happened in Python during a call into LAMMPS and
 then re-throw the error as a Python exception.  This way you can handle
 LAMMPS errors in the conventional way through the Python exception
 handling mechanism.
 .. warning::
   Capturing a LAMMPS exception in Python can still mean that the
   current LAMMPS process is in an illegal state and must be
   terminated.  It is advised to save your data and terminate the Python
   instance as quickly as possible.
 Using LAMMPS in IPython notebooks and Jupyter
 ---------------------------------------------
 If the LAMMPS Python package is installed for the same Python
 interpreter as IPython, you can use LAMMPS directly inside of an IPython
 notebook inside of Jupyter. Jupyter is a powerful integrated development
 environment (IDE) for many dynamic languages like Python, Julia and
 others, which operates inside of any web browser.  Besides
 auto-completion and syntax highlighting it allows you to create
 formatted documents using Markup, mathematical formulas, graphics and
 animations intermixed with executable Python code.  It is a great format
 for tutorials and showcasing your latest research.
 To launch an instance of Jupyter simply run the following command inside your
 Python environment (this assumes you followed the Quick Start instructions):
 .. code-block:: bash
   jupyter notebook
 Interactive Python Examples
 ---------------------------
 Examples of IPython notebooks can be found in the ``python/examples/ipython``
 subdirectory. To open these notebooks launch ``jupyter notebook`` inside this
 directory and navigate to one of them. If you compiled and installed
 a LAMMPS shared library with PNG, JPEG and FFMPEG support
 you should be able to rerun all of these notebooks.
 Validating a dihedral potential
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 This example showcases how an IPython Notebook can be used to compare a simple
 LAMMPS simulation of a harmonic dihedral potential to its analytical solution.
 Four atoms are placed in the simulation and the dihedral potential is applied on
 them using a datafile. Then one of the atoms is rotated along the central axis by
 setting its position from Python, which changes the dihedral angle.
 .. code-block:: python
   phi = [d \* math.pi / 180 for d in range(360)]
   pos = [(1.0, math.cos(p), math.sin(p)) for p in phi]
   x = L.numpy.extract_atom("x")
   pe = []
   for p in pos:
       x[3] = p
       L.cmd.run(0, "post", "no")
       pe.append(L.get_thermo("pe"))
 By evaluating the potential energy for each position we can verify that
 trajectory with the analytical formula.  To compare both solutions, we plot
 both trajectories over each other using matplotlib, which embeds the generated
 plot inside the IPython notebook.
 .. image:: JPG/pylammps_dihedral.jpg
   :align: center
 Running a Monte Carlo relaxation
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 This second example shows how to use the `lammps` Python interface to create a
 2D Monte Carlo Relaxation simulation, computing and plotting energy terms and
 even embedding video output.
 Initially, a 2D system is created in a state with minimal energy.
 .. image:: JPG/pylammps_mc_minimum.jpg
   :align: center
 It is then disordered by moving each atom by a random delta.
 .. code-block:: python
   random.seed(27848)
   deltaperturb = 0.2
   x = L.numpy.extract_atom("x")
   natoms = x.shape[0]
   for i in range(natoms):
       dx = deltaperturb \* random.uniform(-1, 1)
       dy = deltaperturb \* random.uniform(-1, 1)
       x[i][0] += dx
       x[i][1] += dy
   L.cmd.run(0, "post", "no")
 .. image:: JPG/pylammps_mc_disordered.jpg
   :align: center
 Finally, the Monte Carlo algorithm is implemented in Python. It continuously
 moves random atoms by a random delta and only accepts certain moves.
 .. code-block:: python
   estart = L.get_thermo("pe")
   elast = estart
   naccept = 0
   energies = [estart]
   niterations = 3000
   deltamove = 0.1
   kT = 0.05
   for i in range(niterations):
       x = L.numpy.extract_atom("x")
       natoms = x.shape[0]
       iatom = random.randrange(0, natoms)
       current_atom = x[iatom]
       x0 = current_atom[0]
       y0 = current_atom[1]
       dx = deltamove \* random.uniform(-1, 1)
       dy = deltamove \* random.uniform(-1, 1)
       current_atom[0] = x0 + dx
       current_atom[1] = y0 + dy
       L.cmd.run(1, "pre no post no")
       e = L.get_thermo("pe")
       energies.append(e)
       if e <= elast:
           naccept += 1
           elast = e
       elif random.random() <= math.exp(natoms\*(elast-e)/kT):
           naccept += 1
           elast = e
       else:
           current_atom[0] = x0
           current_atom[1] = y0
 The energies of each iteration are collected in a Python list and finally plotted using matplotlib.
 .. image:: JPG/pylammps_mc_energies_plot.jpg
   :align: center
 The IPython notebook also shows how to use dump commands and embed video files
 inside of the IPython notebook.
--- a/doc/src/Howto_triclinic.rst
+++ b/doc/src/Howto_triclinic.rst
@ -249,23 +249,23 @@ as follows:
 .. math::
-  a   = & {\rm lx} \\
+  a   = & \mathrm{lx} \\
-  b^2 = &  {\rm ly}^2 +  {\rm xy}^2 \\
+  b^2 = &  \mathrm{ly}^2 + \mathrm{xy}^2 \\
-  c^2 = &  {\rm lz}^2 +  {\rm xz}^2 +  {\rm yz}^2 \\
+  c^2 = &  \mathrm{lz}^2 + \mathrm{xz}^2 + \mathrm{yz}^2 \\
-  \cos{\alpha} = & \frac{{\rm xy}*{\rm xz} + {\rm ly}*{\rm yz}}{b*c} \\
+  \cos{\alpha} = & \frac{\mathrm{xy}*\mathrm{xz} + \mathrm{ly}*\mathrm{yz}}{b*c} \\
-  \cos{\beta}  = & \frac{\rm xz}{c} \\
+  \cos{\beta}  = & \frac{\mathrm{xz}}{c} \\
-  \cos{\gamma} = & \frac{\rm xy}{b} \\
+  \cos{\gamma} = & \frac{\mathrm{xy}}{b} \\
 The inverse relationship can be written as follows:
 .. math::
-  {\rm lx}   = & a \\
+  \mathrm{lx}   = & a \\
-  {\rm xy}   = & b \cos{\gamma}  \\
+  \mathrm{xy}   = & b \cos{\gamma}  \\
-  {\rm xz}   = & c \cos{\beta}\\
+  \mathrm{xz}   = & c \cos{\beta}\\
-  {\rm ly}^2 = & b^2 - {\rm xy}^2 \\
+  \mathrm{ly}^2 = & b^2 - \mathrm{xy}^2 \\
-  {\rm yz}   = & \frac{b*c \cos{\alpha} - {\rm xy}*{\rm xz}}{\rm ly} \\
+  \mathrm{yz}   = & \frac{b*c \cos{\alpha} - \mathrm{xy}*\mathrm{xz}}{\mathrm{ly}} \\
-  {\rm lz}^2 = & c^2 - {\rm xz}^2 - {\rm yz}^2 \\
+  \mathrm{lz}^2 = & c^2 - \mathrm{xz}^2 - \mathrm{yz}^2 \\
 The values of *a*, *b*, *c*, :math:`\alpha` , :math:`\beta`, and
 :math:`\gamma` can be printed out or accessed by computes using the
--- a/doc/src/Install_git.rst
+++ b/doc/src/Install_git.rst
@ -52,6 +52,7 @@ your machine and "release" is one of the 3 branches listed above.
 between them at any time using "git checkout <branch name>".)
 .. admonition:: Saving time and disk space when using ``git clone``
   :class: note
   The complete git history of the LAMMPS project is quite large because
   it contains the entire commit history of the project since fall 2006,
--- a/doc/src/Install_mac.rst
+++ b/doc/src/Install_mac.rst
@ -5,8 +5,7 @@ LAMMPS can be downloaded, built, and configured for macOS with `Homebrew
 <homebrew_>`_.  (Alternatively, see the installation instructions for
 :doc:`downloading an executable via Conda <Install_conda>`.)  The
 following LAMMPS packages are unavailable at this time because of
-additional requirements not yet met: GPU, KOKKOS, MSCG, POEMS,
+additional requirements not yet met: GPU, KOKKOS.
 VORONOI.
 After installing Homebrew, you can install LAMMPS on your system with
 the following commands:
--- a/doc/src/Intro_portability.rst
+++ b/doc/src/Intro_portability.rst
@ -13,10 +13,14 @@ Programming language standards
 Most of the C++ code currently requires a compiler compatible with the
 C++11 standard, the KOKKOS package currently requires C++17.  Most of
-the Python code is written to be compatible with Python 3.5 or later or
+the Python code is written to be compatible with Python 3.6 or later.
 Python 2.7.  Some Python scripts *require* Python 3 and a few others
 still need to be ported from Python 2 to Python 3.
 .. deprecated:: TBD
 Python 2.x is no longer supported and trying to use it, e.g. for the
 LAMMPS Python module should result in an error.  If you come across
 some part of the LAMMPS distribution that is not (yet) compatible with
 Python 3, please notify the LAMMPS developers.
 Build systems
 ^^^^^^^^^^^^^
@ -24,8 +28,8 @@ Build systems
 LAMMPS can be compiled from source code using a (traditional) build
 system based on shell scripts, a few shell utilities (grep, sed, cat,
 tr) and the GNU make program. This requires running within a Bourne
-shell (``/bin/sh``).  Alternatively, a build system with different back ends
+shell (``/bin/sh``).  Alternatively, a build system with different back
-can be created using CMake.  CMake must be at least version 3.16.
+ends can be created using CMake.  CMake must be at least version 3.16.
 Operating systems
 ^^^^^^^^^^^^^^^^^
--- a/doc/src/JPG/PolyNIPAM.jpg
+++ b/doc/src/JPG/PolyNIPAM.jpg
--- a/doc/src/JPG/butane.jpg
+++ b/doc/src/JPG/butane.jpg
--- a/doc/src/JPG/rhodo-both.jpg
+++ b/doc/src/JPG/rhodo-both.jpg
--- a/doc/src/Library.rst
+++ b/doc/src/Library.rst
@ -131,16 +131,15 @@ run LAMMPS in serial mode.
 .. _lammps_python_api:
-LAMMPS Python APIs
+LAMMPS Python API
-==================
+=================
 The LAMMPS Python module enables calling the LAMMPS C library API from
 Python by dynamically loading functions in the LAMMPS shared library through
 the `Python ctypes module <https://docs.python.org/3/library/ctypes.html>`_.
 Because of the dynamic loading, it is **required** that LAMMPS is compiled
 in :ref:`"shared" mode <exe>`.  The Python interface is object-oriented, but
-otherwise tries to be very similar to the C library API.  Three different
+otherwise tries to be very similar to the C library API.
 Python classes to run LAMMPS are available and they build on each other.
 More information on this is in the :doc:`Python_head`
 section of the manual.  Use of the LAMMPS Python module is described in
 :doc:`Python_module`.
--- a/doc/src/Library_add.rst
+++ b/doc/src/Library_add.rst
@ -19,9 +19,9 @@ there are now a few requirements for including new changes or extensions.
    be added.
  - New features should also be implemented and documented not just
    for the C interface, but also the Python and Fortran interfaces.
-  - All additions should work and be compatible with ``-DLAMMPS_BIGBIG``,
+  - All additions should work and be compatible with
-    ``-DLAMMPS_SMALLBIG``, ``-DLAMMPS_SMALLSMALL`` as well as when
+    ``-DLAMMPS_BIGBIG``, ``-DLAMMPS_SMALLBIG`` as well as when compiling
-    compiling with and without MPI support.
+    with and without MPI support.
  - The ``library.h`` file should be kept compatible to C code at
    a level similar to C89. Its interfaces may not reference any
    custom data types (e.g. ``bigint``, ``tagint``, and so on) that
--- a/doc/src/Library_execute.rst
+++ b/doc/src/Library_execute.rst
@ -7,6 +7,7 @@ This section documents the following functions:
 - :cpp:func:`lammps_command`
 - :cpp:func:`lammps_commands_list`
 - :cpp:func:`lammps_commands_string`
 - :cpp:func:`lammps_expand`
 --------------------
@ -79,3 +80,8 @@ Below is a short example using some of these functions.
 .. doxygenfunction:: lammps_commands_string
   :project: progguide
 -----------------------
 .. doxygenfunction:: lammps_expand
   :project: progguide
--- a/doc/src/Library_objects.rst
+++ b/doc/src/Library_objects.rst
@ -1,5 +1,5 @@
-Compute, fixes, variables
+Computes, fixes, variables
-=========================
+==========================
 This section documents accessing or modifying data stored by computes,
 fixes, or variables in LAMMPS using the following functions:
@ -12,6 +12,10 @@ fixes, or variables in LAMMPS using the following functions:
 - :cpp:func:`lammps_set_string_variable`
 - :cpp:func:`lammps_set_internal_variable`
 - :cpp:func:`lammps_variable_info`
 - :cpp:func:`lammps_eval`
 - :cpp:func:`lammps_clearstep_compute`
 - :cpp:func:`lammps_addstep_compute_all`
 - :cpp:func:`lammps_addstep_compute`
 -----------------------
@ -55,6 +59,26 @@ fixes, or variables in LAMMPS using the following functions:
 -----------------------
 .. doxygenfunction:: lammps_eval
   :project: progguide
 -----------------------
 .. doxygenfunction:: lammps_clearstep_compute
   :project: progguide
 -----------------------
 .. doxygenfunction:: lammps_addstep_compute_all
   :project: progguide
 -----------------------
 .. doxygenfunction:: lammps_addstep_compute
   :project: progguide
 -----------------------
 .. doxygenenum:: _LMP_DATATYPE_CONST
 .. doxygenenum:: _LMP_STYLE_CONST
--- a/doc/src/Library_utility.rst
+++ b/doc/src/Library_utility.rst
@ -20,6 +20,7 @@ functions.  They do not directly call the LAMMPS library.
 - :cpp:func:`lammps_force_timeout`
 - :cpp:func:`lammps_has_error`
 - :cpp:func:`lammps_get_last_error_message`
 - :cpp:func:`lammps_set_show_error`
 - :cpp:func:`lammps_python_api_version`
 The :cpp:func:`lammps_free` function is a clean-up function to free
@ -110,6 +111,11 @@ where such memory buffers were allocated that require the use of
 -----------------------
 .. doxygenfunction:: lammps_set_show_error
   :project: progguide
 -----------------------
 .. doxygenfunction:: lammps_python_api_version
   :project: progguide
--- a/doc/src/Modify_compute.rst
+++ b/doc/src/Modify_compute.rst
@ -45,6 +45,8 @@ class.  See compute.h for details.
 +-----------------------+------------------------------------------------------------------+
 | pair_tally_callback   | callback function for *tally*\ -style computes (optional).       |
 +-----------------------+------------------------------------------------------------------+
 | modify_param          | called when a compute_modify request is executed (optional)      |
 +-----------------------+------------------------------------------------------------------+
 | memory_usage          | tally memory usage (optional)                                    |
 +-----------------------+------------------------------------------------------------------+
--- a/doc/src/Modify_requirements.rst
+++ b/doc/src/Modify_requirements.rst
@ -189,10 +189,8 @@ of the contribution.  As of January 2023, all previously included
 Fortran code for the LAMMPS executable has been replaced by equivalent
 C++ code.
-Python code must be compatible with Python 3.5 and later.  Large parts
+Python code currently must be compatible with Python 3.6.  If a later
-of LAMMPS (including the :ref:`PYTHON package <PKG-PYTHON>`) are also
+version or Python is required, it needs to be documented.
 compatible with Python 2.7.  Compatibility with Python 2.7 is desirable,
 but compatibility with Python 3.5 is **required**.
 Compatibility with older programming language standards is very
 important to maintain portability and availability of LAMMPS on many
@ -208,20 +206,21 @@ Build system (strict)
 LAMMPS currently supports two build systems: one that is based on
 :doc:`traditional Makefiles <Build_make>` and one that is based on
-:doc:`CMake <Build_cmake>`.  Therefore, your contribution must be
+:doc:`CMake <Build_cmake>`.  As of fall 2024, it is no longer required
-compatible with and support both build systems.
+to support the traditional make build system.  New packages may choose
 to only support building with CMake.  Additions to existing packages
 must follow the requirements set by that package.
 For a single pair of header and implementation files that are an
 independent feature, it is usually only required to add them to
 ``src/.gitignore``.
 For traditional make, if your contributed files or package depend on
-other LAMMPS style files or packages also being installed
+other LAMMPS style files or packages also being installed (e.g. because
-(e.g. because your file is a derived class from the other LAMMPS
+your file is a derived class from the other LAMMPS class), then an
-class), then an ``Install.sh`` file is also needed to check for those
+``Install.sh`` file is also needed to check for those dependencies and
-dependencies and modifications to ``src/Depend.sh`` to trigger the checks.
+modifications to ``src/Depend.sh`` to trigger the checks.  See other
-See other README and Install.sh files in other directories as
+README and Install.sh files in other directories as examples.
 examples.
 Similarly, for CMake support, changes may need to be made to
 ``cmake/CMakeLists.txt``, some of the files in ``cmake/presets``, and
--- a/doc/src/Packages_details.rst
+++ b/doc/src/Packages_details.rst
@ -994,6 +994,7 @@ Additional pair styles that are less commonly used.
 * ``src/EXTRA-PAIR``: filenames -> commands
 * :doc:`pair_style <pair_style>`
 * ``examples/PACKAGES/dispersion``
 ----------
@ -2427,7 +2428,7 @@ ways to use LAMMPS and Python together.
   Building with the PYTHON package assumes you have a Python development
   environment (headers and libraries) available on your system, which needs
-   to be either Python version 2.7 or Python 3.5 and later.
+   to be Python version 3.6 or later.
 **Install:**
--- a/doc/src/Python_atoms.rst
+++ b/doc/src/Python_atoms.rst
@ -2,14 +2,8 @@ Per-atom properties
 ===================
 Similar to what is described in :doc:`Library_atoms`, the instances of
-:py:class:`lammps <lammps.lammps>`, :py:class:`PyLammps <lammps.PyLammps>`, or
+:py:class:`lammps <lammps.lammps>` can be used to extract atom quantities
-:py:class:`IPyLammps <lammps.IPyLammps>` can be used to extract atom quantities
+and modify some of them.
 and modify some of them. The main difference between the interfaces is how the information
 is exposed.
 While the :py:class:`lammps <lammps.lammps>` is just a thin layer that wraps C API calls,
 :py:class:`PyLammps <lammps.PyLammps>` and :py:class:`IPyLammps <lammps.IPyLammps>` expose
 information as objects and properties.
 In some cases the data returned is a direct reference to the original data
 inside LAMMPS cast to ``ctypes`` pointers. Where possible, the wrappers will
@ -25,10 +19,6 @@ against invalid accesses.
   accordingly. These arrays can change sizes and order at every neighbor list
   rebuild and atom sort event as atoms are migrating between subdomains.
 .. tabs::
   .. tab:: lammps API
 .. code-block:: python
   from lammps import lammps
@ -36,14 +26,30 @@ against invalid accesses.
   lmp = lammps()
   lmp.file("in.sysinit")
   # Read/Write access via ctypes
   nlocal = lmp.extract_global("nlocal")
   x = lmp.extract_atom("x")
   for i in range(nlocal):
      print("(x,y,z) = (", x[i][0], x[i][1], x[i][2], ")")
   # Read/Write access via NumPy arrays
   atom_id = L.numpy.extract_atom("id")
   atom_type = L.numpy.extract_atom("type")
   x = L.numpy.extract_atom("x")
   v = L.numpy.extract_atom("v")
   f = L.numpy.extract_atom("f")
   # set position in 2D simulation
   x[0] = (1.0, 0.0)
   # set position in 3D simulation
   x[0] = (1.0, 0.0, 1.)
   lmp.close()
 **Methods**:
 * :py:meth:`extract_atom() <lammps.lammps.extract_atom()>`: extract a per-atom quantity
@ -51,31 +57,3 @@ against invalid accesses.
 **Numpy Methods**:
 * :py:meth:`numpy.extract_atom() <lammps.numpy_wrapper.numpy_wrapper.extract_atom()>`: extract a per-atom quantity as numpy array
   .. tab:: PyLammps/IPyLammps API
      All atoms in the current simulation can be accessed by using the :py:attr:`PyLammps.atoms <lammps.PyLammps.atoms>` property.
      Each element of this list is a :py:class:`Atom <lammps.Atom>` or :py:class:`Atom2D <lammps.Atom2D>` object. The attributes of
      these objects provide access to their data (id, type, position, velocity, force, etc.):
      .. code-block:: python
         # access first atom
         L.atoms[0].id
         L.atoms[0].type
         # access second atom
         L.atoms[1].position
         L.atoms[1].velocity
         L.atoms[1].force
      Some attributes can be changed:
      .. code-block:: python
         # set position in 2D simulation
         L.atoms[0].position = (1.0, 0.0)
         # set position in 3D simulation
         L.atoms[0].position = (1.0, 0.0, 1.0)
--- a/doc/src/Python_create.rst
+++ b/doc/src/Python_create.rst
@ -6,11 +6,10 @@ Creating or deleting a LAMMPS object
 ====================================
 With the Python interface the creation of a :cpp:class:`LAMMPS
-<LAMMPS_NS::LAMMPS>` instance is included in the constructors for the
+<LAMMPS_NS::LAMMPS>` instance is included in the constructor for the
-:py:class:`lammps <lammps.lammps>`, :py:class:`PyLammps <lammps.PyLammps>`,
+:py:class:`lammps <lammps.lammps>` class. Internally it will call either
-and :py:class:`IPyLammps <lammps.IPyLammps>` classes.
+:cpp:func:`lammps_open` or :cpp:func:`lammps_open_no_mpi` from the C library
-Internally it will call either :cpp:func:`lammps_open` or :cpp:func:`lammps_open_no_mpi` from the C
+API to create the class instance.
 library API to create the class instance.
 All arguments are optional.  The *name* argument allows loading a
 LAMMPS shared library that is named ``liblammps_machine.so`` instead of
@ -26,11 +25,7 @@ to run the Python module like the library interface on a subset of the
 MPI ranks after splitting the communicator.
-Here are simple examples using all three Python interfaces:
+Here is a simple example using the LAMMPS Python interface:
 .. tabs::
   .. tab:: lammps API
 .. code-block:: python
@ -48,86 +43,7 @@ Here are simple examples using all three Python interfaces:
   # explicitly close and delete LAMMPS instance (optional)
   lmp.close()
-   .. tab:: PyLammps API
+Same as with the :ref:`C library API <lammps_c_api>`, this will use the
      The :py:class:`PyLammps <lammps.PyLammps>` class is a wrapper around the
      :py:class:`lammps <lammps.lammps>` class and all of its lower level functions.
      By default, it will create a new instance of :py:class:`lammps <lammps.lammps>` passing
      along all arguments to the constructor of :py:class:`lammps <lammps.lammps>`.
      .. code-block:: python
         from lammps import PyLammps
         # NOTE: argv[0] is set by the lammps class constructor
         args = ["-log", "none"]
         # create LAMMPS instance
         L = PyLammps(cmdargs=args)
         # get and print numerical version code
         print("LAMMPS Version: ", L.version())
         # explicitly close and delete LAMMPS instance (optional)
         L.close()
      :py:class:`PyLammps <lammps.PyLammps>` objects can also be created on top of an existing
      :py:class:`lammps <lammps.lammps>` object:
      .. code-block:: python
         from lammps import lammps, PyLammps
         ...
         # create LAMMPS instance
         lmp = lammps(cmdargs=args)
         # create PyLammps instance using previously created LAMMPS instance
         L = PyLammps(ptr=lmp)
      This is useful if you have to create the :py:class:`lammps <lammps.lammps>`
      instance is a specific way, but want to take advantage of the
      :py:class:`PyLammps <lammps.PyLammps>` interface.
   .. tab:: IPyLammps API
      The :py:class:`IPyLammps <lammps.IPyLammps>` class is an extension of the
      :py:class:`PyLammps <lammps.PyLammps>` class. It has the same construction behavior. By
      default, it will create a new instance of :py:class:`lammps` passing
      along all arguments to the constructor of :py:class:`lammps`.
      .. code-block:: python
         from lammps import IPyLammps
         # NOTE: argv[0] is set by the lammps class constructor
         args = ["-log", "none"]
         # create LAMMPS instance
         L = IPyLammps(cmdargs=args)
         # get and print numerical version code
         print("LAMMPS Version: ", L.version())
         # explicitly close and delete LAMMPS instance (optional)
         L.close()
      You can also initialize IPyLammps on top of an existing :py:class:`lammps` or :py:class:`PyLammps` object:
      .. code-block:: python
         from lammps import lammps, IPyLammps
         ...
         # create LAMMPS instance
         lmp = lammps(cmdargs=args)
         # create PyLammps instance using previously created LAMMPS instance
         L = PyLammps(ptr=lmp)
      This is useful if you have to create the :py:class:`lammps <lammps.lammps>`
      instance is a specific way, but want to take advantage of the
      :py:class:`IPyLammps <lammps.IPyLammps>` interface.
 In all of the above cases, same as with the :ref:`C library API <lammps_c_api>`, this will use the
 ``MPI_COMM_WORLD`` communicator for the MPI library that LAMMPS was
 compiled with.
--- a/doc/src/Python_execute.rst
+++ b/doc/src/Python_execute.rst
@ -1,24 +1,17 @@
 Executing commands
 ==================
-Once an instance of the :py:class:`lammps <lammps.lammps>`,
+Once an instance of the :py:class:`lammps <lammps.lammps>` class is created, there are
 :py:class:`PyLammps <lammps.PyLammps>`, or
 :py:class:`IPyLammps <lammps.IPyLammps>` class is created, there are
 multiple ways to "feed" it commands. In a way that is not very different from
 running a LAMMPS input script, except that Python has many more facilities
 for structured programming than the LAMMPS input script syntax. Furthermore
 it is possible to "compute" what the next LAMMPS command should be.
-.. tabs::
+Same as in the equivalent :doc:`C library functions <Library_execute>`,
-
+commands can be read from a file, a single string, a list of strings and a
-   .. tab:: lammps API
+block of commands in a single multi-line string. They are processed under the
-
+same boundary conditions as the C library counterparts.  The example below
-      Same as in the equivalent
+demonstrates the use of :py:func:`lammps.file()`, :py:func:`lammps.command()`,
      :doc:`C library functions <Library_execute>`, commands can be read from a file, a
      single string, a list of strings and a block of commands in a single
      multi-line string. They are processed under the same boundary conditions
      as the C library counterparts.  The example below demonstrates the use
      of :py:func:`lammps.file()`, :py:func:`lammps.command()`,
 :py:func:`lammps.commands_list()`, and :py:func:`lammps.commands_string()`:
 .. code-block:: python
@ -33,7 +26,7 @@ it is possible to "compute" what the next LAMMPS command should be.
   lmp.command('variable zpos index 1.0')
   # create 10 groups with 10 atoms each
-         cmds = ["group g{} id {}:{}".format(i,10*i+1,10*(i+1)) for i in range(10)]
+   cmds = [f"group g{i} id {10*i+1}:{10*(i+1)}" for i in range(10)]
   lmp.commands_list(cmds)
   # run commands from a multi-line string
@ -45,11 +38,9 @@ it is possible to "compute" what the next LAMMPS command should be.
   """
   lmp.commands_string(block)
-   .. tab:: PyLammps/IPyLammps API
+For convenience, the :py:class:`lammps <lammps.lammps>` class also provides a
-
+command wrapper ``cmd`` that turns any LAMMPS command into a regular function
-      Unlike the lammps API, the PyLammps/IPyLammps APIs allow running LAMMPS
+call.
      commands by calling equivalent member functions of :py:class:`PyLammps <lammps.PyLammps>`
      and :py:class:`IPyLammps <lammps.IPyLammps>` instances.
 For instance, the following LAMMPS command
@ -57,8 +48,7 @@ it is possible to "compute" what the next LAMMPS command should be.
   region box block 0 10 0 5 -0.5 0.5
-      can be executed using with the lammps API with the following Python code if ``lmp`` is an
+would normally be executed with the following Python code:
      instance of :py:class:`lammps <lammps.lammps>`:
 .. code-block:: python
@ -67,7 +57,7 @@ it is possible to "compute" what the next LAMMPS command should be.
   lmp = lammps()
   lmp.command("region box block 0 10 0 5 -0.5 0.5")
-      With the PyLammps interface, any LAMMPS command can be split up into arbitrary parts.
+With the ``cmd`` wrapper, any LAMMPS command can be split up into arbitrary parts.
 These parts are then passed to a member function with the name of the :doc:`command <Commands_all>`.
 For the :doc:`region <region>` command that means the :code:`region()` method can be called.
 The arguments of the command can be passed as one string, or
@ -75,53 +65,59 @@ it is possible to "compute" what the next LAMMPS command should be.
 .. code-block:: python
-         from lammps import PyLammps
+   from lammps import lammps
-         L = PyLammps()
+   L = lammps()
   # pass command parameters as one string
-         L.region("box block 0 10 0 5 -0.5 0.5")
+   L.cmd.region("box block 0 10 0 5 -0.5 0.5")
   # OR pass them individually
-         L.region("box block", 0, 10, 0, 5, -0.5, 0.5)
+   L.cmd.region("box block", 0, 10, 0, 5, -0.5, 0.5)
 In the latter example, all parameters except the first are Python floating-point literals. The
 member function takes the entire parameter list and transparently merges it to a single command
 string.
 The benefit of this approach is avoiding redundant command calls and easier
-      parameterization. In the lammps API parameterization needed to be done
+parameterization. With `command`, `commands_list`, and `commands_string` the
-      manually by creating formatted command strings.
+parameterization needed to be done manually by creating formatted command
 strings.
 .. code-block:: python
   lmp.command("region box block %f %f %f %f %f %f" % (xlo, xhi, ylo, yhi, zlo, zhi))
-      In contrast, methods of PyLammps accept parameters directly and will convert
+In contrast, methods of the `cmd` wrapper accept parameters directly and will convert
 them automatically to a final command string.
 .. code-block:: python
-         L.region("box block", xlo, xhi, ylo, yhi, zlo, zhi)
+   L.cmd.region("box block", xlo, xhi, ylo, yhi, zlo, zhi)
-      Using these facilities, the example shown for the lammps API can be rewritten as follows:
+.. note::
   When running in IPython you can use Tab-completion after ``L.cmd.`` to see
   all available LAMMPS commands.
 Using these facilities, the previous example shown above can be rewritten as follows:
 .. code-block:: python
-         from lammps import PyLammps
+   from lammps import lammps
-         L = PyLammps()
+   L = lammps()
   # read commands from file 'in.melt'
   L.file('in.melt')
   # issue a single command
-         L.variable('zpos', 'index', 1.0)
+   L.cmd.variable('zpos', 'index', 1.0)
   # create 10 groups with 10 atoms each
   for i in range(10):
-            L.group(f"g{i}", "id", f"{10*i+1}:{10*(i+1)}")
+      L.cmd.group(f"g{i}", "id", f"{10*i+1}:{10*(i+1)}")
-         L.clear()
+   L.cmd.clear()
-         L.region("box block", 0, 2, 0, 2, 0, 2)
+   L.cmd.region("box block", 0, 2, 0, 2, 0, 2)
-         L.create_box(1, "box")
+   L.cmd.create_box(1, "box")
-         L.create_atoms(1, "single", 1.0, 1.0, "${zpos}")
+   L.cmd.create_atoms(1, "single", 1.0, 1.0, "${zpos}")
--- a/doc/src/Python_head.rst
+++ b/doc/src/Python_head.rst
@ -15,6 +15,7 @@ together.
   Python_call
   Python_formats
   Python_examples
   Python_jupyter
   Python_error
   Python_trouble
--- a/doc/src/Python_install.rst
+++ b/doc/src/Python_install.rst
@ -7,6 +7,10 @@ LAMMPS shared library through the Python `ctypes <ctypes_>`_
 module.  Because of the dynamic loading, it is required that LAMMPS is
 compiled in :ref:`"shared" mode <exe>`.
 .. versionchanged:: TBD
 LAMMPS currently only supports Python version 3.6 or later.
 Two components are necessary for Python to be able to invoke LAMMPS code:
 * The LAMMPS Python Package (``lammps``) from the ``python`` folder
@ -106,13 +110,16 @@ folder that the dynamic loader searches or inside of the installed
      .. code-block:: bash
-         python install.py -p <python package> -l <shared library> -v <version.h file> [-n]
+         python install.py -p <python package> -l <shared library> -v <version.h file> [-n] [-f]
      * The ``-p`` flag points to the ``lammps`` Python package folder to be installed,
      * the ``-l`` flag points to the LAMMPS shared library file to be installed,
      * the ``-v`` flag points to the LAMMPS version header file to extract the version date,
-      * and the optional ``-n`` instructs the script to only build a wheel file
+      * the optional ``-n`` instructs the script to only build a wheel file but not attempt
-        but not attempt to install it.
+        to install it,
      * and the optional ``-f`` argument instructs the script to force installation even if
        pip would otherwise refuse installation with an
        :ref:`error about externally managed environments <externally_managed>`.
   .. tab:: Virtual environment
@ -136,11 +143,6 @@ folder that the dynamic loader searches or inside of the installed
         # create virtual environment in folder $HOME/myenv
         python3 -m venv $HOME/myenv
      For Python versions prior 3.3 you can use `virtualenv
      <https://packaging.python.org/en/latest/key_projects/#virtualenv>`_
      command instead of "python3 -m venv".  This step has to be done
      only once.
      To activate the virtual environment type:
      .. code-block:: bash
@ -199,6 +201,10 @@ folder that the dynamic loader searches or inside of the installed
         The ``PYTHONPATH`` needs to point to the parent folder that contains the ``lammps`` package!
 In case you run into an "externally-managed-environment" error when
 trying to install the LAMMPS Python module, please refer to
 :ref:`corresponding paragraph <externally_managed>` in the Python HOWTO
 page to learn about options for handling this error.
 To verify if LAMMPS can be successfully started from Python, start the
 Python interpreter, load the ``lammps`` Python module and create a
@ -245,14 +251,14 @@ make MPI calls directly from Python in your script, if you desire.
 We have tested this with `MPI for Python <https://mpi4py.readthedocs.io/>`_
 (aka mpi4py) and you will find installation instruction for it below.
-Installation of mpi4py (version 3.0.3 as of Sep 2020) can be done as
+Installation of mpi4py (version 4.0.1 as of Feb 2025) can be done as
 follows:
 - Via ``pip`` into a local user folder with:
  .. code-block:: bash
-     pip install --user mpi4py
+     python3 -m pip install --user mpi4py
 - Via ``dnf`` into a system folder for RedHat/Fedora systems:
@ -261,20 +267,20 @@ follows:
     # for use with OpenMPI
     sudo dnf install python3-mpi4py-openmpi
     # for use with MPICH
-     sudo dnf install python3-mpi4py-openmpi
+     sudo dnf install python3-mpi4py-mpich
 - Via ``pip`` into a virtual environment (see above):
  .. code-block:: console
     $ source $HOME/myenv/activate
-     (myenv)$ pip install mpi4py
+     (myenv)$ python -m pip install mpi4py
 - Via ``pip`` into a system folder (not recommended):
  .. code-block:: bash
-     sudo pip install mpi4py
+     sudo python3 -m pip install mpi4py
 For more detailed installation instructions and additional options,
 please see the `mpi4py installation <https://mpi4py.readthedocs.io/en/stable/install.html>`_ page.
--- a/doc/src/Python_jupyter.rst
+++ b/doc/src/Python_jupyter.rst
@ -0,0 +1,45 @@
 Using LAMMPS in IPython notebooks and Jupyter
 =============================================
 If the LAMMPS Python package is installed for the same Python interpreter as
 `IPython <ipython>`_, you can use LAMMPS directly inside of an IPython notebook inside of
 Jupyter. `Jupyter <juypter>`_ is a powerful integrated development environment (IDE) for
 many dynamic languages like Python, Julia and others, which operates inside of
 any web browser. Besides auto-completion and syntax highlighting it allows you
 to create formatted documents using Markup, mathematical formulas, graphics and
 animations intermixed with executable Python code. It is a great format for
 tutorials and showcasing your latest research.
 The easiest way to install it is via ``pip``:
 .. code-block:: bash
   pip install --user jupyter
 To launch an instance of Jupyter simply run the following command inside your
 Python environment:
 .. code-block:: bash
   jupyter notebook
 Interactive Python Examples
 ---------------------------
 Examples of IPython notebooks can be found in the ``python/examples/ipython``
 subdirectory. They require LAMMPS to be compiled as shared library with PYTHON,
 PNG, JPEG and FFMPEG support.
 To open these notebooks launch ``jupyter notebook index.ipynb`` inside this
 directory. The opened file provides an overview of the available examples.
 - Example 1: Using LAMMPS with Python (``simple.ipynb``)
 - Example 2: Analyzing LAMMPS thermodynamic data (``thermo.ipynb``)
 - Example 3: Working with Per-Atom Data (``atoms.ipynb``)
 - Example 4: Working with LAMMPS variables (``variables.ipynb``)
 - Example 5: Validating a dihedral potential (``dihedrals/dihedral.ipynb``)
 - Example 6: Running a Monte Carlo relaxation (``montecarlo/mc.ipynb``)
 .. note::
   Typically clicking a link in Jupyter will open a new tab, which might be blocked by your pop-up blocker.
--- a/doc/src/Python_module.rst
+++ b/doc/src/Python_module.rst
@ -10,19 +10,11 @@ be installed into a Python system folder or a user folder with ``make
 install-python``.  Components of the module can then loaded into a Python
 session with the ``import`` command.
-There are multiple Python interface classes in the :py:mod:`lammps` module:
+.. warning::
- the :py:class:`lammps <lammps.lammps>` class. This is a wrapper around
+   Alternative interfaces such as :py:class:`PyLammps <lammps.PyLammps>` and
-  the C-library interface and its member functions try to replicate the
+   :py:class:`IPyLammps <lammps.IPyLammps>` classes have been deprecated and
-  :ref:`C-library API <lammps_c_api>` closely.  This is the most
+   will be removed in a future version of LAMMPS.
  feature-complete Python API.
 - the :py:class:`PyLammps <lammps.PyLammps>` class. This is a more high-level
  and more Python style class implemented on top of the
  :py:class:`lammps <lammps.lammps>` class.
 - the :py:class:`IPyLammps <lammps.IPyLammps>` class is derived from
  :py:class:`PyLammps <lammps.PyLammps>` and adds embedded graphics
  features to conveniently include LAMMPS into `Jupyter
  <https://jupyter.org/>`_ notebooks.
 .. _mpi4py_url: https://mpi4py.readthedocs.io
@ -49,7 +41,7 @@ The ``lammps`` class API
 ========================
 The :py:class:`lammps <lammps.lammps>` class is the core of the LAMMPS
-Python interfaces.  It is a wrapper around the :ref:`LAMMPS C library
+Python interface.  It is a wrapper around the :ref:`LAMMPS C library
 API <lammps_c_api>` using the `Python ctypes module
 <https://docs.python.org/3/library/ctypes.html>`_ and a shared library
 compiled from the LAMMPS sources code.  The individual methods in this
@ -64,40 +56,7 @@ functions. Below is a detailed documentation of the API.
 .. autoclass:: lammps.numpy_wrapper::numpy_wrapper
   :members:
----------
+.. autoclass:: lammps.ipython::wrapper
 The ``PyLammps`` class API
 ==========================
 The :py:class:`PyLammps <lammps.PyLammps>` class is a wrapper that creates a
 simpler, more "Pythonic" interface to common LAMMPS functionality. LAMMPS
 data structures are exposed through objects and properties. This makes Python
 scripts shorter and more concise. See the :doc:`PyLammps Tutorial
 <Howto_pylammps>` for an introduction on how to use this interface.
 .. autoclass:: lammps.PyLammps
   :members:
 .. autoclass:: lammps.AtomList
   :members:
 .. autoclass:: lammps.Atom
   :members:
 .. autoclass:: lammps.Atom2D
   :members:
 ----------
 The ``IPyLammps`` class API
 ===========================
 The :py:class:`IPyLammps <lammps.PyLammps>` class is an extension of
 :py:class:`PyLammps <lammps.PyLammps>`, adding additional functions to
 quickly display visualizations such as images and videos inside of IPython.
 See the :doc:`PyLammps Tutorial <Howto_pylammps>` for examples.
 .. autoclass:: lammps.IPyLammps
   :members:
 ----------
--- a/doc/src/Python_objects.rst
+++ b/doc/src/Python_objects.rst
@ -4,10 +4,6 @@ Compute, fixes, variables
 This section documents accessing or modifying data from objects like
 computes, fixes, or variables in LAMMPS using the :py:mod:`lammps` module.
 .. tabs::
   .. tab:: lammps API
 For :py:meth:`lammps.extract_compute() <lammps.lammps.extract_compute()>` and
 :py:meth:`lammps.extract_fix() <lammps.lammps.extract_fix()>`, the global, per-atom,
 or local data calculated by the compute or fix can be accessed. What is returned
@ -57,42 +53,3 @@ computes, fixes, or variables in LAMMPS using the :py:mod:`lammps` module.
 * :py:meth:`lammps.numpy.extract_compute() <lammps.numpy_wrapper.numpy_wrapper.extract_compute()>`: extract value(s) from a compute, return arrays as numpy arrays
 * :py:meth:`lammps.numpy.extract_fix() <lammps.numpy_wrapper.numpy_wrapper.extract_fix()>`: extract value(s) from a fix, return arrays as numpy arrays
 * :py:meth:`lammps.numpy.extract_variable() <lammps.numpy_wrapper.numpy_wrapper.extract_variable()>`: extract value(s) from a variable, return arrays as numpy arrays
   .. tab:: PyLammps/IPyLammps API
      PyLammps and IPyLammps classes currently do not add any additional ways of
      retrieving information out of computes and fixes. This information can still be accessed by using the lammps API:
      .. code-block:: python
         L.lmp.extract_compute(...)
         L.lmp.extract_fix(...)
         # OR
         L.lmp.numpy.extract_compute(...)
         L.lmp.numpy.extract_fix(...)
      LAMMPS variables can be both defined and accessed via the :py:class:`PyLammps <lammps.PyLammps>` interface.
      To define a variable you can use the :doc:`variable <variable>` command:
      .. code-block:: python
         L.variable("a index 2")
      A dictionary of all variables is returned by the :py:attr:`PyLammps.variables <lammps.PyLammps.variables>` property:
      you can access an individual variable by retrieving a variable object from the
      ``L.variables`` dictionary by name
      .. code-block:: python
         a = L.variables['a']
      The variable value can then be easily read and written by accessing the value
      property of this object.
      .. code-block:: python
         print(a.value)
         a.value = 4
--- a/doc/src/Python_overview.rst
+++ b/doc/src/Python_overview.rst
@ -44,19 +44,15 @@ Below is an example output for Python version 3.8.5.
 .. warning::
   The options described in this section of the manual for using Python
-   with LAMMPS currently support either Python 2 or 3.  Specifically
+   with LAMMPS support only Python 3.6 or later.  For use with Python
-   version 2.7 or later and 3.6 or later.  Since the Python community no
+   2.x you will need to use an older LAMMPS version like 29 Aug 2024
-   longer maintains Python 2 (see `this notice
+   or older.  If you notice Python code in the LAMMPS distribution that
-   <https://www.python.org/doc/sunset-python-2/>`_), we recommend use of
+   is not compatible with Python 3, please contact the LAMMPS developers
-   Python 3 with LAMMPS.  While Python 2 code should continue to work,
+   or submit `and issue on GitHub <https://github.com/lammps/lammps/issues>`_
   that is not something we can guarantee long-term.  If you notice
   Python code in the LAMMPS distribution that is not compatible with
   Python 3, please contact the LAMMPS developers or submit `and issue
   on GitHub <https://github.com/lammps/lammps/issues>`_
 ---------
-LAMMPS can work together with Python in three ways.  First, Python can
+LAMMPS can work together with Python in two ways.  First, Python can
 wrap LAMMPS through the its :doc:`library interface <Library>`, so
 that a Python script can create one or more instances of LAMMPS and
 launch one or more simulations.  In Python terms, this is referred to as
@ -67,22 +63,7 @@ launch one or more simulations.  In Python terms, this is referred to as
   Launching LAMMPS via Python
-
+Second, LAMMPS can use the Python interpreter, so that a LAMMPS input
 Second, the lower-level Python interface in the :py:class:`lammps Python
 class <lammps.lammps>` can be used indirectly through the provided
 :py:class:`PyLammps <lammps.PyLammps>` and :py:class:`IPyLammps
 <lammps.IPyLammps>` wrapper classes, also written in Python.  These
 wrappers try to simplify the usage of LAMMPS in Python by providing a
 more object-based interface to common LAMMPS functionality.  They also
 reduce the amount of code necessary to parameterize LAMMPS scripts
 through Python and make variables and computes directly accessible.
 .. figure:: JPG/pylammps-invoke-lammps.png
   :figclass: align-center
   Using the PyLammps / IPyLammps wrappers
 Third, LAMMPS can use the Python interpreter, so that a LAMMPS input
 script or styles can invoke Python code directly, and pass information
 back-and-forth between the input script and Python functions you write.
 This Python code can also call back to LAMMPS to query or change its
--- a/doc/src/Python_properties.rst
+++ b/doc/src/Python_properties.rst
@ -2,14 +2,8 @@ System properties
 =================
 Similar to what is described in :doc:`Library_properties`, the instances of
-:py:class:`lammps <lammps.lammps>`, :py:class:`PyLammps <lammps.PyLammps>`, or
+:py:class:`lammps <lammps.lammps>` can be used to extract different kinds
-:py:class:`IPyLammps <lammps.IPyLammps>` can be used to extract different kinds
+of information about the active LAMMPS instance and also to modify some of it.
 of information about the active LAMMPS instance and also to modify some of it. The
 main difference between the interfaces is how the information is exposed.
 While the :py:class:`lammps <lammps.lammps>` is just a thin layer that wraps C API calls,
 :py:class:`PyLammps <lammps.PyLammps>` and :py:class:`IPyLammps <lammps.IPyLammps>` expose
 information as objects and properties.
 In some cases the data returned is a direct reference to the original data
 inside LAMMPS cast to ``ctypes`` pointers. Where possible, the wrappers will
@ -25,10 +19,6 @@ against invalid accesses.
   accordingly. These arrays can change sizes and order at every neighbor list
   rebuild and atom sort event as atoms are migrating between subdomains.
 .. tabs::
   .. tab:: lammps API
 .. code-block:: python
   from lammps import lammps
@ -64,74 +54,3 @@ against invalid accesses.
 **Properties**:
 * :py:attr:`last_thermo_step <lammps.lammps.last_thermo_step>`: the last timestep thermodynamic output was computed
   .. tab:: PyLammps/IPyLammps API
      In addition to the functions provided by :py:class:`lammps <lammps.lammps>`, :py:class:`PyLammps <lammps.PyLammps>` objects
      have several properties which allow you to query the system state:
      L.system
         Is a dictionary describing the system such as the bounding box or number of atoms
      L.system.xlo, L.system.xhi
         bounding box limits along x-axis
      L.system.ylo, L.system.yhi
         bounding box limits along y-axis
      L.system.zlo, L.system.zhi
         bounding box limits along z-axis
      L.communication
         configuration of communication subsystem, such as the number of threads or processors
      L.communication.nthreads
         number of threads used by each LAMMPS process
      L.communication.nprocs
         number of MPI processes used by LAMMPS
      L.fixes
         List of fixes in the current system
      L.computes
         List of active computes in the current system
      L.dump
         List of active dumps in the current system
      L.groups
         List of groups present in the current system
      **Retrieving the value of an arbitrary LAMMPS expressions**
      LAMMPS expressions can be immediately evaluated by using the ``eval`` method. The
      passed string parameter can be any expression containing global :doc:`thermo` values,
      variables, compute or fix data (see :doc:`Howto_output`):
      .. code-block:: python
         result = L.eval("ke") # kinetic energy
         result = L.eval("pe") # potential energy
         result = L.eval("v_t/2.0")
      **Example**
      .. code-block:: python
         from lammps import PyLammps
         L = PyLammps()
         L.file("in.sysinit")
         print(f"running simulation with {L.system.natoms} atoms")
         L.run(1000, "post no");
         for i in range(10):
            L.run(100, "pre no post no")
            pe = L.eval("pe")
            ke = L.eval("ke")
            print(f"PE = {pe}\nKE = {ke}")
--- a/doc/src/Run_formats.rst
+++ b/doc/src/Run_formats.rst
@ -0,0 +1,416 @@
 File formats used by LAMMPS
 ===========================
 This page provides a general overview of the kinds of files and file
 formats that LAMMPS is reading and writing.
 .. contents:: On this page
   :depth: 2
   :backlinks: top
 -------------------
 Character Encoding
 ^^^^^^^^^^^^^^^^^^
 For processing text files, the LAMMPS source code assumes `ASCII
 character encoding <https://en.wikipedia.org/wiki/ASCII>`_ which
 represents the digits 0 to 9, the lower and upper case letters a to z,
 some common punctuation and other symbols and a few whitespace
 characters including a regular "space character", "line feed", "carriage
 return", "tabulator".  These characters are all represented by single
 bytes with a value smaller than 128 and only 95 of those 128 values
 represent printable characters.  This list is sufficient to represent
 most English text, but misses accented characters or umlauts or Greek
 symbols and more.
 Modern text often uses `UTF-8 character encoding
 <https://en.wikipedia.org/wiki/UTF-8>`_ instead.  This encoding is a way
 to represent many more different characters as defined by the Unicode
 standard.  UFT-8 is compatible with ASCII, since the first 128 values
 are identical with the ASCII encoding.  It is important to note,
 however, that there are Unicode characters that *look* similar to ASCII
 characters, but have a different binary representation.  As a general
 rule, these characters may not be correctly recognized by LAMMPS.  For
 some parts of LAMMPS' text processing, translation tables with known
 "lookalike" characters are used.  The tables are used to substitute
 non-ASCII characters with their ASCII equivalents.  Non-ASCII lookalike
 characters are often used by web browsers or PDF viewers to improve the
 readability of text.  Thus, when using copy and paste to transfer text
 from such an application to your input file, you may unintentionally
 create text that is not exclusively using ASCII encoding and may cause
 errors when LAMMPS is trying to read it.
 Lines with non-printable and non-ASCII characters in text files can be
 detected for example with a (Linux) command like the following:
 .. code-block:: bash
   env LC_ALL=C grep -n '[^ -~]' some_file.txt
 Number Formatting
 ^^^^^^^^^^^^^^^^^
 Different countries and languages have different conventions to format
 numbers.  While in some regions commas are used for fractions and points
 to indicate thousand, million and so on, this is reversed in other
 regions.  Modern operating systems have facilities to adjust input and
 output accordingly that are collectively referred to as "native language
 support" (NLS).  The exact rules are often applied according to the
 value of the ``$LANG`` environment variable (e.g. "en_US.utf8" for
 English text in UTF-8 encoding).
 For the sake of simplicity of the implementation and transferability of
 results, LAMMPS does not support this and instead expects numbers being
 formatted in the generic or "C" locale.  The "C" locale has no
 punctuation for thousand, million and so on and uses a decimal point for
 fractions.  One thousand would be represented as "1000.0" and not as
 "1,000.0" nor as "1.000,0".  Having native language support enabled for
 a locale other than "C" will result in different behavior when
 converting or formatting numbers that can trigger unexpected errors.
 LAMMPS also only accepts integer numbers when an integer is required, so
 using floating point equivalents like "1.0" are not accepted; you *must*
 use "1" instead.
 For floating point numbers in scientific notation, the Fortran double
 precision notation "1.1d3" is not accepted; you have to use "1100",
 "1100.0" or "1.1e3".
 Input file
 ^^^^^^^^^^
 A LAMMPS input file is a text file with commands.  It is read
 line-by-line and each line is processed *immediately*.  Before looking
 for commands and executing them, there is a pre-processing step where
 comments (non-quoted text starting with a pound sign '#') are removed,
 ``${variable}`` and ``$(expression)`` constructs are expanded or
 evaluated, and lines that end in the ampersand character '&' are
 combined with the next line (similar to Fortran 90 free-format source
 code).  After the pre-processing, lines are split into "words" and
 evaluated.  The first word must be a :doc:`command <Commands_all>` and
 all following words are arguments.  Below are some example lines:
 .. code-block:: LAMMPS
   # full line comment
   # some global settings
   units           lj
   atom_style      atomic
   # ^^ command    ^^ argument(s)
   variable        x index 1       # may be overridden from command line with -var x <value>
   variable        xx equal 20*$x  # variable "xx" is always 20 times "x"
   lattice         fcc 0.8442
   # example of a command written across multiple lines
   # the "region" command uses spacing from "lattice" command, unless "units box" is specified
   region          box block 0.0 ${xx} &
                             0.0 40.0  &
                             0.0 30.0
   # create simulation box and fill with atoms according to lattice setting
   create_box      1 box
   create_atoms    1 box
   # set force field and parameters
   mass            1 1.0
   pair_style      lj/cut 2.5
   pair_coeff      1 1 1.0 1.0 2.5
   # run simulation
   fix             1 all nve
   run             1000
 The pivotal command in this example input is the :doc:`create_box
 command <create_box>`.  It defines the simulation system and many
 parameters that go with it: units, atom style, number of atom types (and
 other types) and more.  Those settings are *locked in* after the box is
 created.  Commands that change these kind of settings are only allowed
 **before** a simulation box is created and many other commands are only
 allowed **after** the simulation box is defined (e.g. :doc:`pair_coeff
 <pair_coeff>`).  Very few commands (e.g. :doc:`pair_style <pair_style>`)
 may be used in either part of the input.  The :doc:`read_data
 <read_data>` and :doc:`read_restart <read_restart>` commands also create
 the system box and thus have a similar pivotal function.
 The LAMMPS input syntax has minimal support for conditionals and loops,
 but if more complex operations are required, it is recommended to use
 the library interface, e.g. :doc:`from Python using the LAMMPS Python
 module <Python_run>`.
 There is a frequent misconception about the :doc:`if command <if>`:
 this is a command for conditional execution **outside** a run or
 minimization.  To trigger actions on specific conditions **during**
 a run is a non-trivial operation that usually requires adopting one
 of the available "fix" commands or creating a new "fix" command.
 LAMMPS commands change the internal state and thus the order of commands
 matters and reordering them can produce different results.  For example,
 the region defined by the :doc:`region command <region>` in the example
 above depends on the :doc:`lattice setting <lattice>` and thus its
 dimensions will be different depending on the order of the two commands.
 Each line must have an "end-of-line" character (line feed or carriage
 return plus line feed).  Some text editors do not automatically insert
 one which may cause LAMMPS to ignore the last command.  It is thus
 recommended to always have an empty line at the end of an input file.
 The specific details describing how LAMMPS input is processed and parsed
 are explained in :doc:`Commands_parse`.
 Data file
 ^^^^^^^^^
 A LAMMPS data file contains a description of a system suitable for
 reading with the :doc:`read_data command <read_data>`.  Data files are
 commonly used for setting up complex molecular systems that can be
 difficult to achieve with the commands :doc:`create_box <create_box>`
 and :doc:`create_atoms <create_atoms>` alone.  Also, data files can be
 used as a portable alternatives to a :doc:`binary restart file
 <restart>`.  A restart file can be converted into a data file from the
 :doc:`command line <Run_options>`.
 Data files have a header section at the very beginning of the file and
 multiple titled sections such as "Atoms", Masses", "Pair Coeffs", and so
 on.  Header keywords can only be used *before* the first title section.
 The data file **always** starts with a "title" line, which will be
 **ignored** by LAMMPS.  Omitting the title line can lead to unexpected
 behavior because a line of the header with an actual setting may be
 ignored.  In this case, the mistakenly ignored line often contains the
 "atoms" keyword, which results in LAMMPS assuming that there are no
 atoms in the data file and thus throwing an error on the contents of the
 "Atoms" section.  The title line may contain some keywords that can be
 used by external programs to convey information about the system
 (included as comments), that is not required and not read by LAMMPS.
 The line following a section title is also **ignored**.  An error will
 occur if an empty line is not placed after a section title.  The number
 of lines in titled sections depends on header keywords, like the number
 of atom types, the number of atoms, the number of bond types, the number
 of bonds, and so on.  The data in those sections has to be complete.  A
 special case are the "Pair Coeffs" and "PairIJ Coeffs" sections; the
 former is for force fields and pair styles that use mixing of non-bonded
 potential parameters, the latter for pair styles and force fields
 requiring explicit coefficients.  Thus with *N* being the number of atom
 types, the "Pair Coeffs" section has *N* entries while "PairIJ Coeffs"
 has :math:`N \cdot (N-1)` entries.  Internally, these sections will be
 converted to :doc:`pair_coeff <pair_coeff>` commands.  Thus the
 corresponding :doc:`pair style <pair_style>` must have been set *before*
 the :doc:`read_data command <read_data>` reads the data file.
 Data files may contain comments, which start with the pound sign '#'.
 There must be at least one blank between a valid keyword and the pound
 sign. Below is a simple example case of a data file for :doc:`atom style
 full <atom_style>`.
 .. code-block:: bash
   LAMMPS Title line (ignored)
   # full line comment
           10  atoms # comment
            4  atom types
    -36.840194 64.211560 xlo xhi
    -41.013691 68.385058 ylo yhi
    -29.768095 57.139462 zlo zhi
   Masses
     1 12.0110
     2 12.0110
     3 15.9990
     4  1.0080
   Pair Coeffs  # this section is optional
     1    0.110000    3.563595    0.110000    3.563595
     2    0.080000    3.670503    0.010000    3.385415
     3    0.120000    3.029056    0.120000    2.494516
     4    0.022000    2.351973    0.022000    2.351973
   Atoms # full
         1      1       1       0.560   43.99993  58.52678  36.78550   0   0   0
         2      1       2      -0.270   45.10395  58.23499  35.86693   0   0   0
         3      1       3      -0.510   43.81519  59.54928  37.43995   0   0   0
         4      1       4       0.090   45.71714  57.34797  36.13434   0   0   0
         5      1       4       0.090   45.72261  59.13657  35.67007   0   0   0
         6      1       4       0.090   44.66624  58.09539  34.85538   0   0   0
         7      1       3      -0.470   43.28193  57.47427  36.91953   0   0   0
         8      1       4       0.070   42.07157  57.45486  37.62418   0   0   0
         9      1       1       0.510   42.19985  57.57789  39.12163   0   0   0
        10      1       1       0.510   41.88641  58.62251  39.70398   0   0   0
   #  ^^atomID ^^molID ^^type  ^^charge ^^xcoord  ^^ycoord  ^^ycoord  ^^image^^flags (optional)
   Velocities # this section is optional
         1  0.0050731  -0.00398928  0.00391473
         2 -0.0175184   0.0173484  -0.00489207
         3  0.00597225 -0.00202006  0.00166454
         4 -0.010395   -0.0082582   0.00316419
         5 -0.00390877  0.00470331 -0.00226911
         6 -0.00111157 -0.00374545 -0.0169374
         7  0.00209054 -0.00594936 -0.000124563
         8  0.00635002 -0.0120093  -0.0110999
         9 -0.004955   -0.0123375   0.000403422
        10  0.00265028 -0.00189329 -0.00293198
 The common problem is processing the "Atoms" section, since its format
 depends on the :doc:`atom style <atom_style>` used, and that setting
 must be done in the input file *before* reading the data file.  To
 assist with detecting incompatible data files, a comment is appended to
 the "Atoms" title indicating the atom style used (or intended) when
 *writing* the data file.  For example, below is an "Atoms" section for
 :doc:`atom style charge <atom_style>`, which omits the molecule ID
 column.
 .. code-block:: bash
   Atoms # charge
         1      1       0.560   43.99993  58.52678  36.78550
         2      2      -0.270   45.10395  58.23499  35.86693
         3      3      -0.510   43.81519  59.54928  37.43995
         4      4       0.090   45.71714  57.34797  36.13434
         5      4       0.090   45.72261  59.13657  35.67007
         6      4       0.090   44.66624  58.09539  34.85538
         7      3      -0.470   43.28193  57.47427  36.91953
         8      4       0.070   42.07157  57.45486  37.62418
         9      1       0.510   42.19985  57.57789  39.12163
        10      1       0.510   41.88641  58.62251  39.70398
   #  ^^atomID ^^type  ^^charge ^^xcoord  ^^ycoord  ^^ycoord
 Another source of confusion about the "Atoms" section format is the
 ordering of columns.  The three atom style variants `atom_style full`,
 `atom_style hybrid charge molecular`, and `atom_style hybrid molecular
 charge` all carry the same per-atom information. However, in data files,
 the Atoms section has the columns 'Atom-ID Molecule-ID Atom-type Charge
 X Y Z' for atom style full, but for hybrid atom styles the first columns
 are always 'Atom-ID Atom-type X Y Z' followed by any *additional* data
 added by the hybrid styles, for example, 'Charge Molecule-ID' for the
 first hybrid style and 'Molecule-ID Charge' in the second hybrid style
 variant.  Finally, an alternative to a hybrid atom style is to use fix
 property/atom, e.g. to add molecule IDs to atom style charge.  In this
 case the "Atoms" section is formatted according to atom style charge and
 a new section, "Molecules" is added that contains lines with 'Atom-ID
 Molecule-ID', one for each atom in the system.  For adding charges to
 atom style molecular with fix property/atom, the "Atoms" section is now
 formatted according to the atom style and a "Charges" section is added.
 Molecule file
 ^^^^^^^^^^^^^
 Molecule files for use with the :doc:`molecule command <molecule>` look
 quite similar to data files but they do not have a compatible format,
 i.e., one cannot use a data file as molecule file and vice versa.  Below
 is a simple example for a water molecule (SPC/E model).  Same as a data
 file, there is an ignored title line and you can use comments.  However,
 there is no information about the number of types or the box dimensions.
 These parameters are set when the simulation box is created.  Thus the
 header only has the count of atoms, bonds, and so on.
 Molecule files have a header followed by sections (just as in data
 files), but the section names are different than those of a data file.
 There is no "Atoms" section and the section formats in molecule files is
 independent of the atom style.  Its information is split across multiple
 sections, like "Coords", "Types", and "Charges".  Note that no "Masses"
 section is needed here.  The atom masses are by default tied to the atom
 type and set with a data file or the :doc:`mass command <mass>`.  A
 "Masses" section would only be required for atom styles with per-atom
 masses, e.g. atom style sphere, where in data files you would provide
 the density and the diameter instead of the mass.
 Since the entire file is a 'molecule', LAMMPS will assign a new
 molecule-ID (if supported by the atom style) when atoms are instantiated
 from a molecule file, e.g. with the :doc:`create_atoms command
 <create_atoms>`.  It is possible to include a "Molecules" section to
 indicate that the atoms belong to multiple 'molecules'.  Atom-IDs and
 molecule-IDs in the molecule file are relative for the file
 (i.e. starting from 1) and will be translated into actual atom-IDs also
 when the atoms from the molecule are created.
 .. code-block:: bash
   # Water molecule. SPC/E model.
   3 atoms
   2 bonds
   1 angles
   Coords
   1    1.12456   0.09298   1.27452
   2    1.53683   0.75606   1.89928
   3    0.49482   0.56390   0.65678
   Types
   1        1
   2        2
   3        2
   Charges
   1       -0.8472
   2        0.4236
   3        0.4236
   Bonds
   1   1      1      2
   2   1      1      3
   Angles
   1   1      2      1      3
 There are also optional sections, e.g. about :doc:`SHAKE <fix_shake>`
 and :doc:`special bonds <special_bonds>`. Those sections are only needed
 if the molecule command is issued *before* the simulation box is
 defined.  Otherwise, the molecule command can derive the required
 settings internally.
 Restart file
 ^^^^^^^^^^^^
 LAMMPS restart files are binary files and not available in text format.
 They can be identified by the first few bytes that contain the (C-style)
 string ``LammpS RestartT`` as `magic string
 <https://en.wikipedia.org/wiki/Magic_string>`_.  This string is followed
 by a 16-bit integer of the number 1 used for detecting whether the
 computer writing the restart has the same `endianness
 <https://en.wikipedia.org/wiki/Endianness>`_ as the computer reading it.
 If not, the file cannot be read correctly.  This integer is followed by
 a 32-bit integer indicating the file format revision (currently 3),
 which can be used to implement backward compatibility for reading older
 revisions.
 This information has been added to the `Unix "file" command's
 <https://www.darwinsys.com/file/>` "magic" file so that restart files
 can be identified without opening them.  If you have a fairly recent
 version, it should already be included.  If you have an older version,
 the LAMMPS source package :ref:`contains a file with the necessary
 additions <magic>`.
 The rest of the file is organized in sections of a 32-bit signed integer
 constant indicating the kind of content and the corresponding value (or
 values).  If those values are arrays (including C-style strings), then
 the integer constant is followed by a 32-bit integer indicating the
 length of the array.  This mechanism will read the data regardless of
 the ordering of the sections.  Symbolic names of the section constants
 are in the ``lmprestart.h`` header file.
 LAMMPS restart files are not expected to be portable between platforms
 or LAMMPS versions, but changes to the file format are rare.
 .. Native Dump file
 .. ^^^^^^^^^^^^^^^^
 ..
 .. Potential files
 .. ^^^^^^^^^^^^^^^
--- a/doc/src/Run_head.rst
+++ b/doc/src/Run_head.rst
@ -1,10 +1,11 @@
 Run LAMMPS
 **********
-These pages explain how to run LAMMPS once you have :doc:`installed an executable <Install>` or :doc:`downloaded the source code <Install>`
+These pages explain how to run LAMMPS once you have :doc:`installed an
-and :doc:`built an executable <Build>`.  The :doc:`Commands <Commands>`
+executable <Install>` or :doc:`downloaded the source code <Install>` and
-doc page describes how input scripts are structured and the commands
+:doc:`built an executable <Build>`.  The :doc:`Commands <Commands>` doc
-they can contain.
+page describes how input scripts are structured and the commands they
 can contain.
 .. toctree::
   :maxdepth: 1
@ -12,4 +13,5 @@ they can contain.
   Run_basics
   Run_options
   Run_output
   Run_formats
   Run_windows
--- a/doc/src/Run_output.rst
+++ b/doc/src/Run_output.rst
@ -117,14 +117,19 @@ number of histogram counts is equal to the number of processors.
 ----------
-The last section gives aggregate statistics (across all processors)
+The last section gives aggregate statistics (across all processors) for
-for pairwise neighbors and special neighbors that LAMMPS keeps track
+pairwise neighbors and special neighbors that LAMMPS keeps track of (see
-of (see the :doc:`special_bonds <special_bonds>` command).  The number
+the :doc:`special_bonds <special_bonds>` command).  This section will
-of times neighbor lists were rebuilt is tallied, as is the number of
+not always contain data, for example when there has not been a neighbor
-potentially *dangerous* rebuilds.  If atom movement triggered neighbor
+rebuild, or the neighbor list was constructed on the GPU or when a
-list rebuilding (see the :doc:`neigh_modify <neigh_modify>` command),
+hybrid pair style was used and LAMMPS cannot determine a suitable (base)
-then dangerous reneighborings are those that were triggered on the
+neighbor list to draw the statistics from.
-first timestep atom movement was checked for.  If this count is
+
 The number of times neighbor lists were rebuilt is tallied, as is the
 number of potentially *dangerous* rebuilds.  If atom movement triggered
 neighbor list rebuilding (see the :doc:`neigh_modify <neigh_modify>`
 command), then dangerous reneighborings are those that were triggered on
 the first timestep atom movement was checked for.  If this count is
 non-zero you may wish to reduce the delay factor to ensure no force
 interactions are missed by atoms moving beyond the neighbor skin
 distance before a rebuild takes place.
@ -178,3 +183,64 @@ with and without the communication and a Gflop rate is computed.  The
 3d rate is with communication; the 1d rate is without (just the 1d
 FFTs).  Thus you can estimate what fraction of your FFT time was spent
 in communication, roughly 75% in the example above.
 Error message output
 ====================
 Depending on the error function arguments when it is called in the
 source code, there will be one to four lines of error output.
 A single line
 ^^^^^^^^^^^^^
 The line starts with "ERROR: ", followed by the error message and
 information about the location in the source where the error function
 was called in parenthesis on the right (here: line 131 of the file
 src/fix_print.cpp). Example:
 .. parsed-literal::
   ERROR: Fix print timestep variable nevery returned a bad timestep: 9900 (src/fix_print.cpp:131)
 Two lines
 ^^^^^^^^^
 In addition to the single line output, also the last line of the input
 will be repeated.  If a command is spread over multiple lines in the
 input using the continuation character '&', then the error will print
 the entire concatenated line.  For readability all whitespace is
 compressed to single blanks.  Example:
 .. parsed-literal::
   ERROR: Unrecognized fix style 'printf' (src/modify.cpp:924)
   Last input line: fix 0 all printf v_nevery "Step: $(step) ${step}"
 Three lines
 ^^^^^^^^^^^
 In addition to the two line output from above, a third line is added
 that uses caret character markers '^' to indicate which "word" in the
 input failed.  Example:
 .. parsed-literal::
   ERROR: Illegal fix print nevery value -100; must be > 0 (src/fix_print.cpp:41)
   Last input line: fix 0 all print -100 "Step: $(step) ${stepx}"
                                    ^^^^
 Four lines
 ^^^^^^^^^^
 The three line output is expanded to four lines, if the the input is
 modified through input pre-processing, e.g. when substituting
 variables. Now the last command is printed once in the original form and
 a second time after substitutions are applied.  The caret character
 markers '^' are applied to the second version.  Example:
 .. parsed-literal::
   ERROR: Illegal fix print nevery value -100; must be > 0 (src/fix_print.cpp:41)
   Last input line: fix 0 all print ${nevery} 'Step: $(step) ${step}'
   --> parsed line: fix 0 all print -100 "Step: $(step) ${step}"
                                    ^^^^
--- a/doc/src/Speed_compare.rst
+++ b/doc/src/Speed_compare.rst
@ -44,11 +44,6 @@ section below for examples where this has been done.
  system the crossover (in single precision) is often about 50K-100K
  atoms per GPU.  When performing double precision calculations the
  crossover point can be significantly smaller.
 * Both KOKKOS and GPU package compute bonded interactions (bonds, angles,
  etc) on the CPU.  If the GPU package is running with several MPI processes
  assigned to one GPU, the cost of computing the bonded interactions is
  spread across more CPUs and hence the GPU package can run faster in these
  cases.
 * When using LAMMPS with multiple MPI ranks assigned to the same GPU, its
  performance depends to some extent on the available bandwidth between
  the CPUs and the GPU. This can differ significantly based on the
@ -85,10 +80,10 @@ section below for examples where this has been done.
  code (with a performance penalty due to having data transfers between
  host and GPU).
 * The GPU package requires neighbor lists to be built on the CPU when using
-  exclusion lists, or a triclinic simulation box.
+  hybrid pair styles, exclusion lists, or a triclinic simulation box.
-* The GPU package can be compiled for CUDA or OpenCL and thus supports
+* The GPU package can be compiled for CUDA, HIP, or OpenCL and thus supports
-  both, NVIDIA and AMD GPUs well. On NVIDIA hardware, using CUDA is typically
+  NVIDIA, AMD, and Intel GPUs well. On NVIDIA hardware, using CUDA is
-  resulting in equal or better performance over OpenCL.
+  typically resulting in equal or better performance over OpenCL.
 * OpenCL in the GPU package does theoretically also support Intel CPUs or
  Intel Xeon Phi, but the native support for those in KOKKOS (or INTEL)
  is superior.
--- a/doc/src/Speed_kokkos.rst
+++ b/doc/src/Speed_kokkos.rst
@ -67,6 +67,14 @@ version 23 November 2023 and Kokkos version 4.2.
   To build with Kokkos support for AMD GPUs, the AMD ROCm toolkit
   software version 5.2.0 or later must be installed on your system.
 .. admonition:: Intel Data Center GPU support
   :class: note
   Support for Kokkos with Intel Data Center GPU accelerators (formerly
   known under the code name "Ponte Vecchio") in LAMMPS is still a work
   in progress.  Only a subset of the functionality works correctly.
   Please contact the LAMMPS developers if you run into problems.
 .. admonition:: CUDA and MPI library compatibility
   :class: note
@ -80,13 +88,15 @@ version 23 November 2023 and Kokkos version 4.2.
   LAMMPS command-line or by using the command :doc:`package kokkos
   gpu/aware off <package>` in the input file.
-.. admonition:: Intel Data Center GPU support
+.. admonition:: Using multiple MPI ranks per GPU
   :class: note
-   Support for Kokkos with Intel Data Center GPU accelerators (formerly
+   Unlike with the GPU package, there are limited benefits from using
-   known under the code name "Ponte Vecchio") in LAMMPS is still a work
+   multiple MPI processes per GPU with KOKKOS.  But when doing this it
-   in progress.  Only a subset of the functionality works correctly.
+   is **required** to enable CUDA MPS (`Multi-Process Service :: GPU
-   Please contact the LAMMPS developers if you run into problems.
+   Deployment and Management Documentation
   <https://docs.nvidia.com/deploy/mps/index.html>`_ ) to get acceptable
   performance.
 Building LAMMPS with the KOKKOS package
 """""""""""""""""""""""""""""""""""""""
@ -365,13 +375,13 @@ one or more nodes, each with two GPUs:
 .. note::
-   When using a GPU, you will achieve the best performance if your
+   When using a GPU, you will achieve the best performance if your input
-   input script does not use fix or compute styles which are not yet
+   script does not use fix or compute styles which are not yet
   Kokkos-enabled. This allows data to stay on the GPU for multiple
   timesteps, without being copied back to the host CPU. Invoking a
-   non-Kokkos fix or compute, or performing I/O for
+   non-Kokkos fix or compute, or performing I/O for :doc:`thermo
-   :doc:`thermo <thermo_style>` or :doc:`dump <dump>` output will cause data
+   <thermo_style>` or :doc:`dump <dump>` output will cause data to be
-   to be copied back to the CPU incurring a performance penalty.
+   copied back to the CPU incurring a performance penalty.
 .. note::
@ -379,6 +389,56 @@ one or more nodes, each with two GPUs:
   kspace, etc., you must set the environment variable ``CUDA_LAUNCH_BLOCKING=1``.
   However, this will reduce performance and is not recommended for production runs.
 Troubleshooting segmentation faults on GPUs
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 As noted above, KOKKOS by default assumes that the MPI library is
 GPU-aware.  This is not always the case and can lead to segmentation
 faults when using more than one MPI process.  Normally, LAMMPS will
 print a warning like "*Turning off GPU-aware MPI since it is not
 detected*", or an error message like "*Kokkos with GPU-enabled backend
 assumes GPU-aware MPI is available*", OR a **segmentation fault**.  To
 confirm that a segmentation fault is caused by this, you can turn off
 the GPU-aware assumption via the :doc:`package kokkos command <package>`
 or the corresponding command-line flag.
 If you still get a segmentation fault, despite running with only one MPI
 process or using the command-line flag to turn off expecting a GPU-aware
 MPI library, then using the CMake compile setting
 ``-DKokkos_ENABLE_DEBUG=on`` or adding ``KOKKOS_DEBUG=yes`` to your
 machine makefile for building with traditional make will generate useful
 output that can be passed to the LAMMPS developers for further
 debugging.
 Troubleshooting memory allocation on GPUs
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 `Kokkos Tools <https://github.com/kokkos/kokkos-tools/>`_ provides a set
 of lightweight profiling and debugging utilities, which interface with
 instrumentation hooks (eg. `space-time-stack
 <https://github.com/kokkos/kokkos-tools/tree/develop/profiling/space-time-stack>`_)
 built directly into the Kokkos runtime.  After compiling a dynamic LAMMPS
 library, you then have to set the environment variable ``KOKKOS_TOOLS_LIBS``
 before executing your LAMMPS Kokkos run. Example:
 .. code-block:: bash
    export KOKKOS_TOOLS_LIBS=${HOME}/kokkos-tools/src/tools/memory-events/kp_memory_event.so
    mpirun -np 4 lmp_kokkos_cuda_openmpi -in in.lj -k on g 4 -sf kk
 Starting with the NVIDIA Pascal GPU architecture, CUDA supports
 `"Unified Virtual Memory" (UVM)
 <https://developer.nvidia.com/blog/unified-memory-cuda-beginners/>`_
 which enables allocating more memory than a GPU possesses by also using
 memory on the host CPU and then CUDA will transparently move data
 between CPU and GPU as needed.  The resulting LAMMPS performance depends
 on `memory access pattern, data residency, and GPU memory
 oversubscription
 <https://developer.nvidia.com/blog/improving-gpu-memory-oversubscription-performance/>`_
 . The CMake option ``-DKokkos_ENABLE_CUDA_UVM=on`` or the makefile
 setting ``KOKKOS_CUDA_OPTIONS=enable_lambda,force_uvm`` enables using
 :ref:`UVM with Kokkos <kokkos>` when compiling LAMMPS.
 Run with the KOKKOS package by editing an input script
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--- a/doc/src/Tools.rst
+++ b/doc/src/Tools.rst
@ -930,7 +930,7 @@ dependencies and redirects the download to the local cache.
   mkdir build
   cd build
-   cmake -D LAMMPS_DOWNLOADS_URL=${HTTP_CACHE_URL} -C "${LAMMPS_HTTP_CACHE_CONFIG}" -C ../cmake/presets/most.cmake ../cmake
+   cmake -D LAMMPS_DOWNLOADS_URL=${HTTP_CACHE_URL} -C "${LAMMPS_HTTP_CACHE_CONFIG}" -C ../cmake/presets/most.cmake -D DOWNLOAD_POTENTIALS=off ../cmake
   make -j 8
   deactivate_caches
--- a/doc/src/angle_mwlc.rst
+++ b/doc/src/angle_mwlc.rst
@ -0,0 +1,94 @@
 .. index:: angle_style mwlc
 angle_style mwlc command
 ==========================
 Syntax
 """"""
 .. code-block:: LAMMPS
   angle_style mwlc
 Examples
 """"""""
 .. code-block:: LAMMPS
   angle_style mwlc
   angle_coeff * 25 1 10 1
 Description
 """""""""""
 .. versionadded:: 4Feb2025
 The *mwlc* angle style models a meltable wormlike chain and can be used
 to model non-linear bending elasticity of polymers, e.g. DNA.  *mwlc*
 uses a potential that is a canonical-ensemble superposition of a
 non-melted and a melted state :ref:`(Farrell) <Farrell>`.  The potential
 is
 .. math::
    E = -k_{B}T\,\log [q + q^{m}] + E_{0},
 where the non-melted and melted partition functions are
 .. math::
    q = \exp [-k_{1}(1+\cos{\theta})/k_{B}T]; \\
    q^{m} = \exp [-(\mu+k_{2}(1+\cos{\theta}))/k_{B}T].
 :math:`k_1` is the bending elastic constant of the non-melted state,
 :math:`k_2` is the bending elastic constant of the melted state,
 :math:`\mu` is the melting energy, and
 :math:`T` is the reference temperature.
 The reference energy,
 .. math::
    E_{0} = -k_{B}T\,\log [1 + \exp[-\mu/k_{B}T]],
 ensures that E is zero for a fully extended chain.
 This potential is a continuous version of the two-state potential
 introduced by :ref:`(Yan) <Yan>`.
 The following coefficients must be defined for each angle type via the
 :doc:`angle_coeff <angle_coeff>` command as in the example above, or in
 the data file or restart files read by the :doc:`read_data <read_data>`
 or :doc:`read_restart <read_restart>` commands:
 * :math:`k_1` (energy)
 * :math:`k_2` (energy)
 * :math:`\mu` (energy)
 * :math:`T` (temperature)
 ----------
 Restrictions
 """"""""""""
 This angle style can only be used if LAMMPS was built with the
 EXTRA-MOLECULE package.  See the :doc:`Build package <Build_package>`
 doc page for more info.
 Related commands
 """"""""""""""""
 :doc:`angle_coeff <angle_coeff>`
 Default
 """""""
 none
 ----------
 .. _Farrell:
 **(Farrell)** `Farrell, Dobnikar, Podgornik, Curk, Phys Rev Lett, 133, 148101 (2024). <https://doi.org/10.1103/PhysRevLett.133.148101>`_
 .. _Yan:
 **(Yan)** `Yan, Marko, Phys Rev Lett, 93, 108108 (2004). <https://doi.org/10.1103/PhysRevLett.93.108108>`_
--- a/doc/src/angle_style.rst
+++ b/doc/src/angle_style.rst
@ -94,6 +94,7 @@ of (g,i,k,o,t) to indicate which accelerated styles exist.
 * :doc:`lepton <angle_lepton>` - angle potential from evaluating a string
 * :doc:`mesocnt <angle_mesocnt>` - piecewise harmonic and linear angle for bending-buckling of nanotubes
 * :doc:`mm3 <angle_mm3>` - anharmonic angle
 * :doc:`mwlc <angle_mwlc>` - meltable wormlike chain
 * :doc:`quartic <angle_quartic>` - angle with cubic and quartic terms
 * :doc:`spica <angle_spica>` - harmonic angle with repulsive SPICA pair style between 1-3 atoms
 * :doc:`table <angle_table>` - tabulated by angle
--- a/doc/src/bond_bpm_spring.rst
+++ b/doc/src/bond_bpm_spring.rst
@ -10,7 +10,7 @@ Syntax
   bond_style bpm/spring keyword value attribute1 attribute2 ...
-* optional keyword = *overlay/pair* or *store/local* or *smooth* or *break* or *volume/factor*
+* optional keyword = *overlay/pair* or *store/local* or *smooth* or *normalize* or *break* or *volume/factor*
  .. parsed-literal::
@ -123,7 +123,7 @@ heuristic maximum strain used by typical non-bpm bond styles. Similar behavior
 to *break no* can also be attained by setting an arbitrarily high value of
 :math:`\epsilon_c`. One cannot use *break no* with *smooth yes*.
-.. versionadded:: TBD
+.. versionadded:: 4Feb2025
 The *volume/factor* keyword toggles whether an additional multibody
 contribution is added to he force using the formulation in
@ -141,7 +141,8 @@ calculated using bond lengths squared and the cube root in the above equation
 is accordingly replaced with a square root. This approximation assumes bonds
 are evenly distributed on a spherical surface and neglects constant prefactors
 which are irrelevant since only the ratio of volumes matters. This term may be
-used to adjust the Poisson's ratio.
+used to adjust the Poisson's ratio. See the simulation in the
 ``examples/bpm/poissons_ratio`` directory for a demonstration of this effect.
 If a bond is broken (or created), :math:`V_{0,i}` is updated by subtracting
 (or adding) that bond's contribution.
@ -214,11 +215,11 @@ for an overview of LAMMPS output options.
 The vector or array will be floating point values that correspond to
 the specified attribute.
-The single() function of this bond style returns 0.0 for the energy
+The potential energy and the single() function of this bond style return
-of a bonded interaction, since energy is not conserved in these
+:math:`k (r - r_0)^2 / 2` as a proxy of the energy of a bonded interaction,
-dissipative potentials.  The single() function also calculates an
+ignoring any volumetric/smoothing factors or dissipative forces.  The single()
-extra bond quantity, the initial distance :math:`r_0`. This
+function also calculates an extra bond quantity, the initial distance
-extra quantity can be accessed by the
+:math:`r_0`. This extra quantity can be accessed by the
 :doc:`compute bond/local <compute_bond_local>` command as *b1*\ .
 Restrictions
--- a/doc/src/bond_bpm_spring_plastic.rst
+++ b/doc/src/bond_bpm_spring_plastic.rst
@ -0,0 +1,184 @@
 .. index:: bond_style bpm/spring/plastic
 bond_style bpm/spring/plastic command
 =====================================
 Syntax
 """"""
 .. code-block:: LAMMPS
   bond_style bpm/spring/plastic keyword value attribute1 attribute2 ...
 * optional keyword = *overlay/pair* or *store/local* or *smooth* or *normalize* or *break*
  .. parsed-literal::
       *store/local* values = fix_ID N attributes ...
          * fix_ID = ID of associated internal fix to store data
          * N = prepare data for output every this many timesteps
          * attributes = zero or more of the below attributes may be appended
            *id1, id2* = IDs of two atoms in the bond
            *time* = the timestep the bond broke
            *x, y, z* = the center of mass position of the two atoms when the bond broke (distance units)
            *x/ref, y/ref, z/ref* = the initial center of mass position of the two atoms (distance units)
       *overlay/pair* value = *yes* or *no*
          bonded particles will still interact with pair forces
       *smooth* value = *yes* or *no*
          smooths bond forces near the breaking point
       *normalize* value = *yes* or *no*
          normalizes bond forces by the reference length
       *break* value = *yes* or *no*
          indicates whether bonds break during a run
 Examples
 """"""""
 .. code-block:: LAMMPS
   bond_style bpm/spring/plastic
   bond_coeff 1 1.0 0.05 0.1 0.02
   bond_style bpm/spring/plastic myfix 1000 time id1 id2
   dump 1 all local 1000 dump.broken f_myfix[1] f_myfix[2] f_myfix[3]
   dump_modify 1 write_header no
 Description
 """""""""""
 .. versionadded:: TBD
 The *bpm/spring/plastic* bond style computes forces based on
 deviations from the initial reference state of the two atoms and the
 strain history.  The reference length of the bond :math:`r_0` is stored
 by each bond when it is first computed in the setup of a run. Initially,
 the equilibrium length of each bond :math:`r_\mathrm{eq}` is set equal
 to :math:`r_0` but can evolve. data is then preserved across run commands
 and is written to :doc:`binary restart files <restart>` such that restarting
 the system will not modify either of these quantities.
 This bond style only applies central-body forces which conserve the
 translational and rotational degrees of freedom of a bonded set of
 particles. The force has a magnitude of
 .. math::
   F = -k (r_\mathrm{eq} - r) w
 where :math:`k` is a stiffness, :math:`r` is the current distance between
 the two particles, and :math:`w` is an optional smoothing factor discussed
 below. If the bond stretches beyond a strain of :math:`\epsilon_p` in compression
 or extension, it will plastically activate and :math:`r_\mathrm{eq}` will evolve
 to ensure :math:`|(r-r_\mathrm{eq})/r_\mathrm{eq}|` never exceeds :math:`\epsilon_p`.
 Therefore, if a bond is continually loaded in either tension or compression, the
 force will initially grow elastically before plateauing. See
 :ref:`(Clemmer) <plastic-Clemmer>` for more details on these mechanics.
 Bonds will break at a strain of :math:`\epsilon_c`.  This is done by setting
 the bond type to 0 such that forces are no longer computed.
 An additional damping force is applied to the bonded
 particles.  This forces is proportional to the difference in the
 normal velocity of particles:
 .. math::
   F_D = - \gamma w (\hat{r} \bullet \vec{v})
 where :math:`\gamma` is the damping strength, :math:`\hat{r}` is the
 radial normal vector, and :math:`\vec{v}` is the velocity difference
 between the two particles.
 The smoothing factor :math:`w`  is constructed such that forces smoothly
 go to zero, avoiding discontinuities, as bonds approach the critical
 breaking strain
 .. math::
   w = 1.0 - \left( \frac{r - r_0}{r_0 \epsilon_c} \right)^8 .
 The following coefficients must be defined for each bond type via the
 :doc:`bond_coeff <bond_coeff>` command as in the example above, or in
 the data file or restart files read by the :doc:`read_data
 <read_data>` or :doc:`read_restart <read_restart>` commands:
 * :math:`k`             (force/distance units)
 * :math:`\epsilon_c`    (unitless)
 * :math:`\gamma`        (force/velocity units)
 * :math:`\epsilon_p`    (unitless)
 See the :doc:`bpm/spring doc page <bond_bpm_spring>` for information on
 the *smooth*, *normalize*, *break*, *overlay/pair*, and *store/local*
 keywords.
 Note that when unbroken bonds are dumped to a file via the
 :doc:`dump local <dump>` command, bonds with type 0 (broken bonds)
 are not included.
 The :doc:`delete_bonds <delete_bonds>` command can also be used to
 query the status of broken bonds or permanently delete them, e.g.:
 .. code-block:: LAMMPS
   delete_bonds all stats
   delete_bonds all bond 0 remove
 ----------
 Restart and other info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 This bond style writes the reference state and plastic history of each
 bond to :doc:`binary restart files <restart>`. Loading a restart file
 will properly restore bonds. However, the reference state is NOT written
 to data files.  Therefore reading a data file will not restore bonds and
 will cause their reference states to be redefined.
 The potential energy and the single() function of this bond style
 returns zero.  The single() function also calculates two extra bond
 quantities, the initial distance :math:`r_0` and the current equilibrium
 length :math:`r_eq`. These extra quantities can be accessed by the
 :doc:`compute bond/local <compute_bond_local>` command as *b1* and *b2*,
 respectively.
 Restrictions
 """"""""""""
 This bond style is part of the BPM package.  It is only enabled if
 LAMMPS was built with that package.  See the :doc:`Build package
 <Build_package>` page for more info.
 By default if pair interactions between bonded atoms are to be disabled,
 this bond style requires setting
 .. code-block:: LAMMPS
   special_bonds lj 0 1 1 coul 1 1 1
 and :doc:`newton <newton>` must be set to bond off.  If the *overlay/pair*
 keyword is set to *yes*, this bond style alternatively requires setting
 .. code-block:: LAMMPS
   special_bonds lj/coul 1 1 1
 Related commands
 """"""""""""""""
 :doc:`bond_coeff <bond_coeff>`, :doc:`bond bpm/spring <bond_bpm_spring>`
 Default
 """""""
 The option defaults are *overlay/pair* = *no*, *smooth* = *yes*, *normalize* = *no*, and *break* = *yes*
 ----------
 .. _plastic-Clemmer:
 **(Clemmer)** Clemmer and Lechman, Powder Technology (2025).
--- a/doc/src/bond_harmonic.rst
+++ b/doc/src/bond_harmonic.rst
@ -60,6 +60,8 @@ Related commands
 """"""""""""""""
 :doc:`bond_coeff <bond_coeff>`, :doc:`delete_bonds <delete_bonds>`
 :doc:`bond style harmonic/shift <bond_harmonic_shift>`,
 :doc:`bond style harmonic/shift/cut <bond_harmonic_shift_cut>`
 Default
 """""""
--- a/doc/src/bond_harmonic_shift.rst
+++ b/doc/src/bond_harmonic_shift.rst
@ -31,9 +31,15 @@ the potential
   E = \frac{U_{\text{min}}}{(r_0-r_c)^2} \left[ (r-r_0)^2-(r_c-r_0)^2 \right]
-where :math:`r_0` is the equilibrium bond distance, and :math:`r_c` the critical distance.
+where :math:`r_0` is the equilibrium bond distance, and :math:`r_c` the
-The potential is :math:`-U_{\text{min}}` at :math:`r0` and zero at :math:`r_c`. The spring constant is
+critical distance.  The potential energy has the value
-:math:`k = U_{\text{min}} / [ 2 (r_0-r_c)^2]`.
+:math:`-U_{\text{min}}` at :math:`r_0` and zero at :math:`r_c`.  This
 bond style differs from :doc:`bond_style harmonic <bond_harmonic>`
 by the value of the potential energy.
 The equivalent spring constant value *K* for use with :doc:`bond_style
 harmonic <bond_harmonic>` can be computed using :math:`K =
 U_{\text{min}} / [(r_0-r_c)^2]`.
 The following coefficients must be defined for each bond type via the
 :doc:`bond_coeff <bond_coeff>` command as in the example above, or in
@ -41,9 +47,7 @@ the data file or restart files read by the :doc:`read_data <read_data>`
 or :doc:`read_restart <read_restart>` commands:
 * :math:`U_{\text{min}}` (energy)
 * :math:`r_0` (distance)
 * :math:`r_c` (distance)
 ----------
@ -63,7 +67,8 @@ Related commands
 """"""""""""""""
 :doc:`bond_coeff <bond_coeff>`, :doc:`delete_bonds <delete_bonds>`,
-:doc:`bond_harmonic <bond_harmonic>`
+:doc:`bond style harmonic <bond_harmonic>`,
 :doc:`bond style harmonic/shift/cut <bond_harmonic_shift_cut>`
 Default
 """""""
--- a/doc/src/bond_harmonic_shift_cut.rst
+++ b/doc/src/bond_harmonic_shift_cut.rst
@ -31,9 +31,14 @@ uses the potential
   E = \frac{U_{\text{min}}}{(r_0-r_c)^2} \left[ (r-r_0)^2-(r_c-r_0)^2 \right]
-where :math:`r_0` is the equilibrium bond distance, and rc the critical distance.
+where :math:`r_0` is the equilibrium bond distance, and :math:`r_c` the
-The bond potential is zero for distances :math:`r > r_c`. The potential is :math:`-U_{\text{min}}`
+critical distance.  The bond potential is zero and thus its force also
-at :math:`r_0` and zero at :math:`r_c`. The spring constant is :math:`k = U_{\text{min}} / [ 2 (r_0-r_c)^2]`.
+zero for distances :math:`r > r_c`.  The potential energy has the value
 :math:`-U_{\text{min}}` at :math:`r_0` and zero at :math:`r_c`.
 The equivalent spring constant value *K* for use with :doc:`bond_style
 harmonic <bond_harmonic>` for :math:`r <= r_c`, can be computed using
 :math:`K = U_{\text{min}} / [(r_0-r_c)^2]`
 The following coefficients must be defined for each bond type via the
 :doc:`bond_coeff <bond_coeff>` command as in the example above, or in
--- a/doc/src/bond_style.rst
+++ b/doc/src/bond_style.rst
@ -10,7 +10,7 @@ Syntax
   bond_style style args
-* style = *none* or *zero* or *hybrid* or *bpm/rotational* or *bpm/spring* or *class2* or *fene* or *fene/expand* or *fene/nm* or *gaussian* or *gromos* or *harmonic* or *harmonic/restrain* *harmonic/shift* or *harmonic/shift/cut* or *lepton* or *morse* or *nonlinear* or *oxdna/fene* or *oxdena2/fene* or *oxrna2/fene* or *quartic* or *special* or *table*
+* style = *none* or *zero* or *hybrid* or *bpm/rotational* or *bpm/spring* or *bpm/spring/plastic* or *class2* or *fene* or *fene/expand* or *fene/nm* or *gaussian* or *gromos* or *harmonic* or *harmonic/restrain* *harmonic/shift* or *harmonic/shift/cut* or *lepton* or *morse* or *nonlinear* or *oxdna/fene* or *oxdena2/fene* or *oxrna2/fene* or *quartic* or *special* or *table*
 * args = none for any style except *hybrid*
@ -86,6 +86,7 @@ accelerated styles exist.
 * :doc:`bpm/rotational <bond_bpm_rotational>` - breakable bond with forces and torques based on deviation from reference state
 * :doc:`bpm/spring <bond_bpm_spring>` - breakable bond with forces based on deviation from reference length
 * :doc:`bpm/spring/plastic <bond_bpm_spring_plastic>` - a similar breakable bond with plastic yield
 * :doc:`class2 <bond_class2>` - COMPASS (class 2) bond
 * :doc:`fene <bond_fene>` - FENE (finite-extensible non-linear elastic) bond
 * :doc:`fene/expand <bond_fene_expand>` - FENE bonds with variable size particles
--- a/Show More
+++ b/Show More