Merge pull request #3567 from akohlmey/next_patch_release

Set version strings for next patch release

.gitattributes

@@ -3,6 +3,7 @@
 .github export-ignore
 .lgtm.yml export-ignore
 SECURITY.md export-ignore
+CITATION.cff export-ignore
 *       text=auto
 *.jpg   -text
 *.pdf   -text

.github/CODEOWNERS

@@ -13,39 +13,45 @@ lib/kim/*             @ellio167
 lib/mesont/*          @iafoss
 
 # whole packages
-src/COMPRESS/*        @rbberger
-src/GPU/*             @ndtrung81
-src/KOKKOS/*          @stanmoore1
-src/KIM/*             @ellio167
-src/LATTE/*           @cnegre
-src/MESSAGE/*         @sjplimp
-src/MLIAP/*           @athomps
-src/SNAP/*            @athomps
-src/SPIN/*            @julient31
+src/ADIOS/*           @pnorbert
+src/AMOEBA/*          @sjplimp
+src/BPM/*             @jtclemm
 src/BROWNIAN/*        @samueljmcameron
 src/CG-DNA/*          @ohenrich
-src/CG-SDK/*          @akohlmey
+src/CG-SPICA/*        @yskmiyazaki
 src/COLVARS/*         @giacomofiorin
+src/COMPRESS/*        @rbberger
 src/DIELECTRIC/*      @ndtrung81
+src/ELECTRODE/*       @ludwig-ahrens
 src/FEP/*             @agiliopadua
-src/ML-HDNNP/*        @singraber
+src/GPU/*             @ndtrung81
+src/GRANULAR/*        @jtclemm @dsbolin
 src/INTEL/*           @wmbrownintel
+src/KIM/*             @ellio167
+src/KOKKOS/*          @stanmoore1
+src/LATTE/*           @cnegre
 src/MANIFOLD/*        @Pakketeretet2
-src/MDI/*             @taylor-a-barnes
+src/MDI/*             @taylor-a-barnes @sjplimp
 src/MEAM/*            @martok
 src/MESONT/*          @iafoss
+src/ML-HDNNP/*        @singraber
+src/ML-IAP/*          @athomps
+src/ML-PACE/*         @yury-lysogorskiy
+src/ML-POD/*          @exapde @rohskopf
 src/MOFFF/*           @hheenen
 src/MOLFILE/*         @akohlmey
 src/NETCDF/*          @pastewka
-src/ML-PACE/*         @yury-lysogorskiy
-src/PLUMED/*          @gtribello
-src/PHONON/*          @lingtikong
-src/PTM/*             @pmla
 src/OPENMP/*          @akohlmey
+src/PHONON/*          @lingtikong
+src/PLUGIN/*          @akohlmey
+src/PLUMED/*          @gtribello
+src/PTM/*             @pmla
 src/QMMM/*            @akohlmey
-src/REAXFF/*          @hasanmetin @stanmoore1
 src/REACTION/*        @jrgissing
+src/REAXFF/*          @hasanmetin @stanmoore1
 src/SCAFACOS/*        @rhalver
+src/SNAP/*            @athomps
+src/SPIN/*            @julient31
 src/TALLY/*           @akohlmey
 src/UEF/*             @danicholson
 src/VTK/*             @rbberger
@@ -58,6 +64,8 @@ src/MANYBODY/pair_atm.*             @sergeylishchuk
 src/REPLICA/*_grem.*                @dstelter92
 src/EXTRA-COMPUTE/compute_stress_mop*.* @RomainVermorel
 src/MISC/*_tracker.*                @jtclemm
+src/MC/fix_gcmc.*                   @athomps
+src/MC/fix_sgcmc.*                  @athomps
 
 # core LAMMPS classes
 src/lammps.*              @sjplimp
@@ -119,26 +127,32 @@ src/dump_movie.*          @akohlmey
 src/exceptions.h          @rbberger
 src/fix_nh.*              @athomps
 src/info.*                @akohlmey @rbberger
-src/timer.*               @akohlmey
 src/min*                  @sjplimp @stanmoore1
+src/platform.*            @akohlmey
+src/timer.*               @akohlmey
 src/utils.*               @akohlmey @rbberger
 src/verlet.*              @sjplimp @stanmoore1
 src/math_eigen_impl.h     @jewettaij
 
 # tools
-tools/msi2lmp/*       @akohlmey
+tools/coding_standard/* @akohlmey @rbberger
 tools/emacs/*         @HaoZeke
-tools/singularity/*   @akohlmey @rbberger
-tools/coding_standard/* @rbberger
-tools/valgrind/*      @akohlmey
-tools/swig/*          @akohlmey
+tools/lammps-shell/*  @akohlmey
+tools/msi2lmp/*       @akohlmey
 tools/offline/*       @rbberger
+tools/singularity/*   @akohlmey @rbberger
+tools/swig/*          @akohlmey
+tools/valgrind/*      @akohlmey
+tools/vim/*           @hammondkd
 
 # tests
-unittest/*            @akohlmey @rbberger
+unittest/*            @akohlmey
 
 # cmake
 cmake/*               @junghans @rbberger
+cmake/Modules/LAMMPSInterfacePlugin.cmake @akohlmey
+cmake/Modules/MPI4WIN.cmake @akohlmey
+cmake/Modules/OpenCLLoader.cmake @akohlmey
 cmake/Modules/Packages/COLVARS.cmake @junghans @rbberger @giacomofiorin
 cmake/Modules/Packages/KIM.cmake @junghans @rbberger @ellio167
 cmake/presets/*.cmake @akohlmey
@@ -147,13 +161,12 @@ cmake/presets/*.cmake @akohlmey
 python/*              @rbberger
 
 # fortran
-fortran/*             @akohlmey
+fortran/*             @akohlmey @hammondkd
 
 # docs
-doc/utils/*/*         @rbberger
-doc/Makefile          @rbberger
-doc/README            @rbberger
+doc/*                 @akohlmey
 examples/plugin/*     @akohlmey
+examples/PACKAGES/pace/plugin/*     @akohlmey
 
 # for releases
 src/version.h         @sjplimp

.github/ISSUE_TEMPLATE/help_request.md

@@ -1,6 +1,6 @@
 ---
 name: Request for Help
-about: "Don't post help requests here, email the lammps-users mailing list"
+about: "Don't post help requests here, post in the LAMMPS forum"
 title: ""
 labels: invalid
 assignees: ''
@@ -8,8 +8,9 @@ assignees: ''
 ---
 
 Please **do not** post requests for help (e.g. with installing or using LAMMPS) here.
-Instead send an e-mail to the lammps-users mailing list.
+Instead, you can post to the LAMMPS category in the Materials Science Community
+Discourse forum at: https://matsci.org/lammps/
 
 This issue tracker is for tracking LAMMPS development related issues only.
 
-Thanks for your cooperation.
+Thank you in advance for your cooperation.

.github/codecov.yml

@@ -7,7 +7,7 @@ coverage:
         threshold: 10%
         only_pulls: false
         branches:
-          - "master"
+          - "develop"
         flags:
           - "unit"
         paths:
@@ -16,14 +16,14 @@ coverage:
     project:
         default:
             branches:
-              - "master"
+              - "develop"
             paths:
               - "src"
             informational: true
     patch:
         default:
             branches:
-              - "master"
+              - "develop"
             paths:
               - "src"
             informational: true

.github/workflows/compile-msvc.yml

@@ -3,7 +3,11 @@ name: "Native Windows Compilation and Unit Tests"
 
 on:
   push:
-    branches: [develop]
+    branches:
+      - develop
+  pull_request:
+    branches:
+      - develop
 
   workflow_dispatch:
 
@@ -22,15 +26,19 @@ jobs:
     - name: Select Python version
       uses: actions/setup-python@v4
       with:
-        python-version: '3.10'
+        python-version: '3.11'
 
     - name: Building LAMMPS via CMake
       shell: bash
       run: |
         python3 -m pip install numpy
         python3 -m pip install pyyaml
+        nuget install MSMPIsdk
+        nuget install MSMPIDIST
         cmake -C cmake/presets/windows.cmake \
               -D PKG_PYTHON=on \
+              -D WITH_PNG=off \
+              -D WITH_JPEG=off \
               -S cmake -B build \
               -D BUILD_SHARED_LIBS=on \
               -D LAMMPS_EXCEPTIONS=on \
@@ -46,4 +54,4 @@ jobs:
     - name: Run Unit Tests
       working-directory: build
       shell: bash
-      run: ctest -V -C Release
+      run: ctest -V -C Release -E FixTimestep:python_move_nve

.github/workflows/coverity.yml

@@ -0,0 +1,103 @@
+name: "Run Coverity Scan"
+
+on:
+  schedule:
+    - cron: "0 0 * * FRI"
+
+  workflow_dispatch:
+
+jobs:
+  analyze:
+    name: Analyze
+    if: ${{ github.repository == 'lammps/lammps' }}
+    runs-on: ubuntu-latest
+    container:
+      image: lammps/buildenv:ubuntu20.04
+
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v3
+      with:
+        fetch-depth: 2
+
+    - name: Create Build and Download Folder
+      run: mkdir build download
+
+    - name: Cache Coverity
+      id: cache-coverity
+      uses: actions/cache@v3
+      with:
+        path: ./download/
+        key: ${{ runner.os }}-download-${{ hashFiles('**/coverity_tool.*') }}
+
+    - name: Download Coverity if necessary
+      if: steps.cache-coverity.outputs.cache-hit != 'true'
+      working-directory: download
+      run: |
+        wget -nv https://scan.coverity.com/download/linux64 --post-data "token=${{ secrets.COVERITY_TOKEN }}&project=LAMMPS" -O coverity_tool.tgz
+        wget -nv https://scan.coverity.com/download/linux64 --post-data "token=${{ secrets.COVERITY_TOKEN }}&project=LAMMPS&md5=1" -O coverity_tool.md5
+        echo " coverity_tool.tgz" >> coverity_tool.md5
+        md5sum -c coverity_tool.md5
+
+    - name: Setup Coverity
+      run: |
+        tar xzf download/coverity_tool.tgz
+        ln -s cov-analysis-linux64-* coverity
+
+    - name: Configure LAMMPS via CMake
+      shell: bash
+      working-directory: build
+      run: |
+        cmake \
+        -C ../cmake/presets/clang.cmake \
+        -C ../cmake/presets/most.cmake \
+        -C ../cmake/presets/kokkos-openmp.cmake \
+        -D CMAKE_BUILD_TYPE="RelWithDebug" \
+        -D CMAKE_TUNE_FLAGS="-Wall -Wextra -Wno-unused-result" \
+        -D BUILD_MPI=on \
+        -D BUILD_OMP=on \
+        -D BUILD_SHARED_LIBS=on \
+        -D LAMMPS_SIZES=SMALLBIG \
+        -D LAMMPS_EXCEPTIONS=off \
+        -D PKG_MESSAGE=on \
+        -D PKG_MPIIO=on \
+        -D PKG_ATC=on \
+        -D PKG_AWPMD=on \
+        -D PKG_BOCS=on \
+        -D PKG_EFF=on \
+        -D PKG_H5MD=on \
+        -D PKG_INTEL=on \
+        -D PKG_LATBOLTZ=on \
+        -D PKG_MANIFOLD=on \
+        -D PKG_MGPT=on \
+        -D PKG_ML-PACE=on \
+        -D PKG_ML-RANN=on \
+        -D PKG_MOLFILE=on \
+        -D PKG_NETCDF=on \
+        -D PKG_PTM=on \
+        -D PKG_QTB=on \
+        -D PKG_SMTBQ=on \
+        -D PKG_TALLY=on \
+        ../cmake
+
+    - name: Run Coverity Scan
+      shell: bash
+      working-directory: build
+      run: |
+        export PATH=$GITHUB_WORKSPACE/coverity/bin:$PATH
+        cov-build --dir cov-int cmake --build . --parallel 2
+
+    - name: Create tarball with scan results
+      shell: bash
+      working-directory: build
+      run: tar czf lammps.tgz cov-int
+
+    - name: Upload scan result to Coverity
+      shell: bash
+      run: |
+        curl --form token=${{ secrets.COVERITY_TOKEN }} \
+             --form email=${{ secrets.COVERITY_EMAIL }} \
+             --form file=@build/lammps.tgz \
+             --form version=${{ github.sha }} \
+             --form description="LAMMPS automated build" \
+             https://scan.coverity.com/builds?project=LAMMPS

.github/workflows/unittest-macos.yml

@@ -3,7 +3,11 @@ name: "Unittest for MacOS"
 
 on:
   push:
-    branches: [develop]
+    branches:
+      - develop
+  pull_request:
+    branches:
+      - develop
 
   workflow_dispatch:
 
@@ -39,6 +43,7 @@ jobs:
       working-directory: build
       run: |
         ccache -z
+        python3 -m pip install numpy
         python3 -m pip install pyyaml
         cmake -C ../cmake/presets/clang.cmake \
               -C ../cmake/presets/most.cmake \

CITATION.cff

@@ -0,0 +1,91 @@
+# YAML 1.2
+---
+cff-version: 1.2.0
+title: "LAMMPS: Large-scale Atomic/Molecular Massively Parallel Simulator"
+type: software
+authors:
+  - family-names: "Plimpton"
+    given-names: "Steven J."
+  - family-names: "Kohlmeyer"
+    given-names: "Axel"
+    orcid: "https://orcid.org/0000-0001-6204-6475"
+  - family-names: "Thompson"
+    given-names: "Aidan P."
+    orcid: "https://orcid.org/0000-0002-0324-9114"
+  - family-names: "Moore"
+    given-names: "Stan G."
+  - family-names: "Berger"
+    given-names: "Richard"
+    orcid: "https://orcid.org/0000-0002-3044-8266"
+doi: 10.5281/zenodo.3726416
+license: GPL-2.0-only
+url: https://www.lammps.org
+repository-code: https://github.com/lammps/lammps/
+keywords:
+  - "Molecular Dynamics"
+  - "Materials Modeling"
+message: "If you are referencing LAMMPS in a publication, please cite the paper below."
+preferred-citation:
+  type: article
+  doi: "10.1016/j.cpc.2021.108171"
+  url: "https://www.sciencedirect.com/science/article/pii/S0010465521002836"
+  authors:
+  - family-names: "Thompson"
+    given-names: "Aidan P."
+    orcid: "https://orcid.org/0000-0002-0324-9114"
+  - family-names: "Aktulga"
+    given-names: "H. Metin"
+  - family-names: "Berger"
+    given-names: "Richard"
+    orcid: "https://orcid.org/0000-0002-3044-8266"
+  - family-names: "Bolintineanu"
+    given-names: "Dan S."
+  - family-names: "Brown"
+    given-names: "W. Michael"
+  - family-names: "Crozier"
+    given-names: "Paul S."
+  - family-names: "in 't Veld"
+    given-names: "Pieter J."
+  - family-names: "Kohlmeyer"
+    given-names: "Axel"
+    orcid: "https://orcid.org/0000-0001-6204-6475"
+  - family-names: "Moore"
+    given-names: "Stan G."
+  - family-names: "Nguyen"
+    given-names: "Trung Dac"
+  - family-names: "Shan"
+    given-names: "Ray"
+  - family-names: "Stevens"
+    given-names: "Mark J."
+  - family-names: "Tranchida"
+    given-names: "Julien"
+  - family-names: "Trott"
+    given-names: "Christian"
+  - family-names: "Plimpton"
+    given-names: "Steven J."
+  title: "LAMMPS - a flexible simulation tool for particle-based materials modeling at the atomic, meso, and continuum scales"
+  journal: "Computer Physics Communications"
+  keywords:
+   - Molecular dynamics
+   - Materials modeling
+   - Parallel algorithms
+   - LAMMPS
+  month: 2
+  volume: 271
+  issn: 0010-4655
+  pages: 108171
+  year: 2022
+references:
+ - title: "Fast Parallel Algorithms for Short-Range Molecular Dynamics"
+   type: article
+   journal: Journal of Computational Physics
+   volume: 117
+   number: 1
+   pages: "1-19"
+   year: 1995
+   issn: 0021-9991
+   doi: 10.1006/jcph.1995.1039
+   url: https://www.sciencedirect.com/science/article/pii/S002199918571039X
+   authors:
+   - family-names: "Plimpton"
+     given-names: "Steve"

README

@@ -16,8 +16,8 @@ National Laboratories, a US Department of Energy facility, with
 funding from the DOE.  It is an open-source code, distributed freely
 under the terms of the GNU Public License (GPL) version 2.
 
-The primary author of the code is Steve Plimpton, who can be emailed
-at sjplimp@sandia.gov.  The LAMMPS WWW Site at www.lammps.org has
+The code is maintained by the LAMMPS development team who can be emailed
+at developers@lammps.org.  The LAMMPS WWW Site at www.lammps.org has
 more information about the code and its uses.
 
 The LAMMPS distribution includes the following files and directories:

SECURITY.md

@@ -14,14 +14,14 @@ and tested by the LAMMPS developers, so it is easy to import bad
 behavior from calling functions in one of those libraries.
 
 Thus is is quite easy to crash LAMMPS through malicious input and do all
-kinds of filesystem manipulations.  And because of that LAMMPS should
+kinds of file system manipulations.  And because of that LAMMPS should
 **NEVER** be compiled or **run** as superuser, either from a "root" or
 "administrator" account directly or indirectly via "sudo" or "su".
 
 Therefore what could be seen as a security vulnerability is usually
-either a user mistake or a bug in the code.  Bugs can be reported in
-the LAMMPS project
-[issue tracker on GitHub](https://github.com/lammps/lammps/issues).
+either a user mistake or a bug in the code.  Bugs can be reported in the
+LAMMPS project [issue tracker on
+GitHub](https://github.com/lammps/lammps/issues).
 
 To mitigate issues with using homoglyphs or bidirectional reordering in
 unicode, which have been demonstrated as a vector to obfuscate and hide
@@ -30,10 +30,18 @@ for unicode characters and only all-ASCII source code is accepted.
 
 # Version Updates
 
-LAMMPS follows continuous release development model.  We aim to keep all
-release versions (stable or patch) fully functional and employ a variety
-of automatic testing procedures to detect failures of existing
-functionality from adding new features before releases are made.  Thus
-bugfixes and updates are only integrated into the current development
-branch and thus the next (patch) release and users are recommended to
-update regularly.
+LAMMPS follows continuous release development model.  We aim to keep to
+keep the development version (develop branch) always fully functional
+and employ a variety of automatic testing procedures to detect failures
+of existing functionality from adding or modifying features.  Most of
+those tests are run on pull requests *before* merging to the development
+branch.  The develop branch is protected, so all changes *must* be
+submitted as a pull request and thus cannot avoid the automated tests.
+
+Additional tests are run *after* merging.  Before releases are made
+*all* tests must have cleared.  Then a release tag is applied and the
+release branch fast-forwarded to that tag.  Bug fixes and updates are
+applied to the current development branch and thus will be available in
+the next (patch) release.  For stable releases, selected bug fixes are
+back-ported and occasionally published as update releases.  There are
+only updates to the latest stable release.

cmake/CMakeLists.txt

@@ -7,11 +7,20 @@ cmake_minimum_required(VERSION 3.10)
 if(POLICY CMP0074)
   cmake_policy(SET CMP0074 NEW)
 endif()
+# set policy to silence warnings about ignoring  ${CMAKE_REQUIRED_LIBRARIES} but use it
+if(POLICY CMP0075)
+  cmake_policy(SET CMP0075 NEW)
+endif()
 # set policy to silence warnings about missing executable permissions in
 # pythonx.y-config when cross-compiling. review occasionally if it may be set to NEW
 if(POLICY CMP0109)
   cmake_policy(SET CMP0109 OLD)
 endif()
+# set policy to silence warnings about timestamps of downloaded files. review occasionally if it may be set to NEW
+if(POLICY CMP0135)
+  cmake_policy(SET CMP0135 OLD)
+endif()
+
 ########################################
 
 project(lammps CXX)
@@ -100,7 +109,7 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
     if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
       set(CMAKE_TUNE_DEFAULT "-xCOMMON-AVX512")
     else()
-      set(CMAKE_TUNE_DEFAULT "-xHost")
+      set(CMAKE_TUNE_DEFAULT "-xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=2196")
     endif()
   endif()
 endif()
@@ -135,13 +144,11 @@ set(CMAKE_CXX_EXTENSIONS OFF CACHE BOOL "Use compiler extensions")
 # ugly hacks for MSVC which by default always reports an old C++ standard in the __cplusplus macro
 # and prints lots of pointless warnings about "unsafe" functions
 if(MSVC)
-  if(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
+  if((CMAKE_CXX_COMPILER_ID STREQUAL "MSVC") OR (CMAKE_CXX_COMPILER_ID STREQUAL "Intel"))
     add_compile_options(/Zc:__cplusplus)
     add_compile_options(/wd4244)
     add_compile_options(/wd4267)
-    if(LAMMPS_EXCEPTIONS)
-      add_compile_options(/EHsc)
-    endif()
+    add_compile_options(/EHsc)
   endif()
   add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
 endif()
@@ -154,6 +161,19 @@ endif()
 ########################################################################
 # User input options                                                   #
 ########################################################################
+# set path to python interpreter and thus enforcing python version if
+# when in a virtual environment and PYTHON_EXECUTABLE is not set on command line
+if(DEFINED ENV{VIRTUAL_ENV} AND NOT PYTHON_EXECUTABLE)
+  if(CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows")
+    set(PYTHON_EXECUTABLE "$ENV{VIRTUAL_ENV}/Scripts/python.exe")
+  else()
+    set(PYTHON_EXECUTABLE "$ENV{VIRTUAL_ENV}/bin/python")
+  endif()
+  set(Python_EXECUTABLE "${PYTHON_EXECUTABLE}")
+  message(STATUS "Running in virtual environment: $ENV{VIRTUAL_ENV}\n"
+    "   Setting Python interpreter to: ${PYTHON_EXECUTABLE}")
+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)
@@ -194,6 +214,7 @@ option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
 
 set(STANDARD_PACKAGES
   ADIOS
+  AMOEBA
   ASPHERE
   ATC
   AWPMD
@@ -202,7 +223,7 @@ set(STANDARD_PACKAGES
   BPM
   BROWNIAN
   CG-DNA
-  CG-SDK
+  CG-SPICA
   CLASS2
   COLLOID
   COLVARS
@@ -245,6 +266,7 @@ set(STANDARD_PACKAGES
   ML-QUIP
   ML-RANN
   ML-SNAP
+  ML-POD
   MOFFF
   MOLECULE
   MOLFILE
@@ -295,6 +317,15 @@ if(PKG_ADIOS)
   # script that defines the MPI::MPI_C target
   enable_language(C)
   find_package(ADIOS2 REQUIRED)
+  if(BUILD_MPI)
+    if(NOT ADIOS2_HAVE_MPI)
+      message(FATAL_ERROR "ADIOS2 must be built with MPI support when LAMMPS has MPI enabled")
+    endif()
+  else()
+    if(ADIOS2_HAVE_MPI)
+      message(FATAL_ERROR "ADIOS2 must be built without MPI support when LAMMPS has MPI disabled")
+    endif()
+  endif()
   target_link_libraries(lammps PRIVATE adios2::adios2)
 endif()
 
@@ -358,17 +389,19 @@ pkg_depends(MPIIO MPI)
 pkg_depends(ATC MANYBODY)
 pkg_depends(LATBOLTZ MPI)
 pkg_depends(SCAFACOS MPI)
+pkg_depends(AMOEBA KSPACE)
 pkg_depends(DIELECTRIC KSPACE)
 pkg_depends(DIELECTRIC EXTRA-PAIR)
 pkg_depends(CG-DNA MOLECULE)
 pkg_depends(CG-DNA ASPHERE)
 pkg_depends(ELECTRODE KSPACE)
+pkg_depends(EXTRA-MOLECULE MOLECULE)
 
 # detect if we may enable OpenMP support by default
 set(BUILD_OMP_DEFAULT OFF)
-find_package(OpenMP QUIET)
-if(OpenMP_FOUND)
-  check_include_file_cxx(omp.h HAVE_OMP_H_INCLUDE)
+find_package(OpenMP COMPONENTS CXX QUIET)
+if(OpenMP_CXX_FOUND)
+  check_omp_h_include()
   if(HAVE_OMP_H_INCLUDE)
     set(BUILD_OMP_DEFAULT ON)
   endif()
@@ -377,8 +410,8 @@ endif()
 option(BUILD_OMP "Build with OpenMP support" ${BUILD_OMP_DEFAULT})
 
 if(BUILD_OMP)
-  find_package(OpenMP REQUIRED)
-  check_include_file_cxx(omp.h HAVE_OMP_H_INCLUDE)
+  find_package(OpenMP COMPONENTS CXX REQUIRED)
+  check_omp_h_include()
   if(NOT HAVE_OMP_H_INCLUDE)
     message(FATAL_ERROR "Cannot find the 'omp.h' header file required for full OpenMP support")
   endif()
@@ -400,11 +433,13 @@ if(BUILD_OMP)
   target_link_libraries(lmp PRIVATE OpenMP::OpenMP_CXX)
 endif()
 
-if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_LATTE OR PKG_ELECTRODE)
+if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_ML-POD OR PKG_LATTE OR PKG_ELECTRODE)
   enable_language(C)
-  find_package(LAPACK)
-  find_package(BLAS)
-  if(NOT LAPACK_FOUND OR NOT BLAS_FOUND)
+  if (NOT USE_INTERNAL_LINALG)
+    find_package(LAPACK)
+    find_package(BLAS)
+  endif()
+  if(NOT LAPACK_FOUND OR NOT BLAS_FOUND OR USE_INTERNAL_LINALG)
     include(CheckGeneratorSupport)
     if(NOT CMAKE_GENERATOR_SUPPORT_FORTRAN)
       status(FATAL_ERROR "Cannot build internal linear algebra library as CMake build tool lacks Fortran support")
@@ -604,7 +639,7 @@ foreach(PKG_LIB POEMS ATC AWPMD H5MD MESONT)
   endif()
 endforeach()
 
-if(PKG_ELECTRODE)
+if(PKG_ELECTRODE OR PKG_ML-POD)
   target_link_libraries(lammps PRIVATE ${LAPACK_LIBRARIES})
 endif()
 
@@ -633,7 +668,7 @@ endif()
 # packages which selectively include variants based on enabled styles
 # e.g. accelerator packages
 ######################################################################
-foreach(PKG_WITH_INCL CORESHELL DPD-SMOOTH PHONON QEQ OPENMP KOKKOS OPT INTEL GPU)
+foreach(PKG_WITH_INCL CORESHELL DPD-SMOOTH MC MISC PHONON QEQ OPENMP KOKKOS OPT INTEL GPU)
   if(PKG_${PKG_WITH_INCL})
     include(Packages/${PKG_WITH_INCL})
   endif()
@@ -706,18 +741,17 @@ list(FIND LANGUAGES "Fortran" _index)
 if(_index GREATER -1)
   target_link_libraries(lammps PRIVATE ${CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES})
 endif()
-set(LAMMPS_CXX_HEADERS angle.h atom.h bond.h citeme.h comm.h compute.h dihedral.h domain.h error.h fix.h force.h group.h improper.h
-  input.h info.h kspace.h lammps.h lattice.h library.h lmppython.h lmptype.h memory.h modify.h neighbor.h neigh_list.h output.h
-  pair.h pointers.h region.h timer.h universe.h update.h utils.h variable.h)
-if(LAMMPS_EXCEPTIONS)
-  list(APPEND LAMMPS_CXX_HEADERS exceptions.h)
-endif()
+set(LAMMPS_CXX_HEADERS angle.h atom.h bond.h citeme.h comm.h command.h compute.h dihedral.h domain.h
+  error.h exceptions.h fix.h force.h group.h improper.h input.h info.h kspace.h lammps.h lattice.h
+  library.h lmppython.h lmptype.h memory.h modify.h neighbor.h neigh_list.h output.h pair.h
+  platform.h pointers.h region.h timer.h universe.h update.h utils.h variable.h)
+set(LAMMPS_FMT_HEADERS core.h format.h)
 
 set_target_properties(lammps PROPERTIES OUTPUT_NAME lammps${LAMMPS_MACHINE})
 set_target_properties(lammps PROPERTIES SOVERSION ${SOVERSION})
 set_target_properties(lammps PROPERTIES PREFIX "lib")
 target_include_directories(lammps PUBLIC $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}/lammps>)
-file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps)
+file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/fmt)
 foreach(_HEADER ${LAMMPS_CXX_HEADERS})
   add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/${_HEADER} COMMAND ${CMAKE_COMMAND} -E copy_if_different ${LAMMPS_SOURCE_DIR}/${_HEADER} ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/${_HEADER} DEPENDS ${LAMMPS_SOURCE_DIR}/${_HEADER})
   add_custom_target(${_HEADER} DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/${_HEADER})
@@ -726,6 +760,14 @@ foreach(_HEADER ${LAMMPS_CXX_HEADERS})
     install(FILES ${LAMMPS_SOURCE_DIR}/${_HEADER} DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/lammps)
   endif()
 endforeach()
+foreach(_HEADER ${LAMMPS_FMT_HEADERS})
+  add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/fmt/${_HEADER} COMMAND ${CMAKE_COMMAND} -E copy_if_different ${LAMMPS_SOURCE_DIR}/fmt/${_HEADER} ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/fmt/${_HEADER} DEPENDS ${LAMMPS_SOURCE_DIR}/fmt/${_HEADER})
+  add_custom_target(fmt_${_HEADER} DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/fmt/${_HEADER})
+  add_dependencies(lammps fmt_${_HEADER})
+  if(BUILD_SHARED_LIBS)
+    install(FILES ${LAMMPS_SOURCE_DIR}/fmt/${_HEADER} DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/lammps/fmt)
+  endif()
+endforeach()
 target_include_directories(lammps INTERFACE $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/includes>)
 add_library(LAMMPS::lammps ALIAS lammps)
 get_target_property(LAMMPS_DEFINES lammps INTERFACE_COMPILE_DEFINITIONS)
@@ -780,9 +822,13 @@ if(BUILD_SHARED_LIBS)
     set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
     find_package(PythonInterp) # Deprecated since version 3.12
     if(PYTHONINTERP_FOUND)
-        set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
+      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
     endif()
   else()
+    # backward compatibility
+    if(PYTHON_EXECUTABLE)
+      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
+    endif()
     find_package(Python COMPONENTS Interpreter)
   endif()
   if(BUILD_IS_MULTI_CONFIG)
@@ -815,16 +861,25 @@ endif()
 ###############################################################################
 if(BUILD_SHARED_LIBS OR PKG_PYTHON)
   if(CMAKE_VERSION VERSION_LESS 3.12)
+    # adjust so we find Python 3 versions before Python 2 on old systems with old CMake
+    set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
     find_package(PythonInterp) # Deprecated since version 3.12
     if(PYTHONINTERP_FOUND)
-        set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
+      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
     endif()
   else()
+    # backward compatibility
+    if(PYTHON_EXECUTABLE)
+      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
+    endif()
     find_package(Python COMPONENTS Interpreter)
   endif()
   if(Python_EXECUTABLE)
-    file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/python)
-    install(CODE "execute_process(COMMAND ${Python_EXECUTABLE} setup.py build -b ${CMAKE_BINARY_DIR}/python install --prefix=${CMAKE_INSTALL_PREFIX} --root=\$ENV{DESTDIR}/ WORKING_DIRECTORY ${LAMMPS_PYTHON_DIR})")
+    file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/python/lib)
+    file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/python/src)
+    file(COPY ${LAMMPS_SOURCE_DIR}/version.h  DESTINATION ${CMAKE_BINARY_DIR}/python/src)
+    file(COPY ${LAMMPS_PYTHON_DIR}/README ${LAMMPS_PYTHON_DIR}/pyproject.toml ${LAMMPS_PYTHON_DIR}/setup.py ${LAMMPS_PYTHON_DIR}/lammps  DESTINATION ${CMAKE_BINARY_DIR}/python/lib)
+    install(CODE "if(\"\$ENV{DESTDIR}\" STREQUAL \"\")\n execute_process(COMMAND ${Python_EXECUTABLE} -m pip install -v ${CMAKE_BINARY_DIR}/python/lib --prefix=${CMAKE_INSTALL_PREFIX})\n else()\n execute_process(COMMAND ${Python_EXECUTABLE} -m pip install -v ${CMAKE_BINARY_DIR}/python/lib --prefix=${CMAKE_INSTALL_PREFIX} --root=\$ENV{DESTDIR})\n endif()")
   endif()
 endif()
 
@@ -935,9 +990,6 @@ if(PKG_GPU)
   endif()
   message(STATUS "GPU precision:            ${GPU_PREC}")
 endif()
-if(PKG_KOKKOS)
-  message(STATUS "Kokkos Arch: ${KOKKOS_ARCH}")
-endif()
 if(PKG_KSPACE)
   message(STATUS "<<< FFT settings >>>
 -- Primary FFT lib:  ${FFT}")

cmake/Modules/FindClangFormat.cmake

@@ -1,5 +1,10 @@
 # Find clang-format
 find_program(ClangFormat_EXECUTABLE NAMES clang-format
+                                          clang-format-15.0
+                                          clang-format-14.0
+                                          clang-format-13.0
+                                          clang-format-12.0
+                                          clang-format-11.0
                                           clang-format-10.0
                                           clang-format-9.0
                                           clang-format-8.0
@@ -14,19 +19,27 @@ if(ClangFormat_EXECUTABLE)
                   OUTPUT_VARIABLE clang_format_version
                   ERROR_QUIET OUTPUT_STRIP_TRAILING_WHITESPACE)
 
-
-  if(clang_format_version MATCHES "^clang-format version .*")
-    # Arch Linux
+  if(clang_format_version MATCHES "^(Ubuntu |)clang-format version .*")
+    # Arch Linux output:
     # clang-format version 10.0.0
-
-    # Ubuntu 18.04 LTS Output
+    #
+    # Ubuntu 18.04 LTS output:
     # clang-format version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
-    string(REGEX REPLACE "clang-format version ([0-9.]+).*"
-                         "\\1"
+    #
+    # Ubuntu 20.04 LTS output:
+    # clang-format version 10.0.0-4ubuntu1
+    #
+    # Ubuntu 22.04 LTS output:
+    # Ubuntu clang-format version 14.0.0-1ubuntu1
+    #
+    # Fedora 36 output:
+    # clang-format version 14.0.5 (Fedora 14.0.5-1.fc36)
+    string(REGEX REPLACE "^(Ubuntu |)clang-format version ([0-9.]+).*"
+                         "\\2"
                          ClangFormat_VERSION
                          "${clang_format_version}")
   elseif(clang_format_version MATCHES ".*LLVM version .*")
-    # CentOS 7 Output
+    # CentOS 7 output:
     # LLVM (http://llvm.org/):
     #   LLVM version 3.4.2
     #   Optimized build.

cmake/Modules/FindCythonize.cmake

@@ -22,7 +22,7 @@ endif()
 if(Python_EXECUTABLE)
   get_filename_component(_python_path ${Python_EXECUTABLE} PATH)
   find_program(Cythonize_EXECUTABLE
-    NAMES cythonize3 cythonize cythonize.bat
+    NAMES cythonize-${Python_VERSION_MAJOR}.${Python_VERSION_MINOR} cythonize3 cythonize cythonize.bat
     HINTS ${_python_path})
 endif()
 

cmake/Modules/FindZMQ.cmake

@@ -1,19 +0,0 @@
-find_path(ZMQ_INCLUDE_DIR zmq.h)
-find_library(ZMQ_LIBRARY NAMES zmq)
-
-include(FindPackageHandleStandardArgs)
-find_package_handle_standard_args(ZMQ DEFAULT_MSG ZMQ_LIBRARY ZMQ_INCLUDE_DIR)
-
-# Copy the results to the output variables and target.
-if(ZMQ_FOUND)
-  set(ZMQ_LIBRARIES ${ZMQ_LIBRARY})
-  set(ZMQ_INCLUDE_DIRS ${ZMQ_INCLUDE_DIR})
-
-  if(NOT TARGET ZMQ::ZMQ)
-    add_library(ZMQ::ZMQ UNKNOWN IMPORTED)
-    set_target_properties(ZMQ::ZMQ PROPERTIES
-      IMPORTED_LINK_INTERFACE_LANGUAGES "C"
-      IMPORTED_LOCATION "${ZMQ_LIBRARY}"
-      INTERFACE_INCLUDE_DIRECTORIES "${ZMQ_INCLUDE_DIR}")
-  endif()
-endif()

cmake/Modules/LAMMPSInterfacePlugin.cmake

@@ -6,6 +6,9 @@ if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_BINARY_DIR})
     "Please remove CMakeCache.txt and CMakeFiles first.")
 endif()
 
+set(LAMMPS_THIRDPARTY_URL "https://download.lammps.org/thirdparty"
+  CACHE STRING "URL for thirdparty package downloads")
+
 # global LAMMPS/plugin build settings
 set(LAMMPS_SOURCE_DIR ""  CACHE PATH "Location of LAMMPS sources folder")
 if(NOT LAMMPS_SOURCE_DIR)
@@ -78,6 +81,13 @@ function(get_newest_file path variable)
   set(${variable} ${_bestfile} PARENT_SCOPE)
 endfunction()
 
+# get LAMMPS version date
+function(get_lammps_version version_header variable)
+    file(STRINGS ${version_header} line REGEX LAMMPS_VERSION)
+    string(REGEX REPLACE "#define LAMMPS_VERSION \"([0-9]+) ([A-Za-z]+) ([0-9]+)\"" "\\1\\2\\3" date "${line}")
+    set(${variable} "${date}" PARENT_SCOPE)
+endfunction()
+
 #################################################################################
 # LAMMPS C++ interface. We only need the header related parts except on windows.
 add_library(lammps INTERFACE)
@@ -89,6 +99,7 @@ endif()
 ################################################################################
 # MPI configuration
 if(NOT CMAKE_CROSSCOMPILING)
+  set(MPI_CXX_SKIP_MPICXX TRUE)
   find_package(MPI QUIET)
   option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
 else()
@@ -101,45 +112,76 @@ 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)
-    # 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_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)
+    # 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/libmpi.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()
-      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)
+      # 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/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")
   else()
     find_package(MPI REQUIRED)
     option(LAMMPS_LONGLONG_TO_LONG "Workaround if your system or MPI version does not recognize 'long long' data types" OFF)

cmake/Modules/LAMMPSUtils.cmake

@@ -24,6 +24,21 @@ function(validate_option name values)
     endif()
 endfunction(validate_option)
 
+# helper function to check for usable omp.h header
+function(check_omp_h_include)
+  find_package(OpenMP COMPONENTS CXX QUIET)
+  if(OpenMP_CXX_FOUND)
+    set(CMAKE_REQUIRED_FLAGS ${OpenMP_CXX_FLAGS})
+    set(CMAKE_REQUIRED_INCLUDES ${OpenMP_CXX_INCLUDE_DIRS})
+    set(CMAKE_REQUIRED_LINK_OPTIONS ${OpenMP_CXX_FLAGS})
+    set(CMAKE_REQUIRED_LIBRARIES ${OpenMP_CXX_LIBRARIES})
+    check_include_file_cxx(omp.h _have_omp_h)
+  else()
+    set(_have_omp_h FALSE)
+  endif()
+  set(HAVE_OMP_H_INCLUDE ${_have_omp_h} PARENT_SCOPE)
+endfunction()
+
 # helper function for getting the most recently modified file or folder from a glob pattern
 function(get_newest_file path variable)
   file(GLOB _dirs ${path})
@@ -110,14 +125,16 @@ function(FetchPotentials pkgfolder potfolder)
       math(EXPR plusone "${blank}+1")
       string(SUBSTRING ${line} 0 ${blank} pot)
       string(SUBSTRING ${line} ${plusone} -1 sum)
-      if(EXISTS ${LAMMPS_POTENTIALS_DIR}/${pot})
+      if(EXISTS "${LAMMPS_POTENTIALS_DIR}/${pot}")
         file(MD5 "${LAMMPS_POTENTIALS_DIR}/${pot}" oldsum)
       endif()
       if(NOT sum STREQUAL oldsum)
-        message(STATUS "Checking external potential ${pot} from ${LAMMPS_POTENTIALS_URL}")
-        file(DOWNLOAD "${LAMMPS_POTENTIALS_URL}/${pot}.${sum}" "${CMAKE_BINARY_DIR}/${pot}"
+        message(STATUS "Downloading external potential ${pot} from ${LAMMPS_POTENTIALS_URL}")
+        string(MD5 TMP_EXT "${CMAKE_BINARY_DIR}")
+        file(DOWNLOAD "${LAMMPS_POTENTIALS_URL}/${pot}.${sum}" "${CMAKE_BINARY_DIR}/${pot}.${TMP_EXT}"
           EXPECTED_HASH MD5=${sum} SHOW_PROGRESS)
-        file(COPY "${CMAKE_BINARY_DIR}/${pot}" DESTINATION ${LAMMPS_POTENTIALS_DIR})
+        file(COPY "${CMAKE_BINARY_DIR}/${pot}.${TMP_EXT}" DESTINATION "${LAMMPS_POTENTIALS_DIR}")
+        file(RENAME "${LAMMPS_POTENTIALS_DIR}/${pot}.${TMP_EXT}" "${LAMMPS_POTENTIALS_DIR}/${pot}")
       endif()
     endforeach()
   endif()

cmake/Modules/MPI4WIN.cmake

@@ -1,39 +1,74 @@
-# 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_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)
+# 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/libmpi.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()
-  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)
+  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/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")

cmake/Modules/Packages/GPU.cmake

@@ -233,7 +233,8 @@ elseif(GPU_API STREQUAL "OPENCL")
 elseif(GPU_API STREQUAL "HIP")
   if(NOT DEFINED HIP_PATH)
       if(NOT DEFINED ENV{HIP_PATH})
-          set(HIP_PATH "/opt/rocm/hip" CACHE PATH "Path to HIP installation")
+          message(FATAL_ERROR "GPU_API=HIP requires HIP_PATH to be defined.\n"
+          "Either pass the HIP_PATH as a CMake option via -DHIP_PATH=... or set the HIP_PATH environment variable.")
       else()
           set(HIP_PATH $ENV{HIP_PATH} CACHE PATH "Path to HIP installation")
       endif()
@@ -261,6 +262,8 @@ elseif(GPU_API STREQUAL "HIP")
 
   if(HIP_PLATFORM STREQUAL "hcc" OR HIP_PLATFORM STREQUAL "amd")
     set(HIP_ARCH "gfx906" CACHE STRING "HIP target architecture")
+  elseif(HIP_PLATFORM STREQUAL "spirv")
+    set(HIP_ARCH "spirv" CACHE STRING "HIP target architecture")
   elseif(HIP_PLATFORM STREQUAL "nvcc")
     find_package(CUDA REQUIRED)
     set(HIP_ARCH "sm_50" CACHE STRING "HIP primary CUDA architecture (e.g. sm_60)")
@@ -340,7 +343,14 @@ elseif(GPU_API STREQUAL "HIP")
           VERBATIM COMMAND ${HIP_HIPCC_EXECUTABLE} --fatbin --use_fast_math -DUSE_HIP -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES} ${HIP_CUDA_GENCODE} -I${LAMMPS_LIB_SOURCE_DIR}/gpu -o ${CUBIN_FILE} ${CU_FILE}
           DEPENDS ${CU_FILE}
           COMMENT "Generating ${CU_NAME}.cubin")
-    endif()
+    elseif(HIP_PLATFORM STREQUAL "spirv")
+      configure_file(${CU_FILE} ${CU_CPP_FILE} COPYONLY)
+
+      add_custom_command(OUTPUT ${CUBIN_FILE}
+        VERBATIM COMMAND ${HIP_HIPCC_EXECUTABLE} -c -O3 -DUSE_HIP -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES} -I${LAMMPS_LIB_SOURCE_DIR}/gpu -o ${CUBIN_FILE} ${CU_CPP_FILE}
+        DEPENDS ${CU_CPP_FILE}
+        COMMENT "Gerating ${CU_NAME}.cubin")
+      endif()
 
     add_custom_command(OUTPUT ${CUBIN_H_FILE}
       COMMAND ${CMAKE_COMMAND} -D SOURCE_DIR=${CMAKE_CURRENT_SOURCE_DIR} -D VARNAME=${CU_NAME} -D HEADER_FILE=${CUBIN_H_FILE} -D SOURCE_FILE=${CUBIN_FILE} -P ${CMAKE_CURRENT_SOURCE_DIR}/Modules/GenerateBinaryHeader.cmake

cmake/Modules/Packages/KOKKOS.cmake

@@ -15,8 +15,9 @@ if(Kokkos_ENABLE_OPENMP)
   if(NOT BUILD_OMP)
     message(FATAL_ERROR "Must enable BUILD_OMP with Kokkos_ENABLE_OPENMP")
   else()
-    if(LAMMPS_OMP_COMPAT_LEVEL LESS 4)
-      message(FATAL_ERROR "Compiler must support OpenMP 4.0 or later with Kokkos_ENABLE_OPENMP")
+    # NVHPC does not seem to provide a detectable OpenMP version, but is far beyond version 3.1
+    if((OpenMP_CXX_VERSION VERSION_LESS 3.1) AND NOT (CMAKE_CXX_COMPILER_ID STREQUAL "NVHPC"))
+      message(FATAL_ERROR "Compiler must support OpenMP 3.1 or later with Kokkos_ENABLE_OPENMP")
     endif()
   endif()
 endif()
@@ -47,8 +48,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/3.6.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "b5c44ea961031795f434002cd7b31c20" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.7.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_MD5 "84991eca9f066383abe119a5bc7a11c4" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   ExternalProject_Add(kokkos_build
@@ -72,7 +73,7 @@ if(DOWNLOAD_KOKKOS)
   add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
   add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 3.6.00 REQUIRED CONFIG)
+  find_package(Kokkos 3.7.00 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
   target_link_libraries(lmp PRIVATE Kokkos::kokkos)
 else()
@@ -123,7 +124,7 @@ set(KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/kokkos.cpp
 
 if(PKG_KSPACE)
   list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/fft3d_kokkos.cpp
-                                 ${KOKKOS_PKG_SOURCES_DIR}/gridcomm_kokkos.cpp
+                                 ${KOKKOS_PKG_SOURCES_DIR}/grid3d_kokkos.cpp
                                  ${KOKKOS_PKG_SOURCES_DIR}/remap_kokkos.cpp)
   if(Kokkos_ENABLE_CUDA)
     if(NOT (FFT STREQUAL "KISS"))
@@ -138,6 +139,12 @@ if(PKG_KSPACE)
   endif()
 endif()
 
+if(PKG_ML-IAP)
+  list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/mliap_data_kokkos.cpp
+                                 ${KOKKOS_PKG_SOURCES_DIR}/mliap_descriptor_so3_kokkos.cpp
+                                 ${KOKKOS_PKG_SOURCES_DIR}/mliap_model_linear_kokkos.cpp
+                                 ${KOKKOS_PKG_SOURCES_DIR}/mliap_so3_kokkos.cpp)
+endif()
 
 if(PKG_PHONON)
   list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/dynamical_matrix_kokkos.cpp)

cmake/Modules/Packages/LATTE.cmake

@@ -23,8 +23,9 @@ if(DOWNLOAD_LATTE)
   # CMake cannot pass BLAS or LAPACK library variable to external project if they are a list
   list(LENGTH BLAS_LIBRARIES} NUM_BLAS)
   list(LENGTH LAPACK_LIBRARIES NUM_LAPACK)
-  if((NUM_BLAS GREATER 1) OR (NUM_LAPACK GREATER 1))
-    message(FATAL_ERROR "Cannot compile downloaded LATTE library due to a technical limitation")
+  if((NUM_BLAS GREATER 1) OR (NUM_LAPACK GREATER 1) AND NOT USE_INTERNAL_LINALG)
+    message(FATAL_ERROR "Cannot compile downloaded LATTE library due to a technical limitation. "
+                        "Try to configure LAMMPS with '-D USE_INTERNAL_LINALG=on' added as a workaround.")
   endif()
 
   include(ExternalProject)

cmake/Modules/Packages/MC.cmake

@@ -0,0 +1,9 @@
+# fix sgcmc may only be installed if also the EAM pair style from MANYBODY is installed
+if(NOT PKG_MANYBODY)
+  get_property(LAMMPS_FIX_HEADERS GLOBAL PROPERTY FIX)
+  list(REMOVE_ITEM LAMMPS_FIX_HEADERS ${LAMMPS_SOURCE_DIR}/MC/fix_sgcmc.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_sgcmc.cpp)
+  set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
+endif()

cmake/Modules/Packages/MDI.cmake

@@ -8,8 +8,8 @@ option(DOWNLOAD_MDI "Download and compile the MDI library instead of using an al
 
 if(DOWNLOAD_MDI)
   message(STATUS "MDI download requested - we will build our own")
-  set(MDI_URL "https://github.com/MolSSI-MDI/MDI_Library/archive/v1.3.2.tar.gz" CACHE STRING "URL for MDI tarball")
-  set(MDI_MD5 "836f5da400d8cff0f0e4435640f9454f" CACHE STRING "MD5 checksum for MDI tarball")
+  set(MDI_URL "https://github.com/MolSSI-MDI/MDI_Library/archive/v1.4.12.tar.gz" CACHE STRING "URL for MDI tarball")
+  set(MDI_MD5 "7a222353ae8e03961d5365e6cd48baee" CACHE STRING "MD5 checksum for MDI tarball")
   mark_as_advanced(MDI_URL)
   mark_as_advanced(MDI_MD5)
   enable_language(C)
@@ -26,8 +26,21 @@ if(DOWNLOAD_MDI)
   # detect if we have python development support and thus can enable python plugins
   set(MDI_USE_PYTHON_PLUGINS OFF)
   if(CMAKE_VERSION VERSION_LESS 3.12)
+    if(NOT PYTHON_VERSION_STRING)
+      set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
+      # search for interpreter first, so we have a consistent library
+      find_package(PythonInterp) # Deprecated since version 3.12
+      if(PYTHONINTERP_FOUND)
+        set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
+      endif()
+    endif()
+    # search for the library matching the selected interpreter
+    set(Python_ADDITIONAL_VERSIONS ${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
     find_package(PythonLibs QUIET) # Deprecated since version 3.12
     if(PYTHONLIBS_FOUND)
+      if(NOT (PYTHON_VERSION_STRING STREQUAL PYTHONLIBS_VERSION_STRING))
+        message(FATAL_ERROR "Python Library version ${PYTHONLIBS_VERSION_STRING} does not match Interpreter version ${PYTHON_VERSION_STRING}")
+      endif()
       set(MDI_USE_PYTHON_PLUGINS ON)
     endif()
   else()
@@ -36,6 +49,14 @@ if(DOWNLOAD_MDI)
       set(MDI_USE_PYTHON_PLUGINS ON)
     endif()
   endif()
+  # python plugins are not supported and thus must be always off on Windows
+  if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
+    unset(Python_Development_FOUND)
+    set(MDI_USE_PYTHON_PLUGINS OFF)
+    if(CMAKE_CROSSCOMPILING)
+      set(CMAKE_INSTALL_LIBDIR lib)
+    endif()
+  endif()
 
   # download/ build MDI library
   # always build static library with -fpic
@@ -44,8 +65,9 @@ if(DOWNLOAD_MDI)
   ExternalProject_Add(mdi_build
     URL     ${MDI_URL}
     URL_MD5 ${MDI_MD5}
-    CMAKE_ARGS ${CMAKE_REQUEST_PIC}
-    -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
+    PREFIX ${CMAKE_CURRENT_BINARY_DIR}/mdi_build_ext
+    CMAKE_ARGS
+    -DCMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/mdi_build_ext
     -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
     -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
     -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
@@ -54,25 +76,26 @@ if(DOWNLOAD_MDI)
     -Dlanguage=C
     -Dlibtype=STATIC
     -Dmpi=${MDI_USE_MPI}
+    -Dplugins=ON
     -Dpython_plugins=${MDI_USE_PYTHON_PLUGINS}
     UPDATE_COMMAND ""
-    INSTALL_COMMAND ""
-    BUILD_BYPRODUCTS "<BINARY_DIR>/MDI_Library/libmdi.a"
+    INSTALL_COMMAND ${CMAKE_COMMAND} --build ${CMAKE_CURRENT_BINARY_DIR}/mdi_build_ext/src/mdi_build-build --target install
+    BUILD_BYPRODUCTS "${CMAKE_CURRENT_BINARY_DIR}/mdi_build_ext/${CMAKE_INSTALL_LIBDIR}/mdi/${CMAKE_STATIC_LIBRARY_PREFIX}mdi${CMAKE_STATIC_LIBRARY_SUFFIX}"
     )
 
   # where is the compiled library?
-  ExternalProject_get_property(mdi_build BINARY_DIR)
-  set(MDI_BINARY_DIR "${BINARY_DIR}/MDI_Library")
+  ExternalProject_get_property(mdi_build PREFIX)
   # workaround for older CMake versions
-  file(MAKE_DIRECTORY ${MDI_BINARY_DIR})
+  file(MAKE_DIRECTORY ${PREFIX}/${CMAKE_INSTALL_LIBDIR}/mdi)
+  file(MAKE_DIRECTORY ${PREFIX}/include/mdi)
 
   # create imported target for the MDI library
   add_library(LAMMPS::MDI UNKNOWN IMPORTED)
   add_dependencies(LAMMPS::MDI mdi_build)
   set_target_properties(LAMMPS::MDI PROPERTIES
-    IMPORTED_LOCATION "${MDI_BINARY_DIR}/libmdi.a"
-    INTERFACE_INCLUDE_DIRECTORIES ${MDI_BINARY_DIR}
-    )
+    IMPORTED_LOCATION "${PREFIX}/${CMAKE_INSTALL_LIBDIR}/mdi/${CMAKE_STATIC_LIBRARY_PREFIX}mdi${CMAKE_STATIC_LIBRARY_SUFFIX}"
+    INTERFACE_INCLUDE_DIRECTORIES ${PREFIX}/include/mdi
+  )
 
   set(MDI_DEP_LIBS "")
   # if compiling with python plugins we need

cmake/Modules/Packages/MISC.cmake

@@ -0,0 +1,13 @@
+# pair style and fix srp/react depend on the fixes bond/break and bond/create from the MC package
+if(NOT PKG_MC)
+  get_property(LAMMPS_FIX_HEADERS GLOBAL PROPERTY FIX)
+  list(REMOVE_ITEM LAMMPS_FIX_HEADERS ${LAMMPS_SOURCE_DIR}/MISC/fix_srp_react.h)
+  set_property(GLOBAL PROPERTY FIX "${LAMMPS_FIX_HEADERS}")
+  get_property(LAMMPS_PAIR_HEADERS GLOBAL PROPERTY PAIR)
+  list(REMOVE_ITEM LAMMPS_PAIR_HEADERS ${LAMMPS_SOURCE_DIR}/MISC/pair_srp_react.h)
+  set_property(GLOBAL PROPERTY PAIR "${LAMMPS_PAIR_HEADERS}")
+  get_target_property(LAMMPS_SOURCES lammps SOURCES)
+  list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/MISC/fix_srp_react.cpp)
+  list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/MISC/pair_srp_react.cpp)
+  set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
+endif()

cmake/Modules/Packages/ML-HDNNP.cmake

@@ -44,7 +44,9 @@ if(DOWNLOAD_N2P2)
   else()
     # get path to MPI include directory
     get_target_property(N2P2_MPI_INCLUDE MPI::MPI_CXX INTERFACE_INCLUDE_DIRECTORIES)
-    set(N2P2_PROJECT_OPTIONS "-I${N2P2_MPI_INCLUDE}")
+    foreach (_INCL ${N2P2_MPI_INCLUDE})
+      set(N2P2_PROJECT_OPTIONS "${N2P2_PROJECT_OPTIONS} -I${_INCL}")
+    endforeach()
   endif()
 
   # prefer GNU make, if available. N2P2 lib seems to need it.
@@ -75,7 +77,7 @@ if(DOWNLOAD_N2P2)
     UPDATE_COMMAND ""
     CONFIGURE_COMMAND ""
     PATCH_COMMAND sed -i -e "s/\\(MPI_\\(P\\|Unp\\)ack(\\)/\\1(void *) /" src/libnnpif/LAMMPS/InterfaceLammps.cpp
-    BUILD_COMMAND ${N2P2_MAKE} -f makefile libnnpif ${N2P2_BUILD_OPTIONS}
+    BUILD_COMMAND ${N2P2_MAKE} -C <SOURCE_DIR>/src -f makefile libnnpif ${N2P2_BUILD_OPTIONS}
     BUILD_ALWAYS YES
     INSTALL_COMMAND ""
     BUILD_IN_SOURCE 1

cmake/Modules/Packages/ML-IAP.cmake

@@ -2,7 +2,13 @@
 set(MLIAP_ENABLE_PYTHON_DEFAULT OFF)
 if(PKG_PYTHON)
   find_package(Cythonize QUIET)
-  if(Cythonize_FOUND)
+  if (CMAKE_VERSION VERSION_GREATER_EQUAL 3.14)
+    find_package(Python COMPONENTS NumPy QUIET)
+  else()
+    # assume we have NumPy
+    set(Python_NumPy_FOUND ON)
+  endif()
+  if(Cythonize_FOUND AND Python_NumPy_FOUND)
     set(MLIAP_ENABLE_PYTHON_DEFAULT ON)
   endif()
 endif()
@@ -11,6 +17,9 @@ option(MLIAP_ENABLE_PYTHON "Build ML-IAP package with Python support" ${MLIAP_EN
 
 if(MLIAP_ENABLE_PYTHON)
   find_package(Cythonize REQUIRED)
+  if (CMAKE_VERSION VERSION_GREATER_EQUAL 3.14)
+    find_package(Python COMPONENTS NumPy REQUIRED)
+  endif()
   if(NOT PKG_PYTHON)
     message(FATAL_ERROR "Must enable PYTHON package for including Python support in ML-IAP")
   endif()
@@ -25,16 +34,18 @@ if(MLIAP_ENABLE_PYTHON)
   endif()
 
   set(MLIAP_BINARY_DIR ${CMAKE_BINARY_DIR}/cython)
-  set(MLIAP_CYTHON_SRC ${LAMMPS_SOURCE_DIR}/ML-IAP/mliap_model_python_couple.pyx)
-  get_filename_component(MLIAP_CYTHON_BASE ${MLIAP_CYTHON_SRC} NAME_WE)
+  file(GLOB MLIAP_CYTHON_SRC ${LAMMPS_SOURCE_DIR}/ML-IAP/*.pyx)
   file(MAKE_DIRECTORY ${MLIAP_BINARY_DIR})
-  add_custom_command(OUTPUT  ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.cpp ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.h
-          COMMAND            ${CMAKE_COMMAND} -E copy_if_different ${MLIAP_CYTHON_SRC} ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.pyx
-          COMMAND            ${Cythonize_EXECUTABLE} -3 ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.pyx
-          WORKING_DIRECTORY  ${MLIAP_BINARY_DIR}
-          MAIN_DEPENDENCY    ${MLIAP_CYTHON_SRC}
-          COMMENT "Generating C++ sources with cythonize...")
+  foreach(MLIAP_CYTHON_FILE ${MLIAP_CYTHON_SRC})
+    get_filename_component(MLIAP_CYTHON_BASE ${MLIAP_CYTHON_FILE} NAME_WE)
+    add_custom_command(OUTPUT  ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.cpp ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.h
+            COMMAND            ${CMAKE_COMMAND} -E copy_if_different ${MLIAP_CYTHON_FILE} ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.pyx
+            COMMAND            ${Cythonize_EXECUTABLE} -3 ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.pyx
+            WORKING_DIRECTORY  ${MLIAP_BINARY_DIR}
+            MAIN_DEPENDENCY    ${MLIAP_CYTHON_FILE}
+            COMMENT "Generating C++ sources with cythonize...")
+    target_sources(lammps PRIVATE ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.cpp)
+  endforeach()
   target_compile_definitions(lammps PRIVATE -DMLIAP_PYTHON)
-  target_sources(lammps PRIVATE ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.cpp)
   target_include_directories(lammps PRIVATE ${MLIAP_BINARY_DIR})
 endif()

cmake/Modules/Packages/ML-PACE.cmake

@@ -1,6 +1,6 @@
-set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2021.10.25.fix2.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
+set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2022.10.15.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
 
-set(PACELIB_MD5 "32394d799bc282bb57696c78c456e64f" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
+set(PACELIB_MD5 "848ad6a6cc79fa82745927001fb1c9b5" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
 mark_as_advanced(PACELIB_URL)
 mark_as_advanced(PACELIB_MD5)
 
@@ -15,23 +15,9 @@ execute_process(
 )
 get_newest_file(${CMAKE_BINARY_DIR}/lammps-user-pace-* lib-pace)
 
-# enforce building libyaml-cpp as static library and turn off optional features
-set(YAML_BUILD_SHARED_LIBS OFF)
-set(YAML_CPP_BUILD_CONTRIB OFF)
-set(YAML_CPP_BUILD_TOOLS OFF)
-add_subdirectory(${lib-pace}/yaml-cpp build-yaml-cpp)
-set(YAML_CPP_INCLUDE_DIR ${lib-pace}/yaml-cpp/include)
-
-file(GLOB PACE_EVALUATOR_INCLUDE_DIR ${lib-pace}/ML-PACE)
-file(GLOB PACE_EVALUATOR_SOURCES ${lib-pace}/ML-PACE/*.cpp)
-list(FILTER PACE_EVALUATOR_SOURCES EXCLUDE REGEX pair_pace.cpp)
-
-add_library(pace STATIC ${PACE_EVALUATOR_SOURCES})
+add_subdirectory(${lib-pace} build-pace)
 set_target_properties(pace PROPERTIES CXX_EXTENSIONS ON OUTPUT_NAME lammps_pace${LAMMPS_MACHINE})
-target_include_directories(pace PUBLIC ${PACE_EVALUATOR_INCLUDE_DIR} ${YAML_CPP_INCLUDE_DIR})
 
-
-target_link_libraries(pace PRIVATE yaml-cpp-pace)
 if(CMAKE_PROJECT_NAME STREQUAL "lammps")
   target_link_libraries(lammps PRIVATE pace)
 endif()

cmake/Modules/Packages/ML-QUIP.cmake

@@ -58,12 +58,12 @@ if(DOWNLOAD_QUIP)
     BUILD_COMMAND env QUIP_ARCH=lammps make libquip
     INSTALL_COMMAND ""
     BUILD_IN_SOURCE YES
-    BUILD_BYPRODUCTS <SOURCE_DIR>/build/lammps/libquip.a
+    BUILD_BYPRODUCTS <SOURCE_DIR>/build/lammps/${CMAKE_STATIC_LIBRARY_PREFIX}quip${CMAKE_STATIC_LIBRARY_SUFFIX}
   )
   ExternalProject_get_property(quip_build SOURCE_DIR)
   add_library(LAMMPS::QUIP UNKNOWN IMPORTED)
   set_target_properties(LAMMPS::QUIP PROPERTIES
-    IMPORTED_LOCATION "${SOURCE_DIR}/build/lammps/libquip.a"
+    IMPORTED_LOCATION "${SOURCE_DIR}/build/lammps/${CMAKE_STATIC_LIBRARY_PREFIX}quip${CMAKE_STATIC_LIBRARY_SUFFIX}"
     INTERFACE_LINK_LIBRARIES "${LAPACK_LIBRARIES}")
   target_link_libraries(lammps PRIVATE LAMMPS::QUIP)
   add_dependencies(LAMMPS::QUIP quip_build)

cmake/Modules/Packages/PLUMED.cmake

@@ -47,15 +47,15 @@ if(DOWNLOAD_PLUMED)
   endif()
   message(STATUS "PLUMED download requested - we will build our own")
   if(PLUMED_MODE STREQUAL "STATIC")
-    set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumed.a")
+    set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumed${CMAKE_STATIC_LIBRARY_SUFFIX}")
   elseif(PLUMED_MODE STREQUAL "SHARED")
-    set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumed${CMAKE_SHARED_LIBRARY_SUFFIX};<INSTALL_DIR>/lib/libplumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
+    set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumed${CMAKE_SHARED_LIBRARY_SUFFIX};<INSTALL_DIR>/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
   elseif(PLUMED_MODE STREQUAL "RUNTIME")
-    set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumedWrapper.a")
+    set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumedWrapper${CMAKE_STATIC_LIBRARY_PREFIX}")
   endif()
 
-  set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.7.4/plumed-src-2.7.4.tgz" CACHE STRING "URL for PLUMED tarball")
-  set(PLUMED_MD5 "858e0b6aed173748fc85b6bc8a9dcb3e" CACHE STRING "MD5 checksum of PLUMED tarball")
+  set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.8.1/plumed-src-2.8.1.tgz" CACHE STRING "URL for PLUMED tarball")
+  set(PLUMED_MD5 "6bfe72ebdae63dc38a9ca27d9b0e08f8" CACHE STRING "MD5 checksum of PLUMED tarball")
 
   mark_as_advanced(PLUMED_URL)
   mark_as_advanced(PLUMED_MD5)
@@ -78,12 +78,12 @@ if(DOWNLOAD_PLUMED)
   add_library(LAMMPS::PLUMED UNKNOWN IMPORTED)
   add_dependencies(LAMMPS::PLUMED plumed_build)
   if(PLUMED_MODE STREQUAL "STATIC")
-    set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/libplumed.a INTERFACE_LINK_LIBRARIES "${PLUMED_LINK_LIBS};${CMAKE_DL_LIBS}")
+    set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumed${CMAKE_STATIC_LIBRARY_SUFFIX} INTERFACE_LINK_LIBRARIES "${PLUMED_LINK_LIBS};${CMAKE_DL_LIBS}")
   elseif(PLUMED_MODE STREQUAL "SHARED")
-    set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/libplumed${CMAKE_SHARED_LIBRARY_SUFFIX} INTERFACE_LINK_LIBRARIES "${INSTALL_DIR}/lib/libplumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX};${CMAKE_DL_LIBS}")
+    set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumed${CMAKE_SHARED_LIBRARY_SUFFIX} INTERFACE_LINK_LIBRARIES "${INSTALL_DIR}/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX};${CMAKE_DL_LIBS}")
   elseif(PLUMED_MODE STREQUAL "RUNTIME")
-    set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${INSTALL_DIR}/lib/libplumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
-    set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/libplumedWrapper.a INTERFACE_LINK_LIBRARIES "${CMAKE_DL_LIBS}")
+    set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${INSTALL_DIR}/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
+    set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumedWrapper${CMAKE_STATIC_LIBRARY_SUFFIX} INTERFACE_LINK_LIBRARIES "${CMAKE_DL_LIBS}")
   endif()
   set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_INCLUDE_DIRECTORIES ${INSTALL_DIR}/include)
   file(MAKE_DIRECTORY ${INSTALL_DIR}/include)
@@ -96,7 +96,7 @@ else()
   elseif(PLUMED_MODE STREQUAL "SHARED")
     include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.shared)
   elseif(PLUMED_MODE STREQUAL "RUNTIME")
-    set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${PLUMED_LIBDIR}/libplumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
+    set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${PLUMED_LIBDIR}/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
     include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.runtime)
   endif()
   set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_LINK_LIBRARIES "${PLUMED_LOAD}")

cmake/Modules/Packages/PYTHON.cmake

@@ -1,8 +1,28 @@
 if(CMAKE_VERSION VERSION_LESS 3.12)
+  if(NOT PYTHON_VERSION_STRING)
+    set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
+    # search for interpreter first, so we have a consistent library
+    find_package(PythonInterp) # Deprecated since version 3.12
+    if(PYTHONINTERP_FOUND)
+      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
+    endif()
+  endif()
+  # search for the library matching the selected interpreter
+  set(Python_ADDITIONAL_VERSIONS ${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
   find_package(PythonLibs REQUIRED) # Deprecated since version 3.12
+  if(NOT (PYTHON_VERSION_STRING STREQUAL PYTHONLIBS_VERSION_STRING))
+    message(FATAL_ERROR "Python Library version ${PYTHONLIBS_VERSION_STRING} does not match Interpreter version ${PYTHON_VERSION_STRING}")
+  endif()
   target_include_directories(lammps PRIVATE ${PYTHON_INCLUDE_DIRS})
   target_link_libraries(lammps PRIVATE ${PYTHON_LIBRARIES})
 else()
+  if(NOT Python_INTERPRETER)
+    # backward compatibility
+    if(PYTHON_EXECUTABLE)
+      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
+    endif()
+    find_package(Python COMPONENTS Interpreter)
+  endif()
   find_package(Python REQUIRED COMPONENTS Interpreter Development)
   target_link_libraries(lammps PRIVATE Python::Python)
 endif()

cmake/Modules/Packages/VTK.cmake

@@ -1,4 +1,9 @@
 find_package(VTK REQUIRED NO_MODULE)
-include(${VTK_USE_FILE})
 target_compile_definitions(lammps PRIVATE -DLAMMPS_VTK)
-target_link_libraries(lammps PRIVATE ${VTK_LIBRARIES})
+if (VTK_MAJOR_VERSION VERSION_LESS 9.0)
+  include(${VTK_USE_FILE})
+  target_link_libraries(lammps PRIVATE ${VTK_LIBRARIES})
+else()
+  target_link_libraries(lammps PRIVATE VTK::CommonCore VTK::IOCore VTK::CommonDataModel VTK::IOXML VTK::IOLegacy VTK::IOParallelXML)
+  vtk_module_autoinit(TARGETS lammps MODULES VTK::CommonCore VTK::IOCore VTK::CommonDataModel VTK::IOXML VTK::IOLegacy VTK::IOParallelXML)
+endif()

cmake/presets/all_off.cmake

@@ -3,6 +3,7 @@
 
 set(ALL_PACKAGES
   ADIOS
+  AMOEBA
   ASPHERE
   ATC
   AWPMD
@@ -11,7 +12,7 @@ set(ALL_PACKAGES
   BPM
   BROWNIAN
   CG-DNA
-  CG-SDK
+  CG-SPICA
   CLASS2
   COLLOID
   COLVARS
@@ -55,6 +56,7 @@ set(ALL_PACKAGES
   ML-HDNNP
   ML-IAP
   ML-PACE
+  ML-POD
   ML-QUIP
   ML-RANN
   ML-SNAP

cmake/presets/all_on.cmake

@@ -5,6 +5,7 @@
 
 set(ALL_PACKAGES
   ADIOS
+  AMOEBA
   ASPHERE
   ATC
   AWPMD
@@ -13,7 +14,7 @@ set(ALL_PACKAGES
   BPM
   BROWNIAN
   CG-DNA
-  CG-SDK
+  CG-SPICA
   CLASS2
   COLLOID
   COLVARS
@@ -57,6 +58,7 @@ set(ALL_PACKAGES
   ML-HDNNP
   ML-IAP
   ML-PACE
+  ML-POD
   ML-QUIP
   ML-RANN
   ML-SNAP

cmake/presets/clang.cmake

@@ -3,6 +3,13 @@
 # prefer flang over gfortran, if available
 find_program(CLANG_FORTRAN NAMES flang gfortran f95)
 set(ENV{OMPI_FC} ${CLANG_FORTRAN})
+get_filename_component(_tmp_fc ${CLANG_FORTRAN} NAME)
+if (_tmp_fc STREQUAL "flang")
+  set(FC_STD_VERSION "-std=f2018")
+  set(BUILD_MPI OFF)
+else()
+  set(FC_STD_VERSION "-std=f2003")
+endif()
 
 set(CMAKE_CXX_COMPILER "clang++" CACHE STRING "" FORCE)
 set(CMAKE_C_COMPILER "clang" CACHE STRING "" FORCE)
@@ -10,9 +17,9 @@ set(CMAKE_Fortran_COMPILER ${CLANG_FORTRAN} CACHE STRING "" FORCE)
 set(CMAKE_CXX_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
 set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
 set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
-set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -Wextra -g -std=f2003" CACHE STRING "" FORCE)
-set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
-set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -Wextra -g ${FC_STD_VERSION}" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG ${FC_STD_VERSION}" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG ${FC_STD_VERSION}" CACHE STRING "" FORCE)
 set(CMAKE_C_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
 set(CMAKE_C_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
 set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
@@ -21,10 +28,3 @@ set(MPI_CXX "clang++" CACHE STRING "" FORCE)
 set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
 
 unset(HAVE_OMP_H_INCLUDE CACHE)
-set(OpenMP_C "clang" CACHE STRING "" FORCE)
-set(OpenMP_C_FLAGS "-fopenmp" CACHE STRING "" FORCE)
-set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
-set(OpenMP_CXX "clang++" 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/gcc.cmake

@@ -19,11 +19,3 @@ set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -Og -g -std=f2003" CACHE STRING "" FORCE)
 set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-g -O2 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
 set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
 unset(HAVE_OMP_H_INCLUDE CACHE)
-
-set(OpenMP_C "gcc" CACHE STRING "" FORCE)
-set(OpenMP_C_FLAGS "-fopenmp" CACHE STRING "" FORCE)
-set(OpenMP_C_LIB_NAMES "gomp" CACHE STRING "" FORCE)
-set(OpenMP_CXX "g++" CACHE STRING "" FORCE)
-set(OpenMP_CXX_FLAGS "-fopenmp" CACHE STRING "" FORCE)
-set(OpenMP_CXX_LIB_NAMES "gomp" CACHE STRING "" FORCE)
-set(OpenMP_omp_LIBRARY "libgomp.so" CACHE PATH "" FORCE)

cmake/presets/intel.cmake

@@ -1,4 +1,4 @@
-# preset that will enable Intel compilers with support for MPI and OpenMP (on Linux boxes)
+# preset that will enable the classic Intel compilers with support for MPI and OpenMP (on Linux boxes)
 
 set(CMAKE_CXX_COMPILER "icpc" CACHE STRING "" FORCE)
 set(CMAKE_C_COMPILER "icc" CACHE STRING "" FORCE)
@@ -18,11 +18,11 @@ set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
 
 unset(HAVE_OMP_H_INCLUDE CACHE)
 set(OpenMP_C "icc" CACHE STRING "" FORCE)
-set(OpenMP_C_FLAGS "-qopenmp" CACHE STRING "" FORCE)
+set(OpenMP_C_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
 set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
 set(OpenMP_CXX "icpc" CACHE STRING "" FORCE)
-set(OpenMP_CXX_FLAGS "-qopenmp" CACHE STRING "" FORCE)
+set(OpenMP_CXX_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
 set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
-set(OpenMP_Fortran_FLAGS "-qopenmp" CACHE STRING "" FORCE)
+set(OpenMP_Fortran_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
 set(OpenMP_omp_LIBRARY "libiomp5.so" CACHE PATH "" FORCE)
 

cmake/presets/mingw-cross.cmake

@@ -1,4 +1,5 @@
 set(WIN_PACKAGES
+  AMOEBA
   ASPHERE
   ATC
   AWPMD
@@ -7,7 +8,7 @@ set(WIN_PACKAGES
   BPM
   BROWNIAN
   CG-DNA
-  CG-SDK
+  CG-SPICA
   CLASS2
   COLLOID
   COLVARS
@@ -46,6 +47,7 @@ set(WIN_PACKAGES
   MISC
   ML-HDNNP
   ML-IAP
+  ML-POD
   ML-RANN
   ML-SNAP
   MOFFF

cmake/presets/most.cmake

@@ -3,13 +3,14 @@
 # are removed. The resulting binary should be able to run most inputs.
 
 set(ALL_PACKAGES
+  AMOEBA
   ASPHERE
   BOCS
   BODY
   BPM
   BROWNIAN
   CG-DNA
-  CG-SDK
+  CG-SPICA
   CLASS2
   COLLOID
   COLVARS
@@ -40,6 +41,7 @@ set(ALL_PACKAGES
   MEAM
   MISC
   ML-IAP
+  ML-POD
   ML-SNAP
   MOFFF
   MOLECULE

cmake/presets/nvhpc.cmake

@@ -0,0 +1,9 @@
+# preset that will enable Nvidia HPC SDK compilers with support for MPI and OpenMP (on Linux boxes)
+
+set(CMAKE_CXX_COMPILER "nvc++" CACHE STRING "" FORCE)
+set(CMAKE_C_COMPILER "nvc" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_COMPILER "nvfortran" CACHE STRING "" FORCE)
+set(MPI_CXX "nvc++" CACHE STRING "" FORCE)
+set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
+unset(HAVE_OMP_H_INCLUDE CACHE)
+

cmake/presets/oneapi.cmake

@@ -18,11 +18,11 @@ set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
 
 unset(HAVE_OMP_H_INCLUDE CACHE)
 set(OpenMP_C "icx" CACHE STRING "" FORCE)
-set(OpenMP_C_FLAGS "-qopenmp" CACHE STRING "" FORCE)
+set(OpenMP_C_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
 set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
 set(OpenMP_CXX "icpx" CACHE STRING "" FORCE)
-set(OpenMP_CXX_FLAGS "-qopenmp" CACHE STRING "" FORCE)
+set(OpenMP_CXX_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
 set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
-set(OpenMP_Fortran_FLAGS "-qopenmp" CACHE STRING "" FORCE)
+set(OpenMP_Fortran_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
 set(OpenMP_omp_LIBRARY "libiomp5.so" CACHE PATH "" FORCE)
 

cmake/presets/pedantic.cmake

@@ -1,4 +1,4 @@
-# preset that will restore gcc/g++ with support for MPI and OpenMP (on Linux boxes)
+# preset that will set gcc/g++ with extra warnings enabled and support for MPI and OpenMP (on Linux boxes)
 
 set(CMAKE_CXX_COMPILER "g++" CACHE STRING "" FORCE)
 set(CMAKE_C_COMPILER "gcc" CACHE STRING "" FORCE)
@@ -17,10 +17,3 @@ set(MPI_Fortran "gfortran" CACHE STRING "" FORCE)
 set(MPI_Fortran_COMPILER "mpifort" CACHE STRING "" FORCE)
 unset(HAVE_OMP_H_INCLUDE CACHE)
 
-set(OpenMP_C "gcc" CACHE STRING "" FORCE)
-set(OpenMP_C_FLAGS "-fopenmp" CACHE STRING "" FORCE)
-set(OpenMP_C_LIB_NAMES "gomp" CACHE STRING "" FORCE)
-set(OpenMP_CXX "g++" CACHE STRING "" FORCE)
-set(OpenMP_CXX_FLAGS "-fopenmp" CACHE STRING "" FORCE)
-set(OpenMP_CXX_LIB_NAMES "gomp" CACHE STRING "" FORCE)
-set(OpenMP_omp_LIBRARY "libgomp.so" CACHE PATH "" FORCE)

cmake/presets/pgi.cmake

@@ -7,10 +7,3 @@ set(MPI_CXX "pgc++" CACHE STRING "" FORCE)
 set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
 unset(HAVE_OMP_H_INCLUDE CACHE)
 
-set(OpenMP_C "pgcc" CACHE STRING "" FORCE)
-set(OpenMP_C_FLAGS "-mp" CACHE STRING "" FORCE)
-set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
-set(OpenMP_CXX "pgc++" CACHE STRING "" FORCE)
-set(OpenMP_CXX_FLAGS "-mp" CACHE STRING "" FORCE)
-set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
-set(OpenMP_omp_LIBRARY "libomp.so" CACHE PATH "" FORCE)

cmake/presets/windows.cmake

@@ -1,11 +1,12 @@
 set(WIN_PACKAGES
+  AMOEBA
   ASPHERE
   BOCS
   BODY
   BPM
   BROWNIAN
   CG-DNA
-  CG-SDK
+  CG-SPICA
   CLASS2
   COLLOID
   COLVARS

doc/Makefile

@@ -38,16 +38,14 @@ endif
 # override settings for PIP commands
 # PIP_OPTIONS = --cert /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt --proxy http://proxy.mydomain.org
 
-#SPHINXEXTRA = -j $(shell $(PYTHON) -c 'import multiprocessing;print(multiprocessing.cpu_count())') $(shell test -f $(BUILDDIR)/doxygen/xml/run.stamp && printf -- "-E")
-
 # temporarily disable caching so that the hack for the sphinx-tabs extensions to get proper non-html output works
-SPHINXEXTRA = -E -j $(shell $(PYTHON) -c 'import multiprocessing;print(multiprocessing.cpu_count())')
+SPHINXEXTRA = -j $(shell $(PYTHON) -c 'import multiprocessing;print(multiprocessing.cpu_count())')
 
 # grab list of sources from doxygen config file.
 # 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 rst html pdf spelling anchor_check style_check char_check xmlgen fasthtml
+.PHONY: help clean-all clean clean-spelling epub mobi html pdf spelling anchor_check style_check char_check role_check xmlgen fasthtml
 
 # ------------------------------------------
 
@@ -89,6 +87,8 @@ html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
 	@$(MAKE) $(MFLAGS) -C graphviz all
 	@(\
 		. $(VENV)/bin/activate ; env PYTHONWARNINGS= \
+		sphinx-build -E $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
+		touch $(RSTDIR)/Fortran.rst ;\
 		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;\
@@ -96,6 +96,7 @@ html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
 		rst_anchor_check src/*.rst ;\
 		python $(BUILDDIR)/utils/check-packages.py -s ../src -d src ;\
 		env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst ;\
+		env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst ;\
 		python $(BUILDDIR)/utils/check-styles.py -s ../src -d src ;\
 		echo "############################################" ;\
 		deactivate ;\
@@ -114,7 +115,9 @@ fasthtml: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
 	@mkdir -p fasthtml
 	@(\
 		. $(VENV)/bin/activate ; env PYTHONWARNINGS= \
-		sphinx-build -j 4 -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/fasthtml/doctrees $(RSTDIR) fasthtml ;\
+		sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/fasthtml/doctrees $(RSTDIR) fasthtml ;\
+		touch $(RSTDIR)/Fortran.rst ;\
+		sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/fasthtml/doctrees $(RSTDIR) fasthtml ;\
 		deactivate ;\
 	)
 	@rm -rf fasthtml/_sources
@@ -144,6 +147,8 @@ epub: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
 	@cp src/JPG/*.* epub/JPG
 	@(\
 		. $(VENV)/bin/activate ;\
+		sphinx-build -E $(SPHINXEXTRA) -b epub -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
+		touch $(RSTDIR)/Fortran.rst ;\
 		sphinx-build $(SPHINXEXTRA) -b epub -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
 		rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
 		deactivate ;\
@@ -163,12 +168,15 @@ pdf: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
 	@if [ "$(HAS_PDFLATEX)" == "NO" ] ; then echo "PDFLaTeX or latexmk were not found! Please check README for further instructions" 1>&2; exit 1; fi
 	@(\
 		. $(VENV)/bin/activate ; env PYTHONWARNINGS= \
-		sphinx-build $(SPHINXEXTRA) -b latex -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) latex ;\
+		sphinx-build -E $(SPHINXEXTRA) -b latex -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) latex ;\
+		touch $(RSTDIR)/Fortran.rst ;\
+		sphinx-build  $(SPHINXEXTRA) -b latex -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) latex ;\
 		rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
 		echo "############################################" ;\
 		rst_anchor_check src/*.rst ;\
 		python utils/check-packages.py -s ../src -d src ;\
 		env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst ;\
+		env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst ;\
 		python utils/check-styles.py -s ../src -d src ;\
 		echo "############################################" ;\
 		deactivate ;\
@@ -214,6 +222,9 @@ package_check : $(VENV)
 char_check :
 	@( env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst && exit 1 || : )
 
+role_check :
+	@( env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst && exit 1 || : )
+
 xmlgen : doxygen/xml/index.xml
 
 doxygen/Doxyfile: doxygen/Doxyfile.in
@@ -242,7 +253,6 @@ $(MATHJAX):
 $(ANCHORCHECK): $(VENV)
 	@( \
 		. $(VENV)/bin/activate; \
-		(cd utils/converters;\
-		python setup.py develop);\
+		pip $(PIP_OPTIONS) install -e utils/converters;\
 		deactivate;\
 	)

doc/lammps.1

@@ -1,7 +1,7 @@
-.TH LAMMPS "1" "23 June 2022" "2022-6-23"
+.TH LAMMPS "1" "22 December 2022" "2022-12-22"
 .SH NAME
 .B LAMMPS
-\- Molecular Dynamics Simulator.  Version 23 June 2022
+\- Molecular Dynamics Simulator.  Version 22 December 2022
 
 .SH SYNOPSIS
 .B lmp
@@ -161,7 +161,7 @@ list references for specific cite-able features used during a
 run.
 .TP
 \fB\-pk <style> [options]\fR or \fB\-package <style> [options]\fR
-Invoke the \fBpackage\R command with <style> and optional arguments.
+Invoke the \fBpackage\fR command with <style> and optional arguments.
 The syntax is the same as if the command appeared in an input script.
 For example "-pk gpu 2" is the same as "package gpu 2" in the input
 script. The possible styles and options are discussed in the

doc/src/Bibliography.rst

@@ -314,7 +314,7 @@ Bibliography
    Espanol, Revenga, Physical Review E, 67, 026705 (2003).
 
 **(Espanol1997)**
-   Espanol, Europhys Lett, 40(6): 631-636 (1997).  DOI: 10.1209/epl/i1997-00515-8
+   Espanol, Europhys Lett, 40(6): 631-636 (1997).  DOI:10.1209/epl/i1997-00515-8
 
 **(Evans and Morriss)**
    Evans and Morriss, Phys Rev A, 30, 1528 (1984).
@@ -368,7 +368,7 @@ Bibliography
    Frenkel and Smit, Understanding Molecular Simulation, Academic Press, London, 2002.
 
 **(GLE4MD)**
-   `http://gle4md.org/ <http://gle4md.org/>`_
+   `https://gle4md.org/ <https://gle4md.org/>`_
 
 **(Gao)**
    Gao and Weber, Nuclear Instruments and Methods in Physics Research B 191 (2012) 504.
@@ -401,13 +401,13 @@ Bibliography
    Hayre, and Farago, Comp Phys Comm, 185, 524 (2014)
 
 **(Groot)**
-   Groot and Warren, J Chem Phys, 107: 4423-4435 (1997).  DOI: 10.1063/1.474784
+   Groot and Warren, J Chem Phys, 107: 4423-4435 (1997).  DOI:10.1063/1.474784
 
 **(Guenole)**
    Guenole, Noehring, Vaid, Houlle, Xie, Prakash, Bitzek, Comput Mater Sci, 175, 109584 (2020).
 
 **(Gullet)**
-   Gullet, Wagner, Slepoy, SANDIA Report 2003-8782 (2003).
+   Gullet, Wagner, Slepoy, SANDIA Report 2003-8782 (2003). DOI:10.2172/918395
 
 **(Guo)**
    Guo and Thirumalai, Journal of Molecular Biology, 263, 323-43 (1996).
@@ -461,7 +461,7 @@ Bibliography
    Hunt, Mol Simul, 42, 347 (2016).
 
 **(IPI)**
-   `http://epfl-cosmo.github.io/gle4md/index.html?page=ipi <http://epfl-cosmo.github.io/gle4md/index.html?page=ipi>`_
+   `https://ipi-code.org/ <https://ipi-code.org/>`
 
 **(IPI-CPC)**
    Ceriotti, More and Manolopoulos, Comp Phys Comm, 185, 1019-1026 (2014).
@@ -605,16 +605,16 @@ Bibliography
    I.\  Leven et al, J. Chem.Theory Comput. 12, 2896-905 (2016).
 
 **(Li2013_POF)**
-   Li, Hu, Wang, Ma, Zhou, Phys Fluids, 25: 072103 (2013). DOI: 10.1063/1.4812366.
+   Li, Hu, Wang, Ma, Zhou, Phys Fluids, 25: 072103 (2013). DOI:10.1063/1.4812366.
 
 **(Li2014_JCP)**
-   Li, Tang, Lei, Caswell, Karniadakis, J Comput Phys, 265: 113-127 (2014).  DOI: 10.1016/j.jcp.2014.02.003.
+   Li, Tang, Lei, Caswell, Karniadakis, J Comput Phys, 265: 113-127 (2014).  DOI:10.1016/j.jcp.2014.02.003.
 
 **(Li2015_CC)**
-   Li, Tang, Li, Karniadakis, Chem Commun, 51: 11038-11040 (2015).  DOI: 10.1039/C5CC01684C.
+   Li, Tang, Li, Karniadakis, Chem Commun, 51: 11038-11040 (2015).  DOI:10.1039/C5CC01684C.
 
 **(Li2015_JCP)**
-   Li, Yazdani, Tartakovsky, Karniadakis, J Chem Phys, 143: 014101 (2015).  DOI: 10.1063/1.4923254.
+   Li, Yazdani, Tartakovsky, Karniadakis, J Chem Phys, 143: 014101 (2015).  DOI:10.1063/1.4923254.
 
 **(Lisal)**
    M.\  Lisal, J.K. Brennan, J. Bonet Avalos, "Dissipative particle dynamics at isothermal, isobaric, isoenergetic, and isoenthalpic conditions using Shardlow-like splitting algorithms.",
@@ -733,8 +733,8 @@ Bibliography
 **(Mishin)**
    Mishin, Mehl, and Papaconstantopoulos, Acta Mater, 53, 4029 (2005).
 
-**(Mitchell and Finchham)**
-   Mitchell, Finchham, J Phys Condensed Matter, 5, 1031-1038 (1993).
+**(Mitchell and Fincham)**
+   Mitchell, Fincham, J Phys Condensed Matter, 5, 1031-1038 (1993).
 
 **(Mitchell2011)**
    Mitchell. A non-local, ordinary-state-based viscoelasticity model for peridynamics. Sandia National Lab Report, 8064:1-28 (2011).
@@ -875,7 +875,7 @@ Bibliography
    G.A. Tribello, M. Bonomi, D. Branduardi, C. Camilloni and G. Bussi, Comp. Phys. Comm 185, 604 (2014)
 
 **(Paquay)**
-   Paquay and Kusters, Biophys. J., 110, 6, (2016). preprint available at `arXiv:1411.3019 <http://arxiv.org/abs/1411.3019/>`_.
+   Paquay and Kusters, Biophys. J., 110, 6, (2016). preprint available at `arXiv:1411.3019 <https://arxiv.org/abs/1411.3019/>`_.
 
 **(Park)**
    Park, Schulten, J. Chem. Phys. 120 (13), 5946 (2004)
@@ -1373,7 +1373,7 @@ Bibliography
    Zhu, Tajkhorshid, and Schulten, Biophys. J. 83, 154 (2002).
 
 **(Ziegler)**
-   J.F. Ziegler, J. P. Biersack and U. Littmark, "The Stopping and Range of Ions in Matter," Volume 1, Pergamon, 1985.
+   J.F. Ziegler, J. P. Biersack and U. Littmark, "The Stopping and Range of Ions in Matter", Volume 1, Pergamon, 1985.
 
 **(Zimmerman2004)**
    Zimmerman, JA; Webb, EB; Hoyt, JJ;. Jones, RE; Klein, PA; Bammann, DJ, "Calculation of stress in atomistic simulation." Special Issue of Modelling and Simulation in Materials Science and Engineering (2004),12:S319.

doc/src/Build_development.rst

@@ -140,13 +140,23 @@ of the LAMMPS project on GitHub.
 The unit testing facility is integrated into the CMake build process
 of the LAMMPS source code distribution itself.  It can be enabled by
 setting ``-D ENABLE_TESTING=on`` during the CMake configuration step.
-It requires the `YAML <http://pyyaml.org/>`_ library and development
+It requires the `YAML <https://pyyaml.org/>`_ library and development
 headers (if those are not found locally a recent version will be
 downloaded and compiled along with LAMMPS and the test program) to
 compile and will download and compile a specific recent version of the
 `Googletest <https://github.com/google/googletest/>`_ C++ test framework
 for implementing the tests.
 
+.. admonition:: Software version requirements for testing
+   :class: note
+
+   The compiler and library version requirements for the testing
+   framework are more strict than for the main part of LAMMPS.  For
+   example the default GNU C++ and Fortran compilers of RHEL/CentOS 7.x
+   (version 4.8.x) are not sufficient.  The CMake configuration will try
+   to detect compatible versions and either skip incompatible tests or
+   stop with an error.
+
 After compilation is complete, the unit testing is started in the build
 folder using the ``ctest`` command, which is part of the CMake software.
 The output of this command will be looking something like this::

doc/src/Build_extras.rst

@@ -36,6 +36,7 @@ This is the list of packages that may require additional steps.
    * :ref:`AWPMD <awpmd>`
    * :ref:`COLVARS <colvars>`
    * :ref:`COMPRESS <compress>`
+   * :ref:`ELECTRODE <electrode>`
    * :ref:`GPU <gpu>`
    * :ref:`H5MD <h5md>`
    * :ref:`INTEL <intel>`
@@ -48,6 +49,7 @@ This is the list of packages that may require additional steps.
    * :ref:`ML-HDNNP <ml-hdnnp>`
    * :ref:`ML-IAP <mliap>`
    * :ref:`ML-PACE <ml-pace>`
+   * :ref:`ML-POD <ml-pod>`
    * :ref:`ML-QUIP <ml-quip>`
    * :ref:`MOLFILE <molfile>`
    * :ref:`MSCG <mscg>`
@@ -123,6 +125,7 @@ CMake build
    -D GPU_API=value             # value = opencl (default) or cuda or hip
    -D GPU_PREC=value            # precision setting
                                 # value = double or mixed (default) or single
+   -D HIP_PATH                  # path to HIP installation. Must be set if GPU_API=HIP
    -D GPU_ARCH=value            # primary GPU hardware choice for GPU_API=cuda
                                 # value = sm_XX, see below
                                 # default is sm_50
@@ -179,10 +182,17 @@ set appropriate environment variables. Some variables such as
 :code:`HCC_AMDGPU_TARGET` (for ROCm <= 4.0) or :code:`CUDA_PATH` are necessary for :code:`hipcc`
 and the linker to work correctly.
 
+Using CHIP-SPV implementation of HIP is now supported. It allows one to run HIP
+code on Intel GPUs via the OpenCL or Level Zero backends. To use CHIP-SPV, you must
+set :code:`-DHIP_USE_DEVICE_SORT=OFF` in your CMake command line as CHIP-SPV does not
+yet support hipCUB. The use of HIP for Intel GPUs is still experimental so you
+should only use this option in preparations to run on Aurora system at ANL.
+
 .. code:: bash
 
    # AMDGPU target (ROCm <= 4.0)
    export HIP_PLATFORM=hcc
+   export HIP_PATH=/path/to/HIP/install
    export HCC_AMDGPU_TARGET=gfx906
    cmake -D PKG_GPU=on -D GPU_API=HIP -D HIP_ARCH=gfx906 -D CMAKE_CXX_COMPILER=hipcc ..
    make -j 4
@@ -191,6 +201,7 @@ and the linker to work correctly.
 
    # AMDGPU target (ROCm >= 4.1)
    export HIP_PLATFORM=amd
+   export HIP_PATH=/path/to/HIP/install
    cmake -D PKG_GPU=on -D GPU_API=HIP -D HIP_ARCH=gfx906 -D CMAKE_CXX_COMPILER=hipcc ..
    make -j 4
 
@@ -199,10 +210,20 @@ and the linker to work correctly.
    # CUDA target (not recommended, use GPU_ARCH=cuda)
    # !!! DO NOT set CMAKE_CXX_COMPILER !!!
    export HIP_PLATFORM=nvcc
+   export HIP_PATH=/path/to/HIP/install
    export CUDA_PATH=/usr/local/cuda
    cmake -D PKG_GPU=on -D GPU_API=HIP -D HIP_ARCH=sm_70 ..
    make -j 4
 
+.. code:: bash
+
+   # SPIR-V target (Intel GPUs)
+   export HIP_PLATFORM=spirv
+   export HIP_PATH=/path/to/HIP/install
+   export CMAKE_CXX_COMPILER=<hipcc/clang++>
+   cmake -D PKG_GPU=on -D GPU_API=HIP ..
+   make -j 4
+
 Traditional make
 ^^^^^^^^^^^^^^^^
 
@@ -215,7 +236,7 @@ LAMMPS code.  This also applies to the ``-DLAMMPS_BIGBIG``\ ,
 Makefile you use.
 
 You can also build the library in one step from the ``lammps/src`` dir,
-using a command like these, which simply invoke the ``lib/gpu/Install.py``
+using a command like these, which simply invokes the ``lib/gpu/Install.py``
 script with the specified args:
 
 .. code-block:: bash
@@ -295,7 +316,7 @@ detailed information is available at:
 
 In addition to installing the KIM API, it is also necessary to install the
 library of KIM models (interatomic potentials).
-See `Obtaining KIM Models <http://openkim.org/doc/usage/obtaining-models>`_ to
+See `Obtaining KIM Models <https://openkim.org/doc/usage/obtaining-models>`_ to
 learn how to install a pre-build binary of the OpenKIM Repository of Models.
 See the list of all KIM models here: https://openkim.org/browse/models
 
@@ -331,7 +352,7 @@ minutes to hours) to build.  Of course you only need to do that once.)
       You can download and build the KIM library manually if you prefer;
       follow the instructions in ``lib/kim/README``.  You can also do
       this in one step from the lammps/src directory, using a command like
-      these, which simply invoke the ``lib/kim/Install.py`` script with
+      these, which simply invokes the ``lib/kim/Install.py`` script with
       the specified args.
 
       .. code-block:: bash
@@ -413,7 +434,7 @@ Enabling the extra unit tests have some requirements,
   ``EAM_Dynamo_MendelevAckland_2007v3_Zr__MO_004835508849_000``,
   ``EAM_Dynamo_ErcolessiAdams_1994_Al__MO_123629422045_005``, and
   ``LennardJones612_UniversalShifted__MO_959249795837_003`` KIM models.
-  See `Obtaining KIM Models <http://openkim.org/doc/usage/obtaining-models>`_
+  See `Obtaining KIM Models <https://openkim.org/doc/usage/obtaining-models>`_
   to learn how to install a pre-built binary of the OpenKIM Repository of
   Models or see
   `Installing KIM Models <https://openkim.org/doc/usage/obtaining-models/#installing_models>`_
@@ -464,6 +485,9 @@ They must be specified in uppercase.
    *  - **Arch-ID**
       - **HOST or GPU**
       - **Description**
+   *  - NATIVE
+      - HOST
+      - Local machine
    *  - AMDAVX
       - HOST
       - AMD 64-bit x86 CPU (AVX 1)
@@ -503,9 +527,21 @@ They must be specified in uppercase.
    *  - BDW
       - HOST
       - Intel Broadwell Xeon E-class CPU (AVX 2 + transactional mem)
+   *  - SKL
+      - HOST
+      - Intel Skylake Client CPU
    *  - SKX
       - HOST
-      - Intel Sky Lake Xeon E-class HPC CPU (AVX512 + transactional mem)
+      - Intel Skylake Xeon Server CPU (AVX512)
+   *  - ICL
+      - HOST
+      - Intel Ice Lake Client CPU (AVX512)
+   *  - ICX
+      - HOST
+      - Intel Ice Lake Xeon Server CPU (AVX512)
+   *  - SPR
+      - HOST
+      - Intel Sapphire Rapids Xeon Server CPU (AVX512)
    *  - KNC
       - HOST
       - Intel Knights Corner Xeon Phi
@@ -577,7 +613,10 @@ They must be specified in uppercase.
       - AMD GPU MI100 GFX908
    *  - VEGA90A
       - GPU
-      - AMD GPU
+      - AMD GPU MI200 GFX90A
+   *  - INTEL_GEN
+      - GPU
+      - SPIR64-based devices, e.g. Intel GPUs, using JIT
    *  - INTEL_DG1
       - GPU
       - Intel Iris XeMAX GPU
@@ -592,9 +631,12 @@ They must be specified in uppercase.
       - Intel GPU Gen12LP
    *  - INTEL_XEHP
       - GPU
-      - Intel GPUs Xe-HP
+      - Intel GPU Xe-HP
+   *  - INTEL_PVC
+      - GPU
+      - Intel GPU Ponte Vecchio
 
-This list was last updated for version 3.5.0 of the Kokkos library.
+This list was last updated for version 3.7.0 of the Kokkos library.
 
 .. tabs::
 
@@ -788,8 +830,10 @@ library.
 
       .. code-block:: bash
 
-         -D DOWNLOAD_LATTE=value    # download LATTE for build, value = no (default) or yes
-         -D LATTE_LIBRARY=path      # LATTE library file (only needed if a custom location)
+         -D DOWNLOAD_LATTE=value      # download LATTE for build, value = no (default) or yes
+         -D LATTE_LIBRARY=path        # LATTE library file (only needed if a custom location)
+         -D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
+                                      #   value = no (default) or yes
 
       If ``DOWNLOAD_LATTE`` is set, the LATTE library will be downloaded
       and built inside the CMake build directory.  If the LATTE library
@@ -797,6 +841,13 @@ library.
       ``LATTE_LIBRARY`` is the filename (plus path) of the LATTE library
       file, not the directory the library file is in.
 
+      The LATTE library requires LAPACK (and BLAS) and CMake can identify
+      their locations and pass that info to the LATTE build script. But
+      on some systems this triggers a (current) limitation of CMake and
+      the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
+      those cases to use the bundled linear algebra library and work around
+      the limitation.
+
    .. tab:: Traditional make
 
       You can download and build the LATTE library manually if you
@@ -905,7 +956,7 @@ more details.
       You can download and build the MS-CG library manually if you
       prefer; follow the instructions in ``lib/mscg/README``\ .  You can
       also do it in one step from the ``lammps/src`` dir, using a
-      command like these, which simply invoke the
+      command like these, which simply invokes the
       ``lib/mscg/Install.py`` script with the specified args:
 
       .. code-block:: bash
@@ -962,7 +1013,7 @@ POEMS package
       ``lib/poems``\ .  You can do this manually if you prefer; follow
       the instructions in ``lib/poems/README``\ .  You can also do it in
       one step from the ``lammps/src`` dir, using a command like these,
-      which simply invoke the ``lib/poems/Install.py`` script with the
+      which simply invokes the ``lib/poems/Install.py`` script with the
       specified args:
 
       .. code-block:: bash
@@ -1025,7 +1076,7 @@ VORONOI package
 -----------------------------
 
 To build with this package, you must download and build the
-`Voro++ library <http://math.lbl.gov/voro++>`_ or install a
+`Voro++ library <https://math.lbl.gov/voro++>`_ or install a
 binary package provided by your operating system.
 
 .. tabs::
@@ -1051,7 +1102,7 @@ binary package provided by your operating system.
       You can download and build the Voro++ library manually if you
       prefer; follow the instructions in ``lib/voronoi/README``.  You
       can also do it in one step from the ``lammps/src`` dir, using a
-      command like these, which simply invoke the
+      command like these, which simply invokes the
       ``lib/voronoi/Install.py`` script with the specified args:
 
       .. code-block:: bash
@@ -1130,7 +1181,7 @@ The ATC package requires the MANYBODY package also be installed.
       ``lib/atc``.  You can do this manually if you prefer; follow the
       instructions in ``lib/atc/README``.  You can also do it in one
       step from the ``lammps/src`` dir, using a command like these,
-      which simply invoke the ``lib/atc/Install.py`` script with the
+      which simply invokes the ``lib/atc/Install.py`` script with the
       specified args:
 
       .. code-block:: bash
@@ -1181,7 +1232,7 @@ AWPMD package
       ``lib/awpmd``.  You can do this manually if you prefer; follow the
       instructions in ``lib/awpmd/README``.  You can also do it in one
       step from the ``lammps/src`` dir, using a command like these,
-      which simply invoke the ``lib/awpmd/Install.py`` script with the
+      which simply invokes the ``lib/awpmd/Install.py`` script with the
       specified args:
 
       .. code-block:: bash
@@ -1244,7 +1295,7 @@ be built for the most part with all major versions of the C++ language.
 
       In general, it is safer to use build setting consistent with the
       rest of LAMMPS.  This is best carried out from the LAMMPS src
-      directory using a command like these, which simply invoke the
+      directory using a command like these, which simply invokes the
       ``lib/colvars/Install.py`` script with the specified args:
 
       .. code-block:: bash
@@ -1285,20 +1336,30 @@ This package depends on the KSPACE package.
 
    .. tab:: CMake build
 
-      No additional settings are needed besides ``-D PKG_KSPACE=yes`` and ``-D
-      PKG_ELECTRODE=yes``.
+      No additional settings are needed besides ``-D PKG_KSPACE=yes`` and
+      ``-D PKG_ELECTRODE=yes``.
 
    .. tab:: Traditional make
 
-      The package is activated with ``make yes-KSPACE`` and ``make
-      yes-ELECTRODE``
+      Before building LAMMPS, you must configure the ELECTRODE support
+      libraries and settings in ``lib/electrode``.  You can do this
+      manually, if you prefer, or do it in one step from the
+      ``lammps/src`` dir, using a command like these, which simply
+      invokes the ``lib/electrode/Install.py`` script with the specified
+      args:
+
+      .. code-block:: bash
+
+         $ make lib-electrode                   # print help message
+         $ make lib-electrode args="-m serial"  # build with GNU g++ compiler and MPI STUBS (settings as with "make serial")
+         $ make lib-electrode args="-m mpi"     # build with default MPI compiler (settings as with "make mpi")
 
 
-      Note that the ``Makefile.lammps`` file has settings for the BLAS and
-      LAPACK linear algebra libraries.  As explained in ``lib/awpmd/README``
-      these can either exist on your system, or you can use the files provided
-      in ``lib/linalg``.  In the latter case you also need to build the library
-      in ``lib/linalg`` with a command like these:
+      Note that the ``Makefile.lammps`` file has settings for the BLAS
+      and LAPACK linear algebra libraries.  These can either exist on
+      your system, or you can use the files provided in ``lib/linalg``.
+      In the latter case you also need to build the library in
+      ``lib/linalg`` with a command like these:
 
       .. code-block:: bash
 
@@ -1307,6 +1368,9 @@ This package depends on the KSPACE package.
          $ make lib-linalg args="-m mpi"       # build with default MPI Fortran compiler (settings as with "make mpi")
          $ make lib-linalg args="-m gfortran"  # build with GNU Fortran compiler
 
+      The package itself is activated with ``make yes-KSPACE`` and
+      ``make yes-ELECTRODE``
+
 ----------
 
 .. _ml-pace:
@@ -1349,6 +1413,49 @@ at: `https://github.com/ICAMS/lammps-user-pace/ <https://github.com/ICAMS/lammps
 
 ----------
 
+.. _ml-pod:
+
+ML-POD package
+-----------------------------
+
+.. tabs::
+
+   .. tab:: CMake build
+
+      No additional settings are needed besides ``-D PKG_ML-POD=yes``.
+
+   .. tab:: Traditional make
+
+      Before building LAMMPS, you must configure the ML-POD support
+      settings in ``lib/mlpod``.  You can do this manually, if you
+      prefer, or do it in one step from the ``lammps/src`` dir, using a
+      command like the following, which simply invoke the
+      ``lib/mlpod/Install.py`` script with the specified args:
+
+      .. code-block:: bash
+
+         $ make lib-mlpod                   # print help message
+         $ make lib-mlpod args="-m serial"  # build with GNU g++ compiler and MPI STUBS (settings as with "make serial")
+         $ make lib-mlpod args="-m mpi"     # build with default MPI compiler (settings as with "make mpi")
+         $ make lib-mlpod args="-m mpi -e linalg"   # same as above but use the bundled linalg lib
+
+      Note that the ``Makefile.lammps`` file has settings to use the BLAS
+      and LAPACK linear algebra libraries.  These can either exist on
+      your system, or you can use the files provided in ``lib/linalg``.
+      In the latter case you also need to build the library in
+      ``lib/linalg`` with a command like these:
+
+      .. code-block:: bash
+
+         $ make lib-linalg                     # print help message
+         $ make lib-linalg args="-m serial"    # build with GNU Fortran compiler (settings as with "make serial")
+         $ make lib-linalg args="-m mpi"       # build with default MPI Fortran compiler (settings as with "make mpi")
+         $ make lib-linalg args="-m gfortran"  # build with GNU Fortran compiler
+
+      The package itself is activated with ``make yes-ML-POD``.
+
+----------
+
 .. _plumed:
 
 PLUMED package
@@ -1506,7 +1613,7 @@ the HDF5 library.
       ``lib/h5md``.  You can do this manually if you prefer; follow the
       instructions in ``lib/h5md/README``.  You can also do it in one
       step from the ``lammps/src`` dir, using a command like these,
-      which simply invoke the ``lib/h5md/Install.py`` script with the
+      which simply invokes the ``lib/h5md/Install.py`` script with the
       specified args:
 
       .. code-block:: bash
@@ -1562,7 +1669,7 @@ details please see ``lib/hdnnp/README`` and the `n2p2 build documentation
       You can download and build the *n2p2* library manually if you prefer;
       follow the instructions in ``lib/hdnnp/README``\ . You can also do it in
       one step from the ``lammps/src`` dir, using a command like these, which
-      simply invoke the ``lib/hdnnp/Install.py`` script with the specified args:
+      simply invokes the ``lib/hdnnp/Install.py`` script with the specified args:
 
       .. code-block:: bash
 
@@ -1699,7 +1806,7 @@ they will be downloaded the first time this package is installed.
       Before building LAMMPS, you must build the *mesont* library in
       ``lib/mesont``\ .  You can also do it in one step from the
       ``lammps/src`` dir, using a command like these, which simply
-      invoke the ``lib/mesont/Install.py`` script with the specified
+      invokes the ``lib/mesont/Install.py`` script with the specified
       args:
 
       .. code-block:: bash
@@ -1868,7 +1975,7 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to
       ``lib/qmmm``.  You can do this manually if you prefer; follow the
       first two steps explained in ``lib/qmmm/README``.  You can also do
       it in one step from the ``lammps/src`` dir, using a command like
-      these, which simply invoke the ``lib/qmmm/Install.py`` script with
+      these, which simply invokes the ``lib/qmmm/Install.py`` script with
       the specified args:
 
       .. code-block:: bash
@@ -1913,14 +2020,25 @@ within CMake will download the non-commercial use version.
 
       .. code-block:: bash
 
-         -D DOWNLOAD_QUIP=value   # download OpenKIM API v2 for build, value = no (default) or yes
-         -D QUIP_LIBRARY=path     # path to libquip.a (only needed if a custom location)
+         -D DOWNLOAD_QUIP=value       # download QUIP library for build, value = no (default) or yes
+         -D QUIP_LIBRARY=path         # path to libquip.a (only needed if a custom location)
+         -D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
+                                      #   value = no (default) or yes
 
-      CMake will try to download and build the QUIP library from GitHub, if it is not
-      found on the local machine. This requires to have git installed. It will use the same compilers
-      and flags as used for compiling LAMMPS.  Currently this is only supported for the GNU and the
-      Intel compilers. Set the ``QUIP_LIBRARY`` variable if you want to use a previously compiled
-      and installed QUIP library and CMake cannot find it.
+      CMake will try to download and build the QUIP library from GitHub,
+      if it is not found on the local machine. This requires to have git
+      installed. It will use the same compilers and flags as used for
+      compiling LAMMPS.  Currently this is only supported for the GNU
+      and the Intel compilers. Set the ``QUIP_LIBRARY`` variable if you
+      want to use a previously compiled and installed QUIP library and
+      CMake cannot find it.
+
+      The QUIP library requires LAPACK (and BLAS) and CMake can identify
+      their locations and pass that info to the QUIP build script. But
+      on some systems this triggers a (current) limitation of CMake and
+      the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
+      those cases to use the bundled linear algebra library and work around
+      the limitation.
 
    .. tab:: Traditional make
 
@@ -1965,7 +2083,7 @@ To build with this package, you must download and build the
       You can download and build the ScaFaCoS library manually if you
       prefer; follow the instructions in ``lib/scafacos/README``.  You
       can also do it in one step from the ``lammps/src`` dir, using a
-      command like these, which simply invoke the
+      command like these, which simply invokes the
       ``lib/scafacos/Install.py`` script with the specified args:
 
       .. code-block:: bash
@@ -2009,7 +2127,7 @@ Eigen3 is a template library, so you do not need to build it.
       You can download the Eigen3 library manually if you prefer; follow
       the instructions in ``lib/smd/README``.  You can also do it in one
       step from the ``lammps/src`` dir, using a command like these,
-      which simply invoke the ``lib/smd/Install.py`` script with the
+      which simply invokes the ``lib/smd/Install.py`` script with the
       specified args:
 
       .. code-block:: bash

doc/src/Build_manual.rst

@@ -48,18 +48,15 @@ Build using GNU make
 
 The LAMMPS manual is written in `reStructuredText <rst_>`_ format which
 can be translated to different output format using the `Sphinx
-<sphinx_>`_ document generator tool.  It also incorporates programmer
-documentation extracted from the LAMMPS C++ sources through the `Doxygen
-<https://doxygen.nl>`_ program.  Currently the translation to HTML, PDF
-(via LaTeX), ePUB (for many e-book readers) and MOBI (for Amazon Kindle
-readers) are supported.  For that to work a Python 3 interpreter, 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``.
-
-.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
-.. _sphinx: https://www.sphinx-doc.org
+<https://sphinx-doc.org>`_ document generator tool.  It also
+incorporates programmer documentation extracted from the LAMMPS C++
+sources through the `Doxygen <https://doxygen.nl>`_ program.  Currently
+the translation to HTML, PDF (via LaTeX), ePUB (for many e-book readers)
+and MOBI (for Amazon Kindle readers) are supported.  For that to work a
+Python 3 interpreter, 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``.
 
 For the documentation build a python virtual environment is set up in
 the folder ``doc/docenv`` and various python packages are installed into
@@ -179,7 +176,7 @@ math expressions transparently into embedded images.
 For converting the generated ePUB file to a MOBI format file (for e-book
 readers, like Kindle, that cannot read ePUB), you also need to have the
 ``ebook-convert`` tool from the "calibre" software
-installed. `http://calibre-ebook.com/ <http://calibre-ebook.com/>`_
+installed. `https://calibre-ebook.com/ <https://calibre-ebook.com/>`_
 Typing ``make mobi`` will first create the ePUB file and then convert
 it.  On the Kindle readers in particular, you also have support for PDF
 files, so you could download and view the PDF version as an alternative.
@@ -219,9 +216,20 @@ be multiple tests run automatically:
 - A test that only standard, printable ASCII text characters are used.
   This runs the command ``env LC_ALL=C grep -n '[^ -~]' src/*.rst`` and
   thus prints all offending lines with filename and line number
-  prepended to the screen.  Special characters like the Angstrom
-  :math:`\mathrm{\mathring{A}}` should be typeset with embedded math
-  (like this ``:math:`\mathrm{\mathring{A}}```\ ).
+  prepended to the screen.  Special characters like Greek letters
+  (:math:`\alpha~~\sigma~~\epsilon`), super- or subscripts
+  (:math:`x^2~~\mathrm{U}_{LJ}`), mathematical expressions
+  (:math:`\frac{1}{2}\mathrm{N}~~x\to\infty`), or the Angstrom symbol
+  (:math:`\AA`) should be typeset with embedded LaTeX (like this
+  ``:math:`\alpha \sigma \epsilon```, ``:math:`x^2 \mathrm{E}_{LJ}```,
+  ``:math:`\frac{1}{2}\mathrm{N} x\to\infty```, or ``:math:`\AA```\ ).
+
+- Embedded LaTeX is rendered in HTML output with `MathJax
+  <https://www.mathjax.org/>`_ and in PDF output by passing the embedded
+  text to LaTeX.  Some care has to be taken, though, since there are
+  limitations which macros and features can be used in either mode, so
+  it is recommended to always check whether any new or changed
+  documentation does translate and render correctly with either output.
 
 - A test whether all styles are documented and listed in their
   respective overview pages.  A typical output with warnings looks like this:
@@ -252,6 +260,5 @@ manual with ``make spelling``.  This requires `a library called enchant
 positives* (e.g. keywords, names, abbreviations) those can be added to
 the file ``lammps/doc/utils/sphinx-config/false_positives.txt``.
 
-.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
-
 .. _lws: https://www.lammps.org
+.. _rst: https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html

doc/src/Build_settings.rst

@@ -111,26 +111,25 @@ LAMMPS can use them if they are available on your system.
       files in its default search path.  You must specify ``FFT_LIB``
       with the appropriate FFT libraries to include in the link.
 
-The `KISS FFT library <http://kissfft.sf.net>`_ is included in the LAMMPS
-distribution.  It is portable across all platforms.  Depending on the size
-of the FFTs and the number of processors used, the other libraries listed
-here can be faster.
+The `KISS FFT library <https://github.com/mborgerding/kissfft>`_ is
+included in the LAMMPS distribution.  It is portable across all
+platforms.  Depending on the size of the FFTs and the number of
+processors used, the other libraries listed here can be faster.
 
 However, note that long-range Coulombics are only a portion of the
-per-timestep CPU cost, FFTs are only a portion of long-range
-Coulombics, and 1d FFTs are only a portion of the FFT cost (parallel
-communication can be costly).  A breakdown of these timings is printed
-to the screen at the end of a run when using the
-:doc:`kspace_style pppm <kspace_style>` command. The
-:doc:`Screen and logfile output <Run_output>`
-page gives more details.  A more detailed (and time consuming)
-report of the FFT performance is generated with the
+per-timestep CPU cost, FFTs are only a portion of long-range Coulombics,
+and 1d FFTs are only a portion of the FFT cost (parallel communication
+can be costly).  A breakdown of these timings is printed to the screen
+at the end of a run when using the :doc:`kspace_style pppm
+<kspace_style>` command. The :doc:`Screen and logfile output
+<Run_output>` page gives more details.  A more detailed (and time
+consuming) report of the FFT performance is generated with the
 :doc:`kspace_modify fftbench yes <kspace_modify>` command.
 
 FFTW is a fast, portable FFT library that should also work on any
-platform and can be faster than the KISS FFT library.  You can
-download it from `www.fftw.org <http://www.fftw.org>`_.  LAMMPS requires
-version 3.X; the legacy version 2.1.X is no longer supported.
+platform and can be faster than the KISS FFT library.  You can download
+it from `www.fftw.org <https://www.fftw.org>`_.  LAMMPS requires version
+3.X; the legacy version 2.1.X is no longer supported.
 
 Building FFTW for your box should be as simple as ``./configure; make;
 make install``.  The install command typically requires root privileges

doc/src/Commands.rst

@@ -21,6 +21,7 @@ commands in it are used to define a LAMMPS simulation.
    Commands_pair
    Commands_bond
    Commands_kspace
+   Commands_dump
 
 .. toctree::
    :maxdepth: 1

doc/src/Commands_all.rst

@@ -10,11 +10,14 @@
    * :ref:`Dihedral styles <dihedral>`
    * :ref:`Improper styles <improper>`
    * :doc:`KSpace styles <Commands_kspace>`
+   * :doc:`Dump styles <Commands_dump>`
 
 General commands
 ================
 
-An alphabetic list of general LAMMPS commands.
+An alphabetic list of general LAMMPS commands.  Note that style
+commands with many variants, can be more easily accessed via the small
+table above.
 
 .. table_from_list::
    :columns: 5
@@ -28,7 +31,6 @@ An alphabetic list of general LAMMPS commands.
    * :doc:`bond_style <bond_style>`
    * :doc:`bond_write <bond_write>`
    * :doc:`boundary <boundary>`
-   * :doc:`box <box>`
    * :doc:`change_box <change_box>`
    * :doc:`clear <clear>`
    * :doc:`comm_modify <comm_modify>`
@@ -60,6 +62,7 @@ An alphabetic list of general LAMMPS commands.
    * :doc:`kspace_modify <kspace_modify>`
    * :doc:`kspace_style <kspace_style>`
    * :doc:`label <label>`
+   * :doc:`labelmap <labelmap>`
    * :doc:`lattice <lattice>`
    * :doc:`log <log>`
    * :doc:`mass <mass>`
@@ -86,8 +89,7 @@ An alphabetic list of general LAMMPS commands.
    * :doc:`region <region>`
    * :doc:`replicate <replicate>`
    * :doc:`rerun <rerun>`
-   * :doc:`reset_atom_ids <reset_atom_ids>`
-   * :doc:`reset_mol_ids <reset_mol_ids>`
+   * :doc:`reset_atoms <reset_atoms>`
    * :doc:`reset_timestep <reset_timestep>`
    * :doc:`restart <restart>`
    * :doc:`run <run>`
@@ -123,6 +125,7 @@ additional letter in parenthesis: k = KOKKOS.
    * :doc:`group2ndx <group2ndx>`
    * :doc:`hyper <hyper>`
    * :doc:`kim <kim_commands>`
+   * :doc:`fitpod <fitpod_command>`
    * :doc:`mdi <mdi>`
    * :doc:`ndx2group <group2ndx>`
    * :doc:`neb <neb>`

doc/src/Commands_bond.rst

@@ -10,6 +10,7 @@
    * :ref:`Dihedral styles <dihedral>`
    * :ref:`Improper styles <improper>`
    * :doc:`KSpace styles <Commands_kspace>`
+   * :doc:`Dump styles <Commands_dump>`
 
 .. _bond:
 
@@ -43,6 +44,7 @@ OPT.
    * :doc:`harmonic (iko) <bond_harmonic>`
    * :doc:`harmonic/shift (o) <bond_harmonic_shift>`
    * :doc:`harmonic/shift/cut (o) <bond_harmonic_shift_cut>`
+   * :doc:`mesocnt <bond_mesocnt>`
    * :doc:`mm3 <bond_mm3>`
    * :doc:`morse (o) <bond_morse>`
    * :doc:`nonlinear (o) <bond_nonlinear>`
@@ -74,6 +76,7 @@ OPT.
    *
    *
    *
+   * :doc:`amoeba <angle_amoeba>`
    * :doc:`charmm (iko) <angle_charmm>`
    * :doc:`class2 (ko) <angle_class2>`
    * :doc:`class2/p6 <angle_class2>`
@@ -90,9 +93,10 @@ OPT.
    * :doc:`fourier/simple (o) <angle_fourier_simple>`
    * :doc:`gaussian <angle_gaussian>`
    * :doc:`harmonic (iko) <angle_harmonic>`
+   * :doc:`mesocnt <angle_mesocnt>`
    * :doc:`mm3 <angle_mm3>`
    * :doc:`quartic (o) <angle_quartic>`
-   * :doc:`sdk (o) <angle_sdk>`
+   * :doc:`spica (o) <angle_spica>`
    * :doc:`table (o) <angle_table>`
 
 .. _dihedral:
@@ -152,6 +156,7 @@ OPT.
    *
    *
    *
+   * :doc:`amoeba <improper_amoeba>`
    * :doc:`class2 (ko) <improper_class2>`
    * :doc:`cossq (o) <improper_cossq>`
    * :doc:`cvff (io) <improper_cvff>`

doc/src/Commands_category.rst

@@ -25,7 +25,6 @@ Setup simulation box:
    :columns: 4
 
    * :doc:`boundary <boundary>`
-   * :doc:`box <box>`
    * :doc:`change_box <change_box>`
    * :doc:`create_box <create_box>`
    * :doc:`dimension <dimension>`

doc/src/Commands_compute.rst

@@ -10,6 +10,7 @@
    * :ref:`Dihedral styles <dihedral>`
    * :ref:`Improper styles <improper>`
    * :doc:`KSpace styles <Commands_kspace>`
+   * :doc:`Dump styles <Commands_dump>`
 
 Compute commands
 ================
@@ -106,6 +107,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`pressure/uef <compute_pressure_uef>`
    * :doc:`property/atom <compute_property_atom>`
    * :doc:`property/chunk <compute_property_chunk>`
+   * :doc:`property/grid <compute_property_grid>`
    * :doc:`property/local <compute_property_local>`
    * :doc:`ptm/atom <compute_ptm_atom>`
    * :doc:`rdf <compute_rdf>`
@@ -138,6 +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 <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>`

doc/src/Commands_dump.rst

@@ -0,0 +1,57 @@
+.. table_from_list::
+   :columns: 3
+
+   * :doc:`General commands <Commands_all>`
+   * :doc:`Fix styles <Commands_fix>`
+   * :doc:`Compute styles <Commands_compute>`
+   * :doc:`Pair styles <Commands_pair>`
+   * :ref:`Bond styles <bond>`
+   * :ref:`Angle styles <angle>`
+   * :ref:`Dihedral styles <dihedral>`
+   * :ref:`Improper styles <improper>`
+   * :doc:`KSpace styles <Commands_kspace>`
+   * :doc:`Dump styles <Commands_dump>`
+
+Dump commands
+=============
+
+An alphabetic list of all LAMMPS :doc:`dump <dump>` commands.
+
+.. table_from_list::
+   :columns: 5
+
+   * :doc:`atom <dump>`
+   * :doc:`atom/adios <dump_adios>`
+   * :doc:`atom/gz <dump>`
+   * :doc:`atom/mpiio <dump>`
+   * :doc:`atom/zstd <dump>`
+   * :doc:`cfg <dump>`
+   * :doc:`cfg/gz <dump>`
+   * :doc:`cfg/mpiio <dump>`
+   * :doc:`cfg/uef <dump_cfg_uef>`
+   * :doc:`cfg/zstd <dump>`
+   * :doc:`custom <dump>`
+   * :doc:`custom/adios <dump_adios>`
+   * :doc:`custom/gz <dump>`
+   * :doc:`custom/mpiio <dump>`
+   * :doc:`custom/zstd <dump>`
+   * :doc:`dcd <dump>`
+   * :doc:`grid <dump>`
+   * :doc:`grid/vtk <dump>`
+   * :doc:`h5md <dump_h5md>`
+   * :doc:`image <dump_image>`
+   * :doc:`local <dump>`
+   * :doc:`local/gz <dump>`
+   * :doc:`local/zstd <dump>`
+   * :doc:`molfile <dump_molfile>`
+   * :doc:`movie <dump_image>`
+   * :doc:`netcdf <dump_netcdf>`
+   * :doc:`netcdf/mpiio <dump>`
+   * :doc:`vtk <dump_vtk>`
+   * :doc:`xtc <dump>`
+   * :doc:`xyz <dump>`
+   * :doc:`xyz/gz <dump>`
+   * :doc:`xyz/mpiio <dump>`
+   * :doc:`xyz/zstd <dump>`
+   * :doc:`yaml <dump>`
+

doc/src/Commands_fix.rst

@@ -10,6 +10,7 @@
    * :ref:`Dihedral styles <dihedral>`
    * :ref:`Improper styles <improper>`
    * :doc:`KSpace styles <Commands_kspace>`
+   * :doc:`Dump styles <Commands_dump>`
 
 Fix commands
 ============
@@ -28,6 +29,8 @@ OPT.
    * :doc:`adapt/fep <fix_adapt_fep>`
    * :doc:`addforce <fix_addforce>`
    * :doc:`addtorque <fix_addtorque>`
+   * :doc:`amoeba/bitorsion <fix_amoeba_bitorsion>`
+   * :doc:`amoeba/pitorsion <fix_amoeba_pitorsion>`
    * :doc:`append/atoms <fix_append_atoms>`
    * :doc:`atc <fix_atc>`
    * :doc:`atom/swap <fix_atom_swap>`
@@ -35,6 +38,7 @@ OPT.
    * :doc:`ave/chunk <fix_ave_chunk>`
    * :doc:`ave/correlate <fix_ave_correlate>`
    * :doc:`ave/correlate/long <fix_ave_correlate_long>`
+   * :doc:`ave/grid <fix_ave_grid>`
    * :doc:`ave/histo <fix_ave_histo>`
    * :doc:`ave/histo/weight <fix_ave_histo>`
    * :doc:`ave/time <fix_ave_time>`
@@ -62,13 +66,13 @@ OPT.
    * :doc:`drude <fix_drude>`
    * :doc:`drude/transform/direct <fix_drude_transform>`
    * :doc:`drude/transform/inverse <fix_drude_transform>`
-   * :doc:`dt/reset <fix_dt_reset>`
+   * :doc:`dt/reset (k) <fix_dt_reset>`
    * :doc:`edpd/source <fix_dpd_source>`
    * :doc:`efield <fix_efield>`
    * :doc:`ehex <fix_ehex>`
-   * :doc:`electrode/conp (i) <fix_electrode_conp>`
-   * :doc:`electrode/conq (i) <fix_electrode_conp>`
-   * :doc:`electrode/thermo (i) <fix_electrode_conp>`
+   * :doc:`electrode/conp (i) <fix_electrode>`
+   * :doc:`electrode/conq (i) <fix_electrode>`
+   * :doc:`electrode/thermo (i) <fix_electrode>`
    * :doc:`electron/stopping <fix_electron_stopping>`
    * :doc:`electron/stopping/fit <fix_electron_stopping>`
    * :doc:`enforce2d (k) <fix_enforce2d>`
@@ -103,7 +107,7 @@ OPT.
    * :doc:`lb/viscous <fix_lb_viscous>`
    * :doc:`lineforce <fix_lineforce>`
    * :doc:`manifoldforce <fix_manifoldforce>`
-   * :doc:`mdi/aimd <fix_mdi_aimd>`
+   * :doc:`mdi/qm <fix_mdi_qm>`
    * :doc:`meso/move <fix_meso_move>`
    * :doc:`mol/swap <fix_mol_swap>`
    * :doc:`momentum (k) <fix_momentum>`
@@ -162,6 +166,7 @@ OPT.
    * :doc:`orient/fcc <fix_orient>`
    * :doc:`orient/eco <fix_orient_eco>`
    * :doc:`pafi <fix_pafi>`
+   * :doc:`pair <fix_pair>`
    * :doc:`phonon <fix_phonon>`
    * :doc:`pimd <fix_pimd>`
    * :doc:`planeforce <fix_planeforce>`
@@ -209,6 +214,7 @@ OPT.
    * :doc:`saed/vtk <fix_saed_vtk>`
    * :doc:`setforce (k) <fix_setforce>`
    * :doc:`setforce/spin <fix_setforce>`
+   * :doc:`sgcmc <fix_sgcmc>`
    * :doc:`shake (k) <fix_shake>`
    * :doc:`shardlow (k) <fix_shardlow>`
    * :doc:`smd <fix_smd>`
@@ -245,7 +251,7 @@ OPT.
    * :doc:`tune/kspace <fix_tune_kspace>`
    * :doc:`vector <fix_vector>`
    * :doc:`viscosity <fix_viscosity>`
-   * :doc:`viscous <fix_viscous>`
+   * :doc:`viscous (k) <fix_viscous>`
    * :doc:`viscous/sphere <fix_viscous_sphere>`
    * :doc:`wall/body/polygon <fix_wall_body_polygon>`
    * :doc:`wall/body/polyhedron <fix_wall_body_polyhedron>`

doc/src/Commands_kspace.rst

@@ -10,6 +10,7 @@
    * :ref:`Dihedral styles <dihedral>`
    * :ref:`Improper styles <improper>`
    * :doc:`KSpace styles <Commands_kspace>`
+   * :doc:`Dump styles <Commands_dump>`
 
 KSpace solvers
 ==============

doc/src/Commands_pair.rst

@@ -10,6 +10,7 @@
    * :ref:`Dihedral styles <dihedral>`
    * :ref:`Improper styles <improper>`
    * :doc:`KSpace styles <Commands_kspace>`
+   * :doc:`Dump styles <Commands_dump>`
 
 Pair_style potentials
 ======================
@@ -38,6 +39,7 @@ OPT.
    * :doc:`agni (o) <pair_agni>`
    * :doc:`airebo (io) <pair_airebo>`
    * :doc:`airebo/morse (io) <pair_airebo>`
+   * :doc:`amoeba <pair_amoeba>`
    * :doc:`atm <pair_atm>`
    * :doc:`awpmd/cut <pair_awpmd>`
    * :doc:`beck (go) <pair_beck>`
@@ -91,8 +93,8 @@ OPT.
    * :doc:`coul/wolf/cs <pair_cs>`
    * :doc:`dpd (giko) <pair_dpd>`
    * :doc:`dpd/fdt <pair_dpd_fdt>`
-   * :doc:`dpd/ext (k) <pair_dpd_ext>`
-   * :doc:`dpd/ext/tstat (k) <pair_dpd_ext>`
+   * :doc:`dpd/ext (ko) <pair_dpd_ext>`
+   * :doc:`dpd/ext/tstat (ko) <pair_dpd_ext>`
    * :doc:`dpd/fdt/energy (k) <pair_dpd_fdt>`
    * :doc:`dpd/tstat (gko) <pair_dpd>`
    * :doc:`dsmc <pair_dsmc>`
@@ -124,6 +126,7 @@ OPT.
    * :doc:`hbond/dreiding/lj (o) <pair_hbond_dreiding>`
    * :doc:`hbond/dreiding/morse (o) <pair_hbond_dreiding>`
    * :doc:`hdnnp <pair_hdnnp>`
+   * :doc:`hippo <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>`
@@ -179,9 +182,9 @@ OPT.
    * :doc:`lj/long/tip4p/long (o) <pair_lj_long>`
    * :doc:`lj/mdf <pair_mdf>`
    * :doc:`lj/relres (o) <pair_lj_relres>`
-   * :doc:`lj/sdk (gko) <pair_sdk>`
-   * :doc:`lj/sdk/coul/long (go) <pair_sdk>`
-   * :doc:`lj/sdk/coul/msm (o) <pair_sdk>`
+   * :doc:`lj/spica (gko) <pair_spica>`
+   * :doc:`lj/spica/coul/long (go) <pair_spica>`
+   * :doc:`lj/spica/coul/msm (o) <pair_spica>`
    * :doc:`lj/sf/dipole/sf (go) <pair_dipole>`
    * :doc:`lj/smooth (go) <pair_lj_smooth>`
    * :doc:`lj/smooth/linear (o) <pair_lj_smooth_linear>`
@@ -194,14 +197,15 @@ OPT.
    * :doc:`lubricateU/poly <pair_lubricateU>`
    * :doc:`mdpd <pair_mesodpd>`
    * :doc:`mdpd/rhosum <pair_mesodpd>`
-   * :doc:`meam <pair_meam>`
+   * :doc:`meam (k) <pair_meam>`
    * :doc:`meam/spline (o) <pair_meam_spline>`
    * :doc:`meam/sw/spline <pair_meam_sw_spline>`
    * :doc:`mesocnt <pair_mesocnt>`
+   * :doc:`mesocnt/viscous <pair_mesocnt>`
    * :doc:`mesont/tpm <pair_mesont_tpm>`
    * :doc:`mgpt <pair_mgpt>`
    * :doc:`mie/cut (g) <pair_mie>`
-   * :doc:`mliap <pair_mliap>`
+   * :doc:`mliap (k) <pair_mliap>`
    * :doc:`mm3/switch3/coulgauss/long <pair_lj_switch3_coulgauss_long>`
    * :doc:`momb <pair_momb>`
    * :doc:`morse (gkot) <pair_morse>`
@@ -232,6 +236,8 @@ OPT.
    * :doc:`oxrna2/xstk <pair_oxrna2>`
    * :doc:`oxrna2/coaxstk <pair_oxrna2>`
    * :doc:`pace (k) <pair_pace>`
+   * :doc:`pace/extrapolation <pair_pace>`
+   * :doc:`pod <pair_pod>`
    * :doc:`peri/eps <pair_peri>`
    * :doc:`peri/lps (o) <pair_peri>`
    * :doc:`peri/pmb (o) <pair_peri>`
@@ -268,6 +274,7 @@ OPT.
    * :doc:`spin/magelec <pair_spin_magelec>`
    * :doc:`spin/neel <pair_spin_neel>`
    * :doc:`srp <pair_srp>`
+   * :doc:`srp/react <pair_srp>`
    * :doc:`sw (giko) <pair_sw>`
    * :doc:`sw/angle/table <pair_sw_angle_table>`
    * :doc:`sw/mod (o) <pair_sw>`
@@ -289,6 +296,7 @@ OPT.
    * :doc:`vashishta (gko) <pair_vashishta>`
    * :doc:`vashishta/table (o) <pair_vashishta>`
    * :doc:`wf/cut <pair_wf_cut>`
+   * :doc:`ylz <pair_ylz>`
    * :doc:`yukawa (gko) <pair_yukawa>`
    * :doc:`yukawa/colloid (go) <pair_yukawa_colloid>`
    * :doc:`zbl (gko) <pair_zbl>`

doc/src/Commands_parse.rst

@@ -123,14 +123,15 @@ LAMMPS:
 .. _six:
 
 6. If you want text with spaces to be treated as a single argument, it
-   can be enclosed in either single or double or triple quotes.  A long
-   single argument enclosed in single or double quotes can span multiple
-   lines if the "&" character is used, as described above.  When the
-   lines are concatenated together (and the "&" characters and line
-   breaks removed), the text will become a single line.  If you want
-   multiple lines of an argument to retain their line breaks, the text
-   can be enclosed in triple quotes, in which case "&" characters are
-   not needed.  For example:
+   can be enclosed in either single (') or double (") or triple (""")
+   quotes.  A long single argument enclosed in single or double quotes
+   can span multiple lines if the "&" character is used, as described
+   in :ref:`1 <one>` above.  When the lines are concatenated together
+   by LAMMPS (and the "&" characters and line breaks removed), the
+   combined text will become a single line.  If you want multiple lines
+   of an argument to retain their line breaks, the text can be enclosed
+   in triple quotes, in which case "&" characters are not needed and do
+   not function as line continuation character.  For example:
 
    .. code-block:: LAMMPS
 
@@ -144,8 +145,9 @@ LAMMPS:
       System temperature = $t
       """
 
-   In each case, the single, double, or triple quotes are removed when
-   the single argument they enclose is stored internally.
+   In each of these cases, the single, double, or triple quotes are
+   removed and the enclosed text stored internally as a single
+   argument.
 
    See the :doc:`dump modify format <dump_modify>`, :doc:`print
    <print>`, :doc:`if <if>`, and :doc:`python <python>` commands for

doc/src/Commands_removed.rst

@@ -2,14 +2,17 @@ Removed commands and packages
 =============================
 
 This page lists LAMMPS commands and packages that have been removed from
-the distribution and provides suggestions for alternatives or replacements.
-LAMMPS has special dummy styles implemented, that will stop LAMMPS and
-print a suitable error message in most cases, when a style/command is used
-that has been removed.
+the distribution and provides suggestions for alternatives or
+replacements.  LAMMPS has special dummy styles implemented, that will
+stop LAMMPS and print a suitable error message in most cases, when a
+style/command is used that has been removed or will replace the command
+with the direct alternative (if available) and print a warning.
 
 Fix ave/spatial and fix ave/spatial/sphere
 ------------------------------------------
 
+.. deprecated:: 11Dec2015
+
 The fixes ave/spatial and ave/spatial/sphere have been removed from LAMMPS
 since they were superseded by the more general and extensible "chunk
 infrastructure".  Here the system is partitioned in one of many possible
@@ -17,10 +20,23 @@ ways through the :doc:`compute chunk/atom <compute_chunk_atom>` command
 and then averaging is done using :doc:`fix ave/chunk <fix_ave_chunk>`.
 Please refer to the :doc:`chunk HOWTO <Howto_chunk>` section for an overview.
 
-Reset_ids command
------------------
+Box command
+-----------
 
-The reset_ids command has been renamed to :doc:`reset_atom_ids <reset_atom_ids>`.
+.. deprecated:: 22Dec2022
+
+The *box* command has been removed and the LAMMPS code changed so it won't
+be needed.  If present, LAMMPS will ignore the command and print a warning.
+
+Reset_ids, reset_atom_ids, reset_mol_ids commands
+-------------------------------------------------
+
+.. deprecated:: 22Dec2022
+
+The *reset_ids*, *reset_atom_ids*, and *reset_mol_ids* commands have
+been folded into the :doc:`reset_atoms <reset_atoms>` command.  If
+present, LAMMPS will replace the commands accordingly and print a
+warning.
 
 MEAM package
 ------------
@@ -30,18 +46,21 @@ The code in the :ref:`MEAM package <PKG-MEAM>` is a translation of the
 Fortran code of MEAM into C++, which removes several restrictions
 (e.g. there can be multiple instances in hybrid pair styles) and allows
 for some optimizations leading to better performance.  The pair style
-:doc:`meam <pair_meam>` has the exact same syntax.
+:doc:`meam <pair_meam>` has the exact same syntax.  For a transition
+period the C++ version of MEAM was called USER-MEAMC so it could
+coexist with the Fortran version.
 
 REAX package
 ------------
 
 The REAX package has been removed since it was superseded by the
-:ref:`REAXFF package <PKG-REAXFF>`.  The REAXFF
-package has been tested to yield equivalent results to the REAX package,
-offers better performance, supports OpenMP multi-threading via OPENMP,
-and GPU and threading parallelization through KOKKOS.  The new pair styles
-are not syntax compatible with the removed reax pair style, so input
-files will have to be adapted.
+:ref:`REAXFF package <PKG-REAXFF>`.  The REAXFF package has been tested
+to yield equivalent results to the REAX package, offers better
+performance, supports OpenMP multi-threading via OPENMP, and GPU and
+threading parallelization through KOKKOS.  The new pair styles are not
+syntax compatible with the removed reax pair style, so input files will
+have to be adapted.  The REAXFF package was originally called
+USER-REAXC.
 
 USER-CUDA package
 -----------------
@@ -60,5 +79,6 @@ restart2data tool
 The functionality of the restart2data tool has been folded into the
 LAMMPS executable directly instead of having a separate tool.  A
 combination of the commands :doc:`read_restart <read_restart>` and
-:doc:`write_data <write_data>` can be used to the same effect.  For added
-convenience this conversion can also be triggered by :doc:`command line flags <Run_options>`
+:doc:`write_data <write_data>` can be used to the same effect.  For
+added convenience this conversion can also be triggered by
+:doc:`command line flags <Run_options>`

doc/src/Developer.rst

@@ -17,8 +17,10 @@ of time and requests from the LAMMPS user community.
    Developer_flow
    Developer_write
    Developer_notes
+   Developer_updating
    Developer_plugins
    Developer_unittest
    Classes
    Developer_platform
    Developer_utils
+   Developer_grid

doc/src/Developer_code_design.rst

@@ -50,7 +50,7 @@ parallel each MPI process creates such an instance.  This can be seen
 in the ``main.cpp`` file where the core steps of running a LAMMPS
 simulation are the following 3 lines of code:
 
-.. code-block:: C++
+.. code-block:: c++
 
     LAMMPS *lammps = new LAMMPS(argc, argv, lammps_comm);
     lammps->input->file();
@@ -78,7 +78,7 @@ LAMMPS makes extensive use of the object oriented programming (OOP)
 principles of *compositing* and *inheritance*. Classes like the
 ``LAMMPS`` class are a **composite** containing pointers to instances
 of other classes like ``Atom``, ``Comm``, ``Force``, ``Neighbor``,
-``Modify``, and so on.  Each of these classes implement certain
+``Modify``, and so on.  Each of these classes implements certain
 functionality by storing and manipulating data related to the
 simulation and providing member functions that trigger certain
 actions.  Some of those classes like ``Force`` are themselves
@@ -87,9 +87,9 @@ interactions.  Similarly the ``Modify`` class contains a list of
 ``Fix`` and ``Compute`` classes.  If the input commands that
 correspond to these classes include the word *style*, then LAMMPS
 stores only a single instance of that class.  E.g. *atom_style*,
-*comm_style*, *pair_style*, *bond_style*.  It the input command does
-not include the word *style*, there can be many instances of that
-class defined.  E.g. *region*, *fix*, *compute*, *dump*.
+*comm_style*, *pair_style*, *bond_style*.  If the input command does
+**not** include the word *style*, then there may be many instances of
+that class defined, for example *region*, *fix*, *compute*, *dump*.
 
 **Inheritance** enables creation of *derived* classes that can share
 common functionality in their base class while providing a consistent
@@ -232,7 +232,7 @@ macro ``PairStyle()`` will associate the style name "lj/cut"
 with a factory function creating an instance of the ``PairLJCut``
 class.
 
-.. code-block:: C++
+.. code-block:: c++
 
    // from force.h
    typedef Pair *(*PairCreator)(LAMMPS *);
@@ -360,7 +360,7 @@ characters; "{:<8}" would do this as left aligned, "{:^8}" as centered,
 argument type must be compatible or else the {fmt} formatting code will
 throw an exception. Some format string examples are given below:
 
-.. code-block:: C
+.. code-block:: c++
 
    auto mesg = fmt::format("  CPU time: {:4d}:{:02d}:{:02d}\n", cpuh, cpum, cpus);
    mesg = fmt::format("{:<8s}| {:<10.5g} | {:<10.5g} | {:<10.5g} |{:6.1f} |{:6.2f}\n",

doc/src/Developer_grid.rst

@@ -0,0 +1,846 @@
+Use of distributed grids within style classes
+---------------------------------------------
+
+.. versionadded:: 22Dec2022
+
+The LAMMPS source code includes two classes which facilitate the
+creation and use of distributed grids.  These are the Grid2d and
+Grid3d classes in the src/grid2d.cpp.h and src/grid3d.cpp.h files
+respectively.  As the names imply, they are used for 2d or 3d
+simulations, as defined by the :doc:`dimension <dimension>` command.
+
+The :doc:`Howto_grid <Howto_grid>` page gives an overview of how
+distributed grids are defined from a user perspective, lists LAMMPS
+commands which use them, and explains how grid cell data is referenced
+from an input script.  Please read that page first as it motivates the
+coding details discussed here.
+
+This doc page is for users who wish to write new styles (input script
+commands) which use distributed grids.  There are a variety of
+material models and analysis methods which use atoms (or
+coarse-grained particles) and grids in tandem.
+
+A *distributed* grid means each processor owns a subset of the grid
+cells.  In LAMMPS, the subset for each processor will be a sub-block
+of grid cells with low and high index bounds in each dimension of the
+grid.  The union of the sub-blocks across all processors is the global
+grid.
+
+More specifically, a grid point is defined for each cell (by default
+the center point), and a processor owns a grid cell if its point is
+within the processor's spatial sub-domain.  The union of processor
+sub-domains is the global simulation box.  If a grid point is on the
+boundary of two sub-domains, the lower processor owns the grid cell.  A
+processor may also store copies of ghost cells which surround its
+owned cells.
+
+----------
+
+Style commands
+^^^^^^^^^^^^^^
+
+Style commands which can define and use distributed grids include the
+:doc:`compute <compute>`, :doc:`fix <fix>`, :doc:`pair <pair_style>`,
+and :doc:`kspace <kspace_style>` styles.  If you wish grid cell data
+to persist across timesteps, then use a fix.  If you wish grid cell
+data to be accessible by other commands, then use a fix or compute.
+Currently in LAMMPS, the :doc:`pair_style amoeba <pair_amoeba>`,
+:doc:`kspace_style pppm <kspace_style>`, and :doc:`kspace_style msm
+<kspace_style>` commands use distributed grids but do not require
+either of these capabilities; they thus create and use distributed
+grids internally.  Note that a pair style which needs grid cell data
+to persist could be coded to work in tandem with a fix style which
+provides that capability.
+
+The *size* of a grid is specified by the number of grid cells in each
+dimension of the simulation domain.  In any dimension the size can be
+any value >= 1.  Thus a 10x10x1 grid for a 3d simulation is
+effectively a 2d grid, where each grid cell spans the entire
+z-dimension.  A 1x100x1 grid for a 3d simulation is effectively a 1d
+grid, where grid cells are a series of thin xz slabs in the
+y-dimension.  It is even possible to define a 1x1x1 3d grid, though it
+may be inefficient to use it in a computational sense.
+
+Note that the choice of grid size is independent of the number of
+processors or their layout in a grid of processor sub-domains which
+overlays the simulations domain.  Depending on the distributed grid
+size, a single processor may own many 1000s or no grid cells.
+
+A command can define multiple grids, each of a different size.  Each
+grid is an instantiation of the Grid2d or Grid3d class.
+
+The command also defines what data it will store for each grid it
+creates and it allocates the multi-dimensional array(s) needed to
+store the data.  No grid cell data is stored within the Grid2d or
+Grid3d classes.
+
+If a single value per grid cell is needed, the data array will have
+the same dimension as the grid, i.e. a 2d array for a 2d grid,
+likewise for 3d.  If multiple values per grid cell are needed, the
+data array will have one more dimension than the grid, i.e. a 3d array
+for a 2d grid, or 4d array for a 3d grid.  A command can choose to
+define multiple data arrays for each grid it defines.
+
+----------
+
+Grid data allocation and access
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The simplest way for a command to allocate and access grid cell data
+is to use the *create_offset()* methods provided by the Memory class.
+Arguments for these methods can be values returned by the
+*setup_grid()* method (described below), which define the extent of
+the grid cells (owned+ghost) the processor owns.  These 4 methods
+allocate memory for 2d (first two) and 3d (second two) grid data.  The
+two methods that end in "_one" allocate an array which stores a single
+value per grid cell.  The two that end in "_multi" allocate an array
+which stores *Nvalues* per grid cell.
+
+.. code-block:: c++
+
+   // single value per cell for a 2d grid = 2d array
+   memory->create2d_offset(data2d_one, nylo_out, nyhi_out,
+                           nxlo_out, nxhi_out, "data2d_one");
+
+   // nvalues per cell for a 2d grid = 3d array
+   memory->create3d_offset_last(data2d_multi, nylo_out, nyhi_out,
+                                nxlo_out, nxhi_out, nvalues, "data2d_multi");
+
+   // single value per cell for a 3d grid = 3d array
+   memory->create3d_offset(data3d_one, nzlo_out, nzhi_out, nylo_out,
+                           nyhi_out, nxlo_out, nxhi_out, "data3d_one");
+
+   // nvalues per cell for a 3d grid = 4d array
+   memory->create4d_offset_last(data3d_multi, nzlo_out, nzhi_out, nylo_out,
+                                nyhi_out, nxlo_out, nxhi_out, nvalues,
+                                "data3d_multi");
+
+Note that these multi-dimensional arrays are allocated as contiguous
+chunks of memory where the x-index of the grid varies fastest, then y,
+and the z-index slowest.  For multiple values per grid cell, the
+Nvalues are contiguous, so their index varies even faster than the
+x-index.
+
+The key point is that the "offset" methods create arrays which are
+indexed by the range of indices which are the bounds of the sub-block
+of the global grid owned by this processor.  This means loops like
+these can be written in the caller code to loop over owned grid cells,
+where the "i" loop bounds are the range of owned grid cells for the
+processor.  These are the bounds returned by the *setup_grid()*
+method:
+
+.. code-block:: c++
+
+    for (int iy = iylo; iy <= iyhi; iy++)
+      for (int ix = ixlo; ix <= ixhi; ix++)
+        data2d_one[iy][ix] = 0.0;
+
+    for (int iy = iylo; iy <= iyhi; iy++)
+      for (int ix = ixlo; ix <= ixhi; ix++)
+        for (int m = 0; m < nvalues; m++)
+          data2d_multi[iy][ix][m] = 0.0;
+
+    for (int iz = izlo; iz <= izhi; iz++)
+      for (int iy = iylo; iy <= iyhi; iy++)
+        for (int ix = ixlo; ix <= ixhi; ix++)
+          data3d_one[iz][iy][ix] = 0.0;
+
+    for (int iz = izlo; iz <= izhi; iz++)
+      for (int iy = iylo; iy <= iyhi; iy++)
+        for (int ix = ixlo; ix <= ixhi; ix++)
+           for (int m = 0; m < nvalues; m++)
+              data3d_multi[iz][iy][ix][m] = 0.0;
+
+Simply replacing the "i" bounds with "o" bounds, also returned by the
+*setup_grid()* method, would alter this code to loop over owned+ghost
+cells (the entire allocated grid).
+
+----------
+
+Grid class constructors
+^^^^^^^^^^^^^^^^^^^^^^^
+
+The following sub-sections describe the public methods of the Grid3d
+class which a style command can invoke.  The Grid2d methods are
+similar; simply remove arguments which refer to the z-dimension.
+
+There are 2 constructors which can be used.  They differ in the extra
+i/o xyz lo/hi arguments:
+
+.. code-block:: c++
+
+   Grid3d(class LAMMPS *lmp, MPI_Comm gcomm, int gnx, int gny, int gnz)
+   Grid3d(class LAMMPS *lmp, MPI_Comm gcomm, int gnx, int gny, int gnz,
+          int ixlo, int ixhi, int iylo, int iyhi, int izlo, int izhi,
+          int oxlo, int oxhi, int oylo, int oyhi, int ozlo, int ozhi)
+
+Both constructors take the LAMMPS instance pointer and a communicator
+over which the grid will be distributed.  Typically this is the
+*world* communicator the LAMMPS instance is using.  The
+:doc:`kspace_style msm <kspace_style>` command creates a series of
+grids, each of different size, which are partitioned across different
+sub-communicators of processors.  Both constructors are also passed
+the global grid size: *gnx* by *gny* by *gnz*.
+
+The first constructor is used when the caller wants the Grid class to
+partition the global grid across processors; the Grid class defines
+which grid cells each processor owns and also which it stores as ghost
+cells.  A subsequent call to *setup_grid()*, discussed below, returns
+this info to the caller.
+
+The second constructor allows the caller to define the extent of owned
+and ghost cells, and pass them to the Grid class.  The 6 arguments
+which start with "i" are the inclusive lower and upper index bounds of
+the owned (inner) grid cells this processor owns in each of the 3
+dimensions within the global grid.  Owned grid cells are indexed from
+0 to N-1 in each dimension.
+
+The 6 arguments which start with "o" are the inclusive bounds of the
+owned+ghost (outer) grid cells it stores.  If the ghost cells are on
+the other side of a periodic boundary, then these indices may be < 0
+or >= N in any dimension, so that oxlo <= ixlo and ixhi >= ixhi is
+always the case.
+
+For example, if Nx = 100, then a processor might pass ixlo=50,
+ixhi=60, oxlo=48, oxhi=62 to the Grid class.  Or ixlo=0, ixhi=10,
+oxlo=-2, oxhi=13.  If a processor owns no grid cells in a dimension,
+then the ihi value should be specified as one less than the ilo value.
+
+Note that the only reason to use the second constructor is if the
+logic for assigning ghost cells is too complex for the Grid class to
+compute, using the various set() methods described next.  Currently
+only the kspace_style pppm/electrode and kspace_style msm commands use
+the second constructor.
+
+----------
+
+Grid class set methods
+^^^^^^^^^^^^^^^^^^^^^^
+
+The following methods affect how the Grid class computes which owned
+and ghost cells are assigned to each processor.  *Set_shift_grid()* is
+the only method which influences owned cell assignment; all the rest
+influence ghost cell assignment.  These methods are only used with the
+first constructor; they are ignored if the second constructor is used.
+These methods must be called before the *setup_grid()* method is
+invoked, because they influence its operation.
+
+.. code-block:: c++
+
+   void set_shift_grid(double shift);
+   void set_distance(double distance);
+   void set_stencil_atom(int lo, int hi);
+   void set_shift_atom(double shift_lo, double shift_hi);
+   void set_stencil_grid(int lo, int hi);
+   void set_zfactor(double factor);
+
+Processors own a grid cell if a point within the grid cell is inside
+the processor's sub-domain.  By default this is the center point of the
+grid cell.  The *set_shift_grid()* method can change this.  The *shift*
+argument is a value from 0.0 to 1.0 (inclusive) which is the offset of
+the point within the grid cell in each dimension.  The default is 0.5
+for the center of the cell.  A value of 0.0 is the lower left corner
+point; a value of 1.0 is the upper right corner point.  There is
+typically no need to change the default as it is optimal for
+minimizing the number of ghost cells needed.
+
+If a processor maps its particles to grid cells, it needs to allow for
+its particles being outside its sub-domain between reneighboring.  The
+*distance* argument of the *set_distance()* method sets the furthest
+distance outside a processor's sub-domain which a particle can move.
+Typically this is half the neighbor skin distance, assuming
+reneighboring is done appropriately.  This distance is used in
+determining how many ghost cells a processor needs to store to enable
+its particles to be mapped to grid cells.  The default value is 0.0.
+
+Some commands, like the :doc:`kspace_style pppm <kspace_style>`
+command, map values (charge in the case of PPPM) to a stencil of grid
+cells beyond the grid cell the particle is in.  The stencil extent may
+be different in the low and high directions.  The *set_stencil_atom()*
+method defines the maximum values of those 2 extents, assumed to be
+the same in each of the 3 dimensions.  Both the lo and hi values are
+specified as positive integers.  The default values are both 0.
+
+Some commands, like the :doc:`kspace_style pppm <kspace_style>`
+command, shift the position of an atom when mapping it to a grid cell,
+based on the size of the stencil used to map values to the grid
+(charge in the case of PPPM).  The lo and hi arguments of the
+*set_shift_atom()* method are the minimum shift in the low direction
+and the maximum shift in the high direction, assumed to be the same in
+each of the 3 dimensions.  The shifts should be fractions of a grid
+cell size with values between 0.0 and 1.0 inclusive.  The default
+values are both 0.0.  See the src/pppm.cpp file for examples of these
+lo/hi values for regular and staggered grids.
+
+Some methods like the :doc:`fix ttm/grid <fix_ttm>` command, perform
+finite difference kinds of operations on the grid, to diffuse electron
+heat in the case of the two-temperature model (TTM).  This operation
+uses ghost grid values beyond the owned grid values the processor
+updates.  The *set_stencil_grid()* method defines the extent of this
+stencil in both directions, assumed to be the same in each of the 3
+dimensions.  Both the lo and hi values are specified as positive
+integers.  The default values are both 0.
+
+The kspace_style pppm commands allow a grid to be defined which
+overlays a volume which extends beyond the simulation box in the z
+dimension.  This is for the purpose of modeling a 2d-periodic slab
+(non-periodic in z) as if it were a larger 3d periodic system,
+extended (with empty space) in the z dimension.  The
+:doc:`kspace_modify slab <kspace_modify>` command is used to specify
+the ratio of the larger volume to the simulation volume; a volume
+ratio of ~3 is typical.  For this kind of model, the PPPM caller sets
+the global grid size *gnz* ~3x larger than it would be otherwise.
+This same ratio is passed by the PPPM caller as the *factor* argument
+to the Grid class via the *set_zfactor()* method (*set_yfactor()* for
+2d grids).  The Grid class will then assign ownership of the 1/3 of
+grid cells that overlay the simulation box to the processors which
+also overlay the simulation box.  The remaining 2/3 of the grid cells
+are assigned to processors whose sub-domains are adjacent to the upper
+z boundary of the simulation box.
+
+----------
+
+Grid class setup_grid method
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The *setup_grid()* method is called after the first constructor
+(above) to partition the grid across processors, which determines
+which grid cells each processor owns.  It also calculates how many
+ghost grid cells in each dimension and each direction each processor
+needs to store.
+
+Note that this method is NOT called if the second constructor above is
+used.  In that case, the caller assigns owned and ghost cells to each
+processor.
+
+Also note that this method must be invoked after any *set_*()* methods have
+been used, since they can influence the assignment of owned and ghost
+cells.
+
+.. code-block:: c++
+
+   void setup_grid(int &ixlo, int &ixhi, int &iylo, int &iyhi, int &izlo, int &izhi,
+                   int &oxlo, int &oxhi, int &oylo, int &oyhi, int &ozlo, int &ozhi)
+
+The 6 return arguments which start with "i" are the inclusive lower
+and upper index bounds of the owned (inner) grid cells this processor
+owns in each of the 3 dimensions within the global grid.  Owned grid
+cells are indexed from 0 to N-1 in each dimension.
+
+The 6 return arguments which start with "o" are the inclusive bounds of
+the owned+ghost cells it owns.  If the ghost cells are on the other
+side of a periodic boundary, then these indices may be < 0 or >= N in
+any dimension, so that oxlo <= ixlo and ixhi >= ixhi is always the
+case.
+
+----------
+
+More grid class set methods
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The following 2 methods can be used to override settings made by the
+constructors above.  If used, they must be called called before the
+*setup_comm()* method is invoked, since it uses the settings that
+these methods override.  In LAMMPS these methods are called by by the
+:doc:`kspace_style msm <kspace_style>` command for the grids it
+instantiates using the 2nd constructor above.
+
+.. code-block:: c++
+
+   void set_proc_neighs(int pxlo, int pxhi, int pylo, int pyhi, int pzlo, int pzhi)
+   void set_caller_grid(int fxlo, int fxhi, int fylo, int fyhi, int fzlo, int fzhi)
+
+The *set_proc_neighs()* method sets the processor IDs of the 6
+neighboring processors for each processor.  Normally these would match
+the processor grid neighbors which LAMMPS creates to overlay the
+simulation box (the default).  However, MSM excludes non-participating
+processors from coarse grid communication when less processors are
+used.  This method allows MSM to override the default values.
+
+The *set_caller_grid()* method species the size of the data arrays the
+caller allocates.  Normally these would match the extent of the ghost
+grid cells (the default).  However the MSM caller allocates a larger
+data array (more ghost cells) for its finest-level grid, for use in
+other operations besides owned/ghost cell communication.  This method
+allows MSM to override the default values.
+
+
+----------
+
+Grid class get methods
+^^^^^^^^^^^^^^^^^^^^^^
+
+The following methods allow the caller to query the settings for a
+specific grid, whether it created the grid or another command created
+it.
+
+.. code-block:: c++
+
+   void get_size(int &nxgrid, int &nygrid, int &nzgrid);
+   void get_bounds_owned(int &xlo, int &xhi, int &ylo, int &yhi, int &zlo, int &zhi)
+   void get_bounds_ghost(int &xlo, int &xhi, int &ylo, int &yhi, int &zlo, int &zhi)
+
+The *get_size()* method returns the size of the global grid in each dimension.
+
+The *get_bounds_owned()* method return the inclusive index bounds of
+the grid cells this processor owns.  The values range from 0 to N-1 in
+each dimension.  These values are the same as the "i" values returned
+by *setup_grid()*.
+
+The *get_bounds_ghost()* method return the inclusive index bounds of
+the owned+ghost grid cells this processor stores.  The owned cell
+indices range from 0 to N-1, so these indices may be less than 0 or
+greater than or equal to N in each dimension.  These values are the
+same as the "o" values returned by *setup_grid()*.
+
+----------
+
+Grid class owned/ghost communication
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If needed by the command, the following methods setup and perform
+communication of grid data to/from neighboring processors.  The
+*forward_comm()* method sends owned grid cell data to the
+corresponding ghost grid cells on other processors.  The
+*reverse_comm()* method sends ghost grid cell data to the
+corresponding owned grid cells on another processor.  The caller can
+choose to sum ghost grid cell data to the owned grid cell or simply
+copy it.
+
+.. code-block:: c++
+
+   void setup_comm(int &nbuf1, int &nbuf2)
+   void forward_comm(int caller, void *ptr, int which, int nper, int nbyte,
+                     void *buf1, void *buf2, MPI_Datatype datatype);
+   void reverse_comm(int caller, void *ptr, int which, int nper, int nbyte,
+                     void *buf1, void *buf2, MPI_Datatype datatype)
+   int ghost_adjacent();
+
+The *setup_comm()* method must be called one time before performing
+*forward* or *reverse* communication (multiple times if needed).  It
+returns two integers, which should be used to allocate two buffers.
+The *nbuf1* and *nbuf2* values are the number of grid cells whose data
+will be stored in two buffers by the Grid class when *forward* or
+*reverse* communication is performed.  The caller should thus allocate
+them to a size large enough to hold all the data used in any single
+forward or reverse communication operation it performs.  Note that the
+caller may allocate and communicate multiple data arrays for a grid it
+instantiates.  This size includes the bytes needed for the data type
+of the grid data it stores, e.g. double precision values.
+
+The *forward_comm()* and *reverse_comm()* methods send grid cell data
+from owned to ghost cells, or ghost to owned cells, respectively, as
+described above.  The *caller* argument should be one of these values
+-- Grid3d::COMPUTE, Grid3d::FIX, Grid3d::KSPACE, Grid3d::PAIR --
+depending on the style of the caller class.  The *ptr* argument is the
+"this" pointer to the caller class.  These 2 arguments are used to
+call back to pack()/unpack() functions in the caller class, as
+explained below.
+
+The *which* argument is a flag the caller can set which is passed to
+the caller's pack()/unpack() methods.  This allows a single callback
+method to pack/unpack data for several different flavors of
+forward/reverse communication, e.g. operating on different grids or
+grid data.
+
+The *nper* argument is the number of values per grid cell to be
+communicated.  The *nbyte* argument is the number of bytes per value,
+e.g. 8 for double-precision values.  The *buf1* and *buf2* arguments
+are the two allocated buffers described above.  So long as they are
+allocated for the maximum size communication, they can be re-used for
+any *forward_comm()/reverse_comm()* call.  The *datatype* argument is
+the MPI_Datatype setting, which should match the buffer allocation and
+the *nbyte* argument.  E.g. MPI_DOUBLE for buffers storing double
+precision values.
+
+To use the *forward_grid()* method, the caller must provide two
+callback functions; likewise for use of the *reverse_grid()* methods.
+These are the 4 functions, their arguments are all the same.
+
+.. code-block:: c++
+
+   void pack_forward_grid(int which, void *vbuf, int nlist, int *list);
+   void unpack_forward_grid(int which, void *vbuf, int nlist, int *list);
+   void pack_reverse_grid(int which, void *vbuf, int nlist, int *list);
+   void unpack_reverse_grid(int which, void *vbuf, int nlist, int *list);
+
+The *which* argument is set to the *which* value of the
+*forward_comm()* or *reverse_comm()* calls.  It allows the pack/unpack
+function to select what data values to pack/unpack.  *Vbuf* is the
+buffer to pack/unpack the data to/from.  It is a void pointer so that
+the caller can cast it to whatever data type it chooses, e.g. double
+precision values.  *Nlist* is the number of grid cells to pack/unpack
+and *list* is a vector (nlist in length) of offsets to where the data
+for each grid cell resides in the caller's data arrays, which is best
+illustrated with an example from the src/EXTRA-FIX/fix_ttm_grid.cpp
+class which stores the scalar electron temperature for 3d system in a
+3d grid (one value per grid cell):
+
+.. code-block:: c++
+
+   void FixTTMGrid::pack_forward_grid(int /*which*/, void *vbuf, int nlist, int *list)
+   {
+     auto buf = (double *) vbuf;
+     double *src = &T_electron[nzlo_out][nylo_out][nxlo_out];
+     for (int i = 0; i < nlist; i++) buf[i] = src[list[i]];
+   }
+
+In this case, the *which* argument is not used, *vbuf* points to a
+buffer of doubles, and the electron temperature is stored by the
+FixTTMGrid class in a 3d array of owned+ghost cells called T_electron.
+That array is allocated by the *memory->create_3d_offset()* method
+described above so that the first grid cell it stores is indexed as
+T_electron[nzlo_out][nylo_out][nxlo_out].  The *nlist* values in
+*list* are integer offsets from that first grid cell.  Setting *src*
+to the address of the first cell allows those offsets to be used to
+access the temperatures to pack into the buffer.
+
+Here is a similar portion of code from the src/fix_ave_grid.cpp class
+which can store two kinds of data, a scalar count of atoms in a grid
+cell, and one or more grid-cell-averaged atom properties.  The code
+from its *unpack_reverse_grid()* function for 2d grids and multiple
+per-atom properties per grid cell (*nvalues*) is shown here:
+
+.. code-block:: c++
+
+   void FixAveGrid::unpack_reverse_grid(int /*which*/, void *vbuf, int nlist, int *list)
+   {
+     auto buf = (double *) vbuf;
+     double *count,*data,*values;
+     count = &count2d[nylo_out][nxlo_out];
+     data = &array2d[nylo_out][nxlo_out][0];
+     m = 0;
+     for (i = 0; i < nlist; i++) {
+       count[list[i]] += buf[m++];
+       values = &data[nvalues*list[i]];
+       for (j = 0; j < nvalues; j++)
+        values[j] += buf[m++];
+     }
+   }
+
+Both the count and the multiple values per grid cell are communicated
+in *vbuf*.  Note that *data* is now a pointer to the first value in
+the first grid cell.  And *values* points to where the first value in
+*data* is for an offset of grid cells, calculated by multiplying
+*nvalues* by *list[i]*.  Finally, because this is reverse
+communication, the communicated buffer values are summed to the caller
+values.
+
+The *ghost_adjacent()* method returns a 1 if every processor can
+perform the necessary owned/ghost communication with only its nearest
+neighbor processors (4 in 2d, 6 in 3d).  It returns a 0 if any
+processor's ghost cells extend further than nearest neighbor
+processors.
+
+This can be checked by callers who have the option to change the
+global grid size to insure more efficient nearest-neighbor-only
+communication if they wish.  In this case, they instantiate a grid of
+a given size (resolution), then invoke *setup_comm()* followed by
+*ghost_adjacent()*.  If the ghost cells are not adjacent, they destroy
+the grid instance and start over with a higher-resolution grid.
+Several of the :doc:`kspace_style pppm <kspace_style>` command
+variants have this option.
+
+----------
+
+Grid class remap methods for load balancing
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The following methods are used when a load-balancing operation,
+triggered by the :doc:`balance <balance>` or :doc:`fix balance
+<fix_balance>` commands, changes the partitioning of the simulation
+domain into processor sub-domains.
+
+In order to work with load-balancing, any style command (compute, fix,
+pair, or kspace style) which allocates a grid and stores per-grid data
+should define a *reset_grid()* method; it takes no arguments.  It will
+be called by the two balance commands after they have reset processor
+sub-domains and migrated atoms (particles) to new owning processors.
+The *reset_grid()* method will typically perform some or all of the
+following operations.  See the src/fix_ave_grid.cpp and
+src/EXTRA_FIX/fix_ttm_grid.cpp files for examples of *reset_grid()*
+methods, as well as the *pack_remap_grid()* and *unpack_remap_grid()*
+functions.
+
+First, the *reset_grid()* method can instantiate new grid(s) of the
+same global size, then call *setup_grid()* to partition them via the
+new processor sub-domains.  At this point, it can invoke the
+*identical()* method which compares the owned and ghost grid cell
+index bounds between two grids, the old grid passed as a pointer
+argument, and the new grid whose *identical()* method is being called.
+It returns 1 if the indices match on all processors, otherwise 0.  If
+they all match, then the new grids can be deleted; the command can
+continue to use the old grids.
+
+If not, then the command should allocate new grid data array(s) which
+depend on the new partitioning.  If the command does not need to
+persist its grid data from the old partitioning to the new one, then
+the command can simply delete the old data array(s) and grid
+instance(s).  It can then return.
+
+If the grid data does need to persist, then the data for each grid
+needs to be "remapped" from the old grid partitioning to the new grid
+partitioning.  The *setup_remap()* and *remap()* methods are used for
+that purpose.
+
+.. code-block:: c++
+
+   int identical(Grid3d *old);
+   void setup_remap(Grid3d *old, int &nremap_buf1, int &nremap_buf2)
+   void remap(int caller, void *ptr, int which, int nper, int nbyte,
+              void *buf1, void *buf2, MPI_Datatype datatype)
+
+The arguments to these methods are identical to those for
+the *setup_comm()* and *forward_comm()* or *reverse_comm()* methods.
+However the returned *nremap_buf1* and *nremap2_buf* values will be
+different than the *nbuf1* and *nbuf2* values.  They should be used to
+allocate two different remap buffers, separate from the owned/ghost
+communication buffers.
+
+To use the *remap()* method, the caller must provide two
+callback functions:
+
+.. code-block:: c++
+
+   void pack_remap_grid(int which, void *vbuf, int nlist, int *list);
+   void unpack_remap_grid(int which, void *vbuf, int list, int *list);
+
+Their arguments are identical to those for the *pack_forward_grid()*
+and *unpack_forward_grid()* callback functions (or the reverse
+variants) discussed above.  Normally, both these methods pack/unpack
+all the data arrays for a given grid.  The *which* argument of the
+*remap()* method sets the *which* value for the pack/unpack functions.
+If the command instantiates multiple grids (of different sizes), it
+can be used within the pack/unpack methods to select which grid's data
+is being remapped.
+
+Note that the *pack_remap_grid()* function must copy values from the
+OLD grid data arrays into the *vbuf* buffer. The *unpack_remap_grid()*
+function must copy values from the *vbuf* buffer into the NEW grid
+data arrays.
+
+After the remap operation for grid cell data has been performed, the
+*reset_grid()* method can deallocate the two remap buffers it created,
+and can then exit.
+
+----------
+
+Grid class I/O methods
+^^^^^^^^^^^^^^^^^^^^^^
+
+There are two I/O methods in the Grid classes which can be used to
+read and write grid cell data to files.  The caller can decide on the
+precise format of each file, e.g. whether header lines are prepended
+or comment lines are allowed.  Fundamentally, the file should contain
+one line per grid cell for the entire global grid.  Each line should
+contain identifying info as to which grid cell it is, e.g. a unique
+grid cell ID or the ix,iy,iz indices of the cell within a 3d grid.
+The line should also contain one or more data values which are stored
+within the grid data arrays created by the command
+
+For grid cell IDs, the LAMMPS convention is that the IDs run from 1 to
+N, where N = Nx * Ny for 2d grids and N = Nx * Ny * Nz for 3d grids.
+The x-index of the grid cell varies fastest, then y, and the z-index
+varies slowest.  So for a 10x10x10 grid the cell IDs from 901-1000
+would be in the top xy layer of the z dimension.
+
+The *read_file()* method does something simple.  It reads a chunk of
+consecutive lines from the file and passes them back to the caller to
+process.  The caller provides a *unpack_read_grid()* function for this
+purpose.  The function checks the grid cell ID or indices and only
+stores grid cell data for the grid cells it owns.
+
+The *write_file()* method does something slightly more complex.  Each
+processor packs the data for its owned grid cells into a buffer.  The
+caller provides a *pack_write_grid()* function for this purpose.  The
+*write_file()* method then loops over all processors and each sends
+its buffer one at a time to processor 0, along with the 3d (or 2d)
+index bounds of its grid cell data within the global grid.  Processor
+0 calls back to the *unpack_write_grid()* function provided by the
+caller with the buffer.  The function writes one line per grid cell to
+the file.
+
+See the src/EXTRA_FIX/fix_ttm_grid.cpp file for examples of now both
+these methods are used to read/write electron temperature values
+from/to a file, as well as for implementations of the the pack/unpack
+functions described below.
+
+Here are the details of the two I/O methods and the 3 callback
+functions.  See the src/fix_ave_grid.cpp file for examples of all of
+them.
+
+.. code-block:: c++
+
+   void read_file(int caller, void *ptr, FILE *fp, int nchunk, int maxline)
+   void write_file(int caller, void *ptr, int which,
+                   int nper, int nbyte, MPI_Datatype datatype
+
+The *caller* argument in both methods should be one of these values --
+Grid3d::COMPUTE, Grid3d::FIX, Grid3d::KSPACE, Grid3d::PAIR --
+depending on the style of the caller class.  The *ptr* argument in
+both methods is the "this" pointer to the caller class.  These 2
+arguments are used to call back to pack()/unpack() functions in the
+caller class, as explained below.
+
+For the *read_file()* method, the *fp* argument is a file pointer to
+the file to be read from, opened on processor 0 by the caller.
+*Nchunk* is the number of lines to read per chunk, and *maxline* is
+the maximum number of characters per line.  The Grid class will
+allocate a buffer for storing chunks of lines based on these values.
+
+For the *write_file()* method, the *which* argument is a flag the
+caller can set which is passed back to the caller's pack()/unpack()
+methods.  If the command instantiates multiple grids (of different
+sizes), this flag can be used within the pack/unpack methods to select
+which grid's data is being written out (presumably to different
+files).  the *nper* argument is the number of values per grid cell to
+be written out.  The *nbyte* argument is the number of bytes per
+value, e.g. 8 for double-precision values.  The *datatype* argument is
+the MPI_Datatype setting, which should match the *nbyte* argument.
+E.g. MPI_DOUBLE for double precision values.
+
+To use the *read_grid()* method, the caller must provide one callback
+function.  To use the *write_grid()* method, it provides two callback
+functions:
+
+.. code-block:: c++
+
+   int unpack_read_grid(int nlines, char *buffer)
+   void pack_write_grid(int which, void *vbuf)
+   void unpack_write_grid(int which, void *vbuf, int *bounds)
+
+For *unpack_read_grid()* the *nlines* argument is the number of lines
+of character data read from the file and contained in *buffer*.  The
+lines each include a newline character at the end.  When the function
+processes the lines, it may choose to skip some of them (header or
+comment lines).  It returns an integer count of the number of grid
+cell lines it processed.  This enables the Grid class *read_file()*
+method to know when it has read the correct number of lines.
+
+For *pack_write_grid()* and *unpack_write_grid()*, the *vbuf* argument
+is the buffer to pack/unpack data to/from.  It is a void pointer so
+that the caller can cast it to whatever data type it chooses,
+e.g. double precision values.  the *which* argument is set to the
+*which* value of the *write_file()* method.  It allows the caller to
+choose which grid data to operate on.
+
+For *unpack_write_grid()*, the *bounds* argument is a vector of 4 or 6
+integer grid indices (4 for 2d, 6 for 3d).  They are the
+xlo,xhi,ylo,yhi,zlo,zhi index bounds of the portion of the global grid
+which the *vbuf* holds owned grid cell data values for.  The caller
+should loop over the values in *vbuf* with a double loop (2d) or
+triple loop (3d), similar to the code snippets listed above.  The
+x-index varies fastest, then y, and the z-index slowest.  If there are
+multiple values per grid cell, the index for those values varies
+fastest of all.  The caller can add the x,y,z indices of the grid cell
+(or the corresponding grid cell ID) to the data value(s) written as
+one line to the output file.
+
+----------
+
+Style class grid access methods
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A style command can enable its grid cell data to be accessible from
+other commands.  For example :doc:`fix ave/grid <fix_ave_grid>` or
+:doc:`dump grid <dump>` or :doc:`dump grid/vtk <dump>`.  Those
+commands access the grid cell data by using a *grid reference* in
+their input script syntax, as described on the :doc:`Howto_grid
+<Howto_grid>` doc page.  They look like this:
+
+* c_ID:gname:dname
+* c_ID:gname:dname[I]
+* f_ID:gname:dname
+* f_ID:gname:dname[I]
+
+Each grid a command instantiates has a unique *gname*, defined by the
+command.  Likewise each grid cell data structure (scalar or vector)
+associated with a grid has a unique *dname*, also defined by the
+command.
+
+To provide access to its grid cell data, a style command needs to
+implement the following 4 methods:
+
+.. code-block:: c++
+
+   int get_grid_by_name(const std::string &name, int &dim);
+   void *get_grid_by_index(int index);
+   int get_griddata_by_name(int igrid, const std::string &name, int &ncol);
+   void *get_griddata_by_index(int index);
+
+Currently only computes and fixes can implement these methods.  If it
+does so, the compute of fix should also set the variable
+*pergrid_flag* to 1.  See any of the compute or fix commands which set
+"pergrid_flag = 1" for examples of how these 4 functions can be
+implemented.
+
+The *get_grid_by_name()* method takes a grid name as input and returns
+two values.  The *dim* argument is returned as 2 or 3 for the
+dimensionality of the grid.  The function return is a grid index from
+0 to G-1 where *G* is the number of grids the command instantiates.  A
+value of -1 is returned if the grid name is not recognized.
+
+The *get_grid_by_index()* method is called after the
+*get_grid_by_name()* method, using the grid index it returned as its
+argument.  This method will return a pointer to the Grid2d or Grid3d
+class.  The caller can use this to query grid attributes, such as the
+global size of the grid.  The :doc:`dump grid <dump>` to insure each
+its grid reference arguments are for grids of the same size.
+
+The *get_griddata_by_name()* method takes a grid index *igrid* and a
+data name as input.  It returns two values.  The *ncol* argument is
+returned as a 0 if the grid data is a single value (scalar) per grid
+cell, or an integer M > 0 if there are M values (vector) per grid
+cell.  Note that even if M = 1, it is still a 1-length vector, not a
+scalar.  The function return is a data index from 0 to D-1 where *D*
+is the number of data sets associated with that grid by the command.
+A value of -1 is returned if the data name is not recognized.
+
+The *get_griddata_by_index()* method is called after the
+*get_griddata_by_name()* method, using the data index it returned as
+its argument.  This method will return a pointer to the
+multi-dimensional array which stores the requested data.
+
+As in the discussion above of the Memory class *create_offset()*
+methods, the dimensionality of the array associated with the returned
+pointer depends on whether it is a 2d or 3d grid and whether there is
+a single or multiple values stored for each grid cell:
+
+* single value per cell for a 2d grid = 2d array pointer
+* multiple values per cell for a 2d grid = 3d array pointer
+* single value per cell for a 3d grid = 3d array pointer
+* multiple values per cell for a 3d grid = 4d array pointer
+
+The caller will typically access the data by casting the void pointer
+to the corresponding array pointer and using nested loops in x,y,z
+between owned or ghost index bounds returned by the
+*get_bounds_owned()* or *get_bounds_ghost()* methods to index into the
+array.  Example code snippets with this logic were listed above,
+
+----------
+
+Final notes
+^^^^^^^^^^^
+
+Finally, here are some additional issues to pay attention to for
+writing any style command which uses distributed grids via the Grid2d
+or Grid3d class.
+
+The command destructor should delete all instances of the Grid class,
+any buffers it allocated for forward/reverse or remap communication,
+and any data arrays it allocated to store grid cell data.
+
+If a command is intended to work for either 2d or 3d simulations, then
+it should have logic to instantiate either 2d or 3d grids and their
+associated data arrays, depending on the dimension of the simulation
+box.  The :doc:`fix ave/grid <fix_ave_grid>` command is an example of
+such a command.
+
+When a command maps its particles to the grid and updates grid cell
+values, it should check that it is not updating or accessing a grid
+cell value outside the range of its owned+ghost cells, and generate an
+error message if that is the case.  This could happen, for example, if
+a particle has moved further than half the neighbor skin distance,
+because the neighbor list update criterion are not adequate to prevent
+it from happening.  See the src/KSPACE/pppm.cpp file and its
+*particle_map()* method for an example of this kind of error check.

doc/src/Developer_notes.rst

@@ -105,7 +105,7 @@ list, where each pair of atoms is listed only once (except when the
 pairs straddling sub-domains or periodic boundaries will be listed twice).
 Thus these are the default settings when a neighbor list request is created in:
 
-.. code-block:: C++
+.. code-block:: c++
 
    void Pair::init_style()
    {
@@ -129,7 +129,7 @@ neighbor list request to the specific needs of a style an additional
 request flag is needed.  The :doc:`tersoff <pair_tersoff>` pair style,
 for example, needs a "full" neighbor list:
 
-.. code-block:: C++
+.. code-block:: c++
 
    void PairTersoff::init_style()
    {
@@ -141,7 +141,7 @@ When a pair style supports r-RESPA time integration with different cutoff region
 the request flag may depend on the corresponding r-RESPA settings. Here an example
 from pair style lj/cut:
 
-.. code-block:: C++
+.. code-block:: c++
 
    void PairLJCut::init_style()
    {
@@ -160,7 +160,7 @@ Granular pair styles need neighbor lists based on particle sizes and not cutoff
 and also may require to have the list of previous neighbors available ("history").
 For example with:
 
-.. code-block:: C++
+.. code-block:: c++
 
    if (use_history) neighbor->add_request(this, NeighConst::REQ_SIZE | NeighConst::REQ_HISTORY);
    else neighbor->add_request(this, NeighConst::REQ_SIZE);
@@ -170,7 +170,7 @@ settings each request can set an id which is then used in the corresponding
 ``init_list()`` function to assign it to the suitable pointer variable. This is
 done for example by the :doc:`pair style meam <pair_meam>`:
 
-.. code-block:: C++
+.. code-block:: c++
 
    void PairMEAM::init_style()
    {
@@ -189,7 +189,7 @@ just once) and this can also be indicated by a flag.  As an example here
 is the request from the ``FixPeriNeigh`` class which is created
 internally by :doc:`Peridynamics pair styles <pair_peri>`:
 
-.. code-block:: C++
+.. code-block:: c++
 
    neighbor->add_request(this, NeighConst::REQ_FULL | NeighConst::REQ_OCCASIONAL);
 
@@ -198,7 +198,7 @@ than what is usually inferred from the pair style settings (largest cutoff of
 all pair styles plus neighbor list skin).  The following is used in the
 :doc:`compute rdf <compute_rdf>` command implementation:
 
-.. code-block:: C++
+.. code-block:: c++
 
   if (cutflag)
     neighbor->add_request(this, NeighConst::REQ_OCCASIONAL)->set_cutoff(mycutneigh);
@@ -212,7 +212,7 @@ for printing the neighbor list summary the name of the requesting command
 should be set.  Below is the request from the :doc:`delete atoms <delete_atoms>`
 command:
 
-.. code-block:: C++
+.. code-block:: c++
 
    neighbor->add_request(this, "delete_atoms", NeighConst::REQ_FULL);
 

doc/src/Developer_plugins.rst

@@ -95,7 +95,7 @@ a class ``PairMorse2`` in the files ``pair_morse2.h`` and
 ``pair_morse2.cpp`` with the factory function and initialization
 function would look like this:
 
-.. code-block:: C++
+.. code-block:: c++
 
   #include "lammpsplugin.h"
   #include "version.h"
@@ -141,7 +141,7 @@ list of argument strings), then the pointer type is ``lammpsplugin_factory2``
 and it must be assigned to the *creator.v2* member of the plugin struct.
 Below is an example for that:
 
-.. code-block:: C++
+.. code-block:: c++
 
   #include "lammpsplugin.h"
   #include "version.h"
@@ -176,7 +176,7 @@ demonstrated in the following example, which also shows that the
 implementation of the plugin class may be within the same source
 file as the plugin interface code:
 
-.. code-block:: C++
+.. code-block:: c++
 
    #include "lammpsplugin.h"
 

doc/src/Developer_unittest.rst

@@ -194,7 +194,7 @@ macro. These tests operate by capturing the screen output when executing
 the failing command and then comparing that with a provided regular
 expression string pattern.  Example:
 
-.. code-block:: C++
+.. code-block:: c++
 
    TEST_F(SimpleCommandsTest, UnknownCommand)
    {
@@ -226,9 +226,9 @@ The following test programs are currently available:
    * - ``test_kim_commands.cpp``
      - KimCommands
      - Tests for several commands from the :ref:`KIM package <PKG-KIM>`
-   * - ``test_reset_ids.cpp``
-     - ResetIDs
-     - Tests to validate the :doc:`reset_atom_ids <reset_atom_ids>` and :doc:`reset_mol_ids <reset_mol_ids>` commands
+   * - ``test_reset_atoms.cpp``
+     - ResetAtoms
+     - Tests to validate the :doc:`reset_atoms <reset_atoms>` sub-commands
 
 
 Tests for the C-style library interface
@@ -249,7 +249,7 @@ MPI support.  These include tests where LAMMPS is run in multi-partition
 mode or only on a subset of the MPI world communicator.  The CMake
 script code for adding this kind of test looks like this:
 
-.. code-block:: CMake
+.. code-block:: cmake
 
    if (BUILD_MPI)
      add_executable(test_library_mpi test_library_mpi.cpp)

doc/src/Developer_updating.rst

@@ -0,0 +1,479 @@
+Notes for updating code written for older LAMMPS versions
+---------------------------------------------------------
+
+This section documents how C++ source files that are available *outside
+of the LAMMPS source distribution* (e.g. in external USER packages or as
+source files provided as a supplement to a publication) that are written
+for an older version of LAMMPS and thus need to be updated to be
+compatible with the current version of LAMMPS.  Due to the active
+development of LAMMPS it is likely to always be incomplete.  Please
+contact developers@lammps.org in case you run across an issue that is not
+(yet) listed here.  Please also review the latest information about the
+LAMMPS :doc:`programming style conventions <Modify_style>`, especially
+if you are considering to submit the updated version for inclusion into
+the LAMMPS distribution.
+
+Available topics in mostly chronological order are:
+
+- `Setting flags in the constructor`_
+- `Rename of pack/unpack_comm() to pack/unpack_forward_comm()`_
+- `Use ev_init() to initialize variables derived from eflag and vflag`_
+- `Use utils::numeric() functions instead of force->numeric()`_
+- `Use utils::open_potential() function to open potential files`_
+- `Simplify customized error messages`_
+- `Use of "override" instead of "virtual"`_
+- `Simplified and more compact neighbor list requests`_
+- `Split of fix STORE into fix STORE/GLOBAL and fix STORE/PERATOM`_
+- `Use Output::get_dump_by_id() instead of Output::find_dump()`_
+- `Refactored grid communication using Grid3d/Grid2d classes instead of GridComm`_
+
+----
+
+Setting flags in the constructor
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+As LAMMPS gains additional functionality, new flags may need to be set
+in the constructor or a class to signal compatibility with such features.
+Most of the time the defaults are chosen conservatively, but sometimes
+the conservative choice is the uncommon choice, and then those settings
+need to be made when updating code.
+
+Pair styles:
+
+  - ``manybody_flag``: set to 1 if your pair style is not pair-wise additive
+  - ``restartinfo``: set to 0 if your pair style does not store data in restart files
+
+
+Rename of pack/unpack_comm() to pack/unpack_forward_comm()
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: 8Aug2014
+
+In this change set the functions to pack data into communication buffers
+and to unpack data from communication buffers for :doc:`forward
+communications <Developer_comm_ops>` were renamed from ``pack_comm()``
+and ``unpack_comm()`` to ``pack_forward_comm()`` and
+``unpack_forward_comm()``, respectively.  Also the meaning of the return
+value of these functions was changed: rather than returning the number
+of items per atom stored in the buffer, now the total number of items
+added (or unpacked) needs to be returned.  Here is an example from the
+`PairEAM` class.  Of course the member function declaration in corresponding
+header file needs to be updated accordingly.
+
+Old:
+
+.. code-block:: c++
+
+   int PairEAM::pack_comm(int n, int *list, double *buf, int pbc_flag, int *pbc)
+   {
+     int m = 0;
+     for (int i = 0; i < n; i++) {
+       int j = list[i];
+       buf[m++] = fp[j];
+     }
+     return 1;
+   }
+
+New:
+
+.. code-block:: c++
+
+   int PairEAM::pack_forward_comm(int n, int *list, double *buf, int pbc_flag, int *pbc)
+   {
+     int m = 0;
+     for (int i = 0; i < n; i++) {
+       int j = list[i];
+       buf[m++] = fp[j];
+     }
+     return m;
+   }
+
+.. note::
+
+   Because the various "pack" and "unpack" functions are defined in the
+   respective base classes as dummy functions doing nothing, and because
+   of the the name mismatch the custom versions in the derived class
+   will no longer be called, there will be no compilation error when
+   this change is not applied.  Only calculations will suddenly produce
+   incorrect results because the required forward communication calls
+   will cease to function correctly.
+
+Use ev_init() to initialize variables derived from eflag and vflag
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: 29Mar2019
+
+There are several variables that need to be initialized based on
+the values of the "eflag" and "vflag" variables and since sometimes
+there are new bits added and new variables need to be set to 1 or 0.
+To make this consistent, across all styles, there is now an inline
+function ``ev_init(eflag, vflag)`` that makes those settings
+consistently and calls either ``ev_setup()`` or ``ev_unset()``.
+Example from a pair style:
+
+Old:
+
+.. code-block:: c++
+
+   if (eflag || vflag) ev_setup(eflag, vflag);
+   else evflag = vflag_fdotr = eflag_global = eflag_atom = 0;
+
+New:
+
+.. code-block:: c++
+
+   ev_init(eflag, vflag);
+
+Not applying this change will not cause a compilation error, but
+can lead to inconsistent behavior and incorrect tallying of
+energy or virial.
+
+Use utils::numeric() functions instead of force->numeric()
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: 18Sep2020
+
+The "numeric()" conversion functions (including "inumeric()",
+"bnumeric()", and "tnumeric()") have been moved from the Force class to
+the utils namespace.  Also they take an additional argument that selects
+whether the ``Error::all()`` or ``Error::one()`` function should be
+called in case of an error.  The former should be used when *all* MPI
+processes call the conversion function and the latter *must* be used
+when they are called from only one or a subset of the MPI processes.
+
+Old:
+
+.. code-block:: c++
+
+    val = force->numeric(FLERR, arg[1]);
+    num = force->inumeric(FLERR, arg[2]);
+
+New:
+
+.. code-block:: c++
+
+    val = utils::numeric(FLERR, true, arg[1], lmp);
+    num = utils::inumeric(FLERR, false, arg[2], lmp);
+
+.. seealso::
+
+   :cpp:func:`utils::numeric() <LAMMPS_NS::utils::numeric>`,
+   :cpp:func:`utils::inumeric() <LAMMPS_NS::utils::inumeric>`,
+   :cpp:func:`utils::bnumeric() <LAMMPS_NS::utils::bnumeric>`,
+   :cpp:func:`utils::tnumeric() <LAMMPS_NS::utils::tnumeric>`
+
+Use utils::open_potential() function to open potential files
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: 18Sep2020
+
+The :cpp:func:`utils::open_potential()
+<LAMMPS_NS::utils::open_potential>` function must be used to replace
+calls to ``force->open_potential()`` and should be used to replace
+``fopen()`` for opening potential files for reading.  The custom
+function does three additional steps compared to ``fopen()``: 1) it will
+try to parse the ``UNITS:`` and ``DATE:`` metadata will stop with an
+error on a units mismatch and will print the date info, if present, in
+the log file; 2) for pair styles that support it, it will set up
+possible automatic unit conversions based on the embedded unit
+information and LAMMPS' current units setting; 3) it will not only try
+to open a potential file at the given path, but will also search in the
+folders listed in the ``LAMMPS_POTENTIALS`` environment variable.  This
+allows to keep potential files in a common location instead of having to
+copy them around for simulations.
+
+Old:
+
+.. code-block:: c++
+
+   fp = force->open_potential(filename);
+   fp = fopen(filename, "r");
+
+New:
+
+.. code-block:: c++
+
+   fp = utils::open_potential(filename, lmp);
+
+Simplify customized error messages
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: 14May2021
+
+Aided by features of the bundled {fmt} library, error messages now
+can have a variable number of arguments and the string will be interpreted
+as a {fmt} style format string so that custom error messages can be
+easily customized without having to use temporary buffers and ``sprintf()``.
+Example:
+
+Old:
+
+.. code-block:: c++
+
+   if (fptr == NULL) {
+     char str[128];
+     sprintf(str,"Cannot open AEAM potential file %s",filename);
+     error->one(FLERR,str);
+   }
+
+New:
+
+.. code-block:: c++
+
+   if (fptr == nullptr)
+     error->one(FLERR, "Cannot open AEAM potential file {}: {}", filename, utils::getsyserror());
+
+Use of "override" instead of "virtual"
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: 17Feb2022
+
+Since LAMMPS requires C++11 we switched to use the "override" keyword
+instead of "virtual" to indicate polymorphism in derived classes.  This
+allows the C++ compiler to better detect inconsistencies when an
+override is intended or not.  Please note that "override" has to be
+added to **all** polymorph functions in derived classes and "virtual"
+*only* to the function in the base class (or the destructor).  Here is
+an example from the ``FixWallReflect`` class:
+
+Old:
+
+.. code-block:: c++
+
+   FixWallReflect(class LAMMPS *, int, char **);
+   virtual ~FixWallReflect();
+   int setmask();
+   void init();
+   void post_integrate();
+
+New:
+
+.. code-block:: c++
+
+   FixWallReflect(class LAMMPS *, int, char **);
+   ~FixWallReflect() override;
+   int setmask() override;
+   void init() override;
+   void post_integrate() override;
+
+This change set will neither cause a compilation failure, nor will it
+change functionality, but if you plan to submit the updated code for
+inclusion into the LAMMPS distribution, it will be requested for achieve
+a consistent :doc:`programming style <Modify_style>`.
+
+Simplified function names for forward and reverse communication
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: 24Mar2022
+
+Rather then using the function name to distinguish between the different
+forward and reverse communication functions for styles, LAMMPS now uses
+the type of the "this" pointer argument.
+
+Old:
+
+.. code-block:: c++
+
+   comm->forward_comm_pair(this);
+   comm->forward_comm_fix(this);
+   comm->forward_comm_compute(this);
+   comm->forward_comm_dump(this);
+   comm->reverse_comm_pair(this);
+   comm->reverse_comm_fix(this);
+   comm->reverse_comm_compute(this);
+   comm->reverse_comm_dump(this);
+
+New:
+
+.. code-block:: c++
+
+   comm->forward_comm(this);
+   comm->reverse_comm(this);
+
+This change is **required** or else the code will not compile.
+
+Simplified and more compact neighbor list requests
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: 24Mar2022
+
+This change set reduces the amount of code required to request a
+neighbor list.  It enforces consistency and no longer requires to change
+internal data of the request.  More information on neighbor list
+requests can be :doc:`found here <Developer_notes>`. Example from the
+``ComputeRDF`` class:
+
+Old:
+
+.. code-block:: c++
+
+   int irequest = neighbor->request(this,instance_me);
+   neighbor->requests[irequest]->pair = 0;
+   neighbor->requests[irequest]->compute = 1;
+   neighbor->requests[irequest]->occasional = 1;
+   if (cutflag) {
+     neighbor->requests[irequest]->cut = 1;
+     neighbor->requests[irequest]->cutoff = mycutneigh;
+   }
+
+New:
+
+.. code-block:: c++
+
+   auto req = neighbor->add_request(this, NeighConst::REQ_OCCASIONAL);
+   if (cutflag) req->set_cutoff(mycutneigh);
+
+Public access to the ``NeighRequest`` class data members has been
+removed so this update is **required** to avoid compilation failure.
+
+Split of fix STORE into fix STORE/GLOBAL and fix STORE/PERATOM
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: 15Sep2022
+
+This change splits the GLOBAL and PERATOM modes of fix STORE into two
+separate fixes STORE/GLOBAL and STORE/PERATOM.  There was very little
+shared code between the two fix STORE modes and the two different code
+paths had to be prefixed with if statements.  Furthermore, some flags
+were used differently in the two modes leading to confusion.  Splitting
+the code into two fix styles, makes it more easily maintainable.  Since
+these are internal fixes, there is no user visible change.
+
+Old:
+
+.. code-block:: c++
+
+   #include "fix_store.h"
+
+   FixStore *fix = dynamic_cast<FixStore *>(
+      modify->add_fix(fmt::format("{} {} STORE peratom 1 13",id_pole,group->names[0]));
+
+   FixStore *fix = dynamic_cast<FixStore *>(modify->get_fix_by_id(id_pole));
+
+New:
+
+.. code-block:: c++
+
+   #include "fix_store_peratom.h"
+
+   FixStorePeratom *fix = dynamic_cast<FixStorePeratom *>(
+      modify->add_fix(fmt::format("{} {} STORE/PERATOM 1 13",id_pole,group->names[0]));
+
+   FixStorePeratom *fix = dynamic_cast<FixStorePeratom *>(modify->get_fix_by_id(id_pole));
+
+Old:
+
+.. code-block:: c++
+
+   #include "fix_store.h"
+
+   FixStore *fix = dynamic_cast<FixStore *>(
+      modify->add_fix(fmt::format("{} {} STORE global 1 1",id_fix,group->names[igroup]));
+
+   FixStore *fix = dynamic_cast<FixStore *>(modify->get_fix_by_id(id_fix));
+
+New:
+
+.. code-block:: c++
+
+   #include "fix_store_global.h"
+
+   FixStoreGlobal *fix = dynamic_cast<FixStoreGlobal *>(
+      modify->add_fix(fmt::format("{} {} STORE/GLOBAL 1 1",id_fix,group->names[igroup]));
+
+   FixStoreGlobal *fix = dynamic_cast<FixStoreGlobal *>(modify->get_fix_by_id(id_fix));
+
+This change is **required** or else the code will not compile.
+
+Use Output::get_dump_by_id() instead of Output::find_dump()
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: 15Sep2022
+
+The accessor function to individual dump style instances has been changed
+from ``Output::find_dump()`` returning the index of the dump instance in
+the list of dumps to ``Output::get_dump_by_id()`` returning a pointer to
+the dump directly.  Example:
+
+Old:
+
+.. code-block:: c++
+
+   int idump = output->find_dump(arg[iarg+1]);
+   if (idump < 0)
+     error->all(FLERR,"Dump ID in hyper command does not exist");
+   memory->grow(dumplist,ndump+1,"hyper:dumplist");
+   dumplist[ndump++] = idump;
+
+   [...]
+
+   if (dumpflag)
+     for (int idump = 0; idump < ndump; idump++)
+       output->dump[dumplist[idump]]->write();
+
+New:
+
+.. code-block:: c++
+
+   auto idump = output->get_dump_by_id(arg[iarg+1]);
+   if (!idump) error->all(FLERR,"Dump ID {} in hyper command does not exist", arg[iarg+1]);
+   dumplist.emplace_back(idump);
+
+   [...]
+
+   if (dumpflag) for (auto idump : dumplist) idump->write();
+
+This change is **required** or else the code will not compile.
+
+Refactored grid communication using Grid3d/Grid2d classes instead of GridComm
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: 22Dec2022
+
+The ``GridComm`` class was for creating and communicating distributed
+grids was replaced by the ``Grid3d`` class with added functionality.
+A ``Grid2d`` class was also added for additional flexibility.
+
+The new functionality and commands using the two grid classes are
+discussed on the following documentation pages:
+
+- :doc:`Howto_grid`
+- :doc:`Developer_grid`
+
+If you have custom LAMMPS code, which uses the GridComm class, here are some notes
+on how to adapt it for using the Grid3d class.
+
+(1) The constructor has changed to allow the ``Grid3d`` / ``Grid2d``
+    classes to partition the global grid across processors, both for
+    owned and ghost grid cells.  Previously any class which called
+    ``GridComm`` performed the partitioning itself and that information
+    was passed in the ``GridComm::GridComm()`` constructor.  There are
+    several "set" functions which can be called to alter how ``Grid3d``
+    / ``Grid2d`` perform the partitioning.  They should be sufficient
+    for most use cases of the grid classes.
+
+(2) The partitioning is triggered by the ``setup_grid()`` method.
+
+(3) The ``setup()`` method of the ``GridComm`` class has been replaced
+    by the ``setup_comm()`` method in the new grid classes.  The syntax
+    for the ``forward_comm()`` and ``reverse_comm()`` methods is
+    slightly altered as is the syntax of the associated pack/unpack
+    callback methods.  But the functionality of these operations is the
+    same as before.
+
+(4) The new ``Grid3d`` / ``Grid2d`` classes have additional
+    functionality for dynamic load-balancing of grids and their
+    associated data across processors.  This did not exist in the
+    ``GridComm`` class.
+
+This and more is explained in detail on the :doc:`Developer_grid` page.
+The following LAMMPS source files can be used as illustrative examples
+for how the new grid classes are used by computes, fixes, and various
+KSpace solvers which use distributed FFT grids:
+
+- ``src/fix_ave_grid.cpp``
+- ``src/compute_property_grid.cpp``
+- ``src/EXTRA-FIX/fix_ttm_grid.cpp``
+- ``src/KSPACE/pppm.cpp``
+
+This change is **required** or else the code will not compile.

doc/src/Developer_utils.rst

@@ -133,6 +133,9 @@ and parsing files or arguments.
 .. doxygenfunction:: trim_comment
    :project: progguide
 
+.. doxygenfunction:: strip_style_suffix
+   :project: progguide
+
 .. doxygenfunction:: star_subst
    :project: progguide
 
@@ -154,6 +157,9 @@ and parsing files or arguments.
 .. doxygenfunction:: trim_and_count_words
    :project: progguide
 
+.. doxygenfunction:: join_words
+   :project: progguide
+
 .. doxygenfunction:: split_words
    :project: progguide
 
@@ -172,6 +178,12 @@ and parsing files or arguments.
 .. doxygenfunction:: is_double
    :project: progguide
 
+.. doxygenfunction:: is_id
+   :project: progguide
+
+.. doxygenfunction:: is_type
+   :project: progguide
+
 Potential file functions
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -202,10 +214,16 @@ Argument processing
 .. doxygenfunction:: expand_args
    :project: progguide
 
+.. doxygenfunction:: parse_grid_id
+   :project: progguide
+
+.. doxygenfunction:: expand_type
+   :project: progguide
+
 Convenience functions
 ^^^^^^^^^^^^^^^^^^^^^
 
-.. doxygenfunction:: logmesg(LAMMPS *lmp, const S &format, Args&&... args)
+.. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &format, Args&&... args)
    :project: progguide
 
 .. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &mesg)
@@ -305,7 +323,7 @@ are all "whitespace" characters, i.e. the space character, the tabulator
 character, the carriage return character, the linefeed character, and
 the form feed character.
 
-.. code-block:: C++
+.. code-block:: c++
    :caption: Tokenizer class example listing entries of the PATH environment variable
 
    #include "tokenizer.h"
@@ -337,7 +355,7 @@ tokenizer into a ``try`` / ``catch`` block to handle errors.  The
 when a (type of) number is requested as next token that is not
 compatible with the string representing the next word.
 
-.. code-block:: C++
+.. code-block:: c++
    :caption: ValueTokenizer class example with exception handling
 
    #include "tokenizer.h"
@@ -415,7 +433,7 @@ one or two array indices "[<number>]" with numbers > 0.
 
 A typical code segment would look like this:
 
-.. code-block:: C++
+.. code-block:: c++
    :caption: Usage example for ArgInfo class
 
    int nvalues = 0;
@@ -464,7 +482,7 @@ open the file, and will call the :cpp:class:`LAMMPS_NS::Error` class in
 case of failures to read or to convert numbers, so that LAMMPS will be
 aborted.
 
-.. code-block:: C++
+.. code-block:: c++
    :caption: Use of PotentialFileReader class in pair style coul/streitz
 
     PotentialFileReader reader(lmp, file, "coul/streitz");
@@ -543,7 +561,7 @@ chunk size needs to be known in advance, 2) with :cpp:func:`MyPage::vget()
 its size is registered later with :cpp:func:`MyPage::vgot()
 <LAMMPS_NS::MyPage::vgot>`.
 
-.. code-block:: C++
+.. code-block:: c++
    :caption: Example of using :cpp:class:`MyPage <LAMMPS_NS::MyPage>`
 
       #include "my_page.h"

doc/src/Developer_write.rst

@@ -26,7 +26,7 @@ constructor with the signature: ``FixPrintVel(class LAMMPS *, int, char **)``.
 Every fix must be registered in LAMMPS by writing the following lines
 of code in the header before include guards:
 
-.. code-block:: c
+.. code-block:: c++
 
    #ifdef FIX_CLASS
    // clang-format off
@@ -47,7 +47,7 @@ keyword when it parses the input script.
 Let's write a simple fix which will print the average velocity at the end
 of each timestep. First of all, implement a constructor:
 
-.. code-block:: C++
+.. code-block:: c++
 
    FixPrintVel::FixPrintVel(LAMMPS *lmp, int narg, char **arg)
    : Fix(lmp, narg, arg)
@@ -72,7 +72,7 @@ in the Fix class called ``nevery`` which specifies how often the method
 
 The next method we need to implement is ``setmask()``:
 
-.. code-block:: C++
+.. code-block:: c++
 
    int FixPrintVel::setmask()
    {
@@ -87,7 +87,7 @@ during execution. The constant ``END_OF_STEP`` corresponds to the
 are called during a timestep and the order in which they are called
 are shown in the previous section.
 
-.. code-block:: C++
+.. code-block:: c++
 
    void FixPrintVel::end_of_step()
    {
@@ -143,7 +143,7 @@ The group membership information of an atom is contained in the *mask*
 property of and atom and the bit corresponding to a given group is
 stored in the groupbit variable which is defined in Fix base class:
 
-.. code-block:: C++
+.. code-block:: c++
 
    for (int i = 0; i < nlocal; ++i) {
      if (atom->mask[i] & groupbit) {
@@ -174,7 +174,7 @@ to store positions of atoms from previous timestep, we need to add
 ``double** xold`` to the header file. Than add allocation code
 to the constructor:
 
-.. code-block:: C++
+.. code-block:: c++
 
    FixSavePos::FixSavePos(LAMMPS *lmp, int narg, char **arg), xold(nullptr)
    {
@@ -190,7 +190,7 @@ to the constructor:
 
 Implement the aforementioned methods:
 
-.. code-block:: C++
+.. code-block:: c++
 
    double FixSavePos::memory_usage()
    {

doc/src/Errors_debug.rst

@@ -75,7 +75,7 @@ Using the GDB debugger to get a stack trace
 There are two options to use the GDB debugger for identifying the origin
 of the segmentation fault or similar crash. The GDB debugger has many
 more features and options, as can be seen for example its `online
-documentation <http://sourceware.org/gdb/current/onlinedocs/gdb/>`_.
+documentation <https://sourceware.org/gdb/current/onlinedocs/gdb/>`_.
 
 Run LAMMPS from within the debugger
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

doc/src/Errors_messages.rst

@@ -476,65 +476,6 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
 *Bonds defined but no bond types*
    The data file header lists bonds but no bond types.
 
-*Bond/react: Cannot use fix bond/react with non-molecular systems*
-   Only systems with bonds that can be changed can be used. Atom_style
-   template does not qualify.
-
-*Bond/react: Invalid template atom ID in map file*
-   Atom IDs in molecule templates range from 1 to the number of atoms in the template.
-
-*Bond/react: Rmax cutoff is longer than pairwise cutoff*
-   This is not allowed because bond creation is done using the pairwise
-   neighbor list.
-
-*Bond/react: Molecule template ID for fix bond/react does not exist*
-   A valid molecule template must have been created with the molecule
-   command.
-
-*Bond/react: Reaction templates must contain the same number of atoms*
-   There should be a one-to-one correspondence between atoms in the
-   pre-reacted and post-reacted templates, as specified by the map file.
-
-*Bond/react: Unknown section in map file*
-   Please ensure reaction map files are properly formatted.
-
-*Bond/react: Atom/Bond type affected by reaction too close to template edge*
-   This means an atom which changes type or connectivity during the
-   reaction is too close to an 'edge' atom defined in the map
-   file.  This could cause incorrect assignment of bonds, angle, etc.
-   Generally, this means you must include more atoms in your templates,
-   such that there are at least two atoms between each atom involved in
-   the reaction and an edge atom.
-
-*Bond/react: Fix bond/react needs ghost atoms from farther away*
-   This is because a processor needs to map the entire unreacted
-   molecule template onto simulation atoms it knows about. The
-   comm_modify cutoff command can be used to extend the communication
-   range.
-
-*Bond/react: A deleted atom cannot remain bonded to an atom that is not deleted*
-   Self-explanatory.
-
-*Bond/react: First neighbors of chiral atoms must be of mutually different types*
-   Self-explanatory.
-
-*Bond/react: Chiral atoms must have exactly four first neighbors*
-   Self-explanatory.
-
-*Bond/react: Molecule template 'Coords' section required for chiralIDs keyword*
-   The coordinates of atoms in the pre-reacted template are used to determine
-   chirality.
-
-*Bond/react special bond generation overflow*
-   The number of special bonds per-atom created by a reaction exceeds the
-   system setting. See the read_data or create_box command for how to
-   specify this value.
-
-*Bond/react topology/atom exceed system topology/atom*
-   The number of bonds, angles etc per-atom created by a reaction exceeds
-   the system setting. See the read_data or create_box command for how to
-   specify this value.
-
 *Both restart files must use % or neither*
    Self-explanatory.
 
@@ -1291,7 +1232,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
 *Cannot use chosen neighbor list style with lj/gromacs/kk*
    Self-explanatory.
 
-*Cannot use chosen neighbor list style with lj/sdk/kk*
+*Cannot use chosen neighbor list style with lj/spica/kk*
    That style is not supported by Kokkos.
 
 *Cannot use chosen neighbor list style with pair eam/kk*
@@ -1659,10 +1600,10 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
 *Cannot use newton pair with lj/gromacs/gpu pair style*
    Self-explanatory.
 
-*Cannot use newton pair with lj/sdk/coul/long/gpu pair style*
+*Cannot use newton pair with lj/spica/coul/long/gpu pair style*
    Self-explanatory.
 
-*Cannot use newton pair with lj/sdk/gpu pair style*
+*Cannot use newton pair with lj/spica/gpu pair style*
    Self-explanatory.
 
 *Cannot use newton pair with lj96/cut/gpu pair style*
@@ -3521,6 +3462,65 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
    acquire needed info, The comm_modify cutoff command can be used to
    extend the communication range.
 
+*Fix bond/react: Cannot use fix bond/react with non-molecular systems*
+   Only systems with bonds that can be changed can be used. Atom_style
+   template does not qualify.
+
+*Fix bond/react: Invalid template atom ID in map file*
+   Atom IDs in molecule templates range from 1 to the number of atoms in the template.
+
+*Fix bond/react: Rmax cutoff is longer than pairwise cutoff*
+   This is not allowed because bond creation is done using the pairwise
+   neighbor list.
+
+*Fix bond/react: Molecule template ID for fix bond/react does not exist*
+   A valid molecule template must have been created with the molecule
+   command.
+
+*Fix bond/react: Reaction templates must contain the same number of atoms*
+   There should be a one-to-one correspondence between atoms in the
+   pre-reacted and post-reacted templates, as specified by the map file.
+
+*Fix bond/react: Unknown section in map file*
+   Please ensure reaction map files are properly formatted.
+
+*Fix bond/react: Atom/Bond type affected by reaction too close to template edge*
+   This means an atom which changes type or connectivity during the
+   reaction is too close to an 'edge' atom defined in the map
+   file.  This could cause incorrect assignment of bonds, angle, etc.
+   Generally, this means you must include more atoms in your templates,
+   such that there are at least two atoms between each atom involved in
+   the reaction and an edge atom.
+
+*Fix bond/react: Fix bond/react needs ghost atoms from farther away*
+   This is because a processor needs to map the entire unreacted
+   molecule template onto simulation atoms it knows about. The
+   comm_modify cutoff command can be used to extend the communication
+   range.
+
+*Fix bond/react: A deleted atom cannot remain bonded to an atom that is not deleted*
+   Self-explanatory.
+
+*Fix bond/react: First neighbors of chiral atoms must be of mutually different types*
+   Self-explanatory.
+
+*Fix bond/react: Chiral atoms must have exactly four first neighbors*
+   Self-explanatory.
+
+*Fix bond/react: Molecule template 'Coords' section required for chiralIDs keyword*
+   The coordinates of atoms in the pre-reacted template are used to determine
+   chirality.
+
+*Fix bond/react special bond generation overflow*
+   The number of special bonds per-atom created by a reaction exceeds the
+   system setting. See the read_data or create_box command for how to
+   specify this value.
+
+*Fix bond/react topology/atom exceed system topology/atom*
+   The number of bonds, angles etc per-atom created by a reaction exceeds
+   the system setting. See the read_data or create_box command for how to
+   specify this value.
+
 *Fix bond/swap cannot use dihedral or improper styles*
    These styles cannot be defined when using this fix.
 
@@ -5453,6 +5453,11 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
    Mass command must set a type from 1-N where N is the number of atom
    types.
 
+*Invalid label2type() function syntax in variable formula*
+   The first argument must be a label map kind (atom, bond, angle,
+   dihedral, or improper) and the second argument must be a valid type
+   label that has been assigned to a numeric type.
+
 *Invalid use of library file() function*
    This function is called through the library interface.  This
    error should not occur.  Contact the developers if it does.
@@ -5585,9 +5590,18 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
 *LJ6 off not supported in pair_style buck/long/coul/long*
    Self-explanatory.
 
+*Label map is incomplete: all types must be assigned a unique type label*
+   For a given type-kind (atom types, bond types, etc.) to be written to
+   the data file, all associated types must be assigned a type label, and
+   each type label can be assigned to only one numeric type.
+
 *Label wasn't found in input script*
    Self-explanatory.
 
+*Labelmap command before simulation box is defined*
+   The labelmap command cannot be used before a read_data,
+   read_restart, or create_box command.
+
 *Lattice orient vectors are not orthogonal*
    The three specified lattice orientation vectors must be mutually
    orthogonal.
@@ -5863,6 +5877,12 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
 *Must not have multiple fixes change box parameter ...*
    Self-explanatory.
 
+*Must read Angle Type Labels before Angles*
+   An Angle Type Labels section of a data file must come before the Angles section.
+
+*Must read Atom Type Labels before Atoms*
+   An Atom Type Labels section of a data file must come before the Atoms section.
+
 *Must read Atoms before Angles*
    The Atoms section of a data file must come before an Angles section.
 
@@ -5893,6 +5913,15 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
    The Atoms section of a data file must come before a Velocities
    section.
 
+*Must read Bond Type Labels before Bonds*
+   A Bond Type Labels section of a data file must come before the Bonds section.
+
+*Must read Dihedral Type Labels before Dihedrals*
+   An Dihedral Type Labels section of a data file must come before the Dihedrals section.
+
+*Must read Improper Type Labels before Impropers*
+   An Improper Type Labels section of a data file must come before the Impropers section.
+
 *Must re-specify non-restarted pair style (xxx) after read_restart*
    For pair styles, that do not store their settings in a restart file,
    it must be defined with a new 'pair_style' command after read_restart.
@@ -6782,7 +6811,7 @@ keyword to allow for additional bonds to be formed
    This is because the computation of constraint forces within a water
    molecule adds forces to atoms owned by other processors.
 
-*Pair style lj/sdk/coul/long/gpu requires atom attribute q*
+*Pair style lj/spica/coul/long/gpu requires atom attribute q*
    The atom style defined does not have this attribute.
 
 *Pair style nb3b/harmonic requires atom IDs*
@@ -7849,6 +7878,10 @@ keyword to allow for additional bonds to be formed
    Number of local atoms times number of columns must fit in a 32-bit
    integer for dump.
 
+*Topology type exceeds system topology type*
+   The number of bond, angle, etc types exceeds the system setting. See
+   the create_box or read_data command for how to specify these values.
+
 *Tree structure in joint connections*
    Fix poems cannot (yet) work with coupled bodies whose joints connect
    the bodies in a tree structure.
@@ -7873,6 +7906,13 @@ keyword to allow for additional bonds to be formed
 *Two groups cannot be the same in fix spring couple*
    Self-explanatory.
 
+*The %s type label %s is already in use for type %s*
+   For a given type-kind (atom types, bond types, etc.), a given type
+   label can be assigned to only one numeric type.
+
+*Type label string %s for %s type %s is invalid*
+   See the labelmap command documentation for valid type labels.
+
 *Unable to initialize accelerator for use*
    There was a problem initializing an accelerator for the gpu package
 

doc/src/Errors_warnings.rst

@@ -68,14 +68,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
    length, multiplying by the number of bonds in the interaction (e.g. 3
    for a dihedral) and adding a small amount of stretch.
 
-*Bond/react: Atom affected by reaction too close to template edge*
-   This means an atom which changes type or connectivity during the
-   reaction is too close to an 'edge' atom defined in the superimpose
-   file. This could cause incorrect assignment of bonds, angle, etc.
-   Generally, this means you must include more atoms in your templates,
-   such that there are at least two atoms between each atom involved in
-   the reaction and an edge atom.
-
 *Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero*
    Self-explanatory.
 
@@ -206,12 +198,20 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 *Fix SRD walls overlap but fix srd overlap not set*
    You likely want to set this in your input script.
 
-* Fix bond/create is used multiple times or with fix bond/break - may not work as expected*
+*Fix bond/create is used multiple times or with fix bond/break - may not work as expected*
    When using fix bond/create multiple times or in combination with
    fix bond/break, the individual fix instances do not share information
    about changes they made at the same time step and thus it may result
    in unexpected behavior.
 
+*Fix bond/react: Atom affected by reaction too close to template edge*
+   This means an atom which changes type or connectivity during the
+   reaction is too close to an 'edge' atom defined in the superimpose
+   file. This could cause incorrect assignment of bonds, angle, etc.
+   Generally, this means you must include more atoms in your templates,
+   such that there are at least two atoms between each atom involved in
+   the reaction and an edge atom.
+
 *Fix bond/swap will ignore defined angles*
    See the page for fix bond/swap for more info on this
    restriction.
@@ -470,6 +470,12 @@ This will most likely cause errors in kinetic fluctuations.
 *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.
 
@@ -804,4 +810,3 @@ This will most likely cause errors in kinetic fluctuations.
 
 *Using pair tail corrections with pair_modify compute no*
    The tail corrections will thus not be computed.
-

doc/src/Howto.rst

@@ -34,6 +34,7 @@ Settings howto
    :maxdepth: 1
 
    Howto_2d
+   Howto_type_labels
    Howto_triclinic
    Howto_thermostat
    Howto_barostat
@@ -50,6 +51,7 @@ Analysis howto
 
    Howto_output
    Howto_chunk
+   Howto_grid
    Howto_temperature
    Howto_elastic
    Howto_kappa
@@ -65,6 +67,7 @@ Force fields howto
    :maxdepth: 1
 
    Howto_bioFF
+   Howto_amoeba
    Howto_tip3p
    Howto_tip4p
    Howto_spc
@@ -83,6 +86,7 @@ Packages howto
    Howto_coreshell
    Howto_drude
    Howto_drude2
+   Howto_peri
    Howto_manifold
    Howto_spins
 

doc/src/Howto_amoeba.rst

@@ -0,0 +1,324 @@
+AMOEBA and HIPPO force fields
+=============================
+
+The AMOEBA and HIPPO polarizable force fields were developed by Jay
+Ponder's group at the U Washington at St Louis.  The LAMMPS
+implementation is based on Fortran 90 code provided by the Ponder
+group in their `Tinker MD software <https://dasher.wustl.edu/tinker/>`_.
+
+The current implementation (July 2022) of AMOEBA in LAMMPS matches the
+version discussed in :ref:`(Ponder) <amoeba-Ponder>`, :ref:`(Ren)
+<amoeba-Ren>`, and :ref:`(Shi) <amoeba-Shi>`.  Likewise the current
+implementation of HIPPO in LAMMPS matches the version discussed in
+:ref:`(Rackers) <amoeba-Rackers>`.
+
+These force fields can be used when polarization effects are desired
+in simulations of water, organic molecules, and biomolecules including
+proteins, provided that parameterizations (Tinker PRM force field
+files) are available for the systems you are interested in.  Files in
+the LAMMPS potentials directory with a "amoeba" or "hippo" suffix can
+be used.  The Tinker distribution and website have additional force
+field files as well:
+`https://github.com/TinkerTools/tinker/tree/release/params
+<https://github.com/TinkerTools/tinker/tree/release/params>`_.
+
+Note that currently, HIPPO can only be used for water systems, but
+HIPPO files for a variety of small organic and biomolecules are in
+preparation by the Ponder group.  Those force field files will be
+included in the LAMMPS distribution when available.
+
+To use the AMOEBA or HIPPO force fields, a simulation must be 3d, and
+fully periodic or fully non-periodic, and use an orthogonal (not
+triclinic) simulation box.
+
+----------
+
+The AMOEBA and HIPPO force fields contain the following terms in their
+energy (U) computation.  Further details for AMOEBA equations are in
+:ref:`(Ponder) <amoeba-Ponder>`, further details for the HIPPO
+equations are in :ref:`(Rackers) <amoeba-Rackers>`.
+
+.. math::
+
+  U & = U_{intermolecular} + U_{intramolecular} \\
+  U_{intermolecular} & = U_{hal} + U_{repulsion} + U_{dispersion} + U_{multipole} + U_{polar} + U_{qxfer} \\
+  U_{intramolecular} & = U_{bond} + U_{angle} + U_{torsion} + U_{oop} + U_{b\theta} + U_{UB} + U_{pitorsion} + U_{bitorsion}
+
+For intermolecular terms, the AMOEBA force field includes only the
+:math:`U_{hal}`, :math:`U_{multipole}`, :math:`U_{polar}` terms.  The
+HIPPO force field includes all but the :math:`U_{hal}` term.  In
+LAMMPS, these are all computed by the :doc:`pair_style amoeba or hippo
+<pair_style>` command.  Note that the :math:`U_{multipole}` and
+:math:`U_{polar}` terms in this formula are not the same for the
+AMOEBA and HIPPO force fields.
+
+For intramolecular terms, the :math:`U_{bond}`, :math:`U_{angle}`,
+:math:`U_{torsion}`, :math:`U_{oop}` terms are computed by the
+:doc:`bond_style class2 <bond_class2>` :doc:`angle_style amoeba
+<angle_amoeba>`, :doc:`dihedral_style fourier <dihedral_fourier>`, and
+:doc:`improper_style amoeba <improper_amoeba>` commands respectively.
+The :doc:`angle_style amoeba <angle_amoeba>` command includes the
+:math:`U_{b\theta}` bond-angle cross term, and the :math:`U_{UB}` term
+for a Urey-Bradley bond contribution between the I,K atoms in the IJK
+angle.
+
+The :math:`U_{pitorsion}` term is computed by the :doc:`fix
+amoeba/pitorsion <fix_amoeba_pitorsion>` command.  It computes 6-body
+interaction between a pair of bonded atoms which each have 2
+additional bond partners.
+
+The :math:`U_{bitorsion}` term is computed by the :doc:`fix
+amoeba/bitorsion <fix_amoeba_bitorsion>` command.  It computes 5-body
+interaction between two 4-body torsions (dihedrals) which overlap,
+having 3 atoms in common.
+
+These command doc pages have additional details on the terms they
+compute:
+
+* :doc:`pair_style amoeba or hippo <pair_amoeba>`
+* :doc:`bond_style class2 <bond_class2>`
+* :doc:`angle_style amoeba <angle_amoeba>`
+* :doc:`dihedral_style fourier <dihedral_fourier>`
+* :doc:`improper_style amoeba <improper_amoeba>`
+* :doc:`fix amoeba/pitorsion <fix_amoeba_pitorsion>`
+* :doc:`fix amoeba/bitorsion <fix_amoeba_bitorsion>`
+
+----------
+
+To use the AMOEBA or HIPPO force fields in LAMMPS, use commands like
+the following appropriately in your input script.  The only change
+needed for AMOEBA vs HIPPO simulation is for the :doc:`pair_style
+<pair_style>` and :doc:`pair_coeff <pair_coeff>` commands, as shown
+below.  See examples/amoeba for example input scripts for both AMOEBA
+and HIPPO.
+
+.. code-block:: LAMMPS
+
+   units              real                           # required
+   atom_style         amoeba
+   bond_style         class2                         # CLASS2 package
+   angle_style        amoeba
+   dihedral_style     fourier                        # EXTRA-MOLECULE package
+   improper_style     amoeba
+                                                     # required per-atom data
+   fix                amtype all property/atom i_amtype ghost yes
+   fix                extra all property/atom &
+                      i_amgroup i_ired i_xaxis i_yaxis i_zaxis d_pval ghost yes
+   fix                polaxe all property/atom i_polaxe
+
+   fix                pit all amoeba/pitorsion       # PiTorsion terms in FF
+   fix_modify         pit energy yes
+                                                     # Bitorsion terms in FF
+   fix                bit all amoeba/bitorsion bitorsion.ubiquitin.data
+   fix_modify         bit energy yes
+
+   read_data          data.ubiquitin fix amtype NULL "Tinker Types" &
+                      fix pit "pitorsion types" "PiTorsion Coeffs" &
+                      fix pit pitorsions PiTorsions &
+                      fix bit bitorsions BiTorsions
+
+   pair_style         amoeba                          # AMOEBA FF
+   pair_coeff         * * amoeba_ubiquitin.prm amoeba_ubiquitin.key
+
+   pair_style         hippo                           # HIPPO FF
+   pair_coeff         * * hippo_water.prm hippo_water.key
+
+   special_bonds      lj/coul 0.5 0.5 0.5 one/five yes     # 1-5 neighbors
+
+The data file read by the :doc:`read_data <read_data>` command should
+be created by the tools/tinker/tinker2lmp.py conversion program
+described below.  It will create a section in the data file with the
+header "Tinker Types".  A :doc:`fix property/atom <fix_property_atom>`
+command for the data must be specified before the read_data command.
+In the example above the fix ID is *amtype*.
+
+Similarly, if the system you are simulating defines AMOEBA/HIPPO
+pitorsion or bitorsion interactions, there will be entries in the data
+file for those interactions.  They require a :doc:`fix
+amoeba/pitortion <fix_amoeba_pitorsion>` and :doc:`fix
+amoeba/bitorsion <fix_amoeba_bitorsion>` command be defined.  In the
+example above, the IDs for these two fixes are *pit* and *bit*.
+
+Of course, if the system being modeled does not have one or more of
+the following -- bond, angle, dihedral, improper, pitorsion,
+bitorsion interactions -- then the corresponding style and fix
+commands above do not need to be used.  See the example scripts in
+examples/amoeba for water systems as examples; they are simpler than
+what is listed above.
+
+The two :doc:`fix property/atom <fix_property_atom>` commands with IDs
+(in the example above) *extra* and *polaxe* are also needed to define
+internal per-atom quantities used by the AMOEBA and HIPPO force
+fields.
+
+The :doc:`pair_coeff <pair_coeff>` command used for either the AMOEBA
+or HIPPO force field takes two arguments for Tinker force field files,
+namely a PRM and KEY file.  The keyfile can be specified as NULL and
+default values for a various settings will be used.  Note that these 2
+files are meant to allow use of native Tinker files as-is.  However
+LAMMPS does not support all the options which can be included
+in a Tinker PRM or KEY file.  See specifics below.
+
+A :doc:`special_bonds <special_bonds>` command with the *one/five*
+option is required, since the AMOEBA/HIPPO force fields define
+weighting factors for not only 1-2, 1-3, 1-4 interactions, but also
+1-5 interactions.  This command will trigger a per-atom list of 1-5
+neighbors to be generated.  The AMOEBA and HIPPO force fields define
+their own custom weighting factors for all the 1-2, 1-3, 1-4, 1-5
+terms which in the Tinker PRM and KEY files; they can be different for
+different terms in the force field.
+
+In addition to the list above, these command doc pages have additional
+details:
+
+* :doc:`atom_style amoeba <atom_style>`
+* :doc:`fix property/atom <fix_property_atom>`
+* :doc:`special_bonds <special_bonds>`
+
+----------
+
+Tinker PRM and KEY files
+
+A Tinker PRM file is composed of sections, each of which has multiple
+lines.  This is the list of PRM sections LAMMPS knows how to parse and
+use.  Any other sections are skipped:
+
+* Angle Bending Parameters
+* Atom Type Definitions
+* Atomic Multipole Parameters
+* Bond Stretching Parameters
+* Charge Penetration Parameters
+* Charge Transfer Parameters
+* Dipole Polarizability Parameters
+* Dispersion Parameters
+* Force Field Definition
+* Literature References
+* Out-of-Plane Bend Parameters
+* Pauli Repulsion Parameters
+* Pi-Torsion Parameters
+* Stretch-Bend Parameters
+* Torsion-Torsion Parameters
+* Torsional Parameters
+* Urey-Bradley Parameters
+* Van der Waals Pair Parameters
+* Van der Waals Parameters
+
+A Tinker KEY file is composed of lines, each of which has a keyword
+followed by zero or more parameters.  This is the list of keywords
+LAMMPS knows how to parse and use in the same manner Tinker does.  Any
+other keywords are skipped.  The value in parenthesis is the default
+value for the keyword if it is not specified, or if the keyfile in the
+:doc:`pair_coeff <pair_coeff>` command is specified as NULL:
+
+* a-axis (0.0)
+* b-axis (0.0)
+* c-axis (0.0)
+* ctrn-cutoff (6.0)
+* ctrn-taper (0.9 * ctrn-cutoff)
+* cutoff
+* delta-halgren (0.07)
+* dewald (no long-range dispersion unless specified)
+* dewald-alpha (0.4)
+* dewald-cutoff (7.0)
+* dispersion-cutoff (9.0)
+* dispersion-taper (9.0 * dispersion-cutoff)
+* dpme-grid
+* dpme-order (4)
+* ewald (no long-range electrostatics unless specified)
+* ewald-alpha (0.4)
+* ewald-cutoff (7.0)
+* gamma-halgren (0.12)
+* mpole-cutoff (9.0)
+* mpole-taper (0.65 * mpole-cutoff)
+* pcg-guess (enabled by default)
+* pcg-noguess (disable pcg-guess if specified)
+* pcg-noprecond (disable pcg-precond if specified)
+* pcg-peek (1.0)
+* pcg-precond (enabled by default)
+* pewald-alpha (0.4)
+* pme-grid
+* pme-order (5)
+* polar-eps (1.0e-6)
+* polar-iter (100)
+* polar-predict (no prediction operation unless specified)
+* ppme-order (5)
+* repulsion-cutoff (6.0)
+* repulsion-taper (0.9 * repulsion-cutoff)
+* taper
+* usolve-cutoff (4.5)
+* usolve-diag (2.0)
+* vdw-cutoff (9.0)
+* vdw-taper (0.9 * vdw-cutoff)
+
+----------
+
+Tinker2lmp.py tool
+
+This conversion tool is found in the tools/tinker directory.
+As shown in examples/amoeba/README, these commands produce
+the data files found in examples/amoeba, and also illustrate
+all the options available to use with the tinker2lmp.py script:
+
+.. code-block:: bash
+
+   % python tinker2lmp.py -xyz water_dimer.xyz -amoeba amoeba_water.prm -data data.water_dimer.amoeba                # AMOEBA non-periodic system
+   % python tinker2lmp.py -xyz water_dimer.xyz -hippo hippo_water.prm -data data.water_dimer.hippo                   # HIPPO non-periodic system
+   % python tinker2lmp.py -xyz water_box.xyz -amoeba amoeba_water.prm -data data.water_box.amoeba -pbc 18.643 18.643 18.643    # AMOEBA periodic system
+   % python tinker2lmp.py -xyz water_box.xyz -hippo hippo_water.prm -data data.water_box.hippo -pbc 18.643 18.643 18.643       # HIPPO periodic system
+   % python tinker2lmp.py -xyz ubiquitin.xyz -amoeba amoeba_ubiquitin.prm -data data.ubiquitin.new -pbc 54.99 41.91 41.91 -bitorsion bitorsion.ubiquitin.data.new   # system with bitorsions
+
+Switches and their arguments may be specified in any order.
+
+The -xyz switch is required and specifies an input XYZ file as an
+argument.  The format of this file is an extended XYZ format defined
+and used by Tinker for its input.  Example \*.xyz files are in the
+examples/amoeba directory.  The file lists the atoms in the system.
+Each atom has the following information: Tinker species name (ignored
+by LAMMPS), xyz coordinates, Tinker numeric type, and a list of atom
+IDs the atom is bonded to.
+
+Here is more information about the extended XYZ format defined and
+used by Tinker, and links to programs that convert standard PDB files
+to the extended XYZ format:
+
+* `https://openbabel.org/docs/current/FileFormats/Tinker_XYZ_format.html <https://openbabel.org/docs/current/FileFormats/Tinker_XYZ_format.html>`_
+* `https://github.com/emleddin/pdbxyz-xyzpdb <https://github.com/emleddin/pdbxyz-xyzpdb>`_
+* `https://github.com/TinkerTools/tinker/blob/release/source/pdbxyz.f <https://github.com/TinkerTools/tinker/blob/release/source/pdbxyz.f>`_
+
+The -amoeba or -hippo switch is required.  It specifies an input
+AMOEBA or HIPPO PRM force field file as an argument.  This should be
+the same file used by the :doc:`pair_style <pair_style>` command in
+the input script.
+
+The -data switch is required.  It specifies an output file name for
+the LAMMPS data file that will be produced.
+
+For periodic systems, the -pbc switch is required.  It specifies the
+periodic box size for each dimension (x,y,z).  For a Tinker simulation
+these are specified in the KEY file.
+
+The -bitorsion switch is only needed if the system contains Tinker
+bitorsion interactions.  The data for each type of bitorsion
+interaction will be written to the specified file, and read by the
+:doc:`fix amoeba/bitorsion <fix_amoeba_bitorsion>` command.  The data
+includes 2d arrays of values to which splines are fit, and thus is not
+compatible with the LAMMPS data file format.
+
+----------
+
+.. _howto-Ponder:
+
+**(Ponder)** Ponder, Wu, Ren, Pande, Chodera, Schnieders, Haque,  Mobley, Lambrecht, DiStasio Jr, M. Head-Gordon, Clark,  Johnson, T. Head-Gordon, J Phys Chem B, 114, 2549-2564 (2010).
+
+.. _howto-Rackers:
+
+**(Rackers)** Rackers, Silva, Wang, Ponder, J Chem Theory Comput, 17, 7056-7084 (2021).
+
+.. _howto-Ren:
+
+**(Ren)** Ren and Ponder, J Phys Chem B, 107, 5933 (2003).
+
+.. _howto-Shi:
+
+**(Shi)** Shi, Xia, Zhang, Best, Wu, Ponder, Ren, J Chem Theory Comp, 9, 4046, 2013.
+

doc/src/Howto_bioFF.rst

@@ -3,24 +3,20 @@ CHARMM, AMBER, COMPASS, and DREIDING force fields
 
 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
+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.
+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.
 
-See :ref:`(MacKerell) <howto-MacKerell>` for a description of the CHARMM force
-field.  See :ref:`(Cornell) <howto-Cornell>` for a description of the AMBER
-force field.  See :ref:`(Sun) <howto-Sun>` for a description of the COMPASS
-force field.
-
-.. _charmm: http://www.scripps.edu/brooks
-
-.. _amber: http://amber.scripps.edu
+See :ref:`(MacKerell) <howto-MacKerell>` for a description of the CHARMM
+force field.  See :ref:`(Cornell) <howto-Cornell>` for a description of
+the AMBER force field.  See :ref:`(Sun) <howto-Sun>` for a description
+of the COMPASS force field.
 
 The interaction styles listed below compute force field formulas that
 are consistent with common options in CHARMM or AMBER.  See each
@@ -41,9 +37,10 @@ command's documentation for the formula it computes.
 
 .. note::
 
-   For CHARMM, newer *charmmfsw* or *charmmfsh* styles were released
-   in March 2017.  We recommend they be used instead of the older *charmm*
-   styles.  See discussion of the differences on the :doc:`pair charmm <pair_charmm>` and :doc:`dihedral charmm <dihedral_charmm>` doc
+   For CHARMM, newer *charmmfsw* or *charmmfsh* styles were released in
+   March 2017.  We recommend they be used instead of the older *charmm*
+   styles.  See discussion of the differences on the :doc:`pair charmm
+   <pair_charmm>` and :doc:`dihedral charmm <dihedral_charmm>` doc
    pages.
 
 COMPASS is a general force field for atomistic simulation of common

doc/src/Howto_bpm.rst

@@ -33,46 +33,6 @@ reference state of a bond. Bonds that are created midway into a run,
 such as those created by pouring grains using :doc:`fix pour
 <fix_pour>`, are initialized on that timestep.
 
-As bonds can be broken between neighbor list builds, the
-:doc:`special_bonds <special_bonds>` command works differently for BPM
-bond styles. There are two possible settings which determine how pair
-interactions work between bonded particles.  First, one can turn off
-all pair interactions between bonded particles.  Unlike :doc:`bond
-quartic <bond_quartic>`, this is not done by subtracting pair forces
-during the bond computation but rather by dynamically updating the
-special bond list. This is the default behavior of BPM bond styles and
-is done by updating the 1-2 special bond list as bonds break.  To do
-this, LAMMPS requires :doc:`newton <newton>` bond off such that all
-processors containing an atom know when a bond breaks. Additionally,
-one must do either (A) or (B).
-
-A) Use the following special bond settings
-
-   .. code-block:: LAMMPS
-
-      special_bonds lj 0 1 1 coul 1 1 1
-
-   These settings accomplish two goals. First, they turn off 1-3 and 1-4
-   special bond lists, which are not currently supported for BPMs. As
-   BPMs often have dense bond networks, generating 1-3 and 1-4 special
-   bond lists is expensive.  By setting the lj weight for 1-2 bonds to
-   zero, this turns off pairwise interactions.  Even though there are no
-   charges in BPM models, setting a nonzero coul weight for 1-2 bonds
-   ensures all bonded neighbors are still included in the neighbor list
-   in case bonds break between neighbor list builds.
-
-B) Alternatively, one can simply overlay pair interactions such that all
-   bonded particles also feel pair interactions. This can be
-   accomplished by using the *overlay/pair* keyword present in all bpm
-   bond styles and by using the following special bond settings
-
-   .. code-block:: LAMMPS
-
-      special_bonds lj/coul 1 1 1
-
-See the :doc:`Howto <Howto_broken_bonds>` page on broken bonds for
-more information.
-
 ----------
 
 Currently there are two types of bonds included in the BPM
@@ -91,12 +51,6 @@ This also requires a unique integrator :doc:`fix nve/bpm/sphere
 <fix_nve_bpm_sphere>` which numerically integrates orientation similar
 to :doc:`fix nve/asphere <fix_nve_asphere>`.
 
-To monitor the fracture of bonds in the system, all BPM bond styles
-have the ability to record instances of bond breakage to output using
-the :doc:`dump local <dump>` command. Additionally, one can use
-:doc:`compute nbond/atom <compute_nbond_atom>` to tally the current
-number of bonds per atom.
-
 In addition to bond styles, a new pair style :doc:`pair bpm/spring
 <pair_bpm_spring>` was added to accompany the bpm/spring bond
 style. This pair style is simply a hookean repulsion with similar
@@ -104,6 +58,73 @@ velocity damping as its sister bond style.
 
 ----------
 
+Bond data can be output using a combination of standard LAMMPS commands.
+A list of IDs for bonded atoms can be generated using the
+:doc:`compute property/local <compute_property_local>` command.
+Various properties of bonds can be computed using the
+:doc:`compute bond/local <compute_bond_local>` command. This
+command allows one to access data saved to the bond's history
+such as the reference length of the bond. More information on
+bond history data can be found on the documentation pages for the specific
+BPM bond styles. Finally, this data can be output using a :doc:`dump local <dump>`
+command. As one may output many columns from the same compute, the
+:doc:`dump modify <dump_modify>` *colname* option may be used to provide
+more helpful column names. An example of this procedure is found in
+/examples/bpm/pour/. External software, such as OVITO, can read these dump
+files to render bond data.
+
+----------
+
+As bonds can be broken between neighbor list builds, the
+:doc:`special_bonds <special_bonds>` command works differently for BPM
+bond styles. There are two possible settings which determine how pair
+interactions work between bonded particles.  First, one can overlay
+pair forces with bond forces such that all bonded particles also
+feel pair interactions. This can be accomplished by using the *overlay/pair*
+keyword present in all bpm bond styles and by using the following special
+bond settings
+
+   .. code-block:: LAMMPS
+
+      special_bonds lj/coul 1 1 1
+
+Alternatively, one can turn off all pair interactions between bonded
+particles. Unlike :doc:`bond quartic <bond_quartic>`, this is not done
+by subtracting pair forces during the bond computation but rather by
+dynamically updating the special bond list. This is the default behavior
+of BPM bond styles and is done by updating the 1-2 special bond list as
+bonds break.  To do this, LAMMPS requires :doc:`newton <newton>` bond off
+such that all processors containing an atom know when a bond breaks.
+Additionally, one must use the following special bond settings
+
+   .. code-block:: LAMMPS
+
+      special_bonds lj 0 1 1 coul 1 1 1
+
+These settings accomplish two goals. First, they turn off 1-3 and 1-4
+special bond lists, which are not currently supported for BPMs. As
+BPMs often have dense bond networks, generating 1-3 and 1-4 special
+bond lists is expensive.  By setting the lj weight for 1-2 bonds to
+zero, this turns off pairwise interactions.  Even though there are no
+charges in BPM models, setting a nonzero coul weight for 1-2 bonds
+ensures all bonded neighbors are still included in the neighbor list
+in case bonds break between neighbor list builds.
+
+To monitor the fracture of bonds in the system, all BPM bond styles
+have the ability to record instances of bond breakage to output using
+the :doc:`dump local <dump>` command. Since one may frequently output
+a list of broken bonds and the time they broke, the
+:doc:`dump modify <dump_modify>` option *header no* may be useful to
+avoid repeatedly printing the header of the dump file. An example of
+this procedure is found in /examples/bpm/impact/. Additionally,
+one can use :doc:`compute nbond/atom <compute_nbond_atom>` to tally the
+current number of bonds per atom.
+
+See the :doc:`Howto <Howto_broken_bonds>` page on broken bonds for
+more information.
+
+----------
+
 While LAMMPS has many utilities to create and delete bonds, *only*
 the following are currently compatible with BPM bond styles:
 

doc/src/Howto_github.rst

@@ -10,7 +10,7 @@ changes or additions you have made to LAMMPS into the official LAMMPS
 distribution.  It uses the process of updating this very tutorial as an
 example to describe the individual steps and options.  You need to be
 familiar with git and you may want to have a look at the `git book
-<http://git-scm.com/book/>`_ to familiarize yourself with some of the
+<https://git-scm.com/book/>`_ to familiarize yourself with some of the
 more advanced git features used below.
 
 As of fall 2016, submitting contributions to LAMMPS via pull requests

doc/src/Howto_grid.rst

@@ -0,0 +1,102 @@
+Using distributed grids
+=======================
+
+.. versionadded:: 22Dec2022
+
+LAMMPS has internal capabilities to create uniformly spaced grids
+which overlay the simulation domain.  For 2d and 3d simulations these
+are 2d and 3d grids respectively.  Conceptually a grid can be thought
+of as a collection of grid cells.  Each grid cell can store one or
+more values (data).
+
+The grid cells and data they store are distributed across processors.
+Each processor owns the grid cells (and data) whose center points lie
+within the spatial sub-domain of the processor.  If needed for its
+computations, a processor may also store ghost grid cells with their
+data.
+
+Distributed grids can overlay orthogonal or triclinic simulation
+boxes; see the :doc:`Howto triclinic <Howto_triclinic>` doc page for
+an explanation of the latter.  For a triclinic box, the grid cell
+shape conforms to the shape of the simulation domain,
+e.g. parallelograms instead of rectangles in 2d.
+
+If the box size or shape changes during a simulation, the grid changes
+with it, so that it always overlays the entire simulation domain.  For
+non-periodic dimensions, the grid size in that dimension matches the
+box size, as set by the :doc:`boundary <boundary>` command for fixed
+or shrink-wrapped boundaries.
+
+If load-balancing is invoked by the :doc:`balance <balance>` or
+:doc:`fix balance <fix_balance>` commands, then the sub-domain owned
+by a processor can change which may also change which grid cells they
+own.
+
+Post-processing and visualization of grid cell data can be enabled by
+the :doc:`dump grid <dump>`, :doc:`dump grid/vtk <dump>`, and
+:doc:`dump image <dump_image>` commands.  The latter has an optional
+*grid* keyword.  The `OVITO visualization tool
+<https://www.ovito.org>`_ also plans (as of Nov 2022) to add support
+for visualizing grid cell data (along with atoms) using :doc:`dump
+grid <dump>` output files as input.
+
+.. note::
+
+   For developers, distributed grids are implemented within the code via
+   two classes: Grid2d and Grid3d.  These partition the grid across
+   processors and have methods which allow forward and reverse
+   communication of ghost grid data as well as load balancing.  If you
+   write a new compute or fix which needs a distributed grid, these are
+   the classes to look at.  A new pair style could use a distributed
+   grid by having a fix define it.  Please see the section on
+   :doc:`using distributed grids within style classes <Developer_grid>`
+   for a detailed description.
+
+----------
+
+These are the commands which currently define or use distributed
+grids:
+
+* :doc:`fix ttm/grid <fix_ttm>` - store electron temperature on grid
+* :doc:`fix ave/grid <fix_ave_grid>` - time average per-atom or per-grid values
+* :doc:`compute property/grid <compute_property_grid>` - generate grid IDs and coords
+* :doc:`dump grid <dump>` - output per-grid values in LAMMPS format
+* :doc:`dump grid/vtk <dump>` - output per-grid values in VTK format
+* :doc:`dump image grid <dump_image>` - include colored grid in output images
+* :doc:`pair_style amoeba <pair_amoeba>` - FFT grids
+* :doc:`kspace_style pppm <kspace_style>` (and variants) - FFT grids
+* :doc:`kspace_style msm <kspace_style>` (and variants) - MSM grids
+
+The grids used by the :doc:`kspace_style <kspace_style>` can not be
+referenced by an input script.  However the grids and data created and
+used by the other commands can be.
+
+A compute or fix command may create one or more grids (of different
+sizes).  Each grid can store one or more data fields.  A data field
+can be a single value per grid point (per-grid vector) or multiple
+values per grid point (per-grid array).  See the :doc:`Howto output
+<Howto_output>` doc page for an explanation of how per-grid data can
+be generated by some commands and used by other commands.
+
+A command accesses grid data from a compute or fix using a *grid
+reference* with the following syntax:
+
+* c_ID:gname:dname
+* c_ID:gname:dname[I]
+* f_ID:gname:dname
+* f_ID:gname:dname[I]
+
+The prefix "c\_" or "f\_" refers to the ID of the compute or fix; gname is
+the name of the grid, which is assigned by the compute or fix; dname is
+the name of the data field, which is also assigned by the compute or
+fix.
+
+If the data field is a per-grid vector (one value per grid point),
+then no brackets are used to access the values.  If the data field is
+a per-grid array (multiple values per grid point), then brackets are
+used to specify the column I of the array.  I ranges from 1 to Ncol
+inclusive, where Ncol is the number of columns in the array and is
+defined by the compute or fix.
+
+Currently, there are no per-grid variables implemented in LAMMPS.  We
+may add this feature at some point.

doc/src/Howto_manifold.rst

@@ -47,4 +47,4 @@ to the relevant fixes.
 .. _Paquay1:
 
 **(Paquay)** Paquay and Kusters, Biophys. J., 110, 6, (2016).
-preprint available at `arXiv:1411.3019 <http://arxiv.org/abs/1411.3019/>`_.
+preprint available at `arXiv:1411.3019 <https://arxiv.org/abs/1411.3019/>`_.

doc/src/Howto_mdi.rst

@@ -5,9 +5,9 @@ Client/server coupling of two (or more) codes is where one code is the
 "client" and sends request messages (data) to one (or more) "server"
 code(s).  A server responds to each request with a reply message
 (data).  This enables two (or more) codes to work in tandem to perform
-a simulation.  LAMMPS can act as either a client or server code; it
-does this by using the `MolSSI Driver Interface (MDI) library
-<https://molssi-mdi.github.io/MDI_Library/html/index.html>`_,
+a simulation.  In this context, LAMMPS can act as either a client or
+server code.  It does this by using the `MolSSI Driver Interface (MDI)
+library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_,
 developed by the `Molecular Sciences Software Institute (MolSSI)
 <https://molssi.org>`_, which is supported by the :ref:`MDI <PKG-MDI>`
 package.
@@ -63,22 +63,39 @@ The package also provides a :doc:`mdi plugin <mdi>` command which
 enables LAMMPS to operate as an MDI driver and load an MDI engine as a
 plugin library.
 
-The package also has a `fix mdi/aimd <fix_mdi_aimd>` command in which
-LAMMPS operates as an MDI driver to perform *ab initio* MD simulations
-in conjunction with a quantum mechanics code.  Its post_force() method
-illustrates how a driver issues MDI commands to another code.  This
-command can be used to couple to an MDI engine which is either a
-stand-alone code or a plugin library.
+The package also has a `fix mdi/qm <fix_mdi_qm>` command in which
+LAMMPS operates as an MDI driver in conjunction with a quantum
+mechanics code as an MDI engine.  The post_force() method of the
+fix_mdi_qm.cpp file shows how a driver issues MDI commands to another
+code.  This command can be used to couple to an MDI engine which is
+either a stand-alone code or a plugin library.
+
+As explained on the `fix mdi/qm <fix_mdi_qm>` command doc page, it can
+be used to perform *ab initio* MD simulations or energy minimizations,
+or to evaluate the quantum energy and forces for a series of
+independent systems.  The examples/mdi directory has example input
+scripts for all of these use cases.
 
 ----------
 
 The examples/mdi directory contains Python scripts and LAMMPS input
 script which use LAMMPS as either an MDI driver or engine or both.
-Three example use cases are provided:
+Currently, 5 example use cases are provided:
 
-* Run ab initio MD (AIMD) using 2 instances of LAMMPS, one as driver
-  and one as an engine.  As an engine, LAMMPS is a surrogate for a
-  quantum code.
+* Run ab initio MD (AIMD) using 2 instances of LAMMPS.  As a driver
+  LAMMPS performs the timestepping in either NVE or NPT mode.  As an
+  engine, LAMMPS computes forces and is a surrogate for a quantum
+  code.
+
+* As a driver, LAMMPS runs an MD simulation.  Every N steps it passes
+  the current snapshot to an MDI engine to evaluate the energy,
+  virial, and peratom forces.  As the engine LAMMPS is a surrogate for
+  a quantum code.
+
+* As a driver, LAMMPS loops over a series of data files and passes the
+  configuration to an MDI engine to evaluate the energy, virial, and
+  peratom forces.  As the engine LAMMPS is a surrogate for a quantum
+  code.
 
 * A Python script driver invokes a sequence of unrelated LAMMPS
   calculations.  Calculations can be single-point energy/force
@@ -91,20 +108,22 @@ Three example use cases are provided:
 
 Note that in any of these example where LAMMPS is used as an engine,
 an actual QM code (which supports MDI) could be used in its place,
-without modifying other code or scripts, except to specify the name of
-the QM code.
+without modifying the input scripts or launch commands, except to
+specify the name of the QM code.
 
-The examples/mdi/README file explains how to launch both driver and
+The examples/mdi/Run.sh file illustrates how to launch both driver and
 engine codes so that they communicate using the MDI library via either
-MPI or sockets.
+MPI or sockets.  Or using the engine as a stand-alone code or plugin
+library.
 
 -------------
 
-Currently there are two quantum DFT codes which have direct MDI
-support, `Quantum ESPRESSO (QE) <https://www.quantum-espresso.org/>`_
-and `INQ <https://qsg.llnl.gov/node/101.html>`_.  There are also
-several QM codes which have indirect support through QCEngine or i-PI.
-The former means they require a wrapper program (QCEngine) with MDI
+Currently there are at least two quantum DFT codes which have direct
+MDI support, `Quantum ESPRESSO (QE)
+<https://www.quantum-espresso.org/>`_ and `INQ
+<https://qsg.llnl.gov/node/101.html>`_.  There are also several QM
+codes which have indirect support through QCEngine or i-PI.  The
+former means they require a wrapper program (QCEngine) with MDI
 support which writes/read files to pass data to the quantum code
 itself.  The list of QCEngine-supported and i-PI-supported quantum
 codes is on the `MDI webpage

doc/src/Howto_output.rst

@@ -22,14 +22,17 @@ commands you specify.
 As discussed below, LAMMPS gives you a variety of ways to determine
 what quantities are computed and printed when the thermodynamics,
 dump, or fix commands listed above perform output.  Throughout this
-discussion, note that users can also :doc:`add their own computes and fixes to LAMMPS <Modify>` which can then generate values that can then be
-output with these commands.
+discussion, note that users can also :doc:`add their own computes and
+fixes to LAMMPS <Modify>` which can then generate values that can then
+be output with these commands.
 
-The following sub-sections discuss different LAMMPS command related
+The following sub-sections discuss different LAMMPS commands related
 to output and the kind of data they operate on and produce:
 
-* :ref:`Global/per-atom/local data <global>`
+* :ref:`Global/per-atom/local/per-grid data <global>`
 * :ref:`Scalar/vector/array data <scalar>`
+* :ref:`Per-grid data <grid>`
+* :ref:`Disambiguation <disambiguation>`
 * :ref:`Thermodynamic output <thermo>`
 * :ref:`Dump file output <dump>`
 * :ref:`Fixes that write output files <fixoutput>`
@@ -42,27 +45,32 @@ to output and the kind of data they operate on and produce:
 
 .. _global:
 
-Global/per-atom/local data
---------------------------
+Global/per-atom/local/per-grid data
+-----------------------------------
 
-Various output-related commands work with three different styles of
-data: global, per-atom, or local.  A global datum is one or more
-system-wide values, e.g. the temperature of the system.  A per-atom
-datum is one or more values per atom, e.g. the kinetic energy of each
-atom.  Local datums are calculated by each processor based on the
-atoms it owns, but there may be zero or more per atom, e.g. a list of
-bond distances.
+Various output-related commands work with four different styles of
+data: global, per-atom, local, and per-grid.  A global datum is one or
+more system-wide values, e.g. the temperature of the system.  A
+per-atom datum is one or more values per atom, e.g. the kinetic energy
+of each atom.  Local datums are calculated by each processor based on
+the atoms it owns, but there may be zero or more per atom, e.g. a list
+of bond distances.
+
+A per-grid datum is one or more values per grid cell, for a grid which
+overlays the simulation domain.  The grid cells and the data they
+store are distributed across processors; each processor owns the grid
+cells whose center point falls within its sub-domain.
 
 .. _scalar:
 
 Scalar/vector/array data
 ------------------------
 
-Global, per-atom, and local datums can each come in three kinds: a
-single scalar value, a vector of values, or a 2d array of values.  The
-doc page for a "compute" or "fix" or "variable" that generates data
-will specify both the style and kind of data it produces, e.g. a
-per-atom vector.
+Global, per-atom, and local datums can come in three kinds: a single
+scalar value, a vector of values, or a 2d array of values.  The doc
+page for a "compute" or "fix" or "variable" that generates data will
+specify both the style and kind of data it produces, e.g. a per-atom
+vector.
 
 When a quantity is accessed, as in many of the output commands
 discussed below, it can be referenced via the following bracket
@@ -83,6 +91,18 @@ the dimension twice (array -> scalar).  Thus a command that uses
 scalar values as input can typically also process elements of a vector
 or array.
 
+.. _grid:
+
+Per-grid data
+------------------------
+
+Per-grid data can come in two kinds: a vector of values (one per grid
+cekk), or a 2d array of values (multiple values per grid ckk).  The
+doc page for a "compute" or "fix" that generates data will specify
+names for both the grid(s) and datum(s) it produces, e.g. per-grid
+vectors or arrays, which can be referenced by other commands.  See the
+:doc:`Howto grid <Howto_grid>` doc page for more details.
+
 .. _disambiguation:
 
 Disambiguation
@@ -90,15 +110,15 @@ Disambiguation
 
 Some computes and fixes produce data in multiple styles, e.g. a global
 scalar and a per-atom vector. Usually the context in which the input
-script references the data determines which style is meant. Example: if
-a compute provides both a global scalar and a per-atom vector, the
+script references the data determines which style is meant. Example:
+if a compute provides both a global scalar and a per-atom vector, the
 former will be accessed by using ``c_ID`` in an equal-style variable,
 while the latter will be accessed by using ``c_ID`` in an atom-style
-variable.  Note that atom-style variable formulas can also access global
-scalars, but in this case it is not possible to do directly because of
-the ambiguity.  Instead, an equal-style variable can be defined which
-accesses the global scalar, and that variable used in the atom-style
-variable formula in place of ``c_ID``.
+variable.  Note that atom-style variable formulas can also access
+global scalars, but in this case it is not possible to do this
+directly because of the ambiguity.  Instead, an equal-style variable
+can be defined which accesses the global scalar, and that variable can
+be used in the atom-style variable formula in place of ``c_ID``.
 
 .. _thermo:
 
@@ -107,15 +127,14 @@ Thermodynamic output
 
 The frequency and format of thermodynamic output is set by the
 :doc:`thermo <thermo>`, :doc:`thermo_style <thermo_style>`, and
-:doc:`thermo_modify <thermo_modify>` commands.  The
-:doc:`thermo_style <thermo_style>` command also specifies what values
-are calculated and written out.  Pre-defined keywords can be specified
-(e.g. press, etotal, etc).  Three additional kinds of keywords can
-also be specified (c_ID, f_ID, v_name), where a :doc:`compute <compute>`
-or :doc:`fix <fix>` or :doc:`variable <variable>` provides the value to be
-output.  In each case, the compute, fix, or variable must generate
-global values for input to the :doc:`thermo_style custom <dump>`
-command.
+:doc:`thermo_modify <thermo_modify>` commands.  The :doc:`thermo_style
+<thermo_style>` command also specifies what values are calculated and
+written out.  Pre-defined keywords can be specified (e.g. press, etotal,
+etc).  Three additional kinds of keywords can also be specified (c_ID,
+f_ID, v_name), where a :doc:`compute <compute>` or :doc:`fix <fix>` or
+:doc:`variable <variable>` provides the value to be output.  In each
+case, the compute, fix, or variable must generate global values for
+input to the :doc:`thermo_style custom <dump>` command.
 
 Note that thermodynamic output values can be "extensive" or
 "intensive".  The former scale with the number of atoms in the system
@@ -141,9 +160,10 @@ There is also a :doc:`dump custom <dump>` format where the user
 specifies what values are output with each atom.  Pre-defined atom
 attributes can be specified (id, x, fx, etc).  Three additional kinds
 of keywords can also be specified (c_ID, f_ID, v_name), where a
-:doc:`compute <compute>` or :doc:`fix <fix>` or :doc:`variable <variable>`
-provides the values to be output.  In each case, the compute, fix, or
-variable must generate per-atom values for input to the :doc:`dump custom <dump>` command.
+:doc:`compute <compute>` or :doc:`fix <fix>` or :doc:`variable
+<variable>` provides the values to be output.  In each case, the
+compute, fix, or variable must generate per-atom values for input to
+the :doc:`dump custom <dump>` command.
 
 There is also a :doc:`dump local <dump>` format where the user specifies
 what local values to output.  A pre-defined index keyword can be
@@ -154,18 +174,23 @@ provides the values to be output.  In each case, the compute or fix
 must generate local values for input to the :doc:`dump local <dump>`
 command.
 
+There is also a :doc:`dump grid <dump>` format where the user
+specifies what per-grid values to output from computes or fixes that
+generate per-grid data.
+
 .. _fixoutput:
 
 Fixes that write output files
 -----------------------------
 
 Several fixes take various quantities as input and can write output
-files: :doc:`fix ave/time <fix_ave_time>`, :doc:`fix ave/chunk <fix_ave_chunk>`, :doc:`fix ave/histo <fix_ave_histo>`,
-:doc:`fix ave/correlate <fix_ave_correlate>`, and :doc:`fix print <fix_print>`.
+files: :doc:`fix ave/time <fix_ave_time>`, :doc:`fix ave/chunk
+<fix_ave_chunk>`, :doc:`fix ave/histo <fix_ave_histo>`, :doc:`fix
+ave/correlate <fix_ave_correlate>`, and :doc:`fix print <fix_print>`.
 
-The :doc:`fix ave/time <fix_ave_time>` command enables direct output to
-a file and/or time-averaging of global scalars or vectors.  The user
-specifies one or more quantities as input.  These can be global
+The :doc:`fix ave/time <fix_ave_time>` command enables direct output
+to a file and/or time-averaging of global scalars or vectors.  The
+user specifies one or more quantities as input.  These can be global
 :doc:`compute <compute>` values, global :doc:`fix <fix>` values, or
 :doc:`variables <variable>` of any style except the atom style which
 produces per-atom values.  Since a variable can refer to keywords used
@@ -184,8 +209,14 @@ atoms, e.g. individual molecules.  The per-atom quantities can be atom
 density (mass or number) or atom attributes such as position,
 velocity, force.  They can also be per-atom quantities calculated by a
 :doc:`compute <compute>`, by a :doc:`fix <fix>`, or by an atom-style
-:doc:`variable <variable>`.  The chunk-averaged output of this fix can
-also be used as input to other output commands.
+:doc:`variable <variable>`.  The chunk-averaged output of this fix is
+global and can also be used as input to other output commands.
+
+Note that the :doc:`fix ave/grid <fix_ave_grid>` command can also
+average the same per-atom quantities within spatial bins, but it does
+this for a distributed grid whose grid cells are owned by different
+processors.  It outputs per-grid data, not global data, so it is more
+efficient for large numbers of averaging bins.
 
 The :doc:`fix ave/histo <fix_ave_histo>` command enables direct output
 to a file of histogrammed quantities, which can be global or per-atom
@@ -202,38 +233,53 @@ written to the screen and log file or to a separate file, periodically
 during a running simulation.  The line can contain one or more
 :doc:`variable <variable>` values for any style variable except the
 vector or atom styles).  As explained above, variables themselves can
-contain references to global values generated by :doc:`thermodynamic keywords <thermo_style>`, :doc:`computes <compute>`,
-:doc:`fixes <fix>`, or other :doc:`variables <variable>`, or to per-atom
-values for a specific atom.  Thus the :doc:`fix print <fix_print>`
-command is a means to output a wide variety of quantities separate
-from normal thermodynamic or dump file output.
+contain references to global values generated by :doc:`thermodynamic
+keywords <thermo_style>`, :doc:`computes <compute>`, :doc:`fixes
+<fix>`, or other :doc:`variables <variable>`, or to per-atom values
+for a specific atom.  Thus the :doc:`fix print <fix_print>` command is
+a means to output a wide variety of quantities separate from normal
+thermodynamic or dump file output.
 
 .. _computeoutput:
 
 Computes that process output quantities
 ---------------------------------------
 
-The :doc:`compute reduce <compute_reduce>` and :doc:`compute reduce/region <compute_reduce>` commands take one or more per-atom
-or local vector quantities as inputs and "reduce" them (sum, min, max,
+The :doc:`compute reduce <compute_reduce>` and :doc:`compute
+reduce/region <compute_reduce>` commands take one or more per-atom or
+local vector quantities as inputs and "reduce" them (sum, min, max,
 ave) to scalar quantities.  These are produced as output values which
 can be used as input to other output commands.
 
-The :doc:`compute slice <compute_slice>` command take one or more global
-vector or array quantities as inputs and extracts a subset of their
-values to create a new vector or array.  These are produced as output
-values which can be used as input to other output commands.
+The :doc:`compute slice <compute_slice>` command take one or more
+global vector or array quantities as inputs and extracts a subset of
+their values to create a new vector or array.  These are produced as
+output values which can be used as input to other output commands.
 
-The :doc:`compute property/atom <compute_property_atom>` command takes a
-list of one or more pre-defined atom attributes (id, x, fx, etc) and
+The :doc:`compute property/atom <compute_property_atom>` command takes
+a list of one or more pre-defined atom attributes (id, x, fx, etc) and
 stores the values in a per-atom vector or array.  These are produced
 as output values which can be used as input to other output commands.
-The list of atom attributes is the same as for the :doc:`dump custom <dump>` command.
+The list of atom attributes is the same as for the :doc:`dump custom
+<dump>` command.
 
-The :doc:`compute property/local <compute_property_local>` command takes
-a list of one or more pre-defined local attributes (bond info, angle
-info, etc) and stores the values in a local vector or array.  These
-are produced as output values which can be used as input to other
-output commands.
+The :doc:`compute property/local <compute_property_local>` command
+takes a list of one or more pre-defined local attributes (bond info,
+angle info, etc) and stores the values in a local vector or array.
+These are produced as output values which can be used as input to
+other output commands.
+
+The :doc:`compute property/grid <compute_property_grid>` command takes
+a list of one or more pre-defined per-grid attributes (id, grid cell
+coords, etc) and stores the values in a per-grid vector or array.
+These are produced as output values which can be used as input to the
+:doc:`dump grid <dump>` command.
+
+The :doc:`compute property/chunk <compute_property_chunk>` command
+takes a list of one or more pre-defined chunk attributes (id, count,
+coords for spatial bins) and stores the values in a global vector or
+array.  These are produced as output values which can be used as input
+to other output commands.
 
 .. _fixprocoutput:
 
@@ -247,18 +293,42 @@ a time.
 The :doc:`fix ave/atom <fix_ave_atom>` command performs time-averaging
 of per-atom vectors.  The per-atom quantities can be atom attributes
 such as position, velocity, force.  They can also be per-atom
-quantities calculated by a :doc:`compute <compute>`, by a
-:doc:`fix <fix>`, or by an atom-style :doc:`variable <variable>`.  The
+quantities calculated by a :doc:`compute <compute>`, by a :doc:`fix
+<fix>`, or by an atom-style :doc:`variable <variable>`.  The
 time-averaged per-atom output of this fix can be used as input to
 other output commands.
 
-The :doc:`fix store/state <fix_store_state>` command can archive one or
-more per-atom attributes at a particular time, so that the old values
-can be used in a future calculation or output.  The list of atom
-attributes is the same as for the :doc:`dump custom <dump>` command,
-including per-atom quantities calculated by a :doc:`compute <compute>`,
-by a :doc:`fix <fix>`, or by an atom-style :doc:`variable <variable>`.
-The output of this fix can be used as input to other output commands.
+The :doc:`fix store/state <fix_store_state>` command can archive one
+or more per-atom attributes at a particular time, so that the old
+values can be used in a future calculation or output.  The list of
+atom attributes is the same as for the :doc:`dump custom <dump>`
+command, including per-atom quantities calculated by a :doc:`compute
+<compute>`, by a :doc:`fix <fix>`, or by an atom-style :doc:`variable
+<variable>`.  The output of this fix can be used as input to other
+output commands.
+
+The :doc:`fix ave/grid <fix_ave_grid>` command performs time-averaging
+of either per-atom or per-grid data.
+
+For per-atom data it performs averaging for the atoms within each grid
+cell, similar to the :doc:`fix ave/chunk <fix_ave_chunk>` command when
+its chunks are defined as regular 2d or 3d bins.  The per-atom
+quantities can be atom density (mass or number) or atom attributes
+such as position, velocity, force.  They can also be per-atom
+quantities calculated by a :doc:`compute <compute>`, by a :doc:`fix
+<fix>`, or by an atom-style :doc:`variable <variable>`.
+
+The chief difference between the :doc:`fix ave/grid <fix_ave_grid>`
+and :doc:`fix ave/chunk <fix_ave_chunk>` commands when used in this
+context is that the former uses a distributed grid, while the latter
+uses a global grid.  Distributed means that each processor owns the
+subset of grid cells within its sub-domain.  Global means that each
+processor owns a copy of the entire grid.  The :doc:`fix ave/grid
+<fix_ave_grid>` command is thus more efficient for large grids.
+
+For per-grid data, the :doc:`fix ave/grid <fix_ave_grid>` command
+takes inputs for grid data produced by other computes or fixes and
+averages the values for each grid point over time.
 
 .. _compute:
 
@@ -266,24 +336,25 @@ Computes that generate values to output
 ---------------------------------------
 
 Every :doc:`compute <compute>` in LAMMPS produces either global or
-per-atom or local values.  The values can be scalars or vectors or
-arrays of data.  These values can be output using the other commands
-described in this section.  The page for each compute command
+per-atom or local or per-grid values.  The values can be scalars or
+vectors or arrays of data.  These values can be output using the other
+commands described in this section.  The page for each compute command
 describes what it produces.  Computes that produce per-atom or local
-values have the word "atom" or "local" in their style name.  Computes
-without the word "atom" or "local" produce global values.
+or per-grid values have the word "atom" or "local" or "grid as the
+last word in their style name.  Computes without the word "atom" or
+"local" or "grid" produce global values.
 
 .. _fix:
 
 Fixes that generate values to output
 ------------------------------------
 
-Some :doc:`fixes <fix>` in LAMMPS produces either global or per-atom or
-local values which can be accessed by other commands.  The values can
-be scalars or vectors or arrays of data.  These values can be output
-using the other commands described in this section.  The page for
-each fix command tells whether it produces any output quantities and
-describes them.
+Some :doc:`fixes <fix>` in LAMMPS produces either global or per-atom
+or local or per-grid values which can be accessed by other commands.
+The values can be scalars or vectors or arrays of data.  These values
+can be output using the other commands described in this section.  The
+page for each fix command tells whether it produces any output
+quantities and describes them.
 
 .. _variable:
 
@@ -300,6 +371,8 @@ computes, fixes, and other variables.  The values generated by
 variables can be used as input to and thus output by the other
 commands described in this section.
 
+Per-grid variables have not (yet) been implemented.
+
 .. _table:
 
 Summary table of output options and data flow between commands
@@ -319,44 +392,52 @@ Also note that, as described above, when a command takes a scalar as
 input, that could be an element of a vector or array.  Likewise a
 vector input could be a column of an array.
 
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| Command                                                | Input                                        | Output                                    |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`thermo_style custom <thermo_style>`              | global scalars                               | screen, log file                          |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`dump custom <dump>`                              | per-atom vectors                             | dump file                                 |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`dump local <dump>`                               | local vectors                                | dump file                                 |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`fix print <fix_print>`                           | global scalar from variable                  | screen, file                              |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`print <print>`                                   | global scalar from variable                  | screen                                    |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`computes <compute>`                              | N/A                                          | global/per-atom/local scalar/vector/array |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`fixes <fix>`                                     | N/A                                          | global/per-atom/local scalar/vector/array |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`variables <variable>`                            | global scalars and vectors, per-atom vectors | global scalar and vector, per-atom vector |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`compute reduce <compute_reduce>`                 | per-atom/local vectors                       | global scalar/vector                      |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`compute slice <compute_slice>`                   | global vectors/arrays                        | global vector/array                       |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`compute property/atom <compute_property_atom>`   | per-atom vectors                             | per-atom vector/array                     |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`compute property/local <compute_property_local>` | local vectors                                | local vector/array                        |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`fix vector <fix_vector>`                         | global scalars                               | global vector                             |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`fix ave/atom <fix_ave_atom>`                     | per-atom vectors                             | per-atom vector/array                     |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`fix ave/time <fix_ave_time>`                     | global scalars/vectors                       | global scalar/vector/array, file          |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`fix ave/chunk <fix_ave_chunk>`                   | per-atom vectors                             | global array, file                        |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`fix ave/histo <fix_ave_histo>`                   | global/per-atom/local scalars and vectors    | global array, file                        |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`fix ave/correlate <fix_ave_correlate>`           | global scalars                               | global array, file                        |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
-| :doc:`fix store/state <fix_store_state>`               | per-atom vectors                             | per-atom vector/array                     |
-+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| Command                                                | Input                                        | Output                                             |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`thermo_style custom <thermo_style>`              | global scalars                               | screen, log file                                   |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`dump custom <dump>`                              | per-atom vectors                             | dump file                                          |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`dump local <dump>`                               | local vectors                                | dump file                                          |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`dump grid <dump>`                                | per-grid vectors                             | dump file                                          |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`fix print <fix_print>`                           | global scalar from variable                  | screen, file                                       |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`print <print>`                                   | global scalar from variable                  | screen                                             |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`computes <compute>`                              | N/A                                          | global/per-atom/local/per-grid scalar/vector/array |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`fixes <fix>`                                     | N/A                                          | global/per-atom/local/per-grid scalar/vector/array |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`variables <variable>`                            | global scalars and vectors, per-atom vectors | global scalar and vector, per-atom vector          |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`compute reduce <compute_reduce>`                 | per-atom/local vectors                       | global scalar/vector                               |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`compute slice <compute_slice>`                   | global vectors/arrays                        | global vector/array                                |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`compute property/atom <compute_property_atom>`   | N/A                                          | per-atom vector/array                              |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`compute property/local <compute_property_local>` | N/A                                          | local vector/array                                 |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`compute property/grid <compute_property_grid>`   | N/A                                          | per-grid vector/array                              |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`compute property/chunk <compute_property_chunk>` | N/A                                          | global vector/array                                |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`fix vector <fix_vector>`                         | global scalars                               | global vector                                      |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`fix ave/atom <fix_ave_atom>`                     | per-atom vectors                             | per-atom vector/array                              |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`fix ave/time <fix_ave_time>`                     | global scalars/vectors                       | global scalar/vector/array, file                   |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`fix ave/chunk <fix_ave_chunk>`                   | per-atom vectors                             | global array, file                                 |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`fix ave/grid <fix_ave_grid>`                     | per-atom vectors or per-grid vectors         | per-grid vector/array                              |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`fix ave/histo <fix_ave_histo>`                   | global/per-atom/local scalars and vectors    | global array, file                                 |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`fix ave/correlate <fix_ave_correlate>`           | global scalars                               | global array, file                                 |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
+| :doc:`fix store/state <fix_store_state>`               | per-atom vectors                             | per-atom vector/array                              |
++--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+

doc/src/Howto_pylammps.rst

@@ -152,14 +152,14 @@ Creating a new instance of PyLammps
 To create a PyLammps object you need to first import the class from the lammps
 module. By using the default constructor, a new *lammps* instance is created.
 
-.. code-block:: Python
+.. code-block:: python
 
    from lammps import PyLammps
    L = PyLammps()
 
 You can also initialize PyLammps on top of this existing *lammps* object:
 
-.. code-block:: Python
+.. code-block:: python
 
    from lammps import lammps, PyLammps
    lmp = lammps()
@@ -180,14 +180,14 @@ For instance, let's take the following LAMMPS command:
 In the original interface this command can be executed with the following
 Python code if *L* was a lammps instance:
 
-.. code-block:: Python
+.. code-block:: python
 
    L.command("region box block 0 10 0 5 -0.5 0.5")
 
 With the PyLammps interface, any command can be split up into arbitrary parts
 separated by white-space, passed as individual arguments to a region method.
 
-.. code-block:: Python
+.. code-block:: python
 
    L.region("box block", 0, 10, 0, 5, -0.5, 0.5)
 
@@ -199,14 +199,14 @@ The benefit of this approach is avoiding redundant command calls and easier
 parameterization. In the original interface parameterization needed to be done
 manually by creating formatted strings.
 
-.. code-block:: Python
+.. code-block:: python
 
    L.command("region box block %f %f %f %f %f %f" % (xlo, xhi, ylo, yhi, zlo, zhi))
 
 In contrast, methods of PyLammps accept parameters directly and will convert
 them automatically to a final command string.
 
-.. code-block:: Python
+.. code-block:: python
 
    L.region("box block", xlo, xhi, ylo, yhi, zlo, zhi)
 
@@ -256,7 +256,7 @@ LAMMPS variables can be both defined and accessed via the PyLammps interface.
 
 To define a variable you can use the :doc:`variable <variable>` command:
 
-.. code-block:: Python
+.. code-block:: python
 
    L.variable("a index 2")
 
@@ -265,14 +265,14 @@ A dictionary of all variables is returned by L.variables
 you can access an individual variable by retrieving a variable object from the
 L.variables dictionary by name
 
-.. code-block:: Python
+.. code-block:: python
 
    a = L.variables['a']
 
 The variable value can then be easily read and written by accessing the value
 property of this object.
 
-.. code-block:: Python
+.. code-block:: python
 
    print(a.value)
    a.value = 4
@@ -284,7 +284,7 @@ LAMMPS expressions can be immediately evaluated by using the eval method. The
 passed string parameter can be any expression containing global thermo values,
 variables, compute or fix data.
 
-.. code-block:: Python
+.. code-block:: python
 
    result = L.eval("ke") # kinetic energy
    result = L.eval("pe") # potential energy
@@ -298,7 +298,7 @@ All atoms in the current simulation can be accessed by using the L.atoms list.
 Each element of this list is an object which exposes its properties (id, type,
 position, velocity, force, etc.).
 
-.. code-block:: Python
+.. code-block:: python
 
    # access first atom
    L.atoms[0].id
@@ -311,7 +311,7 @@ position, velocity, force, etc.).
 
 Some properties can also be used to set:
 
-.. code-block:: Python
+.. code-block:: python
 
    # set position in 2D simulation
    L.atoms[0].position = (1.0, 0.0)
@@ -328,7 +328,7 @@ after a run via the L.runs list. This list contains a growing list of run data.
 The first element is the output of the first run, the second element that of
 the second run.
 
-.. code-block:: Python
+.. code-block:: python
 
    L.run(1000)
    L.runs[0] # data of first 1000 time steps
@@ -339,14 +339,14 @@ the second run.
 Each run contains a dictionary of all trajectories. Each trajectory is
 accessible through its thermo name:
 
-.. code-block:: Python
+.. code-block:: python
 
    L.runs[0].thermo.Step # list of time steps in first run
    L.runs[0].thermo.Ke   # list of kinetic energy values in first run
 
 Together with matplotlib plotting data out of LAMMPS becomes simple:
 
-.. code-block:: Python
+.. code-block:: python
 
    import matplotlib.plot as plt
    steps = L.runs[0].thermo.Step
@@ -406,7 +406,7 @@ Four atoms are placed in the simulation and the dihedral potential is applied on
 them using a datafile. Then one of the atoms is rotated along the central axis by
 setting its position from Python, which changes the dihedral angle.
 
-.. code-block:: Python
+.. code-block:: python
 
    phi = [d \* math.pi / 180 for d in range(360)]
 
@@ -439,7 +439,7 @@ Initially, a 2D system is created in a state with minimal energy.
 
 It is then disordered by moving each atom by a random delta.
 
-.. code-block:: Python
+.. code-block:: python
 
    random.seed(27848)
    deltaperturb = 0.2
@@ -458,7 +458,7 @@ It is then disordered by moving each atom by a random delta.
 Finally, the Monte Carlo algorithm is implemented in Python. It continuously
 moves random atoms by a random delta and only accepts certain moves.
 
-.. code-block:: Python
+.. code-block:: python
 
    estart = L.eval("pe")
    elast = estart
@@ -517,7 +517,7 @@ PyLammps can be run in parallel using mpi4py. This python package can be install
 The following is a short example which reads in an existing LAMMPS input file and
 executes it in parallel.  You can find in.melt in the examples/melt folder.
 
-.. code-block:: Python
+.. code-block:: python
 
    from mpi4py import MPI
    from lammps import PyLammps

doc/src/Howto_spc.rst

@@ -38,7 +38,7 @@ the partial charge assignments change:
 See the :ref:`(Berendsen) <howto-Berendsen>` reference for more details on both
 the SPC and SPC/E models.
 
-Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
+Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
 
 ----------
 

doc/src/Howto_spins.rst

@@ -30,9 +30,11 @@ can be coupled to another Langevin thermostat applied to the atoms
 using :doc:`fix langevin <fix_langevin>` in order to simulate
 thermostatted spin-lattice systems.
 
-The magnetic Gilbert damping can also be applied using :doc:`fix langevin/spin <fix_langevin_spin>`. It allows to either dissipate
-the thermal energy of the Langevin thermostat, or to perform a
-relaxation of the magnetic configuration toward an equilibrium state.
+The magnetic damping can also be applied
+using :doc:`fix langevin/spin <fix_langevin_spin>`.
+It allows to either dissipate the thermal energy of the Langevin
+thermostat, or to perform a relaxation of the magnetic configuration
+toward an equilibrium state.
 
 The command :doc:`fix setforce/spin <fix_setforce>` allows to set the
 components of the magnetic precession vectors (while erasing and
@@ -52,9 +54,11 @@ All the computed magnetic properties can be output by two main
 commands. The first one is :doc:`compute spin <compute_spin>`, that
 enables to evaluate magnetic averaged quantities, such as the total
 magnetization of the system along x, y, or z, the spin temperature, or
-the magnetic energy. The second command is :doc:`compute property/atom <compute_property_atom>`. It enables to output all the
-per atom magnetic quantities. Typically, the orientation of a given
-magnetic spin, or the magnetic force acting on this spin.
+the magnetic energy. The second command
+is :doc:`compute property/atom <compute_property_atom>`.
+It enables to output all the per atom magnetic quantities. Typically,
+the orientation of a given magnetic spin, or the magnetic force
+acting on this spin.
 
 ----------
 

doc/src/Howto_structured_data.rst

@@ -43,7 +43,7 @@ JSON
      "ke": $(ke)
    }""" file current_state.json screen no
 
-.. code-block:: JSON
+.. code-block:: json
    :caption: current_state.json
 
    {

doc/src/Howto_tip3p.rst

@@ -49,7 +49,7 @@ details:
 | :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
 |
 
-Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
+Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
 
 ----------
 

doc/src/Howto_tip4p.rst

@@ -8,18 +8,28 @@ This site M is located at a fixed distance away from the oxygen along
 the bisector of the HOH bond angle.  A bond style of *harmonic* and an
 angle style of *harmonic* or *charmm* should also be used.
 
-A TIP4P model is run with LAMMPS using either this command
+A TIP4P model is run with LAMMPS using either these commands
 for a cutoff model:
 
+* :doc:`pair_style tip4p/cut <pair_lj_cut_tip4p>`
 * :doc:`pair_style lj/cut/tip4p/cut <pair_lj_cut_tip4p>`
 
-or these two commands for a long-range model:
+or these commands for a long-range model:
 
+* :doc:`pair_style tip4p/long <pair_coul>`
 * :doc:`pair_style lj/cut/tip4p/long <pair_lj_cut_tip4p>`
+* :doc:`pair_style lj/long/tip4p/long <pair_lj_long>`
+* :doc:`pair_style tip4p/long/soft <pair_fep_soft>`
+* :doc:`pair_style lj/cut/tip4p/long/soft <pair_fep_soft>`
 * :doc:`kspace_style pppm/tip4p <kspace_style>`
+* :doc:`kspace_style pppm/disp/tip4p <kspace_style>`
 
-For both models, the bond lengths and bond angles should be held fixed
-using the :doc:`fix shake <fix_shake>` command.
+The bond lengths and bond angles should be held fixed using the
+:doc:`fix shake <fix_shake>` or :doc:`fix rattle <fix_shake>` command,
+unless a parameterization for a flexible TIP4P model is used.  The
+parameter sets listed below are all for rigid TIP4P model variants and
+thus the bond and angle force constants are not used and can be set to
+any legal value; only equilibrium length and angle are used.
 
 These are the additional parameters (in real units) to set for O and H
 atoms and the water molecule to run a rigid TIP4P model with a cutoff
@@ -87,17 +97,18 @@ solver (e.g. Ewald or PPPM in LAMMPS):
 | LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
 |
 
-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 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 trade-off for your model.  The OM distance and the LJ
-and Coulombic cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long <pair_lj_cut_tip4p>` command.
+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
+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
+trade-off for your model.  The OM distance and the LJ and Coulombic
+cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long
+<pair_lj_cut_tip4p>` command.
 
-Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
+Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
 
 ----------
 

doc/src/Howto_triclinic.rst

@@ -144,11 +144,6 @@ does not change the atom positions due to non-periodicity.  In this
 mode, if you tilt the system to extreme angles, the simulation will
 simply become inefficient, due to the highly skewed simulation box.
 
-The limitation on not creating a simulation box with a tilt factor
-skewing the box more than half the distance of the parallel box length
-can be overridden via the :doc:`box <box>` command.  Setting the *tilt*
-keyword to *large* allows any tilt factors to be specified.
-
 Box flips that may occur using the :doc:`fix deform <fix_deform>` or
 :doc:`fix npt <fix_nh>` commands can be turned off using the *flip no*
 option with either of the commands.

doc/src/Howto_type_labels.rst

@@ -0,0 +1,126 @@
+Type labels
+===========
+
+.. versionadded:: 15Sep2022
+
+Each atom in LAMMPS has an associated numeric atom type. Similarly,
+each bond, angle, dihedral, and improper is assigned a bond type,
+angle type, and so on.  The primary use of these types is to map
+potential (force field) parameters to the interactions of the atom,
+bond, angle, dihedral, and improper.
+
+By default, type values are entered as integers from 1 to Ntypes
+wherever they appear in LAMMPS input or output files.  The total number
+Ntypes for each interaction is "locked in" when the simulation box
+is created.
+
+A recent addition to LAMMPS is the option to use strings - referred
+to as type labels - as an alternative.  Using type labels instead of
+numeric types can be advantageous in various scenarios.  For example,
+type labels can make inputs more readable and generic (i.e. usable through
+the :doc:`include command <include>` for different systems with different
+numerical values assigned to types.  This generality also applies to
+other inputs like data files read by :doc:`read_data <read_data>` or
+molecule template files read by the :doc:`molecule <molecule>`
+command.  See below for a list of other commands that can use
+type labels in different ways.
+
+LAMMPS will *internally* continue to use numeric types, which means
+that many previous restrictions still apply.  For example, the total
+number of types is locked in when creating the simulation box, and
+potential parameters for each type must be provided even if not used
+by any interactions.
+
+A collection of type labels for all type-kinds (atom types, bond types,
+etc.) is stored as a "label map" which is simply a list of numeric types
+and their associated type labels.  Within a type-kind, each type label
+must be unique.  It can be assigned to only one numeric type.  To read
+and write type labels to data files for a given type-kind, *all*
+associated numeric types need have a type label assigned.  Partial
+maps can be saved with the :doc:`labelmap write <labelmap>` command
+and read back with the :doc:`include <include>` command.
+
+Valid type labels can contain most ASCII characters, but cannot start
+with a number, a '#', or a '*'.  Also, labels must not contain whitespace
+characters.  When using the :doc:`labelmap command <labelmap>` in the
+LAMMPS input, if certain characters appear in the type label, such as
+the single (') or double (") quote or the '#' character, the label
+must be put in either double, single, or triple (""") quotes.  Triple
+quotes allow for the most generic type label strings, but they require
+to have a leading and trailing blank space.  When defining type labels
+the blanks will be ignored. Example:
+
+.. code-block:: LAMMPS
+
+   labelmap angle 1 """ C1'-C2"-C3# """
+
+This command will map the string ```C1'-C2"-C3#``` to the angle type 1.
+
+There are two ways to define label maps.  One is via the :doc:`labelmap
+<labelmap>` command.  The other is via the :doc:`read_data <read_data>`
+command.  A data file can have sections such as *Atom Type Labels*, *Bond
+Type Labels*, etc., which assign type labels to numeric types.  The
+label map can be written out to data files by the :doc:`write_data
+<write_data>` command.  This map is also written to and read from
+restart files, by the :doc:`write_restart <write_restart>` and
+:doc:`read_restart <read_restart>` commands.
+
+----------
+
+Use of type labels in LAMMPS input or output
+""""""""""""""""""""""""""""""""""""""""""""
+
+Many LAMMPS input script commands that take a numeric type as an
+argument can use the associated type label instead.  If a type label
+is not defined for a particular numeric type, only its numeric type
+can be used.
+
+This example assigns labels to the atom types, and then uses the type
+labels to redefine the pair coefficients.
+
+.. code-block:: LAMMPS
+
+   pair_coeff 1 2 1.0 1.0              # numeric types
+   labelmap atom 1 C 2 H
+   pair_coeff C H 1.0 1.0              # type labels
+
+Adding support for type labels to various commands is an ongoing
+project.  If an input script command (or a section in a file read by a
+command) allows substituting a type label for a numeric type argument,
+it will be explicitly mentioned in that command's documentation page.
+
+As a temporary measure, input script commands can take advantage of
+variables and how they can be expanded during processing of the input.
+The variables can use functions that will translate type label strings
+to their respective number as defined in the current label map.  See the
+:doc:`variable <variable>` command for details.
+
+For example, here is how the pair_coeff command could be used with
+type labels if it did not yet support them, either with an explicit
+variable command or an implicit variable used in the pair_coeff
+command.
+
+.. code-block:: LAMMPS
+
+   labelmap atom 1 C 2 H
+   variable atom1 equal label2type(atom,C)
+   variable atom2 equal label2type(atom,H)
+   pair_coeff ${atom1} ${atom2} 1.0 1.0
+
+.. code-block:: LAMMPS
+
+   labelmap atom 1 C 2 H
+   pair_coeff $(label2type(atom,C)) $(label2type(atom,H)) 80.0 1.2
+
+----------
+
+Commands that can use label types
+"""""""""""""""""""""""""""""""""
+
+Any workflow that involves reading multiple data files, molecule
+templates or a combination of the two can be streamlined by using type
+labels instead of numeric types, because types are automatically synced
+between the files.  The creation of simulation-ready reaction templates
+for :doc:`fix bond/react <fix_bond_react>` is much simpler when using
+type labels, and results in templates that can be used without
+modification in multiple simulations or different systems.

doc/src/Howto_viscosity.rst

@@ -68,7 +68,8 @@ liquid Ar via the GK formalism:
    # Sample LAMMPS input script for viscosity of liquid Ar
 
    units       real
-   variable    T equal 86.4956
+   variable    T equal 200.0       # run temperature
+   variable    Tinit equal 250.0   # equilibration temperature
    variable    V equal vol
    variable    dt equal 4.0
    variable    p equal 400     # correlation length
@@ -99,12 +100,14 @@ liquid Ar via the GK formalism:
 
    # equilibration and thermalization
 
-   velocity     all create $T 102486 mom yes rot yes dist gaussian
-   fix          NVT all nvt temp $T $T 10 drag 0.2
+   velocity     all create ${Tinit} 102486 mom yes rot yes dist gaussian
+   fix          NVT all nvt temp ${Tinit} ${Tinit} 10 drag 0.2
    run          8000
 
    # viscosity calculation, switch to NVE if desired
 
+   velocity     all create $T 102486 mom yes rot yes dist gaussian
+   fix          NVT all nvt temp $T $T 10 drag 0.2
    #unfix       NVT
    #fix         NVE all nve
 
@@ -122,7 +125,7 @@ liquid Ar via the GK formalism:
    run          100000
    variable     v equal (v_v11+v_v22+v_v33)/3.0
    variable     ndens equal count(all)/vol
-   print        "average viscosity: $v [Pa.s] @ $T K, ${ndens} /A^3"
+   print        "average viscosity: $v [Pa.s] @ $T K, ${ndens} atoms/A^3"
 
 The fifth method is related to the above Green-Kubo method,
 but uses the Einstein formulation, analogous to the Einstein
@@ -131,9 +134,9 @@ time-integrated momentum fluxes play the role of Cartesian
 coordinates, whose mean-square displacement increases linearly
 with time at sufficiently long times.
 
-The sixth is periodic perturbation method. It is also a non-equilibrium MD method.
-However, instead of measure the momentum flux in response of applied velocity gradient,
-it measures the velocity profile in response of applied stress.
+The sixth is the periodic perturbation method, which is also a non-equilibrium MD method.
+However, instead of measuring the momentum flux in response to an applied velocity gradient,
+it measures the velocity profile in response to applied stress.
 A cosine-shaped periodic acceleration is added to the system via the
 :doc:`fix accelerate/cos <fix_accelerate_cos>` command,
 and the :doc:`compute viscosity/cos<compute_viscosity_cos>` command is used to monitor the

doc/src/Howto_viz.rst

@@ -17,9 +17,10 @@ formats.  See the :doc:`Tools <Tools>` page for details.
 
 A Python-based toolkit distributed by our group can read native LAMMPS
 dump files, including custom dump files with additional columns of
-user-specified atom information, and convert them to various formats
-or pipe them into visualization software directly.  See the `Pizza.py WWW site <pizza_>`_ for details.  Specifically, Pizza.py can convert
-LAMMPS dump files into PDB, XYZ, `EnSight <ensight_>`_, and VTK formats.
+user-specified atom information, and convert them to various formats or
+pipe them into visualization software directly.  See the `Pizza.py WWW
+site <pizza_>`_ for details.  Specifically, Pizza.py can convert LAMMPS
+dump files into PDB, XYZ, `EnSight <ensight_>`_, and VTK formats.
 Pizza.py can pipe LAMMPS dump files directly into the Raster3d and
 RasMol visualization programs.  Pizza.py has tools that do interactive
 3d OpenGL visualization and one that creates SVG images of dump file

doc/src/Install.rst

@@ -3,10 +3,20 @@ Install LAMMPS
 
 You can download LAMMPS as an executable or as source code.
 
-With source code, you also have to :doc:`build LAMMPS <Build>`.  But you
-have more flexibility as to what features to include or exclude in the
-build.  If you plan to :doc:`modify or extend LAMMPS <Modify>`, then you
-need the source code.
+When downloading the LAMMPS source code, you also have to :doc:`build
+LAMMPS <Build>`.  But you have more flexibility as to what features to
+include or exclude in the build.  When you download and install
+pre-compiled LAMMPS executables, you are limited to install which
+version of LAMMPS is available and which features are included of these
+builds.  If you plan to :doc:`modify or extend LAMMPS <Modify>`, then
+you **must** build LAMMPS from the source code.
+
+.. note::
+
+   If you have questions about the pre-compiled LAMMPS executables, you
+   need to contact the people preparing those executables.  The LAMMPS
+   developers have no control over their choices of how they configure
+   and build their packages and when they update them.
 
 .. toctree::
    :maxdepth: 1

doc/src/Install_conda.rst

@@ -5,7 +5,7 @@ Binaries are available for MacOS or Linux via `Conda <conda_>`_.
 
 First, one must setup the Conda package manager on your system.  Follow the
 instructions to install `Miniconda <mini_conda_install_>`_, then create a conda
-environment (named `my-lammps-env` or whatever you prefer) for your lammps
+environment (named `my-lammps-env` or whatever you prefer) for your LAMMPS
 install:
 
 .. code-block:: bash
@@ -13,7 +13,7 @@ install:
    % conda config --add channels conda-forge
    % conda create -n my-lammps-env
 
-Then, you can install lammps on your system with the following command:
+Then, you can install LAMMPS on your system with the following command:
 
 .. code-block:: bash
 
@@ -38,3 +38,10 @@ up the Conda capability.
 .. _openkim: https://openkim.org
 .. _conda: https://docs.conda.io/en/latest/index.html
 .. _mini_conda_install: https://docs.conda.io/en/latest/miniconda.html
+
+.. note::
+
+   If you have questions about these pre-compiled LAMMPS executables,
+   you need to contact the people preparing those packages.  The LAMMPS
+   developers have no control over their choices of how they configure
+   and build their packages and when they update them.

doc/src/Install_linux.rst

@@ -3,13 +3,19 @@ Download an executable for Linux
 
 Binaries are available for different versions of Linux:
 
-| :ref:`Pre-built Ubuntu Linux executables <ubuntu>`
-| :ref:`Pre-built Fedora Linux executables <fedora>`
-| :ref:`Pre-built EPEL Linux executables (RHEL, CentOS) <epel>`
-| :ref:`Pre-built OpenSuse Linux executables <opensuse>`
-| :ref:`Gentoo Linux executable <gentoo>`
-| :ref:`Arch Linux build-script <arch>`
-|
+- :ref:`Pre-built Ubuntu Linux executables <ubuntu>`
+- :ref:`Pre-built Fedora Linux executables <fedora>`
+- :ref:`Pre-built EPEL Linux executables (RHEL, CentOS) <epel>`
+- :ref:`Pre-built OpenSuse Linux executables <opensuse>`
+- :ref:`Gentoo Linux executable <gentoo>`
+- :ref:`Arch Linux build-script <arch>`
+
+.. note::
+
+   If you have questions about these pre-compiled LAMMPS executables,
+   you need to contact the people preparing those packages.  The LAMMPS
+   developers have no control over their choices of how they configure
+   and build their packages and when they update them.
 
 ----------
 
@@ -18,41 +24,28 @@ Binaries are available for different versions of Linux:
 Pre-built Ubuntu Linux executables
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-A pre-built LAMMPS executable suitable for running on the latest
-Ubuntu Linux versions, can be downloaded as a Debian package.  This
-allows you to install LAMMPS with a single command, and stay
-up-to-date with the current stable version of LAMMPS by simply updating
-your operating system.  Please note, that the repository below offers
-two LAMMPS packages, ``lammps-daily`` and ``lammps-stable``.  The
-LAMMPS developers recommend to use the ``lammps-stable`` package for
-any production simulations.  The ``lammps-daily`` package is built
-from the LAMMPS development sources, and those versions may have known
-issues and bugs when new features are added and the software has not
-undergone full release testing.
-
-To install the appropriate personal-package archives (PPAs), do the
-following once:
-
-.. code-block:: bash
-
-   $ sudo add-apt-repository ppa:gladky-anton/lammps
-   $ sudo add-apt-repository ppa:openkim/latest
-   $ sudo apt-get update
+A pre-built LAMMPS executable suitable for running on the latest Ubuntu
+Linux versions, can be downloaded as a Debian package.  This allows you
+to install LAMMPS with a single command, and stay (mostly) up-to-date
+with the current stable version of LAMMPS by simply updating your
+operating system.
 
 To install LAMMPS do the following once:
 
 .. code-block:: bash
 
-   $ sudo apt-get install lammps-stable
+   $ sudo apt-get install lammps
 
-This downloads an executable named ``lmp_stable`` to your box, which
-can then be used in the usual way to run input scripts:
+This downloads an executable named ``lmp`` to your box and multiple
+packages with supporting data, examples and libraries as well as any
+missing dependencies.  This executable can then be used in the usual way
+to run input scripts:
 
 .. code-block:: bash
 
-   $ lmp_stable -in in.lj
+   $ lmp -in in.lj
 
-To update LAMMPS to the most current stable version, do the following:
+To update LAMMPS to the latest packaged version, do the following:
 
 .. code-block:: bash
 
@@ -60,44 +53,24 @@ To update LAMMPS to the most current stable version, do the following:
 
 which will also update other packages on your system.
 
-To get a copy of the current documentation and examples:
-
-.. code-block:: bash
-
-   $ sudo apt-get install lammps-stable-doc
-
-which will download the doc files in
-``/usr/share/doc/lammps-stable-doc/doc`` and example problems in
-``/usr/share/doc/lammps-doc/examples``.
-
-To get a copy of the current potentials files:
-
-.. code-block:: bash
-
-   $ sudo apt-get install lammps-stable-data
-
-which will download the potentials files to
-``/usr/share/lammps-stable/potentials``.  The ``lmp_stable`` binary is
-hard-coded to look for potential files in this directory (it does not
-use the ``LAMMPS_POTENTIALS`` environment variable, as described
-in :doc:`pair_coeff <pair_coeff>` command).
-
-The ``lmp_stable`` binary is built with the :ref:`KIM package <kim>` which
-results in the above command also installing the ``kim-api`` binaries when LAMMPS
-is installed.  In order to use potentials from `openkim.org <openkim_>`_, you
-can install the ``openkim-models`` package
+The ``lmp`` binary is built with the :ref:`KIM package <kim>` included,
+which results in the above command also installing the ``kim-api``
+binaries when LAMMPS is installed.  In order to use potentials from
+`openkim.org <openkim_>`_, you can also install the ``openkim-models``
+package
 
 .. code-block:: bash
 
    $ sudo apt-get install openkim-models
 
+Or use the KIM-API commands to download and install individual models.
 To un-install LAMMPS, do the following:
 
 .. code-block:: bash
 
-   $ sudo apt-get remove lammps-stable
+   $ sudo apt-get remove lammps
 
-Please use ``lmp_stable -help`` to see which compilation options, packages,
+Please use ``lmp -help`` to see which compilation options, packages,
 and styles are included in the binary.
 
 Thanks to Anton Gladky (gladky.anton at gmail.com) for setting up this
@@ -110,21 +83,21 @@ Ubuntu package capability.
 Pre-built Fedora Linux executables
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Pre-built LAMMPS packages for stable releases are available
-in the Fedora Linux distribution as of version 28. The packages
-can be installed via the dnf package manager. There are 3 basic
-varieties (lammps = no MPI, lammps-mpich = MPICH MPI library,
-lammps-openmpi = OpenMPI MPI library) and for each support for
-linking to the C library interface (lammps-devel, lammps-mpich-devel,
-lammps-openmpi-devel), the header for compiling programs using
-the C library interface (lammps-headers), and the LAMMPS python
-module for Python 3. All packages can be installed at the same
-time and the name of the LAMMPS executable is ``lmp`` and ``lmp_openmpi``
-or ``lmp_mpich`` respectively.  By default, ``lmp`` will refer to the
-serial executable, unless one of the MPI environment modules is loaded
-(``module load mpi/mpich-x86_64`` or ``module load mpi/openmpi-x86_64``).
-Then the corresponding parallel LAMMPS executable can be used.
-The same mechanism applies when loading the LAMMPS python module.
+Pre-built LAMMPS packages for stable releases are available in the
+Fedora Linux distribution as of Fedora version 28. The packages can be
+installed via the dnf package manager. There are 3 basic varieties
+(lammps = no MPI, lammps-mpich = MPICH MPI library, lammps-openmpi =
+OpenMPI MPI library) and for each support for linking to the C library
+interface (lammps-devel, lammps-mpich-devel, lammps-openmpi-devel), the
+header for compiling programs using the C library interface
+(lammps-headers), and the LAMMPS python module for Python 3. All
+packages can be installed at the same time and the name of the LAMMPS
+executable is ``lmp`` and ``lmp_openmpi`` or ``lmp_mpich`` respectively.
+By default, ``lmp`` will refer to the serial executable, unless one of
+the MPI environment modules is loaded (``module load mpi/mpich-x86_64``
+or ``module load mpi/openmpi-x86_64``).  Then the corresponding parallel
+LAMMPS executable can be used.  The same mechanism applies when loading
+the LAMMPS python module.
 
 To install LAMMPS with OpenMPI and run an input ``in.lj`` with 2 CPUs do:
 
@@ -273,3 +246,10 @@ Alternatively, you may use an AUR helper to install these packages.
 
 Note that the AUR provides build-scripts that download the source and
 the build the package on your machine.
+
+.. note::
+
+   It looks like the Arch Linux AUR repository build scripts for LAMMPS
+   have not been updated since the 29 October 2020 version.  You may want
+   to consider installing a more current version of LAMMPS from source
+   directly.

doc/src/Install_windows.rst

@@ -6,7 +6,7 @@ Windows system can be downloaded from this site:
 
 .. parsed-literal::
 
-  `http://packages.lammps.org/windows.html <http://packages.lammps.org/windows.html>`_
+  `https://packages.lammps.org/windows.html <https://packages.lammps.org/windows.html>`_
 
 Note that each installer package has a date in its name, which
 corresponds to the LAMMPS version of the same date.  Installers for

doc/src/Intro_authors.rst

@@ -4,13 +4,13 @@ Authors of LAMMPS
 The primary LAMMPS developers are at Sandia National Labs and Temple
 University:
 
-* `Steve Plimpton <sjp_>`_, sjplimp at sandia.gov
+* `Steve Plimpton <sjp_>`_, sjplimp at gmail.com
 * Aidan Thompson, athomps at sandia.gov
 * Stan Moore, stamoor at sandia.gov
 * Axel Kohlmeyer, akohlmey at gmail.com
 * Richard Berger, richard.berger at outlook.com
 
-.. _sjp: http://www.cs.sandia.gov/~sjplimp
+.. _sjp: https://sjplimp.github.io
 .. _lws: https://www.lammps.org
 
 Past developers include Paul Crozier and Mark Stevens, both at Sandia,

doc/src/Intro_citing.rst

@@ -27,15 +27,15 @@ namely https://www.lammps.org.
 The original publication describing the parallel algorithms used in the
 initial versions of LAMMPS is:
 
-  `S. Plimpton, Fast Parallel Algorithms for Short-Range Molecular Dynamics, J Comp Phys, 117, 1-19 (1995). <http://www.sandia.gov/~sjplimp/papers/jcompphys95.pdf>`_
+  `S. Plimpton, Fast Parallel Algorithms for Short-Range Molecular Dynamics, J Comp Phys, 117, 1-19 (1995). <https://doi.org/10.1006/jcph.1995.1039>`_
 
 
 DOI for the LAMMPS source code
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-LAMMPS developers use the `Zenodo service at CERN <https://zenodo.org/>`_
-to create digital object identifies (DOI) for stable releases of the
-LAMMPS source code. There are two types of DOIs for the LAMMPS source code.
+The LAMMPS developers use the `Zenodo service at CERN <https://zenodo.org/>`_
+to create digital object identifiers (DOI) for stable releases of the
+LAMMPS source code.  There are two types of DOIs for the LAMMPS source code.
 
 The canonical DOI for **all** versions of LAMMPS, which will always
 point to the **latest** stable release version is:

doc/src/Intro_features.rst

@@ -95,7 +95,7 @@ commands)
 * metal-organic framework potentials (QuickFF, MO-FF)
 * implicit solvent potentials: hydrodynamic lubrication, Debye
 * force-field compatibility with common CHARMM, AMBER, DREIDING, OPLS, GROMACS, COMPASS options
-* access to the `OpenKIM Repository <http://openkim.org>`_ of potentials via     :doc:`kim command <kim_commands>`
+* access to the `OpenKIM Repository <https://openkim.org>`_ of potentials via the :doc:`kim command <kim_commands>`
 * hybrid potentials: multiple pair, bond, angle, dihedral, improper potentials can be used in one simulation
 * overlaid potentials: superposition of multiple pair potentials (including many-body) with optional scale factor
 
@@ -205,7 +205,7 @@ Pre- and post-processing
 
 .. _pizza: https://lammps.github.io/pizza
 
-.. _python: http://www.python.org
+.. _python: https://www.python.org
 
 .. _special: