Merge branch 'develop' into gran-temp
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
|
||||
|
||||
7
.github/ISSUE_TEMPLATE/help_request.md
vendored
7
.github/ISSUE_TEMPLATE/help_request.md
vendored
@ -1,6 +1,6 @@
|
||||
---
|
||||
name: Request for Help
|
||||
about: "Don't post help requests here, email the lammps-users mailing list"
|
||||
about: "Don't post help requests here, post in the LAMMPS forum"
|
||||
title: ""
|
||||
labels: invalid
|
||||
assignees: ''
|
||||
@ -8,8 +8,9 @@ assignees: ''
|
||||
---
|
||||
|
||||
Please **do not** post requests for help (e.g. with installing or using LAMMPS) here.
|
||||
Instead send an e-mail to the lammps-users mailing list.
|
||||
Instead, you can post to the LAMMPS category in the Materials Science Community
|
||||
Discourse forum at: https://matsci.org/lammps/
|
||||
|
||||
This issue tracker is for tracking LAMMPS development related issues only.
|
||||
|
||||
Thanks for your cooperation.
|
||||
Thank you in advance for your cooperation.
|
||||
|
||||
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/dependabot.yml
vendored
Normal file
6
.github/dependabot.yml
vendored
Normal file
@ -0,0 +1,6 @@
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "github-actions"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
13
.github/workflows/codeql-analysis.yml
vendored
13
.github/workflows/codeql-analysis.yml
vendored
@ -13,6 +13,11 @@ jobs:
|
||||
if: ${{ github.repository == 'lammps/lammps' }}
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
permissions:
|
||||
security-events: write
|
||||
actions: read
|
||||
contents: read
|
||||
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
@ -20,17 +25,17 @@ jobs:
|
||||
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@v2
|
||||
uses: actions/checkout@v3
|
||||
with:
|
||||
fetch-depth: 2
|
||||
|
||||
- name: Setup Python
|
||||
uses: actions/setup-python@v2
|
||||
uses: actions/setup-python@v4
|
||||
with:
|
||||
python-version: '3.x'
|
||||
|
||||
- name: Initialize CodeQL
|
||||
uses: github/codeql-action/init@v1
|
||||
uses: github/codeql-action/init@v2
|
||||
with:
|
||||
languages: ${{ matrix.language }}
|
||||
config-file: ./.github/codeql/${{ matrix.language }}.yml
|
||||
@ -48,4 +53,4 @@ jobs:
|
||||
cmake --build . --parallel 2
|
||||
|
||||
- name: Perform CodeQL Analysis
|
||||
uses: github/codeql-action/analyze@v1
|
||||
uses: github/codeql-action/analyze@v2
|
||||
|
||||
10
.github/workflows/compile-msvc.yml
vendored
10
.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:
|
||||
|
||||
@ -15,12 +19,12 @@ jobs:
|
||||
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@v2
|
||||
uses: actions/checkout@v3
|
||||
with:
|
||||
fetch-depth: 2
|
||||
|
||||
- name: Select Python version
|
||||
uses: actions/setup-python@v2
|
||||
uses: actions/setup-python@v4
|
||||
with:
|
||||
python-version: '3.10'
|
||||
|
||||
|
||||
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
|
||||
11
.github/workflows/unittest-macos.yml
vendored
11
.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:
|
||||
|
||||
@ -17,7 +21,7 @@ jobs:
|
||||
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@v2
|
||||
uses: actions/checkout@v3
|
||||
with:
|
||||
fetch-depth: 2
|
||||
|
||||
@ -28,7 +32,7 @@ jobs:
|
||||
run: mkdir build
|
||||
|
||||
- name: Set up ccache
|
||||
uses: actions/cache@v2
|
||||
uses: actions/cache@v3
|
||||
with:
|
||||
path: ${{ env.CCACHE_DIR }}
|
||||
key: macos-ccache-${{ github.sha }}
|
||||
@ -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"
|
||||
4
README
4
README
@ -16,8 +16,8 @@ National Laboratories, a US Department of Energy facility, with
|
||||
funding from the DOE. It is an open-source code, distributed freely
|
||||
under the terms of the GNU Public License (GPL) version 2.
|
||||
|
||||
The primary author of the code is Steve Plimpton, who can be emailed
|
||||
at sjplimp@sandia.gov. The LAMMPS WWW Site at www.lammps.org has
|
||||
The code is maintained by the LAMMPS development team who can be emailed
|
||||
at developers@lammps.org. The LAMMPS WWW Site at www.lammps.org has
|
||||
more information about the code and its uses.
|
||||
|
||||
The LAMMPS distribution includes the following files and directories:
|
||||
|
||||
28
SECURITY.md
28
SECURITY.md
@ -19,9 +19,9 @@ kinds of filesystem manipulations. And because of that LAMMPS should
|
||||
"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.
|
||||
|
||||
@ -7,11 +7,20 @@ cmake_minimum_required(VERSION 3.10)
|
||||
if(POLICY CMP0074)
|
||||
cmake_policy(SET CMP0074 NEW)
|
||||
endif()
|
||||
# set policy to silence warnings about ignoring ${CMAKE_REQUIRED_LIBRARIES} but use it
|
||||
if(POLICY CMP0075)
|
||||
cmake_policy(SET CMP0075 NEW)
|
||||
endif()
|
||||
# set policy to silence warnings about missing executable permissions in
|
||||
# pythonx.y-config when cross-compiling. review occasionally if it may be set to NEW
|
||||
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 +109,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,10 +144,10 @@ 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") 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_definitions(_CRT_SECURE_NO_WARNINGS)
|
||||
@ -152,6 +161,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)
|
||||
@ -192,6 +214,7 @@ option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
|
||||
|
||||
set(STANDARD_PACKAGES
|
||||
ADIOS
|
||||
AMOEBA
|
||||
ASPHERE
|
||||
ATC
|
||||
AWPMD
|
||||
@ -200,7 +223,7 @@ set(STANDARD_PACKAGES
|
||||
BPM
|
||||
BROWNIAN
|
||||
CG-DNA
|
||||
CG-SDK
|
||||
CG-SPICA
|
||||
CLASS2
|
||||
COLLOID
|
||||
COLVARS
|
||||
@ -356,17 +379,19 @@ 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)
|
||||
find_package(OpenMP QUIET)
|
||||
if(OpenMP_FOUND)
|
||||
check_include_file_cxx(omp.h HAVE_OMP_H_INCLUDE)
|
||||
find_package(OpenMP COMPONENTS CXX QUIET)
|
||||
if(OpenMP_CXX_FOUND)
|
||||
check_omp_h_include()
|
||||
if(HAVE_OMP_H_INCLUDE)
|
||||
set(BUILD_OMP_DEFAULT ON)
|
||||
endif()
|
||||
@ -375,8 +400,8 @@ endif()
|
||||
option(BUILD_OMP "Build with OpenMP support" ${BUILD_OMP_DEFAULT})
|
||||
|
||||
if(BUILD_OMP)
|
||||
find_package(OpenMP REQUIRED)
|
||||
check_include_file_cxx(omp.h HAVE_OMP_H_INCLUDE)
|
||||
find_package(OpenMP COMPONENTS CXX REQUIRED)
|
||||
check_omp_h_include()
|
||||
if(NOT HAVE_OMP_H_INCLUDE)
|
||||
message(FATAL_ERROR "Cannot find the 'omp.h' header file required for full OpenMP support")
|
||||
endif()
|
||||
@ -400,9 +425,11 @@ endif()
|
||||
|
||||
if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_LATTE OR PKG_ELECTRODE)
|
||||
enable_language(C)
|
||||
if (NOT USE_INTERNAL_LINALG)
|
||||
find_package(LAPACK)
|
||||
find_package(BLAS)
|
||||
if(NOT LAPACK_FOUND OR NOT BLAS_FOUND)
|
||||
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")
|
||||
@ -631,7 +658,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()
|
||||
@ -704,18 +731,17 @@ list(FIND LANGUAGES "Fortran" _index)
|
||||
if(_index GREATER -1)
|
||||
target_link_libraries(lammps PRIVATE ${CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES})
|
||||
endif()
|
||||
set(LAMMPS_CXX_HEADERS angle.h atom.h bond.h citeme.h comm.h compute.h dihedral.h domain.h error.h fix.h force.h group.h improper.h
|
||||
input.h info.h kspace.h lammps.h lattice.h library.h lmppython.h lmptype.h memory.h modify.h neighbor.h neigh_list.h output.h
|
||||
pair.h pointers.h region.h timer.h universe.h update.h utils.h variable.h)
|
||||
if(LAMMPS_EXCEPTIONS)
|
||||
list(APPEND LAMMPS_CXX_HEADERS exceptions.h)
|
||||
endif()
|
||||
set(LAMMPS_CXX_HEADERS angle.h atom.h bond.h citeme.h comm.h command.h compute.h dihedral.h domain.h
|
||||
error.h exceptions.h fix.h force.h group.h improper.h input.h info.h kspace.h lammps.h lattice.h
|
||||
library.h lmppython.h lmptype.h memory.h modify.h neighbor.h neigh_list.h output.h pair.h
|
||||
platform.h pointers.h region.h timer.h universe.h update.h utils.h variable.h)
|
||||
set(LAMMPS_FMT_HEADERS core.h format.h)
|
||||
|
||||
set_target_properties(lammps PROPERTIES OUTPUT_NAME lammps${LAMMPS_MACHINE})
|
||||
set_target_properties(lammps PROPERTIES SOVERSION ${SOVERSION})
|
||||
set_target_properties(lammps PROPERTIES PREFIX "lib")
|
||||
target_include_directories(lammps PUBLIC $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}/lammps>)
|
||||
file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps)
|
||||
file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/fmt)
|
||||
foreach(_HEADER ${LAMMPS_CXX_HEADERS})
|
||||
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/${_HEADER} COMMAND ${CMAKE_COMMAND} -E copy_if_different ${LAMMPS_SOURCE_DIR}/${_HEADER} ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/${_HEADER} DEPENDS ${LAMMPS_SOURCE_DIR}/${_HEADER})
|
||||
add_custom_target(${_HEADER} DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/${_HEADER})
|
||||
@ -724,6 +750,14 @@ foreach(_HEADER ${LAMMPS_CXX_HEADERS})
|
||||
install(FILES ${LAMMPS_SOURCE_DIR}/${_HEADER} DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/lammps)
|
||||
endif()
|
||||
endforeach()
|
||||
foreach(_HEADER ${LAMMPS_FMT_HEADERS})
|
||||
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/fmt/${_HEADER} COMMAND ${CMAKE_COMMAND} -E copy_if_different ${LAMMPS_SOURCE_DIR}/fmt/${_HEADER} ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/fmt/${_HEADER} DEPENDS ${LAMMPS_SOURCE_DIR}/fmt/${_HEADER})
|
||||
add_custom_target(fmt_${_HEADER} DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/fmt/${_HEADER})
|
||||
add_dependencies(lammps fmt_${_HEADER})
|
||||
if(BUILD_SHARED_LIBS)
|
||||
install(FILES ${LAMMPS_SOURCE_DIR}/fmt/${_HEADER} DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/lammps/fmt)
|
||||
endif()
|
||||
endforeach()
|
||||
target_include_directories(lammps INTERFACE $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/includes>)
|
||||
add_library(LAMMPS::lammps ALIAS lammps)
|
||||
get_target_property(LAMMPS_DEFINES lammps INTERFACE_COMPILE_DEFINITIONS)
|
||||
@ -781,17 +815,23 @@ if(BUILD_SHARED_LIBS)
|
||||
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
|
||||
endif()
|
||||
else()
|
||||
# backward compatibility
|
||||
if(PYTHON_EXECUTABLE)
|
||||
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
|
||||
endif()
|
||||
find_package(Python COMPONENTS Interpreter)
|
||||
endif()
|
||||
if(BUILD_IS_MULTI_CONFIG)
|
||||
set(LIBLAMMPS_SHARED_BINARY ${CMAKE_BINARY_DIR}/$<CONFIG>/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX})
|
||||
set(MY_BUILD_DIR ${CMAKE_BINARY_DIR}/$<CONFIG>)
|
||||
else()
|
||||
set(LIBLAMMPS_SHARED_BINARY ${CMAKE_BINARY_DIR}/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX})
|
||||
set(MY_BUILD_DIR ${CMAKE_BINARY_DIR})
|
||||
endif()
|
||||
set(LIBLAMMPS_SHARED_BINARY ${MY_BUILD_DIR}/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX})
|
||||
if(Python_EXECUTABLE)
|
||||
add_custom_target(
|
||||
install-python ${CMAKE_COMMAND} -E remove_directory build
|
||||
COMMAND ${Python_EXECUTABLE} ${LAMMPS_PYTHON_DIR}/install.py -p ${LAMMPS_PYTHON_DIR}/lammps -l ${LIBLAMMPS_SHARED_BINARY}
|
||||
COMMAND ${Python_EXECUTABLE} ${LAMMPS_PYTHON_DIR}/install.py -p ${LAMMPS_PYTHON_DIR}/lammps
|
||||
-l ${LIBLAMMPS_SHARED_BINARY} -w ${MY_BUILD_DIR}
|
||||
COMMENT "Installing LAMMPS Python module")
|
||||
else()
|
||||
add_custom_target(
|
||||
@ -811,16 +851,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})
|
||||
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()
|
||||
|
||||
@ -931,9 +980,6 @@ if(PKG_GPU)
|
||||
endif()
|
||||
message(STATUS "GPU precision: ${GPU_PREC}")
|
||||
endif()
|
||||
if(PKG_KOKKOS)
|
||||
message(STATUS "Kokkos Arch: ${KOKKOS_ARCH}")
|
||||
endif()
|
||||
if(PKG_KSPACE)
|
||||
message(STATUS "<<< FFT settings >>>
|
||||
-- Primary FFT lib: ${FFT}")
|
||||
|
||||
@ -1,5 +1,10 @@
|
||||
# Find clang-format
|
||||
find_program(ClangFormat_EXECUTABLE NAMES clang-format
|
||||
clang-format-15.0
|
||||
clang-format-14.0
|
||||
clang-format-13.0
|
||||
clang-format-12.0
|
||||
clang-format-11.0
|
||||
clang-format-10.0
|
||||
clang-format-9.0
|
||||
clang-format-8.0
|
||||
@ -14,19 +19,27 @@ if(ClangFormat_EXECUTABLE)
|
||||
OUTPUT_VARIABLE clang_format_version
|
||||
ERROR_QUIET OUTPUT_STRIP_TRAILING_WHITESPACE)
|
||||
|
||||
|
||||
if(clang_format_version MATCHES "^clang-format version .*")
|
||||
# Arch Linux
|
||||
if(clang_format_version MATCHES "^(Ubuntu |)clang-format version .*")
|
||||
# Arch Linux output:
|
||||
# clang-format version 10.0.0
|
||||
|
||||
# Ubuntu 18.04 LTS Output
|
||||
#
|
||||
# Ubuntu 18.04 LTS output:
|
||||
# clang-format version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
|
||||
string(REGEX REPLACE "clang-format version ([0-9.]+).*"
|
||||
"\\1"
|
||||
#
|
||||
# Ubuntu 20.04 LTS output:
|
||||
# clang-format version 10.0.0-4ubuntu1
|
||||
#
|
||||
# Ubuntu 22.04 LTS output:
|
||||
# Ubuntu clang-format version 14.0.0-1ubuntu1
|
||||
#
|
||||
# Fedora 36 output:
|
||||
# clang-format version 14.0.5 (Fedora 14.0.5-1.fc36)
|
||||
string(REGEX REPLACE "^(Ubuntu |)clang-format version ([0-9.]+).*"
|
||||
"\\2"
|
||||
ClangFormat_VERSION
|
||||
"${clang_format_version}")
|
||||
elseif(clang_format_version MATCHES ".*LLVM version .*")
|
||||
# CentOS 7 Output
|
||||
# CentOS 7 output:
|
||||
# LLVM (http://llvm.org/):
|
||||
# LLVM version 3.4.2
|
||||
# Optimized build.
|
||||
|
||||
@ -22,7 +22,7 @@ endif()
|
||||
if(Python_EXECUTABLE)
|
||||
get_filename_component(_python_path ${Python_EXECUTABLE} PATH)
|
||||
find_program(Cythonize_EXECUTABLE
|
||||
NAMES cythonize3 cythonize cythonize.bat
|
||||
NAMES cythonize-${Python_VERSION_MAJOR}.${Python_VERSION_MINOR} cythonize3 cythonize cythonize.bat
|
||||
HINTS ${_python_path})
|
||||
endif()
|
||||
|
||||
|
||||
208
cmake/Modules/LAMMPSInterfacePlugin.cmake
Normal file
208
cmake/Modules/LAMMPSInterfacePlugin.cmake
Normal file
@ -0,0 +1,208 @@
|
||||
# CMake script code to define LAMMPS settings required for building LAMMPS plugins
|
||||
|
||||
# enforce out-of-source build
|
||||
if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_BINARY_DIR})
|
||||
message(FATAL_ERROR "In-source builds are not allowed. You must create and use a build directory. "
|
||||
"Please remove CMakeCache.txt and CMakeFiles first.")
|
||||
endif()
|
||||
|
||||
set(LAMMPS_THIRDPARTY_URL "https://download.lammps.org/thirdparty"
|
||||
CACHE STRING "URL for thirdparty package downloads")
|
||||
|
||||
# global LAMMPS/plugin build settings
|
||||
set(LAMMPS_SOURCE_DIR "" CACHE PATH "Location of LAMMPS sources folder")
|
||||
if(NOT LAMMPS_SOURCE_DIR)
|
||||
message(FATAL_ERROR "Must set LAMMPS_SOURCE_DIR")
|
||||
endif()
|
||||
|
||||
# by default, install into $HOME/.local (not /usr/local),
|
||||
# so that no root access (and sudo) is needed
|
||||
if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
|
||||
set(CMAKE_INSTALL_PREFIX "$ENV{HOME}/.local" CACHE PATH "Default install path" FORCE)
|
||||
endif()
|
||||
|
||||
# ugly hacks for MSVC which by default always reports an old C++ standard in the __cplusplus macro
|
||||
# and prints lots of pointless warnings about "unsafe" functions
|
||||
if(MSVC)
|
||||
if(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
|
||||
add_compile_options(/Zc:__cplusplus)
|
||||
add_compile_options(/wd4244)
|
||||
add_compile_options(/wd4267)
|
||||
if(LAMMPS_EXCEPTIONS)
|
||||
add_compile_options(/EHsc)
|
||||
endif()
|
||||
endif()
|
||||
add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
|
||||
endif()
|
||||
|
||||
# C++11 is required
|
||||
set(CMAKE_CXX_STANDARD 11)
|
||||
set(CMAKE_CXX_STANDARD_REQUIRED ON)
|
||||
|
||||
# Need -restrict with Intel compilers
|
||||
if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
|
||||
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
|
||||
endif()
|
||||
set(CMAKE_POSITION_INDEPENDENT_CODE TRUE)
|
||||
|
||||
#######
|
||||
# helper functions from LAMMPSUtils.cmake
|
||||
function(validate_option name values)
|
||||
string(TOLOWER ${${name}} needle_lower)
|
||||
string(TOUPPER ${${name}} needle_upper)
|
||||
list(FIND ${values} ${needle_lower} IDX_LOWER)
|
||||
list(FIND ${values} ${needle_upper} IDX_UPPER)
|
||||
if(${IDX_LOWER} LESS 0 AND ${IDX_UPPER} LESS 0)
|
||||
list_to_bulletpoints(POSSIBLE_VALUE_LIST ${${values}})
|
||||
message(FATAL_ERROR "\n########################################################################\n"
|
||||
"Invalid value '${${name}}' for option ${name}\n"
|
||||
"\n"
|
||||
"Possible values are:\n"
|
||||
"${POSSIBLE_VALUE_LIST}"
|
||||
"########################################################################")
|
||||
endif()
|
||||
endfunction(validate_option)
|
||||
|
||||
# helper function for getting the most recently modified file or folder from a glob pattern
|
||||
function(get_newest_file path variable)
|
||||
file(GLOB _dirs ${path})
|
||||
set(_besttime 2000-01-01T00:00:00)
|
||||
set(_bestfile "<unknown>")
|
||||
foreach(_dir ${_dirs})
|
||||
file(TIMESTAMP ${_dir} _newtime)
|
||||
if(_newtime IS_NEWER_THAN _besttime)
|
||||
set(_bestfile ${_dir})
|
||||
set(_besttime ${_newtime})
|
||||
endif()
|
||||
endforeach()
|
||||
if(_bestfile STREQUAL "<unknown>")
|
||||
message(FATAL_ERROR "Could not find valid path at: ${path}")
|
||||
endif()
|
||||
set(${variable} ${_bestfile} PARENT_SCOPE)
|
||||
endfunction()
|
||||
|
||||
# get LAMMPS version date
|
||||
function(get_lammps_version version_header variable)
|
||||
file(STRINGS ${version_header} line REGEX LAMMPS_VERSION)
|
||||
string(REGEX REPLACE "#define LAMMPS_VERSION \"([0-9]+) ([A-Za-z]+) ([0-9]+)\"" "\\1\\2\\3" date "${line}")
|
||||
set(${variable} "${date}" PARENT_SCOPE)
|
||||
endfunction()
|
||||
|
||||
#################################################################################
|
||||
# LAMMPS C++ interface. We only need the header related parts except on windows.
|
||||
add_library(lammps INTERFACE)
|
||||
target_include_directories(lammps INTERFACE ${LAMMPS_SOURCE_DIR})
|
||||
if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
|
||||
target_link_libraries(lammps INTERFACE ${CMAKE_BINARY_DIR}/../liblammps.dll.a)
|
||||
endif()
|
||||
|
||||
################################################################################
|
||||
# MPI configuration
|
||||
if(NOT CMAKE_CROSSCOMPILING)
|
||||
set(MPI_CXX_SKIP_MPICXX TRUE)
|
||||
find_package(MPI QUIET)
|
||||
option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
|
||||
else()
|
||||
option(BUILD_MPI "Build MPI version" OFF)
|
||||
endif()
|
||||
|
||||
if(BUILD_MPI)
|
||||
# do not include the (obsolete) MPI C++ bindings which makes
|
||||
# for leaner object files and avoids namespace conflicts
|
||||
set(MPI_CXX_SKIP_MPICXX TRUE)
|
||||
# We use a non-standard procedure to cross-compile with MPI on Windows
|
||||
if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
|
||||
# Download and configure custom MPICH files for Windows
|
||||
message(STATUS "Downloading and configuring MPICH-1.4.1 for Windows")
|
||||
set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win64-devel.tar.gz" CACHE STRING "URL for MPICH2 (win64) tarball")
|
||||
set(MPICH2_WIN32_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win32-devel.tar.gz" CACHE STRING "URL for MPICH2 (win32) tarball")
|
||||
set(MPICH2_WIN64_DEVEL_MD5 "4939fdb59d13182fd5dd65211e469f14" CACHE STRING "MD5 checksum of MPICH2 (win64) tarball")
|
||||
set(MPICH2_WIN32_DEVEL_MD5 "a61d153500dce44e21b755ee7257e031" CACHE STRING "MD5 checksum of MPICH2 (win32) tarball")
|
||||
mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
|
||||
mark_as_advanced(MPICH2_WIN32_DEVEL_URL)
|
||||
mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
|
||||
mark_as_advanced(MPICH2_WIN32_DEVEL_MD5)
|
||||
|
||||
include(ExternalProject)
|
||||
if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
|
||||
ExternalProject_Add(mpi4win_build
|
||||
URL ${MPICH2_WIN64_DEVEL_URL}
|
||||
URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
|
||||
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
|
||||
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
|
||||
else()
|
||||
ExternalProject_Add(mpi4win_build
|
||||
URL ${MPICH2_WIN32_DEVEL_URL}
|
||||
URL_MD5 ${MPICH2_WIN32_DEVEL_MD5}
|
||||
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
|
||||
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
|
||||
endif()
|
||||
|
||||
ExternalProject_get_property(mpi4win_build SOURCE_DIR)
|
||||
file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
|
||||
add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
|
||||
set_target_properties(MPI::MPI_CXX PROPERTIES
|
||||
IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmpi.a"
|
||||
INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
|
||||
INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
|
||||
add_dependencies(MPI::MPI_CXX mpi4win_build)
|
||||
|
||||
# set variables for status reporting at the end of CMake run
|
||||
set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
|
||||
set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
|
||||
set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmpi.a")
|
||||
else()
|
||||
find_package(MPI REQUIRED)
|
||||
option(LAMMPS_LONGLONG_TO_LONG "Workaround if your system or MPI version does not recognize 'long long' data types" OFF)
|
||||
if(LAMMPS_LONGLONG_TO_LONG)
|
||||
target_compile_definitions(lammps INTERFACE -DLAMMPS_LONGLONG_TO_LONG)
|
||||
endif()
|
||||
endif()
|
||||
target_link_libraries(lammps INTERFACE MPI::MPI_CXX)
|
||||
else()
|
||||
add_library(mpi_stubs INTERFACE)
|
||||
target_include_directories(mpi_stubs INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
|
||||
target_link_libraries(lammps INTERFACE mpi_stubs)
|
||||
endif()
|
||||
|
||||
################################################################################
|
||||
# detect if we may enable OpenMP support by default
|
||||
set(BUILD_OMP_DEFAULT OFF)
|
||||
find_package(OpenMP QUIET)
|
||||
if(OpenMP_FOUND)
|
||||
check_include_file_cxx(omp.h HAVE_OMP_H_INCLUDE)
|
||||
if(HAVE_OMP_H_INCLUDE)
|
||||
set(BUILD_OMP_DEFAULT ON)
|
||||
endif()
|
||||
endif()
|
||||
|
||||
option(BUILD_OMP "Build with OpenMP support" ${BUILD_OMP_DEFAULT})
|
||||
|
||||
if(BUILD_OMP)
|
||||
find_package(OpenMP REQUIRED)
|
||||
check_include_file_cxx(omp.h HAVE_OMP_H_INCLUDE)
|
||||
if(NOT HAVE_OMP_H_INCLUDE)
|
||||
message(FATAL_ERROR "Cannot find the 'omp.h' header file required for full OpenMP support")
|
||||
endif()
|
||||
|
||||
if (((CMAKE_CXX_COMPILER_ID STREQUAL "GNU") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 9.0)) OR
|
||||
(CMAKE_CXX_COMPILER_ID STREQUAL "PGI") OR
|
||||
((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 10.0)) OR
|
||||
((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.0)))
|
||||
# GCC 9.x and later plus Clang 10.x and later implement strict OpenMP 4.0 semantics for consts.
|
||||
# Intel 18.0 was tested to support both, so we switch to OpenMP 4+ from 19.x onward to be safe.
|
||||
target_compile_definitions(lammps INTERFACE -DLAMMPS_OMP_COMPAT=4)
|
||||
else()
|
||||
target_compile_definitions(lammps INTERFACE -DLAMMPS_OMP_COMPAT=3)
|
||||
endif()
|
||||
target_link_libraries(lammps INTERFACE OpenMP::OpenMP_CXX)
|
||||
endif()
|
||||
|
||||
################
|
||||
# integer size selection
|
||||
set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallsmall: all 32-bit, smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
|
||||
set(LAMMPS_SIZES_VALUES smallbig bigbig smallsmall)
|
||||
set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
|
||||
validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
|
||||
string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)
|
||||
target_compile_definitions(lammps INTERFACE -DLAMMPS_${LAMMPS_SIZES})
|
||||
@ -24,6 +24,39 @@ function(validate_option name values)
|
||||
endif()
|
||||
endfunction(validate_option)
|
||||
|
||||
# helper function to check for usable omp.h header
|
||||
function(check_omp_h_include)
|
||||
find_package(OpenMP COMPONENTS CXX QUIET)
|
||||
if(OpenMP_CXX_FOUND)
|
||||
set(CMAKE_REQUIRED_FLAGS ${OpenMP_CXX_FLAGS})
|
||||
set(CMAKE_REQUIRED_INCLUDES ${OpenMP_CXX_INCLUDE_DIRS})
|
||||
set(CMAKE_REQUIRED_LINK_OPTIONS ${OpenMP_CXX_FLAGS})
|
||||
set(CMAKE_REQUIRED_LIBRARIES ${OpenMP_CXX_LIBRARIES})
|
||||
check_include_file_cxx(omp.h _have_omp_h)
|
||||
else()
|
||||
set(_have_omp_h FALSE)
|
||||
endif()
|
||||
set(HAVE_OMP_H_INCLUDE ${_have_omp_h} PARENT_SCOPE)
|
||||
endfunction()
|
||||
|
||||
# helper function for getting the most recently modified file or folder from a glob pattern
|
||||
function(get_newest_file path variable)
|
||||
file(GLOB _dirs ${path})
|
||||
set(_besttime 2000-01-01T00:00:00)
|
||||
set(_bestfile "<unknown>")
|
||||
foreach(_dir ${_dirs})
|
||||
file(TIMESTAMP ${_dir} _newtime)
|
||||
if(_newtime IS_NEWER_THAN _besttime)
|
||||
set(_bestfile ${_dir})
|
||||
set(_besttime ${_newtime})
|
||||
endif()
|
||||
endforeach()
|
||||
if(_bestfile STREQUAL "<unknown>")
|
||||
message(FATAL_ERROR "Could not find valid path at: ${path}")
|
||||
endif()
|
||||
set(${variable} ${_bestfile} PARENT_SCOPE)
|
||||
endfunction()
|
||||
|
||||
function(get_lammps_version version_header variable)
|
||||
file(STRINGS ${version_header} line REGEX LAMMPS_VERSION)
|
||||
set(MONTHS x Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec)
|
||||
@ -92,14 +125,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,6 +343,13 @@ 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")
|
||||
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}
|
||||
|
||||
@ -15,8 +15,9 @@ if(Kokkos_ENABLE_OPENMP)
|
||||
if(NOT BUILD_OMP)
|
||||
message(FATAL_ERROR "Must enable BUILD_OMP with Kokkos_ENABLE_OPENMP")
|
||||
else()
|
||||
if(LAMMPS_OMP_COMPAT_LEVEL LESS 4)
|
||||
message(FATAL_ERROR "Compiler must support OpenMP 4.0 or later with Kokkos_ENABLE_OPENMP")
|
||||
# NVHPC does not seem to provide a detectable OpenMP version, but is far beyond version 3.1
|
||||
if((OpenMP_CXX_VERSION VERSION_LESS 3.1) AND NOT (CMAKE_CXX_COMPILER_ID STREQUAL "NVHPC"))
|
||||
message(FATAL_ERROR "Compiler must support OpenMP 3.1 or later with Kokkos_ENABLE_OPENMP")
|
||||
endif()
|
||||
endif()
|
||||
endif()
|
||||
@ -47,8 +48,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.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
|
||||
set(KOKKOS_MD5 "b5c44ea961031795f434002cd7b31c20" 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 +73,7 @@ if(DOWNLOAD_KOKKOS)
|
||||
add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
|
||||
add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
|
||||
elseif(EXTERNAL_KOKKOS)
|
||||
find_package(Kokkos 3.6.00 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.3.2.tar.gz" CACHE STRING "URL for MDI tarball")
|
||||
set(MDI_MD5 "836f5da400d8cff0f0e4435640f9454f" 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}
|
||||
CMAKE_ARGS ${CMAKE_REQUEST_PIC}
|
||||
-DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
|
||||
PREFIX ${CMAKE_CURRENT_BINARY_DIR}/mdi_build_ext
|
||||
CMAKE_ARGS
|
||||
-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}
|
||||
@ -54,24 +76,25 @@ if(DOWNLOAD_MDI)
|
||||
-Dlanguage=C
|
||||
-Dlibtype=STATIC
|
||||
-Dmpi=${MDI_USE_MPI}
|
||||
-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 "")
|
||||
|
||||
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()
|
||||
@ -44,7 +44,9 @@ if(DOWNLOAD_N2P2)
|
||||
else()
|
||||
# get path to MPI include directory
|
||||
get_target_property(N2P2_MPI_INCLUDE MPI::MPI_CXX INTERFACE_INCLUDE_DIRECTORIES)
|
||||
set(N2P2_PROJECT_OPTIONS "-I${N2P2_MPI_INCLUDE}")
|
||||
foreach (_INCL ${N2P2_MPI_INCLUDE})
|
||||
set(N2P2_PROJECT_OPTIONS "${N2P2_PROJECT_OPTIONS} -I${_INCL}")
|
||||
endforeach()
|
||||
endif()
|
||||
|
||||
# prefer GNU make, if available. N2P2 lib seems to need it.
|
||||
@ -75,7 +77,7 @@ if(DOWNLOAD_N2P2)
|
||||
UPDATE_COMMAND ""
|
||||
CONFIGURE_COMMAND ""
|
||||
PATCH_COMMAND sed -i -e "s/\\(MPI_\\(P\\|Unp\\)ack(\\)/\\1(void *) /" src/libnnpif/LAMMPS/InterfaceLammps.cpp
|
||||
BUILD_COMMAND ${N2P2_MAKE} -f makefile libnnpif ${N2P2_BUILD_OPTIONS}
|
||||
BUILD_COMMAND ${N2P2_MAKE} -C <SOURCE_DIR>/src -f makefile libnnpif ${N2P2_BUILD_OPTIONS}
|
||||
BUILD_ALWAYS YES
|
||||
INSTALL_COMMAND ""
|
||||
BUILD_IN_SOURCE 1
|
||||
|
||||
@ -2,7 +2,13 @@
|
||||
set(MLIAP_ENABLE_PYTHON_DEFAULT OFF)
|
||||
if(PKG_PYTHON)
|
||||
find_package(Cythonize QUIET)
|
||||
if(Cythonize_FOUND)
|
||||
if (CMAKE_VERSION VERSION_GREATER_EQUAL 3.14)
|
||||
find_package(Python COMPONENTS NumPy QUIET)
|
||||
else()
|
||||
# assume we have NumPy
|
||||
set(Python_NumPy_FOUND ON)
|
||||
endif()
|
||||
if(Cythonize_FOUND AND Python_NumPy_FOUND)
|
||||
set(MLIAP_ENABLE_PYTHON_DEFAULT ON)
|
||||
endif()
|
||||
endif()
|
||||
@ -11,6 +17,9 @@ option(MLIAP_ENABLE_PYTHON "Build ML-IAP package with Python support" ${MLIAP_EN
|
||||
|
||||
if(MLIAP_ENABLE_PYTHON)
|
||||
find_package(Cythonize REQUIRED)
|
||||
if (CMAKE_VERSION VERSION_GREATER_EQUAL 3.14)
|
||||
find_package(Python COMPONENTS NumPy REQUIRED)
|
||||
endif()
|
||||
if(NOT PKG_PYTHON)
|
||||
message(FATAL_ERROR "Must enable PYTHON package for including Python support in ML-IAP")
|
||||
endif()
|
||||
@ -25,16 +34,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})
|
||||
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_SRC} ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.pyx
|
||||
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_SRC}
|
||||
MAIN_DEPENDENCY ${MLIAP_CYTHON_FILE}
|
||||
COMMENT "Generating C++ sources with cythonize...")
|
||||
target_compile_definitions(lammps PRIVATE -DMLIAP_PYTHON)
|
||||
target_sources(lammps PRIVATE ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.cpp)
|
||||
endforeach()
|
||||
target_compile_definitions(lammps PRIVATE -DMLIAP_PYTHON)
|
||||
target_include_directories(lammps PRIVATE ${MLIAP_BINARY_DIR})
|
||||
endif()
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2021.10.25.fix.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
|
||||
set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2022.10.15.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
|
||||
|
||||
set(PACELIB_MD5 "e0572de57039d4afedefb25707b6ceae" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
|
||||
set(PACELIB_MD5 "848ad6a6cc79fa82745927001fb1c9b5" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
|
||||
mark_as_advanced(PACELIB_URL)
|
||||
mark_as_advanced(PACELIB_MD5)
|
||||
|
||||
@ -13,24 +13,11 @@ execute_process(
|
||||
COMMAND ${CMAKE_COMMAND} -E tar xzf libpace.tar.gz
|
||||
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
|
||||
)
|
||||
get_newest_file(${CMAKE_BINARY_DIR}/lammps-user-pace-* lib-pace)
|
||||
|
||||
file(GLOB lib-pace ${CMAKE_BINARY_DIR}/lammps-user-pace-*)
|
||||
# enforce building libyaml-cpp as static library and turn off optional features
|
||||
set(YAML_BUILD_SHARED_LIBS OFF)
|
||||
set(YAML_CPP_BUILD_CONTRIB OFF)
|
||||
set(YAML_CPP_BUILD_TOOLS OFF)
|
||||
add_subdirectory(${lib-pace}/yaml-cpp build-yaml-cpp)
|
||||
set(YAML_CPP_INCLUDE_DIR ${lib-pace}/yaml-cpp/include)
|
||||
|
||||
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})
|
||||
add_subdirectory(${lib-pace} build-pace)
|
||||
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})
|
||||
|
||||
|
||||
target_link_libraries(pace PRIVATE yaml-cpp-pace)
|
||||
|
||||
if(CMAKE_PROJECT_NAME STREQUAL "lammps")
|
||||
target_link_libraries(lammps PRIVATE pace)
|
||||
endif()
|
||||
|
||||
@ -43,6 +43,7 @@ if(DOWNLOAD_QUIP)
|
||||
file(WRITE ${CMAKE_BINARY_DIR}/quip.config "${temp}")
|
||||
|
||||
message(STATUS "QUIP download via git requested - we will build our own")
|
||||
set(CMAKE_EP_GIT_REMOTE_UPDATE_STRATEGY CHECKOUT)
|
||||
# QUIP has no releases (except for a tag marking the end of Python 2 support). We use the current "public" branch
|
||||
# The LAMMPS interface wrapper has a compatibility constant that is being checked at runtime.
|
||||
include(ExternalProject)
|
||||
|
||||
@ -47,15 +47,15 @@ if(DOWNLOAD_PLUMED)
|
||||
endif()
|
||||
message(STATUS "PLUMED download requested - we will build our own")
|
||||
if(PLUMED_MODE STREQUAL "STATIC")
|
||||
set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumed.a")
|
||||
set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumed${CMAKE_STATIC_LIBRARY_SUFFIX}")
|
||||
elseif(PLUMED_MODE STREQUAL "SHARED")
|
||||
set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumed${CMAKE_SHARED_LIBRARY_SUFFIX};<INSTALL_DIR>/lib/libplumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
|
||||
set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumed${CMAKE_SHARED_LIBRARY_SUFFIX};<INSTALL_DIR>/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
|
||||
elseif(PLUMED_MODE STREQUAL "RUNTIME")
|
||||
set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumedWrapper.a")
|
||||
set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumedWrapper${CMAKE_STATIC_LIBRARY_PREFIX}")
|
||||
endif()
|
||||
|
||||
set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.7.4/plumed-src-2.7.4.tgz" CACHE STRING "URL for PLUMED tarball")
|
||||
set(PLUMED_MD5 "858e0b6aed173748fc85b6bc8a9dcb3e" CACHE STRING "MD5 checksum of PLUMED tarball")
|
||||
set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.8.1/plumed-src-2.8.1.tgz" CACHE STRING "URL for PLUMED tarball")
|
||||
set(PLUMED_MD5 "6bfe72ebdae63dc38a9ca27d9b0e08f8" CACHE STRING "MD5 checksum of PLUMED tarball")
|
||||
|
||||
mark_as_advanced(PLUMED_URL)
|
||||
mark_as_advanced(PLUMED_MD5)
|
||||
@ -78,12 +78,12 @@ if(DOWNLOAD_PLUMED)
|
||||
add_library(LAMMPS::PLUMED UNKNOWN IMPORTED)
|
||||
add_dependencies(LAMMPS::PLUMED plumed_build)
|
||||
if(PLUMED_MODE STREQUAL "STATIC")
|
||||
set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/libplumed.a INTERFACE_LINK_LIBRARIES "${PLUMED_LINK_LIBS};${CMAKE_DL_LIBS}")
|
||||
set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumed${CMAKE_STATIC_LIBRARY_SUFFIX} INTERFACE_LINK_LIBRARIES "${PLUMED_LINK_LIBS};${CMAKE_DL_LIBS}")
|
||||
elseif(PLUMED_MODE STREQUAL "SHARED")
|
||||
set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/libplumed${CMAKE_SHARED_LIBRARY_SUFFIX} INTERFACE_LINK_LIBRARIES "${INSTALL_DIR}/lib/libplumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX};${CMAKE_DL_LIBS}")
|
||||
set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumed${CMAKE_SHARED_LIBRARY_SUFFIX} INTERFACE_LINK_LIBRARIES "${INSTALL_DIR}/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX};${CMAKE_DL_LIBS}")
|
||||
elseif(PLUMED_MODE STREQUAL "RUNTIME")
|
||||
set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${INSTALL_DIR}/lib/libplumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
|
||||
set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/libplumedWrapper.a INTERFACE_LINK_LIBRARIES "${CMAKE_DL_LIBS}")
|
||||
set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${INSTALL_DIR}/lib/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
|
||||
set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumedWrapper${CMAKE_STATIC_LIBRARY_SUFFIX} INTERFACE_LINK_LIBRARIES "${CMAKE_DL_LIBS}")
|
||||
endif()
|
||||
set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_INCLUDE_DIRECTORIES ${INSTALL_DIR}/include)
|
||||
file(MAKE_DIRECTORY ${INSTALL_DIR}/include)
|
||||
@ -96,7 +96,7 @@ else()
|
||||
elseif(PLUMED_MODE STREQUAL "SHARED")
|
||||
include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.shared)
|
||||
elseif(PLUMED_MODE STREQUAL "RUNTIME")
|
||||
set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${PLUMED_LIBDIR}/libplumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
|
||||
set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${PLUMED_LIBDIR}/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
|
||||
include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.runtime)
|
||||
endif()
|
||||
set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_LINK_LIBRARIES "${PLUMED_LOAD}")
|
||||
|
||||
@ -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()
|
||||
|
||||
@ -1,4 +1,9 @@
|
||||
find_package(VTK REQUIRED NO_MODULE)
|
||||
include(${VTK_USE_FILE})
|
||||
target_compile_definitions(lammps PRIVATE -DLAMMPS_VTK)
|
||||
if (VTK_MAJOR_VERSION VERSION_LESS 9.0)
|
||||
include(${VTK_USE_FILE})
|
||||
target_link_libraries(lammps PRIVATE ${VTK_LIBRARIES})
|
||||
else()
|
||||
target_link_libraries(lammps PRIVATE VTK::CommonCore VTK::IOCore VTK::CommonDataModel VTK::IOXML VTK::IOLegacy VTK::IOParallelXML)
|
||||
vtk_module_autoinit(TARGETS lammps MODULES VTK::CommonCore VTK::IOCore VTK::CommonDataModel VTK::IOXML VTK::IOLegacy VTK::IOParallelXML)
|
||||
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)
|
||||
@ -21,10 +28,3 @@ set(MPI_CXX "clang++" CACHE STRING "" FORCE)
|
||||
set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
|
||||
|
||||
unset(HAVE_OMP_H_INCLUDE CACHE)
|
||||
set(OpenMP_C "clang" CACHE STRING "" FORCE)
|
||||
set(OpenMP_C_FLAGS "-fopenmp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX "clang++" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX_FLAGS "-fopenmp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_omp_LIBRARY "libomp.so" CACHE PATH "" FORCE)
|
||||
|
||||
@ -19,11 +19,3 @@ set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -Og -g -std=f2003" CACHE STRING "" FORCE)
|
||||
set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-g -O2 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
|
||||
set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
|
||||
unset(HAVE_OMP_H_INCLUDE CACHE)
|
||||
|
||||
set(OpenMP_C "gcc" CACHE STRING "" FORCE)
|
||||
set(OpenMP_C_FLAGS "-fopenmp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_C_LIB_NAMES "gomp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX "g++" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX_FLAGS "-fopenmp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX_LIB_NAMES "gomp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_omp_LIBRARY "libgomp.so" CACHE PATH "" 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
|
||||
@ -46,8 +47,8 @@ set(WIN_PACKAGES
|
||||
MISC
|
||||
ML-HDNNP
|
||||
ML-IAP
|
||||
ML-SNAP
|
||||
ML-RANN
|
||||
ML-SNAP
|
||||
MOFFF
|
||||
MOLECULE
|
||||
MOLFILE
|
||||
@ -56,6 +57,7 @@ set(WIN_PACKAGES
|
||||
ORIENT
|
||||
PERI
|
||||
PHONON
|
||||
PLUGIN
|
||||
POEMS
|
||||
PTM
|
||||
QEQ
|
||||
|
||||
@ -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
|
||||
|
||||
9
cmake/presets/nvhpc.cmake
Normal file
9
cmake/presets/nvhpc.cmake
Normal file
@ -0,0 +1,9 @@
|
||||
# preset that will enable Nvidia HPC SDK compilers with support for MPI and OpenMP (on Linux boxes)
|
||||
|
||||
set(CMAKE_CXX_COMPILER "nvc++" CACHE STRING "" FORCE)
|
||||
set(CMAKE_C_COMPILER "nvc" CACHE STRING "" FORCE)
|
||||
set(CMAKE_Fortran_COMPILER "nvfortran" CACHE STRING "" FORCE)
|
||||
set(MPI_CXX "nvc++" CACHE STRING "" FORCE)
|
||||
set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
|
||||
unset(HAVE_OMP_H_INCLUDE CACHE)
|
||||
|
||||
@ -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,4 +1,4 @@
|
||||
# preset that will restore gcc/g++ with support for MPI and OpenMP (on Linux boxes)
|
||||
# preset that will set gcc/g++ with extra warnings enabled and support for MPI and OpenMP (on Linux boxes)
|
||||
|
||||
set(CMAKE_CXX_COMPILER "g++" CACHE STRING "" FORCE)
|
||||
set(CMAKE_C_COMPILER "gcc" CACHE STRING "" FORCE)
|
||||
@ -17,10 +17,3 @@ set(MPI_Fortran "gfortran" CACHE STRING "" FORCE)
|
||||
set(MPI_Fortran_COMPILER "mpifort" CACHE STRING "" FORCE)
|
||||
unset(HAVE_OMP_H_INCLUDE CACHE)
|
||||
|
||||
set(OpenMP_C "gcc" CACHE STRING "" FORCE)
|
||||
set(OpenMP_C_FLAGS "-fopenmp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_C_LIB_NAMES "gomp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX "g++" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX_FLAGS "-fopenmp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX_LIB_NAMES "gomp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_omp_LIBRARY "libgomp.so" CACHE PATH "" FORCE)
|
||||
|
||||
@ -7,10 +7,3 @@ set(MPI_CXX "pgc++" CACHE STRING "" FORCE)
|
||||
set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
|
||||
unset(HAVE_OMP_H_INCLUDE CACHE)
|
||||
|
||||
set(OpenMP_C "pgcc" CACHE STRING "" FORCE)
|
||||
set(OpenMP_C_FLAGS "-mp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX "pgc++" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX_FLAGS "-mp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
|
||||
set(OpenMP_omp_LIBRARY "libomp.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
|
||||
|
||||
21
doc/Makefile
21
doc/Makefile
@ -13,7 +13,7 @@ VENV = $(BUILDDIR)/docenv
|
||||
ANCHORCHECK = $(VENV)/bin/rst_anchor_check
|
||||
SPHINXCONFIG = $(BUILDDIR)/utils/sphinx-config
|
||||
MATHJAX = $(SPHINXCONFIG)/_static/mathjax
|
||||
MATHJAXTAG = 3.2.1
|
||||
MATHJAXTAG = 3.2.2
|
||||
|
||||
PYTHON = $(word 3,$(shell type python3))
|
||||
DOXYGEN = $(word 3,$(shell type doxygen))
|
||||
@ -38,16 +38,14 @@ endif
|
||||
# override settings for PIP commands
|
||||
# PIP_OPTIONS = --cert /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt --proxy http://proxy.mydomain.org
|
||||
|
||||
#SPHINXEXTRA = -j $(shell $(PYTHON) -c 'import multiprocessing;print(multiprocessing.cpu_count())') $(shell test -f $(BUILDDIR)/doxygen/xml/run.stamp && printf -- "-E")
|
||||
|
||||
# temporarily disable caching so that the hack for the sphinx-tabs extensions to get proper non-html output works
|
||||
SPHINXEXTRA = -E -j $(shell $(PYTHON) -c 'import multiprocessing;print(multiprocessing.cpu_count())')
|
||||
SPHINXEXTRA = -j $(shell $(PYTHON) -c 'import multiprocessing;print(multiprocessing.cpu_count())')
|
||||
|
||||
# grab list of sources from doxygen config file.
|
||||
# we only want to use explicitly listed files.
|
||||
DOXYFILES = $(shell sed -n -e 's/\#.*$$//' -e '/^ *INPUT \+=/,/^[A-Z_]\+ \+=/p' doxygen/Doxyfile.in | sed -e 's/@LAMMPS_SOURCE_DIR@/..\/src/g' -e 's/\\//g' -e 's/ \+/ /' -e 's/[A-Z_]\+ \+= *\(YES\|NO\|\)//')
|
||||
|
||||
.PHONY: help clean-all clean clean-spelling epub mobi rst html pdf spelling anchor_check style_check char_check xmlgen fasthtml
|
||||
.PHONY: help clean-all clean clean-spelling epub mobi html pdf spelling anchor_check style_check char_check xmlgen fasthtml
|
||||
|
||||
# ------------------------------------------
|
||||
|
||||
@ -89,6 +87,8 @@ html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
|
||||
@$(MAKE) $(MFLAGS) -C graphviz all
|
||||
@(\
|
||||
. $(VENV)/bin/activate ; env PYTHONWARNINGS= \
|
||||
sphinx-build -E $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
|
||||
touch $(RSTDIR)/Fortran.rst ;\
|
||||
sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
|
||||
ln -sf Manual.html html/index.html;\
|
||||
rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
|
||||
@ -114,7 +114,9 @@ fasthtml: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
|
||||
@mkdir -p fasthtml
|
||||
@(\
|
||||
. $(VENV)/bin/activate ; env PYTHONWARNINGS= \
|
||||
sphinx-build -j 4 -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/fasthtml/doctrees $(RSTDIR) fasthtml ;\
|
||||
sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/fasthtml/doctrees $(RSTDIR) fasthtml ;\
|
||||
touch $(RSTDIR)/Fortran.rst ;\
|
||||
sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/fasthtml/doctrees $(RSTDIR) fasthtml ;\
|
||||
deactivate ;\
|
||||
)
|
||||
@rm -rf fasthtml/_sources
|
||||
@ -144,6 +146,8 @@ epub: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
|
||||
@cp src/JPG/*.* epub/JPG
|
||||
@(\
|
||||
. $(VENV)/bin/activate ;\
|
||||
sphinx-build -E $(SPHINXEXTRA) -b epub -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
|
||||
touch $(RSTDIR)/Fortran.rst ;\
|
||||
sphinx-build $(SPHINXEXTRA) -b epub -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
|
||||
rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
|
||||
deactivate ;\
|
||||
@ -163,6 +167,8 @@ pdf: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
|
||||
@if [ "$(HAS_PDFLATEX)" == "NO" ] ; then echo "PDFLaTeX or latexmk were not found! Please check README for further instructions" 1>&2; exit 1; fi
|
||||
@(\
|
||||
. $(VENV)/bin/activate ; env PYTHONWARNINGS= \
|
||||
sphinx-build -E $(SPHINXEXTRA) -b latex -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) latex ;\
|
||||
touch $(RSTDIR)/Fortran.rst ;\
|
||||
sphinx-build $(SPHINXEXTRA) -b latex -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) latex ;\
|
||||
rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
|
||||
echo "############################################" ;\
|
||||
@ -242,7 +248,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" "4 May 2022" "2022-5-4"
|
||||
.TH LAMMPS "1" "15 September 2022" "2022-9-15"
|
||||
.SH NAME
|
||||
.B LAMMPS
|
||||
\- Molecular Dynamics Simulator. Version 24 March 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
|
||||
|
||||
@ -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.
|
||||
@ -407,7 +407,7 @@ Bibliography
|
||||
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).
|
||||
@ -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,13 +140,23 @@ 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
|
||||
`Googletest <https://github.com/google/googletest/>`_ C++ test framework
|
||||
for implementing the tests.
|
||||
|
||||
.. admonition:: Software version requirements for testing
|
||||
:class: note
|
||||
|
||||
The compiler and library version requirements for the testing
|
||||
framework are more strict than for the main part of LAMMPS. For
|
||||
example the default GNU C++ and Fortran compilers of RHEL/CentOS 7.x
|
||||
(version 4.8.x) are not sufficient. The CMake configuration will try
|
||||
to detect compatible versions and either skip incompatible tests or
|
||||
stop with an error.
|
||||
|
||||
After compilation is complete, the unit testing is started in the build
|
||||
folder using the ``ctest`` command, which is part of the CMake software.
|
||||
The output of this command will be looking something like this::
|
||||
|
||||
@ -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
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -215,7 +234,7 @@ LAMMPS code. This also applies to the ``-DLAMMPS_BIGBIG``\ ,
|
||||
Makefile you use.
|
||||
|
||||
You can also build the library in one step from the ``lammps/src`` dir,
|
||||
using a command like these, which simply invoke the ``lib/gpu/Install.py``
|
||||
using a command like these, which simply invokes the ``lib/gpu/Install.py``
|
||||
script with the specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
@ -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
|
||||
|
||||
@ -331,7 +350,7 @@ minutes to hours) to build. Of course you only need to do that once.)
|
||||
You can download and build the KIM library manually if you prefer;
|
||||
follow the instructions in ``lib/kim/README``. You can also do
|
||||
this in one step from the lammps/src directory, using a command like
|
||||
these, which simply invoke the ``lib/kim/Install.py`` script with
|
||||
these, which simply invokes the ``lib/kim/Install.py`` script with
|
||||
the specified args.
|
||||
|
||||
.. code-block:: bash
|
||||
@ -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::
|
||||
|
||||
@ -790,6 +830,8 @@ library.
|
||||
|
||||
-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
|
||||
@ -905,7 +954,7 @@ more details.
|
||||
You can download and build the MS-CG library manually if you
|
||||
prefer; follow the instructions in ``lib/mscg/README``\ . You can
|
||||
also do it in one step from the ``lammps/src`` dir, using a
|
||||
command like these, which simply invoke the
|
||||
command like these, which simply invokes the
|
||||
``lib/mscg/Install.py`` script with the specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
@ -962,7 +1011,7 @@ POEMS package
|
||||
``lib/poems``\ . You can do this manually if you prefer; follow
|
||||
the instructions in ``lib/poems/README``\ . You can also do it in
|
||||
one step from the ``lammps/src`` dir, using a command like these,
|
||||
which simply invoke the ``lib/poems/Install.py`` script with the
|
||||
which simply invokes the ``lib/poems/Install.py`` script with the
|
||||
specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
@ -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::
|
||||
@ -1051,7 +1100,7 @@ binary package provided by your operating system.
|
||||
You can download and build the Voro++ library manually if you
|
||||
prefer; follow the instructions in ``lib/voronoi/README``. You
|
||||
can also do it in one step from the ``lammps/src`` dir, using a
|
||||
command like these, which simply invoke the
|
||||
command like these, which simply invokes the
|
||||
``lib/voronoi/Install.py`` script with the specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
@ -1130,7 +1179,7 @@ The ATC package requires the MANYBODY package also be installed.
|
||||
``lib/atc``. You can do this manually if you prefer; follow the
|
||||
instructions in ``lib/atc/README``. You can also do it in one
|
||||
step from the ``lammps/src`` dir, using a command like these,
|
||||
which simply invoke the ``lib/atc/Install.py`` script with the
|
||||
which simply invokes the ``lib/atc/Install.py`` script with the
|
||||
specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
@ -1181,7 +1230,7 @@ AWPMD package
|
||||
``lib/awpmd``. You can do this manually if you prefer; follow the
|
||||
instructions in ``lib/awpmd/README``. You can also do it in one
|
||||
step from the ``lammps/src`` dir, using a command like these,
|
||||
which simply invoke the ``lib/awpmd/Install.py`` script with the
|
||||
which simply invokes the ``lib/awpmd/Install.py`` script with the
|
||||
specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
@ -1244,7 +1293,7 @@ be built for the most part with all major versions of the C++ language.
|
||||
|
||||
In general, it is safer to use build setting consistent with the
|
||||
rest of LAMMPS. This is best carried out from the LAMMPS src
|
||||
directory using a command like these, which simply invoke the
|
||||
directory using a command like these, which simply invokes the
|
||||
``lib/colvars/Install.py`` script with the specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
@ -1285,20 +1334,30 @@ This package depends on the KSPACE package.
|
||||
|
||||
.. tab:: CMake build
|
||||
|
||||
No additional settings are needed besides ``-D PKG_KSPACE=yes`` and ``-D
|
||||
PKG_ELECTRODE=yes``.
|
||||
No additional settings are needed besides ``-D PKG_KSPACE=yes`` and
|
||||
``-D PKG_ELECTRODE=yes``.
|
||||
|
||||
.. tab:: Traditional make
|
||||
|
||||
The package is activated with ``make yes-KSPACE`` and ``make
|
||||
yes-ELECTRODE``
|
||||
Before building LAMMPS, you must configure the ELECTRODE support
|
||||
libraries and settings in ``lib/electrode``. You can do this
|
||||
manually, if you prefer, or do it in one step from the
|
||||
``lammps/src`` dir, using a command like these, which simply
|
||||
invokes the ``lib/electrode/Install.py`` script with the specified
|
||||
args:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ make lib-electrode # print help message
|
||||
$ make lib-electrode args="-m serial" # build with GNU g++ compiler and MPI STUBS (settings as with "make serial")
|
||||
$ make lib-electrode args="-m mpi" # build with default MPI compiler (settings as with "make mpi")
|
||||
|
||||
|
||||
Note that the ``Makefile.lammps`` file has settings for the BLAS and
|
||||
LAPACK linear algebra libraries. As explained in ``lib/awpmd/README``
|
||||
these can either exist on your system, or you can use the files provided
|
||||
in ``lib/linalg``. In the latter case you also need to build the library
|
||||
in ``lib/linalg`` with a command like these:
|
||||
Note that the ``Makefile.lammps`` file has settings for the BLAS
|
||||
and LAPACK linear algebra libraries. These can either exist on
|
||||
your system, or you can use the files provided in ``lib/linalg``.
|
||||
In the latter case you also need to build the library in
|
||||
``lib/linalg`` with a command like these:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -1307,6 +1366,9 @@ This package depends on the KSPACE package.
|
||||
$ make lib-linalg args="-m mpi" # build with default MPI Fortran compiler (settings as with "make mpi")
|
||||
$ make lib-linalg args="-m gfortran" # build with GNU Fortran compiler
|
||||
|
||||
The package itself is activated with ``make yes-KSPACE`` and
|
||||
``make yes-ELECTRODE``
|
||||
|
||||
----------
|
||||
|
||||
.. _ml-pace:
|
||||
@ -1506,7 +1568,7 @@ the HDF5 library.
|
||||
``lib/h5md``. You can do this manually if you prefer; follow the
|
||||
instructions in ``lib/h5md/README``. You can also do it in one
|
||||
step from the ``lammps/src`` dir, using a command like these,
|
||||
which simply invoke the ``lib/h5md/Install.py`` script with the
|
||||
which simply invokes the ``lib/h5md/Install.py`` script with the
|
||||
specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
@ -1562,7 +1624,7 @@ details please see ``lib/hdnnp/README`` and the `n2p2 build documentation
|
||||
You can download and build the *n2p2* library manually if you prefer;
|
||||
follow the instructions in ``lib/hdnnp/README``\ . You can also do it in
|
||||
one step from the ``lammps/src`` dir, using a command like these, which
|
||||
simply invoke the ``lib/hdnnp/Install.py`` script with the specified args:
|
||||
simply invokes the ``lib/hdnnp/Install.py`` script with the specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -1699,7 +1761,7 @@ they will be downloaded the first time this package is installed.
|
||||
Before building LAMMPS, you must build the *mesont* library in
|
||||
``lib/mesont``\ . You can also do it in one step from the
|
||||
``lammps/src`` dir, using a command like these, which simply
|
||||
invoke the ``lib/mesont/Install.py`` script with the specified
|
||||
invokes the ``lib/mesont/Install.py`` script with the specified
|
||||
args:
|
||||
|
||||
.. code-block:: bash
|
||||
@ -1868,7 +1930,7 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to
|
||||
``lib/qmmm``. You can do this manually if you prefer; follow the
|
||||
first two steps explained in ``lib/qmmm/README``. You can also do
|
||||
it in one step from the ``lammps/src`` dir, using a command like
|
||||
these, which simply invoke the ``lib/qmmm/Install.py`` script with
|
||||
these, which simply invokes the ``lib/qmmm/Install.py`` script with
|
||||
the specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
@ -1913,14 +1975,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 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
|
||||
|
||||
@ -1965,7 +2038,7 @@ To build with this package, you must download and build the
|
||||
You can download and build the ScaFaCoS library manually if you
|
||||
prefer; follow the instructions in ``lib/scafacos/README``. You
|
||||
can also do it in one step from the ``lammps/src`` dir, using a
|
||||
command like these, which simply invoke the
|
||||
command like these, which simply invokes the
|
||||
``lib/scafacos/Install.py`` script with the specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
@ -2009,7 +2082,7 @@ Eigen3 is a template library, so you do not need to build it.
|
||||
You can download the Eigen3 library manually if you prefer; follow
|
||||
the instructions in ``lib/smd/README``. You can also do it in one
|
||||
step from the ``lammps/src`` dir, using a command like these,
|
||||
which simply invoke the ``lib/smd/Install.py`` script with the
|
||||
which simply invokes the ``lib/smd/Install.py`` script with the
|
||||
specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -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
|
||||
================
|
||||
@ -138,6 +139,8 @@ KOKKOS, o = OPENMP, t = OPT.
|
||||
* :doc:`smd/vol <compute_smd_vol>`
|
||||
* :doc:`snap <compute_sna_atom>`
|
||||
* :doc:`sna/atom <compute_sna_atom>`
|
||||
* :doc:`sna/grid <compute_sna_atom>`
|
||||
* :doc:`sna/grid/local <compute_sna_atom>`
|
||||
* :doc:`snad/atom <compute_sna_atom>`
|
||||
* :doc:`snav/atom <compute_sna_atom>`
|
||||
* :doc:`sph/e/atom <compute_sph_e_atom>`
|
||||
|
||||
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>`
|
||||
@ -103,7 +106,7 @@ OPT.
|
||||
* :doc:`lb/viscous <fix_lb_viscous>`
|
||||
* :doc:`lineforce <fix_lineforce>`
|
||||
* :doc:`manifoldforce <fix_manifoldforce>`
|
||||
* :doc:`mdi/aimd <fix_mdi_aimd>`
|
||||
* :doc:`mdi/qm <fix_mdi_qm>`
|
||||
* :doc:`meso/move <fix_meso_move>`
|
||||
* :doc:`mol/swap <fix_mol_swap>`
|
||||
* :doc:`momentum (k) <fix_momentum>`
|
||||
@ -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>`
|
||||
@ -194,10 +197,11 @@ OPT.
|
||||
* :doc:`lubricateU/poly <pair_lubricateU>`
|
||||
* :doc:`mdpd <pair_mesodpd>`
|
||||
* :doc:`mdpd/rhosum <pair_mesodpd>`
|
||||
* :doc:`meam <pair_meam>`
|
||||
* :doc:`meam (k) <pair_meam>`
|
||||
* :doc:`meam/spline (o) <pair_meam_spline>`
|
||||
* :doc:`meam/sw/spline <pair_meam_sw_spline>`
|
||||
* :doc:`mesocnt <pair_mesocnt>`
|
||||
* :doc:`mesocnt/viscous <pair_mesocnt>`
|
||||
* :doc:`mesont/tpm <pair_mesont_tpm>`
|
||||
* :doc:`mgpt <pair_mgpt>`
|
||||
* :doc:`mie/cut (g) <pair_mie>`
|
||||
@ -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,7 +273,9 @@ OPT.
|
||||
* :doc:`spin/magelec <pair_spin_magelec>`
|
||||
* :doc:`spin/neel <pair_spin_neel>`
|
||||
* :doc:`srp <pair_srp>`
|
||||
* :doc:`srp/react <pair_srp>`
|
||||
* :doc:`sw (giko) <pair_sw>`
|
||||
* :doc:`sw/angle/table <pair_sw_angle_table>`
|
||||
* :doc:`sw/mod (o) <pair_sw>`
|
||||
* :doc:`table (gko) <pair_table>`
|
||||
* :doc:`table/rx (k) <pair_table_rx>`
|
||||
@ -279,6 +286,7 @@ OPT.
|
||||
* :doc:`tersoff/table (o) <pair_tersoff>`
|
||||
* :doc:`tersoff/zbl (gko) <pair_tersoff_zbl>`
|
||||
* :doc:`thole <pair_thole>`
|
||||
* :doc:`threebody/table <pair_threebody_table>`
|
||||
* :doc:`tip4p/cut (o) <pair_coul>`
|
||||
* :doc:`tip4p/long (o) <pair_coul>`
|
||||
* :doc:`tip4p/long/soft (o) <pair_fep_soft>`
|
||||
@ -287,6 +295,7 @@ OPT.
|
||||
* :doc:`vashishta (gko) <pair_vashishta>`
|
||||
* :doc:`vashishta/table (o) <pair_vashishta>`
|
||||
* :doc:`wf/cut <pair_wf_cut>`
|
||||
* :doc:`ylz <pair_ylz>`
|
||||
* :doc:`yukawa (gko) <pair_yukawa>`
|
||||
* :doc:`yukawa/colloid (go) <pair_yukawa_colloid>`
|
||||
* :doc:`zbl (gko) <pair_zbl>`
|
||||
|
||||
@ -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
|
||||
|
||||
@ -276,10 +276,27 @@ Compilation of the plugin can be managed via both, CMake or traditional
|
||||
GNU makefiles. Some examples that can be used as a template are in the
|
||||
``examples/plugins`` folder. The CMake script code has some small
|
||||
adjustments to allow building the plugins for running unit tests with
|
||||
them. Another example that converts the KIM package into a plugin can be
|
||||
found in the ``examples/kim/plugin`` folder. No changes to the sources
|
||||
of the KIM package themselves are needed; only the plugin interface and
|
||||
loader code needs to be added. This example only supports building with
|
||||
CMake, but is probably a more typical example. To compile you need to
|
||||
run CMake with -DLAMMPS_SOURCE_DIR=<path/to/lammps/src/folder>. Other
|
||||
them.
|
||||
|
||||
Another example that converts the KIM package into a plugin can be found
|
||||
in the ``examples/kim/plugin`` folder. No changes to the sources of the
|
||||
KIM package themselves are needed; only the plugin interface and loader
|
||||
code needs to be added. This example only supports building with CMake,
|
||||
but is probably a more typical example. To compile you need to run CMake
|
||||
with -DLAMMPS_SOURCE_DIR=<path/to/lammps/src/folder>. Other
|
||||
configuration setting are identical to those for compiling LAMMPS.
|
||||
|
||||
A second example for a plugin from a package is in the
|
||||
``examples/PACKAGES/pace/plugin`` folder that will create a plugin from
|
||||
the ML-PACE package. In this case the bulk of the code is in a static
|
||||
external library that is being downloaded and compiled first and then
|
||||
combined with the pair style wrapper and the plugin loader. This
|
||||
example also contains a NSIS script that can be used to create an
|
||||
Installer package for Windows (the mutual licensing terms of the
|
||||
external library and LAMMPS conflict when distributing binaries, so the
|
||||
ML-PACE package cannot be linked statically, but the LAMMPS headers
|
||||
required to build the plugin are also available under a less restrictive
|
||||
license). This will automatically set the required environment variable
|
||||
and launching a (compatible) LAMMPS binary will load and register the
|
||||
plugin and the ML-PACE package can then be used as it was linked into
|
||||
LAMMPS.
|
||||
|
||||
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 developers@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.
|
||||
|
||||
@ -212,6 +204,14 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
|
||||
about changes they made at the same time step and thus it may result
|
||||
in unexpected behavior.
|
||||
|
||||
*Fix bond/react: Atom affected by reaction too close to template edge*
|
||||
This means an atom which changes type or connectivity during the
|
||||
reaction is too close to an 'edge' atom defined in the superimpose
|
||||
file. This could cause incorrect assignment of bonds, angle, etc.
|
||||
Generally, this means you must include more atoms in your templates,
|
||||
such that there are at least two atoms between each atom involved in
|
||||
the reaction and an edge atom.
|
||||
|
||||
*Fix bond/swap will ignore defined angles*
|
||||
See the page for fix bond/swap for more info on this
|
||||
restriction.
|
||||
@ -470,6 +470,12 @@ This will most likely cause errors in kinetic fluctuations.
|
||||
*More than one compute sna/atom*
|
||||
Self-explanatory.
|
||||
|
||||
*More than one compute sna/grid*
|
||||
Self-explanatory.
|
||||
|
||||
*More than one compute sna/grid/local*
|
||||
Self-explanatory.
|
||||
|
||||
*More than one compute snad/atom*
|
||||
Self-explanatory.
|
||||
|
||||
@ -804,4 +810,3 @@ This will most likely cause errors in kinetic fluctuations.
|
||||
|
||||
*Using pair tail corrections with pair_modify compute no*
|
||||
The tail corrections will thus not be computed.
|
||||
|
||||
|
||||
2102
doc/src/Fortran.rst
2102
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/>`_.
|
||||
|
||||
@ -5,9 +5,9 @@ Client/server coupling of two (or more) codes is where one code is the
|
||||
"client" and sends request messages (data) to one (or more) "server"
|
||||
code(s). A server responds to each request with a reply message
|
||||
(data). This enables two (or more) codes to work in tandem to perform
|
||||
a simulation. LAMMPS can act as either a client or server code; it
|
||||
does this by using the `MolSSI Driver Interface (MDI) library
|
||||
<https://molssi-mdi.github.io/MDI_Library/html/index.html>`_,
|
||||
a simulation. In this context, LAMMPS can act as either a client or
|
||||
server code. It does this by using the `MolSSI Driver Interface (MDI)
|
||||
library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_,
|
||||
developed by the `Molecular Sciences Software Institute (MolSSI)
|
||||
<https://molssi.org>`_, which is supported by the :ref:`MDI <PKG-MDI>`
|
||||
package.
|
||||
@ -63,22 +63,39 @@ The package also provides a :doc:`mdi plugin <mdi>` command which
|
||||
enables LAMMPS to operate as an MDI driver and load an MDI engine as a
|
||||
plugin library.
|
||||
|
||||
The package also has a `fix mdi/aimd <fix_mdi_aimd>` command in which
|
||||
LAMMPS operates as an MDI driver to perform *ab initio* MD simulations
|
||||
in conjunction with a quantum mechanics code. Its post_force() method
|
||||
illustrates how a driver issues MDI commands to another code. This
|
||||
command can be used to couple to an MDI engine which is either a
|
||||
stand-alone code or a plugin library.
|
||||
The package also has a `fix mdi/qm <fix_mdi_qm>` command in which
|
||||
LAMMPS operates as an MDI driver in conjunction with a quantum
|
||||
mechanics code as an MDI engine. The post_force() method of the
|
||||
fix_mdi_qm.cpp file shows how a driver issues MDI commands to another
|
||||
code. This command can be used to couple to an MDI engine which is
|
||||
either a stand-alone code or a plugin library.
|
||||
|
||||
As explained on the `fix mdi/qm <fix_mdi_qm>` command doc page, it can
|
||||
be used to perform *ab initio* MD simulations or energy minimizations,
|
||||
or to evaluate the quantum energy and forces for a series of
|
||||
independent systems. The examples/mdi directory has example input
|
||||
scripts for all of these use cases.
|
||||
|
||||
----------
|
||||
|
||||
The examples/mdi directory contains Python scripts and LAMMPS input
|
||||
script which use LAMMPS as either an MDI driver or engine or both.
|
||||
Three example use cases are provided:
|
||||
Currently, 5 example use cases are provided:
|
||||
|
||||
* Run ab initio MD (AIMD) using 2 instances of LAMMPS, one as driver
|
||||
and one as an engine. As an engine, LAMMPS is a surrogate for a
|
||||
quantum code.
|
||||
* Run ab initio MD (AIMD) using 2 instances of LAMMPS. As a driver
|
||||
LAMMPS performs the timestepping in either NVE or NPT mode. As an
|
||||
engine, LAMMPS computes forces and is a surrogate for a quantum
|
||||
code.
|
||||
|
||||
* As a driver, LAMMPS runs an MD simulation. Every N steps it passes
|
||||
the current snapshot to an MDI engine to evaluate the energy,
|
||||
virial, and peratom forces. As the engine LAMMPS is a surrogate for
|
||||
a quantum code.
|
||||
|
||||
* As a driver, LAMMPS loops over a series of data files and passes the
|
||||
configuration to an MDI engine to evaluate the energy, virial, and
|
||||
peratom forces. As the engine LAMMPS is a surrogate for a quantum
|
||||
code.
|
||||
|
||||
* A Python script driver invokes a sequence of unrelated LAMMPS
|
||||
calculations. Calculations can be single-point energy/force
|
||||
@ -91,20 +108,22 @@ Three example use cases are provided:
|
||||
|
||||
Note that in any of these example where LAMMPS is used as an engine,
|
||||
an actual QM code (which supports MDI) could be used in its place,
|
||||
without modifying other code or scripts, except to specify the name of
|
||||
the QM code.
|
||||
without modifying the input scripts or launch commands, except to
|
||||
specify the name of the QM code.
|
||||
|
||||
The examples/mdi/README file explains how to launch both driver and
|
||||
The examples/mdi/Run.sh file illustrates how to launch both driver and
|
||||
engine codes so that they communicate using the MDI library via either
|
||||
MPI or sockets.
|
||||
MPI or sockets. Or using the engine as a stand-alone code or plugin
|
||||
library.
|
||||
|
||||
-------------
|
||||
|
||||
Currently there are two quantum DFT codes which have direct MDI
|
||||
support, `Quantum ESPRESSO (QE) <https://www.quantum-espresso.org/>`_
|
||||
and `INQ <https://qsg.llnl.gov/node/101.html>`_. There are also
|
||||
several QM codes which have indirect support through QCEngine or i-PI.
|
||||
The former means they require a wrapper program (QCEngine) with MDI
|
||||
Currently there are at least two quantum DFT codes which have direct
|
||||
MDI support, `Quantum ESPRESSO (QE)
|
||||
<https://www.quantum-espresso.org/>`_ and `INQ
|
||||
<https://qsg.llnl.gov/node/101.html>`_. There are also several QM
|
||||
codes which have indirect support through QCEngine or i-PI. The
|
||||
former means they require a wrapper program (QCEngine) with MDI
|
||||
support which writes/read files to pass data to the quantum code
|
||||
itself. The list of QCEngine-supported and i-PI-supported quantum
|
||||
codes is on the `MDI webpage
|
||||
|
||||
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.
|
||||
|
||||
----------
|
||||
|
||||
|
||||
@ -184,7 +184,7 @@ frame.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
import re, yaml
|
||||
import yaml
|
||||
import pandas as pd
|
||||
|
||||
try:
|
||||
@ -193,7 +193,7 @@ frame.
|
||||
from yaml import SafeLoader as Loader
|
||||
|
||||
with open("ave.yaml") as f:
|
||||
ave = yaml.load(docs, Loader=Loader)
|
||||
ave = yaml.load(f, Loader=Loader)
|
||||
|
||||
keys = ave['keywords']
|
||||
df = {}
|
||||
|
||||
@ -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>`_.
|
||||
|
||||
----------
|
||||
|
||||
|
||||
@ -8,18 +8,28 @@ This site M is located at a fixed distance away from the oxygen along
|
||||
the bisector of the HOH bond angle. A bond style of *harmonic* and an
|
||||
angle style of *harmonic* or *charmm* should also be used.
|
||||
|
||||
A TIP4P model is run with LAMMPS using either this command
|
||||
A TIP4P model is run with LAMMPS using either these commands
|
||||
for a cutoff model:
|
||||
|
||||
* :doc:`pair_style tip4p/cut <pair_lj_cut_tip4p>`
|
||||
* :doc:`pair_style lj/cut/tip4p/cut <pair_lj_cut_tip4p>`
|
||||
|
||||
or these two commands for a long-range model:
|
||||
or these commands for a long-range model:
|
||||
|
||||
* :doc:`pair_style tip4p/long <pair_coul>`
|
||||
* :doc:`pair_style lj/cut/tip4p/long <pair_lj_cut_tip4p>`
|
||||
* :doc:`pair_style lj/long/tip4p/long <pair_lj_long>`
|
||||
* :doc:`pair_style tip4p/long/soft <pair_fep_soft>`
|
||||
* :doc:`pair_style lj/cut/tip4p/long/soft <pair_fep_soft>`
|
||||
* :doc:`kspace_style pppm/tip4p <kspace_style>`
|
||||
* :doc:`kspace_style pppm/disp/tip4p <kspace_style>`
|
||||
|
||||
For both models, the bond lengths and bond angles should be held fixed
|
||||
using the :doc:`fix shake <fix_shake>` command.
|
||||
The bond lengths and bond angles should be held fixed using the
|
||||
:doc:`fix shake <fix_shake>` or :doc:`fix rattle <fix_shake>` command,
|
||||
unless a parameterization for a flexible TIP4P model is used. The
|
||||
parameter sets listed below are all for rigid TIP4P model variants and
|
||||
thus the bond and angle force constants are not used and can be set to
|
||||
any legal value; only equilibrium length and angle are used.
|
||||
|
||||
These are the additional parameters (in real units) to set for O and H
|
||||
atoms and the water molecule to run a rigid TIP4P model with a cutoff
|
||||
@ -87,17 +97,18 @@ solver (e.g. Ewald or PPPM in LAMMPS):
|
||||
| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
|
||||
|
|
||||
|
||||
Note that the when using the TIP4P pair style, the neighbor list
|
||||
cutoff for Coulomb interactions is effectively extended by a distance
|
||||
2 \* (OM distance), to account for the offset distance of the
|
||||
fictitious charges on O atoms in water molecules. Thus it is
|
||||
typically best in an efficiency sense to use a LJ cutoff >= Coulomb
|
||||
cutoff + 2\*(OM distance), to shrink the size of the neighbor list.
|
||||
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.
|
||||
Note that the when using the TIP4P pair style, the neighbor list cutoff
|
||||
for Coulomb interactions is effectively extended by a distance 2 \* (OM
|
||||
distance), to account for the offset distance of the fictitious charges
|
||||
on O atoms in water molecules. Thus it is typically best in an
|
||||
efficiency sense to use a LJ cutoff >= Coulomb cutoff + 2\*(OM
|
||||
distance), to shrink the size of the neighbor list. 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.
|
||||
@ -68,7 +68,8 @@ liquid Ar via the GK formalism:
|
||||
# Sample LAMMPS input script for viscosity of liquid Ar
|
||||
|
||||
units real
|
||||
variable T equal 86.4956
|
||||
variable T equal 200.0 # run temperature
|
||||
variable Tinit equal 250.0 # equilibration temperature
|
||||
variable V equal vol
|
||||
variable dt equal 4.0
|
||||
variable p equal 400 # correlation length
|
||||
@ -99,12 +100,14 @@ liquid Ar via the GK formalism:
|
||||
|
||||
# equilibration and thermalization
|
||||
|
||||
velocity all create $T 102486 mom yes rot yes dist gaussian
|
||||
fix NVT all nvt temp $T $T 10 drag 0.2
|
||||
velocity all create ${Tinit} 102486 mom yes rot yes dist gaussian
|
||||
fix NVT all nvt temp ${Tinit} ${Tinit} 10 drag 0.2
|
||||
run 8000
|
||||
|
||||
# viscosity calculation, switch to NVE if desired
|
||||
|
||||
velocity all create $T 102486 mom yes rot yes dist gaussian
|
||||
fix NVT all nvt temp $T $T 10 drag 0.2
|
||||
#unfix NVT
|
||||
#fix NVE all nve
|
||||
|
||||
@ -122,7 +125,7 @@ liquid Ar via the GK formalism:
|
||||
run 100000
|
||||
variable v equal (v_v11+v_v22+v_v33)/3.0
|
||||
variable ndens equal count(all)/vol
|
||||
print "average viscosity: $v [Pa.s] @ $T K, ${ndens} /A^3"
|
||||
print "average viscosity: $v [Pa.s] @ $T K, ${ndens} atoms/A^3"
|
||||
|
||||
The fifth method is related to the above Green-Kubo method,
|
||||
but uses the Einstein formulation, analogous to the Einstein
|
||||
@ -131,9 +134,9 @@ time-integrated momentum fluxes play the role of Cartesian
|
||||
coordinates, whose mean-square displacement increases linearly
|
||||
with time at sufficiently long times.
|
||||
|
||||
The sixth is periodic perturbation method. It is also a non-equilibrium MD method.
|
||||
However, instead of measure the momentum flux in response of applied velocity gradient,
|
||||
it measures the velocity profile in response of applied stress.
|
||||
The sixth is the periodic perturbation method, which is also a non-equilibrium MD method.
|
||||
However, instead of measuring the momentum flux in response to an applied velocity gradient,
|
||||
it measures the velocity profile in response to applied stress.
|
||||
A cosine-shaped periodic acceleration is added to the system via the
|
||||
:doc:`fix accelerate/cos <fix_accelerate_cos>` command,
|
||||
and the :doc:`compute viscosity/cos<compute_viscosity_cos>` command is used to monitor the
|
||||
|
||||
@ -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,14 +27,14 @@ 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
|
||||
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
|
||||
|
||||
@ -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 |
@ -2,12 +2,13 @@ LAMMPS Library Interfaces
|
||||
*************************
|
||||
|
||||
As described on the :doc:`library interface to LAMMPS <Howto_library>`
|
||||
page, LAMMPS can be built as a library (static or shared), so that
|
||||
it can be called by another code, used in a :doc:`coupled manner
|
||||
page, LAMMPS can be built as a library (static or shared), so that it
|
||||
can be called by another code, used in a :doc:`coupled manner
|
||||
<Howto_couple>` with other codes, or driven through a :doc:`Python
|
||||
script <Python_head>`. Even the LAMMPS standalone executable is
|
||||
essentially a thin wrapper on top of the LAMMPS library, creating a
|
||||
LAMMPS instance, processing input and then existing.
|
||||
script <Python_head>`. The LAMMPS standalone executable itself is
|
||||
essentially a thin wrapper on top of the LAMMPS library, which creates a
|
||||
LAMMPS instance, passes the input for processing to that instance, and
|
||||
then exits.
|
||||
|
||||
Most of the APIs described below are based on C language wrapper
|
||||
functions in the files ``src/library.h`` and ``src/library.cpp``, but
|
||||
@ -87,6 +88,18 @@ run LAMMPS in serial mode.
|
||||
message retrieved <lammps_get_last_error_message>`. We thus
|
||||
recommend enabling C++ exceptions when using the library interface,
|
||||
|
||||
.. admonition:: Using the C library interface as a plugin
|
||||
:class: note
|
||||
|
||||
Rather than including the C library directly and link to the LAMMPS
|
||||
library at compile time, you can use the ``liblammpsplugin.h`` header
|
||||
file and the ``liblammpsplugin.c`` C code in the
|
||||
``examples/COUPLE/plugin`` folder for an interface to LAMMPS that is
|
||||
largely identical to the regular library interface, only that it will
|
||||
load a LAMMPS shared library file at runtime. This can be useful for
|
||||
applications where the interface to LAMMPS would be an optional
|
||||
feature.
|
||||
|
||||
.. warning::
|
||||
|
||||
No checks are made on the arguments of the function calls of the C
|
||||
@ -163,5 +176,3 @@ The following links provide some examples and references to the C++ API.
|
||||
:maxdepth: 1
|
||||
|
||||
Cplusplus
|
||||
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user