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

Update versions strings for the next patch release

.gitattributes

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

.github/CODEOWNERS

@@ -13,20 +13,21 @@ lib/kim/*             @ellio167
 lib/mesont/*          @iafoss
 
 # whole packages
+src/AMOEBA/*          @sjplimp
 src/COMPRESS/*        @rbberger
 src/GPU/*             @ndtrung81
 src/KOKKOS/*          @stanmoore1
 src/KIM/*             @ellio167
 src/LATTE/*           @cnegre
-src/MESSAGE/*         @sjplimp
 src/MLIAP/*           @athomps
 src/SNAP/*            @athomps
 src/SPIN/*            @julient31
 src/BROWNIAN/*        @samueljmcameron
 src/CG-DNA/*          @ohenrich
-src/CG-SDK/*          @akohlmey
+src/CG-SPICA/*        @yskmiyazaki
 src/COLVARS/*         @giacomofiorin
 src/DIELECTRIC/*      @ndtrung81
+src/ELECTRODE/*       @ludwig-ahrens
 src/FEP/*             @agiliopadua
 src/ML-HDNNP/*        @singraber
 src/INTEL/*           @wmbrownintel
@@ -133,6 +134,7 @@ tools/coding_standard/* @rbberger
 tools/valgrind/*      @akohlmey
 tools/swig/*          @akohlmey
 tools/offline/*       @rbberger
+tools/vim/*           @hammondkd
 
 # tests
 unittest/*            @akohlmey @rbberger

.github/CONTRIBUTING.md

@@ -5,8 +5,8 @@ Thank your for considering to contribute to the LAMMPS software project.
 The following is a set of guidelines as well as explanations of policies and work flows for contributing to the LAMMPS molecular dynamics software project. These guidelines focus on submitting issues or pull requests on the LAMMPS GitHub project.
 
 Thus please also have a look at:
-* [The guide for submitting new features in the LAMMPS manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
-* [The guide on programming style and requirement in the LAMMPS manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
+* [The guide for submitting new features in the LAMMPS manual](https://www.lammps.org/doc/Modify_contribute.html)
+* [The guide on programming style and requirement in the LAMMPS manual](https://www.lammps.org/doc/Modify_style.html)
 * [The GitHub tutorial in the LAMMPS manual](http://lammps.sandia.gov/doc/Howto_github.html)
 
 ## Table of Contents

.github/codecov.yml

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

.github/dependabot.yml

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

.github/workflows/codeql-analysis.yml

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

.github/workflows/compile-msvc.yml

@@ -3,7 +3,13 @@ name: "Native Windows Compilation and Unit Tests"
 
 on:
   push:
-    branches: [develop]
+    branches:
+      - develop
+  pull_request:
+    branches:
+      - develop
+
+  workflow_dispatch:
 
 jobs:
   build:
@@ -13,12 +19,12 @@ jobs:
 
     steps:
     - name: Checkout repository
-      uses: actions/checkout@v2
+      uses: actions/checkout@v3
       with:
         fetch-depth: 2
 
     - name: Select Python version
-      uses: actions/setup-python@v2
+      uses: actions/setup-python@v4
       with:
         python-version: '3.10'
 
@@ -26,6 +32,7 @@ jobs:
       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 \

.github/workflows/coverity.yml

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

.github/workflows/unittest-macos.yml

@@ -3,7 +3,13 @@ name: "Unittest for MacOS"
 
 on:
   push:
-    branches: [develop]
+    branches:
+      - develop
+  pull_request:
+    branches:
+      - develop
+
+  workflow_dispatch:
 
 jobs:
   build:
@@ -15,7 +21,7 @@ jobs:
 
     steps:
     - name: Checkout repository
-      uses: actions/checkout@v2
+      uses: actions/checkout@v3
       with:
         fetch-depth: 2
 
@@ -26,7 +32,7 @@ jobs:
       run: mkdir build
 
     - name: Set up ccache
-      uses: actions/cache@v2
+      uses: actions/cache@v3
       with:
         path: ${{ env.CCACHE_DIR }}
         key: macos-ccache-${{ github.sha }}
@@ -37,6 +43,8 @@ jobs:
       working-directory: build
       run: |
         ccache -z
+        python3 -m pip install numpy
+        python3 -m pip install pyyaml
         cmake -C ../cmake/presets/clang.cmake \
               -C ../cmake/presets/most.cmake \
               -D CMAKE_CXX_COMPILER_LAUNCHER=ccache \

.gitignore

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

CITATION.cff

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

bench/POTENTIALS/ffield.comb

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

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

@@ -0,0 +1,615 @@
+cmake_minimum_required(VERSION 3.10)
+# When using CMake 3.4 and later, don't export symbols from executables unless
+# the CMAKE_ENABLE_EXPORTS variable is set.
+if(POLICY CMP0065)
+  cmake_policy(SET CMP0065 NEW)
+endif()
+if (POLICY CMP0077)
+  cmake_policy(SET CMP0077 NEW)
+endif()
+if(CMAKE_EXECUTABLE_SUFFIX)
+  set(CMAKE_EXECUTABLE_SUFFIX_TMP ${CMAKE_EXECUTABLE_SUFFIX})
+endif()
+
+project(libjpeg-turbo C)
+set(VERSION 2.1.3)
+set(COPYRIGHT_YEAR "1991-2022")
+string(REPLACE "." ";" VERSION_TRIPLET ${VERSION})
+list(GET VERSION_TRIPLET 0 VERSION_MAJOR)
+list(GET VERSION_TRIPLET 1 VERSION_MINOR)
+list(GET VERSION_TRIPLET 2 VERSION_REVISION)
+function(pad_number NUMBER OUTPUT_LEN)
+  string(LENGTH "${${NUMBER}}" INPUT_LEN)
+  if(INPUT_LEN LESS OUTPUT_LEN)
+    math(EXPR ZEROES "${OUTPUT_LEN} - ${INPUT_LEN} - 1")
+    set(NUM ${${NUMBER}})
+    foreach(C RANGE ${ZEROES})
+      set(NUM "0${NUM}")
+    endforeach()
+    set(${NUMBER} ${NUM} PARENT_SCOPE)
+  endif()
+endfunction()
+pad_number(VERSION_MINOR 3)
+pad_number(VERSION_REVISION 3)
+set(LIBJPEG_TURBO_VERSION_NUMBER ${VERSION_MAJOR}${VERSION_MINOR}${VERSION_REVISION})
+
+# CMake 3.14 and later sets CMAKE_MACOSX_BUNDLE to TRUE by default when
+# CMAKE_SYSTEM_NAME is iOS, tvOS, or watchOS, which breaks the libjpeg-turbo
+# build.  (Specifically, when CMAKE_MACOSX_BUNDLE is TRUE, executables for
+# Apple platforms are built as application bundles, which causes CMake to
+# complain that our install() directives for executables do not specify a
+# BUNDLE DESTINATION.  Even if CMake did not complain, building executables as
+# application bundles would break our iOS packages.)
+set(CMAKE_MACOSX_BUNDLE FALSE)
+
+string(TIMESTAMP DEFAULT_BUILD "%Y%m%d")
+set(BUILD ${DEFAULT_BUILD} CACHE STRING "Build string (default: ${DEFAULT_BUILD})")
+
+# NOTE: On Windows, this does nothing except when using MinGW or Cygwin.
+# CMAKE_BUILD_TYPE has no meaning in Visual Studio, and it always defaults to
+# Debug when using NMake.
+if(NOT CMAKE_BUILD_TYPE)
+  set(CMAKE_BUILD_TYPE Release)
+endif()
+message(STATUS "CMAKE_BUILD_TYPE = ${CMAKE_BUILD_TYPE}")
+
+message(STATUS "VERSION = ${VERSION}, BUILD = ${BUILD}")
+
+include(cmakescripts/PackageInfo.cmake)
+
+# Detect CPU type and whether we're building 64-bit or 32-bit code
+math(EXPR BITS "${CMAKE_SIZEOF_VOID_P} * 8")
+string(TOLOWER ${CMAKE_SYSTEM_PROCESSOR} CMAKE_SYSTEM_PROCESSOR_LC)
+set(COUNT 1)
+foreach(ARCH ${CMAKE_OSX_ARCHITECTURES})
+  if(COUNT GREATER 1)
+    message(FATAL_ERROR "The libjpeg-turbo build system does not support multiple values in CMAKE_OSX_ARCHITECTURES.")
+  endif()
+  math(EXPR COUNT "${COUNT}+1")
+endforeach()
+if(CMAKE_SYSTEM_PROCESSOR_LC MATCHES "x86_64" OR
+  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "amd64" OR
+  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "i[0-9]86" OR
+  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "x86" OR
+  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "ia32")
+  if(BITS EQUAL 64 OR CMAKE_C_COMPILER_ABI MATCHES "ELF X32")
+    set(CPU_TYPE x86_64)
+  else()
+    set(CPU_TYPE i386)
+  endif()
+  if(NOT CMAKE_SYSTEM_PROCESSOR STREQUAL ${CPU_TYPE})
+    set(CMAKE_SYSTEM_PROCESSOR ${CPU_TYPE})
+  endif()
+elseif(CMAKE_SYSTEM_PROCESSOR_LC STREQUAL "aarch64" OR
+  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "^arm")
+  if(BITS EQUAL 64)
+    set(CPU_TYPE arm64)
+  else()
+    set(CPU_TYPE arm)
+  endif()
+elseif(CMAKE_SYSTEM_PROCESSOR_LC MATCHES "^ppc" OR
+  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "^powerpc")
+  set(CPU_TYPE powerpc)
+else()
+  set(CPU_TYPE ${CMAKE_SYSTEM_PROCESSOR_LC})
+endif()
+if(CMAKE_OSX_ARCHITECTURES MATCHES "x86_64" OR
+  CMAKE_OSX_ARCHITECTURES MATCHES "arm64" OR
+  CMAKE_OSX_ARCHITECTURES MATCHES "i386")
+  set(CPU_TYPE ${CMAKE_OSX_ARCHITECTURES})
+endif()
+if(CMAKE_OSX_ARCHITECTURES MATCHES "ppc")
+  set(CPU_TYPE powerpc)
+endif()
+if(MSVC_IDE AND CMAKE_GENERATOR_PLATFORM MATCHES "arm64")
+  set(CPU_TYPE arm64)
+endif()
+
+message(STATUS "${BITS}-bit build (${CPU_TYPE})")
+
+macro(report_directory var)
+  if(CMAKE_INSTALL_${var} STREQUAL CMAKE_INSTALL_FULL_${var})
+    message(STATUS "CMAKE_INSTALL_${var} = ${CMAKE_INSTALL_${var}}")
+  else()
+    message(STATUS "CMAKE_INSTALL_${var} = ${CMAKE_INSTALL_${var}} (${CMAKE_INSTALL_FULL_${var}})")
+  endif()
+  mark_as_advanced(CLEAR CMAKE_INSTALL_${var})
+endmacro()
+
+set(DIRLIST "BINDIR;DATAROOTDIR;DOCDIR;INCLUDEDIR;LIBDIR")
+if(UNIX)
+  list(APPEND DIRLIST "MANDIR")
+endif()
+foreach(dir ${DIRLIST})
+  report_directory(${dir})
+endforeach()
+
+
+###############################################################################
+# CONFIGURATION OPTIONS
+###############################################################################
+
+macro(boolean_number var)
+  if(${var})
+    set(${var} 1 ${ARGN})
+  else()
+    set(${var} 0 ${ARGN})
+  endif()
+endmacro()
+
+option(ENABLE_SHARED "Build shared libraries" FALSE)
+boolean_number(ENABLE_SHARED)
+option(ENABLE_STATIC "Build static libraries" TRUE)
+boolean_number(ENABLE_STATIC)
+option(REQUIRE_SIMD "Generate a fatal error if SIMD extensions are not available for this platform (default is to fall back to a non-SIMD build)" FALSE)
+boolean_number(REQUIRE_SIMD)
+option(WITH_12BIT "Encode/decode JPEG images with 12-bit samples (implies WITH_ARITH_DEC=0 WITH_ARITH_ENC=0 WITH_JAVA=0 WITH_SIMD=0 WITH_TURBOJPEG=0 )" FALSE)
+boolean_number(WITH_12BIT)
+option(WITH_ARITH_DEC "Include arithmetic decoding support when emulating the libjpeg v6b API/ABI" TRUE)
+boolean_number(WITH_ARITH_DEC)
+option(WITH_ARITH_ENC "Include arithmetic encoding support when emulating the libjpeg v6b API/ABI" TRUE)
+boolean_number(WITH_ARITH_ENC)
+if(CMAKE_C_COMPILER_ABI MATCHES "ELF X32")
+  set(WITH_JAVA 0)
+else()
+  option(WITH_JAVA "Build Java wrapper for the TurboJPEG API library (implies ENABLE_SHARED=1)" FALSE)
+  boolean_number(WITH_JAVA)
+endif()
+option(WITH_JPEG7 "Emulate libjpeg v7 API/ABI (this makes ${CMAKE_PROJECT_NAME} backward-incompatible with libjpeg v6b)" FALSE)
+boolean_number(WITH_JPEG7)
+option(WITH_JPEG8 "Emulate libjpeg v8 API/ABI (this makes ${CMAKE_PROJECT_NAME} backward-incompatible with libjpeg v6b)" FALSE)
+boolean_number(WITH_JPEG8)
+option(WITH_MEM_SRCDST "Include in-memory source/destination manager functions when emulating the libjpeg v6b or v7 API/ABI" TRUE)
+boolean_number(WITH_MEM_SRCDST)
+option(WITH_SIMD "Include SIMD extensions, if available for this platform" FALSE)
+boolean_number(WITH_SIMD)
+option(WITH_TURBOJPEG "Include the TurboJPEG API library and associated test programs" FALSE)
+boolean_number(WITH_TURBOJPEG)
+option(WITH_FUZZ "Build fuzz targets" FALSE)
+
+macro(report_option var desc)
+  if(${var})
+    message(STATUS "${desc} enabled (${var} = ${${var}})")
+  else()
+    message(STATUS "${desc} disabled (${var} = ${${var}})")
+  endif()
+endmacro()
+
+if(WITH_JAVA)
+  set(ENABLE_SHARED 1)
+endif()
+
+# Explicitly setting CMAKE_POSITION_INDEPENDENT_CODE=FALSE disables PIC for all
+# targets, which will cause the shared library builds to fail.  Thus, if shared
+# libraries are enabled and CMAKE_POSITION_INDEPENDENT_CODE is explicitly set
+# to FALSE, we need to unset it, thus restoring the default behavior
+# (automatically using PIC for shared library targets.)
+if(DEFINED CMAKE_POSITION_INDEPENDENT_CODE AND
+  NOT CMAKE_POSITION_INDEPENDENT_CODE AND ENABLE_SHARED)
+  unset(CMAKE_POSITION_INDEPENDENT_CODE CACHE)
+endif()
+
+report_option(ENABLE_SHARED "Shared libraries")
+report_option(ENABLE_STATIC "Static libraries")
+
+if(ENABLE_SHARED)
+  set(CMAKE_INSTALL_RPATH ${CMAKE_INSTALL_FULL_LIBDIR})
+endif()
+
+if(WITH_JPEG8 OR WITH_JPEG7)
+  set(WITH_ARITH_ENC 1)
+  set(WITH_ARITH_DEC 1)
+endif()
+if(WITH_JPEG8)
+  set(WITH_MEM_SRCDST 0)
+endif()
+
+if(WITH_12BIT)
+  set(WITH_ARITH_DEC 0)
+  set(WITH_ARITH_ENC 0)
+  set(WITH_JAVA 0)
+  set(WITH_SIMD 0)
+  set(WITH_TURBOJPEG 0)
+  set(BITS_IN_JSAMPLE 12)
+else()
+  set(BITS_IN_JSAMPLE 8)
+endif()
+report_option(WITH_12BIT "12-bit JPEG support")
+
+if(WITH_ARITH_DEC)
+  set(D_ARITH_CODING_SUPPORTED 1)
+endif()
+if(NOT WITH_12BIT)
+  report_option(WITH_ARITH_DEC "Arithmetic decoding support")
+endif()
+
+if(WITH_ARITH_ENC)
+  set(C_ARITH_CODING_SUPPORTED 1)
+endif()
+if(NOT WITH_12BIT)
+  report_option(WITH_ARITH_ENC "Arithmetic encoding support")
+endif()
+
+if(NOT WITH_12BIT)
+  report_option(WITH_TURBOJPEG "TurboJPEG API library")
+  report_option(WITH_JAVA "TurboJPEG Java wrapper")
+endif()
+
+if(WITH_MEM_SRCDST)
+  set(MEM_SRCDST_SUPPORTED 1)
+  set(MEM_SRCDST_FUNCTIONS "global:  jpeg_mem_dest;  jpeg_mem_src;")
+endif()
+if(NOT WITH_JPEG8)
+  report_option(WITH_MEM_SRCDST "In-memory source/destination managers")
+endif()
+
+set(SO_AGE 2)
+if(WITH_MEM_SRCDST)
+  set(SO_AGE 3)
+endif()
+
+if(WITH_JPEG8)
+  set(JPEG_LIB_VERSION 80)
+elseif(WITH_JPEG7)
+  set(JPEG_LIB_VERSION 70)
+else()
+  set(JPEG_LIB_VERSION 62)
+endif()
+
+math(EXPR JPEG_LIB_VERSION_DIV10 "${JPEG_LIB_VERSION} / 10")
+math(EXPR JPEG_LIB_VERSION_MOD10 "${JPEG_LIB_VERSION} % 10")
+if(JPEG_LIB_VERSION STREQUAL "62")
+  set(DEFAULT_SO_MAJOR_VERSION ${JPEG_LIB_VERSION})
+else()
+  set(DEFAULT_SO_MAJOR_VERSION ${JPEG_LIB_VERSION_DIV10})
+endif()
+if(JPEG_LIB_VERSION STREQUAL "80")
+  set(DEFAULT_SO_MINOR_VERSION 2)
+else()
+  set(DEFAULT_SO_MINOR_VERSION 0)
+endif()
+
+# This causes SO_MAJOR_VERSION/SO_MINOR_VERSION to reset to defaults if
+# WITH_JPEG7 or WITH_JPEG8 has changed.
+if((DEFINED WITH_JPEG7_INT AND NOT WITH_JPEG7 EQUAL WITH_JPEG7_INT) OR
+  (DEFINED WITH_JPEG8_INT AND NOT WITH_JPEG8 EQUAL WITH_JPEG8_INT))
+  set(FORCE_SO_VERSION "FORCE")
+endif()
+set(WITH_JPEG7_INT ${WITH_JPEG7} CACHE INTERNAL "")
+set(WITH_JPEG8_INT ${WITH_JPEG8} CACHE INTERNAL "")
+
+set(SO_MAJOR_VERSION ${DEFAULT_SO_MAJOR_VERSION} CACHE STRING
+  "Major version of the libjpeg API shared library (default: ${DEFAULT_SO_MAJOR_VERSION})"
+  ${FORCE_SO_VERSION})
+set(SO_MINOR_VERSION ${DEFAULT_SO_MINOR_VERSION} CACHE STRING
+  "Minor version of the libjpeg API shared library (default: ${DEFAULT_SO_MINOR_VERSION})"
+  ${FORCE_SO_VERSION})
+
+set(JPEG_LIB_VERSION_DECIMAL "${JPEG_LIB_VERSION_DIV10}.${JPEG_LIB_VERSION_MOD10}")
+message(STATUS "Emulating libjpeg API/ABI v${JPEG_LIB_VERSION_DECIMAL} (WITH_JPEG7 = ${WITH_JPEG7}, WITH_JPEG8 = ${WITH_JPEG8})")
+message(STATUS "libjpeg API shared library version = ${SO_MAJOR_VERSION}.${SO_AGE}.${SO_MINOR_VERSION}")
+
+# Because the TurboJPEG API library uses versioned symbols and changes the
+# names of functions whenever they are modified in a backward-incompatible
+# manner, it is always backward-ABI-compatible with itself, so the major and
+# minor SO versions don't change.  However, we increase the middle number (the
+# SO "age") whenever functions are added to the API.
+set(TURBOJPEG_SO_MAJOR_VERSION 0)
+set(TURBOJPEG_SO_AGE 2)
+set(TURBOJPEG_SO_VERSION 0.${TURBOJPEG_SO_AGE}.0)
+
+
+###############################################################################
+# COMPILER SETTINGS
+###############################################################################
+
+if(MSVC)
+  option(WITH_CRT_DLL
+    "Link all ${CMAKE_PROJECT_NAME} libraries and executables with the C run-time DLL (msvcr*.dll) instead of the static C run-time library (libcmt*.lib.)  The default is to use the C run-time DLL only with the libraries and executables that need it."
+    FALSE)
+  if(NOT WITH_CRT_DLL)
+    # Use the static C library for all build types
+    foreach(var CMAKE_C_FLAGS CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_RELEASE
+      CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_RELWITHDEBINFO)
+      if(${var} MATCHES "/MD")
+        string(REGEX REPLACE "/MD" "/MT" ${var} "${${var}}")
+      endif()
+    endforeach()
+  endif()
+  add_definitions(-D_CRT_NONSTDC_NO_WARNINGS)
+endif()
+
+if(CMAKE_COMPILER_IS_GNUCC OR CMAKE_C_COMPILER_ID STREQUAL "Clang")
+  # Use the maximum optimization level for release builds
+  foreach(var CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_RELWITHDEBINFO)
+    if(${var} MATCHES "-O2")
+      string(REGEX REPLACE "-O2" "-O3" ${var} "${${var}}")
+    endif()
+  endforeach()
+endif()
+
+if(CMAKE_SYSTEM_NAME STREQUAL "SunOS")
+  if(CMAKE_C_COMPILER_ID MATCHES "SunPro")
+    # Use the maximum optimization level for release builds
+    foreach(var CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_RELWITHDEBINFO)
+      if(${var} MATCHES "-xO3")
+        string(REGEX REPLACE "-xO3" "-xO5" ${var} "${${var}}")
+      endif()
+      if(${var} MATCHES "-xO2")
+        string(REGEX REPLACE "-xO2" "-xO5" ${var} "${${var}}")
+      endif()
+    endforeach()
+  endif()
+endif()
+
+string(TOUPPER ${CMAKE_BUILD_TYPE} CMAKE_BUILD_TYPE_UC)
+
+set(EFFECTIVE_C_FLAGS "${CMAKE_C_FLAGS} ${CMAKE_C_FLAGS_${CMAKE_BUILD_TYPE_UC}}")
+message(STATUS "Compiler flags = ${EFFECTIVE_C_FLAGS}")
+
+set(EFFECTIVE_LD_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${CMAKE_EXE_LINKER_FLAGS_${CMAKE_BUILD_TYPE_UC}}")
+message(STATUS "Linker flags = ${EFFECTIVE_LD_FLAGS}")
+
+include(CheckCSourceCompiles)
+include(CheckIncludeFiles)
+include(CheckTypeSize)
+
+check_type_size("size_t" SIZE_T)
+check_type_size("unsigned long" UNSIGNED_LONG)
+
+if(SIZE_T EQUAL UNSIGNED_LONG)
+  check_c_source_compiles("int main(int argc, char **argv) { unsigned long a = argc;  return __builtin_ctzl(a); }"
+    HAVE_BUILTIN_CTZL)
+endif()
+if(MSVC)
+  check_include_files("intrin.h" HAVE_INTRIN_H)
+endif()
+
+if(UNIX)
+  if(CMAKE_CROSSCOMPILING)
+    set(RIGHT_SHIFT_IS_UNSIGNED 0)
+  else()
+    include(CheckCSourceRuns)
+    check_c_source_runs("
+      #include <stdio.h>
+      #include <stdlib.h>
+      int is_shifting_signed (long arg) {
+        long res = arg >> 4;
+        if (res == -0x7F7E80CL)
+          return 1; /* right shift is signed */
+        /* see if unsigned-shift hack will fix it. */
+        /* we can't just test exact value since it depends on width of long... */
+        res |= (~0L) << (32-4);
+        if (res == -0x7F7E80CL)
+          return 0; /* right shift is unsigned */
+        printf(\"Right shift isn't acting as I expect it to.\\\\n\");
+        printf(\"I fear the JPEG software will not work at all.\\\\n\\\\n\");
+        return 0; /* try it with unsigned anyway */
+      }
+      int main (void) {
+        exit(is_shifting_signed(-0x7F7E80B1L));
+      }" RIGHT_SHIFT_IS_UNSIGNED)
+  endif()
+endif()
+
+if(MSVC)
+  set(INLINE_OPTIONS "__inline;inline")
+else()
+  set(INLINE_OPTIONS "__inline__;inline")
+endif()
+option(FORCE_INLINE "Force function inlining" TRUE)
+boolean_number(FORCE_INLINE)
+if(FORCE_INLINE)
+  if(MSVC)
+    list(INSERT INLINE_OPTIONS 0 "__forceinline")
+  else()
+    list(INSERT INLINE_OPTIONS 0 "inline __attribute__((always_inline))")
+    list(INSERT INLINE_OPTIONS 0 "__inline__ __attribute__((always_inline))")
+  endif()
+endif()
+foreach(inline ${INLINE_OPTIONS})
+  check_c_source_compiles("${inline} static int foo(void) { return 0; } int main(void) { return foo(); }"
+    INLINE_WORKS)
+  if(INLINE_WORKS)
+    set(INLINE ${inline})
+    break()
+  endif()
+endforeach()
+if(NOT INLINE_WORKS)
+  message(FATAL_ERROR "Could not determine how to inline functions.")
+endif()
+message(STATUS "INLINE = ${INLINE} (FORCE_INLINE = ${FORCE_INLINE})")
+
+if(WITH_TURBOJPEG)
+  if(MSVC)
+    set(THREAD_LOCAL "__declspec(thread)")
+  else()
+    set(THREAD_LOCAL "__thread")
+  endif()
+  check_c_source_compiles("${THREAD_LOCAL} int i;  int main(void) { i = 0;  return i; }" HAVE_THREAD_LOCAL)
+  if(HAVE_THREAD_LOCAL)
+    message(STATUS "THREAD_LOCAL = ${THREAD_LOCAL}")
+  else()
+    message(WARNING "Thread-local storage is not available.  The TurboJPEG API library's global error handler will not be thread-safe.")
+    unset(THREAD_LOCAL)
+  endif()
+endif()
+
+if(UNIX AND NOT APPLE)
+  file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/conftest.map "VERS_1 { global: *; };")
+  set(CMAKE_REQUIRED_FLAGS
+    "-Wl,--version-script,${CMAKE_CURRENT_BINARY_DIR}/conftest.map")
+  check_c_source_compiles("int main(void) { return 0; }" HAVE_VERSION_SCRIPT)
+  set(CMAKE_REQUIRED_FLAGS)
+  file(REMOVE ${CMAKE_CURRENT_BINARY_DIR}/conftest.map)
+  if(HAVE_VERSION_SCRIPT)
+    message(STATUS "Linker supports GNU-style version scripts")
+    set(MAPFLAG "-Wl,--version-script,")
+    set(TJMAPFLAG "-Wl,--version-script,")
+  else()
+    message(STATUS "Linker does not support GNU-style version scripts")
+    if(CMAKE_SYSTEM_NAME STREQUAL "SunOS")
+      # The Solaris linker doesn't like our version script for the libjpeg API
+      # library, but the version script for the TurboJPEG API library should
+      # still work.
+      file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/conftest.map
+        "VERS_1 { global: foo;  local: *; }; VERS_2 { global: foo2; } VERS_1;")
+      set(CMAKE_REQUIRED_FLAGS "-Wl,-M,${CMAKE_CURRENT_BINARY_DIR}/conftest.map -shared")
+      check_c_source_compiles("int foo() { return 0; } int foo2() { return 2; }"
+        HAVE_MAPFILE)
+      set(CMAKE_REQUIRED_FLAGS)
+      file(REMOVE ${CMAKE_CURRENT_BINARY_DIR}/conftest.map)
+      if(HAVE_MAPFILE)
+        message(STATUS "Linker supports mapfiles")
+        set(TJMAPFLAG "-Wl,-M,")
+      else()
+        message(STATUS "Linker does not support mapfiles")
+      endif()
+    endif()
+  endif()
+endif()
+
+# Generate files
+if(WIN32)
+  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/win/jconfig.h.in jconfig.h)
+else()
+  configure_file(jconfig.h.in jconfig.h)
+endif()
+configure_file(jconfigint.h.in jconfigint.h)
+configure_file(jversion.h.in jversion.h)
+if(UNIX)
+  configure_file(libjpeg.map.in libjpeg.map)
+endif()
+
+# Include directories and compiler definitions
+include_directories(${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_SOURCE_DIR})
+
+
+###############################################################################
+# TARGETS
+###############################################################################
+
+if(CMAKE_EXECUTABLE_SUFFIX_TMP)
+  set(CMAKE_EXECUTABLE_SUFFIX ${CMAKE_EXECUTABLE_SUFFIX_TMP})
+endif()
+message(STATUS "CMAKE_EXECUTABLE_SUFFIX = ${CMAKE_EXECUTABLE_SUFFIX}")
+
+set(JPEG_SOURCES jcapimin.c jcapistd.c jccoefct.c jccolor.c jcdctmgr.c jchuff.c
+  jcicc.c jcinit.c jcmainct.c jcmarker.c jcmaster.c jcomapi.c jcparam.c
+  jcphuff.c jcprepct.c jcsample.c jctrans.c jdapimin.c jdapistd.c jdatadst.c
+  jdatasrc.c jdcoefct.c jdcolor.c jddctmgr.c jdhuff.c jdicc.c jdinput.c
+  jdmainct.c jdmarker.c jdmaster.c jdmerge.c jdphuff.c jdpostct.c jdsample.c
+  jdtrans.c jerror.c jfdctflt.c jfdctfst.c jfdctint.c jidctflt.c jidctfst.c
+  jidctint.c jidctred.c jquant1.c jquant2.c jutils.c jmemmgr.c jmemnobs.c)
+
+if(WITH_ARITH_ENC OR WITH_ARITH_DEC)
+  set(JPEG_SOURCES ${JPEG_SOURCES} jaricom.c)
+endif()
+
+if(WITH_ARITH_ENC)
+  set(JPEG_SOURCES ${JPEG_SOURCES} jcarith.c)
+endif()
+
+if(WITH_ARITH_DEC)
+  set(JPEG_SOURCES ${JPEG_SOURCES} jdarith.c)
+endif()
+
+if(WITH_SIMD)
+  add_subdirectory(simd)
+  if(NEON_INTRINSICS)
+    add_definitions(-DNEON_INTRINSICS)
+  endif()
+elseif(NOT WITH_12BIT)
+  message(STATUS "SIMD extensions: None (WITH_SIMD = ${WITH_SIMD})")
+endif()
+if(WITH_SIMD)
+  message(STATUS "SIMD extensions: ${CPU_TYPE} (WITH_SIMD = ${WITH_SIMD})")
+  if(MSVC_IDE OR XCODE)
+    set_source_files_properties(${SIMD_OBJS} PROPERTIES GENERATED 1)
+  endif()
+else()
+  add_library(simd OBJECT jsimd_none.c)
+  if(NOT WIN32 AND (CMAKE_POSITION_INDEPENDENT_CODE OR ENABLE_SHARED))
+    set_target_properties(simd PROPERTIES POSITION_INDEPENDENT_CODE 1)
+  endif()
+endif()
+
+if(WITH_JAVA)
+  add_subdirectory(java)
+endif()
+
+if(ENABLE_SHARED)
+  add_subdirectory(sharedlib)
+endif()
+
+if(ENABLE_STATIC)
+  add_library(jpeg-static STATIC ${JPEG_SOURCES} $<TARGET_OBJECTS:simd>
+    ${SIMD_OBJS})
+  if(NOT MSVC)
+    set_target_properties(jpeg-static PROPERTIES OUTPUT_NAME jpeg)
+  endif()
+endif()
+
+if(WITH_TURBOJPEG)
+  if(ENABLE_SHARED)
+    set(TURBOJPEG_SOURCES ${JPEG_SOURCES} $<TARGET_OBJECTS:simd> ${SIMD_OBJS}
+      turbojpeg.c transupp.c jdatadst-tj.c jdatasrc-tj.c rdbmp.c rdppm.c
+      wrbmp.c wrppm.c)
+    set(TJMAPFILE ${CMAKE_CURRENT_SOURCE_DIR}/turbojpeg-mapfile)
+    if(WITH_JAVA)
+      set(TURBOJPEG_SOURCES ${TURBOJPEG_SOURCES} turbojpeg-jni.c)
+      include_directories(${JAVA_INCLUDE_PATH} ${JAVA_INCLUDE_PATH2})
+      set(TJMAPFILE ${CMAKE_CURRENT_SOURCE_DIR}/turbojpeg-mapfile.jni)
+    endif()
+    if(MSVC)
+      configure_file(${CMAKE_SOURCE_DIR}/win/turbojpeg.rc.in
+        ${CMAKE_BINARY_DIR}/win/turbojpeg.rc)
+      set(TURBOJPEG_SOURCES ${TURBOJPEG_SOURCES}
+        ${CMAKE_BINARY_DIR}/win/turbojpeg.rc)
+    endif()
+    add_library(turbojpeg SHARED ${TURBOJPEG_SOURCES})
+    set_property(TARGET turbojpeg PROPERTY COMPILE_FLAGS
+      "-DBMP_SUPPORTED -DPPM_SUPPORTED")
+    if(WIN32)
+      set_target_properties(turbojpeg PROPERTIES DEFINE_SYMBOL DLLDEFINE)
+    endif()
+    if(MINGW)
+      set_target_properties(turbojpeg PROPERTIES LINK_FLAGS -Wl,--kill-at)
+    endif()
+    if(APPLE AND (NOT CMAKE_OSX_DEPLOYMENT_TARGET OR
+                  CMAKE_OSX_DEPLOYMENT_TARGET VERSION_GREATER 10.4))
+      if(NOT CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG)
+        set(CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG "-Wl,-rpath,")
+      endif()
+      set_target_properties(turbojpeg PROPERTIES MACOSX_RPATH 1)
+    endif()
+    set_target_properties(turbojpeg PROPERTIES
+      SOVERSION ${TURBOJPEG_SO_MAJOR_VERSION} VERSION ${TURBOJPEG_SO_VERSION})
+    if(TJMAPFLAG)
+      set_target_properties(turbojpeg PROPERTIES
+        LINK_FLAGS "${TJMAPFLAG}${TJMAPFILE}")
+    endif()
+  endif()
+
+  if(ENABLE_STATIC)
+    add_library(turbojpeg-static STATIC ${JPEG_SOURCES} $<TARGET_OBJECTS:simd>
+      ${SIMD_OBJS} turbojpeg.c transupp.c jdatadst-tj.c jdatasrc-tj.c rdbmp.c
+      rdppm.c wrbmp.c wrppm.c)
+    set_property(TARGET turbojpeg-static PROPERTY COMPILE_FLAGS
+      "-DBMP_SUPPORTED -DPPM_SUPPORTED")
+    if(NOT MSVC)
+      set_target_properties(turbojpeg-static PROPERTIES OUTPUT_NAME turbojpeg)
+    endif()
+  endif()
+endif()
+
+if(WIN32)
+  set(USE_SETMODE "-DUSE_SETMODE")
+endif()
+if(WITH_12BIT)
+  set(COMPILE_FLAGS "-DGIF_SUPPORTED -DPPM_SUPPORTED ${USE_SETMODE}")
+else()
+  set(COMPILE_FLAGS "-DBMP_SUPPORTED -DGIF_SUPPORTED -DPPM_SUPPORTED -DTARGA_SUPPORTED ${USE_SETMODE}")
+  set(CJPEG_BMP_SOURCES rdbmp.c rdtarga.c)
+  set(DJPEG_BMP_SOURCES wrbmp.c wrtarga.c)
+endif()

cmake/CMakeLists.png

@@ -0,0 +1,741 @@
+# CMakeLists.txt
+
+# Copyright (C) 2018 Cosmin Truta
+# Copyright (C) 2007,2009-2018 Glenn Randers-Pehrson
+# Written by Christian Ehrlicher, 2007
+# Revised by Roger Lowman, 2009-2010
+# Revised by Clifford Yapp, 2011-2012,2017
+# Revised by Roger Leigh, 2016
+# Revised by Andreas Franek, 2016
+# Revised by Sam Serrels, 2017
+# Revised by Vadim Barkov, 2017
+# Revised by Vicky Pfau, 2018
+# Revised by Cameron Cawley, 2018
+# Revised by Cosmin Truta, 2018
+# Revised by Kyle Bentley, 2018
+
+# This code is released under the libpng license.
+# For conditions of distribution and use, see the disclaimer
+# and license in png.h
+
+cmake_minimum_required(VERSION 3.10)
+cmake_policy(VERSION 3.1)
+# When using CMake 3.4 and later, don't export symbols from executables unless
+# the CMAKE_ENABLE_EXPORTS variable is set.
+if(POLICY CMP0065)
+  cmake_policy(SET CMP0065 NEW)
+endif()
+if (POLICY CMP0077)
+  cmake_policy(SET CMP0077 NEW)
+endif()
+set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS ON)
+
+project(libpng C ASM)
+enable_testing()
+
+set(PNGLIB_MAJOR 1)
+set(PNGLIB_MINOR 6)
+set(PNGLIB_RELEASE 37)
+set(PNGLIB_NAME libpng${PNGLIB_MAJOR}${PNGLIB_MINOR})
+set(PNGLIB_VERSION ${PNGLIB_MAJOR}.${PNGLIB_MINOR}.${PNGLIB_RELEASE})
+
+include(GNUInstallDirs)
+
+# needed packages
+
+# Allow users to specify location of Zlib.
+# Useful if zlib is being built alongside this as a sub-project.
+option(PNG_BUILD_ZLIB "Custom zlib Location, else find_package is used" ON)
+
+if(NOT PNG_BUILD_ZLIB)
+  find_package(ZLIB REQUIRED)
+  include_directories(${ZLIB_INCLUDE_DIR})
+endif()
+
+if(UNIX AND NOT APPLE AND NOT BEOS AND NOT HAIKU)
+  find_library(M_LIBRARY m)
+else()
+  # libm is not needed and/or not available
+  set(M_LIBRARY "")
+endif()
+
+# COMMAND LINE OPTIONS
+option(PNG_SHARED "Build shared lib" OFF)
+option(PNG_STATIC "Build static lib" ON)
+option(PNG_TESTS  "Build libpng tests" OFF)
+
+# Many more configuration options could be added here
+option(PNG_FRAMEWORK "Build OS X framework" OFF)
+option(PNG_DEBUG "Build with debug output" OFF)
+option(PNG_HARDWARE_OPTIMIZATIONS "Enable hardware optimizations" OFF)
+
+set(PNG_PREFIX "" CACHE STRING "Prefix to add to the API function names")
+set(DFA_XTRA "" CACHE FILEPATH "File containing extra configuration settings")
+
+if(PNG_HARDWARE_OPTIMIZATIONS)
+
+# set definitions and sources for arm
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "^arm" OR
+  CMAKE_SYSTEM_PROCESSOR MATCHES "^aarch64")
+  set(PNG_ARM_NEON_POSSIBLE_VALUES check on off)
+  set(PNG_ARM_NEON "check" CACHE STRING "Enable ARM NEON optimizations:
+     check: (default) use internal checking code;
+     off: disable the optimizations;
+     on: turn on unconditionally.")
+  set_property(CACHE PNG_ARM_NEON PROPERTY STRINGS
+     ${PNG_ARM_NEON_POSSIBLE_VALUES})
+  list(FIND PNG_ARM_NEON_POSSIBLE_VALUES ${PNG_ARM_NEON} index)
+  if(index EQUAL -1)
+    message(FATAL_ERROR
+            "PNG_ARM_NEON must be one of [${PNG_ARM_NEON_POSSIBLE_VALUES}]")
+  elseif(NOT ${PNG_ARM_NEON} STREQUAL "off")
+    set(libpng_arm_sources
+      arm/arm_init.c
+      arm/filter_neon.S
+      arm/filter_neon_intrinsics.c
+      arm/palette_neon_intrinsics.c)
+
+    if(${PNG_ARM_NEON} STREQUAL "on")
+      add_definitions(-DPNG_ARM_NEON_OPT=2)
+    elseif(${PNG_ARM_NEON} STREQUAL "check")
+      add_definitions(-DPNG_ARM_NEON_CHECK_SUPPORTED)
+    endif()
+  else()
+    add_definitions(-DPNG_ARM_NEON_OPT=0)
+  endif()
+endif()
+
+# set definitions and sources for powerpc
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "^powerpc*" OR
+   CMAKE_SYSTEM_PROCESSOR MATCHES "^ppc64*")
+  set(PNG_POWERPC_VSX_POSSIBLE_VALUES on off)
+  set(PNG_POWERPC_VSX "on" CACHE STRING "Enable POWERPC VSX optimizations:
+     off: disable the optimizations.")
+  set_property(CACHE PNG_POWERPC_VSX PROPERTY STRINGS
+     ${PNG_POWERPC_VSX_POSSIBLE_VALUES})
+  list(FIND PNG_POWERPC_VSX_POSSIBLE_VALUES ${PNG_POWERPC_VSX} index)
+  if(index EQUAL -1)
+    message(FATAL_ERROR
+            "PNG_POWERPC_VSX must be one of [${PNG_POWERPC_VSX_POSSIBLE_VALUES}]")
+  elseif(NOT ${PNG_POWERPC_VSX} STREQUAL "off")
+    set(libpng_powerpc_sources
+      powerpc/powerpc_init.c
+      powerpc/filter_vsx_intrinsics.c)
+    if(${PNG_POWERPC_VSX} STREQUAL "on")
+      add_definitions(-DPNG_POWERPC_VSX_OPT=2)
+    endif()
+  else()
+    add_definitions(-DPNG_POWERPC_VSX_OPT=0)
+  endif()
+endif()
+
+# set definitions and sources for intel
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "^i?86" OR
+   CMAKE_SYSTEM_PROCESSOR MATCHES "^x86_64*")
+  set(PNG_INTEL_SSE_POSSIBLE_VALUES on off)
+  set(PNG_INTEL_SSE "on" CACHE STRING "Enable INTEL_SSE optimizations:
+     off: disable the optimizations")
+  set_property(CACHE PNG_INTEL_SSE PROPERTY STRINGS
+     ${PNG_INTEL_SSE_POSSIBLE_VALUES})
+  list(FIND PNG_INTEL_SSE_POSSIBLE_VALUES ${PNG_INTEL_SSE} index)
+  if(index EQUAL -1)
+    message(FATAL_ERROR
+            "PNG_INTEL_SSE must be one of [${PNG_INTEL_SSE_POSSIBLE_VALUES}]")
+  elseif(NOT ${PNG_INTEL_SSE} STREQUAL "off")
+    set(libpng_intel_sources
+      intel/intel_init.c
+      intel/filter_sse2_intrinsics.c)
+    if(${PNG_INTEL_SSE} STREQUAL "on")
+      add_definitions(-DPNG_INTEL_SSE_OPT=1)
+    endif()
+  else()
+    add_definitions(-DPNG_INTEL_SSE_OPT=0)
+  endif()
+endif()
+
+# set definitions and sources for MIPS
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "mipsel*" OR
+   CMAKE_SYSTEM_PROCESSOR MATCHES "mips64el*")
+  set(PNG_MIPS_MSA_POSSIBLE_VALUES on off)
+  set(PNG_MIPS_MSA "on" CACHE STRING "Enable MIPS_MSA optimizations:
+     off: disable the optimizations")
+  set_property(CACHE PNG_MIPS_MSA PROPERTY STRINGS
+     ${PNG_MIPS_MSA_POSSIBLE_VALUES})
+  list(FIND PNG_MIPS_MSA_POSSIBLE_VALUES ${PNG_MIPS_MSA} index)
+  if(index EQUAL -1)
+    message(FATAL_ERROR
+            "PNG_MIPS_MSA must be one of [${PNG_MIPS_MSA_POSSIBLE_VALUES}]")
+  elseif(NOT ${PNG_MIPS_MSA} STREQUAL "off")
+    set(libpng_mips_sources
+      mips/mips_init.c
+      mips/filter_msa_intrinsics.c)
+    if(${PNG_MIPS_MSA} STREQUAL "on")
+      add_definitions(-DPNG_MIPS_MSA_OPT=2)
+    endif()
+  else()
+    add_definitions(-DPNG_MIPS_MSA_OPT=0)
+  endif()
+endif()
+
+else(PNG_HARDWARE_OPTIMIZATIONS)
+
+# set definitions and sources for arm
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "^arm" OR
+   CMAKE_SYSTEM_PROCESSOR MATCHES "^aarch64")
+  add_definitions(-DPNG_ARM_NEON_OPT=0)
+endif()
+
+# set definitions and sources for powerpc
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "^powerpc*" OR
+   CMAKE_SYSTEM_PROCESSOR MATCHES "^ppc64*")
+  add_definitions(-DPNG_POWERPC_VSX_OPT=0)
+endif()
+
+# set definitions and sources for intel
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "^i?86" OR
+   CMAKE_SYSTEM_PROCESSOR MATCHES "^x86_64*")
+  add_definitions(-DPNG_INTEL_SSE_OPT=0)
+endif()
+
+# set definitions and sources for MIPS
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "mipsel*" OR
+   CMAKE_SYSTEM_PROCESSOR MATCHES "mips64el*")
+  add_definitions(-DPNG_MIPS_MSA_OPT=0)
+endif()
+
+endif(PNG_HARDWARE_OPTIMIZATIONS)
+
+# SET LIBNAME
+set(PNG_LIB_NAME png${PNGLIB_MAJOR}${PNGLIB_MINOR})
+
+# to distinguish between debug and release lib
+set(CMAKE_DEBUG_POSTFIX "d")
+
+include(CheckCSourceCompiles)
+option(ld-version-script "Enable linker version script" ON)
+if(ld-version-script AND NOT APPLE)
+  # Check if LD supports linker scripts.
+  file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/conftest.map" "VERS_1 {
+        global: sym;
+        local: *;
+};
+
+VERS_2 {
+        global: sym2;
+                main;
+} VERS_1;
+")
+  set(CMAKE_REQUIRED_FLAGS_SAVE ${CMAKE_REQUIRED_FLAGS})
+  set(CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS} "-Wl,--version-script='${CMAKE_CURRENT_BINARY_DIR}/conftest.map'")
+  check_c_source_compiles("void sym(void) {}
+void sym2(void) {}
+int main(void) {return 0;}
+" HAVE_LD_VERSION_SCRIPT)
+  if(NOT HAVE_LD_VERSION_SCRIPT)
+    set(CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS_SAVE} "-Wl,-M -Wl,${CMAKE_CURRENT_BINARY_DIR}/conftest.map")
+  check_c_source_compiles("void sym(void) {}
+void sym2(void) {}
+int main(void) {return 0;}
+" HAVE_SOLARIS_LD_VERSION_SCRIPT)
+  endif()
+  set(CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS_SAVE})
+  file(REMOVE "${CMAKE_CURRENT_BINARY_DIR}/conftest.map")
+endif()
+
+# Find symbol prefix.  Likely obsolete and unnecessary with recent
+# toolchains (it's not done in many other projects).
+function(symbol_prefix)
+  set(SYMBOL_PREFIX)
+
+  execute_process(COMMAND "${CMAKE_C_COMPILER}" "-E" "-"
+                  INPUT_FILE /dev/null
+                  OUTPUT_VARIABLE OUT
+                  RESULT_VARIABLE STATUS)
+
+  if(CPP_FAIL)
+    message(WARNING "Failed to run the C preprocessor")
+  endif()
+
+  string(REPLACE "\n" ";" OUT "${OUT}")
+  foreach(line ${OUT})
+    string(REGEX MATCH "^PREFIX=" found_match "${line}")
+    if(found_match)
+      string(REGEX REPLACE "^PREFIX=(.*\)" "\\1" prefix "${line}")
+      string(REGEX MATCH "__USER_LABEL_PREFIX__" found_match "${prefix}")
+      if(found_match)
+        string(REGEX REPLACE "(.*)__USER_LABEL_PREFIX__(.*)" "\\1\\2" prefix "${prefix}")
+      endif()
+      set(SYMBOL_PREFIX "${prefix}")
+    endif()
+  endforeach()
+
+  message(STATUS "Symbol prefix: ${SYMBOL_PREFIX}")
+  set(SYMBOL_PREFIX "${SYMBOL_PREFIX}" PARENT_SCOPE)
+endfunction()
+
+if(UNIX)
+  symbol_prefix()
+endif()
+
+find_program(AWK NAMES gawk awk)
+
+include_directories(${CMAKE_CURRENT_BINARY_DIR})
+
+if(NOT AWK OR ANDROID)
+  # No awk available to generate sources; use pre-built pnglibconf.h
+  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/scripts/pnglibconf.h.prebuilt
+                 ${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h)
+  add_custom_target(genfiles) # Dummy
+else()
+  include(CMakeParseArguments)
+  # Generate .chk from .out with awk
+  # generate_chk(INPUT inputfile OUTPUT outputfile [DEPENDS dep1 [dep2...]])
+  function(generate_chk)
+    set(options)
+    set(oneValueArgs INPUT OUTPUT)
+    set(multiValueArgs DEPENDS)
+    cmake_parse_arguments(_GC "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
+    if(NOT _GC_INPUT)
+      message(FATAL_ERROR "generate_chk: Missing INPUT argument")
+    endif()
+    if(NOT _GC_OUTPUT)
+      message(FATAL_ERROR "generate_chk: Missing OUTPUT argument")
+    endif()
+
+    add_custom_command(OUTPUT "${_GC_OUTPUT}"
+                       COMMAND "${CMAKE_COMMAND}"
+                               "-DINPUT=${_GC_INPUT}"
+                               "-DOUTPUT=${_GC_OUTPUT}"
+                               -P "${CMAKE_CURRENT_BINARY_DIR}/scripts/genchk.cmake"
+                       DEPENDS "${_GC_INPUT}" ${_GC_DEPENDS}
+                       WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
+  endfunction()
+
+  # Generate .out from .c with awk
+  # generate_out(INPUT inputfile OUTPUT outputfile [DEPENDS dep1 [dep2...]])
+  function(generate_out)
+    set(options)
+    set(oneValueArgs INPUT OUTPUT)
+    set(multiValueArgs DEPENDS)
+    cmake_parse_arguments(_GO "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
+    if(NOT _GO_INPUT)
+      message(FATAL_ERROR "generate_out: Missing INPUT argument")
+    endif()
+    if(NOT _GO_OUTPUT)
+      message(FATAL_ERROR "generate_out: Missing OUTPUT argument")
+    endif()
+
+    add_custom_command(OUTPUT "${_GO_OUTPUT}"
+                       COMMAND "${CMAKE_COMMAND}"
+                               "-DINPUT=${_GO_INPUT}"
+                               "-DOUTPUT=${_GO_OUTPUT}"
+                               -P "${CMAKE_CURRENT_BINARY_DIR}/scripts/genout.cmake"
+                       DEPENDS "${_GO_INPUT}" ${_GO_DEPENDS}
+                       WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
+  endfunction()
+
+  # Generate specific source file with awk
+  # generate_source(OUTPUT outputfile [DEPENDS dep1 [dep2...]])
+  function(generate_source)
+    set(options)
+    set(oneValueArgs OUTPUT)
+    set(multiValueArgs DEPENDS)
+    cmake_parse_arguments(_GSO "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
+    if(NOT _GSO_OUTPUT)
+      message(FATAL_ERROR "generate_source: Missing OUTPUT argument")
+    endif()
+
+    add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/${_GSO_OUTPUT}"
+                       COMMAND "${CMAKE_COMMAND}"
+                               "-DOUTPUT=${_GSO_OUTPUT}"
+                               -P "${CMAKE_CURRENT_BINARY_DIR}/scripts/gensrc.cmake"
+                       DEPENDS ${_GSO_DEPENDS}
+                       WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
+  endfunction()
+
+  # Copy file
+  function(generate_copy source destination)
+    add_custom_command(OUTPUT "${destination}"
+                       COMMAND "${CMAKE_COMMAND}" -E remove "${destination}"
+                       COMMAND "${CMAKE_COMMAND}" -E copy "${source}"
+                                                          "${destination}"
+                       DEPENDS "${source}")
+  endfunction()
+
+  # Generate scripts/pnglibconf.h
+  generate_source(OUTPUT "scripts/pnglibconf.c"
+                  DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/scripts/pnglibconf.dfa"
+                          "${CMAKE_CURRENT_SOURCE_DIR}/scripts/options.awk"
+                          "${CMAKE_CURRENT_SOURCE_DIR}/pngconf.h")
+
+  # Generate pnglibconf.c
+  generate_source(OUTPUT "pnglibconf.c"
+                  DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/scripts/pnglibconf.dfa"
+                          "${CMAKE_CURRENT_SOURCE_DIR}/scripts/options.awk"
+                          "${CMAKE_CURRENT_SOURCE_DIR}/pngconf.h")
+
+  if(PNG_PREFIX)
+    set(PNGLIBCONF_H_EXTRA_DEPENDS
+        "${CMAKE_CURRENT_BINARY_DIR}/scripts/prefix.out"
+        "${CMAKE_CURRENT_SOURCE_DIR}/scripts/macro.lst")
+    set(PNGPREFIX_H_EXTRA_DEPENDS
+        "${CMAKE_CURRENT_BINARY_DIR}/scripts/intprefix.out")
+  endif()
+
+  generate_out(INPUT "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.c"
+               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.out")
+
+  # Generate pnglibconf.h
+  generate_source(OUTPUT "pnglibconf.h"
+                  DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.out"
+                          ${PNGLIBCONF_H_EXTRA_DEPENDS})
+
+  generate_out(INPUT "${CMAKE_CURRENT_SOURCE_DIR}/scripts/intprefix.c"
+               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/intprefix.out"
+               DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h")
+
+  generate_out(INPUT "${CMAKE_CURRENT_SOURCE_DIR}/scripts/prefix.c"
+               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/prefix.out"
+               DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/png.h"
+                       "${CMAKE_CURRENT_SOURCE_DIR}/pngconf.h"
+                       "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.out")
+
+  # Generate pngprefix.h
+  generate_source(OUTPUT "pngprefix.h"
+                  DEPENDS ${PNGPREFIX_H_EXTRA_DEPENDS})
+
+  generate_out(INPUT "${CMAKE_CURRENT_SOURCE_DIR}/scripts/sym.c"
+               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/sym.out"
+               DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h")
+
+  generate_out(INPUT "${CMAKE_CURRENT_SOURCE_DIR}/scripts/symbols.c"
+               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.out"
+               DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/png.h"
+                       "${CMAKE_CURRENT_SOURCE_DIR}/pngconf.h"
+                       "${CMAKE_CURRENT_SOURCE_DIR}/scripts/pnglibconf.h.prebuilt")
+
+  generate_out(INPUT "${CMAKE_CURRENT_SOURCE_DIR}/scripts/vers.c"
+               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/vers.out"
+               DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/png.h"
+                       "${CMAKE_CURRENT_SOURCE_DIR}/pngconf.h"
+                       "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h")
+
+  generate_chk(INPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.out"
+               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.chk"
+               DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/scripts/checksym.awk"
+                       "${CMAKE_CURRENT_SOURCE_DIR}/scripts/symbols.def")
+
+  add_custom_target(symbol-check DEPENDS
+                    "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.chk")
+
+  generate_copy("${CMAKE_CURRENT_BINARY_DIR}/scripts/sym.out"
+                "${CMAKE_CURRENT_BINARY_DIR}/libpng.sym")
+  generate_copy("${CMAKE_CURRENT_BINARY_DIR}/scripts/vers.out"
+                "${CMAKE_CURRENT_BINARY_DIR}/libpng.vers")
+
+  add_custom_target(genvers DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/libpng.vers")
+  add_custom_target(gensym DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/libpng.sym")
+
+  add_custom_target("genprebuilt"
+                    COMMAND "${CMAKE_COMMAND}"
+                            "-DOUTPUT=scripts/pnglibconf.h.prebuilt"
+                            -P "${CMAKE_CURRENT_BINARY_DIR}/scripts/gensrc.cmake"
+                    WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
+
+  # A single target handles generation of all generated files.  If
+  # they are depended upon separately by multiple targets, this
+  # confuses parallel make (it would require a separate top-level
+  # target for each file to track the dependencies properly).
+  add_custom_target(genfiles DEPENDS
+    "${CMAKE_CURRENT_BINARY_DIR}/libpng.sym"
+    "${CMAKE_CURRENT_BINARY_DIR}/libpng.vers"
+    "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.c"
+    "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h"
+    "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.out"
+    "${CMAKE_CURRENT_BINARY_DIR}/pngprefix.h"
+    "${CMAKE_CURRENT_BINARY_DIR}/scripts/intprefix.out"
+    "${CMAKE_CURRENT_BINARY_DIR}/scripts/pnglibconf.c"
+    "${CMAKE_CURRENT_BINARY_DIR}/scripts/prefix.out"
+    "${CMAKE_CURRENT_BINARY_DIR}/scripts/sym.out"
+    "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.chk"
+    "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.out"
+    "${CMAKE_CURRENT_BINARY_DIR}/scripts/vers.out")
+endif(NOT AWK OR ANDROID)
+
+# OUR SOURCES
+set(libpng_public_hdrs
+  png.h
+  pngconf.h
+  "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h"
+)
+set(libpng_private_hdrs
+  pngpriv.h
+  pngdebug.h
+  pnginfo.h
+  pngstruct.h
+)
+if(AWK AND NOT ANDROID)
+  list(APPEND libpng_private_hdrs "${CMAKE_CURRENT_BINARY_DIR}/pngprefix.h")
+endif()
+set(libpng_sources
+  ${libpng_public_hdrs}
+  ${libpng_private_hdrs}
+  png.c
+  pngerror.c
+  pngget.c
+  pngmem.c
+  pngpread.c
+  pngread.c
+  pngrio.c
+  pngrtran.c
+  pngrutil.c
+  pngset.c
+  pngtrans.c
+  pngwio.c
+  pngwrite.c
+  pngwtran.c
+  pngwutil.c
+  ${libpng_arm_sources}
+  ${libpng_intel_sources}
+  ${libpng_mips_sources}
+  ${libpng_powerpc_sources}
+)
+set(pngtest_sources
+  pngtest.c
+)
+set(pngvalid_sources
+  contrib/libtests/pngvalid.c
+)
+set(pngstest_sources
+  contrib/libtests/pngstest.c
+)
+set(pngunknown_sources
+  contrib/libtests/pngunknown.c
+)
+set(pngimage_sources
+  contrib/libtests/pngimage.c
+)
+set(pngfix_sources
+  contrib/tools/pngfix.c
+)
+set(png_fix_itxt_sources
+  contrib/tools/png-fix-itxt.c
+)
+
+if(MSVC)
+  add_definitions(-D_CRT_SECURE_NO_DEPRECATE)
+endif()
+
+if(PNG_DEBUG)
+  add_definitions(-DPNG_DEBUG)
+endif()
+
+# NOW BUILD OUR TARGET
+include_directories(${CMAKE_CURRENT_SOURCE_DIR} ${ZLIB_INCLUDE_DIR})
+
+unset(PNG_LIB_TARGETS)
+
+if(PNG_STATIC)
+  # does not work without changing name
+  set(PNG_LIB_NAME_STATIC png_static)
+  add_library(png_static STATIC ${libpng_sources})
+  add_dependencies(png_static genfiles)
+  # MSVC doesn't use a different file extension for shared vs. static
+  # libs.  We are able to change OUTPUT_NAME to remove the _static
+  # for all other platforms.
+  if(NOT MSVC)
+    set_target_properties(png_static PROPERTIES
+      OUTPUT_NAME "${PNG_LIB_NAME}"
+      CLEAN_DIRECT_OUTPUT 1)
+  else()
+    set_target_properties(png_static PROPERTIES
+      OUTPUT_NAME "${PNG_LIB_NAME}_static"
+      CLEAN_DIRECT_OUTPUT 1)
+  endif()
+  list(APPEND PNG_LIB_TARGETS png_static)
+  if(MSVC)
+    # msvc does not append 'lib' - do it here to have consistent name
+    set_target_properties(png_static PROPERTIES PREFIX "lib")
+  endif()
+  target_link_libraries(png_static ${M_LIBRARY})
+endif()
+
+if(NOT PNG_LIB_TARGETS)
+  message(SEND_ERROR
+    "No library variant selected to build. "
+    "Please enable at least one of the following options: "
+    "PNG_STATIC, PNG_SHARED, PNG_FRAMEWORK")
+endif()
+
+# Set a variable with CMake code which:
+# Creates a symlink from src to dest (if possible) or alternatively
+# copies if different.
+include(CMakeParseArguments)
+
+function(create_symlink DEST_FILE)
+
+  cmake_parse_arguments(S "" "FILE;TARGET" "" ${ARGN})
+
+  if(NOT S_TARGET AND NOT S_FILE)
+    message(FATAL_ERROR "create_symlink: Missing TARGET or FILE argument")
+  endif()
+
+  if(S_TARGET AND S_FILE)
+    message(FATAL_ERROR "create_symlink: Both source file ${S_FILE} and build target ${S_TARGET} arguments are present; can only have one.")
+  endif()
+
+  if(S_FILE)
+    # If we don't need to symlink something that's coming from a build target,
+    # we can go ahead and symlink/copy at configure time.
+    if(CMAKE_HOST_WIN32 AND NOT CYGWIN)
+      execute_process(
+        COMMAND "${CMAKE_COMMAND}" -E copy_if_different ${S_FILE} ${DEST_FILE}
+        WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
+    else()
+      execute_process(
+        COMMAND ${CMAKE_COMMAND} -E create_symlink ${S_FILE} ${DEST_FILE}
+        WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
+    endif()
+  endif()
+
+  if(S_TARGET)
+    # We need to use generator expressions, which can be a bit tricky, so for
+    # simplicity make the symlink a POST_BUILD step and use the TARGET
+    # signature of add_custom_command.
+    if(CMAKE_HOST_WIN32 AND NOT CYGWIN)
+      add_custom_command(TARGET ${S_TARGET} POST_BUILD
+        COMMAND "${CMAKE_COMMAND}" -E copy_if_different $<TARGET_LINKER_FILE_NAME:${S_TARGET}> $<TARGET_LINKER_FILE_DIR:${S_TARGET}>/${DEST_FILE})
+    else()
+      add_custom_command(TARGET ${S_TARGET} POST_BUILD
+        COMMAND "${CMAKE_COMMAND}" -E create_symlink $<TARGET_LINKER_FILE_NAME:${S_TARGET}> $<TARGET_LINKER_FILE_DIR:${S_TARGET}>/${DEST_FILE})
+    endif()
+  endif()
+
+endfunction()
+
+# Create source generation scripts.
+configure_file(${CMAKE_CURRENT_SOURCE_DIR}/scripts/genchk.cmake.in
+               ${CMAKE_CURRENT_BINARY_DIR}/scripts/genchk.cmake @ONLY)
+configure_file(${CMAKE_CURRENT_SOURCE_DIR}/scripts/genout.cmake.in
+               ${CMAKE_CURRENT_BINARY_DIR}/scripts/genout.cmake @ONLY)
+configure_file(${CMAKE_CURRENT_SOURCE_DIR}/scripts/gensrc.cmake.in
+               ${CMAKE_CURRENT_BINARY_DIR}/scripts/gensrc.cmake @ONLY)
+
+# libpng is a library so default to 'lib'
+if(NOT DEFINED CMAKE_INSTALL_LIBDIR)
+  set(CMAKE_INSTALL_LIBDIR lib)
+endif()
+
+# CREATE PKGCONFIG FILES
+# We use the same files like ./configure, so we have to set its vars.
+# Only do this on Windows for Cygwin - the files don't make much sense outside
+# of a UNIX look-alike.
+if(NOT WIN32 OR CYGWIN OR MINGW)
+  set(prefix      ${CMAKE_INSTALL_PREFIX})
+  set(exec_prefix ${CMAKE_INSTALL_PREFIX})
+  set(libdir      ${CMAKE_INSTALL_FULL_LIBDIR})
+  set(includedir  ${CMAKE_INSTALL_FULL_INCLUDEDIR})
+  set(LIBS        "-lz -lm")
+  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/libpng.pc.in
+    ${CMAKE_CURRENT_BINARY_DIR}/${PNGLIB_NAME}.pc @ONLY)
+  create_symlink(libpng.pc FILE ${PNGLIB_NAME}.pc)
+
+  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/libpng-config.in
+    ${CMAKE_CURRENT_BINARY_DIR}/${PNGLIB_NAME}-config @ONLY)
+  create_symlink(libpng-config FILE ${PNGLIB_NAME}-config)
+endif()
+
+# SET UP LINKS
+if(PNG_SHARED)
+  set_target_properties(png PROPERTIES
+#   VERSION 16.${PNGLIB_RELEASE}.1.6.37
+    VERSION 16.${PNGLIB_RELEASE}.0
+    SOVERSION 16
+    CLEAN_DIRECT_OUTPUT 1)
+endif()
+
+# INSTALL
+if(NOT SKIP_INSTALL_LIBRARIES AND NOT SKIP_INSTALL_ALL)
+  install(TARGETS ${PNG_LIB_TARGETS}
+          EXPORT libpng
+          RUNTIME DESTINATION bin
+          LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
+          ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
+          FRAMEWORK DESTINATION ${CMAKE_INSTALL_LIBDIR})
+
+  if(PNG_SHARED)
+    # Create a symlink for libpng.dll.a => libpng16.dll.a on Cygwin
+    if(CYGWIN OR MINGW)
+      create_symlink(libpng${CMAKE_IMPORT_LIBRARY_SUFFIX} TARGET png)
+      install(FILES $<TARGET_LINKER_FILE_DIR:png>/libpng${CMAKE_IMPORT_LIBRARY_SUFFIX}
+              DESTINATION ${CMAKE_INSTALL_LIBDIR})
+    endif()
+
+    if(NOT WIN32)
+      create_symlink(libpng${CMAKE_SHARED_LIBRARY_SUFFIX} TARGET png)
+      install(FILES $<TARGET_LINKER_FILE_DIR:png>/libpng${CMAKE_SHARED_LIBRARY_SUFFIX}
+              DESTINATION ${CMAKE_INSTALL_LIBDIR})
+    endif()
+  endif()
+
+  if(PNG_STATIC)
+    if(NOT WIN32 OR CYGWIN OR MINGW)
+      create_symlink(libpng${CMAKE_STATIC_LIBRARY_SUFFIX} TARGET png_static)
+      install(FILES $<TARGET_LINKER_FILE_DIR:png_static>/libpng${CMAKE_STATIC_LIBRARY_SUFFIX}
+              DESTINATION ${CMAKE_INSTALL_LIBDIR})
+    endif()
+  endif()
+endif()
+
+if(NOT SKIP_INSTALL_HEADERS AND NOT SKIP_INSTALL_ALL)
+  install(FILES ${libpng_public_hdrs} DESTINATION include)
+  install(FILES ${libpng_public_hdrs} DESTINATION include/${PNGLIB_NAME})
+endif()
+if(NOT SKIP_INSTALL_EXECUTABLES AND NOT SKIP_INSTALL_ALL)
+  if(NOT WIN32 OR CYGWIN OR MINGW)
+    install(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/libpng-config DESTINATION bin)
+    install(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/${PNGLIB_NAME}-config DESTINATION bin)
+  endif()
+endif()
+
+if(NOT SKIP_INSTALL_PROGRAMS AND NOT SKIP_INSTALL_ALL)
+  install(TARGETS ${PNG_BIN_TARGETS}
+          RUNTIME DESTINATION bin)
+endif()
+
+if(NOT SKIP_INSTALL_FILES AND NOT SKIP_INSTALL_ALL)
+  # Install man pages
+  if(NOT PNG_MAN_DIR)
+    set(PNG_MAN_DIR "share/man")
+  endif()
+  install(FILES libpng.3 libpngpf.3 DESTINATION ${PNG_MAN_DIR}/man3)
+  install(FILES png.5 DESTINATION ${PNG_MAN_DIR}/man5)
+  # Install pkg-config files
+  if(NOT CMAKE_HOST_WIN32 OR CYGWIN OR MINGW)
+    install(FILES ${CMAKE_CURRENT_BINARY_DIR}/libpng.pc
+            DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
+    install(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/libpng-config
+            DESTINATION bin)
+    install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${PNGLIB_NAME}.pc
+            DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
+    install(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/${PNGLIB_NAME}-config
+            DESTINATION bin)
+  endif()
+endif()
+
+# Create an export file that CMake users can include() to import our targets.
+if(NOT SKIP_INSTALL_EXPORT AND NOT SKIP_INSTALL_ALL)
+  install(EXPORT libpng DESTINATION lib/libpng FILE lib${PNG_LIB_NAME}.cmake)
+endif()
+
+# what's with libpng-manual.txt and all the extra files?
+
+# UNINSTALL
+# do we need this?
+
+# DIST
+# do we need this?
+
+# to create msvc import lib for mingw compiled shared lib
+# pexports libpng.dll > libpng.def
+# lib /def:libpng.def /machine:x86

cmake/CMakeLists.txt

@@ -16,6 +16,7 @@ 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)
@@ -104,8 +105,28 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
   endif()
 endif()
 
+# silence excessive warnings for new Intel Compilers
+if(CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM")
+  set(CMAKE_TUNE_DEFAULT "-Wno-tautological-constant-compare -Wno-unused-command-line-argument")
+endif()
+
+# silence excessive warnings for PGI/NVHPC compilers
+if((CMAKE_CXX_COMPILER_ID STREQUAL "NVHPC") OR (CMAKE_CXX_COMPILER_ID STREQUAL "PGI"))
+  set(CMAKE_TUNE_DEFAULT "-Minform=severe")
+endif()
+
+# silence nvcc warnings
+if((PKG_KOKKOS) AND (Kokkos_ENABLE_CUDA) AND NOT (CMAKE_CXX_COMPILER_ID STREQUAL "Clang"))
+  set(CMAKE_TUNE_DEFAULT "${CMAKE_TUNE_DEFAULT} -Xcudafe --diag_suppress=unrecognized_pragma")
+endif()
+
 # we require C++11 without extensions. Kokkos requires at least C++14 (currently)
-set(CMAKE_CXX_STANDARD 11)
+if(NOT CMAKE_CXX_STANDARD)
+  set(CMAKE_CXX_STANDARD 11)
+endif()
+if(CMAKE_CXX_STANDARD LESS 11)
+  message(FATAL_ERROR "C++ standard must be set to at least 11")
+endif()
 if(PKG_KOKKOS AND (CMAKE_CXX_STANDARD LESS 14))
   set(CMAKE_CXX_STANDARD 14)
 endif()
@@ -114,9 +135,12 @@ set(CMAKE_CXX_EXTENSIONS OFF CACHE BOOL "Use compiler extensions")
 # ugly hacks for MSVC which by default always reports an old C++ standard in the __cplusplus macro
 # and prints lots of pointless warnings about "unsafe" functions
 if(MSVC)
-  add_compile_options(/Zc:__cplusplus)
-  add_compile_options(/wd4244)
-  add_compile_options(/wd4267)
+  if((CMAKE_CXX_COMPILER_ID STREQUAL "MSVC") OR (CMAKE_CXX_COMPILER_ID STREQUAL "Intel"))
+    add_compile_options(/Zc:__cplusplus)
+    add_compile_options(/wd4244)
+    add_compile_options(/wd4267)
+    add_compile_options(/EHsc)
+  endif()
   add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
 endif()
 
@@ -128,6 +152,19 @@ endif()
 ########################################################################
 # User input options                                                   #
 ########################################################################
+# set path to python interpreter and thus enforcing python version if
+# when in a virtual environment and PYTHON_EXECUTABLE is not set on command line
+if(DEFINED ENV{VIRTUAL_ENV} AND NOT PYTHON_EXECUTABLE)
+  if(CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows")
+    set(PYTHON_EXECUTABLE "$ENV{VIRTUAL_ENV}/Scripts/python.exe")
+  else()
+    set(PYTHON_EXECUTABLE "$ENV{VIRTUAL_ENV}/bin/python")
+  endif()
+  set(Python_EXECUTABLE "${PYTHON_EXECUTABLE}")
+  message(STATUS "Running in virtual environment: $ENV{VIRTUAL_ENV}\n"
+    "   Setting Python interpreter to: ${PYTHON_EXECUTABLE}")
+endif()
+
 set(LAMMPS_MACHINE "" CACHE STRING "Suffix to append to lmp binary (WON'T enable any features automatically")
 mark_as_advanced(LAMMPS_MACHINE)
 if(LAMMPS_MACHINE)
@@ -140,10 +177,12 @@ option(CMAKE_POSITION_INDEPENDENT_CODE "Create object compatible with shared lib
 option(BUILD_TOOLS "Build and install LAMMPS tools (msi2lmp, binary2txt, chain)" OFF)
 option(BUILD_LAMMPS_SHELL "Build and install the LAMMPS shell" OFF)
 
-# allow enabling clang-tidy for C++ files
+# Support using clang-tidy for C++ files with selected options
 set(ENABLE_CLANG_TIDY OFF CACHE BOOL "Include clang-tidy processing when compiling")
 if(ENABLE_CLANG_TIDY)
-  set(CMAKE_CXX_CLANG_TIDY "clang-tidy;-checks=*-header-filter=.*" CACHE STRING "")
+  set(CMAKE_CXX_CLANG_TIDY "clang-tidy;-checks=-*,performance-trivially-destructible,performance-unnecessary-copy-initialization,performance-unnecessary-value-param,readability-redundant-control-flow,readability-redundant-declaration,readability-redundant-function-ptr-dereference,readability-redundant-member-init,readability-redundant-string-cstr,readability-redundant-string-init,readability-simplify-boolean-expr,readability-static-accessed-through-instance,readability-static-definition-in-anonymous-namespace,modernize-use-override,modernize-use-bool-literals,modernize-use-emplace,modernize-return-braced-init-list,modernize-use-equals-default,modernize-use-equals-delete,modernize-replace-random-shuffle,modernize-deprecated-headers,modernize-use-nullptr,modernize-use-noexcept,modernize-redundant-void-arg;-fix;-header-filter=.*,header-filter=library.h,header-filter=fmt/*.h" CACHE STRING "clang-tidy settings")
+else()
+  unset(CMAKE_CXX_CLANG_TIDY CACHE)
 endif()
 
 include(GNUInstallDirs)
@@ -166,14 +205,16 @@ option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
 
 set(STANDARD_PACKAGES
   ADIOS
+  AMOEBA
   ASPHERE
   ATC
   AWPMD
   BOCS
   BODY
+  BPM
   BROWNIAN
   CG-DNA
-  CG-SDK
+  CG-SPICA
   CLASS2
   COLLOID
   COLVARS
@@ -187,6 +228,7 @@ set(STANDARD_PACKAGES
   DPD-SMOOTH
   DRUDE
   EFF
+  ELECTRODE
   EXTRA-COMPUTE
   EXTRA-DUMP
   EXTRA-FIX
@@ -207,7 +249,6 @@ set(STANDARD_PACKAGES
   MDI
   MEAM
   MESONT
-  MESSAGE
   MGPT
   MISC
   ML-HDNNP
@@ -306,7 +347,9 @@ string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)
 target_compile_definitions(lammps PUBLIC -DLAMMPS_${LAMMPS_SIZES})
 
 # posix_memalign is not available on Windows
-if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
+# with INTEL package and Intel compilers we use TBB's aligned malloc
+if((CMAKE_SYSTEM_NAME STREQUAL "Windows")
+   AND NOT (PKG_INTEL AND ((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") OR (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM"))))
   set(LAMMPS_MEMALIGN "0" CACHE STRING "posix_memalign() is not available on Windows" FORCE)
 else()
   set(LAMMPS_MEMALIGN "64" CACHE STRING "enables the use of the posix_memalign() call instead of malloc() when large chunks or memory are allocated by LAMMPS. Set to 0 to disable")
@@ -327,10 +370,13 @@ pkg_depends(MPIIO MPI)
 pkg_depends(ATC MANYBODY)
 pkg_depends(LATBOLTZ MPI)
 pkg_depends(SCAFACOS MPI)
+pkg_depends(AMOEBA KSPACE)
 pkg_depends(DIELECTRIC KSPACE)
 pkg_depends(DIELECTRIC EXTRA-PAIR)
 pkg_depends(CG-DNA MOLECULE)
 pkg_depends(CG-DNA ASPHERE)
+pkg_depends(ELECTRODE KSPACE)
+pkg_depends(EXTRA-MOLECULE MOLECULE)
 
 # detect if we may enable OpenMP support by default
 set(BUILD_OMP_DEFAULT OFF)
@@ -368,11 +414,13 @@ if(BUILD_OMP)
   target_link_libraries(lmp PRIVATE OpenMP::OpenMP_CXX)
 endif()
 
-if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_LATTE)
+if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_LATTE OR PKG_ELECTRODE)
   enable_language(C)
-  find_package(LAPACK)
-  find_package(BLAS)
-  if(NOT LAPACK_FOUND OR NOT BLAS_FOUND)
+  if (NOT USE_INTERNAL_LINALG)
+    find_package(LAPACK)
+    find_package(BLAS)
+  endif()
+  if(NOT LAPACK_FOUND OR NOT BLAS_FOUND OR USE_INTERNAL_LINALG)
     include(CheckGeneratorSupport)
     if(NOT CMAKE_GENERATOR_SUPPORT_FORTRAN)
       status(FATAL_ERROR "Cannot build internal linear algebra library as CMake build tool lacks Fortran support")
@@ -450,7 +498,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()
@@ -467,6 +515,7 @@ set(CMAKE_TUNE_FLAGS "${CMAKE_TUNE_DEFAULT}" CACHE STRING "Compiler and machine
 separate_arguments(CMAKE_TUNE_FLAGS)
 foreach(_FLAG ${CMAKE_TUNE_FLAGS})
   target_compile_options(lammps PRIVATE ${_FLAG})
+  target_compile_options(lmp PRIVATE ${_FLAG})
 endforeach()
 ########################################################################
 # Basic system tests (standard libraries, headers, functions, types)   #
@@ -571,6 +620,10 @@ foreach(PKG_LIB POEMS ATC AWPMD H5MD MESONT)
   endif()
 endforeach()
 
+if(PKG_ELECTRODE)
+  target_link_libraries(lammps PRIVATE ${LAPACK_LIBRARIES})
+endif()
+
 if(PKG_AWPMD)
   target_link_libraries(awpmd PRIVATE ${LAPACK_LIBRARIES})
 endif()
@@ -596,7 +649,7 @@ endif()
 # packages which selectively include variants based on enabled styles
 # e.g. accelerator packages
 ######################################################################
-foreach(PKG_WITH_INCL CORESHELL DPD-SMOOTH PHONON QEQ OPENMP KOKKOS OPT INTEL GPU)
+foreach(PKG_WITH_INCL CORESHELL DPD-SMOOTH MISC PHONON QEQ OPENMP KOKKOS OPT INTEL GPU)
   if(PKG_${PKG_WITH_INCL})
     include(Packages/${PKG_WITH_INCL})
   endif()
@@ -743,18 +796,26 @@ if(BUILD_SHARED_LIBS)
     set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
     find_package(PythonInterp) # Deprecated since version 3.12
     if(PYTHONINTERP_FOUND)
-        set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
+      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
     endif()
   else()
+    # backward compatibility
+    if(PYTHON_EXECUTABLE)
+      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
+    endif()
     find_package(Python COMPONENTS Interpreter)
   endif()
+  if(BUILD_IS_MULTI_CONFIG)
+    set(MY_BUILD_DIR ${CMAKE_BINARY_DIR}/$<CONFIG>)
+  else()
+    set(MY_BUILD_DIR ${CMAKE_BINARY_DIR})
+  endif()
+  set(LIBLAMMPS_SHARED_BINARY ${MY_BUILD_DIR}/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX})
   if(Python_EXECUTABLE)
     add_custom_target(
       install-python ${CMAKE_COMMAND} -E remove_directory build
-      COMMAND ${Python_EXECUTABLE} install.py -v ${LAMMPS_SOURCE_DIR}/version.h
-      -p ${LAMMPS_PYTHON_DIR}/lammps
-      -l ${CMAKE_BINARY_DIR}/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX}
-      WORKING_DIRECTORY  ${LAMMPS_PYTHON_DIR}
+      COMMAND ${Python_EXECUTABLE} ${LAMMPS_PYTHON_DIR}/install.py -p ${LAMMPS_PYTHON_DIR}/lammps
+              -l ${LIBLAMMPS_SHARED_BINARY} -w ${MY_BUILD_DIR}
       COMMENT "Installing LAMMPS Python module")
   else()
     add_custom_target(
@@ -774,11 +835,17 @@ endif()
 ###############################################################################
 if(BUILD_SHARED_LIBS OR PKG_PYTHON)
   if(CMAKE_VERSION VERSION_LESS 3.12)
+    # adjust so we find Python 3 versions before Python 2 on old systems with old CMake
+    set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
     find_package(PythonInterp) # Deprecated since version 3.12
     if(PYTHONINTERP_FOUND)
-        set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
+      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
     endif()
   else()
+    # backward compatibility
+    if(PYTHON_EXECUTABLE)
+      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
+    endif()
     find_package(Python COMPONENTS Interpreter)
   endif()
   if(Python_EXECUTABLE)
@@ -799,7 +866,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()
@@ -808,6 +874,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}
@@ -917,6 +984,12 @@ if(PKG_KSPACE)
       else()
         message(STATUS "Kokkos FFT: cuFFT")
       endif()
+    elseif(Kokkos_ENABLE_HIP)
+      if(FFT STREQUAL "KISS")
+        message(STATUS "Kokkos FFT: KISS")
+      else()
+        message(STATUS "Kokkos FFT: hipFFT")
+      endif()
     else()
       message(STATUS "Kokkos FFT: ${FFT}")
     endif()

cmake/CMakeLists.zlib

@@ -0,0 +1,195 @@
+cmake_minimum_required(VERSION 3.10)
+# When using CMake 3.4 and later, don't export symbols from executables unless
+# the CMAKE_ENABLE_EXPORTS variable is set.
+if(POLICY CMP0065)
+  cmake_policy(SET CMP0065 NEW)
+endif()
+if (POLICY CMP0077)
+  cmake_policy(SET CMP0077 NEW)
+endif()
+set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS ON)
+
+project(zlib C)
+
+set(VERSION "1.2.11")
+
+option(ASM686 "Enable building i686 assembly implementation" OFF)
+option(AMD64 "Enable building amd64 assembly implementation" OFF)
+
+set(INSTALL_BIN_DIR "${CMAKE_INSTALL_PREFIX}/bin" CACHE PATH "Installation directory for executables")
+set(INSTALL_LIB_DIR "${CMAKE_INSTALL_PREFIX}/lib" CACHE PATH "Installation directory for libraries")
+set(INSTALL_INC_DIR "${CMAKE_INSTALL_PREFIX}/include" CACHE PATH "Installation directory for headers")
+set(INSTALL_MAN_DIR "${CMAKE_INSTALL_PREFIX}/share/man" CACHE PATH "Installation directory for manual pages")
+set(INSTALL_PKGCONFIG_DIR "${CMAKE_INSTALL_PREFIX}/share/pkgconfig" CACHE PATH "Installation directory for pkgconfig (.pc) files")
+
+include(CheckTypeSize)
+include(CheckFunctionExists)
+include(CheckIncludeFile)
+include(CheckCSourceCompiles)
+
+check_include_file(sys/types.h HAVE_SYS_TYPES_H)
+check_include_file(stdint.h    HAVE_STDINT_H)
+check_include_file(stddef.h    HAVE_STDDEF_H)
+
+#
+# Check to see if we have large file support
+#
+set(CMAKE_REQUIRED_DEFINITIONS -D_LARGEFILE64_SOURCE=1)
+# We add these other definitions here because CheckTypeSize.cmake
+# in CMake 2.4.x does not automatically do so and we want
+# compatibility with CMake 2.4.x.
+if(HAVE_SYS_TYPES_H)
+    list(APPEND CMAKE_REQUIRED_DEFINITIONS -DHAVE_SYS_TYPES_H)
+endif()
+if(HAVE_STDINT_H)
+    list(APPEND CMAKE_REQUIRED_DEFINITIONS -DHAVE_STDINT_H)
+endif()
+if(HAVE_STDDEF_H)
+    list(APPEND CMAKE_REQUIRED_DEFINITIONS -DHAVE_STDDEF_H)
+endif()
+check_type_size(off64_t OFF64_T)
+check_type_size(off64_t OFF64_T)
+if(HAVE_OFF64_T)
+   add_definitions(-D_LARGEFILE64_SOURCE=1)
+endif()
+set(CMAKE_REQUIRED_DEFINITIONS) # clear variable
+
+#
+# Check for fseeko
+#
+check_function_exists(fseeko HAVE_FSEEKO)
+if(NOT HAVE_FSEEKO)
+    add_definitions(-DNO_FSEEKO)
+endif()
+
+#
+# Check for unistd.h
+#
+check_include_file(unistd.h Z_HAVE_UNISTD_H)
+
+if(MSVC)
+    set(CMAKE_DEBUG_POSTFIX "d")
+    add_definitions(-D_CRT_SECURE_NO_DEPRECATE)
+    add_definitions(-D_CRT_NONSTDC_NO_DEPRECATE)
+    include_directories(${CMAKE_CURRENT_SOURCE_DIR})
+endif()
+
+if(NOT CMAKE_CURRENT_SOURCE_DIR STREQUAL CMAKE_CURRENT_BINARY_DIR)
+    # If we're doing an out of source build and the user has a zconf.h
+    # in their source tree...
+    if(EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/zconf.h)
+        file(RENAME ${CMAKE_CURRENT_SOURCE_DIR}/zconf.h ${CMAKE_CURRENT_SOURCE_DIR}/zconf.h.included)
+  endif()
+endif()
+
+set(ZLIB_PC ${CMAKE_CURRENT_BINARY_DIR}/zlib.pc)
+configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/zlib.pc.cmakein
+		${ZLIB_PC} @ONLY)
+configure_file(	${CMAKE_CURRENT_SOURCE_DIR}/zconf.h.cmakein
+		${CMAKE_CURRENT_BINARY_DIR}/zconf.h @ONLY)
+include_directories(${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_SOURCE_DIR})
+
+
+#============================================================================
+# zlib
+#============================================================================
+
+set(ZLIB_PUBLIC_HDRS
+    ${CMAKE_CURRENT_BINARY_DIR}/zconf.h
+    zlib.h
+)
+set(ZLIB_PRIVATE_HDRS
+    crc32.h
+    deflate.h
+    gzguts.h
+    inffast.h
+    inffixed.h
+    inflate.h
+    inftrees.h
+    trees.h
+    zutil.h
+)
+set(ZLIB_SRCS
+    adler32.c
+    compress.c
+    crc32.c
+    deflate.c
+    gzclose.c
+    gzlib.c
+    gzread.c
+    gzwrite.c
+    inflate.c
+    infback.c
+    inftrees.c
+    inffast.c
+    trees.c
+    uncompr.c
+    zutil.c
+)
+
+if(NOT MINGW)
+    set(ZLIB_DLL_SRCS
+        win32/zlib1.rc # If present will override custom build rule below.
+    )
+endif()
+
+if(CMAKE_COMPILER_IS_GNUCC)
+    if(ASM686)
+        set(ZLIB_ASMS contrib/asm686/match.S)
+    elseif (AMD64)
+        set(ZLIB_ASMS contrib/amd64/amd64-match.S)
+    endif ()
+
+	if(ZLIB_ASMS)
+		add_definitions(-DASMV)
+		set_source_files_properties(${ZLIB_ASMS} PROPERTIES LANGUAGE C COMPILE_FLAGS -DNO_UNDERLINE)
+	endif()
+endif()
+
+if(MSVC)
+    if(ASM686)
+		ENABLE_LANGUAGE(ASM_MASM)
+        set(ZLIB_ASMS
+			contrib/masmx86/inffas32.asm
+			contrib/masmx86/match686.asm
+		)
+    elseif (AMD64)
+		ENABLE_LANGUAGE(ASM_MASM)
+        set(ZLIB_ASMS
+			contrib/masmx64/gvmat64.asm
+			contrib/masmx64/inffasx64.asm
+		)
+    endif()
+
+	if(ZLIB_ASMS)
+		add_definitions(-DASMV -DASMINF)
+	endif()
+endif()
+
+# parse the full version number from zlib.h and include in ZLIB_FULL_VERSION
+file(READ ${CMAKE_CURRENT_SOURCE_DIR}/zlib.h _zlib_h_contents)
+string(REGEX REPLACE ".*#define[ \t]+ZLIB_VERSION[ \t]+\"([-0-9A-Za-z.]+)\".*"
+    "\\1" ZLIB_FULL_VERSION ${_zlib_h_contents})
+
+if(MINGW)
+    # This gets us DLL resource information when compiling on MinGW.
+    if(NOT CMAKE_RC_COMPILER)
+        set(CMAKE_RC_COMPILER windres.exe)
+    endif()
+
+    add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj
+                       COMMAND ${CMAKE_RC_COMPILER}
+                            -D GCC_WINDRES
+                            -I ${CMAKE_CURRENT_SOURCE_DIR}
+                            -I ${CMAKE_CURRENT_BINARY_DIR}
+                            -o ${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj
+                            -i ${CMAKE_CURRENT_SOURCE_DIR}/win32/zlib1.rc)
+    set(ZLIB_DLL_SRCS ${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj)
+endif(MINGW)
+
+add_library(zlibstatic STATIC ${ZLIB_SRCS} ${ZLIB_ASMS} ${ZLIB_PUBLIC_HDRS} ${ZLIB_PRIVATE_HDRS})
+
+if(UNIX)
+    # On unix-like platforms the library is almost always called libz
+   set_target_properties(zlibstatic PROPERTIES OUTPUT_NAME z)
+endif()

cmake/CMakeSettings.json

@@ -8,7 +8,7 @@
       "installRoot": "${workspaceRoot}\\install\\${name}",
       "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
       "buildCommandArgs": "",
-      "ctestCommandArgs": "",
+      "ctestCommandArgs": "-V",
       "inheritEnvironments": [ "msvc_x64_x64" ],
       "variables": [
         {
@@ -26,11 +26,6 @@
           "value": "True",
           "type": "BOOL"
         },
-        {
-          "name": "PKG_PYTHON",
-          "value": "True",
-          "type": "BOOL"
-        },
         {
           "name": "ENABLE_TESTING",
           "value": "True",
@@ -46,7 +41,7 @@
       "installRoot": "${workspaceRoot}\\install\\${name}",
       "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
       "buildCommandArgs": "",
-      "ctestCommandArgs": "",
+      "ctestCommandArgs": "-V",
       "inheritEnvironments": [ "msvc_x64_x64" ],
       "variables": [
         {
@@ -64,11 +59,6 @@
           "value": "True",
           "type": "BOOL"
         },
-        {
-          "name": "PKG_PYTHON",
-          "value": "True",
-          "type": "BOOL"
-        },
         {
           "name": "ENABLE_TESTING",
           "value": "True",
@@ -82,7 +72,7 @@
       "configurationType": "Debug",
       "buildRoot": "${workspaceRoot}\\build\\${name}",
       "installRoot": "${workspaceRoot}\\install\\${name}",
-      "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
+      "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" ],
@@ -102,11 +92,6 @@
           "value": "True",
           "type": "BOOL"
         },
-        {
-          "name": "PKG_PYTHON",
-          "value": "True",
-          "type": "BOOL"
-        },
         {
           "name": "ENABLE_TESTING",
           "value": "True",
@@ -115,15 +100,15 @@
       ]
     },
     {
-      "name": "x64-Debug-OneAPI",
+      "name": "x64-Release-Clang",
       "generator": "Ninja",
-      "configurationType": "Debug",
+      "configurationType": "Release",
       "buildRoot": "${workspaceRoot}\\build\\${name}",
       "installRoot": "${workspaceRoot}\\install\\${name}",
-      "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DCMAKE_CXX_COMPILER=icx -DCMAKE_C_COMPILER=icx",
+      "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" ],
+      "ctestCommandArgs": "-V",
+      "inheritEnvironments": [ "clang_cl_x64" ],
       "variables": [
         {
           "name": "BUILD_SHARED_LIBS",
@@ -140,34 +125,29 @@
           "value": "True",
           "type": "BOOL"
         },
-        {
-          "name": "PKG_PYTHON",
-          "value": "True",
-          "type": "BOOL"
-        },
         {
           "name": "ENABLE_TESTING",
           "value": "True",
           "type": "BOOL"
-        },
-        {
-          "name": "BUILD_MPI",
-          "value": "False",
-          "type": "BOOL"
         }
       ]
     },
     {
-      "name": "x64-Debug-Intel",
+      "name": "x64-Debug-IntelLLVM",
       "generator": "Ninja",
       "configurationType": "Debug",
       "buildRoot": "${workspaceRoot}\\build\\${name}",
       "installRoot": "${workspaceRoot}\\install\\${name}",
-      "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DCMAKE_CXX_COMPILER=icl -DCMAKE_C_COMPILER=icl -DCMAKE_Fortran_COMPILER=ifort",
       "buildCommandArgs": "",
-      "ctestCommandArgs": "",
-      "inheritEnvironments": [ "msvc_x64_x64" ],
+      "ctestCommandArgs": "-V",
+      "inheritEnvironments": [],
+      "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows-intel-llvm.cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
       "variables": [
+        {
+          "name": "PKG_ELECTRODE",
+          "value": "True",
+          "type": "BOOL"
+        },
         {
           "name": "BUILD_SHARED_LIBS",
           "value": "True",
@@ -184,7 +164,88 @@
           "type": "BOOL"
         },
         {
-          "name": "PKG_PYTHON",
+          "name": "ENABLE_TESTING",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "FFT",
+          "value": "MKL",
+          "type": "STRING"
+        }
+      ]
+    },
+    {
+      "name": "x64-Release-IntelLLVM",
+      "generator": "Ninja",
+      "configurationType": "Release",
+      "buildRoot": "${workspaceRoot}\\build\\${name}",
+      "installRoot": "${workspaceRoot}\\install\\${name}",
+      "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows-intel-llvm.cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
+      "buildCommandArgs": "",
+      "ctestCommandArgs": "-V",
+      "inheritEnvironments": [],
+      "variables": [
+        {
+          "name": "PKG_ELECTRODE",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "BUILD_SHARED_LIBS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "BUILD_TOOLS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "LAMMPS_EXCEPTIONS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "ENABLE_TESTING",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "FFT",
+          "value": "MKL",
+          "type": "STRING"
+        }
+      ]
+    },
+    {
+      "name": "x64-Debug-Intel-Classic",
+      "generator": "Ninja",
+      "configurationType": "Debug",
+      "buildRoot": "${workspaceRoot}\\build\\${name}",
+      "installRoot": "${workspaceRoot}\\install\\${name}",
+      "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows-intel-classic.cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
+      "buildCommandArgs": "",
+      "ctestCommandArgs": "-V",
+      "inheritEnvironments": [],
+      "variables": [
+        {
+          "name": "PKG_ELECTRODE",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "BUILD_SHARED_LIBS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "BUILD_TOOLS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "LAMMPS_EXCEPTIONS",
           "value": "True",
           "type": "BOOL"
         },
@@ -194,9 +255,52 @@
           "type": "BOOL"
         },
         {
-          "name": "BUILD_MPI",
+          "name": "FFT",
+          "value": "MKL",
+          "type": "STRING"
+        }
+      ]
+    },
+    {
+      "name": "x64-Release-Intel-Classic",
+      "generator": "Ninja",
+      "configurationType": "Release",
+      "buildRoot": "${workspaceRoot}\\build\\${name}",
+      "installRoot": "${workspaceRoot}\\install\\${name}",
+      "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows-intel-classic.cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
+      "buildCommandArgs": "",
+      "ctestCommandArgs": "-V",
+      "inheritEnvironments": [],
+      "variables": [
+        {
+          "name": "PKG_ELECTRODE",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "BUILD_SHARED_LIBS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "BUILD_TOOLS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "LAMMPS_EXCEPTIONS",
+          "value": "True",
+          "type": "BOOL"
+        },
+        {
+          "name": "ENABLE_TESTING",
           "value": "False",
           "type": "BOOL"
+        },
+        {
+          "name": "FFT",
+          "value": "MKL",
+          "type": "STRING"
         }
       ]
     }

cmake/Modules/Documentation.cmake

@@ -7,13 +7,13 @@ if(BUILD_DOC)
   # Sphinx 3.x requires at least Python 3.5
   if(CMAKE_VERSION VERSION_LESS 3.12)
     find_package(PythonInterp 3.5 REQUIRED)
-    set(VIRTUALENV ${PYTHON_EXECUTABLE} -m virtualenv -p ${PYTHON_EXECUTABLE})
+    set(VIRTUALENV ${PYTHON_EXECUTABLE} -m venv)
   else()
     find_package(Python3 REQUIRED COMPONENTS Interpreter)
     if(Python3_VERSION VERSION_LESS 3.5)
       message(FATAL_ERROR "Python 3.5 and up is required to build the HTML documentation")
     endif()
-    set(VIRTUALENV ${Python3_EXECUTABLE} -m virtualenv -p ${Python3_EXECUTABLE})
+    set(VIRTUALENV ${Python3_EXECUTABLE} -m venv)
   endif()
   find_package(Doxygen 1.8.10 REQUIRED)
 

cmake/Modules/LAMMPSInterfacePlugin.cmake

@@ -0,0 +1,208 @@
+# CMake script code to define LAMMPS settings required for building LAMMPS plugins
+
+# enforce out-of-source build
+if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_BINARY_DIR})
+  message(FATAL_ERROR "In-source builds are not allowed. You must create and use a build directory. "
+    "Please remove CMakeCache.txt and CMakeFiles first.")
+endif()
+
+set(LAMMPS_THIRDPARTY_URL "https://download.lammps.org/thirdparty"
+  CACHE STRING "URL for thirdparty package downloads")
+
+# global LAMMPS/plugin build settings
+set(LAMMPS_SOURCE_DIR ""  CACHE PATH "Location of LAMMPS sources folder")
+if(NOT LAMMPS_SOURCE_DIR)
+  message(FATAL_ERROR "Must set LAMMPS_SOURCE_DIR")
+endif()
+
+# by default, install into $HOME/.local (not /usr/local),
+# so that no root access (and sudo) is needed
+if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
+  set(CMAKE_INSTALL_PREFIX "$ENV{HOME}/.local" CACHE PATH "Default install path" FORCE)
+endif()
+
+# ugly hacks for MSVC which by default always reports an old C++ standard in the __cplusplus macro
+# and prints lots of pointless warnings about "unsafe" functions
+if(MSVC)
+  if(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
+    add_compile_options(/Zc:__cplusplus)
+    add_compile_options(/wd4244)
+    add_compile_options(/wd4267)
+    if(LAMMPS_EXCEPTIONS)
+      add_compile_options(/EHsc)
+    endif()
+  endif()
+  add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
+endif()
+
+# C++11 is required
+set(CMAKE_CXX_STANDARD 11)
+set(CMAKE_CXX_STANDARD_REQUIRED ON)
+
+# Need -restrict with Intel compilers
+if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
+endif()
+set(CMAKE_POSITION_INDEPENDENT_CODE TRUE)
+
+#######
+# helper functions from LAMMPSUtils.cmake
+function(validate_option name values)
+  string(TOLOWER ${${name}} needle_lower)
+  string(TOUPPER ${${name}} needle_upper)
+  list(FIND ${values} ${needle_lower} IDX_LOWER)
+  list(FIND ${values} ${needle_upper} IDX_UPPER)
+  if(${IDX_LOWER} LESS 0 AND ${IDX_UPPER} LESS 0)
+    list_to_bulletpoints(POSSIBLE_VALUE_LIST ${${values}})
+    message(FATAL_ERROR "\n########################################################################\n"
+      "Invalid value '${${name}}' for option ${name}\n"
+      "\n"
+      "Possible values are:\n"
+      "${POSSIBLE_VALUE_LIST}"
+      "########################################################################")
+  endif()
+endfunction(validate_option)
+
+# helper function for getting the most recently modified file or folder from a glob pattern
+function(get_newest_file path variable)
+  file(GLOB _dirs ${path})
+  set(_besttime 2000-01-01T00:00:00)
+  set(_bestfile "<unknown>")
+  foreach(_dir ${_dirs})
+    file(TIMESTAMP ${_dir} _newtime)
+    if(_newtime IS_NEWER_THAN _besttime)
+      set(_bestfile ${_dir})
+      set(_besttime ${_newtime})
+    endif()
+  endforeach()
+  if(_bestfile STREQUAL "<unknown>")
+    message(FATAL_ERROR "Could not find valid path at: ${path}")
+  endif()
+  set(${variable} ${_bestfile} PARENT_SCOPE)
+endfunction()
+
+# get LAMMPS version date
+function(get_lammps_version version_header variable)
+    file(STRINGS ${version_header} line REGEX LAMMPS_VERSION)
+    string(REGEX REPLACE "#define LAMMPS_VERSION \"([0-9]+) ([A-Za-z]+) ([0-9]+)\"" "\\1\\2\\3" date "${line}")
+    set(${variable} "${date}" PARENT_SCOPE)
+endfunction()
+
+#################################################################################
+# LAMMPS C++ interface. We only need the header related parts except on windows.
+add_library(lammps INTERFACE)
+target_include_directories(lammps INTERFACE ${LAMMPS_SOURCE_DIR})
+if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
+  target_link_libraries(lammps INTERFACE ${CMAKE_BINARY_DIR}/../liblammps.dll.a)
+endif()
+
+################################################################################
+# MPI configuration
+if(NOT CMAKE_CROSSCOMPILING)
+  set(MPI_CXX_SKIP_MPICXX TRUE)
+  find_package(MPI QUIET)
+  option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
+else()
+  option(BUILD_MPI "Build MPI version" OFF)
+endif()
+
+if(BUILD_MPI)
+  # do not include the (obsolete) MPI C++ bindings which makes
+  # for leaner object files and avoids namespace conflicts
+  set(MPI_CXX_SKIP_MPICXX TRUE)
+  # We use a non-standard procedure to cross-compile with MPI on Windows
+  if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
+    # Download and configure custom MPICH files for Windows
+    message(STATUS "Downloading and configuring MPICH-1.4.1 for Windows")
+    set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win64-devel.tar.gz" CACHE STRING "URL for MPICH2 (win64) tarball")
+    set(MPICH2_WIN32_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win32-devel.tar.gz" CACHE STRING "URL for MPICH2 (win32) tarball")
+    set(MPICH2_WIN64_DEVEL_MD5 "4939fdb59d13182fd5dd65211e469f14" CACHE STRING "MD5 checksum of MPICH2 (win64) tarball")
+    set(MPICH2_WIN32_DEVEL_MD5 "a61d153500dce44e21b755ee7257e031" CACHE STRING "MD5 checksum of MPICH2 (win32) tarball")
+    mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
+    mark_as_advanced(MPICH2_WIN32_DEVEL_URL)
+    mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
+    mark_as_advanced(MPICH2_WIN32_DEVEL_MD5)
+
+    include(ExternalProject)
+    if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
+      ExternalProject_Add(mpi4win_build
+        URL     ${MPICH2_WIN64_DEVEL_URL}
+        URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
+        CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
+        BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
+    else()
+      ExternalProject_Add(mpi4win_build
+        URL     ${MPICH2_WIN32_DEVEL_URL}
+        URL_MD5 ${MPICH2_WIN32_DEVEL_MD5}
+        CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
+        BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
+    endif()
+
+    ExternalProject_get_property(mpi4win_build SOURCE_DIR)
+    file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
+    add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
+    set_target_properties(MPI::MPI_CXX PROPERTIES
+      IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmpi.a"
+      INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
+      INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
+    add_dependencies(MPI::MPI_CXX mpi4win_build)
+
+    # set variables for status reporting at the end of CMake run
+    set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
+    set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
+    set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmpi.a")
+  else()
+    find_package(MPI REQUIRED)
+    option(LAMMPS_LONGLONG_TO_LONG "Workaround if your system or MPI version does not recognize 'long long' data types" OFF)
+    if(LAMMPS_LONGLONG_TO_LONG)
+      target_compile_definitions(lammps INTERFACE -DLAMMPS_LONGLONG_TO_LONG)
+    endif()
+  endif()
+  target_link_libraries(lammps INTERFACE MPI::MPI_CXX)
+else()
+  add_library(mpi_stubs INTERFACE)
+  target_include_directories(mpi_stubs INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
+  target_link_libraries(lammps INTERFACE mpi_stubs)
+endif()
+
+################################################################################
+# detect if we may enable OpenMP support by default
+set(BUILD_OMP_DEFAULT OFF)
+find_package(OpenMP QUIET)
+if(OpenMP_FOUND)
+  check_include_file_cxx(omp.h HAVE_OMP_H_INCLUDE)
+  if(HAVE_OMP_H_INCLUDE)
+    set(BUILD_OMP_DEFAULT ON)
+  endif()
+endif()
+
+option(BUILD_OMP "Build with OpenMP support" ${BUILD_OMP_DEFAULT})
+
+if(BUILD_OMP)
+  find_package(OpenMP REQUIRED)
+  check_include_file_cxx(omp.h HAVE_OMP_H_INCLUDE)
+  if(NOT HAVE_OMP_H_INCLUDE)
+    message(FATAL_ERROR "Cannot find the 'omp.h' header file required for full OpenMP support")
+  endif()
+
+  if (((CMAKE_CXX_COMPILER_ID STREQUAL "GNU") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 9.0)) OR
+      (CMAKE_CXX_COMPILER_ID STREQUAL "PGI") OR
+      ((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 10.0)) OR
+      ((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.0)))
+    # GCC 9.x and later plus Clang 10.x and later implement strict OpenMP 4.0 semantics for consts.
+    # Intel 18.0 was tested to support both, so we switch to OpenMP 4+ from 19.x onward to be safe.
+    target_compile_definitions(lammps INTERFACE -DLAMMPS_OMP_COMPAT=4)
+  else()
+    target_compile_definitions(lammps INTERFACE -DLAMMPS_OMP_COMPAT=3)
+  endif()
+  target_link_libraries(lammps INTERFACE OpenMP::OpenMP_CXX)
+endif()
+
+################
+# integer size selection
+set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallsmall: all 32-bit, smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
+set(LAMMPS_SIZES_VALUES smallbig bigbig smallsmall)
+set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
+validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
+string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)
+target_compile_definitions(lammps INTERFACE -DLAMMPS_${LAMMPS_SIZES})

cmake/Modules/LAMMPSUtils.cmake

@@ -24,6 +24,24 @@ function(validate_option name values)
     endif()
 endfunction(validate_option)
 
+# helper function for getting the most recently modified file or folder from a glob pattern
+function(get_newest_file path variable)
+  file(GLOB _dirs ${path})
+  set(_besttime 2000-01-01T00:00:00)
+  set(_bestfile "<unknown>")
+  foreach(_dir ${_dirs})
+    file(TIMESTAMP ${_dir} _newtime)
+    if(_newtime IS_NEWER_THAN _besttime)
+      set(_bestfile ${_dir})
+      set(_besttime ${_newtime})
+    endif()
+  endforeach()
+  if(_bestfile STREQUAL "<unknown>")
+    message(FATAL_ERROR "Could not find valid path at: ${path}")
+  endif()
+  set(${variable} ${_bestfile} PARENT_SCOPE)
+endfunction()
+
 function(get_lammps_version version_header variable)
     file(STRINGS ${version_header} line REGEX LAMMPS_VERSION)
     set(MONTHS x Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec)
@@ -92,14 +110,16 @@ function(FetchPotentials pkgfolder potfolder)
       math(EXPR plusone "${blank}+1")
       string(SUBSTRING ${line} 0 ${blank} pot)
       string(SUBSTRING ${line} ${plusone} -1 sum)
-      if(EXISTS ${LAMMPS_POTENTIALS_DIR}/${pot})
+      if(EXISTS "${LAMMPS_POTENTIALS_DIR}/${pot}")
         file(MD5 "${LAMMPS_POTENTIALS_DIR}/${pot}" oldsum)
       endif()
       if(NOT sum STREQUAL oldsum)
-        message(STATUS "Checking external potential ${pot} from ${LAMMPS_POTENTIALS_URL}")
-        file(DOWNLOAD "${LAMMPS_POTENTIALS_URL}/${pot}.${sum}" "${CMAKE_BINARY_DIR}/${pot}"
+        message(STATUS "Downloading external potential ${pot} from ${LAMMPS_POTENTIALS_URL}")
+        string(MD5 TMP_EXT "${CMAKE_BINARY_DIR}")
+        file(DOWNLOAD "${LAMMPS_POTENTIALS_URL}/${pot}.${sum}" "${CMAKE_BINARY_DIR}/${pot}.${TMP_EXT}"
           EXPECTED_HASH MD5=${sum} SHOW_PROGRESS)
-        file(COPY "${CMAKE_BINARY_DIR}/${pot}" DESTINATION ${LAMMPS_POTENTIALS_DIR})
+        file(COPY "${CMAKE_BINARY_DIR}/${pot}.${TMP_EXT}" DESTINATION "${LAMMPS_POTENTIALS_DIR}")
+        file(RENAME "${LAMMPS_POTENTIALS_DIR}/${pot}.${TMP_EXT}" "${LAMMPS_POTENTIALS_DIR}/${pot}")
       endif()
     endforeach()
   endif()

cmake/Modules/Packages/COLVARS.cmake

@@ -19,6 +19,10 @@ endif()
 
 add_library(colvars STATIC ${COLVARS_SOURCES})
 target_compile_definitions(colvars PRIVATE -DCOLVARS_LAMMPS)
+separate_arguments(CMAKE_TUNE_FLAGS)
+foreach(_FLAG ${CMAKE_TUNE_FLAGS})
+  target_compile_options(colvars PRIVATE ${_FLAG})
+endforeach()
 set_target_properties(colvars PROPERTIES OUTPUT_NAME lammps_colvars${LAMMPS_MACHINE})
 target_include_directories(colvars PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/colvars)
 # The line below is needed to locate math_eigen_impl.h

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.")
@@ -72,14 +80,14 @@ if(GPU_API STREQUAL "CUDA")
   # --arch translates directly instead of JIT, so this should be for the preferred or most common architecture
   set(GPU_CUDA_GENCODE "-arch=${GPU_ARCH}")
 
-  # apply the following to build "fat" CUDA binaries only for known CUDA toolkits
-  if(CUDA_VERSION VERSION_GREATER_EQUAL "12.0")
-    message(WARNING "Untested CUDA Toolkit version. Use at your own risk")
+  # apply the following to build "fat" CUDA binaries only for known CUDA toolkits since version 8.0
+  # only the Kepler achitecture and beyond is supported
+  if(CUDA_VERSION VERSION_LESS 8.0)
+    message(FATAL_ERROR "CUDA Toolkit version 8.0 or later is required")
+  elseif(CUDA_VERSION VERSION_GREATER_EQUAL "12.0")
+    message(WARNING "Untested CUDA Toolkit version ${CUDA_VERSION}. Use at your own risk")
+    set(GPU_CUDA_GENCODE "-arch=all")
   else()
-    # Fermi (GPU Arch 2.x) is supported by CUDA 3.2 to CUDA 8.0
-    if((CUDA_VERSION VERSION_GREATER_EQUAL "3.2") AND (CUDA_VERSION VERSION_LESS "9.0"))
-      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_20,code=[sm_20,compute_20] ")
-    endif()
     # Kepler (GPU Arch 3.0) is supported by CUDA 5 to CUDA 10.2
     if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "11.0"))
       string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_30,code=[sm_30,compute_30] ")
@@ -112,6 +120,14 @@ if(GPU_API STREQUAL "CUDA")
     if(CUDA_VERSION VERSION_GREATER_EQUAL "11.1")
       string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_86,code=[sm_86,compute_86]")
     endif()
+    # Hopper (GPU Arch 9.0) is supported by CUDA 12.0? and later
+    if(CUDA_VERSION VERSION_GREATER_EQUAL "12.0")
+      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_90,code=[sm_90,compute_90]")
+    endif()
+    #    # Lovelace (GPU Arch 9.x) is supported by CUDA 12.0? and later
+    #if(CUDA_VERSION VERSION_GREATER_EQUAL "12.0")
+    #  string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_9x,code=[sm_9x,compute_9x]")
+    #endif()
   endif()
 
   cuda_compile_fatbin(GPU_GEN_OBJS ${GPU_LIB_CU} OPTIONS ${CUDA_REQUEST_PIC}
@@ -217,7 +233,8 @@ elseif(GPU_API STREQUAL "OPENCL")
 elseif(GPU_API STREQUAL "HIP")
   if(NOT DEFINED HIP_PATH)
       if(NOT DEFINED ENV{HIP_PATH})
-          set(HIP_PATH "/opt/rocm/hip" CACHE PATH "Path to HIP installation")
+          message(FATAL_ERROR "GPU_API=HIP requires HIP_PATH to be defined.\n"
+          "Either pass the HIP_PATH as a CMake option via -DHIP_PATH=... or set the HIP_PATH environment variable.")
       else()
           set(HIP_PATH $ENV{HIP_PATH} CACHE PATH "Path to HIP installation")
       endif()
@@ -245,47 +262,53 @@ elseif(GPU_API STREQUAL "HIP")
 
   if(HIP_PLATFORM STREQUAL "hcc" OR HIP_PLATFORM STREQUAL "amd")
     set(HIP_ARCH "gfx906" CACHE STRING "HIP target architecture")
+  elseif(HIP_PLATFORM STREQUAL "spirv")
+    set(HIP_ARCH "spirv" CACHE STRING "HIP target architecture")
   elseif(HIP_PLATFORM STREQUAL "nvcc")
     find_package(CUDA REQUIRED)
     set(HIP_ARCH "sm_50" CACHE STRING "HIP primary CUDA architecture (e.g. sm_60)")
 
-    # build arch/gencode commands for nvcc based on CUDA toolkit version and use choice
-    # --arch translates directly instead of JIT, so this should be for the preferred or most common architecture
-    set(HIP_CUDA_GENCODE "-arch=${HIP_ARCH}")
-    # Fermi (GPU Arch 2.x) is supported by CUDA 3.2 to CUDA 8.0
-    if((CUDA_VERSION VERSION_GREATER_EQUAL "3.2") AND (CUDA_VERSION VERSION_LESS "9.0"))
-      string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_20,code=[sm_20,compute_20]")
-    endif()
-    # Kepler (GPU Arch 3.0) is supported by CUDA 5 to CUDA 10.2
-    if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "11.0"))
-      string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_30,code=[sm_30,compute_30]")
-    endif()
-    # Kepler (GPU Arch 3.5) is supported by CUDA 5 to CUDA 11.0
-    if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "12.0"))
-      string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_35,code=[sm_35,compute_35]")
-    endif()
-    # Maxwell (GPU Arch 5.x) is supported by CUDA 6 and later
-    if(CUDA_VERSION VERSION_GREATER_EQUAL "6.0")
-      string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_50,code=[sm_50,compute_50] -gencode arch=compute_52,code=[sm_52,compute_52]")
-    endif()
-    # Pascal (GPU Arch 6.x) is supported by CUDA 8 and later
-    if(CUDA_VERSION VERSION_GREATER_EQUAL "8.0")
-      string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_60,code=[sm_60,compute_60] -gencode arch=compute_61,code=[sm_61,compute_61]")
-    endif()
-    # Volta (GPU Arch 7.0) is supported by CUDA 9 and later
-    if(CUDA_VERSION VERSION_GREATER_EQUAL "9.0")
-      string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_70,code=[sm_70,compute_70]")
-    endif()
-    # Turing (GPU Arch 7.5) is supported by CUDA 10 and later
-    if(CUDA_VERSION VERSION_GREATER_EQUAL "10.0")
-      string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_75,code=[sm_75,compute_75]")
-    endif()
-    # Ampere (GPU Arch 8.0) is supported by CUDA 11 and later
-    if(CUDA_VERSION VERSION_GREATER_EQUAL "11.0")
-      string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_80,code=[sm_80,compute_80]")
-    endif()
-    if(CUDA_VERSION VERSION_GREATER_EQUAL "12.0")
-      message(WARNING "Unsupported CUDA version. Use at your own risk.")
+    if(CUDA_VERSION VERSION_LESS 8.0)
+      message(FATAL_ERROR "CUDA Toolkit version 8.0 or later is required")
+    elseif(CUDA_VERSION VERSION_GREATER_EQUAL "12.0")
+      message(WARNING "Untested CUDA Toolkit version ${CUDA_VERSION}. Use at your own risk")
+      set(HIP_CUDA_GENCODE "-arch=all")
+    else()
+      # build arch/gencode commands for nvcc based on CUDA toolkit version and use choice
+      # --arch translates directly instead of JIT, so this should be for the preferred or most common architecture
+      set(HIP_CUDA_GENCODE "-arch=${HIP_ARCH}")
+      # Kepler (GPU Arch 3.0) is supported by CUDA 5 to CUDA 10.2
+      if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "11.0"))
+        string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_30,code=[sm_30,compute_30]")
+      endif()
+      # Kepler (GPU Arch 3.5) is supported by CUDA 5 to CUDA 11.0
+      if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "12.0"))
+        string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_35,code=[sm_35,compute_35]")
+      endif()
+      # Maxwell (GPU Arch 5.x) is supported by CUDA 6 and later
+      if(CUDA_VERSION VERSION_GREATER_EQUAL "6.0")
+        string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_50,code=[sm_50,compute_50] -gencode arch=compute_52,code=[sm_52,compute_52]")
+      endif()
+      # Pascal (GPU Arch 6.x) is supported by CUDA 8 and later
+      if(CUDA_VERSION VERSION_GREATER_EQUAL "8.0")
+        string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_60,code=[sm_60,compute_60] -gencode arch=compute_61,code=[sm_61,compute_61]")
+      endif()
+      # Volta (GPU Arch 7.0) is supported by CUDA 9 and later
+      if(CUDA_VERSION VERSION_GREATER_EQUAL "9.0")
+        string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_70,code=[sm_70,compute_70]")
+      endif()
+      # Turing (GPU Arch 7.5) is supported by CUDA 10 and later
+      if(CUDA_VERSION VERSION_GREATER_EQUAL "10.0")
+        string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_75,code=[sm_75,compute_75]")
+      endif()
+      # Ampere (GPU Arch 8.0) is supported by CUDA 11 and later
+      if(CUDA_VERSION VERSION_GREATER_EQUAL "11.0")
+        string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_80,code=[sm_80,compute_80]")
+      endif()
+      # Hopper (GPU Arch 9.0) is supported by CUDA 12.0? and later
+      if(CUDA_VERSION VERSION_GREATER_EQUAL "12.0")
+        string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_90,code=[sm_90,compute_90]")
+      endif()
     endif()
   endif()
 
@@ -320,7 +343,14 @@ elseif(GPU_API STREQUAL "HIP")
           VERBATIM COMMAND ${HIP_HIPCC_EXECUTABLE} --fatbin --use_fast_math -DUSE_HIP -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES} ${HIP_CUDA_GENCODE} -I${LAMMPS_LIB_SOURCE_DIR}/gpu -o ${CUBIN_FILE} ${CU_FILE}
           DEPENDS ${CU_FILE}
           COMMENT "Generating ${CU_NAME}.cubin")
-    endif()
+    elseif(HIP_PLATFORM STREQUAL "spirv")
+      configure_file(${CU_FILE} ${CU_CPP_FILE} COPYONLY)
+
+      add_custom_command(OUTPUT ${CUBIN_FILE}
+        VERBATIM COMMAND ${HIP_HIPCC_EXECUTABLE} -c -O3 -DUSE_HIP -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES} -I${LAMMPS_LIB_SOURCE_DIR}/gpu -o ${CUBIN_FILE} ${CU_CPP_FILE}
+        DEPENDS ${CU_CPP_FILE}
+        COMMENT "Gerating ${CU_NAME}.cubin")
+      endif()
 
     add_custom_command(OUTPUT ${CUBIN_H_FILE}
       COMMAND ${CMAKE_COMMAND} -D SOURCE_DIR=${CMAKE_CURRENT_SOURCE_DIR} -D VARNAME=${CU_NAME} -D HEADER_FILE=${CUBIN_H_FILE} -D SOURCE_FILE=${CUBIN_FILE} -P ${CMAKE_CURRENT_SOURCE_DIR}/Modules/GenerateBinaryHeader.cmake
@@ -339,6 +369,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)

cmake/Modules/Packages/H5MD.cmake

@@ -1,5 +1,14 @@
 enable_language(C)
 
+# we don't use the parallel i/o interface.
+set(HDF5_PREFER_PARALLEL FALSE)
+
 find_package(HDF5 REQUIRED)
+
+# parallel HDF5 will import incompatible MPI headers with a serial build
+if((NOT BUILD_MPI) AND HDF5_IS_PARALLEL)
+  message(FATAL_ERROR "Serial LAMMPS build and parallel HDF5 library are not compatible")
+endif()
+
 target_link_libraries(h5md PRIVATE ${HDF5_LIBRARIES})
 target_include_directories(h5md PUBLIC ${HDF5_INCLUDE_DIRS})

cmake/Modules/Packages/INTEL.cmake

@@ -38,7 +38,7 @@ if(INTEL_LRT_MODE STREQUAL "C++11")
   endif()
 endif()
 
-if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
+if((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") OR (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM"))
   if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS 16)
     message(FATAL_ERROR "INTEL needs at least a 2016 Intel compiler, found ${CMAKE_CXX_COMPILER_VERSION}")
   endif()
@@ -46,12 +46,12 @@ else()
   message(WARNING "INTEL gives best performance with Intel compilers")
 endif()
 
-find_package(TBB_MALLOC QUIET)
+find_package(TBB_MALLOC)
 if(TBB_MALLOC_FOUND)
   target_link_libraries(lammps PRIVATE TBB::TBB_MALLOC)
 else()
   target_compile_definitions(lammps PRIVATE -DLMP_INTEL_NO_TBB)
-  if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
+  if((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") OR (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM"))
     message(WARNING "INTEL with Intel compilers should use TBB malloc libraries")
   endif()
 endif()
@@ -112,5 +112,9 @@ if(PKG_KSPACE)
   RegisterIntegrateStyle(${INTEL_SOURCES_DIR}/verlet_lrt_intel.h)
 endif()
 
+if(PKG_ELECTRODE)
+  list(APPEND INTEL_SOURCES ${INTEL_SOURCES_DIR}/electrode_accel_intel.cpp)
+endif()
+
 target_sources(lammps PRIVATE ${INTEL_SOURCES})
 target_include_directories(lammps PRIVATE ${INTEL_SOURCES_DIR})

cmake/Modules/Packages/KOKKOS.cmake

@@ -47,8 +47,8 @@ if(DOWNLOAD_KOKKOS)
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
   include(ExternalProject)
-  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.5.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "079323d973ae0e1c38c0a54a150c674e" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.6.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_MD5 "0ec97fc0c356dd65bd2487defe81a7bf" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   ExternalProject_Add(kokkos_build
@@ -72,7 +72,7 @@ if(DOWNLOAD_KOKKOS)
   add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
   add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 3.5.00 REQUIRED CONFIG)
+  find_package(Kokkos 3.6.01 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
   target_link_libraries(lmp PRIVATE Kokkos::kokkos)
 else()
@@ -130,6 +130,11 @@ if(PKG_KSPACE)
       target_compile_definitions(lammps PRIVATE -DFFT_CUFFT)
       target_link_libraries(lammps PRIVATE cufft)
     endif()
+  elseif(Kokkos_ENABLE_HIP)
+    if(NOT (FFT STREQUAL "KISS"))
+      target_compile_definitions(lammps PRIVATE -DFFT_HIPFFT)
+      target_link_libraries(lammps PRIVATE hipfft)
+    endif()
   endif()
 endif()
 

cmake/Modules/Packages/LATTE.cmake

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

cmake/Modules/Packages/MACHDYN.cmake

@@ -36,3 +36,5 @@ endif()
 if((CMAKE_CXX_COMPILER_ID STREQUAL "PGI") OR (CMAKE_CXX_COMPILER_ID STREQUAL "NVHPC"))
   target_compile_definitions(lammps PRIVATE -DEIGEN_DONT_VECTORIZE)
 endif()
+
+target_compile_definitions(lammps PRIVATE -DEIGEN_NO_CUDA)

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_MD5 "ddfa46d6ee15b4e59cfd527ec7212184" CACHE STRING "MD5 checksum for MDI tarball")
+  set(MDI_URL "https://github.com/MolSSI-MDI/MDI_Library/archive/v1.4.11.tar.gz" CACHE STRING "URL for MDI tarball")
+  set(MDI_MD5 "3791fe5081405c14aac07d4687f1cc58" CACHE STRING "MD5 checksum for MDI tarball")
   mark_as_advanced(MDI_URL)
   mark_as_advanced(MDI_MD5)
   enable_language(C)
@@ -26,8 +26,21 @@ if(DOWNLOAD_MDI)
   # detect if we have python development support and thus can enable python plugins
   set(MDI_USE_PYTHON_PLUGINS OFF)
   if(CMAKE_VERSION VERSION_LESS 3.12)
+    if(NOT PYTHON_VERSION_STRING)
+      set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
+      # search for interpreter first, so we have a consistent library
+      find_package(PythonInterp) # Deprecated since version 3.12
+      if(PYTHONINTERP_FOUND)
+        set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
+      endif()
+    endif()
+    # search for the library matching the selected interpreter
+    set(Python_ADDITIONAL_VERSIONS ${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
     find_package(PythonLibs QUIET) # Deprecated since version 3.12
     if(PYTHONLIBS_FOUND)
+      if(NOT (PYTHON_VERSION_STRING STREQUAL PYTHONLIBS_VERSION_STRING))
+        message(FATAL_ERROR "Python Library version ${PYTHONLIBS_VERSION_STRING} does not match Interpreter version ${PYTHON_VERSION_STRING}")
+      endif()
       set(MDI_USE_PYTHON_PLUGINS ON)
     endif()
   else()
@@ -44,15 +57,17 @@ if(DOWNLOAD_MDI)
   ExternalProject_Add(mdi_build
     URL     ${MDI_URL}
     URL_MD5 ${MDI_MD5}
-    CMAKE_ARGS ${CMAKE_REQUEST_PIC}
+    CMAKE_ARGS
     -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
     -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
     -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
     -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
     -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
+    -DCMAKE_POSITION_INDEPENDENT_CODE=ON
     -Dlanguage=C
     -Dlibtype=STATIC
     -Dmpi=${MDI_USE_MPI}
+    -Dplugins=ON
     -Dpython_plugins=${MDI_USE_PYTHON_PLUGINS}
     UPDATE_COMMAND ""
     INSTALL_COMMAND ""

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/MISC.cmake

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

cmake/Modules/Packages/ML-HDNNP.cmake

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

cmake/Modules/Packages/ML-PACE.cmake

@@ -1,6 +1,6 @@
-set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2021.10.25.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
+set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2021.10.25.fix2.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
 
-set(PACELIB_MD5 "a2ac3315c41a1a4a5c912bcb1bc9c5cc" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
+set(PACELIB_MD5 "32394d799bc282bb57696c78c456e64f" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
 mark_as_advanced(PACELIB_URL)
 mark_as_advanced(PACELIB_MD5)
 
@@ -13,8 +13,12 @@ execute_process(
   COMMAND ${CMAKE_COMMAND} -E tar xzf libpace.tar.gz
   WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
 )
+get_newest_file(${CMAKE_BINARY_DIR}/lammps-user-pace-* lib-pace)
 
-file(GLOB lib-pace ${CMAKE_BINARY_DIR}/lammps-user-pace-*)
+# enforce building libyaml-cpp as static library and turn off optional features
+set(YAML_BUILD_SHARED_LIBS OFF)
+set(YAML_CPP_BUILD_CONTRIB OFF)
+set(YAML_CPP_BUILD_TOOLS OFF)
 add_subdirectory(${lib-pace}/yaml-cpp build-yaml-cpp)
 set(YAML_CPP_INCLUDE_DIR ${lib-pace}/yaml-cpp/include)
 
@@ -28,5 +32,6 @@ target_include_directories(pace PUBLIC ${PACE_EVALUATOR_INCLUDE_DIR} ${YAML_CPP_
 
 
 target_link_libraries(pace PRIVATE yaml-cpp-pace)
-
-target_link_libraries(lammps PRIVATE pace)
+if(CMAKE_PROJECT_NAME STREQUAL "lammps")
+  target_link_libraries(lammps PRIVATE pace)
+endif()

cmake/Modules/Packages/ML-QUIP.cmake

@@ -43,6 +43,7 @@ if(DOWNLOAD_QUIP)
   file(WRITE ${CMAKE_BINARY_DIR}/quip.config "${temp}")
 
   message(STATUS "QUIP download via git requested - we will build our own")
+  set(CMAKE_EP_GIT_REMOTE_UPDATE_STRATEGY CHECKOUT)
   # QUIP has no releases (except for a tag marking the end of Python 2 support). We use the current "public" branch
   # The LAMMPS interface wrapper has a compatibility constant that is being checked at runtime.
   include(ExternalProject)
@@ -51,6 +52,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_MD5 "f00cc82edfefe6bb3df934911dbe32fb" CACHE STRING "MD5 checksum of PLUMED tarball")
+  set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.7.4/plumed-src-2.7.4.tgz" CACHE STRING "URL for PLUMED tarball")
+  set(PLUMED_MD5 "858e0b6aed173748fc85b6bc8a9dcb3e" CACHE STRING "MD5 checksum of PLUMED tarball")
 
   mark_as_advanced(PLUMED_URL)
   mark_as_advanced(PLUMED_MD5)

cmake/Modules/Packages/PYTHON.cmake

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

cmake/Modules/Tools.cmake

@@ -3,6 +3,9 @@ if(BUILD_TOOLS)
   target_compile_definitions(binary2txt PRIVATE -DLAMMPS_${LAMMPS_SIZES})
   install(TARGETS binary2txt DESTINATION ${CMAKE_INSTALL_BINDIR})
 
+  add_executable(stl_bin2txt ${LAMMPS_TOOLS_DIR}/stl_bin2txt.cpp)
+  install(TARGETS stl_bin2txt DESTINATION ${CMAKE_INSTALL_BINDIR})
+
   include(CheckGeneratorSupport)
   if(CMAKE_GENERATOR_SUPPORT_FORTRAN)
     include(CheckLanguage)

cmake/Modules/generate_lmpgitversion.cmake

@@ -31,5 +31,7 @@ set(temp "${temp}const char *LAMMPS_NS::LAMMPS::git_descriptor() { return \"${te
 set(temp "${temp}#endif\n\n")
 
 message(STATUS "Generating lmpgitversion.h...")
-file(WRITE "${LAMMPS_STYLE_HEADERS_DIR}/lmpgitversion.h.tmp" "${temp}" )
-execute_process(COMMAND ${CMAKE_COMMAND} -E copy_if_different "${LAMMPS_STYLE_HEADERS_DIR}/lmpgitversion.h.tmp" "${LAMMPS_STYLE_HEADERS_DIR}/lmpgitversion.h")
+
+string(REPLACE "\\ " " " LAMMPS_GIT_HEADER "${LAMMPS_STYLE_HEADERS_DIR}/lmpgitversion.h")
+file(WRITE "${LAMMPS_GIT_HEADER}.tmp" "${temp}" )
+execute_process(COMMAND ${CMAKE_COMMAND} -E copy_if_different "${LAMMPS_GIT_HEADER}.tmp" "${LAMMPS_GIT_HEADER}")

cmake/presets/all_off.cmake

@@ -3,14 +3,16 @@
 
 set(ALL_PACKAGES
   ADIOS
+  AMOEBA
   ASPHERE
   ATC
   AWPMD
   BOCS
   BODY
+  BPM
   BROWNIAN
   CG-DNA
-  CG-SDK
+  CG-SPICA
   CLASS2
   COLLOID
   COLVARS
@@ -24,6 +26,7 @@ set(ALL_PACKAGES
   DPD-REACT
   DPD-SMOOTH
   DRUDE
+  ELECTRODE
   EFF
   EXTRA-COMPUTE
   EXTRA-DUMP
@@ -48,7 +51,6 @@ set(ALL_PACKAGES
   MDI
   MEAM
   MESONT
-  MESSAGE
   MGPT
   MISC
   ML-HDNNP

cmake/presets/all_on.cmake

@@ -5,14 +5,16 @@
 
 set(ALL_PACKAGES
   ADIOS
+  AMOEBA
   ASPHERE
   ATC
   AWPMD
   BOCS
   BODY
+  BPM
   BROWNIAN
   CG-DNA
-  CG-SDK
+  CG-SPICA
   CLASS2
   COLLOID
   COLVARS
@@ -26,6 +28,7 @@ set(ALL_PACKAGES
   DPD-REACT
   DPD-SMOOTH
   DRUDE
+  ELECTRODE
   EFF
   EXTRA-COMPUTE
   EXTRA-DUMP
@@ -50,7 +53,6 @@ set(ALL_PACKAGES
   MDI
   MEAM
   MESONT
-  MESSAGE
   MGPT
   MISC
   ML-HDNNP

cmake/presets/clang.cmake

@@ -3,6 +3,13 @@
 # prefer flang over gfortran, if available
 find_program(CLANG_FORTRAN NAMES flang gfortran f95)
 set(ENV{OMPI_FC} ${CLANG_FORTRAN})
+get_filename_component(_tmp_fc ${CLANG_FORTRAN} NAME)
+if (_tmp_fc STREQUAL "flang")
+  set(FC_STD_VERSION "-std=f2018")
+  set(BUILD_MPI OFF)
+else()
+  set(FC_STD_VERSION "-std=f2003")
+endif()
 
 set(CMAKE_CXX_COMPILER "clang++" CACHE STRING "" FORCE)
 set(CMAKE_C_COMPILER "clang" CACHE STRING "" FORCE)
@@ -10,9 +17,9 @@ set(CMAKE_Fortran_COMPILER ${CLANG_FORTRAN} CACHE STRING "" FORCE)
 set(CMAKE_CXX_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
 set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
 set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
-set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -Wextra -g -std=f2003" CACHE STRING "" FORCE)
-set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
-set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -Wextra -g ${FC_STD_VERSION}" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG ${FC_STD_VERSION}" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG ${FC_STD_VERSION}" CACHE STRING "" FORCE)
 set(CMAKE_C_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
 set(CMAKE_C_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
 set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)

cmake/presets/kokkos-cuda.cmake

@@ -3,9 +3,9 @@
 # that is compatible with all higher CC, but not the default CC 3.5
 set(PKG_KOKKOS ON CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_SERIAL ON CACHE BOOL "" FORCE)
-set(Kokkos_ENABLE_OPENMP ON CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_CUDA   ON CACHE BOOL "" FORCE)
-set(Kokkos_ARCH_MAXWELL50 on CACHE BOOL "" FORCE)
+set(Kokkos_ARCH_PASCAL60 ON CACHE BOOL "" FORCE)
 set(BUILD_OMP ON CACHE BOOL "" FORCE)
-get_filename_component(NVCC_WRAPPER_CMD ${CMAKE_CURRENT_SOURCE_DIR}/../lib/kokkos/bin/nvcc_wrapper ABSOLUTE)
-set(CMAKE_CXX_COMPILER ${NVCC_WRAPPER_CMD} CACHE FILEPATH "" FORCE)
+
+# hide deprecation warnings temporarily for stable release
+set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)

cmake/presets/kokkos-hip.cmake

@@ -0,0 +1,20 @@
+# preset that enables KOKKOS and selects HIP compilation with OpenMP
+# enabled as well. Also sets some performance related compiler flags.
+set(PKG_KOKKOS ON CACHE BOOL "" FORCE)
+set(Kokkos_ENABLE_SERIAL ON CACHE BOOL "" FORCE)
+set(Kokkos_ENABLE_OPENMP ON CACHE BOOL "" FORCE)
+set(Kokkos_ENABLE_CUDA   OFF CACHE BOOL "" FORCE)
+set(Kokkos_ENABLE_HIP    ON CACHE BOOL "" FORCE)
+set(Kokkos_ARCH_VEGA90A on CACHE BOOL "" FORCE)
+set(Kokkos_ENABLE_HIP_MULTIPLE_KERNEL_INSTANTIATIONS ON CACHE BOOL "" FORCE)
+set(BUILD_OMP ON CACHE BOOL "" FORCE)
+
+set(CMAKE_CXX_COMPILER hipcc CACHE STRING "" FORCE)
+set(CMAKE_TUNE_FLAGS "-munsafe-fp-atomics" CACHE STRING "" FORCE)
+
+# hide deprecation warnings temporarily for stable release
+set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
+
+# these flags are needed to build with Cray MPICH on OLCF Crusher
+#-D CMAKE_CXX_FLAGS="-I/${MPICH_DIR}/include"
+#-D MPI_CXX_LIBRARIES="-L${MPICH_DIR}/lib -lmpi -L${CRAY_MPICH_ROOTDIR}/gtl/lib -lmpi_gtl_hsa"

cmake/presets/kokkos-openmp.cmake

@@ -4,3 +4,6 @@ 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(BUILD_OMP ON CACHE BOOL "" FORCE)
+
+# hide deprecation warnings temporarily for stable release
+set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)

cmake/presets/kokkos-serial.cmake

@@ -3,3 +3,6 @@ set(PKG_KOKKOS ON CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_SERIAL ON  CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_OPENMP OFF CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_CUDA   OFF CACHE BOOL "" FORCE)
+
+# hide deprecation warnings temporarily for stable release
+set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)

cmake/presets/kokkos-sycl.cmake

@@ -0,0 +1,18 @@
+# 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)
+
+# hide deprecation warnings temporarily for stable release
+set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
+
+set(CMAKE_CXX_COMPILER clang++ CACHE STRING "" FORCE)
+set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
+set(CMAKE_CXX_STANDARD 17 CACHE STRING "" FORCE)
+set(CMAKE_SHARED_LINKER_FLAGS "-Xsycl-target-frontend -O3" CACHE STRING "" FORCE)
+set(CMAKE_TUNE_FLAGS "-fgpu-inline-threshold=100000 -Xsycl-target-frontend -O3  -Xsycl-target-frontend -ffp-contract=on -Wno-unknown-cuda-version" CACHE STRING "" FORCE)

cmake/presets/mingw-cross.cmake

@@ -1,12 +1,14 @@
 set(WIN_PACKAGES
+  AMOEBA
   ASPHERE
   ATC
   AWPMD
   BOCS
   BODY
+  BPM
   BROWNIAN
   CG-DNA
-  CG-SDK
+  CG-SPICA
   CLASS2
   COLLOID
   COLVARS
@@ -20,6 +22,7 @@ set(WIN_PACKAGES
   DPD-REACT
   DPD-SMOOTH
   DRUDE
+  ELECTRODE
   EFF
   EXTRA-COMPUTE
   EXTRA-DUMP
@@ -44,8 +47,8 @@ set(WIN_PACKAGES
   MISC
   ML-HDNNP
   ML-IAP
-  ML-SNAP
   ML-RANN
+  ML-SNAP
   MOFFF
   MOLECULE
   MOLFILE
@@ -54,6 +57,7 @@ set(WIN_PACKAGES
   ORIENT
   PERI
   PHONON
+  PLUGIN
   POEMS
   PTM
   QEQ

cmake/presets/most.cmake

@@ -3,12 +3,14 @@
 # are removed. The resulting binary should be able to run most inputs.
 
 set(ALL_PACKAGES
+  AMOEBA
   ASPHERE
   BOCS
   BODY
+  BPM
   BROWNIAN
   CG-DNA
-  CG-SDK
+  CG-SPICA
   CLASS2
   COLLOID
   COLVARS
@@ -22,6 +24,7 @@ set(ALL_PACKAGES
   DPD-REACT
   DPD-SMOOTH
   DRUDE
+  ELECTRODE
   EFF
   EXTRA-COMPUTE
   EXTRA-DUMP

cmake/presets/nolib.cmake

@@ -6,6 +6,7 @@ set(PACKAGES_WITH_LIB
   ATC
   AWPMD
   COMPRESS
+  ELECTRODE
   GPU
   H5MD
   KIM
@@ -15,7 +16,6 @@ set(PACKAGES_WITH_LIB
   MACHDYN
   MDI
   MESONT
-  MESSAGE
   ML-HDNNP
   ML-PACE
   ML-QUIP

cmake/presets/pgi.cmake

@@ -1,4 +1,4 @@
-# preset that will enable clang/clang++ with support for MPI and OpenMP (on Linux boxes)
+# preset that will enable PGI (Nvidia) compilers with support for MPI and OpenMP (on Linux boxes)
 
 set(CMAKE_CXX_COMPILER "pgc++" CACHE STRING "" FORCE)
 set(CMAKE_C_COMPILER "pgcc" CACHE STRING "" FORCE)

cmake/presets/windows-intel-classic.cmake

@@ -0,0 +1,8 @@
+# preset that will enable Intel compilers with support for MPI and OpenMP (on Linux boxes)
+
+set(CMAKE_CXX_COMPILER "icl" CACHE STRING "" FORCE)
+set(CMAKE_C_COMPILER "icl" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_COMPILER "ifort" CACHE STRING "" FORCE)
+
+unset(HAVE_OMP_H_INCLUDE CACHE)
+

cmake/presets/windows-intel-llvm.cmake

@@ -0,0 +1,8 @@
+# preset that will enable Intel compilers with support for MPI and OpenMP (on Linux boxes)
+
+set(CMAKE_CXX_COMPILER "icx" CACHE STRING "" FORCE)
+set(CMAKE_C_COMPILER "icx" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_COMPILER "ifx" CACHE STRING "" FORCE)
+set(INTEL_LRT_MODE "C++11" CACHE STRING "" FORCE)
+unset(HAVE_OMP_H_INCLUDE CACHE)
+set(CMAKE_TUNE_FLAGS -Wno-unused-command-line-argument)

cmake/presets/windows.cmake

@@ -1,10 +1,12 @@
 set(WIN_PACKAGES
+  AMOEBA
   ASPHERE
   BOCS
   BODY
+  BPM
   BROWNIAN
   CG-DNA
-  CG-SDK
+  CG-SPICA
   CLASS2
   COLLOID
   COLVARS
@@ -42,6 +44,7 @@ set(WIN_PACKAGES
   PERI
   PHONON
   POEMS
+  PLUGIN
   PTM
   QEQ
   QTB

doc/.gitignore

@@ -1,6 +1,6 @@
 /old
 /html
-/html-offline
+/fasthtml
 /epub
 /latex
 /mathjax

doc/Makefile

@@ -13,35 +13,24 @@ VENV           = $(BUILDDIR)/docenv
 ANCHORCHECK    = $(VENV)/bin/rst_anchor_check
 SPHINXCONFIG   = $(BUILDDIR)/utils/sphinx-config
 MATHJAX        = $(SPHINXCONFIG)/_static/mathjax
+MATHJAXTAG     = 3.2.2
 
-PYTHON         = $(shell which python3)
-DOXYGEN        = $(shell which doxygen)
-VIRTUALENV     = virtualenv
+PYTHON         = $(word 3,$(shell type python3))
+DOXYGEN        = $(word 3,$(shell type doxygen))
 HAS_PYTHON3    = NO
-HAS_VIRTUALENV = NO
 HAS_DOXYGEN    = NO
 HAS_PDFLATEX   = NO
 
-ifeq ($(shell which python3 >/dev/null 2>&1; echo $$?), 0)
+ifeq ($(shell type python3 >/dev/null 2>&1; echo $$?), 0)
 HAS_PYTHON3    = YES
 endif
 
-ifeq ($(shell which doxygen >/dev/null 2>&1; echo $$?), 0)
+ifeq ($(shell type doxygen >/dev/null 2>&1; echo $$?), 0)
 HAS_DOXYGEN    = YES
 endif
 
-ifeq ($(shell which virtualenv-3 >/dev/null 2>&1; echo $$?), 0)
-VIRTUALENV     = virtualenv-3
-HAS_VIRTUALENV = YES
-endif
-
-ifeq ($(shell which virtualenv >/dev/null 2>&1; echo $$?), 0)
-VIRTUALENV     = virtualenv
-HAS_VIRTUALENV = YES
-endif
-
-ifeq ($(shell which pdflatex >/dev/null 2>&1; echo $$?), 0)
-ifeq ($(shell which latexmk >/dev/null 2>&1; echo $$?), 0)
+ifeq ($(shell type pdflatex >/dev/null 2>&1; echo $$?), 0)
+ifeq ($(shell type latexmk >/dev/null 2>&1; echo $$?), 0)
 HAS_PDFLATEX = YES
 endif
 endif
@@ -58,7 +47,7 @@ SPHINXEXTRA = -E -j $(shell $(PYTHON) -c 'import multiprocessing;print(multiproc
 # we only want to use explicitly listed files.
 DOXYFILES      = $(shell sed -n -e 's/\#.*$$//' -e '/^ *INPUT \+=/,/^[A-Z_]\+ \+=/p' doxygen/Doxyfile.in | sed -e 's/@LAMMPS_SOURCE_DIR@/..\/src/g' -e 's/\\//g' -e 's/ \+/ /' -e 's/[A-Z_]\+ \+= *\(YES\|NO\|\)//') 
 
-.PHONY: help clean-all clean clean-spelling epub mobi rst html pdf spelling anchor_check style_check char_check xmlgen
+.PHONY: help clean-all clean clean-spelling epub mobi rst html pdf spelling anchor_check style_check char_check xmlgen fasthtml
 
 # ------------------------------------------
 
@@ -70,7 +59,8 @@ help:
 	@echo "  epub          create ePUB format manual for e-book readers"
 	@echo "  mobi          convert ePUB to MOBI format manual for e-book readers (e.g. Kindle)"
 	@echo "                      (requires ebook-convert tool from calibre)"
-	@echo "  clean         remove all intermediate RST files"
+	@echo "  fasthtml      approximate HTML page creation in fasthtml dir (for development)"
+	@echo "  clean         remove all intermediate files"
 	@echo "  clean-all     reset the entire build environment"
 	@echo "  anchor_check  scan for duplicate anchor labels"
 	@echo "  style_check   check for complete and consistent style lists"
@@ -83,7 +73,7 @@ clean-all: clean
 	rm -rf $(BUILDDIR)/docenv $(MATHJAX) $(BUILDDIR)/LAMMPS.mobi $(BUILDDIR)/LAMMPS.epub $(BUILDDIR)/Manual.pdf
 
 clean: clean-spelling
-	rm -rf $(BUILDDIR)/html $(BUILDDIR)/epub $(BUILDDIR)/latex $(BUILDDIR)/doctrees $(BUILDDIR)/doxygen/xml $(BUILDDIR)/doxygen-warn.log $(BUILDDIR)/doxygen/Doxyfile $(SPHINXCONFIG)/conf.py
+	rm -rf $(BUILDDIR)/html $(BUILDDIR)/epub $(BUILDDIR)/latex $(BUILDDIR)/doctrees $(BUILDDIR)/doxygen/xml $(BUILDDIR)/doxygen-warn.log $(BUILDDIR)/doxygen/Doxyfile $(SPHINXCONFIG)/conf.py $(BUILDDIR)/fasthtml
 
 clean-spelling:
 	rm -rf $(BUILDDIR)/spelling
@@ -118,6 +108,23 @@ html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
 	@rm -rf html/PDF/.[sg]*
 	@echo "Build finished. The HTML pages are in doc/html."
 
+fasthtml: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
+	@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
+	@$(MAKE) $(MFLAGS) -C graphviz all
+	@mkdir -p fasthtml
+	@(\
+		. $(VENV)/bin/activate ; env PYTHONWARNINGS= \
+		sphinx-build -j 4 -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/fasthtml/doctrees $(RSTDIR) fasthtml ;\
+		deactivate ;\
+	)
+	@rm -rf fasthtml/_sources
+	@rm -rf fasthtml/PDF
+	@rm -rf fasthtml/USER
+	@rm -rf fasthtml/JPG
+	@cp -r src/PDF fasthtml/PDF
+	@rm -rf fasthtml/PDF/.[sg]*
+	@echo "Fast HTML build finished. The HTML pages are in doc/fasthtml."
+
 spelling: xmlgen $(SPHINXCONFIG)/conf.py $(VENV) $(SPHINXCONFIG)/false_positives.txt
 	@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
 	@(\
@@ -220,22 +227,21 @@ $(VENV):
 	@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
 	@if [ "$(HAS_PYTHON3)" == "NO" ] ; then echo "python3 was not found! Please see README for further instructions" 1>&2; exit 1; fi
 	@if [ "$(HAS_DOXYGEN)" == "NO" ] ; then echo "doxygen was not found! Please see README for further instructions" 1>&2; exit 1; fi
-	@if [ "$(HAS_VIRTUALENV)" == "NO" ] ; then echo "virtualenv was not found! Please see README for further instructions" 1>&2; exit 1; fi
 	@( \
-		$(VIRTUALENV) -p $(PYTHON) $(VENV); \
+		$(PYTHON) -m venv $(VENV); \
 		. $(VENV)/bin/activate; \
 		pip $(PIP_OPTIONS) install --upgrade pip; \
+		pip $(PIP_OPTIONS) install --upgrade wheel; \
 		pip $(PIP_OPTIONS) install -r $(BUILDDIR)/utils/requirements.txt; \
 		deactivate;\
 	)
 
 $(MATHJAX):
-	@git clone -b 3.2.0 -c advice.detachedHead=0 --depth 1 https://github.com/mathjax/MathJax.git $@
+	@git clone -b $(MATHJAXTAG) -c advice.detachedHead=0 --depth 1 https://github.com/mathjax/MathJax.git $@
 
 $(ANCHORCHECK): $(VENV)
 	@( \
 		. $(VENV)/bin/activate; \
-		(cd utils/converters;\
-		python setup.py develop);\
+		pip $(PIP_OPTIONS) install -e utils/converters;\
 		deactivate;\
 	)

doc/doxygen/Doxyfile.in

@@ -2,7 +2,7 @@
 
 DOXYFILE_ENCODING      = UTF-8
 PROJECT_NAME           = "LAMMPS Programmer's Guide"
-PROJECT_NUMBER         = "24 August 2020"
+PROJECT_NUMBER         = "4 May 2022"
 PROJECT_BRIEF          = "Documentation of the LAMMPS library interface and Python wrapper"
 PROJECT_LOGO           = lammps-logo.png
 CREATE_SUBDIRS         = NO
@@ -437,6 +437,8 @@ INPUT                  = @LAMMPS_SOURCE_DIR@/utils.cpp                 \
                          @LAMMPS_SOURCE_DIR@/math_eigen.h              \
                          @LAMMPS_SOURCE_DIR@/platform.h                \
                          @LAMMPS_SOURCE_DIR@/platform.cpp              \
+                         @LAMMPS_SOURCE_DIR@/math_special.h            \
+                         @LAMMPS_SOURCE_DIR@/math_special.cpp          \
 
 # The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
 # directories that are symbolic links (a Unix file system feature) are excluded

doc/lammps.1

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

@@ -98,7 +98,7 @@ msi2lmp decane -c 0 -f oplsaa
 
 
 .SH COPYRIGHT
-© 2003--2021 Sandia Corporation
+© 2003--2022 Sandia Corporation
 
 This package is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License version 2 as

doc/src/Bibliography.rst

@@ -1373,7 +1373,7 @@ Bibliography
    Zhu, Tajkhorshid, and Schulten, Biophys. J. 83, 154 (2002).
 
 **(Ziegler)**
-   J.F. Ziegler, J. P. Biersack and U. Littmark, "The Stopping and Range of Ions in Matter," Volume 1, Pergamon, 1985.
+   J.F. Ziegler, J. P. Biersack and U. Littmark, "The Stopping and Range of Ions in Matter", Volume 1, Pergamon, 1985.
 
 **(Zimmerman2004)**
    Zimmerman, JA; Webb, EB; Hoyt, JJ;. Jones, RE; Klein, PA; Bammann, DJ, "Calculation of stress in atomistic simulation." Special Issue of Modelling and Simulation in Materials Science and Engineering (2004),12:S319.

doc/src/Build_development.rst

@@ -486,14 +486,14 @@ The following options are available.
    make fix-whitespace      # correct whitespace issues in files
    make check-homepage      # search for files with old LAMMPS homepage URLs
    make fix-homepage        # correct LAMMPS homepage URLs in files
+   make check-errordocs     # search for deprecated error docs in header files
+   make fix-errordocs       # remove error docs in header files
    make check-permissions   # search for files with permissions issues
    make fix-permissions     # correct permissions issues in files
+   make check               # run all check targets from above
 
-These should help to replace all TAB characters with blanks and remove
-any trailing whitespace.  Also all LAMMPS homepage URL references can be
-updated to the location change from Sandia to the lammps.org domain.
-And the permission check can remove executable permissions from non-executable
-files (like source code).
+These should help to make source and documentation files conforming
+to some the coding style preferences of the LAMMPS developers.
 
 Clang-format support
 --------------------

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>`
@@ -124,6 +123,7 @@ CMake build
    -D GPU_API=value             # value = opencl (default) or cuda or hip
    -D GPU_PREC=value            # precision setting
                                 # value = double or mixed (default) or single
+   -D HIP_PATH                  # path to HIP installation. Must be set if GPU_API=HIP
    -D GPU_ARCH=value            # primary GPU hardware choice for GPU_API=cuda
                                 # value = sm_XX, see below
                                 # default is sm_50
@@ -142,8 +142,6 @@ CMake build
 
 :code:`GPU_ARCH` settings for different GPU hardware is as follows:
 
-* sm_12 or sm_13 for GT200 (supported by CUDA 3.2 until CUDA 6.5)
-* sm_20 or sm_21 for Fermi (supported by CUDA 3.2 until CUDA 7.5)
 * sm_30 for Kepler (supported since CUDA 5 and until CUDA 10.x)
 * sm_35 or sm_37 for Kepler (supported since CUDA 5 and until CUDA 11.x)
 * sm_50 or sm_52 for Maxwell (supported since CUDA 6)
@@ -161,6 +159,12 @@ Thus the GPU_ARCH setting is merely an optimization, to have code for
 the preferred GPU architecture directly included rather than having to wait
 for the JIT compiler of the CUDA driver to translate it.
 
+When compiling for CUDA or HIP with CUDA, version 8.0 or later of the CUDA toolkit
+is required and a GPU architecture of Kepler or later, which must *also* be
+supported by the CUDA toolkit in use **and** the CUDA driver in use.
+When compiling for OpenCL, OpenCL version 1.2 or later is required and the
+GPU must be supported by the GPU driver and OpenCL runtime bundled with the driver.
+
 When building with CMake, you **must NOT** build the GPU library in ``lib/gpu``
 using the traditional build procedure. CMake will detect files generated by that
 process and will terminate with an error and a suggestion for how to remove them.
@@ -176,10 +180,17 @@ set appropriate environment variables. Some variables such as
 :code:`HCC_AMDGPU_TARGET` (for ROCm <= 4.0) or :code:`CUDA_PATH` are necessary for :code:`hipcc`
 and the linker to work correctly.
 
+Using CHIP-SPV implementation of HIP is now supported. It allows one to run HIP
+code on Intel GPUs via the OpenCL or Level Zero backends. To use CHIP-SPV, you must
+set :code:`-DHIP_USE_DEVICE_SORT=OFF` in your CMake command line as CHIP-SPV does not
+yet support hipCUB. The use of HIP for Intel GPUs is still experimental so you
+should only use this option in preparations to run on Aurora system at ANL.
+
 .. code:: bash
 
    # AMDGPU target (ROCm <= 4.0)
    export HIP_PLATFORM=hcc
+   export HIP_PATH=/path/to/HIP/install
    export HCC_AMDGPU_TARGET=gfx906
    cmake -D PKG_GPU=on -D GPU_API=HIP -D HIP_ARCH=gfx906 -D CMAKE_CXX_COMPILER=hipcc ..
    make -j 4
@@ -188,6 +199,7 @@ and the linker to work correctly.
 
    # AMDGPU target (ROCm >= 4.1)
    export HIP_PLATFORM=amd
+   export HIP_PATH=/path/to/HIP/install
    cmake -D PKG_GPU=on -D GPU_API=HIP -D HIP_ARCH=gfx906 -D CMAKE_CXX_COMPILER=hipcc ..
    make -j 4
 
@@ -196,10 +208,20 @@ and the linker to work correctly.
    # CUDA target (not recommended, use GPU_ARCH=cuda)
    # !!! DO NOT set CMAKE_CXX_COMPILER !!!
    export HIP_PLATFORM=nvcc
+   export HIP_PATH=/path/to/HIP/install
    export CUDA_PATH=/usr/local/cuda
    cmake -D PKG_GPU=on -D GPU_API=HIP -D HIP_ARCH=sm_70 ..
    make -j 4
 
+.. code:: bash
+
+   # SPIR-V target (Intel GPUs)
+   export HIP_PLATFORM=spirv
+   export HIP_PATH=/path/to/HIP/install
+   export CMAKE_CXX_COMPILER=<hipcc/clang++>
+   cmake -D PKG_GPU=on -D GPU_API=HIP ..
+   make -j 4
+
 Traditional make
 ^^^^^^^^^^^^^^^^
 
@@ -638,13 +660,27 @@ 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
+      For AMD or NVIDIA GPUs using HIP, set these variables:
+
+      .. code-block:: bash
+
+         -D Kokkos_ARCH_HOSTARCH=yes   # HOSTARCH = HOST from list above
+         -D Kokkos_ARCH_GPUARCH=yes    # GPUARCH = GPU from list above
+         -D Kokkos_ENABLE_HIP=yes
+         -D Kokkos_ENABLE_OPENMP=yes
+
+      This will enable FFTs on the GPU, either by the internal KISSFFT library
+      or with the hipFFT wrapper library, which will call out to the
+      platform-appropriate vendor library: rocFFT on AMD GPUs or cuFFT on
+      NVIDIA GPUs.
+
+      To simplify compilation, five preset files are included in the
       ``cmake/presets`` folder, ``kokkos-serial.cmake``,
-      ``kokkos-openmp.cmake``, and ``kokkos-cuda.cmake``. They will
-      enable the KOKKOS package and enable some hardware choice.  So to
-      compile with OpenMP host parallelization, CUDA device
-      parallelization (for GPUs with CC 5.0 and up) with some common
-      packages enabled, you can do the following:
+      ``kokkos-openmp.cmake``, ``kokkos-cuda.cmake``,
+      ``kokkos-hip.cmake``, and ``kokkos-sycl.cmake``.  They will enable
+      the KOKKOS package and enable some hardware choice.  So to compile
+      with CUDA device parallelization (for GPUs with CC 5.0 and up)
+      with some common packages enabled, you can do the following:
 
       .. code-block:: bash
 
@@ -703,6 +739,15 @@ This list was last updated for version 3.5.0 of the Kokkos library.
          KOKKOS_ABSOLUTE_PATH = $(shell cd $(KOKKOS_PATH); pwd)
          CC = mpicxx -cxx=$(KOKKOS_ABSOLUTE_PATH)/config/nvcc_wrapper
 
+      For AMD or NVIDIA GPUs using HIP:
+
+      .. code-block:: make
+
+         KOKKOS_DEVICES = HIP
+         KOKKOS_ARCH = HOSTARCH,GPUARCH  # HOSTARCH = HOST from list above that is hosting the GPU
+                                         # GPUARCH = GPU from list above
+         FFT_INC = -DFFT_HIPFFT           # enable use of hipFFT (optional)
+         FFT_LIB = -lhipfft               # link to hipFFT library
 
 Advanced KOKKOS compilation settings
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -762,8 +807,10 @@ library.
 
       .. code-block:: bash
 
-         -D DOWNLOAD_LATTE=value    # download LATTE for build, value = no (default) or yes
-         -D LATTE_LIBRARY=path      # LATTE library file (only needed if a custom location)
+         -D DOWNLOAD_LATTE=value      # download LATTE for build, value = no (default) or yes
+         -D LATTE_LIBRARY=path        # LATTE library file (only needed if a custom location)
+         -D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
+                                      #   value = no (default) or yes
 
       If ``DOWNLOAD_LATTE`` is set, the LATTE library will be downloaded
       and built inside the CMake build directory.  If the LATTE library
@@ -771,6 +818,13 @@ library.
       ``LATTE_LIBRARY`` is the filename (plus path) of the LATTE library
       file, not the directory the library file is in.
 
+      The LATTE library requires LAPACK (and BLAS) and CMake can identify
+      their locations and pass that info to the LATTE build script. But
+      on some systems this triggers a (current) limitation of CMake and
+      the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
+      those cases to use the bundled linear algebra library and work around
+      the limitation.
+
    .. tab:: Traditional make
 
       You can download and build the LATTE library manually if you
@@ -796,47 +850,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
@@ -1289,6 +1302,41 @@ be built for the most part with all major versions of the C++ language.
 
 ----------
 
+.. _electrode:
+
+ELECTRODE package
+-----------------
+
+This package depends on the KSPACE package.
+
+.. tabs::
+
+   .. tab:: CMake build
+
+      No additional settings are needed besides ``-D PKG_KSPACE=yes`` and ``-D
+      PKG_ELECTRODE=yes``.
+
+   .. tab:: Traditional make
+
+      The package is activated with ``make yes-KSPACE`` and ``make
+      yes-ELECTRODE``
+
+
+      Note that the ``Makefile.lammps`` file has settings for the BLAS and
+      LAPACK linear algebra libraries.  As explained in ``lib/awpmd/README``
+      these can either exist on your system, or you can use the files provided
+      in ``lib/linalg``.  In the latter case you also need to build the library
+      in ``lib/linalg`` with a command like these:
+
+      .. code-block:: bash
+
+         $ make lib-linalg                     # print help message
+         $ make lib-linalg args="-m serial"    # build with GNU Fortran compiler (settings as with "make serial")
+         $ make lib-linalg args="-m mpi"       # build with default MPI Fortran compiler (settings as with "make mpi")
+         $ make lib-linalg args="-m gfortran"  # build with GNU Fortran compiler
+
+----------
+
 .. _ml-pace:
 
 ML-PACE package
@@ -1893,14 +1941,25 @@ within CMake will download the non-commercial use version.
 
       .. code-block:: bash
 
-         -D DOWNLOAD_QUIP=value   # download OpenKIM API v2 for build, value = no (default) or yes
-         -D QUIP_LIBRARY=path     # path to libquip.a (only needed if a custom location)
+         -D DOWNLOAD_QUIP=value       # download QUIP library for build, value = no (default) or yes
+         -D QUIP_LIBRARY=path         # path to libquip.a (only needed if a custom location)
+         -D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
+                                      #   value = no (default) or yes
 
-      CMake will try to download and build the QUIP library from GitHub, if it is not
-      found on the local machine. This requires to have git installed. It will use the same compilers
-      and flags as used for compiling LAMMPS.  Currently this is only supported for the GNU and the
-      Intel compilers. Set the ``QUIP_LIBRARY`` variable if you want to use a previously compiled
-      and installed QUIP library and CMake cannot find it.
+      CMake will try to download and build the QUIP library from GitHub,
+      if it is not found on the local machine. This requires to have git
+      installed. It will use the same compilers and flags as used for
+      compiling LAMMPS.  Currently this is only supported for the GNU
+      and the Intel compilers. Set the ``QUIP_LIBRARY`` variable if you
+      want to use a previously compiled and installed QUIP library and
+      CMake cannot find it.
+
+      The QUIP library requires LAPACK (and BLAS) and CMake can identify
+      their locations and pass that info to the QUIP build script. But
+      on some systems this triggers a (current) limitation of CMake and
+      the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
+      those cases to use the bundled linear algebra library and work around
+      the limitation.
 
    .. tab:: Traditional make
 

doc/src/Build_manual.rst

@@ -48,18 +48,15 @@ Build using GNU make
 
 The LAMMPS manual is written in `reStructuredText <rst_>`_ format which
 can be translated to different output format using the `Sphinx
-<sphinx_>`_ document generator tool.  It also incorporates programmer
-documentation extracted from the LAMMPS C++ sources through the `Doxygen
-<https://doxygen.nl>`_ program.  Currently the translation to HTML, PDF
-(via LaTeX), ePUB (for many e-book readers) and MOBI (for Amazon Kindle
-readers) are supported.  For that to work a Python 3 interpreter, the
-``doxygen`` tools and internet access to download additional files and
-tools are required.  This download is usually only required once or
-after the documentation folder is returned to a pristine state with
-``make clean-all``.
-
-.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
-.. _sphinx: https://www.sphinx-doc.org
+<https://sphinx-doc.org>`_ document generator tool.  It also
+incorporates programmer documentation extracted from the LAMMPS C++
+sources through the `Doxygen <https://doxygen.nl>`_ program.  Currently
+the translation to HTML, PDF (via LaTeX), ePUB (for many e-book readers)
+and MOBI (for Amazon Kindle readers) are supported.  For that to work a
+Python 3 interpreter, the ``doxygen`` tools and internet access to
+download additional files and tools are required.  This download is
+usually only required once or after the documentation folder is returned
+to a pristine state with ``make clean-all``.
 
 For the documentation build a python virtual environment is set up in
 the folder ``doc/docenv`` and various python packages are installed into
@@ -78,11 +75,12 @@ folder.  The following ``make`` commands are available:
 
    make html          # generate HTML in html dir using Sphinx
    make pdf           # generate PDF  as Manual.pdf using Sphinx and PDFLaTeX
-   make fetch         # fetch HTML pages and PDF files from LAMMPS website
-                      #  and unpack into the html_www folder and Manual_www.pdf
    make epub          # generate LAMMPS.epub in ePUB format using Sphinx
    make mobi          # generate LAMMPS.mobi in MOBI format using ebook-convert
 
+   make fasthtml      # generate approximate HTML in fasthtml dir using Sphinx
+                      # some Sphinx extensions do not work correctly with this
+
    make clean         # remove intermediate RST files created by HTML build
    make clean-all     # remove entire build folder and any cached data
 
@@ -193,8 +191,13 @@ folder need to be updated or new files added. These files are written in
 `reStructuredText <rst_>`_ markup for translation with the Sphinx tool.
 
 Before contributing any documentation, please check that both the HTML
-and the PDF format documentation can translate without errors. Please also
-check the output to the console for any warnings or problems.  There will
+and the PDF format documentation can translate without errors.  During
+testing the html translation, you may use the ``make fasthtml`` command
+which does an approximate translation (i.e. not all Sphinx features and
+extensions will work), but runs very fast because it will only translate
+files that have been changed since the last ``make fasthtml`` command.
+
+Please also check the output to the console for any warnings or problems.  There will
 be multiple tests run automatically:
 
 - A test for correctness of all anchor labels and their references
@@ -246,6 +249,5 @@ manual with ``make spelling``.  This requires `a library called enchant
 positives* (e.g. keywords, names, abbreviations) those can be added to
 the file ``lammps/doc/utils/sphinx-config/false_positives.txt``.
 
-.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
-
 .. _lws: https://www.lammps.org
+.. _rst: https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html

doc/src/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>`
@@ -151,7 +150,7 @@ other files dependent on that package are also excluded.
 .. _cmake_presets:
 
 CMake presets for installing many packages
-""""""""""""""""""""""""""""""""""""""""""
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Instead of specifying all the CMake options via the command-line,
 CMake allows initializing its settings cache using script files.
@@ -179,6 +178,11 @@ one of them as a starting point and customize it to your needs.
     cmake -C ../cmake/presets/all_off.cmake  [OPTIONS] ../cmake  # disable all packages
     mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake  #  compile with MinGW cross compilers
 
+Presets that have names starting with "windows" are specifically for
+compiling LAMMPS :doc:`natively on Windows <Build_windows>` and
+presets that have names starting with "kokkos" are specifically for
+selecting configurations for compiling LAMMPS with :ref:`KOKKOS <kokkos>`.
+
 .. note::
 
    Running cmake this way manipulates the CMake settings cache in your
@@ -221,7 +225,8 @@ These commands install/un-install sets of packages:
 .. code-block:: bash
 
     make yes-all                        # install all packages
-    make no-all                         # uninstall all packages
+    make no-all                         # check for changes and uninstall all packages
+    make no-installed                   # only check and uninstall installed packages
     make yes-basic                      # install a few commonly used packages'
     make no-basic                       # remove a few commonly used packages'
     make yes-most                       # install most packages w/o libs'

doc/src/Build_settings.rst

@@ -4,15 +4,15 @@ Optional build settings
 LAMMPS can be built with several optional settings.  Each sub-section
 explain how to do this for building both with CMake and make.
 
-* :ref:`C++11 standard compliance <cxx11>` when building all of LAMMPS
-* :ref:`FFT library <fft>` for use with the :doc:`kspace_style pppm <kspace_style>` command
-* :ref:`Size of LAMMPS integer types <size>`
-* :ref:`Read or write compressed files <gzip>`
-* :ref:`Output of JPG and PNG files <graphics>` via the :doc:`dump image <dump_image>` command
-* :ref:`Output of movie files <graphics>` via the :doc:`dump_movie <dump_image>` command
-* :ref:`Memory allocation alignment <align>`
-* :ref:`Workaround for long long integers <longlong>`
-* :ref:`Error handling exceptions <exceptions>` when using LAMMPS as a library
+* `C++11 standard compliance`_ when building all of LAMMPS
+* `FFT library`_ for use with the :doc:`kspace_style pppm <kspace_style>` command
+* `Size of LAMMPS integer types and size limits`_
+* `Read or write compressed files`_
+* `Output of JPG, PNG, and move files` via the :doc:`dump image <dump_image>` or :doc:`dump movie <dump_image>` commands
+* `Memory allocation alignment`_
+* `Workaround for long long integers`_
+* `Exception handling when using LAMMPS as a library`_ to capture errors
+* `Trigger selected floating-point exceptions`_
 
 ----------
 
@@ -287,8 +287,8 @@ Output of JPG, PNG, and movie files
 
 The :doc:`dump image <dump_image>` command has options to output JPEG or
 PNG image files.  Likewise the :doc:`dump movie <dump_image>` command
-outputs movie files in MPEG format.  Using these options requires the
-following settings:
+outputs movie files in a variety of movie formats.  Using these options
+requires the following settings:
 
 .. tabs::
 
@@ -328,11 +328,12 @@ following settings:
          JPG_LIB = -ljpeg -lpng -lz       # library names
 
       As with CMake, you do not need to set ``JPG_INC`` or ``JPG_PATH``,
-      if make can find the graphics header and library files.  You must
-      specify ``JPG_LIB`` with a list of graphics libraries to include
-      in the link.  You must insure ffmpeg is in a directory where
-      LAMMPS can find it at runtime, that is a directory in your PATH
-      environment variable.
+      if make can find the graphics header and library files in their
+      default system locations.  You must specify ``JPG_LIB`` with a
+      list of graphics libraries to include in the link.  You must make
+      certain that the ffmpeg executable (or ffmpeg.exe on Windows) is
+      in a directory where LAMMPS can find it at runtime; that is
+      usually a directory list in your ``PATH`` environment variable.
 
 Using ``ffmpeg`` to output movie files requires that your machine
 supports the "popen" function in the standard runtime library.

doc/src/Build_windows.rst

@@ -5,6 +5,7 @@ Notes for building LAMMPS on Windows
 * :ref:`Running Linux on Windows <linux>`
 * :ref:`Using GNU GCC ported to Windows <gnu>`
 * :ref:`Using Visual Studio <msvc>`
+* :ref:`Using Intel oneAPI compilers and libraries <oneapi>`
 * :ref:`Using a cross-compiler <cross>`
 
 ----------
@@ -16,44 +17,54 @@ General remarks
 
 LAMMPS is developed and tested primarily on Linux machines.  The vast
 majority of HPC clusters and supercomputers today run on Linux as well.
-While portability to other platforms is desired, it is not always achieved.
-The LAMMPS developers are dependent on LAMMPS users giving feedback and
-providing assistance in resolving portability issues.  This is particularly
-true for compiling LAMMPS on Windows, since this platform has significant
-differences in some low-level functionality.
+While portability to other platforms is desired, it is not always
+achieved.  That is sometimes due to non-portable code in LAMMPS itself,
+but more often due to portability limitations of external libraries and
+tools required to build a specific feature or package.  The LAMMPS
+developers are dependent on LAMMPS users giving feedback and providing
+assistance in resolving portability issues.  This is particularly true
+for compiling LAMMPS on Windows, since this platform has significant
+differences in some low-level functionality.  As of LAMMPS version 14
+December 2021, large parts of LAMMPS can be compiled natively with the
+Microsoft Visual C++ Compilers.  As of LAMMPS version 31 May 2022, also
+the Intel oneAPI compilers can compile large parts of LAMMPS natively on
+Windows.  This is mostly facilitated by using the
+:doc:`Developer_platform` in the ``platform`` namespace and CMake.
+
+Before trying to build LAMMPS on Windows yourself, please consider the
+`pre-compiled Windows installer packages <https://packages.lammps.org/windows.html>`_
+and see if they are sufficient for your needs.
 
 .. _linux:
 
 Running Linux on Windows
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-Before trying to build LAMMPS on Windows, please consider if the
-pre-compiled Windows binary packages are sufficient for your needs.  If
-it is necessary for you to compile LAMMPS on a Windows machine
+If it is necessary for you to compile LAMMPS on a Windows machine
 (e.g. because it is your main desktop), please also consider using a
 virtual machine software and compile and run LAMMPS in a Linux virtual
 machine, or - if you have a sufficiently up-to-date Windows 10 or
 Windows 11 installation - consider using the Windows subsystem for
 Linux.  This optional Windows feature allows you to run the bash shell
-from Ubuntu from within Windows and from there on, you can pretty much
-use that shell like you are running on an Ubuntu Linux machine
-(e.g. installing software via apt-get and more).  For more details on
-that, please see :doc:`this tutorial <Howto_wsl>`.
+of a Linux system (Ubuntu by default) from within Windows and from there
+on, you can pretty much use that shell like you are running on a regular
+Ubuntu Linux machine (e.g. installing software via apt-get and more).
+For more details on that, please see :doc:`this tutorial <Howto_wsl>`.
 
 .. _gnu:
 
 Using a GNU GCC ported to Windows
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-One option for compiling LAMMPS on Windows natively that has been known
-to work in the past is to install a bash shell, unix shell utilities,
-perl, GNU make, and a GNU compiler ported to Windows.  The Cygwin
-package provides a unix/linux interface to low-level Windows functions,
-so LAMMPS can be compiled on Windows.  The necessary (minor)
-modifications to LAMMPS are included, but may not always up-to-date for
-recently added functionality and the corresponding new code.  A machine
-makefile for using cygwin for the old build system is provided. Using
-CMake for this mode of compilation is untested and not likely to work.
+One option for compiling LAMMPS on Windows natively is to install a Bash
+shell, Unix shell utilities, Perl, Python, GNU make, and a GNU compiler
+ported to Windows.  The Cygwin package provides a unix/linux interface
+to low-level Windows functions, so LAMMPS can be compiled on Windows.
+The necessary (minor) modifications to LAMMPS are included, but may not
+always up-to-date for recently added functionality and the corresponding
+new code.  A machine makefile for using cygwin for the old build system
+is provided.  Using CMake for this mode of compilation is untested and
+not likely to work.
 
 When compiling for Windows do **not** set the ``-DLAMMPS_MEMALIGN``
 define in the LMP_INC makefile variable and add ``-lwsock32 -lpsapi`` to
@@ -65,8 +76,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
-them as an issue or pull request on the LAMMPS GitHub project.
+yourself, please report them on the
+`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,32 +87,97 @@ Using Microsoft Visual Studio
 
 Following the integration of the :doc:`platform namespace
 <Developer_platform>` into the LAMMPS code base, portability of LAMMPS
-to be compiled on Windows using Visual Studio has been significantly
-improved.  This has been tested with Visual Studio 2019 (aka version
-16).  Not all features and packages in LAMMPS are currently supported
-out of the box, but a preset ``cmake/presets/windows.cmake`` is provided
-that contains the packages that have been compiled successfully.  You
-must use the CMake based build procedure, and either use the integrated
-CMake support of Visual Studio or use an external CMake installation to
-create build files for the Visual Studio build system.  Please note that
-on launching Visual Studio it will scan the directory tree and likely
-miss the correct master ``CMakeLists.txt``.  Try to open the
-``cmake/CMakeSettings.json`` and use those CMake configurations as a
-starting point.  It is also possible to configure and compile LAMMPS
-from the command line with a CMake binary from `cmake.org <https://cmake.org>`_.
+for native compilation on Windows using Visual Studio has been
+significantly improved.  This has been tested with Visual Studio 2019
+(aka version 16) and Visual Studio 2022 (aka version 17).  We strongly
+recommend using Visual Studio 2022 version 17.1 or later.  Not all
+features and packages in LAMMPS are currently supported out of the box,
+but a preset ``cmake/presets/windows.cmake`` is provided that contains
+the packages that have been compiled successfully so far.  You **must**
+use the CMake based build procedure, since there is no support for GNU
+make or the Unix shell utilities required for the GNU make build
+procedure.
+
+It is possible to use both the integrated CMake support of the Visual
+Studio IDE or use an external CMake installation (e.g. downloaded from
+cmake.org) to create build files and compile LAMMPS from the command line.
+
+Compilation via command line and unit tests are checked automatically
+for the LAMMPS development branch through
+`GitHub Actions <https://github.com/lammps/lammps/actions/workflows/compile-msvc.yml>`_.
+
+.. note::
+
+   Versions of Visual Studio before version 17.1 may scan the entire
+   LAMMPS source tree and likely miss the correct master
+   ``CMakeLists.txt`` and get confused since there are multiple files
+   of that name in different folders but none in top level folder.
 
 Please note, that for either approach CMake will create a so-called
 :ref:`"multi-configuration" build environment <cmake_multiconfig>`, and
 the command lines for building and testing LAMMPS must be adjusted
 accordingly.
 
+The LAMMPS cmake folder contains a ``CMakeSettings.json`` file with
+build configurations for MSVC compilers and the MS provided Clang
+compiler package in Debug and Release mode.
+
 To support running in parallel you can compile with OpenMP enabled using
 the OPENMP package or install Microsoft MPI (including the SDK) and compile
 LAMMPS with MPI enabled.
 
-This is work in progress and you should contact the LAMMPS developers
-via GitHub, the forum, or the mailing list, if you have questions or
-LAMMPS specific problems.
+.. note::
+
+   This is work in progress and you should contact the LAMMPS developers
+   via GitHub or the `LAMMPS forum at MatSci <https://matsci.org/c/lammps/lammps-development/>`_,
+   if you have questions or LAMMPS specific problems.
+
+.. _oneapi:
+
+Using Intel oneAPI Compilers and Libraries
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionadded:: 31May2022
+
+After installing the `Intel oneAPI
+<https://www.intel.com/content/www/us/en/developer/tools/oneapi/toolkits.html>`_
+base toolkit and the HPC toolkit, it is also possible to compile large
+parts of LAMMPS natively on Windows using Intel compilers.  The HPC
+toolkit provides two sets of C/C++ and Fortran compilers: the so-called
+"classic" compilers (``icl.exe`` and ``ifort.exe``) and newer, LLVM
+based compilers (``icx.exe`` and ``ifx.exe``).  In addition to the
+compilers and their dependent modules, also the thread building blocks
+(TBB) and the math kernel library (MKL) need to be installed.  Two
+presets (``cmake/presets/windows-intel-llvm.cmake`` and
+``cmake/presets/windows-intel-classic.cmake``) are provided for
+selecting the LLVM based or classic compilers, respectively. The preset
+``cmake/presets/windows.cmake`` enables compatible packages that are not
+dependent on additional features or libraries.  You **must** use the
+CMake based build procedure and use Ninja as build tool.  For compiling
+from the command prompt, thus both `CMake <https://cmake.org>`_ and
+`Ninja-build <https://ninja-build.org>`_ binaries must be installed.  It
+is also possible to use Visual Studio, if it is started (``devenv.exe``)
+from a command prompt that has the Intel oneAPI compilers enabled.  The
+Visual Studio settings file in the ``cmake`` folder contains
+configurations for both compiler variants in debug and release settings.
+Those will use the CMake and Ninja binaries bundled with Visual Studio,
+thus a separate installation is not required.
+
+.. admonition:: Known Limitations
+   :class: note
+
+   In addition to portability issues with several packages and external
+   libraries, the classic Intel compilers are currently not able to
+   compile the googletest libraries and thus enabling the ``-DENABLE_TESTING``
+   option will result in compilation failure.  The LLVM based compilers
+   are compatible.
+
+.. note::
+
+   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:
 
@@ -126,14 +203,3 @@ LAMMPS developers.  We instead rely on the feedback of the users
 of these pre-compiled LAMMPS packages for Windows.  We will try to resolve
 issues to the best of our abilities if we become aware of them. However
 this is subject to time constraints and focus on HPC platforms.
-
-.. _native:
-
-Native Visual C++ support
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Support for the Visual C++ compilers is currently not available. The
-CMake build system is capable of creating suitable a Visual Studio
-style build environment, but the LAMMPS source code itself is not
-ported to fully support Visual C++. Volunteers to take on this task
-are welcome.

doc/src/Commands.rst

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

doc/src/Commands_all.rst

@@ -10,11 +10,14 @@
    * :ref:`Dihedral styles <dihedral>`
    * :ref:`Improper styles <improper>`
    * :doc:`KSpace styles <Commands_kspace>`
+   * :doc:`Dump styles <Commands_dump>`
 
 General commands
 ================
 
-An alphabetic list of all general LAMMPS commands.
+An alphabetic list of general LAMMPS commands.  Note that style
+commands with many variants, can be more easily accessed via the small
+table above.
 
 .. table_from_list::
    :columns: 5
@@ -47,36 +50,27 @@ An alphabetic list of all general LAMMPS commands.
    * :doc:`displace_atoms <displace_atoms>`
    * :doc:`dump <dump>`
    * :doc:`dump_modify <dump_modify>`
-   * :doc:`dynamical_matrix (k) <dynamical_matrix>`
    * :doc:`echo <echo>`
    * :doc:`fix <fix>`
    * :doc:`fix_modify <fix_modify>`
    * :doc:`group <group>`
-   * :doc:`group2ndx <group2ndx>`
-   * :doc:`hyper <hyper>`
    * :doc:`if <if>`
    * :doc:`improper_coeff <improper_coeff>`
    * :doc:`improper_style <improper_style>`
    * :doc:`include <include>`
    * :doc:`info <info>`
    * :doc:`jump <jump>`
-   * :doc:`kim <kim_commands>`
    * :doc:`kspace_modify <kspace_modify>`
    * :doc:`kspace_style <kspace_style>`
    * :doc:`label <label>`
+   * :doc:`labelmap <labelmap>`
    * :doc:`lattice <lattice>`
    * :doc:`log <log>`
    * :doc:`mass <mass>`
-   * :doc:`mdi/engine <mdi_engine>`
-   * :doc:`message <message>`
    * :doc:`minimize <minimize>`
    * :doc:`min_modify <min_modify>`
    * :doc:`min_style <min_style>`
-   * :doc:`min_style spin <min_spin>`
    * :doc:`molecule <molecule>`
-   * :doc:`ndx2group <group2ndx>`
-   * :doc:`neb <neb>`
-   * :doc:`neb/spin <neb_spin>`
    * :doc:`neigh_modify <neigh_modify>`
    * :doc:`neighbor <neighbor>`
    * :doc:`newton <newton>`
@@ -87,11 +81,8 @@ An alphabetic list of all general LAMMPS commands.
    * :doc:`pair_style <pair_style>`
    * :doc:`pair_write <pair_write>`
    * :doc:`partition <partition>`
-   * :doc:`plugin <plugin>`
-   * :doc:`prd <prd>`
    * :doc:`print <print>`
    * :doc:`processors <processors>`
-   * :doc:`python <python>`
    * :doc:`quit <quit>`
    * :doc:`read_data <read_data>`
    * :doc:`read_dump <read_dump>`
@@ -105,19 +96,13 @@ 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>`
    * :doc:`suffix <suffix>`
-   * :doc:`tad <tad>`
-   * :doc:`temper <temper>`
-   * :doc:`temper/grem <temper_grem>`
-   * :doc:`temper/npt <temper_npt>`
    * :doc:`thermo <thermo>`
    * :doc:`thermo_modify <thermo_modify>`
    * :doc:`thermo_style <thermo_style>`
-   * :doc:`third_order (k) <third_order>`
    * :doc:`timer <timer>`
    * :doc:`timestep <timestep>`
    * :doc:`uncompute <uncompute>`
@@ -130,3 +115,27 @@ An alphabetic list of all general LAMMPS commands.
    * :doc:`write_data <write_data>`
    * :doc:`write_dump <write_dump>`
    * :doc:`write_restart <write_restart>`
+
+Additional general LAMMPS commands provided by packages.  A few
+commands have accelerated versions.  This is indicated by an
+additional letter in parenthesis: k = KOKKOS.
+
+.. table_from_list::
+   :columns: 5
+
+   * :doc:`dynamical_matrix (k) <dynamical_matrix>`
+   * :doc:`group2ndx <group2ndx>`
+   * :doc:`hyper <hyper>`
+   * :doc:`kim <kim_commands>`
+   * :doc:`mdi <mdi>`
+   * :doc:`ndx2group <group2ndx>`
+   * :doc:`neb <neb>`
+   * :doc:`neb/spin <neb_spin>`
+   * :doc:`plugin <plugin>`
+   * :doc:`prd <prd>`
+   * :doc:`python <python>`
+   * :doc:`tad <tad>`
+   * :doc:`temper <temper>`
+   * :doc:`temper/grem <temper_grem>`
+   * :doc:`temper/npt <temper_npt>`
+   * :doc:`third_order (k) <third_order>`

doc/src/Commands_bond.rst

@@ -10,6 +10,7 @@
    * :ref:`Dihedral styles <dihedral>`
    * :ref:`Improper styles <improper>`
    * :doc:`KSpace styles <Commands_kspace>`
+   * :doc:`Dump styles <Commands_dump>`
 
 .. _bond:
 
@@ -32,6 +33,8 @@ OPT.
    *
    *
    *
+   * :doc:`bpm/rotational <bond_bpm_rotational>`
+   * :doc:`bpm/spring <bond_bpm_spring>`
    * :doc:`class2 (ko) <bond_class2>`
    * :doc:`fene (iko) <bond_fene>`
    * :doc:`fene/expand (o) <bond_fene_expand>`
@@ -41,6 +44,7 @@ OPT.
    * :doc:`harmonic (iko) <bond_harmonic>`
    * :doc:`harmonic/shift (o) <bond_harmonic_shift>`
    * :doc:`harmonic/shift/cut (o) <bond_harmonic_shift_cut>`
+   * :doc:`mesocnt <bond_mesocnt>`
    * :doc:`mm3 <bond_mm3>`
    * :doc:`morse (o) <bond_morse>`
    * :doc:`nonlinear (o) <bond_nonlinear>`
@@ -72,6 +76,7 @@ OPT.
    *
    *
    *
+   * :doc:`amoeba <angle_amoeba>`
    * :doc:`charmm (iko) <angle_charmm>`
    * :doc:`class2 (ko) <angle_class2>`
    * :doc:`class2/p6 <angle_class2>`
@@ -86,11 +91,12 @@ OPT.
    * :doc:`dipole (o) <angle_dipole>`
    * :doc:`fourier (o) <angle_fourier>`
    * :doc:`fourier/simple (o) <angle_fourier_simple>`
-   * :doc:`gaussian <angle_gaussian>` - multicentered Gaussian-based angle potential
+   * :doc:`gaussian <angle_gaussian>`
    * :doc:`harmonic (iko) <angle_harmonic>`
+   * :doc:`mesocnt <angle_mesocnt>`
    * :doc:`mm3 <angle_mm3>`
    * :doc:`quartic (o) <angle_quartic>`
-   * :doc:`sdk (o) <angle_sdk>`
+   * :doc:`spica (o) <angle_spica>`
    * :doc:`table (o) <angle_table>`
 
 .. _dihedral:
@@ -150,6 +156,7 @@ OPT.
    *
    *
    *
+   * :doc:`amoeba <improper_amoeba>`
    * :doc:`class2 (ko) <improper_class2>`
    * :doc:`cossq (o) <improper_cossq>`
    * :doc:`cvff (io) <improper_cvff>`

doc/src/Commands_compute.rst

@@ -10,6 +10,7 @@
    * :ref:`Dihedral styles <dihedral>`
    * :ref:`Improper styles <improper>`
    * :doc:`KSpace styles <Commands_kspace>`
+   * :doc:`Dump styles <Commands_dump>`
 
 Compute commands
 ================
@@ -33,6 +34,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`body/local <compute_body_local>`
    * :doc:`bond <compute_bond>`
    * :doc:`bond/local <compute_bond_local>`
+   * :doc:`born/matrix <compute_born_matrix>`
    * :doc:`centro/atom <compute_centro_atom>`
    * :doc:`centroid/stress/atom <compute_stress_atom>`
    * :doc:`chunk/atom <compute_chunk_atom>`
@@ -63,6 +65,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>`
@@ -90,6 +93,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`msd <compute_msd>`
    * :doc:`msd/chunk <compute_msd_chunk>`
    * :doc:`msd/nongauss <compute_msd_nongauss>`
+   * :doc:`nbond/atom <compute_nbond_atom>`
    * :doc:`omega/chunk <compute_omega_chunk>`
    * :doc:`orientorder/atom (k) <compute_orientorder_atom>`
    * :doc:`pair <compute_pair>`
@@ -100,7 +104,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>`
@@ -136,6 +139,8 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`smd/vol <compute_smd_vol>`
    * :doc:`snap <compute_sna_atom>`
    * :doc:`sna/atom <compute_sna_atom>`
+   * :doc:`sna/grid <compute_sna_atom>`
+   * :doc:`sna/grid/local <compute_sna_atom>`
    * :doc:`snad/atom <compute_sna_atom>`
    * :doc:`snav/atom <compute_sna_atom>`
    * :doc:`sph/e/atom <compute_sph_e_atom>`
@@ -143,8 +148,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_dump.rst

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

doc/src/Commands_fix.rst

@@ -10,6 +10,7 @@
    * :ref:`Dihedral styles <dihedral>`
    * :ref:`Improper styles <improper>`
    * :doc:`KSpace styles <Commands_kspace>`
+   * :doc:`Dump styles <Commands_dump>`
 
 Fix commands
 ============
@@ -28,6 +29,8 @@ OPT.
    * :doc:`adapt/fep <fix_adapt_fep>`
    * :doc:`addforce <fix_addforce>`
    * :doc:`addtorque <fix_addtorque>`
+   * :doc:`amoeba/bitorsion <fix_amoeba_bitorsion>`
+   * :doc:`amoeba/pitorsion <fix_amoeba_pitorsion>`
    * :doc:`append/atoms <fix_append_atoms>`
    * :doc:`atc <fix_atc>`
    * :doc:`atom/swap <fix_atom_swap>`
@@ -51,10 +54,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>`
@@ -66,6 +69,9 @@ OPT.
    * :doc:`edpd/source <fix_dpd_source>`
    * :doc:`efield <fix_efield>`
    * :doc:`ehex <fix_ehex>`
+   * :doc:`electrode/conp (i) <fix_electrode_conp>`
+   * :doc:`electrode/conq (i) <fix_electrode_conp>`
+   * :doc:`electrode/thermo (i) <fix_electrode_conp>`
    * :doc:`electron/stopping <fix_electron_stopping>`
    * :doc:`electron/stopping/fit <fix_electron_stopping>`
    * :doc:`enforce2d (k) <fix_enforce2d>`
@@ -97,12 +103,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/qm <fix_mdi_qm>`
    * :doc:`meso/move <fix_meso_move>`
    * :doc:`mol/swap <fix_mol_swap>`
    * :doc:`momentum (k) <fix_momentum>`
@@ -143,6 +147,7 @@ OPT.
    * :doc:`nve/manifold/rattle <fix_nve_manifold_rattle>`
    * :doc:`nve/noforce <fix_nve_noforce>`
    * :doc:`nve/sphere (ko) <fix_nve_sphere>`
+   * :doc:`nve/bpm/sphere <fix_nve_bpm_sphere>`
    * :doc:`nve/spin <fix_nve_spin>`
    * :doc:`nve/tri <fix_nve_tri>`
    * :doc:`nvk <fix_nvk>`
@@ -160,7 +165,7 @@ OPT.
    * :doc:`orient/fcc <fix_orient>`
    * :doc:`orient/eco <fix_orient_eco>`
    * :doc:`pafi <fix_pafi>`
-   * :doc:`pair/tracker <fix_pair_tracker>`
+   * :doc:`pair <fix_pair>`
    * :doc:`phonon <fix_phonon>`
    * :doc:`pimd <fix_pimd>`
    * :doc:`planeforce <fix_planeforce>`
@@ -245,6 +250,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_kspace.rst

@@ -10,6 +10,7 @@
    * :ref:`Dihedral styles <dihedral>`
    * :ref:`Improper styles <improper>`
    * :doc:`KSpace styles <Commands_kspace>`
+   * :doc:`Dump styles <Commands_dump>`
 
 KSpace solvers
 ==============
@@ -27,6 +28,7 @@ OPT.
    * :doc:`ewald/disp/dipole <kspace_style>`
    * :doc:`ewald/dipole <kspace_style>`
    * :doc:`ewald/dipole/spin <kspace_style>`
+   * :doc:`ewald/electrode <kspace_style>`
    * :doc:`msm (o) <kspace_style>`
    * :doc:`msm/cg (o) <kspace_style>`
    * :doc:`msm/dielectric <kspace_style>`
@@ -41,4 +43,5 @@ OPT.
    * :doc:`pppm/stagger <kspace_style>`
    * :doc:`pppm/tip4p (o) <kspace_style>`
    * :doc:`pppm/dielectric <kspace_style>`
+   * :doc:`pppm/electrode (i) <kspace_style>`
    * :doc:`scafacos <kspace_style>`

doc/src/Commands_pair.rst

@@ -10,6 +10,7 @@
    * :ref:`Dihedral styles <dihedral>`
    * :ref:`Improper styles <improper>`
    * :doc:`KSpace styles <Commands_kspace>`
+   * :doc:`Dump styles <Commands_dump>`
 
 Pair_style potentials
 ======================
@@ -34,10 +35,11 @@ OPT.
    *
    *
    *
-   * :doc:`adp (o) <pair_adp>`
+   * :doc:`adp (ko) <pair_adp>`
    * :doc:`agni (o) <pair_agni>`
    * :doc:`airebo (io) <pair_airebo>`
    * :doc:`airebo/morse (io) <pair_airebo>`
+   * :doc:`amoeba <pair_amoeba>`
    * :doc:`atm <pair_atm>`
    * :doc:`awpmd/cut <pair_awpmd>`
    * :doc:`beck (go) <pair_beck>`
@@ -53,6 +55,7 @@ OPT.
    * :doc:`born/coul/msm (o) <pair_born>`
    * :doc:`born/coul/wolf (go) <pair_born>`
    * :doc:`born/coul/wolf/cs (g) <pair_cs>`
+   * :doc:`bpm/spring <pair_bpm_spring>`
    * :doc:`brownian (o) <pair_brownian>`
    * :doc:`brownian/poly (o) <pair_brownian>`
    * :doc:`buck (giko) <pair_buck>`
@@ -88,12 +91,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/tstat <pair_dpd_ext>`
+   * :doc:`dpd/ext (k) <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>`
@@ -123,8 +126,9 @@ OPT.
    * :doc:`hbond/dreiding/lj (o) <pair_hbond_dreiding>`
    * :doc:`hbond/dreiding/morse (o) <pair_hbond_dreiding>`
    * :doc:`hdnnp <pair_hdnnp>`
-   * :doc:`ilp/graphene/hbn <pair_ilp_graphene_hbn>`
-   * :doc:`ilp/tmd <pair_ilp_tmd>`
+   * :doc:`hippo <pair_amoeba>`
+   * :doc:`ilp/graphene/hbn (t) <pair_ilp_graphene_hbn>`
+   * :doc:`ilp/tmd (t) <pair_ilp_tmd>`
    * :doc:`kolmogorov/crespi/full <pair_kolmogorov_crespi_full>`
    * :doc:`kolmogorov/crespi/z <pair_kolmogorov_crespi_z>`
    * :doc:`lcbop <pair_lcbop>`
@@ -151,7 +155,7 @@ OPT.
    * :doc:`lj/cut/coul/cut/dielectric (o) <pair_dielectric>`
    * :doc:`lj/cut/coul/cut/soft (o) <pair_fep_soft>`
    * :doc:`lj/cut/coul/debye (gko) <pair_lj_cut_coul>`
-   * :doc:`lj/cut/coul/debye/dielectric <pair_dielectric>`
+   * :doc:`lj/cut/coul/debye/dielectric (o) <pair_dielectric>`
    * :doc:`lj/cut/coul/dsf (gko) <pair_lj_cut_coul>`
    * :doc:`lj/cut/coul/long (gikot) <pair_lj_cut_coul>`
    * :doc:`lj/cut/coul/long/cs <pair_cs>`
@@ -178,9 +182,9 @@ OPT.
    * :doc:`lj/long/tip4p/long (o) <pair_lj_long>`
    * :doc:`lj/mdf <pair_mdf>`
    * :doc:`lj/relres (o) <pair_lj_relres>`
-   * :doc:`lj/sdk (gko) <pair_sdk>`
-   * :doc:`lj/sdk/coul/long (go) <pair_sdk>`
-   * :doc:`lj/sdk/coul/msm (o) <pair_sdk>`
+   * :doc:`lj/spica (gko) <pair_spica>`
+   * :doc:`lj/spica/coul/long (go) <pair_spica>`
+   * :doc:`lj/spica/coul/msm (o) <pair_spica>`
    * :doc:`lj/sf/dipole/sf (go) <pair_dipole>`
    * :doc:`lj/smooth (go) <pair_lj_smooth>`
    * :doc:`lj/smooth/linear (o) <pair_lj_smooth_linear>`
@@ -193,10 +197,11 @@ OPT.
    * :doc:`lubricateU/poly <pair_lubricateU>`
    * :doc:`mdpd <pair_mesodpd>`
    * :doc:`mdpd/rhosum <pair_mesodpd>`
-   * :doc:`meam <pair_meam>`
+   * :doc:`meam (k) <pair_meam>`
    * :doc:`meam/spline (o) <pair_meam_spline>`
    * :doc:`meam/sw/spline <pair_meam_sw_spline>`
    * :doc:`mesocnt <pair_mesocnt>`
+   * :doc:`mesocnt/viscous <pair_mesocnt>`
    * :doc:`mesont/tpm <pair_mesont_tpm>`
    * :doc:`mgpt <pair_mgpt>`
    * :doc:`mie/cut (g) <pair_mie>`
@@ -230,7 +235,7 @@ OPT.
    * :doc:`oxrna2/stk <pair_oxrna2>`
    * :doc:`oxrna2/xstk <pair_oxrna2>`
    * :doc:`oxrna2/coaxstk <pair_oxrna2>`
-   * :doc:`pace <pair_pace>`
+   * :doc:`pace (k) <pair_pace>`
    * :doc:`peri/eps <pair_peri>`
    * :doc:`peri/lps (o) <pair_peri>`
    * :doc:`peri/pmb (o) <pair_peri>`
@@ -242,8 +247,10 @@ OPT.
    * :doc:`reaxff (ko) <pair_reaxff>`
    * :doc:`rebo (io) <pair_airebo>`
    * :doc:`resquared (go) <pair_resquared>`
-   * :doc:`saip/metal <pair_saip_metal>`
+   * :doc:`saip/metal (t) <pair_saip_metal>`
    * :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>`
+   * :doc:`smatb <pair_smatb>`
+   * :doc:`smatb/single <pair_smatb>`
    * :doc:`smd/hertz <pair_smd_hertz>`
    * :doc:`smd/tlsph <pair_smd_tlsph>`
    * :doc:`smd/tri_surface <pair_smd_triangulated_surface>`
@@ -265,7 +272,9 @@ OPT.
    * :doc:`spin/magelec <pair_spin_magelec>`
    * :doc:`spin/neel <pair_spin_neel>`
    * :doc:`srp <pair_srp>`
+   * :doc:`srp/react <pair_srp>`
    * :doc:`sw (giko) <pair_sw>`
+   * :doc:`sw/angle/table <pair_sw_angle_table>`
    * :doc:`sw/mod (o) <pair_sw>`
    * :doc:`table (gko) <pair_table>`
    * :doc:`table/rx (k) <pair_table_rx>`
@@ -276,6 +285,7 @@ OPT.
    * :doc:`tersoff/table (o) <pair_tersoff>`
    * :doc:`tersoff/zbl (gko) <pair_tersoff_zbl>`
    * :doc:`thole <pair_thole>`
+   * :doc:`threebody/table <pair_threebody_table>`
    * :doc:`tip4p/cut (o) <pair_coul>`
    * :doc:`tip4p/long (o) <pair_coul>`
    * :doc:`tip4p/long/soft (o) <pair_fep_soft>`

doc/src/Commands_parse.rst

@@ -77,18 +77,19 @@ LAMMPS:
    so that you do not have to define (or discard) a temporary variable,
    "X" in this case.
 
-   Additionally, the "immediate" variable expression may be followed by
-   a colon, followed by a C-style format string, e.g. ":%f" or ":%.10g".
-   The format string must be appropriate for a double-precision
-   floating-point value.  The format string is used to output the result
-   of the variable expression evaluation.  If a format string is not
-   specified a high-precision "%.20g" is used as the default.
+   Additionally, the entire "immediate" variable expression may be
+   followed by a colon, followed by a C-style format string,
+   e.g. ":%f" or ":%.10g".  The format string must be appropriate for
+   a double-precision floating-point value.  The format string is used
+   to output the result of the variable expression evaluation.  If a
+   format string is not specified, a high-precision "%.20g" is used as
+   the default format.
 
    This can be useful for formatting print output to a desired precision:
 
    .. code-block:: LAMMPS
 
-      print "Final energy per atom: $(pe/atoms:%10.3f) eV/atom"
+      print "Final energy per atom: $(v_ke_per_atom+v_pe_per_atom:%10.3f) eV/atom"
 
    Note that neither the curly-bracket or immediate form of variables
    can contain nested $ characters for other variables to substitute
@@ -122,14 +123,15 @@ LAMMPS:
 .. _six:
 
 6. If you want text with spaces to be treated as a single argument, it
-   can be enclosed in either single or double or triple quotes.  A long
-   single argument enclosed in single or double quotes can span multiple
-   lines if the "&" character is used, as described above.  When the
-   lines are concatenated together (and the "&" characters and line
-   breaks removed), the text will become a single line.  If you want
-   multiple lines of an argument to retain their line breaks, the text
-   can be enclosed in triple quotes, in which case "&" characters are
-   not needed.  For example:
+   can be enclosed in either single (') or double (") or triple (""")
+   quotes.  A long single argument enclosed in single or double quotes
+   can span multiple lines if the "&" character is used, as described
+   in :ref:`1 <one>` above.  When the lines are concatenated together
+   by LAMMPS (and the "&" characters and line breaks removed), the
+   combined text will become a single line.  If you want multiple lines
+   of an argument to retain their line breaks, the text can be enclosed
+   in triple quotes, in which case "&" characters are not needed and do
+   not function as line continuation character.  For example:
 
    .. code-block:: LAMMPS
 
@@ -143,8 +145,9 @@ LAMMPS:
       System temperature = $t
       """
 
-   In each case, the single, double, or triple quotes are removed when
-   the single argument they enclose is stored internally.
+   In each of these cases, the single, double, or triple quotes are
+   removed and the enclosed text stored internally as a single
+   argument.
 
    See the :doc:`dump modify format <dump_modify>`, :doc:`print
    <print>`, :doc:`if <if>`, and :doc:`python <python>` commands for

doc/src/Developer.rst

@@ -11,11 +11,13 @@ of time and requests from the LAMMPS user community.
    :maxdepth: 1
 
    Developer_org
-   Developer_cxx_vs_c_style
+   Developer_code_design
    Developer_parallel
+   Developer_comm_ops
    Developer_flow
    Developer_write
    Developer_notes
+   Developer_updating
    Developer_plugins
    Developer_unittest
    Classes

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

@@ -1,384 +0,0 @@
-Code design
------------
-
-This section discusses some of the code design choices in LAMMPS and
-overall strategy in order to assist developers to write new code that
-will fit well with the remaining 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 to discuss of some relevant C++ programming
-language constructs.
-
-Historically, the basic design philosophy of the LAMMPS C++ code was
-that of a "C with classes" style.  The was motivated by the desire to
-make it easier to modify LAMMPS for people without significant training
-in C++ programming and by trying to use data structures and code constructs
-that somewhat resemble the previous implementation(s) in Fortran.
-A contributing factor for this choice also was that at the time the
-implementation of C++ compilers was not always very mature and some of
-the advanced features contained bugs or were not functioning exactly
-as the standard required; plus there was some disagreement between
-compiler vendors about how to interpret the C++ standard documents.
-
-However, C++ compilers have advanced a lot since then and with the
-transition to requiring the C++11 standard in 2020 as the minimum C++ language
-standard for LAMMPS, the decision was made to also replace some of the
-C-style constructs with equivalent C++ functionality, either from the
-C++ standard library or as custom classes or function, 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 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 during compilation
-   is not subject to the conventions discussed here.
-
-Object oriented code
-^^^^^^^^^^^^^^^^^^^^
-
-LAMMPS is designed to be an object oriented code, that is each
-simulation is represented by an instance of the LAMMPS class.  When
-running in parallel, of course, each MPI process will create 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 tells the LAMMPS instance to process the input (either from
-standard input or the provided input file) until the end.  And the third
-line deletes that instance again.  The remainder of the main.cpp file
-are for error handling, MPI configuration and other special features.
-
-In the constructor of the LAMMPS class instance the basic LAMMPS class hierarchy
-is created as shown in :ref:`class-topology`.  While processing the input further
-class instances are created, or deleted, or replaced and specific member functions
-of specific classes are called to trigger actions like creating atoms, computing
-forces, computing properties, 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 a composite again containing instances
-of classes describing the force interactions or ``Modify`` containing
-and calling fixes and computes.  In most cases (e.g. ``AtomVec``, ``Comm``,
-``Pair``, or ``Bond``) there is only one instance of those member classes
-allowed, but in a few cases (e.g. ``Region``, ``Fix``, ``Compute``, or
-``Dump``) there can be multiple instances and the parent class is
-maintaining a list of the pointers of instantiated classes instead
-of a single pointer.
-
-Changing behavior or adjusting how LAMMPS handles a simulation is
-implemented via **inheritance** where different variants of the
-functionality are realized by creating *derived* classes that can share
-common functionality in their base class and provide a consistent
-interface where 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 the LAMMPS documentation those
-derived classes are usually referred to a "styles", e.g.  pair styles,
-fix styles, atom styles and so on.
-
-This is the origin of the flexibility of LAMMPS and facilitates for
-example to compute forces for very different non-bonded potential
-functions by having different pair styles (implemented as different
-classes derived from the ``Pair`` class) where the evaluation of the
-potential function is confined to the implementation of the individual
-classes.  Whenever a new :doc:`pair_style` or :doc:`bond_style` or
-:doc:`comm_style` or similar command is processed in the LAMMPS input
-any existing class instance is deleted and a new instance created in
-it place.
-
-Classes derived from ``Fix`` or ``Compute`` represent a different facet
-of LAMMPS' flexibility as there can be multiple instances of them an
-their member functions will be called at different phases of the time
-integration process (as explained in `Developer_flow`).  This way
-multiple manipulations of the entire or parts of the system can be
-programmed (with fix styles) or different computations can be performed
-and accessed and further processed or output through a common interface
-(with compute styles).
-
-Further code sharing is possible by creating derived classes from the
-derived classes (for instance to implement an accelerated version of a
-pair style) where then only a subset of the methods are replaced with
-the accelerated versions.
-
-Polymorphism
-============
-
-Polymorphism and dynamic dispatch are another OOP feature that play an
-important part of how LAMMPS selects which 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 be using 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 in which of the two member functions is called when
-executing `base1->call()` and `base2->call()`.  Without polymorphism, a
-function within the base class will call only member functions within
-the same scope, that is ``Base::call()`` will always call
-``Base::normal()``.  But for the `base2->call()` the call for the
-virtual member function will be dispatched to ``Derived::poly()``
-instead.  This mechanism allows to always call functions within the
-scope of the class type that was used to create the class instance, even
-if they are assigned to a pointer using the type of a base class. This
-is the desired behavior, and thanks to dynamic dispatch, 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 it will no longer be possible to create an
-instance of the base class and that derived classes **must** implement
-these functions.  Many of the functions listed with the various class
-styles in the section :doc:`Modify` are such pure functions.  The
-motivation for this is to define the interface or API of the functions
-but defer the 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 like in ``Base::poly()``.  Furthermore,
-any destructors in classes containing virtual functions should be
-declared virtual, too, so they are processed in the expected order
-before types are removed from dynamic dispatch.
-
-.. admonition:: Important Notes
-
-   In order to be able to detect incompatibilities and to avoid unexpected
-   behavior already at compile time, 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 it should be avoided to use overloads
-   or default arguments for virtual functions 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 of the 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 in which function pointers are indexed by their keyword
-(for example "lj/cut" for ``PairLJCut`` and "morse" ``PairMorse``).
-A couple of typedefs help to keep the code readable and a template function
-is used to implement the actual factory functions for the individual classes.
-
-I/O and output formatting
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-C-style stdio versus C++ style iostreams
-========================================
-
-LAMMPS chooses to use 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 the better performance, better
-control over formatting, and less effort to achieve specific formatting.
-
-Since mixing "stdio" and "iostreams" can lead to unexpected behavior using
-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 only be done by MPI rank 0 (``comm->me == 0``) and output that is
-send to both ``screen`` and ``logfile`` should use the
-:cpp:func:`utils::logmesg() convenience function <LAMMPS_NS::utils::logmesg>`.
-
-We also discourage the use for stringstreams as the bundled {fmt} library
-and the customized tokenizer classes can provide the same functionality
-in a cleaner way with better performance. This will also help to retain
-a consistent programming style despite the 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 that 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 ``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. Alternatively
-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 arguments 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 the 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
-
-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 data and objects should be done with either the
-C++ commands "new" and "delete/delete[]" or using member functions of
-the ``Memory`` class, most commonly, ``Memory::create()``,
-``Memory::grow()``, and ``Memory::destroy()``.  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.
-
-Using those 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 consecutive block and thus when MPI communication is needed,
-  only this storage needs to be communicated (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 would be safe to call ``Memory::destroy()``
-or ``delete[]`` on them before *any* allocation outside the constructor.
-This helps to prevent memory leaks.

doc/src/Developer_notes.rst

@@ -7,13 +7,22 @@ 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, most commonly potential parameters from a potential
-file for manybody potentials.  LAMMPS provides several custom classes
-and convenience functions to simplify the process.  This offers the
+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
@@ -23,7 +32,7 @@ following benefits:
   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)
+  (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
@@ -31,16 +40,17 @@ ranks.  Then it is best to do the reading and parsing only on MPI rank
 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. Those classes allow to read 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 `File reader classes <file-reader-classes>`_ contains
-an example for a typical case.
+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 in the file usually needs 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()
+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".
@@ -49,19 +59,163 @@ 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 of 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
+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
-an initialization function with a specific name, "lammpsplugin_init", that
-has to follow specific rules described below.  When loading the DSO with
-the "plugin" command, this function is looked up and called and will then
-register the contained plugin(s) with LAMMPS.
+specific functions in those DSOs.  Any DSO file with plugins has to
+include an initialization function with a specific name,
+"lammpsplugin_init", that has to follow specific rules described below.
+When loading the DSO with the "plugin" command, this function is looked
+up and called and will then register the contained plugin(s) with
+LAMMPS.
+
+When the environment variable ``LAMMPS_PLUGIN_PATH`` is set, then LAMMPS
+will search the directory (or directories) listed in this path for files
+with names that end in ``plugin.so`` (e.g. ``helloplugin.so``) and will
+try to load the contained plugins automatically at start-up.  For
+plugins that are loaded this way, the behavior of LAMMPS should be
+identical to a binary where the corresponding code was compiled in
+statically as a package.
 
 From the programmer perspective this can work because of the object
 oriented design of LAMMPS where all pair style commands are derived from
@@ -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
-and which of those is determined by the style of plugin. The
-"creator.v1" element is for factory functions of supported styles
-computing forces (i.e.  command, pair, bond, angle, dihedral, or
-improper styles) and the function takes as single argument the pointer
-to the LAMMPS instance. The factory function is cast to the
-``lammpsplugin_factory1`` type before assignment.  The "creator.v2"
-element is for factory functions creating an instance of a fix, compute,
-or region style and takes three arguments: a pointer to the LAMMPS
-instance, an integer with the length of the argument list and a ``char
-**`` pointer to the list of arguments. The factory function pointer
-needs to be cast to the ``lammpsplugin_factory2`` type before
-assignment.
+Only one of the two alternate creator entries can be used at a time and
+which of those is determined by the style of plugin. The "creator.v1"
+element is for factory functions of supported styles computing forces
+(i.e. pair, bond, angle, dihedral, or improper styles) or command styles
+and the function takes as single argument the pointer to the LAMMPS
+instance. The factory function is cast to the ``lammpsplugin_factory1``
+type before assignment.  The "creator.v2" element is for factory
+functions creating an instance of a fix, compute, or region style and
+takes three arguments: a pointer to the LAMMPS instance, an integer with
+the length of the argument list and a ``char **`` pointer to the list of
+arguments. The factory function pointer needs to be cast to the
+``lammpsplugin_factory2`` type before assignment.
 
 Pair style example
 ^^^^^^^^^^^^^^^^^^
@@ -249,3 +257,46 @@ 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.
+
+A second example for a plugin from a package is in the
+``examples/PACKAGES/pace/plugin`` folder that will create a plugin from
+the ML-PACE package.  In this case the bulk of the code is in a static
+external library that is being downloaded and compiled first and then
+combined with the pair style wrapper and the plugin loader.  This
+example also contains a NSIS script that can be used to create an
+Installer package for Windows (the mutual licensing terms of the
+external library and LAMMPS conflict when distributing binaries, so the
+ML-PACE package cannot be linked statically, but the LAMMPS headers
+required to build the plugin are also available under a less restrictive
+license).  This will automatically set the required environment variable
+and launching a (compatible) LAMMPS binary will load and register the
+plugin and the ML-PACE package can then be used as it was linked into
+LAMMPS.

doc/src/Developer_updating.rst

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

doc/src/Developer_utils.rst

@@ -133,6 +133,9 @@ and parsing files or arguments.
 .. doxygenfunction:: trim_comment
    :project: progguide
 
+.. doxygenfunction:: star_subst
+   :project: progguide
+
 .. doxygenfunction:: has_utf8
    :project: progguide
 
@@ -151,6 +154,9 @@ and parsing files or arguments.
 .. doxygenfunction:: trim_and_count_words
    :project: progguide
 
+.. doxygenfunction:: join_words
+   :project: progguide
+
 .. doxygenfunction:: split_words
    :project: progguide
 
@@ -169,6 +175,12 @@ and parsing files or arguments.
 .. doxygenfunction:: is_double
    :project: progguide
 
+.. doxygenfunction:: is_id
+   :project: progguide
+
+.. doxygenfunction:: is_type
+   :project: progguide
+
 Potential file functions
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -199,15 +211,24 @@ Argument processing
 .. doxygenfunction:: expand_args
    :project: progguide
 
+.. doxygenfunction:: expand_type
+   :project: progguide
+
 Convenience functions
 ^^^^^^^^^^^^^^^^^^^^^
 
-.. doxygenfunction:: logmesg(LAMMPS *lmp, const S &format, Args&&... args)
+.. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &format, Args&&... args)
    :project: progguide
 
 .. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &mesg)
    :project: progguide
 
+.. doxygenfunction:: errorurl
+   :project: progguide
+
+.. doxygenfunction:: missing_cmd_args
+   :project: progguide
+
 .. doxygenfunction:: flush_buffers(LAMMPS *lmp)
    :project: progguide
 
@@ -237,6 +258,44 @@ Customized standard functions
 
 ---------------------------
 
+Special Math functions
+----------------------
+
+The ``MathSpecial`` namespace implements a selection of custom and optimized
+mathematical functions for a variety of applications.
+
+.. doxygenfunction:: factorial
+   :project: progguide
+
+.. doxygenfunction:: exp2_x86
+   :project: progguide
+
+.. doxygenfunction:: fm_exp
+   :project: progguide
+
+.. doxygenfunction:: my_erfcx
+   :project: progguide
+
+.. doxygenfunction:: expmsq
+   :project: progguide
+
+.. doxygenfunction:: square
+   :project: progguide
+
+.. doxygenfunction:: cube
+   :project: progguide
+
+.. doxygenfunction:: powsign
+   :project: progguide
+
+.. doxygenfunction:: powint
+   :project: progguide
+
+.. doxygenfunction:: powsinxx
+   :project: progguide
+
+---------------------------
+
 Tokenizer classes
 -----------------
 
@@ -396,7 +455,7 @@ A typical code segment would look like this:
 
 ----------
 
-.. file-reader-classes:
+.. _file-reader-classes:
 
 File reader classes
 -------------------

doc/src/Errors.rst

@@ -11,6 +11,7 @@ them.
    :maxdepth: 1
 
    Errors_common
+   Errors_details
    Errors_bugs
    Errors_debug
    Errors_messages

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
-   the `LAMMPS forum <https://www.lammps.org/forum.html>`_ to see if the
-   issue has been discussed before.
+ * Check the `LAMMPS forum at MatSci <https://matsci.org/lammps/>`_
+   to see if the 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
-"lammps-users at lists.sourceforge.net" describing the problem with the
-same kind of information.  The mailing list can provide a faster response,
-especially if the bug reported is actually expected behavior.  But because
-of the high volume of the mailing list, it can happen that your e-mail
-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.
+You may also post a message in the `development category of the LAMMPS
+forum at MatSci <https://matsci.org/c/lammps/lammps-development/>`_
+describing the problem with the same kind of information.  The forum can
+provide a faster response, especially if the bug reported is actually
+expected behavior or other LAMMPS users have come across it before.
 

doc/src/Errors_details.rst

@@ -0,0 +1,27 @@
+Error and warning details
+=========================
+
+Many errors or warnings are self-explanatory and thus straightforward to
+resolve.  However, there are also cases, where there is no single cause
+and explanation, where LAMMPS can only detect symptoms of an error but
+not the exact cause, or where the explanation needs to be more detailed than
+what can be fit into a message printed by the program.  The following are
+discussions of such cases.
+
+.. _err0001:
+
+Unknown identifier in data file
+-------------------------------
+
+This error happens when LAMMPS encounters a line of text in an unexpected format
+while reading a data file. This is most commonly cause by inconsistent header and
+section data.  The header section informs LAMMPS how many entries or lines are expected in the
+various sections (like Atoms, Masses, Pair Coeffs, *etc.*\ ) of the data file.
+If there is a mismatch, LAMMPS will either keep reading beyond the end of a section
+or stop reading before the section has ended.
+
+Such a mismatch can happen unexpectedly when the first line of the data
+is *not* a comment as required by the format.  That would result in
+LAMMPS expecting, for instance, 0 atoms because the "atoms" header line
+is treated as a comment.
+

doc/src/Errors_messages.rst

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

doc/src/Errors_warnings.rst

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

doc/src/Examples.rst

@@ -54,6 +54,8 @@ Lowercase directories
 +-------------+------------------------------------------------------------------+
 | body        | body particles, 2d system                                        |
 +-------------+------------------------------------------------------------------+
+| bpm         | BPM simulations of pouring elastic grains and plate impact       |
++-------------+------------------------------------------------------------------+
 | cmap        | CMAP 5-body contributions to CHARMM force field                  |
 +-------------+------------------------------------------------------------------+
 | colloid     | big colloid particles in a small particle solvent, 2d system     |
@@ -94,12 +96,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/Fortran.rst

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

doc/src/Howto.rst

@@ -22,8 +22,9 @@ General howto
    Howto_replica
    Howto_library
    Howto_couple
-   Howto_client_server
    Howto_mdi
+   Howto_bpm
+   Howto_broken_bonds
 
 Settings howto
 ==============
@@ -33,6 +34,7 @@ Settings howto
    :maxdepth: 1
 
    Howto_2d
+   Howto_type_labels
    Howto_triclinic
    Howto_thermostat
    Howto_barostat
@@ -64,6 +66,7 @@ Force fields howto
    :maxdepth: 1
 
    Howto_bioFF
+   Howto_amoeba
    Howto_tip3p
    Howto_tip4p
    Howto_spc

doc/src/Howto_amoeba.rst

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

doc/src/Howto_body.rst

@@ -239,7 +239,7 @@ is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz iyz =
 
 .. parsed-literal::
 
-   3 1 27
+   3 1 19
    4
    1 1 4 0 0 0
    -0.7071 -0.7071 0

doc/src/Howto_bpm.rst

@@ -0,0 +1,119 @@
+Bonded particle models
+======================
+
+The BPM package implements bonded particle models which can be used to
+simulate mesoscale solids.  Solids are constructed as a collection of
+particles which each represent a coarse-grained region of space much
+larger than the atomistic scale. Particles within a solid region are
+then connected by a network of bonds to provide solid elasticity.
+
+Unlike traditional bonds in molecular dynamics, the equilibrium bond
+length can vary between bonds. Bonds store the reference state.  This
+includes setting the equilibrium length equal to the initial distance
+between the two particles but can also include data on the bond
+orientation for rotational models. This produces a stress free initial
+state. Furthermore, bonds are allowed to break under large strains
+producing fracture. The examples/bpm directory has sample input scripts
+for simulations of the fragmentation of an impacted plate and the
+pouring of extended, elastic bodies.
+
+----------
+
+Bonds can be created using a :doc:`read data <read_data>` or
+:doc:`create bonds <create_bonds>` command. Alternatively, a
+:doc:`molecule <molecule>` template with bonds can be used with
+:doc:`fix deposit <fix_deposit>` or :doc:`fix pour <fix_pour>` to
+create solid grains.
+
+In this implementation, bonds store their reference state when they are
+first computed in the setup of the first simulation run. Data is then
+preserved across run commands and is written to :doc:`binary restart
+files <restart>` such that restarting the system will not reset the
+reference state of a bond. Bonds that are created midway into a run,
+such as those created by pouring grains using :doc:`fix pour
+<fix_pour>`, are initialized on that timestep.
+
+As bonds can be broken between neighbor list builds, the
+:doc:`special_bonds <special_bonds>` command works differently for BPM
+bond styles. There are two possible settings which determine how pair
+interactions work between bonded particles.  First, one can turn off
+all pair interactions between bonded particles.  Unlike :doc:`bond
+quartic <bond_quartic>`, this is not done by subtracting pair forces
+during the bond computation but rather by dynamically updating the
+special bond list. This is the default behavior of BPM bond styles and
+is done by updating the 1-2 special bond list as bonds break.  To do
+this, LAMMPS requires :doc:`newton <newton>` bond off such that all
+processors containing an atom know when a bond breaks. Additionally,
+one must do either (A) or (B).
+
+A) Use the following special bond settings
+
+   .. code-block:: LAMMPS
+
+      special_bonds lj 0 1 1 coul 1 1 1
+
+   These settings accomplish two goals. First, they turn off 1-3 and 1-4
+   special bond lists, which are not currently supported for BPMs. As
+   BPMs often have dense bond networks, generating 1-3 and 1-4 special
+   bond lists is expensive.  By setting the lj weight for 1-2 bonds to
+   zero, this turns off pairwise interactions.  Even though there are no
+   charges in BPM models, setting a nonzero coul weight for 1-2 bonds
+   ensures all bonded neighbors are still included in the neighbor list
+   in case bonds break between neighbor list builds.
+
+B) Alternatively, one can simply overlay pair interactions such that all
+   bonded particles also feel pair interactions. This can be
+   accomplished by using the *overlay/pair* keyword present in all bpm
+   bond styles and by using the following special bond settings
+
+   .. code-block:: LAMMPS
+
+      special_bonds lj/coul 1 1 1
+
+See the :doc:`Howto <Howto_broken_bonds>` page on broken bonds for
+more information.
+
+----------
+
+Currently there are two types of bonds included in the BPM
+package. The first bond style, :doc:`bond bpm/spring
+<bond_bpm_spring>`, only applies pairwise, central body forces. Point
+particles must have :doc:`bond atom style <atom_style>` and may be
+thought of as nodes in a spring network. Alternatively, the second
+bond style, :doc:`bond bpm/rotational <bond_bpm_rotational>`, resolves
+tangential forces and torques arising with the shearing, bending, and
+twisting of the bond due to rotation or displacement of particles.
+Particles are similar to those used in the :doc:`granular package
+<Howto_granular>`, :doc:`atom style sphere <atom_style>`. However,
+they must also track the current orientation of particles and store bonds
+and therefore use a :doc:`bpm/sphere atom style <atom_style>`.
+This also requires a unique integrator :doc:`fix nve/bpm/sphere
+<fix_nve_bpm_sphere>` which numerically integrates orientation similar
+to :doc:`fix nve/asphere <fix_nve_asphere>`.
+
+To monitor the fracture of bonds in the system, all BPM bond styles
+have the ability to record instances of bond breakage to output using
+the :doc:`dump local <dump>` command. Additionally, one can use
+:doc:`compute nbond/atom <compute_nbond_atom>` to tally the current
+number of bonds per atom.
+
+In addition to bond styles, a new pair style :doc:`pair bpm/spring
+<pair_bpm_spring>` was added to accompany the bpm/spring bond
+style. This pair style is simply a hookean repulsion with similar
+velocity damping as its sister bond style.
+
+----------
+
+While LAMMPS has many utilities to create and delete bonds, *only*
+the following are currently compatible with BPM bond styles:
+
+* :doc:`create_bonds <create_bonds>`
+* :doc:`delete_bonds <delete_bonds>`
+* :doc:`fix bond/create <fix_bond_create>`
+* :doc:`fix bond/break <fix_bond_break>`
+* :doc:`fix bond/swap <fix_bond_swap>`
+
+Note :doc:`create_bonds <create_bonds>` requires certain special_bonds settings.
+To subtract pair interactions, one will need to switch between different
+special_bonds settings in the input script. An example is found in
+examples/bpm/impact.

doc/src/Howto_broken_bonds.rst

@@ -0,0 +1,48 @@
+Broken Bonds
+============
+
+Typically, bond interactions persist for the duration of a simulation
+in LAMMPS. However, there are some exceptions that allow for bonds to
+break including the :doc:`quartic bond style <bond_quartic>` and the
+bond styles in the :doc:`BPM package <Howto_bpm>` which contains the
+:doc:`bpm/spring <bond_bpm_spring>` and
+:doc:`bpm/rotational <bond_bpm_rotational>` bond styles. In these cases,
+a bond can be broken if it is stretched beyond a user-defined threshold.
+LAMMPS accomplishes this by setting the bond type to zero such that the
+bond force is no longer computed.
+
+Users are normally able to weight the contribution of pair forces to atoms
+that are bonded using the :doc:`special_bonds command <special_bonds>`.
+When bonds break, this is not always the case. For the quartic bond style,
+pair forces are always turned off between bonded particles. LAMMPS does
+this via a computational sleight-of-hand. It subtracts the pairwise
+interaction as part of the bond computation. When the bond breaks, the
+subtraction stops.  For this to work, the pairwise interaction must always
+be computed by the :doc:`pair_style <pair_style>` command, whether the bond
+is broken or not.  This means that :doc:`special_bonds <special_bonds>` must
+be set to 1,1,1. After the bond breaks, the pairwise interaction between the
+two atoms is turned on, since they are no longer bonded.
+
+In the BPM package, one can either turn off all pair interactions between
+bonded particles or leave them on, overlaying pair forces on top of bond
+forces. To remove pair forces, the special bond list is dynamically
+updated. More details can be found on the :doc:`Howto BPM <Howto_bpm>`
+page.
+
+Bonds can also be broken by fixes which change bond topology, including
+:doc:`fix bond/break <fix_bond_break>` and
+:doc:`fix bond/react <fix_bond_react>`. These fixes will automatically
+trigger a rebuild of the neighbor list and update special bond data structures
+when bonds are broken.
+
+Note that when bonds are dumped to a file via the :doc:`dump local <dump>` command, bonds with type 0 are not included.  The
+:doc:`delete_bonds <delete_bonds>` command can also be used to query the
+status of broken bonds or permanently delete them, e.g.:
+
+.. code-block:: LAMMPS
+
+   delete_bonds all stats
+   delete_bonds all bond 0 remove
+
+The compute :doc:`nbond/atom <compute_nbond_atom>` can also be used
+to tally the current number of bonds per atom, excluding broken bonds.

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
-   this scenario, LAMMPS is the driver code.  During timestepping,
+1. Define a new :doc:`fix <fix>` command that calls the other code.
+   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>`_
-   to compute forces, is hooked to LAMMPS.
-   See the :doc:`fix latte <fix_latte>` command for more details.
-   Also see the :doc:`Modify <Modify>` doc pages for info on how to
-   add a new fix to LAMMPS.
+   tight-binding calculations using the `LATTE software
+   <https://github.com/lanl/LATTE>`_ to compute forces, is hooked to
+   LAMMPS.  See the :doc:`fix latte <fix_latte>` command for more
+   details.  Also see the :doc:`Modify <Modify>` doc pages for info on
+   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
-   described on the :doc:`Howto client/server <Howto_client_server>` doc
-   page.
+4. Couple LAMMPS with another code in a client/server fashion, using
+   using the `MDI Library
+   <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_elastic.rst

@@ -18,23 +18,52 @@ At zero temperature, it is easy to estimate these derivatives by
 deforming the simulation box in one of the six directions using the
 :doc:`change_box <change_box>` command and measuring the change in the
 stress tensor. A general-purpose script that does this is given in the
-examples/elastic directory described on the :doc:`Examples <Examples>`
+examples/ELASTIC directory described on the :doc:`Examples <Examples>`
 doc page.
 
 Calculating elastic constants at finite temperature is more
 challenging, because it is necessary to run a simulation that performs
-time averages of differential properties. One way to do this is to
-measure the change in average stress tensor in an NVT simulations when
+time averages of differential properties. There are at least
+3 ways to do this in LAMMPS. The most reliable way to do this is
+by exploiting the relationship between elastic constants, stress
+fluctuations, and the Born matrix, the second derivatives of energy
+w.r.t. strain :ref:`(Ray) <Ray>`.
+The Born matrix calculation has been enabled by
+the :doc:`compute born/matrix <compute_born_matrix>` command,
+which works for any bonded or non-bonded potential in LAMMPS.
+The most expensive part of the calculation is the sampling of
+the stress fluctuations. Several examples of this method are
+provided in the examples/ELASTIC_T/BORN_MATRIX directory
+described on the :doc:`Examples <Examples>` doc page.
+
+A second way is to measure
+the change in average stress tensor in an NVT simulations when
 the cell volume undergoes a finite deformation. In order to balance
 the systematic and statistical errors in this method, the magnitude of
 the deformation must be chosen judiciously, and care must be taken to
 fully equilibrate the deformed cell before sampling the stress
-tensor. Another approach is to sample the triclinic cell fluctuations
+tensor. An example of this method is provided in the
+examples/ELASTIC_T/DEFORMATION directory
+described on the :doc:`Examples <Examples>` doc page.
+
+Another approach is to sample the triclinic cell fluctuations
 that occur in an NPT simulation. This method can also be slow to
-converge and requires careful post-processing :ref:`(Shinoda) <Shinoda1>`
+converge and requires careful post-processing :ref:`(Shinoda) <Shinoda1>`.
+We do not provide an example of this method.
+
+A nice review of the advantages and disadvantages of all of these methods
+is provided in the paper by Clavier et al. :ref:`(Clavier) <Clavier>`.
 
 ----------
 
+.. _Ray:
+
+**(Ray)** J. R. Ray and A. Rahman, J Chem Phys, 80, 4423 (1984).
+
 .. _Shinoda1:
 
 **(Shinoda)** Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).
+
+.. _Clavier:
+
+**(Clavier)** G. Clavier, N. Desbiens, E. Bourasseau, V. Lachet, N. Brusselle-Dupend and B. Rousseau, Mol Sim, 43, 1413 (2017).

doc/src/Howto_mdi.rst

@@ -1,132 +1,163 @@
 Using LAMMPS with the MDI library for code coupling
 ===================================================
 
-.. note::
-
-  This Howto page will eventually replace the
-  :doc:`Howto client/server <Howto_client_server>` doc page.
-
-Client/server coupling of two codes is where one code is the "client"
-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>`_,
+Client/server coupling of two (or more) codes is where one code is the
+"client" and sends request messages (data) to one (or more) "server"
+code(s).  A server responds to each request with a reply message
+(data).  This enables two (or more) codes to work in tandem to perform
+a simulation.  In this context, LAMMPS can act as either a client or
+server code.  It does this by using the `MolSSI Driver Interface (MDI)
+library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_,
 developed by the `Molecular Sciences Software Institute (MolSSI)
-<https://molssi.org>`_.
+<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
-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 which implements the client-side
-protocol can be used in tandem with any code which implements the
-server-side protocol.  Neither code needs to know what specific other
-code it is working with.
+neither code needs to have a library interface.  This also makes it
+easy 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 which implements the
+client-side protocol can be used in tandem with any code which
+implements the server-side protocol.  Neither code needs to know what
+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
-stand-alone executables, MDI also enables a server code to be a
-"plugin" to the client code.  In this scenario, server code(s) are
-compiled as shared libraries, and one (or more) instances of the
-server are instantiated by the driver code.  If the driver code runs
-in parallel, it can split its MPI communicator into multiple
-sub-communicators, and launch each plugin engine instance on a
-sub-communicator.  Driver processors in that sub-communicator exchange
-messages with that engine instance, and can also send MPI messages to
-other processors in the driver.  The driver code can also destroy
-engine instances and re-instantiate them.
+In addition to allowing driver and engine(s) to run as stand-alone
+executables, MDI also enables an engine to be a *plugin* to the client
+code.  In this scenario, server code(s) are compiled as shared
+libraries, and one (or more) instances of the server are instantiated
+by the driver code.  If the driver code runs in parallel, it can split
+its MPI communicator into multiple sub-communicators, and launch each
+plugin engine instance on a sub-communicator.  Driver processors
+within that sub-communicator exchange messages with the corresponding
+engine instance, and can also send MPI messages to other processors in
+the driver.  The driver code can also destroy engine instances and
+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
-MDI_Send() and MDI_Recv() calls, which are conceptually similar to
-MPI_Send() and MPI_Recv() calls.  Each send or receive has a string
-which identifies the command name, and optionally some data, which can
-be a single value or vector of values of any data type.  Inside the
-MDI library, data is exchanged between the driver and engine via MPI
-calls or sockets.  This a run-time choice by the user.
+The way in which an MDI driver communicates with an MDI engine is by
+making MDI_Send() and MDI_Recv() calls, which are conceptually similar
+to MPI_Send() and MPI_Recv() calls.  Each send or receive operation
+uses a string to identify the command name, and optionally some data,
+which can be a single value or vector of values of any data type.
+Inside the MDI library, data is exchanged between the driver and
+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/qm <fix_mdi_qm>` command in which
+LAMMPS operates as an MDI driver in conjunction with a quantum
+mechanics code as an MDI engine.  The post_force() method of the
+fix_mdi_qm.cpp file shows how a driver issues MDI commands to another
+code.  This command can be used to couple to an MDI engine which is
+either a stand-alone code or a plugin library.
+
+As explained on the `fix mdi/qm <fix_mdi_qm>` command doc page, it can
+be used to perform *ab initio* MD simulations or energy minimizations,
+or to evaluate the quantum energy and forces for a series of
+independent systems.  The examples/mdi directory has example input
+scripts for all of these use cases.
+
+----------
+
+The examples/mdi directory contains Python scripts and LAMMPS input
+script which use LAMMPS as either an MDI driver or engine or both.
+Currently, 5 example use cases are provided:
+
+* Run ab initio MD (AIMD) using 2 instances of LAMMPS.  As a driver
+  LAMMPS performs the timestepping in either NVE or NPT mode.  As an
+  engine, LAMMPS computes forces and is a surrogate for a quantum
+  code.
+
+* As a driver, LAMMPS runs an MD simulation.  Every N steps it passes
+  the current snapshot to an MDI engine to evaluate the energy,
+  virial, and peratom forces.  As the engine LAMMPS is a surrogate for
+  a quantum code.
+
+* As a driver, LAMMPS loops over a series of data files and passes the
+  configuration to an MDI engine to evaluate the energy, virial, and
+  peratom forces.  As the engine LAMMPS is a surrogate for a quantum
+  code.
+
+* A Python script driver invokes a sequence of unrelated LAMMPS
+  calculations.  Calculations can be single-point energy/force
+  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 the input scripts or launch commands, except to
+specify the name of the QM code.
+
+The examples/mdi/Run.sh file illustrates how to launch both driver and
+engine codes so that they communicate using the MDI library via either
+MPI or sockets.  Or using the engine as a stand-alone code or plugin
+library.
 
 -------------
 
-As an example, LAMMPS and the ``pw.x`` command from Quantum Espresso (a
-suite of quantum DFT codes), can work together via the MDI library to
-perform an ab initio MD (AIMD) simulation, where LAMMPS runs an MD
-simulation and sends a message each timestep to ``pw.x`` asking it to
-compute quantum forces on the current configuration of atoms.  Here is
-how the 2 codes are launched to communicate by MPI:
+Currently there are at least two quantum DFT codes which have direct
+MDI support, `Quantum ESPRESSO (QE)
+<https://www.quantum-espresso.org/>`_ and `INQ
+<https://qsg.llnl.gov/node/101.html>`_.  There are also several QM
+codes which have indirect support through QCEngine or i-PI.  The
+former means they require a wrapper program (QCEngine) with MDI
+support which writes/read files to pass data to the quantum code
+itself.  The list of QCEngine-supported and i-PI-supported quantum
+codes is on the `MDI webpage
+<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" \
-     -in in.aimd : -np 16 pw.x -in qe.in -mdi "-role ENGINE -name e -method MPI"
+   % git clone --branch mdi_plugin https://github.com/MolSSI-MDI/q-e.git <base_path>/q-e
+   % 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
-processors.
-
-Here is how the 2 codes are launched to communicate by sockets:
+Here is how to build QE as a shared library which can be used in plugin mode,
+which results in a libqemdi.so file in <base_path>/q-e/MDI/src:
 
 .. code-block:: bash
 
-   % mpirun -np 2 lmp_mpi -mdi "-role DRIVER -name d -method TCP -port 8021" -in in.aimd
-   % mpirun -np 16 pw.x -in qe.in -mdi "-role ENGINE -name e -method TCP -port 8021 -hostname localhost"
+   % git clone --branch mdi_plugin https://github.com/MolSSI-MDI/q-e.git <base_path>/q-e
+   % 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
-machine.  Or in the same window, if the first command is ended with
-"&" so as to run in the background.  If "localhost" is replaced by an
-IP address, ``pw.x`` could be run on another machine on the same network, or
-even on another machine across the country.
+INQ cannot be built as a stand-alone code; it is by design a library.
+Here is how to build INQ as a shared library which can be used in
+plugin mode, which results in a libinqmdi.so file in
+<base_path>/inq/build/examples:
 
-After both codes initialize themselves to model the same system, this is
-what occurs each timestep:
+.. code-block:: bash
 
-* LAMMPS send a ">COORDS" message to ``pw.x`` with a 3*N vector of current atom coords
-* ``pw.x`` receives the message/coords and computes quantum forces on all the atoms
-* LAMMPS send a "<FORCES" message to ``pw.x`` and waits for the result
-* ``pw.x`` receives the message (after its computation finishes) and sends a 3*N vector of forces
-* LAMMPS receives the forces and time integrates to complete a single timestep
-
--------------
-
-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
+   % git clone --branch mdi --recurse-submodules https://gitlab.com/taylor-a-barnes/inq.git <base_path>/inq
+   % cd <base_path>/inq
+   % mkdir -p build
+   % cd build
+   % ../configure --prefix=<install_path>/install
+   % make -j 4
+   % make install

doc/src/Howto_spc.rst

@@ -19,7 +19,7 @@ atoms and the water molecule to run a rigid SPC model.
 | LJ :math:`\sigma` of OO = 3.166
 | LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
 | :math:`r_0` of OH bond = 1.0
-| :math:`\theta` of HOH angle = 109.47\ :math:`^{\circ}`
+| :math:`\theta_0` of HOH angle = 109.47\ :math:`^{\circ}`
 |
 
 Note that as originally proposed, the SPC model was run with a 9