Merge remote-tracking branch 'upstream/develop' into upd/refactor-includes
# Conflicts: # cmake/Modules/Packages/ML-PACE.cmake
This commit is contained in:
1
.gitattributes
vendored
1
.gitattributes
vendored
@ -3,6 +3,7 @@
|
||||
.github export-ignore
|
||||
.lgtm.yml export-ignore
|
||||
SECURITY.md export-ignore
|
||||
CITATION.cff export-ignore
|
||||
* text=auto
|
||||
*.jpg -text
|
||||
*.pdf -text
|
||||
|
||||
6
.github/CODEOWNERS
vendored
6
.github/CODEOWNERS
vendored
@ -13,20 +13,21 @@ lib/kim/* @ellio167
|
||||
lib/mesont/* @iafoss
|
||||
|
||||
# whole packages
|
||||
src/AMOEBA/* @sjplimp
|
||||
src/COMPRESS/* @rbberger
|
||||
src/GPU/* @ndtrung81
|
||||
src/KOKKOS/* @stanmoore1
|
||||
src/KIM/* @ellio167
|
||||
src/LATTE/* @cnegre
|
||||
src/MESSAGE/* @sjplimp
|
||||
src/MLIAP/* @athomps
|
||||
src/SNAP/* @athomps
|
||||
src/SPIN/* @julient31
|
||||
src/BROWNIAN/* @samueljmcameron
|
||||
src/CG-DNA/* @ohenrich
|
||||
src/CG-SDK/* @akohlmey
|
||||
src/CG-SPICA/* @yskmiyazaki
|
||||
src/COLVARS/* @giacomofiorin
|
||||
src/DIELECTRIC/* @ndtrung81
|
||||
src/ELECTRODE/* @ludwig-ahrens
|
||||
src/FEP/* @agiliopadua
|
||||
src/ML-HDNNP/* @singraber
|
||||
src/INTEL/* @wmbrownintel
|
||||
@ -133,6 +134,7 @@ tools/coding_standard/* @rbberger
|
||||
tools/valgrind/* @akohlmey
|
||||
tools/swig/* @akohlmey
|
||||
tools/offline/* @rbberger
|
||||
tools/vim/* @hammondkd
|
||||
|
||||
# tests
|
||||
unittest/* @akohlmey @rbberger
|
||||
|
||||
6
.github/codecov.yml
vendored
6
.github/codecov.yml
vendored
@ -7,7 +7,7 @@ coverage:
|
||||
threshold: 10%
|
||||
only_pulls: false
|
||||
branches:
|
||||
- "master"
|
||||
- "develop"
|
||||
flags:
|
||||
- "unit"
|
||||
paths:
|
||||
@ -16,14 +16,14 @@ coverage:
|
||||
project:
|
||||
default:
|
||||
branches:
|
||||
- "master"
|
||||
- "develop"
|
||||
paths:
|
||||
- "src"
|
||||
informational: true
|
||||
patch:
|
||||
default:
|
||||
branches:
|
||||
- "master"
|
||||
- "develop"
|
||||
paths:
|
||||
- "src"
|
||||
informational: true
|
||||
|
||||
6
.github/workflows/compile-msvc.yml
vendored
6
.github/workflows/compile-msvc.yml
vendored
@ -3,7 +3,11 @@ name: "Native Windows Compilation and Unit Tests"
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [develop]
|
||||
branches:
|
||||
- develop
|
||||
pull_request:
|
||||
branches:
|
||||
- develop
|
||||
|
||||
workflow_dispatch:
|
||||
|
||||
|
||||
103
.github/workflows/coverity.yml
vendored
Normal file
103
.github/workflows/coverity.yml
vendored
Normal file
@ -0,0 +1,103 @@
|
||||
name: "Run Coverity Scan"
|
||||
|
||||
on:
|
||||
schedule:
|
||||
- cron: "0 0 * * FRI"
|
||||
|
||||
workflow_dispatch:
|
||||
|
||||
jobs:
|
||||
analyze:
|
||||
name: Analyze
|
||||
if: ${{ github.repository == 'lammps/lammps' }}
|
||||
runs-on: ubuntu-latest
|
||||
container:
|
||||
image: lammps/buildenv:ubuntu20.04
|
||||
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@v3
|
||||
with:
|
||||
fetch-depth: 2
|
||||
|
||||
- name: Create Build and Download Folder
|
||||
run: mkdir build download
|
||||
|
||||
- name: Cache Coverity
|
||||
id: cache-coverity
|
||||
uses: actions/cache@v3
|
||||
with:
|
||||
path: ./download/
|
||||
key: ${{ runner.os }}-download-${{ hashFiles('**/coverity_tool.*') }}
|
||||
|
||||
- name: Download Coverity if necessary
|
||||
if: steps.cache-coverity.outputs.cache-hit != 'true'
|
||||
working-directory: download
|
||||
run: |
|
||||
wget -nv https://scan.coverity.com/download/linux64 --post-data "token=${{ secrets.COVERITY_TOKEN }}&project=LAMMPS" -O coverity_tool.tgz
|
||||
wget -nv https://scan.coverity.com/download/linux64 --post-data "token=${{ secrets.COVERITY_TOKEN }}&project=LAMMPS&md5=1" -O coverity_tool.md5
|
||||
echo " coverity_tool.tgz" >> coverity_tool.md5
|
||||
md5sum -c coverity_tool.md5
|
||||
|
||||
- name: Setup Coverity
|
||||
run: |
|
||||
tar xzf download/coverity_tool.tgz
|
||||
ln -s cov-analysis-linux64-* coverity
|
||||
|
||||
- name: Configure LAMMPS via CMake
|
||||
shell: bash
|
||||
working-directory: build
|
||||
run: |
|
||||
cmake \
|
||||
-C ../cmake/presets/clang.cmake \
|
||||
-C ../cmake/presets/most.cmake \
|
||||
-C ../cmake/presets/kokkos-openmp.cmake \
|
||||
-D CMAKE_BUILD_TYPE="RelWithDebug" \
|
||||
-D CMAKE_TUNE_FLAGS="-Wall -Wextra -Wno-unused-result" \
|
||||
-D BUILD_MPI=on \
|
||||
-D BUILD_OMP=on \
|
||||
-D BUILD_SHARED_LIBS=on \
|
||||
-D LAMMPS_SIZES=SMALLBIG \
|
||||
-D LAMMPS_EXCEPTIONS=off \
|
||||
-D PKG_MESSAGE=on \
|
||||
-D PKG_MPIIO=on \
|
||||
-D PKG_ATC=on \
|
||||
-D PKG_AWPMD=on \
|
||||
-D PKG_BOCS=on \
|
||||
-D PKG_EFF=on \
|
||||
-D PKG_H5MD=on \
|
||||
-D PKG_INTEL=on \
|
||||
-D PKG_LATBOLTZ=on \
|
||||
-D PKG_MANIFOLD=on \
|
||||
-D PKG_MGPT=on \
|
||||
-D PKG_ML-PACE=on \
|
||||
-D PKG_ML-RANN=on \
|
||||
-D PKG_MOLFILE=on \
|
||||
-D PKG_NETCDF=on \
|
||||
-D PKG_PTM=on \
|
||||
-D PKG_QTB=on \
|
||||
-D PKG_SMTBQ=on \
|
||||
-D PKG_TALLY=on \
|
||||
../cmake
|
||||
|
||||
- name: Run Coverity Scan
|
||||
shell: bash
|
||||
working-directory: build
|
||||
run: |
|
||||
export PATH=$GITHUB_WORKSPACE/coverity/bin:$PATH
|
||||
cov-build --dir cov-int cmake --build . --parallel 2
|
||||
|
||||
- name: Create tarball with scan results
|
||||
shell: bash
|
||||
working-directory: build
|
||||
run: tar czf lammps.tgz cov-int
|
||||
|
||||
- name: Upload scan result to Coverity
|
||||
shell: bash
|
||||
run: |
|
||||
curl --form token=${{ secrets.COVERITY_TOKEN }} \
|
||||
--form email=${{ secrets.COVERITY_EMAIL }} \
|
||||
--form file=@build/lammps.tgz \
|
||||
--form version=${{ github.sha }} \
|
||||
--form description="LAMMPS automated build" \
|
||||
https://scan.coverity.com/builds?project=LAMMPS
|
||||
7
.github/workflows/unittest-macos.yml
vendored
7
.github/workflows/unittest-macos.yml
vendored
@ -3,7 +3,11 @@ name: "Unittest for MacOS"
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [develop]
|
||||
branches:
|
||||
- develop
|
||||
pull_request:
|
||||
branches:
|
||||
- develop
|
||||
|
||||
workflow_dispatch:
|
||||
|
||||
@ -39,6 +43,7 @@ jobs:
|
||||
working-directory: build
|
||||
run: |
|
||||
ccache -z
|
||||
python3 -m pip install numpy
|
||||
python3 -m pip install pyyaml
|
||||
cmake -C ../cmake/presets/clang.cmake \
|
||||
-C ../cmake/presets/most.cmake \
|
||||
|
||||
91
CITATION.cff
Normal file
91
CITATION.cff
Normal file
@ -0,0 +1,91 @@
|
||||
# YAML 1.2
|
||||
---
|
||||
cff-version: 1.2.0
|
||||
title: "LAMMPS: Large-scale Atomic/Molecular Massively Parallel Simulator"
|
||||
type: software
|
||||
authors:
|
||||
- family-names: "Plimpton"
|
||||
given-names: "Steven J."
|
||||
- family-names: "Kohlmeyer"
|
||||
given-names: "Axel"
|
||||
orcid: "https://orcid.org/0000-0001-6204-6475"
|
||||
- family-names: "Thompson"
|
||||
given-names: "Aidan P."
|
||||
orcid: "https://orcid.org/0000-0002-0324-9114"
|
||||
- family-names: "Moore"
|
||||
given-names: "Stan G."
|
||||
- family-names: "Berger"
|
||||
given-names: "Richard"
|
||||
orcid: "https://orcid.org/0000-0002-3044-8266"
|
||||
doi: 10.5281/zenodo.3726416
|
||||
license: GPL-2.0-only
|
||||
url: https://www.lammps.org
|
||||
repository-code: https://github.com/lammps/lammps/
|
||||
keywords:
|
||||
- "Molecular Dynamics"
|
||||
- "Materials Modeling"
|
||||
message: "If you are referencing LAMMPS in a publication, please cite the paper below."
|
||||
preferred-citation:
|
||||
type: article
|
||||
doi: "10.1016/j.cpc.2021.108171"
|
||||
url: "https://www.sciencedirect.com/science/article/pii/S0010465521002836"
|
||||
authors:
|
||||
- family-names: "Thompson"
|
||||
given-names: "Aidan P."
|
||||
orcid: "https://orcid.org/0000-0002-0324-9114"
|
||||
- family-names: "Aktulga"
|
||||
given-names: "H. Metin"
|
||||
- family-names: "Berger"
|
||||
given-names: "Richard"
|
||||
orcid: "https://orcid.org/0000-0002-3044-8266"
|
||||
- family-names: "Bolintineanu"
|
||||
given-names: "Dan S."
|
||||
- family-names: "Brown"
|
||||
given-names: "W. Michael"
|
||||
- family-names: "Crozier"
|
||||
given-names: "Paul S."
|
||||
- family-names: "in 't Veld"
|
||||
given-names: "Pieter J."
|
||||
- family-names: "Kohlmeyer"
|
||||
given-names: "Axel"
|
||||
orcid: "https://orcid.org/0000-0001-6204-6475"
|
||||
- family-names: "Moore"
|
||||
given-names: "Stan G."
|
||||
- family-names: "Nguyen"
|
||||
given-names: "Trung Dac"
|
||||
- family-names: "Shan"
|
||||
given-names: "Ray"
|
||||
- family-names: "Stevens"
|
||||
given-names: "Mark J."
|
||||
- family-names: "Tranchida"
|
||||
given-names: "Julien"
|
||||
- family-names: "Trott"
|
||||
given-names: "Christian"
|
||||
- family-names: "Plimpton"
|
||||
given-names: "Steven J."
|
||||
title: "LAMMPS - a flexible simulation tool for particle-based materials modeling at the atomic, meso, and continuum scales"
|
||||
journal: "Computer Physics Communications"
|
||||
keywords:
|
||||
- Molecular dynamics
|
||||
- Materials modeling
|
||||
- Parallel algorithms
|
||||
- LAMMPS
|
||||
month: 2
|
||||
volume: 271
|
||||
issn: 0010-4655
|
||||
pages: 108171
|
||||
year: 2022
|
||||
references:
|
||||
- title: "Fast Parallel Algorithms for Short-Range Molecular Dynamics"
|
||||
type: article
|
||||
journal: Journal of Computational Physics
|
||||
volume: 117
|
||||
number: 1
|
||||
pages: "1-19"
|
||||
year: 1995
|
||||
issn: 0021-9991
|
||||
doi: 10.1006/jcph.1995.1039
|
||||
url: https://www.sciencedirect.com/science/article/pii/S002199918571039X
|
||||
authors:
|
||||
- family-names: "Plimpton"
|
||||
given-names: "Steve"
|
||||
30
SECURITY.md
30
SECURITY.md
@ -14,14 +14,14 @@ and tested by the LAMMPS developers, so it is easy to import bad
|
||||
behavior from calling functions in one of those libraries.
|
||||
|
||||
Thus is is quite easy to crash LAMMPS through malicious input and do all
|
||||
kinds of filesystem manipulations. And because of that LAMMPS should
|
||||
kinds of file system manipulations. And because of that LAMMPS should
|
||||
**NEVER** be compiled or **run** as superuser, either from a "root" or
|
||||
"administrator" account directly or indirectly via "sudo" or "su".
|
||||
|
||||
Therefore what could be seen as a security vulnerability is usually
|
||||
either a user mistake or a bug in the code. Bugs can be reported in
|
||||
the LAMMPS project
|
||||
[issue tracker on GitHub](https://github.com/lammps/lammps/issues).
|
||||
either a user mistake or a bug in the code. Bugs can be reported in the
|
||||
LAMMPS project [issue tracker on
|
||||
GitHub](https://github.com/lammps/lammps/issues).
|
||||
|
||||
To mitigate issues with using homoglyphs or bidirectional reordering in
|
||||
unicode, which have been demonstrated as a vector to obfuscate and hide
|
||||
@ -30,10 +30,18 @@ for unicode characters and only all-ASCII source code is accepted.
|
||||
|
||||
# Version Updates
|
||||
|
||||
LAMMPS follows continuous release development model. We aim to keep all
|
||||
release versions (stable or patch) fully functional and employ a variety
|
||||
of automatic testing procedures to detect failures of existing
|
||||
functionality from adding new features before releases are made. Thus
|
||||
bugfixes and updates are only integrated into the current development
|
||||
branch and thus the next (patch) release and users are recommended to
|
||||
update regularly.
|
||||
LAMMPS follows continuous release development model. We aim to keep to
|
||||
keep the development version (develop branch) always fully functional
|
||||
and employ a variety of automatic testing procedures to detect failures
|
||||
of existing functionality from adding or modifying features. Most of
|
||||
those tests are run on pull requests *before* merging to the development
|
||||
branch. The develop branch is protected, so all changes *must* be
|
||||
submitted as a pull request and thus cannot avoid the automated tests.
|
||||
|
||||
Additional tests are run *after* merging. Before releases are made
|
||||
*all* tests must have cleared. Then a release tag is applied and the
|
||||
release branch fast-forwarded to that tag. Bug fixes and updates are
|
||||
applied to the current development branch and thus will be available in
|
||||
the next (patch) release. For stable releases, selected bug fixes are
|
||||
back-ported and occasionally published as update releases. There are
|
||||
only updates to the latest stable release.
|
||||
|
||||
@ -12,6 +12,11 @@ endif()
|
||||
if(POLICY CMP0109)
|
||||
cmake_policy(SET CMP0109 OLD)
|
||||
endif()
|
||||
# set policy to silence warnings about timestamps of downloaded files. review occasionally if it may be set to NEW
|
||||
if(POLICY CMP0135)
|
||||
cmake_policy(SET CMP0135 OLD)
|
||||
endif()
|
||||
|
||||
########################################
|
||||
|
||||
project(lammps CXX)
|
||||
@ -100,7 +105,7 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
|
||||
if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
|
||||
set(CMAKE_TUNE_DEFAULT "-xCOMMON-AVX512")
|
||||
else()
|
||||
set(CMAKE_TUNE_DEFAULT "-xHost")
|
||||
set(CMAKE_TUNE_DEFAULT "-xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=2196")
|
||||
endif()
|
||||
endif()
|
||||
endif()
|
||||
@ -135,13 +140,11 @@ set(CMAKE_CXX_EXTENSIONS OFF CACHE BOOL "Use compiler extensions")
|
||||
# ugly hacks for MSVC which by default always reports an old C++ standard in the __cplusplus macro
|
||||
# and prints lots of pointless warnings about "unsafe" functions
|
||||
if(MSVC)
|
||||
if(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
|
||||
if((CMAKE_CXX_COMPILER_ID STREQUAL "MSVC") OR (CMAKE_CXX_COMPILER_ID STREQUAL "Intel"))
|
||||
add_compile_options(/Zc:__cplusplus)
|
||||
add_compile_options(/wd4244)
|
||||
add_compile_options(/wd4267)
|
||||
if(LAMMPS_EXCEPTIONS)
|
||||
add_compile_options(/EHsc)
|
||||
endif()
|
||||
add_compile_options(/EHsc)
|
||||
endif()
|
||||
add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
|
||||
endif()
|
||||
@ -154,6 +157,19 @@ endif()
|
||||
########################################################################
|
||||
# User input options #
|
||||
########################################################################
|
||||
# set path to python interpreter and thus enforcing python version if
|
||||
# when in a virtual environment and PYTHON_EXECUTABLE is not set on command line
|
||||
if(DEFINED ENV{VIRTUAL_ENV} AND NOT PYTHON_EXECUTABLE)
|
||||
if(CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows")
|
||||
set(PYTHON_EXECUTABLE "$ENV{VIRTUAL_ENV}/Scripts/python.exe")
|
||||
else()
|
||||
set(PYTHON_EXECUTABLE "$ENV{VIRTUAL_ENV}/bin/python")
|
||||
endif()
|
||||
set(Python_EXECUTABLE "${PYTHON_EXECUTABLE}")
|
||||
message(STATUS "Running in virtual environment: $ENV{VIRTUAL_ENV}\n"
|
||||
" Setting Python interpreter to: ${PYTHON_EXECUTABLE}")
|
||||
endif()
|
||||
|
||||
set(LAMMPS_MACHINE "" CACHE STRING "Suffix to append to lmp binary (WON'T enable any features automatically")
|
||||
mark_as_advanced(LAMMPS_MACHINE)
|
||||
if(LAMMPS_MACHINE)
|
||||
@ -194,6 +210,7 @@ option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
|
||||
|
||||
set(STANDARD_PACKAGES
|
||||
ADIOS
|
||||
AMOEBA
|
||||
ASPHERE
|
||||
ATC
|
||||
AWPMD
|
||||
@ -202,7 +219,7 @@ set(STANDARD_PACKAGES
|
||||
BPM
|
||||
BROWNIAN
|
||||
CG-DNA
|
||||
CG-SDK
|
||||
CG-SPICA
|
||||
CLASS2
|
||||
COLLOID
|
||||
COLVARS
|
||||
@ -358,11 +375,13 @@ pkg_depends(MPIIO MPI)
|
||||
pkg_depends(ATC MANYBODY)
|
||||
pkg_depends(LATBOLTZ MPI)
|
||||
pkg_depends(SCAFACOS MPI)
|
||||
pkg_depends(AMOEBA KSPACE)
|
||||
pkg_depends(DIELECTRIC KSPACE)
|
||||
pkg_depends(DIELECTRIC EXTRA-PAIR)
|
||||
pkg_depends(CG-DNA MOLECULE)
|
||||
pkg_depends(CG-DNA ASPHERE)
|
||||
pkg_depends(ELECTRODE KSPACE)
|
||||
pkg_depends(EXTRA-MOLECULE MOLECULE)
|
||||
|
||||
# detect if we may enable OpenMP support by default
|
||||
set(BUILD_OMP_DEFAULT OFF)
|
||||
@ -402,9 +421,11 @@ endif()
|
||||
|
||||
if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_LATTE OR PKG_ELECTRODE)
|
||||
enable_language(C)
|
||||
find_package(LAPACK)
|
||||
find_package(BLAS)
|
||||
if(NOT LAPACK_FOUND OR NOT BLAS_FOUND)
|
||||
if (NOT USE_INTERNAL_LINALG)
|
||||
find_package(LAPACK)
|
||||
find_package(BLAS)
|
||||
endif()
|
||||
if(NOT LAPACK_FOUND OR NOT BLAS_FOUND OR USE_INTERNAL_LINALG)
|
||||
include(CheckGeneratorSupport)
|
||||
if(NOT CMAKE_GENERATOR_SUPPORT_FORTRAN)
|
||||
status(FATAL_ERROR "Cannot build internal linear algebra library as CMake build tool lacks Fortran support")
|
||||
@ -633,7 +654,7 @@ endif()
|
||||
# packages which selectively include variants based on enabled styles
|
||||
# e.g. accelerator packages
|
||||
######################################################################
|
||||
foreach(PKG_WITH_INCL CORESHELL DPD-SMOOTH PHONON QEQ OPENMP KOKKOS OPT INTEL GPU)
|
||||
foreach(PKG_WITH_INCL CORESHELL DPD-SMOOTH MISC PHONON QEQ OPENMP KOKKOS OPT INTEL GPU)
|
||||
if(PKG_${PKG_WITH_INCL})
|
||||
include(Packages/${PKG_WITH_INCL})
|
||||
endif()
|
||||
@ -780,9 +801,13 @@ if(BUILD_SHARED_LIBS)
|
||||
set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
|
||||
find_package(PythonInterp) # Deprecated since version 3.12
|
||||
if(PYTHONINTERP_FOUND)
|
||||
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
|
||||
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
|
||||
endif()
|
||||
else()
|
||||
# backward compatibility
|
||||
if(PYTHON_EXECUTABLE)
|
||||
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
|
||||
endif()
|
||||
find_package(Python COMPONENTS Interpreter)
|
||||
endif()
|
||||
if(BUILD_IS_MULTI_CONFIG)
|
||||
@ -815,16 +840,25 @@ endif()
|
||||
###############################################################################
|
||||
if(BUILD_SHARED_LIBS OR PKG_PYTHON)
|
||||
if(CMAKE_VERSION VERSION_LESS 3.12)
|
||||
# adjust so we find Python 3 versions before Python 2 on old systems with old CMake
|
||||
set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
|
||||
find_package(PythonInterp) # Deprecated since version 3.12
|
||||
if(PYTHONINTERP_FOUND)
|
||||
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
|
||||
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
|
||||
endif()
|
||||
else()
|
||||
# backward compatibility
|
||||
if(PYTHON_EXECUTABLE)
|
||||
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
|
||||
endif()
|
||||
find_package(Python COMPONENTS Interpreter)
|
||||
endif()
|
||||
if(Python_EXECUTABLE)
|
||||
file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/python)
|
||||
install(CODE "execute_process(COMMAND ${Python_EXECUTABLE} setup.py build -b ${CMAKE_BINARY_DIR}/python install --prefix=${CMAKE_INSTALL_PREFIX} --root=\$ENV{DESTDIR}/ WORKING_DIRECTORY ${LAMMPS_PYTHON_DIR})")
|
||||
file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/python/lib)
|
||||
file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/python/src)
|
||||
file(COPY ${LAMMPS_SOURCE_DIR}/version.h DESTINATION ${CMAKE_BINARY_DIR}/python/src)
|
||||
file(COPY ${LAMMPS_PYTHON_DIR}/README ${LAMMPS_PYTHON_DIR}/pyproject.toml ${LAMMPS_PYTHON_DIR}/setup.py ${LAMMPS_PYTHON_DIR}/lammps DESTINATION ${CMAKE_BINARY_DIR}/python/lib)
|
||||
install(CODE "if(\"\$ENV{DESTDIR}\" STREQUAL \"\")\n execute_process(COMMAND ${Python_EXECUTABLE} -m pip install -v ${CMAKE_BINARY_DIR}/python/lib --prefix=${CMAKE_INSTALL_PREFIX})\n else()\n execute_process(COMMAND ${Python_EXECUTABLE} -m pip install -v ${CMAKE_BINARY_DIR}/python/lib --prefix=${CMAKE_INSTALL_PREFIX} --root=\$ENV{DESTDIR})\n endif()")
|
||||
endif()
|
||||
endif()
|
||||
|
||||
|
||||
@ -110,14 +110,16 @@ function(FetchPotentials pkgfolder potfolder)
|
||||
math(EXPR plusone "${blank}+1")
|
||||
string(SUBSTRING ${line} 0 ${blank} pot)
|
||||
string(SUBSTRING ${line} ${plusone} -1 sum)
|
||||
if(EXISTS ${LAMMPS_POTENTIALS_DIR}/${pot})
|
||||
if(EXISTS "${LAMMPS_POTENTIALS_DIR}/${pot}")
|
||||
file(MD5 "${LAMMPS_POTENTIALS_DIR}/${pot}" oldsum)
|
||||
endif()
|
||||
if(NOT sum STREQUAL oldsum)
|
||||
message(STATUS "Checking external potential ${pot} from ${LAMMPS_POTENTIALS_URL}")
|
||||
file(DOWNLOAD "${LAMMPS_POTENTIALS_URL}/${pot}.${sum}" "${CMAKE_BINARY_DIR}/${pot}"
|
||||
message(STATUS "Downloading external potential ${pot} from ${LAMMPS_POTENTIALS_URL}")
|
||||
string(MD5 TMP_EXT "${CMAKE_BINARY_DIR}")
|
||||
file(DOWNLOAD "${LAMMPS_POTENTIALS_URL}/${pot}.${sum}" "${CMAKE_BINARY_DIR}/${pot}.${TMP_EXT}"
|
||||
EXPECTED_HASH MD5=${sum} SHOW_PROGRESS)
|
||||
file(COPY "${CMAKE_BINARY_DIR}/${pot}" DESTINATION ${LAMMPS_POTENTIALS_DIR})
|
||||
file(COPY "${CMAKE_BINARY_DIR}/${pot}.${TMP_EXT}" DESTINATION "${LAMMPS_POTENTIALS_DIR}")
|
||||
file(RENAME "${LAMMPS_POTENTIALS_DIR}/${pot}.${TMP_EXT}" "${LAMMPS_POTENTIALS_DIR}/${pot}")
|
||||
endif()
|
||||
endforeach()
|
||||
endif()
|
||||
|
||||
@ -233,7 +233,8 @@ elseif(GPU_API STREQUAL "OPENCL")
|
||||
elseif(GPU_API STREQUAL "HIP")
|
||||
if(NOT DEFINED HIP_PATH)
|
||||
if(NOT DEFINED ENV{HIP_PATH})
|
||||
set(HIP_PATH "/opt/rocm/hip" CACHE PATH "Path to HIP installation")
|
||||
message(FATAL_ERROR "GPU_API=HIP requires HIP_PATH to be defined.\n"
|
||||
"Either pass the HIP_PATH as a CMake option via -DHIP_PATH=... or set the HIP_PATH environment variable.")
|
||||
else()
|
||||
set(HIP_PATH $ENV{HIP_PATH} CACHE PATH "Path to HIP installation")
|
||||
endif()
|
||||
@ -261,6 +262,8 @@ elseif(GPU_API STREQUAL "HIP")
|
||||
|
||||
if(HIP_PLATFORM STREQUAL "hcc" OR HIP_PLATFORM STREQUAL "amd")
|
||||
set(HIP_ARCH "gfx906" CACHE STRING "HIP target architecture")
|
||||
elseif(HIP_PLATFORM STREQUAL "spirv")
|
||||
set(HIP_ARCH "spirv" CACHE STRING "HIP target architecture")
|
||||
elseif(HIP_PLATFORM STREQUAL "nvcc")
|
||||
find_package(CUDA REQUIRED)
|
||||
set(HIP_ARCH "sm_50" CACHE STRING "HIP primary CUDA architecture (e.g. sm_60)")
|
||||
@ -340,7 +343,14 @@ elseif(GPU_API STREQUAL "HIP")
|
||||
VERBATIM COMMAND ${HIP_HIPCC_EXECUTABLE} --fatbin --use_fast_math -DUSE_HIP -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES} ${HIP_CUDA_GENCODE} -I${LAMMPS_LIB_SOURCE_DIR}/gpu -o ${CUBIN_FILE} ${CU_FILE}
|
||||
DEPENDS ${CU_FILE}
|
||||
COMMENT "Generating ${CU_NAME}.cubin")
|
||||
endif()
|
||||
elseif(HIP_PLATFORM STREQUAL "spirv")
|
||||
configure_file(${CU_FILE} ${CU_CPP_FILE} COPYONLY)
|
||||
|
||||
add_custom_command(OUTPUT ${CUBIN_FILE}
|
||||
VERBATIM COMMAND ${HIP_HIPCC_EXECUTABLE} -c -O3 -DUSE_HIP -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES} -I${LAMMPS_LIB_SOURCE_DIR}/gpu -o ${CUBIN_FILE} ${CU_CPP_FILE}
|
||||
DEPENDS ${CU_CPP_FILE}
|
||||
COMMENT "Gerating ${CU_NAME}.cubin")
|
||||
endif()
|
||||
|
||||
add_custom_command(OUTPUT ${CUBIN_H_FILE}
|
||||
COMMAND ${CMAKE_COMMAND} -D SOURCE_DIR=${CMAKE_CURRENT_SOURCE_DIR} -D VARNAME=${CU_NAME} -D HEADER_FILE=${CUBIN_H_FILE} -D SOURCE_FILE=${CUBIN_FILE} -P ${CMAKE_CURRENT_SOURCE_DIR}/Modules/GenerateBinaryHeader.cmake
|
||||
|
||||
@ -47,8 +47,8 @@ if(DOWNLOAD_KOKKOS)
|
||||
list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
|
||||
list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
|
||||
include(ExternalProject)
|
||||
set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.6.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
|
||||
set(KOKKOS_MD5 "0ec97fc0c356dd65bd2487defe81a7bf" CACHE STRING "MD5 checksum of KOKKOS tarball")
|
||||
set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.7.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
|
||||
set(KOKKOS_MD5 "84991eca9f066383abe119a5bc7a11c4" CACHE STRING "MD5 checksum of KOKKOS tarball")
|
||||
mark_as_advanced(KOKKOS_URL)
|
||||
mark_as_advanced(KOKKOS_MD5)
|
||||
ExternalProject_Add(kokkos_build
|
||||
@ -72,7 +72,7 @@ if(DOWNLOAD_KOKKOS)
|
||||
add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
|
||||
add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
|
||||
elseif(EXTERNAL_KOKKOS)
|
||||
find_package(Kokkos 3.6.01 REQUIRED CONFIG)
|
||||
find_package(Kokkos 3.7.00 REQUIRED CONFIG)
|
||||
target_link_libraries(lammps PRIVATE Kokkos::kokkos)
|
||||
target_link_libraries(lmp PRIVATE Kokkos::kokkos)
|
||||
else()
|
||||
|
||||
@ -23,8 +23,9 @@ if(DOWNLOAD_LATTE)
|
||||
# CMake cannot pass BLAS or LAPACK library variable to external project if they are a list
|
||||
list(LENGTH BLAS_LIBRARIES} NUM_BLAS)
|
||||
list(LENGTH LAPACK_LIBRARIES NUM_LAPACK)
|
||||
if((NUM_BLAS GREATER 1) OR (NUM_LAPACK GREATER 1))
|
||||
message(FATAL_ERROR "Cannot compile downloaded LATTE library due to a technical limitation")
|
||||
if((NUM_BLAS GREATER 1) OR (NUM_LAPACK GREATER 1) AND NOT USE_INTERNAL_LINALG)
|
||||
message(FATAL_ERROR "Cannot compile downloaded LATTE library due to a technical limitation. "
|
||||
"Try to configure LAMMPS with '-D USE_INTERNAL_LINALG=on' added as a workaround.")
|
||||
endif()
|
||||
|
||||
include(ExternalProject)
|
||||
|
||||
@ -8,8 +8,8 @@ option(DOWNLOAD_MDI "Download and compile the MDI library instead of using an al
|
||||
|
||||
if(DOWNLOAD_MDI)
|
||||
message(STATUS "MDI download requested - we will build our own")
|
||||
set(MDI_URL "https://github.com/MolSSI-MDI/MDI_Library/archive/v1.4.1.tar.gz" CACHE STRING "URL for MDI tarball")
|
||||
set(MDI_MD5 "f9505fccd4c79301a619f6452dad4ad9" CACHE STRING "MD5 checksum for MDI tarball")
|
||||
set(MDI_URL "https://github.com/MolSSI-MDI/MDI_Library/archive/v1.4.12.tar.gz" CACHE STRING "URL for MDI tarball")
|
||||
set(MDI_MD5 "7a222353ae8e03961d5365e6cd48baee" CACHE STRING "MD5 checksum for MDI tarball")
|
||||
mark_as_advanced(MDI_URL)
|
||||
mark_as_advanced(MDI_MD5)
|
||||
enable_language(C)
|
||||
@ -26,8 +26,21 @@ if(DOWNLOAD_MDI)
|
||||
# detect if we have python development support and thus can enable python plugins
|
||||
set(MDI_USE_PYTHON_PLUGINS OFF)
|
||||
if(CMAKE_VERSION VERSION_LESS 3.12)
|
||||
if(NOT PYTHON_VERSION_STRING)
|
||||
set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
|
||||
# search for interpreter first, so we have a consistent library
|
||||
find_package(PythonInterp) # Deprecated since version 3.12
|
||||
if(PYTHONINTERP_FOUND)
|
||||
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
|
||||
endif()
|
||||
endif()
|
||||
# search for the library matching the selected interpreter
|
||||
set(Python_ADDITIONAL_VERSIONS ${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
|
||||
find_package(PythonLibs QUIET) # Deprecated since version 3.12
|
||||
if(PYTHONLIBS_FOUND)
|
||||
if(NOT (PYTHON_VERSION_STRING STREQUAL PYTHONLIBS_VERSION_STRING))
|
||||
message(FATAL_ERROR "Python Library version ${PYTHONLIBS_VERSION_STRING} does not match Interpreter version ${PYTHON_VERSION_STRING}")
|
||||
endif()
|
||||
set(MDI_USE_PYTHON_PLUGINS ON)
|
||||
endif()
|
||||
else()
|
||||
@ -36,6 +49,14 @@ if(DOWNLOAD_MDI)
|
||||
set(MDI_USE_PYTHON_PLUGINS ON)
|
||||
endif()
|
||||
endif()
|
||||
# python plugins are not supported and thus must be always off on Windows
|
||||
if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
|
||||
unset(Python_Development_FOUND)
|
||||
set(MDI_USE_PYTHON_PLUGINS OFF)
|
||||
if(CMAKE_CROSSCOMPILING)
|
||||
set(CMAKE_INSTALL_LIBDIR lib)
|
||||
endif()
|
||||
endif()
|
||||
|
||||
# download/ build MDI library
|
||||
# always build static library with -fpic
|
||||
@ -44,8 +65,9 @@ if(DOWNLOAD_MDI)
|
||||
ExternalProject_Add(mdi_build
|
||||
URL ${MDI_URL}
|
||||
URL_MD5 ${MDI_MD5}
|
||||
PREFIX ${CMAKE_CURRENT_BINARY_DIR}/mdi_build_ext
|
||||
CMAKE_ARGS
|
||||
-DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
|
||||
-DCMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/mdi_build_ext
|
||||
-DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
|
||||
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
|
||||
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
|
||||
@ -57,23 +79,23 @@ if(DOWNLOAD_MDI)
|
||||
-Dplugins=ON
|
||||
-Dpython_plugins=${MDI_USE_PYTHON_PLUGINS}
|
||||
UPDATE_COMMAND ""
|
||||
INSTALL_COMMAND ""
|
||||
BUILD_BYPRODUCTS "<BINARY_DIR>/MDI_Library/libmdi.a"
|
||||
INSTALL_COMMAND ${CMAKE_COMMAND} --build ${CMAKE_CURRENT_BINARY_DIR}/mdi_build_ext/src/mdi_build-build --target install
|
||||
BUILD_BYPRODUCTS "${CMAKE_CURRENT_BINARY_DIR}/mdi_build_ext/${CMAKE_INSTALL_LIBDIR}/mdi/${CMAKE_STATIC_LIBRARY_PREFIX}mdi${CMAKE_STATIC_LIBRARY_SUFFIX}"
|
||||
)
|
||||
|
||||
# where is the compiled library?
|
||||
ExternalProject_get_property(mdi_build BINARY_DIR)
|
||||
set(MDI_BINARY_DIR "${BINARY_DIR}/MDI_Library")
|
||||
ExternalProject_get_property(mdi_build PREFIX)
|
||||
# workaround for older CMake versions
|
||||
file(MAKE_DIRECTORY ${MDI_BINARY_DIR})
|
||||
file(MAKE_DIRECTORY ${PREFIX}/${CMAKE_INSTALL_LIBDIR}/mdi)
|
||||
file(MAKE_DIRECTORY ${PREFIX}/include/mdi)
|
||||
|
||||
# create imported target for the MDI library
|
||||
add_library(LAMMPS::MDI UNKNOWN IMPORTED)
|
||||
add_dependencies(LAMMPS::MDI mdi_build)
|
||||
set_target_properties(LAMMPS::MDI PROPERTIES
|
||||
IMPORTED_LOCATION "${MDI_BINARY_DIR}/libmdi.a"
|
||||
INTERFACE_INCLUDE_DIRECTORIES ${MDI_BINARY_DIR}
|
||||
)
|
||||
IMPORTED_LOCATION "${PREFIX}/${CMAKE_INSTALL_LIBDIR}/mdi/${CMAKE_STATIC_LIBRARY_PREFIX}mdi${CMAKE_STATIC_LIBRARY_SUFFIX}"
|
||||
INTERFACE_INCLUDE_DIRECTORIES ${PREFIX}/include/mdi
|
||||
)
|
||||
|
||||
set(MDI_DEP_LIBS "")
|
||||
# if compiling with python plugins we need
|
||||
|
||||
13
cmake/Modules/Packages/MISC.cmake
Normal file
13
cmake/Modules/Packages/MISC.cmake
Normal file
@ -0,0 +1,13 @@
|
||||
# pair style and fix srp/react depend on the fixes bond/break and bond/create from the MC package
|
||||
if(NOT PKG_MC)
|
||||
get_property(LAMMPS_FIX_HEADERS GLOBAL PROPERTY FIX)
|
||||
list(REMOVE_ITEM LAMMPS_FIX_HEADERS ${LAMMPS_SOURCE_DIR}/MISC/fix_srp_react.h)
|
||||
set_property(GLOBAL PROPERTY FIX "${LAMMPS_FIX_HEADERS}")
|
||||
get_property(LAMMPS_PAIR_HEADERS GLOBAL PROPERTY PAIR)
|
||||
list(REMOVE_ITEM LAMMPS_PAIR_HEADERS ${LAMMPS_SOURCE_DIR}/MISC/pair_srp_react.h)
|
||||
set_property(GLOBAL PROPERTY PAIR "${LAMMPS_PAIR_HEADERS}")
|
||||
get_target_property(LAMMPS_SOURCES lammps SOURCES)
|
||||
list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/MISC/fix_srp_react.cpp)
|
||||
list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/MISC/pair_srp_react.cpp)
|
||||
set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
|
||||
endif()
|
||||
@ -25,16 +25,18 @@ if(MLIAP_ENABLE_PYTHON)
|
||||
endif()
|
||||
|
||||
set(MLIAP_BINARY_DIR ${CMAKE_BINARY_DIR}/cython)
|
||||
set(MLIAP_CYTHON_SRC ${LAMMPS_SOURCE_DIR}/ML-IAP/mliap_model_python_couple.pyx)
|
||||
get_filename_component(MLIAP_CYTHON_BASE ${MLIAP_CYTHON_SRC} NAME_WE)
|
||||
file(GLOB MLIAP_CYTHON_SRC ${LAMMPS_SOURCE_DIR}/ML-IAP/*.pyx)
|
||||
file(MAKE_DIRECTORY ${MLIAP_BINARY_DIR})
|
||||
add_custom_command(OUTPUT ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.cpp ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.h
|
||||
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${MLIAP_CYTHON_SRC} ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.pyx
|
||||
COMMAND ${Cythonize_EXECUTABLE} -3 ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.pyx
|
||||
WORKING_DIRECTORY ${MLIAP_BINARY_DIR}
|
||||
MAIN_DEPENDENCY ${MLIAP_CYTHON_SRC}
|
||||
COMMENT "Generating C++ sources with cythonize...")
|
||||
foreach(MLIAP_CYTHON_FILE ${MLIAP_CYTHON_SRC})
|
||||
get_filename_component(MLIAP_CYTHON_BASE ${MLIAP_CYTHON_FILE} NAME_WE)
|
||||
add_custom_command(OUTPUT ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.cpp ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.h
|
||||
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${MLIAP_CYTHON_FILE} ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.pyx
|
||||
COMMAND ${Cythonize_EXECUTABLE} -3 ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.pyx
|
||||
WORKING_DIRECTORY ${MLIAP_BINARY_DIR}
|
||||
MAIN_DEPENDENCY ${MLIAP_CYTHON_FILE}
|
||||
COMMENT "Generating C++ sources with cythonize...")
|
||||
target_sources(lammps PRIVATE ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.cpp)
|
||||
endforeach()
|
||||
target_compile_definitions(lammps PRIVATE -DMLIAP_PYTHON)
|
||||
target_sources(lammps PRIVATE ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.cpp)
|
||||
target_include_directories(lammps PRIVATE ${MLIAP_BINARY_DIR})
|
||||
endif()
|
||||
|
||||
@ -15,24 +15,9 @@ execute_process(
|
||||
)
|
||||
get_newest_file(${CMAKE_BINARY_DIR}/lammps-user-pace-* lib-pace)
|
||||
|
||||
# enforce building libyaml-cpp as static library and turn off optional features
|
||||
set(YAML_BUILD_SHARED_LIBS OFF)
|
||||
set(YAML_CPP_BUILD_CONTRIB OFF)
|
||||
set(YAML_CPP_BUILD_TOOLS OFF)
|
||||
#add_subdirectory(${lib-pace}/yaml-cpp build-yaml-cpp)
|
||||
#set(YAML_CPP_INCLUDE_DIR ${lib-pace}/yaml-cpp/include)
|
||||
add_subdirectory(${lib-pace} build-pace)
|
||||
set_target_properties(pace PROPERTIES CXX_EXTENSIONS ON OUTPUT_NAME lammps_pace${LAMMPS_MACHINE})
|
||||
|
||||
#file(GLOB PACE_EVALUATOR_INCLUDE_DIR ${lib-pace}/ML-PACE)
|
||||
#file(GLOB PACE_EVALUATOR_SOURCES ${lib-pace}/ML-PACE/*/*.cpp)
|
||||
#list(FILTER PACE_EVALUATOR_SOURCES EXCLUDE REGEX pair_pace.cpp)
|
||||
#
|
||||
#add_library(pace STATIC ${PACE_EVALUATOR_SOURCES})
|
||||
#set_target_properties(pace PROPERTIES CXX_EXTENSIONS ON OUTPUT_NAME lammps_pace${LAMMPS_MACHINE})
|
||||
#target_include_directories(pace PUBLIC ${PACE_EVALUATOR_INCLUDE_DIR} ${YAML_CPP_INCLUDE_DIR}
|
||||
# ${WIGNER_INCLUDE_DIR} ${CNPY_INCLUDE_DIR})
|
||||
add_subdirectory(${lib-pace} build-ML-PACE)
|
||||
|
||||
#target_link_libraries(pace PRIVATE yaml-cpp-pace)
|
||||
if(CMAKE_PROJECT_NAME STREQUAL "lammps")
|
||||
target_link_libraries(lammps PRIVATE pace)
|
||||
endif()
|
||||
|
||||
@ -1,8 +1,28 @@
|
||||
if(CMAKE_VERSION VERSION_LESS 3.12)
|
||||
if(NOT PYTHON_VERSION_STRING)
|
||||
set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
|
||||
# search for interpreter first, so we have a consistent library
|
||||
find_package(PythonInterp) # Deprecated since version 3.12
|
||||
if(PYTHONINTERP_FOUND)
|
||||
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
|
||||
endif()
|
||||
endif()
|
||||
# search for the library matching the selected interpreter
|
||||
set(Python_ADDITIONAL_VERSIONS ${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
|
||||
find_package(PythonLibs REQUIRED) # Deprecated since version 3.12
|
||||
if(NOT (PYTHON_VERSION_STRING STREQUAL PYTHONLIBS_VERSION_STRING))
|
||||
message(FATAL_ERROR "Python Library version ${PYTHONLIBS_VERSION_STRING} does not match Interpreter version ${PYTHON_VERSION_STRING}")
|
||||
endif()
|
||||
target_include_directories(lammps PRIVATE ${PYTHON_INCLUDE_DIRS})
|
||||
target_link_libraries(lammps PRIVATE ${PYTHON_LIBRARIES})
|
||||
else()
|
||||
if(NOT Python_INTERPRETER)
|
||||
# backward compatibility
|
||||
if(PYTHON_EXECUTABLE)
|
||||
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
|
||||
endif()
|
||||
find_package(Python COMPONENTS Interpreter)
|
||||
endif()
|
||||
find_package(Python REQUIRED COMPONENTS Interpreter Development)
|
||||
target_link_libraries(lammps PRIVATE Python::Python)
|
||||
endif()
|
||||
|
||||
@ -3,6 +3,7 @@
|
||||
|
||||
set(ALL_PACKAGES
|
||||
ADIOS
|
||||
AMOEBA
|
||||
ASPHERE
|
||||
ATC
|
||||
AWPMD
|
||||
@ -11,7 +12,7 @@ set(ALL_PACKAGES
|
||||
BPM
|
||||
BROWNIAN
|
||||
CG-DNA
|
||||
CG-SDK
|
||||
CG-SPICA
|
||||
CLASS2
|
||||
COLLOID
|
||||
COLVARS
|
||||
|
||||
@ -5,6 +5,7 @@
|
||||
|
||||
set(ALL_PACKAGES
|
||||
ADIOS
|
||||
AMOEBA
|
||||
ASPHERE
|
||||
ATC
|
||||
AWPMD
|
||||
@ -13,7 +14,7 @@ set(ALL_PACKAGES
|
||||
BPM
|
||||
BROWNIAN
|
||||
CG-DNA
|
||||
CG-SDK
|
||||
CG-SPICA
|
||||
CLASS2
|
||||
COLLOID
|
||||
COLVARS
|
||||
|
||||
@ -3,6 +3,13 @@
|
||||
# prefer flang over gfortran, if available
|
||||
find_program(CLANG_FORTRAN NAMES flang gfortran f95)
|
||||
set(ENV{OMPI_FC} ${CLANG_FORTRAN})
|
||||
get_filename_component(_tmp_fc ${CLANG_FORTRAN} NAME)
|
||||
if (_tmp_fc STREQUAL "flang")
|
||||
set(FC_STD_VERSION "-std=f2018")
|
||||
set(BUILD_MPI OFF)
|
||||
else()
|
||||
set(FC_STD_VERSION "-std=f2003")
|
||||
endif()
|
||||
|
||||
set(CMAKE_CXX_COMPILER "clang++" CACHE STRING "" FORCE)
|
||||
set(CMAKE_C_COMPILER "clang" CACHE STRING "" FORCE)
|
||||
@ -10,9 +17,9 @@ set(CMAKE_Fortran_COMPILER ${CLANG_FORTRAN} CACHE STRING "" FORCE)
|
||||
set(CMAKE_CXX_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
|
||||
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
|
||||
set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
|
||||
set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -Wextra -g -std=f2003" CACHE STRING "" FORCE)
|
||||
set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
|
||||
set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
|
||||
set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -Wextra -g ${FC_STD_VERSION}" CACHE STRING "" FORCE)
|
||||
set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG ${FC_STD_VERSION}" CACHE STRING "" FORCE)
|
||||
set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG ${FC_STD_VERSION}" CACHE STRING "" FORCE)
|
||||
set(CMAKE_C_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
|
||||
set(CMAKE_C_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
|
||||
set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# preset that will enable Intel compilers with support for MPI and OpenMP (on Linux boxes)
|
||||
# preset that will enable the classic Intel compilers with support for MPI and OpenMP (on Linux boxes)
|
||||
|
||||
set(CMAKE_CXX_COMPILER "icpc" CACHE STRING "" FORCE)
|
||||
set(CMAKE_C_COMPILER "icc" CACHE STRING "" FORCE)
|
||||
@ -18,11 +18,11 @@ set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
|
||||
|
||||
unset(HAVE_OMP_H_INCLUDE CACHE)
|
||||
set(OpenMP_C "icc" CACHE STRING "" FORCE)
|
||||
set(OpenMP_C_FLAGS "-qopenmp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_C_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
|
||||
set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX "icpc" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX_FLAGS "-qopenmp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_Fortran_FLAGS "-qopenmp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_Fortran_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
|
||||
set(OpenMP_omp_LIBRARY "libiomp5.so" CACHE PATH "" FORCE)
|
||||
|
||||
|
||||
@ -1,4 +1,5 @@
|
||||
set(WIN_PACKAGES
|
||||
AMOEBA
|
||||
ASPHERE
|
||||
ATC
|
||||
AWPMD
|
||||
@ -7,7 +8,7 @@ set(WIN_PACKAGES
|
||||
BPM
|
||||
BROWNIAN
|
||||
CG-DNA
|
||||
CG-SDK
|
||||
CG-SPICA
|
||||
CLASS2
|
||||
COLLOID
|
||||
COLVARS
|
||||
|
||||
@ -3,13 +3,14 @@
|
||||
# are removed. The resulting binary should be able to run most inputs.
|
||||
|
||||
set(ALL_PACKAGES
|
||||
AMOEBA
|
||||
ASPHERE
|
||||
BOCS
|
||||
BODY
|
||||
BPM
|
||||
BROWNIAN
|
||||
CG-DNA
|
||||
CG-SDK
|
||||
CG-SPICA
|
||||
CLASS2
|
||||
COLLOID
|
||||
COLVARS
|
||||
|
||||
@ -18,11 +18,11 @@ set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
|
||||
|
||||
unset(HAVE_OMP_H_INCLUDE CACHE)
|
||||
set(OpenMP_C "icx" CACHE STRING "" FORCE)
|
||||
set(OpenMP_C_FLAGS "-qopenmp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_C_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
|
||||
set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX "icpx" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX_FLAGS "-qopenmp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_Fortran_FLAGS "-qopenmp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_Fortran_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
|
||||
set(OpenMP_omp_LIBRARY "libiomp5.so" CACHE PATH "" FORCE)
|
||||
|
||||
|
||||
@ -1,11 +1,12 @@
|
||||
set(WIN_PACKAGES
|
||||
AMOEBA
|
||||
ASPHERE
|
||||
BOCS
|
||||
BODY
|
||||
BPM
|
||||
BROWNIAN
|
||||
CG-DNA
|
||||
CG-SDK
|
||||
CG-SPICA
|
||||
CLASS2
|
||||
COLLOID
|
||||
COLVARS
|
||||
|
||||
@ -242,7 +242,6 @@ $(MATHJAX):
|
||||
$(ANCHORCHECK): $(VENV)
|
||||
@( \
|
||||
. $(VENV)/bin/activate; \
|
||||
(cd utils/converters;\
|
||||
python setup.py develop);\
|
||||
pip $(PIP_OPTIONS) install -e utils/converters;\
|
||||
deactivate;\
|
||||
)
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
.TH LAMMPS "1" "23 June 2022" "2022-6-23"
|
||||
.TH LAMMPS "1" "15 September 2022" "2022-9-15"
|
||||
.SH NAME
|
||||
.B LAMMPS
|
||||
\- Molecular Dynamics Simulator. Version 23 June 2022
|
||||
\- Molecular Dynamics Simulator. Version 15 September 2022
|
||||
|
||||
.SH SYNOPSIS
|
||||
.B lmp
|
||||
@ -161,7 +161,7 @@ list references for specific cite-able features used during a
|
||||
run.
|
||||
.TP
|
||||
\fB\-pk <style> [options]\fR or \fB\-package <style> [options]\fR
|
||||
Invoke the \fBpackage\R command with <style> and optional arguments.
|
||||
Invoke the \fBpackage\fR command with <style> and optional arguments.
|
||||
The syntax is the same as if the command appeared in an input script.
|
||||
For example "-pk gpu 2" is the same as "package gpu 2" in the input
|
||||
script. The possible styles and options are discussed in the
|
||||
|
||||
@ -314,7 +314,7 @@ Bibliography
|
||||
Espanol, Revenga, Physical Review E, 67, 026705 (2003).
|
||||
|
||||
**(Espanol1997)**
|
||||
Espanol, Europhys Lett, 40(6): 631-636 (1997). DOI: 10.1209/epl/i1997-00515-8
|
||||
Espanol, Europhys Lett, 40(6): 631-636 (1997). DOI:10.1209/epl/i1997-00515-8
|
||||
|
||||
**(Evans and Morriss)**
|
||||
Evans and Morriss, Phys Rev A, 30, 1528 (1984).
|
||||
@ -368,7 +368,7 @@ Bibliography
|
||||
Frenkel and Smit, Understanding Molecular Simulation, Academic Press, London, 2002.
|
||||
|
||||
**(GLE4MD)**
|
||||
`http://gle4md.org/ <http://gle4md.org/>`_
|
||||
`https://gle4md.org/ <https://gle4md.org/>`_
|
||||
|
||||
**(Gao)**
|
||||
Gao and Weber, Nuclear Instruments and Methods in Physics Research B 191 (2012) 504.
|
||||
@ -401,13 +401,13 @@ Bibliography
|
||||
Hayre, and Farago, Comp Phys Comm, 185, 524 (2014)
|
||||
|
||||
**(Groot)**
|
||||
Groot and Warren, J Chem Phys, 107: 4423-4435 (1997). DOI: 10.1063/1.474784
|
||||
Groot and Warren, J Chem Phys, 107: 4423-4435 (1997). DOI:10.1063/1.474784
|
||||
|
||||
**(Guenole)**
|
||||
Guenole, Noehring, Vaid, Houlle, Xie, Prakash, Bitzek, Comput Mater Sci, 175, 109584 (2020).
|
||||
|
||||
**(Gullet)**
|
||||
Gullet, Wagner, Slepoy, SANDIA Report 2003-8782 (2003).
|
||||
Gullet, Wagner, Slepoy, SANDIA Report 2003-8782 (2003). DOI:10.2172/918395
|
||||
|
||||
**(Guo)**
|
||||
Guo and Thirumalai, Journal of Molecular Biology, 263, 323-43 (1996).
|
||||
@ -461,7 +461,7 @@ Bibliography
|
||||
Hunt, Mol Simul, 42, 347 (2016).
|
||||
|
||||
**(IPI)**
|
||||
`http://epfl-cosmo.github.io/gle4md/index.html?page=ipi <http://epfl-cosmo.github.io/gle4md/index.html?page=ipi>`_
|
||||
`https://ipi-code.org/ <https://ipi-code.org/>`
|
||||
|
||||
**(IPI-CPC)**
|
||||
Ceriotti, More and Manolopoulos, Comp Phys Comm, 185, 1019-1026 (2014).
|
||||
@ -605,16 +605,16 @@ Bibliography
|
||||
I.\ Leven et al, J. Chem.Theory Comput. 12, 2896-905 (2016).
|
||||
|
||||
**(Li2013_POF)**
|
||||
Li, Hu, Wang, Ma, Zhou, Phys Fluids, 25: 072103 (2013). DOI: 10.1063/1.4812366.
|
||||
Li, Hu, Wang, Ma, Zhou, Phys Fluids, 25: 072103 (2013). DOI:10.1063/1.4812366.
|
||||
|
||||
**(Li2014_JCP)**
|
||||
Li, Tang, Lei, Caswell, Karniadakis, J Comput Phys, 265: 113-127 (2014). DOI: 10.1016/j.jcp.2014.02.003.
|
||||
Li, Tang, Lei, Caswell, Karniadakis, J Comput Phys, 265: 113-127 (2014). DOI:10.1016/j.jcp.2014.02.003.
|
||||
|
||||
**(Li2015_CC)**
|
||||
Li, Tang, Li, Karniadakis, Chem Commun, 51: 11038-11040 (2015). DOI: 10.1039/C5CC01684C.
|
||||
Li, Tang, Li, Karniadakis, Chem Commun, 51: 11038-11040 (2015). DOI:10.1039/C5CC01684C.
|
||||
|
||||
**(Li2015_JCP)**
|
||||
Li, Yazdani, Tartakovsky, Karniadakis, J Chem Phys, 143: 014101 (2015). DOI: 10.1063/1.4923254.
|
||||
Li, Yazdani, Tartakovsky, Karniadakis, J Chem Phys, 143: 014101 (2015). DOI:10.1063/1.4923254.
|
||||
|
||||
**(Lisal)**
|
||||
M.\ Lisal, J.K. Brennan, J. Bonet Avalos, "Dissipative particle dynamics at isothermal, isobaric, isoenergetic, and isoenthalpic conditions using Shardlow-like splitting algorithms.",
|
||||
@ -733,8 +733,8 @@ Bibliography
|
||||
**(Mishin)**
|
||||
Mishin, Mehl, and Papaconstantopoulos, Acta Mater, 53, 4029 (2005).
|
||||
|
||||
**(Mitchell and Finchham)**
|
||||
Mitchell, Finchham, J Phys Condensed Matter, 5, 1031-1038 (1993).
|
||||
**(Mitchell and Fincham)**
|
||||
Mitchell, Fincham, J Phys Condensed Matter, 5, 1031-1038 (1993).
|
||||
|
||||
**(Mitchell2011)**
|
||||
Mitchell. A non-local, ordinary-state-based viscoelasticity model for peridynamics. Sandia National Lab Report, 8064:1-28 (2011).
|
||||
@ -875,7 +875,7 @@ Bibliography
|
||||
G.A. Tribello, M. Bonomi, D. Branduardi, C. Camilloni and G. Bussi, Comp. Phys. Comm 185, 604 (2014)
|
||||
|
||||
**(Paquay)**
|
||||
Paquay and Kusters, Biophys. J., 110, 6, (2016). preprint available at `arXiv:1411.3019 <http://arxiv.org/abs/1411.3019/>`_.
|
||||
Paquay and Kusters, Biophys. J., 110, 6, (2016). preprint available at `arXiv:1411.3019 <https://arxiv.org/abs/1411.3019/>`_.
|
||||
|
||||
**(Park)**
|
||||
Park, Schulten, J. Chem. Phys. 120 (13), 5946 (2004)
|
||||
@ -1373,7 +1373,7 @@ Bibliography
|
||||
Zhu, Tajkhorshid, and Schulten, Biophys. J. 83, 154 (2002).
|
||||
|
||||
**(Ziegler)**
|
||||
J.F. Ziegler, J. P. Biersack and U. Littmark, "The Stopping and Range of Ions in Matter," Volume 1, Pergamon, 1985.
|
||||
J.F. Ziegler, J. P. Biersack and U. Littmark, "The Stopping and Range of Ions in Matter", Volume 1, Pergamon, 1985.
|
||||
|
||||
**(Zimmerman2004)**
|
||||
Zimmerman, JA; Webb, EB; Hoyt, JJ;. Jones, RE; Klein, PA; Bammann, DJ, "Calculation of stress in atomistic simulation." Special Issue of Modelling and Simulation in Materials Science and Engineering (2004),12:S319.
|
||||
|
||||
@ -140,7 +140,7 @@ of the LAMMPS project on GitHub.
|
||||
The unit testing facility is integrated into the CMake build process
|
||||
of the LAMMPS source code distribution itself. It can be enabled by
|
||||
setting ``-D ENABLE_TESTING=on`` during the CMake configuration step.
|
||||
It requires the `YAML <http://pyyaml.org/>`_ library and development
|
||||
It requires the `YAML <https://pyyaml.org/>`_ library and development
|
||||
headers (if those are not found locally a recent version will be
|
||||
downloaded and compiled along with LAMMPS and the test program) to
|
||||
compile and will download and compile a specific recent version of the
|
||||
|
||||
@ -123,6 +123,7 @@ CMake build
|
||||
-D GPU_API=value # value = opencl (default) or cuda or hip
|
||||
-D GPU_PREC=value # precision setting
|
||||
# value = double or mixed (default) or single
|
||||
-D HIP_PATH # path to HIP installation. Must be set if GPU_API=HIP
|
||||
-D GPU_ARCH=value # primary GPU hardware choice for GPU_API=cuda
|
||||
# value = sm_XX, see below
|
||||
# default is sm_50
|
||||
@ -179,10 +180,17 @@ set appropriate environment variables. Some variables such as
|
||||
:code:`HCC_AMDGPU_TARGET` (for ROCm <= 4.0) or :code:`CUDA_PATH` are necessary for :code:`hipcc`
|
||||
and the linker to work correctly.
|
||||
|
||||
Using CHIP-SPV implementation of HIP is now supported. It allows one to run HIP
|
||||
code on Intel GPUs via the OpenCL or Level Zero backends. To use CHIP-SPV, you must
|
||||
set :code:`-DHIP_USE_DEVICE_SORT=OFF` in your CMake command line as CHIP-SPV does not
|
||||
yet support hipCUB. The use of HIP for Intel GPUs is still experimental so you
|
||||
should only use this option in preparations to run on Aurora system at ANL.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
# AMDGPU target (ROCm <= 4.0)
|
||||
export HIP_PLATFORM=hcc
|
||||
export HIP_PATH=/path/to/HIP/install
|
||||
export HCC_AMDGPU_TARGET=gfx906
|
||||
cmake -D PKG_GPU=on -D GPU_API=HIP -D HIP_ARCH=gfx906 -D CMAKE_CXX_COMPILER=hipcc ..
|
||||
make -j 4
|
||||
@ -191,6 +199,7 @@ and the linker to work correctly.
|
||||
|
||||
# AMDGPU target (ROCm >= 4.1)
|
||||
export HIP_PLATFORM=amd
|
||||
export HIP_PATH=/path/to/HIP/install
|
||||
cmake -D PKG_GPU=on -D GPU_API=HIP -D HIP_ARCH=gfx906 -D CMAKE_CXX_COMPILER=hipcc ..
|
||||
make -j 4
|
||||
|
||||
@ -199,10 +208,20 @@ and the linker to work correctly.
|
||||
# CUDA target (not recommended, use GPU_ARCH=cuda)
|
||||
# !!! DO NOT set CMAKE_CXX_COMPILER !!!
|
||||
export HIP_PLATFORM=nvcc
|
||||
export HIP_PATH=/path/to/HIP/install
|
||||
export CUDA_PATH=/usr/local/cuda
|
||||
cmake -D PKG_GPU=on -D GPU_API=HIP -D HIP_ARCH=sm_70 ..
|
||||
make -j 4
|
||||
|
||||
.. code:: bash
|
||||
|
||||
# SPIR-V target (Intel GPUs)
|
||||
export HIP_PLATFORM=spirv
|
||||
export HIP_PATH=/path/to/HIP/install
|
||||
export CMAKE_CXX_COMPILER=<hipcc/clang++>
|
||||
cmake -D PKG_GPU=on -D GPU_API=HIP ..
|
||||
make -j 4
|
||||
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -295,7 +314,7 @@ detailed information is available at:
|
||||
|
||||
In addition to installing the KIM API, it is also necessary to install the
|
||||
library of KIM models (interatomic potentials).
|
||||
See `Obtaining KIM Models <http://openkim.org/doc/usage/obtaining-models>`_ to
|
||||
See `Obtaining KIM Models <https://openkim.org/doc/usage/obtaining-models>`_ to
|
||||
learn how to install a pre-build binary of the OpenKIM Repository of Models.
|
||||
See the list of all KIM models here: https://openkim.org/browse/models
|
||||
|
||||
@ -413,7 +432,7 @@ Enabling the extra unit tests have some requirements,
|
||||
``EAM_Dynamo_MendelevAckland_2007v3_Zr__MO_004835508849_000``,
|
||||
``EAM_Dynamo_ErcolessiAdams_1994_Al__MO_123629422045_005``, and
|
||||
``LennardJones612_UniversalShifted__MO_959249795837_003`` KIM models.
|
||||
See `Obtaining KIM Models <http://openkim.org/doc/usage/obtaining-models>`_
|
||||
See `Obtaining KIM Models <https://openkim.org/doc/usage/obtaining-models>`_
|
||||
to learn how to install a pre-built binary of the OpenKIM Repository of
|
||||
Models or see
|
||||
`Installing KIM Models <https://openkim.org/doc/usage/obtaining-models/#installing_models>`_
|
||||
@ -464,6 +483,9 @@ They must be specified in uppercase.
|
||||
* - **Arch-ID**
|
||||
- **HOST or GPU**
|
||||
- **Description**
|
||||
* - NATIVE
|
||||
- HOST
|
||||
- Local machine
|
||||
* - AMDAVX
|
||||
- HOST
|
||||
- AMD 64-bit x86 CPU (AVX 1)
|
||||
@ -503,9 +525,21 @@ They must be specified in uppercase.
|
||||
* - BDW
|
||||
- HOST
|
||||
- Intel Broadwell Xeon E-class CPU (AVX 2 + transactional mem)
|
||||
* - SKL
|
||||
- HOST
|
||||
- Intel Skylake Client CPU
|
||||
* - SKX
|
||||
- HOST
|
||||
- Intel Sky Lake Xeon E-class HPC CPU (AVX512 + transactional mem)
|
||||
- Intel Skylake Xeon Server CPU (AVX512)
|
||||
* - ICL
|
||||
- HOST
|
||||
- Intel Ice Lake Client CPU (AVX512)
|
||||
* - ICX
|
||||
- HOST
|
||||
- Intel Ice Lake Xeon Server CPU (AVX512)
|
||||
* - SPR
|
||||
- HOST
|
||||
- Intel Sapphire Rapids Xeon Server CPU (AVX512)
|
||||
* - KNC
|
||||
- HOST
|
||||
- Intel Knights Corner Xeon Phi
|
||||
@ -577,7 +611,10 @@ They must be specified in uppercase.
|
||||
- AMD GPU MI100 GFX908
|
||||
* - VEGA90A
|
||||
- GPU
|
||||
- AMD GPU
|
||||
- AMD GPU MI200 GFX90A
|
||||
* - INTEL_GEN
|
||||
- GPU
|
||||
- SPIR64-based devices, e.g. Intel GPUs, using JIT
|
||||
* - INTEL_DG1
|
||||
- GPU
|
||||
- Intel Iris XeMAX GPU
|
||||
@ -592,9 +629,12 @@ They must be specified in uppercase.
|
||||
- Intel GPU Gen12LP
|
||||
* - INTEL_XEHP
|
||||
- GPU
|
||||
- Intel GPUs Xe-HP
|
||||
- Intel GPU Xe-HP
|
||||
* - INTEL_PVC
|
||||
- GPU
|
||||
- Intel GPU Ponte Vecchio
|
||||
|
||||
This list was last updated for version 3.5.0 of the Kokkos library.
|
||||
This list was last updated for version 3.7.0 of the Kokkos library.
|
||||
|
||||
.. tabs::
|
||||
|
||||
@ -788,8 +828,10 @@ library.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D DOWNLOAD_LATTE=value # download LATTE for build, value = no (default) or yes
|
||||
-D LATTE_LIBRARY=path # LATTE library file (only needed if a custom location)
|
||||
-D DOWNLOAD_LATTE=value # download LATTE for build, value = no (default) or yes
|
||||
-D LATTE_LIBRARY=path # LATTE library file (only needed if a custom location)
|
||||
-D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
|
||||
# value = no (default) or yes
|
||||
|
||||
If ``DOWNLOAD_LATTE`` is set, the LATTE library will be downloaded
|
||||
and built inside the CMake build directory. If the LATTE library
|
||||
@ -797,6 +839,13 @@ library.
|
||||
``LATTE_LIBRARY`` is the filename (plus path) of the LATTE library
|
||||
file, not the directory the library file is in.
|
||||
|
||||
The LATTE library requires LAPACK (and BLAS) and CMake can identify
|
||||
their locations and pass that info to the LATTE build script. But
|
||||
on some systems this triggers a (current) limitation of CMake and
|
||||
the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
|
||||
those cases to use the bundled linear algebra library and work around
|
||||
the limitation.
|
||||
|
||||
.. tab:: Traditional make
|
||||
|
||||
You can download and build the LATTE library manually if you
|
||||
@ -1025,7 +1074,7 @@ VORONOI package
|
||||
-----------------------------
|
||||
|
||||
To build with this package, you must download and build the
|
||||
`Voro++ library <http://math.lbl.gov/voro++>`_ or install a
|
||||
`Voro++ library <https://math.lbl.gov/voro++>`_ or install a
|
||||
binary package provided by your operating system.
|
||||
|
||||
.. tabs::
|
||||
@ -1913,14 +1962,25 @@ within CMake will download the non-commercial use version.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D DOWNLOAD_QUIP=value # download OpenKIM API v2 for build, value = no (default) or yes
|
||||
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
|
||||
-D DOWNLOAD_QUIP=value # download QUIP library for build, value = no (default) or yes
|
||||
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
|
||||
-D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
|
||||
# value = no (default) or yes
|
||||
|
||||
CMake will try to download and build the QUIP library from GitHub, if it is not
|
||||
found on the local machine. This requires to have git installed. It will use the same compilers
|
||||
and flags as used for compiling LAMMPS. Currently this is only supported for the GNU and the
|
||||
Intel compilers. Set the ``QUIP_LIBRARY`` variable if you want to use a previously compiled
|
||||
and installed QUIP library and CMake cannot find it.
|
||||
CMake will try to download and build the QUIP library from GitHub,
|
||||
if it is not found on the local machine. This requires to have git
|
||||
installed. It will use the same compilers and flags as used for
|
||||
compiling LAMMPS. Currently this is only supported for the GNU
|
||||
and the Intel compilers. Set the ``QUIP_LIBRARY`` variable if you
|
||||
want to use a previously compiled and installed QUIP library and
|
||||
CMake cannot find it.
|
||||
|
||||
The QUIP library requires LAPACK (and BLAS) and CMake can identify
|
||||
their locations and pass that info to the QUIP build script. But
|
||||
on some systems this triggers a (current) limitation of CMake and
|
||||
the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
|
||||
those cases to use the bundled linear algebra library and work around
|
||||
the limitation.
|
||||
|
||||
.. tab:: Traditional make
|
||||
|
||||
|
||||
@ -48,18 +48,15 @@ Build using GNU make
|
||||
|
||||
The LAMMPS manual is written in `reStructuredText <rst_>`_ format which
|
||||
can be translated to different output format using the `Sphinx
|
||||
<sphinx_>`_ document generator tool. It also incorporates programmer
|
||||
documentation extracted from the LAMMPS C++ sources through the `Doxygen
|
||||
<https://doxygen.nl>`_ program. Currently the translation to HTML, PDF
|
||||
(via LaTeX), ePUB (for many e-book readers) and MOBI (for Amazon Kindle
|
||||
readers) are supported. For that to work a Python 3 interpreter, the
|
||||
``doxygen`` tools and internet access to download additional files and
|
||||
tools are required. This download is usually only required once or
|
||||
after the documentation folder is returned to a pristine state with
|
||||
``make clean-all``.
|
||||
|
||||
.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
|
||||
.. _sphinx: https://www.sphinx-doc.org
|
||||
<https://sphinx-doc.org>`_ document generator tool. It also
|
||||
incorporates programmer documentation extracted from the LAMMPS C++
|
||||
sources through the `Doxygen <https://doxygen.nl>`_ program. Currently
|
||||
the translation to HTML, PDF (via LaTeX), ePUB (for many e-book readers)
|
||||
and MOBI (for Amazon Kindle readers) are supported. For that to work a
|
||||
Python 3 interpreter, the ``doxygen`` tools and internet access to
|
||||
download additional files and tools are required. This download is
|
||||
usually only required once or after the documentation folder is returned
|
||||
to a pristine state with ``make clean-all``.
|
||||
|
||||
For the documentation build a python virtual environment is set up in
|
||||
the folder ``doc/docenv`` and various python packages are installed into
|
||||
@ -179,7 +176,7 @@ math expressions transparently into embedded images.
|
||||
For converting the generated ePUB file to a MOBI format file (for e-book
|
||||
readers, like Kindle, that cannot read ePUB), you also need to have the
|
||||
``ebook-convert`` tool from the "calibre" software
|
||||
installed. `http://calibre-ebook.com/ <http://calibre-ebook.com/>`_
|
||||
installed. `https://calibre-ebook.com/ <https://calibre-ebook.com/>`_
|
||||
Typing ``make mobi`` will first create the ePUB file and then convert
|
||||
it. On the Kindle readers in particular, you also have support for PDF
|
||||
files, so you could download and view the PDF version as an alternative.
|
||||
@ -219,9 +216,20 @@ be multiple tests run automatically:
|
||||
- A test that only standard, printable ASCII text characters are used.
|
||||
This runs the command ``env LC_ALL=C grep -n '[^ -~]' src/*.rst`` and
|
||||
thus prints all offending lines with filename and line number
|
||||
prepended to the screen. Special characters like the Angstrom
|
||||
:math:`\mathrm{\mathring{A}}` should be typeset with embedded math
|
||||
(like this ``:math:`\mathrm{\mathring{A}}```\ ).
|
||||
prepended to the screen. Special characters like Greek letters
|
||||
(:math:`\alpha~~\sigma~~\epsilon`), super- or subscripts
|
||||
(:math:`x^2~~\mathrm{U}_{LJ}`), mathematical expressions
|
||||
(:math:`\frac{1}{2}\mathrm{N}~~x\to\infty`), or the Angstrom symbol
|
||||
(:math:`\AA`) should be typeset with embedded LaTeX (like this
|
||||
``:math:`\alpha \sigma \epsilon```, ``:math:`x^2 \mathrm{E}_{LJ}```,
|
||||
``:math:`\frac{1}{2}\mathrm{N} x\to\infty```, or ``:math:`\AA```\ ).
|
||||
|
||||
- Embedded LaTeX is rendered in HTML output with `MathJax
|
||||
<https://www.mathjax.org/>`_ and in PDF output by passing the embedded
|
||||
text to LaTeX. Some care has to be taken, though, since there are
|
||||
limitations which macros and features can be used in either mode, so
|
||||
it is recommended to always check whether any new or changed
|
||||
documentation does translate and render correctly with either output.
|
||||
|
||||
- A test whether all styles are documented and listed in their
|
||||
respective overview pages. A typical output with warnings looks like this:
|
||||
@ -252,6 +260,5 @@ manual with ``make spelling``. This requires `a library called enchant
|
||||
positives* (e.g. keywords, names, abbreviations) those can be added to
|
||||
the file ``lammps/doc/utils/sphinx-config/false_positives.txt``.
|
||||
|
||||
.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
|
||||
|
||||
.. _lws: https://www.lammps.org
|
||||
.. _rst: https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html
|
||||
|
||||
@ -111,26 +111,25 @@ LAMMPS can use them if they are available on your system.
|
||||
files in its default search path. You must specify ``FFT_LIB``
|
||||
with the appropriate FFT libraries to include in the link.
|
||||
|
||||
The `KISS FFT library <http://kissfft.sf.net>`_ is included in the LAMMPS
|
||||
distribution. It is portable across all platforms. Depending on the size
|
||||
of the FFTs and the number of processors used, the other libraries listed
|
||||
here can be faster.
|
||||
The `KISS FFT library <https://github.com/mborgerding/kissfft>`_ is
|
||||
included in the LAMMPS distribution. It is portable across all
|
||||
platforms. Depending on the size of the FFTs and the number of
|
||||
processors used, the other libraries listed here can be faster.
|
||||
|
||||
However, note that long-range Coulombics are only a portion of the
|
||||
per-timestep CPU cost, FFTs are only a portion of long-range
|
||||
Coulombics, and 1d FFTs are only a portion of the FFT cost (parallel
|
||||
communication can be costly). A breakdown of these timings is printed
|
||||
to the screen at the end of a run when using the
|
||||
:doc:`kspace_style pppm <kspace_style>` command. The
|
||||
:doc:`Screen and logfile output <Run_output>`
|
||||
page gives more details. A more detailed (and time consuming)
|
||||
report of the FFT performance is generated with the
|
||||
per-timestep CPU cost, FFTs are only a portion of long-range Coulombics,
|
||||
and 1d FFTs are only a portion of the FFT cost (parallel communication
|
||||
can be costly). A breakdown of these timings is printed to the screen
|
||||
at the end of a run when using the :doc:`kspace_style pppm
|
||||
<kspace_style>` command. The :doc:`Screen and logfile output
|
||||
<Run_output>` page gives more details. A more detailed (and time
|
||||
consuming) report of the FFT performance is generated with the
|
||||
:doc:`kspace_modify fftbench yes <kspace_modify>` command.
|
||||
|
||||
FFTW is a fast, portable FFT library that should also work on any
|
||||
platform and can be faster than the KISS FFT library. You can
|
||||
download it from `www.fftw.org <http://www.fftw.org>`_. LAMMPS requires
|
||||
version 3.X; the legacy version 2.1.X is no longer supported.
|
||||
platform and can be faster than the KISS FFT library. You can download
|
||||
it from `www.fftw.org <https://www.fftw.org>`_. LAMMPS requires version
|
||||
3.X; the legacy version 2.1.X is no longer supported.
|
||||
|
||||
Building FFTW for your box should be as simple as ``./configure; make;
|
||||
make install``. The install command typically requires root privileges
|
||||
|
||||
@ -21,6 +21,7 @@ commands in it are used to define a LAMMPS simulation.
|
||||
Commands_pair
|
||||
Commands_bond
|
||||
Commands_kspace
|
||||
Commands_dump
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
@ -10,11 +10,14 @@
|
||||
* :ref:`Dihedral styles <dihedral>`
|
||||
* :ref:`Improper styles <improper>`
|
||||
* :doc:`KSpace styles <Commands_kspace>`
|
||||
* :doc:`Dump styles <Commands_dump>`
|
||||
|
||||
General commands
|
||||
================
|
||||
|
||||
An alphabetic list of general LAMMPS commands.
|
||||
An alphabetic list of general LAMMPS commands. Note that style
|
||||
commands with many variants, can be more easily accessed via the small
|
||||
table above.
|
||||
|
||||
.. table_from_list::
|
||||
:columns: 5
|
||||
@ -60,6 +63,7 @@ An alphabetic list of general LAMMPS commands.
|
||||
* :doc:`kspace_modify <kspace_modify>`
|
||||
* :doc:`kspace_style <kspace_style>`
|
||||
* :doc:`label <label>`
|
||||
* :doc:`labelmap <labelmap>`
|
||||
* :doc:`lattice <lattice>`
|
||||
* :doc:`log <log>`
|
||||
* :doc:`mass <mass>`
|
||||
|
||||
@ -10,6 +10,7 @@
|
||||
* :ref:`Dihedral styles <dihedral>`
|
||||
* :ref:`Improper styles <improper>`
|
||||
* :doc:`KSpace styles <Commands_kspace>`
|
||||
* :doc:`Dump styles <Commands_dump>`
|
||||
|
||||
.. _bond:
|
||||
|
||||
@ -43,6 +44,7 @@ OPT.
|
||||
* :doc:`harmonic (iko) <bond_harmonic>`
|
||||
* :doc:`harmonic/shift (o) <bond_harmonic_shift>`
|
||||
* :doc:`harmonic/shift/cut (o) <bond_harmonic_shift_cut>`
|
||||
* :doc:`mesocnt <bond_mesocnt>`
|
||||
* :doc:`mm3 <bond_mm3>`
|
||||
* :doc:`morse (o) <bond_morse>`
|
||||
* :doc:`nonlinear (o) <bond_nonlinear>`
|
||||
@ -74,6 +76,7 @@ OPT.
|
||||
*
|
||||
*
|
||||
*
|
||||
* :doc:`amoeba <angle_amoeba>`
|
||||
* :doc:`charmm (iko) <angle_charmm>`
|
||||
* :doc:`class2 (ko) <angle_class2>`
|
||||
* :doc:`class2/p6 <angle_class2>`
|
||||
@ -90,9 +93,10 @@ OPT.
|
||||
* :doc:`fourier/simple (o) <angle_fourier_simple>`
|
||||
* :doc:`gaussian <angle_gaussian>`
|
||||
* :doc:`harmonic (iko) <angle_harmonic>`
|
||||
* :doc:`mesocnt <angle_mesocnt>`
|
||||
* :doc:`mm3 <angle_mm3>`
|
||||
* :doc:`quartic (o) <angle_quartic>`
|
||||
* :doc:`sdk (o) <angle_sdk>`
|
||||
* :doc:`spica (o) <angle_spica>`
|
||||
* :doc:`table (o) <angle_table>`
|
||||
|
||||
.. _dihedral:
|
||||
@ -152,6 +156,7 @@ OPT.
|
||||
*
|
||||
*
|
||||
*
|
||||
* :doc:`amoeba <improper_amoeba>`
|
||||
* :doc:`class2 (ko) <improper_class2>`
|
||||
* :doc:`cossq (o) <improper_cossq>`
|
||||
* :doc:`cvff (io) <improper_cvff>`
|
||||
|
||||
@ -10,6 +10,7 @@
|
||||
* :ref:`Dihedral styles <dihedral>`
|
||||
* :ref:`Improper styles <improper>`
|
||||
* :doc:`KSpace styles <Commands_kspace>`
|
||||
* :doc:`Dump styles <Commands_dump>`
|
||||
|
||||
Compute commands
|
||||
================
|
||||
|
||||
56
doc/src/Commands_dump.rst
Normal file
56
doc/src/Commands_dump.rst
Normal file
@ -0,0 +1,56 @@
|
||||
.. table_from_list::
|
||||
:columns: 3
|
||||
|
||||
* :doc:`General commands <Commands_all>`
|
||||
* :doc:`Fix styles <Commands_fix>`
|
||||
* :doc:`Compute styles <Commands_compute>`
|
||||
* :doc:`Pair styles <Commands_pair>`
|
||||
* :ref:`Bond styles <bond>`
|
||||
* :ref:`Angle styles <angle>`
|
||||
* :ref:`Dihedral styles <dihedral>`
|
||||
* :ref:`Improper styles <improper>`
|
||||
* :doc:`KSpace styles <Commands_kspace>`
|
||||
* :doc:`Dump styles <Commands_dump>`
|
||||
|
||||
Dump commands
|
||||
=============
|
||||
|
||||
An alphabetic list of all LAMMPS :doc:`dump <dump>` commands.
|
||||
|
||||
.. table_from_list::
|
||||
:columns: 5
|
||||
|
||||
* :doc:`atom <dump>`
|
||||
* :doc:`atom/adios <dump_adios>`
|
||||
* :doc:`atom/gz <dump>`
|
||||
* :doc:`atom/mpiio <dump>`
|
||||
* :doc:`atom/zstd <dump>`
|
||||
* :doc:`cfg <dump>`
|
||||
* :doc:`cfg/gz <dump>`
|
||||
* :doc:`cfg/mpiio <dump>`
|
||||
* :doc:`cfg/uef <dump_cfg_uef>`
|
||||
* :doc:`cfg/zstd <dump>`
|
||||
* :doc:`custom <dump>`
|
||||
* :doc:`custom/adios <dump_adios>`
|
||||
* :doc:`custom/gz <dump>`
|
||||
* :doc:`custom/mpiio <dump>`
|
||||
* :doc:`custom/zstd <dump>`
|
||||
* :doc:`dcd <dump>`
|
||||
* :doc:`deprecated <dump>`
|
||||
* :doc:`h5md <dump_h5md>`
|
||||
* :doc:`image <dump_image>`
|
||||
* :doc:`local <dump>`
|
||||
* :doc:`local/gz <dump>`
|
||||
* :doc:`local/zstd <dump>`
|
||||
* :doc:`molfile <dump_molfile>`
|
||||
* :doc:`movie <dump_image>`
|
||||
* :doc:`netcdf <dump_netcdf>`
|
||||
* :doc:`netcdf/mpiio <dump>`
|
||||
* :doc:`vtk <dump_vtk>`
|
||||
* :doc:`xtc <dump>`
|
||||
* :doc:`xyz <dump>`
|
||||
* :doc:`xyz/gz <dump>`
|
||||
* :doc:`xyz/mpiio <dump>`
|
||||
* :doc:`xyz/zstd <dump>`
|
||||
* :doc:`yaml <dump>`
|
||||
|
||||
@ -10,6 +10,7 @@
|
||||
* :ref:`Dihedral styles <dihedral>`
|
||||
* :ref:`Improper styles <improper>`
|
||||
* :doc:`KSpace styles <Commands_kspace>`
|
||||
* :doc:`Dump styles <Commands_dump>`
|
||||
|
||||
Fix commands
|
||||
============
|
||||
@ -28,6 +29,8 @@ OPT.
|
||||
* :doc:`adapt/fep <fix_adapt_fep>`
|
||||
* :doc:`addforce <fix_addforce>`
|
||||
* :doc:`addtorque <fix_addtorque>`
|
||||
* :doc:`amoeba/bitorsion <fix_amoeba_bitorsion>`
|
||||
* :doc:`amoeba/pitorsion <fix_amoeba_pitorsion>`
|
||||
* :doc:`append/atoms <fix_append_atoms>`
|
||||
* :doc:`atc <fix_atc>`
|
||||
* :doc:`atom/swap <fix_atom_swap>`
|
||||
@ -162,6 +165,7 @@ OPT.
|
||||
* :doc:`orient/fcc <fix_orient>`
|
||||
* :doc:`orient/eco <fix_orient_eco>`
|
||||
* :doc:`pafi <fix_pafi>`
|
||||
* :doc:`pair <fix_pair>`
|
||||
* :doc:`phonon <fix_phonon>`
|
||||
* :doc:`pimd <fix_pimd>`
|
||||
* :doc:`planeforce <fix_planeforce>`
|
||||
|
||||
@ -10,6 +10,7 @@
|
||||
* :ref:`Dihedral styles <dihedral>`
|
||||
* :ref:`Improper styles <improper>`
|
||||
* :doc:`KSpace styles <Commands_kspace>`
|
||||
* :doc:`Dump styles <Commands_dump>`
|
||||
|
||||
KSpace solvers
|
||||
==============
|
||||
|
||||
@ -10,6 +10,7 @@
|
||||
* :ref:`Dihedral styles <dihedral>`
|
||||
* :ref:`Improper styles <improper>`
|
||||
* :doc:`KSpace styles <Commands_kspace>`
|
||||
* :doc:`Dump styles <Commands_dump>`
|
||||
|
||||
Pair_style potentials
|
||||
======================
|
||||
@ -38,6 +39,7 @@ OPT.
|
||||
* :doc:`agni (o) <pair_agni>`
|
||||
* :doc:`airebo (io) <pair_airebo>`
|
||||
* :doc:`airebo/morse (io) <pair_airebo>`
|
||||
* :doc:`amoeba <pair_amoeba>`
|
||||
* :doc:`atm <pair_atm>`
|
||||
* :doc:`awpmd/cut <pair_awpmd>`
|
||||
* :doc:`beck (go) <pair_beck>`
|
||||
@ -124,6 +126,7 @@ OPT.
|
||||
* :doc:`hbond/dreiding/lj (o) <pair_hbond_dreiding>`
|
||||
* :doc:`hbond/dreiding/morse (o) <pair_hbond_dreiding>`
|
||||
* :doc:`hdnnp <pair_hdnnp>`
|
||||
* :doc:`hippo <pair_amoeba>`
|
||||
* :doc:`ilp/graphene/hbn (t) <pair_ilp_graphene_hbn>`
|
||||
* :doc:`ilp/tmd (t) <pair_ilp_tmd>`
|
||||
* :doc:`kolmogorov/crespi/full <pair_kolmogorov_crespi_full>`
|
||||
@ -179,9 +182,9 @@ OPT.
|
||||
* :doc:`lj/long/tip4p/long (o) <pair_lj_long>`
|
||||
* :doc:`lj/mdf <pair_mdf>`
|
||||
* :doc:`lj/relres (o) <pair_lj_relres>`
|
||||
* :doc:`lj/sdk (gko) <pair_sdk>`
|
||||
* :doc:`lj/sdk/coul/long (go) <pair_sdk>`
|
||||
* :doc:`lj/sdk/coul/msm (o) <pair_sdk>`
|
||||
* :doc:`lj/spica (gko) <pair_spica>`
|
||||
* :doc:`lj/spica/coul/long (go) <pair_spica>`
|
||||
* :doc:`lj/spica/coul/msm (o) <pair_spica>`
|
||||
* :doc:`lj/sf/dipole/sf (go) <pair_dipole>`
|
||||
* :doc:`lj/smooth (go) <pair_lj_smooth>`
|
||||
* :doc:`lj/smooth/linear (o) <pair_lj_smooth_linear>`
|
||||
@ -198,6 +201,7 @@ OPT.
|
||||
* :doc:`meam/spline (o) <pair_meam_spline>`
|
||||
* :doc:`meam/sw/spline <pair_meam_sw_spline>`
|
||||
* :doc:`mesocnt <pair_mesocnt>`
|
||||
* :doc:`mesocnt/viscous <pair_mesocnt>`
|
||||
* :doc:`mesont/tpm <pair_mesont_tpm>`
|
||||
* :doc:`mgpt <pair_mgpt>`
|
||||
* :doc:`mie/cut (g) <pair_mie>`
|
||||
@ -232,6 +236,7 @@ OPT.
|
||||
* :doc:`oxrna2/xstk <pair_oxrna2>`
|
||||
* :doc:`oxrna2/coaxstk <pair_oxrna2>`
|
||||
* :doc:`pace (k) <pair_pace>`
|
||||
* :doc:`pace/extrapolation <pair_pace>`
|
||||
* :doc:`peri/eps <pair_peri>`
|
||||
* :doc:`peri/lps (o) <pair_peri>`
|
||||
* :doc:`peri/pmb (o) <pair_peri>`
|
||||
@ -268,6 +273,7 @@ OPT.
|
||||
* :doc:`spin/magelec <pair_spin_magelec>`
|
||||
* :doc:`spin/neel <pair_spin_neel>`
|
||||
* :doc:`srp <pair_srp>`
|
||||
* :doc:`srp/react <pair_srp>`
|
||||
* :doc:`sw (giko) <pair_sw>`
|
||||
* :doc:`sw/angle/table <pair_sw_angle_table>`
|
||||
* :doc:`sw/mod (o) <pair_sw>`
|
||||
|
||||
@ -123,14 +123,15 @@ LAMMPS:
|
||||
.. _six:
|
||||
|
||||
6. If you want text with spaces to be treated as a single argument, it
|
||||
can be enclosed in either single or double or triple quotes. A long
|
||||
single argument enclosed in single or double quotes can span multiple
|
||||
lines if the "&" character is used, as described above. When the
|
||||
lines are concatenated together (and the "&" characters and line
|
||||
breaks removed), the text will become a single line. If you want
|
||||
multiple lines of an argument to retain their line breaks, the text
|
||||
can be enclosed in triple quotes, in which case "&" characters are
|
||||
not needed. For example:
|
||||
can be enclosed in either single (') or double (") or triple (""")
|
||||
quotes. A long single argument enclosed in single or double quotes
|
||||
can span multiple lines if the "&" character is used, as described
|
||||
in :ref:`1 <one>` above. When the lines are concatenated together
|
||||
by LAMMPS (and the "&" characters and line breaks removed), the
|
||||
combined text will become a single line. If you want multiple lines
|
||||
of an argument to retain their line breaks, the text can be enclosed
|
||||
in triple quotes, in which case "&" characters are not needed and do
|
||||
not function as line continuation character. For example:
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
@ -144,8 +145,9 @@ LAMMPS:
|
||||
System temperature = $t
|
||||
"""
|
||||
|
||||
In each case, the single, double, or triple quotes are removed when
|
||||
the single argument they enclose is stored internally.
|
||||
In each of these cases, the single, double, or triple quotes are
|
||||
removed and the enclosed text stored internally as a single
|
||||
argument.
|
||||
|
||||
See the :doc:`dump modify format <dump_modify>`, :doc:`print
|
||||
<print>`, :doc:`if <if>`, and :doc:`python <python>` commands for
|
||||
|
||||
@ -17,6 +17,7 @@ of time and requests from the LAMMPS user community.
|
||||
Developer_flow
|
||||
Developer_write
|
||||
Developer_notes
|
||||
Developer_updating
|
||||
Developer_plugins
|
||||
Developer_unittest
|
||||
Classes
|
||||
|
||||
425
doc/src/Developer_updating.rst
Normal file
425
doc/src/Developer_updating.rst
Normal file
@ -0,0 +1,425 @@
|
||||
Notes for updating code written for older LAMMPS versions
|
||||
---------------------------------------------------------
|
||||
|
||||
This section documents how C++ source files that are available *outside
|
||||
of the LAMMPS source distribution* (e.g. in external USER packages or as
|
||||
source files provided as a supplement to a publication) that are written
|
||||
for an older version of LAMMPS and thus need to be updated to be
|
||||
compatible with the current version of LAMMPS. Due to the active
|
||||
development of LAMMPS it is likely to always be incomplete. Please
|
||||
contact developer@lammps.org in case you run across an issue that is not
|
||||
(yet) listed here. Please also review the latest information about the
|
||||
LAMMPS :doc:`programming style conventions <Modify_style>`, especially
|
||||
if you are considering to submit the updated version for inclusion into
|
||||
the LAMMPS distribution.
|
||||
|
||||
Available topics in mostly chronological order are:
|
||||
|
||||
- `Setting flags in the constructor`_
|
||||
- `Rename of pack/unpack_comm() to pack/unpack_forward_comm()`_
|
||||
- `Use ev_init() to initialize variables derived from eflag and vflag`_
|
||||
- `Use utils::numeric() functions instead of force->numeric()`_
|
||||
- `Use utils::open_potential() function to open potential files`_
|
||||
- `Simplify customized error messages`_
|
||||
- `Use of "override" instead of "virtual"`_
|
||||
- `Simplified and more compact neighbor list requests`_
|
||||
- `Split of fix STORE into fix STORE/GLOBAL and fix STORE/PERATOM`_
|
||||
- `Use Output::get_dump_by_id() instead of Output::find_dump()`_
|
||||
|
||||
----
|
||||
|
||||
Setting flags in the constructor
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
As LAMMPS gains additional functionality, new flags may need to be set
|
||||
in the constructor or a class to signal compatibility with such features.
|
||||
Most of the time the defaults are chosen conservatively, but sometimes
|
||||
the conservative choice is the uncommon choice, and then those settings
|
||||
need to be made when updating code.
|
||||
|
||||
Pair styles:
|
||||
|
||||
- ``manybody_flag``: set to 1 if your pair style is not pair-wise additive
|
||||
- ``restartinfo``: set to 0 if your pair style does not store data in restart files
|
||||
|
||||
|
||||
Rename of pack/unpack_comm() to pack/unpack_forward_comm()
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionchanged:: 8Aug2014
|
||||
|
||||
In this change set the functions to pack data into communication buffers
|
||||
and to unpack data from communication buffers for :doc:`forward
|
||||
communications <Developer_comm_ops>` were renamed from ``pack_comm()``
|
||||
and ``unpack_comm()`` to ``pack_forward_comm()`` and
|
||||
``unpack_forward_comm()``, respectively. Also the meaning of the return
|
||||
value of these functions was changed: rather than returning the number
|
||||
of items per atom stored in the buffer, now the total number of items
|
||||
added (or unpacked) needs to be returned. Here is an example from the
|
||||
`PairEAM` class. Of course the member function declaration in corresponding
|
||||
header file needs to be updated accordingly.
|
||||
|
||||
Old:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
int PairEAM::pack_comm(int n, int *list, double *buf, int pbc_flag, int *pbc)
|
||||
{
|
||||
int m = 0;
|
||||
for (int i = 0; i < n; i++) {
|
||||
int j = list[i];
|
||||
buf[m++] = fp[j];
|
||||
}
|
||||
return 1;
|
||||
}
|
||||
|
||||
New:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
int PairEAM::pack_forward_comm(int n, int *list, double *buf, int pbc_flag, int *pbc)
|
||||
{
|
||||
int m = 0;
|
||||
for (int i = 0; i < n; i++) {
|
||||
int j = list[i];
|
||||
buf[m++] = fp[j];
|
||||
}
|
||||
return m;
|
||||
}
|
||||
|
||||
.. note::
|
||||
|
||||
Because the various "pack" and "unpack" functions are defined in the
|
||||
respective base classes as dummy functions doing nothing, and because
|
||||
of the the name mismatch the custom versions in the derived class
|
||||
will no longer be called, there will be no compilation error when
|
||||
this change is not applied. Only calculations will suddenly produce
|
||||
incorrect results because the required forward communication calls
|
||||
will cease to function correctly.
|
||||
|
||||
Use ev_init() to initialize variables derived from eflag and vflag
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionchanged:: 29Mar2019
|
||||
|
||||
There are several variables that need to be initialized based on
|
||||
the values of the "eflag" and "vflag" variables and since sometimes
|
||||
there are new bits added and new variables need to be set to 1 or 0.
|
||||
To make this consistent, across all styles, there is now an inline
|
||||
function ``ev_init(eflag, vflag)`` that makes those settings
|
||||
consistently and calls either ``ev_setup()`` or ``ev_unset()``.
|
||||
Example from a pair style:
|
||||
|
||||
Old:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
if (eflag || vflag) ev_setup(eflag, vflag);
|
||||
else evflag = vflag_fdotr = eflag_global = eflag_atom = 0;
|
||||
|
||||
New:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
ev_init(eflag, vflag);
|
||||
|
||||
Not applying this change will not cause a compilation error, but
|
||||
can lead to inconsistent behavior and incorrect tallying of
|
||||
energy or virial.
|
||||
|
||||
Use utils::numeric() functions instead of force->numeric()
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionchanged:: 18Sep2020
|
||||
|
||||
The "numeric()" conversion functions (including "inumeric()",
|
||||
"bnumeric()", and "tnumeric()") have been moved from the Force class to
|
||||
the utils namespace. Also they take an additional argument that selects
|
||||
whether the ``Error::all()`` or ``Error::one()`` function should be
|
||||
called in case of an error. The former should be used when *all* MPI
|
||||
processes call the conversion function and the latter *must* be used
|
||||
when they are called from only one or a subset of the MPI processes.
|
||||
|
||||
Old:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
val = force->numeric(FLERR, arg[1]);
|
||||
num = force->inumeric(FLERR, arg[2]);
|
||||
|
||||
New:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
val = utils::numeric(FLERR, true, arg[1], lmp);
|
||||
num = utils::inumeric(FLERR, false, arg[2], lmp);
|
||||
|
||||
.. seealso::
|
||||
|
||||
:cpp:func:`utils::numeric() <LAMMPS_NS::utils::numeric>`,
|
||||
:cpp:func:`utils::inumeric() <LAMMPS_NS::utils::inumeric>`,
|
||||
:cpp:func:`utils::bnumeric() <LAMMPS_NS::utils::bnumeric>`,
|
||||
:cpp:func:`utils::tnumeric() <LAMMPS_NS::utils::tnumeric>`
|
||||
|
||||
Use utils::open_potential() function to open potential files
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionchanged:: 18Sep2020
|
||||
|
||||
The :cpp:func:`utils::open_potential()
|
||||
<LAMMPS_NS::utils::open_potential>` function must be used to replace
|
||||
calls to ``force->open_potential()`` and should be used to replace
|
||||
``fopen()`` for opening potential files for reading. The custom
|
||||
function does three additional steps compared to ``fopen()``: 1) it will
|
||||
try to parse the ``UNITS:`` and ``DATE:`` metadata will stop with an
|
||||
error on a units mismatch and will print the date info, if present, in
|
||||
the log file; 2) for pair styles that support it, it will set up
|
||||
possible automatic unit conversions based on the embedded unit
|
||||
information and LAMMPS' current units setting; 3) it will not only try
|
||||
to open a potential file at the given path, but will also search in the
|
||||
folders listed in the ``LAMMPS_POTENTIALS`` environment variable. This
|
||||
allows to keep potential files in a common location instead of having to
|
||||
copy them around for simulations.
|
||||
|
||||
Old:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
fp = force->open_potential(filename);
|
||||
fp = fopen(filename, "r");
|
||||
|
||||
New:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
fp = utils::open_potential(filename, lmp);
|
||||
|
||||
Simplify customized error messages
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionchanged:: 14May2021
|
||||
|
||||
Aided by features of the bundled {fmt} library, error messages now
|
||||
can have a variable number of arguments and the string will be interpreted
|
||||
as a {fmt} style format string so that custom error messages can be
|
||||
easily customized without having to use temporary buffers and ``sprintf()``.
|
||||
Example:
|
||||
|
||||
Old:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
if (fptr == NULL) {
|
||||
char str[128];
|
||||
sprintf(str,"Cannot open AEAM potential file %s",filename);
|
||||
error->one(FLERR,str);
|
||||
}
|
||||
|
||||
New:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
if (fptr == nullptr)
|
||||
error->one(FLERR, "Cannot open AEAM potential file {}: {}", filename, utils::getsyserror());
|
||||
|
||||
Use of "override" instead of "virtual"
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionchanged:: 17Feb2022
|
||||
|
||||
Since LAMMPS requires C++11 we switched to use the "override" keyword
|
||||
instead of "virtual" to indicate polymorphism in derived classes. This
|
||||
allows the C++ compiler to better detect inconsistencies when an
|
||||
override is intended or not. Please note that "override" has to be
|
||||
added to **all** polymorph functions in derived classes and "virtual"
|
||||
*only* to the function in the base class (or the destructor). Here is
|
||||
an example from the ``FixWallReflect`` class:
|
||||
|
||||
Old:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
FixWallReflect(class LAMMPS *, int, char **);
|
||||
virtual ~FixWallReflect();
|
||||
int setmask();
|
||||
void init();
|
||||
void post_integrate();
|
||||
|
||||
New:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
FixWallReflect(class LAMMPS *, int, char **);
|
||||
~FixWallReflect() override;
|
||||
int setmask() override;
|
||||
void init() override;
|
||||
void post_integrate() override;
|
||||
|
||||
This change set will neither cause a compilation failure, nor will it
|
||||
change functionality, but if you plan to submit the updated code for
|
||||
inclusion into the LAMMPS distribution, it will be requested for achieve
|
||||
a consistent :doc:`programming style <Modify_style>`.
|
||||
|
||||
Simplified function names for forward and reverse communication
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionchanged:: 24Mar2022
|
||||
|
||||
Rather then using the function name to distinguish between the different
|
||||
forward and reverse communication functions for styles, LAMMPS now uses
|
||||
the type of the "this" pointer argument.
|
||||
|
||||
Old:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
comm->forward_comm_pair(this);
|
||||
comm->forward_comm_fix(this);
|
||||
comm->forward_comm_compute(this);
|
||||
comm->forward_comm_dump(this);
|
||||
comm->reverse_comm_pair(this);
|
||||
comm->reverse_comm_fix(this);
|
||||
comm->reverse_comm_compute(this);
|
||||
comm->reverse_comm_dump(this);
|
||||
|
||||
New:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
comm->forward_comm(this);
|
||||
comm->reverse_comm(this);
|
||||
|
||||
This change is **required** or else the code will not compile.
|
||||
|
||||
Simplified and more compact neighbor list requests
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionchanged:: 24Mar2022
|
||||
|
||||
This change set reduces the amount of code required to request a
|
||||
neighbor list. It enforces consistency and no longer requires to change
|
||||
internal data of the request. More information on neighbor list
|
||||
requests can be :doc:`found here <Developer_notes>`. Example from the
|
||||
``ComputeRDF`` class:
|
||||
|
||||
Old:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
int irequest = neighbor->request(this,instance_me);
|
||||
neighbor->requests[irequest]->pair = 0;
|
||||
neighbor->requests[irequest]->compute = 1;
|
||||
neighbor->requests[irequest]->occasional = 1;
|
||||
if (cutflag) {
|
||||
neighbor->requests[irequest]->cut = 1;
|
||||
neighbor->requests[irequest]->cutoff = mycutneigh;
|
||||
}
|
||||
|
||||
New:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
auto req = neighbor->add_request(this, NeighConst::REQ_OCCASIONAL);
|
||||
if (cutflag) req->set_cutoff(mycutneigh);
|
||||
|
||||
Public access to the ``NeighRequest`` class data members has been
|
||||
removed so this update is **required** to avoid compilation failure.
|
||||
|
||||
Split of fix STORE into fix STORE/GLOBAL and fix STORE/PERATOM
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionchanged:: 15Sep2022
|
||||
|
||||
This change splits the GLOBAL and PERATOM modes of fix STORE into two
|
||||
separate fixes STORE/GLOBAL and STORE/PERATOM. There was very little
|
||||
shared code between the two fix STORE modes and the two different code
|
||||
paths had to be prefixed with if statements. Furthermore, some flags
|
||||
were used differently in the two modes leading to confusion. Splitting
|
||||
the code into two fix styles, makes it more easily maintainable. Since
|
||||
these are internal fixes, there is no user visible change.
|
||||
|
||||
Old:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
#include "fix_store.h"
|
||||
|
||||
FixStore *fix = dynamic_cast<FixStore *>(
|
||||
modify->add_fix(fmt::format("{} {} STORE peratom 1 13",id_pole,group->names[0]));
|
||||
|
||||
FixStore *fix = dynamic_cast<FixStore *>(modify->get_fix_by_id(id_pole));
|
||||
|
||||
New:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
#include "fix_store_peratom.h"
|
||||
|
||||
FixStorePeratom *fix = dynamic_cast<FixStorePeratom *>(
|
||||
modify->add_fix(fmt::format("{} {} STORE/PERATOM 1 13",id_pole,group->names[0]));
|
||||
|
||||
FixStorePeratom *fix = dynamic_cast<FixStorePeratom *>(modify->get_fix_by_id(id_pole));
|
||||
|
||||
Old:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
#include "fix_store.h"
|
||||
|
||||
FixStore *fix = dynamic_cast<FixStore *>(
|
||||
modify->add_fix(fmt::format("{} {} STORE global 1 1",id_fix,group->names[igroup]));
|
||||
|
||||
FixStore *fix = dynamic_cast<FixStore *>(modify->get_fix_by_id(id_fix));
|
||||
|
||||
New:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
#include "fix_store_global.h"
|
||||
|
||||
FixStoreGlobal *fix = dynamic_cast<FixStoreGlobal *>(
|
||||
modify->add_fix(fmt::format("{} {} STORE/GLOBAL 1 1",id_fix,group->names[igroup]));
|
||||
|
||||
FixStoreGlobal *fix = dynamic_cast<FixStoreGlobal *>(modify->get_fix_by_id(id_fix));
|
||||
|
||||
This change is **required** or else the code will not compile.
|
||||
|
||||
Use Output::get_dump_by_id() instead of Output::find_dump()
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionchanged:: 15Sep2022
|
||||
|
||||
The accessor function to individual dump style instances has been changed
|
||||
from ``Output::find_dump()`` returning the index of the dump instance in
|
||||
the list of dumps to ``Output::get_dump_by_id()`` returning a pointer to
|
||||
the dump directly. Example:
|
||||
|
||||
Old:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
int idump = output->find_dump(arg[iarg+1]);
|
||||
if (idump < 0)
|
||||
error->all(FLERR,"Dump ID in hyper command does not exist");
|
||||
memory->grow(dumplist,ndump+1,"hyper:dumplist");
|
||||
dumplist[ndump++] = idump;
|
||||
|
||||
[...]
|
||||
|
||||
if (dumpflag)
|
||||
for (int idump = 0; idump < ndump; idump++)
|
||||
output->dump[dumplist[idump]]->write();
|
||||
|
||||
New:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
auto idump = output->get_dump_by_id(arg[iarg+1]);
|
||||
if (!idump) error->all(FLERR,"Dump ID {} in hyper command does not exist", arg[iarg+1]);
|
||||
dumplist.emplace_back(idump);
|
||||
|
||||
[...]
|
||||
|
||||
if (dumpflag) for (auto idump : dumplist) idump->write();
|
||||
|
||||
This change is **required** or else the code will not compile.
|
||||
@ -154,6 +154,9 @@ and parsing files or arguments.
|
||||
.. doxygenfunction:: trim_and_count_words
|
||||
:project: progguide
|
||||
|
||||
.. doxygenfunction:: join_words
|
||||
:project: progguide
|
||||
|
||||
.. doxygenfunction:: split_words
|
||||
:project: progguide
|
||||
|
||||
@ -172,6 +175,12 @@ and parsing files or arguments.
|
||||
.. doxygenfunction:: is_double
|
||||
:project: progguide
|
||||
|
||||
.. doxygenfunction:: is_id
|
||||
:project: progguide
|
||||
|
||||
.. doxygenfunction:: is_type
|
||||
:project: progguide
|
||||
|
||||
Potential file functions
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -202,10 +211,13 @@ Argument processing
|
||||
.. doxygenfunction:: expand_args
|
||||
:project: progguide
|
||||
|
||||
.. doxygenfunction:: expand_type
|
||||
:project: progguide
|
||||
|
||||
Convenience functions
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. doxygenfunction:: logmesg(LAMMPS *lmp, const S &format, Args&&... args)
|
||||
.. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &format, Args&&... args)
|
||||
:project: progguide
|
||||
|
||||
.. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &mesg)
|
||||
|
||||
@ -75,7 +75,7 @@ Using the GDB debugger to get a stack trace
|
||||
There are two options to use the GDB debugger for identifying the origin
|
||||
of the segmentation fault or similar crash. The GDB debugger has many
|
||||
more features and options, as can be seen for example its `online
|
||||
documentation <http://sourceware.org/gdb/current/onlinedocs/gdb/>`_.
|
||||
documentation <https://sourceware.org/gdb/current/onlinedocs/gdb/>`_.
|
||||
|
||||
Run LAMMPS from within the debugger
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -476,65 +476,6 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
*Bonds defined but no bond types*
|
||||
The data file header lists bonds but no bond types.
|
||||
|
||||
*Bond/react: Cannot use fix bond/react with non-molecular systems*
|
||||
Only systems with bonds that can be changed can be used. Atom_style
|
||||
template does not qualify.
|
||||
|
||||
*Bond/react: Invalid template atom ID in map file*
|
||||
Atom IDs in molecule templates range from 1 to the number of atoms in the template.
|
||||
|
||||
*Bond/react: Rmax cutoff is longer than pairwise cutoff*
|
||||
This is not allowed because bond creation is done using the pairwise
|
||||
neighbor list.
|
||||
|
||||
*Bond/react: Molecule template ID for fix bond/react does not exist*
|
||||
A valid molecule template must have been created with the molecule
|
||||
command.
|
||||
|
||||
*Bond/react: Reaction templates must contain the same number of atoms*
|
||||
There should be a one-to-one correspondence between atoms in the
|
||||
pre-reacted and post-reacted templates, as specified by the map file.
|
||||
|
||||
*Bond/react: Unknown section in map file*
|
||||
Please ensure reaction map files are properly formatted.
|
||||
|
||||
*Bond/react: Atom/Bond type affected by reaction too close to template edge*
|
||||
This means an atom which changes type or connectivity during the
|
||||
reaction is too close to an 'edge' atom defined in the map
|
||||
file. This could cause incorrect assignment of bonds, angle, etc.
|
||||
Generally, this means you must include more atoms in your templates,
|
||||
such that there are at least two atoms between each atom involved in
|
||||
the reaction and an edge atom.
|
||||
|
||||
*Bond/react: Fix bond/react needs ghost atoms from farther away*
|
||||
This is because a processor needs to map the entire unreacted
|
||||
molecule template onto simulation atoms it knows about. The
|
||||
comm_modify cutoff command can be used to extend the communication
|
||||
range.
|
||||
|
||||
*Bond/react: A deleted atom cannot remain bonded to an atom that is not deleted*
|
||||
Self-explanatory.
|
||||
|
||||
*Bond/react: First neighbors of chiral atoms must be of mutually different types*
|
||||
Self-explanatory.
|
||||
|
||||
*Bond/react: Chiral atoms must have exactly four first neighbors*
|
||||
Self-explanatory.
|
||||
|
||||
*Bond/react: Molecule template 'Coords' section required for chiralIDs keyword*
|
||||
The coordinates of atoms in the pre-reacted template are used to determine
|
||||
chirality.
|
||||
|
||||
*Bond/react special bond generation overflow*
|
||||
The number of special bonds per-atom created by a reaction exceeds the
|
||||
system setting. See the read_data or create_box command for how to
|
||||
specify this value.
|
||||
|
||||
*Bond/react topology/atom exceed system topology/atom*
|
||||
The number of bonds, angles etc per-atom created by a reaction exceeds
|
||||
the system setting. See the read_data or create_box command for how to
|
||||
specify this value.
|
||||
|
||||
*Both restart files must use % or neither*
|
||||
Self-explanatory.
|
||||
|
||||
@ -1291,7 +1232,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
*Cannot use chosen neighbor list style with lj/gromacs/kk*
|
||||
Self-explanatory.
|
||||
|
||||
*Cannot use chosen neighbor list style with lj/sdk/kk*
|
||||
*Cannot use chosen neighbor list style with lj/spica/kk*
|
||||
That style is not supported by Kokkos.
|
||||
|
||||
*Cannot use chosen neighbor list style with pair eam/kk*
|
||||
@ -1659,10 +1600,10 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
*Cannot use newton pair with lj/gromacs/gpu pair style*
|
||||
Self-explanatory.
|
||||
|
||||
*Cannot use newton pair with lj/sdk/coul/long/gpu pair style*
|
||||
*Cannot use newton pair with lj/spica/coul/long/gpu pair style*
|
||||
Self-explanatory.
|
||||
|
||||
*Cannot use newton pair with lj/sdk/gpu pair style*
|
||||
*Cannot use newton pair with lj/spica/gpu pair style*
|
||||
Self-explanatory.
|
||||
|
||||
*Cannot use newton pair with lj96/cut/gpu pair style*
|
||||
@ -3521,6 +3462,65 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
acquire needed info, The comm_modify cutoff command can be used to
|
||||
extend the communication range.
|
||||
|
||||
*Fix bond/react: Cannot use fix bond/react with non-molecular systems*
|
||||
Only systems with bonds that can be changed can be used. Atom_style
|
||||
template does not qualify.
|
||||
|
||||
*Fix bond/react: Invalid template atom ID in map file*
|
||||
Atom IDs in molecule templates range from 1 to the number of atoms in the template.
|
||||
|
||||
*Fix bond/react: Rmax cutoff is longer than pairwise cutoff*
|
||||
This is not allowed because bond creation is done using the pairwise
|
||||
neighbor list.
|
||||
|
||||
*Fix bond/react: Molecule template ID for fix bond/react does not exist*
|
||||
A valid molecule template must have been created with the molecule
|
||||
command.
|
||||
|
||||
*Fix bond/react: Reaction templates must contain the same number of atoms*
|
||||
There should be a one-to-one correspondence between atoms in the
|
||||
pre-reacted and post-reacted templates, as specified by the map file.
|
||||
|
||||
*Fix bond/react: Unknown section in map file*
|
||||
Please ensure reaction map files are properly formatted.
|
||||
|
||||
*Fix bond/react: Atom/Bond type affected by reaction too close to template edge*
|
||||
This means an atom which changes type or connectivity during the
|
||||
reaction is too close to an 'edge' atom defined in the map
|
||||
file. This could cause incorrect assignment of bonds, angle, etc.
|
||||
Generally, this means you must include more atoms in your templates,
|
||||
such that there are at least two atoms between each atom involved in
|
||||
the reaction and an edge atom.
|
||||
|
||||
*Fix bond/react: Fix bond/react needs ghost atoms from farther away*
|
||||
This is because a processor needs to map the entire unreacted
|
||||
molecule template onto simulation atoms it knows about. The
|
||||
comm_modify cutoff command can be used to extend the communication
|
||||
range.
|
||||
|
||||
*Fix bond/react: A deleted atom cannot remain bonded to an atom that is not deleted*
|
||||
Self-explanatory.
|
||||
|
||||
*Fix bond/react: First neighbors of chiral atoms must be of mutually different types*
|
||||
Self-explanatory.
|
||||
|
||||
*Fix bond/react: Chiral atoms must have exactly four first neighbors*
|
||||
Self-explanatory.
|
||||
|
||||
*Fix bond/react: Molecule template 'Coords' section required for chiralIDs keyword*
|
||||
The coordinates of atoms in the pre-reacted template are used to determine
|
||||
chirality.
|
||||
|
||||
*Fix bond/react special bond generation overflow*
|
||||
The number of special bonds per-atom created by a reaction exceeds the
|
||||
system setting. See the read_data or create_box command for how to
|
||||
specify this value.
|
||||
|
||||
*Fix bond/react topology/atom exceed system topology/atom*
|
||||
The number of bonds, angles etc per-atom created by a reaction exceeds
|
||||
the system setting. See the read_data or create_box command for how to
|
||||
specify this value.
|
||||
|
||||
*Fix bond/swap cannot use dihedral or improper styles*
|
||||
These styles cannot be defined when using this fix.
|
||||
|
||||
@ -5453,6 +5453,11 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
Mass command must set a type from 1-N where N is the number of atom
|
||||
types.
|
||||
|
||||
*Invalid label2type() function syntax in variable formula*
|
||||
The first argument must be a label map kind (atom, bond, angle,
|
||||
dihedral, or improper) and the second argument must be a valid type
|
||||
label that has been assigned to a numeric type.
|
||||
|
||||
*Invalid use of library file() function*
|
||||
This function is called through the library interface. This
|
||||
error should not occur. Contact the developers if it does.
|
||||
@ -5585,9 +5590,18 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
*LJ6 off not supported in pair_style buck/long/coul/long*
|
||||
Self-explanatory.
|
||||
|
||||
*Label map is incomplete: all types must be assigned a unique type label*
|
||||
For a given type-kind (atom types, bond types, etc.) to be written to
|
||||
the data file, all associated types must be assigned a type label, and
|
||||
each type label can be assigned to only one numeric type.
|
||||
|
||||
*Label wasn't found in input script*
|
||||
Self-explanatory.
|
||||
|
||||
*Labelmap command before simulation box is defined*
|
||||
The labelmap command cannot be used before a read_data,
|
||||
read_restart, or create_box command.
|
||||
|
||||
*Lattice orient vectors are not orthogonal*
|
||||
The three specified lattice orientation vectors must be mutually
|
||||
orthogonal.
|
||||
@ -5863,6 +5877,12 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
*Must not have multiple fixes change box parameter ...*
|
||||
Self-explanatory.
|
||||
|
||||
*Must read Angle Type Labels before Angles*
|
||||
An Angle Type Labels section of a data file must come before the Angles section.
|
||||
|
||||
*Must read Atom Type Labels before Atoms*
|
||||
An Atom Type Labels section of a data file must come before the Atoms section.
|
||||
|
||||
*Must read Atoms before Angles*
|
||||
The Atoms section of a data file must come before an Angles section.
|
||||
|
||||
@ -5893,6 +5913,15 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
The Atoms section of a data file must come before a Velocities
|
||||
section.
|
||||
|
||||
*Must read Bond Type Labels before Bonds*
|
||||
A Bond Type Labels section of a data file must come before the Bonds section.
|
||||
|
||||
*Must read Dihedral Type Labels before Dihedrals*
|
||||
An Dihedral Type Labels section of a data file must come before the Dihedrals section.
|
||||
|
||||
*Must read Improper Type Labels before Impropers*
|
||||
An Improper Type Labels section of a data file must come before the Impropers section.
|
||||
|
||||
*Must re-specify non-restarted pair style (xxx) after read_restart*
|
||||
For pair styles, that do not store their settings in a restart file,
|
||||
it must be defined with a new 'pair_style' command after read_restart.
|
||||
@ -6782,7 +6811,7 @@ keyword to allow for additional bonds to be formed
|
||||
This is because the computation of constraint forces within a water
|
||||
molecule adds forces to atoms owned by other processors.
|
||||
|
||||
*Pair style lj/sdk/coul/long/gpu requires atom attribute q*
|
||||
*Pair style lj/spica/coul/long/gpu requires atom attribute q*
|
||||
The atom style defined does not have this attribute.
|
||||
|
||||
*Pair style nb3b/harmonic requires atom IDs*
|
||||
@ -7849,6 +7878,10 @@ keyword to allow for additional bonds to be formed
|
||||
Number of local atoms times number of columns must fit in a 32-bit
|
||||
integer for dump.
|
||||
|
||||
*Topology type exceeds system topology type*
|
||||
The number of bond, angle, etc types exceeds the system setting. See
|
||||
the create_box or read_data command for how to specify these values.
|
||||
|
||||
*Tree structure in joint connections*
|
||||
Fix poems cannot (yet) work with coupled bodies whose joints connect
|
||||
the bodies in a tree structure.
|
||||
@ -7873,6 +7906,13 @@ keyword to allow for additional bonds to be formed
|
||||
*Two groups cannot be the same in fix spring couple*
|
||||
Self-explanatory.
|
||||
|
||||
*The %s type label %s is already in use for type %s*
|
||||
For a given type-kind (atom types, bond types, etc.), a given type
|
||||
label can be assigned to only one numeric type.
|
||||
|
||||
*Type label string %s for %s type %s is invalid*
|
||||
See the labelmap command documentation for valid type labels.
|
||||
|
||||
*Unable to initialize accelerator for use*
|
||||
There was a problem initializing an accelerator for the gpu package
|
||||
|
||||
|
||||
@ -68,14 +68,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
|
||||
length, multiplying by the number of bonds in the interaction (e.g. 3
|
||||
for a dihedral) and adding a small amount of stretch.
|
||||
|
||||
*Bond/react: Atom affected by reaction too close to template edge*
|
||||
This means an atom which changes type or connectivity during the
|
||||
reaction is too close to an 'edge' atom defined in the superimpose
|
||||
file. This could cause incorrect assignment of bonds, angle, etc.
|
||||
Generally, this means you must include more atoms in your templates,
|
||||
such that there are at least two atoms between each atom involved in
|
||||
the reaction and an edge atom.
|
||||
|
||||
*Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero*
|
||||
Self-explanatory.
|
||||
|
||||
@ -206,12 +198,20 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
|
||||
*Fix SRD walls overlap but fix srd overlap not set*
|
||||
You likely want to set this in your input script.
|
||||
|
||||
* Fix bond/create is used multiple times or with fix bond/break - may not work as expected*
|
||||
*Fix bond/create is used multiple times or with fix bond/break - may not work as expected*
|
||||
When using fix bond/create multiple times or in combination with
|
||||
fix bond/break, the individual fix instances do not share information
|
||||
about changes they made at the same time step and thus it may result
|
||||
in unexpected behavior.
|
||||
|
||||
*Fix bond/react: Atom affected by reaction too close to template edge*
|
||||
This means an atom which changes type or connectivity during the
|
||||
reaction is too close to an 'edge' atom defined in the superimpose
|
||||
file. This could cause incorrect assignment of bonds, angle, etc.
|
||||
Generally, this means you must include more atoms in your templates,
|
||||
such that there are at least two atoms between each atom involved in
|
||||
the reaction and an edge atom.
|
||||
|
||||
*Fix bond/swap will ignore defined angles*
|
||||
See the page for fix bond/swap for more info on this
|
||||
restriction.
|
||||
@ -810,4 +810,3 @@ This will most likely cause errors in kinetic fluctuations.
|
||||
|
||||
*Using pair tail corrections with pair_modify compute no*
|
||||
The tail corrections will thus not be computed.
|
||||
|
||||
|
||||
1451
doc/src/Fortran.rst
1451
doc/src/Fortran.rst
File diff suppressed because it is too large
Load Diff
@ -34,6 +34,7 @@ Settings howto
|
||||
:maxdepth: 1
|
||||
|
||||
Howto_2d
|
||||
Howto_type_labels
|
||||
Howto_triclinic
|
||||
Howto_thermostat
|
||||
Howto_barostat
|
||||
@ -65,6 +66,7 @@ Force fields howto
|
||||
:maxdepth: 1
|
||||
|
||||
Howto_bioFF
|
||||
Howto_amoeba
|
||||
Howto_tip3p
|
||||
Howto_tip4p
|
||||
Howto_spc
|
||||
@ -83,6 +85,7 @@ Packages howto
|
||||
Howto_coreshell
|
||||
Howto_drude
|
||||
Howto_drude2
|
||||
Howto_peri
|
||||
Howto_manifold
|
||||
Howto_spins
|
||||
|
||||
|
||||
324
doc/src/Howto_amoeba.rst
Normal file
324
doc/src/Howto_amoeba.rst
Normal file
@ -0,0 +1,324 @@
|
||||
AMOEBA and HIPPO force fields
|
||||
=============================
|
||||
|
||||
The AMOEBA and HIPPO polarizable force fields were developed by Jay
|
||||
Ponder's group at the U Washington at St Louis. The LAMMPS
|
||||
implementation is based on Fortran 90 code provided by the Ponder
|
||||
group in their `Tinker MD software <https://dasher.wustl.edu/tinker/>`_.
|
||||
|
||||
The current implementation (July 2022) of AMOEBA in LAMMPS matches the
|
||||
version discussed in :ref:`(Ponder) <amoeba-Ponder>`, :ref:`(Ren)
|
||||
<amoeba-Ren>`, and :ref:`(Shi) <amoeba-Shi>`. Likewise the current
|
||||
implementation of HIPPO in LAMMPS matches the version discussed in
|
||||
:ref:`(Rackers) <amoeba-Rackers>`.
|
||||
|
||||
These force fields can be used when polarization effects are desired
|
||||
in simulations of water, organic molecules, and biomolecules including
|
||||
proteins, provided that parameterizations (Tinker PRM force field
|
||||
files) are available for the systems you are interested in. Files in
|
||||
the LAMMPS potentials directory with a "amoeba" or "hippo" suffix can
|
||||
be used. The Tinker distribution and website have additional force
|
||||
field files as well:
|
||||
`https://github.com/TinkerTools/tinker/tree/release/params
|
||||
<https://github.com/TinkerTools/tinker/tree/release/params>`_.
|
||||
|
||||
Note that currently, HIPPO can only be used for water systems, but
|
||||
HIPPO files for a variety of small organic and biomolecules are in
|
||||
preparation by the Ponder group. Those force field files will be
|
||||
included in the LAMMPS distribution when available.
|
||||
|
||||
To use the AMOEBA or HIPPO force fields, a simulation must be 3d, and
|
||||
fully periodic or fully non-periodic, and use an orthogonal (not
|
||||
triclinic) simulation box.
|
||||
|
||||
----------
|
||||
|
||||
The AMOEBA and HIPPO force fields contain the following terms in their
|
||||
energy (U) computation. Further details for AMOEBA equations are in
|
||||
:ref:`(Ponder) <amoeba-Ponder>`, further details for the HIPPO
|
||||
equations are in :ref:`(Rackers) <amoeba-Rackers>`.
|
||||
|
||||
.. math::
|
||||
|
||||
U & = U_{intermolecular} + U_{intramolecular} \\
|
||||
U_{intermolecular} & = U_{hal} + U_{repulsion} + U_{dispersion} + U_{multipole} + U_{polar} + U_{qxfer} \\
|
||||
U_{intramolecular} & = U_{bond} + U_{angle} + U_{torsion} + U_{oop} + U_{b\theta} + U_{UB} + U_{pitorsion} + U_{bitorsion}
|
||||
|
||||
For intermolecular terms, the AMOEBA force field includes only the
|
||||
:math:`U_{hal}`, :math:`U_{multipole}`, :math:`U_{polar}` terms. The
|
||||
HIPPO force field includes all but the :math:`U_{hal}` term. In
|
||||
LAMMPS, these are all computed by the :doc:`pair_style amoeba or hippo
|
||||
<pair_style>` command. Note that the :math:`U_{multipole}` and
|
||||
:math:`U_{polar}` terms in this formula are not the same for the
|
||||
AMOEBA and HIPPO force fields.
|
||||
|
||||
For intramolecular terms, the :math:`U_{bond}`, :math:`U_{angle}`,
|
||||
:math:`U_{torsion}`, :math:`U_{oop}` terms are computed by the
|
||||
:doc:`bond_style class2 <bond_class2>` :doc:`angle_style amoeba
|
||||
<angle_amoeba>`, :doc:`dihedral_style fourier <dihedral_fourier>`, and
|
||||
:doc:`improper_style amoeba <improper_amoeba>` commands respectively.
|
||||
The :doc:`angle_style amoeba <angle_amoeba>` command includes the
|
||||
:math:`U_{b\theta}` bond-angle cross term, and the :math:`U_{UB}` term
|
||||
for a Urey-Bradley bond contribution between the I,K atoms in the IJK
|
||||
angle.
|
||||
|
||||
The :math:`U_{pitorsion}` term is computed by the :doc:`fix
|
||||
amoeba/pitorsion <fix_amoeba_pitorsion>` command. It computes 6-body
|
||||
interaction between a pair of bonded atoms which each have 2
|
||||
additional bond partners.
|
||||
|
||||
The :math:`U_{bitorsion}` term is computed by the :doc:`fix
|
||||
amoeba/bitorsion <fix_amoeba_bitorsion>` command. It computes 5-body
|
||||
interaction between two 4-body torsions (dihedrals) which overlap,
|
||||
having 3 atoms in common.
|
||||
|
||||
These command doc pages have additional details on the terms they
|
||||
compute:
|
||||
|
||||
* :doc:`pair_style amoeba or hippo <pair_amoeba>`
|
||||
* :doc:`bond_style class2 <bond_class2>`
|
||||
* :doc:`angle_style amoeba <angle_amoeba>`
|
||||
* :doc:`dihedral_style fourier <dihedral_fourier>`
|
||||
* :doc:`improper_style amoeba <improper_amoeba>`
|
||||
* :doc:`fix amoeba/pitorsion <fix_amoeba_pitorsion>`
|
||||
* :doc:`fix amoeba/bitorsion <fix_amoeba_bitorsion>`
|
||||
|
||||
----------
|
||||
|
||||
To use the AMOEBA or HIPPO force fields in LAMMPS, use commands like
|
||||
the following appropriately in your input script. The only change
|
||||
needed for AMOEBA vs HIPPO simulation is for the :doc:`pair_style
|
||||
<pair_style>` and :doc:`pair_coeff <pair_coeff>` commands, as shown
|
||||
below. See examples/amoeba for example input scripts for both AMOEBA
|
||||
and HIPPO.
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
units real # required
|
||||
atom_style amoeba
|
||||
bond_style class2 # CLASS2 package
|
||||
angle_style amoeba
|
||||
dihedral_style fourier # EXTRA-MOLECULE package
|
||||
improper_style amoeba
|
||||
# required per-atom data
|
||||
fix amtype all property/atom i_amtype ghost yes
|
||||
fix extra all property/atom &
|
||||
i_amgroup i_ired i_xaxis i_yaxis i_zaxis d_pval ghost yes
|
||||
fix polaxe all property/atom i_polaxe
|
||||
|
||||
fix pit all amoeba/pitorsion # PiTorsion terms in FF
|
||||
fix_modify pit energy yes
|
||||
# Bitorsion terms in FF
|
||||
fix bit all amoeba/bitorsion bitorsion.ubiquitin.data
|
||||
fix_modify bit energy yes
|
||||
|
||||
read_data data.ubiquitin fix amtype NULL "Tinker Types" &
|
||||
fix pit "pitorsion types" "PiTorsion Coeffs" &
|
||||
fix pit pitorsions PiTorsions &
|
||||
fix bit bitorsions BiTorsions
|
||||
|
||||
pair_style amoeba # AMOEBA FF
|
||||
pair_coeff * * amoeba_ubiquitin.prm amoeba_ubiquitin.key
|
||||
|
||||
pair_style hippo # HIPPO FF
|
||||
pair_coeff * * hippo_water.prm hippo_water.key
|
||||
|
||||
special_bonds lj/coul 0.5 0.5 0.5 one/five yes # 1-5 neighbors
|
||||
|
||||
The data file read by the :doc:`read_data <read_data>` command should
|
||||
be created by the tools/tinker/tinker2lmp.py conversion program
|
||||
described below. It will create a section in the data file with the
|
||||
header "Tinker Types". A :doc:`fix property/atom <fix_property_atom>`
|
||||
command for the data must be specified before the read_data command.
|
||||
In the example above the fix ID is *amtype*.
|
||||
|
||||
Similarly, if the system you are simulating defines AMOEBA/HIPPO
|
||||
pitorsion or bitorsion interactions, there will be entries in the data
|
||||
file for those interactions. They require a :doc:`fix
|
||||
amoeba/pitortion <fix_amoeba_pitorsion>` and :doc:`fix
|
||||
amoeba/bitorsion <fix_amoeba_bitorsion>` command be defined. In the
|
||||
example above, the IDs for these two fixes are *pit* and *bit*.
|
||||
|
||||
Of course, if the system being modeled does not have one or more of
|
||||
the following -- bond, angle, dihedral, improper, pitorsion,
|
||||
bitorsion interactions -- then the corresponding style and fix
|
||||
commands above do not need to be used. See the example scripts in
|
||||
examples/amoeba for water systems as examples; they are simpler than
|
||||
what is listed above.
|
||||
|
||||
The two :doc:`fix property/atom <fix_property_atom>` commands with IDs
|
||||
(in the example above) *extra* and *polaxe* are also needed to define
|
||||
internal per-atom quantities used by the AMOEBA and HIPPO force
|
||||
fields.
|
||||
|
||||
The :doc:`pair_coeff <pair_coeff>` command used for either the AMOEBA
|
||||
or HIPPO force field takes two arguments for Tinker force field files,
|
||||
namely a PRM and KEY file. The keyfile can be specified as NULL and
|
||||
default values for a various settings will be used. Note that these 2
|
||||
files are meant to allow use of native Tinker files as-is. However
|
||||
LAMMPS does not support all the options which can be included
|
||||
in a Tinker PRM or KEY file. See specifics below.
|
||||
|
||||
A :doc:`special_bonds <special_bonds>` command with the *one/five*
|
||||
option is required, since the AMOEBA/HIPPO force fields define
|
||||
weighting factors for not only 1-2, 1-3, 1-4 interactions, but also
|
||||
1-5 interactions. This command will trigger a per-atom list of 1-5
|
||||
neighbors to be generated. The AMOEBA and HIPPO force fields define
|
||||
their own custom weighting factors for all the 1-2, 1-3, 1-4, 1-5
|
||||
terms which in the Tinker PRM and KEY files; they can be different for
|
||||
different terms in the force field.
|
||||
|
||||
In addition to the list above, these command doc pages have additional
|
||||
details:
|
||||
|
||||
* :doc:`atom_style amoeba <atom_style>`
|
||||
* :doc:`fix property/atom <fix_property_atom>`
|
||||
* :doc:`special_bonds <special_bonds>`
|
||||
|
||||
----------
|
||||
|
||||
Tinker PRM and KEY files
|
||||
|
||||
A Tinker PRM file is composed of sections, each of which has multiple
|
||||
lines. This is the list of PRM sections LAMMPS knows how to parse and
|
||||
use. Any other sections are skipped:
|
||||
|
||||
* Angle Bending Parameters
|
||||
* Atom Type Definitions
|
||||
* Atomic Multipole Parameters
|
||||
* Bond Stretching Parameters
|
||||
* Charge Penetration Parameters
|
||||
* Charge Transfer Parameters
|
||||
* Dipole Polarizability Parameters
|
||||
* Dispersion Parameters
|
||||
* Force Field Definition
|
||||
* Literature References
|
||||
* Out-of-Plane Bend Parameters
|
||||
* Pauli Repulsion Parameters
|
||||
* Pi-Torsion Parameters
|
||||
* Stretch-Bend Parameters
|
||||
* Torsion-Torsion Parameters
|
||||
* Torsional Parameters
|
||||
* Urey-Bradley Parameters
|
||||
* Van der Waals Pair Parameters
|
||||
* Van der Waals Parameters
|
||||
|
||||
A Tinker KEY file is composed of lines, each of which has a keyword
|
||||
followed by zero or more parameters. This is the list of keywords
|
||||
LAMMPS knows how to parse and use in the same manner Tinker does. Any
|
||||
other keywords are skipped. The value in parenthesis is the default
|
||||
value for the keyword if it is not specified, or if the keyfile in the
|
||||
:doc:`pair_coeff <pair_coeff>` command is specified as NULL:
|
||||
|
||||
* a-axis (0.0)
|
||||
* b-axis (0.0)
|
||||
* c-axis (0.0)
|
||||
* ctrn-cutoff (6.0)
|
||||
* ctrn-taper (0.9 * ctrn-cutoff)
|
||||
* cutoff
|
||||
* delta-halgren (0.07)
|
||||
* dewald (no long-range dispersion unless specified)
|
||||
* dewald-alpha (0.4)
|
||||
* dewald-cutoff (7.0)
|
||||
* dispersion-cutoff (9.0)
|
||||
* dispersion-taper (9.0 * dispersion-cutoff)
|
||||
* dpme-grid
|
||||
* dpme-order (4)
|
||||
* ewald (no long-range electrostatics unless specified)
|
||||
* ewald-alpha (0.4)
|
||||
* ewald-cutoff (7.0)
|
||||
* gamma-halgren (0.12)
|
||||
* mpole-cutoff (9.0)
|
||||
* mpole-taper (0.65 * mpole-cutoff)
|
||||
* pcg-guess (enabled by default)
|
||||
* pcg-noguess (disable pcg-guess if specified)
|
||||
* pcg-noprecond (disable pcg-precond if specified)
|
||||
* pcg-peek (1.0)
|
||||
* pcg-precond (enabled by default)
|
||||
* pewald-alpha (0.4)
|
||||
* pme-grid
|
||||
* pme-order (5)
|
||||
* polar-eps (1.0e-6)
|
||||
* polar-iter (100)
|
||||
* polar-predict (no prediction operation unless specified)
|
||||
* ppme-order (5)
|
||||
* repulsion-cutoff (6.0)
|
||||
* repulsion-taper (0.9 * repulsion-cutoff)
|
||||
* taper
|
||||
* usolve-cutoff (4.5)
|
||||
* usolve-diag (2.0)
|
||||
* vdw-cutoff (9.0)
|
||||
* vdw-taper (0.9 * vdw-cutoff)
|
||||
|
||||
----------
|
||||
|
||||
Tinker2lmp.py tool
|
||||
|
||||
This conversion tool is found in the tools/tinker directory.
|
||||
As shown in examples/amoeba/README, these commands produce
|
||||
the data files found in examples/amoeba, and also illustrate
|
||||
all the options available to use with the tinker2lmp.py script:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
% python tinker2lmp.py -xyz water_dimer.xyz -amoeba amoeba_water.prm -data data.water_dimer.amoeba # AMOEBA non-periodic system
|
||||
% python tinker2lmp.py -xyz water_dimer.xyz -hippo hippo_water.prm -data data.water_dimer.hippo # HIPPO non-periodic system
|
||||
% python tinker2lmp.py -xyz water_box.xyz -amoeba amoeba_water.prm -data data.water_box.amoeba -pbc 18.643 18.643 18.643 # AMOEBA periodic system
|
||||
% python tinker2lmp.py -xyz water_box.xyz -hippo hippo_water.prm -data data.water_box.hippo -pbc 18.643 18.643 18.643 # HIPPO periodic system
|
||||
% python tinker2lmp.py -xyz ubiquitin.xyz -amoeba amoeba_ubiquitin.prm -data data.ubiquitin.new -pbc 54.99 41.91 41.91 -bitorsion bitorsion.ubiquitin.data.new # system with bitorsions
|
||||
|
||||
Switches and their arguments may be specified in any order.
|
||||
|
||||
The -xyz switch is required and specifies an input XYZ file as an
|
||||
argument. The format of this file is an extended XYZ format defined
|
||||
and used by Tinker for its input. Example \*.xyz files are in the
|
||||
examples/amoeba directory. The file lists the atoms in the system.
|
||||
Each atom has the following information: Tinker species name (ignored
|
||||
by LAMMPS), xyz coordinates, Tinker numeric type, and a list of atom
|
||||
IDs the atom is bonded to.
|
||||
|
||||
Here is more information about the extended XYZ format defined and
|
||||
used by Tinker, and links to programs that convert standard PDB files
|
||||
to the extended XYZ format:
|
||||
|
||||
* `https://openbabel.org/docs/current/FileFormats/Tinker_XYZ_format.html <https://openbabel.org/docs/current/FileFormats/Tinker_XYZ_format.html>`_
|
||||
* `https://github.com/emleddin/pdbxyz-xyzpdb <https://github.com/emleddin/pdbxyz-xyzpdb>`_
|
||||
* `https://github.com/TinkerTools/tinker/blob/release/source/pdbxyz.f <https://github.com/TinkerTools/tinker/blob/release/source/pdbxyz.f>`_
|
||||
|
||||
The -amoeba or -hippo switch is required. It specifies an input
|
||||
AMOEBA or HIPPO PRM force field file as an argument. This should be
|
||||
the same file used by the :doc:`pair_style <pair_style>` command in
|
||||
the input script.
|
||||
|
||||
The -data switch is required. It specifies an output file name for
|
||||
the LAMMPS data file that will be produced.
|
||||
|
||||
For periodic systems, the -pbc switch is required. It specifies the
|
||||
periodic box size for each dimension (x,y,z). For a Tinker simulation
|
||||
these are specified in the KEY file.
|
||||
|
||||
The -bitorsion switch is only needed if the system contains Tinker
|
||||
bitorsion interactions. The data for each type of bitorsion
|
||||
interaction will be written to the specified file, and read by the
|
||||
:doc:`fix amoeba/bitorsion <fix_amoeba_bitorsion>` command. The data
|
||||
includes 2d arrays of values to which splines are fit, and thus is not
|
||||
compatible with the LAMMPS data file format.
|
||||
|
||||
----------
|
||||
|
||||
.. _howto-Ponder:
|
||||
|
||||
**(Ponder)** Ponder, Wu, Ren, Pande, Chodera, Schnieders, Haque, Mobley, Lambrecht, DiStasio Jr, M. Head-Gordon, Clark, Johnson, T. Head-Gordon, J Phys Chem B, 114, 2549-2564 (2010).
|
||||
|
||||
.. _howto-Rackers:
|
||||
|
||||
**(Rackers)** Rackers, Silva, Wang, Ponder, J Chem Theory Comput, 17, 7056-7084 (2021).
|
||||
|
||||
.. _howto-Ren:
|
||||
|
||||
**(Ren)** Ren and Ponder, J Phys Chem B, 107, 5933 (2003).
|
||||
|
||||
.. _howto-Shi:
|
||||
|
||||
**(Shi)** Shi, Xia, Zhang, Best, Wu, Ponder, Ren, J Chem Theory Comp, 9, 4046, 2013.
|
||||
|
||||
@ -3,24 +3,20 @@ CHARMM, AMBER, COMPASS, and DREIDING force fields
|
||||
|
||||
A force field has 2 parts: the formulas that define it and the
|
||||
coefficients used for a particular system. Here we only discuss
|
||||
formulas implemented in LAMMPS that correspond to formulas commonly
|
||||
used in the CHARMM, AMBER, COMPASS, and DREIDING force fields. Setting
|
||||
formulas implemented in LAMMPS that correspond to formulas commonly used
|
||||
in the CHARMM, AMBER, COMPASS, and DREIDING force fields. Setting
|
||||
coefficients is done either from special sections in an input data file
|
||||
via the :doc:`read_data <read_data>` command or in the input script with
|
||||
commands like :doc:`pair_coeff <pair_coeff>` or
|
||||
:doc:`bond_coeff <bond_coeff>` and so on. See the :doc:`Tools <Tools>` doc
|
||||
page for additional tools that can use CHARMM, AMBER, or Materials
|
||||
Studio generated files to assign force field coefficients and convert
|
||||
their output into LAMMPS input.
|
||||
commands like :doc:`pair_coeff <pair_coeff>` or :doc:`bond_coeff
|
||||
<bond_coeff>` and so on. See the :doc:`Tools <Tools>` doc page for
|
||||
additional tools that can use CHARMM, AMBER, or Materials Studio
|
||||
generated files to assign force field coefficients and convert their
|
||||
output into LAMMPS input.
|
||||
|
||||
See :ref:`(MacKerell) <howto-MacKerell>` for a description of the CHARMM force
|
||||
field. See :ref:`(Cornell) <howto-Cornell>` for a description of the AMBER
|
||||
force field. See :ref:`(Sun) <howto-Sun>` for a description of the COMPASS
|
||||
force field.
|
||||
|
||||
.. _charmm: http://www.scripps.edu/brooks
|
||||
|
||||
.. _amber: http://amber.scripps.edu
|
||||
See :ref:`(MacKerell) <howto-MacKerell>` for a description of the CHARMM
|
||||
force field. See :ref:`(Cornell) <howto-Cornell>` for a description of
|
||||
the AMBER force field. See :ref:`(Sun) <howto-Sun>` for a description
|
||||
of the COMPASS force field.
|
||||
|
||||
The interaction styles listed below compute force field formulas that
|
||||
are consistent with common options in CHARMM or AMBER. See each
|
||||
@ -41,9 +37,10 @@ command's documentation for the formula it computes.
|
||||
|
||||
.. note::
|
||||
|
||||
For CHARMM, newer *charmmfsw* or *charmmfsh* styles were released
|
||||
in March 2017. We recommend they be used instead of the older *charmm*
|
||||
styles. See discussion of the differences on the :doc:`pair charmm <pair_charmm>` and :doc:`dihedral charmm <dihedral_charmm>` doc
|
||||
For CHARMM, newer *charmmfsw* or *charmmfsh* styles were released in
|
||||
March 2017. We recommend they be used instead of the older *charmm*
|
||||
styles. See discussion of the differences on the :doc:`pair charmm
|
||||
<pair_charmm>` and :doc:`dihedral charmm <dihedral_charmm>` doc
|
||||
pages.
|
||||
|
||||
COMPASS is a general force field for atomistic simulation of common
|
||||
|
||||
@ -33,46 +33,6 @@ reference state of a bond. Bonds that are created midway into a run,
|
||||
such as those created by pouring grains using :doc:`fix pour
|
||||
<fix_pour>`, are initialized on that timestep.
|
||||
|
||||
As bonds can be broken between neighbor list builds, the
|
||||
:doc:`special_bonds <special_bonds>` command works differently for BPM
|
||||
bond styles. There are two possible settings which determine how pair
|
||||
interactions work between bonded particles. First, one can turn off
|
||||
all pair interactions between bonded particles. Unlike :doc:`bond
|
||||
quartic <bond_quartic>`, this is not done by subtracting pair forces
|
||||
during the bond computation but rather by dynamically updating the
|
||||
special bond list. This is the default behavior of BPM bond styles and
|
||||
is done by updating the 1-2 special bond list as bonds break. To do
|
||||
this, LAMMPS requires :doc:`newton <newton>` bond off such that all
|
||||
processors containing an atom know when a bond breaks. Additionally,
|
||||
one must do either (A) or (B).
|
||||
|
||||
A) Use the following special bond settings
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
special_bonds lj 0 1 1 coul 1 1 1
|
||||
|
||||
These settings accomplish two goals. First, they turn off 1-3 and 1-4
|
||||
special bond lists, which are not currently supported for BPMs. As
|
||||
BPMs often have dense bond networks, generating 1-3 and 1-4 special
|
||||
bond lists is expensive. By setting the lj weight for 1-2 bonds to
|
||||
zero, this turns off pairwise interactions. Even though there are no
|
||||
charges in BPM models, setting a nonzero coul weight for 1-2 bonds
|
||||
ensures all bonded neighbors are still included in the neighbor list
|
||||
in case bonds break between neighbor list builds.
|
||||
|
||||
B) Alternatively, one can simply overlay pair interactions such that all
|
||||
bonded particles also feel pair interactions. This can be
|
||||
accomplished by using the *overlay/pair* keyword present in all bpm
|
||||
bond styles and by using the following special bond settings
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
special_bonds lj/coul 1 1 1
|
||||
|
||||
See the :doc:`Howto <Howto_broken_bonds>` page on broken bonds for
|
||||
more information.
|
||||
|
||||
----------
|
||||
|
||||
Currently there are two types of bonds included in the BPM
|
||||
@ -91,12 +51,6 @@ This also requires a unique integrator :doc:`fix nve/bpm/sphere
|
||||
<fix_nve_bpm_sphere>` which numerically integrates orientation similar
|
||||
to :doc:`fix nve/asphere <fix_nve_asphere>`.
|
||||
|
||||
To monitor the fracture of bonds in the system, all BPM bond styles
|
||||
have the ability to record instances of bond breakage to output using
|
||||
the :doc:`dump local <dump>` command. Additionally, one can use
|
||||
:doc:`compute nbond/atom <compute_nbond_atom>` to tally the current
|
||||
number of bonds per atom.
|
||||
|
||||
In addition to bond styles, a new pair style :doc:`pair bpm/spring
|
||||
<pair_bpm_spring>` was added to accompany the bpm/spring bond
|
||||
style. This pair style is simply a hookean repulsion with similar
|
||||
@ -104,6 +58,73 @@ velocity damping as its sister bond style.
|
||||
|
||||
----------
|
||||
|
||||
Bond data can be output using a combination of standard LAMMPS commands.
|
||||
A list of IDs for bonded atoms can be generated using the
|
||||
:doc:`compute property/local <compute_property_local>` command.
|
||||
Various properties of bonds can be computed using the
|
||||
:doc:`compute bond/local <compute_bond_local>` command. This
|
||||
command allows one to access data saved to the bond's history
|
||||
such as the reference length of the bond. More information on
|
||||
bond history data can be found on the documentation pages for the specific
|
||||
BPM bond styles. Finally, this data can be output using a :doc:`dump local <dump>`
|
||||
command. As one may output many columns from the same compute, the
|
||||
:doc:`dump modify <dump_modify>` *colname* option may be used to provide
|
||||
more helpful column names. An example of this procedure is found in
|
||||
/examples/bpm/pour/. External software, such as OVITO, can read these dump
|
||||
files to render bond data.
|
||||
|
||||
----------
|
||||
|
||||
As bonds can be broken between neighbor list builds, the
|
||||
:doc:`special_bonds <special_bonds>` command works differently for BPM
|
||||
bond styles. There are two possible settings which determine how pair
|
||||
interactions work between bonded particles. First, one can overlay
|
||||
pair forces with bond forces such that all bonded particles also
|
||||
feel pair interactions. This can be accomplished by using the *overlay/pair*
|
||||
keyword present in all bpm bond styles and by using the following special
|
||||
bond settings
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
special_bonds lj/coul 1 1 1
|
||||
|
||||
Alternatively, one can turn off all pair interactions between bonded
|
||||
particles. Unlike :doc:`bond quartic <bond_quartic>`, this is not done
|
||||
by subtracting pair forces during the bond computation but rather by
|
||||
dynamically updating the special bond list. This is the default behavior
|
||||
of BPM bond styles and is done by updating the 1-2 special bond list as
|
||||
bonds break. To do this, LAMMPS requires :doc:`newton <newton>` bond off
|
||||
such that all processors containing an atom know when a bond breaks.
|
||||
Additionally, one must use the following special bond settings
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
special_bonds lj 0 1 1 coul 1 1 1
|
||||
|
||||
These settings accomplish two goals. First, they turn off 1-3 and 1-4
|
||||
special bond lists, which are not currently supported for BPMs. As
|
||||
BPMs often have dense bond networks, generating 1-3 and 1-4 special
|
||||
bond lists is expensive. By setting the lj weight for 1-2 bonds to
|
||||
zero, this turns off pairwise interactions. Even though there are no
|
||||
charges in BPM models, setting a nonzero coul weight for 1-2 bonds
|
||||
ensures all bonded neighbors are still included in the neighbor list
|
||||
in case bonds break between neighbor list builds.
|
||||
|
||||
To monitor the fracture of bonds in the system, all BPM bond styles
|
||||
have the ability to record instances of bond breakage to output using
|
||||
the :doc:`dump local <dump>` command. Since one may frequently output
|
||||
a list of broken bonds and the time they broke, the
|
||||
:doc:`dump modify <dump_modify>` option *header no* may be useful to
|
||||
avoid repeatedly printing the header of the dump file. An example of
|
||||
this procedure is found in /examples/bpm/impact/. Additionally,
|
||||
one can use :doc:`compute nbond/atom <compute_nbond_atom>` to tally the
|
||||
current number of bonds per atom.
|
||||
|
||||
See the :doc:`Howto <Howto_broken_bonds>` page on broken bonds for
|
||||
more information.
|
||||
|
||||
----------
|
||||
|
||||
While LAMMPS has many utilities to create and delete bonds, *only*
|
||||
the following are currently compatible with BPM bond styles:
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ changes or additions you have made to LAMMPS into the official LAMMPS
|
||||
distribution. It uses the process of updating this very tutorial as an
|
||||
example to describe the individual steps and options. You need to be
|
||||
familiar with git and you may want to have a look at the `git book
|
||||
<http://git-scm.com/book/>`_ to familiarize yourself with some of the
|
||||
<https://git-scm.com/book/>`_ to familiarize yourself with some of the
|
||||
more advanced git features used below.
|
||||
|
||||
As of fall 2016, submitting contributions to LAMMPS via pull requests
|
||||
|
||||
@ -47,4 +47,4 @@ to the relevant fixes.
|
||||
.. _Paquay1:
|
||||
|
||||
**(Paquay)** Paquay and Kusters, Biophys. J., 110, 6, (2016).
|
||||
preprint available at `arXiv:1411.3019 <http://arxiv.org/abs/1411.3019/>`_.
|
||||
preprint available at `arXiv:1411.3019 <https://arxiv.org/abs/1411.3019/>`_.
|
||||
|
||||
1078
doc/src/Howto_peri.rst
Normal file
1078
doc/src/Howto_peri.rst
Normal file
File diff suppressed because it is too large
Load Diff
@ -38,7 +38,7 @@ the partial charge assignments change:
|
||||
See the :ref:`(Berendsen) <howto-Berendsen>` reference for more details on both
|
||||
the SPC and SPC/E models.
|
||||
|
||||
Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
|
||||
Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
|
||||
|
||||
----------
|
||||
|
||||
|
||||
@ -30,9 +30,11 @@ can be coupled to another Langevin thermostat applied to the atoms
|
||||
using :doc:`fix langevin <fix_langevin>` in order to simulate
|
||||
thermostatted spin-lattice systems.
|
||||
|
||||
The magnetic Gilbert damping can also be applied using :doc:`fix langevin/spin <fix_langevin_spin>`. It allows to either dissipate
|
||||
the thermal energy of the Langevin thermostat, or to perform a
|
||||
relaxation of the magnetic configuration toward an equilibrium state.
|
||||
The magnetic damping can also be applied
|
||||
using :doc:`fix langevin/spin <fix_langevin_spin>`.
|
||||
It allows to either dissipate the thermal energy of the Langevin
|
||||
thermostat, or to perform a relaxation of the magnetic configuration
|
||||
toward an equilibrium state.
|
||||
|
||||
The command :doc:`fix setforce/spin <fix_setforce>` allows to set the
|
||||
components of the magnetic precession vectors (while erasing and
|
||||
@ -52,9 +54,11 @@ All the computed magnetic properties can be output by two main
|
||||
commands. The first one is :doc:`compute spin <compute_spin>`, that
|
||||
enables to evaluate magnetic averaged quantities, such as the total
|
||||
magnetization of the system along x, y, or z, the spin temperature, or
|
||||
the magnetic energy. The second command is :doc:`compute property/atom <compute_property_atom>`. It enables to output all the
|
||||
per atom magnetic quantities. Typically, the orientation of a given
|
||||
magnetic spin, or the magnetic force acting on this spin.
|
||||
the magnetic energy. The second command
|
||||
is :doc:`compute property/atom <compute_property_atom>`.
|
||||
It enables to output all the per atom magnetic quantities. Typically,
|
||||
the orientation of a given magnetic spin, or the magnetic force
|
||||
acting on this spin.
|
||||
|
||||
----------
|
||||
|
||||
|
||||
@ -49,7 +49,7 @@ details:
|
||||
| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
|
||||
|
|
||||
|
||||
Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
|
||||
Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
|
||||
|
||||
----------
|
||||
|
||||
|
||||
@ -97,7 +97,7 @@ This leads to slightly larger cost for the long-range calculation, so
|
||||
you can test the trade-off for your model. The OM distance and the LJ
|
||||
and Coulombic cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long <pair_lj_cut_tip4p>` command.
|
||||
|
||||
Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
|
||||
Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
|
||||
|
||||
----------
|
||||
|
||||
|
||||
126
doc/src/Howto_type_labels.rst
Normal file
126
doc/src/Howto_type_labels.rst
Normal file
@ -0,0 +1,126 @@
|
||||
Type labels
|
||||
===========
|
||||
|
||||
.. versionadded:: 15Sep2022
|
||||
|
||||
Each atom in LAMMPS has an associated numeric atom type. Similarly,
|
||||
each bond, angle, dihedral, and improper is assigned a bond type,
|
||||
angle type, and so on. The primary use of these types is to map
|
||||
potential (force field) parameters to the interactions of the atom,
|
||||
bond, angle, dihedral, and improper.
|
||||
|
||||
By default, type values are entered as integers from 1 to Ntypes
|
||||
wherever they appear in LAMMPS input or output files. The total number
|
||||
Ntypes for each interaction is "locked in" when the simulation box
|
||||
is created.
|
||||
|
||||
A recent addition to LAMMPS is the option to use strings - referred
|
||||
to as type labels - as an alternative. Using type labels instead of
|
||||
numeric types can be advantageous in various scenarios. For example,
|
||||
type labels can make inputs more readable and generic (i.e. usable through
|
||||
the :doc:`include command <include>` for different systems with different
|
||||
numerical values assigned to types. This generality also applies to
|
||||
other inputs like data files read by :doc:`read_data <read_data>` or
|
||||
molecule template files read by the :doc:`molecule <molecule>`
|
||||
command. See below for a list of other commands that can use
|
||||
type labels in different ways.
|
||||
|
||||
LAMMPS will *internally* continue to use numeric types, which means
|
||||
that many previous restrictions still apply. For example, the total
|
||||
number of types is locked in when creating the simulation box, and
|
||||
potential parameters for each type must be provided even if not used
|
||||
by any interactions.
|
||||
|
||||
A collection of type labels for all type-kinds (atom types, bond types,
|
||||
etc.) is stored as a "label map" which is simply a list of numeric types
|
||||
and their associated type labels. Within a type-kind, each type label
|
||||
must be unique. It can be assigned to only one numeric type. To read
|
||||
and write type labels to data files for a given type-kind, *all*
|
||||
associated numeric types need have a type label assigned. Partial
|
||||
maps can be saved with the :doc:`labelmap write <labelmap>` command
|
||||
and read back with the :doc:`include <include>` command.
|
||||
|
||||
Valid type labels can contain most ASCII characters, but cannot start
|
||||
with a number, a '#', or a '*'. Also, labels must not contain whitespace
|
||||
characters. When using the :doc:`labelmap command <labelmap>` in the
|
||||
LAMMPS input, if certain characters appear in the type label, such as
|
||||
the single (') or double (") quote or the '#' character, the label
|
||||
must be put in either double, single, or triple (""") quotes. Triple
|
||||
quotes allow for the most generic type label strings, but they require
|
||||
to have a leading and trailing blank space. When defining type labels
|
||||
the blanks will be ignored. Example:
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
labelmap angle 1 """ C1'-C2"-C3# """
|
||||
|
||||
This command will map the string ```C1'-C2"-C3#``` to the angle type 1.
|
||||
|
||||
There are two ways to define label maps. One is via the :doc:`labelmap
|
||||
<labelmap>` command. The other is via the :doc:`read_data <read_data>`
|
||||
command. A data file can have sections such as *Atom Type Labels*, *Bond
|
||||
Type Labels*, etc., which assign type labels to numeric types. The
|
||||
label map can be written out to data files by the :doc:`write_data
|
||||
<write_data>` command. This map is also written to and read from
|
||||
restart files, by the :doc:`write_restart <write_restart>` and
|
||||
:doc:`read_restart <read_restart>` commands.
|
||||
|
||||
----------
|
||||
|
||||
Use of type labels in LAMMPS input or output
|
||||
""""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
Many LAMMPS input script commands that take a numeric type as an
|
||||
argument can use the associated type label instead. If a type label
|
||||
is not defined for a particular numeric type, only its numeric type
|
||||
can be used.
|
||||
|
||||
This example assigns labels to the atom types, and then uses the type
|
||||
labels to redefine the pair coefficients.
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
pair_coeff 1 2 1.0 1.0 # numeric types
|
||||
labelmap atom 1 C 2 H
|
||||
pair_coeff C H 1.0 1.0 # type labels
|
||||
|
||||
Adding support for type labels to various commands is an ongoing
|
||||
project. If an input script command (or a section in a file read by a
|
||||
command) allows substituting a type label for a numeric type argument,
|
||||
it will be explicitly mentioned in that command's documentation page.
|
||||
|
||||
As a temporary measure, input script commands can take advantage of
|
||||
variables and how they can be expanded during processing of the input.
|
||||
The variables can use functions that will translate type label strings
|
||||
to their respective number as defined in the current label map. See the
|
||||
:doc:`variable <variable>` command for details.
|
||||
|
||||
For example, here is how the pair_coeff command could be used with
|
||||
type labels if it did not yet support them, either with an explicit
|
||||
variable command or an implicit variable used in the pair_coeff
|
||||
command.
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
labelmap atom 1 C 2 H
|
||||
variable atom1 equal label2type(atom,C)
|
||||
variable atom2 equal label2type(atom,H)
|
||||
pair_coeff ${atom1} ${atom2} 1.0 1.0
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
labelmap atom 1 C 2 H
|
||||
pair_coeff $(label2type(atom,C)) $(label2type(atom,H)) 80.0 1.2
|
||||
|
||||
----------
|
||||
|
||||
Commands that can use label types
|
||||
"""""""""""""""""""""""""""""""""
|
||||
|
||||
Any workflow that involves reading multiple data files, molecule
|
||||
templates or a combination of the two can be streamlined by using type
|
||||
labels instead of numeric types, because types are automatically synced
|
||||
between the files. The creation of simulation-ready reaction templates
|
||||
for :doc:`fix bond/react <fix_bond_react>` is much simpler when using
|
||||
type labels, and results in templates that can be used without
|
||||
modification in multiple simulations or different systems.
|
||||
@ -17,9 +17,10 @@ formats. See the :doc:`Tools <Tools>` page for details.
|
||||
|
||||
A Python-based toolkit distributed by our group can read native LAMMPS
|
||||
dump files, including custom dump files with additional columns of
|
||||
user-specified atom information, and convert them to various formats
|
||||
or pipe them into visualization software directly. See the `Pizza.py WWW site <pizza_>`_ for details. Specifically, Pizza.py can convert
|
||||
LAMMPS dump files into PDB, XYZ, `EnSight <ensight_>`_, and VTK formats.
|
||||
user-specified atom information, and convert them to various formats or
|
||||
pipe them into visualization software directly. See the `Pizza.py WWW
|
||||
site <pizza_>`_ for details. Specifically, Pizza.py can convert LAMMPS
|
||||
dump files into PDB, XYZ, `EnSight <ensight_>`_, and VTK formats.
|
||||
Pizza.py can pipe LAMMPS dump files directly into the Raster3d and
|
||||
RasMol visualization programs. Pizza.py has tools that do interactive
|
||||
3d OpenGL visualization and one that creates SVG images of dump file
|
||||
|
||||
@ -3,10 +3,20 @@ Install LAMMPS
|
||||
|
||||
You can download LAMMPS as an executable or as source code.
|
||||
|
||||
With source code, you also have to :doc:`build LAMMPS <Build>`. But you
|
||||
have more flexibility as to what features to include or exclude in the
|
||||
build. If you plan to :doc:`modify or extend LAMMPS <Modify>`, then you
|
||||
need the source code.
|
||||
When downloading the LAMMPS source code, you also have to :doc:`build
|
||||
LAMMPS <Build>`. But you have more flexibility as to what features to
|
||||
include or exclude in the build. When you download and install
|
||||
pre-compiled LAMMPS executables, you are limited to install which
|
||||
version of LAMMPS is available and which features are included of these
|
||||
builds. If you plan to :doc:`modify or extend LAMMPS <Modify>`, then
|
||||
you **must** build LAMMPS from the source code.
|
||||
|
||||
.. note::
|
||||
|
||||
If you have questions about the pre-compiled LAMMPS executables, you
|
||||
need to contact the people preparing those executables. The LAMMPS
|
||||
developers have no control over their choices of how they configure
|
||||
and build their packages and when they update them.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
@ -5,7 +5,7 @@ Binaries are available for MacOS or Linux via `Conda <conda_>`_.
|
||||
|
||||
First, one must setup the Conda package manager on your system. Follow the
|
||||
instructions to install `Miniconda <mini_conda_install_>`_, then create a conda
|
||||
environment (named `my-lammps-env` or whatever you prefer) for your lammps
|
||||
environment (named `my-lammps-env` or whatever you prefer) for your LAMMPS
|
||||
install:
|
||||
|
||||
.. code-block:: bash
|
||||
@ -13,7 +13,7 @@ install:
|
||||
% conda config --add channels conda-forge
|
||||
% conda create -n my-lammps-env
|
||||
|
||||
Then, you can install lammps on your system with the following command:
|
||||
Then, you can install LAMMPS on your system with the following command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -38,3 +38,10 @@ up the Conda capability.
|
||||
.. _openkim: https://openkim.org
|
||||
.. _conda: https://docs.conda.io/en/latest/index.html
|
||||
.. _mini_conda_install: https://docs.conda.io/en/latest/miniconda.html
|
||||
|
||||
.. note::
|
||||
|
||||
If you have questions about these pre-compiled LAMMPS executables,
|
||||
you need to contact the people preparing those packages. The LAMMPS
|
||||
developers have no control over their choices of how they configure
|
||||
and build their packages and when they update them.
|
||||
|
||||
@ -3,13 +3,19 @@ Download an executable for Linux
|
||||
|
||||
Binaries are available for different versions of Linux:
|
||||
|
||||
| :ref:`Pre-built Ubuntu Linux executables <ubuntu>`
|
||||
| :ref:`Pre-built Fedora Linux executables <fedora>`
|
||||
| :ref:`Pre-built EPEL Linux executables (RHEL, CentOS) <epel>`
|
||||
| :ref:`Pre-built OpenSuse Linux executables <opensuse>`
|
||||
| :ref:`Gentoo Linux executable <gentoo>`
|
||||
| :ref:`Arch Linux build-script <arch>`
|
||||
|
|
||||
- :ref:`Pre-built Ubuntu Linux executables <ubuntu>`
|
||||
- :ref:`Pre-built Fedora Linux executables <fedora>`
|
||||
- :ref:`Pre-built EPEL Linux executables (RHEL, CentOS) <epel>`
|
||||
- :ref:`Pre-built OpenSuse Linux executables <opensuse>`
|
||||
- :ref:`Gentoo Linux executable <gentoo>`
|
||||
- :ref:`Arch Linux build-script <arch>`
|
||||
|
||||
.. note::
|
||||
|
||||
If you have questions about these pre-compiled LAMMPS executables,
|
||||
you need to contact the people preparing those packages. The LAMMPS
|
||||
developers have no control over their choices of how they configure
|
||||
and build their packages and when they update them.
|
||||
|
||||
----------
|
||||
|
||||
@ -18,41 +24,28 @@ Binaries are available for different versions of Linux:
|
||||
Pre-built Ubuntu Linux executables
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
A pre-built LAMMPS executable suitable for running on the latest
|
||||
Ubuntu Linux versions, can be downloaded as a Debian package. This
|
||||
allows you to install LAMMPS with a single command, and stay
|
||||
up-to-date with the current stable version of LAMMPS by simply updating
|
||||
your operating system. Please note, that the repository below offers
|
||||
two LAMMPS packages, ``lammps-daily`` and ``lammps-stable``. The
|
||||
LAMMPS developers recommend to use the ``lammps-stable`` package for
|
||||
any production simulations. The ``lammps-daily`` package is built
|
||||
from the LAMMPS development sources, and those versions may have known
|
||||
issues and bugs when new features are added and the software has not
|
||||
undergone full release testing.
|
||||
|
||||
To install the appropriate personal-package archives (PPAs), do the
|
||||
following once:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo add-apt-repository ppa:gladky-anton/lammps
|
||||
$ sudo add-apt-repository ppa:openkim/latest
|
||||
$ sudo apt-get update
|
||||
A pre-built LAMMPS executable suitable for running on the latest Ubuntu
|
||||
Linux versions, can be downloaded as a Debian package. This allows you
|
||||
to install LAMMPS with a single command, and stay (mostly) up-to-date
|
||||
with the current stable version of LAMMPS by simply updating your
|
||||
operating system.
|
||||
|
||||
To install LAMMPS do the following once:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo apt-get install lammps-stable
|
||||
$ sudo apt-get install lammps
|
||||
|
||||
This downloads an executable named ``lmp_stable`` to your box, which
|
||||
can then be used in the usual way to run input scripts:
|
||||
This downloads an executable named ``lmp`` to your box and multiple
|
||||
packages with supporting data, examples and libraries as well as any
|
||||
missing dependencies. This executable can then be used in the usual way
|
||||
to run input scripts:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ lmp_stable -in in.lj
|
||||
$ lmp -in in.lj
|
||||
|
||||
To update LAMMPS to the most current stable version, do the following:
|
||||
To update LAMMPS to the latest packaged version, do the following:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -60,44 +53,24 @@ To update LAMMPS to the most current stable version, do the following:
|
||||
|
||||
which will also update other packages on your system.
|
||||
|
||||
To get a copy of the current documentation and examples:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo apt-get install lammps-stable-doc
|
||||
|
||||
which will download the doc files in
|
||||
``/usr/share/doc/lammps-stable-doc/doc`` and example problems in
|
||||
``/usr/share/doc/lammps-doc/examples``.
|
||||
|
||||
To get a copy of the current potentials files:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo apt-get install lammps-stable-data
|
||||
|
||||
which will download the potentials files to
|
||||
``/usr/share/lammps-stable/potentials``. The ``lmp_stable`` binary is
|
||||
hard-coded to look for potential files in this directory (it does not
|
||||
use the ``LAMMPS_POTENTIALS`` environment variable, as described
|
||||
in :doc:`pair_coeff <pair_coeff>` command).
|
||||
|
||||
The ``lmp_stable`` binary is built with the :ref:`KIM package <kim>` which
|
||||
results in the above command also installing the ``kim-api`` binaries when LAMMPS
|
||||
is installed. In order to use potentials from `openkim.org <openkim_>`_, you
|
||||
can install the ``openkim-models`` package
|
||||
The ``lmp`` binary is built with the :ref:`KIM package <kim>` included,
|
||||
which results in the above command also installing the ``kim-api``
|
||||
binaries when LAMMPS is installed. In order to use potentials from
|
||||
`openkim.org <openkim_>`_, you can also install the ``openkim-models``
|
||||
package
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo apt-get install openkim-models
|
||||
|
||||
Or use the KIM-API commands to download and install individual models.
|
||||
To un-install LAMMPS, do the following:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo apt-get remove lammps-stable
|
||||
$ sudo apt-get remove lammps
|
||||
|
||||
Please use ``lmp_stable -help`` to see which compilation options, packages,
|
||||
Please use ``lmp -help`` to see which compilation options, packages,
|
||||
and styles are included in the binary.
|
||||
|
||||
Thanks to Anton Gladky (gladky.anton at gmail.com) for setting up this
|
||||
@ -110,21 +83,21 @@ Ubuntu package capability.
|
||||
Pre-built Fedora Linux executables
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Pre-built LAMMPS packages for stable releases are available
|
||||
in the Fedora Linux distribution as of version 28. The packages
|
||||
can be installed via the dnf package manager. There are 3 basic
|
||||
varieties (lammps = no MPI, lammps-mpich = MPICH MPI library,
|
||||
lammps-openmpi = OpenMPI MPI library) and for each support for
|
||||
linking to the C library interface (lammps-devel, lammps-mpich-devel,
|
||||
lammps-openmpi-devel), the header for compiling programs using
|
||||
the C library interface (lammps-headers), and the LAMMPS python
|
||||
module for Python 3. All packages can be installed at the same
|
||||
time and the name of the LAMMPS executable is ``lmp`` and ``lmp_openmpi``
|
||||
or ``lmp_mpich`` respectively. By default, ``lmp`` will refer to the
|
||||
serial executable, unless one of the MPI environment modules is loaded
|
||||
(``module load mpi/mpich-x86_64`` or ``module load mpi/openmpi-x86_64``).
|
||||
Then the corresponding parallel LAMMPS executable can be used.
|
||||
The same mechanism applies when loading the LAMMPS python module.
|
||||
Pre-built LAMMPS packages for stable releases are available in the
|
||||
Fedora Linux distribution as of Fedora version 28. The packages can be
|
||||
installed via the dnf package manager. There are 3 basic varieties
|
||||
(lammps = no MPI, lammps-mpich = MPICH MPI library, lammps-openmpi =
|
||||
OpenMPI MPI library) and for each support for linking to the C library
|
||||
interface (lammps-devel, lammps-mpich-devel, lammps-openmpi-devel), the
|
||||
header for compiling programs using the C library interface
|
||||
(lammps-headers), and the LAMMPS python module for Python 3. All
|
||||
packages can be installed at the same time and the name of the LAMMPS
|
||||
executable is ``lmp`` and ``lmp_openmpi`` or ``lmp_mpich`` respectively.
|
||||
By default, ``lmp`` will refer to the serial executable, unless one of
|
||||
the MPI environment modules is loaded (``module load mpi/mpich-x86_64``
|
||||
or ``module load mpi/openmpi-x86_64``). Then the corresponding parallel
|
||||
LAMMPS executable can be used. The same mechanism applies when loading
|
||||
the LAMMPS python module.
|
||||
|
||||
To install LAMMPS with OpenMPI and run an input ``in.lj`` with 2 CPUs do:
|
||||
|
||||
@ -273,3 +246,10 @@ Alternatively, you may use an AUR helper to install these packages.
|
||||
|
||||
Note that the AUR provides build-scripts that download the source and
|
||||
the build the package on your machine.
|
||||
|
||||
.. note::
|
||||
|
||||
It looks like the Arch Linux AUR repository build scripts for LAMMPS
|
||||
have not been updated since the 29 October 2020 version. You may want
|
||||
to consider installing a more current version of LAMMPS from source
|
||||
directly.
|
||||
|
||||
@ -6,7 +6,7 @@ Windows system can be downloaded from this site:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
`http://packages.lammps.org/windows.html <http://packages.lammps.org/windows.html>`_
|
||||
`https://packages.lammps.org/windows.html <https://packages.lammps.org/windows.html>`_
|
||||
|
||||
Note that each installer package has a date in its name, which
|
||||
corresponds to the LAMMPS version of the same date. Installers for
|
||||
|
||||
@ -4,13 +4,13 @@ Authors of LAMMPS
|
||||
The primary LAMMPS developers are at Sandia National Labs and Temple
|
||||
University:
|
||||
|
||||
* `Steve Plimpton <sjp_>`_, sjplimp at sandia.gov
|
||||
* `Steve Plimpton <sjp_>`_, sjplimp at gmail.com
|
||||
* Aidan Thompson, athomps at sandia.gov
|
||||
* Stan Moore, stamoor at sandia.gov
|
||||
* Axel Kohlmeyer, akohlmey at gmail.com
|
||||
* Richard Berger, richard.berger at outlook.com
|
||||
|
||||
.. _sjp: http://www.cs.sandia.gov/~sjplimp
|
||||
.. _sjp: https://sjplimp.github.io
|
||||
.. _lws: https://www.lammps.org
|
||||
|
||||
Past developers include Paul Crozier and Mark Stevens, both at Sandia,
|
||||
|
||||
@ -27,15 +27,15 @@ namely https://www.lammps.org.
|
||||
The original publication describing the parallel algorithms used in the
|
||||
initial versions of LAMMPS is:
|
||||
|
||||
`S. Plimpton, Fast Parallel Algorithms for Short-Range Molecular Dynamics, J Comp Phys, 117, 1-19 (1995). <http://www.sandia.gov/~sjplimp/papers/jcompphys95.pdf>`_
|
||||
`S. Plimpton, Fast Parallel Algorithms for Short-Range Molecular Dynamics, J Comp Phys, 117, 1-19 (1995). <https://doi.org/10.1006/jcph.1995.1039>`_
|
||||
|
||||
|
||||
DOI for the LAMMPS source code
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
LAMMPS developers use the `Zenodo service at CERN <https://zenodo.org/>`_
|
||||
to create digital object identifies (DOI) for stable releases of the
|
||||
LAMMPS source code. There are two types of DOIs for the LAMMPS source code.
|
||||
The LAMMPS developers use the `Zenodo service at CERN <https://zenodo.org/>`_
|
||||
to create digital object identifiers (DOI) for stable releases of the
|
||||
LAMMPS source code. There are two types of DOIs for the LAMMPS source code.
|
||||
|
||||
The canonical DOI for **all** versions of LAMMPS, which will always
|
||||
point to the **latest** stable release version is:
|
||||
|
||||
@ -95,7 +95,7 @@ commands)
|
||||
* metal-organic framework potentials (QuickFF, MO-FF)
|
||||
* implicit solvent potentials: hydrodynamic lubrication, Debye
|
||||
* force-field compatibility with common CHARMM, AMBER, DREIDING, OPLS, GROMACS, COMPASS options
|
||||
* access to the `OpenKIM Repository <http://openkim.org>`_ of potentials via :doc:`kim command <kim_commands>`
|
||||
* access to the `OpenKIM Repository <https://openkim.org>`_ of potentials via the :doc:`kim command <kim_commands>`
|
||||
* hybrid potentials: multiple pair, bond, angle, dihedral, improper potentials can be used in one simulation
|
||||
* overlaid potentials: superposition of multiple pair potentials (including many-body) with optional scale factor
|
||||
|
||||
@ -205,7 +205,7 @@ Pre- and post-processing
|
||||
|
||||
.. _pizza: https://lammps.github.io/pizza
|
||||
|
||||
.. _python: http://www.python.org
|
||||
.. _python: https://www.python.org
|
||||
|
||||
.. _special:
|
||||
|
||||
|
||||
@ -33,7 +33,7 @@ Here are suggestions on how to perform these tasks:
|
||||
linear bead-spring polymer chains. The moltemplate program is a true
|
||||
molecular builder that will generate complex molecular models. See
|
||||
the :doc:`Tools <Tools>` page for details on tools packaged with
|
||||
LAMMPS. The `Pre/post processing page <http:/www.lammps.org/prepost.html>`_ of the LAMMPS website
|
||||
LAMMPS. The `Pre/post processing page <https:/www.lammps.org/prepost.html>`_ of the LAMMPS website
|
||||
describes a variety of third party tools for this task. Furthermore,
|
||||
some LAMMPS internal commands allow to reconstruct, or selectively add
|
||||
topology information, as well as provide the option to insert molecule
|
||||
@ -80,5 +80,5 @@ Here are suggestions on how to perform these tasks:
|
||||
`Pizza.py <https://lammps.github.io/pizza>`_ which can do certain kinds of
|
||||
setup, analysis, plotting, and visualization (via OpenGL) for LAMMPS
|
||||
simulations. It thus provides some functionality for several of the
|
||||
above bullets. Pizza.py is written in `Python <http://www.python.org>`_
|
||||
and is available for download from `this page <http://www.cs.sandia.gov/~sjplimp/download.html>`_.
|
||||
above bullets. Pizza.py is written in `Python <https://www.python.org>`_
|
||||
and is available for download from `this page <https://sjplimp.github.io/download.html>`_.
|
||||
|
||||
@ -23,9 +23,9 @@ applies to LAMMPS is in the LICENSE file included in the LAMMPS distribution.
|
||||
|
||||
.. _lgpl: https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
|
||||
|
||||
.. _gnuorg: http://www.gnu.org
|
||||
.. _gnuorg: https://www.gnu.org
|
||||
|
||||
.. _opensource: http://www.opensource.org
|
||||
.. _opensource: https://www.opensource.org
|
||||
|
||||
Here is a more specific summary of what the GPL means for LAMMPS users:
|
||||
|
||||
|
||||
BIN
doc/src/JPG/dump.peri.2000.png
Normal file
BIN
doc/src/JPG/dump.peri.2000.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 200 KiB |
BIN
doc/src/JPG/dump.peri.300.png
Normal file
BIN
doc/src/JPG/dump.peri.300.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 144 KiB |
BIN
doc/src/JPG/dump.peri.600.png
Normal file
BIN
doc/src/JPG/dump.peri.600.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 157 KiB |
BIN
doc/src/JPG/ovito-peri-snap.png
Normal file
BIN
doc/src/JPG/ovito-peri-snap.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 494 KiB |
BIN
doc/src/JPG/pdlammps_fig1.png
Normal file
BIN
doc/src/JPG/pdlammps_fig1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 160 KiB |
BIN
doc/src/JPG/pdlammps_fig2.png
Normal file
BIN
doc/src/JPG/pdlammps_fig2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 2.5 MiB |
@ -11,6 +11,7 @@ This section documents the following functions:
|
||||
- :cpp:func:`lammps_mpi_finalize`
|
||||
- :cpp:func:`lammps_kokkos_finalize`
|
||||
- :cpp:func:`lammps_python_finalize`
|
||||
- :cpp:func:`lammps_error`
|
||||
|
||||
--------------------
|
||||
|
||||
@ -115,3 +116,8 @@ calling program.
|
||||
|
||||
.. doxygenfunction:: lammps_python_finalize
|
||||
:project: progguide
|
||||
|
||||
-----------------------
|
||||
|
||||
.. doxygenfunction:: lammps_error
|
||||
:project: progguide
|
||||
|
||||
@ -6,6 +6,7 @@ fixes, or variables in LAMMPS using the following functions:
|
||||
|
||||
- :cpp:func:`lammps_extract_compute`
|
||||
- :cpp:func:`lammps_extract_fix`
|
||||
- :cpp:func:`lammps_extract_variable_datatype`
|
||||
- :cpp:func:`lammps_extract_variable`
|
||||
- :cpp:func:`lammps_set_variable`
|
||||
|
||||
@ -21,6 +22,11 @@ fixes, or variables in LAMMPS using the following functions:
|
||||
|
||||
-----------------------
|
||||
|
||||
.. doxygenfunction:: lammps_extract_variable_datatype
|
||||
:project: progguide
|
||||
|
||||
-----------------------
|
||||
|
||||
.. doxygenfunction:: lammps_extract_variable
|
||||
:project: progguide
|
||||
|
||||
@ -36,3 +42,5 @@ fixes, or variables in LAMMPS using the following functions:
|
||||
.. doxygenenum:: _LMP_STYLE_CONST
|
||||
|
||||
.. doxygenenum:: _LMP_TYPE_CONST
|
||||
|
||||
.. doxygenenum:: _LMP_VAR_CONST
|
||||
|
||||
@ -15,21 +15,21 @@ This section documents the following functions:
|
||||
|
||||
--------------------
|
||||
|
||||
The library interface allows extraction of different kinds of
|
||||
information about the active simulation instance and also
|
||||
modifications to it. This enables combining of a LAMMPS simulation
|
||||
with other processing and simulation methods computed by the calling
|
||||
code, or by another code that is coupled to LAMMPS via the library
|
||||
interface. In some cases the data returned is direct reference to the
|
||||
original data inside LAMMPS, cast to a void pointer. In that case the
|
||||
data needs to be cast to a suitable pointer for the calling program to
|
||||
access it, and you may need to know the correct dimensions and
|
||||
lengths. This also means you can directly change those value(s) from
|
||||
the calling program, e.g. to modify atom positions. Of course, this
|
||||
should be done with care. When accessing per-atom data, please note
|
||||
that this data is the per-processor **local** data and is indexed
|
||||
accordingly. Per-atom data can change sizes and ordering at every
|
||||
neighbor list rebuild or atom sort event as atoms migrate between
|
||||
The library interface allows the extraction of different kinds of
|
||||
information about the active simulation instance and also---in some
|
||||
cases---to apply modifications to it. This enables combining of a
|
||||
LAMMPS simulation with other processing and simulation methods computed
|
||||
by the calling code, or by another code that is coupled to LAMMPS via
|
||||
the library interface. In some cases the data returned is direct
|
||||
reference to the original data inside LAMMPS, cast to a void pointer.
|
||||
In that case the data needs to be cast to a suitable pointer for the
|
||||
calling program to access it, and you may need to know the correct
|
||||
dimensions and lengths. This also means you can directly change those
|
||||
value(s) from the calling program (e.g., to modify atom positions). Of
|
||||
course, changing values should be done with care. When accessing per-atom
|
||||
data, please note that these data are the per-processor **local** data and are
|
||||
indexed accordingly. Per-atom data can change sizes and ordering at
|
||||
every neighbor list rebuild or atom sort event as atoms migrate between
|
||||
sub-domains and processors.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
@ -19,6 +19,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_python_api_version`
|
||||
|
||||
The :cpp:func:`lammps_free` function is a clean-up function to free
|
||||
memory that the library had allocated previously via other function
|
||||
@ -100,3 +101,9 @@ where such memory buffers were allocated that require the use of
|
||||
|
||||
.. doxygenfunction:: lammps_get_last_error_message
|
||||
:project: progguide
|
||||
|
||||
-----------------------
|
||||
|
||||
.. doxygenfunction:: lammps_python_api_version
|
||||
:project: progguide
|
||||
|
||||
|
||||
@ -49,12 +49,12 @@ descriptions of all commands included in the LAMMPS code.
|
||||
|
||||
----------
|
||||
|
||||
.. _user_documentation:
|
||||
|
||||
************
|
||||
User Guide
|
||||
************
|
||||
|
||||
.. _user_documentation:
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:numbered: 3
|
||||
@ -75,11 +75,12 @@ User Guide
|
||||
Errors
|
||||
|
||||
|
||||
.. _programmer_documentation:
|
||||
|
||||
******************
|
||||
Programmer Guide
|
||||
******************
|
||||
|
||||
.. _programmer_documentation:
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:numbered: 3
|
||||
@ -110,6 +111,7 @@ Command Reference
|
||||
angles
|
||||
dihedrals
|
||||
impropers
|
||||
dumps
|
||||
fix_modify_atc_commands
|
||||
Bibliography
|
||||
|
||||
|
||||
@ -23,6 +23,8 @@ derived class. See fix.h for details.
|
||||
+---------------------------+--------------------------------------------------------------------------------------------+
|
||||
| init | initialization before a run (optional) |
|
||||
+---------------------------+--------------------------------------------------------------------------------------------+
|
||||
| init_list | store pointer to neighbor list; called by neighbor list code (optional) |
|
||||
+---------------------------+--------------------------------------------------------------------------------------------+
|
||||
| setup_pre_exchange | called before atom exchange in setup (optional) |
|
||||
+---------------------------+--------------------------------------------------------------------------------------------+
|
||||
| setup_pre_force | called before force computation in setup (optional) |
|
||||
|
||||
@ -100,13 +100,14 @@ Documentation (strict)
|
||||
|
||||
Contributions that add new styles or commands or augment existing ones
|
||||
must include the corresponding new or modified documentation in
|
||||
`ReStructuredText format <rst>`_ (.rst files in the ``doc/src/`` folder). The
|
||||
documentation shall be written in American English and the .rst file
|
||||
must use only ASCII characters so it can be cleanly translated to PDF
|
||||
files (via `sphinx <sphinx>`_ and PDFLaTeX). Special characters may be included via
|
||||
embedded math expression typeset in a LaTeX subset.
|
||||
`ReStructuredText format <rst_>`_ (.rst files in the ``doc/src/``
|
||||
folder). The documentation shall be written in American English and the
|
||||
.rst file must use only ASCII characters so it can be cleanly translated
|
||||
to PDF files (via `sphinx <https://www.sphinx-doc.org>`_ and PDFLaTeX).
|
||||
Special characters may be included via embedded math expression typeset
|
||||
in a LaTeX subset.
|
||||
|
||||
.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
|
||||
.. _rst: https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html
|
||||
|
||||
When adding new commands, they need to be integrated into the sphinx
|
||||
documentation system, and the corresponding command tables and lists
|
||||
@ -133,7 +134,7 @@ error free completion of the HTML and PDF build will be performed and
|
||||
also a spell check, a check for correct anchors and labels, and a check
|
||||
for completeness of references all styles in their corresponding tables
|
||||
and lists is run. In case the spell check reports false positives they
|
||||
can be added to the file doc/utils/sphinx-config/false_positives.txt
|
||||
can be added to the file ``doc/utils/sphinx-config/false_positives.txt``
|
||||
|
||||
Contributions that add or modify the library interface or "public" APIs
|
||||
from the C++ code or the Fortran module must include suitable doxygen
|
||||
|
||||
@ -27,6 +27,7 @@ page gives those details.
|
||||
:columns: 6
|
||||
|
||||
* :ref:`ADIOS <PKG-ADIOS>`
|
||||
* :ref:`AMOEBA <PKG-AMOEBA>`
|
||||
* :ref:`ASPHERE <PKG-ASPHERE>`
|
||||
* :ref:`ATC <PKG-ATC>`
|
||||
* :ref:`AWPMD <PKG-AWPMD>`
|
||||
@ -35,7 +36,7 @@ page gives those details.
|
||||
* :ref:`BPM <PKG-BPM>`
|
||||
* :ref:`BROWNIAN <PKG-BROWNIAN>`
|
||||
* :ref:`CG-DNA <PKG-CG-DNA>`
|
||||
* :ref:`CG-SDK <PKG-CG-SDK>`
|
||||
* :ref:`CG-SPICA <PKG-CG-SPICA>`
|
||||
* :ref:`CLASS2 <PKG-CLASS2>`
|
||||
* :ref:`COLLOID <PKG-COLLOID>`
|
||||
* :ref:`COLVARS <PKG-COLVARS>`
|
||||
@ -133,6 +134,8 @@ commands to write and read data using the ADIOS library.
|
||||
|
||||
**Authors:** Norbert Podhorszki (ORNL) from the ADIOS developer team.
|
||||
|
||||
.. versionadded:: 28Feb2019
|
||||
|
||||
**Install:**
|
||||
|
||||
This package has :ref:`specific installation instructions <adios>` on the :doc:`Build extras <Build_extras>` page.
|
||||
@ -149,6 +152,38 @@ This package has :ref:`specific installation instructions <adios>` on the :doc:`
|
||||
|
||||
----------
|
||||
|
||||
.. _PKG-AMOEBA:
|
||||
|
||||
AMOEBA package
|
||||
---------------
|
||||
|
||||
**Contents:**
|
||||
|
||||
Implementation of the AMOEBA and HIPPO polarized force fields
|
||||
originally developed by Jay Ponder's group at the U Washington at St
|
||||
Louis. The LAMMPS implementation is based on Fortran 90 code
|
||||
provided by the Ponder group in their
|
||||
`Tinker MD software <https://dasher.wustl.edu/tinker/>`_.
|
||||
|
||||
**Authors:** Josh Rackers and Steve Plimpton (Sandia), Trung Nguyen (U
|
||||
Chicago)
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/AMOEBA: filenames -> commands
|
||||
* :doc:`AMOEBA and HIPPO howto <Howto_amoeba>`
|
||||
* :doc:`pair_style amoeba <pair_amoeba>`
|
||||
* :doc:`pair_style hippo <pair_amoeba>`
|
||||
* :doc:`atom_style amoeba <atom_style>`
|
||||
* :doc:`angle_style amoeba <angle_amoeba>`
|
||||
* :doc:`improper_style amoeba <improper_amoeba>`
|
||||
* :doc:`fix amoeba/bitorsion <fix_amoeba_bitorsion>`
|
||||
* :doc:`fix amoeba/pitorsion <fix_amoeba_pitorsion>`
|
||||
* tools/tinker/tinker2lmp.py
|
||||
* examples/amoeba
|
||||
|
||||
----------
|
||||
|
||||
.. _PKG-ASPHERE:
|
||||
|
||||
ASPHERE package
|
||||
@ -181,9 +216,10 @@ ATC package
|
||||
|
||||
**Contents:**
|
||||
|
||||
ATC stands for atoms-to-continuum. This package implements a :doc:`fix atc <fix_atc>` command to either couple molecular dynamics with
|
||||
continuum finite element equations or perform on-the-fly conversion of
|
||||
atomic information to continuum fields.
|
||||
ATC stands for atoms-to-continuum. This package implements a
|
||||
:doc:`fix atc <fix_atc>` command to either couple molecular dynamics
|
||||
with continuum finite element equations or perform on-the-fly
|
||||
conversion of atomic information to continuum fields.
|
||||
|
||||
**Authors:** Reese Jones, Jeremy Templeton, Jon Zimmerman (Sandia).
|
||||
|
||||
@ -242,7 +278,7 @@ the barostat as outlined in:
|
||||
|
||||
N. J. H. Dunn and W. G. Noid, "Bottom-up coarse-grained models that
|
||||
accurately describe the structure, pressure, and compressibility of
|
||||
molecular liquids," J. Chem. Phys. 143, 243148 (2015).
|
||||
molecular liquids", J. Chem. Phys. 143, 243148 (2015).
|
||||
|
||||
**Authors:** Nicholas J. H. Dunn and Michael R. DeLyser (The
|
||||
Pennsylvania State University)
|
||||
@ -298,6 +334,8 @@ models for mesoscale simulations of solids and fracture. See the
|
||||
|
||||
**Authors:** Joel T. Clemmer (Sandia National Labs)
|
||||
|
||||
.. versionadded:: 4May2022
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/BPM filenames -> commands
|
||||
@ -328,6 +366,8 @@ and also support self-propelled particles.
|
||||
**Authors:** Sam Cameron (University of Bristol),
|
||||
Stefan Paquay (while at Brandeis University) (initial version of fix propel/self)
|
||||
|
||||
.. versionadded:: 14May2021
|
||||
|
||||
Example inputs are in the examples/PACKAGES/brownian folder.
|
||||
|
||||
----------
|
||||
@ -365,28 +405,30 @@ The CG-DNA package requires that also the `MOLECULE <PKG-MOLECULE>`_ and
|
||||
|
||||
----------
|
||||
|
||||
.. _PKG-CG-SDK:
|
||||
.. _PKG-CG-SPICA:
|
||||
|
||||
CG-SDK package
|
||||
CG-SPICA package
|
||||
------------------
|
||||
|
||||
**Contents:**
|
||||
|
||||
Several pair styles and an angle style which implement the
|
||||
coarse-grained SDK model of Shinoda, DeVane, and Klein which enables
|
||||
simulation of ionic liquids, electrolytes, lipids and charged amino
|
||||
acids.
|
||||
coarse-grained SPICA (formerly called SDK) model which enables
|
||||
simulation of biological or soft material systems.
|
||||
|
||||
**Author:** Axel Kohlmeyer (Temple U).
|
||||
**Original Author:** Axel Kohlmeyer (Temple U).
|
||||
|
||||
**Maintainers:** Yusuke Miyazaki and Wataru Shinoda (Okayama U).
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/CG-SDK: filenames -> commands
|
||||
* src/CG-SDK/README
|
||||
* :doc:`pair_style lj/sdk/\* <pair_sdk>`
|
||||
* :doc:`angle_style sdk <angle_sdk>`
|
||||
* examples/PACKAGES/cgsdk
|
||||
* src/CG-SPICA: filenames -> commands
|
||||
* src/CG-SPICA/README
|
||||
* :doc:`pair_style lj/spica/\* <pair_spica>`
|
||||
* :doc:`angle_style spica <angle_spica>`
|
||||
* examples/PACKAGES/cgspica
|
||||
* https://www.lammps.org/pictures.html#cg
|
||||
* https://www.spica-ff.org/
|
||||
|
||||
----------
|
||||
|
||||
@ -554,6 +596,8 @@ To use this package, also the :ref:`KSPACE <PKG-KSPACE>` and
|
||||
|
||||
**Author:** Trung Nguyen and Monica Olvera de la Cruz (Northwestern U)
|
||||
|
||||
.. versionadded:: 2Jul2021
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/DIELECTRIC: filenames -> commands
|
||||
@ -614,7 +658,7 @@ short-range or long-range interactions.
|
||||
* :doc:`pair_style lj/cut/dipole/cut <pair_dipole>`
|
||||
* :doc:`pair_style lj/cut/dipole/long <pair_dipole>`
|
||||
* :doc:`pair_style lj/long/dipole/long <pair_dipole>`
|
||||
* :doc: `angle_style dipole <angle_dipole>`
|
||||
* :doc:`angle_style dipole <angle_dipole>`
|
||||
* examples/dipole
|
||||
|
||||
----------
|
||||
@ -824,6 +868,8 @@ groups of atoms that interact with the remaining atoms as electrolyte.
|
||||
Ahrens-Iwers (TUHH, Hamburg, Germany), Shern Tee (UQ, Brisbane, Australia) and
|
||||
Robert Meissner (TUHH, Hamburg, Germany).
|
||||
|
||||
.. versionadded:: 4May2022
|
||||
|
||||
**Install:**
|
||||
|
||||
This package has :ref:`specific installation instructions <electrode>` on the
|
||||
@ -892,6 +938,10 @@ EXTRA-MOLECULE package
|
||||
|
||||
Additional bond, angle, dihedral, and improper styles that are less commonly used.
|
||||
|
||||
**Install:**
|
||||
|
||||
To use this package, also the :ref:`MOLECULE <PKG-MOLECULE>` package needs to be installed.
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/EXTRA-MOLECULE: filenames -> commands
|
||||
@ -1027,7 +1077,7 @@ H5MD is a format for molecular simulations, built on top of HDF5.
|
||||
This package implements a :doc:`dump h5md <dump_h5md>` command to output
|
||||
LAMMPS snapshots in this format.
|
||||
|
||||
.. _HDF5: http://www.hdfgroup.org/HDF5
|
||||
.. _HDF5: https://www.hdfgroup.org/solutions/hdf5
|
||||
|
||||
To use this package you must have the HDF5 library available on your
|
||||
system.
|
||||
@ -1364,7 +1414,7 @@ This package has :ref:`specific installation instructions <machdyn>` on the :doc
|
||||
|
||||
* src/MACHDYN: filenames -> commands
|
||||
* src/MACHDYN/README
|
||||
* doc/PDF/MACHDYN_LAMMPS_userguide.pdf
|
||||
* `doc/PDF/MACHDYN_LAMMPS_userguide.pdf <PDF/MACHDYN_LAMMPS_userguide.pdf>`_
|
||||
* examples/PACKAGES/machdyn
|
||||
* https://www.lammps.org/movies.html#smd
|
||||
|
||||
@ -1468,6 +1518,8 @@ workflows via the `MolSSI Driver Interface
|
||||
|
||||
**Author:** Taylor Barnes - MolSSI, taylor.a.barnes at gmail.com
|
||||
|
||||
.. versionadded:: 14May2021
|
||||
|
||||
**Install:**
|
||||
|
||||
This package has :ref:`specific installation instructions <mdi>` on
|
||||
@ -1516,33 +1568,44 @@ MESONT package
|
||||
|
||||
**Contents:**
|
||||
|
||||
MESONT is a LAMMPS package for simulation of nanomechanics of
|
||||
nanotubes (NTs). The model is based on a coarse-grained representation
|
||||
of NTs as "flexible cylinders" consisting of a variable number of
|
||||
MESONT is a LAMMPS package for simulation of nanomechanics of nanotubes
|
||||
(NTs). The model is based on a coarse-grained representation of NTs as
|
||||
"flexible cylinders" consisting of a variable number of
|
||||
segments. Internal interactions within a NT and the van der Waals
|
||||
interaction between the tubes are described by a mesoscopic force field
|
||||
designed and parameterized based on the results of atomic-level
|
||||
molecular dynamics simulations. The description of the force field is
|
||||
provided in the papers listed below. This package contains two
|
||||
independent implementations of this model: :doc:`pair_style mesocnt
|
||||
<pair_mesocnt>` is a (minimal) C++ implementation, and :doc:`pair_style
|
||||
mesont/tpm <pair_mesont_tpm>` is a more general and feature rich
|
||||
implementation based on a Fortran library in the ``lib/mesont`` folder.
|
||||
provided in the papers listed below.
|
||||
|
||||
This package contains two independent implementations of this model:
|
||||
:doc:`pair_style mesont/tpm <pair_mesont_tpm>` is the original
|
||||
implementation of the model based on a Fortran library in the
|
||||
``lib/mesont`` folder. The second implementation is provided by the
|
||||
mesocnt styles (:doc:`bond_style mesocnt <bond_mesocnt>`,
|
||||
:doc:`angle_style mesocnt <angle_mesocnt>` and :doc:`pair_style mesocnt
|
||||
<pair_mesocnt>`). The mesocnt implementation has the same features as
|
||||
the original implementation with the addition of friction, but is
|
||||
directly implemented in C++, interfaces more cleanly with general LAMMPS
|
||||
functionality, and is typically faster. It also does not require its own
|
||||
atom style and can be installed without any external libraries.
|
||||
|
||||
**Download of potential files:**
|
||||
|
||||
The potential files for these pair styles are *very* large and thus
|
||||
are not included in the regular downloaded packages of LAMMPS or the
|
||||
git repositories. Instead, they will be automatically downloaded
|
||||
from a web server when the package is installed for the first time.
|
||||
The potential files for these pair styles are *very* large and thus are
|
||||
not included in the regular downloaded packages of LAMMPS or the git
|
||||
repositories. Instead, they will be automatically downloaded from a web
|
||||
server when the package is installed for the first time.
|
||||
|
||||
**Authors of the *mesont* styles:**
|
||||
|
||||
Maxim V. Shugaev (University of Virginia), Alexey N. Volkov (University of Alabama), Leonid V. Zhigilei (University of Virginia)
|
||||
Maxim V. Shugaev (University of Virginia), Alexey N. Volkov (University
|
||||
of Alabama), Leonid V. Zhigilei (University of Virginia)
|
||||
|
||||
**Author of the *mesocnt* pair style:**
|
||||
**Author of the *mesocnt* styles:**
|
||||
Philipp Kloza (U Cambridge)
|
||||
|
||||
.. versionadded:: 15Jun2020
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/MESONT: filenames -> commands
|
||||
@ -1550,6 +1613,8 @@ Philipp Kloza (U Cambridge)
|
||||
* :doc:`atom_style mesont <atom_style>`
|
||||
* :doc:`pair_style mesont/tpm <pair_mesont_tpm>`
|
||||
* :doc:`compute mesont <compute_mesont>`
|
||||
* :doc:`bond_style mesocnt <bond_mesocnt>`
|
||||
* :doc:`angle_style mesocnt <angle_mesocnt>`
|
||||
* :doc:`pair_style mesocnt <pair_mesocnt>`
|
||||
* examples/PACKAGES/mesont
|
||||
* tools/mesont
|
||||
@ -1633,6 +1698,8 @@ compiled on your system.
|
||||
|
||||
**Author:** Andreas Singraber
|
||||
|
||||
.. versionadded:: 27May2021
|
||||
|
||||
**Install:**
|
||||
|
||||
This package has :ref:`specific installation instructions <ml-hdnnp>` on the
|
||||
@ -1667,6 +1734,10 @@ must be installed.
|
||||
|
||||
**Author:** Aidan Thompson (Sandia), Nicholas Lubbers (LANL).
|
||||
|
||||
.. versionadded:: 30Jun2020
|
||||
|
||||
.. versionadded:: 30Jun2020
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/ML-IAP: filenames -> commands
|
||||
@ -1711,6 +1782,8 @@ Aidan Thompson^3, Gabor Csanyi^2, Christoph Ortner^4, Ralf Drautz^1.
|
||||
|
||||
^4: University of British Columbia, Vancouver, BC, Canada
|
||||
|
||||
.. versionadded:: 14May2021
|
||||
|
||||
**Install:**
|
||||
|
||||
This package has :ref:`specific installation instructions <ml-pace>` on the
|
||||
@ -1774,6 +1847,8 @@ of a neural network.
|
||||
This package was written by Christopher Barrett
|
||||
with contributions by Doyl Dickel, Mississippi State University.
|
||||
|
||||
.. versionadded:: 27May2021
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/ML-RANN: filenames -> commands
|
||||
@ -1899,7 +1974,7 @@ support for new file formats can be added to LAMMPS (or VMD or other
|
||||
programs that use them) without having to re-compile the application
|
||||
itself. More information about the VMD molfile plugins can be found
|
||||
at
|
||||
`http://www.ks.uiuc.edu/Research/vmd/plugins/molfile <http://www.ks.uiuc.edu/Research/vmd/plugins/molfile>`_.
|
||||
`https://www.ks.uiuc.edu/Research/vmd/plugins/molfile <https://www.ks.uiuc.edu/Research/vmd/plugins/molfile>`_.
|
||||
|
||||
**Author:** Axel Kohlmeyer (Temple U).
|
||||
|
||||
@ -1990,7 +2065,7 @@ NETCDF package
|
||||
Dump styles for writing NetCDF formatted dump files. NetCDF is a
|
||||
portable, binary, self-describing file format developed on top of
|
||||
HDF5. The file contents follow the AMBER NetCDF trajectory conventions
|
||||
(http://ambermd.org/netcdf/nctraj.xhtml), but include extensions.
|
||||
(https://ambermd.org/netcdf/nctraj.xhtml), but include extensions.
|
||||
|
||||
To use this package you must have the NetCDF library available on your
|
||||
system.
|
||||
@ -2001,7 +2076,7 @@ tools:
|
||||
* `Ovito <ovito_>`_ (Ovito supports the AMBER convention and the extensions mentioned above)
|
||||
* `VMD <vmd-home_>`_
|
||||
|
||||
.. _ovito: http://www.ovito.org
|
||||
.. _ovito: https://www.ovito.org
|
||||
|
||||
.. _vmd-home: https://www.ks.uiuc.edu/Research/vmd/
|
||||
|
||||
@ -2145,6 +2220,7 @@ Foster (UTSA).
|
||||
**Supporting info:**
|
||||
|
||||
* src/PERI: filenames -> commands
|
||||
* :doc:`Peridynamics Howto <Howto_peri>`
|
||||
* `doc/PDF/PDLammps_overview.pdf <PDF/PDLammps_overview.pdf>`_
|
||||
* `doc/PDF/PDLammps_EPS.pdf <PDF/PDLammps_EPS.pdf>`_
|
||||
* `doc/PDF/PDLammps_VES.pdf <PDF/PDLammps_VES.pdf>`_
|
||||
@ -2209,6 +2285,8 @@ try to load the contained plugins automatically at start-up.
|
||||
|
||||
**Authors:** Axel Kohlmeyer (Temple U)
|
||||
|
||||
.. versionadded:: 8Apr2021
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/PLUGIN: filenames -> commands
|
||||
@ -2362,7 +2440,7 @@ A :doc:`fix qmmm <fix_qmmm>` command which allows LAMMPS to be used as
|
||||
the MM code in a QM/MM simulation. This is currently only available
|
||||
in combination with the `Quantum ESPRESSO <espresso_>`_ package.
|
||||
|
||||
.. _espresso: http://www.quantum-espresso.org
|
||||
.. _espresso: https://www.quantum-espresso.org
|
||||
|
||||
To use this package you must have Quantum ESPRESSO (QE) available on
|
||||
your system and include its coupling library in the compilation and
|
||||
@ -2652,7 +2730,7 @@ Dynamics, Ernst Mach Institute, Germany).
|
||||
|
||||
* src/SPH: filenames -> commands
|
||||
* src/SPH/README
|
||||
* doc/PDF/SPH_LAMMPS_userguide.pdf
|
||||
* `doc/PDF/SPH_LAMMPS_userguide.pdf <PDF/SPH_LAMMPS_userguide.pdf>`_
|
||||
* examples/PACKAGES/sph
|
||||
* https://www.lammps.org/movies.html#sph
|
||||
|
||||
@ -2774,7 +2852,7 @@ collection of atoms by wrapping the `Voro++ library <voro-home_>`_. This
|
||||
can be used to calculate the local volume or each atoms or its near
|
||||
neighbors.
|
||||
|
||||
.. _voro-home: http://math.lbl.gov/voro++
|
||||
.. _voro-home: https://math.lbl.gov/voro++
|
||||
|
||||
To use this package you must have the Voro++ library available on your
|
||||
system.
|
||||
@ -2808,9 +2886,9 @@ A :doc:`dump vtk <dump_vtk>` command which outputs snapshot info in the
|
||||
`VTK format <vtk_>`_, enabling visualization by `Paraview <paraview_>`_ or
|
||||
other visualization packages.
|
||||
|
||||
.. _vtk: http://www.vtk.org
|
||||
.. _vtk: https://www.vtk.org
|
||||
|
||||
.. _paraview: http://www.paraview.org
|
||||
.. _paraview: https://www.paraview.org
|
||||
|
||||
To use this package you must have VTK library available on your
|
||||
system.
|
||||
@ -2847,11 +2925,13 @@ which discuss the `QuickFF <quickff_>`_ methodology.
|
||||
|
||||
.. _vanduyfhuys2015: https://doi.org/10.1002/jcc.23877
|
||||
.. _vanduyfhuys2018: https://doi.org/10.1002/jcc.25173
|
||||
.. _quickff: http://molmod.github.io/QuickFF
|
||||
.. _quickff: https://molmod.github.io/QuickFF
|
||||
.. _yaff: https://github.com/molmod/yaff
|
||||
|
||||
**Author:** Steven Vandenbrande.
|
||||
|
||||
.. versionadded:: 1Feb2019
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/YAFF/README
|
||||
|
||||
@ -33,6 +33,11 @@ whether an extra library is needed to build and use the package:
|
||||
- :doc:`dump adios <dump_adios>`
|
||||
- PACKAGES/adios
|
||||
- ext
|
||||
* - :ref:`AMOEBA <PKG-AMOEBA>`
|
||||
- AMOEBA and HIPPO force fields
|
||||
- :doc:`AMOEBA and HIPPO howto <Howto_amoeba>`
|
||||
- amoeba
|
||||
- no
|
||||
* - :ref:`ASPHERE <PKG-ASPHERE>`
|
||||
- aspherical particle models
|
||||
- :doc:`Howto spherical <Howto_spherical>`
|
||||
@ -73,10 +78,10 @@ whether an extra library is needed to build and use the package:
|
||||
- src/CG-DNA/README
|
||||
- PACKAGES/cgdna
|
||||
- no
|
||||
* - :ref:`CG-SDK <PKG-CG-SDK>`
|
||||
- SDK coarse-graining model
|
||||
- :doc:`pair_style lj/sdk <pair_sdk>`
|
||||
- PACKAGES/cgsdk
|
||||
* - :ref:`CG-SPICA <PKG-CG-SPICA>`
|
||||
- SPICA (SDK) coarse-graining model
|
||||
- :doc:`pair_style lj/spica <pair_spica>`
|
||||
- PACKAGES/cgspica
|
||||
- no
|
||||
* - :ref:`CLASS2 <PKG-CLASS2>`
|
||||
- class 2 force fields
|
||||
|
||||
@ -43,26 +43,18 @@ Note that for AtomEye, you need version 3, and there is a line in the
|
||||
scripts that specifies the path and name of the executable. See the
|
||||
AtomEye web pages for more details:
|
||||
|
||||
* `http://li.mit.edu/Archive/Graphics/A/ <atomeye_>`_
|
||||
* `http://li.mit.edu/Archive/Graphics/A3/A3.html <atomeye3_>`_
|
||||
* `http://li.mit.edu/Archive/Graphics/A/ <http://li.mit.edu/Archive/Graphics/A/>`_
|
||||
* `http://li.mit.edu/Archive/Graphics/A3/A3.html <http://li.mit.edu/Archive/Graphics/A3/A3.html>`_
|
||||
|
||||
.. _atomeye: http://li.mit.edu/Archive/Graphics/A/
|
||||
|
||||
.. _atomeye3: http://li.mit.edu/Archive/Graphics/A3/A3.html
|
||||
|
||||
The latter link is to AtomEye 3 which has the scripting
|
||||
capability needed by these Python scripts.
|
||||
The latter link is to AtomEye 3 which has the scripting capability
|
||||
needed by these Python scripts.
|
||||
|
||||
Note that for PyMol, you need to have built and installed the
|
||||
open-source version of PyMol in your Python, so that you can import it
|
||||
from a Python script. See the PyMol web pages for more details:
|
||||
|
||||
* `https://www.pymol.org <pymolhome_>`_
|
||||
* `https://github.com/schrodinger/pymol-open-source <pymolopen_>`_
|
||||
|
||||
.. _pymolhome: https://www.pymol.org
|
||||
|
||||
.. _pymolopen: https://github.com/schrodinger/pymol-open-source
|
||||
* `https://www.pymol.org <https://www.pymol.org>`_
|
||||
* `https://github.com/schrodinger/pymol-open-source <https://github.com/schrodinger/pymol-open-source>`_
|
||||
|
||||
The latter link is to the open-source version.
|
||||
|
||||
|
||||
@ -18,17 +18,17 @@ together.
|
||||
Python_error
|
||||
Python_trouble
|
||||
|
||||
If you are not familiar with `Python <http://www.python.org>`_, it is a
|
||||
If you are not familiar with `Python <https://www.python.org>`_, it is a
|
||||
powerful scripting and programming language which can do almost
|
||||
everything that compiled languages like C, C++, or Fortran can do in
|
||||
fewer lines of code. It also comes with a large collection of add-on
|
||||
modules for many purposes (either bundled or easily installed from
|
||||
Python code repositories). The major drawback is slower execution speed
|
||||
of the script code compared to compiled programming languages. But when
|
||||
the script code is interfaced to optimized compiled code, performance can
|
||||
be on par with a standalone executable, for as long as the scripting is
|
||||
restricted to high-level operations. Thus Python is also convenient to
|
||||
use as a "glue" language to "drive" a program through its library
|
||||
the script code is interfaced to optimized compiled code, performance
|
||||
can be on par with a standalone executable, for as long as the scripting
|
||||
is restricted to high-level operations. Thus Python is also convenient
|
||||
to use as a "glue" language to "drive" a program through its library
|
||||
interface, or to hook multiple pieces of software together, such as a
|
||||
simulation code and a visualization tool, or to run a coupled
|
||||
multi-scale or multi-physics model.
|
||||
|
||||
@ -38,6 +38,40 @@ using the NumPy access method.
|
||||
for n in np.nditer(nlist):
|
||||
print(" atom {} with ID {}".format(n,tags[n]))
|
||||
|
||||
Another example for extracting a full neighbor list without evaluating a
|
||||
potential is shown below.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from lammps import lammps
|
||||
import numpy as np
|
||||
|
||||
lmp = lammps()
|
||||
lmp.commands_string("""
|
||||
newton off
|
||||
region box block -2 2 -2 2 -2 2
|
||||
lattice fcc 1.0
|
||||
create_box 1 box
|
||||
create_atoms 1 box
|
||||
mass 1 1.0
|
||||
pair_style zero 1.0 full
|
||||
pair_coeff * *
|
||||
run 0 post no""")
|
||||
|
||||
# look up the neighbor list
|
||||
nlidx = lmp.find_pair_neighlist('zero')
|
||||
nl = lmp.numpy.get_neighlist(nlidx)
|
||||
tags = lmp.extract_atom('id')
|
||||
print("full neighbor list with {} entries".format(nl.size))
|
||||
# print neighbor list contents
|
||||
for i in range(0,nl.size):
|
||||
idx, nlist = nl.get(i)
|
||||
print("\natom {} with ID {} has {} neighbors:".format(idx,tags[idx],nlist.size))
|
||||
if nlist.size > 0:
|
||||
for n in np.nditer(nlist):
|
||||
pass
|
||||
print(" atom {} with ID {}".format(n,tags[n]))
|
||||
|
||||
**Methods:**
|
||||
|
||||
* :py:meth:`lammps.get_neighlist() <lammps.lammps.get_neighlist()>`: Get neighbor list for given index
|
||||
|
||||
@ -30,12 +30,13 @@ executable itself can be placed elsewhere.
|
||||
|
||||
.. note::
|
||||
|
||||
The redirection operator "<" will not always work when running
|
||||
in parallel with mpirun or mpiexec; for those systems the -in form is required.
|
||||
The redirection operator "<" will not always work when running in
|
||||
parallel with ``mpirun`` or ``mpiexec``; for those systems the -in
|
||||
form is required.
|
||||
|
||||
As LAMMPS runs it prints info to the screen and a logfile named
|
||||
*log.lammps*\ . More info about output is given on the
|
||||
:doc:`screen and logfile output <Run_output>` page.
|
||||
*log.lammps*\ . More info about output is given on the :doc:`screen and
|
||||
logfile output <Run_output>` page.
|
||||
|
||||
If LAMMPS encounters errors in the input script or while running a
|
||||
simulation it will print an ERROR message and stop or a WARNING
|
||||
|
||||
@ -14,6 +14,7 @@ letter abbreviation can be used:
|
||||
* :ref:`-m or -mpicolor <mpicolor>`
|
||||
* :ref:`-c or -cite <cite>`
|
||||
* :ref:`-nc or -nocite <nocite>`
|
||||
* :ref:`-nb or -nonbuf <nonbuf>`
|
||||
* :ref:`-pk or -package <package>`
|
||||
* :ref:`-p or -partition <partition>`
|
||||
* :ref:`-pl or -plog <plog>`
|
||||
@ -92,13 +93,13 @@ switch is not set (the default), LAMMPS will operate as if the KOKKOS
|
||||
package were not installed; i.e. you can run standard LAMMPS or with
|
||||
the GPU or OPENMP packages, for testing or benchmarking purposes.
|
||||
|
||||
Additional optional keyword/value pairs can be specified which
|
||||
determine how Kokkos will use the underlying hardware on your
|
||||
platform. These settings apply to each MPI task you launch via the
|
||||
"mpirun" or "mpiexec" command. You may choose to run one or more MPI
|
||||
tasks per physical node. Note that if you are running on a desktop
|
||||
machine, you typically have one physical node. On a cluster or
|
||||
supercomputer there may be dozens or 1000s of physical nodes.
|
||||
Additional optional keyword/value pairs can be specified which determine
|
||||
how Kokkos will use the underlying hardware on your platform. These
|
||||
settings apply to each MPI task you launch via the ``mpirun`` or
|
||||
``mpiexec`` command. You may choose to run one or more MPI tasks per
|
||||
physical node. Note that if you are running on a desktop machine, you
|
||||
typically have one physical node. On a cluster or supercomputer there
|
||||
may be dozens or 1000s of physical nodes.
|
||||
|
||||
Either the full word or an abbreviation can be used for the keywords.
|
||||
Note that the keywords do not use a leading minus sign. I.e. the
|
||||
@ -147,9 +148,9 @@ one of these 4 environment variables
|
||||
MV2_COMM_WORLD_LOCAL_RANK (Mvapich)
|
||||
OMPI_COMM_WORLD_LOCAL_RANK (OpenMPI)
|
||||
|
||||
which are initialized by the "srun", "mpirun" or "mpiexec" commands.
|
||||
The environment variable setting for each MPI rank is used to assign a
|
||||
unique GPU ID to the MPI task.
|
||||
which are initialized by the ``srun``, ``mpirun``, or ``mpiexec``
|
||||
commands. The environment variable setting for each MPI rank is used to
|
||||
assign a unique GPU ID to the MPI task.
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
@ -257,6 +258,24 @@ Disable generating a citation reminder (see above) at all.
|
||||
|
||||
----------
|
||||
|
||||
.. _nonbuf:
|
||||
|
||||
**-nonbuf**
|
||||
|
||||
Turn off buffering for screen and logfile output. For performance
|
||||
reasons, output to the screen and logfile is usually buffered, i.e.
|
||||
output is only written to a file if its buffer - typically 4096 bytes -
|
||||
has been filled. When LAMMPS crashes for some reason, however, that can
|
||||
mean that there is important output missing. With this flag the
|
||||
buffering can be turned off (only for screen and logfile output) and any
|
||||
output will be committed immediately. Note that when running in
|
||||
parallel with MPI, the screen output may still be buffered by the MPI
|
||||
library and this cannot be changed by LAMMPS. This flag should only be
|
||||
used for debugging and not for production simulations as the performance
|
||||
impact can be significant, especially for large parallel runs.
|
||||
|
||||
----------
|
||||
|
||||
.. _package:
|
||||
|
||||
**-package style args ....**
|
||||
@ -476,7 +495,7 @@ run:
|
||||
write_dump group-ID dumpstyle dumpfile arg1 arg2 ...
|
||||
|
||||
Note that the specified restartfile and dumpfile names may contain
|
||||
wild-card characters ("\*","%") as explained on the
|
||||
wild-card characters ("\*" or "%") as explained on the
|
||||
:doc:`read_restart <read_restart>` and :doc:`write_dump <write_dump>` doc
|
||||
pages. The use of "%" means that a parallel restart file and/or
|
||||
parallel dump file can be read and/or written. Note that a filename
|
||||
|
||||
@ -25,8 +25,8 @@ in parallel, follow these steps.
|
||||
|
||||
Download and install a compatible MPI library binary package:
|
||||
|
||||
* for 32-bit Windows: `mpich2-1.4.1p1-win-ia32.msi <http://download.lammps.org/thirdparty/mpich2-1.4.1p1-win-ia32.msi>`_
|
||||
* for 64-bit Windows: `mpich2-1.4.1p1-win-x86-64.msi <http://download.lammps.org/thirdparty/mpich2-1.4.1p1-win-x86-64.msi>`_
|
||||
* for 32-bit Windows: `mpich2-1.4.1p1-win-ia32.msi <https://download.lammps.org/thirdparty/mpich2-1.4.1p1-win-ia32.msi>`_
|
||||
* for 64-bit Windows: `mpich2-1.4.1p1-win-x86-64.msi <https://download.lammps.org/thirdparty/mpich2-1.4.1p1-win-x86-64.msi>`_
|
||||
|
||||
The LAMMPS Windows installer packages will automatically adjust your
|
||||
path for the default location of this MPI package. After the
|
||||
|
||||
@ -39,7 +39,7 @@ toolkit software on your system (this is only tested on Linux
|
||||
and unsupported on Windows):
|
||||
|
||||
* Check if you have an NVIDIA GPU: cat /proc/driver/nvidia/gpus/\*/information
|
||||
* Go to http://www.nvidia.com/object/cuda_get.html
|
||||
* Go to https://developer.nvidia.com/cuda-downloads
|
||||
* Install a driver and toolkit appropriate for your system (SDK is not necessary)
|
||||
* Run lammps/lib/gpu/nvc_get_devices (after building the GPU library, see below) to
|
||||
list supported devices and properties
|
||||
@ -76,10 +76,11 @@ instructions.
|
||||
|
||||
**Run with the GPU package from the command line:**
|
||||
|
||||
The mpirun or mpiexec command sets the total number of MPI tasks used
|
||||
by LAMMPS (one or multiple per compute node) and the number of MPI
|
||||
tasks used per node. E.g. the mpirun command in MPICH does this via
|
||||
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.
|
||||
The ``mpirun`` or ``mpiexec`` command sets the total number of MPI tasks
|
||||
used by LAMMPS (one or multiple per compute node) and the number of MPI
|
||||
tasks used per node. E.g. the ``mpirun`` command in MPICH does this via
|
||||
its ``-np`` and ``-ppn`` switches. Ditto for OpenMPI via ``-np`` and
|
||||
``-npernode``.
|
||||
|
||||
When using the GPU package, you cannot assign more than one GPU to a
|
||||
single MPI task. However multiple MPI tasks can share the same GPU,
|
||||
@ -129,8 +130,8 @@ GPU package pair styles.
|
||||
|
||||
**Or run with the GPU package by editing an input script:**
|
||||
|
||||
The discussion above for the mpirun/mpiexec command, MPI tasks/node,
|
||||
and use of multiple MPI tasks/GPU is the same.
|
||||
The discussion above for the ``mpirun`` or ``mpiexec`` command, MPI
|
||||
tasks/node, and use of multiple MPI tasks/GPU is the same.
|
||||
|
||||
Use the :doc:`suffix gpu <suffix>` command, or you can explicitly add an
|
||||
"gpu" suffix to individual styles in your input script, e.g.
|
||||
|
||||
@ -536,6 +536,6 @@ supported.
|
||||
References
|
||||
""""""""""
|
||||
|
||||
* Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakkar, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., "Optimizing Classical Molecular Dynamics in LAMMPS," in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann.
|
||||
* Brown, W. M., Semin, A., Hebenstreit, M., Khvostov, S., Raman, K., Plimpton, S.J. `Increasing Molecular Dynamics Simulation Rates with an 8-Fold Increase in Electrical Power Efficiency. <http://dl.acm.org/citation.cfm?id=3014915>`_ 2016 High Performance Computing, Networking, Storage and Analysis, SC16: International Conference (pp. 82-95).
|
||||
* Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakkar, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., "Optimizing Classical Molecular Dynamics in LAMMPS", in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann.
|
||||
* Brown, W. M., Semin, A., Hebenstreit, M., Khvostov, S., Raman, K., Plimpton, S.J. `Increasing Molecular Dynamics Simulation Rates with an 8-Fold Increase in Electrical Power Efficiency. <https://dl.acm.org/citation.cfm?id=3014915>`_ 2016 High Performance Computing, Networking, Storage and Analysis, SC16: International Conference (pp. 82-95).
|
||||
* Brown, W.M., Carrillo, J.-M.Y., Gavhane, N., Thakkar, F.M., Plimpton, S.J. Optimizing Legacy Molecular Dynamics Software with Directive-Based Offload. Computer Physics Communications. 2015. 195: p. 95-101.
|
||||
|
||||
@ -72,12 +72,12 @@ See the :ref:`Build extras <kokkos>` page for instructions.
|
||||
Running LAMMPS with the KOKKOS package
|
||||
""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
All Kokkos operations occur within the context of an individual MPI
|
||||
task running on a single node of the machine. The total number of MPI
|
||||
tasks used by LAMMPS (one or multiple per compute node) is set in the
|
||||
usual manner via the mpirun or mpiexec commands, and is independent of
|
||||
Kokkos. E.g. the mpirun command in OpenMPI does this via its -np and
|
||||
-npernode switches. Ditto for MPICH via -np and -ppn.
|
||||
All Kokkos operations occur within the context of an individual MPI task
|
||||
running on a single node of the machine. The total number of MPI tasks
|
||||
used by LAMMPS (one or multiple per compute node) is set in the usual
|
||||
manner via the ``mpirun`` or ``mpiexec`` commands, and is independent of
|
||||
Kokkos. E.g. the mpirun command in OpenMPI does this via its ``-np`` and
|
||||
``-npernode`` switches. Ditto for MPICH via ``-np`` and ``-ppn``.
|
||||
|
||||
Running on a multi-core CPU
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
@ -168,7 +168,7 @@ for your MPI installation), binding can be forced with these flags:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
OpenMPI 1.8: mpirun -np 2 --bind-to socket --map-by socket ./lmp_openmpi ...
|
||||
OpenMPI 1.8: mpirun -np 2 --bind-to socket --map-by socket ./lmp_openmpi ...
|
||||
Mvapich2 2.0: mpiexec -np 2 --bind-to socket --map-by socket ./lmp_mvapich ...
|
||||
|
||||
For binding threads with KOKKOS OpenMP, use thread affinity environment
|
||||
@ -310,7 +310,8 @@ Alternatively the effect of the "-sf" or "-pk" switches can be
|
||||
duplicated by adding the :doc:`package kokkos <package>` or :doc:`suffix kk <suffix>` commands to your input script.
|
||||
|
||||
The discussion above for building LAMMPS with the KOKKOS package, the
|
||||
mpirun/mpiexec command, and setting appropriate thread are the same.
|
||||
``mpirun`` or ``mpiexec`` command, and setting appropriate thread
|
||||
properties are the same.
|
||||
|
||||
You must still use the "-k on" :doc:`command-line switch <Run_options>`
|
||||
to enable the KOKKOS package, and specify its additional arguments for
|
||||
|
||||
@ -33,8 +33,8 @@ These examples assume one or more 16-core nodes.
|
||||
mpirun -np 4 lmp_omp -sf omp -pk omp 4 -in in.script # 4 MPI tasks, 4 threads/task
|
||||
mpirun -np 32 -ppn 4 lmp_omp -sf omp -pk omp 4 -in in.script # 8 nodes, 4 MPI tasks/node, 4 threads/task
|
||||
|
||||
The mpirun or mpiexec command sets the total number of MPI tasks used
|
||||
by LAMMPS (one or multiple per compute node) and the number of MPI
|
||||
The ``mpirun`` or ``mpiexec`` command sets the total number of MPI tasks
|
||||
used by LAMMPS (one or multiple per compute node) and the number of MPI
|
||||
tasks used per node. E.g. the mpirun command in MPICH does this via
|
||||
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.
|
||||
|
||||
@ -58,8 +58,8 @@ OMP_NUM_THREADS environment variable.
|
||||
Or run with the OPENMP package by editing an input script
|
||||
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
The discussion above for the mpirun/mpiexec command, MPI tasks/node,
|
||||
and threads/MPI task is the same.
|
||||
The discussion above for the ``mpirun`` or ``mpiexec`` command, MPI
|
||||
tasks/node, and threads/MPI task is the same.
|
||||
|
||||
Use the :doc:`suffix omp <suffix>` command, or you can explicitly add an
|
||||
"omp" suffix to individual styles in your input script, e.g.
|
||||
@ -97,7 +97,7 @@ sub-section.
|
||||
|
||||
A description of the multi-threading strategy used in the OPENMP
|
||||
package and some performance examples are
|
||||
`presented here <http://sites.google.com/site/akohlmey/software/lammps-icms/lammps-icms-tms2011-talk.pdf?attredirects=0&d=1>`_.
|
||||
`presented here <https://drive.google.com/file/d/1d1gLK6Ru6aPYB50Ld2tO10Li8zgPVNB8/view?usp=sharing>`_.
|
||||
|
||||
Guidelines for best performance
|
||||
"""""""""""""""""""""""""""""""
|
||||
|
||||
@ -117,33 +117,15 @@ script.
|
||||
with all its accelerator packages installed. Note however that the
|
||||
INTEL and KOKKOS packages require you to choose one of their
|
||||
hardware options when building for a specific platform. I.e. CPU or
|
||||
Phi option for the INTEL package. Or the OpenMP, Cuda, or Phi
|
||||
option for the KOKKOS package.
|
||||
Phi option for the INTEL package. Or the OpenMP, CUDA, HIP, SYCL,
|
||||
or Phi option for the KOKKOS package. Or the OpenCL, HIP, or CUDA
|
||||
option for the GPU package.
|
||||
|
||||
These are the exceptions. You cannot build a single executable with:
|
||||
|
||||
* both the INTEL Phi and KOKKOS Phi options
|
||||
* the INTEL Phi or Kokkos Phi option, and the GPU package
|
||||
|
||||
See the examples/accelerate/README and make.list files for sample
|
||||
Make.py commands that build LAMMPS with any or all of the accelerator
|
||||
packages. As an example, here is a command that builds with all the
|
||||
GPU related packages installed (GPU, KOKKOS with Cuda), including
|
||||
settings to build the needed auxiliary GPU libraries for Kepler GPUs:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
Make.py -j 16 -p omp gpu kokkos -cc nvcc wrap=mpi -gpu mode=double arch=35 -kokkos cuda arch=35 lib-all file mpi
|
||||
|
||||
The examples/accelerate directory also has input scripts that can be
|
||||
used with all of the accelerator packages. See its README file for
|
||||
details.
|
||||
|
||||
Likewise, the bench directory has FERMI and KEPLER and PHI
|
||||
sub-directories with Make.py commands and input scripts for using all
|
||||
the accelerator packages on various machines. See the README files in
|
||||
those directories.
|
||||
|
||||
As mentioned above, the `Benchmark page <https://www.lammps.org/bench.html>`_ of the LAMMPS website gives
|
||||
performance results for the various accelerator packages for several
|
||||
of the standard LAMMPS benchmark problems, as a function of problem
|
||||
|
||||
@ -205,6 +205,7 @@ scripts are available:
|
||||
whitespace.py # detects TAB characters and trailing whitespace
|
||||
homepage.py # detects outdated LAMMPS homepage URLs (pointing to sandia.gov instead of lammps.org)
|
||||
errordocs.py # detects deprecated error docs in header files
|
||||
versiontags.py # detects .. versionadded:: or .. versionchanged:: with pending version date
|
||||
|
||||
The tools need to be given the main folder of the LAMMPS distribution
|
||||
or individual file names as argument and will by default check them
|
||||
@ -397,7 +398,7 @@ ipp tool
|
||||
------------------
|
||||
|
||||
The tools/ipp directory contains a Perl script ipp which can be used
|
||||
to facilitate the creation of a complicated file (say, a lammps input
|
||||
to facilitate the creation of a complicated file (say, a LAMMPS input
|
||||
script or tools/createatoms input file) using a template file.
|
||||
|
||||
ipp was created and is maintained by Reese Jones (Sandia), rjones at
|
||||
@ -512,8 +513,8 @@ with an ``.inputrc`` file in the home directory. For application
|
||||
specific customization, the LAMMPS shell uses the name "lammps-shell".
|
||||
For more information about using and customizing an application using
|
||||
readline, please see the available documentation at:
|
||||
`http://www.gnu.org/s/readline/#Documentation
|
||||
<http://www.gnu.org/s/readline/#Documentation>`_
|
||||
https://www.gnu.org/software/readline/
|
||||
|
||||
|
||||
Additional commands
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
@ -715,7 +716,7 @@ See the README.pdf file for more information.
|
||||
These scripts were written by Arun Subramaniyan at Purdue Univ
|
||||
(asubrama at purdue.edu).
|
||||
|
||||
.. _matlabhome: http://www.mathworks.com
|
||||
.. _matlabhome: https://www.mathworks.com
|
||||
|
||||
----------
|
||||
|
||||
@ -1046,7 +1047,7 @@ the binary file. This usually is a so-called little endian hardware
|
||||
SWIG interface
|
||||
--------------
|
||||
|
||||
The `SWIG tool <http://swig.org>`_ offers a mostly automated way to
|
||||
The `SWIG tool <https://swig.org>`_ offers a mostly automated way to
|
||||
incorporate compiled code modules into scripting languages. It
|
||||
processes the function prototypes in C and generates wrappers for a wide
|
||||
variety of scripting languages from it. Thus it can also be applied to
|
||||
@ -1126,7 +1127,7 @@ data passed or returned as pointers are included in the ``lammps.i``
|
||||
file. So most of the functionality of the library interface should be
|
||||
accessible. What works and what does not depends a bit on the
|
||||
individual language for which the wrappers are built and how well SWIG
|
||||
supports those. The `SWIG documentation <http://swig.org/doc.html>`_
|
||||
supports those. The `SWIG documentation <https://swig.org/doc.html>`_
|
||||
has very detailed instructions and recommendations.
|
||||
|
||||
Usage examples
|
||||
|
||||
@ -6,7 +6,7 @@ page. The accelerated styles take the same arguments and should
|
||||
produce the same results, except for round-off and precision issues.
|
||||
|
||||
These accelerated styles are part of the GPU, INTEL, KOKKOS,
|
||||
OPENMP and OPT packages, respectively. They are only enabled if
|
||||
OPENMP, and OPT packages, respectively. They are only enabled if
|
||||
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` page for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
|
||||
138
doc/src/angle_amoeba.rst
Normal file
138
doc/src/angle_amoeba.rst
Normal file
@ -0,0 +1,138 @@
|
||||
.. index:: angle_style amoeba
|
||||
|
||||
angle_style amoeba command
|
||||
==========================
|
||||
|
||||
|
||||
Syntax
|
||||
""""""
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
angle_style amoeba
|
||||
|
||||
Examples
|
||||
""""""""
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
angle_style amoeba
|
||||
angle_coeff * 75.0 -25.0 1.0 0.3 0.02 0.003
|
||||
angle_coeff * ba 3.6551 24.895 1.0119 1.5228
|
||||
angle_coeff * ub -7.6 1.5537
|
||||
|
||||
Description
|
||||
"""""""""""
|
||||
|
||||
The *amoeba* angle style uses the potential
|
||||
|
||||
.. math::
|
||||
|
||||
E & = E_a + E_{ba} + E_{ub} \\
|
||||
E_a & = K_2\left(\theta - \theta_0\right)^2 + K_3\left(\theta - \theta_0\right)^3 + K_4\left(\theta - \theta_0\right)^4 + K_5\left(\theta - \theta_0\right)^5 + K_6\left(\theta - \theta_0\right)^6 \\
|
||||
E_{ba} & = N_1 (r_{ij} - r_1) (\theta - \theta_0) + N_2(r_{jk} - r_2)(\theta - \theta_0) \\
|
||||
E_{UB} & = K_{ub} (r_{ik} - r_{ub})^2
|
||||
|
||||
where :math:`E_a` is the angle term, :math:`E_{ba}` is a bond-angle
|
||||
term, :math:`E_{UB}` is a Urey-Bradley bond term, :math:`\theta_0` is
|
||||
the equilibrium angle, :math:`r_1` and :math:`r_2` are the equilibrium
|
||||
bond lengths, and :math:`r_{ub}` is the equilibrium Urey-Bradley bond
|
||||
length.
|
||||
|
||||
These formulas match how the Tinker MD code performs its angle
|
||||
calculations for the AMOEBA and HIPPO force fields. See the
|
||||
:doc:`Howto amoeba <Howto_amoeba>` page for more information about
|
||||
the implementation of AMOEBA and HIPPO in LAMMPS.
|
||||
|
||||
Note that the :math:`E_a` and :math:`E_{ba}` formulas are identical to
|
||||
those used for the :doc:`angle_style class2/p6 <angle_class2>`
|
||||
command, however there is no bond-bond cross term formula for
|
||||
:math:`E_{bb}`. Additionally, there is a :math:`E_{UB}` term for a
|
||||
Urey-Bradley bond. It is effectively a harmonic bond between the I
|
||||
and K atoms of angle IJK, even though that bond is not enumerated in
|
||||
the "Bonds" section of the data file.
|
||||
|
||||
There are also two ways that Tinker computes the angle :math:`\theta`
|
||||
in the :math:`E_a` formula. The first is the standard way of treating
|
||||
IJK as an "in-plane" angle. The second is an "out-of-plane" method
|
||||
which Tinker may use if the center atom J in the angle is bonded to
|
||||
one additional atom in addition to I and K. In this case, all 4 atoms
|
||||
are used to compute the :math:`E_a` formula, resulting in forces on
|
||||
all 4 atoms. In the Tinker PRM file, these 2 options are denoted by
|
||||
*angle* versus *anglep* entries in the "Angle Bending Parameters"
|
||||
section of the PRM force field file. The *pflag* coefficient
|
||||
described below selects between the 2 options.
|
||||
|
||||
----------
|
||||
|
||||
|
||||
Coefficients for the :math:`E_a`, :math:`E_{bb}`, and :math:`E_{ub}`
|
||||
formulas must be defined for each angle type via the :doc:`angle_coeff
|
||||
<angle_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.
|
||||
|
||||
These are the 8 coefficients for the :math:`E_a` formula:
|
||||
|
||||
* pflag = 0 or 1
|
||||
* ubflag = 0 or 1
|
||||
* :math:`\theta_0` (degrees)
|
||||
* :math:`K_2` (energy)
|
||||
* :math:`K_3` (energy)
|
||||
* :math:`K_4` (energy)
|
||||
* :math:`K_5` (energy)
|
||||
* :math:`K_6` (energy)
|
||||
|
||||
A pflag value of 0 vs 1 selects between the "in-plane" and
|
||||
"out-of-plane" options described above. Ubflag is 1 if there is a
|
||||
Urey-Bradley term associated with this angle type, else it is 0.
|
||||
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to
|
||||
radians internally; hence the various :math:`K` values are effectively
|
||||
energy per radian\^2 or radian\^3 or radian\^4 or radian\^5 or
|
||||
radian\^6.
|
||||
|
||||
For the :math:`E_{ba}` formula, each line in a :doc:`angle_coeff
|
||||
<angle_coeff>` command in the input script lists 5 coefficients, the
|
||||
first of which is "ba" to indicate they are BondAngle coefficients.
|
||||
In a data file, these coefficients should be listed under a "BondAngle
|
||||
Coeffs" heading and you must leave out the "ba", i.e. only list 4
|
||||
coefficients after the angle type.
|
||||
|
||||
* ba
|
||||
* :math:`N_1` (energy/distance\^2)
|
||||
* :math:`N_2` (energy/distance\^2)
|
||||
* :math:`r_1` (distance)
|
||||
* :math:`r_2` (distance)
|
||||
|
||||
The :math:`\theta_0` value in the :math:`E_{ba}` formula is not specified,
|
||||
since it is the same value from the :math:`E_a` formula.
|
||||
|
||||
For the :math:`E_{ub}` formula, each line in a :doc:`angle_coeff
|
||||
<angle_coeff>` command in the input script lists 3 coefficients, the
|
||||
first of which is "ub" to indicate they are UreyBradley coefficients.
|
||||
In a data file, these coefficients should be listed under a
|
||||
"UreyBradley Coeffs" heading and you must leave out the "ub",
|
||||
i.e. only list 2 coefficients after the angle type.
|
||||
|
||||
* ub
|
||||
* :math:`K_{ub}` (energy/distance\^2)
|
||||
* :math:`r_{ub}` (distance)
|
||||
|
||||
----------
|
||||
|
||||
Restrictions
|
||||
""""""""""""
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the AMOEBA
|
||||
package. See the :doc:`Build package <Build_package>` doc page for
|
||||
more info.
|
||||
|
||||
Related commands
|
||||
""""""""""""""""
|
||||
|
||||
:doc:`angle_coeff <angle_coeff>`
|
||||
|
||||
Default
|
||||
"""""""
|
||||
|
||||
none
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user