Merge branch 'develop' into electrode

.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,22 @@ 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
+        python3 -m pip install pyyaml
         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 +40,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

.github/workflows/unittest-macos.yml

@@ -37,6 +37,7 @@ jobs:
       working-directory: build
       run: |
         ccache -z
+        python3 -m pip install pyyaml
         cmake -C ../cmake/presets/clang.cmake \
               -C ../cmake/presets/most.cmake \
               -D CMAKE_CXX_COMPILER_LAUNCHER=ccache \

.gitignore

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

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)
+# 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
+# Edited by Tzu-Ray Shan from MSE, Univ. FL in Apr 2010
-#
+#
-# Elements currently available: Si, Cu, Hf, Ti, Zr, U, O
+# Elements currently available: Si, Cu, Hf, Ti, Zr, U, O
-# Oxides   currently available: Si-O, Cu-O, Hf-O, Ti-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)
+# 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)
+# 		   ,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)
+# 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)
+# 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)
+# 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)
+# 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)
+# 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)
+# 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
+# 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
+# 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
+# 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
+# 27 entries for a system containing three elements A, B and C
-# These entries are in LAMMPS "metal" units
+# 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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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 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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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 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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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
+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 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
+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

bench/README

@@ -4,10 +4,8 @@ This directory contains 5 benchmark problems which are discussed in
 the Benchmark section of the LAMMPS documentation, and on the
 Benchmark page of the LAMMPS WWW site (https://www.lammps.org/bench.html).
 
-This directory also has several sub-directories:
+This directory also has one sub-directories:
 
-FERMI           benchmark scripts for desktop machine with Fermi GPUs (Tesla)
-KEPLER          benchmark scripts for GPU cluster with Kepler GPUs
 POTENTIALS      benchmarks scripts for various potentials in LAMMPS
 
 The results for all of these benchmarks are displayed and discussed on

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)
@@ -205,7 +209,6 @@ set(STANDARD_PACKAGES
   MDI
   MEAM
   MESONT
-  MESSAGE
   MGPT
   MISC
   ML-HDNNP
@@ -281,35 +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)
+  target_sources(lammps PRIVATE ${LAMMPS_SOURCE_DIR}/STUBS/mpi.cpp)
-  add_library(mpi_stubs STATIC ${MPI_SOURCES})
+  add_library(mpi_stubs INTERFACE)
-  set_target_properties(mpi_stubs PROPERTIES OUTPUT_NAME lammps_mpi_stubs${LAMMPS_MACHINE})
+  target_include_directories(mpi_stubs INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
-  target_include_directories(mpi_stubs PUBLIC $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
+  target_link_libraries(lammps PUBLIC mpi_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()
-    target_include_directories(lammps INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
-    target_compile_definitions(lammps INTERFACE $<INSTALL_INTERFACE:LAMMPS_LIB_NO_MPI>)
-  else()
-    target_include_directories(lammps INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
-    target_compile_definitions(lammps INTERFACE $<INSTALL_INTERFACE:LAMMPS_LIB_NO_MPI>)
-    target_link_libraries(lammps PUBLIC mpi_stubs)
-  endif()
-  add_library(MPI::MPI_CXX ALIAS 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)")
@@ -374,11 +361,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 OR PKG_ELECTRODE)
@@ -463,7 +452,7 @@ else()
 endif()
 
 foreach(PKG_WITH_INCL KSPACE PYTHON ML-IAP VORONOI COLVARS ML-HDNNP MDI MOLFILE NETCDF
-        PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM LATTE MESSAGE MSCG COMPRESS ML-PACE)
+        PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM LATTE MSCG COMPRESS ML-PACE)
   if(PKG_${PKG_WITH_INCL})
     include(Packages/${PKG_WITH_INCL})
   endif()
@@ -596,11 +585,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})
@@ -696,6 +684,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})
@@ -715,6 +704,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)
@@ -754,7 +746,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})
@@ -762,13 +754,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
+      COMMAND ${Python_EXECUTABLE} ${LAMMPS_PYTHON_DIR}/install.py -p ${LAMMPS_PYTHON_DIR}/lammps -l ${LIBLAMMPS_SHARED_BINARY}
-      -p ${LAMMPS_PYTHON_DIR}/lammps
-      -l ${CMAKE_BINARY_DIR}/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX}
-      WORKING_DIRECTORY  ${LAMMPS_PYTHON_DIR}
       COMMENT "Installing LAMMPS Python module")
   else()
     add_custom_target(
@@ -813,7 +807,6 @@ if(ClangFormat_FOUND)
 endif()
 
 get_target_property(DEFINES lammps COMPILE_DEFINITIONS)
-get_property(BUILD_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
 if(BUILD_IS_MULTI_CONFIG)
   set(LAMMPS_BUILD_TYPE "Multi-Config")
 else()
@@ -822,6 +815,7 @@ endif()
 include(FeatureSummary)
 feature_summary(DESCRIPTION "The following tools and libraries have been found and configured:" WHAT PACKAGES_FOUND)
 message(STATUS "<<< Build configuration >>>
+   LAMMPS Version:   ${PROJECT_VERSION}
    Operating System: ${CMAKE_SYSTEM_NAME} ${CMAKE_LINUX_DISTRO} ${CMAKE_DISTRO_VERSION}
    Build type:       ${LAMMPS_BUILD_TYPE}
    Install path:     ${CMAKE_INSTALL_PREFIX}

cmake/CMakeSettings.json

@@ -6,7 +6,7 @@
       "configurationType": "Debug",
       "buildRoot": "${workspaceRoot}\\build\\${name}",
       "installRoot": "${workspaceRoot}\\install\\${name}",
-      "cmakeCommandArgs": "-S ${workspaceRoot}\\cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DENABLE_TESTING=on",
+      "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
       "buildCommandArgs": "",
       "ctestCommandArgs": "",
       "inheritEnvironments": [ "msvc_x64_x64" ],
@@ -25,6 +25,54 @@
           "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"
         }
       ]
     },
@@ -34,11 +82,16 @@
       "configurationType": "Debug",
       "buildRoot": "${workspaceRoot}\\build\\${name}",
       "installRoot": "${workspaceRoot}\\install\\${name}",
-      "cmakeCommandArgs": "-S ${workspaceRoot}\\cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DENABLE_TESTING=on",
+      "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",
@@ -48,19 +101,29 @@
           "name": "LAMMPS_EXCEPTIONS",
           "value": "True",
           "type": "BOOL"
+        },
+        {
+          "name": "PKG_PYTHON",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "ENABLE_TESTING",
+          "value": "True",
+          "type": "BOOL"
         }
       ]
     },
     {
-      "name": "x64-Debug-OneAPI",
+      "name": "x64-Release-Clang",
       "generator": "Ninja",
-      "configurationType": "Debug",
+      "configurationType": "Release",
       "buildRoot": "${workspaceRoot}\\build\\${name}",
       "installRoot": "${workspaceRoot}\\install\\${name}",
-      "cmakeCommandArgs": "-S ${workspaceRoot}\\cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DENABLE_TESTING=on -DCMAKE_CXX_COMPILER=icx -DCMAKE_C_COMPILER=icx -DBUILD_MPI=off",
+      "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DCMAKE_C_COMPILER=clang-cl.exe -DCMAKE_CXX_COMPILER=clang-cl.exe",
       "buildCommandArgs": "",
       "ctestCommandArgs": "",
-      "inheritEnvironments": [ "msvc_x64_x64" ],
+      "inheritEnvironments": [ "clang_cl_x64" ],
       "variables": [
         {
           "name": "BUILD_SHARED_LIBS",
@@ -76,32 +139,14 @@
           "name": "LAMMPS_EXCEPTIONS",
           "value": "True",
           "type": "BOOL"
-        }
+        },
-      ]
-    },
-    {
-      "name": "x64-Debug-Intel",
-      "generator": "Ninja",
-      "configurationType": "Debug",
-      "buildRoot": "${workspaceRoot}\\build\\${name}",
-      "installRoot": "${workspaceRoot}\\install\\${name}",
-      "cmakeCommandArgs": "-S ${workspaceRoot}\\cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DENABLE_TESTING=off -DCMAKE_CXX_COMPILER=icl -DCMAKE_C_COMPILER=icl -DCMAKE_Fortran_COMPILER=ifort -DBUILD_MPI=off",
-      "buildCommandArgs": "",
-      "ctestCommandArgs": "",
-      "inheritEnvironments": [ "msvc_x64_x64" ],
-      "variables": [
         {
-          "name": "BUILD_SHARED_LIBS",
+          "name": "PKG_PYTHON",
           "value": "True",
           "type": "BOOL"
         },
         {
-          "name": "BUILD_TOOLS",
+          "name": "ENABLE_TESTING",
-          "value": "True",
-          "type": "BOOL"
-        },
-        {
-          "name": "LAMMPS_EXCEPTIONS",
           "value": "True",
           "type": "BOOL"
         }

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)
+if(Python_EXECUTABLE)
-  get_filename_component(_python_path ${Python3_EXECUTABLE} PATH)
+  get_filename_component(_python_path ${Python_EXECUTABLE} PATH)
   find_program(Cythonize_EXECUTABLE
     NAMES cythonize3 cythonize cythonize.bat
     HINTS ${_python_path})

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_URL "${LAMMPS_THIRDPARTY_URL}/opencl-loader-2022.01.04.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_MD5 "8d3a801e87a2c6653bf0e27707063914" CACHE STRING "MD5 checksum of OpenCL loader tarball")
 mark_as_advanced(OPENCL_LOADER_URL)
 mark_as_advanced(OPENCL_LOADER_MD5)
 
-include(ExternalProject)
+set(INSTALL_LIBOPENCL OFF CACHE BOOL "" FORCE)
-ExternalProject_Add(opencl_loader
+include(ExternalCMakeProject)
-                    URL             ${OPENCL_LOADER_URL}
+ExternalCMakeProject(opencl_loader ${OPENCL_LOADER_URL} ${OPENCL_LOADER_MD5} opencl-loader . "")
-                    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}")
-
 
+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)
+find_package(PkgConfig QUIET)
-pkg_check_modules(Zstd IMPORTED_TARGET libzstd>=1.4)
+if(PkgConfig_FOUND)
-
+  pkg_check_modules(Zstd IMPORTED_TARGET libzstd>=1.4)
-if(Zstd_FOUND)
+  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.")
@@ -339,6 +347,10 @@ elseif(GPU_API STREQUAL "HIP")
   target_link_libraries(gpu PRIVATE hip::host)
 
   if(HIP_USE_DEVICE_SORT)
+    if(HIP_PLATFORM STREQUAL "amd")
+      # newer version of ROCm (5.1+) require c++14 for rocprim
+      set_property(TARGET gpu PROPERTY CXX_STANDARD 14)
+    endif()
     # add hipCUB
     target_include_directories(gpu PRIVATE ${HIP_ROOT_DIR}/../include)
     target_compile_definitions(gpu PRIVATE -DUSE_HIP_DEVICE_SORT)
@@ -422,13 +434,12 @@ RegisterStylesExt(${GPU_SOURCES_DIR} gpu GPU_SOURCES)
 RegisterFixStyle(${GPU_SOURCES_DIR}/fix_gpu.h)
 
 get_property(GPU_SOURCES GLOBAL PROPERTY GPU_SOURCES)
-
+if(BUILD_MPI)
-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()
   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)
+if(Kokkos_ENABLE_OPENMP)
-  message(FATAL_ERROR "Must enable BUILD_OMP with 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()
@@ -47,18 +55,22 @@ if(DOWNLOAD_KOKKOS)
     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)
+  add_library(LAMMPS::KOKKOSCORE UNKNOWN IMPORTED)
-  set_target_properties(LAMMPS::KOKKOS PROPERTIES
+  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)
+  set_target_properties(LAMMPS::KOKKOSCONTAINERS PROPERTIES
-  target_link_libraries(lmp PRIVATE LAMMPS::KOKKOS)
+    IMPORTED_LOCATION "${INSTALL_DIR}/lib/libkokkoscontainers.a")
-  add_dependencies(LAMMPS::KOKKOS kokkos_build)
+  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.5.00 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
@@ -66,8 +78,17 @@ elseif(EXTERNAL_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/MDI.cmake

@@ -8,8 +8,8 @@ option(DOWNLOAD_MDI "Download and compile the MDI library instead of using an al
 
 if(DOWNLOAD_MDI)
   message(STATUS "MDI download requested - we will build our own")
-  set(MDI_URL "https://github.com/MolSSI-MDI/MDI_Library/archive/v1.2.9.tar.gz" CACHE STRING "URL for MDI tarball")
+  set(MDI_URL "https://github.com/MolSSI-MDI/MDI_Library/archive/v1.3.0.tar.gz" CACHE STRING "URL for MDI tarball")
-  set(MDI_MD5 "ddfa46d6ee15b4e59cfd527ec7212184" CACHE STRING "MD5 checksum for MDI tarball")
+  set(MDI_MD5 "8a8da217148bd9b700083b67d795af5e" CACHE STRING "MD5 checksum for MDI tarball")
   mark_as_advanced(MDI_URL)
   mark_as_advanced(MDI_MD5)
   enable_language(C)

cmake/Modules/Packages/MESSAGE.cmake

@@ -1,31 +0,0 @@
-if(LAMMPS_SIZES STREQUAL "BIGBIG")
-  message(FATAL_ERROR "The MESSAGE Package is not compatible with -DLAMMPS_BIGBIG")
-endif()
-option(MESSAGE_ZMQ "Use ZeroMQ in MESSAGE package" OFF)
-file(GLOB_RECURSE cslib_SOURCES
-        ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/[^.]*.cpp)
-
-add_library(cslib STATIC ${cslib_SOURCES})
-target_compile_definitions(cslib PRIVATE -DLAMMPS_${LAMMPS_SIZES})
-set_target_properties(cslib PROPERTIES OUTPUT_NAME lammps_cslib${LAMMPS_MACHINE})
-if(BUILD_MPI)
-  target_compile_definitions(cslib PRIVATE -DMPI_YES)
-  set_target_properties(cslib PROPERTIES OUTPUT_NAME "csmpi")
-  target_link_libraries(cslib PRIVATE MPI::MPI_CXX)
-else()
-  target_compile_definitions(cslib PRIVATE -DMPI_NO)
-  target_include_directories(cslib PRIVATE ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/src/STUBS_MPI)
-  set_target_properties(cslib PROPERTIES OUTPUT_NAME "csnompi")
-endif()
-
-if(MESSAGE_ZMQ)
-  target_compile_definitions(cslib PRIVATE -DZMQ_YES)
-  find_package(ZMQ REQUIRED)
-  target_link_libraries(cslib PUBLIC ZMQ::ZMQ)
-else()
-  target_compile_definitions(cslib PRIVATE -DZMQ_NO)
-  target_include_directories(cslib PRIVATE ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/src/STUBS_ZMQ)
-endif()
-
-target_link_libraries(lammps PRIVATE cslib)
-target_include_directories(lammps PRIVATE ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/src)

cmake/Modules/Packages/ML-HDNNP.cmake

@@ -42,17 +42,9 @@ if(DOWNLOAD_N2P2)
   if(NOT BUILD_MPI)
     set(N2P2_PROJECT_OPTIONS "-DN2P2_NO_MPI")
   else()
-    # get path to MPI include directory when cross-compiling to windows
+    # get path to MPI include directory
-    if((CMAKE_SYSTEM_NAME STREQUAL Windows) AND CMAKE_CROSSCOMPILING)
+    get_target_property(N2P2_MPI_INCLUDE MPI::MPI_CXX INTERFACE_INCLUDE_DIRECTORIES)
-      get_target_property(N2P2_MPI_INCLUDE MPI::MPI_CXX INTERFACE_INCLUDE_DIRECTORIES)
+    set(N2P2_PROJECT_OPTIONS "-I${N2P2_MPI_INCLUDE}")
-      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()
 
   # prefer GNU make, if available. N2P2 lib seems to need it.
@@ -64,8 +56,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_CC=${CMAKE_CXX_COMPILER}" "PROJECT_MPICC=${CMAKE_CXX_COMPILER}" "PROJECT_CFLAGS=${N2P2_BUILD_FLAGS}"
-    "PROJECT_AR=${N2P2_AR}")
+    "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

@@ -51,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/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.3/plumed-src-2.7.3.tgz" CACHE STRING "URL for 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 "f00cc82edfefe6bb3df934911dbe32fb" CACHE STRING "MD5 checksum of 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/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}bool LAMMPS_NS::LAMMPS::has_git_info() { return ${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_commit() { return \"${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_branch() { return \"${temp_git_branch}\"; }\n")
-set(temp "${temp}const char LAMMPS_NS::LAMMPS::git_descriptor[] = \"${temp_git_describe}\";\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/all_off.cmake

@@ -48,7 +48,6 @@ set(ALL_PACKAGES
   MDI
   MEAM
   MESONT
-  MESSAGE
   MGPT
   MISC
   ML-HDNNP

cmake/presets/all_on.cmake

@@ -50,7 +50,6 @@ set(ALL_PACKAGES
   MDI
   MEAM
   MESONT
-  MESSAGE
   MGPT
   MISC
   ML-HDNNP

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/kokkos-sycl.cmake

@@ -0,0 +1,15 @@
+# preset that enables KOKKOS and selects SYCL compilation with OpenMP
+# enabled as well. Also sets some performance related compiler flags.
+set(PKG_KOKKOS ON CACHE BOOL "" FORCE)
+set(Kokkos_ENABLE_SERIAL ON CACHE BOOL "" FORCE)
+set(Kokkos_ENABLE_OPENMP ON CACHE BOOL "" FORCE)
+set(Kokkos_ENABLE_CUDA   OFF CACHE BOOL "" FORCE)
+set(Kokkos_ENABLE_SYCL   ON CACHE BOOL "" FORCE)
+set(Kokkos_ARCH_MAXWELL50 on CACHE BOOL "" FORCE)
+set(BUILD_OMP ON CACHE BOOL "" FORCE)
+
+set(CMAKE_CXX_COMPILER clang++ CACHE STRING "" FORCE)
+set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
+set(CMAKE_CXX_STANDARD 17 CACHE STRING "" FORCE)
+set(CMAKE_SHARED_LINKER_FLAGS "-Xsycl-target-frontend -O3" CACHE STRING "" FORCE)
+set(CMAKE_TUNE_FLAGS "-fgpu-inline-threshold=100000 -Xsycl-target-frontend -O3  -Xsycl-target-frontend -ffp-contract=on -Wno-unknown-cuda-version" CACHE STRING "" FORCE)

cmake/presets/nolib.cmake

@@ -15,7 +15,6 @@ set(PACKAGES_WITH_LIB
   MACHDYN
   MDI
   MESONT
-  MESSAGE
   ML-HDNNP
   ML-PACE
   ML-QUIP

doc/lammps.1

@@ -1,7 +1,7 @@
-.TH LAMMPS "1" "7 January 2022" "2022-1-7"
+.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/Build_extras.rst

@@ -45,7 +45,6 @@ This is the list of packages that may require additional steps.
    * :ref:`MACHDYN <machdyn>`
    * :ref:`MDI <mdi>`
    * :ref:`MESONT <mesont>`
-   * :ref:`MESSAGE <message>`
    * :ref:`ML-HDNNP <ml-hdnnp>`
    * :ref:`ML-IAP <mliap>`
    * :ref:`ML-PACE <ml-pace>`
@@ -638,13 +637,14 @@ This list was last updated for version 3.5.0 of the Kokkos library.
 
          -D CMAKE_CXX_COMPILER=${HOME}/lammps/lib/kokkos/bin/nvcc_wrapper
 
-      To simplify compilation, three preset files are included in the
+      To simplify compilation, four preset files are included in the
       ``cmake/presets`` folder, ``kokkos-serial.cmake``,
-      ``kokkos-openmp.cmake``, and ``kokkos-cuda.cmake``. They will
+      ``kokkos-openmp.cmake``, ``kokkos-cuda.cmake``, and
-      enable the KOKKOS package and enable some hardware choice.  So to
+      ``kokkos-sycl.cmake``.  They will enable the KOKKOS package and
-      compile with OpenMP host parallelization, CUDA device
+      enable some hardware choice.  So to compile with OpenMP host
-      parallelization (for GPUs with CC 5.0 and up) with some common
+      parallelization, CUDA device parallelization (for GPUs with CC 5.0
-      packages enabled, you can do the following:
+      and up) with some common packages enabled, you can do the
+      following:
 
       .. code-block:: bash
 
@@ -796,47 +796,6 @@ library.
 
 ----------
 
-.. _message:
-
-MESSAGE package
------------------------------
-
-This package can optionally include support for messaging via sockets,
-using the open-source `ZeroMQ library <http://zeromq.org>`_, which must
-be installed on your system.
-
-.. tabs::
-
-   .. tab:: CMake build
-
-      .. code-block:: bash
-
-         -D MESSAGE_ZMQ=value    # build with ZeroMQ support, value = no (default) or yes
-         -D ZMQ_LIBRARY=path     # ZMQ library file (only needed if a custom location)
-         -D ZMQ_INCLUDE_DIR=path # ZMQ include directory (only needed if a custom location)
-
-   .. tab:: Traditional make
-
-      Before building LAMMPS, you must build the CSlib library in
-      ``lib/message``\ .  You can build the CSlib library manually if
-      you prefer; follow the instructions in ``lib/message/README``\ .
-      You can also do it in one step from the ``lammps/src`` dir, using
-      a command like these, which simply invoke the
-      ``lib/message/Install.py`` script with the specified args:
-
-      .. code-block:: bash
-
-         $ make lib-message               # print help message
-         $ make lib-message args="-m -z"  # build with MPI and socket (ZMQ) support
-         $ make lib-message args="-s"     # build as serial lib with no ZMQ support
-
-      The build should produce two files: ``lib/message/cslib/src/libmessage.a``
-      and ``lib/message/Makefile.lammps``.  The latter is copied from an
-      existing ``Makefile.lammps.*`` and has settings to link with the ZeroMQ
-      library if requested in the build.
-
-----------
-
 .. _mliap:
 
 ML-IAP package

doc/src/Build_package.rst

@@ -45,7 +45,6 @@ packages:
    * :ref:`KOKKOS <kokkos>`
    * :ref:`LATTE <latte>`
    * :ref:`MACHDYN <machdyn>`
-   * :ref:`MESSAGE <message>`
    * :ref:`ML-HDNNP <ml-hdnnp>`
    * :ref:`ML-PACE <ml-pace>`
    * :ref:`ML-QUIP <ml-quip>`

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
+* `C++11 standard compliance`_ when building all of LAMMPS
-* :ref:`FFT library <fft>` for use with the :doc:`kspace_style pppm <kspace_style>` command
+* `FFT library`_ for use with the :doc:`kspace_style pppm <kspace_style>` command
-* :ref:`Size of LAMMPS integer types <size>`
+* `Size of LAMMPS integer types and size limits`_
-* :ref:`Read or write compressed files <gzip>`
+* `Read or write compressed files`_
-* :ref:`Output of JPG and PNG files <graphics>` via the :doc:`dump image <dump_image>` command
+* `Output of JPG, PNG, and move files` via the :doc:`dump image <dump_image>` or :doc:`dump movie <dump_image>` commands
-* :ref:`Output of movie files <graphics>` via the :doc:`dump_movie <dump_image>` command
+* `Memory allocation alignment`_
-* :ref:`Memory allocation alignment <align>`
+* `Workaround for long long integers`_
-* :ref:`Workaround for long long integers <longlong>`
+* `Exception handling when using LAMMPS as a library`_ to capture errors
-* :ref:`Error handling exceptions <exceptions>` when using LAMMPS as a library
+* `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.
+While portability to other platforms is desired, it is not always
-The LAMMPS developers are dependent on LAMMPS users giving feedback and
+achieved.  That is sometimes due to non-portable code in LAMMPS itself,
-providing assistance in resolving portability issues.  This is particularly
+but more often due to portability limitations of external libraries and
-true for compiling LAMMPS on Windows, since this platform has significant
+tools required to build a specific feature or package.  The LAMMPS
-differences in some low-level functionality.
+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
+If it is necessary for you to compile LAMMPS on a Windows machine
-pre-compiled Windows binary packages are sufficient for your needs.  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
+of a Linux system (Ubuntu by default) from within Windows and from there
-use that shell like you are running on an Ubuntu Linux machine
+on, you can pretty much use that shell like you are running on a regular
-(e.g. installing software via apt-get and more).  For more details on
+Ubuntu Linux machine (e.g. installing software via apt-get and more).
-that, please see :doc:`this tutorial <Howto_wsl>`.
+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
+One option for compiling LAMMPS on Windows natively is to install a Bash
-to work in the past is to install a bash shell, unix shell utilities,
+shell, Unix shell utilities, Perl, Python, GNU make, and a GNU compiler
-perl, GNU make, and a GNU compiler ported to Windows.  The Cygwin
+ported to Windows.  The Cygwin package provides a unix/linux interface
-package provides a unix/linux interface to low-level Windows functions,
+to low-level Windows functions, so LAMMPS can be compiled on Windows.
-so LAMMPS can be compiled on Windows.  The necessary (minor)
+The necessary (minor) modifications to LAMMPS are included, but may not
-modifications to LAMMPS are included, but may not always up-to-date for
+always up-to-date for recently added functionality and the corresponding
-recently added functionality and the corresponding new code.  A machine
+new code.  A machine makefile for using cygwin for the old build system
-makefile for using cygwin for the old build system is provided. Using
+is provided.  Using CMake for this mode of compilation is untested and
-CMake for this mode of compilation is untested and not likely to work.
+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
@@ -65,8 +73,9 @@ configuration should set this up automatically, but is untested.
 In case of problems, you are recommended to contact somebody with
 experience in using Cygwin.  If you do come across portability problems
 requiring changes to the LAMMPS source code, or figure out corrections
-yourself, please report them on the lammps-users mailing list, or file
+yourself, please report them on the
-them as an issue or pull request on the LAMMPS GitHub project.
+`LAMMPS forum at MatSci <https://matsci.org/c/lammps/lammps-development/>`_,
+or file them as an issue or pull request on the LAMMPS GitHub project.
 
 .. _msvc:
 
@@ -75,19 +84,27 @@ 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
+for native compilation on Windows using Visual Studio has been
-improved.  This has been tested with Visual Studio 2019 (aka version
+significantly improved.  This has been tested with Visual Studio 2019
-16).  Not all features and packages in LAMMPS are currently supported
+(aka version 16) and Visual Studio 2022 (aka version 17).  We strongly
-out of the box, but a preset ``cmake/presets/windows.cmake`` is provided
+recommend using Visual Studio 2022 version 17.1 or later.  Not all
-that contains the packages that have been compiled successfully.  You
+features and packages in LAMMPS are currently supported out of the box,
-must use the CMake based build procedure, and either use the integrated
+but a preset ``cmake/presets/windows.cmake`` is provided that contains
-CMake support of Visual Studio or use an external CMake installation to
+the packages that have been compiled successfully so far.  You **must**
-create build files for the Visual Studio build system.  Please note that
+use the CMake based build procedure, since there is no support for GNU
-on launching Visual Studio it will scan the directory tree and likely
+make or the Unix shell utilities required for the GNU make build
-miss the correct master ``CMakeLists.txt``.  Try to open the
+procedure.
-``cmake/CMakeSettings.json`` and use those CMake configurations as a
+
-starting point.  It is also possible to configure and compile LAMMPS
+It is possible to use both the integrated CMake support of the Visual
-from the command line with a CMake binary from `cmake.org <https://cmake.org>`_.
+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
@@ -98,9 +115,11 @@ 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
+.. note::
-via GitHub, the forum, or the mailing list, if you have questions or
+
-LAMMPS specific problems.
+   This is work in progress and you should contact the LAMMPS developers
+   via GitHub or the `LAMMPS forum at MatSci <https://matsci.org/c/lammps/lammps-development/>`_,
+   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>`
@@ -67,8 +67,7 @@ An alphabetic list of all general LAMMPS commands.
    * :doc:`lattice <lattice>`
    * :doc:`log <log>`
    * :doc:`mass <mass>`
-   * :doc:`mdi/engine <mdi_engine>`
+   * :doc:`mdi <mdi>`
-   * :doc:`message <message>`
    * :doc:`minimize <minimize>`
    * :doc:`min_modify <min_modify>`
    * :doc:`min_style <min_style>`
@@ -105,7 +104,6 @@ An alphabetic list of all general LAMMPS commands.
    * :doc:`restart <restart>`
    * :doc:`run <run>`
    * :doc:`run_style <run_style>`
-   * :doc:`server <server>`
    * :doc:`set <set>`
    * :doc:`shell <shell>`
    * :doc:`special_bonds <special_bonds>`
@@ -117,7 +115,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_compute.rst

@@ -63,6 +63,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`event/displace <compute_event_displace>`
    * :doc:`fabric <compute_fabric>`
    * :doc:`fep <compute_fep>`
+   * :doc:`fep/ta <compute_fep_ta>`
    * :doc:`force/tally <compute_tally>`
    * :doc:`fragment/atom <compute_cluster_atom>`
    * :doc:`global/atom <compute_global_atom>`
@@ -100,7 +101,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>`
@@ -143,8 +143,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

@@ -51,10 +51,10 @@ OPT.
    * :doc:`bond/swap <fix_bond_swap>`
    * :doc:`box/relax <fix_box_relax>`
    * :doc:`charge/regulation <fix_charge_regulation>`
-   * :doc:`client/md <fix_client_md>`
    * :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>`
@@ -100,12 +100,10 @@ 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>`
-   * :doc:`mdi/engine <fix_mdi_engine>`
+   * :doc:`mdi/aimd <fix_mdi_aimd>`
    * :doc:`meso/move <fix_meso_move>`
    * :doc:`mol/swap <fix_mol_swap>`
    * :doc:`momentum (k) <fix_momentum>`
@@ -132,6 +130,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>`
@@ -247,6 +246,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

@@ -88,12 +88,12 @@ OPT.
    * :doc:`coul/tt <pair_coul_tt>`
    * :doc:`coul/wolf (ko) <pair_coul>`
    * :doc:`coul/wolf/cs <pair_cs>`
-   * :doc:`dpd (gio) <pair_dpd>`
+   * :doc:`dpd (giko) <pair_dpd>`
    * :doc:`dpd/fdt <pair_dpd_fdt>`
-   * :doc:`dpd/ext <pair_dpd_ext>`
+   * :doc:`dpd/ext (k) <pair_dpd_ext>`
-   * :doc:`dpd/ext/tstat <pair_dpd_ext>`
+   * :doc:`dpd/ext/tstat (k) <pair_dpd_ext>`
    * :doc:`dpd/fdt/energy (k) <pair_dpd_fdt>`
-   * :doc:`dpd/tstat (go) <pair_dpd>`
+   * :doc:`dpd/tstat (gko) <pair_dpd>`
    * :doc:`dsmc <pair_dsmc>`
    * :doc:`e3b <pair_e3b>`
    * :doc:`drip <pair_drip>`
@@ -124,6 +124,7 @@ OPT.
    * :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>`
@@ -241,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>`

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

@@ -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_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
+specific functions in those DSOs.  Any DSO file with plugins has to
-an initialization function with a specific name, "lammpsplugin_init", that
+include an initialization function with a specific name,
-has to follow specific rules described below.  When loading the DSO with
+"lammpsplugin_init", that has to follow specific rules described below.
-the "plugin" command, this function is looked up and called and will then
+When loading the DSO with the "plugin" command, this function is looked
-register the contained plugin(s) with LAMMPS.
+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
@@ -59,25 +68,24 @@ Members of ``lammpsplugin_t``
    * - author
      - String with the name and email of the author
    * - creator.v1
-     - Pointer to factory function for pair, bond, angle, dihedral, improper or command styles
+     - Pointer to factory function for pair, bond, angle, dihedral, improper, kspace, or command styles
    * - creator.v2
      - Pointer to factory function for compute, fix, or region styles
    * - handle
      - Pointer to the open DSO file handle
 
-Only one of the three alternate creator entries can be used at a time
+Only one of the two alternate creator entries can be used at a time and
-and which of those is determined by the style of plugin. The
+which of those is determined by the style of plugin. The "creator.v1"
-"creator.v1" element is for factory functions of supported styles
+element is for factory functions of supported styles computing forces
-computing forces (i.e.  command, pair, bond, angle, dihedral, or
+(i.e. pair, bond, angle, dihedral, or improper styles) or command styles
-improper styles) and the function takes as single argument the pointer
+and the function takes as single argument the pointer to the LAMMPS
-to the LAMMPS instance. The factory function is cast to the
+instance. The factory function is cast to the ``lammpsplugin_factory1``
-``lammpsplugin_factory1`` type before assignment.  The "creator.v2"
+type before assignment.  The "creator.v2" element is for factory
-element is for factory functions creating an instance of a fix, compute,
+functions creating an instance of a fix, compute, or region style and
-or region style and takes three arguments: a pointer to the LAMMPS
+takes three arguments: a pointer to the LAMMPS instance, an integer with
-instance, an integer with the length of the argument list and a ``char
+the length of the argument list and a ``char **`` pointer to the list of
-**`` pointer to the list of arguments. The factory function pointer
+arguments. The factory function pointer needs to be cast to the
-needs to be cast to the ``lammpsplugin_factory2`` type before
+``lammpsplugin_factory2`` type before assignment.
-assignment.
 
 Pair style example
 ^^^^^^^^^^^^^^^^^^
@@ -249,3 +257,29 @@ 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.
+
+Compiling plugins
+^^^^^^^^^^^^^^^^^
+
+Plugins need to be compiled with the same compilers and libraries
+(e.g. MPI) and compilation settings (MPI on/off, OpenMP, integer sizes)
+as the LAMMPS executable and library.  Otherwise the plugin will likely
+not load due to mismatches in the function signatures (LAMMPS is C++ so
+scope, type, and number of arguments are encoded into the symbol names
+and thus differences in them will lead to failed plugin load commands.
+Compilation of the plugin can be managed via both, CMake or traditional
+GNU makefiles.  Some examples that can be used as a template are in the
+``examples/plugins`` folder.  The CMake script code has some small
+adjustments to allow building the plugins for running unit tests with
+them. Another example that converts the KIM package into a plugin can be
+found in the ``examples/kim/plugin`` folder.  No changes to the sources
+of the KIM package themselves are needed; only the plugin interface and
+loader code needs to be added.  This example only supports building with
+CMake, but is probably a more typical example. To compile you need to
+run CMake with -DLAMMPS_SOURCE_DIR=<path/to/lammps/src/folder>.  Other
+configuration setting are identical to those for compiling 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()``
+The :cpp:func:`utils::fgets_trunc() <LAMMPS_NS::utils::fgets_trunc>`
-but it will read in a whole line (i.e. until the end of line or end
+function will work similar for ``fgets()`` but it will read in a whole
-of file), but store only as many characters as will fit into the buffer
+line (i.e. until the end of line or end of file), but store only as many
-including a final newline character and the terminating NULL byte.
+characters as will fit into the buffer including a final newline
-If the line in the file is longer it will thus be truncated in the buffer.
+character and the terminating NULL byte.  If the line in the file is
-This function is used by :cpp:func:`read_lines_from_file` to read individual
+longer it will thus be truncated in the buffer.  This function is used
-lines but make certain they follow the size constraints.
+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
+The :cpp:func:`utils::read_lines_from_file()
-number of lines of a maximum length into a buffer and will return 0
+<LAMMPS_NS::utils::read_lines_from_file>` function will read the
-if successful or 1 if not. It also guarantees that all lines are
+requested number of lines of a maximum length into a buffer and will
-terminated with a newline character and the entire buffer with a
+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.
 
 ----------
@@ -62,7 +65,7 @@ silently returning the result of a partial conversion or zero in cases
 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,8 +73,8 @@ 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>`
+Please also see :cpp:func:`utils::is_integer() <LAMMPS_NS::utils::is_integer>`
-and :cpp:func:`is_double() <LAMMPS_NS::utils::is_double>` for testing
+and :cpp:func:`utils::is_double() <LAMMPS_NS::utils::is_double>` for testing
 strings for compliance without conversion.
 
 ----------
@@ -130,6 +133,9 @@ and parsing files or arguments.
 .. doxygenfunction:: trim_comment
    :project: progguide
 
+.. doxygenfunction:: star_subst
+   :project: progguide
+
 .. doxygenfunction:: has_utf8
    :project: progguide
 
@@ -205,6 +211,9 @@ Convenience functions
 .. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &mesg)
    :project: progguide
 
+.. doxygenfunction:: flush_buffers(LAMMPS *lmp)
+   :project: progguide
+
 .. doxygenfunction:: getsyserror
    :project: progguide
 
@@ -337,11 +346,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:
 
 ----------
 
@@ -390,21 +399,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
+:cpp:class:`ValueTokenizer <LAMMPS_NS::ValueTokenizer>` class to process
-text.  The :cpp:class:`LAMMPS_NS::TextFileReader` is a more general
+the read in text.  The :cpp:class:`TextFileReader
-version while :cpp:class:`LAMMPS_NS::PotentialFileReader` is specialized
+<LAMMPS_NS::TextFileReader>` is a more general version while
-to implement the behavior expected for looking up and reading/parsing
+:cpp:class:`PotentialFileReader <LAMMPS_NS::PotentialFileReader>` is
-files with potential parameters in LAMMPS.  The potential file reader
+specialized to implement the behavior expected for looking up and
-class requires a LAMMPS instance, requires to be run on MPI rank 0 only,
+reading/parsing files with potential parameters in LAMMPS.  The
-will use the :cpp:func:`LAMMPS_NS::utils::get_potential_file_path`
+potential file reader class requires a LAMMPS instance, requires to be
-function to look up and open the file, and will call the
+run on MPI rank 0 only, will use the
-:cpp:class:`LAMMPS_NS::Error` class in case of failures to read or to
+:cpp:func:`utils::get_potential_file_path
-convert numbers, so that LAMMPS will be aborted.
+<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
@@ -479,10 +493,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
+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:`vget()
+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++
@@ -585,4 +599,3 @@ the communication buffers.
 
 .. doxygenunion:: LAMMPS_NS::ubuf
    :project: progguide
-

doc/src/Errors_bugs.rst

@@ -17,9 +17,8 @@ the steps outlined below:
    if your issue has already been reported and if it is still open.
  * Check the `GitHub Pull Requests page <https://github.com/lammps/lammps/pulls>`_
    to see if there is already a fix for your bug pending.
- * Check the `mailing list archives <https://www.lammps.org/mail.html>`_ or
+ * Check the `LAMMPS forum at MatSci <https://matsci.org/lammps/>`_
-   the `LAMMPS forum <https://www.lammps.org/forum.html>`_ to see if the
+   to see if the issue has been discussed before.
-   issue has been discussed before.
 
 If none of these steps yields any useful information, please file a new
 bug report on the `GitHub Issue page <https://github.com/lammps/lammps/issues>`_.
@@ -38,12 +37,9 @@ generate this restart from a data file or a simple additional input.
 This input deck can be used with tools like a debugger or `valgrind
 <https://valgrind.org>`_ to further :doc:`debug the crash <Errors_debug>`.
 
-You may also send an email to the LAMMPS mailing list at
+You may also post a message in the `development category of the LAMMPS
-"lammps-users at lists.sourceforge.net" describing the problem with the
+forum at MatSci <https://matsci.org/c/lammps/lammps-development/>`_
-same kind of information.  The mailing list can provide a faster response,
+describing the problem with the same kind of information.  The forum can
-especially if the bug reported is actually expected behavior.  But because
+provide a faster response, especially if the bug reported is actually
-of the high volume of the mailing list, it can happen that your e-mail
+expected behavior or other LAMMPS users have come across it before.
-is overlooked and then forgotten.  Issues on GitHub have to be explicitly
-closed, so that will *guarantee* that at least one LAMMPS developer will
-have looked at it.
 

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.
 

doc/src/Examples.rst

@@ -94,12 +94,12 @@ Lowercase directories
 +-------------+------------------------------------------------------------------+
 | latte       | examples for using fix latte for DFTB via the LATTE library      |
 +-------------+------------------------------------------------------------------+
+| mdi         | use of the MDI package and MolSSI MDI code coupling library      |
++-------------+------------------------------------------------------------------+
 | meam        | MEAM test for SiC and shear (same as shear examples)             |
 +-------------+------------------------------------------------------------------+
 | melt        | rapid melt of 3d LJ system                                       |
 +-------------+------------------------------------------------------------------+
-| message     | demos for LAMMPS client/server coupling with the MESSAGE package |
-+-------------+------------------------------------------------------------------+
 | micelle     | self-assembly of small lipid-like molecules into 2d bilayers     |
 +-------------+------------------------------------------------------------------+
 | min         | energy minimization of 2d LJ melt                                |

doc/src/Howto.rst

@@ -22,7 +22,6 @@ General howto
    Howto_replica
    Howto_library
    Howto_couple
-   Howto_client_server
    Howto_mdi
 
 Settings howto

doc/src/Howto_client_server.rst

@@ -1,163 +0,0 @@
-Using LAMMPS in client/server mode
-==================================
-
-Client/server coupling of two codes is where one code is the "client"
-and sends request messages to a "server" code.  The server responds to
-each request with a reply message.  This enables the two codes to work
-in tandem to perform a simulation.  LAMMPS can act as either a client
-or server code.
-
-Some advantages of client/server coupling are that the two codes run
-as stand-alone executables; they are not linked together.  Thus
-neither code needs to have a library interface.  This often makes it
-easier to run the two codes on different numbers of processors.  If a
-message protocol (format and content) is defined for a particular kind
-of simulation, then in principle any code that implements the
-client-side protocol can be used in tandem with any code that
-implements the server-side protocol, without the two codes needing to
-know anything more specific about each other.
-
-A simple example of client/server coupling is where LAMMPS is the
-client code performing MD timestepping.  Each timestep it sends a
-message to a server quantum code containing current coords of all the
-atoms.  The quantum code computes energy and forces based on the
-coords.  It returns them as a message to LAMMPS, which completes the
-timestep.
-
-A more complex example is where LAMMPS is the client code and
-processes a series of data files, sending each configuration to a
-quantum code to compute energy and forces.  Or LAMMPS runs dynamics
-with an atomistic force field, but pauses every N steps to ask the
-quantum code to compute energy and forces.
-
-Alternate methods for code coupling with LAMMPS are described on
-the :doc:`Howto couple <Howto_couple>` doc page.
-
-The protocol for using LAMMPS as a client is to use these 3 commands
-in this order (other commands may come in between):
-
-* :doc:`message client <message>`  # initiate client/server interaction
-* :doc:`fix client/md <fix_client_md>`   # any client fix which makes specific requests to the server
-* :doc:`message quit <message>`    # terminate client/server interaction
-
-In between the two message commands, a client fix command and
-:doc:`unfix <unfix>` command can be used multiple times.  Similarly,
-this sequence of 3 commands can be repeated multiple times, assuming
-the server program operates in a similar fashion, to initiate and
-terminate client/server communication.
-
-The protocol for using LAMMPS as a server is to use these 2 commands
-in this order (other commands may come in between):
-
-* :doc:`message server <message>`  # initiate client/server interaction
-* :doc:`server md <server_md>`    # any server command which responds to specific requests from the client
-
-This sequence of 2 commands can be repeated multiple times, assuming
-the client program operates in a similar fashion, to initiate and
-terminate client/server communication.
-
-LAMMPS support for client/server coupling is in its :ref:`MESSAGE package <PKG-MESSAGE>` which implements several
-commands that enable LAMMPS to act as a client or server, as discussed
-below.  The MESSAGE package also wraps a client/server library called
-CSlib which enables two codes to exchange messages in different ways,
-either via files, sockets, or MPI.  The CSlib is provided with LAMMPS
-in the lib/message dir.  The CSlib has its own
-`website <https://cslib.sandia.gov>`_ with documentation and test
-programs.
-
-.. note::
-
-   For client/server coupling to work between LAMMPS and another
-   code, the other code also has to use the CSlib.  This can sometimes be
-   done without any modifications to the other code by simply wrapping it
-   with a Python script that exchanges CSlib messages with LAMMPS and
-   prepares input for or processes output from the other code.  The other
-   code also has to implement a matching protocol for the format and
-   content of messages that LAMMPS exchanges with it.
-
-These are the commands currently in the MESSAGE package for two
-protocols, MD and MC (Monte Carlo).  New protocols can easily be
-defined and added to this directory, where LAMMPS acts as either the
-client or server.
-
-* :doc:`message <message>`
-* :doc:`fix client md <fix_client_md>` = LAMMPS is a client for running MD
-* :doc:`server md <server_md>` = LAMMPS is a server for computing MD forces
-* :doc:`server mc <server_mc>` = LAMMPS is a server for computing a Monte Carlo energy
-
-The server doc files give details of the message protocols
-for data that is exchanged between the client and server.
-
-These example directories illustrate how to use LAMMPS as either a
-client or server code:
-
-* examples/message
-* examples/COUPLE/README
-* examples/COUPLE/lammps_mc
-* examples/COUPLE/lammps_nwchem
-* examples/COUPLE/lammps_vasp
-
-The examples/message directory couples a client instance of LAMMPS to a
-server instance of LAMMPS.
-
-The files in the *lammps_mc* folder show how to couple LAMMPS as
-a server to a simple Monte Carlo client code as the driver.
-
-The files in the *lammps_nwchem* folder show how to couple LAMMPS
-as a client code running MD timestepping to NWChem acting as a
-server providing quantum DFT forces, through a Python wrapper script
-on NWChem.
-
-The files in the *lammps_vasp* folder show how to couple LAMMPS as
-a client code running MD timestepping to VASP acting as a server
-providing quantum DFT forces, through a Python wrapper script on VASP.
-
-Here is how to launch a client and server code together for any of the
-4 modes of message exchange that the :doc:`message <message>` command
-and the CSlib support.  Here LAMMPS is used as both the client and
-server code.  Another code could be substituted for either.
-
-The examples below show launching both codes from the same window (or
-batch script), using the "&" character to launch the first code in the
-background.  For all modes except *mpi/one*, you could also launch the
-codes in separate windows on your desktop machine.  It does not
-matter whether you launch the client or server first.
-
-In these examples either code can be run on one or more processors.
-If running in a non-MPI mode (file or zmq) you can launch a code on a
-single processor without using mpirun.
-
-IMPORTANT: If you run in mpi/two mode, you must launch both codes via
-mpirun, even if one or both of them runs on a single processor.  This
-is so that MPI can figure out how to connect both MPI processes
-together to exchange MPI messages between them.
-
-For message exchange in *file*, *zmq*, or *mpi/two* modes:
-
-.. code-block:: bash
-
-   % mpirun -np 1 lmp_mpi -log log.client < in.client &
-   % mpirun -np 2 lmp_mpi -log log.server < in.server
-
-   % mpirun -np 4 lmp_mpi -log log.client < in.client &
-   % mpirun -np 1 lmp_mpi -log log.server < in.server
-
-   % mpirun -np 2 lmp_mpi -log log.client < in.client &
-   % mpirun -np 4 lmp_mpi -log log.server < in.server
-
-For message exchange in *mpi/one* mode:
-
-Launch both codes in a single mpirun command:
-
-.. code-block:: bash
-
-   mpirun -np 2 lmp_mpi -mpicolor 0 -in in.message.client -log log.client : -np 4 lmp_mpi -mpicolor 1 -in in.message.server -log log.server
-
-The two -np values determine how many procs the client and the server
-run on.
-
-A LAMMPS executable run in this manner must use the -mpicolor color
-command-line option as their its option, where color is an integer
-label that will be used to distinguish one executable from another in
-the multiple executables that the mpirun command launches.  In this
-example the client was colored with a 0, and the server with a 1.

doc/src/Howto_couple.rst

@@ -12,16 +12,16 @@ LAMMPS can be coupled to other codes in at least 4 ways.  Each has
 advantages and disadvantages, which you will have to think about in the
 context of your application.
 
-1. Define a new :doc:`fix <fix>` command that calls the other code.  In
+1. Define a new :doc:`fix <fix>` command that calls the other code.
-   this scenario, LAMMPS is the driver code.  During timestepping,
+   In this scenario, LAMMPS is the driver code.  During timestepping,
    the fix is invoked, and can make library calls to the other code,
-   which has been linked to LAMMPS as a library.  This is the way how the
+   which has been linked to LAMMPS as a library.  This is the way the
    :ref:`LATTE <PKG-LATTE>` package, which performs density-functional
-   tight-binding calculations using the `LATTE software <https://github.com/lanl/LATTE>`_
+   tight-binding calculations using the `LATTE software
-   to compute forces, is hooked to LAMMPS.
+   <https://github.com/lanl/LATTE>`_ to compute forces, is hooked to
-   See the :doc:`fix latte <fix_latte>` command for more details.
+   LAMMPS.  See the :doc:`fix latte <fix_latte>` command for more
-   Also see the :doc:`Modify <Modify>` doc pages for info on how to
+   details.  Also see the :doc:`Modify <Modify>` doc pages for info on
-   add a new fix to LAMMPS.
+   how to add a new fix to LAMMPS.
 
 .. spacer
 
@@ -58,6 +58,12 @@ context of your application.
 
 .. spacer
 
-4. Couple LAMMPS with another code in a client/server mode.  This is
+4. Couple LAMMPS with another code in a client/server fashion, using
-   described on the :doc:`Howto client/server <Howto_client_server>` doc
+   using the `MDI Library
-   page.
+   <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_
+   developed by the `Molecular Sciences Software Institute (MolSSI)
+   <https://molssi.org>`_ to run LAMMPS as either an MDI driver
+   (client) or an MDI engine (server).  The MDI driver issues commands
+   to the MDI server to exchange data between them.  See the
+   :doc:`Howto mdi <Howto_mdi>` page for more information about how
+   LAMMPS can operate in either of these modes.

doc/src/Howto_mdi.rst

@@ -1,132 +1,144 @@
 Using LAMMPS with the MDI library for code coupling
 ===================================================
 
-.. note::
+Client/server coupling of two (or more) codes is where one code is the
-
+"client" and sends request messages (data) to one (or more) "server"
-  This Howto page will eventually replace the
+code(s).  A server responds to each request with a reply message
-  :doc:`Howto client/server <Howto_client_server>` doc page.
+(data).  This enables two (or more) codes to work in tandem to perform
-
+a simulation.  LAMMPS can act as either a client or server code; it
-Client/server coupling of two codes is where one code is the "client"
+does this by using the `MolSSI Driver Interface (MDI) library
-and sends request messages (data) to a "server" code.  The server
-responds to each request with a reply message.  This enables the two
-codes to work in tandem to perform a simulation.  LAMMPS can act as
-either a client or server code; it does this by using the `MolSSI
-Driver Interface (MDI) library
 <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_,
 developed by the `Molecular Sciences Software Institute (MolSSI)
-<https://molssi.org>`_.
+<https://molssi.org>`_, which is supported by the :ref:`MDI <PKG-MDI>`
+package.
 
 Alternate methods for code coupling with LAMMPS are described on the
 :doc:`Howto couple <Howto_couple>` doc page.
 
-Some advantages of client/server coupling are that the two codes can run
+Some advantages of client/server coupling are that the codes can run
 as stand-alone executables; they need not be linked together.  Thus
-neither code needs to have a library interface.  This also makes it easy
+neither code needs to have a library interface.  This also makes it
-to run the two codes on different numbers of processors.  If a message
+easy to run the two codes on different numbers of processors.  If a
-protocol (format and content) is defined for a particular kind of
+message protocol (format and content) is defined for a particular kind
-simulation, then in principle any code which implements the client-side
+of simulation, then in principle any code which implements the
-protocol can be used in tandem with any code which implements the
+client-side protocol can be used in tandem with any code which
-server-side protocol.  Neither code needs to know what specific other
+implements the server-side protocol.  Neither code needs to know what
-code it is working with.
+specific other code it is working with.
 
 In MDI nomenclature, a client code is the "driver", and a server code is
 an "engine".  One driver code can communicate with one or more instances
 of one or more engine codes.  Driver and engine codes can be written in
 any language: C, C++, Fortran, Python, etc.
 
-In addition to allowing driver and engine(s) running to run as
+In addition to allowing driver and engine(s) to run as stand-alone
-stand-alone executables, MDI also enables a server code to be a
+executables, MDI also enables an engine to be a *plugin* to the client
-"plugin" to the client code.  In this scenario, server code(s) are
+code.  In this scenario, server code(s) are compiled as shared
-compiled as shared libraries, and one (or more) instances of the
+libraries, and one (or more) instances of the server are instantiated
-server are instantiated by the driver code.  If the driver code runs
+by the driver code.  If the driver code runs in parallel, it can split
-in parallel, it can split its MPI communicator into multiple
+its MPI communicator into multiple sub-communicators, and launch each
-sub-communicators, and launch each plugin engine instance on a
+plugin engine instance on a sub-communicator.  Driver processors
-sub-communicator.  Driver processors in that sub-communicator exchange
+within that sub-communicator exchange messages with the corresponding
-messages with that engine instance, and can also send MPI messages to
+engine instance, and can also send MPI messages to other processors in
-other processors in the driver.  The driver code can also destroy
+the driver.  The driver code can also destroy engine instances and
-engine instances and re-instantiate them.
+re-instantiate them.  LAMMPS can operate as either a stand-alone or
+plugin MDI engine.  When it operates as a driver, if can use either
+stand-alone or plugin MDI engines.
 
-The way that a driver communicates with an engine is by making
+The way in which an MDI driver communicates with an MDI engine is by
-MDI_Send() and MDI_Recv() calls, which are conceptually similar to
+making MDI_Send() and MDI_Recv() calls, which are conceptually similar
-MPI_Send() and MPI_Recv() calls.  Each send or receive has a string
+to MPI_Send() and MPI_Recv() calls.  Each send or receive operation
-which identifies the command name, and optionally some data, which can
+uses a string to identify the command name, and optionally some data,
-be a single value or vector of values of any data type.  Inside the
+which can be a single value or vector of values of any data type.
-MDI library, data is exchanged between the driver and engine via MPI
+Inside the MDI library, data is exchanged between the driver and
-calls or sockets.  This a run-time choice by the user.
+engine via MPI calls or sockets.  This a run-time choice by the user.
+
+----------
+
+The :ref:`MDI <PKG-MDI>` package provides a :doc:`mdi engine <mdi>`
+command which enables LAMMPS to operate as an MDI engine.  Its doc
+page explains the variety of standard and custom MDI commands which
+the LAMMPS engine recognizes and can respond to.
+
+The package also provides a :doc:`mdi plugin <mdi>` command which
+enables LAMMPS to operate as an MDI driver and load an MDI engine as a
+plugin library.
+
+The package also has a `fix mdi/aimd <fix_mdi_aimd>` command in which
+LAMMPS operates as an MDI driver to perform *ab initio* MD simulations
+in conjunction with a quantum mechanics code.  Its post_force() method
+illustrates how a driver issues MDI commands to another code.  This
+command can be used to couple to an MDI engine which is either a
+stand-alone code or a plugin library.
+
+----------
+
+The examples/mdi directory contains Python scripts and LAMMPS input
+script which use LAMMPS as either an MDI driver or engine or both.
+Three example use cases are provided:
+
+* Run ab initio MD (AIMD) using 2 instances of LAMMPS, one as driver
+  and one as an engine.  As an engine, LAMMPS is a surrogate for a
+  quantum code.
+
+* A Python script driver invokes a sequence of unrelated LAMMPS
+  calculations.  Calculations can be single-point energy/force
+  evaluations, MD runs, or energy minimizations.
+
+* Run AIMD with a Python driver code and 2 LAMMPS instances as
+  engines.  The first LAMMPS instance performs MD timestepping.  The
+  second LAMMPS instance acts as a surrogate QM code to compute
+  forces.
+
+Note that in any of these example where LAMMPS is used as an engine,
+an actual QM code (which supports MDI) could be used in its place,
+without modifying other code or scripts, except to specify the name of
+the QM code.
+
+The examples/mdi/README file explains how to launch both driver and
+engine codes so that they communicate using the MDI library via either
+MPI or sockets.
 
 -------------
 
-As an example, LAMMPS and the ``pw.x`` command from Quantum Espresso (a
+Currently there are two quantum DFT codes which have direct MDI
-suite of quantum DFT codes), can work together via the MDI library to
+support, `Quantum ESPRESSO (QE) <https://www.quantum-espresso.org/>`_
-perform an ab initio MD (AIMD) simulation, where LAMMPS runs an MD
+and `INQ <https://qsg.llnl.gov/node/101.html>`_.  There are also
-simulation and sends a message each timestep to ``pw.x`` asking it to
+several QM codes which have indirect support through QCEngine or i-PI.
-compute quantum forces on the current configuration of atoms.  Here is
+The former means they require a wrapper program (QCEngine) with MDI
-how the 2 codes are launched to communicate by MPI:
+support which writes/read files to pass data to the quantum code
+itself.  The list of QCEngine-supported and i-PI-supported quantum
+codes is on the `MDI webpage
+<https://molssi-mdi.github.io/MDI_Library/html/index.html>`_.
+
+Here is how to build QE as a stand-alone ``pw.x`` file which can be
+used in stand-alone mode:
 
 .. code-block:: bash
 
-   % mpirun -np 2 lmp_mpi -mdi "-role DRIVER -name d -method MPI" \
+   % git clone --branch mdi_plugin https://github.com/MolSSI-MDI/q-e.git <base_path>/q-e
-     -in in.aimd : -np 16 pw.x -in qe.in -mdi "-role ENGINE -name e -method MPI"
+   % build the executable pw.x, following the `QE build guide <https://gitlab.com/QEF/q-e/-/wikis/Developers/CMake-build-system>`_
 
-In this case LAMMPS runs on 2 processors (MPI tasks), ``pw.x`` runs on 16
+Here is how to build QE as a shared library which can be used in plugin mode,
-processors.
+which results in a libqemdi.so file in <base_path>/q-e/MDI/src:
-
-Here is how the 2 codes are launched to communicate by sockets:
 
 .. code-block:: bash
 
-   % mpirun -np 2 lmp_mpi -mdi "-role DRIVER -name d -method TCP -port 8021" -in in.aimd
+   % git clone --branch mdi_plugin https://github.com/MolSSI-MDI/q-e.git <base_path>/q-e
-   % mpirun -np 16 pw.x -in qe.in -mdi "-role ENGINE -name e -method TCP -port 8021 -hostname localhost"
+   % cd <base_path>/q-e
+   % ./configure --enable-parallel --enable-openmp --enable-shared FFLAGS="-fPIC" FCFLAGS="-fPIC" CFLAGS="-fPIC" foxflags="-fPIC" try_foxflags="-fPIC"
+   % make -j 4 mdi
 
-These commands could be issued in different windows on a desktop
+INQ cannot be built as a stand-alone code; it is by design a library.
-machine.  Or in the same window, if the first command is ended with
+Here is how to build INQ as a shared library which can be used in
-"&" so as to run in the background.  If "localhost" is replaced by an
+plugin mode, which results in a libinqmdi.so file in
-IP address, ``pw.x`` could be run on another machine on the same network, or
+<base_path>/inq/build/examples:
-even on another machine across the country.
 
-After both codes initialize themselves to model the same system, this is
+.. code-block:: bash
-what occurs each timestep:
 
-* LAMMPS send a ">COORDS" message to ``pw.x`` with a 3*N vector of current atom coords
+   % git clone --branch mdi --recurse-submodules https://gitlab.com/taylor-a-barnes/inq.git <base_path>/inq
-* ``pw.x`` receives the message/coords and computes quantum forces on all the atoms
+   % cd <base_path>/inq
-* LAMMPS send a "<FORCES" message to ``pw.x`` and waits for the result
+   % mkdir -p build
-* ``pw.x`` receives the message (after its computation finishes) and sends a 3*N vector of forces
+   % cd build
-* LAMMPS receives the forces and time integrates to complete a single timestep
+   % ../configure --prefix=<install_path>/install
-
+   % make -j 4
--------------
+   % make install
-
-Examples scripts for using LAMMPS as an MDI engine are in the
-examples/mdi directory.  See the README file in that directory for
-instructions on how to run the examples.
-
-.. note::
-
-  Work is underway to add commands that allow LAMMPS to be used as an
-  MDI driver, e.g. for the AIMD example discussed above.  Example
-  scripts for this usage mode will be added the same directory when
-  available.
-
-If LAMMPS is used as a stand-alone engine it should set up the system
-it will be modeling in its input script, then invoke the
-:doc:`mdi/engine <mdi_engine>` command.  This will put LAMMPS into
-"engine mode" where it waits for messages and data from the driver.
-When the driver sends an "EXIT" command, LAMMPS will exit engine mode
-and the input script will continue.
-
-If LAMMPS is used as a plugin engine it operates the same way, except
-that the driver will pass LAMMPS an input script to initialize itself.
-Upon receiving the "EXIT" command, LAMMPS will exit engine mode and the
-input script will continue.  After finishing execution of the input
-script, the instance of LAMMPS will be destroyed.
-
-LAMMPS supports the full set of MD-appropriate engine commands defined
-by the MDI library.  See the :doc:`mdi/engine <mdi_engine>` page for
-a list of these.
-
-If those commands are not sufficient for a user-developed driver to use
-LAMMPS as an engine, then new commands can be easily added.  See these
-two files which implement the definition of MDI commands and the logic
-for responding to them:
-
-* src/MDI/mdi_engine.cpp
-* src/MDI/fix_mdi_engine.cpp

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,62 @@ 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
+   try:
+       from yaml import CSafeLoader as Loader, CSafeDumper as Dumper
+   except ImportError:
+       from yaml import SafeLoader as Loader, SafeDumper as Dumper
+
+   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=Loader))
+
+   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

@@ -165,5 +165,4 @@ changed.  How to do this depends on the build system you are using.
    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,
+(Temple U, akohlmey at gmail.com).
-richard.berger at temple.edu).

doc/src/Install_mac.rst

@@ -5,7 +5,7 @@ LAMMPS can be downloaded, built, and configured for OS X on a Mac with
 `Homebrew <homebrew_>`_.  (Alternatively, see the install instructions for
 :doc:`Download an executable via Conda <Install_conda>`.)  The following LAMMPS
 packages are unavailable at this time because of additional needs not yet met:
-GPU, KOKKOS, LATTE, MSCG, MESSAGE, MPIIO POEMS VORONOI.
+GPU, KOKKOS, LATTE, MSCG, MPIIO, POEMS, VORONOI.
 
 After installing Homebrew, you can install LAMMPS on your system with
 the following commands:

doc/src/Install_tarball.rst

@@ -6,7 +6,7 @@ of the `LAMMPS website <lws_>`_.
 
 .. _download: https://www.lammps.org/download.html
 .. _bug: https://www.lammps.org/bug.html
-.. _older: https://www.lammps.org/tars
+.. _older: https://download.lammps.org/tars/
 .. _lws: https://www.lammps.org
 
 You have two choices of tarballs, either the most recent stable

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

@@ -46,7 +46,7 @@ In addition there are DOIs for individual stable releases. Currently there are:
 
 - 3 March 2020 version: `DOI:10.5281/zenodo.3726417 <https://dx.doi.org/10.5281/zenodo.3726417>`_
 - 29 October 2020 version: `DOI:10.5281/zenodo.4157471 <https://dx.doi.org/10.5281/zenodo.4157471>`_
-
+- 29 September 2021 version: `DOI:10.5281/zenodo.6386596 <https//dx.doi.org/10.5281/zenodo.6386596>`_
 
 Home page
 ^^^^^^^^^

doc/src/Intro_website.rst

@@ -20,7 +20,6 @@ available online are listed below.
 * `Glossary of terms relevant to LAMMPS <https://www.lammps.org/glossary.html>`_
 * `LAMMPS highlights with images <https://www.lammps.org/pictures.html>`_
 * `LAMMPS highlights with movies <https://www.lammps.org/movies.html>`_
-* `Mailing list <https://www.lammps.org/mail.html>`_
 * `LAMMPS forum <https://www.lammps.org/forum.html>`_
 * `Workshops <https://www.lammps.org/workshops.html>`_
 * `Tutorials <https://www.lammps.org/tutorials.html>`_

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

@@ -14,11 +14,11 @@ LAMMPS is an open-source code, distributed freely under the terms of
 the GNU Public License Version 2 (GPLv2).
 
 The `LAMMPS website <lws_>`_ has a variety of information about the
-code.  It includes links to an on-line version of this manual, a
+code.  It includes links to an on-line version of this manual, an
-`mailing list <https://www.lammps.org/mail.html>`_ and
+`online forum <https://www.lammps.org/forum.html>`_ where users can post
-`online forum <https://www.lammps.org/forum.html>`_  where users can
+questions and discuss LAMMPS, and a `GitHub site
-post questions, and a `GitHub site <https://github.com/lammps/lammps>`_
+<https://github.com/lammps/lammps>`_ where all LAMMPS development is
-where all LAMMPS development is coordinated.
+coordinated.
 
 ----------
 

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
+are optional.  The following pages give basic instructions on what
-this.
+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
+If you add a new feature to LAMMPS and think it will be of general
-general users, we encourage you to submit it for inclusion in LAMMPS
+interest to other users, we encourage you to submit it for inclusion in
-as a pull request on our `GitHub site <https://github.com/lammps/lammps>`_,
+LAMMPS as a pull request on our `GitHub site
-after reading about :doc:`how to prepare your code for submission <Modify_contribute>`
+<https://github.com/lammps/lammps>`_, after reading about :doc:`how to
-and :doc:`the style requirements and recommendations <Modify_style>`.
+prepare your code for submission <Modify_contribute>` and :doc:`the
+style requirements and recommendations <Modify_style>`.
 
 .. toctree::
    :maxdepth: 1

doc/src/Modify_contribute.rst

@@ -27,11 +27,10 @@ join the `LAMMPS developers on Slack <https://lammps.slack.com>`_.  This
 slack work space is by invitation only.  Thus for access, please send an
 e-mail to ``slack@lammps.org`` explaining what part of LAMMPS you are
 working on.  Only discussions related to LAMMPS development are
-tolerated in that work space, so this is **NOT** for people that look for
+tolerated in that work space, so this is **NOT** for people that look
-help with compiling, installing, or using LAMMPS.  Please post a message
+for help with compiling, installing, or using LAMMPS.  Please post a
-to the `lammps-users mailing list <https://www.lammps.org/mail.html>`_
+message to the `LAMMPS forum <https://www.lammps.org/forum.html>`_ for
-or the `LAMMPS forum <https://www.lammps.org/forum.html>`_ for those
+those purposes.
-purposes.
 
 Packages versus individual files
 --------------------------------

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
+The best way to add a new feature to LAMMPS is to find a similar feature
-feature and look at the corresponding source and header files to figure
+and look at the corresponding source and header files to figure out what
-out what it does.  You will need some knowledge of C++ to be able to
+it does.  You will need some knowledge of C++ to be able to understand
-understand the high-level structure of LAMMPS and its class
+the high-level structure of LAMMPS and its class organization, but
-organization, but functions (class methods) that do actual
+functions (class methods) that do actual computations are mostly written
-computations are written in vanilla C-style code and operate on simple
+in C-style code and operate on simple C-style data structures (vectors
-C-style data structures (vectors and arrays).
+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_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
+string functions of the C library.  In addition a collection of
-:doc:`utility functions and classes <Developer_utils>` for recurring
+convenient :doc:`utility functions and classes <Developer_utils>` for
-tasks are provided.
+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
+important to maintain portability and availability of LAMMPS on many
-environments, which tend to be running older software stacks and LAMMPS
+platforms.  This applies especially to HPC cluster environments, which
-users may be required to use those older tools or not have the option to
+tend to be running older software stacks and LAMMPS users may be
-install newer compilers.
+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
+The ``Thermo`` class computes and prints thermodynamic information to
-to the screen and log file; see the file thermo.cpp.
+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
+There are four styles defined in ``thermo.cpp``: "one", "multi", "yaml",
-is also a flexible "custom" style which allows the user to explicitly
+and "custom".  The "custom" style allows the user to explicitly list
-list keywords for quantities to print when thermodynamic info is
+keywords for individual quantities to print when thermodynamic output is
-output.  See the :doc:`thermo_style <thermo_style>` command for a list
+generated.  The others have a fixed list of keywords.  See the
-of defined quantities.
+: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.
+The thermo styles (one, multi, etc) are defined by lists of keywords
-Adding a new style thus only requires defining a new list of keywords.
+with associated formats for integer and floating point numbers and
-Search for the word "customize" with references to "thermo style" in
+identified but an enumerator constant.  Adding a new style thus mostly
-thermo.cpp to see the two locations where code will need to be added.
+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
+New thermodynamic keywords can also be added to ``thermo.cpp`` to
-for output.  Search for the word "customize" with references to
+compute new quantities for output.  Search for the word "CUSTOMIZATION"
-"keyword" in thermo.cpp to see the several locations where code will
+with references to "keyword" in ``thermo.cpp`` to see the several
-need to be added.
+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
+.. note::
-for thermo output of quantities calculated by :doc:`fixes <fix>`,
+
-:doc:`computes <compute>`, and :doc:`variables <variable>`.  Thus, it may
+   The third argument to ``Thermo::addfield()`` is a flag indicating
-be simpler to compute what you wish via one of those constructs, than
+   whether the function for the keyword computes a floating point
-by adding a new keyword to the thermo command.
+   (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>`
+The ``Variable`` class computes and stores :doc:`variable <variable>`
-information in LAMMPS; see the file variable.cpp.  The value
+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
+command (which can then be accessed by variables) is discussed in the
-:doc:`Modify thermo <Modify_thermo>` doc page.
+: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
+``Variable::evaluate()`` method.  Search for the word "customize" to
-the appropriate location.  You may need to add a new method to the
+find the appropriate location.  You may need to add a new method to the
-Group class as well (see the group.cpp file).
+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>`
@@ -73,7 +73,6 @@ page gives those details.
    * :ref:`MDI <PKG-MDI>`
    * :ref:`MEAM <PKG-MEAM>`
    * :ref:`MESONT <PKG-MESONT>`
-   * :ref:`MESSAGE <PKG-MESSAGE>`
    * :ref:`MGPT <PKG-MGPT>`
    * :ref:`MISC <PKG-MISC>`
    * :ref:`ML-HDNNP <PKG-ML-HDNNP>`
@@ -1422,17 +1421,25 @@ MDI package
 
 **Contents:**
 
-A LAMMPS command and fix to allow client-server coupling of LAMMPS to
+A LAMMPS command and fixes to allow client-server coupling of LAMMPS
-other atomic or molecular simulation codes via the `MolSSI Driver Interface
+to other atomic or molecular simulation codes or materials modeling
+workflows via the `MolSSI Driver Interface
 (MDI) library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_.
 
 **Author:** Taylor Barnes - MolSSI, taylor.a.barnes at gmail.com
 
+**Install:**
+
+This package has :ref:`specific installation instructions <mdi>` on
+the :doc:`Build extras <Build_extras>` page.
+
 **Supporting info:**
 
 * src/MDI/README
-* :doc:`mdi/engine <mdi_engine>`
+* lib/mdi/README
-* :doc:`fix mdi/engine <fix_mdi_engine>`
+* :doc:`Howto MDI <Howto_mdi>`
+* :doc:`mdi <mdi>`
+* :doc:`fix mdi/aimd <fix_mdi_aimd>`
 * examples/PACKAGES/mdi
 
 ----------
@@ -1509,32 +1516,6 @@ Philipp Kloza (U Cambridge)
 
 ----------
 
-.. _PKG-MESSAGE:
-
-MESSAGE package
----------------
-
-**Contents:**
-
-Commands to use LAMMPS as either a client or server and couple it to
-another application.
-
-**Install:**
-
-This package has :ref:`specific installation instructions <message>` on the :doc:`Build extras <Build_extras>` page.
-
-**Supporting info:**
-
-* src/MESSAGE: filenames -> commands
-* lib/message/README
-* :doc:`message <message>`
-* :doc:`fix client/md <fix_client_md>`
-* :doc:`server md <server_md>`
-* :doc:`server mc <server_mc>`
-* examples/message
-
-----------
-
 .. _PKG-MGPT:
 
 MGPT package
@@ -2180,6 +2161,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/Packages_list.rst

@@ -249,7 +249,7 @@ whether an extra library is needed to build and use the package:
      - n/a
      - no
    * - :ref:`MDI <PKG-MDI>`
-     - client-server coupling
+     - client-server code coupling
      - :doc:`MDI Howto <Howto_mdi>`
      - PACKAGES/mdi
      - ext
@@ -263,11 +263,6 @@ whether an extra library is needed to build and use the package:
      - pair styles :doc:`mesont/tpm <pair_mesont_tpm>`, :doc:`mesocnt <pair_mesocnt>`
      - PACKAGES/mesont
      - int
-   * - :ref:`MESSAGE <PKG-MESSAGE>`
-     - client/server messaging
-     - :doc:`message <message>`
-     - message
-     - int
    * - :ref:`MGPT <PKG-MGPT>`
      - fast MGPT multi-ion potentials
      - :doc:`pair_style mgpt <pair_mgpt>`

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
+LAMMPS Python package (``lammps``) into a location where the Python
-Python interpreter can find it and installing the LAMMPS shared library
+interpreter can find it and installing the LAMMPS shared library into a
-into a folder that the dynamic loader searches or inside of the installed
+folder that the dynamic loader searches or inside of the installed
-``lammps`` package folder.  There are multiple ways to achieve
+``lammps`` package folder.  There are multiple ways to achieve this.
-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
+      This will try to build a so-called (binary) 'wheel', a compressed
-      package into a system folder and if that fails (due to missing
+      binary python package and then install it with the python package
-      write permissions) will instead do the installation to a user
+      manager 'pip'.  Installation will be attempted into a system-wide
-      folder under ``$HOME/.local``.  For a system-wide installation you
+      ``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                                                       |
+      | File                   | Location                                                 | Notes                                                       |
-      +========================+=================================================================+=============================================================+
+      +========================+==========================================================+=============================================================+
-      | LAMMPS Python package  | * ``$HOME/.local/lib/pythonX.Y/site-packages/lammps`` (32bit)   | ``X.Y`` depends on the installed Python version             |
+      | LAMMPS Python package  | * ``$HOME/.local/lib/pythonX.Y/site-packages/lammps``    | ``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``    | ``X.Y`` depends on the installed Python version             |
-      | 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) |                                                             |
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
 
       For a system-wide installation those folders would then become.
 
-      +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
+      +------------------------+-------------------------------------------------+-------------------------------------------------------------+
-      | File                   | Location                                                | Notes                                                       |
+      | File                   | Location                                        | Notes                                                       |
-      +========================+=========================================================+=============================================================+
+      +========================+=================================================+=============================================================+
-      | LAMMPS Python package  | * ``/usr/lib/pythonX.Y/site-packages/lammps`` (32bit)   | ``X.Y`` depends on the installed Python version             |
+      | LAMMPS Python package  | * ``/usr/lib/pythonX.Y/site-packages/lammps``   | ``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``   | ``X.Y`` depends on the installed Python version             |
-      | 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) |                                                             |
-      +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
 
       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 ``-n`` instructs the script to only build a wheel file
-      * and the optional ``-d`` flag to a custom (legacy) installation folder
+        but not attempt to install it.
-
-      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".
 
    .. tab:: Virtual environment
 
@@ -257,32 +266,29 @@ this.
       package and the shared library file are installed into the
       following locations:
 
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
+      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
-      | File                   | Location                                                        | Notes                                                       |
+      | File                   | Location                                               | Notes                                                       |
-      +========================+=================================================================+=============================================================+
+      +========================+========================================================+=============================================================+
-      | LAMMPS Python Module   | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps`` (32bit)   | ``X.Y`` depends on the installed Python version             |
+      | LAMMPS Python Module   | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps``  | ``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``  | ``X.Y`` depends on the installed Python version             |
-      | 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) |                                                             |
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
 
       If you do a full installation (CMake only) with "install", this
       leads to the following installation locations:
 
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
+      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
-      | File                   | Location                                                        | Notes                                                       |
+      | File                   | Location                                               | Notes                                                       |
-      +========================+=================================================================+=============================================================+
+      +========================+========================================================+=============================================================+
-      | LAMMPS Python Module   | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps`` (32bit)   | ``X.Y`` depends on the installed Python version             |
+      | LAMMPS Python Module   | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps``  | ``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         |
-      | 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)                           |
-      |                        | * ``$VIRTUAL_ENV/lib64/`` (64bit)                               | (see below for more info on this)                           |
+      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
+      | LAMMPS executable      | * ``$VIRTUAL_ENV/bin/``                                |                                                             |
-      | LAMMPS executable      | * ``$VIRTUAL_ENV/bin/``                                         |                                                             |
+      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
+      | LAMMPS potential files | * ``$VIRTUAL_ENV/share/lammps/potentials/``            | Set ``LAMMPS_POTENTIALS`` environment variable to this path |
-      | 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_options.rst

@@ -226,15 +226,6 @@ other executable(s) perform an MPI_Comm_split() with their own colors
 to shrink the MPI_COMM_WORLD communication to be the subset of
 processors they are actually running on.
 
-Currently, this is only used in LAMMPS to perform client/server
-messaging with another application.  LAMMPS can act as either a client
-or server (or both).  More details are given on the :doc:`Howto client/server <Howto_client_server>` doc page.
-
-Specifically, this refers to the "mpi/one" mode of messaging provided
-by the :doc:`message <message>` command and the CSlib library LAMMPS
-links with from the lib/message directory.  See the
-:doc:`message <message>` command for more details.
-
 ----------
 
 .. _cite:

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
+The tools/eam_database directory contains a Fortran and a Python program
-generate EAM alloy setfl potential files for any combination of 16
+that will generate EAM alloy setfl potential files for any combination
-elements: Cu, Ag, Au, Ni, Pd, Pt, Al, Pb, Fe, Mo, Ta, W, Mg, Co, Ti,
+of the 17 elements: Cu, Ag, Au, Ni, Pd, Pt, Al, Pb, Fe, Mo, Ta, W, Mg,
-Zr.  The files can then be used with the :doc:`pair_style eam/alloy <pair_eam>` command.
+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,
+The Fortran version of the tool was authored by Xiaowang Zhou (Sandia),
-and is based on his paper:
+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/commands_list.rst

@@ -59,8 +59,7 @@ Commands
    lattice
    log
    mass
-   mdi_engine
+   mdi
-   message
    min_modify
    min_spin
    min_style
@@ -96,9 +95,6 @@ Commands
    restart
    run
    run_style
-   server
-   server_mc
-   server_md
    set
    shell
    special_bonds

doc/src/compute.rst

@@ -208,7 +208,8 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`erotate/sphere/atom <compute_erotate_sphere_atom>` - rotational energy for each spherical particle
 * :doc:`event/displace <compute_event_displace>` - detect event on atom displacement
 * :doc:`fabric <compute_fabric>` - calculates fabric tensors from pair interactions
-* :doc:`fep <compute_fep>` -
+* :doc:`fep <compute_fep>` - compute free energies for alchemical transformation from perturbation theory
+* :doc:`fep/ta <compute_fep_ta>` - compute free energies for a test area perturbation
 * :doc:`force/tally <compute_tally>` - force between two groups of atoms via the tally callback mechanism
 * :doc:`fragment/atom <compute_cluster_atom>` - fragment ID for each atom
 * :doc:`global/atom <compute_global_atom>` -
@@ -246,7 +247,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
@@ -289,8 +289,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_fep_ta.rst

@@ -0,0 +1,99 @@
+.. index:: compute fep/ta
+
+compute fep/ta command
+======================
+
+Syntax
+""""""
+
+.. parsed-literal::
+
+   compute ID group-ID fep/ta temp plane scale_factor keyword value ...
+
+* ID, group-ID are documented in the :doc:`compute <compute>` command
+* fep/ta = name of this compute command
+* temp = external temperature (as specified for constant-temperature run)
+* plane = *xy* or *xz* or *yz*
+* scale_factor = multiplicative factor for change in plane area
+* zero or more keyword/value pairs may be appended
+* keyword = *tail*
+
+  .. parsed-literal::
+
+       *tail* value = *no* or *yes*
+         *no* = ignore tail correction to pair energies (usually small in fep)
+         *yes* = include tail correction to pair energies
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   compute 1 all fep/ta 298 xy 1.0005
+
+Description
+"""""""""""
+
+Define a computation that calculates the change in the free energy due
+to a test-area (TA) perturbation :ref:`(Gloor) <Gloor>`. The test-area
+approach can be used to determine the interfacial tension of the system
+in a single simulation:
+
+.. math::
+
+   \gamma = \lim_{\Delta \mathcal{A} \to 0} \left( \frac{\Delta A_{0 \to 1 }}{\Delta \mathcal{A}}\right)_{N,V,T}
+   = - \frac{kT}{\Delta \mathcal{A}} \ln \left< \exp(-(U_1 - U_0)/kT) \right>_0
+
+During the perturbation, both axes of *plane* are scaled by multiplying
+:math:`\sqrt{scale\_factor}`, while the other axis divided by
+*scale_factor* such that the overall volume of the system is maintained.
+
+The *tail* keyword controls the calculation of the tail correction to
+"van der Waals" pair energies beyond the cutoff, if this has been
+activated via the :doc:`pair_modify <pair_modify>` command. If the
+perturbation is small, the tail contribution to the energy difference
+between the reference and perturbed systems should be negligible.
+
+----------
+
+Output info
+"""""""""""
+
+This compute calculates a global vector of length 3 which contains the
+energy difference ( :math:`U_1-U_0` ) as c_ID[1], the Boltzmann factor
+:math:`\exp(-(U_1-U_0)/kT)`, as c_ID[2] and the change in the *plane*
+area :math:`\Delta \mathcal{A}` as c_ID[3]. :math:`U_1` is the potential
+energy of the perturbed state and :math:`U_0` is the potential energy of
+the reference state.  The energies include kspace terms if these are
+used in the simulation.
+
+These output results can be used by any command that uses a global
+scalar or vector from a compute as input.  See the :doc:`Howto output
+<Howto_output>` page for an overview of LAMMPS output options. For
+example, the computed values can be averaged using :doc:`fix ave/time
+<fix_ave_time>`.
+
+Restrictions
+""""""""""""
+
+Constraints, like fix shake, may lead to incorrect values for energy difference.
+
+This compute is distributed as the FEP 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 fep <compute_fep>`
+
+Default
+"""""""
+
+The option defaults are *tail* = *no*\ .
+
+----------
+
+.. _Gloor:
+
+**(Gloor)** Gloor, J Chem Phys, 123, 134703 (2005)

doc/src/compute_momentum.rst

@@ -23,11 +23,10 @@ Examples
 Description
 """""""""""
 
-Define a computation that calculates the translational momentum
+Define a computation that calculates the translational momentum *p*
-of a group of particles.
+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 momentum of each particles is computed as m v, where m and v are
+the mass and velocity vector of the particle, respectively.
-the mass and velocity of the particle.
 
 Output info
 """""""""""

doc/src/compute_msd.rst

@@ -75,10 +75,11 @@ solids undergoing thermal motion.
 .. note::
 
    Initial coordinates are stored in "unwrapped" form, by using the
-   image flags associated with each atom.  See the :doc:`dump custom <dump>` command for a discussion of "unwrapped" coordinates.
+   image flags associated with each atom.  See the :doc:`dump custom
-   See the Atoms section of the :doc:`read_data <read_data>` command for a
+   <dump>` command for a discussion of "unwrapped" coordinates.  See the
-   discussion of image flags and how they are set for each atom.  You can
+   Atoms section of the :doc:`read_data <read_data>` command for a
-   reset the image flags (e.g. to 0) before invoking this compute by
+   discussion of image flags and how they are set for each atom.  You
+   can reset the image flags (e.g. to 0) before invoking this compute by
    using the :doc:`set image <set>` command.
 
 .. note::
@@ -108,7 +109,8 @@ distance\^2 :doc:`units <units>`.
 
 Restrictions
 """"""""""""
- none
+
+Compute *msd* cannot be used with a dynamic group.
 
 Related commands
 """"""""""""""""

doc/src/compute_msd_nongauss.rst

@@ -74,8 +74,11 @@ the third is dimensionless.
 Restrictions
 """"""""""""
 
-This compute is part of the EXTRA-COMPUTE package.  It is only enabled if
+Compute *msd/nongauss* cannot be used with a dynamic group.
-LAMMPS was built with that package.  See the :doc:`Build package <Build_package>` page for more info.
+
+This compute is part of the EXTRA-COMPUTE package.  It is only enabled
+if LAMMPS was built with that package.  See the :doc:`Build package
+<Build_package>` page for more info.
 
 Related commands
 """"""""""""""""

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 pairwise 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_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
+- Compute *pe/tally* calculates a global scalar (the energy) and a per
-atom scalar (the contributions of the single atom to the global
+  atom scalar (the contributions of the single atom to the global
-scalar). Compute *pe/mol/tally* calculates a global 4-element vector
+  scalar).
-containing (in this order): *evdwl* and *ecoul* for intramolecular pairs
+
-and *evdwl* and *ecoul* for intermolecular pairs. Since molecules are
+- Compute *pe/mol/tally* calculates a global 4-element vector containing
-identified by their molecule IDs, the partitioning does not have to be
+  (in this order): *evdwl* and *ecoul* for intramolecular pairs and
-related to molecules, but the energies are tallied into the respective
+  *evdwl* and *ecoul* for intermolecular pairs. Since molecules are
-slots depending on whether the molecule IDs of a pair are the same or
+  identified by their molecule IDs, the partitioning does not have to be
-different. Compute *force/tally* calculates a global scalar (the force
+  related to molecules, but the energies are tallied into the respective
-magnitude) and a per atom 3-element vector (force contribution from
+  slots depending on whether the molecule IDs of a pair are the same or
-each atom).  Compute *stress/tally* calculates a global scalar
+  different.
-(average of the diagonal elements of the stress tensor) and a per atom
+
-vector (the 6 elements of stress tensor contributions from the
+- Compute *force/tally* calculates a global scalar (the force magnitude)
-individual atom). As in :doc:`compute heat/flux <compute_heat_flux>`,
+  and a per atom 3-element vector (force contribution from each atom).
-compute *heat/flux/tally* calculates a global vector of length 6,
+
-where the first 3 components are the :math:`x`, :math:`y`, :math:`z`
+- Compute *stress/tally* calculates a global scalar
-components of the full heat flow vector,
+  (average of the diagonal elements of the stress tensor) and a per atom
-and the next 3 components are the corresponding components
+  vector (the 6 elements of stress tensor contributions from the
-of just the convective portion of the flow, i.e. the
+  individual atom).
-first term in the equation for :math:`\mathbf{Q}`.
+
-Compute *heat/flux/virial/tally* calculates a global scalar (heat flow)
+- As in :doc:`compute heat/flux <compute_heat_flux>`,
-and a per atom 3-element vector
+  compute *heat/flux/tally* calculates a global vector of length 6,
-(contribution to the force acting over atoms in the first group
+  where the first 3 components are the :math:`x`, :math:`y`, :math:`z`
-from individual atoms in both groups).
+  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/dump.rst

@@ -36,7 +36,7 @@ Syntax
 
 * ID = user-assigned name for the dump
 * group-ID = ID of the group of atoms to be dumped
-* style = *atom* or *atom/gz* or *atom/zstd or *atom/mpiio* or *cfg* or *cfg/gz* or *cfg/zstd* or *cfg/mpiio* or *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *dcd* or *h5md* or *image* or *local* or *local/gz* or *local/zstd* or *molfile* or *movie* or *netcdf* or *netcdf/mpiio* or *vtk* or *xtc* or *xyz* or *xyz/gz* or *xyz/zstd* or *xyz/mpiio*
+* style = *atom* or *atom/gz* or *atom/zstd or *atom/mpiio* or *cfg* or *cfg/gz* or *cfg/zstd* or *cfg/mpiio* or *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *dcd* or *h5md* or *image* or *local* or *local/gz* or *local/zstd* or *molfile* or *movie* or *netcdf* or *netcdf/mpiio* or *vtk* or *xtc* or *xyz* or *xyz/gz* or *xyz/zstd* or *xyz/mpiio* or *yaml*
 * N = dump every this many timesteps
 * file = name of file to write dump info to
 * args = list of arguments for a particular style
@@ -68,8 +68,9 @@ Syntax
        *xyz/gz* args = none
        *xyz/zstd* args = none
        *xyz/mpiio* args = none
+       *yaml* args = same as *custom* args, see below
 
-* *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *netcdf* or *netcdf/mpiio* args = list of atom attributes
+* *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *netcdf* or *netcdf/mpiio* or *yaml* args = list of atom attributes
 
   .. parsed-literal::
 
@@ -386,6 +387,70 @@ from using the (numerical) atom type to an element name (or some
 other label). This will help many visualization programs to guess
 bonds and colors.
 
+Dump style *yaml* has the same command syntax as style *custom* and
+writes YAML format files that can be easily parsed by a variety of data
+processing tools and programming languages.  Each timestep will be
+written as a YAML "document" (i.e. starts with "---" and ends with
+"...").  The style supports writing one file per timestep through the
+"\*" wildcard but not multi-processor outputs with the "%" token in the
+filename.  In addition to per-atom data, :doc:`thermo <thermo>` data can
+be included in the *yaml* style dump file using the :doc:`dump_modify
+thermo yes <dump_modify>`. The data included in the dump file uses the
+"thermo" tag and is otherwise identical to data specified by the
+:doc:`thermo_style <thermo_style>` command.
+
+Below is an example for a YAML format dump created by the following commands.
+
+.. code-block:: LAMMPS
+
+   dump out all yaml 100 dump.yaml id type x y z vx vy vz ix iy iz
+   dump_modify out time yes units yes thermo yes format 1 %5d format "% 10.6e"
+
+The tags "time", "units", and "thermo" are optional and enabled by the
+dump_modify command. The list under the "box" tag has 3 lines for
+orthogonal boxes and 4 lines with triclinic boxes, where the first 3 are
+the box boundaries and the 4th the three tilt factors (xy, xz, yz).  The
+"thermo" data follows the format of the *yaml* thermo style.  The
+"keywords" tag lists the per-atom properties contained in the "data"
+columns, which contain a list with one line per atom.  The keywords may
+be renamed using the dump_modify command same as for the *custom* dump
+style.
+
+.. code-block:: yaml
+
+   ---
+   timestep: 0
+   units: lj
+   time: 0
+   natoms: 4000
+   boundary: [ p, p, p, p, p, p, ]
+   thermo:
+     - keywords: [ Step, Temp, E_pair, E_mol, TotEng, Press, ]
+     - data: [ 0, 0, -27093.472213010766, 0, 0, 0, ]
+   box:
+     - [ 0, 16.795961913825074 ]
+     - [ 0, 16.795961913825074 ]
+     - [ 0, 16.795961913825074 ]
+     - [ 0, 0, 0 ]
+   keywords: [ id, type, x, y, z, vx, vy, vz, ix, iy, iz,  ]
+   data:
+     - [     1 , 1 ,  0.000000e+00 ,  0.000000e+00 ,  0.000000e+00 ,  -1.841579e-01 , -9.710036e-01 , -2.934617e+00 , 0 , 0 , 0, ]
+     - [     2 , 1 ,  8.397981e-01 ,  8.397981e-01 ,  0.000000e+00 ,  -1.799591e+00 ,  2.127197e+00 ,  2.298572e+00 , 0 , 0 , 0, ]
+     - [     3 , 1 ,  8.397981e-01 ,  0.000000e+00 ,  8.397981e-01 ,  -1.807682e+00 , -9.585130e-01 ,  1.605884e+00 , 0 , 0 , 0, ]
+
+     [...]
+   ...
+   ---
+   timestep: 100
+   units: lj
+   time: 0.5
+
+     [...]
+
+   ...
+
+----------
+
 Note that *atom*, *custom*, *dcd*, *xtc*, and *xyz* style dump files
 can be read directly by `VMD <http://www.ks.uiuc.edu/Research/vmd>`_, a
 popular molecular viewing program.
@@ -427,9 +492,9 @@ If a "%" character appears in the filename, then each of P processors
 writes a portion of the dump file, and the "%" character is replaced
 with the processor ID from 0 to P-1.  For example, tmp.dump.% becomes
 tmp.dump.0, tmp.dump.1, ... tmp.dump.P-1, etc.  This creates smaller
-files and can be a fast mode of output on parallel machines that
+files and can be a fast mode of output on parallel machines that support
-support parallel I/O for output. This option is not available for the
+parallel I/O for output. This option is **not** available for the *dcd*,
-*dcd*, *xtc*, and *xyz* styles.
+*xtc*, *xyz*, and *yaml* styles.
 
 By default, P = the number of processors meaning one file per
 processor, but P can be set to a smaller value via the *nfile* or
@@ -722,8 +787,8 @@ 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* and *dcd* styles are part of the EXTRA-DUMP package.  They
+The *xtc*, *dcd* and *yaml* styles are part of the EXTRA-DUMP package.
-are only enabled if LAMMPS was built with that package.  See the
+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_adios.rst

@@ -35,13 +35,21 @@ Examples
 Description
 """""""""""
 
-Dump a snapshot of atom coordinates every N timesteps in the
+Dump a snapshot of atom coordinates every N timesteps in the `ADIOS
-`ADIOS <adios_>`_ based "BP" file format, or using different I/O solutions in ADIOS,
+<adios_>`_ based "BP" file format, or using different I/O solutions in
-to a stream that can be read on-line by another program.
+ADIOS, to a stream that can be read on-line by another program.
 ADIOS-BP files are binary, portable and self-describing.
 
 .. _adios: https://github.com/ornladios/ADIOS2
 
+.. note::
+
+   To be able to use ADIOS, a file ``adios2_config.xml`` with specific
+   configuration settings is expected in the current working directory.
+   If the file is not present, LAMMPS will try to create a minimal
+   default file.  Please refer to the ADIOS documentation for details on
+   how to adjust this file for optimal performance and desired features.
+
 **Use from write_dump:**
 
 It is possible to use these dump styles with the

doc/src/dump_modify.rst

@@ -26,6 +26,10 @@ Syntax
          N = index of frame written upon first dump
        *balance* arg = *yes* or *no*
        *buffer* arg = *yes* or *no*
+       *colname* values =  ID string, or *default*
+         string = new column header name
+         ID = integer from 1 to N, or integer from -1 to -N, where N = # of quantities being output
+              *or* a custom dump keyword or reference to compute, fix, property or variable.
        *delay* arg = Dstep
          Dstep = delay output until this timestep
        *element* args = E1 E2 ... EN, where N = # of atom types
@@ -40,9 +44,10 @@ Syntax
          Np = write one file for every this many processors
        *first* arg = *yes* or *no*
        *flush* arg = *yes* or *no*
-       *format* args = *line* string, *int* string, *float* string, M string, or *none*
+       *format* args = *line* string, *int* string, *float* string, ID string, or *none*
          string = C-style format string
-         M = integer from 1 to N, where N = # of per-atom quantities being output
+         ID = integer from 1 to N, or integer from -1 to -N, where N = # of quantities being output
+              *or* a custom dump keyword or reference to compute, fix, property or variable.
        *header* arg = *yes* or *no*
          *yes* to write the header
          *no* to not write the header
@@ -375,6 +380,29 @@ performed with dump style *xtc*\ .
 
 ----------
 
+The *colname* keyword can be used to change the default header keyword
+for dump styles: *atom*, *custom*, and *cfg* and their compressed, ADIOS,
+and MPIIO variants.  The setting for *ID string* replaces the default
+text with the provided string.  *ID* can be a positive integer when it
+represents the column number counting from the left, a negative integer
+when it represents the column number from the right (i.e. -1 is the last
+column/keyword), or a custom dump keyword (or compute, fix, property, or
+variable reference) and then it replaces the string for that specific
+keyword. For *atom* dump styles only the keywords "id", "type", "x",
+"y", "z", "ix", "iy", "iz" can be accessed via string regardless of
+whether scaled or unwrapped coordinates were enabled or disabled, and
+it always assumes 8 columns for indexing regardless of whether image
+flags are enabled or not.  For dump style *cfg* only the "auxiliary"
+keywords (6th or later keyword) may be changed and the column indexing
+considers only them (i.e. the 6th keyword is the the 1st column).
+
+The *colname* keyword can be used multiple times. If multiple *colname*
+settings refer to the same keyword, the last setting has precedence.  A
+setting of *default* clears all previous settings, reverting all values
+to their default names.
+
+----------
+
 The *format* keyword can be used to change the default numeric format output
 by the text-based dump styles: *atom*, *local*, *custom*, *cfg*, and
 *xyz* styles, and their MPIIO variants. Only the *line* or *none*
@@ -684,8 +712,8 @@ run, this option is ignored since the output is already balanced.
 
 ----------
 
-The *thermo* keyword only applies the dump *netcdf* style.  It
+The *thermo* keyword only applies the dump styles *netcdf* and *yaml*.
-triggers writing of :doc:`thermo <thermo>` information to the dump file
+It triggers writing of :doc:`thermo <thermo>` information to the dump file
 alongside per-atom data.  The values included in the dump file are
 identical to the values specified by :doc:`thermo_style <thermo_style>`.
 

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

@@ -194,10 +194,10 @@ accelerated styles exist.
 * :doc:`bond/swap <fix_bond_swap>` - Monte Carlo bond swapping
 * :doc:`box/relax <fix_box_relax>` - relax box size during energy minimization
 * :doc:`charge/regulation <fix_charge_regulation>` - Monte Carlo sampling of charge regulation
-* :doc:`client/md <fix_client_md>` - MD client for client/server simulations
 * :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
@@ -243,12 +243,10 @@ 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
-* :doc:`mdi/engine <fix_mdi_engine>` - connect LAMMPS to external programs via the MolSSI Driver Interface (MDI)
+* :doc:`mdi/aimd <fix_mdi_aimd>` - LAMMPS operates as driver for ab initio MD (AIMD) via the MolSSI Driver Interface (MDI)
 * :doc:`meso/move <fix_meso_move>` - move mesoscopic SPH/SDPD particles in a prescribed fashion
 * :doc:`mol/swap <fix_mol_swap>` - Monte Carlo atom type swapping with a molecule
 * :doc:`momentum <fix_momentum>` - zero the linear and/or angular momentum of a group of atoms
@@ -274,7 +272,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
@@ -390,6 +389,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_acks2_reaxff.rst

@@ -19,6 +19,12 @@ Syntax
 * cutlo,cuthi = lo and hi cutoff for Taper radius
 * tolerance = precision to which charges will be equilibrated
 * params = reaxff or a filename
+* one or more keywords or keyword/value pairs may be appended
+
+  .. parsed-literal::
+
+     keyword = *maxiter*
+       *maxiter* N = limit the number of iterations to *N*
 
 Examples
 """"""""
@@ -26,7 +32,7 @@ Examples
 .. code-block:: LAMMPS
 
    fix 1 all acks2/reaxff 1 0.0 10.0 1.0e-6 reaxff
-   fix 1 all acks2/reaxff 1 0.0 10.0 1.0e-6 param.acks2
+   fix 1 all acks2/reaxff 1 0.0 10.0 1.0e-6 param.acks2 maxiter 500
 
 Description
 """""""""""
@@ -44,14 +50,14 @@ the charge equilibration performed by fix acks2/reaxff, see the
 
 The ACKS2 method minimizes the electrostatic energy of the system by
 adjusting the partial charge on individual atoms based on interactions
-with their neighbors. It requires some parameters for each atom type.
+with their neighbors.  It requires some parameters for each atom type.
 If the *params* setting above is the word "reaxff", then these are
 extracted from the :doc:`pair_style reaxff <pair_reaxff>` command and
 the ReaxFF force field file it reads in.  If a file name is specified
-for *params*\ , then the parameters are taken from the specified file
+for *params*, then the parameters are taken from the specified file
-and the file must contain one line for each atom type.  The latter form
+and the file must contain one line for each atom type.  The latter
-must be used when performing QeQ with a non-ReaxFF potential.  The lines
+form must be used when performing QeQ with a non-ReaxFF potential.
-should be formatted as follows:
+The lines should be formatted as follows:
 
 .. parsed-literal::
 
@@ -67,13 +73,25 @@ ReaxFF potential file, except that eta is defined here as twice the eta
 value in the ReaxFF file. Note that unlike the rest of LAMMPS, the units
 of this fix are hard-coded to be A, eV, and electronic charge.
 
-**Restart, fix_modify, output, run start/stop, minimize info:**
+The optional *maxiter* keyword allows changing the max number
+of iterations in the linear solver. The default value is 200.
+
+.. note::
+
+   In order to solve the self-consistent equations for electronegativity
+   equalization, LAMMPS imposes the additional constraint that all the
+   charges in the fix group must add up to zero.  The initial charge
+   assignments should also satisfy this constraint.  LAMMPS will print a
+   warning if that is not the case.
+
+Restart, fix_modify, output, run start/stop, minimize info
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
 No information about this fix is written to :doc:`binary restart files
-<restart>`.  No global scalar or vector or per-atom quantities are
+<restart>`.  This fix computes a global scalar (the number of
-stored by this fix for access by various :doc:`output commands
+iterations) for access by various :doc:`output commands <Howto_output>`.
-<Howto_output>`.  No parameter of this fix can be used with the
+No parameter of this fix can be used with the *start/stop* keywords of
-*start/stop* keywords of the :doc:`run <run>` command.
+the :doc:`run <run>` command.
 
 This fix is invoked during :doc:`energy minimization <minimize>`.
 
@@ -86,12 +104,12 @@ This fix is invoked during :doc:`energy minimization <minimize>`.
 Restrictions
 """"""""""""
 
-This fix is part of the REAXFF package.  It is only enabled if LAMMPS
+This fix is part of the REAXFF package.  It is only enabled if
-was built with that package.  See the :doc:`Build package
+LAMMPS was built with that package. See the :doc:`Build package
-<Build_package>` doc page for more info.
+<Build_package>` page for more info.
 
 This fix does not correctly handle interactions involving multiple
-periodic images of the same atom. Hence, it should not be used for
+periodic images of the same atom.  Hence, it should not be used for
 periodic cell dimensions less than 10 angstroms.
 
 This fix may be used in combination with :doc:`fix efield <fix_efield>`
@@ -105,7 +123,10 @@ Related commands
 
 :doc:`pair_style reaxff <pair_reaxff>`, :doc:`fix qeq/reaxff <fix_qeq_reaxff>`
 
-**Default:** none
+Default
+"""""""
+
+maxiter 200
 
 ----------
 

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."
+atomistic-to-continuum coupling method for heat transfer in solids."
- Special Issue of Computer Methods and Applied Mechanics (2008)
+Special Issue of Computer Methods and Applied Mechanics (2008)
- 197:3351.
+197:3351.
 
 .. _Zimmeman2004:
 
 **(Zimmerman2004)** Zimmerman, JA; Webb, EB; Hoyt, JJ;. Jones, RE;
- Klein, PA; Bammann, DJ, "Calculation of stress in atomistic
+Klein, PA; Bammann, DJ, "Calculation of stress in atomistic
- simulation." Special Issue of Modelling and Simulation in Materials
+simulation." Special Issue of Modelling and Simulation in Materials
- Science and Engineering (2004), 12:S319.
+Science and Engineering (2004), 12:S319.
 
 .. _Zimmerman2010:
 
 **(Zimmerman2010)** Zimmerman, JA; Jones, RE; Templeton, JA, "A
- material frame approach for evaluating continuum variables in
+material frame approach for evaluating continuum variables in
- atomistic simulations." Journal of Computational Physics (2010),
+atomistic simulations." Journal of Computational Physics (2010),
- 229:2364.
+229:2364.
 
 .. _Templeton2010:
 
 **(Templeton2010)** Templeton, JA; Jones, RE; Wagner, GJ, "Application
- of a field-based method to spatially varying thermal transport
+of a field-based method to spatially varying thermal transport
- problems in molecular dynamics." Modelling and Simulation in
+problems in molecular dynamics." Modelling and Simulation in
- Materials Science and Engineering (2010), 18:085007.
+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
+JA, "Electron transport enhanced molecular dynamics for metals and
- semi-metals." International Journal for Numerical Methods in
+semi-metals." International Journal for Numerical Methods in
- Engineering (2010), 83:940.
+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
+Wong, BM, "A long-range electric field solver for molecular dynamics
- based on atomistic-to-continuum modeling." Journal of Chemical Theory
+based on atomistic-to-continuum modeling." Journal of Chemical Theory
- and Computation (2011), 7:1736.
+and Computation (2011), 7:1736.
 
 .. _Mandadapu:
 
 **(Mandadapu)** Mandadapu, KK; Templeton, JA; Lee, JW, "Polarization
- as a field variable from molecular dynamics simulations." Journal of
+as a field variable from molecular dynamics simulations." Journal of
- Chemical Physics (2013), 139:054115.
+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_brownian.rst

@@ -23,7 +23,7 @@ Syntax
 * temp = temperature
 * seed = random number generator seed
 * one or more keyword/value pairs may be appended
-* keyword = *rng* or *dipole* or *gamma_r_eigen* or *gamma_t_eigen* or *gamma_r* or *gamma_t*
+* keyword = *rng* or *dipole* or *gamma_r_eigen* or *gamma_t_eigen* or *gamma_r* or *gamma_t* or *rotation_temp* or *planar_rotation*
 
   .. parsed-literal::
 
@@ -40,8 +40,10 @@ Syntax
         *gamma_t_eigen* values = *gt1* and *gt2* and *gt3* for *brownian/asphere*
          *gt1*, *gt2*, and *gt3* = diagonal entries of body frame translational friction tensor
         *gamma_t* values = *gt* for *brownian* and *brownian/sphere*
-         *gt* = magnitude of the (isotropic) translational friction tensor
+        *gt* = magnitude of the (isotropic) translational friction tensor
-
+        *rotation_temp* values = *T* for *brownian/sphere* and *brownian/asphere*
+        *T* = rotation temperature, which can be different then *temp* when out of equilibrium
+        *planar_rotation* values = None (constrains rotational diffusion to be in xy plane if in 3D)
 
 Examples
 """"""""
@@ -86,12 +88,45 @@ For the style *brownian/sphere*, the positions of the particles are
 updated, and a dipole slaved to the spherical orientation is also
 updated. This style therefore requires the hybrid atom style
 :doc:`atom_style dipole <atom_style>` and :doc:`atom_style sphere
-<atom_style>`.
+<atom_style>`. The equation of motion for the dipole is
+
+.. math::
+
+   \mathbf{\mu}(t+dt) = \frac{\mathbf{\mu}(t) + \mathbf{\omega} \times \mathbf{\mu}dt
+   }{|\mathbf{\mu}(t) + \mathbf{\omega} \times \mathbf{\mu}|}
+
+which correctly reproduces a Boltzmann distribution of orientations and
+rotational diffusion moments (see :ref:`(Ilie) <Ilie1>`) when
+
+.. math::
+
+   \mathbf{\omega} = \frac{\mathbf{T}}{\gamma_r} + \sqrt{\frac{2 k_B T_{rot}}{\gamma_r}\frac{d\mathbf{W}}{dt}},
+
+with :math:`d\mathbf{W}` being a random number with zero mean and variance :math:`dt`
+and :math:`T_{rot}` is *rotation_temp*.
 
 For the style *brownian/asphere*, the center of mass positions and the
 quaternions of ellipsoidal particles are updated. This fix style is
 suitable for equations of motion where the rotational and translational
-friction tensors can be diagonalized in a certain (body) reference frame.
+friction tensors can be diagonalized in a certain (body) reference
+frame. In this case, the rotational equation of motion is updated via
+the quaternion
+
+.. math::
+
+   \mathbf{q}(t+dt) = \frac{\mathbf{q}(t) + d\mathbf{q}}{|\mathbf{q}(t) + d\mathbf{q}|}
+
+which correctly reproduces a Boltzmann distribution of orientations and rotational
+diffusion moments (see :ref:`(Ilie) <Ilie1>`) when the quaternion step given by
+
+.. math::
+
+   d\mathbf{q} = \mathbf{\Psi}\mathbf{\omega}dt
+
+where :math:`\mathbf{Psi}` has rows :math:`(-q_1,-q_2,-q_3)`, :math:`(q_0,-q_3,q_2)`,
+:math:`(q_3,q_0,-q_1)`, and :math:`(-q_2,q_1,q_0)`. :math:`\mathbf{\omega}` is
+evaluated in the body frame of reference where the friction tensor is diagonal.
+See :ref:`(Delong) <Delong1>` for more details of a similar algorithm.
 
 
 ---------
@@ -99,13 +134,16 @@ friction tensors can be diagonalized in a certain (body) reference frame.
 .. note::
 
    This integrator does not by default assume a relationship between the
-   rotational and translational friction tensors, though such a relationship
+   rotational and translational friction tensors, though such a
-   should exist in the case of no-slip boundary conditions between the particles and
+   relationship should exist in the case of no-slip boundary conditions
-   the surrounding (implicit) solvent. E.g. in the case of spherical particles,
+   between the particles and the surrounding (implicit) solvent. E.g. in
-   the condition :math:`\gamma_t=3\gamma_r/\sigma^2` must be explicitly
+   the case of spherical particles, the condition
-   accounted for by setting *gamma_t* to 3x and *gamma_r* to x (where
+   :math:`\gamma_t=3\gamma_r/\sigma^2` must be explicitly accounted for
-   :math:`\sigma` is the spherical diameter). A similar (though more complex)
+   by setting *gamma_t* to 3x and *gamma_r* to x (where :math:`\sigma`
-   relationship holds for ellipsoids and rod-like particles.
+   is the spherical diameter). A similar (though more complex)
+   relationship holds for ellipsoids and rod-like particles. The
+   translational diffusion and rotational diffusion are given by
+   *temp/gamma_t* and *rotation_temp/gamma_r*.
 
 ---------
 
@@ -113,10 +151,10 @@ friction tensors can be diagonalized in a certain (body) reference frame.
 
    Temperature computation using the :doc:`compute temp <compute_temp>`
    will not correctly compute temperature of these overdamped dynamics
-   since we are explicitly neglecting inertial effects.
+   since we are explicitly neglecting inertial effects.  Furthermore,
-   Furthermore, this time integrator does not add the stochastic terms or
+   this time integrator does not add the stochastic terms or viscous
-   viscous terms to the force and/or torques.  Rather, they are just added
+   terms to the force and/or torques.  Rather, they are just added in to
-   in to the equations of motion to update the degrees of freedom.
+   the equations of motion to update the degrees of freedom.
 
 ---------
 
@@ -145,14 +183,22 @@ The units of *gamma_r* are mass*length**2/time.
 The *gamma_r_eigen*, and *gamma_t_eigen* keywords are the eigenvalues of
 the rotational and viscous damping tensors (having the same units as
 their isotropic counterparts). Required for (and only compatible with)
-*brownian/asphere*. For a 2D system, the first two values of *gamma_r_eigen*
+*brownian/asphere*. For a 2D system, the first two values of
-must be inf (only rotation in xy plane), and the third value of *gamma_t_eigen*
+*gamma_r_eigen* must be inf (only rotation in xy plane), and the third
-must be inf (only diffusion in xy plane).
+value of *gamma_t_eigen* must be inf (only diffusion in xy plane).
 
 If the *dipole* keyword is used, then the dipole moments of the particles
 are updated as described above. Only compatible with *brownian/asphere*
 (as *brownian/sphere* updates dipoles automatically).
 
+If the *rotation_temp* keyword is used, then the rotational diffusion
+will be occur at this prescribed temperature instead of *temp*. Only
+compatible with *brownian/sphere* and *brownian/asphere*.
+
+If the *planar_rotation* keyword is used, then rotation is constrained
+to the xy plane in a 3D simulation. Only compatible with
+*brownian/sphere* and *brownian/asphere* in 3D.
+
 ----------
 
 .. note::
@@ -165,9 +211,9 @@ are updated as described above. Only compatible with *brownian/asphere*
 Restart, fix_modify, output, run start/stop, minimize info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
-No information about this fix is written to :doc:`binary restart files <restart>`.
+No information about this fix is written to :doc:`binary restart files
-No global or per-atom quantities are stored
+<restart>`.  No global or per-atom quantities are stored by this fix for
-by this fix for access by various :doc:`output commands <Howto_output>`.
+access by various :doc:`output commands <Howto_output>`.
 
 
 No parameter of this fix can be used with the *start/stop* keywords of
@@ -177,16 +223,17 @@ the :doc:`run <run>` command.  This fix is not invoked during
 Restrictions
 """"""""""""
 
-The style *brownian/sphere* fix requires that atoms store torque and angular velocity (omega)
+The style *brownian/sphere* fix requires that atoms store torque and
-as defined by the :doc:`atom_style sphere <atom_style>` command.
+angular velocity (omega) as defined by the :doc:`atom_style sphere
-The style *brownian/asphere* fix requires that atoms store torque and quaternions
+<atom_style>` command.  The style *brownian/asphere* fix requires that
-as defined by the :doc:`atom_style ellipsoid <atom_style>` command.
+atoms store torque and quaternions as defined by the :doc:`atom_style
-If the *dipole* keyword is used, they must also store a dipole moment
+ellipsoid <atom_style>` command.  If the *dipole* keyword is used, they
-as defined by the :doc:`atom_style dipole <atom_style>` command.
+must also store a dipole moment as defined by the :doc:`atom_style
+dipole <atom_style>` command.
 
-This fix is part of the BROWNIAN package.  It is only enabled if
+This fix is part of the BROWNIAN package.  It is only enabled if LAMMPS
-LAMMPS was built with that package.  See the :doc:`Build package <Build_package>`
+was built with that package.  See the :doc:`Build package
-doc page for more info.
+<Build_package>` doc page for more info.
 
 Related commands
 """"""""""""""""
@@ -197,8 +244,8 @@ Related commands
 Default
 """""""
 
-The default for *rng* is *uniform*. The default for the rotational and translational friction
+The default for *rng* is *uniform*. The default for the rotational and
-tensors are the identity tensor.
+translational friction tensors are the identity tensor.
 
 ----------
 

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
+     *pKa* value = acid dissociation constant (in the -log10 representation)
-     *pKb* value = base dissociation constant
+     *pKb* value = base dissociation constant (in the -log10 representation)
-     *pIp* value = chemical potential of free cations
+     *pIp* value = activity (effective concentration) of free cations (in the -log10 representation)
-     *pIm* value = chemical potential of free anions
+     *pIm* value = activity (effective concentration) of free anions (in the -log10 representation)
-     *pKs* value = solution self-dissociation constant
+     *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,
+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
-both at chemical potential pI=2.0, see :ref:`(Curk1) <Curk1>` and
 :ref:`(Landsgesell) <Landsgesell>` for more details.
 
-
+We could have simultaneously added a base ionization reaction (:math:`\mathrm{B} \rightleftharpoons \mathrm{B}^++\mathrm{OH}^-`)
- Similarly, 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
+insert (delete) a hydroxyl ion :math:`\mathrm{OH}^-` of atom type 3.
-neither the acid or the base type is specified, for example,
+
+
+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
+\mathrm{mol}/\mathrm{l}`.  For example, in the dilute
-conversion, the length (in nanometers) of the LAMMPS unit length must be
+ideal solution limit, the concentration of free cations will be
-specified via *lunit_nm* (default is set to the Bjerrum length in water
+:math:`c_\mathrm{I} = 10^{-\mathrm{pIp}}\mathrm{mol}/\mathrm{l}`. To perform the internal unit
-at room temperature *lunit_nm* = 0.71nm). For example, in the dilute
+conversion, the the value of the LAMMPS unit length must be
-ideal solution limit, the concentration of free ions will be
+specified in nanometers via *lunit_nm*. The default value is set to the Bjerrum length in water
-:math:`c_\mathrm{I} = 10^{-\mathrm{pIp}}\mathrm{mol}/\mathrm{l}`.
+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_client_md.rst

@@ -1,118 +0,0 @@
-.. index:: fix client/md
-
-fix client/md command
-=====================
-
-Syntax
-""""""
-
-.. parsed-literal::
-
-   fix ID group-ID client/md
-
-* ID, group-ID are documented in :doc:`fix <fix>` command
-* client/md = style name of this fix command
-
-Examples
-""""""""
-
-.. code-block:: LAMMPS
-
-   fix 1 all client/md
-
-Description
-"""""""""""
-
-This fix style enables LAMMPS to run as a "client" code and
-communicate each timestep with a separate "server" code to perform an
-MD simulation together.
-
-The :doc:`Howto client/server <Howto_client_server>` page gives an
-overview of client/server coupling of LAMMPS with another code where
-one code is the "client" and sends request messages to a "server"
-code.  The server responds to each request with a reply message.  This
-enables the two codes to work in tandem to perform a simulation.
-
-When using this fix, LAMMPS (as the client code) passes the current
-coordinates of all particles to the server code each timestep, which
-computes their interaction, and returns the energy, forces, and virial
-for the interacting particles to LAMMPS, so it can complete the
-timestep.
-
-Note that the server code can be a quantum code, or another classical
-MD code which encodes a force field (pair_style in LAMMPS lingo) which
-LAMMPS does not have.  In the quantum case, this fix is a mechanism
-for running *ab initio* MD with quantum forces.
-
-The group associated with this fix is ignored.
-
-The protocol and :doc:`units <units>` for message format and content
-that LAMMPS exchanges with the server code is defined on the
-:doc:`server md <server_md>` doc page.
-
-Note that when using LAMMPS as an MD client, your LAMMPS input script
-should not normally contain force field commands, like a
-:doc:`pair_style <pair_style>`, :doc:`bond_style <bond_style>`, or
-:doc:`kspace_style <kspace_style>` command.  However it is possible
-for a server code to only compute a portion of the full force-field,
-while LAMMPS computes the remaining part.  Your LAMMPS script can also
-specify boundary conditions or force constraints in the usual way,
-which will be added to the per-atom forces returned by the server
-code.
-
-See the examples/message directory for example scripts where LAMMPS is both
-the "client" and/or "server" code for this kind of client/server MD
-simulation.  The examples/message/README file explains how to launch
-LAMMPS and another code in tandem to perform a coupled simulation.
-
-----------
-
-Restart, fix_modify, output, run start/stop, minimize info
-"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-No information about this fix is written to :doc:`binary restart files
-<restart>`.
-
-The :doc:`fix_modify <fix_modify>` *energy* option is supported by
-this fix to add the potential energy set by the server application to
-the global potential energy of the system as part of
-:doc:`thermodynamic output <thermo_style>`.  The default setting for
-this fix is :doc:`fix_modify energy yes <fix_modify>`.
-
-The :doc:`fix_modify <fix_modify>` *virial* option is supported by
-this fix to add the contribution computed by the server application to
-the global pressure of the system via the :doc:`compute pressure
-<compute_pressure>` command.  This can be accessed by
-:doc:`thermodynamic output <thermo_style>`.  The default setting for
-this fix is :doc:`fix_modify virial yes <fix_modify>`.
-
-This fix computes a global scalar which can be accessed by various
-:doc:`output commands <Howto_output>`.  The scalar is the potential
-energy discussed above.  The scalar value calculated by this fix is
-"extensive".
-
-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>`.
-
-Restrictions
-""""""""""""
-
-This fix is part of the MESSAGE package.  It is only enabled if LAMMPS
-was built with that package.  See the :doc:`Build package
-<Build_package>` page for more info.
-
-A script that uses this command must also use the
-:doc:`message <message>` command to setup and shut down the messaging
-protocol with the server code.
-
-Related commands
-""""""""""""""""
-
-:doc:`message <message>`, :doc:`server <server>`
-
-Default
-"""""""
-
-none

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_deform.rst

@@ -70,7 +70,7 @@ Syntax
 
        *remap* value = *x* or *v* or *none*
          x = remap coords of atoms in group into deforming box
-         v = remap velocities of all atoms when they cross periodic boundaries
+         v = remap velocities of atoms in group when they cross periodic boundaries
          none = no remapping of x or v
        *flip* value = *yes* or *no*
          allow or disallow box flips when it becomes highly skewed

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_lb_fluid.rst

@@ -8,59 +8,69 @@ Syntax
 
 .. parsed-literal::
 
-   fix ID group-ID lb/fluid nevery LBtype viscosity density keyword values ...
+   fix ID group-ID lb/fluid nevery viscosity density keyword values ...
 
 * ID, group-ID are documented in :doc:`fix <fix>` command
 * lb/fluid = style name of this fix command
-* nevery = update the lattice-Boltzmann fluid every this many timesteps
+* nevery = update the lattice-Boltzmann fluid every this many timesteps (should normally be 1)
-* LBtype = 1 to use the standard finite difference LB integrator,
-  2 to use the LB integrator of :ref:`Ollila et al. <Ollila>`
 * viscosity = the fluid viscosity (units of mass/(time\*length)).
 * density = the fluid density.
 * zero or more keyword/value pairs may be appended
-* keyword = *setArea* or *setGamma* or *scaleGamma* or *dx* or *dm* or *a0* or *noise* or *calcforce* or *trilinear* or *D3Q19* or *read_restart* or *write_restart* or *zwall_velocity* or *bodyforce* or *printfluid*
+* keyword = *dx* or *dm* or *noise* or *stencil* or *read_restart* or *write_restart* or *zwall_velocity* or *pressurebcx* or *bodyforce* or *D3Q19*  or *dumpxdmf* or *dof* or *scaleGamma* or *a0* or *npits* or *wp* or *sw*
 
   .. parsed-literal::
 
-       *setArea* values = type node_area
-           type = atom type (1-N)
-           node_area = portion of the surface area of the composite object associated with the particular atom type (used when the force coupling constant is set by default).
-       *setGamma* values = gamma
-           gamma = user set value for the force coupling constant.
-       *scaleGamma* values = type gammaFactor
-           type = atom type (1-N)
-           gammaFactor = factor to scale the *setGamma* gamma value by, for the specified atom type.
        *dx* values = dx_LB = the lattice spacing.
        *dm* values = dm_LB = the lattice-Boltzmann mass unit.
-       *a0* values = a_0_real = the square of the speed of sound in the fluid.
        *noise* values = Temperature seed
            Temperature = fluid temperature.
            seed = random number generator seed (positive integer)
-       *calcforce* values = N forcegroup-ID
+       *stencil* values = 2 (trilinear stencil, the default), 3 (3-point immersed boundary stencil), or 4 (4-point Keys' interpolation stencil)
-           N = output the force and torque every N timesteps
-           forcegroup-ID = ID of the particle group to calculate the force and torque of
-       *trilinear* values = none (used to switch from the default Peskin interpolation stencil to the trilinear stencil).
-       *D3Q19* values = none (used to switch from the default D3Q15, 15 velocity lattice, to the D3Q19, 19 velocity lattice).
        *read_restart* values = restart file = name of the restart file to use to restart a fluid run.
        *write_restart* values = N = write a restart file every N MD timesteps.
        *zwall_velocity* values = velocity_bottom velocity_top = velocities along the y-direction of the bottom and top walls (located at z=zmin and z=zmax).
+       *pressurebcx* values = pgradav = imposes a pressure jump at the (periodic) x-boundary of pgradav*Lx*1000.
        *bodyforce* values = bodyforcex bodyforcey bodyforcez = the x,y and z components of a constant body force added to the fluid.
-       *printfluid* values = N = print the fluid density and velocity at each grid point every N timesteps.
+       *D3Q19* values = none (used to switch from the default D3Q15, 15 velocity lattice, to the D3Q19, 19 velocity lattice).
+       *dumpxdmf* values = N file timeI
+           N = output the force and torque every N timesteps
+           file = output file name
+           timeI = 1 (use simulation time to index xdmf file), 0 (use output frame number to index xdmf file)
+       *dof* values = dof = specify the number of degrees of freedom for temperature calculation
+       *scaleGamma* values = type gammaFactor
+           type = atom type (1-N)
+           gammaFactor = factor to scale the *setGamma* gamma value by, for the specified atom type.
+       *a0* values = a_0_real = the square of the speed of sound in the fluid.
+       *npits* values = npits h_p l_p l_pp l_e
+           npits = number of pit regions
+           h_p = z-height of pit regions (floor to bottom of slit)
+           l_p = x-length of pit regions
+           l_pp = x-length of slit regions between consecutive pits
+           l_e = x-length of slit regions at ends
+       *wp* values = w_p = y-width of slit regions (defaults to full width if not present or if sw active)
+       *sw* values = none  (turns on y-sidewalls (in xz plane) if npits option active)
 
 Examples
 """"""""
 
 .. code-block:: LAMMPS
 
-   fix 1 all lb/fluid 1 2 1.0 1.0 setGamma 13.0 dx 4.0 dm 10.0 calcforce sphere1
+   fix 1 all lb/fluid 1 1.0 0.0009982071 dx 1.2 dm 0.001
-   fix 1 all lb/fluid 1 1 1.0 0.0009982071 setArea 1 1.144592082 dx 2.0 dm 0.3 trilinear noise 300.0 8979873
+   fix 1 all lb/fluid 1 1.0 0.0009982071 dx 1.2 dm 0.001 noise 300.0 2761
+   fix 1 all lb/fluid 1 1.0 1.0 dx 4.0 dm 10.0 dumpxdmf 500 fflow 0 pressurebcx 0.01 npits 2 20 40 5 0 wp 30
+
 
 Description
 """""""""""
 
-Implement a lattice-Boltzmann fluid on a uniform mesh covering the LAMMPS
+.. versionchanged:: 24Mar2022
-simulation domain.  The MD particles described by *group-ID* apply a velocity
+
-dependent force to the fluid.
+Implement a lattice-Boltzmann fluid on a uniform mesh covering the
+LAMMPS simulation domain.  Note that this fix was updated in 2022 and is
+not backward compatible with the previous version.  If you need the
+previous version, please download an older version of LAMMPS.  The MD
+particles described by *group-ID* apply a velocity dependent force to
+the fluid.
 
 The lattice-Boltzmann algorithm solves for the fluid motion governed by
 the Navier Stokes equations,
@@ -86,28 +96,23 @@ respectively.  Here, we have implemented
    \sigma_{\alpha \beta} = -P_{\alpha \beta} = -\rho a_0 \delta_{\alpha \beta}
 
 with :math:`a_0` set to :math:`\frac{1}{3} \frac{dx}{dt}^2` by default.
+You should not normally need to change this default.
 
 The algorithm involves tracking the time evolution of a set of partial
-distribution functions which evolve according to a velocity
+distribution functions which evolve according to a velocity discretized
-discretized version of the Boltzmann equation,
+version of the Boltzmann equation,
 
 .. math::
 
    \left(\partial_t + e_{i\alpha}\partial_{\alpha}\right)f_i = -\frac{1}{\tau}\left(f_i - f_i^{eq}\right) + W_i
 
 where the first term on the right hand side represents a single time
-relaxation towards the equilibrium distribution function, and :math:`\tau` is a
+relaxation towards the equilibrium distribution function, and
-parameter physically related to the viscosity.  On a technical note,
+:math:`\tau` is a parameter physically related to the viscosity.  On a
-we have implemented a 15 velocity model (D3Q15) as default; however,
+technical note, we have implemented a 15 velocity model (D3Q15) as
-the user can switch to a 19 velocity model (D3Q19) through the use of
+default; however, the user can switch to a 19 velocity model (D3Q19)
-the *D3Q19* keyword.  This fix provides the user with the choice of
+through the use of the *D3Q19* keyword.  Physical variables are then
-two algorithms to solve this equation, through the specification of
+defined in terms of moments of the distribution functions,
-the keyword *LBtype*\ .  If *LBtype* is set equal to 1, the standard
-finite difference LB integrator is used.  If *LBtype* is set equal to
-2, the algorithm of :ref:`Ollila et al. <Ollila>` is used.
-
-Physical variables are then defined in terms of moments of the distribution
-functions,
 
 .. math::
 
@@ -115,7 +120,7 @@ functions,
    \rho u_{\alpha} = & \displaystyle\sum\limits_{i} f_i e_{i\alpha}
 
 Full details of the lattice-Boltzmann algorithm used can be found in
-:ref:`Mackay et al. <fluid-Mackay>`.
+:ref:`Denniston et al. <fluid-Denniston>`.
 
 The fluid is coupled to the MD particles described by *group-ID* through
 a velocity dependent force.  The contribution to the fluid force on a
@@ -127,92 +132,66 @@ calculated as:
    {\bf F}_{j \alpha} = \gamma \left({\bf v}_n - {\bf u}_f \right) \zeta_{j\alpha}
 
 where :math:`\mathbf{v}_n` is the velocity of the MD particle,
-:math:`\mathbf{u}_f` is the fluid
+:math:`\mathbf{u}_f` is the fluid velocity interpolated to the particle
-velocity interpolated to the particle location, and :math:`\gamma` is the force
+location, and :math:`\gamma` is the force coupling constant.  This
-coupling constant.  :math:`\zeta` is a weight assigned to the grid point,
+force, as with most forces in LAMMPS, and hence the velocities, are
-obtained by distributing the particle to the nearest lattice sites.
+calculated at the half-time step. :math:`\zeta` is a weight assigned to
-For this, the user has the choice between a trilinear stencil, which
+the grid point, obtained by distributing the particle to the nearest
-provides a support of 8 lattice sites, or the immersed boundary method
+lattice sites.
-Peskin stencil, which provides a support of 64 lattice sites.  While
-the Peskin stencil is seen to provide more stable results, the
-trilinear stencil may be better suited for simulation of objects close
-to walls, due to its smaller support.  Therefore, by default, the
-Peskin stencil is used; however the user may switch to the trilinear
-stencil by specifying the keyword, *trilinear*\ .
 
-By default, the force coupling constant, :math:`\gamma`, is calculated
+The force coupling constant, :math:`\gamma`, is calculated
 according to
 
 .. math::
 
-   \gamma = \frac{2m_um_v}{m_u+m_v}\left(\frac{1}{\Delta t_{collision}}\right)
+   \gamma = \frac{2m_um_v}{m_u+m_v}\left(\frac{1}{\Delta t}\right)
 
 Here, :math:`m_v` is the mass of the MD particle, :math:`m_u` is a
-representative fluid mass at the particle location, and :math:`\Delta
+representative fluid mass at the particle location, and :math:`\Delta t`
-t_{collision}` is a collision time, chosen such that
+is the time step.  The fluid mass :math:`m_u` that the MD particle
-:math:`\frac{\tau}{\Delta t_{collision}} = 1` (see :ref:`Mackay and
+interacts with is calculated internally.  This coupling is chosen to
-Denniston <Mackay2>` for full details).  In order to calculate :math:`m_u`,
+constrain the particle and associated fluid velocity to match at the end
-the fluid density is interpolated to the MD particle location, and
+of the time step.  As with other constraints, such as :doc:`shake
-multiplied by a volume, node_area * :math:`dx_{LB}`, where node_area
+<fix_shake>`, this constraint can remove degrees of freedom from the
-represents the portion of the surface area of the composite object
+simulation which are accounted for internally in the algorithm.
-associated with a given MD particle.  By default, node_area is set
-equal to :math:`dx_{LB}^2`; however specific values for given atom types
-can be set using the *setArea* keyword.
-
-The user also has the option of specifying their own value for the
-force coupling constant, for all the MD particles associated with the
-fix, through the use of the *setGamma* keyword.  This may be useful
-when modelling porous particles.  See :ref:`Mackay et al. <fluid-Mackay>` for a
-detailed description of the method by which the user can choose an
-appropriate :math:`\gamma` value.
 
 .. note::
 
-   while this fix applies the force of the particles on the fluid,
+   While this fix applies the force of the particles on the fluid, it
-   it does not apply the force of the fluid to the particles.  When the
+   does not apply the force of the fluid to the particles.  There is
-   force coupling constant is set using the default method, there is only
+   only one option to include this hydrodynamic force on the particles,
-   one option to include this hydrodynamic force on the particles, and
+   and that is through the use of the :doc:`lb/viscous <fix_lb_viscous>`
-   that is through the use of the :doc:`lb/viscous <fix_lb_viscous>` fix.
+   fix.  This fix adds the hydrodynamic force to the total force acting
-   This fix adds the hydrodynamic force to the total force acting on the
+   on the particles, after which any of the built-in LAMMPS integrators
-   particles, after which any of the built-in LAMMPS integrators can be
+   can be used to integrate the particle motion.  If the
-   used to integrate the particle motion.  However, if the user specifies
+   :doc:`lb/viscous <fix_lb_viscous>` fix is NOT used to add the
-   their own value for the force coupling constant, as mentioned in
-   :ref:`Mackay et al. <fluid-Mackay>`, the built-in LAMMPS integrators may prove to
-   be unstable.  Therefore, we have included our own integrators
-   :doc:`fix lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>`, and
-   :doc:`fix lb/pc <fix_lb_pc>`, to solve for the particle motion in these
-   cases.  These integrators should not be used with the
-   :doc:`lb/viscous <fix_lb_viscous>` fix, as they add hydrodynamic forces
-   to the particles directly.  In addition, they can not be used if the
-   force coupling constant has been set the default way.
-
-.. note::
-
-   if the force coupling constant is set using the default method,
-   and the :doc:`lb/viscous <fix_lb_viscous>` fix is NOT used to add the
    hydrodynamic force to the total force acting on the particles, this
    physically corresponds to a situation in which an infinitely massive
    particle is moving through the fluid (since collisions between the
    particle and the fluid do not act to change the particle's velocity).
-   Therefore, the user should set the mass of the particle to be
+   In this case, setting *scaleGamma* to -1 for the corresponding
-   significantly larger than the mass of the fluid at the particle
+   particle type will explicitly take this limit (of infinite particle
-   location, in order to approximate an infinitely massive particle (see
+   mass) in computing the force coupling for the fluid force.
-   the dragforce test run for an example).
 
 ----------
 
-Inside the fix, parameters are scaled by the lattice-Boltzmann
+Physical parameters describing the fluid are specified through
+*viscosity* and *density*.  These parameters should all be given in
+terms of the mass, distance, and time units chosen for the main LAMMPS
+run, as they are scaled by the LB timestep, lattice spacing, and mass
+unit, inside the fix.
+
+The *dx* keyword allows the user to specify a value for the LB grid
+spacing and the *dm* keyword allows the user to specify the LB mass
+unit.  Inside the fix, parameters are scaled by the lattice-Boltzmann
 timestep, :math:`dt_{LB}`, grid spacing, :math:`dx_{LB}`, and mass unit,
 :math:`dm_{LB}`.  :math:`dt_{LB}` is set equal to
-:math:`\mathrm{nevery}\cdot dt_{MD}`, where :math:`dt_{MD}` is the MD timestep.
+:math:`\mathrm{nevery}\cdot dt_{MD}`, where :math:`dt_{MD}` is the MD
-By default,
+timestep.  By default, :math:`dm_{LB}` is set equal to 1.0, and
-:math:`dm_{LB}` is set equal to 1.0, and :math:`dx_{LB}` is chosen so that
+:math:`dx_{LB}` is chosen so that :math:`\frac{\tau}{dt} = \frac{3\eta
-:math:`\frac{\tau}{dt} = \frac{3\eta dt}{\rho dx^2}` is approximately equal to 1.
+dt}{\rho dx^2}` is approximately equal to 1.
-However, the user has the option of specifying their own values for
-:math:`dm_{LB}`, and :math:`dx_{LB}`, by using
-the optional keywords *dm*, and *dx* respectively.
 
-.. note::
+ .. note::
 
    Care must be taken when choosing both a value for :math:`dx_{LB}`,
    and a simulation domain size.  This fix uses the same subdivision of
@@ -223,74 +202,27 @@ the optional keywords *dm*, and *dx* respectively.
    with equal lengths in all dimensions, and the default value for
    :math:`dx_{LB}` is used, this will automatically be satisfied.
 
-Physical parameters describing the fluid are specified through
-*viscosity*, *density*, and *a0*\ . If the force coupling constant is
-set the default way, the surface area associated with the MD particles
-is specified using the *setArea* keyword.  If the user chooses to
-specify a value for the force coupling constant, this is set using the
-*setGamma* keyword.  These parameters should all be given in terms of
-the mass, distance, and time units chosen for the main LAMMPS run, as
-they are scaled by the LB timestep, lattice spacing, and mass unit,
-inside the fix.
-
-----------
-
-The *setArea* keyword allows the user to associate a surface area with
-a given atom type.  For example if a spherical composite object of
-radius R is represented as a spherical shell of N evenly distributed
-MD particles, all of the same type, the surface area per particle
-associated with that atom type should be set equal to :math:`\frac{4\pi R^2}{N}`.
-This keyword should only be used if the force coupling constant,
-:math:`\gamma`, is set the default way.
-
-The *setGamma* keyword allows the user to specify their own value for
-the force coupling constant, :math:`\gamma`, instead of using the default
-value.
-
-The *scaleGamma* keyword should be used in conjunction with the
-*setGamma* keyword, when the user wishes to specify different :math:`\gamma`
-values for different atom types.  This keyword allows the user to
-scale the *setGamma* :math:`\gamma` value by a factor, gammaFactor,
-for a given atom type.
-
-The *dx* keyword allows the user to specify a value for the LB grid
-spacing.
-
-The *dm* keyword allows the user to specify the LB mass unit.
-
-If the *a0* keyword is used, the value specified is used for the
-square of the speed of sound in the fluid.  If this keyword is not
-present, the speed of sound squared is set equal to
-:math:`\frac{1}{3}\left(\frac{dx_{LB}}{dt_{LB}}\right)^2`.
-Setting :math:`a0 > (\frac{dx_{LB}}{dt_{LB}})^2` is not allowed,
-as this may lead to instabilities.
-
 If the *noise* keyword is used, followed by a positive temperature
-value, and a positive integer random number seed, a thermal
+value, and a positive integer random number seed, the thermal LB algorithm
-lattice-Boltzmann algorithm is used.  If *LBtype* is set equal to 1
+of :ref:`Adhikari et al. <Adhikari>` is used.
-(i.e. the standard LB integrator is chosen), the thermal LB algorithm
-of :ref:`Adhikari et al. <Adhikari>` is used; however if *LBtype* is set
-equal to 2 both the LB integrator, and thermal LB algorithm described
-in :ref:`Ollila et al. <Ollila>` are used.
 
-If the *calcforce* keyword is used, both the fluid force and torque
+If the keyword *stencil* is used, the value sets the number of
-acting on the specified particle group are printed to the screen every
+interpolation points used in each direction.  For this, the user has the
-N timesteps.
+choice between a trilinear stencil (*stencil* 2), which provides a
+support of 8 lattice sites, or the 3-point immersed boundary method
+stencil (*stencil* 3), which provides a support of 27 lattice sites, or
+the 4-point Keys' interpolation stencil (stencil 4), which provides a
+support of 64 lattice sites.  The trilinear stencil is the default as it
+is better suited for simulation of objects close to walls or other
+objects, due to its smaller support.  The 3-point stencil provides
+smoother motion of the lattice and is suitable for particles not likely
+to be to close to walls or other objects.
 
-If the keyword *trilinear* is used, the trilinear stencil is used to
+If the keyword *write_restart* is used, followed by a positive integer,
-interpolate the particle nodes onto the fluid mesh.  By default, the
+N, a binary restart file is printed every N LB timesteps.  This restart
-immersed boundary method, Peskin stencil is used.  Both of these
+file only contains information about the fluid.  Therefore, a LAMMPS
-interpolation methods are described in :ref:`Mackay et al. <fluid-Mackay>`.
+restart file should also be written in order to print out full details
-
+of the simulation.
-If the keyword *D3Q19* is used, the 19 velocity (D3Q19) lattice is
-used by the lattice-Boltzmann algorithm.  By default, the 15 velocity
-(D3Q15) lattice is used.
-
-If the keyword *write_restart* is used, followed by a positive
-integer, N, a binary restart file is printed every N LB timesteps.
-This restart file only contains information about the fluid.
-Therefore, a LAMMPS restart file should also be written in order to
-print out full details of the simulation.
 
 .. note::
 
@@ -308,19 +240,100 @@ conditions in the z-direction.  If fixed boundary conditions are
 present in the z-direction, and this keyword is not used, the walls
 are assumed to be stationary.
 
+If the *pressurebcx* keyword is used, a pressure jump (implemented by a
+step jump in density) is imposed at the (periodic) x-boundary.  The
+value set specifies what would be the resulting equilibrium average
+pressure gradient in the x-direction if the system had a constant
+cross-section (i.e. resistance to flow).  It is converted to a pressure
+jump by multiplication by the system size in the x-direction.  As this
+value should normally be quite small, it is also assumed to be scaled
+by 1000.
+
 If the *bodyforce* keyword is used, a constant body force is added to
 the fluid, defined by it's x, y and z components.
 
-If the *printfluid* keyword is used, followed by a positive integer, N,
+If the keyword *D3Q19* is used, the 19 velocity (D3Q19) lattice is
-the fluid densities and velocities at each lattice site are printed to the
+used by the lattice-Boltzmann algorithm.  By default, the 15 velocity
-screen every N timesteps.
+(D3Q15) lattice is used.
+
+If the *dumpxdmf* keyword is used, followed by a positive integer, N,
+and a file name, the fluid densities and velocities at each lattice site
+are output to an xdmf file every N timesteps.  This is a binary file
+format that can be read by visualization packages such as `Paraview
+<https://www.paraview.org/>`_ .  The xdmf file format contains a time
+index for each frame dump and the value timeI = 1 uses simulation time
+while 0 uses the output frame number to index xdmf file.  The later can
+be useful if the :doc:`dump vtk <dump_vtk>` command is used to output
+the particle positions at the same timesteps and you want to visualize
+both the fluid and particle data together in `Paraview
+<https://www.paraview.org/>`_ .
+
+The *scaleGamma* keyword allows the user to scale the :math:`\gamma`
+value by a factor, gammaFactor, for a given atom type.  Setting
+*scaleGamma* to -1 for the corresponding particle type will explicitly
+take the limit of infinite particle mass in computing the force coupling
+for the fluid force (see note above).
+
+If the *a0* keyword is used, the value specified is used for the square
+of the speed of sound in the fluid.  If this keyword is not present, the
+speed of sound squared is set equal to
+:math:`\frac{1}{3}\left(\frac{dx_{LB}}{dt_{LB}}\right)^2`.  Setting
+:math:`a0 > (\frac{dx_{LB}}{dt_{LB}})^2` is not allowed, as this may
+lead to instabilities.  As the speed of sound should usually be much
+larger than any fluid velocity of interest, its value does not normally
+have a significant impact on the results.  As such, it is usually best
+to use the default for this option.
+
+The *npits* keyword (followed by integer arguments: npits, h_p, l_p,
+l_pp, l_e) sets the fluid domain to the pits geometry.  These arguments
+should only be used if you actually want something more complex than a
+rectangular/cubic geometry.  The npits value sets the number of pits
+regions (arranged along x).  The remaining arguments are sizes measured
+in multiples of dx_lb: h_p is the z-height of the pit regions, l_p is
+the x-length of the pit regions, l_pp is the length of the region
+between consecutive pits (referred to as a "slit" region), and l_e is
+the x-length of the slit regions at each end of the channel.  The pit
+geometry must fill the system in the x-direction but can be longer, in
+which case it is truncated (which enables asymmetric entrance/exit end
+sections).  The additional *wp* keyword allows the width (in
+y-direction) of the pit to be specified (the default is full width) and
+the *sw* keyword indicates that there should be sidewalls in the
+y-direction (default is periodic in y-direction).  These parameters are
+illustrated below::
+
+    Sideview (in xz plane) of pit geometry:
+    ______________________________________________________________________
+      slit                          slit                          slit     ^
+                                                                           |
+    <---le---><---------lp-------><---lpp---><-------lp--------><---le---> hs = (Nbz-1) - hp
+                                                                           |
+    __________                    __________                    __________ v
+              |                  |          |                  |           ^       z
+              |                  |          |                  |           |       |
+              |       pit        |          |       pit        |           hp      +-x
+              |                  |          |                  |           |
+              |__________________|          |__________________|           v
+
+    Endview (in yz plane) of pit geometry (no sw so wp is active):
+    _____________________
+                          ^
+                          |
+                          hs
+                          |
+    _____________________ v
+        |          |      ^
+        |          |      |          z
+        |<---wp--->|      hp         |
+        |          |      |          +-y
+        |__________|      v
+
 
 ----------
 
-For further details, as well as descriptions and results of several
+For further details, as well as descriptions and results of several test
-test runs, see :ref:`Mackay et al. <fluid-Mackay>`.  Please include a citation to
+runs, see :ref:`Denniston et al. <fluid-Denniston>`.  Please include a
-this paper if the lb_fluid fix is used in work contributing to
+citation to this paper if the lb_fluid fix is used in work contributing
-published research.
+to published research.
 
 ----------
 
@@ -333,68 +346,77 @@ binary restart files, if requested, independent of the main LAMMPS
 is written to the main LAMMPS :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
+fix.
-access by various :doc:`output commands <Howto_output>`.  No parameter
+
-of this fix can be used with the *start/stop* keywords of the
+The fix computes a global scalar which can be accessed by various
-:doc:`run <run>` command.  This fix is not invoked during :doc:`energy minimization <minimize>`.
+:doc:`output commands <Howto_output>`.  The scalar is the current
+temperature of the group of particles described by *group-ID* along with
+the fluid constrained to move with them. The temperature is computed via
+the kinetic energy of the group and fluid constrained to move with them
+and the total number of degrees of freedom (calculated internally).  If
+the particles are not integrated independently (such as via :doc:`fix
+NVE <fix_nve>`) but have additional constraints imposed on them (such as
+via integration using :doc:`fix rigid <fix_rigid>`) the degrees of
+freedom removed from these additional constraints will not be properly
+accounted for.  In this case, the user can specify the total degrees of
+freedom independently using the *dof* keyword.
+
+The fix also computes a global array of values which can be accessed by
+various :doc:`output commands <Howto_output>`.  There are 5 entries in
+the array.  The first entry is the temperature of the fluid, the second
+entry is the total mass of the fluid plus particles, the third through
+fifth entries give the x, y, and z total momentum of the fluid plus
+particles.
+
+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>`.
 
 Restrictions
 """"""""""""
 
 This fix is part of the LATBOLTZ package.  It is only enabled if LAMMPS
-was built with that package.  See the :doc:`Build package <Build_package>` page for more info.
+was built with that package.  See the :doc:`Build package
+<Build_package>` page for more info.
 
 This fix can only be used with an orthogonal simulation domain.
 
-Walls have only been implemented in the z-direction.  Therefore, the
+The boundary conditions for the fluid are specified independently to the
-boundary conditions, as specified via the main LAMMPS boundary command
+particles.  However, these should normally be specified consistently via
-must be periodic for x and y, and either fixed or periodic for z.
+the main LAMMPS :doc:`boundary <boundary>` command (p p p, p p f, and p
-Shrink-wrapped boundary conditions are not permitted with this fix.
+f f are the only consistent possibilities).  Shrink-wrapped boundary
+conditions are not permitted with this fix.
 
-This fix must be used before any of :doc:`fix lb/viscous <fix_lb_viscous>`, :doc:`fix lb/momentum <fix_lb_momentum>`, :doc:`fix lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>`, and/ or :doc:`fix lb/pc <fix_lb_pc>` , as the fluid needs to be initialized before
+This fix must be used before any of :doc:`fix lb/viscous
-any of these routines try to access its properties.  In addition, in
+<fix_lb_viscous>` and :doc:`fix lb/momentum <fix_lb_momentum>` as the
-order for the hydrodynamic forces to be added to the particles, this
+fluid needs to be initialized before any of these routines try to access
-fix must be used in conjunction with the
+its properties.  In addition, in order for the hydrodynamic forces to be
-:doc:`lb/viscous <fix_lb_viscous>` fix if the force coupling constant is
+added to the particles, this fix must be used in conjunction with the
-set by default, or either the :doc:`lb/viscous <fix_lb_viscous>` fix or
+:doc:`lb/viscous <fix_lb_viscous>` fix.
-one of the :doc:`lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>` or
+
-:doc:`lb/pc <fix_lb_pc>` integrators, if the user chooses to specify
+This fix needs to be used in conjunction with a standard LAMMPS
-their own value for the force coupling constant.
+integrator such as :doc:`fix NVE <fix_nve>` or :doc:`fix rigid
+<fix_rigid>`.
 
 Related commands
 """"""""""""""""
 
-:doc:`fix lb/viscous <fix_lb_viscous>`, :doc:`fix lb/momentum <fix_lb_momentum>`, :doc:`fix lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>`, :doc:`fix lb/pc <fix_lb_pc>`
+:doc:`fix lb/viscous <fix_lb_viscous>`, :doc:`fix lb/momentum <fix_lb_momentum>`
 
 Default
 """""""
 
-By default, the force coupling constant is set according to
+*dx* is chosen such that :math:`\frac{\tau}{dt_{LB}} = \frac{3\eta dt_{LB}}{\rho dx_{LB}^2}` is approximately equal to 1.
-
-.. math::
-
-   \gamma = \frac{2m_um_v}{m_u+m_v}\left(\frac{1}{\Delta t_{collision}}\right)
-
-and an area of :math:`dx_{LB}^2` per node, used to calculate the fluid mass at
-the particle node location, is assumed.
-
-*dx* is chosen such that :math:`\frac{\tau}{dt_{LB}} =
-\frac{3\eta dt_{LB}}{\rho dx_{LB}^2}` is approximately equal to 1.
 *dm* is set equal to 1.0.
 *a0* is set equal to :math:`\frac{1}{3}\left(\frac{dx_{LB}}{dt_{LB}}\right)^2`.
-The Peskin stencil is used as the default interpolation method.
+The trilinear stencil is used as the default interpolation method.
 The D3Q15 lattice is used for the lattice-Boltzmann algorithm.
-If walls are present, they are assumed to be stationary.
 
 ----------
 
-.. _Ollila:
+.. _fluid-Denniston:
 
-**(Ollila et al.)** Ollila, S.T.T., Denniston, C., Karttunen, M., and Ala-Nissila, T., Fluctuating lattice-Boltzmann model for complex fluids, J. Chem. Phys. 134 (2011) 064902.
+**(Denniston et al.)** Denniston, C., Afrasiabian, N., Cole-Andre, M.G., Mackay, F. E., Ollila, S.T.T., and Whitehead, T., LAMMPS lb/fluid fix version 2: Improved Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 275 (2022) `108318 <https://doi.org/10.1016/j.cpc.2022.108318>`_ .
-
-.. _fluid-Mackay:
-
-**(Mackay et al.)** Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.
 
 .. _Mackay2:
 
@@ -403,3 +425,4 @@ If walls are present, they are assumed to be stationary.
 .. _Adhikari:
 
 **(Adhikari et al.)** Adhikari, R., Stratford, K.,  Cates, M. E., and Wagner, A. J., Fluctuating lattice Boltzmann, Europhys. Lett. 71 (2005) 473-479.
+

doc/src/fix_lb_momentum.rst

@@ -38,7 +38,7 @@ lattice-Boltzmann fluid is present.
 
 Zero the total linear momentum of the system, including both the atoms
 specified by group-ID and the lattice-Boltzmann fluid every nevery
-timesteps.  This is accomplished by adjusting the particle velocities
+timesteps.  If there are no atoms specified by group-ID only the fluid momentum is affected.  This is accomplished by adjusting the particle velocities
 and the fluid velocities at each lattice site.
 
 .. note::

doc/src/fix_lb_pc.rst

@@ -1,65 +0,0 @@
-.. index:: fix lb/pc
-
-fix lb/pc command
-=================
-
-Syntax
-""""""
-
-.. parsed-literal::
-
-   fix ID group-ID lb/pc
-
-* ID, group-ID are documented in the :doc:`fix <fix>` command
-* lb/pc = style name of this fix command
-
-Examples
-""""""""
-
-.. code-block:: LAMMPS
-
-   fix 1 all lb/pc
-
-Description
-"""""""""""
-
-Update the positions and velocities of the individual particles
-described by *group-ID*, experiencing velocity-dependent hydrodynamic
-forces, using the integration algorithm described in :ref:`Mackay et al. <Mackay1>`.  This integration algorithm should only be used if a
-user-specified value for the force-coupling constant used in :doc:`fix lb/fluid <fix_lb_fluid>` has been set; do not use this integration
-algorithm if the force coupling constant has been set by default.
-
-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.  This fix is not invoked during :doc:`energy minimization <minimize>`.
-
-Restrictions
-""""""""""""
-
-This fix is part of the LATBOLTZ package.  It is only enabled if LAMMPS
-was built with that package.  See the :doc:`Build package <Build_package>` page for more info.
-
-Can only be used if a lattice-Boltzmann fluid has been created via the
-:doc:`fix lb/fluid <fix_lb_fluid>` command, and must come after this
-command.
-
-Related commands
-""""""""""""""""
-
-:doc:`fix lb/fluid <fix_lb_fluid>` :doc:`fix lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>`
-
-Default
-"""""""
-
-none.
-
-----------
-
-.. _Mackay1:
-
-**(Mackay et al.)** Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.

doc/src/fix_lb_rigid_pc_sphere.rst

@@ -1,167 +0,0 @@
-.. index:: fix lb/rigid/pc/sphere
-
-fix lb/rigid/pc/sphere command
-==============================
-
-Syntax
-""""""
-
-.. parsed-literal::
-
-   fix ID group-ID lb/rigid/pc/sphere bodystyle args keyword values ...
-
-* ID, group-ID are documented in :doc:`fix <fix>` command
-* lb/rigid/pc/sphere = style name of this fix command
-* bodystyle = *single* or *molecule* or *group*
-
-  .. parsed-literal::
-
-       *single* args = none
-       *molecule* args = none
-       *group* args = N groupID1 groupID2 ...
-         N = # of groups
-
-* zero or more keyword/value pairs may be appended
-* keyword = *force* or *torque* or *innerNodes*
-
-  .. parsed-literal::
-
-       *force* values = M xflag yflag zflag
-         M = which rigid body from 1-Nbody (see asterisk form below)
-         xflag,yflag,zflag = off/on if component of center-of-mass force is active
-       *torque* values = M xflag yflag zflag
-         M = which rigid body from 1-Nbody (see asterisk form below)
-         xflag,yflag,zflag = off/on if component of center-of-mass torque is active
-       *innerNodes* values = innergroup-ID
-         innergroup-ID = ID of the atom group which does not experience a hydrodynamic force from the lattice-Boltzmann fluid
-
-Examples
-""""""""
-
-.. code-block:: LAMMPS
-
-   fix 1 spheres lb/rigid/pc/sphere
-   fix 1 all lb/rigid/pc/sphere force 1 0 0 innerNodes ForceAtoms
-
-Description
-"""""""""""
-
-This fix is based on the :doc:`fix rigid <fix_rigid>` command, and was
-created to be used in place of that fix, to integrate the equations of
-motion of spherical rigid bodies when a lattice-Boltzmann fluid is
-present with a user-specified value of the force-coupling constant.
-The fix uses the integration algorithm described in :ref:`Mackay et
-al. <Mackay>` to update the positions, velocities, and orientations of
-a set of spherical rigid bodies experiencing velocity dependent
-hydrodynamic forces.  The spherical bodies are assumed to rotate as
-solid, uniform density spheres, with moments of inertia calculated
-using the combined sum of the masses of all the constituent particles
-(which are assumed to be point particles).
-
-----------
-
-By default, all of the atoms that this fix acts on experience a
-hydrodynamic force due to the presence of the lattice-Boltzmann fluid.
-However, the *innerNodes* keyword allows the user to specify atoms
-belonging to a rigid object which do not interact with the
-lattice-Boltzmann fluid (i.e. these atoms do not feel a hydrodynamic
-force from the lattice-Boltzmann fluid).  This can be used to
-distinguish between atoms on the surface of a non-porous object, and
-those on the inside.
-
-This feature can be used, for example, when implementing a hard sphere
-interaction between two spherical objects.  Instead of interactions
-occurring between the particles on the surfaces of the two spheres, it
-is desirable simply to place an atom at the center of each sphere,
-which does not contribute to the hydrodynamic force, and have these
-central atoms interact with one another.
-
-----------
-
-Apart from the features described above, this fix is very similar to
-the rigid fix (although it includes fewer optional arguments, and
-assumes the constituent atoms are point particles); see
-:doc:`fix rigid <fix_rigid>` for a complete documentation.
-
-Restart, fix_modify, output, run start/stop, minimize info
-"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-No information about the *rigid* and *rigid/nve* fixes are written to
-:doc:`binary restart files <restart>`.
-
-The :doc:`fix_modify <fix_modify>` *virial* option is supported by
-this fix to add the contribution due to the added forces on atoms to
-both the global pressure and per-atom stress of the system via the
-:doc:`compute pressure <compute_pressure>` and :doc:`compute
-stress/atom <compute_stress_atom>` commands.  The former can be
-accessed by :doc:`thermodynamic output <thermo_style>`.  The default
-setting for this fix is :doc:`fix_modify virial yes <fix_modify>`.
-
-Similar to the :doc:`fix rigid <fix_rigid>` command: The rigid fix
-computes a global scalar which can be accessed by various :doc:`output
-commands <Howto_output>`.  The scalar value calculated by these fixes
-is "intensive".  The scalar is the current temperature of the
-collection of rigid bodies.  This is averaged over all rigid bodies
-and their translational and rotational degrees of freedom.  The
-translational energy of a rigid body is 1/2 m v\^2, where m = total
-mass of the body and v = the velocity of its center of mass.  The
-rotational energy of a rigid body is 1/2 I w\^2, where I = the moment
-of inertia tensor of the body and w = its angular velocity.  Degrees
-of freedom constrained by the *force* and *torque* keywords are
-removed from this calculation.
-
-All of these fixes compute a global array of values which can be
-accessed by various :doc:`output commands <Howto_output>`.  The number
-of rows in the array is equal to the number of rigid bodies.  The
-number of columns is 15.  Thus for each rigid body, 15 values are
-stored: the xyz coords of the center of mass (COM), the xyz components
-of the COM velocity, the xyz components of the force acting on the
-COM, the xyz components of the torque acting on the COM, and the xyz
-image flags of the COM, which have the same meaning as image flags for
-atom positions (see the "dump" command).  The force and torque values
-in the array are not affected by the *force* and *torque* keywords in
-the fix rigid command; they reflect values before any changes are made
-by those keywords.
-
-The ordering of the rigid bodies (by row in the array) is as follows.
-For the *single* keyword there is just one rigid body.  For the
-*molecule* keyword, the bodies are ordered by ascending molecule ID.
-For the *group* keyword, the list of group IDs determines the ordering
-of bodies.
-
-The array values calculated by these fixes are "intensive", meaning
-they are independent of the number of atoms in the simulation.
-
-No parameter of these fixes can be used with the *start/stop* keywords
-of the :doc:`run <run>` command.  These fixes are not invoked during
-:doc:`energy minimization <minimize>`.
-
-Restrictions
-""""""""""""
-
-This fix is part of the LATBOLTZ package.  It is only enabled if LAMMPS
-was built with that package.  See the :doc:`Build package
-<Build_package>` page for more info.
-
-Can only be used if a lattice-Boltzmann fluid has been created via the
-:doc:`fix lb/fluid <fix_lb_fluid>` command, and must come after this
-command.  Should only be used if the force coupling constant used in
-:doc:`fix lb/fluid <fix_lb_fluid>` has been set by the user; this
-integration fix cannot be used if the force coupling constant is set
-by default.
-
-Related commands
-""""""""""""""""
-
-:doc:`fix lb/fluid <fix_lb_fluid>`, :doc:`fix lb/pc <fix_lb_pc>`
-
-Default
-"""""""
-
-The defaults are force \* on on on, and torque \* on on on.
-
-----------
-
-.. _Mackay:
-
-**(Mackay et al.)** Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.

doc/src/fix_lb_viscous.rst

@@ -25,27 +25,14 @@ Description
 
 This fix is similar to the :doc:`fix viscous <fix_viscous>` command, and
 is to be used in place of that command when a lattice-Boltzmann fluid
-is present, and the user wishes to integrate the particle motion using
+is present using the :doc:`fix lb/fluid <fix_lb_fluid>`.  This should be used in conjunction with one of the built-in LAMMPS integrators, such as :doc:`fix NVE <fix_nve>` or :doc:`fix rigid <fix_rigid>`.
-one of the built in LAMMPS integrators.
 
-This fix adds a force, F = - Gamma\*(velocity-fluid_velocity), to each
+This fix adds a viscous force to each atom to cause it move with the same velocity as the fluid (an equal and opposite force is applied to the fluid via :doc:`fix lb/fluid <fix_lb_fluid>`).  When :doc:`fix lb/fluid <fix_lb_fluid>` is called with the noise option, the atoms will also experience random forces which will thermalize them to the same temperature as the fluid.  In this way, the combination of this fix with :doc:`fix lb/fluid <fix_lb_fluid>` and a LAMMPS integrator like :doc:`fix NVE <fix_nve>` is analogous to :doc:`fix langevin <fix_langevin>` except here the fluid is explicit.  The temperature of the particles can be monitored via the scalar output of :doc:`fix lb/fluid <fix_lb_fluid>`.
-atom, where Gamma is the force coupling constant described in the :doc:`fix lb/fluid <fix_lb_fluid>` command (which applies an equal and
-opposite force to the fluid).
-
-.. note::
-
-   This fix should only be used in conjunction with one of the
-   built in LAMMPS integrators; it should not be used with the :doc:`fix lb/pc <fix_lb_pc>` or :doc:`fix lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>` integrators, which
-   already include the hydrodynamic forces.  These latter fixes should
-   only be used if the force coupling constant has been set by the user
-   (instead of using the default value); if the default force coupling
-   value is used, then this fix provides the only method for adding the
-   hydrodynamic forces to the particles.
 
 ----------
 
-For further details, as well as descriptions and results of several
+For details of this fix, as well as descriptions and results of several
-test runs, see :ref:`Mackay et al. <Mackay3>`.  Please include a citation to
+test runs, see :ref:`Denniston et al. <fluid-Denniston2>`.  Please include a citation to
 this paper if this fix is used in work contributing to published
 research.
 
@@ -78,14 +65,11 @@ Can only be used if a lattice-Boltzmann fluid has been created via the
 :doc:`fix lb/fluid <fix_lb_fluid>` command, and must come after this
 command.
 
-This fix should not be used if either the :doc:`fix lb/pc <fix_lb_pc>`
-or :doc:`fix lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>` integrator is
-used.
 
 Related commands
 """"""""""""""""
 
-:doc:`fix lb/fluid <fix_lb_fluid>`, :doc:`fix lb/pc <fix_lb_pc>`, :doc:`fix lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>`
+:doc:`fix lb/fluid <fix_lb_fluid>`
 
 Default
 """""""
@@ -94,6 +78,6 @@ none
 
 ----------
 
-.. _Mackay3:
+.. _fluid-Denniston2:
 
-**(Mackay et al.)** Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.
+**(Denniston et al.)** Denniston, C., Afrasiabian, N., Cole-Andre, M.G., Mackay, F. E., Ollila, S.T.T., and Whitehead, T., LAMMPS lb/fluid fix version 2: Improved Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 275 (2022) `108318 <https://doi.org/10.1016/j.cpc.2022.108318>`_ .