ICODE-ADC/lammps
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'develop' into stable_fix_brownian_update

Browse Source
This commit is contained in:
Axel Kohlmeyer
2022-03-29 08:26:11 -04:00
parent 88ff2db715 08bdaf8ca7
commit 5ea526728e
3993 changed files with 322060 additions and 447093 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
.gitattributes vendored
View File

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

2
.github/CODEOWNERS vendored
View File

@ -83,7 +83,7 @@ src/library.* @sjplimp
src/main.cpp @sjplimp
src/min_*.* @sjplimp
src/memory.* @sjplimp
src/modify.* @sjplimp
src/modify.* @sjplimp @stanmoore1
src/molecule.* @sjplimp
src/my_page.h @sjplimp
src/my_pool_chunk.h @sjplimp

2
.github/workflows/codeql-analysis.yml vendored
View File

@ -3,7 +3,7 @@ name: "CodeQL Code Analysis"
on:
push:
branches: [master]
branches: [develop]
jobs:
analyze:

46
.github/workflows/compile-msvc.yml vendored Normal file
View File

@ -0,0 +1,46 @@
# GitHub action to build LAMMPS on Windows with Visual C++
name: "Native Windows Compilation and Unit Tests"
on:
push:
branches: [develop]
jobs:
build:
name: Windows Compilation Test
if: ${{ github.repository == 'lammps/lammps' }}
runs-on: windows-latest
steps:
- name: Checkout repository
uses: actions/checkout@v2
with:
fetch-depth: 2
- name: Select Python version
uses: actions/setup-python@v2
with:
python-version: '3.10'
- name: Building LAMMPS via CMake
shell: bash
run: |
python3 -m pip install numpy
cmake -C cmake/presets/windows.cmake \
-D PKG_PYTHON=on \
-S cmake -B build \
-D BUILD_SHARED_LIBS=on \
-D LAMMPS_EXCEPTIONS=on \
-D ENABLE_TESTING=on
cmake --build build --config Release
- name: Run LAMMPS executable
shell: bash
run: |
./build/Release/lmp.exe -h
./build/Release/lmp.exe -in bench/in.lj
- name: Run Unit Tests
working-directory: build
shell: bash
run: ctest -V -C Release

2
.github/workflows/unittest-macos.yml vendored
View File

@ -3,7 +3,7 @@ name: "Unittest for MacOS"
on:
push:
branches: [master]
branches: [develop]
jobs:
build:

8
.gitignore vendored
View File

@ -12,6 +12,7 @@
*.sif
*.dll
*.pyc
*.whl
a.out
__pycache__
@ -37,8 +38,8 @@ vgcore.*
.Trashes
ehthumbs.db
Thumbs.db
.clang-format
.lammps_history
.vs
#cmake
/build*
@ -49,3 +50,8 @@ Thumbs.db
/Testing
/cmake_install.cmake
/lmp
out/Debug
out/RelWithDebInfo
out/Release
out/x86
out/x64

4
SECURITY.md
View File

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

196
bench/POTENTIALS/ffield.comb
View File

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

123
cmake/CMakeLists.txt
View File

@ -16,9 +16,13 @@ endif()
project(lammps CXX)
set(SOVERSION 0)
get_property(BUILD_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
get_filename_component(LAMMPS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/.. ABSOLUTE)
get_filename_component(LAMMPS_LIB_BINARY_DIR ${CMAKE_BINARY_DIR}/lib ABSOLUTE)
# collect all executables and shared libs in the top level build folder
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
set(LAMMPS_SOURCE_DIR ${LAMMPS_DIR}/src)
set(LAMMPS_LIB_SOURCE_DIR ${LAMMPS_DIR}/lib)
@ -81,22 +85,40 @@ check_for_autogen_files(${LAMMPS_SOURCE_DIR})
include(CheckIncludeFileCXX)
# set required compiler flags and compiler/CPU arch specific optimizations
if((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") OR (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM"))
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
set(CMAKE_TUNE_DEFAULT "-xCOMMON-AVX512")
if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /Qrestrict")
endif()
if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
set(CMAKE_TUNE_DEFAULT "/QxCOMMON-AVX512")
else()
set(CMAKE_TUNE_DEFAULT "/QxHost")
endif()
else()
set(CMAKE_TUNE_DEFAULT "-xHost")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
set(CMAKE_TUNE_DEFAULT "-xCOMMON-AVX512")
else()
set(CMAKE_TUNE_DEFAULT "-xHost")
endif()
endif()
endif()
# we require C++11 without extensions
# we require C++11 without extensions. Kokkos requires at least C++14 (currently)
set(CMAKE_CXX_STANDARD 11)
if(PKG_KOKKOS AND (CMAKE_CXX_STANDARD LESS 14))
set(CMAKE_CXX_STANDARD 14)
endif()
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF CACHE BOOL "Use compiler extensions")
# ugly hack for MSVC which by default always reports an old C++ standard in the __cplusplus macro
# 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)
add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
endif()
# export all symbols when building a .dll file on windows
@ -115,10 +137,7 @@ endif()
set(LAMMPS_BINARY lmp${LAMMPS_MACHINE})
option(BUILD_SHARED_LIBS "Build shared library" OFF)
if(BUILD_SHARED_LIBS) # for all pkg libs, mpi_stubs and linalg
set(CMAKE_POSITION_INDEPENDENT_CODE ON)
endif()
option(CMAKE_POSITION_INDEPENDENT_CODE "Create object compatible with shared libraries" ON)
option(BUILD_TOOLS "Build and install LAMMPS tools (msi2lmp, binary2txt, chain)" OFF)
option(BUILD_LAMMPS_SHELL "Build and install the LAMMPS shell" OFF)
@ -265,28 +284,19 @@ if(BUILD_MPI)
# We use a non-standard procedure to cross-compile with MPI on Windows
if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
include(MPI4WIN)
target_link_libraries(lammps PUBLIC MPI::MPI_CXX)
else()
find_package(MPI REQUIRED)
target_link_libraries(lammps PUBLIC MPI::MPI_CXX)
option(LAMMPS_LONGLONG_TO_LONG "Workaround if your system or MPI version does not recognize 'long long' data types" OFF)
if(LAMMPS_LONGLONG_TO_LONG)
target_compile_definitions(lammps PRIVATE -DLAMMPS_LONGLONG_TO_LONG)
endif()
endif()
target_link_libraries(lammps PUBLIC MPI::MPI_CXX)
else()
file(GLOB MPI_SOURCES ${LAMMPS_SOURCE_DIR}/STUBS/mpi.cpp)
add_library(mpi_stubs STATIC ${MPI_SOURCES})
set_target_properties(mpi_stubs PROPERTIES OUTPUT_NAME lammps_mpi_stubs${LAMMPS_MACHINE})
target_include_directories(mpi_stubs PUBLIC $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
if(BUILD_SHARED_LIBS)
target_link_libraries(lammps PRIVATE mpi_stubs)
target_include_directories(lammps INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
target_compile_definitions(lammps INTERFACE $<INSTALL_INTERFACE:LAMMPS_LIB_NO_MPI>)
else()
target_link_libraries(lammps PUBLIC mpi_stubs)
endif()
add_library(MPI::MPI_CXX ALIAS mpi_stubs)
target_sources(lammps PRIVATE ${LAMMPS_SOURCE_DIR}/STUBS/mpi.cpp)
add_library(mpi_stubs INTERFACE)
target_include_directories(mpi_stubs INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
target_link_libraries(lammps PUBLIC mpi_stubs)
endif()
set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallsmall: all 32-bit, smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
@ -317,7 +327,6 @@ pkg_depends(ML-IAP ML-SNAP)
pkg_depends(MPIIO MPI)
pkg_depends(ATC MANYBODY)
pkg_depends(LATBOLTZ MPI)
pkg_depends(PHONON KSPACE)
pkg_depends(SCAFACOS MPI)
pkg_depends(DIELECTRIC KSPACE)
pkg_depends(DIELECTRIC EXTRA-PAIR)
@ -351,11 +360,13 @@ if(BUILD_OMP)
((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.0)))
# GCC 9.x and later plus Clang 10.x and later implement strict OpenMP 4.0 semantics for consts.
# Intel 18.0 was tested to support both, so we switch to OpenMP 4+ from 19.x onward to be safe.
target_compile_definitions(lammps PRIVATE -DLAMMPS_OMP_COMPAT=4)
set(LAMMPS_OMP_COMPAT_LEVEL 4)
else()
target_compile_definitions(lammps PRIVATE -DLAMMPS_OMP_COMPAT=3)
set(LAMMPS_OMP_COMPAT_LEVEL 3)
endif()
target_compile_definitions(lammps PRIVATE -DLAMMPS_OMP_COMPAT=${LAMMPS_OMP_COMPAT_LEVEL})
target_link_libraries(lammps PRIVATE OpenMP::OpenMP_CXX)
target_link_libraries(lmp PRIVATE OpenMP::OpenMP_CXX)
endif()
if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_LATTE)
@ -468,9 +479,12 @@ foreach(HEADER cmath)
endif(NOT FOUND_${HEADER})
endforeach(HEADER)
set(MATH_LIBRARIES "m" CACHE STRING "math library")
mark_as_advanced( MATH_LIBRARIES )
target_link_libraries(lammps PRIVATE ${MATH_LIBRARIES})
# make the standard math library overrideable and autodetected (for systems that don't have it)
find_library(STANDARD_MATH_LIB m DOC "Standard Math library")
mark_as_advanced(STANDARD_MATH_LIB)
if(STANDARD_MATH_LIB)
target_link_libraries(lammps PRIVATE ${STANDARD_MATH_LIB})
endif()
######################################
# Generate Basic Style files
@ -566,11 +580,10 @@ if(PKG_ATC)
if(LAMMPS_SIZES STREQUAL "BIGBIG")
message(FATAL_ERROR "The ATC Package is not compatible with -DLAMMPS_BIGBIG")
endif()
target_link_libraries(atc PRIVATE ${LAPACK_LIBRARIES})
if(BUILD_MPI)
target_link_libraries(atc PRIVATE MPI::MPI_CXX)
target_link_libraries(atc PRIVATE ${LAPACK_LIBRARIES} MPI::MPI_CXX)
else()
target_link_libraries(atc PRIVATE mpi_stubs)
target_link_libraries(atc PRIVATE ${LAPACK_LIBRARIES} mpi_stubs)
endif()
target_include_directories(atc PRIVATE ${LAMMPS_SOURCE_DIR})
target_compile_definitions(atc PRIVATE -DLAMMPS_${LAMMPS_SIZES})
@ -584,22 +597,19 @@ endif()
# packages which selectively include variants based on enabled styles
# e.g. accelerator packages
######################################################################
foreach(PKG_WITH_INCL CORESHELL QEQ OPENMP DPD-SMOOTH KOKKOS OPT INTEL GPU)
foreach(PKG_WITH_INCL CORESHELL DPD-SMOOTH PHONON QEQ OPENMP KOKKOS OPT INTEL GPU)
if(PKG_${PKG_WITH_INCL})
include(Packages/${PKG_WITH_INCL})
endif()
endforeach()
if(PKG_PLUGIN)
if(BUILD_SHARED_LIBS)
target_compile_definitions(lammps PRIVATE -DLMP_PLUGIN)
else()
message(WARNING "Plugin loading will not work unless BUILD_SHARED_LIBS is enabled")
endif()
# link with -ldl or equivalent for plugin loading; except on Windows
if(NOT ${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
target_link_libraries(lammps PRIVATE ${CMAKE_DL_LIBS})
endif()
target_compile_definitions(lammps PRIVATE -DLMP_PLUGIN)
endif()
# link with -ldl or equivalent for plugin loading; except on Windows
if(NOT ${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
target_link_libraries(lammps PRIVATE ${CMAKE_DL_LIBS})
endif()
######################################################################
@ -608,7 +618,7 @@ endif()
# and after everything else that is compiled locally
######################################################################
if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
target_link_libraries(lammps PRIVATE -lwsock32 -lpsapi)
target_link_libraries(lammps PRIVATE "wsock32;psapi")
endif()
######################################################
@ -669,6 +679,7 @@ endif()
set_target_properties(lammps PROPERTIES OUTPUT_NAME lammps${LAMMPS_MACHINE})
set_target_properties(lammps PROPERTIES SOVERSION ${SOVERSION})
set_target_properties(lammps PROPERTIES PREFIX "lib")
target_include_directories(lammps PUBLIC $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}/lammps>)
file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps)
foreach(_HEADER ${LAMMPS_CXX_HEADERS})
@ -688,6 +699,9 @@ foreach(_DEF ${LAMMPS_DEFINES})
endforeach()
if(BUILD_SHARED_LIBS)
install(TARGETS lammps EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
if(NOT BUILD_MPI)
install(TARGETS mpi_stubs EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
endif()
configure_file(pkgconfig/liblammps.pc.in ${CMAKE_CURRENT_BINARY_DIR}/liblammps${LAMMPS_MACHINE}.pc @ONLY)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/liblammps${LAMMPS_MACHINE}.pc DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
install(EXPORT LAMMPS_Targets FILE LAMMPS_Targets.cmake NAMESPACE LAMMPS:: DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/LAMMPS)
@ -727,7 +741,7 @@ install(
if(BUILD_SHARED_LIBS)
if(CMAKE_VERSION VERSION_LESS 3.12)
# adjust so we find Python 3 versions before Python 2 on old systems with old CMake
set(Python_ADDITIONAL_VERSIONS 3.9 3.8 3.7 3.6 3.5)
set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
find_package(PythonInterp) # Deprecated since version 3.12
if(PYTHONINTERP_FOUND)
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
@ -735,13 +749,15 @@ if(BUILD_SHARED_LIBS)
else()
find_package(Python COMPONENTS Interpreter)
endif()
if(BUILD_IS_MULTI_CONFIG)
set(LIBLAMMPS_SHARED_BINARY ${CMAKE_BINARY_DIR}/$<CONFIG>/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX})
else()
set(LIBLAMMPS_SHARED_BINARY ${CMAKE_BINARY_DIR}/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX})
endif()
if(Python_EXECUTABLE)
add_custom_target(
install-python ${CMAKE_COMMAND} -E remove_directory build
COMMAND ${Python_EXECUTABLE} install.py -v ${LAMMPS_SOURCE_DIR}/version.h
-p ${LAMMPS_PYTHON_DIR}/lammps
-l ${CMAKE_BINARY_DIR}/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX}
WORKING_DIRECTORY ${LAMMPS_PYTHON_DIR}
COMMAND ${Python_EXECUTABLE} ${LAMMPS_PYTHON_DIR}/install.py -p ${LAMMPS_PYTHON_DIR}/lammps -l ${LIBLAMMPS_SHARED_BINARY}
COMMENT "Installing LAMMPS Python module")
else()
add_custom_target(
@ -786,11 +802,16 @@ if(ClangFormat_FOUND)
endif()
get_target_property(DEFINES lammps COMPILE_DEFINITIONS)
if(BUILD_IS_MULTI_CONFIG)
set(LAMMPS_BUILD_TYPE "Multi-Config")
else()
set(LAMMPS_BUILD_TYPE ${CMAKE_BUILD_TYPE})
endif()
include(FeatureSummary)
feature_summary(DESCRIPTION "The following tools and libraries have been found and configured:" WHAT PACKAGES_FOUND)
message(STATUS "<<< Build configuration >>>
Operating System: ${CMAKE_SYSTEM_NAME} ${CMAKE_LINUX_DISTRO} ${CMAKE_DISTRO_VERSION}
Build type: ${CMAKE_BUILD_TYPE}
Build type: ${LAMMPS_BUILD_TYPE}
Install path: ${CMAKE_INSTALL_PREFIX}
Generator: ${CMAKE_GENERATOR} using ${CMAKE_MAKE_PROGRAM}")
###############################################################################

156
cmake/CMakeSettings.json Normal file
View File

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

33
cmake/Modules/ExternalCMakeProject.cmake Normal file
View File

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

9
cmake/Modules/FindCythonize.cmake
View File

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

81
cmake/Modules/GTest.cmake
View File

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

4
cmake/Modules/LAMMPSUtils.cmake
View File

@ -25,7 +25,7 @@ function(validate_option name values)
endfunction(validate_option)
function(get_lammps_version version_header variable)
file(READ ${version_header} line)
file(STRINGS ${version_header} line REGEX LAMMPS_VERSION)
set(MONTHS x Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec)
string(REGEX REPLACE "#define LAMMPS_VERSION \"([0-9]+) ([A-Za-z]+) ([0-9]+)\"" "\\1" day "${line}")
string(REGEX REPLACE "#define LAMMPS_VERSION \"([0-9]+) ([A-Za-z]+) ([0-9]+)\"" "\\2" month "${line}")
@ -85,7 +85,7 @@ endfunction(GenerateBinaryHeader)
# fetch missing potential files
function(FetchPotentials pkgfolder potfolder)
if (EXISTS "${pkgfolder}/potentials.txt")
if(EXISTS "${pkgfolder}/potentials.txt")
file(STRINGS "${pkgfolder}/potentials.txt" linelist REGEX "^[^#].")
foreach(line ${linelist})
string(FIND ${line} " " blank)

51
cmake/Modules/OpenCLLoader.cmake
View File

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

9
cmake/Modules/Packages/COMPRESS.cmake
View File

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

23
cmake/Modules/Packages/GPU.cmake
View File

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

54
cmake/Modules/Packages/KOKKOS.cmake
View File

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

5
cmake/Modules/Packages/MACHDYN.cmake
View File

@ -7,8 +7,9 @@ endif()
option(DOWNLOAD_EIGEN3 "Download Eigen3 instead of using an already installed one)" ${DOWNLOAD_EIGEN3_DEFAULT})
if(DOWNLOAD_EIGEN3)
message(STATUS "Eigen3 download requested - we will build our own")
set(EIGEN3_URL "https://gitlab.com/libeigen/eigen/-/archive/3.3.9/eigen-3.3.9.tar.gz" CACHE STRING "URL for Eigen3 tarball")
set(EIGEN3_MD5 "609286804b0f79be622ccf7f9ff2b660" CACHE STRING "MD5 checksum of Eigen3 tarball")
set(EIGEN3_URL "${LAMMPS_THIRDPARTY_URL}/eigen-3.4.0.tar.gz" CACHE STRING "URL for Eigen3 tarball")
set(EIGEN3_MD5 "4c527a9171d71a72a9d4186e65bea559" CACHE STRING "MD5 checksum of Eigen3 tarball")
mark_as_advanced(EIGEN3_URL)
mark_as_advanced(EIGEN3_MD5)
include(ExternalProject)

6
cmake/Modules/Packages/ML-HDNNP.cmake
View File

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

21
cmake/Modules/Packages/ML-PACE.cmake
View File

@ -1,11 +1,11 @@
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.4.9.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
set(PACELIB_MD5 "4db54962fbd6adcf8c18d46e1798ceb5" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
set(PACELIB_MD5 "a2ac3315c41a1a4a5c912bcb1bc9c5cc" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
mark_as_advanced(PACELIB_URL)
mark_as_advanced(PACELIB_MD5)
# download library sources to build folder
file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz SHOW_PROGRESS EXPECTED_HASH MD5=${PACELIB_MD5})
file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz EXPECTED_HASH MD5=${PACELIB_MD5}) #SHOW_PROGRESS
# uncompress downloaded sources
execute_process(
@ -14,12 +14,19 @@ execute_process(
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
)
file(GLOB PACE_EVALUATOR_INCLUDE_DIR ${CMAKE_BINARY_DIR}/lammps-user-pace-*/USER-PACE)
file(GLOB PACE_EVALUATOR_SOURCES ${CMAKE_BINARY_DIR}/lammps-user-pace-*/USER-PACE/*.cpp)
file(GLOB lib-pace ${CMAKE_BINARY_DIR}/lammps-user-pace-*)
add_subdirectory(${lib-pace}/yaml-cpp build-yaml-cpp)
set(YAML_CPP_INCLUDE_DIR ${lib-pace}/yaml-cpp/include)
file(GLOB PACE_EVALUATOR_INCLUDE_DIR ${lib-pace}/ML-PACE)
file(GLOB PACE_EVALUATOR_SOURCES ${lib-pace}/ML-PACE/*.cpp)
list(FILTER PACE_EVALUATOR_SOURCES EXCLUDE REGEX pair_pace.cpp)
add_library(pace STATIC ${PACE_EVALUATOR_SOURCES})
set_target_properties(pace PROPERTIES CXX_EXTENSIONS ON OUTPUT_NAME lammps_pace${LAMMPS_MACHINE})
target_include_directories(pace PUBLIC ${PACE_EVALUATOR_INCLUDE_DIR})
target_link_libraries(lammps PRIVATE pace)
target_include_directories(pace PUBLIC ${PACE_EVALUATOR_INCLUDE_DIR} ${YAML_CPP_INCLUDE_DIR})
target_link_libraries(pace PRIVATE yaml-cpp-pace)
target_link_libraries(lammps PRIVATE pace)

4
cmake/Modules/Packages/ML-QUIP.cmake
View File

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

39
cmake/Modules/Packages/MSCG.cmake
View File

@ -12,41 +12,12 @@ if(DOWNLOAD_MSCG)
mark_as_advanced(MSCG_URL)
mark_as_advanced(MSCG_MD5)
# CMake cannot pass BLAS or LAPACK library variable to external project if they are a list
list(LENGTH BLAS_LIBRARIES} NUM_BLAS)
list(LENGTH LAPACK_LIBRARIES NUM_LAPACK)
if((NUM_BLAS GREATER 1) OR (NUM_LAPACK GREATER 1))
message(FATAL_ERROR "Cannot compile downloaded MSCG library due to a technical limitation")
endif()
include(ExternalCMakeProject)
ExternalCMakeProject(mscg ${MSCG_URL} ${MSCG_MD5} MSCG-release src/CMake "")
include(ExternalProject)
ExternalProject_Add(mscg_build
URL ${MSCG_URL}
URL_MD5 ${MSCG_MD5}
SOURCE_SUBDIR src/CMake
CMAKE_ARGS ${CMAKE_REQUEST_PIC} ${EXTRA_MSCG_OPTS}
-DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
-DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
-DCMAKE_Fortran_COMPILER=${CMAKE_Fortran_COMPILER}
-DBLAS_LIBRARIES=${BLAS_LIBRARIES} -DLAPACK_LIBRARIES=${LAPACK_LIBRARIES}
-DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
BUILD_COMMAND ${CMAKE_COMMAND} --build . --target mscg
INSTALL_COMMAND ""
BUILD_BYPRODUCTS <BINARY_DIR>/libmscg.a
)
ExternalProject_get_property(mscg_build BINARY_DIR)
ExternalProject_get_property(mscg_build SOURCE_DIR)
file(MAKE_DIRECTORY ${SOURCE_DIR}/src)
add_library(LAMMPS::MSCG UNKNOWN IMPORTED)
set_target_properties(LAMMPS::MSCG PROPERTIES
IMPORTED_LOCATION "${BINARY_DIR}/libmscg.a"
INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/src"
INTERFACE_LINK_LIBRARIES "${LAPACK_LIBRARIES}")
target_link_libraries(lammps PRIVATE LAMMPS::MSCG)
add_dependencies(LAMMPS::MSCG mscg_build)
# set include and link library
target_include_directories(lammps PRIVATE "${CMAKE_BINARY_DIR}/_deps/mscg-src/src")
target_link_libraries(lammps PRIVATE mscg)
else()
find_package(MSCG)
if(NOT MSCG_FOUND)

9
cmake/Modules/Packages/PHONON.cmake Normal file
View File

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

4
cmake/Modules/Packages/PLUMED.cmake
View File

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

2
cmake/Modules/Packages/PYTHON.cmake
View File

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

4
cmake/Modules/Tools.cmake
View File

@ -25,7 +25,9 @@ if(BUILD_TOOLS)
get_filename_component(MSI2LMP_SOURCE_DIR ${LAMMPS_TOOLS_DIR}/msi2lmp/src ABSOLUTE)
file(GLOB MSI2LMP_SOURCES ${MSI2LMP_SOURCE_DIR}/[^.]*.c)
add_executable(msi2lmp ${MSI2LMP_SOURCES})
target_link_libraries(msi2lmp PRIVATE ${MATH_LIBRARIES})
if(STANDARD_MATH_LIB)
target_link_libraries(msi2lmp PRIVATE ${STANDARD_MATH_LIB})
endif()
install(TARGETS msi2lmp DESTINATION ${CMAKE_INSTALL_BINDIR})
install(FILES ${LAMMPS_DOC_DIR}/msi2lmp.1 DESTINATION ${CMAKE_INSTALL_MANDIR}/man1)
endif()

47
cmake/Modules/YAML.cmake
View File

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

8
cmake/Modules/generate_lmpgitversion.cmake
View File

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

7
cmake/iwyu/iwyu-extra-map.imp
View File

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

6
cmake/presets/gcc.cmake
View File

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

1
cmake/presets/most.cmake
View File

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

64
cmake/presets/windows.cmake Normal file
View File

@ -0,0 +1,64 @@
set(WIN_PACKAGES
ASPHERE
BOCS
BODY
BROWNIAN
CG-DNA
CG-SDK
CLASS2
COLLOID
COLVARS
CORESHELL
DIELECTRIC
DIFFRACTION
DIPOLE
DPD-BASIC
DPD-MESO
DPD-REACT
DPD-SMOOTH
DRUDE
EFF
EXTRA-COMPUTE
EXTRA-DUMP
EXTRA-FIX
EXTRA-MOLECULE
EXTRA-PAIR
FEP
GRANULAR
INTERLAYER
KSPACE
MANIFOLD
MANYBODY
MC
MEAM
MISC
ML-IAP
ML-SNAP
MOFFF
MOLECULE
MOLFILE
OPENMP
ORIENT
PERI
PHONON
POEMS
PTM
QEQ
QTB
REACTION
REAXFF
REPLICA
RIGID
SHOCK
SMTBQ
SPH
SPIN
SRD
TALLY
UEF
YAFF)
foreach(PKG ${WIN_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
endforeach()

2
doc/Makefile
View File

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

2
doc/doxygen/Doxyfile.in
View File

@ -435,6 +435,8 @@ INPUT = @LAMMPS_SOURCE_DIR@/utils.cpp \
@LAMMPS_SOURCE_DIR@/my_pool_chunk.cpp \
@LAMMPS_SOURCE_DIR@/my_pool_chunk.h \
@LAMMPS_SOURCE_DIR@/math_eigen.h \
@LAMMPS_SOURCE_DIR@/platform.h \
@LAMMPS_SOURCE_DIR@/platform.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

12
doc/github-development-workflow.md
View File

@ -33,9 +33,9 @@ when necessary.
## Pull Requests
ALL changes to the LAMMPS code and documentation, however trivial, MUST
be submitted as a pull request to GitHub. All changes to the "master"
be submitted as a pull request to GitHub. All changes to the "develop"
branch must be made exclusively through merging pull requests. The
"unstable" and "stable" branches, respectively are only to be updated
"release" and "stable" branches, respectively are only to be updated
upon patch or stable releases with fast-forward merges based on the
associated tags. Pull requests may also be submitted to (long-running)
feature branches created by LAMMPS developers inside the LAMMPS project,
@ -123,16 +123,16 @@ and thus were this comment should be placed.
LAMMPS uses a continuous release development model with incremental
changes, i.e. significant effort is made - including automated pre-merge
testing - that the code in the branch "master" does not get easily
testing - that the code in the branch "develop" does not get easily
broken. These tests are run after every update to a pull request. More
extensive and time consuming tests (including regression testing) are
performed after code is merged to the "master" branch. There are patch
performed after code is merged to the "develop" branch. There are patch
releases of LAMMPS every 3-5 weeks at a point, when the LAMMPS
developers feel, that a sufficient amount of changes have happened, and
the post-merge testing has been successful. These patch releases are
marked with a `patch_<version date>` tag and the "unstable" branch
marked with a `patch_<version date>` tag and the "release" branch
follows only these versions (and thus is always supposed to be of
production quality, unlike "master", which may be temporary broken, in
production quality, unlike "develop", which may be temporary broken, in
the case of larger change sets or unexpected incompatibilities or side
effects.

6
doc/lammps.1
View File

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

2
doc/msi2lmp.1
View File

@ -1,4 +1,4 @@
.TH MSI2LMP "v3.9.9" "2018-11-05"
.TH MSI2LMP "1" "v3.9.9" "2018-11-05"
.SH NAME
.B MSI2LMP
\- Converter for Materials Studio files to LAMMPS

5
doc/src/Bibliography.rst
View File

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

36
doc/src/Build_cmake.rst
View File

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

10
doc/src/Build_development.rst
View File

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

2
doc/src/Build_diskspace.rst
View File

@ -14,7 +14,7 @@ environments with restricted disk space capacity it may be needed to
reduce the storage requirements. Here are some suggestions:
- Create a so-called shallow repository by cloning only the last commit
instead of the full project history by using ``git clone git@github.com:lammps/lammps --depth=1 --branch=master``.
instead of the full project history by using ``git clone git@github.com:lammps/lammps --depth=1 --branch=develop``.
This reduces the downloaded size to about half. With ``--depth=1`` it is not possible to check out different
versions/branches of LAMMPS, using ``--depth=1000`` will make multiple recent versions available at little
extra storage needs (the entire git history had nearly 30,000 commits in fall 2021).

33
doc/src/Build_extras.rst
View File

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

15
doc/src/Build_manual.rst
View File

@ -33,12 +33,15 @@ various tools and files. Some of them have to be installed (see below). For
the rest the build process will attempt to download and install them into
a python virtual environment and local folders.
A current version of the manual (latest patch release, aka unstable
branch) is is available online at:
`https://docs.lammps.org/Manual.html <https://docs.lammps.org/Manual.html>`_.
A version of the manual corresponding to the ongoing development (aka master branch)
is available online at: `https://docs.lammps.org/latest/
<https://docs.lammps.org/latest/>`_
A current version of the manual (latest patch release, that is the state
of the *release* branch) is is available online at:
`https://docs.lammps.org/ <https://docs.lammps.org/>`_.
A version of the manual corresponding to the ongoing development (that is
the state of the *develop* branch) is available online at:
`https://docs.lammps.org/latest/ <https://docs.lammps.org/latest/>`_
A version of the manual corresponding to the latest stable LAMMPS release
(that is the state of the *stable* branch) is available online at:
`https://docs.lammps.org/stable/ <https://docs.lammps.org/stable/>`_
Build using GNU make
--------------------

50
doc/src/Build_settings.rst
View File

@ -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`_
----------
@ -321,9 +321,7 @@ following settings:
.. code-block:: make
LMP_INC = -DLAMMPS_JPEG
LMP_INC = -DLAMMPS_PNG
LMP_INC = -DLAMMPS_FFMPEG
LMP_INC = -DLAMMPS_JPEG -DLAMMPS_PNG -DLAMMPS_FFMPEG <other LMP_INC settings>
JPG_INC = -I/usr/local/include # path to jpeglib.h, png.h, zlib.h header files if make cannot find them
JPG_PATH = -L/usr/lib # paths to libjpeg.a, libpng.a, libz.a (.so) files if make cannot find them
@ -354,8 +352,10 @@ Read or write compressed files
-----------------------------------------
If this option is enabled, large files can be read or written with
gzip compression by several LAMMPS commands, including
:doc:`read_data <read_data>`, :doc:`rerun <rerun>`, and :doc:`dump <dump>`.
compression by ``gzip`` or similar tools by several LAMMPS commands,
including :doc:`read_data <read_data>`, :doc:`rerun <rerun>`, and
:doc:`dump <dump>`. Currently supported compression tools are:
``gzip``, ``bzip2``, ``zstd``, and ``lzma``.
.. tabs::
@ -364,23 +364,23 @@ gzip compression by several LAMMPS commands, including
.. code-block:: bash
-D WITH_GZIP=value # yes or no
# default is yes if CMake can find gzip, else no
-D GZIP_EXECUTABLE=path # path to gzip executable if CMake cannot find it
# default is yes if CMake can find the gzip program, else no
.. tab:: Traditional make
.. code-block:: make
LMP_INC = -DLAMMPS_GZIP
LMP_INC = -DLAMMPS_GZIP <other LMP_INC settings>
This option requires that your operating system fully supports the "popen()"
function in the standard runtime library and that a ``gzip`` executable can be
found by LAMMPS during a run.
This option requires that your operating system fully supports the
"popen()" function in the standard runtime library and that a ``gzip``
or other executable can be found by LAMMPS in the standard search path
during a run.
.. note::
On some clusters with high-speed networks, using the "fork()" library
call (required by "popen()") can interfere with the fast communication
On clusters with high-speed networks, using the "fork()" library call
(required by "popen()") can interfere with the fast communication
library and lead to simulations using compressed output or input to
hang or crash. For selected operations, compressed file I/O is also
available using a compression library instead, which is what the
@ -452,7 +452,7 @@ those systems:
.. code-block:: make
LMP_INC = -DLAMMPS_LONGLONG_TO_LONG
LMP_INC = -DLAMMPS_LONGLONG_TO_LONG <other LMP_INC settings>
----------
@ -479,7 +479,7 @@ e.g. to Python. Of course, the calling code has to be set up to
.. code-block:: make
LMP_INC = -DLAMMPS_EXCEPTIONS
LMP_INC = -DLAMMPS_EXCEPTIONS <other LMP_INC settings>
.. note::
@ -520,7 +520,7 @@ executable, not the library.
.. code-block:: make
LMP_INC = -DLAMMPS_TRAP_FPE
LMP_INC = -DLAMMPS_TRAP_FPE <other LMP_INC settings>
After compilation with this flag set, the LAMMPS executable will stop
and produce a core dump when a division by zero, overflow, illegal math

101
doc/src/Build_windows.rst
View File

@ -4,6 +4,7 @@ Notes for building LAMMPS on Windows
* :ref:`General remarks <generic>`
* :ref:`Running Linux on Windows <linux>`
* :ref:`Using GNU GCC ported to Windows <gnu>`
* :ref:`Using Visual Studio <msvc>`
* :ref:`Using a cross-compiler <cross>`
----------
@ -15,44 +16,52 @@ General remarks
LAMMPS is developed and tested primarily on Linux machines. The vast
majority of HPC clusters and supercomputers today run on Linux as well.
While portability to other platforms is desired, it is not always achieved.
The LAMMPS developers are dependent on LAMMPS users giving feedback and
providing assistance in resolving portability issues. This is particularly
true for compiling LAMMPS on Windows, since this platform has significant
differences in some low-level functionality.
While portability to other platforms is desired, it is not always
achieved. That is sometimes due to non-portable code in LAMMPS itself,
but more often due to portability limitations of external libraries and
tools required to build a specific feature or package. The LAMMPS
developers are dependent on LAMMPS users giving feedback and providing
assistance in resolving portability issues. This is particularly true
for compiling LAMMPS on Windows, since this platform has significant
differences in some low-level functionality. As of LAMMPS version 14
December 2021, large parts of LAMMPS can be compiled natively with the
Microsoft Visual C++ Compilers. This is largely facilitated by using
the :doc:`Developer_platform` in the ``platform`` namespace.
Before trying to build LAMMPS on Windows yourself, please consider the
`pre-compiled Windows installer packages <https://packages.lammps.org/windows.html>`_
and see if they are sufficient for your needs.
.. _linux:
Running Linux on Windows
^^^^^^^^^^^^^^^^^^^^^^^^
Before trying to build LAMMPS on Windows, please consider if the
pre-compiled Windows binary packages are sufficient for your needs. If
it is necessary for you to compile LAMMPS on a Windows machine
If it is necessary for you to compile LAMMPS on a Windows machine
(e.g. because it is your main desktop), please also consider using a
virtual machine software and compile and run LAMMPS in a Linux virtual
machine, or - if you have a sufficiently up-to-date Windows 10
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>`.
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
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
@ -67,6 +76,50 @@ 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.
.. _msvc:
Using Microsoft Visual Studio
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Following the integration of the :doc:`platform namespace
<Developer_platform>` into the LAMMPS code base, portability of LAMMPS
for native compilation on Windows using Visual Studio has been
significantly improved. This has been tested with Visual Studio 2019
(aka version 16) and Visual Studio 2022 (aka version 17). We strongly
recommend using Visual Studio 2022 version 17.1 or later. Not all
features and packages in LAMMPS are currently supported out of the box,
but a preset ``cmake/presets/windows.cmake`` is provided that contains
the packages that have been compiled successfully so far. You **must**
use the CMake based build procedure, since there is no support for GNU
make or the Unix shell utilities required for the GNU make build
procedure.
It is possible to use both the integrated CMake support of the Visual
Studio IDE or use an external CMake installation (e.g. downloaded from
cmake.org) to create build files and compile LAMMPS from the command line.
.. note::
Versions of Visual Studio before version 17.1 may scan the entire
LAMMPS source tree and likely miss the correct master
``CMakeLists.txt`` and get confused since there are multiple files
of that name in different folders but none in top level folder.
Please note, that for either approach CMake will create a so-called
:ref:`"multi-configuration" build environment <cmake_multiconfig>`, and
the command lines for building and testing LAMMPS must be adjusted
accordingly.
To support running in parallel you can compile with OpenMP enabled using
the OPENMP package or install Microsoft MPI (including the SDK) and compile
LAMMPS with MPI enabled.
.. note::
This is work in progress and you should contact the LAMMPS developers
via GitHub, the forum, or the mailing list, if you have questions or
LAMMPS specific problems.
.. _cross:
Using a cross-compiler

4
doc/src/Commands_all.rst
View File

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

1
doc/src/Commands_bond.rst
View File

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

5
doc/src/Commands_compute.rst
View File

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

7
doc/src/Commands_fix.rst
View File

@ -23,6 +23,7 @@ OPT.
:columns: 5
* :doc:`accelerate/cos <fix_accelerate_cos>`
* :doc:`acks2/reaxff (k) <fix_acks2_reaxff>`
* :doc:`adapt <fix_adapt>`
* :doc:`adapt/fep <fix_adapt_fep>`
* :doc:`addforce <fix_addforce>`
@ -54,6 +55,7 @@ OPT.
* :doc:`cmap <fix_cmap>`
* :doc:`colvars <fix_colvars>`
* :doc:`controller <fix_controller>`
* :doc:`damping/cundall <fix_damping_cundall>`
* :doc:`deform (k) <fix_deform>`
* :doc:`deposit <fix_deposit>`
* :doc:`dpd/energy (k) <fix_dpd_energy>`
@ -96,13 +98,12 @@ 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:`meso/move <fix_meso_move>`
* :doc:`mol/swap <fix_mol_swap>`
* :doc:`momentum (k) <fix_momentum>`
* :doc:`momentum/chunk <fix_momentum>`
* :doc:`move <fix_move>`
@ -127,6 +128,7 @@ OPT.
* :doc:`npt/sphere (o) <fix_npt_sphere>`
* :doc:`npt/uef <fix_nh_uef>`
* :doc:`numdiff <fix_numdiff>`
* :doc:`numdiff/virial <fix_numdiff_virial>`
* :doc:`nve (giko) <fix_nve>`
* :doc:`nve/asphere (gi) <fix_nve_asphere>`
* :doc:`nve/asphere/noforce <fix_nve_asphere_noforce>`
@ -242,6 +244,7 @@ OPT.
* :doc:`vector <fix_vector>`
* :doc:`viscosity <fix_viscosity>`
* :doc:`viscous <fix_viscous>`
* :doc:`viscous/sphere <fix_viscous_sphere>`
* :doc:`wall/body/polygon <fix_wall_body_polygon>`
* :doc:`wall/body/polyhedron <fix_wall_body_polyhedron>`
* :doc:`wall/colloid <fix_wall>`

5
doc/src/Commands_pair.rst
View File

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

3
doc/src/Developer.rst
View File

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

433
doc/src/Developer_code_design.rst Normal file
View File

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

235
doc/src/Developer_comm_ops.rst Normal file
View File

@ -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).

209
doc/src/Developer_notes.rst
View File

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

8
doc/src/Developer_org.rst
View File

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

155
doc/src/Developer_platform.rst Normal file
View File

@ -0,0 +1,155 @@
Platform abstraction functions
------------------------------
The ``platform`` sub-namespace inside the ``LAMMPS_NS`` namespace
provides a collection of wrapper and convenience functions and utilities
that perform common tasks for which platform specific code would be
required or for which a more high-level abstraction would be convenient
and reduce duplicated code. This reduces redundant implementations and
encourages consistent behavior and thus has some overlap with the
:doc:`"utils" sub-namespace <Developer_utils>`.
Time functions
^^^^^^^^^^^^^^
.. doxygenfunction:: cputime
:project: progguide
.. doxygenfunction:: walltime
:project: progguide
.. doxygenfunction:: usleep
:project: progguide
Platform information functions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. doxygenfunction:: os_info
:project: progguide
.. doxygenfunction:: compiler_info
:project: progguide
.. doxygenfunction:: cxx_standard
:project: progguide
.. doxygenfunction:: openmp_standard
:project: progguide
.. doxygenfunction:: mpi_vendor
:project: progguide
.. doxygenfunction:: mpi_info
:project: progguide
.. doxygenfunction:: compress_info
:project: progguide
File and path functions and global constants
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. doxygenvariable:: filepathsep
:project: progguide
.. doxygenvariable:: pathvarsep
:project: progguide
.. doxygenfunction:: guesspath
:project: progguide
.. doxygenfunction:: path_basename
:project: progguide
.. doxygenfunction:: path_join
:project: progguide
.. doxygenfunction:: file_is_readable
:project: progguide
.. doxygenfunction:: is_console
:project: progguide
.. doxygenfunction:: path_is_directory
:project: progguide
.. doxygenfunction:: current_directory
:project: progguide
.. doxygenfunction:: list_directory
:project: progguide
.. doxygenfunction:: chdir
:project: progguide
.. doxygenfunction:: mkdir
:project: progguide
.. doxygenfunction:: rmdir
:project: progguide
.. doxygenfunction:: unlink
:project: progguide
Standard I/O function wrappers
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. doxygenvariable:: END_OF_FILE
:project: progguide
.. doxygenfunction:: ftell
:project: progguide
.. doxygenfunction:: fseek
:project: progguide
.. doxygenfunction:: ftruncate
:project: progguide
.. doxygenfunction:: popen
:project: progguide
.. doxygenfunction:: pclose
:project: progguide
Environment variable functions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. doxygenfunction:: putenv
:project: progguide
.. doxygenfunction:: unsetenv
:project: progguide
.. doxygenfunction:: list_pathenv
:project: progguide
.. doxygenfunction:: find_exe_path
:project: progguide
Dynamically loaded object or library functions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. doxygenfunction:: dlopen
:project: progguide
.. doxygenfunction:: dlclose
:project: progguide
.. doxygenfunction:: dlsym
:project: progguide
.. doxygenfunction:: dlerror
:project: progguide
Compressed file I/O functions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. doxygenfunction:: has_compress_extension
:project: progguide
.. doxygenfunction:: compressed_read
:project: progguide
.. doxygenfunction:: compressed_write
:project: progguide

49
doc/src/Developer_plugins.rst
View File

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

128
doc/src/Developer_utils.rst
View File

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

6
doc/src/Developer_write.rst
View File

@ -29,7 +29,9 @@ of code in the header before include guards:
.. code-block:: c
#ifdef FIX_CLASS
FixStyle(print/vel,FixPrintVel)
// clang-format off
FixStyle(print/vel,FixPrintVel);
// clang-format on
#else
/* the definition of the FixPrintVel class comes here */
...
@ -53,7 +55,7 @@ of each timestep. First of all, implement a constructor:
if (narg < 4)
error->all(FLERR,"Illegal fix print/vel command");
nevery = force->inumeric(FLERR,arg[3]);
nevery = utils::inumeric(FLERR,arg[3],false,lmp);
if (nevery <= 0)
error->all(FLERR,"Illegal fix print/vel command");
}

10
doc/src/Errors_messages.rst
View File

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

2
doc/src/Errors_warnings.rst
View File

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

4
doc/src/Examples.rst
View File

@ -80,7 +80,7 @@ Lowercase directories
+-------------+------------------------------------------------------------------+
| friction | frictional contact of spherical asperities between 2d surfaces |
+-------------+------------------------------------------------------------------+
| gcmc | Grand Canonical Monte Carlo (GCMC) via the fix gcmc command |
| mc | Monte Carlo features via fix gcmc, widom and other commands |
+-------------+------------------------------------------------------------------+
| granregion | use of fix wall/region/gran as boundary on granular particles |
+-------------+------------------------------------------------------------------+
@ -205,7 +205,7 @@ Uppercase directories
+------------+--------------------------------------------------------------------------------------------------+
| KAPPA | compute thermal conductivity via several methods |
+------------+--------------------------------------------------------------------------------------------------+
| MC | using LAMMPS in a Monte Carlo mode to relax the energy of a system |
| MC-LOOP | using LAMMPS in a Monte Carlo mode to relax the energy of a system in a input script loop |
+------------+--------------------------------------------------------------------------------------------------+
| PACKAGES | examples for specific packages and contributed commands |
+------------+--------------------------------------------------------------------------------------------------+

5
doc/src/Howto_drude2.rst
View File

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

134
doc/src/Howto_github.rst
View File

@ -7,11 +7,11 @@ LAMMPS GitHub tutorial
This document describes the process of how to use GitHub to integrate
changes or additions you have made to LAMMPS into the official LAMMPS
distribution. It uses the process of updating this very tutorial as
an example to describe the individual steps and options. You need to
be familiar with git and you may want to have a look at the
`git book <http://git-scm.com/book/>`_ to reacquaint yourself with some
of the more advanced git features used below.
distribution. It uses the process of updating this very tutorial as an
example to describe the individual steps and options. You need to be
familiar with git and you may want to have a look at the `git book
<http://git-scm.com/book/>`_ to familiarize yourself with some of the
more advanced git features used below.
As of fall 2016, submitting contributions to LAMMPS via pull requests
on GitHub is the preferred option for integrating contributed features
@ -37,15 +37,15 @@ username or e-mail address and password.
**Forking the repository**
To get changes into LAMMPS, you need to first fork the `lammps/lammps`
repository on GitHub. At the time of writing, *master* is the preferred
repository on GitHub. At the time of writing, *develop* is the preferred
target branch. Thus go to `LAMMPS on GitHub <https://github.com/lammps/lammps>`_
and make sure branch is set to "master", as shown in the figure below.
and make sure branch is set to "develop", as shown in the figure below.
.. image:: JPG/tutorial_branch.png
:align: center
If it is not, use the button to change it to *master*\ . Once it is, use the
fork button to create a fork.
If it is not, use the button to change it to *develop*. Once it is, use
the fork button to create a fork.
.. image:: JPG/tutorial_fork.png
:align: center
@ -64,11 +64,12 @@ LAMMPS development.
**Adding changes to your own fork**
Additions to the upstream version of LAMMPS are handled using *feature
branches*\ . For every new feature, a so-called feature branch is
branches*. For every new feature, a so-called feature branch is
created, which contains only those modification relevant to one specific
feature. For example, adding a single fix would consist of creating a
branch with only the fix header and source file and nothing else. It is
explained in more detail here: `feature branch workflow <https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow>`_.
explained in more detail here: `feature branch workflow
<https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow>`_.
**Feature branches**
@ -94,8 +95,8 @@ The above command copies ("clones") the git repository to your local
machine to a directory with the name you chose. If none is given, it will
default to "lammps". Typical names are "mylammps" or something similar.
You can use this local clone to make changes and
test them without interfering with the repository on GitHub.
You can use this local clone to make changes and test them without
interfering with the repository on GitHub.
To pull changes from upstream into this copy, you can go to the directory
and use git pull:
@ -103,28 +104,46 @@ and use git pull:
.. code-block:: bash
$ cd mylammps
$ git checkout master
$ git pull https://github.com/lammps/lammps
$ git checkout develop
$ git pull https://github.com/lammps/lammps develop
You can also add this URL as a remote:
.. code-block:: bash
$ git remote add lammps_upstream https://www.github.com/lammps/lammps
$ git remote add upstream https://www.github.com/lammps/lammps
At this point, you typically make a feature branch from the updated master
From then on you can update your upstream branches with:
.. code-block:: bash
$ git fetch upstream
and then refer to the upstream repository branches with
`upstream/develop` or `upstream/release` and so on.
At this point, you typically make a feature branch from the updated
branch for the feature you want to work on. This tutorial contains the
workflow that updated this tutorial, and hence we will call the branch
"github-tutorial-update":
.. code-block:: bash
$ git checkout -b github-tutorial-update master
$ git fetch upstream
$ git checkout -b github-tutorial-update upstream/develop
Now that we have changed branches, we can make our changes to our local
repository. Just remember that if you want to start working on another,
unrelated feature, you should switch branches!
.. note::
Committing changes to the *develop*, *release*, or *stable* branches
is strongly discouraged. While it may be convenient initially, it
will create more work in the long run. Various texts and tutorials
on using git effectively discuss the motivation for using feature
branches instead.
**After changes are made**
After everything is done, add the files to the branch and commit them:
@ -287,28 +306,32 @@ After each push, the automated checks are run again.
LAMMPS developers may add labels to your pull request to assign it to
categories (mostly for bookkeeping purposes), but a few of them are
important: needs_work, work_in_progress, test-for-regression, and
full-regression-test. The first two indicate, that your pull request
is not considered to be complete. With "needs_work" the burden is on
exclusively on you; while "work_in_progress" can also mean, that a
LAMMPS developer may want to add changes. Please watch the comments
to the pull requests. The two "test" labels are used to trigger
extended tests before the code is merged. This is sometimes done by
LAMMPS developers, if they suspect that there may be some subtle
side effects from your changes. It is not done by default, because
those tests are very time consuming.
important: *needs_work*, *work_in_progress*, *run_tests*,
*test_for_regression*, and *ready_for_merge*. The first two indicate,
that your pull request is not considered to be complete. With
"needs_work" the burden is on exclusively on you; while
"work_in_progress" can also mean, that a LAMMPS developer may want to
add changes. Please watch the comments to the pull requests. The two
"test" labels are used to trigger extended tests before the code is
merged. This is sometimes done by LAMMPS developers, if they suspect
that there may be some subtle side effects from your changes. It is not
done by default, because those tests are very time consuming. The
*ready_for_merge* label is usually attached when the LAMMPS developer
assigned to the pull request considers this request complete and to
trigger a final full test evaluation.
**Reviews**
As of Summer 2018, a pull request needs at least 1 approving review
from a LAMMPS developer with write access to the repository.
In case your changes touch code that certain developers are associated
with, they are auto-requested by the GitHub software. Those associations
are set in the file
`.github/CODEOWNERS <https://github.com/lammps/lammps/blob/master/.github/CODEOWNERS>`_
Thus if you want to be automatically notified to review when anybody
changes files or packages, that you have contributed to LAMMPS, you can
add suitable patterns to that file, or a LAMMPS developer may add you.
As of Fall 2021, a pull request needs to pass all automatic tests and at
least 1 approving review from a LAMMPS developer with write access to
the repository before it is eligible for merging. In case your changes
touch code that certain developers are associated with, they are
auto-requested by the GitHub software. Those associations are set in
the file `.github/CODEOWNERS
<https://github.com/lammps/lammps/blob/develop/.github/CODEOWNERS>`_ Thus
if you want to be automatically notified to review when anybody changes
files or packages, that **you** have contributed to LAMMPS, you can add
suitable patterns to that file, or a LAMMPS developer may add you.
Otherwise, you can also manually request reviews from specific developers,
or LAMMPS developers - in their assessment of your pull request - may
@ -329,7 +352,7 @@ LAMMPS developer (including him/herself) or c) Axel Kohlmeyer (akohlmey).
After the review, the developer can choose to implement changes directly
or suggest them to you.
* Case c) means that the pull request has been assigned to the developer
overseeing the merging of pull requests into the master branch.
overseeing the merging of pull requests into the *develop* branch.
In this case, Axel assigned the tutorial to Steve:
@ -351,11 +374,11 @@ Sometimes, however, you might not feel comfortable having other people
push changes into your own branch, or maybe the maintainers are not sure
their idea was the right one. In such a case, they can make changes,
reassign you as the assignee, and file a "reverse pull request", i.e.
file a pull request in your GitHub repository to include changes in the
branch, that you have submitted as a pull request yourself. In that
case, you can choose to merge their changes back into your branch,
possibly make additional changes or corrections and proceed from there.
It looks something like this:
file a pull request in **your** forked GitHub repository to include
changes in the branch, that you have submitted as a pull request
yourself. In that case, you can choose to merge their changes back into
your branch, possibly make additional changes or corrections and proceed
from there. It looks something like this:
.. image:: JPG/tutorial_reverse_pull_request.png
:align: center
@ -419,7 +442,7 @@ This merge also shows up on the lammps GitHub page:
**After a merge**
When everything is fine, the feature branch is merged into the master branch:
When everything is fine, the feature branch is merged into the *develop* branch:
.. image:: JPG/tutorial_merged.png
:align: center
@ -433,8 +456,8 @@ branch!
.. code-block:: bash
$ git checkout master
$ git pull master
$ git checkout develop
$ git pull https://github.com/lammps/lammps develop
$ git branch -d github-tutorial-update
If you do not pull first, it is not really a problem but git will warn
@ -442,6 +465,7 @@ you at the next statement that you are deleting a local branch that
was not yet fully merged into HEAD. This is because git does not yet
know your branch just got merged into LAMMPS upstream. If you
first delete and then pull, everything should still be fine.
You can display all branches that are fully merged by:
Finally, if you delete the branch locally, you might want to push this
to your remote(s) as well:
@ -453,14 +477,14 @@ to your remote(s) as well:
**Recent changes in the workflow**
Some changes to the workflow are not captured in this tutorial. For
example, in addition to the master branch, to which all new features
should be submitted, there is now also an "unstable" and a "stable"
branch; these have the same content as "master", but are only updated
after a patch release or stable release was made.
Furthermore, the naming of the patches now follow the pattern
"patch_<Day><Month><Year>" to simplify comparisons between releases.
Finally, all patches and submissions are subject to automatic testing
and code checks to make sure they at the very least compile.
example, in addition to the *develop* branch, to which all new features
should be submitted, there is also a *release* and a *stable* branch;
these have the same content as *develop*, but are only updated after a
patch release or stable release was made. Furthermore, the naming of
the patches now follow the pattern "patch_<Day><Month><Year>" to
simplify comparisons between releases. Finally, all patches and
submissions are subject to automatic testing and code checks to make
sure they at the very least compile.
A discussion of the LAMMPS developer GitHub workflow can be found in the file
`doc/github-development-workflow.md <https://github.com/lammps/lammps/blob/master/doc/github-development-workflow.md>`_
`doc/github-development-workflow.md <https://github.com/lammps/lammps/blob/develop/doc/github-development-workflow.md>`_

2
doc/src/Howto_pylammps.rst
View File

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

55
doc/src/Howto_structured_data.rst
View File

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

80
doc/src/Howto_thermostat.rst
View File

@ -2,8 +2,8 @@ Thermostats
===========
Thermostatting means controlling the temperature of particles in an MD
simulation. :doc:`Barostatting <Howto_barostat>` means controlling the
pressure. Since the pressure includes a kinetic component due to
simulation. :doc:`Barostatting <Howto_barostat>` means controlling
the pressure. Since the pressure includes a kinetic component due to
particle velocities, both these operations require calculation of the
temperature. Typically a target temperature (T) and/or pressure (P)
is specified by the user, and the thermostat or barostat attempts to
@ -26,11 +26,13 @@ can be invoked via the *dpd/tstat* pair style:
* :doc:`pair_style dpd/tstat <pair_dpd>`
:doc:`Fix nvt <fix_nh>` only thermostats the translational velocity of
particles. :doc:`Fix nvt/sllod <fix_nvt_sllod>` also does this, except
that it subtracts out a velocity bias due to a deforming box and
integrates the SLLOD equations of motion. See the :doc:`Howto nemd <Howto_nemd>` page for further details. :doc:`Fix nvt/sphere <fix_nvt_sphere>` and :doc:`fix nvt/asphere <fix_nvt_asphere>` thermostat not only translation
velocities but also rotational velocities for spherical and aspherical
particles.
particles. :doc:`Fix nvt/sllod <fix_nvt_sllod>` also does this,
except that it subtracts out a velocity bias due to a deforming box
and integrates the SLLOD equations of motion. See the :doc:`Howto
nemd <Howto_nemd>` page for further details. :doc:`Fix nvt/sphere
<fix_nvt_sphere>` and :doc:`fix nvt/asphere <fix_nvt_asphere>`
thermostat not only translation velocities but also rotational
velocities for spherical and aspherical particles.
.. note::
@ -40,25 +42,31 @@ particles.
e.g. molecular systems. The latter can be tricky to do correctly.
DPD thermostatting alters pairwise interactions in a manner analogous
to the per-particle thermostatting of :doc:`fix langevin <fix_langevin>`.
to the per-particle thermostatting of :doc:`fix langevin
<fix_langevin>`.
Any of the thermostatting fixes can be instructed to use custom temperature
computes that remove bias which has two effects: first, the current
calculated temperature, which is compared to the requested target temperature,
is calculated with the velocity bias removed; second, the thermostat adjusts
only the thermal temperature component of the particle's velocities, which are
the velocities with the bias removed. The removed bias is then added back
to the adjusted velocities. See the doc pages for the individual
fixes and for the :doc:`fix_modify <fix_modify>` command for
instructions on how to assign a temperature compute to a
thermostatting fix. For example, you can apply a thermostat to only
the x and z components of velocity by using it in conjunction with
:doc:`compute temp/partial <compute_temp_partial>`. Of you could
thermostat only the thermal temperature of a streaming flow of
particles without affecting the streaming velocity, by using
:doc:`compute temp/profile <compute_temp_profile>`.
Any of the thermostatting fixes can be instructed to use custom
temperature computes that remove bias which has two effects: first,
the current calculated temperature, which is compared to the requested
target temperature, is calculated with the velocity bias removed;
second, the thermostat adjusts only the thermal temperature component
of the particle's velocities, which are the velocities with the bias
removed. The removed bias is then added back to the adjusted
velocities. See the doc pages for the individual fixes and for the
:doc:`fix_modify <fix_modify>` command for instructions on how to
assign a temperature compute to a thermostatting fix.
Below is a list of some custom temperature computes that can be used like that:
For example, you can apply a thermostat only to atoms in a spatial
region by using it in conjunction with :doc:`compute temp/region
<compute_temp_region>`. Or you can apply a thermostat to only the x
and z components of velocity by using it with :doc:`compute
temp/partial <compute_temp_partial>`. Of you could thermostat only
the thermal temperature of a streaming flow of particles without
affecting the streaming velocity, by using :doc:`compute temp/profile
<compute_temp_profile>`.
Below is a list of custom temperature computes that can be used like
that:
* :doc:`compute_temp_asphere`
* :doc:`compute_temp_body`
@ -72,8 +80,6 @@ Below is a list of some custom temperature computes that can be used like that:
* :doc:`compute_temp_rotate`
* :doc:`compute_temp_sphere`
.. note::
Only the nvt fixes perform time integration, meaning they update
@ -86,17 +92,17 @@ Below is a list of some custom temperature computes that can be used like that:
* :doc:`fix nve/sphere <fix_nve_sphere>`
* :doc:`fix nve/asphere <fix_nve_asphere>`
Thermodynamic output, which can be setup via the
:doc:`thermo_style <thermo_style>` command, often includes temperature
values. As explained on the page for the
:doc:`thermo_style <thermo_style>` command, the default temperature is
setup by the thermo command itself. It is NOT the temperature
associated with any thermostatting fix you have defined or with any
compute you have defined that calculates a temperature. The doc pages
for the thermostatting fixes explain the ID of the temperature compute
they create. Thus if you want to view these temperatures, you need to
specify them explicitly via the :doc:`thermo_style custom <thermo_style>` command. Or you can use the
:doc:`thermo_modify <thermo_modify>` command to re-define what
Thermodynamic output, which can be setup via the :doc:`thermo_style
<thermo_style>` command, often includes temperature values. As
explained on the page for the :doc:`thermo_style <thermo_style>`
command, the default temperature is setup by the thermo command
itself. It is NOT the temperature associated with any thermostatting
fix you have defined or with any compute you have defined that
calculates a temperature. The doc pages for the thermostatting fixes
explain the ID of the temperature compute they create. Thus if you
want to view these temperatures, you need to specify them explicitly
via the :doc:`thermo_style custom <thermo_style>` command. Or you can
use the :doc:`thermo_modify <thermo_modify>` command to re-define what
temperature compute is used for default thermodynamic output.
----------

59
doc/src/Install_git.rst
View File

@ -9,7 +9,8 @@ has several advantages:
command.
* You can create your own development branches to add code to LAMMPS.
* You can submit your new features back to GitHub for inclusion in
LAMMPS.
LAMMPS. For that you should first create your own :doc:`fork on
GitHub <Howto_github>`.
You must have `git <git_>`_ installed on your system to use the
commands explained below to communicate with the git servers on
@ -20,35 +21,56 @@ provides `limited support for subversion clients <svn_>`_.
As of October 2016, the official home of public LAMMPS development is
on GitHub. The previously advertised LAMMPS git repositories on
git.lammps.org and bitbucket.org are now deprecated or offline.
git.lammps.org and bitbucket.org are now offline or deprecated.
.. _git: https://git-scm.com
.. _svn: https://help.github.com/en/github/importing-your-projects-to-github/working-with-subversion-on-github
You can follow LAMMPS development on 3 different git branches:
You can follow the LAMMPS development on 3 different git branches:
* **stable** : this branch is updated with every stable release
* **unstable** : this branch is updated with every patch release
* **master** : this branch continuously follows ongoing development
* **stable** : this branch is updated from the *release* branch with
every stable release version and also has selected bug fixes and updates
back-ported from the *develop* branch
* **release** : this branch is updated with every patch release;
updates are always "fast forward" merges from *develop*
* **develop** : this branch follows the ongoing development and
is updated with every merge commit of a pull request
To access the git repositories on your box, use the clone command to
create a local copy of the LAMMPS repository with a command like:
.. code-block:: bash
$ git clone -b unstable https://github.com/lammps/lammps.git mylammps
$ git clone -b release https://github.com/lammps/lammps.git mylammps
where "mylammps" is the name of the directory you wish to create on
your machine and "unstable" is one of the 3 branches listed above.
your machine and "release" is one of the 3 branches listed above.
(Note that you actually download all 3 branches; you can switch
between them at any time using "git checkout <branch name>".)
.. admonition:: Saving time and disk space when using ``git clone``
The complete git history of the LAMMPS project is quite large because
it contains the entire commit history of the project since fall 2006,
which includes the time when LAMMPS was managed with subversion.
This includes a few commits that have added and removed some large
files (mostly by accident). If you do not need access to the entire
commit history (most people don't), you can speed up the "cloning"
process and reduce local disk space requirements by using the
*--depth* git command line flag. That will create a "shallow clone"
of the repository containing only a subset of the git history. Using
a depth of 1000 is usually sufficient to include the head commits of
the *develop* and the *release* branches. To include the head commit
of the *stable* branch you may need a depth of up to 10000. If you
later need more of the git history, you can always convert the
shallow clone into a "full clone".
Once the command completes, your directory will contain the same files
as if you unpacked a current LAMMPS tarball, with the exception, that
the HTML documentation files are not included. They can be fetched
from the LAMMPS website by typing ``make fetch`` in the doc directory.
Or they can be generated from the content provided in doc/src by
typing ``make html`` from the doc directory.
Or they can be generated from the content provided in ``doc/src`` by
typing ``make html`` from the ``doc`` directory.
After initial cloning, as bug fixes and new features are added to
LAMMPS you can stay up-to-date by typing the following git commands
@ -56,9 +78,9 @@ from within the "mylammps" directory:
.. code-block:: bash
$ git checkout unstable # not needed if you always stay in this branch
$ git checkout stable # use one of these 3 checkout commands
$ git checkout master # to choose the branch to follow
$ git checkout release # not needed if you always stay in this branch
$ git checkout stable # use one of these 3 checkout commands
$ git checkout develop # to choose the branch to follow
$ git pull
Doing a "pull" will not change any files you have added to the LAMMPS
@ -81,7 +103,7 @@ Stable versions and what tagID to use for a particular stable version
are discussed on `this page <https://www.lammps.org/bug.html#version>`_.
Note that this command will print some warnings, because in order to get
back to the latest revision and to be able to update with ``git pull``
again, you will need to do ``git checkout unstable`` (or
again, you will need to do ``git checkout release`` (or
check out any other desired branch) first.
Once you have updated your local files with a ``git pull`` (or ``git
@ -137,11 +159,10 @@ changed. How to do this depends on the build system you are using.
.. admonition:: Git protocols
:class: note
The servers at github.com support the "git://" and "https://" access
protocols for anonymous, read-only access. If you have a suitably
configured GitHub account, you may also use SSH protocol with the
The servers at github.com support the "https://" access protocol for
anonymous, read-only access. If you have a suitably configured GitHub
account, you may also use SSH protocol with the
URL "git@github.com:lammps/lammps.git".
The LAMMPS GitHub project is currently managed by Axel Kohlmeyer
(Temple U, akohlmey at gmail.com) and Richard Berger (Temple U,
richard.berger at temple.edu).
(Temple U, akohlmey at gmail.com).

2
doc/src/Intro_authors.rst
View File

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

2
doc/src/Intro_citing.rst
View File

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

2
doc/src/Intro_opensource.rst
View File

@ -19,7 +19,7 @@ software and open-source distribution, see `www.gnu.org <gnuorg_>`_
or `www.opensource.org <opensource_>`_. The legal text of the GPL as it
applies to LAMMPS is in the LICENSE file included in the LAMMPS distribution.
.. _gpl: https://github.com/lammps/lammps/blob/master/LICENSE
.. _gpl: https://github.com/lammps/lammps/blob/develop/LICENSE
.. _lgpl: https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html

6
doc/src/Library_utility.rst
View File

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

26
doc/src/Manual_version.rst
View File

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

17
doc/src/Modify.rst
View File

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

15
doc/src/Modify_overview.rst
View File

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

38
doc/src/Modify_pair.rst
View File

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

51
doc/src/Modify_style.rst
View File

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

67
doc/src/Modify_thermo.rst
View File

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

19
doc/src/Modify_variable.rst
View File

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

13
doc/src/Packages_details.rst
View File

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

118
doc/src/Python_install.rst
View File

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

4
doc/src/Run_output.rst
View File

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

2
doc/src/Speed.rst
View File

@ -14,7 +14,7 @@ Intel Xeon Phi co-processors.
The `Benchmark page <https://www.lammps.org/bench.html>`_ of the LAMMPS
website gives performance results for the various accelerator
packages discussed on the :doc:`Speed packages <Speed_packages>` doc
packages discussed on the :doc:`Accelerator packages <Speed_packages>`
page, for several of the standard LAMMPS benchmark problems, as a
function of problem size and number of compute nodes, on different
hardware platforms.

2
doc/src/Speed_kokkos.rst
View File

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

29
doc/src/Tools.rst
View File

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

4
doc/src/accel_styles.rst
View File

@ -1,7 +1,7 @@
Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
hardware, as discussed on the :doc:`Accelerator packages <Speed_packages>`
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
@ -13,5 +13,5 @@ You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
:doc:`suffix <suffix>` command in your input script.
See the :doc:`Speed packages <Speed_packages>` page for more
See the :doc:`Accelerator packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.

18
doc/src/angle_charmm.rst
View File

@ -56,23 +56,7 @@ radian\^2.
----------
Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, INTEL, KOKKOS,
OPENMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
:doc:`suffix <suffix>` command in your input script.
See :doc:`Speed packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.
.. include:: accel_styles.rst
----------

38
doc/src/angle_class2.rst
View File

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

23
doc/src/atom_style.rst
View File

@ -319,28 +319,9 @@ styles; see the :doc:`Modify <Modify>` doc page.
----------
Styles with a *kk* suffix are functionally the same as the
corresponding style without the suffix. They have been optimized to
run faster, depending on your available hardware, as discussed in on
the :doc:`Speed packages <Speed_packages>` doc page. The accelerated
styles take the same arguments and should produce the same results,
except for round-off and precision issues.
.. include:: accel_styles.rst
Note that other acceleration packages in LAMMPS, specifically the GPU,
INTEL, OPENMP, and OPT packages do not use accelerated atom
styles.
The accelerated styles are part of the KOKKOS package. They are only
enabled if LAMMPS was built with those packages. See the :doc:`Build
package <Build_package>` page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line
switch <Run_options>` when you invoke LAMMPS, or you can use the
:doc:`suffix <suffix>` command in your input script.
See the :doc:`Speed packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.
----------
Restrictions
""""""""""""

2
doc/src/balance.rst
View File

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

46
doc/src/bond_fene.rst
View File

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

1
doc/src/bond_style.rst
View File

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

5
doc/src/compute.rst
View File

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

101
doc/src/compute_ave_sphere_atom.rst Normal file
View File

@ -0,0 +1,101 @@
.. index:: compute ave/sphere/atom
.. index:: compute ave/sphere/atom/kk
compute ave/sphere/atom command
================================
Accelerator Variants: *ave/sphere/atom/kk*
Syntax
""""""
.. parsed-literal::
compute ID group-ID ave/sphere/atom keyword values ...
* ID, group-ID are documented in :doc:`compute <compute>` command
* ave/sphere/atom = style name of this compute command
* one or more keyword/value pairs may be appended
.. parsed-literal::
keyword = *cutoff*
*cutoff* value = distance cutoff
Examples
""""""""
.. code-block:: LAMMPS
compute 1 all ave/sphere/atom
compute 1 all ave/sphere/atom cutoff 5.0
comm_modify cutoff 5.0
Description
"""""""""""
Define a computation that calculates the local density and temperature
for each atom and neighbors inside a spherical cutoff.
The optional keyword *cutoff* defines the distance cutoff
used when searching for neighbors. The default value is the cutoff
specified by the pair style. If no pair style is defined, then a cutoff
must be defined using this keyword. If the specified cutoff is larger than
that of the pair_style plus neighbor skin (or no pair style is defined),
the *comm_modify cutoff* option must also be set to match that of the
*cutoff* keyword.
The neighbor list needed to compute this quantity is constructed each
time the calculation is performed (i.e. each time a snapshot of atoms
is dumped). Thus it can be inefficient to compute/dump this quantity
too frequently.
.. note::
If you have a bonded system, then the settings of
:doc:`special_bonds <special_bonds>` command can remove pairwise
interactions between atoms in the same bond, angle, or dihedral. This
is the default setting for the :doc:`special_bonds <special_bonds>`
command, and means those pairwise interactions do not appear in the
neighbor list. Because this fix uses the neighbor list, it also means
those pairs will not be included in the order parameter. This
difficulty can be circumvented by writing a dump file, and using the
:doc:`rerun <rerun>` command to compute the order parameter for
snapshots in the dump file. The rerun script can use a
:doc:`special_bonds <special_bonds>` command that includes all pairs in
the neighbor list.
----------
.. include:: accel_styles.rst
----------
Output info
"""""""""""
This compute calculates a per-atom array with two columns: density and temperature.
These values can be accessed by any command that uses per-atom values
from a compute as input. See the :doc:`Howto output <Howto_output>` doc
page for an overview of LAMMPS output options.
Restrictions
""""""""""""
This compute is part of the EXTRA-COMPUTE package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
Related commands
""""""""""""""""
:doc:`comm_modify <comm_modify>`
Default
"""""""
The option defaults are *cutoff* = pair style cutoff

6
doc/src/compute_bond_local.rst
View File

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

21
doc/src/compute_heat_flux.rst
View File

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

9
doc/src/compute_momentum.rst
View File

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

14
doc/src/compute_pair_local.rst
View File

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

2
doc/src/compute_pressure.rst
View File

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

Some files were not shown because too many files have changed in this diff Show More