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

Merge branch 'upstream' into regression-tests

Browse Source
This commit is contained in:
Trung Nguyen
2024-01-31 13:48:49 -06:00
parent 829708bd71 52de76d97b
commit b1688d4287
1184 changed files with 34053 additions and 25507 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -30,12 +30,12 @@ jobs:
fetch-depth: 2
- name: Setup Python
uses: actions/setup-python@v4
uses: actions/setup-python@v5
with:
python-version: '3.x'
- name: Initialize CodeQL
uses: github/codeql-action/init@v2
uses: github/codeql-action/init@v3
with:
languages: ${{ matrix.language }}
config-file: ./.github/codeql/${{ matrix.language }}.yml
@ -55,4 +55,4 @@ jobs:
cmake --build . --parallel 2
- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v2
uses: github/codeql-action/analyze@v3

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

@ -24,7 +24,7 @@ jobs:
fetch-depth: 2
- name: Select Python version
uses: actions/setup-python@v4
uses: actions/setup-python@v5
with:
python-version: '3.11'

2
.github/workflows/coverity.yml vendored
View File

@ -25,7 +25,7 @@ jobs:
- name: Cache Coverity
id: cache-coverity
uses: actions/cache@v3
uses: actions/cache@v4
with:
path: ./download/
key: ${{ runner.os }}-download-${{ hashFiles('**/coverity_tool.*') }}

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

@ -32,7 +32,7 @@ jobs:
run: mkdir build
- name: Set up ccache
uses: actions/cache@v3
uses: actions/cache@v4
with:
path: ${{ env.CCACHE_DIR }}
key: macos-ccache-${{ github.sha }}

72
cmake/CMakeLists.txt
View File

@ -971,33 +971,53 @@ if(PKG_KOKKOS)
endif()
endif()
if(PKG_KSPACE)
message(STATUS "<<< FFT settings >>>
-- Primary FFT lib: ${FFT}")
if(FFT_SINGLE)
message(STATUS "Using single precision FFTs")
else()
message(STATUS "Using double precision FFTs")
endif()
if(FFT_FFTW_THREADS OR FFT_MKL_THREADS)
message(STATUS "Using threaded FFTs")
else()
message(STATUS "Using non-threaded FFTs")
endif()
if(PKG_KOKKOS)
if(Kokkos_ENABLE_CUDA)
if(FFT STREQUAL "KISS")
message(STATUS "Kokkos FFT: KISS")
else()
message(STATUS "Kokkos FFT: cuFFT")
endif()
elseif(Kokkos_ENABLE_HIP)
if(FFT STREQUAL "KISS")
message(STATUS "Kokkos FFT: KISS")
else()
message(STATUS "Kokkos FFT: hipFFT")
endif()
if (LMP_HEFFTE)
message(STATUS "<<< FFT settings >>>
-- Primary FFT lib: heFFTe")
if (HEFFTE_BACKEND)
message(STATUS "heFFTe backend: ${HEFFTE_BACKEND}")
else()
message(STATUS "Kokkos FFT: ${FFT}")
message(STATUS "heFFTe backend: stock (builtin FFT implementation, tested for corrected but not optimized for production)")
endif()
if(FFT_SINGLE)
message(STATUS "Using single precision FFTs")
else()
message(STATUS "Using double precision FFTs")
endif()
else()
message(STATUS "<<< FFT settings >>>
-- Primary FFT lib: ${FFT}")
if(FFT_SINGLE)
message(STATUS "Using single precision FFTs")
else()
message(STATUS "Using double precision FFTs")
endif()
if(FFT_FFTW_THREADS OR FFT_MKL_THREADS)
message(STATUS "Using threaded FFTs")
else()
message(STATUS "Using non-threaded FFTs")
endif()
if (FFT_HEFFTE)
message(STATUS "Using distributed algorithms from heFTTe")
else()
message(STATUS "Using builtin distributed algorithms")
endif()
if(PKG_KOKKOS)
if(Kokkos_ENABLE_CUDA)
if(FFT STREQUAL "KISS")
message(STATUS "Kokkos FFT: KISS")
else()
message(STATUS "Kokkos FFT: cuFFT")
endif()
elseif(Kokkos_ENABLE_HIP)
if(FFT STREQUAL "KISS")
message(STATUS "Kokkos FFT: KISS")
else()
message(STATUS "Kokkos FFT: hipFFT")
endif()
else()
message(STATUS "Kokkos FFT: ${FFT}")
endif()
endif()
endif()
endif()

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

@ -1,3 +1,10 @@
# Silence CMake warnings about FindCUDA being obsolete.
# We may need to eventually rewrite this section to use enable_language(CUDA)
if(POLICY CMP0146)
cmake_policy(SET CMP0146 OLD)
endif()
set(GPU_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/GPU)
set(GPU_SOURCES ${GPU_SOURCES_DIR}/gpu_extra.h
${GPU_SOURCES_DIR}/fix_gpu.h
@ -151,10 +158,10 @@ if(GPU_API STREQUAL "CUDA")
endif()
cuda_compile_fatbin(GPU_GEN_OBJS ${GPU_LIB_CU} OPTIONS ${CUDA_REQUEST_PIC}
-DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -DNV_KERNEL -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES})
-DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -allow-unsupported-compiler -DNV_KERNEL -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES})
cuda_compile(GPU_OBJS ${GPU_LIB_CUDPP_CU} OPTIONS ${CUDA_REQUEST_PIC}
-DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES})
-DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -allow-unsupported-compiler -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES})
foreach(CU_OBJ ${GPU_GEN_OBJS})
get_filename_component(CU_NAME ${CU_OBJ} NAME_WE)

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

@ -16,11 +16,6 @@ endif()
if(Kokkos_ENABLE_OPENMP)
if(NOT BUILD_OMP)
message(FATAL_ERROR "Must enable BUILD_OMP with Kokkos_ENABLE_OPENMP")
else()
# NVHPC/(AMD)Clang does not seem to provide a detectable OpenMP version, but is far beyond version 3.1
if((OpenMP_CXX_VERSION VERSION_LESS 3.1) AND NOT ((CMAKE_CXX_COMPILER_ID STREQUAL "NVHPC") OR (CMAKE_CXX_COMPILER_ID STREQUAL "Clang")))
message(FATAL_ERROR "Compiler must support OpenMP 3.1 or later with Kokkos_ENABLE_OPENMP")
endif()
endif()
endif()
########################################################################

36
cmake/Modules/Packages/KSPACE.cmake
View File

@ -46,6 +46,42 @@ else()
target_compile_definitions(lammps PRIVATE -DFFT_KISS)
endif()
option(FFT_USE_HEFFTE "Use heFFTe as the distributed FFT engine, overrides the FFT option." OFF)
if(FFT_USE_HEFFTE)
# if FFT_HEFFTE is enabled, switch the builtin FFT engine with Heffte
set(FFT_HEFFTE_BACKEND_VALUES FFTW MKL)
set(FFT_HEFFTE_BACKEND "" CACHE STRING "Select heFFTe backend, e.g., FFTW or MKL")
set_property(CACHE FFT_HEFFTE_BACKEND PROPERTY STRINGS ${FFT_HEFFTE_BACKEND_VALUES})
if(FFT_HEFFTE_BACKEND STREQUAL "FFTW") # respect the backend choice, FFTW or MKL
set(HEFFTE_COMPONENTS "FFTW")
set(Heffte_ENABLE_FFTW "ON" CACHE BOOL "Enables FFTW backend for heFFTe")
elseif(FFT_HEFFTE_BACKEND STREQUAL "MKL")
set(HEFFTE_COMPONENTS "MKL")
set(Heffte_ENABLE_MKL "ON" CACHE BOOL "Enables MKL backend for heFFTe")
else()
message(WARNING "FFT_HEFFTE_BACKEND not selected, defaulting to the builtin 'stock' backend, which is intended for testing and is not optimized for production runs")
endif()
find_package(Heffte 2.4.0 QUIET COMPONENTS ${HEFFTE_COMPONENTS})
if (NOT Heffte_FOUND) # download and build
include(FetchContent)
FetchContent_Declare(HEFFTE_PROJECT # using v2.4.0
URL "https://github.com/icl-utk-edu/heffte/archive/refs/tags/v2.4.0.tar.gz"
URL_HASH SHA256=02310fb4f9688df02f7181667e61c3adb7e38baf79611d80919d47452ff7881d
)
FetchContent_Populate(HEFFTE_PROJECT)
add_subdirectory(${heffte_project_SOURCE_DIR} ${heffte_project_BINARY_DIR})
set_target_properties(lmp PROPERTIES INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
set_target_properties(lammps PROPERTIES INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
add_library(Heffte::Heffte INTERFACE IMPORTED GLOBAL)
target_link_libraries(Heffte::Heffte INTERFACE Heffte)
endif()
target_compile_definitions(lammps PRIVATE -DFFT_HEFFTE "-DFFT_HEFFTE_${FFT_HEFFTE_BACKEND}")
target_link_libraries(lammps PRIVATE Heffte::Heffte)
endif()
set(FFT_PACK "array" CACHE STRING "Optimization for FFT")
set(FFT_PACK_VALUES array pointer memcpy)
set_property(CACHE FFT_PACK PROPERTY STRINGS ${FFT_PACK_VALUES})

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

@ -8,8 +8,8 @@ option(DOWNLOAD_MDI "Download and compile the MDI library instead of using an al
if(DOWNLOAD_MDI)
message(STATUS "MDI download requested - we will build our own")
set(MDI_URL "https://github.com/MolSSI-MDI/MDI_Library/archive/v1.4.16.tar.gz" CACHE STRING "URL for MDI tarball")
set(MDI_MD5 "407db44e2d79447ab5c1233af1965f65" CACHE STRING "MD5 checksum for MDI tarball")
set(MDI_URL "https://github.com/MolSSI-MDI/MDI_Library/archive/v1.4.26.tar.gz" CACHE STRING "URL for MDI tarball")
set(MDI_MD5 "3124bb85259471e2a53a891f04bf697a" CACHE STRING "MD5 checksum for MDI tarball")
mark_as_advanced(MDI_URL)
mark_as_advanced(MDI_MD5)
GetFallbackURL(MDI_URL MDI_FALLBACK)

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

@ -1,33 +1,40 @@
set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.10.04.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.11.25.fix.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
set(PACELIB_MD5 "70ff79f4e59af175e55d24f3243ad1ff" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
set(PACELIB_MD5 "b45de9a633f42ed65422567e3ce56f9f" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
mark_as_advanced(PACELIB_URL)
mark_as_advanced(PACELIB_MD5)
GetFallbackURL(PACELIB_URL PACELIB_FALLBACK)
# download library sources to build folder
if(EXISTS ${CMAKE_BINARY_DIR}/libpace.tar.gz)
file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
endif()
if(NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}")
message(STATUS "Downloading ${PACELIB_URL}")
file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz STATUS DL_STATUS SHOW_PROGRESS)
file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
if((NOT DL_STATUS EQUAL 0) OR (NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}"))
message(WARNING "Download from primary URL ${PACELIB_URL} failed\nTrying fallback URL ${PACELIB_FALLBACK}")
file(DOWNLOAD ${PACELIB_FALLBACK} ${CMAKE_BINARY_DIR}/libpace.tar.gz EXPECTED_HASH MD5=${PACELIB_MD5} SHOW_PROGRESS)
endif()
# LOCAL_ML-PACE points to top-level dir with local lammps-user-pace repo,
# to make it easier to check local build without going through the public github releases
if(LOCAL_ML-PACE)
set(lib-pace "${LOCAL_ML-PACE}")
else()
message(STATUS "Using already downloaded archive ${CMAKE_BINARY_DIR}/libpace.tar.gz")
endif()
# download library sources to build folder
if(EXISTS ${CMAKE_BINARY_DIR}/libpace.tar.gz)
file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
endif()
if(NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}")
message(STATUS "Downloading ${PACELIB_URL}")
file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz STATUS DL_STATUS SHOW_PROGRESS)
file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
if((NOT DL_STATUS EQUAL 0) OR (NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}"))
message(WARNING "Download from primary URL ${PACELIB_URL} failed\nTrying fallback URL ${PACELIB_FALLBACK}")
file(DOWNLOAD ${PACELIB_FALLBACK} ${CMAKE_BINARY_DIR}/libpace.tar.gz EXPECTED_HASH MD5=${PACELIB_MD5} SHOW_PROGRESS)
endif()
else()
message(STATUS "Using already downloaded archive ${CMAKE_BINARY_DIR}/libpace.tar.gz")
endif()
# uncompress downloaded sources
execute_process(
COMMAND ${CMAKE_COMMAND} -E remove_directory lammps-user-pace*
COMMAND ${CMAKE_COMMAND} -E tar xzf libpace.tar.gz
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
)
get_newest_file(${CMAKE_BINARY_DIR}/lammps-user-pace-* lib-pace)
# uncompress downloaded sources
execute_process(
COMMAND ${CMAKE_COMMAND} -E remove_directory lammps-user-pace*
COMMAND ${CMAKE_COMMAND} -E tar xzf libpace.tar.gz
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
)
get_newest_file(${CMAKE_BINARY_DIR}/lammps-user-pace-* lib-pace)
endif()
add_subdirectory(${lib-pace} build-pace)
set_target_properties(pace PROPERTIES CXX_EXTENSIONS ON OUTPUT_NAME lammps_pace${LAMMPS_MACHINE})

11
cmake/presets/gpu-cuda.cmake Normal file
View File

@ -0,0 +1,11 @@
# preset that enables GPU and selects CUDA API
set(PKG_GPU ON CACHE BOOL "Build GPU package" FORCE)
set(GPU_API "cuda" CACHE STRING "APU used by GPU package" FORCE)
set(GPU_PREC "mixed" CACHE STRING "" FORCE)
set(CUDA_NVCC_FLAGS "-allow-unsupported-compiler" CACHE STRING "" FORCE)
set(CUDA_NVCC_FLAGS_DEBUG "-allow-unsupported-compiler" CACHE STRING "" FORCE)
set(CUDA_NVCC_FLAGS_MINSIZEREL "-allow-unsupported-compiler" CACHE STRING "" FORCE)
set(CUDA_NVCC_FLAGS_RELWITHDEBINFO "-allow-unsupported-compiler" CACHE STRING "" FORCE)
set(CUDA_NVCC_FLAGS_RELEASE "-allow-unsupported-compiler" CACHE STRING "" FORCE)

6
cmake/presets/oneapi.cmake
View File

@ -18,11 +18,11 @@ set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
unset(HAVE_OMP_H_INCLUDE CACHE)
set(OpenMP_C "icx" CACHE STRING "" FORCE)
set(OpenMP_C_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
set(OpenMP_C_FLAGS "-qopenmp;-qopenmp-simd" CACHE STRING "" FORCE)
set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
set(OpenMP_CXX "icpx" CACHE STRING "" FORCE)
set(OpenMP_CXX_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
set(OpenMP_CXX_FLAGS "-qopenmp;-qopenmp-simd" CACHE STRING "" FORCE)
set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
set(OpenMP_Fortran_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
set(OpenMP_Fortran_FLAGS "-qopenmp;-qopenmp-simd" CACHE STRING "" FORCE)
set(OpenMP_omp_LIBRARY "libiomp5.so" CACHE PATH "" FORCE)

3
doc/Makefile
View File

@ -100,6 +100,7 @@ html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst ;\
env LC_ALL=C grep -n ' `[^`]\+<[a-z][^`]\+`[^_]' $(RSTDIR)/*.rst ;\
env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst ;\
env LC_ALL=C grep -n '\(ref\|doc\)`[^`]' $(RSTDIR)/*.rst ;\
$(PYTHON) $(BUILDDIR)/utils/check-styles.py -s ../src -d src ;\
echo "############################################" ;\
deactivate ;\
@ -182,6 +183,7 @@ pdf: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst ;\
env LC_ALL=C grep -n ' `[^`]\+<[a-z][^`]\+`[^_]' $(RSTDIR)/*.rst ;\
env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst ;\
env LC_ALL=C grep -n '\(ref\|doc\)`[^`]' $(RSTDIR)/*.rst ;\
$(PYTHON) utils/check-styles.py -s ../src -d src ;\
echo "############################################" ;\
deactivate ;\
@ -231,6 +233,7 @@ role_check :
@( env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst && exit 1 || : )
@( env LC_ALL=C grep -n ' `[^`]\+<[a-z][^`]\+`[^_]' $(RSTDIR)/*.rst && exit 1 || : )
@( env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst && exit 1 || : )
@( env LC_ALL=C grep -n '\(ref\|doc\)`[^`]' $(RSTDIR)/*.rst && exit 1 || : )
link_check : $(VENV) html
@(\

8
doc/github-development-workflow.md
View File

@ -36,10 +36,10 @@ requests.
MUST be submitted as a pull request to GitHub. All changes to the
"develop" branch must be made exclusively through merging pull requests.
The "release" and "stable" branches, respectively, are only to be
updated upon feature or stable releases based on the associated
tags. Updates to the stable release in between stable releases
updated upon "feature releases" or "stable releases" based on the
associated tags. Updates to the stable release in between stable releases
(for example, back-ported bug fixes) are first merged into the "maintenance"
branch and then into the "stable" branch as update releases.
branch and then into the "stable" branch as "stable update releases".
Pull requests may also be submitted to (long-running) feature branches
created by LAMMPS developers inside the LAMMPS project, if needed. Those
@ -131,7 +131,7 @@ testing -- that the code in the branch "develop" does not get easily
broken. These tests are run after every update to a pull request. More
extensive and time-consuming tests (including regression testing) are
performed after code is merged to the "develop" branch. There are feature
releases of LAMMPS made about every 4-6 weeks at a point, when the LAMMPS
releases of LAMMPS made about every 4-8 weeks at a point, when the LAMMPS
developers feel, that a sufficient number of changes have been included
and all post-merge testing has been successful. These feature releases are
marked with a `patch_<version date>` tag and the "release" branch

5
doc/graphviz/Makefile
View File

@ -16,8 +16,11 @@ clean:
rm -f $(IMGSVG) $(IMGPDF) $(IMGPNG) *~
ifeq ($(HAS_DOT),YES)
$(IMGDIR)/%.png: %.dot
$(IMGDIR)/lammps-classes.png : lammps-classes.dot
dot -Tpng -Kneato -o $@ $<
$(IMGDIR)/%.png: %.dot
dot -Tpng -Kdot -o $@ $<
endif
ifeq ($(HAS_DOT),NO)

34
doc/graphviz/lammps-releases.dot Normal file
View File

@ -0,0 +1,34 @@
// LAMMPS branches and releases
digraph releases {
rankdir="LR";
github [shape="box" label="Pull Requests\non GitHub" height=0.75];
github -> develop [label="Merge commits"];
{
rank = "same";
work [shape="none" label="Development branches:"]
develop [label="'develop' branch" height=0.75];
maintenance [label="'maintenance' branch" height=0.75];
};
{
rank = "same";
upload [shape="none" label="Release branches:"]
release [label="'release' branch" height=0.75];
stable [label="'stable' branch" height=0.75];
};
develop -> release [label="Feature release\n(every 4-8 weeks)"];
release -> stable [label="Stable release\n(once per year)"];
stable -> maintenance [label="Reset on stable release" style="setlinewidth(2)"];
develop -> maintenance [label="Backports of bugfixes" style="dashed"];
maintenance -> stable [label="Updates to stable release"];
{
rank = "same";
tag [shape="none" label="Applied tags:"];
patchtag [shape="box" label="patch_<date>"];
stabletag [shape="box" label="stable_<date>"];
updatetag [shape="box" label="stable_<date>_update<num>"];
};
release -> patchtag [label="feature release" style="dotted"];
stable -> stabletag [label="stable release" style="dotted"];
stable -> updatetag [label="update release" style="dotted"];
}

3
doc/src/Bibliography.rst
View File

@ -562,6 +562,9 @@ Bibliography
**(Kumar)**
Kumar and Skinner, J. Phys. Chem. B, 112, 8311 (2008)
**(Lafourcade)**
Lafourcade, Maillet, Denoual, Duval, Allera, Goryaeva, and Marinica, `Comp. Mat. Science, 230, 112534 (2023) <https://doi.org/10.1016/j.commatsci.2023.112534>`_
**(Lamoureux and Roux)**
G.\ Lamoureux, B. Roux, J. Chem. Phys 119, 3025 (2003)

43
doc/src/Build_development.rst
View File

@ -255,16 +255,18 @@ A test run is then a a collection multiple individual test runs each
with many comparisons to reference results based on template input
files, individual command settings, relative error margins, and
reference data stored in a YAML format file with ``.yaml``
suffix. Currently the programs ``test_pair_style``, ``test_bond_style``, and
``test_angle_style`` are implemented. They will compare forces, energies and
(global) stress for all atoms after a ``run 0`` calculation and after a
few steps of MD with :doc:`fix nve <fix_nve>`, each in multiple variants
with different settings and also for multiple accelerated styles. If a
prerequisite style or package is missing, the individual tests are
skipped. All tests will be executed on a single MPI process, so using
the CMake option ``-D BUILD_MPI=off`` can significantly speed up testing,
since this will skip the MPI initialization for each test run.
Below is an example command and output:
suffix. Currently the programs ``test_pair_style``, ``test_bond_style``,
``test_angle_style``, ``test_dihedral_style``, and
``test_improper_style`` are implemented. They will compare forces,
energies and (global) stress for all atoms after a ``run 0`` calculation
and after a few steps of MD with :doc:`fix nve <fix_nve>`, each in
multiple variants with different settings and also for multiple
accelerated styles. If a prerequisite style or package is missing, the
individual tests are skipped. All force style tests will be executed on
a single MPI process, so using the CMake option ``-D BUILD_MPI=off`` can
significantly speed up testing, since this will skip the MPI
initialization for each test run. Below is an example command and
output:
.. code-block:: console
@ -416,15 +418,16 @@ When compiling LAMMPS with enabled tests, most test executables will
need to be linked against the LAMMPS library. Since this can be a very
large library with many C++ objects when many packages are enabled, link
times can become very long on machines that use the GNU BFD linker (e.g.
Linux systems). Alternatives like the ``lld`` linker of the LLVM project
or the ``gold`` linker available with GNU binutils can speed up this step
substantially. CMake will by default test if any of the two can be
enabled and use it when ``ENABLE_TESTING`` is active. It can also be
selected manually through the ``CMAKE_CUSTOM_LINKER`` CMake variable.
Allowed values are ``lld``, ``gold``, ``bfd``, or ``default``. The
``default`` option will use the system default linker otherwise, the
linker is chosen explicitly. This option is only available for the
GNU or Clang C++ compiler.
Linux systems). Alternatives like the ``mold`` linker, the ``lld``
linker of the LLVM project, or the ``gold`` linker available with GNU
binutils can speed up this step substantially (in this order). CMake
will by default test if any of the three can be enabled and use it when
``ENABLE_TESTING`` is active. It can also be selected manually through
the ``CMAKE_CUSTOM_LINKER`` CMake variable. Allowed values are
``mold``, ``lld``, ``gold``, ``bfd``, or ``default``. The ``default``
option will use the system default linker otherwise, the linker is
chosen explicitly. This option is only available for the GNU or Clang
C++ compilers.
Tests for other components and utility functions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -518,6 +521,8 @@ The following options are available.
make fix-errordocs # remove error docs in header files
make check-permissions # search for files with permissions issues
make fix-permissions # correct permissions issues in files
make check-docs # search for several issues in the manual
make check-version # list files with pending release version tags
make check # run all check targets from above
These should help to make source and documentation files conforming

51
doc/src/Build_settings.rst
View File

@ -44,6 +44,14 @@ require use of an FFT library to compute 1d FFTs. The KISS FFT
library is included with LAMMPS, but other libraries can be faster.
LAMMPS can use them if they are available on your system.
.. versionadded:: TBD
Alternatively, LAMMPS can use the `heFFTe
<https://icl-utk-edu.github.io/heffte/>`_ library for the MPI
communication algorithms, which comes with many optimizations for
special cases, e.g. leveraging available 2D and 3D FFTs in the back end
libraries and better pipelining for packing and communication.
.. tabs::
.. tab:: CMake build
@ -53,6 +61,7 @@ LAMMPS can use them if they are available on your system.
-D FFT=value # FFTW3 or MKL or KISS, default is FFTW3 if found, else KISS
-D FFT_SINGLE=value # yes or no (default), no = double precision
-D FFT_PACK=value # array (default) or pointer or memcpy
-D FFT_USE_HEFFTE=value # yes or no (default), yes links to heFFTe
.. note::
@ -76,6 +85,16 @@ LAMMPS can use them if they are available on your system.
-D MKL_INCLUDE_DIR=path # ditto for Intel MKL library
-D FFT_MKL_THREADS=on # enable using threaded FFTs with MKL libraries
-D MKL_LIBRARY=path # path to MKL libraries
-D FFT_HEFFTE_BACKEND=value # FFTW or MKL or empty/undefined for the stock heFFTe back end
-D Heffte_ROOT=path # path to an existing heFFTe installation
.. note::
heFFTe comes with a builtin (= stock) back end for FFTs, i.e. a
default internal FFT implementation; however, this stock back
end is intended for testing purposes only and is not optimized
for production runs.
.. tab:: Traditional make
@ -111,6 +130,24 @@ LAMMPS can use them if they are available on your system.
files in its default search path. You must specify ``FFT_LIB``
with the appropriate FFT libraries to include in the link.
Traditional make can also link to heFFTe using an existing installation
.. code-block:: make
include <path-to-heffte-installation>/share/heffte/HeffteMakefile.in
FFT_INC = -DFFT_HEFFTE -DFFT_HEFFTE_FFTW $(heffte_include)
FFT_PATH =
FFT_LIB = $(heffte_link) $(heffte_libs)
The heFFTe install path will contain `HeffteMakefile.in`.
which will define the `heffte_` include variables needed to link to heFFTe from
an external project using traditional make.
The `-DFFT_HEFFTE` is required to switch to using heFFTe, while the optional `-DFFT_HEFFTE_FFTW`
selects the desired heFFTe back end, e.g., `-DFFT_HEFFTE_FFTW` or `-DFFT_HEFFTE_MKL`,
omitting the variable will default to the `stock` back end.
The heFFTe `stock` back end is intended to be used for testing and debugging,
but is not performance optimized for large scale production runs.
The `KISS FFT library <https://github.com/mborgerding/kissfft>`_ is
included in the LAMMPS distribution. It is portable across all
platforms. Depending on the size of the FFTs and the number of
@ -170,6 +207,16 @@ Depending on the machine, the size of the FFT grid, the number of
processors used, one option may be slightly faster. The default is
ARRAY mode.
When using ``-DFFT_HEFFTE`` CMake will first look for an existing
install with hints provided by ``-DHeffte_ROOT``, as recommended by the
CMake standard and note that the name is case sensitive. If CMake cannot
find a heFFTe installation with the correct back end (e.g., FFTW or
MKL), it will attempt to download and build the library automatically.
In this case, LAMMPS CMake will also accept all heFFTe specific
variables listed in the `heFFTe documentation
<https://mkstoyanov.bitbucket.io/heffte/md_doxygen_installation.html>`_
and those variables will be passed into the heFFTe build.
----------
.. _size:
@ -463,8 +510,8 @@ Exception handling when using LAMMPS as a library
LAMMPS errors do not kill the calling code, but throw an exception. In
the C-library interface, the call stack is unwound and control returns
to the caller, e.g. to Python or a code that is coupled to LAMMPS and
the error status can be queried. When using C++ directly, the calling
to the caller, e.g. to Python or a code that is coupled to LAMMPS. The
error status can then be queried. When using C++ directly, the calling
code has to be set up to *catch* exceptions thrown from within LAMMPS.
.. note::

2
doc/src/Commands_bond.rst
View File

@ -124,7 +124,7 @@ OPT.
*
*
* :doc:`charmm (iko) <dihedral_charmm>`
* :doc:`charmmfsw <dihedral_charmm>`
* :doc:`charmmfsw (k) <dihedral_charmm>`
* :doc:`class2 (ko) <dihedral_class2>`
* :doc:`cosine/shift/exp (o) <dihedral_cosine_shift_exp>`
* :doc:`fourier (io) <dihedral_fourier>`

4
doc/src/Commands_compute.rst
View File

@ -100,6 +100,7 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`nbond/atom <compute_nbond_atom>`
* :doc:`omega/chunk <compute_omega_chunk>`
* :doc:`orientorder/atom (k) <compute_orientorder_atom>`
* :doc:`pace <compute_pace>`
* :doc:`pair <compute_pair>`
* :doc:`pair/local <compute_pair_local>`
* :doc:`pe <compute_pe>`
@ -115,12 +116,15 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`property/grid <compute_property_grid>`
* :doc:`property/local <compute_property_local>`
* :doc:`ptm/atom <compute_ptm_atom>`
* :doc:`rattlers/atom <compute_rattlers_atom>`
* :doc:`rdf <compute_rdf>`
* :doc:`reaxff/atom (k) <compute_reaxff_atom>`
* :doc:`reduce <compute_reduce>`
* :doc:`reduce/chunk <compute_reduce_chunk>`
* :doc:`reduce/region <compute_reduce>`
* :doc:`rigid/local <compute_rigid_local>`
* :doc:`saed <compute_saed>`
* :doc:`slcsa/atom <compute_slcsa_atom>`
* :doc:`slice <compute_slice>`
* :doc:`smd/contact/radius <compute_smd_contact_radius>`
* :doc:`smd/damage <compute_smd_damage>`

5
doc/src/Commands_fix.rst
View File

@ -122,6 +122,7 @@ OPT.
* :doc:`mvv/tdpd <fix_mvv_dpd>`
* :doc:`neb <fix_neb>`
* :doc:`neb/spin <fix_neb_spin>`
* :doc:`nonaffine/displacement <fix_nonaffine_displacement>`
* :doc:`nph (ko) <fix_nh>`
* :doc:`nph/asphere (o) <fix_nph_asphere>`
* :doc:`nph/body <fix_nph_body>`
@ -238,10 +239,10 @@ OPT.
* :doc:`store/force <fix_store_force>`
* :doc:`store/state <fix_store_state>`
* :doc:`tdpd/source <fix_dpd_source>`
* :doc:`temp/berendsen <fix_temp_berendsen>`
* :doc:`temp/berendsen (k) <fix_temp_berendsen>`
* :doc:`temp/csld <fix_temp_csvr>`
* :doc:`temp/csvr <fix_temp_csvr>`
* :doc:`temp/rescale <fix_temp_rescale>`
* :doc:`temp/rescale (k) <fix_temp_rescale>`
* :doc:`temp/rescale/eff <fix_temp_rescale_eff>`
* :doc:`tfmc <fix_tfmc>`
* :doc:`tgnpt/drude <fix_tgnh_drude>`

18
doc/src/Commands_pair.rst
View File

@ -87,7 +87,7 @@ OPT.
* :doc:`coul/long/soft (o) <pair_fep_soft>`
* :doc:`coul/msm (o) <pair_coul>`
* :doc:`coul/slater/cut <pair_coul_slater>`
* :doc:`coul/slater/long <pair_coul_slater>`
* :doc:`coul/slater/long (g) <pair_coul_slater>`
* :doc:`coul/shield <pair_coul_shield>`
* :doc:`coul/streitz <pair_coul>`
* :doc:`coul/tt <pair_coul_tt>`
@ -110,7 +110,7 @@ OPT.
* :doc:`eam/he <pair_eam>`
* :doc:`edip (o) <pair_edip>`
* :doc:`edip/multi <pair_edip>`
* :doc:`edpd <pair_mesodpd>`
* :doc:`edpd (g) <pair_mesodpd>`
* :doc:`eff/cut <pair_eff>`
* :doc:`eim (o) <pair_eim>`
* :doc:`exp6/rx (k) <pair_exp6_rx>`
@ -146,7 +146,7 @@ OPT.
* :doc:`lj/charmm/coul/long/soft (o) <pair_fep_soft>`
* :doc:`lj/charmm/coul/msm (o) <pair_charmm>`
* :doc:`lj/charmmfsw/coul/charmmfsh <pair_charmm>`
* :doc:`lj/charmmfsw/coul/long <pair_charmm>`
* :doc:`lj/charmmfsw/coul/long (k) <pair_charmm>`
* :doc:`lj/class2 (gko) <pair_class2>`
* :doc:`lj/class2/coul/cut (ko) <pair_class2>`
* :doc:`lj/class2/coul/cut/soft <pair_fep_soft>`
@ -158,14 +158,14 @@ OPT.
* :doc:`lj/cut (gikot) <pair_lj>`
* :doc:`lj/cut/coul/cut (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/cut/dielectric (o) <pair_dielectric>`
* :doc:`lj/cut/coul/cut/soft (o) <pair_fep_soft>`
* :doc:`lj/cut/coul/cut/soft (go) <pair_fep_soft>`
* :doc:`lj/cut/coul/debye (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/debye/dielectric (o) <pair_dielectric>`
* :doc:`lj/cut/coul/dsf (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/long (gikot) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/long/cs <pair_cs>`
* :doc:`lj/cut/coul/long/dielectric (o) <pair_dielectric>`
* :doc:`lj/cut/coul/long/soft (o) <pair_fep_soft>`
* :doc:`lj/cut/coul/long/soft (go) <pair_fep_soft>`
* :doc:`lj/cut/coul/msm (go) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/msm/dielectric <pair_dielectric>`
* :doc:`lj/cut/coul/wolf (o) <pair_lj_cut_coul>`
@ -202,7 +202,7 @@ OPT.
* :doc:`lubricate/poly (o) <pair_lubricate>`
* :doc:`lubricateU <pair_lubricateU>`
* :doc:`lubricateU/poly <pair_lubricateU>`
* :doc:`mdpd <pair_mesodpd>`
* :doc:`mdpd (g) <pair_mesodpd>`
* :doc:`mdpd/rhosum <pair_mesodpd>`
* :doc:`meam (k) <pair_meam>`
* :doc:`meam/ms (k) <pair_meam>`
@ -268,11 +268,11 @@ OPT.
* :doc:`smtbq <pair_smtbq>`
* :doc:`snap (ik) <pair_snap>`
* :doc:`soft (go) <pair_soft>`
* :doc:`sph/heatconduction <pair_sph_heatconduction>`
* :doc:`sph/heatconduction (g) <pair_sph_heatconduction>`
* :doc:`sph/idealgas <pair_sph_idealgas>`
* :doc:`sph/lj <pair_sph_lj>`
* :doc:`sph/lj (g) <pair_sph_lj>`
* :doc:`sph/rhosum <pair_sph_rhosum>`
* :doc:`sph/taitwater <pair_sph_taitwater>`
* :doc:`sph/taitwater (g) <pair_sph_taitwater>`
* :doc:`sph/taitwater/morris <pair_sph_taitwater_morris>`
* :doc:`spin/dipole/cut <pair_spin_dipole>`
* :doc:`spin/dipole/long <pair_spin_dipole>`

3
doc/src/Developer_platform.rst
View File

@ -70,6 +70,9 @@ File and path functions and global constants
.. doxygenfunction:: is_console
:project: progguide
.. doxygenfunction:: disk_free
:project: progguide
.. doxygenfunction:: path_is_directory
:project: progguide

137
doc/src/Developer_unittest.rst
View File

@ -121,7 +121,7 @@ will be suppressed and only a summary printed, but adding
the '-V' option will then produce output from the tests
above like the following:
.. code-block::
.. code-block:: console
[...]
1: [ RUN ] Tokenizer.empty_string
@ -274,9 +274,7 @@ Tests for using the Fortran module are in the ``unittest/fortran``
folder. Since they are also using the GoogleTest library, they require
to also implement test wrappers in C++ that will call fortran functions
which provide a C function interface through ISO_C_BINDINGS that will in
turn call the functions in the LAMMPS Fortran module. This part of the
unit tests is incomplete since the Fortran module it is based on is
incomplete as well.
turn call the functions in the LAMMPS Fortran module.
Tests for the C++-style library interface
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -397,10 +395,10 @@ compare with the reference and also start from the data file. A final
check will use multi-cutoff r-RESPA (if supported by the pair style) at
a 1:1 split and compare to the Verlet results. These sets of tests are
run with multiple test fixtures for accelerated styles (OPT, OPENMP,
INTEL) and for the latter two with 4 OpenMP threads enabled. For
these tests the relative error (epsilon) is lowered by a common factor
due to the additional numerical noise, but the tests are still comparing
to the same reference data.
INTEL, KOKKOS (OpenMP only)) and for the latter three with 4 OpenMP
threads enabled. For these tests the relative error (epsilon) is lowered
by a common factor due to the additional numerical noise, but the tests
are still comparing to the same reference data.
Additional tests will check whether all listed extract keywords are
supported and have the correct dimensionality and the final set of tests
@ -434,17 +432,19 @@ The ``test_pair_style`` tester is used with 4 categories of test inputs:
pair style is defined, but the computation of the pair style contributions
is disabled.
The ``test_bond_style`` and ``test_angle_style`` are set up in a similar
fashion and share support functions with the pair style tester. The final
group of tests in this section is for fix styles that add/manipulate forces
and velocities, e.g. for time integration, thermostats and more.
The ``test_bond_style``, ``test_angle_style``, ``test_dihedral_style``, and
``test_improper_style`` tester programs are set up in a similar fashion and
share support functions with the pair style tester. The final group of
tests in this section is for fix styles that add/manipulate forces and
velocities, e.g. for time integration, thermostats and more.
Adding a new test is easiest done by copying and modifying an existing test
for a style that is similar to one to be tested. The file name should follow
the naming conventions described above and after copying the file, the first
step is to replace the style names where needed. The coefficient values
do not have to be meaningful, just in a reasonable range for the given system.
It does not matter if some forces are large, for as long as they do not diverge.
Adding a new test is easiest done by copying and modifying an existing YAML
file for a style that is similar to one to be tested. The file name should
follow the naming conventions described above and after copying the file,
the first step is to replace the style names where needed. The coefficient
values do not have to be meaningful, just in a reasonable range for the
given system. It does not matter if some forces are large, for as long as
they do not diverge.
The template input files define a large number of index variables at the top
that can be modified inside the YAML file to control the behavior. For example,
@ -472,7 +472,7 @@ Note that this disables computing the kspace contribution, but still will run
the setup. The "gewald" parameter should be set explicitly to speed up the run.
For styles with long-range electrostatics, typically two tests are added one using
the (slower) analytic approximation of the erfc() function and the other using
the tabulated coulomb, to test both code paths. The reference results in the YAML
the tabulated coulomb, to test both code paths. The reference results in the YAML
files then should be compared manually, if they agree well enough within the limits
of those two approximations.
@ -526,3 +526,102 @@ The ``unittest/tools`` folder contains tests for programs in the
shell, which are implemented as a python scripts using the ``unittest``
Python module and launching the tool commands through the ``subprocess``
Python module.
Troubleshooting failed unit tests
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The are by default no unit tests for newly added features (e.g. pair, fix,
or compute styles) unless your pull request also includes tests for the
added features. If you are modifying some features, you may see failures
for existing tests, if your modifications have some unexpected side effects
or your changes render the existing text invalid. If you are adding an
accelerated version of an existing style, then only tests for INTEL,
KOKKOS (with OpenMP only), OPENMP, and OPT will be run automatically.
Tests for the GPU package are time consuming and thus are only run
*after* a merge, or when a special label, ``gpu_unit_tests`` is added
to the pull request. After the test has started, it is often best to
remove the label since every PR activity will re-trigger the test (that
is a limitation of triggering a test with a label). Support for unit
tests with using KOKKOS with GPU acceleration is currently not supported.
When you see a failed build on GitHub, click on ``Details`` to be taken
to the corresponding LAMMPS Jenkins CI web page. Click on the "Exit"
symbol near the ``Logout`` button on the top right of that page to go to
the "classic view". In the classic view, there is a list of the
individual runs that make up this test run (they are shown but cannot be
inspected in the default view). You can click on any of those.
Clicking on ``Test Result`` will display the list of failed tests. Click
on the "Status" column to sort the tests based on their Failed or Passed
status. Then click on the failed test to expand its output.
For example, the following output snippet shows the failed unit test
.. code-block:: console
[ RUN ] PairStyle.gpu
/home/builder/workspace/dev/pull_requests/ubuntu_gpu/unit_tests/cmake_gpu_opencl_mixed_smallbig_clang_static/unittest/force-styles/test_main.cpp:63: Failure
Expected: (err) <= (epsilon)
Actual: 0.00018957912910606503 vs 0.0001
Google Test trace:
/home/builder/workspace/dev/pull_requests/ubuntu_gpu/unit_tests/cmake_gpu_opencl_mixed_smallbig_clang_static/unittest/force-styles/test_main.cpp:56: EXPECT_FORCES: init_forces (newton off)
/home/builder/workspace/dev/pull_requests/ubuntu_gpu/unit_tests/cmake_gpu_opencl_mixed_smallbig_clang_static/unittest/force-styles/test_main.cpp:64: Failure
Expected: (err) <= (epsilon)
Actual: 0.00022892713393549854 vs 0.0001
The failed assertions provide line numbers in the test source
(e.g. ``test_main.cpp:56``), from which one can understand what
specific assertion failed.
Note that the force style engine runs one of a small number of systems
in a rather off-equilibrium configuration with a few atoms for a few
steps, writes data and restart files, uses :doc:`the clear command
<clear>` to reset LAMMPS, and then runs from those files with different
settings (e.g. newton on/off) and integrators (e.g. verlet vs. respa).
Beyond potential issues/bugs in the source code, the mismatch between
the expected and actual values could be that force arrays are not
properly cleared between multiple run commands or that class members are
not correctly initialized or written to or read from a data or restart
file.
While the epsilon (relative precision) for a single, `IEEE 754 compliant
<https://en.wikipedia.org/wiki/IEEE_754>`_, double precision floating
point operation is at about 2.2e-16, the achievable precision for the
tests is lower due to most numbers being sums over intermediate results
and the non-associativity of floating point math leading to larger
errors. In some cases specific properties of the tested style. As a
rule of thumb, the test epsilon can often be in the range 5.0e-14 to
1.0e-13. But for "noisy" force kernels, e.g. those a larger amount of
arithmetic operations involving `exp()`, `log()` or `sin()` functions,
and also due to the effect of compiler optimization or differences
between compilers or platforms, epsilon may need to be further relaxed,
sometimes epsilon can be relaxed to 1.0e-12. If interpolation or lookup
tables are used, epsilon may need to be set to 1.0e-10 or even higher.
For tests of accelerated styles, the per-test epsilon is multiplied
by empirical factors that take into account the differences in the order
of floating point operations or that some or most intermediate operations
may be done using approximations or with single precision floating point
math.
To rerun the failed unit test individually, change to the ``build`` directory
and run the test with verbose output. For example,
.. code-block:: bash
env TEST_ARGS=-v ctest -R ^MolPairStyle:lj_cut_coul_long -V
``ctest`` with the ``-V`` flag also shows the exact command line
of the test. One can then use ``gdb --args`` to further debug and
catch exceptions with the test command, for example,
.. code-block:: bash
gdb --args /path/to/lammps/build/test_pair_style /path/to/lammps/unittest/force-styles/tests/mol-pair-lj_cut_coul_long.yaml
It is recommended to configure the build with ``-D
BUILD_SHARED_LIBS=on`` and use a custom linker to shorten the build time
during recompilation. Installing `ccache` in your development
environment helps speed up recompilation by caching previous
compilations and detecting when the same compilation is being done
again. Please see :doc:`Build_development` for further details.

66
doc/src/Developer_updating.rst
View File

@ -20,6 +20,7 @@ Available topics in mostly chronological order are:
- `Use ev_init() to initialize variables derived from eflag and vflag`_
- `Use utils::numeric() functions instead of force->numeric()`_
- `Use utils::open_potential() function to open potential files`_
- `Use symbolic Atom and AtomVec constants instead of numerical values`_
- `Simplify customized error messages`_
- `Use of "override" instead of "virtual"`_
- `Simplified and more compact neighbor list requests`_
@ -196,6 +197,71 @@ New:
fp = utils::open_potential(filename, lmp);
Use symbolic Atom and AtomVec constants instead of numerical values
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: 18Sep2020
Properties in LAMMPS that were represented by integer values (0, 1,
2, 3) to indicate settings in the ``Atom`` and ``AtomVec`` classes (or
classes derived from it) (and its derived classes) have been converted
to use scoped enumerators instead.
.. list-table::
:header-rows: 1
:widths: auto
* - Symbolic Constant
- Value
- Symbolic Constant
- Value
* - Atom::GROW
- 0
- Atom::MAP_NONE
- 0
* - Atom::RESTART
- 1
- Atom::MAP_ARRAY
- 1
* - Atom::BORDER
- 2
- Atom::MAP_HASH
- 2
* - Atom::ATOMIC
- 0
- Atom::MAP_YES
- 3
* - Atom::MOLECULAR
- 1
- AtomVec::PER_ATOM
- 0
* - Atom::TEMPLATE
- 2
- AtomVec::PER_TYPE
- 1
Old:
.. code-block:: c++
molecular = 0;
mass_type = 1;
if (atom->molecular == 2)
if (atom->map_style == 2)
atom->add_callback(0);
atom->delete_callback(id,1);
New:
.. code-block:: c++
molecular = Atom::ATOMIC;
mass_type = AtomVec::PER_TYPE;
if (atom->molecular == Atom::TEMPLATE)
if (atom->map_style == Atom::MAP_HASH)
atom->add_callback(Atom::GROW);
atom->delete_callback(id,Atom::RESTART);
Simplify customized error messages
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

45
doc/src/Fortran.rst
View File

@ -315,6 +315,10 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
:ftype extract_variable: function
:f set_variable: :f:subr:`set_variable`
:ftype set_variable: subroutine
:f set_string_variable: :f:subr:`set_set_string_variable`
:ftype set_string_variable: subroutine
:f set_internal_variable: :f:subr:`set_internal_variable`
:ftype set_internal_variable: subroutine
:f gather_atoms: :f:subr:`gather_atoms`
:ftype gather_atoms: subroutine
:f gather_atoms_concat: :f:subr:`gather_atoms_concat`
@ -1398,7 +1402,28 @@ Procedures Bound to the :f:type:`lammps` Derived Type
Set the value of a string-style variable.
.. versionadded:: 3Nov2022
.. deprecated:: TBD
This function assigns a new value from the string *str* to the string-style
variable *name*\ . If *name* does not exist or is not a string-style
variable, an error is generated.
.. warning::
This subroutine is deprecated and :f:subr:`set_string_variable`
should be used instead.
:p character(len=*) name: name of the variable
:p character(len=*) str: new value to assign to the variable
:to: :cpp:func:`lammps_set_variable`
--------
.. f:subroutine:: set_string_variable(name, str)
Set the value of a string-style variable.
.. versionadded:: TBD
This function assigns a new value from the string *str* to the string-style
variable *name*\ . If *name* does not exist or is not a string-style
@ -1406,7 +1431,23 @@ Procedures Bound to the :f:type:`lammps` Derived Type
:p character(len=*) name: name of the variable
:p character(len=*) str: new value to assign to the variable
:to: :cpp:func:`lammps_set_variable`
:to: :cpp:func:`lammps_set_string_variable`
--------
.. f:subroutine:: set_internal_variable(name, val)
Set the value of a internal-style variable.
.. versionadded:: TBD
This function assigns a new value from the floating-point number *val* to
the internal-style variable *name*\ . If *name* does not exist or is not
an internal-style variable, an error is generated.
:p character(len=*) name: name of the variable
:p read(c_double) val: new value to assign to the variable
:to: :cpp:func:`lammps_set_internal_variable`
--------

2
doc/src/Howto_body.rst
View File

@ -335,7 +335,7 @@ faces are listed, so that M = 6 + 3\*N + 1.
The integer line has three values: number of vertices (N), number of
edges (E) and number of faces (F). The floating point line(s) list 6
moments of inertia followed by the coordinates of the N vertices (x1
to zN) as 3N values, followed by 2N vertex indices corresponding to
to zN) as 3N values, followed by 2E vertex indices corresponding to
the end points of the E edges, then 4\*F vertex indices defining F
faces. The last value is the diameter value = the rounded diameter of
the sphere that surrounds each vertex. The diameter value can be

10
doc/src/Howto_github.rst
View File

@ -480,11 +480,11 @@ Some recent changes to the workflow are not captured in this tutorial.
For example, in addition to the *develop* branch, to which all new
features should be submitted, there is also a *release*, a *stable*, and
a *maintenance* branch; the *release* branch is updated from the
*develop* as part of a feature release, and *stable* (together with
*release*) are updated from *develop* when a stable release is made. In
between stable releases, selected bug fixes and infrastructure updates
are back-ported from the *develop* branch to the *maintenance* branch
and occasionally merged to *stable* as an update release.
*develop* branch as part of a "feature release", and *stable* (together
with *release*) are updated from *develop* when a "stable release" is
made. In between stable releases, selected bug fixes and infrastructure
updates are back-ported from the *develop* branch to the *maintenance*
branch and occasionally merged to *stable* as an update release.
Furthermore, the naming of the release tags now follow the pattern
"patch_<Day><Month><Year>" to simplify comparisons between releases.

21
doc/src/Howto_tip4p.rst
View File

@ -193,11 +193,14 @@ file changed):
write_data tip4p-implicit.data nocoeff
Below is the code for a LAMMPS input file using the explicit method and
a TIP4P molecule file. Because of using :doc:`fix rigid/nvt/small
a TIP4P molecule file. Because of using :doc:`fix rigid/small
<fix_rigid>` no bonds need to be defined and thus no extra storage needs
to be reserved for them, but we need to switch to atom style full or use
:doc:`fix property/atom mol <fix_property_atom>` so that fix
rigid/nvt/small can identify rigid bodies by their molecule ID:
to be reserved for them, but we need to either switch to atom style full
or use :doc:`fix property/atom mol <fix_property_atom>` so that fix
rigid/small can identify rigid bodies by their molecule ID. Also a
:doc:`neigh_modify exclude <neigh_modify>` command is added to exclude
computing intramolecular non-bonded interactions, since those are
removed by the rigid fix anyway:
.. code-block:: LAMMPS
@ -216,17 +219,17 @@ rigid/nvt/small can identify rigid bodies by their molecule ID:
pair_coeff 2 2 0.0 1.0
pair_coeff 3 3 0.0 1.0
fix mol all property/atom mol
fix mol all property/atom mol ghost yes
molecule water tip4p.mol
create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
neigh_modify exclude molecule/intra all
timestep 0.5
fix integrate all rigid/nvt/small molecule temp 300.0 300.0 100.0
velocity all create 300.0 5463576
fix integrate all rigid/small molecule langevin 300.0 300.0 100.0 2345634
thermo_style custom step temp press etotal density pe ke
thermo 1000
run 20000
thermo 2000
run 40000
write_data tip4p-explicit.data nocoeff
.. _tip4p_molecule:

14
doc/src/Howto_tip5p.rst
View File

@ -81,11 +81,13 @@ long-range Coulombic solver (e.g. Ewald or PPPM in LAMMPS).
Below is the code for a LAMMPS input file for setting up a simulation of
TIP5P water with a molecule file. Because of using :doc:`fix
rigid/nvt/small <fix_rigid>` no bonds need to be defined and thus no
extra storage needs to be reserved for them, but we need to switch to
rigid/small <fix_rigid>` no bonds need to be defined and thus no extra
storage needs to be reserved for them, but we need to either switch to
atom style full or use :doc:`fix property/atom mol <fix_property_atom>`
so that fix rigid/nvt/small can identify rigid bodies by their molecule
ID:
so that fix rigid/small can identify rigid bodies by their molecule ID.
Also a :doc:`neigh_modify exclude <neigh_modify>` command is added to
exclude computing intramolecular non-bonded interactions, since those
are removed by the rigid fix anyway:
.. code-block:: LAMMPS
@ -107,11 +109,11 @@ ID:
fix mol all property/atom mol
molecule water tip5p.mol
create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
neigh_modify exclude molecule/intra all
timestep 0.5
fix integrate all rigid/nvt/small molecule temp 300.0 300.0 100.0
fix integrate all rigid/small molecule langevin 300.0 300.0 50.0 235664
reset_timestep 0
velocity all create 300.0 5463576
thermo_style custom step temp press etotal density pe ke
thermo 1000

20
doc/src/Install_git.rst
View File

@ -28,16 +28,16 @@ provides `limited support for subversion clients <svn_>`_.
You can follow the LAMMPS development on 4 different git branches:
* **release** : this branch is updated with every patch or feature release;
updates are always "fast-forward" merges from *develop*
* **develop** : this branch follows the ongoing development and
is updated with every merge commit of a pull request
* **stable** : this branch is updated from the *release* branch with
every stable release version and also has selected bug fixes with every
update release when the *maintenance* branch is merged into it
* **maintenance** : this branch collects back-ported bug fixes from the
*develop* branch to the *stable* branch. It is used to update *stable*
for update releases and it synchronized with *stable* at each stable release.
* **develop** : this branch follows the ongoing development and is
updated with every merge commit of a pull request
* **release** : this branch is updated with every "feature release";
updates are always "fast-forward" merges from *develop*
* **maintenance** : this branch collects back-ported bug fixes from the
*develop* branch to the *stable* branch. It is used to update the
*stable* branch for "stable update releases".
* **stable** : this branch is updated from the *release* branch with
every "stable release" version and also has selected bug fixes with
every "update release" when the *maintenance* branch is merged into it
To access the git repositories on your box, use the clone command to
create a local copy of the LAMMPS repository with a command like:

BIN
doc/src/JPG/lammps-classes.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 286 KiB

After

Width:  |  Height:  |  Size: 304 KiB

BIN
doc/src/JPG/lammps-invoke-python.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 36 KiB

After

Width:  |  Height:  |  Size: 38 KiB

BIN
doc/src/JPG/lammps-releases.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 68 KiB

BIN
doc/src/JPG/pylammps-invoke-lammps.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 36 KiB

After

Width:  |  Height:  |  Size: 36 KiB

BIN
doc/src/JPG/python-invoke-lammps.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 28 KiB

After

Width:  |  Height:  |  Size: 28 KiB

12
doc/src/Library_objects.rst
View File

@ -9,6 +9,8 @@ fixes, or variables in LAMMPS using the following functions:
- :cpp:func:`lammps_extract_variable_datatype`
- :cpp:func:`lammps_extract_variable`
- :cpp:func:`lammps_set_variable`
- :cpp:func:`lammps_set_string_variable`
- :cpp:func:`lammps_set_internal_variable`
- :cpp:func:`lammps_variable_info`
-----------------------
@ -38,6 +40,16 @@ fixes, or variables in LAMMPS using the following functions:
-----------------------
.. doxygenfunction:: lammps_set_string_variable
:project: progguide
-----------------------
.. doxygenfunction:: lammps_set_internal_variable
:project: progguide
-----------------------
.. doxygenfunction:: lammps_variable_info
:project: progguide

99
doc/src/Manual_version.rst
View File

@ -3,45 +3,25 @@ What does a LAMMPS version mean
The LAMMPS "version" is the date when it was released, such as 1 May
2014. LAMMPS is updated continuously, and we aim to keep it working
correctly and reliably at all times. You can follow its development
in a public `git repository on GitHub <https://github.com/lammps/lammps>`_.
Modifications of the LAMMPS source code (like bug fixes, code refactors,
updates to existing features, or addition of new features) are organized
into pull requests. Pull requests will be merged into the *develop*
branch of the git repository after they pass automated testing and code
review by the LAMMPS developers. When a sufficient number of changes
have accumulated *and* the *develop* branch version passes an extended
set of automated tests, we release it as a *feature release*, which are
currently made every 4 to 8 weeks. The *release* branch of the git
repository is updated with every such release. A summary of the most
important changes of the patch releases are on `this website page
<https://www.lammps.org/bug.html>`_. More detailed release notes are
`available on GitHub <https://github.com/lammps/lammps/releases/>`_.
Once or twice a year, we have a "stabilization period" where we apply
only bug fixes and small, non-intrusive changes to the *develop*
branch. At the same time, the code is subjected to more detailed and
thorough manual testing than the default automated testing. Also,
several variants of static code analysis are run to improve the overall
code quality, consistency, and compliance with programming standards,
best practices and style conventions.
The release after such a stabilization period is called a *stable*
version and both, the *release* and the *stable* branches are updated
with it. Between stable releases, we collect back-ported bug fixes and
updates from the *develop* branch in the *maintenance* branch. From the
*maintenance* branch we make occasional update releases and update the
*stable* branch accordingly.
correctly and reliably at all times. Also, several variants of static
code analysis are run regularly to maintain or improve the overall code
quality, consistency, and compliance with programming standards, best
practices and style conventions. You can follow its development in a
public `git repository on GitHub <https://github.com/lammps/lammps>`_.
Each version of LAMMPS contains all the documented *features* up to and
including its version date. For recently added features, we add markers
to the documentation at which specific LAMMPS version a feature or
keyword was added or significantly changed.
The version date is printed to the screen and log file every time you run
LAMMPS. It is also in the file src/version.h and in the LAMMPS
directory name created when you unpack a tarball. And it is on the
Identifying the Version
^^^^^^^^^^^^^^^^^^^^^^^
The version date is printed to the screen and log file every time you
run LAMMPS. There also is an indication, if a LAMMPS binary was
compiled from version with modifications **after** a release.
It is also visible in the file src/version.h and in the LAMMPS directory
name created when you unpack a downloaded tarball. And it is on the
first page of the :doc:`manual <Manual>`.
* If you browse the HTML pages of the online version of the LAMMPS
@ -53,3 +33,56 @@ first page of the :doc:`manual <Manual>`.
* If you browse the HTML pages included in your downloaded tarball, they
describe the version you have, which may be older than the online
version.
LAMMPS releases, branches, and tags
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. figure:: JPG/lammps-releases.png
:figclass: align-center
Relations between releases, main branches, and tags in the LAMMPS git repository
Development
"""""""""""
Modifications of the LAMMPS source code (like bug fixes, code
refactoring, updates to existing features, or addition of new features)
are organized into pull requests. Pull requests will be merged into the
*develop* branch of the git repository after they pass automated testing
and code review by the LAMMPS developers.
Feature Releases
""""""""""""""""
When a sufficient number of new features and updates have accumulated
*and* the LAMMPS version on the *develop* branch passes an extended set
of automated tests, we release it as a *feature release*, which are
currently made every 4 to 8 weeks. The *release* branch of the git
repository is updated with every such *feature release* and a tag in the
format ``patch_1May2014`` is added. A summary of the most important
changes of these releases for the current year are posted on `this
website page <https://www.lammps.org/bug.html>`_. More detailed release
notes are `available on GitHub
<https://github.com/lammps/lammps/releases/>`_.
Stable Releases
"""""""""""""""
About once a year, we release a *stable release* version of LAMMPS.
This is done after a "stabilization period" where we apply only bug
fixes and small, non-intrusive changes to the *develop* branch but no
new features. At the same time, the code is subjected to more detailed
and thorough manual testing than the default automated testing.
After such a *stable release*, both the *release* and the *stable*
branches are updated and two tags are applied, a ``patch_1May2014`` format
and a ``stable_1May2014`` format tag.
Stable Release Updates
""""""""""""""""""""""
Between *stable releases*, we collect bug fixes and updates back-ported
from the *develop* branch in a branch called *maintenance*. From the
*maintenance* branch we make occasional *stable update releases* and
update the *stable* branch accordingly. The first update to the
``stable_1May2014`` release would be tagged as
``stable_1May2014_update1``. These updates contain no new features.

2
doc/src/Packages_details.rst
View File

@ -2226,7 +2226,7 @@ and third order tensor from finite differences.
**Install:**
The PHONON package requires that also the :ref:`KSPACE <PKG-KSPACE>`
The fix phonon command also requires that the :ref:`KSPACE <PKG-KSPACE>`
package is installed.

10
doc/src/Python_error.rst
View File

@ -1,11 +1,11 @@
Handling LAMMPS errors
**********************
The shared library is compiled with :ref:`C++ exception support
<exceptions>` to provide a better error handling experience. C++
exceptions allow capturing errors on the C++ side and rethrowing them on
the Python side. This way LAMMPS errors can be handled through the
Python exception handling mechanism.
LAMMPS and the LAMMPS library are compiled with :ref:`C++ exception support
<exceptions>` to provide a better error handling experience. LAMMPS errors
trigger throwing a C++ exception. These exceptions allow capturing errors on
the C++ side and rethrowing them on the Python side. This way LAMMPS errors
can be handled through the Python exception handling mechanism.
.. code-block:: python

19
doc/src/Run_output.rst
View File

@ -49,14 +49,17 @@ simulation. An example set of statistics is shown here:
----------
The first section provides a global loop timing summary. The *loop time*
is the total wall-clock time for the simulation to run. The
*Performance* line is provided for convenience to help predict how long
it will take to run a desired physical simulation and to have numbers
useful for performance comparison between different simulation settings
or system sizes. The *CPU use* line provides the CPU utilization per
MPI task; it should be close to 100% times the number of OpenMP threads
(or 1 of not using OpenMP). Lower numbers correspond to delays due to
file I/O or insufficient thread utilization.
is the total wall-clock time for the MD steps of the simulation run,
excluding the time for initialization and setup (i.e. the parts that may
be skipped with :doc:`run N pre no <run>`). The *Performance* line is
provided for convenience to help predict how long it will take to run a
desired physical simulation and to have numbers useful for performance
comparison between different simulation settings or system sizes. The
*CPU use* line provides the CPU utilization per MPI task; it should be
close to 100% times the number of OpenMP threads (or 1 if not using
OpenMP). Lower numbers correspond to delays due to file I/O or
insufficient thread utilization from parts of the code that have not
been multi-threaded.
----------

4
doc/src/angle_charmm.rst
View File

@ -70,7 +70,9 @@ for more info.
Related commands
""""""""""""""""
:doc:`angle_coeff <angle_coeff>`
:doc:`angle_coeff <angle_coeff>`, :doc:`pair_style lj/charmm variants <pair_charmm>`,
:doc:`dihedral_style charmm <dihedral_charmm>`,
:doc:`dihedral_style charmmfsw <dihedral_charmm>`, :doc:`fix cmap <fix_cmap>`
Default
"""""""

19
doc/src/angle_lepton.rst
View File

@ -11,7 +11,16 @@ Syntax
.. code-block:: LAMMPS
angle_style lepton
angle_style style args
* style = *lepton*
* args = optional arguments
.. parsed-literal::
args = *auto_offset* or *no_offset*
*auto_offset* = offset the potential energy so that the value at theta0 is 0.0 (default)
*no_offset* = do not offset the potential energy
Examples
""""""""
@ -19,6 +28,7 @@ Examples
.. code-block:: LAMMPS
angle_style lepton
angle_style lepton no_offset
angle_coeff 1 120.0 "k*theta^2; k=250.0"
angle_coeff 2 90.0 "k2*theta^2 + k3*theta^3 + k4*theta^4; k2=300.0; k3=-100.0; k4=50.0"
@ -41,6 +51,13 @@ angle coefficient. For example `"200.0*theta^2"` represents a
U_{angle,i} = K (\theta_i - \theta_0)^2 = K \theta^2 \qquad \theta = \theta_i - \theta_0
.. versionchanged:: TBD
By default the potential energy U is shifted so that the value U is 0.0
for $theta = theta_0$. This is equivalent to using the optional keyword
*auto_offset*. When using the keyword *no_offset* instead, the
potential energy is not shifted.
The `Lepton library <https://simtk.org/projects/lepton>`_, that the
*lepton* angle style interfaces with, evaluates this expression string
at run time to compute the pairwise energy. It also creates an

614
doc/src/atom_style.rst
View File

@ -49,248 +49,221 @@ Examples
Description
"""""""""""
Define what style of atoms to use in a simulation. This determines
what attributes are associated with the atoms. This command must be
used before a simulation is setup via a :doc:`read_data <read_data>`,
:doc:`read_restart <read_restart>`, or :doc:`create_box <create_box>`
command.
The *atom_style* command selects which per-atom attributes are
associated with atoms in a LAMMPS simulation and thus stored and
communicated with those atoms as well as read from and stored in data
and restart files. Different models (e.g. :doc:`pair styles
<pair_style>`) require access to specific per-atom attributes and thus
require a specific atom style. For example, to compute Coulomb
interactions, the atom must have a "charge" (aka "q") attribute.
A number of distinct atom styles exist that combine attributes. Some
atom styles are a superset of other atom styles. Further attributes
may be added to atoms either via using a hybrid style which provides a
union of the attributes of the sub-styles, or via the :doc:`fix
property/atom <fix_property_atom>` command. The *atom_style* command
must be used before a simulation is setup via a :doc:`read_data
<read_data>`, :doc:`read_restart <read_restart>`, or :doc:`create_box
<create_box>` command.
.. note::
Many of the atom styles discussed here are only enabled if
LAMMPS was built with a specific package, as listed below in the
Restrictions section.
Many of the atom styles discussed here are only enabled if LAMMPS was
built with a specific package, as listed below in the Restrictions
section.
Once a style is assigned, it cannot be changed, so use a style general
enough to encompass all attributes. E.g. with style *bond*, angular
terms cannot be used or added later to the model. It is OK to use a
style more general than needed, though it may be slightly inefficient.
Once a style is selected and the simulation box defined, it cannot be
changed but only augmented with the :doc:`fix property/atom
<fix_property_atom>` command. So one should select an atom style
general enough to encompass all attributes required. E.g. with atom
style *bond*, it is not possible to define angles and use angle styles.
The choice of style affects what quantities are stored by each atom,
what quantities are communicated between processors to enable forces
to be computed, and what quantities are listed in the data file read
by the :doc:`read_data <read_data>` command.
It is OK to use a style more general than needed, though it may be
slightly inefficient because it will allocate and communicate
additional unused data.
These are the additional attributes of each style and the typical
kinds of physical systems they are used to model. All styles store
coordinates, velocities, atom IDs and types. See the
Atom style attributes
"""""""""""""""""""""
The atom style *atomic* has the minimum subset of per-atom attributes
and is also the default setting. It encompasses the following per-atom
attributes (name of the vector or array in the :doc:`Atom class
<Classes_atom>` is given in parenthesis): atom-ID (tag), type (type),
position (x), velocities (v), forces (f), image flags (image), group
membership (mask). Since all atom styles are a superset of atom style
*atomic*\ , they all include these attributes.
This table lists all the available atom styles, which attributes they
provide, which :doc:`package <Packages>` is required to use them, and
what the typical applications are that use them. See the
:doc:`read_data <read_data>`, :doc:`create_atoms <create_atoms>`, and
:doc:`set <set>` commands for info on how to set these various
quantities.
:doc:`set <set>` commands for details on how to set these various
quantities. More information about many of the styles is provided in
the Additional Information section below.
+--------------+-----------------------------------------------------+--------------------------------------+
| *amoeba* | molecular + charge + 1/5 neighbors | AMOEBA/HIPPO polarized force fields |
+--------------+-----------------------------------------------------+--------------------------------------+
| *angle* | bonds and angles | bead-spring polymers with stiffness |
+--------------+-----------------------------------------------------+--------------------------------------+
| *atomic* | only the default values | coarse-grain liquids, solids, metals |
+--------------+-----------------------------------------------------+--------------------------------------+
| *body* | mass, inertia moments, quaternion, angular momentum | arbitrary bodies |
+--------------+-----------------------------------------------------+--------------------------------------+
| *bond* | bonds | bead-spring polymers |
+--------------+-----------------------------------------------------+--------------------------------------+
| *charge* | charge | atomic system with charges |
+--------------+-----------------------------------------------------+--------------------------------------+
| *dielectric* | normx normy normz area/patch ed em epsilon curv | system with surface polarization |
+--------------+-----------------------------------------------------+--------------------------------------+
| *dipole* | charge and dipole moment | system with dipolar particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *dpd* | internal temperature and internal energies | DPD particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *edpd* | temperature and heat capacity | eDPD particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *electron* | charge and spin and eradius | electronic force field |
+--------------+-----------------------------------------------------+--------------------------------------+
| *ellipsoid* | shape, quaternion, angular momentum | aspherical particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *full* | molecular + charge | bio-molecules |
+--------------+-----------------------------------------------------+--------------------------------------+
| *line* | end points, angular velocity | rigid bodies |
+--------------+-----------------------------------------------------+--------------------------------------+
| *mdpd* | density | mDPD particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *molecular* | bonds, angles, dihedrals, impropers | uncharged molecules |
+--------------+-----------------------------------------------------+--------------------------------------+
| *oxdna* | nucleotide polarity | coarse-grained DNA and RNA models |
+--------------+-----------------------------------------------------+--------------------------------------+
| *peri* | mass, volume | mesoscopic Peridynamic models |
+--------------+-----------------------------------------------------+--------------------------------------+
| *smd* | volume, kernel diameter, contact radius, mass | solid and fluid SPH particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *sph* | rho, esph, cv | SPH particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *sphere* | diameter, mass, angular velocity | granular models |
+--------------+-----------------------------------------------------+--------------------------------------+
| *bpm/sphere* | diameter, mass, angular velocity, quaternion | granular bonded particle models (BPM)|
+--------------+-----------------------------------------------------+--------------------------------------+
| *spin* | magnetic moment | system with magnetic particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *tdpd* | chemical concentration | tDPD particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *template* | template index, template atom | small molecules with fixed topology |
+--------------+-----------------------------------------------------+--------------------------------------+
| *tri* | corner points, angular momentum | rigid bodies |
+--------------+-----------------------------------------------------+--------------------------------------+
| *wavepacket* | charge, spin, eradius, etag, cs_re, cs_im | AWPMD |
+--------------+-----------------------------------------------------+--------------------------------------+
.. list-table::
:header-rows: 1
:widths: auto
* - Atom style
- Attributes
- Required package
- Applications
* - *amoeba*
- *full* + "1-5 special neighbor data"
- :ref:`AMOEBA <PKG-AMOEBA>`
- AMOEBA/HIPPO force fields
* - *angle*
- *bond* + "angle data"
- :ref:`MOLECULE <PKG-MOLECULE>`
- bead-spring polymers with stiffness
* - *atomic*
- tag, type, x, v, f, image, mask
-
- atomic liquids, solids, metals
* - *body*
- *atomic* + radius, rmass, angmom, torque, body
- :ref:`BODY <PKG-BODY>`
- arbitrary bodies, see :doc:`body howto <Howto_body>`
* - *bond*
- *atomic* + molecule, nspecial, special + "bond data"
- :ref:`MOLECULE <PKG-MOLECULE>`
- bead-spring polymers
* - *bpm/sphere*
- *bond* + radius, rmass, omega, torque, quat
- :ref:`BPM <PKG-BPM>`
- granular bonded particle models, see :doc:`BPM howto <Howto_bpm>`
* - *charge*
- *atomic* + q
-
- atomic systems with charges
* - *dielectric*
- *full* + mu, area, ed, em, epsilon, curvature, q_scaled
- :ref:`DIELECTRIC <PKG-DIELECTRIC>`
- systems with surface polarization
* - *dipole*
- *charge* + mu
- :ref:`DIPOLE <PKG-DIPOLE>`
- atomic systems with charges and point dipoles
* - *dpd*
- *atomic* + rho + "reactive DPD data"
- :ref:`DPD-REACT <PKG-DPD-REACT>`
- reactive DPD
* - *edpd*
- *atomic* + "eDPD data"
- :ref:`DPD-MESO <PKG-DPD-MESO>`
- Energy conservative DPD (eDPD)
* - *electron*
- *charge* + espin, eradius, ervel, erforce
- :ref:`EFF <PKG-EFF>`
- Electron force field systems
* - *ellipsoid*
- *atomic* + rmass, angmom, torque, ellipsoid
-
- aspherical particles
* - *full*
- *molecular* + q
- :ref:`MOLECULE <PKG-MOLECULE>`
- molecular force fields
* - *line*
- *atomic* + molecule, radius, rmass, omega, torque, line
-
- 2-d rigid body particles
* - *mdpd*
- *atomic* + rho, drho, vest
- :ref:`DPD-MESO <PKG-DPD-MESO>`
- Many-body DPD (mDPD)
* - *molecular*
- *angle* + "dihedral and improper data"
- :ref:`MOLECULE <PKG-MOLECULE>`
- apolar and uncharged molecules
* - *oxdna*
- *atomic* + id5p
- :ref:`CG-DNA <PKG-CG-DNA>`
- coarse-grained DNA and RNA models
* - *peri*
- *atomic* + rmass, vfrac, s0, x0
- :ref:`PERI <PKG-PERI>`
- mesoscopic Peridynamics models
* - *smd*
- *atomic* + molecule, radius, rmass + "smd data"
- :ref:`MACHDYN <PKG-MACHDYN>`
- Smooth Mach Dynamics models
* - *sph*
- *atomic* + "sph data"
- :ref:`SPH <PKG-SPH>`
- Smoothed particle hydrodynamics models
* - *sphere*
- *atomic* + radius, rmass, omega, torque
-
- finite size spherical particles, e.g. granular models
* - *spin*
- *atomic* + "magnetic moment data"
- :ref:`SPIN <PKG-SPIN>`
- magnetic particles
* - *tdpd*
- *atomic* + cc, cc_flux, vest
- :ref:`DPD-MESO <PKG-DPD-MESO>`
- Transport DPD (tDPD)
* - *template*
- *atomic* + molecule, molindex, molatom
- :ref:`MOLECULE <PKG-MOLECULE>`
- molecular systems where attributes are taken from :doc:`molecule files <molecule>`
* - *tri*
- *sphere* + molecule, angmom, tri
-
- 3-d triangulated rigid body LJ particles
* - *wavepacket*
- *charge* + "wavepacket data"
- :ref:`AWPMD <PKG-AWPMD>`
- Antisymmetrized wave packet MD
.. note::
It is possible to add some attributes, such as a molecule ID, to
atom styles that do not have them via the :doc:`fix property/atom
<fix_property_atom>` command. This command also allows new custom
attributes consisting of extra integer or floating-point values to
be added to atoms. See the :doc:`fix property/atom
<fix_property_atom>` page for examples of cases where this is
useful and details on how to initialize, access, and output the
custom values.
It is possible to add some attributes, such as a molecule ID and
charge, to atom styles that do not have them built in using the
:doc:`fix property/atom <fix_property_atom>` command. This command
also allows new custom-named attributes consisting of extra integer
or floating-point values or vectors to be added to atoms. See the
:doc:`fix property/atom <fix_property_atom>` page for examples of
cases where this is useful and details on how to initialize,
access, and output these custom values.
All of the above styles define point particles, except the *sphere*,
*bpm/sphere*, *ellipsoid*, *electron*, *peri*, *wavepacket*, *line*,
*tri*, and *body* styles, which define finite-size particles. See the
:doc:`Howto spherical <Howto_spherical>` page for an overview of using
finite-size particle models with LAMMPS.
----------
All of the point-particle styles assign mass to particles on a
per-type basis, using the :doc:`mass <mass>` command, The finite-size
particle styles assign mass to individual particles on a per-particle
basis.
Particle size and mass
""""""""""""""""""""""
For the *sphere* and *bpm/sphere* styles, the particles are spheres
and each stores a per-particle diameter and mass. If the diameter >
0.0, the particle is a finite-size sphere. If the diameter = 0.0, it
is a point particle. Note that by use of the *disc* keyword with 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 for the *sphere* style,
spheres can be effectively treated as 2d discs for a 2d simulation if
desired. See also the :doc:`set density/disc <set>` command. These
styles take an optional 0 or 1 argument. A value of 0 means the
radius of each sphere is constant for the duration of the simulation.
A value of 1 means the radii may vary dynamically during the simulation,
e.g. due to use of the :doc:`fix adapt <fix_adapt>` command.
All of the atom styles define point particles unless they (1) define
finite-size spherical particles via the *radius* attribute, or (2)
define finite-size aspherical particles (e.g. the *body*, *ellipsoid*,
*line*, and *tri* styles). Most of these styles can also be used with
mixtures of point and finite-size particles.
For the *ellipsoid* style, the particles are ellipsoids and each
stores a flag which indicates whether it is a finite-size ellipsoid or
a point particle. If it is an ellipsoid, it also stores a shape
vector with the 3 diameters of the ellipsoid and a quaternion 4-vector
with its orientation.
Note that the *radius* property may need to be provided as a
*diameter* (e.g. in :doc:`molecule files <molecule>` or :doc:`data
files <read_data>`). See the :doc:`Howto spherical <Howto_spherical>`
page for an overview of using finite-size spherical and aspherical
particle models with LAMMPS.
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
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.
Unless an atom style defines the per-atom *rmass* attribute, particle
masses are defined on a per-type basis, using the :doc:`mass <mass>`
command. This means each particle's mass is indexed by its atom
*type*.
For the *dipole* style, a point dipole is defined for each point
particle. Note that if you wish the particles to be finite-size
spheres as in a Stockmayer potential for a dipolar fluid, so that the
particles can rotate due to dipole-dipole interactions, then you need
to use atom_style hybrid sphere dipole, which will assign both a
diameter and dipole moment to each particle.
A few styles define the per-atom *rmass* attribute which can also be
added using the :doc:`fix property/atom <fix_property_atom>` command.
In this case each particle stores its own mass. Atom styles that have
a per-atom rmass may define it indirectly through setting particle
diameter and density on a per-particle basis. If both per-type mass
and per-atom *rmass* are defined (e.g. in a hybrid style), the
per-atom mass will take precedence in any operation which which works
with both flavors of mass.
For the *electron* style, the particles representing electrons are 3d
Gaussians with a specified position and bandwidth or uncertainty in
position, which is represented by the eradius = electron size.
----------
For the *peri* style, the particles are spherical and each stores a
per-particle mass and volume.
The *bpm/sphere* style is part of the BPM package.
The *oxdna* style is for coarse-grained nucleotides and 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. Note that this style is part of the CG-DNA package.
The *dpd* style is for dissipative particle dynamics (DPD) particles.
Note that it is part of the DPD-REACT package, and is not for use with
the :doc:`pair_style dpd or dpd/stat <pair_dpd>` commands, which can
simply use atom_style atomic. Atom_style dpd extends DPD particle
properties with internal temperature (dpdTheta), internal conductive
energy (uCond), internal mechanical energy (uMech), and internal
chemical energy (uChem).
The *edpd* style is for energy-conserving dissipative particle
dynamics (eDPD) particles which store a temperature (edpd_temp), and
heat capacity(edpd_cv).
The *mdpd* style is for many-body dissipative particle dynamics (mDPD)
particles which store a density (rho) for considering
density-dependent many-body interactions.
The *tdpd* style is for transport dissipative particle dynamics (tDPD)
particles which store a set of chemical concentration. An integer
"cc_species" is required to specify the number of chemical species
involved in a tDPD system.
The *sph* style is for smoothed particle hydrodynamics (SPH)
particles which store a density (rho), energy (esph), and heat capacity
(cv).
The *smd* style is for a general formulation of Smooth Particle
Hydrodynamics. Both fluids and solids can be modeled. Particles
store the mass and volume of an integration point, a kernel diameter
used for calculating the field variables (e.g. stress and deformation)
and a contact radius for calculating repulsive forces which prevent
individual physical bodies from penetrating each other.
For the *spin* style, a magnetic spin is associated to each atom.
Those spins have a norm (their magnetic moment) and a direction.
The *wavepacket* style is similar to *electron*, but the electrons may
consist of several Gaussian wave packets, summed up with coefficients
cs= (cs_re,cs_im). Each of the wave packets is treated as a separate
particle in LAMMPS, wave packets belonging to the same electron must
have identical *etag* values.
For the *line* style, the particles are idealized line segments and
each stores a per-particle mass and length and orientation (i.e. the
end points of the line segment).
For the *tri* style, the particles are planar triangles and each
stores a per-particle mass and size and orientation (i.e. the corner
points of the triangle).
The *template* style allows molecular topology (bonds,angles,etc) to be
defined via a molecule template using the :doc:`molecule <molecule>`
command. The template stores one or more molecules with a single copy
of the topology info (bonds,angles,etc) of each. Individual atoms
only store a template index and template atom to identify which
molecule and which atom-within-the-molecule they represent. Using the
*template* style instead of the *bond*, *angle*, *molecular* styles
can save memory for systems comprised of a large number of small
molecules, all of a single type (or small number of types). See the
paper by Grime and Voth, in :ref:`(Grime) <Grime>`, for examples of how this
can be advantageous for large-scale coarse-grained systems.
The ``examples/template`` directory has a few demo inputs and examples
showing the use of the *template* atom style versus *molecular*.
.. note::
When using the *template* style with a :doc:`molecule template
<molecule>` that contains multiple molecules, you should ensure the
atom types, bond types, angle_types, etc in all the molecules are
consistent. E.g. if one molecule represents H2O and another CO2,
then you probably do not want each molecule file to define 2 atom
types and a single bond type, because they will conflict with each
other when a mixture system of H2O and CO2 molecules is defined,
e.g. by the :doc:`read_data <read_data>` command. Rather the H2O
molecule should define atom types 1 and 2, and bond type 1. And
the CO2 molecule should define atom types 3 and 4 (or atom types 3
and 2 if a single oxygen type is desired), and bond type 2.
Additional information about specific atom styles
"""""""""""""""""""""""""""""""""""""""""""""""""
For the *body* style, the particles are arbitrary bodies with internal
attributes defined by the "style" of the bodies, which is specified by
@ -309,6 +282,148 @@ Note that there may be additional arguments required along with the
*bstyle* specification, in the atom_style body command. These
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
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.
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
spheres as in a Stockmayer potential for a dipolar fluid, so that the
particles can rotate due to dipole-dipole interactions, then you need
to use the command `atom_style hybrid sphere dipole`, which will
assign both a diameter and dipole moment to each particle. This also
requires using an integrator with a "/sphere" suffix like :doc:`fix
nve/sphere <fix_nve_sphere>` or :doc:`fix nvt/sphere <fix_nvt_sphere>`
and the "update dipole" or "update dlm" parameters to the fix
commands.
The *dpd* style is for reactive dissipative particle dynamics (DPD)
particles. Note that it is part of the DPD-REACT package, and is not
required for use with the :doc:`pair_style dpd or dpd/stat <pair_dpd>`
commands, which only require the attributes from atom_style *atomic*.
Atom_style *dpd* extends DPD particle properties with internal
temperature (dpdTheta), internal conductive energy (uCond), internal
mechanical energy (uMech), and internal chemical energy (uChem).
The *edpd* style is for energy-conserving dissipative particle
dynamics (eDPD) particles which store a temperature (edpd_temp), and
heat capacity (edpd_cv).
For the *electron* style, the particles representing electrons are 3d
Gaussians with a specified position and bandwidth or uncertainty in
position, which is represented by the eradius = electron size.
For the *ellipsoid* style, particles can be ellipsoids which each
stores a shape vector with the 3 diameters of the ellipsoid and a
quaternion 4-vector with its orientation. Each particle stores a flag
in the ellipsoid vector which indicates whether it is an ellipsoid (1)
or a point particle (0).
For the *line* style, particles can be are idealized line segments
which store a per-particle mass and length and orientation (i.e. the
end points of the line segment). Each particle stores a flag in the
line vector which indicates whether it is a line segment (1) or a
point particle (0).
The *mdpd* style is for many-body dissipative particle dynamics (mDPD)
particles which store a density (rho) for considering density-dependent
many-body interactions.
The *oxdna* style is for coarse-grained nucleotides and 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.
For the *peri* style, the particles are spherical and each stores a
per-particle mass and volume.
The *smd* style is for Smooth Particle Mach dynamics. Both fluids and
solids can be modeled. Particles store the mass and volume of an
integration point, a kernel diameter used for calculating the field
variables (e.g. stress and deformation) and a contact radius for
calculating repulsive forces which prevent individual physical bodies
from penetrating each other.
The *sph* style is for smoothed particle hydrodynamics (SPH) particles
which store a density (rho), energy (esph), and heat capacity (cv).
For the *spin* style, a magnetic spin is associated with each atom.
Those spins have a norm (their magnetic moment) and a direction.
The *tdpd* style is for transport dissipative particle dynamics (tDPD)
particles which store a set of chemical concentration. An integer
"cc_species" is required to specify the number of chemical species
involved in a tDPD system.
The *wavepacket* style is similar to the *electron* style, but the
electrons may consist of several Gaussian wave packets, summed up with
coefficients cs= (cs_re,cs_im). Each of the wave packets is treated
as a separate particle in LAMMPS, wave packets belonging to the same
electron must have identical *etag* values.
The *sphere* and *bpm/sphere* styles allow particles to be either point
particles or finite-size particles. If the *radius* attribute is >
0.0, the particle is a finite-size sphere. If the diameter = 0.0, it
is a point particle. Note that by using the *disc* keyword with 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 for the *sphere* style, spheres
can be effectively treated as 2d discs for a 2d simulation if desired.
See also the :doc:`set density/disc <set>` command. These styles also
take an optional 0 or 1 argument. A value of 0 means the radius of
each sphere is constant for the duration of the simulation (this is
the default). A value of 1 means the radii may vary dynamically
during the simulation, e.g. due to use of the :doc:`fix adapt
<fix_adapt>` command.
The *template* style allows molecular topology (bonds,angles,etc) to be
defined via a molecule template using the :doc:`molecule <molecule>`
command. The template stores one or more molecules with a single copy
of the topology info (bonds,angles,etc) of each. Individual atoms only
store a template index and template atom to identify which molecule and
which atom-within-the-molecule they represent. Using the *template*
style instead of the *bond*, *angle*, *molecular* styles can save memory
for systems comprised of a large number of small molecules, all of a
single type (or small number of types). See the paper by Grime and
Voth, in :ref:`(Grime) <Grime>`, for examples of how this can be
advantageous for large-scale coarse-grained systems. The
``examples/template`` directory has a few demo inputs and examples
showing the use of the *template* atom style versus *molecular*.
.. note::
When using the *template* style with a :doc:`molecule template
<molecule>` that contains multiple molecules, you should ensure the
atom types, bond types, angle_types, etc in all the molecules are
consistent. E.g. if one molecule represents H2O and another CO2,
then you probably do not want each molecule file to define 2 atom
types and a single bond type, because they will conflict with each
other when a mixture system of H2O and CO2 molecules is defined,
e.g. by the :doc:`read_data <read_data>` command. Rather the H2O
molecule should define atom types 1 and 2, and bond type 1. And
the CO2 molecule should define atom types 3 and 4 (or atom types 3
and 2 if a single oxygen type is desired), and bond type 2.
For the *tri* style, particles can be planar triangles which each
stores a per-particle mass and size and orientation (i.e. the corner
points of the triangle). Each particle stores a flag in the tri
vector which indicates whether it is a triangle (1) or a point
particle (0).
----------
Typically, simulations require only a single (non-hybrid) atom style.
@ -326,11 +441,12 @@ dipole". When a hybrid style is used, atoms store and communicate the
union of all quantities implied by the individual styles.
When using the *hybrid* style, you cannot combine the *template* style
with another molecular style that stores bond,angle,etc info on a
with another molecular style that stores bond, angle, etc info on a
per-atom basis.
LAMMPS can be extended with new atom styles as well as new body
styles; see the :doc:`Modify <Modify>` doc page.
LAMMPS can be extended with new atom styles as well as new body styles;
see the corresponding manual page on :doc:`modifying & extending LAMMPS
<Modify_atom>`.
----------
@ -346,54 +462,20 @@ This command cannot be used after the simulation box is defined by a
Many of the styles listed above are only enabled if LAMMPS was built
with a specific package, as listed below. See the :doc:`Build package
<Build_package>` page for more info.
The *amoeba* style is part of the AMOEBA package.
The *angle*, *bond*, *full*, *molecular*, and *template* styles are
part of the MOLECULE package.
The *line* and *tri* styles are part of the ASPHERE package.
The *body* style is part of the BODY package.
The *dipole* style is part of the DIPOLE package.
The *peri* style is part of the PERI package for Peridynamics.
The *oxdna* style is part of the CG-DNA package for coarse-grained
simulation of DNA and RNA.
The *electron* style is part of the EFF package for :doc:`electronic
force fields <pair_eff>`.
The *dpd* style is part of the DPD-REACT package for dissipative
particle dynamics (DPD).
The *edpd*, *mdpd*, and *tdpd* styles are part of the DPD-MESO package
for energy-conserving dissipative particle dynamics (eDPD), many-body
dissipative particle dynamics (mDPD), and transport dissipative particle
dynamics (tDPD), respectively.
The *sph* style is part of the SPH package for smoothed particle
hydrodynamics (SPH). See `this PDF guide
<PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
The *spin* style is part of the SPIN package.
The *wavepacket* style is part of the AWPMD package for the
:doc:`antisymmetrized wave packet MD method <pair_awpmd>`.
<Build_package>` page for more info. The table above lists which package
is required for individual atom styles.
Related commands
""""""""""""""""
:doc:`read_data <read_data>`, :doc:`pair_style <pair_style>`
:doc:`read_data <read_data>`, :doc:`pair_style <pair_style>`,
:doc:`fix property/atom <fix_property_atom>`, :doc:`set <set>`
Default
"""""""
The default atom style is atomic. If atom_style sphere is used its
default argument is 0.
The default atom style is *atomic*. If atom_style *sphere* or
*bpm/sphere* is used, its default argument is 0.
----------

4
doc/src/bond_bpm_rotational.rst
View File

@ -147,8 +147,8 @@ By default, pair forces are not calculated between bonded particles.
Pair forces can alternatively be overlaid on top of bond forces by setting
the *overlay/pair* keyword to *yes*. These settings require specific
:doc:`special_bonds <special_bonds>` settings described in the
restrictions. Further details can be found in the :doc:`how to
<Howto_bpm>` page on BPMs.
restrictions. Further details can be found in the :doc:`how to <Howto_bpm>`
page on BPMs.
.. versionadded:: 28Mar2023

4
doc/src/bond_bpm_spring.rst
View File

@ -113,8 +113,8 @@ By default, pair forces are not calculated between bonded particles.
Pair forces can alternatively be overlaid on top of bond forces by setting
the *overlay/pair* keyword to *yes*. These settings require specific
:doc:`special_bonds <special_bonds>` settings described in the
restrictions. Further details can be found in the :doc:`how to
<Howto_bpm>` page on BPMs.
restrictions. Further details can be found in the :doc:`how to <Howto_bpm>`
page on BPMs.
.. versionadded:: 28Mar2023

19
doc/src/bond_lepton.rst
View File

@ -11,7 +11,16 @@ Syntax
.. code-block:: LAMMPS
bond_style lepton
bond_style style args
* style = *lepton*
* args = optional arguments
.. parsed-literal::
args = *auto_offset* or *no_offset*
*auto_offset* = offset the potential energy so that the value at r0 is 0.0 (default)
*no_offset* = do not offset the potential energy
Examples
""""""""
@ -19,6 +28,7 @@ Examples
.. code-block:: LAMMPS
bond_style lepton
bond_style lepton no_offset
bond_coeff 1 1.5 "k*r^2; k=250.0"
bond_coeff 2 1.1 "k2*r^2 + k3*r^3 + k4*r^4; k2=300.0; k3=-100.0; k4=50.0"
@ -40,6 +50,13 @@ constant *K* of 200.0 energy units:
U_{bond,i} = K (r_i - r_0)^2 = K r^2 \qquad r = r_i - r_0
.. versionchanged:: TBD
By default the potential energy U is shifted so that he value U is 0.0
for $r = r_0$. This is equivalent to using the optional keyword
*auto_offset*. When using the keyword *no_offset* instead, the
potential energy is not shifted.
The `Lepton library <https://simtk.org/projects/lepton>`_, that the
*lepton* bond style interfaces with, evaluates this expression string at
run time to compute the pairwise energy. It also creates an analytical

4
doc/src/compute.rst
View File

@ -264,6 +264,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`nbond/atom <compute_nbond_atom>` - calculates number of bonds per atom
* :doc:`omega/chunk <compute_omega_chunk>` - angular velocity for each chunk
* :doc:`orientorder/atom <compute_orientorder_atom>` - Steinhardt bond orientational order parameters Ql
* :doc:`pace <compute_pace>` - atomic cluster expansion descriptors and related quantities
* :doc:`pair <compute_pair>` - values computed by a pair style
* :doc:`pair/local <compute_pair_local>` - distance/energy/force of each pairwise interaction
* :doc:`pe <compute_pe>` - potential energy
@ -279,12 +280,15 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`property/grid <compute_property_grid>` - convert per-grid attributes to per-grid vectors/arrays
* :doc:`property/local <compute_property_local>` - convert local attributes to local vectors/arrays
* :doc:`ptm/atom <compute_ptm_atom>` - determines the local lattice structure based on the Polyhedral Template Matching method
* :doc:`rattlers/atom <compute_rattlers_atom>` - identify under-coordinated rattler atoms
* :doc:`rdf <compute_rdf>` - radial distribution function :math:`g(r)` histogram of group of atoms
* :doc:`reaxff/atom <compute_reaxff_atom>` - extract ReaxFF bond information
* :doc:`reduce <compute_reduce>` - combine per-atom quantities into a single global value
* :doc:`reduce/chunk <compute_reduce_chunk>` - reduce per-atom quantities within each chunk
* :doc:`reduce/region <compute_reduce>` - same as compute reduce, within a region
* :doc:`rigid/local <compute_rigid_local>` - extract rigid body attributes
* :doc:`saed <compute_saed>` - electron diffraction intensity on a mesh of reciprocal lattice nodes
* :doc:`slcsa/atom <compute_slcsa_atom>` - perform Supervised Learning Crystal Structure Analysis (SL-CSA)
* :doc:`slice <compute_slice>` - extract values from global vector or array
* :doc:`smd/contact/radius <compute_smd_contact_radius>` - contact radius for Smooth Mach Dynamics
* :doc:`smd/damage <compute_smd_damage>` - damage status of SPH particles in Smooth Mach Dynamics

9
doc/src/compute_contact_atom.rst
View File

@ -36,6 +36,9 @@ sum of the radii of the two particles.
The value of the contact number will be 0.0 for atoms not in the
specified compute group.
The optional *group2-ID* argument allows to specify from which group atoms
contribute to the coordination number. Default setting is group 'all'.
Output info
"""""""""""
@ -47,9 +50,6 @@ overview of LAMMPS output options.
The per-atom vector values will be a number :math:`\ge 0.0`, as explained
above.
The optional *group2-ID* argument allows to specify from which group atoms
contribute to the coordination number. Default setting is group 'all.'
Restrictions
""""""""""""
@ -69,6 +69,3 @@ Default
"""""""
*group2-ID* = all
none

253
doc/src/compute_pace.rst Normal file
View File

@ -0,0 +1,253 @@
.. index:: compute pace
compute pace command
========================
Syntax
""""""
.. code-block:: LAMMPS
compute ID group-ID pace ace_potential_filename ... keyword values ...
* ID, group-ID are documented in :doc:`compute <compute>` command
* pace = style name of this compute command
* ace_potential_filename = file name (in the .yace or .ace format from :doc:`pace pair_style <pair_pace>`) including ACE hyper-parameters, bonds, and generalized coupling coefficients
* keyword = *bikflag* or *dgradflag*
.. parsed-literal::
*bikflag* value = *0* or *1*
*0* = descriptors are summed over atoms of each type
*1* = descriptors are listed separately for each atom
*dgradflag* value = *0* or *1*
*0* = descriptor gradients are summed over atoms of each type
*1* = descriptor gradients are listed separately for each atom pair
Examples
""""""""
.. code-block:: LAMMPS
compute pace all pace coupling_coefficients.yace
compute pace all pace coupling_coefficients.yace 0 1
compute pace all pace coupling_coefficients.yace 1 1
Description
"""""""""""
.. versionadded:: TBD
This compute calculates a set of quantities related to the atomic
cluster expansion (ACE) descriptors of the atoms in a group. ACE
descriptors are highly general atomic descriptors, encoding the radial
and angular distribution of neighbor atoms, up to arbitrary bond order
(rank). The detailed mathematical definition is given in the paper by
:ref:`(Drautz) <Drautz19>`. These descriptors are used in the
:doc:`pace pair_style <pair_pace>`. Quantities obtained from `compute
pace` are related to those used in :doc:`pace pair_style <pair_pace>` to
evaluate atomic energies, forces, and stresses for linear ACE models.
For example, the energy for a linear ACE model is calculated as:
:math:`E=\sum_i^{N\_atoms} \sum_{\boldsymbol{\nu}} c_{\boldsymbol{\nu}}
B_{i,\boldsymbol{\boldsymbol{\nu}}}`. The ACE descriptors for atom `i`
:math:`B_{i,\boldsymbol{\nu}}`, and :math:`c_{\nu}` are linear model
parameters. The detailed definition and indexing convention for ACE
descriptors is given in :ref:`(Drautz) <Drautz19>`. In short, body
order :math:`N`, angular character, radial character, and chemical
elements in the *N-body* descriptor are encoded by :math:`\nu`. In the
:doc:`pace pair_style <pair_pace>`, the linear model parameters and the
ACE descriptors are combined for efficient evaluation of energies and
forces. The details and benefits of this efficient implementation are
given in :ref:`(Lysogorskiy) <Lysogorskiy21>`, but the combined
descriptors and linear model parameters for the purposes of `compute
pace` may be expressed in terms of the ACE descriptors mentioned above.
:math:`c_{\boldsymbol{\nu}} B_{i,\boldsymbol{\nu}}= \sum_{\boldsymbol{\nu}' \in \boldsymbol{\nu} } \big[ c_{\boldsymbol{\nu}} C(\boldsymbol{\nu}') \big] A_{i,\boldsymbol{\nu}'}`
where the bracketed terms on the right-hand side are the combined functions
with linear model parameters typically provided in the `<name>.yace` potential
file for `pace pair_style`. When these bracketed terms are multiplied by the
products of the atomic base from :ref:`(Drautz) <Drautz19>`,
:math:`A_{i,\boldsymbol{\nu'}}`, the ACE descriptors are recovered but they
are also scaled by linear model parameters. The generalized coupling coefficients,
written in short-hand here as :math:`C(\boldsymbol{\nu}')`, are the generalized
Clebsch-Gordan or generalized Wigner symbols. It may be desirable to reverse the
combination of these descriptors and the linear model parameters so that the
ACE descriptors themselves may be used. The ACE descriptors and their gradients
are often used when training ACE models, performing custom data analysis,
generalizing ACE model forms, and other tasks that involve direct computation of
descriptors. The key utility of `compute pace` is that it can compute the ACE
descriptors and gradients so that these tasks can be performed during a LAMMPS
simulation or so that LAMMPS can be used as a driver for tasks like ACE model
parameterization. To see how this command can be used within a Python workflow
to train ACE potentials, see the examples in
`FitSNAP <https://github.com/FitSNAP/FitSNAP>`_. Examples on using outputs from
this compute to construct general ACE potential forms are demonstrated in
:ref:`(Goff) <Goff23>`. The various keywords and inputs to `compute pace`
determine what ACE descriptors and related quantities are returned in a compute
array.
The coefficient file, `<name>.yace`, ultimately defines the number of ACE
descriptors to be computed, their maximum body-order, the degree of angular
character they have, the degree of radial character they have, the chemical
character (which element-element interactions are encoded by descriptors),
and other hyper-parameters defined in :ref:`(Drautz) <Drautz19>`. These may
be modeled after the potential files in :doc:`pace pair_style <pair_pace>`,
and have the same format. Details on how to generate the coefficient files
to train ACE models may be found in `FitSNAP <https://github.com/FitSNAP/FitSNAP>`_.
The keyword *bikflag* determines whether or not to list the descriptors of
each atom separately, or sum them together and list in a single row. If
*bikflag* is set to *0* then a single descriptor row is used, which contains
the per-atom ACE descriptors :math:`B_{i,\boldsymbol{\nu}}` summed over all
atoms *i* to produce :math:`B_{\boldsymbol{\nu}}`. If *bikflag* is set to
*1* this is replaced by a separate per-atom ACE descriptor row for each atom.
In this case, the entries in the final column for these rows are set to zero.
The keyword *dgradflag* determines whether to sum atom gradients or list
them separately. If *dgradflag* is set to 0, the ACE
descriptor gradients w.r.t. atom *j* are summed over all atoms *i'*
of, which may be useful when training linear ACE models on atomic forces.
If *dgradflag* is set to 1, gradients are listed separately for each pair of atoms.
Each row corresponds
to a single term :math:`\frac{\partial {B_{i,\boldsymbol{\nu}}}}{\partial {r}^a_j}`
where :math:`{r}^a_j` is the *a-th* position coordinate of the atom with global
index *j*. This also changes the number of columns to be equal to the number of
ACE descriptors, with 3 additional columns representing the indices :math:`i`,
:math:`j`, and :math:`a`, as explained more in the Output info section below.
The option *dgradflag=1* requires that *bikflag=1*.
.. note::
It is noted here that in contrast to :doc:`pace pair_style <pair_pace>`,
the *.yace* file for `compute pace` typically should not contain linear
parameters for an ACE potential. If :math:`c_{\nu}` are included,
the value of the descriptor will not be returned in the `compute` array,
but instead, the energy contribution from that descriptor will be returned.
Do not do this unless it is the desired behavior.
*In short, you should not plug in a '.yace' for a pace potential into this
compute to evaluate descriptors.*
.. note::
*Generalized Clebsch-Gordan or Generalized Wigner symbols (with appropriate
factors) must be used to evaluate ACE descriptors with this compute.* There
are multiple ways to define the generalized coupling coefficients. Because
of this, this compute will not revert your potential file to a coupling
coefficient file. Instead this compute allows the user to supply coupling
coefficients that follow any convention.
.. note::
Using *dgradflag* = 1 produces a global array with :math:`N + 3N^2 + 1` rows
which becomes expensive for systems with more than 1000 atoms.
.. note::
If you have a bonded system, then the settings of :doc:`special_bonds
<special_bonds>` command can remove pairwise interactions between
atoms in the same bond, angle, or dihedral. This is the default
setting for the :doc:`special_bonds <special_bonds>` command, and
means those pairwise interactions do not appear in the neighbor list.
Because this fix uses the neighbor list, it also means those pairs
will not be included in the calculation. One way to get around this,
is to write a dump file, and use the :doc:`rerun <rerun>` command to
compute the ACE descriptors for snapshots in the dump file.
The rerun script can use a :doc:`special_bonds <special_bonds>`
command that includes all pairs in the neighbor list.
----------
Output info
"""""""""""
Compute *pace* evaluates a global array. The columns are arranged into
*ntypes* blocks, listed in order of atom type *I*\ . Each block contains
one column for each ACE descriptor, the same as for compute
*sna/atom*\ in :doc:`compute snap <compute_sna_atom>`. A final column contains the corresponding energy, force
component on an atom, or virial stress component. The rows of the array
appear in the following order:
* 1 row: *pace* average descriptor values for all atoms of type *I*
* 3\*\ *n* force rows: quantities, with derivatives w.r.t. x, y, and z coordinate of atom *i* appearing in consecutive rows. The atoms are sorted based on atom ID and run up to the total number of atoms, *n*.
* 6 rows: *virial* quantities summed for all atoms of type *I*
For example, if :math:`\# \; B_{i, \boldsymbol{\nu}}` =30 and ntypes=1, the number of columns in the
The number of columns in the global array generated by *pace* are 31, and
931, respectively, while the number of rows is 1+3\*\ *n*\ +6, where *n*
is the total number of atoms.
If the *bik* keyword is set to 1, the structure of the pace array is expanded.
The first :math:`N` rows of the pace array
correspond to :math:`\# \; B_{i,\boldsymbol{\nu}}` instead of a single row summed over atoms :math:`i`.
In this case, the entries in the final column for these rows
are set to zero. Also, each row contains only non-zero entries for the
columns corresponding to the type of that atom. This is not true in the case
of *dgradflag* keyword = 1 (see below).
If the *dgradflag* keyword is set to 1, this changes the structure of the
global array completely.
Here the per-atom quantities are replaced with rows corresponding to
descriptor gradient components on single atoms:
.. math::
\frac{\partial {B_{i,\boldsymbol{\nu}} }}{\partial {r}^a_j}
where :math:`{r}^a_j` is the *a-th* position coordinate of the atom with global
index *j*. The rows are
organized in chunks, where each chunk corresponds to an atom with global index
:math:`j`. The rows in an atom :math:`j` chunk correspond to
atoms with global index :math:`i`. The total number of rows for
these descriptor gradients is therefore :math:`3N^2`.
The number of columns is equal to the number of ACE descriptors,
plus 3 additional left-most columns representing the global atom indices
:math:`i`, :math:`j`,
and Cartesian direction :math:`a` (0, 1, 2, for x, y, z).
The first 3 columns of the first :math:`N` rows belong to the reference
potential force components. The remaining K columns contain the
:math:`B_{i,\boldsymbol{\nu}}` per-atom descriptors corresponding to the non-zero entries
obtained when *bikflag* = 1.
The first column of the last row, after the first
:math:`N + 3N^2` rows, contains the reference potential
energy. The virial components are not used with this option. The total number of
rows is therefore :math:`N + 3N^2 + 1` and the number of columns is :math:`K + 3`.
These values can be accessed by any command that uses global values
from a compute as input. See the :doc:`Howto output <Howto_output>` doc
page for an overview of LAMMPS output options.
Restrictions
""""""""""""
These computes are part of the ML-PACE 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:`pair_style pace <pair_pace>`
:doc:`pair_style snap <pair_snap>`
:doc:`compute snap <compute_sna_atom>`
Default
"""""""
The optional keyword defaults are *bikflag* = 0,
*dgradflag* = 0
----------
.. _Drautz19:
**(Drautz)** Drautz, Phys Rev B, 99, 014104 (2019).
.. _Lysogorskiy21:
**(Lysogorskiy)** Lysogorskiy, van der Oord, Bochkarev, Menon, Rinaldi, Hammerschmidt, Mrovec, Thompson, Csanyi, Ortner, Drautz, npj Comp Mat, 7, 97 (2021).
.. _Goff23:
**(Goff)** Goff, Zhang, Negre, Rohskopf, Niklasson, Journal of Chemical Theory and Computation 19, no. 13 (2023).

92
doc/src/compute_rattlers_atom.rst Normal file
View File

@ -0,0 +1,92 @@
.. index:: compute rattlers/atom
compute rattlers/atom command
=============================
Syntax
""""""
.. parsed-literal::
compute ID group-ID rattlers/atom cutoff zmin ntries
* ID, group-ID are documented in :doc:`compute <compute>` command
* rattlers/atom = style name of this compute command
* cutoff = *type* or *radius*
.. parsed-literal::
*type* = cutoffs determined based on atom types
*radius* = cutoffs determined based on atom diameters (atom style sphere)
* zmin = minimum coordination for a non-rattler atom
* ntries = maximum number of iterations to remove rattlers
Examples
""""""""
.. code-block:: LAMMPS
compute 1 all rattlers/atom type 4 10
Description
"""""""""""
.. versionadded:: TBD
Define a compute that identifies rattlers in a system. Rattlers are often
identified in granular or glassy packings as under-coordinated atoms that
do not have the required number of contacts to constrain their translational
degrees of freedom. Such atoms are not considered rigid and can often freely
rattle around in the system. This compute identifies rattlers which can be
helpful for excluding them from analysis or providing extra damping forces
to accelerate relaxation processes.
Rattlers are identified using an interactive approach. The coordination
number of all atoms is first calculated. The *type* and *radius* settings
are used to select whether interaction cutoffs are determined by atom
types or by the sum of atomic radii (atom style sphere), respectively.
Rattlers are then identified as atoms with a coordination number less
than *zmin* and are removed from consideration. Atomic coordination
numbers are then recalculated, excluding previously identified rattlers,
to identify a new set of rattlers. This process is iterated up to a maximum
of *ntries* or until no new rattlers are identified and the remaining
atoms form a stable network of contacts.
In dense homogeneous systems where the average atom coordination number
is expected to be larger than *zmin*, this process usually only takes a few
iterations and a value of *ntries* around ten may be sufficient. In systems
with significant heterogeneity or average coordination numbers less than
*zmin*, an appropriate value of *ntries* depends heavily on the specific
system. For instance, a linear chain of N rattler atoms with a *zmin* of 2
would take N/2 iterations to identify that all the atoms are rattlers.
Output info
"""""""""""
This compute calculates a per-atom vector and a global scalar. The vector
designates which atoms are rattlers, indicated by a value 1. Non-rattlers
have a value of 0. The global scalar returns the total number of rattlers
in the system. See the :doc:`Howto output <Howto_output>` page for an
overview of LAMMPS output options.
Restrictions
""""""""""""
This compute is part of the EXTRA-COMPUTE package. It is only enabled if
LAMMPS was built with that package. See the
:doc:`Build package <Build_package>` page for more info.
The *radius* cutoff option requires that atoms store a radius as defined by the
:doc:`atom_style sphere <atom_style>` or similar commands.
Related commands
""""""""""""""""
:doc:`compute coord/atom <compute_coord_atom>`
:doc:`compute contact/atom <compute_contact_atom>`
Default
"""""""
none

97
doc/src/compute_reaxff_atom.rst Normal file
View File

@ -0,0 +1,97 @@
.. index:: compute reaxff/atom
.. index:: compute reaxff/atom/kk
compute reaxff/atom command
===========================
Accelerator Variants: *reaxff/atom/kk*
Syntax
""""""
.. code-block:: LAMMPS
compute ID group-ID reaxff/atom attribute args ... keyword value ...
* ID, group-ID are documented in :doc:`compute <compute>` command
* reaxff/atom = name of this compute command
* attribute = *pair*
.. parsed-literal::
*pair* args = nsub
nsub = *n*-instance of a sub-style, if a pair style is used multiple times in a hybrid style
* keyword = *bonds*
.. parsed-literal::
*bonds* value = *no* or *yes*
*no* = ignore list of local bonds
*yes* = include list of local bonds
Examples
""""""""
.. code-block:: LAMMPS
compute 1 all reaxff/atom bonds yes
Description
"""""""""""
.. versionadded:: TBD
Define a computation that extracts bond information computed by the ReaxFF
potential specified by :doc:`pair_style reaxff <pair_reaxff>`.
By default, it produces per-atom data that includes the following columns:
* abo = atom bond order (sum of all bonds)
* nlp = number of lone pairs
* nb = number of bonds
Bonds will only be included if its atoms are in the group.
In addition, if ``bonds`` is set to ``yes``, the compute will also produce a
local array of all bonds on the current processor whose atoms are in the group.
The columns of each entry of this local array are:
* id_i = atom i id of bond
* id_j = atom j id of bond
* bo = bond order of bond
Output info
"""""""""""
This compute calculates a per-atom array and local array depending on the
number of keywords. The number of rows in the local array is the number of
bonds as described above. Both per-atom and local array have 3 columns.
The arrays can be accessed by any command that uses local and per-atom values
from a compute as input. See the :doc:`Howto output <Howto_output>` page for
an overview of LAMMPS output options.
----------
.. include:: accel_styles.rst
----------
Restrictions
""""""""""""
The compute reaxff/atom command requires that the :doc:`pair_style reaxff
<pair_reaxff>` is invoked. This fix is part of the REAXFF package. It is only
enabled if LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
Related commands
""""""""""""""""
:doc:`pair_style reaxff <pair_reaxff>`
Default
"""""""
The option defaults are *bonds* = *no*.

2
doc/src/compute_saed.rst
View File

@ -68,7 +68,7 @@ reciprocal lattice nodes. The mesh spacing is defined either (a) by
the entire simulation domain or (b) manually using selected values as
shown in the 2D diagram below.
.. image:: img/saed_mesh.jpg
.. image:: img/saed_mesh.png
:scale: 75%
:align: center

162
doc/src/compute_slcsa_atom.rst Normal file
View File

@ -0,0 +1,162 @@
.. index:: compute slcsa/atom
compute slcsa/atom command
============================
Syntax
""""""
.. code-block:: LAMMPS
compute ID group-ID slcsa/atom twojmax nclasses db_mean_descriptor_file lda_file lr_decision_file lr_bias_file maha_file value
* ID, group-ID are documented in :doc:`compute <compute>` command
* slcsa/atom = style name of this compute command
* twojmax = band limit for bispectrum components (non-negative integer)
* nclasses = number of crystal structures used in the database for the classifier SL-CSA
* db_mean_descriptor_file = file name of file containing the database mean descriptor
* lda_file = file name of file containing the linear discriminant analysis matrix for dimension reduction
* lr_decision_file = file name of file containing the scaling matrix for logistic regression classification
* lr_bias_file = file name of file containing the bias vector for logistic regression classification
* maha_file = file name of file containing for each crystal structure: the Mahalanobis distance threshold for sanity check purposes, the average reduced descriptor and the inverse of the corresponding covariance matrix
* c_ID[*] = compute ID of previously required *compute sna/atom* command
Examples
""""""""
.. code-block:: LAMMPS
compute b1 all sna/atom 9.0 0.99363 8 0.5 1.0 rmin0 0.0 nnn 24 wmode 1 delta 0.3
compute b2 all slcsa/atom 8 4 mean_descriptors.dat lda_scalings.dat lr_decision.dat lr_bias.dat maha_thresholds.dat c_b1[*]
Description
"""""""""""
.. versionadded:: TBD
Define a computation that performs the Supervised Learning Crystal
Structure Analysis (SL-CSA) from :ref:`(Lafourcade) <Lafourcade2023_1>`
for each atom in the group. The SL-CSA tool takes as an input a per-atom
descriptor (bispectrum) that is computed through the *compute sna/atom*
command and then proceeds to a dimension reduction step followed by a
logistic regression in order to assign a probable crystal structure to
each atom in the group. The SL-CSA tool is pre-trained on a database
containing :math:`C` distinct crystal structures from which a crystal
structure classifier is derived and a tutorial to build such a tool is
available at `SL-CSA <https://github.com/lafourcadep/SL-CSA>`_.
The first step of the SL-CSA tool consists in performing a dimension
reduction of the per-atom descriptor :math:`\mathbf{B}^i \in
\mathbb{R}^{D}` through the Linear Discriminant Analysis (LDA) method,
leading to a new projected descriptor
:math:`\mathbf{x}^i=\mathrm{P}_\mathrm{LDA}(\mathbf{B}^i):\mathbb{R}^D
\rightarrow \mathbb{R}^{d=C-1}`:
.. math::
\mathbf{x}^i = \mathbf{C}^T_\mathrm{LDA} \cdot (\mathbf{B}^i - \mu^\mathbf{B}_\mathrm{db})
where :math:`\mathbf{C}^T_\mathrm{LDA} \in \mathbb{R}^{D \times d}` is
the reduction coefficients matrix of the LDA model read in file
*lda_file*, :math:`\mathbf{B}^i \in \mathbb{R}^{D}` is the bispectrum of
atom :math:`i` and :math:`\mu^\mathbf{B}_\mathrm{db} \in \mathbb{R}^{D}`
is the average descriptor of the entire database. The latter is computed
from the average descriptors of each crystal structure read from the
file *mean_descriptors_file*.
The new projected descriptor with dimension :math:`d=C-1` allows for a
good separation of different crystal structures fingerprints in the
latent space.
Once the dimension reduction step is performed by means of LDA, the new
descriptor :math:`\mathbf{x}^i \in \mathbb{R}^{d=C-1}` is taken as an
input for performing a multinomial logistic regression (LR) which
provides a score vector
:math:`\mathbf{s}^i=\mathrm{P}_\mathrm{LR}(\mathbf{x}^i):\mathbb{R}^d
\rightarrow \mathbb{R}^C` defined as:
.. math::
\mathbf{s}^i = \mathbf{b}_\mathrm{LR} + \mathbf{D}_\mathrm{LR} \cdot {\mathbf{x}^i}^T
with :math:`\mathbf{b}_\mathrm{LR} \in \mathbb{R}^C` and
:math:`\mathbf{D}_\mathrm{LR} \in \mathbb{R}^{C \times d}` the bias
vector and decision matrix of the LR model after training both read in
files *lr_fil1* and *lr_file2* respectively.
Finally, a probability vector
:math:`\mathbf{p}^i=\mathrm{P}_\mathrm{LR}(\mathbf{x}^i):\mathbb{R}^d
\rightarrow \mathbb{R}^C` is defined as:
.. math::
\mathbf{p}^i = \frac{\mathrm{exp}(\mathbf{s}^i)}{\sum\limits_{j} \mathrm{exp}(s^i_j) }
from which the crystal structure assigned to each atom with descriptor
:math:`\mathbf{B}^i` and projected descriptor :math:`\mathbf{x}^i` is
computed as the *argmax* of the probability vector
:math:`\mathbf{p}^i`. Since the logistic regression step systematically
attributes a crystal structure to each atom, a sanity check is needed to
avoid misclassification. To this end, a per-atom Mahalanobis distance to
each crystal structure *CS* present in the database is computed:
.. math::
d_\mathrm{Mahalanobis}^{i \rightarrow \mathrm{CS}} = \sqrt{(\mathbf{x}^i - \mathbf{\mu}^\mathbf{x}_\mathrm{CS})^\mathrm{T} \cdot \mathbf{\Sigma}^{-1}_\mathrm{CS} \cdot (\mathbf{x}^i - \mathbf{\mu}^\mathbf{x}_\mathrm{CS}) }
where :math:`\mathbf{\mu}^\mathbf{x}_\mathrm{CS} \in \mathbb{R}^{d}` is
the average projected descriptor of crystal structure *CS* in the
database and where :math:`\mathbf{\Sigma}_\mathrm{CS} \in \mathbb{R}^{d
\times d}` is the corresponding covariance matrix. Finally, if the
Mahalanobis distance to crystal structure *CS* for atom *i* is greater
than the pre-determined threshold, no crystal structure is assigned to
atom *i*. The Mahalanobis distance thresholds are read in file
*maha_file* while the covariance matrices are read in file
*covmat_file*.
The `SL-CSA <https://github.com/lafourcadep/SL-CSA>`_ framework provides
an automatic computation of the different matrices and thresholds
required for a proper classification and writes down all the required
files for calling the *compute slcsa/atom* command.
The *compute slcsa/atom* command requires that the :doc:`compute
sna/atom <compute_sna_atom>` command is called before as it takes the
resulting per-atom bispectrum as an input. In addition, it is crucial
that the value *twojmax* is set to the same value of the value *twojmax*
used in the *compute sna/atom* command, as well as that the value
*nclasses* is set to the number of crystal structures used in the
database to train the SL-CSA tool.
Output info
"""""""""""
By default, this compute computes the Mahalanobis distances to the
different crystal structures present in the database in addition to
assigning a crystal structure for each atom as a per-atom vector, which
can be accessed by any command that uses per-atom values from a compute
as input. See the :doc:`Howto output <Howto_output>` page for an
overview of LAMMPS output options.
Restrictions
""""""""""""
This compute is part of the EXTRA-COMPUTE package. It is only enabled
if LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
Related commands
""""""""""""""""
:doc:`compute sna/atom <compute_sna_atom>`
Default
"""""""
none
----------
.. _Lafourcade2023_1:
**(Lafourcade)** Lafourcade, Maillet, Denoual, Duval, Allera, Goryaeva, and Marinica,
`Comp. Mat. Science, 230, 112534 (2023) <https://doi.org/10.1016/j.commatsci.2023.112534>`_

39
doc/src/compute_sna_atom.rst
View File

@ -45,7 +45,7 @@ Syntax
* w_1, w_2,... = list of neighbor weights, one for each type
* nx, ny, nz = number of grid points in x, y, and z directions (positive integer)
* zero or more keyword/value pairs may be appended
* keyword = *rmin0* or *switchflag* or *bzeroflag* or *quadraticflag* or *chem* or *bnormflag* or *wselfallflag* or *bikflag* or *switchinnerflag* or *sinner* or *dinner* or *dgradflag*
* keyword = *rmin0* or *switchflag* or *bzeroflag* or *quadraticflag* or *chem* or *bnormflag* or *wselfallflag* or *bikflag* or *switchinnerflag* or *sinner* or *dinner* or *dgradflag* or *nnn* or *wmode* or *delta*
.. parsed-literal::
@ -82,6 +82,16 @@ Syntax
*0* = descriptor gradients are summed over atoms of each type
*1* = descriptor gradients are listed separately for each atom pair
* additional keyword = *nnn* or *wmode* or *delta*
.. parsed-literal::
*nnn* value = number of considered nearest neighbors to compute the bispectrum over a target specific number of neighbors (only implemented for compute sna/atom)
*wmode* value = weight function for finding optimal cutoff to match the target number of neighbors (required if nnn used, only implemented for compute sna/atom)
*0* = heavyside weight function
*1* = hyperbolic tangent weight function
*delta* value = transition interval centered at cutoff distance for hyperbolic tangent weight function (ignored if wmode=0, required if wmode=1, only implemented for compute sna/atom)
Examples
""""""""
@ -94,6 +104,7 @@ Examples
compute snap all snap 1.0 0.99363 6 3.81 3.83 1.0 0.93 chem 2 0 1
compute snap all snap 1.0 0.99363 6 3.81 3.83 1.0 0.93 switchinnerflag 1 sinner 1.35 1.6 dinner 0.25 0.3
compute bgrid all sna/grid/local 200 200 200 1.4 0.95 6 2.0 1.0
compute bnnn all sna/atom 9.0 0.99363 8 0.5 1.0 rmin0 0.0 nnn 24 wmode 1 delta 0.2
Description
"""""""""""
@ -433,6 +444,25 @@ requires that *bikflag=1*.
The rerun script can use a :doc:`special_bonds <special_bonds>`
command that includes all pairs in the neighbor list.
The keyword *nnn* allows for the calculation of the bispectrum over a
specific target number of neighbors. This option is only implemented for
the compute *sna/atom*\ . An optimal cutoff radius for defining the
neighborhood of the central atom is calculated by means of a dichotomy
algorithm. This iterative process allows to assign weights to
neighboring atoms in order to match the total sum of weights with the
target number of neighbors. Depending on the radial weight function
used in that process, the cutoff radius can fluctuate a lot in the
presence of thermal noise. Therefore, in addition to the *nnn* keyword,
the keyword *wmode* allows to choose whether a Heaviside (*wmode* = 0)
function or a Hyperbolic tangent function (*wmode* = 1) should be used.
If the Heaviside function is used, the cutoff radius exactly matches the
distance between the central atom an its *nnn*'th neighbor. However, in
the case of the hyperbolic tangent function, the dichotomy algorithm
allows to span the weights over a distance *delta* in order to reduce
fluctuations in the resulting local atomic environment fingerprint. The
detailed formalism is given in the paper by Lafourcade et
al. :ref:`(Lafourcade) <Lafourcade2023_2>`.
----------
Output info
@ -585,6 +615,7 @@ Related commands
""""""""""""""""
:doc:`pair_style snap <pair_snap>`
:doc:`compute slcsa/atom <compute_slcsa_atom>`
Default
"""""""
@ -592,6 +623,7 @@ Default
The optional keyword defaults are *rmin0* = 0,
*switchflag* = 1, *bzeroflag* = 1, *quadraticflag* = 0,
*bnormflag* = 0, *wselfallflag* = 0, *switchinnerflag* = 0,
*nnn* = -1, *wmode* = 0, *delta* = 1.e-3
----------
@ -623,3 +655,8 @@ of Angular Momentum, World Scientific, Singapore (1987).
.. _Ellis2021:
**(Ellis)** Ellis, Fiedler, Popoola, Modine, Stephens, Thompson, Cangi, Rajamanickam, Phys Rev B, 104, 035120, (2021)
.. _Lafourcade2023_2:
**(Lafourcade)** Lafourcade, Maillet, Denoual, Duval, Allera, Goryaeva, and Marinica,
`Comp. Mat. Science, 230, 112534 (2023) <https://doi.org/10.1016/j.commatsci.2023.112534>`_

10
doc/src/compute_stress_atom.rst
View File

@ -127,11 +127,11 @@ result in more consistent heat flux values for angle, dihedrals,
improper and constraint force contributions
when computed via :doc:`compute heat/flux <compute_heat_flux>`.
If no extra keywords are listed, the kinetic contribution all of the
virial contribution terms are included in the per-atom stress tensor.
If any extra keywords are listed, only those terms are summed to
compute the tensor. The *virial* keyword means include all terms
except the kinetic energy *ke*\ .
If no extra keywords are listed, the kinetic contribution *and* all
of the virial contribution terms are included in the per-atom stress
tensor. If any extra keywords are listed, only those terms are
summed to compute the tensor. The *virial* keyword means include all
terms except the kinetic energy *ke*\ .
Note that the stress for each atom is due to its interaction with all
other atoms in the simulation, not just with other atoms in the group.

21
doc/src/compute_stress_mop.rst
View File

@ -18,7 +18,7 @@ Syntax
* style = *stress/mop* or *stress/mop/profile*
* dir = *x* or *y* or *z* is the direction normal to the plane
* args = argument specific to the compute style
* keywords = *kin* or *conf* or *total* or *pair* or *bond* or *angle* (one or more can be specified)
* keywords = *kin* or *conf* or *total* or *pair* or *bond* or *angle* or *dihedral* (one or more can be specified)
.. parsed-literal::
@ -68,15 +68,13 @@ Verlet algorithm.
.. versionadded:: 15Jun2023
contributions from bond and angle potentials
contributions from bond, angle and dihedral potentials
Between one and six keywords can be used to indicate which contributions
Between one and seven keywords can be used to indicate which contributions
to the stress must be computed: total stress (total), kinetic stress
(kin), configurational stress (conf), stress due to bond stretching
(bond), stress due to angle bending (angle) and/or due to pairwise
non-bonded interactions (pair). The angle keyword is currently
available only for the *stress/mop* command and **not** the
*stress/mop/profile* command.
(bond), stress due to angle bending (angle), stress due to dihedral terms (dihedral)
and/or due to pairwise non-bonded interactions (pair).
NOTE 1: The configurational stress is computed considering all pairs of
atoms where at least one atom belongs to group group-ID.
@ -134,14 +132,9 @@ size does not change in time, and axis-aligned planes.
The method only works with two-body pair interactions, because it
requires the class method ``Pair::single()`` to be implemented, which is
not possible for manybody potentials. In particular, compute
*stress/mop/profile* does not work with more than two-body pair
*stress/mop/profile* and *stress/mop* do not work with more than two-body pair
interactions, long range (kspace) interactions and
angle/dihedral/improper intramolecular interactions. Similarly, compute
*stress/mop* does not work with more than two-body pair interactions,
long range (kspace) interactions and dihedral/improper intramolecular
interactions but works with all bond interactions with the class method
single() implemented and all angle interactions with the class method
born_matrix() implemented.
improper intramolecular interactions.
Related commands
""""""""""""""""

7
doc/src/dihedral_charmm.rst
View File

@ -3,6 +3,7 @@
.. index:: dihedral_style charmm/kk
.. index:: dihedral_style charmm/omp
.. index:: dihedral_style charmmfsw
.. index:: dihedral_style charmmfsw/kk
dihedral_style charmm command
=============================
@ -12,6 +13,8 @@ Accelerator Variants: *charmm/intel*, *charmm/kk*, *charmm/omp*
dihedral_style charmmfsw command
================================
Accelerator Variants: *charmmfsw/kk*
Syntax
""""""
@ -144,7 +147,9 @@ for more info.
Related commands
""""""""""""""""
:doc:`dihedral_coeff <dihedral_coeff>`
:doc:`dihedral_coeff <dihedral_coeff>`,
:doc:`pair_style lj/charmm variants <pair_charmm>`,
:doc:`angle_style charmm <angle_charmm>`, :doc:`fix cmap <fix_cmap>`
Default
"""""""

1
doc/src/fix.rst
View File

@ -287,6 +287,7 @@ accelerated styles exist.
* :doc:`mvv/tdpd <fix_mvv_dpd>` - constant temperature DPD using the modified velocity-Verlet algorithm
* :doc:`neb <fix_neb>` - nudged elastic band (NEB) spring forces
* :doc:`neb/spin <fix_neb_spin>` - nudged elastic band (NEB) spring forces for spins
* :doc:`nonaffine/displacement <fix_nonaffine_displacement>` - calculate nonaffine displacement of atoms
* :doc:`nph <fix_nh>` - constant NPH time integration via Nose/Hoover
* :doc:`nph/asphere <fix_nph_asphere>` - NPH for aspherical particles
* :doc:`nph/body <fix_nph_body>` - NPH for body particles

2
doc/src/fix_adapt.rst
View File

@ -221,7 +221,7 @@ formulas for the meaning of these parameters:
+------------------------------------------------------------------------------+--------------------------------------------------+-------------+
| :doc:`table <pair_table>` | table_cutoff | type pairs |
+------------------------------------------------------------------------------+--------------------------------------------------+-------------+
| :doc:`ufm <pair_ufm>` | epsilon,sigma | type pairs |
| :doc:`ufm <pair_ufm>` | epsilon,sigma,scale | type pairs |
+------------------------------------------------------------------------------+--------------------------------------------------+-------------+
| :doc:`wf/cut <pair_wf_cut>` | epsilon,sigma,nu,mu | type pairs |
+------------------------------------------------------------------------------+--------------------------------------------------+-------------+

20
doc/src/fix_adapt_fep.rst
View File

@ -123,19 +123,29 @@ styles and their energy formulas for the meaning of these parameters:
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`born <pair_born>` | a,b,c | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`born/gauss <pair_born_gauss>` | biga0,biga1,r0 | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`buck, buck/coul/cut, buck/coul/long, buck/coul/msm <pair_buck>` | a,c | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`buck/mdf <pair_mdf>` | a,c | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`coul/cut <pair_coul>` | scale | type pairs |
| :doc:`coul/cut, coul/cut/global <pair_coul>` | scale | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`coul/cut/soft <pair_fep_soft>` | lambda | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`coul/debye <pair_coul>` | scale | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`coul/long, coul/msm <pair_coul>` | scale | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`coul/long/soft <pair_fep_soft>` | scale, lambda | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`eam <pair_eam>` | scale | type pairs |
| :doc:`coul/slater/long <pair_coul_slater>` | scale | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`coul/streitz <pair_coul>` | scale | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`eam, eam/alloy, eam/fs <pair_eam>` | scale | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`harmonic/cut <pair_harmonic_cut>` | k | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`gauss <pair_gauss>` | a | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
@ -163,6 +173,8 @@ styles and their energy formulas for the meaning of these parameters:
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`lj/sf/dipole/sf <pair_dipole>` | epsilon,sigma,scale | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`meam <pair_meam>` | scale | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`mie/cut <pair_mie>` | epsilon,sigma,gamR,gamA | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`morse, morse/smooth/linear <pair_morse>` | d0,r0,alpha | type pairs |
@ -173,12 +185,16 @@ styles and their energy formulas for the meaning of these parameters:
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`nm/cut/coul/cut, nm/cut/coul/long <pair_nm>` | e0,r0,nn,mm | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`pace, pace/extrapolation <pair_pace>` | scale | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`snap <pair_snap>` | scale | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`soft <pair_soft>` | a | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`ufm <pair_ufm>` | epsilon,sigma,scale | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
| :doc:`wf/cut <pair_wf_cut>` | epsilon,sigma,nu,mu | type pairs |
+------------------------------------------------------------------------------+-------------------------+------------+
.. note::

2
doc/src/fix_halt.rst
View File

@ -183,4 +183,4 @@ Related commands
Default
"""""""
The option defaults are error = hard, message = yes, and path = ".".
The option defaults are error = soft, message = yes, and path = ".".

96
doc/src/fix_neb.rst
View File

@ -109,7 +109,7 @@ Note that in this case the specified *Kspring* is in
force/distance units.
With a value of *ideal*, the spring force is computed as suggested in
ref`(WeinanE) <WeinanE>`
:ref:`(WeinanE) <WeinanE>`
.. math::
@ -120,18 +120,18 @@ and :math:`RD_{ideal}` is the ideal *RD* for which all the images are
equally spaced. I.e. :math:`RD_{ideal} = (i-1) \cdot meanDist` when the
climbing replica is off, where *i* is the replica number). The
*meanDist* is the average distance between replicas. Note that in this
case the specified *Kspring* is in force units. When the climbing replica
is on, :math:`RD_{ideal}` and :math:`meanDist` are calculated separately
each side of the climbing image. Note that the *ideal* form of nudging
can often be more effective at keeping the replicas equally spaced before
climbing, then equally spaced either side of the climbing image whilst
climbing.
case the specified *Kspring* is in force units. When the climbing
replica is on, :math:`RD_{ideal}` and :math:`meanDist` are calculated
separately each side of the climbing image. Note that the *ideal* form
of nudging can often be more effective at keeping the replicas equally
spaced before climbing, then equally spaced either side of the climbing
image whilst climbing.
With a value of *equal* the spring force is computed as for *ideal*
when the climbing replica is off, promoting equidistance. When the climbing
With a value of *equal* the spring force is computed as for *ideal* when
the climbing replica is off, promoting equidistance. When the climbing
replica is on, the spring force is computed to promote equidistant
absolute differences in energy, rather than distance, each side of
the climbing image:
absolute differences in energy, rather than distance, each side of the
climbing image:
.. math::
@ -143,23 +143,22 @@ where *ED* is the cumulative sum of absolute energy differences:
ED = \sum_{i<N} \left|E(R_{i+1}) - E(R_i)\right|,
*meanEdist* is the average absolute energy difference between
replicas up to the climbing image or from the climbing image
to the final image, for images before or after the climbing
image respectively. :math:`ED_{ideal}` is the corresponding
cumulative sum of average absolute energy differences in
each case, in close analogy to *ideal*. This form of nudging
is to aid schemes which integrate forces along, or near to,
NEB pathways such as :doc:`fix_pafi <fix_pafi>`.
*meanEdist* is the average absolute energy difference between replicas
up to the climbing image or from the climbing image to the final image,
for images before or after the climbing image
respectively. :math:`ED_{ideal}` is the corresponding cumulative sum of
average absolute energy differences in each case, in close analogy to
*ideal*. This form of nudging is to aid schemes which integrate forces
along, or near to, NEB pathways such as :doc:`fix_pafi <fix_pafi>`.
----------
The keyword *perp* specifies if and how a perpendicular nudging force
is computed. It adds a spring force perpendicular to the path in
order to prevent the path from becoming too strongly kinked. It can
The keyword *perp* specifies if and how a perpendicular nudging force is
computed. It adds a spring force perpendicular to the path in order to
prevent the path from becoming too strongly kinked. It can
significantly improve the convergence of the NEB calculation when the
resolution is poor. I.e. when few replicas are used; see
:ref:`(Maras) <Maras1>` for details.
resolution is poor. I.e. when few replicas are used; see :ref:`(Maras)
<Maras1>` for details.
The perpendicular spring force is given by
@ -181,10 +180,10 @@ force is added.
By default, no additional forces act on the first and last replicas
during the NEB relaxation, so these replicas simply relax toward their
respective local minima. By using the key word *end*, additional
forces can be applied to the first and/or last replicas, to enable
them to relax toward a MEP while constraining their energy E to the
target energy ETarget.
respective local minima. By using the key word *end*, additional forces
can be applied to the first and/or last replicas, to enable them to
relax toward a MEP while constraining their energy E to the target
energy ETarget.
If :math:`E_{Target} > E`, the interatomic force :math:`F_i` for the
specified replica becomes:
@ -197,33 +196,33 @@ specified replica becomes:
The "spring" constant on the difference in energies is the specified
*Kspring3* value.
When *estyle* is specified as *first*, the force is applied to the
first replica. When *estyle* is specified as *last*, the force is
applied to the last replica. Note that the *end* keyword can be used
twice to add forces to both the first and last replicas.
When *estyle* is specified as *first*, the force is applied to the first
replica. When *estyle* is specified as *last*, the force is applied to
the last replica. Note that the *end* keyword can be used twice to add
forces to both the first and last replicas.
For both these *estyle* settings, the target energy *ETarget* is set
to the initial energy of the replica (at the start of the NEB
calculation).
If the *estyle* is specified as *last/efirst* or *last/efirst/middle*,
force is applied to the last replica, but the target energy *ETarget*
is continuously set to the energy of the first replica, as it evolves
force is applied to the last replica, but the target energy *ETarget* is
continuously set to the energy of the first replica, as it evolves
during the NEB relaxation.
The difference between these two *estyle* options is as follows. When
*estyle* is specified as *last/efirst*, no change is made to the
inter-replica force applied to the intermediate replicas (neither
first or last). If the initial path is too far from the MEP, an
intermediate replica may relax "faster" and reach a lower energy than
the last replica. In this case the intermediate replica will be
relaxing toward its own local minima. This behavior can be prevented
by specifying *estyle* as *last/efirst/middle* which will alter the
inter-replica force applied to intermediate replicas by removing the
contribution of the gradient to the inter-replica force. This will
only be done if a particular intermediate replica has a lower energy
than the first replica. This should effectively prevent the
intermediate replicas from over-relaxing.
inter-replica force applied to the intermediate replicas (neither first
or last). If the initial path is too far from the MEP, an intermediate
replica may relax "faster" and reach a lower energy than the last
replica. In this case the intermediate replica will be relaxing toward
its own local minima. This behavior can be prevented by specifying
*estyle* as *last/efirst/middle* which will alter the inter-replica
force applied to intermediate replicas by removing the contribution of
the gradient to the inter-replica force. This will only be done if a
particular intermediate replica has a lower energy than the first
replica. This should effectively prevent the intermediate replicas from
over-relaxing.
After converging a NEB calculation using an *estyle* of
*last/efirst/middle*, you should check that all intermediate replicas
@ -237,9 +236,10 @@ target energy.
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
No information about this fix is written to :doc:`binary restart files <restart>`. None of the :doc:`fix_modify <fix_modify>` options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various :doc:`output commands <Howto_output>`.
No information about this fix is written to :doc:`binary restart files
<restart>`. None of the :doc:`fix_modify <fix_modify>` options are
relevant to this fix. No global or per-atom quantities are stored by
this fix for access by various :doc:`output commands <Howto_output>`.
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command.

4
doc/src/fix_nh_uef.rst
View File

@ -23,7 +23,7 @@ Syntax
.. parsed-literal::
keyword = *erate* or *ext* or *strain* or *temp* or *iso* or *x* or *y* or *z* or *tchain* or *pchain* or *tloop* or *ploop* or *mtk*
*erate* values = e_x e_y = engineering strain rates (required)
*erate* values = e_x e_y = true strain rates (required)
*ext* value = *x* or *y* or *z* or *xy* or *yz* or *xz* = external dimensions
sets the external dimensions used to calculate the scalar pressure
*strain* values = e_x e_y = initial strain
@ -62,7 +62,7 @@ performed using the :doc:`fix deform <fix_deform>`, :doc:`fix nvt/sllod
<fix_nvt_sllod>`, and :doc:`compute temp/deform <compute_temp_deform>`
commands.
The applied flow field is set by the *eps* keyword. The values
The applied flow field is set by the *erate* keyword. The values
*edot_x* and *edot_y* correspond to the strain rates in the xx and yy
directions. It is implicitly assumed that the flow field is
traceless, and therefore the strain rate in the zz direction is eqal

133
doc/src/fix_nonaffine_displacement.rst Normal file
View File

@ -0,0 +1,133 @@
.. index:: fix nonaffine/displacement
fix nonaffine/displacement command
==================================
Syntax
""""""
.. parsed-literal::
fix ID group nonaffine/displacement style args reference/style nstep
* ID, group are documented in :doc:`fix <fix>` command
* nonaffine/displacement = style name of this fix command
* nevery = calculate nonaffine displacement every this many timesteps
* style = *d2min* or *integrated*
.. parsed-literal::
*d2min* args = cutoff args
cutoff = *type* or *radius* or *custom*
*type* args = none, cutoffs determined by atom types
*radius* args = none, cutoffs determined based on atom diameters (atom style sphere)
*custom* args = *rmax*, cutoff set by a constant numeric value *rmax* (distance units)
*integrated* args = none
* reference/style = *fixed* or *update* or *offset*
.. parsed-literal::
*fixed* = use a fixed reference frame at *nstep*
*update* = update the reference frame every *nstep* timesteps
*offset* = update the reference frame *nstep* timesteps before calculating the nonaffine displacement
Examples
""""""""
.. code-block:: LAMMPS
fix 1 all nonaffine/displacement 100 integrated update 100
fix 1 all nonaffine/displacement 1000 d2min type fixed 0
fix 1 all nonaffine/displacement 1000 d2min custom 2.0 offset 100
Description
"""""""""""
.. versionadded:: TBD
This fix computes different metrics of the nonaffine displacement of
particles. The first metric, *d2min* calculates the :math:`D^2_\mathrm{min}`
nonaffine displacement by Falk and Langer in :ref:`(Falk) <d2min-Falk>`.
For each atom, the fix computes the two tensors
.. math::
X = \sum_{\mathrm{neighbors}} \vec{r} \left(\vec{r}_{0} \right)^T
and
.. math::
Y = \sum_{\mathrm{neighbors}} \vec{r}_0 \left(\vec{r}_{0} \right)^T
where the neighbors include all other atoms within the distance criterion
set by the cutoff option, discussed below, :math:`\vec{r}` is the current
displacement between particles, and :math:`\vec{r}_0` is the reference
displacement. A deformation gradient tensor is then calculated as
:math:`F = X Y^{-1}` from which
.. math::
D^2_\mathrm{min} = \sum_{\mathrm{neighbors}} \left| \vec{r} - F \vec{r}_0 \right|^2
and a strain tensor is calculated :math:`E = F F^{T} - I` where :math:`I`
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.
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
atom positions such as :doc:`fix deform <fix_deform>` with remap x,
:doc:`fix press/berendsen <fix_press_berendsen>`, or :doc:`fix nh <fix_nh>`.
Both of these methods require defining a reference state. With the *fixed* reference
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.
----------
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
The reference state is saved to :doc:`binary restart files <restart>`.
None of the :doc:`fix_modify <fix_modify>` options are relevant to this
fix.
This fix computes a peratom array with 3 columns, which can be accessed
by indices 1-3 using any command that uses per-atom values from a fix
as input.
For the *integrated* style, the three columns are the nonaffine
displacements in the x, y, and z directions. For the *d2min* style,
the three columns are the calculated :math:`\sqrt{D^2_\mathrm{min}}`, the
volumetric strain, and the deviatoric strain.
Restrictions
""""""""""""
This compute 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.
Related commands
""""""""""""""""
none
Default
"""""""
none
----------
.. _d2min-Falk:
**(Falk)** Falk and Langer PRE, 57, 7192 (1998).

8
doc/src/fix_phonon.rst
View File

@ -181,10 +181,10 @@ This fix assumes a crystalline system with periodical lattice. The
temperature of the system should not exceed the melting temperature to
keep the system in its solid state.
This fix is part of the PHONON package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
This fix requires LAMMPS be built with an FFT library. See the :doc:`Build settings <Build_settings>` page for details.
This fix is part of the PHONON package. It is only enabled if LAMMPS
was built with that package. This fix also requires LAMMPS to be built
with 3d-FFT support which is included in the KSPACE package. See the
:doc:`Build package <Build_package>` page for more info.
Related commands
""""""""""""""""

2
doc/src/fix_qeq.rst
View File

@ -232,8 +232,6 @@ These fixes are part of the QEQ package. They are only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
These qeq fixes are not compatible with the GPU and USER-INTEL packages.
These qeq fixes will ignore electric field contributions from
:doc:`fix efield <fix_efield>`.

4
doc/src/fix_rigid.rst
View File

@ -80,7 +80,7 @@ Syntax
groupID1, groupID2, ... = list of N group IDs
* zero or more keyword/value pairs may be appended
* keyword = *langevin* or *reinit* or *temp* or *iso* or *aniso* or *x* or *y* or *z* or *couple* or *tparam* or *pchain* or *dilate* or *force* or *torque* or *infile* or *gravity*
* keyword = *langevin* or *reinit* or *temp* or *mol* or *iso* or *aniso* or *x* or *y* or *z* or *couple* or *tparam* or *pchain* or *dilate* or *force* or *torque* or *infile* or *gravity*
.. parsed-literal::
@ -92,6 +92,8 @@ Syntax
*temp* values = Tstart Tstop Tdamp
Tstart,Tstop = desired temperature at start/stop of run (temperature units)
Tdamp = temperature damping parameter (time units)
*mol* value = template-ID
template-ID = ID of molecule template specified in a separate :doc:`molecule <molecule>` command
*iso* or *aniso* values = Pstart Pstop Pdamp
Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
Pdamp = pressure damping parameter (time units)

7
doc/src/fix_temp_berendsen.rst
View File

@ -1,8 +1,11 @@
.. index:: fix temp/berendsen
.. index:: fix temp/berendsen/kk
fix temp/berendsen command
==========================
Accelerator Variants: *temp/berendsen/kk*
Syntax
""""""
@ -118,6 +121,10 @@ remaining thermal degrees of freedom, and the bias is added back in.
----------
.. include:: accel_styles.rst
----------
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

7
doc/src/fix_temp_rescale.rst
View File

@ -1,8 +1,11 @@
.. index:: fix temp/rescale
.. index:: fix temp/rescale/kk
fix temp/rescale command
========================
Accelerator Variants: *temp/rescale/kk*
Syntax
""""""
@ -125,6 +128,10 @@ remaining thermal degrees of freedom, and the bias is added back in.
----------
.. include:: accel_styles.rst
----------
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

BIN
doc/src/img/saed_mesh.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 108 KiB

BIN
doc/src/img/saed_mesh.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 90 KiB

202
doc/src/molecule.rst
View File

@ -126,14 +126,50 @@ molecule (header keyword = inertia).
Format of a molecule file
"""""""""""""""""""""""""
The format of an individual molecule file is similar but
(not identical) to the data file read by the :doc:`read_data <read_data>`
commands, and is as follows.
The format of an individual molecule file looks similar but is
different than that of a data file read by the :doc:`read_data <read_data>`
commands. Here is a simple example for a TIP3P water molecule:
.. code-block::
# Water molecule. TIP3P geometry
# header section:
3 atoms
2 bonds
1 angles
# body section:
Coords
1 0.00000 -0.06556 0.00000
2 0.75695 0.52032 0.00000
3 -0.75695 0.52032 0.00000
Types
1 1 # O
2 2 # H
3 2 # H
Charges
1 -0.834
2 0.417
3 0.417
Bonds
1 1 1 2
2 1 1 3
Angles
1 1 2 1 3
A molecule file has a header and a body. The header appears first. The
first line of the header and thus of the molecule file is *always* skipped;
it typically contains a description of the file or a comment from the software
that created the file.
first line of the header and thus of the molecule file is *always*
skipped; it typically contains a description of the file or a comment
from the software that created the file.
Then lines are read one line at a time. Lines can have a trailing
comment starting with '#' that is ignored. There *must* be at least one
@ -154,25 +190,66 @@ These are the recognized header keywords. Header lines can come in
any order. The numeric value(s) are read from the beginning of the
line. The keyword should appear at the end of the line. All these
settings have default values, as explained below. A line need only
appear if the value(s) are different than the default.
appear if the value(s) are different than the default, except when
defining a *body* particle, which requires setting the number of
*atoms* to 1, and setting the *inertia* in a specific section (see below).
* N *atoms* = # of atoms N in molecule, default = 0
* Nb *bonds* = # of bonds Nb in molecule, default = 0
* Na *angles* = # of angles Na in molecule, default = 0
* Nd *dihedrals* = # of dihedrals Nd in molecule, default = 0
* Ni *impropers* = # of impropers Ni in molecule, default = 0
* Nf *fragments* = # of fragments in molecule, default = 0
* Mtotal *mass* = total mass of molecule
* Xc Yc Zc *com* = coordinates of center-of-mass of molecule
* Ixx Iyy Izz Ixy Ixz Iyz *inertia* = 6 components of inertia tensor of molecule
.. list-table::
:header-rows: 1
:widths: auto
For *mass*, *com*, and *inertia*, the default is for LAMMPS to
calculate this quantity itself if needed, assuming the molecules
consists of a set of point particles or finite-size particles (with a
non-zero diameter) that do not overlap. If finite-size particles in
the molecule do overlap, LAMMPS will not account for the overlap
effects when calculating any of these 3 quantities, so you should
pre-compute them yourself and list the values in the file.
* - Number(s)
- Keyword
- Meaning
- Default Value
* - N
- atoms
- # of atoms N in molecule
- 0
* - Nb
- bonds
- # of bonds Nb in molecule
- 0
* - Na
- angles
- # of angles Na in molecule
- 0
* - Nd
- dihedrals
- # of dihedrals Nd in molecule
- 0
* - Ni
- impropers
- # of impropers Ni in molecule
- 0
* - Nf
- fragments
- # of fragments Nf in molecule
- 0
* - Ninteger Ndouble
- body
- # of integer and floating-point values in body particle
- 0
* - Mtotal
- mass
- total mass of molecule
- computed
* - Xc Yc Zc
- com
- coordinates of center-of-mass of molecule
- computed
* - Ixx Iyy Izz Ixy Ixz Iyz
- inertia
- 6 components of inertia tensor of molecule
- computed
For *mass*, *com*, and *inertia*, the default is for LAMMPS to calculate
this quantity itself if needed, assuming the molecules consist of a set
of point particles or finite-size particles (with a non-zero diameter)
that do **not** overlap. If finite-size particles in the molecule
**do** overlap, LAMMPS will not account for the overlap effects when
calculating any of these 3 quantities, so you should pre-compute them
yourself and list the values in the file.
The mass and center-of-mass coordinates (Xc,Yc,Zc) are
self-explanatory. The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz)
@ -184,10 +261,11 @@ internally.
These are the allowed section keywords for the body of the file.
* *Coords, Types, Molecules, Fragments, Charges, Diameters, Masses* = atom-property sections
* *Coords, Types, Molecules, Fragments, Charges, Diameters, Dipoles, Masses* = atom-property sections
* *Bonds, Angles, Dihedrals, Impropers* = molecular topology sections
* *Special Bond Counts, Special Bonds* = special neighbor info
* *Shake Flags, Shake Atoms, Shake Bond Types* = SHAKE info
* *Body Integers, Body Doubles* = body-property sections
For the Types, Bonds, Angles, Dihedrals, and Impropers sections, each
atom/bond/angle/etc type can be specified either as a number (numeric
@ -298,6 +376,21 @@ not listed, the default diameter of each atom in the molecule is 1.0.
----------
.. versionadded:: TBD
*Dipoles* section:
* one line per atom
* line syntax: ID mux muy muz
* mux,muy,muz = x-, y-, and z-component of point dipole vector of atom
This section is only allowed for :doc:`atom styles <atom_style>` that
support particles with point dipoles, e.g. atom_style dipole. If not
listed, the default dipole component of each atom in the molecule is set
to 0.0.
----------
*Masses* section:
* one line per atom
@ -515,6 +608,67 @@ of SHAKE clusters.
----------
*Body Integers* section:
* one line
* line syntax: N E F
* N = number of sub-particles or number or vertices
* E,F = number of edges and faces
This section is only needed when the molecule is a body particle. the other
Body section must also appear in the file.
The total number of values that must appear is determined by the body style, and
must be equal to the Ninteger value given in the *body* header.
For *nparticle* and *rounded/polygon*, only the number of sub-particles or
vertices N is required, and Ninteger should have a value of 1.
For *rounded/polyhedron*, the number of edges E and faces F is required, and
Ninteger should have a value of 3.
See the :doc:`Howto body <Howto_body>` page for a further description of
the file format.
----------
*Body Doubles* section:
* first line
* line syntax: Ixx Iyy Izz Ixy Ixz Iyz
* Ixx Iyy Izz Ixy Ixz Iyz = 6 components of inertia tensor of body particle
* one line per sub-particle or vertex
* line syntax: x y z
* x, y, z = coordinates of sub-particle or vertex
* one line per edge
* line syntax: N1 N2
* N1, N2 = vertex indices
* one line per face
* line syntax: N1 N2 N3 N4
* N1, N2, N3, N4 = vertex indices
* last line
* line syntax: diam
* diam = rounded diameter that surrounds each vertex
This section is only needed when the molecule is a body particle. the other
Body section must also appear in the file.
The total number of values that must appear is determined by the body style, and
must be equal to the Ndouble value given in the *body* header. The 6 moments of
inertia and the 3N coordinates of the sub-particles or vertices are required
for all body styles.
For *rounded/polygon*, the E = 6 + 3*N + 1 edges are automatically determined
from the vertices.
For *rounded/polyhedron*, the 2E vertex indices for the end points of the edges
and 4F vertex indices defining the faces are required.
See the :doc:`Howto body <Howto_body>` page for a further description of
the file format.
----------
Restrictions
""""""""""""

13
doc/src/neb.rst
View File

@ -10,7 +10,7 @@ Syntax
neb etol ftol N1 N2 Nevery file-style arg keyword values
* etol = stopping tolerance for energy (energy units)
* etol = stopping tolerance for energy (dimensionless)
* ftol = stopping tolerance for force (force units)
* N1 = max # of iterations (timesteps) to run initial NEB
* N2 = max # of iterations (timesteps) to run barrier-climbing NEB
@ -89,10 +89,11 @@ potentials, and the starting configuration when the neb command is
issued should be the same for every replica.
In a NEB calculation each replica is connected to other replicas by
inter-replica nudging forces. These forces are imposed by the :doc:`fix neb <fix_neb>` command, which must be used in conjunction with the
neb command. The group used to define the fix neb command defines the
NEB atoms which are the only ones that inter-replica springs are
applied to. If the group does not include all atoms, then non-NEB
inter-replica nudging forces. These forces are imposed by the
:doc:`fix neb <fix_neb>` command, which must be used in conjunction
with the neb command. The group used to define the fix neb command
defines the NEB atoms which are the only ones that inter-replica springs
are applied to. If the group does not include all atoms, then non-NEB
atoms have no inter-replica springs and the forces they feel and their
motion is computed in the usual way due only to other atoms within
their replica. Conceptually, the non-NEB atoms provide a background
@ -445,7 +446,7 @@ Related commands
""""""""""""""""
:doc:`prd <prd>`, :doc:`temper <temper>`, :doc:`fix langevin <fix_langevin>`,
:doc:`fix viscous <fix_viscous>`
:doc:`fix viscous <fix_viscous>`, :doc:`fix neb <fix_neb>`
Default
"""""""

26
doc/src/package.rst
View File

@ -344,12 +344,10 @@ specify additional flags for the runtime build.
----------
The *intel* style invokes settings associated with the use of the
INTEL package. All of its settings, except the *omp* and *mode*
keywords, are ignored if LAMMPS was not built with Xeon Phi
co-processor support. All of its settings, including the *omp* and
*mode* keyword are applicable if LAMMPS was built with co-processor
support.
The *intel* style invokes settings associated with the use of the INTEL
package. The keywords *balance*, *ghost*, *tpc*, and *tptask* are
**only** applicable if LAMMPS was built with Xeon Phi co-processor
support and are otherwise ignored.
The *Nphi* argument sets the number of co-processors per node.
This can be set to any value, including 0, if LAMMPS was not
@ -474,13 +472,13 @@ If the *neigh/thread* keyword is set to *off*, then the KOKKOS package
threads only over atoms. However, for small systems, this may not expose
enough parallelism to keep a GPU busy. When this keyword is set to *on*,
the KOKKOS package threads over both atoms and neighbors of atoms. When
using *neigh/thread* *on*, a full neighbor list must also be used. Using
*neigh/thread* *on* may be slower for large systems, so this this option
is turned on by default only when there are 16K atoms or less owned by
an MPI rank and when using a full neighbor list. Not all KOKKOS-enabled
potentials support this keyword yet, and only thread over atoms. Many
simple pairwise potentials such as Lennard-Jones do support threading
over both atoms and neighbors.
using *neigh/thread* *on*, the :doc:`newton pair <newton>` setting must
be "off". Using *neigh/thread* *on* may be slower for large systems, so
this this option is turned on by default only when running on one or
more GPUs and there are 16k atoms or less owned by an MPI rank. Not all
KOKKOS-enabled potentials support this keyword yet, and only thread over
atoms. Many simple pairwise potentials such as Lennard-Jones do support
threading over both atoms and neighbors.
If the *neigh/transpose* keyword is set to *off*, then the KOKKOS
package will use the same memory layout for building the neighbor list on
@ -732,7 +730,7 @@ comm = device, sort = device, neigh/transpose = off, gpu/aware = on. When
LAMMPS can safely detect that GPU-aware MPI is not available, the default value
of gpu/aware becomes "off". For CPUs or Xeon Phis, the option defaults are
neigh = half, neigh/qeq = half, newton = on, binsize = 0.0, comm = no, and sort
= no. The option neigh/thread = on when there are 16K atoms or less on an MPI
= no. For GPUs, option neigh/thread = on when there are 16k atoms or less on an MPI
rank, otherwise it is "off". These settings are made automatically by the
required "-k on" :doc:`command-line switch <Run_options>`. You can change them
by using the package kokkos command in your input script or via the :doc:`-pk

39
doc/src/pair_aip_water_2dm.rst
View File

@ -22,13 +22,24 @@ Examples
.. code-block:: LAMMPS
pair_style hybrid/overlay aip/water/2dm 16.0 1
pair_coeff * * aip/water/2dm COH.aip.water.2dm C Ow Hw
pair_coeff * * aip/water/2dm CBNOH.aip.water.2dm C Ow Hw
pair_style hybrid/overlay aip/water/2dm 16.0 lj/cut/tip4p/long 2 3 1 1 0.1546 10 8.5
pair_coeff 2 2 lj/cut/tip4p/long 8.0313e-3 3.1589 # O-O
pair_coeff 2 3 lj/cut/tip4p/long 0.0 0.0 # O-H
pair_coeff 3 3 lj/cut/tip4p/long 0.0 0.0 # H-H
pair_coeff * * aip/water/2dm COH.aip.water.2dm C Ow Hw
pair_coeff 2 2 lj/cut/tip4p/long 8.0313e-3 3.1589 # O-O
pair_coeff 2 3 lj/cut/tip4p/long 0.0 0.0 # O-H
pair_coeff 3 3 lj/cut/tip4p/long 0.0 0.0 # H-H
pair_coeff * * aip/water/2dm CBNOH.aip.water.2dm C Ow Hw
pair_style hybrid/overlay aip/water/2dm 16.0 lj/cut/tip4p/long 3 4 1 1 0.1546 10 8.5 coul/shield 16.0 1
pair_coeff 1*2 1*2 none
pair_coeff 3 3 lj/cut/tip4p/long 8.0313e-3 3.1589 # O-O
pair_coeff 3 4 lj/cut/tip4p/long 0.0 0.0 # O-H
pair_coeff 4 4 lj/cut/tip4p/long 0.0 0.0 # H-H
pair_coeff * * aip/water/2dm CBNOH.aip.water.2dm B N Ow Hw
pair_coeff 1 3 coul/shield 1.333
pair_coeff 1 4 coul/shield 1.333
pair_coeff 2 3 coul/shield 1.333
pair_coeff 2 4 coul/shield 1.333
Description
"""""""""""
@ -37,7 +48,7 @@ Description
The *aip/water/2dm* style computes the anisotropic interfacial potential
(AIP) potential for interfaces of water with two-dimensional (2D)
materials as described in :ref:`(Feng) <Feng>`.
materials as described in :ref:`(Feng1) <Feng1>` and :ref:`(Feng2) <Feng2>`.
.. math::
@ -62,12 +73,12 @@ larger than :math:`r_c` :doc:`pair_style ilp_graphene_hbn
.. note::
This pair style uses the atomic normal vector definition from
:ref:`(Feng) <Feng>`), where the atomic normal vectors of the
:ref:`(Feng1) <Feng1>`), where the atomic normal vectors of the
hydrogen atoms are assumed to lie along the corresponding
oxygen-hydrogen bonds and the normal vector of the central oxygen
atom is defined as their average.
The provided parameter file, ``COH.aip.water.2dm``, is intended for use
The provided parameter file, ``CBNOH.aip.water.2dm``, is intended for use
with *metal* :doc:`units <units>`, with energies in meV. Two additional
parameters, *S*, and *rcut* are included in the parameter file. *S* is
designed to facilitate scaling of energies; *rcut* is the cutoff for an
@ -77,7 +88,7 @@ the calculation of the normals for all atom pairs.
.. note::
The parameters presented in the provided parameter file,
``COH.aip.water.2dm``, are fitted with the taper function enabled by
``CBNOH.aip.water.2dm``, are fitted with the taper function enabled by
setting the cutoff equal to 16.0 Angstrom. Using a different cutoff
or taper function setting should be carefully checked as they can
lead to significant errors. These parameters provide a good
@ -134,7 +145,7 @@ if LAMMPS was built with that package. See the :doc:`Build package
This pair style requires the newton setting to be *on* for pair
interactions.
The ``COH.aip.water.2dm`` potential file provided with LAMMPS is
The ``CBNOH.aip.water.2dm`` potential file provided with LAMMPS is
parameterized for *metal* units. You can use this pair style with any
LAMMPS units, but you would need to create your own potential file with
parameters in the appropriate units, if your simulation does not use
@ -162,6 +173,10 @@ tap_flag = 1
----------
.. _Feng:
.. _Feng1:
**(Feng)** Z. Feng and W. Ouyang et al., J. Phys. Chem. C. 127, 8704-8713 (2023).
**(Feng1)** Z. Feng, ..., and W. Ouyang, J. Phys. Chem. C. 127(18), 8704-8713 (2023).
.. _Feng2:
**(Feng2)** Z. Feng, ..., and W. Ouyang, Langmuir 39(50), 18198-18207 (2023).

7
doc/src/pair_charmm.rst
View File

@ -16,6 +16,7 @@
.. index:: pair_style lj/charmm/coul/msm/omp
.. index:: pair_style lj/charmmfsw/coul/charmmfsh
.. index:: pair_style lj/charmmfsw/coul/long
.. index:: pair_style lj/charmmfsw/coul/long/kk
pair_style lj/charmm/coul/charmm command
========================================
@ -43,6 +44,8 @@ pair_style lj/charmmfsw/coul/charmmfsh command
pair_style lj/charmmfsw/coul/long command
=========================================
Accelerator Variants: *lj/charmmfsw/coul/long/kk*
Syntax
""""""
@ -281,7 +284,9 @@ page for more info.
Related commands
""""""""""""""""
:doc:`pair_coeff <pair_coeff>`
:doc:`pair_coeff <pair_coeff>`, :doc:`angle_style charmm <angle_charmm>`,
:doc:`dihedral_style charmm <dihedral_charmm>`,
:doc:`dihedral_style charmmfsw <dihedral_charmm>`, :doc:`fix cmap <fix_cmap>`
Default
"""""""

3
doc/src/pair_coul_slater.rst
View File

@ -1,6 +1,7 @@
.. index:: pair_style coul/slater
.. index:: pair_style coul/slater/cut
.. index:: pair_style coul/slater/long
.. index:: pair_style coul/slater/long/gpu
pair_style coul/slater command
==============================
@ -11,6 +12,8 @@ pair_style coul/slater/cut command
pair_style coul/slater/long command
===================================
Accelerator Variants: *coul/slater/long/gpu*
Syntax
""""""

6
doc/src/pair_fep_soft.rst
View File

@ -1,8 +1,10 @@
.. index:: pair_style lj/cut/soft
.. index:: pair_style lj/cut/soft/omp
.. index:: pair_style lj/cut/coul/cut/soft
.. index:: pair_style lj/cut/coul/cut/soft/gpu
.. index:: pair_style lj/cut/coul/cut/soft/omp
.. index:: pair_style lj/cut/coul/long/soft
.. index:: pair_style lj/cut/coul/long/soft/gpu
.. index:: pair_style lj/cut/coul/long/soft/omp
.. index:: pair_style lj/cut/tip4p/long/soft
.. index:: pair_style lj/cut/tip4p/long/soft/omp
@ -27,12 +29,12 @@ Accelerator Variants: *lj/cut/soft/omp*
pair_style lj/cut/coul/cut/soft command
=======================================
Accelerator Variants: *lj/cut/coul/cut/soft/omp*
Accelerator Variants: *lj/cut/coul/cut/soft/gpu*, *lj/cut/coul/cut/soft/omp*
pair_style lj/cut/coul/long/soft command
========================================
Accelerator Variants: *lj/cut/coul/long/soft/omp*
Accelerator Variants: *lj/cut/coul/long/soft/gpu*, *lj/cut/coul/long/soft/omp*
pair_style lj/cut/tip4p/long/soft command
=========================================

20
doc/src/pair_ilp_tmd.rst
View File

@ -22,12 +22,12 @@ Examples
.. code-block:: LAMMPS
pair_style hybrid/overlay ilp/tmd 16.0 1
pair_coeff * * ilp/tmd MoS2.ILP Mo S S
pair_coeff * * ilp/tmd TMD.ILP Mo S S
pair_style hybrid/overlay sw/mod sw/mod ilp/tmd 16.0
pair_coeff * * sw/mod 1 tmd.sw.mod Mo S S NULL NULL NULL
pair_coeff * * sw/mod 2 tmd.sw.mod NULL NULL NULL Mo S S
pair_coeff * * ilp/tmd MoS2.ILP Mo S S Mo S S
pair_coeff * * sw/mod 2 tmd.sw.mod NULL NULL NULL W Se Se
pair_coeff * * ilp/tmd TMD.ILP Mo S S W Se Se
Description
"""""""""""
@ -36,7 +36,7 @@ Description
The *ilp/tmd* style computes the registry-dependent interlayer
potential (ILP) potential for transition metal dichalcogenides (TMD)
as described in :ref:`(Ouyang7) <Ouyang7>`.
as described in :ref:`(Ouyang7) <Ouyang7>` and :ref:`(Jiang) <Jiang>`.
.. math::
@ -69,7 +69,7 @@ calculating the normals.
each atom `i`, its six nearest neighboring atoms belonging to the same
sub-layer are chosen to define the normal vector `{\bf n}_i`.
The parameter file (e.g. MoS2.ILP), is intended for use with *metal*
The parameter file (e.g. TMD.ILP), is intended for use with *metal*
:doc:`units <units>`, with energies in meV. Two additional parameters,
*S*, and *rcut* are included in the parameter file. *S* is designed to
facilitate scaling of energies. *rcut* is designed to build the neighbor
@ -77,7 +77,7 @@ list for calculating the normals for each atom pair.
.. note::
The parameters presented in the parameter file (e.g. MoS2.ILP),
The parameters presented in the parameter file (e.g. TMD.ILP),
are fitted with taper function by setting the cutoff equal to 16.0
Angstrom. Using different cutoff or taper function should be careful.
These parameters provide a good description in both short- and long-range
@ -133,10 +133,10 @@ if LAMMPS was built with that package. See the :doc:`Build package
This pair style requires the newton setting to be *on* for pair
interactions.
The MoS2.ILP potential file provided with LAMMPS (see the potentials
The TMD.ILP potential file provided with LAMMPS (see the potentials
directory) are parameterized for *metal* units. You can use this
potential with any LAMMPS units, but you would need to create your own
custom MoS2.ILP potential file with coefficients listed in the appropriate
custom TMD.ILP potential file with coefficients listed in the appropriate
units, if your simulation does not use *metal* units.
Related commands
@ -164,3 +164,7 @@ tap_flag = 1
.. _Ouyang7:
**(Ouyang7)** W. Ouyang, et al., J. Chem. Theory Comput. 17, 7237 (2021).
.. _Jiang:
**(Jiang)** W. Jiang, et al., J. Phys. Chem. A, 127, 46, 9820-9830 (2023).

6
doc/src/pair_lepton.rst
View File

@ -72,7 +72,7 @@ interactions between particles which depend on the distance and have a
cutoff. The potential function must be provided as an expression string
using "r" as the distance variable. With pair style *lepton/coul* one
may additionally reference the charges of the two atoms of the pair with
"qi" and "qj", respectively. With pair style *lepton/coul* one may
"qi" and "qj", respectively. With pair style *lepton/sphere* one may
instead reference the radii of the two atoms of the pair with "radi" and
"radj", respectively; this is half of the diameter that can be set in
:doc:`data files <read_data>` or the :doc:`set command <set>`.
@ -166,8 +166,8 @@ mixing. Thus, expressions for *all* I,J pairs must be specified
explicitly.
Only pair style *lepton* supports the :doc:`pair_modify shift <pair_modify>`
option for shifting the energy of the pair interaction so that it is
0 at the cutoff, pair styles *lepton/coul* and *lepton/sphere* do *not*.
option for shifting the potential energy of the pair interaction so that
it is 0 at the cutoff, pair styles *lepton/coul* and *lepton/sphere* do *not*.
The :doc:`pair_modify table <pair_modify>` options are not relevant for
the these pair styles.

6
doc/src/pair_mesodpd.rst
View File

@ -1,14 +1,20 @@
.. index:: pair_style edpd
.. index:: pair_style edpd/gpu
.. index:: pair_style mdpd
.. index:: pair_style mdpd/gpu
.. index:: pair_style mdpd/rhosum
.. index:: pair_style tdpd
pair_style edpd command
=======================
Accelerator Variants: *edpd/gpu*
pair_style mdpd command
=======================
Accelerator Variants: *mdpd/gpu*
pair_style mdpd/rhosum command
==============================

21
doc/src/pair_pace.rst
View File

@ -40,6 +40,9 @@ Examples
pair_style pace product chunksize 2048
pair_coeff * * Cu-PBE-core-rep.ace Cu
pair_style pace
pair_coeff * * Cu.yaml Cu
pair_style pace/extrapolation
pair_coeff * * Cu.yaml Cu.asi Cu
@ -64,7 +67,7 @@ specifies an ACE coefficient file followed by N additional arguments
specifying the mapping of ACE elements to LAMMPS atom types, where N is
the number of LAMMPS atom types:
* ACE coefficient file
* ACE coefficient file (.yaml or .yace/.ace format)
* N element names = mapping of ACE elements to atom types
Only a single pair_coeff command is used with the *pace* style which
@ -136,6 +139,22 @@ product B-basis evaluator is always used and only *linear* ASI is supported.
See the :doc:`pair_coeff <pair_coeff>` page for alternate ways
to specify the path for the ACE coefficient file.
Core repulsion
"""""""""""""""""""
The ACE potential can be configured to initiate core-repulsion from an inner cutoff,
seamlessly transitioning from ACE to ZBL. The core repulsion factor can be accessed
as a per-atom quantity, as demonstrated in the example below:
.. code-block:: LAMMPS
pair_style pace
pair_coeff * * CuNi.yaml Cu Ni
fix pace_corerep all pair 1 pace corerep 1
In this case, per-atom `f_pace_corerep` quantities represent the fraction of ZBL
core-repulsion for each atom.
Mixing, shift, table, tail correction, restart, rRESPA info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

3
doc/src/pair_reaxff.rst
View File

@ -373,7 +373,8 @@ Related commands
:doc:`pair_coeff <pair_coeff>`, :doc:`fix qeq/reaxff <fix_qeq_reaxff>`,
:doc:`fix acks2/reaxff <fix_acks2_reaxff>`, :doc:`fix reaxff/bonds <fix_reaxff_bonds>`,
:doc:`fix reaxff/species <fix_reaxff_species>`
:doc:`fix reaxff/species <fix_reaxff_species>`,
:doc:`compute reaxff/atom <compute_reaxff_atom>`
Default
"""""""

3
doc/src/pair_sph_heatconduction.rst
View File

@ -1,8 +1,11 @@
.. index:: pair_style sph/heatconduction
.. index:: pair_style sph/heatconduction/gpu
pair_style sph/heatconduction command
=====================================
Accelerator Variants: *sph/heatconduction/gpu*
Syntax
""""""

3
doc/src/pair_sph_lj.rst
View File

@ -1,8 +1,11 @@
.. index:: pair_style sph/lj
.. index:: pair_style sph/lj/gpu
pair_style sph/lj command
=========================
Accelerator Variants: *sph/lj/gpu*
Syntax
""""""

3
doc/src/pair_sph_taitwater.rst
View File

@ -1,8 +1,11 @@
.. index:: pair_style sph/taitwater
.. index:: pair_style sph/taitwater/gpu
pair_style sph/taitwater command
================================
Accelerator Variants: *sph/taitwater/gpu*
Syntax
""""""

3
doc/src/run_style.rst
View File

@ -329,7 +329,8 @@ Restrictions
The *verlet/split* style can only be used if LAMMPS was built with the
REPLICA package. Correspondingly the *respa/omp* style is available
only if the OPENMP package was included. See the :doc:`Build package
<Build_package>` page for more info.
<Build_package>` page for more info. It is not compatible with
kspace styles from the INTEL package.
Whenever using rRESPA, the user should experiment with trade-offs in
speed and accuracy for their system, and verify that they are

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

@ -79,6 +79,7 @@ Alessandro
Alexey
ali
aliceblue
Allera
Allinger
allocatable
allocator
@ -124,6 +125,7 @@ antisymmetry
anton
Antonelli
api
apolar
Apoorva
Appl
Appshaw
@ -150,6 +152,7 @@ asphericity
Asq
assignee
assively
associativity
Asta
Astart
Astop
@ -719,6 +722,7 @@ dem
Dendrimer
dendritic
Denniston
Denoual
dephase
dephasing
dequidt
@ -790,11 +794,13 @@ dispersionflag
dissipative
Dissipative
distharm
distutils
dl
dlabel
dlambda
DLAMMPS
dll
dlm
dlopen
dm
dmax
@ -860,6 +866,7 @@ Dunweg
Dupend
Dupont
dUs
Duval
dV
dvector
dVx
@ -1011,6 +1018,7 @@ Ercolessi
Erdmann
erf
erfc
erforce
Erhart
erorate
erose
@ -1074,6 +1082,7 @@ facesets
factorizable
factorizations
Fahrenberger
Falk
Faken
Farago
Fasolino
@ -1298,6 +1307,7 @@ Gonzalez-Melchor
googlemail
googletest
Gordan
Goryaeva
Goudeau
GPa
GPL
@ -1384,12 +1394,14 @@ hcp
hdnnp
HDNNP
Hearn
Heaviside
heatconduction
heatflow
Hebbeker
Hebenstreit
Hecht
Heenen
heFFTe
Hendrik
Henin
Henkelman
@ -1822,6 +1834,7 @@ Lanczos
Lande
Landron
Landsgesell
Langer
langevin
Langevin
Langston
@ -1847,6 +1860,7 @@ lbl
LBtype
lcbop
ld
lda
ldfftw
ldg
lebedeva
@ -1968,6 +1982,7 @@ lossy
Lozovik
lps
lpsapi
lr
lrt
lsfftw
lt
@ -2010,7 +2025,10 @@ magelec
Maginn
magneton
magnetons
maha
Mahalanobis
Mahoney
Maillet
mainboard
mainboards
makefile
@ -2189,6 +2207,7 @@ mintcream
Mintmire
Miron
mis
misclassification
Mises
Mishin
Mishra
@ -2220,8 +2239,10 @@ Mohd
Mohles
mol
Mol
molatom
molfile
Molfile
molindex
MolPairStyle
moltemplate
momb
@ -2297,6 +2318,7 @@ multicomponent
multicore
multielectron
multinode
multinomial
multiphysics
Multipole
multiscale
@ -2388,6 +2410,7 @@ Nbtypes
Nbytes
nc
Nc
nclasses
nchunk
Nchunk
ncoeff
@ -2499,6 +2522,7 @@ noforce
noguess
Noid
nolib
nonaffine
nonequilibrium
nongauss
nonGaussian
@ -2551,6 +2575,7 @@ ns
Ns
Nsample
Nskip
nspecial
Nspecies
nsq
Nstart
@ -2571,6 +2596,7 @@ nthreads
ntimestep
Ntptask
Ntriples
ntries
ntris
Ntype
ntypes
@ -2796,6 +2822,7 @@ pIm
pimd
Piola
pIp
pipelining
Pisarev
Pishevar
Pitera
@ -3348,6 +3375,7 @@ Skylake
slateblue
slategray
slater
slcsa
Slepoy
Sliozberg
sLL
@ -3856,6 +3884,7 @@ versa
Verstraelen
ves
vflag
vfrac
vhi
vibrational
Vij
@ -4028,6 +4057,7 @@ xy
xyz
xz
xzhou
yace
Yade
yade
yaff

2
examples/COUPLE/plugin/liblammpsplugin.c
View File

@ -110,6 +110,8 @@ liblammpsplugin_t *liblammpsplugin_load(const char *lib)
ADDSYM(extract_variable);
ADDSYM(extract_variable_datatype);
ADDSYM(set_variable);
ADDSYM(set_string_variable);
ADDSYM(set_internal_variable);
ADDSYM(variable_info);
ADDSYM(gather_atoms);

6
examples/COUPLE/plugin/liblammpsplugin.h
View File

@ -152,9 +152,11 @@ struct _liblammpsplugin {
void *(*extract_compute)(void *, const char *, int, int);
void *(*extract_fix)(void *, const char *, int, int, int, int);
void *(*extract_variable)(void *, const char *, char *);
void *(*extract_variable)(void *, const char *, const char *);
int (*extract_variable_datatype)(void *, const char *);
int (*set_variable)(void *, char *, char *);
int (*set_variable)(void *, const char *, const char *);
int (*set_string_variable)(void *, const char *, const char *);
int (*set_internal_variable)(void *, const char *, double);
int (*variable_info)(void *, int, char *, int);
void (*gather_atoms)(void *, const char *, int, int, void *);

18
examples/COUPLE/simple/simple.cpp
View File

@ -67,7 +67,7 @@ int main(int narg, char **arg)
FILE *fp;
if (me == 0) {
fp = fopen(arg[2],"r");
if (fp == NULL) {
if (fp == nullptr) {
printf("ERROR: Could not open LAMMPS input script\n");
MPI_Abort(MPI_COMM_WORLD,1);
}
@ -78,14 +78,14 @@ int main(int narg, char **arg)
// (could just send it to proc 0 of comm_lammps and let it Bcast)
// all LAMMPS procs call input->one() on the line
LAMMPS *lmp = NULL;
if (lammps == 1) lmp = new LAMMPS(0,NULL,comm_lammps);
LAMMPS *lmp = nullptr;
if (lammps == 1) lmp = new LAMMPS(0,nullptr,comm_lammps);
int n;
char line[1024];
while (1) {
while (true) {
if (me == 0) {
if (fgets(line,1024,fp) == NULL) n = 0;
if (fgets(line,1024,fp) == nullptr) n = 0;
else n = strlen(line) + 1;
if (n == 0) fclose(fp);
}
@ -101,8 +101,8 @@ int main(int narg, char **arg)
// put coords back into LAMMPS
// run a single step with changed coords
double *x = NULL;
double *v = NULL;
double *x = nullptr;
double *v = nullptr;
if (lammps == 1) {
lmp->input->one("run 10");
@ -147,7 +147,7 @@ int main(int narg, char **arg)
// create_atoms() to create new ones with old coords, vels
// initial thermo should be same as step 20
int *type = NULL;
int *type = nullptr;
if (lammps == 1) {
int natoms = static_cast<int> (lmp->atom->natoms);
@ -155,7 +155,7 @@ int main(int narg, char **arg)
for (int i = 0; i < natoms; i++) type[i] = 1;
lmp->input->one("delete_atoms group all");
lammps_create_atoms(lmp,natoms,NULL,type,x,v,NULL,0);
lammps_create_atoms(lmp,natoms,nullptr,type,x,v,nullptr,0);
lmp->input->one("run 10");
}

369
examples/PACKAGES/cgdna/util/generate.py
View File

@ -22,22 +22,26 @@
"""
Import basic modules
"""
# for python2/3 compatibility
from __future__ import print_function
import sys, os, timeit
from timeit import default_timer as timer
start_time = timer()
"""
Try to import numpy; if failed, import a local version mynumpy
Try to import numpy; if failed, import a local version mynumpy
which needs to be provided
"""
try:
import numpy as np
except:
print >> sys.stderr, "numpy not found. Exiting."
print("numpy not found. Exiting.", file=sys.stderr)
sys.exit(1)
"""
Check that the required arguments (box offset and size in simulation units
Check that the required arguments (box offset and size in simulation units
and the sequence file were provided
"""
try:
@ -45,8 +49,8 @@ try:
box_length = float(sys.argv[2])
infile = sys.argv[3]
except:
print >> sys.stderr, "Usage: %s <%s> <%s> <%s>" % (sys.argv[0], \
"box offset", "box length", "file with sequences")
print( "Usage: %s <%s> <%s> <%s>" % (sys.argv[0], \
"box offset", "box length", "file with sequences"), file=sys.stderr)
sys.exit(1)
box = np.array ([box_length, box_length, box_length])
@ -57,8 +61,7 @@ try:
inp = open (infile, 'r')
inp.close()
except:
print >> sys.stderr, "Could not open file '%s' for reading. \
Aborting." % infile
print( "Could not open file '%s' for reading. Aborting." % infile, file=sys.stderr)
sys.exit(2)
# return parts of a string
@ -86,7 +89,7 @@ Define auxiliary variables for the construction of a helix
# center of the double strand
CM_CENTER_DS = POS_BASE + 0.2
# ideal distance between base sites of two nucleotides
# ideal distance between base sites of two nucleotides
# which are to be base paired in a duplex
BASE_BASE = 0.3897628551303122
@ -118,7 +121,7 @@ strandnum = []
bonds = []
"""
"""
Convert local body frame to quaternion DOF
"""
def exyz_to_quat (mya1, mya3):
@ -135,25 +138,25 @@ def exyz_to_quat (mya1, mya3):
# compute other components from it
if q0sq >= 0.25:
myquat[0] = np.sqrt(q0sq)
myquat[1] = (mya2[2] - mya3[1]) / (4.0*myquat[0])
myquat[2] = (mya3[0] - mya1[2]) / (4.0*myquat[0])
myquat[3] = (mya1[1] - mya2[0]) / (4.0*myquat[0])
myquat[0] = np.sqrt(q0sq)
myquat[1] = (mya2[2] - mya3[1]) / (4.0*myquat[0])
myquat[2] = (mya3[0] - mya1[2]) / (4.0*myquat[0])
myquat[3] = (mya1[1] - mya2[0]) / (4.0*myquat[0])
elif q1sq >= 0.25:
myquat[1] = np.sqrt(q1sq)
myquat[0] = (mya2[2] - mya3[1]) / (4.0*myquat[1])
myquat[2] = (mya2[0] + mya1[1]) / (4.0*myquat[1])
myquat[3] = (mya1[2] + mya3[0]) / (4.0*myquat[1])
myquat[1] = np.sqrt(q1sq)
myquat[0] = (mya2[2] - mya3[1]) / (4.0*myquat[1])
myquat[2] = (mya2[0] + mya1[1]) / (4.0*myquat[1])
myquat[3] = (mya1[2] + mya3[0]) / (4.0*myquat[1])
elif q2sq >= 0.25:
myquat[2] = np.sqrt(q2sq)
myquat[0] = (mya3[0] - mya1[2]) / (4.0*myquat[2])
myquat[1] = (mya2[0] + mya1[1]) / (4.0*myquat[2])
myquat[3] = (mya3[1] + mya2[2]) / (4.0*myquat[2])
myquat[2] = np.sqrt(q2sq)
myquat[0] = (mya3[0] - mya1[2]) / (4.0*myquat[2])
myquat[1] = (mya2[0] + mya1[1]) / (4.0*myquat[2])
myquat[3] = (mya3[1] + mya2[2]) / (4.0*myquat[2])
elif q3sq >= 0.25:
myquat[3] = np.sqrt(q3sq)
myquat[0] = (mya1[1] - mya2[0]) / (4.0*myquat[3])
myquat[1] = (mya3[0] + mya1[2]) / (4.0*myquat[3])
myquat[2] = (mya3[1] + mya2[2]) / (4.0*myquat[3])
myquat[3] = np.sqrt(q3sq)
myquat[0] = (mya1[1] - mya2[0]) / (4.0*myquat[3])
myquat[1] = (mya3[0] + mya1[2]) / (4.0*myquat[3])
myquat[2] = (mya3[1] + mya2[2]) / (4.0*myquat[3])
norm = 1.0/np.sqrt(myquat[0]*myquat[0] + myquat[1]*myquat[1] + \
myquat[2]*myquat[2] + myquat[3]*myquat[3])
@ -169,62 +172,62 @@ Adds a strand to the system by appending it to the array of previous strands
"""
def add_strands (mynewpositions, mynewa1s, mynewa3s):
overlap = False
# This is a simple check for each of the particles where for previously
# placed particles i we check whether it overlaps with any of the
# This is a simple check for each of the particles where for previously
# placed particles i we check whether it overlaps with any of the
# newly created particles j
print >> sys.stdout, "## Checking for overlaps"
print( "## Checking for overlaps", file=sys.stdout)
for i in xrange(len(positions)):
for i in range(len(positions)):
p = positions[i]
pa1 = a1s[i]
p = positions[i]
pa1 = a1s[i]
for j in xrange (len(mynewpositions)):
for j in range (len(mynewpositions)):
q = mynewpositions[j]
qa1 = mynewa1s[j]
q = mynewpositions[j]
qa1 = mynewa1s[j]
# skip particles that are anyway too far away
dr = p - q
dr -= box * np.rint (dr / box)
if np.dot(dr, dr) > RC2:
continue
# skip particles that are anyway too far away
dr = p - q
dr -= box * np.rint(dr / box)
if np.dot(dr, dr) > RC2:
continue
# base site and backbone site of the two particles
# base site and backbone site of the two particles
p_pos_back = p + pa1 * POS_BACK
p_pos_base = p + pa1 * POS_BASE
q_pos_back = q + qa1 * POS_BACK
q_pos_base = q + qa1 * POS_BASE
# check for no overlap between the two backbone sites
# check for no overlap between the two backbone sites
dr = p_pos_back - q_pos_back
dr -= box * np.rint (dr / box)
dr -= box * np.rint(dr / box)
if np.dot(dr, dr) < RC2_BACK:
overlap = True
# check for no overlap between the two base sites
# check for no overlap between the two base sites
dr = p_pos_base - q_pos_base
dr -= box * np.rint (dr / box)
dr -= box * np.rint(dr / box)
if np.dot(dr, dr) < RC2_BASE:
overlap = True
# check for no overlap between backbone site of particle p
# with base site of particle q
# check for no overlap between backbone site of particle p
# with base site of particle q
dr = p_pos_back - q_pos_base
dr -= box * np.rint (dr / box)
if np.dot(dr, dr) < RC2_BACK_BASE:
overlap = True
# check for no overlap between base site of particle p and
# backbone site of particle q
# check for no overlap between base site of particle p and
# backbone site of particle q
dr = p_pos_base - q_pos_back
dr -= box * np.rint (dr / box)
if np.dot(dr, dr) < RC2_BACK_BASE:
overlap = True
# exit if there is an overlap
# exit if there is an overlap
if overlap:
return False
@ -237,10 +240,10 @@ def add_strands (mynewpositions, mynewa1s, mynewa3s):
a1s.append (p)
for p in mynewa3s:
a3s.append (p)
# calculate quaternion from local body frame and append
for ia in xrange(len(mynewpositions)):
mynewquaternions = exyz_to_quat(mynewa1s[ia],mynewa3s[ia])
quaternions.append(mynewquaternions)
# calculate quaternion from local body frame and append
for ia in range(len(mynewpositions)):
mynewquaternions = exyz_to_quat(mynewa1s[ia],mynewa3s[ia])
quaternions.append(mynewquaternions)
return True
@ -281,7 +284,7 @@ def get_rotation_matrix(axis, anglest):
[olc*x*z-st*y, olc*y*z+st*x, olc*z*z+ct]])
"""
Generates the position and orientation vectors of a
Generates the position and orientation vectors of a
(single or double) strand from a sequence string
"""
def generate_strand(bp, sequence=None, start_pos=np.array([0, 0, 0]), \
@ -295,76 +298,75 @@ def generate_strand(bp, sequence=None, start_pos=np.array([0, 0, 0]), \
# overall direction of the helix
dir = np.array(dir, dtype=float)
if sequence == None:
sequence = np.random.randint(1, 5, bp)
sequence = np.random.randint(1, 5, bp)
# the elseif here is most likely redundant
# the elseif here is most likely redundant
elif len(sequence) != bp:
n = bp - len(sequence)
sequence += np.random.randint(1, 5, n)
print >> sys.stderr, "sequence is too short, adding %d random bases" % n
n = bp - len(sequence)
sequence += np.random.randint(1, 5, n)
print( "sequence is too short, adding %d random bases" % n, file=sys.stderr)
# normalize direction
dir_norm = np.sqrt(np.dot(dir,dir))
if dir_norm < 1e-10:
print >> sys.stderr, "direction must be a valid vector, \
defaulting to (0, 0, 1)"
dir = np.array([0, 0, 1])
print( "direction must be a valid vector, defaulting to (0, 0, 1)", file=sys.stderr)
dir = np.array([0, 0, 1])
else: dir /= dir_norm
# find a vector orthogonal to dir to act as helix direction,
# if not provided switch off random orientation
if perp is None or perp is False:
v1 = np.random.random_sample(3)
v1 -= dir * (np.dot(dir, v1))
v1 /= np.sqrt(sum(v1*v1))
v1 = np.random.random_sample(3)
v1 -= dir * (np.dot(dir, v1))
v1 /= np.sqrt(sum(v1*v1))
else:
v1 = perp;
v1 = perp;
# generate rotational matrix representing the overall rotation of the helix
R0 = get_rotation_matrix(dir, rot)
# rotation matrix corresponding to one step along the helix
R = get_rotation_matrix(dir, [1, "bp"])
# set the vector a1 (backbone to base) to v1
# set the vector a1 (backbone to base) to v1
a1 = v1
# apply the global rotation to a1
# apply the global rotation to a1
a1 = np.dot(R0, a1)
# set the position of the fist backbone site to start_pos
rb = np.array(start_pos)
# set a3 to the direction of the helix
a3 = dir
for i in range(bp):
# work out the position of the centre of mass of the nucleotide
rcdm = rb - CM_CENTER_DS * a1
# append to newpositions
mynewpositions.append(rcdm)
mynewa1s.append(a1)
mynewa3s.append(a3)
# if we are not at the end of the helix, we work out a1 and rb for the
# next nucleotide along the helix
if i != bp - 1:
a1 = np.dot(R, a1)
rb += a3 * BASE_BASE
rcdm = rb - CM_CENTER_DS * a1
# if we are working on a double strand, we do a cycle similar
# append to newpositions
mynewpositions.append(rcdm)
mynewa1s.append(a1)
mynewa3s.append(a3)
# if we are not at the end of the helix, we work out a1 and rb for the
# next nucleotide along the helix
if i != bp - 1:
a1 = np.dot(R, a1)
rb += a3 * BASE_BASE
# if we are working on a double strand, we do a cycle similar
# to the previous one but backwards
if double == True:
a1 = -a1
a3 = -dir
R = R.transpose()
for i in range(bp):
rcdm = rb - CM_CENTER_DS * a1
mynewpositions.append (rcdm)
mynewa1s.append (a1)
mynewa3s.append (a3)
a1 = np.dot(R, a1)
rb += a3 * BASE_BASE
a1 = -a1
a3 = -dir
R = R.transpose()
for i in range(bp):
rcdm = rb - CM_CENTER_DS * a1
mynewpositions.append (rcdm)
mynewa1s.append (a1)
mynewa3s.append (a3)
a1 = np.dot(R, a1)
rb += a3 * BASE_BASE
assert (len (mynewpositions) > 0)
@ -391,10 +393,10 @@ def read_strands(filename):
try:
infile = open (filename)
except:
print >> sys.stderr, "Could not open file '%s'. Aborting." % filename
print( "Could not open file '%s'. Aborting." % filename, file=sys.stderr )
sys.exit(2)
# This block works out the number of nucleotides and strands by reading
# This block works out the number of nucleotides and strands by reading
# the number of non-empty lines in the input file and the number of letters,
# taking the possible DOUBLE keyword into account.
nstrands, nnucl, nbonds = 0, 0, 0
@ -406,30 +408,29 @@ def read_strands(filename):
if line[:6] == 'DOUBLE':
line = line.split()[1]
length = len(line)
print >> sys.stdout, "## Found duplex of %i base pairs" % length
print( "## Found duplex of %i base pairs" % length, file=sys.stdout)
nnucl += 2*length
nstrands += 2
nbonds += (2*length-2)
nbonds += (2*length-2)
else:
line = line.split()[0]
length = len(line)
print >> sys.stdout, \
"## Found single strand of %i bases" % length
print( "## Found single strand of %i bases" % length, file=sys.stdout)
nnucl += length
nstrands += 1
nbonds += length-1
nbonds += length-1
# rewind the sequence input file
infile.seek(0)
print >> sys.stdout, "## nstrands, nnucl = ", nstrands, nnucl
print( "## nstrands, nnucl = ", nstrands, nnucl, file=sys.stdout)
# generate the data file in LAMMPS format
try:
out = open ("data.oxdna", "w")
except:
print >> sys.stderr, "Could not open data file for writing. Aborting."
print( "Could not open data file for writing. Aborting.", file=sys.stderr)
sys.exit(2)
lines = infile.readlines()
nlines = len(lines)
i = 1
@ -440,115 +441,114 @@ def read_strands(filename):
line = line.upper().strip()
# skip empty lines
if len(line) == 0:
i += 1
continue
if len(line) == 0:
i += 1
continue
# block for duplexes: last argument of the generate function
# is set to 'True'
# block for duplexes: last argument of the generate function
# is set to 'True'
if line[:6] == 'DOUBLE':
line = line.split()[1]
length = len(line)
seq = [(base_to_number[x]) for x in line]
myns += 1
for b in xrange(length):
basetype.append(seq[b])
strandnum.append(myns)
myns += 1
for b in range(length):
basetype.append(seq[b])
strandnum.append(myns)
for b in xrange(length-1):
bondpair = [noffset + b, noffset + b + 1]
bonds.append(bondpair)
noffset += length
for b in range(length-1):
bondpair = [noffset + b, noffset + b + 1]
bonds.append(bondpair)
noffset += length
# create the sequence of the second strand as made of
# complementary bases
seq2 = [5-s for s in seq]
seq2.reverse()
# create the sequence of the second strand as made of
# complementary bases
seq2 = [5-s for s in seq]
seq2.reverse()
myns += 1
for b in xrange(length):
basetype.append(seq2[b])
strandnum.append(myns)
myns += 1
for b in range(length):
basetype.append(seq2[b])
strandnum.append(myns)
for b in xrange(length-1):
bondpair = [noffset + b, noffset + b + 1]
bonds.append(bondpair)
noffset += length
print >> sys.stdout, "## Created duplex of %i bases" % (2*length)
for b in range(length-1):
bondpair = [noffset + b, noffset + b + 1]
bonds.append(bondpair)
noffset += length
# generate random position of the first nucleotide
print( "## Created duplex of %i bases" % (2*length), file=sys.stdout)
# generate random position of the first nucleotide
cdm = box_offset + np.random.random_sample(3) * box
# generate the random direction of the helix
# generate the random direction of the helix
axis = np.random.random_sample(3)
axis /= np.sqrt(np.dot(axis, axis))
# use the generate function defined above to create
# the position and orientation vector of the strand
# use the generate function defined above to create
# the position and orientation vector of the strand
newpositions, newa1s, newa3s = generate_strand(len(line), \
sequence=seq, dir=axis, start_pos=cdm, double=True)
sequence=seq, dir=axis, start_pos=cdm, double=True)
# generate a new position for the strand until it does not overlap
# with anything already present
start = timer()
# with anything already present
start = timer()
while not add_strands(newpositions, newa1s, newa3s):
cdm = box_offset + np.random.random_sample(3) * box
axis = np.random.random_sample(3)
axis /= np.sqrt(np.dot(axis, axis))
newpositions, newa1s, newa3s = generate_strand(len(line), \
sequence=seq, dir=axis, start_pos=cdm, double=True)
print >> sys.stdout, "## Trying %i" % i
end = timer()
print >> sys.stdout, "## Added duplex of %i bases (line %i/%i) in %.2fs, now at %i/%i" % \
(2*length, i, nlines, end-start, len(positions), nnucl)
sequence=seq, dir=axis, start_pos=cdm, double=True)
print( "## Trying %i" % i, file=sys.stdout)
end = timer()
print( "## Added duplex of %i bases (line %i/%i) in %.2fs, now at %i/%i" % \
(2*length, i, nlines, end-start, len(positions), nnucl), file=sys.stdout)
# block for single strands: last argument of the generate function
# is set to 'False'
# block for single strands: last argument of the generate function
# is set to 'False'
else:
length = len(line)
seq = [(base_to_number[x]) for x in line]
myns += 1
for b in xrange(length):
basetype.append(seq[b])
strandnum.append(myns)
myns += 1
for b in range(length):
basetype.append(seq[b])
strandnum.append(myns)
for b in xrange(length-1):
bondpair = [noffset + b, noffset + b + 1]
bonds.append(bondpair)
noffset += length
for b in range(length-1):
bondpair = [noffset + b, noffset + b + 1]
bonds.append(bondpair)
noffset += length
# generate random position of the first nucleotide
# generate random position of the first nucleotide
cdm = box_offset + np.random.random_sample(3) * box
# generate the random direction of the helix
# generate the random direction of the helix
axis = np.random.random_sample(3)
axis /= np.sqrt(np.dot(axis, axis))
print >> sys.stdout, \
"## Created single strand of %i bases" % length
print("## Created single strand of %i bases" % length, file=sys.stdout)
newpositions, newa1s, newa3s = generate_strand(length, \
sequence=seq, dir=axis, start_pos=cdm, double=False)
start = timer()
start = timer()
while not add_strands(newpositions, newa1s, newa3s):
cdm = box_offset + np.random.random_sample(3) * box
axis = np.random.random_sample(3)
axis /= np.sqrt(np.dot(axis, axis))
axis /= np.sqrt(np.dot(axis, axis))
newpositions, newa1s, newa3s = generate_strand(length, \
sequence=seq, dir=axis, start_pos=cdm, double=False)
sequence=seq, dir=axis, start_pos=cdm, double=False)
print >> sys.stdout, "## Trying %i" % (i)
end = timer()
print >> sys.stdout, "## Added single strand of %i bases (line %i/%i) in %.2fs, now at %i/%i" % \
(length, i, nlines, end-start,len(positions), nnucl)
end = timer()
print( "## Added single strand of %i bases (line %i/%i) in %.2fs, now at %i/%i" % \
(length, i, nlines, end-start,len(positions), nnucl), file=sys.stdout)
i += 1
# sanity check
if not len(positions) == nnucl:
print len(positions), nnucl
print( len(positions), nnucl )
raise AssertionError
out.write('# LAMMPS data file\n')
@ -580,44 +580,41 @@ def read_strands(filename):
out.write('Atoms\n')
out.write('\n')
for i in xrange(nnucl):
out.write('%d %d %22.15le %22.15le %22.15le %d 1 1\n' \
% (i+1, basetype[i], \
positions[i][0], positions[i][1], positions[i][2], \
strandnum[i]))
for i in range(nnucl):
out.write('%d %d %22.15le %22.15le %22.15le %d 1 1\n' \
% (i+1, basetype[i], positions[i][0], positions[i][1], positions[i][2], strandnum[i]))
out.write('\n')
out.write('# Atom-ID, translational, rotational velocity\n')
out.write('Velocities\n')
out.write('\n')
for i in xrange(nnucl):
out.write("%d %22.15le %22.15le %22.15le %22.15le %22.15le %22.15le\n" \
% (i+1,0.0,0.0,0.0,0.0,0.0,0.0))
for i in range(nnucl):
out.write("%d %22.15le %22.15le %22.15le %22.15le %22.15le %22.15le\n" \
% (i+1,0.0,0.0,0.0,0.0,0.0,0.0))
out.write('\n')
out.write('# Atom-ID, shape, quaternion\n')
out.write('Ellipsoids\n')
out.write('\n')
for i in xrange(nnucl):
out.write(\
"%d %22.15le %22.15le %22.15le %22.15le %22.15le %22.15le %22.15le\n" \
% (i+1,1.1739845031423408,1.1739845031423408,1.1739845031423408, \
quaternions[i][0],quaternions[i][1], quaternions[i][2],quaternions[i][3]))
for i in range(nnucl):
out.write("%d %22.15le %22.15le %22.15le %22.15le %22.15le %22.15le %22.15le\n" \
% (i+1,1.1739845031423408,1.1739845031423408,1.1739845031423408, \
quaternions[i][0],quaternions[i][1], quaternions[i][2],quaternions[i][3]))
out.write('\n')
out.write('# Bond topology\n')
out.write('Bonds\n')
out.write('\n')
for i in xrange(nbonds):
out.write("%d %d %d %d\n" % (i+1,1,bonds[i][0],bonds[i][1]))
for i in range(nbonds):
out.write("%d %d %d %d\n" % (i+1,1,bonds[i][0],bonds[i][1]))
out.close()
print >> sys.stdout, "## Wrote data to 'data.oxdna'"
print >> sys.stdout, "## DONE"
print("## Wrote data to 'data.oxdna'", file=sys.stdout)
print("## DONE", file=sys.stdout)
# call the above main() function, which executes the program
read_strands (infile)
@ -627,4 +624,6 @@ runtime = end_time-start_time
hours = runtime/3600
minutes = (runtime-np.rint(hours)*3600)/60
seconds = (runtime-np.rint(hours)*3600-np.rint(minutes)*60)%60
print >> sys.stdout, "## Total runtime %ih:%im:%.2fs" % (hours,minutes,seconds)
print( "## Total runtime %ih:%im:%.2fs" % (hours,minutes,seconds), file=sys.stdout)

75
examples/PACKAGES/cgdna/util/generate_simple.py
View File

@ -1,5 +1,8 @@
# Setup tool for oxDNA input in LAMMPS format.
# for python2/3 compatibility
from __future__ import print_function
import math,numpy as np,sys,os
# system size
@ -250,59 +253,59 @@ def duplex_array():
qrot3=math.sin(0.5*twist)
for letter in strand[2]:
temp1=[]
temp2=[]
temp1=[]
temp2=[]
temp1.append(nt2num[letter])
temp2.append(compnt2num[letter])
temp1.append(nt2num[letter])
temp2.append(compnt2num[letter])
temp1.append([posx1,posy1,posz1])
temp2.append([posx2,posy2,posz2])
temp1.append([posx1,posy1,posz1])
temp2.append([posx2,posy2,posz2])
vel=[0,0,0,0,0,0]
temp1.append(vel)
temp2.append(vel)
vel=[0,0,0,0,0,0]
temp1.append(vel)
temp2.append(vel)
temp1.append(shape)
temp2.append(shape)
temp1.append(shape)
temp2.append(shape)
temp1.append(quat1)
temp2.append(quat2)
temp1.append(quat1)
temp2.append(quat2)
quat1_0 = quat1[0]*qrot0 - quat1[1]*qrot1 - quat1[2]*qrot2 - quat1[3]*qrot3
quat1_1 = quat1[0]*qrot1 + quat1[1]*qrot0 + quat1[2]*qrot3 - quat1[3]*qrot2
quat1_2 = quat1[0]*qrot2 + quat1[2]*qrot0 + quat1[3]*qrot1 - quat1[1]*qrot3
quat1_3 = quat1[0]*qrot3 + quat1[3]*qrot0 + quat1[1]*qrot2 + quat1[2]*qrot1
quat1_0 = quat1[0]*qrot0 - quat1[1]*qrot1 - quat1[2]*qrot2 - quat1[3]*qrot3
quat1_1 = quat1[0]*qrot1 + quat1[1]*qrot0 + quat1[2]*qrot3 - quat1[3]*qrot2
quat1_2 = quat1[0]*qrot2 + quat1[2]*qrot0 + quat1[3]*qrot1 - quat1[1]*qrot3
quat1_3 = quat1[0]*qrot3 + quat1[3]*qrot0 + quat1[1]*qrot2 + quat1[2]*qrot1
quat1 = [quat1_0,quat1_1,quat1_2,quat1_3]
quat1 = [quat1_0,quat1_1,quat1_2,quat1_3]
posx1=axisx - dcomh*(quat1[0]**2+quat1[1]**2-quat1[2]**2-quat1[3]**2)
posy1=axisy - dcomh*(2*(quat1[1]*quat1[2]+quat1[0]*quat1[3]))
posz1=posz1+risez
posx1=axisx - dcomh*(quat1[0]**2+quat1[1]**2-quat1[2]**2-quat1[3]**2)
posy1=axisy - dcomh*(2*(quat1[1]*quat1[2]+quat1[0]*quat1[3]))
posz1=posz1+risez
quat2_0 = quat2[0]*qrot0 - quat2[1]*qrot1 - quat2[2]*qrot2 + quat2[3]*qrot3
quat2_1 = quat2[0]*qrot1 + quat2[1]*qrot0 - quat2[2]*qrot3 - quat2[3]*qrot2
quat2_2 = quat2[0]*qrot2 + quat2[2]*qrot0 + quat2[3]*qrot1 + quat2[1]*qrot3
quat2_3 =-quat2[0]*qrot3 + quat2[3]*qrot0 + quat2[1]*qrot2 + quat2[2]*qrot1
quat2_0 = quat2[0]*qrot0 - quat2[1]*qrot1 - quat2[2]*qrot2 + quat2[3]*qrot3
quat2_1 = quat2[0]*qrot1 + quat2[1]*qrot0 - quat2[2]*qrot3 - quat2[3]*qrot2
quat2_2 = quat2[0]*qrot2 + quat2[2]*qrot0 + quat2[3]*qrot1 + quat2[1]*qrot3
quat2_3 =-quat2[0]*qrot3 + quat2[3]*qrot0 + quat2[1]*qrot2 + quat2[2]*qrot1
quat2 = [quat2_0,quat2_1,quat2_2,quat2_3]
quat2 = [quat2_0,quat2_1,quat2_2,quat2_3]
posx2=axisx + dcomh*(quat1[0]**2+quat1[1]**2-quat1[2]**2-quat1[3]**2)
posy2=axisy + dcomh*(2*(quat1[1]*quat1[2]+quat1[0]*quat1[3]))
posz2=posz1
posx2=axisx + dcomh*(quat1[0]**2+quat1[1]**2-quat1[2]**2-quat1[3]**2)
posy2=axisy + dcomh*(2*(quat1[1]*quat1[2]+quat1[0]*quat1[3]))
posz2=posz1
if (len(nucleotide)+1 > strandstart):
topology.append([1,len(nucleotide),len(nucleotide)+1])
comptopo.append([1,len(nucleotide)+len(strand[2]),len(nucleotide)+len(strand[2])+1])
if (len(nucleotide)+1 > strandstart):
topology.append([1,len(nucleotide),len(nucleotide)+1])
comptopo.append([1,len(nucleotide)+len(strand[2]),len(nucleotide)+len(strand[2])+1])
nucleotide.append(temp1)
compstrand.append(temp2)
nucleotide.append(temp1)
compstrand.append(temp2)
for ib in range(len(compstrand)):
nucleotide.append(compstrand[len(compstrand)-1-ib])
nucleotide.append(compstrand[len(compstrand)-1-ib])
for ib in range(len(comptopo)):
topology.append(comptopo[ib])
topology.append(comptopo[ib])
return

1
examples/PACKAGES/dpd-meso/mdpd/in.mdpd
View File

@ -16,6 +16,7 @@ neighbor 0.3 bin
neigh_modify every 1 delay 0 check yes
atom_style mdpd
comm_modify vel yes
region mdpd block -25 25 -10 10 -10 10 units box
create_box 1 mdpd

1
examples/PACKAGES/interlayer/aip_water_2dm/CBNOH.aip.water.2dm Symbolic link
View File

@ -0,0 +1 @@
../../../../potentials/CBNOH.aip.water.2dm

1
examples/PACKAGES/interlayer/aip_water_2dm/COH.aip.water.2dm
View File

@ -1 +0,0 @@
../../../../potentials/COH.aip.water.2dm

1
examples/PACKAGES/interlayer/ilp_tmds/MoS2.ILP
View File

@ -1 +0,0 @@
../../../../potentials/MoS2.ILP

1
examples/PACKAGES/interlayer/ilp_tmds/TMD.ILP Symbolic link
View File

@ -0,0 +1 @@
../../../../potentials/TMD.ILP

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