Compilation errors

.github/CODEOWNERS

@@ -71,10 +71,7 @@ src/EXTRA-COMMAND/group_ndx.*       @akohlmey
 src/EXTRA-COMMAND/ndx_group.*       @akohlmey
 src/EXTRA-COMPUTE/compute_stress_mop*.* @RomainVermorel
 src/EXTRA-COMPUTE/compute_born_matrix.* @Bibobu @athomps
-src/EXTRA-DUMP/dump_extxyz.*          @fxcoudert
 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

.github/release_steps.md

@@ -1,54 +1,42 @@
 # LAMMPS Release Steps
 
-The following notes chronicle the current steps for preparing and
-publishing LAMMPS releases.  For definitions of LAMMPS versions and
-releases, please refer to [the corresponding section in the LAMMPS
-manual](https://docs.lammps.org/Manual_version.html).
+The following notes chronicle the current steps for preparing and publishing LAMMPS releases.  For
+definitions of LAMMPS versions and releases mean, please refer to [the corresponding section in the
+LAMMPS manual](https://docs.lammps.org/Manual_version.html).
 
 ## LAMMPS Feature Release
 
-A LAMMPS feature release is currently prepared after about 500 to 750
-commits to the 'develop' branch or after a period of four weeks up to
-two months.  This is not a fixed rule, though, since external
-circumstances can cause delays in preparing a release, or pull requests
-that are desired to be merged for the release are not yet completed.
+A LAMMPS feature release is currently prepared after about 500 to 750 commits to the 'develop'
+branch or after a period of four weeks up to two months.  This is not a fixed rule, though, since
+external circumstances can cause delays in preparing a release, or pull requests that are desired to
+be merged for the release are not yet completed.
 
 ### Preparing a 'next\_release' branch
 
 Create a 'next\_release' branch off 'develop' and make the following changes:
 
-- set the LAMMPS\_VERSION define to the planned release date in
-  src/version.h in the format "D Mmm YYYY" or "DD Mmm YYYY"
+- set the LAMMPS\_VERSION define to the planned release date in src/version.h in the format
+  "D Mmm YYYY" or "DD Mmm YYYY"
 - remove the LAMMPS\_UPDATE define in src/version.h
 - update the release date in doc/lammps.1
-- update all TBD arguments for ..versionadded::, ..versionchanged::
-  ..deprecated:: to the planned release date in the format "DMmmYYYY" or
-  "DDMmmYYYY"
-- check release notes for merged new features and check if
-  ..versionadded:: or ..versionchanged:: are missing and need to be
-  added
+- update all TBD arguments for ..versionadded::, ..versionchanged:: ..deprecated:: to the
+  planned release date in the format "DMmmYYYY" or "DDMmmYYYY"
+- check release notes for merged new features and check if ..versionadded:: or ..versionchanged::
+  are missing and need to be added
+Submit this pull request, rebase if needed.  This is the last pull request merged for the release
+and should not contain any other changes. (Exceptions: this document, last minute trivial(!) changes).
 
-Submit this pull request.  This is the last pull request merged for the
-release and should not contain any other changes. (Exceptions: this
-document, last minute trivial(!) changes).
-
-This PR shall not be merged before **all** pending tests have completed
-and cleared.  We currently use a mix of automated tests running on
-either Temple's Jenkins cluster or GitHub workflows.  Those include time
-consuming tests not run on pull requests.  If needed, a bug-fix pull
-request should be created and merged to clear all tests.
+This PR shall not be merged before **all** pending tests have completed and cleared. If needed, a
+bugfix pull request should be created and merged to clear all tests.
 
 ### Create release on GitHub
 
-When all pending pull requests for the release are merged and have
-cleared testing, the 'next\_release' branch is merged into 'develop'.
+When all pending pull requests for the release are merged and have cleared testing, the
+'next\_release' branch is merged into 'develop'.
 
-Check out or update the 'develop' branch locally, pull the latest
-changes, merge them into 'release' with a fast forward(!) merge, and
-apply a suitable release tag (for historical reasons the tag starts with
-"patch_" followed by the date, and finally push everything back to
-GitHub.  There should be no commits made to 'release' but only
-fast forward merges.  Example:
+Check out 'develop' locally, pull the latest changes, merge them into 'release', apply a suitable
+release tag (for historical reasons the tag starts with "patch_" followed by the date, and finally
+push everything back to GitHub. Example:
 
 ```
 git checkout develop
@@ -56,315 +44,65 @@ git pull
 git checkout release
 git pull
 git merge --ff-only develop
-git tag -s -m "LAMMPS feature release 4 February 2025" patch_4Feb2025
+git tag -s -m "LAMMPS feature release 19 November 2024" patch_19Nov2024
 git push git@github.com:lammps/lammps.git --tags develop release
 ```
 
-Applying this tag will trigger two actions on the Temple Jenkins cluster:
-- The online manual at https://docs.lammps.org/ will be updated to the
-  state of the 'release' branch.  Merges to the 'develop' branch will
-  trigger updating https://docs.lammps.org/latest/ so by reviewing the
-  version of the manual under the "latest" URL, it is possible to preview
-  what the updated release documentation will look like.
-- A downloadable tar archive of the LAMMPS distribution that includes the
-  html format documentation and a PDF of the manual will be created and
-  uploaded to the download server at https://download.lammps.org/tars
-  Note that the file is added, but the `index.html` file is not updated,
-  so it is not yet publicly visible.
-
-Go to https://github.com/lammps/lammps/releases and create a new (draft)
-release page with a summary of all the changes included and references
-to the pull requests they were merged from or check the existing draft
-for any necessary changes from pull requests that were merged but are
-not listed.  Then select the applied tag for the release in the "Choose
-a tag" 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
+Go to https://github.com/lammps/lammps/releases and create a new (draft) release page or check the
+existing draft for any necessary changes from pull requests that were merged but are not listed.
+Then select the applied tag for the release in the "Choose a tag" dropdown list. Go to the bottom of
+the list and select the "Set as pre-release" checkbox.  The "Set as the latest release" button is
 reserved for stable releases and updates to them.
 
-If everything is in order, you can click on the "Publish release"
-button.  Otherwise, click on "Save draft" and finish pending tasks until
-you can return to edit the release page and publish it.
+If everything is in order, you can click on the "Publish release" button.  Otherwise, click on "Save
+draft" and finish pending tasks until you can return to edit the release page and publish it.
 
-### Prepare pre-compiled packages, update packages to GitHub
+### Update download website, prepare pre-compiled packages, update packages to GitHub
 
-A suitable build environment is provided with the
-https://download.lammps.org/static/fedora41_musl_mingw.sif container
-image.  The corresponding container build definition file is maintained
-in the tools/singularity folder of the LAMMPS source distribution.
+Publishing the release on GitHub will trigger the Temple Jenkins cluster to update
+the https://docs.lammps.org/ website with the documentation for the new feature release
+and it will create a tarball for download (which contains the translated manual).
 
-#### Fully portable static Linux x86_64 non-MPI binaries
-
-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_mingw.sif
-apptainer shell fedora41_musl_mingw.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 -g 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
+Build a fully static LAMMPS installation using a musl-libc cross-compiler, install into a
+lammps-static folder, and create a tarball called lammps-linux-x86_64-19Nov2024.tar.gz (or using a
+corresponding date with a future release) from the lammps-static folder and upload it to GitHub
 with:
 
-``` sh
-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 ..
+```
+gh release upload patch_19Nov2024 ~/Downloads/lammps-linux-x86_64-19Nov2024.tar.gz
 ```
 
-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 with GUI 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 with GUI 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.  One (or two, if needed) feature releases
-before the stable release shall contain only bug fixes or minor feature
-updates in optional packages.  Also substantial changes to the core of
-the code shall be applied rather toward the beginning of a development
-cycle between two stable releases than toward the end.  The intention is
-to stablilize significant change to the core and have outside users and
-developers try them out during the development cycle; the sooner the
-changes are included, the better chances for spotting peripheral bugs
-and issues.
+A LAMMPS stable release is prepared about once per year in the months July, August, or September.
+One (or two, if needed) feature releases before the stable release shall contain only bug fixes
+or minor feature updates in optional packages.  Also substantial changes to the core of the code
+shall be applied rather toward the beginning of a development cycle between two stable releases
+than toward the end.  The intention is to stablilize significant change to the core and have
+outside users and developers try them out during the development cycle; the sooner the changes
+are included, the better chances for spotting peripheral bugs and issues.
 
 ### Prerequesites
 
-Before making a stable release all remaining backported bugfixes shall
-be released as a (final) stable update release (see below).
+Before making a stable release all remaining backported bugfixes shall be released as a (final)
+stable update release (see below).
 
-A LAMMPS stable release process starts like a feature release (see
-above), only that this feature release is called a "Stable Release
-Candidate" and no assets are uploaded to GitHub.
+A LAMMPS stable release process starts like a feature release (see above), only that this feature
+release is called a "Stable Release Candidate" and no assets are uploaded to GitHub.
 
 ### Synchronize 'maintenance' branch with 'release'
 
-The state of the 'release' branch is then transferred to the
-'maintenance' branch (which will have diverged significantly from
-'release' due to the selectively backported bug fixes).
+The state of the 'release' branch is then transferred to the 'maintenance' branch (which will
+have diverged significantly from 'release' due to the selectively backported bug fixes).
 
 ### Fast-forward merge of 'maintenance' into 'stable' and apply tag
 
-At this point it should be possible to do a fast-forward merge of
-'maintenance' to 'stable' and then apply the stable\_DMmmYYYY tag.
+At this point it should be possible to do a fast-forward merge of 'maintenance' to 'stable'
+and then apply the stable\_DMmmYYYY tag.
 
 ### Push branches and tags
 
+
+
 ## LAMMPS Stable Update Release
-
-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.

.github/workflows/check-cpp23.yml

@@ -1,4 +1,4 @@
-# GitHub action to build LAMMPS on Linux with gcc or clang and C++23
+# GitHub action to build LAMMPS on Linux with gcc and C++23
 name: "Check for C++23 Compatibility"
 
 on:
@@ -11,19 +11,11 @@ on:
 
   workflow_dispatch:
 
-concurrency:
-  group: ${{ github.event_name }}-${{ github.workflow }}-${{ github.ref }}
-  cancel-in-progress: ${{github.event_name == 'pull_request'}}
-
 jobs:
   build:
     name: Build with C++23 support enabled
     if: ${{ github.repository == 'lammps/lammps' }}
     runs-on: ubuntu-latest
-    strategy:
-      max-parallel: 2
-      matrix:
-        idx: [ gcc, clang ]
     env:
       CCACHE_DIR: ${{ github.workspace }}/.ccache
 
@@ -37,11 +29,8 @@ jobs:
       run: |
         sudo apt-get update
         sudo apt-get install -y ccache \
-                                clang \
-                                libcurl4-openssl-dev \
                                 libeigen3-dev \
-                                libfftw3-dev \
-                                libomp-dev \
+                                libcurl4-openssl-dev \
                                 mold \
                                 mpi-default-bin \
                                 mpi-default-dev \
@@ -55,8 +44,8 @@ jobs:
       uses: actions/cache@v4
       with:
         path: ${{ env.CCACHE_DIR }}
-        key: linux-cpp23-ccache-${{ matrix.idx }}-${{ github.sha }}
-        restore-keys: linux-cpp23-ccache-${{ matrix.idx }}
+        key: linux-cpp23-ccache-${{ github.sha }}
+        restore-keys: linux-cpp23-ccache-
 
     - name: Building LAMMPS via CMake
       shell: bash
@@ -69,14 +58,14 @@ jobs:
         cmake -S cmake -B build \
               -C cmake/presets/most.cmake \
               -C cmake/presets/kokkos-openmp.cmake \
-              -C cmake/presets/${{ matrix.idx }}.cmake \
               -D CMAKE_CXX_STANDARD=23 \
+              -D CMAKE_CXX_COMPILER=g++ \
+              -D CMAKE_C_COMPILER=gcc \
               -D CMAKE_CXX_COMPILER_LAUNCHER=ccache \
               -D CMAKE_C_COMPILER_LAUNCHER=ccache \
               -D CMAKE_BUILD_TYPE=Debug \
               -D CMAKE_CXX_FLAGS_DEBUG="-Og -g" \
               -D DOWNLOAD_POTENTIALS=off \
-              -D FFT=KISS \
               -D BUILD_MPI=on \
               -D BUILD_SHARED_LIBS=on \
               -D BUILD_TOOLS=off \

.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=on \
+              -D PKG_ML-RANN=off \
               -D PKG_MOLFILE=on \
               -D PKG_RHEO=on \
               -D PKG_PTM=on \

.github/workflows/style-check.yml

@@ -35,4 +35,3 @@ jobs:
          make check-permissions
          make check-homepage
          make check-errordocs
-         make check-fmtlib

.github/workflows/unittest-arm64.yml

@@ -1,81 +0,0 @@
-# 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

README

@@ -23,21 +23,17 @@ 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 (GPLv2)
-CITATION.cff               Citation information for LAMMPS in CFF format
-bench                      benchmark inputs
+LICENSE                    the GNU General Public License (GPL)
+bench                      benchmark problems
 cmake                      CMake build files
 doc                        documentation
-examples                   example inputs for many LAMMPS commands
-fortran                    Fortran 2003 module for LAMMPS
+examples                   simple test problems
+fortran                    Fortran wrapper for LAMMPS
 lib                        additional provided or external libraries
 potentials                 interatomic potential files
-python                     Python module for LAMMPS
+python                     Python wrappers for LAMMPS
 src                        source files
-third_party                Copies of thirdparty software bundled with LAMMPS
 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:
 
@@ -46,8 +42,6 @@ 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

cmake/CMakeLists.txt

@@ -3,11 +3,10 @@
 # CMake build system
 # This file is part of LAMMPS
 cmake_minimum_required(VERSION 3.16)
-########################################
-# initialize version variables with project command
-if(POLICY CMP0048)
-  cmake_policy(SET CMP0048 NEW)
+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)
   cmake_policy(SET CMP0074 NEW)
@@ -28,10 +27,7 @@ endif()
 
 ########################################
 
-project(lammps
-        DESCRIPTION "The LAMMPS Molecular Dynamics Simulator"
-        HOMEPAGE_URL "https://www.lammps.org"
-        LANGUAGES CXX C)
+project(lammps CXX)
 set(SOVERSION 0)
 get_property(BUILD_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
 
@@ -48,7 +44,6 @@ set(LAMMPS_DOC_DIR        ${LAMMPS_DIR}/doc)
 set(LAMMPS_TOOLS_DIR      ${LAMMPS_DIR}/tools)
 set(LAMMPS_PYTHON_DIR     ${LAMMPS_DIR}/python)
 set(LAMMPS_POTENTIALS_DIR ${LAMMPS_DIR}/potentials)
-set(LAMMPS_THIRDPARTY_DIR ${LAMMPS_DIR}/third_party)
 
 set(LAMMPS_DOWNLOADS_URL "https://download.lammps.org" CACHE STRING "Base URL for LAMMPS downloads")
 set(LAMMPS_POTENTIALS_URL "${LAMMPS_DOWNLOADS_URL}/potentials")
@@ -103,42 +98,50 @@ check_for_autogen_files(${LAMMPS_SOURCE_DIR})
 #####################################################################
 include(CheckIncludeFileCXX)
 
-# set required compiler flags and compiler/CPU arch specific optimizations
+# set required compiler flags, apply checks, and compiler/CPU arch specific optimizations
 if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
+  # Intel classic compilers version 19 are broken and fail to compile the embedded fmtlib
+  if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS 20.0)
+    message(ERROR "Intel classic compiler version ${CMAKE_CXX_COMPILER_VERSION} is too old")
+  endif()
+
   if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
     if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
       set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /Qrestrict")
     endif()
-    if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
-      set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /QxCOMMON-AVX512")
-    else()
-      set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /QxHost")
-    endif()
+    set(CMAKE_TUNE_DEFAULT "/QxHost")
   else()
     set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
-    if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
-      set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -xCOMMON-AVX512")
-    else()
-      set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=11074 -diag-disable=11076 -diag-disable=2196")
-    endif()
+    set(CMAKE_TUNE_DEFAULT "-xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=11074 -diag-disable=11076 -diag-disable=2196")
   endif()
 endif()
 
 # silence excessive warnings for new Intel Compilers
 if(CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM")
-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fp-model precise -Wno-tautological-constant-compare -Wno-unused-command-line-argument")
+  set(CMAKE_TUNE_DEFAULT "-fp-model precise -Wno-tautological-constant-compare -Wno-unused-command-line-argument")
 endif()
 
 # silence excessive warnings for PGI/NVHPC compilers
 if((CMAKE_CXX_COMPILER_ID STREQUAL "NVHPC") OR (CMAKE_CXX_COMPILER_ID STREQUAL "PGI"))
-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Minform=severe")
+  set(CMAKE_TUNE_DEFAULT "-Minform=severe")
+endif()
+
+# this hack is required to compile fmt lib with CrayClang version 15.0.2
+# CrayClang is only directly recognized by version 3.28 and later
+if(CMAKE_VERSION VERSION_LESS 3.28)
+  get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
+  if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
+    set(CMAKE_TUNE_DEFAULT "-DFMT_STATIC_THOUSANDS_SEPARATOR")
+  endif()
+else()
+  if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
+    set(CMAKE_TUNE_DEFAULT "-DFMT_STATIC_THOUSANDS_SEPARATOR")
+  endif()
 endif()
 
 # silence nvcc warnings
-if((PKG_KOKKOS) AND (Kokkos_ENABLE_CUDA) AND NOT
-    ((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") OR (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM")
-    OR (CMAKE_CXX_COMPILER_ID STREQUAL "XLClang") OR (CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")))
-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Xcudafe --diag_suppress=unrecognized_pragma,--diag_suppress=128")
+if((PKG_KOKKOS) AND (Kokkos_ENABLE_CUDA) AND NOT (CMAKE_CXX_COMPILER_ID STREQUAL "Clang"))
+  set(CMAKE_TUNE_DEFAULT "${CMAKE_TUNE_DEFAULT}" "-Xcudafe --diag_suppress=unrecognized_pragma,--diag_suppress=128")
 endif()
 
 # we *require* C++11 without extensions but prefer C++17.
@@ -153,6 +156,9 @@ 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()
@@ -197,14 +203,10 @@ if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND BUILD_SHARED_LIBS)
   set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
 endif()
 
-# do not include the (obsolete) MPI C++ bindings which makes for leaner object files
-# and avoids namespace conflicts. Put this early to increase its visbility.
-set(MPI_CXX_SKIP_MPICXX TRUE CACHE BOOL "Skip MPI C++ Bindings" FORCE)
-
 ########################################################################
 # User input options                                                   #
 ########################################################################
-# backward compatibility with older LAMMPS documentation
+# backward compatibility with CMake before 3.12 and older LAMMPS documentation
 if (PYTHON_EXECUTABLE)
   set(Python_EXECUTABLE "${PYTHON_EXECUTABLE}")
 endif()
@@ -220,12 +222,6 @@ 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)
@@ -238,6 +234,15 @@ option(CMAKE_POSITION_INDEPENDENT_CODE "Create object compatible with shared lib
 option(BUILD_TOOLS "Build and install LAMMPS tools (msi2lmp, binary2txt, chain)" OFF)
 option(BUILD_LAMMPS_GUI "Build and install the LAMMPS GUI" OFF)
 
+# Support using clang-tidy for C++ files with selected options
+set(ENABLE_CLANG_TIDY OFF CACHE BOOL "Include clang-tidy processing when compiling")
+if(ENABLE_CLANG_TIDY)
+  set(CMAKE_CXX_CLANG_TIDY "clang-tidy;-checks=-*,performance-trivially-destructible,performance-unnecessary-copy-initialization,performance-unnecessary-value-param,readability-redundant-control-flow,readability-redundant-declaration,readability-redundant-function-ptr-dereference,readability-redundant-member-init,readability-redundant-string-cstr,readability-redundant-string-init,readability-simplify-boolean-expr,readability-static-accessed-through-instance,readability-static-definition-in-anonymous-namespace,readability-qualified-auto,misc-unused-parameters,modernize-deprecated-ios-base-aliases,modernize-loop-convert,modernize-shrink-to-fit,modernize-use-auto,modernize-use-using,modernize-use-override,modernize-use-bool-literals,modernize-use-emplace,modernize-return-braced-init-list,modernize-use-equals-default,modernize-use-equals-delete,modernize-replace-random-shuffle,modernize-deprecated-headers,modernize-use-nullptr,modernize-use-noexcept,modernize-redundant-void-arg;-fix;-header-filter=.*,header-filter=library.h,header-filter=fmt/*.h" CACHE STRING "clang-tidy settings")
+else()
+  unset(CMAKE_CXX_CLANG_TIDY CACHE)
+endif()
+
+
 file(GLOB ALL_SOURCES CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/[^.]*.cpp)
 file(GLOB MAIN_SOURCES CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/main.cpp)
 list(REMOVE_ITEM ALL_SOURCES ${MAIN_SOURCES})
@@ -262,7 +267,6 @@ option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
 set(STANDARD_PACKAGES
   ADIOS
   AMOEBA
-  APIP
   ASPHERE
   ATC
   AWPMD
@@ -355,16 +359,27 @@ 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
 ######################################################
 target_include_directories(lammps PUBLIC $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}>)
-target_include_directories(lammps PUBLIC $<BUILD_INTERFACE:${LAMMPS_THIRDPARTY_DIR}>)
 
 if(PKG_ADIOS)
   # The search for ADIOS2 must come before MPI because
   # it includes its own MPI search with the latest FindMPI.cmake
   # script that defines the MPI::MPI_C target
+  enable_language(C)
   find_package(ADIOS2 REQUIRED)
   if(BUILD_MPI)
     if(NOT ADIOS2_HAVE_MPI)
@@ -379,18 +394,21 @@ if(PKG_ADIOS)
 endif()
 
 if(NOT CMAKE_CROSSCOMPILING)
-  find_package(MPI QUIET COMPONENTS CXX)
+  find_package(MPI QUIET)
   option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
 else()
   option(BUILD_MPI "Build MPI version" OFF)
 endif()
 
 if(BUILD_MPI)
+  # do not include the (obsolete) MPI C++ bindings which makes
+  # for leaner object files and avoids namespace conflicts
+  set(MPI_CXX_SKIP_MPICXX TRUE)
   # We use a non-standard procedure to cross-compile with MPI on Windows
   if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
     include(MPI4WIN)
   else()
-    find_package(MPI REQUIRED COMPONENTS CXX)
+    find_package(MPI REQUIRED)
     option(LAMMPS_LONGLONG_TO_LONG "Workaround if your system or MPI version does not recognize 'long long' data types" OFF)
     if(LAMMPS_LONGLONG_TO_LONG)
       target_compile_definitions(lammps PRIVATE -DLAMMPS_LONGLONG_TO_LONG)
@@ -404,8 +422,8 @@ else()
   target_link_libraries(lammps PUBLIC mpi_stubs)
 endif()
 
-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)
+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_VALUES smallbig bigbig smallsmall)
 set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
 validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
 string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)
@@ -423,19 +441,6 @@ if(NOT ${LAMMPS_MEMALIGN} STREQUAL "0")
   target_compile_definitions(lammps PRIVATE -DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
 endif()
 
-# this hack is required to compile fmt lib with CrayClang version 15.0.2
-# CrayClang is only directly recognized by CMake version 3.28 and later
-if(CMAKE_VERSION VERSION_LESS 3.28)
-  get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
-  if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
-    target_compile_definitions(lammps PRIVATE -DFMT_STATIC_THOUSANDS_SEPARATOR)
-  endif()
-else()
-  if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
-    target_compile_definitions(lammps PRIVATE -DFMT_STATIC_THOUSANDS_SEPARATOR)
-  endif()
-endif()
-
 # "hard" dependencies between packages resulting
 # in an error instead of skipping over files
 pkg_depends(ML-IAP ML-SNAP)
@@ -451,7 +456,6 @@ pkg_depends(ELECTRODE KSPACE)
 pkg_depends(EXTRA-MOLECULE MOLECULE)
 pkg_depends(MESONT MOLECULE)
 pkg_depends(RHEO BPM)
-pkg_depends(APIP ML-PACE)
 
 # detect if we may enable OpenMP support by default
 set(BUILD_OMP_DEFAULT OFF)
@@ -494,13 +498,13 @@ if(BUILD_OMP)
   if(CMAKE_VERSION VERSION_LESS 3.28)
     get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
     if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
-      set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fopenmp")
-      set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} -fopenmp")
+      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE}} -fopenmp")
+      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE}} -fopenmp")
     endif()
   else()
     if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
-      set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fopenmp")
-      set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} -fopenmp")
+      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE}} -fopenmp")
+      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE}} -fopenmp")
     endif()
   endif()
 endif()
@@ -518,6 +522,7 @@ if((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_STANDARD GREATER_EQUA
 endif()
 
 if(PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_ML-POD OR PKG_ELECTRODE OR PKG_RHEO OR BUILD_TOOLS)
+  enable_language(C)
   if (NOT USE_INTERNAL_LINALG)
     find_package(LAPACK)
     find_package(BLAS)
@@ -614,6 +619,10 @@ if(WITH_SWIG)
   add_subdirectory(${LAMMPS_SWIG_DIR} swig)
 endif()
 
+set(CMAKE_TUNE_FLAGS "${CMAKE_TUNE_DEFAULT}" CACHE STRING "Compiler and machine specific optimization flags (compilation only)")
+separate_arguments(CMAKE_TUNE_FLAGS)
+target_compile_options(lammps PRIVATE ${CMAKE_TUNE_FLAGS})
+target_compile_options(lmp PRIVATE ${CMAKE_TUNE_FLAGS})
 ########################################################################
 # Basic system tests (standard libraries, headers, functions, types)   #
 ########################################################################
@@ -918,7 +927,7 @@ endif()
 include(Testing)
 include(CodeCoverage)
 include(CodingStandard)
-find_package(ClangFormat 11.0 QUIET)
+find_package(ClangFormat 11.0)
 
 if(ClangFormat_FOUND)
   add_custom_target(format-src

cmake/Modules/CodeCoverage.cmake

@@ -7,76 +7,76 @@
 # For Python coverage the coverage package needs to be installed
 ###############################################################################
 if(ENABLE_COVERAGE)
-  find_program(GCOVR_BINARY gcovr)
-  find_package_handle_standard_args(GCOVR DEFAULT_MSG GCOVR_BINARY)
+    find_program(GCOVR_BINARY gcovr)
+    find_package_handle_standard_args(GCOVR DEFAULT_MSG GCOVR_BINARY)
 
-  find_program(COVERAGE_BINARY coverage)
-  find_package_handle_standard_args(COVERAGE DEFAULT_MSG COVERAGE_BINARY)
+    find_program(COVERAGE_BINARY coverage)
+    find_package_handle_standard_args(COVERAGE DEFAULT_MSG COVERAGE_BINARY)
 
-  if(GCOVR_FOUND)
-    get_filename_component(ABSOLUTE_LAMMPS_SOURCE_DIR ${LAMMPS_SOURCE_DIR} ABSOLUTE)
+    if(GCOVR_FOUND)
+        get_filename_component(ABSOLUTE_LAMMPS_SOURCE_DIR ${LAMMPS_SOURCE_DIR} ABSOLUTE)
 
-    add_custom_target(
-        gen_coverage_xml
-        COMMAND ${GCOVR_BINARY} -s -x -r ${ABSOLUTE_LAMMPS_SOURCE_DIR} --object-directory=${CMAKE_BINARY_DIR} -o coverage.xml
-        WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
-        COMMENT "Generating XML coverage report..."
-    )
+        add_custom_target(
+            gen_coverage_xml
+            COMMAND ${GCOVR_BINARY} -s -x -r ${ABSOLUTE_LAMMPS_SOURCE_DIR} --object-directory=${CMAKE_BINARY_DIR} -o coverage.xml
+            WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
+            COMMENT "Generating XML coverage report..."
+        )
 
-    set(COVERAGE_HTML_DIR ${CMAKE_BINARY_DIR}/coverage_html)
+        set(COVERAGE_HTML_DIR ${CMAKE_BINARY_DIR}/coverage_html)
 
-    add_custom_target(coverage_html_folder
-        COMMAND ${CMAKE_COMMAND} -E make_directory ${COVERAGE_HTML_DIR})
+        add_custom_target(coverage_html_folder
+            COMMAND ${CMAKE_COMMAND} -E make_directory ${COVERAGE_HTML_DIR})
 
-    add_custom_target(
-        gen_coverage_html
-        COMMAND ${GCOVR_BINARY} -s  --html --html-details -r ${ABSOLUTE_LAMMPS_SOURCE_DIR} --object-directory=${CMAKE_BINARY_DIR} -o ${COVERAGE_HTML_DIR}/index.html
-        WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
-        COMMENT "Generating HTML coverage report..."
-    )
-    add_dependencies(gen_coverage_html coverage_html_folder)
+        add_custom_target(
+            gen_coverage_html
+            COMMAND ${GCOVR_BINARY} -s  --html --html-details -r ${ABSOLUTE_LAMMPS_SOURCE_DIR} --object-directory=${CMAKE_BINARY_DIR} -o ${COVERAGE_HTML_DIR}/index.html
+            WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
+            COMMENT "Generating HTML coverage report..."
+        )
+        add_dependencies(gen_coverage_html coverage_html_folder)
 
-    add_custom_target(clean_coverage_html
-        ${CMAKE_COMMAND} -E remove_directory ${COVERAGE_HTML_DIR}
-        COMMENT "Deleting HTML coverage report..."
-    )
+        add_custom_target(clean_coverage_html
+            ${CMAKE_COMMAND} -E remove_directory ${COVERAGE_HTML_DIR}
+            COMMENT "Deleting HTML coverage report..."
+        )
 
-    add_custom_target(reset_coverage
-        ${CMAKE_COMMAND} -E remove -f */*.gcda */*/*.gcda */*/*/*.gcda
-                          */*/*/*/*.gcda */*/*/*/*/*.gcda */*/*/*/*/*/*.gcda
-                          */*/*/*/*/*/*/*.gcda */*/*/*/*/*/*/*/*.gcda
-                          */*/*/*/*/*/*/*/*/*.gcda */*/*/*/*/*/*/*/*/*/*.gcda
-        WORKIND_DIRECTORY ${CMAKE_BINARY_DIR}
-        COMMENT "Deleting coverage data files..."
-    )
-    add_dependencies(reset_coverage clean_coverage_html)
-  endif()
+        add_custom_target(reset_coverage
+            ${CMAKE_COMMAND} -E remove -f */*.gcda */*/*.gcda */*/*/*.gcda
+                              */*/*/*/*.gcda */*/*/*/*/*.gcda */*/*/*/*/*/*.gcda
+                              */*/*/*/*/*/*/*.gcda */*/*/*/*/*/*/*/*.gcda
+                              */*/*/*/*/*/*/*/*/*.gcda */*/*/*/*/*/*/*/*/*/*.gcda
+            WORKIND_DIRECTORY ${CMAKE_BINARY_DIR}
+            COMMENT "Deleting coverage data files..."
+        )
+        add_dependencies(reset_coverage clean_coverage_html)
+    endif()
 
-  if(COVERAGE_FOUND)
-    set(PYTHON_COVERAGE_HTML_DIR ${CMAKE_BINARY_DIR}/python_coverage_html)
-    configure_file(.coveragerc.in ${CMAKE_BINARY_DIR}/.coveragerc @ONLY)
+    if(COVERAGE_FOUND)
+        set(PYTHON_COVERAGE_HTML_DIR ${CMAKE_BINARY_DIR}/python_coverage_html)
+        configure_file(.coveragerc.in ${CMAKE_BINARY_DIR}/.coveragerc @ONLY)
 
-    add_custom_command(
-        OUTPUT ${CMAKE_BINARY_DIR}/unittest/python/.coverage
-        COMMAND ${COVERAGE_BINARY} combine
-        WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/unittest/python
-        COMMENT "Combine Python coverage files..."
-    )
+        add_custom_command(
+            OUTPUT ${CMAKE_BINARY_DIR}/unittest/python/.coverage
+            COMMAND ${COVERAGE_BINARY} combine
+            WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/unittest/python
+            COMMENT "Combine Python coverage files..."
+        )
 
-    add_custom_target(
-        gen_python_coverage_html
-        COMMAND ${COVERAGE_BINARY} html --rcfile=${CMAKE_BINARY_DIR}/.coveragerc -d ${PYTHON_COVERAGE_HTML_DIR}
-        DEPENDS ${CMAKE_BINARY_DIR}/unittest/python/.coverage ${CMAKE_BINARY_DIR}/.coveragerc
-        WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/unittest/python
-        COMMENT "Generating HTML Python coverage report..."
-    )
+        add_custom_target(
+            gen_python_coverage_html
+            COMMAND ${COVERAGE_BINARY} html --rcfile=${CMAKE_BINARY_DIR}/.coveragerc -d ${PYTHON_COVERAGE_HTML_DIR}
+            DEPENDS ${CMAKE_BINARY_DIR}/unittest/python/.coverage ${CMAKE_BINARY_DIR}/.coveragerc
+            WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/unittest/python
+            COMMENT "Generating HTML Python coverage report..."
+        )
 
-    add_custom_target(
-        gen_python_coverage_xml
-        COMMAND ${COVERAGE_BINARY} xml --rcfile=${CMAKE_BINARY_DIR}/.coveragerc -o ${CMAKE_BINARY_DIR}/python_coverage.xml
-        DEPENDS ${CMAKE_BINARY_DIR}/unittest/python/.coverage ${CMAKE_BINARY_DIR}/.coveragerc
-        WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/unittest/python
-        COMMENT "Generating XML Python coverage report..."
-    )
-  endif()
+        add_custom_target(
+            gen_python_coverage_xml
+            COMMAND ${COVERAGE_BINARY} xml --rcfile=${CMAKE_BINARY_DIR}/.coveragerc -o ${CMAKE_BINARY_DIR}/python_coverage.xml
+            DEPENDS ${CMAKE_BINARY_DIR}/unittest/python/.coverage ${CMAKE_BINARY_DIR}/.coveragerc
+            WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/unittest/python
+            COMMENT "Generating XML Python coverage report..."
+        )
+    endif()
 endif()

cmake/Modules/CodingStandard.cmake

@@ -1,39 +1,40 @@
-# use default (or custom) Python executable.
-# Python version check is in main CMakeLists.txt file
-if(Python_EXECUTABLE)
+# use default (or custom) Python executable, if version is sufficient
+if(Python_VERSION VERSION_GREATER_EQUAL 3.6)
   set(Python3_EXECUTABLE ${Python_EXECUTABLE})
 endif()
 find_package(Python3 COMPONENTS Interpreter)
 
 if(Python3_EXECUTABLE)
-  add_custom_target(
-    check-whitespace
-    ${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/whitespace.py .
-    WORKING_DIRECTORY  ${LAMMPS_DIR}
-    COMMENT "Check for whitespace errors")
-  add_custom_target(
-    check-homepage
-    ${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/homepage.py .
-    WORKING_DIRECTORY  ${LAMMPS_DIR}
-    COMMENT "Check for homepage URL errors")
-  add_custom_target(
-    check-permissions
-    ${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/permissions.py .
-    WORKING_DIRECTORY  ${LAMMPS_DIR}
-    COMMENT "Check for permission errors")
-  add_custom_target(
-    fix-whitespace
-    ${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/whitespace.py -f .
-    WORKING_DIRECTORY  ${LAMMPS_DIR}
-    COMMENT "Fix whitespace errors")
-  add_custom_target(
-    fix-homepage
-    ${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/homepage.py -f .
-    WORKING_DIRECTORY  ${LAMMPS_DIR}
-    COMMENT "Fix homepage URL errors")
-  add_custom_target(
-    fix-permissions
-    ${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/permissions.py -f .
-    WORKING_DIRECTORY  ${LAMMPS_DIR}
-    COMMENT "Fix permission errors")
+    if(Python3_VERSION VERSION_GREATER_EQUAL 3.6)
+        add_custom_target(
+          check-whitespace
+          ${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/whitespace.py .
+          WORKING_DIRECTORY  ${LAMMPS_DIR}
+          COMMENT "Check for whitespace errors")
+        add_custom_target(
+          check-homepage
+          ${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/homepage.py .
+          WORKING_DIRECTORY  ${LAMMPS_DIR}
+          COMMENT "Check for homepage URL errors")
+        add_custom_target(
+          check-permissions
+          ${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/permissions.py .
+          WORKING_DIRECTORY  ${LAMMPS_DIR}
+          COMMENT "Check for permission errors")
+        add_custom_target(
+          fix-whitespace
+          ${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/whitespace.py -f .
+          WORKING_DIRECTORY  ${LAMMPS_DIR}
+          COMMENT "Fix whitespace errors")
+        add_custom_target(
+          fix-homepage
+          ${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/homepage.py -f .
+          WORKING_DIRECTORY  ${LAMMPS_DIR}
+          COMMENT "Fix homepage URL errors")
+        add_custom_target(
+          fix-permissions
+          ${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/permissions.py -f .
+          WORKING_DIRECTORY  ${LAMMPS_DIR}
+          COMMENT "Fix permission errors")
+    endif()
 endif()

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 LAMMPS HTML documentation")
+    message(FATAL_ERROR "Python 3.8 and up is required to build the 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.2.2.tar.gz" CACHE STRING "URL for MathJax tarball")
-  set(MATHJAX_MD5 "08dd6ef33ca08870220d9aade2a62845" CACHE STRING "MD5 checksum of MathJax tarball")
+  set(MATHJAX_URL "https://github.com/mathjax/MathJax/archive/3.1.3.tar.gz" CACHE STRING "URL for MathJax tarball")
+  set(MATHJAX_MD5 "b81661c6e6ba06278e6ae37b30b0c492" CACHE STRING "MD5 checksum of MathJax tarball")
   mark_as_advanced(MATHJAX_URL)
   GetFallbackURL(MATHJAX_URL MATHJAX_FALLBACK)
 

cmake/Modules/LAMMPSInterfacePlugin.cmake

@@ -34,26 +34,8 @@ if(MSVC)
   add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
 endif()
 
-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()
+# C++11 is required
+set(CMAKE_CXX_STANDARD 11)
 set(CMAKE_CXX_STANDARD_REQUIRED ON)
 
 # Need -restrict with Intel compilers
@@ -62,9 +44,6 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
 endif()
 set(CMAKE_POSITION_INDEPENDENT_CODE TRUE)
 
-# skip over obsolete MPI-2 C++ bindings
-set(MPI_CXX_SKIP_MPICXX TRUE)
-
 #######
 # helper functions from LAMMPSUtils.cmake
 function(validate_option name values)
@@ -131,7 +110,8 @@ endif()
 ################################################################################
 # MPI configuration
 if(NOT CMAKE_CROSSCOMPILING)
-  find_package(MPI QUIET COMPONENTS CXX)
+  set(MPI_CXX_SKIP_MPICXX TRUE)
+  find_package(MPI QUIET)
   option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
 else()
   option(BUILD_MPI "Build MPI version" OFF)
@@ -143,38 +123,78 @@ if(BUILD_MPI)
   set(MPI_CXX_SKIP_MPICXX TRUE)
   # We use a non-standard procedure to cross-compile with MPI on Windows
   if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
-    message(STATUS "Downloading and configuring MS-MPI 10.1 for Windows cross-compilation")
-    set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/msmpi-win64-devel.tar.gz" CACHE STRING "URL for MS-MPI (win64) tarball")
-    set(MPICH2_WIN64_DEVEL_MD5 "86314daf1bffb809f1fcbefb8a547490" CACHE STRING "MD5 checksum of MS-MPI (win64) tarball")
-    mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
-    mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
+    # Download and configure MinGW compatible MPICH development files for Windows
+    option(USE_MSMPI "Use Microsoft's MS-MPI SDK instead of MPICH2-1.4.1" OFF)
+    if(USE_MSMPI)
+      message(STATUS "Downloading and configuring MS-MPI 10.1 for Windows cross-compilation")
+      set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/msmpi-win64-devel.tar.gz" CACHE STRING "URL for MS-MPI (win64) tarball")
+      set(MPICH2_WIN64_DEVEL_MD5 "86314daf1bffb809f1fcbefb8a547490" CACHE STRING "MD5 checksum of MS-MPI (win64) tarball")
+      mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
+      mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
 
-    include(ExternalProject)
-    if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
-      ExternalProject_Add(mpi4win_build
-        URL     ${MPICH2_WIN64_DEVEL_URL}
-        URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
-        CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
-        BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmsmpi.a)
+      include(ExternalProject)
+      if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
+        ExternalProject_Add(mpi4win_build
+          URL     ${MPICH2_WIN64_DEVEL_URL}
+          URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
+          CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
+          BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmsmpi.a)
+      else()
+        message(FATAL_ERROR "Only x86 64-bit builds are supported with MS-MPI")
+      endif()
+
+      ExternalProject_get_property(mpi4win_build SOURCE_DIR)
+      file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
+      add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
+      set_target_properties(MPI::MPI_CXX PROPERTIES
+        IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmsmpi.a"
+        INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
+        INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
+      add_dependencies(MPI::MPI_CXX mpi4win_build)
+
+      # set variables for status reporting at the end of CMake run
+      set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
+      set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
+      set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmsmpi.a")
     else()
-      message(FATAL_ERROR "Only x86 64-bit builds are supported with MS-MPI")
+      # Download and configure custom MPICH files for Windows
+      message(STATUS "Downloading and configuring MPICH-1.4.1 for Windows")
+      set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win64-devel.tar.gz" CACHE STRING "URL for MPICH2 (win64) tarball")
+      set(MPICH2_WIN64_DEVEL_MD5 "4939fdb59d13182fd5dd65211e469f14" CACHE STRING "MD5 checksum of MPICH2 (win64) tarball")
+      mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
+      mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
+
+      include(ExternalProject)
+      if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
+        ExternalProject_Add(mpi4win_build
+          URL     ${MPICH2_WIN64_DEVEL_URL}
+          URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
+          CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
+          BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
+      else()
+        ExternalProject_Add(mpi4win_build
+          URL     ${MPICH2_WIN32_DEVEL_URL}
+          URL_MD5 ${MPICH2_WIN32_DEVEL_MD5}
+          CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
+          BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
+      endif()
+
+      ExternalProject_get_property(mpi4win_build SOURCE_DIR)
+      file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
+      add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
+      set_target_properties(MPI::MPI_CXX PROPERTIES
+        IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmpi.a"
+        INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
+        INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
+      add_dependencies(MPI::MPI_CXX mpi4win_build)
+
+      # set variables for status reporting at the end of CMake run
+      set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
+      set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
+      set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmpi.a")
     endif()
-
-    ExternalProject_get_property(mpi4win_build SOURCE_DIR)
-    file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
-    add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
-    set_target_properties(MPI::MPI_CXX PROPERTIES
-      IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmsmpi.a"
-      INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
-      INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX=1")
-    add_dependencies(MPI::MPI_CXX mpi4win_build)
-
-    # set variables for status reporting at the end of CMake run
-    set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
-    set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX=1")
-    set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmsmpi.a")
   else()
-    find_package(MPI REQUIRED COMPONENTS CXX)
+    find_package(MPI REQUIRED)
     option(LAMMPS_LONGLONG_TO_LONG "Workaround if your system or MPI version does not recognize 'long long' data types" OFF)
     if(LAMMPS_LONGLONG_TO_LONG)
       target_compile_definitions(lammps INTERFACE -DLAMMPS_LONGLONG_TO_LONG)
@@ -222,8 +242,8 @@ endif()
 
 ################
 # integer size selection
-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)
+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_VALUES smallbig bigbig smallsmall)
 set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
 validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
 string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)

cmake/Modules/LAMMPSUtils.cmake

@@ -30,7 +30,7 @@ function(check_omp_h_include)
   if(OpenMP_CXX_FOUND)
     set(CMAKE_REQUIRED_FLAGS ${OpenMP_CXX_FLAGS})
     set(CMAKE_REQUIRED_INCLUDES ${OpenMP_CXX_INCLUDE_DIRS})
-    separate_arguments(CMAKE_REQUIRED_LINK_OPTIONS NATIVE_COMMAND ${OpenMP_CXX_FLAGS}) # needs to be a list
+    set(CMAKE_REQUIRED_LINK_OPTIONS ${OpenMP_CXX_FLAGS})
     set(CMAKE_REQUIRED_LIBRARIES ${OpenMP_CXX_LIBRARIES})
     # there are all kinds of problems with finding omp.h
     # for Clang and derived compilers so we pretend it is there.
@@ -75,25 +75,13 @@ function(get_lammps_version version_header variable)
     list(FIND MONTHS "${month}" month)
     string(LENGTH ${day} day_length)
     string(LENGTH ${month} month_length)
-    # no leading zero needed for new version string with dots
-    # if(day_length EQUAL 1)
-    #   set(day "0${day}")
-    # endif()
-    # if(month_length EQUAL 1)
-    #   set(month "0${month}")
-    #endif()
-    file(STRINGS ${version_header} line REGEX LAMMPS_UPDATE)
-    string(REGEX REPLACE "#define LAMMPS_UPDATE \"Update ([0-9]+)\"" "\\1" tweak "${line}")
-    if (line MATCHES "#define LAMMPS_UPDATE \"(Maintenance|Development)\"")
-      set(tweak "99")
+    if(day_length EQUAL 1)
+        set(day "0${day}")
     endif()
-    if(NOT tweak)
-      set(tweak "0")
+    if(month_length EQUAL 1)
+        set(month "0${month}")
     endif()
-    # new version string with dots
-    set(${variable} "${year}.${month}.${day}.${tweak}" PARENT_SCOPE)
-    # old version string without dots
-    # set(${variable} "${year}${month}${day}" PARENT_SCOPE)
+    set(${variable} "${year}${month}${day}" PARENT_SCOPE)
 endfunction()
 
 function(check_for_autogen_files source_dir)

cmake/Modules/MPI4WIN.cmake

@@ -1,31 +1,74 @@
-# set-up MS-MPI library for Windows with MinGW compatibility
-message(STATUS "Downloading and configuring MS-MPI 10.1 for Windows cross-compilation")
-set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/msmpi-win64-devel.tar.gz" CACHE STRING "URL for MS-MPI (win64) tarball")
-set(MPICH2_WIN64_DEVEL_MD5 "86314daf1bffb809f1fcbefb8a547490" CACHE STRING "MD5 checksum of MS-MPI (win64) tarball")
-mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
-mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
+# Download and configure MinGW compatible MPICH development files for Windows
+option(USE_MSMPI "Use Microsoft's MS-MPI SDK instead of MPICH2-1.4.1" OFF)
 
-include(ExternalProject)
-if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
-  ExternalProject_Add(mpi4win_build
-    URL     ${MPICH2_WIN64_DEVEL_URL}
-    URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
-    CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
-    BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmsmpi.a)
+if(USE_MSMPI)
+  message(STATUS "Downloading and configuring MS-MPI 10.1 for Windows cross-compilation")
+  set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/msmpi-win64-devel.tar.gz" CACHE STRING "URL for MS-MPI (win64) tarball")
+  set(MPICH2_WIN64_DEVEL_MD5 "86314daf1bffb809f1fcbefb8a547490" CACHE STRING "MD5 checksum of MS-MPI (win64) tarball")
+  mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
+  mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
+
+  include(ExternalProject)
+  if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
+    ExternalProject_Add(mpi4win_build
+      URL     ${MPICH2_WIN64_DEVEL_URL}
+      URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
+      CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
+      BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmsmpi.a)
+  else()
+    message(FATAL_ERROR "Only x86 64-bit builds are supported with MS-MPI")
+  endif()
+
+  ExternalProject_get_property(mpi4win_build SOURCE_DIR)
+  file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
+  add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
+  set_target_properties(MPI::MPI_CXX PROPERTIES
+    IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmsmpi.a"
+    INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
+    INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
+  add_dependencies(MPI::MPI_CXX mpi4win_build)
+
+  # set variables for status reporting at the end of CMake run
+  set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
+  set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
+  set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmsmpi.a")
 else()
-  message(FATAL_ERROR "Only x86 64-bit builds are supported with MS-MPI")
+  message(STATUS "Downloading and configuring MPICH2-1.4.1 for Windows cross-compilation")
+  set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win64-devel.tar.gz" CACHE STRING "URL for MPICH2 (win64) tarball")
+  set(MPICH2_WIN32_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win32-devel.tar.gz" CACHE STRING "URL for MPICH2 (win32) tarball")
+  set(MPICH2_WIN64_DEVEL_MD5 "4939fdb59d13182fd5dd65211e469f14" CACHE STRING "MD5 checksum of MPICH2 (win64) tarball")
+  set(MPICH2_WIN32_DEVEL_MD5 "a61d153500dce44e21b755ee7257e031" CACHE STRING "MD5 checksum of MPICH2 (win32) tarball")
+  mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
+  mark_as_advanced(MPICH2_WIN32_DEVEL_URL)
+  mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
+  mark_as_advanced(MPICH2_WIN32_DEVEL_MD5)
+
+  include(ExternalProject)
+  if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
+    ExternalProject_Add(mpi4win_build
+      URL     ${MPICH2_WIN64_DEVEL_URL}
+      URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
+      CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
+      BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
+  else()
+    ExternalProject_Add(mpi4win_build
+      URL     ${MPICH2_WIN32_DEVEL_URL}
+      URL_MD5 ${MPICH2_WIN32_DEVEL_MD5}
+      CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
+      BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
+  endif()
+
+  ExternalProject_get_property(mpi4win_build SOURCE_DIR)
+  file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
+  add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
+  set_target_properties(MPI::MPI_CXX PROPERTIES
+    IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmpi.a"
+    INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
+    INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
+  add_dependencies(MPI::MPI_CXX mpi4win_build)
+
+  # set variables for status reporting at the end of CMake run
+  set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
+  set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
+  set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmpi.a")
 endif()
-
-ExternalProject_get_property(mpi4win_build SOURCE_DIR)
-file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
-add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
-set_target_properties(MPI::MPI_CXX PROPERTIES
-  IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmsmpi.a"
-  INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
-  INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX=1")
-add_dependencies(MPI::MPI_CXX mpi4win_build)
-
-# set variables for status reporting at the end of CMake run
-set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
-set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX=1")
-set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmsmpi.a")

cmake/Modules/Packages/COLVARS.cmake

@@ -14,6 +14,10 @@ endif()
 
 add_library(colvars STATIC ${COLVARS_SOURCES})
 target_compile_definitions(colvars PRIVATE -DCOLVARS_LAMMPS)
+separate_arguments(CMAKE_TUNE_FLAGS)
+foreach(_FLAG ${CMAKE_TUNE_FLAGS})
+  target_compile_options(colvars PRIVATE ${_FLAG})
+endforeach()
 set_target_properties(colvars PROPERTIES OUTPUT_NAME lammps_colvars${LAMMPS_MACHINE})
 target_include_directories(colvars PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/colvars)
 # The line below is needed to locate math_eigen_impl.h
@@ -26,10 +30,6 @@ if(BUILD_OMP)
   target_link_libraries(colvars PRIVATE OpenMP::OpenMP_CXX)
 endif()
 
-if(BUILD_MPI)
-  target_link_libraries(colvars PUBLIC MPI::MPI_CXX)
-endif()
-
 if(COLVARS_DEBUG)
   # Need to export the define publicly to be valid in interface code
   target_compile_definitions(colvars PUBLIC -DCOLVARS_DEBUG)

cmake/Modules/Packages/EXTRA-COMMAND.cmake

@@ -1,18 +1,10 @@
 # the geturl command needs libcurl
 
-find_package(CURL QUIET)
+find_package(CURL QUIET COMPONENTS HTTP HTTPS)
 option(WITH_CURL "Enable libcurl support" ${CURL_FOUND})
 if(WITH_CURL)
+  find_package(CURL REQUIRED COMPONENTS HTTP HTTPS)
   target_compile_definitions(lammps PRIVATE -DLAMMPS_CURL)
-
-  # need to use pkgconfig for fully static bins to find custom static libs
-  if (CMAKE_SYSTEM_NAME STREQUAL "LinuxMUSL")
-    include(FindPkgConfig)
-    pkg_check_modules(CURL IMPORTED_TARGET libcurl libssl libcrypto)
-    target_link_libraries(lammps PUBLIC PkgConfig::CURL)
-  else()
-    find_package(CURL REQUIRED)
-    target_link_libraries(lammps PRIVATE CURL::libcurl)
-  endif()
+  target_link_libraries(lammps PRIVATE CURL::libcurl)
 endif()
 

cmake/Modules/Packages/GPU.cmake

@@ -189,7 +189,7 @@ if(GPU_API STREQUAL "CUDA")
   endif()
 
   add_executable(nvc_get_devices ${LAMMPS_LIB_SOURCE_DIR}/gpu/geryon/ucl_get_devices.cpp)
-  target_compile_definitions(nvc_get_devices PRIVATE -DUCL_CUDADR -DLAMMPS_${LAMMPS_SIZES})
+  target_compile_definitions(nvc_get_devices PRIVATE -DUCL_CUDADR)
   target_link_libraries(nvc_get_devices PRIVATE ${CUDA_LIBRARIES} ${CUDA_CUDA_LIBRARY})
   target_include_directories(nvc_get_devices PRIVATE ${CUDA_INCLUDE_DIRS})
 
@@ -489,7 +489,7 @@ else()
   target_link_libraries(gpu PRIVATE mpi_stubs)
 endif()
 
-set_target_properties(gpu PROPERTIES OUTPUT_NAME lammps_gpu${LAMMPS_MACHINE})
 target_compile_definitions(gpu PRIVATE -DLAMMPS_${LAMMPS_SIZES})
+set_target_properties(gpu PROPERTIES OUTPUT_NAME lammps_gpu${LAMMPS_MACHINE})
 target_sources(lammps PRIVATE ${GPU_SOURCES})
 target_include_directories(lammps PRIVATE ${GPU_SOURCES_DIR})

cmake/Modules/Packages/INTEL.cmake

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

cmake/Modules/Packages/KOKKOS.cmake

@@ -57,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.6.02.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "14c02fac07bfcec48a1654f88ddee9c6" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.5.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_MD5 "4d832aa0284169d9e3fbae3165286bc6" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   GetFallbackURL(KOKKOS_URL KOKKOS_FALLBACK)
@@ -83,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.6.02 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)
@@ -117,6 +117,7 @@ set(KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/atom_vec_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/comm_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/comm_tiled_kokkos.cpp
+                       ${KOKKOS_PKG_SOURCES_DIR}/group_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/min_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/min_linesearch_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/neighbor_kokkos.cpp

cmake/Modules/Packages/MC.cmake

@@ -7,23 +7,3 @@ if(NOT PKG_MANYBODY)
   list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/MC/fix_sgcmc.cpp)
   set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
 endif()
-
-# fix hmc may only be installed if also fix rigid/small from RIGID is installed
-if(NOT PKG_RIGID)
-  get_property(LAMMPS_FIX_HEADERS GLOBAL PROPERTY FIX)
-  list(REMOVE_ITEM LAMMPS_FIX_HEADERS ${LAMMPS_SOURCE_DIR}/MC/fix_hmc.h)
-  set_property(GLOBAL PROPERTY FIX "${LAMMPS_FIX_HEADERS}")
-  get_target_property(LAMMPS_SOURCES lammps SOURCES)
-  list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/MC/fix_hmc.cpp)
-  set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
-endif()
-
-# fix neighbor/swap may only be installed if also the VORONOI package is installed
-if(NOT PKG_VORONOI)
-  get_property(LAMMPS_FIX_HEADERS GLOBAL PROPERTY FIX)
-  list(REMOVE_ITEM LAMMPS_FIX_HEADERS ${LAMMPS_SOURCE_DIR}/MC/fix_neighbor_swap.h)
-  set_property(GLOBAL PROPERTY FIX "${LAMMPS_FIX_HEADERS}")
-  get_target_property(LAMMPS_SOURCES lammps SOURCES)
-  list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/MC/fix_neighbor_swap.cpp)
-  set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
-endif()

cmake/Modules/Packages/ML-IAP.cmake

@@ -24,7 +24,9 @@ if(MLIAP_ENABLE_PYTHON)
   if(NOT PKG_PYTHON)
     message(FATAL_ERROR "Must enable PYTHON package for including Python support in ML-IAP")
   endif()
-  # Python version check is in main CMakeLists.txt file
+  if(Python_VERSION VERSION_LESS 3.6)
+    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)

cmake/Modules/Packages/ML-PACE.cmake

@@ -53,13 +53,7 @@ else()
       add_library(yaml-cpp::yaml-cpp ALIAS yaml-cpp)
     endif()
 
-    # fixup yaml-cpp/emitterutils.cpp for GCC 15+ until patch is applied
-    file(READ ${lib-pace}/yaml-cpp/src/emitterutils.cpp yaml_emitterutils)
-    string(REPLACE "#include <sstream>" "#include <sstream>\n#include <cinttypes>" yaml_tmp_emitterutils "${yaml_emitterutils}")
-    string(REPLACE "#include <cinttypes>\n#include <cinttypes>" "#include <cinttypes>" yaml_emitterutils "${yaml_tmp_emitterutils}")
-    file(WRITE ${lib-pace}/yaml-cpp/src/emitterutils.cpp "${yaml_emitterutils}")
-
-    add_subdirectory(${lib-pace} build-pace EXCLUDE_FROM_ALL)
+    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")

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_EXECUTABLE}\nPIP=pip\nEXTRA_LINKOPTS=\n")
+  set(temp "${temp}PYTHON=python\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")

cmake/Modules/Packages/PLUMED.cmake

@@ -32,21 +32,14 @@ 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.3/plumed-src-2.9.3.tgz"
+set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.9.2/plumed-src-2.9.2.tgz"
   CACHE STRING "URL for PLUMED tarball")
-set(PLUMED_MD5 "ee1249805fe94bccee17d10610d3f6f1" CACHE STRING "MD5 checksum of PLUMED tarball")
+set(PLUMED_MD5 "04862602a372c1013bdfee2d6d03bace" CACHE STRING "MD5 checksum of PLUMED tarball")
 
 mark_as_advanced(PLUMED_URL)
 mark_as_advanced(PLUMED_MD5)
 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)
@@ -62,7 +55,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=${PLUMED_CXX_STANDARD}
+                                         --disable-python --enable-cxx=11
                                          --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}
@@ -149,7 +142,7 @@ else()
       CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR>
                                              ${CONFIGURE_REQUEST_PIC}
                                              --enable-modules=all
-                                             --enable-cxx=${PLUMED_CXX_STANDARD}
+                                             --enable-cxx=11
                                              --disable-python
                                              ${PLUMED_CONFIG_MPI}
                                              ${PLUMED_CONFIG_OMP}

cmake/Modules/Packages/PYTHON.cmake

@@ -1,6 +1,6 @@
 
 if(NOT Python_INTERPRETER)
-  # backward compatibility with older LAMMPS documentation
+  # backward compatibility with CMake before 3.12 and older LAMMPS documentation
   if(PYTHON_EXECUTABLE)
     set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
   endif()

cmake/Modules/Packages/SCAFACOS.cmake

@@ -14,16 +14,27 @@ endif()
 option(DOWNLOAD_SCAFACOS "Download ScaFaCoS library instead of using an already installed one" ${DOWNLOAD_SCAFACOS_DEFAULT})
 if(DOWNLOAD_SCAFACOS)
   message(STATUS "ScaFaCoS download requested - we will build our own")
-  set(SCAFACOS_URL "https://github.com/scafacos/scafacos/releases/download/v1.0.4/scafacos-1.0.4.tar.gz" CACHE STRING "URL for SCAFACOS tarball")
-  set(SCAFACOS_MD5 "23867540ec32e63ce71d6ecc105278d2" CACHE STRING "MD5 checksum of SCAFACOS tarball")
+  set(SCAFACOS_URL "https://github.com/scafacos/scafacos/releases/download/v1.0.1/scafacos-1.0.1.tar.gz" CACHE STRING "URL for SCAFACOS tarball")
+  set(SCAFACOS_MD5 "bd46d74e3296bd8a444d731bb10c1738" CACHE STRING "MD5 checksum of SCAFACOS tarball")
   mark_as_advanced(SCAFACOS_URL)
   mark_as_advanced(SCAFACOS_MD5)
   GetFallbackURL(SCAFACOS_URL SCAFACOS_FALLBACK)
 
+
+  # version 1.0.1 needs a patch to compile and linke cleanly with GCC 10 and later.
+  file(DOWNLOAD ${LAMMPS_THIRDPARTY_URL}/scafacos-1.0.1-fix.diff ${CMAKE_CURRENT_BINARY_DIR}/scafacos-1.0.1.fix.diff
+          EXPECTED_HASH MD5=4baa1333bb28fcce102d505e1992d032)
+
+  find_program(HAVE_PATCH patch)
+  if(NOT HAVE_PATCH)
+    message(FATAL_ERROR "The 'patch' program is required to build the ScaFaCoS library")
+  endif()
+
   include(ExternalProject)
   ExternalProject_Add(scafacos_build
     URL     ${SCAFACOS_URL} ${SCAFACOS_FALLBACK}
     URL_MD5 ${SCAFACOS_MD5}
+    PATCH_COMMAND patch -p1 < ${CMAKE_CURRENT_BINARY_DIR}/scafacos-1.0.1.fix.diff
     CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR> --disable-doc
                                              --enable-fcs-solvers=fmm,p2nfft,direct,ewald,p3m
                                              --with-internal-fftw --with-internal-pfft

cmake/Modules/Testing.cmake

@@ -21,11 +21,11 @@ if(ENABLE_TESTING)
   # also only verified with Fedora Linux > 30 and Ubuntu 18.04 or 22.04+(Ubuntu 20.04 fails)
   if((CMAKE_SYSTEM_NAME STREQUAL "Linux")
       AND ((CMAKE_CXX_COMPILER_ID STREQUAL "GNU") OR (CMAKE_CXX_COMPILER_ID STREQUAL "Clang")))
-    if(((CMAKE_LINUX_DISTRO STREQUAL "Ubuntu") AND (CMAKE_DISTRO_VERSION VERSION_GREATER_EQUAL 22.04))
+    if(((CMAKE_LINUX_DISTRO STREQUAL "Ubuntu") AND
+          ((CMAKE_DISTRO_VERSION VERSION_LESS_EQUAL 18.04) OR (CMAKE_DISTRO_VERSION VERSION_GREATER_EQUAL 22.04)))
         OR ((CMAKE_LINUX_DISTRO STREQUAL "Fedora") AND (CMAKE_DISTRO_VERSION VERSION_GREATER 30)))
       include(CheckCXXCompilerFlag)
       set(CMAKE_CUSTOM_LINKER_DEFAULT default)
-      check_cxx_compiler_flag(--ld-path=${CMAKE_LINKER} HAVE_LD_PATH_FLAG)
       check_cxx_compiler_flag(-fuse-ld=mold HAVE_MOLD_LINKER_FLAG)
       check_cxx_compiler_flag(-fuse-ld=lld HAVE_LLD_LINKER_FLAG)
       check_cxx_compiler_flag(-fuse-ld=gold HAVE_GOLD_LINKER_FLAG)
@@ -50,17 +50,6 @@ if(ENABLE_TESTING)
       if(NOT "${CMAKE_CUSTOM_LINKER}" STREQUAL "default")
         target_link_options(lammps PUBLIC -fuse-ld=${CMAKE_CUSTOM_LINKER})
       endif()
-      if(HAVE_LD_PATH_FLAG)
-        if("${CMAKE_CUSTOM_LINKER}" STREQUAL "mold")
-          target_link_options(lammps PUBLIC --ld-path=${HAVE_MOLD_LINKER_BIN})
-        elseif("${CMAKE_CUSTOM_LINKER}" STREQUAL "lld")
-          target_link_options(lammps PUBLIC --ld-path=${HAVE_LLD_LINKER_BIN})
-        elseif("${CMAKE_CUSTOM_LINKER}" STREQUAL "gold")
-          target_link_options(lammps PUBLIC --ld-path=${HAVE_GOLD_LINKER_BIN})
-        elseif("${CMAKE_CUSTOM_LINKER}" STREQUAL "bfd")
-          target_link_options(lammps PUBLIC --ld-path=${HAVE_BFD_LINKER_BIN})
-        endif()
-      endif()
     endif()
   endif()
 

cmake/Modules/Tools.cmake

@@ -6,10 +6,6 @@ if(BUILD_TOOLS)
   add_executable(stl_bin2txt ${LAMMPS_TOOLS_DIR}/stl_bin2txt.cpp)
   install(TARGETS stl_bin2txt DESTINATION ${CMAKE_INSTALL_BINDIR})
 
-  add_executable(reformat-json ${LAMMPS_TOOLS_DIR}/json/reformat-json.cpp)
-  target_include_directories(reformat-json PRIVATE ${LAMMPS_SOURCE_DIR})
-  install(TARGETS reformat-json DESTINATION ${CMAKE_INSTALL_BINDIR})
-
   include(CheckGeneratorSupport)
   if(CMAKE_GENERATOR_SUPPORT_FORTRAN)
     include(CheckLanguage)

cmake/packaging/linux_wrapper.sh

@@ -7,11 +7,6 @@ export LC_ALL=C
 BASEDIR="$(dirname "$0")"
 EXENAME="$(basename "$0")"
 
-# save old settings (for restoring them later)
-OLDPATH="${PATH}"
-OLDLDLIB="${LD_LIBRARY_PATH}"
-
-# prepend path to find our custom executables
 PATH="${BASEDIR}/bin:${PATH}"
 
 # append to LD_LIBRARY_PATH to prefer local (newer) libs
@@ -20,8 +15,6 @@ LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${BASEDIR}/lib"
 # set some environment variables for LAMMPS etc.
 LAMMPS_POTENTIALS="${BASEDIR}/share/lammps/potentials"
 MSI2LMP_LIBRARY="${BASEDIR}/share/lammps/frc_files"
-
-# export everything
-export LD_LIBRARY_PATH LAMMPS_POTENTIALS MSI2LMP_LIBRARY PATH OLDPATH OLDLDLIB
+export LD_LIBRARY_PATH LAMMPS_POTENTIALS MSI2LMP_LIBRARY PATH
 
 exec "${BASEDIR}/bin/${EXENAME}" "$@"

cmake/packaging/xdg-open

@@ -33,14 +33,6 @@
 #
 #---------------------------------------------
 
-# restore previously saved environment variables, if available
-if [ -n "${OLDPATH}" ]
-then
-    PATH="${OLDPATH}"
-    LD_LIBRARY_PATH="${OLDLDLIB}"
-    export PATH LD_LIBRARY_PATH
-fi
-
 NEW_LIBRARY_PATH="/usr/local/lib64"
 for s in $(echo $LD_LIBRARY_PATH | sed -e 's/:/ /g')
 do \

cmake/presets/all_off.cmake

@@ -4,7 +4,6 @@
 set(ALL_PACKAGES
   ADIOS
   AMOEBA
-  APIP
   ASPHERE
   ATC
   AWPMD

cmake/presets/all_on.cmake

@@ -6,7 +6,6 @@
 set(ALL_PACKAGES
   ADIOS
   AMOEBA
-  APIP
   ASPHERE
   ATC
   AWPMD

cmake/presets/hip_amd.cmake

@@ -19,19 +19,12 @@ set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
 
 set(MPI_CXX "hipcc" CACHE STRING "" FORCE)
 set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
-set(MPI_C "hipcc" CACHE STRING "" FORCE)
-set(MPI_C_COMPILER "mpicc" CACHE STRING "" FORCE)
-
-# change as needed. This is for Fedora Linux 41 and 42
-set(_libomp_root "/usr/lib/clang/18")
-# we need to explicitly specify the include dir, since hipcc will
-# compile each file twice and doesn't find omp.h the second time
 
 unset(HAVE_OMP_H_INCLUDE CACHE)
 set(OpenMP_C "hipcc" CACHE STRING "" FORCE)
-set(OpenMP_C_FLAGS "-fopenmp=libomp -I${_libomp_root}/include" CACHE STRING "" FORCE)
+set(OpenMP_C_FLAGS "-fopenmp" CACHE STRING "" FORCE)
 set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
 set(OpenMP_CXX "hipcc" CACHE STRING "" FORCE)
-set(OpenMP_CXX_FLAGS "-fopenmp=libomp -I${_libomp_root}/include" CACHE STRING "" FORCE)
+set(OpenMP_CXX_FLAGS "-fopenmp" CACHE STRING "" FORCE)
 set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
 set(OpenMP_omp_LIBRARY "libomp.so" CACHE PATH "" FORCE)

cmake/presets/kokkos-cuda.cmake

@@ -1,8 +1,10 @@
 # preset that enables KOKKOS and selects CUDA compilation with OpenMP
-# enabled as well. The GPU architecture *must* match your hardware (If not manually set, Kokkos will try to autodetect it).
+# enabled as well. This preselects CC 5.0 as default GPU arch, since
+# 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)
+set(Kokkos_ARCH_PASCAL60 ON CACHE BOOL "" FORCE)
 set(BUILD_OMP ON CACHE BOOL "" FORCE)
 get_filename_component(NVCC_WRAPPER_CMD ${CMAKE_CURRENT_SOURCE_DIR}/../lib/kokkos/bin/nvcc_wrapper ABSOLUTE)
 set(CMAKE_CXX_COMPILER ${NVCC_WRAPPER_CMD} CACHE FILEPATH "" FORCE)

cmake/presets/kokkos-hip.cmake

@@ -1,21 +1,22 @@
-# preset that enables KOKKOS and selects HIP compilation withOUT OpenMP.
-# Kokkos OpenMP is not compatible with the second pass of hipcc.
+# preset that enables KOKKOS and selects HIP compilation with OpenMP
+# enabled as well. Also sets some performance related compiler flags.
 set(PKG_KOKKOS ON CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_SERIAL ON CACHE BOOL "" FORCE)
-set(Kokkos_ENABLE_OPENMP OFF CACHE BOOL "" FORCE)
+set(Kokkos_ENABLE_OPENMP ON CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_CUDA   OFF CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_HIP    ON CACHE BOOL "" FORCE)
 set(Kokkos_ARCH_VEGA90A on CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_HIP_MULTIPLE_KERNEL_INSTANTIATIONS ON CACHE BOOL "" FORCE)
 set(BUILD_OMP ON CACHE BOOL "" FORCE)
 
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -munsafe-fp-atomics" CACHE STRING "" FORCE)
+set(CMAKE_CXX_COMPILER hipcc CACHE STRING "" FORCE)
+set(CMAKE_TUNE_FLAGS "-munsafe-fp-atomics" CACHE STRING "" FORCE)
 
-# If KSPACE is also enabled, use HIPFFT for FFTs
+# If KSPACE is also enabled, use CUFFT for FFTs
 set(FFT_KOKKOS "HIPFFT" CACHE STRING "" FORCE)
 
 # hide deprecation warnings temporarily for stable release
-#set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
+set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
 
 # these flags are needed to build with Cray MPICH on OLCF Crusher
 #-D CMAKE_CXX_FLAGS="-I/${MPICH_DIR}/include"

cmake/presets/kokkos-sycl-intel.cmake

@@ -21,10 +21,9 @@ set(CMAKE_C_COMPILER icx CACHE STRING "" FORCE)
 set(CMAKE_Fortran_COMPILER "" CACHE STRING "" FORCE)
 set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
 set(CMAKE_CXX_STANDARD 17 CACHE STRING "" FORCE)
-
-# set(_intel_sycl_flags " -w -fsycl -flink-huge-device-code -fsycl-targets=spir64_gen "
-set(_intel_sycl_flags " -w -fsycl -fsycl-device-code-split=per_kernel -fsycl-targets=spir64_gen ")
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${_intel_sycl_flags}" CACHE STRING "" FORCE)
-
+# Silence everything
+set(CMAKE_CXX_FLAGS "-w" CACHE STRING "" FORCE)
 #set(CMAKE_EXE_LINKER_FLAGS "-fsycl -flink-huge-device-code -fsycl-targets=spir64_gen " CACHE STRING "" FORCE)
-set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsycl -flink-huge-device-code " CACHE STRING "" FORCE)
+#set(CMAKE_TUNE_FLAGS "-O3 -fsycl -fsycl-device-code-split=per_kernel -fsycl-targets=spir64_gen" CACHE STRING "" FORCE)
+set(CMAKE_EXE_LINKER_FLAGS "-fsycl -flink-huge-device-code " CACHE STRING "" FORCE)
+set(CMAKE_TUNE_FLAGS "-O3 -fsycl -fsycl-device-code-split=per_kernel " CACHE STRING "" FORCE)

cmake/presets/kokkos-sycl-nvidia.cmake

@@ -14,7 +14,5 @@ set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
 set(CMAKE_CXX_COMPILER clang++ CACHE STRING "" FORCE)
 set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
 set(CMAKE_CXX_STANDARD 17 CACHE STRING "" FORCE)
-set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Xsycl-target-frontend -O3 " CACHE STRING "" FORCE)
-
-set(_intel_sycl_flags "-fgpu-inline-threshold=100000 -Xsycl-target-frontend -O3  -Xsycl-target-frontend -ffp-contract=on -Wno-unknown-cuda-version")
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${_intel_sycl_flags}" CACHE STRING "" FORCE)
+set(CMAKE_SHARED_LINKER_FLAGS "-Xsycl-target-frontend -O3" CACHE STRING "" FORCE)
+set(CMAKE_TUNE_FLAGS "-fgpu-inline-threshold=100000 -Xsycl-target-frontend -O3  -Xsycl-target-frontend -ffp-contract=on -Wno-unknown-cuda-version" CACHE STRING "" FORCE)

cmake/presets/mingw-cross.cmake

@@ -91,7 +91,7 @@ endif()
 set(DOWNLOAD_VORO ON CACHE BOOL "" FORCE)
 set(DOWNLOAD_EIGEN3 ON CACHE BOOL "" FORCE)
 set(LAMMPS_MEMALIGN "0" CACHE STRING "" FORCE)
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-missing-include-dirs" CACHE STRING "" FORCE)
+set(CMAKE_TUNE_FLAGS "-Wno-missing-include-dirs" CACHE STRING "" FORCE)
 set(CMAKE_EXE_LINKER_FLAGS "-Wl,--enable-stdcall-fixup,--as-needed,-lssp" CACHE STRING "" FORCE)
 set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--enable-stdcall-fixup,--as-needed,-lssp" CACHE STRING "" FORCE)
 set(BUILD_TOOLS ON CACHE BOOL "" FORCE)

cmake/presets/nolib.cmake

@@ -3,7 +3,6 @@
 
 set(PACKAGES_WITH_LIB
   ADIOS
-  APIP
   ATC
   AWPMD
   COMPRESS

cmake/presets/windows-intel-llvm.cmake

@@ -5,4 +5,4 @@ set(CMAKE_C_COMPILER "icx" CACHE STRING "" FORCE)
 set(CMAKE_Fortran_COMPILER "ifx" CACHE STRING "" FORCE)
 set(INTEL_LRT_MODE "C++11" CACHE STRING "" FORCE)
 unset(HAVE_OMP_H_INCLUDE CACHE)
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-unused-command-line-argument" CACHE STRING "" FORCE)
+set(CMAKE_TUNE_FLAGS -Wno-unused-command-line-argument)

doc/Makefile

@@ -17,11 +17,9 @@ 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
@@ -33,14 +31,10 @@ endif
 
 ifeq ($(shell type pdflatex >/dev/null 2>&1; echo $$?), 0)
 ifeq ($(shell type latexmk >/dev/null 2>&1; echo $$?), 0)
-HAS_PDFLATEX   = YES
+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
 
@@ -51,9 +45,8 @@ 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 fasthtml-init 
+.PHONY: help clean-all clean clean-spelling epub mobi html pdf spelling anchor_check style_check char_check role_check xmlgen fasthtml
 
-FASTHTMLFILES = $(patsubst $(RSTDIR)/%.rst,fasthtml/%.html,$(wildcard $(RSTDIR)/*rst))
 # ------------------------------------------
 
 help:
@@ -99,6 +92,8 @@ html: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJ
 	@(\
 		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build -E $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
+		touch $(RSTDIR)/Fortran.rst ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
+		sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
 		ln -sf Manual.html html/index.html;\
 		rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
 		echo "############################################" ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
@@ -110,8 +105,6 @@ html: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJ
 		env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst ;\
 		env LC_ALL=C grep -n '\(ref\|doc\)`[^`]' $(RSTDIR)/*.rst ;\
 		$(PYTHON) $(BUILDDIR)/utils/check-styles.py -s ../src -d src ;\
-		env LC_ALL=C grep -n -E '^ *\.\. [a-z0-9]+:(\s+.*|)$$' \
-                         $(RSTDIR)/*.rst ../src/*.{cpp,h} ../src/*/*.{cpp,h} ;\
 		echo "############################################" ;\
 		deactivate ;\
 	)
@@ -123,22 +116,24 @@ 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: fasthtml-init $(FASTHTMLFILES)
-	@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
+fasthtml: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
+	@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
+	@$(MAKE) $(MFLAGS) -C graphviz all
 	@mkdir -p fasthtml
-	@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
+	@(\
+		. $(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."
 
 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
@@ -160,6 +155,8 @@ epub: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
 	@(\
 		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build -E $(SPHINXEXTRA) -b epub -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
+		touch $(RSTDIR)/Fortran.rst ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
+		sphinx-build $(SPHINXEXTRA) -b epub -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
 		rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
 		deactivate ;\
 	)
@@ -179,6 +176,8 @@ pdf: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
 	@(\
 		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build -E $(SPHINXEXTRA) -b latex -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) latex ;\
+		touch $(RSTDIR)/Fortran.rst ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
+		sphinx-build  $(SPHINXEXTRA) -b latex -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) latex ;\
 		rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
 		echo "############################################" ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		rst_anchor_check src/*.rst ;\
@@ -189,8 +188,6 @@ pdf: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
 		env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst ;\
 		env LC_ALL=C grep -n '\(ref\|doc\)`[^`]' $(RSTDIR)/*.rst ;\
 		$(PYTHON) utils/check-styles.py -s ../src -d src ;\
-		env LC_ALL=C grep -n -E '^ *\.\. [a-z0-9]+:(\s+.*|)$$' \
-                         $(RSTDIR)/*.rst ../src/*.{cpp,h} ../src/*/*.{cpp,h} ;\
 		echo "############################################" ;\
 		deactivate ;\
 	)
@@ -240,8 +237,6 @@ role_check :
 	@( env LC_ALL=C grep -n ' `[^`]\+<[a-z][^`]\+`[^_]' $(RSTDIR)/*.rst && exit 1 || : )
 	@( env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst && exit 1 || : )
 	@( env LC_ALL=C grep -n '\(ref\|doc\)`[^`]' $(RSTDIR)/*.rst && exit 1 || : )
-	@( env LC_ALL=C grep -n -E '^ *\.\. [a-z0-9]+:(\s+.*|)$$' \
-                        $(RSTDIR)/*.rst ../src/*.{cpp,h} ../src/*/*.{cpp,h} && exit 1 || : )
 
 link_check : $(VENV) html
 	@(\
@@ -250,15 +245,6 @@ link_check : $(VENV) html
 		deactivate ;\
 	)
 
-upgrade: $(VENV)
-	@(\
-		. $(VENV)/bin/activate; \
-		pip $(PIP_OPTIONS) install --upgrade pip; \
-		pip $(PIP_OPTIONS) install --upgrade wheel; \
-		pip $(PIP_OPTIONS) install --upgrade -r $(BUILDDIR)/utils/requirements.txt; \
-		deactivate;\
-	)
-
 xmlgen : doxygen/xml/index.xml
 
 doxygen/Doxyfile: doxygen/Doxyfile.in

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
-using GitHub then you either need to build them yourself or read the
-online version at https://docs.lammps.org/
+from GitHub then you either need to build them.
 
 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.8 or later,
-doxygen 1.8.10 or later, git, and the venv python module have to be
-installed if not already available.  Also internet access is initially
-required to download external files and tools.
+To run the HTML documention build toolchain, python 3.x, doxygen, git,
+and the venv python module have to be installed if not already available.
+Also internet access is initially 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,24 +52,16 @@ 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.

doc/graphviz/lammps-releases.dot

@@ -5,13 +5,13 @@ digraph releases {
     github -> develop [label="Merge commits"];
     {
         rank = "same";
-        work [shape="none" label="Development branches:" fontname="bold"]
+        work [shape="none" label="Development branches:"]
         develop [label="'develop' branch" height=0.75];
         maintenance [label="'maintenance' branch" height=0.75];
     };
     {
         rank = "same";
-        upload [shape="none" label="Release branches:" fontname="bold"]
+        upload [shape="none" label="Release branches:"]
         release [label="'release' branch" height=0.75];
         stable [label="'stable' branch" height=0.75];
     };
@@ -22,7 +22,7 @@ digraph releases {
     maintenance -> stable [label="Updates to stable release"];
     {
         rank = "same";
-        tag [shape="none" label="Applied tags:" fontname="bold"];
+        tag [shape="none" label="Applied tags:"];
         patchtag [shape="box" label="patch_<date>"];
         stabletag [shape="box" label="stable_<date>"];
         updatetag [shape="box" label="stable_<date>_update<num>"];

doc/lammps.1

@@ -1,7 +1,7 @@
-.TH LAMMPS "1" "12 June 2025" "2025-06-12"
+.TH LAMMPS "1" "19 November 2024" "2024-11-19"
 .SH NAME
 .B LAMMPS
-\- Molecular Dynamics Simulator.  Version 12 June 2025
+\- Molecular Dynamics Simulator.  Version 19 November 2024
 
 .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--2025 Sandia Corporation
+© 2003--2024 Sandia Corporation
 
 This package is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License version 2 as

doc/src/Build.rst

@@ -17,7 +17,6 @@ section of the manual.
 .. toctree::
    :maxdepth: 1
 
-   Build_prerequisites
    Build_cmake
    Build_make
    Build_link

doc/src/Build_basics.rst

@@ -196,23 +196,22 @@ LAMMPS.
 
    .. tab:: CMake build
 
-      By default CMake will use the compiler it finds according to its
+      By default CMake will use the compiler it finds according to
       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.  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.
+      is not the case.
 
       You can tell CMake to look for a specific compiler with setting
       CMake variables (listed below) during configuration.  For a few
       common choices, there are also presets in the ``cmake/presets``
-      folder.  You may also specify the corresponding ``CMAKE_*_FLAGS``
+      folder.  For convenience, there is a ``CMAKE_TUNE_FLAGS`` variable
+      that can be set to apply global compiler options (applied to
+      compilation only), to be used for adding compiler or host specific
+      optimization flags in addition to the "flags" variables listed
+      below. You may also specify the corresponding ``CMAKE_*_FLAGS``
       variables individually, if you want to experiment with alternate
       optimization flags.  You should specify all 3 compilers, so that
       the (few) LAMMPS source files written in C or Fortran are built
@@ -224,8 +223,6 @@ 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
@@ -262,6 +259,10 @@ LAMMPS.
       ``-C ../cmake/presets/pgi.cmake`` will switch the compiler to the PGI compilers,
       and ``-C ../cmake/presets/nvhpc.cmake`` will switch to the NVHPC compilers.
 
+      Furthermore, you can set ``CMAKE_TUNE_FLAGS`` to specifically add
+      compiler flags to tune for optimal performance on given hosts.
+      This variable is empty by default.
+
       .. note::
 
          When the cmake command completes, it prints a summary to the
@@ -320,23 +321,15 @@ 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
-      achieve optimal performance.  You need to include these in the
-      ``CCFLAGS`` and ``LINKFLAGS`` settings above.  For details, see the
-      documentation for the individual packages listed on the
-      :doc:`Speed_packages` page.  Or examine these files in the
-      ``src/MAKE/OPTIONS`` directory.  They correspond to each of the 5
-      accelerator packages and their hardware variants:
+         If you build LAMMPS with any :doc:`Speed_packages` included,
+         there may be specific compiler or linker flags that are either
+         required or recommended to enable required features and to
+         achieve optimal performance.  You need to include these in the
+         ``CCFLAGS`` and ``LINKFLAGS`` settings above.  For details, see the
+         documentation for the individual packages listed on the
+         :doc:`Speed_packages` page.  Or examine these files in the
+         ``src/MAKE/OPTIONS`` directory.  They correspond to each of the 5
+         accelerator packages and their hardware variants:
 
          .. code-block:: bash
 

doc/src/Build_cmake.rst

@@ -52,9 +52,9 @@ software or for people 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 `Spack <https://spack.io>`_
-  or `Homebrew <https://brew.sh/>`_.
-- Integration of automated unit and regression testing.
+  modules, or automated build tools like `Homebrew <https://brew.sh/>`_.
+- Integration of automated unit and regression testing (the LAMMPS side
+  of this is still under active development).
 
 .. _cmake_build:
 
@@ -119,13 +119,6 @@ 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

doc/src/Build_development.rst

@@ -28,6 +28,28 @@ variable VERBOSE set to 1:
 
 ----------
 
+.. _clang-tidy:
+
+Enable static code analysis with clang-tidy (CMake only)
+--------------------------------------------------------
+
+The `clang-tidy tool <https://clang.llvm.org/extra/clang-tidy/>`_ is a
+static code analysis tool to diagnose (and potentially fix) typical
+programming errors or coding style violations.  It has a modular framework
+of tests that can be adjusted to help identifying problems before they
+become bugs and also assist in modernizing large code bases (like LAMMPS).
+It can be enabled for all C++ code with the following CMake flag
+
+.. code-block:: bash
+
+   -D ENABLE_CLANG_TIDY=value    # value = no (default) or yes
+
+With this flag enabled all source files will be processed twice, first to
+be compiled and then to be analyzed. Please note that the analysis can be
+significantly more time-consuming than the compilation itself.
+
+----------
+
 .. _iwyu_processing:
 
 Report missing and unneeded '#include' statements (CMake only)
@@ -501,7 +523,7 @@ to do this to install it via pip:
 
 .. code-block:: bash
 
-   python3 -m pip install gcovr
+   pip install git+https://github.com/gcovr/gcovr.git
 
 After post-processing with ``gen_coverage_html`` the results are in
 a folder ``coverage_html`` and can be viewed with a web browser.

doc/src/Build_extras.rst

@@ -35,7 +35,6 @@ This is the list of packages that may require additional steps.
    :columns: 6
 
    * :ref:`ADIOS <adios>`
-   * :ref:`APIP <apip>`
    * :ref:`ATC <atc>`
    * :ref:`AWPMD <awpmd>`
    * :ref:`COLVARS <colvar>`
@@ -256,10 +255,11 @@ 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 use the same MPI library (or the STUBS library) settings as the
-main LAMMPS code.  This also applies to the ``-DLAMMPS_BIGBIG`` or
-``-DLAMMPS_SMALLBIG`` settings in whichever Makefile you use.
+``lib/gpu/README``.  Note that the GPU library uses MPI calls, so you must
+use the same MPI library (or the STUBS library) settings as the main
+LAMMPS code.  This also applies to the ``-DLAMMPS_BIGBIG``\ ,
+``-DLAMMPS_SMALLBIG``\ , or ``-DLAMMPS_SMALLSMALL`` settings in whichever
+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``
@@ -612,12 +612,6 @@ They must be specified in uppercase.
    *  - ZEN3
       - HOST
       - AMD Zen3 architecture
-   *  - ZEN4
-      - HOST
-      - AMD Zen4 architecture
-   *  - ZEN5
-      - HOST
-      - AMD Zen5 architecture
    *  - RISCV_SG2042
       - HOST
       - SG2042 (RISC-V) CPUs
@@ -672,12 +666,6 @@ They must be specified in uppercase.
    *  - HOPPER90
       - GPU
       - NVIDIA Hopper generation CC 9.0
-   *  - BLACKWELL100
-      - GPU
-      - NVIDIA Blackwell generation CC 10.0
-   *  - BLACKWELL120
-      - GPU
-      - NVIDIA Blackwell generation CC 12.0
    *  - AMD_GFX906
       - GPU
       - AMD GPU MI50/60
@@ -726,11 +714,8 @@ They must be specified in uppercase.
    *  - INTEL_PVC
       - GPU
       - Intel GPU Ponte Vecchio
-   *  - INTEL_DG2
-      - GPU
-      - Intel GPU DG2
 
-This list was last updated for version 4.6.2 of the Kokkos library.
+This list was last updated for version 4.5.1 of the Kokkos library.
 
 .. tabs::
 
@@ -1154,10 +1139,11 @@ POEMS package
 PYTHON package
 ---------------------------
 
-Building with the PYTHON package requires you have a the Python
-development headers and library available on your system, which
-needs to be Python version 3.6 or later.  See ``lib/python/README``
-for additional details.
+Building with the PYTHON package requires you have a the Python development
+headers and library available on your system, which needs to be a Python 2.7
+version or a Python 3.x version.  Since support for Python 2.x has ended,
+using Python 3.x is strongly recommended. See ``lib/python/README`` for
+additional details.
 
 .. tabs::
 
@@ -1173,7 +1159,7 @@ for 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. python3-devel.
+      e.g. python2-devel.
 
    .. tab:: Traditional make
 
@@ -1285,34 +1271,6 @@ systems.
 
 ----------
 
-.. _apip:
-
-APIP package
------------------------------
-
-The APIP package depends on the library of the
-:ref:`ML-PACE <ml-pace>` package.
-The code for the library can be found
-at: `https://github.com/ICAMS/lammps-user-pace/ <https://github.com/ICAMS/lammps-user-pace/>`_
-
-.. tabs::
-
-   .. tab:: CMake build
-
-      No additional settings are needed besides ``-D PKG_APIP=yes``
-      and ``-D PKG_ML-PACE=yes``.
-      One can use a local version of the ML-PACE library instead of
-      automatically downloading the library as described :ref:`here <ml-pace>`.
-
-
-   .. tab:: Traditional make
-
-      You need to install the ML-PACE package *first* and follow
-      the instructions :ref:`here <ml-pace>` before installing
-      the APIP package.
-
-----------
-
 .. _atc:
 
 ATC package

doc/src/Build_make.rst

@@ -30,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 3.6 to 3.11.
-    The procedure for :doc:`building the documentation <Build_manual>`
-    *requires* Python 3.8 or later.
+    folder).  Python scripts are currently tested with python 2.7 and
+    3.6 to 3.11. The procedure for :doc:`building the documentation
+    <Build_manual>` *requires* Python 3.5 or later.
 
 Getting started
 ^^^^^^^^^^^^^^^

doc/src/Build_manual.rst

@@ -57,8 +57,6 @@ Python interpreter version 3.8 or later, the ``doxygen`` tools and
 internet access to download additional files and tools are required.
 This download is usually only required once or after the documentation
 folder is returned to a pristine state with ``make clean-all``.
-You can also upgrade those packages to their latest available versions
-with ``make upgrade``.
 
 For the documentation build a python virtual environment is set up in
 the folder ``doc/docenv`` and various python packages are installed into
@@ -80,11 +78,11 @@ 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 pandoc
+   make fasthtml      # generate approximate HTML in fasthtml dir using Sphinx
+                      # 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
-   make upgrade       # upgrade the python packages in the virtual environment
 
    make anchor_check  # check for duplicate anchor labels
    make style_check   # check for complete and consistent style lists
@@ -118,9 +116,9 @@ environment variable.
 Prerequisites for HTML
 ----------------------
 
-To run the HTML documentation build toolchain, Python 3.8 or later, git,
-doxygen, and virtualenv have to be installed locally.  Here are
-instructions for common setups:
+To run the HTML documentation build toolchain, python 3, git, doxygen,
+and virtualenv have to be installed locally.  Here are instructions for
+common setups:
 
 .. tabs::
 
@@ -130,7 +128,13 @@ instructions for common setups:
 
          sudo apt-get install git doxygen
 
-   .. tab:: Fedora or RHEL/AlmaLinux/RockyLinux (8.x or later)
+   .. tab:: RHEL or CentOS (Version 7.x)
+
+      .. code-block:: bash
+
+         sudo yum install git doxygen
+
+   .. tab:: Fedora or RHEL/CentOS (8.x or later)
 
       .. code-block:: bash
 
@@ -150,36 +154,7 @@ 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.  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
+of LaTeX styles/packages are required.  To run the PDFLaTeX translation
 the ``latexmk`` script needs to be installed as well.
 
 Prerequisites for ePUB and MOBI
@@ -207,42 +182,12 @@ 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 and that
-there are no spelling issues.  This is done with ``make html``, ``make pdf``,
-and ``make spelling``, respectively.
-
-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
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+and the PDF format documentation can translate without errors.  During
+testing the html translation, you may use the ``make fasthtml`` command
+which does an approximate translation (i.e. not all Sphinx features and
+extensions will work), but runs very fast because it will only translate
+files that have been changed since the last ``make fasthtml`` command.
 
 Please also check the output to the console for any warnings or problems.  There will
 be multiple tests run automatically:

doc/src/Build_prerequisites.rst

@@ -1,22 +0,0 @@
-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.

doc/src/Build_settings.rst

@@ -8,30 +8,29 @@ 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 and C++17 standard compliance`_ when building all of LAMMPS
+* `C++11 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 from the input`_
-* `Prevent download of large potential files`_
+* `Support for downloading files`_
 * `Memory allocation alignment`_
 * `Workaround for long long integers`_
 * `Exception handling when using LAMMPS as a library`_ to capture errors
+* `Trigger selected floating-point exceptions`_
 
 ----------
 
 .. _cxx11:
 
-C++11 and C++17 standard compliance
------------------------------------
+C++11 standard compliance
+-------------------------
 
-A C++11 standard compatible compiler is currently the minimum
-requirement for compiling LAMMPS.  LAMMPS version 3 March 2020 is the
-last version compatible with the previous C++98 standard for the core
-code and most packages. Most currently used C++ compilers are compatible
-with C++11, but some older ones may need extra flags to enable C++11
-compliance.  Example for GNU c++ 4.8.x:
+A C++11 standard compatible compiler is a requirement for compiling LAMMPS.
+LAMMPS version 3 March 2020 is the last version compatible with the previous
+C++98 standard for the core code and most packages. Most currently used
+C++ compilers are compatible 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
 
@@ -41,17 +40,6 @@ 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:
@@ -315,7 +303,7 @@ large counters can become before "rolling over".  The default setting of
 
       .. code-block:: bash
 
-         -D LAMMPS_SIZES=value   # smallbig (default) or bigbig
+         -D LAMMPS_SIZES=value   # smallbig (default) or bigbig or smallsmall
 
       If the variable is not set explicitly, "smallbig" is used.
 
@@ -326,7 +314,7 @@ large counters can become before "rolling over".  The default setting of
 
       .. code-block:: make
 
-         LMP_INC = -DLAMMPS_SMALLBIG    # or -DLAMMPS_BIGBIG
+         LMP_INC = -DLAMMPS_SMALLBIG    # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL
 
       The default setting is ``-DLAMMPS_SMALLBIG`` if nothing is specified
 
@@ -335,27 +323,34 @@ LAMMPS system size restrictions
 
 .. list-table::
    :header-rows: 1
-   :widths: 27 36 37
+   :widths: 18 27 28 27
    :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
-the default "smallbig" setting.
+"smallbig" and the "smallsmall" setting is only needed if your machine
+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
@@ -509,8 +504,8 @@ during a run.
 
 .. _libcurl:
 
-Support for downloading files from the input
---------------------------------------------
+Support for downloading files
+-----------------------------
 
 .. versionadded:: 29Aug2024
 
@@ -553,25 +548,6 @@ 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
@@ -658,3 +634,40 @@ code has to be set up to *catch* exceptions thrown from within LAMMPS.
    throw an exception and thus other MPI ranks may get stuck waiting for
    messages from the ones with errors.
 
+----------
+
+.. _trap_fpe:
+
+Trigger selected floating-point exceptions
+------------------------------------------
+
+Many kinds of CPUs have the capability to detect when a calculation
+results in an invalid math operation, like a division by zero or calling
+the square root with a negative argument.  The default behavior on
+most operating systems is to continue and have values for ``NaN`` (= not
+a number) or ``Inf`` (= infinity).  This allows software to detect and
+recover from such conditions.  This behavior can be changed, however,
+often through use of compiler flags.  On Linux systems (or more general
+on systems using the GNU C library), these so-called floating-point traps
+can also be selectively enabled through library calls.  LAMMPS supports
+that by setting the ``-DLAMMPS_TRAP_FPE`` pre-processor define.  As it is
+done in the ``main()`` function, this applies only to the standalone
+executable, not the library.
+
+.. tabs::
+
+   .. tab:: CMake build
+
+      .. code-block:: bash
+
+         -D CMAKE_TUNE_FLAGS=-DLAMMPS_TRAP_FPE
+
+   .. tab:: Traditional make
+
+      .. code-block:: make
+
+         LMP_INC = -DLAMMPS_TRAP_FPE  <other LMP_INC settings>
+
+After compilation with this flag set, the LAMMPS executable will stop
+and produce a core dump when a division by zero, overflow, illegal math
+function argument or other invalid floating point operation is encountered.

doc/src/Commands_all.rst

@@ -140,7 +140,6 @@ 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>`

doc/src/Commands_bond.rst

@@ -23,7 +23,6 @@ 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>`
@@ -128,7 +127,7 @@ OPT.
    * :doc:`harmonic (iko) <dihedral_harmonic>`
    * :doc:`helix (o) <dihedral_helix>`
    * :doc:`lepton (o) <dihedral_lepton>`
-   * :doc:`multi/harmonic (ko) <dihedral_multi_harmonic>`
+   * :doc:`multi/harmonic (o) <dihedral_multi_harmonic>`
    * :doc:`nharmonic (o) <dihedral_nharmonic>`
    * :doc:`opls (iko) <dihedral_opls>`
    * :doc:`quadratic (o) <dihedral_quadratic>`

doc/src/Commands_compute.rst

@@ -58,7 +58,6 @@ 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>`
@@ -141,8 +140,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 (k) <compute_sna_atom>`
-   * :doc:`sna/grid/local (k) <compute_sna_atom>`
+   * :doc:`sna/grid <compute_sna_atom>`
+   * :doc:`sna/grid/local <compute_sna_atom>`
    * :doc:`snad/atom <compute_sna_atom>`
    * :doc:`snav/atom <compute_sna_atom>`
    * :doc:`sph/e/atom <compute_sph_e_atom>`
@@ -178,7 +177,6 @@ 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>`

doc/src/Commands_dump.rst

@@ -19,7 +19,6 @@ An alphabetic list of all LAMMPS :doc:`dump <dump>` commands.
    * :doc:`custom/gz <dump>`
    * :doc:`custom/zstd <dump>`
    * :doc:`dcd <dump>`
-   * :doc:`extxyz <dump>`
    * :doc:`grid <dump>`
    * :doc:`grid/vtk <dump>`
    * :doc:`h5md <dump_h5md>`

doc/src/Commands_fix.rst

@@ -22,7 +22,6 @@ OPT.
    * :doc:`append/atoms <fix_append_atoms>`
    * :doc:`atc <fix_atc>`
    * :doc:`atom/swap <fix_atom_swap>`
-   * :doc:`atom_weight/apip <fix_atom_weight_apip>`
    * :doc:`ave/atom <fix_ave_atom>`
    * :doc:`ave/chunk <fix_ave_chunk>`
    * :doc:`ave/correlate <fix_ave_correlate>`
@@ -30,7 +29,6 @@ OPT.
    * :doc:`ave/grid <fix_ave_grid>`
    * :doc:`ave/histo <fix_ave_histo>`
    * :doc:`ave/histo/weight <fix_ave_histo>`
-   * :doc:`ave/moments <fix_ave_moments>`
    * :doc:`ave/time <fix_ave_time>`
    * :doc:`aveforce <fix_aveforce>`
    * :doc:`balance <fix_balance>`
@@ -66,7 +64,7 @@ OPT.
    * :doc:`electrode/conp (i) <fix_electrode>`
    * :doc:`electrode/conq (i) <fix_electrode>`
    * :doc:`electrode/thermo (i) <fix_electrode>`
-   * :doc:`electron/stopping (k) <fix_electron_stopping>`
+   * :doc:`electron/stopping <fix_electron_stopping>`
    * :doc:`electron/stopping/fit <fix_electron_stopping>`
    * :doc:`enforce2d (k) <fix_enforce2d>`
    * :doc:`eos/cv <fix_eos_cv>`
@@ -79,7 +77,6 @@ OPT.
    * :doc:`flow/gauss <fix_flow_gauss>`
    * :doc:`freeze (k) <fix_freeze>`
    * :doc:`gcmc <fix_gcmc>`
-   * :doc:`gjf <fix_gjf>`
    * :doc:`gld <fix_gld>`
    * :doc:`gle <fix_gle>`
    * :doc:`gravity (ko) <fix_gravity>`
@@ -87,14 +84,11 @@ OPT.
    * :doc:`halt <fix_halt>`
    * :doc:`heat <fix_heat>`
    * :doc:`heat/flow <fix_heat_flow>`
-   * :doc:`hmc <fix_hmc>`
    * :doc:`hyper/global <fix_hyper_global>`
    * :doc:`hyper/local <fix_hyper_local>`
    * :doc:`imd <fix_imd>`
    * :doc:`indent <fix_indent>`
    * :doc:`ipi <fix_ipi>`
-   * :doc:`lambda/apip <fix_lambda_apip>`
-   * :doc:`lambda_thermostat/apip <fix_lambda_thermostat_apip>`
    * :doc:`langevin (k) <fix_langevin>`
    * :doc:`langevin/drude <fix_langevin_drude>`
    * :doc:`langevin/eff <fix_langevin_eff>`
@@ -117,7 +111,6 @@ OPT.
    * :doc:`mvv/tdpd <fix_mvv_dpd>`
    * :doc:`neb <fix_neb>`
    * :doc:`neb/spin <fix_neb_spin>`
-   * :doc:`neighbor/swap <fix_neighbor_swap>`
    * :doc:`nonaffine/displacement <fix_nonaffine_displacement>`
    * :doc:`nph (ko) <fix_nh>`
    * :doc:`nph/asphere (o) <fix_nph_asphere>`
@@ -169,8 +162,6 @@ 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>`
@@ -193,7 +184,6 @@ OPT.
    * :doc:`qeq/fire <fix_qeq>`
    * :doc:`qeq/point <fix_qeq>`
    * :doc:`qeq/reaxff (ko) <fix_qeq_reaxff>`
-   * :doc:`qeq/rel/reaxff <fix_qeq_rel_reaxff>`
    * :doc:`qeq/shielded <fix_qeq>`
    * :doc:`qeq/slater <fix_qeq>`
    * :doc:`qmmm <fix_qmmm>`
@@ -223,7 +213,6 @@ OPT.
    * :doc:`rigid/small (o) <fix_rigid>`
    * :doc:`rx (k) <fix_rx>`
    * :doc:`saed/vtk <fix_saed_vtk>`
-   * :doc:`set <fix_set>`
    * :doc:`setforce (k) <fix_setforce>`
    * :doc:`setforce/spin <fix_setforce>`
    * :doc:`sgcmc <fix_sgcmc>`
@@ -245,6 +234,8 @@ OPT.
    * :doc:`srd <fix_srd>`
    * :doc:`store/force <fix_store_force>`
    * :doc:`store/state <fix_store_state>`
+   * :doc:`surface/global <fix_surface_global>`
+   * :doc:`surface/local <fix_surface_local>`
    * :doc:`tdpd/source <fix_dpd_source>`
    * :doc:`temp/berendsen (k) <fix_temp_berendsen>`
    * :doc:`temp/csld <fix_temp_csvr>`

doc/src/Commands_kspace.rst

@@ -31,5 +31,3 @@ OPT.
    * :doc:`pppm/dielectric <kspace_style>`
    * :doc:`pppm/electrode (i) <kspace_style>`
    * :doc:`scafacos <kspace_style>`
-   * :doc:`zero <kspace_style>`
-

doc/src/Commands_pair.rst

@@ -96,9 +96,7 @@ OPT.
    * :doc:`eam/cd <pair_eam>`
    * :doc:`eam/cd/old <pair_eam>`
    * :doc:`eam/fs (gikot) <pair_eam>`
-   * :doc:`eam/fs/apip <pair_eam_apip>`
    * :doc:`eam/he <pair_eam>`
-   * :doc:`eam/apip <pair_eam_apip>`
    * :doc:`edip (o) <pair_edip>`
    * :doc:`edip/multi <pair_edip>`
    * :doc:`edpd (g) <pair_mesodpd>`
@@ -117,18 +115,13 @@ 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>`
    * :doc:`ilp/tmd (t) <pair_ilp_tmd>`
    * :doc:`kolmogorov/crespi/full <pair_kolmogorov_crespi_full>`
    * :doc:`kolmogorov/crespi/z <pair_kolmogorov_crespi_z>`
-   * :doc:`lambda/input/apip <pair_lambda_input_apip>`
-   * :doc:`lambda/input/csp/apip <pair_lambda_input_apip>`
-   * :doc:`lambda/zone/apip <pair_lambda_zone_apip>`
    * :doc:`lcbop <pair_lcbop>`
    * :doc:`lebedeva/z <pair_lebedeva_z>`
    * :doc:`lennard/mdf <pair_mdf>`
@@ -184,7 +177,6 @@ OPT.
    * :doc:`lj/long/dipole/long <pair_dipole>`
    * :doc:`lj/long/tip4p/long (o) <pair_lj_long>`
    * :doc:`lj/mdf <pair_mdf>`
-   * :doc:`lj/pirani (o) <pair_lj_pirani>`
    * :doc:`lj/relres (o) <pair_lj_relres>`
    * :doc:`lj/spica (gko) <pair_spica>`
    * :doc:`lj/spica/coul/long (gko) <pair_spica>`
@@ -242,9 +234,6 @@ OPT.
    * :doc:`oxrna2/coaxstk <pair_oxrna2>`
    * :doc:`pace (k) <pair_pace>`
    * :doc:`pace/extrapolation (k) <pair_pace>`
-   * :doc:`pace/apip <pair_pace_apip>`
-   * :doc:`pace/fast/apip <pair_pace_apip>`
-   * :doc:`pace/precise/apip <pair_pace_apip>`
    * :doc:`pedone (o) <pair_pedone>`
    * :doc:`pod (k) <pair_pod>`
    * :doc:`peri/eps <pair_peri>`

doc/src/Commands_removed.rst

@@ -12,21 +12,10 @@ 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.
 
-GJF formulation in fix langevin
--------------------------------
-
-.. deprecated:: 12Jun2025
-
-The *gjf* keyword in fix langevin is deprecated and will be removed
-soon.  The GJF functionality has been moved to its own fix style
-:doc:`fix gjf <fix_gjf>` and it is strongly recommended to use that
-fix instead.
-
-
 LAMMPS shell
 ------------
 
-.. deprecated:: 29Aug2024
+.. versionchanged:: 29Aug2024
 
 The LAMMPS shell has been removed from the LAMMPS distribution. Users
 are encouraged to use the :ref:`LAMMPS-GUI <lammps_gui>` tool instead.
@@ -34,7 +23,7 @@ are encouraged to use the :ref:`LAMMPS-GUI <lammps_gui>` tool instead.
 i-PI tool
 ---------
 
-.. deprecated:: 27Jun2024
+.. versionchanged:: 27Jun2024
 
 The i-PI tool has been removed from the LAMMPS distribution.  Instead,
 instructions to install i-PI from PyPI via pip are provided.
@@ -98,7 +87,7 @@ 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
+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
@@ -181,18 +170,6 @@ performance characteristics on NVIDIA GPUs. Both, the KOKKOS
 and the :ref:`GPU package <PKG-GPU>` are maintained
 and allow running LAMMPS with GPU acceleration.
 
-Compute atom/molecule
----------------------
-
-.. deprecated:: 11 Dec2015
-
-The atom/molecule command has been removed from LAMMPS since it was superseded
-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.
-
 Fix ave/spatial and fix ave/spatial/sphere
 ------------------------------------------
 

doc/src/Developer.rst

@@ -24,5 +24,4 @@ of time and requests from the LAMMPS user community.
    Classes
    Developer_platform
    Developer_utils
-   Developer_internal
    Developer_grid

doc/src/Developer_code_design.rst

@@ -203,7 +203,6 @@ 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
@@ -301,24 +300,18 @@ Formatting with the {fmt} library
 
 The LAMMPS source code includes a copy of the `{fmt} library
 <https://fmt.dev>`_, which is preferred over formatting with the
-"printf()" family of functions.  The primary reason is that it allows a
-typesafe default format for any type of supported data.  This is
+"printf()" family of functions.  The primary reason is that it allows
+a typesafe default format for any type of supported data.  This is
 particularly useful for formatting integers of a given size (32-bit or
-64-bit) which may require different format strings depending on compile
-time settings or compilers/operating systems.  Furthermore, {fmt} gives
-better performance, has more functionality, a familiar formatting syntax
-that has similarities to ``format()`` in Python, and provides a facility
-that can be used to integrate format strings and a variable number of
-arguments into custom functions in a much simpler way than the varargs
-mechanism of the C library.  Finally, {fmt} has been included into the
-C++20 language standard as ``std::format()``, so changes to adopt it are
-future-proof, for as long as they are not using any extensions that are
-not (yet) included into C++.
-
-The long-term plan is to switch to using ``std::format()`` instead of
-``fmt::format()`` when the minimum C++ standard required for LAMMPS will
-be set to C++20. See the :ref:`basic build instructions <compile>` for
-more details.
+64-bit) which may require different format strings depending on
+compile time settings or compilers/operating systems.  Furthermore,
+{fmt} gives better performance, has more functionality, a familiar
+formatting syntax that has similarities to ``format()`` in Python, and
+provides a facility that can be used to integrate format strings and a
+variable number of arguments into custom functions in a much simpler
+way than the varargs mechanism of the C library.  Finally, {fmt} has
+been included into the C++20 language standard, so changes to adopt it
+are future-proof.
 
 Formatted strings are frequently created by calling the
 ``fmt::format()`` function, which will return a string as a
@@ -326,13 +319,11 @@ 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 :cpp:func:`utils::print() <LAMMPS_NS::utils::print>`
-function may be used instead of ``printf()`` or ``fprintf()``.  In
-addition, several LAMMPS output functions, that originally accepted a
-single string as argument have been overloaded to accept a format string
-with optional arguments as well (e.g., ``Error::all()``,
-``Error::one()``, :cpp:func:`utils::logmesg()
-<LAMMPS_NS::utils::logmesg>`).
+Otherwise, the ``fmt::print()`` function may be used instead of
+``printf()`` or ``fprintf()``.  In addition, several LAMMPS output
+functions, that originally accepted a single string as argument have
+been overloaded to accept a format string with optional arguments as
+well (e.g., ``Error::all()``, ``Error::one()``, ``utils::logmesg()``).
 
 Summary of the {fmt} format syntax
 ==================================

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/chunk fixes.  The final operation of the
+e.g. the ave/time and ave/spatial fixes.  The final operation of the
 timestep is to perform any requested output, via the ``write()`` method
 of the Output class.  There are 3 kinds of LAMMPS output: thermodynamic
 output to the screen and log file, snapshots of atom data to a dump

doc/src/Developer_internal.rst

@@ -1,120 +0,0 @@
-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
-^^^^^^^^^^^^^^^^^^^
-
-These provide an implementation of features that would otherwise have
-been replicated across multiple styles.  The used fix ID is generally
-derived from the compute or fix ID creating the fix with some string
-appended.  When needed, the fix can be looked up with
-``Modify::get_fix_by_id()``, which returns a pointer to the fix
-instance.  The data managed by the fix can be accessed just as for other
-fixes that can be used in input files.
-
-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 the intended fix through 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

doc/src/Developer_notes.rst

@@ -7,7 +7,13 @@ 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.
 
-.. contents:: Available notes
+Available topics are:
+
+- `Reading and parsing of text and text files`_
+- `Requesting and accessing neighbor lists`_
+- `Choosing between a custom atom style, fix property/atom, and fix STORE/ATOM`_
+- `Fix contributions to instantaneous energy, virial, and cumulative energy`_
+- `KSpace PPPM FFT grids`_
 
 ----
 
@@ -212,149 +218,6 @@ 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
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 

doc/src/Developer_plugins.rst

@@ -68,25 +68,24 @@ Members of ``lammpsplugin_t``
    * - author
      - String with the name and email of the author
    * - creator.v1
-     - Pointer to factory function for pair, bond, angle, dihedral, improper, kspace, command, or minimize styles
+     - Pointer to factory function for pair, bond, angle, dihedral, improper, kspace, or command styles
    * - creator.v2
-     - Pointer to factory function for compute, fix, region, or run styles
+     - Pointer to factory function for compute, fix, or region styles
    * - handle
      - Pointer to the open DSO file handle
 
 Only one of the two alternate creator entries can be used at a time and
 which of those is determined by the style of plugin. The "creator.v1"
 element is for factory functions of supported styles computing forces
-(i.e. pair, bond, angle, dihedral, or improper styles), command styles,
-or minimize styles and the function takes as single argument the pointer
-to the LAMMPS instance. The factory function is cast to the
-``lammpsplugin_factory1`` type before assignment.  The "creator.v2"
-element is for factory functions creating an instance of a fix, compute,
-region, or run style and takes three arguments: a pointer to the LAMMPS
-instance, an integer with the length of the argument list and a ``char
-**`` pointer to the list of arguments. The factory function pointer
-needs to be cast to the ``lammpsplugin_factory2`` type before
-assignment.
+(i.e. pair, bond, angle, dihedral, or improper styles) or command styles
+and the function takes as single argument the pointer to the LAMMPS
+instance. The factory function is cast to the ``lammpsplugin_factory1``
+type before assignment.  The "creator.v2" element is for factory
+functions creating an instance of a fix, compute, or region style and
+takes three arguments: a pointer to the LAMMPS instance, an integer with
+the length of the argument list and a ``char **`` pointer to the list of
+arguments. The factory function pointer needs to be cast to the
+``lammpsplugin_factory2`` type before assignment.
 
 Pair style example
 ^^^^^^^^^^^^^^^^^^
@@ -248,8 +247,8 @@ DSO handle.  The registration function is called with a pointer to the address
 of this struct and the pointer of the LAMMPS class.  The registration function
 will then add the factory function of the plugin style to the respective
 style map under the provided name.  It will also make a copy of the struct
-in a global list of all loaded plugins and update the reference counter for
-loaded plugins from this specific DSO file.
+in a list of all loaded plugins and update the reference counter for loaded
+plugins from this specific DSO file.
 
 The pair style itself (i.e. the PairMorse2 class in this example) can be
 written just like any other pair style that is included in LAMMPS.  For
@@ -264,21 +263,6 @@ the plugin will override the existing code.  This can be used to modify
 the behavior of existing styles or to debug new versions of them without
 having to re-compile or re-install all of LAMMPS.
 
-.. versionchanged:: 12Jun2025
-
-When using the :doc:`clear <clear>` command, plugins are not unloaded
-but restored to their respective style maps.  This also applies when
-multiple LAMMPS instances are created and deleted through the library
-interface.  The :doc:`plugin load <plugin>` load command may be issued
-again, but for existing plugins they will be skipped.  To replace
-plugins they must be explicitly unloaded with :doc:`plugin unload
-<plugin>`.  When multiple LAMMPS instances are created concurrently, any
-loaded plugins will be added to the global list of plugins, but are not
-immediately available to any LAMMPS instance that was created before
-loading the plugin.  To "import" such plugins, the :doc:`plugin restore
-<plugin>` may be used.  Plugins are only removed when they are explicitly
-unloaded or the LAMMPS interface is "finalized".
-
 Compiling plugins
 ^^^^^^^^^^^^^^^^^
 

doc/src/Developer_updating.rst

@@ -29,8 +29,6 @@ Available topics in mostly chronological order are:
 - `Rename of fix STORE/PERATOM to fix STORE/ATOM and change of arguments`_
 - `Use Output::get_dump_by_id() instead of Output::find_dump()`_
 - `Refactored grid communication using Grid3d/Grid2d classes instead of GridComm`_
-- `FLERR as first argument to minimum image functions in Domain class`_
-- `Use utils::logmesg() instead of error->warning()`_
 
 ----
 
@@ -612,71 +610,3 @@ KSpace solvers which use distributed FFT grids:
 - ``src/KSPACE/pppm.cpp``
 
 This change is **required** or else the code will not compile.
-
-FLERR as first argument to minimum image functions in Domain class
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. versionchanged:: 12Jun2025
-
-The ``Domain::minimum_image()`` and ``Domain::minimum_image_big()``
-functions were changed to take the ``FLERR`` macros as first argument.
-This way the error message indicates *where* the function was called
-instead of pointing to the implementation of the function.  Example:
-
-Old:
-
-.. code-block:: c++
-
-   double delx1 = x[i1][0] - x[i2][0];
-   double dely1 = x[i1][1] - x[i2][1];
-   double delz1 = x[i1][2] - x[i2][2];
-   domain->minimum_image(delx1, dely1, delz1);
-   double r1 = sqrt(delx1 * delx1 + dely1 * dely1 + delz1 * delz1);
-
-   double delx2 = x[i3][0] - x[i2][0];
-   double dely2 = x[i3][1] - x[i2][1];
-   double delz2 = x[i3][2] - x[i2][2];
-   domain->minimum_image_big(delx2, dely2, delz2);
-   double r2 = sqrt(delx2 * delx2 + dely2 * dely2 + delz2 * delz2);
-
-New:
-
-.. code-block:: c++
-
-   double delx1 = x[i1][0] - x[i2][0];
-   double dely1 = x[i1][1] - x[i2][1];
-   double delz1 = x[i1][2] - x[i2][2];
-   domain->minimum_image(FLERR, delx1, dely1, delz1);
-   double r1 = sqrt(delx1 * delx1 + dely1 * dely1 + delz1 * delz1);
-
-   double delx2 = x[i3][0] - x[i2][0];
-   double dely2 = x[i3][1] - x[i2][1];
-   double delz2 = x[i3][2] - x[i2][2];
-   domain->minimum_image_big(FLERR, delx2, dely2, delz2);
-   double r2 = sqrt(delx2 * delx2 + dely2 * dely2 + delz2 * delz2);
-
-This change is **required** or else the code will not compile.
-
-Use utils::logmesg() instead of error->warning()
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. versionchanged:: TBD
-
-The ``Error::message()`` method has been removed since its functionality
-has been superseded by the :cpp:func:`utils::logmesg` function.
-
-Old:
-
-.. code-block:: c++
-
-   if (comm->me == 0) {
-     error->message(FLERR, "INFO: About to read data file: {}", filename);
-  }
-
-New:
-
-.. code-block:: c++
-
-   if (comm->me == 0) utils::logmesg(lmp, "INFO: About to read data file: {}\n", filename);
-
-This change is **required** or else the code will not compile.

doc/src/Developer_utils.rst

@@ -133,9 +133,6 @@ and parsing files or arguments.
 .. doxygenfunction:: trim_comment
    :project: progguide
 
-.. doxygenfunction:: strcompress
-   :project: progguide
-
 .. doxygenfunction:: strip_style_suffix
    :project: progguide
 
@@ -169,9 +166,6 @@ and parsing files or arguments.
 .. doxygenfunction:: split_lines
    :project: progguide
 
-.. doxygenfunction:: strsame
-   :project: progguide
-
 .. doxygenfunction:: strmatch
    :project: progguide
 
@@ -238,21 +232,12 @@ 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
 

doc/src/Developer_write_fix.rst

@@ -96,8 +96,8 @@ 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) {
-       utils::print(screen, "{}, {}, {}\n",
-                    globalAvgVel[0], globalAvgVel[1], globalAvgVel[2]);
+       fmt::print(screen,"{}, {}, {}\n",
+                  globalAvgVel[0], globalAvgVel[1], globalAvgVel[2]);
      }
    }
 

doc/src/Errors_common.rst

@@ -1,149 +1,124 @@
-Common issues that are often regarded as bugs
-=============================================
+Common problems
+===============
 
-The list below are some random notes on behavior of LAMMPS that is
-sometimes unexpected or even considered a bug.  Most of the time, these
-are just issues of understanding how LAMMPS is implemented and
-parallelized.  Please also have a look at the :doc:`Error details
-discussions page <Errors_details>` that contains recommendations for
-tracking down issues and explanations for error messages that may
-sometimes be confusing or need additional explanations.
+If two LAMMPS runs do not produce the exact same answer on different
+machines or different numbers of processors, this is typically not a
+bug.  In theory you should get identical answers on any number of
+processors and on any machine.  In practice, numerical round-off can
+cause slight differences and eventual divergence of molecular dynamics
+phase space trajectories within a few 100s or few 1000s of timesteps.
+However, the statistical properties of the two runs (e.g. average
+energy or temperature) should still be the same.
 
-- A LAMMPS simulation typically has two stages, 1) issuing commands
-  and 2) run or minimize.  Most LAMMPS errors are detected in stage 1),
-  others at the beginning of stage 2), and finally others like a bond
-  stretching too far may or lost atoms or bonds may not occur until the
-  middle of a run.
+If the :doc:`velocity <velocity>` command is used to set initial atom
+velocities, a particular atom can be assigned a different velocity
+when the problem is run on a different number of processors or on
+different machines.  If this happens, the phase space trajectories of
+the two simulations will rapidly diverge.  See the discussion of the
+*loop* option in the :doc:`velocity <velocity>` command for details and
+options that avoid this issue.
 
-- If two LAMMPS runs do not produce the exact same answer on different
-  machines or different numbers of processors, this is typically not a
-  bug.  In theory you should get identical answers on any number of
-  processors and on any machine.  In practice, numerical round-off can
-  cause slight differences and eventual divergence of molecular dynamics
-  phase space trajectories within a few 100s or few 1000s of timesteps.
-  This can be triggered by different ordering of atoms due to different
-  domain decompositions, but also through different CPU architectures,
-  different operating systems, different compilers or compiler versions,
-  different compiler optimization levels, different FFT libraries.
-  However, the statistical properties of the two runs (e.g. average
-  energy or temperature) should still be the same.
+Similarly, the :doc:`create_atoms <create_atoms>` command generates a
+lattice of atoms.  For the same physical system, the ordering and
+numbering of atoms by atom ID may be different depending on the number
+of processors.
 
-- If the :doc:`velocity <velocity>` command is used to set initial atom
-  velocities, a particular atom can be assigned a different velocity
-  when the problem is run on a different number of processors or on
-  different machines.  If this happens, the phase space trajectories of
-  the two simulations will rapidly diverge.  See the discussion of the
-  *loop* option in the :doc:`velocity <velocity>` command for details
-  and options that avoid this issue.
+Some commands use random number generators which may be setup to
+produce different random number streams on each processor and hence
+will produce different effects when run on different numbers of
+processors.  A commonly-used example is the :doc:`fix langevin <fix_langevin>` command for thermostatting.
 
-- Similarly, the :doc:`create_atoms <create_atoms>` command generates a
-  lattice of atoms.  For the same physical system, the ordering and
-  numbering of atoms by atom ID may be different depending on the number
-  of processors.
+A LAMMPS simulation typically has two stages, setup and run.  Most
+LAMMPS errors are detected at setup time; others like a bond
+stretching too far may not occur until the middle of a run.
 
-- Some commands use random number generators which may be setup to
-  produce different random number streams on each processor and hence
-  will produce different effects when run on different numbers of
-  processors.  A commonly-used example is the :doc:`fix langevin
-  <fix_langevin>` command for thermostatting.
+LAMMPS tries to flag errors and print informative error messages so
+you can fix the problem.  For most errors it will also print the last
+input script command that it was processing.  Of course, LAMMPS cannot
+figure out your physics or numerical mistakes, like choosing too big a
+timestep, specifying erroneous force field coefficients, or putting 2
+atoms on top of each other!  If you run into errors that LAMMPS
+does not catch that you think it should flag, please send an email to
+the `developers <https://www.lammps.org/authors.html>`_ or create an new
+topic on the dedicated `MatSci forum section <https://matsci.org/lammps/>`_.
 
-- LAMMPS tries to flag errors and print informative error messages so
-  you can fix the problem.  For most errors it will also print the last
-  input script command that it was processing or even point to the
-  keyword that is causing troubles.  Of course, LAMMPS cannot figure out
-  your physics or numerical mistakes, like choosing too big a timestep,
-  specifying erroneous force field coefficients, or putting 2 atoms on
-  top of each other!  Also, LAMMPS does not know what you *intend* to
-  do, but very strictly applies the syntax as described in the
-  documentation.  If you run into errors that LAMMPS does not catch that
-  you think it should flag, please send an email to the `developers
-  <https://www.lammps.org/authors.html>`_ or create an new topic on the
-  dedicated `MatSci forum section <https://matsci.org/lammps/>`_.
+If you get an error message about an invalid command in your input
+script, you can determine what command is causing the problem by
+looking in the log.lammps file or using the :doc:`echo command <echo>`
+to see it on the screen.  If you get an error like "Invalid ...
+style", with ... being fix, compute, pair, etc, it means that you
+mistyped the style name or that the command is part of an optional
+package which was not compiled into your executable.  The list of
+available styles in your executable can be listed by using
+:doc:`the -h command-line switch <Run_options>`.  The installation and
+compilation of optional packages is explained on the
+:doc:`Build packages <Build_package>` doc page.
 
-- If you get an error message about an invalid command in your input
-  script, you can determine what command is causing the problem by
-  looking in the log.lammps file or using the :doc:`echo command <echo>`
-  to see it on the screen.  If you get an error like "Invalid ...
-  style", with ... being fix, compute, pair, etc, it means that you
-  mistyped the style name or that the command is part of an optional
-  package which was not compiled into your executable.  The list of
-  available styles in your executable can be listed by using
-  :doc:`the -h command-line switch <Run_options>`.  The installation and
-  compilation of optional packages is explained on the :doc:`Build
-  packages <Build_package>` doc page.
+For a given command, LAMMPS expects certain arguments in a specified
+order.  If you mess this up, LAMMPS will often flag the error, but it
+may also simply read a bogus argument and assign a value that is
+valid, but not what you wanted.  E.g. trying to read the string "abc"
+as an integer value of 0.  Careful reading of the associated doc page
+for the command should allow you to fix these problems. In most cases,
+where LAMMPS expects to read a number, either integer or floating point,
+it performs a stringent test on whether the provided input actually
+is an integer or floating-point number, respectively, and reject the
+input with an error message (for instance, when an integer is required,
+but a floating-point number 1.0 is provided):
 
-- For a given command, LAMMPS expects certain arguments in a specified
-  order.  If you mess this up, LAMMPS will often flag the error, but it
-  may also simply read a bogus argument and assign a value that is
-  valid, but not what you wanted.  E.g. trying to read the string "abc"
-  as an integer value of 0.  Careful reading of the associated doc page
-  for the command should allow you to fix these problems. In most cases,
-  where LAMMPS expects to read a number, either integer or floating
-  point, it performs a stringent test on whether the provided input
-  actually is an integer or floating-point number, respectively, and
-  reject the input with an error message (for instance, when an integer
-  is required, but a floating-point number 1.0 is provided):
+.. parsed-literal::
 
-  .. parsed-literal::
+   ERROR: Expected integer parameter instead of '1.0' in input script or data file
 
-     ERROR: Expected integer parameter instead of '1.0' in input script or data file
+Some commands allow for using variable references in place of numeric
+constants so that the value can be evaluated and may change over the
+course of a run.  This is typically done with the syntax *v_name* for a
+parameter, where name is the name of the variable. On the other hand,
+immediate variable expansion with the syntax ${name} is performed while
+reading the input and before parsing commands,
 
-- Some commands allow for using variable references in place of numeric
-  constants so that the value can be evaluated and may change over the
-  course of a run.  This is typically done with the syntax *v_name* for
-  a parameter, where name is the name of the variable. On the other
-  hand, immediate variable expansion with the syntax ${name} is
-  performed while reading the input and before parsing commands,
+.. note::
 
-  .. note::
+   Using a variable reference (i.e. *v_name*) is only allowed if
+   the documentation of the corresponding command explicitly says it is.
+   Otherwise, you will receive an error message of this kind:
 
-     Using a variable reference (i.e. *v_name*) is only allowed if
-     the documentation of the corresponding command explicitly says it is.
-     Otherwise, you will receive an error message of this kind:
+.. parsed-literal::
 
-  .. parsed-literal::
+   ERROR: Expected floating point parameter instead of 'v_name' in input script or data file
 
-     ERROR: Expected floating point parameter instead of 'v_name' in input script or data file
+Generally, LAMMPS will print a message to the screen and logfile and
+exit gracefully when it encounters a fatal error.  Sometimes it will
+print a WARNING to the screen and logfile and continue on; you can
+decide if the WARNING is important or not.  A WARNING message that is
+generated in the middle of a run is only printed to the screen, not to
+the logfile, to avoid cluttering up thermodynamic output.  If LAMMPS
+crashes or hangs without spitting out an error message first then it
+could be a bug (see :doc:`this section <Errors_bugs>`) or one of the following
+cases:
 
-- Generally, LAMMPS will print a message to the screen and logfile and
-  exit gracefully when it encounters a fatal error.  When running in
-  parallel this message may be stuck in an I/O buffer and LAMMPS will be
-  terminated before that buffer is printed.  In that case you can try
-  adding the ``-nonblock`` or ``-nb`` command-line flag to turn off that
-  buffering.  Please note that this should not be used for production
-  runs, since turning off buffering usually has a significant negative
-  impact on performance (even worse than :doc:`thermo_modify flush yes
-  <thermo_modify>`).  Sometimes LAMMPS will print a WARNING to the
-  screen and logfile and continue on; you can decide if the WARNING is
-  important or not, but as a general rule do not ignore warnings that
-  you not understand.  A WARNING message that is generated in the middle
-  of a run is only printed to the screen, not to the logfile, to avoid
-  cluttering up thermodynamic output.  If LAMMPS crashes or hangs
-  without generating an error message first then it could be a bug
-  (see :doc:`this section <Errors_bugs>`).
+LAMMPS runs in the available memory a processor allows to be
+allocated.  Most reasonable MD runs are compute limited, not memory
+limited, so this should not be a bottleneck on most platforms.  Almost
+all large memory allocations in the code are done via C-style malloc's
+which will generate an error message if you run out of memory.
+Smaller chunks of memory are allocated via C++ "new" statements.  If
+you are unlucky you could run out of memory just when one of these
+small requests is made, in which case the code will crash or hang (in
+parallel), since LAMMPS does not trap on those errors.
 
-- LAMMPS runs in the available memory a processor allows to be
-  allocated.  Most reasonable MD runs are compute limited, not memory
-  limited, so this should not be a bottleneck on most platforms.  Almost
-  all large memory allocations in the code are done via C-style malloc's
-  which will generate an error message if you run out of memory.
-  Smaller chunks of memory are allocated via C++ "new" statements.  If
-  you are unlucky you could run out of memory just when one of these
-  small requests is made, in which case the code will crash or hang (in
-  parallel).
+Illegal arithmetic can cause LAMMPS to run slow or crash.  This is
+typically due to invalid physics and numerics that your simulation is
+computing.  If you see wild thermodynamic values or NaN values in your
+LAMMPS output, something is wrong with your simulation.  If you
+suspect this is happening, it is a good idea to print out
+thermodynamic info frequently (e.g. every timestep) via the
+:doc:`thermo <thermo>` so you can monitor what is happening.
+Visualizing the atom movement is also a good idea to ensure your model
+is behaving as you expect.
 
-- Illegal arithmetic can cause LAMMPS to run slow or crash.  This is
-  typically due to invalid physics and numerics that your simulation is
-  computing.  If you see wild thermodynamic values or NaN values in your
-  LAMMPS output, something is wrong with your simulation.  If you
-  suspect this is happening, it is a good idea to print out
-  thermodynamic info frequently (e.g. every timestep) via the
-  :doc:`thermo <thermo>` so you can monitor what is happening.
-  Visualizing the atom movement is also a good idea to ensure your model
-  is behaving as you expect.
-
-- When running in parallel with MPI, one way LAMMPS can hang is because
-  LAMMPS has come across an error condition, but only on one or a few
-  MPI processes and not all of them.  LAMMPS has two different "stop
-  with an error message" functions and the correct one has to be called
-  or else it will hang.
+In parallel, one way LAMMPS can hang is due to how different MPI
+implementations handle buffering of messages.  If the code hangs
+without an error message, it may be that you need to specify an MPI
+setting or two (usually via an environment variable) to enable
+buffering or boost the sizes of messages that can be buffered.

doc/src/Errors_warnings.rst

@@ -1,15 +1,11 @@
 Warning messages
 ================
 
-This is an alphabetic list of some of the WARNING messages LAMMPS prints
-out and the reason why.  If the explanation here is not sufficient, the
-documentation for the offending command may help.  This is a historic
-list and no longer updated.  Instead the LAMMPS developers are trying
-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:
+This is an alphabetic list of the WARNING messages LAMMPS prints out
+and the reason why.  If the explanation here is not sufficient, the
+documentation for the offending command may help.  Warning messages
+also list the source file and line number where the warning was
+generated.  For example, a message like this:
 
 .. parsed-literal::
 
@@ -18,7 +14,7 @@ warning was 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.
 
-Please also see the page with :doc:`Error messages <Errors_messages>`
+Doc page with :doc:`ERROR messages <Errors_messages>`
 
 ----------
 
@@ -32,10 +28,16 @@ Please also see the 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
@@ -51,6 +53,9 @@ Please also see the 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.
@@ -63,6 +68,9 @@ Please also see the 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
@@ -78,6 +86,18 @@ Please also see the 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
@@ -103,6 +123,9 @@ Please also see the 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.
@@ -135,6 +158,9 @@ Please also see the 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.
@@ -151,6 +177,9 @@ Please also see the 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.
@@ -163,6 +192,9 @@ Please also see the 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.
 
@@ -206,12 +238,21 @@ Please also see the 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.
@@ -244,6 +285,9 @@ Please also see the 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
@@ -266,14 +310,46 @@ Please also see the 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.
@@ -325,10 +401,20 @@ Please also see the 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.
@@ -363,6 +449,9 @@ Please also see the 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.
 
@@ -375,6 +464,24 @@ Please also see the 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.
 
@@ -450,12 +557,21 @@ Please also see the 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
@@ -565,6 +681,9 @@ Please also see the 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.
 
@@ -575,9 +694,15 @@ Please also see the 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.
@@ -609,6 +734,9 @@ Please also see the 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.
@@ -617,6 +745,9 @@ Please also see the 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.
@@ -644,6 +775,24 @@ Please also see the 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.
 

doc/src/Examples.rst

@@ -54,7 +54,7 @@ Lowercase directories
 +-------------+------------------------------------------------------------------+
 | body        | body particles, 2d system                                        |
 +-------------+------------------------------------------------------------------+
-| bpm         | simulations of solid elastic/plastic deformation and fracture    |
+| bpm         | BPM simulations of pouring elastic grains and plate impact       |
 +-------------+------------------------------------------------------------------+
 | cmap        | CMAP 5-body contributions to CHARMM force field                  |
 +-------------+------------------------------------------------------------------+

doc/src/Fortran.rst

@@ -69,11 +69,10 @@ statement.  Internally, it will call either
 :cpp:func:`lammps_open_fortran` or :cpp:func:`lammps_open_no_mpi` from
 the C library API to create the class instance.  All arguments are
 optional and :cpp:func:`lammps_mpi_init` will be called automatically
-if it is needed.  Similarly, optional calls to
-:cpp:func:`lammps_mpi_finalize`, :cpp:func:`lammps_kokkos_finalize`,
-:cpp:func:`lammps_python_finalize`, and :cpp:func:`lammps_plugin_finalize`
-are integrated into the :f:func:`close` function and triggered with the
-optional logical argument set to ``.TRUE.``. Here is a simple example:
+if it is needed.  Similarly, a possible call to
+:cpp:func:`lammps_mpi_finalize` is integrated into the :f:func:`close`
+function and triggered with the optional logical argument set to
+``.TRUE.``. Here is a simple example:
 
 .. code-block:: fortran
 
@@ -324,12 +323,6 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
    :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`
@@ -522,8 +515,8 @@ Procedures Bound to the :f:type:`lammps` Derived Type
    This method will close down the LAMMPS instance through calling
    :cpp:func:`lammps_close`.  If the *finalize* argument is present and
    has a value of ``.TRUE.``, then this subroutine also calls
-   :cpp:func:`lammps_kokkos_finalize`, :cpp:func:`lammps_mpi_finalize`,
-   :cpp:func:`lammps_python_finalize`, and :cpp:func:`lammps_plugin_finalize`.
+   :cpp:func:`lammps_kokkos_finalize` and
+   :cpp:func:`lammps_mpi_finalize`.
 
    :o finalize: shut down the MPI environment of the LAMMPS
     library if ``.TRUE.``.
@@ -531,8 +524,6 @@ Procedures Bound to the :f:type:`lammps` Derived Type
    :to: :cpp:func:`lammps_close`
    :to: :cpp:func:`lammps_mpi_finalize`
    :to: :cpp:func:`lammps_kokkos_finalize`
-   :to: :cpp:func:`lammps_python_finalize`
-   :to: :cpp:func:`lammps_plugin_finalize`
 
 --------
 
@@ -965,7 +956,6 @@ 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
@@ -1078,7 +1068,6 @@ 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
@@ -1337,7 +1326,6 @@ 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
@@ -1462,62 +1450,11 @@ 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 real(c_double) val:  new value to assign to the variable
+   :p read(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
@@ -2099,7 +2036,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type
 
 --------
 
-.. f:function:: create_atoms([id,] type, x, [v,] [image,] [bexpand])
+.. f:subroutine:: create_atoms([id,] type, x, [v,] [image,] [bexpand])
 
    This method calls :cpp:func:`lammps_create_atoms` to create additional atoms
    from a given list of coordinates and a list of atom types. Additionally,
@@ -2128,8 +2065,6 @@ Procedures Bound to the :f:type:`lammps` Derived Type
     will be created, not dropped, and the box dimensions will be extended.
     Default is ``.FALSE.``
    :otype bexpand: logical,optional
-   :r atoms: number of created atoms
-   :rtype atoms: integer(c_int)
    :to: :cpp:func:`lammps_create_atoms`
 
    .. note::
@@ -2154,18 +2089,6 @@ Procedures Bound to the :f:type:`lammps` Derived Type
 
 --------
 
-.. f:subroutine:: create_molecule(id, jsonstr)
-
-   Add molecule template from string with JSON data
-
-   .. versionadded:: TBD
-
-   :p character(len=\*) id: desired molecule-ID
-   :p character(len=\*) jsonstr: string with JSON data defining the molecule template
-   :to: :cpp:func:`lammps_create_molecule`
-
---------
-
 .. f:function:: find_pair_neighlist(style[, exact][, nsub][, reqid])
 
    Find index of a neighbor list requested by a pair style.
@@ -2790,7 +2713,8 @@ Procedures Bound to the :f:type:`lammps` Derived Type
         END SUBROUTINE external_callback
       END INTERFACE
 
-   where ``c_bigint`` is ``c_int64_t`` and ``c_tagint`` is ``c_int64_t`` if
+   where ``c_bigint`` is ``c_int`` if ``-DLAMMPS_SMALLSMALL`` was used and
+   ``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

doc/src/Howto.rst

@@ -23,7 +23,6 @@ General howto
    Howto_library
    Howto_couple
    Howto_mdi
-   Howto_broken_bonds
 
 Settings howto
 ==============
@@ -40,7 +39,6 @@ Settings howto
    Howto_walls
    Howto_nemd
    Howto_dispersion
-   Howto_bulk2slab
 
 Analysis howto
 ==============
@@ -50,6 +48,7 @@ Analysis howto
    :maxdepth: 1
 
    Howto_output
+   Howto_structured_data
    Howto_chunk
    Howto_grid
    Howto_temperature
@@ -57,7 +56,6 @@ Analysis howto
    Howto_kappa
    Howto_viscosity
    Howto_diffusion
-   Howto_structured_data
 
 Force fields howto
 ==================
@@ -66,7 +64,7 @@ Force fields howto
    :name: force_howto
    :maxdepth: 1
 
-   Howto_FFgeneral
+   Howto_broken_bonds
    Howto_bioFF
    Howto_amoeba
    Howto_tip3p
@@ -83,6 +81,7 @@ Packages howto
 
    Howto_spherical
    Howto_granular
+   Howto_granular_surfaces
    Howto_body
    Howto_bpm
    Howto_polarizable
@@ -93,7 +92,6 @@ Packages howto
    Howto_manifold
    Howto_rheo
    Howto_spins
-   Howto_apip
 
 Tutorials howto
 ===============

doc/src/Howto_FFgeneral.rst

@@ -1,55 +0,0 @@
-Some general force field considerations
-=======================================
-
-A compact summary of the concepts, definitions, and properties of force
-fields with explicit bonded interactions (like the ones discussed in
-this HowTo) is given in :ref:`(Gissinger) <Typelabel2>`.
-
-A force field has 2 parts: the formulas that define its potential
-functions and the coefficients used for a particular system.  To assign
-parameters it is first required to assign atom types.  Those are not
-only based on the elements, but also on the chemical environment due to
-the atoms bound to them.  This often follows the chemical concept of
-*functional groups*.  Example: a carbon atom bound with a single bond to
-a single OH-group (alcohol) would be a different atom type than a carbon
-atom bound to a methyl CH3 group (aliphatic carbon).  The atom types
-usually then determine the non-bonded Lennard-Jones parameters and the
-parameters for bonds, angles, dihedrals, and impropers.  On top of that,
-partial charges have to be applied.  Those are usually independent of
-the atom types and are determined either for groups of atoms called
-residues with some fitting procedure based on quantum mechanical
-calculations, or based on some increment system that add or subtract
-increments from the partial charge of an atom based on the types of
-the neighboring atoms.
-
-Force fields differ in the strategies they employ to determine the
-parameters and charge distribution in how generic or specific they are
-which in turn has an impact on the accuracy (compare for example
-CGenFF to CHARMM and GAFF to Amber).  Because of the different
-strategies, it is not a good idea to use a mix of parameters from
-different force field *families* (like CHARMM, Amber, or GROMOS)
-and that extends to the parameters for the solvent, especially
-water.  The publication describing the parameterization of a force
-field will describe which water model to use.  Changing the water
-model usually leads to overall worse results (even if it may improve
-on the water itself).
-
-In addition, one has to consider that *families* of force fields like
-CHARMM, Amber, OPLS, or GROMOS have evolved over time and thus provide
-different *revisions* of the force field parameters.  These often
-corresponds to changes in the functional form or the parameterization
-strategies.  This may also result in changes required for simulation
-settings like the preferred cutoff or how Coulomb interactions are
-computed (cutoff, smoothed/shifted cutoff, or long-range with Ewald
-summation or equivalent).  Unless explicitly stated in the publication
-describing the force field, the Coulomb interaction cannot be chosen at
-will but must match the revision of the force field.  That said,
-liberties may be taken during the initial equilibration of a system to
-speed up the process, but not for production simulations.
-
-----------
-
-.. _Typelabel2:
-
-**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).
-

doc/src/Howto_apip.rst

@@ -1,225 +0,0 @@
-Adaptive-precision interatomic potentials (APIP)
-================================================
-
-The :ref:`PKG-APIP <PKG-APIP>` enables use of adaptive-precision potentials
-as described in :ref:`(Immel) <Immel2025_1>`.
-In the context of this package, precision refers to the accuracy of an interatomic
-potential.
-
-Modern machine-learning (ML) potentials translate the accuracy of DFT
-simulations into MD simulations, i.e., ML potentials are more accurate
-compared to traditional empirical potentials.
-However, this accuracy comes at a cost: there is a considerable performance
-gap between the evaluation of classical and ML potentials, e.g., the force
-calculation of a classical EAM potential is 100-1000 times faster compared
-to the ML-based ACE method.
-The evaluation time difference results in a conflict between large time and
-length scales on the one hand and accuracy on the other.
-This conflict is resolved by an APIP model for simulations, in which the highest precision
-is required only locally but not globally.
-
-An APIP model uses a precise but
-expensive ML potential only for a subset of atoms, while a fast
-potential is used for the remaining atoms.
-Whether the precise or the fast potential is used is determined
-by a continuous switching parameter :math:`\lambda_i` that can be defined for each
-atom :math:`i`.
-The switching parameter can be adjusted dynamically during a simulation or
-kept constant as explained below.
-
-The potential energy :math:`E_i` of an atom :math:`i` described by an
-adaptive-precision
-interatomic potential is given by :ref:`(Immel) <Immel2025_1>`
-
-.. math::
-
-   E_i = \lambda_i E_i^\text{(fast)} + (1-\lambda_i) E_i^\text{(precise)},
-
-whereas :math:`E_i^\text{(fast)}` is the potential energy of atom :math:`i`
-according to a fast interatomic potential,
-:math:`E_i^\text{(precise)}` is the potential energy according to a precise
-interatomic potential and :math:`\lambda_i\in[0,1]` is the
-switching parameter that decides how the potential energies are weighted.
-
-Adaptive-precision saves computation time when the computation of the
-precise potential is not required for many atoms, i.e., when
-:math:`\lambda_i=1` applies for many atoms.
-
-The currently implemented potentials are:
-
-.. list-table::
-   :header-rows: 1
-
-   * - Fast potential
-     - Precise potential
-   * - :doc:`ACE <pair_pace_apip>`
-     - :doc:`ACE <pair_pace_apip>`
-   * - :doc:`EAM <pair_eam_apip>`
-     -
-
-In theory, any short-range potential can be used for an adaptive-precision
-interatomic potential. How to implement a new (fast or precise)
-adaptive-precision
-potential is explained in :ref:`here <implementing_new_apip_styles>`.
-
-The switching parameter :math:`\lambda_i` that combines the two potentials
-can be dynamically calculated during a
-simulation.
-Alternatively, one can set a constant switching parameter before the start
-of a simulation.
-To run a simulation with an adaptive-precision potential, one needs the
-following components:
-
-.. tabs::
-
-   .. tab:: dynamic switching parameter
-
-        #. :doc:`atom_style apip <atom_style>` so that the switching parameter :math:`\lambda_i` can be stored.
-        #. A fast potential: :doc:`eam/apip <pair_eam_apip>` or :doc:`pace/fast/apip <pair_pace_apip>`.
-        #. A precise potential: :doc:`pace/precise/apip <pair_pace_apip>`.
-        #. :doc:`pair_style lambda/input/apip  <pair_lambda_input_apip>` to calculate :math:`\lambda_i^\text{input}`, from which :math:`\lambda_i` is calculated.
-        #. :doc:`fix lambda/apip <fix_lambda_apip>` to calculate the switching parameter :math:`\lambda_i`.
-        #. :doc:`pair_style lambda/zone/apip <pair_lambda_zone_apip>` to calculate the spatial transition zone of the switching parameter.
-        #. :doc:`pair_style hybrid/overlay <pair_hybrid>` to combine the previously mentioned pair_styles.
-        #. :doc:`fix lambda_thermostat/apip <fix_lambda_thermostat_apip>` to conserve the energy when switching parameters change.
-        #. :doc:`fix atom_weight/apip <fix_atom_weight_apip>` to approximate the load caused by every atom, as the computations of the pair_styles are only required for a subset of atoms.
-        #. :doc:`fix balance <fix_balance>` to perform dynamic load balancing with the calculated load.
-
-   .. tab:: constant switching parameter
-
-        #. :doc:`atom_style apip <atom_style>` so that the switching parameter :math:`\lambda_i` can be stored.
-        #. A fast potential: :doc:`eam/apip <pair_eam_apip>` or :doc:`pace/fast/apip <pair_pace_apip>`.
-        #. A precise potential: :doc:`pace/precise/apip <pair_pace_apip>`.
-        #. :doc:`set <set>` command to set the switching parameter :math:`\lambda_i`.
-        #. :doc:`pair_style hybrid/overlay <pair_hybrid>` to combine the previously mentioned pair_styles.
-        #. :doc:`fix atom_weight/apip <fix_atom_weight_apip>` to approximate the load caused by every atom, as the computations of the pair_styles are only required for a subset of atoms.
-        #. :doc:`fix balance <fix_balance>` to perform dynamic load balancing with the calculated load.
-
-----------
-
-Example
-"""""""
-.. note::
-
-   How to select the values of the parameters of an adaptive-precision
-   interatomic potential is discussed in detail in :ref:`(Immel) <Immel2025_1>`.
-
-
-.. tabs::
-
-   .. tab:: dynamic switching parameter
-
-      Lines like these would appear in the input script:
-
-
-      .. code-block:: LAMMPS
-
-         atom_style apip
-         comm_style tiled
-
-         pair_style hybrid/overlay eam/fs/apip pace/precise/apip lambda/input/csp/apip fcc cutoff 5.0 lambda/zone/apip 12.0
-         pair_coeff * * eam/fs/apip Cu.eam.fs Cu
-         pair_coeff * * pace/precise/apip Cu.yace Cu
-         pair_coeff * * lambda/input/csp/apip
-         pair_coeff * * lambda/zone/apip
-
-         fix 2 all lambda/apip 2.5 3.0 time_averaged_zone 4.0 12.0 110 110 min_delta_lambda 0.01
-         fix 3 all lambda_thermostat/apip N_rescaling 200
-         fix 4 all atom_weight/apip 100 eam ace lambda/input lambda/zone all
-
-         variable myweight atom f_4
-
-         fix 5 all balance 100 1.1 rcb weight var myweight
-
-      First, the :doc:`atom_style apip <atom_style>` and the communication style are set.
-
-      .. note::
-         Note, that :doc:`comm_style <comm_style>` *tiled* is required for the style *rcb* of
-         :doc:`fix balance <fix_balance>`, but not for APIP.
-         However, the flexibility offered by the balancing style *rcb*, compared to the
-         balancing style *shift*, is advantageous for APIP.
-
-      An adaptive-precision EAM-ACE potential, for which the switching parameter
-      :math:`\lambda` is calculated from the CSP, is defined via
-      :doc:`pair_style hybrid/overlay <pair_hybrid>`.
-      The fixes ensure that the switching parameter is calculated, the energy conserved,
-      the weight for the load balancing calculated and the load-balancing itself is done.
-
-   .. tab:: constant switching parameter
-
-      Lines like these would appear in the input script:
-
-      .. code-block:: LAMMPS
-
-         atom_style apip
-         comm_style tiled
-
-         pair_style hybrid/overlay eam/fs/apip pace/precise/apip
-         pair_coeff * * eam/fs/apip Cu.eam.fs Cu
-         pair_coeff * * pace/precise/apip Cu.yace Cu
-
-         # calculate lambda somehow
-         variable lambda atom ...
-         set group all apip/lambda v_lambda
-
-         fix 4 all atom_weight/apip 100 eam ace lambda/input lambda/zone all
-
-         variable myweight atom f_4
-
-         fix 5 all balance 100 1.1 rcb weight var myweight
-
-      First, the :doc:`atom_style apip <atom_style>` and the communication style are set.
-
-      .. note::
-         Note, that :doc:`comm_style <comm_style>` *tiled* is required for the style *rcb* of
-         :doc:`fix balance <fix_balance>`, but not for APIP.
-         However, the flexibility offered by the balancing style *rcb*, compared to the
-         balancing style *shift*, is advantageous for APIP.
-
-      An adaptive-precision EAM-ACE potential is defined via
-      :doc:`pair_style hybrid/overlay <pair_hybrid>`.
-      The switching parameter :math:`\lambda_i` of the adaptive-precision
-      EAM-ACE potential is set via the :doc:`set command <set>`.
-      The parameter is not updated during the simulation.
-      Therefore, the potential is conservative.
-      The fixes ensure that the weight for the load balancing is calculated
-      and the load-balancing itself is done.
-
-----------
-
-.. _implementing_new_apip_styles:
-
-Implementing new APIP pair styles
-"""""""""""""""""""""""""""""""""
-
-One can introduce adaptive-precision to an existing pair style by modifying
-the original pair style.
-One should calculate the force
-:math:`F_i = - \nabla_i \sum_j E_j^\text{original}` for a fast potential or
-:math:`F_i = - (1-\nabla_i) \sum_j E_j^\text{original}` for a precise
-potential from the original potential
-energy :math:`E_j^\text{original}` to see where the switching parameter
-:math:`\lambda_i` needs to be introduced in the force calculation.
-The switching parameter :math:`\lambda_i` is known for all atoms :math:`i`
-in force calculation routine.
-One needs to introduce an abortion criterion based on :math:`\lambda_i` to
-ensure that all not required calculations are skipped and compute time can
-be saved.
-Furthermore, one needs to provide the number of calculations and measure the
-computation time.
-Communication within the force calculation needs to be prevented to allow
-effective load-balancing.
-With communication, the load balancer cannot balance few calculations of the
-precise potential on one processor with many computations of the fast
-potential on another processor.
-
-All changes in the pair_style pace/apip compared to the pair_style pace
-are annotated and commented.
-Thus, the pair_style pace/apip can serve as an example for the implementation
-of new adaptive-precision potentials.
-
-----------
-
-.. _Immel2025_1:
-
-**(Immel)** Immel, Drautz and Sutmann, J Chem Phys, 162, 114119 (2025)

doc/src/Howto_barostat.rst

@@ -10,21 +10,20 @@ 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>`.  Three
+Barostatting in LAMMPS is performed by :doc:`fixes <fix>`.  Two
 barostatting methods are currently available: Nose-Hoover (npt and
-nph), Berendsen, and various linear controllers in deform/pressure:
+nph) and Berendsen:
 
 * :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.  The fixes :doc:`nph <fix_nh>`, :doc:`press/berendsen <fix_press_berendsen>`, and :doc:`deform/pressure <fix_deform_pressure>`
-can be used in conjunction with any of the thermostatting fixes.
+it does no thermostatting.  Both :doc:`fix nph <fix_nh>` and :doc:`fix press/berendsen <fix_press_berendsen>` 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
@@ -45,9 +44,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>` and :doc:`fix deform/pressure <fix_deform_pressure>`
-   do NOT, so they should be used with one of the constant NVE fixes or with
-   one of the NVT fixes.
+   :doc:`Fix press/berendsen <fix_press_berendsen>` does NOT, so it should
+   be used with one of the constant NVE fixes or with one of the NVT
+   fixes.
 
 Thermodynamic output, which can be setup via the
 :doc:`thermo_style <thermo_style>` command, often includes pressure

doc/src/Howto_bioFF.rst

@@ -1,16 +1,22 @@
 CHARMM, AMBER, COMPASS, DREIDING, and OPLS force fields
 =======================================================
 
-Here we only discuss formulas implemented in LAMMPS that correspond to
-formulas commonly used in the CHARMM, AMBER, COMPASS, and DREIDING force
-fields.  Setting coefficients is done either from special sections in an
-input data file via the :doc:`read_data <read_data>` command or in the
-input script with commands like :doc:`pair_coeff <pair_coeff>` or
-:doc:`bond_coeff <bond_coeff>` and so on.  See the :doc:`Tools <Tools>`
-doc page for additional tools that can use CHARMM, AMBER, or Materials
-Studio generated files to assign force field coefficients and convert
-their output into LAMMPS input. LAMMPS input scripts can also be
-generated by `charmm-gui.org <https://charmm-gui.org/>`_.
+A compact summary of the concepts, definitions, and properties of
+force fields with explicit bonded interactions (like the ones discussed
+in this HowTo) is given in :ref:`(Gissinger) <Typelabel2>`.
+
+A force field has 2 parts: the formulas that define it and the
+coefficients used for a particular system.  Here we only discuss
+formulas implemented in LAMMPS that correspond to formulas commonly used
+in the CHARMM, AMBER, COMPASS, and DREIDING force fields.  Setting
+coefficients is done either from special sections in an input data file
+via the :doc:`read_data <read_data>` command or in the input script with
+commands like :doc:`pair_coeff <pair_coeff>` or :doc:`bond_coeff
+<bond_coeff>` and so on.  See the :doc:`Tools <Tools>` doc page for
+additional tools that can use CHARMM, AMBER, or Materials Studio
+generated files to assign force field coefficients and convert their
+output into LAMMPS input. LAMMPS input scripts can also be generated by
+`charmm-gui.org <https://charmm-gui.org/>`_.
 
 CHARMM and AMBER
 ----------------
@@ -197,11 +203,9 @@ rather than individual force constants and geometric parameters that
 depend on the particular combinations of atoms involved in the bond,
 angle, or torsion terms.  DREIDING has an :doc:`explicit hydrogen bond
 term <pair_hbond_dreiding>` to describe interactions involving a
-hydrogen atom on very electronegative atoms (N, O, F).  Unlike CHARMM or
-AMBER, the DREIDING force field has not been parameterized for
-considering solvents (like water) and has no rules for assigning
-(partial) charges.  That will seriously limit its accuracy when used for
-simulating systems where those matter.
+hydrogen atom on very electronegative atoms (N, O, F).  Unlike CHARMM
+or AMBER, the DREIDING force field has not been parameterized for
+considering solvents (like water).
 
 See :ref:`(Mayo) <howto-Mayo>` for a description of the DREIDING force field
 
@@ -268,6 +272,10 @@ compatible with a subset of OPLS interactions.
 
 ----------
 
+.. _Typelabel2:
+
+**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).
+
 .. _howto-MacKerell:
 
 **(MacKerell)** MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field, Fischer, Gao, Guo, Ha, et al (1998).  J Phys Chem, 102, 3586 . https://doi.org/10.1021/jp973084f

doc/src/Howto_bpm.rst

@@ -42,14 +42,12 @@ such as those created by pouring grains using :doc:`fix pour
 
 ----------
 
-Currently, there are three types of bonds included in the BPM package. The
+Currently, there are two types of bonds included in the BPM package. The
 first bond style, :doc:`bond bpm/spring <bond_bpm_spring>`, only applies
 pairwise, central body forces. Point particles must have :doc:`bond atom
 style <atom_style>` and may be thought of as nodes in a spring
 network. An optional multibody term can be used to adjust the network's
-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
+Poisson's ratio. Alternatively, the second bond style, :doc:`bond bpm/rotational
 <bond_bpm_rotational>`, resolves tangential forces and torques arising
 with the shearing, bending, and twisting of the bond due to rotation or
 displacement of particles.  Particles are similar to those used in the

doc/src/Howto_bulk2slab.rst

@@ -1,160 +0,0 @@
-===========================
-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.

doc/src/Howto_cmake.rst

@@ -285,7 +285,7 @@ when used before the CMake directory, there may be a space between the
 can have boolean values (on/off, yes/no, or 1/0 are all valid) or are
 strings representing a choice, or a path, or are free format. If the
 string would contain whitespace, it must be put in quotes, for example
-``-D CMAKE_CXX_FLAGS="-O3 -Wall -ftree-vectorize -ffast-math"``.
+``-D CMAKE_TUNE_FLAGS="-ftree-vectorize -ffast-math"``.
 
 CMake variables fall into two categories: 1) common CMake variables that
 are used by default for any CMake configuration setup and 2) project
@@ -341,6 +341,8 @@ Some common LAMMPS specific variables
      - compile some additional executables from the ``tools`` folder (default: ``off``)
    * - ``BUILD_DOC``
      - include building the HTML format documentation for packaging/installing (default: ``off``)
+   * - ``CMAKE_TUNE_FLAGS``
+     - common compiler flags, for optimization or instrumentation (default:)
    * - ``LAMMPS_MACHINE``
      - when set to ``name`` the LAMMPS executable and library will be called ``lmp_name`` and ``liblammps_name.a``
    * - ``FFT``

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.
-For stable releases additional "stable\_<Day><Month><Year>" tags are
+"patch_<Day><Month><Year>" to simplify comparisons between releases.
+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.
@@ -498,7 +498,3 @@ systems.  Some unit and regression testing is applied as well.
 A detailed discussion of the LAMMPS developer GitHub workflow can be
 found in the file `doc/github-development-workflow.md
 <https://github.com/lammps/lammps/blob/develop/doc/github-development-workflow.md>`_
-
-.. raw:: latex
-
-   \clearpage

doc/src/Howto_granular.rst

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

doc/src/Howto_granular_surfaces.rst

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

doc/src/Howto_lammps_gui.rst

@@ -1,45 +1,47 @@
 Using LAMMPS-GUI
 ================
 
-.. image:: JPG/lammps-gui-banner.png
-   :align: center
-   :scale: 75%
-
-LAMMPS-GUI is a graphical text editor programmed using the `Qt Framework
-<https://www.qt.io/>`_ and customized for editing and running LAMMPS
-input files.  It is linked to the :ref:`LAMMPS library <lammps_c_api>`
-and thus can run LAMMPS directly using the contents of the editor's text
-buffer as input and without having to launch the LAMMPS executable.
-
-It *differs* from other known interfaces to LAMMPS in that it can
-retrieve and display information from LAMMPS *while it is running*,
-display visualizations created with the :doc:`dump image command
-<dump_image>`, can launch the online LAMMPS documentation for known
-LAMMPS commands and styles, and directly integrates with a collection
-of LAMMPS tutorials (:ref:`Gravelle1 <Gravelle1>`).
-
-This document describes **LAMMPS-GUI version 1.7**.
+This document describes **LAMMPS-GUI version 1.6**.
 
 -----
 
-.. contents::
+LAMMPS-GUI is a graphical text editor customized for editing LAMMPS
+input files that is linked to the :ref:`LAMMPS library <lammps_c_api>`
+and thus can run LAMMPS directly using the contents of the editor's text
+buffer as input.  It can retrieve and display information from LAMMPS
+while it is running, display visualizations created with the :doc:`dump
+image command <dump_image>`, and is adapted specifically for editing
+LAMMPS input files through text completion and reformatting, and linking
+to the online LAMMPS documentation for known LAMMPS commands and styles.
 
-----
+.. note::
 
-LAMMPS-GUI aims to provide the traditional experience of running LAMMPS
-using a text editor, a command-line window, and launching the LAMMPS
-text-mode executable printing output to the screen, but just integrated
-into a single application:
+   Pre-compiled, ready-to-use LAMMPS-GUI executables for Linux x86\_64
+   (Ubuntu 20.04LTS or later and compatible), macOS (version 11 aka Big
+   Sur or later), and Windows (version 10 or later) :ref:`are available
+   <lammps_gui_install>` for download.  Non-MPI LAMMPS executables (as
+   ``lmp``) for running LAMMPS from the command-line and :doc:`some
+   LAMMPS tools <Tools>` compiled executables are also included.
+   Also, the pre-compiled LAMMPS-GUI packages include the WHAM executables
+   from http://membrane.urmc.rochester.edu/content/wham/ for use with
+   LAMMPS tutorials.
 
-- Write and edit LAMMPS input files using the built-in text editor.
-- Run LAMMPS on those input file with command-line flags to enable a
-  specific accelerator package (or none).
-- Extract data from the created files (like trajectory files, log files
-  with thermodynamic data, or images) and visualize it using external
-  software.
+   The source code for LAMMPS-GUI is included in the LAMMPS source code
+   distribution and can be found in the ``tools/lammps-gui`` folder.  It
+   can be compiled alongside LAMMPS when :doc:`compiling with CMake
+   <Build_cmake>`.
 
-That traditional procedure is effective for people proficient in using the
-command-line, as it allows them to use the tools for the individual steps
+LAMMPS-GUI tries to provide an experience similar to what people
+traditionally would have running LAMMPS using a command-line window and
+the console LAMMPS executable but just rolled into a single executable:
+
+- writing & editing LAMMPS input files with a text editor
+- run LAMMPS on those input file with selected command-line flags
+- extract data from the created files and visualize it with and
+  external software
+
+That procedure is quite effective for people proficient in using the
+command-line, as that allows them to use tools for the individual steps
 that they are most comfortable with.  In fact, it is often *required* to
 adopt this workflow when running LAMMPS simulations on high-performance
 computing facilities.
@@ -50,69 +52,37 @@ window or using external programs, let alone writing scripts to extract
 data from the generated output.  It also integrates well with graphical
 desktop environments where the `.lmp` filename extension can be
 registered with LAMMPS-GUI as the executable to launch when double
-clicking on such files using a file manager.  LAMMPS-GUI also has
-support for 'drag and drop' for opening inputs: an input file can
-be selected and then moved and dropped on the LAMMPS-GUI executable;
-LAMMPS-GUI will launch and read the file into its buffer.  Input files
-also can be dropped into the editor window of the running LAMMPS-GUI
-application, which will close the current file and open the new file.
-In many cases LAMMPS-GUI will be integrated into the graphical desktop
-environment and can be launched just like any other applications from
-the graphical interface.
+clicking on such files.  Also, LAMMPS-GUI has support for drag-n-drop,
+i.e.  an input file can be selected and then moved and dropped on the
+LAMMPS-GUI executable, and LAMMPS-GUI will launch and read the file into
+its buffer.  In many cases LAMMPS-GUI will be integrated into the
+graphical desktop environment and can be launched like other
+applications.
 
 LAMMPS-GUI thus makes it easier for beginners to get started running
-LAMMPS and is well-suited for LAMMPS tutorials, since you only need to
-work with a single, ready-to-use program for most of the tasks.  Plus it
-is available for download as pre-compiled package for popular operating
-systems (Linux, macOS, Windows).  This saves time and allows users to
-focus on learning LAMMPS itself, without the need to learn how to
-compile LAMMPS, learn how to use the command line, or learn how to use a
-separate text editor.
-
+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 and their tutorial materials can be
-downloaded and edited directly from within the GUI while automatically
-loading the matching tutorial instructions into a webbrowser.
+updated for use with LAMMPS-GUI and can their tutorial materials can
+be downloaded and loaded directly from the GUI.
 
-Yet the basic control flow remains similar to running LAMMPS from the
-command line, so the barrier for replacing parts of the functionality of
-LAMMPS-GUI with external tools is low.  That said, LAMMPS-GUI offer some
-unique features that are not easily found elsewhere:
+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 available LAMMPS commands and options only
-- context-sensitive online help for known LAMMPS commands
+- auto-completion for LAMMPS commands and options
+- context-sensitive online help
 - start and stop of simulations via mouse or keyboard
-- monitoring of simulation progress and CPU use
-- interactive visualization using the LAMMPS :doc:`dump image feature <dump_image>`
+- 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 output at runtime
-- automatic plotting of thermodynamic data at runtime
+- automatic slide show generation from dump image out at runtime
+- automatic plotting of thermodynamics data at runtime
 - inspection of binary restart files
-- integration will a set of LAMMPS tutorials
 
-.. admonition:: Download LAMMPS-GUI for your platform
-   :class: Hint
-
-   Pre-compiled, ready-to-use LAMMPS-GUI executables for Linux x86\_64
-   (Ubuntu 20.04LTS or later and compatible), macOS (version 11 aka Big
-   Sur or later), and Windows (version 10 or later) :ref:`are available
-   <lammps_gui_install>` for download.  Non-MPI LAMMPS executables (as
-   ``lmp``) for running LAMMPS from the command-line and :doc:`some
-   LAMMPS tools <Tools>` compiled executables are also included.  Also,
-   the pre-compiled LAMMPS-GUI packages include the WHAM executables
-   from http://membrane.urmc.rochester.edu/content/wham/ for use with
-   LAMMPS tutorials documented in this paper (:ref:`Gravelle1
-   <Gravelle1>`).
-
-   The source code for LAMMPS-GUI is included in the LAMMPS source code
-   distribution and can be found in the ``tools/lammps-gui`` folder.  It
-   can be compiled alongside LAMMPS when :doc:`compiling with CMake
-   <Build_cmake>`.
-
------
-
-The following text provides a documentation of the features and
+The following text provides a detailed tour of the features and
 functionality of LAMMPS-GUI.  Suggestions for new features and
 reports of bugs are always welcome.  You can use the :doc:`the same
 channels as for LAMMPS itself <Errors_bugs>` for that purpose.
@@ -122,12 +92,9 @@ channels as for LAMMPS itself <Errors_bugs>` for that purpose.
 Installing Pre-compiled LAMMPS-GUI Packages
 -------------------------------------------
 
-LAMMPS-GUI is available for download as pre-compiled binary packages for
-Linux x86\_64 (Ubuntu 20.04LTS or later and compatible), macOS (version
-11 aka Big Sur or later), and Windows (version 10 or later) from the
-`LAMMPS release pages on GitHub <https://github.com/lammps/lammps/releases/>`_.
-A backup download location is at https://download.lammps.org/static/
-Alternately, LAMMPS-GUI can be compiled from source when building LAMMPS.
+LAMMPS-GUI is available as pre-compiled binary packages for Linux
+x86\_64, macOS 11 and later, and Windows 10 and later.  Alternately, it
+can be compiled from source.
 
 Windows 10 and later
 ^^^^^^^^^^^^^^^^^^^^
@@ -249,8 +216,8 @@ editor buffer, which may contain multiple :doc:`run <run>` or
 
 LAMMPS runs in a separate thread, so the GUI stays responsive and is
 able to interact with the running calculation and access data it
-produces.  It is important to note that running LAMMPS this way is using
-the contents of the input buffer for the run (via the
+produces.  It is important to note that running LAMMPS this way is
+using the contents of the input buffer for the run (via the
 :cpp:func:`lammps_commands_string()` function of the LAMMPS C-library
 interface), and **not** the original file it was read from.  Thus, if
 there are unsaved changes in the buffer, they *will* be used.  As an
@@ -259,55 +226,28 @@ of a file from the *Run LAMMPS from File* menu entry or with
 `Ctrl-Shift-Enter`.  This option may be required in some rare cases
 where the input uses some functionality that is not compatible with
 running LAMMPS from a string buffer.  For consistency, any unsaved
-changes in the buffer must be either saved to the file or undone before
-LAMMPS can be run from a file.
-
-The line number of the currently executed command is highlighted in
-green in the line number display for the *Editor* Window.
+changes in the buffer must be either saved to the file or undone
+before LAMMPS can be run from a file.
 
 .. image:: JPG/lammps-gui-running.png
    :align: center
    :scale: 75%
 
-While LAMMPS is running, the contents of the status bar change.  The
-text fields that normally show "Ready." and the current working
-directory, change into an area showing the CPU utilization in percent.
-Nest to it is a text indicating that LAMMPS is running, which also
-indicates the number of active threads (in case thread-parallel
-acceleration was selected in the *Preferences* dialog).  On the right
+While LAMMPS is running, the contents of the status bar change.  On
+the left side there is a text indicating that LAMMPS is running, which
+also indicates the number of active threads, when thread-parallel
+acceleration was selected in the *Preferences* dialog.  On the right
 side, a progress bar is shown that displays the estimated progress for
 the current :doc:`run <run>` or :doc:`minimize <minimize>` command.
 
-.. admonition:: CPU Utilization
-   :class: note
-
-   The CPU Utilization should ideally be close to 100% times the number
-   of threads like in the screenshot image above.  Since the GUI is
-   running as a separate thread, the CPU utilization can be higher, for
-   example when the GUI needs to work hard to keep up with the
-   simulation.  This can be caused by having frequent thermo output or
-   running a simulation of a small system.  In the *Preferences* dialog,
-   the polling interval for updating the the *Output* and *Charts*
-   windows can be set. The intervals may need to be lowered to not miss
-   data between *Charts* data updates or to avoid stalling when the
-   thermo output is not transferred to the *Output* window fast enough.
-   It is also possible to reduce the amount of data by increasing the
-   :doc:`thermo interval <thermo>`.  LAMMPS-GUI detects, if the
-   associated I/O buffer is by a significant percentage and will print a
-   warning after the run with suggested adjustments.  The utilization
-   can also be lower, e.g.  when the simulation is slowed down by the
-   GUI or other processes also running on the host computer and
-   competing with LAMMPS-GUI for GPU resources.
-
-   .. image:: JPG/lammps-gui-buffer-warn.png
-      :align: center
-      :scale: 75%
+Also, the line number of the currently executed command is highlighted
+in green.
 
 If an error occurs (in the example below the command :doc:`label
 <label>` was incorrectly capitalized as "Label"), an error message
 dialog is shown and the line of the input which triggered the error is
-highlighted in red.  The state of LAMMPS in the status bar is set to
-"Failed."  instead of "Ready."
+highlighted.  The state of LAMMPS in the status bar is set to "Failed."
+instead of "Ready."
 
 .. image:: JPG/lammps-gui-run-error.png
    :align: center
@@ -354,10 +294,7 @@ of the *Output* window showing how many warnings and errors were
 detected and how many lines the entire output has.  By clicking on the
 button on the right with the warning symbol or by using the keyboard
 shortcut `Ctrl-N` (`Command-N` on macOS), you can jump to the next
-line with a warning or error.  If there is a URL pointing to additional
-explanations in the online manual, that URL will be highlighted and
-double-clicking on it shall open the corresponding manual page in
-the web browser.  The option is also available from the context menu.
+line with a warning or error.
 
 By default, the *Output* window is replaced each time a run is started.
 The runs are counted and the run number for the current run is displayed
@@ -397,28 +334,27 @@ plot of thermodynamic output of the LAMMPS calculation as shown below.
    :align: center
    :scale: 33%
 
-The "Data:" drop down menu on the top right allows selection of
-different properties that are computed and written as thermodynamic
-output to the output window.  Only one property can be shown at a time.
-The plots are updated regularly with new data as the run progresses, so
-they can be used to visually monitor the evolution of available
-properties.  The update interval can be set in the *Preferences* dialog.
-By default, the raw data for the selected property is plotted as a blue
-graph.  From the "Plot:" drop menu on the second row and on the left,
-you can select whether to plot only raw data graph, only a smoothed data
-graph, or both graphs on top of each other.  The smoothing process uses
-a `Savitzky-Golay convolution filter
-<https://en.wikipedia.org/wiki/Savitzky%E2%80%93Golay_filter>`_.  The
-convolution window width (left) and order (right) parameters can be set
-in the boxes next to the drop down menu.  Default settings are 10 and 4
-which means that the smoothing window includes 10 points each to the
-left and the right of the current data point for a total of 21 points
-and a fourth order polynomial is fitted to the data in the window.
+The drop down menu on the top right allows selection of different
+properties that are computed and written to thermo output.  Only one
+property can be shown at a time.  The plots are updated regularly with
+new data as the run progresses, so they can be used to visually monitor
+the evolution of available properties.  The update interval can be set
+in the *Preferences* dialog.  By default, the raw data for the selected
+property is plotted as a blue graph. As soon as there are a sufficient
+number of data points, there will be a second graph shown in red with a
+smoothed version of the data.  From the drop down menu on the top left,
+you can select whether to plot only the raw data, only the smoothed
+data or both.  The smoothing uses a `Savitzky-Golay convolution filter
+<https://en.wikipedia.org/wiki/Savitzky%E2%80%93Golay_filter>`_ The
+window width (left) and order (right) parameters can be set in the boxes
+next to the drop down menu.  Default settings are 10 and 4 which means
+that the smoothing window includes 10 points each to the left and the
+right of the current data point and a fourth order polynomial is fit to
+the data in the window.
 
-The "Title:" and "Y:" input boxes allow to edit the text shown as the
-plot title and the y-axis label, respectively.  The text entered in the
-"Title:" box is applied to *all* charts, while the "Y:" text changes
-only the y-axis label of the currently *selected* plot.
+You can use the mouse to zoom into the graph (hold the left button and
+drag to mark an area) or zoom out (right click) and you can reset the
+view with a click to the "lens" button next to the data drop down menu.
 
 The window title shows the current run number that this chart window
 corresponds to.  Same as for the *Output* window, the chart window is
@@ -446,40 +382,6 @@ here you get the compounded data set starting with the last change of
 output fields or timestep setting, while the export from the log will
 contain *all* YAML output but *segmented* into individual runs.
 
-The *Preferences* dialog has a *Charts* tab, where you can configure
-multiple chart-related settings, like the default title, colors for the
-graphs, default choice of the raw / smooth graph selection, and the
-default chart graph size.
-
-
-
-.. admonition:: Slowdown of Simulations from Charts Data Processing
-   :class: warning
-
-   Using frequent thermo output during long simulations can result in a
-   significant slowdown of that simulation since it is accumulating many
-   data points for each of the thermo properties in the chart window to
-   be redrawn with every update.  The updates are consuming additional
-   CPU time when smoothing enabled.  This slowdown can be confirmed when
-   an increasing percentage of the total run time is spent in the
-   "Output" or "Other" sections of the :doc:`MPI task timing breakdown
-   <Run_output>`.  It is thus recommended to use a large enough value as
-   argument `N` for the :doc:`thermo command <thermo>` and to select
-   plotting only the "Raw" data in the *Charts Window* during such
-   simulations.  It is always possible to switch between the different
-   display styles for charts during the simulation and after it has
-   finished.
-
-   .. versionchanged:: 1.7
-
-      As of LAMMPS-GUI version 1.7 the chart data processing is
-      significantly optimized compared to older versions of LAMMPS-GUI.
-      The general problem of accumulating excessive amounts of data
-      and the overhead of too frequently polling LAMMPS for new data
-      cannot be optimized away, though.  If necessary, the command
-      line LAMMPS executable needs to be used and the output accumulated
-      of a very fast disk (e.g. a high-performance SSD).
-
 Image Slide Show
 ----------------
 
@@ -559,11 +461,11 @@ correspond to (via their mass) and then colorize them in the image and
 set their atom diameters accordingly.  If this is not possible, for
 instance when using reduced (= 'lj') :doc:`units <units>`, then
 LAMMPS-GUI will check the current pair style and if it is a
-Lennard-Jones type potential, it will extract the *sigma* parameter for
-each atom type and assign atom diameters from those numbers.  For cases
-where atom diameters are not auto-detected, the *Atom size* field can be
-edited and a suitable value set manually. The default value is inferred
-from the x-direction lattice spacing.
+Lennard-Jones type potential, it will extract the *sigma* parameter
+for each atom type and assign atom diameters from those numbers.
+For cases where atom diameters are not auto-detected, the *Atom size* field
+can be edited and a suitable value set manually. The default value
+is inferred from the x-direction lattice spacing.
 
 If elements cannot be detected the default sequence of colors of the
 :doc:`dump image <dump_image>` command is assigned to the different atom
@@ -578,31 +480,22 @@ types.
 |gui-image1|  |gui-image2|
 
 The default image size, some default image quality settings, the view
-style and some colors can be changed in the *Preferences* dialog window.
-From the image viewer window further adjustments can be made: actual
-image size, high-quality (SSAO) rendering, anti-aliasing, view style,
-display of box or axes, zoom factor.  The view of the system can be
-rotated horizontally and vertically.
-
-It is also possible to display only the atoms within a :doc:`group
-defined in the input script <group>` (default is "all").  The available
-groups can be selected from the drop down list next to the "Group:"
-label.  Similarly, if there are :doc:`molecules defined in the input
-<molecule>`, it is possible to select one of them (default is "none")
-and visualize it (it will be shown at the center of the simulation box).
-While a molecule is selected, the group selection is disabled.  It can
-be restored by selecting the molecule "none".
-
-The image can also be re-centered on the center of mass of the selected
-group.  After each change, the image is rendered again and the display
-updated.  The small palette icon on the top left is colored while LAMMPS
-is running to render the new image; it is grayed out when LAMMPS is
-finished.  When there are many atoms to render and high quality images
-with anti-aliasing are requested, re-rendering may take several seconds.
-From the *File* menu of the image window, the current image can be saved
-to a file (keyboard shortcut `Ctrl-S`) or copied to the clipboard
-(keyboard shortcut `Ctrl-C`) for pasting the image into another
-application.
+style and some colors can be changed in the *Preferences* dialog
+window.  From the image viewer window further adjustments can be made:
+actual image size, high-quality (SSAO) rendering, anti-aliasing, view
+style, display of box or axes, zoom factor.  The view of the system can
+be rotated horizontally and vertically.  It is also possible to only
+display the atoms within a group defined in the input script (default is
+"all").  The image can also be re-centered on the center of mass of the
+selected group.  After each change, the image is rendered again and the
+display updated.  The small palette icon on the top left is colored
+while LAMMPS is running to render the new image; it is grayed out when
+LAMMPS is finished.  When there are many atoms to render and high
+quality images with anti-aliasing are requested, re-rendering may take
+several seconds.  From the *File* menu of the image window, the
+current image can be saved to a file (keyboard shortcut `Ctrl-S`) or
+copied to the clipboard (keyboard shortcut `Ctrl-C`) for pasting the
+image into another application.
 
 From the *File* menu it is also possible to copy the current
 :doc:`dump image <dump_image>` and :doc:`dump_modify <dump_image>`
@@ -711,27 +604,13 @@ generated with a :doc:`write_data command <write_data>`.  The third
 window is a :ref:`Snapshot Image Viewer <snapshot_viewer>` containing a
 visualization of the system in the restart.
 
-.. |inspect1| image:: JPG/lammps-gui-inspect-data.png
-   :width: 32%
-
-.. |inspect2| image:: JPG/lammps-gui-inspect-info.png
-   :width: 32%
-
-.. |inspect3| image:: JPG/lammps-gui-inspect-image.png
-   :width: 32%
-
-|inspect1|  |inspect2|  |inspect3|
-
-.. admonition:: Large Restart Files
-   :class: warning
-
-   If the restart file is larger than 250 MBytes, a dialog will ask for
-   confirmation before continuing, since large restart files may require
-   large amounts of RAM since the entire system must be read into RAM.
-   Thus restart file for large simulations that have been run on an HPC
-   cluster may overload a laptop or local workstation. The *Show
-   Details...* button will display a rough estimate of the additional
-   memory required.
+If the restart file is larger than 250 MBytes, a dialog will ask
+for confirmation before continuing, since large restart files
+may require large amounts of RAM since the entire system must
+be read into RAM.  Thus restart file for large simulations that
+have been run on an HPC cluster may overload a laptop or local
+workstation. The *Show Details...* button will display a rough
+estimate of the additional memory required.
 
 Menu
 ----
@@ -803,12 +682,6 @@ timestep.  The *Stop LAMMPS* entry will do this by calling the
 :cpp:func:`lammps_force_timeout` library function, which is equivalent
 to a :doc:`timer timeout 0 <timer>` command.
 
-The *Relaunch LAMMPS Instance* will destroy the current LAMMPS thread
-and free its data and then create a new thread with a new LAMMPS
-instance.  This is usually not needed, since LAMMPS-GUI tries to detect
-when this is needed and does it automatically.  This is available
-in case it missed something and LAMMPS behaves in unexpected ways.
-
 The *Set Variables...* entry opens a dialog box where
 :doc:`index style variables <variable>` can be set. Those variables
 are passed to the LAMMPS instance when it is created and are thus
@@ -847,26 +720,6 @@ output, charts, slide show, variables, or snapshot images.  The
 default settings for their visibility can be changed in the
 *Preferences* dialog.
 
-Tutorials
-^^^^^^^^^
-
-The *Tutorials* menu is to support the set of LAMMPS tutorials for
-beginners and intermediate LAMMPS users documented in (:ref:`Gravelle1
-<Gravelle1>`).  From the drop down menu you can select which of the
-eight currently available tutorial sessions you want to begin.  This
-opens a 'wizard' dialog where you can choose in which folder you want to
-work, whether you want that folder to be wiped from *any* files, whether
-you want to download the solutions files (which can be large) to a
-``solution`` sub-folder, and whether you want the corresponding
-tutorial's online version opened in your web browser.  The dialog will
-then start downloading the files requested (download progress is
-reported in the status line) and load the first input file for the
-selected session into LAMMPS-GUI.
-
-.. image:: JPG/lammps-gui-tutorials.png
-   :align: center
-   :scale: 50%
-
 About
 ^^^^^
 
@@ -930,21 +783,18 @@ look of LAMMPS-GUI.  The settings are grouped and each group is
 displayed within a tab.
 
 .. |guiprefs1| image:: JPG/lammps-gui-prefs-general.png
-   :width: 19%
+   :width: 24%
 
 .. |guiprefs2| image:: JPG/lammps-gui-prefs-accel.png
-   :width: 19%
+   :width: 24%
 
 .. |guiprefs3| image:: JPG/lammps-gui-prefs-image.png
-   :width: 19%
+   :width: 24%
 
 .. |guiprefs4| image:: JPG/lammps-gui-prefs-editor.png
-   :width: 19%
+   :width: 24%
 
-.. |guiprefs5| image:: JPG/lammps-gui-prefs-charts.png
-   :width: 19%
-
-|guiprefs1|  |guiprefs2|  |guiprefs3|  |guiprefs4|  |guiprefs5|
+|guiprefs1|  |guiprefs2|  |guiprefs3|  |guiprefs4|
 
 General Settings:
 ^^^^^^^^^^^^^^^^^
@@ -973,12 +823,13 @@ General Settings:
 - *Replace image window on new render:* when checked, an existing
   chart window will be replaced when a new snapshot image is requested,
   otherwise each command will create a new image window.
-- *Download tutorial solutions enabled* this controls whether the
-  "Download solutions" option is enabled by default when setting up
-  a tutorial.
-- *Open tutorial webpage enabled* this controls whether the "Open
-  tutorial webpage in web browser" option is enabled by default when
-  setting up a tutorial.
+- *Path to LAMMPS Shared Library File:* this option is only visible
+  when LAMMPS-GUI was compiled to load the LAMMPS library at run time
+  instead of being linked to it directly.  With the *Browse..* button
+  or by changing the text, a different shared library file with a
+  different compilation of LAMMPS with different settings or from a
+  different version can be loaded.  After this setting was changed,
+  LAMMPS-GUI needs to be re-launched.
 - *Select Default Font:* Opens a font selection dialog where the type
   and size for the default font (used for everything but the editor and
   log) of the application can be set.
@@ -997,36 +848,16 @@ General Settings:
   the plots in the *Charts* window in milliseconds.  The default is to
   redraw the plots every 500 milliseconds.  This is just for the drawing,
   data collection is managed with the previous setting.
-- *HTTPS proxy setting:* Allows to enter a URL for an HTTPS proxy.  This
-  may be needed when the LAMMPS input contains :doc:`geturl commands <geturl>`
-  or for downloading tutorial files from the *Tutorials* menu.  If the
-  ``https_proxy`` environment variable was set externally, its value is
-  displayed but cannot be changed.
-- *Path to LAMMPS Shared Library File:* this option is only visible
-  when LAMMPS-GUI was compiled to load the LAMMPS library at run time
-  instead of being linked to it directly.  With the *Browse..* button
-  or by changing the text, a different shared library file with a
-  different compilation of LAMMPS with different settings or from a
-  different version can be loaded.  After this setting was changed,
-  LAMMPS-GUI needs to be re-launched.
 
 Accelerators:
 ^^^^^^^^^^^^^
 
-This tab enables selection of an accelerator package and modify some of
-its settings to use for running LAMMPS and is equivalent to using the
-:doc:`-sf <suffix>` and :doc:`-pk <package>` flags :doc:`on the
-command-line <Run_options>`.  Only settings supported by the LAMMPS
-library and local hardware are available.  The `Number of threads` field
-allows setting the number of threads for the accelerator packages that
-support using threads (OPENMP, INTEL, KOKKOS, and GPU).  Furthermore,
-the choice of precision mode (double, mixed, or single) for the INTEL
-package can be selected and for the GPU package, whether the neighbor
-lists are built on the GPU or the host (required for :doc:`pair style
-hybrid <pair_hybrid>`) and whether only pair styles should be
-accelerated (i.e. run PPPM entirely on the CPU, which sometimes leads
-to better overall performance).  Whether settings can be changed depends
-on which accelerator package is chosen (or "None").
+This tab enables selection of an accelerator package for LAMMPS to use
+and is equivalent to using the `-suffix` and `-package` flags on the
+command-line.  Only settings supported by the LAMMPS library and local
+hardware are available.  The `Number of threads` field allows setting
+the maximum number of threads for the accelerator packages that use
+threads.
 
 Snapshot Image:
 ^^^^^^^^^^^^^^^
@@ -1053,7 +884,7 @@ lists to select the background and box colors.
 Editor Settings:
 ^^^^^^^^^^^^^^^^
 
-This tab allows tweaking settings of the editor window.  Specifically,
+This tab allows tweaking settings of the editor window.  Specifically
 the amount of padding to be added to LAMMPS commands, types or type
 ranges, IDs (e.g. for fixes), and names (e.g. for groups).  The value
 set is the minimum width for the text element and it can be chosen in
@@ -1065,16 +896,6 @@ the completion pop-up window, and whether auto-save mode is enabled.
 In auto-save mode the editor buffer is saved before a run or before
 exiting LAMMPS-GUI.
 
-Charts Settings:
-----------------
-
-This tab allows tweaking settings of the *Charts* window.  Specifically,
-one can set the default chart title (if the title contains '%f' it will
-be replaced with the name of the current input file), one can select
-whether by default the raw data, the smoothed data or both will be
-plotted, one can set the colors for the two lines, the default smoothing
-parameters, and the default size of the chart graph in pixels.
-
 -----------
 
 Keyboard Shortcuts
@@ -1155,25 +976,10 @@ available (On macOS use the Command key instead of Ctrl/Control).
      - Ctrl+Shift+T
      - LAMMPS Tutorial
 
-Further keybindings of the editor window `are documented with the Qt
-documentation
+Further editing keybindings `are documented with the Qt documentation
 <https://doc.qt.io/qt-5/qplaintextedit.html#editing-key-bindings>`_.  In
 case of conflicts the list above takes precedence.
 
 All other windows only support a subset of keyboard shortcuts listed
 above.  Typically, the shortcuts `Ctrl-/` (Stop Run), `Ctrl-W` (Close
 Window), and `Ctrl-Q` (Quit Application) are supported.
-
--------------
-
-.. _Gravelle1:
-
-**(Gravelle1)** Gravelle, Gissinger, Kohlmeyer, `arXiv:2503.14020 \[physics.comp-ph\] <https://doi.org/10.48550/arXiv.2503.14020>`_ (2025)
-
-.. _Gravelle2:
-
-**(Gravelle2)** Gravelle https://lammpstutorials.github.io/
-
-.. raw:: latex
-
-   \clearpage

doc/src/Howto_moltemplate.rst

@@ -2,18 +2,14 @@ Moltemplate Tutorial
 ====================
 
 In this tutorial, we are going to use the tool :ref:`Moltemplate
-<Moltemplate1>` from https://moltemplate.org/ to set up a classical
-molecular dynamic simulation using the :ref:`OPLS-AA force field
-<oplsaa2024>`. The first task is to describe an organic compound and
-create a complete input deck for LAMMPS.  The second task is to use
-moltemplate to build a polymer.  The third task is to map the OPLS-AA
-force field to a molecular sample created with an external tool,
-e.g. PACKMOL, and exported as a PDB file.  The files used in this
-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
-
+<moltemplate>` to set up a classical molecular dynamic simulation using
+the :ref:`OPLS-AA force field <OPLSAA96>`. The first
+task is to describe an organic compound and create a complete input deck
+for LAMMPS. The second task is to map the OPLS-AA force field to a
+molecular sample created with an external tool, e.g. PACKMOL, and
+exported as a PDB file.  The files used in this tutorial can be found
+in the ``tools/moltemplate/tutorial-files`` folder of the LAMMPS
+source code distribution.
 
 Simulating an organic solvent
 """""""""""""""""""""""""""""
@@ -21,13 +17,14 @@ 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 LAMMPS-template
-(LT) file format representing a single molecule, which will be
-stored in a Moltemplate object called ``_FAM inherits OPLSAA {}``.
+The first step is to create a molecular topology in the
+LAMMPS-template (LT) file format representing a single molecule, which
+will be 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``,
@@ -39,23 +36,21 @@ 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
-``oplsaa2024.lt``, looking for a reasonable match with the description of the atom.
+``oplsaa.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:235  0.00    0.100   0.490   0.0
-       $atom:O01  $mol  @atom:236  0.00    1.091  -0.250   0.0
-       $atom:N02  $mol  @atom:237  0.00   -1.121  -0.181   0.0
-       $atom:H03  $mol  @atom:240  0.00   -2.013   0.272   0.0
-       $atom:H04  $mol  @atom:240  0.00   -1.056  -1.190   0.0
-       $atom:H05  $mol  @atom:279  0.00    0.144   1.570   0.0
+       $atom:C00 $mol   @atom:177  0.00    0.100   0.490   0.0
+       $atom:O01 $mol   @atom:178  0.00    1.091  -0.250   0.0
+       $atom:N02 $mol   @atom:179  0.00   -1.121  -0.181   0.0
+       $atom:H03 $mol   @atom:182  0.00   -2.013   0.272   0.0
+       $atom:H04 $mol   @atom:182  0.00   -1.056  -1.190   0.0
+       $atom:H05 $mol   @atom:221  0.00    0.144   1.570   0.0
      }
 
      # A list of the bonds in the molecule:
@@ -69,17 +64,16 @@ The resulting file (``formamide.lt``) follows:
      }
    }
 
-You don't have to specify the charge in this example because the OPLSAA
-force-field assigns charge according to the atom type.  (This is not true
-when using other force fields.)  A "Data Bond List" section is needed as
-the atom type will determine the bond type. The other bonded interactions
-(e.g. angles, dihedrals, and impropers) will be automatically generated by
+You don't have to specify the charge in this example because they will
+be assigned according to the atom type. Analogously, only a
+"Data Bond List" section is needed as the atom type will determine the
+bond type. The other bonded interactions (e.g. angles,
+dihedrals, and impropers) will be automatically generated by
 Moltemplate.
 
-If the simulation is not charge-neutral, or Moltemplate complains that
-you have missing bond, angle, or dihedral types, this probably means that
-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).
+If the simulation is non-neutral, or Moltemplate complains that you have
+missing bond, angle, or dihedral types, this means at least one of your
+atom types is incorrect.
 
 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
@@ -87,9 +81,11 @@ master file (``solv_01.lt``) follows:
 
 .. code-block:: bash
 
-   import formamide.lt  # Defines "_FAM" and OPLSAA
+   # Import the force field.
+   import /usr/local/moltemplate/moltemplate/force_fields/oplsaa.lt
+   import formamide.lt # after oplsaa.lt, as it depends on it.
 
-   # Distribute the molecules on a 5x5x5 cubic grid with spacing 4.6
+   # Create the input sample.
    solv = new _FAM [5].move( 4.6, 0, 0)
                    [5].move( 0, 4.6, 0)
                    [5].move( 0, 0, 4.6)
@@ -102,11 +98,8 @@ 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.
-    # Run an NPT simulation.
+   # Create an input deck for LAMMPS.
+   write_once("In Init"){
     # Input variables.
     variable run    string solv_01   # output name
     variable ts     equal  1         # timestep
@@ -116,6 +109,12 @@ 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
@@ -144,7 +143,7 @@ master file (``solv_01.lt``) follows:
     unfix NPT
    }
 
-The first two commands insert the content of files ``oplsaa2024.lt`` and
+The first two commands insert the content of files ``oplsaa.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
@@ -154,37 +153,21 @@ 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
-``oplsaa2024.lt`` and are written automatically in the input deck. We also
+``oplsaa.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 solv_01.lt
-   cleanup_moltemplate.sh   # <-- optional: see below
+   moltemplate.sh -overlay-all solv_01.lt
 
-(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:
+And execute the simulation with the following:
 
 .. code-block:: bash
 
@@ -197,116 +180,15 @@ Then 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
-sub-unit 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 assembled
-from different simulations or created with specialized software (e.g. PACKMOL).
-(Note: The previous link shows how to build this entire system from scratch
-using only moltemplate.  However here we will assume instead that we obtained
-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
+sample to a force field. This is useful when a complex sample is
+assembled from different simulations or created with specialized
+software (e.g. PACKMOL). As in the previous example, all molecular
+species in the sample must be 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
@@ -364,25 +246,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/oplsaa2024.lt
+   import /usr/local/moltemplate/moltemplate/force_fields/oplsaa.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:412 0.0  0.00000 0.00000 0.000000
+       $atom:a1  $mol:. @atom:354 0.0  0.00000 0.00000 0.000000
      }
    }
    Cl inherits OPLSAA {
      write("Data Atoms"){
-       $atom:a1  $mol:. @atom:401 0.0  0.00000 0.00000 0.000000
+       $atom:a1  $mol:. @atom:344 0.0  0.00000 0.00000 0.000000
      }
    }
    SPC inherits OPLSAA {
      write("Data Atoms"){
-       $atom:O  $mol:. @atom:9991 0.  0.0000000 0.00000 0.0000000
-       $atom:H1 $mol:. @atom:9990 0.  0.8164904 0.00000 0.5773590
-       $atom:H2 $mol:. @atom:9990 0. -0.8164904 0.00000 0.5773590
+       $atom:O  $mol:. @atom:76 0.  0.0000000 0.00000 0.000000
+       $atom:H1 $mol:. @atom:77 0.  0.8164904 0.00000 0.5773590
+       $atom:H2 $mol:. @atom:77 0. -0.8164904 0.00000 0.5773590
      }
      write("Data Bond List") {
        $bond:OH1 $atom:O $atom:H1
@@ -403,15 +285,8 @@ 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
@@ -419,6 +294,13 @@ 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 &
@@ -432,8 +314,8 @@ The resulting master LT file defining short annealing at a fixed volume
      write_data \$\{run\}.min
 
      # Set the constrains.
-     group watergroup type @atom:9991 @atom:9990
-     fix 0 watergroup shake 0.0001 10 0 b @bond:spcO_spcH a @angle:spcH_spcO_spcH
+     group watergroup type @atom:76 @atom:77
+     fix 0 watergroup shake 0.0001 10 0 b @bond:042_043 a @angle:043_042_043
 
      # Short annealing.
      timestep        \$\{ts\}
@@ -445,7 +327,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
-``oplsaa2024.lt`` file with atom types ``@atom:9991`` and ``@atom:9990``.  For
+``oplsaa.lt`` file with atom types ``@atom:76`` and ``@atom:77``.  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
@@ -454,20 +336,19 @@ are:
 
 .. code-block:: bash
 
-   replace{ @atom:9991 @atom:9991_bspcO_aspcO_dspcO_ispcO }
-   replace{ @atom:9990 @atom:9990_bspcH_aspcH_dspcH_ispcH }
+   replace{ @atom:76 @atom:76_b042_a042_d042_i042 }
+   replace{ @atom:77 @atom:77_b043_a043_d043_i043 }
 
 From which we can identify the following "Data Bonds By Type":
-``@bond:spcO_spcH @atom:*_bspcO*_a*_d*_i* @atom:*_bspcH*_a*_d*_i*``
-and "Data Angles By Type":
-``@angle:spcH_spcO_spcH @atom:*_b*_aspcH*_d*_i* @atom:*_b*_aspcO*_d*_i* @atom:*_b*_aspcH*_d*_i*``
+``@bond:042_043 @atom:*_b042*_a*_d*_i* @atom:*_b043*_a*_d*_i*`` and
+"Data Angles By Type": ``@angle:043_042_043 @atom:*_b*_a043*_d*_i*
+@atom:*_b*_a042*_d*_i* @atom:*_b*_a043*_d*_i*``
 
 Compile the master file with:
 
 .. code-block:: bash
 
-   moltemplate.sh -pdb model.pdb sample01.lt
-   cleanup_moltemplate.sh
+   moltemplate.sh -overlay-all -pdb model.pdb sample01.lt
 
 And execute the simulation with the following:
 
@@ -482,13 +363,8 @@ And execute the simulation with the following:
    Sample visualized with Ovito loading the trajectory into the DATA
    file written after minimization.
 
-
 ------------
 
-.. _oplsaa2024:
+.. _OPLSAA96:
 
-**(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)
+**(OPLS-AA)**  Jorgensen, Maxwell, Tirado-Rives, J Am Chem Soc, 118(45), 11225-11236 (1996).

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}^\mathrm{d}, \qquad\qquad\textrm{(3)}
+   \alpha \underline{\omega}\,\underline{e}^{\rm 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}^\mathrm{i}=\frac{\theta \underline{x}}{3}, \qquad
-   \underline{e}^\mathrm{d} = \underline{e}- \underline{e}^\mathrm{i},
+   \underline{e}^{\rm i}=\frac{\theta \underline{x}}{3}, \qquad
+   \underline{e}^{\rm d} = \underline{e}- \underline{e}^{\rm 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}^\mathrm{d}`.
+extension :math:`\underline{e}^{\rm d}`.
 
 .. note::
 

doc/src/Howto_python.rst

@@ -62,17 +62,17 @@ with :ref:`PNG, JPEG and FFMPEG output support <graphics>` enabled.
 
          cd $LAMMPS_DIR/src
 
-         # add LAMMPS packages if necessary
+         # add packages if necessary
          make yes-MOLECULE
          make yes-PYTHON
 
          # compile shared library using Makefile
          make mpi mode=shlib LMP_INC="-DLAMMPS_PNG -DLAMMPS_JPEG -DLAMMPS_FFMPEG" JPG_LIB="-lpng -ljpeg"
 
-Step 2: Installing the LAMMPS Python module
-"""""""""""""""""""""""""""""""""""""""""""
+Step 2: Installing the LAMMPS Python package
+""""""""""""""""""""""""""""""""""""""""""""
 
-Next install the LAMMPS Python module into your current Python installation with:
+Next install the LAMMPS Python package into your current Python installation with:
 
 .. code-block:: bash
 
@@ -89,29 +89,6 @@ privileges) or into your personal Python module folder.
    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
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 

doc/src/Howto_spc.rst

@@ -1,5 +1,5 @@
-SPC and SPC/E water model
-=========================
+SPC water model
+===============
 
 The SPC water model specifies a 3-site rigid water molecule with
 charges and Lennard-Jones parameters assigned to each of the three atoms.
@@ -8,18 +8,6 @@ the two O-H bonds and the H-O-H angle rigid.  A bond style of
 *harmonic* and an angle style of *harmonic* or *charmm* should also be
 used.
 
-One suitable pair style with cutoff Coulomb would for instance be:
-
-* :doc:`pair_style lj/cut/coul/cut <pair_lj_cut_coul>`
-
-These commands are examples for a long-range Coulomb model:
-
-* :doc:`pair_style lj/cut/coul/long <pair_lj_cut_coul>`
-* :doc:`pair_style lj/cut/coul/long/soft <pair_fep_soft>`
-* :doc:`kspace_style pppm <kspace_style>`
-* :doc:`pair_style lj/long/coul/long <pair_lj_long>`
-* :doc:`kspace_style pppm/disp <kspace_style>`
-
 These are the additional parameters (in real units) to set for O and H
 atoms and the water molecule to run a rigid SPC model.
 
@@ -51,9 +39,7 @@ the SPC and SPC/E models.
 Below is the code for a LAMMPS input file and a molecule file
 (``spce.mol``) of SPC/E water for use with the :doc:`molecule command
 <molecule>` demonstrating how to set up a small bulk water system for
-SPC/E with rigid bonds.  For simplicity and speed the example uses a
-cutoff Coulomb.  Most production simulations require long-range Coulomb
-instead.
+SPC/E with rigid bonds.
 
 .. code-block:: LAMMPS
 

doc/src/Howto_thermostat.rst

@@ -21,14 +21,9 @@ can be invoked via the *dpd/tstat* pair style:
 * :doc:`fix nvt/sllod <fix_nvt_sllod>`
 * :doc:`fix temp/berendsen <fix_temp_berendsen>`
 * :doc:`fix temp/csvr <fix_temp_csvr>`
-* :doc:`fix ffl <fix_ffl>`
-* :doc:`fix gjf <fix_gjf>`
-* :doc:`fix gld <fix_gld>`
-* :doc:`fix gle <fix_gle>`
 * :doc:`fix langevin <fix_langevin>`
 * :doc:`fix temp/rescale <fix_temp_rescale>`
 * :doc:`pair_style dpd/tstat <pair_dpd>`
-* :doc:`pair_style dpd/ext/tstat <pair_dpd_ext>`
 
 :doc:`Fix nvt <fix_nh>` only thermostats the translational velocity of
 particles.  :doc:`Fix nvt/sllod <fix_nvt_sllod>` also does this,
@@ -87,10 +82,10 @@ that:
 
 .. note::
 
-   Not all thermostat fixes perform time integration, meaning they update
+   Only the nvt fixes perform time integration, meaning they update
    the velocities and positions of particles due to forces and velocities
    respectively.  The other thermostat fixes only adjust velocities; they
-   do NOT perform time integration updates.  Thus, they should be used in
+   do NOT perform time integration updates.  Thus they should be used in
    conjunction with a constant NVE integration fix such as these:
 
 * :doc:`fix nve <fix_nve>`

doc/src/Howto_tip3p.rst

@@ -5,24 +5,17 @@ The TIP3P water model as implemented in CHARMM :ref:`(MacKerell)
 <howto-tip3p>` specifies a 3-site rigid water molecule with charges and
 Lennard-Jones parameters assigned to each of the three atoms.
 
-One suitable pair style with cutoff Coulomb would for instance be:
+A suitable pair style with cutoff Coulomb would be:
 
 * :doc:`pair_style lj/cut/coul/cut <pair_lj_cut_coul>`
 
-These commands are examples for a long-range Coulomb model:
+or these commands for a long-range Coulomb model:
 
 * :doc:`pair_style lj/cut/coul/long <pair_lj_cut_coul>`
 * :doc:`pair_style lj/cut/coul/long/soft <pair_fep_soft>`
 * :doc:`kspace_style pppm <kspace_style>`
-* :doc:`pair_style lj/long/coul/long <pair_lj_long>`
 * :doc:`kspace_style pppm/disp <kspace_style>`
 
-And these pair styles are compatible with the CHARMM force field:
-
-* :doc:`pair_style lj/charmm/coul/charmm <pair_charmm>`
-* :doc:`pair_style lj/charmm/coul/long <pair_charmm>`
-* :doc:`pair_style lj/charmmfsw/coul/long <pair_charmm>`
-
 In LAMMPS the :doc:`fix shake or fix rattle <fix_shake>` command can be
 used to hold the two O-H bonds and the H-O-H angle rigid.  A bond style
 of :doc:`harmonic <bond_harmonic>` and an angle style of :doc:`harmonic
@@ -107,9 +100,7 @@ ignored.
 Below is the code for a LAMMPS input file and a molecule file
 (``tip3p.mol``) of TIP3P water for use with the :doc:`molecule command
 <molecule>` demonstrating how to set up a small bulk water system for
-TIP3P with rigid bonds.  For simplicity and speed the example uses a
-cutoff Coulomb.  Most production simulations require long-range Coulomb
-instead.
+TIP3P with rigid bonds.
 
 .. code-block:: LAMMPS
 

doc/src/Howto_tip4p.rst

@@ -1,5 +1,5 @@
-TIP4P and OPC water models
-==========================
+TIP4P water model
+=================
 
 The four-point TIP4P rigid water model extends the traditional
 :doc:`three-point TIP3P <Howto_tip3p>` model by adding an additional
@@ -9,11 +9,9 @@ the oxygen along the bisector of the HOH bond angle.  A bond style of
 :doc:`harmonic <bond_harmonic>` and an angle style of :doc:`harmonic
 <angle_harmonic>` or :doc:`charmm <angle_charmm>` should also be used.
 In case of rigid bonds also bond style :doc:`zero <bond_zero>` and angle
-style :doc:`zero <angle_zero>` can be used.  Very similar to the TIP4P
-model is the OPC water model.  It can be realized the same way as TIP4P
-but has different geometry and force field parameters.
+style :doc:`zero <angle_zero>` can be used.
 
-There are two ways to implement TIP4P-like water in LAMMPS:
+There are two ways to implement TIP4P water in LAMMPS:
 
 #. Use a specially written pair style that uses the :ref:`TIP3P geometry
    <tip3p_molecule>` without the point M. The point M location is then
@@ -23,10 +21,7 @@ There are two ways to implement TIP4P-like water in LAMMPS:
    computationally very efficient, but the charge distribution in space
    is only correct within the tip4p labeled styles.  So all other
    computations using charges will "see" the negative charge incorrectly
-   located on the oxygen atom unless they are specially written for using
-   the TIP4P geometry internally as well, e.g. :doc:`compute dipole/tip4p
-   <compute_dipole>`, :doc:`fix efield/tip4p <fix_efield>`, or
-   :doc:`kspace_style pppm/tip4p <kspace_style>`.
+   on the oxygen atom.
 
    This can be done with the following pair styles for Coulomb with a cutoff:
 
@@ -73,90 +68,77 @@ TIP4P/2005 model :ref:`(Abascal2) <Abascal2>` and a version of TIP4P
 parameters adjusted for use with a long-range Coulombic solver
 (e.g. Ewald or PPPM in LAMMPS).  Note that for implicit TIP4P models the
 OM distance is specified in the :doc:`pair_style <pair_style>` command,
-not as part of the pair coefficients. Also parameters for the OPC
-model (:ref:`Izadi <Izadi>`) are provided.
+not as part of the pair coefficients.
 
 .. list-table::
       :header-rows: 1
-      :widths: 40 12 12 14 11 11
+      :widths: 36 19 13 15 17
 
       * - Parameter
         - TIP4P (original)
         - TIP4P/Ice
         - TIP4P/2005
         - TIP4P (Ewald)
-        - OPC
       * - O mass (amu)
         - 15.9994
         - 15.9994
         - 15.9994
         - 15.9994
-        - 15.9994
       * - H mass (amu)
         - 1.008
         - 1.008
         - 1.008
         - 1.008
-        - 1.008
       * - O or M charge (:math:`e`)
         - -1.040
         - -1.1794
         - -1.1128
         - -1.04844
-        - -1.3582
       * - H charge (:math:`e`)
         - 0.520
         - 0.5897
         - 0.5564
         - 0.52422
-        - 0.6791
       * - LJ :math:`\epsilon` of OO (kcal/mole)
         - 0.1550
         - 0.21084
         - 0.1852
         - 0.16275
-        - 0.21280
       * - LJ :math:`\sigma` of OO (:math:`\AA`)
         - 3.1536
         - 3.1668
         - 3.1589
         - 3.16435
-        - 3.1660
       * - LJ :math:`\epsilon` of HH, MM, OH, OM, HM (kcal/mole)
         - 0.0
         - 0.0
         - 0.0
         - 0.0
-        - 0.0
       * - LJ :math:`\sigma` of HH, MM, OH, OM, HM (:math:`\AA`)
         - 1.0
         - 1.0
         - 1.0
         - 1.0
-        - 1.0
       * - :math:`r_0` of OH bond (:math:`\AA`)
         - 0.9572
         - 0.9572
         - 0.9572
         - 0.9572
-        - 0.8724
       * - :math:`\theta_0` of HOH angle
         - 104.52\ :math:`^{\circ}`
         - 104.52\ :math:`^{\circ}`
         - 104.52\ :math:`^{\circ}`
         - 104.52\ :math:`^{\circ}`
-        - 103.60\ :math:`^{\circ}`
       * - OM distance (:math:`\AA`)
         - 0.15
         - 0.1577
         - 0.1546
         - 0.1250
-        - 0.1594
 
-Note that the when using a TIP4P pair style, the neighbor list cutoff
+Note that the when using the TIP4P pair style, the neighbor list cutoff
 for Coulomb interactions is effectively extended by a distance 2 \* (OM
 distance), to account for the offset distance of the fictitious charges
-on O atoms in water molecules.  Thus, it is typically best in an
+on O atoms in water molecules.  Thus it is typically best in an
 efficiency sense to use a LJ cutoff >= Coulomb cutoff + 2\*(OM
 distance), to shrink the size of the neighbor list.  This leads to
 slightly larger cost for the long-range calculation, so you can test the
@@ -167,9 +149,7 @@ cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long
 Below is the code for a LAMMPS input file using the implicit method and
 the :ref:`TIP3P molecule file <tip3p_molecule>`.  Because the TIP4P
 charges are different from TIP3P they need to be reset (or the molecule
-file changed).  For simplicity and speed the example uses a cutoff
-Coulomb.  Most production simulations require long-range Coulomb
-instead.
+file changed):
 
 .. code-block:: LAMMPS
 
@@ -212,94 +192,6 @@ instead.
     run 20000
     write_data tip4p-implicit.data nocoeff
 
-When constructing an OPC model, we cannot use the ``tip3p.mol`` file due
-to the different geometry.  Below is a molecule file providing the 3
-sites of an implicit OPC geometry for use with TIP4P styles.  Note, that
-the "Shake" and "Special" sections are missing here.  Those will be
-auto-generated by LAMMPS when the molecule file is loaded *after* the
-simulation box has been created.  These sections are required only when
-the molecule file is loaded *before*.
-
-.. _opc3p_molecule:
-.. code-block::
-
-   # Water molecule. 3 point geometry for OPC model
-
-   3 atoms
-   2 bonds
-   1 angles
-
-   Coords
-
-   1    0.00000  -0.06037   0.00000
-   2    0.68558   0.50250   0.00000
-   3   -0.68558   0.50250   0.00000
-
-   Types
-
-   1        1   # O
-   2        2   # H
-   3        2   # H
-
-   Charges
-
-   1       -1.3582
-   2        0.6791
-   3        0.6791
-
-   Bonds
-
-   1   1      1      2
-   2   1      1      3
-
-   Angles
-
-   1   1      2      1      3
-
-Below is a LAMMPS input file using the implicit method to implement
-the OPC model using the molecule file from above and including the
-PPPM long-range Coulomb solver.
-
-.. code-block:: LAMMPS
-
-    units real
-    atom_style full
-    region box block -5 5 -5 5 -5 5
-    create_box 2 box bond/types 1 angle/types 1 &
-                extra/bond/per/atom 2 extra/angle/per/atom 1 extra/special/per/atom 2
-
-    mass 1 15.9994
-    mass 2 1.008
-
-    pair_style lj/cut/tip4p/long 1 2 1 1 0.1594 12.0
-    pair_coeff 1 1 0.2128 3.166
-    pair_coeff 2 2 0.0    1.0
-
-    bond_style zero
-    bond_coeff 1 0.8724
-
-    angle_style zero
-    angle_coeff 1 103.6
-
-    kspace_style pppm/tip4p 1.0e-5
-
-    molecule water opc3p.mol  # this file has the OPC geometry but is without M
-    create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
-
-    fix rigid all shake 0.001 10 10000 b 1 a 1
-    minimize 0.0 0.0 1000 10000
-
-    reset_timestep 0
-    timestep 1.0
-    velocity all create 300.0 5463576
-    fix integrate all nvt temp 300 300 100.0
-
-    thermo_style custom step temp press etotal pe
-
-    thermo 1000
-    run 20000
-    write_data opc-implicit.data nocoeff
-
 Below is the code for a LAMMPS input file using the explicit method and
 a TIP4P molecule file.  Because of using :doc:`fix rigid/small
 <fix_rigid>` no bonds need to be defined and thus no extra storage needs
@@ -387,8 +279,3 @@ Phys, 79, 926 (1983).
 
 **(Abascal2)** Abascal, J Chem Phys, 123, 234505 (2005)
    https://doi.org/10.1063/1.2121687
-
-.. _Izadi:
-
-**(Izadi)** Izadi, Anandakrishnan, Onufriev, J. Phys. Chem. Lett., 5, 21, 3863 (2014)
-   https://doi.org/10.1021/jz501780a

doc/src/Howto_tip5p.rst

@@ -87,9 +87,7 @@ atom style full or use :doc:`fix property/atom mol <fix_property_atom>`
 so that fix rigid/small can identify rigid bodies by their molecule ID.
 Also a :doc:`neigh_modify exclude <neigh_modify>` command is added to
 exclude computing intramolecular non-bonded interactions, since those
-are removed by the rigid fix anyway.  For simplicity and speed the
-example uses a cutoff Coulomb.  Most production simulations require
-long-range Coulomb instead.
+are removed by the rigid fix anyway:
 
 .. code-block:: LAMMPS
 

doc/src/Howto_triclinic.rst

@@ -249,23 +249,23 @@ as follows:
 
 .. math::
 
-  a   = & \mathrm{lx} \\
-  b^2 = &  \mathrm{ly}^2 + \mathrm{xy}^2 \\
-  c^2 = &  \mathrm{lz}^2 + \mathrm{xz}^2 + \mathrm{yz}^2 \\
-  \cos{\alpha} = & \frac{\mathrm{xy}*\mathrm{xz} + \mathrm{ly}*\mathrm{yz}}{b*c} \\
-  \cos{\beta}  = & \frac{\mathrm{xz}}{c} \\
-  \cos{\gamma} = & \frac{\mathrm{xy}}{b} \\
+  a   = & {\rm lx} \\
+  b^2 = &  {\rm ly}^2 +  {\rm xy}^2 \\
+  c^2 = &  {\rm lz}^2 +  {\rm xz}^2 +  {\rm yz}^2 \\
+  \cos{\alpha} = & \frac{{\rm xy}*{\rm xz} + {\rm ly}*{\rm yz}}{b*c} \\
+  \cos{\beta}  = & \frac{\rm xz}{c} \\
+  \cos{\gamma} = & \frac{\rm xy}{b} \\
 
 The inverse relationship can be written as follows:
 
 .. math::
 
-  \mathrm{lx}   = & a \\
-  \mathrm{xy}   = & b \cos{\gamma}  \\
-  \mathrm{xz}   = & c \cos{\beta}\\
-  \mathrm{ly}^2 = & b^2 - \mathrm{xy}^2 \\
-  \mathrm{yz}   = & \frac{b*c \cos{\alpha} - \mathrm{xy}*\mathrm{xz}}{\mathrm{ly}} \\
-  \mathrm{lz}^2 = & c^2 - \mathrm{xz}^2 - \mathrm{yz}^2 \\
+  {\rm lx}   = & a \\
+  {\rm xy}   = & b \cos{\gamma}  \\
+  {\rm xz}   = & c \cos{\beta}\\
+  {\rm ly}^2 = & b^2 - {\rm xy}^2 \\
+  {\rm yz}   = & \frac{b*c \cos{\alpha} - {\rm xy}*{\rm xz}}{\rm ly} \\
+  {\rm lz}^2 = & c^2 - {\rm xz}^2 - {\rm 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

doc/src/Install_git.rst

@@ -12,17 +12,26 @@ several advantages:
   LAMMPS.  For that, you should first create your own :doc:`fork on
   GitHub <Howto_github>`, though.
 
-You must have `git <git_>`_ installed on your system to use the commands
-explained below to communicate with the git servers on GitHub.
+You must have `git <git_>`_ installed on your system to use the
+commands explained below to communicate with the git servers on
+GitHub.  For people still using subversion (svn), GitHub also
+provides `limited support for subversion clients <svn_>`_.
+
+.. note::
+
+   As of October 2016, the official home of public LAMMPS development is
+   on GitHub.  The previously advertised LAMMPS git repositories on
+   git.lammps.org and bitbucket.org are now offline or deprecated.
 
 .. _git: https://git-scm.com
+.. _svn: https://help.github.com/en/github/importing-your-projects-to-github/working-with-subversion-on-github
 
 You can follow the LAMMPS development on 4 different git branches:
 
 * **develop** : this branch follows the ongoing development and is
   updated with every merge commit of a pull request
-* **release** : this branch is updated with every "feature release"
-  and updates are always "fast-forward" merges from *develop*
+* **release** : this branch is updated with every "feature release";
+   updates are always "fast-forward" merges from *develop*
 * **maintenance** : this branch collects back-ported bug fixes from the
   *develop* branch to the *stable* branch.  It is used to update the
   *stable* branch for "stable update releases".
@@ -43,7 +52,6 @@ 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,

doc/src/Install_mac.rst

@@ -5,7 +5,8 @@ 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.
+additional requirements not yet met: GPU, KOKKOS, MSCG, POEMS,
+VORONOI.
 
 After installing Homebrew, you can install LAMMPS on your system with
 the following commands:

doc/src/Intro_authors.rst

@@ -84,9 +84,8 @@ lammps.org".  General questions about LAMMPS should be posted in the
 
    \normalsize
 
-Past core developers include Paul Crozier and Mark Stevens, both at SNL,
-and Ray Shan while at SNL and later at Materials Design, now at Thermo
-Fisher Scientific.
+Past developers include Paul Crozier and Mark Stevens, both at SNL,
+and Ray Shan, now at Materials Design.
 
 ----------