Merge pull request #3184 from akohlmey/next_patch_release

Update version strings for next patch release

.gitattributes

@@ -3,3 +3,9 @@
 .github export-ignore
 .lgtm.yml export-ignore
 SECURITY.md export-ignore
+*       text=auto
+*.jpg   -text
+*.pdf   -text
+*.gz    -text
+*.png   -text
+*.ps    -text

.github/workflows/compile-msvc.yml

@@ -1,5 +1,5 @@
 # GitHub action to build LAMMPS on Windows with Visual C++
-name: "Native Windows Compilation"
+name: "Native Windows Compilation and Unit Tests"
 
 on:
   push:
@@ -17,13 +17,21 @@ jobs:
       with:
         fetch-depth: 2
 
+    - name: Select Python version
+      uses: actions/setup-python@v2
+      with:
+        python-version: '3.10'
+
     - name: Building LAMMPS via CMake
       shell: bash
       run: |
+        python3 -m pip install numpy
         cmake -C cmake/presets/windows.cmake \
+              -D PKG_PYTHON=on \
               -S cmake -B build \
               -D BUILD_SHARED_LIBS=on \
-              -D LAMMPS_EXCEPTIONS=on
+              -D LAMMPS_EXCEPTIONS=on \
+              -D ENABLE_TESTING=on
         cmake --build build --config Release
 
     - name: Run LAMMPS executable
@@ -31,3 +39,8 @@ jobs:
       run: |
         ./build/Release/lmp.exe -h
         ./build/Release/lmp.exe -in bench/in.lj
+
+    - name: Run Unit Tests
+      working-directory: build
+      shell: bash
+      run: ctest -V -C Release

.gitignore

@@ -12,6 +12,7 @@
 *.sif
 *.dll
 *.pyc
+*.whl
 a.out
 __pycache__
 

SECURITY.md

@@ -23,6 +23,10 @@ either a user mistake or a bug in the code.  Bugs can be reported in
 the LAMMPS project
 [issue tracker on GitHub](https://github.com/lammps/lammps/issues).
 
+To mitigate issues with using homoglyphs or bidirectional reordering in
+unicode, which have been demonstrated as a vector to obfuscate and hide
+malicious changes to the source code, all LAMMPS submissions are checked
+for unicode characters and only all-ASCII source code is accepted.
 
 # Version Updates
 

bench/POTENTIALS/ffield.comb

@@ -1,98 +1,98 @@
-# COMB parameters for various elements (Si, Cu, Hf, Ti, Zr, U, O) and mixtures (their oxides and alloys)
-# Edited by Tzu-Ray Shan from MSE, Univ. FL in Apr 2010
-#
-# Elements currently available: Si, Cu, Hf, Ti, Zr, U, O
-# Oxides   currently available: Si-O, Cu-O, Hf-O, Ti-O
-#
-# Si parameter set from (JG Yu, SB Sinnott, SR Phillpot, Phys. Rev. B 75 085311 2007)
-# 		   ,and (TR Shan, BD Devine, SR Phillpot, SB Sinnott, to be sub to Phys. Rev. B)
-# O  parameter set from (TR Shan, BD Devine, SB Sinnott, SR Phillpot, Phys. Rev. B 81 125328 2010)
-# Cu parameter set from (BD Devine, TR Shan, SB Sinnott, SR Phillpot, to be sub to Phys. Rev. B)
-# Hf parameter set from (TR Shan, BD Devine, SB Sinnott, SR Phillpot, Phys. Rev. B 81 125328 2010)
-# Ti parameter set from (TR Shan, SR Phillpot, SB Sinnott, in preparation)
-# U  parameter set from (Y Li, TR Shan, SB Sinnott, SR Phillpot, in preparation)
-# Zr parameter set from (T Iwasaki, J. Mater. Res. 20 5 1300 2005)
-#
-# Multiple entries can be added to this file, LAMMPS reads the ones it needs
-# Only M-O are added in the potential table, using mixing rules to generate desired alloy (A-B) parameters
-# 8  entries for a desired A-B type: AAA, BBB, AAB, ABA, ABB, BAA, BBA, BBA
-# 27 entries for a system containing three elements A, B and C
-# These entries are in LAMMPS "metal" units
-#
-Hf Hf Hf 1 0 1 0 1.011011 0.046511 0.959614 0.959614 55.9421 55.9421 3.90 0.10 2.069563 2.069563 707.53 707.53 0 0 0.008 0 0 0 1 1 1 1 -4 4 0.26152 -0.25918 -4 4 0.26152 -0.25918 0 3.139520d0 0 0.009410d0 0 0.679131 -3.92875 -3.92875 4.83958 4.83958 12  0.0
-Ti Ti Ti 1 0 1 0 1.255016 0.089078 1.226342 1.226342 99.3916 99.3916 3.40 0.10 2.082408 2.082408 546.386 546.386 0 0 0.0084 0 0 0 1 1 1 1 -4 4 2.508854 -2.511416 -4 4 2.508854 -2.511416 0 2.46820415900968 0 0.151351003255176 0 0.873685 0.392632 0.392632 1.78349 1.78349 12  0.0
-O O O 1 6.6 1 -0.229 1 2 2.68 2.68 260.893 260.893 2.8 0.2 5.36 5.36 3326.69 3326.69 0 0 0 0 0 0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -1.8349 5.5046 0.00148 -0.00112 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -3.922011 0.971086 0.971086 12  0.0
-Cu Cu Cu 1 0 1 0 1 0.140835 1.681711 1.681711 146.987 146.987 2.95 0.05 2.794608 2.794608 952.693 952.693 0.077 0.0095 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -6 2 0.1677645 -0.161007 0 5.946437 0 0 0 0.454784 0.72571 0.72571 0.274649 0.274649 12  -2.0
-Si Si Si 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 1.7322 471.18 471.18 2.90 0.10 2.4799 2.4799 1830.8 1830.8 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -4 4 1.651725 -1.658949 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -0.499378 2.999911 2.999911 12  0.0
-Zr Zr Zr 1 0 1 0 1 0 0.929 0.929 39.9454 39.9454 3.8 0.31 1.857 1.857 382.6 382.6 0 0 0 0 0 0 1 1 1 1 -4 4 1.64 -1.5 -4 4 1.64 -1.5 0 3.139520d0 0 0.009410d0 0 0.679131 -3.92875 -3.92875 4.83958 4.83958 12  0.0
-U U U 1 0 1 0 4.346966 0.77617 0.832 0.832 162.6 162.6 3.9 0.15 1.835 1.835 795.6 795.6 0 0 0 0 0 0 1 1 1 1 -4 4 2 -2 -4 4 2 -2 0 3.139520d0 0 0.009410d0 0 0.679131 -3.92875 -3.92875 4.83958 4.83958 12  0.0
-#                                               
-Si O O 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 2.68 471.18 260.893 2.80 0.25 2.4799 5.36 1830.8 3326.69 0 0 0 109.47 0.3122 0 1 1 1 1 -4 4 1.651725 -1.658949 -1.8349 5.5046 0.00148 -0.00112 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -3.922011 2.999911 0.971086 12 0
-O Si Si 1 6.6 1 -0.229 1 2 2.68 1.7322 260.893 471.18 2.80 0.25 5.36 2.4799 3326.69 1830.8 0 0 0 143.73 2.6 0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -4 4 1.651725 -1.658949 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -0.499378 0.971086 2.999911 12 0
-Si O Si 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 2.68 471.18 260.893 2.80 0.25 2.4799 5.36 1830.8 3326.69 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -1.8349 5.5046 0.00148 -0.00112 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -3.922011 2.999911 0.971086 12 0
-O Si O 1 6.6 1 -0.229 1 2 2.68 1.7322 260.893 471.18 3.20 0.25 5.36 2.4799 3326.69 1830.8 0 0 0 0 0 0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -4 4 1.651725 -1.658949 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -0.499378 0.971086 2.999911 12 0
-Si Si O 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 1.7322 471.18 471.18 2.80 0.25 2.4799 2.4799 1830.8 1830.8 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -4 4 1.651725 -1.658949 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -0.499378 2.999911 2.999911 12 0
-O O Si 1 6.6 1 -0.229 1 2 2.68 2.68 260.893 260.893 2.80 0.25 5.36 5.36 3326.69 3326.69 0 0 0 0 0 0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -1.8349 5.5046 0.00148 -0.00112 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -3.922011 0.971086 0.971086 12 0
-#
-Si Cu Cu 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 1.681711 471.18 146.987 2.70 0.10 2.4799 2.794608 1830.8 952.693 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -6 2 0.1677645 -0.161007 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 0.72571 2.999911 0.274649 12   0
-Cu Si Si 1 0 1 0 1 0.140835 1.681711 1.7322 146.987 471.18 2.70 0.10 2.794608 2.4799 952.693 1830.8 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -4 4 1.651725 -1.658949 0 5.946437 0 0 0 0.454784 0.72571 -0.499378 0.274649 2.999911 12   0
-Si Cu Si 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 1.681711 471.18 146.987 2.70 0.10 2.4799 2.794608 1830.8 952.693 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -6 2 0.1677645 -0.161007 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 0.72571 2.999911 0.274649 12   0
-Cu Si Cu 1 0 1 0 1 0.140835 1.681711 1.7322 146.987 471.18 2.70 0.10 2.794608 2.4799 952.693 1830.8 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -4 4 1.651725 -1.658949 0 5.946437 0 0 0 0.454784 0.72571 -0.499378 0.274649 2.999911 12   0
-Si Si Cu 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 1.7322 471.18 471.18 2.70 0.10 2.4799 2.4799 1830.8 1830.8 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -4 4 1.651725 -1.658949 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -0.499378 2.999911 2.999911 12   0
-Cu Cu Si 1 0 1 0 1 0.140835 1.681711 1.681711 146.987 146.987 2.70 0.10 2.794608 2.794608 952.693 952.693 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -6 2 0.1677645 -0.161007 0 5.946437 0 0 0 0.454784 0.72571 0.72571 0.274649 0.274649 12   0
-#                                                
-Si O Cu 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 2.68 471.18 260.893 2.80 0.10 2.4799 5.36 1830.8 3326.69 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -1.8349 5.5046 0.00148 -0.00112 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -3.922011 2.999911 0.971086 12   0
-Cu O Si 1 0 1 0 1 0.140835 1.681711 2.68 146.987 260.893 2.40 0.10 2.794608 5.36 952.693 3326.69 0 0 0 0 0 0 0.15867 1.106214 0.533319 1.857837 -6 2 0.1677645 -0.161007 -1.8349 5.5046 0.00148 -0.00112 0 5.946437 0 0 0 0.454784 0.72571 -3.922011 0.274649 0.971086 12  0
-Si Cu O 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 1.681711 471.18 146.987 2.70 0.10 2.4799 2.794608 1830.8 952.693 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -6 2 0.1677645 -0.161007 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 0.72571 2.999911 0.274649 12   0
-Cu Si O 1 0 1 0 1 0.140835 1.681711 1.7322 146.987 471.18 2.70 0.10 2.794608 2.4799 952.693 1830.8 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -4 4 1.651725 -1.658949 0 5.946437 0 0 0 0.454784 0.72571 -0.499378 0.274649 2.999911 12   0
-O Si Cu 1 6.6 1 -0.229 1 2 2.68 1.7322 260.893 471.18 2.80 0.10 5.36 2.4799 3326.69 1830.8 0 0 0 0 0 0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -4 4 1.651725 -1.658949 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -0.499378 0.971086 2.999911 12   0
-O Cu Si 1 6.6 1 -0.229 1 2 2.68 1.681711 260.893 146.987 2.40 0.10 5.36 2.794608 3326.69 952.693 0 0 0 0 0 0 0.15867 1.106214 0.533319 1.857837 -1.8349 5.5046 0.00148 -0.00112 -6 2 0.1677645 -0.161007 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 0.72571 0.971086 0.274649 12  0
-#
-Cu O O 1 0 1 0 1 0.140835 1.681711 2.68 146.987 260.893 2.40 0.110 2.794608 5.36 952.693 3326.69 0 0 0 360 3.0 0 0.15867 1.106214 0.533319 1.857837 -6 2 0.1677645 -0.161007 -1.8349 5.5046 0.00148 -0.00112 0 5.946437 0 0 0 0.454784 0.72571 -3.922011 0.274649 0.971086 12  -1.0
-O Cu Cu 1 6.6 1 -0.229 1 2 2.68 1.681711 260.893 146.987 2.40 0.110 5.36 2.794608 3326.69 952.693 0 0 0 109.47 2.98 0 0.15867 1.106214 0.533319 1.857837 -1.8349 5.5046 0.00148 -0.00112 -6 2 0.1677645 -0.161007 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 0.72571 0.971086 0.274649 12  0
-Cu O Cu 1 0 1 0 1 0.140835 1.681711 2.68 146.987 260.893 2.40 0.110 2.794608 5.36 952.693 3326.69 0 0 0 0 0 0 0.15867 1.106214 0.533319 1.857837 -6 2 0.1677645 -0.161007 -1.8349 5.5046 0.00148 -0.00112 0 5.946437 0 0 0 0.454784 0.72571 -3.922011 0.274649 0.971086 12  0
-O Cu O 1 6.6 1 -0.229 1 2 2.68 1.681711 260.893 146.987 2.40 0.110 5.36 2.794608 3326.69 952.693 0 0 0 0 0 0 0.15867 1.106214 0.533319 1.857837 -1.8349 5.5046 0.00148 -0.00112 -6 2 0.1677645 -0.161007 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 0.72571 0.971086 0.274649 12  0
-Cu Cu O 1 0 1 0 1 0.140835 1.681711 1.681711 146.987 146.987 2.90 0.05 2.794608 2.794608 952.693 952.693 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -6 2 0.1677645 -0.161007 0 5.946437 0 0 0 0.454784 0.72571 0.72571 0.274649 0.274649 12  0
-O O Cu 1 6.6 1 -0.229 1 2 2.68 2.68 260.893 260.893 2.80 0.20 5.36 5.36 3326.69 3326.69 0 0 0 0 0 0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -1.8349 5.5046 0.00148 -0.00112 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -3.922011 0.971086 0.971086 12  0
-#
-Si Hf Hf 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 0.959614 471.18 55.9421 3.26 0.15 2.4799 2.069563 1830.8 707.53 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -4 4 0.26152 -0.25918 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -3.92875 2.999911 4.83958 12 0
-Hf Si Si 1 0 1 0 1.011011 0.046511 0.959614 1.7322 55.9421 471.18 3.26 0.15 2.069563 2.4799 707.53 1830.8 0 0 0 0 0 0 1 1 1 1 -4 4 0.26152 -0.25918 -4 4 1.651725 -1.658949 0 3.13952 0 0.00941 0 0.719131 -3.92875 -0.499378 4.83958 2.999911 12 0
-Si Hf Si 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 0.959614 471.18 55.9421 3.26 0.15 2.4799 2.069563 1830.8 707.53 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -4 4 0.26152 -0.25918 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -3.92875 2.999911 4.83958 12 0
-Hf Si Hf 1 0 1 0 1.011011 0.046511 0.959614 1.7322 55.9421 471.18 3.26 0.15 2.069563 2.4799 707.53 1830.8 0 0 0 0 0 0 1 1 1 1 -4 4 0.26152 -0.25918 -4 4 1.651725 -1.658949 0 3.13952 0 0.00941 0 0.719131 -3.92875 -0.499378 4.83958 2.999911 12 0
-Si Si Hf 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 1.7322 471.18 471.18 3.26 0.15 2.4799 2.4799 1830.8 1830.8 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -4 4 1.651725 -1.658949 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -0.499378 2.999911 2.999911 12 0
-Hf Hf Si 1 0 1 0 1.011011 0.046511 0.959614 0.959614 55.9421 55.9421 3.26 0.15 2.069563 2.069563 707.53 707.53 0 0 0 0 0 0 1 1 1 1 -4 4 0.26152 -0.25918 -4 4 0.26152 -0.25918 0 3.13952 0 0.00941 0 0.719131 -3.92875 -3.92875 4.83958 4.83958 12 0
-#
-Si O Hf 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 2.68 471.18 260.893 3.196 0.21 2.4799 5.36 1830.8 3326.69 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -1.8349 5.5046 0.00148 -0.00112 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -3.922011 2.999911 0.971086 12 0
-Hf O Si 1 0 1 0 1.011011 0.046511 0.959614 2.68 55.9421 260.893 3.196 0.21 2.069563 5.36 707.53 3326.69 0 0 0 0 0 0.14 1 1 1 1 -4 4 0.26152 -0.25918 -1.8349 5.5046 0.00148 -0.00112 0 3.13952 0 0.00941 0 0.719131 -3.92875 -3.922011 4.83958 0.971086 12  0.16
-Si Hf O 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 0.959614 471.18 55.9421 3.26 0.15 2.4799 2.069563 1830.8 707.53 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -4 4 0.26152 -0.25918 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -3.92875 2.999911 4.83958 12 0
-Hf Si O 1 0 1 0 1.011011 0.046511 0.959614 1.7322 55.9421 471.18 3.26 0.15 2.069563 2.4799 707.53 1830.8 0 0 0 0 0 0 1 1 1 1 -4 4 0.26152 -0.25918 -4 4 1.651725 -1.658949 0 3.13952 0 0.00941 0 0.719131 -3.92875 -0.499378 4.83958 2.999911 12 0
-O Si Hf 1 6.6 1 -0.229 1 2 2.68 1.7322 260.893 471.18 3.196 0.21 5.36 2.4799 3326.69 1830.8 0 0 0 0 0 0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -4 4 1.651725 -1.658949 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -0.499378 0.971086 2.999911 12 0
-O Hf Si 1 6.6 1 -0.229 1 2 2.68 0.959614 260.893 55.9421 3.196 0.21 5.36 2.069563 3326.69 707.53 0 0 0 0 0 0.14 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -4 4 0.26152 -0.25918 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -3.92875 0.971086 4.83958 12 0.16
-#
-Hf O O 1 0 1 0 1.011011 0.046511 0.959614 2.68 55.9421 260.893 3.29 0.12 2.069563 5.36 707.53 3326.69 0 0 0 0 0 0.14 1 1 1 1 -4 4 0.26152 -0.25918 -1.8349 5.5046 0.00148 -0.00112 0 3.13952 0 0.00941 0 0.679131 -3.92875 -3.922011 4.83958 0.971086 12  0.30
-O Hf Hf 1 6.6 1 -0.229 1 2 2.68 0.959614 260.893 55.9421 3.29 0.12 5.36 2.069563 3326.69 707.53 0 0 0 0 0 0.14 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -4 4 0.26152 -0.25918 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -3.92875 0.971086 4.83958 12  0.30
-Hf O Hf 1 0 1 0 1.011011 0.046511 0.959614 2.68 55.9421 260.893 3.29 0.12 2.069563 5.36 707.53 3326.69 0 0 0 0 0 0.14 1 1 1 1 -4 4 0.26152 -0.25918 -1.8349 5.5046 0.00148 -0.00112 0 3.13952 0 0.00941 0 0.679131 -3.92875 -3.922011 4.83958 0.971086 12  0.30
-O Hf O 1 6.6 1 -0.229 1 2 2.68 0.959614 260.893 55.9421 3.29 0.12 5.36 2.069563 3326.69 707.53 0 0 0 0 0 0.14 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -4 4 0.26152 -0.25918 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -3.92875 0.971086 4.83958 12  0.30
-Hf Hf O 1 0 1 0 1.011011 0.046511 0.959614 0.959614 55.9421 55.9421 3.29 0.12 2.069563 2.069563 707.53 707.53 0 0 0 0 0 0.0 1 1 1 1 -4 4 0.26152 -0.25918 -4 4 0.26152 -0.25918 0 3.13952 0 0.00941 0 0.679131 -3.92875 -3.92875 4.83958 4.83958 12  0.30
-O O Hf 1 6.6 1 -0.229 1 2 2.68 2.68 260.893 260.893 3.29 0.12 5.36 5.36 3326.69 3326.69 0 0 0 0 0 0.0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -1.8349 5.5046 0.00148 -0.00112 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -3.922011 0.971086 0.971086 12  0.30
-#
-Ti O O 1 0 1 0 1.255016 0.089078 1.226342 2.68 99.3916 260.893 3.25 0.10 2.082408 5.36 546.386 3326.69 0 0 0 90 0.403105 8.45  0.088406 0.969934 0.296577 1.326746 -4 4 2.508854 -2.511416 -1.8349 5.5046 0.00148 -0.00112 0 1.943430774 0 0.254695274 0 0.873685 0.392632 -3.922011 1.78349 0.971086 12  0.0
-O Ti Ti 1 6.6 1 -0.229 1 2 2.68 1.226342 260.893 99.3916 3.25 0.10 5.36 2.082408 3326.69 546.386 0 0 0 130.54 0.202777 8.45  0.088406 0.969934 0.296577 1.326746 -1.8349 5.5046 0.00148 -0.00112 -4 4 2.508854 -2.511416 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 0.392632 0.971086 1.78349 12  0.0
-Ti O Ti 1 0 1 0 1.255016 0.089078 1.226342 2.68 99.3916 260.893 3.25 0.10 2.082408 5.36 546.386 3326.69 0 0 0 0 0 8.45  0.088406 0.969934 0.296577 1.326746 -4 4 2.508854 -2.511416 -1.8349 5.5046 0.00148 -0.00112 0 1.943430774 0 0.254695274 0 0.873685 0.392632 -3.922011 1.78349 0.971086 12  0.0
-O Ti O 1 6.6 1 -0.229 1 2 2.68 1.226342 260.893 99.3916 3.25 0.10 5.36 2.082408 3326.69 546.386 0 0 0 0 0 8.45  0.088406 0.969934 0.296577 1.326746 -1.8349 5.5046 0.00148 -0.00112 -4 4 2.508854 -2.511416 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 0.392632 0.971086 1.78349 12  0.0
-Ti Ti O 1 0 1 0 1.255016 0.089078 1.226342 1.226342 99.3916 99.3916 3.25 0.10 2.082408 2.082408 546.386 546.386 0 0 0 0 0 0 1 1 1 1 -4 4 2.508854 -2.511416 -4 4 2.508854 -2.511416 0 1.943430774 0 0.254695274 0 0.873685 0.392632 0.392632 1.78349 1.78349 12  0.0
-O O Ti 1 6.6 1 -0.229 1 2 2.68 2.68 260.893 260.893 2.80 0.20 5.36 5.36 3326.69 3326.69 0 0 0 0 0 0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -1.8349 5.5046 0.00148 -0.00112 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -3.922011 0.971086 0.971086 12  0.0
-#
-Ti Cu Cu 1 0 1 0 1.255016 0.089078 1.226342 1.681711 99.3916 146.987 3.40 0.15 2.082408 2.794608 546.386 952.693 0 0 0 0 0 0 1 1 1 1 -4 4 2.508854 -2.511416 -6 2 0.1677645 -0.161007 0 1.943430774 0 0.254695274 0 0.873685 0.392632 0.72571 1.78349 0.274649 12 0
-Cu Ti Ti 1 0 1 0 1 0.140835 1.681711 1.226342 146.987 99.3916 3.40 0.15 2.794608 2.082408 952.693 546.386 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -4 4 2.508854 -2.511416 0 5.946437 0 0 0 0.454784 0.72571 0.392632 0.274649 1.78349 12 0
-Ti Cu Ti 1 0 1 0 1.255016 0.089078 1.226342 1.681711 99.3916 146.987 3.40 0.15 2.082408 2.794608 546.386 952.693 0 0 0 0 0 0 1 1 1 1 -4 4 2.508854 -2.511416 -6 2 0.1677645 -0.161007 0 1.943430774 0 0.254695274 0 0.873685 0.392632 0.72571 1.78349 0.274649 12 0
-Cu Ti Cu 1 0 1 0 1 0.140835 1.681711 1.226342 146.987 99.3916 3.40 0.15 2.794608 2.082408 952.693 546.386 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -4 4 2.508854 -2.511416 0 5.946437 0 0 0 0.454784 0.72571 0.392632 0.274649 1.78349 12 0
-Ti Ti Cu 1 0 1 0 1.255016 0.089078 1.226342 1.226342 99.3916 99.3916 3.40 0.10 2.082408 2.082408 546.386 546.386 0 0 0 0 0 0 1 1 1 1 -4 4 2.508854 -2.511416 -4 4 2.508854 -2.511416 0 1.943430774 0 0.254695274 0 0.873685 0.392632 0.392632 1.78349 1.78349 12 0
-Cu Cu Ti 1 0 1 0 1 0.140835 1.681711 1.681711 146.987 146.987 2.90 0.05 2.794608 2.794608 952.693 952.693 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -6 2 0.1677645 -0.161007 0 5.946437 0 0 0 0.454784 0.72571 0.72571 0.274649 0.274649 12 0
-#                                                
-Ti O Cu 1 0 1 0 1.255016 0.089078 1.226342 2.68 99.3916 260.893 3.25 0.10 2.082408 5.36 546.386 3326.69 0 0 0 0 0  8.45  0.088406 0.969934 0.296577 1.326746 -4 4 2.508854 -2.511416 -1.8349 5.5046 0.00148 -0.00112 0 1.943430774 0 0.254695274 0 0.873685 0.392632 -3.922011 1.78349 0.971086 12 0
-Cu O Ti 1 0 1 0 1 0.140835 1.681711 2.68 146.987 260.893 2.40 0.10 2.794608 5.36 952.693 3326.69 0 0 0 0 0 0 0.15867 1.106214 0.533319 1.857837 -6 2 0.1677645 -0.161007 -1.8349 5.5046 0.00148 -0.00112 0 5.946437 0 0 0 0.454784 0.72571 -3.922011 0.274649 0.971086 12  0
-Ti Cu O 1 0 1 0 1.255016 0.089078 1.226342 1.681711 99.3916 146.987 3.40 0.15 2.082408 2.794608 546.386 952.693 0 0 0 0 0 0 1 1 1 1 -4 4 2.508854 -2.511416 -6 2 0.1677645 -0.161007 0 1.943430774 0 0.254695274 0 0.873685 0.392632 0.72571 1.78349 0.274649 12 0
-Cu Ti O 1 0 1 0 1 0.140835 1.681711 1.226342 146.987 99.3916 3.40 0.15 2.794608 2.082408 952.693 546.386 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -4 4 2.508854 -2.511416 0 5.946437 0 0 0 0.454784 0.72571 0.392632 0.274649 1.78349 12 0
-O Ti Cu 1 6.6 1 -0.229 1 2 2.68 1.226342 260.893 99.3916 3.25 0.10 5.36 2.082408 3326.69 546.386 0 0 0 0 0  8.45  0.088406 0.969934 0.296577 1.326746 -1.8349 5.5046 0.00148 -0.00112 -4 4 2.508854 -2.511416 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 0.392632 0.971086 1.78349 12 0
-O Cu Ti 1 6.6 1 -0.229 1 2 2.68 1.681711 260.893 146.987 2.40 0.10 5.36 2.794608 3326.69 952.693 0 0 0 0 0 0 0.15867 1.106214 0.533319 1.857837 -1.8349 5.5046 0.00148 -0.00112 -6 2 0.1677645 -0.161007 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 0.72571 0.971086 0.274649 12  0
+# COMB parameters for various elements (Si, Cu, Hf, Ti, Zr, U, O) and mixtures (their oxides and alloys)
+# Edited by Tzu-Ray Shan from MSE, Univ. FL in Apr 2010
+#
+# Elements currently available: Si, Cu, Hf, Ti, Zr, U, O
+# Oxides   currently available: Si-O, Cu-O, Hf-O, Ti-O
+#
+# Si parameter set from (JG Yu, SB Sinnott, SR Phillpot, Phys. Rev. B 75 085311 2007)
+# 		   ,and (TR Shan, BD Devine, SR Phillpot, SB Sinnott, to be sub to Phys. Rev. B)
+# O  parameter set from (TR Shan, BD Devine, SB Sinnott, SR Phillpot, Phys. Rev. B 81 125328 2010)
+# Cu parameter set from (BD Devine, TR Shan, SB Sinnott, SR Phillpot, to be sub to Phys. Rev. B)
+# Hf parameter set from (TR Shan, BD Devine, SB Sinnott, SR Phillpot, Phys. Rev. B 81 125328 2010)
+# Ti parameter set from (TR Shan, SR Phillpot, SB Sinnott, in preparation)
+# U  parameter set from (Y Li, TR Shan, SB Sinnott, SR Phillpot, in preparation)
+# Zr parameter set from (T Iwasaki, J. Mater. Res. 20 5 1300 2005)
+#
+# Multiple entries can be added to this file, LAMMPS reads the ones it needs
+# Only M-O are added in the potential table, using mixing rules to generate desired alloy (A-B) parameters
+# 8  entries for a desired A-B type: AAA, BBB, AAB, ABA, ABB, BAA, BBA, BBA
+# 27 entries for a system containing three elements A, B and C
+# These entries are in LAMMPS "metal" units
+#
+Hf Hf Hf 1 0 1 0 1.011011 0.046511 0.959614 0.959614 55.9421 55.9421 3.90 0.10 2.069563 2.069563 707.53 707.53 0 0 0.008 0 0 0 1 1 1 1 -4 4 0.26152 -0.25918 -4 4 0.26152 -0.25918 0 3.139520d0 0 0.009410d0 0 0.679131 -3.92875 -3.92875 4.83958 4.83958 12  0.0
+Ti Ti Ti 1 0 1 0 1.255016 0.089078 1.226342 1.226342 99.3916 99.3916 3.40 0.10 2.082408 2.082408 546.386 546.386 0 0 0.0084 0 0 0 1 1 1 1 -4 4 2.508854 -2.511416 -4 4 2.508854 -2.511416 0 2.46820415900968 0 0.151351003255176 0 0.873685 0.392632 0.392632 1.78349 1.78349 12  0.0
+O O O 1 6.6 1 -0.229 1 2 2.68 2.68 260.893 260.893 2.8 0.2 5.36 5.36 3326.69 3326.69 0 0 0 0 0 0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -1.8349 5.5046 0.00148 -0.00112 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -3.922011 0.971086 0.971086 12  0.0
+Cu Cu Cu 1 0 1 0 1 0.140835 1.681711 1.681711 146.987 146.987 2.95 0.05 2.794608 2.794608 952.693 952.693 0.077 0.0095 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -6 2 0.1677645 -0.161007 0 5.946437 0 0 0 0.454784 0.72571 0.72571 0.274649 0.274649 12  -2.0
+Si Si Si 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 1.7322 471.18 471.18 2.90 0.10 2.4799 2.4799 1830.8 1830.8 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -4 4 1.651725 -1.658949 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -0.499378 2.999911 2.999911 12  0.0
+Zr Zr Zr 1 0 1 0 1 0 0.929 0.929 39.9454 39.9454 3.8 0.31 1.857 1.857 382.6 382.6 0 0 0 0 0 0 1 1 1 1 -4 4 1.64 -1.5 -4 4 1.64 -1.5 0 3.139520d0 0 0.009410d0 0 0.679131 -3.92875 -3.92875 4.83958 4.83958 12  0.0
+U U U 1 0 1 0 4.346966 0.77617 0.832 0.832 162.6 162.6 3.9 0.15 1.835 1.835 795.6 795.6 0 0 0 0 0 0 1 1 1 1 -4 4 2 -2 -4 4 2 -2 0 3.139520d0 0 0.009410d0 0 0.679131 -3.92875 -3.92875 4.83958 4.83958 12  0.0
+#                                               
+Si O O 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 2.68 471.18 260.893 2.80 0.25 2.4799 5.36 1830.8 3326.69 0 0 0 109.47 0.3122 0 1 1 1 1 -4 4 1.651725 -1.658949 -1.8349 5.5046 0.00148 -0.00112 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -3.922011 2.999911 0.971086 12 0
+O Si Si 1 6.6 1 -0.229 1 2 2.68 1.7322 260.893 471.18 2.80 0.25 5.36 2.4799 3326.69 1830.8 0 0 0 143.73 2.6 0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -4 4 1.651725 -1.658949 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -0.499378 0.971086 2.999911 12 0
+Si O Si 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 2.68 471.18 260.893 2.80 0.25 2.4799 5.36 1830.8 3326.69 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -1.8349 5.5046 0.00148 -0.00112 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -3.922011 2.999911 0.971086 12 0
+O Si O 1 6.6 1 -0.229 1 2 2.68 1.7322 260.893 471.18 3.20 0.25 5.36 2.4799 3326.69 1830.8 0 0 0 0 0 0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -4 4 1.651725 -1.658949 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -0.499378 0.971086 2.999911 12 0
+Si Si O 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 1.7322 471.18 471.18 2.80 0.25 2.4799 2.4799 1830.8 1830.8 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -4 4 1.651725 -1.658949 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -0.499378 2.999911 2.999911 12 0
+O O Si 1 6.6 1 -0.229 1 2 2.68 2.68 260.893 260.893 2.80 0.25 5.36 5.36 3326.69 3326.69 0 0 0 0 0 0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -1.8349 5.5046 0.00148 -0.00112 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -3.922011 0.971086 0.971086 12 0
+#
+Si Cu Cu 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 1.681711 471.18 146.987 2.70 0.10 2.4799 2.794608 1830.8 952.693 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -6 2 0.1677645 -0.161007 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 0.72571 2.999911 0.274649 12   0
+Cu Si Si 1 0 1 0 1 0.140835 1.681711 1.7322 146.987 471.18 2.70 0.10 2.794608 2.4799 952.693 1830.8 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -4 4 1.651725 -1.658949 0 5.946437 0 0 0 0.454784 0.72571 -0.499378 0.274649 2.999911 12   0
+Si Cu Si 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 1.681711 471.18 146.987 2.70 0.10 2.4799 2.794608 1830.8 952.693 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -6 2 0.1677645 -0.161007 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 0.72571 2.999911 0.274649 12   0
+Cu Si Cu 1 0 1 0 1 0.140835 1.681711 1.7322 146.987 471.18 2.70 0.10 2.794608 2.4799 952.693 1830.8 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -4 4 1.651725 -1.658949 0 5.946437 0 0 0 0.454784 0.72571 -0.499378 0.274649 2.999911 12   0
+Si Si Cu 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 1.7322 471.18 471.18 2.70 0.10 2.4799 2.4799 1830.8 1830.8 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -4 4 1.651725 -1.658949 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -0.499378 2.999911 2.999911 12   0
+Cu Cu Si 1 0 1 0 1 0.140835 1.681711 1.681711 146.987 146.987 2.70 0.10 2.794608 2.794608 952.693 952.693 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -6 2 0.1677645 -0.161007 0 5.946437 0 0 0 0.454784 0.72571 0.72571 0.274649 0.274649 12   0
+#                                                
+Si O Cu 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 2.68 471.18 260.893 2.80 0.10 2.4799 5.36 1830.8 3326.69 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -1.8349 5.5046 0.00148 -0.00112 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -3.922011 2.999911 0.971086 12   0
+Cu O Si 1 0 1 0 1 0.140835 1.681711 2.68 146.987 260.893 2.40 0.10 2.794608 5.36 952.693 3326.69 0 0 0 0 0 0 0.15867 1.106214 0.533319 1.857837 -6 2 0.1677645 -0.161007 -1.8349 5.5046 0.00148 -0.00112 0 5.946437 0 0 0 0.454784 0.72571 -3.922011 0.274649 0.971086 12  0
+Si Cu O 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 1.681711 471.18 146.987 2.70 0.10 2.4799 2.794608 1830.8 952.693 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -6 2 0.1677645 -0.161007 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 0.72571 2.999911 0.274649 12   0
+Cu Si O 1 0 1 0 1 0.140835 1.681711 1.7322 146.987 471.18 2.70 0.10 2.794608 2.4799 952.693 1830.8 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -4 4 1.651725 -1.658949 0 5.946437 0 0 0 0.454784 0.72571 -0.499378 0.274649 2.999911 12   0
+O Si Cu 1 6.6 1 -0.229 1 2 2.68 1.7322 260.893 471.18 2.80 0.10 5.36 2.4799 3326.69 1830.8 0 0 0 0 0 0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -4 4 1.651725 -1.658949 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -0.499378 0.971086 2.999911 12   0
+O Cu Si 1 6.6 1 -0.229 1 2 2.68 1.681711 260.893 146.987 2.40 0.10 5.36 2.794608 3326.69 952.693 0 0 0 0 0 0 0.15867 1.106214 0.533319 1.857837 -1.8349 5.5046 0.00148 -0.00112 -6 2 0.1677645 -0.161007 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 0.72571 0.971086 0.274649 12  0
+#
+Cu O O 1 0 1 0 1 0.140835 1.681711 2.68 146.987 260.893 2.40 0.110 2.794608 5.36 952.693 3326.69 0 0 0 360 3.0 0 0.15867 1.106214 0.533319 1.857837 -6 2 0.1677645 -0.161007 -1.8349 5.5046 0.00148 -0.00112 0 5.946437 0 0 0 0.454784 0.72571 -3.922011 0.274649 0.971086 12  -1.0
+O Cu Cu 1 6.6 1 -0.229 1 2 2.68 1.681711 260.893 146.987 2.40 0.110 5.36 2.794608 3326.69 952.693 0 0 0 109.47 2.98 0 0.15867 1.106214 0.533319 1.857837 -1.8349 5.5046 0.00148 -0.00112 -6 2 0.1677645 -0.161007 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 0.72571 0.971086 0.274649 12  0
+Cu O Cu 1 0 1 0 1 0.140835 1.681711 2.68 146.987 260.893 2.40 0.110 2.794608 5.36 952.693 3326.69 0 0 0 0 0 0 0.15867 1.106214 0.533319 1.857837 -6 2 0.1677645 -0.161007 -1.8349 5.5046 0.00148 -0.00112 0 5.946437 0 0 0 0.454784 0.72571 -3.922011 0.274649 0.971086 12  0
+O Cu O 1 6.6 1 -0.229 1 2 2.68 1.681711 260.893 146.987 2.40 0.110 5.36 2.794608 3326.69 952.693 0 0 0 0 0 0 0.15867 1.106214 0.533319 1.857837 -1.8349 5.5046 0.00148 -0.00112 -6 2 0.1677645 -0.161007 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 0.72571 0.971086 0.274649 12  0
+Cu Cu O 1 0 1 0 1 0.140835 1.681711 1.681711 146.987 146.987 2.90 0.05 2.794608 2.794608 952.693 952.693 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -6 2 0.1677645 -0.161007 0 5.946437 0 0 0 0.454784 0.72571 0.72571 0.274649 0.274649 12  0
+O O Cu 1 6.6 1 -0.229 1 2 2.68 2.68 260.893 260.893 2.80 0.20 5.36 5.36 3326.69 3326.69 0 0 0 0 0 0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -1.8349 5.5046 0.00148 -0.00112 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -3.922011 0.971086 0.971086 12  0
+#
+Si Hf Hf 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 0.959614 471.18 55.9421 3.26 0.15 2.4799 2.069563 1830.8 707.53 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -4 4 0.26152 -0.25918 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -3.92875 2.999911 4.83958 12 0
+Hf Si Si 1 0 1 0 1.011011 0.046511 0.959614 1.7322 55.9421 471.18 3.26 0.15 2.069563 2.4799 707.53 1830.8 0 0 0 0 0 0 1 1 1 1 -4 4 0.26152 -0.25918 -4 4 1.651725 -1.658949 0 3.13952 0 0.00941 0 0.719131 -3.92875 -0.499378 4.83958 2.999911 12 0
+Si Hf Si 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 0.959614 471.18 55.9421 3.26 0.15 2.4799 2.069563 1830.8 707.53 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -4 4 0.26152 -0.25918 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -3.92875 2.999911 4.83958 12 0
+Hf Si Hf 1 0 1 0 1.011011 0.046511 0.959614 1.7322 55.9421 471.18 3.26 0.15 2.069563 2.4799 707.53 1830.8 0 0 0 0 0 0 1 1 1 1 -4 4 0.26152 -0.25918 -4 4 1.651725 -1.658949 0 3.13952 0 0.00941 0 0.719131 -3.92875 -0.499378 4.83958 2.999911 12 0
+Si Si Hf 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 1.7322 471.18 471.18 3.26 0.15 2.4799 2.4799 1830.8 1830.8 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -4 4 1.651725 -1.658949 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -0.499378 2.999911 2.999911 12 0
+Hf Hf Si 1 0 1 0 1.011011 0.046511 0.959614 0.959614 55.9421 55.9421 3.26 0.15 2.069563 2.069563 707.53 707.53 0 0 0 0 0 0 1 1 1 1 -4 4 0.26152 -0.25918 -4 4 0.26152 -0.25918 0 3.13952 0 0.00941 0 0.719131 -3.92875 -3.92875 4.83958 4.83958 12 0
+#
+Si O Hf 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 2.68 471.18 260.893 3.196 0.21 2.4799 5.36 1830.8 3326.69 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -1.8349 5.5046 0.00148 -0.00112 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -3.922011 2.999911 0.971086 12 0
+Hf O Si 1 0 1 0 1.011011 0.046511 0.959614 2.68 55.9421 260.893 3.196 0.21 2.069563 5.36 707.53 3326.69 0 0 0 0 0 0.14 1 1 1 1 -4 4 0.26152 -0.25918 -1.8349 5.5046 0.00148 -0.00112 0 3.13952 0 0.00941 0 0.719131 -3.92875 -3.922011 4.83958 0.971086 12  0.16
+Si Hf O 3 100390 16.218 -0.59826 0.78734 1.0999E-06 1.7322 0.959614 471.18 55.9421 3.26 0.15 2.4799 2.069563 1830.8 707.53 0 0 0 0 0 0 1 1 1 1 -4 4 1.651725 -1.658949 -4 4 0.26152 -0.25918 0 3.625144859 0 0.087067714 0 0.772871 -0.499378 -3.92875 2.999911 4.83958 12 0
+Hf Si O 1 0 1 0 1.011011 0.046511 0.959614 1.7322 55.9421 471.18 3.26 0.15 2.069563 2.4799 707.53 1830.8 0 0 0 0 0 0 1 1 1 1 -4 4 0.26152 -0.25918 -4 4 1.651725 -1.658949 0 3.13952 0 0.00941 0 0.719131 -3.92875 -0.499378 4.83958 2.999911 12 0
+O Si Hf 1 6.6 1 -0.229 1 2 2.68 1.7322 260.893 471.18 3.196 0.21 5.36 2.4799 3326.69 1830.8 0 0 0 0 0 0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -4 4 1.651725 -1.658949 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -0.499378 0.971086 2.999911 12 0
+O Hf Si 1 6.6 1 -0.229 1 2 2.68 0.959614 260.893 55.9421 3.196 0.21 5.36 2.069563 3326.69 707.53 0 0 0 0 0 0.14 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -4 4 0.26152 -0.25918 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -3.92875 0.971086 4.83958 12 0.16
+#
+Hf O O 1 0 1 0 1.011011 0.046511 0.959614 2.68 55.9421 260.893 3.29 0.12 2.069563 5.36 707.53 3326.69 0 0 0 0 0 0.14 1 1 1 1 -4 4 0.26152 -0.25918 -1.8349 5.5046 0.00148 -0.00112 0 3.13952 0 0.00941 0 0.679131 -3.92875 -3.922011 4.83958 0.971086 12  0.30
+O Hf Hf 1 6.6 1 -0.229 1 2 2.68 0.959614 260.893 55.9421 3.29 0.12 5.36 2.069563 3326.69 707.53 0 0 0 0 0 0.14 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -4 4 0.26152 -0.25918 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -3.92875 0.971086 4.83958 12  0.30
+Hf O Hf 1 0 1 0 1.011011 0.046511 0.959614 2.68 55.9421 260.893 3.29 0.12 2.069563 5.36 707.53 3326.69 0 0 0 0 0 0.14 1 1 1 1 -4 4 0.26152 -0.25918 -1.8349 5.5046 0.00148 -0.00112 0 3.13952 0 0.00941 0 0.679131 -3.92875 -3.922011 4.83958 0.971086 12  0.30
+O Hf O 1 6.6 1 -0.229 1 2 2.68 0.959614 260.893 55.9421 3.29 0.12 5.36 2.069563 3326.69 707.53 0 0 0 0 0 0.14 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -4 4 0.26152 -0.25918 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -3.92875 0.971086 4.83958 12  0.30
+Hf Hf O 1 0 1 0 1.011011 0.046511 0.959614 0.959614 55.9421 55.9421 3.29 0.12 2.069563 2.069563 707.53 707.53 0 0 0 0 0 0.0 1 1 1 1 -4 4 0.26152 -0.25918 -4 4 0.26152 -0.25918 0 3.13952 0 0.00941 0 0.679131 -3.92875 -3.92875 4.83958 4.83958 12  0.30
+O O Hf 1 6.6 1 -0.229 1 2 2.68 2.68 260.893 260.893 3.29 0.12 5.36 5.36 3326.69 3326.69 0 0 0 0 0 0.0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -1.8349 5.5046 0.00148 -0.00112 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -3.922011 0.971086 0.971086 12  0.30
+#
+Ti O O 1 0 1 0 1.255016 0.089078 1.226342 2.68 99.3916 260.893 3.25 0.10 2.082408 5.36 546.386 3326.69 0 0 0 90 0.403105 8.45  0.088406 0.969934 0.296577 1.326746 -4 4 2.508854 -2.511416 -1.8349 5.5046 0.00148 -0.00112 0 1.943430774 0 0.254695274 0 0.873685 0.392632 -3.922011 1.78349 0.971086 12  0.0
+O Ti Ti 1 6.6 1 -0.229 1 2 2.68 1.226342 260.893 99.3916 3.25 0.10 5.36 2.082408 3326.69 546.386 0 0 0 130.54 0.202777 8.45  0.088406 0.969934 0.296577 1.326746 -1.8349 5.5046 0.00148 -0.00112 -4 4 2.508854 -2.511416 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 0.392632 0.971086 1.78349 12  0.0
+Ti O Ti 1 0 1 0 1.255016 0.089078 1.226342 2.68 99.3916 260.893 3.25 0.10 2.082408 5.36 546.386 3326.69 0 0 0 0 0 8.45  0.088406 0.969934 0.296577 1.326746 -4 4 2.508854 -2.511416 -1.8349 5.5046 0.00148 -0.00112 0 1.943430774 0 0.254695274 0 0.873685 0.392632 -3.922011 1.78349 0.971086 12  0.0
+O Ti O 1 6.6 1 -0.229 1 2 2.68 1.226342 260.893 99.3916 3.25 0.10 5.36 2.082408 3326.69 546.386 0 0 0 0 0 8.45  0.088406 0.969934 0.296577 1.326746 -1.8349 5.5046 0.00148 -0.00112 -4 4 2.508854 -2.511416 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 0.392632 0.971086 1.78349 12  0.0
+Ti Ti O 1 0 1 0 1.255016 0.089078 1.226342 1.226342 99.3916 99.3916 3.25 0.10 2.082408 2.082408 546.386 546.386 0 0 0 0 0 0 1 1 1 1 -4 4 2.508854 -2.511416 -4 4 2.508854 -2.511416 0 1.943430774 0 0.254695274 0 0.873685 0.392632 0.392632 1.78349 1.78349 12  0.0
+O O Ti 1 6.6 1 -0.229 1 2 2.68 2.68 260.893 260.893 2.80 0.20 5.36 5.36 3326.69 3326.69 0 0 0 0 0 0 1 1 1 1 -1.8349 5.5046 0.00148 -0.00112 -1.8349 5.5046 0.00148 -0.00112 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 -3.922011 0.971086 0.971086 12  0.0
+#
+Ti Cu Cu 1 0 1 0 1.255016 0.089078 1.226342 1.681711 99.3916 146.987 3.40 0.15 2.082408 2.794608 546.386 952.693 0 0 0 0 0 0 1 1 1 1 -4 4 2.508854 -2.511416 -6 2 0.1677645 -0.161007 0 1.943430774 0 0.254695274 0 0.873685 0.392632 0.72571 1.78349 0.274649 12 0
+Cu Ti Ti 1 0 1 0 1 0.140835 1.681711 1.226342 146.987 99.3916 3.40 0.15 2.794608 2.082408 952.693 546.386 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -4 4 2.508854 -2.511416 0 5.946437 0 0 0 0.454784 0.72571 0.392632 0.274649 1.78349 12 0
+Ti Cu Ti 1 0 1 0 1.255016 0.089078 1.226342 1.681711 99.3916 146.987 3.40 0.15 2.082408 2.794608 546.386 952.693 0 0 0 0 0 0 1 1 1 1 -4 4 2.508854 -2.511416 -6 2 0.1677645 -0.161007 0 1.943430774 0 0.254695274 0 0.873685 0.392632 0.72571 1.78349 0.274649 12 0
+Cu Ti Cu 1 0 1 0 1 0.140835 1.681711 1.226342 146.987 99.3916 3.40 0.15 2.794608 2.082408 952.693 546.386 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -4 4 2.508854 -2.511416 0 5.946437 0 0 0 0.454784 0.72571 0.392632 0.274649 1.78349 12 0
+Ti Ti Cu 1 0 1 0 1.255016 0.089078 1.226342 1.226342 99.3916 99.3916 3.40 0.10 2.082408 2.082408 546.386 546.386 0 0 0 0 0 0 1 1 1 1 -4 4 2.508854 -2.511416 -4 4 2.508854 -2.511416 0 1.943430774 0 0.254695274 0 0.873685 0.392632 0.392632 1.78349 1.78349 12 0
+Cu Cu Ti 1 0 1 0 1 0.140835 1.681711 1.681711 146.987 146.987 2.90 0.05 2.794608 2.794608 952.693 952.693 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -6 2 0.1677645 -0.161007 0 5.946437 0 0 0 0.454784 0.72571 0.72571 0.274649 0.274649 12 0
+#                                                
+Ti O Cu 1 0 1 0 1.255016 0.089078 1.226342 2.68 99.3916 260.893 3.25 0.10 2.082408 5.36 546.386 3326.69 0 0 0 0 0  8.45  0.088406 0.969934 0.296577 1.326746 -4 4 2.508854 -2.511416 -1.8349 5.5046 0.00148 -0.00112 0 1.943430774 0 0.254695274 0 0.873685 0.392632 -3.922011 1.78349 0.971086 12 0
+Cu O Ti 1 0 1 0 1 0.140835 1.681711 2.68 146.987 260.893 2.40 0.10 2.794608 5.36 952.693 3326.69 0 0 0 0 0 0 0.15867 1.106214 0.533319 1.857837 -6 2 0.1677645 -0.161007 -1.8349 5.5046 0.00148 -0.00112 0 5.946437 0 0 0 0.454784 0.72571 -3.922011 0.274649 0.971086 12  0
+Ti Cu O 1 0 1 0 1.255016 0.089078 1.226342 1.681711 99.3916 146.987 3.40 0.15 2.082408 2.794608 546.386 952.693 0 0 0 0 0 0 1 1 1 1 -4 4 2.508854 -2.511416 -6 2 0.1677645 -0.161007 0 1.943430774 0 0.254695274 0 0.873685 0.392632 0.72571 1.78349 0.274649 12 0
+Cu Ti O 1 0 1 0 1 0.140835 1.681711 1.226342 146.987 99.3916 3.40 0.15 2.794608 2.082408 952.693 546.386 0 0 0 0 0 0 1 1 1 1 -6 2 0.1677645 -0.161007 -4 4 2.508854 -2.511416 0 5.946437 0 0 0 0.454784 0.72571 0.392632 0.274649 1.78349 12 0
+O Ti Cu 1 6.6 1 -0.229 1 2 2.68 1.226342 260.893 99.3916 3.25 0.10 5.36 2.082408 3326.69 546.386 0 0 0 0 0  8.45  0.088406 0.969934 0.296577 1.326746 -1.8349 5.5046 0.00148 -0.00112 -4 4 2.508854 -2.511416 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 0.392632 0.971086 1.78349 12 0
+O Cu Ti 1 6.6 1 -0.229 1 2 2.68 1.681711 260.893 146.987 2.40 0.10 5.36 2.794608 3326.69 952.693 0 0 0 0 0 0 0.15867 1.106214 0.533319 1.857837 -1.8349 5.5046 0.00148 -0.00112 -6 2 0.1677645 -0.161007 5.63441383 7.689598017 4.51426991 1.330079082 0 2.243072 -3.922011 0.72571 0.971086 0.274649 12  0

cmake/CMakeLists.txt

@@ -16,9 +16,13 @@ endif()
 
 project(lammps CXX)
 set(SOVERSION 0)
+get_property(BUILD_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
 
 get_filename_component(LAMMPS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/.. ABSOLUTE)
 get_filename_component(LAMMPS_LIB_BINARY_DIR ${CMAKE_BINARY_DIR}/lib ABSOLUTE)
+# collect all executables and shared libs in the top level build folder
+set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
+set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
 
 set(LAMMPS_SOURCE_DIR     ${LAMMPS_DIR}/src)
 set(LAMMPS_LIB_SOURCE_DIR ${LAMMPS_DIR}/lib)
@@ -133,10 +137,7 @@ endif()
 set(LAMMPS_BINARY lmp${LAMMPS_MACHINE})
 
 option(BUILD_SHARED_LIBS "Build shared library" OFF)
-if(BUILD_SHARED_LIBS) # for all pkg libs, mpi_stubs and linalg
-  set(CMAKE_POSITION_INDEPENDENT_CODE ON)
-endif()
-
+option(CMAKE_POSITION_INDEPENDENT_CODE "Create object compatible with shared libraries" ON)
 option(BUILD_TOOLS "Build and install LAMMPS tools (msi2lmp, binary2txt, chain)" OFF)
 option(BUILD_LAMMPS_SHELL "Build and install the LAMMPS shell" OFF)
 
@@ -283,33 +284,19 @@ if(BUILD_MPI)
   # We use a non-standard procedure to cross-compile with MPI on Windows
   if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
     include(MPI4WIN)
-    target_link_libraries(lammps PUBLIC MPI::MPI_CXX)
   else()
     find_package(MPI REQUIRED)
-    target_link_libraries(lammps PUBLIC MPI::MPI_CXX)
     option(LAMMPS_LONGLONG_TO_LONG "Workaround if your system or MPI version does not recognize 'long long' data types" OFF)
     if(LAMMPS_LONGLONG_TO_LONG)
       target_compile_definitions(lammps PRIVATE -DLAMMPS_LONGLONG_TO_LONG)
     endif()
   endif()
+  target_link_libraries(lammps PUBLIC MPI::MPI_CXX)
 else()
-  file(GLOB MPI_SOURCES ${LAMMPS_SOURCE_DIR}/STUBS/mpi.cpp)
-  add_library(mpi_stubs STATIC ${MPI_SOURCES})
-  set_target_properties(mpi_stubs PROPERTIES OUTPUT_NAME lammps_mpi_stubs${LAMMPS_MACHINE})
-  target_include_directories(mpi_stubs PUBLIC $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
-  if(BUILD_SHARED_LIBS)
-    target_link_libraries(lammps PRIVATE mpi_stubs)
-    if(MSVC)
-      target_link_libraries(lmp PRIVATE mpi_stubs)
-      target_include_directories(lmp INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
-      target_compile_definitions(lmp INTERFACE $<INSTALL_INTERFACE:LAMMPS_LIB_NO_MPI>)
-    endif(MSVC)
-    target_include_directories(lammps INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
-    target_compile_definitions(lammps INTERFACE $<INSTALL_INTERFACE:LAMMPS_LIB_NO_MPI>)
-  else()
-    target_link_libraries(lammps PUBLIC mpi_stubs)
-  endif()
-  add_library(MPI::MPI_CXX ALIAS mpi_stubs)
+  target_sources(lammps PRIVATE ${LAMMPS_SOURCE_DIR}/STUBS/mpi.cpp)
+  add_library(mpi_stubs INTERFACE)
+  target_include_directories(mpi_stubs INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
+  target_link_libraries(lammps PUBLIC mpi_stubs)
 endif()
 
 set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallsmall: all 32-bit, smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
@@ -340,7 +327,6 @@ pkg_depends(ML-IAP ML-SNAP)
 pkg_depends(MPIIO MPI)
 pkg_depends(ATC MANYBODY)
 pkg_depends(LATBOLTZ MPI)
-pkg_depends(PHONON KSPACE)
 pkg_depends(SCAFACOS MPI)
 pkg_depends(DIELECTRIC KSPACE)
 pkg_depends(DIELECTRIC EXTRA-PAIR)
@@ -374,11 +360,13 @@ if(BUILD_OMP)
       ((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 PRIVATE -DLAMMPS_OMP_COMPAT=4)
+    set(LAMMPS_OMP_COMPAT_LEVEL 4)
   else()
-    target_compile_definitions(lammps PRIVATE -DLAMMPS_OMP_COMPAT=3)
+    set(LAMMPS_OMP_COMPAT_LEVEL 3)
   endif()
+  target_compile_definitions(lammps PRIVATE -DLAMMPS_OMP_COMPAT=${LAMMPS_OMP_COMPAT_LEVEL})
   target_link_libraries(lammps PRIVATE OpenMP::OpenMP_CXX)
+  target_link_libraries(lmp PRIVATE OpenMP::OpenMP_CXX)
 endif()
 
 if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_LATTE)
@@ -592,11 +580,10 @@ if(PKG_ATC)
   if(LAMMPS_SIZES STREQUAL "BIGBIG")
     message(FATAL_ERROR "The ATC Package is not compatible with -DLAMMPS_BIGBIG")
   endif()
-  target_link_libraries(atc PRIVATE ${LAPACK_LIBRARIES})
   if(BUILD_MPI)
-    target_link_libraries(atc PRIVATE MPI::MPI_CXX)
+    target_link_libraries(atc PRIVATE ${LAPACK_LIBRARIES} MPI::MPI_CXX)
   else()
-    target_link_libraries(atc PRIVATE mpi_stubs)
+    target_link_libraries(atc PRIVATE ${LAPACK_LIBRARIES} mpi_stubs)
   endif()
   target_include_directories(atc PRIVATE ${LAMMPS_SOURCE_DIR})
   target_compile_definitions(atc PRIVATE -DLAMMPS_${LAMMPS_SIZES})
@@ -610,7 +597,7 @@ endif()
 # packages which selectively include variants based on enabled styles
 # e.g. accelerator packages
 ######################################################################
-foreach(PKG_WITH_INCL CORESHELL QEQ OPENMP DPD-SMOOTH KOKKOS OPT INTEL GPU)
+foreach(PKG_WITH_INCL CORESHELL DPD-SMOOTH PHONON QEQ OPENMP KOKKOS OPT INTEL GPU)
   if(PKG_${PKG_WITH_INCL})
     include(Packages/${PKG_WITH_INCL})
   endif()
@@ -692,6 +679,7 @@ endif()
 
 set_target_properties(lammps PROPERTIES OUTPUT_NAME lammps${LAMMPS_MACHINE})
 set_target_properties(lammps PROPERTIES SOVERSION ${SOVERSION})
+set_target_properties(lammps PROPERTIES PREFIX "lib")
 target_include_directories(lammps PUBLIC $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}/lammps>)
 file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps)
 foreach(_HEADER ${LAMMPS_CXX_HEADERS})
@@ -711,6 +699,9 @@ foreach(_DEF ${LAMMPS_DEFINES})
 endforeach()
 if(BUILD_SHARED_LIBS)
   install(TARGETS lammps EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
+  if(NOT BUILD_MPI)
+    install(TARGETS mpi_stubs EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
+  endif()
   configure_file(pkgconfig/liblammps.pc.in ${CMAKE_CURRENT_BINARY_DIR}/liblammps${LAMMPS_MACHINE}.pc @ONLY)
   install(FILES ${CMAKE_CURRENT_BINARY_DIR}/liblammps${LAMMPS_MACHINE}.pc DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
   install(EXPORT LAMMPS_Targets FILE LAMMPS_Targets.cmake NAMESPACE LAMMPS:: DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/LAMMPS)
@@ -750,7 +741,7 @@ install(
 if(BUILD_SHARED_LIBS)
   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.9 3.8 3.7 3.6 3.5)
+    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})
@@ -758,13 +749,15 @@ if(BUILD_SHARED_LIBS)
   else()
     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})
+  else()
+    set(LIBLAMMPS_SHARED_BINARY ${CMAKE_BINARY_DIR}/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX})
+  endif()
   if(Python_EXECUTABLE)
     add_custom_target(
       install-python ${CMAKE_COMMAND} -E remove_directory build
-      COMMAND ${Python_EXECUTABLE} install.py -v ${LAMMPS_SOURCE_DIR}/version.h
-      -p ${LAMMPS_PYTHON_DIR}/lammps
-      -l ${CMAKE_BINARY_DIR}/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX}
-      WORKING_DIRECTORY  ${LAMMPS_PYTHON_DIR}
+      COMMAND ${Python_EXECUTABLE} ${LAMMPS_PYTHON_DIR}/install.py -p ${LAMMPS_PYTHON_DIR}/lammps -l ${LIBLAMMPS_SHARED_BINARY}
       COMMENT "Installing LAMMPS Python module")
   else()
     add_custom_target(
@@ -809,11 +802,16 @@ if(ClangFormat_FOUND)
 endif()
 
 get_target_property(DEFINES lammps COMPILE_DEFINITIONS)
+if(BUILD_IS_MULTI_CONFIG)
+  set(LAMMPS_BUILD_TYPE "Multi-Config")
+else()
+  set(LAMMPS_BUILD_TYPE ${CMAKE_BUILD_TYPE})
+endif()
 include(FeatureSummary)
 feature_summary(DESCRIPTION "The following tools and libraries have been found and configured:" WHAT PACKAGES_FOUND)
 message(STATUS "<<< Build configuration >>>
    Operating System: ${CMAKE_SYSTEM_NAME} ${CMAKE_LINUX_DISTRO} ${CMAKE_DISTRO_VERSION}
-   Build type:       ${CMAKE_BUILD_TYPE}
+   Build type:       ${LAMMPS_BUILD_TYPE}
    Install path:     ${CMAKE_INSTALL_PREFIX}
    Generator:        ${CMAKE_GENERATOR} using ${CMAKE_MAKE_PROGRAM}")
 ###############################################################################

cmake/CMakeSettings.json

@@ -1,55 +1,156 @@
 {
-    "configurations": [
+  "configurations": [
+    {
+      "name": "x64-Debug-MSVC",
+      "generator": "Ninja",
+      "configurationType": "Debug",
+      "buildRoot": "${workspaceRoot}\\build\\${name}",
+      "installRoot": "${workspaceRoot}\\install\\${name}",
+      "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
+      "buildCommandArgs": "",
+      "ctestCommandArgs": "",
+      "inheritEnvironments": [ "msvc_x64_x64" ],
+      "variables": [
         {
-            "name": "x64-Debug-MSVC",
-            "generator": "Ninja",
-            "configurationType": "Debug",
-            "buildRoot": "${workspaceRoot}\\build\\${name}",
-            "installRoot": "${workspaceRoot}\\install\\${name}",
-            "cmakeCommandArgs": "-S ${workspaceRoot}\\cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
-            "buildCommandArgs": "",
-            "ctestCommandArgs": "",
-            "inheritEnvironments": [ "msvc_x64_x64" ],
-            "variables": [
-                {
-                    "name": "BUILD_SHARED_LIBS",
-                    "value": "True",
-                    "type": "BOOL"
-                },
-                {
-                    "name": "BUILD_TOOLS",
-                    "value": "True",
-                    "type": "BOOL"
-                },
-                {
-                    "name": "LAMMPS_EXCEPTIONS",
-                    "value": "True",
-                    "type": "BOOL"
-                }
-            ]
+          "name": "BUILD_SHARED_LIBS",
+          "value": "True",
+          "type": "BOOL"
         },
         {
-            "name": "x64-Debug-Clang",
-            "generator": "Ninja",
-            "configurationType": "Debug",
-            "buildRoot": "${workspaceRoot}\\build\\${name}",
-            "installRoot": "${workspaceRoot}\\install\\${name}",
-            "cmakeCommandArgs": "-S ${workspaceRoot}\\cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
-            "buildCommandArgs": "",
-            "ctestCommandArgs": "",
-            "inheritEnvironments": [ "clang_cl_x64" ],
-            "variables": [
-                {
-                    "name": "BUILD_TOOLS",
-                    "value": "True",
-                    "type": "BOOL"
-                },
-                {
-                    "name": "LAMMPS_EXCEPTIONS",
-                    "value": "True",
-                    "type": "BOOL"
-                }
-            ]
+          "name": "BUILD_TOOLS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "LAMMPS_EXCEPTIONS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "PKG_PYTHON",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "ENABLE_TESTING",
+          "value": "True",
+          "type": "BOOL"
         }
-    ]
+      ]
+    },
+    {
+      "name": "x64-Release-MSVC",
+      "generator": "Ninja",
+      "configurationType": "Release",
+      "buildRoot": "${workspaceRoot}\\build\\${name}",
+      "installRoot": "${workspaceRoot}\\install\\${name}",
+      "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
+      "buildCommandArgs": "",
+      "ctestCommandArgs": "",
+      "inheritEnvironments": [ "msvc_x64_x64" ],
+      "variables": [
+        {
+          "name": "BUILD_SHARED_LIBS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "BUILD_TOOLS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "LAMMPS_EXCEPTIONS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "PKG_PYTHON",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "ENABLE_TESTING",
+          "value": "True",
+          "type": "BOOL"
+        }
+      ]
+    },
+    {
+      "name": "x64-Debug-Clang",
+      "generator": "Ninja",
+      "configurationType": "Debug",
+      "buildRoot": "${workspaceRoot}\\build\\${name}",
+      "installRoot": "${workspaceRoot}\\install\\${name}",
+      "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DCMAKE_C_COMPILER=clang-cl.exe -DCMAKE_CXX_COMPILER=clang-cl.exe",
+      "buildCommandArgs": "",
+      "ctestCommandArgs": "",
+      "inheritEnvironments": [ "clang_cl_x64" ],
+      "variables": [
+        {
+          "name": "BUILD_SHARED_LIBS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "BUILD_TOOLS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "LAMMPS_EXCEPTIONS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "PKG_PYTHON",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "ENABLE_TESTING",
+          "value": "True",
+          "type": "BOOL"
+        }
+      ]
+    },
+    {
+      "name": "x64-Release-Clang",
+      "generator": "Ninja",
+      "configurationType": "Release",
+      "buildRoot": "${workspaceRoot}\\build\\${name}",
+      "installRoot": "${workspaceRoot}\\install\\${name}",
+      "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DCMAKE_C_COMPILER=clang-cl.exe -DCMAKE_CXX_COMPILER=clang-cl.exe",
+      "buildCommandArgs": "",
+      "ctestCommandArgs": "",
+      "inheritEnvironments": [ "clang_cl_x64" ],
+      "variables": [
+        {
+          "name": "BUILD_SHARED_LIBS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "BUILD_TOOLS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "LAMMPS_EXCEPTIONS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "PKG_PYTHON",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "ENABLE_TESTING",
+          "value": "True",
+          "type": "BOOL"
+        }
+      ]
+    }
+  ]
 }

cmake/Modules/ExternalCMakeProject.cmake

@@ -0,0 +1,33 @@
+# Build a CMake based external library as subdirectory.
+# The sources will be unpacked to ${CMAKE_BINARY_DIR}/_deps/${target}-src
+# The binaries will be built in ${CMAKE_BINARY_DIR}/_deps/${target}-build
+#
+function(ExternalCMakeProject target url hash basedir cmakedir cmakefile)
+  # change settings locally
+  set(BUILD_SHARED_LIBS OFF)
+  set(CMAKE_POSITION_INDEPENDENT_CODE ON)
+
+  get_filename_component(archive ${url} NAME)
+  file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/_deps/src)
+  message(STATUS "Downloading ${url}")
+  file(DOWNLOAD ${url} ${CMAKE_BINARY_DIR}/_deps/${archive} EXPECTED_HASH MD5=${hash} SHOW_PROGRESS)
+  message(STATUS "Unpacking and configuring ${archive}")
+  execute_process(COMMAND ${CMAKE_COMMAND} -E tar xzf ${CMAKE_BINARY_DIR}/_deps/${archive}
+    WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/_deps/src)
+  file(GLOB TARGET_SOURCE "${CMAKE_BINARY_DIR}/_deps/src/${basedir}*")
+  list(LENGTH TARGET_SOURCE _num)
+  if(_num GREATER 1)
+    message(FATAL_ERROR "Inconsistent ${target} library sources. "
+      "Please delete ${CMAKE_BINARY_DIR}/_deps/src and re-run cmake")
+  endif()
+  file(REMOVE_RECURSE ${CMAKE_BINARY_DIR}/_deps/${target}-src)
+  file(RENAME ${TARGET_SOURCE} ${CMAKE_BINARY_DIR}/_deps/${target}-src)
+  if(NOT (cmakefile STREQUAL ""))
+    file(COPY ${cmakefile} DESTINATION ${CMAKE_BINARY_DIR}/_deps/${target}-src/${cmakedir}/)
+    get_filename_component(_cmakefile ${cmakefile} NAME)
+    file(RENAME "${CMAKE_BINARY_DIR}/_deps/${target}-src/${cmakedir}/${_cmakefile}"
+      "${CMAKE_BINARY_DIR}/_deps/${target}-src/${cmakedir}/CMakeLists.txt")
+  endif()
+  add_subdirectory("${CMAKE_BINARY_DIR}/_deps/${target}-src/${cmakedir}"
+    "${CMAKE_BINARY_DIR}/_deps/${target}-build")
+endfunction(ExternalCMakeProject)

cmake/Modules/FindCythonize.cmake

@@ -8,18 +8,19 @@
 #=============================================================================
 
 if(CMAKE_VERSION VERSION_LESS 3.12)
+    set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
     find_package(PythonInterp 3.6 QUIET) # Deprecated since version 3.12
     if(PYTHONINTERP_FOUND)
-        set(Python3_EXECUTABLE ${PYTHON_EXECUTABLE})
+        set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
     endif()
 else()
-    find_package(Python3 3.6 COMPONENTS Interpreter QUIET)
+    find_package(Python 3.6 COMPONENTS Interpreter QUIET)
 endif()
 
 # Use the Cython executable that lives next to the Python executable
 # if it is a local installation.
-if(Python3_EXECUTABLE)
-  get_filename_component(_python_path ${Python3_EXECUTABLE} PATH)
+if(Python_EXECUTABLE)
+  get_filename_component(_python_path ${Python_EXECUTABLE} PATH)
   find_program(Cythonize_EXECUTABLE
     NAMES cythonize3 cythonize cythonize.bat
     HINTS ${_python_path})

cmake/Modules/GTest.cmake

@@ -1,81 +0,0 @@
-message(STATUS "Downloading and building Google Test library")
-
-if(CMAKE_BUILD_TYPE STREQUAL "Debug")
-  set(GTEST_LIB_POSTFIX d)
-else()
-  set(GTEST_LIB_POSTFIX)
-endif()
-
-include(ExternalProject)
-set(GTEST_URL "https://github.com/google/googletest/archive/release-1.11.0.tar.gz" CACHE STRING "URL of googletest source")
-set(GTEST_MD5 "e8a8df240b6938bb6384155d4c37d937" CACHE STRING "MD5 sum for googletest source")
-mark_as_advanced(GTEST_URL)
-mark_as_advanced(GTEST_MD5)
-ExternalProject_Add(googletest
-                    URL             ${GTEST_URL}
-                    URL_MD5         ${GTEST_MD5}
-                    SOURCE_DIR      "${CMAKE_BINARY_DIR}/gtest-src"
-                    BINARY_DIR      "${CMAKE_BINARY_DIR}/gtest-build"
-                    CMAKE_ARGS      ${CMAKE_REQUEST_PIC} ${CMAKE_EXTRA_GTEST_OPTS}
-                                    -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
-                                    -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
-                                    -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-                                    -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
-                                    -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
-                    BUILD_BYPRODUCTS <BINARY_DIR>/lib/libgtest${GTEST_LIB_POSTFIX}${CMAKE_STATIC_LIBRARY_SUFFIX}
-                                     <BINARY_DIR>/lib/libgmock${GTEST_LIB_POSTFIX}${CMAKE_STATIC_LIBRARY_SUFFIX}
-                                     <BINARY_DIR>/lib/libgtest_main${GTEST_LIB_POSTFIX}${CMAKE_STATIC_LIBRARY_SUFFIX}
-                                     <BINARY_DIR>/lib/libgmock_main${GTEST_LIB_POSTFIX}${CMAKE_STATIC_LIBRARY_SUFFIX}
-                    LOG_DOWNLOAD ON
-                    LOG_CONFIGURE ON
-                    LOG_BUILD ON
-                    INSTALL_COMMAND ""
-                    TEST_COMMAND    "")
-
-ExternalProject_Get_Property(googletest SOURCE_DIR)
-set(GTEST_INCLUDE_DIR ${SOURCE_DIR}/googletest/include)
-set(GMOCK_INCLUDE_DIR ${SOURCE_DIR}/googlemock/include)
-
-# workaround for CMake 3.10 on ubuntu 18.04
-file(MAKE_DIRECTORY ${GTEST_INCLUDE_DIR})
-file(MAKE_DIRECTORY ${GMOCK_INCLUDE_DIR})
-
-ExternalProject_Get_Property(googletest BINARY_DIR)
-set(GTEST_LIBRARY_PATH ${BINARY_DIR}/lib/libgtest${GTEST_LIB_POSTFIX}${CMAKE_STATIC_LIBRARY_SUFFIX})
-set(GMOCK_LIBRARY_PATH ${BINARY_DIR}/lib/libgmock${GTEST_LIB_POSTFIX}${CMAKE_STATIC_LIBRARY_SUFFIX})
-set(GTEST_MAIN_LIBRARY_PATH ${BINARY_DIR}/lib/libgtest_main${GTEST_LIB_POSTFIX}${CMAKE_STATIC_LIBRARY_SUFFIX})
-set(GMOCK_MAIN_LIBRARY_PATH ${BINARY_DIR}/lib/libgmock_main${GTEST_LIB_POSTFIX}${CMAKE_STATIC_LIBRARY_SUFFIX})
-
-# Prevent GoogleTest from overriding our compiler/linker options
-# when building with Visual Studio
-set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
-
-find_package(Threads QUIET)
-
-add_library(GTest::GTest UNKNOWN IMPORTED)
-set_target_properties(GTest::GTest PROPERTIES
-        IMPORTED_LOCATION ${GTEST_LIBRARY_PATH}
-        INTERFACE_INCLUDE_DIRECTORIES ${GTEST_INCLUDE_DIR}
-        INTERFACE_LINK_LIBRARIES "${CMAKE_THREAD_LIBS_INIT}")
-add_dependencies(GTest::GTest googletest)
-
-add_library(GTest::GMock UNKNOWN IMPORTED)
-set_target_properties(GTest::GMock PROPERTIES
-        IMPORTED_LOCATION ${GMOCK_LIBRARY_PATH}
-        INTERFACE_INCLUDE_DIRECTORIES ${GMOCK_INCLUDE_DIR}
-        INTERFACE_LINK_LIBRARIES "${CMAKE_THREAD_LIBS_INIT}")
-add_dependencies(GTest::GMock googletest)
-
-add_library(GTest::GTestMain UNKNOWN IMPORTED)
-set_target_properties(GTest::GTestMain PROPERTIES
-        IMPORTED_LOCATION ${GTEST_MAIN_LIBRARY_PATH}
-        INTERFACE_INCLUDE_DIRECTORIES ${GTEST_INCLUDE_DIR}
-        INTERFACE_LINK_LIBRARIES "${CMAKE_THREAD_LIBS_INIT}")
-add_dependencies(GTest::GTestMain googletest)
-
-add_library(GTest::GMockMain UNKNOWN IMPORTED)
-set_target_properties(GTest::GMockMain PROPERTIES
-        IMPORTED_LOCATION ${GMOCK_MAIN_LIBRARY_PATH}
-        INTERFACE_INCLUDE_DIRECTORIES ${GMOCK_INCLUDE_DIR}
-        INTERFACE_LINK_LIBRARIES "${CMAKE_THREAD_LIBS_INIT}")
-add_dependencies(GTest::GMockMain googletest)

cmake/Modules/LAMMPSUtils.cmake

@@ -25,7 +25,7 @@ function(validate_option name values)
 endfunction(validate_option)
 
 function(get_lammps_version version_header variable)
-    file(READ ${version_header} line)
+    file(STRINGS ${version_header} line REGEX LAMMPS_VERSION)
     set(MONTHS x Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec)
     string(REGEX REPLACE "#define LAMMPS_VERSION \"([0-9]+) ([A-Za-z]+) ([0-9]+)\"" "\\1" day "${line}")
     string(REGEX REPLACE "#define LAMMPS_VERSION \"([0-9]+) ([A-Za-z]+) ([0-9]+)\"" "\\2" month "${line}")

cmake/Modules/OpenCLLoader.cmake

@@ -1,50 +1,11 @@
 message(STATUS "Downloading and building OpenCL loader library")
-set(OPENCL_LOADER_URL "${LAMMPS_THIRDPARTY_URL}/opencl-loader-2021.09.18.tar.gz" CACHE STRING "URL for OpenCL loader tarball")
-set(OPENCL_LOADER_MD5 "3b3882627964bd02e5c3b02065daac3c" CACHE STRING "MD5 checksum of OpenCL loader tarball")
+set(OPENCL_LOADER_URL "${LAMMPS_THIRDPARTY_URL}/opencl-loader-2022.01.04.tar.gz" CACHE STRING "URL for OpenCL loader tarball")
+set(OPENCL_LOADER_MD5 "8d3a801e87a2c6653bf0e27707063914" CACHE STRING "MD5 checksum of OpenCL loader tarball")
 mark_as_advanced(OPENCL_LOADER_URL)
 mark_as_advanced(OPENCL_LOADER_MD5)
 
-include(ExternalProject)
-ExternalProject_Add(opencl_loader
-                    URL             ${OPENCL_LOADER_URL}
-                    URL_MD5         ${OPENCL_LOADER_MD5}
-                    SOURCE_DIR      "${CMAKE_BINARY_DIR}/opencl_loader-src"
-                    BINARY_DIR      "${CMAKE_BINARY_DIR}/opencl_loader-build"
-                    CMAKE_ARGS      ${CMAKE_REQUEST_PIC} ${CMAKE_EXTRA_OPENCL_LOADER_OPTS}
-                                    -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
-                                    -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
-                                    -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-                                    -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
-                                    -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
-                    BUILD_BYPRODUCTS <BINARY_DIR>/libOpenCL${CMAKE_STATIC_LIBRARY_SUFFIX}
-                    LOG_DOWNLOAD ON
-                    LOG_CONFIGURE ON
-                    LOG_BUILD ON
-                    INSTALL_COMMAND ""
-                    TEST_COMMAND    "")
-
-ExternalProject_Get_Property(opencl_loader SOURCE_DIR)
-set(OPENCL_LOADER_INCLUDE_DIR ${SOURCE_DIR}/inc)
-
-# workaround for CMake 3.10 on ubuntu 18.04
-file(MAKE_DIRECTORY ${OPENCL_LOADER_INCLUDE_DIR})
-
-ExternalProject_Get_Property(opencl_loader BINARY_DIR)
-set(OPENCL_LOADER_LIBRARY_PATH "${BINARY_DIR}/libOpenCL${CMAKE_STATIC_LIBRARY_SUFFIX}")
-
-find_package(Threads QUIET)
-if(NOT WIN32)
-  set(OPENCL_LOADER_DEP_LIBS "Threads::Threads;${CMAKE_DL_LIBS}")
-else()
-  set(OPENCL_LOADER_DEP_LIBS "cfgmgr32;runtimeobject")
-endif()
-
-add_library(OpenCL::OpenCL UNKNOWN IMPORTED)
-add_dependencies(OpenCL::OpenCL opencl_loader)
-
-set_target_properties(OpenCL::OpenCL PROPERTIES
-  IMPORTED_LOCATION ${OPENCL_LOADER_LIBRARY_PATH}
-  INTERFACE_INCLUDE_DIRECTORIES ${OPENCL_LOADER_INCLUDE_DIR}
-  INTERFACE_LINK_LIBRARIES "${OPENCL_LOADER_DEP_LIBS}")
-
+set(INSTALL_LIBOPENCL OFF CACHE BOOL "" FORCE)
+include(ExternalCMakeProject)
+ExternalCMakeProject(opencl_loader ${OPENCL_LOADER_URL} ${OPENCL_LOADER_MD5} opencl-loader . "")
 
+add_library(OpenCL::OpenCL ALIAS OpenCL)

cmake/Modules/Packages/COMPRESS.cmake

@@ -1,10 +1,11 @@
 find_package(ZLIB REQUIRED)
 target_link_libraries(lammps PRIVATE ZLIB::ZLIB)
 
-find_package(PkgConfig REQUIRED)
-pkg_check_modules(Zstd IMPORTED_TARGET libzstd>=1.4)
-
-if(Zstd_FOUND)
+find_package(PkgConfig QUIET)
+if(PkgConfig_FOUND)
+  pkg_check_modules(Zstd IMPORTED_TARGET libzstd>=1.4)
+  if(Zstd_FOUND)
     target_compile_definitions(lammps PRIVATE -DLAMMPS_ZSTD)
     target_link_libraries(lammps PRIVATE PkgConfig::Zstd)
+  endif()
 endif()

cmake/Modules/Packages/GPU.cmake

@@ -30,7 +30,15 @@ file(GLOB GPU_LIB_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cpp)
 file(MAKE_DIRECTORY ${LAMMPS_LIB_BINARY_DIR}/gpu)
 
 if(GPU_API STREQUAL "CUDA")
-  find_package(CUDA REQUIRED)
+  find_package(CUDA QUIET)
+  # augment search path for CUDA toolkit libraries to include the stub versions. Needed to find libcuda.so on machines without a CUDA driver installation
+  if(CUDA_FOUND)
+    set(CMAKE_LIBRARY_PATH "${CUDA_TOOLKIT_ROOT_DIR}/lib64/stubs;${CUDA_TOOLKIT_ROOT_DIR}/lib/stubs;${CUDA_TOOLKIT_ROOT_DIR}/lib64;${CUDA_TOOLKIT_ROOT_DIR}/lib;${CMAKE_LIBRARY_PATH}")
+    find_package(CUDA REQUIRED)
+  else()
+    message(FATAL_ERROR "CUDA Toolkit not found")
+  endif()
+
   find_program(BIN2C bin2c)
   if(NOT BIN2C)
     message(FATAL_ERROR "Could not find bin2c, use -DBIN2C=/path/to/bin2c to help cmake finding it.")
@@ -306,12 +314,12 @@ elseif(GPU_API STREQUAL "HIP")
 
         if(HIP_COMPILER STREQUAL "clang")
           add_custom_command(OUTPUT ${CUBIN_FILE}
-            VERBATIM COMMAND ${HIP_HIPCC_EXECUTABLE} --genco --offload-arch=${HIP_ARCH} -O3 -ffast-math -DUSE_HIP -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES} -I${LAMMPS_LIB_SOURCE_DIR}/gpu -o ${CUBIN_FILE} ${CU_CPP_FILE}
+            VERBATIM COMMAND ${HIP_HIPCC_EXECUTABLE} --genco --offload-arch=${HIP_ARCH} -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 "Generating ${CU_NAME}.cubin")
         else()
           add_custom_command(OUTPUT ${CUBIN_FILE}
-            VERBATIM COMMAND ${HIP_HIPCC_EXECUTABLE} --genco -t="${HIP_ARCH}" -f=\"-O3 -ffast-math -DUSE_HIP -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES} -I${LAMMPS_LIB_SOURCE_DIR}/gpu\" -o ${CUBIN_FILE} ${CU_CPP_FILE}
+            VERBATIM COMMAND ${HIP_HIPCC_EXECUTABLE} --genco -t="${HIP_ARCH}" -f=\"-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 "Generating ${CU_NAME}.cubin")
         endif()
@@ -422,13 +430,12 @@ RegisterStylesExt(${GPU_SOURCES_DIR} gpu GPU_SOURCES)
 RegisterFixStyle(${GPU_SOURCES_DIR}/fix_gpu.h)
 
 get_property(GPU_SOURCES GLOBAL PROPERTY GPU_SOURCES)
-
-if(NOT BUILD_MPI)
-  # mpistubs is aliased to MPI::MPI_CXX, but older versions of cmake won't work forward the include path
-  target_link_libraries(gpu PRIVATE mpi_stubs)
-else()
+if(BUILD_MPI)
   target_link_libraries(gpu PRIVATE MPI::MPI_CXX)
+else()
+  target_link_libraries(gpu PRIVATE mpi_stubs)
 endif()
+
 target_compile_definitions(gpu PRIVATE -DLAMMPS_${LAMMPS_SIZES})
 set_target_properties(gpu PROPERTIES OUTPUT_NAME lammps_gpu${LAMMPS_MACHINE})
 target_sources(lammps PRIVATE ${GPU_SOURCES})

cmake/Modules/Packages/KOKKOS.cmake

@@ -11,8 +11,14 @@ if(Kokkos_ENABLE_CUDA)
 endif()
 # Adding OpenMP compiler flags without the checks done for
 # BUILD_OMP can result in compile failures. Enforce consistency.
-if(Kokkos_ENABLE_OPENMP AND NOT BUILD_OMP)
-  message(FATAL_ERROR "Must enable BUILD_OMP with Kokkos_ENABLE_OPENMP")
+if(Kokkos_ENABLE_OPENMP)
+  if(NOT BUILD_OMP)
+    message(FATAL_ERROR "Must enable BUILD_OMP with Kokkos_ENABLE_OPENMP")
+  else()
+    if(LAMMPS_OMP_COMPAT_LEVEL LESS 4)
+      message(FATAL_ERROR "Compiler must support OpenMP 4.0 or later with Kokkos_ENABLE_OPENMP")
+    endif()
+  endif()
 endif()
 ########################################################################
 
@@ -27,6 +33,8 @@ if(DOWNLOAD_KOKKOS)
   endforeach()
   message(STATUS "KOKKOS download requested - we will build our own")
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>")
+  # build KOKKOS downloaded libraries as static libraries but with PIC, if needed
+  list(APPEND KOKKOS_LIB_BUILD_ARGS "-DBUILD_SHARED_LIBS=OFF")
   if(CMAKE_REQUEST_PIC)
     list(APPEND KOKKOS_LIB_BUILD_ARGS ${CMAKE_REQUEST_PIC})
   endif()
@@ -39,35 +47,48 @@ 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.4.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "4c84698917c93a18985b311bb6caf84f" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.5.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_MD5 "079323d973ae0e1c38c0a54a150c674e" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   ExternalProject_Add(kokkos_build
     URL     ${KOKKOS_URL}
     URL_MD5 ${KOKKOS_MD5}
     CMAKE_ARGS ${KOKKOS_LIB_BUILD_ARGS}
-    BUILD_BYPRODUCTS <INSTALL_DIR>/lib/libkokkoscore.a
+    BUILD_BYPRODUCTS <INSTALL_DIR>/lib/libkokkoscore.a <INSTALL_DIR>/lib/libkokkoscontainers.a
   )
   ExternalProject_get_property(kokkos_build INSTALL_DIR)
   file(MAKE_DIRECTORY ${INSTALL_DIR}/include)
-  add_library(LAMMPS::KOKKOS UNKNOWN IMPORTED)
-  set_target_properties(LAMMPS::KOKKOS PROPERTIES
+  add_library(LAMMPS::KOKKOSCORE UNKNOWN IMPORTED)
+  add_library(LAMMPS::KOKKOSCONTAINERS UNKNOWN IMPORTED)
+  set_target_properties(LAMMPS::KOKKOSCORE PROPERTIES
     IMPORTED_LOCATION "${INSTALL_DIR}/lib/libkokkoscore.a"
     INTERFACE_INCLUDE_DIRECTORIES "${INSTALL_DIR}/include"
     INTERFACE_LINK_LIBRARIES ${CMAKE_DL_LIBS})
-  target_link_libraries(lammps PRIVATE LAMMPS::KOKKOS)
-  target_link_libraries(lmp PRIVATE LAMMPS::KOKKOS)
-  add_dependencies(LAMMPS::KOKKOS kokkos_build)
+  set_target_properties(LAMMPS::KOKKOSCONTAINERS PROPERTIES
+    IMPORTED_LOCATION "${INSTALL_DIR}/lib/libkokkoscontainers.a")
+  target_link_libraries(lammps PRIVATE LAMMPS::KOKKOSCORE LAMMPS::KOKKOSCONTAINERS)
+  target_link_libraries(lmp PRIVATE LAMMPS::KOKKOSCORE LAMMPS::KOKKOSCONTAINERS)
+  add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
+  add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 3.4.01 REQUIRED CONFIG)
+  find_package(Kokkos 3.5.00 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
   target_link_libraries(lmp PRIVATE Kokkos::kokkos)
 else()
   set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)
   set(LAMMPS_LIB_KOKKOS_BIN_DIR ${LAMMPS_LIB_BINARY_DIR}/kokkos)
+  # build KOKKOS internal libraries as static libraries but with PIC, if needed
+  if(BUILD_SHARED_LIBS)
+    set(BUILD_SHARED_LIBS_WAS_ON YES)
+    set(BUILD_SHARED_LIBS OFF)
+  endif()
+  if(CMAKE_REQUEST_PIC)
+    set(CMAKE_POSITION_INDEPENDENT_CODE ON)
+  endif()
   add_subdirectory(${LAMMPS_LIB_KOKKOS_SRC_DIR} ${LAMMPS_LIB_KOKKOS_BIN_DIR})
 
+
   set(Kokkos_INCLUDE_DIRS ${LAMMPS_LIB_KOKKOS_SRC_DIR}/core/src
                           ${LAMMPS_LIB_KOKKOS_SRC_DIR}/containers/src
                           ${LAMMPS_LIB_KOKKOS_SRC_DIR}/algorithms/src
@@ -75,6 +96,9 @@ else()
   target_include_directories(lammps PRIVATE ${Kokkos_INCLUDE_DIRS})
   target_link_libraries(lammps PRIVATE kokkos)
   target_link_libraries(lmp PRIVATE kokkos)
+  if(BUILD_SHARED_LIBS_WAS_ON)
+    set(BUILD_SHARED_LIBS ON)
+  endif()
 endif()
 target_compile_definitions(lammps PUBLIC $<BUILD_INTERFACE:LMP_KOKKOS>)
 
@@ -109,6 +133,12 @@ if(PKG_KSPACE)
   endif()
 endif()
 
+
+if(PKG_PHONON)
+  list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/dynamical_matrix_kokkos.cpp)
+  list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/third_order_kokkos.cpp)
+endif()
+
 set_property(GLOBAL PROPERTY "KOKKOS_PKG_SOURCES" "${KOKKOS_PKG_SOURCES}")
 
 # detects styles which have KOKKOS version

cmake/Modules/Packages/ML-HDNNP.cmake

@@ -46,12 +46,10 @@ if(DOWNLOAD_N2P2)
     if((CMAKE_SYSTEM_NAME STREQUAL Windows) AND CMAKE_CROSSCOMPILING)
       get_target_property(N2P2_MPI_INCLUDE MPI::MPI_CXX INTERFACE_INCLUDE_DIRECTORIES)
       set(N2P2_PROJECT_OPTIONS "-I${N2P2_MPI_INCLUDE}")
-      set(MPI_CXX_COMPILER ${CMAKE_CXX_COMPILER})
     endif()
     if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
       get_target_property(N2P2_MPI_INCLUDE MPI::MPI_CXX INTERFACE_INCLUDE_DIRECTORIES)
       set(N2P2_PROJECT_OPTIONS "-I${N2P2_MPI_INCLUDE}")
-      set(MPI_CXX_COMPILER ${CMAKE_CXX_COMPILER})
     endif()
   endif()
 
@@ -64,8 +62,8 @@ if(DOWNLOAD_N2P2)
   string(TOUPPER "${CMAKE_BUILD_TYPE}" BTYPE)
   set(N2P2_BUILD_FLAGS "${CMAKE_SHARED_LIBRARY_CXX_FLAGS} ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_${BTYPE}} ${N2P2_CXX_STD}")
   set(N2P2_BUILD_OPTIONS INTERFACES=LAMMPS COMP=${N2P2_COMP} "PROJECT_OPTIONS=${N2P2_PROJECT_OPTIONS}" "PROJECT_DEBUG="
-    "PROJECT_CC=${CMAKE_CXX_COMPILER}" "PROJECT_MPICC=${MPI_CXX_COMPILER}" "PROJECT_CFLAGS=${N2P2_BUILD_FLAGS}"
-    "PROJECT_AR=${N2P2_AR}")
+    "PROJECT_CC=${CMAKE_CXX_COMPILER}" "PROJECT_MPICC=${CMAKE_CXX_COMPILER}" "PROJECT_CFLAGS=${N2P2_BUILD_FLAGS}"
+    "PROJECT_AR=${N2P2_AR}" "APP_CORE=nnp-convert" "APP_TRAIN=nnp-train" "APP=nnp-convert")
   # echo final flag for debugging
   message(STATUS "N2P2 BUILD OPTIONS: ${N2P2_BUILD_OPTIONS}")
 

cmake/Modules/Packages/ML-QUIP.cmake

@@ -32,7 +32,8 @@ if(DOWNLOAD_QUIP)
   foreach(flag ${LAPACK_LIBRARIES})
     set(temp "${temp} ${flag}")
   endforeach()
-  set(temp "${temp}\n")
+  # Fix cmake crashing when MATH_LINKOPTS not set, required for e.g. recent Cray Programming Environment
+  set(temp "${temp} -L/_DUMMY_PATH_\n")
   set(temp "${temp}PYTHON=python\nPIP=pip\nEXTRA_LINKOPTS=\n")
   set(temp "${temp}HAVE_CP2K=0\nHAVE_VASP=0\nHAVE_TB=0\nHAVE_PRECON=1\nHAVE_LOTF=0\nHAVE_ONIOM=0\n")
   set(temp "${temp}HAVE_LOCAL_E_MIX=0\nHAVE_QC=0\nHAVE_GAP=1\nHAVE_DESCRIPTORS_NONCOMMERCIAL=1\n")
@@ -50,6 +51,7 @@ if(DOWNLOAD_QUIP)
     GIT_TAG origin/public
     GIT_SHALLOW YES
     GIT_PROGRESS YES
+    GIT_SUBMODULES "src/fox;src/GAP"
     PATCH_COMMAND ${CMAKE_COMMAND} -E copy_if_different ${CMAKE_BINARY_DIR}/quip.config <SOURCE_DIR>/arch/Makefile.lammps
     CONFIGURE_COMMAND env QUIP_ARCH=lammps make config
     BUILD_COMMAND env QUIP_ARCH=lammps make libquip

cmake/Modules/Packages/MSCG.cmake

@@ -12,41 +12,12 @@ if(DOWNLOAD_MSCG)
   mark_as_advanced(MSCG_URL)
   mark_as_advanced(MSCG_MD5)
 
-  # 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 MSCG library due to a technical limitation")
-  endif()
+  include(ExternalCMakeProject)
+  ExternalCMakeProject(mscg ${MSCG_URL} ${MSCG_MD5} MSCG-release src/CMake "")
 
-  include(ExternalProject)
-  ExternalProject_Add(mscg_build
-    URL     ${MSCG_URL}
-    URL_MD5 ${MSCG_MD5}
-    SOURCE_SUBDIR src/CMake
-    CMAKE_ARGS ${CMAKE_REQUEST_PIC} ${EXTRA_MSCG_OPTS}
-               -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
-               -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
-               -DCMAKE_Fortran_COMPILER=${CMAKE_Fortran_COMPILER}
-               -DBLAS_LIBRARIES=${BLAS_LIBRARIES} -DLAPACK_LIBRARIES=${LAPACK_LIBRARIES}
-               -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
-               -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-               -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
-               -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
-    BUILD_COMMAND ${CMAKE_COMMAND} --build . --target mscg
-    INSTALL_COMMAND ""
-    BUILD_BYPRODUCTS <BINARY_DIR>/libmscg.a
-    )
-  ExternalProject_get_property(mscg_build BINARY_DIR)
-  ExternalProject_get_property(mscg_build SOURCE_DIR)
-  file(MAKE_DIRECTORY ${SOURCE_DIR}/src)
-  add_library(LAMMPS::MSCG UNKNOWN IMPORTED)
-  set_target_properties(LAMMPS::MSCG PROPERTIES
-    IMPORTED_LOCATION "${BINARY_DIR}/libmscg.a"
-    INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/src"
-    INTERFACE_LINK_LIBRARIES "${LAPACK_LIBRARIES}")
-  target_link_libraries(lammps PRIVATE LAMMPS::MSCG)
-  add_dependencies(LAMMPS::MSCG mscg_build)
+  # set include and link library
+  target_include_directories(lammps PRIVATE "${CMAKE_BINARY_DIR}/_deps/mscg-src/src")
+  target_link_libraries(lammps PRIVATE mscg)
 else()
   find_package(MSCG)
   if(NOT MSCG_FOUND)

cmake/Modules/Packages/PHONON.cmake

@@ -0,0 +1,9 @@
+# fix phonon may only be installed if also the FFT wrappers from KSPACE are installed
+if(NOT PKG_KSPACE)
+  get_property(LAMMPS_FIX_HEADERS GLOBAL PROPERTY FIX)
+  list(REMOVE_ITEM LAMMPS_FIX_HEADERS ${LAMMPS_SOURCE_DIR}/PHONON/fix_phonon.h)
+  set_property(GLOBAL PROPERTY FIX "${LAMMPS_FIX_HEADERS}")
+  get_target_property(LAMMPS_SOURCES lammps SOURCES)
+  list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/PHONON/fix_phonon.cpp)
+  set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
+endif()

cmake/Modules/Packages/PLUMED.cmake

@@ -54,8 +54,8 @@ if(DOWNLOAD_PLUMED)
     set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumedWrapper.a")
   endif()
 
-  set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.7.2/plumed-src-2.7.2.tgz" CACHE STRING "URL for PLUMED tarball")
-  set(PLUMED_MD5 "cfa0b4dd90a81c25d3302e8d97bfeaea" CACHE STRING "MD5 checksum of PLUMED tarball")
+  set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.7.4/plumed-src-2.7.4.tgz" CACHE STRING "URL for PLUMED tarball")
+  set(PLUMED_MD5 "858e0b6aed173748fc85b6bc8a9dcb3e" CACHE STRING "MD5 checksum of PLUMED tarball")
 
   mark_as_advanced(PLUMED_URL)
   mark_as_advanced(PLUMED_MD5)

cmake/Modules/Packages/PYTHON.cmake

@@ -3,7 +3,7 @@ if(CMAKE_VERSION VERSION_LESS 3.12)
   target_include_directories(lammps PRIVATE ${PYTHON_INCLUDE_DIRS})
   target_link_libraries(lammps PRIVATE ${PYTHON_LIBRARIES})
 else()
-  find_package(Python REQUIRED COMPONENTS Development)
+  find_package(Python REQUIRED COMPONENTS Interpreter Development)
   target_link_libraries(lammps PRIVATE Python::Python)
 endif()
 target_compile_definitions(lammps PRIVATE -DLMP_PYTHON)

cmake/Modules/YAML.cmake

@@ -1,47 +0,0 @@
-message(STATUS "Downloading and building YAML library")
-
-include(ExternalProject)
-set(YAML_URL "https://pyyaml.org/download/libyaml/yaml-0.2.5.tar.gz" CACHE STRING "URL for libyaml tarball")
-set(YAML_MD5 "bb15429d8fb787e7d3f1c83ae129a999" CACHE STRING "MD5 checksum of libyaml tarball")
-mark_as_advanced(YAML_URL)
-mark_as_advanced(YAML_MD5)
-
-# support cross-compilation to windows
-if(CMAKE_CROSSCOMPILING AND (CMAKE_SYSTEM_NAME STREQUAL "Windows"))
-  if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86")
-    set(YAML_CROSS_HOST --host=i686-mingw64)
-  elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
-    set(YAML_CROSS_HOST --host=x86_64-mingw64)
-  else()
-    message(FATAL_ERROR "Unsupported cross-compilation "
-      " for ${CMAKE_SYSTEM_NAME}/${CMAKE_SYSTEM_PROCESSOR}"
-      " on ${CMAKE_HOST_SYSTEM}/${CMAKE_HOST_SYSTEM_PROCESSOR}")
-  endif()
-endif()
-
-ExternalProject_Add(libyaml
-                    URL               ${YAML_URL}
-                    URL_MD5           ${YAML_MD5}
-                    SOURCE_DIR        "${CMAKE_BINARY_DIR}/yaml-src"
-                    BINARY_DIR        "${CMAKE_BINARY_DIR}/yaml-build"
-                    CONFIGURE_COMMAND <SOURCE_DIR>/configure ${CONFIGURE_REQUEST_PIC}
-                                      CXX=${CMAKE_CXX_COMPILER} CC=${CMAKE_C_COMPILER}
-                                      --prefix=<INSTALL_DIR> --disable-shared ${YAML_CROSS_HOST}
-                    BUILD_BYPRODUCTS  <INSTALL_DIR>/lib/libyaml${CMAKE_STATIC_LIBRARY_SUFFIX}
-                    TEST_COMMAND      "")
-
-ExternalProject_Get_Property(libyaml INSTALL_DIR)
-set(YAML_INCLUDE_DIR ${INSTALL_DIR}/include)
-set(YAML_LIBRARY_DIR ${INSTALL_DIR}/lib)
-
-# workaround for CMake 3.10 on ubuntu 18.04
-file(MAKE_DIRECTORY ${YAML_INCLUDE_DIR})
-file(MAKE_DIRECTORY ${YAML_LIBRARY_DIR})
-
-set(YAML_LIBRARY_PATH ${INSTALL_DIR}/lib/libyaml${CMAKE_STATIC_LIBRARY_SUFFIX})
-
-add_library(Yaml::Yaml UNKNOWN IMPORTED)
-set_target_properties(Yaml::Yaml PROPERTIES
-        IMPORTED_LOCATION ${YAML_LIBRARY_PATH}
-        INTERFACE_INCLUDE_DIRECTORIES ${YAML_INCLUDE_DIR})
-add_dependencies(Yaml::Yaml libyaml)

cmake/Modules/generate_lmpgitversion.cmake

@@ -24,10 +24,10 @@ if(GIT_FOUND AND EXISTS ${LAMMPS_DIR}/.git)
     OUTPUT_STRIP_TRAILING_WHITESPACE)
 endif()
 
-set(temp "${temp}const bool LAMMPS_NS::LAMMPS::has_git_info = ${temp_git_info};\n")
-set(temp "${temp}const char LAMMPS_NS::LAMMPS::git_commit[] = \"${temp_git_commit}\";\n")
-set(temp "${temp}const char LAMMPS_NS::LAMMPS::git_branch[] = \"${temp_git_branch}\";\n")
-set(temp "${temp}const char LAMMPS_NS::LAMMPS::git_descriptor[] = \"${temp_git_describe}\";\n")
+set(temp "${temp}bool LAMMPS_NS::LAMMPS::has_git_info() { return ${temp_git_info}; }\n")
+set(temp "${temp}const char *LAMMPS_NS::LAMMPS::git_commit() { return \"${temp_git_commit}\"; }\n")
+set(temp "${temp}const char *LAMMPS_NS::LAMMPS::git_branch() { return \"${temp_git_branch}\"; }\n")
+set(temp "${temp}const char *LAMMPS_NS::LAMMPS::git_descriptor() { return \"${temp_git_describe}\"; }\n")
 set(temp "${temp}#endif\n\n")
 
 message(STATUS "Generating lmpgitversion.h...")

cmake/iwyu/iwyu-extra-map.imp

@@ -20,9 +20,14 @@
   { include: [ "@\"kspace_.*.h\"", public, "\"style_kspace.h\"", public ] },
   { include: [ "@\"nbin_.*.h\"", public, "\"style_nbin.h\"", public ] },
   { include: [ "@\"npair_.*.h\"", public, "\"style_npair.h\"", public ] },
-  { include: [ "@\"nstenci_.*.h\"", public, "\"style_nstencil.h\"", public ] },
+  { include: [ "@\"nstencil_.*.h\"", public, "\"style_nstencil.h\"", public ] },
   { include: [ "@\"ntopo_.*.h\"", public, "\"style_ntopo.h\"", public ] },
+  { include: [ "\"fmt/core.h\"", private, "\"fmt/format.h\"", public ] },
   { include: [ "<float.h>",   public, "<cfloat>", public ] },
+  { include: [ "\"float.h\"",   public, "<cfloat>", public ] },
   { include: [ "<limits.h>",  public, "<climits>", public ] },
+  { include: [ "\"limits.h\"",  public, "<climits>", public ] },
+  { include: [ "<stdio.h>",  public, "<cstdio>", public ] },
+  { include: [ "<bits/types/struct_rusage.h>", private, "<sys/types.h>", public ] },
   { include: [ "<bits/types/struct_tm.h>", private, "<ctime>", public ] },
 ]

cmake/presets/gcc.cmake

@@ -3,19 +3,19 @@
 set(CMAKE_CXX_COMPILER "g++" CACHE STRING "" FORCE)
 set(CMAKE_C_COMPILER "gcc" CACHE STRING "" FORCE)
 set(CMAKE_Fortran_COMPILER "gfortran" CACHE STRING "" FORCE)
-set(CMAKE_CXX_FLAGS_DEBUG "-Wall -g" CACHE STRING "" FORCE)
+set(CMAKE_CXX_FLAGS_DEBUG "-Wall -Og -g" CACHE STRING "" FORCE)
 set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-g -O2 -DNDEBUG" CACHE STRING "" FORCE)
 set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
 set(MPI_CXX "g++" CACHE STRING "" FORCE)
 set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
 set(MPI_C "gcc" CACHE STRING "" FORCE)
 set(MPI_C_COMPILER "mpicc" CACHE STRING "" FORCE)
-set(CMAKE_C_FLAGS_DEBUG "-Wall -g" CACHE STRING "" FORCE)
+set(CMAKE_C_FLAGS_DEBUG "-Wall -Og -g" CACHE STRING "" FORCE)
 set(CMAKE_C_FLAGS_RELWITHDEBINFO "-g -O2 -DNDEBUG" CACHE STRING "" FORCE)
 set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
 set(MPI_Fortran "gfortran" CACHE STRING "" FORCE)
 set(MPI_Fortran_COMPILER "mpifort" CACHE STRING "" FORCE)
-set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -g -std=f2003" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -Og -g -std=f2003" CACHE STRING "" FORCE)
 set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-g -O2 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
 set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
 unset(HAVE_OMP_H_INCLUDE CACHE)

cmake/presets/most.cmake

@@ -48,7 +48,6 @@ set(ALL_PACKAGES
   PHONON
   PLUGIN
   POEMS
-  PYTHON
   QEQ
   REACTION
   REAXFF

doc/Makefile

@@ -230,7 +230,7 @@ $(VENV):
 	)
 
 $(MATHJAX):
-	@git clone -b 3.2.0 -c advice.detachedHead=0 --depth 1 git://github.com/mathjax/MathJax.git $@
+	@git clone -b 3.2.0 -c advice.detachedHead=0 --depth 1 https://github.com/mathjax/MathJax.git $@
 
 $(ANCHORCHECK): $(VENV)
 	@( \

doc/lammps.1

@@ -1,7 +1,7 @@
-.TH LAMMPS "1" "27 October 2021" "2021-10-27"
+.TH LAMMPS "1" "24 March 2022" "2022-3-24"
 .SH NAME
 .B LAMMPS
-\- Molecular Dynamics Simulator.
+\- Molecular Dynamics Simulator.  Version 24 March 2022
 
 .SH SYNOPSIS
 .B lmp
@@ -297,7 +297,7 @@ the chapter on errors in the
 manual gives some additional information about error messages, if possible.
 
 .SH COPYRIGHT
-© 2003--2021 Sandia Corporation
+© 2003--2022 Sandia Corporation
 
 This package is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License version 2 as

doc/src/Bibliography.rst

@@ -1123,9 +1123,12 @@ Bibliography
 **(Sun)**
    Sun, J. Phys. Chem. B, 102, 7338-7364 (1998).
 
-**(Surblys)**
+**(Surblys2019)**
    Surblys, Matsubara, Kikugawa, Ohara, Phys Rev E, 99, 051301(R) (2019).
 
+**(Surblys2021)**
+   Surblys, Matsubara, Kikugawa, Ohara, J Appl Phys 130, 215104 (2021).
+
 **(Sutmann)**
    Sutmann, Arnold, Fahrenberger, et. al., Physical review / E 88(6), 063308 (2013)
 

doc/src/Build_cmake.rst

@@ -150,6 +150,42 @@ for IDEs like Eclipse, CodeBlocks, or Kate can be selected using the *-G*
 command line flag.  A list of available generator settings for your
 specific CMake version is given when running ``cmake --help``.
 
+.. _cmake_multiconfig:
+
+Multi-configuration build systems
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Throughout this manual it is mostly assumed that LAMMPS is being built
+on a Unix-like operating system with "make" as the underlying "builder",
+since this is the most common case.  In this case the build "configuration"
+is chose using ``-D CMAKE_BUILD_TYPE=<configuration>`` with ``<configuration>``
+being one of "Release", "Debug", "RelWithDebInfo", or "MinSizeRel".
+Some build tools, however, can also use or even require to have a so-called
+multi-configuration build system setup.  For those the built type (or
+configuration) is chosen at compile time using the same build files. E.g.
+with:
+
+.. code-block:: bash
+
+   cmake --build build-multi --config Release
+
+In that case the resulting binaries are not in the build folder directly
+but in sub-directories corresponding to the build type (i.e. Release in
+the example from above).  Similarly, for running unit tests the
+configuration is selected with the *-C* flag:
+
+.. code-block:: bash
+
+   ctest -C Debug
+
+The CMake scripts in LAMMPS have basic support for being compiled using a
+multi-config build system, but not all of it has been ported.  This is in
+particular applicable to compiling packages that require additional libraries
+that would be downloaded and compiled by CMake.  The "windows" preset file
+tries to keep track of which packages can be compiled natively with the
+MSVC compilers out-of-the box.  Not all of those external libraries are
+portable to Windows either.
+
 
 Installing CMake
 ^^^^^^^^^^^^^^^^

doc/src/Build_development.rst

@@ -185,6 +185,10 @@ The ``ctest`` command has many options, the most important ones are:
      - run subset of tests matching the regular expression <regex>
    * - -E <regex>
      - exclude subset of tests matching the regular expression <regex>
+   * - -L <regex>
+     - run subset of tests with a label matching the regular expression <regex>
+   * - -LE <regex>
+     - exclude subset of tests with a label matching the regular expression <regex>
    * - -N
      - dry-run: display list of tests without running them
    * - -T memcheck
@@ -299,6 +303,12 @@ will destroy the original file, if the generation run does not complete,
 so using *-g* is recommended unless the YAML file is fully tested
 and working.
 
+Some of the force style tests are rather slow to run and some are very
+sensitive to small differences like CPU architecture, compiler
+toolchain, compiler optimization. Those tests are flagged with a "slow"
+and/or "unstable" label, and thus those tests can be selectively
+excluded with the ``-LE`` flag or selected with the ``-L`` flag.
+
 .. admonition:: Recommendations and notes for YAML files
    :class: note
 

doc/src/Build_extras.rst

@@ -341,6 +341,18 @@ minutes to hours) to build.  Of course you only need to do that once.)
          $ make lib-kim args="-p /usr/local" # use an existing KIM API installation at the provided location
          $ make lib-kim args="-p /usr/local -a EAM_Dynamo_Ackland_W__MO_141627196590_002" # ditto but add one model or driver
 
+      When using the "-b " option, the KIM library is built using its native
+      cmake build system.  The ``lib/kim/Install.py`` script supports a
+      ``CMAKE`` environment variable if the cmake executable is named other
+      than ``cmake`` on your system.  Additional environment variables may be
+      provided on the command line for use by cmake.  For example, to use the
+      ``cmake3`` executable and tell it to use the gnu version 11 compilers
+      to build KIM, one could use the following command line.
+
+      .. code-block:: bash
+
+         $ CMAKE=cmake3 CXX=g++-11 CC=gcc-11 FC=gfortran-11 make lib-kim args="-b "  # (re-)install KIM API lib using cmake3 and gnu v11 compilers with only example models
+
       Settings for debugging OpenKIM web queries discussed below need to
       be applied by adding them to the ``LMP_INC`` variable through
       editing the ``Makefile.machine`` you are using.  For example:
@@ -560,11 +572,26 @@ They must be specified in uppercase.
    *  - VEGA908
       - GPU
       - AMD GPU MI100 GFX908
-   *  - INTEL_GEN
+   *  - VEGA90A
       - GPU
-      - Intel GPUs Gen9+
+      - AMD GPU
+   *  - INTEL_DG1
+      - GPU
+      - Intel Iris XeMAX GPU
+   *  - INTEL_GEN9
+      - GPU
+      - Intel GPU Gen9
+   *  - INTEL_GEN11
+      - GPU
+      - Intel GPU Gen11
+   *  - INTEL_GEN12LP
+      - GPU
+      - Intel GPU Gen12LP
+   *  - INTEL_XEHP
+      - GPU
+      - Intel GPUs Xe-HP
 
-This list was last updated for version 3.4.1 of the Kokkos library.
+This list was last updated for version 3.5.0 of the Kokkos library.
 
 .. tabs::
 

doc/src/Build_settings.rst

@@ -4,15 +4,15 @@ Optional build settings
 LAMMPS can be built with several optional settings.  Each sub-section
 explain how to do this for building both with CMake and make.
 
-* :ref:`C++11 standard compliance <cxx11>` when building all of LAMMPS
-* :ref:`FFT library <fft>` for use with the :doc:`kspace_style pppm <kspace_style>` command
-* :ref:`Size of LAMMPS integer types <size>`
-* :ref:`Read or write compressed files <gzip>`
-* :ref:`Output of JPG and PNG files <graphics>` via the :doc:`dump image <dump_image>` command
-* :ref:`Output of movie files <graphics>` via the :doc:`dump_movie <dump_image>` command
-* :ref:`Memory allocation alignment <align>`
-* :ref:`Workaround for long long integers <longlong>`
-* :ref:`Error handling exceptions <exceptions>` when using LAMMPS as a library
+* `C++11 standard compliance`_ when building all of LAMMPS
+* `FFT library`_ for use with the :doc:`kspace_style pppm <kspace_style>` command
+* `Size of LAMMPS integer types and size limits`_
+* `Read or write compressed files`_
+* `Output of JPG, PNG, and move files` via the :doc:`dump image <dump_image>` or :doc:`dump movie <dump_image>` commands
+* `Memory allocation alignment`_
+* `Workaround for long long integers`_
+* `Exception handling when using LAMMPS as a library`_ to capture errors
+* `Trigger selected floating-point exceptions`_
 
 ----------
 

doc/src/Build_windows.rst

@@ -16,44 +16,52 @@ General remarks
 
 LAMMPS is developed and tested primarily on Linux machines.  The vast
 majority of HPC clusters and supercomputers today run on Linux as well.
-While portability to other platforms is desired, it is not always achieved.
-The LAMMPS developers are dependent on LAMMPS users giving feedback and
-providing assistance in resolving portability issues.  This is particularly
-true for compiling LAMMPS on Windows, since this platform has significant
-differences in some low-level functionality.
+While portability to other platforms is desired, it is not always
+achieved.  That is sometimes due to non-portable code in LAMMPS itself,
+but more often due to portability limitations of external libraries and
+tools required to build a specific feature or package.  The LAMMPS
+developers are dependent on LAMMPS users giving feedback and providing
+assistance in resolving portability issues.  This is particularly true
+for compiling LAMMPS on Windows, since this platform has significant
+differences in some low-level functionality.  As of LAMMPS version 14
+December 2021, large parts of LAMMPS can be compiled natively with the
+Microsoft Visual C++ Compilers.  This is largely facilitated by using
+the :doc:`Developer_platform` in the ``platform`` namespace.
+
+Before trying to build LAMMPS on Windows yourself, please consider the
+`pre-compiled Windows installer packages <https://packages.lammps.org/windows.html>`_
+and see if they are sufficient for your needs.
 
 .. _linux:
 
 Running Linux on Windows
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-Before trying to build LAMMPS on Windows, please consider if the
-pre-compiled Windows binary packages are sufficient for your needs.  If
-it is necessary for you to compile LAMMPS on a Windows machine
+If it is necessary for you to compile LAMMPS on a Windows machine
 (e.g. because it is your main desktop), please also consider using a
 virtual machine software and compile and run LAMMPS in a Linux virtual
 machine, or - if you have a sufficiently up-to-date Windows 10 or
 Windows 11 installation - consider using the Windows subsystem for
 Linux.  This optional Windows feature allows you to run the bash shell
-from Ubuntu from within Windows and from there on, you can pretty much
-use that shell like you are running on an Ubuntu Linux machine
-(e.g. installing software via apt-get and more).  For more details on
-that, please see :doc:`this tutorial <Howto_wsl>`.
+of a Linux system (Ubuntu by default) from within Windows and from there
+on, you can pretty much use that shell like you are running on a regular
+Ubuntu Linux machine (e.g. installing software via apt-get and more).
+For more details on that, please see :doc:`this tutorial <Howto_wsl>`.
 
 .. _gnu:
 
 Using a GNU GCC ported to Windows
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-One option for compiling LAMMPS on Windows natively that has been known
-to work in the past is to install a bash shell, unix shell utilities,
-perl, GNU make, and a GNU compiler ported to Windows.  The Cygwin
-package provides a unix/linux interface to low-level Windows functions,
-so LAMMPS can be compiled on Windows.  The necessary (minor)
-modifications to LAMMPS are included, but may not always up-to-date for
-recently added functionality and the corresponding new code.  A machine
-makefile for using cygwin for the old build system is provided. Using
-CMake for this mode of compilation is untested and not likely to work.
+One option for compiling LAMMPS on Windows natively is to install a Bash
+shell, Unix shell utilities, Perl, Python, GNU make, and a GNU compiler
+ported to Windows.  The Cygwin package provides a unix/linux interface
+to low-level Windows functions, so LAMMPS can be compiled on Windows.
+The necessary (minor) modifications to LAMMPS are included, but may not
+always up-to-date for recently added functionality and the corresponding
+new code.  A machine makefile for using cygwin for the old build system
+is provided.  Using CMake for this mode of compilation is untested and
+not likely to work.
 
 When compiling for Windows do **not** set the ``-DLAMMPS_MEMALIGN``
 define in the LMP_INC makefile variable and add ``-lwsock32 -lpsapi`` to
@@ -75,27 +83,42 @@ Using Microsoft Visual Studio
 
 Following the integration of the :doc:`platform namespace
 <Developer_platform>` into the LAMMPS code base, portability of LAMMPS
-to be compiled on Windows using Visual Studio has been significantly
-improved.  This has been tested with Visual Studio 2019 (aka version
-16).  Not all features and packages in LAMMPS are currently supported
-out of the box, but a preset ``cmake/presets/windows.cmake`` is provided
-that contains the packages that have been compiled successfully.  You
-must use the CMake based build procedure, and either use the integrated
-CMake support of Visual Studio or use an external CMake installation to
-create build files for the Visual Studio build system.  Please note that
-on launching Visual Studio it will scan the directory tree and likely
-miss the correct master ``CMakeLists.txt``.  Try to open the
-``cmake/CMakeSettings.json`` and use those CMake configurations as a
-starting point.  It is also possible to configure and compile LAMMPS
-from the command line with a CMake binary from `cmake.org <https://cmake.org>`_.
+for native compilation on Windows using Visual Studio has been
+significantly improved.  This has been tested with Visual Studio 2019
+(aka version 16) and Visual Studio 2022 (aka version 17).  We strongly
+recommend using Visual Studio 2022 version 17.1 or later.  Not all
+features and packages in LAMMPS are currently supported out of the box,
+but a preset ``cmake/presets/windows.cmake`` is provided that contains
+the packages that have been compiled successfully so far.  You **must**
+use the CMake based build procedure, since there is no support for GNU
+make or the Unix shell utilities required for the GNU make build
+procedure.
+
+It is possible to use both the integrated CMake support of the Visual
+Studio IDE or use an external CMake installation (e.g. downloaded from
+cmake.org) to create build files and compile LAMMPS from the command line.
+
+.. note::
+
+   Versions of Visual Studio before version 17.1 may scan the entire
+   LAMMPS source tree and likely miss the correct master
+   ``CMakeLists.txt`` and get confused since there are multiple files
+   of that name in different folders but none in top level folder.
+
+Please note, that for either approach CMake will create a so-called
+:ref:`"multi-configuration" build environment <cmake_multiconfig>`, and
+the command lines for building and testing LAMMPS must be adjusted
+accordingly.
 
 To support running in parallel you can compile with OpenMP enabled using
 the OPENMP package or install Microsoft MPI (including the SDK) and compile
 LAMMPS with MPI enabled.
 
-This is work in progress and you should contact the LAMMPS developers
-via GitHub, the forum, or the mailing list, if you have questions or
-LAMMPS specific problems.
+.. note::
+
+   This is work in progress and you should contact the LAMMPS developers
+   via GitHub, the forum, or the mailing list, if you have questions or
+   LAMMPS specific problems.
 
 .. _cross:
 

doc/src/Commands_all.rst

@@ -47,7 +47,7 @@ An alphabetic list of all general LAMMPS commands.
    * :doc:`displace_atoms <displace_atoms>`
    * :doc:`dump <dump>`
    * :doc:`dump_modify <dump_modify>`
-   * :doc:`dynamical_matrix <dynamical_matrix>`
+   * :doc:`dynamical_matrix (k) <dynamical_matrix>`
    * :doc:`echo <echo>`
    * :doc:`fix <fix>`
    * :doc:`fix_modify <fix_modify>`
@@ -117,7 +117,7 @@ An alphabetic list of all general LAMMPS commands.
    * :doc:`thermo <thermo>`
    * :doc:`thermo_modify <thermo_modify>`
    * :doc:`thermo_style <thermo_style>`
-   * :doc:`third_order <third_order>`
+   * :doc:`third_order (k) <third_order>`
    * :doc:`timer <timer>`
    * :doc:`timestep <timestep>`
    * :doc:`uncompute <uncompute>`

doc/src/Commands_bond.rst

@@ -35,6 +35,7 @@ OPT.
    * :doc:`class2 (ko) <bond_class2>`
    * :doc:`fene (iko) <bond_fene>`
    * :doc:`fene/expand (o) <bond_fene_expand>`
+   * :doc:`fene/nm <bond_fene>`
    * :doc:`gaussian <bond_gaussian>`
    * :doc:`gromos (o) <bond_gromos>`
    * :doc:`harmonic (iko) <bond_harmonic>`

doc/src/Commands_compute.rst

@@ -28,6 +28,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`angle <compute_angle>`
    * :doc:`angle/local <compute_angle_local>`
    * :doc:`angmom/chunk <compute_angmom_chunk>`
+   * :doc:`ave/sphere/atom (k) <compute_ave_sphere_atom>`
    * :doc:`basal/atom <compute_basal_atom>`
    * :doc:`body/local <compute_body_local>`
    * :doc:`bond <compute_bond>`
@@ -99,7 +100,6 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`pe/tally <compute_tally>`
    * :doc:`plasticity/atom <compute_plasticity_atom>`
    * :doc:`pressure <compute_pressure>`
-   * :doc:`pressure/cylinder <compute_pressure_cylinder>`
    * :doc:`pressure/uef <compute_pressure_uef>`
    * :doc:`property/atom <compute_property_atom>`
    * :doc:`property/chunk <compute_property_chunk>`
@@ -142,8 +142,11 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`sph/t/atom <compute_sph_t_atom>`
    * :doc:`spin <compute_spin>`
    * :doc:`stress/atom <compute_stress_atom>`
+   * :doc:`stress/cartesian <compute_stress_profile>`
+   * :doc:`stress/cylinder <compute_stress_profile>`
    * :doc:`stress/mop <compute_stress_mop>`
    * :doc:`stress/mop/profile <compute_stress_mop>`
+   * :doc:`stress/spherical <compute_stress_profile>`
    * :doc:`stress/tally <compute_tally>`
    * :doc:`tdpd/cc/atom <compute_tdpd_cc_atom>`
    * :doc:`temp (k) <compute_temp>`

doc/src/Commands_fix.rst

@@ -55,6 +55,7 @@ OPT.
    * :doc:`cmap <fix_cmap>`
    * :doc:`colvars <fix_colvars>`
    * :doc:`controller <fix_controller>`
+   * :doc:`damping/cundall <fix_damping_cundall>`
    * :doc:`deform (k) <fix_deform>`
    * :doc:`deposit <fix_deposit>`
    * :doc:`dpd/energy (k) <fix_dpd_energy>`
@@ -97,8 +98,6 @@ OPT.
    * :doc:`latte <fix_latte>`
    * :doc:`lb/fluid <fix_lb_fluid>`
    * :doc:`lb/momentum <fix_lb_momentum>`
-   * :doc:`lb/pc <fix_lb_pc>`
-   * :doc:`lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>`
    * :doc:`lb/viscous <fix_lb_viscous>`
    * :doc:`lineforce <fix_lineforce>`
    * :doc:`manifoldforce <fix_manifoldforce>`
@@ -129,6 +128,7 @@ OPT.
    * :doc:`npt/sphere (o) <fix_npt_sphere>`
    * :doc:`npt/uef <fix_nh_uef>`
    * :doc:`numdiff <fix_numdiff>`
+   * :doc:`numdiff/virial <fix_numdiff_virial>`
    * :doc:`nve (giko) <fix_nve>`
    * :doc:`nve/asphere (gi) <fix_nve_asphere>`
    * :doc:`nve/asphere/noforce <fix_nve_asphere_noforce>`
@@ -244,6 +244,7 @@ OPT.
    * :doc:`vector <fix_vector>`
    * :doc:`viscosity <fix_viscosity>`
    * :doc:`viscous <fix_viscous>`
+   * :doc:`viscous/sphere <fix_viscous_sphere>`
    * :doc:`wall/body/polygon <fix_wall_body_polygon>`
    * :doc:`wall/body/polyhedron <fix_wall_body_polyhedron>`
    * :doc:`wall/colloid <fix_wall>`

doc/src/Commands_pair.rst

@@ -119,10 +119,12 @@ OPT.
    * :doc:`granular <pair_granular>`
    * :doc:`gw <pair_gw>`
    * :doc:`gw/zbl <pair_gw>`
+   * :doc:`harmonic/cut (o) <pair_harmonic_cut>`
    * :doc:`hbond/dreiding/lj (o) <pair_hbond_dreiding>`
    * :doc:`hbond/dreiding/morse (o) <pair_hbond_dreiding>`
    * :doc:`hdnnp <pair_hdnnp>`
    * :doc:`ilp/graphene/hbn <pair_ilp_graphene_hbn>`
+   * :doc:`ilp/tmd <pair_ilp_tmd>`
    * :doc:`kolmogorov/crespi/full <pair_kolmogorov_crespi_full>`
    * :doc:`kolmogorov/crespi/z <pair_kolmogorov_crespi_z>`
    * :doc:`lcbop <pair_lcbop>`
@@ -210,6 +212,7 @@ OPT.
    * :doc:`nm/cut (o) <pair_nm>`
    * :doc:`nm/cut/coul/cut (o) <pair_nm>`
    * :doc:`nm/cut/coul/long (o) <pair_nm>`
+   * :doc:`nm/cut/split <pair_nm>`
    * :doc:`oxdna/coaxstk <pair_oxdna>`
    * :doc:`oxdna/excv <pair_oxdna>`
    * :doc:`oxdna/hbond <pair_oxdna>`
@@ -239,6 +242,7 @@ OPT.
    * :doc:`reaxff (ko) <pair_reaxff>`
    * :doc:`rebo (io) <pair_airebo>`
    * :doc:`resquared (go) <pair_resquared>`
+   * :doc:`saip/metal <pair_saip_metal>`
    * :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>`
    * :doc:`smd/hertz <pair_smd_hertz>`
    * :doc:`smd/tlsph <pair_smd_tlsph>`
@@ -262,6 +266,7 @@ OPT.
    * :doc:`spin/neel <pair_spin_neel>`
    * :doc:`srp <pair_srp>`
    * :doc:`sw (giko) <pair_sw>`
+   * :doc:`sw/mod (o) <pair_sw>`
    * :doc:`table (gko) <pair_table>`
    * :doc:`table/rx (k) <pair_table_rx>`
    * :doc:`tdpd <pair_mesodpd>`

doc/src/Developer.rst

@@ -11,7 +11,9 @@ of time and requests from the LAMMPS user community.
    :maxdepth: 1
 
    Developer_org
+   Developer_code_design
    Developer_parallel
+   Developer_comm_ops
    Developer_flow
    Developer_write
    Developer_notes

doc/src/Developer_code_design.rst

@@ -0,0 +1,433 @@
+Code design
+-----------
+
+This section explains some of the code design choices in LAMMPS with
+the goal of helping developers write new code similar to the existing
+code.  Please see the section on :doc:`Requirements for contributed
+code <Modify_style>` for more specific recommendations and guidelines.
+While that section is organized more in the form of a checklist for
+code contributors, the focus here is on overall code design strategy,
+choices made between possible alternatives, and discussing some
+relevant C++ programming language constructs.
+
+Historically, the basic design philosophy of the LAMMPS C++ code was a
+"C with classes" style.  The motivation was to make it easy to modify
+LAMMPS for people without significant training in C++ programming.
+Data structures and code constructs were used that resemble the
+previous implementation(s) in Fortran.  A contributing factor to this
+choice also was that at the time, C++ compilers were often not mature
+and some of the advanced features contained bugs or did not function
+as the standard required.  There were also disagreements between
+compiler vendors as to how to interpret the C++ standard documents.
+
+However, C++ compilers have now advanced significantly.  In 2020 we
+decided to to require the C++11 standard as the minimum C++ language
+standard for LAMMPS.  Since then we have begun to also replace some of
+the C-style constructs with equivalent C++ functionality, either from
+the C++ standard library or as custom classes or functions, in order
+to improve readability of the code and to increase code reuse through
+abstraction of commonly used functionality.
+
+.. note::
+
+   Please note that as of spring 2022 there is still a sizable chunk
+   of legacy code in LAMMPS that has not yet been refactored to
+   reflect these style conventions in full.  LAMMPS has a large code
+   base and many different contributors and there also is a hierarchy
+   of precedence in which the code is adapted.  Highest priority has
+   been the code in the ``src`` folder, followed by code in packages
+   in order of their popularity and complexity (simpler code is
+   adapted sooner), followed by code in the ``lib`` folder.  Source
+   code that is downloaded from external packages or libraries during
+   compilation is not subject to the conventions discussed here.
+
+Object oriented code
+^^^^^^^^^^^^^^^^^^^^
+
+LAMMPS is designed to be an object oriented code.  Each simulation is
+represented by an instance of the LAMMPS class.  When running in
+parallel each MPI process creates such an instance.  This can be seen
+in the ``main.cpp`` file where the core steps of running a LAMMPS
+simulation are the following 3 lines of code:
+
+.. code-block:: C++
+
+    LAMMPS *lammps = new LAMMPS(argc, argv, lammps_comm);
+    lammps->input->file();
+    delete lammps;
+
+The first line creates a LAMMPS class instance and passes the command
+line arguments and the global communicator to its constructor.  The
+second line triggers the LAMMPS instance to process the input (either
+from standard input or a provided input file) until the simulation
+ends.  The third line deletes the LAMMPS instance.  The remainder of
+the main.cpp file has code for error handling, MPI configuration, and
+other special features.
+
+The basic LAMMPS class hierarchy which is created by the LAMMPS class
+constructor is shown in :ref:`class-topology`.  When input commands
+are processed, additional class instances are created, or deleted, or
+replaced.  Likewise specific member functions of specific classes are
+called to trigger actions such creating atoms, computing forces,
+computing properties, time-propagating the system, or writing output.
+
+Compositing and Inheritance
+===========================
+
+LAMMPS makes extensive use of the object oriented programming (OOP)
+principles of *compositing* and *inheritance*. Classes like the
+``LAMMPS`` class are a **composite** containing pointers to instances
+of other classes like ``Atom``, ``Comm``, ``Force``, ``Neighbor``,
+``Modify``, and so on.  Each of these classes implement certain
+functionality by storing and manipulating data related to the
+simulation and providing member functions that trigger certain
+actions.  Some of those classes like ``Force`` are themselves
+composites, containing instances of classes describing different force
+interactions.  Similarly the ``Modify`` class contains a list of
+``Fix`` and ``Compute`` classes.  If the input commands that
+correspond to these classes include the word *style*, then LAMMPS
+stores only a single instance of that class.  E.g. *atom_style*,
+*comm_style*, *pair_style*, *bond_style*.  It the input command does
+not include the word *style*, there can be many instances of that
+class defined.  E.g. *region*, *fix*, *compute*, *dump*.
+
+**Inheritance** enables creation of *derived* classes that can share
+common functionality in their base class while providing a consistent
+interface.  The derived classes replace (dummy or pure) functions in
+the base class.  The higher level classes can then call those methods
+of the instantiated classes without having to know which specific
+derived class variant was instantiated.  In LAMMPS these derived
+classes are often referred to as "styles", e.g.  pair styles, fix
+styles, atom styles and so on.
+
+This is the origin of the flexibility of LAMMPS.  For example pair
+styles implement a variety of different non-bonded interatomic
+potentials functions.  All details for the implementation of a
+potential are stored and executed in a single class.
+
+As mentioned above, there can be multiple instances of classes derived
+from the ``Fix`` or ``Compute`` base classes.  They represent a
+different facet of LAMMPS flexibility as they provide methods which
+can be called at different points in time within a timestep, as
+explained in `Developer_flow`.  This allows the input script to tailor
+how a specific simulation is run, what diagnostic computations are
+performed, and how the output of those computations is further
+processed or output.
+
+Additional code sharing is possible by creating derived classes from the
+derived classes (e.g., to implement an accelerated version of a pair
+style) where only a subset of the derived class methods are replaced
+with accelerated versions.
+
+Polymorphism
+============
+
+Polymorphism and dynamic dispatch are another OOP feature that play an
+important role in how LAMMPS selects what code to execute.  In a
+nutshell, this is a mechanism where the decision of which member
+function to call from a class is determined at runtime and not when
+the code is compiled.  To enable it, the function has to be declared
+as ``virtual`` and all corresponding functions in derived classes
+should use the ``override`` property. Below is a brief example.
+
+.. code-block:: c++
+
+   class Base {
+   public:
+    virtual ~Base() = default;
+    void call();
+    void normal();
+    virtual void poly();
+   };
+
+   void Base::call() {
+    normal();
+    poly();
+   }
+
+   class Derived : public Base {
+   public:
+    ~Derived() override = default;
+    void normal();
+    void poly() override;
+   };
+
+   // [....]
+
+   Base *base1 = new Base();
+   Base *base2 = new Derived();
+
+   base1->call();
+   base2->call();
+
+The difference in behavior of the ``normal()`` and the ``poly()`` member
+functions is which of the two member functions is called when executing
+`base1->call()` versus `base2->call()`.  Without polymorphism, a
+function within the base class can only call member functions within the
+same scope, that is ``Base::call()`` will always call
+``Base::normal()``.  But for the `base2->call()` case the call of the
+virtual member function will be dispatched to ``Derived::poly()``
+instead.  This mechanism means that functions are called within the
+scope of the class type that was used to *create* the class instance are
+invoked; even if they are assigned to a pointer using the type of a base
+class.  This is the desired behavior and this way LAMMPS can even use
+styles that are loaded at runtime from a shared object file with the
+:doc:`plugin command <plugin>`.
+
+A special case of virtual functions are so-called pure functions.  These
+are virtual functions that are initialized to 0 in the class declaration
+(see example below).
+
+.. code-block:: c++
+
+   class Base {
+   public:
+    virtual void pure() = 0;
+   };
+
+This has the effect that an instance of the base class cannot be
+created and that derived classes **must** implement these functions.
+Many of the functions listed with the various class styles in the
+section :doc:`Modify` are pure functions.  The motivation for this is
+to define the interface or API of the functions but defer their
+implementation to the derived classes.
+
+However, there are downsides to this. For example, calls to virtual
+functions from within a constructor, will not be in the scope of the
+derived class and thus it is good practice to either avoid calling them
+or to provide an explicit scope such as ``Base::poly()`` or
+``Derived::poly()``.  Furthermore, any destructors in classes containing
+virtual functions should be declared virtual too, so they will be
+processed in the expected order before types are removed from dynamic
+dispatch.
+
+.. admonition:: Important Notes
+
+   In order to be able to detect incompatibilities at compile time and
+   to avoid unexpected behavior, it is crucial that all member functions
+   that are intended to replace a virtual or pure function use the
+   ``override`` property keyword.  For the same reason, the use of
+   overloads or default arguments for virtual functions should be
+   avoided as they lead to confusion over which function is supposed to
+   override which and which arguments need to be declared.
+
+Style Factories
+===============
+
+In order to create class instances for different styles, LAMMPS often
+uses a programming pattern called `Factory`.  Those are functions that
+create an instance of a specific derived class, say ``PairLJCut`` and
+return a pointer to the type of the common base class of that style,
+``Pair`` in this case.  To associate the factory function with the
+style keyword, an ``std::map`` class is used with function pointers
+indexed by their keyword (for example "lj/cut" for ``PairLJCut`` and
+"morse" for ``PairMorse``).  A couple of typedefs help keep the code
+readable and a template function is used to implement the actual
+factory functions for the individual classes.  Below is an example
+of such a factory function from the ``Force`` class as declared in
+``force.h`` and implemented in ``force.cpp``.  The file ``style_pair.h``
+is generated during compilation and includes all main header files
+(i.e. those starting with ``pair_``) of pair styles and then the
+macro ``PairStyle()`` will associate the style name "lj/cut"
+with a factory function creating an instance of the ``PairLJCut``
+class.
+
+.. code-block:: C++
+
+   // from force.h
+   typedef Pair *(*PairCreator)(LAMMPS *);
+   typedef std::map<std::string, PairCreator> PairCreatorMap;
+   PairCreatorMap *pair_map;
+
+   // from force.cpp
+   template <typename S, typename T> static S *style_creator(LAMMPS *lmp)
+   {
+     return new T(lmp);
+   }
+
+   // [...]
+
+   pair_map = new PairCreatorMap();
+
+   #define PAIR_CLASS
+   #define PairStyle(key, Class) (*pair_map)[#key] = &style_creator<Pair, Class>;
+   #include "style_pair.h"
+   #undef PairStyle
+   #undef PAIR_CLASS
+
+   // from pair_lj_cut.h
+
+   #ifdef PAIR_CLASS
+   PairStyle(lj/cut,PairLJCut);
+   #else
+   // [...]
+
+Similar code constructs are present in other files like ``modify.cpp`` and
+``modify.h`` or ``neighbor.cpp`` and ``neighbor.h``.  Those contain
+similar macros and include ``style_*.h`` files for creating class instances
+of styles they manage.
+
+
+I/O and output formatting
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+C-style stdio versus C++ style iostreams
+========================================
+
+LAMMPS uses the "stdio" library of the standard C library for reading
+from and writing to files and console instead of C++ "iostreams".
+This is mainly motivated by better performance, better control over
+formatting, and less effort to achieve specific formatting.
+
+Since mixing "stdio" and "iostreams" can lead to unexpected
+behavior. use of the latter is strongly discouraged.  Also output to
+the screen should not use the predefined ``stdout`` FILE pointer, but
+rather the ``screen`` and ``logfile`` FILE pointers managed by the
+LAMMPS class.  Furthermore, output should generally only be done by
+MPI rank 0 (``comm->me == 0``).  Output that is sent to both
+``screen`` and ``logfile`` should use the :cpp:func:`utils::logmesg()
+convenience function <LAMMPS_NS::utils::logmesg>`.
+
+We also discourage the use of stringstreams because the bundled {fmt}
+library and the customized tokenizer classes can provide the same
+functionality in a cleaner way with better performance.  This also
+helps maintain a consistent programming syntax with code from many
+different contributors.
+
+Formatting with the {fmt} library
+===================================
+
+The LAMMPS source code includes a copy of the `{fmt} library
+<https://fmt.dev>`_ which is preferred over formatting with the
+"printf()" family of functions.  The primary reason is that it allows
+a typesafe default format for any type of supported data.  This is
+particularly useful for formatting integers of a given size (32-bit or
+64-bit) which may require different format strings depending on
+compile time settings or compilers/operating systems.  Furthermore,
+{fmt} gives better performance, has more functionality, a familiar
+formatting syntax that has similarities to ``format()`` in Python, and
+provides a facility that can be used to integrate format strings and a
+variable number of arguments into custom functions in a much simpler
+way than the varargs mechanism of the C library.  Finally, {fmt} has
+been included into the C++20 language standard, so changes to adopt it
+are future-proof.
+
+Formatted strings are frequently created by calling the
+``fmt::format()`` function which will return a string as a
+``std::string`` class instance.  In contrast to the ``%`` placeholder
+in ``printf()``, the {fmt} library uses ``{}`` to embed format
+descriptors.  In the simplest case, no additional characters are
+needed as {fmt} will choose the default format based on the data type
+of the argument.  Otherwise the ``fmt::print()`` function may be
+used instead of ``printf()`` or ``fprintf()``.  In addition, several
+LAMMPS output functions, that originally accepted a single string as
+argument have been overloaded to accept a format string with optional
+arguments as well (e.g., ``Error::all()``, ``Error::one()``,
+``utils::logmesg()``).
+
+Summary of the {fmt} format syntax
+==================================
+
+The syntax of the format string is "{[<argument id>][:<format spec>]}",
+where either the argument id or the format spec (separated by a colon
+':') is optional.  The argument id is usually a number starting from 0
+that is the index to the arguments following the format string.  By
+default these are assigned in order (i.e. 0, 1, 2, 3, 4 etc.).  The most
+common case for using argument id would be to use the same argument in
+multiple places in the format string without having to provide it as an
+argument multiple times. In LAMMPS the argument id is rarely used.
+
+More common is the use of a format specifier, which starts with a colon.
+This may optionally be followed by a fill character (default is ' '). If
+provided, the fill character **must** be followed by an alignment
+character ('<', '^', '>' for left, centered, or right alignment
+(default)).  The alignment character may be used without a fill
+character.  The next important format parameter would be the minimum
+width, which may be followed by a dot '.' and a precision for floating
+point numbers.  The final character in the format string would be an
+indicator for the "presentation", i.e. 'd' for decimal presentation of
+integers, 'x' for hexadecimal, 'o' for octal, 'c' for character etc.
+This mostly follows the "printf()" scheme but without requiring an
+additional length parameter to distinguish between different integer
+widths.  The {fmt} library will detect those and adapt the formatting
+accordingly.  For floating point numbers there are correspondingly, 'g'
+for generic presentation, 'e' for exponential presentation, and 'f' for
+fixed point presentation.
+
+Thus "{:8}" would represent *any* type argument using at least 8
+characters; "{:<8}" would do this as left aligned, "{:^8}" as centered,
+"{:>8}" as right aligned.  If a specific presentation is selected, the
+argument type must be compatible or else the {fmt} formatting code will
+throw an exception. Some format string examples are given below:
+
+.. code-block:: C
+
+   auto mesg = fmt::format("  CPU time: {:4d}:{:02d}:{:02d}\n", cpuh, cpum, cpus);
+   mesg = fmt::format("{:<8s}| {:<10.5g} | {:<10.5g} | {:<10.5g} |{:6.1f} |{:6.2f}\n",
+                      label, time_min, time, time_max, time_sq, tmp);
+   utils::logmesg(lmp,"{:>6} = max # of 1-2 neighbors\n",maxall);
+   utils::logmesg(lmp,"Lattice spacing in x,y,z = {:.8} {:.8} {:.8}\n",
+                  xlattice,ylattice,zlattice);
+
+which will create the following output lines:
+
+.. parsed-literal::
+
+     CPU time:    0:02:16
+     Pair    | 2.0133     | 2.0133     | 2.0133     |   0.0 | 84.21
+          4 = max # of 1-2 neighbors
+     Lattice spacing in x,y,z = 1.6795962 1.6795962 1.6795962
+
+Finally, a special feature of the {fmt} library is that format
+parameters like the width or the precision may be also provided as
+arguments. In that case a nested format is used where a pair of curly
+braces (with an optional argument id) "{}" are used instead of the
+value, for example "{:{}d}" will consume two integer arguments, the
+first will be the value shown and the second the minimum width.
+
+For more details and examples, please consult the `{fmt} syntax
+documentation <https://fmt.dev/latest/syntax.html>`_ website.
+
+
+Memory management
+^^^^^^^^^^^^^^^^^
+
+Dynamical allocation of small data and objects can be done with the
+the C++ commands "new" and "delete/delete[].  Large data should use
+the member functions of the ``Memory`` class, most commonly,
+``Memory::create()``, ``Memory::grow()``, and ``Memory::destroy()``,
+which provide variants for vectors, 2d arrays, 3d arrays, etc.
+These can also be used for small data.
+
+The use of ``malloc()``, ``calloc()``, ``realloc()`` and ``free()``
+directly is strongly discouraged.  To simplify adapting legacy code
+into the LAMMPS code base the member functions ``Memory::smalloc()``,
+``Memory::srealloc()``, and ``Memory::sfree()`` are available, which
+perform additional error checks for safety.
+
+Use of these custom memory allocation functions is motivated by the
+following considerations:
+
+- memory allocation failures on *any* MPI rank during a parallel run
+  will trigger an immediate abort of the entire parallel calculation
+  instead of stalling it
+- a failing "new" will trigger an exception which is also captured by
+  LAMMPS and triggers a global abort
+- allocation of multi-dimensional arrays will be done in a C compatible
+  fashion but so that the storage of the actual data is stored in one
+  large contiguous block.  Thus when MPI communication is needed,
+  the data can be communicated directly (similar to Fortran arrays).
+- the "destroy()" and "sfree()" functions may safely be called on NULL
+  pointers
+- the "destroy()" functions will nullify the pointer variables making
+  "use after free" errors easy to detect
+- it is possible to use a larger than default memory alignment (not on
+  all operating systems, since the allocated storage pointers must be
+  compatible with ``free()`` for technical reasons)
+
+In the practical implementation of code this means that any pointer
+variables that are class members should be initialized to a
+``nullptr`` value in their respective constructors.  That way it is
+safe to call ``Memory::destroy()`` or ``delete[]`` on them before
+*any* allocation outside the constructor.  This helps prevent memory
+leaks.

doc/src/Developer_comm_ops.rst

@@ -0,0 +1,235 @@
+Communication patterns
+----------------------
+
+This page describes various inter-processor communication operations
+provided by LAMMPS, mostly in the core *Comm* class.  These are operations
+for common tasks implemented using MPI library calls.  They are used by
+other classes to perform communication of different kinds.  These
+operations are useful to know about when writing new code for LAMMPS
+that needs to communicate data between processors.
+
+Owned and ghost atoms
+^^^^^^^^^^^^^^^^^^^^^
+
+As described on the :doc:`parallel partitioning algorithms
+<Developer_par_part>` page, LAMMPS spatially decomposes the simulation
+domain, either in a *brick* or *tiled* manner.  Each processor (MPI
+task) owns atoms within its sub-domain and additionally stores ghost
+atoms within a cutoff distance of its sub-domain.
+
+Forward and reverse communication
+=================================
+
+As described on the :doc:`parallel communication algorithms
+<Developer_par_comm>` page, the most common communication operations are
+first, *forward communication* which sends owned atom information from
+each processor to nearby processors to store with their ghost atoms.
+The need to do this communication arises when data from the owned atoms
+is updated (e.g. their positions) and this updated information needs to
+be **copied** to the corresponding ghost atoms.
+
+And second, *reverse communication* which sends ghost atom information
+from each processor to the owning processor to **accumulate** (sum)
+the values with the corresponding owned atoms.  The need for this
+arises when data is computed and also stored with ghost atoms
+(e.g. forces when using a "half" neighbor list) and thus those terms
+need to be added to their corresponding atoms on the process where
+they are "owned" atoms.  Please note, that with the :doc:`newton off
+<newton>` setting this does not happen and the neighbor lists are
+constructed so that these interactions are computed on both MPI
+processes containing one of the atoms and only the data pertaining to
+the local atom is stored.
+
+The time-integration classes in LAMMPS invoke these operations each
+timestep via the *forward_comm()* and *reverse_comm()* methods in the
+*Comm* class.  Which per-atom data is communicated depends on the
+currently used :doc:`atom style <atom_style>` and whether
+:doc:`comm_modify vel <comm_modify>` setting is "no" (default) or
+"yes".
+
+Similarly, *Pair* style classes can invoke the *forward_comm(this)*
+and *reverse_comm(this)* methods in the *Comm* class to perform the
+same operations on per-atom data that is generated and stored within
+the pair style class. Note that this function requires passing the
+``this`` pointer as the first argument to enable the *Comm* class to
+call the "pack" and "unpack" functions discussed below.  An example of
+the use of these functions are many-body pair styles like the
+embedded-atom method (EAM) which compute intermediate values in the
+first part of the compute() function that need to be stored by both
+owned and ghost atoms for the second part of the force computation.
+The *Comm* class methods perform the MPI communication for buffers of
+per-atom data.  They "call back" to the *Pair* class so it can *pack*
+or *unpack* the buffer with data the *Pair* class owns.  There are 4
+such methods that the *Pair* class must define, assuming it uses both
+forward and reverse communication:
+
+* pack_forward_comm()
+* unpack_forward_comm()
+* pack_reverse_comm()
+* unpack_reverse_comm()
+
+The arguments to these methods include the buffer and a list of atoms
+to pack or unpack.  The *Pair* class also must set the *comm_forward*
+and *comm_reverse* variables which store the number of values stored
+in the communication buffers for each operation.  This means, if
+desired, it can choose to store multiple per-atom values in the
+buffer, and they will be communicated together to minimize
+communication overhead.  The communication buffers are defined vectors
+containing ``double`` values.  To correctly store integers that may be
+64-bit (bigint, tagint, imageint) in the buffer, you need to use the
+`ubuf union <Communication buffer coding with ubuf>`_ construct.
+
+The *Fix*, *Compute*, and *Dump* classes can also invoke the same kind
+of forward and reverse communication operations using the same *Comm*
+class methods.  Likewise the same pack/unpack methods and
+comm_forward/comm_reverse variables must be defined by the calling
+*Fix*, *Compute*, or *Dump* class.
+
+For *Fix* classes there is an optional second argument to the
+*forward_comm()* and *reverse_comm()* call which can be used when the
+fix performs multiple modes of communication, with different numbers
+of values per atom.  The fix should set the *comm_forward* and
+*comm_reverse* variables to the maximum value, but can invoke the
+communication for a particular mode with a smaller value.  For this
+to work, the *pack_forward_comm()*, etc methods typically use a class
+member variable to choose which values to pack/unpack into/from the
+buffer.
+
+Finally, for reverse communications in *Fix* classes there is also the
+*reverse_comm_variable()* method that allows the communication to have
+a different amount of data per-atom.  It invokes these corresponding
+callback methods:
+
+* pack_reverse_comm_size()
+* unpack_reverse_comm_size()
+
+which have extra arguments to specify the amount of data stored
+in the buffer for each atom.
+
+Higher level communication
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+There are also several higher-level communication operations provided
+in LAMMPS which work for either *brick* or *tiled* decompositions.
+They may be useful for a new class to invoke if it requires more
+sophisticated communication than the *forward* and *reverse* methods
+provide.  The 3 communication operations described here are
+
+* ring
+* irregular
+* rendezvous
+
+You can invoke these *grep* command in the LAMMPS src directory, to
+see a list of classes that invoke the 3 operations.
+
+* ``grep "\->ring" *.cpp */*.cpp``
+* ``grep "irregular\->" *.cpp``
+* ``grep "\->rendezvous" *.cpp */*.cpp``
+
+Ring operation
+==============
+
+The *ring* operation is invoked via the *ring()* method in the *Comm*
+class.
+
+Each processor first creates a buffer with a list of values, typically
+associated with a subset of the atoms it owns.  Now think of the *P*
+processors as connected to each other in a *ring*.  Each processor *M*
+sends data to the next *M+1* processor.  It receives data from the
+preceding *M-1* processor.  The ring is periodic so that the last
+processor sends to the first processor, and the first processor
+receives from the last processor.
+
+Invoking the *ring()* method passes each processor's buffer in *P*
+steps around the ring.  At each step a *callback* method, provided as
+an argument to ring(), in the caller is invoked.  This allows each
+processor to examine the data buffer provided by every other
+processor.  It may extract values needed by its atoms from the
+buffers, or it may alter placeholder values in the buffer.  In the
+latter case, when the *ring* operation is complete, each processor can
+examine its original buffer to extract modified values.
+
+Note that the *ring* operation is similar to an MPI_Alltoall()
+operation where every processor effectively sends and receives data to
+every other processor.  The difference is that the *ring* operation
+does it one step at a time, so the total volume of data does not need
+to be stored by every processor.  However, the *ring* operation is
+also less efficient than MPI_Alltoall() because of the *P* stages
+required.  So it is typically only suitable for small data buffers and
+occasional operations that are not time-critical.
+
+Irregular operation
+===================
+
+The *irregular* operation is provided by the *Irregular* class.  What
+LAMMPS terms irregular communication is when each processor knows what
+data it needs to send to what processor, but does not know what
+processors are sending it data.  An example is when load-balancing is
+performed and each processor needs to send some of its atoms to new
+processors.
+
+The *Irregular* class provides 5 high-level methods useful in this
+context:
+
+* create_data()
+* exchange_data()
+* create_atom()
+* exchange_atom()
+* migrate_atoms()
+
+For the *create_data()* method, each processor specifies a list of *N*
+datums to send, each to a specified processor.  Internally, the method
+creates efficient data structures for performing the communication.
+The *exchange_data()* method triggers the communication to be
+performed.  Each processor provides the vector of *N* datums to send,
+and the size of each datum.  All datums must be the same size.
+
+The *create_atom()* and *exchange_atom()* methods are similar except
+that the size of each datum can be different.  Typically this is used
+to communicate atoms, each with a variable amount of per-atom data, to
+other processors.
+
+The *migrate_atoms()* method is a convenience wrapper on the
+*create_atom()* and *exchange_atom()* methods to simplify
+communication of all the per-atom data associated with an atom so that
+the atom can effectively migrate to a new owning processor.  It is
+similar to the *exchange()* method in the *Comm* class invoked when
+atoms move to neighboring processors (in the regular or tiled
+decomposition) during timestepping, except that it allows atoms to
+have moved arbitrarily long distances and still be properly
+communicated to a new owning processor.
+
+Rendezvous operation
+====================
+
+Finally, the *rendezvous* operation is invoked via the *rendezvous()*
+method in the *Comm* class.  Depending on how much communication is
+needed and how many processors a LAMMPS simulation is running on, it
+can be a much more efficient choice than the *ring()* method.  It uses
+the *irregular* operation internally once or twice to do its
+communication.  The rendezvous algorithm is described in detail in
+:ref:`(Plimpton) <Plimpton>`, including some LAMMPS use cases.
+
+For the *rendezvous()* method, each processor specifies a list of *N*
+datums to send and which processor to send each of them to.
+Internally, this communication is performed as an irregular operation.
+The received datums are returned to the caller via invocation of
+*callback* function, provided as an argument to *rendezvous()*.  The
+caller can then process the received datums and (optionally) assemble
+a new list of datums to communicate to a new list of specific
+processors.  When the callback function exits, the *rendezvous()*
+method performs a second irregular communication on the new list of
+datums.
+
+Examples in LAMMPS of use of the *rendezvous* operation are the
+:doc:`fix rigid/small <fix_rigid>` and :doc:`fix shake
+<fix_shake>` commands (for one-time identification of the rigid body
+atom clusters) and the identification of special_bond 1-2, 1-3 and 1-4
+neighbors within molecules.  See the :doc:`special_bonds <special_bonds>`
+command for context.
+
+----------
+
+.. _Plimpton:
+
+**(Plimpton)** Plimpton and Knight, JPDC, 147, 184-195 (2021).

doc/src/Developer_notes.rst

@@ -7,6 +7,215 @@ typically document what a variable stores, what a small section of
 code does, or what a function does and its input/outputs.  The topics
 on this page are intended to document code functionality at a higher level.
 
+Available topics are:
+
+- `Reading and parsing of text and text files`_
+- `Requesting and accessing neighbor lists`_
+- `Fix contributions to instantaneous energy, virial, and cumulative energy`_
+- `KSpace PPPM FFT grids`_
+
+----
+
+Reading and parsing of text and text files
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+It is frequently required for a class in LAMMPS to read in additional
+data from a file, e.g. potential parameters from a potential file for
+manybody potentials.  LAMMPS provides several custom classes and
+convenience functions to simplify the process.  They offer the
+following benefits:
+
+- better code reuse and fewer lines of code needed to implement reading
+  and parsing data from a file
+- better detection of format errors, incompatible data, and better error messages
+- exit with an error message instead of silently converting only part of the
+  text to a number or returning a 0 on unrecognized text and thus reading incorrect values
+- re-entrant code through avoiding global static variables (as used by ``strtok()``)
+- transparent support for translating unsupported UTF-8 characters to their ASCII equivalents
+  (the text-to-value conversion functions **only** accept ASCII characters)
+
+In most cases (e.g. potential files) the same data is needed on all MPI
+ranks.  Then it is best to do the reading and parsing only on MPI rank
+0, and communicate the data later with one or more ``MPI_Bcast()``
+calls.  For reading generic text and potential parameter files the
+custom classes :cpp:class:`TextFileReader <LAMMPS_NS::TextFileReader>`
+and :cpp:class:`PotentialFileReader <LAMMPS_NS::PotentialFileReader>`
+are available. They allow reading the file as individual lines for which
+they can return a tokenizer class (see below) for parsing the line.  Or
+they can return blocks of numbers as a vector directly.  The
+documentation on :ref:`File reader classes <file-reader-classes>`
+contains an example for a typical case.
+
+When reading per-atom data, the data on each line of the file usually
+needs to include an atom ID so it can be associated with a particular
+atom.  In that case the data can be read in multi-line chunks and
+broadcast to all MPI ranks with
+:cpp:func:`utils::read_lines_from_file()
+<LAMMPS_NS::utils::read_lines_from_file>`.  Those chunks are then
+split into lines, parsed, and applied only to atoms the MPI rank
+"owns".
+
+For splitting a string (incrementally) into words and optionally
+converting those to numbers, the :cpp:class:`Tokenizer
+<LAMMPS_NS::Tokenizer>` and :cpp:class:`ValueTokenizer
+<LAMMPS_NS::ValueTokenizer>` can be used.  Those provide a superset of
+the functionality of ``strtok()`` from the C-library and the latter
+also includes conversion to different types.  Any errors while
+processing the string in those classes will result in an exception,
+which can be caught and the error processed as needed.  Unlike the
+C-library functions ``atoi()``, ``atof()``, ``strtol()``, or
+``strtod()`` the conversion will check if the converted text is a
+valid integer or floating point number and will not silently return an
+unexpected or incorrect value.  For example, ``atoi()`` will return 12
+when converting "12.5", while the ValueTokenizer class will throw an
+:cpp:class:`InvalidIntegerException
+<LAMMPS_NS::InvalidIntegerException>` if
+:cpp:func:`ValueTokenizer::next_int()
+<LAMMPS_NS::ValueTokenizer::next_int>` is called on the same string.
+
+Requesting and accessing neighbor lists
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+LAMMPS uses Verlet-style neighbor lists to avoid having to loop over
+*all* pairs of *all* atoms when computing pairwise properties with a
+cutoff (e.g. pairwise forces or radial distribution functions).  There
+are three main algorithms that can be selected by the :doc:`neighbor
+command <neighbor>`: `bin` (the default, uses binning to achieve linear
+scaling with system size), `nsq` (without binning, quadratic scaling),
+`multi` (with binning, optimized for varying cutoffs or polydisperse
+granular particles).  In addition to how the neighbor lists are
+constructed a number of different variants of neighbor lists need to be
+created (e.g. "full" or "half") for different purposes and styles and
+those may be required in every time step ("perpetual") or on some steps
+("occasional").
+
+The neighbor list creation is managed by the ``Neighbor`` class.
+Individual classes can obtain a neighbor list by creating an instance of
+a ``NeighRequest`` class which is stored in a list inside the
+``Neighbor`` class.  The ``Neighbor`` class will then analyze the
+various requests and apply optimizations where neighbor lists that have
+the same settings will be created only once and then copied, or a list
+may be constructed by processing a neighbor list from a different
+request that is a superset of the requested list.  The neighbor list
+build is then :doc:`processed in parallel <Developer_par_neigh>`.
+
+The most commonly required neighbor list is a so-called "half" neighbor
+list, where each pair of atoms is listed only once (except when the
+:doc:`newton command setting <newton>` for pair is off; in that case
+pairs straddling sub-domains or periodic boundaries will be listed twice).
+Thus these are the default settings when a neighbor list request is created in:
+
+.. code-block:: C++
+
+   void Pair::init_style()
+   {
+     neighbor->add_request(this);
+   }
+
+   void Pair::init_list(int /*id*/, NeighList *ptr)
+   {
+     list = ptr;
+   }
+
+The ``this`` pointer argument is required so the neighbor list code can
+access the requesting class instance to store the assembled neighbor
+list with that instance by calling its ``init_list()`` member function.
+The optional second argument (omitted here) contains a bitmask of flags
+that determines the kind of neighbor list requested.  The default value
+used here asks for a perpetual "half" neighbor list.
+
+Non-default values of the second argument need to be used to adjust a
+neighbor list request to the specific needs of a style an additional
+request flag is needed.  The :doc:`tersoff <pair_tersoff>` pair style,
+for example, needs a "full" neighbor list:
+
+.. code-block:: C++
+
+   void PairTersoff::init_style()
+   {
+     // [...]
+     neighbor->add_request(this, NeighConst::REQ_FULL);
+   }
+
+When a pair style supports r-RESPA time integration with different cutoff regions,
+the request flag may depend on the corresponding r-RESPA settings. Here an example
+from pair style lj/cut:
+
+.. code-block:: C++
+
+   void PairLJCut::init_style()
+   {
+     int list_style = NeighConst::REQ_DEFAULT;
+
+     if (update->whichflag == 1 && utils::strmatch(update->integrate_style, "^respa")) {
+       auto respa = (Respa *) update->integrate;
+       if (respa->level_inner >= 0) list_style = NeighConst::REQ_RESPA_INOUT;
+       if (respa->level_middle >= 0) list_style = NeighConst::REQ_RESPA_ALL;
+     }
+     neighbor->add_request(this, list_style);
+     // [...]
+   }
+
+Granular pair styles need neighbor lists based on particle sizes and not cutoff
+and also may require to have the list of previous neighbors available ("history").
+For example with:
+
+.. code-block:: C++
+
+   if (use_history) neighbor->add_request(this, NeighConst::REQ_SIZE | NeighConst::REQ_HISTORY);
+   else neighbor->add_request(this, NeighConst::REQ_SIZE);
+
+In case a class would need to make multiple neighbor list requests with different
+settings each request can set an id which is then used in the corresponding
+``init_list()`` function to assign it to the suitable pointer variable. This is
+done for example by the :doc:`pair style meam <pair_meam>`:
+
+.. code-block:: C++
+
+   void PairMEAM::init_style()
+   {
+   // [...]
+     neighbor->add_request(this, NeighConst::REQ_FULL)->set_id(1);
+     neighbor->add_request(this)->set_id(2);
+   }
+   void PairMEAM::init_list(int id, NeighList *ptr)
+   {
+     if (id == 1) listfull = ptr;
+     else if (id == 2) listhalf = ptr;
+   }
+
+Fixes may require a neighbor list that is only build occasionally (or
+just once) and this can also be indicated by a flag.  As an example here
+is the request from the ``FixPeriNeigh`` class which is created
+internally by :doc:`Peridynamics pair styles <pair_peri>`:
+
+.. code-block:: C++
+
+   neighbor->add_request(this, NeighConst::REQ_FULL | NeighConst::REQ_OCCASIONAL);
+
+It is also possible to request a neighbor list that uses a different cutoff
+than what is usually inferred from the pair style settings (largest cutoff of
+all pair styles plus neighbor list skin).  The following is used in the
+:doc:`compute rdf <compute_rdf>` command implementation:
+
+.. code-block:: C++
+
+  if (cutflag)
+    neighbor->add_request(this, NeighConst::REQ_OCCASIONAL)->set_cutoff(mycutneigh);
+  else
+    neighbor->add_request(this, NeighConst::REQ_OCCASIONAL);
+
+The neighbor list request function has a slightly different set of arguments
+when created by a command style.  In this case the neighbor list is
+*always* an occasional neighbor list, so that flag is not needed. However
+for printing the neighbor list summary the name of the requesting command
+should be set.  Below is the request from the :doc:`delete atoms <delete_atoms>`
+command:
+
+.. code-block:: C++
+
+   neighbor->add_request(this, "delete_atoms", NeighConst::REQ_FULL);
+
 Fix contributions to instantaneous energy, virial, and cumulative energy
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 

doc/src/Developer_org.rst

@@ -225,7 +225,7 @@ follows:
   commands in an input script.
 
 - The Force class computes various forces between atoms.  The Pair
-  parent class is for non-bonded or pair-wise forces, which in LAMMPS
+  parent class is for non-bonded or pairwise forces, which in LAMMPS
   also includes many-body forces such as the Tersoff 3-body potential if
   those are computed by walking pairwise neighbor lists.  The Bond,
   Angle, Dihedral, Improper parent classes are styles for bonded
@@ -252,12 +252,6 @@ follows:
 - The Timer class logs timing information, output at the end
   of a run.
 
-.. TODO section on "Spatial decomposition and parallel operations"
-..       diagram of 3d processor grid, brick vs. tiled. local vs. ghost
-..       atoms, 6-way communication with pack/unpack functions,
-..       PBC as part of the communication, forward and reverse communication
-..       rendezvous communication, ring communication.
-
 .. TODO section on "Fixes, Computes, and Variables"
 ..      how and when data is computed and provided and how it is
 ..      referenced. flags in Fix/Compute/Variable classes tell

doc/src/Developer_platform.rst

@@ -118,6 +118,9 @@ Environment variable functions
 .. doxygenfunction:: putenv
    :project: progguide
 
+.. doxygenfunction:: unsetenv
+   :project: progguide
+
 .. doxygenfunction:: list_pathenv
    :project: progguide
 

doc/src/Developer_plugins.rst

@@ -8,11 +8,20 @@ without recompiling LAMMPS.  The functionality for this and the
 
 Plugins use the operating system's capability to load dynamic shared
 object (DSO) files in a way similar shared libraries and then reference
-specific functions in those DSOs.  Any DSO file with plugins has to include
-an initialization function with a specific name, "lammpsplugin_init", that
-has to follow specific rules described below.  When loading the DSO with
-the "plugin" command, this function is looked up and called and will then
-register the contained plugin(s) with LAMMPS.
+specific functions in those DSOs.  Any DSO file with plugins has to
+include an initialization function with a specific name,
+"lammpsplugin_init", that has to follow specific rules described below.
+When loading the DSO with the "plugin" command, this function is looked
+up and called and will then register the contained plugin(s) with
+LAMMPS.
+
+When the environment variable ``LAMMPS_PLUGIN_PATH`` is set, then LAMMPS
+will search the directory (or directories) listed in this path for files
+with names that end in ``plugin.so`` (e.g. ``helloplugin.so``) and will
+try to load the contained plugins automatically at start-up.  For
+plugins that are loaded this way, the behavior of LAMMPS should be
+identical to a binary where the corresponding code was compiled in
+statically as a package.
 
 From the programmer perspective this can work because of the object
 oriented design of LAMMPS where all pair style commands are derived from
@@ -65,19 +74,18 @@ Members of ``lammpsplugin_t``
    * - handle
      - Pointer to the open DSO file handle
 
-Only one of the three alternate creator entries can be used at a time
-and which of those is determined by the style of plugin. The
-"creator.v1" element is for factory functions of supported styles
-computing forces (i.e.  command, pair, bond, angle, dihedral, or
-improper styles) and the function takes as single argument the pointer
-to the LAMMPS instance. The factory function is cast to the
-``lammpsplugin_factory1`` type before assignment.  The "creator.v2"
-element is for factory functions creating an instance of a fix, compute,
-or region style and takes three arguments: a pointer to the LAMMPS
-instance, an integer with the length of the argument list and a ``char
-**`` pointer to the list of arguments. The factory function pointer
-needs to be cast to the ``lammpsplugin_factory2`` type before
-assignment.
+Only one of the two alternate creator entries can be used at a time and
+which of those is determined by the style of plugin. The "creator.v1"
+element is for factory functions of supported styles computing forces
+(i.e. pair, bond, angle, dihedral, or improper styles) or command styles
+and the function takes as single argument the pointer to the LAMMPS
+instance. The factory function is cast to the ``lammpsplugin_factory1``
+type before assignment.  The "creator.v2" element is for factory
+functions creating an instance of a fix, compute, or region style and
+takes three arguments: a pointer to the LAMMPS instance, an integer with
+the length of the argument list and a ``char **`` pointer to the list of
+arguments. The factory function pointer needs to be cast to the
+``lammpsplugin_factory2`` type before assignment.
 
 Pair style example
 ^^^^^^^^^^^^^^^^^^
@@ -249,3 +257,8 @@ by ``#ifdef PAIR_CLASS`` is not needed, since the mapping of the class
 name to the style name is done by the plugin registration function with
 the information from the ``lammpsplugin_t`` struct.  It may be included
 in case the new code is intended to be later included in LAMMPS directly.
+
+A plugin may be registered under an existing style name.  In that case
+the plugin will override the existing code.  This can be used to modify
+the behavior of existing styles or to debug new versions of them without
+having to re-compile or re-install all of LAMMPS.

doc/src/Developer_utils.rst

@@ -21,18 +21,21 @@ In that case, the functions will stop with an error message, indicating
 the name of the problematic file, if possible unless the *error* argument
 is a NULL pointer.
 
-The :cpp:func:`fgets_trunc` function will work similar for ``fgets()``
-but it will read in a whole line (i.e. until the end of line or end
-of file), but store only as many characters as will fit into the buffer
-including a final newline character and the terminating NULL byte.
-If the line in the file is longer it will thus be truncated in the buffer.
-This function is used by :cpp:func:`read_lines_from_file` to read individual
-lines but make certain they follow the size constraints.
+The :cpp:func:`utils::fgets_trunc() <LAMMPS_NS::utils::fgets_trunc>`
+function will work similar for ``fgets()`` but it will read in a whole
+line (i.e. until the end of line or end of file), but store only as many
+characters as will fit into the buffer including a final newline
+character and the terminating NULL byte.  If the line in the file is
+longer it will thus be truncated in the buffer.  This function is used
+by :cpp:func:`utils::read_lines_from_file()
+<LAMMPS_NS::utils::read_lines_from_file>` to read individual lines but
+make certain they follow the size constraints.
 
-The :cpp:func:`read_lines_from_file` function will read the requested
-number of lines of a maximum length into a buffer and will return 0
-if successful or 1 if not. It also guarantees that all lines are
-terminated with a newline character and the entire buffer with a
+The :cpp:func:`utils::read_lines_from_file()
+<LAMMPS_NS::utils::read_lines_from_file>` function will read the
+requested number of lines of a maximum length into a buffer and will
+return 0 if successful or 1 if not. It also guarantees that all lines
+are terminated with a newline character and the entire buffer with a
 NULL character.
 
 ----------
@@ -56,13 +59,13 @@ String to number conversions with validity check
 
 These functions should be used to convert strings to numbers. They are
 are strongly preferred over C library calls like ``atoi()`` or
-``atof()`` since they check if the **entire** provided string is a valid
+``atof()`` since they check if the **entire** string is a valid
 (floating-point or integer) number, and will error out instead of
 silently returning the result of a partial conversion or zero in cases
-where the string is not a valid number.  This behavior allows to more
-easily detect typos or issues when processing input files.
+where the string is not a valid number.  This behavior improves
+detecting typos or issues when processing input files.
 
-Similarly the :cpp:func:`logical() <LAMMPS_NS::utils::logical>` function
+Similarly the :cpp:func:`utils::logical() <LAMMPS_NS::utils::logical>` function
 will convert a string into a boolean and will only accept certain words.
 
 The *do_abort* flag should be set to ``true`` in case  this function
@@ -70,25 +73,40 @@ is called only on a single MPI rank, as that will then trigger the
 a call to ``Error::one()`` for errors instead of ``Error::all()``
 and avoids a "hanging" calculation when run in parallel.
 
-Please also see :cpp:func:`is_integer() <LAMMPS_NS::utils::is_integer>`
-and :cpp:func:`is_double() <LAMMPS_NS::utils::is_double>` for testing
+Please also see :cpp:func:`utils::is_integer() <LAMMPS_NS::utils::is_integer>`
+and :cpp:func:`utils::is_double() <LAMMPS_NS::utils::is_double>` for testing
 strings for compliance without conversion.
 
 ----------
 
-.. doxygenfunction:: numeric
+.. doxygenfunction:: numeric(const char *file, int line, const std::string &str, bool do_abort, LAMMPS *lmp)
    :project: progguide
 
-.. doxygenfunction:: inumeric
+.. doxygenfunction:: numeric(const char *file, int line, const char *str, bool do_abort, LAMMPS *lmp)
    :project: progguide
 
-.. doxygenfunction:: bnumeric
+.. doxygenfunction:: inumeric(const char *file, int line, const std::string &str, bool do_abort, LAMMPS *lmp)
    :project: progguide
 
-.. doxygenfunction:: tnumeric
+.. doxygenfunction:: inumeric(const char *file, int line, const char *str, bool do_abort, LAMMPS *lmp)
    :project: progguide
 
-.. doxygenfunction:: logical
+.. doxygenfunction:: bnumeric(const char *file, int line, const std::string &str, bool do_abort, LAMMPS *lmp)
+   :project: progguide
+
+.. doxygenfunction:: bnumeric(const char *file, int line, const char *str, bool do_abort, LAMMPS *lmp)
+   :project: progguide
+
+.. doxygenfunction:: tnumeric(const char *file, int line, const std::string &str, bool do_abort, LAMMPS *lmp)
+   :project: progguide
+
+.. doxygenfunction:: tnumeric(const char *file, int line, const char *str, bool do_abort, LAMMPS *lmp)
+   :project: progguide
+
+.. doxygenfunction:: logical(const char *file, int line, const std::string &str, bool do_abort, LAMMPS *lmp)
+   :project: progguide
+
+.. doxygenfunction:: logical(const char *file, int line, const char *str, bool do_abort, LAMMPS *lmp)
    :project: progguide
 
 
@@ -190,6 +208,9 @@ Convenience functions
 .. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &mesg)
    :project: progguide
 
+.. doxygenfunction:: flush_buffers(LAMMPS *lmp)
+   :project: progguide
+
 .. doxygenfunction:: getsyserror
    :project: progguide
 
@@ -322,11 +343,11 @@ This code example should produce the following output:
 
 .. doxygenclass:: LAMMPS_NS::InvalidIntegerException
    :project: progguide
-   :members: what
+   :members:
 
 .. doxygenclass:: LAMMPS_NS::InvalidFloatException
    :project: progguide
-   :members: what
+   :members:
 
 ----------
 
@@ -375,21 +396,26 @@ A typical code segment would look like this:
 
 ----------
 
+.. _file-reader-classes:
+
 File reader classes
 -------------------
 
 The purpose of the file reader classes is to simplify the recurring task
 of reading and parsing files. They can use the
-:cpp:class:`LAMMPS_NS::ValueTokenizer` class to process the read in
-text.  The :cpp:class:`LAMMPS_NS::TextFileReader` is a more general
-version while :cpp:class:`LAMMPS_NS::PotentialFileReader` is specialized
-to implement the behavior expected for looking up and reading/parsing
-files with potential parameters in LAMMPS.  The potential file reader
-class requires a LAMMPS instance, requires to be run on MPI rank 0 only,
-will use the :cpp:func:`LAMMPS_NS::utils::get_potential_file_path`
-function to look up and open the file, and will call the
-:cpp:class:`LAMMPS_NS::Error` class in case of failures to read or to
-convert numbers, so that LAMMPS will be aborted.
+:cpp:class:`ValueTokenizer <LAMMPS_NS::ValueTokenizer>` class to process
+the read in text.  The :cpp:class:`TextFileReader
+<LAMMPS_NS::TextFileReader>` is a more general version while
+:cpp:class:`PotentialFileReader <LAMMPS_NS::PotentialFileReader>` is
+specialized to implement the behavior expected for looking up and
+reading/parsing files with potential parameters in LAMMPS.  The
+potential file reader class requires a LAMMPS instance, requires to be
+run on MPI rank 0 only, will use the
+:cpp:func:`utils::get_potential_file_path
+<LAMMPS_NS::utils::get_potential_file_path>` function to look up and
+open the file, and will call the :cpp:class:`LAMMPS_NS::Error` class in
+case of failures to read or to convert numbers, so that LAMMPS will be
+aborted.
 
 .. code-block:: C++
    :caption: Use of PotentialFileReader class in pair style coul/streitz
@@ -464,10 +490,10 @@ provided, as that is used to determine whether a new page of memory
 must be used.
 
 The :cpp:class:`MyPage <LAMMPS_NS::MyPage>` class offers two ways to
-reserve a chunk: 1) with :cpp:func:`get() <LAMMPS_NS::MyPage::get>` the
-chunk size needs to be known in advance, 2) with :cpp:func:`vget()
+reserve a chunk: 1) with :cpp:func:`MyPage::get() <LAMMPS_NS::MyPage::get>` the
+chunk size needs to be known in advance, 2) with :cpp:func:`MyPage::vget()
 <LAMMPS_NS::MyPage::vget>` a pointer to the next chunk is returned, but
-its size is registered later with :cpp:func:`vgot()
+its size is registered later with :cpp:func:`MyPage::vgot()
 <LAMMPS_NS::MyPage::vgot>`.
 
 .. code-block:: C++
@@ -570,4 +596,3 @@ the communication buffers.
 
 .. doxygenunion:: LAMMPS_NS::ubuf
    :project: progguide
-

doc/src/Developer_write.rst

@@ -55,7 +55,7 @@ of each timestep. First of all, implement a constructor:
      if (narg < 4)
        error->all(FLERR,"Illegal fix print/vel command");
 
-     nevery = force->inumeric(FLERR,arg[3]);
+     nevery = utils::inumeric(FLERR,arg[3],false,lmp);
      if (nevery <= 0)
        error->all(FLERR,"Illegal fix print/vel command");
    }

doc/src/Errors_messages.rst

@@ -1941,6 +1941,9 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
 *Compute ID for fix numdiff does not exist*
    Self-explanatory.
 
+*Compute ID for fix numdiff/virial does not exist*
+   Self-explanatory.
+
 *Compute ID for fix store/state does not exist*
    Self-explanatory.
 
@@ -3796,6 +3799,10 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
    Self-explanatory. Efficient loop over all atoms for numerical
    difference requires consecutive atom IDs.
 
+*Fix numdiff/virial must use group all*
+   Virial contributions computed by this fix are
+   computed on all atoms.
+
 *Fix nve/asphere requires extended particles*
    This fix can only be used for particles with a shape setting.
 
@@ -7772,9 +7779,6 @@ keyword to allow for additional bonds to be formed
    The system size must fit in a 32-bit integer to use this dump
    style.
 
-*Too many atoms to dump sort*
-   Cannot sort when running with more than 2\^31 atoms.
-
 *Too many elements extracted from MEAM library.*
    Increase 'maxelt' in meam.h and recompile.
 

doc/src/Errors_warnings.rst

@@ -416,7 +416,7 @@ This will most likely cause errors in kinetic fluctuations.
    not defined for the specified atom style.
 
 *Molecule has bond topology but no special bond settings*
-   This means the bonded atoms will not be excluded in pair-wise
+   This means the bonded atoms will not be excluded in pairwise
    interactions.
 
 *Molecule template for create_atoms has multiple molecules*

doc/src/Howto_drude2.rst

@@ -491,11 +491,6 @@ NPT ensemble using Nose-Hoover thermostat:
 **(Schroeder)**  Schroeder and Steinhauser, J Chem Phys, 133,
 154511 (2010).
 
-.. _Jiang2:
-
-**(Jiang)** Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux,
- J Phys Chem Lett, 2, 87-92 (2011).
-
 .. _Thole2:
 
 **(Thole)** Chem Phys, 59, 341 (1981).

doc/src/Howto_github.rst

@@ -141,7 +141,8 @@ unrelated feature, you should switch branches!
    Committing changes to the *develop*, *release*, or *stable* branches
    is strongly discouraged.  While it may be convenient initially, it
    will create more work in the long run.  Various texts and tutorials
-   on using git effectively discuss the motivation for this.
+   on using git effectively discuss the motivation for using feature
+   branches instead.
 
 **After changes are made**
 

doc/src/Howto_pylammps.rst

@@ -545,6 +545,6 @@ Feedback and Contributing
 -------------------------
 
 If you find this Python interface useful, please feel free to provide feedback
-and ideas on how to improve it to Richard Berger (richard.berger@temple.edu). We also
+and ideas on how to improve it to Richard Berger (richard.berger@outlook.com). We also
 want to encourage people to write tutorial style IPython notebooks showcasing LAMMPS usage
 and maybe their latest research results.

doc/src/Howto_structured_data.rst

@@ -21,7 +21,8 @@ YAML
    print """---
    timestep: $(step)
    pe: $(pe)
-   ke: $(ke)""" file current_state.yaml screen no
+   ke: $(ke)
+   ...""" file current_state.yaml screen no
 
 .. code-block:: yaml
    :caption: current_state.yaml
@@ -51,6 +52,58 @@ JSON
      "ke": 2.4962152903997174569
    }
 
+YAML format thermo_style output
+===============================
+
+.. versionadded:: 24Mar2022
+
+LAMMPS supports the thermo style "yaml" and for "custom" style
+thermodynamic output the format can be changed to YAML with
+:doc:`thermo_modify line yaml <thermo_modify>`.  This will produce a
+block of output in a compact YAML format - one "document" per run - of
+the following style:
+
+.. code-block:: yaml
+
+   ---
+   keywords: [Step, Temp, E_pair, E_mol, TotEng, Press, ]
+   data:
+     - [100, 0.757453103239935, -5.7585054860159, 0, -4.62236133677021, 0.207261053624721, ]
+     - [110, 0.759322359337036, -5.7614668389562, 0, -4.62251889318624, 0.194314975399602, ]
+     - [120, 0.759372342462676, -5.76149365656489, 0, -4.62247073844943, 0.191600048851267, ]
+     - [130, 0.756833027516501, -5.75777334823494, 0, -4.62255928350835, 0.208792327853067, ]
+   ...
+
+This data can be extracted and parsed from a log file using python with:
+
+.. code-block:: python
+
+   import re, yaml
+
+   docs = ""
+   with open("log.lammps") as f:
+       for line in f:
+           m = re.search(r"^(keywords:.*$|data:$|---$|\.\.\.$|  - \[.*\]$)", line)
+           if m: docs += m.group(0) + '\n'
+
+   thermo = list(yaml.load_all(docs, Loader=yaml.SafeLoader))
+
+   print("Number of runs: ", len(thermo))
+   print(thermo[1]['keywords'][4], ' = ', thermo[1]['data'][2][4])
+
+After loading the YAML data, `thermo` is a list containing a dictionary
+for each "run" where the tag "keywords" maps to the list of thermo
+header strings and the tag "data" has a list of lists where the outer
+list represents the lines of output and the inner list the values of the
+columns matching the header keywords for that step.  The second print()
+command for example will print the header string for the fifth keyword
+of the second run and the corresponding value for the third output line
+of that run:
+
+.. parsed-literal::
+
+   Number of runs:  2
+   TotEng  =  -4.62140097780047
 
 Writing continuous data during a simulation
 ===========================================

doc/src/Install_git.rst

@@ -28,8 +28,9 @@ provides `limited support for subversion clients <svn_>`_.
 
 You can follow the LAMMPS development on 3 different git branches:
 
-* **stable**   :  this branch is updated with every stable release;
-  updates are always "fast forward" merges from *develop*
+* **stable**   :  this branch is updated from the *release* branch with
+  every stable release version and also has selected bug fixes and updates
+  back-ported from the *develop* branch
 * **release**  :  this branch is updated with every patch release;
   updates are always "fast forward" merges from *develop*
 * **develop**  :  this branch follows the ongoing development and
@@ -47,20 +48,22 @@ your machine and "release" is one of the 3 branches listed above.
 (Note that you actually download all 3 branches; you can switch
 between them at any time using "git checkout <branch name>".)
 
-.. note::
+.. admonition:: Saving time and disk space when using ``git clone``
 
    The complete git history of the LAMMPS project is quite large because
    it contains the entire commit history of the project since fall 2006,
-   which includes the time when LAMMPS was managed with subversion. This
-   also includes commits that have added and removed some large files
-   (mostly by accident).  If you do not need access to the entire commit
-   history, you can speed up the "cloning" process and reduce local disk
-   space requirements by using the *--depth* git command line flag thus
-   create a "shallow clone" of the repository that contains only a
-   subset of the git history. Using a depth of 1000 is usually sufficient
-   to include the head commits of the *develop* and the *release* branches.
-   To include the head commit of the *stable* branch you may need a depth
-   of up to 10000.
+   which includes the time when LAMMPS was managed with subversion.
+   This includes a few commits that have added and removed some large
+   files (mostly by accident).  If you do not need access to the entire
+   commit history (most people don't), you can speed up the "cloning"
+   process and reduce local disk space requirements by using the
+   *--depth* git command line flag.  That will create a "shallow clone"
+   of the repository containing only a subset of the git history.  Using
+   a depth of 1000 is usually sufficient to include the head commits of
+   the *develop* and the *release* branches.  To include the head commit
+   of the *stable* branch you may need a depth of up to 10000.  If you
+   later need more of the git history, you can always convert the
+   shallow clone into a "full clone".
 
 Once the command completes, your directory will contain the same files
 as if you unpacked a current LAMMPS tarball, with the exception, that
@@ -156,11 +159,10 @@ changed.  How to do this depends on the build system you are using.
 .. admonition:: Git protocols
    :class: note
 
-   The servers at github.com support the "git://" and "https://" access
-   protocols for anonymous, read-only access.  If you have a suitably
-   configured GitHub account, you may also use SSH protocol with the
+   The servers at github.com support the "https://" access protocol for
+   anonymous, read-only access.  If you have a suitably configured GitHub
+   account, you may also use SSH protocol with the
    URL "git@github.com:lammps/lammps.git".
 
 The LAMMPS GitHub project is currently managed by Axel Kohlmeyer
-(Temple U, akohlmey at gmail.com) and Richard Berger (Temple U,
-richard.berger at temple.edu).
+(Temple U, akohlmey at gmail.com).

doc/src/Intro_authors.rst

@@ -8,7 +8,7 @@ University:
 * Aidan Thompson, athomps at sandia.gov
 * Stan Moore, stamoor at sandia.gov
 * Axel Kohlmeyer, akohlmey at gmail.com
-* Richard Berger, richard.berger at temple.edu
+* Richard Berger, richard.berger at outlook.com
 
 .. _sjp: http://www.cs.sandia.gov/~sjplimp
 .. _lws: https://www.lammps.org

doc/src/Intro_citing.rst

@@ -16,7 +16,7 @@ source code design, the program structure, the spatial decomposition
 approach, the neighbor finding, basic communications algorithms, and how
 users and developers have contributed to LAMMPS is:
 
-  `LAMMPS - A flexible simulation tool for particle-based materials modeling at the atomic, meso, and continuum scales, Comp. Phys. Comm. (accepted 09/2021), DOI:10.1016/j.cpc.2021.108171 <https://doi.org/10.1016/j.cpc.2021.108171>`_
+  `LAMMPS - A flexible simulation tool for particle-based materials modeling at the atomic, meso, and continuum scales, Comp. Phys. Comm. 271, 108171 (2022) <https://doi.org/10.1016/j.cpc.2021.108171>`_
 
 So a project using LAMMPS or a derivative application that uses LAMMPS
 as a simulation engine should cite this paper.  The paper is expected to

doc/src/Library_utility.rst

@@ -13,6 +13,7 @@ functions.  They do not directly call the LAMMPS library.
 - :cpp:func:`lammps_fix_external_set_virial_peratom`
 - :cpp:func:`lammps_fix_external_set_vector_length`
 - :cpp:func:`lammps_fix_external_set_vector`
+- :cpp:func:`lammps_flush_buffers`
 - :cpp:func:`lammps_free`
 - :cpp:func:`lammps_is_running`
 - :cpp:func:`lammps_force_timeout`
@@ -72,6 +73,11 @@ where such memory buffers were allocated that require the use of
 
 -----------------------
 
+.. doxygenfunction:: lammps_flush_buffers
+   :project: progguide
+
+-----------------------
+
 .. doxygenfunction:: lammps_free
    :project: progguide
 

doc/src/Manual_version.rst

@@ -10,23 +10,31 @@ Whenever we fix a bug or update or add a feature, it will be merged into
 the *develop* branch of the git repository.  When a sufficient number of
 changes have accumulated *and* the software passes a set of automated
 tests, we release it in the next *patch* release, which are made every
-few weeks.  Info on patch releases are on `this website page
+few weeks.  The *release* branch of the git repository is updated with
+every such release.  Info on patch releases are on `this website page
 <https://www.lammps.org/bug.html>`_.
 
-Once or twice a year, only bug fixes and small, non-intrusive changes are
-included for a period of time, and the code is subjected to more detailed
+Once or twice a year, we apply only bug fixes and small, non-intrusive
+changes to the *develop* branch and the code is subjected to more detailed
 and thorough testing than the default automated testing.  The latest
-patch release after such a period is then labeled as a *stable* version.
+patch release after such a period is then also labeled as a *stable* version
+and the *stable* branch is updated with it.  Between stable releases
+we occasionally release some updates to the stable release containing
+only bug fixes and updates back-ported from *develop* but no new features
+and update the *stable* branch accordingly.
 
-Each version of LAMMPS contains all the features and bug-fixes up to
-and including its version date.
+Each version of LAMMPS contains all the documented features up to and
+including its version date.
 
 The version date is printed to the screen and logfile every time you
 run LAMMPS. It is also in the file src/version.h and in the LAMMPS
 directory name created when you unpack a tarball.  And it is on the
 first page of the :doc:`manual <Manual>`.
 
-* If you browse the HTML pages on the LAMMPS WWW site, they always
-  describe the most current patch release of LAMMPS.
+* If you browse the HTML pages on the LAMMPS WWW site, they will by
+  default describe the most current patch release version of LAMMPS.
+  In the navigation bar on the bottom left, there is the option to
+  view instead the documentation for the most recent *stable* version
+  or the latest version from the current development branch.
 * If you browse the HTML pages included in your tarball, they
   describe the version you have, which may be older.

doc/src/Modify.rst

@@ -1,16 +1,17 @@
 Modifying & extending LAMMPS
 ****************************
 
-LAMMPS is designed in a modular fashion so as to be easy to modify and
+LAMMPS is designed in a modular fashion and to be easy to modify or
 extend with new functionality.  In fact, about 95% of its source code
-is add-on files.  These doc pages give basic instructions on how to do
-this.
+are optional.  The following pages give basic instructions on what
+is required when adding new styles of different kinds to LAMMPS.
 
-If you add a new feature to LAMMPS and think it will be of interest to
-general users, we encourage you to submit it for inclusion in LAMMPS
-as a pull request on our `GitHub site <https://github.com/lammps/lammps>`_,
-after reading about :doc:`how to prepare your code for submission <Modify_contribute>`
-and :doc:`the style requirements and recommendations <Modify_style>`.
+If you add a new feature to LAMMPS and think it will be of general
+interest to other users, we encourage you to submit it for inclusion in
+LAMMPS as a pull request on our `GitHub site
+<https://github.com/lammps/lammps>`_, after reading about :doc:`how to
+prepare your code for submission <Modify_contribute>` and :doc:`the
+style requirements and recommendations <Modify_style>`.
 
 .. toctree::
    :maxdepth: 1

doc/src/Modify_overview.rst

@@ -1,13 +1,14 @@
 Overview
 ========
 
-The best way to add a new feature to LAMMPS is to find a similar
-feature and look at the corresponding source and header files to figure
-out what it does.  You will need some knowledge of C++ to be able to
-understand the high-level structure of LAMMPS and its class
-organization, but functions (class methods) that do actual
-computations are written in vanilla C-style code and operate on simple
-C-style data structures (vectors and arrays).
+The best way to add a new feature to LAMMPS is to find a similar feature
+and look at the corresponding source and header files to figure out what
+it does.  You will need some knowledge of C++ to be able to understand
+the high-level structure of LAMMPS and its class organization, but
+functions (class methods) that do actual computations are mostly written
+in C-style code and operate on simple C-style data structures (vectors
+and arrays).  A high-level overview of the programming style choices in
+LAMMPS is :doc:`given elsewhere <Developer_code_design>`.
 
 Most of the new features described on the :doc:`Modify <Modify>` doc
 page require you to write a new C++ derived class (except for exceptions

doc/src/Modify_pair.rst

@@ -12,24 +12,24 @@ includes some optional methods to enable its use with rRESPA.
 
 Here is a brief description of the class methods in pair.h:
 
-+---------------------------------+-------------------------------------------------------------------+
-| compute                         | workhorse routine that computes pairwise interactions             |
-+---------------------------------+-------------------------------------------------------------------+
-| settings                        | reads the input script line with arguments you define             |
-+---------------------------------+-------------------------------------------------------------------+
-| coeff                           | set coefficients for one i,j type pair                            |
-+---------------------------------+-------------------------------------------------------------------+
-| init_one                        | perform initialization for one i,j type pair                      |
-+---------------------------------+-------------------------------------------------------------------+
-| init_style                      | initialization specific to this pair style                        |
-+---------------------------------+-------------------------------------------------------------------+
-| write & read_restart            | write/read i,j pair coeffs to restart files                       |
-+---------------------------------+-------------------------------------------------------------------+
-| write & read_restart_settings   | write/read global settings to restart files                       |
-+---------------------------------+-------------------------------------------------------------------+
-| single                          | force and energy of a single pairwise interaction between 2 atoms |
-+---------------------------------+-------------------------------------------------------------------+
-| compute_inner/middle/outer      | versions of compute used by rRESPA                                |
-+---------------------------------+-------------------------------------------------------------------+
++---------------------------------+---------------------------------------------------------------------+
+| compute                         | workhorse routine that computes pairwise interactions               |
++---------------------------------+---------------------------------------------------------------------+
+| settings                        | reads the input script line with arguments you define               |
++---------------------------------+---------------------------------------------------------------------+
+| coeff                           | set coefficients for one i,j type pair                              |
++---------------------------------+---------------------------------------------------------------------+
+| init_one                        | perform initialization for one i,j type pair                        |
++---------------------------------+---------------------------------------------------------------------+
+| init_style                      | initialization specific to this pair style                          |
++---------------------------------+---------------------------------------------------------------------+
+| write & read_restart            | write/read i,j pair coeffs to restart files                         |
++---------------------------------+---------------------------------------------------------------------+
+| write & read_restart_settings   | write/read global settings to restart files                         |
++---------------------------------+---------------------------------------------------------------------+
+| single                          | force/r and energy of a single pairwise interaction between 2 atoms |
++---------------------------------+---------------------------------------------------------------------+
+| compute_inner/middle/outer      | versions of compute used by rRESPA                                  |
++---------------------------------+---------------------------------------------------------------------+
 
 The inner/middle/outer routines are optional.

doc/src/Modify_style.rst

@@ -250,9 +250,11 @@ keep the code readable to programmers that have limited C++ programming
 experience.  C++ constructs are acceptable when they help improving the
 readability and reliability of the code, e.g. when using the
 `std::string` class instead of manipulating pointers and calling the
-string functions of the C library.  In addition and number of convenient
-:doc:`utility functions and classes <Developer_utils>` for recurring
-tasks are provided.
+string functions of the C library.  In addition a collection of
+convenient :doc:`utility functions and classes <Developer_utils>` for
+recurring tasks and a collection of
+:doc:`platform neutral functions <Developer_platform>` for improved
+portability are provided.
 
 Included Fortran code has to be compatible with the Fortran 2003
 standard.  Python code must be compatible with Python 3.5.  Large parts
@@ -261,10 +263,11 @@ compatible with Python 2.7.  Compatibility with Python 2.7 is
 desirable, but compatibility with Python 3.5 is **required**.
 
 Compatibility with these older programming language standards is very
-important to maintain portability, especially with HPC cluster
-environments, which tend to be running older software stacks and LAMMPS
-users may be required to use those older tools or not have the option to
-install newer compilers.
+important to maintain portability and availability of LAMMPS on many
+platforms.  This applies especially to HPC cluster environments, which
+tend to be running older software stacks and LAMMPS users may be
+required to use those older tools for access to advanced hardware
+features or not have the option to install newer compilers or libraries.
 
 Programming conventions (varied)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -305,6 +308,40 @@ you are uncertain, please ask.
   FILE pointers and only be done on MPI rank 0.  Use the :cpp:func:`utils::logmesg`
   convenience function where possible.
 
+- Usage of C++11 `virtual`, `override`, `final` keywords: Please follow the
+  `C++ Core Guideline C.128 <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override>`_.
+  That means, you should only use `virtual` to declare a new virtual
+  function, `override` to indicate you are overriding an existing virtual
+  function, and `final` to prevent any further overriding.
+
+- Trivial destructors: Prefer not writing destructors when they are empty and `default`.
+
+  .. code-block:: c++
+
+     // don't write destructors for A or B like this
+     class A : protected Pointers {
+      public:
+        A();
+        ~A() override {}
+     };
+
+     class B : protected Pointers {
+      public:
+        B();
+        ~B() override = default;
+     };
+
+     // instead, let the compiler create the implicit default destructor by not writing it
+     class A : protected Pointers {
+      public:
+        A();
+     };
+
+     class B : protected Pointers {
+      public:
+        B();
+     };
+
 - Header files, especially those defining a "style", should only use
   the absolute minimum number of include files and **must not** contain
   any ``using`` statements. Typically that would be only the header for

doc/src/Modify_thermo.rst

@@ -1,27 +1,54 @@
 Thermodynamic output options
 ============================
 
-There is one class that computes and prints thermodynamic information
-to the screen and log file; see the file thermo.cpp.
+The ``Thermo`` class computes and prints thermodynamic information to
+the screen and log file; see the files ``thermo.cpp`` and ``thermo.h``.
 
-There are two styles defined in thermo.cpp: "one" and "multi".  There
-is also a flexible "custom" style which allows the user to explicitly
-list keywords for quantities to print when thermodynamic info is
-output.  See the :doc:`thermo_style <thermo_style>` command for a list
-of defined quantities.
+There are four styles defined in ``thermo.cpp``: "one", "multi", "yaml",
+and "custom".  The "custom" style allows the user to explicitly list
+keywords for individual quantities to print when thermodynamic output is
+generated.  The others have a fixed list of keywords.  See the
+:doc:`thermo_style <thermo_style>` command for a list of available
+quantities.  The formatting of the "custom" style defaults to the "one"
+style, but can be adapted using :doc:`thermo_modify line <thermo_modify>`.
 
-The thermo styles (one, multi, etc) are simply lists of keywords.
-Adding a new style thus only requires defining a new list of keywords.
-Search for the word "customize" with references to "thermo style" in
-thermo.cpp to see the two locations where code will need to be added.
+The thermo styles (one, multi, etc) are defined by lists of keywords
+with associated formats for integer and floating point numbers and
+identified but an enumerator constant.  Adding a new style thus mostly
+requires defining a new list of keywords and the associated formats and
+then inserting the required output processing where the enumerators are
+identified.  Search for the word "CUSTOMIZATION" with references to
+"thermo style" in the ``thermo.cpp`` file to see the locations where
+code will need to be added.  The member function ``Thermo::header()``
+prints output at the very beginning of a thermodynamic output block and
+can be used to print column headers or other front matter.  The member
+function ``Thermo::footer()`` prints output at the end of a
+thermodynamic output block.  The formatting of the output is done by
+assembling a "line" (which may span multiple lines if the style inserts
+newline characters ("\n" as in the "multi" style).
 
-New keywords can also be added to thermo.cpp to compute new quantities
-for output.  Search for the word "customize" with references to
-"keyword" in thermo.cpp to see the several locations where code will
-need to be added.
+New thermodynamic keywords can also be added to ``thermo.cpp`` to
+compute new quantities for output.  Search for the word "CUSTOMIZATION"
+with references to "keyword" in ``thermo.cpp`` to see the several
+locations where code will need to be added.  Effectively, you need to
+define a member function that computes the property, add an if statement
+in ``Thermo::parse_fields()`` where the corresponding header string for
+the keyword and the function pointer is registered by calling the
+``Thermo::addfield()`` method, and add an if statement in
+``Thermo::evaluate_keyword()`` which is called from the ``Variable``
+class when a thermo keyword is encountered.
 
-Note that the :doc:`thermo_style custom <thermo_style>` command already allows
-for thermo output of quantities calculated by :doc:`fixes <fix>`,
-:doc:`computes <compute>`, and :doc:`variables <variable>`.  Thus, it may
-be simpler to compute what you wish via one of those constructs, than
-by adding a new keyword to the thermo command.
+.. note::
+
+   The third argument to ``Thermo::addfield()`` is a flag indicating
+   whether the function for the keyword computes a floating point
+   (FLOAT), regular integer (INT), or big integer (BIGINT) value.  This
+   information is used for formatting the thermodynamic output.  Inside
+   the function the result must then be stored either in the ``dvalue``,
+   ``ivalue`` or ``bivalue`` member variable, respectively.
+
+Since the :doc:`thermo_style custom <thermo_style>` command allows to
+use output of quantities calculated by :doc:`fixes <fix>`,
+:doc:`computes <compute>`, and :doc:`variables <variable>`, it may often
+be simpler to compute what you wish via one of those constructs, rather
+than by adding a new keyword to the thermo_style command.

doc/src/Modify_variable.rst

@@ -1,8 +1,8 @@
 Variable options
 ================
 
-There is one class that computes and stores :doc:`variable <variable>`
-information in LAMMPS; see the file variable.cpp.  The value
+The ``Variable`` class computes and stores :doc:`variable <variable>`
+information in LAMMPS; see the file ``variable.cpp``.  The value
 associated with a variable can be periodically printed to the screen
 via the :doc:`print <print>`, :doc:`fix print <fix_print>`, or
 :doc:`thermo_style custom <thermo_style>` commands.  Variables of style
@@ -19,21 +19,22 @@ of arguments:
    compute values = c_mytemp[0], c_thermo_press[3], ...
 
 Adding keywords for the :doc:`thermo_style custom <thermo_style>`
-command (which can then be accessed by variables) is discussed on the
-:doc:`Modify thermo <Modify_thermo>` doc page.
+command (which can then be accessed by variables) is discussed in the
+:doc:`Modify thermo <Modify_thermo>` documentation.
 
 Adding a new math function of one or two arguments can be done by
-editing one section of the Variable::evaluate() method.  Search for
+editing one section of the ``Variable::evaluate()`` method.  Search for
 the word "customize" to find the appropriate location.
 
 Adding a new group function can be done by editing one section of the
-Variable::evaluate() method.  Search for the word "customize" to find
-the appropriate location.  You may need to add a new method to the
-Group class as well (see the group.cpp file).
+``Variable::evaluate()`` method.  Search for the word "customize" to
+find the appropriate location.  You may need to add a new method to the
+Group class as well (see the ``group.cpp`` file).
 
 Accessing a new atom-based vector can be done by editing one section
 of the Variable::evaluate() method.  Search for the word "customize"
 to find the appropriate location.
 
 Adding new :doc:`compute styles <compute>` (whose calculated values can
-then be accessed by variables) is discussed on the :doc:`Modify compute <Modify_compute>` doc page.
+then be accessed by variables) is discussed in the :doc:`Modify compute
+<Modify_compute>` documentation.

doc/src/Packages_details.rst

@@ -9,7 +9,7 @@ gives links to documentation, example scripts, and pictures/movies (if
 available) that illustrate use of the package.
 
 The majority of packages can be included in a LAMMPS build with a
-single setting (``-D PGK_<NAME>=on`` for CMake) or command
+single setting (``-D PKG_<NAME>=on`` for CMake) or command
 (``make yes-<name>`` for make).  See the :doc:`Build package <Build_package>`
 page for more info.  A few packages may require additional steps;
 this is indicated in the descriptions below.  The :doc:`Build extras <Build_extras>`
@@ -1880,6 +1880,12 @@ MPIIO library.  It adds :doc:`dump styles <dump>` with a "mpiio" in
 their style name.  Restart files with an ".mpiio" suffix are also
 written and read in parallel.
 
+.. warning::
+
+   The MPIIO package is currently unmaintained and has become
+   unreliable. Use with caution.
+
+
 **Install:**
 
 The MPIIO package requires that LAMMPS is build in :ref:`MPI parallel mode <serial>`.
@@ -2148,6 +2154,11 @@ A :doc:`plugin <plugin>` command that can load and unload several
 kind of styles in LAMMPS from shared object files at runtime without
 having to recompile and relink LAMMPS.
 
+When the environment variable ``LAMMPS_PLUGIN_PATH`` is set, then LAMMPS
+will search the directory (or directories) listed in this path for files
+with names that end in ``plugin.so`` (e.g. ``helloplugin.so``) and will
+try to load the contained plugins automatically at start-up.
+
 **Authors:** Axel Kohlmeyer (Temple U)
 
 **Supporting info:**

doc/src/Python_install.rst

@@ -25,11 +25,10 @@ Installing the LAMMPS Python Module and Shared Library
 ======================================================
 
 Making LAMMPS usable within Python and vice versa requires putting the
-LAMMPS Python package (``lammps``) into a location where the
-Python interpreter can find it and installing the LAMMPS shared library
-into a folder that the dynamic loader searches or inside of the installed
-``lammps`` package folder.  There are multiple ways to achieve
-this.
+LAMMPS Python package (``lammps``) into a location where the Python
+interpreter can find it and installing the LAMMPS shared library into a
+folder that the dynamic loader searches or inside of the installed
+``lammps`` package folder.  There are multiple ways to achieve this.
 
 #. Do a full LAMMPS installation of libraries, executables, selected
    headers, documentation (if enabled), and supporting files (only
@@ -159,38 +158,52 @@ this.
 
          make install-python
 
-      This will try to install (only) the shared library and the Python
-      package into a system folder and if that fails (due to missing
-      write permissions) will instead do the installation to a user
-      folder under ``$HOME/.local``.  For a system-wide installation you
+      This will try to build a so-called (binary) 'wheel', a compressed
+      binary python package and then install it with the python package
+      manager 'pip'.  Installation will be attempted into a system-wide
+      ``site-packages`` folder and if that fails into the corresponding
+      folder in the user's home directory.  For a system-wide installation you
       would have to gain superuser privilege, e.g. though ``sudo``
 
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
-      | File                   | Location                                                        | Notes                                                       |
-      +========================+=================================================================+=============================================================+
-      | LAMMPS Python package  | * ``$HOME/.local/lib/pythonX.Y/site-packages/lammps`` (32bit)   | ``X.Y`` depends on the installed Python version             |
-      |                        | * ``$HOME/.local/lib64/pythonX.Y/site-packages/lammps`` (64bit) |                                                             |
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
-      | LAMMPS shared library  | * ``$HOME/.local/lib/pythonX.Y/site-packages/lammps`` (32bit)   | ``X.Y`` depends on the installed Python version             |
-      |                        | * ``$HOME/.local/lib64/pythonX.Y/site-packages/lammps`` (64bit) |                                                             |
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
+      +------------------------+----------------------------------------------------------+-------------------------------------------------------------+
+      | File                   | Location                                                 | Notes                                                       |
+      +========================+==========================================================+=============================================================+
+      | LAMMPS Python package  | * ``$HOME/.local/lib/pythonX.Y/site-packages/lammps``    | ``X.Y`` depends on the installed Python version             |
+      +------------------------+----------------------------------------------------------+-------------------------------------------------------------+
+      | LAMMPS shared library  | * ``$HOME/.local/lib/pythonX.Y/site-packages/lammps``    | ``X.Y`` depends on the installed Python version             |
+      +------------------------+----------------------------------------------------------+-------------------------------------------------------------+
 
       For a system-wide installation those folders would then become.
 
-      +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
-      | File                   | Location                                                | Notes                                                       |
-      +========================+=========================================================+=============================================================+
-      | LAMMPS Python package  | * ``/usr/lib/pythonX.Y/site-packages/lammps`` (32bit)   | ``X.Y`` depends on the installed Python version             |
-      |                        | * ``/usr/lib64/pythonX.Y/site-packages/lammps`` (64bit) |                                                             |
-      +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
-      | LAMMPS shared library  | * ``/usr/lib/pythonX.Y/site-packages/lammps`` (32bit)   | ``X.Y`` depends on the installed Python version             |
-      |                        | * ``/usr/lib64/pythonX.Y/site-packages/lammps`` (64bit) |                                                             |
-      +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
+      +------------------------+-------------------------------------------------+-------------------------------------------------------------+
+      | File                   | Location                                        | Notes                                                       |
+      +========================+=================================================+=============================================================+
+      | LAMMPS Python package  | * ``/usr/lib/pythonX.Y/site-packages/lammps``   | ``X.Y`` depends on the installed Python version             |
+      +------------------------+-------------------------------------------------+-------------------------------------------------------------+
+      | LAMMPS shared library  | * ``/usr/lib/pythonX.Y/site-packages/lammps``   | ``X.Y`` depends on the installed Python version             |
+      +------------------------+-------------------------------------------------+-------------------------------------------------------------+
 
       No environment variables need to be set for those, as those
       folders are searched by default by Python or the LAMMPS Python
       package.
 
+      .. versionchanged:: 24Mar2022
+
+      .. note::
+
+            If there is an existing installation of the LAMMPS python
+            module, ``make install-python`` will try to update it.
+            However, that will fail if the older version of the module
+            was installed by LAMMPS versions until 17Feb2022.  Those
+            were using the distutils package, which does not create a
+            "manifest" that allows a clean uninstall.  The ``make
+            install-python`` command will always produce a
+            lammps-<version>-<python>-<abi>-<os>-<arch>.whl file (the
+            'wheel'). And this file can be later installed directly with
+            ``python -m pip install <wheel file>.whl`` without having to
+            type ``make install-python`` again and repeating the build
+            step, too.
+
       For the traditional make process you can override the python
       version to version x.y when calling ``make`` with
       ``PYTHON=pythonX.Y``.  For a CMake based compilation this choice
@@ -201,16 +214,12 @@ this.
 
       .. code-block:: bash
 
-         $ python install.py -p <python package> -l <shared library> -v <version.h file> [-d <pydir>]
+         $ python install.py -p <python package> -l <shared library> [-n]
 
       * The ``-p`` flag points to the ``lammps`` Python package folder to be installed,
       * the ``-l`` flag points to the LAMMPS shared library file to be installed,
-      * the ``-v`` flag points to the ``version.h`` file in the LAMMPS source
-      * and the optional ``-d`` flag to a custom (legacy) installation folder
-
-      If you use a legacy installation folder, you will need to set your
-      ``PYTHONPATH`` and ``LD_LIBRARY_PATH`` (and/or ``DYLD_LIBRARY_PATH``) environment
-      variables accordingly as explained in the description for "In place use".
+      * and the optional ``-n`` instructs the script to only build a wheel file
+        but not attempt to install it.
 
    .. tab:: Virtual environment
 
@@ -257,32 +266,29 @@ this.
       package and the shared library file are installed into the
       following locations:
 
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
-      | File                   | Location                                                        | Notes                                                       |
-      +========================+=================================================================+=============================================================+
-      | LAMMPS Python Module   | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps`` (32bit)   | ``X.Y`` depends on the installed Python version             |
-      |                        | * ``$VIRTUAL_ENV/lib64/pythonX.Y/site-packages/lammps`` (64bit) |                                                             |
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
-      | LAMMPS shared library  | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps`` (32bit)   | ``X.Y`` depends on the installed Python version             |
-      |                        | * ``$VIRTUAL_ENV/lib64/pythonX.Y/site-packages/lammps`` (64bit) |                                                             |
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
+      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
+      | File                   | Location                                               | Notes                                                       |
+      +========================+========================================================+=============================================================+
+      | LAMMPS Python Module   | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps``  | ``X.Y`` depends on the installed Python version             |
+      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
+      | LAMMPS shared library  | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps``  | ``X.Y`` depends on the installed Python version             |
+      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
 
       If you do a full installation (CMake only) with "install", this
       leads to the following installation locations:
 
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
-      | File                   | Location                                                        | Notes                                                       |
-      +========================+=================================================================+=============================================================+
-      | LAMMPS Python Module   | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps`` (32bit)   | ``X.Y`` depends on the installed Python version             |
-      |                        | * ``$VIRTUAL_ENV/lib64/pythonX.Y/site-packages/lammps`` (64bit) |                                                             |
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
-      | LAMMPS shared library  | * ``$VIRTUAL_ENV/lib/`` (32bit)                                 | Set shared loader environment variable to this path         |
-      |                        | * ``$VIRTUAL_ENV/lib64/`` (64bit)                               | (see below for more info on this)                           |
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
-      | LAMMPS executable      | * ``$VIRTUAL_ENV/bin/``                                         |                                                             |
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
-      | LAMMPS potential files | * ``$VIRTUAL_ENV/share/lammps/potentials/``                     | Set ``LAMMPS_POTENTIALS`` environment variable to this path |
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
+      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
+      | File                   | Location                                               | Notes                                                       |
+      +========================+========================================================+=============================================================+
+      | LAMMPS Python Module   | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps``  | ``X.Y`` depends on the installed Python version             |
+      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
+      | LAMMPS shared library  | * ``$VIRTUAL_ENV/lib/`` (32bit)                        | Set shared loader environment variable to this path         |
+      |                        | * ``$VIRTUAL_ENV/lib64/`` (64bit)                      | (see below for more info on this)                           |
+      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
+      | LAMMPS executable      | * ``$VIRTUAL_ENV/bin/``                                |                                                             |
+      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
+      | LAMMPS potential files | * ``$VIRTUAL_ENV/share/lammps/potentials/``            | Set ``LAMMPS_POTENTIALS`` environment variable to this path |
+      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
 
       In that case you need to modify the ``$HOME/myenv/bin/activate``
       script in a similar fashion you need to update your

doc/src/Run_output.rst

@@ -106,7 +106,7 @@ individual ranks. Here is an example output for this section:
 ----------
 
 The third section above lists the number of owned atoms (Nlocal),
-ghost atoms (Nghost), and pair-wise neighbors stored per processor.
+ghost atoms (Nghost), and pairwise neighbors stored per processor.
 The max and min values give the spread of these values across
 processors with a 10-bin histogram showing the distribution. The total
 number of histogram counts is equal to the number of processors.
@@ -114,7 +114,7 @@ number of histogram counts is equal to the number of processors.
 ----------
 
 The last section gives aggregate statistics (across all processors)
-for pair-wise neighbors and special neighbors that LAMMPS keeps track
+for pairwise neighbors and special neighbors that LAMMPS keeps track
 of (see the :doc:`special_bonds <special_bonds>` command).  The number
 of times neighbor lists were rebuilt is tallied, as is the number of
 potentially *dangerous* rebuilds.  If atom movement triggered neighbor

doc/src/Speed_kokkos.rst

@@ -214,7 +214,7 @@ threads/task as Nt. The product of these two values should be N, i.e.
    The default for the :doc:`package kokkos <package>` command when
    running on KNL is to use "half" neighbor lists and set the Newton flag
    to "on" for both pairwise and bonded interactions. This will typically
-   be best for many-body potentials. For simpler pair-wise potentials, it
+   be best for many-body potentials. For simpler pairwise potentials, it
    may be faster to use a "full" neighbor list with Newton flag to "off".
    Use the "-pk kokkos" :doc:`command-line switch <Run_options>` to change
    the default :doc:`package kokkos <package>` options. See its page for

doc/src/Tools.rst

@@ -277,17 +277,34 @@ at ens-lyon.fr, alain.dequidt at uca.fr
 eam database tool
 -----------------------------
 
-The tools/eam_database directory contains a Fortran program that will
-generate EAM alloy setfl potential files for any combination of 16
-elements: Cu, Ag, Au, Ni, Pd, Pt, Al, Pb, Fe, Mo, Ta, W, Mg, Co, Ti,
-Zr.  The files can then be used with the :doc:`pair_style eam/alloy <pair_eam>` command.
+The tools/eam_database directory contains a Fortran and a Python program
+that will generate EAM alloy setfl potential files for any combination
+of the 17 elements: Cu, Ag, Au, Ni, Pd, Pt, Al, Pb, Fe, Mo, Ta, W, Mg,
+Co, Ti, Zr, Cr.  The files can then be used with the :doc:`pair_style
+eam/alloy <pair_eam>` command.
 
-The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov,
-and is based on his paper:
+The Fortran version of the tool was authored by Xiaowang Zhou (Sandia),
+xzhou at sandia.gov, with updates from Lucas Hale (NIST) lucas.hale at
+nist.gov and is based on his paper:
 
 X. W. Zhou, R. A. Johnson, and H. N. G. Wadley, Phys. Rev. B, 69,
 144113 (2004).
 
+The parameters for Cr were taken from:
+
+Lin Z B, Johnson R A and Zhigilei L V, Phys. Rev. B 77 214108 (2008).
+
+The Python version of the tool was authored  by Germain Clavier
+(TU Eindhoven) g.m.g.c.clavier at tue.nl or germain.clavier at gmail.com
+
+.. note::
+
+   The parameters in the database are only optimized for individual
+   elements. The mixed parameters for interactions between different
+   elements generated by this tool are derived from simple mixing rules
+   and are thus inferior to parameterizations that are specifically
+   optimized for specific mixtures and combinations of elements.
+
 ----------
 
 .. _eamgn:

doc/src/angle_class2.rst

@@ -64,34 +64,44 @@ These are the 4 coefficients for the :math:`E_a` formula:
 radians internally; hence the various :math:`K` are effectively energy
 per radian\^2 or radian\^3 or radian\^4.
 
-For the :math:`E_{bb}` formula, each line in a :doc:`angle_coeff <angle_coeff>`
-command in the input script lists 4 coefficients, the first of which
-is "bb" to indicate they are BondBond coefficients.  In a data file,
-these coefficients should be listed under a "BondBond Coeffs" heading
-and you must leave out the "bb", i.e. only list 3 coefficients after
-the angle type.
+For the :math:`E_{bb}` formula, each line in a :doc:`angle_coeff
+<angle_coeff>` command in the input script lists 4 coefficients, the
+first of which is "bb" to indicate they are BondBond coefficients.  In
+a data file, these coefficients should be listed under a "BondBond
+Coeffs" heading and you must leave out the "bb", i.e. only list 3
+coefficients after the angle type.
 
 * bb
 * :math:`M` (energy/distance\^2)
 * :math:`r_1` (distance)
 * :math:`r_2` (distance)
 
-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.
+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:`N_1` (energy/distance)
+* :math:`N_2` (energy/distance)
 * :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.
 
+.. note::
+
+   It is important that the order of the I,J,K atoms in each angle
+   listed in the Angles section of the data file read by the
+   :doc:`read_data <read_data>` command be consistent with the order
+   of the :math:`r_1` and :math:`r_2` BondBond and BondAngle
+   coefficients.  This is because the terms in the formulas for
+   :math:`E_{bb}` and :math:`E_{ba}` will use the I,J atoms to compute
+   :math:`r_{ij}` and the J,K atoms to compute :math:`r_{jk}`.
+
 ----------
 
 .. include:: accel_styles.rst

doc/src/balance.rst

@@ -383,7 +383,7 @@ multiple groups, its weight is the product of the weight factors.
 
 This weight style is useful in combination with pair style
 :doc:`hybrid <pair_hybrid>`, e.g. when combining a more costly many-body
-potential with a fast pair-wise potential.  It is also useful when
+potential with a fast pairwise potential.  It is also useful when
 using :doc:`run_style respa <run_style>` where some portions of the
 system have many bonded interactions and others none.  It assumes that
 the computational cost for each group remains constant over time.

doc/src/bond_fene.rst

@@ -1,4 +1,5 @@
 .. index:: bond_style fene
+.. index:: bond_style fene/nm
 .. index:: bond_style fene/intel
 .. index:: bond_style fene/kk
 .. index:: bond_style fene/omp
@@ -8,12 +9,16 @@ bond_style fene command
 
 Accelerator Variants: *fene/intel*, *fene/kk*, *fene/omp*
 
+bond_style fene/nm command
+==========================
+
 Syntax
 """"""
 
 .. code-block:: LAMMPS
 
    bond_style fene
+   bond_style fene/nm
 
 Examples
 """"""""
@@ -23,6 +28,9 @@ Examples
    bond_style fene
    bond_coeff 1 30.0 1.5 1.0 1.0
 
+   bond_style fene/nm
+   bond_coeff 1 2.25344 1.5 1.0 1.12246 2 6
+
 Description
 """""""""""
 
@@ -38,16 +46,36 @@ term is attractive, the second Lennard-Jones term is repulsive.  The
 first term extends to :math:`R_0`, the maximum extent of the bond.  The second
 term is cutoff at :math:`2^\frac{1}{6} \sigma`, the minimum of the LJ potential.
 
-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:
+The *fene/nm* bond style substitutes the standard LJ potential with the generalized LJ potential
+in the same form as in pair style :doc:`nm/cut <pair_nm>`. The bond energy is then given by
+
+.. math::
+
+  E = -0.5 K r_0^2  \ln \left[ 1 - \left(\frac{r}{R_0}\right)^2\right] + \frac{E_0}{(n-m)} \left[ m \left(\frac{r_0}{r}\right)^n - n \left(\frac{r_0}{r}\right)^m \right]
+
+Similar to the *fene* style, the generalized Lennard-Jones is cut off at
+the potential minimum, :math:`r_0`, to be repulsive only.  The following
+coefficients must be defined for each bond type via the :doc:`bond_coeff
+<bond_coeff>` command as in the example above, or in the data file or
+restart files read by the :doc:`read_data <read_data>` or
+:doc:`read_restart <read_restart>` commands:
 
 * :math:`K` (energy/distance\^2)
 * :math:`R_0` (distance)
 * :math:`\epsilon` (energy)
 * :math:`\sigma` (distance)
 
+For the *fene/nm* style, the following coefficients are used.  Please
+note, that the standard LJ potential and thus the regular FENE potential
+is recovered for (n=12 m=6) and :math:`r_0 = 2^\frac{1}{6} \sigma`.
+
+* :math:`K` (energy/distance\^2)
+* :math:`R_0` (distance)
+* :math:`E_0` (energy)
+* :math:`r_0` (distance)
+* :math:`n` (unitless)
+* :math:`m` (unitless)
+
 ----------
 
 .. include:: accel_styles.rst
@@ -57,9 +85,10 @@ or :doc:`read_restart <read_restart>` commands:
 Restrictions
 """"""""""""
 
-This bond style can only be used if LAMMPS was built with the MOLECULE
-package.  See the :doc:`Build package <Build_package>` page for more
-info.
+The *fene* bond style can only be used if LAMMPS was built with the MOLECULE
+package; the *fene/nm* bond style can only be used if LAMMPS was built
+with the EXTRA-MOLECULE package. See the :doc:`Build package <Build_package>`
+page for more info.
 
 You typically should specify :doc:`special_bonds fene <special_bonds>`
 or :doc:`special_bonds lj/coul 0 1 1 <special_bonds>` to use this bond
@@ -68,7 +97,8 @@ style.  LAMMPS will issue a warning it that's not the case.
 Related commands
 """"""""""""""""
 
-:doc:`bond_coeff <bond_coeff>`, :doc:`delete_bonds <delete_bonds>`
+:doc:`bond_coeff <bond_coeff>`, :doc:`delete_bonds <delete_bonds>`,
+:doc:`pair style lj/cut <pair_lj>`, :doc:`pair style nm/cut <pair_nm>`.
 
 Default
 """""""

doc/src/bond_style.rst

@@ -87,6 +87,7 @@ accelerated styles exist.
 * :doc:`class2 <bond_class2>` - COMPASS (class 2) bond
 * :doc:`fene <bond_fene>` - FENE (finite-extensible non-linear elastic) bond
 * :doc:`fene/expand <bond_fene_expand>` - FENE bonds with variable size particles
+* :doc:`fene/nm <bond_fene>` - FENE bonds with a generalized Lennard-Jones potential
 * :doc:`gaussian <bond_gaussian>` - multicentered Gaussian-based bond potential
 * :doc:`gromos <bond_gromos>` - GROMOS force field bond
 * :doc:`harmonic <bond_harmonic>` - harmonic bond

doc/src/compute.rst

@@ -174,6 +174,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`angle <compute_angle>` - energy of each angle sub-style
 * :doc:`angle/local <compute_angle_local>` - theta and energy of each angle
 * :doc:`angmom/chunk <compute_angmom_chunk>` - angular momentum for each chunk
+* :doc:`ave/sphere/atom <compute_ave_sphere_atom>` - compute local density and temperature around each atom
 * :doc:`basal/atom <compute_basal_atom>` - calculates the hexagonal close-packed "c" lattice vector of each atom
 * :doc:`body/local <compute_body_local>` - attributes of body sub-particles
 * :doc:`bond <compute_bond>` - energy of each bond sub-style
@@ -245,7 +246,6 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`pe/tally <compute_tally>` - potential energy between two groups of atoms via the tally callback mechanism
 * :doc:`plasticity/atom <compute_plasticity_atom>` - Peridynamic plasticity for each atom
 * :doc:`pressure <compute_pressure>` - total pressure and pressure tensor
-* :doc:`pressure/cylinder <compute_pressure_cylinder>` - pressure tensor in cylindrical coordinates
 * :doc:`pressure/uef <compute_pressure_uef>` - pressure tensor in the reference frame of an applied flow field
 * :doc:`property/atom <compute_property_atom>` - convert atom attributes to per-atom vectors/arrays
 * :doc:`property/chunk <compute_property_chunk>` - extract various per-chunk attributes
@@ -288,8 +288,11 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`sph/t/atom <compute_sph_t_atom>` - per-atom internal temperature of Smooth-Particle Hydrodynamics atoms
 * :doc:`spin <compute_spin>` - magnetic quantities for a system of atoms having spins
 * :doc:`stress/atom <compute_stress_atom>` - stress tensor for each atom
+* :doc:`stress/cartesian <compute_stress_profile>` - stress tensor in cartesian coordinates
+* :doc:`stress/cylinder <compute_stress_profile>` - stress tensor in cylindrical coordinates
 * :doc:`stress/mop <compute_stress_mop>` - normal components of the local stress tensor using the method of planes
 * :doc:`stress/mop/profile <compute_stress_mop>` - profile of the normal components of the local stress tensor using the method of planes
+* :doc:`stress/spherical <compute_stress_profile>` - stress tensor in spherical coordinates
 * :doc:`stress/tally <compute_tally>` - stress between two groups of atoms via the tally callback mechanism
 * :doc:`tdpd/cc/atom <compute_tdpd_cc_atom>` - per-atom chemical concentration of a specified species for each tDPD particle
 * :doc:`temp <compute_temp>` - temperature of group of atoms

doc/src/compute_ave_sphere_atom.rst

@@ -0,0 +1,101 @@
+.. index:: compute ave/sphere/atom
+.. index:: compute ave/sphere/atom/kk
+
+compute ave/sphere/atom command
+================================
+
+Accelerator Variants: *ave/sphere/atom/kk*
+
+Syntax
+""""""
+
+.. parsed-literal::
+
+   compute ID group-ID ave/sphere/atom keyword values ...
+
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* ave/sphere/atom = style name of this compute command
+* one or more keyword/value pairs may be appended
+
+  .. parsed-literal::
+
+     keyword = *cutoff*
+       *cutoff* value = distance cutoff
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   compute 1 all ave/sphere/atom
+
+   compute 1 all ave/sphere/atom cutoff 5.0
+   comm_modify cutoff 5.0
+
+Description
+"""""""""""
+
+Define a computation that calculates the local density and temperature
+for each atom and neighbors inside a spherical cutoff.
+
+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
+is dumped).  Thus it can be inefficient to compute/dump this quantity
+too frequently.
+
+.. note::
+
+   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.
+
+----------
+
+
+.. include:: accel_styles.rst
+
+
+----------
+
+Output info
+"""""""""""
+
+This compute calculates a per-atom array with two columns: density and temperature.
+
+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.
+
+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.
+
+Related commands
+""""""""""""""""
+
+:doc:`comm_modify <comm_modify>`
+
+Default
+"""""""
+
+The option defaults are *cutoff* = pair style cutoff
+

doc/src/compute_bond_local.rst

@@ -13,7 +13,7 @@ Syntax
 * ID, group-ID are documented in :doc:`compute <compute>` command
 * bond/local = style name of this compute command
 * one or more values may be appended
-* value = *dist* or *engpot* or *force* or *fx* or *fy* or *fz* or *engvib* or *engrot* or *engtrans* or *omega* or *velvib* or *v_name*
+* value = *dist* or *dx* or *dy* or *dz* or *engpot* or *force* or *fx* or *fy* or *fz* or *engvib* or *engrot* or *engtrans* or *omega* or *velvib* or *v_name*
 
 .. parsed-literal::
 
@@ -21,6 +21,7 @@ Syntax
      *engpot* = bond potential energy
      *force* = bond force
 
+     *dx*,\ *dy*,\ *dz* = components of pairwise distance
      *fx*,\ *fy*,\ *fz* = components of bond force
      *engvib* = bond kinetic energy of vibration
      *engrot* = bond kinetic energy of rotation
@@ -63,6 +64,9 @@ whether the 2 atoms represent a simple diatomic molecule, or are part
 of some larger molecule.
 
 The value *dist* is the current length of the bond.
+The values *dx*, *dy*, and *dz* are the xyz components of the
+*distance* between the pair of atoms. This value is always the
+distance from the atom of lower to the one with the higher id.
 
 The value *engpot* is the potential energy for the bond,
 based on the current separation of the pair of atoms in the bond.

doc/src/compute_heat_flux.rst

@@ -89,13 +89,20 @@ included in the calculation.
 .. warning::
 
    The compute *heat/flux* has been reported to produce unphysical
-   values for angle, dihedral and improper contributions
+   values for angle, dihedral, improper and constraint force contributions
    when used with :doc:`compute stress/atom <compute_stress_atom>`,
-   as discussed in :ref:`(Surblys) <Surblys2>` and :ref:`(Boone) <Boone>`.
-   You are strongly advised to
+   as discussed in :ref:`(Surblys2019) <Surblys3>`, :ref:`(Boone) <Boone>`
+   and :ref:`(Surblys2021) <Surblys4>`. You are strongly advised to
    use :doc:`compute centroid/stress/atom <compute_stress_atom>`,
    which has been implemented specifically for such cases.
 
+.. warning::
+
+   Due to an implementation detail, the :math:`y` and :math:`z`
+   components of heat flux from :doc:`fix rigid <fix_rigid>`
+   contribution when computed via :doc:`compute stress/atom <compute_stress_atom>`
+   are highly unphysical and should not be used.
+
 The Green-Kubo formulas relate the ensemble average of the
 auto-correlation of the heat flux :math:`\mathbf{J}`
 to the thermal conductivity :math:`\kappa`:
@@ -232,10 +239,14 @@ none
 
 ----------
 
-.. _Surblys2:
+.. _Surblys3:
 
-**(Surblys)** Surblys, Matsubara, Kikugawa, Ohara, Phys Rev E, 99, 051301(R) (2019).
+**(Surblys2019)** Surblys, Matsubara, Kikugawa, Ohara, Phys Rev E, 99, 051301(R) (2019).
 
 .. _Boone:
 
 **(Boone)** Boone, Babaei, Wilmer, J Chem Theory Comput, 15, 5579--5587 (2019).
+
+.. _Surblys4:
+
+**(Surblys2021)** Surblys, Matsubara, Kikugawa, Ohara, J Appl Phys 130, 215104 (2021).

doc/src/compute_momentum.rst

@@ -23,11 +23,10 @@ Examples
 Description
 """""""""""
 
-Define a computation that calculates the translational momentum
-of a group of particles.
-
-The momentum of each particles is computed as m v, where m and v are
-the mass and velocity of the particle.
+Define a computation that calculates the translational momentum *p*
+of a group of particles.  It is computed as the sum :math:`\vec{p} = \sum_i m_i \cdot \vec{v}_i`
+over all particles in the compute group, where *m* and *v* are
+the mass and velocity vector of the particle, respectively.
 
 Output info
 """""""""""

doc/src/compute_pair_local.rst

@@ -13,11 +13,12 @@ Syntax
 * ID, group-ID are documented in :doc:`compute <compute>` command
 * pair/local = style name of this compute command
 * one or more values may be appended
-* value = *dist* or *eng* or *force* or *fx* or *fy* or *fz* or *pN*
+* value = *dist* or *dx* or *dy* or *dz* or *eng* or *force* or *fx* or *fy* or *fz* or *pN*
 
   .. parsed-literal::
 
        *dist* = pairwise distance
+       *dx*,\ *dy*,\ *dz* = components of pairwise distance
        *eng* = pairwise energy
        *force* = pairwise force
        *fx*,\ *fy*,\ *fz* = components of pairwise force
@@ -56,6 +57,9 @@ force cutoff distance for that interaction, as defined by the
 commands.
 
 The value *dist* is the distance between the pair of atoms.
+The values *dx*, *dy*, and *dz* are the xyz components of the
+*distance* between the pair of atoms. This value is always the
+distance from the atom of lower to the one with the higher id.
 
 The value *eng* is the interaction energy for the pair of atoms.
 
@@ -89,10 +93,10 @@ from the second of the two sub-styles.  If the referenced *pN*
 is not computed for the specific pairwise interaction (based on
 atom types), then the output will be 0.0.
 
-The value *dist* will be in distance :doc:`units <units>`.  The value
-*eng* will be in energy :doc:`units <units>`.  The values *force*, *fx*,
-*fy*, and *fz* will be in force :doc:`units <units>`.  The values *pN*
-will be in whatever units the pair style defines.
+The value *dist*, *dx*, *dy* and *dz* will be in distance :doc:`units <units>`.
+The value *eng* will be in energy :doc:`units <units>`.
+The values *force*, *fx*, *fy*, and *fz* will be in force :doc:`units <units>`.
+The values *pN* will be in whatever units the pair style defines.
 
 The optional *cutoff* keyword determines how the force cutoff distance
 for an interaction is determined.  For the default setting of *type*,

doc/src/compute_pressure.rst

@@ -141,7 +141,7 @@ Related commands
 """"""""""""""""
 
 :doc:`compute temp <compute_temp>`, :doc:`compute stress/atom <compute_stress_atom>`,
-:doc:`thermo_style <thermo_style>`,
+:doc:`thermo_style <thermo_style>`, :doc:`fix numdiff/virial <fix_numdiff_virial>`,
 
 Default
 """""""

doc/src/compute_pressure_cylinder.rst

@@ -1,88 +0,0 @@
-.. index:: compute pressure/cylinder
-
-compute pressure/cylinder command
-=================================
-
-Syntax
-""""""
-
-.. parsed-literal::
-
-   compute ID group-ID pressure/cylinder zlo zhi Rmax bin_width
-
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* pressure/cylinder = style name of this compute command
-* zlo = minimum z-boundary for cylinder
-* zhi = maximum z-boundary for cylinder
-* Rmax = maximum radius to perform calculation to
-* bin_width = width of radial bins to use for calculation
-
-Examples
-""""""""
-
-.. code-block:: LAMMPS
-
-   compute 1 all pressure/cylinder -10.0 10.0 15.0 0.25
-
-Description
-"""""""""""
-
-Define a computation that calculates the pressure tensor of a system in
-cylindrical coordinates, as discussed in :ref:`(Addington) <Addington1>`.
-This is useful for systems with a single axis of rotational symmetry,
-such as cylindrical micelles or carbon nanotubes. The compute splits the
-system into radial, cylindrical-shell-type bins of width bin_width,
-centered at x=0,y=0, and calculates the radial (P_rhorho), azimuthal
-(P_phiphi), and axial (P_zz) components of the configurational pressure
-tensor. The local density is also calculated for each bin, so that the
-true pressure can be recovered as P_kin+P_conf=density\*k\*T+P_conf.  The
-output is a global array with 5 columns; one each for bin radius, local
-number density, P_rhorho, P_phiphi, and P_zz. The number of rows is
-governed by the values of Rmax and bin_width. Pressure tensor values are
-output in pressure units.
-
-Output info
-"""""""""""
-
-This compute calculates a global array with 5 columns and Rmax/bin_width
-rows. The output columns are: R (distance units), number density (inverse
-volume units), configurational radial pressure (pressure units),
-configurational azimuthal pressure (pressure units), and configurational
-axial pressure (pressure units).
-
-The values calculated by this compute are
-"intensive".  The pressure values will be in pressure
-:doc:`units <units>`. The number density values will be in
-inverse volume :doc:`units <units>`.
-
-Restrictions
-""""""""""""
-
-This compute currently calculates the pressure tensor contributions
-for pair styles only (i.e. no bond, angle, dihedral, etc. contributions
-and in the presence of bonded interactions, the result will be incorrect
-due to exclusions for special bonds)  and requires pair-wise force
-calculations not available for most many-body pair styles. K-space
-calculations are also excluded. Note that this pressure compute outputs
-the configurational terms only; the kinetic contribution is not included
-and may be calculated from the number density output by P_kin=density\*k\*T.
-
-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
-""""""""""""""""
-
-:doc:`compute temp <compute_temp>`, :doc:`compute stress/atom <compute_stress_atom>`,
-:doc:`thermo_style <thermo_style>`,
-
-Default
-"""""""
-
-none
-
-----------
-
-.. _Addington1:
-
-**(Addington)** Addington, Long, Gubbins, J Chem Phys, 149, 084109 (2018).

doc/src/compute_sna_atom.rst

@@ -33,7 +33,7 @@ Syntax
 * R_1, R_2,... = list of cutoff radii, one for each type (distance units)
 * w_1, w_2,... = list of neighbor weights, one for each type
 * zero or more keyword/value pairs may be appended
-* keyword = *rmin0* or *switchflag* or *bzeroflag* or *quadraticflag* or *chem* or *bnormflag* or *wselfallflag*
+* keyword = *rmin0* or *switchflag* or *bzeroflag* or *quadraticflag* or *chem* or *bnormflag* or *wselfallflag* or *bikflag* or *switchinnerflag*
 
   .. parsed-literal::
 
@@ -56,6 +56,12 @@ Syntax
        *wselfallflag* value = *0* or *1*
           *0* = self-contribution only for element of central atom
           *1* = self-contribution for all elements
+       *bikflag* value = *0* or *1* (only implemented for compute snap)
+          *0* = per-atom bispectrum descriptors are summed over atoms
+          *1* = per-atom bispectrum descriptors are not summed over atoms
+       *switchinnerflag* values = *rinnerlist* *drinnerlist*
+          *rinnerlist* = *ntypes* values of rinner (distance units)
+          *drinnerlist* = *ntypes* values of drinner (distance units)
 
 Examples
 """"""""
@@ -67,6 +73,7 @@ Examples
    compute vb all sna/atom 1.4 0.95 6 2.0 1.0
    compute snap all snap 1.4 0.95 6 2.0 1.0
    compute snap all snap 1.0 0.99363 6 3.81 3.83 1.0 0.93 chem 2 0 1
+   compute snap all snap 1.0 0.99363 6 3.81 3.83 1.0 0.93 switchinnerflag 1.1 1.3 0.5 0.6
 
 Description
 """""""""""
@@ -296,6 +303,35 @@ This option is typically used in conjunction with the *chem* keyword,
 and LAMMPS will generate a warning if both *chem* and *bnormflag*
 are not both set or not both unset.
 
+The keyword *bikflag* determines whether or not to expand the bispectrum
+rows of the global array returned by compute snap. If *bikflag* is set
+to *1* then the bispectrum row, which is typically the per-atom bispectrum
+descriptors :math:`B_{i,k}` summed over all atoms *i* to produce
+:math:`B_k`, becomes bispectrum rows equal to the number of atoms. Thus,
+the resulting bispectrum rows are :math:`B_{i,k}` instead of just
+:math:`B_k`. In this case, the entries in the final column for these rows
+are set to zero.
+
+The keyword *switchinnerflag* activates an additional radial switching
+function similar to :math:`f_c(r)` above, but acting to switch off
+smoothly contributions from neighbor atoms at short separation distances.
+This is useful when SNAP is used in combination with a simple
+repulsive potential. The keyword is followed by the *ntypes*
+values for :math:`r_{inner}` and the *ntypes*
+values for :math:`\Delta r_{inner}`. For a neighbor atom at
+distance :math:`r`, its contribution is scaled by a multiplicative
+factor :math:`f_{inner}(r)` defined as follows:
+
+.. math::
+
+               = & 0,  r \leq r_{inner} \\
+  f_{inner}(r) = & \frac{1}{2}(1 - \cos(\pi \frac{r-r_{inner}}{\Delta r_{inner}})), r_{inner} < r \leq r_{inner} + \Delta r_{inner} \\
+               = & 1,  r > r_{inner} + \Delta r_{inner}
+
+The values of :math:`r_{inner}` and :math:`\Delta r_{inner}` are
+the arithmetic means of the values for the central atom of type I
+and the neighbor atom of type J.
+
 .. note::
 
    If you have a bonded system, then the settings of :doc:`special_bonds

doc/src/compute_stress_atom.rst

@@ -87,6 +87,10 @@ Tersoff 3-body interaction) is assigned in equal portions to each atom
 in the set.  E.g. 1/4 of the dihedral virial to each of the 4 atoms,
 or 1/3 of the fix virial due to SHAKE constraints applied to atoms in
 a water molecule via the :doc:`fix shake <fix_shake>` command.
+As an exception, the virial contribution from
+constraint forces in :doc:`fix rigid <fix_rigid>` on each atom
+is computed from the constraint force acting on the corresponding atom
+and its position, i.e. the total virial is not equally distributed.
 
 In case of compute *centroid/stress/atom*, the virial contribution is:
 
@@ -103,13 +107,25 @@ atom :math:`I` due to the interaction and the relative position
 :math:`\mathbf{r}_{I0}` of the atom :math:`I` to the geometric center
 of the interacting atoms, i.e. centroid, is used.  As the geometric
 center is different for each interaction, the :math:`\mathbf{r}_{I0}`
-also differs.  The sixth and seventh terms, Kspace and :doc:`fix
-<fix>` contribution respectively, are computed identical to compute
-*stress/atom*.  Although the total system virial is the same as
+also differs. The sixth term, Kspace contribution,
+is computed identically to compute *stress/atom*.
+The seventh term is handed differently depending on
+if the constraint forces are due to :doc:`fix shake <fix_shake>`
+or :doc:`fix rigid <fix_rigid>`.
+In case of SHAKE constraints, each distance constraint is
+handed as a pairwise interaction.
+E.g. in case of a water molecule, two OH and one HH distance
+constraints are treated as three pairwise interactions.
+In case of :doc:`fix rigid <fix_rigid>`,
+all constraint forces in the molecule are treated
+as a single many-body interaction with a single centroid position.
+In case of water molecule, the formula expression would become
+identical to that of the three-body angle interaction.
+Although the total system virial is the same as
 compute *stress/atom*, compute *centroid/stress/atom* is know to
-result in more consistent heat flux values for angle, dihedrals and
-improper contributions when computed via :doc:`compute heat/flux
-<compute_heat_flux>`.
+result in more consistent heat flux values for angle, dihedrals,
+improper and constraint force contributions
+when computed via :doc:`compute heat/flux <compute_heat_flux>`.
 
 If no extra keywords are listed, the kinetic contribution all of the
 virial contribution terms are included in the per-atom stress tensor.
@@ -134,7 +150,8 @@ contribution for the cluster interaction is divided evenly among those
 atoms.
 
 Details of how compute *centroid/stress/atom* obtains the virial for
-individual atoms is given in :ref:`(Surblys) <Surblys1>`, where the
+individual atoms are given in :ref:`(Surblys2019) <Surblys1>` and
+:ref:`(Surblys2021) <Surblys2>`, where the
 idea is that the virial of the atom :math:`I` is the result of only
 the force :math:`\mathbf{F}_I` on the atom due to the interaction and
 its positional vector :math:`\mathbf{r}_{I0}`, relative to the
@@ -235,10 +252,10 @@ between the pair of particles.  All bond styles are supported.  All
 angle, dihedral, improper styles are supported with the exception of
 INTEL and KOKKOS variants of specific styles.  It also does not
 support models with long-range Coulombic or dispersion forces,
-i.e. the kspace_style command in LAMMPS.  It also does not support the
-following fixes which add rigid-body constraints: :doc:`fix shake
-<fix_shake>`, :doc:`fix rattle <fix_shake>`, :doc:`fix rigid
-<fix_rigid>`, :doc:`fix rigid/small <fix_rigid>`.
+i.e. the kspace_style command in LAMMPS.  It also does not implement the
+following fixes which add rigid-body constraints:
+:doc:`fix rigid/* <fix_rigid>` and the OpenMP accelerated version of :doc:`fix rigid/small <fix_rigid>`,
+while all other :doc:`fix rigid/*/small <fix_rigid>` are implemented.
 
 LAMMPS will generate an error if one of these options is included in
 your model.  Extension of centroid stress calculations to these force
@@ -270,4 +287,8 @@ none
 
 .. _Surblys1:
 
-**(Surblys)** Surblys, Matsubara, Kikugawa, Ohara, Phys Rev E, 99, 051301(R) (2019).
+**(Surblys2019)** Surblys, Matsubara, Kikugawa, Ohara, Phys Rev E, 99, 051301(R) (2019).
+
+.. _Surblys2:
+
+**(Surblys2021)** Surblys, Matsubara, Kikugawa, Ohara, J Appl Phys 130, 215104 (2021).

doc/src/compute_stress_mop.rst

@@ -68,7 +68,19 @@ configurational stress (conf), and/or total stress (total).
 NOTE 1: The configurational stress is computed considering all pairs of atoms where at least one atom belongs to group group-ID.
 
 NOTE 2: The local stress does not include any Lennard-Jones tail
-corrections to the pressure added by the :doc:`pair_modify tail yes <pair_modify>` command, since those are contributions to the global system pressure.
+corrections to the stress added by the :doc:`pair_modify tail yes <pair_modify>`
+command, since those are contributions to the global system pressure.
+
+NOTE 3: The local stress profile generated by compute *stress/mop/profile*
+is similar to that obtained by compute
+:doc:`stress/cartesian <compute_stress_profile>`.
+A key difference
+is that compute *stress/mop/profile* considers particles
+crossing a set of planes,
+while compute *stress/cartesian* computes averages for a set of
+small volumes.  More information
+on the similarities and differences can be found in
+:ref:`(Ikeshoji)<Ikeshoji2>`.
 
 Output info
 """""""""""
@@ -87,7 +99,10 @@ and stress_dir,z.
 
 The values are in pressure :doc:`units <units>`.
 
-The values produced by this compute can be accessed by various :doc:`output commands <Howto_output>`. For instance, the results can be written to a file using the :doc:`fix ave/time <fix_ave_time>` command. Please see the example in the examples/PACKAGES/mop folder.
+The values produced by this compute can be accessed by various :doc:`output commands <Howto_output>`.
+For instance, the results can be written to a file using the
+:doc:`fix ave/time <fix_ave_time>` command. Please see the example
+in the examples/PACKAGES/mop folder.
 
 Restrictions
 """"""""""""
@@ -107,7 +122,7 @@ intra-molecular interactions, and long range (kspace) interactions.
 Related commands
 """"""""""""""""
 
-:doc:`compute stress/atom <compute_stress_atom>`
+:doc:`compute stress/atom <compute_stress_atom>`, :doc:`compute pressure <compute_pressure>`, :doc:`compute stress/cartesian <compute_stress_profile>`, :doc:`compute stress/cylinder <compute_stress_profile>`, :doc:`compute stress/spherical <compute_stress_profile>`
 
 Default
 """""""
@@ -120,3 +135,7 @@ none
 
 **(Todd)** B. D. Todd, Denis J. Evans, and Peter J. Daivis: "Pressure tensor for inhomogeneous fluids",
 Phys. Rev. E 52, 1627 (1995).
+
+.. _Ikeshoji3:
+
+**(Ikeshoji)** Ikeshoji, Hafskjold, Furuholt, Mol Sim, 29, 101-109, (2003).

doc/src/compute_stress_profile.rst

@@ -0,0 +1,165 @@
+.. index:: compute stress/cartesian
+.. index:: compute stress/cylinder
+.. index:: compute stress/spherical
+
+
+compute stress/cartesian command
+==================================
+
+compute stress/cylinder command
+=================================
+
+compute stress/spherical command
+==================================
+
+Syntax
+""""""
+
+.. parsed-literal::
+
+   compute ID group-ID style args
+
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* style = stress/cartesian or stress/spherical or stress/cylinder
+* args = argument specific to the compute style
+
+.. parsed-literal::
+
+  *stress/cartesian* args = dim bin_width
+    dim = x, y, or z. One or two dim/bin_width pairs may be appended
+    bin_width = width of the bin
+  *stress/cylinder* args = zlo zh Rmax bin_width keyword
+    zlo = minimum z-boundary for cylinder
+    zhi = maximum z-boundary for cylinder
+    Rmax = maximum radius to perform calculation to
+    bin_width = width of radial bins to use for calculation
+    keyword = ke (zero or one can be specified)
+      ke = yes or no
+  *stress/spherical*
+    x0, y0, z0 = origin of the spherical coordinate system
+    bin_width = width of spherical shells
+    Rmax = maximum radius of spherical shells
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   compute 1 all stress/cartesian x 0.1
+   compute 1 all stress/cartesian y 0.25 z 0.1
+   compute 1 all stress/cylinder -10.0 10.0 15.0 0.25
+   compute 1 all stress/cylinder -10.0 10.0 15.0 0.25 ke no
+   compute 1 all stress/spherical 0 0 0 0.1 10
+
+Description
+"""""""""""
+
+Compute *stress/cartesian*, compute *stress/cylinder*, and compute
+*stress/spherical* define computations that calculate profiles of the
+diagonal components of the local stress tensor in the specified
+coordinate system. The stress tensor is split into a kinetic
+contribution :math:`P^k` and a virial contribution :math:`P^v`. The sum
+gives the total stress tensor :math:`P = P^k+P^v`. These computes can
+for example be used to calculate the diagonal components of the local
+stress tensor of interfaces with flat, cylindrical, or spherical
+symmetry. These computes obeys momentum balance through fluid
+interfaces. They use the Irving-Kirkwood contour, which is the straight
+line between particle pairs.
+
+The *stress/cartesian* computes the stress profile along one or two
+Cartesian coordinates, as described in :ref:`(Ikeshoji)<Ikeshoji2>`. The
+compute *stress/cylinder* computes the stress profile along the
+radial direction in cylindrical coordinates, as described in
+:ref:`(Addington)<Addington1>`. The compute *stress/spherical*
+computes the stress profile along the radial direction in spherical
+coordinates, as described in :ref:`(Ikeshoji)<Ikeshoji2>`.
+
+
+Output info
+"""""""""""
+
+The output columns for *stress/cartesian* are the position of the
+center of the local volume in the first and second dimensions, number
+density, :math:`P^k_{xx}`, :math:`P^k_{yy}`, :math:`P^k_{zz}`,
+:math:`P^v_{xx}`, :math:`P^v_{yy}`, and :math:`P^v_{zz}`. There are 8
+columns when one dimension is specified and 9 columns when two
+dimensions are specified. The number of bins/rows are
+(L1/bin_width1)*(L2/bin_width2), L1 and L2 are the sizes of the
+simulation box in the specified dimensions, and bin_width1 and
+bin_width2 are the specified bin widths. When only one dimension is
+specified the number of bins/rows are L1/bin_width.
+
+The default output columns for *stress/cylinder* are the radius to the
+center of the cylindrical shell, number density, :math:`P^k_{rr}`,
+:math:`P^k_{\phi\phi}`, :math:`P^k_{zz}`, :math:`P^v_{rr}`,
+:math:`P^v_{\phi\phi}`, and :math:`P^v_{zz}`. When the keyword *ke* is
+set to no, the kinetic contributions are not calculated, and
+consequently there are only 5 columns the radius to the center of the
+cylindrical shell, number density, :math:`P^v_{rr}`,
+:math:`P^v_{\phi\phi}`, :math:`P^v_{zz}`. The number of bins/rows are
+Rmax/bin_width.
+
+The output columns for *stress/spherical* are the radius to the center
+of the spherical shell, number density, :math:`P^k_{rr}`,
+:math:`P^k_{\theta\theta}`, :math:`P^k_{\phi\phi}`, :math:`P^v_{rr}`,
+:math:`P^v_{\theta\theta}`, and :math:`P^v_{\phi\phi}`. There are 8
+columns and the number of bins/rows are Rmax/bin_width.
+
+This array can be output with :doc:`fix ave/time <fix_ave_time>`,
+
+.. code-block:: LAMMPS
+
+  compute p all stress/cartesian x 0.1
+  fix 2 all ave/time 100 1 100 c_p[*] file dump_p.out mode vector
+
+The values calculated by this compute are "intensive".  The stress
+values will be in pressure :doc:`units <units>`. The number density
+values are in inverse volume :doc:`units <units>`.
+
+NOTE 1: The local stress does not include any Lennard-Jones tail
+corrections to the stress added by the :doc:`pair_modify tail yes <pair_modify>`
+command, since those are contributions to the global system pressure.
+
+NOTE 2: The local stress profiles generated by these computes are
+similar to those obtained by the
+:doc:`method-of-planes (MOP) <compute_stress_mop>`.
+A key difference
+is that compute `stress/mop/profile <compute_stress_mop>`
+considers particles crossing a set of planes, while
+*stress/cartesian* computes averages for a set of small volumes.
+More information on the similarities and differences can be found in
+:ref:`(Ikeshoji)<Ikeshoji2>`.
+
+Restrictions
+""""""""""""
+
+These computes calculate the stress tensor contributions for pair
+styles only (i.e. no bond, angle, dihedral, etc. contributions, and in
+the presence of bonded interactions, the result will be incorrect due to
+exclusions for special bonds) and requires pairwise force calculations
+not available for most many-body pair styles. K-space calculations are
+also excluded.
+
+These computes are part of the EXTRA-COMPUTE package.  They are only
+enabled if LAMMPS was built with that package.  See the :doc:`Build
+package <Build_package>` doc page for more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`compute stress/atom <compute_stress_atom>`, :doc:`compute pressure <compute_pressure>`, :doc:`compute stress/mop/profile <compute_stress_mop>`
+
+Default
+"""""""
+
+The keyword default for ke in style *stress/cylinder* is yes.
+
+----------
+
+.. _Ikeshoji2:
+
+**(Ikeshoji)** Ikeshoji, Hafskjold, Furuholt, Mol Sim, 29, 101-109, (2003).
+
+.. _Addington1:
+
+**(Addington)** Addington, Long, Gubbins, J Chem Phys, 149, 084109 (2018).

doc/src/compute_tally.rst

@@ -31,7 +31,7 @@ Syntax
    compute ID group-ID style group2-ID
 
 * ID, group-ID are documented in :doc:`compute <compute>` command
-* style = *force/tally* or *heat/flux/tally* or *heat/flux/virial/tally* or * or *pe/tally* or *pe/mol/tally* or *stress/tally*
+* style = *force/tally* or *heat/flux/tally* or *heat/flux/virial/tally* or *pe/tally* or *pe/mol/tally* or *stress/tally*
 * group2-ID = group ID of second (or same) group
 
 Examples
@@ -61,7 +61,7 @@ mechanism. Compute *pe/mol/tally* is one such style, that can
 - through using this mechanism - separately tally intermolecular
 and intramolecular energies. Something that would otherwise be
 impossible without integrating this as a core functionality into
-the based classes of LAMMPS.
+the base classes of LAMMPS.
 
 ----------
 
@@ -148,30 +148,38 @@ pairwise property computations.
 Output info
 """""""""""
 
-Compute *pe/tally* calculates a global scalar (the energy) and a per
-atom scalar (the contributions of the single atom to the global
-scalar). Compute *pe/mol/tally* calculates a global 4-element vector
-containing (in this order): *evdwl* and *ecoul* for intramolecular pairs
-and *evdwl* and *ecoul* for intermolecular pairs. Since molecules are
-identified by their molecule IDs, the partitioning does not have to be
-related to molecules, but the energies are tallied into the respective
-slots depending on whether the molecule IDs of a pair are the same or
-different. Compute *force/tally* calculates a global scalar (the force
-magnitude) and a per atom 3-element vector (force contribution from
-each atom).  Compute *stress/tally* calculates a global scalar
-(average of the diagonal elements of the stress tensor) and a per atom
-vector (the 6 elements of stress tensor contributions from the
-individual atom). As in :doc:`compute heat/flux <compute_heat_flux>`,
-compute *heat/flux/tally* calculates a global vector of length 6,
-where the first 3 components are the :math:`x`, :math:`y`, :math:`z`
-components of the full heat flow vector,
-and the next 3 components are the corresponding components
-of just the convective portion of the flow, i.e. the
-first term in the equation for :math:`\mathbf{Q}`.
-Compute *heat/flux/virial/tally* calculates a global scalar (heat flow)
-and a per atom 3-element vector
-(contribution to the force acting over atoms in the first group
-from individual atoms in both groups).
+- Compute *pe/tally* calculates a global scalar (the energy) and a per
+  atom scalar (the contributions of the single atom to the global
+  scalar).
+
+- Compute *pe/mol/tally* calculates a global 4-element vector containing
+  (in this order): *evdwl* and *ecoul* for intramolecular pairs and
+  *evdwl* and *ecoul* for intermolecular pairs. Since molecules are
+  identified by their molecule IDs, the partitioning does not have to be
+  related to molecules, but the energies are tallied into the respective
+  slots depending on whether the molecule IDs of a pair are the same or
+  different.
+
+- Compute *force/tally* calculates a global scalar (the force magnitude)
+  and a per atom 3-element vector (force contribution from each atom).
+
+- Compute *stress/tally* calculates a global scalar
+  (average of the diagonal elements of the stress tensor) and a per atom
+  vector (the 6 elements of stress tensor contributions from the
+  individual atom).
+
+- As in :doc:`compute heat/flux <compute_heat_flux>`,
+  compute *heat/flux/tally* calculates a global vector of length 6,
+  where the first 3 components are the :math:`x`, :math:`y`, :math:`z`
+  components of the full heat flow vector,
+  and the next 3 components are the corresponding components
+  of just the convective portion of the flow, i.e. the
+  first term in the equation for :math:`\mathbf{Q}`.
+
+- Compute *heat/flux/virial/tally* calculates a global scalar (heat flow)
+  and a per atom 3-element vector
+  (contribution to the force acting over atoms in the first group
+  from individual atoms in both groups).
 
 Both the scalar and vector values calculated by this compute are
 "extensive".

doc/src/delete_atoms.rst

@@ -20,8 +20,10 @@ Syntax
          cutoff = delete one atom from pairs of atoms within the cutoff (distance units)
          group1-ID = one atom in pair must be in this group
          group2-ID = other atom in pair must be in this group
-       *porosity* args = region-ID fraction seed
+       *porosity* args = group-ID region-ID fraction seed
+         group-ID = group within which to perform deletions
          region-ID = region within which to perform deletions
+                     or NULL to only impose the group criterion
          fraction = delete this fraction of atoms
          seed = random number seed (positive integer)
 
@@ -43,7 +45,8 @@ Examples
    delete_atoms region sphere compress no
    delete_atoms overlap 0.3 all all
    delete_atoms overlap 0.5 solvent colloid
-   delete_atoms porosity cube 0.1 482793 bond yes
+   delete_atoms porosity all cube 0.1 482793 bond yes
+   delete_atoms porosity polymer cube 0.1 482793 bond yes
 
 Description
 """""""""""
@@ -76,12 +79,17 @@ have occurred that no atom pairs within the cutoff will remain
 minimum number of atoms will be deleted, or that the same atoms will
 be deleted when running on different numbers of processors.
 
-For style *porosity* a specified *fraction* of atoms are deleted
-within the specified region.  For example, if fraction is 0.1, then
-10% of the atoms will be deleted.  The atoms to delete are chosen
-randomly.  There is no guarantee that the exact fraction of atoms will
-be deleted, or that the same atoms will be deleted when running on
-different numbers of processors.
+For style *porosity* a specified *fraction* of atoms are deleted which
+are both in the specified group and within the specified region.  The
+region-ID can be specified as NULL to only impose the group criterion.
+Likewise, specifying the group-ID as *all* will only impose the region
+criterion.
+
+For example, if fraction is 0.1, then 10% of the eligible atoms will
+be deleted.  The atoms to delete are chosen randomly.  There is no
+guarantee that the exact fraction of atoms will be deleted, or that
+the same atoms will be deleted when running on different numbers of
+processors.
 
 If the *compress* keyword is set to *yes*, then after atoms are
 deleted, then atom IDs are re-assigned so that they run from 1 to the
@@ -89,8 +97,8 @@ number of atoms in the system.  Note that this is not done for
 molecular systems (see the :doc:`atom_style <atom_style>` command),
 regardless of the *compress* setting, since it would foul up the bond
 connectivity that has already been assigned.  However, the
-:doc:`reset_atom_ids <reset_atom_ids>` command can be used after this command to
-accomplish the same thing.
+:doc:`reset_atom_ids <reset_atom_ids>` command can be used after this
+command to accomplish the same thing.
 
 Note that the re-assignment of IDs is not really a compression, where
 gaps in atom IDs are removed by decrementing atom IDs that are larger.
@@ -100,15 +108,15 @@ the :doc:`create_atoms <create_atoms>` command explains.
 
 A molecular system with fixed bonds, angles, dihedrals, or improper
 interactions, is one where the topology of the interactions is
-typically defined in the data file read by the
-:doc:`read_data <read_data>` command, and where the interactions
-themselves are defined with the :doc:`bond_style <bond_style>`,
-:doc:`angle_style <angle_style>`, etc commands.  If you delete atoms
-from such a system, you must be careful not to end up with bonded
-interactions that are stored by remaining atoms but which include
-deleted atoms.  This will cause LAMMPS to generate a "missing atoms"
-error when the bonded interaction is computed.  The *bond* and *mol*
-keywords offer two ways to do that.
+typically defined in the data file read by the :doc:`read_data
+<read_data>` command, and where the interactions themselves are
+defined with the :doc:`bond_style <bond_style>`, :doc:`angle_style
+<angle_style>`, etc commands.  If you delete atoms from such a system,
+you must be careful not to end up with bonded interactions that are
+stored by remaining atoms but which include deleted atoms.  This will
+cause LAMMPS to generate a "missing atoms" error when the bonded
+interaction is computed.  The *bond* and *mol* keywords offer two ways
+to do that.
 
 It the *bond* keyword is set to *yes* then any bond or angle or
 dihedral or improper interaction that includes a deleted atom is also

doc/src/dump.rst

@@ -137,7 +137,7 @@ Examples
    dump myDump all atom/gz 100 dump.atom.gz
    dump myDump all atom/zstd 100 dump.atom.zst
    dump 2 subgroup atom 50 dump.run.bin
-   dump 2 subgroup atom 50 dump.run.mpiio.bin
+   dump 2 subgroup atom/mpiio 50 dump.run.mpiio.bin
    dump 4a all custom 100 dump.myforce.* id type x y vx fx
    dump 4b flow custom 100 dump.%.myforce id type c_myF[3] v_ke
    dump 4b flow custom 100 dump.%.myforce id type c_myF[*] v_ke
@@ -169,11 +169,12 @@ or multiple smaller files).
 
 .. note::
 
-   Because periodic boundary conditions are enforced only on
-   timesteps when neighbor lists are rebuilt, the coordinates of an atom
-   written to a dump file may be slightly outside the simulation box.
-   Re-neighbor timesteps will not typically coincide with the timesteps
-   dump snapshots are written.  See the :doc:`dump_modify pbc <dump_modify>` command if you with to force coordinates to be
+   Because periodic boundary conditions are enforced only on timesteps
+   when neighbor lists are rebuilt, the coordinates of an atom written
+   to a dump file may be slightly outside the simulation box.
+   Re-neighbor timesteps will not typically coincide with the
+   timesteps dump snapshots are written.  See the :doc:`dump_modify
+   pbc <dump_modify>` command if you with to force coordinates to be
    strictly inside the simulation box.
 
 .. note::
@@ -189,20 +190,21 @@ or multiple smaller files).
    multiple processors, each of which owns a subset of the atoms.
 
 For the *atom*, *custom*, *cfg*, and *local* styles, sorting is off by
-default.  For the *dcd*, *xtc*, *xyz*, and *molfile* styles, sorting by
-atom ID is on by default. See the :doc:`dump_modify <dump_modify>` doc
-page for details.
+default.  For the *dcd*, *xtc*, *xyz*, and *molfile* styles, sorting
+by atom ID is on by default. See the :doc:`dump_modify <dump_modify>`
+doc page for details.
 
-The *atom/gz*, *cfg/gz*, *custom/gz*, *local/gz*, and *xyz/gz* styles are identical
-in command syntax to the corresponding styles without "gz", however,
-they generate compressed files using the zlib library. Thus the filename
-suffix ".gz" is mandatory. This is an alternative approach to writing
-compressed files via a pipe, as done by the regular dump styles, which
-may be required on clusters where the interface to the high-speed network
-disallows using the fork() library call (which is needed for a pipe).
-For the remainder of this doc page, you should thus consider the *atom*
-and *atom/gz* styles (etc) to be inter-changeable, with the exception
-of the required filename suffix.
+The *atom/gz*, *cfg/gz*, *custom/gz*, *local/gz*, and *xyz/gz* styles
+are identical in command syntax to the corresponding styles without
+"gz", however, they generate compressed files using the zlib
+library. Thus the filename suffix ".gz" is mandatory. This is an
+alternative approach to writing compressed files via a pipe, as done
+by the regular dump styles, which may be required on clusters where
+the interface to the high-speed network disallows using the fork()
+library call (which is needed for a pipe).  For the remainder of this
+doc page, you should thus consider the *atom* and *atom/gz* styles
+(etc) to be inter-changeable, with the exception of the required
+filename suffix.
 
 Similarly, the *atom/zstd*, *cfg/zstd*, *custom/zstd*, *local/zstd*,
 and *xyz/zstd* styles are identical to the gz styles, but use the Zstd
@@ -219,6 +221,11 @@ you should thus consider the *atom* and *atom/mpiio* styles (etc) to
 be inter-changeable.  The one exception is how the filename is
 specified for the MPI-IO styles, as explained below.
 
+.. warning::
+
+   The MPIIO package is currently unmaintained and has become
+   unreliable. Use with caution.
+
 The precision of values output to text-based dump files can be
 controlled by the :doc:`dump_modify format <dump_modify>` command and
 its options.
@@ -275,10 +282,11 @@ This bounding box is convenient for many visualization programs.  The
 meaning of the 6 character flags for "xx yy zz" is the same as above.
 
 Note that the first two numbers on each line are now xlo_bound instead
-of xlo, etc, since they represent a bounding box.  See the :doc:`Howto triclinic <Howto_triclinic>` page for a geometric description
-of triclinic boxes, as defined by LAMMPS, simple formulas for how the
-6 bounding box extents (xlo_bound,xhi_bound,etc) are calculated from
-the triclinic parameters, and how to transform those parameters to and
+of xlo, etc, since they represent a bounding box.  See the :doc:`Howto
+triclinic <Howto_triclinic>` page for a geometric description of
+triclinic boxes, as defined by LAMMPS, simple formulas for how the 6
+bounding box extents (xlo_bound,xhi_bound,etc) are calculated from the
+triclinic parameters, and how to transform those parameters to and
 from other commonly used triclinic representations.
 
 The "ITEM: ATOMS" line in each snapshot lists column descriptors for
@@ -310,23 +318,24 @@ written to the dump file.  This local data is typically calculated by
 each processor based on the atoms it owns, but there may be zero or
 more entities per atom, e.g. a list of bond distances.  An explanation
 of the possible dump local attributes is given below.  Note that by
-using input from the :doc:`compute property/local <compute_property_local>` command with dump local,
-it is possible to generate information on bonds, angles, etc that can
-be cut and pasted directly into a data file read by the
-:doc:`read_data <read_data>` command.
+using input from the :doc:`compute property/local
+<compute_property_local>` command with dump local, it is possible to
+generate information on bonds, angles, etc that can be cut and pasted
+directly into a data file read by the :doc:`read_data <read_data>`
+command.
 
 Style *cfg* has the same command syntax as style *custom* and writes
-extended CFG format files, as used by the
-`AtomEye <http://li.mit.edu/Archive/Graphics/A/>`_ visualization
-package.  Since the extended CFG format uses a single snapshot of the
-system per file, a wildcard "\*" must be included in the filename, as
-discussed below.  The list of atom attributes for style *cfg* must
-begin with either "mass type xs ys zs" or "mass type xsu ysu zsu"
-since these quantities are needed to write the CFG files in the
-appropriate format (though the "mass" and "type" fields do not appear
-explicitly in the file).  Any remaining attributes will be stored as
-"auxiliary properties" in the CFG files.  Note that you will typically
-want to use the :doc:`dump_modify element <dump_modify>` command with
+extended CFG format files, as used by the `AtomEye
+<http://li.mit.edu/Archive/Graphics/A/>`_ visualization package.
+Since the extended CFG format uses a single snapshot of the system per
+file, a wildcard "\*" must be included in the filename, as discussed
+below.  The list of atom attributes for style *cfg* must begin with
+either "mass type xs ys zs" or "mass type xsu ysu zsu" since these
+quantities are needed to write the CFG files in the appropriate format
+(though the "mass" and "type" fields do not appear explicitly in the
+file).  Any remaining attributes will be stored as "auxiliary
+properties" in the CFG files.  Note that you will typically want to
+use the :doc:`dump_modify element <dump_modify>` command with
 CFG-formatted files, to associate element names with atom types, so
 that AtomEye can render atoms appropriately. When unwrapped
 coordinates *xsu*, *ysu*, and *zsu* are requested, the nominal AtomEye
@@ -452,6 +461,11 @@ use the :doc:`read_dump <read_dump>` command or perform other
 post-processing, just as if the dump file was not written using
 MPI-IO.
 
+.. warning::
+
+   The MPIIO package is currently unmaintained and has become
+   unreliable. Use with caution.
+
 Note that MPI-IO dump files are one large file which all processors
 write to.  You thus cannot use the "%" wildcard character described
 above in the filename since that specifies generation of multiple
@@ -708,8 +722,9 @@ are part of the MPIIO package.  They are only enabled if LAMMPS was
 built with that package.  See the :doc:`Build package <Build_package>`
 doc page for more info.
 
-The *xtc* style is part of the MISC package.  It is only enabled if
-LAMMPS was built with that package.  See the :doc:`Build package <Build_package>` page for more info.
+The *xtc* and *dcd* styles are part of the EXTRA-DUMP package.  They
+are only enabled if LAMMPS was built with that package.  See the
+:doc:`Build package <Build_package>` page for more info.
 
 Related commands
 """"""""""""""""

doc/src/dump_image.rst

@@ -6,6 +6,8 @@ dump image command
 dump movie command
 ==================
 
+(see below for :ref:`dump_modify options <dump_modify_image>` specific to dump image/movie)
+
 Syntax
 """"""
 
@@ -15,7 +17,7 @@ Syntax
 
 * ID = user-assigned name for the dump
 * group-ID = ID of the group of atoms to be imaged
-* style = *image* or *movie* = style of dump command (other styles *atom* or *cfg* or *dcd* or *xtc* or *xyz* or *local* or *custom* are discussed on the :doc:`dump <dump>` doc page)
+* style = *image* or *movie* = style of dump command (other styles such as *atom* or *cfg* or *dcd* or *xtc* or *xyz* or *local* or *custom* are discussed on the :doc:`dump <dump>` doc page)
 * N = dump every this many timesteps
 * file = name of file to write image to
 * color = atom attribute that determines color of each atom
@@ -79,6 +81,69 @@ Syntax
          seed = random # seed (positive integer)
          dfactor = strength of shading from 0.0 to 1.0
 
+
+.. _dump_modify_image:
+
+dump_modify options for dump image/movie
+========================================
+
+Syntax
+""""""
+
+.. parsed-literal::
+
+   dump_modify dump-ID keyword values ...
+
+* these keywords apply only to the *image* and *movie* styles and are documented on this page
+* keyword = *acolor* or *adiam* or *amap* or *backcolor* or *bcolor* or *bdiam* or *boxcolor* or *color* or *bitrate* or *framerate*
+* see the :doc:`dump modify <dump_modify>` doc page for more general keywords
+
+  .. parsed-literal::
+
+       *acolor* args = type color
+         type = atom type or range of types (see below)
+         color = name of color or color1/color2/...
+       *adiam* args = type diam
+         type = atom type or range of types (see below)
+         diam = diameter of atoms of that type (distance units)
+       *amap* args = lo hi style delta N entry1 entry2 ... entryN
+         lo = number or *min* = lower bound of range of color map
+         hi = number or *max* = upper bound of range of color map
+         style = 2 letters = "c" or "d" or "s" plus "a" or "f"
+           "c" for continuous
+           "d" for discrete
+           "s" for sequential
+           "a" for absolute
+           "f" for fractional
+         delta = binsize (only used for style "s", otherwise ignored)
+           binsize = range is divided into bins of this width
+         N = # of subsequent entries
+         entry = value color (for continuous style)
+           value = number or *min* or *max* = single value within range
+           color = name of color used for that value
+         entry = lo hi color (for discrete style)
+           lo/hi = number or *min* or *max* = lower/upper bound of subset of range
+           color = name of color used for that subset of values
+         entry = color (for sequential style)
+           color = name of color used for a bin of values
+       *backcolor* arg = color
+         color = name of color for background
+       *bcolor* args = type color
+         type = bond type or range of types (see below)
+         color = name of color or color1/color2/...
+       *bdiam* args = type diam
+         type = bond type or range of types (see below)
+         diam = diameter of bonds of that type (distance units)
+       *boxcolor* arg = color
+         color = name of color for simulation box lines and processor sub-domain lines
+       *color* args = name R G B
+         name = name of color
+         R,G,B = red/green/blue numeric values from 0.0 to 1.0
+       *bitrate* arg = rate
+         rate = target bitrate for movie in kbps
+       *framerate* arg = fps
+         fps = frames per second for movie
+
 Examples
 """"""""
 
@@ -91,6 +156,8 @@ Examples
    dump m1 all movie 1000 movie.avi type type size 640 480
    dump m2 all movie 100 movie.m4v type type zoom 1.8 adiam v_value size 1280 720
 
+   dump_modify 1 amap min max cf 0.0 3 min green 0.5 yellow max blue boxcolor red
+
 Description
 """""""""""
 
@@ -145,10 +212,10 @@ is used.
 Similarly, the format of the resulting movie is chosen with the
 *movie* dump style. This is handled by the underlying FFmpeg converter
 and thus details have to be looked up in the `FFmpeg documentation
-<http://ffmpeg.org/ffmpeg.html>`_.
-Typical examples are: .avi, .mpg, .m4v, .mp4, .mkv, .flv, .mov, .gif
-Additional settings of the movie compression like bitrate and
-framerate can be set using the :doc:`dump_modify <dump_modify>` command.
+<http://ffmpeg.org/ffmpeg.html>`_.  Typical examples are: .avi, .mpg,
+.m4v, .mp4, .mkv, .flv, .mov, .gif Additional settings of the movie
+compression like bitrate and framerate can be set using the
+dump_modify command as described below.
 
 To write out JPEG and PNG format files, you must build LAMMPS with
 support for the corresponding JPEG or PNG library. To convert images
@@ -210,19 +277,20 @@ to colors is as follows:
 * type 6 = cyan
 
 and repeats itself for types > 6.  This mapping can be changed by the
-:doc:`dump_modify acolor <dump_modify>` command.
+"dump_modify acolor" command, as described below.
 
 If *type* is specified for the *diameter* setting then the diameter of
 each atom is determined by its atom type.  By default all types have
-diameter 1.0.  This mapping can be changed by the :doc:`dump_modify adiam <dump_modify>` command.
+diameter 1.0.  This mapping can be changed by the "dump_modify adiam"
+command, as described below.
 
 If *element* is specified for the *color* and/or *diameter* setting,
 then the color and/or diameter of each atom is determined by which
 element it is, which in turn is specified by the element-to-type
-mapping specified by the "dump_modify element" command.  By default
-every atom type is C (carbon).  Every element has a color and diameter
-associated with it, which is the same as the colors and sizes used by
-the `AtomEye <atomeye_>`_ visualization package.
+mapping specified by the "dump_modify element" command, as described
+below.  By default every atom type is C (carbon).  Every element has a
+color and diameter associated with it, which is the same as the colors
+and sizes used by the `AtomEye <atomeye_>`_ visualization package.
 
 .. _atomeye: http://li.mit.edu/Archive/Graphics/A/
 
@@ -232,13 +300,13 @@ settings, they are interpreted in the following way.
 If "vx", for example, is used as the *color* setting, then the color
 of the atom will depend on the x-component of its velocity.  The
 association of a per-atom value with a specific color is determined by
-a "color map", which can be specified via the
-:doc:`dump_modify <dump_modify>` command.  The basic idea is that the
-atom-attribute will be within a range of values, and every value
-within the range is mapped to a specific color.  Depending on how the
-color map is defined, that mapping can take place via interpolation so
-that a value of -3.2 is halfway between "red" and "blue", or
-discretely so that the value of -3.2 is "orange".
+a "color map", which can be specified via the dump_modify command, as
+described below.  The basic idea is that the atom-attribute will be
+within a range of values, and every value within the range is mapped
+to a specific color.  Depending on how the color map is defined, that
+mapping can take place via interpolation so that a value of -3.2 is
+halfway between "red" and "blue", or discretely so that the value of
+-3.2 is "orange".
 
 If "vx", for example, is used as the *diameter* setting, then the atom
 will be rendered using the x-component of its velocity as the
@@ -251,9 +319,10 @@ diameter, which can be used as the *diameter* setting.
 
 The various keywords listed above control how the image is rendered.
 As listed below, all of the keywords have defaults, most of which you
-will likely not need to change.  The :doc:`dump modify <dump_modify>`
-also has options specific to the dump image style, particularly for
-assigning colors to atoms, bonds, and other image features.
+will likely not need to change.  As described below, the dump modify
+command also has options specific to the dump image style,
+particularly for assigning colors to atoms, bonds, and other image
+features.
 
 ----------
 
@@ -295,7 +364,7 @@ types to colors is as follows:
 * type 6 = cyan
 
 and repeats itself for bond types > 6.  This mapping can be changed by
-the :doc:`dump_modify bcolor <dump_modify>` command.
+the "dump_modify bcolor" command, as described below.
 
 The bond *width* value can be a numeric value or *atom* or *type* (or
 *none* as indicated above).
@@ -310,7 +379,8 @@ of the 2 atoms in the bond.
 
 If *type* is specified for the *width* value then the diameter of each
 bond is determined by its bond type.  By default all types have
-diameter 0.5.  This mapping can be changed by the :doc:`dump_modify bdiam <dump_modify>` command.
+diameter 0.5.  This mapping can be changed by the "dump_modify bdiam" command,
+as described below.
 
 ----------
 
@@ -330,7 +400,7 @@ mapping of types to colors is as follows:
 * type 6 = cyan
 
 and repeats itself for types > 6.  There is not yet an option to
-change this via the :doc:`dump_modify <dump_modify>` command.
+change this via the dump_modify command.
 
 The line *width* can only be a numeric value, which specifies that all
 lines will be drawn as cylinders with that diameter, e.g. 1.0, which
@@ -357,7 +427,7 @@ default the mapping of types to colors is as follows:
 * type 6 = cyan
 
 and repeats itself for types > 6.  There is not yet an option to
-change this via the :doc:`dump_modify <dump_modify>` command.
+change this via the dump_modify command.
 
 ----------
 
@@ -390,7 +460,7 @@ particle.  By default the mapping of types to colors is as follows:
 * type 6 = cyan
 
 and repeats itself for types > 6.  There is not yet an option to
-change this via the :doc:`dump_modify <dump_modify>` command.
+change this via the dump_modify command.
 
 ----------
 
@@ -414,7 +484,7 @@ the mapping of types to colors is as follows:
 * type 6 = cyan
 
 and repeats itself for types > 6.  There is not yet an option to
-change this via the :doc:`dump_modify <dump_modify>` command.
+change this via the dump_modify command.
 
 ----------
 
@@ -488,7 +558,8 @@ are rendered as thin cylinders in the image.  If *no* is set, then the
 box boundaries are not drawn and the *diam* setting is ignored.  If
 *yes* is set, the 12 edges of the box are drawn, with a diameter that
 is a fraction of the shortest box length in x,y,z (for 3d) or x,y (for
-2d).  The color of the box boundaries can be set with the :doc:`dump_modify boxcolor <dump_modify>` command.
+2d).  The color of the box boundaries can be set with the "dump_modify
+boxcolor" command.
 
 The *axes* keyword determines if and how the coordinate axes are
 rendered as thin cylinders in the image.  If *no* is set, then the
@@ -507,7 +578,8 @@ set (default), then the sub-domain boundaries are not drawn and the
 *diam* setting is ignored.  If *yes* is set, the 12 edges of each
 processor sub-domain are drawn, with a diameter that is a fraction of
 the shortest box length in x,y,z (for 3d) or x,y (for 2d).  The color
-of the sub-domain boundaries can be set with the :doc:`dump_modify boxcolor <dump_modify>` command.
+of the sub-domain boundaries can be set with the "dump_modify
+boxcolor" command.
 
 ----------
 
@@ -607,9 +679,272 @@ Play the movie:
 
 ----------
 
-See the :doc:`Modify <Modify>` page for information on how to add
-new compute and fix styles to LAMMPS to calculate per-atom quantities
-which could then be output into dump files.
+Dump_modify keywords for dump image and dump movie
+""""""""""""""""""""""""""""""""""""""""""""""""""
+
+The following dump_modify keywords apply only to the dump image and
+dump movie styles.  Any keyword that works with dump image also works
+with dump movie, since the movie is simply a collection of images.
+Some of the keywords only affect the dump movie style.  The
+descriptions give details.
+
+----------
+
+The *acolor* keyword can be used with the dump image command, when its
+atom color setting is *type*, to set the color that atoms of each type
+will be drawn in the image.
+
+The specified *type* should be an integer from 1 to Ntypes = the
+number of atom types.  A wildcard asterisk can be used in place of or
+in conjunction with the *type* argument to specify a range of atom
+types.  This takes the form "\*" or "\*n" or "n\*" or "m\*n".  If N =
+the number of atom 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).
+
+The specified *color* can be a single color which is any of the 140
+pre-defined colors (see below) or a color name defined by the
+"dump_modify color" command, as described below.  Or it can be two or
+more colors separated by a "/" character, e.g. red/green/blue.  In the
+former case, that color is assigned to all the specified atom types.
+In the latter case, the list of colors are assigned in a round-robin
+fashion to each of the specified atom types.
+
+----------
+
+The *adiam* keyword can be used with the dump image command, when its
+atom diameter setting is *type*, to set the size that atoms of each
+type will be drawn in the image.  The specified *type* should be an
+integer from 1 to Ntypes.  As with the *acolor* keyword, a wildcard
+asterisk can be used as part of the *type* argument to specify a range
+of atom types.  The specified *diam* is the size in whatever distance
+:doc:`units <units>` the input script is using, e.g. Angstroms.
+
+----------
+
+The *amap* keyword can be used with the dump image command, with its
+*atom* keyword, when its atom setting is an atom-attribute, to setup a
+color map.  The color map is used to assign a specific RGB
+(red/green/blue) color value to an individual atom when it is drawn,
+based on the atom's attribute, which is a numeric value, e.g. its
+x-component of velocity if the atom-attribute "vx" was specified.
+
+The basic idea of a color map is that the atom-attribute will be
+within a range of values, and that range is associated with a series
+of colors (e.g. red, blue, green).  An atom's specific value (vx =
+-3.2) can then mapped to the series of colors (e.g. halfway between
+red and blue), and a specific color is determined via an interpolation
+procedure.
+
+There are many possible options for the color map, enabled by the
+*amap* keyword.  Here are the details.
+
+The *lo* and *hi* settings determine the range of values allowed for
+the atom attribute.  If numeric values are used for *lo* and/or *hi*,
+then values that are lower/higher than that value are set to the
+value.  I.e. the range is static.  If *lo* is specified as *min* or
+*hi* as *max* then the range is dynamic, and the lower and/or
+upper bound will be calculated each time an image is drawn, based
+on the set of atoms being visualized.
+
+The *style* setting is two letters, such as "ca".  The first letter is
+either "c" for continuous, "d" for discrete, or "s" for sequential.
+The second letter is either "a" for absolute, or "f" for fractional.
+
+A continuous color map is one in which the color changes continuously
+from value to value within the range.  A discrete color map is one in
+which discrete colors are assigned to sub-ranges of values within the
+range.  A sequential color map is one in which discrete colors are
+assigned to a sequence of sub-ranges of values covering the entire
+range.
+
+An absolute color map is one in which the values to which colors are
+assigned are specified explicitly as values within the range.  A
+fractional color map is one in which the values to which colors are
+assigned are specified as a fractional portion of the range.  For
+example if the range is from -10.0 to 10.0, and the color red is to be
+assigned to atoms with a value of 5.0, then for an absolute color map
+the number 5.0 would be used.  But for a fractional map, the number
+0.75 would be used since 5.0 is 3/4 of the way from -10.0 to 10.0.
+
+The *delta* setting must be specified for all styles, but is only used
+for the sequential style; otherwise the value is ignored.  It
+specifies the bin size to use within the range for assigning
+consecutive colors to.  For example, if the range is from -10.0 to
+10.0 and a *delta* of 1.0 is used, then 20 colors will be assigned to
+the range.  The first will be from -10.0 <= color1 < -9.0, then second
+from -9.0 <= color2 < -8.0, etc.
+
+The *N* setting is how many entries follow.  The format of the entries
+depends on whether the color map style is continuous, discrete or
+sequential.  In all cases the *color* setting can be any of the 140
+pre-defined colors (see below) or a color name defined by the
+dump_modify color option.
+
+For continuous color maps, each entry has a *value* and a *color*\ .
+The *value* is either a number within the range of values or *min* or
+*max*\ .  The *value* of the first entry must be *min* and the *value*
+of the last entry must be *max*\ .  Any entries in between must have
+increasing values.  Note that numeric values can be specified either
+as absolute numbers or as fractions (0.0 to 1.0) of the range,
+depending on the "a" or "f" in the style setting for the color map.
+
+Here is how the entries are used to determine the color of an
+individual atom, given the value X of its atom attribute.  X will fall
+between 2 of the entry values.  The color of the atom is linearly
+interpolated (in each of the RGB values) between the 2 colors
+associated with those entries.  For example, if X = -5.0 and the 2
+surrounding entries are "red" at -10.0 and "blue" at 0.0, then the
+atom's color will be halfway between "red" and "blue", which happens
+to be "purple".
+
+For discrete color maps, each entry has a *lo* and *hi* value and a
+*color*\ .  The *lo* and *hi* settings are either numbers within the
+range of values or *lo* can be *min* or *hi* can be *max*\ .  The *lo*
+and *hi* settings of the last entry must be *min* and *max*\ .  Other
+entries can have any *lo* and *hi* values and the sub-ranges of
+different values can overlap.  Note that numeric *lo* and *hi* values
+can be specified either as absolute numbers or as fractions (0.0 to
+1.0) of the range, depending on the "a" or "f" in the style setting
+for the color map.
+
+Here is how the entries are used to determine the color of an
+individual atom, given the value X of its atom attribute.  The entries
+are scanned from first to last.  The first time that *lo* <= X <=
+*hi*, X is assigned the color associated with that entry.  You can
+think of the last entry as assigning a default color (since it will
+always be matched by X), and the earlier entries as colors that
+override the default.  Also note that no interpolation of a color RGB
+is done.  All atoms will be drawn with one of the colors in the list
+of entries.
+
+For sequential color maps, each entry has only a *color*\ .  Here is how
+the entries are used to determine the color of an individual atom,
+given the value X of its atom attribute.  The range is partitioned
+into N bins of width *binsize*\ .  Thus X will fall in a specific bin
+from 1 to N, say the Mth bin.  If it falls on a boundary between 2
+bins, it is considered to be in the higher of the 2 bins.  Each bin is
+assigned a color from the E entries.  If E < N, then the colors are
+repeated.  For example if 2 entries with colors red and green are
+specified, then the odd numbered bins will be red and the even bins
+green.  The color of the atom is the color of its bin.  Note that the
+sequential color map is really a shorthand way of defining a discrete
+color map without having to specify where all the bin boundaries are.
+
+Here is an example of using a sequential color map to color all the
+atoms in individual molecules with a different color.  See the
+examples/pour/in.pour.2d.molecule input script for an example of how
+this is used.
+
+.. code-block:: LAMMPS
+
+   variable        colors string &
+                   "red green blue yellow white &
+                   purple pink orange lime gray"
+   variable        mol atom mol%10
+   dump            1 all image 250 image.*.jpg v_mol type &
+                   zoom 1.6 adiam 1.5
+   dump_modify     1 pad 5 amap 0 10 sa 1 10 ${colors}
+
+In this case, 10 colors are defined, and molecule IDs are
+mapped to one of the colors, even if there are 1000s of molecules.
+
+----------
+
+The *backcolor* sets the background color of the images.  The color
+name can be any of the 140 pre-defined colors (see below) or a color
+name defined by the dump_modify color option.
+
+----------
+
+The *bcolor* keyword can be used with the dump image command, with its
+*bond* keyword, when its color setting is *type*, to set the color
+that bonds of each type will be drawn in the image.
+
+The specified *type* should be an integer from 1 to Nbondtypes = the
+number of bond types.  A wildcard asterisk can be used in place of or
+in conjunction with the *type* argument to specify a range of 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 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).
+
+The specified *color* can be a single color which is any of the 140
+pre-defined colors (see below) or a color name defined by the
+dump_modify color option.  Or it can be two or more colors separated
+by a "/" character, e.g. red/green/blue.  In the former case, that
+color is assigned to all the specified bond types.  In the latter
+case, the list of colors are assigned in a round-robin fashion to each
+of the specified bond types.
+
+----------
+
+The *bdiam* keyword can be used with the dump image command, with its
+*bond* keyword, when its diam setting is *type*, to set the diameter
+that bonds of each type will be drawn in the image.  The specified
+*type* should be an integer from 1 to Nbondtypes.  As with the
+*bcolor* keyword, a wildcard asterisk can be used as part of the
+*type* argument to specify a range of bond types.  The specified
+*diam* is the size in whatever distance :doc:`units <units>` you are
+using, e.g. Angstroms.
+
+----------
+
+The *bitrate* keyword can be used with the :doc:`dump movie
+<dump_image>` command to define the size of the resulting movie file
+and its quality via setting how many kbits per second are to be used
+for the movie file. Higher bitrates require less compression and will
+result in higher quality movies.  The quality is also determined by
+the compression format and encoder.  The default setting is 2000
+kbit/s, which will result in average quality with older compression
+formats.
+
+.. note::
+
+   Not all movie file formats supported by dump movie allow the
+   bitrate to be set.  If not, the setting is silently ignored.
+
+----------
+
+The *boxcolor* keyword sets the color of the simulation box drawn
+around the atoms in each image as well as the color of processor
+sub-domain boundaries.  See the "dump image box" command for how to
+specify that a box be drawn via the *box* keyword, and the sub-domain
+boundaries via the *subbox* keyword.  The color name can be any of the
+140 pre-defined colors (see below) or a color name defined by the
+dump_modify color option.
+
+----------
+
+The *color* keyword allows definition of a new color name, in addition
+to the 140-predefined colors (see below), and associates 3
+red/green/blue RGB values with that color name.  The color name can
+then be used with any other dump_modify keyword that takes a color
+name as a value.  The RGB values should each be floating point values
+between 0.0 and 1.0 inclusive.
+
+When a color name is converted to RGB values, the user-defined color
+names are searched first, then the 140 pre-defined color names.  This
+means you can also use the *color* keyword to overwrite one of the
+pre-defined color names with new RBG values.
+
+----------
+
+The *framerate* keyword can be used with the :doc:`dump movie
+<dump_image>` command to define the duration of the resulting movie
+file.  Movie files written by the dump *movie* command have a default
+frame rate of 24 frames per second and the images generated will be
+converted at that rate.  Thus a sequence of 1000 dump images will
+result in a movie of about 42 seconds.  To make a movie run longer you
+can either generate images more frequently or lower the frame rate.
+To speed a movie up, you can do the inverse.  Using a frame rate
+higher than 24 is not recommended, as it will result in simply
+dropping the rendered images. It is more efficient to dump images less
+frequently.
 
 ----------
 
@@ -664,7 +999,7 @@ Related commands
 Default
 """""""
 
-The defaults for the keywords are as follows:
+The defaults for the dump image and dump movie keywords are as follows:
 
 * adiam = not specified (use diameter setting)
 * atom = yes
@@ -682,3 +1017,101 @@ The defaults for the keywords are as follows:
 * subbox no 0.0
 * shiny = 1.0
 * ssao = no
+
+----------
+
+The defaults for the dump_modify keywords specific to dump image and dump movie are as follows:
+
+* acolor = \* red/green/blue/yellow/aqua/cyan
+* adiam = \* 1.0
+* amap = min max cf 0.0 2 min blue max red
+* backcolor = black
+* bcolor = \* red/green/blue/yellow/aqua/cyan
+* bdiam = \* 0.5
+* bitrate = 2000
+* boxcolor = yellow
+* color = 140 color names are pre-defined as listed below
+* framerate = 24
+
+----------
+
+These are the standard 109 element names that LAMMPS pre-defines for
+use with the dump image and dump_modify commands.
+
+* 1-10 = "H", "He", "Li", "Be", "B", "C", "N", "O", "F", "Ne"
+* 11-20 = "Na", "Mg", "Al", "Si", "P", "S", "Cl", "Ar", "K", "Ca"
+* 21-30 = "Sc", "Ti", "V", "Cr", "Mn", "Fe", "Co", "Ni", "Cu", "Zn"
+* 31-40 = "Ga", "Ge", "As", "Se", "Br", "Kr", "Rb", "Sr", "Y", "Zr"
+* 41-50 = "Nb", "Mo", "Tc", "Ru", "Rh", "Pd", "Ag", "Cd", "In", "Sn"
+* 51-60 = "Sb", "Te", "I", "Xe", "Cs", "Ba", "La", "Ce", "Pr", "Nd"
+* 61-70 = "Pm", "Sm", "Eu", "Gd", "Tb", "Dy", "Ho", "Er", "Tm", "Yb"
+* 71-80 = "Lu", "Hf", "Ta", "W", "Re", "Os", "Ir", "Pt", "Au", "Hg"
+* 81-90 = "Tl", "Pb", "Bi", "Po", "At", "Rn", "Fr", "Ra", "Ac", "Th"
+* 91-100 = "Pa", "U", "Np", "Pu", "Am", "Cm", "Bk", "Cf", "Es", "Fm"
+* 101-109 = "Md", "No", "Lr", "Rf", "Db", "Sg", "Bh", "Hs", "Mt"
+
+----------
+
+These are the 140 colors that LAMMPS pre-defines for use with the dump
+image and dump_modify commands.  Additional colors can be defined with
+the dump_modify color command.  The 3 numbers listed for each name are
+the RGB (red/green/blue) values.  Divide each value by 255 to get the
+equivalent 0.0 to 1.0 value.
+
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| aliceblue = 240, 248, 255     | antiquewhite = 250, 235, 215         | aqua = 0, 255, 255              | aquamarine = 127, 255, 212     | azure = 240, 255, 255          |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| beige = 245, 245, 220         | bisque = 255, 228, 196               | black = 0, 0, 0                 | blanchedalmond = 255, 255, 205 | blue = 0, 0, 255               |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| blueviolet = 138, 43, 226     | brown = 165, 42, 42                  | burlywood = 222, 184, 135       | cadetblue = 95, 158, 160       | chartreuse = 127, 255, 0       |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| chocolate = 210, 105, 30      | coral = 255, 127, 80                 | cornflowerblue = 100, 149, 237  | cornsilk = 255, 248, 220       | crimson = 220, 20, 60          |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| cyan = 0, 255, 255            | darkblue = 0, 0, 139                 | darkcyan = 0, 139, 139          | darkgoldenrod = 184, 134, 11   | darkgray = 169, 169, 169       |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| darkgreen = 0, 100, 0         | darkkhaki = 189, 183, 107            | darkmagenta = 139, 0, 139       | darkolivegreen = 85, 107, 47   | darkorange = 255, 140, 0       |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| darkorchid = 153, 50, 204     | darkred = 139, 0, 0                  | darksalmon = 233, 150, 122      | darkseagreen = 143, 188, 143   | darkslateblue = 72, 61, 139    |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| darkslategray = 47, 79, 79    | darkturquoise = 0, 206, 209          | darkviolet = 148, 0, 211        | deeppink = 255, 20, 147        | deepskyblue = 0, 191, 255      |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| dimgray = 105, 105, 105       | dodgerblue = 30, 144, 255            | firebrick = 178, 34, 34         | floralwhite = 255, 250, 240    | forestgreen = 34, 139, 34      |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| fuchsia = 255, 0, 255         | gainsboro = 220, 220, 220            | ghostwhite = 248, 248, 255      | gold = 255, 215, 0             | goldenrod = 218, 165, 32       |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| gray = 128, 128, 128          | green = 0, 128, 0                    | greenyellow = 173, 255, 47      | honeydew = 240, 255, 240       | hotpink = 255, 105, 180        |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| indianred = 205, 92, 92       | indigo = 75, 0, 130                  | ivory = 255, 240, 240           | khaki = 240, 230, 140          | lavender = 230, 230, 250       |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| lavenderblush = 255, 240, 245 | lawngreen = 124, 252, 0              | lemonchiffon = 255, 250, 205    | lightblue = 173, 216, 230      | lightcoral = 240, 128, 128     |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| lightcyan = 224, 255, 255     | lightgoldenrodyellow = 250, 250, 210 | lightgreen = 144, 238, 144      | lightgrey = 211, 211, 211      | lightpink = 255, 182, 193      |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| lightsalmon = 255, 160, 122   | lightseagreen = 32, 178, 170         | lightskyblue = 135, 206, 250    | lightslategray = 119, 136, 153 | lightsteelblue = 176, 196, 222 |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| lightyellow = 255, 255, 224   | lime = 0, 255, 0                     | limegreen = 50, 205, 50         | linen = 250, 240, 230          | magenta = 255, 0, 255          |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| maroon = 128, 0, 0            | mediumaquamarine = 102, 205, 170     | mediumblue = 0, 0, 205          | mediumorchid = 186, 85, 211    | mediumpurple = 147, 112, 219   |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| mediumseagreen = 60, 179, 113 | mediumslateblue = 123, 104, 238      | mediumspringgreen = 0, 250, 154 | mediumturquoise = 72, 209, 204 | mediumvioletred = 199, 21, 133 |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| midnightblue = 25, 25, 112    | mintcream = 245, 255, 250            | mistyrose = 255, 228, 225       | moccasin = 255, 228, 181       | navajowhite = 255, 222, 173    |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| navy = 0, 0, 128              | oldlace = 253, 245, 230              | olive = 128, 128, 0             | olivedrab = 107, 142, 35       | orange = 255, 165, 0           |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| orangered = 255, 69, 0        | orchid = 218, 112, 214               | palegoldenrod = 238, 232, 170   | palegreen = 152, 251, 152      | paleturquoise = 175, 238, 238  |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| palevioletred = 219, 112, 147 | papayawhip = 255, 239, 213           | peachpuff = 255, 239, 213       | peru = 205, 133, 63            | pink = 255, 192, 203           |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| plum = 221, 160, 221          | powderblue = 176, 224, 230           | purple = 128, 0, 128            | red = 255, 0, 0                | rosybrown = 188, 143, 143      |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| royalblue = 65, 105, 225      | saddlebrown = 139, 69, 19            | salmon = 250, 128, 114          | sandybrown = 244, 164, 96      | seagreen = 46, 139, 87         |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| seashell = 255, 245, 238      | sienna = 160, 82, 45                 | silver = 192, 192, 192          | skyblue = 135, 206, 235        | slateblue = 106, 90, 205       |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| slategray = 112, 128, 144     | snow = 255, 250, 250                 | springgreen = 0, 255, 127       | steelblue = 70, 130, 180       | tan = 210, 180, 140            |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| teal = 0, 128, 128            | thistle = 216, 191, 216              | tomato = 253, 99, 71            | turquoise = 64, 224, 208       | violet = 238, 130, 238         |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| wheat = 245, 222, 179         | white = 255, 255, 255                | whitesmoke = 245, 245, 245      | yellow = 255, 255, 0           | yellowgreen = 154, 205, 50     |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+

doc/src/dump_modify.rst

@@ -3,6 +3,9 @@
 dump_modify command
 ===================
 
+:doc:`dump_modify <dump_image>` command for image/movie options
+===============================================================
+
 Syntax
 """"""
 
@@ -12,14 +15,16 @@ Syntax
 
 * dump-ID = ID of dump to modify
 * one or more keyword/value pairs may be appended
+
 * these keywords apply to various dump styles
-* keyword = *append* or *at* or *buffer* or *delay* or *element* or *every* or *fileper* or *first* or *flush* or *format* or *image* or *label* or *maxfiles* or *nfile* or *pad* or *pbc* or *precision* or *region* or *refresh* or *scale* or *sfactor* or *sort* or *tfactor* or *thermo* or *thresh* or *time* or *units* or *unwrap*
+* keyword = *append* or *at* or *balance* or *buffer* or *delay* or *element* or *every* or *every/time* or *fileper* or *first* or *flush* or *format* or *header* or *image* or *label* or *maxfiles* or *nfile* or *pad* or *pbc* or *precision* or *region* or *refresh* or *scale* or *sfactor* or *sort* or *tfactor* or *thermo* or *thresh* or *time* or *units* or *unwrap*
 
   .. parsed-literal::
 
        *append* arg = *yes* or *no*
        *at* arg = N
          N = index of frame written upon first dump
+       *balance* arg = *yes* or *no*
        *buffer* arg = *yes* or *no*
        *delay* arg = Dstep
          Dstep = delay output until this timestep
@@ -28,6 +33,9 @@ Syntax
        *every* arg = N
          N = dump every this many timesteps
          N can be a variable (see below)
+       *every/time* arg = Delta
+         Delta = dump every this interval in simulation time (time units)
+         Delta can be a variable (see below)
        *fileper* arg = Np
          Np = write one file for every this many processors
        *first* arg = *yes* or *no*
@@ -35,6 +43,9 @@ Syntax
        *format* args = *line* string, *int* string, *float* string, M string, or *none*
          string = C-style format string
          M = integer from 1 to N, where N = # of per-atom quantities being output
+       *header* arg = *yes* or *no*
+         *yes* to write the header
+         *no* to not write the header
        *image* arg = *yes* or *no*
        *label* arg = string
          string = character string (e.g. BONDS) to use in header of dump local file
@@ -66,56 +77,11 @@ Syntax
        *unwrap* arg = *yes* or *no*
 
 * these keywords apply only to the *image* and *movie* :doc:`styles <dump_image>`
-* keyword = *acolor* or *adiam* or *amap* or *backcolor* or *bcolor* or *bdiam* or *boxcolor* or *color* or *bitrate* or *framerate* or *header*
+* keyword = *acolor* or *adiam* or *amap* or *backcolor* or *bcolor* or *bdiam* or *boxcolor* or *color* or *bitrate* or *framerate*
 
   .. parsed-literal::
 
-       *acolor* args = type color
-         type = atom type or range of types (see below)
-         color = name of color or color1/color2/...
-       *adiam* args = type diam
-         type = atom type or range of types (see below)
-         diam = diameter of atoms of that type (distance units)
-       *amap* args = lo hi style delta N entry1 entry2 ... entryN
-         lo = number or *min* = lower bound of range of color map
-         hi = number or *max* = upper bound of range of color map
-         style = 2 letters = "c" or "d" or "s" plus "a" or "f"
-           "c" for continuous
-           "d" for discrete
-           "s" for sequential
-           "a" for absolute
-           "f" for fractional
-         delta = binsize (only used for style "s", otherwise ignored)
-           binsize = range is divided into bins of this width
-         N = # of subsequent entries
-         entry = value color (for continuous style)
-           value = number or *min* or *max* = single value within range
-           color = name of color used for that value
-         entry = lo hi color (for discrete style)
-           lo/hi = number or *min* or *max* = lower/upper bound of subset of range
-           color = name of color used for that subset of values
-         entry = color (for sequential style)
-           color = name of color used for a bin of values
-       *backcolor* arg = color
-         color = name of color for background
-       *bcolor* args = type color
-         type = bond type or range of types (see below)
-         color = name of color or color1/color2/...
-       *bdiam* args = type diam
-         type = bond type or range of types (see below)
-         diam = diameter of bonds of that type (distance units)
-       *boxcolor* arg = color
-         color = name of color for simulation box lines and processor sub-domain lines
-       *color* args = name R G B
-         name = name of color
-         R,G,B = red/green/blue numeric values from 0.0 to 1.0
-       *bitrate* arg = rate
-         rate = target bitrate for movie in kbps
-       *framerate* arg = fps
-         fps = frames per second for movie
-       *header* arg = *yes* or *no*
-         *yes* to write the header
-         *no* to not write the header
+       see the :doc:`dump image <dump_image>` doc page for details
 
 * these keywords apply only to the */gz* and */zstd* dump styles
 * keyword = *compression_level*
@@ -126,7 +92,7 @@ Syntax
          level = integer specifying the compression level that should be used (see below for supported levels)
 
 * these keywords apply only to the */zstd* dump styles
-* keyword = *compression_level*
+* keyword = *checksum*
 
   .. parsed-literal::
 
@@ -144,7 +110,6 @@ Examples
    dump_modify xtcdump precision 10000 sfactor 0.1
    dump_modify 1 every 1000 nfile 20
    dump_modify 1 every v_myVar
-   dump_modify 1 amap min max cf 0.0 3 min green 0.5 yellow max blue boxcolor red
 
 Description
 """""""""""
@@ -163,8 +128,9 @@ which allow for use of MPI-IO.
 
 ----------
 
-These keywords apply to various dump styles, including the :doc:`dump image <dump_image>` and :doc:`dump movie <dump_image>` styles.  The
-description gives details.
+Unless otherwise noted, the following keywords apply to all the
+various dump styles, including the :doc:`dump image <dump_image>` and
+:doc:`dump movie <dump_image>` styles.
 
 ----------
 
@@ -235,11 +201,19 @@ will be accepted.
 
 ----------
 
-The *every* keyword changes the dump frequency originally specified by
-the :doc:`dump <dump>` command to a new value.  The every keyword can be
-specified in one of two ways.  It can be a numeric value in which case
-it must be > 0.  Or it can be an :doc:`equal-style variable <variable>`,
-which should be specified as v_name, where name is the variable name.
+The *every* keyword can be used with any dump style except the *dcd*
+and *xtc* styles.  It does two things.  It specifies that the interval
+between dump snapshots will be set in timesteps, which is the default
+if the *every* or *every/time* keywords are not used.  See the
+*every/time* keyword for how to specify the interval in simulation
+time, i.e. in time units of the :doc:`units <units>` command.  The
+*every* keyword also sets the interval value, which overrides the dump
+frequency originally specified by the :doc:`dump <dump>` command.
+
+The *every* keyword can be specified in one of two ways.  It can be a
+numeric value in which case it must be > 0.  Or it can be an
+:doc:`equal-style variable <variable>`, which should be specified as
+v_name, where name is the variable name.
 
 In this case, the variable is evaluated at the beginning of a run to
 determine the next timestep at which a dump snapshot will be written
@@ -248,11 +222,12 @@ determine the next timestep, etc.  Thus the variable should return
 timestep values.  See the stagger() and logfreq() and stride() math
 functions for :doc:`equal-style variables <variable>`, as examples of
 useful functions to use in this context.  Other similar math functions
-could easily be added as options for :doc:`equal-style variables <variable>`.  Also see the next() function, which allows
-use of a file-style variable which reads successive values from a
-file, each time the variable is evaluated.  Used with the *every*
-keyword, if the file contains a list of ascending timesteps, you can
-output snapshots whenever you wish.
+could easily be added as options for :doc:`equal-style variables
+<variable>`.  Also see the next() function, which allows use of a
+file-style variable which reads successive values from a file, each
+time the variable is evaluated.  Used with the *every* keyword, if the
+file contains a list of ascending timesteps, you can output snapshots
+whenever you wish.
 
 Note that when using the variable option with the *every* keyword, you
 need to use the *first* option if you want an initial snapshot written
@@ -293,14 +268,103 @@ in file tmp.times:
 
 ----------
 
+The *every/time* keyword can be used with any dump style except the
+*dcd* and *xtc* styles.  It does two things.  It specifies that the
+interval between dump snapshots will be set in simulation time,
+i.e. in time units of the :doc:`units <units>` command.  This can be
+useful when the timestep size varies during a simulation run, e.g. by
+use of the :doc:`fix dt/reset <fix_dt_reset>` command.  The default is
+to specify the interval in timesteps; see the *every* keyword.  The
+*every/time* command also sets the interval value.
+
+.. note::
+
+   If you wish dump styles *atom*, *custom*, *local*, or *xyz* to
+   include the simulation time as a field in the header portion of
+   each snapshot, you also need to use the dump_modify *time* keyword
+   with a setting of *yes*.  See its documentation below.
+
+Note that since snapshots are output on simulation steps, each
+snapshot will be written on the first timestep whose associated
+simulation time is >= the exact snapshot time value.
+
+As with the *every* option, the *Delta* value can be specified in one
+of two ways.  It can be a numeric value in which case it must be >
+0.0.  Or it can be an :doc:`equal-style variable <variable>`, which
+should be specified as v_name, where name is the variable name.
+
+In this case, the variable is evaluated at the beginning of a run to
+determine the next simulation time at which a dump snapshot will be
+written out.  On that timestep the variable will be evaluated again to
+determine the next simulation time, etc.  Thus the variable should
+return values in time units.  Note the current timestep or simulation
+time can be used in an :doc:`equal-style variables <variable>` since
+they are both thermodynamic keywords.  Also see the next() function,
+which allows use of a file-style variable which reads successive
+values from a file, each time the variable is evaluated.  Used with
+the *every/time* keyword, if the file contains a list of ascending
+simulation times, you can output snapshots whenever you wish.
+
+Note that when using the variable option with the *every/time*
+keyword, you need to use the *first* option if you want an initial
+snapshot written to the dump file.  The *every/time* keyword cannot be
+used with the dump *dcd* style.
+
+For example, the following commands will write snapshots at successive
+simulation times which grow by a factor of 1.5 with each interval.
+The dt value used in the variable is to avoid a zero result when the
+initial simulation time is 0.0.
+
+.. code-block:: LAMMPS
+
+   variable        increase equal 1.5*(time+dt)
+   dump            1 all atom 100 tmp.dump
+   dump_modify     1 every/time v_increase first yes
+
+The following commands would write snapshots at the times listed in
+file tmp.times:
+
+.. code-block:: LAMMPS
+
+   variable        f file tmp.times
+   variable        s equal next(f)
+   dump            1 all atom 100 tmp.dump
+   dump_modify     1 every/time v_s
+
+.. note::
+
+   When using a file-style variable with the *every/time* keyword, the
+   file of timesteps must list a first time that is beyond the time
+   associated with the current timestep (e.g. it cannot be 0.0).  And
+   it must list one or more times beyond the length of the run you
+   perform.  This is because the dump command will generate an error
+   if the next time it reads from the file is not a value greater than
+   the current time.  Thus if you wanted output at times 0,15,100 of a
+   run of length 100 in simulation time, the file should contain the
+   values 15,100,101 and you should also use the dump_modify first
+   command.  Any final value > 100 could be used in place of 101.
+
+----------
+
 The *first* keyword determines whether a dump snapshot is written on
 the very first timestep after the dump command is invoked.  This will
-always occur if the current timestep is a multiple of N, the frequency
-specified in the :doc:`dump <dump>` command, including timestep 0.  But
-if this is not the case, a dump snapshot will only be written if the
-setting of this keyword is *yes*\ .  If it is *no*, which is the
+always occur if the current timestep is a multiple of $N$, the
+frequency specified in the :doc:`dump <dump>` command or
+:doc:`dump_modify every <dump_modify>` command, including timestep 0.
+It will also always occur if the current simulation time is a multiple
+of *Delta*, the time interval specified in the doc:`dump_modify
+every/time <dump_modify>` command.
+
+But if this is not the case, a dump snapshot will only be written if
+the setting of this keyword is *yes*\ .  If it is *no*, which is the
 default, then it will not be written.
 
+Note that if the argument to the :doc:`dump_modify every
+<dump_modify>` doc:`dump_modify every/time <dump_modify>` commands is
+a variable and not a numeric value, then specifying *first yes* is the
+only way to write a dump snapshot on the first timestep after the dump
+command is invoked.
+
 ----------
 
 The *flush* keyword determines whether a flush operation is invoked
@@ -380,6 +444,13 @@ The *fileper* keyword is documented below with the *nfile* keyword.
 
 ----------
 
+The *header* keyword toggles whether the dump file will include a
+header.  Excluding a header will reduce the size of the dump file for
+fixes such as :doc:`fix pair/tracker <fix_pair_tracker>` which do not
+require the information typically written to the header.
+
+----------
+
 The *image* keyword applies only to the dump *atom* style.  If the
 image value is *yes*, 3 flags are appended to each atom's coords which
 are the absolute box image of the atom in each dimension.  For
@@ -592,9 +663,19 @@ The dump *local* style cannot be sorted by atom ID, since there are
 typically multiple lines of output per atom.  Some dump styles, such
 as *dcd* and *xtc*, require sorting by atom ID to format the output
 file correctly.  If multiple processors are writing the dump file, via
-the "%" wildcard in the dump filename, then sorting cannot be
+the "%" wildcard in the dump filename and the *nfile* or *fileper*
+keywords are set to non-default values (i.e. the number of dump file
+pieces is not equal to the number of procs), then sorting cannot be
 performed.
 
+In a parallel run, the per-processor dump file pieces can have
+significant imbalance in number of lines of per-atom info. The *balance*
+keyword determines whether the number of lines in each processor
+snapshot are balanced to be nearly the same. A balance value of *no*
+means no balancing will be done, while *yes* means balancing will be
+performed. This balancing preserves dump sorting order. For a serial
+run, this option is ignored since the output is already balanced.
+
 .. note::
 
    Unless it is required by the dump style, sorting dump file
@@ -670,16 +751,20 @@ threshold criterion is met.  Otherwise it is not met.
 
 ----------
 
-The *time* keyword only applies to the dump *atom*, *custom*, and
-*local* styles (and their COMPRESS package versions *atom/gz*,
-*custom/gz* and *local/gz*\ ). If set to *yes*, each frame will will
-contain two extra lines before the "ITEM: TIMESTEP" entry:
+The *time* keyword only applies to the dump *atom*, *custom*, *local*,
+and *xyz* styles (and their COMPRESS package versions *atom/gz*,
+*custom/gz* and *local/gz*\ ).  For the first 3 styles, if set to
+*yes*, each frame will will contain two extra lines before the "ITEM:
+TIMESTEP" entry:
 
 .. parsed-literal::
 
    ITEM: TIME
    \<elapsed time\>
 
+For the *xyz* style, the simulation time is included on the same line
+as the timestep value.
+
 This will output the current elapsed simulation time in current
 time units equivalent to the :doc:`thermo keyword <thermo_style>` *time*\ .
 This is to simplify post-processing of trajectories using a variable time
@@ -715,303 +800,35 @@ box size stored with the snapshot.
 
 ----------
 
-These keywords apply only to the :doc:`dump image <dump_image>` and
-:doc:`dump movie <dump_image>` styles.  Any keyword that affects an
-image, also affects a movie, since the movie is simply a collection of
-images.  Some of the keywords only affect the :doc:`dump movie <dump_image>` style.  The descriptions give details.
+The COMPRESS package offers both GZ and Zstd compression variants of
+styles atom, custom, local, cfg, and xyz. When using these styles the
+compression level can be controlled by the :code:`compression_level`
+keyword. File names with these styles have to end in either
+:code:`.gz` or :code:`.zst`.
 
-----------
-
-The *acolor* keyword can be used with the :doc:`dump image <dump_image>`
-command, when its atom color setting is *type*, to set the color that
-atoms of each type will be drawn in the image.
-
-The specified *type* should be an integer from 1 to Ntypes = the
-number of atom types.  A wildcard asterisk can be used in place of or
-in conjunction with the *type* argument to specify a range of atom
-types.  This takes the form "\*" or "\*n" or "n\*" or "m\*n".  If N = the
-number of atom 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).
-
-The specified *color* can be a single color which is any of the 140
-pre-defined colors (see below) or a color name defined by the
-dump_modify color option.  Or it can be two or more colors separated
-by a "/" character, e.g. red/green/blue.  In the former case, that
-color is assigned to all the specified atom types.  In the latter
-case, the list of colors are assigned in a round-robin fashion to each
-of the specified atom types.
-
-----------
-
-The *adiam* keyword can be used with the :doc:`dump image <dump_image>`
-command, when its atom diameter setting is *type*, to set the size
-that atoms of each type will be drawn in the image.  The specified
-*type* should be an integer from 1 to Ntypes.  As with the *acolor*
-keyword, a wildcard asterisk can be used as part of the *type*
-argument to specify a range of atom types.  The specified *diam* is
-the size in whatever distance :doc:`units <units>` the input script is
-using, e.g. Angstroms.
-
-----------
-
-The *amap* keyword can be used with the :doc:`dump image <dump_image>`
-command, with its *atom* keyword, when its atom setting is an
-atom-attribute, to setup a color map.  The color map is used to assign
-a specific RGB (red/green/blue) color value to an individual atom when
-it is drawn, based on the atom's attribute, which is a numeric value,
-e.g. its x-component of velocity if the atom-attribute "vx" was
-specified.
-
-The basic idea of a color map is that the atom-attribute will be
-within a range of values, and that range is associated with a series
-of colors (e.g. red, blue, green).  An atom's specific value (vx =
--3.2) can then mapped to the series of colors (e.g. halfway between
-red and blue), and a specific color is determined via an interpolation
-procedure.
-
-There are many possible options for the color map, enabled by the
-*amap* keyword.  Here are the details.
-
-The *lo* and *hi* settings determine the range of values allowed for
-the atom attribute.  If numeric values are used for *lo* and/or *hi*,
-then values that are lower/higher than that value are set to the
-value.  I.e. the range is static.  If *lo* is specified as *min* or
-*hi* as *max* then the range is dynamic, and the lower and/or
-upper bound will be calculated each time an image is drawn, based
-on the set of atoms being visualized.
-
-The *style* setting is two letters, such as "ca".  The first letter is
-either "c" for continuous, "d" for discrete, or "s" for sequential.
-The second letter is either "a" for absolute, or "f" for fractional.
-
-A continuous color map is one in which the color changes continuously
-from value to value within the range.  A discrete color map is one in
-which discrete colors are assigned to sub-ranges of values within the
-range.  A sequential color map is one in which discrete colors are
-assigned to a sequence of sub-ranges of values covering the entire
-range.
-
-An absolute color map is one in which the values to which colors are
-assigned are specified explicitly as values within the range.  A
-fractional color map is one in which the values to which colors are
-assigned are specified as a fractional portion of the range.  For
-example if the range is from -10.0 to 10.0, and the color red is to be
-assigned to atoms with a value of 5.0, then for an absolute color map
-the number 5.0 would be used.  But for a fractional map, the number
-0.75 would be used since 5.0 is 3/4 of the way from -10.0 to 10.0.
-
-The *delta* setting must be specified for all styles, but is only used
-for the sequential style; otherwise the value is ignored.  It
-specifies the bin size to use within the range for assigning
-consecutive colors to.  For example, if the range is from -10.0 to
-10.0 and a *delta* of 1.0 is used, then 20 colors will be assigned to
-the range.  The first will be from -10.0 <= color1 < -9.0, then second
-from -9.0 <= color2 < -8.0, etc.
-
-The *N* setting is how many entries follow.  The format of the entries
-depends on whether the color map style is continuous, discrete or
-sequential.  In all cases the *color* setting can be any of the 140
-pre-defined colors (see below) or a color name defined by the
-dump_modify color option.
-
-For continuous color maps, each entry has a *value* and a *color*\ .
-The *value* is either a number within the range of values or *min* or
-*max*\ .  The *value* of the first entry must be *min* and the *value*
-of the last entry must be *max*\ .  Any entries in between must have
-increasing values.  Note that numeric values can be specified either
-as absolute numbers or as fractions (0.0 to 1.0) of the range,
-depending on the "a" or "f" in the style setting for the color map.
-
-Here is how the entries are used to determine the color of an
-individual atom, given the value X of its atom attribute.  X will fall
-between 2 of the entry values.  The color of the atom is linearly
-interpolated (in each of the RGB values) between the 2 colors
-associated with those entries.  For example, if X = -5.0 and the 2
-surrounding entries are "red" at -10.0 and "blue" at 0.0, then the
-atom's color will be halfway between "red" and "blue", which happens
-to be "purple".
-
-For discrete color maps, each entry has a *lo* and *hi* value and a
-*color*\ .  The *lo* and *hi* settings are either numbers within the
-range of values or *lo* can be *min* or *hi* can be *max*\ .  The *lo*
-and *hi* settings of the last entry must be *min* and *max*\ .  Other
-entries can have any *lo* and *hi* values and the sub-ranges of
-different values can overlap.  Note that numeric *lo* and *hi* values
-can be specified either as absolute numbers or as fractions (0.0 to
-1.0) of the range, depending on the "a" or "f" in the style setting
-for the color map.
-
-Here is how the entries are used to determine the color of an
-individual atom, given the value X of its atom attribute.  The entries
-are scanned from first to last.  The first time that *lo* <= X <=
-*hi*, X is assigned the color associated with that entry.  You can
-think of the last entry as assigning a default color (since it will
-always be matched by X), and the earlier entries as colors that
-override the default.  Also note that no interpolation of a color RGB
-is done.  All atoms will be drawn with one of the colors in the list
-of entries.
-
-For sequential color maps, each entry has only a *color*\ .  Here is how
-the entries are used to determine the color of an individual atom,
-given the value X of its atom attribute.  The range is partitioned
-into N bins of width *binsize*\ .  Thus X will fall in a specific bin
-from 1 to N, say the Mth bin.  If it falls on a boundary between 2
-bins, it is considered to be in the higher of the 2 bins.  Each bin is
-assigned a color from the E entries.  If E < N, then the colors are
-repeated.  For example if 2 entries with colors red and green are
-specified, then the odd numbered bins will be red and the even bins
-green.  The color of the atom is the color of its bin.  Note that the
-sequential color map is really a shorthand way of defining a discrete
-color map without having to specify where all the bin boundaries are.
-
-Here is an example of using a sequential color map to color all the
-atoms in individual molecules with a different color.  See the
-examples/pour/in.pour.2d.molecule input script for an example of how
-this is used.
-
-.. code-block:: LAMMPS
-
-   variable        colors string &
-                   "red green blue yellow white &
-                   purple pink orange lime gray"
-   variable        mol atom mol%10
-   dump            1 all image 250 image.*.jpg v_mol type &
-                   zoom 1.6 adiam 1.5
-   dump_modify     1 pad 5 amap 0 10 sa 1 10 ${colors}
-
-In this case, 10 colors are defined, and molecule IDs are
-mapped to one of the colors, even if there are 1000s of molecules.
-
-----------
-
-The *backcolor* sets the background color of the images.  The color
-name can be any of the 140 pre-defined colors (see below) or a color
-name defined by the dump_modify color option.
-
-----------
-
-The *bcolor* keyword can be used with the :doc:`dump image <dump_image>`
-command, with its *bond* keyword, when its color setting is *type*, to
-set the color that bonds of each type will be drawn in the image.
-
-The specified *type* should be an integer from 1 to Nbondtypes = the
-number of bond types.  A wildcard asterisk can be used in place of or
-in conjunction with the *type* argument to specify a range of 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 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).
-
-The specified *color* can be a single color which is any of the 140
-pre-defined colors (see below) or a color name defined by the
-dump_modify color option.  Or it can be two or more colors separated
-by a "/" character, e.g. red/green/blue.  In the former case, that
-color is assigned to all the specified bond types.  In the latter
-case, the list of colors are assigned in a round-robin fashion to each
-of the specified bond types.
-
-----------
-
-The *bdiam* keyword can be used with the :doc:`dump image <dump_image>`
-command, with its *bond* keyword, when its diam setting is *type*, to
-set the diameter that bonds of each type will be drawn in the image.
-The specified *type* should be an integer from 1 to Nbondtypes.  As
-with the *bcolor* keyword, a wildcard asterisk can be used as part of
-the *type* argument to specify a range of bond types.  The specified
-*diam* is the size in whatever distance :doc:`units <units>` you are
-using, e.g. Angstroms.
-
-----------
-
-The *bitrate* keyword can be used with the :doc:`dump movie <dump_image>` command to define the size of the resulting
-movie file and its quality via setting how many kbits per second are
-to be used for the movie file. Higher bitrates require less
-compression and will result in higher quality movies.  The quality is
-also determined by the compression format and encoder.  The default
-setting is 2000 kbit/s, which will result in average quality with
-older compression formats.
-
-.. note::
-
-   Not all movie file formats supported by dump movie allow the
-   bitrate to be set.  If not, the setting is silently ignored.
-
-----------
-
-The *boxcolor* keyword sets the color of the simulation box drawn
-around the atoms in each image as well as the color of processor
-sub-domain boundaries.  See the "dump image box" command for how to
-specify that a box be drawn via the *box* keyword, and the sub-domain
-boundaries via the *subbox* keyword.  The color name can be any of the
-140 pre-defined colors (see below) or a color name defined by the
-dump_modify color option.
-
-----------
-
-The *color* keyword allows definition of a new color name, in addition
-to the 140-predefined colors (see below), and associates 3
-red/green/blue RGB values with that color name.  The color name can
-then be used with any other dump_modify keyword that takes a color
-name as a value.  The RGB values should each be floating point values
-between 0.0 and 1.0 inclusive.
-
-When a color name is converted to RGB values, the user-defined color
-names are searched first, then the 140 pre-defined color names.  This
-means you can also use the *color* keyword to overwrite one of the
-pre-defined color names with new RBG values.
-
-----------
-
-The *framerate* keyword can be used with the :doc:`dump movie <dump_image>` command to define the duration of the resulting
-movie file.  Movie files written by the dump *movie* command have a
-default frame rate of 24 frames per second and the images generated
-will be converted at that rate.  Thus a sequence of 1000 dump images
-will result in a movie of about 42 seconds.  To make a movie run
-longer you can either generate images more frequently or lower the
-frame rate.  To speed a movie up, you can do the inverse.  Using a
-frame rate higher than 24 is not recommended, as it will result in
-simply dropping the rendered images. It is more efficient to dump
-images less frequently.
-
-----------
-
-The *header* keyword toggles whether the dump file will include a header.
-Excluding a header will reduce the size of the dump file for fixes such as
-:doc:`fix pair/tracker <fix_pair_tracker>` which do not require the information
-typically written to the header.
-
-----------
-
-The COMPRESS package offers both GZ and Zstd compression variants of styles
-atom, custom, local, cfg, and xyz. When using these styles the compression
-level can be controlled by the :code:`compression_level` parameter. File names
-with these styles have to end in either :code:`.gz` or :code:`.zst`.
-
-GZ supports compression levels from -1 (default), 0 (no compression), and 1 to
-9. 9 being the best compression. The COMPRESS :code:`/gz` styles use 9 as
-default compression level.
+GZ supports compression levels from -1 (default), 0 (no compression),
+and 1 to
+9. 9 being the best compression. The COMPRESS :code:`/gz` styles use 9
+as default compression level.
 
 Zstd offers a wider range of compression levels, including negative
-levels that sacrifice compression for performance. 0 is the
-default, positive levels are 1 to 22, with 22 being the most expensive
+levels that sacrifice compression for performance. 0 is the default,
+positive levels are 1 to 22, with 22 being the most expensive
 compression. Zstd promises higher compression/decompression speeds for
 similar compression ratios. For more details see
 `http://facebook.github.io/zstd/`.
 
-In addition, Zstd compressed files can have a checksum of the entire
-contents. The Zstd enabled dump styles enable this feature by default and it
-can be disabled with the :code:`checksum` parameter.
+In addition, Zstd compressed files can include a checksum of the
+entire contents. The Zstd enabled dump styles enable this feature by
+default and it can be disabled with the :code:`checksum` keyword.
 
 ----------
 
 Restrictions
 """"""""""""
- none
+
+Not all *dump_modify* options can be applied to all dump styles.
+Details are in the discussions of the individual options.
 
 Related commands
 """"""""""""""""
@@ -1024,6 +841,7 @@ Default
 The option defaults are
 
 * append = no
+* balance = no
 * buffer = yes for dump styles *atom*, *custom*, *loca*, and *xyz*
 * element = "C" for every atom type
 * every = whatever it was set to via the :doc:`dump <dump>` command
@@ -1046,100 +864,7 @@ The option defaults are
 * units = no
 * unwrap = no
 
-* acolor = \* red/green/blue/yellow/aqua/cyan
-* adiam = \* 1.0
-* amap = min max cf 0.0 2 min blue max red
-* backcolor = black
-* bcolor = \* red/green/blue/yellow/aqua/cyan
-* bdiam = \* 0.5
-* bitrate = 2000
-* boxcolor = yellow
-* color = 140 color names are pre-defined as listed below
-* framerate = 24
-
 * compression_level = 9 (gz variants)
 * compression_level = 0 (zstd variants)
 * checksum = yes (zstd variants)
 
-----------
-
-These are the standard 109 element names that LAMMPS pre-defines for
-use with the :doc:`dump image <dump_image>` and dump_modify commands.
-
-* 1-10 = "H", "He", "Li", "Be", "B", "C", "N", "O", "F", "Ne"
-* 11-20 = "Na", "Mg", "Al", "Si", "P", "S", "Cl", "Ar", "K", "Ca"
-* 21-30 = "Sc", "Ti", "V", "Cr", "Mn", "Fe", "Co", "Ni", "Cu", "Zn"
-* 31-40 = "Ga", "Ge", "As", "Se", "Br", "Kr", "Rb", "Sr", "Y", "Zr"
-* 41-50 = "Nb", "Mo", "Tc", "Ru", "Rh", "Pd", "Ag", "Cd", "In", "Sn"
-* 51-60 = "Sb", "Te", "I", "Xe", "Cs", "Ba", "La", "Ce", "Pr", "Nd"
-* 61-70 = "Pm", "Sm", "Eu", "Gd", "Tb", "Dy", "Ho", "Er", "Tm", "Yb"
-* 71-80 = "Lu", "Hf", "Ta", "W", "Re", "Os", "Ir", "Pt", "Au", "Hg"
-* 81-90 = "Tl", "Pb", "Bi", "Po", "At", "Rn", "Fr", "Ra", "Ac", "Th"
-* 91-100 = "Pa", "U", "Np", "Pu", "Am", "Cm", "Bk", "Cf", "Es", "Fm"
-* 101-109 = "Md", "No", "Lr", "Rf", "Db", "Sg", "Bh", "Hs", "Mt"
-
-----------
-
-These are the 140 colors that LAMMPS pre-defines for use with the
-:doc:`dump image <dump_image>` and dump_modify commands.  Additional
-colors can be defined with the dump_modify color command.  The 3
-numbers listed for each name are the RGB (red/green/blue) values.
-Divide each value by 255 to get the equivalent 0.0 to 1.0 value.
-
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| aliceblue = 240, 248, 255     | antiquewhite = 250, 235, 215         | aqua = 0, 255, 255              | aquamarine = 127, 255, 212     | azure = 240, 255, 255          |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| beige = 245, 245, 220         | bisque = 255, 228, 196               | black = 0, 0, 0                 | blanchedalmond = 255, 255, 205 | blue = 0, 0, 255               |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| blueviolet = 138, 43, 226     | brown = 165, 42, 42                  | burlywood = 222, 184, 135       | cadetblue = 95, 158, 160       | chartreuse = 127, 255, 0       |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| chocolate = 210, 105, 30      | coral = 255, 127, 80                 | cornflowerblue = 100, 149, 237  | cornsilk = 255, 248, 220       | crimson = 220, 20, 60          |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| cyan = 0, 255, 255            | darkblue = 0, 0, 139                 | darkcyan = 0, 139, 139          | darkgoldenrod = 184, 134, 11   | darkgray = 169, 169, 169       |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| darkgreen = 0, 100, 0         | darkkhaki = 189, 183, 107            | darkmagenta = 139, 0, 139       | darkolivegreen = 85, 107, 47   | darkorange = 255, 140, 0       |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| darkorchid = 153, 50, 204     | darkred = 139, 0, 0                  | darksalmon = 233, 150, 122      | darkseagreen = 143, 188, 143   | darkslateblue = 72, 61, 139    |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| darkslategray = 47, 79, 79    | darkturquoise = 0, 206, 209          | darkviolet = 148, 0, 211        | deeppink = 255, 20, 147        | deepskyblue = 0, 191, 255      |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| dimgray = 105, 105, 105       | dodgerblue = 30, 144, 255            | firebrick = 178, 34, 34         | floralwhite = 255, 250, 240    | forestgreen = 34, 139, 34      |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| fuchsia = 255, 0, 255         | gainsboro = 220, 220, 220            | ghostwhite = 248, 248, 255      | gold = 255, 215, 0             | goldenrod = 218, 165, 32       |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| gray = 128, 128, 128          | green = 0, 128, 0                    | greenyellow = 173, 255, 47      | honeydew = 240, 255, 240       | hotpink = 255, 105, 180        |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| indianred = 205, 92, 92       | indigo = 75, 0, 130                  | ivory = 255, 240, 240           | khaki = 240, 230, 140          | lavender = 230, 230, 250       |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| lavenderblush = 255, 240, 245 | lawngreen = 124, 252, 0              | lemonchiffon = 255, 250, 205    | lightblue = 173, 216, 230      | lightcoral = 240, 128, 128     |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| lightcyan = 224, 255, 255     | lightgoldenrodyellow = 250, 250, 210 | lightgreen = 144, 238, 144      | lightgrey = 211, 211, 211      | lightpink = 255, 182, 193      |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| lightsalmon = 255, 160, 122   | lightseagreen = 32, 178, 170         | lightskyblue = 135, 206, 250    | lightslategray = 119, 136, 153 | lightsteelblue = 176, 196, 222 |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| lightyellow = 255, 255, 224   | lime = 0, 255, 0                     | limegreen = 50, 205, 50         | linen = 250, 240, 230          | magenta = 255, 0, 255          |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| maroon = 128, 0, 0            | mediumaquamarine = 102, 205, 170     | mediumblue = 0, 0, 205          | mediumorchid = 186, 85, 211    | mediumpurple = 147, 112, 219   |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| mediumseagreen = 60, 179, 113 | mediumslateblue = 123, 104, 238      | mediumspringgreen = 0, 250, 154 | mediumturquoise = 72, 209, 204 | mediumvioletred = 199, 21, 133 |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| midnightblue = 25, 25, 112    | mintcream = 245, 255, 250            | mistyrose = 255, 228, 225       | moccasin = 255, 228, 181       | navajowhite = 255, 222, 173    |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| navy = 0, 0, 128              | oldlace = 253, 245, 230              | olive = 128, 128, 0             | olivedrab = 107, 142, 35       | orange = 255, 165, 0           |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| orangered = 255, 69, 0        | orchid = 218, 112, 214               | palegoldenrod = 238, 232, 170   | palegreen = 152, 251, 152      | paleturquoise = 175, 238, 238  |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| palevioletred = 219, 112, 147 | papayawhip = 255, 239, 213           | peachpuff = 255, 239, 213       | peru = 205, 133, 63            | pink = 255, 192, 203           |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| plum = 221, 160, 221          | powderblue = 176, 224, 230           | purple = 128, 0, 128            | red = 255, 0, 0                | rosybrown = 188, 143, 143      |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| royalblue = 65, 105, 225      | saddlebrown = 139, 69, 19            | salmon = 250, 128, 114          | sandybrown = 244, 164, 96      | seagreen = 46, 139, 87         |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| seashell = 255, 245, 238      | sienna = 160, 82, 45                 | silver = 192, 192, 192          | skyblue = 135, 206, 235        | slateblue = 106, 90, 205       |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| slategray = 112, 128, 144     | snow = 255, 250, 250                 | springgreen = 0, 255, 127       | steelblue = 70, 130, 180       | tan = 210, 180, 140            |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| teal = 0, 128, 128            | thistle = 216, 191, 216              | tomato = 253, 99, 71            | turquoise = 64, 224, 208       | violet = 238, 130, 238         |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| wheat = 245, 222, 179         | white = 255, 255, 255                | whitesmoke = 245, 245, 245      | yellow = 255, 255, 0           | yellowgreen = 154, 205, 50     |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+

doc/src/dynamical_matrix.rst

@@ -1,8 +1,11 @@
 .. index:: dynamical_matrix
+.. index:: dynamical_matrix/kk
 
 dynamical_matrix command
 ========================
 
+Accelerator Variants: dynamical_matrix/kk
+
 Syntax
 """"""
 
@@ -56,6 +59,12 @@ If the style eskm is selected, the dynamical matrix will be in units of
 inverse squared femtoseconds. These units will then conveniently leave
 frequencies in THz.
 
+----------
+
+.. include:: accel_styles.rst
+
+----------
+
 Restrictions
 """"""""""""
 

doc/src/fix.rst

@@ -198,6 +198,7 @@ accelerated styles exist.
 * :doc:`cmap <fix_cmap>` - enables CMAP cross-terms of the CHARMM force field
 * :doc:`colvars <fix_colvars>` - interface to the collective variables "Colvars" library
 * :doc:`controller <fix_controller>` - apply control loop feedback mechanism
+* :doc:`damping/cundall <fix_damping_cundall>` - Cundall non-viscous damping for granular simulations
 * :doc:`deform <fix_deform>` - change the simulation box size/shape
 * :doc:`deposit <fix_deposit>` - add new atoms above a surface
 * :doc:`dpd/energy <fix_dpd_energy>` - constant energy dissipative particle dynamics
@@ -240,8 +241,6 @@ accelerated styles exist.
 * :doc:`latte <fix_latte>` - wrapper on LATTE density-functional tight-binding code
 * :doc:`lb/fluid <fix_lb_fluid>` -
 * :doc:`lb/momentum <fix_lb_momentum>` -
-* :doc:`lb/pc <fix_lb_pc>` -
-* :doc:`lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>` -
 * :doc:`lb/viscous <fix_lb_viscous>` -
 * :doc:`lineforce <fix_lineforce>` - constrain atoms to move in a line
 * :doc:`manifoldforce <fix_manifoldforce>` - restrain atoms to a manifold during minimization
@@ -271,7 +270,8 @@ accelerated styles exist.
 * :doc:`npt/eff <fix_nh_eff>` - NPT for  nuclei and electrons in the electron force field model
 * :doc:`npt/sphere <fix_npt_sphere>` - NPT for spherical particles
 * :doc:`npt/uef <fix_nh_uef>` - NPT style time integration with diagonal flow
-* :doc:`numdiff <fix_numdiff>` - compute derivatives of per-atom data from finite differences
+* :doc:`numdiff <fix_numdiff>` - numerically approximate atomic forces using finite energy differences
+* :doc:`numdiff/virial <fix_numdiff_virial>` - numerically approximate virial stress tensor using finite energy differences
 * :doc:`nve <fix_nve>` - constant NVE time integration
 * :doc:`nve/asphere <fix_nve_asphere>` - NVE for aspherical particles
 * :doc:`nve/asphere/noforce <fix_nve_asphere_noforce>` - NVE for aspherical particles without forces
@@ -387,6 +387,7 @@ accelerated styles exist.
 * :doc:`vector <fix_vector>` - accumulate a global vector every N timesteps
 * :doc:`viscosity <fix_viscosity>` - Muller-Plathe momentum exchange for viscosity calculation
 * :doc:`viscous <fix_viscous>` - viscous damping for granular simulations
+* :doc:`viscous/sphere <fix_viscous_sphere>` - viscous damping on angular velocity for granular simulations
 * :doc:`wall/body/polygon <fix_wall_body_polygon>` -
 * :doc:`wall/body/polyhedron <fix_wall_body_polyhedron>` -
 * :doc:`wall/colloid <fix_wall>` - Lennard-Jones wall interacting with finite-size particles

doc/src/fix_addtorque.rst

@@ -99,7 +99,7 @@ invoked by the :doc:`minimize <minimize>` command.
 Restrictions
 """"""""""""
 
-This fix is part of the MISC package.  It is only enabled if
+This fix is part of the EXTRA-FIX package.  It is only enabled if
 LAMMPS was built with that package.  See the :doc:`Build package
 <Build_package>` page for more info.
 

doc/src/fix_atc.rst

@@ -266,50 +266,50 @@ For detailed exposition of the theory and algorithms please see:
 .. _Wagner:
 
 **(Wagner)** Wagner, GJ; Jones, RE; Templeton, JA; Parks, MA, "An
- atomistic-to-continuum coupling method for heat transfer in solids."
- Special Issue of Computer Methods and Applied Mechanics (2008)
- 197:3351.
+atomistic-to-continuum coupling method for heat transfer in solids."
+Special Issue of Computer Methods and Applied Mechanics (2008)
+197:3351.
 
 .. _Zimmeman2004:
 
 **(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.
+Klein, PA; Bammann, DJ, "Calculation of stress in atomistic
+simulation." Special Issue of Modelling and Simulation in Materials
+Science and Engineering (2004), 12:S319.
 
 .. _Zimmerman2010:
 
 **(Zimmerman2010)** Zimmerman, JA; Jones, RE; Templeton, JA, "A
- material frame approach for evaluating continuum variables in
- atomistic simulations." Journal of Computational Physics (2010),
- 229:2364.
+material frame approach for evaluating continuum variables in
+atomistic simulations." Journal of Computational Physics (2010),
+229:2364.
 
 .. _Templeton2010:
 
 **(Templeton2010)** Templeton, JA; Jones, RE; Wagner, GJ, "Application
- of a field-based method to spatially varying thermal transport
- problems in molecular dynamics." Modelling and Simulation in
- Materials Science and Engineering (2010), 18:085007.
+of a field-based method to spatially varying thermal transport
+problems in molecular dynamics." Modelling and Simulation in
+Materials Science and Engineering (2010), 18:085007.
 
 .. _Jones:
 
 **(Jones)** Jones, RE; Templeton, JA; Wagner, GJ; Olmsted, D; Modine,
- JA, "Electron transport enhanced molecular dynamics for metals and
- semi-metals." International Journal for Numerical Methods in
- Engineering (2010), 83:940.
+JA, "Electron transport enhanced molecular dynamics for metals and
+semi-metals." International Journal for Numerical Methods in
+Engineering (2010), 83:940.
 
 .. _Templeton2011:
 
 **(Templeton2011)** Templeton, JA; Jones, RE; Lee, JW; Zimmerman, JA;
- Wong, BM, "A long-range electric field solver for molecular dynamics
- based on atomistic-to-continuum modeling." Journal of Chemical Theory
- and Computation (2011), 7:1736.
+Wong, BM, "A long-range electric field solver for molecular dynamics
+based on atomistic-to-continuum modeling." Journal of Chemical Theory
+and Computation (2011), 7:1736.
 
 .. _Mandadapu:
 
 **(Mandadapu)** Mandadapu, KK; Templeton, JA; Lee, JW, "Polarization
- as a field variable from molecular dynamics simulations." Journal of
- Chemical Physics (2013), 139:054115.
+as a field variable from molecular dynamics simulations." Journal of
+Chemical Physics (2013), 139:054115.
 
 Please refer to the standard finite element (FE) texts, e.g. T.J.R
 Hughes " The finite element method ", Dover 2003, for the basics of FE

doc/src/fix_charge_regulation.rst

@@ -20,13 +20,13 @@ Syntax
 
   .. parsed-literal::
 
-     keyword = *pH*, *pKa*, *pKb*, *pIp*, *pIm*, *pKs*, *acid_type*, *base_type*, *lunit_nm*, *temp*, *tempfixid*, *nevery*, *nmc*, *xrd*, *seed*, *tag*, *group*, *onlysalt*, *pmcmoves*
+     keyword = *pH*, *pKa*, *pKb*, *pIp*, *pIm*, *pKs*, *acid_type*, *base_type*, *lunit_nm*, *temp*, *tempfixid*, *nevery*, *nmc*, *rxd*, *seed*, *tag*, *group*, *onlysalt*, *pmcmoves*
      *pH* value = pH of the solution (can be specified as an equal-style variable)
-     *pKa* value = acid dissociation constant
-     *pKb* value = base dissociation constant
-     *pIp* value = chemical potential of free cations
-     *pIm* value = chemical potential of free anions
-     *pKs* value = solution self-dissociation constant
+     *pKa* value = acid dissociation constant (in the -log10 representation)
+     *pKb* value = base dissociation constant (in the -log10 representation)
+     *pIp* value = activity (effective concentration) of free cations (in the -log10 representation)
+     *pIm* value = activity (effective concentration) of free anions (in the -log10 representation)
+     *pKs* value = solvent self-dissociation constant (in the -log10 representation)
      *acid_type* = atom type of acid groups
      *base_type*  = atom type of base groups
      *lunit_nm* value = unit length used by LAMMPS (# in the units of nanometers)
@@ -34,7 +34,7 @@ Syntax
      *tempfixid* value = fix ID of temperature thermostat
      *nevery* value = invoke this fix every nevery steps
      *nmc* value = number of charge regulation MC moves to attempt every nevery steps
-     *xrd* value = cutoff distance for acid/base reaction
+     *rxd* value = cutoff distance for acid/base reaction
      *seed* value = random # seed (positive integer)
      *tag* value = yes or no (yes: The code assign unique tags to inserted ions; no: The tag of all inserted ions is "0")
      *group* value = group-ID, inserted ions are assigned to group group-ID. Can be used multiple times to assign inserted ions to multiple groups.
@@ -47,7 +47,7 @@ Examples
 """"""""
 .. code-block:: LAMMPS
 
-    fix chareg all charge/regulation 1 2 acid_type 3 base_type 4 pKa 5 pKb 7 lb 1.0 nevery 200 nexchange 200 seed 123 tempfixid fT
+    fix chareg all charge/regulation 1 2 acid_type 3 base_type 4 pKa 5.0 pKb 6.0 pH 7.0 pIp 3.0 pIm 3.0 nevery 200 nmc 200 seed 123 tempfixid fT
 
     fix chareg all charge/regulation 1 2 pIp 3 pIm 3 onlysalt yes 2 -1 seed 123 tag yes temp 1.0
 
@@ -92,7 +92,11 @@ where the fix attempts to charge :math:`\mathrm{A}` (discharge
 :math:`\mathrm{A}^-`) to :math:`\mathrm{A}^-` (:math:`\mathrm{A}`) and
 insert (delete) a proton (atom type 2). Besides, the fix implements
 self-ionization reaction of water :math:`\emptyset \rightleftharpoons
-\mathrm{H}^++\mathrm{OH}^-`.  However, this approach is highly
+\mathrm{H}^++\mathrm{OH}^-`.
+
+
+
+However, this approach is highly
 inefficient at :math:`\mathrm{pH} \approx 7` when the concentration of
 both protons and hydroxyl ions is low, resulting in a relatively low
 acceptance rate of MC moves.
@@ -102,24 +106,31 @@ reactions, which can be easily achieved via
 
 .. code-block:: LAMMPS
 
-    fix acid_reaction all charge/regulation 4 5 acid_type 1 pH 7.0 pKa 5.0 pIp 2.0 pIm 2.0
+    fix acid_reaction2 all charge/regulation 4 5 acid_type 1 pH 7.0 pKa 5.0 pIp 2.0 pIm 2.0
 
-where particles of atom type 4 and 5 are the salt cations and anions,
-both at chemical potential pI=2.0, see :ref:`(Curk1) <Curk1>` and
+where particles of atom type 4 and 5 are the salt cations and anions, both at activity (effective concentration) of :math:`10^{-2}` mol/l, see :ref:`(Curk1) <Curk1>` and
 :ref:`(Landsgesell) <Landsgesell>` for more details.
 
-
- Similarly, we could have simultaneously added a base ionization reaction
- (:math:`\mathrm{B} \rightleftharpoons \mathrm{B}^++\mathrm{OH}^-`)
+We could have simultaneously added a base ionization reaction (:math:`\mathrm{B} \rightleftharpoons \mathrm{B}^++\mathrm{OH}^-`)
 
 .. code-block:: LAMMPS
 
-    fix base_reaction all charge/regulation 2 3 base_type 6 pH 7.0 pKb 6.0 pIp 7.0 pIm 7.0
+    fix acid_base_reaction all charge/regulation 2 3 acid_type 1 base_type 6 pH 7.0 pKa 5.0 pKb 6.0 pIp 7.0 pIm 7.0
 
 where the fix will attempt to charge :math:`\mathrm{B}` (discharge
 :math:`\mathrm{B}^+`) to :math:`\mathrm{B}^+` (:math:`\mathrm{B}`) and
-insert (delete) a hydroxyl ion :math:`\mathrm{OH}^-` of atom type 3.  If
-neither the acid or the base type is specified, for example,
+insert (delete) a hydroxyl ion :math:`\mathrm{OH}^-` of atom type 3.
+
+
+Dissociated ions and salt ions can be combined into a single particle type, which reduces the number of necessary MC moves and increases sampling performance, see :ref:`(Curk1) <Curk1>`. The :math:`\mathrm{H}^+` and monovalent salt cation (:math:`\mathrm{S}^+`) are combined into a single particle type, :math:`\mathrm{X}^+ = \{\mathrm{H}^+, \mathrm{S}^+\}`. In this case "pIp" refers to the effective concentration of the combined cation type :math:`\mathrm{X}^+` and its value is determined by :math:`10^{-\mathrm{pIp}} = 10^{-\mathrm{pH}} + 10^{-\mathrm{pSp}}`, where :math:`10^{-\mathrm{pSp}}` is the effective concentration of salt cations. For example, at pH=7 and pSp=6 we would find pIp~5.958 and the command that performs reactions with combined ions could read,
+
+.. code-block:: LAMMPS
+
+    fix acid_reaction_combined all charge/regulation 2 3 acid_type 1 pH 7.0 pKa 5.0 pIp 5.958 pIm 5.958
+
+
+
+If neither the acid or the base type is specified, for example,
 
 .. code-block:: LAMMPS
 
@@ -127,11 +138,11 @@ neither the acid or the base type is specified, for example,
 
 the fix simply inserts or deletes an ion pair of a free cation (atom
 type 4) and a free anion (atom type 5) as done in a conventional
-grand-canonical MC simulation.
+grand-canonical MC simulation. Multivalent ions can be inserted (deleted) by using the *onlysalt* keyword.
 
 
 The fix is compatible with LAMMPS sub-packages such as *molecule* or
-*rigid*. That said, the acid and base particles can be part of larger
+*rigid*. The acid and base particles can be part of larger
 molecules or rigid bodies. Free ions that are inserted to or deleted
 from the system must be defined as single particles (no bonded
 interactions allowed) and cannot be part of larger molecules or rigid
@@ -153,14 +164,14 @@ Langevin thermostat:
     fix fT all langevin 1.0 1.0 1.0 123
     fix_modify fT temp dtemp
 
-The chemical potential units (e.g. pH) are in the standard log10
+The units of  pH, pKa, pKb, pIp, pIm are considered to be in the standard -log10
 representation assuming reference concentration :math:`\rho_0 =
-\mathrm{mol}/\mathrm{l}`.  Therefore, to perform the internal unit
-conversion, the length (in nanometers) of the LAMMPS unit length must be
-specified via *lunit_nm* (default is set to the Bjerrum length in water
-at room temperature *lunit_nm* = 0.71nm). For example, in the dilute
-ideal solution limit, the concentration of free ions will be
-:math:`c_\mathrm{I} = 10^{-\mathrm{pIp}}\mathrm{mol}/\mathrm{l}`.
+\mathrm{mol}/\mathrm{l}`.  For example, in the dilute
+ideal solution limit, the concentration of free cations will be
+:math:`c_\mathrm{I} = 10^{-\mathrm{pIp}}\mathrm{mol}/\mathrm{l}`. To perform the internal unit
+conversion, the the value of the LAMMPS unit length must be
+specified in nanometers via *lunit_nm*. The default value is set to the Bjerrum length in water
+at room temperature (0.71 nm), *lunit_nm* = 0.71.
 
 The temperature used in MC acceptance probability is set by *temp*. This
 temperature should be the same as the temperature set by the molecular
@@ -171,10 +182,10 @@ thermostat fix-ID is *fT*. The inserted particles attain a random
 velocity corresponding to the specified temperature. Using *tempfixid*
 overrides any fixed temperature set by *temp*.
 
-The *xrd* keyword can be used to restrict the inserted/deleted
+The *rxd* keyword can be used to restrict the inserted/deleted
 counterions to a specific radial distance from an acid or base particle
 that is currently participating in a reaction. This can be used to
-simulate more realist reaction dynamics. If *xrd* = 0 or *xrd* > *L* /
+simulate more realist reaction dynamics. If *rxd* = 0 or *rxd* > *L* /
 2, where *L* is the smallest box dimension, the radial restriction is
 automatically turned off and free ion can be inserted or deleted
 anywhere in the simulation box.
@@ -258,18 +269,18 @@ Default
 
 pH = 7.0; pKa = 100.0; pKb = 100.0; pIp = 5.0; pIm = 5.0; pKs = 14.0;
 acid_type = -1; base_type = -1; lunit_nm = 0.71; temp = 1.0; nevery =
-100; nmc = 100; xrd = 0; seed = 0; tag = no; onlysalt = no, pmcmoves =
+100; nmc = 100; rxd = 0; seed = 0; tag = no; onlysalt = no, pmcmoves =
 [1/3, 1/3, 1/3], group-ID = all
 
 ----------
 
 .. _Curk1:
 
-**(Curk1)** T. Curk, J. Yuan, and E. Luijten, "Coarse-grained simulation of charge regulation using LAMMPS", preprint (2021).
+**(Curk1)** T. Curk, J. Yuan, and E. Luijten, "Accelerated simulation method for charge regulation effects", JCP 156 (2022).
 
 .. _Curk2:
 
-**(Curk2)** T. Curk and E. Luijten, "Charge-regulation effects in nanoparticle self-assembly", PRL (2021)
+**(Curk2)** T. Curk and E. Luijten, "Charge-regulation effects in nanoparticle self-assembly", PRL 126 (2021)
 
 .. _Landsgesell:
 

doc/src/fix_damping_cundall.rst

@@ -0,0 +1,149 @@
+.. index:: fix damping/cundall
+
+fix damping/cundall command
+===========================
+
+Syntax
+""""""
+
+.. parsed-literal::
+
+   fix ID group-ID damping/cundall gamma_l gamma_a keyword values ...
+
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* damping/cundall = style name of this fix command
+* gamma_l = linear damping coefficient (dimensionless)
+* gamma_a = angular damping coefficient (dimensionless)
+* zero or more keyword/value pairs may be appended
+
+  .. parsed-literal::
+
+     keyword = *scale*
+       *scale* values = *type ratio* or *v_name*
+         type = atom type (1-N)
+         ratio = factor to scale the damping coefficients by
+         v_name = reference to atom style variable *name*
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   fix 1 all damping/cundall 0.8 0.8
+   fix 1 all damping/cundall 0.8 0.5 scale 3 2.5
+   fix a all damping/cundall 0.8 0.5 scale v_radscale
+
+Description
+"""""""""""
+
+Add damping force and torque to finite-size spherical particles in the group
+following the model of :ref:`Cundall, 1987 <Cundall1987>`, as implemented in other
+granular physics code (e.g., :ref:`Yade-DEM <YadeDEM>`, :ref:`PFC <PFC>`).
+
+The damping is constructed to always have negative mechanical power with respect
+to the current velocity/angular velocity to ensure dissipation of kinetic energy.
+If used without additional thermostatting (to add kinetic energy to the system),
+it has the effect of slowly (or rapidly) freezing the system; hence it can also
+be used as a simple energy minimization technique.
+
+The magnitude of the damping force/torque :math:`F_d`/:math:`T_d` is a fraction
+:math:`\gamma \in [0;1]` of the current force/torque :math:`F`/:math:`T` on the
+particle. Damping is applied component-by-component in each direction
+:math:`k\in\{x, y, z\}`:
+
+.. math::
+
+   {F_d}_k = - \gamma_l \, F_k \, \mathrm{sign}(F_k v_k)
+
+.. math::
+
+   {T_d}_k = - \gamma_a \, T_k \, \mathrm{sign}(T_k \omega_k)
+
+The larger the coefficients, the faster the kinetic energy is reduced.
+
+If the optional keyword *scale* is used, :math:`\gamma_l` and :math:`\gamma_a`
+can be scaled up or down by the specified factor for atoms.  This factor can be
+set for different atom types and thus the *scale* keyword used multiple times
+followed by the atom type and the associated scale factor.  Alternately the
+scaling factor can be computed for each atom (e.g. based on its radius) by
+using an :doc:`atom-style variable <variable>`.
+
+.. Note::
+
+  The damping force/torque is computed based on the force/torque at the moment
+  this fix is invoked. Any force/torque added after this fix, e.g., by
+  :doc:`fix addforce <fix_addforce>` or :doc:`fix addtorque <fix_addtorque>`
+  will not be damped. When performing simulations with gravity, invoking
+  :doc:`fix gravity <fix_gravity>` after this fix will maintain the specified
+  gravitational acceleration.
+
+.. Note::
+
+  This scheme is dependent on the coordinates system and does not correspond to
+  realistic physical processes. It is constructed for numerical convenience and
+  efficacy.
+
+This non-viscous damping presents the following advantages:
+
+1. damping is independent of velocity, equally damping regions with distinct natural frequencies,
+2. damping affects acceleration and vanishes for steady uniform motion of the particles,
+3. damping parameter :math:`\gamma` is dimensionless and does not require scaling.
+
+----------
+
+Restart, fix_modify, output, run start/stop, minimize info
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+No information about this fix is written to :doc:`binary restart files
+<restart>`.  None of the :doc:`fix_modify <fix_modify>` options are
+relevant to this fix.  No global or per-atom quantities are stored by
+this fix for access by various :doc:`output commands <Howto_output>`.
+No parameter of this fix can be used with the *start/stop* keywords of
+the :doc:`run <run>` command.
+
+The :doc:`fix_modify <fix_modify>` *respa* option is supported by this
+fix. This allows to set at which level of the :doc:`r-RESPA <run_style>`
+integrator the fix is modifying forces/torques. Default is the outermost level.
+
+The forces/torques due to this fix are imposed during an energy minimization,
+invoked by the :doc:`minimize <minimize>` command.  This fix should only
+be used with damped dynamics minimizers that allow for
+non-conservative forces.  See the :doc:`min_style <min_style>` command
+for details.
+
+Restrictions
+""""""""""""
+
+This fix is part of the GRANULAR package.  It is only enabled if
+LAMMPS was built with that package.  See the :doc:`Build package <Build_package>` page for more info.
+
+This fix requires that atoms store torque and a radius as defined by the
+:doc:`atom_style sphere <atom_style>` command.
+
+Related commands
+""""""""""""""""
+
+:doc:`fix viscous <fix_viscous>`, :doc:`fix viscous/sphere <fix_viscous_sphere>`
+
+Default
+"""""""
+
+none
+
+References
+""""""""""
+
+.. _Cundall1987:
+
+**(Cundall, 1987)** Cundall, P. A. Distinct Element Models of Rock and Soil
+Structure, in Analytical and Computational Methods in Engineering Rock
+Mechanics, Ch. 4, pp. 129-163. E. T. Brown, ed. London: Allen & Unwin., 1987.
+
+.. _PFC:
+
+**(PFC)** PFC Particle Flow Code 6.0 Documentation. Itasca Consulting Group.
+
+.. _YadeDEM:
+
+**(Yade-DEM)** V. Smilauer et al. (2021), Yade Documentation 3rd ed.
+The Yade Project. DOI:10.5281/zenodo.5705394 (https://yade-dem.org/doc/)

doc/src/fix_dt_reset.rst

@@ -78,13 +78,20 @@ outer loop (largest) timestep, which is the same timestep that the
 
 Note that the cumulative simulation time (in time units), which
 accounts for changes in the timestep size as a simulation proceeds,
-can be accessed by the :doc:`thermo_style time <thermo_style>` keyword.
+can be accessed by the :doc:`thermo_style time <thermo_style>`
+keyword.
+
+Also note that the :doc:`dump_modify every/time <dump_modify>` option
+allows dump files to be written at intervals specified by simulation
+time, rather than by timesteps.  Simulation time is in time units;
+see the :doc:`units <units>` doc page for details.
 
 Restart, fix_modify, output, run start/stop, minimize info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
-No information about this fix is written to :doc:`binary restart files <restart>`.  None of the :doc:`fix_modify <fix_modify>` options
-are relevant to this fix.
+No information about this fix is written to :doc:`binary restart files
+<restart>`.  None of the :doc:`fix_modify <fix_modify>` options are
+relevant to this fix.
 
 This fix computes a global scalar which can be accessed by various
 :doc:`output commands <Howto_output>`.  The scalar stores the last
@@ -93,7 +100,8 @@ timestep on which the timestep was reset to a new value.
 The scalar value calculated by this fix is "intensive".
 
 No parameter of this fix can be used with the *start/stop* keywords of
-the :doc:`run <run>` command.  This fix is not invoked during :doc:`energy minimization <minimize>`.
+the :doc:`run <run>` command.  This fix is not invoked during
+:doc:`energy minimization <minimize>`.
 
 Restrictions
 """"""""""""
@@ -102,7 +110,7 @@ Restrictions
 Related commands
 """"""""""""""""
 
-:doc:`timestep <timestep>`
+:doc:`timestep <timestep>`, :doc:`dump_modify every/time <dump_modify>`
 
 Default
 """""""

doc/src/fix_gcmc.rst

@@ -444,8 +444,15 @@ doc page for more info.
 Do not set "neigh_modify once yes" or else this fix will never be
 called.  Reneighboring is required.
 
+Only usable for 3D simulations.
+
 Can be run in parallel, but aspects of the GCMC part will not scale
-well in parallel. Only usable for 3D simulations.
+well in parallel. Currently, molecule translations and rotations
+are not supported with more than one MPI process.
+It is still possible to do parallel molecule exchange without
+translation and rotation moves by setting MC moves to zero
+and/or by using the *mcmoves* keyword with *Pmoltrans* = *Pmolrotate* = 0 .
+
 
 When using fix gcmc in combination with fix shake or fix rigid,
 only GCMC exchange moves are supported, so the argument

doc/src/fix_langevin_drude.rst

@@ -40,7 +40,7 @@ Example input scripts available: examples/PACKAGES/drude
 Description
 """""""""""
 
-Apply two Langevin thermostats as described in :ref:`(Jiang) <Jiang1>` for
+Apply two Langevin thermostats as described in :ref:`(Jiang1) <Jiang1>` for
 thermalizing the reduced degrees of freedom of Drude oscillators.
 This link describes how to use the :doc:`thermalized Drude oscillator model <Howto_drude>` in LAMMPS and polarizable models in LAMMPS
 are discussed on the :doc:`Howto polarizable <Howto_polarizable>` doc
@@ -300,5 +300,5 @@ The option defaults are zero = no.
 
 .. _Jiang1:
 
-**(Jiang)** Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux, J
+**(Jiang1)** Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux, J
 Phys Chem Lett, 2, 87-92 (2011).