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

Merge branch 'lammps:develop' into bond_react_fixes_aug23

Browse Source
This commit is contained in:
Jacob Gissinger
2023-12-17 17:02:18 -05:00
committed by GitHub
parent 1039f86037 df7f3b8dea
commit e6a510ddc5
1665 changed files with 120782 additions and 48725 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
.github/CODEOWNERS vendored
View File

@ -61,6 +61,7 @@ src/GPU/pair_vashishta_gpu.* @andeplane
src/KOKKOS/pair_vashishta_kokkos.* @andeplane
src/MANYBODY/pair_vashishta_table.* @andeplane
src/MANYBODY/pair_atm.* @sergeylishchuk
src/MANYBODY/pair_nb3b_screened.* @flodesani
src/REPLICA/*_grem.* @dstelter92
src/EXTRA-COMPUTE/compute_stress_mop*.* @RomainVermorel
src/EXTRA-COMPUTE/compute_born_matrix.* @Bibobu @athomps
@ -135,6 +136,7 @@ src/timer.* @akohlmey
src/utils.* @akohlmey @rbberger
src/verlet.* @sjplimp @stanmoore1
src/math_eigen_impl.h @jewettaij
src/fix_press_langevin.* @Bibobu
# tools
tools/coding_standard/* @akohlmey @rbberger
@ -151,12 +153,12 @@ tools/vim/* @hammondkd
unittest/* @akohlmey
# cmake
cmake/* @rbberger
cmake/* @akohlmey
cmake/Modules/LAMMPSInterfacePlugin.cmake @akohlmey
cmake/Modules/MPI4WIN.cmake @akohlmey
cmake/Modules/OpenCLLoader.cmake @akohlmey
cmake/Modules/Packages/COLVARS.cmake @rbberger @giacomofiorin
cmake/Modules/Packages/KIM.cmake @rbberger @ellio167
cmake/Modules/Packages/COLVARS.cmake @giacomofiorin
cmake/Modules/Packages/KIM.cmake @ellio167
cmake/presets/*.cmake @akohlmey
# python

22
.github/CONTRIBUTING.md vendored
View File

@ -5,9 +5,9 @@ Thank you for considering to contribute to the LAMMPS software project.
The following is a set of guidelines as well as explanations of policies and work flows for contributing to the LAMMPS molecular dynamics software project. These guidelines focus on submitting issues or pull requests on the LAMMPS GitHub project.
Thus please also have a look at:
* [The guide for submitting new features in the LAMMPS manual](https://www.lammps.org/doc/Modify_contribute.html)
* [The guide on programming style and requirement in the LAMMPS manual](https://www.lammps.org/doc/Modify_style.html)
* [The GitHub tutorial in the LAMMPS manual](http://lammps.sandia.gov/doc/Howto_github.html)
* [The guide for submitting new features in the LAMMPS manual](https://docs.lammps.org/Modify_contribute.html)
* [The guide on programming style and requirement in the LAMMPS manual](https://docs.lammps.org/Modify_requirements.html)
* [The GitHub tutorial in the LAMMPS manual](http://docs.lammps.org/Howto_github.html)
## Table of Contents
@ -27,17 +27,17 @@ __
## I don't want to read this whole thing I just have a question!
> **Note:** Please do not file an issue to ask a general question about LAMMPS, its features, how to use specific commands, or how perform simulations or analysis in LAMMPS. Instead post your question to either the ['lammps-users' mailing list](https://lammps.sandia.gov/mail.html) or the [LAMMPS Material Science Discourse forum](https://matsci.org/lammps). You do not need to be subscribed to post to the list (but a mailing list subscription avoids having your post delayed until it is approved by a mailing list moderator). Most posts to the mailing list receive a response within less than 24 hours. Before posting to the mailing list, please read the [mailing list guidelines](https://lammps.sandia.gov/guidelines.html). Following those guidelines will help greatly to get a helpful response. Always mention which LAMMPS version you are using. The LAMMPS forum was recently created as part of a larger effort to build a materials science community and have discussions not just about using LAMMPS. Thus the forum may be also used for discussions that would be off-topic for the mailing list. Those will just have to be posted to a more general category.
> **Note:** Please do not file an issue to ask a general question about LAMMPS, its features, how to use specific commands, or how perform simulations or analysis in LAMMPS. Instead post your question to the [LAMMPS Material Science Discourse forum](https://matsci.org/lammps). Before posting to the forum, please read the general [guidelines](https://www.lammps.org/guidelines.html) and the forum specific [suggestions](https://matsci.org/t/please-read-this-first-guidelines-and-suggestions-for-posting-lammps-questions/49913). Following those guidelines and suggestions will help greatly to get a helpful response. *Always* mention which LAMMPS version you are using. The MatSci website may be also used for discussions that would be off-topic for the LAMMPS categories. Those will just have to be posted to a different category.
## How Can I Contribute?
There are several ways how you can actively contribute to the LAMMPS project: you can discuss compiling and using LAMMPS, and solving LAMMPS related problems with other LAMMPS users on the lammps-users mailing list or the forum, you can report bugs or suggest enhancements by creating issues on GitHub (or posting them to the lammps-users mailing list or posting in the LAMMPS Materials Science Discourse forum), and you can contribute by submitting pull requests on GitHub or e-mail your code
to one of the [LAMMPS core developers](https://lammps.sandia.gov/authors.html). As you may see from the aforementioned developer page, the LAMMPS software package includes the efforts of a very large number of contributors beyond the principal authors and maintainers.
to one of the [LAMMPS core developers](https://www.lammps.org/authors.html). As you may see from the aforementioned developer page, the LAMMPS software package includes the efforts of a very large number of contributors beyond the principal authors and maintainers.
### Discussing How To Use LAMMPS
The LAMMPS mailing list is hosted at SourceForge. The mailing list began in 2005, and now includes tens of thousands of messages in thousands of threads. LAMMPS developers try to respond to posted questions in a timely manner, but there are no guarantees. Please consider that people live in different timezone and may not have time to answer e-mails outside of their work hours.
You can post to list by sending your email to lammps-users at lists.sourceforge.net (no subscription required), but before posting, please read the [mailing list guidelines](https://lammps.sandia.gov/guidelines.html) to maximize your chances to receive a helpful response.
You can post to list by sending your email to lammps-users at lists.sourceforge.net (no subscription required), but before posting, please read the [mailing list guidelines](https://www.lammps.org/guidelines.html) to maximize your chances to receive a helpful response.
Anyone can browse/search previous questions/answers in the archives. You do not have to subscribe to the list to post questions, receive answers (to your questions), or browse/search the archives. You **do** need to subscribe to the list if you want emails for **all** the posts (as individual messages or in digest form), or to answer questions yourself. Feel free to sign up and help us out! Answering questions from fellow LAMMPS users is a great way to pay back the community for providing you a useful tool for free, and to pass on the advice you have received yourself to others. It improves your karma and helps you understand your own research better.
@ -47,7 +47,7 @@ The LAMMPS Materials Science Discourse forum was created recently to facilitate
### Reporting Bugs
While developers writing code for LAMMPS are careful to test their code, LAMMPS is such a large and complex software, that it is impossible to test for all combinations of features under all normal and not so normal circumstances. Thus bugs do happen, and if you suspect, that you have encountered one, please try to document it and report it as an [Issue](https://github.com/lammps/lammps/issues) on the LAMMPS GitHub project web page. However, before reporting a bug, you need to check whether this is something that may have already been corrected. The [Latest Features and Bug Fixes in LAMMPS](https://lammps.sandia.gov/bug.html) web page lists all significant changes to LAMMPS over the years. It also tells you what the current latest development version of LAMMPS is, and you should test whether your issue still applies to that version.
While developers writing code for LAMMPS are careful to test their code, LAMMPS is such a large and complex software, that it is impossible to test for all combinations of features under all normal and not so normal circumstances. Thus bugs do happen, and if you suspect, that you have encountered one, please try to document it and report it as an [Issue](https://github.com/lammps/lammps/issues) on the LAMMPS GitHub project web page. However, before reporting a bug, you need to check whether this is something that may have already been corrected. The [Latest Features and Bug Fixes in LAMMPS](https://www.lammps.org/bug.html) web page lists all significant changes to LAMMPS over the years. It also tells you what the current latest development version of LAMMPS is, and you should test whether your issue still applies to that version.
When you click on the green "New Issue" button, you will be provided with a text field, where you can enter your message. That text field with contain a template with several headlines and some descriptions. Keep the headlines that are relevant to your reported potential bug and replace the descriptions with the information as suggested by the descriptions.
You can also attach small text files (please add the file name extension `.txt` or it will be rejected), images, or small compressed text files (using gzip, do not use RAR or 7-ZIP or similar tools that are uncommon outside of Windows machines). In many cases, bugs are best illustrated by providing a small input deck (do **not** attach your entire production input, but remove everything that is not required to reproduce the issue, and scale down your system size, that the resulting calculation runs fast and can be run on small desktop quickly).
@ -65,9 +65,9 @@ To be able to submit an issue on GitHub, you have to register for an account (fo
We encourage users to submit new features or modifications for LAMMPS. Instructions, guidelines, requirements,
and recommendations are in the following sections of the LAMMPS manual:
* [The guide for submitting new features in the LAMMPS manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
* [The guide on programming style and requirement in the LAMMPS manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
* [The GitHub tutorial in the LAMMPS manual](http://lammps.sandia.gov/doc/Howto_github.html)
* [The guide for submitting new features in the LAMMPS manual](https://docs.lammps.org/Modify_contribute.html)
* [The guide on programming style and requirement in the LAMMPS manual](https://docs.lammps.org/Modify_requirements.html)
* [The GitHub tutorial in the LAMMPS manual](http://docs.lammps.org/Howto_github.html)
## GitHub Workflows
@ -85,7 +85,7 @@ For bug reports, the next step is that one of the core LAMMPS developers will se
### Pull Requests
Pull requests are the **only** way that changes get made to the LAMMPS distribution. So also the LAMMPS core developers will submit pull requests for their own changes and discuss them on GitHub. Thus if you submit a pull request it will be treated in a similar fashion. When you submit a pull request you may opt to submit a "Draft" pull request. That means your changes are visible and will be subject to testing, but reviewers will not be (auto-)assigned and comments will take into account that this is not complete. On the other hand, this is a perfect way to ask the LAMMPS developers for comments on non-obvious changes and get feedback and possible suggestions for improvements or recommendations about what to avoid.
Immediately after the submission, the LAMMPS continuing integration server at ci.lammps.org will download your submitted branch and perform a number of tests: it will tests whether it compiles cleanly under various conditions, it will also do a check on whether your included documentation translates cleanly and run some unit tests and other checks. Whether these tests are successful or fail will be recorded. If a test fails, please inspect the corresponding output on the CI server and take the necessary steps, if needed, so that the code can compile cleanly again. The test will be re-run each time the pull request is updated with a push to the remote branch on GitHub. If you are unsure about what you need to change, ask a question in the discussion area of the pull request.
Immediately after the submission, the LAMMPS continuing integration server at https://ci.lammps.org will download your submitted branch and perform a number of tests: it will tests whether it compiles cleanly under various conditions, it will also do a check on whether your included documentation translates cleanly and run some unit tests and other checks. Whether these tests are successful or fail will be recorded. If a test fails, please inspect the corresponding output on the CI server and take the necessary steps, if needed, so that the code can compile cleanly again. The test will be re-run each time the pull request is updated with a push to the remote branch on GitHub. If you are unsure about what you need to change, ask a question in the discussion area of the pull request.
Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission. If you submitted a draft pull request, this will not happen unless you mark it "ready for review". If you are not yet invited as a LAMMPS collaborator, and your contribution seems significant, you may also receive an invitation for collaboration on the LAMMPS repository. As part of the assessment, the pull request will be categorized with labels. There are two special labels: `needs_work` (indicates that work from the submitter of the pull request is needed) and `work_in_progress` (indicates, that the assigned LAMMPS developer will make changes, if not done by the contributor who made the submit).
You may also receive comments and suggestions on the overall submission or specific details and on occasion specific requests for changes as part of the review. If permitted, also additional changes may be pushed into your pull request branch or a pull request may be filed in your LAMMPS fork on GitHub to include those changes.
The LAMMPS developer may then decide to assign the pull request to another developer (e.g. when that developer is more knowledgeable about the submitted feature or enhancement or has written the modified code). It may also happen, that additional developers are requested to provide a review and approve the changes. For submissions, that may change the general behavior of LAMMPS, or where a possibility of unwanted side effects exists, additional tests may be requested by the assigned developer.

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

@ -25,12 +25,12 @@ jobs:
steps:
- name: Checkout repository
uses: actions/checkout@v3
uses: actions/checkout@v4
with:
fetch-depth: 2
- name: Setup Python
uses: actions/setup-python@v4
uses: actions/setup-python@v5
with:
python-version: '3.x'

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

@ -19,12 +19,12 @@ jobs:
steps:
- name: Checkout repository
uses: actions/checkout@v3
uses: actions/checkout@v4
with:
fetch-depth: 2
- name: Select Python version
uses: actions/setup-python@v4
uses: actions/setup-python@v5
with:
python-version: '3.11'

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

@ -16,7 +16,7 @@ jobs:
steps:
- name: Checkout repository
uses: actions/checkout@v3
uses: actions/checkout@v4
with:
fetch-depth: 2
@ -59,16 +59,13 @@ jobs:
-D BUILD_SHARED_LIBS=on \
-D LAMMPS_SIZES=SMALLBIG \
-D LAMMPS_EXCEPTIONS=off \
-D PKG_MESSAGE=on \
-D PKG_MPIIO=on \
-D PKG_ATC=on \
-D PKG_AWPMD=on \
-D PKG_BOCS=on \
-D PKG_EFF=on \
-D PKG_H5MD=on \
-D PKG_INTEL=on \
-D PKG_LATBOLTZ=on \
-D PKG_MANIFOLD=on \
-D PKG_MDI=on \
-D PKG_MGPT=on \
-D PKG_ML-PACE=on \
-D PKG_ML-RANN=on \
@ -77,7 +74,6 @@ jobs:
-D PKG_PTM=on \
-D PKG_QTB=on \
-D PKG_SMTBQ=on \
-D PKG_TALLY=on \
../cmake
- name: Run Coverity Scan

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

@ -21,7 +21,7 @@ jobs:
steps:
- name: Checkout repository
uses: actions/checkout@v3
uses: actions/checkout@v4
with:
fetch-depth: 2

111
cmake/CMakeLists.txt
View File

@ -2,7 +2,6 @@
########################################
# CMake build system
# This file is part of LAMMPS
# Created by Christoph Junghans and Richard Berger
cmake_minimum_required(VERSION 3.16)
########################################
# set policy to silence warnings about ignoring <PackageName>_ROOT but use it
@ -106,7 +105,7 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
set(CMAKE_TUNE_DEFAULT "-xCOMMON-AVX512")
else()
set(CMAKE_TUNE_DEFAULT "-xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=2196")
set(CMAKE_TUNE_DEFAULT "-xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=11074 -diag-disable=11076 -diag-disable=2196")
endif()
endif()
endif()
@ -159,17 +158,20 @@ endif()
########################################################################
# User input options #
########################################################################
# set path to python interpreter and thus enforcing python version when
# in a virtual environment and PYTHON_EXECUTABLE is not set on command line
if(DEFINED ENV{VIRTUAL_ENV} AND NOT PYTHON_EXECUTABLE)
if(CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows")
set(PYTHON_EXECUTABLE "$ENV{VIRTUAL_ENV}/Scripts/python.exe")
else()
set(PYTHON_EXECUTABLE "$ENV{VIRTUAL_ENV}/bin/python")
endif()
# backward compatibility with CMake before 3.12 and older LAMMPS documentation
if (PYTHON_EXECUTABLE)
set(Python_EXECUTABLE "${PYTHON_EXECUTABLE}")
endif()
# set path to python interpreter and thus enforcing python version when
# in a virtual environment and Python_EXECUTABLE is not set on command line
if(DEFINED ENV{VIRTUAL_ENV} AND NOT Python_EXECUTABLE)
if(CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows")
set(Python_EXECUTABLE "$ENV{VIRTUAL_ENV}/Scripts/python.exe")
else()
set(Python_EXECUTABLE "$ENV{VIRTUAL_ENV}/bin/python")
endif()
message(STATUS "Running in virtual environment: $ENV{VIRTUAL_ENV}\n"
" Setting Python interpreter to: ${PYTHON_EXECUTABLE}")
" Setting Python interpreter to: ${Python_EXECUTABLE}")
endif()
set(LAMMPS_MACHINE "" CACHE STRING "Suffix to append to lmp binary (WON'T enable any features automatically")
@ -425,6 +427,18 @@ if(BUILD_OMP)
target_link_libraries(lmp PRIVATE OpenMP::OpenMP_CXX)
endif()
# lower C++ standard for fmtlib sources when using Intel classic compiler
if((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_STANDARD GREATER_EQUAL 17)
AND (CMAKE_CXX_COMPILER_VERSION VERSION_LESS 2021.10))
message(STATUS "Lowering C++ standard for compiling fmtlib sources with Intel Classic compiler")
get_filename_component(LMP_UTILS_SRC "${LAMMPS_SOURCE_DIR}/utils.cpp" ABSOLUTE)
get_filename_component(LMP_VARIABLE_SRC "${LAMMPS_SOURCE_DIR}/variable.cpp" ABSOLUTE)
get_filename_component(FMT_FORMAT_SRC "${LAMMPS_SOURCE_DIR}/fmtlib_format.cpp" ABSOLUTE)
get_filename_component(FMT_OS_SRC "${LAMMPS_SOURCE_DIR}/fmtlib_os.cpp" ABSOLUTE)
set_source_files_properties("${FMT_FORMAT_SRC}" "${FMT_OS_SRC}" "${LMP_VARIABLE_SRC}" "${LMP_UTILS_SRC}"
PROPERTIES COMPILE_OPTIONS "-std=c++14")
endif()
if(PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_ML-POD OR PKG_ELECTRODE OR BUILD_TOOLS)
enable_language(C)
if (NOT USE_INTERNAL_LINALG)
@ -794,9 +808,6 @@ install(
###############################################################################
if(BUILD_SHARED_LIBS)
# backward compatibility
if(PYTHON_EXECUTABLE)
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
endif()
find_package(Python COMPONENTS Interpreter)
if(BUILD_IS_MULTI_CONFIG)
set(MY_BUILD_DIR ${CMAKE_BINARY_DIR}/$<CONFIG>)
@ -960,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()

14
cmake/Modules/LAMMPSUtils.cmake
View File

@ -83,17 +83,17 @@ function(check_for_autogen_files source_dir)
file(GLOB SRC_AUTOGEN_FILES CONFIGURE_DEPENDS ${source_dir}/style_*.h)
file(GLOB SRC_AUTOGEN_PACKAGES CONFIGURE_DEPENDS ${source_dir}/packages_*.h)
list(APPEND SRC_AUTOGEN_FILES ${SRC_AUTOGEN_PACKAGES} ${source_dir}/lmpinstalledpkgs.h ${source_dir}/lmpgitversion.h)
list(APPEND SRC_AUTOGEN_FILES ${SRC_AUTOGEN_PACKAGES} ${source_dir}/mliap_model_python_couple.h ${source_dir}/mliap_model_python_couple.cpp)
list(APPEND SRC_AUTOGEN_FILES ${source_dir}/mliap_model_python_couple.h ${source_dir}/mliap_model_python_couple.cpp)
foreach(_SRC ${SRC_AUTOGEN_FILES})
get_filename_component(FILENAME "${_SRC}" NAME)
if(EXISTS ${source_dir}/${FILENAME})
message(FATAL_ERROR "\n########################################################################\n"
"Found header file(s) generated by the make-based build system\n"
"\n"
"Please run\n"
"make -C ${source_dir} purge\n"
"to remove\n"
"########################################################################")
"Found header file ${source_dir}/${FILENAME} generated by the make-based build system\n"
"\n"
"Please run\n"
"make -C ${source_dir} purge\n"
"to remove\n"
"########################################################################")
endif()
endforeach()
endfunction()

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

@ -151,10 +151,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)

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

@ -50,8 +50,8 @@ if(DOWNLOAD_KOKKOS)
list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
include(ExternalProject)
set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.1.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
set(KOKKOS_MD5 "a5f096bd8ad01b97fdc7a32583b17a33" CACHE STRING "MD5 checksum of KOKKOS tarball")
set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.2.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
set(KOKKOS_MD5 "731647b61a4233f568d583702e9cd6d1" CACHE STRING "MD5 checksum of KOKKOS tarball")
mark_as_advanced(KOKKOS_URL)
mark_as_advanced(KOKKOS_MD5)
GetFallbackURL(KOKKOS_URL KOKKOS_FALLBACK)
@ -76,7 +76,7 @@ if(DOWNLOAD_KOKKOS)
add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
elseif(EXTERNAL_KOKKOS)
find_package(Kokkos 4.1.00 REQUIRED CONFIG)
find_package(Kokkos 4.2.00 REQUIRED CONFIG)
target_link_libraries(lammps PRIVATE Kokkos::kokkos)
else()
set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)

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

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.01.3.fix.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.11.25.fix.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
set(PACELIB_MD5 "4f0b3b5b14456fe9a73b447de3765caa" 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})

2
cmake/Modules/Packages/PYTHON.cmake
View File

@ -1,6 +1,6 @@
if(NOT Python_INTERPRETER)
# backward compatibility
# backward compatibility with CMake before 3.12 and older LAMMPS documentation
if(PYTHON_EXECUTABLE)
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
endif()

BIN
cmake/packaging/LAMMPS_DMG_Background.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 85 KiB

After

Width:  |  Height:  |  Size: 86 KiB

2
cmake/packaging/MacOSXBundleInfo.plist.in
View File

@ -17,7 +17,7 @@
<key>CFBundleLongVersionString</key>
<string>${MACOSX_BUNDLE_LONG_VERSION_STRING}</string>
<key>CFBundleName</key>
<string>LAMMPS</string>
<string>LAMMPS_GUI</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleShortVersionString</key>

26
cmake/packaging/README.macos
View File

@ -9,7 +9,7 @@ of the available packages.
The following individual commands are included:
binary2txt lammps-gui lmp msi2lmp phana stl_bin2txt
After copying the lammps-gui folder into your Applications folder, please follow
After copying the LAMMPS_GUI folder into your Applications folder, please follow
these steps:
1. Open the Terminal app
@ -23,7 +23,7 @@ these steps:
3. Add the following lines to the end of the file, save it, and close the editor
LAMMPS_INSTALL_DIR=/Applications/LAMMPS.app/Contents
LAMMPS_INSTALL_DIR=/Applications/LAMMPS_GUI.app/Contents
LAMMPS_POTENTIALS=${LAMMPS_INSTALL_DIR}/share/lammps/potentials
LAMMPS_BENCH_DIR=${LAMMPS_INSTALL_DIR}/share/lammps/bench
MSI2LMP_LIBRARY=${LAMMPS_INSTALL_DIR}/share/lammps/frc_files
@ -38,9 +38,9 @@ these steps:
the changes from .zprofile automatically.
Note: the above assumes you use the default shell (zsh) that comes with
MacOS. If you customized MacOS to use a different shell, you'll need to modify
that shell's init file (.cshrc, .bashrc, etc.) instead with appropiate commands
to modify the same environment variables.
MacOS. If you customized MacOS to use a different shell, you'll need to
modify that shell's init file (.cshrc, .bashrc, etc.) instead with
appropiate commands to modify the same environment variables.
5. Try running LAMMPS (which might fail, see step 7)
@ -50,10 +50,10 @@ these steps:
lammps-gui ${LAMMPS_BENCH_DIR}/in.rhodo
Depending on the size and resolution of your screen, the fonts may
be too small to read. This can be adjusted by setting the environment
variable QT_FONT_DPI. The default value would be 72, so to increase
the fonts by a third one can add to the .zprofile file the line
Depending on the size and resolution of your screen, the fonts may be too
small to read. This can be adjusted by setting the environment variable
QT_FONT_DPI. The default value would be 72, so to increase the fonts by a
third, one can add to the .zprofile file the line
export QT_FONT_DPI=96
@ -61,9 +61,9 @@ these steps:
7. Give permission to execute the commands (lmp, lammps-gui, msi2lmp, binary2txt, phana, stl_bin2txt)
MacOS will likely block the initial run of the executables, since they
were downloaded from the internet and are missing a known signature from an
identified developer. Go to "Settings" and search for "Security settings". It
should display a message that an executable like "lmp" was blocked. Press
MacOS will likely block the initial run of the executables, since they were
downloaded from the internet and are missing a known signature from an
identified developer. Go to "Settings" and search for "Security settings".
It should display a message that an executable like "lmp" was blocked. Press
"Open anyway", which might prompt you for your admin credentials. Afterwards
"lmp" and the other executables should work as expected.

4
cmake/packaging/build_linux_tgz.sh
View File

@ -4,7 +4,7 @@ APP_NAME=lammps-gui
DESTDIR=${PWD}/../LAMMPS_GUI
echo "Delete old files, if they exist"
rm -rf ${DESTDIR} ../LAMMPS-Linux-amd64.tar.gz
rm -rf ${DESTDIR} ../LAMMPS_GUI-Linux-amd64.tar.gz
echo "Create staging area for deployment and populate"
DESTDIR=${DESTDIR} cmake --install . --prefix "/"
@ -69,7 +69,7 @@ do \
done
pushd ..
tar -czvvf LAMMPS-Linux-amd64.tar.gz LAMMPS_GUI
tar -czvvf LAMMPS_GUI-Linux-amd64.tar.gz LAMMPS_GUI
popd
echo "Cleanup dir"

14
cmake/packaging/build_macos_dmg.sh
View File

@ -3,7 +3,7 @@
APP_NAME=lammps-gui
echo "Delete old files, if they exist"
rm -f ${APP_NAME}.dmg ${APP_NAME}-rw.dmg LAMMPS-macOS-multiarch.dmg
rm -f ${APP_NAME}.dmg ${APP_NAME}-rw.dmg LAMMPS_GUI-macOS-multiarch.dmg
echo "Create initial dmg file with macdeployqt"
macdeployqt lammps-gui.app -dmg
@ -22,8 +22,8 @@ ln -s /Applications .
mv ${APP_NAME}.app/Contents/Resources/README.txt .
mkdir .background
mv ${APP_NAME}.app/Contents/Resources/LAMMPS_DMG_Background.png .background/background.png
mv ${APP_NAME}.app LAMMPS.app
cd LAMMPS.app/Contents
mv ${APP_NAME}.app LAMMPS_GUI.app
cd LAMMPS_GUI.app/Contents
echo "Attach icons to LAMMPS console and GUI executables"
echo "read 'icns' (-16455) \"Resources/lammps.icns\";" > icon.rsrc
@ -75,7 +75,7 @@ echo '
set statusbar visible to false
set toolbar visible to false
set the bounds to { 100, 40, 868, 640 }
set position of item "'LAMMPS'.app" to { 190, 216 }
set position of item "'LAMMPS_GUI'.app" to { 190, 216 }
set position of item "Applications" to { 576, 216 }
set position of item "README.txt" to { 190, 400 }
end tell
@ -96,12 +96,12 @@ sync
echo "Unmount modified disk image and convert to compressed read-only image"
hdiutil detach "${DEVICE}"
hdiutil convert "${APP_NAME}-rw.dmg" -format UDZO -o "LAMMPS-macOS-multiarch.dmg"
hdiutil convert "${APP_NAME}-rw.dmg" -format UDZO -o "LAMMPS_GUI-macOS-multiarch.dmg"
echo "Attach icon to .dmg file"
echo "read 'icns' (-16455) \"lammps-gui.app/Contents/Resources/lammps.icns\";" > icon.rsrc
Rez -a icon.rsrc -o LAMMPS-macOS-multiarch.dmg
SetFile -a C LAMMPS-macOS-multiarch.dmg
Rez -a icon.rsrc -o LAMMPS_GUI-macOS-multiarch.dmg
SetFile -a C LAMMPS_GUI-macOS-multiarch.dmg
rm icon.rsrc
echo "Delete temporary disk images"

11
cmake/packaging/build_windows_vs.cmake
View File

@ -1,7 +1,7 @@
# CMake script to be run post installation to build zipped package
# clean up old zipfile and deployment tree
file(REMOVE LAMMPS-Win10-amd64.zip)
file(REMOVE LAMMPS_GUI-Win10-amd64.zip)
file(REMOVE_RECURSE LAMMPS_GUI)
file(RENAME ${INSTNAME} LAMMPS_GUI)
@ -21,8 +21,15 @@ file(WRITE qtdeploy.bat "@ECHO OFF\r\nset VSCMD_DEBUG=0\r\nCALL ${VC_INIT} x64\r
execute_process(COMMAND cmd.exe /c qtdeploy.bat COMMAND_ECHO STDERR)
file(REMOVE qtdeploy.bat)
# download and uncompress static FFMpeg and gzip binaries
file(DOWNLOAD "https://download.lammps.org/thirdparty/ffmpeg-gzip.zip" ffmpeg-gzip.zip)
file(WRITE unpackzip.ps1 "Expand-Archive -Path ffmpeg-gzip.zip -DestinationPath LAMMPS_GUI")
execute_process(COMMAND powershell -ExecutionPolicy Bypass -File unpackzip.ps1)
file(REMOVE unpackzip.ps1)
file(REMOVE ffmpeg-gzip.zip)
# create zip archive
file(WRITE makearchive.ps1 "Compress-Archive -Path LAMMPS_GUI -CompressionLevel Optimal -DestinationPath LAMMPS-Win10-amd64.zip")
file(WRITE makearchive.ps1 "Compress-Archive -Path LAMMPS_GUI -CompressionLevel Optimal -DestinationPath LAMMPS_GUI-Win10-amd64.zip")
execute_process(COMMAND powershell -ExecutionPolicy Bypass -File makearchive.ps1)
file(REMOVE makearchive.ps1)
file(REMOVE_RECURSE LAMMPS_GUI)

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)

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

@ -6,6 +6,8 @@ set(Kokkos_ENABLE_SERIAL ON CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_CUDA ON CACHE BOOL "" FORCE)
set(Kokkos_ARCH_PASCAL60 ON CACHE BOOL "" FORCE)
set(BUILD_OMP ON CACHE BOOL "" FORCE)
get_filename_component(NVCC_WRAPPER_CMD ${CMAKE_CURRENT_SOURCE_DIR}/../lib/kokkos/bin/nvcc_wrapper ABSOLUTE)
set(CMAKE_CXX_COMPILER ${NVCC_WRAPPER_CMD} CACHE FILEPATH "" FORCE)
# hide deprecation warnings temporarily for stable release
set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)

2
cmake/presets/macos-multiarch.cmake
View File

@ -10,5 +10,3 @@ set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
set(BUILD_MPI FALSE CACHE BOOL "" FORCE)
set(BUILD_SHARED_LIBS FALSE CACHE BOOL "" FORCE)
set(LAMMPS_EXCEPTIONS TRUE CACHE BOOL "" FORCE)

4
doc/Makefile
View File

@ -63,6 +63,7 @@ help:
@echo " anchor_check scan for duplicate anchor labels"
@echo " style_check check for complete and consistent style lists"
@echo " package_check check for complete and consistent package lists"
@echo " role_check check for misformatted role keywords"
@echo " spelling spell-check the manual"
# ------------------------------------------
@ -98,6 +99,7 @@ html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst ;\
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 ;\
$(PYTHON) $(BUILDDIR)/utils/check-styles.py -s ../src -d src ;\
echo "############################################" ;\
deactivate ;\
@ -179,6 +181,7 @@ pdf: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst ;\
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 ;\
$(PYTHON) utils/check-styles.py -s ../src -d src ;\
echo "############################################" ;\
deactivate ;\
@ -227,6 +230,7 @@ char_check :
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 || : )
link_check : $(VENV) html
@(\

4
doc/lammps.1
View File

@ -1,7 +1,7 @@
.TH LAMMPS "1" "2 August 2023" "2023-08-2"
.TH LAMMPS "1" "21 November 2023" "2023-11-21"
.SH NAME
.B LAMMPS
\- Molecular Dynamics Simulator. Version 2 August 2023
\- Molecular Dynamics Simulator. Version 21 November 2023
.SH SYNOPSIS
.B lmp

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)

6
doc/src/Build_basics.rst
View File

@ -488,8 +488,9 @@ using CMake or Make.
.. code-block:: bash
-D BUILD_TOOLS=value # yes or no (default)
-D BUILD_LAMMPS_SHELL=value # yes or no (default)
-D BUILD_TOOLS=value # yes or no (default). Build binary2txt, chain.x, micelle2d.x, msi2lmp, phana, stl_bin2txt
-D BUILD_LAMMPS_SHELL=value # yes or no (default). Build lammps-shell
-D BUILD_LAMMPS_GUI=value # yes or no (default). Build lammps-gui
The generated binaries will also become part of the LAMMPS installation
(see below).
@ -503,7 +504,6 @@ using CMake or Make.
make binary2txt # build only binary2txt tool
make chain # build only chain tool
make micelle2d # build only micelle2d tool
make thermo_extract # build only thermo_extract tool
cd lammps/tools/lammps-shell
make # build LAMMPS shell

14
doc/src/Build_cmake.rst
View File

@ -177,13 +177,13 @@ configuration is selected with the *-C* flag:
ctest -C Debug
The CMake scripts in LAMMPS have basic support for being compiled using a
multi-config build system, but not all of it has been ported. This is in
particular applicable to compiling packages that require additional libraries
that would be downloaded and compiled by CMake. The "windows" preset file
tries to keep track of which packages can be compiled natively with the
MSVC compilers out-of-the box. Not all of those external libraries are
portable to Windows, either.
The CMake scripts in LAMMPS have basic support for being compiled using
a multi-config build system, but not all of it has been ported. This is
in particular applicable to compiling packages that require additional
libraries that would be downloaded and compiled by CMake. The
``windows.cmake`` preset file tries to keep track of which packages can
be compiled natively with the MSVC compilers out-of-the box. Not all of
the external libraries are portable to Windows, either.
Installing CMake

2
doc/src/Build_development.rst
View File

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

219
doc/src/Build_extras.rst
View File

@ -626,22 +626,22 @@ They must be specified in uppercase.
* - HOPPER90
- GPU
- NVIDIA Hopper generation CC 9.0 GPU
* - VEGA900
* - AMD_GFX906
- GPU
- AMD GPU MI25 GFX900
* - VEGA906
- AMD GPU MI50/MI60
* - AMD_GFX908
- GPU
- AMD GPU MI50/MI60 GFX906
* - VEGA908
- AMD GPU MI100
* - AMD_GFX90A
- GPU
- AMD GPU MI100 GFX908
* - VEGA90A
- AMD GPU MI200
* - AMD_GFX942
- GPU
- AMD GPU MI200 GFX90A
* - NAVI1030
- AMD GPU MI300
* - AMD_GFX1030
- GPU
- AMD GPU V620/W6800
* - NAVI1100
* - AMD_GFX1100
- GPU
- AMD GPU RX7900XTX
* - INTEL_GEN
@ -666,7 +666,7 @@ They must be specified in uppercase.
- GPU
- Intel GPU Ponte Vecchio
This list was last updated for version 4.0.1 of the Kokkos library.
This list was last updated for version 4.2 of the Kokkos library.
.. tabs::
@ -722,9 +722,10 @@ This list was last updated for version 4.0.1 of the Kokkos library.
``cmake/presets`` folder, ``kokkos-serial.cmake``,
``kokkos-openmp.cmake``, ``kokkos-cuda.cmake``,
``kokkos-hip.cmake``, and ``kokkos-sycl.cmake``. They will enable
the KOKKOS package and enable some hardware choice. So to compile
with CUDA device parallelization (for GPUs with CC 5.0 and up)
with some common packages enabled, you can do the following:
the KOKKOS package and enable some hardware choices. For GPU
support those preset files must be customized to match the
hardware used. So to compile with CUDA device parallelization with
some common packages enabled, you can do the following:
.. code-block:: bash
@ -886,6 +887,50 @@ included in the LAMMPS source distribution in the ``lib/lepton`` folder.
----------
.. _machdyn:
MACHDYN package
-------------------------------
To build with this package, you must download the Eigen3 library.
Eigen3 is a template library, so you do not need to build it.
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D DOWNLOAD_EIGEN3 # download Eigen3, value = no (default) or yes
-D EIGEN3_INCLUDE_DIR=path # path to Eigen library (only needed if a custom location)
If ``DOWNLOAD_EIGEN3`` is set, the Eigen3 library will be
downloaded and inside the CMake build directory. If the Eigen3
library is already on your system (in a location where CMake
cannot find it), set ``EIGEN3_INCLUDE_DIR`` to the directory the
``Eigen3`` include file is in.
.. tab:: Traditional make
You can download the Eigen3 library manually if you prefer; follow
the instructions in ``lib/machdyn/README``. You can also do it in one
step from the ``lammps/src`` dir, using a command like these,
which simply invokes the ``lib/machdyn/Install.py`` script with the
specified args:
.. code-block:: bash
make lib-machdyn # print help message
make lib-machdyn args="-b" # download to lib/machdyn/eigen3
make lib-machdyn args="-p /usr/include/eigen3" # use existing Eigen installation in /usr/include/eigen3
Note that a symbolic (soft) link named ``includelink`` is created
in ``lib/machdyn`` to point to the Eigen dir. When LAMMPS builds it
will use this link. You should not need to edit the
``lib/machdyn/Makefile.lammps`` file.
----------
.. _mliap:
ML-IAP package
@ -1011,12 +1056,12 @@ additional details.
.. code-block:: bash
-D PYTHON_EXECUTABLE=path # path to Python executable to use
-D Python_EXECUTABLE=path # path to Python executable to use
Without this setting, CMake will guess the default Python version
on your system. To use a different Python version, you can either
create a virtualenv, activate it and then run cmake. Or you can
set the PYTHON_EXECUTABLE variable to specify which Python
set the Python_EXECUTABLE variable to specify which Python
interpreter should be used. Note note that you will also need to
have the development headers installed for this version,
e.g. python2-devel.
@ -1431,6 +1476,55 @@ ML-POD package
----------
.. _ml-quip:
ML-QUIP package
---------------------------------
To build with this package, you must download and build the QUIP
library. It can be obtained from GitHub. For support of GAP
potentials, additional files with specific licensing conditions need
to be downloaded and configured. The automatic download will from
within CMake will download the non-commercial use version.
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D DOWNLOAD_QUIP=value # download QUIP library for build, value = no (default) or yes
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
-D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
# value = no (default) or yes
CMake will try to download and build the QUIP library from GitHub,
if it is not found on the local machine. This requires to have git
installed. It will use the same compilers and flags as used for
compiling LAMMPS. Currently this is only supported for the GNU
and the Intel compilers. Set the ``QUIP_LIBRARY`` variable if you
want to use a previously compiled and installed QUIP library and
CMake cannot find it.
The QUIP library requires LAPACK (and BLAS) and CMake can identify
their locations and pass that info to the QUIP build script. But
on some systems this triggers a (current) limitation of CMake and
the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
those cases to use the bundled linear algebra library and work around
the limitation.
.. tab:: Traditional make
The download/build procedure for the QUIP library, described in
``lib/quip/README`` file requires setting two environment
variables, ``QUIP_ROOT`` and ``QUIP_ARCH``. These are accessed by
the ``lib/quip/Makefile.lammps`` file which is used when you
compile and link LAMMPS with this package. You should only need
to edit ``Makefile.lammps`` if the LAMMPS build can not use its
settings to successfully build on your system.
----------
.. _plumed:
PLUMED package
@ -1952,55 +2046,6 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to
----------
.. _ml-quip:
ML-QUIP package
---------------------------------
To build with this package, you must download and build the QUIP
library. It can be obtained from GitHub. For support of GAP
potentials, additional files with specific licensing conditions need
to be downloaded and configured. The automatic download will from
within CMake will download the non-commercial use version.
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D DOWNLOAD_QUIP=value # download QUIP library for build, value = no (default) or yes
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
-D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
# value = no (default) or yes
CMake will try to download and build the QUIP library from GitHub,
if it is not found on the local machine. This requires to have git
installed. It will use the same compilers and flags as used for
compiling LAMMPS. Currently this is only supported for the GNU
and the Intel compilers. Set the ``QUIP_LIBRARY`` variable if you
want to use a previously compiled and installed QUIP library and
CMake cannot find it.
The QUIP library requires LAPACK (and BLAS) and CMake can identify
their locations and pass that info to the QUIP build script. But
on some systems this triggers a (current) limitation of CMake and
the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
those cases to use the bundled linear algebra library and work around
the limitation.
.. tab:: Traditional make
The download/build procedure for the QUIP library, described in
``lib/quip/README`` file requires setting two environment
variables, ``QUIP_ROOT`` and ``QUIP_ARCH``. These are accessed by
the ``lib/quip/Makefile.lammps`` file which is used when you
compile and link LAMMPS with this package. You should only need
to edit ``Makefile.lammps`` if the LAMMPS build can not use its
settings to successfully build on your system.
----------
.. _scafacos:
SCAFACOS package
@ -2048,50 +2093,6 @@ To build with this package, you must download and build the
----------
.. _machdyn:
MACHDYN package
-------------------------------
To build with this package, you must download the Eigen3 library.
Eigen3 is a template library, so you do not need to build it.
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D DOWNLOAD_EIGEN3 # download Eigen3, value = no (default) or yes
-D EIGEN3_INCLUDE_DIR=path # path to Eigen library (only needed if a custom location)
If ``DOWNLOAD_EIGEN3`` is set, the Eigen3 library will be
downloaded and inside the CMake build directory. If the Eigen3
library is already on your system (in a location where CMake
cannot find it), set ``EIGEN3_INCLUDE_DIR`` to the directory the
``Eigen3`` include file is in.
.. tab:: Traditional make
You can download the Eigen3 library manually if you prefer; follow
the instructions in ``lib/smd/README``. You can also do it in one
step from the ``lammps/src`` dir, using a command like these,
which simply invokes the ``lib/smd/Install.py`` script with the
specified args:
.. code-block:: bash
make lib-smd # print help message
make lib-smd args="-b" # download to lib/smd/eigen3
make lib-smd args="-p /usr/include/eigen3" # use existing Eigen installation in /usr/include/eigen3
Note that a symbolic (soft) link named ``includelink`` is created
in ``lib/smd`` to point to the Eigen dir. When LAMMPS builds it
will use this link. You should not need to edit the
``lib/smd/Makefile.lammps`` file.
----------
.. _vtk:
VTK package

1
doc/src/Build_package.rst
View File

@ -182,6 +182,7 @@ make a copy of one of them and modify it to suit your needs.
cmake -C ../cmake/presets/all_on.cmake [OPTIONS] ../cmake # enable all packages
cmake -C ../cmake/presets/all_off.cmake [OPTIONS] ../cmake # disable all packages
mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake # compile with MinGW cross-compilers
cmake -C ../cmake/presets/macos-multiarch.cmake [OPTIONS] ../cmake # compile serial multi-arch binaries on macOS
Presets that have names starting with "windows" are specifically for
compiling LAMMPS :doc:`natively on Windows <Build_windows>` and

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

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

10
doc/src/Commands_fix.rst
View File

@ -69,7 +69,7 @@ OPT.
* :doc:`drude/transform/inverse <fix_drude_transform>`
* :doc:`dt/reset (k) <fix_dt_reset>`
* :doc:`edpd/source <fix_dpd_source>`
* :doc:`efield <fix_efield>`
* :doc:`efield (k) <fix_efield>`
* :doc:`efield/tip4p <fix_efield>`
* :doc:`ehex <fix_ehex>`
* :doc:`electrode/conp (i) <fix_electrode>`
@ -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>`
@ -181,6 +182,7 @@ OPT.
* :doc:`pour <fix_pour>`
* :doc:`precession/spin <fix_precession_spin>`
* :doc:`press/berendsen <fix_press_berendsen>`
* :doc:`press/langevin <fix_press_langevin>`
* :doc:`print <fix_print>`
* :doc:`propel/self <fix_propel_self>`
* :doc:`property/atom (k) <fix_property_atom>`
@ -232,15 +234,15 @@ OPT.
* :doc:`spring <fix_spring>`
* :doc:`spring/chunk <fix_spring_chunk>`
* :doc:`spring/rg <fix_spring_rg>`
* :doc:`spring/self <fix_spring_self>`
* :doc:`spring/self (k) <fix_spring_self>`
* :doc:`srd <fix_srd>`
* :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>`

23
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>`
@ -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>`
@ -220,7 +220,8 @@ OPT.
* :doc:`morse/soft <pair_fep_soft>`
* :doc:`multi/lucy <pair_multi_lucy>`
* :doc:`multi/lucy/rx (k) <pair_multi_lucy_rx>`
* :doc:`nb3b/harmonic <pair_nb3b_harmonic>`
* :doc:`nb3b/harmonic <pair_nb3b>`
* :doc:`nb3b/screened <pair_nb3b>`
* :doc:`nm/cut (o) <pair_nm>`
* :doc:`nm/cut/coul/cut (o) <pair_nm>`
* :doc:`nm/cut/coul/long (o) <pair_nm>`
@ -265,13 +266,13 @@ OPT.
* :doc:`smd/tri_surface <pair_smd_triangulated_surface>`
* :doc:`smd/ulsph <pair_smd_ulsph>`
* :doc:`smtbq <pair_smtbq>`
* :doc:`snap (k) <pair_snap>`
* :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>`
@ -305,5 +306,5 @@ OPT.
* :doc:`wf/cut <pair_wf_cut>`
* :doc:`ylz <pair_ylz>`
* :doc:`yukawa (gko) <pair_yukawa>`
* :doc:`yukawa/colloid (go) <pair_yukawa_colloid>`
* :doc:`yukawa/colloid (gko) <pair_yukawa_colloid>`
* :doc:`zbl (gko) <pair_zbl>`

15
doc/src/Commands_removed.rst
View File

@ -88,7 +88,7 @@ The same functionality is available through
MPIIO package
-------------
.. deprecated:: TBD
.. deprecated:: 21Nov2023
The MPIIO package has been removed from LAMMPS since it was unmaintained
for many years and thus not updated to incorporate required changes that
@ -107,7 +107,7 @@ see :doc:`restart <restart>`, :doc:`read_restart <read_restart>`,
MSCG package
------------
.. deprecated:: TBD
.. deprecated:: 21Nov2023
The MSCG package has been removed from LAMMPS since it was unmaintained
for many years and instead superseded by the `OpenMSCG software
@ -126,6 +126,17 @@ syntax compatible with the removed reax pair style, so input files will
have to be adapted. The REAXFF package was originally called
USER-REAXC.
USER-REAXC package
------------------
.. deprecated:: TBD
The USER-REAXC package has been renamed to :ref:`REAXFF <PKG-REAXFF>`.
In the process also the pair style and related fixes were renamed to use
the "reaxff" string instead of "reax/c". For a while LAMMPS was maintaining
backward compatibility by providing aliases for the styles. These have
been removed, so using "reaxff" is now *required*.
USER-CUDA package
-----------------

54
doc/src/Developer_unittest.rst
View File

@ -180,19 +180,11 @@ discarded but by setting the verbose flag (via setting the ``TEST_ARGS``
environment variable, ``TEST_ARGS=-v``) it can be printed and used to
understand why tests fail unexpectedly.
Another complexity of these tests stems from the need to capture
situations where LAMMPS will stop with an error, i.e. handle so-called
"death tests". Here the LAMMPS code will operate differently depending
on whether it was configured to throw C++ exceptions on errors or call
either ``exit()`` or ``MPI_Abort()``. In the latter case, the test code
also needs to detect whether LAMMPS was compiled with the OpenMPI
library, as OpenMPI is **only** compatible the death test options of the
GoogleTest library when C++ exceptions are enabled; otherwise those
"death tests" must be skipped to avoid reporting bogus failures. The
specifics of this step are implemented in the ``TEST_FAILURE()``
macro. These tests operate by capturing the screen output when executing
the failing command and then comparing that with a provided regular
expression string pattern. Example:
The specifics of so-called "death tests", i.e. conditions where LAMMPS
should fail and throw an exception, are implemented in the
``TEST_FAILURE()`` macro. These tests operate by capturing the screen
output when executing the failing command and then comparing that with a
provided regular expression string pattern. Example:
.. code-block:: c++
@ -282,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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -405,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
@ -442,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,
@ -480,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.

15
doc/src/Fortran.rst
View File

@ -3038,14 +3038,6 @@ Procedures Bound to the :f:type:`lammps` Derived Type
This function can be used to query if an error inside of LAMMPS
has thrown a :ref:`C++ exception <exceptions>`.
.. note::
This function will always report "no error" when the LAMMPS library
has been compiled without ``-DLAMMPS_EXCEPTIONS``, which turns fatal
errors aborting LAMMPS into C++ exceptions. You can use the library
function :cpp:func:`lammps_config_has_exceptions` to check if this is
the case.
:to: :cpp:func:`lammps_has_error`
:r has_error: ``.TRUE.`` if there is an error.
:rtype has_error: logical
@ -3068,13 +3060,6 @@ Procedures Bound to the :f:type:`lammps` Derived Type
would happen only in a single MPI rank and thus may not be recoverable, as
other MPI ranks may be waiting on the failing MPI rank(s) to send messages.
.. note::
This function will do nothing when the LAMMPS library has been
compiled without ``-DLAMMPS_EXCEPTIONS``, which turns errors aborting
LAMMPS into C++ exceptions. You can use the function
:f:func:`config_has_exceptions` to check whether this is the case.
:p character(len=\*) buffer: string buffer to copy the error message into
:o integer(c_int) status [optional]: 1 when all ranks had the error,
2 on a single-rank error.

1
doc/src/Howto.rst
View File

@ -101,6 +101,7 @@ Tutorials howto
Howto_cmake
Howto_github
Howto_lammps_gui
Howto_moltemplate
Howto_pylammps
Howto_wsl

8
doc/src/Howto_body.rst
View File

@ -170,9 +170,9 @@ with this body style to compute body/body and body/non-body interactions.
The *rounded/polygon* body style represents body particles as a 2d
polygon with a variable number of N vertices. This style can only be
used for 2d models; see the :doc:`boundary <boundary>` command. See the
"pair_style body/rounded/polygon" page for a diagram of two
squares with rounded circles at the vertices. Special cases for N = 1
(circle) and N = 2 (rod with rounded ends) can also be specified.
:doc:`pair_style body/rounded/polygon <pair_body_rounded_polygon>` page for
a diagram of two squares with rounded circles at the vertices. Special cases
for N = 1 (circle) and N = 2 (rod with rounded ends) can also be specified.
One use of this body style is for 2d discrete element models, as
described in :ref:`Fraige <body-Fraige>`.
@ -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

686
doc/src/Howto_lammps_gui.rst
View File

@ -1,111 +1,310 @@
Using the LAMMPS GUI
====================
LAMMPS GUI is a simple graphical text editor that is linked to the
:ref:`LAMMPS C-library interface <lammps_c_api>` and thus can run LAMMPS
directly using the contents of the editor's text buffer as input.
This is similar to what people traditionally would do to run LAMMPS:
using a regular text editor to edit the input and run the necessary
commands, possibly including the text editor, too, from a command line
terminal window. That is quite effective when running LAMMPS on
high-performance computing facilities and when you are very proficient
in using the command line. The main benefit of a GUI application is
that this integrates well with graphical desktop environments and many
basic tasks can be done directly from within the GUI without switching
to a text console or requiring external programs or scripts to extract
data from the generated output. This makes it easier for beginners to
get started running simple LAMMPS simulations and thus very suitable for
tutorials on LAMMPS. But also makes it easier to switch to a full
featured text editor and more sophisticated visualization and analysis
tools.
This document describes **LAMMPS GUI version 1.5**.
-----
LAMMPS GUI is a graphical text editor customized for editing LAMMPS
input files that is linked to the :ref:`LAMMPS library <lammps_c_api>`
and thus can run LAMMPS directly using the contents of the editor's text
buffer as input. It can retrieve and display information from LAMMPS
while it is running, display visualizations created with the :doc:`dump
image command <dump_image>`, and is adapted specifically for editing
LAMMPS input files through text completion and reformatting, and linking
to the online LAMMPS documentation for known LAMMPS commands and styles.
.. note::
Pre-compiled, ready-to-use LAMMPS GUI executables for Linux (Ubuntu
20.04LTS or later and compatible), macOS (version 11 aka Big Sur or
later), and Windows (version 10 or later) :ref:`are available
<lammps_gui_install>` for download. They may be linked to a
development version of LAMMPS in case they need features not yet
available in a released version. Serial LAMMPS executables of the
same LAMMPS version are included as well. The source code for the
LAMMPS GUI is included in the LAMMPS source code and can be found in
the ``tools/lammps-gui`` folder. It can be compiled alongside LAMMPS
when :doc:`compiling with CMake <Build_cmake>`.
LAMMPS GUI tries to provide an experience similar to what people
traditionally would do to run LAMMPS using a command line window:
- editing inputs with a text editor
- run LAMMPS on the input with selected command line flags
- and then use or extract data from the created files and visualize it
That procedure is quite effective for people proficient in using the
command line, as that allows them to use tools for the individual steps
which they are most comfortable with. It is often required when running
LAMMPS on high-performance computing facilities.
The main benefit of using the LAMMPS GUI application instead is that
many basic tasks can be done directly from the GUI without switching to
a text console window or using external programs, let alone writing
scripts to extract data from the generated output. It also integrates
well with graphical desktop environments.
LAMMPS GUI thus makes it easier for beginners to get started running
simple LAMMPS simulations. It is very suitable for tutorials on LAMMPS
since you only need to learn how to use a single program for most tasks
and thus time can be saved and people can focus on learning LAMMPS. It
is also designed to keep the barrier low when you decide to switch to a
full featured, standalone programming editor and more sophisticated
visualization and analysis tools and run LAMMPS from a command line.
The following text provides a detailed tour of the features and
functionality of the LAMMPS GUI. This document describes LAMMPS GUI
version 1.2.
functionality of the LAMMPS GUI.
Suggestions for new features and reports of bugs are always welcome.
You can use the :doc:`the same channels as for LAMMPS itself
<Errors_bugs>` for that purpose.
-----
Main window
-----------
When LAMMPS GUI starts, it will show the main window with either an
empty buffer, or have a file loaded. In the latter case it may look like
the following:
When LAMMPS GUI starts, it will show a main window with either an
empty buffer or the contents of a loaded file. In the latter case it
may look like the following:
.. image:: JPG/lammps-gui-main.png
:align: center
:scale: 50%
There is the menu bar at the top, then the main editor buffer with the
input file contents in the center with line numbers on the left and the
input colored according to the LAMMPS input file syntax. At the bottom
is the status bar, which shows the status of LAMMPS execution on the
left ("Ready." when idle) and the current working directory on the
right. The size of the main window will be stored when exiting and
restored when starting again. The name of the current file in the
buffer is shown in the window title and the text `*modified*` is added
in case the buffer has modifications that are not yet saved to a file.
There is the typical menu bar at the top, then the main editor buffer,
and a status bar at the bottom. The input file contents are shown
with line numbers on the left and the input is colored according to
the LAMMPS input file syntax. The status bar shows the status of
LAMMPS execution on the left (e.g. "Ready." when idle) and the current
working directory on the right. The name of the current file in the
buffer is shown in the window title; the word `*modified*` is added if
the buffer edits have not yet saved to a file. The size of the main
window will be stored when exiting and restored when starting again.
Opening Files
^^^^^^^^^^^^^
The LAMMPS GUI application will try to open the first command line
argument as input file, further arguments are ignored. When no
argument is given LAMMPS GUI will start with an empty buffer.
Files can also be opened via the ``File`` menu or by drag-and-drop
of a file from a file manager to the editor window. Only one
file can be open at a time, so opening a new file with a filled
buffer will close this buffer and in case the buffer has unsaved
modifications will ask to either cancel the load, discard the
changes or save them.
argument as a LAMMPS input script, further arguments are ignored.
When no argument is given, LAMMPS GUI will start with an empty buffer.
Files can also be opened via the ``File`` menu or by drag-and-drop of
a file from a graphical file manager into the editor window. Only one
file can be open at a time, so opening a new file with a filled buffer
will close the buffer. If the buffer has unsaved modifications, you
will be asked to either cancel the operation, discard the changes, or
save them.
Running LAMMPS
^^^^^^^^^^^^^^
From within the LAMMPS GUI main window LAMMPS can be started either from
the ``Run`` menu, by the hotkey `Ctrl-Enter` (`Command-Enter` on macOS),
or by clicking on the green button in the status bar. LAMMPS runs in a
separate thread, so the GUI stays responsive and thus it is able to
interact with the calculation and access its data. It is important to
note, that LAMMPS is using the contents of the input buffer for the run,
**not** the file it was read from. If there are unsaved changes in the
buffer, they *will* be used.
the ``Run`` menu using the ``Run LAMMPS from Editor Buffer`` entry, by
the keyboard shortcut `Ctrl-Enter` (`Command-Enter` on macOS), or by
clicking on the green "Run" button in the status bar. All of these
operations will cause LAMMPS to process the entire input script, which
may contain multiple :doc:`run <run>` or :doc:`minimize <minimize>`
commands.
LAMMPS runs in a separate thread, so the GUI stays responsive and is
able to interact with the running calculation and access data it
produces. It is important to note that running LAMMPS this way is
using the contents of the input buffer for the run (via the
:cpp:func:`lammps_commands_string()` function of the LAMMPS C-library
interface), and **not** the original file it was read from. Thus, if
there are unsaved changes in the buffer, they *will* be used. As an
alternative, it is also possible to run LAMMPS by reading the contents
of a file from the ``Run LAMMPS from File`` menu entry or with
`Ctrl-Shift-Enter`. This option may be required in some rare cases
where the input uses some functionality that is not compatible with
running LAMMPS from a string buffer. For consistency, any unsaved
changes in the buffer must be either saved to the file or undone
before LAMMPS can be run from a file.
.. image:: JPG/lammps-gui-running.png
:align: center
:scale: 75%
While LAMMPS is running, the contents of the status bar change: on the
left side there is a text indicating that LAMMPS is running, which will
contain the selected number of threads, if thread-parallel acceleration
was selected in the ``Preferences`` dialog. On the right side, a
progress bar is shown that displays the estimated progress on the
current :doc:`run command <run>`. Additionally, two windows will open:
the log window with the captured screen output and the chart window with
a line graph created from the thermodynamic output of the run.
While LAMMPS is running, the contents of the status bar change. On
the left side there is a text indicating that LAMMPS is running, which
will also show the number of active threads, if thread-parallel
acceleration was selected in the ``Preferences`` dialog. On the right
side, a progress bar is shown that displays the estimated progress for
the current :doc:`run command <run>`.
The run can be stopped cleanly by using either the ``Stop LAMMPS`` entry
in the ``Run`` menu, the hotkey `Ctrl-/` (`Command-/` on macOS), or
clicking on the red button in the status bar. This will cause that the
running LAMMPS process will complete the current iteration and then
stop. This is equivalent to the command :doc:`timer timeout 0 <timer>`
and implemented by calling the :cpp:func:`lammps_force_timeout()`
function of the LAMMPS C-library interface.
Also, the line number of the currently executed command will be
highlighted in green.
.. image:: JPG/lammps-gui-run-highlight.png
:align: center
:scale: 75%
If an error occurs (in the example below the command :doc:`label
<label>` was incorrectly capitalized as "Label"), an error message
dialog will be shown and the line of the input which triggered the
error will be highlighted. The state of LAMMPS in the status bar will
be set to "Failed." instead of "Ready."
.. image:: JPG/lammps-gui-run-error.png
:align: center
:scale: 75%
Up to three additional windows will open during a run:
- a log window with the captured screen output
- a chart window with a line graph created from the thermodynamic output of the run
- a slide show window with images created by a :doc:`dump image command <dump_image>`
More information on those windows and how to adjust their behavior and
contents is given below.
An active LAMMPS run can be stopped cleanly by using either the ``Stop
LAMMPS`` entry in the ``Run`` menu, the keyboard shortcut `Ctrl-/`
(`Command-/` on macOS), or by clicking on the red button in the status
bar. This will cause the running LAMMPS process to complete the current
timestep (or iteration for energy minimization) and then complete the
processing of the buffer while skipping all run or minimize commands.
This is equivalent to the input script command :doc:`timer timeout 0
<timer>` and is implemented by calling the
:cpp:func:`lammps_force_timeout()` function of the LAMMPS C-library
interface. Please see the corresponding documentation pages to
understand the implications of this operation.
Log Window
----------
By default, when starting a run, a "Log Window" will open that displays
the current screen output of the LAMMPS calculation, that would normally
be seen in the command line window, as shown below.
.. image:: JPG/lammps-gui-log.png
:align: center
:scale: 50%
LAMMPS GUI captures the screen output as it is generated and updates
the log window regularly during a run.
By default, the log window will be replaced each time a run is started.
The runs are counted and the run number for the current run is displayed
in the window title. It is possible to change the behavior of LAMMPS
GUI in the preferences dialog to create a *new* log window for every run
or to not show the current log window. It is also possible to show or
hide the *current* log window from the ``View`` menu.
The text in the log window is read-only and cannot be modified, but
keyboard shortcuts to select and copy all or parts of the text can be
used to transfer text to another program. Also, the keyboard shortcut
`Ctrl-S` (`Command-S` on macOS) is available to save the log buffer to a
file. The "Select All" and "Copy" functions, as well as a "Save Log to
File" option are also available from a context menu by clicking with the
right mouse button into the log window text area.
Chart Window
------------
By default, when starting a run, a "Chart Window" will open that
displays a plot of thermodynamic output of the LAMMPS calculation as
shown below.
.. image:: JPG/lammps-gui-chart.png
:align: center
:scale: 50%
The drop down menu on the top right allows selection of different
properties that are computed and written to thermo output. Only one
property can be shown at a time. The plots will be updated with new
data as the run progresses, so they can be used to visually monitor the
evolution of available properties. The window title will show the
current run number that this chart window corresponds to. Same as
explained for the log window above, by default, the chart window will
be replaced on each new run, but the behavior can be changed in the
preferences dialog.
From the ``File`` menu on the top left, it is possible to save an image
of the currently displayed plot or export the data in either plain text
columns (for use by plotting tools like `gnuplot
<http://www.gnuplot.info/>`_ or `grace
<https://plasma-gate.weizmann.ac.il/Grace/>`_), or as CSV data which can
be imported for further processing with Microsoft Excel or `pandas
<https://pandas.pydata.org/>`_
Thermo output data from successive run commands in the input script will
be combined into a single data set unless the format, number, or names
of output columns are changed with a :doc:`thermo_style <thermo_style>`
or a :doc:`thermo_modify <thermo_modify>` command, or the current time
step is reset with :doc:`reset_timestep <reset_timestep>`, or if a
:doc:`clear <clear>` command is issued.
Image Slide Show
----------------
By default, if the LAMMPS input contains a :doc:`dump image
<dump_image>` command, a "Slide Show" window will open which loads and
displays the images created by LAMMPS as they are written.
.. image:: JPG/lammps-gui-slideshow.png
:align: center
:scale: 50%
The various buttons at the bottom right of the window allow single
stepping through the sequence of images or playing an animation (as a
continuous loop or once from first to last). It is also possible to
zoom in or zoom out of the displayed images, and to export the slide
show animation to a movie file, if `ffmpeg <https://ffmpeg.org/>`_ is
installed.
Variable Info
-------------
During a run, it may be of interest to monitor the value of input script
variables, for example to monitor the progress of loops. This can be
done by enabling the "Variables Window" in the ``View`` menu or by using
the `Ctrl-Shift-W` keyboard shortcut. This will show info similar to
the :doc:`info variables <info>` command in a separate window as shown
below.
.. image:: JPG/lammps-gui-variable-info.png
:align: center
:scale: 75%
Like the log and chart windows, its content is continuously updated
during a run. It will show "(none)" if there are no variables
defined. Note that it is also possible to *set* :doc:`index style
variables <variable>`, that would normally be set via command line
flags, via the "Set Variables..." dialog from the ``Run`` menu.
LAMMPS GUI will automatically set the variable "gui_run" to the
current value of the run counter. That way it would be possible
to automatically record a log for each run attempt by using the
command
.. code-block:: LAMMPS
log logfile-${gui_run}.txt
at the beginning of an input file. That would record logs to files
``logfile-1.txt``, ``logfile-2.txt``, and so on for successive runs.
Viewing Snapshot Images
^^^^^^^^^^^^^^^^^^^^^^^
-----------------------
By selecting the ``View Image`` entry in the ``Run`` menu, by hitting
the `Ctrl-I` (`Command-I` on macOS) hotkey or by clicking on the
"palette" button in the status bar, LAMMPS GUI will issue a
:doc:`write_dump image <dump_image>` command and read the resulting
snapshot image into an image viewer window. When possible, LAMMPS
GUI will try to detect which elements the atoms correspond to (via
their mass) and then colorize them accordingly. Otherwise just some
predefined sequence of colors are assigned to different atom types.
By selecting the ``Create Image`` entry in the ``Run`` menu, or by
hitting the `Ctrl-I` (`Command-I` on macOS) keyboard shortcut, or by
clicking on the "palette" button in the status bar, LAMMPS GUI will send
a custom :doc:`write_dump image <dump_image>` command to LAMMPS and read
the resulting snapshot image with the current state of the system into
an image viewer window. This functionality is not available *during* an
ongoing run. When LAMMPS is not yet initialized, LAMMPS GUI will try to
identify the line with the first run or minimize command and execute all
command up to that line from the input buffer and then add a "run 0"
command. This will initialize the system so an image of the initial
state of the system can be rendered. If there was an error, the
snapshot image viewer will not appear.
When possible, LAMMPS GUI will try to detect which elements the atoms
correspond to (via their mass) and then colorize them in the image
accordingly. Otherwise the default predefined sequence of colors is
assigned to the different atom types.
.. image:: JPG/lammps-gui-image.png
:align: center
@ -114,28 +313,68 @@ predefined sequence of colors are assigned to different atom types.
The default image size, some default image quality settings, the view
style and some colors can be changed in the ``Preferences`` dialog
window. From the image viewer window further adjustments can be made:
actual image size, high-quality rendering, anti-aliasing, view style,
display of box or axes, zoom factor. The the image can be rotated
horizontally and vertically and it is possible to only display the atoms
within a predefined group (default is "all"). After each change, the
image is rendered again and the display updated. The small palette icon
on the top left will be colored while LAMMPS is running to render the
image and it will be grayed out again, when it is done. When there are
many items to show and high quality images with anti-aliasing are
requested, re-rendering can take several seconds. From the ``File``
menu, the shown image can be saved to a file permanently or copied into
the cut-n-paste buffer for pasting into another application.
actual image size, high-quality (SSAO) rendering, anti-aliasing, view
style, display of box or axes, zoom factor. The view of the system
can be rotated horizontally and vertically. It is also possible to
only display the atoms within a group defined in the input script
(default is "all"). After each change, the image is rendered again
and the display updated. The small palette icon on the top left will
be colored while LAMMPS is running to render the new image; it will be
grayed out when it is finished. When there are many atoms to render
and high quality images with anti-aliasing are requested, re-rendering
may take several seconds. From the ``File`` menu of the image window,
the current image can be saved to a file or copied into the
cut-n-paste buffer for pasting into another application.
Editor Functions
^^^^^^^^^^^^^^^^
----------------
The editor has most the usual functionality that similar programs have:
text selection via mouse or with cursor moves while holding the Shift
key, Cut, Copy, Paste, Undo, Redo. All of these editing functions are
available via hotkeys. When trying to exit the editor with a modified
buffer, a dialog will pop up asking whether to cancel the quit, or don't
save or save the buffer's contents to a file.
The editor has most of the usual functionality that similar programs
have: text selection via mouse or with cursor moves while holding the
Shift key, Cut (`Ctrl-X`), Copy (`Ctrl-C`), Paste (`Ctrl-V`), Undo
(`Ctrl-Z`), Redo (`Ctrl-Shift-Z`), Select All (`Ctrl-A`). When trying
to exit the editor with a modified buffer, a dialog will pop up asking
whether to cancel the exit operation, or to save or not save the buffer
contents to a file.
Context Specific Word Completion
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
By default, LAMMPS GUI will display a small pop-up frame with possible
choices for LAMMPS input script commands or styles after 2 characters of
a word have been typed.
.. image:: JPG/lammps-gui-complete.png
:align: center
:scale: 75%
The word can then be completed through selecting an entry by scrolling
up and down with the cursor keys and selecting with the 'Enter' key or
by clicking on the entry with the mouse. The automatic completion
pop-up can be disabled in the ``Preferences`` dialog, but the completion
can still be requested manually by either hitting the 'Shift-TAB' key or
by right-clicking with the mouse and selecting the option from the
context menu. Most of the completion information is taken from the
LAMMPS instance and thus it will be adjusted to only show available
options that have been enabled while compiling LAMMPS. That, however,
excludes accelerated styles and commands; for improved clarity, only the
non-suffix version of styles are shown.
Line Reformatting
^^^^^^^^^^^^^^^^^
The editor supports reformatting lines according to the syntax in order
to have consistently aligned lines. This primarily means adding
whitespace padding to commands, type specifiers, IDs and names. This
reformatting is performed by default when hitting the 'Enter' key to
start a new line. This feature can be turned on or off in the
``Preferences`` dialog, but it can still be manually performed by
hitting the 'TAB' key. The amount of padding can also be changed in the
``Preferences`` dialog.
Internally this functionality is achieved by splitting the line into
"words" and then putting it back together with padding added where the
context can be detected; otherwise a single space is used between words.
Context Specific Help
^^^^^^^^^^^^^^^^^^^^^
@ -145,22 +384,23 @@ Context Specific Help
:scale: 50%
A unique feature of the LAMMPS GUI is the option to look up the
documentation for the command in the current line. This can be achieved
by either clicking the right mouse button or by using the `Ctrl-?`
hotkey. When clicking the mouse there are additional entries in the
documentation for the command in the current line. This can be done by
either clicking the right mouse button or by using the `Ctrl-?` keyboard
shortcut. When clicking the mouse there are additional entries in the
context menu that will open the corresponding documentation page in the
online LAMMPS documentation. When using the hotkey, the first of those
entries will be chosen directly.
online LAMMPS documentation. When using the keyboard, the first of
those entries will be chosen directly.
Menu
----
The menu bar the entries ``File``, ``Edit``, ``Run``, ``View``, and ``About``.
Instead of using the mouse to click on them, the individual menus can also
be activated by hitting the `Alt` key together with the corresponding underlined
letter, that is `Alt-f` will activate the ``File`` menu. For the corresponding
activated sub-menus, also the underlined letter, together with the `Alt` key can
be used to select instead of the mouse.
The menu bar has entries ``File``, ``Edit``, ``Run``, ``View``, and
``About``. Instead of using the mouse to click on them, the individual
menus can also be activated by hitting the `Alt` key together with the
corresponding underlined letter, that is `Alt-F` will activate the
``File`` menu. For the corresponding activated sub-menus, the key
corresponding the underlined letters can again be used to select entries
instead of using the mouse.
File
^^^^
@ -174,104 +414,121 @@ The ``File`` menu offers the usual options:
- ``Save As`` will open a dialog to select and new file name and save
the buffer to it
- ``Quit`` will exit LAMMPS GUI. If there are unsaved changes, a dialog
will appear to either cancel the quit, save or don't save the file.
will appear to either cancel the operation, or to save or not save the
edited file.
In addition, up to 5 recent file names will be listed after the ``Open``
entry that allows to re-open recent files. This list is stored when
quitting and recovered when starting again.
In addition, up to 5 recent file names will be listed after the
``Open`` entry that allows re-opening recent files. This list is
stored when quitting and recovered when starting again.
Edit
^^^^
The ``Edit`` menu offers the usual editor functions like ``Undo``,
``Redo``, ``Cut``, ``Copy``, ``Paste``, but also offers to open the
``Preferences`` dialog and to delete all stored preferences so they
will be reset to their defaults.
``Redo``, ``Cut``, ``Copy``, ``Paste``. It can also open a
``Preferences`` dialog (keyboard shortcut `Ctrl-P`) and allows deletion
of all stored preferences so they will be reset to default values.
Run
^^^
The ``Run`` menu allows to start and stop a LAMMPS process. Rather than
calling the LAMMPS executable as a separate executable, the LAMMPS GUI
is linked to the LAMMPS library and thus can run LAMMPS internally
through the :ref:`LAMMPS C-library interface <lammps_c_api>`.
The ``Run`` menu has options to start and stop a LAMMPS process.
Rather than calling the LAMMPS executable as a separate executable,
the LAMMPS GUI is linked to the LAMMPS library and thus can run LAMMPS
internally through the :ref:`LAMMPS C-library interface
<lammps_c_api>`.
Specifically, a LAMMPS instance will be created by calling
:cpp:func:`lammps_open_no_mpi` and then the buffer contents run by
:cpp:func:`lammps_open_no_mpi`. The buffer contents then executed by
calling :cpp:func:`lammps_commands_string`. Certain commands and
features are only available, after a LAMMPS instance is created. Its
presence is indicated by a small LAMMPS ``L`` logo in the status bar at
the bottom left of the main window.
features are only available after a LAMMPS instance is created. Its
presence is indicated by a small LAMMPS ``L`` logo in the status bar
at the bottom left of the main window. As an alternative, it is also
possible to run LAMMPS using the contents of the edited file by
reading the file. This is mainly provided as a fallback option in
case the input uses some feature that is not available when running
from a string buffer.
The LAMMPS calculation will be run in a concurrent thread so that the
GUI will stay responsive and will be updated during the run. This can
be used to tell the running LAMMPS instance to stop at the next
timestep. The ``Stop LAMMPS`` entry will do this by calling
GUI can stay responsive and be updated during the run. This can be
used to tell the running LAMMPS instance to stop at the next timestep.
The ``Stop LAMMPS`` entry will do this by calling
:cpp:func:`lammps_force_timeout`, which is equivalent to a :doc:`timer
timeout 0 <timer>` command.
The ``Set Variables`` entry will open a dialog box where :doc:`index style variables <variable>`
can be set. Those variables will be passed to the LAMMPS instance when
it is created and are thus set *before* a run is started.
The ``Set Variables...`` entry will open a dialog box where
:doc:`index style variables <variable>` can be set. Those variables
will be passed to the LAMMPS instance when it is created and are thus
set *before* a run is started.
.. image:: JPG/lammps-gui-variables.png
:align: center
:scale: 75%
The ``Set Variables`` dialog will be pre-populated with entries that are
set as index variables in the input and any variables that are used but
not defined as far as the built-in parser can detect them. New rows for
additional variables can be added through the ``Add Row`` button and
existing rows deleted by clicking on the ``X`` icons on the right.
The ``Set Variables`` dialog will be pre-populated with entries that
are set as index variables in the input and any variables that are
used but not defined, if the built-in parser can detect them. New
rows for additional variables can be added through the ``Add Row``
button and existing rows can be deleted by clicking on the ``X`` icons
on the right.
The ``View Image`` entry will send a :doc:`dump image <dump_image>`
command to the LAMMPS instance, read the resulting file, and show it in
an ``Image Viewer`` window.
The ``Create Image`` entry will send a :doc:`dump image <dump_image>`
command to the LAMMPS instance, read the resulting file, and show it
in an ``Image Viewer`` window.
The ``View in OVITO`` entry will launch `OVITO <https://ovito.org>`_
with a :doc:`data file <write_data>` of the current state of the system.
This option is only available, if the LAMMPS GUI can find the OVITO
executable in the system path.
with a :doc:`data file <write_data>` containing the current state of
the system. This option is only available if the LAMMPS GUI can find
the OVITO executable in the system path.
The ``View in VMD`` entry will instead launch VMD, also to load a
:doc:`data file <write_data>` of the current state of the system. This
option is only available, if the LAMMPS GUI can find the VMD executable
in the system path.
The ``View in VMD`` entry will launch VMD with a :doc:`data file
<write_data>` containing the current state of the system. This option
is only available if the LAMMPS GUI can find the VMD executable in the
system path.
View
^^^^
The ``View`` menu offers to show or hide the three optional windows
with log output, graphs, or images. The default settings for those
can be changed in the ``Preferences dialog``.
The ``View`` menu offers to show or hide additional windows with log
output, charts, slide show, variables, or snapshot images. The
default settings for their visibility can be changed in the
``Preferences dialog``.
About
^^^^^
The ``About`` menu finally offers a couple of dialog windows and an
option to launch the LAMMPS online documentation in a web browser. The
``About LAMMPS GUI`` entry displays a dialog with a summary of the
option to launch the LAMMPS online documentation in a web browser.
The ``About LAMMPS`` entry displays a dialog with a summary of the
configuration settings of the LAMMPS library in use and the version
number of LAMMPS GUI itself. The ``Quick Help`` displays a dialog with
a minimal description of LAMMPS GUI. And ``LAMMPS Manual`` will open
the main page of this LAMMPS documentation at https://docs.lammps.org/.
number of LAMMPS GUI itself. The ``Quick Help`` displays a dialog
with a minimal description of LAMMPS GUI. The ``LAMMPS GUI Howto``
entry will open this documentation page from the online documentation
in a web browser window. The ``LAMMPS Manual`` entry will open the
main page of the LAMMPS documentation in the web browser.
-----
Preferences
-----------
The ``Preferences`` dialog allows to customize some of the behavior
and looks of the LAMMPS GUI application. The settings are grouped
and each group is displayed within a tab.
The ``Preferences`` dialog allows customization of the behavior and
look of the LAMMPS GUI application. The settings are grouped and each
group is displayed within a tab.
.. |guiprefs1| image:: JPG/lammps-gui-prefs-general.png
:width: 25%
:width: 24%
.. |guiprefs2| image:: JPG/lammps-gui-prefs-accel.png
:width: 25%
:width: 24%
.. |guiprefs3| image:: JPG/lammps-gui-prefs-image.png
:width: 25%
:width: 24%
|guiprefs1| |guiprefs2| |guiprefs3|
.. |guiprefs4| image:: JPG/lammps-gui-prefs-editor.png
:width: 24%
|guiprefs1| |guiprefs2| |guiprefs3| |guiprefs4|
General Settings:
^^^^^^^^^^^^^^^^^
@ -279,7 +536,7 @@ General Settings:
- *Echo input to log:* when checked, all input commands, including
variable expansions, will be echoed to the log window. This is
equivalent to using `-echo screen` at the command line. There is no
log *file* produced since it always uses `-log none`.
log *file* produced by default, since LAMMPS GUI uses `-log none`.
- *Include citation details:* when checked full citation info will be
included to the log window. This is equivalent to using `-cite
screen` on the command line.
@ -288,6 +545,9 @@ General Settings:
- *Show chart window by default:* when checked, the thermodynamic
output of a LAMMPS run will be collected and displayed in a chart
window as line graphs.
- *Show slide show window by default:* when checked, a slide show
window will be shown with images from a dump image command, if
present, in the LAMMPS input.
- *Replace log window on new run:* when checked, an existing log
window will be replaced on a new LAMMPS run, otherwise each run will
create a new log window.
@ -297,7 +557,7 @@ General Settings:
- *Replace image window on new render:* when checked, an existing
chart window will be replaced when a new snapshot image is requested,
otherwise each command will create a new image window.
- *Path to LAMMPS Shared Library File:* this options is only available
- *Path to LAMMPS Shared Library File:* this option is only visible
when LAMMPS GUI was compiled to load the LAMMPS library at run time
instead of being linked to it directly. With the ``Browse..`` button
or by changing the text, a different shared library file with a
@ -309,94 +569,132 @@ General Settings:
log) of the application can be set.
- *Select Text Font:* Opens a font selection dialog where the type and
size for the text editor and log font of the application can be set.
- *GUI update interval:* Allows to set the time interval between GUI
and data updates during a LAMMPS run in milliseconds. The default is
to update the GUI every 100 milliseconds. This is good for most cases.
For LAMMPS runs that run very fast, however, data may be missed and
through lowering this interval, this can be corrected. However, this
will make the GUI use more resources, which may be a problem on some
computers with slower CPUs. The default value is 100 milliseconds.
Accelerators:
^^^^^^^^^^^^^
This tab enables to select which accelerator package is used and is
equivalent to using the `-suffix` and `-package` flags on the command
line. Only settings supported by the LAMMPS library and local hardware
are available. The `Number of threads` field allows to set the maximum
number of threads for the accelerator packages that use threads.
This tab enables selection of an accelerator package for LAMMPS to use
and is equivalent to using the `-suffix` and `-package` flags on the
command line. Only settings supported by the LAMMPS library and local
hardware are available. The `Number of threads` field allows setting
the maximum number of threads for the accelerator packages that use
threads.
Snapshot Image:
^^^^^^^^^^^^^^^
This tab allows to set some defaults for the snapshot images displayed
in the ``Image Viewer`` window, like its dimensions and the zoom factor
applied. The *Antialias* switch requests to render images with twice
the number of pixels for width and height and then smoothly scales the
This tab allows setting defaults for the snapshot images displayed in
the ``Image Viewer`` window, such as its dimensions and the zoom
factor applied. The *Antialias* switch will render images with twice
the number of pixels for width and height and then smoothly scale the
image back to the requested size. This produces higher quality images
with smoother edges at the expense of requiring more CPU time to render
the image. The *HQ Image mode* option turns on using a screen space
ambient occlusion mode (SSAO) when rendering images. This is also more
time consuming, but produces a more 'spatial' representation of the
system. The *VDW Style* checkbox selects whether atoms are represented
by space filling spheres when checked or by smaller spheres and stick.
Finally there are a couple of drop down lists to select the background
and box color.
with smoother edges at the expense of requiring more CPU time to
render the image. The *HQ Image mode* option turns on screen space
ambient occlusion (SSAO) mode when rendering images. This is also
more time consuming, but produces a more 'spatial' representation of
the system shading of atoms by their depth. The *VDW Style* checkbox
selects whether atoms are represented by space filling spheres when
checked or by smaller spheres and sticks. Finally there are a couple
of drop down lists to select the background and box colors.
Editor Settings:
^^^^^^^^^^^^^^^^
Hotkeys
-------
This tab allows tweaking settings of the editor window. Specifically
the amount of padding to be added to LAMMPS commands, types or type
ranges, IDs (e.g. for fixes), and names (e.g. for groups). The value
set is the minimum width for the text element and it can be chosen in
the range between 1 and 32.
Almost all functionality is accessible from the menu or via hotkeys.
The following hotkeys are available (On macOS use the Command key
instead of Ctrl/Control).
The two settings which follow enable or disable the automatic
reformatting when hitting the 'Enter' key and the automatic display of
the completion pop-up window.
-----------
Keyboard Shortcuts
------------------
Almost all functionality is accessible from the menu of the editor
window or through keyboard shortcuts. The following shortcuts are
available (On macOS use the Command key instead of Ctrl/Control).
.. list-table::
:header-rows: 1
:widths: auto
* - Hotkey
* - Shortcut
- Function
- Hotkey
- Shortcut
- Function
- Hotkey
- Function
- Hotkey
- Shortcut
- Function
* - Ctrl+N
- New File
- Ctrl+Z
- Undo edit
- Ctrl+Enter
- Run LAMMPS
- Ctrl+Shift+A
- About LAMMPS GUI
- Run Input
* - Ctrl+O
- Open File
- Ctrl+Shift+Z
- Redo edit
- Ctrl+/
- Stop Active Run
- Ctrl+Shift+H
- Quick Help
* - CTRL+S
* - Ctrl+S
- Save File
- Ctrl+C
- Copy text
- Ctrl+Shift+V
- Set Variables
- Ctrl+Shift+G
- LAMMPS GUI Howto
* - Ctrl+Shift+S
- Save File As
- Ctrl+X
- Cut text
- Ctrl+I
- Create Snapshot Image
- Ctrl+Shift+M
- LAMMPS Manual
- Snapshot Image
* - Ctrl+Q
- Quit
- Quit Application
- Ctrl+V
- Paste text
- Ctrl+L
- Slide Show
* - Ctrl+W
- Close Window
- Ctrl+A
- Select All
- Ctrl+P
- Preferences
* - Ctrl+Shift+A
- About LAMMPS
- Ctrl+Shift+H
- Quick Help
- Ctrl+Shift+G
- LAMMPS GUI Howto
* - Ctrl+Shift+M
- LAMMPS Manual
- Ctrl+?
- Context Help
- Ctrl+Shift+W
- Show Variables
* - Ctrl+Shift+Enter
- Run File
- TAB
- Reformat line
- Shift+TAB
- Show Completions
Further editing keybindings `are documented with the Qt documentation
<https://doc.qt.io/qt-5/qplaintextedit.html#editing-key-bindings>`_. In
case of conflicts the list above takes precedence.
All other windows only support a subset of keyboard shortcuts listed
above. Typically, the shortcuts `Ctrl-/` (Stop Run), `Ctrl-W` (Close
Window), and `Ctrl-Q` (Quit Application) are supported.

371
doc/src/Howto_moltemplate.rst Normal file
View File

@ -0,0 +1,371 @@
Moltemplate Tutorial
====================
In this tutorial, we are going to use the tool :ref:`Moltemplate
<moltemplate>` to set up a classical molecular dynamic simulation using
the :ref:`OPLS-AA force field <OPLSAA96>`. The first
task is to describe an organic compound and create a complete input deck
for LAMMPS. The second task is to map the OPLS-AA force field to a
molecular sample created with an external tool, e.g. PACKMOL, and
exported as a PDB file. The files used in this tutorial can be found
in the ``tools/moltemplate/tutorial-files`` folder of the LAMMPS
source code distribution.
Simulating an organic solvent
"""""""""""""""""""""""""""""
This example aims to create a cubic box of the organic solvent
formamide.
The first step is to create a molecular topology in the
LAMMPS-template (LT) file format representing a single molecule, which
will be stored in a Moltemplate object called ``_FAM inherits OPLSAA {}``.
This command states that the object ``_FAM`` is based on an existing
object called ``OPLSAA``, which contains OPLS-AA parameters, atom type
definitions, partial charges, masses and bond-angle rules for many organic
and biological compounds.
The atomic structure is the starting point to populate the command
``write('Data Atoms') {}``, which will write the ``Atoms`` section in the
LAMMPS data file. The OPLS-AA force field uses the ``atom_style full``,
therefore, this column format is used:
``# atomID molID atomType charge coordX coordY coordZ``.
The ``atomID``\ s are replaced with Moltemplate ``$``-type variables, which
are then substituted with unique numerical IDs. The same logic is applied
to the ``molID``, except that the same variable is used for the whole
molecule. The atom types are assigned using ``@``-type variables. The
assignment of atom types (e.g. ``@atom:177``, ``@atom:178``) is done using
the OPLS-AA atom types defined in the "In Charges" section of the file
``oplsaa.lt``, looking for a reasonable match with the description of the atom.
The resulting file (``formamide.lt``) follows:
.. code-block:: bash
_FAM inherits OPLSAA {
# atomID molID atomType charge coordX coordY coordZ
write('Data Atoms') {
$atom:C00 $mol @atom:177 0.00 0.100 0.490 0.0
$atom:O01 $mol @atom:178 0.00 1.091 -0.250 0.0
$atom:N02 $mol @atom:179 0.00 -1.121 -0.181 0.0
$atom:H03 $mol @atom:182 0.00 -2.013 0.272 0.0
$atom:H04 $mol @atom:182 0.00 -1.056 -1.190 0.0
$atom:H05 $mol @atom:221 0.00 0.144 1.570 0.0
}
# A list of the bonds in the molecule:
# BondID AtomID1 AtomID2
write('Data Bond List') {
$bond:C1 $atom:C00 $atom:O01
$bond:C2 $atom:C00 $atom:H05
$bond:C3 $atom:C00 $atom:N02
$bond:C4 $atom:N02 $atom:H03
$bond:C5 $atom:N02 $atom:H04
}
}
You don't have to specify the charge in this example because they will
be assigned according to the atom type. Analogously, only a
"Data Bond List" section is needed as the atom type will determine the
bond type. The other bonded interactions (e.g. angles,
dihedrals, and impropers) will be automatically generated by
Moltemplate.
If the simulation is non-neutral, or Moltemplate complains that you have
missing bond, angle, or dihedral types, this means at least one of your
atom types is incorrect.
The second step is to create a master file with instructions to build a
starting structure and the LAMMPS commands to run an NPT simulation. The
master file (``solv_01.lt``) follows:
.. code-block:: bash
# Import the force field.
import /usr/local/moltemplate/moltemplate/force_fields/oplsaa.lt
import formamide.lt # after oplsaa.lt, as it depends on it.
# Create the input sample.
solv = new _FAM [5].move( 4.6, 0, 0)
[5].move( 0, 4.6, 0)
[5].move( 0, 0, 4.6)
solv[*][*][*].move(-11.5, -11.5, -11.5)
# Set the simulation box.
write_once("Data Boundary") {
-11.5 11.5 xlo xhi
-11.5 11.5 ylo yhi
-11.5 11.5 zlo zhi
}
# Create an input deck for LAMMPS.
write_once("In Init"){
# Input variables.
variable run string solv_01 # output name
variable ts equal 1 # timestep
variable temp equal 300 # equilibrium temperature
variable p equal 1. # equilibrium pressure
variable d equal 1000 # output frequency
variable equi equal 5000 # Equilibration steps
variable prod equal 30000 # Production steps
# PBC (set them before the creation of the box).
boundary p p p
}
# Run an NPT simulation.
write_once("In Run"){
# Derived variables.
variable tcouple equal \$\{ts\}*100
variable pcouple equal \$\{ts\}*1000
# Output.
thermo \$d
thermo_style custom step etotal evdwl ecoul elong ebond eangle &
edihed eimp ke pe temp press vol density cpu
thermo_modify flush yes
# Trajectory.
dump TRJ all dcd \$d \$\{run\}.dcd
dump_modify TRJ unwrap yes
# Thermalisation and relaxation, NPT ensemble.
timestep \$\{ts\}
fix NPT all npt temp \$\{temp\} \$\{temp\} \$\{tcouple\} iso \$p \$p \$\{pcouple\}
velocity all create \$\{temp\} 858096 dist gaussian
# Short runs to update the PPPM settings as the box shinks.
run \$\{equi\} post no
run \$\{equi\} post no
run \$\{equi\} post no
run \$\{equi\}
# From now on, the density shouldn't change too much.
run \$\{prod\}
unfix NPT
}
The first two commands insert the content of files ``oplsaa.lt`` and
``formamide.lt`` into the master file. At this point, we can use the
command ``solv = new _FAM [N]`` to create N copies of a molecule of type
``_FAM``. In this case, we create an array of 5*5*5 molecules on a cubic
grid using the coordinate transformation command ``.move( 4.6, 0, 0)``.
See the Moltemplate documentation to learn more about the syntax. As
the sample was created from scratch, we also specify the simulation box
size in the "Data Boundary" section.
The LAMMPS setting for the force field are specified in the file
``oplsaa.lt`` and are written automatically in the input deck. We also
specify the boundary conditions and a set of variables in
the "In Init" section. The remaining commands to run an NPT simulation
are written in the "In Run" section. Note that in this script, LAMMPS
variables are protected with the escape character ``\`` to distinguish
them from Moltemplate variables, e.g. ``\$\{run\}`` is a LAMMPS
variable that is written in the input deck as ``${run}``.
Compile the master file with:
.. code-block:: bash
moltemplate.sh -overlay-all solv_01.lt
And execute the simulation with the following:
.. code-block:: bash
mpirun -np 4 lmp -in solv_01.in -l solv_01.log
.. figure:: JPG/solv_01.png
:figwidth: 80%
:figclass: align-center
Snapshot of the sample at the beginning and end of the simulation.
Rendered with Ovito.
Mapping an existing structure
"""""""""""""""""""""""""""""
Another helpful way to use Moltemplate is mapping an existing molecular
sample to a force field. This is useful when a complex sample is
assembled from different simulations or created with specialized
software (e.g. PACKMOL). As in the previous example, all molecular
species in the sample must be defined using single-molecule Moltemplate
objects. For this example, we use a short polymer in a box containing
water molecules and ions in the PDB file ``model.pdb``.
It is essential to understand that the order of atoms in the PDB file
and in the Moltemplate master script must match, as we are using the
coordinates from the PDB file in the order they appear. The order of
atoms and molecules in the PDB file provided is as follows:
- 500 water molecules, with atoms ordered in this sequence:
.. parsed-literal::
ATOM 1 O MOL D 1 5.901 7.384 1.103 0.00 0.00 DUM
ATOM 2 H MOL D 1 6.047 8.238 0.581 0.00 0.00 DUM
ATOM 3 H MOL D 1 6.188 7.533 2.057 0.00 0.00 DUM
- 1 polymer molecule.
- 1 Ca\ :sup:`2+` ion.
- 2 Cl\ :sup:`-` ions.
In the master LT file, this sequence of molecules is matched with the
following commands:
.. code-block:: bash
# Create the sample.
wat=new SPC[500]
pol=new PolyNIPAM[1]
cat=new Ca[1]
ani=new Cl[2]
Note that the first command would create 500 water molecules in the
same position in space, and the other commands will use the coordinates
specified in the corresponding molecular topology block. However, the
coordinates will be overwritten by rendering an external atomic
structure file. Note that if the same molecule species are scattered in
the input structure, it is recommended to reorder and group together
for molecule types to facilitate the creation of the input sample.
The molecular topology for the polymer is created as in the previous
example, with the atom types assigned as in the following schema:
.. figure:: JPG/PolyNIPAM.jpg
:scale: 30%
:align: center
Atom types assigned to the polymer's repeating unit.
The molecular topology of the water and ions is stated directly into
the master file for the sake of space, but they could also be written
in a separate file(s) and imported before the sample is created.
The resulting master LT file defining short annealing at a fixed volume
(NVT) follows:
.. code-block:: bash
# Use the OPLS-AA force field for all species.
import /usr/local/moltemplate/moltemplate/force_fields/oplsaa.lt
import PolyNIPAM.lt
# Define the SPC water and ions as in the OPLS-AA
Ca inherits OPLSAA {
write("Data Atoms"){
$atom:a1 $mol:. @atom:354 0.0 0.00000 0.00000 0.000000
}
}
Cl inherits OPLSAA {
write("Data Atoms"){
$atom:a1 $mol:. @atom:344 0.0 0.00000 0.00000 0.000000
}
}
SPC inherits OPLSAA {
write("Data Atoms"){
$atom:O $mol:. @atom:76 0. 0.0000000 0.00000 0.000000
$atom:H1 $mol:. @atom:77 0. 0.8164904 0.00000 0.5773590
$atom:H2 $mol:. @atom:77 0. -0.8164904 0.00000 0.5773590
}
write("Data Bond List") {
$bond:OH1 $atom:O $atom:H1
$bond:OH2 $atom:O $atom:H2
}
}
# Create the sample.
wat=new SPC[500]
pol=new PolyNIPAM[1]
cat=new Ca[1]
ani=new Cl[2]
# Periodic boundary conditions:
write_once("Data Boundary"){
0 26 xlo xhi
0 26 ylo yhi
0 26 zlo zhi
}
# Define the input variables.
write_once("In Init"){
# Input variables.
variable run string sample01 # output name
variable ts equal 2 # timestep
variable temp equal 298.15 # equilibrium temperature
variable p equal 1. # equilibrium pressure
variable equi equal 30000 # equilibration steps
# PBC (set them before the creation of the box).
boundary p p p
neighbor 3 bin
}
# Run an NVT simulation.
write_once("In Run"){
# Set the output.
thermo 1000
thermo_style custom step etotal evdwl ecoul elong ebond eangle &
edihed eimp pe ke temp press atoms vol density cpu
thermo_modify flush yes
compute pe1 all pe/atom pair
dump TRJ all custom 100 \$\{run\}.dump id xu yu zu c_pe1
# Minimise the input structure, just in case.
minimize .01 .001 1000 100000
write_data \$\{run\}.min
# Set the constrains.
group watergroup type @atom:76 @atom:77
fix 0 watergroup shake 0.0001 10 0 b @bond:042_043 a @angle:043_042_043
# Short annealing.
timestep \$\{ts\}
fix 1 all nvt temp \$\{temp\} \$\{temp\} \$(100*dt)
velocity all create \$\{temp\} 315443
run \$\{equi\}
unfix 1
}
In this example, the water model is SPC and it is defined in the
``oplsaa.lt`` file with atom types ``@atom:76`` and ``@atom:77``. For
water we also use the ``group`` and ``fix shake`` commands with
Moltemplate ``@``-type variables, to ensure consistency with the
numerical values assigned during compilation. To identify the bond and
angle types, look for the extended ``@atom`` IDs, which in this case
are:
.. code-block:: bash
replace{ @atom:76 @atom:76_b042_a042_d042_i042 }
replace{ @atom:77 @atom:77_b043_a043_d043_i043 }
From which we can identify the following "Data Bonds By Type":
``@bond:042_043 @atom:*_b042*_a*_d*_i* @atom:*_b043*_a*_d*_i*`` and
"Data Angles By Type": ``@angle:043_042_043 @atom:*_b*_a043*_d*_i*
@atom:*_b*_a042*_d*_i* @atom:*_b*_a043*_d*_i*``
Compile the master file with:
.. code-block:: bash
moltemplate.sh -overlay-all -pdb model.pdb sample01.lt
And execute the simulation with the following:
.. code-block:: bash
mpirun -np 4 lmp -in sample01.in -l sample01.log
.. figure:: JPG/sample01.png
:figwidth: 50%
:figclass: align-center
Sample visualized with Ovito loading the trajectory into the DATA
file written after minimization.
------------
.. _OPLSAA96:
**(OPLS-AA)** Jorgensen, Maxwell, Tirado-Rives, J Am Chem Soc,
118(45), 11225-11236 (1996).

140
doc/src/Howto_output.rst
View File

@ -1,7 +1,7 @@
Output from LAMMPS (thermo, dumps, computes, fixes, variables)
==============================================================
There are four basic kinds of LAMMPS output:
There are four basic forms of LAMMPS output:
* :doc:`Thermodynamic output <thermo_style>`, which is a list of
quantities printed every few timesteps to the screen and logfile.
@ -20,18 +20,17 @@ output files, depending on what :doc:`dump <dump>` and :doc:`fix <fix>`
commands you specify.
As discussed below, LAMMPS gives you a variety of ways to determine
what quantities are computed and printed when the thermodynamics,
what quantities are calculated and printed when the thermodynamics,
dump, or fix commands listed above perform output. Throughout this
discussion, note that users can also :doc:`add their own computes and
fixes to LAMMPS <Modify>` which can then generate values that can then
be output with these commands.
fixes to LAMMPS <Modify>` which can generate values that can then be
output with these commands.
The following subsections discuss different LAMMPS commands related
to output and the kind of data they operate on and produce:
* :ref:`Global/per-atom/local/per-grid data <global>`
* :ref:`Scalar/vector/array data <scalar>`
* :ref:`Per-grid data <grid>`
* :ref:`Disambiguation <disambiguation>`
* :ref:`Thermodynamic output <thermo>`
* :ref:`Dump file output <dump>`
@ -48,34 +47,65 @@ to output and the kind of data they operate on and produce:
Global/per-atom/local/per-grid data
-----------------------------------
Various output-related commands work with four different styles of
Various output-related commands work with four different "styles" of
data: global, per-atom, local, and per-grid. A global datum is one or
more system-wide values, e.g. the temperature of the system. A
per-atom datum is one or more values per atom, e.g. the kinetic energy
of each atom. Local datums are calculated by each processor based on
the atoms it owns, but there may be zero or more per atom, e.g. a list
the atoms it owns, and there may be zero or more per atom, e.g. a list
of bond distances.
A per-grid datum is one or more values per grid cell, for a grid which
overlays the simulation domain. The grid cells and the data they
store are distributed across processors; each processor owns the grid
cells whose center point falls within its subdomain.
overlays the simulation domain. Similar to atoms and per-atom data,
the grid cells and the data they store are distributed across
processors; each processor owns the grid cells whose center points
fall within its subdomain.
.. _scalar:
Scalar/vector/array data
------------------------
Global, per-atom, and local datums can come in three kinds: a single
scalar value, a vector of values, or a 2d array of values. The doc
page for a "compute" or "fix" or "variable" that generates data will
specify both the style and kind of data it produces, e.g. a per-atom
vector.
Global, per-atom, local, and per-grid datums can come in three
"kinds": a single scalar value, a vector of values, or a 2d array of
values. More specifically these are the valid kinds for each style:
When a quantity is accessed, as in many of the output commands
discussed below, it can be referenced via the following bracket
notation, where ID in this case is the ID of a compute. The leading
"c\_" would be replaced by "f\_" for a fix, or "v\_" for a variable:
* global scalar
* global vector
* global array
* per-atom vector
* per-atom array
* local vector
* local array
* per-grid vector
* per-grid array
A per-atom vector means a single value per atom; the "vector" is the
length of the number of atoms. A per-atom array means multiple values
per atom. Similarly a local vector or array means one or multiple
values per entity (e.g. per bond in the system). And a per-grid
vector or array means one or multiple values per grid cell.
The doc page for a compute or fix or variable that generates data will
specify both the styles and kinds of data it produces, e.g. a per-atom
vector. Note that a compute or fix may generate multiple styles and
kinds of output. However, for per-atom data only a vector or array is
output, never both. Likewise for per-local and per-grid data. An
example of a fix which generates multiple styles and kinds of data is
the :doc:`fix mdi/qm <fix_mdi_qm>` command. It outputs a global
scalar, global vector, and per-atom array for the quantum mechanical
energy and virial of the system and forces on each atom.
By contrast, different variable styles generate only a single kind of
data: a global scalar for an equal-style variable, global vector for a
vector-style variable, and a per-atom vector for an atom-style
variable.
When data is accessed by another command, as in many of the output
commands discussed below, it can be referenced via the following
bracket notation, where ID in this case is the ID of a compute. The
leading "c\_" would be replaced by "f\_" for a fix, or "v\_" for a
variable (and ID would be the name of the variable):
+-------------+--------------------------------------------+
| c_ID | entire scalar, vector, or array |
@ -85,40 +115,56 @@ notation, where ID in this case is the ID of a compute. The leading
| c_ID[I][J] | one element of array |
+-------------+--------------------------------------------+
In other words, using one bracket reduces the dimension of the data
once (vector -> scalar, array -> vector). Using two brackets reduces
the dimension twice (array -> scalar). Thus a command that uses
scalar values as input can typically also process elements of a vector
or array.
Note that using one bracket reduces the dimension of the data once
(vector -> scalar, array -> vector). Using two brackets reduces the
dimension twice (array -> scalar). Thus a command that uses scalar
values as input can also conceptually operate on an element of a
vector or array.
.. _grid:
Per-grid data
------------------------
Per-grid data can come in two kinds: a vector of values (one per grid
cekk), or a 2d array of values (multiple values per grid ckk). The
doc page for a "compute" or "fix" that generates data will specify
names for both the grid(s) and datum(s) it produces, e.g. per-grid
vectors or arrays, which can be referenced by other commands. See the
:doc:`Howto grid <Howto_grid>` doc page for more details.
Per-grid vectors or arrays are accessed similarly, except that the ID
for the compute or fix includes a grid name and a data name. This is
because a fix or compute can create multiple grids (of different
sizes) and multiple sets of data (for each grid). The fix or compute
defines names for each grid and for each data set, so that all of them
can be accessed by other commands. See the :doc:`Howto grid
<Howto_grid>` doc page for more details.
.. _disambiguation:
Disambiguation
--------------
Some computes and fixes produce data in multiple styles, e.g. a global
scalar and a per-atom vector. Usually the context in which the input
script references the data determines which style is meant. Example:
if a compute provides both a global scalar and a per-atom vector, the
former will be accessed by using ``c_ID`` in an equal-style variable,
while the latter will be accessed by using ``c_ID`` in an atom-style
variable. Note that atom-style variable formulas can also access
global scalars, but in this case it is not possible to do this
directly because of the ambiguity. Instead, an equal-style variable
can be defined which accesses the global scalar, and that variable can
be used in the atom-style variable formula in place of ``c_ID``.
When a compute or fix produces data in multiple styles, e.g. global
and per-atom, a reference to the data can sometimes be ambiguous.
Usually the context in which the input script references the data
determines which style is meant.
For example, if a compute outputs a global vector and a per-atom
array, an element of the global vector will be accessed by using
``c_ID[I]`` in :doc:`thermodynamic output <thermo_style>`, while a
column of the per-atom array will be accessed by using ``c_ID[I]`` in
a :doc:`dump custom <dump>` command.
However, if a :doc:`atom-style variable <variable>` references
``c_ID[I]``, then it could be intended to refer to a single element of
the global vector or a column of the per-atom array. The doc page for
any command that has a potential ambiguity (variables are the most
common) will explain how to resolve the ambiguity.
In this case, an atom-style variables references per-atom data if it
exists. If access to an element of a global vector is needed (as in
this example), an equal-style variable which references the value can
be defined and used in the atom-style variable formula instead.
Similarly, :doc:`thermodynamic output <thermo_style>` can only
reference global data from a compute or fix. But you can indirectly
access per-atom data as follows. The reference ``c_ID[245][2]`` for
the ID of a :doc:`compute displace/atom <compute_displace_atom>`
command, refers to the y-component of displacement for the atom with
ID 245. While you cannot use that reference directly in the
:doc:`thermo_style <thermo_style>` command, you can use it an
equal-style variable formula, and then reference the variable in
thermodynamic output.
.. _thermo:
@ -389,7 +435,7 @@ output and input data types must match, e.g. global/per-atom/local
data and scalar/vector/array data.
Also note that, as described above, when a command takes a scalar as
input, that could be an element of a vector or array. Likewise a
input, that could also be an element of a vector or array. Likewise a
vector input could be a column of an array.
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+

2
doc/src/Howto_pylammps.rst
View File

@ -133,7 +133,7 @@ to the location in the virtual environment with:
.. code-block:: bash
cmake . -DPYTHON_EXECUTABLE=$(which python)
cmake . -DPython_EXECUTABLE=$(which python)
# install LAMMPS package in virtualenv
(testing) make install-python

39
doc/src/Howto_structured_data.rst
View File

@ -119,6 +119,45 @@ for example :doc:`dump yaml <dump>` or :doc:`fix ave/time <fix_ave_time>`
Depending on the kind of data being written, organization of the data
or the specific syntax used may change, but the principles are very
similar and all files should be readable with a suitable YAML parser.
A simple example for this is given below:
.. code-block:: python
import yaml
try:
from yaml import CSafeLoader as YamlLoader
except ImportError:
from yaml import SafeLoader as YamlLoader
timesteps = []
with open("dump.yaml", "r") as f:
data = yaml.load_all(f, Loader=YamlLoader)
for d in data:
print('Processing timestep %d' % d['timestep'])
timesteps.append(d)
print('Read %d timesteps from yaml dump' % len(timesteps))
print('Second timestep: ', timesteps[1]['timestep'])
print('Box info: x: ' , timesteps[1]['box'][0], ' y:', timesteps[1]['box'][1], ' z:',timesteps[1]['box'][2])
print('First 5 per-atom columns: ', timesteps[1]['keywords'][0:5])
print('Corresponding 10th atom data: ', timesteps[1]['data'][9][0:5])
The corresponding output for a YAML dump command added to the "melt" example is:
.. parsed-literal::
Processing timestep 0
Processing timestep 50
Processing timestep 100
Processing timestep 150
Processing timestep 200
Processing timestep 250
Read 6 timesteps from yaml dump
Second timestep: 50
Box info: x: [0, 16.795961913825074] y: [0, 16.795961913825074] z: [0, 16.795961913825074]
First 5 per-atom columns: ['id', 'type', 'x', 'y', 'z']
Corresponding 10th atom data: [10, 1, 4.43828, 0.968481, 0.108555]
Processing scalar data with Python
----------------------------------

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

3
doc/src/Howto_triclinic.rst
View File

@ -12,7 +12,8 @@ is created, e.g. by the :doc:`create_box <create_box>` or
:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
commands. Additionally, LAMMPS defines box size parameters lx,ly,lz
where lx = xhi-xlo, and similarly in the y and z dimensions. The 6
parameters, as well as lx,ly,lz, can be output via the :doc:`thermo_style custom <thermo_style>` command.
parameters, as well as lx,ly,lz, can be output via the
:doc:`thermo_style custom <thermo_style>` command.
LAMMPS also allows simulations to be performed in triclinic
(non-orthogonal) simulation boxes shaped as a parallelepiped with

14
doc/src/Intro_nonfeatures.rst
View File

@ -5,7 +5,7 @@ LAMMPS is designed to be a fast, parallel engine for molecular
dynamics (MD) simulations. It provides only a modest amount of
functionality for setting up simulations and analyzing their output.
Specifically, LAMMPS was not conceived and designed for:
Originally, LAMMPS was not conceived and designed for:
* being run through a GUI
* building molecular systems, or building molecular topologies
@ -14,9 +14,10 @@ Specifically, LAMMPS was not conceived and designed for:
* visualize your MD simulation interactively
* plot your output data
Over the years some of these limitations have been reduced or
removed, through features added to LAMMPS or external tools
that either closely interface with LAMMPS or extend LAMMPS.
Over the years many of these limitations have been reduced or
removed. In part through features added to LAMMPS and in part
through external tools that either closely interface with LAMMPS
or extend LAMMPS.
Here are suggestions on how to perform these tasks:
@ -24,8 +25,9 @@ Here are suggestions on how to perform these tasks:
wraps the library interface is provided. Thus, GUI interfaces can be
written in Python or C/C++ that run LAMMPS and visualize or plot its
output. Examples of this are provided in the python directory and
described on the :doc:`Python <Python_head>` doc page. Also, there
are several external wrappers or GUI front ends.
described on the :doc:`Python <Python_head>` doc page. As of version
2 August 2023 :ref:`a GUI tool <lammps_gui>` is included in LAMMPS.
Also, there are several external wrappers or GUI front ends.
* **Builder:** Several pre-processing tools are packaged with LAMMPS.
Some of them convert input files in formats produced by other MD codes
such as CHARMM, AMBER, or Insight into LAMMPS input formats. Some of

BIN
doc/src/JPG/PolyNIPAM.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
doc/src/JPG/lammps-gui-chart.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 73 KiB

After

Width:  |  Height:  |  Size: 105 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 36 KiB

BIN
doc/src/JPG/lammps-gui-log.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 185 KiB

After

Width:  |  Height:  |  Size: 95 KiB

BIN
doc/src/JPG/lammps-gui-main.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 91 KiB

After

Width:  |  Height:  |  Size: 90 KiB

BIN
doc/src/JPG/lammps-gui-popup-help.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 119 KiB

After

Width:  |  Height:  |  Size: 130 KiB

BIN
doc/src/JPG/lammps-gui-prefs-accel.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 32 KiB

After

Width:  |  Height:  |  Size: 37 KiB

BIN
doc/src/JPG/lammps-gui-prefs-editor.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 44 KiB

BIN
doc/src/JPG/lammps-gui-prefs-general.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 66 KiB

After

Width:  |  Height:  |  Size: 81 KiB

BIN
doc/src/JPG/lammps-gui-prefs-image.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 44 KiB

After

Width:  |  Height:  |  Size: 50 KiB

BIN
doc/src/JPG/lammps-gui-run-error.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 41 KiB

BIN
doc/src/JPG/lammps-gui-run-highlight.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 67 KiB

BIN
doc/src/JPG/lammps-gui-variable-info.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

BIN
doc/src/JPG/sample01.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 808 KiB

BIN
doc/src/JPG/solv_01.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 86 KiB

16
doc/src/Library.rst
View File

@ -80,13 +80,15 @@ run LAMMPS in serial mode.
:class: note
If the LAMMPS executable encounters an error condition, it will abort
after printing an error message. For a library interface this is
usually not desirable. Thus LAMMPS can be compiled to to :ref:`throw
a C++ exception <exceptions>` instead. If enabled, the library
functions will catch those exceptions and return. The error status
:cpp:func:`can be queried <lammps_has_error>` and an :cpp:func:`error
message retrieved <lammps_get_last_error_message>`. We thus
recommend enabling C++ exceptions when using the library interface,
after printing an error message. It does so by catching the
exceptions that LAMMPS could throw. For a C library interface this
is usually not desirable since the calling code might lack the
ability to catch such exceptions. Thus, the library functions will
catch those exceptions and return from the affected functions. The
error status :cpp:func:`can be queried <lammps_has_error>` and an
:cpp:func:`error message retrieved <lammps_get_last_error_message>`.
This is, for example used by the :doc:`LAMMPS python module
<Python_module>` and then a suitable Python exception is thrown.
.. admonition:: Using the C library interface as a plugin
:class: note

6
doc/src/Library_objects.rst
View File

@ -9,6 +9,7 @@ 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_variable_info`
-----------------------
@ -37,6 +38,11 @@ fixes, or variables in LAMMPS using the following functions:
-----------------------
.. doxygenfunction:: lammps_variable_info
:project: progguide
-----------------------
.. doxygenenum:: _LMP_DATATYPE_CONST
.. doxygenenum:: _LMP_STYLE_CONST

21
doc/src/Manual.rst
View File

@ -23,10 +23,23 @@ coordinated.
----------
The content for this manual is part of the LAMMPS distribution. The
online version always corresponds to the latest feature release version.
If needed, you can build a local copy of the manual as HTML pages or a
PDF file by following the steps on the :doc:`Build_manual` page. If you
The content for this manual is part of the LAMMPS distribution in its
doc directory.
* The version of the manual on the LAMMPS website corresponds to the
latest LAMMPS feature release. It is available at:
`https://docs.lammps.org/ <https://docs.lammps.org/>`_.
* A version of the manual corresponding to the latest LAMMPS stable
release (state of the *stable* branch on GitHub) is available online
at: `https://docs.lammps.org/stable/
<https://docs.lammps.org/stable/>`_
* A version of the manual with the features most recently added to
LAMMPS (state of the *develop* branch on GitHub) is available at:
`https://docs.lammps.org/latest/ <https://docs.lammps.org/latest/>`_
If needed, you can build a copy on your local machine of the manual
(HTML pages or PDF file) for the version of LAMMPS you have
downloaded. Follow the steps on the :doc:`Build_manual` page. If you
have difficulties viewing the pages, please :ref:`see this note
<webbrowser>`.

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.

14
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
@ -15,9 +15,7 @@ Python exception handling mechanism.
try:
# LAMMPS will normally terminate itself and the running process if an error
# occurs. This would kill the Python interpreter. To avoid this, make sure to
# compile with LAMMPS_EXCEPTIONS enabled. This ensures the library API calls
# will not terminate the parent process. Instead, the library wrapper will
# occurs. This would kill the Python interpreter. The library wrapper will
# detect that an error has occured and throw a Python exception
lmp.command('unknown')

3
doc/src/Python_install.rst
View File

@ -5,8 +5,7 @@ The LAMMPS Python module enables calling the :ref:`LAMMPS C library API
<lammps_c_api>` from Python by dynamically loading functions in the
LAMMPS shared library through the Python `ctypes <ctypes_>`_
module. Because of the dynamic loading, it is required that LAMMPS is
compiled in :ref:`"shared" mode <exe>`. It is also recommended to
compile LAMMPS with :ref:`C++ exceptions <exceptions>` enabled.
compiled in :ref:`"shared" mode <exe>`.
Two components are necessary for Python to be able to invoke LAMMPS code:

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

41
doc/src/Tools.rst
View File

@ -645,9 +645,14 @@ LAMMPS GUI
Overview
^^^^^^^^
LAMMPS GUI is a simple graphical text editor that is linked to the
:ref:`LAMMPS C-library interface <lammps_c_api>` and thus can run LAMMPS
directly using the contents of the editor's text buffer as input.
LAMMPS GUI is a graphical text editor customized for editing LAMMPS
input files that is linked to the :ref:`LAMMPS C-library <lammps_c_api>`
and thus can run LAMMPS directly using the contents of the editor's text
buffer as input. It can retrieve and display information from LAMMPS
while it is running, display visualizations created with the :doc:`dump
image command <dump_image>`, and is adapted specifically for editing
LAMMPS input files through text completion and reformatting, and linking
to the online LAMMPS documentation for known LAMMPS commands and styles.
This is similar to what people traditionally would do to run LAMMPS:
using a regular text editor to edit the input and run the necessary
@ -656,9 +661,9 @@ terminal window. This similarity is a design goal. While making it easy
for beginners to start with LAMMPS, it is also the intention to simplify
the transition to workflows like most experienced LAMMPS users do.
All features have been extensively exposed to hotkeys, so that there is
also appeal for experienced LAMMPS users, too, especially for
prototyping and testing simulations setups.
All features have been extensively exposed to keyboard shortcuts, so
that there is also appeal for experienced LAMMPS users for prototyping
and testing simulations setups.
Features
^^^^^^^^
@ -673,11 +678,13 @@ Here are a few highlights of LAMMPS GUI
- Text editor will remember up to 5 recent files
- Context specific LAMMPS command help via online documentation
- LAMMPS is running in a concurrent thread, so the GUI remains responsive
- Support for accelerator packages
- Progress bar indicates that LAMMPS is running
- Support for most accelerator packages
- Progress bar indicates how far a run command is completed
- LAMMPS can be started and stopped with a hotkey
- Screen output is captured in a Log Window
- Thermodynamic output is captured and displayed as line graph in a Chart Window
- Indicator for currently executed command
- Indicator for line that caused an error
- Visualization of current state in Image Viewer (via :doc:`dump image <dump_image>`)
- Many adjustable settings and preferences that are persistent
- Dialog to set variables from the LAMMPS command line
@ -695,19 +702,26 @@ Prerequisites and portability
LAMMPS GUI is programmed in C++ based on the C++11 standard and using
the `Qt GUI framework <https://www.qt.io/product/framework>`_.
Currently, Qt version 5.12 or later is required; Qt 5.15LTS is
recommended; Qt 6.x not (yet) supported. Building LAMMPS with CMake is
required. The LAMMPS GUI has been successfully compiled and tested on:
recommended; support for Qt version 6.x is under active development and
thus far only tested with Qt 6.5LTS on Linux. Building LAMMPS with
CMake is required.
The LAMMPS GUI has been successfully compiled and tested on:
- Ubuntu Linux 20.04LTS x86_64 using GCC 9, Qt version 5.12
- Fedora Linux 38 x86\_64 using GCC 13 and Clang 16, Qt version 5.15LTS
- Fedora Linux 38 x86\_64 using GCC 13, Qt version 6.5LTS
- Apple macOS 12 (Monterey) and macOS 13 (Ventura) with Xcode on arm64 and x86\_64, Qt version 5.15LTS
- Windows 10 and 11 x86_64 with Visual Studio 2022 and Visual C++ 14.36, Qt version 5.15LTS
- Windows 10 and 11 x86_64 with MinGW / GCC 10.0 cross-compiler on Fedora 38, Qt version 5.15LTS
.. _lammps_gui_install:
Pre-compiled executables
^^^^^^^^^^^^^^^^^^^^^^^^
Pre-compiled LAMMPS executables including the GUI are currently
Pre-compiled LAMMPS executable packages that include the GUI are currently
available from https://download.lammps.org/static or
https://github.com/lammps/lammps/releases. You can unpack the archives
(or mount the macOS disk image) and run the GUI directly in place. The
@ -732,7 +746,10 @@ stored in a location where CMake can find them without additional help.
Otherwise, the location of the Qt library installation must be indicated
by setting ``-D Qt5_DIR=/path/to/qt5/lib/cmake/Qt5``, which is a path to
a folder inside the Qt installation that contains the file
``Qt5Config.cmake``.
``Qt5Config.cmake``. Similarly, for Qt6 the location of the Qt library
installation can be indicated by setting ``-D Qt6_DIR=/path/to/qt6/lib/cmake/Qt6``,
if necessary. When both, Qt5 and Qt6 are available, Qt6 will be preferred
unless ``-D LAMMPS_GUI_USE_QT5=yes`` is set.
It should be possible to build the LAMMPS GUI as a standalone
compilation (e.g. when LAMMPS has been compiled with traditional make),

5
doc/src/atom_modify.rst
View File

@ -65,6 +65,11 @@ switch. This is described on the :doc:`Build_settings <Build_settings>`
doc page. If atom IDs are not used, they must be specified as 0 for
all atoms, e.g. in a data or restart file.
.. note::
If a :doc:`triclinic simulation box <Howto_triclinic>` is used,
atom IDs are required, due to how neighbor lists are built.
The *map* keyword determines how atoms with specific IDs are found
when required. An example are the bond (angle, etc) methods which
need to find the local index of an atom with a specific global ID

118
doc/src/compute.rst
View File

@ -27,58 +27,62 @@ Examples
Description
"""""""""""
Define a computation that will be performed on a group of atoms.
Quantities calculated by a compute are instantaneous values, meaning
they are calculated from information about atoms on the current
timestep or iteration, though a compute may internally store some
information about a previous state of the system. Defining a compute
does not perform a computation. Instead computes are invoked by other
LAMMPS commands as needed (e.g., to calculate a temperature needed for
a thermostat fix or to generate thermodynamic or dump file output).
See the :doc:`Howto output <Howto_output>` page for a summary of
various LAMMPS output options, many of which involve computes.
Define a diagnostic computation that will be performed on a group of
atoms. Quantities calculated by a compute are instantaneous values,
meaning they are calculated from information about atoms on the
current timestep or iteration, though internally a compute may store
some information about a previous state of the system. Defining a
compute does not perform the computation. Instead computes are
invoked by other LAMMPS commands as needed (e.g., to calculate a
temperature needed for a thermostat fix or to generate thermodynamic
or dump file output). See the :doc:`Howto output <Howto_output>` page
for a summary of various LAMMPS output options, many of which involve
computes.
The ID of a compute can only contain alphanumeric characters and
underscores.
----------
Computes calculate one or more of four styles of quantities: global,
per-atom, local, or per-atom. A global quantity is one or more
system-wide values, e.g. the temperature of the system. A per-atom
quantity is one or more values per atom, e.g. the kinetic energy of
each atom. Per-atom values are set to 0.0 for atoms not in the
specified compute group. Local quantities are calculated by each
processor based on the atoms it owns, but there may be zero or more
per atom, e.g. a list of bond distances. Per-grid quantities are
calculated on a regular 2d or 3d grid which overlays a 2d or 3d
simulation domain. The grid points and the data they store are
distributed across processors; each processor owns the grid points
which fall within its subdomain.
Computes calculate and store any of four *styles* of quantities:
global, per-atom, local, or per-grid.
Computes that produce per-atom quantities have the word "atom" at the
end of their style, e.g. *ke/atom*\ . Computes that produce local
quantities have the word "local" at the end of their style,
e.g. *bond/local*\ . Computes that produce per-grid quantities have
the word "grid" at the end of their style, e.g. *property/grid*\ .
Styles with neither "atom" or "local" or "grid" at the end of their
style name produce global quantities.
A global quantity is one or more system-wide values, e.g. the
temperature of the system. A per-atom quantity is one or more values
per atom, e.g. the kinetic energy of each atom. Per-atom values are
set to 0.0 for atoms not in the specified compute group. Local
quantities are calculated by each processor based on the atoms it
owns, but there may be zero or more per atom, e.g. a list of bond
distances. Per-grid quantities are calculated on a regular 2d or 3d
grid which overlays a 2d or 3d simulation domain. The grid points and
the data they store are distributed across processors; each processor
owns the grid points which fall within its subdomain.
Note that a single compute typically produces either global or
per-atom or local or per-grid values. It does not compute both global
and per-atom values. It can produce local values or per-grid values
in tandem with global or per-atom quantities. The compute doc page
will explain the details.
As a general rule of thumb, computes that produce per-atom quantities
have the word "atom" at the end of their style, e.g. *ke/atom*\ .
Computes that produce local quantities have the word "local" at the
end of their style, e.g. *bond/local*\ . Computes that produce
per-grid quantities have the word "grid" at the end of their style,
e.g. *property/grid*\ . And styles with neither "atom" or "local" or
"grid" at the end of their style name produce global quantities.
Global, per-atom, local, and per-grid quantities come in three kinds:
a single scalar value, a vector of values, or a 2d array of values.
The doc page for each compute describes the style and kind of values
it produces, e.g. a per-atom vector. Some computes produce more than
one kind of a single style, e.g. a global scalar and a global vector.
Global, per-atom, local, and per-grid quantities can also be of three
*kinds*: a single scalar value (global only), a vector of values, or a
2d array of values. For per-atom, local, and per-grid quantities, a
"vector" means a single value for each atom, each local entity
(e.g. bond), or grid cell. Likewise an "array", means multiple values
for each atom, each local entity, or each grid cell.
When a compute quantity is accessed, as in many of the output commands
discussed below, it can be referenced via the following bracket
notation, where ID is the ID of the compute:
Note that a single compute can produce any combination of global,
per-atom, local, or per-grid values. Likewise it can produce any
combination of scalar, vector, or array output for each style. The
exception is that for per-atom, local, and per-grid output, either a
vector or array can be produced, but not both. The doc page for each
compute explains the values it produces.
When a compute output is accessed by another input script command it
is referenced via the following bracket notation, where ID is the ID
of the compute:
+-------------+--------------------------------------------+
| c_ID | entire scalar, vector, or array |
@ -89,17 +93,23 @@ notation, where ID is the ID of the compute:
+-------------+--------------------------------------------+
In other words, using one bracket reduces the dimension of the
quantity once (vector :math:`\to` scalar, array :math:`\to` vector). Using two
brackets reduces the dimension twice (array :math:`\to` scalar). Thus a
command that uses scalar compute values as input can also process elements of a
vector or array.
quantity once (vector :math:`\to` scalar, array :math:`\to` vector).
Using two brackets reduces the dimension twice (array :math:`\to`
scalar). Thus, for example, a command that uses global scalar compute
values as input can also process elements of a vector or array.
Depending on the command, this can either be done directly using the
syntax in the table, or by first defining a :doc:`variable <variable>`
of the appropriate style to store the quantity, then using the
variable as an input to the command.
Note that commands and :doc:`variables <variable>` which use compute
quantities typically do not allow for all kinds (e.g., a command may
require a vector of values, not a scalar). This means there is no
ambiguity about referring to a compute quantity as c_ID even if it
produces, for example, both a scalar and vector. The doc pages for
various commands explain the details.
Note that commands and :doc:`variables <variable>` which take compute
outputs as input typically do not allow for all styles and kinds of
data (e.g., a command may require global but not per-atom values, or
it may require a vector of values, not a scalar). This means there is
typically no ambiguity about referring to a compute output as c_ID
even if it produces, for example, both a scalar and vector. The doc
pages for various commands explain the details, including how any
ambiguities are resolved.
----------
@ -254,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
@ -269,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

2
doc/src/compute_composition_atom.rst
View File

@ -36,7 +36,7 @@ Examples
Description
"""""""""""
.. versionadded:: TBD
.. versionadded:: 21Nov2023
Define a computation that calculates a local composition vector for each
atom. For a central atom with :math:`M` neighbors within the neighbor cutoff sphere,

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

6
doc/src/compute_property_atom.rst
View File

@ -128,9 +128,9 @@ Attributes *i_name*, *d_name*, *i2_name*, *d2_name* refer to custom
per-atom integer and floating-point vectors or arrays that have been
added via the :doc:`fix property/atom <fix_property_atom>` command.
When that command is used specific names are given to each attribute
which are the "name" portion of these attributes. For arrays *i2_name*
and *d2_name*, the column of the array must also be included following
the name in brackets (e.g., d2_xyz[2] or i2_mySpin[3]).
which are the "name" portion of these attributes. For arrays
*i2_name* and *d2_name*, the column of the array must also be included
following the name in brackets (e.g., d2_xyz[2] or i2_mySpin[3]).
The additional quantities only accessible via this command, and not
directly via the :doc:`dump custom <dump>` command, are as follows.

2
doc/src/compute_property_grid.rst
View File

@ -61,7 +61,7 @@ varying fastest, then Y, then Z slowest. For 2d grids (in 2d
simulations), the grid IDs range from 1 to Nx*Ny, with X varying
fastest and Y slowest.
.. versionadded:: TBD
.. versionadded:: 21Nov2023
The *proc* attribute is the ID of the processor which owns the grid
cell. Processor IDs range from 0 to Nprocs - 1, where Nprocs is the

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

158
doc/src/compute_reduce.rst
View File

@ -37,13 +37,16 @@ Syntax
v_name = per-atom vector calculated by an atom-style variable with name
* zero or more keyword/args pairs may be appended
* keyword = *replace*
* keyword = *replace* or *inputs*
.. parsed-literal::
*replace* args = vec1 vec2
vec1 = reduced value from this input vector will be replaced
vec2 = replace it with vec1[N] where N is index of max/min value from vec2
*inputs* arg = peratom or local
peratom = all inputs are per-atom quantities (default)
local = all input are local quantities
Examples
""""""""
@ -60,38 +63,44 @@ Description
"""""""""""
Define a calculation that "reduces" one or more vector inputs into
scalar values, one per listed input. The inputs can be per-atom or
local quantities; they cannot be global quantities. Atom attributes
are per-atom quantities, :doc:`computes <compute>` and :doc:`fixes <fix>`
may generate any of the three kinds of quantities, and :doc:`atom-style variables <variable>` generate per-atom quantities. See the
:doc:`variable <variable>` command and its special functions which can
perform the same operations as the compute reduce command on global
vectors.
scalar values, one per listed input. For the compute reduce command,
the inputs can be either per-atom or local quantities and must all be
of the same kind (per-atom or local); see discussion of the optional
*inputs* keyword below. The compute reduce/region command can only be
used with per-atom inputs.
Atom attributes are per-atom quantities, :doc:`computes <compute>` and
:doc:`fixes <fix>` can generate either per-atom or local quantities,
and :doc:`atom-style variables <variable>` generate per-atom
quantities. See the :doc:`variable <variable>` command and its
special functions which can perform the same reduction operations as
the compute reduce command on global vectors.
The reduction operation is specified by the *mode* setting. The *sum*
option adds the values in the vector into a global total. The *min*
or *max* options find the minimum or maximum value across all vector
values. The *minabs* or *maxabs* options find the minimum or maximum
value across all absolute vector values. The *ave* setting adds the
vector values into a global total, then divides by the number of values
in the vector. The *sumsq* option sums the square of the values in the
vector into a global total. The *avesq* setting does the same as *sumsq*,
then divides the sum of squares by the number of values. The last two options
can be useful for calculating the variance of some quantity (e.g., variance =
sumsq :math:`-` ave\ :math:`^2`). The *sumabs* option sums the absolute
values in the vector into a global total. The *aveabs* setting does the same
as *sumabs*, then divides the sum of absolute values by the number of
vector values into a global total, then divides by the number of
values in the vector. The *sumsq* option sums the square of the
values in the vector into a global total. The *avesq* setting does
the same as *sumsq*, then divides the sum of squares by the number of
values. The last two options can be useful for calculating the
variance of some quantity (e.g., variance = sumsq :math:`-` ave\
:math:`^2`). The *sumabs* option sums the absolute values in the
vector into a global total. The *aveabs* setting does the same as
*sumabs*, then divides the sum of absolute values by the number of
values.
Each listed input is operated on independently. For per-atom inputs,
the group specified with this command means only atoms within the
group contribute to the result. For per-atom inputs, if the compute
reduce/region command is used, the atoms must also currently be within
the region. Note that an input that produces per-atom quantities may
define its own group which affects the quantities it returns. For
example, if a compute is used as an input which generates a per-atom
vector, it will generate values of 0.0 for atoms that are not in the
group specified for that compute.
group contribute to the result. Likewise for per-atom inputs, if the
compute reduce/region command is used, the atoms must also currently
be within the region. Note that an input that produces per-atom
quantities may define its own group which affects the quantities it
returns. For example, if a compute is used as an input which
generates a per-atom vector, it will generate values of 0.0 for atoms
that are not in the group specified for that compute.
Each listed input can be an atom attribute (position, velocity, force
component) or can be the result of a :doc:`compute <compute>` or
@ -123,52 +132,54 @@ array with six columns:
----------
The atom attribute values (*x*, *y*, *z*, *vx*, *vy*, *vz*, *fx*, *fy*, and
*fz*) are self-explanatory. Note that other atom attributes can be used as
inputs to this fix by using the
:doc:`compute property/atom <compute_property_atom>` command and then specifying
an input value from that compute.
The atom attribute values (*x*, *y*, *z*, *vx*, *vy*, *vz*, *fx*,
*fy*, and *fz*) are self-explanatory. Note that other atom attributes
can be used as inputs to this fix by using the :doc:`compute
property/atom <compute_property_atom>` command and then specifying an
input value from that compute.
If a value begins with "c\_", a compute ID must follow which has been
previously defined in the input script. Computes can generate
per-atom or local quantities. See the individual
:doc:`compute <compute>` page for details. If no bracketed integer
is appended, the vector calculated by the compute is used. If a
bracketed integer is appended, the Ith column of the array calculated
by the compute is used. Users can also write code for their own
compute styles and :doc:`add them to LAMMPS <Modify>`. See the
discussion above for how :math:`I` can be specified with a wildcard asterisk
to effectively specify multiple values.
previously defined in the input script. Valid computes can generate
per-atom or local quantities. See the individual :doc:`compute
<compute>` page for details. If no bracketed integer is appended, the
vector calculated by the compute is used. If a bracketed integer is
appended, the Ith column of the array calculated by the compute is
used. Users can also write code for their own compute styles and
:doc:`add them to LAMMPS <Modify>`. See the discussion above for how
:math:`I` can be specified with a wildcard asterisk to effectively
specify multiple values.
If a value begins with "f\_", a fix ID must follow which has been
previously defined in the input script. Fixes can generate per-atom
or local quantities. See the individual :doc:`fix <fix>` page for
details. Note that some fixes only produce their values on certain
timesteps, which must be compatible with when compute reduce
previously defined in the input script. Valid fixes can generate
per-atom or local quantities. See the individual :doc:`fix <fix>`
page for details. Note that some fixes only produce their values on
certain timesteps, which must be compatible with when compute reduce
references the values, else an error results. If no bracketed integer
is appended, the vector calculated by the fix is used. If a bracketed
integer is appended, the Ith column of the array calculated by the fix
is used. Users can also write code for their own fix style and
:doc:`add them to LAMMPS <Modify>`. See the discussion above for how
:math:`I` can be specified with a wildcard asterisk to effectively specify
multiple values.
:math:`I` can be specified with a wildcard asterisk to effectively
specify multiple values.
If a value begins with "v\_", a variable name must follow which has
been previously defined in the input script. It must be an
:doc:`atom-style variable <variable>`. Atom-style variables can
reference thermodynamic keywords and various per-atom attributes, or
invoke other computes, fixes, or variables when they are evaluated, so
this is a very general means of generating per-atom quantities to reduce.
this is a very general means of generating per-atom quantities to
reduce.
----------
If the *replace* keyword is used, two indices *vec1* and *vec2* are
specified, where each index ranges from 1 to the number of input values.
The replace keyword can only be used if the *mode* is *min* or *max*\ .
It works as follows. A min/max is computed as usual on the *vec2*
input vector. The index :math:`N` of that value within *vec2* is also stored.
Then, instead of performing a min/max on the *vec1* input vector, the
stored index is used to select the :math:`N`\ th element of the *vec1* vector.
specified, where each index ranges from 1 to the number of input
values. The replace keyword can only be used if the *mode* is *min*
or *max*\ . It works as follows. A min/max is computed as usual on
the *vec2* input vector. The index :math:`N` of that value within
*vec2* is also stored. Then, instead of performing a min/max on the
*vec1* input vector, the stored index is used to select the :math:`N`\
th element of the *vec1* vector.
Thus, for example, if you wish to use this compute to find the bond
with maximum stretch, you can do it as follows:
@ -190,6 +201,16 @@ information in this context, the *replace* keywords will extract the
atom IDs for the two atoms in the bond of maximum stretch. These atom
IDs and the bond stretch will be printed with thermodynamic output.
.. versionadded:: 21Nov2023
The *inputs* keyword allows selection of whether all the inputs are
per-atom or local quantities. As noted above, all the inputs must be
the same kind (per-atom or local). Per-atom is the default setting.
If a compute or fix is specified as an input, it must produce per-atom
or local data to match this setting. If it produces both, e.g. for
the :doc:`compute voronoi/atom <compute_voronoi_atom>` command, then
this keyword selects between them.
----------
If a single input is specified this compute produces a global scalar
@ -197,38 +218,41 @@ value. If multiple inputs are specified, this compute produces a
global vector of values, the length of which is equal to the number of
inputs specified.
As discussed below, for the *sum*, *sumabs*, and *sumsq* modes, the value(s)
produced by this compute are all "extensive", meaning their value
scales linearly with the number of atoms involved. If normalized
values are desired, this compute can be accessed by the
As discussed below, for the *sum*, *sumabs*, and *sumsq* modes, the
value(s) produced by this compute are all "extensive", meaning their
value scales linearly with the number of atoms involved. If
normalized values are desired, this compute can be accessed by the
:doc:`thermo_style custom <thermo_style>` command with
:doc:`thermo_modify norm yes <thermo_modify>` set as an option.
Or it can be accessed by a
:doc:`variable <variable>` that divides by the appropriate atom count.
:doc:`thermo_modify norm yes <thermo_modify>` set as an option. Or it
can be accessed by a :doc:`variable <variable>` that divides by the
appropriate atom count.
----------
Output info
"""""""""""
This compute calculates a global scalar if a single input value is specified
or a global vector of length :math:`N`, where :math:`N` is the number of
inputs, and which can be accessed by indices 1 to :math:`N`. These values can
be used by any command that uses global scalar or vector values from a
compute as input. See the :doc:`Howto output <Howto_output>` doc page
for an overview of LAMMPS output options.
This compute calculates a global scalar if a single input value is
specified or a global vector of length :math:`N`, where :math:`N` is
the number of inputs, and which can be accessed by indices 1 to
:math:`N`. These values can be used by any command that uses global
scalar or vector values from a compute as input. See the :doc:`Howto
output <Howto_output>` doc page for an overview of LAMMPS output
options.
All the scalar or vector values calculated by this compute are
"intensive", except when the *sum*, *sumabs*, or *sumsq* modes are used on
per-atom or local vectors, in which case the calculated values are
"extensive".
The scalar or vector values will be in whatever :doc:`units <units>` the
quantities being reduced are in.
The scalar or vector values will be in whatever :doc:`units <units>`
the quantities being reduced are in.
Restrictions
""""""""""""
none
As noted above, the compute reduce/region command can only be used
with per-atom inputs.
Related commands
""""""""""""""""
@ -238,4 +262,4 @@ Related commands
Default
"""""""
none
The default value for the *inputs* keyword is peratom.

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>`_

12
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.
@ -223,7 +223,7 @@ result. I.e. the last 2 columns of thermo output will be the same:
system pressure.
The compute stress/atom can be used in a number of ways. Here is an
example to compute a 1-d pressure profile in z-direction across the
example to compute a 1-d pressure profile in x-direction across the
complete simulation box. You will need to adjust the number of bins and the
selections for time averaging to your specific simulation. This assumes
that the dimensions of the simulation cell does not change.

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

130
doc/src/compute_voronoi_atom.rst
View File

@ -13,7 +13,7 @@ Syntax
* ID, group-ID are documented in :doc:`compute <compute>` command
* voronoi/atom = style name of this compute command
* zero or more keyword/value pairs may be appended
* keyword = *only_group* or *occupation* or *surface* or *radius* or *edge_histo* or *edge_threshold* or *face_threshold* or *neighbors* or *peratom*
* keyword = *only_group* or *occupation* or *surface* or *radius* or *edge_histo* or *edge_threshold* or *face_threshold* or *neighbors*
.. parsed-literal::
@ -31,7 +31,6 @@ Syntax
*face_threshold* arg = minarea
minarea = minimum area for a face to be counted
*neighbors* value = *yes* or *no* = store list of all neighbors or no
*peratom* value = *yes* or *no* = per-atom quantities accessible or no
Examples
""""""""
@ -53,14 +52,12 @@ atoms in the simulation box. The tessellation is calculated using all
atoms in the simulation, but non-zero values are only stored for atoms
in the group.
By default two per-atom quantities are calculated by this compute.
The first is the volume of the Voronoi cell around each atom. Any
point in an atom's Voronoi cell is closer to that atom than any other.
The second is the number of faces of the Voronoi cell. This is
equal to the number of nearest neighbors of the central atom,
plus any exterior faces (see note below). If the *peratom* keyword
is set to "no", the per-atom quantities are still calculated,
but they are not accessible.
Two per-atom quantities are calculated by this compute. The first is
the volume of the Voronoi cell around each atom. Any point in an
atom's Voronoi cell is closer to that atom than any other. The second
is the number of faces of the Voronoi cell. This is equal to the
number of nearest neighbors of the central atom, plus any exterior
faces (see note below).
----------
@ -97,13 +94,13 @@ present in atom_style sphere for granular models.
The *edge_histo* keyword activates the compilation of a histogram of
number of edges on the faces of the Voronoi cells in the compute
group. The argument *maxedge* of the this keyword is the largest number
of edges on a single Voronoi cell face expected to occur in the
sample. This keyword adds the generation of a global vector with
*maxedge*\ +1 entries. The last entry in the vector contains the number of
faces with more than *maxedge* edges. Since the polygon with the
smallest amount of edges is a triangle, entries 1 and 2 of the vector
will always be zero.
group. The argument *maxedge* of the this keyword is the largest
number of edges on a single Voronoi cell face expected to occur in the
sample. This keyword generates output of a global vector by this
compute with *maxedge*\ +1 entries. The last entry in the vector
contains the number of faces with more than *maxedge* edges. Since the
polygon with the smallest amount of edges is a triangle, entries 1 and
2 of the vector will always be zero.
The *edge_threshold* and *face_threshold* keywords allow the
suppression of edges below a given minimum length and faces below a
@ -127,8 +124,8 @@ to locate vacancies (the coordinates are given by the atom coordinates
at the time step when the compute was first invoked), while column two
data can be used to identify interstitial atoms.
If the *neighbors* value is set to yes, then this compute creates a
local array with 3 columns. There is one row for each face of each
If the *neighbors* value is set to yes, then this compute also creates
a local array with 3 columns. There is one row for each face of each
Voronoi cell. The 3 columns are the atom ID of the atom that owns the
cell, the atom ID of the atom in the neighboring cell (or zero if the
face is external), and the area of the face. The array can be
@ -143,8 +140,8 @@ containing all the Voronoi neighbors in a system:
compute 6 all voronoi/atom neighbors yes
dump d2 all local 1 dump.neighbors index c_6[1] c_6[2] c_6[3]
If the *face_threshold* keyword is used, then only faces
with areas greater than the threshold are stored.
If the *face_threshold* keyword is used, then only faces with areas
greater than the threshold are stored.
----------
@ -158,48 +155,52 @@ Voro++ software in the src/VORONOI/README file.
.. note::
The calculation of Voronoi volumes is performed by each processor for
the atoms it owns, and includes the effect of ghost atoms stored by
the processor. This assumes that the Voronoi cells of owned atoms
are not affected by atoms beyond the ghost atom cut-off distance.
This is usually a good assumption for liquid and solid systems, but
may lead to underestimation of Voronoi volumes in low density
systems. By default, the set of ghost atoms stored by each processor
is determined by the cutoff used for :doc:`pair_style <pair_style>`
interactions. The cutoff can be set explicitly via the
:doc:`comm_modify cutoff <comm_modify>` command. The Voronoi cells
for atoms adjacent to empty regions will extend into those regions up
to the communication cutoff in :math:`x`, :math:`y`, or :math:`z`.
In that situation, an exterior face is created at the cutoff distance
normal to the :math:`x`, :math:`y`, or :math:`z` direction. For
triclinic systems, the exterior face is parallel to the corresponding
reciprocal lattice vector.
The calculation of Voronoi volumes is performed by each processor
for the atoms it owns, and includes the effect of ghost atoms
stored by the processor. This assumes that the Voronoi cells of
owned atoms are not affected by atoms beyond the ghost atom cut-off
distance. This is usually a good assumption for liquid and solid
systems, but may lead to underestimation of Voronoi volumes in low
density systems. By default, the set of ghost atoms stored by each
processor is determined by the cutoff used for :doc:`pair_style
<pair_style>` interactions. The cutoff can be set explicitly via
the :doc:`comm_modify cutoff <comm_modify>` command. The Voronoi
cells for atoms adjacent to empty regions will extend into those
regions up to the communication cutoff in :math:`x`, :math:`y`, or
:math:`z`. In that situation, an exterior face is created at the
cutoff distance normal to the :math:`x`, :math:`y`, or :math:`z`
direction. For triclinic systems, the exterior face is parallel to
the corresponding reciprocal lattice vector.
.. note::
The Voro++ package performs its calculation in 3d. This will
still work for a 2d LAMMPS simulation, provided all the atoms have the
same :math:`z`-coordinate. The Voronoi cell of each atom will be a columnar
polyhedron with constant cross-sectional area along the :math:`z`-direction
and two exterior faces at the top and bottom of the simulation box. If
the atoms do not all have the same :math:`z`-coordinate, then the columnar
cells will be accordingly distorted. The cross-sectional area of each
Voronoi cell can be obtained by dividing its volume by the :math:`z` extent
of the simulation box. Note that you define the :math:`z` extent of the
simulation box for 2d simulations when using the
:doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands.
The Voro++ package performs its calculation in 3d. This will still
work for a 2d LAMMPS simulation, provided all the atoms have the
same :math:`z`-coordinate. The Voronoi cell of each atom will be a
columnar polyhedron with constant cross-sectional area along the
:math:`z`-direction and two exterior faces at the top and bottom of
the simulation box. If the atoms do not all have the same
:math:`z`-coordinate, then the columnar cells will be accordingly
distorted. The cross-sectional area of each Voronoi cell can be
obtained by dividing its volume by the :math:`z` extent of the
simulation box. Note that you define the :math:`z` extent of the
simulation box for 2d simulations when using the :doc:`create_box
<create_box>` or :doc:`read_data <read_data>` commands.
Output info
"""""""""""
By default, this compute calculates a per-atom array with two
columns. In regular dynamic tessellation mode the first column is the
Voronoi volume, the second is the neighbor count, as described above
(read above for the output data in case the *occupation* keyword is
specified). These values can be accessed by any command that uses
per-atom values from a compute as input. See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
options. If the *peratom* keyword is set to "no", the per-atom array
is still created, but it is not accessible.
.. deprecated:: 21Nov2023
The *peratom* keyword was removed as it is no longer required.
This compute calculates a per-atom array with two columns. In regular
dynamic tessellation mode the first column is the Voronoi volume, the
second is the neighbor count, as described above (read above for the
output data in case the *occupation* keyword is specified). These
values can be accessed by any command that uses per-atom values from a
compute as input. See the :doc:`Howto output <Howto_output>` page for
an overview of LAMMPS output options.
If the *edge_histo* keyword is used, then this compute generates a
global vector of length *maxedge*\ +1, containing a histogram of the
@ -209,17 +210,6 @@ If the *neighbors* value is set to *yes*, then this compute calculates a
local array with three columns. There is one row for each face of each
Voronoi cell.
.. note::
Some LAMMPS commands such as the :doc:`compute reduce <compute_reduce>`
command can accept either a per-atom or local quantity. If this compute
produces both quantities, the command
may access the per-atom quantity, even if you want to access the local
quantity. This effect can be eliminated by using the *peratom*
keyword to turn off the production of the per-atom quantities. For
the default value *yes* both quantities are produced. For the value
*no*, only the local array is produced.
The Voronoi cell volume will be in distance :doc:`units <units>` cubed.
The Voronoi face area will be in distance :doc:`units <units>` squared.
@ -227,7 +217,8 @@ Restrictions
""""""""""""
This compute is part of the VORONOI package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
It also requires you have a copy of the Voro++ library built and
installed on your system. See instructions on obtaining and
@ -241,5 +232,4 @@ Related commands
Default
"""""""
*neighbors* no, *peratom* yes
The default for the neighbors keyword is no.

29
doc/src/compute_xrd.rst
View File

@ -62,28 +62,29 @@ equations:
\frac{\sin(\theta)}{\lambda} &= \frac{\left\lVert\mathbf{k}\right\rVert}{2}
Here, :math:`\mathbf{k}` is the location of the reciprocal lattice node,
:math:`r_j` is the position of each atom, :math:`f_j` are atomic scattering
factors, *Lp* is the Lorentz-polarization factor, and :math:`\theta` is the
scattering angle of diffraction. The Lorentz-polarization factor can be turned
off using the optional *LP* keyword.
:math:`r_j` is the position of each atom, :math:`f_j` are atomic
scattering factors, *Lp* is the Lorentz-polarization factor, and
:math:`\theta` is the scattering angle of diffraction. The
Lorentz-polarization factor can be turned off using the optional *LP*
keyword.
Diffraction intensities are calculated on a three-dimensional mesh of
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.
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/xrd_mesh.jpg
.. image:: img/xrd_mesh.png
:scale: 75%
:align: center
For a mesh defined by the simulation domain, a rectilinear grid is
constructed with spacing :math:`c A^{-1}` along each reciprocal lattice
axis, where :math:`A` is a matrix containing the vectors corresponding to the
edges of the simulation cell. If one or two directions has non-periodic
boundary conditions, then the spacing in these directions is defined from the
average of the (inversed) box lengths with periodic boundary conditions.
Meshes defined by the simulation domain must contain at least one periodic
boundary.
axis, where :math:`A` is a matrix containing the vectors corresponding
to the edges of the simulation cell. If one or two directions has
non-periodic boundary conditions, then the spacing in these directions
is defined from the average of the (inversed) box lengths with periodic
boundary conditions. Meshes defined by the simulation domain must
contain at least one periodic boundary.
If the *manual* flag is included, the mesh of reciprocal lattice nodes
will be defined using the *c* values for the spacing along each

22
doc/src/dump.rst
View File

@ -613,7 +613,7 @@ when running on large numbers of processors.
Note that using the "\*" and "%" characters together can produce a
large number of small dump files!
.. deprecated:: TBD
.. deprecated:: 21Nov2023
The MPIIO package and the the corresponding "/mpiio" dump styles, except
for the unrelated "netcdf/mpiio" style were removed from LAMMPS.
@ -805,16 +805,16 @@ computes, fixes, or variables when they are evaluated, so this is a very
general means of creating quantities to output to a dump file.
The *i_name*, *d_name*, *i2_name*, *d2_name* attributes refer to
per-atom integer and floating-point vectors or arrays that have been
added via the :doc:`fix property/atom <fix_property_atom>` command.
When that command is used specific names are given to each attribute
which are the "name" portion of these keywords. For arrays *i2_name*
and *d2_name*, the column of the array must also be included following
the name in brackets (e.g., d2_xyz[i], i2_mySpin[i], where :math:`i` is
in the range from 1 to :math:`M`, where :math:`M` is the number of
columns in the custom array). See the discussion above for how :math:`i`
can be specified with a wildcard asterisk to effectively specify
multiple values.
custom per-atom integer and floating-point vectors or arrays that have
been added via the :doc:`fix property/atom <fix_property_atom>`
command. When that command is used specific names are given to each
attribute which are the "name" portion of these keywords. For arrays
*i2_name* and *d2_name*, the column of the array must also be included
following the name in brackets (e.g., d2_xyz[i], i2_mySpin[i], where
:math:`i` is in the range from 1 to :math:`M`, where :math:`M` is the
number of columns in the custom array). See the discussion above for
how :math:`i` can be specified with a wildcard asterisk to effectively
specify multiple values.
See the :doc:`Modify <Modify>` page for information on how to add
new compute and fix styles to LAMMPS to calculate per-atom quantities

2
doc/src/dump_image.rst
View File

@ -599,7 +599,7 @@ image will appear. The *sfactor* value must be a value 0.0 <=
*sfactor* <= 1.0, where *sfactor* = 1 is a highly reflective surface
and *sfactor* = 0 is a rough non-shiny surface.
.. versionadded:: TBD
.. versionadded:: 21Nov2023
The *fsaa* keyword can be used with the dump image command to improve
the image quality by enabling full scene anti-aliasing. Internally the

91
doc/src/fix.rst
View File

@ -77,35 +77,44 @@ for individual fixes for info on which ones can be restarted.
----------
Some fixes calculate one or more of four styles of quantities: global,
per-atom, local, or per-grid, which can be used by other commands or
output as described below. A global quantity is one or more
system-wide values, e.g. the energy of a wall interacting with
particles. A per-atom quantity is one or more values per atom,
e.g. the displacement vector for each atom since time 0. Per-atom
values are set to 0.0 for atoms not in the specified fix group. Local
quantities are calculated by each processor based on the atoms it
owns, but there may be zero or more per atoms. Per-grid quantities
are calculated on a regular 2d or 3d grid which overlays a 2d or 3d
simulation domain. The grid points and the data they store are
distributed across processors; each processor owns the grid points
which fall within its subdomain.
Some fixes calculate and store any of four *styles* of quantities:
global, per-atom, local, or per-grid.
Note that a single fix typically produces either global or per-atom or
local or per-grid values (or none at all). It does not produce both
global and per-atom. It can produce local or per-grid values in
tandem with global or per-atom values. The fix doc page will explain
the details.
A global quantity is one or more system-wide values, e.g. the energy
of a wall interacting with particles. A per-atom quantity is one or
more values per atom, e.g. the original coordinates of each atom at
time 0. Per-atom values are set to 0.0 for atoms not in the specified
fix group. Local quantities are calculated by each processor based on
the atoms it owns, but there may be zero or more per atom, e.g. values
for each bond. Per-grid quantities are calculated on a regular 2d or
3d grid which overlays a 2d or 3d simulation domain. The grid points
and the data they store are distributed across processors; each
processor owns the grid points which fall within its subdomain.
Global, per-atom, local, and per-grid quantities come in three kinds:
a single scalar value, a vector of values, or a 2d array of values.
The doc page for each fix describes the style and kind of values it
produces, e.g. a per-atom vector. Some fixes produce more than one
kind of a single style, e.g. a global scalar and a global vector.
As a general rule of thumb, fixes that produce per-atom quantities
have the word "atom" at the end of their style, e.g. *ave/atom*\ .
Fixes that produce local quantities have the word "local" at the end
of their style, e.g. *store/local*\ . Fixes that produce per-grid
quantities have the word "grid" at the end of their style,
e.g. *ave/grid*\ .
When a fix quantity is accessed, as in many of the output commands
discussed below, it can be referenced via the following bracket
notation, where ID is the ID of the fix:
Global, per-atom, local, and per-grid quantities can also be of three
*kinds*: a single scalar value (global only), a vector of values, or a
2d array of values. For per-atom, local, and per-grid quantities, a
"vector" means a single value for each atom, each local entity
(e.g. bond), or grid cell. Likewise an "array", means multiple values
for each atom, each local entity, or each grid cell.
Note that a single fix can produce any combination of global,
per-atom, local, or per-grid values. Likewise it can produce any
combination of scalar, vector, or array output for each style. The
exception is that for per-atom, local, and per-grid output, either a
vector or array can be produced, but not both. The doc page for each
fix explains the values it produces, if any.
When a fix output is accessed by another input script command it is
referenced via the following bracket notation, where ID is the ID of
the fix:
+-------------+--------------------------------------------+
| f_ID | entire scalar, vector, or array |
@ -116,19 +125,23 @@ notation, where ID is the ID of the fix:
+-------------+--------------------------------------------+
In other words, using one bracket reduces the dimension of the
quantity once (vector :math:`\to` scalar, array :math:`\to` vector). Using two
brackets reduces the dimension twice (array :math:`\to` scalar). Thus, a
command that uses scalar fix values as input can also process elements of a
vector or array.
quantity once (vector :math:`\to` scalar, array :math:`\to` vector).
Using two brackets reduces the dimension twice (array :math:`\to`
scalar). Thus, for example, a command that uses global scalar fix
values as input can also process elements of a vector or array.
Depending on the command, this can either be done directly using the
syntax in the table, or by first defining a :doc:`variable <variable>`
of the appropriate style to store the quantity, then using the
variable as an input to the command.
Note that commands and :doc:`variables <variable>` that use fix
quantities typically do not allow for all kinds (e.g., a command may
require a vector of values, not a scalar), and even if they do, the context
in which they are called can be used to resolve which output is being
requested. This means there is no
ambiguity about referring to a fix quantity as f_ID even if it
produces, for example, both a scalar and vector. The doc pages for
various commands explain the details.
Note that commands and :doc:`variables <variable>` which take fix
outputs as input typically do not allow for all styles and kinds of
data (e.g., a command may require global but not per-atom values, or
it may require a vector of values, not a scalar). This means there is
typically no ambiguity about referring to a fix output as c_ID even if
it produces, for example, both a scalar and vector. The doc pages for
various commands explain the details, including how any ambiguities
are resolved.
----------
@ -274,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
@ -333,6 +347,7 @@ accelerated styles exist.
* :doc:`pour <fix_pour>` - pour new atoms/molecules into a granular simulation domain
* :doc:`precession/spin <fix_precession_spin>` - apply a precession torque to each magnetic spin
* :doc:`press/berendsen <fix_press_berendsen>` - pressure control by Berendsen barostat
* :doc:`press/langevin <fix_press_langevin>` - pressure control by Langevin barostat
* :doc:`print <fix_print>` - print text and variables during a simulation
* :doc:`propel/self <fix_propel_self>` - model self-propelled particles
* :doc:`property/atom <fix_property_atom>` - add customized per-atom values

32
doc/src/fix_adapt.rst
View File

@ -205,6 +205,8 @@ formulas for the meaning of these parameters:
+------------------------------------------------------------------------------+--------------------------------------------------+-------------+
| :doc:`pace, pace/extrapolation <pair_pace>` | scale | type pairs |
+------------------------------------------------------------------------------+--------------------------------------------------+-------------+
| :doc:`quip <pair_quip>` | scale | type global |
+------------------------------------------------------------------------------+--------------------------------------------------+-------------+
| :doc:`snap <pair_snap>` | scale | type pairs |
+------------------------------------------------------------------------------+--------------------------------------------------+-------------+
| :doc:`spin/dmi <pair_spin_dmi>` | coulombic_cutoff | type global |
@ -219,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 |
+------------------------------------------------------------------------------+--------------------------------------------------+-------------+
@ -315,21 +317,21 @@ Currently *bond* does not support bond_style hybrid nor bond_style
hybrid/overlay as bond styles. The bond styles that currently work
with fix_adapt are
+------------------------------------+-------+-----------------+
+------------------------------------+------------+------------+
| :doc:`class2 <bond_class2>` | r0 | type bonds |
+------------------------------------+-------+-----------------+
+------------------------------------+------------+------------+
| :doc:`fene <bond_fene>` | k,r0 | type bonds |
+------------------------------------+-------+-----------------+
+------------------------------------+------------+------------+
| :doc:`fene/nm <bond_fene>` | k,r0 | type bonds |
+------------------------------------+-------+-----------------+
+------------------------------------+------------+------------+
| :doc:`gromos <bond_gromos>` | k,r0 | type bonds |
+------------------------------------+-------+-----------------+
+------------------------------------+------------+------------+
| :doc:`harmonic <bond_harmonic>` | k,r0 | type bonds |
+------------------------------------+-------+-----------------+
+------------------------------------+------------+------------+
| :doc:`morse <bond_morse>` | r0 | type bonds |
+------------------------------------+-------+-----------------+
+------------------------------------+------------+------------+
| :doc:`nonlinear <bond_nonlinear>` | epsilon,r0 | type bonds |
+------------------------------------+-------+-----------------+
+------------------------------------+------------+------------+
----------
@ -353,11 +355,11 @@ Currently *angle* does not support angle_style hybrid nor angle_style
hybrid/overlay as angle styles. The angle styles that currently work
with fix_adapt are
+------------------------------------+-------+-----------------+
| :doc:`harmonic <angle_harmonic>` | k,theta0 | type angles |
+------------------------------------+-------+-----------------+
| :doc:`cosine <angle_cosine>` | k | type angles |
+------------------------------------+-------+-----------------+
+------------------------------------+----------+-------------+
| :doc:`harmonic <angle_harmonic>` | k,theta0 | type angles |
+------------------------------------+----------+-------------+
| :doc:`cosine <angle_cosine>` | k | type angles |
+------------------------------------+----------+-------------+
Note that internally, theta0 is stored in radians, so the variable
this fix uses to reset theta0 needs to generate values in radians.
@ -482,7 +484,7 @@ Restrictions
Related commands
""""""""""""""""
:doc:`compute ti <compute_ti>`
:doc:`compute ti <compute_ti>`, :doc:`fix adapt/fep <fix_adapt_fep>`
Default
"""""""

24
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::
@ -307,7 +323,9 @@ the :doc:`run <run>` command. This fix is not invoked during
Restrictions
""""""""""""
none
The keyword "scale yes" is not supported for scaling per-atom parameters
diameter and change. You can use :doc:`fix adapt <fix_adapt>` for those.
Related commands
""""""""""""""""

6
doc/src/fix_atom_swap.rst
View File

@ -181,6 +181,12 @@ This fix is part of the MC package. It is only enabled if LAMMPS was
built with that package. See the :doc:`Build package <Build_package>`
doc page for more info.
This fix cannot be used with systems that do not have per-type masses
(e.g. atom style sphere) since the implemented algorithm pre-computes
velocity rescaling factors from per-type masses and ignores any per-atom
masses, if present. In case both, per-type and per-atom masses are
present, a warning is printed.
Related commands
""""""""""""""""

8
doc/src/fix_ave_chunk.rst
View File

@ -541,10 +541,10 @@ Restrictions
Related commands
""""""""""""""""
:doc:`compute <compute>`, :doc:`fix ave/atom <fix_ave_atom>`, `fix
:doc:ave/histo <fix_ave_histo>`, :doc:`fix ave/time <fix_ave_time>`,
:doc:`variable <variable>`, :doc:`fix ave/correlate
:doc:<fix_ave_correlate>`, `fix ave/atogrid <fix_ave_grid>`
:doc:`compute <compute>`, :doc:`fix ave/atom <fix_ave_atom>`,
:doc:`fix ave/histo <fix_ave_histo>`, :doc:`fix ave/time <fix_ave_time>`,
:doc:`variable <variable>`, :doc:`fix ave/correlate <fix_ave_correlate>`,
:doc:`fix ave/grid <fix_ave_grid>`
Default

42
doc/src/fix_ave_histo.rst
View File

@ -79,9 +79,10 @@ Description
Use one or more values as inputs every few timesteps to create a
single histogram. The histogram can then be averaged over longer
timescales. The resulting histogram can be used by other :doc:`output commands <Howto_output>`, and can also be written to a file. The
fix ave/histo/weight command has identical syntax to fix ave/histo,
except that exactly two values must be specified. See details below.
timescales. The resulting histogram can be used by other :doc:`output
commands <Howto_output>`, and can also be written to a file. The fix
ave/histo/weight command has identical syntax to fix ave/histo, except
that exactly two values must be specified. See details below.
The group specified with this command is ignored for global and local
input values. For per-atom input values, only atoms in the group
@ -96,14 +97,18 @@ different ways; see the discussion of the *beyond* keyword below.
Each input value can be an atom attribute (position, velocity, force
component) or can be the result of a :doc:`compute <compute>` or
:doc:`fix <fix>` or the evaluation of an equal-style or vector-style or
atom-style :doc:`variable <variable>`. The set of input values can be
either all global, all per-atom, or all local quantities. Inputs of
different kinds (e.g. global and per-atom) cannot be mixed. Atom
attributes are per-atom vector values. See the page for
individual "compute" and "fix" commands to see what kinds of
quantities they generate. See the optional *kind* keyword below for
how to force the fix ave/histo command to disambiguate if necessary.
:doc:`fix <fix>` or the evaluation of an equal-style or vector-style
or atom-style :doc:`variable <variable>`. The set of input values can
be either all global, all per-atom, or all local quantities. Inputs
of different kinds (e.g. global and per-atom) cannot be mixed. Atom
attributes are per-atom vector values. See the page for individual
"compute" and "fix" commands to see what kinds of quantities they
generate.
Note that a compute or fix can produce multiple kinds of data (global,
per-atom, local). If LAMMPS cannot unambiguously determine which kind
of data to use, the optional *kind* keyword discussed below can force
the desired disambiguation.
Note that the output of this command is a single histogram for all
input values combined together, not one histogram per input value.
@ -258,13 +263,14 @@ keyword is set to *vector*, then all input values must be global or
per-atom or local vectors, or columns of global or per-atom or local
arrays.
The *kind* keyword only needs to be set if a compute or fix produces
more than one kind of output (global, per-atom, local). If this is
not the case, then LAMMPS will determine what kind of input is
provided and whether all the input arguments are consistent. If a
compute or fix produces more than one kind of output, the *kind*
keyword should be used to specify which output will be used. The
remaining input arguments must still be consistent.
The *kind* keyword only needs to be used if any of the specified input
computes or fixes produce more than one kind of output (global,
per-atom, local). If not, LAMMPS will determine the kind of data all
the inputs produce and verify it is all the same kind. If not, an
error will be triggered. If a compute or fix produces more than one
kind of output, the *kind* keyword should be used to specify which
output will be used. The other input arguments must still be
consistent.
The *beyond* keyword determines how input values that fall outside the
*lo* to *hi* bounds are treated. Values such that *lo* :math:`\le` value

59
doc/src/fix_deposit.rst
View File

@ -17,12 +17,16 @@ Syntax
* M = insert a single atom or molecule every M steps
* seed = random # seed (positive integer)
* one or more keyword/value pairs may be appended to args
* keyword = *region* or *id* or *global* or *local* or *near* or *gaussian* or *attempt* or *rate* or *vx* or *vy* or *vz* or *target* or *mol* or *molfrac* or *rigid* or *shake* or *orient* or *units*
* keyword = *region* or *var* or *set* or *id* or *global* or *local* or *near* or *gaussian* or *attempt* or *rate* or *vx* or *vy* or *vz* or *target* or *mol* or *molfrac* or *rigid* or *shake* or *orient* or *units*
.. parsed-literal::
*region* value = region-ID
region-ID = ID of region to use as insertion volume
*var* value = name = variable name to evaluate for test of atom creation
*set* values = dim name
dim = *x* or *y* or *z*
name = name of variable to set with x, y, or z atom position
*id* value = *max* or *next*
max = atom ID for new atom(s) is max ID of all current atoms plus one
next = atom ID for new atom(s) increments by one for every deposition
@ -193,17 +197,19 @@ simulation that is "nearby" the chosen x,y position. In this context,
particles is less than the *delta* setting.
Once a trial x,y,z position has been selected, the insertion is only
performed if no current atom in the simulation is within a distance R
of any atom in the new particle, including the effect of periodic
boundary conditions if applicable. R is defined by the *near*
keyword. Note that the default value for R is 0.0, which will allow
atoms to strongly overlap if you are inserting where other atoms are
present. This distance test is performed independently for each atom
in an inserted molecule, based on the randomly rotated configuration
of the molecule. If this test fails, a new random position within the
insertion volume is chosen and another trial is made. Up to Q
attempts are made. If the particle is not successfully inserted,
LAMMPS prints a warning message.
performed if both the *near* and *var* keywords are satisfied (see below).
If either the *near* or the *var* keyword is not satisfied, a new random
position within the insertion volume is chosen and another trial is made.
Up to Q attempts are made. If one or more particle insertions are not
successful, LAMMPS prints a warning message.
The *near* keyword ensures that no current atom in the simulation is within
a distance R of any atom in the new particle, including the effect of
periodic boundary conditions if applicable. Note that the default value
for R is 0.0, which will allow atoms to strongly overlap if you are
inserting where other atoms are present. This distance test is performed
independently for each atom in an inserted molecule, based on the randomly
rotated configuration of the molecule.
.. note::
@ -214,6 +220,26 @@ LAMMPS prints a warning message.
existing particle. LAMMPS will issue a warning if R is smaller than
this value, based on the radii of existing and inserted particles.
.. versionadded:: 21Nov2023
The *var* and *set* keywords can be used together to provide a criterion
for accepting or rejecting the addition of an individual atom, based on its
coordinates. The *name* specified for the *var* keyword is the name of an
:doc:`equal-style variable <variable>` that should evaluate to a zero or
non-zero value based on one or two or three variables that will store the
*x*, *y*, or *z* coordinates of an atom (one variable per coordinate). If
used, these other variables must be :doc:`internal-style variables
<variable>` defined in the input script; their initial numeric value can be
anything. They must be internal-style variables, because this command
resets their values directly. The *set* keyword is used to identify the
names of these other variables, one variable for the *x*-coordinate of a
created atom, one for *y*, and one for *z*. When an atom is created, its
:math:`(x,y,z)` coordinates become the values for any *set* variable that
is defined. The *var* variable is then evaluated. If the returned value
is 0.0, the atom is not created. If it is non-zero, the atom is created.
For an example of how to use these keywords, see the
:doc:`create_atoms <create_atoms>` command.
The *rate* option moves the insertion volume in the z direction (3d)
or y direction (2d). This enables particles to be inserted from a
successively higher height over time. Note that this parameter is
@ -289,10 +315,11 @@ operation of the fix continues in an uninterrupted fashion.
The fix will try to detect it and stop with an error.
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. This fix is not invoked during :doc:`energy minimization <minimize>`.
fix. This fix computes a global scalar, which can be accessed by various
output commands. The scalar is the cumulative number of insertions. The
scalar value calculated by this fix is "intensive". No parameter of this
fix can be used with the *start/stop* keywords of the :doc:`run <run>`
command. This fix is not invoked during :doc:`energy minimization <minimize>`.
Restrictions
""""""""""""

7
doc/src/fix_efield.rst
View File

@ -1,4 +1,5 @@
.. index:: fix efield
.. index:: fix efield/kk
.. index:: fix efield/tip4p
fix efield command
@ -210,6 +211,12 @@ the iteration count during the minimization.
system (the quantity being minimized), you MUST enable the
:doc:`fix_modify <fix_modify>` *energy* option for this fix.
----------
.. include:: accel_styles.rst
----------
Restrictions
""""""""""""

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

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