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

Merge branch 'mesocnt_stable' of https://github.com/phankl/lammps into HEAD

Browse Source
This commit is contained in:
phankl
2022-07-12 11:40:41 +01:00
parent c5c565195d ce971678ba
commit 601068a33f
396 changed files with 44749 additions and 4372 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
.github/dependabot.yml vendored Normal file
View File

@ -0,0 +1,6 @@
version: 2
updates:
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"

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

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

4
.github/workflows/compile-msvc.yml vendored
View File

@ -15,12 +15,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'

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

@ -17,7 +17,7 @@ jobs:
steps:
- name: Checkout repository
uses: actions/checkout@v2
uses: actions/checkout@v3
with:
fetch-depth: 2
@ -28,7 +28,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 }}

20
cmake/CMakeLists.txt
View File

@ -135,11 +135,13 @@ 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)
add_compile_options(/Zc:__cplusplus)
add_compile_options(/wd4244)
add_compile_options(/wd4267)
if(LAMMPS_EXCEPTIONS)
add_compile_options(/EHsc)
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()
@ -784,14 +786,16 @@ if(BUILD_SHARED_LIBS)
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(

208
cmake/Modules/LAMMPSInterfacePlugin.cmake Normal file
View 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})

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

@ -47,8 +47,8 @@ if(DOWNLOAD_KOKKOS)
list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
include(ExternalProject)
set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.6.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.6.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
set(KOKKOS_MD5 "0ec97fc0c356dd65bd2487defe81a7bf" CACHE STRING "MD5 checksum of KOKKOS tarball")
mark_as_advanced(KOKKOS_URL)
mark_as_advanced(KOKKOS_MD5)
ExternalProject_Add(kokkos_build
@ -72,7 +72,7 @@ if(DOWNLOAD_KOKKOS)
add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
elseif(EXTERNAL_KOKKOS)
find_package(Kokkos 3.6.00 REQUIRED CONFIG)
find_package(Kokkos 3.6.01 REQUIRED CONFIG)
target_link_libraries(lammps PRIVATE Kokkos::kokkos)
target_link_libraries(lmp PRIVATE Kokkos::kokkos)
else()

7
cmake/Modules/Packages/MDI.cmake
View File

@ -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.1.tar.gz" CACHE STRING "URL for MDI tarball")
set(MDI_MD5 "f9505fccd4c79301a619f6452dad4ad9" CACHE STRING "MD5 checksum for MDI tarball")
mark_as_advanced(MDI_URL)
mark_as_advanced(MDI_MD5)
enable_language(C)
@ -44,7 +44,7 @@ if(DOWNLOAD_MDI)
ExternalProject_Add(mdi_build
URL ${MDI_URL}
URL_MD5 ${MDI_MD5}
CMAKE_ARGS ${CMAKE_REQUEST_PIC}
CMAKE_ARGS
-DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
-DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
@ -54,6 +54,7 @@ if(DOWNLOAD_MDI)
-Dlanguage=C
-Dlibtype=STATIC
-Dmpi=${MDI_USE_MPI}
-Dplugins=ON
-Dpython_plugins=${MDI_USE_PYTHON_PLUGINS}
UPDATE_COMMAND ""
INSTALL_COMMAND ""

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

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

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

@ -32,5 +32,6 @@ target_include_directories(pace PUBLIC ${PACE_EVALUATOR_INCLUDE_DIR} ${YAML_CPP_
target_link_libraries(pace PRIVATE yaml-cpp-pace)
target_link_libraries(lammps PRIVATE pace)
if(CMAKE_PROJECT_NAME STREQUAL "lammps")
target_link_libraries(lammps PRIVATE pace)
endif()

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

@ -46,8 +46,8 @@ set(WIN_PACKAGES
MISC
ML-HDNNP
ML-IAP
ML-SNAP
ML-RANN
ML-SNAP
MOFFF
MOLECULE
MOLFILE
@ -56,6 +56,7 @@ set(WIN_PACKAGES
ORIENT
PERI
PHONON
PLUGIN
POEMS
PTM
QEQ

2
doc/Makefile
View File

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

4
doc/lammps.1
View File

@ -1,7 +1,7 @@
.TH LAMMPS "1" "2 June 2022" "2022-6-2"
.TH LAMMPS "1" "23 June 2022" "2022-6-23"
.SH NAME
.B LAMMPS
\- Molecular Dynamics Simulator. Version 2 June 2022
\- Molecular Dynamics Simulator. Version 23 June 2022
.SH SYNOPSIS
.B lmp

2
doc/src/Commands_compute.rst
View File

@ -138,6 +138,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>`

2
doc/src/Commands_fix.rst
View File

@ -103,7 +103,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>`

2
doc/src/Commands_pair.rst
View File

@ -194,7 +194,7 @@ 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>`

29
doc/src/Developer_plugins.rst
View File

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

6
doc/src/Errors_warnings.rst
View File

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

63
doc/src/Howto_mdi.rst
View File

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

4
doc/src/Howto_structured_data.rst
View File

@ -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 = {}

17
doc/src/Howto_viscosity.rst
View File

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

6
doc/src/Packages_details.rst
View File

@ -657,7 +657,7 @@ advection-diffusion-reaction systems. The equations of motion of these
DPD extensions are integrated through a modified velocity-Verlet (MVV)
algorithm.
**Author:** Zhen Li (Division of Applied Mathematics, Brown University)
**Author:** Zhen Li (Department of Mechanical Engineering, Clemson University)
**Supporting info:**
@ -1479,7 +1479,7 @@ the :doc:`Build extras <Build_extras>` page.
* lib/mdi/README
* :doc:`Howto MDI <Howto_mdi>`
* :doc:`mdi <mdi>`
* :doc:`fix mdi/aimd <fix_mdi_aimd>`
* :doc:`fix mdi/qm <fix_mdi_qm>`
* examples/PACKAGES/mdi
----------
@ -1801,6 +1801,8 @@ computes which analyze attributes of the potential.
* src/ML-SNAP: filenames -> commands
* :doc:`pair_style snap <pair_snap>`
* :doc:`compute sna/atom <compute_sna_atom>`
* :doc:`compute sna/grid <compute_sna_atom>`
* :doc:`compute sna/grid/local <compute_sna_atom>`
* :doc:`compute snad/atom <compute_sna_atom>`
* :doc:`compute snav/atom <compute_sna_atom>`
* examples/snap

3
doc/src/Speed_measure.rst
View File

@ -42,5 +42,4 @@ inaccurate relative timing data, because processors have to wait when
communication occurs for other processors to catch up. Thus the
reported times for "Communication" or "Other" may be higher than they
really are, due to load-imbalance. If this is an issue, you can
uncomment the MPI_Barrier() lines in src/timer.cpp, and re-compile
LAMMPS, to obtain synchronized timings.
use the :doc:`timer sync <timer>` command to obtain synchronized timings.

17
doc/src/Tools.rst
View File

@ -95,7 +95,7 @@ Miscellaneous tools
* :ref:`LAMMPS shell <lammps_shell>`
* :ref:`LAMMPS magic patterns for file(1) <magic>`
* :ref:`Offline build tool <offline>`
* :ref:`singularity <singularity_tool>`
* :ref:`singularity/apptainer <singularity_tool>`
* :ref:`SWIG interface <swig>`
* :ref:`vim <vim>`
@ -1007,14 +1007,15 @@ Ivanov, at University of Iceland (ali5 at hi.is).
.. _singularity_tool:
singularity tool
----------------------------------------
singularity/apptainer tool
--------------------------
The singularity sub-directory contains container definitions files
that can be used to build container images for building and testing
LAMMPS on specific OS variants using the `Singularity <https://sylabs.io>`_
container software. Contributions for additional variants are welcome.
For more details please see the README.md file in that folder.
The singularity sub-directory contains container definitions files that
can be used to build container images for building and testing LAMMPS on
specific OS variants using the `Apptainer <https://apptainer.org>`_ or
`Singularity <https://sylabs.io>`_ container software. Contributions for
additional variants are welcome. For more details please see the
README.md file in that folder.
----------

2
doc/src/compute.rst
View File

@ -284,6 +284,8 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`smd/vol <compute_smd_vol>` - per-particle volumes and their sum in Smooth Mach Dynamics
* :doc:`snap <compute_sna_atom>` - gradients of SNAP energy and forces w.r.t. linear coefficients and related quantities for fitting SNAP potentials
* :doc:`sna/atom <compute_sna_atom>` - bispectrum components for each atom
* :doc:`sna/grid <compute_sna_atom>` - global array of bispectrum components on a regular grid
* :doc:`sna/grid/local <compute_sna_atom>` - local array of bispectrum components on a regular grid
* :doc:`snad/atom <compute_sna_atom>` - derivative of bispectrum components for each atom
* :doc:`snav/atom <compute_sna_atom>` - virial contribution from bispectrum components for each atom
* :doc:`sph/e/atom <compute_sph_e_atom>` - per-atom internal energy of Smooth-Particle Hydrodynamics atoms

61
doc/src/compute_ave_sphere_atom.rst
View File

@ -35,16 +35,24 @@ Examples
Description
"""""""""""
Define a computation that calculates the local density and temperature
for each atom and neighbors inside a spherical cutoff.
Define a computation that calculates the local mass density and
temperature for each atom based on its neighbors inside a spherical
cutoff. If an atom has M neighbors, then its local mass density is
calculated as the sum of its mass and its M neighbor masses, divided
by the volume of the cutoff sphere (or circle in 2d). The local
temperature of the atom is calculated as the temperature of the
collection of M+1 atoms, after subtracting the center-of-mass velocity
of the M+1 atoms from each of the M+1 atom's velocities. This is
effectively the thermal velocity of the neighborhood of the central
atom, similar to :doc:`compute temp/com <compute_temp_com>`.
The optional keyword *cutoff* defines the distance cutoff
used when searching for neighbors. The default value is the cutoff
specified by the pair style. If no pair style is defined, then a cutoff
must be defined using this keyword. If the specified cutoff is larger than
that of the pair_style plus neighbor skin (or no pair style is defined),
the *comm_modify cutoff* option must also be set to match that of the
*cutoff* keyword.
The optional keyword *cutoff* defines the distance cutoff used when
searching for neighbors. The default value is the cutoff specified by
the pair style. If no pair style is defined, then a cutoff must be
defined using this keyword. If the specified cutoff is larger than
that of the pair_style plus neighbor skin (or no pair style is
defined), the *comm_modify cutoff* option must also be set to match
that of the *cutoff* keyword.
The neighbor list needed to compute this quantity is constructed each
time the calculation is performed (i.e. each time a snapshot of atoms
@ -55,16 +63,16 @@ too frequently.
If you have a bonded system, then the settings of
:doc:`special_bonds <special_bonds>` command can remove pairwise
interactions between atoms in the same bond, angle, or dihedral. This
is the default setting for the :doc:`special_bonds <special_bonds>`
command, and means those pairwise interactions do not appear in the
neighbor list. Because this fix uses the neighbor list, it also means
those pairs will not be included in the order parameter. This
difficulty can be circumvented by writing a dump file, and using the
:doc:`rerun <rerun>` command to compute the order parameter for
snapshots in the dump file. The rerun script can use a
:doc:`special_bonds <special_bonds>` command that includes all pairs in
the neighbor list.
interactions between atoms in the same bond, angle, or dihedral.
This is the default setting for the :doc:`special_bonds
<special_bonds>` command, and means those pairwise interactions do
not appear in the neighbor list. Because this compute uses the
neighbor list, it also means those pairs will not be included in
the order parameter. This difficulty can be circumvented by
writing a dump file, and using the :doc:`rerun <rerun>` command to
compute the order parameter for snapshots in the dump file. The
rerun script can use a :doc:`special_bonds <special_bonds>` command
that includes all pairs in the neighbor list.
----------
@ -77,17 +85,20 @@ too frequently.
Output info
"""""""""""
This compute calculates a per-atom array with two columns: density and temperature.
This compute calculates a per-atom array with two columns: mass
density in density :doc:`units <units>` and temperature in temperature
:doc:`units <units>`.
These values can be accessed by any command that uses per-atom values
from a compute as input. See the :doc:`Howto output <Howto_output>` doc
page for an overview of LAMMPS output options.
from a compute as input. See the :doc:`Howto output <Howto_output>`
doc page for an overview of LAMMPS output options.
Restrictions
""""""""""""
This compute is part of the EXTRA-COMPUTE package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
This compute is part of the EXTRA-COMPUTE package. It is only enabled
if LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
Related commands
""""""""""""""""
@ -97,5 +108,5 @@ Related commands
Default
"""""""
The option defaults are *cutoff* = pair style cutoff
The option defaults are *cutoff* = pair style cutoff.

163
doc/src/compute_sna_atom.rst
View File

@ -2,6 +2,8 @@
.. index:: compute snad/atom
.. index:: compute snav/atom
.. index:: compute snap
.. index:: compute sna/grid
.. index:: compute sna/grid/local
compute sna/atom command
========================
@ -15,6 +17,12 @@ compute snav/atom command
compute snap command
====================
compute sna/grid command
========================
compute sna/grid/local command
==============================
Syntax
""""""
@ -24,6 +32,9 @@ Syntax
compute ID group-ID snad/atom rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
compute ID group-ID snav/atom rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
compute ID group-ID snap rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
compute ID group-ID snap rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
compute ID group-ID sna/grid nx ny nz rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
compute ID group-ID sna/grid/local nx ny nz rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
* ID, group-ID are documented in :doc:`compute <compute>` command
* sna/atom = style name of this compute command
@ -32,8 +43,9 @@ Syntax
* twojmax = band limit for bispectrum components (non-negative integer)
* R_1, R_2,... = list of cutoff radii, one for each type (distance units)
* w_1, w_2,... = list of neighbor weights, one for each type
* nx, ny, nz = number of grid points in x, y, and z directions (positive integer)
* zero or more keyword/value pairs may be appended
* keyword = *rmin0* or *switchflag* or *bzeroflag* or *quadraticflag* or *chem* or *bnormflag* or *wselfallflag* or *bikflag* or *switchinnerflag* or *sinner* or *dinner*
* keyword = *rmin0* or *switchflag* or *bzeroflag* or *quadraticflag* or *chem* or *bnormflag* or *wselfallflag* or *bikflag* or *switchinnerflag* or *sinner* or *dinner* or *dgradflag*
.. parsed-literal::
@ -56,9 +68,6 @@ Syntax
*wselfallflag* value = *0* or *1*
*0* = self-contribution only for element of central atom
*1* = self-contribution for all elements
*bikflag* value = *0* or *1* (only implemented for compute snap)
*0* = per-atom bispectrum descriptors are summed over atoms
*1* = per-atom bispectrum descriptors are not summed over atoms
*switchinnerflag* value = *0* or *1*
*0* = do not use inner switching function
*1* = use inner switching function
@ -66,6 +75,12 @@ Syntax
*sinnerlist* = *ntypes* values of *Sinner* (distance units)
*dinner* values = *dinnerlist*
*dinnerlist* = *ntypes* values of *Dinner* (distance units)
*bikflag* value = *0* or *1* (only implemented for compute snap)
*0* = descriptors are summed over atoms of each type
*1* = descriptors are listed separately for each atom
*dgradflag* value = *0* or *1* (only implemented for compute snap)
*0* = descriptor gradients are summed over atoms of each type
*1* = descriptor gradients are listed separately for each atom pair
Examples
""""""""
@ -78,6 +93,7 @@ Examples
compute snap all snap 1.4 0.95 6 2.0 1.0
compute snap all snap 1.0 0.99363 6 3.81 3.83 1.0 0.93 chem 2 0 1
compute snap all snap 1.0 0.99363 6 3.81 3.83 1.0 0.93 switchinnerflag 1 sinner 1.35 1.6 dinner 0.25 0.3
compute bgrid all sna/grid/local 200 200 200 1.4 0.95 6 2.0 1.0
Description
"""""""""""
@ -212,6 +228,46 @@ command:
See section below on output for a detailed explanation of the data
layout in the global array.
The compute *sna/grid* and *sna/grid/local* commands calculate
bispectrum components for a regular grid of points.
These are calculated from the local density of nearby atoms *i'*
around each grid point, as if there was a central atom *i*
at the grid point. This is useful for characterizing fine-scale
structure in a configuration of atoms, and it is used
in the `MALA package <https://github.com/casus/mala>`_
to build machine-learning surrogates for finite-temperature Kohn-Sham
density functional theory (:ref:`Ellis et al. <Ellis2021>`)
Neighbor atoms not in the group do not contribute to the
bispectrum components of the grid points. The distance cutoff :math:`R_{ii'}`
assumes that *i* has the same type as the neighbor atom *i'*.
Compute *sna/grid* calculates a global array containing bispectrum
components for a regular grid of points.
The grid is aligned with the current box dimensions, with the
first point at the box origin, and forming a regular 3d array with
*nx*, *ny*, and *nz* points in the x, y, and z directions. For triclinic
boxes, the array is congruent with the periodic lattice vectors
a, b, and c. The array contains one row for each of the
:math:`nx \times ny \times nz` grid points, looping over the index for *ix* fastest,
then *iy*, and *iz* slowest. Each row of the array contains the *x*, *y*,
and *z* coordinates of the grid point, followed by the bispectrum
components. See section below on output for a detailed explanation of the data
layout in the global array.
Compute *sna/grid/local* calculates bispectrum components of a regular
grid of points similarly to compute *sna/grid* described above.
However, because the array is local, it contains only rows for grid points
that are local to the processor sub-domain. The global grid
of :math:`nx \times ny \times nz` points is still laid out in space the same as for *sna/grid*,
but grid points are strictly partitioned, so that every grid point appears in
one and only one local array. The array contains one row for each of the
local grid points, looping over the global index *ix* fastest,
then *iy*, and *iz* slowest. Each row of the array contains
the global indexes *ix*, *iy*, and *iz* first, followed by the *x*, *y*,
and *z* coordinates of the grid point, followed by the bispectrum
components. See section below on output for a detailed explanation of the data
layout in the global array.
The value of all bispectrum components will be zero for atoms not in
the group. Neighbor atoms not in the group do not contribute to the
bispectrum of atoms in the group.
@ -307,15 +363,6 @@ This option is typically used in conjunction with the *chem* keyword,
and LAMMPS will generate a warning if both *chem* and *bnormflag*
are not both set or not both unset.
The keyword *bikflag* determines whether or not to expand the bispectrum
rows of the global array returned by compute snap. If *bikflag* is set
to *1* then the bispectrum row, which is typically the per-atom bispectrum
descriptors :math:`B_{i,k}` summed over all atoms *i* to produce
:math:`B_k`, becomes bispectrum rows equal to the number of atoms. Thus,
the resulting bispectrum rows are :math:`B_{i,k}` instead of just
:math:`B_k`. In this case, the entries in the final column for these rows
are set to zero.
The keyword *switchinnerflag* with value 1
activates an additional radial switching
function similar to :math:`f_c(r)` above, but acting to switch off
@ -340,6 +387,36 @@ When the central atom and the neighbor atom have different types,
the values of :math:`S_{inner}` and :math:`D_{inner}` are
the arithmetic means of the values for both types.
The keywords *bikflag* and *dgradflag* are only used by compute *snap*.
The keyword *bikflag* determines whether or not to list the descriptors
of each atom separately, or sum them together and list in a single row.
If *bikflag* is set
to *0* then a single bispectrum row is used, which contains the per-atom bispectrum
descriptors :math:`B_{i,k}` summed over all atoms *i* to produce
:math:`B_k`. If *bikflag* is set
to *1* this is replaced by a separate per-atom bispectrum row for each atom.
In this case, the entries in the final column for these rows
are set to zero.
The keyword *dgradflag* determines whether to sum atom gradients or list
them separately. If *dgradflag* is set to 0, the bispectrum
descriptor gradients w.r.t. atom *j* are summed over all atoms *i'*
of type *I* (similar to *snad/atom* above).
If *dgradflag* is set to 1, gradients are listed separately for each pair of atoms.
Each row corresponds
to a single term :math:`\frac{\partial {B_{i,k} }}{\partial {r}^a_j}`
where :math:`{r}^a_j` is the *a-th* position coordinate of the atom with global
index *j*. This also changes
the number of columns to be equal to the number of bispectrum components, with 3
additional columns representing the indices :math:`i`, :math:`j`, and :math:`a`,
as explained more in the Output info section below. The option *dgradflag=1*
requires that *bikflag=1*.
.. note::
Using *dgradflag* = 1 produces a global array with :math:`N + 3N^2 + 1` rows
which becomes expensive for systems with more than 1000 atoms.
.. note::
If you have a bonded system, then the settings of :doc:`special_bonds
@ -414,6 +491,21 @@ number of columns in the global array generated by *snap* are 31, and
931, respectively, while the number of rows is 1+3\*\ *N*\ +6, where *N*
is the total number of atoms.
Compute *sna/grid* evaluates a global array.
The array contains one row for each of the
:math:`nx \times ny \times nz` grid points, looping over the index for *ix* fastest,
then *iy*, and *iz* slowest. Each row of the array contains the *x*, *y*,
and *z* coordinates of the grid point, followed by the bispectrum
components.
Compute *sna/grid/local* evaluates a local array.
The array contains one row for each of the
local grid points, looping over the global index *ix* fastest,
then *iy*, and *iz* slowest. Each row of the array contains
the global indexes *ix*, *iy*, and *iz* first, followed by the *x*, *y*,
and *z* coordinates of the grid point, followed by the bispectrum
components.
If the *quadratic* keyword value is set to 1, then additional columns
are generated, corresponding to the products of all distinct pairs of
bispectrum components. If the number of bispectrum components is *K*,
@ -435,6 +527,42 @@ components. For the purposes of handling contributions to force, virial,
and quadratic combinations, these :math:`N_{elem}^3` sub-blocks are
treated as a single block of :math:`K N_{elem}^3` columns.
If the *bik* keyword is set to 1, the structure of the snap array is expanded.
The first :math:`N` rows of the snap array
correspond to :math:`B_{i,k}` instead of a single row summed over atoms :math:`i`.
In this case, the entries in the final column for these rows
are set to zero. Also, each row contains only non-zero entries for the
columns corresponding to the type of that atom. This is not true in the case
of *dgradflag* keyword = 1 (see below).
If the *dgradflag* keyword is set to 1, this changes the structure of the
global array completely.
Here the *snad/atom* quantities are replaced with rows corresponding to
descriptor gradient components on single atoms:
.. math::
\frac{\partial {B_{i,k} }}{\partial {r}^a_j}
where :math:`{r}^a_j` is the *a-th* position coordinate of the atom with global
index *j*. The rows are
organized in chunks, where each chunk corresponds to an atom with global index
:math:`j`. The rows in an atom :math:`j` chunk correspond to
atoms with global index :math:`i`. The total number of rows for
these descriptor gradients is therefore :math:`3N^2`.
The number of columns is equal to the number of bispectrum components,
plus 3 additional left-most columns representing the global atom indices
:math:`i`, :math:`j`,
and Cartesian direction :math:`a` (0, 1, 2, for x, y, z).
The first 3 columns of the first :math:`N` rows belong to the reference
potential force components. The remaining K columns contain the
:math:`B_{i,k}` per-atom descriptors corresponding to the non-zero entries
obtained when *bikflag* = 1.
The first column of the last row, after the first
:math:`N + 3N^2` rows, contains the reference potential
energy. The virial components are not used with this option. The total number of
rows is therefore :math:`N + 3N^2 + 1` and the number of columns is :math:`K + 3`.
These values can be accessed by any command that uses per-atom values
from a compute as input. See the :doc:`Howto output <Howto_output>` doc
page for an overview of LAMMPS output options. To see how this command
@ -464,8 +592,7 @@ The optional keyword defaults are *rmin0* = 0,
.. _Thompson20141:
**(Thompson)** Thompson, Swiler, Trott, Foiles, Tucker, under review, preprint
available at `arXiv:1409.3880 <http://arxiv.org/abs/1409.3880>`_
**(Thompson)** Thompson, Swiler, Trott, Foiles, Tucker, J Comp Phys, 285, 316, (2015).
.. _Bartok20101:
@ -486,4 +613,8 @@ of Angular Momentum, World Scientific, Singapore (1987).
.. _Cusentino2020:
**(Cusentino)** Cusentino, Wood, and Thompson, J Phys Chem A, xxx, xxxxx, (2020)
**(Cusentino)** Cusentino, Wood, Thompson, J Phys Chem A, 124, 5456, (2020)
.. _Ellis2021:
**(Ellis)** Ellis, Fiedler, Popoola, Modine, Stephens, Thompson, Cangi, Rajamanickam, Phys Rev B, 104, 035120, (2021)

49
doc/src/dump.rst
View File

@ -27,6 +27,9 @@ dump command
:doc:`dump custom/adios <dump_adios>` command
=============================================
:doc:`dump cfg/uef <dump_cfg_uef>` command
==========================================
Syntax
""""""
@ -36,7 +39,7 @@ Syntax
* ID = user-assigned name for the dump
* group-ID = ID of the group of atoms to be dumped
* style = *atom* or *atom/gz* or *atom/zstd or *atom/mpiio* or *cfg* or *cfg/gz* or *cfg/zstd* or *cfg/mpiio* or *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *dcd* or *h5md* or *image* or *local* or *local/gz* or *local/zstd* or *molfile* or *movie* or *netcdf* or *netcdf/mpiio* or *vtk* or *xtc* or *xyz* or *xyz/gz* or *xyz/zstd* or *xyz/mpiio* or *yaml*
* style = *atom* or *atom/gz* or *atom/zstd or *atom/mpiio* or *cfg* or *cfg/gz* or *cfg/zstd* or *cfg/mpiio* or *cfg/uef* or *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *dcd* or *h5md* or *image* or *local* or *local/gz* or *local/zstd* or *molfile* or *movie* or *netcdf* or *netcdf/mpiio* or *vtk* or *xtc* or *xyz* or *xyz/gz* or *xyz/zstd* or *xyz/mpiio* or *yaml*
* N = dump every this many timesteps
* file = name of file to write dump info to
* args = list of arguments for a particular style
@ -47,22 +50,23 @@ Syntax
*atom/gz* args = none
*atom/zstd* args = none
*atom/mpiio* args = none
*atom/adios* args = none, discussed on :doc:`dump atom/adios <dump_adios>` doc page
*atom/adios* args = none, discussed on :doc:`dump atom/adios <dump_adios>` page
*cfg* args = same as *custom* args, see below
*cfg/gz* args = same as *custom* args, see below
*cfg/zstd* args = same as *custom* args, see below
*cfg/mpiio* args = same as *custom* args, see below
*cfg/uef* args = same as *custom* args, discussed on :doc:`dump cfg/uef <dump_cfg_uef>` page
*custom*, *custom/gz*, *custom/zstd*, *custom/mpiio* args = see below
*custom/adios* args = same as *custom* args, discussed on :doc:`dump custom/adios <dump_adios>` doc page
*custom/adios* args = same as *custom* args, discussed on :doc:`dump custom/adios <dump_adios>` page
*dcd* args = none
*h5md* args = discussed on :doc:`dump h5md <dump_h5md>` doc page
*image* args = discussed on :doc:`dump image <dump_image>` doc page
*h5md* args = discussed on :doc:`dump h5md <dump_h5md>` page
*image* args = discussed on :doc:`dump image <dump_image>` page
*local*, *local/gz*, *local/zstd* args = see below
*molfile* args = discussed on :doc:`dump molfile <dump_molfile>` doc page
*movie* args = discussed on :doc:`dump image <dump_image>` doc page
*netcdf* args = discussed on :doc:`dump netcdf <dump_netcdf>` doc page
*netcdf/mpiio* args = discussed on :doc:`dump netcdf <dump_netcdf>` doc page
*vtk* args = same as *custom* args, see below, also :doc:`dump vtk <dump_vtk>` doc page
*molfile* args = discussed on :doc:`dump molfile <dump_molfile>` page
*movie* args = discussed on :doc:`dump image <dump_image>` page
*netcdf* args = discussed on :doc:`dump netcdf <dump_netcdf>` page
*netcdf/mpiio* args = discussed on :doc:`dump netcdf <dump_netcdf>` page
*vtk* args = same as *custom* args, see below, also :doc:`dump vtk <dump_vtk>` page
*xtc* args = none
*xyz* args = none
*xyz/gz* args = none
@ -155,7 +159,7 @@ timesteps in one of several styles. The *image* and *movie* styles are
the exception: the *image* style renders a JPG, PNG, or PPM image file
of the atom configuration every N timesteps while the *movie* style
combines and compresses them into a movie file; both are discussed in
detail on the :doc:`dump image <dump_image>` doc page. The timesteps on
detail on the :doc:`dump image <dump_image>` page. The timesteps on
which dump output is written can also be controlled by a variable.
See the :doc:`dump_modify every <dump_modify>` command.
@ -194,7 +198,7 @@ or multiple smaller files).
For the *atom*, *custom*, *cfg*, and *local* styles, sorting is off by
default. For the *dcd*, *xtc*, *xyz*, and *molfile* styles, sorting
by atom ID is on by default. See the :doc:`dump_modify <dump_modify>`
doc page for details.
page for details.
The *atom/gz*, *cfg/gz*, *custom/gz*, *local/gz*, and *xyz/gz* styles
are identical in command syntax to the corresponding styles without
@ -204,7 +208,7 @@ alternative approach to writing compressed files via a pipe, as done
by the regular dump styles, which may be required on clusters where
the interface to the high-speed network disallows using the fork()
library call (which is needed for a pipe). For the remainder of this
doc page, you should thus consider the *atom* and *atom/gz* styles
page, you should thus consider the *atom* and *atom/gz* styles
(etc) to be inter-changeable, with the exception of the required
filename suffix.
@ -218,7 +222,7 @@ As explained below, the *atom/mpiio*, *cfg/mpiio*, *custom/mpiio*, and
*xyz/mpiio* styles are identical in command syntax and in the format
of the dump files they create, to the corresponding styles without
"mpiio", except the single dump file they produce is written in
parallel via the MPI-IO library. For the remainder of this doc page,
parallel via the MPI-IO library. For the remainder of this page,
you should thus consider the *atom* and *atom/mpiio* styles (etc) to
be inter-changeable. The one exception is how the filename is
specified for the MPI-IO styles, as explained below.
@ -664,7 +668,7 @@ so that each value is 0.0 to 1.0. If the simulation box is triclinic
(tilted), then all atom coords will still be between 0.0 and 1.0.
I.e. actual unscaled (x,y,z) = xs\*A + ys\*B + zs\*C, where (A,B,C) are
the non-orthogonal vectors of the simulation box edges, as discussed
on the :doc:`Howto triclinic <Howto_triclinic>` doc page.
on the :doc:`Howto triclinic <Howto_triclinic>` page.
Use *xu*, *yu*, *zu* if you want the coordinates "unwrapped" by the
image flags for each atom. Unwrapped means that if the atom has
@ -779,6 +783,11 @@ To write gzipped dump files, you must either compile LAMMPS with the
-DLAMMPS_GZIP option or use the styles from the COMPRESS package.
See the :doc:`Build settings <Build_settings>` page for details.
While a dump command is active (i.e. has not been stopped by using
the undump command), no commands may be used that will change the
timestep (e.g. :doc:`reset_timestep <reset_timestep>`). LAMMPS
will terminate with an error otherwise.
The *atom/gz*, *cfg/gz*, *custom/gz*, and *xyz/gz* styles are part of
the COMPRESS package. They are only enabled if LAMMPS was built with
that package. See the :doc:`Build package <Build_package>` page for
@ -787,7 +796,7 @@ more info.
The *atom/mpiio*, *cfg/mpiio*, *custom/mpiio*, and *xyz/mpiio* styles
are part of the MPIIO package. They are only enabled if LAMMPS was
built with that package. See the :doc:`Build package <Build_package>`
doc page for more info.
page for more info.
The *xtc*, *dcd* and *yaml* styles are part of the EXTRA-DUMP package.
They are only enabled if LAMMPS was built with that package. See the
@ -797,12 +806,12 @@ Related commands
""""""""""""""""
:doc:`dump atom/adios <dump_adios>`, :doc:`dump custom/adios <dump_adios>`,
:doc:`dump h5md <dump_h5md>`, :doc:`dump image <dump_image>`,
:doc:`dump molfile <dump_molfile>`, :doc:`dump_modify <dump_modify>`,
:doc:`undump <undump>`
:doc:`dump cfg/uef <dump_cfg_uef>`, :doc:`dump h5md <dump_h5md>`,
:doc:`dump image <dump_image>`, :doc:`dump molfile <dump_molfile>`,
:doc:`dump_modify <dump_modify>`, :doc:`undump <undump>`, :doc:`write_dump <write_dump>`
Default
"""""""
The defaults for the *image* and *movie* styles are listed on the
:doc:`dump image <dump_image>` doc page.
:doc:`dump image <dump_image>` page.

2
doc/src/fix.rst
View File

@ -246,7 +246,7 @@ accelerated styles exist.
* :doc:`lb/viscous <fix_lb_viscous>` -
* :doc:`lineforce <fix_lineforce>` - constrain atoms to move in a line
* :doc:`manifoldforce <fix_manifoldforce>` - restrain atoms to a manifold during minimization
* :doc:`mdi/aimd <fix_mdi_aimd>` - LAMMPS operates as driver for ab initio MD (AIMD) via the MolSSI Driver Interface (MDI)
* :doc:`mdi/qm <fix_mdi_qm>` - LAMMPS operates as driver for a quantum code via the MolSSI Driver Interface (MDI)
* :doc:`meso/move <fix_meso_move>` - move mesoscopic SPH/SDPD particles in a prescribed fashion
* :doc:`mol/swap <fix_mol_swap>` - Monte Carlo atom type swapping with a molecule
* :doc:`momentum <fix_momentum>` - zero the linear and/or angular momentum of a group of atoms

9
doc/src/fix_latte.rst
View File

@ -116,13 +116,6 @@ potential energy of the system as part of :doc:`thermodynamic output
<thermo_style>`. The default setting for this fix is :doc:`fix_modify
energy yes <fix_modify>`.
The :doc:`fix_modify <fix_modify>` *virial* option is supported by
this fix to add the contribution compute by LATTE to the global
pressure of the system via the :doc:`compute pressure
<compute_pressure>` command. This can be accessed by
:doc:`thermodynamic output <thermo_style>`. The default setting for
this fix is :doc:`fix_modify virial yes <fix_modify>`.
The :doc:`fix_modify <fix_modify>` *virial* option is supported by
this fix to add the contribution computed by LATTE to the global
pressure of the system as part of :doc:`thermodynamic output
@ -137,7 +130,7 @@ energy discussed above. The scalar value calculated by this fix is
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command.
The DFTB forces computed by LATTE via this fix are imposed during an
The DFTB forces computed by LATTE via this fix are used during an
energy minimization, invoked by the :doc:`minimize <minimize>`
command.

103
doc/src/fix_mdi_aimd.rst
View File

@ -1,103 +0,0 @@
.. index:: fix mdi/aimd
fix mdi/aimd command
======================
Syntax
""""""
.. parsed-literal::
fix ID group-ID mdi/aimd keyword
* ID, group-ID are documented in :doc:`fix <fix>` command
* mdi/aimd = style name of this fix command
* optional keyword = *plugin*
Examples
""""""""
.. code-block:: LAMMPS
fix 1 all mdi/aimd
fix 1 all mdi/aimd plugin
Description
"""""""""""
This command enables LAMMPS to act as a client with another server
code to couple the two codes together to perform ab initio MD (AIMD)
simulations.
More specifically, this command causes LAMMPS to begin using the `MDI
Library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_
to run as an MDI driver (client), which sends MDI commands to an
external MDI engine code (server) which in the case of AIMD is a
quantum mechanics (QM) code, or could be LAMMPS itself, acting as a
surrogate for a QM code. See the :doc:`Howto mdi <Howto_mdi>` page
for more information about how LAMMPS can operate as either an MDI
driver or engine.
The examples/mdi directory contains input scripts performing AIMD in
this manner with LAMMPS acting as both a driver and an engine
(surrogate for a QM code). The examples/mdi/README file explains how
to launch both driver and engine codes so that they communicate using
the MDI library via either MPI or sockets. Any QM code that supports
MDI could be used in place of LAMMPS acting as a QM surrogate. See
the :doc:`Howto mdi <Howto_mdi>` page for a current list (March 2022)
of such QM codes.
The engine code can run either as a stand-alone code, launched at the
same time as LAMMPS, or as a plugin library. See the :doc:`mdi plugin
<mdi>` command for how to trigger LAMMPS to load the plugin library.
Again, the examples/mdi/README file explains how to launch both driver
and engine codes so that engine is used in plugin mode.
To use this fix with a plugin engine, you must specify the
*plugin* keyword as the last argument, as illustrated above.
.. note::
As of April 2022, the *plugin* keyword is needed. In a future
version of the MDI library it will no longer be necessary.
----------
This fix performs the timestepping portion of an AIMD simulation.
Both LAMMPS and the engine code (QM or LAMMPS) should define the same
system (simulation box, atoms and their types) in their respective
input scripts. LAMMPS then begins its timestepping.
At the point in each timestep when LAMMPS needs the force on each
atom, it communicates with the engine code. It sends the current
simulation box size and shape (if they change dynamically, e.g. during
an NPT simulation), and the current atom coordinates. The engine code
computes quantum forces on each atom and returns them to LAMMPS. If
LAMMPS also needs the system energy and/or virial, it requests those
values from the engine code as well.
Restrictions
""""""""""""
This command is part of the MDI package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
To use LAMMPS as an MDI driver in conjunction with other MDI-enabled
atomistic codes, the :doc:`units <units>` command should be used to
specify *real* or *metal* units. This will ensure the correct unit
conversions between LAMMPS and MDI units, which the other codes will
also perform in their preferred units.
LAMMPS can also be used as an MDI driver in other unit choices it
supports, e.g. *lj*, but then no unit conversion is performed.
Related commands
""""""""""""""""
:doc:`mdi engine <mdi>`
Default
"""""""
none

276
doc/src/fix_mdi_qm.rst Normal file
View File

@ -0,0 +1,276 @@
.. index:: fix mdi/qm
fix mdi/qm command
======================
Syntax
""""""
.. parsed-literal::
fix ID group-ID mdi/qm keyword
* ID, group-ID are documented in :doc:`fix <fix>` command
* mdi/qm = style name of this fix command
* zero or more keyword/value pairs may be appended
* keyword = *virial* or *add* or *every* or *connect* or *elements*
.. parsed-literal::
*virial* args = *yes* or *no*
yes = request virial tensor from server code
no = do not request virial tensor from server code
*add* args = *yes* or *no*
yes = add returned value from server code to LAMMPS quantities
no = do not add returned values to LAMMPS quantities
*every* args = Nevery
Nevery = request values from server code once every Nevery steps
*connect* args = *yes* or *no*
yes = perform a one-time connection to the MDI engine code
no = do not perform the connection operation
*elements* args = N_1 N_2 ... N_ntypes
N_1,N_2,...N_ntypes = atomic number for each of ntypes LAMMPS atom types
Examples
""""""""
.. code-block:: LAMMPS
fix 1 all mdi/qm
fix 1 all mdi/qm virial yes
fix 1 all mdi/qm add no every 100 elements 13 29
Description
"""""""""""
This command enables LAMMPS to act as a client with another server
code that will compute the total energy, per-atom forces, and total
virial for atom conformations and simulation box size/shapes that
LAMMPS sends it.
Typically the server code will be a quantum mechanics (QM) code, hence
the name of the fix. However this is not required, the server code
could be another classical molecular dynamics code or LAMMPS itself.
The server code must support use of the `MDI Library
<https://molssi-mdi.github.io/MDI_Library/html/index.html>`_ as
explained below.
These are example use cases for this fix, discussed further below:
* perform an ab initio MD (AIMD) simulation with quantum forces
* perform an energy minimization with quantum forces
* perform a nudged elastic band (NEB) calculation with quantum forces
* perform a QM calculation for a series of independent systems which LAMMPS reads or generates
The code coupling performed by this command is done via the `MDI
Library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_.
LAMMPS runs as an MDI driver (client), and sends MDI commands to an
external MDI engine code (server), e.g. a QM code which has support
for MDI. See the :doc:`Howto mdi <Howto_mdi>` page for more
information about how LAMMPS can operate as either an MDI driver or
engine.
The examples/mdi directory contains input scripts using this fix in
the various use cases discussed below. In each case, two instances of
LAMMPS are used, once as an MDI driver, once as an MDI engine
(surrogate for a QM code). The examples/mdi/README file explains how
to launch two codes so that they communicate via the MDI library using
either MPI or sockets. Any QM code that supports MDI could be used in
place of LAMMPS acting as a QM surrogate. See the :doc:`Howto mdi
<Howto_mdi>` page for a current list (March 2022) of such QM codes.
Note that an engine code can support MDI in either or both of two
modes. It can be used as a stand-alone code, launched at the same
time as LAMMPS. Or it can be used as a plugin library, which LAMMPS
loads. See the :doc:`mdi plugin <mdi>` command for how to trigger
LAMMPS to load a plugin library. The examples/mdi/README file
explains how to launch the two codes in either mode.
----------
The *virial* keyword setting of yes or no determines whether
LAMMPS will request the QM code to also compute and return
a 6-element symmetric virial tensor for the system.
The *add* keyword setting of *yes* or *no* determines whether the
energy and forces and virial returned by the QM code will be added to
the LAMMPS internal energy and forces and virial or not. If the
setting is *no* then the default :doc:`fix_modify energy <fix_modify>`
and :doc:`fix_modify virial <fix_modify>` settings are also set to
*no* and your input scripts should not set them to yes. See more
details on these fix_modify settings below.
Whatever the setting for the *add* keyword, the QM energy, forces, and
virial will be stored by the fix, so they can be accessed by other
commands. See details below.
The *every* keyword determines how often the QM code will be invoked
during a dynamics run with the current LAMMPS simulation box and
configuration of atoms. The QM code will be called once every
*Nevery* timesteps.
The *connect* keyword determines whether this fix performs a one-time
connection to the QM code. The default is *yes*. The only time a
*no* is needed is if this command is used multiple times in an input
script. E.g. if it used inside a loop which also uses the :doc:`clear
<clear>` command to destroy the system (including any defined fixes).
See the examples/mdi/in.series.driver script as an example of this,
where LAMMPS is using the QM code to compute energy and forces for a
series of system configurations. In this use case *connect no*
is used along with the :doc:`mdi connect and exit <mdi>` command
to one-time initiate/terminate the connection outside the loop.
The *elements* keyword allows specification of what element each
LAMMPS atom type corresponds to. This is specified by the atomic
number of the element, e.g. 13 for Al. An atomic number must be
specified for each of the ntypes LAMMPS atom types. Ntypes is
typically specified via the create_box command or in the data file
read by the read_data command. If this keyword is not specified, then
this fix will send the LAMMPS atom type for each atom to the MDI
engine. If both the LAMMPS driver and the MDI engine are initialized
so that atom type values are consistent in both codes, then the
*elements* keyword is not needed. Otherwise the keyword can be used
to insure the two codes are consistent in their definition of atomic
species.
----------
The following 3 example use cases are illustrated in the examples/mdi
directory. See its README file for more details.
(1) To run an ab initio MD (AIMD) dynamics simulation, or an energy
minimization with QM forces, or a multi-replica NEB calculation, use
*add yes* and *every 1* (the defaults). This is so that every time
LAMMPS needs energy and forces, the QM code will be invoked.
Both LAMMPS and the QM code should define the same system (simulation
box, atoms and their types) in their respective input scripts. Note
that on this scenario, it may not be necessary for LAMMPS to define a
pair style or use a neighbor list.
LAMMPS will then perform the timestepping or minimization iterations
for the simulation. At the point in each timestep or iteration when
LAMMPS needs the force on each atom, it communicates with the engine
code. It sends the current simulation box size and shape (if they
change dynamically, e.g. during an NPT simulation), and the current
atom coordinates. The engine code computes quantum forces on each
atom and the total energy of the system and returns them to LAMMPS.
Note that if the AIMD simulation is an NPT or NPH model, or the energy
minimization includes :doc:`fix box relax <fix_box_relax>` to
equilibrate the box size/shape, then LAMMPS computes a pressure. This
means the *virial* keyword should be set to *yes* so that the QM
contribution to the pressure can be included.
(2) To run dynamics with a LAMMPS interatomic potential, and evaluate
the QM energy and forces once every 1000 steps, use *add no* and
*every 1000*. This could be useful for using an MD run to generate
randomized configurations which are then passed to the QM code to
produce training data for a machine learning potential. A :doc:`dump
custom <dump>` command could be invoked every 1000 steps to dump the
atom coordinates and QM forces to a file. Likewise the QM energy and
virial could be output with the :doc:`thermo_style custom
<thermo_style>` command.
(3) To do a QM evaluation of energy and forces for a series of *N*
independent systems (simulation box and atoms), use *add no* and
*every 1*. Write a LAMMPS input script which loops over the *N*
systems. See the :doc:`Howto multiple <Howto_multiple>` doc page for
details on looping and removing old systems. The series of systems
could be initialized by reading them from data files with
:doc:`read_data <read_data>` commands. Or, for example, by using the
:doc:`lattice <lattice>` , :doc:`create_atoms <create_atoms>`,
:doc:`delete_atoms <delete_atoms>`, and/or :doc:`displace_atoms
random <displace_atoms>` commands to generate a series of different
systems. At the end of the loop perform :doc:`run 0 <run>` and
:doc:`write_dump <write_dump>` commands to invoke the QM code and
output the QM energy and forces. As in (2) this be useful to produce
QM data for training a machine learning potential.
----------
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
No information about this fix is written to :doc:`binary restart files
<restart>`.
The :doc:`fix_modify <fix_modify>` *energy* option is supported by
this fix to add the potential energy computed by the QM code to the
global potential energy of the system as part of :doc:`thermodynamic
output <thermo_style>`. The default setting for this fix is
:doc:`fix_modify energy yes <fix_modify>`, unless the *add* keyword is
set to *no*, in which case the default setting is *no*.
The :doc:`fix_modify <fix_modify>` *virial* option is supported by
this fix to add the contribution computed by the QM code to the global
pressure of the system as part of :doc:`thermodynamic output
<thermo_style>`. The default setting for this fix is :doc:`fix_modify
virial yes <fix_modify>`, unless the *add* keyword is set to *no*, in
which case the default setting is *no*.
This fix computes a global scalar which can be accessed by various
:doc:`output commands <Howto_output>`. The scalar is the energy
returned by the QM code. The scalar value calculated by this fix is
"extensive".
This fix also computes a global vector with of length 6 which contains
the symmetric virial tensor values returned by the QM code. It can
likewise be accessed by various :doc:`output commands <Howto_output>`.
The ordering of values in the symmetric virial tensor is as follows:
vxx, vyy, vzz, vxy, vxz, vyz. The values will be in pressure
:doc:`units <units>`.
This fix also computes a peratom array with 3 columns which contains
the peratom forces returned by the QM code. It can likewise be
accessed by various :doc:`output commands <Howto_output>`.
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command.
Assuming the *add* keyword is set to *yes* (the default), the forces
computed by the QM code are used during an energy minimization,
invoked by the :doc:`minimize <minimize>` command.
.. note::
If you want the potential energy associated with the QM forces to
be included in the total potential energy of the system (the
quantity being minimized), you MUST not disable the
:doc:`fix_modify <fix_modify>` *energy* option for this fix, which
means the *add* keyword should also be set to *yes* (the default).
Restrictions
""""""""""""
This command is part of the MDI package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
The QM code does not currently compute and return per-atom energy or
per-atom virial contributions. So they will not show up as part of
the calculations performed by the :doc:`compute pe/atom
<compute_pe_atom>` or :doc:`compute stress/atom <compute_stress_atom>`
commands.
To use LAMMPS as an MDI driver in conjunction with other MDI-enabled
codes (MD or QM codes), the :doc:`units <units>` command should be
used to specify *real* or *metal* units. This will ensure the correct
unit conversions between LAMMPS and MDI units. The other code will
also perform similar unit conversions into its preferred units.
LAMMPS can also be used as an MDI driver in other unit choices it
supports, e.g. *lj*, but then no unit conversion is performed.
Related commands
""""""""""""""""
:doc:`mdi plugin <mdi>`, :doc:`mdi engine <mdi>`
Default
"""""""
The default for the optional keywords are virial = no, add = yes,
every = 1, connect = yes.

54
doc/src/fix_reaxff_species.rst
View File

@ -20,7 +20,7 @@ Syntax
* Nfreq = calculate average bond-order every this many timesteps
* filename = name of output file
* zero or more keyword/value pairs may be appended
* keyword = *cutoff* or *element* or *position*
* keyword = *cutoff* or *element* or *position* or *delete*
.. parsed-literal::
@ -31,6 +31,14 @@ Syntax
*position* value = posfreq filepos
posfreq = write position files every this many timestep
filepos = name of position output file
*delete* value = filedel keyword value
filedel = name of delete species output file
keyword = *specieslist* or *masslimit*
*specieslist* value = Nspecies Species1 Species2 ...
Nspecies = number of species in list
*masslimit* value = massmin massmax
massmin = minimum molecular weight of species to delete
massmax = maximum molecular weight of species to delete
Examples
""""""""
@ -40,6 +48,7 @@ Examples
fix 1 all reaxff/species 10 10 100 species.out
fix 1 all reaxff/species 1 2 20 species.out cutoff 1 1 0.40 cutoff 1 2 0.55
fix 1 all reaxff/species 1 100 100 species.out element Au O H position 1000 AuOH.pos
fix 1 all reaxff/species 1 100 100 species.out delete species.del masslimit 0 50
Description
"""""""""""
@ -59,13 +68,18 @@ the first line.
.. warning::
In order to compute averaged data, it is required that there are no
neighbor list rebuilds between the *Nfreq* steps. For that reason, fix
*reaxff/species* may change your neighbor list settings. There will
be a warning message showing the new settings. Having an *Nfreq*
setting that is larger than what is required for correct computation
of the ReaxFF force field interactions can thus lead to incorrect
results. For typical ReaxFF calculations a value of 100 is already
quite large.
neighbor list rebuilds for at least Nrepeat\*Nevery steps preceding
each *Nfreq* step. For that reason, fix *reaxff/species* may
change your neighbor list settings. Reneighboring will occur no
more frequently than every Nrepeat\*Nevery timesteps, and will
occur less frequently if *Nfreq* is not a multiple of
Nrepeat\*Nevery. There will be a warning message showing the new
settings. Having a *Nfreq* setting that is larger than what is
required for correct computation of the ReaxFF force field
interactions, in combination with certain *Nrepeat* and *Nevery*
settings, can thus lead to incorrect results. For typical ReaxFF
calculations, reneighboring only every 100 steps is already quite a
low frequency.
If the filename ends with ".gz", the output file is written in gzipped
format. A gzipped dump file will be about 3x smaller than the text version,
@ -104,6 +118,30 @@ character appears in *filepos*, then one file per snapshot is written
at *posfreq* and the "\*" character is replaced with the timestep
value. For example, AuO.pos.\* becomes AuO.pos.0, AuO.pos.1000, etc.
The optional keyword *delete* enables the periodic removal of
molecules from the system. Criteria for deletion can be either a list
of specific chemical formulae or a range of molecular weights.
Molecules are deleted every *Nfreq* timesteps, and bond connectivity
is determined using the *Nevery* and *Nrepeat* keywords. The
*filedel* argument is the name of the output file that records the
species that are removed from the system. The *specieslist* keyword
permits specific chemical species to be deleted. The *Nspecies*
argument specifies how many species are eligible for deletion and is
followed by a list of chemical formulae, whose strings are compared to
species identified by this fix. For example, "specieslist 2 CO CO2"
deletes molecules that are identified as "CO" and "CO2" in the species
output file. When using the *specieslist* keyword, the *filedel* file
has the following format: the first line lists the chemical formulae
eligible for deletion, and each additional line contains the timestep
on which a molecule deletion occurs and the number of each species
deleted on that timestep. The *masslimit* keyword permits deletion of
molecules with molecular weights between *massmin* and *massmax*.
When using the *masslimit* keyword, each line of the *filedel* file
contains the timestep on which deletions occurs, followed by how many
of each species are deleted (with quantities preceding chemical
formulae). The *specieslist* and *masslimit* keywords cannot both be
used in the same *reaxff/species* fix.
----------
The *Nevery*, *Nrepeat*, and *Nfreq* arguments specify on what

33
doc/src/if.rst
View File

@ -156,27 +156,28 @@ and Boolean operators:
Each A and B is a number or string or a variable reference like $a or
${abc}, or A or B can be another Boolean expression.
If a variable is used it can produce a number when evaluated, like an
:doc:`equal-style variable <variable>`. Or it can produce a string,
like an :doc:`index-style variable <variable>`. For an individual
Boolean operator, A and B must both be numbers or must both be
strings. You cannot compare a number to a string.
Note that all variables used will be substituted for before the
Boolean expression in evaluated. A variable can produce a number,
like an :doc:`equal-style variable <variable>`. Or it can produce a
string, like an :doc:`index-style variable <variable>`.
The Boolean operators "==" and "!=" can operate on a pair or strings
or numbers. They cannot compare a number to a string. All the other
Boolean operations can only operate on numbers.
Expressions are evaluated left to right and have the usual C-style
precedence: the unary logical NOT operator "!" has the highest
precedence, the 4 relational operators "<", "<=", ">", and ">=" are
next; the two remaining relational operators "==" and "!=" are next;
then the logical AND operator "&&"; and finally the logical OR
operator "\|\|" and logical XOR (exclusive or) operator "\|\^" have the
lowest precedence. Parenthesis can be used to group one or more
operator "\|\|" and logical XOR (exclusive or) operator "\|\^" have
the lowest precedence. Parenthesis can be used to group one or more
portions of an expression and/or enforce a different order of
evaluation than what would occur with the default precedence.
When the 6 relational operators (first 6 in list above) compare 2
numbers, they return either a 1.0 or 0.0 depending on whether the
relationship between A and B is TRUE or FALSE. When the 6 relational
operators compare 2 strings, they also return a 1.0 or 0.0 for TRUE or
FALSE, but the comparison is done by the C function strcmp().
relationship between A and B is TRUE or FALSE.
When the 3 logical operators (last 3 in list above) compare 2 numbers,
they also return either a 1.0 or 0.0 depending on whether the
@ -190,8 +191,16 @@ returns 1.0 if its argument is 0.0, else it returns 0.0. The 3
logical operators can only be used to operate on numbers, not on
strings.
The overall Boolean expression produces a TRUE result if the result is
non-zero. If the result is zero, the expression result is FALSE.
The overall Boolean expression produces a TRUE result if the numeric
result is non-zero. If the result is zero, the expression result is
FALSE.
.. note::
If the Boolean expression is a single numeric value with no Boolean
operators, it will be FALSE if the value = 0.0, otherwise TRUE. If
the Boolean expression is a single string, an error message will be
issued.
----------

4
doc/src/kspace_style.rst
View File

@ -129,8 +129,8 @@ Examples
kspace_style pppm 1.0e-4
kspace_style pppm/cg 1.0e-5 1.0e-6
kspace style msm 1.0e-4
kspace style scafacos fmm 1.0e-4
kspace_style msm 1.0e-4
kspace_style scafacos fmm 1.0e-4
kspace_style none
Used in input scripts:

113
doc/src/mdi.rst
View File

@ -8,21 +8,26 @@ Syntax
.. parsed-literal::
mdi mode args
mdi option args
* mode = *engine* or *plugin*
* option = *engine* or *plugin* or *connect* or *exit*
.. parsed-literal::
*engine* args = none
*plugin* args = name keyword value keyword value
*engine* args = zero or more keyword arg pairs
keywords = *elements*
*elements* args = N_1 N_2 ... N_ntypes
N_1,N_2,...N_ntypes = atomic number for each of ntypes LAMMPS atom types
*plugin* args = name keyword value keyword value ...
name = name of plugin library, e.g. lammps means a liblammps.so library will be loaded
keyword/value pairs in any order, some are required, some are optional
keywords = *mdi* or *infile* or *extra* or *command*
*mdi* value = args passed to MDI for driver to operate with plugins
*infile* value = filename the engine will read at start-up
*mdi* value = args passed to MDI for driver to operate with plugins (required)
*infile* value = filename the engine will read at start-up (optional)
*extra* value = aditional command-line args to pass to engine library when loaded
*command* value = a LAMMPS input script command to execute
*command* value = a LAMMPS input script command to execute (required)
*connect* args = none
*exit* args = none
Examples
""""""""
@ -30,26 +35,19 @@ Examples
.. code-block:: LAMMPS
mdi engine
mdi engine elements 13 29
mdi plugin lammps mdi "-role ENGINE -name lammps -method LINK" &
infile in.aimd.engine extra "-log log.aimd.engine.plugin" &
command "run 5"
mdi connect
mdi exit
Description
"""""""""""
This command implements two high-level operations within LAMMPS to use
the `MDI Library
<https://molssi-mdi.github.io/MDI_Library/html/index.html>` for
coupling to other codes in a client/server protocol.
The *engine* mode enables LAMMPS to act as an MDI engine (server),
responding to requests from an MDI driver (client) code.
The *plugin* mode enables LAMMPS to act as an MDI driver (client), and
load the MDI engine (server) code as a library plugin. In this case
the MDI engine is a library plugin. It can also be a stand-alone
code, launched separately from LAMMPS, in which case the mdi plugin
command is not used.
This command implements operations within LAMMPS to use the `MDI
Library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`
for coupling to other codes in a client/server protocol.
See the Howto MDI doc page for a discussion of all the different ways
2 or more codes can interact via MDI.
@ -61,6 +59,22 @@ stand-alone code or as a plugin. The README file in that directory
shows how to launch and couple codes for all the 4 usage modes, and so
they communicate via the MDI library using either MPI or sockets.
The scripts in that directory illustrate the use of all the options
for this command.
The *engine* option enables LAMMPS to act as an MDI engine (server),
responding to requests from an MDI driver (client) code.
The *plugin* option enables LAMMPS to act as an MDI driver (client),
and load the MDI engine (server) code as a library plugin. In this
case the MDI engine is a library plugin. An MDI engine can also be a
stand-alone code, launched separately from LAMMPS, in which case the
mdi plugin command is not used.
The *connect* and *exit* options are only used when LAMMPS is acting
as an MDI driver. As explained below, these options are normally not
needed, except for a specific kind of use case.
----------
The *mdi engine* command is used to make LAMMPS operate as an MDI
@ -100,6 +114,8 @@ commands, which are described further below.
- Send/request charge on each atom (N values)
* - >COORDS or <COORDS
- Send/request coordinates of each atom (3N values)
* - >ELEMENTS
- Send elements (atomic numbers) for each atom (N values)
* - <ENERGY
- Request total energy (potential + kinetic) of the system (1 value)
* - >FORCES or <FORCES
@ -121,11 +137,11 @@ commands, which are described further below.
* - <PE
- Request potential energy of the system (1 value)
* - <STRESS
- Request stress tensor (virial) of the system (6 values)
- Request symmetric stress tensor (virial) of the system (9 values)
* - >TOLERANCE
- Send 4 tolerance parameters for next MD minimization via OPTG command
* - >TYPES or <TYPES
- Send/request the numeric type of each atom (N values)
- Send/request the LAMMPS atom type for each atom (N values)
* - >VELOCITIES or <VELOCITIES
- Send/request the velocity of each atom (3N values)
* - @INIT_MD or @INIT_OPTG
@ -145,9 +161,25 @@ commands, which are described further below.
builds. If the change in atom positions is large (since the
previous >COORDS command), then LAMMPS will do a more expensive
operation to migrate atoms to new processors as needed and
re-neighbor. If the >NATOMS or >TYPES commands have been sent
(since the previous >COORDS command), then LAMMPS assumes the
system is new and re-initializes an entirely new simulation.
re-neighbor. If the >NATOMS or >TYPES or >ELEMENTS commands have
been sent (since the previous >COORDS command), then LAMMPS assumes
the system is new and re-initializes an entirely new simulation.
.. note::
The >TYPES or >ELEMENTS commands are how the MDI driver tells the
LAMMPS engine which LAMMPS atom type to assign to each atom. If
both the MDI driver and the LAMMPS engine are initialized so that
atom type values are consistent in both codes, then the >TYPES
command can be used. If not, the optional *elements* keyword can
be used to specify what element each LAMMPS atom type corresponds
to. This is specified by the atomic number of the element, e.g. 13
for Al. An atomic number must be specified for each of the ntypes
LAMMPS atom types. Ntypes is typically specified via the
create_box command or in the data file read by the read_data
command. In this has been done, the MDI driver can send an
>ELEMENTS command to the LAMMPS driver with the atomic number of
each atom.
The MD and OPTG commands perform an entire MD simulation or energy
minimization (to convergence) with no communication from the driver
@ -270,7 +302,7 @@ The *command* keyword is required. It specifies a LAMMPS input script
command (as a single argument in quotes if it is multiple words).
Once the plugin library is launched, LAMMPS will execute this command.
Other previously-defined commands in the input script, such as the
:doc:`fix mdi/aimd <fix_mdi_aimd>` command, should perform MDI
:doc:`fix mdi/qm <fix_mdi_qm>` command, should perform MDI
communication with the engine, while the specified *command* executes.
Note that if *command* is an :doc:`include <include>` command, then it
could specify a filename with multiple LAMMPS commands.
@ -284,6 +316,31 @@ could specify a filename with multiple LAMMPS commands.
"mdi plugin" command could then load the same library plugin or
a different one if desired.
----------
The *mdi connect* and *mdi exit* commands are only used when LAMMPS is
operating as an MDI driver. And when other LAMMPS command(s) which
send MDI commands and associated data to/from the MDI engine are not
able to initiate and terminate the connection to the engine code.
The only current MDI driver command in LAMMPS is the :doc:`fix mdi/qm
<fix_mdi_qm>` command. If it is only used once in an input script
then it can initiate and terminate the connection. But if it is being
issued multiple times, e.g. in a loop that issues a :doc:`clear
<clear>` command, then it cannot initiate or terminate the connection
multiple times. Instead, the *mdi connect* and *mdi exit* commands
should be used outside the loop to initiate or terminate the connection.
See the examples/mdi/in.series.driver script for an example of how
this is done. The LOOP in that script is reading a series of data
file configurations and passing them to an MDI engine (e.g. quantum
code) for energy and force evaluation. A *clear* command inside the
loop wipes out the current system so a new one can be defined. This
operation also destroys all fixes. So the :doc:`fix mdi/qm
<fix_mdi_qm>` command is issued once per loop iteration. Note that it
includes a "connect no" option which disables the initiate/terminate
logic within that fix.
Restrictions
""""""""""""
@ -304,7 +361,7 @@ supports, e.g. *lj*, but then no unit conversion is performed.
Related commands
""""""""""""""""
:doc:`fix mdi/aimd <fix_mdi_aimd>`
:doc:`fix mdi/qm <fix_mdi_qm>`
Default
"""""""

18
doc/src/package.rst
View File

@ -71,7 +71,7 @@ Syntax
*no_affinity* values = none
*kokkos* args = keyword value ...
zero or more keyword/value pairs may be appended
keywords = *neigh* or *neigh/qeq* or *neigh/thread* or *newton* or *binsize* or *comm* or *comm/exchange* or *comm/forward* *comm/pair/forward* *comm/fix/forward* or *comm/reverse* or *gpu/aware* or *pair/only*
keywords = *neigh* or *neigh/qeq* or *neigh/thread* or *newton* or *binsize* or *comm* or *comm/exchange* or *comm/forward* *comm/pair/forward* *comm/fix/forward* or *comm/reverse* or *comm/pair/reverse* or *gpu/aware* or *pair/only*
*neigh* value = *full* or *half*
full = full neighbor list
half = half neighbor list built in thread-safe manner
@ -96,6 +96,7 @@ Syntax
*comm/pair/forward* value = *no* or *device*
*comm/fix/forward* value = *no* or *device*
*comm/reverse* value = *no* or *host* or *device*
*comm/pair/reverse* value = *no* or *device*
no = perform communication pack/unpack in non-KOKKOS mode
host = perform pack/unpack on host (e.g. with OpenMP threading)
device = perform pack/unpack on device (e.g. on GPU)
@ -500,7 +501,7 @@ rule of thumb may give too large a binsize and the default should be
overridden with a smaller value.
The *comm* and *comm/exchange* and *comm/forward* and *comm/pair/forward*
and *comm/fix/forward* and comm/reverse*
and *comm/fix/forward* and *comm/reverse* and *comm/pair/reverse*
keywords determine whether the host or device performs the packing and
unpacking of data when communicating per-atom data between processors.
"Exchange" communication happens only on timesteps that neighbor lists
@ -521,9 +522,16 @@ packing/unpacking data for the communication. A value of *host* means to
use the host, typically a multi-core CPU, and perform the
packing/unpacking in parallel with threads. A value of *device* means to
use the device, typically a GPU, to perform the packing/unpacking
operation. If a value of *host* is used for the *comm/pair/forward* or
*comm/fix/forward* keyword, it will be automatically be changed to *no*
since these keywords don't support *host* mode.
operation.
For the *comm/pair/forward* or *comm/fix/forward* or *comm/pair/reverse*
keywords, if a value of *host* is used it will be automatically
be changed to *no* since these keywords don't support *host* mode. The
value of *no* will also always be used when running on the CPU, i.e. setting
the value to *device* will have no effect if the pair/fix style is
running on the CPU. For the *comm/fix/forward* or *comm/pair/reverse*
keywords, not all styles support *device* mode and in that case will run
in *no* mode instead.
The optimal choice for these keywords depends on the input script and
the hardware used. The *no* value is useful for verifying that the

91
doc/src/pair_e3b.rst
View File

@ -50,6 +50,12 @@ Examples
pair_style hybrid/overlay e3b 1 lj/cut/tip4p/long 1 2 1 1 0.15 8.5
pair_coeff * * e3b preset 2011
Used in example input script:
.. parsed-literal::
examples/PACKAGES/e3b/in.e3b-tip4p2005
Description
"""""""""""
@ -68,21 +74,27 @@ The *e3b* style computes an \"explicit three-body\" (E3B) potential for water :r
0 & r>R_f\\
\end{cases}
This potential was developed as a water model that includes the three-body cooperativity of hydrogen bonding explicitly.
To use it in this way, it must be applied in conjunction with a conventional two-body water model, through *pair_style hybrid/overlay*.
The three body interactions are split into three types: A, B, and C.
Type A corresponds to anti-cooperative double hydrogen bond donor interactions.
Type B corresponds to the cooperative interaction of molecules that both donate and accept a hydrogen bond.
Type C corresponds to anti-cooperative double hydrogen bond acceptor interactions.
The three-body interactions are smoothly cutoff by the switching function s(r) between Rs and Rc3.
The two-body interactions are designed to correct for the effective many-body interactions implicitly included in the conventional two-body potential.
The two-body interactions are cut off sharply at Rc2, because K3 is typically significantly smaller than K2.
See :ref:`(Kumar 2008) <Kumar>` for more details.
This potential was developed as a water model that includes the
three-body cooperativity of hydrogen bonding explicitly. To use it in
this way, it must be applied in conjunction with a conventional two-body
water model, through pair style :doc:`hybrid/overlay <pair_hybrid>`. The
three body interactions are split into three types: A, B, and C. Type A
corresponds to anti-cooperative double hydrogen bond donor interactions.
Type B corresponds to the cooperative interaction of molecules that both
donate and accept a hydrogen bond. Type C corresponds to
anti-cooperative double hydrogen bond acceptor interactions. The
three-body interactions are smoothly cutoff by the switching function
s(r) between Rs and Rc3. The two-body interactions are designed to
correct for the effective many-body interactions implicitly included in
the conventional two-body potential. The two-body interactions are cut
off sharply at Rc2, because K3 is typically significantly smaller than
K2. See :ref:`(Kumar 2008) <Kumar>` for more details.
Only a single *pair_coeff* command is used with the *e3b* style.
The first two arguments must be \* \*.
The oxygen atom type for the pair style is passed as the only argument to the *pair_style* command, not in the *pair_coeff* command.
The hydrogen atom type is inferred by the ordering of the atoms.
Only a single :doc:`pair_coeff <pair_coeff>` command is used with the
*e3b* style and the first two arguments must be \* \*. The oxygen atom
type for the pair style is passed as the only argument to the
*pair_style* command, not in the *pair_coeff* command. The hydrogen
atom type is inferred from the ordering of the atoms.
.. note::
@ -90,26 +102,41 @@ The hydrogen atom type is inferred by the ordering of the atoms.
Each water molecule must have consecutive IDs with the oxygen first.
This pair style does not test that this criteria is met.
The *pair_coeff* command must have at least one keyword/value pair, as described above.
The *preset* keyword sets the potential parameters to the values used in :ref:`(Tainter 2011) <Tainter2011>` or :ref:`(Tainter 2015) <Tainter2015>`.
To use the water models defined in those references, the *e3b* style should always be used in conjunction with an *lj/cut/tip4p/long* style through *pair_style hybrid/overlay*, as demonstrated in the second example above.
The *preset 2011* option should be used with the :doc:`TIP4P water model <Howto_tip4p>`.
The *preset 2015* option should be used with the :doc:`TIP4P/2005 water model <Howto_tip4p>`.
If the *preset* keyword is used, no other keyword is needed.
Changes to the preset parameters can be made by specifying the *preset* keyword followed by the specific parameter to change, like *Ea*\ .
Note that the other keywords must come after *preset* in the pair_style command.
The *e3b* style can also be used to implement any three-body potential of the same form by specifying all the keywords except *neigh*\ : *Ea*, *Eb*, *Ec*, *E2*, *K3*, *K2*, *Rc3*, *Rc2*, *Rs*, and *bondL*\ .
The keyword *bondL* specifies the intramolecular OH bond length of the water model being used.
This is needed to include H atoms that are within the cutoff even when the attached oxygen atom is not.
The *pair_coeff* command must have at least one keyword/value pair, as
described above. The *preset* keyword sets the potential parameters to
the values used in :ref:`(Tainter 2011) <Tainter2011>` or
:ref:`(Tainter 2015) <Tainter2015>`. To use the water models defined in
those references, the *e3b* style should always be used in conjunction
with an *lj/cut/tip4p/long* style through *pair_style hybrid/overlay*,
as demonstrated in the second example above. The *preset 2011* option
should be used with the :doc:`TIP4P water model <Howto_tip4p>`. The
*preset 2015* option should be used with the :doc:`TIP4P/2005 water
model <Howto_tip4p>`. If the *preset* keyword is used, no other keyword
is needed. Changes to the preset parameters can be made by specifying
the *preset* keyword followed by the specific parameter to change, like
*Ea*\ . Note that the other keywords must come after *preset* in the
pair_style command. The *e3b* style can also be used to implement any
three-body potential of the same form by specifying all the keywords
except *neigh*\ : *Ea*, *Eb*, *Ec*, *E2*, *K3*, *K2*, *Rc3*, *Rc2*,
*Rs*, and *bondL*\ . The keyword *bondL* specifies the intramolecular
OH bond length of the water model being used. This is needed to include
H atoms that are within the cutoff even when the attached oxygen atom is
not.
This pair style allocates arrays sized according to the number of pairwise interactions within Rc3.
To do this it needs an estimate for the number of water molecules within Rc3 of an oxygen atom.
This estimate defaults to 10 and can be changed using the *neigh* keyword, which takes an integer as an argument.
If the neigh setting is too small, the simulation will fail with the error "neigh is too small".
If the neigh setting is too large, the pair style will use more memory than necessary.
This pair style allocates arrays sized according to the number of
pairwise interactions within Rc3. To do this it needs an estimate for
the number of water molecules within Rc3 of an oxygen atom. This
estimate defaults to 10 and can be changed using the *neigh* keyword,
which takes an integer as an argument. If the neigh setting is too
small, the simulation will fail with the error "neigh is too small". If
the neigh setting is too large, the pair style will use more memory than
necessary.
This pair style tallies a breakdown of the total E3B potential energy into sub-categories, which can be accessed via the :doc:`compute pair <compute_pair>` command as a vector of values of length 4.
The 4 values correspond to the terms in the first equation above: the E2 term, the Ea term, the Eb term, and the Ec term.
This pair style tallies a breakdown of the total E3B potential energy
into sub-categories, which can be accessed via the :doc:`compute pair
<compute_pair>` command as a vector of values of length 4. The 4 values
correspond to the terms in the first equation above: the E2 term, the Ea
term, the Eb term, and the Ec term.
See the examples/PACKAGES/e3b directory for a complete example script.

9
doc/src/pair_meam.rst
View File

@ -1,8 +1,11 @@
.. index:: pair_style meam
.. index:: pair_style meam/kk
pair_style meam command
=========================
Accelerator Variants: *meam/kk*
Syntax
""""""
@ -347,6 +350,12 @@ Most published MEAM parameter sets use the default values *attrac* = *repulse* =
Setting *repuls* = *attrac* = *delta* corresponds to the form used in several
recent published MEAM parameter sets, such as :ref:`(Valone) <Valone>`
----------
.. include:: accel_styles.rst
----------
.. note::
The default form of the *erose* expression in LAMMPS was corrected

141
doc/src/pair_sw.rst
View File

@ -24,13 +24,16 @@ Syntax
pair_style style keyword values
* style = *sw* or *sw/mod*
* keyword = *maxdelcs*
* keyword = *maxdelcs* or *threebody*
.. parsed-literal::
*maxdelcs* value = delta1 delta2 (optional)
*maxdelcs* value = delta1 delta2 (optional, sw/mod only)
delta1 = The minimum thershold for the variation of cosine of three-body angle
delta2 = The maximum threshold for the variation of cosine of three-body angle
*threebody* value = *on* or *off* (optional, sw only)
on (default) = Compute both the three-body and two-body terms of the potential
off = Compute only the two-body term of the potential
Examples
""""""""
@ -44,6 +47,11 @@ Examples
pair_style sw/mod maxdelcs 0.25 0.35
pair_coeff * * tmd.sw.mod Mo S S
pair_style hybrid sw threebody on sw threebody off
pair_coeff * * sw 1 mW_xL.sw mW NULL
pair_coeff 1 2 sw 2 mW_xL.sw mW xL
pair_coeff 2 2 sw 2 mW_xL.sw mW xL
Description
"""""""""""
@ -68,22 +76,25 @@ three-body term. The summations in the formula are over all neighbors J
and K of atom I within a cutoff distance :math:`a `\sigma`.
The *sw/mod* style is designed for simulations of materials when
distinguishing three-body angles are necessary, such as borophene
and transition metal dichalcogenides, which cannot be described
by the original code for the Stillinger-Weber potential.
For instance, there are several types of angles around each Mo atom in `MoS_2`,
and some unnecessary angle types should be excluded in the three-body interaction.
Such exclusion may be realized by selecting proper angle types directly.
The exclusion of unnecessary angles is achieved here by the cut-off function (`f_C(\delta)`),
which induces only minimum modifications for LAMMPS.
distinguishing three-body angles are necessary, such as borophene and
transition metal dichalcogenides, which cannot be described by the
original code for the Stillinger-Weber potential. For instance, there
are several types of angles around each Mo atom in `MoS_2`, and some
unnecessary angle types should be excluded in the three-body
interaction. Such exclusion may be realized by selecting proper angle
types directly. The exclusion of unnecessary angles is achieved here by
the cut-off function (`f_C(\delta)`), which induces only minimum
modifications for LAMMPS.
Validation, benchmark tests, and applications of the *sw/mod* style
can be found in :ref:`(Jiang2) <Jiang2>` and :ref:`(Jiang3) <Jiang3>`.
The *sw/mod* style computes the energy E of a system of atoms, whose potential
function is mostly the same as the Stillinger-Weber potential. The only modification
is in the three-body term, where the value of :math:`\delta = \cos \theta_{ijk} - \cos \theta_{0ijk}`
used in the original energy and force expression is scaled by a switching factor :math:`f_C(\delta)`:
The *sw/mod* style computes the energy E of a system of atoms, whose
potential function is mostly the same as the Stillinger-Weber
potential. The only modification is in the three-body term, where the
value of :math:`\delta = \cos \theta_{ijk} - \cos \theta_{0ijk}` used in
the original energy and force expression is scaled by a switching factor
:math:`f_C(\delta)`:
.. math::
@ -94,28 +105,46 @@ used in the original energy and force expression is scaled by a switching factor
0 & \left| \delta \right| > \delta_2
\end{array} \right. \\
This cut-off function decreases smoothly from 1 to 0 over the range :math:`[\delta_1, \delta_2]`.
This smoothly turns off the energy and force contributions for :math:`\left| \delta \right| > \delta_2`.
It is suggested that :math:`\delta 1` and :math:`\delta_2` to be the value around
:math:`0.5 \left| \cos \theta_1 - \cos \theta_2 \right|`, with
:math:`\theta_1` and :math:`\theta_2` as the different types of angles around an atom.
For borophene and transition metal dichalcogenides, :math:`\delta_1 = 0.25` and :math:`\delta_2 = 0.35`.
This value enables the cut-off function to exclude unnecessary angles in the three-body SW terms.
This cut-off function decreases smoothly from 1 to 0 over the range
:math:`[\delta_1, \delta_2]`. This smoothly turns off the energy and
force contributions for :math:`\left| \delta \right| > \delta_2`. It is
suggested that :math:`\delta 1` and :math:`\delta_2` to be the value
around :math:`0.5 \left| \cos \theta_1 - \cos \theta_2 \right|`, with
:math:`\theta_1` and :math:`\theta_2` as the different types of angles
around an atom. For borophene and transition metal dichalcogenides,
:math:`\delta_1 = 0.25` and :math:`\delta_2 = 0.35`. This value enables
the cut-off function to exclude unnecessary angles in the three-body SW
terms.
.. note::
The cut-off function is just to be used as a technique to exclude some unnecessary angles,
and it has no physical meaning. It should be noted that the force and potential are inconsistent
with each other in the decaying range of the cut-off function, as the angle dependence for the
cut-off function is not implemented in the force (first derivation of potential).
However, the angle variation is much smaller than the given threshold value for actual simulations,
so the inconsistency between potential and force can be neglected in actual simulations.
The cut-off function is just to be used as a technique to exclude
some unnecessary angles, and it has no physical meaning. It should be
noted that the force and potential are inconsistent with each other
in the decaying range of the cut-off function, as the angle
dependence for the cut-off function is not implemented in the force
(first derivation of potential). However, the angle variation is
much smaller than the given threshold value for actual simulations,
so the inconsistency between potential and force can be neglected in
actual simulations.
Only a single pair_coeff command is used with the *sw* and *sw/mod* styles
which specifies a Stillinger-Weber potential file with parameters for all
needed elements. These are mapped to LAMMPS atom types by specifying
N additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:
The *threebody* keyword is optional and determines whether or not the
three-body term of the potential is calculated. The default value is
"on" and it is only available for the plain *sw* pair style variants,
but not available for the *sw/mod* and :doc:`sw/angle/table
<pair_sw_angle_table>` pair style variants. To turn off the threebody
contributions all :math:`\lambda_{ijk}` parameters from the potential
file are forcibly set to 0. In addition the pair style implementation
may employ code optimizations for the *threebody off* setting that can
result in significant speedups versus the default. These code optimizations
are currently only available for the MANYBODY and OPENMP packages.
Only a single pair_coeff command is used with the *sw* and *sw/mod*
styles which specifies a Stillinger-Weber potential file with parameters
for all needed elements, except for when the *threebody off* setting is
used (see note below). These are mapped to LAMMPS atom types by
specifying N additional arguments after the filename in the pair_coeff
command, where N is the number of LAMMPS atom types:
* filename
* N element names = mapping of SW elements to atom types
@ -130,16 +159,22 @@ pair_coeff command:
.. code-block:: LAMMPS
pair_style sw
pair_coeff * * SiC.sw Si Si Si C
The first 2 arguments must be \* \* so as to span all LAMMPS atom types.
The first three Si arguments map LAMMPS atom types 1,2,3 to the Si
element in the SW file. The final C argument maps LAMMPS atom type 4
to the C element in the SW file. If a mapping value is specified as
NULL, the mapping is not performed. This can be used when a *sw*
The first three Si arguments map LAMMPS atom types 1, 2, and 3 to the Si
element in the SW file. The final C argument maps LAMMPS atom type 4 to
the C element in the SW file. If an argument value is specified as
NULL, the mapping is not performed. This can be used when an *sw*
potential is used as part of the *hybrid* pair style. The NULL values
are placeholders for atom types that will be used with other
potentials.
are placeholders for atom types that will be used with other potentials.
.. note::
When the *threebody off* keyword is used, multiple pair_coeff commands may
be used to specific the pairs of atoms which don't require three-body term.
In these cases, the first 2 arguments are not required to be \* \*.
Stillinger-Weber files in the *potentials* directory of the LAMMPS
distribution have a ".sw" suffix. Lines that are not blank or
@ -243,30 +278,39 @@ described above from values in the potential file.
This pair style does not support the :doc:`pair_modify <pair_modify>`
shift, table, and tail options.
This pair style does not write its information to :doc:`binary restart files <restart>`, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.
This pair style does not write its information to :doc:`binary restart
files <restart>`, since it is stored in potential files. Thus, you need
to re-specify the pair_style and pair_coeff commands in an input script
that reads a restart file.
This pair style can only be used via the *pair* keyword of the
:doc:`run_style respa <run_style>` command. It does not support the
*inner*, *middle*, *outer* keywords.
The single() function of the *sw* pair style is only enabled and
supported for the case of the *threebody off* setting.
----------
Restrictions
""""""""""""
This pair style is part of the MANYBODY package. It is only enabled
if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
This pair style is part of the MANYBODY package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
This pair style requires the :doc:`newton <newton>` setting to be "on"
for pair interactions.
The Stillinger-Weber potential files provided with LAMMPS (see the
potentials directory) are parameterized for metal :doc:`units <units>`.
You can use the SW potential with any LAMMPS units, but you would need
to create your own SW potential file with coefficients listed in the
appropriate units if your simulation does not use "metal" units.
You can use the sw or sw/mod pair styles with any LAMMPS units, but you
would need to create your own SW potential file with coefficients listed
in the appropriate units if your simulation does not use "metal" units.
If the potential file contains a 'UNITS:' metadata tag in the first line
of the potential file, then LAMMPS can convert it transparently between
"metal" and "real" units.
Related commands
""""""""""""""""
@ -276,8 +320,9 @@ Related commands
Default
"""""""
The default values for the *maxdelcs* setting of the *sw/mod* pair
style are *delta1* = 0.25 and *delta2* = 0.35`.
The default value for the *threebody* setting of the "sw" pair style is
"on", the default values for the "*maxdelcs* setting of the *sw/mod*
pair style are *delta1* = 0.25 and *delta2* = 0.35`.
----------

7
doc/src/pair_sw_angle_table.rst
View File

@ -23,9 +23,9 @@ Examples
Used in example input script:
.. parsed-literal::
.. parsed-literal::
examples/PACKAGES/manybody_table/in.spce_sw
examples/PACKAGES/manybody_table/in.spce_sw
Description
@ -296,7 +296,8 @@ for pair interactions.
Related commands
""""""""""""""""
:doc:`pair_coeff <pair_coeff>`, :doc:`pair_style sw <pair_sw>`, :doc:`pair_style threebody/table <pair_threebody_table>`
:doc:`pair_coeff <pair_coeff>`, :doc:`pair_style sw <pair_sw>`,
:doc:`pair_style threebody/table <pair_threebody_table>`
----------

6
doc/src/pair_threebody_table.rst
View File

@ -27,10 +27,10 @@ Examples
Used in example input scripts:
.. parsed-literal::
.. parsed-literal::
examples/PACKAGES/manybody_table/in.spce
examples/PACKAGES/manybody_table/in.spce2
examples/PACKAGES/manybody_table/in.spce
examples/PACKAGES/manybody_table/in.spce2
Description
"""""""""""

4
doc/src/read_data.rst
View File

@ -56,7 +56,7 @@ Examples
read_data ../run7/data.polymer.gz
read_data data.protein fix mycmap crossterm CMAP
read_data data.water add append offset 3 1 1 1 1 shift 0.0 0.0 50.0
read_data data.water add merge 1 group solvent
read_data data.water add merge group solvent
Description
"""""""""""
@ -622,6 +622,8 @@ of analysis.
- atom-ID molecule-ID atom-type x y z
* - charge
- atom-ID atom-type q x y z
* - dielectric
- atom-ID atom-type q x y z normx normy normz area ed em epsilon curvature
* - dipole
- atom-ID atom-type q x y z mux muy muz
* - dpd

35
doc/src/read_dump.rst
View File

@ -24,12 +24,13 @@ Syntax
*fx*,\ *fy*,\ *fz* = force components
* zero or more keyword/value pairs may be appended
* keyword = *nfile* or *box* or *replace* or *purge* or *trim* or *add* or *label* or *scaled* or *wrapped* or *format*
* keyword = *nfile* or *box* or *timestep* or *replace* or *purge* or *trim* or *add* or *label* or *scaled* or *wrapped* or *format*
.. parsed-literal::
*nfile* value = Nfiles = how many parallel dump files exist
*box* value = *yes* or *no* = replace simulation box with dump box
*timestep* value = *yes* or *no* = reset simulation timestep with dump timestep
*replace* value = *yes* or *no* = overwrite atoms with dump atoms
*purge* value = *yes* or *no* = delete all atoms before adding dump atoms
*trim* value = *yes* or *no* = trim atoms not in dump snapshot
@ -60,6 +61,7 @@ Examples
read_dump dump.dcd 0 x y z box yes format molfile dcd
read_dump dump.file 1000 x y z vx vy vz box yes format molfile lammpstrj /usr/local/lib/vmd/plugins/LINUXAMD64/plugins/molfile
read_dump dump.file 5000 x y vx vy trim yes
read_dump dump.file 5000 x y vx vy add yes box no timestep no
read_dump ../run7/dump.file.gz 10000 x y z box yes
read_dump dump.xyz 10 x y z box no format molfile xyz ../plugins
read_dump dump.dcd 0 x y z format molfile dcd
@ -71,9 +73,9 @@ Description
"""""""""""
Read atom information from a dump file to overwrite the current atom
coordinates, and optionally the atom velocities and image flags and
the simulation box dimensions. This is useful for restarting a run
from a particular snapshot in a dump file. See the
coordinates, and optionally the atom velocities and image flags, the
simulation timestep, and the simulation box dimensions. This is useful
for restarting a run from a particular snapshot in a dump file. See the
:doc:`read_restart <read_restart>` and :doc:`read_data <read_data>`
commands for alternative methods to do this. Also see the
:doc:`rerun <rerun>` command for a means of reading multiple snapshots
@ -89,9 +91,9 @@ Also note that reading per-atom information from a dump snapshot is
limited to the atom coordinates, velocities and image flags, as
explained below. Other atom properties, which may be necessary to run
a valid simulation, such as atom charge, or bond topology information
for a molecular system, are not read from (or even contained in) dump
files. Thus this auxiliary information should be defined in the usual
way, e.g. in a data file read in by a :doc:`read_data <read_data>`
for a molecular system, are not read from (or may not even be contained
in) dump files. Thus this auxiliary information should be defined in
the usual way, e.g. in a data file read in by a :doc:`read_data <read_data>`
command, before using the read_dump command, or by the :doc:`set <set>`
command, after the dump snapshot is read.
@ -165,11 +167,10 @@ variable *ntimestep*:
uint64_t ntimestep 5*scalar
(0) 0 50 100 150 200
Note that the *xyz*
and *molfile* formats do not store the timestep. For these formats,
timesteps are numbered logically, in a sequential manner, starting
from 0. Thus to access the 10th snapshot in an *xyz* or *mofile*
formatted dump file, use *Nstep* = 9.
Note that the *xyz* and *molfile* formats do not store the timestep.
For these formats, timesteps are numbered logically, in a sequential
manner, starting from 0. Thus to access the 10th snapshot in an *xyz*
or *mofile* formatted dump file, use *Nstep* = 9.
The dimensions of the simulation box for the selected snapshot are
also read; see the *box* keyword discussion below. For the *native*
@ -266,8 +267,10 @@ for how this is done, determined by the specified fields and optional
keywords.
The timestep of the snapshot becomes the current timestep for the
simulation. See the :doc:`reset_timestep <reset_timestep>` command if
you wish to change this after the dump snapshot is read.
simulation unless the *timestep* keyword is specified with a *no* value
(default setting is *yes*). See the :doc:`reset_timestep <reset_timestep>`
command if you wish to change this to a different value after the dump
snapshot is read.
If the *box* keyword is specified with a *yes* value, then the current
simulation box dimensions are replaced by the dump snapshot box
@ -391,7 +394,7 @@ Related commands
Default
"""""""
The option defaults are box = yes, replace = yes, purge = no, trim =
no, add = no, scaled = no, wrapped = yes, and format = native.
The option defaults are box = yes, timestep = yes, replace = yes, purge = no,
trim = no, add = no, scaled = no, wrapped = yes, and format = native.
.. _vmd: http://www.ks.uiuc.edu/Research/vmd

102
doc/src/read_restart.rst
View File

@ -11,7 +11,6 @@ Syntax
read_restart file flag
* file = name of binary restart file to read in
* flag = remap (optional)
Examples
""""""""
@ -19,44 +18,40 @@ Examples
.. code-block:: LAMMPS
read_restart save.10000
read_restart save.10000 remap
read_restart restart.*
read_restart restart.*.mpiio
read_restart poly.*.% remap
Description
"""""""""""
Read in a previously saved system configuration from a restart file.
This allows continuation of a previous run. Details about what
information is stored (and not stored) in a restart file is given
below. Basically this operation will re-create the simulation box
with all its atoms and their attributes as well as some related global
settings, at the point in time it was written to the restart file by a
previous simulation. The simulation box will be partitioned into a
regular 3d grid of rectangular bricks, one per processor, based on the
number of processors in the current simulation and the settings of the
information is stored (and not stored) in a restart file is given below.
Basically this operation will re-create the simulation box with all its
atoms and their attributes as well as some related global settings, at
the point in time it was written to the restart file by a previous
simulation. The simulation box will be partitioned into a regular 3d
grid of rectangular bricks, one per processor, based on the number of
processors in the current simulation and the settings of the
:doc:`processors <processors>` command. The partitioning can later be
changed by the :doc:`balance <balance>` or :doc:`fix balance <fix_balance>` commands.
.. note::
Normally, restart files are written by the
:doc:`restart <restart>` or :doc:`write_restart <write_restart>` commands
so that all atoms in the restart file are inside the simulation box.
If this is not the case, the read_restart command will print an error
that atoms were "lost" when the file is read. This error should be
reported to the LAMMPS developers so the invalid writing of the
restart file can be fixed. If you still wish to use the restart file,
the optional *remap* flag can be appended to the read_restart command.
This should avoid the error, by explicitly remapping each atom back
into the simulation box, updating image flags for the atom
appropriately.
changed by the :doc:`balance <balance>` or :doc:`fix balance
<fix_balance>` commands.
Restart files are saved in binary format to enable exact restarts,
meaning that the trajectories of a restarted run will precisely match
those produced by the original run had it continued on.
The binary restart file format was not designed with backward, forward,
or cross-platform compatibility in mind, so the files are only expected
to be read correctly by the same LAMMPS executable on the same platform.
Changes to the architecture, compilation settings, or LAMMPS version can
render a restart file unreadable or it may read the data incorrectly.
If you want a more portable format, you can use the data file format as
created by the :doc:`write_data <write_data>` command. Binary restart
files can also be converted into a data file from the command line by
the LAMMPS executable that wrote them using the :ref:`-restart2data
<restart2data>` command line flag.
Several things can prevent exact restarts due to round-off effects, in
which case the trajectories in the 2 runs will slowly diverge. These
include running on a different number of processors or changing
@ -65,7 +60,8 @@ certain settings such as those set by the :doc:`newton <newton>` or
these cases.
Certain fixes will not restart exactly, though they should provide
statistically similar results. These include :doc:`fix shake <fix_shake>` and :doc:`fix langevin <fix_langevin>`.
statistically similar results. These include :doc:`fix shake
<fix_shake>` and :doc:`fix langevin <fix_langevin>`.
Certain pair styles will not restart exactly, though they should
provide statistically similar results. This is because the forces
@ -81,18 +77,19 @@ produced the restart file, it could be a LAMMPS bug, so consider
:doc:`reporting it <Errors_bugs>` if you think the behavior is a bug.
Because restart files are binary, they may not be portable to other
machines. In this case, you can use the :doc:`-restart command-line switch <Run_options>` to convert a restart file to a data file.
machines. In this case, you can use the :doc:`-restart command-line
switch <Run_options>` to convert a restart file to a data file.
Similar to how restart files are written (see the
:doc:`write_restart <write_restart>` and :doc:`restart <restart>`
commands), the restart filename can contain two wild-card characters.
If a "\*" appears in the filename, the directory is searched for all
filenames that match the pattern where "\*" is replaced with a timestep
value. The file with the largest timestep value is read in. Thus,
this effectively means, read the latest restart file. It's useful if
you want your script to continue a run from where it left off. See
the :doc:`run <run>` command and its "upto" option for how to specify
the run command so it does not need to be changed either.
Similar to how restart files are written (see the :doc:`write_restart
<write_restart>` and :doc:`restart <restart>` commands), the restart
filename can contain two wild-card characters. If a "\*" appears in the
filename, the directory is searched for all filenames that match the
pattern where "\*" is replaced with a timestep value. The file with the
largest timestep value is read in. Thus, this effectively means, read
the latest restart file. It's useful if you want your script to
continue a run from where it left off. See the :doc:`run <run>` command
and its "upto" option for how to specify the run command so it does not
need to be changed either.
If a "%" character appears in the restart filename, LAMMPS expects a
set of multiple files to exist. The :doc:`restart <restart>` and
@ -222,17 +219,17 @@ its calculations in a consistent manner.
.. note::
There are a handful of commands which can be used before or
between runs which may require a system initialization. Examples
include the "balance", "displace_atoms", "delete_atoms", "set" (some
options), and "velocity" (some options) commands. This is because
they can migrate atoms to new processors. Thus they will also discard
unused "state" information from fixes. You will know the discard has
There are a handful of commands which can be used before or between
runs which may require a system initialization. Examples include the
"balance", "displace_atoms", "delete_atoms", "set" (some options),
and "velocity" (some options) commands. This is because they can
migrate atoms to new processors. Thus they will also discard unused
"state" information from fixes. You will know the discard has
occurred because a list of discarded fixes will be printed to the
screen and log file, as explained above. This means that if you wish
to retain that info in a restarted run, you must re-specify the
relevant fixes and computes (which create fixes) before those commands
are used.
relevant fixes and computes (which create fixes) before those
commands are used.
Some pair styles, like the :doc:`granular pair styles <pair_gran>`, also
use a fix to store "state" information that persists from timestep to
@ -245,18 +242,19 @@ LAMMPS allows bond interactions (angle, etc) to be turned off or
deleted in various ways, which can affect how their info is stored in
a restart file.
If bonds (angles, etc) have been turned off by the :doc:`fix shake <fix_shake>` or :doc:`delete_bonds <delete_bonds>` command,
their info will be written to a restart file as if they are turned on.
This means they will need to be turned off again in a new run after
the restart file is read.
If bonds (angles, etc) have been turned off by the :doc:`fix shake
<fix_shake>` or :doc:`delete_bonds <delete_bonds>` command, their info
will be written to a restart file as if they are turned on. This means
they will need to be turned off again in a new run after the restart
file is read.
Bonds that are broken (e.g. by a bond-breaking potential) are written
to the restart file as broken bonds with a type of 0. Thus these
bonds will still be broken when the restart file is read.
Bonds that have been broken by the :doc:`fix bond/break <fix_bond_break>` command have disappeared from the
system. No information about these bonds is written to the restart
file.
Bonds that have been broken by the :doc:`fix bond/break
<fix_bond_break>` command have disappeared from the system. No
information about these bonds is written to the restart file.
----------

14
doc/utils/sphinx-config/false_positives.txt
View File

@ -120,6 +120,7 @@ Antonelli
api
Apoorva
Appl
apptainer
Apu
arallel
arccos
@ -372,6 +373,7 @@ Caltech
Camilloni
Camiloni
Campana
Cangi
Cao
Capolungo
Caro
@ -2368,7 +2370,11 @@ nopreliminary
Nord
norder
Nordlund
noremap
normals
normx
normy
normz
Noskov
noslip
noticable
@ -2676,6 +2682,7 @@ polyhedra
Polym
polymorphism
popen
Popoola
Popov
popstore
Poresag
@ -2819,6 +2826,7 @@ radians
Rafferty
rahman
Rahman
Rajamanickam
Ralf
Raman
ramped
@ -3671,13 +3679,19 @@ vx
Vx
vxcm
vxmu
vxx
vxy
vxz
vy
Vy
vycm
vyy
vyz
vz
Vz
vzcm
vzi
vzz
Waals
Wadley
wallstyle

182
examples/COUPLE/fortran2/LAMMPS-wrapper.cpp
View File

@ -12,8 +12,8 @@
------------------------------------------------------------------------- */
/* ------------------------------------------------------------------------
Contributing author: Karl D. Hammond <karlh@ugcs.caltech.edu>
University of Tennessee, Knoxville (USA), 2012
Contributing author: Karl D. Hammond <hammondkd@missouri.edu>
University of Missouri (USA), 2012
------------------------------------------------------------------------- */
/* This is set of "wrapper" functions to assist LAMMPS.F90, which itself
@ -23,6 +23,7 @@
#include <mpi.h>
#include "LAMMPS-wrapper.h"
#define LAMMPS_LIB_MPI 1
#include <library.h>
#include <lammps.h>
#include <atom.h>
@ -56,181 +57,40 @@ void lammps_error_all (void *ptr, const char *file, int line, const char *str)
int lammps_extract_compute_vectorsize (void *ptr, char *id, int style)
{
class LAMMPS *lmp = (class LAMMPS *) ptr;
int icompute = lmp->modify->find_compute(id);
if ( icompute < 0 ) return 0;
class Compute *compute = lmp->modify->compute[icompute];
if ( style == 0 )
{
if ( !compute->vector_flag )
return 0;
else
return compute->size_vector;
}
else if ( style == 1 )
{
return lammps_get_natoms (ptr);
}
else if ( style == 2 )
{
if ( !compute->local_flag )
return 0;
else
return compute->size_local_rows;
}
else
return 0;
int *size;
size = (int *) lammps_extract_compute(ptr, id, style, LMP_SIZE_VECTOR);
if (size) return *size;
return 0;
}
void lammps_extract_compute_arraysize (void *ptr, char *id, int style,
int *nrows, int *ncols)
{
class LAMMPS *lmp = (class LAMMPS *) ptr;
int icompute = lmp->modify->find_compute(id);
if ( icompute < 0 )
{
*nrows = 0;
*ncols = 0;
}
class Compute *compute = lmp->modify->compute[icompute];
if ( style == 0 )
{
if ( !compute->array_flag )
{
*nrows = 0;
*ncols = 0;
}
else
{
*nrows = compute->size_array_rows;
*ncols = compute->size_array_cols;
}
}
else if ( style == 1 )
{
if ( !compute->peratom_flag )
{
*nrows = 0;
*ncols = 0;
}
else
{
*nrows = lammps_get_natoms (ptr);
*ncols = compute->size_peratom_cols;
}
}
else if ( style == 2 )
{
if ( !compute->local_flag )
{
*nrows = 0;
*ncols = 0;
}
else
{
*nrows = compute->size_local_rows;
*ncols = compute->size_local_cols;
}
}
else
{
*nrows = 0;
*ncols = 0;
}
int *tmp;
tmp = (int *) lammps_extract_compute(ptr, id, style, LMP_SIZE_ROWS);
if (tmp) *nrows = *tmp;
tmp = (int *) lammps_extract_compute(ptr, id, style, LMP_SIZE_COLS);
if (tmp) *ncols = *tmp;
return;
}
int lammps_extract_fix_vectorsize (void *ptr, char *id, int style)
{
class LAMMPS *lmp = (class LAMMPS *) ptr;
int ifix = lmp->modify->find_fix(id);
if ( ifix < 0 ) return 0;
class Fix *fix = lmp->modify->fix[ifix];
if ( style == 0 )
{
if ( !fix->vector_flag )
return 0;
else
return fix->size_vector;
}
else if ( style == 1 )
{
return lammps_get_natoms (ptr);
}
else if ( style == 2 )
{
if ( !fix->local_flag )
return 0;
else
return fix->size_local_rows;
}
else
return 0;
int *size;
size = (int *) lammps_extract_fix(ptr, id, style, LMP_SIZE_VECTOR, 0, 0);
if (size) return *size;
return 0;
}
void lammps_extract_fix_arraysize (void *ptr, char *id, int style,
int *nrows, int *ncols)
{
class LAMMPS *lmp = (class LAMMPS *) ptr;
int ifix = lmp->modify->find_fix(id);
if ( ifix < 0 )
{
*nrows = 0;
*ncols = 0;
}
class Fix *fix = lmp->modify->fix[ifix];
if ( style == 0 )
{
if ( !fix->array_flag )
{
*nrows = 0;
*ncols = 0;
}
else
{
*nrows = fix->size_array_rows;
*ncols = fix->size_array_cols;
}
}
else if ( style == 1 )
{
if ( !fix->peratom_flag )
{
*nrows = 0;
*ncols = 0;
}
else
{
*nrows = lammps_get_natoms (ptr);
*ncols = fix->size_peratom_cols;
}
}
else if ( style == 2 )
{
if ( !fix->local_flag )
{
*nrows = 0;
*ncols = 0;
}
else
{
*nrows = fix->size_local_rows;
*ncols = fix->size_local_cols;
}
}
else
{
*nrows = 0;
*ncols = 0;
}
int *tmp;
tmp = (int *) lammps_extract_fix(ptr, id, style, LMP_SIZE_ROWS, 0, 0);
if (tmp) *nrows = *tmp;
tmp = (int *) lammps_extract_fix(ptr, id, style, LMP_SIZE_COLS, 0, 0);
if (tmp) *ncols = *tmp;
return;
}
/* vim: set ts=3 sts=3 expandtab: */

4
examples/COUPLE/fortran2/LAMMPS-wrapper.h
View File

@ -12,8 +12,8 @@
------------------------------------------------------------------------- */
/* ------------------------------------------------------------------------
Contributing author: Karl D. Hammond <karlh@ugcs.caltech.edu>
University of Tennessee, Knoxville (USA), 2012
Contributing author: Karl D. Hammond <hammondkd@missouri.edu>
University of Missouri (USA), 2012
------------------------------------------------------------------------- */
/* This is set of "wrapper" functions to assist LAMMPS.F90, which itself

4
examples/COUPLE/fortran2/LAMMPS.F90
View File

@ -1292,7 +1292,7 @@ contains !! Wrapper functions local to this module {{{1
Cname = string2Cstring (name)
Ccount = size(data) / natoms
if ( Ccount /= 1 .and. Ccount /= 3 ) &
call lammps_error_all (ptr, FLERR, 'lammps_gather_atoms requires&
call lammps_error_all (ptr, FLERR, 'lammps_scatter_atoms requires&
& count to be either 1 or 3')
Fdata = data
Cdata = C_loc (Fdata(1))
@ -1355,7 +1355,7 @@ contains !! Wrapper functions local to this module {{{1
Cname = string2Cstring (name)
Ccount = size(data) / ndata
if ( Ccount /= 1 .and. Ccount /= 3 ) &
call lammps_error_all (ptr, FLERR, 'lammps_gather_atoms requires&
call lammps_error_all (ptr, FLERR, 'lammps_scatter_atoms requires&
& count to be either 1 or 3')
Fdata = data
Cdata = C_loc (Fdata(1))

2
examples/COUPLE/fortran2/Makefile
View File

@ -14,7 +14,7 @@ CXXLIB = -lstdc++ # replace with your C++ runtime libs
# Flags for Fortran compiler, C++ compiler, and C preprocessor, respectively
FFLAGS = -O2 -fPIC
CXXFLAGS = -O2 -fPIC
CPPFLAGS = -DOMPI_SKIP_MPICXX=1 -DMPICH_SKIP_MPICXX -DLAMMPS_LIB_MPI
CPPFLAGS = -DOMPI_SKIP_MPICXX=1 -DMPICH_SKIP_MPICXX
all : liblammps_fortran.a liblammps_fortran.so

5
examples/COUPLE/fortran2/README
View File

@ -11,9 +11,8 @@ This interface was created by Karl Hammond who you can contact with
questions:
Karl D. Hammond
University of Tennessee, Knoxville
karlh at ugcs.caltech.edu
karlh at utk.edu
University of Missouri
hammondkd at missouri.edu
-------------------------------------

182
examples/COUPLE/fortran_dftb/LAMMPS-wrapper.cpp
View File

@ -12,8 +12,8 @@
------------------------------------------------------------------------- */
/* ------------------------------------------------------------------------
Contributing author: Karl D. Hammond <karlh@ugcs.caltech.edu>
University of Tennessee, Knoxville (USA), 2012
Contributing author: Karl D. Hammond <hammondkd@missouri.edu>
University of Missouri (USA), 2012
------------------------------------------------------------------------- */
/* This is set of "wrapper" functions to assist LAMMPS.F90, which itself
@ -23,6 +23,7 @@
#include <mpi.h>
#include "LAMMPS-wrapper.h"
#define LAMMPS_LIB_MPI 1
#include <library.h>
#include <lammps.h>
#include <atom.h>
@ -56,181 +57,40 @@ void lammps_error_all (void *ptr, const char *file, int line, const char *str)
int lammps_extract_compute_vectorsize (void *ptr, char *id, int style)
{
class LAMMPS *lmp = (class LAMMPS *) ptr;
int icompute = lmp->modify->find_compute(id);
if ( icompute < 0 ) return 0;
class Compute *compute = lmp->modify->compute[icompute];
if ( style == 0 )
{
if ( !compute->vector_flag )
return 0;
else
return compute->size_vector;
}
else if ( style == 1 )
{
return lammps_get_natoms (ptr);
}
else if ( style == 2 )
{
if ( !compute->local_flag )
return 0;
else
return compute->size_local_rows;
}
else
return 0;
int *size;
size = (int *) lammps_extract_compute(ptr, id, style, LMP_SIZE_VECTOR);
if (size) return *size;
return 0;
}
void lammps_extract_compute_arraysize (void *ptr, char *id, int style,
int *nrows, int *ncols)
{
class LAMMPS *lmp = (class LAMMPS *) ptr;
int icompute = lmp->modify->find_compute(id);
if ( icompute < 0 )
{
*nrows = 0;
*ncols = 0;
}
class Compute *compute = lmp->modify->compute[icompute];
if ( style == 0 )
{
if ( !compute->array_flag )
{
*nrows = 0;
*ncols = 0;
}
else
{
*nrows = compute->size_array_rows;
*ncols = compute->size_array_cols;
}
}
else if ( style == 1 )
{
if ( !compute->peratom_flag )
{
*nrows = 0;
*ncols = 0;
}
else
{
*nrows = lammps_get_natoms (ptr);
*ncols = compute->size_peratom_cols;
}
}
else if ( style == 2 )
{
if ( !compute->local_flag )
{
*nrows = 0;
*ncols = 0;
}
else
{
*nrows = compute->size_local_rows;
*ncols = compute->size_local_cols;
}
}
else
{
*nrows = 0;
*ncols = 0;
}
int *tmp;
tmp = (int *) lammps_extract_compute(ptr, id, style, LMP_SIZE_ROWS);
if (tmp) *nrows = *tmp;
tmp = (int *) lammps_extract_compute(ptr, id, style, LMP_SIZE_COLS);
if (tmp) *ncols = *tmp;
return;
}
int lammps_extract_fix_vectorsize (void *ptr, char *id, int style)
{
class LAMMPS *lmp = (class LAMMPS *) ptr;
int ifix = lmp->modify->find_fix(id);
if ( ifix < 0 ) return 0;
class Fix *fix = lmp->modify->fix[ifix];
if ( style == 0 )
{
if ( !fix->vector_flag )
return 0;
else
return fix->size_vector;
}
else if ( style == 1 )
{
return lammps_get_natoms (ptr);
}
else if ( style == 2 )
{
if ( !fix->local_flag )
return 0;
else
return fix->size_local_rows;
}
else
return 0;
int *size;
size = (int *) lammps_extract_fix(ptr, id, style, LMP_SIZE_VECTOR, 0, 0);
if (size) return *size;
return 0;
}
void lammps_extract_fix_arraysize (void *ptr, char *id, int style,
int *nrows, int *ncols)
{
class LAMMPS *lmp = (class LAMMPS *) ptr;
int ifix = lmp->modify->find_fix(id);
if ( ifix < 0 )
{
*nrows = 0;
*ncols = 0;
}
class Fix *fix = lmp->modify->fix[ifix];
if ( style == 0 )
{
if ( !fix->array_flag )
{
*nrows = 0;
*ncols = 0;
}
else
{
*nrows = fix->size_array_rows;
*ncols = fix->size_array_cols;
}
}
else if ( style == 1 )
{
if ( !fix->peratom_flag )
{
*nrows = 0;
*ncols = 0;
}
else
{
*nrows = lammps_get_natoms (ptr);
*ncols = fix->size_peratom_cols;
}
}
else if ( style == 2 )
{
if ( !fix->local_flag )
{
*nrows = 0;
*ncols = 0;
}
else
{
*nrows = fix->size_local_rows;
*ncols = fix->size_local_cols;
}
}
else
{
*nrows = 0;
*ncols = 0;
}
int *tmp;
tmp = (int *) lammps_extract_fix(ptr, id, style, LMP_SIZE_ROWS, 0, 0);
if (tmp) *nrows = *tmp;
tmp = (int *) lammps_extract_fix(ptr, id, style, LMP_SIZE_COLS, 0, 0);
if (tmp) *ncols = *tmp;
return;
}
/* vim: set ts=3 sts=3 expandtab: */

4
examples/COUPLE/fortran_dftb/LAMMPS-wrapper.h
View File

@ -12,8 +12,8 @@
------------------------------------------------------------------------- */
/* ------------------------------------------------------------------------
Contributing author: Karl D. Hammond <karlh@ugcs.caltech.edu>
University of Tennessee, Knoxville (USA), 2012
Contributing author: Karl D. Hammond <hammondkd@missouri.edu>
University of Missouri (USA), 2012
------------------------------------------------------------------------- */
/* This is set of "wrapper" functions to assist LAMMPS.F90, which itself

3
examples/COUPLE/fortran_dftb/LAMMPS-wrapper2.cpp
View File

@ -12,8 +12,7 @@
------------------------------------------------------------------------- */
/* ------------------------------------------------------------------------
Contributing author: Karl D. Hammond <karlh@ugcs.caltech.edu>
University of Tennessee, Knoxville (USA), 2012
Contributing author: Nir Goldman, LLNL <ngoldman@llnl.gov>, 2016
------------------------------------------------------------------------- */
/* This is set of "wrapper" functions to assist LAMMPS.F90, which itself

2
examples/COUPLE/fortran_dftb/LAMMPS-wrapper2.h
View File

@ -12,7 +12,7 @@
------------------------------------------------------------------------- */
/* ------------------------------------------------------------------------
Contributing author: Nir Goldman, ngoldman@llnl.gov, Oct. 19th, 2016
Contributing author: Nir Goldman, LLNL <ngoldman@llnl.gov>, 2016
------------------------------------------------------------------------- */
/* This is set of "wrapper" functions to assist LAMMPS.F90, which itself

4
examples/COUPLE/fortran_dftb/LAMMPS.F90
View File

@ -12,8 +12,8 @@
!--------------------------------------------------------------------------
!! ------------------------------------------------------------------------
! Contributing author: Karl D. Hammond <karlh@ugcs.caltech.edu>
! University of Tennessee, Knoxville (USA), 2012
! Contributing author: Karl D. Hammond <hammondkd@missouri.edu>
! University of Missouri (USA), 2012
!--------------------------------------------------------------------------
!! LAMMPS, a Fortran 2003 module containing an interface between Fortran

1
examples/ELASTIC_T/BORN_MATRIX/Argon/Analytical/compute_born.py
View File

@ -1,7 +1,6 @@
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
import sys
import numpy as np
def reduce_Born(Cf):

1
examples/ELASTIC_T/BORN_MATRIX/Argon/Numdiff/compute_born.py
View File

@ -1,7 +1,6 @@
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
import sys
import numpy as np
def reduce_Born(Cf):

2
examples/ELASTIC_T/BORN_MATRIX/Silicon/elastic_utils.py
View File

@ -1,5 +1,5 @@
import numpy as np
from lammps import lammps, LAMMPS_INT, LMP_STYLE_GLOBAL, LMP_VAR_EQUAL, LMP_VAR_ATOM
from lammps import lammps, LMP_VAR_EQUAL
# method for rotating elastic constants

53
examples/PACKAGES/pace/plugin/CMakeLists.txt Normal file
View File

@ -0,0 +1,53 @@
##########################################
# CMake build system for plugin examples.
# The is meant to be used as a template for plugins that are
# distributed independent from the LAMMPS package.
##########################################
cmake_minimum_required(VERSION 3.10)
project(paceplugin VERSION 1.0 LANGUAGES CXX)
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR})
include(CheckIncludeFileCXX)
include(LAMMPSInterfacePlugin)
include(ML-PACE)
##########################
# building the plugins
add_library(paceplugin MODULE paceplugin.cpp ${LAMMPS_SOURCE_DIR}/ML-PACE/pair_pace.cpp)
target_link_libraries(paceplugin PRIVATE pace)
target_link_libraries(paceplugin PRIVATE lammps)
target_include_directories(paceplugin PRIVATE ${LAMMPS_SOURCE_DIR}/ML-PACE)
set_target_properties(paceplugin PROPERTIES PREFIX "" SUFFIX ".so")
# MacOS seems to need this
if(CMAKE_SYSTEM_NAME STREQUAL Darwin)
set_target_properties(paceplugin PROPERTIES LINK_FLAGS "-Wl,-undefined,dynamic_lookup")
elseif(CMAKE_SYSTEM_NAME STREQUAL "Windows")
# tell CMake to export all symbols to a .dll on Windows with special case for MinGW cross-compilers
set_target_properties(paceplugin PROPERTIES WINDOWS_EXPORT_ALL_SYMBOLS TRUE)
if(CMAKE_CROSSCOMPILING)
set_target_properties(paceplugin PROPERTIES LINK_FLAGS "-Wl,--export-all-symbols")
endif()
get_lammps_version(${LAMMPS_SOURCE_DIR}/version.h LAMMPS_VERSION)
find_program(MAKENSIS_PATH makensis)
if(MAKENSIS_PATH)
execute_process(COMMAND ${CMAKE_COMMAND} -E copy_if_different ${CMAKE_SOURCE_DIR}/lammps.ico
${CMAKE_SOURCE_DIR}/lammps-text-logo-wide.bmp ${CMAKE_SOURCE_DIR}/paceplugin.nsis ${CMAKE_BINARY_DIR})
if(BUILD_MPI)
add_custom_target(package ${MAKENSIS_PATH} -V1 -DVERSION=${LAMMPS_VERSION}-MPI paceplugin.nsis
DEPENDS paceplugin
BYPRODUCTS LAMMPS-ML-PACE-plugin-${LAMMPS_VERSION}-MPI.exe)
else()
add_custom_target(package ${MAKENSIS_PATH} -V1 -DVERSION=${LAMMPS_VERSION} paceplugin.nsis
COMMAND ${CMAKE_COMMAND} -E echo ${PWD}
DEPENDS paceplugin lammps.ico lammps-text-logo-wide.bmp paceplugin.nsis
BYPRODUCTS LAMMPS-ML-PACE-plugin-${LAMMPS_VERSION}.exe)
endif()
endif()
else()
set_target_properties(paceplugin PROPERTIES LINK_FLAGS "-rdynamic")
endif()

1
examples/PACKAGES/pace/plugin/LAMMPSInterfacePlugin.cmake Symbolic link
View File

@ -0,0 +1 @@
../../../../cmake/Modules/LAMMPSInterfacePlugin.cmake

1
examples/PACKAGES/pace/plugin/ML-PACE.cmake Symbolic link
View File

@ -0,0 +1 @@
../../../../cmake/Modules/Packages/ML-PACE.cmake

2
examples/PACKAGES/pace/plugin/README.txt Normal file
View File

@ -0,0 +1,2 @@
This folder contains a loader and support files to build the ML-PACE package as plugin.
For more information please see: https://docs.lammps.org/Developer_plugins.html

BIN
examples/PACKAGES/pace/plugin/lammps-text-logo-wide.bmp Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 25 KiB

BIN
examples/PACKAGES/pace/plugin/lammps.ico Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 204 KiB

28
examples/PACKAGES/pace/plugin/paceplugin.cpp Normal file
View File

@ -0,0 +1,28 @@
#include "lammpsplugin.h"
#include "version.h"
#include "pair_pace.h"
using namespace LAMMPS_NS;
static Pair *pair_pace_creator(LAMMPS *lmp)
{
return new PairPACE(lmp);
}
extern "C" void lammpsplugin_init(void *lmp, void *handle, void *regfunc)
{
lammpsplugin_t plugin;
lammpsplugin_regfunc register_plugin = (lammpsplugin_regfunc) regfunc;
// register pace pair style
plugin.version = LAMMPS_VERSION;
plugin.style = "pair";
plugin.name = "pace";
plugin.info = "PACE plugin pair style v1.0";
plugin.author = "Axel Kohlmeyer (akohlmey@gmail.com)";
plugin.creator.v1 = (lammpsplugin_factory1 *) &pair_pace_creator;
plugin.handle = handle;
(*register_plugin)(&plugin, lmp);
}

157
examples/PACKAGES/pace/plugin/paceplugin.nsis Normal file
View File

@ -0,0 +1,157 @@
#!Nsis Installer Command Script
#
# The following external defines are recognized:
# ${VERSION} = YYYYMMDD
!include "MUI2.nsh"
!include "FileFunc.nsh"
!define MUI_ICON "lammps.ico"
!define MUI_UNICON "lammps.ico"
!define MUI_HEADERIMAGE
!define MUI_HEADERIMAGE_BITMAP "lammps-text-logo-wide.bmp"
!define MUI_HEADERIMAGE_RIGHT
Unicode true
XPStyle on
!include "LogicLib.nsh"
!addplugindir "envvar/Plugins/x86-unicode"
!include "x64.nsh"
RequestExecutionLevel user
!macro VerifyUserIsAdmin
UserInfo::GetAccountType
pop $0
${If} $0 != "admin"
messageBox mb_iconstop "Administrator rights required!"
setErrorLevel 740 ;ERROR_ELEVATION_REQUIRED
quit
${EndIf}
!macroend
!define PACEPLUGIN "LAMMPS ML-PACE Plugin ${VERSION}"
OutFile "LAMMPS-ML-PACE-plugin-${VERSION}.exe"
Name "${PACEPLUGIN}"
InstallDir "$LOCALAPPDATA\${PACEPLUGIN}"
ShowInstDetails show
ShowUninstDetails show
SetCompressor lzma
!define MUI_ABORTWARNING
!insertmacro MUI_PAGE_DIRECTORY
!insertmacro MUI_PAGE_INSTFILES
!insertmacro MUI_UNPAGE_CONFIRM
!insertmacro MUI_UNPAGE_INSTFILES
!insertmacro MUI_LANGUAGE "English"
function .onInit
# Determine if LAMMPS was already installed and check whether it was in 32-bit
# or 64-bit. Then look up path to uninstaller and offer to uninstall or quit
SetRegView 32
ReadRegDWORD $0 HKCU "Software\LAMMPS-ML-PACE" "Bits"
SetRegView LastUsed
${If} $0 == "32"
SetRegView 32
${ElseIf} $0 == "64"
SetRegView 64
${Else}
SetRegView 64
${EndIf}
ClearErrors
ReadRegStr $R0 HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\LAMMPS-ML-PACE" "UninstallString"
SetRegView LastUsed
${If} ${Errors}
DetailPrint "LAMMPS ML-PACE plugin not (yet) installed"
${Else}
MessageBox MB_YESNO "LAMMPS ML-PACE plugin ($0 bit) is already installed. Uninstall existing version?" /SD IDYES IDNO Quit
Pop $R1
StrCmp $R1 2 Quit +1
Exec $R0
Quit:
Quit
${EndIf}
setShellVarContext all
functionEnd
Section "${PACEPLUGIN}" SecPaceplugin
SectionIn RO
# Write LAMMPS installation bitness marker. Always use 32-bit registry view
SetRegView 32
IntFmt $0 "0x%08X" 64
WriteRegDWORD HKCU "Software\LAMMPS-ML-PACE" "Bits" $0
# Switch to "native" registry view
SetRegView 64
SetShellVarContext current
SetOutPath "$INSTDIR"
File lammps.ico
File paceplugin.so
# Register Application and its uninstaller
WriteRegStr HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\LAMMPS-ML-PACE" \
"DisplayName" "${PACEPLUGIN}"
WriteRegStr HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\LAMMPS-ML-PACE" \
"Publisher" "The LAMMPS and PACE Developers"
WriteRegStr HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\LAMMPS-ML-PACE" \
"URLInfoAbout" "lammps.org"
WriteRegStr HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\LAMMPS-ML-PACE" \
"DisplayIcon" "$INSTDIR\lammps.ico"
WriteRegStr HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\LAMMPS-ML-PACE" \
"DisplayVersion" "${VERSION}"
WriteRegStr HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\LAMMPS-ML-PACE" \
"InstallLocation" "$INSTDIR"
WriteRegStr HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\LAMMPS-ML-PACE" \
"UninstallString" "$\"$INSTDIR\uninstall.exe$\""
WriteRegStr HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\LAMMPS-ML-PACE" \
"QuietUninstallString" "$\"$INSTDIR\uninstall.exe$\" /S"
${GetSize} "$INSTDIR" "/S=0K" $0 $1 $2
IntFmt $0 "0x%08X" $0
WriteRegDWORD HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\LAMMPS-ML-PACE" \
"EstimatedSize" "$0"
# update path variables
EnVar::SetHKCU
# add to LAMMPS plugin search path
EnVar::AddValue "LAMMPS_PLUGIN_PATH" "$INSTDIR"
WriteUninstaller "$INSTDIR\Uninstall.exe"
SectionEnd
function un.onInit
SetShellVarContext current
functionEnd
Section "Uninstall"
# remove LAMMPS bitness/installation indicator always in 32-bit registry view
SetRegView 32
DeleteRegKey HKCU "Software\LAMMPS-ML-PACE"
# unregister extension, and uninstall info
SetRegView 64
SetShellVarContext current
# unregister installation
DeleteRegKey HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\LAMMPS-ML-PACE"
# update path variables
EnVar::SetHKCU
# remove entry from LAMMPS plugin search path
EnVar::DeleteValue "LAMMPS_PLUGIN_PATH" "$INSTDIR"
Delete /REBOOTOK "$INSTDIR\paceplugin.so"
Delete /REBOOTOK "$INSTDIR\Uninstall.exe"
Delete /REBOOTOK "$INSTDIR\lammps.ico"
RMDir /REBOOTOK "$INSTDIR"
SectionEnd
# Local Variables:
# mode: sh
# End:

41
examples/kim/plugin/CMakeLists.txt
View File

@ -6,46 +6,11 @@
cmake_minimum_required(VERSION 3.10)
# 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()
project(kimplugin VERSION 1.0 LANGUAGES CXX)
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)
add_compile_options(/Zc:__cplusplus)
add_compile_options(/wd4244)
add_compile_options(/wd4267)
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_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR})
include(CheckIncludeFileCXX)
include(LAMMPSInterfaceCXX)
include(LAMMPSInterfacePlugin)
##########################
# building the plugins
@ -90,9 +55,9 @@ if(CMAKE_SYSTEM_NAME STREQUAL Darwin)
set_target_properties(kimplugin PROPERTIES LINK_FLAGS "-Wl,-undefined,dynamic_lookup")
elseif(CMAKE_SYSTEM_NAME STREQUAL "Windows")
# tell CMake to export all symbols to a .dll on Windows with special case for MinGW cross-compilers
set_target_properties(kimplugin.so PROPERTIES WINDOWS_EXPORT_ALL_SYMBOLS TRUE)
set_target_properties(kimplugin PROPERTIES WINDOWS_EXPORT_ALL_SYMBOLS TRUE)
if(CMAKE_CROSSCOMPILING)
set_target_properties(kimplugin PROPERTIES LINK_FLAGS "-Wl,--export-all-symbols")
set_target_properties(kimplugin PROPERTIES LINK_FLAGS "-Wl,--export-all-symbols")
endif()
else()
set_target_properties(kimplugin PROPERTIES LINK_FLAGS "-rdynamic")

88
examples/kim/plugin/LAMMPSInterfaceCXX.cmake
View File

@ -1,88 +0,0 @@
# Cmake script code to define the LAMMPS C++ interface
# settings required for building LAMMPS plugins
################################################################################
# helper function
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)
#################################################################################
# LAMMPS C++ interface. We only need the header related parts.
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)
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()
target_link_libraries(lammps INTERFACE MPI::MPI_CXX)
else()
target_include_directories(lammps INTERFACE "${LAMMPS_SOURCE_DIR}/STUBS")
endif()
set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallsmall: all 32-bit, smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
set(LAMMPS_SIZES_VALUES smallbig bigbig smallsmall)
set_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})
################################################################################
# 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()

1
examples/kim/plugin/LAMMPSInterfacePlugin.cmake Symbolic link
View File

@ -0,0 +1 @@
../../../cmake/Modules/LAMMPSInterfacePlugin.cmake

2
examples/kim/plugin/README.txt Normal file
View File

@ -0,0 +1,2 @@
This folder contains a loader and support files to build the KIM package as plugin.
For more information please see: https://docs.lammps.org/Developer_plugins.html

249
examples/mdi/README
View File

@ -2,10 +2,11 @@ These are examples that work the MDI package in LAMMPS which uses the
MolSSI MDI library for coupling codes together and communicating
between them with MDI messages.
In MDI lingo, one code is the driver and another code is the engine.
The 2 codes can be written in any language; C++ (LAMMPS) and Python
are illustrated here. The 2 codes can each be stand-alone codes, in
which case they can be run on different numbers of processors. The 2
Within the MDI context, one code is the driver and another code is
the engine. The 2 codes can be written in any language; C++ (LAMMPS)
and Python are illustrated here. The 2 codes can each be stand-alone
codes, in which case they can be run on different numbers of processors.
The 2
codes can communicate either via TCP (sockets) or via MPI. For the
TCP case, the driver and engine need to be launched separately,
e.g. in 2 windows on your desktop machine. For the MPI case, a single
@ -19,87 +20,99 @@ LAMMPS supports operating in all these MDI modes. It can be an engine
operating either as a stand-alone code or as a plugin. It can also be
a driver and couple to an engine that is either a stand-alone code or
a plugin. Examples for all these use cases are in this directory.
The example commands below illustrate how to run all the variants.
The Run.sh file shows how run in all the modes. Type "sh Run.sh"
to try them all out.
To use LAMMPS as a plugin engine, you must build it as a shared library.
Something like this, which also builds the normal LAMMPS executable
lmp_mpi:
To use LAMMPS as a plugin engine, you must build it as a shared
library. Something like this with make, which also builds the normal
LAMMPS executable lmp_mpi:
cd src
make yes-mdi
make mode=shlib mpi
To use the serial_driver.py example you will need Python 3 with Numpy
and mpi4py available in your Python. Make sure LAMMPS and Python are
using same the same version of MPI.
-------------------------------------------------
Examples 4 and 5 use Python scripts as MDI drivers. For this you will
need Python 3 with Numpy and mpi4py installed. Make sure LAMMPS and
Python/mpi4py are using same the same version of MPI.
You will also need MDI installed in your Python. You cannot use the
LAMMPS build of the MDI library for this, b/c LAMMPS builds MDI as a
static library, not shared, which Python requires.
You can install MDI in your Python via conda:
% conda install -c conda-forge pymdi=1.4.1
or via pip:
% pip install pymdi==1.4.1
It is likely fine to leave off the version number, to get the latest
MDI version. But to be safe, 1.4.1 is the version LAMMPS is currently
using.
-------------------------------------------------
5 example use-cases are explained below.
In the first 3 examples, results running with MDI should be identical
to running without MDI (alone log files). Example #4 has no non-MDI
run. Example #5 results should match the non-MDI run of example #1.
-------------------------------------------------
* Example #1 = run ab initio MD (AIMD)
Two instances of LAMMPS operate as a driver and engine. As an engine,
LAMMPS is a surrogate for a quantum code.
You can compare the thermo output in log.aimd.alone.1 to the thermo output in
any of the log.aimd.driver* files. It should be identical.
Note that the "alone" and "driver" input scripts have options for
running in NVE vs NPT Comment in/out the appropriate line to make
change. Nothing needs to be changed in the "engine" scripts.
-------------------------------------------------
-------------------------------------------------
* Example #1 = run ab inito MD (AIMD)
Two instances of LAMMPS operate as a driver and engine
As an engine, LAMMPS is a surrogate for a quantum code
* Example #2 = run LAMMPS, compute QM forces on snapshots from a long run
Note that the 2 input scripts in.aimd.alone and in.aimd.driver
have an option for running in NVE vs NPT mode. Comment in/out
the appropriate line to change modes. Nothing needs to be
changed in the in.aimd.engine or in.aimd.engine.plugin scripts.
Two instances of LAMMPS operate as a driver and engine. As an engine,
LAMMPS is a surrogate for a quantum code
---
You can compare the thermo output in log.snapshot.alone.1 to the
thermo output in any of the log.snapshot.driver* files. It should be
identical.
Run the entire calculation with a single instance of LAMMPS by itself
results should be identical to running this example with MDI
% lmp_mpi < in.aimd.alone
With MDI, the thermo output of the driver should match the thermo
output of the in.aimd.alone script.
---
Run with TCP: 1 proc each
% lmp_mpi -mdi "-name aimd -role DRIVER -method TCP -port 8021" -log log.aimd.driver -in in.aimd.driver
% lmp_mpi -mdi "-name LAMMPS -role ENGINE -method TCP -port 8021 -hostname localhost" -log log.aimd.engine -in in.aimd.engine
---
Run with TCP: 3 procs + 4 procs
% mpirun -np 3 lmp_mpi -mdi "-name aimd -role DRIVER -method TCP -port 8021" -log log.aimd.driver -in in.aimd.driver
% mpirun -np 4 lmp_mpi -mdi "-name LAMMPS -role ENGINE -method TCP -port 8021 -hostname localhost" -log log.aimd.engine -in in.aimd.engine
---
Run with MPI: 1 proc each
% mpirun -np 1 lmp_mpi -mdi "-name aimd -role DRIVER -method MPI" -log log.aimd.driver -in in.aimd.driver : -np 1 lmp_mpi -mdi "-name LAMMPS -role ENGINE -method MPI" -log log.aimd.engine -in in.aimd.engine
---
Run with MPI: 3 procs + 4 procs
% mpirun -np 3 lmp_mpi -mdi "-name aimd -role DRIVER -method MPI" -log log.aimd.driver -in in.aimd.driver : -np 4 lmp_mpi -mdi "-name LAMMPS -role ENGINE -method MPI" -log log.aimd.engine -in in.aimd.engine
---
Run in plugin mode: 1 proc
% lmp_mpi -mdi "-name aimd -role DRIVER -method LINK -plugin_path /home/sjplimp/lammps/git/src" -log log.aimd.driver.plugin -in in.aimd.driver.plugin
---
Run in plugin mode: 3 procs
% mpirun -np 3 lmp_mpi -mdi "-name aimd -role DRIVER -method LINK -plugin_path /home/sjplimp/lammps/git/src" -log log.aimd.driver.plugin -in in.aimd.driver.plugin
You can compare the dumped forces in dump.snapshot.alone.1 to the
forces in any of the dump.snapshot.* files. They should be identical,
although at step 0 the forces are "zero" and may be epsilon different.
-------------------------------------------------
-------------------------------------------------
* Example #2 = Python driver runs a sequence of unrelated LAMMPS calculations
Each calculation can be a single-point evaluation, MD run, or minimization
* Example #3 = run LAMMPS, compute QM forces on series of independent systems
Two instances of LAMMPS operate as a driver and engine. As an engine,
LAMMPS is a surrogate for a quantum code
You can compare the thermo output in log.series.alone.1 to the thermo
output in any of the log.series.driver* files. It should be
identical.
You can compare the dumped forces in dump.series.alone.1 to the forces
in any of the dump.series.* files. They should be identical,
-------------------------------------------------
-------------------------------------------------
* Example #4 = Python driver runs a sequence of unrelated LAMMPS calculations
Each calculation can be a single-point evaluation, MD run, or
minimization
The sequence_driver.py code allows for optional switches in addition
to -mdi (required) and the -plugin and -plugin_args switches which are
@ -128,101 +141,31 @@ copied here:
# -seed 12345
# random number seed > 0, default = 12345
---
Run with TCP: 1 proc each
% python3 sequence_driver.py -mdi "-role DRIVER -name sequence -method TCP -port 8021"
% lmp_mpi -mdi "-role ENGINE -name LAMMPS -method TCP -port 8021 -hostname localhost" -log log.sequence -in in.sequence
---
Run with TCP: 2 proc + 4 procs
% mpirun -np 2 python3 sequence_driver.py -mdi "-role DRIVER -name sequence -method TCP -port 8021"
% mpirun -np 4 lmp_mpi -mdi "-role ENGINE -name LAMMPS -method TCP -port 8021 -hostname localhost" -log log.sequence -in in.sequence
---
Run with MPI: 1 proc each
% mpirun -np 1 python3 sequence_driver.py -mdi "-role DRIVER -name sequence -method MPI" : -np 1 lmp_mpi -mdi "-role ENGINE -name LAMMPS -method MPI" -log log.sequence -in in.sequence
---
Run with MPI: 2 procs + 4 procs
% mpirun -np 2 python3 sequence_driver.py -mdi "-role DRIVER -name sequence -method MPI" : -np 4 lmp_mpi -mdi "-role ENGINE -name LAMMPS -method MPI" -log log.sequence -in in.sequence
---
Run in plugin mode: 1 proc
% python3 sequence_driver.py -plugin lammps -mdi "-role DRIVER -name sequence -method LINK -plugin_path /home/sjplimp/lammps/git/src" -plugin_args "-log log.sequence -in in.sequence"
---
Run in plugin mode: 3 procs
% mpirun -np 3 python3 sequence_driver.py -plugin lammps -mdi "-role DRIVER -name sequence -method LINK -plugin_path /home/sjplimp/lammps/git/src" -plugin_args "-log log.sequence -in in.sequence"
You can compare the thermo output in any of the log.sequence.engine.*
files. It should be identical.
-------------------------------------------------
-------------------------------------------------
* Example #3 = run AIMD with Python driver code and 2 LAMMPS instances as engines
First LAMMPS instance performs the MD timestepping
Second LAMMPS instance is surrogate QM = computes forces
* Example #5 = run AIMD with Python driver code and 2 LAMMPS instances as engines
First LAMMPS instance performs the MD timestepping. Second LAMMPS
instance is surrogate QM to compute forces.
The aimd_driver.py code allows for an optional switch in addition to
-mdi (required) and the -plugin and -plugin_args swiches which are
used to link to the 2 engines as a plugin libraries. The example run
commands below use the default values of the optional switch. The
switch is also explained the top of the file; the info is copied
here:
switch is also explained the top of the file; the info is copied here:
# -nsteps 5
# number of timesteps in dynamics runs, default = 5
# -nsteps 10
# number of timesteps in dynamics runs, default = 10
---
This calculation is the same as Example #1 with a LAMMPS driver and a
LAMMPS engine. Now there is a Python driver and two LAMMPS engines.
Run the entire calculation with a single instance of LAMMPS by itself
results should be identical to running this example with MDI
You can compare the thermo output in log.aimd.alone.1 output to the
thermo output is any of the log.sequence.engine.* files. It should be
identical for the Total Energy printed out by the Python driver script.
% lmp_mpi < in.aimd.alone
With MDI, the driver prints the QM and Total energies. These should
match the PotEng and TotEng output of the in.aimd.alone script.
---
Run with TCP: 1 proc each
% python3 aimd_driver.py -mdi "-role DRIVER -name aimd -method TCP -port 8021"
% lmp_mpi -mdi "-role ENGINE -name MM -method TCP -port 8021 -hostname localhost" -log log.aimd.mm -in in.aimd.mm
% lmp_mpi -mdi "-role ENGINE -name QM -method TCP -port 8021 -hostname localhost" -log log.aimd.qm -in in.aimd.qm
---
Run with TCP: 2 procs + 2 procs + 3 procs
% mpirun -np 2 python3 aimd_driver.py -mdi "-role DRIVER -name aimd -method TCP -port 8021"
% mpirun -np 2 lmp_mpi -mdi "-role ENGINE -name MM -method TCP -port 8021 -hostname localhost" -log log.aimd.mm -in in.aimd.mm
% mpirun -np 3 lmp_mpi -mdi "-role ENGINE -name QM -method TCP -port 8021 -hostname localhost" -log log.aimd.qm -in in.aimd.qm
---
Run with MPI: 1 proc each
% mpirun -np 1 python3 aimd_driver.py -mdi "-role DRIVER -name aimd -method MPI" : -np 1 lmp_mpi -mdi "-role ENGINE -name MM -method MPI" -log log.aimd.mm -in in.aimd.mm : -np 1 lmp_mpi -mdi "-role ENGINE -name QM -method MPI" -log log.aimd.qm -in in.aimd.qm
---
Run with MPI: 2 procs + 2 procs + 3 procs
% mpirun -np 2 python3 aimd_driver.py -mdi "-role DRIVER -name aimd -method MPI" : -np 2 lmp_mpi -mdi "-role ENGINE -name MM -method MPI" -log log.aimd.mm -in in.aimd.mm : -np 3 lmp_mpi -mdi "-role ENGINE -name QM -method MPI" -log log.aimd.qm -in in.aimd.qm
E.g. Step 10: MM energy 1.69875, QM energy -6.31535, Total energy -4.6166

256
examples/mdi/Run.sh Normal file
View File

@ -0,0 +1,256 @@
# Run all the examples
# -------------------------------------------------
# -------------------------------------------------
# Example 1 = run ab initio MD (AIMD)
# ---
# Run without MDI
lmp_mpi -log log.aimd.alone.1 < in.aimd.alone
# ---
# Run with TCP: 1 proc each
lmp_mpi -mdi "-name LMP1 -role DRIVER -method TCP -port 8021" -log log.aimd.driver.tcp.1 -in in.aimd.driver &
lmp_mpi -mdi "-name LMP2 -role ENGINE -method TCP -port 8021 -hostname localhost" -log log.aimd.engine.tcp.1 -in in.aimd.engine
# ---
# Run with TCP: 3 procs + 4 procs
mpirun -np 3 lmp_mpi -mdi "-name LMP1 -role DRIVER -method TCP -port 8021" -log log.aimd.driver.tcp.3 -in in.aimd.driver &
mpirun -np 4 lmp_mpi -mdi "-name LMP2 -role ENGINE -method TCP -port 8021 -hostname localhost" -log log.aimd.engine.tcp.4 -in in.aimd.engine
# ---
# Run with MPI: 1 proc each
mpirun -np 1 lmp_mpi -mdi "-name LMP1 -role DRIVER -method MPI" -log log.aimd.driver.mpi.1 -in in.aimd.driver : -np 1 lmp_mpi -mdi "-name LMP2 -role ENGINE -method MPI" -log log.aimd.engine.mpi.1 -in in.aimd.engine
# ---
# Run with MPI: 3 procs + 4 procs
mpirun -np 3 lmp_mpi -mdi "-name LMP1 -role DRIVER -method MPI" -log log.aimd.driver.mpi.3 -in in.aimd.driver : -np 4 lmp_mpi -mdi "-name LMP2 -role ENGINE -method MPI" -log log.aimd.engine.mpi.4 -in in.aimd.engine
# ---
# Run in plugin mode: 1 proc
lmp_mpi -mdi "-name LMP1 -role DRIVER -method LINK -plugin_path /home/sjplimp/lammps/git/src" -log log.aimd.driver.plugin.1 -in in.aimd.driver.plugin
mv log.aimd.engine.plugin log.aimd.engine.plugin.1
# ---
# Run in plugin mode: 3 procs
mpirun -np 3 lmp_mpi -mdi "-name LMP1 -role DRIVER -method LINK -plugin_path /home/sjplimp/lammps/git/src" -log log.aimd.driver.plugin.3 -in in.aimd.driver.plugin
mv log.aimd.engine.plugin log.aimd.engine.plugin.3
# -------------------------------------------------
# -------------------------------------------------
# Example 2 = run LAMMPS, compute QM forces on snapshots from a long run
# ---
# Run without MDI
lmp_mpi -log log.snapshot.alone.1 < in.snapshot.alone
mv dump.snapshot.alone dump.snapshot.alone.1
# ---
# Run with TCP: 1 proc each
lmp_mpi -mdi "-name LMP1 -role DRIVER -method TCP -port 8021" -log log.snapshot.driver.tcp.1 -in in.snapshot.driver &
lmp_mpi -mdi "-name LMP2 -role ENGINE -method TCP -port 8021 -hostname localhost" -log log.snapshot.engine.tcp.1 -in in.snapshot.engine
mv dump.snapshot.driver dump.snapshot.driver.tcp.1
# ---
# Run with TCP: 3 procs + 4 procs
mpirun -np 3 lmp_mpi -mdi "-name LMP1 -role DRIVER -method TCP -port 8021" -log log.snapshot.driver.tcp.3 -in in.snapshot.driver &
mpirun -np 4 lmp_mpi -mdi "-name LMP2 -role ENGINE -method TCP -port 8021 -hostname localhost" -log log.snapshot.engine.tcp.4 -in in.snapshot.engine
mv dump.snapshot.driver dump.snapshot.driver.tcp.4
# ---
# Run with MPI: 1 proc each
mpirun -np 1 lmp_mpi -mdi "-name LMP1 -role DRIVER -method MPI" -log log.snapshot.driver.mpi.1 -in in.snapshot.driver : -np 1 lmp_mpi -mdi "-name LMP2 -role ENGINE -method MPI" -log log.snapshot.engine.mpi.1 -in in.snapshot.engine
mv dump.snapshot.driver dump.snapshot.driver.mpi.1
# ---
# Run with MPI: 3 procs + 4 procs
mpirun -np 3 lmp_mpi -mdi "-name LMP1 -role DRIVER -method MPI" -log log.snapshot.driver.mpi.3 -in in.snapshot.driver : -np 4 lmp_mpi -mdi "-name LMP2 -role ENGINE -method MPI" -log log.snapshot.engine.mpi.3 -in in.snapshot.engine
mv dump.snapshot.driver dump.snapshot.driver.mpi.4
# ---
# Run in plugin mode: 1 proc
lmp_mpi -mdi "-name LMP1 -role DRIVER -method LINK -plugin_path /home/sjplimp/lammps/git/src" -log log.snapshot.driver.plugin.1 -in in.snapshot.driver.plugin
mv log.snapshot.engine.plugin log.snapshot.engine.plugin.1
mv dump.snapshot.driver.plugin dump.snapshot.driver.plugin.1
# ---
# Run in plugin mode: 3 procs
mpirun -np 3 lmp_mpi -mdi "-name LMP1 -role DRIVER -method LINK -plugin_path /home/sjplimp/lammps/git/src" -log log.snapshot.driver.plugin.3 -in in.snapshot.driver.plugin
mv log.snapshot.engine.plugin log.snapshot.engine.plugin.3
mv dump.snapshot.driver.plugin dump.snapshot.driver.plugin.3
# -------------------------------------------------
# -------------------------------------------------
# Example 3 = run LAMMPS, compute QM forces on series of independent systems
# ---
# Run without MDI
lmp_mpi -log log.series.alone.1 < in.series.alone
mv dump.series.alone dump.series.alone.1
# ---
# Run with TCP: 1 proc each
lmp_mpi -mdi "-name LMP1 -role DRIVER -method TCP -port 8021" -log log.series.driver.tcp.1 -in in.series.driver &
lmp_mpi -mdi "-name LMP2 -role ENGINE -method TCP -port 8021 -hostname localhost" -log log.series.engine.tcp.1 -in in.series.engine
mv dump.series.driver dump.series.driver.tcp.1
# ---
# Run with TCP: 3 procs + 4 procs
mpirun -np 3 lmp_mpi -mdi "-name LMP1 -role DRIVER -method TCP -port 8021" -log log.series.driver.tcp.3 -in in.series.driver &
mpirun -np 4 lmp_mpi -mdi "-name LMP2 -role ENGINE -method TCP -port 8021 -hostname localhost" -log log.series.engine.tcp.4 -in in.series.engine
mv dump.series.driver dump.series.driver.tcp.4
# ---
# Run with MPI: 1 proc each
mpirun -np 1 lmp_mpi -mdi "-name LMP1 -role DRIVER -method MPI" -log log.series.driver.mpi.1 -in in.series.driver : -np 1 lmp_mpi -mdi "-name LMP2 -role ENGINE -method MPI" -log log.series.engine.mpi.1 -in in.series.engine
mv dump.series.driver dump.series.driver.mpi.1
# ---
# Run with MPI: 3 procs + 4 procs
mpirun -np 3 lmp_mpi -mdi "-name LMP1 -role DRIVER -method MPI" -log log.series.driver.mpi.3 -in in.series.driver : -np 4 lmp_mpi -mdi "-name LMP2 -role ENGINE -method MPI" -log log.series.engine.mpi.4 -in in.series.engine
mv dump.series.driver dump.series.driver.mpi.4
# ---
# Run in plugin mode: 1 proc
lmp_mpi -mdi "-name LMP1 -role DRIVER -method LINK -plugin_path /home/sjplimp/lammps/git/src" -log log.series.driver.plugin.1 -in in.series.driver.plugin
mv log.series.engine.plugin log.series.engine.plugin.1
mv dump.series.driver.plugin dump.series.driver.plugin.1
# ---
# Run in plugin mode: 3 procs
mpirun -np 3 lmp_mpi -mdi "-name LMP1 -role DRIVER -method LINK -plugin_path /home/sjplimp/lammps/git/src" -log log.series.driver.plugin.3 -in in.series.driver.plugin
mv log.series.engine.plugin log.series.engine.plugin.3
mv dump.series.driver.plugin dump.series.driver.plugin.3
# -------------------------------------------------
# -------------------------------------------------
# Example 4 = Python driver runs a sequence of unrelated LAMMPS calculations
# ---
# Run with TCP: 1 proc each
python3 sequence_driver.py -mdi "-role DRIVER -name sequence -method TCP -port 8021" &
lmp_mpi -mdi "-role ENGINE -name LMP -method TCP -port 8021 -hostname localhost" -log log.sequence.engine.tcp.1 -in in.sequence.python
# ---
# Run with TCP: 2 proc + 4 procs
mpirun -np 2 python3 sequence_driver.py -mdi "-role DRIVER -name sequence -method TCP -port 8021" &
mpirun -np 4 lmp_mpi -mdi "-role ENGINE -name LMP -method TCP -port 8021 -hostname localhost" -log log.sequence.engine.tcp.4 -in in.sequence.python
# ---
# Run with MPI: 1 proc each
mpirun -np 1 python3 sequence_driver.py -mdi "-role DRIVER -name sequence -method MPI" : -np 1 lmp_mpi -mdi "-role ENGINE -name LAMMPS -method MPI" -log log.sequence.engine.mpi.1 -in in.sequence.python
# ---
# Run with MPI: 2 procs + 4 procs
mpirun -np 2 python3 sequence_driver.py -mdi "-role DRIVER -name sequence -method MPI" : -np 4 lmp_mpi -mdi "-role ENGINE -name LMP -method MPI" -log log.sequence.engine.mpi.4 -in in.sequence.python
# ---
# Run in plugin mode: 1 proc
python3 sequence_driver.py -plugin lammps -mdi "-role DRIVER -name sequence -method LINK -plugin_path /home/sjplimp/lammps/git/src" -plugin_args "-log log.sequence.engine.plugin.1 -in in.sequence".python
# ---
# Run in plugin mode: 3 procs
mpirun -np 3 python3 sequence_driver.py -plugin lammps -mdi "-role DRIVER -name sequence -method LINK -plugin_path /home/sjplimp/lammps/git/src" -plugin_args "-log log.sequence.engine.plugin.3 -in in.sequence".python
# -------------------------------------------------
# -------------------------------------------------
# Example 5 = run AIMD with Python driver code and 2 LAMMPS instances as engines
# ---
# Run with TCP: 1 proc each
python3 aimd_driver.py -mdi "-role DRIVER -name aimdpy -method TCP -port 8021" > log.aimdpy.driver.tcp.1 &
lmp_mpi -mdi "-role ENGINE -name MM -method TCP -port 8021 -hostname localhost" -log log.aimdpy.mm.tcp.1 -in in.aimdpy.mm &
lmp_mpi -mdi "-role ENGINE -name QM -method TCP -port 8021 -hostname localhost" -log log.aimdpy.qm.tcp.1 -in in.aimdpy.qm
# ---
# Run with TCP: 2 procs + 2 procs + 3 procs
mpirun -np 2 python3 aimd_driver.py -mdi "-role DRIVER -name aimdpy -method TCP -port 8021" > log.aimdpy.driver.tcp.2 &
mpirun -np 2 lmp_mpi -mdi "-role ENGINE -name MM -method TCP -port 8021 -hostname localhost" -log log.aimdpy.mm.tcp.2 -in in.aimdpy.mm &
mpirun -np 3 lmp_mpi -mdi "-role ENGINE -name QM -method TCP -port 8021 -hostname localhost" -log log.aimdpy.qm.tcp.3 -in in.aimdpy.qm
# ---
# Run with MPI: 1 proc each
mpirun -np 1 python3 aimd_driver.py -mdi "-role DRIVER -name aimdpy -method MPI" : -np 1 lmp_mpi -mdi "-role ENGINE -name MM -method MPI" -log log.aimdpy.mm.mpi.1 -in in.aimdpy.mm : -np 1 lmp_mpi -mdi "-role ENGINE -name QM -method MPI" -log log.aimdpy.qm.mpi.1 -in in.aimdpy.qm > log.aimdpy.driver.mpi.1
# ---
# Run with MPI: 2 procs + 2 procs + 3 procs
mpirun -np 2 python3 aimd_driver.py -mdi "-role DRIVER -name aimdpy -method MPI" : -np 2 lmp_mpi -mdi "-role ENGINE -name MM -method MPI" -log log.aimdpy.mm.mpi.2 -in in.aimdpy.mm : -np 3 lmp_mpi -mdi "-role ENGINE -name QM -method MPI" -log log.aimdpy.qm.mpi.3 -in in.aimdpy.qm > log.aimdpy.driver.mpi.2

11
examples/mdi/aimd_driver.py
View File

@ -23,10 +23,10 @@
# -plugin_args arglist
# args to add when launching plugin library, only when using plugin mode
# enclose arglist in quotes if multiple words
# -nsteps 5
# number of timesteps, default = 5
# -nsteps 10
# number of timesteps, default = 10
import sys,math,random
import sys
import mdi
import numpy as np
from mpi4py import MPI
@ -42,10 +42,9 @@ def error(txt=None):
def perform_aimd(world,mm_comm,qm_comm):
me = world.Get_rank()
nprocs = world.Get_size()
# receive number of atoms from the MM engine
mdi.MDI_Send_command("<NATOMS",mm_comm)
natoms = mdi.MDI_Recv(1,mdi.MDI_INT,mm_comm)
natoms = world.bcast(natoms,root=0)
@ -183,7 +182,7 @@ mdiarg = ""
plugin = ""
plugin_args = ""
nsteps = 5
nsteps = 10
# parse command-line args

1018
examples/mdi/data.series.0.7 Normal file
View File

File diff suppressed because it is too large Load Diff

1018
examples/mdi/data.series.0.8 Normal file
View File

File diff suppressed because it is too large Load Diff

1018
examples/mdi/data.series.0.9 Normal file
View File

File diff suppressed because it is too large Load Diff

1018
examples/mdi/data.snapshot Normal file
View File

File diff suppressed because it is too large Load Diff

1527
examples/mdi/dump.17Jun22.series.alone.1 Normal file
View File

File diff suppressed because it is too large Load Diff

1527
examples/mdi/dump.17Jun22.series.driver.mpi.1 Normal file
View File

File diff suppressed because it is too large Load Diff

1527
examples/mdi/dump.17Jun22.series.driver.mpi.4 Normal file
View File

File diff suppressed because it is too large Load Diff

1527
examples/mdi/dump.17Jun22.series.driver.plugin.1 Normal file
View File

File diff suppressed because it is too large Load Diff

1527
examples/mdi/dump.17Jun22.series.driver.plugin.3 Normal file
View File

File diff suppressed because it is too large Load Diff

1527
examples/mdi/dump.17Jun22.series.driver.tcp.1 Normal file
View File

File diff suppressed because it is too large Load Diff

1527
examples/mdi/dump.17Jun22.series.driver.tcp.4 Normal file
View File

File diff suppressed because it is too large Load Diff

2036
examples/mdi/dump.17Jun22.snapshot.alone.1 Normal file
View File

File diff suppressed because it is too large Load Diff

2036
examples/mdi/dump.17Jun22.snapshot.driver.mpi.1 Normal file
View File

File diff suppressed because it is too large Load Diff

2036
examples/mdi/dump.17Jun22.snapshot.driver.mpi.4 Normal file
View File

File diff suppressed because it is too large Load Diff

2036
examples/mdi/dump.17Jun22.snapshot.driver.plugin.1 Normal file
View File

File diff suppressed because it is too large Load Diff

2036
examples/mdi/dump.17Jun22.snapshot.driver.plugin.3 Normal file
View File

File diff suppressed because it is too large Load Diff

2036
examples/mdi/dump.17Jun22.snapshot.driver.tcp.1 Normal file
View File

File diff suppressed because it is too large Load Diff

2036
examples/mdi/dump.17Jun22.snapshot.driver.tcp.4 Normal file
View File

File diff suppressed because it is too large Load Diff

2
examples/mdi/in.aimd.alone
View File

@ -29,4 +29,4 @@ fix 1 all nve
thermo_style custom step temp pe etotal press vol
thermo 1
run 5
run 10

5
examples/mdi/in.aimd.driver
View File

@ -23,10 +23,9 @@ fix 1 all nve
# NPT
#fix 1 all npt temp 1.0 1.0 0.1 iso 1.0 1.0 1.0
fix 2 all mdi/aimd
fix_modify 2 energy yes virial yes
fix 2 all mdi/qm virial yes
thermo_style custom step temp pe etotal press vol
thermo 1
run 5
run 10

7
examples/mdi/in.aimd.driver.plugin
View File

@ -23,12 +23,11 @@ fix 1 all nve
# NPT
#fix 1 all npt temp 1.0 1.0 0.1 iso 1.0 1.0 1.0
fix 2 all mdi/aimd
fix_modify 2 energy yes virial yes
fix 2 all mdi/qm virial yes
thermo_style custom step temp pe etotal press vol
thermo 1
mdi plugin lammps mdi "-role ENGINE -name lammps -method LINK" &
mdi plugin lammps mdi "-role ENGINE -name LMP2 -method LINK" &
infile in.aimd.engine extra "-log log.aimd.engine.plugin" &
command "run 5"
command "run 10"

12
examples/mdi/in.aimd.engine
View File

@ -1,16 +1,11 @@
# 3d Lennard-Jones melt - MDI engine script
variable x index 5
variable y index 5
variable z index 5
units lj
atom_style atomic
lattice fcc 0.8442
region box block 0 $x 0 $y 0 $z
lattice fcc 1.0
region box block 0 1 0 1 0 1
create_box 1 box
create_atoms 1 box
mass 1 1.0
pair_style lj/cut 2.5
@ -19,4 +14,7 @@ pair_coeff 1 1 1.0 1.0 2.5
neighbor 0.3 bin
neigh_modify delay 0 every 1 check yes
thermo_style custom step temp pe etotal press vol
thermo 1
mdi engine

0
examples/mdi/in.aimd.mm → examples/mdi/in.aimdpy.mm
View File

0
examples/mdi/in.aimd.qm → examples/mdi/in.aimdpy.qm
View File

1
examples/mdi/in.sequence → examples/mdi/in.sequence.python
View File

@ -19,3 +19,4 @@ fix 1 all nve
thermo 10
mdi engine

37
examples/mdi/in.series.alone Normal file
View File

@ -0,0 +1,37 @@
# 3d Lennard-Jones melt - MDI driver script
variable x index 5
variable y index 5
variable z index 5
variable rho index 0.7 0.8 0.9
label LOOP
units lj
atom_style atomic
read_data data.series.${rho}
displace_atoms all random 0.1 0.1 0.1 48294
pair_style lj/cut 2.5
pair_coeff 1 1 1.0 1.0 2.5
neighbor 0.3 bin
neigh_modify delay 0 every 1 check yes
compute 1 all pressure NULL virial
thermo_style custom step temp pe c_1 c_1[1] c_1[2] c_1[3]
run 0
write_dump all custom dump.series.alone &
id type x y z fx fy fz modify sort id append yes
clear
next rho
jump SELF LOOP

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