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

Merge branch 'master' into tgnh

Browse Source
This commit is contained in:
Axel Kohlmeyer
2020-12-20 14:48:49 -05:00
parent 3d28f5d610 09028b27d4
commit 2e33887d0b
483 changed files with 19119 additions and 705896 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.github/CONTRIBUTING.md vendored
View File

@ -108,7 +108,7 @@ For bug reports, the next step is that one of the core LAMMPS developers will se
For submitting pull requests, there is a [detailed tutorial](https://lammps.sandia.gov/doc/Howto_github.html) in the LAMMPS manual. Thus only a brief breakdown of the steps is presented here. Please note, that the LAMMPS developers are still reviewing and trying to improve the process. If you are unsure about something, do not hesitate to post a question on the lammps-users mailing list or contact one fo the core LAMMPS developers. For submitting pull requests, there is a [detailed tutorial](https://lammps.sandia.gov/doc/Howto_github.html) in the LAMMPS manual. Thus only a brief breakdown of the steps is presented here. Please note, that the LAMMPS developers are still reviewing and trying to improve the process. If you are unsure about something, do not hesitate to post a question on the lammps-users mailing list or contact one fo the core LAMMPS developers.
Immediately after the submission, the LAMMPS continuing integration server at ci.lammps.org will download your submitted branch and perform a simple compilation test, i.e. will test whether your submitted code can be compiled under various conditions. It will also do a check on whether your included documentation translates cleanly. 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 the pull request is updated with a push to the remote branch on GitHub. Immediately after the submission, the LAMMPS continuing integration server at ci.lammps.org will download your submitted branch and perform a simple compilation test, i.e. will test whether your submitted code can be compiled under various conditions. It will also do a check on whether your included documentation translates cleanly. 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 the pull request is updated with a push to the remote branch on GitHub.
Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission. If you are not yet registered as a LAMMPS collaborator, you will receive an invitation for that. As part of the assesment, 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). Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission. If you are not yet registered as a LAMMPS collaborator, you will receive an invitation for that. 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. 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. 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.
If the assigned developer is satisfied and considers the submission ready for inclusion into LAMMPS, the pull request will receive approvals and be merged into the master branch by one of the core LAMMPS developers. After the pull request is merged, you may delete the feature branch used for the pull request in your personal LAMMPS fork. If the assigned developer is satisfied and considers the submission ready for inclusion into LAMMPS, the pull request will receive approvals and be merged into the master branch by one of the core LAMMPS developers. After the pull request is merged, you may delete the feature branch used for the pull request in your personal LAMMPS fork.

6
README
View File

@ -37,14 +37,14 @@ tools pre- and post-processing tools
Point your browser at any of these files to get started: Point your browser at any of these files to get started:
https://lammps.sandia.gov/doc/Manual.html LAMMPS user manual https://lammps.sandia.gov/doc/Manual.html LAMMPS manual
https://lammps.sandia.gov/doc/Intro.html hi-level introduction https://lammps.sandia.gov/doc/Intro.html hi-level introduction
https://lammps.sandia.gov/doc/Build.html how to build LAMMPS https://lammps.sandia.gov/doc/Build.html how to build LAMMPS
https://lammps.sandia.gov/doc/Run_head.html how to run LAMMPS https://lammps.sandia.gov/doc/Run_head.html how to run LAMMPS
https://lammps.sandia.gov/doc/Commands_all.html Table of available commands https://lammps.sandia.gov/doc/Commands_all.html Table of available commands
https://lammps.sandia.gov/doc/pg_library.html LAMMPS programmer guide https://lammps.sandia.gov/doc/Library.html LAMMPS library interfaces
https://lammps.sandia.gov/doc/Modify.html how to modify and extend LAMMPS https://lammps.sandia.gov/doc/Modify.html how to modify and extend LAMMPS
https://lammps.sandia.gov/doc/pg_developer.html LAMMPS developer guide https://lammps.sandia.gov/doc/Developer.html LAMMPS developer info
You can also create these doc pages locally: You can also create these doc pages locally:

10
cmake/CMakeLists.txt
View File

@ -220,6 +220,7 @@ if(BUILD_OMP)
endif() endif()
if (((CMAKE_CXX_COMPILER_ID STREQUAL "GNU") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 9.0)) OR if (((CMAKE_CXX_COMPILER_ID STREQUAL "GNU") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 9.0)) OR
(CMAKE_CXX_COMPILER_ID STREQUAL "PGI") OR
((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 10.0)) OR ((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 10.0)) OR
((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.0))) ((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.0)))
# GCC 9.x and later plus Clang 10.x and later implement strict OpenMP 4.0 semantics for consts. # GCC 9.x and later plus Clang 10.x and later implement strict OpenMP 4.0 semantics for consts.
@ -661,7 +662,7 @@ if(BUILD_SHARED_LIBS)
add_custom_target( add_custom_target(
install-python install-python
${Python_EXECUTABLE} install.py -v ${LAMMPS_SOURCE_DIR}/version.h ${Python_EXECUTABLE} install.py -v ${LAMMPS_SOURCE_DIR}/version.h
-m ${LAMMPS_PYTHON_DIR}/lammps.py -p ${LAMMPS_PYTHON_DIR}/lammps
-l ${CMAKE_BINARY_DIR}/liblammps${CMAKE_SHARED_LIBRARY_SUFFIX} -l ${CMAKE_BINARY_DIR}/liblammps${CMAKE_SHARED_LIBRARY_SUFFIX}
WORKING_DIRECTORY ${LAMMPS_PYTHON_DIR} WORKING_DIRECTORY ${LAMMPS_PYTHON_DIR}
COMMENT "Installing LAMMPS Python module") COMMENT "Installing LAMMPS Python module")
@ -691,11 +692,8 @@ if(BUILD_SHARED_LIBS OR PKG_PYTHON)
find_package(Python COMPONENTS Interpreter) find_package(Python COMPONENTS Interpreter)
endif() endif()
if (Python_EXECUTABLE) if (Python_EXECUTABLE)
execute_process(COMMAND ${Python_EXECUTABLE} file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/python)
-c "import distutils.sysconfig as cg; print(cg.get_python_lib(1,0,prefix='${CMAKE_INSTALL_PREFIX}'))" install(CODE "execute_process(COMMAND ${Python_EXECUTABLE} setup.py build -b ${CMAKE_BINARY_DIR}/python install --prefix=${CMAKE_INSTALL_PREFIX} --root=\$ENV{DESTDIR}/ WORKING_DIRECTORY ${LAMMPS_PYTHON_DIR})")
OUTPUT_VARIABLE PYTHON_DEFAULT_INSTDIR OUTPUT_STRIP_TRAILING_WHITESPACE)
set(PYTHON_INSTDIR ${PYTHON_DEFAULT_INSTDIR} CACHE PATH "Installation folder for LAMMPS Python module")
install(FILES ${LAMMPS_PYTHON_DIR}/lammps.py DESTINATION ${PYTHON_INSTDIR})
endif() endif()
endif() endif()

29
cmake/Modules/Packages/KIM.cmake
View File

@ -19,6 +19,8 @@ if(CURL_FOUND)
target_compile_definitions(lammps PRIVATE -DLMP_NO_SSL_CHECK) target_compile_definitions(lammps PRIVATE -DLMP_NO_SSL_CHECK)
endif() endif()
endif() endif()
set(KIM_EXTRA_UNITTESTS OFF CACHE STRING "Set extra unit tests verbose mode on/off. If on, extra tests are included.")
mark_as_advanced(KIM_EXTRA_UNITTESTS)
find_package(PkgConfig QUIET) find_package(PkgConfig QUIET)
set(DOWNLOAD_KIM_DEFAULT ON) set(DOWNLOAD_KIM_DEFAULT ON)
if(PKG_CONFIG_FOUND) if(PKG_CONFIG_FOUND)
@ -34,8 +36,8 @@ if(DOWNLOAD_KIM)
enable_language(C) enable_language(C)
enable_language(Fortran) enable_language(Fortran)
ExternalProject_Add(kim_build ExternalProject_Add(kim_build
URL https://s3.openkim.org/kim-api/kim-api-2.1.3.txz URL https://s3.openkim.org/kim-api/kim-api-2.2.1.txz
URL_MD5 6ee829a1bbba5f8b9874c88c4c4ebff8 URL_MD5 ae1ddda2ef7017ea07934e519d023dca
BINARY_DIR build BINARY_DIR build
CMAKE_ARGS ${CMAKE_REQUEST_PIC} CMAKE_ARGS ${CMAKE_REQUEST_PIC}
-DCMAKE_C_COMPILER=${CMAKE_C_COMPILER} -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
@ -53,11 +55,28 @@ if(DOWNLOAD_KIM)
add_library(LAMMPS::KIM UNKNOWN IMPORTED) add_library(LAMMPS::KIM UNKNOWN IMPORTED)
set_target_properties(LAMMPS::KIM PROPERTIES set_target_properties(LAMMPS::KIM PROPERTIES
IMPORTED_LOCATION "${INSTALL_DIR}/lib/libkim-api${CMAKE_SHARED_LIBRARY_SUFFIX}" IMPORTED_LOCATION "${INSTALL_DIR}/lib/libkim-api${CMAKE_SHARED_LIBRARY_SUFFIX}"
INTERFACE_INCLUDE_DIRECTORIES "${INSTALL_DIR}/include/kim-api") INTERFACE_INCLUDE_DIRECTORIES "${INSTALL_DIR}/include/kim-api"
target_link_libraries(lammps PRIVATE LAMMPS::KIM) )
add_dependencies(LAMMPS::KIM kim_build) add_dependencies(LAMMPS::KIM kim_build)
target_link_libraries(lammps PRIVATE LAMMPS::KIM)
# Set rpath so lammps build directory is relocatable
if("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
set(_rpath_prefix "@loader_path")
else()
set(_rpath_prefix "$ORIGIN")
endif()
set_target_properties(lmp PROPERTIES
BUILD_RPATH "${_rpath_prefix}/kim_build-prefix/lib"
)
else() else()
if(KIM-API_FOUND AND KIM_API_VERSION VERSION_GREATER_EQUAL 2.2.0)
# For kim-api >= 2.2.0
find_package(KIM-API ${KIM-API_MIN_VERSION} CONFIG REQUIRED)
target_link_libraries(lammps PRIVATE KIM-API::kim-api)
else()
# For kim-api 2.1.3 (consistent with previous version of this file)
find_package(PkgConfig REQUIRED) find_package(PkgConfig REQUIRED)
pkg_check_modules(KIM-API REQUIRED IMPORTED_TARGET libkim-api>=${KIM-API_MIN_VERSION}) pkg_check_modules(KIM-API REQUIRED IMPORTED_TARGET libkim-api>=KIM-API_MIN_VERSION)
target_link_libraries(lammps PRIVATE PkgConfig::KIM-API) target_link_libraries(lammps PRIVATE PkgConfig::KIM-API)
endif()
endif() endif()

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

@ -35,8 +35,8 @@ if(DOWNLOAD_KOKKOS)
list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}") list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
include(ExternalProject) include(ExternalProject)
ExternalProject_Add(kokkos_build ExternalProject_Add(kokkos_build
URL https://github.com/kokkos/kokkos/archive/3.2.00.tar.gz URL https://github.com/kokkos/kokkos/archive/3.2.01.tar.gz
URL_MD5 81569170fe232e5e64ab074f7cca5e50 URL_MD5 ba72440e285ccde05b403694ea0c92e5
CMAKE_ARGS ${KOKKOS_LIB_BUILD_ARGS} CMAKE_ARGS ${KOKKOS_LIB_BUILD_ARGS}
BUILD_BYPRODUCTS <INSTALL_DIR>/lib/libkokkoscore.a BUILD_BYPRODUCTS <INSTALL_DIR>/lib/libkokkoscore.a
) )
@ -50,7 +50,7 @@ if(DOWNLOAD_KOKKOS)
target_link_libraries(lammps PRIVATE LAMMPS::KOKKOS) target_link_libraries(lammps PRIVATE LAMMPS::KOKKOS)
add_dependencies(LAMMPS::KOKKOS kokkos_build) add_dependencies(LAMMPS::KOKKOS kokkos_build)
elseif(EXTERNAL_KOKKOS) elseif(EXTERNAL_KOKKOS)
find_package(Kokkos 3.2.00 REQUIRED CONFIG) find_package(Kokkos 3.2.01 REQUIRED CONFIG)
target_link_libraries(lammps PRIVATE Kokkos::kokkos) target_link_libraries(lammps PRIVATE Kokkos::kokkos)
else() else()
set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos) set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)

32
cmake/Modules/YAML.cmake Normal file
View File

@ -0,0 +1,32 @@
message(STATUS "Downloading and building YAML library")
include(ExternalProject)
set(YAML_URL "https://pyyaml.org/download/libyaml/yaml-0.2.5.tar.gz" CACHE STRING "URL for libyaml tarball")
mark_as_advanced(YAML_URL)
ExternalProject_Add(libyaml
URL ${YAML_URL}
URL_MD5 bb15429d8fb787e7d3f1c83ae129a999
SOURCE_DIR "${CMAKE_BINARY_DIR}/yaml-src"
BINARY_DIR "${CMAKE_BINARY_DIR}/yaml-build"
CONFIGURE_COMMAND <SOURCE_DIR>/configure ${CONFIGURE_REQUEST_PIC}
CXX=${CMAKE_CXX_COMPILER}
CC=${CMAKE_C_COMPILER}
--prefix=<INSTALL_DIR> --disable-shared
BUILD_BYPRODUCTS <INSTALL_DIR>/lib/${CMAKE_FIND_LIBRARY_PREFIXES}yaml.a
TEST_COMMAND "")
ExternalProject_Get_Property(libyaml INSTALL_DIR)
set(YAML_INCLUDE_DIR ${INSTALL_DIR}/include)
set(YAML_LIBRARY_DIR ${INSTALL_DIR}/lib)
# workaround for CMake 3.10 on ubuntu 18.04
file(MAKE_DIRECTORY ${YAML_INCLUDE_DIR})
file(MAKE_DIRECTORY ${YAML_LIBRARY_DIR})
set(YAML_LIBRARY_PATH ${INSTALL_DIR}/lib/${CMAKE_FIND_LIBRARY_PREFIXES}yaml.a)
add_library(Yaml::Yaml UNKNOWN IMPORTED)
set_target_properties(Yaml::Yaml PROPERTIES
IMPORTED_LOCATION ${YAML_LIBRARY_PATH}
INTERFACE_INCLUDE_DIRECTORIES ${YAML_INCLUDE_DIR})
add_dependencies(Yaml::Yaml libyaml)

16
cmake/presets/pgi.cmake Normal file
View File

@ -0,0 +1,16 @@
# preset that will enable clang/clang++ with support for MPI and OpenMP (on Linux boxes)
set(CMAKE_CXX_COMPILER "pgc++" CACHE STRING "" FORCE)
set(CMAKE_C_COMPILER "pgcc" CACHE STRING "" FORCE)
set(CMAKE_Fortran_COMPILER "pgfortran" CACHE STRING "" FORCE)
set(MPI_CXX "pgc++" CACHE STRING "" FORCE)
set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
unset(HAVE_OMP_H_INCLUDE CACHE)
set(OpenMP_C "pgcc" CACHE STRING "" FORCE)
set(OpenMP_C_FLAGS "-mp" CACHE STRING "" FORCE)
set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
set(OpenMP_CXX "pgc++" CACHE STRING "" FORCE)
set(OpenMP_CXX_FLAGS "-mp" CACHE STRING "" FORCE)
set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
set(OpenMP_omp_LIBRARY "libomp.so" CACHE PATH "" FORCE)

2
doc/Makefile
View File

@ -229,7 +229,7 @@ $(VENV):
$(VIRTUALENV) -p $(PYTHON) $(VENV); \ $(VIRTUALENV) -p $(PYTHON) $(VENV); \
. $(VENV)/bin/activate; \ . $(VENV)/bin/activate; \
pip install --upgrade pip; \ pip install --upgrade pip; \
pip install --use-feature=2020-resolver -r $(BUILDDIR)/utils/requirements.txt; \ pip install -r $(BUILDDIR)/utils/requirements.txt; \
deactivate;\ deactivate;\
) )

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

@ -95,7 +95,7 @@ on the pull request discussion page on GitHub, so that other developers
can later review the entire discussion after the fact and understand the can later review the entire discussion after the fact and understand the
rationale behind choices made. Exceptions to this policy are technical rationale behind choices made. Exceptions to this policy are technical
discussions, that are centered on tools or policies themselves discussions, that are centered on tools or policies themselves
(git, github, c++) rather than on the content of the pull request. (git, GitHub, c++) rather than on the content of the pull request.
### Checklist for Pull Requests ### Checklist for Pull Requests

2
doc/lammps.1
View File

@ -1,4 +1,4 @@
.TH LAMMPS "29 October 2020" "2020-10-29" .TH LAMMPS "30 November 2020" "2020-10-29"
.SH NAME .SH NAME
.B LAMMPS .B LAMMPS
\- Molecular Dynamics Simulator. \- Molecular Dynamics Simulator.

5
doc/src/Build_basics.rst
View File

@ -236,12 +236,15 @@ LAMMPS.
cmake ../cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort cmake ../cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort
# Building with LLVM/Clang Compilers: # Building with LLVM/Clang Compilers:
cmake ../cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_Fortran_COMPILER=flang cmake ../cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_Fortran_COMPILER=flang
# Building with PGI/Nvidia Compilers:
cmake ../cmake -DCMAKE_C_COMPILER=pgcc -DCMAKE_CXX_COMPILER=pgc++ -DCMAKE_Fortran_COMPILER=pgfortran
For compiling with the Clang/LLVM compilers a CMake preset is For compiling with the Clang/LLVM compilers a CMake preset is
provided that can be loaded with provided that can be loaded with
`-C ../cmake/presets/clang.cmake`. Similarly, `-C ../cmake/presets/clang.cmake`. Similarly,
`-C ../cmake/presets/intel.cmake` should switch the compiler `-C ../cmake/presets/intel.cmake` should switch the compiler
toolchain to the Intel compilers. toolchain to the Intel compilers and `-C ../cmake/presets/pgi.cmake`
should switch the compiler to the PGI compilers.
In addition you can set ``CMAKE_TUNE_FLAGS`` to specifically add In addition you can set ``CMAKE_TUNE_FLAGS`` to specifically add
compiler flags to tune for optimal performance on given hosts. By compiler flags to tune for optimal performance on given hosts. By

36
doc/src/Build_development.rst
View File

@ -108,11 +108,18 @@ results over a given number of steps and operations within a given
error margin). The status of this automated testing can be viewed on error margin). The status of this automated testing can be viewed on
`https://ci.lammps.org <https://ci.lammps.org>`_. `https://ci.lammps.org <https://ci.lammps.org>`_.
The scripts and inputs for integration, run, and regression testing
are maintained in a
`separate repository <https://github.com/lammps/lammps-testing>`_
of the LAMMPS project on GitHub.
The unit testing facility is integrated into the CMake build process The unit testing facility is integrated into the CMake build process
of the LAMMPS source code distribution itself. It can be enabled by of the LAMMPS source code distribution itself. It can be enabled by
setting ``-D ENABLE_TESTING=on`` during the CMake configuration step. setting ``-D ENABLE_TESTING=on`` during the CMake configuration step.
It requires the `PyYAML <http://pyyaml.org/>`_ library and development It requires the `YAML <http://pyyaml.org/>`_ library and development
headers to compile and will download and compile a recent version of the headers (if those are not found locally a recent version will be
downloaded and compiled along with LAMMPS and the test program) to
compile and will download and compile a specific recent version of the
`Googletest <https://github.com/google/googletest/>`_ C++ test framework `Googletest <https://github.com/google/googletest/>`_ C++ test framework
for implementing the tests. for implementing the tests.
@ -162,22 +169,21 @@ The ``ctest`` command has many options, the most important ones are:
In its full implementation, the unit test framework will consist of multiple In its full implementation, the unit test framework will consist of multiple
kinds of tests implemented in different programming languages (C++, C, Python, kinds of tests implemented in different programming languages (C++, C, Python,
Fortran) and testing different aspects of the LAMMPS software and its features. Fortran) and testing different aspects of the LAMMPS software and its features.
At the moment only tests for "force styles" are implemented. More on those The tests will adapt to the compilation settings of LAMMPS, so that tests
in the next section. will be skipped if prerequisite features are not available in LAMMPS.
.. note:: .. note::
The unit test framework is new and still under development. The unit test framework was added in spring 2020 and is under active
The coverage is only minimal and will be expanded over time. development. The coverage is not complete and will be expanded over
Tests styles of the same kind of style (e.g. pair styles or time.
bond styles) are performed with the same executable using
different input files in YAML format. So to add a test for Tests for styles of the same kind of style (e.g. pair styles or bond
another pair style can be done by copying the YAML file and styles) are performed with the same test executable using different
editing the style settings and then running the individual test input files in YAML format. So to add a test for another style of the
program with a flag to update the computed reference data. same kind it may be sufficient to add a suitable YAML file.
Detailed documentation about how to add new test program and :doc:`Detailed instructions for adding tests <Developer_unittest>` are
the contents of the YAML files for existing test programs provided in the Programmer Guide part of the manual.
will be provided in time as well.
Unit tests for force styles Unit tests for force styles
^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^

38
doc/src/Build_extras.rst
View File

@ -282,6 +282,7 @@ minutes to hours) to build. Of course you only need to do that once.)
-D DOWNLOAD_KIM=value # download OpenKIM API v2 for build, value = no (default) or yes -D DOWNLOAD_KIM=value # download OpenKIM API v2 for build, value = no (default) or yes
-D LMP_DEBUG_CURL=value # set libcurl verbose mode on/off, value = off (default) or on -D LMP_DEBUG_CURL=value # set libcurl verbose mode on/off, value = off (default) or on
-D LMP_NO_SSL_CHECK=value # tell libcurl to not verify the peer, value = no (default) or yes -D LMP_NO_SSL_CHECK=value # tell libcurl to not verify the peer, value = no (default) or yes
-D KIM_EXTRA_UNITTESTS=value # enables extra unit tests, value = no (default) or yes
If ``DOWNLOAD_KIM`` is set to *yes* (or *on*), the KIM API library If ``DOWNLOAD_KIM`` is set to *yes* (or *on*), the KIM API library
will be downloaded and built inside the CMake build directory. If will be downloaded and built inside the CMake build directory. If
@ -290,6 +291,11 @@ minutes to hours) to build. Of course you only need to do that once.)
``PKG_CONFIG_PATH`` environment variable so that libkim-api can be ``PKG_CONFIG_PATH`` environment variable so that libkim-api can be
found, or run the command ``source kim-api-activate``. found, or run the command ``source kim-api-activate``.
Extra unit tests can only be available if they are explicitly requested
(``KIM_EXTRA_UNITTESTS`` is set to *yes* (or *on*)) and the prerequisites
are met. See :ref:`KIM Extra unit tests <kim_extra_unittests>` for
more details on this.
.. tab:: Traditional make .. tab:: Traditional make
You can download and build the KIM library manually if you prefer; You can download and build the KIM library manually if you prefer;
@ -338,6 +344,38 @@ specify your own CA cert path by setting the environment variable
``CURL_CA_BUNDLE`` to the path of your choice. A call to the KIM web ``CURL_CA_BUNDLE`` to the path of your choice. A call to the KIM web
query would get this value from the environment variable. query would get this value from the environment variable.
.. _kim_extra_unittests:
KIM Extra unit tests (CMake only)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
During development, testing, or debugging, if
:doc:`unit testing <Build_development>` is enabled in LAMMPS, one can also
enable extra tests on :doc:`KIM commands <kim_commands>` by setting the
``KIM_EXTRA_UNITTESTS`` to *yes* (or *on*).
Enabling the extra unit tests have some requirements,
* It requires to have internet access.
* It requires to have libcurl installed with the matching development headers
and the curl-config tool.
* It requires to build LAMMPS with the PYTHON package installed and linked to
Python 3.6 or later. See the :ref:`PYTHON package build info <python>` for
more details on this.
* It requires to have ``kim-property`` Python package installed, which can be
easily done using *pip* as ``pip install kim-property``, or from the
*conda-forge* channel as ``conda install kim-property`` if LAMMPS is built in
Conda. More detailed information is available at:
`kim-property installation <https://github.com/openkim/kim-property#installing-kim-property>`_.
* It is also necessary to install
``EAM_Dynamo_Mendelev_2007_Zr__MO_848899341753_000``, and
``EAM_Dynamo_ErcolessiAdams_1994_Al__MO_123629422045_005`` KIM models.
See `Obtaining KIM Models <http://openkim.org/doc/usage/obtaining-models>`_
to learn how to install a pre-build binary of the OpenKIM Repository of
Models or see
`Installing KIM Models <https://openkim.org/doc/usage/obtaining-models/#installing_models>`_
to learn how to install the specific KIM models.
---------- ----------
.. _kokkos: .. _kokkos:

2
doc/src/Build_package.rst
View File

@ -1,4 +1,5 @@
Include packages in build Include packages in build
========================= =========================
In LAMMPS, a package is a group of files that enable a specific set of In LAMMPS, a package is a group of files that enable a specific set of
@ -160,6 +161,7 @@ one of them as a starting point and customize it to your needs.
cmake -C ../cmake/presets/clang.cmake [OPTIONS] ../cmake # change settings to use the Clang compilers by default cmake -C ../cmake/presets/clang.cmake [OPTIONS] ../cmake # change settings to use the Clang compilers by default
cmake -C ../cmake/presets/gcc.cmake [OPTIONS] ../cmake # change settings to use the GNU compilers by default cmake -C ../cmake/presets/gcc.cmake [OPTIONS] ../cmake # change settings to use the GNU compilers by default
cmake -C ../cmake/presets/intel.cmake [OPTIONS] ../cmake # change settings to use the Intel compilers by default cmake -C ../cmake/presets/intel.cmake [OPTIONS] ../cmake # change settings to use the Intel compilers by default
cmake -C ../cmake/presets/pgi.cmake [OPTIONS] ../cmake # change settings to use the PGI compilers by default
cmake -C ../cmake/presets/all_on.cmake [OPTIONS] ../cmake # enable all packages cmake -C ../cmake/presets/all_on.cmake [OPTIONS] ../cmake # enable all packages
cmake -C ../cmake/presets/all_off.cmake [OPTIONS] ../cmake # disable 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 mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake # compile with MinGW cross compilers

2
doc/src/Commands_bond.rst
View File

@ -35,6 +35,7 @@ OPT.
* :doc:`class2 (ko) <bond_class2>` * :doc:`class2 (ko) <bond_class2>`
* :doc:`fene (iko) <bond_fene>` * :doc:`fene (iko) <bond_fene>`
* :doc:`fene/expand (o) <bond_fene_expand>` * :doc:`fene/expand (o) <bond_fene_expand>`
* :doc:`gaussian <bond_gaussian>`
* :doc:`gromos (o) <bond_gromos>` * :doc:`gromos (o) <bond_gromos>`
* :doc:`harmonic (iko) <bond_harmonic>` * :doc:`harmonic (iko) <bond_harmonic>`
* :doc:`harmonic/shift (o) <bond_harmonic_shift>` * :doc:`harmonic/shift (o) <bond_harmonic_shift>`
@ -84,6 +85,7 @@ OPT.
* :doc:`dipole (o) <angle_dipole>` * :doc:`dipole (o) <angle_dipole>`
* :doc:`fourier (o) <angle_fourier>` * :doc:`fourier (o) <angle_fourier>`
* :doc:`fourier/simple (o) <angle_fourier_simple>` * :doc:`fourier/simple (o) <angle_fourier_simple>`
* :doc:`gaussian <angle_gaussian>` - multicentered Gaussian-based angle potential
* :doc:`harmonic (iko) <angle_harmonic>` * :doc:`harmonic (iko) <angle_harmonic>`
* :doc:`mm3 <angle_mm3>` * :doc:`mm3 <angle_mm3>`
* :doc:`quartic (o) <angle_quartic>` * :doc:`quartic (o) <angle_quartic>`

3
doc/src/Commands_fix.rst
View File

@ -62,6 +62,7 @@ OPT.
* :doc:`efield <fix_efield>` * :doc:`efield <fix_efield>`
* :doc:`ehex <fix_ehex>` * :doc:`ehex <fix_ehex>`
* :doc:`electron/stopping <fix_electron_stopping>` * :doc:`electron/stopping <fix_electron_stopping>`
* :doc:`electron/stopping/fit <fix_electron_stopping>`
* :doc:`enforce2d (k) <fix_enforce2d>` * :doc:`enforce2d (k) <fix_enforce2d>`
* :doc:`eos/cv <fix_eos_cv>` * :doc:`eos/cv <fix_eos_cv>`
* :doc:`eos/table <fix_eos_table>` * :doc:`eos/table <fix_eos_table>`
@ -195,7 +196,7 @@ OPT.
* :doc:`saed/vtk <fix_saed_vtk>` * :doc:`saed/vtk <fix_saed_vtk>`
* :doc:`setforce (k) <fix_setforce>` * :doc:`setforce (k) <fix_setforce>`
* :doc:`setforce/spin <fix_setforce>` * :doc:`setforce/spin <fix_setforce>`
* :doc:`shake <fix_shake>` * :doc:`shake (k) <fix_shake>`
* :doc:`shardlow (k) <fix_shardlow>` * :doc:`shardlow (k) <fix_shardlow>`
* :doc:`smd <fix_smd>` * :doc:`smd <fix_smd>`
* :doc:`smd/adjust_dt <fix_smd_adjust_dt>` * :doc:`smd/adjust_dt <fix_smd_adjust_dt>`

1
doc/src/Commands_pair.rst
View File

@ -241,6 +241,7 @@ OPT.
* :doc:`spin/dipole/long <pair_spin_dipole>` * :doc:`spin/dipole/long <pair_spin_dipole>`
* :doc:`spin/dmi <pair_spin_dmi>` * :doc:`spin/dmi <pair_spin_dmi>`
* :doc:`spin/exchange <pair_spin_exchange>` * :doc:`spin/exchange <pair_spin_exchange>`
* :doc:`spin/exchange/biquadratic <pair_spin_exchange>`
* :doc:`spin/magelec <pair_spin_magelec>` * :doc:`spin/magelec <pair_spin_magelec>`
* :doc:`spin/neel <pair_spin_neel>` * :doc:`spin/neel <pair_spin_neel>`
* :doc:`srp <pair_srp>` * :doc:`srp <pair_srp>`

1
doc/src/Developer.rst
View File

@ -13,5 +13,6 @@ of time and requests from the LAMMPS user community.
Developer_org Developer_org
Developer_flow Developer_flow
Developer_write Developer_write
Developer_unittest
Classes Classes
Developer_utils Developer_utils

523
doc/src/Developer_unittest.rst Normal file
View File

@ -0,0 +1,523 @@
Adding tests for unit testing
-----------------------------
This section discusses adding or expanding tests for the unit test
infrastructure included into the LAMMPS source code distribution.
Unlike example inputs, unit tests focus on testing the "local" behavior
of individual features, tend to run very fast, and should be set up to
cover as much of the added code as possible. When contributing code to
the distribution, the LAMMPS developers will appreciate if additions
to the integrated unit test facility are included.
Given the complex nature of MD simulations where many operations can
only be performed when suitable "real" simulation environment has been
set up, not all tests will be unit tests in the strict definition of
the term. They are rather executed on a more abstract level by issuing
LAMMPS script commands and then inspecting the changes to the internal
data. For some classes of tests, generic test programs have been
written that can be applied to parts of LAMMPS that use the same
interface (via polymorphism) and those are driven by input files, so
tests can be added by simply adding more of those input files. Those
tests should be seen more as a hybrid between unit and regression tests.
When adding tests it is recommended to also :ref:`enable support for
code coverage reporting <testing>`, and study the coverage reports
so that it is possible to monitor which parts of the code of a given
file are executed during the tests and which tests would need to be
added to increase the coverage.
The tests are grouped into categories and corresponding folders.
The following sections describe how the tests are implemented and
executed in those categories with increasing complexity of tests
and implementation.
Tests for utility functions
^^^^^^^^^^^^^^^^^^^^^^^^^^^
These tests are driven by programs in the ``unittest/utils`` folder
and most closely resemble conventional unit tests. There is one test
program for each namespace or group of classes or file. The naming
convention for the sources and executables is that they start with
with ``test_``. The following sources and groups of tests are currently
available:
.. list-table::
:header-rows: 1
:widths: auto
:align: left
* - File name:
- Test name:
- Description:
* - ``test_fmtlib.cpp``
- FmtLib
- Tests for ``fmtlib::`` functions used by LAMMPS
* - ``test_math_eigen_impl.cpp``
- MathEigen
- Tests for ``MathEigen::`` classes and functions
* - ``test_mempool.cpp``
- MemPool
- Tests for :cpp:class:`MyPage <LAMMPS_NS::MyPage>` and :cpp:class:`MyPoolChunk <LAMMPS_NS::MyPoolChunk>`
* - ``test_tokenizer.cpp``
- Tokenizer
- Tests for :cpp:class:`Tokenizer <LAMMPS_NS::Tokenizer>` and :cpp:class:`ValueTokenizer <LAMMPS_NS::ValueTokenizer>`
* - ``test_utils.cpp``
- Utils
- Tests for ``utils::`` :doc:`functions <Developer_utils>`
To add tests either an existing source file needs to be modified or a
new source file needs to be added to the distribution and enabled for
testing. To add a new file suitable CMake script code needs to be added
to the ``CMakeLists.txt`` file in the ``unittest/utils`` folder. Example:
.. code-block:: cmake
add_executable(test_tokenizer test_tokenizer.cpp)
target_link_libraries(test_tokenizer PRIVATE lammps GTest::GMockMain GTest::GMock GTest::GTest)
add_test(Tokenizer test_tokenizer)
This adds instructions to build the ``test_tokenizer`` executable from
``test_tokenizer.cpp`` and links it with the GoogleTest libraries and the
LAMMPS library as well as it uses the ``main()`` function from the
GoogleMock library of GoogleTest. The third line registers the executable
as a test program to be run from ``ctest`` under the name ``Tokenizer``.
The test executable itself will execute multiple individual tests
through the GoogleTest framework. In this case each test consists of
creating a tokenizer class instance with a given string and explicit or
default separator choice, and then executing member functions of the
class and comparing their results with expected values. A few examples:
.. code-block:: c++
TEST(Tokenizer, empty_string)
{
Tokenizer t("", " ");
ASSERT_EQ(t.count(), 0);
}
TEST(Tokenizer, two_words)
{
Tokenizer t("test word", " ");
ASSERT_EQ(t.count(), 2);
}
TEST(Tokenizer, default_separators)
{
Tokenizer t(" \r\n test \t word \f");
ASSERT_THAT(t.next(), Eq("test"));
ASSERT_THAT(t.next(), Eq("word"));
ASSERT_EQ(t.count(), 2);
}
Each of these TEST functions will become an individual
test run by the test program. When using the ``ctest``
command as a front end to run the tests, their output
will be suppressed and only a summary printed, but adding
the '-V' option will then produce output from the tests
above like the following:
.. code-block::
[...]
1: [ RUN ] Tokenizer.empty_string
1: [ OK ] Tokenizer.empty_string (0 ms)
1: [ RUN ] Tokenizer.two_words
1: [ OK ] Tokenizer.two_words (0 ms)
1: [ RUN ] Tokenizer.default_separators
1: [ OK ] Tokenizer.default_separators (0 ms)
[...]
The MathEigen test collection has been adapted from a standalone test
and does not use the GoogleTest framework and thus not representative.
The other test sources, however, can serve as guiding examples for
additional tests.
Tests for individual LAMMPS commands
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The tests ``unittest/commands`` are a bit more complex as they require
to first create a :cpp:class:`LAMMPS <LAMMPS_NS::LAMMPS>` class instance
and then use the :doc:`C++ API <Cplusplus>` to pass individual commands
to that LAMMPS instance. For that reason these tests use a GoogleTest
"test fixture", i.e. a class derived from ``testing::Test`` that will
create (and delete) the required LAMMPS class instance for each set of
tests in a ``TEST_F()`` function. Please see the individual source files
for different examples of setting up suitable test fixtures. Here is an
example for implementing a test using a fixture by first checking the
default value and then issuing LAMMPS commands and checking whether they
have the desired effect:
.. code-block:: c++
TEST_F(SimpleCommandsTest, ResetTimestep)
{
ASSERT_EQ(lmp->update->ntimestep, 0);
if (!verbose) ::testing::internal::CaptureStdout();
lmp->input->one("reset_timestep 10");
if (!verbose) ::testing::internal::GetCapturedStdout();
ASSERT_EQ(lmp->update->ntimestep, 10);
if (!verbose) ::testing::internal::CaptureStdout();
lmp->input->one("reset_timestep 0");
if (!verbose) ::testing::internal::GetCapturedStdout();
ASSERT_EQ(lmp->update->ntimestep, 0);
}
Please note the use of the (global) verbose variable to control whether
the LAMMPS command will be silent by capturing the output or not. In
the default case, verbose == false, the test output will be compact and
not mixed with LAMMPS output. However setting the verbose flag (via
setting the ``TEST_ARGS`` environment variable, ``TEST_ARGS=-v``) can be
helpful 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:
.. code-block:: C++
TEST_F(SimpleCommandsTest, UnknownCommand)
{
TEST_FAILURE(".*ERROR: Unknown command.*", lmp->input->one("XXX one two"););
}
The following test programs are currently available:
.. list-table::
:header-rows: 1
:widths: auto
:align: left
* - File name:
- Test name:
- Description:
* - ``test_simple_commands.cpp``
- SimpleCommands
- Tests for LAMMPS commands that do not require a box
* - ``test_lattice_region.cpp``
- LatticeRegion
- Tests to validate the :doc:`lattice <lattice>` and :doc:`region <region>` commands
* - ``test_kim_commands.cpp``
- KimCommands
- Tests for several commands from the :ref:`KIM package <PKG-KIM>`
* - ``test_reset_ids.cpp``
- ResetIDs
- Tests to validate the :doc:`reset_atom_ids <reset_atom_ids>` and :doc:`reset_mol_ids <reset_mol_ids>` commands
Tests for the C-style library interface
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Tests for validating the LAMMPS C-style library interface are in the
``unittest/c-library`` folder. They are implemented in either way used
for utility functions and for LAMMPS commands, but use the functions
implemented in the ``src/library.cpp`` file as much as possible. There
may be some overlap with other tests, but only in as much as is required
to test the C-style library API. The tests are distributed over
multiple test programs which tries to match the grouping of the
functions in the source code and :ref:`in the manual <lammps_c_api>`.
This group of tests also includes tests invoking LAMMPS in parallel
through the library interface, provided that LAMMPS was compiled with
MPI support. These include tests where LAMMPS is run in multi-partition
mode or only on a subset of the MPI world communicator. The CMake
script code for adding this kind of test looks like this:
.. code-block:: CMake
if (BUILD_MPI)
add_executable(test_library_mpi test_library_mpi.cpp)
target_link_libraries(test_library_mpi PRIVATE lammps GTest::GTest GTest::GMock)
target_compile_definitions(test_library_mpi PRIVATE ${TEST_CONFIG_DEFS})
add_mpi_test(NAME LibraryMPI NUM_PROCS 4 COMMAND $<TARGET_FILE:test_library_mpi>)
endif()
Note the custom function ``add_mpi_test()`` which adapts how ``ctest``
will execute the test so it is launched in parallel (with 4 MPI ranks).
Tests for the Python module and package
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The ``unittest/python`` folder contains primarily tests for classes and
functions in the LAMMPS python module but also for commands in the
PYTHON package. These tests are only enabled, if the necessary
prerequisites are detected or enabled during configuration and
compilation of LAMMPS (shared library build enabled, Python interpreter
found, Python development files found).
The Python tests are implemented using the ``unittest`` standard Python
module and split into multiple files with similar categories as the
tests for the C-style library interface.
Tests for the Fortran interface
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
Tests for the C++-style library interface
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The tests in the ``unittest/cplusplus`` folder are somewhat similar to
the tests for the C-style library interface, but do not need to test the
several convenience and utility functions that are only available through
the C-style interface. Instead it can focus on the more generic features
that are used internally. This part of the unit tests is currently still
mostly in the planning stage.
Tests for reading and writing file formats
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The ``unittest/formats`` folder contains test programs for reading and
writing files like data files, restart files, potential files or dump files.
This covers simple things like the file i/o convenience functions in the
``utils::`` namespace to complex tests of atom styles where creating and
deleting of atoms with different properties is tested in different ways
and through script commands or reading and writing of data or restart files.
Tests for styles computing or modifying forces
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
These are tests common configurations for pair styles, bond styles,
angle styles, kspace styles and certain fix styles. Those are tests
driven by some test executables build from sources in the
``unittest/force-styles`` folder and use LAMMPS input template and data
files as well as input files in YAML format from the
``unittest/force-styles/tests`` folder. The YAML file names have to
follow some naming conventions so they get associated with the test
programs and categorized and listed with canonical names in the list
of tests as displayed by ``ctest -N``. If you add a new YAML file,
you need to re-run CMake to update the corresponding list of tests.
A minimal YAML file for a (molecular) pair style test will looks
something like the following (see ``mol-pair-zero.yaml``):
.. code-block:: yaml
---
lammps_version: 24 Aug 2020
date_generated: Tue Sep 15 09:44:21 202
epsilon: 1e-14
prerequisites: ! |
atom full
pair zero
pre_commands: ! ""
post_commands: ! ""
input_file: in.fourmol
pair_style: zero 8.0
pair_coeff: ! |
* *
extract: ! ""
natoms: 29
init_vdwl: 0
init_coul: 0
[...]
The following table describes the available keys and their purpose for
testing pair styles:
.. list-table::
:header-rows: 1
* - Key:
- Description:
* - lammps_version
- LAMMPS version used to last update the reference data
* - date_generated
- date when the file was last updated
* - epsilon
- base value for the relative precision required for tests to pass
* - prerequisites
- list of style kind / style name pairs required to run the test
* - pre_commands
- LAMMPS commands to be executed before the input template file is read
* - post_commands
- LAMMPS commands to be executed right before the actual tests
* - input_file
- LAMMPS input file template based on pair style zero
* - pair_style
- arguments to the pair_style command to be tested
* - pair_coeff
- list of pair_coeff arguments to set parameters for the input template
* - extract
- list of keywords supported by ``Pair::extract()`` and their dimension
* - natoms
- number of atoms in the input file template
* - init_vdwl
- non-Coulomb pair energy after "run 0"
* - init_coul
- Coulomb pair energy after "run 0"
* - init_stress
- stress tensor after "run 0"
* - init_forces
- forces on atoms after "run 0"
* - run_vdwl
- non-Coulomb pair energy after "run 4"
* - run_coul
- Coulomb pair energy after "run 4"
* - run_stress
- stress tensor after "run 4"
* - run_forces
- forces on atoms after "run 4"
The test program will read all this data from the YAML file and then
create a LAMMPS instance, apply the settings/commands from the YAML file
as needed and then issue a "run 0" command, write out a restart file, a
data file and a coeff file. The actual test will then compare computed
energies, stresses, and forces with the reference data, issue a "run 4"
command and compare to the second set of reference data. This will be
run with both the newton_pair setting enabled and disabled and is
expected to generate the same results (allowing for some numerical
noise). Then it will restart from the previously generated restart and
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, USER-OMP,
USER-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.
Additional tests will check whether all listed extract keywords are
supported and have the correct dimensionality and the final set of tests
will set up a few pairs of atoms explicitly and in such a fashion that
the forces on the atoms computed from ``Pair::compute()`` will match
individually with the results from ``Pair::single()``, if the pair style
does support that functionality.
With this scheme a large fraction of the code of any tested pair style
will be executed and consistent results are required for different
settings and between different accelerated pair style variants and the
base class, as well as for computing individual pairs through the
``Pair::single()`` where supported.
The ``test_pair_style`` tester is used with 4 categories of test inputs:
- pair styles compatible with molecular systems using bonded
interactions and exclusions. For pair styles requiring a KSpace style
the KSpace computations are disabled. The YAML files match the
pattern "mol-pair-\*.yaml" and the tests are correspondingly labeled
with "MolPairStyle:\*"
- pair styles not compatible with the previous input template.
The YAML files match the pattern "atomic-pair-\*.yaml" and the tests are
correspondingly labeled with "AtomicPairStyle:\*"
- manybody pair styles.
The YAML files match the pattern "atomic-pair-\*.yaml" and the tests are
correspondingly labeled with "AtomicPairStyle:\*"
- kspace styles.
The YAML files match the pattern "kspace-\*.yaml" and the tests are
correspondingly labeled with "KSpaceStyle:\*". In these cases a compatible
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.
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.
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,
if a pair style requires a "newton on" setting, the following can be used in
as the "pre_commands" section:
.. code-block:: yaml
pre_commands: ! |
variable newton_pair delete
variable newton_pair index on
And for a pair style requiring a kspace solver the following would be used as
the "post_commands" section:
.. code-block:: yaml
post_commands: ! |
pair_modify table 0
kspace_style pppm/tip4p 1.0e-6
kspace_modify gewald 0.3
kspace_modify compute no
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
files then should be compared manually, if they agree well enough within the limits
of those two approximations.
The ``test_pair_style`` and equivalent programs have special command line options
to update the YAML files. Running a command like
.. code-block:: bash
$ test_pair_style mol-pair-lennard_mdf.yaml -g new.yaml
will read the settings from the ``mol-pair-lennard_mdf.yaml`` file and then compute
the reference data and write a new file with to ``new.yaml``. If this step fails,
there are likely some (LAMMPS or YAML) syntax issues in the YAML file that need to
be resolved and then one can compare the two files to see if the output is as expected.
It is also possible to do an update in place with:
.. code-block:: bash
$ test_pair_style mol-pair-lennard_mdf.yaml -u
And one can finally run the full set of tests with:
.. code-block:: bash
$ test_pair_style mol-pair-lennard_mdf.yaml
This will just print a summary of the groups of tests. When using the "-v" flag
the test will also keep any LAMMPS output and when using the "-s" flag, there
will be some statistics reported on the relative errors for the individual checks
which can help to figure out what would be a good choice of the epsilon parameter.
It should be as small as possible to catch any unintended side effects from changes
elsewhere, but large enough to accommodate the numerical noise due to the implementation
of the potentials and differences in compilers.
.. note::
These kinds of tests can be very sensitive to compiler optimization and
thus the expectation is that they pass with compiler optimization turned
off. When compiler optimization is enabled, there may be some failures, but
one has to carefully check whether those are acceptable due to the enhanced
numerical noise from reordering floating-point math operations or due to
the compiler mis-compiling the code. That is not always obvious.
Tests for programs in the tools folder
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The ``unittest/tools`` folder contains tests for programs in the
``tools`` folder. This currently only contains tests for the LAMMPS
shell, which are implemented as a python scripts using the ``unittest``
Python module and launching the tool commands through the ``subprocess``
Python module.

1
doc/src/Errors_warnings.rst
View File

@ -119,7 +119,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
:doc:`pair style zero <pair_zero>` with a suitable cutoff or use :doc:`comm_modify cutoff <comm_modify>`. :doc:`pair style zero <pair_zero>` with a suitable cutoff or use :doc:`comm_modify cutoff <comm_modify>`.
*Communication cutoff is shorter than a bond length based estimate. This may lead to errors.* *Communication cutoff is shorter than a bond length based estimate. This may lead to errors.*
Since LAMMPS stores topology data with individual atoms, all atoms Since LAMMPS stores topology data with individual atoms, all atoms
comprising a bond, angle, dihedral or improper must be present on any comprising a bond, angle, dihedral or improper must be present on any
sub-domain that "owns" the atom with the information, either as a sub-domain that "owns" the atom with the information, either as a

2
doc/src/Howto_drude2.rst
View File

@ -36,7 +36,7 @@ polarizability :math:`\alpha` by
Ideally, the mass of the Drude particle should be small, and the Ideally, the mass of the Drude particle should be small, and the
stiffness of the harmonic bond should be large, so that the Drude stiffness of the harmonic bond should be large, so that the Drude
particle remains close ot the core. The values of Drude mass, Drude particle remains close to the core. The values of Drude mass, Drude
charge, and force constant can be chosen following different charge, and force constant can be chosen following different
strategies, as in the following examples of polarizable force strategies, as in the following examples of polarizable force
fields: fields:

4
doc/src/Howto_github.rst
View File

@ -72,7 +72,7 @@ explained in more detail here: `feature branch workflow <https://www.atlassian.c
**Feature branches** **Feature branches**
First of all, create a clone of your version on github on your local First of all, create a clone of your version on GitHub on your local
machine via HTTPS: machine via HTTPS:
.. code-block:: bash .. code-block:: bash
@ -155,7 +155,7 @@ useful message that explains the change.
.. code-block:: bash .. code-block:: bash
$ git commit -m 'Finally updated the github tutorial' $ git commit -m 'Finally updated the GitHub tutorial'
After the commit, the changes can be pushed to the same branch on GitHub: After the commit, the changes can be pushed to the same branch on GitHub:

4
doc/src/Howto_pylammps.rst
View File

@ -9,8 +9,8 @@ Overview
``PyLammps`` is a Python wrapper class for LAMMPS which can be created ``PyLammps`` is a Python wrapper class for LAMMPS which can be created
on its own or use an existing lammps Python object. It creates a simpler, on its own or use an existing lammps Python object. It creates a simpler,
more "pythonic" interface to common LAMMPS functionality, in contrast to more "pythonic" interface to common LAMMPS functionality, in contrast to
the ``lammps.py`` wrapper for the C-style LAMMPS library interface which the ``lammps`` wrapper for the C-style LAMMPS library interface which
is written using `Python ctypes <ctypes_>`_. The ``lammps.py`` wrapper is written using `Python ctypes <ctypes_>`_. The ``lammps`` wrapper
is discussed on the :doc:`Python_head` doc page. is discussed on the :doc:`Python_head` doc page.
Unlike the flat ``ctypes`` interface, PyLammps exposes a discoverable Unlike the flat ``ctypes`` interface, PyLammps exposes a discoverable

2
doc/src/Howto_walls.rst
View File

@ -67,5 +67,5 @@ rotate.
The only frictional idealized walls currently in LAMMPS are flat or The only frictional idealized walls currently in LAMMPS are flat or
curved surfaces specified by the :doc:`fix wall/gran <fix_wall_gran>` curved surfaces specified by the :doc:`fix wall/gran <fix_wall_gran>`
command. At some point we plan to allow regoin surfaces to be used as command. At some point we plan to allow region surfaces to be used as
frictional walls, as well as triangulated surfaces. frictional walls, as well as triangulated surfaces.

12
doc/src/Intro_citing.rst
View File

@ -24,13 +24,15 @@ DOI for the LAMMPS code
LAMMPS developers use the `Zenodo service at CERN LAMMPS developers use the `Zenodo service at CERN
<https://zenodo.org/>`_ to create digital object identifies (DOI) for <https://zenodo.org/>`_ to create digital object identifies (DOI) for
stable releases of the LAMMPS code. There are two types of DOIs for the stable releases of the LAMMPS code. There are two types of DOIs for the
LAMMPS source code: 1) the canonical DOI for **all** versions of LAMMPS, LAMMPS source code: the canonical DOI for **all** versions of LAMMPS,
which will always point to the latest stable release version is: which will always point to the **latest** stable release version is:
`DOI: 10.5281/zenodo.3726416 <https://dx.doi/org/10.5281/zenodo.3726416>`_ - DOI: `10.5281/zenodo.3726416 <https://dx.doi.org/10.5281/zenodo.3726416>`_
In addition there are DOIs for individual stable releases starting with In addition there are DOIs for individual stable releases. Currently there are:
the `3 March 2020 version, DOI:10.5281/zenodo.3726417 <https://dx.doi/org/10.5281/zenodo.3726416>`_
- 3 March 2020 version: `DOI:10.5281/zenodo.3726417 <https://dx.doi.org/10.5281/zenodo.3726417>`_
- 29 October 2020 version: `DOI:10.5281/zenodo.4157471 <https://dx.doi.org/10.5281/zenodo.4157471>`_
Home page Home page

2
doc/src/Packages_details.rst
View File

@ -1036,9 +1036,11 @@ the usual manner via MD. Various pair, fix, and compute styles.
* :doc:`pair_style spin/dipole/long <pair_spin_dipole>` * :doc:`pair_style spin/dipole/long <pair_spin_dipole>`
* :doc:`pair_style spin/dmi <pair_spin_dmi>` * :doc:`pair_style spin/dmi <pair_spin_dmi>`
* :doc:`pair_style spin/exchange <pair_spin_exchange>` * :doc:`pair_style spin/exchange <pair_spin_exchange>`
* :doc:`pair_style spin/exchange/biquadratic <pair_spin_exchange>`
* :doc:`pair_style spin/magelec <pair_spin_magelec>` * :doc:`pair_style spin/magelec <pair_spin_magelec>`
* :doc:`pair_style spin/neel <pair_spin_neel>` * :doc:`pair_style spin/neel <pair_spin_neel>`
* :doc:`fix nve/spin <fix_nve_spin>` * :doc:`fix nve/spin <fix_nve_spin>`
* :doc:`fix langevin/spin <fix_langevin_spin>`
* :doc:`fix precession/spin <fix_precession_spin>` * :doc:`fix precession/spin <fix_precession_spin>`
* :doc:`compute spin <compute_spin>` * :doc:`compute spin <compute_spin>`
* :doc:`neb/spin <neb_spin>` * :doc:`neb/spin <neb_spin>`

2
doc/src/Python_ext.rst
View File

@ -9,7 +9,7 @@ This means you can extend the Python wrapper by following these steps:
* Add a new interface function to ``src/library.cpp`` and * Add a new interface function to ``src/library.cpp`` and
``src/library.h``. ``src/library.h``.
* Rebuild LAMMPS as a shared library. * Rebuild LAMMPS as a shared library.
* Add a wrapper method to ``python/lammps.py`` for this interface * Add a wrapper method to ``python/lammps/core.py`` for this interface
function. function.
* Define the corresponding ``argtypes`` list and ``restype`` * Define the corresponding ``argtypes`` list and ``restype``
in the ``lammps.__init__()`` function. in the ``lammps.__init__()`` function.

152
doc/src/Python_install.rst
View File

@ -8,9 +8,9 @@ module. Because of the dynamic loading, it is required that LAMMPS is
compiled in :ref:`"shared" mode <exe>`. It is also recommended to compiled in :ref:`"shared" mode <exe>`. It is also recommended to
compile LAMMPS with :ref:`C++ exceptions <exceptions>` enabled. compile LAMMPS with :ref:`C++ exceptions <exceptions>` enabled.
Two files are necessary for Python to be able to invoke LAMMPS code: Two components are necessary for Python to be able to invoke LAMMPS code:
* The LAMMPS Python Module (``lammps.py``) from the ``python`` folder * The LAMMPS Python Package (``lammps``) from the ``python`` folder
* The LAMMPS Shared Library (``liblammps.so``, ``liblammps.dylib`` or * The LAMMPS Shared Library (``liblammps.so``, ``liblammps.dylib`` or
``liblammps.dll``) from the folder where you compiled LAMMPS. ``liblammps.dll``) from the folder where you compiled LAMMPS.
@ -25,10 +25,10 @@ Installing the LAMMPS Python Module and Shared Library
====================================================== ======================================================
Making LAMMPS usable within Python and vice versa requires putting the Making LAMMPS usable within Python and vice versa requires putting the
LAMMPS Python module file (``lammps.py``) into a location where the LAMMPS Python package (``lammps``) into a location where the
Python interpreter can find it and installing the LAMMPS shared library Python interpreter can find it and installing the LAMMPS shared library
into a folder that the dynamic loader searches or into the same folder into a folder that the dynamic loader searches or inside of the installed
where the ``lammps.py`` file is. There are multiple ways to achieve ``lammps`` package folder. There are multiple ways to achieve
this. this.
#. Do a full LAMMPS installation of libraries, executables, selected #. Do a full LAMMPS installation of libraries, executables, selected
@ -36,13 +36,13 @@ this.
available via CMake), which can also be either system-wide or into available via CMake), which can also be either system-wide or into
user specific folders. user specific folders.
#. Install both files into a Python ``site-packages`` folder, either #. Install both components into a Python ``site-packages`` folder, either
system-wide or in the corresponding user-specific folder. This way no system-wide or in the corresponding user-specific folder. This way no
additional environment variables need to be set, but the shared additional environment variables need to be set, but the shared
library is otherwise not accessible. library is otherwise not accessible.
#. Do an installation into a virtual environment. This can either be #. Do an installation into a virtual environment. This can either be an
an installation of the python module only or a full installation. installation of the Python package only or a full installation of LAMMPS.
#. Leave the files where they are in the source/development tree and #. Leave the files where they are in the source/development tree and
adjust some environment variables. adjust some environment variables.
@ -81,19 +81,19 @@ this.
This leads to an installation to the following locations: This leads to an installation to the following locations:
+------------------------+-----------------------------------------------------------+-------------------------------------------------------------+ +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes | | File | Location | Notes |
+========================+===========================================================+=============================================================+ +========================+=================================================================+=============================================================+
| LAMMPS Python Module | * ``$HOME/.local/lib/pythonX.Y/site-packages/`` (32bit) | ``X.Y`` depends on the installed Python version | | LAMMPS Python package | * ``$HOME/.local/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``$HOME/.local/lib64/pythonX.Y/site-packages/`` (64bit) | | | | * ``$HOME/.local/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+-----------------------------------------------------------+-------------------------------------------------------------+ +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``$HOME/.local/lib/`` (32bit) | | | LAMMPS shared library | * ``$HOME/.local/lib/`` (32bit) | Set shared loader environment variable to this path |
| | * ``$HOME/.local/lib64/`` (64bit) | | | | * ``$HOME/.local/lib64/`` (64bit) | (see below for more info on this) |
+------------------------+-----------------------------------------------------------+-------------------------------------------------------------+ +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS executable | * ``$HOME/.local/bin/`` | | | LAMMPS executable | * ``$HOME/.local/bin/`` | |
+------------------------+-----------------------------------------------------------+-------------------------------------------------------------+ +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS potential files | * ``$HOME/.local/share/lammps/potentials/`` | Set ``LAMMPS_POTENTIALS`` environment variable to this path | | LAMMPS potential files | * ``$HOME/.local/share/lammps/potentials/`` | Set ``LAMMPS_POTENTIALS`` environment variable to this path |
+------------------------+-----------------------------------------------------------+-------------------------------------------------------------+ +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
For a system-wide installation you need to set For a system-wide installation you need to set
``CMAKE_INSTALL_PREFIX`` to a system folder like ``/usr`` (or ``CMAKE_INSTALL_PREFIX`` to a system folder like ``/usr`` (or
@ -102,19 +102,19 @@ this.
privilege, e.g. by using ``sudo cmake --install .``. The privilege, e.g. by using ``sudo cmake --install .``. The
installation folders will then by changed to: installation folders will then by changed to:
+------------------------+---------------------------------------------------+-------------------------------------------------------------+ +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes | | File | Location | Notes |
+========================+===================================================+=============================================================+ +========================+=========================================================+=============================================================+
| LAMMPS Python Module | * ``/usr/lib/pythonX.Y/site-packages/`` (32bit) | ``X.Y`` depends on the installed Python version | | LAMMPS Python package | * ``/usr/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``/usr/lib64/pythonX.Y/site-packages/`` (64bit) | | | | * ``/usr/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+---------------------------------------------------+-------------------------------------------------------------+ +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``/usr/lib/`` (32bit) | | | LAMMPS shared library | * ``/usr/lib/`` (32bit) | |
| | * ``/usr/lib64/`` (64bit) | | | | * ``/usr/lib64/`` (64bit) | |
+------------------------+---------------------------------------------------+-------------------------------------------------------------+ +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS executable | * ``/usr/bin/`` | | | LAMMPS executable | * ``/usr/bin/`` | |
+------------------------+---------------------------------------------------+-------------------------------------------------------------+ +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS potential files | * ``/usr/share/lammps/potentials/`` | | | LAMMPS potential files | * ``/usr/share/lammps/potentials/`` | |
+------------------------+---------------------------------------------------+-------------------------------------------------------------+ +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
To be able to use the "user" installation you have to ensure that To be able to use the "user" installation you have to ensure that
the folder containing the LAMMPS shared library is either included the folder containing the LAMMPS shared library is either included
@ -146,7 +146,7 @@ this.
necessary due to files installed in system folders that are loaded necessary due to files installed in system folders that are loaded
automatically when a login shell is started. automatically when a login shell is started.
.. tab:: Python module only .. tab:: Python package only
Compile LAMMPS with either :doc:`CMake <Build_cmake>` or the Compile LAMMPS with either :doc:`CMake <Build_cmake>` or the
:doc:`traditional make <Build_make>` procedure in :ref:`shared :doc:`traditional make <Build_make>` procedure in :ref:`shared
@ -157,37 +157,37 @@ this.
make install-python make install-python
This will try to install (only) the shared library and the python This will try to install (only) the shared library and the Python
module into a system folder and if that fails (due to missing package into a system folder and if that fails (due to missing
write permissions) will instead do the installation to a user write permissions) will instead do the installation to a user
folder under ``$HOME/.local``. For a system-wide installation you folder under ``$HOME/.local``. For a system-wide installation you
would have to gain superuser privilege, e.g. though ``sudo`` would have to gain superuser privilege, e.g. though ``sudo``
+------------------------+-----------------------------------------------------------+-------------------------------------------------------------+ +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes | | File | Location | Notes |
+========================+===========================================================+=============================================================+ +========================+=================================================================+=============================================================+
| LAMMPS Python Module | * ``$HOME/.local/lib/pythonX.Y/site-packages/`` (32bit) | ``X.Y`` depends on the installed Python version | | LAMMPS Python package | * ``$HOME/.local/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``$HOME/.local/lib64/pythonX.Y/site-packages/`` (64bit) | | | | * ``$HOME/.local/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+-----------------------------------------------------------+-------------------------------------------------------------+ +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``$HOME/.local/lib/pythonX.Y/site-packages/`` (32bit) | ``X.Y`` depends on the installed Python version | | LAMMPS shared library | * ``$HOME/.local/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``$HOME/.local/lib64/pythonX.Y/site-packages/`` (64bit) | | | | * ``$HOME/.local/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+-----------------------------------------------------------+-------------------------------------------------------------+ +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
For a system-wide installation those folders would then become. For a system-wide installation those folders would then become.
+------------------------+---------------------------------------------------+-------------------------------------------------------------+ +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes | | File | Location | Notes |
+========================+===================================================+=============================================================+ +========================+=========================================================+=============================================================+
| LAMMPS Python Module | * ``/usr/lib/pythonX.Y/site-packages/`` (32bit) | ``X.Y`` depends on the installed Python version | | LAMMPS Python package | * ``/usr/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``/usr/lib64/pythonX.Y/site-packages/`` (64bit) | | | | * ``/usr/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+---------------------------------------------------+-------------------------------------------------------------+ +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``/usr/lib/pythonX.Y/site-packages/`` (32bit) | ``X.Y`` depends on the installed Python version | | LAMMPS shared library | * ``/usr/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``/usr/lib64/pythonX.Y/site-packages/`` (64bit) | | | | * ``/usr/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+---------------------------------------------------+-------------------------------------------------------------+ +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
No environment variables need to be set for those, as those No environment variables need to be set for those, as those
folders are searched by default by Python or the LAMMPS Python folders are searched by default by Python or the LAMMPS Python
module. package.
For the traditional make process you can override the python For the traditional make process you can override the python
version to version x.y when calling ``make`` with version to version x.y when calling ``make`` with
@ -199,9 +199,9 @@ this.
.. code-block:: bash .. code-block:: bash
$ python install.py -m <python module> -l <shared library> -v <version.h file> [-d <pydir>] $ python install.py -p <python package> -l <shared library> -v <version.h file> [-d <pydir>]
* The ``-m`` flag points to the ``lammps.py`` python module file to be installed, * The ``-p`` flag points to the ``lammps`` Python package folder to be installed,
* the ``-l`` flag points to the LAMMPS shared library file to be installed, * the ``-l`` flag points to the LAMMPS shared library file to be installed,
* the ``-v`` flag points to the ``version.h`` file in the LAMMPS source * the ``-v`` flag points to the ``version.h`` file in the LAMMPS source
* and the optional ``-d`` flag to a custom (legacy) installation folder * and the optional ``-d`` flag to a custom (legacy) installation folder
@ -249,38 +249,38 @@ this.
When using CMake to build LAMMPS, you need to set When using CMake to build LAMMPS, you need to set
``CMAKE_INSTALL_PREFIX`` to the value of the ``$VIRTUAL_ENV`` ``CMAKE_INSTALL_PREFIX`` to the value of the ``$VIRTUAL_ENV``
environment variable during the configuration step. For the environment variable during the configuration step. For the
traditional make procedure, not additional steps are needed. traditional make procedure, no additional steps are needed.
After compiling LAMMPS you can do a "Python module only" After compiling LAMMPS you can do a "Python package only"
installation with ``make install-python`` and the LAMMPS Python installation with ``make install-python`` and the LAMMPS Python
module and the shared library file are installed into the package and the shared library file are installed into the
following locations: following locations:
+------------------------+-----------------------------------------------------------+-------------------------------------------------------------+ +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes | | File | Location | Notes |
+========================+===========================================================+=============================================================+ +========================+=================================================================+=============================================================+
| LAMMPS Python Module | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/`` (32bit) | ``X.Y`` depends on the installed Python version | | LAMMPS Python Module | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``$VIRTUAL_ENV/lib64/pythonX.Y/site-packages/`` (64bit) | | | | * ``$VIRTUAL_ENV/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+-----------------------------------------------------------+-------------------------------------------------------------+ +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/`` (32bit) | ``X.Y`` depends on the installed Python version | | LAMMPS shared library | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``$VIRTUAL_ENV/lib64/pythonX.Y/site-packages/`` (64bit) | | | | * ``$VIRTUAL_ENV/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+-----------------------------------------------------------+-------------------------------------------------------------+ +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
If you do a full installation (CMake only) with "install", this If you do a full installation (CMake only) with "install", this
leads to the following installation locations: leads to the following installation locations:
+------------------------+-----------------------------------------------------------+-------------------------------------------------------------+ +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes | | File | Location | Notes |
+========================+===========================================================+=============================================================+ +========================+=================================================================+=============================================================+
| LAMMPS Python Module | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/`` (32bit) | ``X.Y`` depends on the installed Python version | | LAMMPS Python Module | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``$VIRTUAL_ENV/lib64/pythonX.Y/site-packages/`` (64bit) | | | | * ``$VIRTUAL_ENV/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+-----------------------------------------------------------+-------------------------------------------------------------+ +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``$VIRTUAL_ENV/lib/`` (32bit) | | | LAMMPS shared library | * ``$VIRTUAL_ENV/lib/`` (32bit) | Set shared loader environment variable to this path |
| | * ``$VIRTUAL_ENV/lib64/`` (64bit) | | | | * ``$VIRTUAL_ENV/lib64/`` (64bit) | (see below for more info on this) |
+------------------------+-----------------------------------------------------------+-------------------------------------------------------------+ +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS executable | * ``$VIRTUAL_ENV/bin/`` | | | LAMMPS executable | * ``$VIRTUAL_ENV/bin/`` | |
+------------------------+-----------------------------------------------------------+-------------------------------------------------------------+ +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS potential files | * ``$VIRTUAL_ENV/share/lammps/potentials/`` | | | LAMMPS potential files | * ``$VIRTUAL_ENV/share/lammps/potentials/`` | Set ``LAMMPS_POTENTIALS`` environment variable to this path |
+------------------------+-----------------------------------------------------------+-------------------------------------------------------------+ +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
In that case you need to modify the ``$HOME/myenv/bin/activate`` In that case you need to modify the ``$HOME/myenv/bin/activate``
script in a similar fashion you need to update your script in a similar fashion you need to update your
@ -296,15 +296,15 @@ this.
echo 'export LD_LIBRARY_PATH=$VIRTUAL_ENV/lib:$LD_LIBRARY_PATH' >> $HOME/myenv/bin/activate echo 'export LD_LIBRARY_PATH=$VIRTUAL_ENV/lib:$LD_LIBRARY_PATH' >> $HOME/myenv/bin/activate
# MacOS # MacOS
echo 'export DYLD_LIBRARY_PATH=$VIRTUAL_ENV/lib:$LD_LIBRARY_PATH' >> $HOME/myenv/bin/activate echo 'export DYLD_LIBRARY_PATH=$VIRTUAL_ENV/lib:$DYLD_LIBRARY_PATH' >> $HOME/myenv/bin/activate
.. tab:: In place usage .. tab:: In place usage
You can also :doc:`compile LAMMPS <Build>` as usual in You can also :doc:`compile LAMMPS <Build>` as usual in
:ref:`"shared" mode <exe>` leave the shared library and Python :ref:`"shared" mode <exe>` leave the shared library and Python
module files inside the source/compilation folders. Instead of package inside the source/compilation folders. Instead of
copying the files where they can be found, you need to set the environment copying the files where they can be found, you need to set the environment
variables ``PYTHONPATH`` (for the Python module) and variables ``PYTHONPATH`` (for the Python package) and
``LD_LIBRARY_PATH`` (or ``DYLD_LIBRARY_PATH`` on MacOS ``LD_LIBRARY_PATH`` (or ``DYLD_LIBRARY_PATH`` on MacOS
For Bourne shells (bash, ksh and similar) the commands are: For Bourne shells (bash, ksh and similar) the commands are:
@ -325,6 +325,10 @@ this.
You can make those changes permanent by editing your ``$HOME/.bashrc`` You can make those changes permanent by editing your ``$HOME/.bashrc``
or ``$HOME/.login`` files, respectively. or ``$HOME/.login`` files, respectively.
.. note::
The ``PYTHONPATH`` needs to point to the parent folder that contains the ``lammps`` package!
To verify if LAMMPS can be successfully started from Python, start the To verify if LAMMPS can be successfully started from Python, start the
Python interpreter, load the ``lammps`` Python module and create a Python interpreter, load the ``lammps`` Python module and create a
@ -346,7 +350,7 @@ output similar to the following:
.. note:: .. note::
Unless you opted for "In place use", you will have to rerun the installation Unless you opted for "In place use", you will have to rerun the installation
any time you recompile LAMMPS to ensure the latest Python module and shared any time you recompile LAMMPS to ensure the latest Python package and shared
library are installed and used. library are installed and used.
.. note:: .. note::

24
doc/src/Python_module.rst
View File

@ -3,12 +3,12 @@ The ``lammps`` Python module
.. py:module:: lammps .. py:module:: lammps
The LAMMPS Python interface is implemented as a module called The LAMMPS Python interface is implemented as a module called :py:mod:`lammps`
:py:mod:`lammps` in the ``lammps.py`` file in the ``python`` folder of which is defined in the ``lammps`` package in the ``python`` folder of the
the LAMMPS source code distribution. After compilation of LAMMPS, the LAMMPS source code distribution. After compilation of LAMMPS, the module can
module can be installed into a Python system folder or a user folder be installed into a Python system folder or a user folder with ``make
with ``make install-python``. Components of the module can then loaded install-python``. Components of the module can then loaded into a Python
into a Python session with the ``import`` command. session with the ``import`` command.
There are multiple Python interface classes in the :py:mod:`lammps` module: There are multiple Python interface classes in the :py:mod:`lammps` module:
@ -44,7 +44,7 @@ functions. Below is a detailed documentation of the API.
.. autoclass:: lammps.lammps .. autoclass:: lammps.lammps
:members: :members:
.. autoclass:: lammps.numpy_wrapper .. autoclass:: lammps.numpy::numpy_wrapper
:members: :members:
---------- ----------
@ -117,8 +117,8 @@ Style Constants
to request from computes or fixes. See :cpp:enum:`_LMP_STYLE_CONST` to request from computes or fixes. See :cpp:enum:`_LMP_STYLE_CONST`
for the equivalent constants in the C library interface. Used in for the equivalent constants in the C library interface. Used in
:py:func:`lammps.extract_compute`, :py:func:`lammps.extract_fix`, and their NumPy variants :py:func:`lammps.extract_compute`, :py:func:`lammps.extract_fix`, and their NumPy variants
:py:func:`lammps.numpy.extract_compute() <numpy_wrapper.extract_compute>` and :py:func:`lammps.numpy.extract_compute() <lammps.numpy.numpy_wrapper.extract_compute>` and
:py:func:`lammps.numpy.extract_fix() <numpy_wrapper.extract_fix>`. :py:func:`lammps.numpy.extract_fix() <lammps.numpy.numpy_wrapper.extract_fix>`.
.. _py_type_constants: .. _py_type_constants:
@ -132,8 +132,8 @@ Type Constants
to request from computes or fixes. See :cpp:enum:`_LMP_TYPE_CONST` to request from computes or fixes. See :cpp:enum:`_LMP_TYPE_CONST`
for the equivalent constants in the C library interface. Used in for the equivalent constants in the C library interface. Used in
:py:func:`lammps.extract_compute`, :py:func:`lammps.extract_fix`, and their NumPy variants :py:func:`lammps.extract_compute`, :py:func:`lammps.extract_fix`, and their NumPy variants
:py:func:`lammps.numpy.extract_compute() <numpy_wrapper.extract_compute>` and :py:func:`lammps.numpy.extract_compute() <lammps.numpy.numpy_wrapper.extract_compute>` and
:py:func:`lammps.numpy.extract_fix() <numpy_wrapper.extract_fix>`. :py:func:`lammps.numpy.extract_fix() <lammps.numpy.numpy_wrapper.extract_fix>`.
.. _py_vartype_constants: .. _py_vartype_constants:
@ -153,6 +153,6 @@ Classes representing internal objects
:members: :members:
:no-undoc-members: :no-undoc-members:
.. autoclass:: lammps.NumPyNeighList .. autoclass:: lammps.numpy::NumPyNeighList
:members: :members:
:no-undoc-members: :no-undoc-members:

10
doc/src/Python_overview.rst
View File

@ -2,9 +2,9 @@ Overview
======== ========
The LAMMPS distribution includes a ``python`` directory with the Python The LAMMPS distribution includes a ``python`` directory with the Python
code needed to run LAMMPS from Python. The ``python/lammps.py`` code needed to run LAMMPS from Python. The ``python/lammps`` package
contains :doc:`the "lammps" Python <Python_module>` that wraps the contains :doc:`the "lammps" Python module <Python_module>` that wraps the
LAMMPS C-library interface. This file makes it is possible to do the LAMMPS C-library interface. This module makes it is possible to do the
following either from a Python script, or interactively from a Python following either from a Python script, or interactively from a Python
prompt: prompt:
@ -20,8 +20,8 @@ have a version of Python that extends Python to enable multiple
instances of Python to read what you type. instances of Python to read what you type.
To do all of this, you must build LAMMPS in :ref:`"shared" mode <exe>` To do all of this, you must build LAMMPS in :ref:`"shared" mode <exe>`
and make certain that your Python interpreter can find the ``lammps.py`` and make certain that your Python interpreter can find the ``lammps``
file and the LAMMPS shared library file. Python package and the LAMMPS shared library file.
.. _ctypes: https://docs.python.org/3/library/ctypes.html .. _ctypes: https://docs.python.org/3/library/ctypes.html

2
doc/src/Python_trouble.rst
View File

@ -33,7 +33,7 @@ the constructor call as follows (see :ref:`python_create_lammps` for more detail
>>> lmp = lammps(name='mpi') >>> lmp = lammps(name='mpi')
You can also test the load directly in Python as follows, without You can also test the load directly in Python as follows, without
first importing from the lammps.py file: first importing from the ``lammps`` module:
.. code-block:: python .. code-block:: python

19
doc/src/Run_options.rst
View File

@ -62,15 +62,18 @@ used.
**-in file** **-in file**
Specify a file to use as an input script. This is an optional switch Specify a file to use as an input script. This is an optional but
when running LAMMPS in one-partition mode. If it is not specified, recommended switch when running LAMMPS in one-partition mode. If it
LAMMPS reads its script from standard input, typically from a script is not specified, LAMMPS reads its script from standard input, typically
via I/O redirection; e.g. lmp_linux < in.run. I/O redirection should from a script via I/O redirection; e.g. lmp_linux < in.run.
also work in parallel, but if it does not (in the unlikely case that With many MPI implementations I/O redirection also works in parallel,
an MPI implementation does not support it), then use the -in flag. but using the -in flag will always work.
Note that this is a required switch when running LAMMPS in Note that this is a required switch when running LAMMPS in
multi-partition mode, since multiple processors cannot all read from multi-partition mode, since multiple processors cannot all read from
stdin. stdin concurrently. The file name may be "none" for starting
multi-partition calculations without reading an initial input file
from the library interface.
---------- ----------
@ -296,7 +299,7 @@ command-line option.
**-pscreen file** **-pscreen file**
Specify the base name for the partition screen file, so partition N Specify the base name for the partition screen file, so partition N
writes screen information to file.N. If file is none, then no writes screen information to file.N. If file is "none", then no
partition screen files are created. This overrides the filename partition screen files are created. This overrides the filename
specified in the -screen command-line option. This option is useful specified in the -screen command-line option. This option is useful
when working with large numbers of partitions, allowing the partition when working with large numbers of partitions, allowing the partition

69
doc/src/angle_gaussian.rst Normal file
View File

@ -0,0 +1,69 @@
.. index:: angle_style gaussian
angle_style gaussian command
================================
Syntax
""""""
.. code-block:: LAMMPS
angle_style gaussian
Examples
""""""""
.. code-block:: LAMMPS
angle_style gaussian
angle_coeff 1 300.0 2 0.0128 0.375 80.0 0.0730 0.148 123.0
Description
"""""""""""
The *gaussian* angle style uses the potential:
.. math::
E = -k_B T ln\left(\sum_{i=1}^{n} \frac{A_i}{w_i \sqrt{\pi/2}} exp\left( \frac{-(\theta-\theta_{i})^2}{w_i^2})\right) \right)
This analytical form is a suitable potential for obtaining
mesoscale effective force fields which can reproduce target atomistic distributions :ref:`(Milano) <Milano1>`
The following coefficients must be defined for each angle type via the
:doc:`angle_coeff <angle_coeff>` command as in the example above, or in
the data file or restart files read by the :doc:`read_data <read_data>`
or :doc:`read_restart <read_restart>` commands:
* T temperature at which the potential was derived
* :math:`n` (integer >=1)
* :math:`A_1` (-)
* :math:`w_1` (-)
* :math:`\theta_1` (degrees)
* ...
* :math:`A_n` (-)
* :math:`w_n` (-)
* :math:`\theta_n` (degrees)
Restrictions
""""""""""""
This angle style can only be used if LAMMPS was built with the
USER-MISC package. See the :doc:`Build package <Build_package>` doc
page for more info.
Related commands
""""""""""""""""
:doc:`angle_coeff <angle_coeff>`
Default
"""""""
none
----------
.. _Milano1:
**(Milano)** G. Milano, S. Goudeau, F. Mueller-Plathe, J. Polym. Sci. B Polym. Phys. 43, 871 (2005).

1
doc/src/angle_style.rst
View File

@ -87,6 +87,7 @@ of (g,i,k,o,t) to indicate which accelerated styles exist.
* :doc:`dipole <angle_dipole>` - angle that controls orientation of a point dipole * :doc:`dipole <angle_dipole>` - angle that controls orientation of a point dipole
* :doc:`fourier <angle_fourier>` - angle with multiple cosine terms * :doc:`fourier <angle_fourier>` - angle with multiple cosine terms
* :doc:`fourier/simple <angle_fourier_simple>` - angle with a single cosine term * :doc:`fourier/simple <angle_fourier_simple>` - angle with a single cosine term
* :doc:`gaussian <angle_gaussian>` - multicentered Gaussian-based angle potential
* :doc:`harmonic <angle_harmonic>` - harmonic angle * :doc:`harmonic <angle_harmonic>` - harmonic angle
* :doc:`mm3 <angle_mm3>` - anharmonic angle * :doc:`mm3 <angle_mm3>` - anharmonic angle
* :doc:`quartic <angle_quartic>` - angle with cubic and quartic terms * :doc:`quartic <angle_quartic>` - angle with cubic and quartic terms

2
doc/src/atc_output.rst
View File

@ -14,7 +14,7 @@ Syntax
* AtC fixID = ID of :doc:`fix atc <fix_atc>` instance * AtC fixID = ID of :doc:`fix atc <fix_atc>` instance
* *output* or *output index* = name of the AtC sub-command * *output* or *output index* = name of the AtC sub-command
* filename_prefix = prefix for data files (for *output*) * filename_prefix = prefix for data files (for *output*)
* frequency = frequency of output in time-steps (for *output*) * frequency = frequency of output in timesteps (for *output*)
* optional keywords for *output*: * optional keywords for *output*:
- text = creates text output of index, step and nodal variable values for unique nodes - text = creates text output of index, step and nodal variable values for unique nodes

74
doc/src/balance.rst
View File

@ -78,14 +78,16 @@ or particles and thus indirectly the computational cost (load) more
evenly across processors. The load balancing is "static" in the sense evenly across processors. The load balancing is "static" in the sense
that this command performs the balancing once, before or between that this command performs the balancing once, before or between
simulations. The processor sub-domains will then remain static during simulations. The processor sub-domains will then remain static during
the subsequent run. To perform "dynamic" balancing, see the :doc:`fix balance <fix_balance>` command, which can adjust processor the subsequent run. To perform "dynamic" balancing, see the :doc:`fix
sub-domain sizes and shapes on-the-fly during a :doc:`run <run>`. balance <fix_balance>` command, which can adjust processor sub-domain
sizes and shapes on-the-fly during a :doc:`run <run>`.
Load-balancing is typically most useful if the particles in the Load-balancing is typically most useful if the particles in the
simulation box have a spatially-varying density distribution or when simulation box have a spatially-varying density distribution or when
the computational cost varies significantly between different the computational cost varies significantly between different
particles. E.g. a model of a vapor/liquid interface, or a solid with particles. E.g. a model of a vapor/liquid interface, or a solid with
an irregular-shaped geometry containing void regions, or :doc:`hybrid pair style simulations <pair_hybrid>` which combine pair styles with an irregular-shaped geometry containing void regions, or :doc:`hybrid
pair style simulations <pair_hybrid>` which combine pair styles with
different computational cost. In these cases, the LAMMPS default of different computational cost. In these cases, the LAMMPS default of
dividing the simulation box volume into a regular-spaced grid of 3d dividing the simulation box volume into a regular-spaced grid of 3d
bricks, with one equal-volume sub-domain per processor, may assign bricks, with one equal-volume sub-domain per processor, may assign
@ -101,13 +103,14 @@ which typically induces a different number of atoms assigned to each
processor. Details on the various weighting options and examples for processor. Details on the various weighting options and examples for
how they can be used are :ref:`given below <weighted_balance>`. how they can be used are :ref:`given below <weighted_balance>`.
Note that the :doc:`processors <processors>` command allows some control Note that the :doc:`processors <processors>` command allows some
over how the box volume is split across processors. Specifically, for control over how the box volume is split across processors.
a Px by Py by Pz grid of processors, it allows choice of Px, Py, and Specifically, for a Px by Py by Pz grid of processors, it allows
Pz, subject to the constraint that Px \* Py \* Pz = P, the total number choice of Px, Py, and Pz, subject to the constraint that Px \* Py \*
of processors. This is sufficient to achieve good load-balance for Pz = P, the total number of processors. This is sufficient to achieve
some problems on some processor counts. However, all the processor good load-balance for some problems on some processor counts.
sub-domains will still have the same shape and same volume. However, all the processor sub-domains will still have the same shape
and same volume.
The requested load-balancing operation is only performed if the The requested load-balancing operation is only performed if the
current "imbalance factor" in particles owned by each processor current "imbalance factor" in particles owned by each processor
@ -170,12 +173,12 @@ The method used to perform a load balance is specified by one of the
listed styles (or more in the case of *x*\ ,\ *y*\ ,\ *z*\ ), which are listed styles (or more in the case of *x*\ ,\ *y*\ ,\ *z*\ ), which are
described in detail below. There are 2 kinds of styles. described in detail below. There are 2 kinds of styles.
The *x*\ , *y*\ , *z*\ , and *shift* styles are "grid" methods which produce The *x*\ , *y*\ , *z*\ , and *shift* styles are "grid" methods which
a logical 3d grid of processors. They operate by changing the cutting produce a logical 3d grid of processors. They operate by changing the
planes (or lines) between processors in 3d (or 2d), to adjust the cutting planes (or lines) between processors in 3d (or 2d), to adjust
volume (area in 2d) assigned to each processor, as in the following 2d the volume (area in 2d) assigned to each processor, as in the
diagram where processor sub-domains are shown and particles are following 2d diagram where processor sub-domains are shown and
colored by the processor that owns them. particles are colored by the processor that owns them.
.. |balance1| image:: img/balance_uniform.jpg .. |balance1| image:: img/balance_uniform.jpg
:width: 32% :width: 32%
@ -190,20 +193,20 @@ colored by the processor that owns them.
The leftmost diagram is the default partitioning of the simulation box The leftmost diagram is the default partitioning of the simulation box
across processors (one sub-box for each of 16 processors); the middle across processors (one sub-box for each of 16 processors); the middle
diagram is after a "grid" method has been applied. The *rcb* style is a diagram is after a "grid" method has been applied. The *rcb* style is
"tiling" method which does not produce a logical 3d grid of processors. a "tiling" method which does not produce a logical 3d grid of
Rather it tiles the simulation domain with rectangular sub-boxes of processors. Rather it tiles the simulation domain with rectangular
varying size and shape in an irregular fashion so as to have equal sub-boxes of varying size and shape in an irregular fashion so as to
numbers of particles (or weight) in each sub-box, as in the rightmost have equal numbers of particles (or weight) in each sub-box, as in the
diagram above. rightmost diagram above.
The "grid" methods can be used with either of the The "grid" methods can be used with either of the :doc:`comm_style
:doc:`comm_style <comm_style>` command options, *brick* or *tiled*\ . The <comm_style>` command options, *brick* or *tiled*\ . The "tiling"
"tiling" methods can only be used with :doc:`comm_style tiled <comm_style>`. Note that it can be useful to use a "grid" methods can only be used with :doc:`comm_style tiled <comm_style>`.
method with :doc:`comm_style tiled <comm_style>` to return the domain Note that it can be useful to use a "grid" method with
partitioning to a logical 3d grid of processors so that "comm_style :doc:`comm_style tiled <comm_style>` to return the domain partitioning
brick" can afterwords be specified for subsequent :doc:`run <run>` to a logical 3d grid of processors so that "comm_style brick" can
commands. afterwords be specified for subsequent :doc:`run <run>` commands.
When a "grid" method is specified, the current domain partitioning can When a "grid" method is specified, the current domain partitioning can
be either a logical 3d grid or a tiled partitioning. In the former be either a logical 3d grid or a tiled partitioning. In the former
@ -280,6 +283,14 @@ information, so that they become closer together over time. Thus as
the recursion progresses, the count of particles on either side of the the recursion progresses, the count of particles on either side of the
plane gets closer to the target value. plane gets closer to the target value.
After the balanced plane positions are determined, if any pair of
adjacent planes are closer together than the neighbor skin distance
(as specified by the :doc`neigh_modify <neigh_modify>` command), then
the plane positions are shifted to separate them by at least this
amount. This is to prevent particles being lost when dynamics are run
with processor sub-domains that are too narrow in one or more
dimensions.
Once the re-balancing is complete and final processor sub-domains Once the re-balancing is complete and final processor sub-domains
assigned, particles are migrated to their new owning processor, and assigned, particles are migrated to their new owning processor, and
the balance procedure ends. the balance procedure ends.
@ -293,7 +304,7 @@ the balance procedure ends.
*Niter* is specified as 10, the cutting plane will typically be *Niter* is specified as 10, the cutting plane will typically be
positioned to 1 part in 1000 accuracy (relative to the perfect target positioned to 1 part in 1000 accuracy (relative to the perfect target
position). For *Niter* = 20, it will be accurate to 1 part in a position). For *Niter* = 20, it will be accurate to 1 part in a
million. Thus there is no need ot set *Niter* to a large value. million. Thus there is no need to set *Niter* to a large value.
LAMMPS will check if the threshold accuracy is reached (in a LAMMPS will check if the threshold accuracy is reached (in a
dimension) is less iterations than *Niter* and exit early. However, dimension) is less iterations than *Niter* and exit early. However,
*Niter* should also not be set too small, since it will take roughly *Niter* should also not be set too small, since it will take roughly
@ -416,7 +427,8 @@ The *time* weight style uses :doc:`timer data <timer>` to estimate
weights. It assigns the same weight to each particle owned by a weights. It assigns the same weight to each particle owned by a
processor based on the total computational time spent by that processor based on the total computational time spent by that
processor. See details below on what time window is used. It uses processor. See details below on what time window is used. It uses
the same timing information as is used for the :doc:`MPI task timing breakdown <Run_output>`, namely, for sections *Pair*\ , *Bond*\ , the same timing information as is used for the :doc:`MPI task timing
breakdown <Run_output>`, namely, for sections *Pair*\ , *Bond*\ ,
*Kspace*\ , and *Neigh*\ . The time spent in those portions of the *Kspace*\ , and *Neigh*\ . The time spent in those portions of the
timestep are measured for each MPI rank, summed, then divided by the timestep are measured for each MPI rank, summed, then divided by the
number of particles owned by that processor. I.e. the weight is an number of particles owned by that processor. I.e. the weight is an

70
doc/src/bond_gaussian.rst Normal file
View File

@ -0,0 +1,70 @@
.. index:: bond_style gaussian
bond_style gaussian command
================================
Syntax
""""""
.. code-block:: LAMMPS
bond_style gaussian
Examples
""""""""
.. code-block:: LAMMPS
bond_style gaussian
bond_coeff 1 300.0 2 0.0128 0.375 3.37 0.0730 0.148 3.63
Description
"""""""""""
The *gaussian* bond style uses the potential:
.. math::
E = -k_B T ln\left(\sum_{i=1}^{n} \frac{A_i}{w_i \sqrt{\pi/2}} exp\left( \frac{-(r-r_{i})^2}{w_i^2})\right) \right)
This analytical form is a suitable potential for obtaining
mesoscale effective force fields which can reproduce target atomistic distributions :ref:`(Milano) <Milano0>`
The following coefficients must be defined for each bond type via the
:doc:`bond_coeff <bond_coeff>` command as in the example above, or in
the data file or restart files read by the :doc:`read_data <read_data>`
or :doc:`read_restart <read_restart>` commands:
* T temperature at which the potential was derived
* :math:`n` (integer >=1)
* :math:`A_1` (-)
* :math:`w_1` (-)
* :math:`r_1` (length)
* ...
* :math:`A_n` (-)
* :math:`w_n` (-)
* :math:`r_n` (length)
Restrictions
""""""""""""
This bond style can only be used if LAMMPS was built with the
USER-MISC package. See the :doc:`Build package <Build_package>` doc
page for more info.
Related commands
""""""""""""""""
:doc:`bond_coeff <bond_coeff>`
Default
"""""""
none
----------
.. _Milano0:
**(Milano)** G. Milano, S. Goudeau, F. Mueller-Plathe, J. Polym. Sci. B Polym. Phys. 43, 871 (2005).

1
doc/src/bond_style.rst
View File

@ -87,6 +87,7 @@ accelerated styles exist.
* :doc:`class2 <bond_class2>` - COMPASS (class 2) bond * :doc:`class2 <bond_class2>` - COMPASS (class 2) bond
* :doc:`fene <bond_fene>` - FENE (finite-extensible non-linear elastic) bond * :doc:`fene <bond_fene>` - FENE (finite-extensible non-linear elastic) bond
* :doc:`fene/expand <bond_fene_expand>` - FENE bonds with variable size particles * :doc:`fene/expand <bond_fene_expand>` - FENE bonds with variable size particles
* :doc:`gaussian <bond_gaussian>` - multicentered Gaussian-based bond potential
* :doc:`gromos <bond_gromos>` - GROMOS force field bond * :doc:`gromos <bond_gromos>` - GROMOS force field bond
* :doc:`harmonic <bond_harmonic>` - harmonic bond * :doc:`harmonic <bond_harmonic>` - harmonic bond
* :doc:`harmonic/shift <bond_harmonic_shift>` - shifted harmonic bond * :doc:`harmonic/shift <bond_harmonic_shift>` - shifted harmonic bond

10
doc/src/change_box.rst
View File

@ -301,9 +301,13 @@ command.
.. note:: .. note::
Changing a periodic boundary to a non-periodic one will also Changing a periodic boundary to a non-periodic one will also cause
cause the image flag for that dimension to be reset to 0 for the image flag for that dimension of all atoms to be reset to 0.
all atoms. LAMMPS will print a warning message, if that happens. LAMMPS will print a warning message, if that happens.
Please note that this reset can lead to undesired changes when
atoms are involved in bonded interactions that straddle periodic
boundaries and thus the values of the image flag differs for those
atoms.
---------- ----------

6
doc/src/comm_modify.rst
View File

@ -84,13 +84,15 @@ information is available, then also a heuristic based on that bond length
is computed. It is used as communication cutoff, if there is no pair is computed. It is used as communication cutoff, if there is no pair
style present and no *comm_modify cutoff* command used. Otherwise a style present and no *comm_modify cutoff* command used. Otherwise a
warning is printed, if this bond based estimate is larger than the warning is printed, if this bond based estimate is larger than the
communication cutoff used. A communication cutoff used.
The *cutoff/multi* option is equivalent to *cutoff*\ , but applies to The *cutoff/multi* option is equivalent to *cutoff*\ , but applies to
communication mode *multi* instead. Since in this case the communication communication mode *multi* instead. Since in this case the communication
cutoffs are determined per atom type, a type specifier is needed and cutoffs are determined per atom type, a type specifier is needed and
cutoff for one or multiple types can be extended. Also ranges of types cutoff for one or multiple types can be extended. Also ranges of types
using the usual asterisk notation can be given. using the usual asterisk notation can be given. For granular pairstyles,
the default cutoff is set to the sum of the current maximum atomic radii
for each type.
These are simulation scenarios in which it may be useful or even These are simulation scenarios in which it may be useful or even
necessary to set a ghost cutoff > neighbor cutoff: necessary to set a ghost cutoff > neighbor cutoff:

2
doc/src/compute_reduce_chunk.rst
View File

@ -38,7 +38,7 @@ Description
Define a calculation that reduces one or more per-atom vectors into Define a calculation that reduces one or more per-atom vectors into
per-chunk values. This can be useful for diagnostic output. Or when per-chunk values. This can be useful for diagnostic output. Or when
used in conjunction with the :doc:`compute chunk/spread/atom <compute_chunk_spread_atom>` command it can be used in conjunction with the :doc:`compute chunk/spread/atom <compute_chunk_spread_atom>` command it can be
used ot create per-atom values that induce a new set of chunks with a used to create per-atom values that induce a new set of chunks with a
second :doc:`compute chunk/atom <compute_chunk_atom>` command. An second :doc:`compute chunk/atom <compute_chunk_atom>` command. An
example is given below. example is given below.

236
doc/src/compute_stress_atom.rst
View File

@ -33,32 +33,31 @@ Examples
Description Description
""""""""""" """""""""""
Define a computation that computes per-atom stress Define a computation that computes per-atom stress tensor for each
tensor for each atom in a group. In case of compute *stress/atom*, atom in a group. In case of compute *stress/atom*, the tensor for
the tensor for each atom is symmetric with 6 each atom is symmetric with 6 components and is stored as a 6-element
components and is stored as a 6-element vector in the following order: vector in the following order: :math:`xx`, :math:`yy`, :math:`zz`,
:math:`xx`, :math:`yy`, :math:`zz`, :math:`xy`, :math:`xz`, :math:`yz`. :math:`xy`, :math:`xz`, :math:`yz`. In case of compute
In case of compute *centroid/stress/atom*, *centroid/stress/atom*, the tensor for each atom is asymmetric with 9
the tensor for each atom is asymmetric with 9 components components and is stored as a 9-element vector in the following order:
and is stored as a 9-element vector in the following order: :math:`xx`, :math:`yy`, :math:`zz`, :math:`xy`, :math:`xz`,
:math:`xx`, :math:`yy`, :math:`zz`, :math:`xy`, :math:`xz`, :math:`yz`, :math:`yz`, :math:`yx`, :math:`zx`, :math:`zy`. See the :doc:`compute
:math:`yx`, :math:`zx`, :math:`zy`. pressure <compute_pressure>` command if you want the stress tensor
See the :doc:`compute pressure <compute_pressure>` command if you want the stress tensor
(pressure) of the entire system. (pressure) of the entire system.
The stress tensor for atom :math:`I` is given by the following formula, The stress tensor for atom :math:`I` is given by the following
where :math:`a` and :math:`b` take on values :math:`x`, :math:`y`, :math:`z` formula, where :math:`a` and :math:`b` take on values :math:`x`,
to generate the components of the tensor: :math:`y`, :math:`z` to generate the components of the tensor:
.. math:: .. math::
S_{ab} = - m v_a v_b - W_{ab} S_{ab} = - m v_a v_b - W_{ab}
The first term is a kinetic energy contribution for atom :math:`I`. See The first term is a kinetic energy contribution for atom :math:`I`.
details below on how the specified *temp-ID* can affect the velocities See details below on how the specified *temp-ID* can affect the
used in this calculation. The second term is the virial velocities used in this calculation. The second term is the virial
contribution due to intra and intermolecular interactions, contribution due to intra and intermolecular interactions, where the
where the exact computation details are determined by the compute style. exact computation details are determined by the compute style.
In case of compute *stress/atom*, the virial contribution is: In case of compute *stress/atom*, the virial contribution is:
@ -68,29 +67,26 @@ In case of compute *stress/atom*, the virial contribution is:
& + \frac{1}{3} \sum_{n = 1}^{N_a} (r_{1_a} F_{1_b} + r_{2_a} F_{2_b} + r_{3_a} F_{3_b}) + \frac{1}{4} \sum_{n = 1}^{N_d} (r_{1_a} F_{1_b} + r_{2_a} F_{2_b} + r_{3_a} F_{3_b} + r_{4_a} F_{4_b}) \\ & + \frac{1}{3} \sum_{n = 1}^{N_a} (r_{1_a} F_{1_b} + r_{2_a} F_{2_b} + r_{3_a} F_{3_b}) + \frac{1}{4} \sum_{n = 1}^{N_d} (r_{1_a} F_{1_b} + r_{2_a} F_{2_b} + r_{3_a} F_{3_b} + r_{4_a} F_{4_b}) \\
& + \frac{1}{4} \sum_{n = 1}^{N_i} (r_{1_a} F_{1_b} + r_{2_a} F_{2_b} + r_{3_a} F_{3_b} + r_{4_a} F_{4_b}) + {\rm Kspace}(r_{i_a},F_{i_b}) + \sum_{n = 1}^{N_f} r_{i_a} F_{i_b} & + \frac{1}{4} \sum_{n = 1}^{N_i} (r_{1_a} F_{1_b} + r_{2_a} F_{2_b} + r_{3_a} F_{3_b} + r_{4_a} F_{4_b}) + {\rm Kspace}(r_{i_a},F_{i_b}) + \sum_{n = 1}^{N_f} r_{i_a} F_{i_b}
The first term is a pairwise energy The first term is a pairwise energy contribution where :math:`n` loops
contribution where :math:`n` loops over the :math:`N_p` over the :math:`N_p` neighbors of atom :math:`I`, :math:`\mathbf{r}_1`
neighbors of atom :math:`I`, :math:`\mathbf{r}_1` and :math:`\mathbf{r}_2` and :math:`\mathbf{r}_2` are the positions of the 2 atoms in the
are the positions of the 2 atoms in the pairwise interaction, pairwise interaction, and :math:`\mathbf{F}_1` and
and :math:`\mathbf{F}_1` and :math:`\mathbf{F}_2` are the forces :math:`\mathbf{F}_2` are the forces on the 2 atoms resulting from the
on the 2 atoms resulting from the pairwise interaction. pairwise interaction. The second term is a bond contribution of
The second term is a bond contribution of similar form for the :math:`N_b` bonds which atom :math:`I` is part
similar form for the :math:`N_b` bonds which atom :math:`I` is part of. of. There are similar terms for the :math:`N_a` angle, :math:`N_d`
There are similar terms for the :math:`N_a` angle, :math:`N_d` dihedral, dihedral, and :math:`N_i` improper interactions atom :math:`I` is part
and :math:`N_i` improper interactions atom :math:`I` is part of. of. There is also a term for the KSpace contribution from long-range
There is also a term for the KSpace Coulombic interactions, if defined. Finally, there is a term for the
contribution from long-range Coulombic interactions, if defined. :math:`N_f` :doc:`fixes <fix>` that apply internal constraint forces
Finally, there is a term for the :math:`N_f` :doc:`fixes <fix>` that apply to atom :math:`I`. Currently, only the :doc:`fix shake <fix_shake>`
internal constraint forces to atom :math:`I`. Currently, only the and :doc:`fix rigid <fix_rigid>` commands contribute to this term. As
:doc:`fix shake <fix_shake>` and :doc:`fix rigid <fix_rigid>` commands the coefficients in the formula imply, a virial contribution produced
contribute to this term. by a small set of atoms (e.g. 4 atoms in a dihedral or 3 atoms in a
As the coefficients in the formula imply, a virial contribution Tersoff 3-body interaction) is assigned in equal portions to each atom
produced by a small set of atoms (e.g. 4 atoms in a dihedral or 3 in the set. E.g. 1/4 of the dihedral virial to each of the 4 atoms,
atoms in a Tersoff 3-body interaction) is assigned in equal portions or 1/3 of the fix virial due to SHAKE constraints applied to atoms in
to each atom in the set. E.g. 1/4 of the dihedral virial to each of a water molecule via the :doc:`fix shake <fix_shake>` command.
the 4 atoms, or 1/3 of the fix virial due to SHAKE constraints applied
to atoms in a water molecule via the :doc:`fix shake <fix_shake>`
command.
In case of compute *centroid/stress/atom*, the virial contribution is: In case of compute *centroid/stress/atom*, the virial contribution is:
@ -99,71 +95,69 @@ In case of compute *centroid/stress/atom*, the virial contribution is:
W_{ab} & = \sum_{n = 1}^{N_p} r_{I0_a} F_{I_b} + \sum_{n = 1}^{N_b} r_{I0_a} F_{I_b} + \sum_{n = 1}^{N_a} r_{I0_a} F_{I_b} + \sum_{n = 1}^{N_d} r_{I0_a} F_{I_b} + \sum_{n = 1}^{N_i} r_{I0_a} F_{I_b} \\ W_{ab} & = \sum_{n = 1}^{N_p} r_{I0_a} F_{I_b} + \sum_{n = 1}^{N_b} r_{I0_a} F_{I_b} + \sum_{n = 1}^{N_a} r_{I0_a} F_{I_b} + \sum_{n = 1}^{N_d} r_{I0_a} F_{I_b} + \sum_{n = 1}^{N_i} r_{I0_a} F_{I_b} \\
& + {\rm Kspace}(r_{i_a},F_{i_b}) + \sum_{n = 1}^{N_f} r_{i_a} F_{i_b} & + {\rm Kspace}(r_{i_a},F_{i_b}) + \sum_{n = 1}^{N_f} r_{i_a} F_{i_b}
As with compute *stress/atom*, the first, second, third, fourth and fifth terms As with compute *stress/atom*, the first, second, third, fourth and
are pairwise, bond, angle, dihedral and improper contributions, fifth terms are pairwise, bond, angle, dihedral and improper
but instead of assigning the virial contribution equally to each atom, contributions, but instead of assigning the virial contribution
only the force :math:`\mathbf{F}_I` acting on atom :math:`I` equally to each atom, only the force :math:`\mathbf{F}_I` acting on
due to the interaction and the relative atom :math:`I` due to the interaction and the relative position
position :math:`\mathbf{r}_{I0}` of the atom :math:`I` to the geometric center :math:`\mathbf{r}_{I0}` of the atom :math:`I` to the geometric center
of the interacting atoms, i.e. centroid, is used. of the interacting atoms, i.e. centroid, is used. As the geometric
As the geometric center is different center is different for each interaction, the :math:`\mathbf{r}_{I0}`
for each interaction, the :math:`\mathbf{r}_{I0}` also differs. also differs. The sixth and seventh terms, Kspace and :doc:`fix
The sixth and seventh terms, Kspace and :doc:`fix <fix>` contribution <fix>` contribution respectively, are computed identical to compute
respectively, are computed identical to compute *stress/atom*. *stress/atom*. Although the total system virial is the same as
Although the total system virial is the same as compute *stress/atom*, compute *stress/atom*, compute *centroid/stress/atom* is know to
compute *centroid/stress/atom* is know to result in more consistent result in more consistent heat flux values for angle, dihedrals and
heat flux values for angle, dihedrals and improper contributions improper contributions when computed via :doc:`compute heat/flux
when computed via :doc:`compute heat/flux <compute_heat_flux>`. <compute_heat_flux>`.
If no extra keywords are listed, the kinetic contribution If no extra keywords are listed, the kinetic contribution all of the
all of the virial contribution terms are virial contribution terms are included in the per-atom stress tensor.
included in the per-atom stress tensor. If any extra keywords are If any extra keywords are listed, only those terms are summed to
listed, only those terms are summed to compute the tensor. The compute the tensor. The *virial* keyword means include all terms
*virial* keyword means include all terms except the kinetic energy except the kinetic energy *ke*\ .
*ke*\ .
Note that the stress for each atom is due to its interaction with all 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. other atoms in the simulation, not just with other atoms in the group.
Details of how compute *stress/atom* obtains the virial for individual atoms for Details of how compute *stress/atom* obtains the virial for individual
either pairwise or many-body potentials, and including the effects of atoms for either pairwise or many-body potentials, and including the
periodic boundary conditions is discussed in :ref:`(Thompson) <Thompson2>`. effects of periodic boundary conditions is discussed in
The basic idea for many-body potentials is to treat each component of :ref:`(Thompson) <Thompson2>`. The basic idea for many-body
the force computation between a small cluster of atoms in the same potentials is to treat each component of the force computation between
manner as in the formula above for bond, angle, dihedral, etc a small cluster of atoms in the same manner as in the formula above
interactions. Namely the quantity :math:`\mathbf{r} \cdot \mathbf{F}` for bond, angle, dihedral, etc interactions. Namely the quantity
is summed over the atoms in :math:`\mathbf{r} \cdot \mathbf{F}` is summed over the atoms in the
the interaction, with the :math:`r` vectors unwrapped by periodic boundaries interaction, with the :math:`r` vectors unwrapped by periodic
so that the cluster of atoms is close together. The total boundaries so that the cluster of atoms is close together. The total
contribution for the cluster interaction is divided evenly among those contribution for the cluster interaction is divided evenly among those
atoms. Details of how compute *centroid/stress/atom* obtains atoms.
the virial for individual atoms
is given in :ref:`(Surblys) <Surblys1>`, Details of how compute *centroid/stress/atom* obtains the virial for
where the idea is that the virial of the atom :math:`I` individual atoms is given in :ref:`(Surblys) <Surblys1>`, where the
is the result of only the force :math:`\mathbf{F}_I` on the atom due idea is that the virial of the atom :math:`I` is the result of only
to the interaction the force :math:`\mathbf{F}_I` on the atom due to the interaction and
and its positional vector :math:`\mathbf{r}_{I0}`, its positional vector :math:`\mathbf{r}_{I0}`, relative to the
relative to the geometric center of the geometric center of the interacting atoms, regardless of the number of
interacting atoms, regardless of the number of participating atoms. participating atoms. The periodic boundary treatment is identical to
The periodic boundary treatment is identical to
that of compute *stress/atom*, and both of them reduce to identical that of compute *stress/atom*, and both of them reduce to identical
expressions for two-body interactions, expressions for two-body interactions, i.e. computed values for
i.e. computed values for contributions from bonds and two-body pair styles, contributions from bonds and two-body pair styles, such as
such as :doc:`Lennard-Jones <pair_lj>`, will be the same, :doc:`Lennard-Jones <pair_lj>`, will be the same, while contributions
while contributions from angles, dihedrals and impropers will be different. from angles, dihedrals and impropers will be different.
The :doc:`dihedral_style charmm <dihedral_charmm>` style calculates The :doc:`dihedral_style charmm <dihedral_charmm>` style calculates
pairwise interactions between 1-4 atoms. The virial contribution of pairwise interactions between 1-4 atoms. The virial contribution of
these terms is included in the pair virial, not the dihedral virial. these terms is included in the pair virial, not the dihedral virial.
The KSpace contribution is calculated using the method in The KSpace contribution is calculated using the method in
:ref:`(Heyes) <Heyes2>` for the Ewald method and by the methodology described :ref:`(Heyes) <Heyes2>` for the Ewald method and by the methodology
in :ref:`(Sirk) <Sirk1>` for PPPM. The choice of KSpace solver is specified described in :ref:`(Sirk) <Sirk1>` for PPPM. The choice of KSpace
by the :doc:`kspace_style pppm <kspace_style>` command. Note that for solver is specified by the :doc:`kspace_style pppm <kspace_style>`
PPPM, the calculation requires 6 extra FFTs each timestep that command. Note that for PPPM, the calculation requires 6 extra FFTs
per-atom stress is calculated. Thus it can significantly increase the each timestep that per-atom stress is calculated. Thus it can
cost of the PPPM calculation if it is needed on a large fraction of significantly increase the cost of the PPPM calculation if it is
the simulation timesteps. needed on a large fraction of the simulation timesteps.
The *temp-ID* argument can be used to affect the per-atom velocities The *temp-ID* argument can be used to affect the per-atom velocities
used in the kinetic energy contribution to the total stress. If the used in the kinetic energy contribution to the total stress. If the
@ -189,10 +183,10 @@ See the :doc:`compute voronoi/atom <compute_voronoi_atom>` command for
one possible way to estimate a per-atom volume. one possible way to estimate a per-atom volume.
Thus, if the diagonal components of the per-atom stress tensor are Thus, if the diagonal components of the per-atom stress tensor are
summed for all atoms in the system and the sum is divided by :math:`dV`, where summed for all atoms in the system and the sum is divided by
:math:`d` = dimension and :math:`V` is the volume of the system, :math:`dV`, where :math:`d` = dimension and :math:`V` is the volume of
the result should be :math:`-P`, where :math:`P` the system, the result should be :math:`-P`, where :math:`P` is the
is the total pressure of the system. total pressure of the system.
These lines in an input script for a 3d system should yield that These lines in an input script for a 3d system should yield that
result. I.e. the last 2 columns of thermo output will be the same: result. I.e. the last 2 columns of thermo output will be the same:
@ -207,33 +201,43 @@ result. I.e. the last 2 columns of thermo output will be the same:
.. note:: .. note::
The per-atom stress does not include any Lennard-Jones tail The per-atom stress does not include any Lennard-Jones tail
corrections to the pressure added by the :doc:`pair_modify tail yes <pair_modify>` command, since those are contributions to the corrections to the pressure added by the :doc:`pair_modify tail yes
global system pressure. <pair_modify>` command, since those are contributions to the global
system pressure.
Output info Output info
""""""""""" """""""""""
This compute *stress/atom* calculates a per-atom array with 6 columns, which can be Compute *stress/atom* calculates a per-atom array with 6 columns,
accessed by indices 1-6 by any command that uses per-atom values from which can be accessed by indices 1-6 by any command that uses per-atom
a compute as input. values from a compute as input. Compute *centroid/stress/atom*
The compute *centroid/stress/atom* produces a per-atom array with 9 columns, produces a per-atom array with 9 columns, but otherwise can be used in
but otherwise can be used in an identical manner to compute *stress/atom*. an identical manner to compute *stress/atom*. See the :doc:`Howto
See the :doc:`Howto output <Howto_output>` doc page output <Howto_output>` doc page for an overview of LAMMPS output
for an overview of LAMMPS output options. options.
The per-atom array values will be in pressure\*volume The per-atom array values will be in pressure\*volume :doc:`units
:doc:`units <units>` as discussed above. <units>` as discussed above.
Restrictions Restrictions
"""""""""""" """"""""""""
Currently (Spring 2020), compute *centroid/stress/atom* does not support Currently, compute *centroid/stress/atom* does not support pair styles
pair styles with many-body interactions, such as :doc:`Tersoff with many-body interactions (:doc:`EAM <pair_eam>` is an exception,
<pair_tersoff>`, or pair styles with long-range Coulomb interactions. since its computations are performed pairwise), nor granular pair
LAMMPS will generate an error in such cases. In principal, equivalent styles with pairwise forces which are not aligned with the vector
formulation to that of angle, dihedral and improper contributions in the between the pair of particles. All bond styles are supported. All
virial :math:`W_{ab}` formula can also be applied to the many-body pair angle, dihedral, improper styles are supported with the exception of
styles, and is planned in the future. USER-INTEL and KOKKOS variants of specific styles. It also does not
support models with long-range Coulombic or dispersion forces,
i.e. the kspace_style command in LAMMPS. It also does not support the
following fixes which add rigid-body constraints: :doc:`fix shake
<fix_shake>`, :doc:`fix rattle <fix_shake>`, :doc:`fix rigid
<fix_rigid>`, :doc:`fix rigid/small <fix_rigid>`.
LAMMPS will generate an error if one of these options is included in
your model. Extension of centroid stress calculations to these force
and fix styles is planned for the future.
Related commands Related commands
"""""""""""""""" """"""""""""""""

1
doc/src/fix.rst
View File

@ -205,6 +205,7 @@ accelerated styles exist.
* :doc:`efield <fix_efield>` - impose electric field on system * :doc:`efield <fix_efield>` - impose electric field on system
* :doc:`ehex <fix_ehex>` - enhanced heat exchange algorithm * :doc:`ehex <fix_ehex>` - enhanced heat exchange algorithm
* :doc:`electron/stopping <fix_electron_stopping>` - electronic stopping power as a friction force * :doc:`electron/stopping <fix_electron_stopping>` - electronic stopping power as a friction force
* :doc:`electron/stopping/fit <fix_electron_stopping>` - electronic stopping power as a friction force
* :doc:`enforce2d <fix_enforce2d>` - zero out z-dimension velocity and force * :doc:`enforce2d <fix_enforce2d>` - zero out z-dimension velocity and force
* :doc:`eos/cv <fix_eos_cv>` - * :doc:`eos/cv <fix_eos_cv>` -
* :doc:`eos/table <fix_eos_table>` - * :doc:`eos/table <fix_eos_table>` -

118
doc/src/fix_bond_react.rst
View File

@ -35,8 +35,8 @@ Syntax
* react-ID = user-assigned name for the reaction * react-ID = user-assigned name for the reaction
* react-group-ID = only atoms in this group are considered for the reaction * react-group-ID = only atoms in this group are considered for the reaction
* Nevery = attempt reaction every this many steps * Nevery = attempt reaction every this many steps
* Rmin = bonding pair atoms must be separated by more than Rmin to initiate reaction (distance units) * Rmin = initiator atoms must be separated by more than Rmin to initiate reaction (distance units)
* Rmax = bonding pair atoms must be separated by less than Rmax to initiate reaction (distance units) * Rmax = initiator atoms must be separated by less than Rmax to initiate reaction (distance units)
* template-ID(pre-reacted) = ID of a molecule template containing pre-reaction topology * template-ID(pre-reacted) = ID of a molecule template containing pre-reaction topology
* template-ID(post-reacted) = ID of a molecule template containing post-reaction topology * template-ID(post-reacted) = ID of a molecule template containing post-reaction topology
* map_file = name of file specifying corresponding atom-IDs in the pre- and post-reacted templates * map_file = name of file specifying corresponding atom-IDs in the pre- and post-reacted templates
@ -55,6 +55,10 @@ Syntax
*custom_charges* value = *no* or *fragmentID* *custom_charges* value = *no* or *fragmentID*
no = update all atomic charges (default) no = update all atomic charges (default)
fragmentID = ID of molecule fragment whose charges are updated fragmentID = ID of molecule fragment whose charges are updated
*molecule* value = *off* or *inter* or *intra*
off = allow both inter- and intramolecular reactions (default)
inter = search for reactions between molecules with different IDs
intra = search for reactions within the same molecule
Examples Examples
"""""""" """"""""
@ -172,8 +176,8 @@ timesteps. *Nevery* can be specified with an equal-style
integer. integer.
Three physical conditions must be met for a reaction to occur. First, Three physical conditions must be met for a reaction to occur. First,
a bonding atom pair must be identified within the reaction distance an initiator atom pair must be identified within the reaction distance
cutoffs. Second, the topology surrounding the bonding atom pair must cutoffs. Second, the topology surrounding the initiator atom pair must
match the topology of the pre-reaction template. Only atom types and match the topology of the pre-reaction template. Only atom types and
bond connectivity are used to identify a valid reaction site (not bond bond connectivity are used to identify a valid reaction site (not bond
types, etc.). Finally, any reaction constraints listed in the map file types, etc.). Finally, any reaction constraints listed in the map file
@ -181,10 +185,10 @@ types, etc.). Finally, any reaction constraints listed in the map file
reaction site is eligible to be modified to match the post-reaction reaction site is eligible to be modified to match the post-reaction
template. template.
A bonding atom pair will be identified if several conditions are met. An initiator atom pair will be identified if several conditions are
First, a pair of atoms I,J within the specified react-group-ID of type met. First, a pair of atoms I,J within the specified react-group-ID of
itype and jtype must be separated by a distance between *Rmin* and type itype and jtype must be separated by a distance between *Rmin*
*Rmax*\ . *Rmin* and *Rmax* can be specified with equal-style and *Rmax*\ . *Rmin* and *Rmax* can be specified with equal-style
:doc:`variables <variable>`. For example, these reaction cutoffs can :doc:`variables <variable>`. For example, these reaction cutoffs can
be a function of the reaction conversion using the following commands: be a function of the reaction conversion using the following commands:
@ -194,20 +198,20 @@ be a function of the reaction conversion using the following commands:
fix myrxn all bond/react react myrxn1 all 1 0 v_rmax mol1 mol2 map_file.txt fix myrxn all bond/react react myrxn1 all 1 0 v_rmax mol1 mol2 map_file.txt
variable rmax equal 3+f_myrxn[1]/100 # arbitrary function of reaction count variable rmax equal 3+f_myrxn[1]/100 # arbitrary function of reaction count
The following criteria are used if multiple candidate bonding atom The following criteria are used if multiple candidate initiator atom
pairs are identified within the cutoff distance: 1) If the bonding pairs are identified within the cutoff distance: 1) If the initiator
atoms in the pre-reaction template are not 1-2 neighbors (i.e. not atoms in the pre-reaction template are not 1-2 neighbors (i.e. not
directly bonded) the closest potential partner is chosen. 2) directly bonded) the closest potential partner is chosen. 2)
Otherwise, if the bonding atoms in the pre-reaction template are 1-2 Otherwise, if the initiator atoms in the pre-reaction template are 1-2
neighbors (i.e. directly bonded) the farthest potential partner is neighbors (i.e. directly bonded) the farthest potential partner is
chosen. 3) Then, if both an atom I and atom J have each other as their chosen. 3) Then, if both an atom I and atom J have each other as their
bonding partners, these two atoms are identified as the bonding atom initiator partners, these two atoms are identified as the initiator
pair of the reaction site. Note that it can be helpful to select atom pair of the reaction site. Note that it can be helpful to select
unique atom types for the bonding atoms: if a bonding atom pair is unique atom types for the initiator atoms: if an initiator atom pair
identified, as described in the previous steps, but does not is identified, as described in the previous steps, but does not
correspond to the same pair specified in the pre-reaction template, an correspond to the same pair specified in the pre-reaction template, an
otherwise eligible reaction could be prevented from occurring. Once otherwise eligible reaction could be prevented from occurring. Once
this unique bonding atom pair is identified for each reaction, there this unique initiator atom pair is identified for each reaction, there
could be two or more reactions that involve the same atom on the same could be two or more reactions that involve the same atom on the same
timestep. If this is the case, only one such reaction is permitted to timestep. If this is the case, only one such reaction is permitted to
occur. This reaction is chosen randomly from all potential reactions occur. This reaction is chosen randomly from all potential reactions
@ -217,7 +221,7 @@ with user-specified probabilities.
The pre-reacted molecule template is specified by a molecule command. The pre-reacted molecule template is specified by a molecule command.
This molecule template file contains a sample reaction site and its This molecule template file contains a sample reaction site and its
surrounding topology. As described below, the bonding atom pairs of surrounding topology. As described below, the initiator atom pairs of
the pre-reacted template are specified by atom ID in the map file. The the pre-reacted template are specified by atom ID in the map file. The
pre-reacted molecule template should contain as few atoms as possible pre-reacted molecule template should contain as few atoms as possible
while still completely describing the topology of all atoms affected while still completely describing the topology of all atoms affected
@ -231,18 +235,18 @@ missing topology with respect to the simulation. For example, the
pre-reacted template may contain an atom that, in the simulation, is pre-reacted template may contain an atom that, in the simulation, is
currently connected to the rest of a long polymer chain. These are currently connected to the rest of a long polymer chain. These are
referred to as edge atoms, and are also specified in the map file. All referred to as edge atoms, and are also specified in the map file. All
pre-reaction template atoms should be linked to a bonding atom, via at pre-reaction template atoms should be linked to an initiator atom, via
least one path that does not involve edge atoms. When the pre-reaction at least one path that does not involve edge atoms. When the
template contains edge atoms, not all atoms, bonds, charges, etc. pre-reaction template contains edge atoms, not all atoms, bonds,
specified in the reaction templates will be updated. Specifically, charges, etc. specified in the reaction templates will be updated.
topology that involves only atoms that are 'too near' to template Specifically, topology that involves only atoms that are 'too near' to
edges will not be updated. The definition of 'too near the edge' template edges will not be updated. The definition of 'too near the
depends on which interactions are defined in the simulation. If the edge' depends on which interactions are defined in the simulation. If
simulation has defined dihedrals, atoms within two bonds of edge atoms the simulation has defined dihedrals, atoms within two bonds of edge
are considered 'too near the edge.' If the simulation defines angles, atoms are considered 'too near the edge.' If the simulation defines
but not dihedrals, atoms within one bond of edge atoms are considered angles, but not dihedrals, atoms within one bond of edge atoms are
'too near the edge.' If just bonds are defined, only edge atoms are considered 'too near the edge.' If just bonds are defined, only edge
considered 'too near the edge.' atoms are considered 'too near the edge.'
.. note:: .. note::
@ -298,23 +302,23 @@ The optional keywords are 'edgeIDs', 'deleteIDs', 'chiralIDs' and
The body of the map file contains two mandatory sections and four The body of the map file contains two mandatory sections and four
optional sections. The first mandatory section begins with the keyword optional sections. The first mandatory section begins with the keyword
'BondingIDs' and lists the atom IDs of the bonding atom pair in the 'InitiatorIDs' and lists the two atom IDs of the initiator atom pair
pre-reacted molecule template. The second mandatory section begins in the pre-reacted molecule template. The second mandatory section
with the keyword 'Equivalences' and lists a one-to-one correspondence begins with the keyword 'Equivalences' and lists a one-to-one
between atom IDs of the pre- and post-reacted templates. The first correspondence between atom IDs of the pre- and post-reacted
column is an atom ID of the pre-reacted molecule template, and the templates. The first column is an atom ID of the pre-reacted molecule
second column is the corresponding atom ID of the post-reacted template, and the second column is the corresponding atom ID of the
molecule template. The first optional section begins with the keyword post-reacted molecule template. The first optional section begins with
'EdgeIDs' and lists the atom IDs of edge atoms in the pre-reacted the keyword 'EdgeIDs' and lists the atom IDs of edge atoms in the
molecule template. The second optional section begins with the keyword pre-reacted molecule template. The second optional section begins with
'DeleteIDs' and lists the atom IDs of pre-reaction template atoms to the keyword 'DeleteIDs' and lists the atom IDs of pre-reaction
delete. The third optional section begins with the keyword 'ChiralIDs' template atoms to delete. The third optional section begins with the
lists the atom IDs of chiral atoms whose handedness should be keyword 'ChiralIDs' lists the atom IDs of chiral atoms whose
enforced. The fourth optional section begins with the keyword handedness should be enforced. The fourth optional section begins with
'Constraints' and lists additional criteria that must be satisfied in the keyword 'Constraints' and lists additional criteria that must be
order for the reaction to occur. Currently, there are five types of satisfied in order for the reaction to occur. Currently, there are
constraints available, as discussed below: 'distance', 'angle', five types of constraints available, as discussed below: 'distance',
'dihedral', 'arrhenius', and 'rmsd'. 'angle', 'dihedral', 'arrhenius', and 'rmsd'.
A sample map file is given below: A sample map file is given below:
@ -327,7 +331,7 @@ A sample map file is given below:
7 equivalences 7 equivalences
2 edgeIDs 2 edgeIDs
BondingIDs InitiatorIDs
3 3
5 5
@ -462,7 +466,7 @@ A few capabilities to note: 1) You may specify as many *react*
arguments as desired. For example, you could break down a complicated arguments as desired. For example, you could break down a complicated
reaction mechanism into several reaction steps, each defined by its reaction mechanism into several reaction steps, each defined by its
own *react* argument. 2) While typically a bond is formed or removed own *react* argument. 2) While typically a bond is formed or removed
between the bonding atom pairs specified in the pre-reacted molecule between the initiator atoms specified in the pre-reacted molecule
template, this is not required. 3) By reversing the order of the pre- template, this is not required. 3) By reversing the order of the pre-
and post- reacted molecule templates in another *react* argument, you and post- reacted molecule templates in another *react* argument, you
can allow for the possibility of one or more reverse reactions. can allow for the possibility of one or more reverse reactions.
@ -491,12 +495,20 @@ situations, decreasing rather than increasing this parameter will
result in an increase in stability. result in an increase in stability.
The *custom_charges* keyword can be used to specify which atoms' The *custom_charges* keyword can be used to specify which atoms'
atomic charges are updated. When the value is set to 'no,' all atomic atomic charges are updated. When the value is set to 'no', all atomic
charges are updated to those specified by the post-reaction template charges are updated to those specified by the post-reaction template
(default). Otherwise, the value should be the name of a molecule (default). Otherwise, the value should be the name of a molecule
fragment defined in the pre-reaction molecule template. In this case, fragment defined in the pre-reaction molecule template. In this case,
only the atomic charges of atoms in the molecule fragment are updated. only the atomic charges of atoms in the molecule fragment are updated.
The *molecule* keyword can be used to force the reaction to be
intermolecular, intramolecular or either. When the value is set to
'off', molecule IDs are not considered when searching for reactions
(default). When the value is set to 'inter', the initiator atoms must
have different molecule IDs in order to be considered for the
reaction. When the value is set to 'intra', only initiator atoms with
the same molecule ID are considered for the reaction.
A few other considerations: A few other considerations:
Many reactions result in one or more atoms that are considered Many reactions result in one or more atoms that are considered
@ -558,7 +570,7 @@ These is 1 quantity for each react argument:
No parameter of this fix can be used with the *start/stop* keywords 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>`. of the :doc:`run <run>` command. This fix is not invoked during :doc:`energy minimization <minimize>`.
When fix bond/react is 'unfixed,' all internally-created groups are When fix bond/react is 'unfixed', all internally-created groups are
deleted. Therefore, fix bond/react can only be unfixed after unfixing deleted. Therefore, fix bond/react can only be unfixed after unfixing
all other fixes that use any group created by fix bond/react. all other fixes that use any group created by fix bond/react.
@ -581,10 +593,14 @@ Default
""""""" """""""
The option defaults are stabilization = no, prob = 1.0, stabilize_steps = 60, The option defaults are stabilization = no, prob = 1.0, stabilize_steps = 60,
reset_mol_ids = yes, custom_charges = no reset_mol_ids = yes, custom_charges = no, molecule = off
---------- ----------
.. _Gissinger: .. _Gissinger:
**(Gissinger)** Gissinger, Jensen and Wise, Polymer, 128, 211 (2017). **(Gissinger)** Gissinger, Jensen and Wise, Polymer, 128, 211 (2017).
.. _Gissinger2020:
**(Gissinger)** Gissinger, Jensen and Wise, Macromolecules (2020, in press).

50
doc/src/fix_electron_stopping.rst
View File

@ -1,26 +1,39 @@
.. index:: fix electron/stopping .. index:: fix electron/stopping
.. index:: fix electron/stopping/fit
fix electron/stopping command fix electron/stopping command
============================= =============================
fix electron/stopping/fit command
=================================
Syntax Syntax
"""""" """"""
.. parsed-literal:: .. parsed-literal::
fix ID group-ID electron/stopping Ecut file keyword value ... fix ID group-ID style args
* ID, group-ID are documented in :doc:`fix <fix>` command * ID, group-ID are documented in :doc:`fix <fix>` command
* electron/stopping = style name of this fix command * style = *electron/stopping* or *electron/stopping/fit*
* Ecut = minimum kinetic energy for electronic stopping (energy units)
* file = name of the file containing the electronic stopping power table
* zero or more keyword/value pairs may be appended to args
* keyword = *region* or *minneigh*
.. parsed-literal:: .. parsed-literal::
*electron/stopping* args = Ecut file keyword value ...
Ecut = minimum kinetic energy for electronic stopping (energy units)
file = name of the file containing the electronic stopping power table
*electron/stopping/fit* args = Ecut c1 c2 ...
Ecut = minimum kinetic energy for electronic stopping (energy units)
c1 c2 = linear and quadratic coefficients for the fitted quadratic polynomial
* zero or more keyword/value pairs may be appended to args for style = *electron/stopping*
.. parsed-literal::
keyword = *region* or *minneigh*
*region* value = region-ID *region* value = region-ID
region-ID = region, whose atoms will be affected by this fix region-ID = region whose atoms will be affected by this fix
*minneigh* value = minneigh *minneigh* value = minneigh
minneigh = minimum number of neighbors an atom to have stopping applied minneigh = minimum number of neighbors an atom to have stopping applied
@ -32,6 +45,8 @@ Examples
fix el all electron/stopping 10.0 elstop-table.txt fix el all electron/stopping 10.0 elstop-table.txt
fix el all electron/stopping 10.0 elstop-table.txt minneigh 3 fix el all electron/stopping 10.0 elstop-table.txt minneigh 3
fix el mygroup electron/stopping 1.0 elstop-table.txt region bulk fix el mygroup electron/stopping 1.0 elstop-table.txt region bulk
fix 1 all electron/stopping/fit 4.63 3.3e-3 4.0e-8
fix 1 all electron/stopping/fit 3.49 1.8e-3 9.0e-8 7.57 4.2e-3 5.0e-8
Description Description
""""""""""" """""""""""
@ -129,6 +144,19 @@ scientific publications, experimental databases or by using
of the impact parameter of the ion; these results can be used of the impact parameter of the ion; these results can be used
to derive the stopping power. to derive the stopping power.
----------
Style *electron/stopping/fit* calculates the electronic stopping power
and cumulative energy lost to the electron gas via a quadratic functional
and applies a drag force to the classical equations-of-motion for all
atoms moving above some minimum cutoff velocity (i.e., kinetic energy).
These coefficients can be determined by fitting a quadratic polynomial to
electronic stopping data predicted by, for example, SRIM or TD-DFT. Multiple
'Ecut c1 c2' values can be provided for multi-species simulations in the order
of the atom types. There is an examples/USER/misc/electron_stopping/ directory,
which illustrates uses of this command. Details of this implementation are
further described in :ref:`Stewart2018 <Stewart2018>` and :ref:`Lee2020 <Lee2020>`.
Restart, fix_modify, output, run start/stop, minimize info Restart, fix_modify, output, run start/stop, minimize info
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
@ -181,3 +209,11 @@ The default is no limitation by region, and minneigh = 1.
.. _PASS: .. _PASS:
**(PASS)** PASS webpage: https://www.sdu.dk/en/DPASS **(PASS)** PASS webpage: https://www.sdu.dk/en/DPASS
.. _Stewart2018:
**(Stewart2018)** J.A. Stewart, et al. (2018) Journal of Applied Physics, 123(16), 165902.
.. _Lee2020:
**(Lee2020)** C.W. Lee, et al. (2020) Physical Review B, 102(2), 024107.

2
doc/src/fix_filter_corotate.rst
View File

@ -56,7 +56,7 @@ is slightly modified only for the computation of long-range forces. A
good cluster decomposition constitutes in building clusters which good cluster decomposition constitutes in building clusters which
contain the fastest covalent bonds inside clusters. contain the fastest covalent bonds inside clusters.
If the clusters are chosen suitably, the :doc:`run_style respa <run_style>` is stable for outer time-steps of at least 8fs. If the clusters are chosen suitably, the :doc:`run_style respa <run_style>` is stable for outer timesteps of at least 8fs.
---------- ----------

2
doc/src/fix_phonon.rst
View File

@ -121,7 +121,7 @@ A detailed description of this method can be found in
The *sysdim* keyword is optional. If specified with a value smaller The *sysdim* keyword is optional. If specified with a value smaller
than the dimensionality of the LAMMPS simulation, its value is used than the dimensionality of the LAMMPS simulation, its value is used
for the dynamical matrix calculation. For example, using LAMMPS ot for the dynamical matrix calculation. For example, using LAMMPS to
model a 2D or 3D system, the phonon dispersion of a 1D atomic chain model a 2D or 3D system, the phonon dispersion of a 1D atomic chain
can be computed using *sysdim* = 1. can be computed using *sysdim* = 1.

2
doc/src/fix_precession_spin.rst
View File

@ -62,7 +62,7 @@ with:
The field value in Tesla is multiplied by the gyromagnetic The field value in Tesla is multiplied by the gyromagnetic
ratio, :math:`g \cdot \mu_B/\hbar`, converting it into a precession frequency in ratio, :math:`g \cdot \mu_B/\hbar`, converting it into a precession frequency in
rad.THz (in metal units and with :math:`\mu_B = 5.788 eV/T`). rad.THz (in metal units and with :math:`\mu_B = 5.788\cdot 10^{-5}` eV/T).
As a comparison, the figure below displays the simulation of a As a comparison, the figure below displays the simulation of a
single spin (of norm :math:`\mu_i = 1.0`) submitted to an external single spin (of norm :math:`\mu_i = 1.0`) submitted to an external

4
doc/src/fix_rx.rst
View File

@ -90,10 +90,10 @@ accepted, *h* is increased by a proportional amount, and the next ODE step is be
Otherwise, *h* is shrunk and the ODE step is repeated. Otherwise, *h* is shrunk and the ODE step is repeated.
Run-time diagnostics are available for the rkf45 ODE solver. The frequency Run-time diagnostics are available for the rkf45 ODE solver. The frequency
(in time-steps) that diagnostics are reported is controlled by the last (optional) (in timesteps) that diagnostics are reported is controlled by the last (optional)
12th argument. A negative frequency means that diagnostics are reported once at the 12th argument. A negative frequency means that diagnostics are reported once at the
end of each run. A positive value N means that the diagnostics are reported once end of each run. A positive value N means that the diagnostics are reported once
per N time-steps. per N timesteps.
The diagnostics report the average # of integrator steps and RHS function evaluations The diagnostics report the average # of integrator steps and RHS function evaluations
and run-time per ODE as well as the average/RMS/min/max per process. If the and run-time per ODE as well as the average/RMS/min/max per process. If the

3
doc/src/fix_shake.rst
View File

@ -1,9 +1,12 @@
.. index:: fix shake .. index:: fix shake
.. index:: fix shake/kk
.. index:: fix rattle .. index:: fix rattle
fix shake command fix shake command
================= =================
Accelerator Variants: *shake/kk*
fix rattle command fix rattle command
================== ==================

13
doc/src/fix_temp_csvr.rst
View File

@ -124,6 +124,19 @@ temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in. thermal degrees of freedom, and the bias is added back in.
An important feature of these thermostats is that they have an
associated effective energy that is a constant of motion.
The effective energy is the total energy (kinetic + potential) plus
the accumulated kinetic energy changes due to the thermostat. The
latter quantity is the global scalar computed by these fixes. This
feature is useful to check the integration of the equations of motion
against discretization errors. In other words, the conservation of
the effective energy can be used to choose an appropriate integration
:doc:`timestep <timestep>`. This is similar to the usual paradigm of
checking the conservation of the total energy in the microcanonical
ensemble.
---------- ----------
Restart, fix_modify, output, run start/stop, minimize info Restart, fix_modify, output, run start/stop, minimize info

14
doc/src/lattice.rst
View File

@ -251,12 +251,16 @@ in commands that use the spacings should be decipherable.
---------- ----------
Example commands for generating a Wurtzite crystal (courtesy Example commands for generating a Wurtzite crystal.
of Aidan Thompson), with its 8 atom unit cell. The lattice constants approximate those of CdSe.
The :math:`\sqrt{3}\times 1` orthorhombic supercell is used
with the x, y, and z directions oriented
along :math:`[\bar{1}\bar{2}30]`,
:math:`[10\bar{1}0]`, and :math:`[0001]`, respectively.
.. code-block:: LAMMPS .. code-block:: LAMMPS
variable a equal 4.340330 variable a equal 4.34
variable b equal $a*sqrt(3.0) variable b equal $a*sqrt(3.0)
variable c equal $a*sqrt(8.0/3.0) variable c equal $a*sqrt(8.0/3.0)
@ -264,8 +268,8 @@ of Aidan Thompson), with its 8 atom unit cell.
variable five6 equal 5.0/6.0 variable five6 equal 5.0/6.0
lattice custom 1.0 & lattice custom 1.0 &
a1 $a 0.0 0.0 & a1 $b 0.0 0.0 &
a2 0.0 $b 0.0 & a2 0.0 $a 0.0 &
a3 0.0 0.0 $c & a3 0.0 0.0 $c &
basis 0.0 0.0 0.0 & basis 0.0 0.0 0.0 &
basis 0.5 0.5 0.0 & basis 0.5 0.5 0.0 &

2
doc/src/message.rst
View File

@ -34,7 +34,7 @@ Examples
message server md file tmp.couple message server md file tmp.couple
message client md zmq localhost:5555 message client md zmq localhost:5555
message server md zmq \*:5555 message server md zmq *:5555
message client md mpi/one message client md mpi/one
message server md mpi/one message server md mpi/one

11
doc/src/molecule.rst
View File

@ -201,11 +201,12 @@ bonds between nuclear cores and Drude electrons in a different manner.
Each section is listed below in alphabetic order. The format of each Each section is listed below in alphabetic order. The format of each
section is described including the number of lines it must contain and section is described including the number of lines it must contain and
rules (if any) for whether it can appear in the data file. In each rules (if any) for whether it can appear in the data file. For per-
case the ID is ignored; it is simply included for readability, and atom sections, entries should be numbered from 1 to Natoms (where
should be a number from 1 to Nlines for the section, indicating which Natoms is the number of atoms in the template), indicating which atom
atom (or bond, etc) the entry applies to. The lines are assumed to be (or bond, etc) the entry applies to. Per-atom sections need to
listed in order from 1 to Nlines, but LAMMPS does not check for this. include a setting for every atom, but the atoms can be listed in any
order.
---------- ----------

4
doc/src/neighbor.rst
View File

@ -49,7 +49,9 @@ sometimes be faster. Either style should give the same answers.
The *multi* style is a modified binning algorithm that is useful for The *multi* style is a modified binning algorithm that is useful for
systems with a wide range of cutoff distances, e.g. due to different systems with a wide range of cutoff distances, e.g. due to different
size particles. For the *bin* style, the bin size is set to 1/2 of size particles. For granular pairstyles, cutoffs are set to the
sum of the maximum atomic radii for each atom type.
For the *bin* style, the bin size is set to 1/2 of
the largest cutoff distance between any pair of atom types and a the largest cutoff distance between any pair of atom types and a
single set of bins is defined to search over for all atom types. This single set of bins is defined to search over for all atom types. This
can be inefficient if one pair of types has a very long cutoff, but can be inefficient if one pair of types has a very long cutoff, but

3
doc/src/package.rst
View File

@ -448,8 +448,7 @@ does not require atomic operations in the calculation of pair forces. For
that reason, *full* is the default setting for GPUs. However, when that reason, *full* is the default setting for GPUs. However, when
running on CPUs, a *half* neighbor list is the default because it are running on CPUs, a *half* neighbor list is the default because it are
often faster, just as it is for non-accelerated pair styles. Similarly, often faster, just as it is for non-accelerated pair styles. Similarly,
the *neigh/qeq* keyword determines how neighbor lists are built for :doc:`fix qeq/reax/kk <fix_qeq_reax>`. If not explicitly set, the value of the *neigh/qeq* keyword determines how neighbor lists are built for :doc:`fix qeq/reax/kk <fix_qeq_reax>`.
*neigh/qeq* will match *neigh*\ .
If the *neigh/thread* keyword is set to *off*\ , then the KOKKOS package If the *neigh/thread* keyword is set to *off*\ , then the KOKKOS package
threads only over atoms. However, for small systems, this may not expose threads only over atoms. However, for small systems, this may not expose

2
doc/src/pair_atm.rst
View File

@ -143,7 +143,7 @@ combinations, else an error will result.
Mixing, shift, table, tail correction, restart, rRESPA info Mixing, shift, table, tail correction, restart, rRESPA info
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This pair styles do not support the :doc:`pair_modify <pair_modify>` This pair style do not support the :doc:`pair_modify <pair_modify>`
mix, shift, table, and tail options. mix, shift, table, and tail options.
This pair style writes its information to :doc:`binary restart files This pair style writes its information to :doc:`binary restart files

2
doc/src/pair_buck_long.rst
View File

@ -117,7 +117,7 @@ global Coulombic cutoff is allowed.
Mixing, shift, table, tail correction, restart, rRESPA info Mixing, shift, table, tail correction, restart, rRESPA info
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This pair styles does not support mixing. Thus, coefficients for all This pair style does not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly. I,J pairs must be specified explicitly.
This pair style supports the :doc:`pair_modify <pair_modify>` shift This pair style supports the :doc:`pair_modify <pair_modify>` shift

2
doc/src/pair_gayberne.rst
View File

@ -160,7 +160,7 @@ For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for this pair style can be mixed. The default mix and cutoff distance for this pair style can be mixed. The default mix
value is *geometric*\ . See the "pair_modify" command for details. value is *geometric*\ . See the "pair_modify" command for details.
This pair styles supports the :doc:`pair_modify <pair_modify>` shift This pair style supports the :doc:`pair_modify <pair_modify>` shift
option for the energy of the Lennard-Jones portion of the pair option for the energy of the Lennard-Jones portion of the pair
interaction, but only for sphere-sphere interactions. There is no interaction, but only for sphere-sphere interactions. There is no
shifting performed for ellipsoidal interactions due to the anisotropic shifting performed for ellipsoidal interactions due to the anisotropic

9
doc/src/pair_lcbop.rst
View File

@ -75,14 +75,15 @@ This pair style can only be used via the *pair* keyword of the
Restrictions Restrictions
"""""""""""" """"""""""""
This pair styles is part of the MANYBODY package. It is only enabled This pair style is part of the MANYBODY package. It is only enabled
if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` doc page for more info. if LAMMPS was built with that package.
See the :doc:`Build package <Build_package>` doc page for more info.
This pair potential requires the :doc:`newton <newton>` setting to be This pair potential requires the :doc:`newton <newton>` setting to be
"on" for pair interactions. "on" for pair interactions.
The C.lcbop potential file provided with LAMMPS (see the potentials The ``C.lcbop`` potential file provided with LAMMPS (see the potentials
directory) is parameterized for metal :doc:`units <units>`. You can use directory) is parameterized for :doc:`metal units <units>`. You can use
the LCBOP potential with any LAMMPS units, but you would need to the LCBOP potential with any LAMMPS units, but you would need to
create your own LCBOP potential file with coefficients listed in the create your own LCBOP potential file with coefficients listed in the
appropriate units if your simulation does not use "metal" units. appropriate units if your simulation does not use "metal" units.

29
doc/src/pair_meam_spline.rst
View File

@ -20,7 +20,7 @@ Examples
pair_style meam/spline pair_style meam/spline
pair_coeff * * Ti.meam.spline Ti pair_coeff * * Ti.meam.spline Ti
pair_coeff * * Ti.meam.spline Ti Ti Ti pair_coeff * * Ti.meam.spline Ti O
Description Description
""""""""""" """""""""""
@ -84,23 +84,22 @@ where N is the number of LAMMPS atom types:
See the :doc:`pair_coeff <pair_coeff>` doc page for alternate ways See the :doc:`pair_coeff <pair_coeff>` doc page for alternate ways
to specify the path for the potential file. to specify the path for the potential file.
As an example, imagine the Ti.meam.spline file has values for Ti (old style). If As an example, imagine the Ti.meam.spline file has values for Ti (old style).
your LAMMPS simulation has 3 atoms types and they are all to be In that case your LAMMPS simulation may only have one atom type which has
treated with this potentials, you would use the following pair_coeff to be mapped to the Ti element as follows:
command:
.. code-block:: LAMMPS .. code-block:: LAMMPS
pair_coeff * * Ti.meam.spline Ti Ti Ti pair_coeff * * Ti.meam.spline Ti
The first 2 arguments must be \* \* so as to span all LAMMPS atom types. The first 2 arguments must be \* \* and there may be only one element
The three Ti arguments map LAMMPS atom types 1,2,3 to the Ti element following or NULL. Systems where there would be multiple atom types
in the potential file. If a mapping value is specified as NULL, the assigned to the same element are **not** supported by this pair style
mapping is not performed. This can be used when a *meam/spline* due to limitations in its implementation. If a mapping value is
potential is used as part of the *hybrid* pair style. The NULL values specified as NULL, the mapping is not performed. This can be used when
are placeholders for atom types that will be used with other a *meam/spline* potential is used as part of the *hybrid* pair style.
potentials. The old-style potential maps any non-NULL species named The NULL values are placeholders for atom types that will be used with
on the command line to that single type. other potentials.
An example with a two component spline (new style) is TiO.meam.spline, where An example with a two component spline (new style) is TiO.meam.spline, where
the command the command
@ -143,6 +142,8 @@ Restrictions
This pair style requires the :doc:`newton <newton>` setting to be "on" This pair style requires the :doc:`newton <newton>` setting to be "on"
for pair interactions. for pair interactions.
This pair style does not support mapping multiple atom types to the same element.
This pair style is only enabled if LAMMPS was built with the USER-MISC This pair style is only enabled if LAMMPS was built with the USER-MISC
package. See the :doc:`Build package <Build_package>` doc page for more package. See the :doc:`Build package <Build_package>` doc page for more
info. info.

2
doc/src/pair_polymorphic.rst
View File

@ -298,7 +298,7 @@ described above. For each of the F functions, nx values are listed.
Mixing, shift, table, tail correction, restart, rRESPA info Mixing, shift, table, tail correction, restart, rRESPA info
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This pair styles does not support the :doc:`pair_modify <pair_modify>` This pair style does not support the :doc:`pair_modify <pair_modify>`
shift, table, and tail options. shift, table, and tail options.
This pair style does not write their information to :doc:`binary restart This pair style does not write their information to :doc:`binary restart

2
doc/src/pair_resquared.rst
View File

@ -173,7 +173,7 @@ equation for the Hamaker constant presented here. Mixing of sigma and
epsilon followed by calculation of the energy prefactors using the epsilon followed by calculation of the energy prefactors using the
equations above is recommended. equations above is recommended.
This pair styles supports the :doc:`pair_modify <pair_modify>` shift This pair style supports the :doc:`pair_modify <pair_modify>` shift
option for the energy of the Lennard-Jones portion of the pair option for the energy of the Lennard-Jones portion of the pair
interaction, but only for sphere-sphere interactions. There is no interaction, but only for sphere-sphere interactions. There is no
shifting performed for ellipsoidal interactions due to the anisotropic shifting performed for ellipsoidal interactions due to the anisotropic

161
doc/src/pair_spin_exchange.rst
View File

@ -1,14 +1,19 @@
.. index:: pair_style spin/exchange .. index:: pair_style spin/exchange
.. index:: pair_style spin/exchange/biquadratic
pair_style spin/exchange command pair_style spin/exchange command
================================ ================================
pair_style spin/exchange/biquadratic command
============================================
Syntax Syntax
"""""" """"""
.. code-block:: LAMMPS .. code-block:: LAMMPS
pair_style spin/exchange cutoff pair_style spin/exchange cutoff
pair_style spin/exchange/biquadratic cutoff
* cutoff = global cutoff pair (distance in metal units) * cutoff = global cutoff pair (distance in metal units)
@ -19,7 +24,11 @@ Examples
pair_style spin/exchange 4.0 pair_style spin/exchange 4.0
pair_coeff * * exchange 4.0 0.0446928 0.003496 1.4885 pair_coeff * * exchange 4.0 0.0446928 0.003496 1.4885
pair_coeff 1 2 exchange 6.0 -0.01575 0.0 1.965 pair_coeff 1 2 exchange 6.0 -0.01575 0.0 1.965 offset yes
pair_style spin/exchange/biquadratic 4.0
pair_coeff * * biquadratic 4.0 0.05 0.03 1.48 0.05 0.03 1.48 offset no
pair_coeff 1 2 biquadratic 6.0 -0.01 0.0 1.9 0.0 0.1 19
Description Description
""""""""""" """""""""""
@ -31,69 +40,163 @@ pairs of magnetic spins:
H_{ex} = -\sum_{i,j}^N J_{ij} (r_{ij}) \,\vec{s}_i \cdot \vec{s}_j H_{ex} = -\sum_{i,j}^N J_{ij} (r_{ij}) \,\vec{s}_i \cdot \vec{s}_j
where :math:`\vec{s}_i` and :math:`\vec{s}_j` are two neighboring magnetic spins of two particles, where :math:`\vec{s}_i` and :math:`\vec{s}_j` are two unit vectors representing
:math:`r_{ij} = \vert \vec{r}_i - \vec{r}_j \vert` is the inter-atomic distance between the two the magnetic spins of two particles (usually atoms), and
particles. The summation is over pairs of nearest neighbors. :math:`r_{ij} = \vert \vec{r}_i - \vec{r}_j \vert` is the inter-atomic distance
:math:`J(r_{ij})` is a function defining the intensity and the sign of the exchange between those two particles. The summation is over pairs of nearest neighbors.
interaction for different neighboring shells. This function is defined as: :math:`J(r_{ij})` is a function defining the intensity and the sign of the
exchange interaction for different neighboring shells.
Style *spin/exchange/biquadratic* computes a biquadratic exchange interaction
between pairs of magnetic spins:
.. math:: .. math::
{J}\left( r_{ij} \right) = 4 a \left( \frac{r_{ij}}{d} \right)^2 \left( 1 - b \left( \frac{r_{ij}}{d} \right)^2 \right) e^{-\left( \frac{r_{ij}}{d} \right)^2 }\Theta (R_c - r_{ij}) H_{bi} = -\sum_{i, j}^{N} {J}_{ij} \left(r_{ij} \right)\,
\vec{s}_{i}\cdot \vec{s}_{j}
-\sum_{i, j}^{N} {K}_{ij} \left(r_{ij} \right)\,
\left(\vec{s}_{i}\cdot
\vec{s}_{j}\right)^2
where :math:`a`, :math:`b` and :math:`d` are the three constant coefficients defined in the associated where :math:`\vec{s}_i`, :math:`\vec{s}_j`, :math:`r_{ij}` and
"pair_coeff" command, and :math:`R_c` is the radius cutoff associated to :math:`J(r_{ij})` have the same definitions as above, and :math:`K(r_{ij})` is
the pair interaction (see below for more explanations). a second function, defining the intensity and the sign of the biquadratic term.
The coefficients :math:`a`, :math:`b`, and :math:`d` need to be fitted so that the function above matches with The interatomic dependence of :math:`J(r_{ij})` and :math:`K(r_{ij})` in both
the value of the exchange interaction for the :math:`N` neighbor shells taken into account. interactions above is defined by the following function:
Examples and more explanations about this function and its parameterization are reported
in :ref:`(Tranchida) <Tranchida3>`. .. math::
{f}\left( r_{ij} \right) = 4 a \left( \frac{r_{ij}}{d} \right)^2
\left( 1 - b \left( \frac{r_{ij}}{d} \right)^2 \right)
e^{-\left( \frac{r_{ij}}{d} \right)^2 }\Theta (R_c - r_{ij})
where :math:`a`, :math:`b` and :math:`d` are the three constant coefficients
defined in the associated "pair_coeff" command, and :math:`R_c` is the radius
cutoff associated to the pair interaction (see below for more explanations).
The coefficients :math:`a`, :math:`b`, and :math:`d` need to be fitted so that
the function above matches with the value of the exchange interaction for the
:math:`N` neighbor shells taken into account.
Examples and more explanations about this function and its parameterization
are reported in :ref:`(Tranchida) <Tranchida3>`.
When a *spin/exchange/biquadratic* pair style is defined, six coefficients
(three for :math:`J(r_{ij})`, and three for :math:`K(r_{ij})`) have to be
fitted.
From this exchange interaction, each spin :math:`i` will be submitted From this exchange interaction, each spin :math:`i` will be submitted
to a magnetic torque :math:`\vec{\omega}`, and its associated atom can be submitted to a to a magnetic torque :math:`\vec{\omega}_{i}`, and its associated atom can be
force :math:`\vec{F}` for spin-lattice calculations (see :doc:`fix nve/spin <fix_nve_spin>`), submitted to a force :math:`\vec{F}_{i}` for spin-lattice calculations (see
such as: :doc:`fix nve/spin <fix_nve_spin>`), such as:
.. math:: .. math::
\vec{\omega}_{i} = \frac{1}{\hbar} \sum_{j}^{Neighb} {J} \vec{\omega}_{i} = \frac{1}{\hbar} \sum_{j}^{Neighb} {J}
\left(r_{ij} \right)\,\vec{s}_{j} \left(r_{ij} \right)\,\vec{s}_{j}
~~{\rm and}~~ ~~{\rm and}~~
\vec{F}_{i} = \sum_{j}^{Neighb} \frac{\partial {J} \left(r_{ij} \right)}{ \partial r_{ij}} \left( \vec{s}_{i}\cdot \vec{s}_{j} \right) \vec{e}_{ij} \vec{F}_{i} = \sum_{j}^{Neighb} \frac{\partial {J} \left(r_{ij} \right)}{
\partial r_{ij}} \left( \vec{s}_{i}\cdot \vec{s}_{j} \right) \vec{e}_{ij}
with :math:`\hbar` the Planck constant (in metal units), and :math:`\vec{e}_{ij} = \frac{\vec{r}_i - \vec{r}_j}{\vert \vec{r}_i-\vec{r}_j \vert}` the unit with :math:`\hbar` the Planck constant (in metal units), and :math:`\vec{e}_{ij}
= \frac{\vec{r}_i - \vec{r}_j}{\vert \vec{r}_i-\vec{r}_j \vert}` the unit
vector between sites :math:`i` and :math:`j`. vector between sites :math:`i` and :math:`j`.
Equivalent forces and magnetic torques are generated for the biquadratic term
when a *spin/exchange/biquadratic* pair style is defined.
More details about the derivation of these torques/forces are reported in More details about the derivation of these torques/forces are reported in
:ref:`(Tranchida) <Tranchida3>`. :ref:`(Tranchida) <Tranchida3>`.
For the *spin/exchange* pair style, the following coefficients must be defined For the *spin/exchange* and *spin/exchange/biquadratic* pair styles, the
for each pair of atoms types via the :doc:`pair_coeff <pair_coeff>` command as in following coefficients must be defined for each pair of atoms types via the
the examples above, or in the data file or restart files read by the :doc:`pair_coeff <pair_coeff>` command as in the examples above, or in the data
:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>` commands, and file or restart files read by the :doc:`read_data <read_data>` or
set in the following order: :doc:`read_restart <read_restart>` commands, and set in the following order:
* :math:`R_c` (distance units) * :math:`R_c` (distance units)
* :math:`a` (energy units) * :math:`a` (energy units)
* :math:`b` (adim parameter) * :math:`b` (adim parameter)
* :math:`d` (distance units) * :math:`d` (distance units)
Note that :math:`R_c` is the radius cutoff of the considered exchange interaction, for the *spin/exchange* pair style, and:
and :math:`a`, :math:`b` and :math:`d` are the three coefficients performing the parameterization
of the function :math:`J(r_{ij})` defined above. * :math:`R_c` (distance units)
* :math:`a_j` (energy units)
* :math:`b_j` (adim parameter)
* :math:`d_j` (distance units)
* :math:`a_k` (energy units)
* :math:`b_k` (adim parameter)
* :math:`d_k` (distance units)
for the *spin/exchange/biquadratic* pair style.
Note that :math:`R_c` is the radius cutoff of the considered exchange
interaction, and :math:`a`, :math:`b` and :math:`d` are the three coefficients
performing the parameterization of the function :math:`J(r_{ij})` defined
above (in the *biquadratic* style, :math:`a_j`, :math:`b_j`, :math:`d_j` and
:math:`a_k`, :math:`b_k`, :math:`d_k` are the coefficients of :math:`J(r_{ij})`
and :math:`K(r_{ij})` respectively).
None of those coefficients is optional. If not specified, the None of those coefficients is optional. If not specified, the
*spin/exchange* pair style cannot be used. *spin/exchange* pair style cannot be used.
---------- ----------
**Offsetting magnetic forces and energies**\ :
For spin-lattice simulation, it can be useful to offset the
mechanical forces and energies generated by the exchange
interaction.
The *offset* keyword allows to apply this offset.
By setting *offset* to *yes*, the energy definitions above are
replaced by:
.. math::
H_{ex} = -\sum_{i,j}^N J_{ij} (r_{ij}) \,[ \vec{s}_i \cdot \vec{s}_j-1 ]
for the *spin/exchange* pair style, and:
.. math::
H_{bi} = -\sum_{i, j}^{N} {J}_{ij} \left(r_{ij} \right)\,
[ \vec{s}_{i}\cdot \vec{s}_{j} -1 ]
-\sum_{i, j}^{N} {K}_{ij} \left(r_{ij} \right)\,
[ \left(\vec{s}_{i}\cdot
\vec{s}_{j}\right)^2 -1]
for the *spin/exchange/biquadratic* pair style.
Note that this offset only affects the calculation of the energy
and mechanical forces. It does not modify the calculation of the
precession vectors (and thus does no impact the purely magnetic
properties).
This ensures that when all spins are aligned, the magnetic energy
and the associated mechanical forces (and thus the pressure
generated by the magnetic potential) are null.
.. note::
This offset term can be very important when calculations such as
equations of state (energy vs volume, or energy vs pressure) are
being performed. Indeed, setting the *offset* term ensures that
at the ground state of the crystal and at the equilibrium magnetic
configuration (typically ferromagnetic), the pressure is null,
as expected.
Otherwise, magnetic forces could generate a residual pressure.
When the *offset* option is set to *no*, no offset is applied
(also corresponding to the default option).
----------
Restrictions Restrictions
"""""""""""" """"""""""""
All the *pair/spin* styles are part of the SPIN package. These styles All the *pair/spin* styles are part of the SPIN package. These styles
are only enabled if LAMMPS was built with this package, and if the are only enabled if LAMMPS was built with this package, and if the
atom_style "spin" was declared. See the :doc:`Build package <Build_package>` doc page for more info. atom_style "spin" was declared.
See the :doc:`Build package <Build_package>` doc page for more info.
Related commands Related commands
"""""""""""""""" """"""""""""""""
@ -105,7 +208,7 @@ Default
""""""" """""""
none The default *offset* keyword value is *no*.
---------- ----------

2
doc/src/pair_srp.rst
View File

@ -124,7 +124,7 @@ at the cutoff distance :math:`r_c`.
Mixing, shift, table, tail correction, restart, rRESPA info Mixing, shift, table, tail correction, restart, rRESPA info
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This pair styles does not support mixing. This pair style does not support mixing.
This pair style does not support the :doc:`pair_modify <pair_modify>` This pair style does not support the :doc:`pair_modify <pair_modify>`
shift option for the energy of the pair interaction. Note that as shift option for the energy of the pair interaction. Note that as

1
doc/src/pair_style.rst
View File

@ -305,6 +305,7 @@ accelerated styles exist.
* :doc:`spin/dipole/long <pair_spin_dipole>` - * :doc:`spin/dipole/long <pair_spin_dipole>` -
* :doc:`spin/dmi <pair_spin_dmi>` - * :doc:`spin/dmi <pair_spin_dmi>` -
* :doc:`spin/exchange <pair_spin_exchange>` - * :doc:`spin/exchange <pair_spin_exchange>` -
* :doc:`spin/exchange/biquadratic <pair_spin_exchange>` -
* :doc:`spin/magelec <pair_spin_magelec>` - * :doc:`spin/magelec <pair_spin_magelec>` -
* :doc:`spin/neel <pair_spin_neel>` - * :doc:`spin/neel <pair_spin_neel>` -
* :doc:`srp <pair_srp>` - * :doc:`srp <pair_srp>` -

26
doc/src/python.rst
View File

@ -323,8 +323,8 @@ Python function is as follows:
The function definition must include a variable (lmpptr in this case) The function definition must include a variable (lmpptr in this case)
which corresponds to SELF in the python command. The first line of the which corresponds to SELF in the python command. The first line of the
function imports the Python module lammps.py in the python directory of function imports the :doc:`"lammps" Python module <Python_module>`.
the distribution. The second line creates a Python object "lmp" which The second line creates a Python object ``lmp`` which
wraps the instance of LAMMPS that called the function. The "ptr=lmpptr" wraps the instance of LAMMPS that called the function. The "ptr=lmpptr"
argument is what makes that happen. The third line invokes the argument is what makes that happen. The third line invokes the
command() function in the LAMMPS library interface. It takes a single command() function in the LAMMPS library interface. It takes a single
@ -502,18 +502,16 @@ Python library on your system. Settings to enable this are in the
lib/python/Makefile.lammps file. See the lib/python/README file for lib/python/Makefile.lammps file. See the lib/python/README file for
information on those settings. information on those settings.
If you use Python code which calls back to LAMMPS, via the SELF input If you use Python code which calls back to LAMMPS, via the SELF input argument
argument explained above, there is an extra step required when explained above, there is an extra step required when building LAMMPS. LAMMPS
building LAMMPS. LAMMPS must also be built as a shared library and must also be built as a shared library and your Python function must be able to
your Python function must be able to load the Python module in load the :doc:`"lammps" Python module <Python_module>` that wraps the LAMMPS
python/lammps.py that wraps the LAMMPS library interface. These are library interface. These are the same steps required to use Python by itself
the same steps required to use Python by itself to wrap LAMMPS. to wrap LAMMPS. Details on these steps are explained on the :doc:`Python
Details on these steps are explained on the :doc:`Python <Python_head>` <Python_head>` doc page. Note that it is important that the stand-alone LAMMPS
doc page. Note that it is important that the stand-alone LAMMPS executable and the LAMMPS shared library be consistent (built from the same
executable and the LAMMPS shared library be consistent (built from the source code files) in order for this to work. If the two have been built at
same source code files) in order for this to work. If the two have different times using different source files, problems may occur.
been built at different times using different source files, problems
may occur.
Related commands Related commands
"""""""""""""""" """"""""""""""""

58
doc/src/read_data.rst
View File

@ -345,10 +345,11 @@ Similarly, the z dimension should be periodic if xz or yz is non-zero.
LAMMPS does not require this periodicity, but you may lose atoms if LAMMPS does not require this periodicity, but you may lose atoms if
this is not the case. this is not the case.
Also note that if your simulation will tilt the box, e.g. via the :doc:`fix deform <fix_deform>` command, the simulation box must be setup to Also note that if your simulation will tilt the box, e.g. via the
be triclinic, even if the tilt factors are initially 0.0. You can :doc:`fix deform <fix_deform>` command, the simulation box must be setup
also change an orthogonal box to a triclinic box or vice versa by to be triclinic, even if the tilt factors are initially 0.0. You can
using the :doc:`change box <change_box>` command with its *ortho* and also change an orthogonal box to a triclinic box or vice versa by using
the :doc:`change box <change_box>` command with its *ortho* and
*triclinic* options. *triclinic* options.
For 2d simulations, the *zlo zhi* values should be set to bound the z For 2d simulations, the *zlo zhi* values should be set to bound the z
@ -364,24 +365,53 @@ periodic remapping will be performed using simulation box bounds that
are the union of the existing box and the box boundaries in the new are the union of the existing box and the box boundaries in the new
data file. data file.
If the system is non-periodic (in a dimension), then an image flag for
that direction has no meaning, since there cannot be periodic images
without periodicity and the data file is therefore - technically speaking
- invalid. This situation would happen when a data file was written
with periodic boundaries and then read back for non-periodic boundaries.
Accepting a non-zero image flag can lead to unexpected results for any
operations and computations in LAMMPS that internally use unwrapped
coordinates (for example computing the center of mass of a group of
atoms). Thus all non-zero image flags for non-periodic dimensions will
be be reset to zero on reading the data file and LAMMPS will print a
warning message, if that happens. This is equivalent to wrapping atoms
individually back into the principal unit cell in that direction. This
operation is equivalent to the behavior of the :doc:`change_box command
<change_box>` when used to change periodicity.
If those atoms with non-zero image flags are involved in bonded
interactions, this reset can lead to undesired changes, when the image
flag values differ between the atoms, i.e. the bonded interaction
straddles domain boundaries. For example a bond can become stretched
across the unit cell if one of its atoms is wrapped to one side of the
cell and the second atom to the other. In those cases the data file
needs to be pre-processed externally to become valid again. This can be
done by first unwrapping coordinates and then wrapping entire molecules
instead of individual atoms back into the principal simulation cell and
finally expanding the cell dimensions in the non-periodic direction as
needed, so that the image flag would be zero.
.. note:: .. note::
If the system is non-periodic (in a dimension), then all atoms If the system is non-periodic (in a dimension), then all atoms in the
in the data file must have coordinates (in that dimension) that are data file must have coordinates (in that dimension) that are "greater
"greater than or equal to" the lo value and "less than or equal to" than or equal to" the lo value and "less than or equal to" the hi
the hi value. If the non-periodic dimension is of style "fixed" (see value. If the non-periodic dimension is of style "fixed" (see the
the :doc:`boundary <boundary>` command), then the atom coords must be :doc:`boundary <boundary>` command), then the atom coords must be
strictly "less than" the hi value, due to the way LAMMPS assign atoms strictly "less than" the hi value, due to the way LAMMPS assign atoms
to processors. Note that you should not make the lo/hi values to processors. Note that you should not make the lo/hi values
radically smaller/larger than the extent of the atoms. For example, radically smaller/larger than the extent of the atoms. For example,
if your atoms extend from 0 to 50, you should not specify the box if your atoms extend from 0 to 50, you should not specify the box
bounds as -10000 and 10000. This is because LAMMPS uses the specified bounds as -10000 and 10000 unless you also use the :doc:`processors
box size to layout the 3d grid of processors. A huge (mostly empty) command <processors>`. This is because LAMMPS uses the specified box
box will be sub-optimal for performance when using "fixed" boundary size to layout the 3d grid of processors. A huge (mostly empty) box
will be sub-optimal for performance when using "fixed" boundary
conditions (see the :doc:`boundary <boundary>` command). When using conditions (see the :doc:`boundary <boundary>` command). When using
"shrink-wrap" boundary conditions (see the :doc:`boundary <boundary>` "shrink-wrap" boundary conditions (see the :doc:`boundary <boundary>`
command), a huge (mostly empty) box may cause a parallel simulation to command), a huge (mostly empty) box may cause a parallel simulation
lose atoms when LAMMPS shrink-wraps the box around the atoms. The to lose atoms when LAMMPS shrink-wraps the box around the atoms. The
read_data command will generate an error in this case. read_data command will generate an error in this case.
The "extra bond per atom" setting (angle, dihedral, improper) is only The "extra bond per atom" setting (angle, dihedral, improper) is only

2
doc/src/read_dump.rst
View File

@ -370,6 +370,8 @@ needed to generate absolute, unscaled coordinates.
Restrictions Restrictions
"""""""""""" """"""""""""
The *native* dump file reader does not support binary .bin dump files.
To read gzipped dump files, you must compile LAMMPS with the To read gzipped dump files, you must compile LAMMPS with the
-DLAMMPS_GZIP option. See the :doc:`Build settings <Build_settings>` -DLAMMPS_GZIP option. See the :doc:`Build settings <Build_settings>`
doc page for details. doc page for details.

29
doc/src/rerun.rst
View File

@ -99,14 +99,15 @@ files do not match the specified output frequency.
---------- ----------
If more than one dump file is specified, the dump files are read one If more than one dump file is specified, the dump files are read one
after the other. It is assumed that snapshot timesteps will be in after the other in the order specified. It is assumed that snapshot
ascending order. If a snapshot is encountered that is not in timesteps will be in ascending order. If a snapshot is encountered that
ascending order, it will skip the snapshot until it reads one that is. is not in ascending order, it will skip the snapshot until it reads one
that is.
This allows skipping of a duplicate snapshot (same timestep), This allows skipping of a duplicate snapshot (same timestep),
e.g. that appeared at the end of one file and beginning of the next. e.g. that appeared at the end of one file and beginning of the next.
However if you specify a series of dump files in an incorrect order However if you specify a series of dump files in an incorrect order
(with respect to the timesteps they contain), you may skip large (with respect to the timesteps they contain), you may skip large
numbers of snapshots numbers of snapshots.
Note that the dump files specified as part of the *dump* keyword can be Note that the dump files specified as part of the *dump* keyword can be
parallel files, i.e. written as multiple files either per processor parallel files, i.e. written as multiple files either per processor
@ -118,17 +119,24 @@ and write parallel dump files.
The *first*\ , *last*\ , *every*\ , *skip* keywords determine which The *first*\ , *last*\ , *every*\ , *skip* keywords determine which
snapshots are read from the dump file(s). Snapshots are skipped until snapshots are read from the dump file(s). Snapshots are skipped until
they have a timestamp >= *Nfirst*\ . When a snapshot with a timestamp > they have a timestep >= *Nfirst*\ . When a snapshot with a timestep >
*Nlast* is encountered, the rerun command finishes. Note below that *Nlast* is encountered, the rerun command finishes. Note that
the defaults for *first* and *last* are to read all snapshots. If the the defaults for *first* and *last* are to read all snapshots. If the
*every* keyword is set to a value > 0, then only snapshots with *every* keyword is set to a value > 0, then only snapshots with
timestamps that are a multiple of *Nevery* are read (the first timesteps that are a multiple of *Nevery* are read (the first
snapshot is always read). If *Nevery* = 0, then this criterion is snapshot is always read). If *Nevery* = 0, then this criterion is
ignored, i.e. every snapshot is read that meets the other criteria. ignored, i.e. every snapshot is read that meets the other criteria.
If the *skip* keyword is used, then after the first snapshot is read, If the *skip* keyword is used, then after the first snapshot is read,
every Nth snapshot is read, where N = *Nskip*\ . E.g. if *Nskip* = 3, every Nth snapshot is read, where N = *Nskip*\ . E.g. if *Nskip* = 3,
then only 1 out of every 3 snapshots is read, assuming the snapshot then only 1 out of every 3 snapshots is read, assuming the snapshot
timestamp is also consistent with the other criteria. timestep is also consistent with the other criteria.
.. note::
Not all dump formats contain the timestep and not all dump readers
support reading it. In that case individual snapshots are assigned
consecutive timestep numbers starting at 1.
The *start* and *stop* keywords do not affect which snapshots are read The *start* and *stop* keywords do not affect which snapshots are read
from the dump file(s). Rather, they have the same meaning that they from the dump file(s). Rather, they have the same meaning that they
@ -205,9 +213,8 @@ thermodynamic output or new dump file output.
Restrictions Restrictions
"""""""""""" """"""""""""
To read gzipped dump files, you must compile LAMMPS with the The *rerun* command is subject to all restrictions of
-DLAMMPS_GZIP option. See the :doc:`Build settings <Build_settings>` the :doc:`read_dump <read_dump>` command.
doc page for details.
Related commands Related commands
"""""""""""""""" """"""""""""""""

11
doc/src/set.rst
View File

@ -13,7 +13,16 @@ Syntax
* style = *atom* or *type* or *mol* or *group* or *region* * style = *atom* or *type* or *mol* or *group* or *region*
* ID = atom ID range or type range or mol ID range or group ID or region ID * ID = atom ID range or type range or mol ID range or group ID or region ID
* one or more keyword/value pairs may be appended * one or more keyword/value pairs may be appended
* keyword = *type* or *type/fraction* or *type/ratio* or *type/subset* or *mol* or *x* or *y* or *z* or *charge* or *dipole* or *dipole/random* or *quat* or *spin* or *spin/random* or *quat* or *quat/random* or *diameter* or *shape* or *length* or *tri* or *theta* or *theta/random* or *angmom* or *omega* or *mass* or *density* or *density/disc* or *volume* or *image* or *bond* or *angle* or *dihedral* or *improper* or *sph/e* or *sph/cv* or *sph/rho* or *smd/contact/radius* or *smd/mass/density* or *dpd/theta* or *edpd/temp* or *edpd/cv* or *cc* or *i_name* or *d_name* * keyword = *type* or *type/fraction* or *type/ratio* or *type/subset* or *mol*
or *x* or *y* or *z* or *vx* or *vy* or *vz*
or *charge* or *dipole* or *dipole/random* or *spin* or *spin/random*
or *quat* *quat/random* or *diameter* or *shape* or *length* or *tri*
or *theta* or *theta/random* or *angmom* or *omega* or *mass*
or *density* or *density/disc* or *volume* or *image*
or *bond* or *angle* or *dihedral* or *improper*
or *sph/e* or *sph/cv* or *sph/rho* or *smd/contact/radius* or *smd/mass/density*
or *dpd/theta* or *edpd/temp* or *edpd/cv* or *cc*
or *i_name* or *d_name*
.. parsed-literal:: .. parsed-literal::

10
doc/src/units.rst
View File

@ -66,11 +66,15 @@ generality, LAMMPS sets the fundamental quantities mass, :math:`\sigma`,
masses, distances, energies you specify are multiples of these masses, distances, energies you specify are multiples of these
fundamental values. The formulas relating the reduced or unitless fundamental values. The formulas relating the reduced or unitless
quantity (with an asterisk) to the same quantity with units is also quantity (with an asterisk) to the same quantity with units is also
given. Thus you can use the mass & :math:`\sigma` & :math:`\epsilon` given. Thus you can use the mass, :math:`\sigma`, and :math:`\epsilon`
values for a specific material and convert the results from a unitless values for a specific material and convert the results from a unitless
LJ simulation into physical quantities. LJ simulation into physical quantities. Please note that using
these three properties as base, your unit of time has to conform
to the relation :math:`\epsilon = \frac{m \sigma^2}{\tau^2}` since
energy is a derived unit (in SI units you equivalently have the relation
:math:`1\mathsf{J} = 1\frac{\mathsf{kg}\cdot\mathsf{m}^2}{\mathsf{s}^2}`).
* mass = mass or *m* * mass = mass or :math:`m`, where :math:`M^* = \frac{M}{m}`
* distance = :math:`\sigma`, where :math:`x^* = \frac{x}{\sigma}` * distance = :math:`\sigma`, where :math:`x^* = \frac{x}{\sigma}`
* time = :math:`\tau`, where :math:`\tau^* = \tau \sqrt{\frac{\epsilon}{m \sigma^2}}` * time = :math:`\tau`, where :math:`\tau^* = \tau \sqrt{\frac{\epsilon}{m \sigma^2}}`
* energy = :math:`\epsilon`, where :math:`E^* = \frac{E}{\epsilon}` * energy = :math:`\epsilon`, where :math:`E^* = \frac{E}{\epsilon}`

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

@ -148,6 +148,7 @@ athomps
atm atm
atomeye atomeye
atomfile atomfile
AtomicPairStyle
atomID atomID
atomistic atomistic
attogram attogram
@ -240,6 +241,7 @@ bigint
Bij Bij
bilayer bilayer
bilayers bilayers
biquadratic
binsize binsize
binstyle binstyle
binutils binutils
@ -277,7 +279,6 @@ Boltzman
BondAngle BondAngle
BondBond BondBond
bondchk bondchk
BondingIDs
bondmax bondmax
bondtype bondtype
Bonet Bonet
@ -1118,12 +1119,15 @@ gmail
gmake gmake
gmask gmask
Gmask Gmask
GMock
gneb gneb
GNEB GNEB
Goldfarb Goldfarb
Gonzalez-Melchor Gonzalez-Melchor
googlemail googlemail
googletest
Gordan Gordan
Goudeau
GPa GPa
gpu gpu
gpuID gpuID
@ -1324,6 +1328,7 @@ inhomogeneous
init init
initialdelay initialdelay
initializations initializations
InitiatorIDs
initio initio
InP InP
inregion inregion
@ -1542,6 +1547,7 @@ ksh
kspace kspace
Kspace Kspace
KSpace KSpace
KSpaceStyle
Kspring Kspring
kT kT
kTequil kTequil
@ -1882,6 +1888,7 @@ mie
Mie Mie
Mij Mij
Mikami Mikami
Milano
Militzer Militzer
Minary Minary
mincap mincap
@ -1927,6 +1934,7 @@ mol
Mol Mol
molfile molfile
Molfile Molfile
MolPairStyle
moltemplate moltemplate
momb momb
Monaghan Monaghan
@ -1984,6 +1992,7 @@ multi
multibody multibody
Multibody Multibody
multicenter multicenter
multicentered
multicmd multicmd
multicomponent multicomponent
multicore multicore
@ -2004,6 +2013,7 @@ muVT
mux mux
muy muy
muz muz
Müller
mv mv
mV mV
Mvapich Mvapich
@ -2301,7 +2311,6 @@ ortho
orthonormal orthonormal
orthorhombic orthorhombic
oso oso
ot
Otype Otype
Ouldridge Ouldridge
outfile outfile
@ -2452,6 +2461,7 @@ polydispersity
polyelectrolyte polyelectrolyte
polyhedra polyhedra
polymorphism polymorphism
Polym
popen popen
Popov Popov
popstore popstore
@ -2614,7 +2624,6 @@ Ree
refactored refactored
refactoring refactoring
reflectionstyle reflectionstyle
regoin
Reinders Reinders
reinit reinit
relaxbox relaxbox
@ -2784,6 +2793,7 @@ Schulten
Schunk Schunk
Schuring Schuring
Schwen Schwen
Sci
screenshot screenshot
screenshots screenshots
Scripps Scripps
@ -2979,6 +2989,8 @@ Subclassed
subcutoff subcutoff
subcycle subcycle
subcycling subcycling
subhi
sublo
Subramaniyan Subramaniyan
subscripted subscripted
subscripting subscripting
@ -2989,6 +3001,7 @@ Sukumaran
Sulc Sulc
sumsq sumsq
Sunderland Sunderland
supercell
superset superset
supersphere supersphere
Supinski Supinski
@ -3287,6 +3300,7 @@ vdfmax
vdim vdim
vdisplace vdisplace
vdW vdW
vdwl
vec vec
vectorial vectorial
vectorization vectorization
@ -3454,6 +3468,7 @@ xyz
xz xz
xzhou xzhou
yaff yaff
yaml
YAFF YAFF
Yamada Yamada
Yaser Yaser

2
examples/COUPLE/fortran2/Makefile
View File

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

2
examples/COUPLE/python/example.py
View File

@ -1,4 +1,4 @@
# this example requires the LAMMPS Python package (lammps.py) to be installed # this example requires the LAMMPS Python package (python/lammps) to be installed
# and LAMMPS to be loadable as shared library in LD_LIBRARY_PATH # and LAMMPS to be loadable as shared library in LD_LIBRARY_PATH
import lammps import lammps

2
examples/SPIN/cobalt_hcp/in.spin.cobalt_hcp
View File

@ -26,7 +26,7 @@ velocity all create 100 4928459 rot yes dist gaussian
#pair_style hybrid/overlay eam/alloy spin/exchange 4.0 spin/neel 4.0 #pair_style hybrid/overlay eam/alloy spin/exchange 4.0 spin/neel 4.0
pair_style hybrid/overlay eam/alloy spin/exchange 4.0 pair_style hybrid/overlay eam/alloy spin/exchange 4.0
pair_coeff * * eam/alloy Co_PurjaPun_2012.eam.alloy Co pair_coeff * * eam/alloy Co_PurjaPun_2012.eam.alloy Co
pair_coeff * * spin/exchange exchange 4.0 -0.3593 1.135028015e-05 1.064568567 pair_coeff * * spin/exchange exchange 4.0 -0.3593 1.135028015e-05 1.0645 offset yes
#pair_coeff * * spin/neel neel 4.0 0.0048 0.234 1.168 2.6905 0.705 0.652 #pair_coeff * * spin/neel neel 4.0 0.0048 0.234 1.168 2.6905 0.705 0.652
neighbor 0.1 bin neighbor 0.1 bin

2
examples/SPIN/iron/in.spin.iron
View File

@ -25,7 +25,7 @@ velocity all create 100 4928459 rot yes dist gaussian
pair_style hybrid/overlay eam/alloy spin/exchange 3.5 pair_style hybrid/overlay eam/alloy spin/exchange 3.5
pair_coeff * * eam/alloy Fe_Mishin2006.eam.alloy Fe pair_coeff * * eam/alloy Fe_Mishin2006.eam.alloy Fe
pair_coeff * * spin/exchange exchange 3.4 0.02726 0.2171 1.841 pair_coeff * * spin/exchange exchange 3.4 0.02726 0.2171 1.841 offset yes
neighbor 0.1 bin neighbor 0.1 bin
neigh_modify every 10 check yes delay 20 neigh_modify every 10 check yes delay 20

4
examples/SPIN/iron/in.spin.iron_cubic
View File

@ -21,9 +21,9 @@ mass 1 55.845
set group all spin 2.2 -1.0 0.0 0.0 set group all spin 2.2 -1.0 0.0 0.0
velocity all create 100 4928459 rot yes dist gaussian velocity all create 100 4928459 rot yes dist gaussian
pair_style hybrid/overlay eam/alloy spin/exchange 3.5 pair_style hybrid/overlay eam/alloy spin/exchange/biquadratic 3.5
pair_coeff * * eam/alloy Fe_Mishin2006.eam.alloy Fe pair_coeff * * eam/alloy Fe_Mishin2006.eam.alloy Fe
pair_coeff * * spin/exchange exchange 3.4 0.02726 0.2171 1.841 pair_coeff * * spin/exchange/biquadratic biquadratic 3.4 0.02726 0.2171 1.841 0.0 0.0 2.0 offset yes
neighbor 0.1 bin neighbor 0.1 bin
neigh_modify every 10 check yes delay 20 neigh_modify every 10 check yes delay 20

20
examples/SPIN/test_problems/validation_damped_exchange/llg_exchange.py
View File

@ -6,9 +6,17 @@ import matplotlib.pyplot as plt
import mpmath as mp import mpmath as mp
hbar=0.658212 # Planck's constant (eV.fs/rad) hbar=0.658212 # Planck's constant (eV.fs/rad)
J0=0.05 # per-neighbor exchange interaction (eV) # J0=0.05 # per-neighbor exchange interaction (eV)
# exchange interaction parameters
J1 = 11.254 # in eV
J2 = 0.0 # adim
J3 = 1.0 # in Ang.
# initial spins
S1 = np.array([1.0, 0.0, 0.0]) S1 = np.array([1.0, 0.0, 0.0])
S2 = np.array([0.0, 1.0, 0.0]) S2 = np.array([0.0, 1.0, 0.0])
alpha=0.01 # damping coefficient alpha=0.01 # damping coefficient
pi=math.pi pi=math.pi
@ -30,6 +38,14 @@ def rotation_matrix(axis, theta):
[2 * (bc - ad), aa + cc - bb - dd, 2 * (cd + ab)], [2 * (bc - ad), aa + cc - bb - dd, 2 * (cd + ab)],
[2 * (bd + ac), 2 * (cd - ab), aa + dd - bb - cc]]) [2 * (bd + ac), 2 * (cd - ab), aa + dd - bb - cc]])
#Definition of the Bethe-Slater function
def func_BS(x,a,b,c):
return 4*a*((x/c)**2)*(1-b*(x/c)**2)*np.exp(-(x/c)**2)
#Definition of the derivative of the Bethe-Slater function
def func_dBS(x,a,b,c):
return 4*a*((x/c)**2)*(1-b*(x/c)**2)*np.exp(-(x/c)**2)
# calculating precession field of spin Sr # calculating precession field of spin Sr
def calc_rot_vector(Sr,Sf): def calc_rot_vector(Sr,Sf):
rot = (J0/hbar)*(Sf-alpha*np.cross(Sf,Sr))/(1.0+alpha**2) rot = (J0/hbar)*(Sf-alpha*np.cross(Sf,Sr))/(1.0+alpha**2)
@ -65,6 +81,6 @@ for t in range (0,N):
# calc. average magnetization # calc. average magnetization
Sm = (S1+S2)*0.5 Sm = (S1+S2)*0.5
# calc. energy # calc. energy
en = -2.0*J0*(np.dot(S1,S2)) en = -J0*(np.dot(S1,S2))
# print res. in ps for comparison with LAMMPS # print res. in ps for comparison with LAMMPS
print(t*dt/1000.0,Sm[0],Sm[1],Sm[2],en) print(t*dt/1000.0,Sm[0],Sm[1],Sm[2],en)

4
examples/SPIN/test_problems/validation_damped_exchange/run-test-exchange.sh
View File

@ -13,7 +13,7 @@ en="$(echo "$en-$in" | bc -l)"
tail -n +$in log.lammps | head -n $en > res_lammps.dat tail -n +$in log.lammps | head -n $en > res_lammps.dat
# compute Langevin # compute Langevin
python3 -m llg_exchange.py > res_llg.dat python3 llg_exchange.py > res_llg.dat
# plot results # plot results
python3 -m plot_precession.py res_lammps.dat res_llg.dat python3 plot_precession.py res_lammps.dat res_llg.dat

23
examples/SPIN/test_problems/validation_damped_exchange/test-spin-precession.in
View File

@ -5,22 +5,24 @@ atom_style spin
atom_modify map array atom_modify map array
boundary f f f boundary f f f
read_data two_spins.data atom_modify map array
lattice sc 3.0
region box block 0 2 0 1 0 1
create_box 1 box
create_atoms 1 box
mass 1 55.845
set atom 1 spin 2.0 1.0 0.0 0.0
set atom 2 spin 2.0 0.0 1.0 0.0
pair_style spin/exchange 3.1 pair_style spin/exchange 3.1
pair_coeff * * exchange 3.1 11.254 0.0 1.0 pair_coeff * * exchange 3.1 11.254 0.0 1.0
group bead type 1
variable H equal 0.0
variable Kan equal 0.0
variable Temperature equal 0.0 variable Temperature equal 0.0
variable RUN equal 30000 variable RUN equal 30000
fix 1 all nve/spin lattice no fix 1 all nve/spin lattice frozen
fix 2 all precession/spin zeeman ${H} 0.0 0.0 1.0 anisotropy ${Kan} 0.0 0.0 1.0 fix 2 all langevin/spin ${Temperature} 0.01 12345
fix_modify 2 energy yes
fix 3 all langevin/spin ${Temperature} 0.01 12345
compute out_mag all spin compute out_mag all spin
compute out_pe all pe compute out_pe all pe
@ -34,6 +36,9 @@ variable emag equal c_out_mag[5]
thermo_style custom step time v_magx v_magy v_magz v_emag pe etotal thermo_style custom step time v_magx v_magy v_magz v_emag pe etotal
thermo 10 thermo 10
compute outsp all property/atom spx spy spz sp fmx fmy fmz
dump 1 all custom 10 dump.data type x y z c_outsp[1] c_outsp[2] c_outsp[3] fx fy fz
timestep 0.0001 timestep 0.0001
run ${RUN} run ${RUN}

22
examples/SPIN/test_problems/validation_damped_exchange/two_spins.data
View File

@ -1,22 +0,0 @@
LAMMPS data file via write_data, version 19 Sep 2019, timestep = 0
2 atoms
1 atom types
0.0 6.0 xlo xhi
0.0 3.0 ylo yhi
0.0 3.0 zlo zhi
Masses
1 1
Atoms # spin
1 1 2.0 0.0 0.0 0.0 1.0 0.0 0.0 0 0 0
2 1 2.0 3.0 0.0 0.0 0.0 1.0 0.0 0 0 0
Velocities
1 0.0 0.0 0.0
2 0.0 0.0 0.0

2
examples/SPIN/test_problems/validation_nve/run-test-nve.sh
View File

@ -13,4 +13,4 @@ en="$(echo "$en-$in" | bc -l)"
tail -n +$in log.lammps | head -n $en > res_lammps.dat tail -n +$in log.lammps | head -n $en > res_lammps.dat
# plot results # plot results
python3 -m plot_nve.py res_lammps.dat res_llg.dat python3 plot_nve.py res_lammps.dat res_llg.dat

2
examples/SPIN/test_problems/validation_nvt/in.spin.nvt_lattice
View File

@ -30,7 +30,7 @@ neighbor 0.1 bin
neigh_modify every 10 check yes delay 20 neigh_modify every 10 check yes delay 20
fix 1 all precession/spin zeeman 0.0 0.0 0.0 1.0 fix 1 all precession/spin zeeman 0.0 0.0 0.0 1.0
fix 2 all langevin 200.0 200.0 10.0 48279 fix 2 all langevin 200.0 200.0 1.0 48279
fix 3 all langevin/spin 0.0 0.00001 321 fix 3 all langevin/spin 0.0 0.00001 321
fix 4 all nve/spin lattice moving fix 4 all nve/spin lattice moving
timestep 0.001 timestep 0.001

2
examples/SPIN/test_problems/validation_nvt/in.spin.nvt_spin
View File

@ -29,7 +29,7 @@ neighbor 0.1 bin
neigh_modify every 10 check yes delay 20 neigh_modify every 10 check yes delay 20
fix 1 all precession/spin zeeman 0.0 0.0 0.0 1.0 fix 1 all precession/spin zeeman 0.0 0.0 0.0 1.0
fix 2 all langevin/spin 200.0 0.1 321 fix 2 all langevin/spin 200.0 0.01 321
fix 3 all nve/spin lattice moving fix 3 all nve/spin lattice moving
timestep 0.001 timestep 0.001

2
examples/SPIN/test_problems/validation_nvt/plot_nvt.py
View File

@ -39,5 +39,5 @@ plt.xlabel('Time (in ps)')
plt.legend() plt.legend()
plt.show() plt.show()
fig.savefig(os.path.join(os.getcwd(), "nve_spin_lattice.pdf"), bbox_inches="tight") fig.savefig(os.path.join(os.getcwd(), "nvt_spin_lattice.pdf"), bbox_inches="tight")
plt.close(fig) plt.close(fig)

38
examples/USER/misc/electron_stopping/in.cascade_AlCu Normal file
View File

@ -0,0 +1,38 @@
# ***
# Example input for including electronic stopping effects using fix electron/stopping/fit
# Al lattice with a single incident Cu atom - multiple species simulation
# ***
units metal
boundary p p p
lattice fcc 4.0495
region box block -10 10 -10 10 -10 10
create_box 2 box
create_atoms 1 box
pair_style eam/alloy
pair_coeff * * ../../../../potentials/AlCu.eam.alloy Al Cu
mass 1 26.982
mass 2 63.546
velocity all create 300 42534 mom yes rot yes
set atom 1 type 2
group pka id 1
velocity pka set 1120 1620 400
fix 1 all nve
fix 2 all dt/reset 1 NULL 0.001 0.05 emax 10.0
fix 3 all electron/stopping/fit 3.49 1.8e-3 9.0e-8 7.57 4.2e-3 5.0e-8
thermo 5
thermo_style custom step dt time temp pe ke f_3
thermo_modify lost warn flush yes
#dump 0 all custom 10 dump.pka_* id type x y z vx vy vz fx fy fz
#dump_modify 0 first yes
run 100

36
examples/USER/misc/electron_stopping/in.cascade_SiSi Normal file
View File

@ -0,0 +1,36 @@
# ***
# Example input for including electronic stopping effects using fix electron/stopping/fit
# Si lattice with one primary knock-on atom (PKA) - single species simulation
# ***
units metal
boundary p p p
lattice diamond 5.431
region box block -10 10 -10 10 -10 10
create_box 1 box
create_atoms 1 box
pair_style tersoff/zbl
pair_coeff * * ../../../../potentials/SiC.tersoff.zbl Si
mass 1 28.0855
velocity all create 300 42534 mom yes rot yes
group pka id 1
velocity pka set 1120 1620 400
fix 1 all nve
fix 2 all dt/reset 1 NULL 0.001 0.05 emax 10.0
fix 3 all electron/stopping/fit 4.63 3.3e-3 4.0e-8
thermo 5
thermo_style custom step dt time temp pe ke f_3
thermo_modify lost warn flush yes
#dump 0 all custom 10 dump.pka_* id type x y z vx vy vz fx fy fz
#dump_modify 0 first yes
run 100

115
examples/USER/misc/electron_stopping/log.18Sep2020.cascade_AlCu.intel.1 Normal file
View File

@ -0,0 +1,115 @@
LAMMPS (18 Sep 2020)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:94)
using 1 OpenMP thread(s) per MPI task
# ***
# Example input for including electronic stopping effects using fix electron/stopping/fit
# Al lattice with a single incident Cu atom - multiple species simulation
# ***
units metal
boundary p p p
lattice fcc 4.0495
Lattice spacing in x,y,z = 4.0495000 4.0495000 4.0495000
region box block -10 10 -10 10 -10 10
create_box 2 box
Created orthogonal box = (-40.495000 -40.495000 -40.495000) to (40.495000 40.495000 40.495000)
1 by 1 by 1 MPI processor grid
create_atoms 1 box
Created 32000 atoms
create_atoms CPU = 0.004 seconds
pair_style eam/alloy
pair_coeff * * ../../../../potentials/AlCu.eam.alloy Al Cu
Reading eam/alloy potential file ../../../../potentials/AlCu.eam.alloy with DATE: 2008-10-01
mass 1 26.982
mass 2 63.546
velocity all create 300 42534 mom yes rot yes
set atom 1 type 2
Setting atom values ...
1 settings made for type
group pka id 1
1 atoms in group pka
velocity pka set 1120 1620 400
fix 1 all nve
fix 2 all dt/reset 1 NULL 0.001 0.05 emax 10.0
fix 3 all electron/stopping/fit 3.49 1.8e-3 9.0e-8 7.57 4.2e-3 5.0e-8
thermo 5
thermo_style custom step dt time temp pe ke f_3
thermo_modify lost warn flush yes
#dump 0 all custom 10 dump.pka_* id type x y z vx vy vz fx fy fz
#dump_modify 0 first yes
run 100
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 8.6825
ghost atom cutoff = 8.6825
binsize = 4.34125, bins = 19 19 19
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair eam/alloy, perpetual
attributes: half, newton on
pair build: half/bin/atomonly/newton
stencil: half/bin/3d/newton
bin: standard
Per MPI rank memory allocation (min/avg/max) = 23.27 | 23.27 | 23.27 Mbytes
Step Dt Time Temp PotEng KinEng f_3
0 2.4879625e-05 0 53029.167 -106186.96 219339 0
5 2.4881895e-05 0.00012440247 53019.542 -106184.2 219299.18 36.968257
10 1.0341799e-05 0.00021830163 53006.803 -106159.67 219246.49 64.866504
15 5.6753071e-06 0.0002583636 52996.09 -106127.26 219202.18 76.766363
20 4.0862476e-06 0.0002830119 52987.566 -106099.31 219166.93 84.086344
25 3.3677164e-06 0.00030179992 52980.99 -106077.67 219139.73 89.665096
30 3.0218093e-06 0.00031784053 52976.302 -106063.03 219120.34 94.427505
35 2.8935922e-06 0.00033262008 52973.489 -106055.77 219108.7 98.815168
40 2.9394209e-06 0.00034711037 52972.541 -106056.15 219104.78 103.11678
45 3.1822694e-06 0.00036220043 52973.425 -106064.3 219108.44 107.59642
50 3.743784e-06 0.00037905999 52976.072 -106080.26 219119.38 112.60152
55 5.0685177e-06 0.0003999287 52980.344 -106104.15 219137.05 118.79722
60 1.0189784e-05 0.00043198334 52985.861 -106136.52 219159.88 128.31484
65 1.8636384e-05 0.00052946777 52985.275 -106162.53 219157.45 157.2625
70 1.844772e-05 0.00061001061 52977.927 -106155.89 219127.06 181.17691
75 2.4893022e-05 0.00072690857 52972.391 -106168.08 219104.16 215.88136
80 7.390618e-06 0.00081149431 52959.379 -106139.89 219050.34 240.98969
85 4.1547853e-06 0.00084037647 52948.078 -106101.74 219003.59 249.56079
90 2.9763749e-06 0.00085843347 52938.03 -106065.54 218962.03 254.91825
95 2.3727508e-06 0.00087197081 52929.043 -106032.37 218924.86 258.93397
100 2.0138478e-06 0.00088304936 52921.103 -106002.81 218892.02 262.21977
Loop time of 9.53154 on 1 procs for 100 steps with 32000 atoms
Performance: 0.002 ns/day, 13147.213 hours/ns, 10.491 timesteps/s
99.7% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 8.815 | 8.815 | 8.815 | 0.0 | 92.48
Neigh | 0.38408 | 0.38408 | 0.38408 | 0.0 | 4.03
Comm | 0.029049 | 0.029049 | 0.029049 | 0.0 | 0.30
Output | 0.0025912 | 0.0025912 | 0.0025912 | 0.0 | 0.03
Modify | 0.28624 | 0.28624 | 0.28624 | 0.0 | 3.00
Other | | 0.01456 | | | 0.15
Nlocal: 32000.0 ave 32000 max 32000 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 26825.0 ave 26825 max 26825 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 2.81599e+06 ave 2.81599e+06 max 2.81599e+06 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 2815993
Ave neighs/atom = 87.999781
Neighbor list builds = 5
Dangerous builds = 3
Please see the log.cite file for references relevant to this simulation
Total wall time: 0:00:09

115
examples/USER/misc/electron_stopping/log.18Sep2020.cascade_AlCu.intel.4 Normal file
View File

@ -0,0 +1,115 @@
LAMMPS (18 Sep 2020)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:94)
using 1 OpenMP thread(s) per MPI task
# ***
# Example input for including electronic stopping effects using fix electron/stopping/fit
# Al lattice with a single incident Cu atom - multiple species simulation
# ***
units metal
boundary p p p
lattice fcc 4.0495
Lattice spacing in x,y,z = 4.0495000 4.0495000 4.0495000
region box block -10 10 -10 10 -10 10
create_box 2 box
Created orthogonal box = (-40.495000 -40.495000 -40.495000) to (40.495000 40.495000 40.495000)
1 by 2 by 2 MPI processor grid
create_atoms 1 box
Created 32000 atoms
create_atoms CPU = 0.001 seconds
pair_style eam/alloy
pair_coeff * * ../../../../potentials/AlCu.eam.alloy Al Cu
Reading eam/alloy potential file ../../../../potentials/AlCu.eam.alloy with DATE: 2008-10-01
mass 1 26.982
mass 2 63.546
velocity all create 300 42534 mom yes rot yes
set atom 1 type 2
Setting atom values ...
1 settings made for type
group pka id 1
1 atoms in group pka
velocity pka set 1120 1620 400
fix 1 all nve
fix 2 all dt/reset 1 NULL 0.001 0.05 emax 10.0
fix 3 all electron/stopping/fit 3.49 1.8e-3 9.0e-8 7.57 4.2e-3 5.0e-8
thermo 5
thermo_style custom step dt time temp pe ke f_3
thermo_modify lost warn flush yes
#dump 0 all custom 10 dump.pka_* id type x y z vx vy vz fx fy fz
#dump_modify 0 first yes
run 100
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 8.6825
ghost atom cutoff = 8.6825
binsize = 4.34125, bins = 19 19 19
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair eam/alloy, perpetual
attributes: half, newton on
pair build: half/bin/atomonly/newton
stencil: half/bin/3d/newton
bin: standard
Per MPI rank memory allocation (min/avg/max) = 9.014 | 9.014 | 9.014 Mbytes
Step Dt Time Temp PotEng KinEng f_3
0 2.4879625e-05 0 53029.167 -106186.96 219339 0
5 2.4881895e-05 0.00012440247 53019.542 -106184.2 219299.18 36.968257
10 1.0341742e-05 0.00021830123 53006.803 -106159.67 219246.49 64.866388
15 5.6752732e-06 0.00025836298 52996.09 -106127.26 219202.18 76.76618
20 4.0862174e-06 0.00028301112 52987.566 -106099.31 219166.93 84.086114
25 3.3676848e-06 0.00030179899 52980.99 -106077.67 219139.73 89.664821
30 3.021773e-06 0.00031783944 52976.302 -106063.02 219120.33 94.427181
35 2.8935472e-06 0.00033261879 52973.489 -106055.77 219108.7 98.814784
40 2.9393606e-06 0.00034710883 52972.541 -106056.15 219104.78 103.11632
45 3.1821803e-06 0.00036219854 52973.425 -106064.29 219108.43 107.59586
50 3.7436309e-06 0.00037905755 52976.071 -106080.26 219119.38 112.60079
55 5.0681667e-06 0.0003999252 52980.343 -106104.15 219137.05 118.79618
60 1.0187808e-05 0.00043197649 52985.861 -106136.51 219159.87 128.3128
65 1.8643099e-05 0.00052944037 52985.278 -106162.53 219157.46 157.25436
70 1.8445045e-05 0.00060999223 52977.928 -106155.89 219127.06 181.17146
75 2.4893021e-05 0.00072688076 52972.393 -106168.08 219104.17 215.8731
80 7.3916674e-06 0.0008114874 52959.382 -106139.9 219050.35 240.98764
85 4.1550998e-06 0.00084037284 52948.08 -106101.75 219003.6 249.55971
90 2.976545e-06 0.00085843108 52938.032 -106065.55 218962.04 254.91754
95 2.3728646e-06 0.00087196913 52929.045 -106032.38 218924.87 258.93348
100 2.0139362e-06 0.00088304819 52921.106 -106002.82 218892.03 262.21943
Loop time of 2.45676 on 4 procs for 100 steps with 32000 atoms
Performance: 0.007 ns/day, 3388.559 hours/ns, 40.704 timesteps/s
99.8% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 2.2127 | 2.2257 | 2.2399 | 0.8 | 90.59
Neigh | 0.095856 | 0.097842 | 0.10197 | 0.8 | 3.98
Comm | 0.03626 | 0.054908 | 0.069787 | 6.3 | 2.23
Output | 0.00088538 | 0.0011005 | 0.0017236 | 1.1 | 0.04
Modify | 0.072449 | 0.072553 | 0.072611 | 0.0 | 2.95
Other | | 0.004684 | | | 0.19
Nlocal: 8000.00 ave 8033 max 7977 min
Histogram: 1 0 1 1 0 0 0 0 0 1
Nghost: 12605.0 ave 12628 max 12572 min
Histogram: 1 0 0 0 0 0 1 1 0 1
Neighs: 703998.0 ave 706570 max 702282 min
Histogram: 1 1 0 0 1 0 0 0 0 1
Total # of neighbors = 2815992
Ave neighs/atom = 87.999750
Neighbor list builds = 5
Dangerous builds = 3
Please see the log.cite file for references relevant to this simulation
Total wall time: 0:00:02

113
examples/USER/misc/electron_stopping/log.18Sep2020.cascade_SiSi.intel.1 Normal file
View File

@ -0,0 +1,113 @@
LAMMPS (18 Sep 2020)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:94)
using 1 OpenMP thread(s) per MPI task
# ***
# Example input for including electronic stopping effects using fix electron/stopping/fit
# Si lattice with one primary knock-on atom (PKA) - single species simulation
# ***
units metal
boundary p p p
lattice diamond 5.431
Lattice spacing in x,y,z = 5.4310000 5.4310000 5.4310000
region box block -10 10 -10 10 -10 10
create_box 1 box
Created orthogonal box = (-54.310000 -54.310000 -54.310000) to (54.310000 54.310000 54.310000)
1 by 1 by 1 MPI processor grid
create_atoms 1 box
Created 64000 atoms
create_atoms CPU = 0.008 seconds
pair_style tersoff/zbl
pair_coeff * * ../../../../potentials/SiC.tersoff.zbl Si
Reading tersoff/zbl potential file ../../../../potentials/SiC.tersoff.zbl with DATE: 2009-04-15
mass 1 28.0855
velocity all create 300 42534 mom yes rot yes
group pka id 1
1 atoms in group pka
velocity pka set 1120 1620 400
fix 1 all nve
fix 2 all dt/reset 1 NULL 0.001 0.05 emax 10.0
fix 3 all electron/stopping/fit 4.63 3.3e-3 4.0e-8
thermo 5
thermo_style custom step dt time temp pe ke f_3
thermo_modify lost warn flush yes
#dump 0 all custom 10 dump.pka_* id type x y z vx vy vz fx fy fz
#dump_modify 0 first yes
run 100
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 5
ghost atom cutoff = 5
binsize = 2.5, bins = 44 44 44
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair tersoff/zbl, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 23.91 | 23.91 | 23.91 Mbytes
Step Dt Time Temp PotEng KinEng f_3
0 2.4879625e-05 0 21258.724 -296293.96 175863.22 0
5 9.2462185e-06 9.0354398e-05 21252.059 -296277.65 175808.08 38.834393
10 6.1558479e-06 0.00013003059 21246.736 -296250.63 175764.05 55.881868
15 4.9002335e-06 0.00015681379 21242.649 -296228.27 175730.24 67.386915
20 5.853687e-06 0.00018286317 21239.571 -296213.99 175704.78 78.574676
25 7.0182823e-06 0.00021483214 21237.286 -296208.81 175685.87 92.303028
30 8.2570048e-06 0.00025083646 21236.034 -296213.99 175675.52 107.76296
35 6.4734302e-06 0.00029194185 21233.473 -296210.33 175654.33 125.41212
40 7.3445302e-06 0.00032561085 21231.196 -296205.94 175635.5 139.86641
45 6.9480705e-06 0.00036268325 21230.21 -296213.68 175627.33 155.78046
50 7.2224188e-06 0.00039655436 21230.512 -296230.74 175629.84 170.32001
55 1.0773409e-05 0.00044221823 21230.023 -296246.37 175625.79 189.92217
60 5.7527075e-06 0.00048339879 21226.064 -296231.33 175593.04 207.5982
65 5.8568503e-06 0.0005110075 21222.544 -296213.97 175563.92 219.44643
70 6.7430644e-06 0.00054252027 21220.179 -296207.92 175544.35 232.96808
75 7.0523029e-06 0.00057648256 21219.781 -296219.19 175541.06 247.53974
80 1.784394e-05 0.00062210154 21221.276 -296251.35 175553.43 267.11364
85 2.1885193e-05 0.0007395532 21218.037 -296274.94 175526.64 317.50995
90 8.233509e-06 0.00081518257 21211.247 -296251.53 175470.47 349.95382
95 5.1490725e-06 0.00084789415 21205.33 -296216.55 175421.52 363.982
100 5.7628664e-06 0.0008764946 21200.168 -296186.27 175378.81 376.24357
Loop time of 20.4868 on 1 procs for 100 steps with 64000 atoms
Performance: 0.002 ns/day, 9874.909 hours/ns, 4.881 timesteps/s
99.8% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 19.397 | 19.397 | 19.397 | 0.0 | 94.68
Neigh | 0.45332 | 0.45332 | 0.45332 | 0.0 | 2.21
Comm | 0.035144 | 0.035144 | 0.035144 | 0.0 | 0.17
Output | 0.0040397 | 0.0040397 | 0.0040397 | 0.0 | 0.02
Modify | 0.5739 | 0.5739 | 0.5739 | 0.0 | 2.80
Other | | 0.0229 | | | 0.11
Nlocal: 64000.0 ave 64000 max 64000 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 18341.0 ave 18341 max 18341 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 0.00000 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 1.79199e+06 ave 1.79199e+06 max 1.79199e+06 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 1791990
Ave neighs/atom = 27.999844
Neighbor list builds = 7
Dangerous builds = 2
Please see the log.cite file for references relevant to this simulation
Total wall time: 0:00:20

113
examples/USER/misc/electron_stopping/log.18Sep2020.cascade_SiSi.intel.4 Normal file
View File

@ -0,0 +1,113 @@
LAMMPS (18 Sep 2020)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:94)
using 1 OpenMP thread(s) per MPI task
# ***
# Example input for including electronic stopping effects using fix electron/stopping/fit
# Si lattice with one primary knock-on atom (PKA) - single species simulation
# ***
units metal
boundary p p p
lattice diamond 5.431
Lattice spacing in x,y,z = 5.4310000 5.4310000 5.4310000
region box block -10 10 -10 10 -10 10
create_box 1 box
Created orthogonal box = (-54.310000 -54.310000 -54.310000) to (54.310000 54.310000 54.310000)
1 by 2 by 2 MPI processor grid
create_atoms 1 box
Created 64000 atoms
create_atoms CPU = 0.003 seconds
pair_style tersoff/zbl
pair_coeff * * ../../../../potentials/SiC.tersoff.zbl Si
Reading tersoff/zbl potential file ../../../../potentials/SiC.tersoff.zbl with DATE: 2009-04-15
mass 1 28.0855
velocity all create 300 42534 mom yes rot yes
group pka id 1
1 atoms in group pka
velocity pka set 1120 1620 400
fix 1 all nve
fix 2 all dt/reset 1 NULL 0.001 0.05 emax 10.0
fix 3 all electron/stopping/fit 4.63 3.3e-3 4.0e-8
thermo 5
thermo_style custom step dt time temp pe ke f_3
thermo_modify lost warn flush yes
#dump 0 all custom 10 dump.pka_* id type x y z vx vy vz fx fy fz
#dump_modify 0 first yes
run 100
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 5
ghost atom cutoff = 5
binsize = 2.5, bins = 44 44 44
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair tersoff/zbl, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 7.777 | 7.777 | 7.777 Mbytes
Step Dt Time Temp PotEng KinEng f_3
0 2.4879625e-05 0 21258.724 -296293.96 175863.22 0
5 9.2462211e-06 9.0354422e-05 21252.059 -296277.66 175808.08 38.834403
10 6.1568847e-06 0.00013003069 21246.736 -296250.63 175764.05 55.881913
15 4.8997821e-06 0.00015681555 21242.649 -296228.27 175730.24 67.387669
20 5.8536714e-06 0.00018286203 21239.571 -296213.99 175704.78 78.574187
25 7.0160073e-06 0.00021483347 21237.285 -296208.8 175685.86 92.303599
30 8.2556386e-06 0.00025082046 21236.035 -296213.99 175675.53 107.75609
35 6.4735852e-06 0.00029193023 21233.474 -296210.34 175654.34 125.40713
40 7.3441556e-06 0.00032559783 21231.197 -296205.94 175635.5 139.86082
45 6.9483099e-06 0.00036267022 21230.21 -296213.68 175627.34 155.77487
50 7.2213562e-06 0.0003965413 21230.513 -296230.74 175629.84 170.31441
55 1.0776037e-05 0.00044219672 21230.024 -296246.38 175625.8 189.91293
60 5.7538246e-06 0.0004833796 21226.067 -296231.34 175593.06 207.58996
65 5.856213e-06 0.00051099409 21222.546 -296213.98 175563.94 219.44067
70 6.7431217e-06 0.00054250526 21220.18 -296207.92 175544.37 232.96164
75 7.0518411e-06 0.00057646788 21219.781 -296219.18 175541.07 247.53344
80 1.7829072e-05 0.00062207162 21221.276 -296251.34 175553.43 267.1008
85 2.1894958e-05 0.0007395084 21218.04 -296274.95 175526.66 317.49073
90 8.2365472e-06 0.00081516502 21211.25 -296251.55 175470.49 349.94629
95 5.1493496e-06 0.00084788428 21205.333 -296216.57 175421.54 363.97777
100 5.7652664e-06 0.00087648406 21200.171 -296186.3 175378.84 376.23905
Loop time of 5.23182 on 4 procs for 100 steps with 64000 atoms
Performance: 0.010 ns/day, 2520.759 hours/ns, 19.114 timesteps/s
99.7% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 4.8069 | 4.8618 | 4.9229 | 2.0 | 92.93
Neigh | 0.11442 | 0.11856 | 0.12948 | 1.8 | 2.27
Comm | 0.040943 | 0.098988 | 0.15807 | 14.7 | 1.89
Output | 0.0013075 | 0.0014801 | 0.0019936 | 0.8 | 0.03
Modify | 0.14496 | 0.14502 | 0.1451 | 0.0 | 2.77
Other | | 0.005981 | | | 0.11
Nlocal: 16000.0 ave 16017 max 15987 min
Histogram: 1 0 1 0 0 1 0 0 0 1
Nghost: 8044.00 ave 8058 max 8026 min
Histogram: 1 0 0 0 1 0 0 0 1 1
Neighs: 0.00000 ave 0 max 0 min
Histogram: 4 0 0 0 0 0 0 0 0 0
FullNghs: 447998.0 ave 448471 max 447634 min
Histogram: 1 0 1 0 0 1 0 0 0 1
Total # of neighbors = 1791990
Ave neighs/atom = 27.999844
Neighbor list builds = 7
Dangerous builds = 2
Please see the log.cite file for references relevant to this simulation
Total wall time: 0:00:05

2
examples/USER/reaction/nylon,6-6_melt/rxn1_stp1_map
View File

@ -3,7 +3,7 @@ this is a nominal superimpose file
2 edgeIDs 2 edgeIDs
18 equivalences 18 equivalences
BondingIDs InitiatorIDs
10 10
1 1

2
examples/USER/reaction/nylon,6-6_melt/rxn1_stp2_map
View File

@ -3,7 +3,7 @@ this is a nominal superimpose file
2 edgeIDs 2 edgeIDs
15 equivalences 15 equivalences
BondingIDs InitiatorIDs
4 4
12 12

2
examples/USER/reaction/tiny_epoxy/rxn1_stp1.map
View File

@ -3,7 +3,7 @@ this is a map file
1 edgeIDs 1 edgeIDs
31 equivalences 31 equivalences
BondingIDs InitiatorIDs
15 15
1 1

2
examples/USER/reaction/tiny_epoxy/rxn1_stp2.map
View File

@ -3,7 +3,7 @@ this is a map file
1 edgeIDs 1 edgeIDs
31 equivalences 31 equivalences
BondingIDs InitiatorIDs
4 4
25 25

2
examples/USER/reaction/tiny_epoxy/rxn2_stp1.map
View File

@ -3,7 +3,7 @@ this is a map file
2 edgeIDs 2 edgeIDs
42 equivalences 42 equivalences
BondingIDs InitiatorIDs
15 15
32 32

2
examples/USER/reaction/tiny_epoxy/rxn2_stp2.map
View File

@ -3,7 +3,7 @@ this is a map file
2 edgeIDs 2 edgeIDs
42 equivalences 42 equivalences
BondingIDs InitiatorIDs
35 35
24 24

2
examples/USER/reaction/tiny_nylon/rxn1_stp1_map
View File

@ -3,7 +3,7 @@ this is a nominal superimpose file
2 edgeIDs 2 edgeIDs
18 equivalences 18 equivalences
BondingIDs InitiatorIDs
10 10
1 1

2
examples/USER/reaction/tiny_nylon/rxn1_stp2_map
View File

@ -3,7 +3,7 @@ this is a nominal superimpose file
2 edgeIDs 2 edgeIDs
15 equivalences 15 equivalences
BondingIDs InitiatorIDs
4 4
12 12

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