Merge pull request #3446 from akohlmey/next-patch-release

Update versions strings for the 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,20 +13,21 @@ lib/kim/*             @ellio167
 lib/mesont/*          @iafoss
 
 # whole packages
+src/AMOEBA/*          @sjplimp
 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/BROWNIAN/*        @samueljmcameron
 src/CG-DNA/*          @ohenrich
-src/CG-SDK/*          @akohlmey
+src/CG-SPICA/*        @yskmiyazaki
 src/COLVARS/*         @giacomofiorin
 src/DIELECTRIC/*      @ndtrung81
+src/ELECTRODE/*       @ludwig-ahrens
 src/FEP/*             @agiliopadua
 src/ML-HDNNP/*        @singraber
 src/INTEL/*           @wmbrownintel
@@ -133,6 +134,7 @@ tools/coding_standard/* @rbberger
 tools/valgrind/*      @akohlmey
 tools/swig/*          @akohlmey
 tools/offline/*       @rbberger
+tools/vim/*           @hammondkd
 
 # tests
 unittest/*            @akohlmey @rbberger

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

@@ -0,0 +1,6 @@
+version: 2
+updates:
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"

.github/workflows/codeql-analysis.yml

@@ -13,6 +13,11 @@ jobs:
     if: ${{ github.repository == 'lammps/lammps' }}
     runs-on: ubuntu-latest
 
+    permissions:
+      security-events: write
+      actions: read
+      contents: read
+
     strategy:
       fail-fast: false
       matrix:
@@ -20,17 +25,17 @@ jobs:
 
     steps:
     - name: Checkout repository
-      uses: actions/checkout@v2
+      uses: actions/checkout@v3
       with:
         fetch-depth: 2
 
     - name: Setup Python
-      uses: actions/setup-python@v2
+      uses: actions/setup-python@v4
       with:
         python-version: '3.x'
 
     - name: Initialize CodeQL
-      uses: github/codeql-action/init@v1
+      uses: github/codeql-action/init@v2
       with:
         languages: ${{ matrix.language }}
         config-file: ./.github/codeql/${{ matrix.language }}.yml
@@ -48,4 +53,4 @@ jobs:
         cmake --build . --parallel 2
 
     - name: Perform CodeQL Analysis
-      uses: github/codeql-action/analyze@v1
+      uses: github/codeql-action/analyze@v2

.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:
 
@@ -15,12 +19,12 @@ jobs:
 
     steps:
     - name: Checkout repository
-      uses: actions/checkout@v2
+      uses: actions/checkout@v3
       with:
         fetch-depth: 2
 
     - name: Select Python version
-      uses: actions/setup-python@v2
+      uses: actions/setup-python@v4
       with:
         python-version: '3.10'
 

.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:
 
@@ -17,7 +21,7 @@ jobs:
 
     steps:
     - name: Checkout repository
-      uses: actions/checkout@v2
+      uses: actions/checkout@v3
       with:
         fetch-depth: 2
 
@@ -28,7 +32,7 @@ jobs:
       run: mkdir build
 
     - name: Set up ccache
-      uses: actions/cache@v2
+      uses: actions/cache@v3
       with:
         path: ${{ env.CCACHE_DIR }}
         key: macos-ccache-${{ github.sha }}
@@ -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"

cmake/CMakeLists.txt

@@ -135,10 +135,10 @@ 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)
-  add_compile_options(/Zc:__cplusplus)
-  add_compile_options(/wd4244)
-  add_compile_options(/wd4267)
-  if(LAMMPS_EXCEPTIONS)
+  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)
     add_compile_options(/EHsc)
   endif()
   add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
@@ -152,6 +152,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)
@@ -192,6 +205,7 @@ option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
 
 set(STANDARD_PACKAGES
   ADIOS
+  AMOEBA
   ASPHERE
   ATC
   AWPMD
@@ -200,7 +214,7 @@ set(STANDARD_PACKAGES
   BPM
   BROWNIAN
   CG-DNA
-  CG-SDK
+  CG-SPICA
   CLASS2
   COLLOID
   COLVARS
@@ -356,11 +370,13 @@ 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)
@@ -400,9 +416,11 @@ endif()
 
 if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP 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")
@@ -631,7 +649,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 MISC PHONON QEQ OPENMP KOKKOS OPT INTEL GPU)
   if(PKG_${PKG_WITH_INCL})
     include(Packages/${PKG_WITH_INCL})
   endif()
@@ -778,20 +796,26 @@ 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)
-    set(LIBLAMMPS_SHARED_BINARY ${CMAKE_BINARY_DIR}/$<CONFIG>/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX})
+    set(MY_BUILD_DIR ${CMAKE_BINARY_DIR}/$<CONFIG>)
   else()
-    set(LIBLAMMPS_SHARED_BINARY ${CMAKE_BINARY_DIR}/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX})
+    set(MY_BUILD_DIR ${CMAKE_BINARY_DIR})
   endif()
+  set(LIBLAMMPS_SHARED_BINARY ${MY_BUILD_DIR}/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX})
   if(Python_EXECUTABLE)
     add_custom_target(
       install-python ${CMAKE_COMMAND} -E remove_directory build
-      COMMAND ${Python_EXECUTABLE} ${LAMMPS_PYTHON_DIR}/install.py -p ${LAMMPS_PYTHON_DIR}/lammps -l ${LIBLAMMPS_SHARED_BINARY}
+      COMMAND ${Python_EXECUTABLE} ${LAMMPS_PYTHON_DIR}/install.py -p ${LAMMPS_PYTHON_DIR}/lammps
+              -l ${LIBLAMMPS_SHARED_BINARY} -w ${MY_BUILD_DIR}
       COMMENT "Installing LAMMPS Python module")
   else()
     add_custom_target(
@@ -811,11 +835,17 @@ 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)

cmake/Modules/LAMMPSInterfacePlugin.cmake

@@ -0,0 +1,208 @@
+# CMake script code to define LAMMPS settings required for building LAMMPS plugins
+
+# enforce out-of-source build
+if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_BINARY_DIR})
+  message(FATAL_ERROR "In-source builds are not allowed. You must create and use a build directory. "
+    "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)
+  message(FATAL_ERROR "Must set LAMMPS_SOURCE_DIR")
+endif()
+
+# by default, install into $HOME/.local (not /usr/local),
+# so that no root access (and sudo) is needed
+if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
+  set(CMAKE_INSTALL_PREFIX "$ENV{HOME}/.local" CACHE PATH "Default install path" FORCE)
+endif()
+
+# 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")
+    add_compile_options(/Zc:__cplusplus)
+    add_compile_options(/wd4244)
+    add_compile_options(/wd4267)
+    if(LAMMPS_EXCEPTIONS)
+      add_compile_options(/EHsc)
+    endif()
+  endif()
+  add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
+endif()
+
+# C++11 is required
+set(CMAKE_CXX_STANDARD 11)
+set(CMAKE_CXX_STANDARD_REQUIRED ON)
+
+# Need -restrict with Intel compilers
+if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
+endif()
+set(CMAKE_POSITION_INDEPENDENT_CODE TRUE)
+
+#######
+# helper functions from LAMMPSUtils.cmake
+function(validate_option name values)
+  string(TOLOWER ${${name}} needle_lower)
+  string(TOUPPER ${${name}} needle_upper)
+  list(FIND ${values} ${needle_lower} IDX_LOWER)
+  list(FIND ${values} ${needle_upper} IDX_UPPER)
+  if(${IDX_LOWER} LESS 0 AND ${IDX_UPPER} LESS 0)
+    list_to_bulletpoints(POSSIBLE_VALUE_LIST ${${values}})
+    message(FATAL_ERROR "\n########################################################################\n"
+      "Invalid value '${${name}}' for option ${name}\n"
+      "\n"
+      "Possible values are:\n"
+      "${POSSIBLE_VALUE_LIST}"
+      "########################################################################")
+  endif()
+endfunction(validate_option)
+
+# 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})
+  set(_besttime 2000-01-01T00:00:00)
+  set(_bestfile "<unknown>")
+  foreach(_dir ${_dirs})
+    file(TIMESTAMP ${_dir} _newtime)
+    if(_newtime IS_NEWER_THAN _besttime)
+      set(_bestfile ${_dir})
+      set(_besttime ${_newtime})
+    endif()
+  endforeach()
+  if(_bestfile STREQUAL "<unknown>")
+    message(FATAL_ERROR "Could not find valid path at: ${path}")
+  endif()
+  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)
+target_include_directories(lammps INTERFACE ${LAMMPS_SOURCE_DIR})
+if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
+  target_link_libraries(lammps INTERFACE ${CMAKE_BINARY_DIR}/../liblammps.dll.a)
+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()
+  option(BUILD_MPI "Build MPI version" OFF)
+endif()
+
+if(BUILD_MPI)
+  # do not include the (obsolete) MPI C++ bindings which makes
+  # for leaner object files and avoids namespace conflicts
+  set(MPI_CXX_SKIP_MPICXX TRUE)
+  # We use a non-standard procedure to cross-compile with MPI on Windows
+  if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
+    # 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)
+
+    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")
+  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)
+    if(LAMMPS_LONGLONG_TO_LONG)
+      target_compile_definitions(lammps INTERFACE -DLAMMPS_LONGLONG_TO_LONG)
+    endif()
+  endif()
+  target_link_libraries(lammps INTERFACE MPI::MPI_CXX)
+else()
+  add_library(mpi_stubs INTERFACE)
+  target_include_directories(mpi_stubs INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
+  target_link_libraries(lammps INTERFACE mpi_stubs)
+endif()
+
+################################################################################
+# 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)
+  if(HAVE_OMP_H_INCLUDE)
+    set(BUILD_OMP_DEFAULT ON)
+  endif()
+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)
+  if(NOT HAVE_OMP_H_INCLUDE)
+    message(FATAL_ERROR "Cannot find the 'omp.h' header file required for full OpenMP support")
+  endif()
+
+  if (((CMAKE_CXX_COMPILER_ID STREQUAL "GNU") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 9.0)) OR
+      (CMAKE_CXX_COMPILER_ID STREQUAL "PGI") OR
+      ((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 10.0)) OR
+      ((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.0)))
+    # GCC 9.x and later plus Clang 10.x and later implement strict OpenMP 4.0 semantics for consts.
+    # Intel 18.0 was tested to support both, so we switch to OpenMP 4+ from 19.x onward to be safe.
+    target_compile_definitions(lammps INTERFACE -DLAMMPS_OMP_COMPAT=4)
+  else()
+    target_compile_definitions(lammps INTERFACE -DLAMMPS_OMP_COMPAT=3)
+  endif()
+  target_link_libraries(lammps INTERFACE OpenMP::OpenMP_CXX)
+endif()
+
+################
+# integer size selection
+set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallsmall: all 32-bit, smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
+set(LAMMPS_SIZES_VALUES smallbig bigbig smallsmall)
+set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
+validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
+string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)
+target_compile_definitions(lammps INTERFACE -DLAMMPS_${LAMMPS_SIZES})

cmake/Modules/LAMMPSUtils.cmake

@@ -110,14 +110,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/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

@@ -47,8 +47,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.6.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_MD5 "0ec97fc0c356dd65bd2487defe81a7bf" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   ExternalProject_Add(kokkos_build
@@ -72,7 +72,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.6.01 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
   target_link_libraries(lmp PRIVATE Kokkos::kokkos)
 else()

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/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.11.tar.gz" CACHE STRING "URL for MDI tarball")
+  set(MDI_MD5 "3791fe5081405c14aac07d4687f1cc58" 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()
@@ -44,7 +57,7 @@ if(DOWNLOAD_MDI)
   ExternalProject_Add(mdi_build
     URL     ${MDI_URL}
     URL_MD5 ${MDI_MD5}
-    CMAKE_ARGS ${CMAKE_REQUEST_PIC}
+    CMAKE_ARGS
     -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
     -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
     -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
@@ -54,6 +67,7 @@ if(DOWNLOAD_MDI)
     -Dlanguage=C
     -Dlibtype=STATIC
     -Dmpi=${MDI_USE_MPI}
+    -Dplugins=ON
     -Dpython_plugins=${MDI_USE_PYTHON_PLUGINS}
     UPDATE_COMMAND ""
     INSTALL_COMMAND ""

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-PACE.cmake

@@ -32,5 +32,6 @@ target_include_directories(pace PUBLIC ${PACE_EVALUATOR_INCLUDE_DIR} ${YAML_CPP_
 
 
 target_link_libraries(pace PRIVATE yaml-cpp-pace)
-
-target_link_libraries(lammps PRIVATE pace)
+if(CMAKE_PROJECT_NAME STREQUAL "lammps")
+  target_link_libraries(lammps PRIVATE pace)
+endif()

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

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

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)

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,8 +47,8 @@ set(WIN_PACKAGES
   MISC
   ML-HDNNP
   ML-IAP
-  ML-SNAP
   ML-RANN
+  ML-SNAP
   MOFFF
   MOLECULE
   MOLFILE
@@ -56,6 +57,7 @@ set(WIN_PACKAGES
   ORIENT
   PERI
   PHONON
+  PLUGIN
   POEMS
   PTM
   QEQ

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

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

@@ -13,7 +13,7 @@ VENV           = $(BUILDDIR)/docenv
 ANCHORCHECK    = $(VENV)/bin/rst_anchor_check
 SPHINXCONFIG   = $(BUILDDIR)/utils/sphinx-config
 MATHJAX        = $(SPHINXCONFIG)/_static/mathjax
-MATHJAXTAG     = 3.2.1
+MATHJAXTAG     = 3.2.2
 
 PYTHON         = $(word 3,$(shell type python3))
 DOXYGEN        = $(word 3,$(shell type doxygen))
@@ -242,7 +242,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" "2 June 2022" "2022-6-2"
+.TH LAMMPS "1" "15 September 2022" "2022-9-15"
 .SH NAME
 .B LAMMPS
-\- Molecular Dynamics Simulator.  Version 2 June 2022
+\- Molecular Dynamics Simulator.  Version 15 September 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

@@ -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_extras.rst

@@ -123,6 +123,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 +180,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 +199,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 +208,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
 ^^^^^^^^^^^^^^^^
 
@@ -788,8 +807,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 +818,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
@@ -1913,14 +1941,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
 

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
@@ -252,6 +249,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/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
@@ -60,6 +63,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>`

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_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
 ================
@@ -138,6 +139,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,56 @@
+.. 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:`deprecated <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>`
@@ -103,7 +106,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 +165,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>`

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>`
@@ -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,10 +197,11 @@ 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>`
@@ -268,6 +272,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>`

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

@@ -17,6 +17,7 @@ of time and requests from the LAMMPS user community.
    Developer_flow
    Developer_write
    Developer_notes
+   Developer_updating
    Developer_plugins
    Developer_unittest
    Classes

doc/src/Developer_plugins.rst

@@ -276,10 +276,27 @@ Compilation of the plugin can be managed via both, CMake or traditional
 GNU makefiles.  Some examples that can be used as a template are in the
 ``examples/plugins`` folder.  The CMake script code has some small
 adjustments to allow building the plugins for running unit tests with
-them. Another example that converts the KIM package into a plugin can be
-found in the ``examples/kim/plugin`` folder.  No changes to the sources
-of the KIM package themselves are needed; only the plugin interface and
-loader code needs to be added.  This example only supports building with
-CMake, but is probably a more typical example. To compile you need to
-run CMake with -DLAMMPS_SOURCE_DIR=<path/to/lammps/src/folder>.  Other
+them.
+
+Another example that converts the KIM package into a plugin can be found
+in the ``examples/kim/plugin`` folder.  No changes to the sources of the
+KIM package themselves are needed; only the plugin interface and loader
+code needs to be added.  This example only supports building with CMake,
+but is probably a more typical example. To compile you need to run CMake
+with -DLAMMPS_SOURCE_DIR=<path/to/lammps/src/folder>.  Other
 configuration setting are identical to those for compiling LAMMPS.
+
+A second example for a plugin from a package is in the
+``examples/PACKAGES/pace/plugin`` folder that will create a plugin from
+the ML-PACE package.  In this case the bulk of the code is in a static
+external library that is being downloaded and compiled first and then
+combined with the pair style wrapper and the plugin loader.  This
+example also contains a NSIS script that can be used to create an
+Installer package for Windows (the mutual licensing terms of the
+external library and LAMMPS conflict when distributing binaries, so the
+ML-PACE package cannot be linked statically, but the LAMMPS headers
+required to build the plugin are also available under a less restrictive
+license).  This will automatically set the required environment variable
+and launching a (compatible) LAMMPS binary will load and register the
+plugin and the ML-PACE package can then be used as it was linked into
+LAMMPS.

doc/src/Developer_updating.rst

@@ -0,0 +1,425 @@
+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 developer@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()`_
+
+----
+
+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.

doc/src/Developer_utils.rst

@@ -154,6 +154,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 +175,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 +211,13 @@ Argument processing
 .. doxygenfunction:: expand_args
    :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)

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

@@ -38,11 +38,11 @@ found together with equivalent examples in C and C++ in the
 
 .. note::
 
-   A contributed (and complete!) Fortran interface that more
-   closely resembles the C-library interface is available
-   in the ``examples/COUPLE/fortran2`` folder.  Please see the
-   ``README`` file in that folder for more information about it
-   and how to contact its author and maintainer.
+   A contributed (and more complete!) Fortran interface that more
+   closely resembles the C-library interface is available in the
+   ``examples/COUPLE/fortran2`` folder.  Please see the ``README`` file
+   in that folder for more information about it and how to contact its
+   author and maintainer.
 
 ----------
 
@@ -65,8 +65,9 @@ the optional logical argument set to ``.true.``. Here is a simple example:
 
    PROGRAM testlib
      USE LIBLAMMPS                 ! include the LAMMPS library interface
+     IMPLICIT NONE
      TYPE(lammps)     :: lmp       ! derived type to hold LAMMPS instance
-     CHARACTER(len=*), DIMENSION(*), PARAMETER :: args = &
+     CHARACTER(len=*), PARAMETER :: args(3) = &
          [ CHARACTER(len=12) :: 'liblammps', '-log', 'none' ]
 
      ! create a LAMMPS instance (and initialize MPI)
@@ -78,6 +79,41 @@ the optional logical argument set to ``.true.``. Here is a simple example:
 
    END PROGRAM testlib
 
+It is also possible to pass command line flags from Fortran to C/C++ and
+thus make the resulting executable behave similar to the standalone
+executable (it will ignore the `-in/-i` flag, though).  This allows to
+use the command line to configure accelerator and suffix settings,
+configure screen and logfile output, or to set index style variables
+from the command line and more. Here is a correspondingly adapted
+version of the previous example:
+
+.. code-block:: fortran
+
+   PROGRAM testlib2
+     USE LIBLAMMPS                 ! include the LAMMPS library interface
+     IMPLICIT NONE
+     TYPE(lammps)     :: lmp       ! derived type to hold LAMMPS instance
+     CHARACTER(len=128), ALLOCATABLE :: command_args(:)
+     INTEGER :: i, argc
+
+     ! copy command line flags to `command_args()`
+     argc = COMMAND_ARGUMENT_COUNT()
+     ALLOCATE(command_args(0:argc))
+     DO i=0, argc
+       CALL GET_COMMAND_ARGUMENT(i, command_args(i))
+     END DO
+
+     ! create a LAMMPS instance (and initialize MPI)
+     lmp = lammps(command_args)
+     ! get and print numerical version code
+     PRINT*, 'Program name:   ', command_args(0)
+     PRINT*, 'LAMMPS Version: ', lmp%version()
+     ! delete LAMMPS instance (and shuts down MPI)
+     CALL lmp%close(.TRUE.)
+     DEALLOCATE(command_args)
+
+   END PROGRAM testlib2
+
 --------------------
 
 Executing LAMMPS commands
@@ -102,7 +138,7 @@ Below is a small demonstration of the uses of the different functions:
      USE LIBLAMMPS
      TYPE(lammps)     :: lmp
      CHARACTER(len=512) :: cmds
-     CHARACTER(len=40),ALLOCATABLE :: cmdlist(:)
+     CHARACTER(len=40), ALLOCATABLE :: cmdlist(:)
      CHARACTER(len=10) :: trimmed
      INTEGER :: i
 
@@ -111,10 +147,10 @@ Below is a small demonstration of the uses of the different functions:
      CALL lmp%command('variable zpos index 1.0')
      ! define 10 groups of 10 atoms each
      ALLOCATE(cmdlist(10))
-     DO i=1,10
+     DO i=1, 10
          WRITE(trimmed,'(I10)') 10*i
          WRITE(cmdlist(i),'(A,I1,A,I10,A,A)')       &
-             'group g',i-1,' id ',10*(i-1)+1,':',ADJUSTL(trimmed)
+             'group g', i-1, ' id ', 10*(i-1)+1, ':', ADJUSTL(trimmed)
      END DO
      CALL lmp%commands_list(cmdlist)
      ! run multiple commands from multi-line string
@@ -123,7 +159,7 @@ Below is a small demonstration of the uses of the different functions:
          'create_box 1 box' // NEW_LINE('A') //               &
          'create_atoms 1 single 1.0 1.0 ${zpos}'
      CALL lmp%commands_string(cmds)
-     CALL lmp%close()
+     CALL lmp%close(.TRUE.)
 
    END PROGRAM testcmd
 
@@ -137,9 +173,9 @@ of the contents of the ``LIBLAMMPS`` Fortran interface to LAMMPS.
 
 .. f:type:: lammps
 
-   Derived type that is the general class of the Fortran interface.
-   It holds a reference to the :cpp:class:`LAMMPS <LAMMPS_NS::LAMMPS>` class instance
-   that any of the included calls are forwarded to.
+   Derived type that is the general class of the Fortran interface.  It
+   holds a reference to the :cpp:class:`LAMMPS <LAMMPS_NS::LAMMPS>`
+   class instance that any of the included calls are forwarded to.
 
    :f c_ptr handle: reference to the LAMMPS class
    :f close: :f:func:`close`
@@ -202,7 +238,7 @@ of the contents of the ``LIBLAMMPS`` Fortran interface to LAMMPS.
    This method will call :cpp:func:`lammps_commands_list` to have LAMMPS
    execute a list of input lines.
 
-   :p character(len=*) cmd(*): list of LAMMPS input lines
+   :p character(len=*) cmd(:): list of LAMMPS input lines
 
 .. f:subroutine:: commands_string(str)
 
@@ -210,4 +246,3 @@ of the contents of the ``LIBLAMMPS`` Fortran interface to LAMMPS.
    execute a block of commands from a string.
 
    :p character(len=*) str: LAMMPS input in string
-

doc/src/Howto.rst

@@ -34,6 +34,7 @@ Settings howto
    :maxdepth: 1
 
    Howto_2d
+   Howto_type_labels
    Howto_triclinic
    Howto_thermostat
    Howto_barostat
@@ -65,6 +66,7 @@ Force fields howto
    :maxdepth: 1
 
    Howto_bioFF
+   Howto_amoeba
    Howto_tip3p
    Howto_tip4p
    Howto_spc

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:
+
+* `http://openbabel.org/docs/current/FileFormats/Tinker_XYZ_format.html <http://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_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_structured_data.rst

@@ -184,7 +184,7 @@ frame.
 
 .. code-block:: python
 
-   import re, yaml
+   import yaml
    import pandas as pd
 
    try:
@@ -193,7 +193,7 @@ frame.
        from yaml import SafeLoader as Loader
 
    with open("ave.yaml") as f:
-       ave = yaml.load(docs, Loader=Loader)
+       ave = yaml.load(f, Loader=Loader)
 
    keys = ave['keywords']
    df = {}

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

@@ -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/Intro_citing.rst

@@ -33,9 +33,9 @@ initial versions of LAMMPS is:
 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/Manual.rst

@@ -49,12 +49,12 @@ descriptions of all commands included in the LAMMPS code.
 
 ----------
 
+.. _user_documentation:
 
 ************
 User Guide
 ************
 
-.. _user_documentation:
 .. toctree::
    :maxdepth: 2
    :numbered: 3
@@ -75,11 +75,12 @@ User Guide
    Errors
 
 
+.. _programmer_documentation:
+
 ******************
 Programmer Guide
 ******************
 
-.. _programmer_documentation:
 .. toctree::
    :maxdepth: 2
    :numbered: 3
@@ -110,6 +111,7 @@ Command Reference
    angles
    dihedrals
    impropers
+   dumps
    fix_modify_atc_commands
    Bibliography
 

doc/src/Modify_fix.rst

@@ -23,6 +23,8 @@ derived class.  See fix.h for details.
 +---------------------------+--------------------------------------------------------------------------------------------+
 | init                      | initialization before a run (optional)                                                     |
 +---------------------------+--------------------------------------------------------------------------------------------+
+| init_list                 | store pointer to neighbor list; called by neighbor list code (optional)                    |
++---------------------------+--------------------------------------------------------------------------------------------+
 | setup_pre_exchange        | called before atom exchange in setup (optional)                                            |
 +---------------------------+--------------------------------------------------------------------------------------------+
 | setup_pre_force           | called before force computation in setup (optional)                                        |

doc/src/Modify_style.rst

@@ -100,13 +100,14 @@ Documentation (strict)
 
 Contributions that add new styles or commands or augment existing ones
 must include the corresponding new or modified documentation in
-`ReStructuredText format <rst>`_ (.rst files in the ``doc/src/`` folder). The
-documentation shall be written in American English and the .rst file
-must use only ASCII characters so it can be cleanly translated to PDF
-files (via `sphinx <sphinx>`_ and PDFLaTeX).  Special characters may be included via
-embedded math expression typeset in a LaTeX subset.
+`ReStructuredText format <rst_>`_ (.rst files in the ``doc/src/``
+folder). The documentation shall be written in American English and the
+.rst file must use only ASCII characters so it can be cleanly translated
+to PDF files (via `sphinx <https://www.sphinx-doc.org>`_ and PDFLaTeX).
+Special characters may be included via embedded math expression typeset
+in a LaTeX subset.
 
-.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
+.. _rst: https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html
 
 When adding new commands, they need to be integrated into the sphinx
 documentation system, and the corresponding command tables and lists
@@ -133,7 +134,7 @@ error free completion of the HTML and PDF build will be performed and
 also a spell check, a check for correct anchors and labels, and a check
 for completeness of references all styles in their corresponding tables
 and lists is run.  In case the spell check reports false positives they
-can be added to the file doc/utils/sphinx-config/false_positives.txt
+can be added to the file ``doc/utils/sphinx-config/false_positives.txt``
 
 Contributions that add or modify the library interface or "public" APIs
 from the C++ code or the Fortran module must include suitable doxygen

doc/src/Packages_details.rst

@@ -27,6 +27,7 @@ page gives those details.
    :columns: 6
 
    * :ref:`ADIOS <PKG-ADIOS>`
+   * :ref:`AMOEBA <PKG-AMOEBA>`
    * :ref:`ASPHERE <PKG-ASPHERE>`
    * :ref:`ATC <PKG-ATC>`
    * :ref:`AWPMD <PKG-AWPMD>`
@@ -35,7 +36,7 @@ page gives those details.
    * :ref:`BPM <PKG-BPM>`
    * :ref:`BROWNIAN <PKG-BROWNIAN>`
    * :ref:`CG-DNA <PKG-CG-DNA>`
-   * :ref:`CG-SDK <PKG-CG-SDK>`
+   * :ref:`CG-SPICA <PKG-CG-SPICA>`
    * :ref:`CLASS2 <PKG-CLASS2>`
    * :ref:`COLLOID <PKG-COLLOID>`
    * :ref:`COLVARS <PKG-COLVARS>`
@@ -149,6 +150,38 @@ This package has :ref:`specific installation instructions <adios>` on the :doc:`
 
 ----------
 
+.. _PKG-AMOEBA:
+
+AMOEBA package
+---------------
+
+**Contents:**
+
+Implementation of the AMOEBA and HIPPO polarized force fields
+originally 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/>`_.
+
+**Authors:** Josh Rackers and Steve Plimpton (Sandia), Trung Nguyen (U
+ Chicago)
+
+**Supporting info:**
+
+* src/AMOEBA: filenames -> commands
+* :doc:`AMOEBA and HIPPO howto <Howto_amoeba>`
+* :doc:`pair_style amoeba <pair_amoeba>`
+* :doc:`pair_style hippo <pair_amoeba>`
+* :doc:`atom_style amoeba <atom_style>`
+* :doc:`angle_style amoeba <angle_amoeba>`
+* :doc:`improper_style amoeba <improper_amoeba>`
+* :doc:`fix amoeba/bitorsion <fix_amoeba_bitorsion>`
+* :doc:`fix amoeba/pitorsion <fix_amoeba_pitorsion>`
+* tools/tinker/tinker2lmp.py
+* examples/amoeba
+
+----------
+
 .. _PKG-ASPHERE:
 
 ASPHERE package
@@ -181,9 +214,10 @@ ATC package
 
 **Contents:**
 
-ATC stands for atoms-to-continuum.  This package implements a :doc:`fix atc <fix_atc>` command to either couple molecular dynamics with
-continuum finite element equations or perform on-the-fly conversion of
-atomic information to continuum fields.
+ATC stands for atoms-to-continuum.  This package implements a
+:doc:`fix atc <fix_atc>` command to either couple molecular dynamics
+with continuum finite element equations or perform on-the-fly
+conversion of atomic information to continuum fields.
 
 **Authors:** Reese Jones, Jeremy Templeton, Jon Zimmerman (Sandia).
 
@@ -242,7 +276,7 @@ the barostat as outlined in:
 
 N. J. H. Dunn and W. G. Noid, "Bottom-up coarse-grained models that
 accurately describe the structure, pressure, and compressibility of
-molecular liquids," J. Chem. Phys. 143, 243148 (2015).
+molecular liquids", J. Chem. Phys. 143, 243148 (2015).
 
 **Authors:** Nicholas J. H. Dunn and Michael R. DeLyser (The
 Pennsylvania State University)
@@ -298,6 +332,8 @@ models for mesoscale simulations of solids and fracture.  See the
 
 **Authors:** Joel T. Clemmer (Sandia National Labs)
 
+.. versionadded:: 4May2022
+
 **Supporting info:**
 
 * src/BPM filenames -> commands
@@ -365,28 +401,30 @@ The CG-DNA package requires that also the `MOLECULE <PKG-MOLECULE>`_ and
 
 ----------
 
-.. _PKG-CG-SDK:
+.. _PKG-CG-SPICA:
 
-CG-SDK package
+CG-SPICA package
 ------------------
 
 **Contents:**
 
 Several pair styles and an angle style which implement the
-coarse-grained SDK model of Shinoda, DeVane, and Klein which enables
-simulation of ionic liquids, electrolytes, lipids and charged amino
-acids.
+coarse-grained SPICA (formerly called SDK) model which enables
+simulation of biological or soft material systems.
 
-**Author:** Axel Kohlmeyer (Temple U).
+**Original Author:** Axel Kohlmeyer (Temple U).
+
+**Maintainers:** Yusuke Miyazaki and Wataru Shinoda (Okayama U).
 
 **Supporting info:**
 
-* src/CG-SDK: filenames -> commands
-* src/CG-SDK/README
-* :doc:`pair_style lj/sdk/\* <pair_sdk>`
-* :doc:`angle_style sdk <angle_sdk>`
-* examples/PACKAGES/cgsdk
+* src/CG-SPICA: filenames -> commands
+* src/CG-SPICA/README
+* :doc:`pair_style lj/spica/\* <pair_spica>`
+* :doc:`angle_style spica <angle_spica>`
+* examples/PACKAGES/cgspica
 * https://www.lammps.org/pictures.html#cg
+* https://www.spica-ff.org/
 
 ----------
 
@@ -614,7 +652,7 @@ short-range or long-range interactions.
 * :doc:`pair_style lj/cut/dipole/cut <pair_dipole>`
 * :doc:`pair_style lj/cut/dipole/long <pair_dipole>`
 * :doc:`pair_style lj/long/dipole/long <pair_dipole>`
-* :doc: `angle_style dipole <angle_dipole>`
+* :doc:`angle_style dipole <angle_dipole>`
 * examples/dipole
 
 ----------
@@ -657,7 +695,7 @@ advection-diffusion-reaction systems. The equations of motion of these
 DPD extensions are integrated through a modified velocity-Verlet (MVV)
 algorithm.
 
-**Author:** Zhen Li (Division of Applied Mathematics, Brown University)
+**Author:** Zhen Li (Department of Mechanical Engineering, Clemson University)
 
 **Supporting info:**
 
@@ -824,6 +862,8 @@ groups of atoms that interact with the remaining atoms as electrolyte.
 Ahrens-Iwers (TUHH, Hamburg, Germany), Shern Tee (UQ, Brisbane, Australia) and
 Robert Meissner (TUHH, Hamburg, Germany).
 
+.. versionadded:: 4May2022
+
 **Install:**
 
 This package has :ref:`specific installation instructions <electrode>` on the
@@ -892,6 +932,10 @@ EXTRA-MOLECULE package
 
 Additional bond, angle, dihedral, and improper styles that are less commonly used.
 
+**Install:**
+
+To use this package, also the :ref:`MOLECULE <PKG-MOLECULE>` package needs to be installed.
+
 **Supporting info:**
 
 * src/EXTRA-MOLECULE: filenames -> commands
@@ -1364,7 +1408,7 @@ This package has :ref:`specific installation instructions <machdyn>` on the :doc
 
 * src/MACHDYN: filenames -> commands
 * src/MACHDYN/README
-* doc/PDF/MACHDYN_LAMMPS_userguide.pdf
+* `doc/PDF/MACHDYN_LAMMPS_userguide.pdf <PDF/MACHDYN_LAMMPS_userguide.pdf>`_
 * examples/PACKAGES/machdyn
 * https://www.lammps.org/movies.html#smd
 
@@ -1479,7 +1523,7 @@ the :doc:`Build extras <Build_extras>` page.
 * lib/mdi/README
 * :doc:`Howto MDI <Howto_mdi>`
 * :doc:`mdi <mdi>`
-* :doc:`fix mdi/aimd <fix_mdi_aimd>`
+* :doc:`fix mdi/qm <fix_mdi_qm>`
 * examples/PACKAGES/mdi
 
 ----------
@@ -1516,31 +1560,40 @@ MESONT package
 
 **Contents:**
 
-MESONT is a LAMMPS package for simulation of nanomechanics of
-nanotubes (NTs). The model is based on a coarse-grained representation
-of NTs as "flexible cylinders" consisting of a variable number of
+MESONT is a LAMMPS package for simulation of nanomechanics of nanotubes
+(NTs). The model is based on a coarse-grained representation of NTs as
+"flexible cylinders" consisting of a variable number of
 segments. Internal interactions within a NT and the van der Waals
 interaction between the tubes are described by a mesoscopic force field
 designed and parameterized based on the results of atomic-level
 molecular dynamics simulations. The description of the force field is
-provided in the papers listed below. This package contains two
-independent implementations of this model: :doc:`pair_style mesocnt
-<pair_mesocnt>` is a (minimal) C++ implementation, and :doc:`pair_style
-mesont/tpm <pair_mesont_tpm>` is a more general and feature rich
-implementation based on a Fortran library in the ``lib/mesont`` folder.
+provided in the papers listed below.
+
+This package contains two independent implementations of this model:
+:doc:`pair_style mesont/tpm <pair_mesont_tpm>` is the original
+implementation of the model based on a Fortran library in the
+``lib/mesont`` folder. The second implementation is provided by the
+mesocnt styles (:doc:`bond_style mesocnt <bond_mesocnt>`,
+:doc:`angle_style mesocnt <angle_mesocnt>` and :doc:`pair_style mesocnt
+<pair_mesocnt>`).  The mesocnt implementation has the same features as
+the original implementation with the addition of friction, but is
+directly implemented in C++, interfaces more cleanly with general LAMMPS
+functionality, and is typically faster. It also does not require its own
+atom style and can be installed without any external libraries.
 
 **Download of potential files:**
 
-The potential files for these pair styles are *very* large and thus
-are not included in the regular downloaded packages of LAMMPS or the
-git repositories.  Instead, they will be automatically downloaded
-from a web server when the package is installed for the first time.
+The potential files for these pair styles are *very* large and thus are
+not included in the regular downloaded packages of LAMMPS or the git
+repositories.  Instead, they will be automatically downloaded from a web
+server when the package is installed for the first time.
 
 **Authors of the *mesont* styles:**
 
-Maxim V. Shugaev (University of Virginia), Alexey N. Volkov (University of Alabama), Leonid V. Zhigilei (University of Virginia)
+Maxim V. Shugaev (University of Virginia), Alexey N. Volkov (University
+of Alabama), Leonid V. Zhigilei (University of Virginia)
 
-**Author of the *mesocnt* pair style:**
+**Author of the *mesocnt* styles:**
 Philipp Kloza (U Cambridge)
 
 **Supporting info:**
@@ -1550,6 +1603,8 @@ Philipp Kloza (U Cambridge)
 * :doc:`atom_style mesont <atom_style>`
 * :doc:`pair_style mesont/tpm <pair_mesont_tpm>`
 * :doc:`compute mesont <compute_mesont>`
+* :doc:`bond_style mesocnt <bond_mesocnt>`
+* :doc:`angle_style mesocnt <angle_mesocnt>`
 * :doc:`pair_style mesocnt <pair_mesocnt>`
 * examples/PACKAGES/mesont
 * tools/mesont
@@ -1801,6 +1856,8 @@ computes which analyze attributes of the potential.
 * src/ML-SNAP: filenames -> commands
 * :doc:`pair_style snap <pair_snap>`
 * :doc:`compute sna/atom <compute_sna_atom>`
+* :doc:`compute sna/grid <compute_sna_atom>`
+* :doc:`compute sna/grid/local <compute_sna_atom>`
 * :doc:`compute snad/atom <compute_sna_atom>`
 * :doc:`compute snav/atom <compute_sna_atom>`
 * examples/snap
@@ -2650,7 +2707,7 @@ Dynamics, Ernst Mach Institute, Germany).
 
 * src/SPH: filenames -> commands
 * src/SPH/README
-* doc/PDF/SPH_LAMMPS_userguide.pdf
+* `doc/PDF/SPH_LAMMPS_userguide.pdf <PDF/SPH_LAMMPS_userguide.pdf>`_
 * examples/PACKAGES/sph
 * https://www.lammps.org/movies.html#sph
 

doc/src/Packages_list.rst

@@ -33,6 +33,11 @@ whether an extra library is needed to build and use the package:
      - :doc:`dump adios <dump_adios>`
      - PACKAGES/adios
      - ext
+   * - :ref:`AMOEBA <PKG-AMOEBA>`
+     - AMOEBA and HIPPO force fields
+     - :doc:`AMOEBA and HIPPO howto <Howto_amoeba>`
+     - amoeba
+     - no
    * - :ref:`ASPHERE <PKG-ASPHERE>`
      - aspherical particle models
      - :doc:`Howto spherical <Howto_spherical>`
@@ -73,10 +78,10 @@ whether an extra library is needed to build and use the package:
      - src/CG-DNA/README
      - PACKAGES/cgdna
      - no
-   * - :ref:`CG-SDK <PKG-CG-SDK>`
-     - SDK coarse-graining model
-     - :doc:`pair_style lj/sdk <pair_sdk>`
-     - PACKAGES/cgsdk
+   * - :ref:`CG-SPICA <PKG-CG-SPICA>`
+     - SPICA (SDK) coarse-graining model
+     - :doc:`pair_style lj/spica <pair_spica>`
+     - PACKAGES/cgspica
      - no
    * - :ref:`CLASS2 <PKG-CLASS2>`
      - class 2 force fields

doc/src/Run_options.rst

@@ -14,6 +14,7 @@ letter abbreviation can be used:
 * :ref:`-m or -mpicolor <mpicolor>`
 * :ref:`-c or -cite <cite>`
 * :ref:`-nc or -nocite <nocite>`
+* :ref:`-nb or -nonbuf <nonbuf>`
 * :ref:`-pk or -package <package>`
 * :ref:`-p or -partition <partition>`
 * :ref:`-pl or -plog <plog>`
@@ -257,6 +258,24 @@ Disable generating a citation reminder (see above) at all.
 
 ----------
 
+.. _nonbuf:
+
+**-nonbuf**
+
+Turn off buffering for screen and logfile output.  For performance
+reasons, output to the screen and logfile is usually buffered, i.e.
+output is only written to a file if its buffer - typically 4096 bytes -
+has been filled.  When LAMMPS crashes for some reason, however, that can
+mean that there is important output missing.  With this flag the
+buffering can be turned off (only for screen and logfile output) and any
+output will be committed immediately.  Note that when running in
+parallel with MPI, the screen output may still be buffered by the MPI
+library and this cannot be changed by LAMMPS.  This flag should only be
+used for debugging and not for production simulations as the performance
+impact can be significant, especially for large parallel runs.
+
+----------
+
 .. _package:
 
 **-package style args ....**
@@ -476,7 +495,7 @@ run:
    write_dump group-ID dumpstyle dumpfile arg1 arg2 ...
 
 Note that the specified restartfile and dumpfile names may contain
-wild-card characters ("\*","%") as explained on the
+wild-card characters ("\*" or "%") as explained on the
 :doc:`read_restart <read_restart>` and :doc:`write_dump <write_dump>` doc
 pages.  The use of "%" means that a parallel restart file and/or
 parallel dump file can be read and/or written.  Note that a filename

doc/src/Speed_intel.rst

@@ -536,6 +536,6 @@ supported.
 References
 """"""""""
 
-* Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakkar, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., "Optimizing Classical Molecular Dynamics in LAMMPS," in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann.
+* Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakkar, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., "Optimizing Classical Molecular Dynamics in LAMMPS", in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann.
 * Brown, W. M., Semin, A., Hebenstreit, M., Khvostov, S., Raman, K., Plimpton, S.J. `Increasing Molecular Dynamics Simulation Rates with an 8-Fold Increase in Electrical Power Efficiency. <http://dl.acm.org/citation.cfm?id=3014915>`_ 2016 High Performance Computing, Networking, Storage and Analysis, SC16: International Conference (pp. 82-95).
 * Brown, W.M., Carrillo, J.-M.Y., Gavhane, N., Thakkar, F.M., Plimpton, S.J. Optimizing Legacy Molecular Dynamics Software with Directive-Based Offload. Computer Physics Communications. 2015. 195: p. 95-101.

doc/src/Speed_measure.rst

@@ -42,5 +42,4 @@ inaccurate relative timing data, because processors have to wait when
 communication occurs for other processors to catch up.  Thus the
 reported times for "Communication" or "Other" may be higher than they
 really are, due to load-imbalance.  If this is an issue, you can
-uncomment the MPI_Barrier() lines in src/timer.cpp, and re-compile
-LAMMPS, to obtain synchronized timings.
+use the :doc:`timer sync <timer>` command to obtain synchronized timings.

doc/src/Tools.rst

@@ -95,7 +95,7 @@ Miscellaneous tools
    * :ref:`LAMMPS shell <lammps_shell>`
    * :ref:`LAMMPS magic patterns for file(1) <magic>`
    * :ref:`Offline build tool <offline>`
-   * :ref:`singularity <singularity_tool>`
+   * :ref:`singularity/apptainer <singularity_tool>`
    * :ref:`SWIG interface <swig>`
    * :ref:`vim <vim>`
 
@@ -1007,14 +1007,15 @@ Ivanov, at University of Iceland (ali5 at hi.is).
 
 .. _singularity_tool:
 
-singularity tool
-----------------------------------------
+singularity/apptainer tool
+--------------------------
 
-The singularity sub-directory contains container definitions files
-that can be used to build container images for building and testing
-LAMMPS on specific OS variants using the `Singularity <https://sylabs.io>`_
-container software. Contributions for additional variants are welcome.
-For more details please see the README.md file in that folder.
+The singularity sub-directory contains container definitions files that
+can be used to build container images for building and testing LAMMPS on
+specific OS variants using the `Apptainer <https://apptainer.org>`_ or
+`Singularity <https://sylabs.io>`_ container software. Contributions for
+additional variants are welcome.  For more details please see the
+README.md file in that folder.
 
 ----------
 

doc/src/accel_styles.rst

@@ -6,7 +6,7 @@ page.  The accelerated styles take the same arguments and should
 produce the same results, except for round-off and precision issues.
 
 These accelerated styles are part of the GPU, INTEL, KOKKOS,
-OPENMP and OPT packages, respectively.  They are only enabled if
+OPENMP, and OPT packages, respectively.  They are only enabled if
 LAMMPS was built with those packages.  See the :doc:`Build package <Build_package>` page for more info.
 
 You can specify the accelerated styles explicitly in your input script

doc/src/angle_amoeba.rst

@@ -0,0 +1,138 @@
+.. index:: angle_style amoeba
+
+angle_style amoeba command
+==========================
+
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   angle_style amoeba
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   angle_style amoeba
+   angle_coeff * 75.0 -25.0 1.0 0.3 0.02 0.003
+   angle_coeff * ba 3.6551 24.895 1.0119 1.5228
+   angle_coeff * ub -7.6 1.5537
+
+Description
+"""""""""""
+
+The *amoeba* angle style uses the potential
+
+.. math::
+
+   E & = E_a + E_{ba} + E_{ub} \\
+   E_a & = K_2\left(\theta - \theta_0\right)^2 + K_3\left(\theta - \theta_0\right)^3 + K_4\left(\theta - \theta_0\right)^4 + K_5\left(\theta - \theta_0\right)^5 + K_6\left(\theta - \theta_0\right)^6 \\
+   E_{ba} & = N_1 (r_{ij} - r_1) (\theta - \theta_0) + N_2(r_{jk} - r_2)(\theta - \theta_0) \\
+   E_{UB} & = K_{ub} (r_{ik} - r_{ub})^2
+
+where :math:`E_a` is the angle term, :math:`E_{ba}` is a bond-angle
+term, :math:`E_{UB}` is a Urey-Bradley bond term, :math:`\theta_0` is
+the equilibrium angle, :math:`r_1` and :math:`r_2` are the equilibrium
+bond lengths, and :math:`r_{ub}` is the equilibrium Urey-Bradley bond
+length.
+
+These formulas match how the Tinker MD code performs its angle
+calculations for the AMOEBA and HIPPO force fields.  See the
+:doc:`Howto amoeba <Howto_amoeba>` page for more information about
+the implementation of AMOEBA and HIPPO in LAMMPS.
+
+Note that the :math:`E_a` and :math:`E_{ba}` formulas are identical to
+those used for the :doc:`angle_style class2/p6 <angle_class2>`
+command, however there is no bond-bond cross term formula for
+:math:`E_{bb}`.  Additionally, there is a :math:`E_{UB}` term for a
+Urey-Bradley bond.  It is effectively a harmonic bond between the I
+and K atoms of angle IJK, even though that bond is not enumerated in
+the "Bonds" section of the data file.
+
+There are also two ways that Tinker computes the angle :math:`\theta`
+in the :math:`E_a` formula.  The first is the standard way of treating
+IJK as an "in-plane" angle.  The second is an "out-of-plane" method
+which Tinker may use if the center atom J in the angle is bonded to
+one additional atom in addition to I and K.  In this case, all 4 atoms
+are used to compute the :math:`E_a` formula, resulting in forces on
+all 4 atoms.  In the Tinker PRM file, these 2 options are denoted by
+*angle* versus *anglep* entries in the "Angle Bending Parameters"
+section of the PRM force field file.  The *pflag* coefficient
+described below selects between the 2 options.
+
+----------
+
+
+Coefficients for the :math:`E_a`, :math:`E_{bb}`, and :math:`E_{ub}`
+formulas must be defined for each angle type via the :doc:`angle_coeff
+<angle_coeff>` command as in the example above, or in the data file or
+restart files read by the :doc:`read_data <read_data>` or
+:doc:`read_restart <read_restart>` commands.
+
+These are the 8 coefficients for the :math:`E_a` formula:
+
+* pflag = 0 or 1
+* ubflag = 0 or 1
+* :math:`\theta_0` (degrees)
+* :math:`K_2` (energy)
+* :math:`K_3` (energy)
+* :math:`K_4` (energy)
+* :math:`K_5` (energy)
+* :math:`K_6` (energy)
+
+A pflag value of 0 vs 1 selects between the "in-plane" and
+"out-of-plane" options described above.  Ubflag is 1 if there is a
+Urey-Bradley term associated with this angle type, else it is 0.
+:math:`\theta_0` is specified in degrees, but LAMMPS converts it to
+radians internally; hence the various :math:`K` values are effectively
+energy per radian\^2 or radian\^3 or radian\^4 or radian\^5 or
+radian\^6.
+
+For the :math:`E_{ba}` formula, each line in a :doc:`angle_coeff
+<angle_coeff>` command in the input script lists 5 coefficients, the
+first of which is "ba" to indicate they are BondAngle coefficients.
+In a data file, these coefficients should be listed under a "BondAngle
+Coeffs" heading and you must leave out the "ba", i.e. only list 4
+coefficients after the angle type.
+
+* ba
+* :math:`N_1` (energy/distance\^2)
+* :math:`N_2` (energy/distance\^2)
+* :math:`r_1` (distance)
+* :math:`r_2` (distance)
+
+The :math:`\theta_0` value in the :math:`E_{ba}` formula is not specified,
+since it is the same value from the :math:`E_a` formula.
+
+For the :math:`E_{ub}` formula, each line in a :doc:`angle_coeff
+<angle_coeff>` command in the input script lists 3 coefficients, the
+first of which is "ub" to indicate they are UreyBradley coefficients.
+In a data file, these coefficients should be listed under a
+"UreyBradley Coeffs" heading and you must leave out the "ub",
+i.e. only list 2 coefficients after the angle type.
+
+* ub
+* :math:`K_{ub}` (energy/distance\^2)
+* :math:`r_{ub}` (distance)
+
+----------
+
+Restrictions
+""""""""""""
+
+This angle style can only be used if LAMMPS was built with the AMOEBA
+package.  See the :doc:`Build package <Build_package>` doc page for
+more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`angle_coeff <angle_coeff>`
+
+Default
+"""""""
+
+none

doc/src/angle_class2.rst

@@ -24,7 +24,7 @@ Examples
 .. code-block:: LAMMPS
 
    angle_style class2
-   angle_coeff * 75.0
+   angle_coeff * 75.0 25.0 0.3 0.002
    angle_coeff 1 bb 10.5872 1.0119 1.5228
    angle_coeff * ba 3.6551 24.895 1.0119 1.5228
 

doc/src/angle_coeff.rst

@@ -10,7 +10,7 @@ Syntax
 
    angle_coeff N args
 
-* N = angle type (see asterisk form below)
+* N = numeric angle type (see asterisk form below), or type label
 * args = coefficients for one or more angle types
 
 Examples
@@ -22,6 +22,9 @@ Examples
    angle_coeff * 5.0
    angle_coeff 2*10 5.0
 
+   labelmap angle 1 hydroxyl
+   angle_coeff hydroxyl 300.0 107.0
+
 Description
 """""""""""
 
@@ -30,18 +33,24 @@ The number and meaning of the coefficients depends on the angle style.
 Angle coefficients can also be set in the data file read by the
 :doc:`read_data <read_data>` command or in a restart file.
 
-N can be specified in one of two ways.  An explicit numeric value can
-be used, as in the first example above.  Or a wild-card asterisk can be
-used to set the coefficients for multiple angle types.  This takes the
-form "\*" or "\*n" or "n\*" or "m\*n".  If N = the number of angle types,
-then an asterisk with no numeric values means all types from 1 to N.  A
-leading asterisk means all types from 1 to n (inclusive).  A trailing
-asterisk means all types from n to N (inclusive).  A middle asterisk
-means all types from m to n (inclusive).
+:math:`N` can be specified in one of two ways.  An explicit numeric
+value can be used, as in the first example above.  Or :math:`N` can be a
+type label, which is an alphanumeric string defined by the
+:doc:`labelmap <labelmap>` command or in a section of a data file read
+by the :doc:`read_data <read_data>` command.
 
-Note that using an :doc:`angle_coeff <angle_coeff>` command can override a previous setting
-for the same angle type.  For example, these commands set the coeffs
-for all angle types, then overwrite the coeffs for just angle type 2:
+For numeric values only, a wild-card asterisk can be used to set the
+coefficients for multiple angle types.  This takes the form "\*" or
+"\*n" or "n\*" or "m\*n".  If :math:`N` is the number of angle types,
+then an asterisk with no numeric values means all types from 1 to
+:math:`N`.  A leading asterisk means all types from 1 to n (inclusive).
+A trailing asterisk means all types from n to :math:`N` (inclusive).  A
+middle asterisk means all types from m to n (inclusive).
+
+Note that using an :doc:`angle_coeff <angle_coeff>` command can
+override a previous setting for the same angle type.  For example,
+these commands set the coeffs for all angle types, then overwrite the
+coeffs for just angle type 2:
 
 .. code-block:: LAMMPS
 
@@ -49,11 +58,11 @@ for all angle types, then overwrite the coeffs for just angle type 2:
    angle_coeff 2 50.0 107.0
 
 A line in a data file that specifies angle coefficients uses the exact
-same format as the arguments of the :doc:`angle_coeff <angle_coeff>` command in an input
-script, except that wild-card asterisks should not be used since
-coefficients for all N types must be listed in the file.  For example,
-under the "Angle Coeffs" section of a data file, the line that
-corresponds to the first example above would be listed as
+same format as the arguments of the :doc:`angle_coeff <angle_coeff>`
+command in an input script, except that wild-card asterisks should not
+be used since coefficients for all :math:`N` types must be listed in the
+file.  For example, under the "Angle Coeffs" section of a data file, the
+line that corresponds to the first example above would be listed as
 
 .. parsed-literal::
 
@@ -61,15 +70,14 @@ corresponds to the first example above would be listed as
 
 The :doc:`angle_style class2 <angle_class2>` is an exception to this
 rule, in that an additional argument is used in the input script to
-allow specification of the cross-term coefficients.   See its
-doc page for details.
+allow specification of the cross-term coefficients.  See its doc page
+for details.
 
 ----------
 
 The list of all angle styles defined in LAMMPS is given on the
 :doc:`angle_style <angle_style>` doc page.  They are also listed in more
-compact form on the :ref:`Commands angle <angle>` doc
-page.
+compact form on the :ref:`Commands angle <angle>` doc page.
 
 On either of those pages, click on the style to display the formula it
 computes and its coefficients as specified by the associated

doc/src/angle_mesocnt.rst

@@ -0,0 +1,146 @@
+.. index:: angle_style mesocnt
+
+angle_style mesocnt command
+===========================
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   angle_style mesocnt
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   angle_style mesocnt
+   angle_coeff 1 buckling C 10 10 20.0
+   angle_coeff 4 harmonic C 8 4 10.0
+   angle_coeff 2 buckling custom 400.0 50.0 5.0
+   angle_coeff 1 harmonic custom 300.0
+
+Description
+"""""""""""
+
+.. versionadded:: 15Sep2022
+
+The *mesocnt* angle style uses the potential
+
+.. math::
+
+   E = K_\text{H} \Delta \theta^2, \qquad |\Delta \theta| < \Delta
+   \theta_\text{B} \\
+   E = K_\text{H} \Delta \theta_\text{B}^2 +
+   K_\text{B} (\Delta \theta - \Delta \theta_\text{B}), \qquad |\Delta
+   \theta| \geq \Delta \theta_\text{B}
+
+where :math:`\Delta \theta = \theta - \pi` is the bending angle of the
+nanotube, :math:`K_\text{H}` and :math:`K_\text{B}` are prefactors for
+the harmonic and linear regime respectively and :math:`\Delta
+\theta_\text{B}` is the buckling angle. Note that the usual 1/2 factor
+for the harmonic potential is included in :math:`K_\text{H}`.
+
+The style implements parameterization presets of :math:`K_\text{H}`,
+:math:`K_\text{B}` and :math:`\Delta \theta_\text{B}` for mesoscopic
+simulations of carbon nanotubes based on the atomistic simulations of
+:ref:`(Srivastava) <Srivastava_2>` and buckling considerations of
+:ref:`(Zhigilei) <Zhigilei1_1>`.
+
+The following coefficients must be defined for each angle type via the
+:doc:`angle_coeff <angle_coeff>` command as in the examples above, or
+in the data file or restart files read by the :doc:`read_data
+<read_data>` or :doc:`read_restart <read_restart>` commands:
+
+* mode = *buckling* or *harmonic*
+* preset = *C* or *custom*
+* additional parameters depending on preset
+
+If mode *harmonic* is chosen, the potential is simply harmonic and
+does not switch to the linear term when the buckling angle is
+reached. In *buckling* mode, the full piecewise potential is used.
+
+Preset *C* is for carbon nanotubes, and the additional parameters are:
+
+* chiral index :math:`n` (unitless)
+* chiral index :math:`m` (unitless)
+* :math:`r_0` (distance)
+
+Here, :math:`r_0` is the equilibrium distance of the bonds included in
+the angle, see :doc:`bond_style mesocnt <bond_mesocnt>`.
+
+In harmonic mode with preset *custom*, the additional parameter is:
+
+* :math:`K_\text{H}` (energy)
+
+Hence, this setting is simply a wrapper for :doc:`bond_style harmonic
+<bond_harmonic>` with an equilibrium angle of 180 degrees.
+
+In harmonic mode with preset *custom*, the additional parameters are:
+
+* :math:`K_\text{H}` (energy)
+* :math:`K_\text{B}` (energy)
+* :math:`\Delta \theta_\text{B}` (degrees)
+
+:math:`\Delta \theta_\text{B}` is specified in degrees, but LAMMPS
+converts it to radians internally; hence :math:`K_\text{H}` is
+effectively energy per radian\^2 and :math:`K_\text{B}` is energy per
+radian.
+
+----------
+
+In *buckling* mode, this angle style adds the *buckled* property to
+all atoms in the simulation, which is an integer flag indicating
+whether the bending angle at a given atom has exceeded :math:`\Delta
+\theta_\text{B}`. It can be accessed as an atomic variable, e.g. for
+custom dump commands, as *i_buckled*.
+
+.. note::
+
+   If the initial state of the simulation contains buckled nanotubes
+   and :doc:`pair_style mesocnt <pair_mesocnt>` is used, the
+   *i_buckled* atomic variable needs to be initialized before the
+   pair_style is defined by doing a *run 0* command straight after the
+   angle_style command. See below for an example.
+
+If CNTs are already buckled at the start of the simulation, this
+script will correctly initialize *i_buckled*:
+
+.. code-block:: LAMMPS
+
+   angle_style mesocnt
+   angle_coeff 1 buckling C 10 10 20.0
+
+   run 0
+
+   pair_style mesocnt 60.0
+   pair_coeff * * C_10_10.mesocnt 1
+
+Restrictions
+""""""""""""
+
+This angle style can only be used if LAMMPS was built with the
+MOLECULE and MESONT packages.  See the :doc:`Build package
+<Build_package>` doc page for more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`angle_coeff <angle_coeff>`
+
+Default
+"""""""
+
+none
+
+----------
+
+.. _Srivastava_2:
+
+**(Srivastava)** Zhigilei, Wei, Srivastava, Phys. Rev. B 71, 165417
+(2005).
+
+.. _Zhigilei1_1:
+
+**(Zhigilei)** Volkov and Zhigilei, ACS Nano 4, 6187 (2010).

doc/src/angle_spica.rst

@@ -1,32 +1,32 @@
-.. index:: angle_style sdk
-.. index:: angle_style sdk/omp
+.. index:: angle_style spica
+.. index:: angle_style spica/omp
 
-angle_style sdk command
-=======================
+angle_style spica command
+=========================
 
-Accelerator Variants: *sdk/omp*
+Accelerator Variants: *spica/omp*
 
 Syntax
 """"""
 
 .. code-block:: LAMMPS
 
-   angle_style sdk
+   angle_style spica
 
-   angle_style sdk/omp
+   angle_style spica/omp
 
 Examples
 """"""""
 
 .. code-block:: LAMMPS
 
-   angle_style sdk
+   angle_style spica
    angle_coeff 1 300.0 107.0
 
 Description
 """""""""""
 
-The *sdk* angle style is a combination of the harmonic angle potential,
+The *spica* angle style is a combination of the harmonic angle potential,
 
 .. math::
 
@@ -34,10 +34,10 @@ The *sdk* angle style is a combination of the harmonic angle potential,
 
 where :math:`\theta_0` is the equilibrium value of the angle and
 :math:`K` a prefactor, with the *repulsive* part of the non-bonded
-*lj/sdk* pair style between the atoms 1 and 3.  This angle potential is
-intended for coarse grained MD simulations with the CMM parameterization
-using the :doc:`pair_style lj/sdk <pair_sdk>`.  Relative to the
-pair_style *lj/sdk*, however, the energy is shifted by
+*lj/spica* pair style between the atoms 1 and 3.  This angle potential is
+intended for coarse grained MD simulations with the SPICA (formerly called SDK) parameterization
+using the :doc:`pair_style lj/spica <pair_spica>`.  Relative to the
+pair_style *lj/spica*, however, the energy is shifted by
 :math:`\epsilon`, to avoid sudden jumps.  Note that the usual 1/2 factor
 is included in :math:`K`.
 
@@ -51,9 +51,12 @@ The following coefficients must be defined for each angle type via the
 radians internally; hence :math:`K` is effectively energy per
 radian\^2.
 
-The required *lj/sdk* parameters are extracted automatically from the
+The required *lj/spica* parameters are extracted automatically from the
 pair_style.
 
+Style *sdk*, the original implementation of style *spica*, is available
+for backward compatibility.
+
 ----------
 
 .. include:: accel_styles.rst
@@ -64,14 +67,14 @@ Restrictions
 """"""""""""
 
 This angle style can only be used if LAMMPS was built with the
-CG-SDK package.  See the :doc:`Build package <Build_package>` doc
+CG-SPICA package.  See the :doc:`Build package <Build_package>` doc
 page for more info.
 
 Related commands
 """"""""""""""""
 
-:doc:`angle_coeff <angle_coeff>`, :doc:`angle_style harmonic <angle_harmonic>`, :doc:`pair_style lj/sdk <pair_sdk>`,
-:doc:`pair_style lj/sdk/coul/long <pair_sdk>`
+:doc:`angle_coeff <angle_coeff>`, :doc:`angle_style harmonic <angle_harmonic>`, :doc:`pair_style lj/spica <pair_spica>`,
+:doc:`pair_style lj/spica/coul/long <pair_spica>`
 
 Default
 """""""

doc/src/angle_style.rst

@@ -10,7 +10,7 @@ Syntax
 
    angle_style style
 
-* style = *none* or *hybrid* or *charmm* or *class2* or *cosine* or         *cosine/squared* or *harmonic*
+* style = *none* or *zero* or *hybrid* or *amoeba* or *charmm* or *class2* or *class2/p6* or *cosine* or *cosine/buck6d* or *cosine/delta* or *cosine/periodic* or *cosine/shift* or *cosine/shift/exp* or *cosine/squared* or *cross* or *dipole* or *fourier* or *fourier/simple* or *gaussian* or *harmonic* or *mm3* or *quartic* or *spica* or *table*
 
 Examples
 """"""""
@@ -73,6 +73,7 @@ of (g,i,k,o,t) to indicate which accelerated styles exist.
 * :doc:`zero <angle_zero>` - topology but no interactions
 * :doc:`hybrid <angle_hybrid>` - define multiple styles of angle interactions
 
+* :doc:`amoeba <angle_amoeba>` - AMOEBA angle
 * :doc:`charmm <angle_charmm>` - CHARMM angle
 * :doc:`class2 <angle_class2>` - COMPASS (class 2) angle
 * :doc:`class2/p6 <angle_class2>` - COMPASS (class 2) angle expanded to 6th order
@@ -89,9 +90,10 @@ of (g,i,k,o,t) to indicate which accelerated styles exist.
 * :doc:`fourier/simple <angle_fourier_simple>` - angle with a single cosine term
 * :doc:`gaussian <angle_gaussian>` - multi-centered Gaussian-based angle potential
 * :doc:`harmonic <angle_harmonic>` - harmonic angle
+* :doc:`mesocnt <angle_mesocnt>` - piecewise harmonic and linear angle for bending-buckling of nanotubes
 * :doc:`mm3 <angle_mm3>` - anharmonic angle
 * :doc:`quartic <angle_quartic>` - angle with cubic and quartic terms
-* :doc:`sdk <angle_sdk>` - harmonic angle with repulsive SDK pair style between 1-3 atoms
+* :doc:`spica <angle_spica>` - harmonic angle with repulsive SPICA pair style between 1-3 atoms
 * :doc:`table <angle_table>` - tabulated by angle
 
 ----------

doc/src/angle_zero.rst

@@ -8,7 +8,10 @@ Syntax
 
 .. code-block:: LAMMPS
 
-   angle_style zero *nocoeff*
+   angle_style zero keyword
+
+* zero or more keywords may be appended
+* keyword = *nocoeff*
 
 Examples
 """"""""

doc/src/atom_style.rst

@@ -10,7 +10,7 @@ Syntax
 
    atom_style style args
 
-* style = *angle* or *atomic* or *body* or *bond* or *charge* or *dipole* or  *dpd* or *edpd* or *electron* or *ellipsoid* or *full* or *line* or *mdpd* or *molecular* or *oxdna* or *peri* or *smd* or *sph* or *sphere* or *bpm/sphere* or *spin* or *tdpd* or *tri* or *template* or *hybrid*
+* style = *amoeba* or *angle* or *atomic* or *body* or *bond* or *charge* or *dielectric* or *dipole* or  *dpd* or *edpd* or *electron* or *ellipsoid* or *full* or *line* or *mdpd* or *mesont* or *molecular* or *oxdna* or *peri* or *smd* or *sph* or *sphere* or *bpm/sphere* or *spin* or *tdpd* or *tri* or *template* or *wavepacket* or *hybrid*
 
   .. parsed-literal::
 
@@ -78,6 +78,8 @@ coordinates, velocities, atom IDs and types.  See the
 :doc:`set <set>` commands for info on how to set these various
 quantities.
 
++--------------+-----------------------------------------------------+--------------------------------------+
+| *amoeba*     | molecular + charge + 1/5 neighbors                  | AMOEBA/HIPPO polarized force fields  |
 +--------------+-----------------------------------------------------+--------------------------------------+
 | *angle*      | bonds and angles                                    | bead-spring polymers with stiffness  |
 +--------------+-----------------------------------------------------+--------------------------------------+
@@ -137,11 +139,13 @@ quantities.
 .. note::
 
    It is possible to add some attributes, such as a molecule ID, to
-   atom styles that do not have them via the :doc:`fix property/atom <fix_property_atom>` command.  This command also
-   allows new custom attributes consisting of extra integer or
-   floating-point values to be added to atoms.  See the :doc:`fix property/atom <fix_property_atom>` page for examples of cases
-   where this is useful and details on how to initialize, access, and
-   output the custom values.
+   atom styles that do not have them via the :doc:`fix property/atom
+   <fix_property_atom>` command.  This command also allows new custom
+   attributes consisting of extra integer or floating-point values to
+   be added to atoms.  See the :doc:`fix property/atom
+   <fix_property_atom>` page for examples of cases where this is
+   useful and details on how to initialize, access, and output the
+   custom values.
 
 All of the above styles define point particles, except the *sphere*,
 *bpm/sphere*, *ellipsoid*, *electron*, *peri*, *wavepacket*, *line*,
@@ -154,19 +158,20 @@ per-type basis, using the :doc:`mass <mass>` command, The finite-size
 particle styles assign mass to individual particles on a per-particle
 basis.
 
-For the *sphere* and *bpm/sphere* styles, the particles are spheres and each stores a
-per-particle diameter and mass.  If the diameter > 0.0, the particle
-is a finite-size sphere.  If the diameter = 0.0, it is a point
-particle.  Note that by use of the *disc* keyword with the :doc:`fix
-nve/sphere <fix_nve_sphere>`, :doc:`fix nvt/sphere <fix_nvt_sphere>`,
-:doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix npt/sphere
-<fix_npt_sphere>` commands for the *sphere* style, spheres can be effectively treated as 2d
-discs for a 2d simulation if desired.  See also the :doc:`set
-density/disc <set>` command.  The *sphere* and *bpm/sphere* styles take an optional 0
-or 1 argument.  A value of 0 means the radius of each sphere is
-constant for the duration of the simulation.  A value of 1 means the
-radii may vary dynamically during the simulation, e.g. due to use of
-the :doc:`fix adapt <fix_adapt>` command.
+For the *sphere* and *bpm/sphere* styles, the particles are spheres
+and each stores a per-particle diameter and mass.  If the diameter >
+0.0, the particle is a finite-size sphere.  If the diameter = 0.0, it
+is a point particle.  Note that by use of the *disc* keyword with the
+:doc:`fix nve/sphere <fix_nve_sphere>`, :doc:`fix nvt/sphere
+<fix_nvt_sphere>`, :doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix
+npt/sphere <fix_npt_sphere>` commands for the *sphere* style, spheres
+can be effectively treated as 2d discs for a 2d simulation if desired.
+See also the :doc:`set density/disc <set>` command.  The *sphere* and
+*bpm/sphere* styles take an optional 0 or 1 argument.  A value of 0
+means the radius of each sphere is constant for the duration of the
+simulation.  A value of 1 means the radii may vary dynamically during
+the simulation, e.g. due to use of the :doc:`fix adapt <fix_adapt>`
+command.
 
 For the *ellipsoid* style, the particles are ellipsoids and each
 stores a flag which indicates whether it is a finite-size ellipsoid or
@@ -175,15 +180,16 @@ vector with the 3 diameters of the ellipsoid and a quaternion 4-vector
 with its orientation.
 
 For the *dielectric* style, each particle can be either a physical
-particle (e.g. an ion), or an interface particle representing a boundary
-element. For physical particles, the per-particle properties are
-the same as atom_style full.  For interface particles, in addition to
-these properties, each particle also has an area, a normal unit vector,
-a mean local curvature, the mean and difference of the dielectric constants
-of two sides of the interface, and the local dielectric constant at the
-boundary element.  The distinction between the physical and interface
-particles is only meaningful when :doc:`fix polarize <fix_polarize>`
-commands are applied to the interface particles.
+particle (e.g. an ion), or an interface particle representing a
+boundary element. For physical particles, the per-particle properties
+are the same as atom_style full.  For interface particles, in addition
+to these properties, each particle also has an area, a normal unit
+vector, a mean local curvature, the mean and difference of the
+dielectric constants of two sides of the interface, and the local
+dielectric constant at the boundary element.  The distinction between
+the physical and interface particles is only meaningful when :doc:`fix
+polarize <fix_polarize>` commands are applied to the interface
+particles.
 
 For the *dipole* style, a point dipole is defined for each point
 particle.  Note that if you wish the particles to be finite-size
@@ -272,16 +278,17 @@ showing the use of the *template* atom style versus *molecular*.
 
 .. note::
 
-   When using the *template* style with a :doc:`molecule template <molecule>` that contains multiple molecules, you should
-   insure the atom types, bond types, angle_types, etc in all the
-   molecules are consistent.  E.g. if one molecule represents H2O and
-   another CO2, then you probably do not want each molecule file to
-   define 2 atom types and a single bond type, because they will conflict
-   with each other when a mixture system of H2O and CO2 molecules is
-   defined, e.g. by the :doc:`read_data <read_data>` command.  Rather the
-   H2O molecule should define atom types 1 and 2, and bond type 1.  And
-   the CO2 molecule should define atom types 3 and 4 (or atom types 3 and
-   2 if a single oxygen type is desired), and bond type 2.
+   When using the *template* style with a :doc:`molecule template
+   <molecule>` that contains multiple molecules, you should insure the
+   atom types, bond types, angle_types, etc in all the molecules are
+   consistent.  E.g. if one molecule represents H2O and another CO2,
+   then you probably do not want each molecule file to define 2 atom
+   types and a single bond type, because they will conflict with each
+   other when a mixture system of H2O and CO2 molecules is defined,
+   e.g. by the :doc:`read_data <read_data>` command.  Rather the H2O
+   molecule should define atom types 1 and 2, and bond type 1.  And
+   the CO2 molecule should define atom types 3 and 4 (or atom types 3
+   and 2 if a single oxygen type is desired), and bond type 2.
 
 For the *body* style, the particles are arbitrary bodies with internal
 attributes defined by the "style" of the bodies, which is specified by
@@ -339,6 +346,8 @@ Many of the styles listed above are only enabled if LAMMPS was built
 with a specific package, as listed below.  See the :doc:`Build package
 <Build_package>` page for more info.
 
+The *amoeba* style is part of the AMOEBA package.
+
 The *angle*, *bond*, *full*, *molecular*, and *template* styles are
 part of the MOLECULE package.
 
@@ -350,9 +359,11 @@ The *dipole* style is part of the DIPOLE package.
 
 The *peri* style is part of the PERI package for Peridynamics.
 
-The *oxdna* style is part of the CG-DNA package for coarse-grained simulation of DNA and RNA.
+The *oxdna* style is part of the CG-DNA package for coarse-grained
+simulation of DNA and RNA.
 
-The *electron* style is part of the EFF package for :doc:`electronic force fields <pair_eff>`.
+The *electron* style is part of the EFF package for :doc:`electronic
+force fields <pair_eff>`.
 
 The *dpd* style is part of the DPD-REACT package for dissipative
 particle dynamics (DPD).
@@ -363,7 +374,8 @@ dissipative particle dynamics (mDPD), and transport dissipative particle
 dynamics (tDPD), respectively.
 
 The *sph* style is part of the SPH package for smoothed particle
-hydrodynamics (SPH).  See `this PDF guide <PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
+hydrodynamics (SPH).  See `this PDF guide
+<PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
 
 The *mesont* style is part of the MESONT package.
 

doc/src/balance.rst

@@ -6,7 +6,7 @@ balance command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    balance thresh style args ... keyword args ...
 

doc/src/bond_bpm_rotational.rst

@@ -38,8 +38,7 @@ Examples
    bond_style bpm/rotational
    bond_coeff 1 1.0 0.2 0.02 0.02 0.20 0.04 0.04 0.04 0.1 0.02 0.002 0.002
 
-   bond_style bpm/rotational myfix 1000 time id1 id2
-   fix myfix all store/local 1000 3
+   bond_style bpm/rotational store/local myfix 1000 time id1 id2
    dump 1 all local 1000 dump.broken f_myfix[1] f_myfix[2] f_myfix[3]
    dump_modify 1 write_header no
 

doc/src/bond_coeff.rst

@@ -10,7 +10,7 @@ Syntax
 
    bond_coeff N args
 
-* N = bond type (see asterisk form below)
+* N = numeric bond type (see asterisk form below), or type label
 * args = coefficients for one or more bond types
 
 Examples
@@ -21,7 +21,10 @@ Examples
    bond_coeff 5 80.0 1.2
    bond_coeff * 30.0 1.5 1.0 1.0
    bond_coeff 1*4 30.0 1.5 1.0 1.0
-   bond_coeff 1 harmonic 200.0 1.0
+   bond_coeff 1 harmonic 200.0 1.0 (for bond_style hybrid)
+
+   labelmap bond 5 carbonyl
+   bond_coeff carbonyl 80.0 1.2
 
 Description
 """""""""""
@@ -31,14 +34,19 @@ The number and meaning of the coefficients depends on the bond style.
 Bond coefficients can also be set in the data file read by the
 :doc:`read_data <read_data>` command or in a restart file.
 
-N can be specified in one of two ways.  An explicit numeric value can
-be used, as in the first example above.  Or a wild-card asterisk can be
-used to set the coefficients for multiple bond types.  This takes the
-form "\*" or "\*n" or "n\*" or "m\*n".  If N = the number of bond types,
-then an asterisk with no numeric values means all types from 1 to N.  A
+:math:`N` can be specified in one of several ways.  An explicit numeric
+value can be used, as in the first example above.  Or :math:`N` can be a
+type label, which is an alphanumeric string defined by the
+:doc:`labelmap <labelmap>` command or in a section of a data file read
+by the :doc:`read_data <read_data>` command.
+
+For numeric values only, a wild-card asterisk can be used to set the
+coefficients for multiple bond types.  This takes the form "\*" or "\*n"
+or "n\*" or "m\*n".  If :math:`N` is the number of bond types, then an
+asterisk with no numeric values means all types from 1 to :math:`N`.  A
 leading asterisk means all types from 1 to n (inclusive).  A trailing
-asterisk means all types from n to N (inclusive).  A middle asterisk
-means all types from m to n (inclusive).
+asterisk means all types from n to :math:`N` (inclusive).  A middle
+asterisk means all types from m to n (inclusive).
 
 Note that using a bond_coeff command can override a previous setting
 for the same bond type.  For example, these commands set the coeffs
@@ -52,8 +60,8 @@ for all bond types, then overwrite the coeffs for just bond type 2:
 A line in a data file that specifies bond coefficients uses the exact
 same format as the arguments of the bond_coeff command in an input
 script, except that wild-card asterisks should not be used since
-coefficients for all N types must be listed in the file.  For example,
-under the "Bond Coeffs" section of a data file, the line that
+coefficients for all :math:`N` types must be listed in the file.  For
+example, under the "Bond Coeffs" section of a data file, the line that
 corresponds to the first example above would be listed as
 
 .. parsed-literal::

doc/src/bond_mesocnt.rst

@@ -0,0 +1,84 @@
+.. index:: bond_style mesocnt
+
+bond_style mesocnt command
+===========================
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   bond_style mesocnt
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   bond_style mesocnt
+   bond_coeff 1 C 10 10 20.0
+   bond_coeff 4 custom 800.0 10.0
+
+Description
+"""""""""""
+
+.. versionadded:: 15Sep2022
+
+The *mesocnt* bond style is a wrapper for the :doc:`harmonic
+<bond_harmonic>` style, and uses the potential
+
+.. math::
+
+   E = K (r - r_0)^2
+
+where :math:`r_0` is the equilibrium bond distance.  Note that the
+usual 1/2 factor is included in :math:`K`.  The style implements
+parameterization presets of :math:`K` for mesoscopic simulations of
+carbon nanotubes based on the atomistic simulations of
+:ref:`(Srivastava) <Srivastava_1>`.
+
+Other presets can be readily implemented in the future.
+
+The following coefficients must be defined for each bond type via the
+:doc:`bond_coeff <bond_coeff>` command as in the example above, or in
+the data file or restart files read by the :doc:`read_data
+<read_data>` or :doc:`read_restart <read_restart>` commands:
+
+* preset = *C* or *custom*
+* additional parameters depending on preset
+
+Preset *C* is for carbon nanotubes, and the additional parameters are:
+
+* chiral index :math:`n` (unitless)
+* chiral index :math:`m` (unitless)
+* :math:`r_0` (distance)
+
+Preset *custom* is simply a direct wrapper for the :doc:`harmonic
+<bond_harmonic>` style, and the additional parameters are:
+
+* :math:`K` (energy/distance\^2)
+* :math:`r_0` (distance)
+
+Restrictions
+""""""""""""
+
+This bond style can only be used if LAMMPS was built with the MOLECULE
+and MESONT packages.  See the :doc:`Build package <Build_package>`
+page for more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`bond_coeff <bond_coeff>`, :doc:`delete_bonds <delete_bonds>`
+
+Default
+"""""""
+
+none
+
+----------
+
+.. _Srivastava_1:
+
+**(Srivastava)** Zhigilei, Wei and Srivastava, Phys. Rev. B 71, 165417
+(2005).

doc/src/bond_style.rst

@@ -10,7 +10,7 @@ Syntax
 
    bond_style style args
 
-* style = *none* or *hybrid* or *class2* or *fene* or *fene/expand* or         *harmonic* or *morse* or *nonlinear* or *quartic*
+* style = *none* or *zero* or *hybrid* or *bpm/rotational* or *bpm/spring* or *class2* or *fene* or *fene/expand* or *fene/nm* or *gaussian* or *gromos* or *harmonic* or *harmonic/shift* or *harmonic/shift/cut* or *morse* or *nonlinear* or *oxdna/fene* or *oxdena2/fene* or *oxrna2/fene* or *quartic* or *special* or *table*
 
 * args = none for any style except *hybrid*
 
@@ -95,6 +95,7 @@ accelerated styles exist.
 * :doc:`harmonic <bond_harmonic>` - harmonic bond
 * :doc:`harmonic/shift <bond_harmonic_shift>` - shifted harmonic bond
 * :doc:`harmonic/shift/cut <bond_harmonic_shift_cut>` - shifted harmonic bond with a cutoff
+* :doc:`mesocnt <bond_mesocnt>` - Harmonic bond wrapper with parameterization presets for nanotubes
 * :doc:`mm3 <bond_mm3>` - MM3 anharmonic bond
 * :doc:`morse <bond_morse>` - Morse bond
 * :doc:`nonlinear <bond_nonlinear>` - nonlinear bond

doc/src/bond_zero.rst

@@ -8,7 +8,10 @@ Syntax
 
 .. code-block:: LAMMPS
 
-   bond_style zero [nocoeff]
+   bond_style zero keyword
+
+* zero or more keywords may be appended
+* keyword = *nocoeff*
 
 Examples
 """"""""

doc/src/boundary.rst

@@ -6,7 +6,7 @@ boundary command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    boundary x y z
 

doc/src/box.rst

@@ -6,7 +6,7 @@ box command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    box keyword value ...
 

doc/src/clear.rst

@@ -6,18 +6,18 @@ clear command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    clear
 
 Examples
 """"""""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
-   (commands for 1st simulation)
+   # (commands for 1st simulation)
    clear
-   (commands for 2nd simulation)
+   # (commands for 2nd simulation)
 
 Description
 """""""""""

doc/src/comm_modify.rst

@@ -10,8 +10,8 @@ Syntax
 
    comm_modify keyword value ...
 
-* zero or more keyword/value pairs may be appended
-* keyword = *mode* or *cutoff* or *cutoff/multi* or *multi/reduce* or *group* or *vel*
+* one or more keyword/value pairs may be appended
+* keyword = *mode* or *cutoff* or *cutoff/multi* or *group* or *reduce/multi* or *vel*
 
   .. parsed-literal::
 

doc/src/commands_list.rst

@@ -56,6 +56,7 @@ Commands
    kspace_modify
    kspace_style
    label
+   labelmap
    lattice
    log
    mass

doc/src/compute.rst

@@ -6,7 +6,7 @@ compute command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    compute ID group-ID style args
 
@@ -33,8 +33,8 @@ they are calculated from information about atoms on the current
 timestep or iteration, though a compute may internally store some
 information about a previous state of the system.  Defining a compute
 does not perform a computation.  Instead computes are invoked by other
-LAMMPS commands as needed, e.g. to calculate a temperature needed for
-a thermostat fix or to generate thermodynamic or dump file output.
+LAMMPS commands as needed (e.g., to calculate a temperature needed for
+a thermostat fix or to generate thermodynamic or dump file output).
 See the :doc:`Howto output <Howto_output>` page for a summary of
 various LAMMPS output options, many of which involve computes.
 
@@ -45,15 +45,15 @@ underscores.
 
 Computes calculate one of three styles of quantities: global,
 per-atom, or local.  A global quantity is one or more system-wide
-values, e.g. the temperature of the system.  A per-atom quantity is
-one or more values per atom, e.g. the kinetic energy of each atom.
+values (e.g., the temperature of the system).  A per-atom quantity is
+one or more values per atom (e.g., the kinetic energy of each atom).
 Per-atom values are set to 0.0 for atoms not in the specified compute
 group.  Local quantities 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.  Computes that produce per-atom quantities have the
-word "atom" in their style, e.g. *ke/atom*\ .  Computes that produce
-local quantities have the word "local" in their style,
-e.g. *bond/local*\ .  Styles with neither "atom" or "local" in their
+atoms it owns, but there may be zero or more per atom (e.g., a list of
+bond distances).  Computes that produce per-atom quantities have the
+word "atom" in their style (e.g., *ke/atom*\ ).  Computes that produce
+local quantities have the word "local" in their style
+(e.g., *bond/local*\ ).  Styles with neither "atom" or "local" in their
 style produce global quantities.
 
 Note that a single compute can produce either global or per-atom or
@@ -64,8 +64,8 @@ compute page will explain.
 Global, per-atom, and local quantities each come in three kinds: a
 single scalar value, a vector of values, or a 2d array of values.  The
 doc page for each compute describes the style and kind of values it
-produces, e.g. a per-atom vector.  Some computes produce more than one
-kind of a single style, e.g. a global scalar and a global vector.
+produces (e.g., a per-atom vector).  Some computes produce more than one
+kind of a single style (e.g., a global scalar and a global vector).
 
 When a compute quantity is accessed, as in many of the output commands
 discussed below, it can be referenced via the following bracket
@@ -80,14 +80,14 @@ notation, where ID is the ID of the compute:
 +-------------+--------------------------------------------+
 
 In other words, using one bracket reduces the dimension of the
-quantity once (vector -> scalar, array -> vector).  Using two brackets
-reduces the dimension twice (array -> scalar).  Thus a command that
-uses scalar compute values as input can also process elements of a
+quantity once (vector :math:`\to` scalar, array :math:`\to` vector).  Using two
+brackets reduces the dimension twice (array :math:`\to` scalar).  Thus a
+command that uses scalar compute values as input can also process elements of a
 vector or array.
 
 Note that commands and :doc:`variables <variable>` which use compute
-quantities typically do not allow for all kinds, e.g. a command may
-require a vector of values, not a scalar.  This means there is no
+quantities typically do not allow for all kinds (e.g., a command may
+require a vector of values, not a scalar).  This means there is no
 ambiguity about referring to a compute quantity as c_ID even if it
 produces, for example, both a scalar and vector.  The doc pages for
 various commands explain the details.
@@ -111,14 +111,14 @@ ways:
 
 The results of computes that calculate global quantities can be either
 "intensive" or "extensive" values.  Intensive means the value is
-independent of the number of atoms in the simulation,
-e.g. temperature.  Extensive means the value scales with the number of
-atoms in the simulation, e.g. total rotational kinetic energy.
+independent of the number of atoms in the simulation
+(e.g., temperature).  Extensive means the value scales with the number of
+atoms in the simulation (e.g., total rotational kinetic energy).
 :doc:`Thermodynamic output <thermo_style>` will normalize extensive
 values by the number of atoms in the system, depending on the
 "thermo_modify norm" setting.  It will not normalize intensive values.
-If a compute value is accessed in another way, e.g. by a
-:doc:`variable <variable>`, you may want to know whether it is an
+If a compute value is accessed in another way (e.g., by a
+:doc:`variable <variable>`), you may want to know whether it is an
 intensive or extensive value.  See the page for individual
 computes for further info.
 
@@ -187,8 +187,8 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`cluster/atom <compute_cluster_atom>` - cluster ID for each atom
 * :doc:`cna/atom <compute_cna_atom>` - common neighbor analysis (CNA) for each atom
 * :doc:`cnp/atom <compute_cnp_atom>` - common neighborhood parameter (CNP) for each atom
-* :doc:`com <compute_com>` - center-of-mass of group of atoms
-* :doc:`com/chunk <compute_com_chunk>` - center-of-mass for each chunk
+* :doc:`com <compute_com>` - center of mass of group of atoms
+* :doc:`com/chunk <compute_com_chunk>` - center of mass for each chunk
 * :doc:`contact/atom <compute_contact_atom>` - contact count for each spherical particle
 * :doc:`coord/atom <compute_coord_atom>` - coordination number for each atom
 * :doc:`damage/atom <compute_damage_atom>` - Peridynamic damage for each atom
@@ -198,10 +198,10 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`dipole <compute_dipole>` - dipole vector and total dipole
 * :doc:`dipole/chunk <compute_dipole_chunk>` - dipole vector and total dipole for each chunk
 * :doc:`displace/atom <compute_displace_atom>` - displacement of each atom
-* :doc:`dpd <compute_dpd>` -
-* :doc:`dpd/atom <compute_dpd_atom>` -
+* :doc:`dpd <compute_dpd>` - total values of internal conductive energy, internal mechanical energy, chemical energy, and harmonic average of internal temperature
+* :doc:`dpd/atom <compute_dpd_atom>` - per-particle values of internal conductive energy, internal mechanical energy, chemical energy, and internal temperature
 * :doc:`edpd/temp/atom <compute_edpd_temp_atom>` - per-atom temperature for each eDPD particle in a group
-* :doc:`efield/atom <compute_efield_atom>` -
+* :doc:`efield/atom <compute_efield_atom>` - electric field at each atom
 * :doc:`entropy/atom <compute_entropy_atom>` - pair entropy fingerprint of each atom
 * :doc:`erotate/asphere <compute_erotate_asphere>` - rotational energy of aspherical particles
 * :doc:`erotate/rigid <compute_erotate_rigid>` - rotational energy of rigid bodies
@@ -213,7 +213,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`fep/ta <compute_fep_ta>` - compute free energies for a test area perturbation
 * :doc:`force/tally <compute_tally>` - force between two groups of atoms via the tally callback mechanism
 * :doc:`fragment/atom <compute_cluster_atom>` - fragment ID for each atom
-* :doc:`global/atom <compute_global_atom>` -
+* :doc:`global/atom <compute_global_atom>` - assign global values to each atom from arrays of global values
 * :doc:`group/group <compute_group_group>` - energy/force between two groups of atoms
 * :doc:`gyration <compute_gyration>` - radius of gyration of group of atoms
 * :doc:`gyration/chunk <compute_gyration_chunk>` - radius of gyration for each chunk
@@ -232,7 +232,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`ke/atom/eff <compute_ke_atom_eff>` - per-atom translational and radial kinetic energy in the electron force field model
 * :doc:`ke/eff <compute_ke_eff>` - kinetic energy of a group of nuclei and electrons in the electron force field model
 * :doc:`ke/rigid <compute_ke_rigid>` - translational kinetic energy of rigid bodies
-* :doc:`mliap <compute_mliap>` - gradients of energy and forces w.r.t. model parameters and related quantities for training machine learning interatomic potentials
+* :doc:`mliap <compute_mliap>` - gradients of energy and forces with respect to model parameters and related quantities for training machine learning interatomic potentials
 * :doc:`momentum <compute_momentum>` - translational momentum
 * :doc:`msd <compute_msd>` - mean-squared displacement of group of atoms
 * :doc:`msd/chunk <compute_msd_chunk>` - mean-squared displacement for each chunk
@@ -254,36 +254,38 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`property/chunk <compute_property_chunk>` - extract various per-chunk attributes
 * :doc:`property/local <compute_property_local>` - convert local attributes to localvectors/arrays
 * :doc:`ptm/atom <compute_ptm_atom>` - determines the local lattice structure based on the Polyhedral Template Matching method
-* :doc:`rdf <compute_rdf>` - radial distribution function g(r) histogram of group of atoms
+* :doc:`rdf <compute_rdf>` - radial distribution function :math:`g(r)` histogram of group of atoms
 * :doc:`reduce <compute_reduce>` - combine per-atom quantities into a single global value
 * :doc:`reduce/chunk <compute_reduce_chunk>` - reduce per-atom quantities within each chunk
 * :doc:`reduce/region <compute_reduce>` - same as compute reduce, within a region
 * :doc:`rigid/local <compute_rigid_local>` - extract rigid body attributes
 * :doc:`saed <compute_saed>` - electron diffraction intensity on a mesh of reciprocal lattice nodes
 * :doc:`slice <compute_slice>` - extract values from global vector or array
-* :doc:`smd/contact/radius <compute_smd_contact_radius>` -
+* :doc:`smd/contact/radius <compute_smd_contact_radius>` - contact radius for Smooth Mach Dynamics
 * :doc:`smd/damage <compute_smd_damage>` - damage status of SPH particles in Smooth Mach Dynamics
-* :doc:`smd/hourglass/error <compute_smd_hourglass_error>` -
+* :doc:`smd/hourglass/error <compute_smd_hourglass_error>` - error associated with approximated relative separation in Smooth Mach Dynamics
 * :doc:`smd/internal/energy <compute_smd_internal_energy>` - per-particle enthalpy in Smooth Mach Dynamics
 * :doc:`smd/plastic/strain <compute_smd_plastic_strain>` - equivalent plastic strain per particle in Smooth Mach Dynamics
 * :doc:`smd/plastic/strain/rate <compute_smd_plastic_strain_rate>` - time rate of the equivalent plastic strain in Smooth Mach Dynamics
 * :doc:`smd/rho <compute_smd_rho>` - per-particle mass density in Smooth Mach Dynamics
 * :doc:`smd/tlsph/defgrad <compute_smd_tlsph_defgrad>` - deformation gradient in Smooth Mach Dynamics
 * :doc:`smd/tlsph/dt <compute_smd_tlsph_dt>` - CFL-stable time increment per particle in Smooth Mach Dynamics
-* :doc:`smd/tlsph/num/neighs <compute_smd_tlsph_num_neighs>` -
-* :doc:`smd/tlsph/shape <compute_smd_tlsph_shape>` -
-* :doc:`smd/tlsph/strain <compute_smd_tlsph_strain>` -
-* :doc:`smd/tlsph/strain/rate <compute_smd_tlsph_strain_rate>` -
+* :doc:`smd/tlsph/num/neighs <compute_smd_tlsph_num_neighs>` - number of particles inside the smoothing kernel radius for Smooth Mach Dynamics
+* :doc:`smd/tlsph/shape <compute_smd_tlsph_shape>` - current shape of the volume of a particle for Smooth Mach Dynamics
+* :doc:`smd/tlsph/strain <compute_smd_tlsph_strain>` - Green--Lagrange strain tensor for Smooth Mach Dynamics
+* :doc:`smd/tlsph/strain/rate <compute_smd_tlsph_strain_rate>` - rate of strain for Smooth Mach Dynamics
 * :doc:`smd/tlsph/stress <compute_smd_tlsph_stress>` - per-particle Cauchy stress tensor for SPH particles
-* :doc:`smd/triangle/vertices <compute_smd_triangle_vertices>` -
+* :doc:`smd/triangle/vertices <compute_smd_triangle_vertices>` - coordinates of vertices corresponding to the triangle elements of a mesh for Smooth Mach Dynamics
 * :doc:`smd/ulsph/effm <compute_smd_ulsph_effm>` - per-particle effective shear modulus
-* :doc:`smd/ulsph/num/neighs <compute_smd_ulsph_num_neighs>` -
-* :doc:`smd/ulsph/strain <compute_smd_ulsph_strain>` -
-* :doc:`smd/ulsph/strain/rate <compute_smd_ulsph_strain_rate>` -
+* :doc:`smd/ulsph/num/neighs <compute_smd_ulsph_num_neighs>` - number of neighbor particles inside the smoothing kernel radius for Smooth Mach Dynamics
+* :doc:`smd/ulsph/strain <compute_smd_ulsph_strain>` - logarithmic strain tensor for Smooth Mach Dynamics
+* :doc:`smd/ulsph/strain/rate <compute_smd_ulsph_strain_rate>` - logarithmic strain rate for Smooth Mach Dynamics
 * :doc:`smd/ulsph/stress <compute_smd_ulsph_stress>` - per-particle Cauchy stress tensor and von Mises equivalent stress in Smooth Mach Dynamics
 * :doc:`smd/vol <compute_smd_vol>` - per-particle volumes and their sum in Smooth Mach Dynamics
-* :doc:`snap <compute_sna_atom>` - gradients of SNAP energy and forces w.r.t. linear coefficients and related quantities for fitting SNAP potentials
+* :doc:`snap <compute_sna_atom>` - gradients of SNAP energy and forces with respect to linear coefficients and related quantities for fitting SNAP potentials
 * :doc:`sna/atom <compute_sna_atom>` - bispectrum components for each atom
+* :doc:`sna/grid <compute_sna_atom>` - global array of bispectrum components on a regular grid
+* :doc:`sna/grid/local <compute_sna_atom>` - local array of bispectrum components on a regular grid
 * :doc:`snad/atom <compute_sna_atom>` - derivative of bispectrum components for each atom
 * :doc:`snav/atom <compute_sna_atom>` - virial contribution from bispectrum components for each atom
 * :doc:`sph/e/atom <compute_sph_e_atom>` - per-atom internal energy of Smooth-Particle Hydrodynamics atoms
@@ -306,7 +308,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`temp/cs <compute_temp_cs>` - temperature based on the center-of-mass velocity of atom pairs that are bonded to each other
 * :doc:`temp/deform <compute_temp_deform>` - temperature excluding box deformation velocity
 * :doc:`temp/deform/eff <compute_temp_deform_eff>` - temperature excluding box deformation velocity in the electron force field model
-* :doc:`temp/drude <compute_temp_drude>` - temperature of Core-Drude pairs
+* :doc:`temp/drude <compute_temp_drude>` - temperature of Core--Drude pairs
 * :doc:`temp/eff <compute_temp_eff>` - temperature of a group of nuclei and electrons in the electron force field model
 * :doc:`temp/partial <compute_temp_partial>` - temperature excluding one or more dimensions of velocity
 * :doc:`temp/profile <compute_temp_profile>` - temperature excluding a binned velocity profile
@@ -322,7 +324,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`vcm/chunk <compute_vcm_chunk>` - velocity of center-of-mass for each chunk
 * :doc:`viscosity/cos <compute_viscosity_cos>` - velocity profile under cosine-shaped acceleration
 * :doc:`voronoi/atom <compute_voronoi_atom>` - Voronoi volume and neighbors for each atom
-* :doc:`xrd <compute_xrd>` - x-ray diffraction intensity on a mesh of reciprocal lattice nodes
+* :doc:`xrd <compute_xrd>` - X-ray diffraction intensity on a mesh of reciprocal lattice nodes
 
 Restrictions
 """"""""""""
@@ -331,7 +333,9 @@ Restrictions
 Related commands
 """"""""""""""""
 
-:doc:`uncompute <uncompute>`, :doc:`compute_modify <compute_modify>`, :doc:`fix ave/atom <fix_ave_atom>`, :doc:`fix ave/time <fix_ave_time>`, :doc:`fix ave/histo <fix_ave_histo>`
+:doc:`uncompute <uncompute>`, :doc:`compute_modify <compute_modify>`,
+:doc:`fix ave/atom <fix_ave_atom>`, :doc:`fix ave/time <fix_ave_time>`,
+:doc:`fix ave/histo <fix_ave_histo>`
 
 Default
 """""""

doc/src/compute_ackland_atom.rst

@@ -6,7 +6,7 @@ compute ackland/atom command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    compute ID group-ID ackland/atom keyword/value
 
@@ -17,7 +17,7 @@ Syntax
 
   .. parsed-literal::
 
-       *legacy* yes/no = use (\ *yes*\ ) or do not use (\ *no*\ ) legacy ackland algorithm implementation
+       *legacy* args = *yes* or *no* = use (\ *yes*\ ) or do not use (\ *no*\ ) legacy Ackland algorithm implementation
 
 Examples
 """"""""

doc/src/compute_adf.rst

@@ -6,7 +6,7 @@ compute adf command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    compute ID group-ID adf Nbin itype1 jtype1 ktype1 Rjinner1 Rjouter1 Rkinner1 Rkouter1 ...
 
@@ -16,10 +16,10 @@ Syntax
 * itypeN = central atom type for Nth ADF histogram (see asterisk form below)
 * jtypeN = J atom type for Nth ADF histogram (see asterisk form below)
 * ktypeN = K atom type for Nth ADF histogram (see asterisk form below)
-* RjinnerN =  inner radius of J atom shell for Nth ADF histogram (distance units)
-* RjouterN =  outer radius of J atom shell for Nth ADF histogram (distance units)
+* RjinnerN = inner radius of J atom shell for Nth ADF histogram (distance units)
+* RjouterN = outer radius of J atom shell for Nth ADF histogram (distance units)
 * RkinnerN = inner radius of K atom shell for Nth ADF histogram (distance units)
-* RkouterN =  outer radius of K atom shell for Nth ADF histogram (distance units)
+* RkouterN = outer radius of K atom shell for Nth ADF histogram (distance units)
 * zero or one keyword/value pairs may be appended
 * keyword = *ordinate*
 
@@ -177,8 +177,8 @@ Output info
 """""""""""
 
 This compute calculates a global array with the number of rows =
-*Nbins*, and the number of columns = 1 + 2\*Ntriples, where Ntriples is the
-number of I,J,K triples specified.  The first column has the bin
+*Nbins* and the number of columns = :math:`1 + 2 \times` *Ntriples*, where *Ntriples*
+is the number of I,J,K triples specified.  The first column has the bin
 coordinate (angle-related ordinate at midpoint of bin). Each subsequent column has
 the two ADF values for a specific set of (\ *itypeN*,\ *jtypeN*,\ *ktypeN*\ )
 interactions, as described above.  These values can be used
@@ -192,10 +192,10 @@ The first column of array values is the angle-related ordinate, either
 the angle in degrees or radians, or the cosine of the angle.  Each
 subsequent pair of columns gives the first and second kinds of ADF
 for a specific set of (\ *itypeN*,\ *jtypeN*,\ *ktypeN*\ ). The values
-in the first ADF column are normalized numbers >= 0.0,
+in the first ADF column are normalized numbers :math:`\ge 0.0`,
 whose integral w.r.t. the ordinate is 1,
 i.e. the first ADF is a normalized probability distribution.
-The values in the second ADF column are also numbers >= 0.0.
+The values in the second ADF column are also numbers :math:`\ge 0.0`.
 They are the cumulative density distribution of angles per atom.
 By definition, this ADF is monotonically increasing from zero to
 a maximum value equal to the average total number of

doc/src/compute_angle.rst

@@ -6,7 +6,7 @@ compute angle command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    compute ID group-ID angle
 
@@ -35,12 +35,12 @@ the hybrid sub-styles.
 Output info
 """""""""""
 
-This compute calculates a global vector of length N where N is the number of
-sub_styles defined by the :doc:`angle_style hybrid <angle_style>` command,
-which can be accessed by indices 1-N.  These values can be used by any command
-that uses global scalar or vector values from a compute as input.  See the
-:doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
-options.
+This compute calculates a global vector of length *N*, where *N* is the number
+of sub_styles defined by the :doc:`angle_style hybrid <angle_style>` command,
+which can be accessed by indices 1 through *N*.  These values can be used by
+any command that uses global scalar or vector values from a compute as input.
+See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS
+output options.
 
 The vector values are "extensive" and will be in energy
 :doc:`units <units>`.

doc/src/compute_angle_local.rst

@@ -6,7 +6,7 @@ compute angle/local command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    compute ID group-ID angle/local value1 value2 ... keyword args ...
 
@@ -47,7 +47,7 @@ interactions.  The number of datums generated, aggregated across all
 processors, equals the number of angles in the system, modified by the
 group parameter as explained below.
 
-The value *theta* is the angle for the 3 atoms in the interaction.
+The value *theta* is the angle for the three atoms in the interaction.
 
 The value *eng* is the interaction energy for the angle.
 
@@ -65,8 +65,8 @@ Note that the value of theta for each angle which stored in the
 internal variable is in radians, not degrees.
 
 As an example, these commands can be added to the bench/in.rhodo
-script to compute the cosine and cosine\^2 of every angle in the system
-and output the statistics in various ways:
+script to compute the cosine and cosine-squared of every angle in the
+system and output the statistics in various ways:
 
 .. code-block:: LAMMPS
 
@@ -83,19 +83,20 @@ and output the statistics in various ways:
 
    fix 10 all ave/histo 10 10 100 -1 1 20 c_2[3] mode vector file tmp.histo
 
-The :doc:`dump local <dump>` command will output the energy, angle,
-cosine(angle), cosine\^2(angle) for every angle in the system.  The
-:doc:`thermo_style <thermo_style>` command will print the average of
-those quantities via the :doc:`compute reduce <compute_reduce>` command
-with thermo output.  And the :doc:`fix ave/histo <fix_ave_histo>`
-command will histogram the cosine(angle) values and write them to a
+The :doc:`dump local <dump>` command will output the potential energy
+(:math:`\phi`), the angle (:math:`\theta`), :math:`\cos(\theta`), and
+:math:`\cos^2(\theta)` for every angle :math:`\theta` in the system.
+The :doc:`thermo_style <thermo_style>` command will print the
+average of those quantities via the :doc:`compute reduce <compute_reduce>`
+command with thermo output.  And the :doc:`fix ave/histo <fix_ave_histo>`
+command will histogram the :math:`\cos(\theta)` values and write them to a
 file.
 
 ----------
 
 The local data stored by this command is generated by looping over all
 the atoms owned on a processor and their angles.  An angle will only
-be included if all 3 atoms in the angle are in the specified compute
+be included if all three atoms in the angle are in the specified compute
 group.  Any angles that have been broken (see the
 :doc:`angle_style <angle_style>` command) by setting their angle type to
 0 are not included.  Angles that have been turned off (see the :doc:`fix shake <fix_shake>` or :doc:`delete_bonds <delete_bonds>` commands) by

doc/src/compute_angmom_chunk.rst

@@ -6,7 +6,7 @@ compute angmom/chunk command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    compute ID group-ID angmom/chunk chunkID
 
@@ -72,8 +72,8 @@ Output info
 """""""""""
 
 This compute calculates a global array where the number of rows = the
-number of chunks *Nchunk* as calculated by the specified :doc:`compute chunk/atom <compute_chunk_atom>` command.  The number of columns =
-3 for the 3 xyz components of the angular momentum for each chunk.
+number of chunks *Nchunk* as calculated by the specified :doc:`compute chunk/atom <compute_chunk_atom>` command.  The number of columns = 3 for the three
+(*x*, *y*, *z*) components of the angular momentum for each chunk.
 These values can be accessed by any command that uses global array
 values from a compute as input.  See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
 options.

doc/src/compute_ave_sphere_atom.rst

@@ -9,7 +9,7 @@ Accelerator Variants: *ave/sphere/atom/kk*
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    compute ID group-ID ave/sphere/atom keyword values ...
 
@@ -35,16 +35,24 @@ Examples
 Description
 """""""""""
 
-Define a computation that calculates the local density and temperature
-for each atom and neighbors inside a spherical cutoff.
+Define a computation that calculates the local mass density and
+temperature for each atom based on its neighbors inside a spherical
+cutoff.  If an atom has :math:`M` neighbors, then its local mass density is
+calculated as the sum of its mass and its :math:`M` neighbor masses, divided
+by the volume of the cutoff sphere (or circle in 2d).  The local
+temperature of the atom is calculated as the temperature of the
+collection of :math:`M+1` atoms, after subtracting the center-of-mass velocity
+of the :math:`M+1` atoms from each of the :math:`M+1` atom's velocities.  This
+is effectively the thermal velocity of the neighborhood of the central
+atom, similar to :doc:`compute temp/com <compute_temp_com>`.
 
-The optional keyword *cutoff* defines the distance cutoff
-used when searching for neighbors. The default value is the cutoff
-specified by the pair style. If no pair style is defined, then a cutoff
-must be defined using this keyword. If the specified cutoff is larger than
-that of the pair_style plus neighbor skin (or no pair style is defined),
-the *comm_modify cutoff* option must also be set to match that of the
-*cutoff* keyword.
+The optional keyword *cutoff* defines the distance cutoff used when
+searching for neighbors. The default value is the cutoff specified by
+the pair style. If no pair style is defined, then a cutoff must be
+defined using this keyword. If the specified cutoff is larger than
+that of the pair_style plus neighbor skin (or no pair style is
+defined), the *comm_modify cutoff* option must also be set to match
+that of the *cutoff* keyword.
 
 The neighbor list needed to compute this quantity is constructed each
 time the calculation is performed (i.e. each time a snapshot of atoms
@@ -55,16 +63,16 @@ too frequently.
 
    If you have a bonded system, then the settings of
    :doc:`special_bonds <special_bonds>` command can remove pairwise
-   interactions between atoms in the same bond, angle, or dihedral.  This
-   is the default setting for the :doc:`special_bonds <special_bonds>`
-   command, and means those pairwise interactions do not appear in the
-   neighbor list.  Because this fix uses the neighbor list, it also means
-   those pairs will not be included in the order parameter.  This
-   difficulty can be circumvented by writing a dump file, and using the
-   :doc:`rerun <rerun>` command to compute the order parameter for
-   snapshots in the dump file.  The rerun script can use a
-   :doc:`special_bonds <special_bonds>` command that includes all pairs in
-   the neighbor list.
+   interactions between atoms in the same bond, angle, or dihedral.
+   This is the default setting for the :doc:`special_bonds
+   <special_bonds>` command, and means those pairwise interactions do
+   not appear in the neighbor list.  Because this compute uses the
+   neighbor list, it also means those pairs will not be included in
+   the order parameter.  This difficulty can be circumvented by
+   writing a dump file, and using the :doc:`rerun <rerun>` command to
+   compute the order parameter for snapshots in the dump file.  The
+   rerun script can use a :doc:`special_bonds <special_bonds>` command
+   that includes all pairs in the neighbor list.
 
 ----------
 
@@ -77,17 +85,20 @@ too frequently.
 Output info
 """""""""""
 
-This compute calculates a per-atom array with two columns: density and temperature.
+This compute calculates a per-atom array with two columns: mass
+density in density :doc:`units <units>` and temperature in temperature
+:doc:`units <units>`.
 
 These values can be accessed by any command that uses per-atom values
-from a compute as input.  See the :doc:`Howto output <Howto_output>` doc
-page for an overview of LAMMPS output options.
+from a compute as input.  See the :doc:`Howto output <Howto_output>`
+doc page for an overview of LAMMPS output options.
 
 Restrictions
 """"""""""""
 
-This compute is part of the EXTRA-COMPUTE package.  It is only enabled if
-LAMMPS was built with that package.  See the :doc:`Build package <Build_package>` page for more info.
+This compute is part of the EXTRA-COMPUTE package.  It is only enabled
+if LAMMPS was built with that package.  See the :doc:`Build package
+<Build_package>` page for more info.
 
 Related commands
 """"""""""""""""
@@ -97,5 +108,5 @@ Related commands
 Default
 """""""
 
-The option defaults are *cutoff* = pair style cutoff
+The option defaults are *cutoff* = pair style cutoff.
 

doc/src/compute_basal_atom.rst

@@ -6,7 +6,7 @@ compute basal/atom command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    compute ID group-ID basal/atom
 
@@ -47,12 +47,12 @@ in examples/PACKAGES/basal.
 Output info
 """""""""""
 
-This compute calculates a per-atom array with 3 columns, which can be
-accessed by indices 1-3 by any command that uses per-atom values from
+This compute calculates a per-atom array with three columns, which can be
+accessed by indices 1--3 by any command that uses per-atom values from
 a compute as input.  See the :doc:`Howto output <Howto_output>` doc page
 for an overview of LAMMPS output options.
 
-The per-atom vector values are unitless since the 3 columns represent
+The per-atom vector values are unitless since the three columns represent
 components of a unit vector.
 
 Restrictions

doc/src/compute_body_local.rst

@@ -6,7 +6,7 @@ compute body/local command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    compute ID group-ID body/local input1 input2 ...
 
@@ -33,7 +33,7 @@ Description
 """""""""""
 
 Define a computation that calculates properties of individual body
-sub-particles.  The number of datums generated, aggregated across all
+sub-particles.  The number of data generated, aggregated across all
 processors, equals the number of body sub-particles plus the number of
 non-body particles in the system, modified by the group parameter as
 explained below.  See the :doc:`Howto body <Howto_body>` page for
@@ -41,8 +41,8 @@ more details on using body particles.
 
 The local data stored by this command is generated by looping over all
 the atoms.  An atom will only be included if it is in the group.  If
-the atom is a body particle, then its N sub-particles will be looped
-over, and it will contribute N datums to the count of datums.  If it
+the atom is a body particle, then its :math:`N` sub-particles will be looped
+over, and it will contribute :math:`N` data to the count of data.  If it
 is not a body particle, it will contribute 1 datum.
 
 For both body particles and non-body particles, the *id* keyword
@@ -64,8 +64,8 @@ by the :doc:`atom_style body <atom_style>`, determines how many fields
 exist and what they are.  See the :doc:`Howto_body <Howto_body>` doc
 page for details of the different styles.
 
-Here is an example of how to output body information using the :doc:`dump local <dump>` command with this compute.  If fields 1,2,3 for the
-body sub-particles are x,y,z coordinates, then the dump file will be
+Here is an example of how to output body information using the :doc:`dump local <dump>` command with this compute.  If fields 1, 2, and 3 for the
+body sub-particles are (*x*, *y*, *z*) coordinates, then the dump file will be
 formatted similar to the output of a :doc:`dump atom or custom <dump>`
 command.
 
@@ -79,7 +79,7 @@ Output info
 
 This compute calculates a local vector or local array depending on the
 number of keywords.  The length of the vector or number of rows in the
-array is the number of datums as described above.  If a single keyword
+array is the number of data as described above.  If a single keyword
 is specified, a local vector is produced.  If two or more keywords are
 specified, a local array is produced where the number of columns = the
 number of keywords.  The vector or array can be accessed by any

doc/src/compute_bond.rst

@@ -6,7 +6,7 @@ compute bond command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    compute ID group-ID bond
 
@@ -35,10 +35,13 @@ or more of the hybrid sub-styles.
 Output info
 """""""""""
 
-This compute calculates a global vector of length N where N is the
-number of sub_styles defined by the :doc:`bond_style hybrid <bond_style>` command, which can be accessed by indices 1-N.
+This compute calculates a global vector of length :math:`N`, where :math:`N`
+is the number of sub_styles defined by the
+:doc:`bond_style hybrid <bond_style>` command,
+which can be accessed by indices 1 through :math:`N`.
 These values can be used by any command that uses global scalar or
-vector values from a compute as input.  See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
+vector values from a compute as input.  See the
+:doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
 options.
 
 The vector values are "extensive" and will be in energy

doc/src/compute_bond_local.rst

@@ -6,7 +6,7 @@ compute bond/local command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    compute ID group-ID bond/local value1 value2 ... keyword args ...
 
@@ -35,8 +35,8 @@ Syntax
 
 .. parsed-literal::
 
-     *set* args = dist name
-       dist = only currently allowed arg
+     *set* args = *dist* name
+       *dist* = only currently allowed arg
        name = name of variable to set with distance (dist)
 
 Examples
@@ -49,7 +49,7 @@ Examples
 
    compute 1 all bond/local dist fx fy fz
 
-   compute 1 all angle/local dist v_distsq set dist d
+   compute 1 all bond/local dist v_distsq set dist d
 
 Description
 """""""""""
@@ -82,32 +82,34 @@ relative to the center of mass (COM) velocity of the 2 atoms in the
 bond.
 
 The value *engvib* is the vibrational kinetic energy of the two atoms
-in the bond, which is simply 1/2 m1 v1\^2 + 1/2 m2 v2\^2, where v1 and
-v2 are the magnitude of the velocity of the 2 atoms along the bond
-direction, after the COM velocity has been subtracted from each.
-
-The value *engrot* is the rotational kinetic energy of the two atoms
-in the bond, which is simply 1/2 m1 v1\^2 + 1/2 m2 v2\^2, where v1 and
-v2 are the magnitude of the velocity of the 2 atoms perpendicular to
-the bond direction, after the COM velocity has been subtracted from
+in the bond, which is simply :math:`\frac12 m_1 v_1^2 + \frac12 m_2 v_2^2,`
+where :math:`v_1` and :math:`v_2` are the magnitude of the velocity of the two
+atoms along the bond direction, after the COM velocity has been subtracted from
 each.
 
-The value *engtrans* is the translational kinetic energy associated
-with the motion of the COM of the system itself, namely 1/2 (m1+m2)
-Vcm\^2 where Vcm = magnitude of the velocity of the COM.
+The value *engrot* is the rotational kinetic energy of the two atoms
+in the bond, which is simply :math:`\frac12 m_1 v_1^2 + \frac12 m_2 v_2^2,`
+where :math:`v_1` and :math:`v_2` are the magnitude of the velocity of the two
+atoms perpendicular to the bond direction, after the COM velocity has been
+subtracted from each.
 
-Note that these 3 kinetic energy terms are simply a partitioning of
-the summed kinetic energy of the 2 atoms themselves.  I.e. total KE =
-1/2 m1 v1\^2 + 1/2 m2 v2\^2 = engvib + engrot + engtrans, where v1,v2
-are the magnitude of the velocities of the 2 atoms, without any
-adjustment for the COM velocity.
+The value *engtrans* is the translational kinetic energy associated
+with the motion of the COM of the system itself, namely :math:`\frac12(m_1+m_2)
+V_{\mathrm{cm}}^2`, where `Vcm` = magnitude of the velocity of the COM.
+
+Note that these three kinetic energy terms are simply a partitioning of
+the summed kinetic energy of the two atoms themselves.  That is, the total
+kinetic energy is
+:math:`\frac12 m_1 v_1^2 + \frac12 m_2 v_2^2` = engvib + engrot + engtrans,
+where :math:`v_1` and :math:`v_2` are the magnitude of the velocities of the
+two atoms, without any adjustment for the COM velocity.
 
 The value *omega* is the magnitude of the angular velocity of the
 two atoms around their COM position.
 
 The value *velvib* is the magnitude of the relative velocity of the
 two atoms in the bond towards each other.  A negative value means the
-2 atoms are moving toward each other; a positive value means they are
+two atoms are moving toward each other; a positive value means they are
 moving apart.
 
 The value *v_name* can be used together with the *set* keyword to
@@ -121,7 +123,7 @@ directly.  The *set* keyword is used to identify the name of this
 other variable associated with theta.
 
 As an example, these commands can be added to the bench/in.rhodo
-script to compute the distance\^2 of every bond in the system and
+script to compute the length\ :math:`^2` of every bond in the system and
 output the statistics in various ways:
 
 .. code-block:: LAMMPS
@@ -138,12 +140,12 @@ output the statistics in various ways:
 
    fix 10 all ave/histo 10 10 100 0 6 20 c_2[3] mode vector file tmp.histo
 
-The :doc:`dump local <dump>` command will output the energy, distance,
-distance\^2 for every bond in the system.  The
+The :doc:`dump local <dump>` command will output the energy, length,
+and length\ :math:`^2` for every bond in the system.  The
 :doc:`thermo_style <thermo_style>` command will print the average of
 those quantities via the :doc:`compute reduce <compute_reduce>` command
-with thermo output.  And the :doc:`fix ave/histo <fix_ave_histo>`
-command will histogram the distance\^2 values and write them to a file.
+with thermo output, and the :doc:`fix ave/histo <fix_ave_histo>`
+command will histogram the length\ :math:`^2` values and write them to a file.
 
 ----------
 

doc/src/compute_born_matrix.rst

@@ -6,20 +6,26 @@ compute born/matrix command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    compute ID group-ID born/matrix keyword value ...
 
 * ID, group-ID are documented in :doc:`compute <compute>` command
 * born/matrix = style name of this compute command
-* zero or more keyword/value pairs may be appended
+* zero or more keywords or keyword/value pairs may be appended
 
   .. parsed-literal::
 
-     keyword = *numdiff*
+     keyword = *numdiff* or *pair* or *bond* or *angle* or *dihedral* or *improper*
        *numdiff* values = delta virial-ID
          delta = magnitude of strain (dimensionless)
          virial-ID = ID of pressure compute for virial (string)
+         (*numdiff* cannot be used with any other keyword)
+       *pair* = compute pair-wise contributions
+       *bond* = compute bonding contributions
+       *angle* = compute angle contributions
+       *dihedral* = compute dihedral contributions
+       *improper* = compute improper contributions
 
 Examples
 """"""""
@@ -33,9 +39,11 @@ Examples
 Description
 """""""""""
 
+.. versionadded:: 4May2022
+
 Define a compute that calculates
-:math:`\frac{\partial{}^2U}{\partial\varepsilon_{i}\partial\varepsilon_{j}}` the
-second derivatives of the potential energy :math:`U` w.r.t. strain
+:math:`\frac{\partial{}^2U}{\partial\varepsilon_{i}\partial\varepsilon_{j}},` the
+second derivatives of the potential energy :math:`U` with respect to the strain
 tensor :math:`\varepsilon` elements. These values are related to:
 
 .. math::
@@ -67,14 +75,14 @@ whose 21 independent elements are output in this order:
 
 .. math::
 
-    \begin{matrix}
+    \begin{bmatrix}
        C_{1}  & C_{7}   & C_{8}  & C_{9}  & C_{10} & C_{11} \\
        C_{7}  & C_{2}   & C_{12} & C_{13} & C_{14} & C_{15} \\
        \vdots & C_{12}  & C_{3}  & C_{16} & C_{17} & C_{18} \\
        \vdots & C_{13}  & C_{16} & C_{4}  & C_{19} & C_{20} \\
        \vdots & \vdots  & \vdots & C_{19} & C_{5}  & C_{21} \\
        \vdots & \vdots  & \vdots & \vdots & C_{21} & C_{6}
-    \end{matrix}
+    \end{bmatrix}
 
 in this matrix the indices of :math:`C_{k}` value are the corresponding element
 :math:`k` in the global vector output by this compute. Each term comes from the sum
@@ -167,7 +175,7 @@ requiring that it use the virial keyword e.g.
 **Output info:**
 
 This compute calculates a global vector with 21 values that are
-the second derivatives of the potential energy w.r.t. strain.
+the second derivatives of the potential energy with respect to strain.
 The values are in energy units.
 The values are ordered as explained above. These values can be used
 by any command that uses global values from a compute as input. See
@@ -186,7 +194,7 @@ the :doc:`Build package <Build_package>` page for more info.
 
 The Born term can be decomposed as a product of two terms. The first one is a
 general term which depends on the configuration. The second one is specific to
-every interaction composing your force field (non-bonded, bonds, angle...).
+every interaction composing your force field (non-bonded, bonds, angle, ...).
 Currently not all LAMMPS interaction styles implement the *born_matrix* method
 giving first and second order derivatives and LAMMPS will exit with an error if
 this compute is used with such interactions unless the *numdiff* option is

doc/src/compute_centro_atom.rst

@@ -6,17 +6,17 @@ compute centro/atom command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    compute ID group-ID centro/atom lattice keyword value ...
 
 * ID, group-ID are documented in :doc:`compute <compute>` command
-  centro/atom = style name of this compute command
-  lattice = *fcc* or *bcc* or N = # of neighbors per atom to include
+* centro/atom = style name of this compute command
+* lattice = *fcc* or *bcc* or N = # of neighbors per atom to include
 * zero or more keyword/value pairs may be appended
 * keyword = *axes*
 
-.. parsed-literal::
+  .. parsed-literal::
 
      *axes* value = *no* or *yes*
        *no* = do not calculate 3 symmetry axes
@@ -83,12 +83,13 @@ atoms with smallest contributions to the centrosymmetry parameter,
 i.e. the two most symmetric pairs of atoms.  The third vector is
 normal to the first two by the right-hand rule.  All three vectors are
 normalized to unit length.  For FCC crystals, the first two vectors
-will lie along a <110> direction, while the third vector will lie
-along either a <100> or <111> direction.  For HCP crystals, the first
-two vectors will lie along <1000> directions, while the third vector
-will lie along <0001>.  This provides a simple way to measure local
-orientation in HCP structures.  In general, the *axes* keyword can be
-used to estimate the orientation of symmetry axes in the neighborhood
+will lie along a :math:`\langle110\rangle` direction, while the third vector
+will lie along either a :math:`\langle100\rangle` or :math:`\langle111\rangle`
+direction.  For HCP crystals, the first two vectors will lie along
+:math:`\langle1000\rangle` directions, while the third vector
+will lie along :math:`\langle0001\rangle`.  This provides a simple way to
+measure local orientation in HCP structures.  In general, the *axes* keyword
+can be used to estimate the orientation of symmetry axes in the neighborhood
 of any atom.
 
 Only atoms within the cutoff of the pairwise neighbor list are
@@ -96,7 +97,7 @@ considered as possible neighbors.  Atoms not in the compute group are
 included in the :math:`N` neighbors used in this calculation.
 
 The neighbor list needed to compute this quantity is constructed each
-time the calculation is performed (e.g. each time a snapshot of atoms
+time the calculation is performed (e.g., each time a snapshot of atoms
 is dumped).  Thus it can be inefficient to compute/dump this quantity
 too frequently or to have multiple compute/dump commands, each with a
 *centro/atom* style.
@@ -111,11 +112,11 @@ options.
 
 If the *axes* keyword setting is *yes*, then a per-atom array is
 calculated. The first column is the centrosymmetry parameter.  The
-next three columns are the x, y, and z components of the first
+next three columns are the *x*, *y*, and *z* components of the first
 symmetry axis, followed by the second, and third symmetry axes in
-columns 5-7 and 8-10.
+columns 5--7 and 8--10.
 
-The centrosymmetry values are unitless values >= 0.0.  Their magnitude
+The centrosymmetry values are unitless values :math:`\ge 0.0`. Their magnitude
 depends on the lattice style due to the number of contributing neighbor
 pairs in the summation in the formula above.  And it depends on the
 local defects surrounding the central atom, as described above.  For

doc/src/compute_chunk_atom.rst

@@ -6,7 +6,7 @@ compute chunk/atom command
 Syntax
 """"""
 
-.. parsed-literal::
+.. code-block:: LAMMPS
 
    compute ID group-ID chunk/atom style args keyword values ...
 
@@ -15,7 +15,7 @@ Syntax
 
   .. parsed-literal::
 
-     style = *bin/1d* or *bin/2d* or *bin/3d* or *bin/sphere* or *type* or *molecule* or c_ID, c_ID[I], f_ID, f_ID[I], v_name
+     style = *bin/1d* or *bin/2d* or *bin/3d* or *bin/sphere* or *bin/cylinder* or *type* or *molecule* or c_ID, c_ID[I], f_ID, f_ID[I], v_name
        *bin/1d* args = dim origin delta
          dim = *x* or *y* or *z*
          origin = *lower* or *center* or *upper* or coordinate value (distance units)
@@ -49,7 +49,7 @@ Syntax
          v_name = per-atom vector calculated by an atom-style variable with name
 
 * zero or more keyword/values pairs may be appended
-* keyword = *region* or *nchunk* or *static* or *compress* or *bound* or *discard* or *pbc* or *units*
+* keyword = *region* or *nchunk* or *limit* or *ids* or *compress* or *discard* or *bound* or *pbc* or *units*
 
   .. parsed-literal::
 
@@ -74,7 +74,7 @@ Syntax
          no = keep atoms with out-of-range chunk IDs by assigning a valid chunk ID
          mixed = keep or discard such atoms according to spatial binning rule
        *bound* values = x/y/z lo hi
-         x/y/z = *x* or *y* or *z* to bound sptial bins in this dimension
+         x/y/z = *x* or *y* or *z* to bound spatial bins in this dimension
          lo = *lower* or coordinate value (distance units)
          hi = *upper* or coordinate value (distance units)
        *pbc* value = *no* or *yes*
@@ -150,14 +150,14 @@ The *binning* styles perform a spatial binning of atoms, and assign an
 atom the chunk ID corresponding to the bin number it is in.  *Nchunk*
 is set to the number of bins, which can change if the simulation box
 size changes.  This also depends on the setting of the *units*
-keyword; e.g. for *reduced* units the number of chunks may not change
-even if the box size does.
+keyword (e.g., for *reduced* units the number of chunks may not change
+even if the box size does).
 
 The *bin/1d*, *bin/2d*, and *bin/3d* styles define bins as 1d layers
 (slabs), 2d pencils, or 3d boxes.  The *dim*, *origin*, and *delta*
 settings are specified 1, 2, or 3 times.  For 2d or 3d bins, there is
-no restriction on specifying dim = x before dim = y or z, or dim = y
-before dim = z.  Bins in a particular *dim* have a bin size in that
+no restriction on specifying dim = *x* before dim = *y* or *z*, or dim = *y*
+before dim = *z*.  Bins in a particular *dim* have a bin size in that
 dimension given by *delta*\ .  In each dimension, bins are defined
 relative to a specified *origin*, which may be the lower/upper edge of
 the simulation box (in that dimension), or its center point, or a
@@ -170,10 +170,11 @@ boxes aligned with the xyz coordinate axes.  For triclinic
 (non-orthogonal) simulation boxes, the bin faces are parallel to the
 tilted faces of the simulation box.  See the :doc:`Howto triclinic <Howto_triclinic>` page for a discussion of the
 geometry of triclinic boxes in LAMMPS.  As described there, a tilted
-simulation box has edge vectors a,b,c.  In that nomenclature, bins in
-the x dimension have faces with normals in the "b" cross "c"
-direction.  Bins in y have faces normal to the "a" cross "c"
-direction.  And bins in z have faces normal to the "a" cross "b"
+simulation box has edge vectors :math:`\vec a`, :math:`\vec b`, and
+:math:`\vec c`.  In that nomenclature, bins in
+the *x* dimension have faces with normals in the :math:`\vec b \times \vec c`
+direction, bins in *y* have faces normal to the :math:`\vec a \times \vec c`
+direction, and bins in *z* have faces normal to the :math:`\vec a \times \vec b`
 direction.  Note that in order to define the size and position of
 these bins in an unambiguous fashion, the *units* option must be set
 to *reduced* when using a triclinic simulation box, as noted below.
@@ -181,46 +182,46 @@ to *reduced* when using a triclinic simulation box, as noted below.
 The meaning of *origin* and *delta* for triclinic boxes is as follows.
 Consider a triclinic box with bins that are 1d layers or slabs in the
 x dimension.  No matter how the box is tilted, an *origin* of 0.0
-means start layers at the lower "b" cross "c" plane of the simulation
-box and an *origin* of 1.0 means to start layers at the upper "b"
-cross "c" face of the box.  A *delta* value of 0.1 in *reduced* units
-means there will be 10 layers from 0.0 to 1.0, regardless of the
-current size or shape of the simulation box.
+means start layers at the lower :math:`\vec b \times \vec c` plane of the
+simulation box and an *origin* of 1.0 means to start layers at the upper
+:math:`\vec b \times \vec c` face of the box.  A *delta* value of 0.1 in
+*reduced* units means there will be 10 layers from 0.0 to 1.0, regardless of
+the current size or shape of the simulation box.
 
 The *bin/sphere* style defines a set of spherical shell bins around
 the origin (\ *xorig*,\ *yorig*,\ *zorig*\ ), using *nsbin* bins with radii
 equally spaced between *srmin* and *srmax*\ .  This is effectively a 1d
 vector of bins.  For example, if *srmin* = 1.0 and *srmax* = 10.0 and
-*nsbin* = 9, then the first bin spans 1.0 < r < 2.0, and the last bin
-spans 9.0 < r 10.0.  The geometry of the bins is the same whether the
-simulation box is orthogonal or triclinic; i.e. the spherical shells
+*nsbin* = 9, then the first bin spans :math:`1.0 < r < 2.0`, and the last bin
+spans :math:`9.0 < r < 10.0`.  The geometry of the bins is the same whether the
+simulation box is orthogonal or triclinic (i.e., the spherical shells
 are not tilted or scaled differently in different dimensions to
-transform them into ellipsoidal shells.
+transform them into ellipsoidal shells).
 
 The *bin/cylinder* style defines bins for a cylinder oriented along
 the axis *dim* with the axis coordinates in the other two radial
-dimensions at (\ *c1*,\ *c2*\ ).  For dim = x, c1/c2 = y/z; for dim = y,
-c1/c2 = x/z; for dim = z, c1/c2 = x/y.  This is effectively a 2d array
-of bins.  The first dimension is along the cylinder axis, the second
-dimension is radially outward from the cylinder axis.  The bin size
-and positions along the cylinder axis are specified by the *origin*
-and *delta* values, the same as for the *bin/1d*, *bin/2d*, and
-*bin/3d* styles.  There are *ncbin* concentric circle bins in the
+dimensions at (\ *c1*,\ *c2*\ ).  For dim = *x*, :math:`c_1/c_2 = y/z`;
+for dim = *y*, :math:`c_1/c_2 = x/z`; for dim = *z*,
+:math:`c_1/c_2 = x/y`.  This is effectively a 2d array of bins.  The first
+dimension is along the cylinder axis, the second dimension is radially outward
+from the cylinder axis.  The bin size and positions along the cylinder axis are
+specified by the *origin* and *delta* values, the same as for the *bin/1d*,
+*bin/2d*, and *bin/3d* styles.  There are *ncbin* concentric circle bins in the
 radial direction from the cylinder axis with radii equally spaced
 between *crmin* and *crmax*\ .  For example, if *crmin* = 1.0 and
-*crmax* = 10.0 and *ncbin* = 9, then the first bin spans 1.0 < r <
-2.0, and the last bin spans 9.0 < r 10.0.  The geometry of the bins in
+*crmax* = 10.0 and *ncbin* = 9, then the first bin spans :math:`1.0 < r < 2.0`
+and the last bin spans :math:`9.0 < r < 10.0`.  The geometry of the bins in
 the radial dimensions is the same whether the simulation box is
-orthogonal or triclinic; i.e. the concentric circles are not tilted or
+orthogonal or triclinic (i.e., the concentric circles are not tilted or
 scaled differently in the two different dimensions to transform them
-into ellipses.
+into ellipses).
 
 The created bins (and hence the chunk IDs) are numbered consecutively
 from 1 to the number of bins = *Nchunk*\ .  For *bin2d* and *bin3d*, the
 numbering varies most rapidly in the first dimension (which could be
-x, y, or z), next rapidly in the second dimension, and most slowly in the
+*x*, *y*, or *z*), next rapidly in the second dimension, and most slowly in the
 third dimension.  For *bin/sphere*, the bin with smallest radii is chunk
-1 and the bni with largest radii is chunk Nchunk = *ncbin*\ .  For
+1 and the bin with largest radii is chunk Nchunk = *ncbin*\ .  For
 *bin/cylinder*, the numbering varies most rapidly in the dimension
 along the cylinder axis and most slowly in the radial direction.
 
@@ -236,8 +237,8 @@ assigned to the atom.
 ----------
 
 The *type* style uses the atom type as the chunk ID.  *Nchunk* is set
-to the number of atom types defined for the simulation, e.g. via the
-:doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands.
+to the number of atom types defined for the simulation (e.g., via the
+:doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands).
 
 ----------
 
@@ -264,8 +265,8 @@ on a quantity calculated and stored by a compute, fix, or variable.
 In each case, it must be a per-atom quantity.  In each case the
 referenced floating point values are converted to an integer chunk ID
 as follows.  The floating point value is truncated (rounded down) to
-an integer value.  If the integer value is <= 0, then a chunk ID of 0
-is assigned to the atom.  If the integer value is > 0, it becomes the
+an integer value.  If the integer value is :math:`\le 0`, then a chunk ID of 0
+is assigned to the atom.  If the integer value is :math:`> 0`, it becomes the
 chunk ID to the atom.  *Nchunk* is set to the largest chunk ID.  Note
 that this excludes atoms which are not in the specified group or
 optional region.
@@ -362,7 +363,7 @@ If *limit* is set to *Nc* = 0, then no limit is imposed on *Nchunk*,
 though the *compress* keyword can still be used to reduce *Nchunk*, as
 described below.
 
-If *Nc* > 0, then the effect of the *limit* keyword depends on whether
+If *Nc* :math:`>` 0, then the effect of the *limit* keyword depends on whether
 the *compress* keyword is also used with a setting of *yes*, and
 whether the *compress* keyword is specified before the *limit* keyword
 or after.
@@ -374,7 +375,7 @@ First, here is what occurs if *compress yes* is not set.  If *limit*
 is set to *Nc max*, then *Nchunk* is reset to the smaller of *Nchunk*
 and *Nc*\ .  If *limit* is set to *Nc exact*, then *Nchunk* is reset to
 *Nc*, whether the original *Nchunk* was larger or smaller than *Nc*\ .
-If *Nchunk* shrank due to the *limit* setting, then atom chunk IDs >
+If *Nchunk* shrank due to the *limit* setting, then atom chunk IDs :math:`>`
 *Nchunk* will be reset to 0 or *Nchunk*, depending on the setting of
 the *discard* keyword.  If *Nchunk* grew, there will simply be some
 chunks with no atoms assigned to them.
@@ -384,22 +385,22 @@ If *compress yes* is set, and the *compress* keyword comes before the
 described below, which resets *Nchunk*\ .  The *limit* keyword is then
 applied to the new *Nchunk* value, exactly as described in the
 preceding paragraph.  Note that in this case, all atoms will end up
-with chunk IDs <= *Nc*, but their original values (e.g. molecule ID or
-compute/fix/variable) may have been > *Nc*, because of the compression
-operation.
+with chunk IDs :math:`\le` *Nc*, but their original values (e.g., molecule ID
+or compute/fix/variable) may have been :math:`>` *Nc*, because of the
+compression operation.
 
 If *compress yes* is set, and the *compress* keyword comes after the
 *limit* keyword, then the *limit* value of *Nc* is applied first to
-the uncompressed value of *Nchunk*, but only if *Nc* < *Nchunk*
+the uncompressed value of *Nchunk*, but only if *Nc* :math:`<` *Nchunk*
 (whether *Nc max* or *Nc exact* is used).  This effectively means all
-atoms with chunk IDs > *Nc* have their chunk IDs reset to 0 or *Nc*,
+atoms with chunk IDs :math:`>` *Nc* have their chunk IDs reset to 0 or *Nc*,
 depending on the setting of the *discard* keyword.  The compression
 operation is then performed, which may shrink *Nchunk* further.  If
-the new *Nchunk* < *Nc* and *limit* = *Nc exact* is specified, then
+the new *Nchunk* :math:`<` *Nc* and *limit* = *Nc exact* is specified, then
 *Nchunk* is reset to *Nc*, which results in extra chunks with no atoms
 assigned to them.  Note that in this case, all atoms will end up with
-chunk IDs <= *Nc*, and their original values (e.g. molecule ID or
-compute/fix/variable value) will also have been <= *Nc*\ .
+chunk IDs :math:`\le` *Nc*, and their original values (e.g., molecule ID or
+compute/fix/variable value) will also have been :math:`\le` *Nc*\ .
 
 ----------
 
@@ -601,7 +602,8 @@ be used.  For non-orthogonal (triclinic) simulation boxes, only the
 *reduced* option may be used.
 
 A *box* value selects standard distance units as defined by the
-:doc:`units <units>` command, e.g. Angstroms for units = real or metal.
+:doc:`units <units>` command (e.g., :math:`\mathrm{\mathring A}`
+for units = *real* or *metal*).
 A *lattice* value means the distance units are in lattice spacings.
 The :doc:`lattice <lattice>` command must have been previously used to
 define the lattice spacing.  A *reduced* value means normalized
@@ -615,8 +617,8 @@ scaled by the lattice spacing or reduced value of the *x* dimension.
 
 Note that for the *bin/cylinder* style, the radii *crmin* and *crmax*
 are scaled by the lattice spacing or reduced value of the first
-dimension perpendicular to the cylinder axis.  E.g. y for an x-axis
-cylinder, x for a y-axis cylinder, and x for a z-axis cylinder.
+dimension perpendicular to the cylinder axis (e.g., *y* for an *x*-axis
+cylinder, *x* for a *y*-axis cylinder, and *x* for a *z*-axis cylinder).
 
 ----------