tx258/lammps-gran-kokkos
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'develop' into bugfix/bond-react-peratom-mass

Browse Source
This commit is contained in:
FelixWodaczek
2025-06-13 16:39:44 +02:00
parent d7cd2795c5 0d2f47ddd4
commit 2c9dac5505
3051 changed files with 324253 additions and 85754 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
.github/CODEOWNERS vendored
View File

@ -71,7 +71,10 @@ src/EXTRA-COMMAND/group_ndx.* @akohlmey
src/EXTRA-COMMAND/ndx_group.* @akohlmey
src/EXTRA-COMPUTE/compute_stress_mop*.* @RomainVermorel
src/EXTRA-COMPUTE/compute_born_matrix.* @Bibobu @athomps
src/EXTRA-DUMP/dump_extxyz.* @fxcoudert
src/EXTRA-FIX/fix_deform_pressure.* @jtclemm
src/EXTRA-PAIR/pair_dispersion_d3.* @soniasolomoni @arthurfl
src/EXTRA-PAIR/d3_parameters.h @soniasolomoni @arthurfl
src/MISC/*_tracker.* @jtclemm
src/MC/fix_gcmc.* @athomps
src/MC/fix_sgcmc.* @athomps
@ -101,7 +104,8 @@ src/group.* @sjplimp
src/improper.* @sjplimp
src/info.* @akohlmey
src/kspace.* @sjplimp
src/lmptyp.h @sjplimp
src/lmptype.h @sjplimp
src/label_map.* @jrgissing @akohlmey
src/library.* @sjplimp @akohlmey
src/main.cpp @sjplimp
src/min_*.* @sjplimp

370
.github/release_steps.md vendored Normal file
View File

@ -0,0 +1,370 @@
# LAMMPS Release Steps
The following notes chronicle the current steps for preparing and
publishing LAMMPS releases. For definitions of LAMMPS versions and
releases, please refer to [the corresponding section in the LAMMPS
manual](https://docs.lammps.org/Manual_version.html).
## LAMMPS Feature Release
A LAMMPS feature release is currently prepared after about 500 to 750
commits to the 'develop' branch or after a period of four weeks up to
two months. This is not a fixed rule, though, since external
circumstances can cause delays in preparing a release, or pull requests
that are desired to be merged for the release are not yet completed.
### Preparing a 'next\_release' branch
Create a 'next\_release' branch off 'develop' and make the following changes:
- set the LAMMPS\_VERSION define to the planned release date in
src/version.h in the format "D Mmm YYYY" or "DD Mmm YYYY"
- remove the LAMMPS\_UPDATE define in src/version.h
- update the release date in doc/lammps.1
- update all TBD arguments for ..versionadded::, ..versionchanged::
..deprecated:: to the planned release date in the format "DMmmYYYY" or
"DDMmmYYYY"
- check release notes for merged new features and check if
..versionadded:: or ..versionchanged:: are missing and need to be
added
Submit this pull request. This is the last pull request merged for the
release and should not contain any other changes. (Exceptions: this
document, last minute trivial(!) changes).
This PR shall not be merged before **all** pending tests have completed
and cleared. We currently use a mix of automated tests running on
either Temple's Jenkins cluster or GitHub workflows. Those include time
consuming tests not run on pull requests. If needed, a bug-fix pull
request should be created and merged to clear all tests.
### Create release on GitHub
When all pending pull requests for the release are merged and have
cleared testing, the 'next\_release' branch is merged into 'develop'.
Check out or update the 'develop' branch locally, pull the latest
changes, merge them into 'release' with a fast forward(!) merge, and
apply a suitable release tag (for historical reasons the tag starts with
"patch_" followed by the date, and finally push everything back to
GitHub. There should be no commits made to 'release' but only
fast forward merges. Example:
```
git checkout develop
git pull
git checkout release
git pull
git merge --ff-only develop
git tag -s -m "LAMMPS feature release 4 February 2025" patch_4Feb2025
git push git@github.com:lammps/lammps.git --tags develop release
```
Applying this tag will trigger two actions on the Temple Jenkins cluster:
- The online manual at https://docs.lammps.org/ will be updated to the
state of the 'release' branch. Merges to the 'develop' branch will
trigger updating https://docs.lammps.org/latest/ so by reviewing the
version of the manual under the "latest" URL, it is possible to preview
what the updated release documentation will look like.
- A downloadable tar archive of the LAMMPS distribution that includes the
html format documentation and a PDF of the manual will be created and
uploaded to the download server at https://download.lammps.org/tars
Note that the file is added, but the `index.html` file is not updated,
so it is not yet publicly visible.
Go to https://github.com/lammps/lammps/releases and create a new (draft)
release page with a summary of all the changes included and references
to the pull requests they were merged from or check the existing draft
for any necessary changes from pull requests that were merged but are
not listed. Then select the applied tag for the release in the "Choose
a tag" drop-down list. Go to the bottom of the list and select the "Set
as pre-release" checkbox. The "Set as the latest release" button is
reserved for stable releases and updates to them.
If everything is in order, you can click on the "Publish release"
button. Otherwise, click on "Save draft" and finish pending tasks until
you can return to edit the release page and publish it.
### Prepare pre-compiled packages, update packages to GitHub
A suitable build environment is provided with the
https://download.lammps.org/static/fedora41_musl_mingw.sif container
image. The corresponding container build definition file is maintained
in the tools/singularity folder of the LAMMPS source distribution.
#### Fully portable static Linux x86_64 non-MPI binaries
The following commands use the Fedora container to build a fully static
LAMMPS installation using a musl-libc cross-compiler, install it into a
`lammps-static` folder, and create a tarball called
`lammps-linux-x86_64-4Feb2025.tar.gz` (or using a corresponding date
with a future release) from the `lammps-static` folder.
``` sh
rm -rf release-packages
mkdir release-packages
cd release-packages
wget https://download.lammps.org/static/fedora41_musl_mingw.sif
apptainer shell fedora41_musl_mingw.sif
git clone -b release --depth 10 https://github.com/lammps/lammps.git lammps-release
cmake -S lammps-release/cmake -B build-release -G Ninja -D CMAKE_INSTALL_PREFIX=$PWD/lammps-static -D CMAKE_TOOLCHAIN_FILE=/usr/musl/share/cmake/linux-musl.cmake -C lammps-release/cmake/presets/most.cmake -C lammps-release/cmake/presets/kokkos-openmp.cmake -D DOWNLOAD_POTENTIALS=OFF -D BUILD_MPI=OFF -D BUILD_TESTING=OFF -D CMAKE_BUILD_TYPE=Release -D PKG_ATC=ON -D PKG_AWPMD=ON -D PKG_MANIFOLD=ON -D PKG_MESONT=ON -D PKG_MGPT=ON -D PKG_ML-PACE=ON -D PKG_ML-RANN=ON -D PKG_MOLFILE=ON -D PKG_PTM=ON -D PKG_QTB=ON -D PKG_SMTBQ=ON
cmake --build build-release --target all
cmake --build build-release --target install
/usr/musl/bin/x86_64-linux-musl-strip lammps-static/bin/*
tar -czvvf ../lammps-linux-x86_64-4Feb2025.tar.gz lammps-static
exit # fedora 41 container
cd ..
```
The resulting tar archive can be uploaded to the GitHub release page with:
``` sh
gh release upload patch_4Feb2025 lammps-linux-x86_64-4Feb2025.tar.gz
```
#### Linux x86_64 Flatpak bundle with GUI included
Make sure you have the `flatpak` and `flatpak-builder` packages
installed locally (they require binaries that run with elevated
privileges and thus cannot be used from the container) and build a
LAMMPS and LAMMPS-GUI flatpak bundle in the `release-packages` folder
with:
``` sh
cd release-packages
flatpak --user remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
flatpak-builder --force-clean --verbose --repo=$PWD/flatpak-repo --install-deps-from=flathub --state-dir=$PWD --user --ccache --default-branch=release flatpak-build lammps-release/tools/lammps-gui/org.lammps.lammps-gui.yml
flatpak build-bundle --runtime-repo=https://flathub.org/repo/flathub.flatpakrepo --verbose $PWD/flatpak-repo ../LAMMPS-Linux-x86_64-GUI-4Feb2025.flatpak org.lammps.lammps-gui release
cd ..
```
The resulting flatpak bundle file can be uploaded to the GitHub release page with:
``` sh
gh release upload patch_4Feb2025 LAMMPS-Linux-x86_64-GUI-4Feb2025.flatpak
```
#### LAMMPS Source tarball
The container for the static binary can also be used to prepare the source
tarball including the HTML and PDF manual (this is currently done automatically
when the releases is created and the tarball uploaded to https://download.lammps.org/tars/).
The steps are as follows:
``` sh
cd release-packages
apptainer shell fedora41_musl_mingw.sif
cd lammps-release
rm -f ../release.tar*
git archive --output=../release.tar --prefix=lammps-4Feb2025/ HEAD
cd doc
make clean-all
make html pdf
tar -rf ../../release.tar --transform 's,^,lammps-4Feb2025/doc/,' html Manual.pdf
gzip -9v ../../release.tar
mv ../../release.tar.gz ../../lammps-src-4Feb2025.tar.gz
exit # fedora41 container
cd ..
```
The resulting source tarball can be uploaded to the GitHub release page with:
``` sh
gh release upload patch_4Feb2025 lammps-src-4Feb2025.tar.gz
```
#### Build Windows Installer Packages with MinGW Linux-to-Windows Cross-compiler
The various Windows installer packages can also be built with
apptainer container image.
``` sh
cd release-packages
apptainer shell fedora41_musl_mingw.sif
git clone --depth 10 https://github.com/lammps/lammps-packages.git lammps-packages
cd lammps-packages/mingw-cross
ln -sf ../../lammps-release lammps
./buildall.sh release >& mk.log & less +F mk.log
```
The installer with the GUI included can be uploaded to the GitHub release page with:
``` sh
ln -sf LAMMPS-64bit-GUI-4Feb2025.exe LAMMPS-Win10-64bit-GUI-4Feb2025.exe
gh release upload patch_4Feb2025 LAMMPS-Win10-64bit-GUI-4Feb2025.exe
```
The symbolic link is used to have a consistent naming scheme for the packages
attached to the GitHub release page.
#### Clean up:
``` sh
cd ..
rm -r release-packages
```
#### Build Multi-arch App-bundle with GUI for macOS
Building app-bundles for macOS is not as easily automated and portable
as some of the other steps. It requires a machine actually running
macOS. In that machine the Xcode compiler package needs to be
installed. This also includes tools for building and manipulating disk
images. This compiler supports building executables for both, the
x86_64 and the arm64 architectures. This requires building with CMake
and using the CMake settings:
``` sh
-D CMAKE_OSX_ARCHITECTURES=arm64;x86_64
-D CMAKE_OSX_DEPLOYMENT_TARGET=11.0
```
This will add the compiler flags `-arch arm64 -arch x86_64
-mmacosx-version-min=11.0` and thus produce object for both
architectures and support for macOS versions back to version 11 (aka Big
Sur). With these settings the following libraries should be compiled
and installed (e.g. to `$HOME/.local`) as static libraries only:
- libomp taken from the LLVM/Clang source distribution (to support OpenMP)
- jpeg
- zlib
- png
- Qt (for LAMMPS-GUI)
When configuring LAMMPS the `cmake/presets/clang.cmake` should be used
and as many packages as possible enabled. For LAMMPS-GUI, MPI should be
disabled with `-D BUILD_MPI=OFF` and LAMMPS-GUI enabled with
`-D BUILD_LAMMPS_GUI=ON`. If the CMake configuration is successful,
settings for building a macOS app-bundle are enabled and with `cmake
--build build --target dmg` extra steps will be executed that will build
a macOS application installer image under the name
`LAMMPS_GUI-macOS-multiarch-4Feb2025.dmg`
The application image can be uploaded to the GitHub release page with:
``` sh
ln -sf LAMMPS_GUI-macOS-multiarch-4Feb2025.dmg LAMMPS-macOS-multiarch-GUI-4Feb2025.dmg
gh release upload patch_4Feb2025 LAMMPS-macOS-multiarch-GUI-4Feb2025.dmg
```
The symbolic link is used to have a consistent naming scheme for the packages
attached to the GitHub release page.
We are currently building the application images on macOS 12 (aka Monterey).
#### Build Linux x86_64 binary tarball with GUI on Ubuntu 20.04LTS
While the flatpak Linux version uses portable runtime libraries provided
by the flatpak environment, we also build regular Linux executables that
use a wrapper script and matching shared libraries in a tarball. To be
compatible with many Linux distributions, one has to build this on a
very old Linux distribution, since most Linux system libraries are
usually backward compatible but not forward compatible. This is
currently done on an Ubuntu 20.04LTS system. Once LAMMPS moves to
require CMake 3.20 and C++17, we will have to move to Ubuntu 22.04LTS.
This installation (either on a real or a virtual machine) should have
the packages installed that are indicated in
`tools/singularity/ubuntu20.04.def` plus Qt version 5.x with development
headers, so that LAMMPS-GUI can be compiled.
Also the building of the binary tarball and setup of the bundled
libraries and wrapper scripts is automated and can executed with `cmake
--build build --target tgz`. This should produce a file
`LAMMPS_GUI-Linux-amd64-4Feb2025.tar.gz` which can be uploaded to the
GitHub release page with:
``` sh
ln -sf LAMMPS_GUI-Linux-amd64-4Feb2025.tar.gz LAMMPS-Linux-x86_64-GUI-4Feb2025.tar.gz
gh release upload patch_4Feb2025 LAMMPS-Linux-x86_64-GUI-4Feb2025.tar.gz
```
### Update download page on LAMMPS website
Check out the LAMMPS website repo
https://github.com/lammps/lammps-website.git and edit the file
`src/download.txt` for the new release. Test translation with `make
html` and review `html/download.html` Then add and commit to git and
push the changes to GitHub. The Temple Jenkis cluster will
automatically update https://www.lammps.org/download.html accordingly.
Also notify Steve of the release so he can update `src/bug.txt` on the
website from the available release notes.
## LAMMPS Stable Release
A LAMMPS stable release is prepared about once per year in the months
July, August, or September. One (or two, if needed) feature releases
before the stable release shall contain only bug fixes or minor feature
updates in optional packages. Also substantial changes to the core of
the code shall be applied rather toward the beginning of a development
cycle between two stable releases than toward the end. The intention is
to stablilize significant change to the core and have outside users and
developers try them out during the development cycle; the sooner the
changes are included, the better chances for spotting peripheral bugs
and issues.
### Prerequesites
Before making a stable release all remaining backported bugfixes shall
be released as a (final) stable update release (see below).
A LAMMPS stable release process starts like a feature release (see
above), only that this feature release is called a "Stable Release
Candidate" and no assets are uploaded to GitHub.
### Synchronize 'maintenance' branch with 'release'
The state of the 'release' branch is then transferred to the
'maintenance' branch (which will have diverged significantly from
'release' due to the selectively backported bug fixes).
### Fast-forward merge of 'maintenance' into 'stable' and apply tag
At this point it should be possible to do a fast-forward merge of
'maintenance' to 'stable' and then apply the stable\_DMmmYYYY tag.
### Push branches and tags
## LAMMPS Stable Update Release
After making a stable release, bugfixes from the 'develop' branch
are selectively backported to the 'maintenance' branch. This is
done with "git cherry-pick \<commit hash\>' wherever possible.
The LAMMPS\_UPDATE define in "src/version.h" is set to "Maintenance".
### Prerequesites
When a sufficient number of bugfixes has accumulated or an urgent
or important bugfix needs to be distributed a new stable update
release is made. To make this publicly visible a pull request
is submitted that will merge 'maintenance' into 'stable'. Before
merging, set LAMMPS\_UPDATE in "src/version.h" to "Update #" with
"#" indicating the update count (1, 2, and so on).
Also draft suitable release notes under https://github.com/lammps/lammps/releases
### Fast-forward merge of 'maintenance' into 'stable', apply tag, and publish
Do a fast-forward merge of 'maintenance' to 'stable' and then
apply the stable\_DMmmYYYY\_update# tag and push branch and tag
to GitHub. The corresponding pull request will be automatically
closed. Example:
```
git checkout maintenance
git pull
git checkout stable
git pull
git merge --ff-only maintenance
git tag -s -m 'Update 2 for Stable LAMMPS version 29 August 2024' stable_29Aug2024_update2
git push git@github.com:lammps/lammps.git --tags maintenance stable
```
Associate draft release notes with new tag and publish as "latest release".
On https://ci.lammps.org/ go to "dev", "stable" and manually execute
the "update\_release" task. This will update https://docs.lammps.org/stable
and prepare a stable tarball.
### Build and upload binary packages and source tarball to GitHub
The build procedure is the same as for the feature releases, only
that packages are built from the 'stable' branch.

103
.github/workflows/check-cpp23.yml vendored Normal file
View File

@ -0,0 +1,103 @@
# GitHub action to build LAMMPS on Linux with gcc or clang and C++23
name: "Check for C++23 Compatibility"
on:
push:
branches:
- develop
pull_request:
branches:
- develop
workflow_dispatch:
concurrency:
group: ${{ github.event_name }}-${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: ${{github.event_name == 'pull_request'}}
jobs:
build:
name: Build with C++23 support enabled
if: ${{ github.repository == 'lammps/lammps' }}
runs-on: ubuntu-latest
strategy:
max-parallel: 2
matrix:
idx: [ gcc, clang ]
env:
CCACHE_DIR: ${{ github.workspace }}/.ccache
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
fetch-depth: 2
- name: Install extra packages
run: |
sudo apt-get update
sudo apt-get install -y ccache \
clang \
libcurl4-openssl-dev \
libeigen3-dev \
libfftw3-dev \
libomp-dev \
mold \
mpi-default-bin \
mpi-default-dev \
ninja-build \
python3-dev
- name: Create Build Environment
run: mkdir build
- name: Set up ccache
uses: actions/cache@v4
with:
path: ${{ env.CCACHE_DIR }}
key: linux-cpp23-ccache-${{ github.sha }}
restore-keys: linux-cpp23-ccache-
- name: Building LAMMPS via CMake
shell: bash
run: |
ccache -z
python3 -m venv linuxenv
source linuxenv/bin/activate
python3 -m pip install numpy
python3 -m pip install pyyaml
cmake -S cmake -B build \
-C cmake/presets/most.cmake \
-C cmake/presets/kokkos-openmp.cmake \
-C cmake/presets/${{ matrix.idx }}.cmake \
-D CMAKE_CXX_STANDARD=23 \
-D CMAKE_CXX_COMPILER_LAUNCHER=ccache \
-D CMAKE_C_COMPILER_LAUNCHER=ccache \
-D CMAKE_BUILD_TYPE=Debug \
-D CMAKE_CXX_FLAGS_DEBUG="-Og -g" \
-D DOWNLOAD_POTENTIALS=off \
-D FFT=KISS \
-D BUILD_MPI=on \
-D BUILD_SHARED_LIBS=on \
-D BUILD_TOOLS=off \
-D ENABLE_TESTING=off \
-D MLIAP_ENABLE_ACE=on \
-D MLIAP_ENABLE_PYTHON=off \
-D PKG_AWPMD=on \
-D PKG_GPU=on \
-D GPU_API=opencl \
-D PKG_KOKKOS=on \
-D PKG_LATBOLTZ=on \
-D PKG_MDI=on \
-D PKG_MANIFOLD=on \
-D PKG_ML-PACE=on \
-D PKG_ML-RANN=off \
-D PKG_MOLFILE=on \
-D PKG_RHEO=on \
-D PKG_PTM=on \
-D PKG_PYTHON=on \
-D PKG_QTB=on \
-D PKG_SMTBQ=on \
-G Ninja
cmake --build build
ccache -s

2
.github/workflows/check-vla.yml vendored
View File

@ -77,7 +77,7 @@ jobs:
-D PKG_MDI=on \
-D PKG_MANIFOLD=on \
-D PKG_ML-PACE=on \
-D PKG_ML-RANN=off \
-D PKG_ML-RANN=on \
-D PKG_MOLFILE=on \
-D PKG_RHEO=on \
-D PKG_PTM=on \

1
.github/workflows/coverity.yml vendored
View File

@ -67,7 +67,6 @@ jobs:
-D PKG_MANIFOLD=on \
-D PKG_MDI=on \
-D PKG_MGPT=on \
-D PKG_ML-PACE=on \
-D PKG_ML-RANN=on \
-D PKG_MOLFILE=on \
-D PKG_NETCDF=on \

126
.github/workflows/kokkos-regression.yaml vendored Normal file
View File

@ -0,0 +1,126 @@
# GitHub action to build LAMMPS on Linux and run selected regression tests
name: "Kokkos OpenMP Regression Test"
on:
push:
branches:
- develop
workflow_dispatch:
jobs:
build:
name: Build LAMMPS with Kokkos OpenMP
# restrict to official LAMMPS repository
if: ${{ github.repository == 'lammps/lammps' }}
runs-on: ubuntu-latest
env:
CCACHE_DIR: ${{ github.workspace }}/.ccache
strategy:
max-parallel: 6
matrix:
idx: [ 'pair-0', 'pair-1', 'fix-0', 'fix-1', 'compute', 'misc' ]
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
fetch-depth: 2
show-progress: false
- name: Install extra packages
run: |
sudo apt-get update
sudo apt-get install -y ccache ninja-build libeigen3-dev \
libcurl4-openssl-dev python3-dev \
mpi-default-bin mpi-default-dev
- name: Create Build Environment
run: mkdir build
- name: Set up ccache
uses: actions/cache@v4
with:
path: ${{ env.CCACHE_DIR }}
key: linux-kokkos-ccache-${{ github.sha }}
restore-keys: linux-kokkos-ccache-
- name: Building LAMMPS via CMake
shell: bash
run: |
ccache -z
python3 -m venv linuxenv
source linuxenv/bin/activate
python3 -m pip install --upgrade pip
python3 -m pip install numpy pyyaml junit_xml
cmake -S cmake -B build \
-C cmake/presets/gcc.cmake \
-C cmake/presets/basic.cmake \
-C cmake/presets/kokkos-openmp.cmake \
-D CMAKE_CXX_COMPILER_LAUNCHER=ccache \
-D CMAKE_C_COMPILER_LAUNCHER=ccache \
-D BUILD_SHARED_LIBS=off \
-D DOWNLOAD_POTENTIALS=off \
-D PKG_AMOEBA=on \
-D PKG_ASPHERE=on \
-D PKG_BROWNIAN=on \
-D PKG_CLASS2=on \
-D PKG_COLLOID=on \
-D PKG_CORESHELL=on \
-D PKG_DIPOLE=on \
-D PKG_DPD-BASIC=on \
-D PKG_EXTRA-COMPUTE=on \
-D PKG_EXTRA-FIX=on \
-D PKG_EXTRA-MOLECULE=on \
-D PKG_EXTRA-PAIR=on \
-D PKG_GRANULAR=on \
-D PKG_LEPTON=on \
-D PKG_MC=on \
-D PKG_MEAM=on \
-D PKG_POEMS=on \
-D PKG_PYTHON=on \
-D PKG_QEQ=on \
-D PKG_REAXFF=on \
-D PKG_REPLICA=on \
-D PKG_SRD=on \
-D PKG_SPH=on \
-D PKG_VORONOI=on \
-G Ninja
cmake --build build
ccache -s
- name: Run Regression Tests for Selected Examples
shell: bash
run: |
source linuxenv/bin/activate
python3 tools/regression-tests/get_kokkos_input.py \
--examples-top-level=examples --batch-size=50 \
--filter-out="balance;fire;gcmc;granregion;hyper;mc;mdi;mliap;neb;pace;prd;pour;python;rigid;snap;streitz;shear;ttm"
export OMP_PROC_BIND=false
python3 tools/regression-tests/run_tests.py \
--lmp-bin=build/lmp \
--config-file=tools/regression-tests/config_kokkos_openmp.yaml \
--list-input=input-list-${{ matrix.idx }}-kk.txt \
--output-file=output-${{ matrix.idx }}.xml \
--progress-file=progress-${{ matrix.idx }}.yaml \
--log-file=run-${{ matrix.idx }}.log \
--quick-max=100
tar -cvf kokkos-regression-test-${{ matrix.idx }}.tar run-${{ matrix.idx }}.log progress-${{ matrix.idx }}.yaml output-${{ matrix.idx }}.xml
- name: Upload artifacts
uses: actions/upload-artifact@v4
with:
name: kokkos-regression-test-artifact-${{ matrix.idx }}
path: kokkos-regression-test-${{ matrix.idx }}.tar
merge:
runs-on: ubuntu-latest
needs: build
steps:
- name: Merge Artifacts
uses: actions/upload-artifact/merge@v4
with:
name: merged-kokkos-regresssion-artifact
pattern: kokkos-regression-test-artifact-*

53
.github/workflows/lammps-gui-flatpak.yml vendored Normal file
View File

@ -0,0 +1,53 @@
# GitHub action to build LAMMPS-GUI as a flatpak bundle
name: "Build LAMMPS-GUI as flatpak bundle"
on:
push:
branches:
- develop
workflow_dispatch:
concurrency:
group: ${{ github.event_name }}-${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: ${{github.event_name == 'pull_request'}}
jobs:
build:
name: LAMMPS-GUI flatpak build
if: ${{ github.repository == 'lammps/lammps' }}
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
fetch-depth: 2
- name: Install extra packages
run: |
sudo apt-get update
sudo apt-get install -y ccache \
libeigen3-dev \
libcurl4-openssl-dev \
mold \
ninja-build \
python3-dev \
flatpak \
flatpak-builder
- name: Set up access to flatpak repo
run: flatpak --user remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
- name: Build flatpak
run: |
mkdir flatpack-state
sed -i -e 's/branch:.*/branch: develop/' tools/lammps-gui/org.lammps.lammps-gui.yml
flatpak-builder --force-clean --verbose --repo=flatpak-repo \
--install-deps-from=flathub --state-dir=flatpak-state \
--user --ccache --default-branch=${{ github.ref_name }} \
flatpak-build tools/lammps-gui/org.lammps.lammps-gui.yml
flatpak build-bundle --runtime-repo=https://flathub.org/repo/flathub.flatpakrepo \
--verbose flatpak-repo LAMMPS-Linux-x86_64-GUI.flatpak \
org.lammps.lammps-gui ${{ github.ref_name }}
flatpak install -y -v --user LAMMPS-Linux-x86_64-GUI.flatpak

1
.github/workflows/style-check.yml vendored
View File

@ -35,3 +35,4 @@ jobs:
make check-permissions
make check-homepage
make check-errordocs
make check-fmtlib

81
.github/workflows/unittest-arm64.yml vendored Normal file
View File

@ -0,0 +1,81 @@
# GitHub action to build LAMMPS on Linux with ARM64 and run standard unit tests
name: "Unittest for Linux on ARM64"
on:
push:
branches: [develop]
workflow_dispatch:
concurrency:
group: ${{ github.event_name }}-${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: ${{github.event_name == 'pull_request'}}
jobs:
build:
name: Linux ARM64 Unit Test
if: ${{ github.repository == 'lammps/lammps' }}
runs-on: ubuntu-22.04-arm
env:
CCACHE_DIR: ${{ github.workspace }}/.ccache
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
fetch-depth: 2
- name: Install extra packages
run: |
sudo apt-get update
sudo apt-get install -y ccache \
libeigen3-dev \
libcurl4-openssl-dev \
mold \
ninja-build \
python3-dev
- name: Create Build Environment
run: mkdir build
- name: Set up ccache
uses: actions/cache@v4
with:
path: ${{ env.CCACHE_DIR }}
key: linux-unit-ccache-${{ github.sha }}
restore-keys: linux-unit-ccache-
- name: Building LAMMPS via CMake
shell: bash
run: |
ccache -z
python3 -m venv linuxenv
source linuxenv/bin/activate
python3 -m pip install numpy
python3 -m pip install pyyaml
cmake -S cmake -B build \
-C cmake/presets/gcc.cmake \
-C cmake/presets/most.cmake \
-D CMAKE_CXX_COMPILER_LAUNCHER=ccache \
-D CMAKE_C_COMPILER_LAUNCHER=ccache \
-D BUILD_SHARED_LIBS=on \
-D DOWNLOAD_POTENTIALS=off \
-D ENABLE_TESTING=on \
-D MLIAP_ENABLE_ACE=on \
-D MLIAP_ENABLE_PYTHON=off \
-D PKG_MANIFOLD=on \
-D PKG_ML-PACE=on \
-D PKG_ML-RANN=on \
-D PKG_RHEO=on \
-D PKG_PTM=on \
-D PKG_PYTHON=on \
-D PKG_QTB=on \
-D PKG_SMTBQ=on \
-G Ninja
cmake --build build
ccache -s
- name: Run Tests
working-directory: build
shell: bash
run: ctest -V -LE unstable

16
README
View File

@ -23,17 +23,21 @@ more information about the code and its uses.
The LAMMPS distribution includes the following files and directories:
README this file
LICENSE the GNU General Public License (GPL)
bench benchmark problems
LICENSE the GNU General Public License (GPLv2)
CITATION.cff Citation information for LAMMPS in CFF format
bench benchmark inputs
cmake CMake build files
doc documentation
examples simple test problems
fortran Fortran wrapper for LAMMPS
examples example inputs for many LAMMPS commands
fortran Fortran 2003 module for LAMMPS
lib additional provided or external libraries
potentials interatomic potential files
python Python wrappers for LAMMPS
python Python module for LAMMPS
src source files
third_party Copies of thirdparty software bundled with LAMMPS
tools pre- and post-processing tools
unittest test programs for use with CTest
.github Git and GitHub related files and tools
Point your browser at any of these files to get started:
@ -42,6 +46,8 @@ https://docs.lammps.org/Intro.html hi-level introduction
https://docs.lammps.org/Build.html how to build LAMMPS
https://docs.lammps.org/Run_head.html how to run LAMMPS
https://docs.lammps.org/Commands_all.html Table of available commands
https://docs.lammps.org/Howto.html Short tutorials and HowTo discussions
https://docs.lammps.org/Errors.html How to interpret and debug errors
https://docs.lammps.org/Library.html LAMMPS library interfaces
https://docs.lammps.org/Modify.html how to modify and extend LAMMPS
https://docs.lammps.org/Developer.html LAMMPS developer info

155
cmake/CMakeLists.txt
View File

@ -3,7 +3,14 @@
# CMake build system
# This file is part of LAMMPS
cmake_minimum_required(VERSION 3.16)
if(CMAKE_VERSION VERSION_LESS 3.20)
message(WARNING "LAMMPS is planning to require at least CMake version 3.20 by Summer 2025. Please upgrade!")
endif()
########################################
# initialize version variables with project command
if(POLICY CMP0048)
cmake_policy(SET CMP0048 NEW)
endif()
# set policy to silence warnings about ignoring <PackageName>_ROOT but use it
if(POLICY CMP0074)
cmake_policy(SET CMP0074 NEW)
@ -24,7 +31,10 @@ endif()
########################################
project(lammps CXX)
project(lammps
DESCRIPTION "The LAMMPS Molecular Dynamics Simulator"
HOMEPAGE_URL "https://www.lammps.org"
LANGUAGES CXX C)
set(SOVERSION 0)
get_property(BUILD_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
@ -41,6 +51,7 @@ set(LAMMPS_DOC_DIR ${LAMMPS_DIR}/doc)
set(LAMMPS_TOOLS_DIR ${LAMMPS_DIR}/tools)
set(LAMMPS_PYTHON_DIR ${LAMMPS_DIR}/python)
set(LAMMPS_POTENTIALS_DIR ${LAMMPS_DIR}/potentials)
set(LAMMPS_THIRDPARTY_DIR ${LAMMPS_DIR}/third_party)
set(LAMMPS_DOWNLOADS_URL "https://download.lammps.org" CACHE STRING "Base URL for LAMMPS downloads")
set(LAMMPS_POTENTIALS_URL "${LAMMPS_DOWNLOADS_URL}/potentials")
@ -102,58 +113,59 @@ 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")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /QxCOMMON-AVX512")
else()
set(CMAKE_TUNE_DEFAULT "/QxHost")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /QxHost")
endif()
else()
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")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -xCOMMON-AVX512")
else()
set(CMAKE_TUNE_DEFAULT "-xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=11074 -diag-disable=11076 -diag-disable=2196")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=11074 -diag-disable=11076 -diag-disable=2196")
endif()
endif()
endif()
# silence excessive warnings for new Intel Compilers
if(CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM")
set(CMAKE_TUNE_DEFAULT "-Wno-tautological-constant-compare -Wno-unused-command-line-argument")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fp-model precise -Wno-tautological-constant-compare -Wno-unused-command-line-argument")
endif()
# silence excessive warnings for PGI/NVHPC compilers
if((CMAKE_CXX_COMPILER_ID STREQUAL "NVHPC") OR (CMAKE_CXX_COMPILER_ID STREQUAL "PGI"))
set(CMAKE_TUNE_DEFAULT "-Minform=severe")
endif()
# this hack is required to compile fmt lib with CrayClang version 15.0.2
# CrayClang is only directly recognized by version 3.28 and later
if(CMAKE_VERSION VERSION_LESS 3.28)
get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
set(CMAKE_TUNE_DEFAULT "-DFMT_STATIC_THOUSANDS_SEPARATOR")
endif()
else()
if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
set(CMAKE_TUNE_DEFAULT "-DFMT_STATIC_THOUSANDS_SEPARATOR")
endif()
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Minform=severe")
endif()
# silence nvcc warnings
if((PKG_KOKKOS) AND (Kokkos_ENABLE_CUDA) AND NOT (CMAKE_CXX_COMPILER_ID STREQUAL "Clang"))
set(CMAKE_TUNE_DEFAULT "${CMAKE_TUNE_DEFAULT} -Xcudafe --diag_suppress=unrecognized_pragma")
if((PKG_KOKKOS) AND (Kokkos_ENABLE_CUDA) AND NOT
((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") OR (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM")
OR (CMAKE_CXX_COMPILER_ID STREQUAL "XLClang") OR (CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")))
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Xcudafe --diag_suppress=unrecognized_pragma,--diag_suppress=128")
endif()
# we require C++11 without extensions. Kokkos requires at least C++17 (currently)
# we *require* C++11 without extensions but prefer C++17.
# Kokkos requires at least C++17 (currently)
if(NOT CMAKE_CXX_STANDARD)
set(CMAKE_CXX_STANDARD 11)
if(cxx_std_17 IN_LIST CMAKE_CXX_COMPILE_FEATURES)
set(CMAKE_CXX_STANDARD 17)
else()
set(CMAKE_CXX_STANDARD 11)
endif()
endif()
if(CMAKE_CXX_STANDARD LESS 11)
message(FATAL_ERROR "C++ standard must be set to at least 11")
endif()
if(CMAKE_CXX_STANDARD LESS 17)
message(WARNING "Selecting C++17 standard is preferred over C++${CMAKE_CXX_STANDARD}")
endif()
if(PKG_KOKKOS AND (CMAKE_CXX_STANDARD LESS 17))
set(CMAKE_CXX_STANDARD 17)
endif()
# turn off C++17 check in lmptype.h
if(LAMMPS_CXX11)
add_compile_definitions(LAMMPS_CXX11)
endif()
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF CACHE BOOL "Use compiler extensions")
# ugly hacks for MSVC which by default always reports an old C++ standard in the __cplusplus macro
@ -165,6 +177,7 @@ if(MSVC)
add_compile_options(/wd4267)
add_compile_options(/wd4250)
add_compile_options(/EHsc)
add_compile_options(/utf-8)
endif()
add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
endif()
@ -190,10 +203,14 @@ if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND BUILD_SHARED_LIBS)
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
endif()
# do not include the (obsolete) MPI C++ bindings which makes for leaner object files
# and avoids namespace conflicts. Put this early to increase its visbility.
set(MPI_CXX_SKIP_MPICXX TRUE CACHE BOOL "Skip MPI C++ Bindings" FORCE)
########################################################################
# User input options #
########################################################################
# backward compatibility with CMake before 3.12 and older LAMMPS documentation
# backward compatibility with older LAMMPS documentation
if (PYTHON_EXECUTABLE)
set(Python_EXECUTABLE "${PYTHON_EXECUTABLE}")
endif()
@ -209,6 +226,12 @@ if(DEFINED ENV{VIRTUAL_ENV} AND NOT Python_EXECUTABLE)
" Setting Python interpreter to: ${Python_EXECUTABLE}")
endif()
find_package(Python COMPONENTS Interpreter QUIET)
# NOTE: RHEL 8.0 and Ubuntu 18.04LTS ship with Python 3.6, Python 3.8 was EOL in 2024
if(Python_VERSION VERSION_LESS 3.6)
message(FATAL_ERROR "LAMMPS requires Python 3.6 or later")
endif()
set(LAMMPS_MACHINE "" CACHE STRING "Suffix to append to lmp binary (WON'T enable any features automatically")
mark_as_advanced(LAMMPS_MACHINE)
if(LAMMPS_MACHINE)
@ -346,16 +369,27 @@ foreach(PKG ${STANDARD_PACKAGES} ${SUFFIX_PACKAGES})
option(PKG_${PKG} "Build ${PKG} Package" OFF)
endforeach()
set(DEPRECATED_PACKAGES AWPMD ATC POEMS)
foreach(PKG ${DEPRECATED_PACKAGES})
if(PKG_${PKG})
message(WARNING
"The ${PKG} package will be removed from LAMMPS in Summer 2025 due to lack of "
"maintenance and use of code constructs that conflict with modern C++ compilers "
"and standards. Please contact developers@lammps.org if you have any concerns "
"about this step.")
endif()
endforeach()
######################################################
# packages with special compiler needs or external libs
######################################################
target_include_directories(lammps PUBLIC $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}>)
target_include_directories(lammps PUBLIC $<BUILD_INTERFACE:${LAMMPS_THIRDPARTY_DIR}>)
if(PKG_ADIOS)
# The search for ADIOS2 must come before MPI because
# it includes its own MPI search with the latest FindMPI.cmake
# script that defines the MPI::MPI_C target
enable_language(C)
find_package(ADIOS2 REQUIRED)
if(BUILD_MPI)
if(NOT ADIOS2_HAVE_MPI)
@ -370,21 +404,18 @@ if(PKG_ADIOS)
endif()
if(NOT CMAKE_CROSSCOMPILING)
find_package(MPI QUIET)
find_package(MPI QUIET COMPONENTS CXX)
option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
else()
option(BUILD_MPI "Build MPI version" OFF)
endif()
if(BUILD_MPI)
# do not include the (obsolete) MPI C++ bindings which makes
# for leaner object files and avoids namespace conflicts
set(MPI_CXX_SKIP_MPICXX TRUE)
# We use a non-standard procedure to cross-compile with MPI on Windows
if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
include(MPI4WIN)
else()
find_package(MPI REQUIRED)
find_package(MPI REQUIRED COMPONENTS 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)
@ -398,8 +429,8 @@ else()
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)")
set(LAMMPS_SIZES_VALUES smallbig bigbig smallsmall)
set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
set(LAMMPS_SIZES_VALUES smallbig bigbig)
set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)
@ -417,6 +448,19 @@ if(NOT ${LAMMPS_MEMALIGN} STREQUAL "0")
target_compile_definitions(lammps PRIVATE -DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
endif()
# this hack is required to compile fmt lib with CrayClang version 15.0.2
# CrayClang is only directly recognized by CMake version 3.28 and later
if(CMAKE_VERSION VERSION_LESS 3.28)
get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
target_compile_definitions(lammps PRIVATE -DFMT_STATIC_THOUSANDS_SEPARATOR)
endif()
else()
if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
target_compile_definitions(lammps PRIVATE -DFMT_STATIC_THOUSANDS_SEPARATOR)
endif()
endif()
# "hard" dependencies between packages resulting
# in an error instead of skipping over files
pkg_depends(ML-IAP ML-SNAP)
@ -474,13 +518,13 @@ if(BUILD_OMP)
if(CMAKE_VERSION VERSION_LESS 3.28)
get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE}} -fopenmp")
set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE}} -fopenmp")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fopenmp")
set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} -fopenmp")
endif()
else()
if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE}} -fopenmp")
set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE}} -fopenmp")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fopenmp")
set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} -fopenmp")
endif()
endif()
endif()
@ -498,7 +542,6 @@ if((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_STANDARD GREATER_EQUA
endif()
if(PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_ML-POD OR PKG_ELECTRODE OR PKG_RHEO OR BUILD_TOOLS)
enable_language(C)
if (NOT USE_INTERNAL_LINALG)
find_package(LAPACK)
find_package(BLAS)
@ -578,6 +621,16 @@ foreach(PKG_WITH_INCL KSPACE PYTHON ML-IAP VORONOI COLVARS ML-HDNNP MDI MOLFILE
endif()
endforeach()
# settings for misc packages and styles
if(PKG_MISC)
option(LAMMPS_ASYNC_IMD "Asynchronous IMD processing" OFF)
mark_as_advanced(LAMMPS_ASYNC_IMD)
if(LAMMPS_ASYNC_IMD)
target_compile_definitions(lammps PRIVATE -DLAMMPS_ASYNC_IMD)
message(STATUS "Using IMD in asynchronous mode")
endif()
endif()
# optionally enable building script wrappers using swig
option(WITH_SWIG "Build scripting language wrappers with SWIG" OFF)
if(WITH_SWIG)
@ -585,15 +638,6 @@ if(WITH_SWIG)
add_subdirectory(${LAMMPS_SWIG_DIR} swig)
endif()
set(CMAKE_TUNE_FLAGS "${CMAKE_TUNE_DEFAULT}" CACHE STRING "Compiler and machine specific optimization flags (compilation only)")
separate_arguments(CMAKE_TUNE_FLAGS)
foreach(_FLAG ${CMAKE_TUNE_FLAGS})
target_compile_options(lammps PRIVATE ${_FLAG})
# skip these flags when linking the main executable
if(NOT (("${_FLAG}" STREQUAL "-Xcudafe") OR (("${_FLAG}" STREQUAL "--diag_suppress=unrecognized_pragma"))))
target_compile_options(lmp PRIVATE ${_FLAG})
endif()
endforeach()
########################################################################
# Basic system tests (standard libraries, headers, functions, types) #
########################################################################
@ -822,9 +866,15 @@ foreach(_DEF ${LAMMPS_DEFINES})
set(LAMMPS_API_DEFINES "${LAMMPS_API_DEFINES} -D${_DEF}")
endforeach()
if(BUILD_SHARED_LIBS)
install(TARGETS lammps EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
install(TARGETS lammps EXPORT LAMMPS_Targets
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR})
if(NOT BUILD_MPI)
install(TARGETS mpi_stubs EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
install(TARGETS mpi_stubs EXPORT LAMMPS_Targets
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR})
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)
@ -892,7 +942,7 @@ endif()
include(Testing)
include(CodeCoverage)
include(CodingStandard)
find_package(ClangFormat 11.0)
find_package(ClangFormat 11.0 QUIET)
if(ClangFormat_FOUND)
add_custom_target(format-src
@ -1076,12 +1126,15 @@ if(BUILD_TOOLS)
message(STATUS "<<< Building Tools >>>")
endif()
if(BUILD_LAMMPS_GUI)
message(STATUS "<<< Building LAMMPS GUI >>>")
message(STATUS "<<< Building LAMMPS-GUI >>>")
if(LAMMPS_GUI_USE_PLUGIN)
message(STATUS "Loading LAMMPS library as plugin at run time")
else()
message(STATUS "Linking LAMMPS library at compile time")
endif()
if(BUILD_WHAM)
message(STATUS "<<< Building WHAM >>>")
endif()
endif()
if(ENABLE_TESTING)
message(STATUS "<<< Building Unit Tests >>>")

120
cmake/Modules/CodeCoverage.cmake
View File

@ -7,76 +7,76 @@
# For Python coverage the coverage package needs to be installed
###############################################################################
if(ENABLE_COVERAGE)
find_program(GCOVR_BINARY gcovr)
find_package_handle_standard_args(GCOVR DEFAULT_MSG GCOVR_BINARY)
find_program(GCOVR_BINARY gcovr)
find_package_handle_standard_args(GCOVR DEFAULT_MSG GCOVR_BINARY)
find_program(COVERAGE_BINARY coverage)
find_package_handle_standard_args(COVERAGE DEFAULT_MSG COVERAGE_BINARY)
find_program(COVERAGE_BINARY coverage)
find_package_handle_standard_args(COVERAGE DEFAULT_MSG COVERAGE_BINARY)
if(GCOVR_FOUND)
get_filename_component(ABSOLUTE_LAMMPS_SOURCE_DIR ${LAMMPS_SOURCE_DIR} ABSOLUTE)
if(GCOVR_FOUND)
get_filename_component(ABSOLUTE_LAMMPS_SOURCE_DIR ${LAMMPS_SOURCE_DIR} ABSOLUTE)
add_custom_target(
gen_coverage_xml
COMMAND ${GCOVR_BINARY} -s -x -r ${ABSOLUTE_LAMMPS_SOURCE_DIR} --object-directory=${CMAKE_BINARY_DIR} -o coverage.xml
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
COMMENT "Generating XML coverage report..."
)
add_custom_target(
gen_coverage_xml
COMMAND ${GCOVR_BINARY} -s -x -r ${ABSOLUTE_LAMMPS_SOURCE_DIR} --object-directory=${CMAKE_BINARY_DIR} -o coverage.xml
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
COMMENT "Generating XML coverage report..."
)
set(COVERAGE_HTML_DIR ${CMAKE_BINARY_DIR}/coverage_html)
set(COVERAGE_HTML_DIR ${CMAKE_BINARY_DIR}/coverage_html)
add_custom_target(coverage_html_folder
COMMAND ${CMAKE_COMMAND} -E make_directory ${COVERAGE_HTML_DIR})
add_custom_target(coverage_html_folder
COMMAND ${CMAKE_COMMAND} -E make_directory ${COVERAGE_HTML_DIR})
add_custom_target(
gen_coverage_html
COMMAND ${GCOVR_BINARY} -s --html --html-details -r ${ABSOLUTE_LAMMPS_SOURCE_DIR} --object-directory=${CMAKE_BINARY_DIR} -o ${COVERAGE_HTML_DIR}/index.html
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
COMMENT "Generating HTML coverage report..."
)
add_dependencies(gen_coverage_html coverage_html_folder)
add_custom_target(
gen_coverage_html
COMMAND ${GCOVR_BINARY} -s --html --html-details -r ${ABSOLUTE_LAMMPS_SOURCE_DIR} --object-directory=${CMAKE_BINARY_DIR} -o ${COVERAGE_HTML_DIR}/index.html
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
COMMENT "Generating HTML coverage report..."
)
add_dependencies(gen_coverage_html coverage_html_folder)
add_custom_target(clean_coverage_html
${CMAKE_COMMAND} -E remove_directory ${COVERAGE_HTML_DIR}
COMMENT "Deleting HTML coverage report..."
)
add_custom_target(clean_coverage_html
${CMAKE_COMMAND} -E remove_directory ${COVERAGE_HTML_DIR}
COMMENT "Deleting HTML coverage report..."
)
add_custom_target(reset_coverage
${CMAKE_COMMAND} -E remove -f */*.gcda */*/*.gcda */*/*/*.gcda
*/*/*/*/*.gcda */*/*/*/*/*.gcda */*/*/*/*/*/*.gcda
*/*/*/*/*/*/*/*.gcda */*/*/*/*/*/*/*/*.gcda
*/*/*/*/*/*/*/*/*/*.gcda */*/*/*/*/*/*/*/*/*/*.gcda
WORKIND_DIRECTORY ${CMAKE_BINARY_DIR}
COMMENT "Deleting coverage data files..."
)
add_dependencies(reset_coverage clean_coverage_html)
endif()
add_custom_target(reset_coverage
${CMAKE_COMMAND} -E remove -f */*.gcda */*/*.gcda */*/*/*.gcda
*/*/*/*/*.gcda */*/*/*/*/*.gcda */*/*/*/*/*/*.gcda
*/*/*/*/*/*/*/*.gcda */*/*/*/*/*/*/*/*.gcda
*/*/*/*/*/*/*/*/*/*.gcda */*/*/*/*/*/*/*/*/*/*.gcda
WORKIND_DIRECTORY ${CMAKE_BINARY_DIR}
COMMENT "Deleting coverage data files..."
)
add_dependencies(reset_coverage clean_coverage_html)
endif()
if(COVERAGE_FOUND)
set(PYTHON_COVERAGE_HTML_DIR ${CMAKE_BINARY_DIR}/python_coverage_html)
configure_file(.coveragerc.in ${CMAKE_BINARY_DIR}/.coveragerc @ONLY)
if(COVERAGE_FOUND)
set(PYTHON_COVERAGE_HTML_DIR ${CMAKE_BINARY_DIR}/python_coverage_html)
configure_file(.coveragerc.in ${CMAKE_BINARY_DIR}/.coveragerc @ONLY)
add_custom_command(
OUTPUT ${CMAKE_BINARY_DIR}/unittest/python/.coverage
COMMAND ${COVERAGE_BINARY} combine
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/unittest/python
COMMENT "Combine Python coverage files..."
)
add_custom_command(
OUTPUT ${CMAKE_BINARY_DIR}/unittest/python/.coverage
COMMAND ${COVERAGE_BINARY} combine
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/unittest/python
COMMENT "Combine Python coverage files..."
)
add_custom_target(
gen_python_coverage_html
COMMAND ${COVERAGE_BINARY} html --rcfile=${CMAKE_BINARY_DIR}/.coveragerc -d ${PYTHON_COVERAGE_HTML_DIR}
DEPENDS ${CMAKE_BINARY_DIR}/unittest/python/.coverage ${CMAKE_BINARY_DIR}/.coveragerc
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/unittest/python
COMMENT "Generating HTML Python coverage report..."
)
add_custom_target(
gen_python_coverage_html
COMMAND ${COVERAGE_BINARY} html --rcfile=${CMAKE_BINARY_DIR}/.coveragerc -d ${PYTHON_COVERAGE_HTML_DIR}
DEPENDS ${CMAKE_BINARY_DIR}/unittest/python/.coverage ${CMAKE_BINARY_DIR}/.coveragerc
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/unittest/python
COMMENT "Generating HTML Python coverage report..."
)
add_custom_target(
gen_python_coverage_xml
COMMAND ${COVERAGE_BINARY} xml --rcfile=${CMAKE_BINARY_DIR}/.coveragerc -o ${CMAKE_BINARY_DIR}/python_coverage.xml
DEPENDS ${CMAKE_BINARY_DIR}/unittest/python/.coverage ${CMAKE_BINARY_DIR}/.coveragerc
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/unittest/python
COMMENT "Generating XML Python coverage report..."
)
endif()
add_custom_target(
gen_python_coverage_xml
COMMAND ${COVERAGE_BINARY} xml --rcfile=${CMAKE_BINARY_DIR}/.coveragerc -o ${CMAKE_BINARY_DIR}/python_coverage.xml
DEPENDS ${CMAKE_BINARY_DIR}/unittest/python/.coverage ${CMAKE_BINARY_DIR}/.coveragerc
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/unittest/python
COMMENT "Generating XML Python coverage report..."
)
endif()
endif()

67
cmake/Modules/CodingStandard.cmake
View File

@ -1,40 +1,39 @@
# use default (or custom) Python executable, if version is sufficient
if(Python_VERSION VERSION_GREATER_EQUAL 3.6)
# use default (or custom) Python executable.
# Python version check is in main CMakeLists.txt file
if(Python_EXECUTABLE)
set(Python3_EXECUTABLE ${Python_EXECUTABLE})
endif()
find_package(Python3 COMPONENTS Interpreter)
if(Python3_EXECUTABLE)
if(Python3_VERSION VERSION_GREATER_EQUAL 3.6)
add_custom_target(
check-whitespace
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/whitespace.py .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Check for whitespace errors")
add_custom_target(
check-homepage
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/homepage.py .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Check for homepage URL errors")
add_custom_target(
check-permissions
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/permissions.py .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Check for permission errors")
add_custom_target(
fix-whitespace
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/whitespace.py -f .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Fix whitespace errors")
add_custom_target(
fix-homepage
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/homepage.py -f .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Fix homepage URL errors")
add_custom_target(
fix-permissions
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/permissions.py -f .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Fix permission errors")
endif()
add_custom_target(
check-whitespace
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/whitespace.py .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Check for whitespace errors")
add_custom_target(
check-homepage
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/homepage.py .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Check for homepage URL errors")
add_custom_target(
check-permissions
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/permissions.py .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Check for permission errors")
add_custom_target(
fix-whitespace
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/whitespace.py -f .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Fix whitespace errors")
add_custom_target(
fix-homepage
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/homepage.py -f .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Fix homepage URL errors")
add_custom_target(
fix-permissions
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/permissions.py -f .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Fix permission errors")
endif()

7
cmake/Modules/Documentation.cmake
View File

@ -13,7 +13,7 @@ if(BUILD_DOC)
endif()
find_package(Python3 REQUIRED COMPONENTS Interpreter)
if(Python3_VERSION VERSION_LESS 3.8)
message(FATAL_ERROR "Python 3.8 and up is required to build the HTML documentation")
message(FATAL_ERROR "Python 3.8 and up is required to build the LAMMPS HTML documentation")
endif()
set(VIRTUALENV ${Python3_EXECUTABLE} -m venv)
@ -65,8 +65,8 @@ if(BUILD_DOC)
find_package(Sphinx)
endif()
set(MATHJAX_URL "https://github.com/mathjax/MathJax/archive/3.1.3.tar.gz" CACHE STRING "URL for MathJax tarball")
set(MATHJAX_MD5 "b81661c6e6ba06278e6ae37b30b0c492" CACHE STRING "MD5 checksum of MathJax tarball")
set(MATHJAX_URL "https://github.com/mathjax/MathJax/archive/3.2.2.tar.gz" CACHE STRING "URL for MathJax tarball")
set(MATHJAX_MD5 "08dd6ef33ca08870220d9aade2a62845" CACHE STRING "MD5 checksum of MathJax tarball")
mark_as_advanced(MATHJAX_URL)
GetFallbackURL(MATHJAX_URL MATHJAX_FALLBACK)
@ -110,6 +110,7 @@ if(BUILD_DOC)
add_custom_command(
OUTPUT html
DEPENDS ${DOC_SOURCES} ${DOCENV_DEPS} ${DOXYGEN_XML_DIR}/index.xml ${BUILD_DOC_CONFIG_FILE}
COMMAND ${Python3_EXECUTABLE} ${LAMMPS_DOC_DIR}/utils/make-globbed-tocs.py -d ${LAMMPS_DOC_DIR}/src
COMMAND Sphinx::sphinx-build ${SPHINX_EXTRA_OPTS} -b html -c ${DOC_BUILD_DIR} -d ${DOC_BUILD_DIR}/doctrees ${LAMMPS_DOC_DIR}/src ${DOC_BUILD_DIR}/html
COMMAND ${CMAKE_COMMAND} -E create_symlink Manual.html ${DOC_BUILD_DIR}/html/index.html
COMMAND ${CMAKE_COMMAND} -E copy_directory ${LAMMPS_DOC_DIR}/src/PDF ${DOC_BUILD_DIR}/html/PDF

6
cmake/Modules/FindVORO.cmake
View File

@ -21,9 +21,9 @@ if(VORO_FOUND)
set(VORO_LIBRARIES ${VORO_LIBRARY})
set(VORO_INCLUDE_DIRS ${VORO_INCLUDE_DIR})
if(NOT TARGET VORO::VORO)
add_library(VORO::VORO UNKNOWN IMPORTED)
set_target_properties(VORO::VORO PROPERTIES
if(NOT TARGET VORO::voro++)
add_library(VORO::voro++ UNKNOWN IMPORTED)
set_target_properties(VORO::voro++ PROPERTIES
IMPORTED_LOCATION "${VORO_LIBRARY}"
INTERFACE_INCLUDE_DIRECTORIES "${VORO_INCLUDE_DIR}")
endif()

128
cmake/Modules/LAMMPSInterfacePlugin.cmake
View File

@ -34,8 +34,26 @@ if(MSVC)
add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
endif()
# C++11 is required
set(CMAKE_CXX_STANDARD 11)
if(NOT CMAKE_CXX_STANDARD)
if(cxx_std_17 IN_LIST CMAKE_CXX_COMPILE_FEATURES)
set(CMAKE_CXX_STANDARD 17)
else()
set(CMAKE_CXX_STANDARD 11)
endif()
endif()
if(CMAKE_CXX_STANDARD LESS 11)
message(FATAL_ERROR "C++ standard must be set to at least 11")
endif()
if(CMAKE_CXX_STANDARD LESS 17)
message(WARNING "Selecting C++17 standard is preferred over C++${CMAKE_CXX_STANDARD}")
endif()
if(PKG_KOKKOS AND (CMAKE_CXX_STANDARD LESS 17))
set(CMAKE_CXX_STANDARD 17)
endif()
# turn off C++17 check in lmptype.h
if(LAMMPS_CXX11)
add_compile_definitions(LAMMPS_CXX11)
endif()
set(CMAKE_CXX_STANDARD_REQUIRED ON)
# Need -restrict with Intel compilers
@ -44,6 +62,9 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
endif()
set(CMAKE_POSITION_INDEPENDENT_CODE TRUE)
# skip over obsolete MPI-2 C++ bindings
set(MPI_CXX_SKIP_MPICXX TRUE)
#######
# helper functions from LAMMPSUtils.cmake
function(validate_option name values)
@ -110,8 +131,7 @@ endif()
################################################################################
# MPI configuration
if(NOT CMAKE_CROSSCOMPILING)
set(MPI_CXX_SKIP_MPICXX TRUE)
find_package(MPI QUIET)
find_package(MPI QUIET COMPONENTS CXX)
option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
else()
option(BUILD_MPI "Build MPI version" OFF)
@ -123,78 +143,38 @@ if(BUILD_MPI)
set(MPI_CXX_SKIP_MPICXX TRUE)
# We use a non-standard procedure to cross-compile with MPI on Windows
if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
# Download and configure MinGW compatible MPICH development files for Windows
option(USE_MSMPI "Use Microsoft's MS-MPI SDK instead of MPICH2-1.4.1" OFF)
if(USE_MSMPI)
message(STATUS "Downloading and configuring MS-MPI 10.1 for Windows cross-compilation")
set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/msmpi-win64-devel.tar.gz" CACHE STRING "URL for MS-MPI (win64) tarball")
set(MPICH2_WIN64_DEVEL_MD5 "86314daf1bffb809f1fcbefb8a547490" CACHE STRING "MD5 checksum of MS-MPI (win64) tarball")
mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
message(STATUS "Downloading and configuring MS-MPI 10.1 for Windows cross-compilation")
set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/msmpi-win64-devel.tar.gz" CACHE STRING "URL for MS-MPI (win64) tarball")
set(MPICH2_WIN64_DEVEL_MD5 "86314daf1bffb809f1fcbefb8a547490" CACHE STRING "MD5 checksum of MS-MPI (win64) tarball")
mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
include(ExternalProject)
if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
ExternalProject_Add(mpi4win_build
URL ${MPICH2_WIN64_DEVEL_URL}
URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmsmpi.a)
else()
message(FATAL_ERROR "Only x86 64-bit builds are supported with MS-MPI")
endif()
ExternalProject_get_property(mpi4win_build SOURCE_DIR)
file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
set_target_properties(MPI::MPI_CXX PROPERTIES
IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmsmpi.a"
INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
add_dependencies(MPI::MPI_CXX mpi4win_build)
# set variables for status reporting at the end of CMake run
set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmsmpi.a")
include(ExternalProject)
if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
ExternalProject_Add(mpi4win_build
URL ${MPICH2_WIN64_DEVEL_URL}
URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmsmpi.a)
else()
# Download and configure custom MPICH files for Windows
message(STATUS "Downloading and configuring MPICH-1.4.1 for Windows")
set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win64-devel.tar.gz" CACHE STRING "URL for MPICH2 (win64) tarball")
set(MPICH2_WIN64_DEVEL_MD5 "4939fdb59d13182fd5dd65211e469f14" CACHE STRING "MD5 checksum of MPICH2 (win64) tarball")
mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
include(ExternalProject)
if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
ExternalProject_Add(mpi4win_build
URL ${MPICH2_WIN64_DEVEL_URL}
URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
else()
ExternalProject_Add(mpi4win_build
URL ${MPICH2_WIN32_DEVEL_URL}
URL_MD5 ${MPICH2_WIN32_DEVEL_MD5}
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
endif()
ExternalProject_get_property(mpi4win_build SOURCE_DIR)
file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
set_target_properties(MPI::MPI_CXX PROPERTIES
IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmpi.a"
INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
add_dependencies(MPI::MPI_CXX mpi4win_build)
# set variables for status reporting at the end of CMake run
set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmpi.a")
message(FATAL_ERROR "Only x86 64-bit builds are supported with MS-MPI")
endif()
ExternalProject_get_property(mpi4win_build SOURCE_DIR)
file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
set_target_properties(MPI::MPI_CXX PROPERTIES
IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmsmpi.a"
INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX=1")
add_dependencies(MPI::MPI_CXX mpi4win_build)
# set variables for status reporting at the end of CMake run
set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX=1")
set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmsmpi.a")
else()
find_package(MPI REQUIRED)
find_package(MPI REQUIRED COMPONENTS 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 INTERFACE -DLAMMPS_LONGLONG_TO_LONG)
@ -242,8 +222,8 @@ endif()
################
# integer size selection
set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallsmall: all 32-bit, smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
set(LAMMPS_SIZES_VALUES smallbig bigbig smallsmall)
set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
set(LAMMPS_SIZES_VALUES smallbig bigbig)
set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)

24
cmake/Modules/LAMMPSUtils.cmake
View File

@ -30,7 +30,7 @@ function(check_omp_h_include)
if(OpenMP_CXX_FOUND)
set(CMAKE_REQUIRED_FLAGS ${OpenMP_CXX_FLAGS})
set(CMAKE_REQUIRED_INCLUDES ${OpenMP_CXX_INCLUDE_DIRS})
set(CMAKE_REQUIRED_LINK_OPTIONS ${OpenMP_CXX_FLAGS})
separate_arguments(CMAKE_REQUIRED_LINK_OPTIONS NATIVE_COMMAND ${OpenMP_CXX_FLAGS}) # needs to be a list
set(CMAKE_REQUIRED_LIBRARIES ${OpenMP_CXX_LIBRARIES})
# there are all kinds of problems with finding omp.h
# for Clang and derived compilers so we pretend it is there.
@ -75,13 +75,25 @@ function(get_lammps_version version_header variable)
list(FIND MONTHS "${month}" month)
string(LENGTH ${day} day_length)
string(LENGTH ${month} month_length)
if(day_length EQUAL 1)
set(day "0${day}")
# no leading zero needed for new version string with dots
# if(day_length EQUAL 1)
# set(day "0${day}")
# endif()
# if(month_length EQUAL 1)
# set(month "0${month}")
#endif()
file(STRINGS ${version_header} line REGEX LAMMPS_UPDATE)
string(REGEX REPLACE "#define LAMMPS_UPDATE \"Update ([0-9]+)\"" "\\1" tweak "${line}")
if (line MATCHES "#define LAMMPS_UPDATE \"(Maintenance|Development)\"")
set(tweak "99")
endif()
if(month_length EQUAL 1)
set(month "0${month}")
if(NOT tweak)
set(tweak "0")
endif()
set(${variable} "${year}${month}${day}" PARENT_SCOPE)
# new version string with dots
set(${variable} "${year}.${month}.${day}.${tweak}" PARENT_SCOPE)
# old version string without dots
# set(${variable} "${year}${month}${day}" PARENT_SCOPE)
endfunction()
function(check_for_autogen_files source_dir)

99
cmake/Modules/MPI4WIN.cmake
View File

@ -1,74 +1,31 @@
# Download and configure MinGW compatible MPICH development files for Windows
option(USE_MSMPI "Use Microsoft's MS-MPI SDK instead of MPICH2-1.4.1" OFF)
# set-up MS-MPI library for Windows with MinGW compatibility
message(STATUS "Downloading and configuring MS-MPI 10.1 for Windows cross-compilation")
set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/msmpi-win64-devel.tar.gz" CACHE STRING "URL for MS-MPI (win64) tarball")
set(MPICH2_WIN64_DEVEL_MD5 "86314daf1bffb809f1fcbefb8a547490" CACHE STRING "MD5 checksum of MS-MPI (win64) tarball")
mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
if(USE_MSMPI)
message(STATUS "Downloading and configuring MS-MPI 10.1 for Windows cross-compilation")
set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/msmpi-win64-devel.tar.gz" CACHE STRING "URL for MS-MPI (win64) tarball")
set(MPICH2_WIN64_DEVEL_MD5 "86314daf1bffb809f1fcbefb8a547490" CACHE STRING "MD5 checksum of MS-MPI (win64) tarball")
mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
include(ExternalProject)
if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
ExternalProject_Add(mpi4win_build
URL ${MPICH2_WIN64_DEVEL_URL}
URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmsmpi.a)
else()
message(FATAL_ERROR "Only x86 64-bit builds are supported with MS-MPI")
endif()
ExternalProject_get_property(mpi4win_build SOURCE_DIR)
file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
set_target_properties(MPI::MPI_CXX PROPERTIES
IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmsmpi.a"
INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
add_dependencies(MPI::MPI_CXX mpi4win_build)
# set variables for status reporting at the end of CMake run
set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmsmpi.a")
include(ExternalProject)
if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
ExternalProject_Add(mpi4win_build
URL ${MPICH2_WIN64_DEVEL_URL}
URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmsmpi.a)
else()
message(STATUS "Downloading and configuring MPICH2-1.4.1 for Windows cross-compilation")
set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win64-devel.tar.gz" CACHE STRING "URL for MPICH2 (win64) tarball")
set(MPICH2_WIN32_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win32-devel.tar.gz" CACHE STRING "URL for MPICH2 (win32) tarball")
set(MPICH2_WIN64_DEVEL_MD5 "4939fdb59d13182fd5dd65211e469f14" CACHE STRING "MD5 checksum of MPICH2 (win64) tarball")
set(MPICH2_WIN32_DEVEL_MD5 "a61d153500dce44e21b755ee7257e031" CACHE STRING "MD5 checksum of MPICH2 (win32) tarball")
mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
mark_as_advanced(MPICH2_WIN32_DEVEL_URL)
mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
mark_as_advanced(MPICH2_WIN32_DEVEL_MD5)
include(ExternalProject)
if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
ExternalProject_Add(mpi4win_build
URL ${MPICH2_WIN64_DEVEL_URL}
URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
else()
ExternalProject_Add(mpi4win_build
URL ${MPICH2_WIN32_DEVEL_URL}
URL_MD5 ${MPICH2_WIN32_DEVEL_MD5}
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
endif()
ExternalProject_get_property(mpi4win_build SOURCE_DIR)
file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
set_target_properties(MPI::MPI_CXX PROPERTIES
IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmpi.a"
INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
add_dependencies(MPI::MPI_CXX mpi4win_build)
# set variables for status reporting at the end of CMake run
set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmpi.a")
message(FATAL_ERROR "Only x86 64-bit builds are supported with MS-MPI")
endif()
ExternalProject_get_property(mpi4win_build SOURCE_DIR)
file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
set_target_properties(MPI::MPI_CXX PROPERTIES
IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmsmpi.a"
INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX=1")
add_dependencies(MPI::MPI_CXX mpi4win_build)
# set variables for status reporting at the end of CMake run
set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX=1")
set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmsmpi.a")

8
cmake/Modules/Packages/COLVARS.cmake
View File

@ -14,10 +14,6 @@ endif()
add_library(colvars STATIC ${COLVARS_SOURCES})
target_compile_definitions(colvars PRIVATE -DCOLVARS_LAMMPS)
separate_arguments(CMAKE_TUNE_FLAGS)
foreach(_FLAG ${CMAKE_TUNE_FLAGS})
target_compile_options(colvars PRIVATE ${_FLAG})
endforeach()
set_target_properties(colvars PROPERTIES OUTPUT_NAME lammps_colvars${LAMMPS_MACHINE})
target_include_directories(colvars PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/colvars)
# The line below is needed to locate math_eigen_impl.h
@ -30,6 +26,10 @@ if(BUILD_OMP)
target_link_libraries(colvars PRIVATE OpenMP::OpenMP_CXX)
endif()
if(BUILD_MPI)
target_link_libraries(colvars PUBLIC MPI::MPI_CXX)
endif()
if(COLVARS_DEBUG)
# Need to export the define publicly to be valid in interface code
target_compile_definitions(colvars PUBLIC -DCOLVARS_DEBUG)

14
cmake/Modules/Packages/EXTRA-COMMAND.cmake
View File

@ -1,10 +1,18 @@
# the geturl command needs libcurl
find_package(CURL QUIET COMPONENTS HTTP HTTPS)
find_package(CURL QUIET)
option(WITH_CURL "Enable libcurl support" ${CURL_FOUND})
if(WITH_CURL)
find_package(CURL REQUIRED COMPONENTS HTTP HTTPS)
target_compile_definitions(lammps PRIVATE -DLAMMPS_CURL)
target_link_libraries(lammps PRIVATE CURL::libcurl)
# need to use pkgconfig for fully static bins to find custom static libs
if (CMAKE_SYSTEM_NAME STREQUAL "LinuxMUSL")
include(FindPkgConfig)
pkg_check_modules(CURL IMPORTED_TARGET libcurl libssl libcrypto)
target_link_libraries(lammps PUBLIC PkgConfig::CURL)
else()
find_package(CURL REQUIRED)
target_link_libraries(lammps PRIVATE CURL::libcurl)
endif()
endif()

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

@ -189,7 +189,7 @@ if(GPU_API STREQUAL "CUDA")
endif()
add_executable(nvc_get_devices ${LAMMPS_LIB_SOURCE_DIR}/gpu/geryon/ucl_get_devices.cpp)
target_compile_definitions(nvc_get_devices PRIVATE -DUCL_CUDADR)
target_compile_definitions(nvc_get_devices PRIVATE -DUCL_CUDADR -DLAMMPS_${LAMMPS_SIZES})
target_link_libraries(nvc_get_devices PRIVATE ${CUDA_LIBRARIES} ${CUDA_CUDA_LIBRARY})
target_include_directories(nvc_get_devices PRIVATE ${CUDA_INCLUDE_DIRS})
@ -489,7 +489,7 @@ 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_compile_definitions(gpu PRIVATE -DLAMMPS_${LAMMPS_SIZES})
target_sources(lammps PRIVATE ${GPU_SOURCES})
target_include_directories(lammps PRIVATE ${GPU_SOURCES_DIR})

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

@ -3,7 +3,7 @@ enable_language(C)
# we don't use the parallel i/o interface.
set(HDF5_PREFER_PARALLEL FALSE)
find_package(HDF5 REQUIRED)
find_package(HDF5 COMPONENTS C REQUIRED)
# parallel HDF5 will import incompatible MPI headers with a serial build
if((NOT BUILD_MPI) AND HDF5_IS_PARALLEL)

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

@ -72,6 +72,10 @@ if(INTEL_ARCH STREQUAL "KNL")
if(NOT CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
message(FATAL_ERROR "Must use Intel compiler with INTEL for KNL architecture")
endif()
message(WARNING, "Support for Intel Xeon Phi accelerators and Knight's Landing CPUs "
"will be removed from LAMMPS in Summer 2025 due to lack of available machines "
"in labs and HPC centers and removed support in recent compilers "
"Please contact developers@lammps.org if you have any concerns about this step.")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -xHost -qopenmp -qoffload")
set(MIC_OPTIONS "-qoffload-option,mic,compiler,\"-fp-model fast=2 -mGLOB_default_function_attrs=\\\"gather_scatter_loop_unroll=4\\\"\"")
target_compile_options(lammps PRIVATE -xMIC-AVX512 -qoffload -fno-alias -ansi-alias -restrict -qoverride-limits ${MIC_OPTIONS})

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

@ -7,26 +7,13 @@ endif()
########################################################################
# consistency checks and Kokkos options/settings required by LAMMPS
if(Kokkos_ENABLE_CUDA)
option(Kokkos_ENABLE_IMPL_CUDA_MALLOC_ASYNC "CUDA asynchronous malloc support" OFF)
mark_as_advanced(Kokkos_ENABLE_IMPL_CUDA_MALLOC_ASYNC)
if(Kokkos_ENABLE_IMPL_CUDA_MALLOC_ASYNC)
message(STATUS "KOKKOS: CUDA malloc async support enabled")
else()
message(STATUS "KOKKOS: CUDA malloc async support disabled")
endif()
endif()
if(Kokkos_ENABLE_HIP)
option(Kokkos_ENABLE_HIP_MULTIPLE_KERNEL_INSTANTIATIONS "Enable multiple kernel instantiations with HIP" ON)
mark_as_advanced(Kokkos_ENABLE_HIP_MULTIPLE_KERNEL_INSTANTIATIONS)
option(Kokkos_ENABLE_ROCTHRUST "Use RoCThrust library" ON)
mark_as_advanced(Kokkos_ENABLE_ROCTHRUST)
if(Kokkos_ARCH_AMD_GFX942 OR Kokkos_ARCH_AMD_GFX940)
option(Kokkos_ENABLE_IMPL_HIP_UNIFIED_MEMORY "Enable unified memory with HIP" ON)
mark_as_advanced(Kokkos_ENABLE_IMPL_HIP_UNIFIED_MEMORY)
endif()
endif()
# Adding OpenMP compiler flags without the checks done for
# BUILD_OMP can result in compile failures. Enforce consistency.
if(Kokkos_ENABLE_OPENMP)
@ -70,8 +57,8 @@ if(DOWNLOAD_KOKKOS)
list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
include(ExternalProject)
set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.4.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
set(KOKKOS_MD5 "de6ee80d00b6212b02bfb7f1e71a8392" CACHE STRING "MD5 checksum of KOKKOS tarball")
set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.6.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
set(KOKKOS_MD5 "61b2b69ae50d83eedcc7d47a3fa3d6cb" CACHE STRING "MD5 checksum of KOKKOS tarball")
mark_as_advanced(KOKKOS_URL)
mark_as_advanced(KOKKOS_MD5)
GetFallbackURL(KOKKOS_URL KOKKOS_FALLBACK)
@ -96,7 +83,7 @@ if(DOWNLOAD_KOKKOS)
add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
elseif(EXTERNAL_KOKKOS)
find_package(Kokkos 4.4.01 REQUIRED CONFIG)
find_package(Kokkos 4.6.00 REQUIRED CONFIG)
target_link_libraries(lammps PRIVATE Kokkos::kokkos)
else()
set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)

10
cmake/Modules/Packages/MC.cmake
View File

@ -7,3 +7,13 @@ if(NOT PKG_MANYBODY)
list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/MC/fix_sgcmc.cpp)
set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
endif()
# fix neighbor/swap may only be installed if also the VORONOI package is installed
if(NOT PKG_VORONOI)
get_property(LAMMPS_FIX_HEADERS GLOBAL PROPERTY FIX)
list(REMOVE_ITEM LAMMPS_FIX_HEADERS ${LAMMPS_SOURCE_DIR}/MC/fix_neighbor_swap.h)
set_property(GLOBAL PROPERTY FIX "${LAMMPS_FIX_HEADERS}")
get_target_property(LAMMPS_SOURCES lammps SOURCES)
list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/MC/fix_neighbor_swap.cpp)
set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
endif()

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

@ -24,9 +24,7 @@ if(MLIAP_ENABLE_PYTHON)
if(NOT PKG_PYTHON)
message(FATAL_ERROR "Must enable PYTHON package for including Python support in ML-IAP")
endif()
if(Python_VERSION VERSION_LESS 3.6)
message(FATAL_ERROR "Python support in ML-IAP requires Python 3.6 or later")
endif()
# Python version check is in main CMakeLists.txt file
set(MLIAP_BINARY_DIR ${CMAKE_BINARY_DIR}/cython)
file(GLOB MLIAP_CYTHON_SRC CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/ML-IAP/*.pyx)

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

@ -1,50 +1,62 @@
# PACE library support for ML-PACE package
find_package(pace QUIET)
# set policy to silence warnings about timestamps of downloaded files. review occasionally if it may be set to NEW
if(POLICY CMP0135)
cmake_policy(SET CMP0135 OLD)
endif()
set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.11.25.fix.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
set(PACELIB_MD5 "b45de9a633f42ed65422567e3ce56f9f" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
mark_as_advanced(PACELIB_URL)
mark_as_advanced(PACELIB_MD5)
GetFallbackURL(PACELIB_URL PACELIB_FALLBACK)
# LOCAL_ML-PACE points to top-level dir with local lammps-user-pace repo,
# to make it easier to check local build without going through the public github releases
if(LOCAL_ML-PACE)
set(lib-pace "${LOCAL_ML-PACE}")
if(pace_FOUND)
find_package(pace)
target_link_libraries(lammps PRIVATE pace::pace)
else()
# download library sources to build folder
if(EXISTS ${CMAKE_BINARY_DIR}/libpace.tar.gz)
file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
endif()
if(NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}")
message(STATUS "Downloading ${PACELIB_URL}")
file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz STATUS DL_STATUS SHOW_PROGRESS)
file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
if((NOT DL_STATUS EQUAL 0) OR (NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}"))
message(WARNING "Download from primary URL ${PACELIB_URL} failed\nTrying fallback URL ${PACELIB_FALLBACK}")
file(DOWNLOAD ${PACELIB_FALLBACK} ${CMAKE_BINARY_DIR}/libpace.tar.gz EXPECTED_HASH MD5=${PACELIB_MD5} SHOW_PROGRESS)
# set policy to silence warnings about timestamps of downloaded files. review occasionally if it may be set to NEW
if(POLICY CMP0135)
cmake_policy(SET CMP0135 OLD)
endif()
else()
message(STATUS "Using already downloaded archive ${CMAKE_BINARY_DIR}/libpace.tar.gz")
endif()
set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.11.25.fix2.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
set(PACELIB_MD5 "a53bd87cfee8b07d9f44bc17aad69c3f" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
mark_as_advanced(PACELIB_URL)
mark_as_advanced(PACELIB_MD5)
GetFallbackURL(PACELIB_URL PACELIB_FALLBACK)
# LOCAL_ML-PACE points to top-level dir with local lammps-user-pace repo,
# to make it easier to check local build without going through the public github releases
if(LOCAL_ML-PACE)
set(lib-pace "${LOCAL_ML-PACE}")
else()
# download library sources to build folder
if(EXISTS ${CMAKE_BINARY_DIR}/libpace.tar.gz)
file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
endif()
if(NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}")
message(STATUS "Downloading ${PACELIB_URL}")
file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz STATUS DL_STATUS SHOW_PROGRESS)
file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
if((NOT DL_STATUS EQUAL 0) OR (NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}"))
message(WARNING "Download from primary URL ${PACELIB_URL} failed\nTrying fallback URL ${PACELIB_FALLBACK}")
file(DOWNLOAD ${PACELIB_FALLBACK} ${CMAKE_BINARY_DIR}/libpace.tar.gz EXPECTED_HASH MD5=${PACELIB_MD5} SHOW_PROGRESS)
endif()
else()
message(STATUS "Using already downloaded archive ${CMAKE_BINARY_DIR}/libpace.tar.gz")
endif()
# uncompress downloaded sources
execute_process(
COMMAND ${CMAKE_COMMAND} -E remove_directory lammps-user-pace*
COMMAND ${CMAKE_COMMAND} -E tar xzf libpace.tar.gz
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
)
get_newest_file(${CMAKE_BINARY_DIR}/lammps-user-pace-* lib-pace)
endif()
add_subdirectory(${lib-pace} build-pace)
set_target_properties(pace PROPERTIES CXX_EXTENSIONS ON OUTPUT_NAME lammps_pace${LAMMPS_MACHINE})
if(CMAKE_PROJECT_NAME STREQUAL "lammps")
target_link_libraries(lammps PRIVATE pace)
# uncompress downloaded sources
execute_process(
COMMAND ${CMAKE_COMMAND} -E remove_directory lammps-user-pace*
COMMAND ${CMAKE_COMMAND} -E tar xzf libpace.tar.gz
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
)
get_newest_file(${CMAKE_BINARY_DIR}/lammps-user-pace-* lib-pace)
endif()
# some preinstalled yaml-cpp versions don't provide a namespaced target
find_package(yaml-cpp QUIET)
if(TARGET yaml-cpp AND NOT TARGET yaml-cpp::yaml-cpp)
add_library(yaml-cpp::yaml-cpp ALIAS yaml-cpp)
endif()
add_subdirectory(${lib-pace} build-pace)
set_target_properties(pace PROPERTIES CXX_EXTENSIONS ON OUTPUT_NAME lammps_pace${LAMMPS_MACHINE})
if(CMAKE_PROJECT_NAME STREQUAL "lammps")
target_link_libraries(lammps PRIVATE pace)
endif()
endif()

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

@ -37,7 +37,7 @@ if(DOWNLOAD_QUIP)
endforeach()
# 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}PYTHON=${Python_EXECUTABLE}\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")
set(temp "${temp}HAVE_TURBOGAP=0\nHAVE_QR=1\nHAVE_THIRDPARTY=0\nHAVE_FX=0\nHAVE_SCME=0\nHAVE_MTP=0\n")

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

@ -32,14 +32,21 @@ endif()
# Note: must also adjust check for supported API versions in
# fix_plumed.cpp when version changes from v2.n.x to v2.n+1.y
set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.9.2/plumed-src-2.9.2.tgz"
set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.9.3/plumed-src-2.9.3.tgz"
CACHE STRING "URL for PLUMED tarball")
set(PLUMED_MD5 "04862602a372c1013bdfee2d6d03bace" CACHE STRING "MD5 checksum of PLUMED tarball")
set(PLUMED_MD5 "ee1249805fe94bccee17d10610d3f6f1" CACHE STRING "MD5 checksum of PLUMED tarball")
mark_as_advanced(PLUMED_URL)
mark_as_advanced(PLUMED_MD5)
GetFallbackURL(PLUMED_URL PLUMED_FALLBACK)
# adjust C++ standard support for self-compiled Plumed2
if(CMAKE_CXX_STANDARD GREATER 11)
set(PLUMED_CXX_STANDARD 14)
else()
set(PLUMED_CXX_STANDARD 11)
endif()
if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND (CMAKE_CROSSCOMPILING))
if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
set(CROSS_CONFIGURE mingw64-configure)
@ -55,7 +62,7 @@ if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND (CMAKE_CROSSCOMPILING))
URL_MD5 ${PLUMED_MD5}
BUILD_IN_SOURCE 1
CONFIGURE_COMMAND ${CROSS_CONFIGURE} --disable-shared --disable-bsymbolic
--disable-python --enable-cxx=11
--disable-python --enable-cxx=${PLUMED_CXX_STANDARD}
--enable-modules=-adjmat:+crystallization:-dimred:+drr:+eds:-fisst:+funnel:+logmfd:+manyrestraints:+maze:+opes:+multicolvar:-pamm:-piv:+s2cm:-sasa:-ves
${PLUMED_CONFIG_OMP}
${PLUMED_CONFIG_MPI}
@ -142,7 +149,7 @@ else()
CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR>
${CONFIGURE_REQUEST_PIC}
--enable-modules=all
--enable-cxx=11
--enable-cxx=${PLUMED_CXX_STANDARD}
--disable-python
${PLUMED_CONFIG_MPI}
${PLUMED_CONFIG_OMP}

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

@ -1,6 +1,6 @@
if(NOT Python_INTERPRETER)
# backward compatibility with CMake before 3.12 and older LAMMPS documentation
# backward compatibility with older LAMMPS documentation
if(PYTHON_EXECUTABLE)
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
endif()

15
cmake/Modules/Packages/SCAFACOS.cmake
View File

@ -14,27 +14,16 @@ endif()
option(DOWNLOAD_SCAFACOS "Download ScaFaCoS library instead of using an already installed one" ${DOWNLOAD_SCAFACOS_DEFAULT})
if(DOWNLOAD_SCAFACOS)
message(STATUS "ScaFaCoS download requested - we will build our own")
set(SCAFACOS_URL "https://github.com/scafacos/scafacos/releases/download/v1.0.1/scafacos-1.0.1.tar.gz" CACHE STRING "URL for SCAFACOS tarball")
set(SCAFACOS_MD5 "bd46d74e3296bd8a444d731bb10c1738" CACHE STRING "MD5 checksum of SCAFACOS tarball")
set(SCAFACOS_URL "https://github.com/scafacos/scafacos/releases/download/v1.0.4/scafacos-1.0.4.tar.gz" CACHE STRING "URL for SCAFACOS tarball")
set(SCAFACOS_MD5 "23867540ec32e63ce71d6ecc105278d2" CACHE STRING "MD5 checksum of SCAFACOS tarball")
mark_as_advanced(SCAFACOS_URL)
mark_as_advanced(SCAFACOS_MD5)
GetFallbackURL(SCAFACOS_URL SCAFACOS_FALLBACK)
# version 1.0.1 needs a patch to compile and linke cleanly with GCC 10 and later.
file(DOWNLOAD ${LAMMPS_THIRDPARTY_URL}/scafacos-1.0.1-fix.diff ${CMAKE_CURRENT_BINARY_DIR}/scafacos-1.0.1.fix.diff
EXPECTED_HASH MD5=4baa1333bb28fcce102d505e1992d032)
find_program(HAVE_PATCH patch)
if(NOT HAVE_PATCH)
message(FATAL_ERROR "The 'patch' program is required to build the ScaFaCoS library")
endif()
include(ExternalProject)
ExternalProject_Add(scafacos_build
URL ${SCAFACOS_URL} ${SCAFACOS_FALLBACK}
URL_MD5 ${SCAFACOS_MD5}
PATCH_COMMAND patch -p1 < ${CMAKE_CURRENT_BINARY_DIR}/scafacos-1.0.1.fix.diff
CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR> --disable-doc
--enable-fcs-solvers=fmm,p2nfft,direct,ewald,p3m
--with-internal-fftw --with-internal-pfft

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

@ -54,5 +54,5 @@ else()
if(NOT VORO_FOUND)
message(FATAL_ERROR "Voro++ library not found. Help CMake to find it by setting VORO_LIBRARY and VORO_INCLUDE_DIR, or set DOWNLOAD_VORO=ON to download it")
endif()
target_link_libraries(lammps PRIVATE VORO::VORO)
target_link_libraries(lammps PRIVATE VORO::voro++)
endif()

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

@ -1,3 +1,5 @@
# FindVTK requires that C support is enabled when looking for MPI support
enable_language(C)
find_package(VTK REQUIRED NO_MODULE)
target_compile_definitions(lammps PRIVATE -DLAMMPS_VTK)
if (VTK_MAJOR_VERSION VERSION_LESS 9.0)

15
cmake/Modules/Testing.cmake
View File

@ -21,11 +21,11 @@ if(ENABLE_TESTING)
# also only verified with Fedora Linux > 30 and Ubuntu 18.04 or 22.04+(Ubuntu 20.04 fails)
if((CMAKE_SYSTEM_NAME STREQUAL "Linux")
AND ((CMAKE_CXX_COMPILER_ID STREQUAL "GNU") OR (CMAKE_CXX_COMPILER_ID STREQUAL "Clang")))
if(((CMAKE_LINUX_DISTRO STREQUAL "Ubuntu") AND
((CMAKE_DISTRO_VERSION VERSION_LESS_EQUAL 18.04) OR (CMAKE_DISTRO_VERSION VERSION_GREATER_EQUAL 22.04)))
if(((CMAKE_LINUX_DISTRO STREQUAL "Ubuntu") AND (CMAKE_DISTRO_VERSION VERSION_GREATER_EQUAL 22.04))
OR ((CMAKE_LINUX_DISTRO STREQUAL "Fedora") AND (CMAKE_DISTRO_VERSION VERSION_GREATER 30)))
include(CheckCXXCompilerFlag)
set(CMAKE_CUSTOM_LINKER_DEFAULT default)
check_cxx_compiler_flag(--ld-path=${CMAKE_LINKER} HAVE_LD_PATH_FLAG)
check_cxx_compiler_flag(-fuse-ld=mold HAVE_MOLD_LINKER_FLAG)
check_cxx_compiler_flag(-fuse-ld=lld HAVE_LLD_LINKER_FLAG)
check_cxx_compiler_flag(-fuse-ld=gold HAVE_GOLD_LINKER_FLAG)
@ -50,6 +50,17 @@ if(ENABLE_TESTING)
if(NOT "${CMAKE_CUSTOM_LINKER}" STREQUAL "default")
target_link_options(lammps PUBLIC -fuse-ld=${CMAKE_CUSTOM_LINKER})
endif()
if(HAVE_LD_PATH_FLAG)
if("${CMAKE_CUSTOM_LINKER}" STREQUAL "mold")
target_link_options(lammps PUBLIC --ld-path=${HAVE_MOLD_LINKER_BIN})
elseif("${CMAKE_CUSTOM_LINKER}" STREQUAL "lld")
target_link_options(lammps PUBLIC --ld-path=${HAVE_LLD_LINKER_BIN})
elseif("${CMAKE_CUSTOM_LINKER}" STREQUAL "gold")
target_link_options(lammps PUBLIC --ld-path=${HAVE_GOLD_LINKER_BIN})
elseif("${CMAKE_CUSTOM_LINKER}" STREQUAL "bfd")
target_link_options(lammps PUBLIC --ld-path=${HAVE_BFD_LINKER_BIN})
endif()
endif()
endif()
endif()

4
cmake/Modules/Tools.cmake
View File

@ -6,6 +6,10 @@ if(BUILD_TOOLS)
add_executable(stl_bin2txt ${LAMMPS_TOOLS_DIR}/stl_bin2txt.cpp)
install(TARGETS stl_bin2txt DESTINATION ${CMAKE_INSTALL_BINDIR})
add_executable(reformat-json ${LAMMPS_TOOLS_DIR}/json/reformat-json.cpp)
target_include_directories(reformat-json PRIVATE ${LAMMPS_SOURCE_DIR})
install(TARGETS reformat-json DESTINATION ${CMAKE_INSTALL_BINDIR})
include(CheckGeneratorSupport)
if(CMAKE_GENERATOR_SUPPORT_FORTRAN)
include(CheckLanguage)

11
cmake/presets/hip_amd.cmake
View File

@ -19,12 +19,19 @@ set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
set(MPI_CXX "hipcc" CACHE STRING "" FORCE)
set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
set(MPI_C "hipcc" CACHE STRING "" FORCE)
set(MPI_C_COMPILER "mpicc" CACHE STRING "" FORCE)
# change as needed. This is for Fedora Linux 41 and 42
set(_libomp_root "/usr/lib/clang/18")
# we need to explicitly specify the include dir, since hipcc will
# compile each file twice and doesn't find omp.h the second time
unset(HAVE_OMP_H_INCLUDE CACHE)
set(OpenMP_C "hipcc" CACHE STRING "" FORCE)
set(OpenMP_C_FLAGS "-fopenmp" CACHE STRING "" FORCE)
set(OpenMP_C_FLAGS "-fopenmp=libomp -I${_libomp_root}/include" CACHE STRING "" FORCE)
set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
set(OpenMP_CXX "hipcc" CACHE STRING "" FORCE)
set(OpenMP_CXX_FLAGS "-fopenmp" CACHE STRING "" FORCE)
set(OpenMP_CXX_FLAGS "-fopenmp=libomp -I${_libomp_root}/include" CACHE STRING "" FORCE)
set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
set(OpenMP_omp_LIBRARY "libomp.so" CACHE PATH "" FORCE)

4
cmake/presets/kokkos-cuda.cmake
View File

@ -1,10 +1,8 @@
# preset that enables KOKKOS and selects CUDA compilation with OpenMP
# enabled as well. This preselects CC 5.0 as default GPU arch, since
# that is compatible with all higher CC, but not the default CC 3.5
# enabled as well. The GPU architecture *must* match your hardware (If not manually set, Kokkos will try to autodetect it).
set(PKG_KOKKOS ON CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_SERIAL ON CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_CUDA ON CACHE BOOL "" FORCE)
set(Kokkos_ARCH_PASCAL60 ON CACHE BOOL "" FORCE)
set(BUILD_OMP ON CACHE BOOL "" FORCE)
get_filename_component(NVCC_WRAPPER_CMD ${CMAKE_CURRENT_SOURCE_DIR}/../lib/kokkos/bin/nvcc_wrapper ABSOLUTE)
set(CMAKE_CXX_COMPILER ${NVCC_WRAPPER_CMD} CACHE FILEPATH "" FORCE)

13
cmake/presets/kokkos-hip.cmake
View File

@ -1,22 +1,21 @@
# preset that enables KOKKOS and selects HIP compilation with OpenMP
# enabled as well. Also sets some performance related compiler flags.
# preset that enables KOKKOS and selects HIP compilation withOUT OpenMP.
# Kokkos OpenMP is not compatible with the second pass of hipcc.
set(PKG_KOKKOS ON CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_SERIAL ON CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_OPENMP ON CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_OPENMP OFF CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_CUDA OFF CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_HIP ON CACHE BOOL "" FORCE)
set(Kokkos_ARCH_VEGA90A on CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_HIP_MULTIPLE_KERNEL_INSTANTIATIONS ON CACHE BOOL "" FORCE)
set(BUILD_OMP ON CACHE BOOL "" FORCE)
set(CMAKE_CXX_COMPILER hipcc CACHE STRING "" FORCE)
set(CMAKE_TUNE_FLAGS "-munsafe-fp-atomics" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -munsafe-fp-atomics" CACHE STRING "" FORCE)
# If KSPACE is also enabled, use CUFFT for FFTs
# If KSPACE is also enabled, use HIPFFT for FFTs
set(FFT_KOKKOS "HIPFFT" CACHE STRING "" FORCE)
# hide deprecation warnings temporarily for stable release
set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
#set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
# these flags are needed to build with Cray MPICH on OLCF Crusher
#-D CMAKE_CXX_FLAGS="-I/${MPICH_DIR}/include"

20
cmake/presets/kokkos-sycl-intel.cmake
View File

@ -6,13 +6,25 @@ set(Kokkos_ENABLE_OPENMP ON CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_CUDA OFF CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_SYCL ON CACHE BOOL "" FORCE)
set(FFT "MKL" CACHE STRING "" FORCE)
set(FFT_KOKKOS "MKL_GPU" CACHE STRING "" FORCE)
unset(USE_INTERNAL_LINALG)
unset(USE_INTERNAL_LINALG CACHE)
set(BLAS_VENDOR "Intel10_64_dyn")
# hide deprecation warnings temporarily for stable release
set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
set(CMAKE_CXX_COMPILER icpx CACHE STRING "" FORCE)
set(CMAKE_C_COMPILER icx CACHE STRING "" FORCE)
set(CMAKE_Fortran_COMPILER "" CACHE STRING "" FORCE)
set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
set(CMAKE_CXX_STANDARD 17 CACHE STRING "" FORCE)
# Silence everything
set(CMAKE_CXX_FLAGS "-w" CACHE STRING "" FORCE)
set(CMAKE_EXE_LINKER_FLAGS "-fsycl -flink-huge-device-code -fsycl-max-parallel-link-jobs=32 -fsycl-targets=spir64_gen -Xsycl-target-backend \"-device 12.60.7\" " CACHE STRING "" FORCE)
set(CMAKE_TUNE_FLAGS "-O3 -fsycl -fsycl-device-code-split=per_kernel -fsycl-targets=spir64_gen" CACHE STRING "" FORCE)
# set(_intel_sycl_flags " -w -fsycl -flink-huge-device-code -fsycl-targets=spir64_gen "
set(_intel_sycl_flags " -w -fsycl -fsycl-device-code-split=per_kernel -fsycl-targets=spir64_gen ")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${_intel_sycl_flags}" CACHE STRING "" FORCE)
#set(CMAKE_EXE_LINKER_FLAGS "-fsycl -flink-huge-device-code -fsycl-targets=spir64_gen " CACHE STRING "" FORCE)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsycl -flink-huge-device-code " CACHE STRING "" FORCE)

6
cmake/presets/kokkos-sycl-nvidia.cmake
View File

@ -14,5 +14,7 @@ set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
set(CMAKE_CXX_COMPILER clang++ CACHE STRING "" FORCE)
set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
set(CMAKE_CXX_STANDARD 17 CACHE STRING "" FORCE)
set(CMAKE_SHARED_LINKER_FLAGS "-Xsycl-target-frontend -O3" CACHE STRING "" FORCE)
set(CMAKE_TUNE_FLAGS "-fgpu-inline-threshold=100000 -Xsycl-target-frontend -O3 -Xsycl-target-frontend -ffp-contract=on -Wno-unknown-cuda-version" CACHE STRING "" FORCE)
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Xsycl-target-frontend -O3 " CACHE STRING "" FORCE)
set(_intel_sycl_flags "-fgpu-inline-threshold=100000 -Xsycl-target-frontend -O3 -Xsycl-target-frontend -ffp-contract=on -Wno-unknown-cuda-version")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${_intel_sycl_flags}" CACHE STRING "" FORCE)

2
cmake/presets/mingw-cross.cmake
View File

@ -91,7 +91,7 @@ endif()
set(DOWNLOAD_VORO ON CACHE BOOL "" FORCE)
set(DOWNLOAD_EIGEN3 ON CACHE BOOL "" FORCE)
set(LAMMPS_MEMALIGN "0" CACHE STRING "" FORCE)
set(CMAKE_TUNE_FLAGS "-Wno-missing-include-dirs" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-missing-include-dirs" CACHE STRING "" FORCE)
set(CMAKE_EXE_LINKER_FLAGS "-Wl,--enable-stdcall-fixup,--as-needed,-lssp" CACHE STRING "" FORCE)
set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--enable-stdcall-fixup,--as-needed,-lssp" CACHE STRING "" FORCE)
set(BUILD_TOOLS ON CACHE BOOL "" FORCE)

21
cmake/presets/oneapi.cmake
View File

@ -3,26 +3,9 @@
set(CMAKE_CXX_COMPILER "icpx" CACHE STRING "" FORCE)
set(CMAKE_C_COMPILER "icx" CACHE STRING "" FORCE)
set(CMAKE_Fortran_COMPILER "ifx" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
set(MPI_CXX "icpx" CACHE STRING "" FORCE)
set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
unset(HAVE_OMP_H_INCLUDE CACHE)
set(OpenMP_C "icx" CACHE STRING "" FORCE)
set(OpenMP_C_FLAGS "-qopenmp;-qopenmp-simd" CACHE STRING "" FORCE)
set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
set(OpenMP_CXX "icpx" CACHE STRING "" FORCE)
set(OpenMP_CXX_FLAGS "-qopenmp;-qopenmp-simd" CACHE STRING "" FORCE)
set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
set(OpenMP_Fortran_FLAGS "-qopenmp;-qopenmp-simd" CACHE STRING "" FORCE)
set(OpenMP_omp_LIBRARY "libiomp5.so" CACHE PATH "" FORCE)
# force using internal BLAS/LAPCK since external ones may not be ABI compatible
set(USE_INTERNAL_LINALG ON CACHE BOOL "" FORCE)

2
cmake/presets/windows-intel-llvm.cmake
View File

@ -5,4 +5,4 @@ set(CMAKE_C_COMPILER "icx" CACHE STRING "" FORCE)
set(CMAKE_Fortran_COMPILER "ifx" CACHE STRING "" FORCE)
set(INTEL_LRT_MODE "C++11" CACHE STRING "" FORCE)
unset(HAVE_OMP_H_INCLUDE CACHE)
set(CMAKE_TUNE_FLAGS -Wno-unused-command-line-argument)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-unused-command-line-argument" CACHE STRING "" FORCE)

7
doc/.gitignore vendored
View File

@ -17,3 +17,10 @@
*.el
/utils/sphinx-config/_static/mathjax
/utils/sphinx-config/_static/polyfill.js
/src/pairs.rst
/src/bonds.rst
/src/angles.rst
/src/dihedrals.rst
/src/impropers.rst
/src/computes.rst
/src/fixes.rst

60
doc/Makefile
View File

@ -17,9 +17,11 @@ MATHJAXTAG = 3.2.2
PYTHON = $(word 3,$(shell type python3))
DOXYGEN = $(word 3,$(shell type doxygen))
PANDOC = $(word 3,$(shell type pandoc))
HAS_PYTHON3 = NO
HAS_DOXYGEN = NO
HAS_PDFLATEX = NO
HAS_PANDOC = NO
ifeq ($(shell type python3 >/dev/null 2>&1; echo $$?), 0)
HAS_PYTHON3 = YES
@ -31,10 +33,14 @@ endif
ifeq ($(shell type pdflatex >/dev/null 2>&1; echo $$?), 0)
ifeq ($(shell type latexmk >/dev/null 2>&1; echo $$?), 0)
HAS_PDFLATEX = YES
HAS_PDFLATEX = YES
endif
endif
ifeq ($(shell type pandoc >/dev/null 2>&1; echo $$?), 0)
HAS_PANDOC = YES
endif
# override settings for PIP commands
# PIP_OPTIONS = --cert /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt --proxy http://proxy.mydomain.org
@ -45,8 +51,9 @@ SPHINXEXTRA = -j $(shell $(PYTHON) -c 'import multiprocessing;print(multiprocess
# we only want to use explicitly listed files.
DOXYFILES = $(shell sed -n -e 's/\#.*$$//' -e '/^ *INPUT \+=/,/^[A-Z_]\+ \+=/p' doxygen/Doxyfile.in | sed -e 's/@LAMMPS_SOURCE_DIR@/..\/src/g' -e 's/\\//g' -e 's/ \+/ /' -e 's/[A-Z_]\+ \+= *\(YES\|NO\|\)//')
.PHONY: help clean-all clean clean-spelling epub mobi html pdf spelling anchor_check style_check char_check role_check xmlgen fasthtml
.PHONY: help clean-all clean clean-spelling epub mobi html pdf spelling anchor_check style_check char_check role_check xmlgen fasthtml fasthtml-init
FASTHTMLFILES = $(patsubst $(RSTDIR)/%.rst,fasthtml/%.html,$(wildcard $(RSTDIR)/*rst))
# ------------------------------------------
help:
@ -83,7 +90,10 @@ $(SPHINXCONFIG)/conf.py: $(SPHINXCONFIG)/conf.py.in
-e 's,@LAMMPS_PYTHON_DIR@,$(BUILDDIR)/../python,g' \
-e 's,@LAMMPS_DOC_DIR@,$(BUILDDIR),g' $< > $@
html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
globbed-tocs:
$(PYTHON) $(BUILDDIR)/utils/make-globbed-tocs.py -d $(RSTDIR)
html: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
@$(MAKE) $(MFLAGS) -C graphviz all
@(\
@ -102,6 +112,8 @@ html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst ;\
env LC_ALL=C grep -n '\(ref\|doc\)`[^`]' $(RSTDIR)/*.rst ;\
$(PYTHON) $(BUILDDIR)/utils/check-styles.py -s ../src -d src ;\
env LC_ALL=C grep -n -E '^ *\.\. [a-z0-9]+:(\s+.*|)$$' \
$(RSTDIR)/*.rst ../src/*.{cpp,h} ../src/*/*.{cpp,h} ;\
echo "############################################" ;\
deactivate ;\
)
@ -113,26 +125,24 @@ html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
@rm -rf html/PDF/.[sg]*
@echo "Build finished. The HTML pages are in doc/html."
fasthtml: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
@$(MAKE) $(MFLAGS) -C graphviz all
@mkdir -p fasthtml
@(\
. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/fasthtml/doctrees $(RSTDIR) fasthtml ;\
touch $(RSTDIR)/Fortran.rst ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/fasthtml/doctrees $(RSTDIR) fasthtml ;\
deactivate ;\
)
@rm -rf fasthtml/_sources
@rm -rf fasthtml/PDF
@rm -rf fasthtml/USER
@rm -rf fasthtml/JPG
@cp -r src/PDF fasthtml/PDF
@rm -rf fasthtml/PDF/.[sg]*
fasthtml: fasthtml-init $(FASTHTMLFILES)
@echo "Fast HTML build finished. The HTML pages are in doc/fasthtml."
spelling: xmlgen $(SPHINXCONFIG)/conf.py $(VENV) $(SPHINXCONFIG)/false_positives.txt
fasthtml-init:
@mkdir -p fasthtml/JPG
@cp src/JPG/*.* fasthtml/JPG
@cp $(RSTDIR)/accel_styles.rst $(RSTDIR)/lepton_expression.rst fasthtml/
@cp $(BUILDDIR)/utils/pandoc.css fasthtml/
fasthtml/%.html: $(RSTDIR)/%.rst
@if [ "$(HAS_PANDOC)" == "NO" ] ; then echo "Make 'fasthtml' requires the 'pandoc' software" 1>&2; exit 1; fi
@mkdir -p fasthtml
@echo converting $< to $@
@sed -e 's/\\AA/\\mathring{\\mathrm{A}}/g' $< > fasthtml/$*.temp.rst
@pandoc -s --mathml --css="pandoc.css" --template=$(BUILDDIR)/utils/pandoc.html --metadata title="$@" -o $@ fasthtml/$*.temp.rst
@rm -f fasthtml/$*.temp.rst
spelling: xmlgen globbed-tocs $(SPHINXCONFIG)/conf.py $(VENV) $(SPHINXCONFIG)/false_positives.txt
@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
@(\
. $(VENV)/bin/activate ; \
@ -143,7 +153,7 @@ spelling: xmlgen $(SPHINXCONFIG)/conf.py $(VENV) $(SPHINXCONFIG)/false_positives
)
@echo "Spell check finished."
epub: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
epub: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
@$(MAKE) $(MFLAGS) -C graphviz all
@mkdir -p epub/JPG
@ -166,7 +176,7 @@ mobi: epub
@ebook-convert LAMMPS.epub LAMMPS.mobi
@echo "Conversion finished. The MOBI manual file is created."
pdf: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
pdf: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
@$(MAKE) $(MFLAGS) -C graphviz all
@if [ "$(HAS_PDFLATEX)" == "NO" ] ; then echo "PDFLaTeX or latexmk were not found! Please check README for further instructions" 1>&2; exit 1; fi
@ -185,6 +195,8 @@ pdf: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst ;\
env LC_ALL=C grep -n '\(ref\|doc\)`[^`]' $(RSTDIR)/*.rst ;\
$(PYTHON) utils/check-styles.py -s ../src -d src ;\
env LC_ALL=C grep -n -E '^ *\.\. [a-z0-9]+:(\s+.*|)$$' \
$(RSTDIR)/*.rst ../src/*.{cpp,h} ../src/*/*.{cpp,h} ;\
echo "############################################" ;\
deactivate ;\
)
@ -234,6 +246,8 @@ role_check :
@( env LC_ALL=C grep -n ' `[^`]\+<[a-z][^`]\+`[^_]' $(RSTDIR)/*.rst && exit 1 || : )
@( env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst && exit 1 || : )
@( env LC_ALL=C grep -n '\(ref\|doc\)`[^`]' $(RSTDIR)/*.rst && exit 1 || : )
@( env LC_ALL=C grep -n -E '^ *\.\. [a-z0-9]+:(\s+.*|)$$' \
$(RSTDIR)/*.rst ../src/*.{cpp,h} ../src/*/*.{cpp,h} && exit 1 || : )
link_check : $(VENV) html
@(\

20
doc/README
View File

@ -22,12 +22,12 @@ doxygen-warn.log logfile with warnings from running doxygen
and:
github-development-workflow.md notes on the LAMMPS development workflow
include-file-conventions.md notes on LAMMPS' include file conventions
documentation_conventions.md notes on writing documentation for LAMMPS
If you downloaded a LAMMPS tarball from www.lammps.org, then the html
folder and the PDF manual should be included. If you downloaded LAMMPS
from GitHub then you either need to build them.
using GitHub then you either need to build them yourself or read the
online version at https://docs.lammps.org/
You can build the HTML and PDF files yourself, by typing "make html"
or by "make pdf", respectively. This requires various tools and files.
@ -39,10 +39,10 @@ environment and local folders.
Installing prerequisites for the documentation build
To run the HTML documention build toolchain, python 3.x, doxygen, git,
and the venv python module have to be installed if not already available.
Also internet access is initially required to download external files
and tools.
To run the HTML documention build toolchain, python 3.8 or later,
doxygen 1.8.10 or later, git, and the venv python module have to be
installed if not already available. Also internet access is initially
required to download external files and tools.
Building the PDF format manual requires in addition a compatible LaTeX
installation with support for PDFLaTeX and several add-on LaTeX packages
@ -52,16 +52,24 @@ installed. This includes:
- babel
- capt-of
- cmap
- dvipng
- ellipse
- fncychap
- fontawesom
- framed
- geometry
- gyre
- hyperref
- hypcap
- needspace
- pict2e
- times
- tabulary
- titlesec
- upquote
- wrapfig
- xindy
Also the latexmk script is required to run PDFLaTeX and related tools.
the required number of times to have self-consistent output and include
updated bibliography and indices.

9
doc/documentation_conventions.md
View File

@ -10,7 +10,7 @@ Last change: 2022-12-30
In fall 2019, the LAMMPS documentation file format has changed from a
home grown markup designed to generate HTML format files only, to
[reStructuredText](https://docutils.sourceforge.io/rst.html>. For a
[reStructuredText](https://docutils.sourceforge.io/rst.html>). For a
transition period all files in the old .txt format were transparently
converted to .rst and then processed. The `txt2rst tool` is still
included in the distribution to obtain an initial .rst file for legacy
@ -45,8 +45,7 @@ what kind of information and sections are needed.
## Formatting conventions
For headlines we try to follow the conventions posted here:
https://documentation-style-guide-sphinx.readthedocs.io/en/latest/style-guide.html#headings
For headlines we try to follow the conventions posted [here](https://documentation-style-guide-sphinx.readthedocs.io/en/latest/style-guide.html#headings).
It seems to be sufficient to have this consistent only within
any single file and it is not (yet) enforced strictly, but making
this globally consistent makes it easier to move sections around.
@ -64,7 +63,7 @@ Groups of shell commands or LAMMPS input script or C/C++/Python source
code should be typeset into a `.. code-block::` section. A syntax
highlighting extension for LAMMPS input scripts is provided, so `LAMMPS`
can be used to indicate the language in the code block in addition to
`bash`, `c`, `c++`, `console`, `csh`, `diff', `fortran`, `json`, `make`,
`bash`, `c`, `c++`, `console`, `csh`, `diff`, `fortran`, `json`, `make`,
`perl`, `powershell`, `python`, `sh`, or `tcl`, `text`, or `yaml`. When
no syntax style is indicated, no syntax highlighting is performed. When
typesetting commands executed on the shell, please do not prefix
@ -84,7 +83,7 @@ block can be used, followed by multiple `.. tab::` blocks, one
for each alternative. This is only used for HTML output. For other
outputs, the `.. tabs::` directive is transparently removed and
the individual `.. tab::` blocks will be replaced with an
`.. admonition::`` block. Thus in PDF and ePUB output those will
`.. admonition::` block. Thus in PDF and ePUB output those will
be realized as sequential and plain notes.
Special remarks can be highlighted with a `.. note::` block and

2
doc/doxygen/Doxyfile.in
View File

@ -2,7 +2,7 @@
DOXYFILE_ENCODING = UTF-8
PROJECT_NAME = "LAMMPS Programmer's Guide"
PROJECT_NUMBER = "4 May 2022"
PROJECT_NUMBER = "19 November 2024"
PROJECT_BRIEF = "Documentation of the LAMMPS library interface and Python wrapper"
PROJECT_LOGO = lammps-logo.png
CREATE_SUBDIRS = NO

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

@ -6,7 +6,9 @@ choices the LAMMPS developers have agreed on. Git and GitHub provide the
tools, but do not set policies, so it is up to the developers to come to
an agreement as to how to define and interpret policies. This document
is likely to change as our experiences and needs change, and we try to
adapt it accordingly. Last change 2023-02-10.
adapt it accordingly.
Last change: 2023-02-10
## Table of Contents
@ -72,7 +74,7 @@ be assigned to signal urgency to merge this pull request quickly.
People can be assigned to review a pull request in two ways:
* They can be assigned manually to review a pull request
by the submitter or a LAMMPS developer
by the submitter or a LAMMPS developer.
* They can be automatically assigned, because a developer's GitHub
handle matches a file pattern in the `.github/CODEOWNERS` file,
which associates developers with the code they contributed and
@ -86,9 +88,9 @@ required before merging, in addition to passing all automated
compilation and unit tests. Merging counts as implicit approval, so
does submission of a pull request (by a LAMMPS developer). So the person
doing the merge may not also submit an approving review. The GitHub
feature, that reviews from code owners are "hard" reviews (i.e. they
must all approve before merging is allowed), is currently disabled.
It is in the discretion of the merge maintainer to assess when a
feature that reviews from code owners are "hard" reviews (i.e. they
must all approve before merging is allowed) is currently disabled.
It is at the discretion of the merge maintainer to assess when a
sufficient degree of approval has been reached, especially from external
collaborators. Reviews may be (automatically) dismissed, when the
reviewed code has been changed. Review may be requested a second time.
@ -147,7 +149,8 @@ only contain bug fixes, feature additions to peripheral functionality,
and documentation updates. In between stable releases, bug fixes and
infrastructure updates are back-ported from the "develop" branch to the
"maintenance" branch and occasionally merged into "stable" and published
as update releases.
as update releases. Further explanation of LAMMPS versions can be found
[in the documentation](https://docs.lammps.org/Manual_version.html).
## Project Management

6
doc/graphviz/lammps-releases.dot
View File

@ -5,13 +5,13 @@ digraph releases {
github -> develop [label="Merge commits"];
{
rank = "same";
work [shape="none" label="Development branches:"]
work [shape="none" label="Development branches:" fontname="bold"]
develop [label="'develop' branch" height=0.75];
maintenance [label="'maintenance' branch" height=0.75];
};
{
rank = "same";
upload [shape="none" label="Release branches:"]
upload [shape="none" label="Release branches:" fontname="bold"]
release [label="'release' branch" height=0.75];
stable [label="'stable' branch" height=0.75];
};
@ -22,7 +22,7 @@ digraph releases {
maintenance -> stable [label="Updates to stable release"];
{
rank = "same";
tag [shape="none" label="Applied tags:"];
tag [shape="none" label="Applied tags:" fontname="bold"];
patchtag [shape="box" label="patch_<date>"];
stabletag [shape="box" label="stable_<date>"];
updatetag [shape="box" label="stable_<date>_update<num>"];

6
doc/lammps.1
View File

@ -1,7 +1,7 @@
.TH LAMMPS "1" "29 August 2024" "2024-08-29"
.TH LAMMPS "1" "12 June 2025" "2025-06-12"
.SH NAME
.B LAMMPS
\- Molecular Dynamics Simulator. Version 29 August 2024
\- Molecular Dynamics Simulator. Version 12 June 2025
.SH SYNOPSIS
.B lmp
@ -311,7 +311,7 @@ the chapter on errors in the
manual gives some additional information about error messages, if possible.
.SH COPYRIGHT
© 2003--2024 Sandia Corporation
© 2003--2025 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

13
doc/src/Build.rst
View File

@ -1,10 +1,14 @@
Build LAMMPS
============
LAMMPS is built as a library and an executable from source code using
either traditional makefiles for use with GNU make (which may require
manual editing), or using a build environment generated by CMake (Unix
Makefiles, Ninja, Xcode, Visual Studio, KDevelop, CodeBlocks and more).
LAMMPS is built as a library and an executable from source code using a
build environment generated by CMake (Unix Makefiles, Ninja, Xcode,
Visual Studio, KDevelop, CodeBlocks and more depending on the platform).
Using CMake is the preferred way to build LAMMPS. In addition, LAMMPS
can be compiled using the legacy build system based on traditional
makefiles for use with GNU make (which may require manual editing).
Support for the legacy build system is slowly being phased out and may
not be available for all optional features.
As an alternative, you can download a package with pre-built executables
or automated build trees, as described in the :doc:`Install <Install>`
@ -13,6 +17,7 @@ section of the manual.
.. toctree::
:maxdepth: 1
Build_prerequisites
Build_cmake
Build_make
Build_link

51
doc/src/Build_basics.rst
View File

@ -160,7 +160,7 @@ with the OpenMP 3.1 semantics used in LAMMPS for maximal compatibility
with compiler versions in use. If compilation with OpenMP enabled fails
because of your compiler requiring strict OpenMP 4.0 semantics, you can
change the behavior by adding ``-D LAMMPS_OMP_COMPAT=4`` to the
``LMP_INC`` variable in your makefile, or add it to the command line
``LMP_INC`` variable in your makefile, or add it to the command-line flags
while configuring with CMake. LAMMPS will auto-detect a suitable setting
for most GNU, Clang, and Intel compilers.
@ -196,22 +196,23 @@ LAMMPS.
.. tab:: CMake build
By default CMake will use the compiler it finds according to
By default CMake will use the compiler it finds according to its
internal preferences, and it will add optimization flags
appropriate to that compiler and any :doc:`accelerator packages
<Speed_packages>` you have included in the build. CMake will
check if the detected or selected compiler is compatible with the
C++ support requirements of LAMMPS and stop with an error, if this
is not the case.
is not the case. A C++11 compatible compiler is currently
required, but a transition to require C++17 is in progress and
planned to be completed in Summer 2025. Currently, setting
``-DLAMMPS_CXX11=yes`` is required when configuring with CMake while
using a C++11 compatible compiler that does not support C++17,
otherwise setting ``-DCMAKE_CXX_STANDARD=17`` is preferred.
You can tell CMake to look for a specific compiler with setting
CMake variables (listed below) during configuration. For a few
common choices, there are also presets in the ``cmake/presets``
folder. For convenience, there is a ``CMAKE_TUNE_FLAGS`` variable
that can be set to apply global compiler options (applied to
compilation only), to be used for adding compiler or host specific
optimization flags in addition to the "flags" variables listed
below. You may also specify the corresponding ``CMAKE_*_FLAGS``
folder. You may also specify the corresponding ``CMAKE_*_FLAGS``
variables individually, if you want to experiment with alternate
optimization flags. You should specify all 3 compilers, so that
the (few) LAMMPS source files written in C or Fortran are built
@ -223,6 +224,8 @@ LAMMPS.
-D CMAKE_C_COMPILER=name # name of C compiler
-D CMAKE_Fortran_COMPILER=name # name of Fortran compiler
-D CMAKE_CXX_STANDARD=17 # put compiler in C++17 mode
-D LAMMPS_CXX11=yes # enforce compilation in C++11 mode
-D CMAKE_CXX_FLAGS=string # flags to use with C++ compiler
-D CMAKE_C_FLAGS=string # flags to use with C compiler
-D CMAKE_Fortran_FLAGS=string # flags to use with Fortran compiler
@ -259,10 +262,6 @@ LAMMPS.
``-C ../cmake/presets/pgi.cmake`` will switch the compiler to the PGI compilers,
and ``-C ../cmake/presets/nvhpc.cmake`` will switch to the NVHPC compilers.
Furthermore, you can set ``CMAKE_TUNE_FLAGS`` to specifically add
compiler flags to tune for optimal performance on given hosts.
This variable is empty by default.
.. note::
When the cmake command completes, it prints a summary to the
@ -321,15 +320,23 @@ LAMMPS.
you would have to install a newer compiler that supports C++11;
either as a binary package or through compiling from source.
If you build LAMMPS with any :doc:`Speed_packages` included,
there may be specific compiler or linker flags that are either
required or recommended to enable required features and to
achieve optimal performance. You need to include these in the
``CCFLAGS`` and ``LINKFLAGS`` settings above. For details, see the
documentation for the individual packages listed on the
:doc:`Speed_packages` page. Or examine these files in the
``src/MAKE/OPTIONS`` directory. They correspond to each of the 5
accelerator packages and their hardware variants:
While a C++11 compatible compiler is currently sufficient to compile
LAMMPS, a transition to require C++17 is in progress and planned to
be completed in Summer 2025. Currently, setting ``-DLAMMPS_CXX11``
in the ``LMP_INC =`` line in the machine makefile is required when
using a C++11 compatible compiler that does not support C++17.
Otherwise, to enable C++17 support (if not enabled by default) using
a compiler flag like ``-std=c++17`` in CCFLAGS may needed.
If you build LAMMPS with any :doc:`Speed_packages` included,
there may be specific compiler or linker flags that are either
required or recommended to enable required features and to
achieve optimal performance. You need to include these in the
``CCFLAGS`` and ``LINKFLAGS`` settings above. For details, see the
documentation for the individual packages listed on the
:doc:`Speed_packages` page. Or examine these files in the
``src/MAKE/OPTIONS`` directory. They correspond to each of the 5
accelerator packages and their hardware variants:
.. code-block:: bash
@ -502,6 +509,8 @@ using CMake or Make.
# chain.x, micelle2d.x, msi2lmp, phana,
# stl_bin2txt
-D BUILD_LAMMPS_GUI=value # yes or no (default). Build LAMMPS-GUI
-D BUILD_WHAM=value # yes (default). Download and build WHAM;
# only available for BUILD_LAMMPS_GUI=yes
The generated binaries will also become part of the LAMMPS installation
(see below).

41
doc/src/Build_cmake.rst
View File

@ -8,7 +8,7 @@ packages. Links to those pages on the :doc:`Build overview <Build>`
page.
The following text assumes some familiarity with CMake and focuses on
using the command line tool ``cmake`` and what settings are supported
using the command-line tool ``cmake`` and what settings are supported
for building LAMMPS. A more detailed tutorial on how to use CMake
itself, the text mode or graphical user interface, to change the
generated output files for different build tools and development
@ -16,7 +16,7 @@ environments is on a :doc:`separate page <Howto_cmake>`.
.. note::
LAMMPS currently requires that CMake version 3.16 or later is available.
LAMMPS currently requires that CMake version 3.20 or later is available.
.. warning::
@ -32,29 +32,29 @@ environments is on a :doc:`separate page <Howto_cmake>`.
Advantages of using CMake
^^^^^^^^^^^^^^^^^^^^^^^^^
CMake is an alternative to compiling LAMMPS in the traditional way
through :doc:`(manually customized) makefiles <Build_make>`. Using
CMake has multiple advantages that are specifically helpful for
people with limited experience in compiling software or for people
that want to modify or extend LAMMPS.
CMake is the preferred way of compiling LAMMPS in contrast to the legacy
build system based on GNU make and through :doc:`(manually customized)
makefiles <Build_make>`. Using CMake has multiple advantages that are
specifically helpful for people with limited experience in compiling
software or for people that want to modify or extend LAMMPS.
- CMake can detect available hardware, tools, features, and libraries
and adapt the LAMMPS default build configuration accordingly.
- CMake can generate files for different build tools and integrated
development environments (IDE).
- CMake supports customization of settings with a command line, text
- CMake supports customization of settings with a command-line, text
mode, or graphical user interface. No manual editing of files,
knowledge of file formats or complex command line syntax is required.
knowledge of file formats or complex command-line syntax is required.
- All enabled components are compiled in a single build operation.
- Automated dependency tracking for all files and configuration options.
- Support for true out-of-source compilation. Multiple configurations
- Support for true out-of-source compilation. Multiple configurations
and settings with different choices of LAMMPS packages, settings, or
compilers can be configured and built concurrently from the same
source tree.
- Simplified packaging of LAMMPS for Linux distributions, environment
modules, or automated build tools like `Homebrew <https://brew.sh/>`_.
- Integration of automated unit and regression testing (the LAMMPS side
of this is still under active development).
modules, or automated build tools like `Spack <https://spack.io>`_
or `Homebrew <https://brew.sh/>`_.
- Integration of automated unit and regression testing.
.. _cmake_build:
@ -68,7 +68,7 @@ that purpose you can use either the command-line utility ``cmake`` (or
graphical utility ``cmake-gui``, or use them interchangeably. The
second step is then the compilation and linking of all objects,
libraries, and executables using the selected build tool. Here is a
minimal example using the command line version of CMake to build LAMMPS
minimal example using the command-line version of CMake to build LAMMPS
with no add-on packages enabled and no customization:
.. code-block:: bash
@ -119,6 +119,13 @@ configured) and additional files like LAMMPS API headers, manpages,
potential and force field files. The location of the installation tree
defaults to ``${HOME}/.local``.
.. note::
If you have set `-D CMAKE_INSTALL_PREFIX` to install LAMMPS into a
system location on a Linux machine , you may also have to run (as
root) the `ldconfig` program to update the cache file for fast lookup
of system shared libraries.
.. _cmake_options:
Configuration and build options
@ -131,7 +138,7 @@ file called ``CMakeLists.txt`` (for LAMMPS it is located in the
configuration step. The cache file contains all current CMake settings.
To modify settings, enable or disable features, you need to set
*variables* with either the ``-D`` command line flag (``-D
*variables* with either the ``-D`` command-line flag (``-D
VARIABLE1_NAME=value``) or change them in the text mode of the graphical
user interface. The ``-D`` flag can be used several times in one command.
@ -141,11 +148,11 @@ a different compiler tool chain. Those are loaded with the ``-C`` flag
(``-C ../cmake/presets/basic.cmake``). This step would only be needed
once, as the settings from the preset files are stored in the
``CMakeCache.txt`` file. It is also possible to customize the build
by adding one or more ``-D`` flags to the CMake command line.
by adding one or more ``-D`` flags to the CMake command.
Generating files for alternate build tools (e.g. Ninja) and project files
for IDEs like Eclipse, CodeBlocks, or Kate can be selected using the ``-G``
command line flag. A list of available generator settings for your
command-line flag. A list of available generator settings for your
specific CMake version is given when running ``cmake --help``.
.. _cmake_multiconfig:

10
doc/src/Build_development.rst
View File

@ -263,9 +263,9 @@ will be skipped if prerequisite features are not available in LAMMPS.
time. Preference is given to parts of the code base that are easy to
test or commonly used.
Tests as shown by the ``ctest`` program are command lines defined in the
Tests as shown by the ``ctest`` program are commands defined in the
``CMakeLists.txt`` files in the ``unittest`` directory tree. A few
tests simply execute LAMMPS with specific command line flags and check
tests simply execute LAMMPS with specific command-line flags and check
the output to the screen for expected content. A large number of unit
tests are special tests programs using the `GoogleTest framework
<https://github.com/google/googletest/>`_ and linked to the LAMMPS
@ -420,7 +420,7 @@ during MD timestepping and manipulate per-atom properties like
positions, velocities, and forces. For those fix styles, testing can be
done in a very similar fashion as for force fields and thus there is a
test program `test_fix_timestep` that shares a lot of code, properties,
and command line flags with the force field style testers described in
and command-line flags with the force field style testers described in
the previous section.
This tester will set up a small molecular system run with verlet run
@ -642,10 +642,10 @@ The following target are available for both, GNU make and CMake:
.. _gh-cli:
GitHub command line interface
GitHub command-line interface
-----------------------------
GitHub has developed a `command line tool <https://cli.github.com>`_
GitHub has developed a `command-line tool <https://cli.github.com>`_
to interact with the GitHub website via a command called ``gh``.
This is extremely convenient when working with a Git repository hosted
on GitHub (like LAMMPS). It is thus highly recommended to install it

172
doc/src/Build_extras.rst
View File

@ -48,6 +48,7 @@ This is the list of packages that may require additional steps.
* :ref:`LEPTON <lepton>`
* :ref:`MACHDYN <machdyn>`
* :ref:`MDI <mdi>`
* :ref:`MISC <misc>`
* :ref:`ML-HDNNP <ml-hdnnp>`
* :ref:`ML-IAP <mliap>`
* :ref:`ML-PACE <ml-pace>`
@ -209,7 +210,7 @@ necessary for ``hipcc`` and the linker to work correctly.
Using the CHIP-SPV implementation of HIP is supported. It allows one to
run HIP code on Intel GPUs via the OpenCL or Level Zero back ends. To use
CHIP-SPV, you must set ``-DHIP_USE_DEVICE_SORT=OFF`` in your CMake
command line as CHIP-SPV does not yet support hipCUB. As of Summer 2022,
command-line as CHIP-SPV does not yet support hipCUB. As of Summer 2022,
the use of HIP for Intel GPUs is experimental. You should only use this
option in preparations to run on Aurora system at Argonne.
@ -232,7 +233,7 @@ option in preparations to run on Aurora system at Argonne.
.. code:: bash
# CUDA target (not recommended, use GPU_ARCH=cuda)
# CUDA target (not recommended, use GPU_API=cuda)
# !!! DO NOT set CMAKE_CXX_COMPILER !!!
export HIP_PLATFORM=nvcc
export HIP_PATH=/path/to/HIP/install
@ -254,11 +255,10 @@ Traditional make
Before building LAMMPS, you must build the GPU library in ``lib/gpu``\ .
You can do this manually if you prefer; follow the instructions in
``lib/gpu/README``. Note that the GPU library uses MPI calls, so you must
use the same MPI library (or the STUBS library) settings as the main
LAMMPS code. This also applies to the ``-DLAMMPS_BIGBIG``\ ,
``-DLAMMPS_SMALLBIG``\ , or ``-DLAMMPS_SMALLSMALL`` settings in whichever
Makefile you use.
``lib/gpu/README``. Note that the GPU library uses MPI calls, so you
must use the same MPI library (or the STUBS library) settings as the
main LAMMPS code. This also applies to the ``-DLAMMPS_BIGBIG`` or
``-DLAMMPS_SMALLBIG`` settings in whichever Makefile you use.
You can also build the library in one step from the ``lammps/src`` dir,
using a command like these, which simply invokes the ``lib/gpu/Install.py``
@ -421,9 +421,10 @@ minutes to hours) to build. Of course you only need to do that once.)
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.
set with the ``make`` command for use by cmake. For example, to use the
``cmake3`` executable and tell it to use the GNU version 11 compilers
called ``g++-11``, ``gcc-11`` and ``gfortran-11`` to build KIM, one
could use the following command.
.. code-block:: bash
@ -546,16 +547,7 @@ They must be specified in uppercase.
- Local machine
* - AMDAVX
- HOST
- AMD 64-bit x86 CPU (AVX 1)
* - ZEN
- HOST
- AMD Zen class CPU (AVX 2)
* - ZEN2
- HOST
- AMD Zen2 class CPU (AVX 2)
* - ZEN3
- HOST
- AMD Zen3 class CPU (AVX 2)
- AMD chip
* - ARMV80
- HOST
- ARMv8.0 Compatible CPU
@ -571,105 +563,129 @@ They must be specified in uppercase.
* - A64FX
- HOST
- ARMv8.2 with SVE Support
* - ARMV9_GRACE
- HOST
- ARMv9 NVIDIA Grace CPU
* - SNB
- HOST
- Intel Sandy/Ivy Bridge CPU (AVX 1)
- Intel Sandy/Ivy Bridge CPUs
* - HSW
- HOST
- Intel Haswell CPU (AVX 2)
- Intel Haswell CPUs
* - BDW
- HOST
- Intel Broadwell Xeon E-class CPU (AVX 2 + transactional mem)
* - SKL
- HOST
- Intel Skylake Client CPU
* - SKX
- HOST
- Intel Skylake Xeon Server CPU (AVX512)
- Intel Broadwell Xeon E-class CPUs
* - ICL
- HOST
- Intel Ice Lake Client CPU (AVX512)
- Intel Ice Lake Client CPUs (AVX512)
* - ICX
- HOST
- Intel Ice Lake Xeon Server CPU (AVX512)
* - SPR
- Intel Ice Lake Xeon Server CPUs (AVX512)
* - SKL
- HOST
- Intel Sapphire Rapids Xeon Server CPU (AVX512)
- Intel Skylake Client CPUs
* - SKX
- HOST
- Intel Skylake Xeon Server CPUs (AVX512)
* - KNC
- HOST
- Intel Knights Corner Xeon Phi
* - KNL
- HOST
- Intel Knights Landing Xeon Phi
* - SPR
- HOST
- Intel Sapphire Rapids Xeon Server CPUs (AVX512)
* - POWER8
- HOST
- IBM POWER8 CPU
- IBM POWER8 CPUs
* - POWER9
- HOST
- IBM POWER9 CPU
- IBM POWER9 CPUs
* - ZEN
- HOST
- AMD Zen architecture
* - ZEN2
- HOST
- AMD Zen2 architecture
* - ZEN3
- HOST
- AMD Zen3 architecture
* - ZEN4
- HOST
- AMD Zen4 architecture
* - RISCV_SG2042
- HOST
- SG2042 (RISC-V) CPU
- SG2042 (RISC-V) CPUs
* - RISCV_RVA22V
- HOST
- RVA22V (RISC-V) CPUs
* - KEPLER30
- GPU
- NVIDIA Kepler generation CC 3.0 GPU
- NVIDIA Kepler generation CC 3.0
* - KEPLER32
- GPU
- NVIDIA Kepler generation CC 3.2 GPU
- NVIDIA Kepler generation CC 3.2
* - KEPLER35
- GPU
- NVIDIA Kepler generation CC 3.5 GPU
- NVIDIA Kepler generation CC 3.5
* - KEPLER37
- GPU
- NVIDIA Kepler generation CC 3.7 GPU
- NVIDIA Kepler generation CC 3.7
* - MAXWELL50
- GPU
- NVIDIA Maxwell generation CC 5.0 GPU
- NVIDIA Maxwell generation CC 5.0
* - MAXWELL52
- GPU
- NVIDIA Maxwell generation CC 5.2 GPU
- NVIDIA Maxwell generation CC 5.2
* - MAXWELL53
- GPU
- NVIDIA Maxwell generation CC 5.3 GPU
- NVIDIA Maxwell generation CC 5.3
* - PASCAL60
- GPU
- NVIDIA Pascal generation CC 6.0 GPU
- NVIDIA Pascal generation CC 6.0
* - PASCAL61
- GPU
- NVIDIA Pascal generation CC 6.1 GPU
- NVIDIA Pascal generation CC 6.1
* - VOLTA70
- GPU
- NVIDIA Volta generation CC 7.0 GPU
- NVIDIA Volta generation CC 7.0
* - VOLTA72
- GPU
- NVIDIA Volta generation CC 7.2 GPU
- NVIDIA Volta generation CC 7.2
* - TURING75
- GPU
- NVIDIA Turing generation CC 7.5 GPU
- NVIDIA Turing generation CC 7.5
* - AMPERE80
- GPU
- NVIDIA Ampere generation CC 8.0 GPU
- NVIDIA Ampere generation CC 8.0
* - AMPERE86
- GPU
- NVIDIA Ampere generation CC 8.6 GPU
- NVIDIA Ampere generation CC 8.6
* - ADA89
- GPU
- NVIDIA Ada Lovelace generation CC 8.9 GPU
- NVIDIA Ada generation CC 8.9
* - HOPPER90
- GPU
- NVIDIA Hopper generation CC 9.0 GPU
- NVIDIA Hopper generation CC 9.0
* - AMD_GFX906
- GPU
- AMD GPU MI50/MI60
- AMD GPU MI50/60
* - AMD_GFX908
- GPU
- AMD GPU MI100
* - AMD_GFX90A
- GPU
- AMD GPU MI200
* - AMD_GFX940
- GPU
- AMD GPU MI300
* - AMD_GFX942
- GPU
- AMD GPU MI300
* - AMD_GFX942_APU
- GPU
- AMD APU MI300A
* - AMD_GFX1030
- GPU
- AMD GPU V620/W6800
@ -678,7 +694,7 @@ They must be specified in uppercase.
- AMD GPU RX7900XTX
* - AMD_GFX1103
- GPU
- AMD Phoenix APU with Radeon 740M/760M/780M/880M/890M
- AMD APU Phoenix
* - INTEL_GEN
- GPU
- SPIR64-based devices, e.g. Intel GPUs, using JIT
@ -701,7 +717,7 @@ They must be specified in uppercase.
- GPU
- Intel GPU Ponte Vecchio
This list was last updated for version 4.3.0 of the Kokkos library.
This list was last updated for version 4.6.0 of the Kokkos library.
.. tabs::
@ -1125,11 +1141,10 @@ POEMS package
PYTHON package
---------------------------
Building with the PYTHON package requires you have a the Python development
headers and library available on your system, which needs to be a Python 2.7
version or a Python 3.x version. Since support for Python 2.x has ended,
using Python 3.x is strongly recommended. See ``lib/python/README`` for
additional details.
Building with the PYTHON package requires you have a the Python
development headers and library available on your system, which
needs to be Python version 3.6 or later. See ``lib/python/README``
for additional details.
.. tabs::
@ -1145,7 +1160,7 @@ additional details.
set the Python_EXECUTABLE variable to specify which Python
interpreter should be used. Note note that you will also need to
have the development headers installed for this version,
e.g. python2-devel.
e.g. python3-devel.
.. tab:: Traditional make
@ -2018,7 +2033,7 @@ TBB and MKL.
.. _mdi:
MDI package
-----------------------------
-----------
.. tabs::
@ -2045,6 +2060,37 @@ MDI package
----------
.. _misc:
MISC package
------------
The :doc:`fix imd <fix_imd>` style in this package can be run either
synchronously (communication with IMD clients is done in the main
process) or asynchronously (the fix spawns a separate thread that can
communicate with IMD clients concurrently to the LAMMPS execution).
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D LAMMPS_ASYNC_IMD=value # Run IMD server asynchronously
# value = no (default) or yes
.. tab:: Traditional make
To enable asynchronous mode the ``-DLAMMPS_ASYNC_IMD`` define
needs to be added to the ``LMP_INC`` variable in the
``Makefile.machine`` you are using. For example:
.. code-block:: make
LMP_INC = -DLAMMPS_ASYNC_IMD -DLAMMPS_MEMALIGN=64
----------
.. _molfile:
MOLFILE package
@ -2191,7 +2237,7 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to
from the sources in the *lib* folder (including the essential
libqmmm.a) are not included in the static LAMMPS library and
(currently) not installed, while their code is included in the
shared LAMMPS library. Thus a typical command line to configure
shared LAMMPS library. Thus a typical command to configure
building LAMMPS for QMMM would be:
.. code-block:: bash

10
doc/src/Build_make.rst
View File

@ -8,6 +8,10 @@ Building LAMMPS with traditional makefiles requires that you have a
for customizing your LAMMPS build with a number of global compilation
options and features.
This build system is slowly being phased out and may not support all
optional features and packages in LAMMPS. It is recommended to switch
to the :doc:`CMake based build system <Build_cmake>`.
Requirements
^^^^^^^^^^^^
@ -26,9 +30,9 @@ additional tools to be available and functioning.
* A Bourne shell compatible "Unix" shell program (frequently this is ``bash``)
* A few shell utilities: ``ls``, ``mv``, ``ln``, ``rm``, ``grep``, ``sed``, ``tr``, ``cat``, ``touch``, ``diff``, ``dirname``
* Python (optional, required for ``make lib-<pkg>`` in the ``src``
folder). Python scripts are currently tested with python 2.7 and
3.6 to 3.11. The procedure for :doc:`building the documentation
<Build_manual>` *requires* Python 3.5 or later.
folder). Python scripts are currently tested with 3.6 to 3.11.
The procedure for :doc:`building the documentation <Build_manual>`
*requires* Python 3.8 or later.
Getting started
^^^^^^^^^^^^^^^

88
doc/src/Build_manual.rst
View File

@ -78,8 +78,7 @@ folder. The following ``make`` commands are available:
make epub # generate LAMMPS.epub in ePUB format using Sphinx
make mobi # generate LAMMPS.mobi in MOBI format using ebook-convert
make fasthtml # generate approximate HTML in fasthtml dir using Sphinx
# some Sphinx extensions do not work correctly with this
make fasthtml # generate approximate HTML in fasthtml dir using pandoc
make clean # remove intermediate RST files created by HTML build
make clean-all # remove entire build folder and any cached data
@ -116,9 +115,9 @@ environment variable.
Prerequisites for HTML
----------------------
To run the HTML documentation build toolchain, python 3, git, doxygen,
and virtualenv have to be installed locally. Here are instructions for
common setups:
To run the HTML documentation build toolchain, Python 3.8 or later, git,
doxygen, and virtualenv have to be installed locally. Here are
instructions for common setups:
.. tabs::
@ -128,13 +127,7 @@ common setups:
sudo apt-get install git doxygen
.. tab:: RHEL or CentOS (Version 7.x)
.. code-block:: bash
sudo yum install git doxygen
.. tab:: Fedora or RHEL/CentOS (8.x or later)
.. tab:: Fedora or RHEL/AlmaLinux/RockyLinux (8.x or later)
.. code-block:: bash
@ -154,7 +147,36 @@ Prerequisites for PDF
In addition to the tools needed for building the HTML format manual,
a working LaTeX installation with support for PDFLaTeX and a selection
of LaTeX styles/packages are required. To run the PDFLaTeX translation
of LaTeX styles/packages are required. Apart from LaTeX packages that
are usually installed by default, the following packages are required:
.. table_from_list::
:columns: 11
- amsmath
- anysize
- babel
- capt-of
- cmap
- dvipng
- ellipse
- fncychap
- fontawesome
- framed
- geometry
- gyre
- hyperref
- hypcap
- needspace
- pict2e
- times
- tabulary
- titlesec
- upquote
- wrapfig
- xindy
To run the PDFLaTeX translation
the ``latexmk`` script needs to be installed as well.
Prerequisites for ePUB and MOBI
@ -182,12 +204,42 @@ documentation is required and either existing files in the ``src``
folder need to be updated or new files added. These files are written in
`reStructuredText <rst_>`_ markup for translation with the Sphinx tool.
Testing your contribution
^^^^^^^^^^^^^^^^^^^^^^^^^
Before contributing any documentation, please check that both the HTML
and the PDF format documentation can translate without errors. During
testing the html translation, you may use the ``make fasthtml`` command
which does an approximate translation (i.e. not all Sphinx features and
extensions will work), but runs very fast because it will only translate
files that have been changed since the last ``make fasthtml`` command.
and the PDF format documentation can translate without errors and that
there are no spelling issues. This is done with ``make html``, ``make pdf``,
and ``make spelling``, respectively.
Fast and approximate translation to HTML
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Translating the full manual to HTML or PDF can take a long time. Thus
there is a fast and approximate way to translate the reStructuredText to
HTML as a quick-n-dirty way of checking your manual page.
This translation uses `Pandoc <https://pandoc.org>`_ instead of Sphinx
and thus all special Sphinx features (cross-references, advanced tables,
embedding of Python docstrings or doxygen documentation, and so on) will
not render correctly. Most embedded math should render correctly. This
is a **very fast** way to check the syntax and layout of a documentation
file translated to HTML while writing or updating it.
To translate **all** manual pages, you can type ``make fasthtml`` at the
command line. The translated HTML files are then in the ``fasthtml``
folder. All subsequent ``make fasthtml`` commands will only translate
``.rst`` files that have been changed. The ``make fasthtml`` command
can be parallelized with make using the `-j` flag. You can also
directly translate only individual pages: e.g. to translate only the
``doc/src/pair_lj.rst`` page type ``make fasthtml/pair_lj.html``
After writing the documentation is completed, you will still need
to verify with ``make html`` and ``make pdf`` that it translates
correctly in both formats.
Tests for consistency, completeness, and other known issues
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Please also check the output to the console for any warnings or problems. There will
be multiple tests run automatically:

1
doc/src/Build_package.rst
View File

@ -49,6 +49,7 @@ packages:
* :ref:`LEPTON <lepton>`
* :ref:`MACHDYN <machdyn>`
* :ref:`MDI <mdi>`
* :ref:`MISC <misc>`
* :ref:`ML-HDNNP <ml-hdnnp>`
* :ref:`ML-IAP <mliap>`
* :ref:`ML-PACE <ml-pace>`

22
doc/src/Build_prerequisites.rst Normal file
View File

@ -0,0 +1,22 @@
Prerequisites
-------------
Which software you need to compile and use LAMMPS strongly depends on
which :doc:`features and settings <Build_settings>` and which
:doc:`optional packages <Packages_list>` you are trying to include.
Common to all is that you need a C++ and C compiler, where the C++
compiler has to support at least the C++11 standard (note that some
compilers require command-line flag to activate C++11 support).
Furthermore, if you are building with CMake, you need at least CMake
version 3.20 and a compatible build tool (make or ninja-build); if you
are building the the legacy GNU make based build system you need GNU
make (other make variants are not going to work since the build system
uses features unique to GNU make) and a Unix-like build environment with
a Bourne shell, and shell tools like "sed", "grep", "touch", "test",
"tr", "cp", "mv", "rm", "ln", "diff" and so on. Parts of LAMMPS
interface with or use Python version 3.6 or later.
The LAMMPS developers aim to keep LAMMPS very portable and usable -
at least in parts - on most operating systems commonly used for
running MD simulations. Please see the :doc:`section on portablility
<Intro_portability>` for more details.

107
doc/src/Build_settings.rst
View File

@ -8,29 +8,30 @@ Optional build settings
LAMMPS can be built with several optional settings. Each subsection
explains how to do this for building both with CMake and make.
* `C++11 standard compliance`_ when building all of LAMMPS
* `C++11 and C++17 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 JPEG, PNG, and movie files`_ via the :doc:`dump image <dump_image>` or :doc:`dump movie <dump_image>` commands
* `Support for downloading files`_
* `Support for downloading files from the input`_
* `Prevent download of large potential files`_
* `Memory allocation alignment`_
* `Workaround for long long integers`_
* `Exception handling when using LAMMPS as a library`_ to capture errors
* `Trigger selected floating-point exceptions`_
----------
.. _cxx11:
C++11 standard compliance
-------------------------
C++11 and C++17 standard compliance
-----------------------------------
A C++11 standard compatible compiler is a requirement for compiling LAMMPS.
LAMMPS version 3 March 2020 is the last version compatible with the previous
C++98 standard for the core code and most packages. Most currently used
C++ compilers are compatible with C++11, but some older ones may need extra
flags to enable C++11 compliance. Example for GNU c++ 4.8.x:
A C++11 standard compatible compiler is currently the minimum
requirement for compiling LAMMPS. LAMMPS version 3 March 2020 is the
last version compatible with the previous C++98 standard for the core
code and most packages. Most currently used C++ compilers are compatible
with C++11, but some older ones may need extra flags to enable C++11
compliance. Example for GNU c++ 4.8.x:
.. code-block:: make
@ -40,6 +41,17 @@ Individual packages may require compliance with a later C++ standard
like C++14 or C++17. These requirements will be documented with the
:doc:`individual packages <Packages_details>`.
.. versionchanged:: 4Feb2025
Starting with LAMMPS version 4 February 2025 we are starting a
transition to require the C++17 standard. Most current compilers are
compatible and if the C++17 standard is available by default, LAMMPS
will enable C++17 and will compile normally. If the chosen compiler is
not compatible with C++17, but only supports C++11, then the define
-DLAMMPS_CXX11 is required to fall back to compiling with a C++11
compiler. After the next stable release of LAMMPS in summer 2025, the
LAMMPS development branch and future releases will require C++17.
----------
.. _fft:
@ -303,7 +315,7 @@ large counters can become before "rolling over". The default setting of
.. code-block:: bash
-D LAMMPS_SIZES=value # smallbig (default) or bigbig or smallsmall
-D LAMMPS_SIZES=value # smallbig (default) or bigbig
If the variable is not set explicitly, "smallbig" is used.
@ -314,7 +326,7 @@ large counters can become before "rolling over". The default setting of
.. code-block:: make
LMP_INC = -DLAMMPS_SMALLBIG # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL
LMP_INC = -DLAMMPS_SMALLBIG # or -DLAMMPS_BIGBIG
The default setting is ``-DLAMMPS_SMALLBIG`` if nothing is specified
@ -323,34 +335,27 @@ LAMMPS system size restrictions
.. list-table::
:header-rows: 1
:widths: 18 27 28 27
:widths: 27 36 37
:align: center
* -
- smallbig
- bigbig
- smallsmall
* - Total atom count
- :math:`2^{63}` atoms (= :math:`9.223 \cdot 10^{18}`)
- :math:`2^{63}` atoms (= :math:`9.223 \cdot 10^{18}`)
- :math:`2^{31}` atoms (= :math:`2.147 \cdot 10^9`)
* - Total timesteps
- :math:`2^{63}` steps (= :math:`9.223 \cdot 10^{18}`)
- :math:`2^{63}` steps (= :math:`9.223 \cdot 10^{18}`)
- :math:`2^{31}` steps (= :math:`2.147 \cdot 10^9`)
* - Atom ID values
- :math:`1 \le i \le 2^{31} (= 2.147 \cdot 10^9)`
- :math:`1 \le i \le 2^{63} (= 9.223 \cdot 10^{18})`
- :math:`1 \le i \le 2^{31} (= 2.147 \cdot 10^9)`
* - Image flag values
- :math:`-512 \le i \le 511`
- :math:`- 1\,048\,576 \le i \le 1\,048\,575`
- :math:`-512 \le i \le 511`
The "bigbig" setting increases the size of image flags and atom IDs over
"smallbig" and the "smallsmall" setting is only needed if your machine
does not support 64-bit integers or incurs performance penalties when
using them.
the default "smallbig" setting.
These are limits for the core of the LAMMPS code, specific features or
some styles may impose additional limits. The :ref:`ATC
@ -504,8 +509,8 @@ during a run.
.. _libcurl:
Support for downloading files
-----------------------------
Support for downloading files from the input
--------------------------------------------
.. versionadded:: 29Aug2024
@ -548,6 +553,25 @@ LAMMPS is compiled accordingly which needs the following settings:
----------
.. _download_pot:
Prevent download of large potential files
-----------------------------------------
.. versionadded:: 8Feb2023
LAMMPS bundles a selection of potential files in the ``potentials``
folder as examples of how those kinds of potential files look like and
for use with the provided input examples in the ``examples`` tree. To
keep the size of the distributed LAMMPS source package small, very large
potential files (> 5 MBytes) are not bundled, but only downloaded on
demand when the :doc:`corresponding package <Packages_list>` is
installed. This automatic download can be prevented when :doc:`building
LAMMPS with CMake <Build_cmake>` by adding the setting `-D
DOWNLOAD_POTENTIALS=off` when configuring.
----------
.. _align:
Memory allocation alignment
@ -634,40 +658,3 @@ code has to be set up to *catch* exceptions thrown from within LAMMPS.
throw an exception and thus other MPI ranks may get stuck waiting for
messages from the ones with errors.
----------
.. _trap_fpe:
Trigger selected floating-point exceptions
------------------------------------------
Many kinds of CPUs have the capability to detect when a calculation
results in an invalid math operation, like a division by zero or calling
the square root with a negative argument. The default behavior on
most operating systems is to continue and have values for ``NaN`` (= not
a number) or ``Inf`` (= infinity). This allows software to detect and
recover from such conditions. This behavior can be changed, however,
often through use of compiler flags. On Linux systems (or more general
on systems using the GNU C library), these so-called floating-point traps
can also be selectively enabled through library calls. LAMMPS supports
that by setting the ``-DLAMMPS_TRAP_FPE`` pre-processor define. As it is
done in the ``main()`` function, this applies only to the standalone
executable, not the library.
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D CMAKE_TUNE_FLAGS=-DLAMMPS_TRAP_FPE
.. tab:: Traditional make
.. code-block:: make
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
function argument or other invalid floating point operation is encountered.

6
doc/src/Build_windows.rst
View File

@ -100,9 +100,9 @@ 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.
cmake.org) to create build files and compile LAMMPS from the command-line.
Compilation via command line and unit tests are checked automatically
Compilation via command-line and unit tests are checked automatically
for the LAMMPS development branch through
`GitHub Actions <https://github.com/lammps/lammps/actions/workflows/compile-msvc.yml>`_.
@ -115,7 +115,7 @@ for the LAMMPS development branch through
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
the commands for building and testing LAMMPS must be adjusted
accordingly.
The LAMMPS cmake folder contains a ``CMakeSettings.json`` file with

2
doc/src/Classes_lammps.rst
View File

@ -4,7 +4,7 @@ LAMMPS Class
The LAMMPS class is encapsulating an MD simulation state and thus it is
the class that needs to be created when starting a new simulation system
state. The LAMMPS executable essentially creates one instance of this
class and passes the command line flags and tells it to process the
class and passes the command-line flags and tells it to process the
provided input (a file or ``stdin``). It shuts the class down when
control is returned to it and then exits. When using LAMMPS as a
library from another code it is required to create an instance of this

1
doc/src/Commands_all.rst
View File

@ -140,6 +140,7 @@ additional letter in parenthesis: k = KOKKOS.
* :doc:`plugin <plugin>`
* :doc:`prd <prd>`
* :doc:`python <python>`
* :doc:`region2vmd <region2vmd>`
* :doc:`tad <tad>`
* :doc:`temper <temper>`
* :doc:`temper/grem <temper_grem>`

4
doc/src/Commands_bond.rst
View File

@ -23,6 +23,7 @@ OPT.
*
* :doc:`bpm/rotational <bond_bpm_rotational>`
* :doc:`bpm/spring <bond_bpm_spring>`
* :doc:`bpm/spring/plastic <bond_bpm_spring_plastic>`
* :doc:`class2 (ko) <bond_class2>`
* :doc:`fene (iko) <bond_fene>`
* :doc:`fene/expand (o) <bond_fene_expand>`
@ -90,6 +91,7 @@ OPT.
* :doc:`lepton (o) <angle_lepton>`
* :doc:`mesocnt <angle_mesocnt>`
* :doc:`mm3 <angle_mm3>`
* :doc:`mwlc <angle_mwlc>`
* :doc:`quartic (o) <angle_quartic>`
* :doc:`spica (ko) <angle_spica>`
* :doc:`table (o) <angle_table>`
@ -126,7 +128,7 @@ OPT.
* :doc:`harmonic (iko) <dihedral_harmonic>`
* :doc:`helix (o) <dihedral_helix>`
* :doc:`lepton (o) <dihedral_lepton>`
* :doc:`multi/harmonic (o) <dihedral_multi_harmonic>`
* :doc:`multi/harmonic (ko) <dihedral_multi_harmonic>`
* :doc:`nharmonic (o) <dihedral_nharmonic>`
* :doc:`opls (iko) <dihedral_opls>`
* :doc:`quadratic (o) <dihedral_quadratic>`

6
doc/src/Commands_compute.rst
View File

@ -58,6 +58,7 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`fep/ta <compute_fep_ta>`
* :doc:`force/tally <compute_tally>`
* :doc:`fragment/atom <compute_cluster_atom>`
* :doc:`gaussian/grid/local (k) <compute_gaussian_grid_local>`
* :doc:`global/atom <compute_global_atom>`
* :doc:`group/group <compute_group_group>`
* :doc:`gyration <compute_gyration>`
@ -140,8 +141,8 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`smd/vol <compute_smd_vol>`
* :doc:`snap <compute_sna_atom>`
* :doc:`sna/atom <compute_sna_atom>`
* :doc:`sna/grid <compute_sna_atom>`
* :doc:`sna/grid/local <compute_sna_atom>`
* :doc:`sna/grid (k) <compute_sna_atom>`
* :doc:`sna/grid/local (k) <compute_sna_atom>`
* :doc:`snad/atom <compute_sna_atom>`
* :doc:`snav/atom <compute_sna_atom>`
* :doc:`sph/e/atom <compute_sph_e_atom>`
@ -177,6 +178,7 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`ti <compute_ti>`
* :doc:`torque/chunk <compute_torque_chunk>`
* :doc:`vacf <compute_vacf>`
* :doc:`vacf/chunk <compute_vacf_chunk>`
* :doc:`vcm/chunk <compute_vcm_chunk>`
* :doc:`viscosity/cos <compute_viscosity_cos>`
* :doc:`voronoi/atom <compute_voronoi_atom>`

1
doc/src/Commands_dump.rst
View File

@ -19,6 +19,7 @@ An alphabetic list of all LAMMPS :doc:`dump <dump>` commands.
* :doc:`custom/gz <dump>`
* :doc:`custom/zstd <dump>`
* :doc:`dcd <dump>`
* :doc:`extxyz <dump>`
* :doc:`grid <dump>`
* :doc:`grid/vtk <dump>`
* :doc:`h5md <dump_h5md>`

17
doc/src/Commands_fix.rst
View File

@ -29,6 +29,7 @@ OPT.
* :doc:`ave/grid <fix_ave_grid>`
* :doc:`ave/histo <fix_ave_histo>`
* :doc:`ave/histo/weight <fix_ave_histo>`
* :doc:`ave/moments <fix_ave_moments>`
* :doc:`ave/time <fix_ave_time>`
* :doc:`aveforce <fix_aveforce>`
* :doc:`balance <fix_balance>`
@ -43,7 +44,7 @@ OPT.
* :doc:`brownian/asphere <fix_brownian>`
* :doc:`brownian/sphere <fix_brownian>`
* :doc:`charge/regulation <fix_charge_regulation>`
* :doc:`cmap <fix_cmap>`
* :doc:`cmap (k) <fix_cmap>`
* :doc:`colvars <fix_colvars>`
* :doc:`controller <fix_controller>`
* :doc:`damping/cundall <fix_damping_cundall>`
@ -58,6 +59,7 @@ OPT.
* :doc:`dt/reset (k) <fix_dt_reset>`
* :doc:`edpd/source <fix_dpd_source>`
* :doc:`efield (k) <fix_efield>`
* :doc:`efield/lepton <fix_efield_lepton>`
* :doc:`efield/tip4p <fix_efield>`
* :doc:`ehex <fix_ehex>`
* :doc:`electrode/conp (i) <fix_electrode>`
@ -76,6 +78,7 @@ OPT.
* :doc:`flow/gauss <fix_flow_gauss>`
* :doc:`freeze (k) <fix_freeze>`
* :doc:`gcmc <fix_gcmc>`
* :doc:`gjf <fix_gjf>`
* :doc:`gld <fix_gld>`
* :doc:`gle <fix_gle>`
* :doc:`gravity (ko) <fix_gravity>`
@ -134,7 +137,7 @@ OPT.
* :doc:`nve/dot <fix_nve_dot>`
* :doc:`nve/dotc/langevin <fix_nve_dotc_langevin>`
* :doc:`nve/eff <fix_nve_eff>`
* :doc:`nve/limit <fix_nve_limit>`
* :doc:`nve/limit (k) <fix_nve_limit>`
* :doc:`nve/line <fix_nve_line>`
* :doc:`nve/manifold/rattle <fix_nve_manifold_rattle>`
* :doc:`nve/noforce <fix_nve_noforce>`
@ -161,6 +164,8 @@ OPT.
* :doc:`phonon <fix_phonon>`
* :doc:`pimd/langevin <fix_pimd>`
* :doc:`pimd/nvt <fix_pimd>`
* :doc:`pimd/langevin/bosonic <fix_pimd>`
* :doc:`pimd/nvt/bosonic <fix_pimd>`
* :doc:`planeforce <fix_planeforce>`
* :doc:`plumed <fix_plumed>`
* :doc:`poems <fix_poems>`
@ -178,18 +183,21 @@ OPT.
* :doc:`python/move <fix_python_move>`
* :doc:`qbmsst <fix_qbmsst>`
* :doc:`qeq/comb (o) <fix_qeq_comb>`
* :doc:`qeq/ctip <fix_qeq>`
* :doc:`qeq/dynamic <fix_qeq>`
* :doc:`qeq/fire <fix_qeq>`
* :doc:`qeq/point <fix_qeq>`
* :doc:`qeq/reaxff (ko) <fix_qeq_reaxff>`
* :doc:`qeq/rel/reaxff <fix_qeq_rel_reaxff>`
* :doc:`qeq/shielded <fix_qeq>`
* :doc:`qeq/slater <fix_qeq>`
* :doc:`qmmm <fix_qmmm>`
* :doc:`qtb <fix_qtb>`
* :doc:`qtpie/reaxff <fix_qtpie_reaxff>`
* :doc:`rattle <fix_shake>`
* :doc:`reaxff/bonds (k) <fix_reaxff_bonds>`
* :doc:`reaxff/species (k) <fix_reaxff_species>`
* :doc:`recenter <fix_recenter>`
* :doc:`recenter (k) <fix_recenter>`
* :doc:`restrain <fix_restrain>`
* :doc:`rheo <fix_rheo>`
* :doc:`rheo/oxidation <fix_rheo_oxidation>`
@ -210,6 +218,7 @@ OPT.
* :doc:`rigid/small (o) <fix_rigid>`
* :doc:`rx (k) <fix_rx>`
* :doc:`saed/vtk <fix_saed_vtk>`
* :doc:`set <fix_set>`
* :doc:`setforce (k) <fix_setforce>`
* :doc:`setforce/spin <fix_setforce>`
* :doc:`sgcmc <fix_sgcmc>`
@ -267,7 +276,7 @@ OPT.
* :doc:`wall/piston <fix_wall_piston>`
* :doc:`wall/reflect (k) <fix_wall_reflect>`
* :doc:`wall/reflect/stochastic <fix_wall_reflect_stochastic>`
* :doc:`wall/region <fix_wall_region>`
* :doc:`wall/region (k) <fix_wall_region>`
* :doc:`wall/region/ees <fix_wall_ees>`
* :doc:`wall/srd <fix_wall_srd>`
* :doc:`wall/table <fix_wall>`

2
doc/src/Commands_input.rst
View File

@ -69,7 +69,7 @@ WARNING message is printed. The :doc:`Errors <Errors>` page gives
more information on what errors mean. The documentation for each
command lists restrictions on how the command can be used.
You can use the :ref:`-skiprun <skiprun>` command line flag
You can use the :ref:`-skiprun <skiprun>` command-line flag
to have LAMMPS skip the execution of any ``run``, ``minimize``, or similar
commands to check the entire input for correct syntax to avoid crashes
on typos or syntax errors in long runs.

2
doc/src/Commands_kspace.rst
View File

@ -31,3 +31,5 @@ OPT.
* :doc:`pppm/dielectric <kspace_style>`
* :doc:`pppm/electrode (i) <kspace_style>`
* :doc:`scafacos <kspace_style>`
* :doc:`zero <kspace_style>`

7
doc/src/Commands_pair.rst
View File

@ -44,7 +44,7 @@ OPT.
* :doc:`born/coul/wolf/cs (g) <pair_cs>`
* :doc:`born/gauss <pair_born_gauss>`
* :doc:`bpm/spring <pair_bpm_spring>`
* :doc:`brownian (o) <pair_brownian>`
* :doc:`brownian (ko) <pair_brownian>`
* :doc:`brownian/poly (o) <pair_brownian>`
* :doc:`buck (giko) <pair_buck>`
* :doc:`buck/coul/cut (giko) <pair_buck>`
@ -59,6 +59,7 @@ OPT.
* :doc:`comb (o) <pair_comb>`
* :doc:`comb3 <pair_comb>`
* :doc:`cosine/squared <pair_cosine_squared>`
* :doc:`coul/ctip <pair_coul>`
* :doc:`coul/cut (gko) <pair_coul>`
* :doc:`coul/cut/dielectric <pair_dielectric>`
* :doc:`coul/cut/global (o) <pair_coul>`
@ -79,6 +80,7 @@ OPT.
* :doc:`coul/tt <pair_coul_tt>`
* :doc:`coul/wolf (ko) <pair_coul>`
* :doc:`coul/wolf/cs <pair_cs>`
* :doc:`dispersion/d3 <pair_dispersion_d3>`
* :doc:`dpd (giko) <pair_dpd>`
* :doc:`dpd/coul/slater/long (g) <pair_dpd_coul_slater_long>`
* :doc:`dpd/ext (ko) <pair_dpd_ext>`
@ -113,7 +115,9 @@ OPT.
* :doc:`gw/zbl <pair_gw>`
* :doc:`harmonic/cut (o) <pair_harmonic_cut>`
* :doc:`hbond/dreiding/lj (o) <pair_hbond_dreiding>`
* :doc:`hbond/dreiding/lj/angleoffset (o) <pair_hbond_dreiding>`
* :doc:`hbond/dreiding/morse (o) <pair_hbond_dreiding>`
* :doc:`hbond/dreiding/morse/angleoffset (o) <pair_hbond_dreiding>`
* :doc:`hdnnp <pair_hdnnp>`
* :doc:`hippo (g) <pair_amoeba>`
* :doc:`ilp/graphene/hbn (t) <pair_ilp_graphene_hbn>`
@ -175,6 +179,7 @@ OPT.
* :doc:`lj/long/dipole/long <pair_dipole>`
* :doc:`lj/long/tip4p/long (o) <pair_lj_long>`
* :doc:`lj/mdf <pair_mdf>`
* :doc:`lj/pirani (o) <pair_lj_pirani>`
* :doc:`lj/relres (o) <pair_lj_relres>`
* :doc:`lj/spica (gko) <pair_spica>`
* :doc:`lj/spica/coul/long (gko) <pair_spica>`

231
doc/src/Commands_removed.rst
View File

@ -1,6 +1,10 @@
Removed commands and packages
=============================
.. contents::
------
This page lists LAMMPS commands and packages that have been removed from
the distribution and provides suggestions for alternatives or
replacements. LAMMPS has special dummy styles implemented, that will
@ -8,94 +12,43 @@ stop LAMMPS and print a suitable error message in most cases, when a
style/command is used that has been removed or will replace the command
with the direct alternative (if available) and print a warning.
restart2data tool
-----------------
GJF formulation in fix langevin
-------------------------------
.. versionchanged:: 23Nov2013
.. deprecated:: 12Jun2025
The functionality of the restart2data tool has been folded into the
LAMMPS executable directly instead of having a separate tool. A
combination of the commands :doc:`read_restart <read_restart>` and
:doc:`write_data <write_data>` can be used to the same effect. For
added convenience this conversion can also be triggered by
:doc:`command line flags <Run_options>`
The *gjf* keyword in fix langevin is deprecated and will be removed
soon. The GJF functionality has been moved to its own fix style
:doc:`fix gjf <fix_gjf>` and it is strongly recommended to use that
fix instead.
Fix ave/spatial and fix ave/spatial/sphere
------------------------------------------
.. deprecated:: 11Dec2015
The fixes ave/spatial and ave/spatial/sphere have been removed from LAMMPS
since they were superseded by the more general and extensible "chunk
infrastructure". Here the system is partitioned in one of many possible
ways through the :doc:`compute chunk/atom <compute_chunk_atom>` command
and then averaging is done using :doc:`fix ave/chunk <fix_ave_chunk>`.
Please refer to the :doc:`chunk HOWTO <Howto_chunk>` section for an overview.
Box command
-----------
.. deprecated:: 22Dec2022
The *box* command has been removed and the LAMMPS code changed so it won't
be needed. If present, LAMMPS will ignore the command and print a warning.
Reset_ids, reset_atom_ids, reset_mol_ids commands
-------------------------------------------------
.. deprecated:: 22Dec2022
The *reset_ids*, *reset_atom_ids*, and *reset_mol_ids* commands have
been folded into the :doc:`reset_atoms <reset_atoms>` command. If
present, LAMMPS will replace the commands accordingly and print a
warning.
LATTE package
-------------
.. deprecated:: 15Jun2023
The LATTE package with the fix latte command was removed from LAMMPS.
This functionality has been superseded by :doc:`fix mdi/qm <fix_mdi_qm>`
and :doc:`fix mdi/qmmm <fix_mdi_qmmm>` from the :ref:`MDI package
<PKG-MDI>`. These fixes are compatible with several quantum software
packages, including LATTE. See the ``examples/QUANTUM`` dir and the
:doc:`MDI coupling HOWTO <Howto_mdi>` page. MDI supports running LAMMPS
with LATTE as a plugin library (similar to the way fix latte worked), as
well as on a different set of MPI processors.
MEAM package
LAMMPS shell
------------
The MEAM package in Fortran has been replaced by a C++ implementation.
The code in the :ref:`MEAM package <PKG-MEAM>` is a translation of the
Fortran code of MEAM into C++, which removes several restrictions
(e.g. there can be multiple instances in hybrid pair styles) and allows
for some optimizations leading to better performance. The pair style
:doc:`meam <pair_meam>` has the exact same syntax. For a transition
period the C++ version of MEAM was called USER-MEAMC so it could
coexist with the Fortran version.
.. deprecated:: 29Aug2024
Minimize style fire/old
-----------------------
The LAMMPS shell has been removed from the LAMMPS distribution. Users
are encouraged to use the :ref:`LAMMPS-GUI <lammps_gui>` tool instead.
.. deprecated:: 8Feb2023
i-PI tool
---------
Minimize style *fire/old* has been removed. Its functionality can be
reproduced with *fire* with specific options. Please see the
:doc:`min_modify command <min_modify>` documentation for details.
.. deprecated:: 27Jun2024
Pair style mesont/tpm, compute style mesont, atom style mesont
--------------------------------------------------------------
The i-PI tool has been removed from the LAMMPS distribution. Instead,
instructions to install i-PI from PyPI via pip are provided.
.. deprecated:: 8Feb2023
USER-REAXC package
------------------
Pair style *mesont/tpm*, compute style *mesont*, and atom style
*mesont* have been removed from the :ref:`MESONT package <PKG-MESONT>`.
The same functionality is available through
:doc:`pair style mesocnt <pair_mesocnt>`,
:doc:`bond style mesocnt <bond_mesocnt>` and
:doc:`angle style mesocnt <angle_mesocnt>`.
.. deprecated:: 7Feb2024
The USER-REAXC package has been renamed to :ref:`REAXFF <PKG-REAXFF>`.
In the process also the pair style and related fixes were renamed to use
the "reaxff" string instead of "reax/c". For a while LAMMPS was maintaining
backward compatibility by providing aliases for the styles. These have
been removed, so using "reaxff" is now *required*.
MPIIO package
-------------
@ -115,7 +68,6 @@ Similarly, the "nfile" and "fileper" keywords exist for restarts:
see :doc:`restart <restart>`, :doc:`read_restart <read_restart>`,
:doc:`write_restart <write_restart>`.
MSCG package
------------
@ -126,9 +78,73 @@ for many years and instead superseded by the `OpenMSCG software
<https://software.rcc.uchicago.edu/mscg/>`_ of the Voth group at the
University of Chicago, which can be used independent from LAMMPS.
LATTE package
-------------
.. deprecated:: 15Jun2023
The LATTE package with the fix latte command was removed from LAMMPS.
This functionality has been superseded by :doc:`fix mdi/qm <fix_mdi_qm>`
and :doc:`fix mdi/qmmm <fix_mdi_qmmm>` from the :ref:`MDI package
<PKG-MDI>`. These fixes are compatible with several quantum software
packages, including LATTE. See the ``examples/QUANTUM`` dir and the
:doc:`MDI coupling HOWTO <Howto_mdi>` page. MDI supports running LAMMPS
with LATTE as a plugin library (similar to the way fix latte worked), as
well as on a different set of MPI processors.
Minimize style fire/old
-----------------------
.. deprecated:: 8Feb2023
Minimize style *fire/old* has been removed. Its functionality can be
reproduced with style *fire* with specific options. Please see the
:doc:`min_modify command <min_modify>` documentation for details.
Pair style mesont/tpm, compute style mesont, atom style mesont
--------------------------------------------------------------
.. deprecated:: 8Feb2023
Pair style *mesont/tpm*, compute style *mesont*, and atom style
*mesont* have been removed from the :ref:`MESONT package <PKG-MESONT>`.
The same functionality is available through
:doc:`pair style mesocnt <pair_mesocnt>`,
:doc:`bond style mesocnt <bond_mesocnt>` and
:doc:`angle style mesocnt <angle_mesocnt>`.
Box command
-----------
.. deprecated:: 22Dec2022
The *box* command has been removed and the LAMMPS code changed so it won't
be needed. If present, LAMMPS will ignore the command and print a warning.
Reset_ids, reset_atom_ids, reset_mol_ids commands
-------------------------------------------------
.. deprecated:: 22Dec2022
The *reset_ids*, *reset_atom_ids*, and *reset_mol_ids* commands have
been folded into the :doc:`reset_atoms <reset_atoms>` command. If
present, LAMMPS will replace the commands accordingly and print a
warning.
MESSAGE package
---------------
.. deprecated:: 4May2022
The MESSAGE package has been removed since it was superseded by the
:ref:`MDI package <PKG-MDI>`. MDI implements the same functionality
and in a more general way with direct support for more applications.
REAX package
------------
.. deprecated:: 4Jan2019
The REAX package has been removed since it was superseded by the
:ref:`REAXFF package <PKG-REAXFF>`. The REAXFF package has been tested
to yield equivalent results to the REAX package, offers better
@ -138,20 +154,25 @@ syntax compatible with the removed reax pair style, so input files will
have to be adapted. The REAXFF package was originally called
USER-REAXC.
USER-REAXC package
------------------
MEAM package
------------
.. deprecated:: 7Feb2024
.. deprecated:: 4Jan2019
The USER-REAXC package has been renamed to :ref:`REAXFF <PKG-REAXFF>`.
In the process also the pair style and related fixes were renamed to use
the "reaxff" string instead of "reax/c". For a while LAMMPS was maintaining
backward compatibility by providing aliases for the styles. These have
been removed, so using "reaxff" is now *required*.
The MEAM package in Fortran has been replaced by a C++ implementation.
The code in the :ref:`MEAM package <PKG-MEAM>` is a translation of the
Fortran code of MEAM into C++, which removes several restrictions
(e.g. there can be multiple instances in hybrid pair styles) and allows
for some optimizations leading to better performance. The pair style
:doc:`meam <pair_meam>` has the exact same syntax. For a transition
period the C++ version of MEAM was called USER-MEAMC so it could
coexist with the Fortran version.
USER-CUDA package
-----------------
.. deprecated:: 31May2016
The USER-CUDA package had been removed, since it had been unmaintained
for a long time and had known bugs and problems. Significant parts of
the design were transferred to the
@ -160,19 +181,39 @@ performance characteristics on NVIDIA GPUs. Both, the KOKKOS
and the :ref:`GPU package <PKG-GPU>` are maintained
and allow running LAMMPS with GPU acceleration.
i-PI tool
---------
Compute atom/molecule
---------------------
.. versionchanged:: 27Jun2024
.. deprecated:: 11 Dec2015
The i-PI tool has been removed from the LAMMPS distribution. Instead,
instructions to install i-PI from PyPI via pip are provided.
The atom/molecule command has been removed from LAMMPS since it was superseded
by the more general and extensible "chunk infrastructure". Here the system is
partitioned in one of many possible ways - including using molecule IDs -
through the :doc:`compute chunk/atom <compute_chunk_atom>` command and then
summing is done using :doc:`compute reduce/chunk <compute_reduce_chunk>` Please
refer to the :doc:`chunk HOWTO <Howto_chunk>` section for an overview.
LAMMPS shell
------------
Fix ave/spatial and fix ave/spatial/sphere
------------------------------------------
.. versionchanged:: 29Aug2024
.. deprecated:: 11Dec2015
The LAMMPS shell has been removed from the LAMMPS distribution. Users
are encouraged to use the :ref:`LAMMPS-GUI <lammps_gui>` tool instead.
The fixes ave/spatial and ave/spatial/sphere have been removed from LAMMPS
since they were superseded by the more general and extensible "chunk
infrastructure". Here the system is partitioned in one of many possible
ways through the :doc:`compute chunk/atom <compute_chunk_atom>` command
and then averaging is done using :doc:`fix ave/chunk <fix_ave_chunk>`.
Please refer to the :doc:`chunk HOWTO <Howto_chunk>` section for an overview.
restart2data tool
-----------------
.. deprecated:: 23Nov2013
The functionality of the restart2data tool has been folded into the
LAMMPS executable directly instead of having a separate tool. A
combination of the commands :doc:`read_restart <read_restart>` and
:doc:`write_data <write_data>` can be used to the same effect. For
added convenience this conversion can also be triggered by
:doc:`command-line flags <Run_options>`

1
doc/src/Developer.rst
View File

@ -24,4 +24,5 @@ of time and requests from the LAMMPS user community.
Classes
Developer_platform
Developer_utils
Developer_internal
Developer_grid

41
doc/src/Developer_code_design.rst
View File

@ -203,6 +203,7 @@ processed in the expected order before types are removed from dynamic
dispatch.
.. admonition:: Important Notes
:class: note
In order to be able to detect incompatibilities at compile time and
to avoid unexpected behavior, it is crucial that all member functions
@ -300,18 +301,24 @@ 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
"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.
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 as ``std::format()``, so changes to adopt it are
future-proof, for as long as they are not using any extensions that are
not (yet) included into C++.
The long-term plan is to switch to using ``std::format()`` instead of
``fmt::format()`` when the minimum C++ standard required for LAMMPS will
be set to C++20. See the :ref:`basic build instructions <compile>` for
more details.
Formatted strings are frequently created by calling the
``fmt::format()`` function, which will return a string as a
@ -319,11 +326,13 @@ Formatted strings are frequently created by calling the
``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()``).
Otherwise, the :cpp:func:`utils::print() <LAMMPS_NS::utils::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()``, :cpp:func:`utils::logmesg()
<LAMMPS_NS::utils::logmesg>`).
Summary of the {fmt} format syntax
==================================

16
doc/src/Developer_comm_ops.rst
View File

@ -79,19 +79,19 @@ containing ``double`` values. To correctly store integers that may be
64-bit (bigint, tagint, imageint) in the buffer, you need to use the
:ref:`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
The *Fix*, *Bond*, *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.
*Fix*, *Bond*, *Compute*, or *Dump* class.
For *Fix* classes, there is an optional second argument to the
For all of these 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
class performs multiple modes of communication, with different numbers
of values per atom. The class 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
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.

2
doc/src/Developer_flow.rst
View File

@ -209,7 +209,7 @@ nve, nvt, npt.
At the end of the timestep, fixes that contain an ``end_of_step()``
method are invoked. These typically perform a diagnostic calculation,
e.g. the ave/time and ave/spatial fixes. The final operation of the
e.g. the ave/time and ave/chunk fixes. The final operation of the
timestep is to perform any requested output, via the ``write()`` method
of the Output class. There are 3 kinds of LAMMPS output: thermodynamic
output to the screen and log file, snapshots of atom data to a dump

120
doc/src/Developer_internal.rst Normal file
View File

@ -0,0 +1,120 @@
Internal Styles
---------------
LAMMPS has a number of styles that are not meant to be used in an input
file and thus are not documented in the :doc:`LAMMPS command
documentation <Commands_all>`. The differentiation between user
commands and internal commands is through the case of the command name:
user commands and styles are all lower case, internal styles are all
upper case. Internal styles are not called from the input file, but
their classes are instantiated by other styles. Often they are
created by other styles to store internal data or to perform actions
regularly at specific steps of the simulation.
The paragraphs below document some of those styles that have general
utility and may be used to avoid redundant implementation.
DEPRECATED Styles
^^^^^^^^^^^^^^^^^
The styles called DEPRECATED (e.g. pair, bond, fix, compute, region, etc.)
have the purpose to inform users that a specific style has been removed
or renamed. This is achieved by creating an alias for the deprecated
style to the corresponding class. For example, the fix style DEPRECATED
is aliased to fix style ave/spatial and fix style ave/spatial/sphere with
the following code:
.. code-block:: c++
FixStyle(DEPRECATED,FixDeprecated);
FixStyle(ave/spatial,FixDeprecated);
FixStyle(ave/spatial/sphere,FixDeprecated);
The individual class will then determine based on the style name
what action to perform:
- inform that the style has been removed and what style replaces it, if any, and then error out
- inform that the style has been renamed and then either execute the replacement or error out
- inform that the style is no longer required, and it is thus ignored and continue
There is also a section in the user's guide for :doc:`removed commands
and packages <Commands_removed>` with additional explanations.
Internal fix styles
^^^^^^^^^^^^^^^^^^^
These provide an implementation of features that would otherwise have
been replicated across multiple styles. The used fix ID is generally
derived from the compute or fix ID creating the fix with some string
appended. When needed, the fix can be looked up with
``Modify::get_fix_by_id()``, which returns a pointer to the fix
instance. The data managed by the fix can be accessed just as for other
fixes that can be used in input files.
fix DUMMY
"""""""""
Most fix classes cannot be instantiated before the simulation box has
been created since they access data that is only available then.
However, in some cases it is required that a fix must be at or close to
the top of the list of all fixes. In those cases an instance of the
DUMMY fix style may be created by calling ``Modify::add_fix()`` and then
later replaced by the intended fix through calling ``Modify::replace_fix()``.
fix STORE/ATOM
""""""""""""""
Fix STORE/ATOM can be used as persistent storage of per-atom data.
**Syntax**
.. code-block:: LAMMPS
fix ID group-ID STORE/ATOM N1 N2 gflag rflag
* ID, group-ID are documented in :doc:`fix <fix>` command
* STORE/ATOM = style name of this fix command
* N1 = 1, N2 = 0 : data is per-atom vector = single value per atom
* N1 > 1, N2 = 0 : data is per-atom array = N1 values per atom
* N1 > 0, N2 > 0 : data is per-atom tensor = N1xN2 values per atom
* gflag = 1 communicate per-atom values with ghost atoms, 0 do not update ghost atom data
* rflag = 1 store per-atom value in restart file, 0 do not store data in restart
Similar functionality is also available through using custom per-atom
properties with :doc:`fix property/atom <fix_property_atom>`. The
choice between the two fixes should be based on whether the user should
be able to access this per-atom data: if yes, then fix property/atom is
preferred, otherwise fix STORE/ATOM.
fix STORE/GLOBAL
""""""""""""""""
Fix STORE/GLOBAL can be used as persistent storage of global data with support for restarts
**Syntax**
.. code-block:: LAMMPS
fix ID group-ID STORE/GLOBAL N1 N2
* ID, group-ID are documented in :doc:`fix <fix>` command
* STORE/GLOBAL = style name of this fix command
* N1 >=1 : number of global items to store
* N2 = 1 : data is global vector of length N1
* N2 > 1 : data is global N1xN2 array
fix STORE/LOCAL
"""""""""""""""
Fix STORE/LOCAL can be used as persistent storage for local data
**Syntax**
.. code-block:: LAMMPS
fix ID group-ID STORE/LOCAL Nreset Nvalues
* ID, group-ID are documented in :doc:`fix <fix>` command
* STORE/LOCAL = style name of this fix command
* Nreset = frequency at which local data is available
* Nvalues = number of values per local item, that is the number of columns

151
doc/src/Developer_notes.rst
View File

@ -7,13 +7,7 @@ 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`_
- `Choosing between a custom atom style, fix property/atom, and fix STORE/ATOM`_
- `Fix contributions to instantaneous energy, virial, and cumulative energy`_
- `KSpace PPPM FFT grids`_
.. contents:: Available notes
----
@ -218,6 +212,149 @@ command:
neighbor->add_request(this, "delete_atoms", NeighConst::REQ_FULL);
Errors, warnings, and informational messages
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
LAMMPS has specialized functionality to handle errors (which should
terminate LAMMPS), warning messages (which should indicate possible
problems *without* terminating LAMMPS), and informational text for
messages about the progress and chosen settings. We *strongly*
encourage using these facilities and to *stay away* from using
``printf()`` or ``fprintf()`` or ``std::cout`` or ``std::cerr`` and
calling ``MPI_Abort()`` or ``exit()`` directly. Warnings and
informational messages should be printed only on MPI rank 0 to avoid
flooding the output when running in parallel with many MPI processes.
**Errors**
When LAMMPS encounters an error, for example a syntax error in the
input, then a suitable error message should be printed giving a brief,
one line remark about the reason and then call either ``Error::all()``
or ``Error::one()``. ``Error::all()`` must be called when the failing
code path is executed by *all* MPI processes and the error condition
will appear for *all* MPI processes the same. If desired, each MPI
process may set a flag to either 0 or 1 and then MPI_Allreduce()
searching for the maximum can be used to determine if there was an error
on *any* of the MPI processes and make this information available to
*all*. ``Error::one()`` in contrast needs to be called when only one or
a few MPI processes execute the code path or can have the error
condition. ``Error::all()`` is generally the preferred option.
Calling these functions does not abort LAMMPS directly, but rather
throws either a ``LAMMPSException`` (from ``Error::all()``) or a
``LAMMPSAbortException`` (from ``Error::one()``). These exceptions are
caught by the LAMMPS ``main()`` program and then handled accordingly.
The reason for this approach is to support applications, especially
graphical applications like :ref:`LAMMPS-GUI <lammps_gui>`, that are
linked to the LAMMPS library and have a mechanism to avoid that an error
in LAMMPS terminates the application. By catching the exceptions, the
application can delete the failing LAMMPS class instance and create a
new one to try again. In a similar fashion, the :doc:`LAMMPS Python
module <Python_module>` checks for this and then re-throws corresponding
Python exception, which in turn can be caught by the calling Python
code.
There are multiple "signatures" that can be called:
- ``Error::all(FLERR, "Error message")``: this will abort LAMMPS with
the error message "Error message", followed by the last line of input
that was read and processed before the error condition happened.
- ``Error::all(FLERR, Error::NOLASTLINE, "Error message")``: this is the
same as before but without the last line of input. This is preferred
for errors that would happen *during* a :doc:`run <run>` or
:doc:`minimization <minimize>`, since showing the "run" or "minimize"
command would be the last line, but is unrelated to the error.
- ``Error::all(FLERR, idx, "Error message")``: this is for argument
parsing where "idx" is the index (starting at 0) of the argument for a
LAMMPS command that is causing the failure (use -1 for the command
itself). For index 0, you need to use the constant ``Error::ARGZERO``
to work around the inability of some compilers to disambiguate between
a NULL pointer and an integer constant 0, even with an added type cast.
The output may also include the last input line *before* and
*after*, if they differ due to substituting variables. A textual
indicator is pointing to the specific word that failed. Using the
constant ``Error::NOPOINTER`` in place of the *idx* argument will
suppress the marker and then the behavior is like the *idx* argument
is not provided.
FLERR is a macro containing the filename and line where the Error class
is called and that information is appended to the error message. This
allows to quickly find the relevant source code causing the error. For
all three signatures, the single string "Error message" may be replaced
with a format string using '{}' placeholders and followed by a variable
number of arguments, one for each placeholder. This format string and
the arguments are then handed for formatting to the `{fmt} library
<https://fmt.dev>`_ (which is bundled with LAMMPS) and thus allow
processing similar to the "format()" functionality in Python.
.. note::
For commands like :doc:`fix ave/time <fix_ave_time>` that accept
wildcard arguments, the :cpp:func:`utils::expand_args` function
may be passed as an optional argument where the function will provide
a map to the original arguments from the expanded argument indices.
For complex errors, that can have multiple causes and which cannot be
explained in a single line, you can append to the error message, the
string created by :cpp:func:`utils::errorurl`, which then provides a
URL pointing to a paragraph of the :doc:`Errors_details` that
corresponds to the number provided. Example:
.. code-block:: c++
error->all(FLERR, "Unknown identifier in data file: {}{}", keyword, utils::errorurl(1));
This will output something like this:
.. parsed-literal::
ERROR: Unknown identifier in data file: Massess
For more information see https://docs.lammps.org/err0001 (src/read_data.cpp:1482)
Last input line: read_data data.peptide
Where the URL points to the first paragraph with explanations on
the :doc:`Errors_details` page in the manual.
**Warnings**
To print warnings, the ``Errors::warning()`` function should be used.
It also requires the FLERR macros as first argument to easily identify
the location of the warning in the source code. Same as with the error
functions above, the function has two variants: one just taking a single
string as final argument and a second that uses the `{fmt} library
<https://fmt.dev>`_ to make it similar to, say, ``fprintf()``. One
motivation to use this function is that it will output warnings with
always the same capitalization of the leading "WARNING" string. A
second is that it has a built in rate limiter. After a given number (by
default 100), that can be set via the :doc:`thermo_modify command
<thermo_modify>` no more warnings are printed. Also, warnings are
written consistently to both screen and logfile or not, depending on the
settings for :ref:`screen <screen>` or :doc:`logfile <log>` output.
.. note::
Unlike ``Error::all()``, the warning function will produce output on
*every* MPI process, so it typically would be prefixed with an if
statement testing for ``comm->me == 0``, i.e. limiting output to MPI
rank 0.
**Informational messages**
Finally, for informational message LAMMPS has the
:cpp:func:`utils::logmesg() convenience function
<LAMMPS_NS::utils::logmesg>`. It also uses the `{fmt} library
<https://fmt.dev>`_ to support using a format string followed by a
matching number of arguments. It will output the resulting formatted
text to both, the screen and the logfile and will honor the
corresponding settings about whether this output is active and to which
file it should be send. Same as for ``Error::warning()``, it would
produce output for every MPI process and thus should usually be called
only on MPI rank 0 to avoid flooding the output when running with many
parallel processes.
Choosing between a custom atom style, fix property/atom, and fix STORE/ATOM
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

4
doc/src/Developer_org.rst
View File

@ -94,12 +94,12 @@ represents what is generally referred to as an "instance of LAMMPS". It
is a composite holding pointers to instances of other core classes
providing the core functionality of the MD engine in LAMMPS and through
them abstractions of the required operations. The constructor of the
LAMMPS class will instantiate those instances, process the command line
LAMMPS class will instantiate those instances, process the command-line
flags, initialize MPI (if not already done) and set up file pointers for
input and output. The destructor will shut everything down and free all
associated memory. Thus code for the standalone LAMMPS executable in
``main.cpp`` simply initializes MPI, instantiates a single instance of
LAMMPS while passing it the command line flags and input script. It
LAMMPS while passing it the command-line flags and input script. It
deletes the LAMMPS instance after the method reading the input returns
and shuts down the MPI environment before it exits the executable.

42
doc/src/Developer_plugins.rst
View File

@ -68,24 +68,25 @@ Members of ``lammpsplugin_t``
* - author
- String with the name and email of the author
* - creator.v1
- Pointer to factory function for pair, bond, angle, dihedral, improper, kspace, or command styles
- Pointer to factory function for pair, bond, angle, dihedral, improper, kspace, command, or minimize styles
* - creator.v2
- Pointer to factory function for compute, fix, or region styles
- Pointer to factory function for compute, fix, region, or run styles
* - handle
- Pointer to the open DSO file handle
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.
(i.e. pair, bond, angle, dihedral, or improper styles), command styles,
or minimize 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,
region, or run 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
^^^^^^^^^^^^^^^^^^
@ -247,8 +248,8 @@ DSO handle. The registration function is called with a pointer to the address
of this struct and the pointer of the LAMMPS class. The registration function
will then add the factory function of the plugin style to the respective
style map under the provided name. It will also make a copy of the struct
in a list of all loaded plugins and update the reference counter for loaded
plugins from this specific DSO file.
in a global list of all loaded plugins and update the reference counter for
loaded plugins from this specific DSO file.
The pair style itself (i.e. the PairMorse2 class in this example) can be
written just like any other pair style that is included in LAMMPS. For
@ -263,6 +264,21 @@ 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.
.. versionchanged:: 12Jun2025
When using the :doc:`clear <clear>` command, plugins are not unloaded
but restored to their respective style maps. This also applies when
multiple LAMMPS instances are created and deleted through the library
interface. The :doc:`plugin load <plugin>` load command may be issued
again, but for existing plugins they will be skipped. To replace
plugins they must be explicitly unloaded with :doc:`plugin unload
<plugin>`. When multiple LAMMPS instances are created concurrently, any
loaded plugins will be added to the global list of plugins, but are not
immediately available to any LAMMPS instance that was created before
loading the plugin. To "import" such plugins, the :doc:`plugin restore
<plugin>` may be used. Plugins are only removed when they are explicitly
unloaded or the LAMMPS interface is "finalized".
Compiling plugins
^^^^^^^^^^^^^^^^^

76
doc/src/Developer_unittest.rst
View File

@ -227,12 +227,12 @@ Tests for the C-style library interface
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Tests for validating the LAMMPS C-style library interface are in the
``unittest/c-library`` folder. They are implemented either to be used
for utility functions or for LAMMPS commands, but use the functions
implemented in the ``src/library.cpp`` file as much as possible. There
may be some overlap with other tests, but only in as much as is required
to test the C-style library API. The tests are distributed over
multiple test programs which try to match the grouping of the
``unittest/c-library`` folder. They text either utility functions or
LAMMPS commands, but use the functions implemented in
``src/library.cpp`` as much as possible. There may be some overlap with
other tests as far as the LAMMPS functionality is concerned, but the
focus is on testing the C-style library API. The tests are distributed
over multiple test programs which try to match the grouping of the
functions in the source code and :ref:`in the manual <lammps_c_api>`.
This group of tests also includes tests invoking LAMMPS in parallel
@ -258,7 +258,7 @@ Tests for the Python module and package
The ``unittest/python`` folder contains primarily tests for classes and
functions in the LAMMPS python module but also for commands in the
PYTHON package. These tests are only enabled if the necessary
PYTHON package. These tests are only enabled, if the necessary
prerequisites are detected or enabled during configuration and
compilation of LAMMPS (shared library build enabled, Python interpreter
found, Python development files found).
@ -272,29 +272,30 @@ Tests for the Fortran interface
Tests for using the Fortran module are in the ``unittest/fortran``
folder. Since they are also using the GoogleTest library, they require
implementing test wrappers in C++ that will call fortran functions
which provide a C function interface through ISO_C_BINDINGS that will in
turn call the functions in the LAMMPS Fortran module.
test wrappers written in C++ that will call fortran functions with a C
function interface through ISO_C_BINDINGS which will in turn call the
functions in the LAMMPS Fortran module.
Tests for the C++-style library interface
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The tests in the ``unittest/cplusplus`` folder are somewhat similar to
the tests for the C-style library interface, but do not need to test the
several convenience and utility functions that are only available through
the C-style interface. Instead it can focus on the more generic features
that are used internally. This part of the unit tests is currently still
mostly in the planning stage.
convenience and utility functions that are only available through the
C-style library interface. Instead they focus on the more generic
features that are used in LAMMPS internally. This part of the unit
tests is currently still mostly in the planning stage.
Tests for reading and writing file formats
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The ``unittest/formats`` folder contains test programs for reading and
writing files like data files, restart files, potential files or dump files.
This covers simple things like the file i/o convenience functions in the
``utils::`` namespace to complex tests of atom styles where creating and
deleting atoms with different properties is tested in different ways
and through script commands or reading and writing of data or restart files.
writing files like data files, restart files, potential files or dump
files. This covers simple things like the file i/o convenience
functions in the ``utils::`` namespace to complex tests of atom styles
where creating and deleting of atoms with different properties is tested
in different ways and through script commands or reading and writing of
data or restart files.
Tests for styles computing or modifying forces
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -443,7 +444,7 @@ file for a style that is similar to one to be tested. The file name should
follow the naming conventions described above and after copying the file,
the first step is to replace the style names where needed. The coefficient
values do not have to be meaningful, just in a reasonable range for the
given system. It does not matter if some forces are large, as long as
given system. It does not matter if some forces are large, for as long as
they do not diverge.
The template input files define a large number of index variables at the top
@ -476,7 +477,7 @@ the tabulated coulomb, to test both code paths. The reference results in the YA
files then should be compared manually, if they agree well enough within the limits
of those two approximations.
The ``test_pair_style`` and equivalent programs have special command line options
The ``test_pair_style`` and equivalent programs have special command-line options
to update the YAML files. Running a command like
.. code-block:: bash
@ -531,19 +532,20 @@ Python module.
Troubleshooting failed unit tests
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The are by default no unit tests for newly added features (e.g. pair, fix,
or compute styles) unless your pull request also includes tests for the
added features. If you are modifying some features, you may see failures
for existing tests, if your modifications have some unexpected side effects
or your changes render the existing test invalid. If you are adding an
accelerated version of an existing style, then only tests for INTEL,
KOKKOS (with OpenMP only), OPENMP, and OPT will be run automatically.
Tests for the GPU package are time consuming and thus are only run
*after* a merge, or when a special label, ``gpu_unit_tests`` is added
to the pull request. After the test has started, it is often best to
remove the label since every PR activity will re-trigger the test (that
is a limitation of triggering a test with a label). Support for unit
tests when using KOKKOS with GPU acceleration is currently not supported.
There are by default no unit tests for newly added features (e.g. pair,
fix, or compute styles) unless your pull request also includes tests for
these added features. If you are modifying some existing LAMMPS
features, you may see failures for existing tests, if your modifications
have some unexpected side effects or your changes render the existing
test invalid. If you are adding an accelerated version of an existing
style, then only tests for INTEL, KOKKOS (with OpenMP only), OPENMP, and
OPT will be run automatically. Tests for the GPU package are time
consuming and thus are only run *after* a merge, or when a special
label, ``gpu_unit_tests`` is added to the pull request. After the test
has started, it is often best to remove the label since every PR
activity will re-trigger the test (that is a limitation of triggering a
test with a label). Support for unit tests using KOKKOS with GPU
acceleration is currently not supported.
When you see a failed build on GitHub, click on ``Details`` to be taken
to the corresponding LAMMPS Jenkins CI web page. Click on the "Exit"
@ -588,7 +590,7 @@ While the epsilon (relative precision) for a single, `IEEE 754 compliant
<https://en.wikipedia.org/wiki/IEEE_754>`_, double precision floating
point operation is at about 2.2e-16, the achievable precision for the
tests is lower due to most numbers being sums over intermediate results
and the non-associativity of floating point math leading to larger
for which the non-associativity of floating point math leads to larger
errors. As a rule of thumb, the test epsilon can often be in the range
5.0e-14 to 1.0e-13. But for "noisy" force kernels, e.g. those a larger
amount of arithmetic operations involving `exp()`, `log()` or `sin()`
@ -602,14 +604,14 @@ of floating point operations or that some or most intermediate operations
may be done using approximations or with single precision floating point
math.
To rerun the failed unit test individually, change to the ``build`` directory
To rerun a failed unit test individually, change to the ``build`` directory
and run the test with verbose output. For example,
.. code-block:: bash
env TEST_ARGS=-v ctest -R ^MolPairStyle:lj_cut_coul_long -V
``ctest`` with the ``-V`` flag also shows the exact command line
``ctest`` with the ``-V`` flag also shows the exact command
of the test. One can then use ``gdb --args`` to further debug and
catch exceptions with the test command, for example,

45
doc/src/Developer_updating.rst
View File

@ -29,6 +29,7 @@ Available topics in mostly chronological order are:
- `Rename of fix STORE/PERATOM to fix STORE/ATOM and change of arguments`_
- `Use Output::get_dump_by_id() instead of Output::find_dump()`_
- `Refactored grid communication using Grid3d/Grid2d classes instead of GridComm`_
- `FLERR as first argument to minimum image functions in Domain class`_
----
@ -610,3 +611,47 @@ KSpace solvers which use distributed FFT grids:
- ``src/KSPACE/pppm.cpp``
This change is **required** or else the code will not compile.
FLERR as first argument to minimum image functions in Domain class
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: 12Jun2025
The ``Domain::minimum_image()`` and ``Domain::minimum_image_big()``
functions were changed to take the ``FLERR`` macros as first argument.
This way the error message indicates *where* the function was called
instead of pointing to the implementation of the function. Example:
Old:
.. code-block:: c++
double delx1 = x[i1][0] - x[i2][0];
double dely1 = x[i1][1] - x[i2][1];
double delz1 = x[i1][2] - x[i2][2];
domain->minimum_image(delx1, dely1, delz1);
double r1 = sqrt(delx1 * delx1 + dely1 * dely1 + delz1 * delz1);
double delx2 = x[i3][0] - x[i2][0];
double dely2 = x[i3][1] - x[i2][1];
double delz2 = x[i3][2] - x[i2][2];
domain->minimum_image_big(delx2, dely2, delz2);
double r2 = sqrt(delx2 * delx2 + dely2 * dely2 + delz2 * delz2);
New:
.. code-block:: c++
double delx1 = x[i1][0] - x[i2][0];
double dely1 = x[i1][1] - x[i2][1];
double delz1 = x[i1][2] - x[i2][2];
domain->minimum_image(FLERR, delx1, dely1, delz1);
double r1 = sqrt(delx1 * delx1 + dely1 * dely1 + delz1 * delz1);
double delx2 = x[i3][0] - x[i2][0];
double dely2 = x[i3][1] - x[i2][1];
double delz2 = x[i3][2] - x[i2][2];
domain->minimum_image_big(FLERR, delx2, dely2, delz2);
double r2 = sqrt(delx2 * delx2 + dely2 * dely2 + delz2 * delz2);
This change is **required** or else the code will not compile.

15
doc/src/Developer_utils.rst
View File

@ -133,6 +133,9 @@ and parsing files or arguments.
.. doxygenfunction:: trim_comment
:project: progguide
.. doxygenfunction:: strcompress
:project: progguide
.. doxygenfunction:: strip_style_suffix
:project: progguide
@ -166,6 +169,9 @@ and parsing files or arguments.
.. doxygenfunction:: split_lines
:project: progguide
.. doxygenfunction:: strsame
:project: progguide
.. doxygenfunction:: strmatch
:project: progguide
@ -232,12 +238,21 @@ Convenience functions
.. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &mesg)
:project: progguide
.. doxygenfunction:: print(FILE *fp, const std::string &format, Args&&... args)
:project: progguide
.. doxygenfunction:: print(FILE *fp, const std::string &mesg)
:project: progguide
.. doxygenfunction:: errorurl
:project: progguide
.. doxygenfunction:: missing_cmd_args
:project: progguide
.. doxygenfunction:: point_to_error
:project: progguide
.. doxygenfunction:: flush_buffers(LAMMPS *lmp)
:project: progguide

4
doc/src/Developer_write_fix.rst
View File

@ -96,8 +96,8 @@ Here the we specify which methods of the fix should be called during
MPI_Allreduce(localAvgVel, globalAvgVel, 4, MPI_DOUBLE, MPI_SUM, world);
scale3(1.0 / globalAvgVel[3], globalAvgVel);
if ((comm->me == 0) && screen) {
fmt::print(screen,"{}, {}, {}\n",
globalAvgVel[0], globalAvgVel[1], globalAvgVel[2]);
utils::print(screen, "{}, {}, {}\n",
globalAvgVel[0], globalAvgVel[1], globalAvgVel[2]);
}
}

10
doc/src/Developer_write_pair.rst
View File

@ -310,7 +310,7 @@ the constructor and the destructor.
Pair styles are different from most classes in LAMMPS that define a
"style", as their constructor only uses the LAMMPS class instance
pointer as an argument, but **not** the command line arguments of the
pointer as an argument, but **not** the arguments of the
:doc:`pair_style command <pair_style>`. Instead, those arguments are
processed in the ``Pair::settings()`` function (or rather the version in
the derived class). The constructor is the place where global defaults
@ -891,7 +891,7 @@ originally created from mixing or not).
These data file output functions are only useful for true pair-wise
additive potentials, where the potential parameters can be entered
through *multiple* :doc:`pair_coeff commands <pair_coeff>`. Pair styles
that require a single "pair_coeff \* \*" command line are not compatible
that require a single "pair_coeff \* \*" command are not compatible
with reading their parameters from data files. For pair styles like
*born/gauss* that do support writing to data files, the potential
parameters will be read from the data file, if present, and
@ -1122,7 +1122,7 @@ once. Thus, the ``coeff()`` function has to do three tasks, each of
which is delegated to a function in the ``PairTersoff`` class:
#. map elements to atom types. Those follow the potential file name in the
command line arguments and are processed by the ``map_element2type()`` function.
command arguments and are processed by the ``map_element2type()`` function.
#. read and parse the potential parameter file in the ``read_file()`` function.
#. Build data structures where the original and derived parameters are
indexed by all possible triples of atom types and thus can be looked
@ -1356,8 +1356,8 @@ either 0 or 1.
The ``morseflag`` variable defaults to 0 and is set to 1 in the
``PairAIREBOMorse::settings()`` function which is called by the
:doc:`pair_style <pair_style>` command. This function delegates
all command line processing and setting of other parameters to the
:doc:`pair_style <pair_style>` command. This function delegates all
command argument processing and setting of other parameters to the
``PairAIREBO::settings()`` function of the base class.
.. code-block:: c++

54
doc/src/Errors_debug.rst
View File

@ -83,7 +83,7 @@ Run LAMMPS from within the debugger
Running LAMMPS under the control of the debugger as shown below only
works for a single MPI rank (for debugging a program running in parallel
you usually need a parallel debugger program). A simple way to launch
GDB is to prefix the LAMMPS command line with ``gdb --args`` and then
GDB is to prefix the LAMMPS command-line with ``gdb --args`` and then
type the command "run" at the GDB prompt. This will launch the
debugger, load the LAMMPS executable and its debug info, and then run
it. When it reaches the code causing the segmentation fault, it will
@ -180,7 +180,7 @@ inspect the behavior of a compiled program by essentially emulating a
CPU and instrumenting the program while running. This slows down
execution quite significantly, but can also report issues that are not
resulting in a crash. The default valgrind tool is a memory checker and
you can use it by prefixing the normal command line with ``valgrind``.
you can use it by prefixing the normal command-line with ``valgrind``.
Unlike GDB, this will also work for parallel execution, but it is
recommended to redirect the valgrind output to a file (e.g. with
``--log-file=crash-%p.txt``, the %p will be substituted with the
@ -235,3 +235,53 @@ from GDB. In addition you get a more specific hint about what cause the
segmentation fault, i.e. that it is a NULL pointer dereference. To find
out which pointer exactly was NULL, you need to use the debugger, though.
Debugging when LAMMPS appears to be stuck
=========================================
Sometimes the LAMMPS calculation appears to be stuck, that is the LAMMPS
process or processes are active, but there is no visible progress. This
can have multiple reasons:
- The selected styles are slow and require a lot of CPU time and the
system is large. When extrapolating the expected speed from smaller
systems, one has to factor in that not all models scale linearly with
system size, e.g. :doc:`kspace styles like ewald or pppm
<kspace_style>`. There is very little that can be done in this case.
- The output interval is not set or set to a large value with the
:doc:`thermo <thermo>` command. I the first case, there will be output
only at the first and last step.
- The output is block-buffered and instead of line-buffered. The output
will only be written to the screen after 4096 or 8192 characters of
output have accumulated. This most often happens for files but also
with MPI parallel executables for output to the screen, since the
output to the screen is handled by the MPI library so that output from
all processes can be shown. This can be suppressed by using the
``-nonblock`` or ``-nb`` command-line flag, which turns off buffering
for screen and logfile output.
- An MPI parallel calculation has a bug where a collective MPI function
is called (e.g. ``MPI_Barrier()``, ``MPI_Bcast()``,
``MPI_Allreduce()`` and so on) before pending point-to-point
communications are completed or when the collective function is only
called from a subset of the MPI processes. This also applies to some
internal LAMMPS functions like ``Error::all()`` which uses
``MPI_Barrier()`` and thus ``Error::one()`` must be called, if the
error condition does not happen on all MPI processes simultaneously.
- Some function in LAMMPS has a bug where a ``for`` or ``while`` loop
does not trigger the exit condition and thus will loop forever. This
can happen when the wrong variable is incremented or when one value in
a comparison becomes ``NaN`` due to an overflow.
In the latter two cases, further information and stack traces (see above)
can be obtain by attaching a debugger to a running process. For that the
process ID (PID) is needed; this can be found on Linux machines with the
``top``, ``htop``, ``ps``, or ``pstree`` commands.
Then running the (GNU) debugger ``gdb`` with the ``-p`` flag followed by
the process id will attach the process to the debugger and stop
execution of that specific process. From there on it is possible to
issue all debugger commands in the same way as when LAMMPS was started
from the debugger (see above). Most importantly it is possible to
obtain a stack trace with the ``where`` command and thus determine where
in the execution of a timestep this process is. Also internal data can
be printed and execution single stepped or continued. When the debugger
is exited, the calculation will resume normally.

1032
doc/src/Errors_details.rst
View File

File diff suppressed because it is too large Load Diff

3489
doc/src/Errors_messages.rst
View File

File diff suppressed because it is too large Load Diff

169
doc/src/Errors_warnings.rst
View File

@ -1,11 +1,15 @@
Warning messages
================
This is an alphabetic list of the WARNING messages LAMMPS prints out
and the reason why. If the explanation here is not sufficient, the
documentation for the offending command may help. Warning messages
also list the source file and line number where the warning was
generated. For example, a message like this:
This is an alphabetic list of some of the WARNING messages LAMMPS prints
out and the reason why. If the explanation here is not sufficient, the
documentation for the offending command may help. This is a historic
list and no longer updated. Instead the LAMMPS developers are trying
to provide more details right with the error message or link to a
paragraph with :doc:`detailed explanations <Errors_details>`.
Warning messages also list the source file and line number where the
warning was generated. For example, a message like this:
.. parsed-literal::
@ -14,7 +18,7 @@ generated. For example, a message like this:
means that line #187 in the file src/domain.cpp generated the error.
Looking in the source code may help you figure out what went wrong.
Doc page with :doc:`ERROR messages <Errors_messages>`
Please also see the page with :doc:`Error messages <Errors_messages>`
----------
@ -28,16 +32,10 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
cutoff is set too short or the angle has blown apart and an atom is
too far away.
*Angle style in data file differs from currently defined angle style*
Self-explanatory.
*Angles are defined but no angle style is set*
The topology contains angles, but there are no angle forces computed
since there was no angle_style command.
*Atom style in data file differs from currently defined atom style*
Self-explanatory.
*Bond atom missing in box size check*
The second atom needed to compute a particular bond is missing on this
processor. Typically this is because the pairwise cutoff is set too
@ -53,9 +51,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
processor. Typically this is because the pairwise cutoff is set too
short or the bond has blown apart and an atom is too far away.
*Bond style in data file differs from currently defined bond style*
Self-explanatory.
*Bonds are defined but no bond style is set*
The topology contains bonds, but there are no bond forces computed
since there was no bond_style command.
@ -68,9 +63,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
length, multiplying by the number of bonds in the interaction (e.g. 3
for a dihedral) and adding a small amount of stretch.
*Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero*
Self-explanatory.
*Calling write_dump before a full system init.*
The write_dump command is used before the system has been fully
initialized as part of a 'run' or 'minimize' command. Not all dump
@ -86,18 +78,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
This means the temperature associated with the rigid bodies may be
incorrect on this timestep.
*Cannot include log terms without 1/r terms; setting flagHI to 1*
Self-explanatory.
*Cannot include log terms without 1/r terms; setting flagHI to 1.*
Self-explanatory.
*Charges are set, but coulombic solver is not used*
Self-explanatory.
*Charges did not converge at step %ld: %lg*
Self-explanatory.
*Communication cutoff is 0.0. No ghost atoms will be generated. Atoms may get lost*
The communication cutoff defaults to the maximum of what is inferred from
pair and bond styles (will be zero, if none are defined) and what is specified
@ -123,9 +103,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
is not changed automatically and the warning may be ignored depending
on the specific system being simulated.
*Communication cutoff is too small for SNAP micro load balancing, increased to %lf*
Self-explanatory.
*Compute cna/atom cutoff may be too large to find ghost atom neighbors*
The neighbor cutoff used may not encompass enough ghost atoms
to perform this operation correctly.
@ -158,9 +135,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
Conformation of the 4 listed dihedral atoms is extreme; you may want
to check your simulation geometry.
*Dihedral style in data file differs from currently defined dihedral style*
Self-explanatory.
*Dihedrals are defined but no dihedral style is set*
The topology contains dihedrals, but there are no dihedral forces computed
since there was no dihedral_style command.
@ -177,9 +151,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*Estimated error in splitting of dispersion coeffs is %g*
Error is greater than 0.0001 percent.
*Ewald/disp Newton solver failed, using old method to estimate g_ewald*
Self-explanatory. Choosing a different cutoff value may help.
*FENE bond too long*
A FENE bond has stretched dangerously far. It's interaction strength
will be truncated to attempt to prevent the bond from blowing up.
@ -192,9 +163,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
A FENE bond has stretched dangerously far. It's interaction strength
will be truncated to attempt to prevent the bond from blowing up.
*Fix halt condition for fix-id %s met on step %ld with value %g*
Self explanatory.
*Fix SRD walls overlap but fix srd overlap not set*
You likely want to set this in your input script.
@ -238,21 +206,12 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*Fix property/atom mol or charge w/out ghost communication*
A model typically needs these properties defined for ghost atoms.
*Fix qeq CG convergence failed (%g) after %d iterations at %ld step*
Self-explanatory.
*Fix qeq has non-zero lower Taper radius cutoff*
Absolute value must be <= 0.01.
*Fix qeq has very low Taper radius cutoff*
Value should typically be >= 5.0.
*Fix qeq/dynamic tolerance may be too small for damped dynamics*
Self-explanatory.
*Fix qeq/fire tolerance may be too small for damped fires*
Self-explanatory.
*Fix rattle should come after all other integration fixes*
This fix is designed to work after all other integration fixes change
atom positions. Thus it should be the last integration fix specified.
@ -285,9 +244,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
The user-specified force accuracy cannot be achieved unless the table
feature is disabled by using 'pair_modify table 0'.
*Geometric mixing assumed for 1/r\^6 coefficients*
Self-explanatory.
*Group for fix_modify temp != fix group*
The fix_modify command is specifying a temperature computation that
computes a temperature on a different group of atoms than the fix
@ -310,46 +266,14 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
Conformation of the 4 listed improper atoms is extreme; you may want
to check your simulation geometry.
*Improper style in data file differs from currently defined improper style*
Self-explanatory.
*Impropers are defined but no improper style is set*
The topology contains impropers, but there are no improper forces computed
since there was no improper_style command.
*Inconsistent image flags*
The image flags for a pair on bonded atoms appear to be inconsistent.
Inconsistent means that when the coordinates of the two atoms are
unwrapped using the image flags, the two atoms are far apart.
Specifically they are further apart than half a periodic box length.
Or they are more than a box length apart in a non-periodic dimension.
This is usually due to the initial data file not having correct image
flags for the two atoms in a bond that straddles a periodic boundary.
They should be different by 1 in that case. This is a warning because
inconsistent image flags will not cause problems for dynamics or most
LAMMPS simulations. However they can cause problems when such atoms
are used with the fix rigid or replicate commands. Note that if you
have an infinite periodic crystal with bonds then it is impossible to
have fully consistent image flags, since some bonds will cross
periodic boundaries and connect two atoms with the same image
flag.
*Increasing communication cutoff for GPU style*
The pair style has increased the communication cutoff to be consistent with
the communication cutoff requirements for this pair style when run on the GPU.
*KIM Model does not provide 'energy'; Potential energy will be zero*
Self-explanatory.
*KIM Model does not provide 'forces'; Forces will be zero*
Self-explanatory.
*KIM Model does not provide 'particleEnergy'; energy per atom will be zero*
Self-explanatory.
*KIM Model does not provide 'particleVirial'; virial per atom will be zero*
Self-explanatory.
*Kspace_modify slab param < 2.0 may cause unphysical behavior*
The kspace_modify slab parameter should be larger to ensure periodic
grids padded with empty space do not overlap.
@ -401,20 +325,10 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
box, or moved further than one processor's subdomain away before
reneighboring.
*MSM mesh too small, increasing to 2 points in each direction*
Self-explanatory.
*Mismatch between velocity and compute groups*
The temperature computation used by the velocity command will not be
on the same group of atoms that velocities are being set for.
*Mixing forced for lj coefficients*
Self-explanatory.
*Molecule attributes do not match system attributes*
An attribute is specified (e.g. diameter, charge) that is
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 pairwise
interactions.
@ -449,9 +363,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*More than one compute damage/atom*
It is not efficient to use compute ke/atom more than once.
*More than one compute dilatation/atom*
Self-explanatory.
*More than one compute erotate/sphere/atom*
It is not efficient to use compute erorate/sphere/atom more than once.
@ -464,24 +375,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*More than one compute orientorder/atom*
It is not efficient to use compute orientorder/atom more than once.
*More than one compute plasticity/atom*
Self-explanatory.
*More than one compute sna/atom*
Self-explanatory.
*More than one compute sna/grid*
Self-explanatory.
*More than one compute sna/grid/local*
Self-explanatory.
*More than one compute snad/atom*
Self-explanatory.
*More than one compute snav/atom*
Self-explanatory.
*More than one fix poems*
It is not efficient to use fix poems more than once.
@ -557,21 +450,12 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*Pair COMB charge %.10f with force %.10f hit min barrier*
Something is possibly wrong with your model.
*Pair brownian needs newton pair on for momentum conservation*
Self-explanatory.
*Pair dpd needs newton pair on for momentum conservation*
Self-explanatory.
*Pair dsmc: num_of_collisions > number_of_A*
Collision model in DSMC is breaking down.
*Pair dsmc: num_of_collisions > number_of_B*
Collision model in DSMC is breaking down.
*Pair style in data file differs from currently defined pair style*
Self-explanatory.
*Pair style restartinfo set but has no restart support*
This pair style has a bug, where it does not support reading and
writing information to a restart file, but does not set the member
@ -681,9 +565,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
cluster specified by the fix shake command is numerically suspect. LAMMPS
will set it to 0.0 and continue.
*Shell command '%s' failed with error '%s'*
Self-explanatory.
*Shell command returned with non-zero status*
This may indicate the shell command did not operate as expected.
@ -694,15 +575,9 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
This will lead to invalid constraint forces in the SHAKE/RATTLE
computation.
*Simulations might be very slow because of large number of structure factors*
Self-explanatory.
*Slab correction not needed for MSM*
Slab correction is intended to be used with Ewald or PPPM and is not needed by MSM.
*Specifying an 'subset' value of '0' is equivalent to no 'subset' keyword*
Self-explanatory.
*System is not charge neutral, net charge = %g*
The total charge on all atoms on the system is not 0.0.
For some KSpace solvers this is only a warning.
@ -734,9 +609,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
assumed to also be for all atoms. Thus the pressure printed by thermo
could be inaccurate.
*The fix ave/spatial command has been replaced by the more flexible fix ave/chunk and compute chunk/atom commands -- fix ave/spatial will be removed in the summer of 2015*
Self-explanatory.
*The minimizer does not re-orient dipoles when using fix efield*
This means that only the atom coordinates will be minimized,
not the orientation of the dipoles.
@ -745,9 +617,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
More than the maximum # of neighbors was found multiple times. This
was unexpected.
*Too many inner timesteps in fix ttm*
Self-explanatory.
*Too many neighbors in CNA for %d atoms*
More than the maximum # of neighbors was found multiple times. This
was unexpected.
@ -775,24 +644,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
The deformation will heat the SRD particles so this can
be dangerous.
*Using kspace solver on system with no charge*
Self-explanatory.
*Using largest cut-off for lj/long/dipole/long long long*
Self-explanatory.
*Using largest cutoff for buck/long/coul/long*
Self-explanatory.
*Using largest cutoff for lj/long/coul/long*
Self-explanatory.
*Using largest cutoff for pair_style lj/long/tip4p/long*
Self-explanatory.
*Using package gpu without any pair style defined*
Self-explanatory.
*Using pair potential shift with pair_modify compute no*
The shift effects will thus not be computed.

4
doc/src/Examples.rst
View File

@ -54,7 +54,7 @@ Lowercase directories
+-------------+------------------------------------------------------------------+
| body | body particles, 2d system |
+-------------+------------------------------------------------------------------+
| bpm | BPM simulations of pouring elastic grains and plate impact |
| bpm | simulations of solid elastic/plastic deformation and fracture |
+-------------+------------------------------------------------------------------+
| cmap | CMAP 5-body contributions to CHARMM force field |
+-------------+------------------------------------------------------------------+
@ -146,6 +146,8 @@ Lowercase directories
+-------------+------------------------------------------------------------------+
| streitz | use of Streitz/Mintmire potential with charge equilibration |
+-------------+------------------------------------------------------------------+
| stress_vcm | removing binned rigid body motion from binned stress profile |
+-------------+------------------------------------------------------------------+
| tad | temperature-accelerated dynamics of vacancy diffusion in bulk Si |
+-------------+------------------------------------------------------------------+
| threebody | regression test input for a variety of manybody potentials |

94
doc/src/Fortran.rst
View File

@ -16,7 +16,7 @@ compiled alongside the code using it from the source code in
``fortran/lammps.f90`` *and* with the same compiler used to build the
rest of the Fortran code that interfaces to LAMMPS. When linking, you
also need to :doc:`link to the LAMMPS library <Build_link>`. A typical
command line for a simple program using the Fortran interface would be:
command for a simple program using the Fortran interface would be:
.. code-block:: bash
@ -69,10 +69,11 @@ statement. Internally, it will call either
:cpp:func:`lammps_open_fortran` or :cpp:func:`lammps_open_no_mpi` from
the C library API to create the class instance. All arguments are
optional and :cpp:func:`lammps_mpi_init` will be called automatically
if it is needed. Similarly, a possible call to
:cpp:func:`lammps_mpi_finalize` is integrated into the :f:func:`close`
function and triggered with the optional logical argument set to
``.TRUE.``. Here is a simple example:
if it is needed. Similarly, optional calls to
:cpp:func:`lammps_mpi_finalize`, :cpp:func:`lammps_kokkos_finalize`,
:cpp:func:`lammps_python_finalize`, and :cpp:func:`lammps_plugin_finalize`
are integrated into the :f:func:`close` function and triggered with the
optional logical argument set to ``.TRUE.``. Here is a simple example:
.. code-block:: fortran
@ -91,12 +92,12 @@ function and triggered with the optional logical argument set to
CALL lmp%close(.TRUE.)
END PROGRAM testlib
It is also possible to pass command line flags from Fortran to C/C++ and
It is also possible to pass command-line flags from Fortran to C/C++ and
thus make the resulting executable behave similarly to the standalone
executable (it will ignore the `-in/-i` flag, though). This allows
using the command line to configure accelerator and suffix settings,
using the command-line to configure accelerator and suffix settings,
configure screen and logfile output, or to set index style variables
from the command line and more. Here is a correspondingly adapted
from the command-line and more. Here is a correspondingly adapted
version of the previous example:
.. code-block:: fortran
@ -108,7 +109,7 @@ version of the previous example:
CHARACTER(LEN=128), ALLOCATABLE :: command_args(:)
INTEGER :: i, argc
! copy command line flags to `command_args()`
! copy command-line flags to `command_args()`
argc = COMMAND_ARGUMENT_COUNT()
ALLOCATE(command_args(0:argc))
DO i=0, argc
@ -321,6 +322,14 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
:ftype set_string_variable: subroutine
:f set_internal_variable: :f:subr:`set_internal_variable`
:ftype set_internal_variable: subroutine
:f eval: :f:func:`eval`
:ftype eval: function
:f clearstep_compute: :f:subr:`clearstep_compute`
:ftype clearstep_compute: subroutine
:f addstep_compute: :f:subr:`addstep_compute`
:ftype addstep_compute: subroutine
:f addstep_compute_all: :f:subr:`addstep_compute_all`
:ftype addstep_compute_all: subroutine
:f gather_atoms: :f:subr:`gather_atoms`
:ftype gather_atoms: subroutine
:f gather_atoms_concat: :f:subr:`gather_atoms_concat`
@ -448,7 +457,7 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
compiled with MPI support, it will also initialize MPI, if it has
not already been initialized before.
The *args* argument with the list of command line parameters is
The *args* argument with the list of command-line parameters is
optional and so it the *comm* argument with the MPI communicator.
If *comm* is not provided, ``MPI_COMM_WORLD`` is assumed. For
more details please see the documentation of :cpp:func:`lammps_open`.
@ -513,8 +522,8 @@ Procedures Bound to the :f:type:`lammps` Derived Type
This method will close down the LAMMPS instance through calling
:cpp:func:`lammps_close`. If the *finalize* argument is present and
has a value of ``.TRUE.``, then this subroutine also calls
:cpp:func:`lammps_kokkos_finalize` and
:cpp:func:`lammps_mpi_finalize`.
:cpp:func:`lammps_kokkos_finalize`, :cpp:func:`lammps_mpi_finalize`,
:cpp:func:`lammps_python_finalize`, and :cpp:func:`lammps_plugin_finalize`.
:o finalize: shut down the MPI environment of the LAMMPS
library if ``.TRUE.``.
@ -522,6 +531,8 @@ Procedures Bound to the :f:type:`lammps` Derived Type
:to: :cpp:func:`lammps_close`
:to: :cpp:func:`lammps_mpi_finalize`
:to: :cpp:func:`lammps_kokkos_finalize`
:to: :cpp:func:`lammps_python_finalize`
:to: :cpp:func:`lammps_plugin_finalize`
--------
@ -954,6 +965,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type
:f:func:`extract_atom` between runs.
.. admonition:: Array index order
:class: tip
Two-dimensional arrays returned from :f:func:`extract_atom` will be
**transposed** from equivalent arrays in C, and they will be indexed
@ -1066,6 +1078,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type
you based on data from the :cpp:class:`Compute` class.
.. admonition:: Array index order
:class: tip
Two-dimensional arrays returned from :f:func:`extract_compute` will be
**transposed** from equivalent arrays in C, and they will be indexed
@ -1324,6 +1337,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type
:rtype data: polymorphic
.. admonition:: Array index order
:class: tip
Two-dimensional global, per-atom, or local array data from
:f:func:`extract_fix` will be **transposed** from equivalent arrays in
@ -1448,11 +1462,62 @@ Procedures Bound to the :f:type:`lammps` Derived Type
an internal-style variable, an error is generated.
:p character(len=*) name: name of the variable
:p read(c_double) val: new value to assign to the variable
:p real(c_double) val: new value to assign to the variable
:to: :cpp:func:`lammps_set_internal_variable`
--------
.. f:function:: eval(expr)
This function is a wrapper around :cpp:func:`lammps_eval` that takes a
LAMMPS equal style variable string, evaluates it and returns the resulting
scalar value as a floating-point number.
.. versionadded:: 4Feb2025
:p character(len=\*) expr: string to be evaluated
:to: :cpp:func:`lammps_eval`
:r value [real(c_double)]: result of the evaluated string
--------
.. f:subroutine:: clearstep_compute()
Clear whether a compute has been invoked
.. versionadded:: 4Feb2025
:to: :cpp:func:`lammps_clearstep_compute`
--------
.. f:subroutine:: addstep_compute(nextstep)
Add timestep to list of future compute invocations
if the compute has been invoked on the current timestep
.. versionadded:: 4Feb2025
overloaded for 32-bit and 64-bit integer arguments
:p integer(kind=8 or kind=4) nextstep: next timestep
:to: :cpp:func:`lammps_addstep_compute`
--------
.. f:subroutine:: addstep_compute_all(nextstep)
Add timestep to list of future compute invocations
.. versionadded:: 4Feb2025
overloaded for 32-bit and 64-bit integer arguments
:p integer(kind=8 or kind=4) nextstep: next timestep
:to: :cpp:func:`lammps_addstep_compute_all`
--------
.. f:subroutine:: gather_atoms(name, count, data)
This function calls :cpp:func:`lammps_gather_atoms` to gather the named
@ -2711,8 +2776,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type
END SUBROUTINE external_callback
END INTERFACE
where ``c_bigint`` is ``c_int`` if ``-DLAMMPS_SMALLSMALL`` was used and
``c_int64_t`` otherwise; and ``c_tagint`` is ``c_int64_t`` if
where ``c_bigint`` is ``c_int64_t`` and ``c_tagint`` is ``c_int64_t`` if
``-DLAMMPS_BIGBIG`` was used and ``c_int`` otherwise.
The argument *caller* to :f:subr:`set_fix_external_callback` is unlimited

3
doc/src/Howto.rst
View File

@ -40,6 +40,7 @@ Settings howto
Howto_walls
Howto_nemd
Howto_dispersion
Howto_bulk2slab
Analysis howto
==============
@ -65,6 +66,7 @@ Force fields howto
:name: force_howto
:maxdepth: 1
Howto_FFgeneral
Howto_bioFF
Howto_amoeba
Howto_tip3p
@ -103,6 +105,7 @@ Tutorials howto
Howto_github
Howto_lammps_gui
Howto_moltemplate
Howto_python
Howto_pylammps
Howto_wsl

55
doc/src/Howto_FFgeneral.rst Normal file
View File

@ -0,0 +1,55 @@
Some general force field considerations
=======================================
A compact summary of the concepts, definitions, and properties of force
fields with explicit bonded interactions (like the ones discussed in
this HowTo) is given in :ref:`(Gissinger) <Typelabel2>`.
A force field has 2 parts: the formulas that define its potential
functions and the coefficients used for a particular system. To assign
parameters it is first required to assign atom types. Those are not
only based on the elements, but also on the chemical environment due to
the atoms bound to them. This often follows the chemical concept of
*functional groups*. Example: a carbon atom bound with a single bond to
a single OH-group (alcohol) would be a different atom type than a carbon
atom bound to a methyl CH3 group (aliphatic carbon). The atom types
usually then determine the non-bonded Lennard-Jones parameters and the
parameters for bonds, angles, dihedrals, and impropers. On top of that,
partial charges have to be applied. Those are usually independent of
the atom types and are determined either for groups of atoms called
residues with some fitting procedure based on quantum mechanical
calculations, or based on some increment system that add or subtract
increments from the partial charge of an atom based on the types of
the neighboring atoms.
Force fields differ in the strategies they employ to determine the
parameters and charge distribution in how generic or specific they are
which in turn has an impact on the accuracy (compare for example
CGenFF to CHARMM and GAFF to Amber). Because of the different
strategies, it is not a good idea to use a mix of parameters from
different force field *families* (like CHARMM, Amber, or GROMOS)
and that extends to the parameters for the solvent, especially
water. The publication describing the parameterization of a force
field will describe which water model to use. Changing the water
model usually leads to overall worse results (even if it may improve
on the water itself).
In addition, one has to consider that *families* of force fields like
CHARMM, Amber, OPLS, or GROMOS have evolved over time and thus provide
different *revisions* of the force field parameters. These often
corresponds to changes in the functional form or the parameterization
strategies. This may also result in changes required for simulation
settings like the preferred cutoff or how Coulomb interactions are
computed (cutoff, smoothed/shifted cutoff, or long-range with Ewald
summation or equivalent). Unless explicitly stated in the publication
describing the force field, the Coulomb interaction cannot be chosen at
will but must match the revision of the force field. That said,
liberties may be taken during the initial equilibration of a system to
speed up the process, but not for production simulations.
----------
.. _Typelabel2:
**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).

15
doc/src/Howto_barostat.rst
View File

@ -10,20 +10,21 @@ and/or pressure (P) is specified by the user, and the thermostat or
barostat attempts to equilibrate the system to the requested T and/or
P.
Barostatting in LAMMPS is performed by :doc:`fixes <fix>`. Two
Barostatting in LAMMPS is performed by :doc:`fixes <fix>`. Three
barostatting methods are currently available: Nose-Hoover (npt and
nph) and Berendsen:
nph), Berendsen, and various linear controllers in deform/pressure:
* :doc:`fix npt <fix_nh>`
* :doc:`fix npt/sphere <fix_npt_sphere>`
* :doc:`fix npt/asphere <fix_npt_asphere>`
* :doc:`fix nph <fix_nh>`
* :doc:`fix press/berendsen <fix_press_berendsen>`
* :doc:`fix deform/pressure <fix_deform_pressure>`
The :doc:`fix npt <fix_nh>` commands include a Nose-Hoover thermostat
and barostat. :doc:`Fix nph <fix_nh>` is just a Nose/Hoover barostat;
it does no thermostatting. Both :doc:`fix nph <fix_nh>` and :doc:`fix press/berendsen <fix_press_berendsen>` can be used in conjunction
with any of the thermostatting fixes.
it does no thermostatting. The fixes :doc:`nph <fix_nh>`, :doc:`press/berendsen <fix_press_berendsen>`, and :doc:`deform/pressure <fix_deform_pressure>`
can be used in conjunction with any of the thermostatting fixes.
As with the :doc:`thermostats <Howto_thermostat>`, :doc:`fix npt <fix_nh>`
and :doc:`fix nph <fix_nh>` only use translational motion of the
@ -44,9 +45,9 @@ a temperature or pressure compute to a barostatting fix.
.. note::
As with the thermostats, the Nose/Hoover methods (:doc:`fix npt <fix_nh>` and :doc:`fix nph <fix_nh>`) perform time integration.
:doc:`Fix press/berendsen <fix_press_berendsen>` does NOT, so it should
be used with one of the constant NVE fixes or with one of the NVT
fixes.
:doc:`Fix press/berendsen <fix_press_berendsen>` and :doc:`fix deform/pressure <fix_deform_pressure>`
do NOT, so they should be used with one of the constant NVE fixes or with
one of the NVT fixes.
Thermodynamic output, which can be setup via the
:doc:`thermo_style <thermo_style>` command, often includes pressure

79
doc/src/Howto_bioFF.rst
View File

@ -1,22 +1,16 @@
CHARMM, AMBER, COMPASS, and DREIDING force fields
=================================================
CHARMM, AMBER, COMPASS, DREIDING, and OPLS force fields
=======================================================
A compact summary of the concepts, definitions, and properties of
force fields with explicit bonded interactions (like the ones discussed
in this HowTo) is given in :ref:`(Gissinger) <Typelabel2>`.
A force field has 2 parts: the formulas that define it and the
coefficients used for a particular system. Here we only discuss
formulas implemented in LAMMPS that correspond to formulas commonly used
in the CHARMM, AMBER, COMPASS, and DREIDING force fields. Setting
coefficients is done either from special sections in an input data file
via the :doc:`read_data <read_data>` command or in the input script with
commands like :doc:`pair_coeff <pair_coeff>` or :doc:`bond_coeff
<bond_coeff>` and so on. See the :doc:`Tools <Tools>` doc page for
additional tools that can use CHARMM, AMBER, or Materials Studio
generated files to assign force field coefficients and convert their
output into LAMMPS input. LAMMPS input scripts can also be generated by
`charmm-gui.org <https://charmm-gui.org/>`_.
Here we only discuss formulas implemented in LAMMPS that correspond to
formulas commonly used in the CHARMM, AMBER, COMPASS, and DREIDING force
fields. Setting coefficients is done either from special sections in an
input data file via the :doc:`read_data <read_data>` command or in the
input script with commands like :doc:`pair_coeff <pair_coeff>` or
:doc:`bond_coeff <bond_coeff>` and so on. See the :doc:`Tools <Tools>`
doc page for additional tools that can use CHARMM, AMBER, or Materials
Studio generated files to assign force field coefficients and convert
their output into LAMMPS input. LAMMPS input scripts can also be
generated by `charmm-gui.org <https://charmm-gui.org/>`_.
CHARMM and AMBER
----------------
@ -203,9 +197,11 @@ rather than individual force constants and geometric parameters that
depend on the particular combinations of atoms involved in the bond,
angle, or torsion terms. DREIDING has an :doc:`explicit hydrogen bond
term <pair_hbond_dreiding>` to describe interactions involving a
hydrogen atom on very electronegative atoms (N, O, F). Unlike CHARMM
or AMBER, the DREIDING force field has not been parameterized for
considering solvents (like water).
hydrogen atom on very electronegative atoms (N, O, F). Unlike CHARMM or
AMBER, the DREIDING force field has not been parameterized for
considering solvents (like water) and has no rules for assigning
(partial) charges. That will seriously limit its accuracy when used for
simulating systems where those matter.
See :ref:`(Mayo) <howto-Mayo>` for a description of the DREIDING force field
@ -236,12 +232,42 @@ documentation for the formula it computes.
* :doc:`special_bonds <special_bonds>` dreiding
OPLS
----
OPLS (Optimized Potentials for Liquid Simulations) is a general force
field for atomistic simulation of organic molecules in solvent. It was
developed by the `Jorgensen group
<https://traken.chem.yale.edu/oplsaam.html>`_ at Purdue University and
later at Yale University. Multiple versions of the OPLS parameters
exist for united atom representations (OPLS-UA) and for all-atom
representations (OPLS-AA).
This force field is based on atom types mapped to specific functional
groups in organic and biological molecules. Each atom includes a
static, partial atomic charge reflecting the oxidation state of the
element derived from its bonded neighbors :ref:`(Jorgensen)
<howto-jorgensen>` and computed based on increments determined by the
atom type of the atoms bond to it.
The interaction styles listed below compute force field formulas that
are fully or in part consistent with the OPLS style force fields. See
each command's documentation for the formula it computes. Some are only
compatible with a subset of OPLS interactions.
* :doc:`bond_style <bond_harmonic>` harmonic
* :doc:`angle_style <angle_harmonic>` harmonic
* :doc:`dihedral_style <dihedral_opls>` opls
* :doc:`improper_style <improper_cvff>` cvff
* :doc:`improper_style <improper_fourier>` fourier
* :doc:`improper_style <improper_harmonic>` harmonic
* :doc:`pair_style <pair_lj_cut_coul>` lj/cut/coul/cut
* :doc:`pair_style <pair_lj_cut_coul>` lj/cut/coul/long
* :doc:`pair_modify <pair_modify>` geometric
* :doc:`special_bonds <special_bonds>` lj/coul 0.0 0.0 0.5
----------
.. _Typelabel2:
**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).
.. _howto-MacKerell:
**(MacKerell)** MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field, Fischer, Gao, Guo, Ha, et al (1998). J Phys Chem, 102, 3586 . https://doi.org/10.1021/jp973084f
@ -266,3 +292,6 @@ documentation for the formula it computes.
**(Mayo)** Mayo, Olfason, Goddard III (1990). J Phys Chem, 94, 8897-8909. https://doi.org/10.1021/j100389a010
.. _howto-Jorgensen:
**(Jorgensen)** Jorgensen, Tirado-Rives (1988). J Am Chem Soc, 110, 1657-1666. https://doi.org/10.1021/ja00214a001

18
doc/src/Howto_bpm.rst
View File

@ -5,7 +5,11 @@ The BPM package implements bonded particle models which can be used to
simulate mesoscale solids. Solids are constructed as a collection of
particles, which each represent a coarse-grained region of space much
larger than the atomistic scale. Particles within a solid region are
then connected by a network of bonds to provide solid elasticity.
then connected by a network of bonds to model solid elasticity.
There are many names for methods that are based on similar (or
equivalent) capabilities to those in this package, including, but not
limited to, cohesive beam models, bonded DEMs, lattice spring models,
mass spring models, and lattice particle methods.
Unlike traditional bonds in molecular dynamics, the equilibrium bond
length can vary between bonds. Bonds store the reference state. This
@ -38,11 +42,14 @@ such as those created by pouring grains using :doc:`fix pour
----------
Currently, there are two types of bonds included in the BPM package. The
Currently, there are three types of bonds included in the BPM package. The
first bond style, :doc:`bond bpm/spring <bond_bpm_spring>`, only applies
pairwise, central body forces. Point particles must have :doc:`bond atom
style <atom_style>` and may be thought of as nodes in a spring
network. Alternatively, the second bond style, :doc:`bond bpm/rotational
network. An optional multibody term can be used to adjust the network's
Poisson's ratio. The :doc:`bpm/spring/plastic <bond_bpm_spring_plastic>`
bond style is similar except it adds a plastic yield strain.
Alternatively, the third bond style, :doc:`bond bpm/rotational
<bond_bpm_rotational>`, resolves tangential forces and torques arising
with the shearing, bending, and twisting of the bond due to rotation or
displacement of particles. Particles are similar to those used in the
@ -55,8 +62,9 @@ orientation similar to :doc:`fix nve/asphere <fix_nve_asphere>`.
In addition to bond styles, a new pair style :doc:`pair bpm/spring
<pair_bpm_spring>` was added to accompany the bpm/spring bond
style. This pair style is simply a hookean repulsion with similar
velocity damping as its sister bond style.
style. By default, this pair style is simply a hookean repulsion with
similar velocity damping as its sister bond style, but optional
arguments can be used to modify the force.
----------

160
doc/src/Howto_bulk2slab.rst Normal file
View File

@ -0,0 +1,160 @@
===========================
Convert bulk system to slab
===========================
A regularly encountered simulation problem is how to convert a bulk
system that has been run for a while to equilibrate into a slab system
with some vacuum space and free surfaces. The challenge here is that
one cannot just change the box dimensions with the :doc:`change_box
command <change_box>` or edit the box boundaries in a data file because
some atoms will have non-zero image flags from diffusing around.
Changing the box dimensions results in an undesired displacement of
those atoms, since the image flags indicate how many times the box
length in x-, y-, or z-direction needs to be added or subtracted to get
the "unwrapped" coordinates. By changing the box dimension this
distance is changed and thus those atoms move unphysically relative to
their neighbors with zero image flags. Setting image flags forcibly to
zero creates problems because that could break apart molecules by having
one atom of a bond on the top of the system and the other at the bottom.
.. _bulk2slab:
.. figure:: JPG/rhodo-both.jpg
:figwidth: 80%
:figclass: align-center
Snapshots of the bulk Rhodopsin in lipid layer and water system (right)
and the generated slab geometry (left)
.. admonition:: Disclaimer
:class: note
The following workflow will work for many bulk systems, but not all.
Some systems cannot be converted (e.g. polymers with bonds to the
same molecule across periodic boundaries, sometimes called "infinite
polymers"). The amount of vacuum that needs to be added depends on
the length of the molecules where the system is split (the example
here splits where there is water with short molecules). In some
cases, the system may need to be re-centered in the box first using
the :doc:`displace_atoms command <displace_atoms>`. Also, the time
spent on strong thermalization and equilibration will depend on the
specific system and its thermodynamic conditions.
Below is a suggested workflow using the :doc:`Rhodopsin benchmark input
<Speed_bench>` for demonstration. The figure shows the state *before*
the procedure on the left (with unwrapped atoms that have diffused out
of the box) and *after* on the right (with the vacuum added above and
below). The procedure is implemented by modifying a copy of the
``in.rhodo`` input file. The first lines up to and including the
:doc:`read_data command <read_data>` remain unchanged. Then we insert
the following lines to add vacuum to the z direction above and below the
system:
.. code-block:: LAMMPS
variable delta index 10.0
reset_atoms image all
write_dump all custom rhodo-unwrap.lammpstrj id xu yu zu
change_box all z final $(zlo-2.0*v_delta) $(zhi+2.0*v_delta) &
boundary p p f
read_dump rhodo-unwrap.lammpstrj 0 x y z box no replace yes
kspace_modify slab 3.0
Specifically, the :doc:`variable delta <variable>` (set to 10.0)
represents a distance that determines the amount of vacuum added: we add
twice its value in each direction to the z-dimension; thus in total
:math:`40 \AA` get added. The :doc:`reset_atoms image all
<reset_atoms>` command shall reset any image flags to become either 0 or
:math:`\pm 1` and thus have the minimum distance from the center of the
simulation box, but the correct relative distance for bonded atoms.
The :doc:`write_dump command <write_dump>` then writes out the resulting
*unwrapped* coordinates of the system. After expanding the box,
coordinates that were outside the box should now be inside and the
unwrapped coordinates will become "wrapped", while atoms outside the
periodic boundaries will be wrapped back into the box and their image
flags in those directions restored.
The :doc:`change_box command <change_box>` adds the desired
distance to the low and high box boundary in z-direction and then changes
the :doc:`boundary to "p p f" <boundary>` which will force the image
flags in z-direction to zero and create an undesired displacement for
the atoms with non-zero image flags.
With the :doc:`read_dump command <read_dump>` we read back and replace
partially incorrect coordinates with the previously saved, unwrapped
coordinates. It is important to ignore the box dimensions stored in the
dump file. We want to preserve the expanded box. Finally, we turn on
the slab correction for the PPPM long-range solver with the
:doc:`kspace_modify command <kspace_modify>` as required when using a
long range Coulomb solver for non-periodic z-dimension.
Next we replace the :doc:`fix npt command <fix_nh>` with:
.. code-block:: LAMMPS
fix 2 nvt temp 300.0 300.0 10.0
We now have an open system and thus the adjustment of the cell in
z-direction is no longer required. Since splitting the bulk water
region where the vacuum is inserted, creates surface atoms with high
potential energy, we reduce the thermostat time constant from 100.0 to
10.0 to remove excess kinetic energy resulting from that change faster.
Also the high potential energy of the surface atoms can cause that some
of them are ejected from the slab. In order to suppress that, we add
soft harmonic walls to push back any atoms that want to leave the slab.
To determine the position of the wall, we first need to to determine the
extent of the atoms in z-direction and then place the harmonic walls
based on that information:
.. code-block:: LAMMPS
compute zmin all reduce min z
compute zmax all reduce max z
thermo_style custom zlo c_zmin zhi c_zmax
run 0 post no
fix 3 all wall/harmonic zhi $(c_zmax+v_delta) 10.0 0.0 ${delta} &
zlo $(c_zmin-v_delta) 10.0 0.0 ${delta}
The two :doc:`compute reduce <compute_reduce>` command determine the
minimum and maximum z-coordinate across all atoms. In order to trigger
the execution of the compute commands we need to "consume" them. This
is done with the :doc:`thermo_style custom <thermo_style>` command
followed by the :doc:`run 0 <run>` command. This avoids and error
accessing the min/max values determined by the compute commands to
compute the location of the wall in lower and upper direction. This
uses the previously defined *delta* variable to determine the distance
of the wall from the extent of the system and the cutoff for the wall
interaction. This way only atoms that move beyond the min/max values in
z-direction will experience a restoring force, nudging them back to the
slab. The force constant of :math:`10.0 \frac{\mathrm{kcal/mol}}{\AA}`
was determined empirically.
Adding these "restoring" soft walls assist in making the free surfaces
above and below the slab flat, instead of having rugged or ondulated
surfaces. The impact of the walls can be changed by adjusting the force
constant, cutoff, and position of the wall.
Finally, we replace the :doc:`run 100 <run>` of the original input with:
.. code-block:: LAMMPS
run 1000 post no
unfix 3
fix 2 all nvt temp 300.0 300.0 100.0
run 1000 post no
write_data data.rhodo-slab
This runs the system converted to a slab first for 1000 MD steps using
the walls and stronger Nose-Hoover thermostat. Then the walls are
removed with :doc:`unfix 3 <unfix>` and the thermostat time constant
reset to 100.0 and the system run for another 1000 steps. Finally the
resulting slab geometry is written to a new data file
``data.rhodo-slab`` with a :doc:`write_data command <write_data>`. The
number of MD steps required to reach a proper equilibrium state is very
likely larger. The number of 1000 steps (corresponding to 2
picoseconds) was chosen for demonstration purposes, so that the
procedure can be easily and quickly tested.

67
doc/src/Howto_chunk.rst
View File

@ -58,28 +58,30 @@ chunk ID for an individual atom can also be static (e.g. a molecule
ID), or dynamic (e.g. what spatial bin an atom is in as it moves).
Note that this compute allows the per-atom output of other
:doc:`computes <compute>`, :doc:`fixes <fix>`, and
:doc:`variables <variable>` to be used to define chunk IDs for each
atom. This means you can write your own compute or fix to output a
per-atom quantity to use as chunk ID. See the :doc:`Modify <Modify>`
doc pages for info on how to do this. You can also define a :doc:`per-atom variable <variable>` in the input script that uses a formula to
generate a chunk ID for each atom.
:doc:`computes <compute>`, :doc:`fixes <fix>`, and :doc:`variables
<variable>` to be used to define chunk IDs for each atom. This means
you can write your own compute or fix to output a per-atom quantity to
use as chunk ID. See the :doc:`Modify <Modify>` doc pages for info on
how to do this. You can also define a :doc:`per-atom variable
<variable>` in the input script that uses a formula to generate a chunk
ID for each atom.
Fix ave/chunk command:
----------------------
This fix takes the ID of a :doc:`compute chunk/atom <compute_chunk_atom>` command as input. For each chunk,
it then sums one or more specified per-atom values over the atoms in
each chunk. The per-atom values can be any atom property, such as
velocity, force, charge, potential energy, kinetic energy, stress,
etc. Additional keywords are defined for per-chunk properties like
density and temperature. More generally any per-atom value generated
by other :doc:`computes <compute>`, :doc:`fixes <fix>`, and :doc:`per-atom variables <variable>`, can be summed over atoms in each chunk.
This fix takes the ID of a :doc:`compute chunk/atom
<compute_chunk_atom>` command as input. For each chunk, it then sums
one or more specified per-atom values over the atoms in each chunk. The
per-atom values can be any atom property, such as velocity, force,
charge, potential energy, kinetic energy, stress, etc. Additional
keywords are defined for per-chunk properties like density and
temperature. More generally any per-atom value generated by other
:doc:`computes <compute>`, :doc:`fixes <fix>`, and :doc:`per-atom
variables <variable>`, can be summed over atoms in each chunk.
Similar to other averaging fixes, this fix allows the summed per-chunk
values to be time-averaged in various ways, and output to a file. The
fix produces a global array as output with one row of values per
chunk.
fix produces a global array as output with one row of values per chunk.
Compute \*/chunk commands:
--------------------------
@ -97,17 +99,20 @@ category:
* :doc:`compute torque/chunk <compute_vcm_chunk>`
* :doc:`compute vcm/chunk <compute_vcm_chunk>`
They each take the ID of a :doc:`compute chunk/atom <compute_chunk_atom>` command as input. As their names
indicate, they calculate the center-of-mass, radius of gyration,
moments of inertia, mean-squared displacement, temperature, torque,
and velocity of center-of-mass for each chunk of atoms. The :doc:`compute property/chunk <compute_property_chunk>` command can tally the
count of atoms in each chunk and extract other per-chunk properties.
They each take the ID of a :doc:`compute chunk/atom
<compute_chunk_atom>` command as input. As their names indicate, they
calculate the center-of-mass, radius of gyration, moments of inertia,
mean-squared displacement, temperature, torque, and velocity of
center-of-mass for each chunk of atoms. The :doc:`compute
property/chunk <compute_property_chunk>` command can tally the count of
atoms in each chunk and extract other per-chunk properties.
The reason these various calculations are not part of the :doc:`fix ave/chunk command <fix_ave_chunk>`, is that each requires a more
The reason these various calculations are not part of the :doc:`fix
ave/chunk command <fix_ave_chunk>`, is that each requires a more
complicated operation than simply summing and averaging over per-atom
values in each chunk. For example, many of them require calculation
of a center of mass, which requires summing mass\*position over the
atoms and then dividing by summed mass.
values in each chunk. For example, many of them require calculation of
a center of mass, which requires summing mass\*position over the atoms
and then dividing by summed mass.
All of these computes produce a global vector or global array as
output, with one or more values per chunk. The output can be used in
@ -118,9 +123,10 @@ various ways:
* As input to the :doc:`fix ave/histo <fix_ave_histo>` command to
histogram values across chunks. E.g. a histogram of cluster sizes or
molecule diffusion rates.
* As input to special functions of :doc:`equal-style variables <variable>`, like sum() and max() and ave(). E.g. to
find the largest cluster or fastest diffusing molecule or average
radius-of-gyration of a set of molecules (chunks).
* As input to special functions of :doc:`equal-style variables
<variable>`, like sum() and max() and ave(). E.g. to find the largest
cluster or fastest diffusing molecule or average radius-of-gyration of
a set of molecules (chunks).
Other chunk commands:
---------------------
@ -138,9 +144,10 @@ spatially average per-chunk values calculated by a per-chunk compute.
The :doc:`compute reduce/chunk <compute_reduce_chunk>` command reduces a
peratom value across the atoms in each chunk to produce a value per
chunk. When used with the :doc:`compute chunk/spread/atom <compute_chunk_spread_atom>` command it can
create peratom values that induce a new set of chunks with a second
:doc:`compute chunk/atom <compute_chunk_atom>` command.
chunk. When used with the :doc:`compute chunk/spread/atom
<compute_chunk_spread_atom>` command it can create peratom values that
induce a new set of chunks with a second :doc:`compute chunk/atom
<compute_chunk_atom>` command.
Example calculations with chunks
--------------------------------

12
doc/src/Howto_cmake.rst
View File

@ -56,7 +56,7 @@ using a shell like Bash or Zsh.
Visual Studio IDE with the bundled CMake or from the Windows command prompt using
a separately installed CMake package, both using the native Microsoft Visual C++
compilers and (optionally) the Microsoft MPI SDK. This tutorial, however, only
covers unix-like command line interfaces.
covers unix-like command-line interfaces.
We also assume that you have downloaded and unpacked a recent LAMMPS source code package
or used Git to create a clone of the LAMMPS sources on your compilation machine.
@ -277,7 +277,7 @@ Setting options
---------------
Options that enable, disable or modify settings are modified by setting
the value of CMake variables. This is done on the command line with the
the value of CMake variables. This is done on the command-line with the
*-D* flag in the format ``-D VARIABLE=value``, e.g. ``-D
CMAKE_BUILD_TYPE=Release`` or ``-D BUILD_MPI=on``. There is one quirk:
when used before the CMake directory, there may be a space between the
@ -285,7 +285,7 @@ when used before the CMake directory, there may be a space between the
can have boolean values (on/off, yes/no, or 1/0 are all valid) or are
strings representing a choice, or a path, or are free format. If the
string would contain whitespace, it must be put in quotes, for example
``-D CMAKE_TUNE_FLAGS="-ftree-vectorize -ffast-math"``.
``-D CMAKE_CXX_FLAGS="-O3 -Wall -ftree-vectorize -ffast-math"``.
CMake variables fall into two categories: 1) common CMake variables that
are used by default for any CMake configuration setup and 2) project
@ -341,8 +341,6 @@ Some common LAMMPS specific variables
- compile some additional executables from the ``tools`` folder (default: ``off``)
* - ``BUILD_DOC``
- include building the HTML format documentation for packaging/installing (default: ``off``)
* - ``CMAKE_TUNE_FLAGS``
- common compiler flags, for optimization or instrumentation (default:)
* - ``LAMMPS_MACHINE``
- when set to ``name`` the LAMMPS executable and library will be called ``lmp_name`` and ``liblammps_name.a``
* - ``FFT``
@ -376,7 +374,7 @@ Using presets
-------------
Since LAMMPS has a lot of optional features and packages, specifying
them all on the command line can be tedious. Or when selecting a
them all on the command-line can be tedious. Or when selecting a
different compiler toolchain, multiple options have to be changed
consistently and that is rather error prone. Or when enabling certain
packages, they require consistent settings to be operated in a
@ -384,7 +382,7 @@ particular mode. For this purpose, we are providing a selection of
"preset files" for CMake in the folder ``cmake/presets``. They
represent a way to pre-load or override the CMake configuration cache by
setting or changing CMake variables. Preset files are loaded using the
*-C* command line flag. You can combine loading multiple preset files or
*-C* command-line flag. You can combine loading multiple preset files or
change some variables later with additional *-D* flags. A few examples:
.. code-block:: bash

12
doc/src/Howto_github.rst
View File

@ -163,7 +163,7 @@ After everything is done, add the files to the branch and commit them:
*git rm*, *git mv* for adding, removing, renaming individual files,
respectively, and then *git commit* to finalize the commit.
Carefully check all pending changes with *git status* before
committing them. If you find doing this on the command line too
committing them. If you find doing this on the command-line too
tedious, consider using a GUI, for example the one included in git
distributions written in Tk, i.e. use *git gui* (on some Linux
distributions it may be required to install an additional package to
@ -487,10 +487,10 @@ updates are back-ported from the *develop* branch to the *maintenance*
branch and occasionally merged to *stable* as an update release.
Furthermore, the naming of the release tags now follow the pattern
"patch_<Day><Month><Year>" to simplify comparisons between releases.
For stable releases additional "stable_<Day><Month><Year>" tags are
"patch\_<Day><Month><Year>" to simplify comparisons between releases.
For stable releases additional "stable\_<Day><Month><Year>" tags are
applied and update releases are tagged with
"stable_<Day><Month><Year>_update<Number>", Finally, all releases and
"stable\_<Day><Month><Year>\_update<Number>", Finally, all releases and
submissions are subject to automatic testing and code checks to make
sure they compile with a variety of compilers and popular operating
systems. Some unit and regression testing is applied as well.
@ -498,3 +498,7 @@ systems. Some unit and regression testing is applied as well.
A detailed discussion of the LAMMPS developer GitHub workflow can be
found in the file `doc/github-development-workflow.md
<https://github.com/lammps/lammps/blob/develop/doc/github-development-workflow.md>`_
.. raw:: latex
\clearpage

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