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

Merge branch 'develop' into electrode

Browse Source
This commit is contained in:
Axel Kohlmeyer
2024-07-03 15:17:43 -04:00
parent 01502f70a4 993a7cce54
commit 17d736c0f9
1377 changed files with 147339 additions and 80018 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
.github/CODEOWNERS vendored
View File

@ -37,7 +37,8 @@ src/MESONT/* @iafoss
src/ML-HDNNP/* @singraber
src/ML-IAP/* @athomps
src/ML-PACE/* @yury-lysogorskiy
src/ML-POD/* @exapde @rohskopf
src/ML-POD/* @exapde
src/ML-UF3/* @monk-04
src/MOFFF/* @hheenen
src/MOLFILE/* @akohlmey
src/NETCDF/* @pastewka
@ -58,7 +59,8 @@ src/VTK/* @rbberger
# individual files in packages
src/GPU/pair_vashishta_gpu.* @andeplane
src/KOKKOS/pair_vashishta_kokkos.* @andeplane
src/KOKKOS/pair_vashishta_kokkos.* @andeplane @stanmoore1
src/KOSSOS/pair_pod_kokkos.* @exapde @stanmoore1
src/MANYBODY/pair_vashishta_table.* @andeplane
src/MANYBODY/pair_atm.* @sergeylishchuk
src/MANYBODY/pair_nb3b_screened.* @flodesani
@ -72,6 +74,8 @@ src/MC/fix_sgcmc.* @athomps
src/REAXFF/compute_reaxff_atom.* @rbberger
src/KOKKOS/compute_reaxff_atom_kokkos.* @rbberger
src/REPLICA/fix_pimd_langevin.* @Yi-FanLi
src/DPD-BASIC/pair_dpd_coul_slater_long.* @Eddy-Barraud
src/GPU/pair_dpd_coul_slater_long.* @Eddy-Barraud
# core LAMMPS classes
src/lammps.* @sjplimp
@ -83,7 +87,7 @@ src/bond.* @sjplimp
src/comm*.* @sjplimp
src/compute.* @sjplimp
src/dihedral.* @sjplimp
src/domain.* @sjplimp
src/domain.* @sjplimp @stanmoore1
src/dump*.* @sjplimp
src/error.* @sjplimp
src/finish.* @sjplimp

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

@ -15,7 +15,7 @@ jobs:
build:
name: MacOS Unit Test
if: ${{ github.repository == 'lammps/lammps' }}
runs-on: macos-latest
runs-on: macos-13
env:
CCACHE_DIR: ${{ github.workspace }}/.ccache
@ -43,6 +43,8 @@ jobs:
working-directory: build
run: |
ccache -z
python3 -m venv macosenv
source macosenv/bin/activate
python3 -m pip install numpy
python3 -m pip install pyyaml
cmake -C ../cmake/presets/clang.cmake \

11
.gitignore vendored
View File

@ -43,12 +43,12 @@ Thumbs.db
#cmake
/build*
/CMakeCache.txt
/CMakeFiles/
/Testing
CMakeCache.txt
CMakeFiles
/Makefile
/Testing
/cmake_install.cmake
Testing
Temporary
cmake_install.cmake
/lmp
out/Debug
out/RelWithDebInfo
@ -60,3 +60,4 @@ src/Makefile.package.settings-e
/cmake/build/x64-Debug-Clang
/install/x64-GUI-MSVC
/install
.Rhistory

9
cmake/CMakeLists.txt
View File

@ -23,6 +23,7 @@ project(lammps CXX)
set(SOVERSION 0)
get_property(BUILD_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
include(GNUInstallDirs)
get_filename_component(LAMMPS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/.. ABSOLUTE)
get_filename_component(LAMMPS_LIB_BINARY_DIR ${CMAKE_BINARY_DIR}/lib ABSOLUTE)
# collect all executables and shared libs in the top level build folder
@ -208,7 +209,7 @@ else()
unset(CMAKE_CXX_CLANG_TIDY CACHE)
endif()
include(GNUInstallDirs)
file(GLOB ALL_SOURCES CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/[^.]*.cpp)
file(GLOB MAIN_SOURCES CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/main.cpp)
list(REMOVE_ITEM ALL_SOURCES ${MAIN_SOURCES})
@ -256,6 +257,7 @@ set(STANDARD_PACKAGES
DRUDE
EFF
ELECTRODE
EXTRA-COMMAND
EXTRA-COMPUTE
EXTRA-DUMP
EXTRA-FIX
@ -281,10 +283,11 @@ set(STANDARD_PACKAGES
ML-HDNNP
ML-IAP
ML-PACE
ML-POD
ML-QUIP
ML-RANN
ML-SNAP
ML-POD
ML-UF3
MOFFF
MOLECULE
MOLFILE
@ -689,7 +692,7 @@ endif()
# packages which selectively include variants based on enabled styles
# e.g. accelerator packages
######################################################################
foreach(PKG_WITH_INCL CORESHELL DPD-SMOOTH MC MISC PHONON QEQ OPENMP KOKKOS OPT INTEL GPU)
foreach(PKG_WITH_INCL CORESHELL DPD-BASIC DPD-SMOOTH MC MISC PHONON QEQ OPENMP KOKKOS OPT INTEL GPU)
if(PKG_${PKG_WITH_INCL})
include(Packages/${PKG_WITH_INCL})
endif()

4
cmake/Modules/OpenCLLoader.cmake
View File

@ -1,6 +1,6 @@
message(STATUS "Downloading and building OpenCL loader library")
set(OPENCL_LOADER_URL "${LAMMPS_THIRDPARTY_URL}/opencl-loader-2024.02.09.tar.gz" CACHE STRING "URL for OpenCL loader tarball")
set(OPENCL_LOADER_MD5 "f3573cf9daa3558ba46fd5866517f38f" CACHE STRING "MD5 checksum of OpenCL loader tarball")
set(OPENCL_LOADER_URL "${LAMMPS_THIRDPARTY_URL}/opencl-loader-2024.05.09.tar.gz" CACHE STRING "URL for OpenCL loader tarball")
set(OPENCL_LOADER_MD5 "e7796826b21c059224fabe997e0f2075" CACHE STRING "MD5 checksum of OpenCL loader tarball")
mark_as_advanced(OPENCL_LOADER_URL)
mark_as_advanced(OPENCL_LOADER_MD5)

9
cmake/Modules/Packages/DPD-BASIC.cmake Normal file
View File

@ -0,0 +1,9 @@
# pair style dpd/coul/slater/long may only be installed if also KSPACE is installed
if(NOT PKG_KSPACE)
get_property(LAMMPS_PAIR_HEADERS GLOBAL PROPERTY PAIR)
list(REMOVE_ITEM LAMMPS_PAIR_HEADERS ${LAMMPS_SOURCE_DIR}/DPD-BASIC/pair_dpd_coul_slater_long.h)
set_property(GLOBAL PROPERTY PAIR "${LAMMPS_PAIR_HEADERS}")
get_target_property(LAMMPS_SOURCES lammps SOURCES)
list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/DPD-BASIC/pair_dpd_coul_slater_long.cpp)
set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
endif()

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

@ -45,8 +45,8 @@ if(DOWNLOAD_KOKKOS)
list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
include(ExternalProject)
set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.2.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
set(KOKKOS_MD5 "731647b61a4233f568d583702e9cd6d1" CACHE STRING "MD5 checksum of KOKKOS tarball")
set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.3.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
set(KOKKOS_MD5 "243de871b3dc2cf3990c1c404032df83" CACHE STRING "MD5 checksum of KOKKOS tarball")
mark_as_advanced(KOKKOS_URL)
mark_as_advanced(KOKKOS_MD5)
GetFallbackURL(KOKKOS_URL KOKKOS_FALLBACK)
@ -71,7 +71,7 @@ if(DOWNLOAD_KOKKOS)
add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
elseif(EXTERNAL_KOKKOS)
find_package(Kokkos 4.2.00 REQUIRED CONFIG)
find_package(Kokkos 4.3.01 REQUIRED CONFIG)
target_link_libraries(lammps PRIVATE Kokkos::kokkos)
else()
set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)
@ -139,12 +139,9 @@ if(PKG_KSPACE)
message(WARNING "Using KISS FFT with the CUDA backend of Kokkos may be sub-optimal.")
target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_KISS)
elseif(FFT_KOKKOS STREQUAL "CUFFT")
find_library(CUFFT_LIBRARY cufft)
if (CUFFT_LIBRARY STREQUAL "CUFFT_LIBRARY-NOTFOUND")
message(FATAL_ERROR "Required cuFFT library not found. Check your environment or set CUFFT_LIBRARY to its location")
endif()
find_package(CUDAToolkit REQUIRED)
target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_CUFFT)
target_link_libraries(lammps PRIVATE ${CUFFT_LIBRARY})
target_link_libraries(lammps PRIVATE CUDA::cufft)
endif()
elseif(Kokkos_ENABLE_HIP)
if(NOT ((FFT_KOKKOS STREQUAL "KISS") OR (FFT_KOKKOS STREQUAL "HIPFFT")))

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

@ -10,6 +10,14 @@ endif()
option(MLIAP_ENABLE_PYTHON "Build ML-IAP package with Python support" ${MLIAP_ENABLE_PYTHON_DEFAULT})
# if ML-PACE package *and* MLIAP with Python is enabled is included we may also include ML-PACE support in ML-IAP
set(MLIAP_ENABLE_ACE_DEFAULT OFF)
if(PKG_ML-PACE)
set(MLIAP_ENABLE_ACE_DEFAULT ON)
endif()
option(MLIAP_ENABLE_ACE "Build ML-IAP package with ACE support" ${MLIAP_ENABLE_ACE_DEFAULT})
if(MLIAP_ENABLE_PYTHON)
find_package(Cythonize REQUIRED)
find_package(Python COMPONENTS NumPy REQUIRED)
@ -36,3 +44,10 @@ if(MLIAP_ENABLE_PYTHON)
target_compile_definitions(lammps PRIVATE -DMLIAP_PYTHON)
target_include_directories(lammps PRIVATE ${MLIAP_BINARY_DIR})
endif()
if(MLIAP_ENABLE_ACE)
if(NOT PKG_ML-PACE)
message(FATAL_ERROR "Must enable ML-PACE package for including ACE support in ML-IAP")
endif()
target_compile_definitions(lammps PRIVATE -DMLIAP_ACE)
endif()

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

@ -1,5 +1,9 @@
# Plumed2 support for PLUMED package
# for supporting multiple concurrent plumed2 installations for debugging and testing
set(PLUMED_SUFFIX "" CACHE STRING "Suffix for Plumed2 library")
mark_as_advanced(PLUMED_SUFFIX)
if(BUILD_MPI)
set(PLUMED_CONFIG_MPI "--enable-mpi")
set(PLUMED_CONFIG_CC ${CMAKE_MPI_C_COMPILER})
@ -21,9 +25,11 @@ else()
set(PLUMED_CONFIG_OMP "--disable-openmp")
endif()
set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.8.3/plumed-src-2.8.3.tgz"
# Note: must also adjust check for supported API versions in
# fix_plumed.cpp when version changes from v2.n.x to v2.n+1.y
set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.9.1/plumed-src-2.9.1.tgz"
CACHE STRING "URL for PLUMED tarball")
set(PLUMED_MD5 "76d23cd394eba9e6530316ed1184e219" CACHE STRING "MD5 checksum of PLUMED tarball")
set(PLUMED_MD5 "c3b2d31479c1e9ce211719d40e9efbd7" CACHE STRING "MD5 checksum of PLUMED tarball")
mark_as_advanced(PLUMED_URL)
mark_as_advanced(PLUMED_MD5)
@ -151,15 +157,15 @@ else()
file(MAKE_DIRECTORY ${INSTALL_DIR}/include)
else()
find_package(PkgConfig REQUIRED)
pkg_check_modules(PLUMED REQUIRED plumed)
pkg_check_modules(PLUMED REQUIRED plumed${PLUMED_SUFFIX})
add_library(LAMMPS::PLUMED INTERFACE IMPORTED)
if(PLUMED_MODE STREQUAL "STATIC")
include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.static)
include(${PLUMED_LIBDIR}/plumed${PLUMED_SUFFIX}/src/lib/Plumed.cmake.static)
elseif(PLUMED_MODE STREQUAL "SHARED")
include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.shared)
include(${PLUMED_LIBDIR}/plumed${PLUMED_SUFFIX}/src/lib/Plumed.cmake.shared)
elseif(PLUMED_MODE STREQUAL "RUNTIME")
set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${PLUMED_LIBDIR}/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.runtime)
set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${PLUMED_LIBDIR}/${CMAKE_SHARED_LIBRARY_PREFIX}plumed${PLUMED_SUFFIX}Kernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
include(${PLUMED_LIBDIR}/plumed${PLUMED_SUFFIX}/src/lib/Plumed.cmake.runtime)
endif()
set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_LINK_LIBRARIES "${PLUMED_LOAD}")
set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${PLUMED_INCLUDE_DIRS}")

2
cmake/packaging/build_linux_tgz.sh
View File

@ -59,12 +59,14 @@ done
echo "Set up wrapper script"
MYDIR=$(dirname "$0")
cp ${MYDIR}/xdg-open ${DESTDIR}/bin
cp ${MYDIR}/linux_wrapper.sh ${DESTDIR}/bin
for s in ${DESTDIR}/bin/*
do \
EXE=$(basename $s)
test ${EXE} = linux_wrapper.sh && continue
test ${EXE} = qt.conf && continue
test ${EXE} = xdg-open && continue
ln -s bin/linux_wrapper.sh ${DESTDIR}/${EXE}
done

14
cmake/packaging/linux_wrapper.sh
View File

@ -4,15 +4,17 @@
# reset locale to avoid problems with decimal numbers
export LC_ALL=C
BASEDIR=$(dirname "$0")
EXENAME=$(basename "$0")
BASEDIR="$(dirname "$0")"
EXENAME="$(basename "$0")"
PATH="${BASEDIR}/bin:${PATH}"
# append to LD_LIBRARY_PATH to prefer local (newer) libs
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${BASEDIR}/lib
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${BASEDIR}/lib"
# set some environment variables for LAMMPS etc.
LAMMPS_POTENTIALS=${BASEDIR}/share/lammps/potentials
MSI2LMP_LIBRARY=${BASEDIR}/share/lammps/frc_files
export LD_LIBRARY_PATH LAMMPS_POTENTIALS MSI2LMP_LIBRARY
LAMMPS_POTENTIALS="${BASEDIR}/share/lammps/potentials"
MSI2LMP_LIBRARY="${BASEDIR}/share/lammps/frc_files"
export LD_LIBRARY_PATH LAMMPS_POTENTIALS MSI2LMP_LIBRARY PATH
exec "${BASEDIR}/bin/${EXENAME}" "$@"

1074
cmake/packaging/xdg-open Executable file
View File

File diff suppressed because it is too large Load Diff

4
cmake/presets/all_off.cmake
View File

@ -26,8 +26,9 @@ set(ALL_PACKAGES
DPD-REACT
DPD-SMOOTH
DRUDE
ELECTRODE
EFF
ELECTRODE
EXTRA-COMMAND
EXTRA-COMPUTE
EXTRA-DUMP
EXTRA-FIX
@ -60,6 +61,7 @@ set(ALL_PACKAGES
ML-QUIP
ML-RANN
ML-SNAP
ML-UF3
MOFFF
MOLECULE
MOLFILE

4
cmake/presets/all_on.cmake
View File

@ -28,8 +28,9 @@ set(ALL_PACKAGES
DPD-REACT
DPD-SMOOTH
DRUDE
ELECTRODE
EFF
ELECTRODE
EXTRA-COMMAND
EXTRA-COMPUTE
EXTRA-DUMP
EXTRA-FIX
@ -62,6 +63,7 @@ set(ALL_PACKAGES
ML-QUIP
ML-RANN
ML-SNAP
ML-UF3
MOFFF
MOLECULE
MOLFILE

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

@ -13,7 +13,7 @@ set(CMAKE_CXX_COMPILER hipcc CACHE STRING "" FORCE)
set(CMAKE_TUNE_FLAGS "-munsafe-fp-atomics" CACHE STRING "" FORCE)
# If KSPACE is also enabled, use CUFFT for FFTs
set(FFT_KOKKOS "HIPFFT" CACHE STRING FORCE)
set(FFT_KOKKOS "HIPFFT" CACHE STRING "" FORCE)
# hide deprecation warnings temporarily for stable release
set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)

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

@ -22,8 +22,9 @@ set(WIN_PACKAGES
DPD-REACT
DPD-SMOOTH
DRUDE
ELECTRODE
EFF
ELECTRODE
EXTRA-COMMAND
EXTRA-COMPUTE
EXTRA-DUMP
EXTRA-FIX
@ -32,7 +33,6 @@ set(WIN_PACKAGES
FEP
GPU
GRANULAR
INTEL
INTERLAYER
KSPACE
LEPTON
@ -50,6 +50,7 @@ set(WIN_PACKAGES
ML-POD
ML-RANN
ML-SNAP
ML-UF3
MOFFF
MOLECULE
MOLFILE

2
cmake/presets/most.cmake
View File

@ -26,6 +26,7 @@ set(ALL_PACKAGES
DRUDE
EFF
ELECTRODE
EXTRA-COMMAND
EXTRA-COMPUTE
EXTRA-DUMP
EXTRA-FIX
@ -45,6 +46,7 @@ set(ALL_PACKAGES
ML-IAP
ML-POD
ML-SNAP
ML-UF3
MOFFF
MOLECULE
OPENMP

4
cmake/presets/windows.cmake
View File

@ -22,6 +22,7 @@ set(WIN_PACKAGES
DRUDE
EFF
ELECTRODE
EXTRA-COMMAND
EXTRA-COMPUTE
EXTRA-DUMP
EXTRA-FIX
@ -42,6 +43,7 @@ set(WIN_PACKAGES
ML-IAP
ML-POD
ML-SNAP
ML-UF3
MOFFF
MOLECULE
MOLFILE
@ -50,8 +52,8 @@ set(WIN_PACKAGES
ORIENT
PERI
PHONON
POEMS
PLUGIN
POEMS
PTM
QEQ
QTB

6
doc/lammps.1
View File

@ -1,7 +1,7 @@
.TH LAMMPS "1" "7 February 2024" "2024-02-07"
.TH LAMMPS "1" "27 June 2024" "2024-06-27"
.SH NAME
.B LAMMPS
\- Molecular Dynamics Simulator. Version 7 February 2024
\- Molecular Dynamics Simulator. Version 27 June 2024
.SH SYNOPSIS
.B lmp
@ -297,7 +297,7 @@ the chapter on errors in the
manual gives some additional information about error messages, if possible.
.SH COPYRIGHT
© 2003--2022 Sandia Corporation
© 2003--2024 Sandia Corporation
This package is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License version 2 as

14
doc/src/Build_extras.rst
View File

@ -533,9 +533,6 @@ They must be specified in uppercase.
* - A64FX
- HOST
- ARMv8.2 with SVE Support
* - WSM
- HOST
- Intel Westmere CPU (SSE 4.2)
* - SNB
- HOST
- Intel Sandy/Ivy Bridge CPU (AVX 1)
@ -566,18 +563,15 @@ They must be specified in uppercase.
* - KNL
- HOST
- Intel Knights Landing Xeon Phi
* - BGQ
- HOST
- IBM Blue Gene/Q CPU
* - POWER7
- HOST
- IBM POWER7 CPU
* - POWER8
- HOST
- IBM POWER8 CPU
* - POWER9
- HOST
- IBM POWER9 CPU
* - RISCV_SG2042
- HOST
- SG2042 (RISC-V) CPU
* - KEPLER30
- GPU
- NVIDIA Kepler generation CC 3.0 GPU
@ -666,7 +660,7 @@ They must be specified in uppercase.
- GPU
- Intel GPU Ponte Vecchio
This list was last updated for version 4.2 of the Kokkos library.
This list was last updated for version 4.3.0 of the Kokkos library.
.. tabs::

4
doc/src/Commands_bond.rst
View File

@ -27,7 +27,7 @@ OPT.
* :doc:`none <bond_none>`
* :doc:`zero <bond_zero>`
* :doc:`hybrid <bond_hybrid>`
* :doc:`hybrid (k) <bond_hybrid>`
*
*
*
@ -89,6 +89,7 @@ OPT.
* :doc:`cosine/shift (o) <angle_cosine_shift>`
* :doc:`cosine/shift/exp (o) <angle_cosine_shift_exp>`
* :doc:`cosine/squared (o) <angle_cosine_squared>`
* :doc:`cosine/squared/restricted (o) <angle_cosine_squared_restricted>`
* :doc:`cross <angle_cross>`
* :doc:`dipole (o) <angle_dipole>`
* :doc:`fourier (o) <angle_fourier>`
@ -127,6 +128,7 @@ OPT.
* :doc:`charmmfsw (k) <dihedral_charmm>`
* :doc:`class2 (ko) <dihedral_class2>`
* :doc:`cosine/shift/exp (o) <dihedral_cosine_shift_exp>`
* :doc:`cosine/squared/restricted <dihedral_cosine_squared_restricted>`
* :doc:`fourier (io) <dihedral_fourier>`
* :doc:`harmonic (iko) <dihedral_harmonic>`
* :doc:`helix (o) <dihedral_helix>`

4
doc/src/Commands_compute.rst
View File

@ -108,6 +108,10 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`pe/mol/tally <compute_tally>`
* :doc:`pe/tally <compute_tally>`
* :doc:`plasticity/atom <compute_plasticity_atom>`
* :doc:`pod/atom <compute_pod_atom>`
* :doc:`podd/atom <compute_pod_atom>`
* :doc:`pod/local <compute_pod_atom>`
* :doc:`pod/global <compute_pod_atom>`
* :doc:`pressure <compute_pressure>`
* :doc:`pressure/alchemy <compute_pressure_alchemy>`
* :doc:`pressure/uef <compute_pressure_uef>`

17
doc/src/Commands_pair.rst
View File

@ -25,16 +25,16 @@ OPT.
* :doc:`none <pair_none>`
* :doc:`zero <pair_zero>`
* :doc:`hybrid (k) <pair_hybrid>`
* :doc:`hybrid/overlay (k) <pair_hybrid>`
* :doc:`hybrid/scaled <pair_hybrid>`
* :doc:`hybrid (ko) <pair_hybrid>`
* :doc:`hybrid/molecular (o) <pair_hybrid>`
* :doc:`hybrid/overlay (ko) <pair_hybrid>`
* :doc:`hybrid/scaled (o) <pair_hybrid>`
* :doc:`kim <pair_kim>`
* :doc:`list <pair_list>`
* :doc:`tracker <pair_tracker>`
*
*
*
*
* :doc:`adp (ko) <pair_adp>`
* :doc:`agni (o) <pair_agni>`
* :doc:`aip/water/2dm (t) <pair_aip_water_2dm>`
@ -94,9 +94,10 @@ OPT.
* :doc:`coul/wolf (ko) <pair_coul>`
* :doc:`coul/wolf/cs <pair_cs>`
* :doc:`dpd (giko) <pair_dpd>`
* :doc:`dpd/fdt <pair_dpd_fdt>`
* :doc:`dpd/coul/slater/long (g) <pair_dpd_coul_slater_long>`
* :doc:`dpd/ext (ko) <pair_dpd_ext>`
* :doc:`dpd/ext/tstat (ko) <pair_dpd_ext>`
* :doc:`dpd/fdt <pair_dpd_fdt>`
* :doc:`dpd/fdt/energy (k) <pair_dpd_fdt>`
* :doc:`dpd/tstat (gko) <pair_dpd>`
* :doc:`dsmc <pair_dsmc>`
@ -245,7 +246,8 @@ OPT.
* :doc:`oxrna2/coaxstk <pair_oxrna2>`
* :doc:`pace (k) <pair_pace>`
* :doc:`pace/extrapolation (k) <pair_pace>`
* :doc:`pod <pair_pod>`
* :doc:`pedone (o) <pair_pedone>`
* :doc:`pod (k) <pair_pod>`
* :doc:`peri/eps <pair_peri>`
* :doc:`peri/lps (o) <pair_peri>`
* :doc:`peri/pmb (o) <pair_peri>`
@ -268,7 +270,7 @@ OPT.
* :doc:`smd/ulsph <pair_smd_ulsph>`
* :doc:`smtbq <pair_smtbq>`
* :doc:`snap (ik) <pair_snap>`
* :doc:`soft (go) <pair_soft>`
* :doc:`soft (gko) <pair_soft>`
* :doc:`sph/heatconduction (g) <pair_sph_heatconduction>`
* :doc:`sph/idealgas <pair_sph_idealgas>`
* :doc:`sph/lj (g) <pair_sph_lj>`
@ -302,6 +304,7 @@ OPT.
* :doc:`tip4p/long/soft (o) <pair_fep_soft>`
* :doc:`tri/lj <pair_tri_lj>`
* :doc:`ufm (got) <pair_ufm>`
* :doc:`uf3 (k) <pair_uf3>`
* :doc:`vashishta (gko) <pair_vashishta>`
* :doc:`vashishta/table (o) <pair_vashishta>`
* :doc:`wf/cut <pair_wf_cut>`

8
doc/src/Commands_removed.rst
View File

@ -148,6 +148,14 @@ performance characteristics on NVIDIA GPUs. Both, the KOKKOS
and the :ref:`GPU package <PKG-GPU>` are maintained
and allow running LAMMPS with GPU acceleration.
i-PI tool
---------
.. versionchanged:: 27June2024
The i-PI tool has been removed from the LAMMPS distribution. Instead,
instructions to install i-PI from PyPI via pip are provided.
restart2data tool
-----------------

47
doc/src/Developer_updating.rst
View File

@ -18,6 +18,7 @@ Available topics in mostly chronological order are:
- `Setting flags in the constructor`_
- `Rename of pack/unpack_comm() to pack/unpack_forward_comm()`_
- `Use ev_init() to initialize variables derived from eflag and vflag`_
- `Use utils::count_words() functions instead of atom->count_words()`_
- `Use utils::numeric() functions instead of force->numeric()`_
- `Use utils::open_potential() function to open potential files`_
- `Use symbolic Atom and AtomVec constants instead of numerical values`_
@ -130,6 +131,41 @@ Not applying this change will not cause a compilation error, but
can lead to inconsistent behavior and incorrect tallying of
energy or virial.
Use utils::count_words() functions instead of atom->count_words()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: 2Jun2020
The "count_words()" functions for parsing text have been moved from the
Atom class to the :doc:`utils namespace <Developer_utils>`. The
"count_words()" function in "utils" uses the Tokenizer class internally
to split a line into words and count them, thus it will not modify the
argument string as the function in the Atoms class did and thus had a
variant using a copy buffer. Unlike the old version, the new version
does not remove comments. For that you can use the
:cpp:func:`utils::trim_comment() function
<LAMMPS_NS::utils::trim_comment>` as shown in the example below.
Old:
.. code-block:: c++
nwords = atom->count_words(line);
int nwords = atom->count_words(buf);
New:
.. code-block:: c++
nwords = utils::count_words(line);
int nwords = utils::count_words(utils::trim_comment(buf));
.. seealso::
:cpp:func:`utils::count_words() <LAMMPS_NS::utils::count_words>`,
:cpp:func:`utils::trim_comments() <LAMMPS_NS::utils::trim_comments>`
Use utils::numeric() functions instead of force->numeric()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -137,11 +173,12 @@ Use utils::numeric() functions instead of force->numeric()
The "numeric()" conversion functions (including "inumeric()",
"bnumeric()", and "tnumeric()") have been moved from the Force class to
the utils namespace. Also they take an additional argument that selects
whether the ``Error::all()`` or ``Error::one()`` function should be
called in case of an error. The former should be used when *all* MPI
processes call the conversion function and the latter *must* be used
when they are called from only one or a subset of the MPI processes.
the :doc:`utils namespace <Developer_utils>`. Also they take an
additional argument that selects whether the ``Error::all()`` or
``Error::one()`` function should be called in case of an error. The
former should be used when *all* MPI processes call the conversion
function and the latter *must* be used when they are called from only
one or a subset of the MPI processes.
Old:

7
doc/src/Developer_utils.rst
View File

@ -211,6 +211,9 @@ Argument processing
.. doxygenfunction:: bounds
:project: progguide
.. doxygenfunction:: bounds_typelabel
:project: progguide
.. doxygenfunction:: expand_args
:project: progguide
@ -635,10 +638,10 @@ Tohoku University (under MIT license)
----------
.. doxygenfunction:: MathEigen::jacobi3(double const *const *mat, double *eval, double **evec)
.. doxygenfunction:: MathEigen::jacobi3(double const *const *mat, double *eval, double **evec, int sort)
:project: progguide
.. doxygenfunction:: MathEigen::jacobi3(double const mat[3][3], double *eval, double evec[3][3])
.. doxygenfunction:: MathEigen::jacobi3(double const mat[3][3], double *eval, double evec[3][3], int sort)
:project: progguide
---------------------------

24
doc/src/Developer_write_pair.rst
View File

@ -50,6 +50,30 @@ We are looking at the following cases:
- `Case 3: a potential requiring communication`_
- `Case 4: potentials without a compute() function`_
Package and build system considerations
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In general, new pair styles should be added to the :ref:`EXTRA-PAIR
package <PKG-EXTRA-PAIR>` unless they are an accelerated pair style and
then they should be added to the corresponding accelerator package
(:ref:`GPU <PKG-GPU>`, :ref:`INTEL <PKG-INTEL>`, :ref:`KOKKOS
<PKG-KOKKOS>`, :ref:`OPENMP <PKG-OPENMP>`, :ref:`OPT <PKG-OPT>`). If
you feel that your contribution should be added to a different package,
please consult with the LAMMPS developers first.
The contributed code needs to support the :doc:`traditional GNU make
build process <Build_make>` **and** the :doc:`CMake build process
<Build_cmake>`. For the GNU make process and if the package has an
``Install.sh`` file, most likely that file needs to be updated to
correctly copy the sources when installing the package and properly
delete them when uninstalling. This is particularly important when
added a new pair style that is a derived class from an existing pair
style in a package, so that its installation depends on the the
installation status of the package of the derived class. For the CMake
process, it is sometimes necessary to make changes to the package
specific CMake scripting in ``cmake/Modules/Packages``.
----
Case 1: a pairwise additive model

49
doc/src/Errors_details.rst
View File

@ -13,15 +13,44 @@ discussions of such cases.
Unknown identifier in data file
-------------------------------
This error happens when LAMMPS encounters a line of text in an unexpected format
while reading a data file. This is most commonly cause by inconsistent header and
section data. The header section informs LAMMPS how many entries or lines are expected in the
various sections (like Atoms, Masses, Pair Coeffs, *etc.*\ ) of the data file.
If there is a mismatch, LAMMPS will either keep reading beyond the end of a section
or stop reading before the section has ended.
This error happens when LAMMPS encounters a line of text with an
unexpected keyword while :doc:`reading a data file <read_data>`. This
would be either header keywords or section header keywords. This is
most commonly due to a mistyped keyword or due to a keyword that is
inconsistent with the :doc:`atom style <atom_style>` used.
Such a mismatch can happen unexpectedly when the first line of the data
is *not* a comment as required by the format. That would result in
LAMMPS expecting, for instance, 0 atoms because the "atoms" header line
is treated as a comment.
The header section informs LAMMPS how many entries or lines are expected
in the various sections (like Atoms, Masses, Pair Coeffs, *etc.*\ ) of
the data file. If there is a mismatch, LAMMPS will either keep reading
beyond the end of a section or stop reading before the section has
ended. In that case the next line will not contain a recognized keyword.
Such a mismatch can also happen when the first line of the data
is *not* a comment as required by the format, but a line with a valid
header keyword. That would result in LAMMPS expecting, for instance,
0 atoms because the "atoms" header line is the first line and thus
treated as a comment.
Another possibility to trigger this error is to have a keyword in the
data file that corresponds to a fix (e.g. :doc:`fix cmap <fix_cmap>`)
but the :doc:`read_data <read_data>` command is missing the (optional)
arguments that identify the fix and the header keyword and section
keyword or those arguments are inconsistent with the keywords in the
data file.
.. _err0002:
Incorrect format in ... section of data file
--------------------------------------------
This error happens when LAMMPS reads the contents of a section of a
:doc:`data file <read_data>` and the number of parameters in the line
differs from what is expected. This most commonly happens, when the
atom style is different from what is expected for a specific data file
since changing the atom style usually changes the format of the line.
This error can also happen when the number of entries indicated in the
header of a data file (e.g. the number of atoms) is larger than the
number of lines provided (e.g. in the corresponding Atoms section)
and then LAMMPS will continue reading into the next section and that
would have a completely different format.

6
doc/src/Errors_messages.rst
View File

@ -7883,12 +7883,6 @@ keyword to allow for additional bonds to be formed
Fix poems cannot (yet) work with coupled bodies whose joints connect
the bodies in a tree structure.
*Triclinic box skew is too large*
The displacement in a skewed direction must be less than half the box
length in that dimension. E.g. the xy tilt must be between -half and
+half of the x box length. This constraint can be relaxed by using
the box tilt command.
*Tried to convert a double to int, but input_double > INT_MAX*
Self-explanatory.

7
doc/src/Errors_warnings.rst
View File

@ -752,13 +752,6 @@ This will most likely cause errors in kinetic fluctuations.
More than the maximum # of neighbors was found multiple times. This
was unexpected.
*Triclinic box skew is large*
The displacement in a skewed direction is normally required to be less
than half the box length in that dimension. E.g. the xy tilt must be
between -half and +half of the x box length. You have relaxed the
constraint using the box tilt command, but the warning means that a
LAMMPS simulation may be inefficient as a result.
*Use special bonds = 0,1,1 with bond style fene*
Most FENE models need this setting for the special_bonds command.

6
doc/src/Fortran.rst
View File

@ -305,6 +305,8 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
:ftype extract_setting: function
:f extract_global: :f:func:`extract_global`
:ftype extract_global: function
:f map_atom: :f:func:`map_atom`
:ftype map_atom: function
:f extract_atom: :f:func:`extract_atom`
:ftype extract_atom: function
:f extract_compute: :f:func:`extract_compute`
@ -1255,8 +1257,8 @@ Procedures Bound to the :f:type:`lammps` Derived Type
three elements of the global vector calculated by fix recenter into the
variables *dx*, *dy*, and *dz*, respectively.
If asked for per-atom or local data, :f:func:`extract_compute` returns a
pointer to actual LAMMPS data. The pointer so returned will have the
If asked for per-atom or local data, :f:func:`extract_fix` returns a
pointer to actual LAMMPS data. The pointer returned will have the
appropriate size to match the internal data, and will be
type/kind/rank-checked at the time of the assignment. For example,

124
doc/src/Howto_2d.rst
View File

@ -1,42 +1,112 @@
2d simulations
==============
================
2d simulations
================
Use the :doc:`dimension <dimension>` command to specify a 2d simulation.
You must use the :doc:`dimension <dimension>` command to specify a 2d
simulation. The default is 3d.
Make the simulation box periodic in z via the :doc:`boundary <boundary>`
command. This is the default.
A 2d simulation box must be periodic in z as set by the :doc:`boundary
<boundary>` command. This is the default.
If using the :doc:`create_box <create_box>` command to define a
simulation box, set the z dimensions narrow, but finite, so that the
:doc:`create_atoms <create_atoms>` command will fill the 3d simulation
box with a single z plane of atoms - e.g.
Simulation boxes in LAMMPS can be either orthogonal or triclinic in
shape. Orthogonal boxes in 2d are a rectangle with 4 edges that are
each perpendicular to either the x or y coordinate axes. Triclinic
boxes in 2d are a parallelogram with opposite pairs of faces parallel
to each other. LAMMPS supports two forms of triclinic boxes,
restricted and general, which for 2d differ in how the box is oriented
with respect to the xy coordinate axes. See the :doc:`Howto triclinic
<Howto_triclinic>` for a detailed description of all 3 kinds of
simulation boxes.
Here are examples of using the :doc:`create_box <create_box>` command
to define the simulation box for a 2d system.
.. code-block:: LAMMPS
create_box 1 -10 10 -10 10 -0.25 0.25
# 2d orthogonal box using a block-style region
region mybox block -10 10 0 10 -0.5 0.5
create_box 1 mybox
If using the :doc:`read_data <read_data>` command to read in a file of
atom coordinates, set the "zlo zhi" values to be finite but narrow,
similar to the create_box command settings just described. For each
atom in the file, assign a z coordinate so it falls inside the
z-boundaries of the box - e.g. 0.0.
# 2d restricted triclinic box using a prism-style region with only xy tilt
region mybox prism 0 10 0 10 -0.5 0.5 2.0 0.0 0.0
create_box 1 mybox
Use the :doc:`fix enforce2d <fix_enforce2d>` command as the last
defined fix to ensure that the z-components of velocities and forces
are zeroed out every timestep. The reason to make it the last fix is
so that any forces induced by other fixes will be zeroed out.
# 2d general triclinic box using a primitive cell for a 2d hex lattice
lattice custom 1.0 a1 1.0 0.0 0.0 a2 0.5 0.86602540378 0.0 &
a3 0.0 0.0 1.0 basis 0.0 0.0 0.0 triclinic/general
create_box 1 NULL 0 5 0 5 -0.5 0.5
Many of the example input scripts included in the LAMMPS distribution
Note that for 2d orthogonal or restricted triclinic boxes, the box has
a 3rd dimension which must straddle z = 0.0 in the z dimension.
Typically the width of box in the z dimension should be narrow,
e.g. -0.5 to 0.5, but that is not required. For a 2d general
triclinic box, the *a3* vector defined by the :doc:`lattice <lattice>`
command must be (0.0,0.0,1.0), which is its default value. Also the
*clo* and *chi* arguments of the :doc:`create_box <create_box>`
command must be -0.5 and 0.5.
Here are examples of using the :doc:`read_data <read_data>` command
to define the simulation box for a 2d system via keywords in the
header section of the data file. These are the same boxes as the examples
for the :doc:`create_box <create_box>` command
.. code-block:: LAMMPS
# 2d orthogonal box
-10 10 xlo xhi
0 10 ylo yhi
-0.5 0.5 zlo zhi # this is the default, so no need to specify
# 2d restricted triclinic box with only xy tilt
-10 10 xlo xhi
0 10 ylo yhi
-0.5 0.5 zlo zhi # this is the default, so no need to specify
2.0 0.0 0.0 xy xz yz
# 3d general triclinic box using a primitive cell for a 2d hex lattice
5 0 0 avec
2.5 4.3301270189 0 bvec
0 0 1 cvec # this is the default, so no need to specify
0 0 -0.5 abc origin # this is the default for 2d, so no need to specify
Note that for 2d orthogonal or restricted triclinic boxes, the box has
a 3rd dimension specified by the *zlo zhi* values, which must straddle
z = 0.0. Typically the width of box in the z dimension should be
narrow, e.g. -0.5 to 0.5, but that is not required. For a 2d general
triclinic box, the z component of *avec* and *bvec* must be zero, and
*cvec* must be (0,0,1), which is the default. The z component of *abc
origin* must also be -0.5, which is the default.
If using the :doc:`create_atoms <create_atoms>` command to create
atoms in the 2d simulation box, all the z coordinates of created atoms
will be zero.
If using the :doc:`read_data <read_data>` command to read in a data
file of atom coordinates for a 2d system, the z coordinates of all
atoms should be zero. A value within epsilon of zero is also allowed
in case the data file was generated by another program with finite
numeric precision, in which case the z coord for the atom will be set
to zero.
Use the :doc:`fix enforce2d <fix_enforce2d>` command as the last fix
defined in the input script. It ensures that the z-components of
velocities and forces are zeroed out every timestep. The reason to
make it the last fix is so that any forces added by other fixes will
also be zeroed out.
Many of the example input scripts included in the examples directory
are for 2d models.
.. note::
Some models in LAMMPS treat particles as finite-size spheres, as
opposed to point particles. See the :doc:`atom_style sphere <atom_style>` and :doc:`fix nve/sphere <fix_nve_sphere>`
commands for details. By default, for 2d simulations, such particles
will still be modeled as 3d spheres, not 2d discs (circles), meaning
opposed to point particles. See the :doc:`atom_style sphere
<atom_style>` and :doc:`fix nve/sphere <fix_nve_sphere>` commands
for details. By default, for 2d simulations, such particles will
still be modeled as 3d spheres, not 2d discs (circles), meaning
their moment of inertia will be that of a sphere. If you wish to
model them as 2d discs, see the :doc:`set density/disc <set>` command
and the *disc* option for the :doc:`fix nve/sphere <fix_nve_sphere>`,
:doc:`fix nvt/sphere <fix_nvt_sphere>`, :doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix npt/sphere <fix_npt_sphere>`
commands.
model them as 2d discs, see the :doc:`set density/disc <set>`
command and the *disc* option for the :doc:`fix nve/sphere
<fix_nve_sphere>`, :doc:`fix nvt/sphere <fix_nvt_sphere>`,
:doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix npt/sphere
<fix_npt_sphere>` commands.

198
doc/src/Howto_bioFF.rst
View File

@ -1,6 +1,10 @@
CHARMM, AMBER, COMPASS, and DREIDING force fields
=================================================
A compact summary of the concepts, definitions, and properties of
force fields with explicit bonded interactions (like the ones discussed
in this HowTo) is given in :ref:`(Gissinger) <Typelabel2>`.
A force field has 2 parts: the formulas that define it and the
coefficients used for a particular system. Here we only discuss
formulas implemented in LAMMPS that correspond to formulas commonly used
@ -11,12 +15,42 @@ commands like :doc:`pair_coeff <pair_coeff>` or :doc:`bond_coeff
<bond_coeff>` and so on. See the :doc:`Tools <Tools>` doc page for
additional tools that can use CHARMM, AMBER, or Materials Studio
generated files to assign force field coefficients and convert their
output into LAMMPS input.
output into LAMMPS input. LAMMPS input scripts can also be generated by
`charmm-gui.org <https://charmm-gui.org/>`_.
See :ref:`(MacKerell) <howto-MacKerell>` for a description of the CHARMM
force field. See :ref:`(Cornell) <howto-Cornell>` for a description of
the AMBER force field. See :ref:`(Sun) <howto-Sun>` for a description
of the COMPASS force field.
CHARMM and AMBER
----------------
The `CHARMM force field
<https://mackerell.umaryland.edu/charmm_ff.shtml>`_ :ref:`(MacKerell)
<howto-MacKerell>` and `AMBER force field
<https://ambermd.org/AmberModels.php>`_ :ref:`(Cornell) <howto-Cornell>`
have potential energy function of the form
.. math::
V & = \sum_{bonds} E_b + \sum_{angles} \!E_a + \!\overbrace{\sum_{dihedral} \!\!E_d}^{\substack{
\text{charmm} \\
\text{charmmfsw}
}} +\!\!\! \sum_{impropers} \!\!\!E_i \\[.6em]
& \quad + \!\!\!\!\!\!\!\!\!\!\underbrace{~\sum_{pairs} \left(E_{LJ}+E_{coul}\right)}_{\substack{
\text{lj/charmm/coul/charmm} \\
\text{lj/charmm/coul/charmm/implicit} \\
\text{lj/charmm/coul/long} \\
\text{lj/charmm/coul/msm} \\
\text{lj/charmmfsw/coul/charmmfsh} \\
\text{lj/charmmfsw/coul/long}
}} \!\!\!\!\!\!\!\!+ \!\!\sum_{special}\! E_s + \!\!\!\!\sum_{residues} \!\!\!{\scriptstyle\mathrm{CMAP}(\phi,\psi)}
The terms are computed by bond styles (relationship between 2 atoms),
angle styles (between 3 atoms) , dihedral/improper styles (between 4
atoms), pair styles (non-covalently bonded pair interactions) and
special bonds. The CMAP term (see :doc:`fix cmap <fix_cmap>` command for
details) corrects for pairs of dihedral angles ("Correction MAP") to
significantly improve the structural and dynamic properties of proteins
in crystalline and solution environments :ref:`(Brooks)
<howto-Brooks>`. The AMBER force field does not include the CMAP term.
The interaction styles listed below compute force field formulas that
are consistent with common options in CHARMM or AMBER. See each
@ -31,10 +65,81 @@ command's documentation for the formula it computes.
* :doc:`pair_style <pair_charmm>` lj/charmm/coul/charmm
* :doc:`pair_style <pair_charmm>` lj/charmm/coul/charmm/implicit
* :doc:`pair_style <pair_charmm>` lj/charmm/coul/long
* :doc:`special_bonds <special_bonds>` charmm
* :doc:`special_bonds <special_bonds>` amber
The pair styles compute Lennard Jones (LJ) and Coulombic interactions
with additional switching or shifting functions that ramp the energy
and/or force smoothly to zero between an inner :math:`(a)` and outer
:math:`(b)` cutoff. The older styles with *charmm* (not *charmmfsw* or
*charmmfsh*\ ) in their name compute the LJ and Coulombic interactions
with an energy switching function (esw) S(r) which ramps the energy
smoothly to zero between the inner and outer cutoff. This can cause
irregularities in pairwise forces (due to the discontinuous second
derivative of energy at the boundaries of the switching region), which
in some cases can result in complications in energy minimization and
detectable artifacts in MD simulations.
.. grid:: 1 1 2 2
.. grid-item::
.. math::
LJ(r) &= 4 \epsilon \left[ \left(\frac{\sigma}{r}\right)^{12} -
\left(\frac{\sigma}{r}\right)^6 \right]\\[.6em]
C(r) &= \frac{C q_i q_j}{ \epsilon r}\\[.6em]
S(r) &= \frac{ \left(b^2 - r^2\right)^2 \left(b^2 + 2r^2 - 3{a^2}\right)}
{ \left(b^2 - a^2\right)^3 }\\[.6em]
E_{LJ}(r) &= \begin{cases}
LJ(r), & r \leq a \\
LJ(r) S(r), & a < r \leq b \\
0, &r > b
\end{cases} \\[.6em]
E_{coul}(r) &= \begin{cases}
C(r), & r \leq a \\
C(r) S(r), & a < r \leq b \\
0, & r > b
\end{cases}
.. grid-item::
.. image:: img/howto_charmm_ELJ.png
:align: center
The newer styles with *charmmfsw* or *charmmfsh* in their name replace
energy switching with force switching (fsw) for LJ interactions and
force shifting (fsh) functions for Coulombic interactions
:ref:`(Steinbach) <howto-Steinbach>`
.. grid:: 1 1 2 2
.. grid-item::
.. math::
E_{LJ}(r) = & \begin{cases}
4 \epsilon \sigma^6 \left(\frac{\displaystyle\sigma
^6-r^6}{\displaystyle r^{12}}-\frac{\displaystyle\sigma ^6}{\displaystyle a^6
b^6}+\frac{\displaystyle 1}{\displaystyle a^3 b^3}\right) & r\leq a \\
\frac{\displaystyle 4 \epsilon \sigma^6 \left(\sigma ^6
\left(b^6-r^6\right)^2-b^3 r^6 \left(a^3+b^3\right)
\left(b^3-r^3\right)^2\right)}{\displaystyle b^6 r^{12}
\left(b^6-a^6\right)} & a<r \leq b\\
0, & r>b
\end{cases}\\[.6em]
E_{coul}(r) & = \begin{cases}
C(r) \frac{\displaystyle (b-r)^2}{\displaystyle r b^2}, & r \leq b \\
0, & r > b
\end{cases}
.. grid-item::
.. image:: img/howto_charmmfsw_ELJ.png
:align: center
These styles are used by LAMMPS input scripts generated by
https://charmm-gui.org/ :ref:`(Brooks) <howto-Brooks>`.
.. note::
For CHARMM, newer *charmmfsw* or *charmmfsh* styles were released in
@ -43,17 +148,33 @@ command's documentation for the formula it computes.
<pair_charmm>` and :doc:`dihedral charmm <dihedral_charmm>` doc
pages.
.. note::
The TIP3P water model is strongly recommended for use with the CHARMM
force field. In fact, `"using the SPC model with CHARMM parameters is
a bad idea"
<https://matsci.org/t/using-spc-water-with-charmm-ff/24715>`_ and `"to
enable TIP4P style water in CHARMM, you would have to write a new pair
style"
<https://matsci.org/t/hybrid-pair-styles-for-charmm-and-tip4p-ew/32609>`_
. LAMMPS input scripts generated by Solution Builder on https://charmm-gui.org
use TIP3P molecules for solvation. Any other water model can and
probably will lead to false conclusions.
COMPASS
-------
COMPASS is a general force field for atomistic simulation of common
organic molecules, inorganic small molecules, and polymers which was
developed using ab initio and empirical parameterization techniques.
See the :doc:`Tools <Tools>` page for the msi2lmp tool for creating
LAMMPS template input and data files from BIOVIA's Materials Studio
files. Please note that the msi2lmp tool is very old and largely
unmaintained, so it does not support all features of Materials Studio
provided force field files, especially additions during the last decade.
You should watch the output carefully and compare results, where
possible. See :ref:`(Sun) <howto-Sun>` for a description of the COMPASS force
field.
developed using ab initio and empirical parameterization techniques
:ref:`(Sun) <howto-Sun>`. See the :doc:`Tools <Tools>` page for the
msi2lmp tool for creating LAMMPS template input and data files from
BIOVIA's Materials Studio files. Please note that the msi2lmp tool is
very old and largely unmaintained, so it does not support all features
of Materials Studio provided force field files, especially additions
during the last decade. You should watch the output carefully and
compare results, where possible. See :ref:`(Sun) <howto-Sun>` for a
description of the COMPASS force field.
These interaction styles listed below compute force field formulas that
are consistent with the COMPASS force field. See each command's
@ -70,14 +191,21 @@ documentation for the formula it computes.
* :doc:`special_bonds <special_bonds>` lj/coul 0 0 1
DREIDING is a generic force field developed by the `Goddard group <http://www.wag.caltech.edu>`_ at Caltech and is useful for
predicting structures and dynamics of organic, biological and main-group
inorganic molecules. The philosophy in DREIDING is to use general force
constants and geometry parameters based on simple hybridization
considerations, rather than individual force constants and geometric
parameters that depend on the particular combinations of atoms involved
in the bond, angle, or torsion terms. DREIDING has an :doc:`explicit hydrogen bond term <pair_hbond_dreiding>` to describe interactions involving a
hydrogen atom on very electronegative atoms (N, O, F).
DREIDING
--------
DREIDING is a generic force field developed by the `Goddard group
<http://www.wag.caltech.edu>`_ at Caltech and is useful for predicting
structures and dynamics of organic, biological and main-group inorganic
molecules. The philosophy in DREIDING is to use general force constants
and geometry parameters based on simple hybridization considerations,
rather than individual force constants and geometric parameters that
depend on the particular combinations of atoms involved in the bond,
angle, or torsion terms. DREIDING has an :doc:`explicit hydrogen bond
term <pair_hbond_dreiding>` to describe interactions involving a
hydrogen atom on very electronegative atoms (N, O, F). Unlike CHARMM
or AMBER, the DREIDING force field has not been parameterized for
considering solvents (like water).
See :ref:`(Mayo) <howto-Mayo>` for a description of the DREIDING force field
@ -110,21 +238,31 @@ documentation for the formula it computes.
----------
.. _Typelabel2:
**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).
.. _howto-MacKerell:
**(MacKerell)** MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
**(MacKerell)** MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field, Fischer, Gao, Guo, Ha, et al (1998). J Phys Chem, 102, 3586 . https://doi.org/10.1021/jp973084f
.. _howto-Cornell:
**(Cornell)** Cornell, Cieplak, Bayly, Gould, Merz, Ferguson,
Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
**(Cornell)** Cornell, Cieplak, Bayly, Gould, Merz, Ferguson, Spellmeyer, Fox, Caldwell, Kollman (1995). JACS 117, 5179-5197. https://doi.org/10.1021/ja00124a002
.. _howto-Steinbach:
**(Steinbach)** Steinbach, Brooks (1994). J Comput Chem, 15, 667. https://doi.org/10.1002/jcc.540150702
.. _howto-Brooks:
**(Brooks)** Brooks, et al (2009). J Comput Chem, 30, 1545. https://onlinelibrary.wiley.com/doi/10.1002/jcc.21287
.. _howto-Sun:
**(Sun)** Sun, J. Phys. Chem. B, 102, 7338-7364 (1998).
**(Sun)** Sun (1998). J. Phys. Chem. B, 102, 7338-7364. https://doi.org/10.1021/jp980939v
.. _howto-Mayo:
**(Mayo)** Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
(1990).
**(Mayo)** Mayo, Olfason, Goddard III (1990). J Phys Chem, 94, 8897-8909. https://doi.org/10.1021/j100389a010

33
doc/src/Howto_body.rst
View File

@ -102,8 +102,19 @@ particles of different styles
| :doc:`dump image <dump_image>` | output body particle attributes as an image |
+------------------------------------------------+-----------------------------------------------------+
The pair styles defined for use with specific body styles are listed
in the sections below.
The pair styles currently defined for use with specific body styles
are listed in the sections below.
Note that for all the body styles, if the data file defines a general
triclinic box, then the orientation of the body particle and its
corresponding 6 moments of inertia and other orientation-dependent
values should reflect the fact the body is defined withing a general
triclinic box with edge vectors **A**,**B**,**C**. LAMMPS will rotate
the box to convert it to a restricted triclinic box. This operation
will also rotate the orientation of the body particles. See the
:doc:`Howto triclinic <Howto_triclinic>` doc page for more details.
The sections below highlight the orientation-dependent values specific
to each body style.
----------
@ -154,12 +165,18 @@ values consistent with the current orientation of the rigid body
around its center of mass. The values are with respect to the
simulation box XYZ axes, not with respect to the principal axes of the
rigid body itself. LAMMPS performs the latter calculation internally.
The coordinates of each sub-particle are specified as its x,y,z
displacement from the center-of-mass of the body particle. The
center-of-mass position of the particle is specified by the x,y,z
values in the *Atoms* section of the data file, as is the total mass
of the body particle.
Note that if the data file defines a general triclinic simulation box,
these sub-particle displacements are orientation-dependent and, as
mentioned above, should reflect the body particle's orientation within
the general triclinic box.
The :doc:`pair_style body/nparticle <pair_body_nparticle>` command can be used
with this body style to compute body/body and body/non-body interactions.
@ -226,6 +243,7 @@ values consistent with the current orientation of the rigid body
around its center of mass. The values are with respect to the
simulation box XYZ axes, not with respect to the principal axes of the
rigid body itself. LAMMPS performs the latter calculation internally.
The coordinates of each vertex are specified as its x,y,z displacement
from the center-of-mass of the body particle. The center-of-mass
position of the particle is specified by the x,y,z values in the
@ -270,6 +288,11 @@ A disk, whose diameter is 3.0, mass 1.0, is specified as follows:
0 0 0
3.0
Note that if the data file defines a general triclinic simulation box,
these polygon vertex displacements are orientation-dependent and, as
mentioned above, should reflect the body particle's orientation within
the general triclinic box.
The :doc:`pair_style body/rounded/polygon <pair_body_rounded_polygon>`
command can be used with this body style to compute body/body
interactions. The :doc:`fix wall/body/polygon <fix_wall_body_polygon>`
@ -366,6 +389,7 @@ values consistent with the current orientation of the rigid body
around its center of mass. The values are with respect to the
simulation box XYZ axes, not with respect to the principal axes of the
rigid body itself. LAMMPS performs the latter calculation internally.
The coordinates of each vertex are specified as its x,y,z displacement
from the center-of-mass of the body particle. The center-of-mass
position of the particle is specified by the x,y,z values in the
@ -435,6 +459,11 @@ A sphere whose diameter is 3.0 and mass 1.0, is specified as follows:
The number of edges and faces for a rod or sphere must be listed,
but is ignored.
Note that if the data file defines a general triclinic simulation box,
these polyhedron vertex displacements are orientation-dependent and,
as mentioned above, should reflect the body particle's orientation
within the general triclinic box.
The :doc:`pair_style body/rounded/polhedron
<pair_body_rounded_polyhedron>` command can be used with this body
style to compute body/body interactions. The :doc:`fix

9
doc/src/Howto_bpm.rst
View File

@ -15,7 +15,8 @@ orientation for rotational models. This produces a stress-free initial
state. Furthermore, bonds are allowed to break under large strains,
producing fracture. The examples/bpm directory has sample input scripts
for simulations of the fragmentation of an impacted plate and the
pouring of extended, elastic bodies.
pouring of extended, elastic bodies. See :ref:`(Clemmer) <howto-Clemmer>`
for more general information on the approach and the LAMMPS implementation.
----------
@ -150,3 +151,9 @@ the following are currently compatible with BPM bond styles:
interactions, one will need to switch between different *special_bonds*
settings in the input script. An example is found in
``examples/bpm/impact``.
----------
.. _howto-Clemmer:
**(Clemmer)** Clemmer, Monti, Lechman, Soft Matter, 20, 1702 (2024).

431
doc/src/Howto_triclinic.rst
View File

@ -2,43 +2,195 @@ Triclinic (non-orthogonal) simulation boxes
===========================================
By default, LAMMPS uses an orthogonal simulation box to encompass the
particles. The :doc:`boundary <boundary>` command sets the boundary
conditions of the box (periodic, non-periodic, etc). The orthogonal
box has its "origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors
starting from the origin given by **a** = (xhi-xlo,0,0); **b** =
(0,yhi-ylo,0); **c** = (0,0,zhi-zlo). The 6 parameters
particles. The orthogonal box has its "origin" at (xlo,ylo,zlo) and
extends to (xhi,yhi,zhi). Conceptually it is defined by 3 edge
vectors starting from the origin given by **A** = (xhi-xlo,0,0); **B**
= (0,yhi-ylo,0); **C** = (0,0,zhi-zlo). The :doc:`boundary
<boundary>` command sets the boundary conditions for the 6 faces of
the box (periodic, non-periodic, etc). The 6 parameters
(xlo,xhi,ylo,yhi,zlo,zhi) are defined at the time the simulation box
is created, e.g. by the :doc:`create_box <create_box>` or
:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
commands. Additionally, LAMMPS defines box size parameters lx,ly,lz
where lx = xhi-xlo, and similarly in the y and z dimensions. The 6
parameters, as well as lx,ly,lz, can be output via the
:doc:`thermo_style custom <thermo_style>` command.
is created by one of these commands:
LAMMPS also allows simulations to be performed in triclinic
(non-orthogonal) simulation boxes shaped as a parallelepiped with
triclinic symmetry. The parallelepiped has its "origin" at
(xlo,ylo,zlo) and is defined by 3 edge vectors starting from the
origin given by **a** = (xhi-xlo,0,0); **b** = (xy,yhi-ylo,0); **c** =
(xz,yz,zhi-zlo). *xy,xz,yz* can be 0.0 or positive or negative values
and are called "tilt factors" because they are the amount of
displacement applied to faces of an originally orthogonal box to
transform it into the parallelepiped. In LAMMPS the triclinic
simulation box edge vectors **a**, **b**, and **c** cannot be arbitrary
vectors. As indicated, **a** must lie on the positive x axis. **b** must
lie in the xy plane, with strictly positive y component. **c** may have
any orientation with strictly positive z component. The requirement
that **a**, **b**, and **c** have strictly positive x, y, and z components,
respectively, ensures that **a**, **b**, and **c** form a complete
right-handed basis. These restrictions impose no loss of generality,
since it is possible to rotate/invert any set of 3 crystal basis
vectors so that they conform to the restrictions.
* :doc:`create_box <create_box>`
* :doc:`read_data <read_data>`
* :doc:`read_restart <read_restart>`
* :doc:`read_dump <read_dump>`
For example, assume that the 3 vectors **A**,\ **B**,\ **C** are the edge
vectors of a general parallelepiped, where there is no restriction on
**A**,\ **B**,\ **C** other than they form a complete right-handed basis i.e.
**A** x **B** . **C** > 0. The equivalent LAMMPS **a**,\ **b**,\ **c** are a linear
rotation of **A**, **B**, and **C** and can be computed as follows:
Internally, LAMMPS defines box size parameters lx,ly,lz where lx =
xhi-xlo, and similarly in the y and z dimensions. The 6 parameters, as
well as lx,ly,lz, can be output via the :doc:`thermo_style custom
<thermo_style>` command. See the :doc:`Howto 2d <Howto_2d>` doc page
for info on how zlo and zhi are defined for 2d simulations.
----------
Triclinic simulation boxes
""""""""""""""""""""""""""
LAMMPS also allows simulations to be performed using triclinic
(non-orthogonal) simulation boxes shaped as a 3d parallelepiped with
triclinic symmetry. For 2d simulations a triclinic simulation box is
effectively a parallelogram; see the :doc:`Howto 2d <Howto_2d>` doc
page for details.
One use of triclinic simulation boxes is to model solid-state crystals
with triclinic symmetry. The :doc:`lattice <lattice>` command can be
used with non-orthogonal basis vectors to define a lattice that will
tile a triclinic simulation box via the :doc:`create_atoms
<create_atoms>` command.
A second use is to run Parrinello-Rahman dynamics via the :doc:`fix
npt <fix_nh>` command, which will adjust the xy, xz, yz tilt factors
to compensate for off-diagonal components of the pressure tensor. The
analog for an :doc:`energy minimization <minimize>` is the :doc:`fix
box/relax <fix_box_relax>` command.
A third use is to shear a bulk solid to study the response of the
material. The :doc:`fix deform <fix_deform>` command can be used for
this purpose. It allows dynamic control of the xy, xz, yz tilt
factors as a simulation runs. This is discussed in the :doc:`Howto
NEMD <Howto_nemd>` doc page on non-equilibrium MD (NEMD) simulations.
Conceptually, a triclinic parallelepiped is defined with an "origin"
at (xlo,ylo,zhi) and 3 edge vectors **A** = (ax,ay,az), **B** =
(bx,by,bz), **C** = (cx,cy,cz) which can be arbitrary vectors, so long
as they are non-zero, distinct, and not co-planar. In addition, they
must define a right-handed system, such that (**A** cross **B**)
points in the direction of **C**. Note that a left-handed system can
be converted to a right-handed system by simply swapping the order of
any pair of the **A**, **B**, **C** vectors.
The 4 commands listed above for defining orthogonal simulation boxes
have triclinic options which allow for specification of the origin and
edge vectors **A**, **B**, **C**. For each command, this can be done
in one of two ways, for what LAMMPS calls a *general* triclinic box or
a *restricted* triclinic box.
A *general* triclinic box is specified by an origin (xlo, ylo, zlo)
and arbitrary edge vectors **A** = (ax,ay,az), **B** = (bx,by,bz), and
**C** = (cx,cy,cz). So there are 12 parameters in total.
A *restricted* triclinic box also has an origin (xlo,ylo,zlo), but its
edge vectors are of the following restricted form: **A** =
(xhi-xlo,0,0), **B** = (xy,yhi-ylo,0), **C** = (xz,yz,zhi-zlo). So
there are 9 parameters in total. Note that the restricted form
requires **A** to be along the x-axis, **B** to be in the xy plane
with a y-component in the +y direction, and **C** to have its
z-component in the +z direction. Note that a restricted triclinic box
is *right-handed* by construction since (**A** cross **B**) points in
the direction of **C**.
The *xy,xz,yz* values can be zero or positive or negative. They are
called "tilt factors" because they are the amount of displacement
applied to edges of faces of an orthogonal box to change it into a
restricted triclinic parallelepiped.
.. note::
Any right-handed general triclinic box (i.e. solid-state crystal
basis vectors) can be rotated in 3d around its origin in order to
conform to the LAMMPS definition of a restricted triclinic box.
See the discussion in the next sub-section about general triclinic
simulation boxes in LAMMPS.
Note that the :doc:`thermo_style custom <thermo_style>` command has
keywords for outputting the various parameters that define the size
and shape of orthogonal, restricted triclinic, and general triclinic
simulation boxes.
For orthogonal boxes there 6 thermo keywords (xlo,ylo,zlo) and
(xhi,yhi,zhi).
For restricted triclinic boxes there are 9 thermo keywords for
(xlo,ylo,zlo), (xhi,yhi,zhi), and the (xy,xz,yz) tilt factors.
For general triclinic boxes there are 12 thermo keywords for
(xlo,ylo,zhi) and the components of the **A**, **B**, **C** edge
vectors, namely (avecx,avecy,avecz), (bvecx,bvecy,bvecz), and
(cvecx,cvecy,cvecz),
The remainder of this doc page explains (a) how LAMMPS operates with
general triclinic simulation boxes, (b) mathematical transformations
between general and restricted triclinic boxes which may be useful
when creating LAMMPS inputs or interpreting outputs for triclinic
simulations, and (c) how LAMMPS uses tilt factors for restricted
triclinic simulation boxes.
----------
General triclinic simulation boxes in LAMMPS
""""""""""""""""""""""""""""""""""""""""""""
LAMMPS allows specification of general triclinic simulation boxes with
their atoms as a convenience for users who may be converting data from
solid-state crystallographic representations or from DFT codes for
input to LAMMPS. Likewise it allows output of dump files, data files,
and thermodynamic data (e.g. pressure tensor) in a general triclinic
format.
However internally, LAMMPS only uses restricted triclinic simulation
boxes. This is for parallel efficiency and to formulate partitioning
of the simulation box across processors, neighbor list building, and
inter-processor communication of per-atom data with methods similar to
those used for orthogonal boxes.
This means 4 things which are important to understand:
* Input of a general triclinic system is immediately converted to a
restricted triclinic system.
* If output of per-atom data for a general triclinic system is
requested (e.g. for atom coordinates in a dump file),
conversion from a restricted to general triclinic system is done at
the time of output.
* The conversion of the simulation box and per-atom data from general
triclinic to restricted triclinic (and vice versa) is a 3d rotation
operation around an origin, which is the lower left corner of the
simulation box. This means an input data file for a general
triclinic system should specify all per-atom quantities consistent
with the general triclinic box and its orientation relative to the
standard x,y,z coordinate axes. For example, atom coordinates
should be inside the general triclinic simulation box defined by the
edge vectors **A**, **B**, **C** and its origin. Likewise per-atom
velocities should be in directions consistent with the general
triclinic box orientation. E.g. a velocity vector which will be in
the +x direction once LAMMPS converts from a general to restricted
triclinic box, should be specified in the data file in the direction
of the **A** edge vector. See the :doc:`read_data <read_data>` doc
page for info on all the per-atom vector quantities to which this
rule applies when a data file for a general triclinic box is input.
* If commands such as :doc:`write_data <write_data>` or :doc:`dump
custom <dump>` are used to output general triclinic information, it
is effectively the inverse of the operation described in the
preceding bullet.
* Other LAMMPS commands such as :doc:`region <region>` or
:doc:`velocity <velocity>` or :doc:`set <set>`, operate on a
restricted triclinic system even if a general triclinic system was
defined initially.
This is the list of commands which have general triclinic options:
* :doc:`create_box <create_box>` - define a general triclinic box
* :doc:`create_atoms <create_atoms>` - add atoms to a general triclinic box
* :doc:`lattice <lattice>` - define a custom lattice consistent with the **A**, **B**, **C** edge vectors of a general triclinic box
* :doc:`read_data <read_data>` - read a data file for a general triclinic system
* :doc:`write_data <write_data>` - write a data file for a general triclinic system
* :doc:`dump atom, dump custom <dump>` - output dump snapshots in general triclinic format
* :doc:`dump_modify triclinic/general <dump_modify>` - select general triclinic format for dump output
* :doc:`thermo_style <thermo_style>` - output the pressure tensor in
general triclinic format
* :doc:`thermo_modify triclinic/general <thermo_modify>` - select general triclinic format for thermo output
* :doc:`read_restart <read_restart>` - read a restart file for a general triclinic system
* :doc:`write_restart <read_restart>` - write a restart file for a general triclinic system
----------
Transformation from general to restricted triclinic boxes
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Let **A**,\ **B**,\ **C** be the right-handed edge vectors of a
general triclinic simulation box. The equivalent LAMMPS **a**,\
**b**,\ **c** for a restricted triclinic box are a 3d rotation of
**A**, **B**, and **C** and can be computed as follows:
.. math::
@ -55,23 +207,17 @@ rotation of **A**, **B**, and **C** and can be computed as follows:
c_y = & \mathbf{C} \cdot \widehat{(\mathbf{A} \times \mathbf{B})} \times \mathbf{\hat{A}} \quad = \quad \frac{\mathbf{B} \cdot \mathbf{C} - b_x c_x}{b_y} \\
c_z = & |\mathbf{C} \cdot \widehat{(\mathbf{A} \times \mathbf{B})}|\quad = \quad \sqrt{C^2 - {c_x}^2 - {c_y}^2}
where A = \| **A** \| indicates the scalar length of **A**\ . The hat symbol (\^)
indicates the corresponding unit vector. :math:`\beta` and :math:`\gamma` are angles
between the vectors described below. Note that by construction,
**a**, **b**, and **c** have strictly positive x, y, and z components, respectively.
If it should happen that
**A**, **B**, and **C** form a left-handed basis, then the above equations
are not valid for **c**\ . In this case, it is necessary
to first apply an inversion. This can be achieved
by interchanging two basis vectors or by changing the sign of one of them.
where A = \| **A** \| indicates the scalar length of **A**\ . The hat
symbol (\^) indicates the corresponding unit vector. :math:`\beta` and
:math:`\gamma` are angles between the **A**, **B**, **C** vectors
as described below.
For consistency, the same rotation/inversion applied to the basis vectors
must also be applied to atom positions, velocities,
and any other vector quantities.
This can be conveniently achieved by first converting to
fractional coordinates in the
old basis and then converting to distance coordinates in the new basis.
The transformation is given by the following equation:
For consistency, the same rotation applied to the triclinic box edge
vectors can also be applied to atom positions, velocities, and other
vector quantities. This can be conveniently achieved by first
converting to fractional coordinates in the general triclinic
coordinates and then converting to coordinates in the restricted
triclinic basis. The transformation is given by the following equation:
.. math::
@ -82,87 +228,24 @@ The transformation is given by the following equation:
\mathbf{A \times B}
\end{pmatrix} \cdot \mathbf{X}
where *V* is the volume of the box, **X** is the original vector quantity and
**x** is the vector in the LAMMPS basis.
where *V* is the volume of the box (same in either basis), **X** is
the fractional vector in the general triclinic basis and **x** is the
resulting vector in the restricted triclinic basis.
There is no requirement that a triclinic box be periodic in any
dimension, though it typically should be in at least the second dimension
of the tilt (y in xy) if you want to enforce a shift in periodic
boundary conditions across that boundary. Some commands that work
with triclinic boxes, e.g. the :doc:`fix deform <fix_deform>` and :doc:`fix npt <fix_nh>` commands, require periodicity or non-shrink-wrap
boundary conditions in specific dimensions. See the command doc pages
for details.
----------
The 9 parameters (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) are defined at the
time the simulation box is created. This happens in one of 3 ways.
If the :doc:`create_box <create_box>` command is used with a region of
style *prism*, then a triclinic box is setup. See the
:doc:`region <region>` command for details. If the
:doc:`read_data <read_data>` command is used to define the simulation
box, and the header of the data file contains a line with the "xy xz
yz" keyword, then a triclinic box is setup. See the
:doc:`read_data <read_data>` command for details. Finally, if the
:doc:`read_restart <read_restart>` command reads a restart file which
was written from a simulation using a triclinic box, then a triclinic
box will be setup for the restarted simulation.
Crystallographic general triclinic representation of a simulation box
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Note that you can define a triclinic box with all 3 tilt factors =
0.0, so that it is initially orthogonal. This is necessary if the box
will become non-orthogonal, e.g. due to the :doc:`fix npt <fix_nh>` or
:doc:`fix deform <fix_deform>` commands. Alternatively, you can use the
:doc:`change_box <change_box>` command to convert a simulation box from
orthogonal to triclinic and vice versa.
As with orthogonal boxes, LAMMPS defines triclinic box size parameters
lx,ly,lz where lx = xhi-xlo, and similarly in the y and z dimensions.
The 9 parameters, as well as lx,ly,lz, can be output via the
:doc:`thermo_style custom <thermo_style>` command.
To avoid extremely tilted boxes (which would be computationally
inefficient), LAMMPS normally requires that no tilt factor can skew
the box more than half the distance of the parallel box length, which
is the first dimension in the tilt factor (x for xz). This is required
both when the simulation box is created, e.g. via the
:doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands,
as well as when the box shape changes dynamically during a simulation,
e.g. via the :doc:`fix deform <fix_deform>` or :doc:`fix npt <fix_nh>`
commands.
For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
the xy tilt factor must be between -5 and 5. Similarly, both xz and
yz must be between -(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is
not a limitation, since if the maximum tilt factor is 5 (as in this
example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
... are geometrically all equivalent. If the box tilt exceeds this
limit during a dynamics run (e.g. via the :doc:`fix deform <fix_deform>`
command), then the box is "flipped" to an equivalent shape with a tilt
factor within the bounds, so the run can continue. See the :doc:`fix deform <fix_deform>` page for further details.
One exception to this rule is if the first dimension in the tilt
factor (x for xy) is non-periodic. In that case, the limits on the
tilt factor are not enforced, since flipping the box in that dimension
does not change the atom positions due to non-periodicity. In this
mode, if you tilt the system to extreme angles, the simulation will
simply become inefficient, due to the highly skewed simulation box.
Box flips that may occur using the :doc:`fix deform <fix_deform>` or
:doc:`fix npt <fix_nh>` commands can be turned off using the *flip no*
option with either of the commands.
Note that if a simulation box has a large tilt factor, LAMMPS will run
less efficiently, due to the large volume of communication needed to
acquire ghost atoms around a processor's irregular-shaped subdomain.
For extreme values of tilt, LAMMPS may also lose atoms and generate an
error.
Triclinic crystal structures are often defined using three lattice
constants *a*, *b*, and *c*, and three angles :math:`\alpha`,
:math:`\beta`, and :math:`\gamma`. Note that in this nomenclature,
the a, b, and c lattice constants are the scalar lengths of the edge
General triclinic crystal structures are often defined using three
lattice constants *a*, *b*, and *c*, and three angles :math:`\alpha`,
:math:`\beta`, and :math:`\gamma`. Note that in this nomenclature, the
a, b, and c lattice constants are the scalar lengths of the edge
vectors **a**, **b**, and **c** defined above. The relationship
between these 6 quantities (a, b, c, :math:`\alpha`, :math:`\beta`,
:math:`\gamma`) and the LAMMPS box sizes (lx,ly,lz) =
(xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:
:math:`\gamma`) and the LAMMPS restricted triclinic box sizes
(lx,ly,lz) = (xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is
as follows:
.. math::
@ -186,15 +269,19 @@ The inverse relationship can be written as follows:
The values of *a*, *b*, *c*, :math:`\alpha` , :math:`\beta`, and
:math:`\gamma` can be printed out or accessed by computes using the
:doc:`thermo_style custom <thermo_style>` keywords
*cella*, *cellb*, *cellc*, *cellalpha*, *cellbeta*, *cellgamma*,
respectively.
:doc:`thermo_style custom <thermo_style>` keywords *cella*, *cellb*,
*cellc*, *cellalpha*, *cellbeta*, *cellgamma*, respectively.
----------
Output of restricted and general triclinic boxes in a dump file
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
As discussed on the :doc:`dump <dump>` command doc page, when the BOX
BOUNDS for a snapshot is written to a dump file for a triclinic box,
an orthogonal bounding box which encloses the triclinic simulation box
is output, along with the 3 tilt factors (xy, xz, yz) of the triclinic
box, formatted as follows:
BOUNDS for a snapshot is written to a dump file for a restricted
triclinic box, an orthogonal bounding box which encloses the triclinic
simulation box is output, along with the 3 tilt factors (xy, xz, yz) of
the restricted triclinic box, formatted as follows:
.. parsed-literal::
@ -204,7 +291,7 @@ box, formatted as follows:
zlo_bound zhi_bound yz
This bounding box is convenient for many visualization programs and is
calculated from the 9 triclinic box parameters
calculated from the 9 restricted triclinic box parameters
(xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) as follows:
.. parsed-literal::
@ -217,22 +304,66 @@ calculated from the 9 triclinic box parameters
zhi_bound = zhi
These formulas can be inverted if you need to convert the bounding box
back into the triclinic box parameters, e.g. xlo = xlo_bound -
MIN(0.0,xy,xz,xy+xz).
back into the restricted triclinic box parameters, e.g. xlo =
xlo_bound - MIN(0.0,xy,xz,xy+xz).
One use of triclinic simulation boxes is to model solid-state crystals
with triclinic symmetry. The :doc:`lattice <lattice>` command can be
used with non-orthogonal basis vectors to define a lattice that will
tile a triclinic simulation box via the
:doc:`create_atoms <create_atoms>` command.
----------
A second use is to run Parrinello-Rahman dynamics via the :doc:`fix npt <fix_nh>` command, which will adjust the xy, xz, yz tilt
factors to compensate for off-diagonal components of the pressure
tensor. The analog for an :doc:`energy minimization <minimize>` is
the :doc:`fix box/relax <fix_box_relax>` command.
Periodicity and tilt factors for triclinic simulation boxes
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
A third use is to shear a bulk solid to study the response of the
material. The :doc:`fix deform <fix_deform>` command can be used for
this purpose. It allows dynamic control of the xy, xz, yz tilt
factors as a simulation runs. This is discussed in the next section
on non-equilibrium MD (NEMD) simulations.
There is no requirement that a triclinic box be periodic in any
dimension, though it typically should be in y or z if you wish to
enforce a shift in coordinates due to periodic boundary conditions
across the y or z boundaries. See the doc page for the :doc:`boundary
<boundary>` command for an explanation of shifted coordinates for
restricted triclinic boxes which are periodic.
Some commands that work with triclinic boxes, e.g. the :doc:`fix
deform <fix_deform>` and :doc:`fix npt <fix_nh>` commands, require
periodicity or non-shrink-wrap boundary conditions in specific
dimensions. See the command doc pages for details.
A restricted triclinic box can be defined with all 3 tilt factors =
0.0, so that it is initially orthogonal. This is necessary if the box
will become non-orthogonal, e.g. due to use of the :doc:`fix npt
<fix_nh>` or :doc:`fix deform <fix_deform>` commands. Alternatively,
you can use the :doc:`change_box <change_box>` command to convert a
simulation box from orthogonal to restricted triclinic and vice versa.
.. note::
Highly tilted restricted triclinic simulation boxes can be
computationally inefficient. This is due to the large volume of
communication needed to acquire ghost atoms around a processor's
irregular-shaped subdomain. For extreme values of tilt, LAMMPS may
also lose atoms and generate an error.
LAMMPS will issue a warning if you define a restricted triclinic box
with a tilt factor which skews the box more than half the distance of
the parallel box length, which is the first dimension in the tilt
factor (e.g. x for xz).
For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
the xy tilt factor should be between -5 and 5 to avoid the warning.
Similarly, both xz and yz should be between -(xhi-xlo)/2 and
+(yhi-ylo)/2. Note that these are not limitations, since if the
maximum tilt factor is 5 (as in this example), then simulations boxes
and atom configurations with tilt = ..., -15, -5, 5, 15, 25, ... are
all geometrically equivalent.
If the box tilt exceeds this limit during a dynamics run (e.g. due to
the :doc:`fix deform <fix_deform>` command), then by default the box
is "flipped" to an equivalent shape with a tilt factor within the
warning bounds, and the run continues. See the :doc:`fix deform
<fix_deform>` page for further details. Box flips that would normally
occur using the :doc:`fix deform <fix_deform>` or :doc:`fix npt
<fix_nh>` commands can be suppressed using the *flip no* option with
either of the commands.
One exception to box flipping is if the first dimension in the tilt
factor (e.g. x for xy) is non-periodic. In that case, the limits on
the tilt factor are not enforced, since flipping the box in that
dimension would not change the atom positions due to non-periodicity.
In this mode, if the system tilts to large angles, the simulation will
simply become inefficient, due to the highly skewed simulation box.

25
doc/src/Howto_type_labels.rst
View File

@ -14,16 +14,17 @@ wherever they appear in LAMMPS input or output files. The total number
Ntypes for each interaction is "locked in" when the simulation box
is created.
A recent addition to LAMMPS is the option to use strings - referred
to as type labels - as an alternative. Using type labels instead of
A recent addition to LAMMPS is the option to use strings - referred to
as type labels - as an alternative. Using type labels instead of
numeric types can be advantageous in various scenarios. For example,
type labels can make inputs more readable and generic (i.e. usable through
the :doc:`include command <include>` for different systems with different
numerical values assigned to types. This generality also applies to
other inputs like data files read by :doc:`read_data <read_data>` or
molecule template files read by the :doc:`molecule <molecule>`
command. See below for a list of other commands that can use
type labels in different ways.
type labels can make inputs more readable and generic (i.e. usable
through the :doc:`include command <include>` for different systems with
different numerical values assigned to types. This generality also
applies to other inputs like data files read by :doc:`read_data
<read_data>` or molecule template files read by the :doc:`molecule
<molecule>` command. A discussion of the current type label support can
be found in :ref:`(Gissinger) <Typelabel24>`. See below for a list of
other commands that can use type labels in different ways.
LAMMPS will *internally* continue to use numeric types, which means
that many previous restrictions still apply. For example, the total
@ -124,3 +125,9 @@ between the files. The creation of simulation-ready reaction templates
for :doc:`fix bond/react <fix_bond_react>` is much simpler when using
type labels, and results in templates that can be used without
modification in multiple simulations or different systems.
-----------
.. _Typelabel24:
**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).

2
doc/src/Intro_citing.rst
View File

@ -47,6 +47,8 @@ In addition there are DOIs generated for individual stable releases:
- 3 March 2020 version: `DOI:10.5281/zenodo.3726417 <https://dx.doi.org/10.5281/zenodo.3726417>`_
- 29 October 2020 version: `DOI:10.5281/zenodo.4157471 <https://dx.doi.org/10.5281/zenodo.4157471>`_
- 29 September 2021 version: `DOI:10.5281/zenodo.6386596 <https://dx.doi.org/10.5281/zenodo.6386596>`_
- 23 June 2022 version: `DOI:10.5281/zenodo.10806836 <https://doi.org/10.5281/zenodo.10806836>`_
- 2 August 2023 version: `DOI:10.5281/zenodo.10806852 <https://doi.org/10.5281/zenodo.10806852>`_
Home page
^^^^^^^^^

4
doc/src/Intro_features.rst
View File

@ -29,7 +29,7 @@ General features
* spatial decomposition of simulation domain for MPI parallelism
* particle decomposition inside spatial decomposition for OpenMP and GPU parallelism
* GPLv2 licensed open-source distribution
* highly portable C++-11
* highly portable C++-11 (optional packages may require C++17)
* modular code with most functionality in optional packages
* only depends on MPI library for basic parallel functionality, MPI stub for serial compilation
* other libraries are optional and only required for specific packages
@ -81,7 +81,7 @@ commands)
* pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, Yukawa, soft, Class II (COMPASS), hydrogen bond, harmonic, gaussian, tabulated, scripted
* charged pairwise potentials: Coulombic, point-dipole
* many-body potentials: EAM, Finnis/Sinclair, MEAM, MEAM+SW, EIM, EDIP, ADP, Stillinger-Weber, Tersoff, REBO, AIREBO, ReaxFF, COMB, Streitz-Mintmire, 3-body polymorphic, BOP, Vashishta
* machine learning potentials: ACE, AGNI, GAP, Behler-Parrinello (N2P2), POD, RANN
* machine learning potentials: ACE, AGNI, GAP, Behler-Parrinello (N2P2), POD, RANN, SNAP
* interfaces to ML potentials distributed by external groups: ANI, ChIMES, DeepPot, HIPNN, MTP
* long-range interactions for charge, point-dipoles, and LJ dispersion: Ewald, Wolf, PPPM (similar to particle-mesh Ewald), MSM, ScaFaCoS
* polarization models: :doc:`QEq <fix_qeq>`, :doc:`core/shell model <Howto_coreshell>`, :doc:`Drude dipole model <Howto_drude>`

6
doc/src/Library_properties.rst
View File

@ -13,6 +13,7 @@ This section documents the following functions:
- :cpp:func:`lammps_extract_setting`
- :cpp:func:`lammps_extract_global_datatype`
- :cpp:func:`lammps_extract_global`
- :cpp:func:`lammps_map_atom`
--------------------
@ -120,3 +121,8 @@ subdomains and processors.
.. doxygenfunction:: lammps_extract_global
:project: progguide
-----------------------
.. doxygenfunction:: lammps_map_atom
:project: progguide

52
doc/src/Packages_details.rst
View File

@ -52,6 +52,7 @@ page gives those details.
* :ref:`DRUDE <PKG-DRUDE>`
* :ref:`EFF <PKG-EFF>`
* :ref:`ELECTRODE <PKG-ELECTRODE>`
* :ref:`EXTRA-COMMAND <PKG-EXTRA-COMMAND>`
* :ref:`EXTRA-COMPUTE <PKG-EXTRA-COMPUTE>`
* :ref:`EXTRA-DUMP <PKG-EXTRA-DUMP>`
* :ref:`EXTRA-FIX <PKG-EXTRA-FIX>`
@ -84,6 +85,7 @@ page gives those details.
* :ref:`ML-QUIP <PKG-ML-QUIP>`
* :ref:`ML-RANN <PKG-ML-RANN>`
* :ref:`ML-SNAP <PKG-ML-SNAP>`
* :ref:`ML-UF3 <PKG-ML-UF3>`
* :ref:`MOFFF <PKG-MOFFF>`
* :ref:`MOLECULE <PKG-MOLECULE>`
* :ref:`MOLFILE <PKG-MOLFILE>`
@ -403,6 +405,7 @@ and :ref:`ASPHERE <PKG-ASPHERE>` packages are installed.
* :doc:`bond_style oxdna2/\* <bond_oxdna>`
* :doc:`bond_style oxrna2/\* <bond_oxdna>`
* :doc:`fix nve/dotc/langevin <fix_nve_dotc_langevin>`
* examples/PACKAGES/cgdna
----------
@ -676,7 +679,12 @@ DPD-BASIC package
Pair styles for the basic dissipative particle dynamics (DPD) method
and DPD thermostatting.
**Author:** Kurt Smith (U Pittsburgh), Martin Svoboda, Martin Lisal (ICPF and UJEP)
Pair style :doc:`dpd/coul/slater/long <pair_dpd_coul_slater_long>` also
includes smeared charges for coulomb interactions and thus requires the
:ref:`KSPACE <PKG-KSPACE>` package to be installed to handle the long-range
Coulomb part of the interactions.
**Authors:** Kurt Smith (U Pittsburgh), Martin Svoboda, Martin Lisal (ICPF and UJEP), Eddy Barraud (IFPEN)
**Supporting info:**
@ -685,6 +693,7 @@ and DPD thermostatting.
* :doc:`pair_style dpd/tstat <pair_dpd>`
* :doc:`pair_style dpd/ext <pair_dpd_ext>`
* :doc:`pair_style dpd/ext/tstat <pair_dpd_ext>`
* :doc:`pair_style dpd/coul/slater/long <pair_dpd_coul_slater_long>`
* examples/PACKAGES/dpd-basic
----------
@ -886,6 +895,22 @@ This package has :ref:`specific installation instructions <electrode>` on the
----------
.. _PKG-EXTRA-COMMAND:
EXTRA-COMMAND package
---------------------
**Contents:**
Additional command styles that are less commonly used.
**Supporting info:**
* src/EXTRA-COMMAND: filenames -> commands
* :doc:`general commands <Commands_all>`
----------
.. _PKG-EXTRA-COMPUTE:
EXTRA-COMPUTE package
@ -1925,6 +1950,31 @@ computes which analyze attributes of the potential.
----------
.. _PKG-ML-UF3:
ML-UF3 package
--------------
**Contents:**
A pair style for the ultra-fast force field potentials (UF3). UF3 is a
methodology for deriving a highly accurate classical potential which is
fast to evaluate and is fitted to a large archives of quantum mechanical
(DFT) data. The use of b-spline basis set in UF3 enables the rapid
evaluation of 2-body and 3-body interactions.
**Authors:** Ajinkya C Hire (University of Florida),
Hendrik Krass (University of Constance),
Matthias Rupp (Luxembourg Institute of Science and Technology),
Richard Hennig (University of Florida)
**Supporting info:**
* src/ML-UF3: filenames -> commands
* :doc:`pair_style uf3 <pair_uf3>`
* examples/uf3
* https://github.com/uf3/uf3
.. _PKG-MOFFF:
MOFFF package

10
doc/src/Packages_list.rst
View File

@ -158,6 +158,11 @@ whether an extra library is needed to build and use the package:
- :doc:`fix electrode/conp <fix_electrode>`
- PACKAGES/electrode
- no
* - :ref:`EXTRA-COMMAND <PKG-EXTRA-COMMAND>`
- additional command styles
- :doc:`general commands <Commands_all>`
- n/a
- no
* - :ref:`EXTRA-COMPUTE <PKG-EXTRA-COMPUTE>`
- additional compute styles
- :doc:`compute <compute>`
@ -318,6 +323,11 @@ whether an extra library is needed to build and use the package:
- :doc:`pair_style snap <pair_snap>`
- snap
- no
* - :ref:`ML-UF3 <PKG-ML-UF3>`
- quantum-fitted ultra fast potentials
- :doc:`pair_style uf3 <pair_uf3>`
- PACKAGES/uf3
- no
* - :ref:`MOFFF <PKG-MOFFF>`
- styles for `MOF-FF <MOFplus_>`_ force field
- :doc:`pair_style buck6d/coul/gauss <pair_buck6d_coul_gauss>`

17
doc/src/Python_scatter.rst
View File

@ -54,8 +54,21 @@ like this:
x[3] = x coord of atom with ID 2
...
x[n3-1] = z coord of atom with ID natoms
lmp.scatter_atoms("x",1,3,x)
lmp.scatter_atoms("x", 1, 3, x)
The coordinates can also be provided as arguments to the initializer of x:
.. code-block:: python
from ctypes import c_double
natoms = 2
n3 = 3*natoms
# init in constructor
x = (n3*c_double)(0.0, 0.0, 0.0, 1.0, 1.0, 1.0)
lmp.scatter_atoms("x", 1, 3, x)
# or using a list
coords = [1.0, 2.0, 3.0, -3.0, -2.0, -1.0]
x = (c_double*len(coords))(*coords)
Alternatively, you can just change values in the vector returned by
the gather methods, since they are also ctypes vectors.

72
doc/src/Tools.rst
View File

@ -90,7 +90,7 @@ Miscellaneous tools
* :ref:`LAMMPS coding standards <coding_standard>`
* :ref:`emacs <emacs>`
* :ref:`i-pi <ipi>`
* :ref:`i-PI <ipi>`
* :ref:`kate <kate>`
* :ref:`LAMMPS shell <lammps_shell>`
* :ref:`LAMMPS GUI <lammps_gui>`
@ -376,21 +376,40 @@ See README file in the tools/fep directory.
.. _ipi:
i-pi tool
i-PI tool
-------------------
The tools/i-pi directory contains a version of the i-PI package, with
all the LAMMPS-unrelated files removed. It is provided so that it can
be used with the :doc:`fix ipi <fix_ipi>` command to perform
path-integral molecular dynamics (PIMD).
.. versionchanged:: 27June2024
The tools/i-pi directory used to contain a bundled version of the i-PI
software package for use with LAMMPS. This version, however, was
removed in 06/2024.
The i-PI package was created and is maintained by Michele Ceriotti,
michele.ceriotti at gmail.com, to interface to a variety of molecular
dynamics codes.
See the tools/i-pi/manual.pdf file for an overview of i-PI, and the
:doc:`fix ipi <fix_ipi>` page for further details on running PIMD
calculations with LAMMPS.
i-PI is now available via PyPI using the pip package manager at:
https://pypi.org/project/ipi/
Here are the commands to set up a virtual environment and install
i-PI into it with all its dependencies.
.. code-block:: sh
python -m venv ipienv
source ipienv/bin/activate
pip install --upgrade pip
pip install ipi
To install the development version from GitHub, please use:
.. code-block:: sh
pip install git+https://github.com/i-pi/i-pi.git
For further information, please consult the [i-PI home
page](https://ipi-code.org).
----------
@ -709,8 +728,8 @@ CMake is required.
The LAMMPS GUI has been successfully compiled and tested on:
- Ubuntu Linux 20.04LTS x86_64 using GCC 9, Qt version 5.12
- Fedora Linux 38 x86\_64 using GCC 13 and Clang 16, Qt version 5.15LTS
- Fedora Linux 38 x86\_64 using GCC 13, Qt version 6.5LTS
- Fedora Linux 40 x86\_64 using GCC 14 and Clang 17, Qt version 5.15LTS
- Fedora Linux 40 x86\_64 using GCC 14, Qt version 6.5LTS
- Apple macOS 12 (Monterey) and macOS 13 (Ventura) with Xcode on arm64 and x86\_64, Qt version 5.15LTS
- Windows 10 and 11 x86_64 with Visual Studio 2022 and Visual C++ 14.36, Qt version 5.15LTS
- Windows 10 and 11 x86_64 with MinGW / GCC 10.0 cross-compiler on Fedora 38, Qt version 5.15LTS
@ -752,22 +771,23 @@ if necessary. When both, Qt5 and Qt6 are available, Qt6 will be preferred
unless ``-D LAMMPS_GUI_USE_QT5=yes`` is set.
It should be possible to build the LAMMPS GUI as a standalone
compilation (e.g. when LAMMPS has been compiled with traditional make),
then the CMake configuration needs to be told where to find the LAMMPS
compilation (e.g. when LAMMPS has been compiled with traditional make).
Then the CMake configuration needs to be told where to find the LAMMPS
headers and the LAMMPS library, via ``-D
LAMMPS_SOURCE_DIR=/path/to/lammps/src``. CMake will try to guess a
build folder with the LAMMPS library from that path, but it can also be
set with ``-D LAMMPS_LIB_DIR=/path/to/lammps/lib``.
Rather than linking to the LAMMPS library during compilation, it is also
possible to compile the GUI with a plugin loader library that will load
possible to compile the GUI with a plugin loader that will load
the LAMMPS library dynamically at runtime during the start of the GUI
from a shared library; e.g. ``liblammps.so`` or ``liblammps.dylib`` or
``liblammps.dll`` (depending on the operating system). This has the
advantage that the LAMMPS library can be updated LAMMPS without having
to recompile the GUI. The ABI of the LAMMPS C-library interface is very
stable and generally backward compatible. This feature is enabled by
setting ``-D LAMMPS_GUI_USE_PLUGIN=on`` and then ``-D
advantage that the LAMMPS library can be built from updated or modified
LAMMPS source without having to recompile the GUI. The ABI of the
LAMMPS C-library interface is very stable and generally backward
compatible. This feature is enabled by setting
``-D LAMMPS_GUI_USE_PLUGIN=on`` and then ``-D
LAMMPS_PLUGINLIB_DIR=/path/to/lammps/plugin/loader``. Typically, this
would be the ``examples/COUPLE/plugin`` folder of the LAMMPS
distribution.
@ -779,8 +799,8 @@ macOS
"""""
When building on macOS, the build procedure will try to manufacture a
drag-n-drop installer, LAMMPS-macOS-multiarch.dmg, when using the 'dmg'
target (i.e. ``cmake --build <build dir> --target dmg`` or ``make dmg``.
drag-n-drop installer, ``LAMMPS-macOS-multiarch.dmg``, when using the
'dmg' target (i.e. ``cmake --build <build dir> --target dmg`` or ``make dmg``.
To build multi-arch executables that will run on both, arm64 and x86_64
architectures natively, it is necessary to set the CMake variable ``-D
@ -819,12 +839,12 @@ and LAMMPS GUI can be launched from anywhere from the command line.
The standard CMake build procedure can be applied and the
``mingw-cross.cmake`` preset used. By using ``mingw64-cmake`` the CMake
command will automatically include a suitable CMake toolset file (the
regular cmake command can be used after that). After building the
libraries and executables, you can build the target 'zip'
(i.e. ``cmake --build <build dir> --target zip`` or ``make zip``
to stage all installed files into a LAMMPS_GUI folder and then
run a script to copy all required dependencies, some other files,
command will automatically include a suitable CMake toolchain file (the
regular cmake command can be used after that to modify the configuration
settings, if needed). After building the libraries and executables,
you can build the target 'zip' (i.e. ``cmake --build <build dir> --target zip``
or ``make zip`` to stage all installed files into a LAMMPS_GUI folder
and then run a script to copy all required dependencies, some other files,
and create a zip file from it.
Linux

80
doc/src/angle_cosine_squared_restricted.rst Normal file
View File

@ -0,0 +1,80 @@
.. index:: angle_style cosine/squared/restricted
.. index:: angle_style cosine/squared/restricted/omp
angle_style cosine/squared/restricted command
=============================================
Accelerator Variants: *cosine/squared/restricted/omp*
Syntax
""""""
.. code-block:: LAMMPS
angle_style cosine/squared/restricted
Examples
""""""""
.. code-block:: LAMMPS
angle_style cosine/squared/restricted
angle_coeff 2*4 75.0 100.0
Description
"""""""""""
.. versionadded:: 17Apr2024
The *cosine/squared/restricted* angle style uses the potential
.. math::
E = K [\cos(\theta) - \cos(\theta_0)]^2 / \sin^2(\theta)
, which is commonly used in the MARTINI force field,
where :math:`\theta_0` is the equilibrium value of the angle, and :math:`K`
is a prefactor. Note that the usual 1/2 factor is included in :math:`K`.
See :ref:`(Bulacu) <restricted-Bulacu>` for a description of the restricted angle for the MARTINI force field.
The following coefficients must be defined for each angle type via the
:doc:`angle_coeff <angle_coeff>` command as in the example above, or in
the data file or restart files read by the :doc:`read_data <read_data>`
or :doc:`read_restart <read_restart>` commands:
* :math:`K` (energy)
* :math:`\theta_0` (degrees)
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to radians
internally.
----------
.. include:: accel_styles.rst
----------
Restrictions
""""""""""""
This angle style can only be used if LAMMPS was built with the
EXTRA-MOLECULE package. See the :doc:`Build package <Build_package>` doc page
for more info.
Related commands
""""""""""""""""
:doc:`angle_coeff <angle_coeff>`
Default
"""""""
none
----------
.. _restricted-Bulacu:
**(Bulacu)** Bulacu, Goga, Zhao, Rossi, Monticelli, Periole, Tieleman, Marrink, J Chem Theory Comput, 9, 3282-3292
(2013).

3
doc/src/angle_style.rst
View File

@ -10,7 +10,7 @@ Syntax
angle_style style
* style = *none* or *zero* or *hybrid* or *amoeba* or *charmm* or *class2* or *class2/p6* or *cosine* or *cosine/buck6d* or *cosine/delta* or *cosine/periodic* or *cosine/shift* or *cosine/shift/exp* or *cosine/squared* or *cross* or *dipole* or *fourier* or *fourier/simple* or *gaussian* or *harmonic* or *lepton* or *mm3* or *quartic* or *spica* or *table*
* style = *none* or *zero* or *hybrid* or *amoeba* or *charmm* or *class2* or *class2/p6* or *cosine* or *cosine/buck6d* or *cosine/delta* or *cosine/periodic* or *cosine/shift* or *cosine/shift/exp* or *cosine/squared* or *cosine/squared/restricted* or *cross* or *dipole* or *fourier* or *fourier/simple* or *gaussian* or *harmonic* or *lepton* or *mm3* or *quartic* or *spica* or *table*
Examples
""""""""
@ -84,6 +84,7 @@ of (g,i,k,o,t) to indicate which accelerated styles exist.
* :doc:`cosine/shift <angle_cosine_shift>` - angle cosine with a shift
* :doc:`cosine/shift/exp <angle_cosine_shift_exp>` - cosine with shift and exponential term in spring constant
* :doc:`cosine/squared <angle_cosine_squared>` - angle with cosine squared term
* :doc:`cosine/squared/restricted <angle_cosine_squared_restricted>` - angle with restricted cosine squared term
* :doc:`cross <angle_cross>` - cross term coupling angle and bond lengths
* :doc:`dipole <angle_dipole>` - angle that controls orientation of a point dipole
* :doc:`fourier <angle_fourier>` - angle with multiple cosine terms

99
doc/src/atom_modify.rst
View File

@ -71,11 +71,11 @@ all atoms, e.g. in a data or restart file.
atom IDs are required, due to how neighbor lists are built.
The *map* keyword determines how atoms with specific IDs are found
when required. An example are the bond (angle, etc) methods which
need to find the local index of an atom with a specific global ID
which is a bond (angle, etc) partner. LAMMPS performs this operation
efficiently by creating a "map", which is either an *array* or *hash*
table, as described below.
when required. For example, the bond (angle, etc) methods need to
find the local index of an atom with a specific global ID which is a
bond (angle, etc) partner. LAMMPS performs this operation efficiently
by creating a "map", which is either an *array* or *hash* table, as
described below.
When the *map* keyword is not specified in your input script, LAMMPS
only creates a map for :doc:`atom_styles <atom_style>` for molecular
@ -83,34 +83,39 @@ systems which have permanent bonds (angles, etc). No map is created
for atomic systems, since it is normally not needed. However some
LAMMPS commands require a map, even for atomic systems, and will
generate an error if one does not exist. The *map* keyword thus
allows you to force the creation of a map. The *yes* value will
create either an *array* or *hash* style map, as explained in the next
paragraph. The *array* and *hash* values create an array-style or
hash-style map respectively.
allows you to force the creation of a map.
For an *array*\ -style map, each processor stores a lookup table of
length N, where N is the largest atom ID in the system. This is a
fast, simple method for many simulations, but requires too much memory
for large simulations. For a *hash*\ -style map, a hash table is
created on each processor, which finds an atom ID in constant time
(independent of the global number of atom IDs). It can be slightly
slower than the *array* map, but its memory cost is proportional to
the number of atoms owned by a processor, i.e. N/P when N is the total
number of atoms in the system and P is the number of processors.
Specifying a value of *yes* will create either an array-style or
hash-style map, depending on the size of the system. If no atom ID is
larger than 1 million, then an array-style map is used, otherwise a
hash-style map is used. Specifying a value of *array* or *hash*
creates an array-style or hash-style map respectively, regardless of
the size of the system.
The *first* keyword allows a :doc:`group <group>` to be specified whose
atoms will be maintained as the first atoms in each processor's list
of owned atoms. This in only useful when the specified group is a
small fraction of all the atoms, and there are other operations LAMMPS
is performing that will be sped-up significantly by being able to loop
over the smaller set of atoms. Otherwise the reordering required by
this option will be a net slow-down. The :doc:`neigh_modify include <neigh_modify>` and :doc:`comm_modify group <comm_modify>`
commands are two examples of commands that require this setting to
work efficiently. Several :doc:`fixes <fix>`, most notably time
integration fixes like :doc:`fix nve <fix_nve>`, also take advantage of
this setting if the group they operate on is the group specified by
this command. Note that specifying "all" as the group-ID effectively
turns off the *first* option.
For an array-style map, each processor stores a lookup table of length
N, where N is the largest atom ID in the system. This is a fast,
simple method for many simulations, but requires too much memory for
large simulations. For a hash-style map, a hash table is created on
each processor, which finds an atom ID in constant time (independent
of the global number of atom IDs). It can be slightly slower than the
*array* map, but its memory cost is proportional to the number of
atoms owned by a processor, i.e. N/P when N is the total number of
atoms in the system and P is the number of processors.
The *first* keyword allows a :doc:`group <group>` to be specified
whose atoms will be maintained as the first atoms in each processor's
list of owned atoms. This in only useful when the specified group is
a small fraction of all the atoms, and there are other operations
LAMMPS is performing that will be sped-up significantly by being able
to loop over the smaller set of atoms. Otherwise the reordering
required by this option will be a net slow-down. The
:doc:`neigh_modify include <neigh_modify>` and :doc:`comm_modify group
<comm_modify>` commands are two examples of commands that require this
setting to work efficiently. Several :doc:`fixes <fix>`, most notably
time integration fixes like :doc:`fix nve <fix_nve>`, also take
advantage of this setting if the group they operate on is the group
specified by this command. Note that specifying "all" as the group-ID
effectively turns off the *first* option.
It is OK to use the *first* keyword with a group that has not yet been
defined, e.g. to use the atom_modify first command at the beginning of
@ -148,15 +153,16 @@ cache locality will be undermined.
.. note::
Running a simulation with sorting on versus off should not
change the simulation results in a statistical sense. However, a
different ordering will induce round-off differences, which will lead
to diverging trajectories over time when comparing two simulations.
Various commands, particularly those which use random numbers
(e.g. :doc:`velocity create <velocity>`, and :doc:`fix langevin <fix_langevin>`), may generate (statistically identical)
results which depend on the order in which atoms are processed. The
order of atoms in a :doc:`dump <dump>` file will also typically change
if sorting is enabled.
Running a simulation with sorting on versus off should not change
the simulation results in a statistical sense. However, a
different ordering will induce round-off differences, which will
lead to diverging trajectories over time when comparing two
simulations. Various commands, particularly those which use random
numbers (e.g. :doc:`velocity create <velocity>`, and :doc:`fix
langevin <fix_langevin>`), may generate (statistically identical)
results which depend on the order in which atoms are processed.
The order of atoms in a :doc:`dump <dump>` file will also typically
change if sorting is enabled.
.. note::
@ -183,12 +189,13 @@ Default
By default, *id* is yes. By default, atomic systems (no bond topology
info) do not use a map. For molecular systems (with bond topology
info), a map is used. The default map style is array if no atom ID is
larger than 1 million, otherwise the default is hash. By default, a
"first" group is not defined. By default, sorting is enabled with a
frequency of 1000 and a binsize of 0.0, which means the neighbor
cutoff will be used to set the bin size. If no neighbor cutoff is
defined, sorting will be turned off.
info), the default is to use a map of either *array* or *hash* style
depending on the size of the sustem, as explained above for the *map
yes* keyword/value option. By default, a *first* group is not
defined. By default, sorting is enabled with a frequency of 1000 and
a binsize of 0.0, which means the neighbor cutoff will be used to set
the bin size. If no neighbor cutoff is defined, sorting will be turned
off.
----------

27
doc/src/atom_style.rst
View File

@ -283,21 +283,22 @@ Note that there may be additional arguments required along with the
arguments are described on the :doc:`Howto body <Howto_body>` doc page.
For the *dielectric* style, each particle can be either a physical
particle (e.g. an ion), or an interface particle representing a boundary
element between two regions of different dielectric constant. For
interface particles, in addition to the properties associated with
atom_style full, each particle also should be assigned a normal unit
vector (defined by normx, normy, normz), an area (area/patch), the
particle (e.g. an ion), or an interface particle representing a
boundary element between two regions of different dielectric
constant. For interface particles, in addition to the properties
associated with atom_style full, each particle also should be assigned
a unit dipole vector (mu) representing the direction of the induced
dipole moment at each interface particle, an area (area/patch), the
difference and mean of the dielectric constants of two sides of the
interface along the direction of the normal vector (ed and em), the
local dielectric constant at the boundary element (epsilon), and a mean
local curvature (curv). Physical particles must be assigned these
values, as well, but only their local dielectric constants will be used;
see documentation for associated :doc:`pair styles <pair_dielectric>`
and :doc:`fixes <fix_polarize>`. The distinction between the physical
and interface particles is only meaningful when :doc:`fix polarize
<fix_polarize>` commands are applied to the interface particles. This
style is part of the DIELECTRIC package.
local dielectric constant at the boundary element (epsilon), and a
mean local curvature (curv). Physical particles must be assigned
these values, as well, but only their local dielectric constants will
be used; see documentation for associated :doc:`pair styles
<pair_dielectric>` and :doc:`fixes <fix_polarize>`. The distinction
between the physical and interface particles is only meaningful when
:doc:`fix polarize <fix_polarize>` commands are applied to the
interface particles. This style is part of the DIELECTRIC package.
For the *dipole* style, a point dipole vector mu is defined for each
point particle. Note that if you wish the particles to be finite-size

9
doc/src/bond_hybrid.rst
View File

@ -1,8 +1,11 @@
.. index:: bond_style hybrid
.. index:: bond_style hybrid/kk
bond_style hybrid command
=========================
Accelerator Variants: *hybrid/kk*
Syntax
""""""
@ -15,7 +18,7 @@ Syntax
Examples
""""""""
.. code-block: LAMMPS
.. code-block:: LAMMPS
bond_style hybrid harmonic fene
bond_coeff 1 harmonic 80.0 1.2
@ -60,6 +63,10 @@ bond types.
----------
.. include:: accel_styles.rst
----------
Restrictions
""""""""""""

122
doc/src/bond_oxdna.rst
View File

@ -27,6 +27,7 @@ Examples
.. code-block:: LAMMPS
# LJ units
bond_style oxdna/fene
bond_coeff * 2.0 0.25 0.7525
@ -36,6 +37,32 @@ Examples
bond_style oxrna2/fene
bond_coeff * 2.0 0.25 0.76107
bond_style oxdna/fene
bond_coeff * oxdna_lj.cgdna
# Real units
bond_style oxdna/fene
bond_coeff * 11.92337812042065 2.1295 6.409795
bond_style oxdna2/fene
bond_coeff * 11.92337812042065 2.1295 6.4430152
bond_style oxrna2/fene
bond_coeff * 11.92337812042065 2.1295 6.482800913
bond_style oxrna2/fene
bond_coeff * oxrna2_real.cgdna
.. note::
The coefficients in the above examples have to be kept fixed and
cannot be changed without reparameterizing the entire model. They are
provided in forms compatible with both *units lj* and *units real*
(see documentation of :doc:`units <units>`). These can also be read
from a potential file with correct unit style by specifying the name
of the file. Several potential files for each unit style are included
in the ``potentials`` directory of the LAMMPS distribution.
Description
"""""""""""
@ -46,15 +73,14 @@ The *oxdna/fene*, *oxdna2/fene*, and *oxrna2/fene* bond styles use the potential
E = - \frac{\epsilon}{2} \ln \left[ 1 - \left(\frac{r-r_0}{\Delta}\right)^2\right]
to define a modified finite extensible nonlinear elastic (FENE)
potential :ref:`(Ouldridge) <Ouldridge0>` to model the connectivity of the
phosphate backbone in the oxDNA/oxRNA force field for coarse-grained
potential :ref:`(Ouldridge) <Ouldridge0>` to model the connectivity of
the phosphate backbone in the oxDNA/oxRNA force field for coarse-grained
modelling of DNA/RNA.
The following coefficients must be defined for the bond type via the
:doc:`bond_coeff <bond_coeff>` command as given in the above example, or
in the data file or restart files read by the
:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
commands:
in the data file or restart files read by the :doc:`read_data
<read_data>` or :doc:`read_restart <read_restart>` commands:
* :math:`\epsilon` (energy)
* :math:`\Delta` (distance)
@ -62,41 +88,40 @@ commands:
.. note::
The oxDNA bond style has to be used together with the
corresponding oxDNA pair styles for excluded volume interaction
*oxdna/excv* , stacking *oxdna/stk* , cross-stacking *oxdna/xstk* and
coaxial stacking interaction *oxdna/coaxstk* as well as
hydrogen-bonding interaction *oxdna/hbond* (see also documentation of
:doc:`pair_style oxdna/excv <pair_oxdna>`). For the oxDNA2
:ref:`(Snodin) <Snodin0>` bond style the analogous pair styles
*oxdna2/excv* , *oxdna2/stk* , *oxdna2/xstk* , *oxdna2/coaxstk* ,
*oxdna2/hbond* and an additional Debye-Hueckel pair style
*oxdna2/dh* have to be defined. The same applies to the oxRNA2
:ref:`(Sulc1) <Sulc01>` styles.
The coefficients in the above example have to be kept fixed and cannot
be changed without reparameterizing the entire model.
The oxDNA bond style has to be used together with the corresponding
oxDNA pair styles for excluded volume interaction *oxdna/excv* ,
stacking *oxdna/stk* , cross-stacking *oxdna/xstk* and coaxial
stacking interaction *oxdna/coaxstk* as well as hydrogen-bonding
interaction *oxdna/hbond* (see also documentation of :doc:`pair_style
oxdna/excv <pair_oxdna>`). For the oxDNA2 :ref:`(Snodin) <Snodin0>`
bond style the analogous pair styles *oxdna2/excv* , *oxdna2/stk* ,
*oxdna2/xstk* , *oxdna2/coaxstk* , *oxdna2/hbond* and an additional
Debye-Hueckel pair style *oxdna2/dh* have to be defined. The same
applies to the oxRNA2 :ref:`(Sulc1) <Sulc01>` styles.
.. note::
This bond style has to be used with the *atom_style hybrid bond ellipsoid oxdna*
(see documentation of :doc:`atom_style <atom_style>`). The *atom_style oxdna*
stores the 3'-to-5' polarity of the nucleotide strand, which is set through
the bond topology in the data file. The first (second) atom in a bond definition
is understood to point towards the 3'-end (5'-end) of the strand.
This bond style has to be used with the *atom_style hybrid bond
ellipsoid oxdna* (see documentation of :doc:`atom_style
<atom_style>`). The *atom_style oxdna* stores the 3'-to-5' polarity
of the nucleotide strand, which is set through the bond topology in
the data file. The first (second) atom in a bond definition is
understood to point towards the 3'-end (5'-end) of the strand.
.. warning::
If data files are produced with :doc:`write_data <write_data>`, then the
:doc:`newton <newton>` command should be set to *newton on* or *newton off on*.
Otherwise the data files will not have the same 3'-to-5' polarity as the
initial data file. This limitation does not apply to binary restart files
produced with :doc:`write_restart <write_restart>`.
If data files are produced with :doc:`write_data <write_data>`, then
the :doc:`newton <newton>` command should be set to *newton on* or
*newton off on*. Otherwise the data files will not have the same
3'-to-5' polarity as the initial data file. This limitation does not
apply to binary restart files produced with :doc:`write_restart
<write_restart>`.
Example input and data files for DNA and RNA duplexes can be found in
examples/PACKAGES/cgdna/examples/oxDNA/ , /oxDNA2/ and /oxRNA2/. A simple python
setup tool which creates single straight or helical DNA strands, DNA/RNA
duplexes or arrays of DNA/RNA duplexes can be found in
examples/PACKAGES/cgdna/util/.
``examples/PACKAGES/cgdna/examples/oxDNA/`, `.../oxDNA2/`` and
``.../oxRNA2/``. A simple python setup tool which creates single
straight or helical DNA strands, DNA/RNA duplexes or arrays of DNA/RNA
duplexes can be found in ``examples/PACKAGES/cgdna/util/``.
Please cite :ref:`(Henrich) <Henrich0>` in any publication that uses
this implementation. An updated documentation that contains general information
@ -113,6 +138,39 @@ and for sequence-specific hydrogen-bonding and stacking interactions
----------
Potential file reading
""""""""""""""""""""""
For each style oxdna, oxdna2 and oxrna2, the first parameter argument
can be a filename, and if it is, no further arguments should be
supplied. Therefore the following command:
.. code-block:: LAMMPS
bond_style oxdna/fene
bond_coeff * oxdna_lj.cgdna
will be interpreted as a request to read the (FENE) potential
:ref:`(Ouldridge) <Ouldridge0>` parameters from the file with the given
name. The file can define multiple potential parameters for both bonded
and pair interactions, but for the above bonded interactions there must
exist in the file a line of the form:
.. code-block:: LAMMPS
* fene epsilon delta r0
There are sample potential files for each unit style in the
``potentials`` directory of the LAMMPS distribution. The potential file
unit system must align with the units defined via the :doc:`units
<units>` command. For conversion between different *LJ* and *real* unit
systems for oxDNA, the python tool *lj2real.py* located in the
``examples/PACKAGES/cgdna/util/`` directory can be used. This tool
assumes similar file structure to the examples found in
``examples/PACKAGES/cgdna/examples/``.
----------
Restrictions
""""""""""""

54
doc/src/boundary.rst
View File

@ -42,8 +42,10 @@ commands.
The style *p* means the box is periodic, so that particles interact
across the boundary, and they can exit one end of the box and re-enter
the other end. A periodic dimension can change in size due to
constant pressure boundary conditions or box deformation (see the :doc:`fix npt <fix_nh>` and :doc:`fix deform <fix_deform>` commands). The *p*
style must be applied to both faces of a dimension.
constant pressure boundary conditions or box deformation (see the
:doc:`fix npt <fix_nh>` and :doc:`fix deform <fix_deform>` commands).
The *p* style must be applied to both faces of a dimension. For 2d
simulations the z dimension must be periodic (which is the default).
The styles *f*, *s*, and *m* mean the box is non-periodic, so that
particles do not interact across the boundary and do not move from one
@ -76,28 +78,44 @@ atoms becomes less than 50.0. This can be useful if you start a
simulation with an empty box or if you wish to leave room on one side
of the box, e.g. for atoms to evaporate from a surface.
For triclinic (non-orthogonal) simulation boxes, if the second dimension
of a tilt factor (e.g. y for xy) is periodic, then the periodicity is
enforced with the tilt factor offset. If the first dimension is
shrink-wrapped, then the shrink wrapping is applied to the tilted box
face, to encompass the atoms. E.g. for a positive xy tilt, the xlo
and xhi faces of the box are planes tilting in the +y direction as y
increases. These tilted planes are shrink-wrapped around the atoms to
determine the x extent of the box.
LAMMPS also allows use of triclinic (non-orthogonal) simulation boxes.
See the :doc:`Howto triclinic <Howto_triclinic>` page for a
geometric description of triclinic boxes, as defined by LAMMPS, and
how to transform these parameters to and from other commonly used
triclinic representations.
description of both general and restricted triclinic boxes and how to
define them. General triclinic boxes (arbitrary edge vectors **A**,
**B**, and **C**) are converted internally to restricted triclinic
boxes with tilt factors (xy,xz,yz) which skew an otherwise orthogonal
box.
The boundary <boundary> command settings explained above for the 6
faces of an orthogonal box also apply in similar manner to the 6 faces
of a restricted triclinic box (and thus to the corresponding 6 faces
of a general triclinic box), with the following context.
if the second dimension of a tilt factor (e.g. y for xy) is periodic,
then the periodicity is enforced with the tilt factor offset. This
means that for y periodicity a particle which exits the lower y
boundary is displaced in the x-direction by xy before it re-enters the
upper y boundary. And vice versa if a particle exits the upper y
boundary. Likewise the ghost atoms surrounding a particle near the
lower y boundary include images of particles near the upper y-boundary
which are displaced in the x-direction by xy. Similar rules apply for
z-periodicity and the xz and/or yz tilt factors.
If the first dimension of a tilt factor is shrink-wrapped, then the
shrink wrapping is applied to the tilted box face, to encompass the
atoms. E.g. for a positive xy tilt, the xlo and xhi faces of the box
are planes tilting in the +y direction as y increases. The position
of these tilted planes are adjusted dynamically to shrink-wrap around
the atoms to determine the xlo and xhi extents of the box.
Restrictions
""""""""""""
This command cannot be used after the simulation box is defined by a
:doc:`read_data <read_data>` or :doc:`create_box <create_box>` command or
:doc:`read_restart <read_restart>` command. See the
:doc:`change_box <change_box>` command for how to change the simulation
box boundaries after it has been defined.
:doc:`read_data <read_data>` or :doc:`create_box <create_box>` command
or :doc:`read_restart <read_restart>` command. See the
:doc:`change_box <change_box>` command for how to change the
simulation box boundaries after it has been defined.
For 2d simulations, the z dimension must be periodic.

4
doc/src/compute.rst
View File

@ -272,6 +272,10 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`pe/mol/tally <compute_tally>` - potential energy between two groups of atoms separated into intermolecular and intramolecular components via the tally callback mechanism
* :doc:`pe/tally <compute_tally>` - potential energy between two groups of atoms via the tally callback mechanism
* :doc:`plasticity/atom <compute_plasticity_atom>` - Peridynamic plasticity for each atom
* :doc:`pod/atom <compute_pod_atom>` - POD descriptors for each atom
* :doc:`podd/atom <compute_pod_atom>` - derivative of POD descriptors for each atom
* :doc:`pod/local <compute_pod_atom>` - local POD descriptors and their derivatives
* :doc:`pod/global <compute_pod_atom>` - global POD descriptors and their derivatives
* :doc:`pressure <compute_pressure>` - total pressure and pressure tensor
* :doc:`pressure/alchemy <compute_pressure_alchemy>` - mixed system total pressure and pressure tensor for :doc:`fix alchemy <fix_alchemy>` runs
* :doc:`pressure/uef <compute_pressure_uef>` - pressure tensor in the reference frame of an applied flow field

19
doc/src/compute_adf.rst
View File

@ -204,8 +204,23 @@ angles per atom satisfying the ADF criteria.
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.
By default, the ADF is not computed for distances longer than the
largest force cutoff, since the neighbor list creation will only contain
pairs up to that distance (plus neighbor list skin). If you use outer
cutoffs larger than that, you must use :doc:`neighbor style 'bin' or
'nsq' <neighbor>`.
If you want an ADF for a larger outer cutoff, you can also use the
:doc:`rerun <rerun>` command to post-process a dump file, use :doc:`pair
style zero <pair_zero>` and set the force cutoff to be larger in the
rerun script. Note that in the rerun context, the force cutoff is
arbitrary and with pair style zero you are not computing any forces, and
since you are not running dynamics you are not changing the model that
generated the trajectory.
The ADF is not computed for neighbors outside the force cutoff,
since processors (in parallel) don't know about atom coordinates for

2
doc/src/compute_ave_sphere_atom.rst
View File

@ -102,6 +102,8 @@ 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 requires :doc:`neighbor styles 'bin' or 'nsq' <neighbor>`.
Related commands
""""""""""""""""

2
doc/src/compute_composition_atom.rst
View File

@ -107,6 +107,8 @@ 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 requires :doc:`neighbor styles 'bin' or 'nsq' <neighbor>`.
Related commands
""""""""""""""""

38
doc/src/compute_count_type.rst
View File

@ -12,7 +12,7 @@ Syntax
* ID, group-ID are documented in :doc:`compute <compute>` command
* count/type = style name of this compute command
* mode = {atom} or {bond} or {angle} or {dihedral} or {improper}
* mode = *atom* or *bond* or *angle* or *dihedral* or *improper*
Examples
""""""""
@ -69,29 +69,42 @@ for each type:
----------
If the {mode} setting is {atom} then the count of atoms for each atom
If the *mode* setting is *atom* then the count of atoms for each atom
type is tallied. Only atoms in the specified group are counted.
If the {mode} setting is {bond} then the count of bonds for each bond
The atom count for each type can be normalized by the total number of
atoms like so:
.. code-block:: LAMMPS
compute typevec all count/type atom # number of atoms of each type
variable normtypes vector c_typevec/atoms # divide by total number of atoms
variable ntypes equal extract_setting(ntypes) # number of atom types
thermo_style custom step v_normtypes[*${ntypes}] # vector variable needs upper limit
Similarly, bond counts can be normalized by the total number of bonds.
The same goes for angles, dihedrals, and impropers (see below).
If the *mode* setting is *bond* then the count of bonds for each bond
type is tallied. Only bonds with both atoms in the specified group
are counted.
For {mode} = {bond}, broken bonds with a bond type of zero are also
For *mode* = *bond*, broken bonds with a bond type of zero are also
counted. The :doc:`bond_style quartic <bond_quartic>` and :doc:`BPM
bond styles <Howto_bpm>` break bonds by doing this. See the :doc:`
Howto broken bonds <Howto_broken_bonds>` doc page for more details.
bond styles <Howto_bpm>` break bonds by doing this. See the
:doc:`Howto broken bonds <Howto_broken_bonds>` doc page for more details.
Note that the group setting is ignored for broken bonds; all broken
bonds in the system are counted.
If the {mode} setting is {angle} then the count of angles for each
If the *mode* setting is *angle* then the count of angles for each
angle type is tallied. Only angles with all 3 atoms in the specified
group are counted.
If the {mode} setting is {dihedral} then the count of dihedrals for
If the *mode* setting is *dihedral* then the count of dihedrals for
each dihedral type is tallied. Only dihedrals with all 4 atoms in the
specified group are counted.
If the {mode} setting is {improper} then the count of impropers for
If the *mode* setting is *improper* then the count of impropers for
each improper type is tallied. Only impropers with all 4 atoms in the
specified group are counted.
@ -101,18 +114,19 @@ Output info
"""""""""""
This compute calculates a global vector of counts. If the mode is
{atom} or {bond} or {angle} or {dihedral} or {improper}, then the
*atom* or *bond* or *angle* or *dihedral* or *improper*, then the
vector length is the number of atom types or bond types or angle types
or dihedral types or improper types, respectively.
If the mode is {bond} this compute also calculates a global scalar
If the mode is *bond* this compute also calculates a global scalar
which is the number of broken bonds with type = 0, as explained above.
These values can be used by any command that uses global scalar or
vector values from a compute as input. See the :doc:`Howto output
<Howto_output>` page for an overview of LAMMPS output options.
The scalar and vector values calculated by this compute are "extensive".
The scalar and vector values calculated by this compute are both
"intensive".
Restrictions
""""""""""""

2
doc/src/compute_efield_wolf_atom.rst
View File

@ -106,6 +106,8 @@ Restrictions
This compute is part of the EXTRA-COMPUTE package. It is only enabled if
LAMMPS was built with that package.
This compute requires :doc:`neighbor styles 'bin' or 'nsq' <neighbor>`.
Related commands
""""""""""""""""

54
doc/src/compute_mliap.rst
View File

@ -20,7 +20,7 @@ Syntax
*model* values = style
style = *linear* or *quadratic* or *mliappy*
*descriptor* values = style filename
style = *sna*
style = *sna* or *ace*
filename = name of file containing descriptor definitions
*gradgradflag* value = 0/1
toggle gradgrad method for force gradient
@ -31,6 +31,7 @@ Examples
.. code-block:: LAMMPS
compute mliap model linear descriptor sna Ta06A.mliap.descriptor
compute mliap model linear descriptor ace H_N_O_ccs.yace gradgradflag 1
Description
"""""""""""
@ -40,18 +41,15 @@ of machine-learning interatomic potentials with respect to model parameters.
It is used primarily for calculating the gradient of energy, force, and
stress components with respect to model parameters, which is useful when
training :doc:`mliap pair_style <pair_mliap>` models to match target data.
It provides separate
definitions of the interatomic potential functional form (*model*)
and the geometric quantities that characterize the atomic positions
(*descriptor*). By defining *model* and *descriptor* separately,
It provides separate definitions of the interatomic potential functional
form (*model*) and the geometric quantities that characterize the atomic
positions (*descriptor*). By defining *model* and *descriptor* separately,
it is possible to use many different models with a given descriptor,
or many different descriptors with a given model. Currently, the
compute supports just two models, *linear* and *quadratic*,
and one descriptor, *sna*, the SNAP descriptor used by
:doc:`pair_style snap <pair_snap>`, including the linear, quadratic,
and chem variants. Work is currently underway to extend
the interface to handle neural network energy models,
and it is also straightforward to add new descriptor styles.
or many different descriptors with a given model. Currently, the compute
supports *linear* and *quadratic* SNAP descriptor computes used in
:doc:`pair_style snap <pair_snap>`, *linear* SO3 descriptor computes, and
*linear* ACE descriptor computes used in :doc:`pair_style pace <pair_pace>`,
and it is straightforward to add new descriptor styles.
The compute *mliap* command must be followed by two keywords
*model* and *descriptor* in either order.
@ -60,19 +58,31 @@ The *model* keyword is followed by the model style (*linear*,
*quadratic* or *mliappy*). The *mliappy* model is only available if
LAMMPS is built with the *mliappy* Python module. There are
:ref:`specific installation instructions <mliap>` for that module.
For the *mliap* compute, specifying a *linear* model will compute the
specified descriptors and gradients with respect to linear model parameters
whereas *quadratic* will do the same, but for the quadratic products of
descriptors.
The *descriptor* keyword is followed by a descriptor style, and
additional arguments. The compute currently supports two descriptor
styles *sna* and *so3*, but it is is straightforward to add additional
descriptor styles. The SNAP descriptor style *sna* is the same as that
used by :doc:`pair_style snap <pair_snap>`, including the linear,
quadratic, and chem variants. A single additional argument specifies
the descriptor filename containing the parameters and setting used by
the SNAP descriptor. The descriptor filename usually ends in the
additional arguments. The compute currently supports three descriptor
styles: *sna*, *so3*, and *ace*, but it is is straightforward to add
additional descriptor styles. The SNAP descriptor style *sna* is the
same as that used by :doc:`pair_style snap <pair_snap>`, including the
linear, quadratic, and chem variants. A single additional argument
specifies the descriptor filename containing the parameters and setting used
by the SNAP descriptor. The descriptor filename usually ends in the
*.mliap.descriptor* extension. The format of this file is identical to
the descriptor file in the :doc:`pair_style mliap <pair_mliap>`, and is
described in detail there.
The ACE descriptor style *ace* is the same as :doc:`pair_style pace <pair_pace>`.
A single additional argument specifies the *ace* descriptor filename
that contains parameters and settings for the ACE descriptors. This file
format differs from the SNAP or SO3 descriptor files, and has a *.yace* or
*.ace* extension. However, as with other mliap descriptor styles, this file
is identical to the ace descriptor file in :doc:`pair_style mliap <pair_mliap>`,
where it is described in further detail.
.. note::
The number of LAMMPS atom types (and the value of *nelems* in the model)
@ -172,8 +182,10 @@ This compute is part of the ML-IAP package. It is only enabled if
LAMMPS was built with that package. In addition, building LAMMPS with
the ML-IAP package requires building LAMMPS with the ML-SNAP package.
The *mliappy* model also requires building LAMMPS with the PYTHON
package. See the :doc:`Build package <Build_package>` page for more
info.
package. The *ace* descriptor also requires building LAMMPS with the
ML-PACE package. See the :doc:`Build package <Build_package>` page for
more info. Note that `kk` (KOKKOS) accelerated variants of SNAP and
ACE descriptors are not compatible with `mliap descriptor`.
Related commands
""""""""""""""""

145
doc/src/compute_pod_atom.rst Normal file
View File

@ -0,0 +1,145 @@
.. index:: compute pod/atom
.. index:: compute podd/atom
.. index:: compute pod/local
.. index:: compute pod/global
compute pod/atom command
========================
compute podd/atom command
=========================
compute pod/local command
=========================
compute pod/global command
==========================
Syntax
""""""
.. code-block:: LAMMPS
compute ID group-ID pod/atom param.pod coefficients.pod
compute ID group-ID podd/atom param.pod coefficients.pod
compute ID group-ID pod/local param.pod coefficients.pod
compute ID group-ID pod/global param.pod coefficients.pod
* ID, group-ID are documented in :doc:`compute <compute>` command
* pod/atom = style name of this compute command
* param.pod = the parameter file specifies parameters of the POD descriptors
* coefficients.pod = the coefficient file specifies coefficients of the POD potential
Examples
""""""""
.. code-block:: LAMMPS
compute d all pod/atom Ta_param.pod
compute dd all podd/atom Ta_param.pod
compute ldd all pod/local Ta_param.pod
compute gdd all podd/global Ta_param.pod
compute d all pod/atom Ta_param.pod Ta_coefficients.pod
compute dd all podd/atom Ta_param.pod Ta_coefficients.pod
compute ldd all pod/local Ta_param.pod Ta_coefficients.pod
compute gdd all podd/global Ta_param.pod Ta_coefficients.pod
Description
"""""""""""
.. versionadded:: 27June2024
Define a computation that calculates a set of quantities related to the
POD descriptors of the atoms in a group. These computes are used
primarily for calculating the dependence of energy and force components
on the linear coefficients in the :doc:`pod pair_style <pair_pod>`,
which is useful when training a POD potential to match target data. POD
descriptors of an atom are characterized by the radial and angular
distribution of neighbor atoms. The detailed mathematical definition is
given in the papers by :ref:`(Nguyen and Rohskopf) <Nguyen20222c>`,
:ref:`(Nguyen2023) <Nguyen20232c>`, :ref:`(Nguyen2024) <Nguyen20242c>`,
and :ref:`(Nguyen and Sema) <Nguyen20243c>`.
Compute *pod/atom* calculates the per-atom POD descriptors.
Compute *podd/atom* calculates derivatives of the per-atom POD
descriptors with respect to atom positions.
Compute *pod/local* calculates the per-atom POD descriptors and their
derivatives with respect to atom positions.
Compute *pod/global* calculates the global POD descriptors and their
derivatives with respect to atom positions.
Examples how to use Compute POD commands are found in the directory
``examples/PACKAGES/pod``.
.. warning::
All of these compute styles produce *very* large per-atom output
arrays that scale with the total number of atoms in the system.
This will result in *very* large memory consumption for systems
with a large number of atoms.
----------
Output info
"""""""""""
Compute *pod/atom* produces an 2D array of size :math:`N \times M`,
where :math:`N` is the number of atoms and :math:`M` is the number of
descriptors. Each column corresponds to a particular POD descriptor.
Compute *podd/atom* produces an 2D array of size :math:`N \times (M * 3
N)`. Each column corresponds to a particular derivative of a POD
descriptor.
Compute *pod/local* produces an 2D array of size :math:`(1 + 3N) \times
(M * N)`. The first row contains the per-atom descriptors, and the last
3N rows contain the derivatives of the per-atom descriptors with respect
to atom positions.
Compute *pod/global* produces an 2D array of size :math:`(1 + 3N) \times
(M)`. The first row contains the global descriptors, and the last 3N
rows contain the derivatives of the global descriptors with respect to
atom positions.
Restrictions
""""""""""""
These computes are part of the ML-POD package. They are only enabled
if LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
Related commands
""""""""""""""""
:doc:`fitpod <fitpod_command>`,
:doc:`pair_style pod <pair_pod>`
Default
"""""""
none
----------
.. _Nguyen20222c:
**(Nguyen and Rohskopf)** Nguyen and Rohskopf, Journal of Computational Physics, 480, 112030, (2023).
.. _Nguyen20232c:
**(Nguyen2023)** Nguyen, Physical Review B, 107(14), 144103, (2023).
.. _Nguyen20242c:
**(Nguyen2024)** Nguyen, Journal of Computational Physics, 113102, (2024).
.. _Nguyen20243c:
**(Nguyen and Sema)** Nguyen and Sema, https://arxiv.org/abs/2405.00306, (2024).

59
doc/src/compute_rdf.rst
View File

@ -13,8 +13,8 @@ Syntax
* ID, group-ID are documented in :doc:`compute <compute>` command
* rdf = style name of this compute command
* Nbin = number of RDF bins
* itypeN = central atom type for Nth RDF histogram (see asterisk form below)
* jtypeN = distribution atom type for Nth RDF histogram (see asterisk form below)
* itypeN = central atom type for Nth RDF histogram (integer, type label, or asterisk form)
* jtypeN = distribution atom type for Nth RDF histogram (integer, type label, or asterisk form)
* zero or more keyword/value pairs may be appended
* keyword = *cutoff*
@ -96,14 +96,16 @@ is computed for :math:`g(r)` between all atom types. If one or more pairs are
listed, then a separate histogram is generated for each
*itype*,\ *jtype* pair.
The *itypeN* and *jtypeN* settings can be specified in one of two
ways. An explicit numeric value can be used, as in the fourth example
above. Or a wild-card asterisk can be used to specify a range of atom
types. This takes the form "\*" or "\*n" or "m\*" or "m\*n". If
:math:`N` is the number of atom types, then an asterisk with no numeric values
means all types from 1 to :math:`N`. A leading asterisk means all types from 1
to n (inclusive). A trailing asterisk means all types from m to :math:`N`
(inclusive). A middle asterisk means all types from m to n (inclusive).
The *itypeN* and *jtypeN* settings can be specified in one of three
ways. One or both of the types in the I,J pair can be a
:doc:`type label <Howto_type_labels>`. Or an explicit numeric value can be
used, as in the fourth example above. Or a wild-card asterisk can be used
to specify a range of atom types. This takes the form "\*" or "\*n" or
"m\*" or "m\*n". If :math:`N` is the number of atom types, then an asterisk
with no numeric values means all types from 1 to :math:`N`. A leading
asterisk means all types from 1 to n (inclusive). A trailing asterisk
means all types from m to :math:`N` (inclusive). A middle asterisk means
all types from m to n (inclusive).
If both *itypeN* and *jtypeN* are single values, as in the fourth example
above, this means that a :math:`g(r)` is computed where atoms of type *itypeN*
@ -176,22 +178,29 @@ also numbers :math:`\ge 0.0`.
Restrictions
""""""""""""
The RDF is not computed for distances longer than the force cutoff,
since processors (in parallel) do not know about atom coordinates for
atoms further away than that distance. If you want an RDF for larger
distances, you can use the :doc:`rerun <rerun>` command to post-process
a dump file and set the cutoff for the potential to be longer in the
By default, the RDF is not computed for distances longer than the
largest force cutoff, since the neighbor list creation will only contain
pairs up to that distance (plus neighbor list skin). This distance can
be increased using the *cutoff* keyword but this keyword is only valid
with :doc:`neighbor styles 'bin' and 'nsq' <neighbor>`.
If you want an RDF for larger distances, you can also use the
:doc:`rerun <rerun>` command to post-process a dump file, use :doc:`pair
style zero <pair_zero>` and set the force cutoff to be longer in the
rerun script. Note that in the rerun context, the force cutoff is
arbitrary, since you are not running dynamics and thus are not changing
your model. The definition of :math:`g(r)` used by LAMMPS is only appropriate
for characterizing atoms that are uniformly distributed throughout the
simulation cell. In such cases, the coordination number is still
correct and meaningful. As an example, if a large simulation cell
contains only one atom of type *itypeN* and one of *jtypeN*, then :math:`g(r)`
will register an arbitrarily large spike at whatever distance they
happen to be at, and zero everywhere else.
The function :math:`\text{coord}(r)` will show a step
change from zero to one at the location of the spike in :math:`g(r)`.
arbitrary and with pair style zero you are not computing any forces, and
you are not running dynamics you are not changing the model that
generated the trajectory.
The definition of :math:`g(r)` used by LAMMPS is only appropriate for
characterizing atoms that are uniformly distributed throughout the
simulation cell. In such cases, the coordination number is still correct
and meaningful. As an example, if a large simulation cell contains only
one atom of type *itypeN* and one of *jtypeN*, then :math:`g(r)` will
register an arbitrarily large spike at whatever distance they happen to
be at, and zero everywhere else. The function :math:`\text{coord}(r)`
will show a step change from zero to one at the location of the spike in
:math:`g(r)`.
.. note::

2
doc/src/compute_stress_mop.rst
View File

@ -126,7 +126,7 @@ These styles are part of the EXTRA-COMPUTE package. They are only
enabled if LAMMPS is built with that package. See the :doc:`Build
package <Build_package>` doc page on for more info.
The method is only implemented for 3d orthogonal simulation boxes whose
The method is implemented for orthogonal simulation boxes whose
size does not change in time, and axis-aligned planes.
The method only works with two-body pair interactions, because it

266
doc/src/create_atoms.rst
View File

@ -10,7 +10,7 @@ Syntax
create_atoms type style args keyword values ...
* type = atom type (1-Ntypes) of atoms to create (offset for molecule creation)
* type = atom type (1-Ntypes or type label) of atoms to create (offset for molecule creation)
* style = *box* or *region* or *single* or *mesh* or *random*
.. parsed-literal::
@ -37,7 +37,7 @@ Syntax
seed = random # seed (positive integer)
*basis* values = M itype
M = which basis atom
itype = atom type (1-N) to assign to this basis atom
itype = atom type (1-Ntypes or type label) to assign to this basis atom
*ratio* values = frac seed
frac = fraction of lattice sites (0 to 1) to populate randomly
seed = random # seed (positive integer)
@ -74,6 +74,13 @@ Examples
.. code-block:: LAMMPS
create_atoms 1 box
labelmap atom 1 Pt
create_atoms Pt box
labelmap atom 1 C 2 Si
create_atoms C region regsphere basis Si C
create_atoms 3 region regsphere basis 2 3
create_atoms 3 region regsphere basis 2 3 ratio 0.5 74637
create_atoms 3 single 0 0 5
@ -86,25 +93,46 @@ Description
"""""""""""
This command creates atoms (or molecules) within the simulation box,
either on a lattice, or a single atom (or molecule), or on a surface
defined by a triangulated mesh, or a random collection of atoms (or
molecules). It is an alternative to reading in atom coordinates
either on a lattice, or at random points, or on a surface defined by a
triangulated mesh. Or it creates a single atom (or molecule) at a
specified point. It is an alternative to reading in atom coordinates
explicitly via a :doc:`read_data <read_data>` or :doc:`read_restart
<read_restart>` command. A simulation box must already exist, which is
<read_restart>` command.
To use this command a simulation box must already exist, which is
typically created via the :doc:`create_box <create_box>` command.
Before using this command, a lattice must also be defined using the
:doc:`lattice <lattice>` command, unless you specify the *single* style
with units = box or the *random* style. For the remainder of this doc
page, a created atom or molecule is referred to as a "particle".
Before using this command, a lattice must typically also be defined
using the :doc:`lattice <lattice>` command, unless you specify the
*single* or *mesh* style with units = box or the *random* style. To
create atoms on a lattice for general triclinic boxes, see the
discussion below.
For the remainder of this doc page, a created atom or molecule is
referred to as a "particle".
If created particles are individual atoms, they are assigned the
specified atom *type*, though this can be altered via the *basis*
keyword as discussed below. If molecules are being created, the type
of each atom in the created molecule is specified in the file read by
the :doc:`molecule <molecule>` command, and those values are added to
the specified atom *type* (e.g., if *type* = 2 and the file specifies
atom types 1, 2, and 3, then each created molecule will have atom types
3, 4, and 5).
of each atom in the created molecule is specified in a specified file
read by the :doc:`molecule <molecule>` command, and those values are
added to the specified atom *type* (e.g., if *type* = 2 and the file
specifies atom types 1, 2, and 3, then each created molecule will have
atom types 3, 4, and 5).
.. note::
You cannot use this command to create atoms that are outside the
simulation box; they will just be ignored by LAMMPS. This is true
even if you are using shrink-wrapped box boundaries, as specified
by the :doc:`boundary <boundary>` command. However, you can first
use the :doc:`change_box <change_box>` command to temporarily
expand the box, then add atoms via create_atoms, then finally use
change_box command again if needed to re-shrink-wrap the new atoms.
See the :doc:`change_box <change_box>` doc page for an example of
how to do this, using the create_atoms *single* style to insert a
new atom outside the current simulation box.
----------
For the *box* style, the create_atoms command fills the entire
simulation box with particles on the lattice. If your simulation box
@ -126,10 +154,117 @@ periodic boundaries. If this is desired, you should either use the
*box* style, or tweak the region size to get precisely the particles
you want.
----------
If the simulation box is formulated as a general triclinic box defined
by arbitrary edge vectors **A**, **B**, **C**, then the *box* and
*region* styles will create atoms on a lattice commensurate with those
edge vectors. See the :doc:`Howto_triclinic <Howto_triclinic>` doc
page for a detailed explanation of orthogonal, restricted triclinic,
and general triclinic simulation boxes. As with the :doc:`create_box
<create_box>` command, the :doc:`lattice <lattice>` command used by
this command must be of style *custom* and use its *triclinic/general*
option. The *a1, *a2*, *a3* settings of the :doc:`lattice <lattice>`
command define the edge vectors of a unit cell of the general
triclinic lattice. The :doc:`create_box <create_box>` command creates
a simulation box which replicates that unit cell along each of the
**A**, **B**, **C** edge vectors.
.. note::
LAMMPS allows specification of general triclinic simulation boxes
as a convenience for users who may be converting data from
solid-state crystallographic representations or from DFT codes for
input to LAMMPS. However, as explained on the
:doc:`Howto_triclinic <Howto_triclinic>` doc page, internally,
LAMMPS only uses restricted triclinic simulation boxes. This means
the box created by the :doc:`create_box <create_box>` command as
well as the atoms created by this command with their per-atom
information (e.g. coordinates, velocities) are converted (rotated)
from general to restricted triclinic form when the two commands are
invoked. The <Howto_triclinic>` doc page also discusses other
LAMMPS commands which can input/output general triclinic
representations of the simulation box and per-atom data.
The *box* style will fill the entire general triclinic box with
particles on the lattice, as explained above.
.. note::
The *region* style also operates as explained above, but the check
for particles inside the region is performed *after* the particle
coordinates have been converted to the restricted triclinic box.
This means the region must also be defined with respect to the
restricted triclinic box, not the general triclinic box.
If the simulation box is general triclinic, the *single*, *random*,
and *mesh* styles described next operate on the box *after* it has
been converted to restricted triclinic. So all the settings for those
styles should be made in that context.
----------
For the *single* style, a single particle is added to the system at
the specified coordinates. This can be useful for debugging purposes
or to create a tiny system with a handful of particles at specified
positions.
positions. For a 2d simulation the specified z coordinate must be
0.0.
.. versionchanged:: 2Jun2022
The *porosity* style has been renamed to *random* with added functionality.
For the *random* style, *N* particles are added to the system at
randomly generated coordinates, which can be useful for generating an
amorphous system. For 2d simulations, the z coordinates of all added
atoms will be 0.0.
The particles are created one by one using the specified random number
*seed*, resulting in the same set of particle coordinates, independent
of how many processors are being used in the simulation. Unless the
*overlap* keyword is specified, particles created by the *random*
style will typically be highly overlapped. Various additional
criteria can be used to accept or reject a random particle insertion;
see the keyword discussion below. Multiple attempts per particle are
made (see the *maxtry* keyword) until the insertion is either
successful or fails. If this command fails to add all requested *N*
particles, a warning will be output.
If the *region-ID* argument is specified as NULL, then the randomly
created particles will be anywhere in the simulation box. If a
*region-ID* is specified, a geometric volume is filled that is both
inside the simulation box and is also consistent with the region
volume. See the :doc:`region <region>` command for details. Note
that a region can be specified so that its "volume" is either inside
or outside its geometric boundary.
Note that the create_atoms command adds particles to those that
already exist. This means it can be used to add particles to a system
previously read in from a data or restart file. Or the create_atoms
command can be used multiple times, to add multiple sets of particles
to the simulation. For example, grain boundaries can be created, by
interleaving the create_atoms command with :doc:`lattice <lattice>`
commands specifying different orientations.
When this command is used, care should be taken to ensure the
resulting system does not contain particles that are highly
overlapped. Such overlaps will cause many interatomic potentials to
compute huge energies and forces, leading to bad dynamics. There are
several strategies to avoid this problem:
* Use the :doc:`delete_atoms overlap <delete_atoms>` command after
create_atoms. For example, this strategy can be used to overlay and
surround a large protein molecule with a volume of water molecules,
then delete water molecules that overlap with the protein atoms.
* For the *random* style, use the optional *overlap* keyword to avoid
overlaps when each new particle is created.
* Before running dynamics on an overlapped system, perform an
:doc:`energy minimization <minimize>`. Or run initial dynamics with
:doc:`pair_style soft <pair_soft>` or with :doc:`fix nve/limit
<fix_nve_limit>` to un-overlap the particles, before running normal
dynamics.
.. figure:: img/marble_race.jpg
:figwidth: 33%
@ -189,73 +324,6 @@ to the area of that triangle.
beneficial to exclude computing interactions between the created
particles using :doc:`neigh_modify exclude <neigh_modify>`.
.. versionchanged:: 2Jun2022
The *porosity* style has been renamed to *random* with added functionality.
For the *random* style, *N* particles are added to the system at
randomly generated coordinates, which can be useful for generating an
amorphous system. The particles are created one by one using the
specified random number *seed*, resulting in the same set of particle
coordinates, independent of how many processors are being used in the
simulation. Unless the *overlap* keyword is specified, particles
created by the *random* style will typically be highly overlapped.
Various additional criteria can be used to accept or reject a random
particle insertion; see the keyword discussion below. Multiple
attempts per particle are made (see the *maxtry* keyword) until the
insertion is either successful or fails. If this command fails to add
all requested *N* particles, a warning will be output.
If the *region-ID* argument is specified as NULL, then the randomly
created particles will be anywhere in the simulation box. If a
*region-ID* is specified, a geometric volume is filled that is both
inside the simulation box and is also consistent with the region
volume. See the :doc:`region <region>` command for details. Note
that a region can be specified so that its "volume" is either inside
or outside its geometric boundary.
Note that the create_atoms command adds particles to those that
already exist. This means it can be used to add particles to a system
previously read in from a data or restart file. Or the create_atoms
command can be used multiple times, to add multiple sets of particles
to the simulation. For example, grain boundaries can be created, by
interleaving the create_atoms command with :doc:`lattice <lattice>`
commands specifying different orientations.
When this command is used, care should be taken to ensure the
resulting system does not contain particles that are highly
overlapped. Such overlaps will cause many interatomic potentials to
compute huge energies and forces, leading to bad dynamics. There are
several strategies to avoid this problem:
* Use the :doc:`delete_atoms overlap <delete_atoms>` command after
create_atoms. For example, this strategy can be used to overlay and
surround a large protein molecule with a volume of water molecules,
then delete water molecules that overlap with the protein atoms.
* For the *random* style, use the optional *overlap* keyword to avoid
overlaps when each new particle is created.
* Before running dynamics on an overlapped system, perform an
:doc:`energy minimization <minimize>`. Or run initial dynamics with
:doc:`pair_style soft <pair_soft>` or with :doc:`fix nve/limit
<fix_nve_limit>` to un-overlap the particles, before running normal
dynamics.
.. note::
You cannot use any of the styles explained above to create atoms
that are outside the simulation box; they will just be ignored by
LAMMPS. This is true even if you are using shrink-wrapped box
boundaries, as specified by the :doc:`boundary <boundary>` command.
However, you can first use the :doc:`change_box <change_box>`
command to temporarily expand the box, then add atoms via
create_atoms, then finally use change_box command again if needed
to re-shrink-wrap the new atoms. See the :doc:`change_box
<change_box>` doc page for an example of how to do this, using the
create_atoms *single* style to insert a new atom outside the
current simulation box.
----------
Individual atoms are inserted by this command, unless the *mol*
@ -407,12 +475,13 @@ to.
The *overlap* keyword only applies to the *random* style. It prevents
newly created particles from being created closer than the specified
*Doverlap* distance from any other particle. When the particles being
created are molecules, the radius of the molecule (from its geometric
center) is added to *Doverlap*. If particles have finite size (see
:doc:`atom_style sphere <atom_style>` for example) *Doverlap* should
be specified large enough to include the particle size in the
non-overlapping criterion.
*Doverlap* distance from any other particle. If particles have finite
size (see :doc:`atom_style sphere <atom_style>` for example) *Doverlap*
should be specified large enough to include the particle size in the
non-overlapping criterion. If molecules are being randomly inserted, then
an insertion is only accepted if each particle in the molecule meets the
overlap criterion with respect to other particles (not including particles
in the molecule itself).
.. note::
@ -469,12 +538,19 @@ on a single CPU core.
-----
The *units* keyword determines the meaning of the distance units used
to specify the coordinates of the one particle created by the *single*
style, or the overlap distance *Doverlap* by the *overlap* keyword. A
*box* value selects standard distance units as defined by the
:doc:`units <units>` command (e.g., :math:`\AA` for
units = *real* or *metal*\ . A *lattice* value means the distance units are in
lattice spacings.
by parameters for various styles. A *box* value selects standard
distance units as defined by the :doc:`units <units>` command (e.g.,
:math:`\AA` for units = *real* or *metal*\ . A *lattice* value means
the distance units are in lattice spacings. These are affected settings:
* for *single* style: coordinates of the particle created
* for *random* style: overlap distance *Doverlap* by the *overlap* keyword
* for *mesh* style: *bisect* threshold value for *meshmode* = *bisect*
* for *mesh* style: *radthresh* value for *meshmode* = *bisect*
* for *mesh* style: *density* value for *meshmode* = *qrand*
Since *density* represents an area (distance ^2), the lattice spacing
factor is also squared.
----------

241
doc/src/create_box.rst
View File

@ -9,9 +9,11 @@ Syntax
.. code-block:: LAMMPS
create_box N region-ID keyword value ...
create_box N NULL alo ahi blo bhi clo chi keyword value ...
* N = # of atom types to use in this simulation
* region-ID = ID of region to use as simulation domain
* region-ID = ID of region to use as simulation domain or NULL for general triclinic box
* alo,ahi,blo,bhi,clo,chi = multipliers on a1,a2,a3 vectors defined by :doc"`lattice <lattice>` command (only when region-ID = NULL)
* zero or more keyword/value pairs may be appended
* keyword = *bond/types* or *angle/types* or *dihedral/types* or *improper/types* or *extra/bond/per/atom* or *extra/angle/per/atom* or *extra/dihedral/per/atom* or *extra/improper/per/atom* or *extra/special/per/atom*
@ -32,121 +34,204 @@ Examples
.. code-block:: LAMMPS
# orthogonal or restricted triclinic box using regionID = mybox
create_box 2 mybox
create_box 2 mybox bond/types 2 extra/bond/per/atom 1
.. code-block:: LAMMPS
# 2d general triclinic box using primitive cell for 2d hex lattice
lattice custom 1.0 a1 1.0 0.0 0.0 a2 0.5 0.86602540378 0.0 &
a3 0.0 0.0 1.0 basis 0.0 0.0 0.0 triclinic/general
create_box 1 NULL 0 5 0 5 -0.5 0.5
.. code-block:: LAMMPS
# 3d general triclinic box using primitive cell for 3d fcc lattice
lattice custom 1.0 a2 0.0 0.5 0.5 a1 0.5 0.0 0.5 a3 0.5 0.5 0.0 basis 0.0 0.0 0.0 triclinic/general
create box 1 NULL -5 5 -10 10 0 20
Description
"""""""""""
This command creates a simulation box based on the specified region.
Thus a :doc:`region <region>` command must first be used to define a
geometric domain. It also partitions the simulation box into a
regular 3d grid of rectangular bricks, one per processor, based on the
number of processors being used 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.
This command creates a simulation box. It also partitions the box into
a regular 3d grid of smaller sub-boxes, one per processor (MPI task).
The geometry of the partitioning is based on the size and shape of the
simulation box, the number of processors being used 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.
The argument N is the number of atom types that will be used in the
Simulation boxes in LAMMPS can be either orthogonal or triclinic in
shape. Orthogonal boxes are a brick in 3d (rectangle in 2d) with 6
faces that are each perpendicular to one of the standard xyz
coordinate axes. Triclinic boxes are a parallelepiped in 3d
(parallelogram in 2d) with opposite pairs of faces parallel to each
other. LAMMPS supports two forms of triclinic boxes, restricted and
general, which differ in how the box is oriented with respect to the
xyz coordinate axes. See the :doc:`Howto triclinic <Howto_triclinic>`
for a detailed description of all 3 kinds of simulation boxes.
The argument *N* is the number of atom types that will be used in the
simulation.
Orthogonal and restricted triclinic boxes are created by specifying a
region ID previously defined by the :doc:`region <region>` command.
General triclinic boxes are discussed below.
If the region is not of style *prism*, then LAMMPS encloses the region
(block, sphere, etc.) with an axis-aligned orthogonal bounding box
which becomes the simulation domain.
which becomes the simulation domain. For a 2d simulation, the zlo and
zhi values of the simulation box must straddle zero.
If the region is of style *prism*, LAMMPS creates a non-orthogonal
simulation domain shaped as a parallelepiped with triclinic symmetry.
As defined by the :doc:`region prism <region>` command, the
parallelepiped has its "origin" at (xlo,ylo,zlo) and is defined by three
edge vectors starting from the origin given by
:math:`\vec a = (x_\text{hi}-x_\text{lo},0,0)`;
:math:`\vec b = (xy,y_\text{hi}-y_\text{lo},0)`; and
:math:`\vec c = (xz,yz,z_\text{hi}-z_\text{lo})`.
The parameters *xy*\ , *xz*\ , and *yz* can be 0.0 or
positive or negative values and are called "tilt factors" because they
are the amount of displacement applied to faces of an originally
orthogonal box to transform it into the parallelepiped.
parallelepiped has an "origin" at (xlo,ylo,zlo) and three edge vectors
starting from the origin given by :math:`\vec a =
(x_\text{hi}-x_\text{lo},0,0)`; :math:`\vec b =
(xy,y_\text{hi}-y_\text{lo},0)`; and :math:`\vec c =
(xz,yz,z_\text{hi}-z_\text{lo})`. In LAMMPS lingo, this is a
restricted triclinic box because the three edge vectors cannot be
defined in arbitrary (general) directions. The parameters *xy*\ ,
*xz*\ , and *yz* can be 0.0 or positive or negative values and are
called "tilt factors" because they are the amount of displacement
applied to faces of an originally orthogonal box to transform it into
the parallelepiped. For a 2d simulation, the zlo and zhi values of
the simulation box must straddle zero.
By default, a *prism* region used with the create_box command must have
tilt factors :math:`(xy,xz,yz)` that do not skew the box more than half
the distance of the parallel box length. For example, if
:math:`x_\text{lo} = 2` and :math:`x_\text{hi} = 12`, then the :math:`x`
box length is 10 and the :math:`xy` tilt factor must be between
:math:`-5` and :math:`5`. Similarly, both :math:`xz` and :math:`yz`
must be between :math:`-(x_\text{hi}-x_\text{lo})/2` and
Typically a *prism* region used with the create_box command should
have tilt factors :math:`(xy,xz,yz)` that do not skew the box more
than half the distance of the parallel box length. For example, if
:math:`x_\text{lo} = 2` and :math:`x_\text{hi} = 12`, then the
:math:`x` box length is 10 and the :math:`xy` tilt factor must be
between :math:`-5` and :math:`5`. Similarly, both :math:`xz` and
:math:`yz` must be between :math:`-(x_\text{hi}-x_\text{lo})/2` and
:math:`+(y_\text{hi}-y_\text{lo})/2`. Note that this is not a
limitation, since if the maximum tilt factor is 5 (as in this example),
then configurations with tilt :math:`= \dots, -15`, :math:`-5`,
:math:`5`, :math:`15`, :math:`25, \dots` are all geometrically
equivalent. Simulations with large tilt factors will run inefficiently,
since they require more ghost atoms and thus more communication. With
very large tilt factors, LAMMPS will eventually produce incorrect
trajectories and stop with errors due to lost atoms or similar.
limitation, since if the maximum tilt factor is 5 (as in this
example), then configurations with tilt :math:`= \dots, -15`,
:math:`-5`, :math:`5`, :math:`15`, :math:`25, \dots` are all
geometrically equivalent.
See the :doc:`Howto triclinic <Howto_triclinic>` page for a
geometric description of triclinic boxes, as defined by LAMMPS, and
how to transform these parameters to and from other commonly used
triclinic representations.
LAMMPS will issue a warning if the tilt factors of the created box do
not meet this criterion. This is because simulations with large tilt
factors may run inefficiently, since they require more ghost atoms and
thus more communication. With very large tilt factors, LAMMPS may
eventually produce incorrect trajectories and stop with errors due to
lost atoms or similar issues.
When a prism region is used, the simulation domain should normally be periodic
in the dimension that the tilt is applied to, which is given by the second
dimension of the tilt factor (e.g., :math:`y` for :math:`xy` tilt). This is so
that pairs of atoms interacting across that boundary will have one of them
shifted by the tilt factor. Periodicity is set by the
:doc:`boundary <boundary>` command. For example, if the :math:`xy` tilt factor
is non-zero, then the :math:`y` dimension should be periodic. Similarly, the
:math:`z` dimension should be periodic if :math:`xz` or :math:`yz` is non-zero.
LAMMPS does not require this periodicity, but you may lose atoms if this is not
the case.
See the :doc:`Howto triclinic <Howto_triclinic>` page for geometric
descriptions of triclinic boxes and tilt factors, as well as how to
transform the restricted triclinic parameters to and from other
commonly used triclinic representations.
When a prism region is used, the simulation domain should normally be
periodic in the dimension that the tilt is applied to, which is given
by the second dimension of the tilt factor (e.g., :math:`y` for
:math:`xy` tilt). This is so that pairs of atoms interacting across
that boundary will have one of them shifted by the tilt factor.
Periodicity is set by the :doc:`boundary <boundary>` command. For
example, if the :math:`xy` tilt factor is non-zero, then the :math:`y`
dimension should be periodic. Similarly, the :math:`z` dimension
should be periodic if :math:`xz` or :math:`yz` is non-zero. LAMMPS
does not require this periodicity, but you may lose atoms if this is
not the case.
Note that if your simulation will tilt the box (e.g., via the
:doc:`fix deform <fix_deform>` command), the simulation box must be set up to
be triclinic, even if the tilt factors are initially 0.0. You can
also change an orthogonal box to a triclinic box or vice versa by
:doc:`fix deform <fix_deform>` command), the simulation box must be
created as triclinic, even if the tilt factors are initially 0.0. You
can also change an orthogonal box to a triclinic box or vice versa by
using the :doc:`change box <change_box>` command with its *ortho* and
*triclinic* options.
.. note::
If the system is non-periodic (in a dimension), then you should
not make the lo/hi box dimensions (as defined in your
:doc:`region <region>` command) radically smaller/larger than the extent
of the atoms you eventually plan to create (e.g., via the
:doc:`create_atoms <create_atoms>` command). For example, if your atoms
extend from 0 to 50, you should not specify the box bounds as :math:`-10000`
and :math:`10000`. This is because as described above, LAMMPS uses the
specified box size to lay out the 3d grid of processors. A huge
(mostly empty) box will be sub-optimal for performance when using
"fixed" boundary conditions (see the :doc:`boundary <boundary>`
command). When using "shrink-wrap" boundary conditions (see the
:doc:`boundary <boundary>` command), a huge (mostly empty) box may cause
a parallel simulation to lose atoms the first time that LAMMPS
shrink-wraps the box around the atoms.
If the system is non-periodic (in a dimension), then you should not
make the lo/hi box dimensions (as defined in your :doc:`region
<region>` command) radically smaller/larger than the extent of the
atoms you eventually plan to create (e.g., via the
:doc:`create_atoms <create_atoms>` command). For example, if your
atoms extend from 0 to 50, you should not specify the box bounds as
:math:`-10000` and :math:`10000`. This is because as described
above, LAMMPS uses the specified box size to lay out the 3d grid of
processors. A huge (mostly empty) box will be sub-optimal for
performance when using "fixed" boundary conditions (see the
:doc:`boundary <boundary>` command). When using "shrink-wrap"
boundary conditions (see the :doc:`boundary <boundary>` command), a
huge (mostly empty) box may cause a parallel simulation to lose
atoms the first time that LAMMPS shrink-wraps the box around the
atoms.
----------
As noted above, general triclinic boxes in LAMMPS allow the box to
have arbitrary edge vectors **A**, **B**, **C**. The only
restrictions are that the three vectors be distinct, non-zero, and not
co-planar. They must also define a right-handed system such that
(**A** x **B**) points in the direction of **C**. Note that a
left-handed system can be converted to a right-handed system by simply
swapping the order of any pair of the **A**, **B**, **C** vectors.
To create a general triclinic boxes, the region is specified as NULL
and the next 6 parameters (alo,ahi,blo,bhi,clo,chi) define the three
edge vectors **A**, **B**, **C** using additional information
previously defined by the :doc:`lattice <lattice>` command.
The lattice must be of style *custom* and use its *triclinic/general*
option. This insures the lattice satisfies the restrictions listed
above. The *a1, *a2*, *a3* settings of the :doc:`lattice <lattice>`
command define the edge vectors of a unit cell of the general
triclinic lattice. This command uses them to define the three edge
vectors and origin of the general triclinic box as:
* **A** = (ahi-alo) * *a1*
* **B** = (bhi-blo) * *a2*
* **C** = (chi-clo) * *a3*
* origin = (alo*a1 + blo*a2 + clo*a3)
For 2d general triclinic boxes, clo = -0.5 and chi = 0.5 is required.
.. note::
LAMMPS allows specification of general triclinic simulation boxes
as a convenience for users who may be converting data from
solid-state crystallographic representations or from DFT codes for
input to LAMMPS. However, as explained on the
:doc:`Howto_triclinic <Howto_triclinic>` doc page, internally,
LAMMPS only uses restricted triclinic simulation boxes. This means
the box defined by this command and per-atom information
(e.g. coordinates, velocities) defined by the :doc:`create_atoms
<create_atoms>` command are converted (rotated) from general to
restricted triclinic form when the two commands are invoked. The
<Howto_triclinic>` doc page also discusses other LAMMPS commands
which can input/output general triclinic representations of the
simulation box and per-atom data.
----------
The optional keywords can be used to create a system that allows for
bond (angle, dihedral, improper) interactions, or for molecules with
special 1--2, 1--3, or 1--4 neighbors to be added later. These optional
keywords serve the same purpose as the analogous keywords that can be
used in a data file which are recognized by the
special 1--2, 1--3, or 1--4 neighbors to be added later. These
optional keywords serve the same purpose as the analogous keywords
that can be used in a data file which are recognized by the
:doc:`read_data <read_data>` command when it sets up a system.
Note that if these keywords are not used, then the create_box command
creates an atomic (non-molecular) simulation that does not allow bonds
between pairs of atoms to be defined, or a
:doc:`bond potential <bond_style>` to be specified, or for molecules with
special neighbors to be added to the system by commands such as
:doc:`create_atoms mol <create_atoms>`, :doc:`fix deposit <fix_deposit>`
or :doc:`fix pour <fix_pour>`.
between pairs of atoms to be defined, or a :doc:`bond potential
<bond_style>` to be specified, or for molecules with special neighbors
to be added to the system by commands such as :doc:`create_atoms mol
<create_atoms>`, :doc:`fix deposit <fix_deposit>` or :doc:`fix pour
<fix_pour>`.
As an example, see the examples/deposit/in.deposit.molecule script,
which deposits molecules onto a substrate. Initially there are no
molecules in the system, but they are added later by the
:doc:`fix deposit <fix_deposit>` command. The create_box command in the
script uses the bond/types and extra/bond/per/atom keywords to allow
this. If the added molecule contained more than one special bond
(allowed by default), an extra/special/per/atom keyword would also
need to be specified.
molecules in the system, but they are added later by the :doc:`fix
deposit <fix_deposit>` command. The create_box command in the script
uses the bond/types and extra/bond/per/atom keywords to allow this.
If the added molecule contained more than one special bond (allowed by
default), an extra/special/per/atom keyword would also need to be
specified.
----------

24
doc/src/delete_bonds.rst
View File

@ -43,6 +43,9 @@ Examples
delete_bonds all bond 0*3 special
delete_bonds all stats
labelmap atom 4 hc
delete_bonds all atom hc special
Description
"""""""""""
@ -59,19 +62,20 @@ For all styles, by default, an interaction is only turned off (or on)
if all the atoms involved are in the specified group. See the *any*
keyword to change the behavior.
Several of the styles (\ *atom*, *bond*, *angle*, *dihedral*,
*improper*\ ) take a *type* as an argument. The specified *type* should
be an integer from 0 to :math:`N`, where :math:`N` is the number of relevant
Several of the styles (\ *atom*, *bond*, *angle*, *dihedral*, *improper*\ )
take a *type* as an argument. The specified *type* can be a
:doc:`type label <Howto_type_labels>`. Otherwise, the type should be an
integer from 0 to :math:`N`, where :math:`N` is the number of relevant
types (atom types, bond types, etc.). A value of 0 is only relevant for
style *bond*\ ; see details below. In all cases, a wildcard asterisk
style *bond*\ ; see details below. For numeric types, a wildcard asterisk
can be used in place of or in conjunction with the *type* argument to
specify a range of types. This takes the form "\*" or "\*n" or "m\*" or
"m\*n". If :math:`N` is the number of types, then an asterisk with no numeric
values means all types from 0 to :math:`N`. A leading asterisk means all
types from 0 to n (inclusive). A trailing asterisk means all types
from m to N (inclusive). A middle asterisk means all types from m to
n (inclusive). Note that it is fine to include a type of 0 for
non-bond styles; it will simply be ignored.
"m\*n". If :math:`N` is the number of types, then an asterisk with no
numeric values means all types from 0 to :math:`N`. A leading asterisk
means all types from 0 to n (inclusive). A trailing asterisk means all
types from m to N (inclusive). A middle asterisk means all types from m to
n (inclusive). Note that it is fine to include a type of 0 for non-bond
styles; it will simply be ignored.
For style *multi* all bond, angle, dihedral, and improper interactions
of any type, involving atoms in the group, are turned off.

71
doc/src/dihedral_cosine_squared_restricted.rst Normal file
View File

@ -0,0 +1,71 @@
.. index:: dihedral_style cosine/squared/restricted
dihedral_style cosine/squared/restricted command
================================================
Syntax
""""""
.. code-block:: LAMMPS
dihedral_style cosine/squared/restricted
Examples
""""""""
.. code-block:: LAMMPS
dihedral_style cosine/squared/restricted
dihedral_coeff 1 10.0 120
Description
"""""""""""
.. versionadded:: 17Apr2024
The *cosine/squared/restricted* dihedral style uses the potential
.. math::
E = K [\cos(\phi) - \cos(\phi_0)]^2 / \sin^2(\phi)
, which is commonly used in the MARTINI force field.
See :ref:`(Bulacu) <restricted-Bul>` for a description of the restricted dihedral for the MARTINI force field.
The following coefficients must be defined for each dihedral type via the
:doc:`dihedral_coeff <dihedral_coeff>` command as in the example above, or in
the data file or restart files read by the :doc:`read_data <read_data>`
or :doc:`read_restart <read_restart>` commands:
* :math:`K` (energy)
* :math:`\phi_0` (degrees)
:math:`\phi_0` is specified in degrees, but LAMMPS converts it to radians internally.
----------
Restrictions
""""""""""""
This dihedral style can only be used if LAMMPS was built with the
EXTRA-MOLECULE package. See the :doc:`Build package <Build_package>` doc page
for more info.
Related commands
""""""""""""""""
:doc:`dihedral_coeff <dihedral_coeff>`
Default
"""""""
none
----------
.. _restricted-Bul:
**(Bulacu)** Bulacu, Goga, Zhao, Rossi, Monticelli, Periole, Tieleman, Marrink, J Chem Theory Comput, 9, 3282-3292
(2013).

3
doc/src/dihedral_style.rst
View File

@ -10,7 +10,7 @@ Syntax
dihedral_style style
* style = *none* or *zero* or *hybrid* or *charmm* or *charmmfsw* or *class2* or *cosine/shift/exp* or *fourier* or *harmonic* or *helix* or *lepton* or *multi/harmonic* or *nharmonic* or *opls* or *spherical* or *table* or *table/cut*
* style = *none* or *zero* or *hybrid* or *charmm* or *charmmfsw* or *class2* or *cosine/shift/exp* or *cosine/squared/restricted* or *fourier* or *harmonic* or *helix* or *lepton* or *multi/harmonic* or *nharmonic* or *opls* or *spherical* or *table* or *table/cut*
Examples
""""""""
@ -105,6 +105,7 @@ exist.
* :doc:`charmmfsw <dihedral_charmm>` - CHARMM dihedral with force switching
* :doc:`class2 <dihedral_class2>` - COMPASS (class 2) dihedral
* :doc:`cosine/shift/exp <dihedral_cosine_shift_exp>` - dihedral with exponential in spring constant
* :doc:`cosine/squared/restricted <dihedral_cosine_squared_restricted>` - squared cosine dihedral with restricted term
* :doc:`fourier <dihedral_fourier>` - dihedral with multiple cosine terms
* :doc:`harmonic <dihedral_harmonic>` - harmonic dihedral
* :doc:`helix <dihedral_helix>` - helix dihedral

136
doc/src/dump.rst
View File

@ -114,6 +114,7 @@ Syntax
proc = ID of processor that owns atom
procp1 = ID+1 of processor that owns atom
type = atom type
typelabel = atom :doc:`type label <Howto_type_labels>`
element = name of atom element, as defined by :doc:`dump_modify <dump_modify>` command
mass = atom mass
x,y,z = unscaled atom coordinates
@ -275,16 +276,20 @@ format <dump_modify>` command and its options.
Format of native LAMMPS format dump files:
The *atom*, *custom*, *grid*, and *local* styles create files in a
simple LAMMPS-specific text format that is self-explanatory when
viewing a dump file. Many post-processing tools either included with
LAMMPS or third-party tools can read this format, as does the
simple LAMMPS-specific text format that is mostly self-explanatory
when viewing a dump file. Many post-processing tools either included
with LAMMPS or third-party tools can read this format, as does the
:doc:`rerun <rerun>` command. See tools described on the :doc:`Tools
<Tools>` doc page for examples, including `Pizza.py
<https://lammps.github.io/pizza>`_.
For all these styles, the dimensions of the simulation box are
included in each snapshot. For an orthogonal simulation box this
information is formatted as:
included in each snapshot. The simulation box in LAMMPS can be
defined in one of 3 ways: orthogonal, restricted triclinic, and
general triclinic. See the :doc:`Howto triclinic <Howto_triclinic>`
doc page for a detailed description of all 3 options.
For an orthogonal simulation box the box information is formatted as:
.. parsed-literal::
@ -301,10 +306,10 @@ the six characters is one of *p* (periodic), *f* (fixed), *s* (shrink wrap),
or *m* (shrink wrapped with a minimum value). See the
:doc:`boundary <boundary>` command for details.
For triclinic simulation boxes (non-orthogonal), an orthogonal
bounding box which encloses the triclinic simulation box is output,
along with the three tilt factors (*xy*, *xz*, *yz*) of the triclinic box,
formatted as follows:
For a restricted triclinic simulation box, an orthogonal bounding box
which encloses the restricted triclinic simulation box is output,
along with the three tilt factors (*xy*, *xz*, *yz*) of the triclinic
box, formatted as follows:
.. parsed-literal::
@ -326,6 +331,10 @@ bounding box extents (xlo_bound, xhi_bound, etc.) are calculated from the
triclinic parameters, and how to transform those parameters to and
from other commonly used triclinic representations.
For a general triclinic simulation box, see the "General triclinic"
section below for a description of the ITEM: BOX BOUNDS format as well
as how per-atom coordinates and per-atom vector quantities are output.
The *atom* and *custom* styles output a "ITEM: NUMBER OF ATOMS" line
with the count of atoms in the snapshot. Likewise they output an
"ITEM: ATOMS" line which includes column descriptors for the per-atom
@ -397,7 +406,6 @@ command.
Dump files in other popular formats:
.. note::
This section only discusses file formats relevant to this doc page.
@ -463,8 +471,9 @@ followed by one line per atom with the atom type and the :math:`x`-,
:math:`y`-, and :math:`z`-coordinate of that atom. You can use the
:doc:`dump_modify element <dump_modify>` option to change the output
from using the (numerical) atom type to an element name (or some other
label). This will help many visualization programs to guess bonds and
colors.
label). This option will help many visualization programs to guess bonds
and colors. You can use the :doc:`dump_modify types labels <dump_modify>`
option to replace numeric atom types with :doc:`type labels <Howto_type_labels>`.
.. versionadded:: 22Dec2022
@ -653,6 +662,87 @@ how to control the compression level in both variants.
----------
General triclinic simulation box output for the *atom* and *custom* styles:
As mentioned above, the simulation box can be defined as a general
triclinic box, which means that 3 arbitrary box edge vectors **A**,
**B**, **C** can be specified. See the :doc:`Howto triclinic
<Howto_triclinic>` doc page for a detailed description of general
triclinic boxes.
This option is provided as a convenience for users who may be
converting data from solid-state crystallographic representations or
from DFT codes for input to LAMMPS. However, as explained on the
:doc:`Howto_triclinic <Howto_triclinic>` doc page, internally, LAMMPS
only uses restricted triclinic simulation boxes. This means the box
and per-atom information (e.g. coordinates, velocities) LAMMPS stores
are converted (rotated) from general to restricted triclinic form when
the system is created.
For dump output, if the :doc:`dump_modify triclinic/general
<dump_modify>` command is used, the box description and per-atom
coordinates and other per-atom vectors will be converted (rotated)
from restricted to general form when each dump file snapshots is
output. This option can only be used if the simulation box was
initially created as general triclinic. If the option is not used,
and the simulation box is general triclinic, then the dump file
snapshots will reflect the internal restricted triclinic geometry.
The dump_modify triclinic/general option affects 3 aspects of the dump
file output.
First, the format for the BOX BOUNDS is as follows
.. parsed-literal::
ITEM: BOX BOUNDS abc origin
ax ay az originx
bx by bz originy
cx cy cz originz
where the **A** edge vector of the box is (ax,ay,az) and similarly
for **B** and **C**. The origin of all 3 edge vectors is (originx,
originy, originz).
Second, the coordinates of each atom are converted (rotated) so that
the atom is inside (or near) the general triclinic box defined by the
**A**, **B**, **C** edge vectors. For style *atom*, this only alters
output for unscaled atom coords, via the :doc:`dump_modify scaled no
<dump_modify>` setting. For style *custom*, this alters output for
either unscaled or unwrapped output of atom coords, via the *x,y,z* or
*xu,yu,zu* attributes. For output of scaled atom coords by both
styles, there is no difference between restricted and general
triclinic values.
Third, the output for any attribute of the *custom* style which
represents a per-atom vector quantity will be converted (rotated) to
be oriented consistent with the general triclinic box and its
orientation relative to the standard xyz coordinate axes.
This applies to the following *custom* style attributes:
* vx,vy,vz = atom velocities
* fx,fy,fz = forces on atoms
* mux,muy,muz = orientation of dipole moment of atom
* omegax,omegay,omegaz = angular velocity of spherical particle
* angmomx,angmomy,angmomz = angular momentum of aspherical particle
* tqx,tqy,tqz = torque on finite-size particles
For example, if the velocity of an atom in a restricted triclinic box
is along the x-axis, then it will be output for a general triclinic
box as a vector along the **A** edge vector of the box.
.. note::
For style *custom*, the :doc:`dump_modify thresh <dump_modify>`
command may access per-atom attributes either directly or
indirectly through a compute or variable. If the attribute is an
atom coordinate or one of the vectors mentioned above, its value
will *NOT* be a general triclinic (rotated) value. Rather it will
be a restricted triclinic value.
----------
Arguments for different styles:
The sections below describe per-atom, local, and per grid cell
@ -686,21 +776,21 @@ command creates a per-atom array with six columns:
Per-atom attributes used as arguments to the *custom* and *cfg* styles:
The *id*, *mol*, *proc*, *procp1*, *type*, *element*, *mass*, *vx*,
*vy*, *vz*, *fx*, *fy*, *fz*, *q* attributes are self-explanatory.
The *id*, *mol*, *proc*, *procp1*, *type*, *typelabel*, *element*, *mass*,
*vx*, *vy*, *vz*, *fx*, *fy*, *fz*, *q* attributes are self-explanatory.
*Id* is the atom ID. *Mol* is the molecule ID, included in the data
file for molecular systems. *Proc* is the ID of the processor (0 to
*Id* is the atom ID. *Mol* is the molecule ID, included in the data file
for molecular systems. *Proc* is the ID of the processor (0 to
:math:`N_\text{procs}-1`) that currently owns the atom. *Procp1* is the
proc ID+1, which can be convenient in place of a *type* attribute (1 to
:math:`N_\text{types}`) for coloring atoms in a visualization program.
*Type* is the atom type (1 to :math:`N_\text{types}`). *Element* is
typically the chemical name of an element, which you must assign to each
type via the :doc:`dump_modify element <dump_modify>` command. More
generally, it can be any string you wish to associated with an atom
type. *Mass* is the atom mass. The quantities *vx*, *vy*, *vz*, *fx*,
*fy*, *fz*, and *q* are components of atom velocity and force and atomic
charge.
*Type* is the atom type (1 to :math:`N_\text{types}`). *Typelabel* is the
atom :doc:`type label <Howto_type_labels>`. *Element* is typically the
chemical name of an element, which you must assign to each type via the
:doc:`dump_modify element <dump_modify>` command. More generally, it can
be any string you wish to associated with an atom type. *Mass* is the atom
mass. The quantities *vx*, *vy*, *vz*, *fx*, *fy*, *fz*, and *q* are
components of atom velocity and force and atomic charge.
There are several options for outputting atom coordinates. The *x*,
*y*, and *z* attributes write atom coordinates "unscaled", in the

57
doc/src/dump_modify.rst
View File

@ -17,7 +17,7 @@ Syntax
* one or more keyword/value pairs may be appended
* these keywords apply to various dump styles
* keyword = *append* or *at* or *balance* or *buffer* or *colname* or *delay* or *element* or *every* or *every/time* or *fileper* or *first* or *flush* or *format* or *header* or *image* or *label* or *maxfiles* or *nfile* or *pad* or *pbc* or *precision* or *region* or *refresh* or *scale* or *sfactor* or *skip* or *sort* or *tfactor* or *thermo* or *thresh* or *time* or *units* or *unwrap*
* keyword = *append* or *at* or *balance* or *buffer* or *colname* or *delay* or *element* or *every* or *every/time* or *fileper* or *first* or *flush* or *format* or *header* or *image* or *label* or *maxfiles* or *nfile* or *pad* or *pbc* or *precision* or *region* or *refresh* or *scale* or *sfactor* or *skip* or *sort* or *tfactor* or *thermo* or *thresh* or *time* or *triclinic/general* or *types* or *units* or *unwrap*
.. parsed-literal::
@ -74,12 +74,14 @@ Syntax
-N = sort per-atom lines in descending order by the Nth column
*tfactor* arg = time scaling factor (> 0.0)
*thermo* arg = *yes* or *no*
*time* arg = *yes* or *no*
*thresh* args = attribute operator value
attribute = same attributes (x,fy,etotal,sxx,etc) used by dump custom style
operator = "<" or "<=" or ">" or ">=" or "==" or "!=" or "\|\^"
value = numeric value to compare to, or LAST
these 3 args can be replaced by the word "none" to turn off thresholding
*time* arg = *yes* or *no*
*triclinic/general* arg = *yes* or *no*
*types* value = *numeric* or *labels*
*units* arg = *yes* or *no*
*unwrap* arg = *yes* or *no*
@ -802,8 +804,9 @@ region since the last dump.
dump_modify ... thresh v_charge |^ LAST
This will dump atoms whose charge has changed from an absolute value
less than :math:`\frac12` to greater than :math:`\frac12` (or vice versa) since the last dump (e.g., due to reactions and subsequent charge equilibration in a
reactive force field).
less than :math:`\frac12` to greater than :math:`\frac12` (or vice
versa) since the last dump (e.g., due to reactions and subsequent
charge equilibration in a reactive force field).
The choice of operators listed above are the usual comparison
operators. The XOR operation (exclusive or) is also included as "\|\^".
@ -811,6 +814,18 @@ In this context, XOR means that if either the attribute or value is
0.0 and the other is non-zero, then the result is "true" and the
threshold criterion is met. Otherwise it is not met.
.. note::
For style *custom*, the *triclinic/general* keyword can alter dump
output for general triclinic simulation boxes and their atoms. See
the :doc:`dump <dump>` command for details of how this changes the
format of dump file snapshots. The thresh keyword may access
per-atom attributes either directly or indirectly through a compute
or variable. If the attribute is an atom coordinate or a per-atom
vector (such as velocity, force, or dipole moment), its value will
*NOT* be a general triclinic (rotated) value. Rather it will be a
restricted triclinic value.
----------
The *time* keyword only applies to the dump *atom*, *custom*, *local*,
@ -835,6 +850,36 @@ The default setting is *no*\ .
----------
The *types* keyword applies only to the dump xyz style. If this keyword is
used with a value of *numeric*, then numeric atom types are printed in the
xyz file (default). If the value *labels* is specified, then
:doc:`type labels <Howto_type_labels>` are printed for atom types.
----------
The *triclinic/general* keyword only applies to the dump *atom* and
*custom* styles. It can only be used with a value of *yes* if the
simulation box was created as a general triclinic box. See the
:doc:`Howto_triclinic <Howto_triclinic>` doc page for a detailed
explanation of orthogonal, restricted triclinic, and general triclinic
simulation boxes.
If this keyword is used with a value of *yes*, the box information at
the beginning of each snapshot will include information about the 3
arbitrary edge vectors **A**, **B**, **C** that define the general
triclinic box as well as their origin. The format is described on the
:doc:`dump <dump>` doc page.
The coordinates of each atom will likewise be output as values in (or
near) the general triclinic box. Likewise, per-atom vector quantities
such as velocity, omega, dipole moment, etc will have orientations
consistent with the general triclinic box, meaning they will be
rotated relative to the standard xyz coordinate axes. See the
:doc:`dump <dump>` doc page for a full list of which dump attributes
this affects.
----------
The *units* keyword only applies to the dump *atom*, *custom*, and
*local* styles (and their COMPRESS package versions *atom/gz*,
*custom/gz* and *local/gz*\ ). If set to *yes*, each individual dump
@ -922,10 +967,12 @@ The option defaults are
* sort = off for dump styles *atom*, *custom*, *cfg*, and *local*
* sort = id for dump styles *dcd*, *xtc*, and *xyz*
* thresh = none
* time = no
* triclinic/general = no
* types = numeric
* units = no
* unwrap = no
* compression_level = 9 (gz variants)
* compression_level = 0 (zstd variants)
* checksum = yes (zstd variants)

741
doc/src/fitpod_command.rst
View File

@ -1,18 +1,19 @@
.. index:: fitpod
fitpod command
======================
==============
Syntax
""""""
.. code-block:: LAMMPS
fitpod Ta_param.pod Ta_data.pod
fitpod Ta_param.pod Ta_data.pod Ta_coefficients.pod
* fitpod = style name of this command
* Ta_param.pod = an input file that describes proper orthogonal descriptors (PODs)
* Ta_data.pod = an input file that specifies DFT data used to fit a POD potential
* Ta_coefficients.pod (optional) = an input file that specifies trainable coefficients of a POD potential
Examples
""""""""
@ -20,20 +21,26 @@ Examples
.. code-block:: LAMMPS
fitpod Ta_param.pod Ta_data.pod
fitpod Ta_param.pod Ta_data.pod Ta_coefficients.pod
Description
"""""""""""
.. versionadded:: 22Dec2022
Fit a machine-learning interatomic potential (ML-IAP) based on proper
orthogonal descriptors (POD). Two input files are required for this
command. The first input file describes a POD potential parameter
settings, while the second input file specifies the DFT data used for
the fitting procedure.
orthogonal descriptors (POD); please see :ref:`(Nguyen and Rohskopf)
<Nguyen20222a>`, :ref:`(Nguyen2023) <Nguyen20232a>`, :ref:`(Nguyen2024)
<Nguyen20242a>`, and :ref:`(Nguyen and Sema) <Nguyen20243a>` for details.
The fitted POD potential can be used to run MD simulations via
:doc:`pair_style pod <pair_pod>`.
The table below has one-line descriptions of all the keywords that can
be used in the first input file (i.e. ``Ta_param.pod`` in the example
above):
Two input files are required for this command. The first input file
describes a POD potential parameter settings, while the second input
file specifies the DFT data used for the fitting procedure. All keywords
except *species* have default values. If a keyword is not set in the
input file, its default value is used. The table below has one-line
descriptions of all the keywords that can be used in the first input
file (i.e. ``Ta_param.pod``)
.. list-table::
:header-rows: 1
@ -52,7 +59,7 @@ above):
- INT
- three integer constants specify boundary conditions
* - rin
- 1.0
- 0.5
- REAL
- a real number specifies the inner cut-off radius
* - rcut
@ -60,46 +67,75 @@ above):
- REAL
- a real number specifies the outer cut-off radius
* - bessel_polynomial_degree
- 3
- 4
- INT
- the maximum degree of Bessel polynomials
* - inverse_polynomial_degree
- 6
- 8
- INT
- the maximum degree of inverse radial basis functions
* - number_of_environment_clusters
- 1
- INT
- the number of clusters for environment-adaptive potentials
* - number_of_principal_components
- 2
- INT
- the number of principal components for dimensionality reduction
* - onebody
- 1
- BOOL
- turns on/off one-body potential
* - twobody_number_radial_basis_functions
- 6
- 8
- INT
- number of radial basis functions for two-body potential
* - threebody_number_radial_basis_functions
- 5
- 6
- INT
- number of radial basis functions for three-body potential
* - threebody_number_angular_basis_functions
* - threebody_angular_degree
- 5
- INT
- number of angular basis functions for three-body potential
* - fourbody_snap_twojmax
- angular degree for three-body potential
* - fourbody_number_radial_basis_functions
- 4
- INT
- number of radial basis functions for four-body potential
* - fourbody_angular_degree
- 3
- INT
- angular degree for four-body potential
* - fivebody_number_radial_basis_functions
- 0
- INT
- band limit for SNAP bispectrum components (0,2,4,6,8... allowed)
* - fourbody_snap_chemflag
- number of radial basis functions for five-body potential
* - fivebody_angular_degree
- 0
- BOOL
- turns on/off the explicit multi-element variant of the SNAP bispectrum components
* - quadratic_pod_potential
- INT
- angular degree for five-body potential
* - sixbody_number_radial_basis_functions
- 0
- BOOL
- turns on/off quadratic POD potential
- INT
- number of radial basis functions for six-body potential
* - sixbody_angular_degree
- 0
- INT
- angular degree for six-body potential
* - sevenbody_number_radial_basis_functions
- 0
- INT
- number of radial basis functions for seven-body potential
* - sevenbody_angular_degree
- 0
- INT
- angular degree for seven-body potential
Note that both the number of radial basis functions and angular degree
must decrease as the body order increases. The next table describes all
keywords that can be used in the second input file (i.e. ``Ta_data.pod``
in the example above):
All keywords except *species* have default values. If a keyword is not
set in the input file, its default value is used. The next table
describes all keywords that can be used in the second input file
(i.e. ``Ta_data.pod`` in the example above):
.. list-table::
:header-rows: 1
@ -125,6 +161,10 @@ describes all keywords that can be used in the second input file
- ""
- STRING
- specifies the path to test data files in double quotes
* - path_to_environment_configuration_set
- ""
- STRING
- specifies the path to environment configuration files in double quotes
* - fraction_training_data_set
- 1.0
- REAL
@ -133,6 +173,14 @@ describes all keywords that can be used in the second input file
- 0
- BOOL
- turns on/off randomization of the training set
* - fraction_test_data_set
- 1.0
- REAL
- a real number (<= 1.0) specifies the fraction of the test set used to validate POD
* - randomize_test_data_set
- 0
- BOOL
- turns on/off randomization of the test set
* - fitting_weight_energy
- 100.0
- REAL
@ -161,6 +209,10 @@ describes all keywords that can be used in the second input file
- 8
- INT
- number of digits after the decimal points for numbers in the coefficient file
* - group_weights
- global
- STRING
- ``table`` uses group weights defined for each group named by filename
All keywords except *path_to_training_data_set* have default values. If
a keyword is not set in the input file, its default value is used. After
@ -172,14 +224,44 @@ successful training, a number of output files are produced, if enabled:
* ``<basename>_test_analysis.pod`` reports detailed errors for all test configurations
* ``<basename>_coefficients.pod`` contains the coefficients of the POD potential
After training the POD potential, ``Ta_param.pod`` and ``<basename>_coefficients.pod``
are the two files needed to use the POD potential in LAMMPS. See
:doc:`pair_style pod <pair_pod>` for using the POD potential. Examples
about training and using POD potentials are found in the directory
lammps/examples/PACKAGES/pod.
After training the POD potential, ``Ta_param.pod`` and
``<basename>_coefficients.pod`` are the two files needed to use the POD
potential in LAMMPS. See :doc:`pair_style pod <pair_pod>` for using the
POD potential. Examples about training and using POD potentials are
found in the directory lammps/examples/PACKAGES/pod and the Github repo
https://github.com/cesmix-mit/pod-examples.
Parameterized Potential Energy Surface
""""""""""""""""""""""""""""""""""""""
Loss Function Group Weights
^^^^^^^^^^^^^^^^^^^^^^^^^^^
The *group_weights* keyword in the ``data.pod`` file is responsible for
weighting certain groups of configurations in the loss function. For
example:
.. code-block:: LAMMPS
group_weights table
Displaced_A15 100.0 1.0
Displaced_BCC 100.0 1.0
Displaced_FCC 100.0 1.0
Elastic_BCC 100.0 1.0
Elastic_FCC 100.0 1.0
GSF_110 100.0 1.0
GSF_112 100.0 1.0
Liquid 100.0 1.0
Surface 100.0 1.0
Volume_A15 100.0 1.0
Volume_BCC 100.0 1.0
Volume_FCC 100.0 1.0
This will apply an energy weight of ``100.0`` and a force weight of
``1.0`` for all groups in the ``Ta`` example. The groups are named by
their respective filename. If certain groups are left out of this table,
then the globally defined weights from the ``fitting_weight_energy`` and
``fitting_weight_force`` keywords will be used.
POD Potential
"""""""""""""
We consider a multi-element system of *N* atoms with :math:`N_{\rm e}`
unique elements. We denote by :math:`\boldsymbol r_n` and :math:`Z_n`
@ -187,535 +269,82 @@ position vector and type of an atom *n* in the system,
respectively. Note that we have :math:`Z_n \in \{1, \ldots, N_{\rm e}
\}`, :math:`\boldsymbol R = (\boldsymbol r_1, \boldsymbol r_2, \ldots,
\boldsymbol r_N) \in \mathbb{R}^{3N}`, and :math:`\boldsymbol Z = (Z_1,
Z_2, \ldots, Z_N) \in \mathbb{N}^{N}`. The potential energy surface
(PES) of the system can be expressed as a many-body expansion of the
form
Z_2, \ldots, Z_N) \in \mathbb{N}^{N}`. The total energy of the
POD potential is expressed as :math:`E(\boldsymbol R, \boldsymbol Z) =
\sum_{i=1}^N E_i(\boldsymbol R_i, \boldsymbol Z_i)`, where
.. math::
E(\boldsymbol R, \boldsymbol Z, \boldsymbol{\eta}, \boldsymbol{\mu}) \ = \ & \sum_{i} V^{(1)}(\boldsymbol r_i, Z_i, \boldsymbol \mu^{(1)} ) + \frac12 \sum_{i,j} V^{(2)}(\boldsymbol r_i, \boldsymbol r_j, Z_i, Z_j, \boldsymbol \eta, \boldsymbol \mu^{(2)}) \\
& + \frac16 \sum_{i,j,k} V^{(3)}(\boldsymbol r_i, \boldsymbol r_j, \boldsymbol r_k, Z_i, Z_j, Z_k, \boldsymbol \eta, \boldsymbol \mu^{(3)}) + \ldots
where :math:`V^{(1)}` is the one-body potential often used for
representing external field or energy of isolated elements, and the
higher-body potentials :math:`V^{(2)}, V^{(3)}, \ldots` are symmetric,
uniquely defined, and zero if two or more indices take identical values.
The superscript on each potential denotes its body order. Each *q*-body
potential :math:`V^{(q)}` depends on :math:`\boldsymbol \mu^{(q)}` which
are sets of parameters to fit the PES. Note that :math:`\boldsymbol \mu`
is a collection of all potential parameters :math:`\boldsymbol
\mu^{(1)}`, :math:`\boldsymbol \mu^{(2)}`, :math:`\boldsymbol
\mu^{(3)}`, etc, and that :math:`\boldsymbol \eta` is a set of
hyper-parameters such as inner cut-off radius :math:`r_{\rm in}` and
outer cut-off radius :math:`r_{\rm cut}`.
Interatomic potentials rely on parameters to learn relationship between
atomic environments and interactions. Since interatomic potentials are
approximations by nature, their parameters need to be set to some
reference values or fitted against data by necessity. Typically,
potential fitting finds optimal parameters, :math:`\boldsymbol \mu^*`,
to minimize a certain loss function of the predicted quantities and
data. Since the fitted potential depends on the data set used to fit it,
different data sets will yield different optimal parameters and thus
different fitted potentials. When fitting the same functional form on
*Q* different data sets, we would obtain *Q* different optimized
potentials, :math:`E(\boldsymbol R,\boldsymbol Z, \boldsymbol \eta,
\boldsymbol \mu_q^*), 1 \le q \le Q`. Consequently, there exist many
different sets of optimized parameters for empirical interatomic
potentials.
Instead of optimizing the potential parameters, inspired by the reduced
basis method :ref:`(Grepl) <Grepl20072>` for parameterized partial
differential equations, we view the parameterized PES as a parametric
manifold of potential energies
.. math::
\mathcal{M} = \{E(\boldsymbol R, \boldsymbol Z, \boldsymbol \eta, \boldsymbol \mu) \ | \ \boldsymbol \mu \in \Omega^{\boldsymbol \mu} \}
where :math:`\Omega^{\boldsymbol \mu}` is a parameter domain in which
:math:`\boldsymbol \mu` resides. The parametric manifold
:math:`\mathcal{M}` contains potential energy surfaces for all values of
:math:`\boldsymbol \mu \in \Omega^{\boldsymbol \mu}`. Therefore, the
parametric manifold yields a much richer and more transferable atomic
representation than any particular individual PES :math:`E(\boldsymbol
R, \boldsymbol Z, \boldsymbol \eta, \boldsymbol \mu^*)`.
We propose specific forms of the parameterized potentials for one-body,
two-body, and three-body interactions. We apply the Karhunen-Loeve
expansion to snapshots of the parameterized potentials to obtain sets of
orthogonal basis functions. These basis functions are aggregated
according to the chemical elements of atoms, thus leading to
multi-element proper orthogonal descriptors.
Proper Orthogonal Descriptors
"""""""""""""""""""""""""""""
Proper orthogonal descriptors are finger prints characterizing the
radial and angular distribution of a system of atoms. The detailed
mathematical definition is given in the paper by Nguyen and Rohskopf
:ref:`(Nguyen) <Nguyen20222>`.
The descriptors for the one-body interaction are used to capture energy
of isolated elements and defined as follows
.. math::
D_{ip}^{(1)} = \left\{
\begin{array}{ll}
1, & \mbox{if } Z_i = p \\
0, & \mbox{if } Z_i \neq p
\end{array}
\right.
for :math:`1 \le i \le N, 1 \le p \le N_{\rm e}`. The number of one-body
descriptors per atom is equal to the number of elements. The one-body
descriptors are independent of atom positions, but dependent on atom
types. The one-body descriptors are active only when the keyword
*onebody* is set to 1.
We adopt the usual assumption that the direct interaction between two
atoms vanishes smoothly when their distance is greater than the outer
cutoff distance :math:`r_{\rm cut}`. Furthermore, we assume that two
atoms can not get closer than the inner cutoff distance :math:`r_{\rm
in}` due to the Pauli repulsion principle. Let :math:`r \in (r_{\rm in},
r_{\rm cut})`, we introduce the following parameterized radial functions
.. math::
\phi(r, r_{\rm in}, r_{\rm cut}, \alpha, \beta) = \frac{\sin (\alpha \pi x) }{r - r_{\rm in}}, \qquad \varphi(r, \gamma) = \frac{1}{r^\gamma} ,
where the scaled distance function :math:`x` is defined below to enrich the two-body manifold
.. math::
x(r, r_{\rm in}, r_{\rm cut}, \beta) = \frac{e^{-\beta(r - r_{\rm in})/(r_{\rm cut} - r_{\rm in})} - 1}{e^{-\beta} - 1} .
We introduce the following function as a convex combination of the two functions
.. math::
\psi(r, r_{\rm in}, r_{\rm cut}, \alpha, \beta, \gamma, \kappa) = \kappa \phi(r, r_{\rm in}, r_{\rm cut}, \alpha, \beta) + (1- \kappa) \varphi(r, \gamma) .
We see that :math:`\psi` is a function of distance :math:`r`, cut-off
distances :math:`r_{\rm in}` and :math:`r_{\rm cut}`, and parameters
:math:`\alpha, \beta, \gamma, \kappa`. Together these parameters allow
the function :math:`\psi` to characterize a diverse spectrum of two-body
interactions within the cut-off interval :math:`(r_{\rm in}, r_{\rm
cut})`.
Next, we introduce the following parameterized potential
.. math::
W^{(2)}(r_{ij}, \boldsymbol \eta, \boldsymbol \mu^{(2)}) = f_{\rm c}(r_{ij}, \boldsymbol \eta) \psi(r_{ij}, \boldsymbol \eta, \boldsymbol \mu^{(2)})
where :math:`\eta_1 = r_{\rm in}, \eta_2 = r_{\rm cut}, \mu_1^{(2)} =
\alpha, \mu_2^{(2)} = \beta, \mu_3^{(2)} = \gamma`, and
:math:`\mu_4^{(2)} = \kappa`. Here the cut-off function :math:`f_{\rm
c}(r_{ij}, \boldsymbol \eta)` proposed in [refs] is used to ensure the
smooth vanishing of the potential and its derivative for :math:`r_{ij}
\ge r_{\rm cut}`:
.. math::
f_{\rm c}(r_{ij}, r_{\rm in}, r_{\rm cut}) = \exp \left(1 -\frac{1}{\sqrt{\left(1 - \frac{(r-r_{\rm in})^3}{(r_{\rm cut} - r_{\rm in})^3} \right)^2 + 10^{-6}}} \right)
Based on the parameterized potential, we form a set of snapshots as
follows. We assume that we are given :math:`N_{\rm s}` parameter tuples
:math:`\boldsymbol \mu^{(2)}_\ell, 1 \le \ell \le N_{\rm s}`. We
introduce the following set of snapshots on :math:`(r_{\rm in}, r_{\rm
cut})`:
.. math::
\xi_\ell(r_{ij}, \boldsymbol \eta) = W^{(2)}(r_{ij}, \boldsymbol \eta, \boldsymbol \mu^{(2)}_\ell), \quad \ell = 1, \ldots, N_{\rm s} .
To ensure adequate sampling of the PES for different parameters, we
choose :math:`N_{\rm s}` parameter points :math:`\boldsymbol
\mu^{(2)}_\ell = (\alpha_\ell, \beta_\ell, \gamma_\ell, \kappa_\ell), 1
\le \ell \le N_{\rm s}` as follows. The parameters :math:`\alpha \in [1,
N_\alpha]` and :math:`\gamma \in [1, N_\gamma]` are integers, where
:math:`N_\alpha` and :math:`N_\gamma` are the highest degrees for
:math:`\alpha` and :math:`\gamma`, respectively. We next choose
:math:`N_\beta` different values of :math:`\beta` in the interval
:math:`[\beta_{\min}, \beta_{\max}]`, where :math:`\beta_{\min} = 0` and
:math:`\beta_{\max} = 4`. The parameter :math:`\kappa` can be set either
0 or 1. Hence, the total number of parameter points is :math:`N_{\rm s}
= N_\alpha N_\beta + N_\gamma`. Although :math:`N_\alpha, N_\beta,
N_\gamma` can be chosen conservatively large, we find that
:math:`N_\alpha = 6, N_\beta = 3, N_\gamma = 8` are adequate for most
problems. Note that :math:`N_\alpha` and :math:`N_\gamma` correspond to
*bessel_polynomial_degree* and *inverse_polynomial_degree*,
respectively.
We employ the Karhunen-Loeve (KL) expansion to generate an orthogonal
basis set which is known to be optimal for representation of the
snapshot family :math:`\{\xi_\ell\}_{\ell=1}^{N_{\rm s}}`. The two-body
orthogonal basis functions are computed as follows
.. math::
U^{(2)}_m(r_{ij}, \boldsymbol \eta) = \sum_{\ell = 1}^{N_{\rm s}} A_{\ell m}(\boldsymbol \eta) \, \xi_\ell(r_{ij}, \boldsymbol \eta), \qquad m = 1, \ldots, N_{\rm 2b} ,
where the matrix :math:`\boldsymbol A \in \mathbb{R}^{N_{\rm s} \times
N_{\rm s}}` consists of eigenvectors of the eigenvalue problem
.. math::
\boldsymbol C \boldsymbol a = \lambda \boldsymbol a
with the entries of :math:`\boldsymbol C \in \mathbb{R}^{N_{\rm s} \times N_{\rm s}}` being given by
.. math::
C_{ij} = \frac{1}{N_{\rm s}} \int_{r_{\rm in}}^{r_{\rm cut}} \xi_i(x, \boldsymbol \eta) \xi_j(x, \boldsymbol \eta) dx, \quad 1 \le i, j \le N_{\rm s}
Note that the eigenvalues :math:`\lambda_\ell, 1 \le \ell \le N_{\rm
s}`, are ordered such that :math:`\lambda_1 \ge \lambda_2 \ge \ldots \ge
\lambda_{N_{\rm s}}`, and that the matrix :math:`\boldsymbol A` is
pe-computed and stored for any given :math:`\boldsymbol \eta`. Owing to
the rapid convergence of the KL expansion, only a small number of
orthogonal basis functions is needed to obtain accurate
approximation. The value of :math:`N_{\rm 2b}` corresponds to
*twobody_number_radial_basis_functions*.
The two-body proper orthogonal descriptors at each atom *i* are computed
by summing the orthogonal basis functions over the neighbors of atom *i*
and numerating on the atom types as follows
.. math::
D^{(2)}_{im l(p, q) }(\boldsymbol \eta) = \left\{
\begin{array}{ll}
\displaystyle \sum_{\{j | Z_j = q\}} U^{(2)}_m(r_{ij}, \boldsymbol \eta), & \mbox{if } Z_i = p \\
0, & \mbox{if } Z_i \neq p
\end{array}
\right.
for :math:`1 \le i \le N, 1 \le m \le N_{\rm 2b}, 1 \le q, p \le N_{\rm
e}`. Here :math:`l(p,q)` is a symmetric index mapping such that
.. math::
l(p,q) = \left\{
\begin{array}{ll}
q + (p-1) N_{\rm e} - p(p-1)/2, & \mbox{if } q \ge p \\
p + (q-1) N_{\rm e} - q(q-1)/2, & \mbox{if } q < p .
\end{array}
\right.
The number of two-body descriptors per atom is thus :math:`N_{\rm 2b}
N_{\rm e}(N_{\rm e}+1)/2`.
It is important to note that the orthogonal basis functions do not
depend on the atomic numbers :math:`Z_i` and :math:`Z_j`. Therefore, the
cost of evaluating the basis functions and their derivatives with
respect to :math:`r_{ij}` is independent of the number of elements
:math:`N_{\rm e}`. Consequently, even though the two-body proper
orthogonal descriptors depend on :math:`\boldsymbol Z`, their
computational complexity is independent of :math:`N_{\rm e}`.
In order to provide proper orthogonal descriptors for three-body
interactions, we need to introduce a three-body parameterized
potential. In particular, the three-body potential is defined as a
product of radial and angular functions as follows
.. math::
W^{(3)}(r_{ij}, r_{ik}, \theta_{ijk}, \boldsymbol \eta, \boldsymbol \mu^{(3)}) = \psi(r_{ij}, r_{\rm min}, r_{\rm max}, \alpha, \beta, \gamma, \kappa) f_{\rm c}(r_{ij}, r_{\rm min}, r_{\rm max}) \\
\psi(r_{ik}, r_{\rm min}, r_{\rm max}, \alpha, \beta, \gamma, \kappa) f_{\rm c}(r_{ik}, r_{\rm min}, r_{\rm max}) \\
\cos (\sigma \theta_{ijk} + \zeta)
where :math:`\sigma` is the periodic multiplicity, :math:`\zeta` is the
equilibrium angle, :math:`\boldsymbol \mu^{(3)} = (\alpha, \beta,
\gamma, \kappa, \sigma, \zeta)`. The three-body potential provides an
angular fingerprint of the atomic environment through the bond angles
:math:`\theta_{ijk}` formed with each pair of neighbors :math:`j` and
:math:`k`. Compared to the two-body potential, the three-body potential
has two extra parameters :math:`(\sigma, \zeta)` associated with the
angular component.
Let :math:`\boldsymbol \varrho = (\alpha, \beta, \gamma, \kappa)`. We
assume that we are given :math:`L_{\rm r}` parameter tuples
:math:`\boldsymbol \varrho_\ell, 1 \le \ell \le L_{\rm r}`. We
introduce the following set of snapshots on :math:`(r_{\min},
r_{\max})`:
.. math::
\zeta_\ell(r_{ij}, r_{\rm min}, r_{\rm max} ) = \psi(r_{ij}, r_{\rm min}, r_{\rm max}, \boldsymbol \varrho_\ell) f_{\rm c}(r_{ij}, r_{\rm min}, r_{\rm max}), \quad 1 \le \ell \le L_{\rm r} .
We apply the Karhunen-Loeve (KL) expansion to this set of snapshots to
obtain orthogonal basis functions as follows
.. math::
U^{r}_m(r_{ij}, r_{\rm min}, r_{\rm max} ) = \sum_{\ell = 1}^{L_{\rm r}} A_{\ell m} \, \zeta_\ell(r_{ij}, r_{\rm min}, r_{\rm max} ), \qquad m = 1, \ldots, N_{\rm r} ,
where the matrix :math:`\boldsymbol A \in \mathbb{R}^{L_{\rm r} \times L_{\rm r}}` consists
of eigenvectors of the eigenvalue problem. For the parameterized angular function,
we consider angular basis functions
.. math::
U^{a}_n(\theta_{ijk}) = \cos ((n-1) \theta_{ijk}), \qquad n = 1,\ldots, N_{\rm a},
where :math:`N_{\rm a}` is the number of angular basis functions. The orthogonal
basis functions for the parameterized potential are computed as follows
.. math::
U^{(3)}_{mn}(r_{ij}, r_{ik}, \theta_{ijk}, \boldsymbol \eta) = U^{r}_m(r_{ij}, \boldsymbol \eta) U^{r}_m(r_{ik}, \boldsymbol \eta) U^{a}_n(\theta_{ijk}),
for :math:`1 \le m \le N_{\rm r}, 1 \le n \le N_{\rm a}`. The number of three-body
orthogonal basis functions is equal to :math:`N_{\rm 3b} = N_{\rm r} N_{\rm a}` and
independent of the number of elements. The value of :math:`N_{\rm r}` corresponds to
*threebody_number_radial_basis_functions*, while that of :math:`N_{\rm a}` to
*threebody_number_angular_basis_functions*.
The three-body proper orthogonal descriptors at each atom *i*
are obtained by summing over the neighbors *j* and *k* of atom *i* as
.. math::
D^{(3)}_{imn \ell(p, q, s)}(\boldsymbol \eta) = \left\{
\begin{array}{ll}
\displaystyle \sum_{\{j | Z_j = q\}} \sum_{\{k | Z_k = s\}} U^{(3)}_{mn}(r_{ij}, r_{ik}, \theta_{ijk}, \boldsymbol \eta), & \mbox{if } Z_i = p \\
0, & \mbox{if } Z_i \neq p
\end{array}
\right.
for :math:`1 \le i \le N, 1 \le m \le N_{\rm r}, 1 \le n \le N_{\rm a}, 1 \le q, p, s \le N_{\rm e}`,
where
.. math::
\ell(p,q,s) = \left\{
\begin{array}{ll}
s + (q-1) N_{\rm e} - q(q-1)/2 + (p-1)N_{\rm e}(1+N_{\rm e})/2 , & \mbox{if } s \ge q \\
q + (s-1) N_{\rm e} - s(s-1)/2 + (p-1)N_{\rm e}(1+N_{\rm e})/2, & \mbox{if } s < q .
\end{array}
\right.
The number of three-body descriptors per atom is thus :math:`N_{\rm 3b} N_{\rm e}^2(N_{\rm e}+1)/2`.
While the number of three-body PODs is cubic function of the number of elements,
the computational complexity of the three-body PODs is independent of the number of elements.
Four-Body SNAP Descriptors
""""""""""""""""""""""""""
In addition to the proper orthogonal descriptors described above, we also employ
the spectral neighbor analysis potential (SNAP) descriptors. SNAP uses bispectrum components
to characterize the local neighborhood of each atom in a very general way. The mathematical definition
of the bispectrum calculation and its derivatives w.r.t. atom positions is described in
:doc:`compute snap <compute_sna_atom>`. In SNAP, the
total energy is decomposed into a sum over atom energies. The energy of
atom *i* is expressed as a weighted sum over bispectrum components.
.. math::
E_i^{\rm SNAP} = \sum_{k=1}^{N_{\rm 4b}} \sum_{p=1}^{N_{\rm e}} c_{kp}^{(4)} D_{ikp}^{(4)}
where the SNAP descriptors are related to the bispectrum components by
.. math::
D^{(4)}_{ikp} = \left\{
\begin{array}{ll}
\displaystyle B_{ik}, & \mbox{if } Z_i = p \\
0, & \mbox{if } Z_i \neq p
\end{array}
\right.
Here :math:`B_{ik}` is the *k*\ -th bispectrum component of atom *i*. The number of
bispectrum components :math:`N_{\rm 4b}` depends on the value of *fourbody_snap_twojmax* :math:`= 2 J_{\rm max}`
and *fourbody_snap_chemflag*. If *fourbody_snap_chemflag* = 0
then :math:`N_{\rm 4b} = (J_{\rm max}+1)(J_{\rm max}+2)(J_{\rm max}+1.5)/3`.
If *fourbody_snap_chemflag* = 1 then :math:`N_{\rm 4b} = N_{\rm e}^3 (J_{\rm max}+1)(J_{\rm max}+2)(J_{\rm max}+1.5)/3`.
The bispectrum calculation is described in more detail in :doc:`compute sna/atom <compute_sna_atom>`.
Linear Proper Orthogonal Descriptor Potentials
""""""""""""""""""""""""""""""""""""""""""""""
The proper orthogonal descriptors and SNAP descriptors are used to define the atomic energies
in the following expansion
.. math::
E_{i}(\boldsymbol \eta) = \sum_{p=1}^{N_{\rm e}} c^{(1)}_p D^{(1)}_{ip} + \sum_{m=1}^{N_{\rm 2b}} \sum_{l=1}^{N_{\rm e}(N_{\rm e}+1)/2} c^{(2)}_{ml} D^{(2)}_{iml}(\boldsymbol \eta) + \sum_{m=1}^{N_{\rm r}} \sum_{n=1}^{N_{\rm a}} \sum_{\ell=1}^{N_{\rm e}^2(N_{\rm e}+1)/2} c^{(3)}_{mn\ell} D^{(3)}_{imn\ell}(\boldsymbol \eta) + \sum_{k=1}^{N_{\rm 4b}} \sum_{p=1}^{N_{\rm e}} c_{kp}^{(4)} D_{ikp}^{(4)}(\boldsymbol \eta),
where :math:`D^{(1)}_{ip}, D^{(2)}_{iml}, D^{(3)}_{imn\ell}, D^{(4)}_{ikp}` are the one-body, two-body, three-body, four-body descriptors,
respectively, and :math:`c^{(1)}_p, c^{(2)}_{ml}, c^{(3)}_{mn\ell}, c^{(4)}_{kp}` are their respective expansion
coefficients. In a more compact notation that implies summation over descriptor indices
the atomic energies can be written as
.. math::
E_i(\boldsymbol \eta) = \sum_{m=1}^{N_{\rm e}} c^{(1)}_m D^{(1)}_{im} + \sum_{m=1}^{N_{\rm d}^{(2)}} c^{(2)}_k D^{(2)}_{im} + \sum_{m=1}^{N_{\rm d}^{(3)}} c^{(3)}_m D^{(3)}_{im} + \sum_{m=1}^{N_{\rm d}^{(4)}} c^{(4)}_m D^{(4)}_{im}
where :math:`N_{\rm d}^{(2)} = N_{\rm 2b} N_{\rm e} (N_{\rm e}+1)/2`,
:math:`N_{\rm d}^{(3)} = N_{\rm 3b} N_{\rm e}^2 (N_{\rm e}+1)/2`, and
:math:`N_{\rm d}^{(4)} = N_{\rm 4b} N_{\rm e}` are
the number of two-body, three-body, and four-body descriptors, respectively.
The potential energy is then obtained by summing local atomic energies :math:`E_i`
for all atoms :math:`i` in the system
.. math::
E(\boldsymbol \eta) = \sum_{i}^N E_{i}(\boldsymbol \eta)
Because the descriptors are one-body, two-body, and three-body terms,
the resulting POD potential is a three-body PES. We can express the potential
energy as a linear combination of the global descriptors as follows
.. math::
E(\boldsymbol \eta) = \sum_{m=1}^{N_{\rm e}} c^{(1)}_m d^{(1)}_{m} + \sum_{m=1}^{N_{\rm d}^{(2)}} c^{(2)}_m d^{(2)}_{m} + \sum_{m=1}^{N_{\rm d}^{(3)}} c^{(3)}_m d^{(3)}_{m} + \sum_{m=1}^{N_{\rm d}^{(4)}} c^{(4)}_m d^{(4)}_{m}
where the global descriptors are given by
.. math::
d_{m}^{(1)}(\boldsymbol \eta) = \sum_{i=1}^N D_{im}^{(1)}(\boldsymbol \eta), \quad d_{m}^{(2)}(\boldsymbol \eta) = \sum_{i=1}^N D_{im}^{(2)}(\boldsymbol \eta), \quad d_{m}^{(3)}(\boldsymbol \eta) = \sum_{i=1}^N D_{im}^{(3)}(\boldsymbol \eta), \quad d_{m}^{(4)}(\boldsymbol \eta) = \sum_{i=1}^N D_{im}^{(4)}(\boldsymbol \eta)
Hence, we obtain the atomic forces as
.. math::
\boldsymbol F = -\nabla E(\boldsymbol \eta) = - \sum_{m=1}^{N_{\rm d}^{(2)}} c^{(2)}_m \nabla d_m^{(2)} - \sum_{m=1}^{N_{\rm d}^{(3)}} c^{(3)}_m \nabla d_m^{(3)} - \sum_{m=1}^{N_{\rm d}^{(4)}} c^{(4)}_m \nabla d_m^{(4)}
where :math:`\nabla d_m^{(2)}`, :math:`\nabla d_m^{(3)}` and :math:`\nabla d_m^{(4)}` are derivatives of the two-body
three-body, and four-body global descriptors with respect to atom positions, respectively.
Note that since the first-body global descriptors are constant, their derivatives are zero.
Quadratic Proper Orthogonal Descriptor Potentials
"""""""""""""""""""""""""""""""""""""""""""""""""
We recall two-body PODs :math:`D^{(2)}_{ik}, 1 \le k \le N_{\rm d}^{(2)}`,
and three-body PODs :math:`D^{(3)}_{im}, 1 \le m \le N_{\rm d}^{(3)}`,
with :math:`N_{\rm d}^{(2)} = N_{\rm 2b} N_{\rm e} (N_{\rm e}+1)/2` and
:math:`N_{\rm d}^{(3)} = N_{\rm 3b} N_{\rm e}^2 (N_{\rm e}+1)/2` being
the number of descriptors per atom for the two-body PODs and three-body PODs,
respectively. We employ them to define a new set of atomic descriptors as follows
.. math::
D^{(2*3)}_{ikm} = \frac{1}{2N}\left( D^{(2)}_{ik} \sum_{j=1}^N D^{(3)}_{jm} + D^{(3)}_{im} \sum_{j=1}^N D^{(2)}_{jk} \right)
for :math:`1 \le i \le N, 1 \le k \le N_{\rm d}^{(2)}, 1 \le m \le N_{\rm d}^{(3)}`.
The new descriptors are four-body because they involve central atom :math:`i` together
with three neighbors :math:`j, k` and :math:`l`. The total number of new descriptors per atom is equal to
.. math::
N_{\rm d}^{(2*3)} = N_{\rm d}^{(2)} * N_{\rm d}^{(3)} = N_{\rm 2b} N_{\rm 3b} N_{\rm e}^3 (N_{\rm e}+1)^2/4 .
The new global descriptors are calculated as
.. math::
d^{(2*3)}_{km} = \sum_{i=1}^N D^{(2*3)}_{ikm} = \left( \sum_{i=1}^N D^{(2)}_{ik} \right) \left( \sum_{i=1}^N D^{(3)}_{im} \right) = d^{(2)}_{k} d^{(3)}_m,
for :math:`1 \le k \le N_{\rm d}^{(2)}, 1 \le m \le N_{\rm d}^{(3)}`. Hence, the gradient
of the new global descriptors with respect to atom positions is calculated as
.. math::
\nabla d^{(2*3)}_{km} = d^{(3)}_m \nabla d^{(2)}_{k} + d^{(2)}_{k} \nabla d^{(3)}_m, \quad 1 \le k \le N_{\rm d}^{(2)}, 1 \le m \le N_{\rm d}^{(3)} .
The quadratic POD potential is defined as a linear combination of the
original and new global descriptors as follows
.. math::
E^{(2*3)} = \sum_{k=1}^{N_{\rm 2d}^{(2*3)}} \sum_{m=1}^{N_{\rm 3d}^{(2*3)}} c^{(2*3)}_{km} d^{(2*3)}_{km} .
It thus follows that
.. math::
E^{(2*3)} = 0.5 \sum_{k=1}^{N_{\rm 2d}^{(2*3)}} \left( \sum_{m=1}^{N_{\rm 3d}^{(2*3)}} c^{(2*3)}_{km} d_m^{(3)} \right) d_k^{(2)} + 0.5 \sum_{m=1}^{N_{\rm 3d}^{(2*3)}} \left( \sum_{k=1}^{N_{\rm 2d}^{(2*3)}} c^{(2*3)}_{km} d_k^{(2)} \right) d_m^{(3)} ,
which is simplified to
.. math::
E^{(2*3)} = 0.5 \sum_{k=1}^{N_{\rm 2d}^{(2*3)}} b_k^{(2)} d_k^{(2)} + 0.5 \sum_{m=1}^{N_{\rm 3d}^{(2*3)}} b_m^{(3)} d_m^{(3)}
where
.. math::
b_k^{(2)} & = \sum_{m=1}^{N_{\rm 3d}^{(2*3)}} c^{(2*3)}_{km} d_m^{(3)}, \quad k = 1,\ldots, N_{\rm 2d}^{(2*3)}, \\
b_m^{(3)} & = \sum_{k=1}^{N_{\rm 2d}^{(2*3)}} c^{(2*3)}_{km} d_k^{(2)}, \quad m = 1,\ldots, N_{\rm 3d}^{(2*3)} .
The quadratic POD potential results in the following atomic forces
.. math::
\boldsymbol F^{(2*3)} = - \sum_{k=1}^{N_{\rm 2d}^{(2*3)}} \sum_{m=1}^{N_{\rm 3d}^{(2*3)}} c^{(2*3)}_{km} \nabla d^{(2*3)}_{km} .
It can be shown that
.. math::
\boldsymbol F^{(2*3)} = - \sum_{k=1}^{N_{\rm 2d}^{(2*3)}} b^{(2)}_k \nabla d_k^{(2)} - \sum_{m=1}^{N_{\rm 3d}^{(2*3)}} b^{(3)}_m \nabla d_m^{(3)} .
The calculation of the atomic forces for the quadratic POD potential
only requires the extra calculation of :math:`b_k^{(2)}` and :math:`b_m^{(3)}` which can be negligible.
As a result, the quadratic POD potential does not increase the computational complexity.
E_i(\boldsymbol R_i, \boldsymbol Z_i) \ = \ \sum_{m=1}^M c_m \mathcal{D}_{im}(\boldsymbol R_i, \boldsymbol Z_i)
Here :math:`c_m` are trainable coefficients and
:math:`\mathcal{D}_{im}(\boldsymbol R_i, \boldsymbol Z_i)` are per-atom
POD descriptors. Summing the per-atom descriptors over :math:`i` yields
the global descriptors :math:`d_m(\boldsymbol R, \boldsymbol Z) =
\sum_{i=1}^N \mathcal{D}_{im}(\boldsymbol R_i, \boldsymbol Z_i)`. It
thus follows that :math:`E(\boldsymbol R, \boldsymbol Z) = \sum_{m=1}^M
c_m d_m(\boldsymbol R, \boldsymbol Z)`.
The per-atom POD descriptors include one, two, three, four, five, six,
and seven-body descriptors, which can be specified in the first input
file. Furthermore, the per-atom POD descriptors also depend on the
number of environment clusters specified in the first input file.
Please see :ref:`(Nguyen2024) <Nguyen20242a>` and :ref:`(Nguyen and Sema)
<Nguyen20243a>` for the detailed description of the per-atom POD
descriptors.
Training
""""""""
POD potentials are trained using the least-squares regression against
A POD potential is trained using the least-squares regression against
density functional theory (DFT) data. Let :math:`J` be the number of
training configurations, with :math:`N_j` being the number of atoms in
the j-th configuration. Let :math:`\{E^{\star}_j\}_{j=1}^{J}` and
:math:`\{\boldsymbol F^{\star}_j\}_{j=1}^{J}` be the DFT energies and
forces for :math:`J` configurations. Next, we calculate the global
descriptors and their derivatives for all training configurations. Let
:math:`d_{jm}, 1 \le m \le M`, be the global descriptors associated with
the j-th configuration, where :math:`M` is the number of global
descriptors. We then form a matrix :math:`\boldsymbol A \in
\mathbb{R}^{J \times M}` with entries :math:`A_{jm} = d_{jm}/ N_j` for
:math:`j=1,\ldots,J` and :math:`m=1,\ldots,M`. Moreover, we form a
matrix :math:`\boldsymbol B \in \mathbb{R}^{\mathcal{N} \times M}` by
stacking the derivatives of the global descriptors for all training
configurations from top to bottom, where :math:`\mathcal{N} =
3\sum_{j=1}^{J} N_j`.
the j-th configuration. The training configurations are extracted from
the extended XYZ files located in a directory (i.e.,
path_to_training_data_set in the second input file). Let
:math:`\{E^{\star}_j\}_{j=1}^{J}` and :math:`\{\boldsymbol
F^{\star}_j\}_{j=1}^{J}` be the DFT energies and forces for :math:`J`
configurations. Next, we calculate the global descriptors and their
derivatives for all training configurations. Let :math:`d_{jm}, 1 \le m
\le M`, be the global descriptors associated with the j-th
configuration, where :math:`M` is the number of global descriptors. We
then form a matrix :math:`\boldsymbol A \in \mathbb{R}^{J \times M}`
with entries :math:`A_{jm} = d_{jm}/ N_j` for :math:`j=1,\ldots,J` and
:math:`m=1,\ldots,M`. Moreover, we form a matrix :math:`\boldsymbol B
\in \mathbb{R}^{\mathcal{N} \times M}` by stacking the derivatives of
the global descriptors for all training configurations from top to
bottom, where :math:`\mathcal{N} = 3\sum_{j=1}^{J} N_j`.
The coefficient vector :math:`\boldsymbol c` of the POD potential is
found by solving the following least-squares problem
.. math::
{\min}_{\boldsymbol c \in \mathbb{R}^{M}} \ w_E \|\boldsymbol A(\boldsymbol \eta) \boldsymbol c - \bar{\boldsymbol E}^{\star} \|^2 + w_F \|\boldsymbol B(\boldsymbol \eta) \boldsymbol c + \boldsymbol F^{\star} \|^2 + w_R \|\boldsymbol c \|^2,
{\min}_{\boldsymbol c \in \mathbb{R}^{M}} \ w_E \|\boldsymbol A \boldsymbol c - \bar{\boldsymbol E}^{\star} \|^2 + w_F \|\boldsymbol B \boldsymbol c + \boldsymbol F^{\star} \|^2 + w_R \|\boldsymbol c \|^2,
where :math:`w_E` and :math:`w_F` are weights for the energy
(*fitting_weight_energy*) and force (*fitting_weight_force*),
respectively; and :math:`w_R` is the regularization parameter (*fitting_regularization_parameter*). Here :math:`\bar{\boldsymbol E}^{\star} \in
\mathbb{R}^{J}` is a vector of with entries :math:`\bar{E}^{\star}_j =
E^{\star}_j/N_j` and :math:`\boldsymbol F^{\star}` is a vector of
:math:`\mathcal{N}` entries obtained by stacking :math:`\{\boldsymbol
F^{\star}_j\}_{j=1}^{J}` from top to bottom.
respectively; and :math:`w_R` is the regularization parameter
(*fitting_regularization_parameter*). Here :math:`\bar{\boldsymbol
E}^{\star} \in \mathbb{R}^{J}` is a vector of with entries
:math:`\bar{E}^{\star}_j = E^{\star}_j/N_j` and :math:`\boldsymbol
F^{\star}` is a vector of :math:`\mathcal{N}` entries obtained by
stacking :math:`\{\boldsymbol F^{\star}_j\}_{j=1}^{J}` from top to
bottom.
The training procedure is the same for both the linear and quadratic POD
potentials. However, since the quadratic POD potential has a
significantly larger number of the global descriptors, it is more
expensive to train the linear POD potential. This is because the
training of the quadratic POD potential still requires us to calculate
and store the quadratic global descriptors and their
gradient. Furthermore, the quadratic POD potential may require more
training data in order to prevent over-fitting. In order to reduce the
computational cost of fitting the quadratic POD potential and avoid
over-fitting, we can use subsets of two-body and three-body PODs for
constructing the new descriptors.
Validation
""""""""""
POD potential can be validated on a test dataset in a directory
specified by setting path_to_test_data_set in the second input file. It
is possible to validate the POD potential after the training is
complete. This is done by providing the coefficient file as an input to
:doc:`fitpod <fitpod_command>`, for example,
.. code-block:: LAMMPS
fitpod Ta_param.pod Ta_data.pod Ta_coefficients.pod
Restrictions
""""""""""""
@ -727,7 +356,11 @@ LAMMPS was built with that package. See the :doc:`Build package
Related commands
""""""""""""""""
:doc:`pair_style pod <pair_pod>`
:doc:`pair_style pod <pair_pod>`,
:doc:`compute pod/atom <compute_pod_atom>`,
:doc:`compute podd/atom <compute_pod_atom>`,
:doc:`compute pod/local <compute_pod_atom>`,
:doc:`compute pod/global <compute_pod_atom>`
Default
"""""""
@ -736,10 +369,20 @@ The keyword defaults are also given in the description of the input files.
----------
.. _Grepl20072:
.. _Nguyen20222a:
**(Grepl)** Grepl, Maday, Nguyen, and Patera, ESAIM: Mathematical Modelling and Numerical Analysis 41(3), 575-605, (2007).
**(Nguyen and Rohskopf)** Nguyen and Rohskopf, Journal of Computational Physics, 480, 112030, (2023).
.. _Nguyen20232a:
**(Nguyen2023)** Nguyen, Physical Review B, 107(14), 144103, (2023).
.. _Nguyen20242a:
**(Nguyen2024)** Nguyen, Journal of Computational Physics, 113102, (2024).
.. _Nguyen20243a:
**(Nguyen and Sema)** Nguyen and Sema, https://arxiv.org/abs/2405.00306, (2024).
.. _Nguyen20222:
**(Nguyen)** Nguyen and Rohskopf, arXiv preprint arXiv:2209.02362 (2022).

24
doc/src/fix_adapt.rst
View File

@ -21,17 +21,17 @@ Syntax
*pair* args = pstyle pparam I J v_name
pstyle = pair style name (e.g., lj/cut)
pparam = parameter to adapt over time
I,J = type pair(s) to set parameter for
I,J = type pair(s) to set parameter for (integer or type label)
v_name = variable with name that calculates value of pparam
*bond* args = bstyle bparam I v_name
bstyle = bond style name (e.g., harmonic)
bparam = parameter to adapt over time
I = type bond to set parameter for
I = type bond to set parameter for (integer or type label)
v_name = variable with name that calculates value of bparam
*angle* args = astyle aparam I v_name
astyle = angle style name (e.g., harmonic)
aparam = parameter to adapt over time
I = type angle to set parameter for
I = type angle to set parameter for (integer or type label)
v_name = variable with name that calculates value of aparam
*kspace* arg = v_name
v_name = variable with name that calculates scale factor on :math:`k`-space terms
@ -67,6 +67,9 @@ Examples
variable ramp_up equal "ramp(0.01,0.5)"
fix stretch all adapt 1 bond harmonic r0 1 v_ramp_up
labelmap atom 1 c1
fix 1 all adapt 1 pair soft a c1 c1 v_prefactor
Description
"""""""""""
@ -254,10 +257,12 @@ should be specified to indicate which type pairs to apply it to. If a global
parameter is specified, the :math:`I` and :math:`J` settings still need to be
specified, but are ignored.
Similar to the :doc:`pair_coeff command <pair_coeff>`, :math:`I` and :math:`J`
can be specified in one of two ways. Explicit numeric values can be used for
each, as in the first example above. :math:`I \le J` is required. LAMMPS sets
the coefficients for the symmetric :math:`J,I` interaction to the same values.
Similar to the :doc:`pair_coeff command <pair_coeff>`, :math:`I` and
:math:`J` can be specified in one of several ways. Explicit numeric values
can be used for each, as in the first example above. Or, one or both of
the types in the I,J pair can be a :doc:`type label <Howto_type_labels>`.
LAMMPS sets the coefficients for the symmetric :math:`J,I` interaction to
the same values.
A wild-card asterisk can be used in place of or in conjunction with
the :math:`I,J` arguments to set the coefficients for multiple pairs of atom
@ -266,8 +271,9 @@ is the number of atom types, then an asterisk with no numeric values
means all types from 1 to :math:`N`. A leading asterisk means all types from
1 to n (inclusive). A trailing asterisk means all types from m to :math:`N`
(inclusive). A middle asterisk means all types from m to n
(inclusive). Note that only type pairs with :math:`I \le J` are considered; if
asterisks imply type pairs where :math:`J < I`, they are ignored.
(inclusive). For the asterisk syntax, note that only type pairs with
:math:`I \le J` are considered; if asterisks imply type pairs where
:math:`J < I`, they are ignored.
IMPORTANT NOTE: If :doc:`pair_style hybrid or hybrid/overlay
<pair_hybrid>` is being used, then the *pstyle* will be a sub-style

22
doc/src/fix_adapt_fep.rst
View File

@ -21,13 +21,13 @@ Syntax
*pair* args = pstyle pparam I J v_name
pstyle = pair style name (e.g., lj/cut)
pparam = parameter to adapt over time
I,J = type pair(s) to set parameter for
I,J = type pair(s) to set parameter for (integer or type label)
v_name = variable with name that calculates value of pparam
*kspace* arg = v_name
v_name = variable with name that calculates scale factor on K-space terms
*atom* args = aparam v_name
aparam = parameter to adapt over time
I = type(s) to set parameter for
I = type(s) to set parameter for (integer or type label)
v_name = variable with name that calculates value of aparam
* zero or more keyword/value pairs may be appended
@ -56,6 +56,9 @@ Examples
fix 1 all adapt/fep 1 pair lj/cut epsilon * * v_scale1 coul/cut scale 3 3 v_scale2 scale yes reset yes
fix 1 all adapt/fep 10 atom diameter 1 v_size
labelmap atom 1 c1
fix 1 all adapt/fep 1 pair soft a c1 c1 v_prefactor
Example input scripts available: examples/PACKAGES/fep
@ -218,10 +221,12 @@ be specified to indicate which type pairs to apply it to. If a global
parameter is specified, the *I* and *J* settings still need to be
specified, but are ignored.
Similar to the :doc:`pair_coeff command <pair_coeff>`, I and J can be
specified in one of two ways. Explicit numeric values can be used for
each, as in the first example above. :math:`I \le J` is required. LAMMPS sets
the coefficients for the symmetric J,I interaction to the same values.
Similar to the :doc:`pair_coeff command <pair_coeff>`, :math:`I` and
:math:`J` can be specified in one of several ways. Explicit numeric values
can be used for each, as in the first example above. Or, one or both of
the types in the I,J pair can be a :doc:`type label <Howto_type_labels>`.
LAMMPS sets the coefficients for the symmetric :math:`J,I` interaction to
the same values.
A wild-card asterisk can be used in place of or in conjunction with
the :math:`I,J` arguments to set the coefficients for multiple pairs of atom
@ -230,8 +235,9 @@ the number of atom types, then an asterisk with no numeric values means
all types from 1 to :math:`N`. A leading asterisk means all types from 1 to n
(inclusive). A trailing asterisk means all types from m to :math:`N`
(inclusive). A middle asterisk means all types from m to n
(inclusive). Note that only type pairs with :math:`I \le J` are considered; if
asterisks imply type pairs where :math:`J < I`, they are ignored.
(inclusive). For the asterisk syntax, note that only type pairs with
:math:`I \le J` are considered; if asterisks imply type pairs where
:math:`J < I`, they are ignored.
IMPROTANT NOTE: If :doc:`pair_style hybrid or hybrid/overlay <pair_hybrid>` is
being used, then the *pstyle* will be a sub-style name. You must specify

23
doc/src/fix_amoeba_bitorsion.rst
View File

@ -35,7 +35,11 @@ the implementation of AMOEBA and HIPPO in LAMMPS.
Bitorsion interactions add additional potential energy contributions
to pairs of overlapping phi-psi dihedrals of amino-acids, which are
important to properly represent their conformational behavior.
important to properly represent their conformational behavior. Each
bitorsion interaction is thus defined for a 5-tuple of atoms
:math:`IJKLM` with bonds between successive atoms in the list,
i.e. two overlapping dihedral interactions for atoms :math:`IJKL` and
:math:`JKLM`.
The examples/amoeba directory has a sample input script and data file
for ubiquitin, which illustrates use of the fix amoeba/bitorsion
@ -68,14 +72,15 @@ lines:
[...]
N 3 314 315 317 318 330
The first column is an index from 1 to :math:`N` to enumerate the bitorsion
5-atom tuples; it is ignored by LAMMPS. The second column is the
*type* of the interaction; it is an index into the bitorsion force
field file. The remaining 5 columns are the atom IDs of the atoms in
the two 4-atom dihedrals that overlap to create the bitorsion 5-body
interaction. Note that the *bitorsions* and *BiTorsions* keywords for
the header and body sections match those specified in the
:doc:`read_data <read_data>` command following the data file name.
The first column is an index from 1 to :math:`N` to enumerate the
bitorsion 5-atom tuples; it is ignored by LAMMPS. The second column
is the *type* of the interaction; it is an index into the bitorsion
force field file. The remaining 5 columns are the atom IDs of the
atoms (in order) for the 5-tuple :math:`IJKLM`, as described above.
Note that the *bitorsions* and *BiTorsions* keywords for the header
and body sections match those specified in the :doc:`read_data
<read_data>` command following the data file name.
The data file should be generated by using the
tools/tinker/tinker2lmp.py conversion script which creates a LAMMPS

23
doc/src/fix_amoeba_pitorsion.rst
View File

@ -57,7 +57,7 @@ should have two lines like these in its header section:
M pitorsion types
N pitorsions
where :math:`N` is the number of pitorsion 5-body interactions and :math:`M` is
where :math:`N` is the number of pitorsion 6-body interactions and :math:`M` is
the number of pitorsion types. It should also have two sections in the body
of the data file like these with :math:`M` and :math:`N` lines each:
@ -74,21 +74,20 @@ of the data file like these with :math:`M` and :math:`N` lines each:
PiTorsions
1 1 8 10 12 18 20
2 5 18 20 22 25 27
1 1 2 4 3 20 21 24
2 5 21 23 22 37 38 41
[...]
N 3 314 315 317 318 330
N 7 27 29 28 30 35 36
For PiTorsion Coeffs, the first column is an index from 1 to :math:`M` to
enumerate the pitorsion types. The second column is the single
For PiTorsion Coeffs, the first column is an index from 1 to :math:`M`
to enumerate the pitorsion types. The second column is the single
prefactor coefficient needed for each type.
For PiTorsions, the first column is an index from 1 to :math:`N` to enumerate
the pitorsion 5-atom tuples; it is ignored by LAMMPS. The second
column is the "type" of the interaction; it is an index into the
PiTorsion Coeffs. The remaining 5 columns are the atom IDs of the
atoms in the two 4-atom dihedrals that overlap to create the pitorsion
5-body interaction.
For PiTorsions, the first column is an index from 1 to :math:`N` to
enumerate the pitorsion 6-atom tuples; it is ignored by LAMMPS. The
second column is the "type" of the interaction; it is an index into
the PiTorsion Coeffs. The remaining 6 columns are the atom IDs of the
atoms (in order) for the 6-tuple :math:`IJKLMN`, as described above.
Note that the *pitorsion types* and *pitorsions* and *PiTorsion
Coeffs* and *PiTorsions* keywords for the header and body sections of

4
doc/src/fix_atom_swap.rst
View File

@ -21,7 +21,7 @@ Syntax
.. parsed-literal::
*types* values = two or more atom types
*types* values = two or more atom types (1-Ntypes or type label)
*mu* values = chemical potential of swap types (energy units)
*ke* value = *no* or *yes*
*no* = no conservation of kinetic energy after atom swaps
@ -168,7 +168,7 @@ the following global cumulative quantities:
* 1 = swap attempts
* 2 = swap accepts
The vector values calculated by this fix are "extensive".
The vector values calculated by this fix are "intensive".
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during

28
doc/src/fix_ave_chunk.rst
View File

@ -31,7 +31,7 @@ Syntax
v_name = per-atom vector calculated by an atom-style variable with name
* zero or more keyword/arg pairs may be appended
* keyword = *norm* or *ave* or *bias* or *adof* or *cdof* or *file* or *overwrite* or *format* or *title1* or *title2* or *title3*
* keyword = *norm* or *ave* or *bias* or *adof* or *cdof* or *file* or *append* or *overwrite* or *format* or *title1* or *title2* or *title3*
.. parsed-literal::
@ -51,6 +51,8 @@ Syntax
dof_per_chunk = define this many degrees-of-freedom per chunk for temperature calculation
*file* arg = filename
filename = file to write results to
*append* arg = filename
filename = file to append results to
*overwrite* arg = none = overwrite output file with only latest output
*format* arg = string
string = C-style format string
@ -433,15 +435,21 @@ molecule.
----------
The *file* keyword allows a filename to be specified. Every
:math:`N_\text{freq}` timesteps, a section of chunk info will be written to a
text file in the following format. A line with the timestep and number of
chunks is written. Then one line per chunk is written, containing the chunk
ID :math:`(1-N_\text{chunk}),` an optional original ID value, optional
coordinate values for chunks that represent spatial bins, the number of atoms
in the chunk, and one or more calculated values. More explanation of the
optional values is given below. The number of values in each line
corresponds to the number of values specified in the fix ave/chunk
.. versionadded:: 17Apr2024
new keyword *append*
The *file* or *append* keywords allow a filename to be specified. If
*file* is used, then the filename is overwritten if it already exists.
If *append* is used, then the filename is appended to if it already
exists, or created if it does not exist. Every :math:`N_\text{freq}`
timesteps, a section of chunk info will be written to a text file in the
following format. A line with the timestep and number of chunks is
written. Then one line per chunk is written, containing the chunk ID
:math:`(1-N_\text{chunk}),` an optional original ID value, optional
coordinate values for chunks that represent spatial bins, the number of
atoms in the chunk, and one or more calculated values. More explanation
of the optional values is given below. The number of values in each
line corresponds to the number of values specified in the fix ave/chunk
command. The number of atoms and the value(s) are summed or average
quantities, as explained above.

1
doc/src/fix_ave_correlate.rst
View File

@ -65,7 +65,6 @@ Examples
fix 1 all ave/correlate 1 50 10000 &
c_thermo_press[1] c_thermo_press[2] c_thermo_press[3] &
type upper ave running title1 "My correlation data"
fix 1 all ave/correlate 1 50 10000 c_thermo_press[*]
Description

13
doc/src/fix_ave_correlate_long.rst
View File

@ -20,11 +20,11 @@ Syntax
.. parsed-literal::
c_ID = global scalar calculated by a compute with ID
c_ID[I] = Ith component of global vector calculated by a compute with ID
c_ID[I] = Ith component of global vector calculated by a compute with ID, I can include wildcard (see below)
f_ID = global scalar calculated by a fix with ID
f_ID[I] = Ith component of global vector calculated by a fix with ID
f_ID[I] = Ith component of global vector calculated by a fix with ID, I can include wildcard (see below)
v_name = global value calculated by an equal-style variable with name
v_name[I] = Ith component of global vector calculated by a vector-style variable with name
v_name[I] = Ith component of a vector-style variable with name, I can include wildcard (see below)
* zero or more keyword/arg pairs may be appended
* keyword = *type* or *start* or *file* or *overwrite* or *title1* or *title2* or *ncorr* or *nlen* or *ncount*
@ -63,6 +63,7 @@ Examples
fix 1 all ave/correlate/long 1 10000 &
c_thermo_press[1] c_thermo_press[2] c_thermo_press[3] &
type upper title1 "My correlation data" nlen 15 ncount 3
fix 1 all ave/correlate/long 1 10000 c_thermo_press[*]
Description
"""""""""""
@ -80,8 +81,10 @@ specified values may represent calculations performed by computes and
fixes which store their own "group" definitions.
Each listed value can be the result of a compute or fix or the
evaluation of an equal-style variable. See the
:doc:`fix ave/correlate <fix_ave_correlate>` page for details.
evaluation of an equal-style or vector-style variable. For
vector-style variables, the specified indices can include a wildcard
character. See the :doc:`fix ave/correlate <fix_ave_correlate>` page
for details.
The *Nevery* and *Nfreq* arguments specify on what time steps the input
values will be used to calculate correlation data and the frequency

36
doc/src/fix_ave_histo.rst
View File

@ -35,7 +35,7 @@ Syntax
v_name[I] = value calculated by a vector-style variable with name, I can include wildcard (see below)
* zero or more keyword/arg pairs may be appended
* keyword = *mode* or *kind* or *file* or *ave* or *start* or *beyond* or *overwrite* or *title1* or *title2* or *title3*
* keyword = *mode* or *kind* or *file* or *append* or *ave* or *start* or *beyond* or *overwrite* or *title1* or *title2* or *title3*
.. parsed-literal::
@ -45,6 +45,8 @@ Syntax
*kind* arg = *global* or *peratom* or *local*
*file* arg = filename
filename = name of file to output histogram(s) to
*append* arg = filename
filename = name of file to append histogram(s) to
*ave* args = *one* or *running* or *window*
one = output a new average value every Nfreq steps
running = output cumulative average of all previous Nfreq steps
@ -317,19 +319,25 @@ on. The default is step 0. Often input values can be 0.0 at time 0,
so setting *start* to a larger value can avoid including a 0.0 in
a running or windowed histogram.
The *file* keyword allows a filename to be specified. Every *Nfreq*
steps, one histogram is written to the file. This includes a leading
line that contains the timestep, number of bins, the total count of
values contributing to the histogram, the count of values that were
not histogrammed (see the *beyond* keyword), the minimum value
encountered, and the maximum value encountered. The min/max values
include values that were not histogrammed. Following the leading
line, one line per bin is written into the file. Each line contains
the bin #, the coordinate for the center of the bin (between *lo* and
*hi*\ ), the count of values in the bin, and the normalized count. The
normalized count is the bin count divided by the total count (not
including values not histogrammed), so that the normalized values sum
to 1.0 across all bins.
.. versionadded:: 17Apr2024
new keyword *append*
The *file* or *append* keywords allow a filename to be specified. If
*file* is used, then the filename is overwritten if it already exists.
If *append* is used, then the filename is appended to if it already
exists, or created if it does not exist. Every *Nfreq* steps, one
histogram is written to the file. This includes a leading line that
contains the timestep, number of bins, the total count of values
contributing to the histogram, the count of values that were not
histogrammed (see the *beyond* keyword), the minimum value encountered,
and the maximum value encountered. The min/max values include values
that were not histogrammed. Following the leading line, one line per
bin is written into the file. Each line contains the bin #, the
coordinate for the center of the bin (between *lo* and *hi*\ ), the
count of values in the bin, and the normalized count. The normalized
count is the bin count divided by the total count (not including values
not histogrammed), so that the normalized values sum to 1.0 across all
bins.
The *overwrite* keyword will continuously overwrite the output file
with the latest output, so that it only contains one timestep worth of

29
doc/src/fix_ave_time.rst
View File

@ -28,7 +28,7 @@ Syntax
v_name[I] = value calculated by a vector-style variable with name, I can include wildcard (see below)
* zero or more keyword/arg pairs may be appended
* keyword = *mode* or *file* or *ave* or *start* or *off* or *overwrite* or *format* or *title1* or *title2* or *title3*
* keyword = *mode* or *file* or *append* or *ave* or *start* or *off* or *overwrite* or *format* or *title1* or *title2* or *title3*
.. parsed-literal::
@ -45,6 +45,8 @@ Syntax
M = value # from 1 to Nvalues
*file* arg = filename
filename = name of file to output time averages to
*append* arg = filename
filename = name of file to append time averages to
*overwrite* arg = none = overwrite output file with only latest output
*format* arg = string
string = C-style format string
@ -270,16 +272,21 @@ are effectively constant or are simply current values (e.g., they are
being written to a file with other time-averaged values for purposes
of creating well-formatted output).
The *file* keyword allows a filename to be specified. Every *Nfreq*
steps, one quantity or vector of quantities is written to the file for
each input value specified in the fix ave/time command. For *mode* =
scalar, this means a single line is written each time output is
performed. Thus the file ends up to be a series of lines, i.e. one
column of numbers for each input value. For *mode* = vector, an array
of numbers is written each time output is performed. The number of rows
is the length of the input vectors, and the number of columns is the
number of values. Thus the file ends up to be a series of these array
sections.
.. versionadded:: 17Apr2024
new keyword *append*
The *file* or *append* keywords allow a filename to be specified. If
*file* is used, then the filename is overwritten if it already exists.
If *append* is used, then the filename is appended to if it already
exists, or created if it does not exist. Every *Nfreq* steps, one
quantity or vector of quantities is written to the file for each input
value specified in the fix ave/time command. For *mode* = scalar, this
means a single line is written each time output is performed. Thus the
file ends up to be a series of lines, i.e. one column of numbers for
each input value. For *mode* = vector, an array of numbers is written
each time output is performed. The number of rows is the length of the
input vectors, and the number of columns is the number of values. Thus
the file ends up to be a series of these array sections.
.. versionadded:: 4May2022

13
doc/src/fix_balance.rst
View File

@ -14,15 +14,15 @@ Syntax
* balance = style name of this fix command
* Nfreq = perform dynamic load balancing every this many steps
* thresh = imbalance threshold that must be exceeded to perform a re-balance
* style = *shift* or *rcb*
* style = *shift* or *rcb* or *report*
.. parsed-literal::
shift args = dimstr Niter stopthresh
*shift* args = dimstr Niter stopthresh
dimstr = sequence of letters containing *x* or *y* or *z*, each not more than once
Niter = # of times to iterate within each dimension of dimstr sequence
stopthresh = stop balancing when this imbalance threshold is reached
*rcb* args = none
*report* args = none
* zero or more keyword/arg pairs may be appended
* keyword = *weight* or *out*
@ -70,6 +70,13 @@ re-balancing is performed periodically during the simulation. To
perform "static" balancing, before or between runs, see the
:doc:`balance <balance>` command.
.. versionadded:: 17Apr2024
The *report* balance style only computes the load imbalance but
does not attempt any re-balancing. This way the load imbalance
information can be used otherwise, for instance for stopping a
run with :doc:`fix halt <fix_halt>`.
Load-balancing is typically most useful if the particles in the
simulation box have a spatially-varying density distribution or
where the computational cost varies significantly between different

2
doc/src/fix_bond_break.rst
View File

@ -13,7 +13,7 @@ Syntax
* ID, group-ID are documented in :doc:`fix <fix>` command
* bond/break = style name of this fix command
* Nevery = attempt bond breaking every this many steps
* bondtype = type of bonds to break
* bondtype = type of bonds to break (integer or type label)
* Rmax = bond longer than Rmax can break (distance units)
* zero or more keyword/value pairs may be appended
* keyword = *prob*

18
doc/src/fix_bond_create.rst
View File

@ -17,9 +17,9 @@ Syntax
* ID, group-ID are documented in :doc:`fix <fix>` command
* bond/create = style name of this fix command
* Nevery = attempt bond creation every this many steps
* itype,jtype = atoms of itype can bond to atoms of jtype
* itype,jtype = atoms of itype can bond to atoms of jtype (1-Ntypes or type label)
* Rmin = 2 atoms separated by less than Rmin can bond (distance units)
* bondtype = type of created bonds
* bondtype = type of created bonds (integer or type label)
* zero or more keyword/value pairs may be appended to args
* keyword = *iparam* or *jparam* or *prob* or *atype* or *dtype* or *itype* or *aconstrain*
@ -27,19 +27,19 @@ Syntax
*iparam* values = maxbond, newtype
maxbond = max # of bonds of bondtype the itype atom can have
newtype = change the itype atom to this type when maxbonds exist
newtype = change the itype atom to this type when maxbonds exist (1-Ntypes or type label)
*jparam* values = maxbond, newtype
maxbond = max # of bonds of bondtype the jtype atom can have
newtype = change the jtype atom to this type when maxbonds exist
newtype = change the jtype atom to this type when maxbonds exist (1-Ntypes or type label)
*prob* values = fraction seed
fraction = create a bond with this probability if otherwise eligible
seed = random number seed (positive integer)
*atype* value = angletype
angletype = type of created angles
angletype = type of created angles (integer or type label)
*dtype* value = dihedraltype
dihedraltype = type of created dihedrals
dihedraltype = type of created dihedrals (integer or type label)
*itype* value = impropertype
impropertype = type of created impropers
impropertype = type of created impropers (integer or type label)
*aconstrain* value = amin amax
amin = minimal angle at which new bonds can be created
amax = maximal angle at which new bonds can be created
@ -54,6 +54,10 @@ Examples
fix 5 all bond/create 1 3 3 0.8 1 prob 0.5 85784 iparam 2 3 atype 1 dtype 2
fix 5 all bond/create/angle 10 1 2 1.122 1 aconstrain 120 180 prob 1 4928459 iparam 2 1 jparam 2 2
labelmap atom 1 c1 2 n2
labelmap bond 1 c1-n2
fix 5 all bond/create 10 c1 n2 0.8 c1-n2
Description
"""""""""""

11
doc/src/fix_charge_regulation.rst
View File

@ -13,8 +13,8 @@ Syntax
* ID, group-ID are documented in fix command
* charge/regulation = style name of this fix command
* cation_type = atom type of free cations
* anion_type = atom type of free anions
* cation_type = atom type of free cations (integer or type label)
* anion_type = atom type of free anions (integer or type label)
* zero or more keyword/value pairs may be appended
@ -27,8 +27,8 @@ Syntax
*pIp* value = activity (effective concentration) of free cations (in the -log10 representation)
*pIm* value = activity (effective concentration) of free anions (in the -log10 representation)
*pKs* value = solvent self-dissociation constant (in the -log10 representation)
*acid_type* = atom type of acid groups
*base_type* = atom type of base groups
*acid_type* = atom type of acid groups (integer or type label)
*base_type* = atom type of base groups (integer or type label)
*lunit_nm* value = unit length used by LAMMPS (# in the units of nanometers)
*temp* value = temperature
*tempfixid* value = fix ID of temperature thermostat
@ -51,6 +51,9 @@ Examples
fix chareg all charge/regulation 1 2 acid_type 3 base_type 4 pKa 5.0 pKb 6.0 pH 7.0 pIp 3.0 pIm 3.0 nevery 200 nmc 200 seed 123 tempfixid fT
fix chareg all charge/regulation 1 2 pIp 3 pIm 3 onlysalt yes 2 -1 seed 123 tag yes temp 1.0
labelmap atom 1 H+ 2 OH-
fix chareg all charge/regulation H+ OH- pIp 3 pIm 3 onlysalt yes 2 -1 seed 123 tag yes temp 1.0
Description
"""""""""""

2
doc/src/fix_deform.rst
View File

@ -64,6 +64,8 @@ Syntax
effectively an engineering shear strain rate
*erate* value = R
R = engineering shear strain rate (1/time units)
*erate/rescale* value = R (ONLY available in :doc:`fix deform/pressure <fix_deform_pressure>` command)
R = engineering shear strain rate (1/time units)
*trate* value = R
R = true shear strain rate (1/time units)
*wiggle* values = A Tp

27
doc/src/fix_deform_pressure.rst
View File

@ -29,10 +29,12 @@ Syntax
NOTE: All other styles are documented by the :doc:`fix deform <fix_deform>` command
*xy*, *xz*, *yz* args = style value
style = *final* or *delta* or *vel* or *erate* or *trate* or *wiggle* or *variable* or *pressure*
style = *final* or *delta* or *vel* or *erate* or *trate* or *wiggle* or *variable* or *pressure* or *erate/rescale*
*pressure* values = target gain
target = target pressure (pressure units)
gain = proportional gain constant (1/(time * pressure) or 1/time units)
*erate/rescale* value = R
R = engineering shear strain rate (1/time units)
NOTE: All other styles are documented by the :doc:`fix deform <fix_deform>` command
*box* = style value
@ -69,7 +71,7 @@ Examples
Description
"""""""""""
.. versionadded:: TBD
.. versionadded:: 17Apr2024
This fix is an extension of the :doc:`fix deform <fix_deform>`
command, which allows all of its options to be used as well as new
@ -91,7 +93,7 @@ corresponding component of the pressure tensor. This option attempts to
maintain a specified target pressure using a linear controller where the
box length :math:`L` evolves according to the equation
.. parsed-literal::
.. math::
\frac{d L(t)}{dt} = L(t) k (P_t - P)
@ -159,6 +161,21 @@ details of a simulation and testing different values is
recommended. One can also apply a maximum limit to the magnitude of
the applied strain using the :ref:`max/rate <deform_max_rate>` option.
The *erate/rescale* style operates similarly to the *erate* style with
a specified strain rate in units of 1/time. The difference is that
the change in the tilt factor will depend on the current length of
the box perpendicular to the shear direction, L, instead of the
original length, L0. The tilt factor T as a function of time will
change as
.. parsed-literal::
T(t) = T(t-1) + L\*erate\* \Delta t
where T(t-1) is the tilt factor on the previous timestep and :math:`\Delta t`
is the timestep size. This option may be useful in scenarios where
L changes in time.
----------
The *box* parameter provides an additional control over the *x*, *y*,
@ -294,6 +311,10 @@ This fix is not invoked during :doc:`energy minimization <minimize>`.
Restrictions
""""""""""""
This fix is part of the EXTRA-FIX package. It is only enabled if LAMMPS
was built with that package. See the :doc:`Build package <Build_package>`
page for more info.
You cannot apply x, y, or z deformations to a dimension that is
shrink-wrapped via the :doc:`boundary <boundary>` command.

5
doc/src/fix_deposit.rst
View File

@ -13,7 +13,7 @@ Syntax
* ID, group-ID are documented in :doc:`fix <fix>` command
* deposit = style name of this fix command
* N = # of atoms or molecules to insert
* type = atom type to assign to inserted atoms (offset for molecule insertion)
* type = atom type (1-Ntypes or type label) to assign to inserted atoms (offset for molecule insertion)
* M = insert a single atom or molecule every M steps
* seed = random # seed (positive integer)
* one or more keyword/value pairs may be appended to args
@ -76,6 +76,9 @@ Examples
fix 4 sputter deposit 1000 2 500 12235 region sphere vz -1.0 -1.0 target 5.0 5.0 0.0 units lattice
fix 5 insert deposit 200 2 100 777 region disk gaussian 5.0 5.0 9.0 1.0 units box
labelmap atom 1 Au
fix 4 sputter deposit 1000 Au 500 12235 region sphere vz -1.0 -1.0 target 5.0 5.0 0.0 units lattice
Description
"""""""""""

33
doc/src/fix_electrode.rst
View File

@ -253,23 +253,26 @@ be enabled if any electrode particle has the same type as any
electrolyte particle (which would be unusual in a typical simulation)
and the fix will issue an error in that case.
.. versionchanged:: qtotal
.. versionadded:: 17Apr2024
The keyword *qtotal* causes *fix electrode/conp* and *fix electrode/thermo*
to add an overall potential to all electrodes so that the total charge on
the electrodes is a specified amount (which may be an equal-style variable).
For example, if a user wanted to simulate a solution of excess cations
such that the total electrolyte charge is +2, setting *qtotal -2* would cause
the total electrode charge to be -2, so that the simulation box remains overall
electroneutral. Since *fix electrode/conq* constrains the total charges of
individual electrodes, and since *symm on* constrains the total charge of all
electrodes to be zero, either option is incompatible with the *qtotal* keyword
(even if *qtotal* is set to zero).
The keyword *qtotal* causes *fix electrode/conp* and *fix
electrode/thermo* to add an overall potential to all electrodes so that
the total charge on the electrodes is a specified amount (which may be
an equal-style variable). For example, if a user wanted to simulate a
solution of excess cations such that the total electrolyte charge is +2,
setting *qtotal -2* would cause the total electrode charge to be -2, so
that the simulation box remains overall electroneutral. Since *fix
electrode/conq* constrains the total charges of individual electrodes,
and since *symm on* constrains the total charge of all electrodes to be
zero, either option is incompatible with the *qtotal* keyword (even if
*qtotal* is set to zero).
The keyword *eta* takes the name of a custom double vector defined via fix
property/atom. The values will be used instead of the standard eta value. The
property/atom fix must be for vector of double values and use the *ghost on*
option.
.. versionadded:: 17Apr2024
The keyword *eta* takes the name of a custom double vector defined via
fix property/atom. The values will be used instead of the standard eta
value. The property/atom fix must be for vector of double values and
use the *ghost on* option.
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

73
doc/src/fix_gcmc.rst
View File

@ -15,7 +15,7 @@ Syntax
* N = invoke this fix every N steps
* X = average number of GCMC exchanges to attempt every N steps
* M = average number of MC moves to attempt every N steps
* type = atom type for inserted atoms (must be 0 if mol keyword used)
* type = atom type (1-Ntypes or type label) for inserted atoms (must be 0 if mol keyword used)
* seed = random # seed (positive integer)
* T = temperature of the ideal gas reservoir (temperature units)
* mu = chemical potential of the ideal gas reservoir (energy units)
@ -45,7 +45,7 @@ Syntax
*group* value = group-ID
group-ID = group-ID for inserted atoms (string)
*grouptype* values = type group-ID
type = atom type (int)
type = atom type (1-Ntypes or type label)
group-ID = group-ID for inserted atoms (string)
*intra_energy* value = intramolecular energy (energy units)
*tfac_insert* value = scale up/down temperature of inserted atoms (unitless)
@ -62,52 +62,47 @@ Examples
fix 3 water gcmc 10 100 100 0 3456543 3.0 -2.5 0.1 mol my_one_water maxangle 180 full_energy
fix 4 my_gas gcmc 1 10 10 1 123456543 300.0 -12.5 1.0 region disk
labelmap atom 1 Li
fix 2 ion gcmc 10 1000 1000 Li 29494 298.0 -0.5 0.01
Description
"""""""""""
This fix performs grand canonical Monte Carlo (GCMC) exchanges of
atoms or molecules with an imaginary ideal gas
reservoir at the specified T and chemical potential (mu) as discussed
in :ref:`(Frenkel) <Frenkel2>`. It also
attempts Monte Carlo (MC) moves (translations and molecule
rotations) within the simulation cell or
region. If used with the :doc:`fix nvt <fix_nh>`
This fix performs grand canonical Monte Carlo (GCMC) exchanges of atoms or
molecules with an imaginary ideal gas reservoir at the specified T and
chemical potential (mu) as discussed in :ref:`(Frenkel) <Frenkel2>`. It
also attempts Monte Carlo (MC) moves (translations and molecule rotations)
within the simulation cell or region. If used with the :doc:`fix nvt <fix_nh>`
command, simulations in the grand canonical ensemble (muVT, constant
chemical potential, constant volume, and constant temperature) can be
performed. Specific uses include computing isotherms in microporous
materials, or computing vapor-liquid coexistence curves.
Every N timesteps the fix attempts both GCMC exchanges
(insertions or deletions) and MC moves of gas atoms or molecules.
On those timesteps, the average number of attempted GCMC exchanges is X,
while the average number of attempted MC moves is M.
For GCMC exchanges of either molecular or atomic gasses,
these exchanges can be either deletions or insertions,
with equal probability.
Every N timesteps the fix attempts both GCMC exchanges (insertions or
deletions) and MC moves of gas atoms or molecules. On those timesteps, the
average number of attempted GCMC exchanges is X, while the average number
of attempted MC moves is M. For GCMC exchanges of either molecular or
atomic gasses, these exchanges can be either deletions or insertions, with
equal probability.
The possible choices for MC moves are translation of an atom,
translation of a molecule, and rotation of a molecule.
The relative amounts of each are determined by the optional
*mcmoves* keyword (see below).
The default behavior is as follows.
If the *mol* keyword is used, only molecule translations
and molecule rotations are performed with equal probability.
Conversely, if the *mol* keyword is not used, only atom
translations are performed.
M should typically be
chosen to be approximately equal to the expected number of gas atoms
or molecules of the given type within the simulation cell or region,
which will result in roughly one MC move per atom or molecule
per MC cycle.
The possible choices for MC moves are translation of an atom, translation
of a molecule, and rotation of a molecule. The relative amounts of each are
determined by the optional *mcmoves* keyword (see below). The default
behavior is as follows. If the *mol* keyword is used, only molecule
translations and molecule rotations are performed with equal probability.
Conversely, if the *mol* keyword is not used, only atom translations are
performed. M should typically be chosen to be approximately equal to the
expected number of gas atoms or molecules of the given type within the
simulation cell or region, which will result in roughly one MC move per
atom or molecule per MC cycle.
All inserted particles are always added to two groups: the default
group "all" and the fix group specified in the fix command.
In addition, particles are also added to any groups
specified by the *group* and *grouptype* keywords. If inserted
particles are individual atoms, they are assigned the atom type given
by the type argument. If they are molecules, the type argument has no
effect and must be set to zero. Instead, the type of each atom in the
inserted molecule is specified in the file read by the
All inserted particles are always added to two groups: the default group
"all" and the fix group specified in the fix command. In addition,
particles are also added to any groups specified by the *group* and
*grouptype* keywords. If inserted particles are individual atoms, they are
assigned the atom type given by the type argument. If they are molecules,
the type argument has no effect and must be set to zero. Instead, the type
of each atom in the inserted molecule is specified in the file read by the
:doc:`molecule <molecule>` command.
.. note::
@ -427,7 +422,7 @@ the following global cumulative quantities:
* 7 = rotation attempts
* 8 = rotation successes
The vector values calculated by this fix are "extensive".
The vector values calculated by this fix are "intensive".
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during

3
doc/src/fix_hyper_local.rst
View File

@ -512,8 +512,7 @@ Value 27 computes the average boost for biased bonds only on this step.
Value 28 is the count of bonds with an absolute value of strain >= q
on this step.
The scalar value is an "extensive" quantity since it grows with the
system size; the vector values are all "intensive".
The scalar value and vector values are all "intensive".
This fix also computes a local vector of length the number of bonds
currently in the system. The value for each bond is its :math:`C_{ij}`

90
doc/src/fix_indent.rst
View File

@ -8,33 +8,44 @@ Syntax
.. code-block:: LAMMPS
fix ID group-ID indent K keyword values ...
fix ID group-ID indent K gstyle args keyword value ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* indent = style name of this fix command
* K = force constant for indenter surface (force/distance\^2 units)
* one or more keyword/value pairs may be appended
* keyword = *sphere* or *cylinder* or *plane* or *side* or *units*
* gstyle = *sphere* or *cylinder* or *cone* or *plane*
.. parsed-literal::
*sphere* args = x y z R
x,y,z = position of center of indenter (distance units)
x, y, z = position of center of indenter (distance units)
R = sphere radius of indenter (distance units)
any of x,y,z,R can be a variable (see below)
any of x, y, z, R can be a variable (see below)
*cylinder* args = dim c1 c2 R
dim = *x* or *y* or *z* = axis of cylinder
c1,c2 = coords of cylinder axis in other 2 dimensions (distance units)
c1, c2 = coords of cylinder axis in other 2 dimensions (distance units)
R = cylinder radius of indenter (distance units)
any of c1,c2,R can be a variable (see below)
*cone* args = dim c1 c2 radlo radhi lo hi
dim = *x* or *y* or *z* = axis of cone
c1, c2 = coords of cone axis in other 2 dimensions (distance units)
radlo,radhi = cone radii at lo and hi end (distance units)
lo,hi = bounds of cone in dim (distance units)
any of c1, c2, radlo, radhi, lo, hi can be a variable (see below)
*plane* args = dim pos side
dim = *x* or *y* or *z* = plane perpendicular to this dimension
pos = position of plane in dimension x, y, or z (distance units)
pos can be a variable (see below)
side = *lo* or *hi*
* zero or more keyword/value pairs may be appended
* keyword = *side* or *units*
.. parsed-literal::
*side* value = *in* or *out*
*in* = the indenter acts on particles inside the sphere or cylinder
*out* = the indenter acts on particles outside the sphere or cylinder
*in* = the indenter acts on particles inside the sphere or cylinder or cone
*out* = the indenter acts on particles outside the sphere or cylinder or cone
*units* value = *lattice* or *box*
lattice = the geometry is defined in lattice units
box = the geometry is defined in simulation box units
@ -53,12 +64,12 @@ Description
Insert an indenter within a simulation box. The indenter repels all
atoms in the group that touch it, so it can be used to push into a
material or as an obstacle in a flow. Or it can be used as a
material or as an obstacle in a flow. Alternatively, it can be used as a
constraining wall around a simulation; see the discussion of the
*side* keyword below.
The indenter can either be spherical or cylindrical or planar. You
must set one of those 3 keywords.
The *gstyle* geometry of the indenter can either be a sphere, a
cylinder, a cone, or a plane.
A spherical indenter exerts a force of magnitude
@ -75,15 +86,20 @@ A cylindrical indenter exerts the same force, except that *r* is the
distance from the atom to the center axis of the cylinder. The
cylinder extends infinitely along its axis.
Spherical and cylindrical indenters account for periodic boundaries in
two ways. First, the center point of a spherical indenter (x,y,z) or
axis of a cylindrical indenter (c1,c2) is remapped back into the
simulation box, if the box is periodic in a particular dimension.
This occurs every timestep if the indenter geometry is specified with
a variable (see below), e.g. it is moving over time. Second, the
calculation of distance to the indenter center or axis accounts for
periodic boundaries. Both of these mean that an indenter can
effectively move through and straddle one or more periodic boundaries.
A conical indenter is similar to a cylindrical indenter except that it
has a finite length (between *lo* and *hi*), and that two different
radii (one at each end, *radlo* and *radhi*) can be defined.
Spherical, cylindrical, and conical indenters account for periodic
boundaries in two ways. First, the center point of a spherical
indenter (x,y,z) or axis of a cylindrical/conical indenter (c1,c2) is
remapped back into the simulation box, if the box is periodic in a
particular dimension. This occurs every timestep if the indenter
geometry is specified with a variable (see below), e.g. it is moving
over time. Second, the calculation of distance to the indenter center
or axis accounts for periodic boundaries. Both of these mean that an
indenter can effectively move through and straddle one or more
periodic boundaries.
A planar indenter is really an axis-aligned infinite-extent wall
exerting the same force on atoms in the system, where *R* is the
@ -97,9 +113,13 @@ is specified as *hi*\ .
Any of the 4 quantities defining a spherical indenter's geometry can
be specified as an equal-style :doc:`variable <variable>`, namely *x*,
*y*, *z*, or *R*\ . Similarly, for a cylindrical indenter, any of *c1*,
*c2*, or *R*, can be a variable. For a planar indenter, *pos* can be
a variable. If the value is a variable, it should be specified as
*y*, *z*, or *R*\ . For a cylindrical indenter, any of the 3
quantities *c1*, *c2*, or *R*, can be a variable. For a conical
indenter, any of the 6 quantities *c1*, *c2*, *radlo*, *radhi*, *lo*,
or *hi* can be a variable. For a planar indenter, the single value
*pos* can be a variable.
If any of these values is a variable, it should be specified as
v_name, where name is the variable name. In this case, the variable
will be evaluated each timestep, and its value used to define the
indenter geometry.
@ -110,7 +130,8 @@ command keywords for the simulation box parameters and timestep and
elapsed time. Thus it is easy to specify indenter properties that
change as a function of time or span consecutive runs in a continuous
fashion. For the latter, see the *start* and *stop* keywords of the
:doc:`run <run>` command and the *elaplong* keyword of :doc:`thermo_style custom <thermo_style>` for details.
:doc:`run <run>` command and the *elaplong* keyword of
:doc:`thermo_style custom <thermo_style>` for details.
For example, if a spherical indenter's x-position is specified as v_x,
then this variable definition will keep it's center at a relative
@ -141,12 +162,13 @@ rate.
If the *side* keyword is specified as *out*, which is the default,
then particles outside the indenter are pushed away from its outer
surface, as described above. This only applies to spherical or
cylindrical indenters. If the *side* keyword is specified as *in*,
the action of the indenter is reversed. Particles inside the indenter
are pushed away from its inner surface. In other words, the indenter
is now a containing wall that traps the particles inside it. If the
radius shrinks over time, it will squeeze the particles.
surface, as described above. This only applies to spherical,
cylindrical, and conical indenters. If the *side* keyword is
specified as *in*, the action of the indenter is reversed. Particles
inside the indenter are pushed away from its inner surface. In other
words, the indenter is now a containing wall that traps the particles
inside it. If the radius shrinks over time, it will squeeze the
particles.
The *units* keyword determines the meaning of the distance units used
to define the indenter geometry. A *box* value selects standard
@ -166,10 +188,10 @@ lattice spacings in a variable formula.
The force constant *K* is not affected by the *units* keyword. It is
always in force/distance\^2 units where force and distance are defined
by the :doc:`units <units>` command. If you wish K to be scaled by the
lattice spacing, you can define K with a variable whose formula
contains *xlat*, *ylat*, *zlat* keywords of the
:doc:`thermo_style <thermo_style>` command, e.g.
by the :doc:`units <units>` command. If you wish K to be scaled by
the lattice spacing, you can define K with a variable whose formula
contains *xlat*, *ylat*, *zlat* keywords of the :doc:`thermo_style
<thermo_style>` command, e.g.
.. code-block:: LAMMPS

54
doc/src/fix_ipi.rst
View File

@ -35,23 +35,24 @@ Description
"""""""""""
This fix enables LAMMPS to be run as a client for the i-PI Python
wrapper :ref:`(IPI) <ipihome>` for performing a path integral molecular dynamics
(PIMD) simulation. The philosophy behind i-PI is described in the
following publication :ref:`(IPI-CPC) <IPICPC>`.
wrapper :ref:`(IPI) <ipihome>`. i-PI is a universal force engine,
designed to perform advanced molecular simulations, with a special
focus on path integral molecular dynamics (PIMD) simulation.
The philosophy behind i-PI is to separate the evaluation of the
energy and forces, which is delegated to the client, and the evolution
of the dynamics, that is the responsibility of i-PI. This approach also
simplifies combining energies computed from different codes, which
can for instance be useful to mix first-principles calculations,
empirical force fields or machine-learning potentials.
The following publication :ref:`(IPI-CPC-2014) <IPICPC>` discusses the
overall implementation of i-PI, and focuses on path-integral techniques,
while a later release :ref:`(IPI-CPC-2019) <IPICPC2>` introduces several
additional features and simulation schemes.
A version of the i-PI package, containing only files needed for use
with LAMMPS, is provided in the tools/i-pi directory. See the
tools/i-pi/manual.pdf for an introduction to i-PI. The
examples/PACKAGES/i-pi directory contains example scripts for using i-PI
with LAMMPS.
In brief, the path integral molecular dynamics is performed by the
Python wrapper, while the client (LAMMPS in this case) simply computes
forces and energy for each configuration. The communication between
the two components takes place using sockets, and is reduced to the
bare minimum. All the parameters of the dynamics are specified in the
input of i-PI, and all the parameters of the force field must be
specified as LAMMPS inputs, preceding the *fix ipi* command.
The communication between i-PI and LAMMPS takes place using sockets,
and is reduced to the bare minimum. All the parameters of the dynamics
are specified in the input of i-PI, and all the parameters of the force
field must be specified as LAMMPS inputs, preceding the *fix ipi* command.
The server address must be specified by the *address* argument, and
can be either the IP address, the fully-qualified name of the server,
@ -75,6 +76,20 @@ If the cell varies too wildly, it may be advisable to re-initialize
these interactions at each call. This behavior can be requested by
setting the *reset* switch.
Obtaining i-PI
""""""""""""""
Here are the commands to set up a virtual environment and install
i-PI into it with all its dependencies via the PyPI repository and
the pip package manager.
.. code-block:: sh
python -m venv ipienv
source ipienv/bin/activate
pip install --upgrade pip
pip install ipi
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
@ -111,9 +126,14 @@ Related commands
.. _IPICPC:
**(IPI-CPC)** Ceriotti, More and Manolopoulos, Comp Phys Comm, 185,
**(IPI-CPC-2014)** Ceriotti, More and Manolopoulos, Comp Phys Comm 185,
1019-1026 (2014).
.. _IPICPC2:
**(IPI-CPC-2019)** Kapil et al., Comp Phys Comm 236, 214-223 (2019).
.. _ipihome:
**(IPI)**

7
doc/src/fix_mol_swap.rst
View File

@ -14,7 +14,7 @@ Syntax
* atom/swap = style name of this fix command
* N = invoke this fix every N steps
* X = number of swaps to attempt every N steps
* itype,jtype = two atom types to swap with each other
* itype,jtype = two atom types (1-Ntypes or type label) to swap with each other
* seed = random # seed (positive integer)
* T = scaling temperature of the MC swaps (temperature units)
* zero or more keyword/value pairs may be appended to args
@ -34,6 +34,9 @@ Examples
fix 2 all mol/swap 100 1 2 3 29494 300.0 ke no
fix mySwap fluid mol/swap 500 10 1 2 482798 1.0
labelmap atom 1 A 2 B
fix mySwap fluid mol/swap 500 10 A B 482798 1.0
Description
"""""""""""
@ -146,7 +149,7 @@ the following global cumulative quantities:
* 1 = swap attempts
* 2 = swap accepts
The vector values calculated by this fix are "extensive".
The vector values calculated by this fix are "intensive".
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during

19
doc/src/fix_nonaffine_displacement.rst
View File

@ -8,7 +8,7 @@ Syntax
.. parsed-literal::
fix ID group nonaffine/displacement style args reference/style nstep
fix ID group nonaffine/displacement style args reference/style nstep keyword values
* ID, group are documented in :doc:`fix <fix>` command
* nonaffine/displacement = style name of this fix command
@ -32,6 +32,13 @@ Syntax
*update* = update the reference frame every *nstep* timesteps
*offset* = update the reference frame *nstep* timesteps before calculating the nonaffine displacement
* zero or more keyword/value pairs may be appended
.. parsed-literal::
*z/min* values = zmin
zmin = minimum coordination number to calculate D2min
Examples
""""""""
@ -76,6 +83,12 @@ is the identity tensor. This calculation is only performed on timesteps that
are a multiple of *nevery* (including timestep zero). Data accessed before
this occurs will simply be zeroed.
For particles with low coordination numbers, calculations of :math:`D^2_\mathrm{min}`
may not be accurate. An optional minimum coordination number can be defined using
the *z/min* keyword. If any particle has fewer than the specified number of particles
in the cutoff distance or in contact, the above calculations will be skipped and the
corresponding peratom array entries will be zero.
The *integrated* style simply integrates the velocity of particles
every timestep to calculate a displacement. This style only works if
used in conjunction with another fix that deforms the box and displaces
@ -86,8 +99,8 @@ Both of these methods require defining a reference state. With the *fixed* refer
style, the user picks a specific timestep *nstep* at which particle positions are saved.
If peratom data is accessed from this compute prior to this timestep, it will simply be
zeroed. The *update* reference style implies the reference state will be updated every
*nstep* timesteps. The *offset* reference only applies to the *d2min* metric and will
update the reference state *nstep* timesteps before a multiple of *nevery* timesteps.
*nstep* timesteps. The *offset* reference will update the reference state *nstep*
timesteps before a multiple of *nevery* timesteps.
----------

74
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* or *delete*
* keyword = *cutoff* or *element* or *position* or *delete* or *delete_rate_limit*
.. parsed-literal::
@ -110,10 +110,10 @@ all types from 1 to :math:`N`. A leading asterisk means all types from
The optional keyword *element* can be used to specify the chemical
symbol printed for each LAMMPS atom type. The number of symbols must
match the number of LAMMPS atom types and each symbol must consist of
1 or 2 alphanumeric characters. Normally, these symbols should be
chosen to match the chemical identity of each LAMMPS atom type, as
specified using the :doc:`reaxff pair_coeff <pair_reaxff>` command and
the ReaxFF force field file.
1 or 2 alphanumeric characters. By default, these symbols are the same
as the chemical identity of each LAMMPS atom type, as specified by the
:doc:`ReaxFF pair_coeff <pair_reaxff>` command and the ReaxFF force
field file.
The optional keyword *position* writes center-of-mass positions of
each identified molecules to file *filepos* every *posfreq* timesteps.
@ -134,36 +134,34 @@ value. For example, AuO.pos.\* becomes AuO.pos.0, AuO.pos.1000, etc.
.. versionadded:: 3Aug2022
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 *delete_rate_limit*
keyword can enforce an upper limit on the overall rate of molecule
deletion. The number of deletion occurrences is limited to Nlimit
within an interval of Nsteps timesteps. Nlimit can be specified with
an equal-style :doc:`variable <variable>`. When using the
*delete_rate_limit* keyword, no deletions are permitted to occur
within the first Nsteps timesteps of the first run (after reading a
either a data or restart file).
The optional keyword *delete* enables the periodic removal of molecules
from the system :ref:`(Gissinger) <Delete>`. 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 *delete_rate_limit* keyword
can enforce an upper limit on the overall rate of molecule deletion. The
number of deletion occurrences is limited to Nlimit within an interval of
Nsteps timesteps. Nlimit can be specified with an equal-style
:doc:`variable <variable>`. When using the *delete_rate_limit* keyword, no
deletions are permitted to occur within the first Nsteps timesteps of the
first run (after reading a either a data or restart file).
----------
@ -233,5 +231,9 @@ Default
"""""""
The default values for bond-order cutoffs are 0.3 for all I-J pairs.
The default element symbols are C, H, O, N.
The default element symbols are taken from the ReaxFF pair_coeff command.
Position files are not written by default.
.. _Delete:
**(Gissinger)** Jacob R. Gissinger, Scott R. Zavada, Joseph G. Smith, Josh Kemppainen, Ivan Gallegos, Gregory M. Odegard, Emilie J. Siochi, and Kristopher E. Wise, Carbon, 202, 336-347 (2023).

281
doc/src/fix_rigid.rst
View File

@ -171,14 +171,15 @@ Examples of large rigid bodies are a colloidal particle, or portions
of a biomolecule such as a protein.
Example of small rigid bodies are patchy nanoparticles, such as those
modeled in :ref:`this paper <Zhang1>` by Sharon Glotzer's group, clumps of
granular particles, lipid molecules consisting of one or more point
dipoles connected to other spheroids or ellipsoids, irregular
particles built from line segments (2d) or triangles (3d), and
coarse-grain models of nano or colloidal particles consisting of a
small number of constituent particles. Note that the :doc:`fix shake <fix_shake>` command can also be used to rigidify small
molecules of 2, 3, or 4 atoms, e.g. water molecules. That fix treats
the constituent atoms as point masses.
modeled in :ref:`this paper <Zhang1>` by Sharon Glotzer's group,
clumps of granular particles, lipid molecules consisting of one or
more point dipoles connected to other spheroids or ellipsoids,
irregular particles built from line segments (2d) or triangles (3d),
and coarse-grain models of nano or colloidal particles consisting of a
small number of constituent particles. Note that the :doc:`fix shake
<fix_shake>` command can also be used to rigidify small molecules of
2, 3, or 4 atoms, e.g. water molecules. That fix treats the
constituent atoms as point masses.
These fixes also update the positions and velocities of the atoms in
each rigid body via time integration, in the NVE, NVT, NPT, or NPH
@ -212,13 +213,14 @@ processors when ghost atom info is accumulated.
.. note::
To use the *rigid/small* styles the ghost atom cutoff must be
large enough to span the distance between the atom that owns the body
and every other atom in the body. This distance value is printed out
when the rigid bodies are defined. If the
:doc:`pair_style <pair_style>` cutoff plus neighbor skin does not span
this distance, then you should use the :doc:`comm_modify cutoff <comm_modify>` command with a setting epsilon larger than
the distance.
To use the *rigid/small* styles the ghost atom cutoff must be large
enough to span the distance between the atom that owns the body and
every other atom in the body. This distance value is printed out
when the rigid bodies are defined. If the :doc:`pair_style
<pair_style>` cutoff plus neighbor skin does not span this
distance, then you should use the :doc:`comm_modify cutoff
<comm_modify>` command with a setting epsilon larger than the
distance.
Which of the two variants is faster for a particular problem is hard
to predict. The best way to decide is to perform a short test run.
@ -229,49 +231,54 @@ differences may accumulate to produce divergent trajectories.
.. note::
You should not update the atoms in rigid bodies via other
time-integration fixes (e.g. :doc:`fix nve <fix_nve>`, :doc:`fix nvt <fix_nh>`, :doc:`fix npt <fix_nh>`, :doc:`fix move <fix_move>`),
or you will have conflicting updates to positions and velocities
resulting in unphysical behavior in most cases. When performing a hybrid
simulation with some atoms in rigid bodies, and some not, a separate
time integration fix like :doc:`fix nve <fix_nve>` or :doc:`fix nvt <fix_nh>` should be used for the non-rigid particles.
time-integration fixes (e.g. :doc:`fix nve <fix_nve>`, :doc:`fix
nvt <fix_nh>`, :doc:`fix npt <fix_nh>`, :doc:`fix move
<fix_move>`), or you will have conflicting updates to positions and
velocities resulting in unphysical behavior in most cases. When
performing a hybrid simulation with some atoms in rigid bodies, and
some not, a separate time integration fix like :doc:`fix nve
<fix_nve>` or :doc:`fix nvt <fix_nh>` should be used for the
non-rigid particles.
.. note::
These fixes are overkill if you simply want to hold a collection
of atoms stationary or have them move with a constant velocity. A
simpler way to hold atoms stationary is to not include those atoms in
your time integration fix. E.g. use "fix 1 mobile nve" instead of
"fix 1 all nve", where "mobile" is the group of atoms that you want to
move. You can move atoms with a constant velocity by assigning them
an initial velocity (via the :doc:`velocity <velocity>` command),
setting the force on them to 0.0 (via the :doc:`fix setforce <fix_setforce>` command), and integrating them as usual
(e.g. via the :doc:`fix nve <fix_nve>` command).
These fixes are overkill if you simply want to hold a collection of
atoms stationary or have them move with a constant velocity. A
simpler way to hold atoms stationary is to not include those atoms
in your time integration fix. E.g. use "fix 1 mobile nve" instead
of "fix 1 all nve", where "mobile" is the group of atoms that you
want to move. You can move atoms with a constant velocity by
assigning them an initial velocity (via the :doc:`velocity
<velocity>` command), setting the force on them to 0.0 (via the
:doc:`fix setforce <fix_setforce>` command), and integrating them
as usual (e.g. via the :doc:`fix nve <fix_nve>` command).
.. warning::
The aggregate properties of each rigid body are
calculated at the start of a simulation run and are maintained in
internal data structures. The properties include the position and
velocity of the center-of-mass of the body, its moments of inertia, and
its angular momentum. This is done using the properties of the
constituent atoms of the body at that point in time (or see the *infile*
keyword option). Thereafter, changing these properties of individual
atoms in the body will have no effect on a rigid body's dynamics, unless
they effect any computation of per-atom forces or torques. If the
keyword *reinit* is set to *yes* (the default), the rigid body data
structures will be recreated at the beginning of each *run* command;
if the keyword *reinit* is set to *no*, the rigid body data structures
will be built only at the very first *run* command and maintained for
as long as the rigid fix is defined. For example, you might think you
could displace the atoms in a body or add a large velocity to each atom
in a body to make it move in a desired direction before a second run is
performed, using the :doc:`set <set>` or
:doc:`displace_atoms <displace_atoms>` or :doc:`velocity <velocity>`
commands. But these commands will not affect the internal attributes
of the body unless *reinit* is set to *yes*\ . With *reinit* set to *no*
(or using the *infile* option, which implies *reinit* *no*\ ) the position
and velocity of individual atoms in the body will be reset when time
integration starts again.
The aggregate properties of each rigid body are calculated at the
start of a simulation run and are maintained in internal data
structures. The properties include the position and velocity of the
center-of-mass of the body, its moments of inertia, and its angular
momentum. This is done using the properties of the constituent
atoms of the body at that point in time (or see the *infile*
keyword option). Thereafter, changing these properties of
individual atoms in the body will have no effect on a rigid body's
dynamics, unless they effect any computation of per-atom forces or
torques. If the keyword *reinit* is set to *yes* (the default), the
rigid body data structures will be recreated at the beginning of
each *run* command; if the keyword *reinit* is set to *no*, the
rigid body data structures will be built only at the very first
*run* command and maintained for as long as the rigid fix is
defined. For example, you might think you could displace the atoms
in a body or add a large velocity to each atom in a body to make it
move in a desired direction before a second run is performed, using
the :doc:`set <set>` or :doc:`displace_atoms <displace_atoms>` or
:doc:`velocity <velocity>` commands. But these commands will not
affect the internal attributes of the body unless *reinit* is set
to *yes*\ . With *reinit* set to *no* (or using the *infile*
option, which implies *reinit* *no*\ ) the position and velocity of
individual atoms in the body will be reset when time integration
starts again.
----------
@ -316,17 +323,17 @@ to be part of rigid bodies.
.. note::
To compute the initial center-of-mass position and other
properties of each rigid body, the image flags for each atom in the
body are used to "unwrap" the atom coordinates. Thus you must ensure
that these image flags are consistent so that the unwrapping creates a
To compute the initial center-of-mass position and other properties
of each rigid body, the image flags for each atom in the body are
used to "unwrap" the atom coordinates. Thus you must ensure that
these image flags are consistent so that the unwrapping creates a
valid rigid body (one where the atoms are close together),
particularly if the atoms in a single rigid body straddle a periodic
boundary. This means the input data file or restart file must define
the image flags for each atom consistently or that you have used the
:doc:`set <set>` command to specify them correctly. If a dimension is
non-periodic then the image flag of each atom must be 0 in that
dimension, else an error is generated.
particularly if the atoms in a single rigid body straddle a
periodic boundary. This means the input data file or restart file
must define the image flags for each atom consistently or that you
have used the :doc:`set <set>` command to specify them correctly.
If a dimension is non-periodic then the image flag of each atom
must be 0 in that dimension, else an error is generated.
The *force* and *torque* keywords discussed next are only allowed for
the *rigid* styles.
@ -362,12 +369,13 @@ settings from the final keyword are used.
.. note::
For computational efficiency, you may wish to turn off pairwise
and bond interactions within each rigid body, as they no longer
contribute to the motion. The :doc:`neigh_modify exclude <neigh_modify>` and :doc:`delete_bonds <delete_bonds>`
commands are used to do this. If the rigid bodies have strongly
overlapping atoms, you may need to turn off these interactions to
avoid numerical problems due to large equal/opposite intra-body forces
For computational efficiency, you may wish to turn off pairwise and
bond interactions within each rigid body, as they no longer
contribute to the motion. The :doc:`neigh_modify exclude
<neigh_modify>` and :doc:`delete_bonds <delete_bonds>` commands are
used to do this. If the rigid bodies have strongly overlapping
atoms, you may need to turn off these interactions to avoid
numerical problems due to large equal/opposite intra-body forces
swamping the contribution of small inter-body forces.
For computational efficiency, you should typically define one fix
@ -379,7 +387,8 @@ is more expensive.
The constituent particles within a rigid body can be point particles
(the default in LAMMPS) or finite-size particles, such as spheres or
ellipsoids or line segments or triangles. See the :doc:`atom_style sphere and ellipsoid and line and tri <atom_style>` commands for more
ellipsoids or line segments or triangles. See the :doc:`atom_style
sphere and ellipsoid and line and tri <atom_style>` commands for more
details on these kinds of particles. Finite-size particles contribute
differently to the moment of inertia of a rigid body than do point
particles. Finite-size particles can also experience torque (e.g. due
@ -389,7 +398,8 @@ orientation. These contributions are accounted for by these fixes.
Forces between particles within a body do not contribute to the
external force or torque on the body. Thus for computational
efficiency, you may wish to turn off pairwise and bond interactions
between particles within each rigid body. The :doc:`neigh_modify exclude <neigh_modify>` and :doc:`delete_bonds <delete_bonds>`
between particles within each rigid body. The :doc:`neigh_modify
exclude <neigh_modify>` and :doc:`delete_bonds <delete_bonds>`
commands are used to do this. For finite-size particles this also
means the particles can be highly overlapped when creating the rigid
body.
@ -401,16 +411,17 @@ perform constant NVE time integration. They are referred to below as
the 4 NVE rigid styles. The only difference is that the *rigid* and
*rigid/small* styles use an integration technique based on Richardson
iterations. The *rigid/nve* and *rigid/small/nve* styles uses the
methods described in the paper by :ref:`Miller <Miller3>`, which are thought
to provide better energy conservation than an iterative approach.
methods described in the paper by :ref:`Miller <Miller3>`, which are
thought to provide better energy conservation than an iterative
approach.
The *rigid/nvt* and *rigid/nvt/small* styles performs constant NVT
integration using a Nose/Hoover thermostat with chains as described
originally in :ref:`(Hoover) <Hoover>` and :ref:`(Martyna) <Martyna2>`, which
thermostats both the translational and rotational degrees of freedom
of the rigid bodies. They are referred to below as the 2 NVT rigid
styles. The rigid-body algorithm used by *rigid/nvt* is described in
the paper by :ref:`Kamberaj <Kamberaj>`.
originally in :ref:`(Hoover) <Hoover>` and :ref:`(Martyna)
<Martyna2>`, which thermostats both the translational and rotational
degrees of freedom of the rigid bodies. They are referred to below as
the 2 NVT rigid styles. The rigid-body algorithm used by *rigid/nvt*
is described in the paper by :ref:`Kamberaj <Kamberaj>`.
The *rigid/npt*, *rigid/nph*, *rigid/npt/small*, and *rigid/nph/small*
styles perform constant NPT or NPH integration using a Nose/Hoover
@ -436,12 +447,12 @@ The target pressures for each of the 6 components of the stress tensor
can be specified independently via the *x*, *y*, *z* keywords, which
correspond to the 3 simulation box dimensions. For each component,
the external pressure or tensor component at each timestep is a ramped
value during the run from *Pstart* to *Pstop*\ . If a target pressure is
specified for a component, then the corresponding box dimension will
change during a simulation. For example, if the *y* keyword is used,
the y-box length will change. A box dimension will not change if that
component is not specified, although you have the option to change
that dimension via the :doc:`fix deform <fix_deform>` command.
value during the run from *Pstart* to *Pstop*\ . If a target pressure
is specified for a component, then the corresponding box dimension
will change during a simulation. For example, if the *y* keyword is
used, the y-box length will change. A box dimension will not change
if that component is not specified, although you have the option to
change that dimension via the :doc:`fix deform <fix_deform>` command.
For all barostat keywords, the *Pdamp* parameter operates like the
*Tdamp* parameter, determining the time scale on which pressure is
@ -525,11 +536,11 @@ discussed below.
The *langevin* keyword applies a Langevin thermostat to the constant
NVE time integration performed by any of the 4 NVE rigid styles:
*rigid*, *rigid/nve*, *rigid/small*, *rigid/small/nve*\ . It cannot be
used with the 2 NVT rigid styles: *rigid/nvt*, *rigid/small/nvt*\ . The
desired temperature at each timestep is a ramped value during the run
from *Tstart* to *Tstop*\ . The *Tdamp* parameter is specified in time
units and determines how rapidly the temperature is relaxed. For
*rigid*, *rigid/nve*, *rigid/small*, *rigid/small/nve*\ . It cannot
be used with the 2 NVT rigid styles: *rigid/nvt*, *rigid/small/nvt*\ .
The desired temperature at each timestep is a ramped value during the
run from *Tstart* to *Tstop*\ . The *Tdamp* parameter is specified in
time units and determines how rapidly the temperature is relaxed. For
example, a value of 100.0 means to relax the temperature in a timespan
of (roughly) 100 time units (:math:`\tau` or fs or ps - see the
:doc:`units <units>` command). The random # *seed* must be a positive
@ -564,29 +575,30 @@ used. *Tchain* is the number of thermostats in the Nose Hoover chain.
This value, along with *Tdamp* can be varied to dampen undesirable
oscillations in temperature that can occur in a simulation. As a rule
of thumb, increasing the chain length should lead to smaller
oscillations. The keyword *pchain* specifies the number of
thermostats in the chain thermostatting the barostat degrees of
freedom.
oscillations. The keyword *pchain* specifies the number of thermostats
in the chain thermostatting the barostat degrees of freedom.
.. note::
There are alternate ways to thermostat a system of rigid bodies.
You can use :doc:`fix langevin <fix_langevin>` to treat the individual
particles in the rigid bodies as effectively immersed in an implicit
solvent, e.g. a Brownian dynamics model. For hybrid systems with both
rigid bodies and solvent particles, you can thermostat only the
solvent particles that surround one or more rigid bodies by
appropriate choice of groups in the compute and fix commands for
temperature and thermostatting. The solvent interactions with the
rigid bodies should then effectively thermostat the rigid body
temperature as well without use of the Langevin or Nose/Hoover options
associated with the fix rigid commands.
You can use :doc:`fix langevin <fix_langevin>` to treat the
individual particles in the rigid bodies as effectively immersed in
an implicit solvent, e.g. a Brownian dynamics model. For hybrid
systems with both rigid bodies and solvent particles, you can
thermostat only the solvent particles that surround one or more
rigid bodies by appropriate choice of groups in the compute and fix
commands for temperature and thermostatting. The solvent
interactions with the rigid bodies should then effectively
thermostat the rigid body temperature as well without use of the
Langevin or Nose/Hoover options associated with the fix rigid
commands.
----------
The *mol* keyword can only be used with the *rigid/small* styles. It
must be used when other commands, such as :doc:`fix deposit <fix_deposit>` or :doc:`fix pour <fix_pour>`, add rigid
bodies on-the-fly during a simulation. You specify a *template-ID*
must be used when other commands, such as :doc:`fix deposit
<fix_deposit>` or :doc:`fix pour <fix_pour>`, add rigid bodies
on-the-fly during a simulation. You specify a *template-ID*
previously defined using the :doc:`molecule <molecule>` command, which
reads a file that defines the molecule. You must use the same
*template-ID* that the other fix which is adding rigid bodies uses.
@ -670,16 +682,16 @@ cross periodic boundaries during the simulation.
.. note::
If you use the *infile* or *mol* keywords and write restart
files during a simulation, then each time a restart file is written,
the fix also write an auxiliary restart file with the name
rfile.rigid, where "rfile" is the name of the restart file,
If you use the *infile* or *mol* keywords and write restart files
during a simulation, then each time a restart file is written, the
fix also write an auxiliary restart file with the name rfile.rigid,
where "rfile" is the name of the restart file,
e.g. tmp.restart.10000 and tmp.restart.10000.rigid. This auxiliary
file is in the same format described above. Thus it can be used in a
new input script that restarts the run and re-specifies a rigid fix
using an *infile* keyword and the appropriate filename. Note that the
auxiliary file will contain one line for every rigid body, even if the
original file only listed a subset of the rigid bodies.
file is in the same format described above. Thus it can be used in
a new input script that restarts the run and re-specifies a rigid
fix using an *infile* keyword and the appropriate filename. Note
that the auxiliary file will contain one line for every rigid body,
even if the original file only listed a subset of the rigid bodies.
If the system has rigid bodies with finite-size overlapping particles
and the model uses the :doc:`fix gravity <fix_gravity>` command to
@ -728,10 +740,11 @@ also accounted for by this fix.
----------
If your simulation is a hybrid model with a mixture of rigid bodies and
non-rigid particles (e.g. solvent) there are several ways these rigid
fixes can be used in tandem with :doc:`fix nve <fix_nve>`, :doc:`fix nvt
<fix_nh>`, :doc:`fix npt <fix_nh>`, and :doc:`fix nph <fix_nh>`.
If your simulation is a hybrid model with a mixture of rigid bodies
and non-rigid particles (e.g. solvent) there are several ways these
rigid fixes can be used in tandem with :doc:`fix nve <fix_nve>`,
:doc:`fix nvt <fix_nh>`, :doc:`fix npt <fix_nh>`, and :doc:`fix nph
<fix_nh>`.
If you wish to perform NVE dynamics (no thermostatting or
barostatting), use one of 4 NVE rigid styles to integrate the rigid
@ -741,14 +754,14 @@ particles.
If you wish to perform NVT dynamics (thermostatting, but no
barostatting), you can use one of the 2 NVT rigid styles for the rigid
bodies, and any thermostatting fix for the non-rigid particles
(:doc:`fix nvt <fix_nh>`, :doc:`fix langevin <fix_langevin>`, :doc:`fix
temp/berendsen <fix_temp_berendsen>`). You can also use one of the 4
NVE rigid styles for the rigid bodies and thermostat them using
:doc:`fix langevin <fix_langevin>` on the group that contains all the
particles in the rigid bodies. The net force added by :doc:`fix
langevin <fix_langevin>` to each rigid body effectively thermostats its
translational center-of-mass motion. Not sure how well it does at
thermostatting its rotational motion.
(:doc:`fix nvt <fix_nh>`, :doc:`fix langevin <fix_langevin>`,
:doc:`fix temp/berendsen <fix_temp_berendsen>`). You can also use one
of the 4 NVE rigid styles for the rigid bodies and thermostat them
using :doc:`fix langevin <fix_langevin>` on the group that contains
all the particles in the rigid bodies. The net force added by
:doc:`fix langevin <fix_langevin>` to each rigid body effectively
thermostats its translational center-of-mass motion. Not sure how
well it does at thermostatting its rotational motion.
If you wish to perform NPT or NPH dynamics (barostatting), you cannot
use both :doc:`fix npt <fix_nh>` and the NPT or NPH rigid styles. This
@ -774,12 +787,12 @@ to the global pressure and the box is scaled the same by any of the
barostatting fixes.
You could even use the second and third options for a non-hybrid
simulation consisting of only rigid bodies, assuming you give :doc:`fix
npt <fix_nh>` an empty group, though it's an odd thing to do. The
barostatting fixes (:doc:`fix npt <fix_nh>` and :doc:`fix press/berensen
<fix_press_berendsen>`) will monitor the pressure and change the box
dimensions, but not time integrate any particles. The integration of
the rigid bodies will be performed by fix rigid/nvt.
simulation consisting of only rigid bodies, assuming you give
:doc:`fix npt <fix_nh>` an empty group, though it's an odd thing to
do. The barostatting fixes (:doc:`fix npt <fix_nh>` and :doc:`fix
press/berensen <fix_press_berendsen>`) will monitor the pressure and
change the box dimensions, but not time integrate any particles. The
integration of the rigid bodies will be performed by fix rigid/nvt.
----------
@ -824,10 +837,10 @@ various :doc:`output commands <Howto_output>`. The scalar value
calculated by these fixes is "intensive". The scalar is the current
temperature of the collection of rigid bodies. This is averaged over
all rigid bodies and their translational and rotational degrees of
freedom. The translational energy of a rigid body is 1/2 m v\^2, where
m = total mass of the body and v = the velocity of its center of mass.
The rotational energy of a rigid body is 1/2 I w\^2, where I = the
moment of inertia tensor of the body and w = its angular velocity.
freedom. The translational energy of a rigid body is 1/2 m v\^2,
where m = total mass of the body and v = the velocity of its center of
mass. The rotational energy of a rigid body is 1/2 I w\^2, where I =
the moment of inertia tensor of the body and w = its angular velocity.
Degrees of freedom constrained by the *force* and *torque* keywords
are removed from this calculation, but only for the *rigid* and
*rigid/nve* fixes.

33
doc/src/fix_sgcmc.rst
View File

@ -15,7 +15,7 @@ Syntax
* every_nsteps = number of MD steps between MC cycles
* swap_fraction = fraction of a full MC cycle carried out at each call (a value of 1.0 will perform as many trial moves as there are atoms)
* temperature = temperature that enters Boltzmann factor in Metropolis criterion (usually the same as MD temperature)
* deltamu = chemical potential difference(s) (`N-1` values must be provided, with `N` being the number of elements)
* deltamu = `N-1` chemical potential differences :math:`\mu_1-\mu_2, \ldots, \mu_1-\mu_N` (`N` is the number of atom types)
* Zero or more keyword/value pairs may be appended to fix definition line:
.. parsed-literal::
@ -23,7 +23,7 @@ Syntax
keyword = *variance* or *randseed* or *window_moves* or *window_size*
*variance* kappa conc1 [conc2] ... [concN]
kappa = variance constraint parameter
conc1,conc2,... = target concentration(s) in the range 0.0-1.0 (*N-1* values must be provided, with *N* being the number of elements)
`c_2`, `c_3`,..., `c_N` = `N-1` target concentration fractions
*randseed* N
N = seed for pseudo random number generator
*window_moves* N
@ -90,11 +90,10 @@ the simulation, e.g., to speed up equilibration at low temperatures.
------------
The parameter *deltamu* is used to set the chemical potential difference
in the SGC MC algorithm (see Eq. 16 in :ref:`Sadigh1 <Sadigh1>`). By
convention it is the difference of the chemical potentials of elements
`B`, `C` ..., with respect to element A. When the simulation includes
`N` elements, `N-1` values must be specified.
The parameter *deltamu* is used to set the chemical potential differences
in the SGC MC algorithm (see Eq. 16 in :ref:`Sadigh1 <Sadigh1>`).
The `N-1` differences are defined as :math:`\mu_1-\mu_2, \ldots, \mu_1-\mu_N`,
where `N` is the number of atom types.
------------
@ -104,12 +103,12 @@ the effective average constraint in the parallel VC-SGC MC algorithm
(parameter :math:`\delta\mu_0` in Eq. (20) of :ref:`Sadigh1
<Sadigh1>`). The parameter *kappa* specifies the variance constraint
(see Eqs. (20-21) in :ref:`Sadigh1 <Sadigh1>`).
The parameter *conc* sets the target concentration (parameter
:math:`c_0` in Eqs. (20-21) of :ref:`Sadigh1 <Sadigh1>`). The atomic
concentrations refer to components `B`, `C` ..., with `A` being set
automatically. When the simulation includes `N` elements, `N-1`
concentration values must be specified.
The parameter *conc* sets the `N-1` target atomic concentration
fractions (parameter :math:`c_0` in Eqs. (20-21) of :ref:`Sadigh1 <Sadigh1>`)
:math:`0 \le c_2, \ldots, c_N \le 1`, with
:math:`c_1 = 1 - \Sigma_{i=2}^N c_i`.
When the simulation includes `N` atom types (elements),
`N-1` concentration values must be specified.
------------
@ -143,10 +142,12 @@ components of the vector represent the following quantities:
* 1 = The absolute number of accepted trial swaps during the last MC step
* 2 = The absolute number of rejected trial swaps during the last MC step
* 3 = The current global concentration of species *A* (= number of atoms of type 1 / total number of atoms)
* 4 = The current global concentration of species *B* (= number of atoms of type 2 / total number of atoms)
* 3 = Current global concentration `c_1` (= number of atoms of type 1 / total number of atoms)
* 4 = Current global concentration `c_2` (= number of atoms of type 2 / total number of atoms)
* ...
* N+2: The current global concentration of species *X* (= number of atoms of type *N* / total number of atoms)
* N+2: Current global concentration `c_N` (= number of atoms of type *N* / total number of atoms)
The vector values calculated by this fix are "intensive".
Restrictions
""""""""""""

103
doc/src/fix_ttm.rst
View File

@ -96,11 +96,11 @@ each processor, which is acceptable when the overall grid is reasonably
small. For larger grids you should use fix *ttm/grid* instead.
Fix *ttm/mod* adds options to account for external heat sources (e.g. at
a surface) and for specifying parameters that allow the electronic
heat capacity to depend strongly on electronic temperature. It is
more expensive computationally than fix *ttm* because it treats the
thermal diffusion equation as non-linear. More details on fix *ttm/mod*
are given below.
a surface) and for specifying parameters that allow the electronic heat
capacity to depend strongly on electronic temperature. It is more
expensive computationally than fix *ttm* because it treats the thermal
diffusion equation as non-linear. More details on fix *ttm/mod* are
given below.
Heat transfer between the electronic and atomic subsystems is carried
out via an inhomogeneous Langevin thermostat. Only atoms in the fix
@ -136,23 +136,23 @@ transfer between the subsystems:
\bigtriangledown (\kappa_e \bigtriangledown T_e) -
g_p (T_e - T_a) + g_s T_a'
where C_e is the specific heat, rho_e is the density, kappa_e is the
thermal conductivity, T is temperature, the "e" and "a" subscripts
represent electronic and atomic subsystems respectively, g_p is the
coupling constant for the electron-ion interaction, and g_s is the
electron stopping coupling parameter. C_e, rho_e, and kappa_e are
specified as parameters to the fix. The other quantities are derived.
The form of the heat diffusion equation used here is almost the same
as that in equation 6 of :ref:`(Duffy) <Duffy>`, with the exception that the
electronic density is explicitly represented, rather than being part
of the specific heat parameter.
where :math:`C_e` is the specific heat, :math:`\rho_e` is the density,
:math:`\kappa_e` is the thermal conductivity, *T* is temperature, the
"e" and "a" subscripts represent electronic and atomic subsystems
respectively, :math:`g_p` is the coupling constant for the electron-ion
interaction, and :math:`g_s` is the electron stopping coupling
parameter. :math:`C_e`, :math:`\rho_e`, and :math:`\kappa_e` are
specified as parameters to the fix *ttm* or *ttm/grid*. The other
quantities are derived. The form of the heat diffusion equation used
here is almost the same as that in equation 6 of :ref:`(Duffy) <Duffy>`,
with the exception that the electronic density is explicitly
represented, rather than being part of the specific heat parameter.
Currently, the TTM fixes assume that none of the user-supplied
parameters will vary with temperature. Note that :ref:`(Duffy)
<Duffy>` used a tanh() functional form for the temperature dependence
of the electronic specific heat, but ignored temperature dependencies
of any of the other parameters. See more discussion below for fix
ttm/mod.
parameters will vary with temperature. Note that :ref:`(Duffy) <Duffy>`
used a tanh() functional form for the temperature dependence of the
electronic specific heat, but ignored temperature dependencies of any of
the other parameters. See more discussion below for fix *ttm/mod*.
.. note::
@ -265,27 +265,27 @@ heat sources (e.g. laser heating in ablation simulations):
\bigtriangledown (\kappa_e \bigtriangledown T_e) -
g_p (T_e - T_a) + g_s T_a' + \theta (x-x_{surface})I_0 \exp(-x/l_{skin})
where theta is the Heaviside step function, I_0 is the (absorbed)
laser pulse intensity for ablation simulations, l_skin is the depth
of skin-layer, and all other designations have the same meaning as in
the former equation. The duration of the pulse is set by the parameter
*tau* in the *init_file*.
where :math:`\theta` is the Heaviside step function, :math:`I_0` is the
(absorbed) laser pulse intensity for ablation simulations,
:math:`l_{skin}` is the depth of the skin-layer, and all other
designations have the same meaning as in the former equation. The
duration of the pulse is set by the parameter *tau* in the *init_file*.
Fix ttm/mod also allows users to specify the dependencies of C_e and
kappa_e on the electronic temperature. The specific heat is expressed
as
Fix *ttm/mod* also allows users to specify the dependencies of
:math:`C_e` and :math:`\kappa_e` on the electronic temperature. The
specific heat is expressed as
.. math::
C_e = C_0 + (a_0 + a_1 X + a_2 X^2 + a_3 X^3 + a_4 X^4) \exp (-(AX)^2)
where *X* = T_e/1000, and the thermal conductivity is defined as
kappa_e = D_e\*rho_e\*C_e, where D_e is the thermal diffusion
coefficient.
where :math:`X = \frac{T_e}{1000}`, and the thermal conductivity is
defined as :math:`\kappa_e = D_e \cdot rho_e \cdot C_e`, where
:math:`D_e` is the thermal diffusion coefficient.
Electronic pressure effects are included in the TTM model to account
for the blast force acting on ions because of electronic pressure
gradient (see :ref:`(Chen) <Chen>`, :ref:`(Norman) <Norman>`). The total force
Electronic pressure effects are included in the TTM model to account for
the blast force acting on ions because of electronic pressure gradient
(see :ref:`(Chen) <Chen>`, :ref:`(Norman) <Norman>`). The total force
acting on an ion is:
.. math::
@ -293,25 +293,26 @@ acting on an ion is:
{\vec F}_i = - \partial U / \partial {\vec r}_i + {\vec
F}_{langevin} - \nabla P_e/n_{ion}
where F_langevin is a force from Langevin thermostat simulating
electron-phonon coupling, and nabla P_e/n_ion is the electron blast
force.
where :math:`F_{langevin}` is a force from Langevin thermostat
simulating electron-phonon coupling, and :math:`\nabla P_e/n_{ion}` is
the electron blast force.
The electronic pressure is taken to be P_e = B\*rho_e\*C_e\*T_e
The electronic pressure is taken to be :math:`P_e = B \cdot rho_e \cdot
C_e \cdot T_e`
The current fix ttm/mod implementation allows TTM simulations with a
The current fix *ttm/mod* implementation allows TTM simulations with a
vacuum. The vacuum region is defined as the grid cells with zero
electronic temperature. The numerical scheme does not allow energy
exchange with such cells. Since the material can expand to previously
unoccupied region in some simulations, the vacuum border can be
allowed to move. It is controlled by the *surface_movement* parameter
in the *init_file*. If it is set to 1, then "vacuum" cells can be
changed to "electron-filled" cells with the temperature *T_e_min* if
atoms move into them (currently only implemented for the case of
1-dimensional motion of flat surface normal to the X axis). The
initial borders of vacuum can be set in the *init_file* via *lsurface*
and *rsurface* parameters. In this case, electronic pressure gradient
is calculated as
unoccupied region in some simulations, the vacuum border can be allowed
to move. It is controlled by the *surface_movement* parameter in the
*init_file*. If it is set to 1, then "vacuum" cells can be changed to
"electron-filled" cells with the temperature *T_e_min* if atoms move
into them (currently only implemented for the case of 1-dimensional
motion of a flat surface normal to the X axis). The initial locations of
the interfaces of the electron density to the vacuum can be set in the
*init_file* via *lsurface* and *rsurface* parameters. In this case,
electronic pressure gradient is calculated as
.. math::
@ -319,10 +320,10 @@ is calculated as
\frac{x}{x+\lambda}\frac{(C_e{}T_e)_{x+\Delta
x}-(C_e{}T_e)_{x}}{\Delta x} \right]
where lambda is the electron mean free path (see :ref:`(Norman) <Norman>`,
:ref:`(Pisarev) <Pisarev>`)
where :math:`\lambda` is the electron mean free path (see :ref:`(Norman)
<Norman>`, :ref:`(Pisarev) <Pisarev>`)
The fix ttm/mod parameter file *init_file* has the following syntax.
The fix *ttm/mod* parameter file *init_file* has the following syntax.
Every line with an odd number is considered as a comment and
ignored. The lines with the even numbers are treated as follows:

2
doc/src/fix_wall_flow.rst
View File

@ -40,7 +40,7 @@ Examples
Description
"""""""""""
.. versionadded:: TBD
.. versionadded:: 17Apr2024
This fix implements flow boundary conditions (FBC) introduced in
:ref:`(Pavlov1) <fbc-Pavlov1>` and :ref:`(Pavlov2) <fbc-Pavlov2>`.

12
doc/src/fix_wall_gran.rst
View File

@ -115,6 +115,18 @@ friction and twisting friction supported by the :doc:`pair_style granular <pair_
supported for walls. These are discussed in greater detail on the doc
page for :doc:`pair_style granular <pair_granular>`.
.. note::
When *fstyle* *granular* is specified, the associated *fstyle_params* are taken as
those for a wall/particle interaction. For example, for the *hertz/material* normal
contact model with :math:`E = 960` and :math:`\nu = 0.2`, the effective Young's
modulus for a wall/particle interaction is computed as
:math:`E_{eff} = \frac{960}{2(1-0.2^2)} = 500`. Any pair coefficients defined by
:doc:`pair_style granular <pair_granular>` are not taken into consideration. To
model different wall/particle interactions for particles of different material
types, the user may define multiple fix wall/gran commands operating on separate
groups (e.g. based on particle type) each with a different wall/particle effective
Young's modulus.
Note that you can choose a different force styles and/or different
values for the wall/particle coefficients than for particle/particle
interactions. E.g. if you wish to model the wall as a different

7
doc/src/fix_widom.rst
View File

@ -14,7 +14,7 @@ Syntax
* widom = style name of this fix command
* N = invoke this fix every N steps
* M = number of Widom insertions to attempt every N steps
* type = atom type for inserted atoms (must be 0 if mol keyword used)
* type = atom type (1-Ntypes or type label) for inserted atoms (must be 0 if mol keyword used)
* seed = random # seed (positive integer)
* T = temperature of the system (temperature units)
* zero or more keyword/value pairs may be appended to args
@ -38,6 +38,9 @@ Examples
fix 2 gas widom 1 50000 1 19494 2.0
fix 3 water widom 1000 100 0 29494 300.0 mol h2omol full_energy
labelmap atom 1 Li
fix 2 ion widom 1 50000 Li 19494 2.0
Description
"""""""""""
@ -179,7 +182,7 @@ the following global cumulative quantities:
* 2 = average difference in potential energy on each timestep
* 3 = volume of the insertion region
The vector values calculated by this fix are "extensive".
The vector values calculated by this fix are "intensive".
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during

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