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

Merge branch 'develop' of https://www.github.com/lammps/lammps into kmc

Browse Source
This commit is contained in:
Jacob Tavenner
2025-04-14 15:37:47 -06:00
parent 3a6ea0808d b081d289c1
commit ca246a50f1
1579 changed files with 96240 additions and 33294 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

372
.github/release_steps.md vendored
View File

@ -1,42 +1,54 @@
# LAMMPS Release Steps
The following notes chronicle the current steps for preparing and publishing LAMMPS releases. For
definitions of LAMMPS versions and releases mean, please refer to [the corresponding section in the
LAMMPS manual](https://docs.lammps.org/Manual_version.html).
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.
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"
- 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, rebase if needed. This is the last pull request merged for the release
and should not contain any other changes. (Exceptions: this document, last minute trivial(!) changes).
- 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
This PR shall not be merged before **all** pending tests have completed and cleared. If needed, a
bugfix pull request should be created and merged to clear all tests.
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'.
When all pending pull requests for the release are merged and have
cleared testing, the 'next\_release' branch is merged into 'develop'.
Check out 'develop' locally, pull the latest changes, merge them into 'release', apply a suitable
release tag (for historical reasons the tag starts with "patch_" followed by the date, and finally
push everything back to GitHub. Example:
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
@ -44,65 +56,315 @@ git pull
git checkout release
git pull
git merge --ff-only develop
git tag -s -m "LAMMPS feature release 19 November 2024" patch_19Nov2024
git tag -s -m "LAMMPS feature release 4 February 2025" patch_4Feb2025
git push git@github.com:lammps/lammps.git --tags develop release
```
Go to https://github.com/lammps/lammps/releases and create a new (draft) release page 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" dropdown list. Go to the bottom of
the list and select the "Set as pre-release" checkbox. The "Set as the latest release" button is
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.
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.
### Update download website, prepare pre-compiled packages, update packages to GitHub
### Prepare pre-compiled packages, update packages to GitHub
Publishing the release on GitHub will trigger the Temple Jenkins cluster to update
the https://docs.lammps.org/ website with the documentation for the new feature release
and it will create a tarball for download (which contains the translated manual).
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.
Build a fully static LAMMPS installation using a musl-libc cross-compiler, install into a
lammps-static folder, and create a tarball called lammps-linux-x86_64-19Nov2024.tar.gz (or using a
corresponding date with a future release) from the lammps-static folder and upload it to GitHub
#### 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.sif
apptainer shell fedora41_musl.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:
```
gh release upload patch_19Nov2024 ~/Downloads/lammps-linux-x86_64-19Nov2024.tar.gz
``` 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 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 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.
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).
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.
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).
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.
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.

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 \

15
README
View File

@ -23,17 +23,20 @@ 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
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 +45,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

14
cmake/CMakeLists.txt
View File

@ -209,7 +209,7 @@ endif()
########################################################################
# 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()
@ -225,6 +225,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)
@ -425,8 +431,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)
@ -930,7 +936,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

7
cmake/Modules/CodingStandard.cmake
View File

@ -1,11 +1,11 @@
# 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 .
@ -36,5 +36,4 @@ if(Python3_EXECUTABLE)
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/permissions.py -f .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Fix permission errors")
endif()
endif()

6
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)

26
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
@ -242,8 +260,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)

12
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)
# 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()

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

@ -57,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.5.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
set(KOKKOS_MD5 "4d832aa0284169d9e3fbae3165286bc6" 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)
@ -83,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.5.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)

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)

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")

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

@ -40,6 +40,13 @@ 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()

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

@ -1,6 +1,5 @@
# 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
set(PKG_KOKKOS ON CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_SERIAL ON CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_CUDA ON CACHE BOOL "" FORCE)

47
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
@ -35,6 +37,10 @@ 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:
@ -105,6 +112,8 @@ html: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJ
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 ;\
)
@ -116,25 +125,23 @@ html: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJ
@rm -rf html/PDF/.[sg]*
@echo "Build finished. The HTML pages are in doc/html."
fasthtml: 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
@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."
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
@(\
@ -188,6 +195,8 @@ pdf: xmlgen globbed-tocs $(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 ;\
)
@ -237,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.

6
doc/lammps.1
View File

@ -1,7 +1,7 @@
.TH LAMMPS "1" "19 November 2024" "2024-11-19"
.TH LAMMPS "1" "2 April 2025" "2025-04-02"
.SH NAME
.B LAMMPS
\- Molecular Dynamics Simulator. Version 19 November 2024
\- Molecular Dynamics Simulator. Version 2 April 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

23
doc/src/Build.rst
View File

@ -14,6 +14,29 @@ As an alternative, you can download a package with pre-built executables
or automated build trees, as described in the :doc:`Install <Install>`
section of the manual.
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.
.. toctree::
:maxdepth: 1

4
doc/src/Build_basics.rst
View File

@ -203,7 +203,7 @@ LAMMPS.
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. A C++11 compatible compiler is currently
required, but a transition to require C++17 is in progess and
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,
@ -329,7 +329,7 @@ LAMMPS.
either as a binary package or through compiling from source.
While a C++11 compatible compiler is currently sufficient to compile
LAMMPS, a transition to require C++17 is in progess and planned to
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.

13
doc/src/Build_cmake.rst
View File

@ -52,9 +52,9 @@ software or for people that want to modify or extend LAMMPS.
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:
@ -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

25
doc/src/Build_extras.rst
View File

@ -255,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``
@ -612,6 +611,9 @@ They must be specified in uppercase.
* - ZEN3
- HOST
- AMD Zen3 architecture
* - ZEN4
- HOST
- AMD Zen4 architecture
* - RISCV_SG2042
- HOST
- SG2042 (RISC-V) CPUs
@ -715,7 +717,7 @@ They must be specified in uppercase.
- GPU
- Intel GPU Ponte Vecchio
This list was last updated for version 4.5.1 of the Kokkos library.
This list was last updated for version 4.6.0 of the Kokkos library.
.. tabs::
@ -1139,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::
@ -1159,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

6
doc/src/Build_make.rst
View File

@ -30,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:

69
doc/src/Build_settings.rst
View File

@ -8,12 +8,13 @@ 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
@ -23,14 +24,15 @@ explains how to do this for building both with CMake and make.
.. _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 +42,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 +316,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 +327,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 +336,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 +510,8 @@ during a run.
.. _libcurl:
Support for downloading files
-----------------------------
Support for downloading files from the input
--------------------------------------------
.. versionadded:: 29Aug2024
@ -548,6 +554,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

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

3
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>`
@ -127,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>`

1
doc/src/Commands_compute.rst
View File

@ -178,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>`

3
doc/src/Commands_fix.rst
View File

@ -163,6 +163,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>`
@ -185,6 +187,7 @@ OPT.
* :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>`

2
doc/src/Commands_pair.rst
View File

@ -115,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>`

16
doc/src/Commands_removed.rst
View File

@ -1,7 +1,7 @@
Removed commands and packages
=============================
.. contents::
.. contents:: \
------
@ -87,7 +87,7 @@ Minimize style fire/old
.. deprecated:: 8Feb2023
Minimize style *fire/old* has been removed. Its functionality can be
reproduced with *fire* with specific options. Please see the
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
@ -170,6 +170,18 @@ performance characteristics on NVIDIA GPUs. Both, the KOKKOS
and the :ref:`GPU package <PKG-GPU>` are maintained
and allow running LAMMPS with GPU acceleration.
Compute atom/molecule
---------------------
.. deprecated:: 11 Dec2015
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.
Fix ave/spatial and fix ave/spatial/sphere
------------------------------------------

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

1
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

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

7
doc/src/Developer_notes.rst
View File

@ -7,7 +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.
.. contents::
.. contents:: Available notes
----
@ -270,7 +270,10 @@ There are multiple "signatures" that can be called:
- ``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). The output may also include the last input line *before* and
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

1029
doc/src/Errors_details.rst
View File

File diff suppressed because it is too large Load Diff

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

2
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 |
+-------------+------------------------------------------------------------------+

65
doc/src/Fortran.rst
View File

@ -323,6 +323,12 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
: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`
@ -956,6 +962,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
@ -1068,6 +1075,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
@ -1326,6 +1334,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
@ -1450,11 +1459,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
@ -2713,8 +2773,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

1
doc/src/Howto.rst
View File

@ -40,6 +40,7 @@ Settings howto
Howto_walls
Howto_nemd
Howto_dispersion
Howto_bulk2slab
Analysis howto
==============

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

6
doc/src/Howto_bpm.rst
View File

@ -42,12 +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. An optional multibody term can be used to adjust the network's
Poisson's ratio. Alternatively, the second bond style, :doc:`bond bpm/rotational
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

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.

10
doc/src/Howto_github.rst
View File

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

204
doc/src/Howto_lammps_gui.rst
View File

@ -1,35 +1,25 @@
Using LAMMPS-GUI
================
LAMMPS-GUI is a graphical text editor programmed using the `Qt Framework
<https://www.qt.io/>`_ and customized for editing LAMMPS input files. It
is linked to the :ref:`LAMMPS library <lammps_c_api>` and thus can run
LAMMPS directly using the contents of the editor's text buffer as input.
It *differs* from other known interfaces to LAMMPS in that it can
retrieve and display information from LAMMPS *while it is running*,
display visualizations created with the :doc:`dump image command
<dump_image>`, can launch the online LAMMPS documentation for known
LAMMPS commands and styles, and directly integrates with a collection
of LAMMPS tutorials (:ref:`Gravelle1 <Gravelle1>`).
This document describes **LAMMPS-GUI version 1.6**.
-----
LAMMPS-GUI is a graphical text editor customized for editing LAMMPS
input files that is linked to the :ref:`LAMMPS library <lammps_c_api>`
and thus can run LAMMPS directly using the contents of the editor's text
buffer as input. It can retrieve and display information from LAMMPS
while it is running, display visualizations created with the :doc:`dump
image command <dump_image>`, and is adapted specifically for editing
LAMMPS input files through text completion and reformatting, and linking
to the online LAMMPS documentation for known LAMMPS commands and styles.
.. contents::
.. note::
Pre-compiled, ready-to-use LAMMPS-GUI executables for Linux x86\_64
(Ubuntu 20.04LTS or later and compatible), macOS (version 11 aka Big
Sur or later), and Windows (version 10 or later) :ref:`are available
<lammps_gui_install>` for download. Non-MPI LAMMPS executables (as
``lmp``) for running LAMMPS from the command-line and :doc:`some
LAMMPS tools <Tools>` compiled executables are also included.
Also, the pre-compiled LAMMPS-GUI packages include the WHAM executables
from http://membrane.urmc.rochester.edu/content/wham/ for use with
LAMMPS tutorials.
The source code for LAMMPS-GUI is included in the LAMMPS source code
distribution and can be found in the ``tools/lammps-gui`` folder. It
can be compiled alongside LAMMPS when :doc:`compiling with CMake
<Build_cmake>`.
----
LAMMPS-GUI tries to provide an experience similar to what people
traditionally would have running LAMMPS using a command-line window and
@ -64,8 +54,8 @@ simple LAMMPS simulations. It is very suitable for tutorials on LAMMPS
since you only need to learn how to use a single program for most tasks
and thus time can be saved and people can focus on learning LAMMPS.
The tutorials at https://lammpstutorials.github.io/ are specifically
updated for use with LAMMPS-GUI and can their tutorial materials can
be downloaded and loaded directly from the GUI.
updated for use with LAMMPS-GUI and their tutorial materials can
be downloaded and edited directly from the GUI.
Another design goal is to keep the barrier low when replacing part of
the functionality of LAMMPS-GUI with external tools. That said, LAMMPS-GUI
@ -78,10 +68,31 @@ has some unique functionality that is not found elsewhere:
- monitoring of simulation progress
- interactive visualization using the :doc:`dump image <dump_image>`
command with the option to copy-paste the resulting settings
- automatic slide show generation from dump image out at runtime
- automatic plotting of thermodynamics data at runtime
- automatic slide show generation from dump image output at runtime
- automatic plotting of thermodynamic data at runtime
- inspection of binary restart files
.. admonition:: Download LAMMPS-GUI for your platform
:class: Hint
Pre-compiled, ready-to-use LAMMPS-GUI executables for Linux x86\_64
(Ubuntu 20.04LTS or later and compatible), macOS (version 11 aka Big
Sur or later), and Windows (version 10 or later) :ref:`are available
<lammps_gui_install>` for download. Non-MPI LAMMPS executables (as
``lmp``) for running LAMMPS from the command-line and :doc:`some
LAMMPS tools <Tools>` compiled executables are also included. Also,
the pre-compiled LAMMPS-GUI packages include the WHAM executables
from http://membrane.urmc.rochester.edu/content/wham/ for use with
LAMMPS tutorials documented in this paper (:ref:`Gravelle1
<Gravelle1>`).
The source code for LAMMPS-GUI is included in the LAMMPS source code
distribution and can be found in the ``tools/lammps-gui`` folder. It
can be compiled alongside LAMMPS when :doc:`compiling with CMake
<Build_cmake>`.
-----
The following text provides a detailed tour of the features and
functionality of LAMMPS-GUI. Suggestions for new features and
reports of bugs are always welcome. You can use the :doc:`the same
@ -92,9 +103,12 @@ channels as for LAMMPS itself <Errors_bugs>` for that purpose.
Installing Pre-compiled LAMMPS-GUI Packages
-------------------------------------------
LAMMPS-GUI is available as pre-compiled binary packages for Linux
x86\_64, macOS 11 and later, and Windows 10 and later. Alternately, it
can be compiled from source.
LAMMPS-GUI is available for download as pre-compiled binary packages for
Linux x86\_64 (Ubuntu 20.04LTS or later and compatible), macOS (version
11 aka Big Sur or later), and Windows (version 10 or later) from the
`LAMMPS release pages on GitHub <https://github.com/lammps/lammps/releases/>`_.
A backup download location is at https://download.lammps.org/static/
Alternately, LAMMPS-GUI can be compiled from source when building LAMMPS.
Windows 10 and later
^^^^^^^^^^^^^^^^^^^^
@ -349,8 +363,13 @@ data or both. The smoothing uses a `Savitzky-Golay convolution filter
window width (left) and order (right) parameters can be set in the boxes
next to the drop down menu. Default settings are 10 and 4 which means
that the smoothing window includes 10 points each to the left and the
right of the current data point and a fourth order polynomial is fit to
the data in the window.
right of the current data point for a total of 21 points and a fourth
order polynomial is fitted to the data in the window.
The "Title:" and "Y:" input boxes allow to edit the text shown as the
plot title and the y-axis label, respectively. The text entered in the
"Title:" box is applied to *all* charts, while the "Y:" text changes
only the y-axis label of the currently *selected* plot.
You can use the mouse to zoom into the graph (hold the left button and
drag to mark an area) or zoom out (right click) and you can reset the
@ -382,6 +401,11 @@ here you get the compounded data set starting with the last change of
output fields or timestep setting, while the export from the log will
contain *all* YAML output but *segmented* into individual runs.
The *Preferences* dialog has a *Charts* tab, where you can configure
multiple chart-related settings, like the default title, colors for the
graphs, default choice of the raw / smooth graph selection, and the
default chart graph size.
Image Slide Show
----------------
@ -461,11 +485,11 @@ correspond to (via their mass) and then colorize them in the image and
set their atom diameters accordingly. If this is not possible, for
instance when using reduced (= 'lj') :doc:`units <units>`, then
LAMMPS-GUI will check the current pair style and if it is a
Lennard-Jones type potential, it will extract the *sigma* parameter
for each atom type and assign atom diameters from those numbers.
For cases where atom diameters are not auto-detected, the *Atom size* field
can be edited and a suitable value set manually. The default value
is inferred from the x-direction lattice spacing.
Lennard-Jones type potential, it will extract the *sigma* parameter for
each atom type and assign atom diameters from those numbers. For cases
where atom diameters are not auto-detected, the *Atom size* field can be
edited and a suitable value set manually. The default value is inferred
from the x-direction lattice spacing.
If elements cannot be detected the default sequence of colors of the
:doc:`dump image <dump_image>` command is assigned to the different atom
@ -480,22 +504,31 @@ types.
|gui-image1| |gui-image2|
The default image size, some default image quality settings, the view
style and some colors can be changed in the *Preferences* dialog
window. From the image viewer window further adjustments can be made:
actual image size, high-quality (SSAO) rendering, anti-aliasing, view
style, display of box or axes, zoom factor. The view of the system can
be rotated horizontally and vertically. It is also possible to only
display the atoms within a group defined in the input script (default is
"all"). The image can also be re-centered on the center of mass of the
selected group. After each change, the image is rendered again and the
display updated. The small palette icon on the top left is colored
while LAMMPS is running to render the new image; it is grayed out when
LAMMPS is finished. When there are many atoms to render and high
quality images with anti-aliasing are requested, re-rendering may take
several seconds. From the *File* menu of the image window, the
current image can be saved to a file (keyboard shortcut `Ctrl-S`) or
copied to the clipboard (keyboard shortcut `Ctrl-C`) for pasting the
image into another application.
style and some colors can be changed in the *Preferences* dialog window.
From the image viewer window further adjustments can be made: actual
image size, high-quality (SSAO) rendering, anti-aliasing, view style,
display of box or axes, zoom factor. The view of the system can be
rotated horizontally and vertically.
It is also possible to display only the atoms within a :doc:`group
defined in the input script <group>` (default is "all"). The available
groups can be selected from the drop down list next to the "Group:"
label. Similarly, if there are :doc:`molecules defined in the input
<molecule>`, it is possible to select one of them (default is "none")
and visualize it (it will be shown at the center of the simulation box).
While a molecule is selected, the group selection is disabled. It can
be restored by selecting the molecule "none".
The image can also be re-centered on the center of mass of the selected
group. After each change, the image is rendered again and the display
updated. The small palette icon on the top left is colored while LAMMPS
is running to render the new image; it is grayed out when LAMMPS is
finished. When there are many atoms to render and high quality images
with anti-aliasing are requested, re-rendering may take several seconds.
From the *File* menu of the image window, the current image can be saved
to a file (keyboard shortcut `Ctrl-S`) or copied to the clipboard
(keyboard shortcut `Ctrl-C`) for pasting the image into another
application.
From the *File* menu it is also possible to copy the current
:doc:`dump image <dump_image>` and :doc:`dump_modify <dump_image>`
@ -720,6 +753,22 @@ output, charts, slide show, variables, or snapshot images. The
default settings for their visibility can be changed in the
*Preferences* dialog.
Tutorials
^^^^^^^^^
The *Tutorials* menu is to support the set of LAMMPS tutorials for
beginners and intermediate LAMMPS users documented in (:ref:`Gravelle1
<Gravelle1>`). From the drop down menu you can select which of the
eight currently available tutorial sessions you want to begin. This
opens a 'wizard' dialog where you can choose in which folder you want to
work, whether you want that folder to be wiped from *any* files, whether
you want to download the solutions files (which can be large) to a
``solution`` sub-folder, and whether you want the corresponding
tutorial's online version opened in your web browser. The dialog will
then start downloading the files requested (download progress is
reported in the status line) and load the first input file for the
selected session into LAMMPS-GUI.
About
^^^^^
@ -783,18 +832,21 @@ look of LAMMPS-GUI. The settings are grouped and each group is
displayed within a tab.
.. |guiprefs1| image:: JPG/lammps-gui-prefs-general.png
:width: 24%
:width: 19%
.. |guiprefs2| image:: JPG/lammps-gui-prefs-accel.png
:width: 24%
:width: 19%
.. |guiprefs3| image:: JPG/lammps-gui-prefs-image.png
:width: 24%
:width: 19%
.. |guiprefs4| image:: JPG/lammps-gui-prefs-editor.png
:width: 24%
:width: 19%
|guiprefs1| |guiprefs2| |guiprefs3| |guiprefs4|
.. |guiprefs5| image:: JPG/lammps-gui-prefs-charts.png
:width: 19%
|guiprefs1| |guiprefs2| |guiprefs3| |guiprefs4| |guiprefs5|
General Settings:
^^^^^^^^^^^^^^^^^
@ -848,6 +900,11 @@ General Settings:
the plots in the *Charts* window in milliseconds. The default is to
redraw the plots every 500 milliseconds. This is just for the drawing,
data collection is managed with the previous setting.
- *HTTPS proxy setting:* Allows to enter a URL for an HTTPS proxy. This
may be needed when the LAMMPS input contains :doc:`geturl commands <geturl>`
or for downloading tutorial files from the *Tutorials* menu. If the
``https_proxy`` environment variable was set externally, its value is
displayed but cannot be changed.
Accelerators:
^^^^^^^^^^^^^
@ -884,7 +941,7 @@ lists to select the background and box colors.
Editor Settings:
^^^^^^^^^^^^^^^^
This tab allows tweaking settings of the editor window. Specifically
This tab allows tweaking settings of the editor window. Specifically,
the amount of padding to be added to LAMMPS commands, types or type
ranges, IDs (e.g. for fixes), and names (e.g. for groups). The value
set is the minimum width for the text element and it can be chosen in
@ -896,6 +953,16 @@ the completion pop-up window, and whether auto-save mode is enabled.
In auto-save mode the editor buffer is saved before a run or before
exiting LAMMPS-GUI.
Charts Settings:
----------------
This tab allows tweaking settings of the *Charts* window. Specifically,
one can set the default chart title (if the title contains '%f' it will
be replaced with the name of the current input file), one can select
whether by default the raw data, the smoothed data or both will be
plotted, one can set the colors for the two lines, the default smoothing
parameters, and the default size of the chart graph in pixels.
-----------
Keyboard Shortcuts
@ -976,10 +1043,25 @@ available (On macOS use the Command key instead of Ctrl/Control).
- Ctrl+Shift+T
- LAMMPS Tutorial
Further editing keybindings `are documented with the Qt documentation
Further keybindings of the editor window `are documented with the Qt
documentation
<https://doc.qt.io/qt-5/qplaintextedit.html#editing-key-bindings>`_. In
case of conflicts the list above takes precedence.
All other windows only support a subset of keyboard shortcuts listed
above. Typically, the shortcuts `Ctrl-/` (Stop Run), `Ctrl-W` (Close
Window), and `Ctrl-Q` (Quit Application) are supported.
-------------
.. _Gravelle1:
**(Gravelle1)** Gravelle, Gissinger, Kohlmeyer, `arXiv:2503.14020 \[physics.comp-ph\] <https://doi.org/10.48550/arXiv.2503.14020>`_ (2025)
.. _Gravelle2:
**(Gravelle2)** Gravelle https://lammpstutorials.github.io/
.. raw:: latex
\clearpage

270
doc/src/Howto_moltemplate.rst
View File

@ -2,14 +2,18 @@ Moltemplate Tutorial
====================
In this tutorial, we are going to use the tool :ref:`Moltemplate
<moltemplate>` to set up a classical molecular dynamic simulation using
the :ref:`OPLS-AA force field <OPLSAA96>`. The first
task is to describe an organic compound and create a complete input deck
for LAMMPS. The second task is to map the OPLS-AA force field to a
molecular sample created with an external tool, e.g. PACKMOL, and
exported as a PDB file. The files used in this tutorial can be found
in the ``tools/moltemplate/tutorial-files`` folder of the LAMMPS
source code distribution.
<Moltemplate1>` from https://moltemplate.org/ to set up a classical
molecular dynamic simulation using the :ref:`OPLS-AA force field
<oplsaa2024>`. The first task is to describe an organic compound and
create a complete input deck for LAMMPS. The second task is to use
moltemplate to build a polymer. The third task is to map the OPLS-AA
force field to a molecular sample created with an external tool,
e.g. PACKMOL, and exported as a PDB file. The files used in this
tutorial can be found in the ``tools/moltemplate/tutorial-files`` folder
of the LAMMPS source code distribution.
Many more examples can be found here: https://moltemplate.org/examples.html
Simulating an organic solvent
"""""""""""""""""""""""""""""
@ -17,14 +21,13 @@ Simulating an organic solvent
This example aims to create a cubic box of the organic solvent
formamide.
The first step is to create a molecular topology in the
LAMMPS-template (LT) file format representing a single molecule, which
will be stored in a Moltemplate object called ``_FAM inherits OPLSAA {}``.
The first step is to create a molecular topology in the LAMMPS-template
(LT) file format representing a single molecule, which will be
stored in a Moltemplate object called ``_FAM inherits OPLSAA {}``.
This command states that the object ``_FAM`` is based on an existing
object called ``OPLSAA``, which contains OPLS-AA parameters, atom type
definitions, partial charges, masses and bond-angle rules for many organic
and biological compounds.
The atomic structure is the starting point to populate the command
``write('Data Atoms') {}``, which will write the ``Atoms`` section in the
LAMMPS data file. The OPLS-AA force field uses the ``atom_style full``,
@ -36,21 +39,23 @@ to the ``molID``, except that the same variable is used for the whole
molecule. The atom types are assigned using ``@``-type variables. The
assignment of atom types (e.g. ``@atom:177``, ``@atom:178``) is done using
the OPLS-AA atom types defined in the "In Charges" section of the file
``oplsaa.lt``, looking for a reasonable match with the description of the atom.
``oplsaa2024.lt``, looking for a reasonable match with the description of the atom.
The resulting file (``formamide.lt``) follows:
.. code-block:: bash
import /usr/local/moltemplate/moltemplate/force_fields/oplsaa2024.lt # defines OPLSAA
_FAM inherits OPLSAA {
# atomID molID atomType charge coordX coordY coordZ
write('Data Atoms') {
$atom:C00 $mol @atom:177 0.00 0.100 0.490 0.0
$atom:O01 $mol @atom:178 0.00 1.091 -0.250 0.0
$atom:N02 $mol @atom:179 0.00 -1.121 -0.181 0.0
$atom:H03 $mol @atom:182 0.00 -2.013 0.272 0.0
$atom:H04 $mol @atom:182 0.00 -1.056 -1.190 0.0
$atom:H05 $mol @atom:221 0.00 0.144 1.570 0.0
$atom:C00 $mol @atom:235 0.00 0.100 0.490 0.0
$atom:O01 $mol @atom:236 0.00 1.091 -0.250 0.0
$atom:N02 $mol @atom:237 0.00 -1.121 -0.181 0.0
$atom:H03 $mol @atom:240 0.00 -2.013 0.272 0.0
$atom:H04 $mol @atom:240 0.00 -1.056 -1.190 0.0
$atom:H05 $mol @atom:279 0.00 0.144 1.570 0.0
}
# A list of the bonds in the molecule:
@ -64,16 +69,17 @@ The resulting file (``formamide.lt``) follows:
}
}
You don't have to specify the charge in this example because they will
be assigned according to the atom type. Analogously, only a
"Data Bond List" section is needed as the atom type will determine the
bond type. The other bonded interactions (e.g. angles,
dihedrals, and impropers) will be automatically generated by
You don't have to specify the charge in this example because the OPLSAA
force-field assigns charge according to the atom type. (This is not true
when using other force fields.) A "Data Bond List" section is needed as
the atom type will determine the bond type. The other bonded interactions
(e.g. angles, dihedrals, and impropers) will be automatically generated by
Moltemplate.
If the simulation is non-neutral, or Moltemplate complains that you have
missing bond, angle, or dihedral types, this means at least one of your
atom types is incorrect.
If the simulation is not charge-neutral, or Moltemplate complains that
you have missing bond, angle, or dihedral types, this probably means that
at least one of your atom types is incorrect (or that perhaps there is no
suitable atom type currently defined in the ``oplsaa2024.lt`` file).
The second step is to create a master file with instructions to build a
starting structure and the LAMMPS commands to run an NPT simulation. The
@ -81,11 +87,9 @@ master file (``solv_01.lt``) follows:
.. code-block:: bash
# Import the force field.
import /usr/local/moltemplate/moltemplate/force_fields/oplsaa.lt
import formamide.lt # after oplsaa.lt, as it depends on it.
import formamide.lt # Defines "_FAM" and OPLSAA
# Create the input sample.
# Distribute the molecules on a 5x5x5 cubic grid with spacing 4.6
solv = new _FAM [5].move( 4.6, 0, 0)
[5].move( 0, 4.6, 0)
[5].move( 0, 0, 4.6)
@ -98,8 +102,11 @@ master file (``solv_01.lt``) follows:
-11.5 11.5 zlo zhi
}
# Note: The lines below in the "In Run" section are often omitted.
write_once("In Run"){
# Create an input deck for LAMMPS.
write_once("In Init"){
# Run an NPT simulation.
# Input variables.
variable run string solv_01 # output name
variable ts equal 1 # timestep
@ -109,12 +116,6 @@ master file (``solv_01.lt``) follows:
variable equi equal 5000 # Equilibration steps
variable prod equal 30000 # Production steps
# PBC (set them before the creation of the box).
boundary p p p
}
# Run an NPT simulation.
write_once("In Run"){
# Derived variables.
variable tcouple equal \$\{ts\}*100
variable pcouple equal \$\{ts\}*1000
@ -143,7 +144,7 @@ master file (``solv_01.lt``) follows:
unfix NPT
}
The first two commands insert the content of files ``oplsaa.lt`` and
The first two commands insert the content of files ``oplsaa2024.lt`` and
``formamide.lt`` into the master file. At this point, we can use the
command ``solv = new _FAM [N]`` to create N copies of a molecule of type
``_FAM``. In this case, we create an array of 5*5*5 molecules on a cubic
@ -153,21 +154,37 @@ the sample was created from scratch, we also specify the simulation box
size in the "Data Boundary" section.
The LAMMPS setting for the force field are specified in the file
``oplsaa.lt`` and are written automatically in the input deck. We also
``oplsaa2024.lt`` and are written automatically in the input deck. We also
specify the boundary conditions and a set of variables in
the "In Init" section. The remaining commands to run an NPT simulation
the "In Init" section.
The remaining commands to run an NPT simulation
are written in the "In Run" section. Note that in this script, LAMMPS
variables are protected with the escape character ``\`` to distinguish
them from Moltemplate variables, e.g. ``\$\{run\}`` is a LAMMPS
variable that is written in the input deck as ``${run}``.
(Note: Moltemplate can be slow to run, so you need to change you run
settings frequently, I recommended moving those commands (from "In Run")
out of your .lt files and into a separate file. Moltemplate creates a
file named ``run.in.EXAMPLE`` for this purpose. You can put your run
settings and fixes that file and then invoke LAMMPS using
``mpirun -np 4 lmp -in run.in.EXAMPLE`` instead.)
Compile the master file with:
.. code-block:: bash
moltemplate.sh -overlay-all solv_01.lt
moltemplate.sh solv_01.lt
cleanup_moltemplate.sh # <-- optional: see below
And execute the simulation with the following:
(Note: The optional "cleanup_moltemplate.sh" command deletes
unused atom types, which sometimes makes LAMMPS run faster.
But it does not work with many-body pair styles or dreiding-style h-bonds.
Fortunately most force fields, including OPLSAA, don't use those features.)
Then execute the simulation with the following:
.. code-block:: bash
@ -180,15 +197,116 @@ And execute the simulation with the following:
Snapshot of the sample at the beginning and end of the simulation.
Rendered with Ovito.
Building a simple polymer
"""""""""""""""""""""""""
Moltemplate is particularly useful for building polymers (and other molecules
with sub-units). As an simple example, consider butane:
.. figure:: JPG/butane.jpg
The ``butane.lt`` file below defines Butane as a polymer containing
4 monomers (of type ``CH3``, ``CH2``, ``CH2``, ``CH3``).
.. code-block:: bash
import /usr/local/moltemplate/moltemplate/force_fields/oplsaa2024.lt # defines OPLSAA
CH3 inherits OPLSAA {
# atomID molID atomType charge coordX coordY coordZ
write("Data Atoms") {
$atom:c $mol:... @atom:54 0.0 0.000000 0.4431163 0.000000
$atom:h1 $mol:... @atom:60 0.0 0.000000 1.0741603 0.892431
$atom:h2 $mol:... @atom:60 0.0 0.000000 1.0741603 -0.892431
$atom:h3 $mol:... @atom:60 0.0 -0.892431 -0.1879277 0.000000
}
# (Using "$mol:..." indicates this object ("CH3") is part of a larger
# molecule. Moltemplate will share the molecule-ID with that molecule.)
# A list of the bonds within the "CH3" molecular sub-unit:
# BondID AtomID1 AtomID2
write('Data Bond List') {
$bond:ch1 $atom:c $atom:h1
$bond:ch2 $atom:c $atom:h2
$bond:ch3 $atom:c $atom:h3
}
}
CH2 inherits OPLSAA {
# atomID molID atomType charge coordX coordY coordZ
write("Data Atoms") {
$atom:c $mol:... @atom:57 0.0 0.000000 0.4431163 0.000000
$atom:h1 $mol:... @atom:60 0.0 0.000000 1.0741603 0.892431
$atom:h2 $mol:... @atom:60 0.0 0.000000 1.0741603 -0.892431
}
# A list of the bonds within the "CH2" molecular sub-unit:
# BondID AtomID1 AtomID2
write('Data Bond List') {
$bond:ch1 $atom:c $atom:h1
$bond:ch2 $atom:c $atom:h2
}
}
Butane inherits OPLSAA {
create_var {$mol} # optional:force all monomers to share the same molecule-ID
# - Create 4 monomers
# - Move them along the X axis using ".move()",
# - Rotate them 180 degrees with respect to the previous monomer
monomer1 = new CH3
monomer2 = new CH2.rot(180,1,0,0).move(1.2533223,0,0)
monomer3 = new CH2.move(2.5066446,0,0)
monomer4 = new CH3.rot(180,0,0,1).move(3.7599669,0,0)
# A list of the bonds connecting different monomers together:
write('Data Bond List') {
$bond:b1 $atom:monomer1/c $atom:monomer2/c
$bond:b2 $atom:monomer2/c $atom:monomer3/c
$bond:b3 $atom:monomer3/c $atom:monomer4/c
}
}
Again, you don't have to specify the charge in this example because OPLSAA
assigns charges according to the atom type.
This ``Butane`` object is a molecule which can be used anywhere other molecules
can be used. (You can arrange ``Butane`` molecules on a lattice, as we did previously.
You can also modify individual butane molecules by adding or deleting atoms or bonds.
You can add bonds between specific butane molecules or use ``Butane`` as a
sub-unit to define even larger molecules. See the moltemplate manual for details.)
How to build a complex polymer
""""""""""""""""""""""""""""""""""""""""""
A similar procedure can be used to create more complicated polymers,
such as the NIPAM polymer example shown below. For details, see:
https://github.com/jewettaij/moltemplate/tree/master/examples/all_atom/force_field_OPLSAA/NIPAM_polymer+water+ions
Mapping an existing structure
"""""""""""""""""""""""""""""
Another helpful way to use Moltemplate is mapping an existing molecular
sample to a force field. This is useful when a complex sample is
assembled from different simulations or created with specialized
software (e.g. PACKMOL). As in the previous example, all molecular
species in the sample must be defined using single-molecule Moltemplate
objects. For this example, we use a short polymer in a box containing
sample to a force field. This is useful when a complex sample is assembled
from different simulations or created with specialized software (e.g. PACKMOL).
(Note: The previous link shows how to build this entire system from scratch
using only moltemplate. However here we will assume instead that we obtained
a PDB file for this system using PACKMOL.)
As in the previous examples, all molecular species in the sample
are defined using single-molecule Moltemplate objects.
For this example, we use a short polymer in a box containing
water molecules and ions in the PDB file ``model.pdb``.
It is essential to understand that the order of atoms in the PDB file
@ -246,25 +364,25 @@ The resulting master LT file defining short annealing at a fixed volume
.. code-block:: bash
# Use the OPLS-AA force field for all species.
import /usr/local/moltemplate/moltemplate/force_fields/oplsaa.lt
import /usr/local/moltemplate/moltemplate/force_fields/oplsaa2024.lt
import PolyNIPAM.lt
# Define the SPC water and ions as in the OPLS-AA
Ca inherits OPLSAA {
write("Data Atoms"){
$atom:a1 $mol:. @atom:354 0.0 0.00000 0.00000 0.000000
$atom:a1 $mol:. @atom:412 0.0 0.00000 0.00000 0.000000
}
}
Cl inherits OPLSAA {
write("Data Atoms"){
$atom:a1 $mol:. @atom:344 0.0 0.00000 0.00000 0.000000
$atom:a1 $mol:. @atom:401 0.0 0.00000 0.00000 0.000000
}
}
SPC inherits OPLSAA {
write("Data Atoms"){
$atom:O $mol:. @atom:76 0. 0.0000000 0.00000 0.000000
$atom:H1 $mol:. @atom:77 0. 0.8164904 0.00000 0.5773590
$atom:H2 $mol:. @atom:77 0. -0.8164904 0.00000 0.5773590
$atom:O $mol:. @atom:9991 0. 0.0000000 0.00000 0.0000000
$atom:H1 $mol:. @atom:9990 0. 0.8164904 0.00000 0.5773590
$atom:H2 $mol:. @atom:9990 0. -0.8164904 0.00000 0.5773590
}
write("Data Bond List") {
$bond:OH1 $atom:O $atom:H1
@ -285,8 +403,15 @@ The resulting master LT file defining short annealing at a fixed volume
0 26 zlo zhi
}
# Define the input variables.
write_once("In Init"){
boundary p p p # "p p p" is the default. This line is optional.
neighbor 3 bin # (This line is also optional in this example.)
}
# Note: The lines below in the "In Run" section are often omitted.
# Run an NVT simulation.
write_once("In Run"){
# Input variables.
variable run string sample01 # output name
variable ts equal 2 # timestep
@ -294,13 +419,6 @@ The resulting master LT file defining short annealing at a fixed volume
variable p equal 1. # equilibrium pressure
variable equi equal 30000 # equilibration steps
# PBC (set them before the creation of the box).
boundary p p p
neighbor 3 bin
}
# Run an NVT simulation.
write_once("In Run"){
# Set the output.
thermo 1000
thermo_style custom step etotal evdwl ecoul elong ebond eangle &
@ -314,8 +432,8 @@ The resulting master LT file defining short annealing at a fixed volume
write_data \$\{run\}.min
# Set the constrains.
group watergroup type @atom:76 @atom:77
fix 0 watergroup shake 0.0001 10 0 b @bond:042_043 a @angle:043_042_043
group watergroup type @atom:9991 @atom:9990
fix 0 watergroup shake 0.0001 10 0 b @bond:spcO_spcH a @angle:spcH_spcO_spcH
# Short annealing.
timestep \$\{ts\}
@ -327,7 +445,7 @@ The resulting master LT file defining short annealing at a fixed volume
In this example, the water model is SPC and it is defined in the
``oplsaa.lt`` file with atom types ``@atom:76`` and ``@atom:77``. For
``oplsaa2024.lt`` file with atom types ``@atom:9991`` and ``@atom:9990``. For
water we also use the ``group`` and ``fix shake`` commands with
Moltemplate ``@``-type variables, to ensure consistency with the
numerical values assigned during compilation. To identify the bond and
@ -336,19 +454,20 @@ are:
.. code-block:: bash
replace{ @atom:76 @atom:76_b042_a042_d042_i042 }
replace{ @atom:77 @atom:77_b043_a043_d043_i043 }
replace{ @atom:9991 @atom:9991_bspcO_aspcO_dspcO_ispcO }
replace{ @atom:9990 @atom:9990_bspcH_aspcH_dspcH_ispcH }
From which we can identify the following "Data Bonds By Type":
``@bond:042_043 @atom:*_b042*_a*_d*_i* @atom:*_b043*_a*_d*_i*`` and
"Data Angles By Type": ``@angle:043_042_043 @atom:*_b*_a043*_d*_i*
@atom:*_b*_a042*_d*_i* @atom:*_b*_a043*_d*_i*``
``@bond:spcO_spcH @atom:*_bspcO*_a*_d*_i* @atom:*_bspcH*_a*_d*_i*``
and "Data Angles By Type":
``@angle:spcH_spcO_spcH @atom:*_b*_aspcH*_d*_i* @atom:*_b*_aspcO*_d*_i* @atom:*_b*_aspcH*_d*_i*``
Compile the master file with:
.. code-block:: bash
moltemplate.sh -overlay-all -pdb model.pdb sample01.lt
moltemplate.sh -pdb model.pdb sample01.lt
cleanup_moltemplate.sh
And execute the simulation with the following:
@ -363,8 +482,13 @@ And execute the simulation with the following:
Sample visualized with Ovito loading the trajectory into the DATA
file written after minimization.
------------
.. _OPLSAA96:
.. _oplsaa2024:
**(OPLS-AA)** Jorgensen, Maxwell, Tirado-Rives, J Am Chem Soc, 118(45), 11225-11236 (1996).
**(OPLS-AA)** Jorgensen, W.L., Ghahremanpour, M.M., Saar, A., Tirado-Rives, J., J. Phys. Chem. B, 128(1), 250-262 (2024).
.. _Moltemplate1:
**(Moltemplate)** Jewett et al., J. Mol. Biol., 433(11), 166841 (2021)

8
doc/src/Howto_peri.rst
View File

@ -197,7 +197,7 @@ The LPS model has a force scalar state
.. math::
\underline{t} = \frac{3K\theta}{m}\underline{\omega}\,\underline{x} +
\alpha \underline{\omega}\,\underline{e}^{\rm d}, \qquad\qquad\textrm{(3)}
\alpha \underline{\omega}\,\underline{e}^\mathrm{d}, \qquad\qquad\textrm{(3)}
with :math:`K` the bulk modulus and :math:`\alpha` related to the shear
modulus :math:`G` as
@ -242,14 +242,14 @@ scalar state are defined, respectively, as
.. math::
\underline{e}^{\rm i}=\frac{\theta \underline{x}}{3}, \qquad
\underline{e}^{\rm d} = \underline{e}- \underline{e}^{\rm i},
\underline{e}^\mathrm{i}=\frac{\theta \underline{x}}{3}, \qquad
\underline{e}^\mathrm{d} = \underline{e}- \underline{e}^\mathrm{i},
where the arguments of the state functions and the vectors on which they
operate are omitted for simplicity. We note that the LPS model is linear
in the dilatation :math:`\theta`, and in the deviatoric part of the
extension :math:`\underline{e}^{\rm d}`.
extension :math:`\underline{e}^\mathrm{d}`.
.. note::

31
doc/src/Howto_python.rst
View File

@ -62,17 +62,17 @@ with :ref:`PNG, JPEG and FFMPEG output support <graphics>` enabled.
cd $LAMMPS_DIR/src
# add packages if necessary
# add LAMMPS packages if necessary
make yes-MOLECULE
make yes-PYTHON
# compile shared library using Makefile
make mpi mode=shlib LMP_INC="-DLAMMPS_PNG -DLAMMPS_JPEG -DLAMMPS_FFMPEG" JPG_LIB="-lpng -ljpeg"
Step 2: Installing the LAMMPS Python package
""""""""""""""""""""""""""""""""""""""""""""
Step 2: Installing the LAMMPS Python module
"""""""""""""""""""""""""""""""""""""""""""
Next install the LAMMPS Python package into your current Python installation with:
Next install the LAMMPS Python module into your current Python installation with:
.. code-block:: bash
@ -89,6 +89,29 @@ privileges) or into your personal Python module folder.
Recompiling the shared library requires re-installing the Python
package.
.. _externally_managed:
.. admonition:: Handling an "externally-managed-environment" Error
:class: Hint
Some Python installations made through Linux distributions
(e.g. Ubuntu 24.04LTS or later) will prevent installing the LAMMPS
Python module into a system folder or a corresponding folder of the
individual user as attempted by ``make install-python`` with an error
stating that an *externally managed* python installation must be only
managed by the same package package management tool. This is an
optional setting, so not all Linux distributions follow it currently
(Spring 2025). The reasoning and explanations for this error can be
found in the `Python Packaging User Guide
<https://packaging.python.org/en/latest/specifications/externally-managed-environments/>`_
These guidelines suggest to create a virtual environment and install
the LAMMPS Python module there (see below). This is generally a good
idea and the LAMMPS developers recommend this, too. If, however, you
want to proceed and install the LAMMPS Python module regardless, you
can install the "wheel" file (see above) manually with the ``pip``
command by adding the ``--break-system-packages`` flag.
Installation inside of a virtual environment
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

24
doc/src/Howto_triclinic.rst
View File

@ -249,23 +249,23 @@ as follows:
.. math::
a = & {\rm lx} \\
b^2 = & {\rm ly}^2 + {\rm xy}^2 \\
c^2 = & {\rm lz}^2 + {\rm xz}^2 + {\rm yz}^2 \\
\cos{\alpha} = & \frac{{\rm xy}*{\rm xz} + {\rm ly}*{\rm yz}}{b*c} \\
\cos{\beta} = & \frac{\rm xz}{c} \\
\cos{\gamma} = & \frac{\rm xy}{b} \\
a = & \mathrm{lx} \\
b^2 = & \mathrm{ly}^2 + \mathrm{xy}^2 \\
c^2 = & \mathrm{lz}^2 + \mathrm{xz}^2 + \mathrm{yz}^2 \\
\cos{\alpha} = & \frac{\mathrm{xy}*\mathrm{xz} + \mathrm{ly}*\mathrm{yz}}{b*c} \\
\cos{\beta} = & \frac{\mathrm{xz}}{c} \\
\cos{\gamma} = & \frac{\mathrm{xy}}{b} \\
The inverse relationship can be written as follows:
.. math::
{\rm lx} = & a \\
{\rm xy} = & b \cos{\gamma} \\
{\rm xz} = & c \cos{\beta}\\
{\rm ly}^2 = & b^2 - {\rm xy}^2 \\
{\rm yz} = & \frac{b*c \cos{\alpha} - {\rm xy}*{\rm xz}}{\rm ly} \\
{\rm lz}^2 = & c^2 - {\rm xz}^2 - {\rm yz}^2 \\
\mathrm{lx} = & a \\
\mathrm{xy} = & b \cos{\gamma} \\
\mathrm{xz} = & c \cos{\beta}\\
\mathrm{ly}^2 = & b^2 - \mathrm{xy}^2 \\
\mathrm{yz} = & \frac{b*c \cos{\alpha} - \mathrm{xy}*\mathrm{xz}}{\mathrm{ly}} \\
\mathrm{lz}^2 = & c^2 - \mathrm{xz}^2 - \mathrm{yz}^2 \\
The values of *a*, *b*, *c*, :math:`\alpha` , :math:`\beta`, and
:math:`\gamma` can be printed out or accessed by computes using the

1
doc/src/Install_git.rst
View File

@ -52,6 +52,7 @@ your machine and "release" is one of the 3 branches listed above.
between them at any time using "git checkout <branch name>".)
.. admonition:: Saving time and disk space when using ``git clone``
:class: note
The complete git history of the LAMMPS project is quite large because
it contains the entire commit history of the project since fall 2006,

3
doc/src/Install_mac.rst
View File

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

14
doc/src/Intro_overview.rst
View File

@ -20,13 +20,21 @@ acceleration.
.. _lws: https://www.lammps.org
.. _omp: https://www.openmp.org
LAMMPS is written in C++ and requires a compiler that is at least
compatible with the C++-11 standard. Earlier versions were written in
F77, F90, and C++-98. See the `History page
LAMMPS is written in C++ and currently requires a compiler that is at
least compatible with the C++-11 standard. Earlier versions were
written in F77, F90, and C++-98. See the `History page
<https://www.lammps.org/history.html>`_ of the website for details. All
versions can be downloaded as source code from the `LAMMPS website
<lws_>`_.
Through a :ref:`C language API <lammps_c_api>` LAMMPS functionality can
be accessed and managed from other programming languages rather than
running the LAMMPS executable. Ready to use modules for :ref:`Python
<lammps_python_api>` and :ref:`Fortran <lammps_fortran_api>` exist, and
an example :ref:`SWIG interface file <swig>` as well as example C files
for dynamically loading LAMMPS as a shared library into other
executables are provided.
LAMMPS is designed to be easy to modify or extend with new capabilities,
such as new force fields, atom types, boundary conditions, or
diagnostics. See the :doc:`Modify` section of for more details.

14
doc/src/Intro_portability.rst
View File

@ -13,10 +13,14 @@ Programming language standards
Most of the C++ code currently requires a compiler compatible with the
C++11 standard, the KOKKOS package currently requires C++17. Most of
the Python code is written to be compatible with Python 3.5 or later or
Python 2.7. Some Python scripts *require* Python 3 and a few others
still need to be ported from Python 2 to Python 3.
the Python code is written to be compatible with Python 3.6 or later.
.. deprecated:: 2Apr2025
Python 2.x is no longer supported and trying to use it, e.g. for the
LAMMPS Python module should result in an error. If you come across
some part of the LAMMPS distribution that is not (yet) compatible with
Python 3, please notify the LAMMPS developers.
Build systems
^^^^^^^^^^^^^
@ -24,8 +28,8 @@ Build systems
LAMMPS can be compiled from source code using a (traditional) build
system based on shell scripts, a few shell utilities (grep, sed, cat,
tr) and the GNU make program. This requires running within a Bourne
shell (``/bin/sh``). Alternatively, a build system with different back ends
can be created using CMake. CMake must be at least version 3.16.
shell (``/bin/sh``). Alternatively, a build system with different back
ends can be created using CMake. CMake must be at least version 3.16.
Operating systems
^^^^^^^^^^^^^^^^^

BIN
doc/src/JPG/PolyNIPAM.jpg
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 40 KiB

After

Width:  |  Height:  |  Size: 94 KiB

BIN
doc/src/JPG/butane.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

BIN
doc/src/JPG/lammps-gui-chart.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 106 KiB

After

Width:  |  Height:  |  Size: 117 KiB

BIN
doc/src/JPG/lammps-gui-prefs-accel.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 32 KiB

After

Width:  |  Height:  |  Size: 31 KiB

BIN
doc/src/JPG/lammps-gui-prefs-charts.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 49 KiB

BIN
doc/src/JPG/lammps-gui-prefs-editor.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 39 KiB

After

Width:  |  Height:  |  Size: 39 KiB

BIN
doc/src/JPG/lammps-gui-prefs-general.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 59 KiB

After

Width:  |  Height:  |  Size: 57 KiB

BIN
doc/src/JPG/lammps-gui-prefs-image.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 44 KiB

After

Width:  |  Height:  |  Size: 44 KiB

BIN
doc/src/JPG/rhodo-both.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 568 KiB

6
doc/src/Library_add.rst
View File

@ -19,9 +19,9 @@ there are now a few requirements for including new changes or extensions.
be added.
- New features should also be implemented and documented not just
for the C interface, but also the Python and Fortran interfaces.
- All additions should work and be compatible with ``-DLAMMPS_BIGBIG``,
``-DLAMMPS_SMALLBIG``, ``-DLAMMPS_SMALLSMALL`` as well as when
compiling with and without MPI support.
- All additions should work and be compatible with
``-DLAMMPS_BIGBIG``, ``-DLAMMPS_SMALLBIG`` as well as when compiling
with and without MPI support.
- The ``library.h`` file should be kept compatible to C code at
a level similar to C89. Its interfaces may not reference any
custom data types (e.g. ``bigint``, ``tagint``, and so on) that

18
doc/src/Library_objects.rst
View File

@ -13,6 +13,9 @@ fixes, or variables in LAMMPS using the following functions:
- :cpp:func:`lammps_set_internal_variable`
- :cpp:func:`lammps_variable_info`
- :cpp:func:`lammps_eval`
- :cpp:func:`lammps_clearstep_compute`
- :cpp:func:`lammps_addstep_compute_all`
- :cpp:func:`lammps_addstep_compute`
-----------------------
@ -61,6 +64,21 @@ fixes, or variables in LAMMPS using the following functions:
-----------------------
.. doxygenfunction:: lammps_clearstep_compute
:project: progguide
-----------------------
.. doxygenfunction:: lammps_addstep_compute_all
:project: progguide
-----------------------
.. doxygenfunction:: lammps_addstep_compute
:project: progguide
-----------------------
.. doxygenenum:: _LMP_DATATYPE_CONST
.. doxygenenum:: _LMP_STYLE_CONST

6
doc/src/Library_utility.rst
View File

@ -20,6 +20,7 @@ functions. They do not directly call the LAMMPS library.
- :cpp:func:`lammps_force_timeout`
- :cpp:func:`lammps_has_error`
- :cpp:func:`lammps_get_last_error_message`
- :cpp:func:`lammps_set_show_error`
- :cpp:func:`lammps_python_api_version`
The :cpp:func:`lammps_free` function is a clean-up function to free
@ -110,6 +111,11 @@ where such memory buffers were allocated that require the use of
-----------------------
.. doxygenfunction:: lammps_set_show_error
:project: progguide
-----------------------
.. doxygenfunction:: lammps_python_api_version
:project: progguide

51
doc/src/Manual_version.rst
View File

@ -2,9 +2,15 @@ What does a LAMMPS version mean
-------------------------------
The LAMMPS "version" is the date when it was released, such as 1 May
2014. LAMMPS is updated continuously, and we aim to keep it working
correctly and reliably at all times. Also, several variants of static
code analysis are run regularly to maintain or improve the overall code
2014. LAMMPS is updated continuously, and with the help of extensive
automated testing (mostly applied *before* changes are included) we aim
to keep it working correctly and reliably at all times, but there also
are regular *feature releases* with new and expanded functionality, and
there are designated *stable releases* that receive updates with bug
fixes back-ported from the development branch.
In addition to automated testing, several variants of static code
analysis are run regularly to maintain or improve the overall code
quality, consistency, and compliance with programming standards, best
practices and style conventions. You can follow its development in a
public `git repository on GitHub <https://github.com/lammps/lammps>`_.
@ -19,17 +25,18 @@ Identifying the Version
The version date is printed to the screen and log file every time you
run LAMMPS. There also is an indication, if a LAMMPS binary was
compiled from version with modifications **after** a release.
It is also visible in the file src/version.h and in the LAMMPS directory
name created when you unpack a downloaded tarball. And it is on the
first page of the :doc:`manual <Manual>`.
compiled from version with modifications **after** a release, either
from the development version or the maintenance version of the last
stable release. It is also visible in the file src/version.h and in the
LAMMPS directory name created when you unpack a downloaded tarball. And
it is on the first page of the :doc:`manual <Manual>`.
* If you browse the HTML pages of the online version of the LAMMPS
manual, they will by default describe the most current feature release
version of LAMMPS. In the navigation bar on the bottom left, there is
the option to view instead the documentation for the most recent
*stable* version or the documentation corresponding to the state of
the development branch.
the development branch *develop*.
* If you browse the HTML pages included in your downloaded tarball, they
describe the version you have, which may be older than the online
version.
@ -48,8 +55,9 @@ Development
Modifications of the LAMMPS source code (like bug fixes, code
refactoring, updates to existing features, or addition of new features)
are organized into pull requests. Pull requests will be merged into the
*develop* branch of the git repository after they pass automated testing
and code review by the LAMMPS developers.
*develop* branch of the LAMMPS git repository on GitHub after they pass
automated testing and code review by :doc:`core LAMMPS developers
<Intro_authors>`.
Feature Releases
""""""""""""""""
@ -62,8 +70,7 @@ repository is updated with every such *feature release* and a tag in the
format ``patch_1May2014`` is added. A summary of the most important
changes of these releases for the current year are posted on `this
website page <https://www.lammps.org/bug.html>`_. More detailed release
notes are `available on GitHub
<https://github.com/lammps/lammps/releases/>`_.
notes are `available on GitHub <https://github.com/lammps/lammps/releases/>`_.
Stable Releases
"""""""""""""""
@ -71,18 +78,18 @@ Stable Releases
About once a year, we release a *stable release* version of LAMMPS.
This is done after a "stabilization period" where we apply only bug
fixes and small, non-intrusive changes to the *develop* branch but no
new features. At the same time, the code is subjected to more detailed
and thorough manual testing than the default automated testing.
After such a *stable release*, both the *release* and the *stable*
branches are updated and two tags are applied, a ``patch_1May2014`` format
and a ``stable_1May2014`` format tag.
new features to the core code. At the same time, the code is subjected
to more detailed and thorough manual testing than the default automated
testing. After such a *stable release*, both the *release* and the
*stable* branches are updated and two tags are applied, a
``patch_1May2014`` format and a ``stable_1May2014`` format tag.
Stable Release Updates
""""""""""""""""""""""
Between *stable releases*, we collect bug fixes and updates back-ported
from the *develop* branch in a branch called *maintenance*. From the
*maintenance* branch we make occasional *stable update releases* and
update the *stable* branch accordingly. The first update to the
``stable_1May2014`` release would be tagged as
Between *stable releases*, we collect bug fixes and updates that are
back-ported from the *develop* branch in a branch called *maintenance*.
From the *maintenance* branch we make occasional *stable update
releases* and update the *stable* branch accordingly. The first update
to the ``stable_1May2014`` release would be tagged as
``stable_1May2014_update1``. These updates contain no new features.

35
doc/src/Modify_compute.rst
View File

@ -1,19 +1,21 @@
Compute styles
==============
Classes that compute scalar and vector quantities like temperature
and the pressure tensor, as well as classes that compute per-atom
quantities like kinetic energy and the centro-symmetry parameter
are derived from the Compute class. New styles can be created
to add new calculations to LAMMPS.
Classes that compute scalar and vector quantities like temperature and
the pressure tensor, as well as classes that compute per-atom quantities
like kinetic energy and the centro-symmetry parameter are derived from
the Compute class. New styles can be created to add new calculations to
LAMMPS.
Compute_temp.cpp is a simple example of computing a scalar
temperature. Compute_ke_atom.cpp is a simple example of computing
per-atom kinetic energy.
The ``src/compute_temp.cpp`` file is a simple example of computing a
scalar temperature. The ``src/compute_ke_atom.cpp`` file is a simple
example of computing per-atom kinetic energy.
Here is a brief description of methods you define in your new derived
class. See compute.h for details.
class. See ``src/compute.h`` for additional details.
+-----------------------+------------------------------------------------------------------+
| post_constructor | perform tasks that cannot be run in the constructor (optional) |
+-----------------------+------------------------------------------------------------------+
| init | perform one time setup (required) |
+-----------------------+------------------------------------------------------------------+
@ -50,10 +52,11 @@ class. See compute.h for details.
| memory_usage | tally memory usage (optional) |
+-----------------------+------------------------------------------------------------------+
Tally-style computes are a special case, as their computation is done
in two stages: the callback function is registered with the pair style
and then called from the Pair::ev_tally() function, which is called for
each pair after force and energy has been computed for this pair. Then
the tallied values are retrieved with the standard compute_scalar or
compute_vector or compute_peratom methods. The :doc:`compute styles in the TALLY package <compute_tally>`
provide *examples* for utilizing this mechanism.
Tally-style computes are a special case, as their computation is done in
two stages: the callback function is registered with the pair style and
then called from the Pair::ev_tally() function, which is called for each
pair after force and energy has been computed for this pair. Then the
tallied values are retrieved with the standard compute_scalar or
compute_vector or compute_peratom methods. The :doc:`compute styles in
the TALLY package <compute_tally>` provide *examples* for utilizing this
mechanism.

57
doc/src/Modify_fix.rst
View File

@ -1,23 +1,25 @@
Fix styles
==========
In LAMMPS, a "fix" is any operation that is computed during
timestepping that alters some property of the system. Essentially
everything that happens during a simulation besides force computation,
neighbor list construction, and output, is a "fix". This includes
time integration (update of coordinates and velocities), force
constraints or boundary conditions (SHAKE or walls), and diagnostics
(compute a diffusion coefficient). New styles can be created to add
new options to LAMMPS.
In LAMMPS, a "fix" is any operation that is computed during timestepping
that alters some property of the system. Essentially everything that
happens during a simulation besides force computation, neighbor list
construction, and output, is a "fix". This includes time integration
(update of coordinates and velocities), force constraints or boundary
conditions (SHAKE or walls), and diagnostics (compute a diffusion
coefficient). New styles can be created to add new options to LAMMPS.
Fix_setforce.cpp is a simple example of setting forces on atoms to
prescribed values. There are dozens of fix options already in LAMMPS;
choose one as a template that is similar to what you want to
implement.
The file ``src/fix_setforce.cpp`` is a simple example of setting forces
on atoms to prescribed values. There are dozens of fix options already
in LAMMPS; choose one as a template that is similar to what you want to
implement. There also is a detailed discussion of :doc:`how to write
new fix styles <Developer_write_fix>` in LAMMPS.
Here is a brief description of methods you can define in your new
derived class. See fix.h for details.
derived class. See ``src/fix.h`` for additional details.
+---------------------------+--------------------------------------------------------------------------------------------+
| post_constructor | perform tasks that cannot be run in the constructor (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| setmask | determines when the fix is called during the timestep (required) |
+---------------------------+--------------------------------------------------------------------------------------------+
@ -130,10 +132,11 @@ derived class. See fix.h for details.
Typically, only a small fraction of these methods are defined for a
particular fix. Setmask is mandatory, as it determines when the fix
will be invoked during the timestep. Fixes that perform time
integration (\ *nve*, *nvt*, *npt*\ ) implement initial_integrate() and
final_integrate() to perform velocity Verlet updates. Fixes that
constrain forces implement post_force().
will be invoked during :doc:`the evolution of a timestep
<Developer_flow>`. Fixes that perform time integration (\ *nve*, *nvt*,
*npt*\ ) implement initial_integrate() and final_integrate() to perform
velocity Verlet updates. Fixes that constrain forces implement
post_force().
Fixes that perform diagnostics typically implement end_of_step(). For
an end_of_step fix, one of your fix arguments must be the variable
@ -143,13 +146,13 @@ is the first argument the fix defines (after the ID, group-ID, style).
If the fix needs to store information for each atom that persists from
timestep to timestep, it can manage that memory and migrate the info
with the atoms as they move from processors to processor by
implementing the grow_arrays, copy_arrays, pack_exchange, and
unpack_exchange methods. Similarly, the pack_restart and
unpack_restart methods can be implemented to store information about
the fix in restart files. If you wish an integrator or force
constraint fix to work with rRESPA (see the :doc:`run_style <run_style>`
command), the initial_integrate, post_force_integrate, and
final_integrate_respa methods can be implemented. The thermo method
enables a fix to contribute values to thermodynamic output, as printed
quantities and/or to be summed to the potential energy of the system.
with the atoms as they move from processors to processor by implementing
the grow_arrays, copy_arrays, pack_exchange, and unpack_exchange
methods. Similarly, the pack_restart and unpack_restart methods can be
implemented to store information about the fix in restart files. If you
wish an integrator or force constraint fix to work with rRESPA (see the
:doc:`run_style <run_style>` command), the initial_integrate,
post_force_integrate, and final_integrate_respa methods can be
implemented. The thermo method enables a fix to contribute values to
thermodynamic output, as printed quantities and/or to be summed to the
potential energy of the system.

6
doc/src/Modify_requirements.rst
View File

@ -189,10 +189,8 @@ of the contribution. As of January 2023, all previously included
Fortran code for the LAMMPS executable has been replaced by equivalent
C++ code.
Python code must be compatible with Python 3.5 and later. Large parts
of LAMMPS (including the :ref:`PYTHON package <PKG-PYTHON>`) are also
compatible with Python 2.7. Compatibility with Python 2.7 is desirable,
but compatibility with Python 3.5 is **required**.
Python code currently must be compatible with Python 3.6. If a later
version or Python is required, it needs to be documented.
Compatibility with older programming language standards is very
important to maintain portability and availability of LAMMPS on many

2
doc/src/Packages_details.rst
View File

@ -2428,7 +2428,7 @@ ways to use LAMMPS and Python together.
Building with the PYTHON package assumes you have a Python development
environment (headers and libraries) available on your system, which needs
to be either Python version 2.7 or Python 3.5 and later.
to be Python version 3.6 or later.
**Install:**

32
doc/src/Python_install.rst
View File

@ -7,6 +7,10 @@ LAMMPS shared library through the Python `ctypes <ctypes_>`_
module. Because of the dynamic loading, it is required that LAMMPS is
compiled in :ref:`"shared" mode <exe>`.
.. versionchanged:: 2Apr2025
LAMMPS currently only supports Python version 3.6 or later.
Two components are necessary for Python to be able to invoke LAMMPS code:
* The LAMMPS Python Package (``lammps``) from the ``python`` folder
@ -106,13 +110,16 @@ folder that the dynamic loader searches or inside of the installed
.. code-block:: bash
python install.py -p <python package> -l <shared library> -v <version.h file> [-n]
python install.py -p <python package> -l <shared library> -v <version.h file> [-n] [-f]
* The ``-p`` flag points to the ``lammps`` Python package folder to be installed,
* the ``-l`` flag points to the LAMMPS shared library file to be installed,
* the ``-v`` flag points to the LAMMPS version header file to extract the version date,
* and the optional ``-n`` instructs the script to only build a wheel file
but not attempt to install it.
* the optional ``-n`` instructs the script to only build a wheel file but not attempt
to install it,
* and the optional ``-f`` argument instructs the script to force installation even if
pip would otherwise refuse installation with an
:ref:`error about externally managed environments <externally_managed>`.
.. tab:: Virtual environment
@ -136,11 +143,6 @@ folder that the dynamic loader searches or inside of the installed
# create virtual environment in folder $HOME/myenv
python3 -m venv $HOME/myenv
For Python versions prior 3.3 you can use `virtualenv
<https://packaging.python.org/en/latest/key_projects/#virtualenv>`_
command instead of "python3 -m venv". This step has to be done
only once.
To activate the virtual environment type:
.. code-block:: bash
@ -199,6 +201,10 @@ folder that the dynamic loader searches or inside of the installed
The ``PYTHONPATH`` needs to point to the parent folder that contains the ``lammps`` package!
In case you run into an "externally-managed-environment" error when
trying to install the LAMMPS Python module, please refer to
:ref:`corresponding paragraph <externally_managed>` in the Python HOWTO
page to learn about options for handling this error.
To verify if LAMMPS can be successfully started from Python, start the
Python interpreter, load the ``lammps`` Python module and create a
@ -245,14 +251,14 @@ make MPI calls directly from Python in your script, if you desire.
We have tested this with `MPI for Python <https://mpi4py.readthedocs.io/>`_
(aka mpi4py) and you will find installation instruction for it below.
Installation of mpi4py (version 3.0.3 as of Sep 2020) can be done as
Installation of mpi4py (version 4.0.1 as of Feb 2025) can be done as
follows:
- Via ``pip`` into a local user folder with:
.. code-block:: bash
pip install --user mpi4py
python3 -m pip install --user mpi4py
- Via ``dnf`` into a system folder for RedHat/Fedora systems:
@ -261,20 +267,20 @@ follows:
# for use with OpenMPI
sudo dnf install python3-mpi4py-openmpi
# for use with MPICH
sudo dnf install python3-mpi4py-openmpi
sudo dnf install python3-mpi4py-mpich
- Via ``pip`` into a virtual environment (see above):
.. code-block:: console
$ source $HOME/myenv/activate
(myenv)$ pip install mpi4py
(myenv)$ python -m pip install mpi4py
- Via ``pip`` into a system folder (not recommended):
.. code-block:: bash
sudo pip install mpi4py
sudo python3 -m pip install mpi4py
For more detailed installation instructions and additional options,
please see the `mpi4py installation <https://mpi4py.readthedocs.io/en/stable/install.html>`_ page.

2
doc/src/Python_launch.rst
View File

@ -1,7 +1,7 @@
Running LAMMPS and Python in serial
-----------------------------------
To run a LAMMPS in serial, type these lines into Python
To run a LAMMPS input in serial, type these lines into Python
interactively from the ``bench`` directory:
.. code-block:: python

14
doc/src/Python_overview.rst
View File

@ -44,15 +44,11 @@ Below is an example output for Python version 3.8.5.
.. warning::
The options described in this section of the manual for using Python
with LAMMPS currently support either Python 2 or 3. Specifically
version 2.7 or later and 3.6 or later. Since the Python community no
longer maintains Python 2 (see `this notice
<https://www.python.org/doc/sunset-python-2/>`_), we recommend use of
Python 3 with LAMMPS. While Python 2 code should continue to work,
that is not something we can guarantee long-term. If you notice
Python code in the LAMMPS distribution that is not compatible with
Python 3, please contact the LAMMPS developers or submit `and issue
on GitHub <https://github.com/lammps/lammps/issues>`_
with LAMMPS support only Python 3.6 or later. For use with Python
2.x you will need to use an older LAMMPS version like 29 Aug 2024
or older. If you notice Python code in the LAMMPS distribution that
is not compatible with Python 3, please contact the LAMMPS developers
or submit `and issue on GitHub <https://github.com/lammps/lammps/issues>`_
---------

21
doc/src/Python_scatter.rst
View File

@ -3,17 +3,16 @@ Scatter/gather operations
.. code-block:: python
data = lmp.gather_atoms(name,type,count) # return per-atom property of all atoms gathered into data, ordered by atom ID
# name = "x", "charge", "type", etc
data = lmp.gather_atoms_concat(name,type,count) # ditto, but concatenated atom values from each proc (unordered)
data = lmp.gather_atoms_subset(name,type,count,ndata,ids) # ditto, but for subset of Ndata atoms with IDs
data = lmp.gather_atoms(name,dtype,count) # return per-atom property of all atoms gathered into data, ordered by atom ID
# name = "x", "q", "type", etc
data = lmp.gather_atoms_concat(name,dtype,count) # ditto, but concatenated atom values from each proc (unordered)
data = lmp.gather_atoms_subset(name,dtype,count,ndata,ids) # ditto, but for subset of Ndata atoms with IDs
lmp.scatter_atoms(name,type,count,data) # scatter per-atom property to all atoms from data, ordered by atom ID
# name = "x", "charge", "type", etc
lmp.scatter_atoms(name,dtype,count,data) # scatter per-atom property to all atoms from data, ordered by atom ID
# name = "x", "q", "type", etc
# count = # of per-atom values, 1 or 3, etc
lmp.scatter_atoms_subset(name,type,count,ndata,ids,data) # ditto, but for subset of Ndata atoms with IDs
lmp.scatter_atoms_subset(name,dtype,count,ndata,ids,data) # ditto, but for subset of Ndata atoms with IDs
The gather methods collect peratom info of the requested type (atom
coords, atom types, forces, etc) from all processors, and returns the
@ -22,6 +21,12 @@ functions do the inverse. They distribute a vector of peratom values,
passed by all calling processors, to individual atoms, which may be
owned by different processors.
The *dtype* parameter is 0 for ``int`` values and 1 for ``double``
values. The *count* parameter is 1 for per-atom vectors like "type"
or "q" and 3 for per-atom arrays like "x", "v", "f". Use *count* = 3
with name = "image" if you want the single integer storing the image
flags unpacked into 3 components ("x", "y", and "z").
Note that the data returned by the gather methods,
e.g. :py:meth:`gather_atoms("x") <lammps.lammps.gather_atoms()>`, is
different from the data structure returned by

416
doc/src/Run_formats.rst Normal file
View File

@ -0,0 +1,416 @@
File formats used by LAMMPS
===========================
This page provides a general overview of the kinds of files and file
formats that LAMMPS is reading and writing.
.. contents:: On this page
:depth: 2
:backlinks: top
-------------------
Character Encoding
^^^^^^^^^^^^^^^^^^
For processing text files, the LAMMPS source code assumes `ASCII
character encoding <https://en.wikipedia.org/wiki/ASCII>`_ which
represents the digits 0 to 9, the lower and upper case letters a to z,
some common punctuation and other symbols and a few whitespace
characters including a regular "space character", "line feed", "carriage
return", "tabulator". These characters are all represented by single
bytes with a value smaller than 128 and only 95 of those 128 values
represent printable characters. This list is sufficient to represent
most English text, but misses accented characters or umlauts or Greek
symbols and more.
Modern text often uses `UTF-8 character encoding
<https://en.wikipedia.org/wiki/UTF-8>`_ instead. This encoding is a way
to represent many more different characters as defined by the Unicode
standard. UFT-8 is compatible with ASCII, since the first 128 values
are identical with the ASCII encoding. It is important to note,
however, that there are Unicode characters that *look* similar to ASCII
characters, but have a different binary representation. As a general
rule, these characters may not be correctly recognized by LAMMPS. For
some parts of LAMMPS' text processing, translation tables with known
"lookalike" characters are used. The tables are used to substitute
non-ASCII characters with their ASCII equivalents. Non-ASCII lookalike
characters are often used by web browsers or PDF viewers to improve the
readability of text. Thus, when using copy and paste to transfer text
from such an application to your input file, you may unintentionally
create text that is not exclusively using ASCII encoding and may cause
errors when LAMMPS is trying to read it.
Lines with non-printable and non-ASCII characters in text files can be
detected for example with a (Linux) command like the following:
.. code-block:: bash
env LC_ALL=C grep -n '[^ -~]' some_file.txt
Number Formatting
^^^^^^^^^^^^^^^^^
Different countries and languages have different conventions to format
numbers. While in some regions commas are used for fractions and points
to indicate thousand, million and so on, this is reversed in other
regions. Modern operating systems have facilities to adjust input and
output accordingly that are collectively referred to as "native language
support" (NLS). The exact rules are often applied according to the
value of the ``$LANG`` environment variable (e.g. "en_US.utf8" for
English text in UTF-8 encoding).
For the sake of simplicity of the implementation and transferability of
results, LAMMPS does not support this and instead expects numbers being
formatted in the generic or "C" locale. The "C" locale has no
punctuation for thousand, million and so on and uses a decimal point for
fractions. One thousand would be represented as "1000.0" and not as
"1,000.0" nor as "1.000,0". Having native language support enabled for
a locale other than "C" will result in different behavior when
converting or formatting numbers that can trigger unexpected errors.
LAMMPS also only accepts integer numbers when an integer is required, so
using floating point equivalents like "1.0" are not accepted; you *must*
use "1" instead.
For floating point numbers in scientific notation, the Fortran double
precision notation "1.1d3" is not accepted; you have to use "1100",
"1100.0" or "1.1e3".
Input file
^^^^^^^^^^
A LAMMPS input file is a text file with commands. It is read
line-by-line and each line is processed *immediately*. Before looking
for commands and executing them, there is a pre-processing step where
comments (non-quoted text starting with a pound sign '#') are removed,
``${variable}`` and ``$(expression)`` constructs are expanded or
evaluated, and lines that end in the ampersand character '&' are
combined with the next line (similar to Fortran 90 free-format source
code). After the pre-processing, lines are split into "words" and
evaluated. The first word must be a :doc:`command <Commands_all>` and
all following words are arguments. Below are some example lines:
.. code-block:: LAMMPS
# full line comment
# some global settings
units lj
atom_style atomic
# ^^ command ^^ argument(s)
variable x index 1 # may be overridden from command line with -var x <value>
variable xx equal 20*$x # variable "xx" is always 20 times "x"
lattice fcc 0.8442
# example of a command written across multiple lines
# the "region" command uses spacing from "lattice" command, unless "units box" is specified
region box block 0.0 ${xx} &
0.0 40.0 &
0.0 30.0
# create simulation box and fill with atoms according to lattice setting
create_box 1 box
create_atoms 1 box
# set force field and parameters
mass 1 1.0
pair_style lj/cut 2.5
pair_coeff 1 1 1.0 1.0 2.5
# run simulation
fix 1 all nve
run 1000
The pivotal command in this example input is the :doc:`create_box
command <create_box>`. It defines the simulation system and many
parameters that go with it: units, atom style, number of atom types (and
other types) and more. Those settings are *locked in* after the box is
created. Commands that change these kind of settings are only allowed
**before** a simulation box is created and many other commands are only
allowed **after** the simulation box is defined (e.g. :doc:`pair_coeff
<pair_coeff>`). Very few commands (e.g. :doc:`pair_style <pair_style>`)
may be used in either part of the input. The :doc:`read_data
<read_data>` and :doc:`read_restart <read_restart>` commands also create
the system box and thus have a similar pivotal function.
The LAMMPS input syntax has minimal support for conditionals and loops,
but if more complex operations are required, it is recommended to use
the library interface, e.g. :doc:`from Python using the LAMMPS Python
module <Python_run>`.
There is a frequent misconception about the :doc:`if command <if>`:
this is a command for conditional execution **outside** a run or
minimization. To trigger actions on specific conditions **during**
a run is a non-trivial operation that usually requires adopting one
of the available "fix" commands or creating a new "fix" command.
LAMMPS commands change the internal state and thus the order of commands
matters and reordering them can produce different results. For example,
the region defined by the :doc:`region command <region>` in the example
above depends on the :doc:`lattice setting <lattice>` and thus its
dimensions will be different depending on the order of the two commands.
Each line must have an "end-of-line" character (line feed or carriage
return plus line feed). Some text editors do not automatically insert
one which may cause LAMMPS to ignore the last command. It is thus
recommended to always have an empty line at the end of an input file.
The specific details describing how LAMMPS input is processed and parsed
are explained in :doc:`Commands_parse`.
Data file
^^^^^^^^^
A LAMMPS data file contains a description of a system suitable for
reading with the :doc:`read_data command <read_data>`. Data files are
commonly used for setting up complex molecular systems that can be
difficult to achieve with the commands :doc:`create_box <create_box>`
and :doc:`create_atoms <create_atoms>` alone. Also, data files can be
used as a portable alternatives to a :doc:`binary restart file
<restart>`. A restart file can be converted into a data file from the
:doc:`command line <Run_options>`.
Data files have a header section at the very beginning of the file and
multiple titled sections such as "Atoms", Masses", "Pair Coeffs", and so
on. Header keywords can only be used *before* the first title section.
The data file **always** starts with a "title" line, which will be
**ignored** by LAMMPS. Omitting the title line can lead to unexpected
behavior because a line of the header with an actual setting may be
ignored. In this case, the mistakenly ignored line often contains the
"atoms" keyword, which results in LAMMPS assuming that there are no
atoms in the data file and thus throwing an error on the contents of the
"Atoms" section. The title line may contain some keywords that can be
used by external programs to convey information about the system
(included as comments), that is not required and not read by LAMMPS.
The line following a section title is also **ignored**. An error will
occur if an empty line is not placed after a section title. The number
of lines in titled sections depends on header keywords, like the number
of atom types, the number of atoms, the number of bond types, the number
of bonds, and so on. The data in those sections has to be complete. A
special case are the "Pair Coeffs" and "PairIJ Coeffs" sections; the
former is for force fields and pair styles that use mixing of non-bonded
potential parameters, the latter for pair styles and force fields
requiring explicit coefficients. Thus with *N* being the number of atom
types, the "Pair Coeffs" section has *N* entries while "PairIJ Coeffs"
has :math:`N \cdot (N-1)` entries. Internally, these sections will be
converted to :doc:`pair_coeff <pair_coeff>` commands. Thus the
corresponding :doc:`pair style <pair_style>` must have been set *before*
the :doc:`read_data command <read_data>` reads the data file.
Data files may contain comments, which start with the pound sign '#'.
There must be at least one blank between a valid keyword and the pound
sign. Below is a simple example case of a data file for :doc:`atom style
full <atom_style>`.
.. code-block:: bash
LAMMPS Title line (ignored)
# full line comment
10 atoms # comment
4 atom types
-36.840194 64.211560 xlo xhi
-41.013691 68.385058 ylo yhi
-29.768095 57.139462 zlo zhi
Masses
1 12.0110
2 12.0110
3 15.9990
4 1.0080
Pair Coeffs # this section is optional
1 0.110000 3.563595 0.110000 3.563595
2 0.080000 3.670503 0.010000 3.385415
3 0.120000 3.029056 0.120000 2.494516
4 0.022000 2.351973 0.022000 2.351973
Atoms # full
1 1 1 0.560 43.99993 58.52678 36.78550 0 0 0
2 1 2 -0.270 45.10395 58.23499 35.86693 0 0 0
3 1 3 -0.510 43.81519 59.54928 37.43995 0 0 0
4 1 4 0.090 45.71714 57.34797 36.13434 0 0 0
5 1 4 0.090 45.72261 59.13657 35.67007 0 0 0
6 1 4 0.090 44.66624 58.09539 34.85538 0 0 0
7 1 3 -0.470 43.28193 57.47427 36.91953 0 0 0
8 1 4 0.070 42.07157 57.45486 37.62418 0 0 0
9 1 1 0.510 42.19985 57.57789 39.12163 0 0 0
10 1 1 0.510 41.88641 58.62251 39.70398 0 0 0
# ^^atomID ^^molID ^^type ^^charge ^^xcoord ^^ycoord ^^ycoord ^^image^^flags (optional)
Velocities # this section is optional
1 0.0050731 -0.00398928 0.00391473
2 -0.0175184 0.0173484 -0.00489207
3 0.00597225 -0.00202006 0.00166454
4 -0.010395 -0.0082582 0.00316419
5 -0.00390877 0.00470331 -0.00226911
6 -0.00111157 -0.00374545 -0.0169374
7 0.00209054 -0.00594936 -0.000124563
8 0.00635002 -0.0120093 -0.0110999
9 -0.004955 -0.0123375 0.000403422
10 0.00265028 -0.00189329 -0.00293198
The common problem is processing the "Atoms" section, since its format
depends on the :doc:`atom style <atom_style>` used, and that setting
must be done in the input file *before* reading the data file. To
assist with detecting incompatible data files, a comment is appended to
the "Atoms" title indicating the atom style used (or intended) when
*writing* the data file. For example, below is an "Atoms" section for
:doc:`atom style charge <atom_style>`, which omits the molecule ID
column.
.. code-block:: bash
Atoms # charge
1 1 0.560 43.99993 58.52678 36.78550
2 2 -0.270 45.10395 58.23499 35.86693
3 3 -0.510 43.81519 59.54928 37.43995
4 4 0.090 45.71714 57.34797 36.13434
5 4 0.090 45.72261 59.13657 35.67007
6 4 0.090 44.66624 58.09539 34.85538
7 3 -0.470 43.28193 57.47427 36.91953
8 4 0.070 42.07157 57.45486 37.62418
9 1 0.510 42.19985 57.57789 39.12163
10 1 0.510 41.88641 58.62251 39.70398
# ^^atomID ^^type ^^charge ^^xcoord ^^ycoord ^^ycoord
Another source of confusion about the "Atoms" section format is the
ordering of columns. The three atom style variants `atom_style full`,
`atom_style hybrid charge molecular`, and `atom_style hybrid molecular
charge` all carry the same per-atom information. However, in data files,
the Atoms section has the columns 'Atom-ID Molecule-ID Atom-type Charge
X Y Z' for atom style full, but for hybrid atom styles the first columns
are always 'Atom-ID Atom-type X Y Z' followed by any *additional* data
added by the hybrid styles, for example, 'Charge Molecule-ID' for the
first hybrid style and 'Molecule-ID Charge' in the second hybrid style
variant. Finally, an alternative to a hybrid atom style is to use fix
property/atom, e.g. to add molecule IDs to atom style charge. In this
case the "Atoms" section is formatted according to atom style charge and
a new section, "Molecules" is added that contains lines with 'Atom-ID
Molecule-ID', one for each atom in the system. For adding charges to
atom style molecular with fix property/atom, the "Atoms" section is now
formatted according to the atom style and a "Charges" section is added.
Molecule file
^^^^^^^^^^^^^
Molecule files for use with the :doc:`molecule command <molecule>` look
quite similar to data files but they do not have a compatible format,
i.e., one cannot use a data file as molecule file and vice versa. Below
is a simple example for a water molecule (SPC/E model). Same as a data
file, there is an ignored title line and you can use comments. However,
there is no information about the number of types or the box dimensions.
These parameters are set when the simulation box is created. Thus the
header only has the count of atoms, bonds, and so on.
Molecule files have a header followed by sections (just as in data
files), but the section names are different than those of a data file.
There is no "Atoms" section and the section formats in molecule files is
independent of the atom style. Its information is split across multiple
sections, like "Coords", "Types", and "Charges". Note that no "Masses"
section is needed here. The atom masses are by default tied to the atom
type and set with a data file or the :doc:`mass command <mass>`. A
"Masses" section would only be required for atom styles with per-atom
masses, e.g. atom style sphere, where in data files you would provide
the density and the diameter instead of the mass.
Since the entire file is a 'molecule', LAMMPS will assign a new
molecule-ID (if supported by the atom style) when atoms are instantiated
from a molecule file, e.g. with the :doc:`create_atoms command
<create_atoms>`. It is possible to include a "Molecules" section to
indicate that the atoms belong to multiple 'molecules'. Atom-IDs and
molecule-IDs in the molecule file are relative for the file
(i.e. starting from 1) and will be translated into actual atom-IDs also
when the atoms from the molecule are created.
.. code-block:: bash
# Water molecule. SPC/E model.
3 atoms
2 bonds
1 angles
Coords
1 1.12456 0.09298 1.27452
2 1.53683 0.75606 1.89928
3 0.49482 0.56390 0.65678
Types
1 1
2 2
3 2
Charges
1 -0.8472
2 0.4236
3 0.4236
Bonds
1 1 1 2
2 1 1 3
Angles
1 1 2 1 3
There are also optional sections, e.g. about :doc:`SHAKE <fix_shake>`
and :doc:`special bonds <special_bonds>`. Those sections are only needed
if the molecule command is issued *before* the simulation box is
defined. Otherwise, the molecule command can derive the required
settings internally.
Restart file
^^^^^^^^^^^^
LAMMPS restart files are binary files and not available in text format.
They can be identified by the first few bytes that contain the (C-style)
string ``LammpS RestartT`` as `magic string
<https://en.wikipedia.org/wiki/Magic_string>`_. This string is followed
by a 16-bit integer of the number 1 used for detecting whether the
computer writing the restart has the same `endianness
<https://en.wikipedia.org/wiki/Endianness>`_ as the computer reading it.
If not, the file cannot be read correctly. This integer is followed by
a 32-bit integer indicating the file format revision (currently 3),
which can be used to implement backward compatibility for reading older
revisions.
This information has been added to the `Unix "file" command's
<https://www.darwinsys.com/file/>` "magic" file so that restart files
can be identified without opening them. If you have a fairly recent
version, it should already be included. If you have an older version,
the LAMMPS source package :ref:`contains a file with the necessary
additions <magic>`.
The rest of the file is organized in sections of a 32-bit signed integer
constant indicating the kind of content and the corresponding value (or
values). If those values are arrays (including C-style strings), then
the integer constant is followed by a 32-bit integer indicating the
length of the array. This mechanism will read the data regardless of
the ordering of the sections. Symbolic names of the section constants
are in the ``lmprestart.h`` header file.
LAMMPS restart files are not expected to be portable between platforms
or LAMMPS versions, but changes to the file format are rare.
.. Native Dump file
.. ^^^^^^^^^^^^^^^^
..
.. Potential files
.. ^^^^^^^^^^^^^^^

10
doc/src/Run_head.rst
View File

@ -1,10 +1,11 @@
Run LAMMPS
**********
These pages explain how to run LAMMPS once you have :doc:`installed an executable <Install>` or :doc:`downloaded the source code <Install>`
and :doc:`built an executable <Build>`. The :doc:`Commands <Commands>`
doc page describes how input scripts are structured and the commands
they can contain.
These pages explain how to run LAMMPS once you have :doc:`installed an
executable <Install>` or :doc:`downloaded the source code <Install>` and
:doc:`built an executable <Build>`. The :doc:`Commands <Commands>` doc
page describes how input scripts are structured and the commands they
can contain.
.. toctree::
:maxdepth: 1
@ -12,4 +13,5 @@ they can contain.
Run_basics
Run_options
Run_output
Run_formats
Run_windows

21
doc/src/Run_output.rst
View File

@ -117,14 +117,19 @@ number of histogram counts is equal to the number of processors.
----------
The last section gives aggregate statistics (across all processors)
for pairwise neighbors and special neighbors that LAMMPS keeps track
of (see the :doc:`special_bonds <special_bonds>` command). The number
of times neighbor lists were rebuilt is tallied, as is the number of
potentially *dangerous* rebuilds. If atom movement triggered neighbor
list rebuilding (see the :doc:`neigh_modify <neigh_modify>` command),
then dangerous reneighborings are those that were triggered on the
first timestep atom movement was checked for. If this count is
The last section gives aggregate statistics (across all processors) for
pairwise neighbors and special neighbors that LAMMPS keeps track of (see
the :doc:`special_bonds <special_bonds>` command). This section will
not always contain data, for example when there has not been a neighbor
rebuild, or the neighbor list was constructed on the GPU or when a
hybrid pair style was used and LAMMPS cannot determine a suitable (base)
neighbor list to draw the statistics from.
The number of times neighbor lists were rebuilt is tallied, as is the
number of potentially *dangerous* rebuilds. If atom movement triggered
neighbor list rebuilding (see the :doc:`neigh_modify <neigh_modify>`
command), then dangerous reneighborings are those that were triggered on
the first timestep atom movement was checked for. If this count is
non-zero you may wish to reduce the delay factor to ensure no force
interactions are missed by atoms moving beyond the neighbor skin
distance before a rebuild takes place.

13
doc/src/Speed_compare.rst
View File

@ -44,11 +44,6 @@ section below for examples where this has been done.
system the crossover (in single precision) is often about 50K-100K
atoms per GPU. When performing double precision calculations the
crossover point can be significantly smaller.
* Both KOKKOS and GPU package compute bonded interactions (bonds, angles,
etc) on the CPU. If the GPU package is running with several MPI processes
assigned to one GPU, the cost of computing the bonded interactions is
spread across more CPUs and hence the GPU package can run faster in these
cases.
* When using LAMMPS with multiple MPI ranks assigned to the same GPU, its
performance depends to some extent on the available bandwidth between
the CPUs and the GPU. This can differ significantly based on the
@ -85,10 +80,10 @@ section below for examples where this has been done.
code (with a performance penalty due to having data transfers between
host and GPU).
* The GPU package requires neighbor lists to be built on the CPU when using
exclusion lists, or a triclinic simulation box.
* The GPU package can be compiled for CUDA or OpenCL and thus supports
both, NVIDIA and AMD GPUs well. On NVIDIA hardware, using CUDA is typically
resulting in equal or better performance over OpenCL.
hybrid pair styles, exclusion lists, or a triclinic simulation box.
* The GPU package can be compiled for CUDA, HIP, or OpenCL and thus supports
NVIDIA, AMD, and Intel GPUs well. On NVIDIA hardware, using CUDA is
typically resulting in equal or better performance over OpenCL.
* OpenCL in the GPU package does theoretically also support Intel CPUs or
Intel Xeon Phi, but the native support for those in KOKKOS (or INTEL)
is superior.

14
doc/src/Tools.rst
View File

@ -930,7 +930,7 @@ dependencies and redirects the download to the local cache.
mkdir build
cd build
cmake -D LAMMPS_DOWNLOADS_URL=${HTTP_CACHE_URL} -C "${LAMMPS_HTTP_CACHE_CONFIG}" -C ../cmake/presets/most.cmake ../cmake
cmake -D LAMMPS_DOWNLOADS_URL=${HTTP_CACHE_URL} -C "${LAMMPS_HTTP_CACHE_CONFIG}" -C ../cmake/presets/most.cmake -D DOWNLOAD_POTENTIALS=off ../cmake
make -j 8
deactivate_caches
@ -1276,11 +1276,13 @@ Those scripts were written by Steve Plimpton sjplimp at gmail.com
valgrind tool
-------------
The ``valgrind`` folder contains additional suppressions fur LAMMPS when using
valgrind's memcheck tool to search for memory access violation and memory
leaks. These suppressions are automatically invoked when running tests through
CMake "ctest -T memcheck". See the provided README file to add these
suppressions when running LAMMPS.
The ``valgrind`` folder contains additional suppressions fur LAMMPS when
using `valgrind's <https://valgrind.org/>`_ ` `memcheck tool
<https://valgrind.org/info/tools.html#memcheck>`_ to search for memory
access violation and memory leaks. These suppressions are automatically
invoked when running tests through CMake "ctest -T memcheck". See the
instruction in the ``README`` file to add these suppressions when using
valgrind with LAMMPS or other programs.
----------

2
doc/src/angle_mwlc.rst
View File

@ -21,7 +21,7 @@ Examples
Description
"""""""""""
.. versionadded:: TBD
.. versionadded:: 4Feb2025
The *mwlc* angle style models a meltable wormlike chain and can be used
to model non-linear bending elasticity of polymers, e.g. DNA. *mwlc*

19
doc/src/bond_bpm_spring.rst
View File

@ -10,7 +10,7 @@ Syntax
bond_style bpm/spring keyword value attribute1 attribute2 ...
* optional keyword = *overlay/pair* or *store/local* or *smooth* or *break* or *volume/factor*
* optional keyword = *overlay/pair* or *store/local* or *smooth* or *normalize* or *break* or *volume/factor*
.. parsed-literal::
@ -123,7 +123,7 @@ heuristic maximum strain used by typical non-bpm bond styles. Similar behavior
to *break no* can also be attained by setting an arbitrarily high value of
:math:`\epsilon_c`. One cannot use *break no* with *smooth yes*.
.. versionadded:: TBD
.. versionadded:: 4Feb2025
The *volume/factor* keyword toggles whether an additional multibody
contribution is added to he force using the formulation in
@ -141,7 +141,8 @@ calculated using bond lengths squared and the cube root in the above equation
is accordingly replaced with a square root. This approximation assumes bonds
are evenly distributed on a spherical surface and neglects constant prefactors
which are irrelevant since only the ratio of volumes matters. This term may be
used to adjust the Poisson's ratio.
used to adjust the Poisson's ratio. See the simulation in the
``examples/bpm/poissons_ratio`` directory for a demonstration of this effect.
If a bond is broken (or created), :math:`V_{0,i}` is updated by subtracting
(or adding) that bond's contribution.
@ -152,7 +153,7 @@ the data file or restart files read by the :doc:`read_data
<read_data>` or :doc:`read_restart <read_restart>` commands:
* :math:`k` (force/distance units)
* :math:`\epsilon_c` (unit less)
* :math:`\epsilon_c` (unitless)
* :math:`\gamma` (force/velocity units)
Additionally, if *volume/factor* is set to *yes*, a fourth coefficient
@ -214,11 +215,11 @@ for an overview of LAMMPS output options.
The vector or array will be floating point values that correspond to
the specified attribute.
The single() function of this bond style returns 0.0 for the energy
of a bonded interaction, since energy is not conserved in these
dissipative potentials. The single() function also calculates an
extra bond quantity, the initial distance :math:`r_0`. This
extra quantity can be accessed by the
The potential energy and the single() function of this bond style return
:math:`k (r - r_0)^2 / 2` as a proxy of the energy of a bonded interaction,
ignoring any volumetric/smoothing factors or dissipative forces. The single()
function also calculates an extra bond quantity, the initial distance
:math:`r_0`. This extra quantity can be accessed by the
:doc:`compute bond/local <compute_bond_local>` command as *b1*\ .
Restrictions

184
doc/src/bond_bpm_spring_plastic.rst Normal file
View File

@ -0,0 +1,184 @@
.. index:: bond_style bpm/spring/plastic
bond_style bpm/spring/plastic command
=====================================
Syntax
""""""
.. code-block:: LAMMPS
bond_style bpm/spring/plastic keyword value attribute1 attribute2 ...
* optional keyword = *overlay/pair* or *store/local* or *smooth* or *normalize* or *break*
.. parsed-literal::
*store/local* values = fix_ID N attributes ...
* fix_ID = ID of associated internal fix to store data
* N = prepare data for output every this many timesteps
* attributes = zero or more of the below attributes may be appended
*id1, id2* = IDs of two atoms in the bond
*time* = the timestep the bond broke
*x, y, z* = the center of mass position of the two atoms when the bond broke (distance units)
*x/ref, y/ref, z/ref* = the initial center of mass position of the two atoms (distance units)
*overlay/pair* value = *yes* or *no*
bonded particles will still interact with pair forces
*smooth* value = *yes* or *no*
smooths bond forces near the breaking point
*normalize* value = *yes* or *no*
normalizes bond forces by the reference length
*break* value = *yes* or *no*
indicates whether bonds break during a run
Examples
""""""""
.. code-block:: LAMMPS
bond_style bpm/spring/plastic
bond_coeff 1 1.0 0.05 0.1 0.02
bond_style bpm/spring/plastic myfix 1000 time id1 id2
dump 1 all local 1000 dump.broken f_myfix[1] f_myfix[2] f_myfix[3]
dump_modify 1 write_header no
Description
"""""""""""
.. versionadded:: 2Apr2025
The *bpm/spring/plastic* bond style computes forces based on
deviations from the initial reference state of the two atoms and the
strain history. The reference length of the bond :math:`r_0` is stored
by each bond when it is first computed in the setup of a run. Initially,
the equilibrium length of each bond :math:`r_\mathrm{eq}` is set equal
to :math:`r_0` but can evolve. data is then preserved across run commands
and is written to :doc:`binary restart files <restart>` such that restarting
the system will not modify either of these quantities.
This bond style only applies central-body forces which conserve the
translational and rotational degrees of freedom of a bonded set of
particles. The force has a magnitude of
.. math::
F = -k (r_\mathrm{eq} - r) w
where :math:`k` is a stiffness, :math:`r` is the current distance between
the two particles, and :math:`w` is an optional smoothing factor discussed
below. If the bond stretches beyond a strain of :math:`\epsilon_p` in compression
or extension, it will plastically activate and :math:`r_\mathrm{eq}` will evolve
to ensure :math:`|(r-r_\mathrm{eq})/r_\mathrm{eq}|` never exceeds :math:`\epsilon_p`.
Therefore, if a bond is continually loaded in either tension or compression, the
force will initially grow elastically before plateauing. See
:ref:`(Clemmer) <plastic-Clemmer>` for more details on these mechanics.
Bonds will break at a strain of :math:`\epsilon_c`. This is done by setting
the bond type to 0 such that forces are no longer computed.
An additional damping force is applied to the bonded
particles. This forces is proportional to the difference in the
normal velocity of particles:
.. math::
F_D = - \gamma w (\hat{r} \bullet \vec{v})
where :math:`\gamma` is the damping strength, :math:`\hat{r}` is the
radial normal vector, and :math:`\vec{v}` is the velocity difference
between the two particles.
The smoothing factor :math:`w` is constructed such that forces smoothly
go to zero, avoiding discontinuities, as bonds approach the critical
breaking strain
.. math::
w = 1.0 - \left( \frac{r - r_0}{r_0 \epsilon_c} \right)^8 .
The following coefficients must be defined for each bond type via the
:doc:`bond_coeff <bond_coeff>` command as in the example above, or in
the data file or restart files read by the :doc:`read_data
<read_data>` or :doc:`read_restart <read_restart>` commands:
* :math:`k` (force/distance units)
* :math:`\epsilon_c` (unitless)
* :math:`\gamma` (force/velocity units)
* :math:`\epsilon_p` (unitless)
See the :doc:`bpm/spring doc page <bond_bpm_spring>` for information on
the *smooth*, *normalize*, *break*, *overlay/pair*, and *store/local*
keywords.
Note that when unbroken bonds are dumped to a file via the
:doc:`dump local <dump>` command, bonds with type 0 (broken bonds)
are not included.
The :doc:`delete_bonds <delete_bonds>` command can also be used to
query the status of broken bonds or permanently delete them, e.g.:
.. code-block:: LAMMPS
delete_bonds all stats
delete_bonds all bond 0 remove
----------
Restart and other info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This bond style writes the reference state and plastic history of each
bond to :doc:`binary restart files <restart>`. Loading a restart file
will properly restore bonds. However, the reference state is NOT written
to data files. Therefore reading a data file will not restore bonds and
will cause their reference states to be redefined.
The potential energy and the single() function of this bond style
returns zero. The single() function also calculates two extra bond
quantities, the initial distance :math:`r_0` and the current equilibrium
length :math:`r_eq`. These extra quantities can be accessed by the
:doc:`compute bond/local <compute_bond_local>` command as *b1* and *b2*,
respectively.
Restrictions
""""""""""""
This bond style is part of the BPM package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
By default if pair interactions between bonded atoms are to be disabled,
this bond style requires setting
.. code-block:: LAMMPS
special_bonds lj 0 1 1 coul 1 1 1
and :doc:`newton <newton>` must be set to bond off. If the *overlay/pair*
keyword is set to *yes*, this bond style alternatively requires setting
.. code-block:: LAMMPS
special_bonds lj/coul 1 1 1
Related commands
""""""""""""""""
:doc:`bond_coeff <bond_coeff>`, :doc:`bond bpm/spring <bond_bpm_spring>`
Default
"""""""
The option defaults are *overlay/pair* = *no*, *smooth* = *yes*, *normalize* = *no*, and *break* = *yes*
----------
.. _plastic-Clemmer:
**(Clemmer)** Clemmer and Lechman, Powder Technology (2025).

2
doc/src/bond_harmonic.rst
View File

@ -60,6 +60,8 @@ Related commands
""""""""""""""""
:doc:`bond_coeff <bond_coeff>`, :doc:`delete_bonds <delete_bonds>`
:doc:`bond style harmonic/shift <bond_harmonic_shift>`,
:doc:`bond style harmonic/shift/cut <bond_harmonic_shift_cut>`
Default
"""""""

17
doc/src/bond_harmonic_shift.rst
View File

@ -31,9 +31,15 @@ the potential
E = \frac{U_{\text{min}}}{(r_0-r_c)^2} \left[ (r-r_0)^2-(r_c-r_0)^2 \right]
where :math:`r_0` is the equilibrium bond distance, and :math:`r_c` the critical distance.
The potential is :math:`-U_{\text{min}}` at :math:`r0` and zero at :math:`r_c`. The spring constant is
:math:`k = U_{\text{min}} / [ 2 (r_0-r_c)^2]`.
where :math:`r_0` is the equilibrium bond distance, and :math:`r_c` the
critical distance. The potential energy has the value
:math:`-U_{\text{min}}` at :math:`r_0` and zero at :math:`r_c`. This
bond style differs from :doc:`bond_style harmonic <bond_harmonic>`
by the value of the potential energy.
The equivalent spring constant value *K* for use with :doc:`bond_style
harmonic <bond_harmonic>` can be computed using :math:`K =
U_{\text{min}} / [(r_0-r_c)^2]`.
The following coefficients must be defined for each bond type via the
:doc:`bond_coeff <bond_coeff>` command as in the example above, or in
@ -41,9 +47,7 @@ the data file or restart files read by the :doc:`read_data <read_data>`
or :doc:`read_restart <read_restart>` commands:
* :math:`U_{\text{min}}` (energy)
* :math:`r_0` (distance)
* :math:`r_c` (distance)
----------
@ -63,7 +67,8 @@ Related commands
""""""""""""""""
:doc:`bond_coeff <bond_coeff>`, :doc:`delete_bonds <delete_bonds>`,
:doc:`bond_harmonic <bond_harmonic>`
:doc:`bond style harmonic <bond_harmonic>`,
:doc:`bond style harmonic/shift/cut <bond_harmonic_shift_cut>`
Default
"""""""

11
doc/src/bond_harmonic_shift_cut.rst
View File

@ -31,9 +31,14 @@ uses the potential
E = \frac{U_{\text{min}}}{(r_0-r_c)^2} \left[ (r-r_0)^2-(r_c-r_0)^2 \right]
where :math:`r_0` is the equilibrium bond distance, and rc the critical distance.
The bond potential is zero for distances :math:`r > r_c`. The potential is :math:`-U_{\text{min}}`
at :math:`r_0` and zero at :math:`r_c`. The spring constant is :math:`k = U_{\text{min}} / [ 2 (r_0-r_c)^2]`.
where :math:`r_0` is the equilibrium bond distance, and :math:`r_c` the
critical distance. The bond potential is zero and thus its force also
zero for distances :math:`r > r_c`. The potential energy has the value
:math:`-U_{\text{min}}` at :math:`r_0` and zero at :math:`r_c`.
The equivalent spring constant value *K* for use with :doc:`bond_style
harmonic <bond_harmonic>` for :math:`r <= r_c`, can be computed using
:math:`K = U_{\text{min}} / [(r_0-r_c)^2]`
The following coefficients must be defined for each bond type via the
:doc:`bond_coeff <bond_coeff>` command as in the example above, or in

2
doc/src/bond_rheo_shell.rst
View File

@ -94,7 +94,7 @@ the data file or restart files read by the :doc:`read_data
<read_data>` or :doc:`read_restart <read_restart>` commands:
* :math:`k` (force/distance units)
* :math:`\epsilon_c` (unit less)
* :math:`\epsilon_c` (unitless)
* :math:`\gamma` (force/velocity units)
Unlike other BPM-style bonds, this bond style does not update special

3
doc/src/bond_style.rst
View File

@ -10,7 +10,7 @@ Syntax
bond_style style args
* style = *none* or *zero* or *hybrid* or *bpm/rotational* or *bpm/spring* or *class2* or *fene* or *fene/expand* or *fene/nm* or *gaussian* or *gromos* or *harmonic* or *harmonic/restrain* *harmonic/shift* or *harmonic/shift/cut* or *lepton* or *morse* or *nonlinear* or *oxdna/fene* or *oxdena2/fene* or *oxrna2/fene* or *quartic* or *special* or *table*
* style = *none* or *zero* or *hybrid* or *bpm/rotational* or *bpm/spring* or *bpm/spring/plastic* or *class2* or *fene* or *fene/expand* or *fene/nm* or *gaussian* or *gromos* or *harmonic* or *harmonic/restrain* *harmonic/shift* or *harmonic/shift/cut* or *lepton* or *morse* or *nonlinear* or *oxdna/fene* or *oxdena2/fene* or *oxrna2/fene* or *quartic* or *special* or *table*
* args = none for any style except *hybrid*
@ -86,6 +86,7 @@ accelerated styles exist.
* :doc:`bpm/rotational <bond_bpm_rotational>` - breakable bond with forces and torques based on deviation from reference state
* :doc:`bpm/spring <bond_bpm_spring>` - breakable bond with forces based on deviation from reference length
* :doc:`bpm/spring/plastic <bond_bpm_spring_plastic>` - a similar breakable bond with plastic yield
* :doc:`class2 <bond_class2>` - COMPASS (class 2) bond
* :doc:`fene <bond_fene>` - FENE (finite-extensible non-linear elastic) bond
* :doc:`fene/expand <bond_fene_expand>` - FENE bonds with variable size particles

36
doc/src/comm_modify.rst
View File

@ -15,15 +15,12 @@ Syntax
.. parsed-literal::
*mode* value = *single*, *multi*, or *multi/old* = communicate atoms within a single or multiple distances
*mode* value = *single* or *multi* = communicate atoms within a single or multiple distances
*cutoff* value = Rcut (distance units) = communicate atoms from this far away
*cutoff/multi* collection value
collection = atom collection or collection range (supports asterisk notation)
value = Rcut (distance units) = communicate atoms for selected types from this far away
*reduce/multi* arg = none = reduce number of communicated ghost atoms for multi style
*cutoff/multi/old* type value
type = atom type or type range (supports asterisk notation)
value = Rcut (distance units) = communicate atoms for selected types from this far away
*group* value = group-ID = only communicate atoms in the group
*vel* value = *yes* or *no* = do or do not communicate velocity info with ghost atoms
@ -66,19 +63,16 @@ subdomain. The distance is by default the maximum of the neighbor
cutoff across all atom type pairs.
For many systems this is an efficient algorithm, but for systems with
widely varying cutoffs for different type pairs, the *multi* or *multi/old* mode can
be faster. In *multi*, each atom is assigned to a collection which should
correspond to a set of atoms with similar interaction cutoffs.
See the :doc:`neighbor <neighbor>` command for a detailed description of collections.
In this case, each atom collection is assigned its own distance
cutoff for communication purposes, and fewer atoms will be
communicated. in *multi/old*, a similar technique is used but atoms
are grouped by atom type. See the :doc:`neighbor multi <neighbor>` and
:doc:`neighbor multi/old <neighbor>` commands for
widely varying cutoffs for different type pairs, the *multi* mode can be
faster. In *multi*, each atom is assigned to a collection which should
correspond to a set of atoms with similar interaction cutoffs. See the
:doc:`neighbor <neighbor>` command for a detailed description of
collections. In this case, each atom collection is assigned its own
distance cutoff for communication purposes, and fewer atoms will be
communicated. See the :doc:`neighbor multi <neighbor>` command for
neighbor list construction options that may also be beneficial for
simulations of this kind. The *multi* communication mode is only compatible
with the *multi* neighbor style. The *multi/old* communication mode is comparable
with both the *multi* and *multi/old* neighbor styles.
simulations of this kind. The *multi* communication mode is only
compatible with the *multi* neighbor style.
The *cutoff* keyword allows you to extend the ghost cutoff distance
for communication mode *single*, which is the distance from the borders
@ -108,14 +102,12 @@ simulation to account for potential changes in the number of
collections. Custom cutoffs are preserved between runs but if
collections are redefined, one may want to re-specify the communication
cutoffs. For granular pair styles,the default cutoff is set to the sum
of the current maximum atomic radii for each collection. The
*cutoff/multi/old* option is similar to *cutoff/multi* except it
operates on atom types as opposed to collections.
of the current maximum atomic radii for each collection.
The *reduce/multi* option applies to *multi* and sets the communication
cutoff for a particle equal to the maximum interaction distance between particles
in the same collection. This reduces the number of
ghost atoms that need to be communicated. This method is only compatible with the
cutoff for a particle equal to the maximum interaction distance between
particles in the same collection. This reduces the number of ghost atoms
that need to be communicated. This method is only compatible with the
*multi* neighbor style and requires a half neighbor list and Newton on.
See the :doc:`neighbor multi <neighbor>` command for more information.

1
doc/src/commands_list.rst
View File

@ -82,6 +82,7 @@ Commands
read_dump
read_restart
region
region2vmd
replicate
rerun
reset_atoms

1
doc/src/compute.rst
View File

@ -356,6 +356,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`ti <compute_ti>` - thermodynamic integration free energy values
* :doc:`torque/chunk <compute_torque_chunk>` - torque applied on each chunk
* :doc:`vacf <compute_vacf>` - velocity auto-correlation function of group of atoms
* :doc:`vacf/chunk <compute_vacf_chunk>` - velocity auto-correlation for the center of mass velocities of chunks of atoms
* :doc:`vcm/chunk <compute_vcm_chunk>` - velocity of center-of-mass for each chunk
* :doc:`viscosity/cos <compute_viscosity_cos>` - velocity profile under cosine-shaped acceleration
* :doc:`voronoi/atom <compute_voronoi_atom>` - Voronoi volume and neighbors for each atom

15
doc/src/compute_chunk_atom.rst
View File

@ -218,12 +218,15 @@ into ellipses).
The created bins (and hence the chunk IDs) are numbered consecutively
from 1 to the number of bins = *Nchunk*\ . For *bin2d* and *bin3d*, the
numbering varies most rapidly in the first dimension (which could be
*x*, *y*, or *z*), next rapidly in the second dimension, and most slowly in the
third dimension. For *bin/sphere*, the bin with smallest radii is chunk
1 and the bin with largest radii is chunk Nchunk = *ncbin*\ . For
*bin/cylinder*, the numbering varies most rapidly in the dimension
along the cylinder axis and most slowly in the radial direction.
numbering varies fastest in the last dimension (which could be
*x*, *y*, or *z*), slower in the second dimension, and slowest in the
first dimension. For *bin/sphere*, the bin with smallest radius is chunk
1 and the bin with largest radius is chunk Nchunk = *ncbin*\ . For
*bin/cylinder*, the numbering varies faster in the dimension
along the cylinder axis and slower in the radial direction.
In all cases, for a given dimension, the numbering increases
with increasing value of the coordinate (Cartesian coordinate,
sphere or cylinder radius, axial position).
Each time this compute is invoked, each atom is mapped to a bin based
on its current position. Note that between reneighboring timesteps,

2
doc/src/compute_cna_atom.rst
View File

@ -67,7 +67,7 @@ following relation should also be satisfied:
.. math::
r_c + r_s > 2*{\rm cutoff}
r_c + r_s > 2*\mathrm{cutoff}
where :math:`r_c` is the cutoff distance of the potential, :math:`r_s`
is the skin

2
doc/src/compute_cnp_atom.rst
View File

@ -74,7 +74,7 @@ following relation should also be satisfied:
.. math::
r_c + r_s > 2*{\rm cutoff}
r_c + r_s > 2*\mathrm{cutoff}
where :math:`r_c` is the cutoff distance of the potential, :math:`r_s` is
the skin

4
doc/src/compute_efield_wolf_atom.rst
View File

@ -50,9 +50,9 @@ the potential energy using the Wolf summation method, described in
.. math::
E_i = \frac{1}{2} \sum_{j \neq i}
\frac{q_i q_j {\rm erfc}(\alpha r_{ij})}{r_{ij}} +
\frac{q_i q_j \mathrm{erfc}(\alpha r_{ij})}{r_{ij}} +
\frac{1}{2} \sum_{j \neq i}
\frac{q_i q_j {\rm erf}(\alpha r_{ij})}{r_{ij}} \qquad r < r_c
\frac{q_i q_j \mathrm{erf}(\alpha r_{ij})}{r_{ij}} \qquad r < r_c
where :math:`\alpha` is the damping parameter, and *erf()* and *erfc()*
are error-function and complementary error-function terms. This

2
doc/src/compute_gaussian_grid_local.rst
View File

@ -30,7 +30,7 @@ Examples
Description
"""""""""""
.. versionadded:: TBD
.. versionadded:: 4Feb2025
Define a computation that calculates a Gaussian representation of the ionic
structure. This representation is used for the efficient evaluation

2
doc/src/compute_hexorder_atom.rst
View File

@ -40,7 +40,7 @@ is a complex number (stored as two real numbers) defined as follows:
.. math::
q_n = \frac{1}{nnn}\sum_{j = 1}^{nnn} e^{n i \theta({\bf r}_{ij})}
q_n = \frac{1}{nnn}\sum_{j = 1}^{nnn} e^{n i \theta({\textbf{r}}_{ij})}
where the sum is over the *nnn* nearest neighbors
of the central atom. The angle :math:`\theta`

4
doc/src/compute_msd.rst
View File

@ -116,7 +116,9 @@ Compute *msd* cannot be used with a dynamic group.
Related commands
""""""""""""""""
:doc:`compute msd/nongauss <compute_msd_nongauss>`, :doc:`compute displace_atom <compute_displace_atom>`, :doc:`fix store/state <fix_store_state>`, :doc:`compute msd/chunk <compute_msd_chunk>`
:doc:`compute msd/nongauss <compute_msd_nongauss>`,
:doc:`compute displace_atom <compute_displace_atom>`, :doc:`fix store/state <fix_store_state>`,
:doc:`compute msd/chunk <compute_msd_chunk>`
Default
"""""""

2
doc/src/compute_msd_chunk.rst
View File

@ -131,7 +131,7 @@ Restrictions
Related commands
""""""""""""""""
:doc:`compute msd <compute_msd>`
:doc:`compute msd <compute_msd>`, :doc:`compute vacf/chunk <compute_vacf_chunk>`
Default
"""""""

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