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

Merge branch 'develop' into type-labels

Browse Source
This commit is contained in:
Jacob Gissinger
2022-08-08 17:16:50 -04:00
committed by GitHub
parent e13a70ad2f fb2dd26d45
commit f9717049b1
4100 changed files with 378596 additions and 127634 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
doc/src/Build_development.rst
View File

@ -486,14 +486,14 @@ The following options are available.
make fix-whitespace # correct whitespace issues in files
make check-homepage # search for files with old LAMMPS homepage URLs
make fix-homepage # correct LAMMPS homepage URLs in files
make check-errordocs # search for deprecated error docs in header files
make fix-errordocs # remove error docs in header files
make check-permissions # search for files with permissions issues
make fix-permissions # correct permissions issues in files
make check # run all check targets from above
These should help to replace all TAB characters with blanks and remove
any trailing whitespace. Also all LAMMPS homepage URL references can be
updated to the location change from Sandia to the lammps.org domain.
And the permission check can remove executable permissions from non-executable
files (like source code).
These should help to make source and documentation files conforming
to some the coding style preferences of the LAMMPS developers.
Clang-format support
--------------------

177
doc/src/Build_extras.rst
View File

@ -45,7 +45,6 @@ This is the list of packages that may require additional steps.
* :ref:`MACHDYN <machdyn>`
* :ref:`MDI <mdi>`
* :ref:`MESONT <mesont>`
* :ref:`MESSAGE <message>`
* :ref:`ML-HDNNP <ml-hdnnp>`
* :ref:`ML-IAP <mliap>`
* :ref:`ML-PACE <ml-pace>`
@ -124,6 +123,7 @@ CMake build
-D GPU_API=value # value = opencl (default) or cuda or hip
-D GPU_PREC=value # precision setting
# value = double or mixed (default) or single
-D HIP_PATH # path to HIP installation. Must be set if GPU_API=HIP
-D GPU_ARCH=value # primary GPU hardware choice for GPU_API=cuda
# value = sm_XX, see below
# default is sm_50
@ -142,8 +142,6 @@ CMake build
:code:`GPU_ARCH` settings for different GPU hardware is as follows:
* sm_12 or sm_13 for GT200 (supported by CUDA 3.2 until CUDA 6.5)
* sm_20 or sm_21 for Fermi (supported by CUDA 3.2 until CUDA 7.5)
* sm_30 for Kepler (supported since CUDA 5 and until CUDA 10.x)
* sm_35 or sm_37 for Kepler (supported since CUDA 5 and until CUDA 11.x)
* sm_50 or sm_52 for Maxwell (supported since CUDA 6)
@ -161,6 +159,12 @@ Thus the GPU_ARCH setting is merely an optimization, to have code for
the preferred GPU architecture directly included rather than having to wait
for the JIT compiler of the CUDA driver to translate it.
When compiling for CUDA or HIP with CUDA, version 8.0 or later of the CUDA toolkit
is required and a GPU architecture of Kepler or later, which must *also* be
supported by the CUDA toolkit in use **and** the CUDA driver in use.
When compiling for OpenCL, OpenCL version 1.2 or later is required and the
GPU must be supported by the GPU driver and OpenCL runtime bundled with the driver.
When building with CMake, you **must NOT** build the GPU library in ``lib/gpu``
using the traditional build procedure. CMake will detect files generated by that
process and will terminate with an error and a suggestion for how to remove them.
@ -176,10 +180,17 @@ set appropriate environment variables. Some variables such as
:code:`HCC_AMDGPU_TARGET` (for ROCm <= 4.0) or :code:`CUDA_PATH` are necessary for :code:`hipcc`
and the linker to work correctly.
Using CHIP-SPV implementation of HIP is now supported. It allows one to run HIP
code on Intel GPUs via the OpenCL or Level Zero backends. To use CHIP-SPV, you must
set :code:`-DHIP_USE_DEVICE_SORT=OFF` in your CMake command line as CHIP-SPV does not
yet support hipCUB. The use of HIP for Intel GPUs is still experimental so you
should only use this option in preparations to run on Aurora system at ANL.
.. code:: bash
# AMDGPU target (ROCm <= 4.0)
export HIP_PLATFORM=hcc
export HIP_PATH=/path/to/HIP/install
export HCC_AMDGPU_TARGET=gfx906
cmake -D PKG_GPU=on -D GPU_API=HIP -D HIP_ARCH=gfx906 -D CMAKE_CXX_COMPILER=hipcc ..
make -j 4
@ -188,6 +199,7 @@ and the linker to work correctly.
# AMDGPU target (ROCm >= 4.1)
export HIP_PLATFORM=amd
export HIP_PATH=/path/to/HIP/install
cmake -D PKG_GPU=on -D GPU_API=HIP -D HIP_ARCH=gfx906 -D CMAKE_CXX_COMPILER=hipcc ..
make -j 4
@ -196,10 +208,20 @@ and the linker to work correctly.
# CUDA target (not recommended, use GPU_ARCH=cuda)
# !!! DO NOT set CMAKE_CXX_COMPILER !!!
export HIP_PLATFORM=nvcc
export HIP_PATH=/path/to/HIP/install
export CUDA_PATH=/usr/local/cuda
cmake -D PKG_GPU=on -D GPU_API=HIP -D HIP_ARCH=sm_70 ..
make -j 4
.. code:: bash
# SPIR-V target (Intel GPUs)
export HIP_PLATFORM=spirv
export HIP_PATH=/path/to/HIP/install
export CMAKE_CXX_COMPILER=<hipcc/clang++>
cmake -D PKG_GPU=on -D GPU_API=HIP ..
make -j 4
Traditional make
^^^^^^^^^^^^^^^^
@ -638,13 +660,27 @@ This list was last updated for version 3.5.0 of the Kokkos library.
-D CMAKE_CXX_COMPILER=${HOME}/lammps/lib/kokkos/bin/nvcc_wrapper
To simplify compilation, three preset files are included in the
For AMD or NVIDIA GPUs using HIP, set these variables:
.. code-block:: bash
-D Kokkos_ARCH_HOSTARCH=yes # HOSTARCH = HOST from list above
-D Kokkos_ARCH_GPUARCH=yes # GPUARCH = GPU from list above
-D Kokkos_ENABLE_HIP=yes
-D Kokkos_ENABLE_OPENMP=yes
This will enable FFTs on the GPU, either by the internal KISSFFT library
or with the hipFFT wrapper library, which will call out to the
platform-appropriate vendor library: rocFFT on AMD GPUs or cuFFT on
NVIDIA GPUs.
To simplify compilation, five preset files are included in the
``cmake/presets`` folder, ``kokkos-serial.cmake``,
``kokkos-openmp.cmake``, and ``kokkos-cuda.cmake``. They will
enable the KOKKOS package and enable some hardware choice. So to
compile with OpenMP host parallelization, CUDA device
parallelization (for GPUs with CC 5.0 and up) with some common
packages enabled, you can do the following:
``kokkos-openmp.cmake``, ``kokkos-cuda.cmake``,
``kokkos-hip.cmake``, and ``kokkos-sycl.cmake``. They will enable
the KOKKOS package and enable some hardware choice. So to compile
with CUDA device parallelization (for GPUs with CC 5.0 and up)
with some common packages enabled, you can do the following:
.. code-block:: bash
@ -703,6 +739,15 @@ This list was last updated for version 3.5.0 of the Kokkos library.
KOKKOS_ABSOLUTE_PATH = $(shell cd $(KOKKOS_PATH); pwd)
CC = mpicxx -cxx=$(KOKKOS_ABSOLUTE_PATH)/config/nvcc_wrapper
For AMD or NVIDIA GPUs using HIP:
.. code-block:: make
KOKKOS_DEVICES = HIP
KOKKOS_ARCH = HOSTARCH,GPUARCH # HOSTARCH = HOST from list above that is hosting the GPU
# GPUARCH = GPU from list above
FFT_INC = -DFFT_HIPFFT # enable use of hipFFT (optional)
FFT_LIB = -lhipfft # link to hipFFT library
Advanced KOKKOS compilation settings
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -762,8 +807,10 @@ library.
.. code-block:: bash
-D DOWNLOAD_LATTE=value # download LATTE for build, value = no (default) or yes
-D LATTE_LIBRARY=path # LATTE library file (only needed if a custom location)
-D DOWNLOAD_LATTE=value # download LATTE for build, value = no (default) or yes
-D LATTE_LIBRARY=path # LATTE library file (only needed if a custom location)
-D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
# value = no (default) or yes
If ``DOWNLOAD_LATTE`` is set, the LATTE library will be downloaded
and built inside the CMake build directory. If the LATTE library
@ -771,6 +818,13 @@ library.
``LATTE_LIBRARY`` is the filename (plus path) of the LATTE library
file, not the directory the library file is in.
The LATTE library requires LAPACK (and BLAS) and CMake can identify
their locations and pass that info to the LATTE build script. But
on some systems this triggers a (current) limitation of CMake and
the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
those cases to use the bundled linear algebra library and work around
the limitation.
.. tab:: Traditional make
You can download and build the LATTE library manually if you
@ -796,47 +850,6 @@ library.
----------
.. _message:
MESSAGE package
-----------------------------
This package can optionally include support for messaging via sockets,
using the open-source `ZeroMQ library <http://zeromq.org>`_, which must
be installed on your system.
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D MESSAGE_ZMQ=value # build with ZeroMQ support, value = no (default) or yes
-D ZMQ_LIBRARY=path # ZMQ library file (only needed if a custom location)
-D ZMQ_INCLUDE_DIR=path # ZMQ include directory (only needed if a custom location)
.. tab:: Traditional make
Before building LAMMPS, you must build the CSlib library in
``lib/message``\ . You can build the CSlib library manually if
you prefer; follow the instructions in ``lib/message/README``\ .
You can also do it in one step from the ``lammps/src`` dir, using
a command like these, which simply invoke the
``lib/message/Install.py`` script with the specified args:
.. code-block:: bash
$ make lib-message # print help message
$ make lib-message args="-m -z" # build with MPI and socket (ZMQ) support
$ make lib-message args="-s" # build as serial lib with no ZMQ support
The build should produce two files: ``lib/message/cslib/src/libmessage.a``
and ``lib/message/Makefile.lammps``. The latter is copied from an
existing ``Makefile.lammps.*`` and has settings to link with the ZeroMQ
library if requested in the build.
----------
.. _mliap:
ML-IAP package
@ -1289,6 +1302,41 @@ be built for the most part with all major versions of the C++ language.
----------
.. _electrode:
ELECTRODE package
-----------------
This package depends on the KSPACE package.
.. tabs::
.. tab:: CMake build
No additional settings are needed besides ``-D PKG_KSPACE=yes`` and ``-D
PKG_ELECTRODE=yes``.
.. tab:: Traditional make
The package is activated with ``make yes-KSPACE`` and ``make
yes-ELECTRODE``
Note that the ``Makefile.lammps`` file has settings for the BLAS and
LAPACK linear algebra libraries. As explained in ``lib/awpmd/README``
these can either exist on your system, or you can use the files provided
in ``lib/linalg``. In the latter case you also need to build the library
in ``lib/linalg`` with a command like these:
.. code-block:: bash
$ make lib-linalg # print help message
$ make lib-linalg args="-m serial" # build with GNU Fortran compiler (settings as with "make serial")
$ make lib-linalg args="-m mpi" # build with default MPI Fortran compiler (settings as with "make mpi")
$ make lib-linalg args="-m gfortran" # build with GNU Fortran compiler
----------
.. _ml-pace:
ML-PACE package
@ -1893,14 +1941,25 @@ within CMake will download the non-commercial use version.
.. code-block:: bash
-D DOWNLOAD_QUIP=value # download OpenKIM API v2 for build, value = no (default) or yes
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
-D DOWNLOAD_QUIP=value # download QUIP library for build, value = no (default) or yes
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
-D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
# value = no (default) or yes
CMake will try to download and build the QUIP library from GitHub, if it is not
found on the local machine. This requires to have git installed. It will use the same compilers
and flags as used for compiling LAMMPS. Currently this is only supported for the GNU and the
Intel compilers. Set the ``QUIP_LIBRARY`` variable if you want to use a previously compiled
and installed QUIP library and CMake cannot find it.
CMake will try to download and build the QUIP library from GitHub,
if it is not found on the local machine. This requires to have git
installed. It will use the same compilers and flags as used for
compiling LAMMPS. Currently this is only supported for the GNU
and the Intel compilers. Set the ``QUIP_LIBRARY`` variable if you
want to use a previously compiled and installed QUIP library and
CMake cannot find it.
The QUIP library requires LAPACK (and BLAS) and CMake can identify
their locations and pass that info to the QUIP build script. But
on some systems this triggers a (current) limitation of CMake and
the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
those cases to use the bundled linear algebra library and work around
the limitation.
.. tab:: Traditional make

38
doc/src/Build_manual.rst
View File

@ -48,18 +48,15 @@ Build using GNU make
The LAMMPS manual is written in `reStructuredText <rst_>`_ format which
can be translated to different output format using the `Sphinx
<sphinx_>`_ document generator tool. It also incorporates programmer
documentation extracted from the LAMMPS C++ sources through the `Doxygen
<https://doxygen.nl>`_ program. Currently the translation to HTML, PDF
(via LaTeX), ePUB (for many e-book readers) and MOBI (for Amazon Kindle
readers) are supported. For that to work a Python 3 interpreter, the
``doxygen`` tools and internet access to download additional files and
tools are required. This download is usually only required once or
after the documentation folder is returned to a pristine state with
``make clean-all``.
.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
.. _sphinx: https://www.sphinx-doc.org
<https://sphinx-doc.org>`_ document generator tool. It also
incorporates programmer documentation extracted from the LAMMPS C++
sources through the `Doxygen <https://doxygen.nl>`_ program. Currently
the translation to HTML, PDF (via LaTeX), ePUB (for many e-book readers)
and MOBI (for Amazon Kindle readers) are supported. For that to work a
Python 3 interpreter, the ``doxygen`` tools and internet access to
download additional files and tools are required. This download is
usually only required once or after the documentation folder is returned
to a pristine state with ``make clean-all``.
For the documentation build a python virtual environment is set up in
the folder ``doc/docenv`` and various python packages are installed into
@ -78,11 +75,12 @@ folder. The following ``make`` commands are available:
make html # generate HTML in html dir using Sphinx
make pdf # generate PDF as Manual.pdf using Sphinx and PDFLaTeX
make fetch # fetch HTML pages and PDF files from LAMMPS website
# and unpack into the html_www folder and Manual_www.pdf
make epub # generate LAMMPS.epub in ePUB format using Sphinx
make mobi # generate LAMMPS.mobi in MOBI format using ebook-convert
make fasthtml # generate approximate HTML in fasthtml dir using Sphinx
# some Sphinx extensions do not work correctly with this
make clean # remove intermediate RST files created by HTML build
make clean-all # remove entire build folder and any cached data
@ -193,8 +191,13 @@ folder need to be updated or new files added. These files are written in
`reStructuredText <rst_>`_ markup for translation with the Sphinx tool.
Before contributing any documentation, please check that both the HTML
and the PDF format documentation can translate without errors. Please also
check the output to the console for any warnings or problems. There will
and the PDF format documentation can translate without errors. During
testing the html translation, you may use the ``make fasthtml`` command
which does an approximate translation (i.e. not all Sphinx features and
extensions will work), but runs very fast because it will only translate
files that have been changed since the last ``make fasthtml`` command.
Please also check the output to the console for any warnings or problems. There will
be multiple tests run automatically:
- A test for correctness of all anchor labels and their references
@ -246,6 +249,5 @@ manual with ``make spelling``. This requires `a library called enchant
positives* (e.g. keywords, names, abbreviations) those can be added to
the file ``lammps/doc/utils/sphinx-config/false_positives.txt``.
.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
.. _lws: https://www.lammps.org
.. _rst: https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html

11
doc/src/Build_package.rst
View File

@ -45,7 +45,6 @@ packages:
* :ref:`KOKKOS <kokkos>`
* :ref:`LATTE <latte>`
* :ref:`MACHDYN <machdyn>`
* :ref:`MESSAGE <message>`
* :ref:`ML-HDNNP <ml-hdnnp>`
* :ref:`ML-PACE <ml-pace>`
* :ref:`ML-QUIP <ml-quip>`
@ -151,7 +150,7 @@ other files dependent on that package are also excluded.
.. _cmake_presets:
CMake presets for installing many packages
""""""""""""""""""""""""""""""""""""""""""
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Instead of specifying all the CMake options via the command-line,
CMake allows initializing its settings cache using script files.
@ -179,6 +178,11 @@ one of them as a starting point and customize it to your needs.
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
Presets that have names starting with "windows" are specifically for
compiling LAMMPS :doc:`natively on Windows <Build_windows>` and
presets that have names starting with "kokkos" are specifically for
selecting configurations for compiling LAMMPS with :ref:`KOKKOS <kokkos>`.
.. note::
Running cmake this way manipulates the CMake settings cache in your
@ -221,7 +225,8 @@ These commands install/un-install sets of packages:
.. code-block:: bash
make yes-all # install all packages
make no-all # uninstall all packages
make no-all # check for changes and uninstall all packages
make no-installed # only check and uninstall installed packages
make yes-basic # install a few commonly used packages'
make no-basic # remove a few commonly used packages'
make yes-most # install most packages w/o libs'

15
doc/src/Build_settings.rst
View File

@ -287,8 +287,8 @@ Output of JPG, PNG, and movie files
The :doc:`dump image <dump_image>` command has options to output JPEG or
PNG image files. Likewise the :doc:`dump movie <dump_image>` command
outputs movie files in MPEG format. Using these options requires the
following settings:
outputs movie files in a variety of movie formats. Using these options
requires the following settings:
.. tabs::
@ -328,11 +328,12 @@ following settings:
JPG_LIB = -ljpeg -lpng -lz # library names
As with CMake, you do not need to set ``JPG_INC`` or ``JPG_PATH``,
if make can find the graphics header and library files. You must
specify ``JPG_LIB`` with a list of graphics libraries to include
in the link. You must insure ffmpeg is in a directory where
LAMMPS can find it at runtime, that is a directory in your PATH
environment variable.
if make can find the graphics header and library files in their
default system locations. You must specify ``JPG_LIB`` with a
list of graphics libraries to include in the link. You must make
certain that the ffmpeg executable (or ffmpeg.exe on Windows) is
in a directory where LAMMPS can find it at runtime; that is
usually a directory list in your ``PATH`` environment variable.
Using ``ffmpeg`` to output movie files requires that your machine
supports the "popen" function in the standard runtime library.

82
doc/src/Build_windows.rst
View File

@ -5,6 +5,7 @@ Notes for building LAMMPS on Windows
* :ref:`Running Linux on Windows <linux>`
* :ref:`Using GNU GCC ported to Windows <gnu>`
* :ref:`Using Visual Studio <msvc>`
* :ref:`Using Intel oneAPI compilers and libraries <oneapi>`
* :ref:`Using a cross-compiler <cross>`
----------
@ -25,8 +26,10 @@ assistance in resolving portability issues. This is particularly true
for compiling LAMMPS on Windows, since this platform has significant
differences in some low-level functionality. As of LAMMPS version 14
December 2021, large parts of LAMMPS can be compiled natively with the
Microsoft Visual C++ Compilers. This is largely facilitated by using
the :doc:`Developer_platform` in the ``platform`` namespace.
Microsoft Visual C++ Compilers. As of LAMMPS version 31 May 2022, also
the Intel oneAPI compilers can compile large parts of LAMMPS natively on
Windows. This is mostly facilitated by using the
:doc:`Developer_platform` in the ``platform`` namespace and CMake.
Before trying to build LAMMPS on Windows yourself, please consider the
`pre-compiled Windows installer packages <https://packages.lammps.org/windows.html>`_
@ -73,8 +76,9 @@ configuration should set this up automatically, but is untested.
In case of problems, you are recommended to contact somebody with
experience in using Cygwin. If you do come across portability problems
requiring changes to the LAMMPS source code, or figure out corrections
yourself, please report them on the lammps-users mailing list, or file
them as an issue or pull request on the LAMMPS GitHub project.
yourself, please report them on the
`LAMMPS forum at MatSci <https://matsci.org/c/lammps/lammps-development/>`_,
or file them as an issue or pull request on the LAMMPS GitHub project.
.. _msvc:
@ -98,6 +102,10 @@ It is possible to use both the integrated CMake support of the Visual
Studio IDE or use an external CMake installation (e.g. downloaded from
cmake.org) to create build files and compile LAMMPS from the command line.
Compilation via command line and unit tests are checked automatically
for the LAMMPS development branch through
`GitHub Actions <https://github.com/lammps/lammps/actions/workflows/compile-msvc.yml>`_.
.. note::
Versions of Visual Studio before version 17.1 may scan the entire
@ -110,6 +118,10 @@ Please note, that for either approach CMake will create a so-called
the command lines for building and testing LAMMPS must be adjusted
accordingly.
The LAMMPS cmake folder contains a ``CMakeSettings.json`` file with
build configurations for MSVC compilers and the MS provided Clang
compiler package in Debug and Release mode.
To support running in parallel you can compile with OpenMP enabled using
the OPENMP package or install Microsoft MPI (including the SDK) and compile
LAMMPS with MPI enabled.
@ -117,8 +129,55 @@ LAMMPS with MPI enabled.
.. note::
This is work in progress and you should contact the LAMMPS developers
via GitHub, the forum, or the mailing list, if you have questions or
LAMMPS specific problems.
via GitHub or the `LAMMPS forum at MatSci <https://matsci.org/c/lammps/lammps-development/>`_,
if you have questions or LAMMPS specific problems.
.. _oneapi:
Using Intel oneAPI Compilers and Libraries
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionadded:: 31May2022
After installing the `Intel oneAPI
<https://www.intel.com/content/www/us/en/developer/tools/oneapi/toolkits.html>`_
base toolkit and the HPC toolkit, it is also possible to compile large
parts of LAMMPS natively on Windows using Intel compilers. The HPC
toolkit provides two sets of C/C++ and Fortran compilers: the so-called
"classic" compilers (``icl.exe`` and ``ifort.exe``) and newer, LLVM
based compilers (``icx.exe`` and ``ifx.exe``). In addition to the
compilers and their dependent modules, also the thread building blocks
(TBB) and the math kernel library (MKL) need to be installed. Two
presets (``cmake/presets/windows-intel-llvm.cmake`` and
``cmake/presets/windows-intel-classic.cmake``) are provided for
selecting the LLVM based or classic compilers, respectively. The preset
``cmake/presets/windows.cmake`` enables compatible packages that are not
dependent on additional features or libraries. You **must** use the
CMake based build procedure and use Ninja as build tool. For compiling
from the command prompt, thus both `CMake <https://cmake.org>`_ and
`Ninja-build <https://ninja-build.org>`_ binaries must be installed. It
is also possible to use Visual Studio, if it is started (``devenv.exe``)
from a command prompt that has the Intel oneAPI compilers enabled. The
Visual Studio settings file in the ``cmake`` folder contains
configurations for both compiler variants in debug and release settings.
Those will use the CMake and Ninja binaries bundled with Visual Studio,
thus a separate installation is not required.
.. admonition:: Known Limitations
:class: note
In addition to portability issues with several packages and external
libraries, the classic Intel compilers are currently not able to
compile the googletest libraries and thus enabling the ``-DENABLE_TESTING``
option will result in compilation failure. The LLVM based compilers
are compatible.
.. note::
This is work in progress and you should contact the LAMMPS developers
via GitHub or the `LAMMPS forum at MatSci <https://matsci.org/c/lammps/lammps-development/>`_,
if you have questions or LAMMPS specific problems.
.. _cross:
@ -144,14 +203,3 @@ LAMMPS developers. We instead rely on the feedback of the users
of these pre-compiled LAMMPS packages for Windows. We will try to resolve
issues to the best of our abilities if we become aware of them. However
this is subject to time constraints and focus on HPC platforms.
.. _native:
Native Visual C++ support
^^^^^^^^^^^^^^^^^^^^^^^^^
Support for the Visual C++ compilers is currently not available. The
CMake build system is capable of creating suitable a Visual Studio
style build environment, but the LAMMPS source code itself is not
ported to fully support Visual C++. Volunteers to take on this task
are welcome.

1
doc/src/Commands.rst
View File

@ -21,6 +21,7 @@ commands in it are used to define a LAMMPS simulation.
Commands_pair
Commands_bond
Commands_kspace
Commands_dump
.. toctree::
:maxdepth: 1

46
doc/src/Commands_all.rst
View File

@ -10,11 +10,12 @@
* :ref:`Dihedral styles <dihedral>`
* :ref:`Improper styles <improper>`
* :doc:`KSpace styles <Commands_kspace>`
* :doc:`Dump styles <Commands_dump>`
General commands
================
An alphabetic list of all general LAMMPS commands.
An alphabetic list of general LAMMPS commands.
.. table_from_list::
:columns: 5
@ -47,20 +48,16 @@ An alphabetic list of all general LAMMPS commands.
* :doc:`displace_atoms <displace_atoms>`
* :doc:`dump <dump>`
* :doc:`dump_modify <dump_modify>`
* :doc:`dynamical_matrix (k) <dynamical_matrix>`
* :doc:`echo <echo>`
* :doc:`fix <fix>`
* :doc:`fix_modify <fix_modify>`
* :doc:`group <group>`
* :doc:`group2ndx <group2ndx>`
* :doc:`hyper <hyper>`
* :doc:`if <if>`
* :doc:`improper_coeff <improper_coeff>`
* :doc:`improper_style <improper_style>`
* :doc:`include <include>`
* :doc:`info <info>`
* :doc:`jump <jump>`
* :doc:`kim <kim_commands>`
* :doc:`kspace_modify <kspace_modify>`
* :doc:`kspace_style <kspace_style>`
* :doc:`label <label>`
@ -68,16 +65,10 @@ An alphabetic list of all general LAMMPS commands.
* :doc:`lattice <lattice>`
* :doc:`log <log>`
* :doc:`mass <mass>`
* :doc:`mdi/engine <mdi_engine>`
* :doc:`message <message>`
* :doc:`minimize <minimize>`
* :doc:`min_modify <min_modify>`
* :doc:`min_style <min_style>`
* :doc:`min_style spin <min_spin>`
* :doc:`molecule <molecule>`
* :doc:`ndx2group <group2ndx>`
* :doc:`neb <neb>`
* :doc:`neb/spin <neb_spin>`
* :doc:`neigh_modify <neigh_modify>`
* :doc:`neighbor <neighbor>`
* :doc:`newton <newton>`
@ -88,11 +79,8 @@ An alphabetic list of all general LAMMPS commands.
* :doc:`pair_style <pair_style>`
* :doc:`pair_write <pair_write>`
* :doc:`partition <partition>`
* :doc:`plugin <plugin>`
* :doc:`prd <prd>`
* :doc:`print <print>`
* :doc:`processors <processors>`
* :doc:`python <python>`
* :doc:`quit <quit>`
* :doc:`read_data <read_data>`
* :doc:`read_dump <read_dump>`
@ -106,19 +94,13 @@ An alphabetic list of all general LAMMPS commands.
* :doc:`restart <restart>`
* :doc:`run <run>`
* :doc:`run_style <run_style>`
* :doc:`server <server>`
* :doc:`set <set>`
* :doc:`shell <shell>`
* :doc:`special_bonds <special_bonds>`
* :doc:`suffix <suffix>`
* :doc:`tad <tad>`
* :doc:`temper <temper>`
* :doc:`temper/grem <temper_grem>`
* :doc:`temper/npt <temper_npt>`
* :doc:`thermo <thermo>`
* :doc:`thermo_modify <thermo_modify>`
* :doc:`thermo_style <thermo_style>`
* :doc:`third_order (k) <third_order>`
* :doc:`timer <timer>`
* :doc:`timestep <timestep>`
* :doc:`uncompute <uncompute>`
@ -131,3 +113,27 @@ An alphabetic list of all general LAMMPS commands.
* :doc:`write_data <write_data>`
* :doc:`write_dump <write_dump>`
* :doc:`write_restart <write_restart>`
Additional general LAMMPS commands provided by packages. A few
commands have accelerated versions. This is indicated by an
additional letter in parenthesis: k = KOKKOS.
.. table_from_list::
:columns: 5
* :doc:`dynamical_matrix (k) <dynamical_matrix>`
* :doc:`group2ndx <group2ndx>`
* :doc:`hyper <hyper>`
* :doc:`kim <kim_commands>`
* :doc:`mdi <mdi>`
* :doc:`ndx2group <group2ndx>`
* :doc:`neb <neb>`
* :doc:`neb/spin <neb_spin>`
* :doc:`plugin <plugin>`
* :doc:`prd <prd>`
* :doc:`python <python>`
* :doc:`tad <tad>`
* :doc:`temper <temper>`
* :doc:`temper/grem <temper_grem>`
* :doc:`temper/npt <temper_npt>`
* :doc:`third_order (k) <third_order>`

9
doc/src/Commands_bond.rst
View File

@ -10,6 +10,7 @@
* :ref:`Dihedral styles <dihedral>`
* :ref:`Improper styles <improper>`
* :doc:`KSpace styles <Commands_kspace>`
* :doc:`Dump styles <Commands_dump>`
.. _bond:
@ -32,6 +33,8 @@ OPT.
*
*
*
* :doc:`bpm/rotational <bond_bpm_rotational>`
* :doc:`bpm/spring <bond_bpm_spring>`
* :doc:`class2 (ko) <bond_class2>`
* :doc:`fene (iko) <bond_fene>`
* :doc:`fene/expand (o) <bond_fene_expand>`
@ -72,6 +75,7 @@ OPT.
*
*
*
* :doc:`amoeba <angle_amoeba>`
* :doc:`charmm (iko) <angle_charmm>`
* :doc:`class2 (ko) <angle_class2>`
* :doc:`class2/p6 <angle_class2>`
@ -86,11 +90,11 @@ OPT.
* :doc:`dipole (o) <angle_dipole>`
* :doc:`fourier (o) <angle_fourier>`
* :doc:`fourier/simple (o) <angle_fourier_simple>`
* :doc:`gaussian <angle_gaussian>` - multicentered Gaussian-based angle potential
* :doc:`gaussian <angle_gaussian>`
* :doc:`harmonic (iko) <angle_harmonic>`
* :doc:`mm3 <angle_mm3>`
* :doc:`quartic (o) <angle_quartic>`
* :doc:`sdk (o) <angle_sdk>`
* :doc:`spica (o) <angle_spica>`
* :doc:`table (o) <angle_table>`
.. _dihedral:
@ -150,6 +154,7 @@ OPT.
*
*
*
* :doc:`amoeba <improper_amoeba>`
* :doc:`class2 (ko) <improper_class2>`
* :doc:`cossq (o) <improper_cossq>`
* :doc:`cvff (io) <improper_cvff>`

6
doc/src/Commands_compute.rst
View File

@ -10,6 +10,7 @@
* :ref:`Dihedral styles <dihedral>`
* :ref:`Improper styles <improper>`
* :doc:`KSpace styles <Commands_kspace>`
* :doc:`Dump styles <Commands_dump>`
Compute commands
================
@ -33,6 +34,7 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`body/local <compute_body_local>`
* :doc:`bond <compute_bond>`
* :doc:`bond/local <compute_bond_local>`
* :doc:`born/matrix <compute_born_matrix>`
* :doc:`centro/atom <compute_centro_atom>`
* :doc:`centroid/stress/atom <compute_stress_atom>`
* :doc:`chunk/atom <compute_chunk_atom>`
@ -63,6 +65,7 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`event/displace <compute_event_displace>`
* :doc:`fabric <compute_fabric>`
* :doc:`fep <compute_fep>`
* :doc:`fep/ta <compute_fep_ta>`
* :doc:`force/tally <compute_tally>`
* :doc:`fragment/atom <compute_cluster_atom>`
* :doc:`global/atom <compute_global_atom>`
@ -90,6 +93,7 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`msd <compute_msd>`
* :doc:`msd/chunk <compute_msd_chunk>`
* :doc:`msd/nongauss <compute_msd_nongauss>`
* :doc:`nbond/atom <compute_nbond_atom>`
* :doc:`omega/chunk <compute_omega_chunk>`
* :doc:`orientorder/atom (k) <compute_orientorder_atom>`
* :doc:`pair <compute_pair>`
@ -135,6 +139,8 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`smd/vol <compute_smd_vol>`
* :doc:`snap <compute_sna_atom>`
* :doc:`sna/atom <compute_sna_atom>`
* :doc:`sna/grid <compute_sna_atom>`
* :doc:`sna/grid/local <compute_sna_atom>`
* :doc:`snad/atom <compute_sna_atom>`
* :doc:`snav/atom <compute_sna_atom>`
* :doc:`sph/e/atom <compute_sph_e_atom>`

56
doc/src/Commands_dump.rst Normal file
View File

@ -0,0 +1,56 @@
.. table_from_list::
:columns: 3
* :doc:`General commands <Commands_all>`
* :doc:`Fix styles <Commands_fix>`
* :doc:`Compute styles <Commands_compute>`
* :doc:`Pair styles <Commands_pair>`
* :ref:`Bond styles <bond>`
* :ref:`Angle styles <angle>`
* :ref:`Dihedral styles <dihedral>`
* :ref:`Improper styles <improper>`
* :doc:`KSpace styles <Commands_kspace>`
* :doc:`Dump styles <Commands_dump>`
Dump commands
=============
An alphabetic list of all LAMMPS :doc:`dump <dump>` commands.
.. table_from_list::
:columns: 5
* :doc:`atom <dump>`
* :doc:`atom/adios <dump_adios>`
* :doc:`atom/gz <dump>`
* :doc:`atom/mpiio <dump>`
* :doc:`atom/zstd <dump>`
* :doc:`cfg <dump>`
* :doc:`cfg/gz <dump>`
* :doc:`cfg/mpiio <dump>`
* :doc:`cfg/uef <dump_cfg_uef>`
* :doc:`cfg/zstd <dump>`
* :doc:`custom <dump>`
* :doc:`custom/adios <dump_adios>`
* :doc:`custom/gz <dump>`
* :doc:`custom/mpiio <dump>`
* :doc:`custom/zstd <dump>`
* :doc:`dcd <dump>`
* :doc:`deprecated <dump>`
* :doc:`h5md <dump_h5md>`
* :doc:`image <dump_image>`
* :doc:`local <dump>`
* :doc:`local/gz <dump>`
* :doc:`local/zstd <dump>`
* :doc:`molfile <dump_molfile>`
* :doc:`movie <dump_image>`
* :doc:`netcdf <dump_netcdf>`
* :doc:`netcdf/mpiio <dump>`
* :doc:`vtk <dump_vtk>`
* :doc:`xtc <dump>`
* :doc:`xyz <dump>`
* :doc:`xyz/gz <dump>`
* :doc:`xyz/mpiio <dump>`
* :doc:`xyz/zstd <dump>`
* :doc:`yaml <dump>`

13
doc/src/Commands_fix.rst
View File

@ -10,6 +10,7 @@
* :ref:`Dihedral styles <dihedral>`
* :ref:`Improper styles <improper>`
* :doc:`KSpace styles <Commands_kspace>`
* :doc:`Dump styles <Commands_dump>`
Fix commands
============
@ -28,6 +29,8 @@ OPT.
* :doc:`adapt/fep <fix_adapt_fep>`
* :doc:`addforce <fix_addforce>`
* :doc:`addtorque <fix_addtorque>`
* :doc:`amoeba/bitorsion <fix_amoeba_bitorsion>`
* :doc:`amoeba/pitorsion <fix_amoeba_pitorsion>`
* :doc:`append/atoms <fix_append_atoms>`
* :doc:`atc <fix_atc>`
* :doc:`atom/swap <fix_atom_swap>`
@ -51,10 +54,10 @@ OPT.
* :doc:`bond/swap <fix_bond_swap>`
* :doc:`box/relax <fix_box_relax>`
* :doc:`charge/regulation <fix_charge_regulation>`
* :doc:`client/md <fix_client_md>`
* :doc:`cmap <fix_cmap>`
* :doc:`colvars <fix_colvars>`
* :doc:`controller <fix_controller>`
* :doc:`damping/cundall <fix_damping_cundall>`
* :doc:`deform (k) <fix_deform>`
* :doc:`deposit <fix_deposit>`
* :doc:`dpd/energy (k) <fix_dpd_energy>`
@ -66,6 +69,9 @@ OPT.
* :doc:`edpd/source <fix_dpd_source>`
* :doc:`efield <fix_efield>`
* :doc:`ehex <fix_ehex>`
* :doc:`electrode/conp (i) <fix_electrode_conp>`
* :doc:`electrode/conq (i) <fix_electrode_conp>`
* :doc:`electrode/thermo (i) <fix_electrode_conp>`
* :doc:`electron/stopping <fix_electron_stopping>`
* :doc:`electron/stopping/fit <fix_electron_stopping>`
* :doc:`enforce2d (k) <fix_enforce2d>`
@ -100,7 +106,7 @@ OPT.
* :doc:`lb/viscous <fix_lb_viscous>`
* :doc:`lineforce <fix_lineforce>`
* :doc:`manifoldforce <fix_manifoldforce>`
* :doc:`mdi/engine <fix_mdi_engine>`
* :doc:`mdi/qm <fix_mdi_qm>`
* :doc:`meso/move <fix_meso_move>`
* :doc:`mol/swap <fix_mol_swap>`
* :doc:`momentum (k) <fix_momentum>`
@ -141,6 +147,7 @@ OPT.
* :doc:`nve/manifold/rattle <fix_nve_manifold_rattle>`
* :doc:`nve/noforce <fix_nve_noforce>`
* :doc:`nve/sphere (ko) <fix_nve_sphere>`
* :doc:`nve/bpm/sphere <fix_nve_bpm_sphere>`
* :doc:`nve/spin <fix_nve_spin>`
* :doc:`nve/tri <fix_nve_tri>`
* :doc:`nvk <fix_nvk>`
@ -158,7 +165,6 @@ OPT.
* :doc:`orient/fcc <fix_orient>`
* :doc:`orient/eco <fix_orient_eco>`
* :doc:`pafi <fix_pafi>`
* :doc:`pair/tracker <fix_pair_tracker>`
* :doc:`phonon <fix_phonon>`
* :doc:`pimd <fix_pimd>`
* :doc:`planeforce <fix_planeforce>`
@ -243,6 +249,7 @@ OPT.
* :doc:`vector <fix_vector>`
* :doc:`viscosity <fix_viscosity>`
* :doc:`viscous <fix_viscous>`
* :doc:`viscous/sphere <fix_viscous_sphere>`
* :doc:`wall/body/polygon <fix_wall_body_polygon>`
* :doc:`wall/body/polyhedron <fix_wall_body_polyhedron>`
* :doc:`wall/colloid <fix_wall>`

3
doc/src/Commands_kspace.rst
View File

@ -10,6 +10,7 @@
* :ref:`Dihedral styles <dihedral>`
* :ref:`Improper styles <improper>`
* :doc:`KSpace styles <Commands_kspace>`
* :doc:`Dump styles <Commands_dump>`
KSpace solvers
==============
@ -27,6 +28,7 @@ OPT.
* :doc:`ewald/disp/dipole <kspace_style>`
* :doc:`ewald/dipole <kspace_style>`
* :doc:`ewald/dipole/spin <kspace_style>`
* :doc:`ewald/electrode <kspace_style>`
* :doc:`msm (o) <kspace_style>`
* :doc:`msm/cg (o) <kspace_style>`
* :doc:`msm/dielectric <kspace_style>`
@ -41,4 +43,5 @@ OPT.
* :doc:`pppm/stagger <kspace_style>`
* :doc:`pppm/tip4p (o) <kspace_style>`
* :doc:`pppm/dielectric <kspace_style>`
* :doc:`pppm/electrode (i) <kspace_style>`
* :doc:`scafacos <kspace_style>`

37
doc/src/Commands_pair.rst
View File

@ -10,6 +10,7 @@
* :ref:`Dihedral styles <dihedral>`
* :ref:`Improper styles <improper>`
* :doc:`KSpace styles <Commands_kspace>`
* :doc:`Dump styles <Commands_dump>`
Pair_style potentials
======================
@ -34,10 +35,11 @@ OPT.
*
*
*
* :doc:`adp (o) <pair_adp>`
* :doc:`adp (ko) <pair_adp>`
* :doc:`agni (o) <pair_agni>`
* :doc:`airebo (io) <pair_airebo>`
* :doc:`airebo/morse (io) <pair_airebo>`
* :doc:`amoeba <pair_amoeba>`
* :doc:`atm <pair_atm>`
* :doc:`awpmd/cut <pair_awpmd>`
* :doc:`beck (go) <pair_beck>`
@ -53,6 +55,7 @@ OPT.
* :doc:`born/coul/msm (o) <pair_born>`
* :doc:`born/coul/wolf (go) <pair_born>`
* :doc:`born/coul/wolf/cs (g) <pair_cs>`
* :doc:`bpm/spring <pair_bpm_spring>`
* :doc:`brownian (o) <pair_brownian>`
* :doc:`brownian/poly (o) <pair_brownian>`
* :doc:`buck (giko) <pair_buck>`
@ -88,12 +91,12 @@ OPT.
* :doc:`coul/tt <pair_coul_tt>`
* :doc:`coul/wolf (ko) <pair_coul>`
* :doc:`coul/wolf/cs <pair_cs>`
* :doc:`dpd (gio) <pair_dpd>`
* :doc:`dpd (giko) <pair_dpd>`
* :doc:`dpd/fdt <pair_dpd_fdt>`
* :doc:`dpd/ext <pair_dpd_ext>`
* :doc:`dpd/ext/tstat <pair_dpd_ext>`
* :doc:`dpd/ext (k) <pair_dpd_ext>`
* :doc:`dpd/ext/tstat (k) <pair_dpd_ext>`
* :doc:`dpd/fdt/energy (k) <pair_dpd_fdt>`
* :doc:`dpd/tstat (go) <pair_dpd>`
* :doc:`dpd/tstat (gko) <pair_dpd>`
* :doc:`dsmc <pair_dsmc>`
* :doc:`e3b <pair_e3b>`
* :doc:`drip <pair_drip>`
@ -123,8 +126,9 @@ OPT.
* :doc:`hbond/dreiding/lj (o) <pair_hbond_dreiding>`
* :doc:`hbond/dreiding/morse (o) <pair_hbond_dreiding>`
* :doc:`hdnnp <pair_hdnnp>`
* :doc:`ilp/graphene/hbn <pair_ilp_graphene_hbn>`
* :doc:`ilp/tmd <pair_ilp_tmd>`
* :doc:`hippo <pair_amoeba>`
* :doc:`ilp/graphene/hbn (t) <pair_ilp_graphene_hbn>`
* :doc:`ilp/tmd (t) <pair_ilp_tmd>`
* :doc:`kolmogorov/crespi/full <pair_kolmogorov_crespi_full>`
* :doc:`kolmogorov/crespi/z <pair_kolmogorov_crespi_z>`
* :doc:`lcbop <pair_lcbop>`
@ -151,7 +155,7 @@ OPT.
* :doc:`lj/cut/coul/cut/dielectric (o) <pair_dielectric>`
* :doc:`lj/cut/coul/cut/soft (o) <pair_fep_soft>`
* :doc:`lj/cut/coul/debye (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/debye/dielectric <pair_dielectric>`
* :doc:`lj/cut/coul/debye/dielectric (o) <pair_dielectric>`
* :doc:`lj/cut/coul/dsf (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/long (gikot) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/long/cs <pair_cs>`
@ -178,9 +182,9 @@ OPT.
* :doc:`lj/long/tip4p/long (o) <pair_lj_long>`
* :doc:`lj/mdf <pair_mdf>`
* :doc:`lj/relres (o) <pair_lj_relres>`
* :doc:`lj/sdk (gko) <pair_sdk>`
* :doc:`lj/sdk/coul/long (go) <pair_sdk>`
* :doc:`lj/sdk/coul/msm (o) <pair_sdk>`
* :doc:`lj/spica (gko) <pair_spica>`
* :doc:`lj/spica/coul/long (go) <pair_spica>`
* :doc:`lj/spica/coul/msm (o) <pair_spica>`
* :doc:`lj/sf/dipole/sf (go) <pair_dipole>`
* :doc:`lj/smooth (go) <pair_lj_smooth>`
* :doc:`lj/smooth/linear (o) <pair_lj_smooth_linear>`
@ -193,7 +197,7 @@ OPT.
* :doc:`lubricateU/poly <pair_lubricateU>`
* :doc:`mdpd <pair_mesodpd>`
* :doc:`mdpd/rhosum <pair_mesodpd>`
* :doc:`meam <pair_meam>`
* :doc:`meam (k) <pair_meam>`
* :doc:`meam/spline (o) <pair_meam_spline>`
* :doc:`meam/sw/spline <pair_meam_sw_spline>`
* :doc:`mesocnt <pair_mesocnt>`
@ -230,7 +234,7 @@ OPT.
* :doc:`oxrna2/stk <pair_oxrna2>`
* :doc:`oxrna2/xstk <pair_oxrna2>`
* :doc:`oxrna2/coaxstk <pair_oxrna2>`
* :doc:`pace <pair_pace>`
* :doc:`pace (k) <pair_pace>`
* :doc:`peri/eps <pair_peri>`
* :doc:`peri/lps (o) <pair_peri>`
* :doc:`peri/pmb (o) <pair_peri>`
@ -242,8 +246,10 @@ OPT.
* :doc:`reaxff (ko) <pair_reaxff>`
* :doc:`rebo (io) <pair_airebo>`
* :doc:`resquared (go) <pair_resquared>`
* :doc:`saip/metal <pair_saip_metal>`
* :doc:`saip/metal (t) <pair_saip_metal>`
* :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>`
* :doc:`smatb <pair_smatb>`
* :doc:`smatb/single <pair_smatb>`
* :doc:`smd/hertz <pair_smd_hertz>`
* :doc:`smd/tlsph <pair_smd_tlsph>`
* :doc:`smd/tri_surface <pair_smd_triangulated_surface>`
@ -265,7 +271,9 @@ OPT.
* :doc:`spin/magelec <pair_spin_magelec>`
* :doc:`spin/neel <pair_spin_neel>`
* :doc:`srp <pair_srp>`
* :doc:`srp/react <pair_srp>`
* :doc:`sw (giko) <pair_sw>`
* :doc:`sw/angle/table <pair_sw_angle_table>`
* :doc:`sw/mod (o) <pair_sw>`
* :doc:`table (gko) <pair_table>`
* :doc:`table/rx (k) <pair_table_rx>`
@ -276,6 +284,7 @@ OPT.
* :doc:`tersoff/table (o) <pair_tersoff>`
* :doc:`tersoff/zbl (gko) <pair_tersoff_zbl>`
* :doc:`thole <pair_thole>`
* :doc:`threebody/table <pair_threebody_table>`
* :doc:`tip4p/cut (o) <pair_coul>`
* :doc:`tip4p/long (o) <pair_coul>`
* :doc:`tip4p/long/soft (o) <pair_fep_soft>`

37
doc/src/Commands_parse.rst
View File

@ -77,18 +77,19 @@ LAMMPS:
so that you do not have to define (or discard) a temporary variable,
"X" in this case.
Additionally, the "immediate" variable expression may be followed by
a colon, followed by a C-style format string, e.g. ":%f" or ":%.10g".
The format string must be appropriate for a double-precision
floating-point value. The format string is used to output the result
of the variable expression evaluation. If a format string is not
specified a high-precision "%.20g" is used as the default.
Additionally, the entire "immediate" variable expression may be
followed by a colon, followed by a C-style format string,
e.g. ":%f" or ":%.10g". The format string must be appropriate for
a double-precision floating-point value. The format string is used
to output the result of the variable expression evaluation. If a
format string is not specified, a high-precision "%.20g" is used as
the default format.
This can be useful for formatting print output to a desired precision:
.. code-block:: LAMMPS
print "Final energy per atom: $(pe/atoms:%10.3f) eV/atom"
print "Final energy per atom: $(v_ke_per_atom+v_pe_per_atom:%10.3f) eV/atom"
Note that neither the curly-bracket or immediate form of variables
can contain nested $ characters for other variables to substitute
@ -122,14 +123,15 @@ LAMMPS:
.. _six:
6. If you want text with spaces to be treated as a single argument, it
can be enclosed in either single or double or triple quotes. A long
single argument enclosed in single or double quotes can span multiple
lines if the "&" character is used, as described above. When the
lines are concatenated together (and the "&" characters and line
breaks removed), the text will become a single line. If you want
multiple lines of an argument to retain their line breaks, the text
can be enclosed in triple quotes, in which case "&" characters are
not needed. For example:
can be enclosed in either single (') or double (") or triple (""")
quotes. A long single argument enclosed in single or double quotes
can span multiple lines if the "&" character is used, as described
in :ref:`1 <one>` above. When the lines are concatenated together
by LAMMPS (and the "&" characters and line breaks removed), the
combined text will become a single line. If you want multiple lines
of an argument to retain their line breaks, the text can be enclosed
in triple quotes, in which case "&" characters are not needed and do
not function as line continuation character. For example:
.. code-block:: LAMMPS
@ -143,8 +145,9 @@ LAMMPS:
System temperature = $t
"""
In each case, the single, double, or triple quotes are removed when
the single argument they enclose is stored internally.
In each of these cases, the single, double, or triple quotes are
removed and the enclosed text stored internally as a single
argument.
See the :doc:`dump modify format <dump_modify>`, :doc:`print
<print>`, :doc:`if <if>`, and :doc:`python <python>` commands for

1
doc/src/Developer.rst
View File

@ -17,6 +17,7 @@ of time and requests from the LAMMPS user community.
Developer_flow
Developer_write
Developer_notes
Developer_updating
Developer_plugins
Developer_unittest
Classes

40
doc/src/Developer_plugins.rst
View File

@ -68,7 +68,7 @@ Members of ``lammpsplugin_t``
* - author
- String with the name and email of the author
* - creator.v1
- Pointer to factory function for pair, bond, angle, dihedral, improper or command styles
- Pointer to factory function for pair, bond, angle, dihedral, improper, kspace, or command styles
* - creator.v2
- Pointer to factory function for compute, fix, or region styles
* - handle
@ -262,3 +262,41 @@ A plugin may be registered under an existing style name. In that case
the plugin will override the existing code. This can be used to modify
the behavior of existing styles or to debug new versions of them without
having to re-compile or re-install all of LAMMPS.
Compiling plugins
^^^^^^^^^^^^^^^^^
Plugins need to be compiled with the same compilers and libraries
(e.g. MPI) and compilation settings (MPI on/off, OpenMP, integer sizes)
as the LAMMPS executable and library. Otherwise the plugin will likely
not load due to mismatches in the function signatures (LAMMPS is C++ so
scope, type, and number of arguments are encoded into the symbol names
and thus differences in them will lead to failed plugin load commands.
Compilation of the plugin can be managed via both, CMake or traditional
GNU makefiles. Some examples that can be used as a template are in the
``examples/plugins`` folder. The CMake script code has some small
adjustments to allow building the plugins for running unit tests with
them.
Another example that converts the KIM package into a plugin can be found
in the ``examples/kim/plugin`` folder. No changes to the sources of the
KIM package themselves are needed; only the plugin interface and loader
code needs to be added. This example only supports building with CMake,
but is probably a more typical example. To compile you need to run CMake
with -DLAMMPS_SOURCE_DIR=<path/to/lammps/src/folder>. Other
configuration setting are identical to those for compiling LAMMPS.
A second example for a plugin from a package is in the
``examples/PACKAGES/pace/plugin`` folder that will create a plugin from
the ML-PACE package. In this case the bulk of the code is in a static
external library that is being downloaded and compiled first and then
combined with the pair style wrapper and the plugin loader. This
example also contains a NSIS script that can be used to create an
Installer package for Windows (the mutual licensing terms of the
external library and LAMMPS conflict when distributing binaries, so the
ML-PACE package cannot be linked statically, but the LAMMPS headers
required to build the plugin are also available under a less restrictive
license). This will automatically set the required environment variable
and launching a (compatible) LAMMPS binary will load and register the
plugin and the ML-PACE package can then be used as it was linked into
LAMMPS.

384
doc/src/Developer_updating.rst Normal file
View File

@ -0,0 +1,384 @@
Notes for updating code written for older LAMMPS versions
---------------------------------------------------------
This section documents how C++ source files that are available *outside
of the LAMMPS source distribution* (e.g. in external USER packages or as
source files provided as a supplement to a publication) that are written
for an older version of LAMMPS and thus need to be updated to be
compatible with the current version of LAMMPS. Due to the active
development of LAMMPS it is likely to always be incomplete. Please
contact developer@lammps.org in case you run across an issue that is not
(yet) listed here. Please also review the latest information about the
LAMMPS :doc:`programming style conventions <Modify_style>`, especially
if you are considering to submit the updated version for inclusion into
the LAMMPS distribution.
Available topics in mostly chronological order are:
- `Setting flags in the constructor`_
- `Rename of pack/unpack_comm() to pack/unpack_forward_comm()`_
- `Use ev_init() to initialize variables derived from eflag and vflag`_
- `Use utils::numeric() functions instead of force->numeric()`_
- `Use utils::open_potential() function to open potential files`_
- `Simplify customized error messages`_
- `Use of "override" instead of "virtual"`_
- `Simplified and more compact neighbor list requests`_
- `Split of fix STORE into fix STORE/GLOBAL and fix STORE/PERATOM`_
----
Setting flags in the constructor
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
As LAMMPS gains additional functionality, new flags may need to be set
in the constructor or a class to signal compatibility with such features.
Most of the time the defaults are chosen conservatively, but sometimes
the conservative choice is the uncommon choice, and then those settings
need to be made when updating code.
Pair styles:
- ``manybody_flag``: set to 1 if your pair style is not pair-wise additive
- ``restartinfo``: set to 0 if your pair style does not store data in restart files
Rename of pack/unpack_comm() to pack/unpack_forward_comm()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: 8Aug2014
In this change set the functions to pack data into communication buffers
and to unpack data from communication buffers for :doc:`forward
communications <Developer_comm_ops>` were renamed from ``pack_comm()``
and ``unpack_comm()`` to ``pack_forward_comm()`` and
``unpack_forward_comm()``, respectively. Also the meaning of the return
value of these functions was changed: rather than returning the number
of items per atom stored in the buffer, now the total number of items
added (or unpacked) needs to be returned. Here is an example from the
`PairEAM` class. Of course the member function declaration in corresponding
header file needs to be updated accordingly.
Old:
.. code-block:: C++
int PairEAM::pack_comm(int n, int *list, double *buf, int pbc_flag, int *pbc)
{
int m = 0;
for (int i = 0; i < n; i++) {
int j = list[i];
buf[m++] = fp[j];
}
return 1;
}
New:
.. code-block:: C++
int PairEAM::pack_forward_comm(int n, int *list, double *buf, int pbc_flag, int *pbc)
{
int m = 0;
for (int i = 0; i < n; i++) {
int j = list[i];
buf[m++] = fp[j];
}
return m;
}
.. note::
Because the various "pack" and "unpack" functions are defined in the
respective base classes as dummy functions doing nothing, and because
of the the name mismatch the custom versions in the derived class
will no longer be called, there will be no compilation error when
this change is not applied. Only calculations will suddenly produce
incorrect results because the required forward communication calls
will cease to function correctly.
Use ev_init() to initialize variables derived from eflag and vflag
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: 29Mar2019
There are several variables that need to be initialized based on
the values of the "eflag" and "vflag" variables and since sometimes
there are new bits added and new variables need to be set to 1 or 0.
To make this consistent, across all styles, there is now an inline
function ``ev_init(eflag, vflag)`` that makes those settings
consistently and calls either ``ev_setup()`` or ``ev_unset()``.
Example from a pair style:
Old:
.. code-block:: C++
if (eflag || vflag) ev_setup(eflag, vflag);
else evflag = vflag_fdotr = eflag_global = eflag_atom = 0;
New:
.. code-block:: C++
ev_init(eflag, vflag);
Not applying this change will not cause a compilation error, but
can lead to inconsistent behavior and incorrect tallying of
energy or virial.
Use utils::numeric() functions instead of force->numeric()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: 18Sep2020
The "numeric()" conversion functions (including "inumeric()",
"bnumeric()", and "tnumeric()") have been moved from the Force class to
the utils namespace. Also they take an additional argument that selects
whether the ``Error::all()`` or ``Error::one()`` function should be
called in case of an error. The former should be used when *all* MPI
processes call the conversion function and the latter *must* be used
when they are called from only one or a subset of the MPI processes.
Old:
.. code-block:: C++
val = force->numeric(FLERR, arg[1]);
num = force->inumeric(FLERR, arg[2]);
New:
.. code-block:: C++
val = utils::numeric(FLERR, true, arg[1], lmp);
num = utils::inumeric(FLERR, false, arg[2], lmp);
.. seealso::
:cpp:func:`utils::numeric() <LAMMPS_NS::utils::numeric>`,
:cpp:func:`utils::inumeric() <LAMMPS_NS::utils::inumeric>`,
:cpp:func:`utils::bnumeric() <LAMMPS_NS::utils::bnumeric>`,
:cpp:func:`utils::tnumeric() <LAMMPS_NS::utils::tnumeric>`
Use utils::open_potential() function to open potential files
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: 18Sep2020
The :cpp:func:`utils::open_potential()
<LAMMPS_NS::utils::open_potential>` function must be used to replace
calls to ``force->open_potential()`` and should be used to replace
``fopen()`` for opening potential files for reading. The custom
function does three additional steps compared to ``fopen()``: 1) it will
try to parse the ``UNITS:`` and ``DATE:`` metadata will stop with an
error on a units mismatch and will print the date info, if present, in
the log file; 2) for pair styles that support it, it will set up
possible automatic unit conversions based on the embedded unit
information and LAMMPS' current units setting; 3) it will not only try
to open a potential file at the given path, but will also search in the
folders listed in the ``LAMMPS_POTENTIALS`` environment variable. This
allows to keep potential files in a common location instead of having to
copy them around for simulations.
Old:
.. code-block:: C++
fp = force->open_potential(filename);
fp = fopen(filename, "r");
New:
.. code-block:: C++
fp = utils::open_potential(filename, lmp);
Simplify customized error messages
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: 14May2021
Aided by features of the bundled {fmt} library, error messages now
can have a variable number of arguments and the string will be interpreted
as a {fmt} style format string so that custom error messages can be
easily customized without having to use temporary buffers and ``sprintf()``.
Example:
Old:
.. code-block:: C++
if (fptr == NULL) {
char str[128];
sprintf(str,"Cannot open AEAM potential file %s",filename);
error->one(FLERR,str);
}
New:
.. code-block:: C++
if (fptr == nullptr)
error->one(FLERR, "Cannot open AEAM potential file {}: {}", filename, utils::getsyserror());
Use of "override" instead of "virtual"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: 17Feb2022
Since LAMMPS requires C++11 we switched to use the "override" keyword
instead of "virtual" to indicate polymorphism in derived classes. This
allows the C++ compiler to better detect inconsistencies when an
override is intended or not. Please note that "override" has to be
added to **all** polymorph functions in derived classes and "virtual"
*only* to the function in the base class (or the destructor). Here is
an example from the ``FixWallReflect`` class:
Old:
.. code-block:: C++
FixWallReflect(class LAMMPS *, int, char **);
virtual ~FixWallReflect();
int setmask();
void init();
void post_integrate();
New:
.. code-block:: C++
FixWallReflect(class LAMMPS *, int, char **);
~FixWallReflect() override;
int setmask() override;
void init() override;
void post_integrate() override;
This change set will neither cause a compilation failure, nor will it
change functionality, but if you plan to submit the updated code for
inclusion into the LAMMPS distribution, it will be requested for achieve
a consistent :doc:`programming style <Modify_style>`.
Simplified function names for forward and reverse communication
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: 24Mar2022
Rather then using the function name to distinguish between the different
forward and reverse communication functions for styles, LAMMPS now uses
the type of the "this" pointer argument.
Old:
.. code-block:: C++
comm->forward_comm_pair(this);
comm->forward_comm_fix(this);
comm->forward_comm_compute(this);
comm->forward_comm_dump(this);
comm->reverse_comm_pair(this);
comm->reverse_comm_fix(this);
comm->reverse_comm_compute(this);
comm->reverse_comm_dump(this);
New:
.. code-block:: C++
comm->forward_comm(this);
comm->reverse_comm(this);
This change is **required** or else the code will not compile.
Simplified and more compact neighbor list requests
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: 24Mar2022
This change set reduces the amount of code required to request a
neighbor list. It enforces consistency and no longer requires to change
internal data of the request. More information on neighbor list
requests can be :doc:`found here <Developer_notes>`. Example from the
``ComputeRDF`` class:
Old:
.. code-block:: C++
int irequest = neighbor->request(this,instance_me);
neighbor->requests[irequest]->pair = 0;
neighbor->requests[irequest]->compute = 1;
neighbor->requests[irequest]->occasional = 1;
if (cutflag) {
neighbor->requests[irequest]->cut = 1;
neighbor->requests[irequest]->cutoff = mycutneigh;
}
New:
.. code-block:: C++
auto req = neighbor->add_request(this, NeighConst::REQ_OCCASIONAL);
if (cutflag) req->set_cutoff(mycutneigh);
Public access to the ``NeighRequest`` class data members has been
removed so this update is **required** to avoid compilation failure.
Split of fix STORE into fix STORE/GLOBAL and fix STORE/PERATOM
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: TBD
This change splits the GLOBAL and PERATOM modes of fix STORE into two
separate fixes STORE/GLOBAL and STORE/PERATOM. There was very little
shared code between the two fix STORE modes and the two different code
paths had to be prefixed with if statements. Furthermore, some flags
were used differently in the two modes leading to confusion. Splitting
the code into two fix styles, makes it more easily maintainable. Since
these are internal fixes, there is no user visible change.
Old:
.. code-block:: C++
#include "fix_store.h"
FixStore *fix = dynamic_cast<FixStore *>(
modify->add_fix(fmt::format("{} {} STORE peratom 1 13",id_pole,group->names[0]));
FixStore *fix = dynamic_cast<FixStore *>(modify->get_fix_by_id(id_pole));
New:
.. code-block:: C++
#include "fix_store_peratom.h"
FixStorePeratom *fix = dynamic_cast<FixStorePeratom *>(
modify->add_fix(fmt::format("{} {} STORE/PERATOM 1 13",id_pole,group->names[0]));
FixStorePeratom *fix = dynamic_cast<FixStorePeratom *>(modify->get_fix_by_id(id_pole));
Old:
.. code-block:: C++
#include "fix_store.h"
FixStore *fix = dynamic_cast<FixStore *>(
modify->add_fix(fmt::format("{} {} STORE global 1 1",id_fix,group->names[igroup]));
FixStore *fix = dynamic_cast<FixStore *>(modify->get_fix_by_id(id_fix));
New:
.. code-block:: C++
#include "fix_store_global.h"
FixStoreGlobal *fix = dynamic_cast<FixStoreGlobal *>(
modify->add_fix(fmt::format("{} {} STORE/GLOBAL 1 1",id_fix,group->names[igroup]));
FixStoreGlobal *fix = dynamic_cast<FixStoreGlobal *>(modify->get_fix_by_id(id_fix));
This change is **required** or else the code will not compile.

52
doc/src/Developer_utils.rst
View File

@ -133,6 +133,9 @@ and parsing files or arguments.
.. doxygenfunction:: trim_comment
:project: progguide
.. doxygenfunction:: star_subst
:project: progguide
.. doxygenfunction:: has_utf8
:project: progguide
@ -151,6 +154,9 @@ and parsing files or arguments.
.. doxygenfunction:: trim_and_count_words
:project: progguide
.. doxygenfunction:: join_words
:project: progguide
.. doxygenfunction:: split_words
:project: progguide
@ -202,12 +208,18 @@ Argument processing
Convenience functions
^^^^^^^^^^^^^^^^^^^^^
.. doxygenfunction:: logmesg(LAMMPS *lmp, const S &format, Args&&... args)
.. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &format, Args&&... args)
:project: progguide
.. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &mesg)
:project: progguide
.. doxygenfunction:: errorurl
:project: progguide
.. doxygenfunction:: missing_cmd_args
:project: progguide
.. doxygenfunction:: flush_buffers(LAMMPS *lmp)
:project: progguide
@ -237,6 +249,44 @@ Customized standard functions
---------------------------
Special Math functions
----------------------
The ``MathSpecial`` namespace implements a selection of custom and optimized
mathematical functions for a variety of applications.
.. doxygenfunction:: factorial
:project: progguide
.. doxygenfunction:: exp2_x86
:project: progguide
.. doxygenfunction:: fm_exp
:project: progguide
.. doxygenfunction:: my_erfcx
:project: progguide
.. doxygenfunction:: expmsq
:project: progguide
.. doxygenfunction:: square
:project: progguide
.. doxygenfunction:: cube
:project: progguide
.. doxygenfunction:: powsign
:project: progguide
.. doxygenfunction:: powint
:project: progguide
.. doxygenfunction:: powsinxx
:project: progguide
---------------------------
Tokenizer classes
-----------------

1
doc/src/Errors.rst
View File

@ -11,6 +11,7 @@ them.
:maxdepth: 1
Errors_common
Errors_details
Errors_bugs
Errors_debug
Errors_messages

18
doc/src/Errors_bugs.rst
View File

@ -17,9 +17,8 @@ the steps outlined below:
if your issue has already been reported and if it is still open.
* Check the `GitHub Pull Requests page <https://github.com/lammps/lammps/pulls>`_
to see if there is already a fix for your bug pending.
* Check the `mailing list archives <https://www.lammps.org/mail.html>`_ or
the `LAMMPS forum <https://www.lammps.org/forum.html>`_ to see if the
issue has been discussed before.
* Check the `LAMMPS forum at MatSci <https://matsci.org/lammps/>`_
to see if the issue has been discussed before.
If none of these steps yields any useful information, please file a new
bug report on the `GitHub Issue page <https://github.com/lammps/lammps/issues>`_.
@ -38,12 +37,9 @@ generate this restart from a data file or a simple additional input.
This input deck can be used with tools like a debugger or `valgrind
<https://valgrind.org>`_ to further :doc:`debug the crash <Errors_debug>`.
You may also send an email to the LAMMPS mailing list at
"lammps-users at lists.sourceforge.net" describing the problem with the
same kind of information. The mailing list can provide a faster response,
especially if the bug reported is actually expected behavior. But because
of the high volume of the mailing list, it can happen that your e-mail
is overlooked and then forgotten. Issues on GitHub have to be explicitly
closed, so that will *guarantee* that at least one LAMMPS developer will
have looked at it.
You may also post a message in the `development category of the LAMMPS
forum at MatSci <https://matsci.org/c/lammps/lammps-development/>`_
describing the problem with the same kind of information. The forum can
provide a faster response, especially if the bug reported is actually
expected behavior or other LAMMPS users have come across it before.

27
doc/src/Errors_details.rst Normal file
View File

@ -0,0 +1,27 @@
Error and warning details
=========================
Many errors or warnings are self-explanatory and thus straightforward to
resolve. However, there are also cases, where there is no single cause
and explanation, where LAMMPS can only detect symptoms of an error but
not the exact cause, or where the explanation needs to be more detailed than
what can be fit into a message printed by the program. The following are
discussions of such cases.
.. _err0001:
Unknown identifier in data file
-------------------------------
This error happens when LAMMPS encounters a line of text in an unexpected format
while reading a data file. This is most commonly cause by inconsistent header and
section data. The header section informs LAMMPS how many entries or lines are expected in the
various sections (like Atoms, Masses, Pair Coeffs, *etc.*\ ) of the data file.
If there is a mismatch, LAMMPS will either keep reading beyond the end of a section
or stop reading before the section has ended.
Such a mismatch can happen unexpectedly when the first line of the data
is *not* a comment as required by the format. That would result in
LAMMPS expecting, for instance, 0 atoms because the "atoms" header line
is treated as a comment.

126
doc/src/Errors_messages.rst
View File

@ -476,65 +476,6 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
*Bonds defined but no bond types*
The data file header lists bonds but no bond types.
*Bond/react: Cannot use fix bond/react with non-molecular systems*
Only systems with bonds that can be changed can be used. Atom_style
template does not qualify.
*Bond/react: Invalid template atom ID in map file*
Atom IDs in molecule templates range from 1 to the number of atoms in the template.
*Bond/react: Rmax cutoff is longer than pairwise cutoff*
This is not allowed because bond creation is done using the pairwise
neighbor list.
*Bond/react: Molecule template ID for fix bond/react does not exist*
A valid molecule template must have been created with the molecule
command.
*Bond/react: Reaction templates must contain the same number of atoms*
There should be a one-to-one correspondence between atoms in the
pre-reacted and post-reacted templates, as specified by the map file.
*Bond/react: Unknown section in map file*
Please ensure reaction map files are properly formatted.
*Bond/react: Atom/Bond type affected by reaction too close to template edge*
This means an atom which changes type or connectivity during the
reaction is too close to an 'edge' atom defined in the map
file. This could cause incorrect assignment of bonds, angle, etc.
Generally, this means you must include more atoms in your templates,
such that there are at least two atoms between each atom involved in
the reaction and an edge atom.
*Bond/react: Fix bond/react needs ghost atoms from farther away*
This is because a processor needs to map the entire unreacted
molecule template onto simulation atoms it knows about. The
comm_modify cutoff command can be used to extend the communication
range.
*Bond/react: A deleted atom cannot remain bonded to an atom that is not deleted*
Self-explanatory.
*Bond/react: First neighbors of chiral atoms must be of mutually different types*
Self-explanatory.
*Bond/react: Chiral atoms must have exactly four first neighbors*
Self-explanatory.
*Bond/react: Molecule template 'Coords' section required for chiralIDs keyword*
The coordinates of atoms in the pre-reacted template are used to determine
chirality.
*Bond/react special bond generation overflow*
The number of special bonds per-atom created by a reaction exceeds the
system setting. See the read_data or create_box command for how to
specify this value.
*Bond/react topology/atom exceed system topology/atom*
The number of bonds, angles etc per-atom created by a reaction exceeds
the system setting. See the read_data or create_box command for how to
specify this value.
*Both restart files must use % or neither*
Self-explanatory.
@ -1291,7 +1232,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
*Cannot use chosen neighbor list style with lj/gromacs/kk*
Self-explanatory.
*Cannot use chosen neighbor list style with lj/sdk/kk*
*Cannot use chosen neighbor list style with lj/spica/kk*
That style is not supported by Kokkos.
*Cannot use chosen neighbor list style with pair eam/kk*
@ -1659,10 +1600,10 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
*Cannot use newton pair with lj/gromacs/gpu pair style*
Self-explanatory.
*Cannot use newton pair with lj/sdk/coul/long/gpu pair style*
*Cannot use newton pair with lj/spica/coul/long/gpu pair style*
Self-explanatory.
*Cannot use newton pair with lj/sdk/gpu pair style*
*Cannot use newton pair with lj/spica/gpu pair style*
Self-explanatory.
*Cannot use newton pair with lj96/cut/gpu pair style*
@ -3521,6 +3462,65 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
acquire needed info, The comm_modify cutoff command can be used to
extend the communication range.
*Fix bond/react: Cannot use fix bond/react with non-molecular systems*
Only systems with bonds that can be changed can be used. Atom_style
template does not qualify.
*Fix bond/react: Invalid template atom ID in map file*
Atom IDs in molecule templates range from 1 to the number of atoms in the template.
*Fix bond/react: Rmax cutoff is longer than pairwise cutoff*
This is not allowed because bond creation is done using the pairwise
neighbor list.
*Fix bond/react: Molecule template ID for fix bond/react does not exist*
A valid molecule template must have been created with the molecule
command.
*Fix bond/react: Reaction templates must contain the same number of atoms*
There should be a one-to-one correspondence between atoms in the
pre-reacted and post-reacted templates, as specified by the map file.
*Fix bond/react: Unknown section in map file*
Please ensure reaction map files are properly formatted.
*Fix bond/react: Atom/Bond type affected by reaction too close to template edge*
This means an atom which changes type or connectivity during the
reaction is too close to an 'edge' atom defined in the map
file. This could cause incorrect assignment of bonds, angle, etc.
Generally, this means you must include more atoms in your templates,
such that there are at least two atoms between each atom involved in
the reaction and an edge atom.
*Fix bond/react: Fix bond/react needs ghost atoms from farther away*
This is because a processor needs to map the entire unreacted
molecule template onto simulation atoms it knows about. The
comm_modify cutoff command can be used to extend the communication
range.
*Fix bond/react: A deleted atom cannot remain bonded to an atom that is not deleted*
Self-explanatory.
*Fix bond/react: First neighbors of chiral atoms must be of mutually different types*
Self-explanatory.
*Fix bond/react: Chiral atoms must have exactly four first neighbors*
Self-explanatory.
*Fix bond/react: Molecule template 'Coords' section required for chiralIDs keyword*
The coordinates of atoms in the pre-reacted template are used to determine
chirality.
*Fix bond/react special bond generation overflow*
The number of special bonds per-atom created by a reaction exceeds the
system setting. See the read_data or create_box command for how to
specify this value.
*Fix bond/react topology/atom exceed system topology/atom*
The number of bonds, angles etc per-atom created by a reaction exceeds
the system setting. See the read_data or create_box command for how to
specify this value.
*Fix bond/swap cannot use dihedral or improper styles*
These styles cannot be defined when using this fix.
@ -6810,7 +6810,7 @@ keyword to allow for additional bonds to be formed
This is because the computation of constraint forces within a water
molecule adds forces to atoms owned by other processors.
*Pair style lj/sdk/coul/long/gpu requires atom attribute q*
*Pair style lj/spica/coul/long/gpu requires atom attribute q*
The atom style defined does not have this attribute.
*Pair style nb3b/harmonic requires atom IDs*

25
doc/src/Errors_warnings.rst
View File

@ -68,14 +68,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
length, multiplying by the number of bonds in the interaction (e.g. 3
for a dihedral) and adding a small amount of stretch.
*Bond/react: Atom affected by reaction too close to template edge*
This means an atom which changes type or connectivity during the
reaction is too close to an 'edge' atom defined in the superimpose
file. This could cause incorrect assignment of bonds, angle, etc.
Generally, this means you must include more atoms in your templates,
such that there are at least two atoms between each atom involved in
the reaction and an edge atom.
*Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero*
Self-explanatory.
@ -206,12 +198,20 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*Fix SRD walls overlap but fix srd overlap not set*
You likely want to set this in your input script.
* Fix bond/create is used multiple times or with fix bond/break - may not work as expected*
*Fix bond/create is used multiple times or with fix bond/break - may not work as expected*
When using fix bond/create multiple times or in combination with
fix bond/break, the individual fix instances do not share information
about changes they made at the same time step and thus it may result
in unexpected behavior.
*Fix bond/react: Atom affected by reaction too close to template edge*
This means an atom which changes type or connectivity during the
reaction is too close to an 'edge' atom defined in the superimpose
file. This could cause incorrect assignment of bonds, angle, etc.
Generally, this means you must include more atoms in your templates,
such that there are at least two atoms between each atom involved in
the reaction and an edge atom.
*Fix bond/swap will ignore defined angles*
See the page for fix bond/swap for more info on this
restriction.
@ -470,6 +470,12 @@ This will most likely cause errors in kinetic fluctuations.
*More than one compute sna/atom*
Self-explanatory.
*More than one compute sna/grid*
Self-explanatory.
*More than one compute sna/grid/local*
Self-explanatory.
*More than one compute snad/atom*
Self-explanatory.
@ -804,4 +810,3 @@ This will most likely cause errors in kinetic fluctuations.
*Using pair tail corrections with pair_modify compute no*
The tail corrections will thus not be computed.

6
doc/src/Examples.rst
View File

@ -54,6 +54,8 @@ Lowercase directories
+-------------+------------------------------------------------------------------+
| body | body particles, 2d system |
+-------------+------------------------------------------------------------------+
| bpm | BPM simulations of pouring elastic grains and plate impact |
+-------------+------------------------------------------------------------------+
| cmap | CMAP 5-body contributions to CHARMM force field |
+-------------+------------------------------------------------------------------+
| colloid | big colloid particles in a small particle solvent, 2d system |
@ -94,12 +96,12 @@ Lowercase directories
+-------------+------------------------------------------------------------------+
| latte | examples for using fix latte for DFTB via the LATTE library |
+-------------+------------------------------------------------------------------+
| mdi | use of the MDI package and MolSSI MDI code coupling library |
+-------------+------------------------------------------------------------------+
| meam | MEAM test for SiC and shear (same as shear examples) |
+-------------+------------------------------------------------------------------+
| melt | rapid melt of 3d LJ system |
+-------------+------------------------------------------------------------------+
| message | demos for LAMMPS client/server coupling with the MESSAGE package |
+-------------+------------------------------------------------------------------+
| micelle | self-assembly of small lipid-like molecules into 2d bilayers |
+-------------+------------------------------------------------------------------+
| min | energy minimization of 2d LJ melt |

65
doc/src/Fortran.rst
View File

@ -38,11 +38,11 @@ found together with equivalent examples in C and C++ in the
.. note::
A contributed (and complete!) Fortran interface that more
closely resembles the C-library interface is available
in the ``examples/COUPLE/fortran2`` folder. Please see the
``README`` file in that folder for more information about it
and how to contact its author and maintainer.
A contributed (and more complete!) Fortran interface that more
closely resembles the C-library interface is available in the
``examples/COUPLE/fortran2`` folder. Please see the ``README`` file
in that folder for more information about it and how to contact its
author and maintainer.
----------
@ -65,8 +65,9 @@ the optional logical argument set to ``.true.``. Here is a simple example:
PROGRAM testlib
USE LIBLAMMPS ! include the LAMMPS library interface
IMPLICIT NONE
TYPE(lammps) :: lmp ! derived type to hold LAMMPS instance
CHARACTER(len=*), DIMENSION(*), PARAMETER :: args = &
CHARACTER(len=*), PARAMETER :: args(3) = &
[ CHARACTER(len=12) :: 'liblammps', '-log', 'none' ]
! create a LAMMPS instance (and initialize MPI)
@ -78,6 +79,41 @@ the optional logical argument set to ``.true.``. Here is a simple example:
END PROGRAM testlib
It is also possible to pass command line flags from Fortran to C/C++ and
thus make the resulting executable behave similar to the standalone
executable (it will ignore the `-in/-i` flag, though). This allows to
use the command line to configure accelerator and suffix settings,
configure screen and logfile output, or to set index style variables
from the command line and more. Here is a correspondingly adapted
version of the previous example:
.. code-block:: fortran
PROGRAM testlib2
USE LIBLAMMPS ! include the LAMMPS library interface
IMPLICIT NONE
TYPE(lammps) :: lmp ! derived type to hold LAMMPS instance
CHARACTER(len=128), ALLOCATABLE :: command_args(:)
INTEGER :: i, argc
! copy command line flags to `command_args()`
argc = COMMAND_ARGUMENT_COUNT()
ALLOCATE(command_args(0:argc))
DO i=0, argc
CALL GET_COMMAND_ARGUMENT(i, command_args(i))
END DO
! create a LAMMPS instance (and initialize MPI)
lmp = lammps(command_args)
! get and print numerical version code
PRINT*, 'Program name: ', command_args(0)
PRINT*, 'LAMMPS Version: ', lmp%version()
! delete LAMMPS instance (and shuts down MPI)
CALL lmp%close(.TRUE.)
DEALLOCATE(command_args)
END PROGRAM testlib2
--------------------
Executing LAMMPS commands
@ -102,7 +138,7 @@ Below is a small demonstration of the uses of the different functions:
USE LIBLAMMPS
TYPE(lammps) :: lmp
CHARACTER(len=512) :: cmds
CHARACTER(len=40),ALLOCATABLE :: cmdlist(:)
CHARACTER(len=40), ALLOCATABLE :: cmdlist(:)
CHARACTER(len=10) :: trimmed
INTEGER :: i
@ -111,10 +147,10 @@ Below is a small demonstration of the uses of the different functions:
CALL lmp%command('variable zpos index 1.0')
! define 10 groups of 10 atoms each
ALLOCATE(cmdlist(10))
DO i=1,10
DO i=1, 10
WRITE(trimmed,'(I10)') 10*i
WRITE(cmdlist(i),'(A,I1,A,I10,A,A)') &
'group g',i-1,' id ',10*(i-1)+1,':',ADJUSTL(trimmed)
'group g', i-1, ' id ', 10*(i-1)+1, ':', ADJUSTL(trimmed)
END DO
CALL lmp%commands_list(cmdlist)
! run multiple commands from multi-line string
@ -123,7 +159,7 @@ Below is a small demonstration of the uses of the different functions:
'create_box 1 box' // NEW_LINE('A') // &
'create_atoms 1 single 1.0 1.0 ${zpos}'
CALL lmp%commands_string(cmds)
CALL lmp%close()
CALL lmp%close(.TRUE.)
END PROGRAM testcmd
@ -137,9 +173,9 @@ of the contents of the ``LIBLAMMPS`` Fortran interface to LAMMPS.
.. f:type:: lammps
Derived type that is the general class of the Fortran interface.
It holds a reference to the :cpp:class:`LAMMPS <LAMMPS_NS::LAMMPS>` class instance
that any of the included calls are forwarded to.
Derived type that is the general class of the Fortran interface. It
holds a reference to the :cpp:class:`LAMMPS <LAMMPS_NS::LAMMPS>`
class instance that any of the included calls are forwarded to.
:f c_ptr handle: reference to the LAMMPS class
:f close: :f:func:`close`
@ -202,7 +238,7 @@ of the contents of the ``LIBLAMMPS`` Fortran interface to LAMMPS.
This method will call :cpp:func:`lammps_commands_list` to have LAMMPS
execute a list of input lines.
:p character(len=*) cmd(*): list of LAMMPS input lines
:p character(len=*) cmd(:): list of LAMMPS input lines
.. f:subroutine:: commands_string(str)
@ -210,4 +246,3 @@ of the contents of the ``LIBLAMMPS`` Fortran interface to LAMMPS.
execute a block of commands from a string.
:p character(len=*) str: LAMMPS input in string

4
doc/src/Howto.rst
View File

@ -22,8 +22,9 @@ General howto
Howto_replica
Howto_library
Howto_couple
Howto_client_server
Howto_mdi
Howto_bpm
Howto_broken_bonds
Settings howto
==============
@ -65,6 +66,7 @@ Force fields howto
:maxdepth: 1
Howto_bioFF
Howto_amoeba
Howto_tip3p
Howto_tip4p
Howto_spc

324
doc/src/Howto_amoeba.rst Normal file
View File

@ -0,0 +1,324 @@
AMOEBA and HIPPO force fields
=============================
The AMOEBA and HIPPO polarizable force fields were developed by Jay
Ponder's group at the U Washington at St Louis. The LAMMPS
implementation is based on Fortran 90 code provided by the Ponder
group in their `Tinker MD software <https://dasher.wustl.edu/tinker/>`_.
The current implementation (July 2022) of AMOEBA in LAMMPS matches the
version discussed in :ref:`(Ponder) <amoeba-Ponder>`, :ref:`(Ren)
<amoeba-Ren>`, and :ref:`(Shi) <amoeba-Shi>`. Likewise the current
implementation of HIPPO in LAMMPS matches the version discussed in
:ref:`(Rackers) <amoeba-Rackers>`.
These force fields can be used when polarization effects are desired
in simulations of water, organic molecules, and biomolecules including
proteins, provided that parameterizations (Tinker PRM force field
files) are available for the systems you are interested in. Files in
the LAMMPS potentials directory with a "amoeba" or "hippo" suffix can
be used. The Tinker distribution and website have additional force
field files as well:
`https://github.com/TinkerTools/tinker/tree/release/params
<https://github.com/TinkerTools/tinker/tree/release/params>`_.
Note that currently, HIPPO can only be used for water systems, but
HIPPO files for a variety of small organic and biomolecules are in
preparation by the Ponder group. Those force field files will be
included in the LAMMPS distribution when available.
To use the AMOEBA or HIPPO force fields, a simulation must be 3d, and
fully periodic or fully non-periodic, and use an orthogonal (not
triclinic) simulation box.
----------
The AMOEBA and HIPPO force fields contain the following terms in their
energy (U) computation. Further details for AMOEBA equations are in
:ref:`(Ponder) <amoeba-Ponder>`, further details for the HIPPO
equations are in :ref:`(Rackers) <amoeba-Rackers>`.
.. math::
U & = U_{intermolecular} + U_{intramolecular} \\
U_{intermolecular} & = U_{hal} + U_{repulsion} + U_{dispersion} + U_{multipole} + U_{polar} + U_{qxfer} \\
U_{intramolecular} & = U_{bond} + U_{angle} + U_{torsion} + U_{oop} + U_{b\theta} + U_{UB} + U_{pitorsion} + U_{bitorsion}
For intermolecular terms, the AMOEBA force field includes only the
:math:`U_{hal}`, :math:`U_{multipole}`, :math:`U_{polar}` terms. The
HIPPO force field includes all but the :math:`U_{hal}` term. In
LAMMPS, these are all computed by the :doc:`pair_style amoeba or hippo
<pair_style>` command. Note that the :math:`U_{multipole}` and
:math:`U_{polar}` terms in this formula are not the same for the
AMOEBA and HIPPO force fields.
For intramolecular terms, the :math:`U_{bond}`, :math:`U_{angle}`,
:math:`U_{torsion}`, :math:`U_{oop}` terms are computed by the
:doc:`bond_style class2 <bond_class2>` :doc:`angle_style amoeba
<angle_amoeba>`, :doc:`dihedral_style fourier <dihedral_fourier>`, and
:doc:`improper_style amoeba <improper_amoeba>` commands respectively.
The :doc:`angle_style amoeba <angle_amoeba>` command includes the
:math:`U_{b\theta}` bond-angle cross term, and the :math:`U_{UB}` term
for a Urey-Bradley bond contribution between the I,K atoms in the IJK
angle.
The :math:`U_{pitorsion}` term is computed by the :doc:`fix
amoeba/pitorsion <fix_amoeba_pitorsion>` command. It computes 6-body
interaction between a pair of bonded atoms which each have 2
additional bond partners.
The :math:`U_{bitorsion}` term is computed by the :doc:`fix
amoeba/bitorsion <fix_amoeba_bitorsion>` command. It computes 5-body
interaction between two 4-body torsions (dihedrals) which overlap,
having 3 atoms in common.
These command doc pages have additional details on the terms they
compute:
* :doc:`pair_style amoeba or hippo <pair_amoeba>`
* :doc:`bond_style class2 <bond_class2>`
* :doc:`angle_style amoeba <angle_amoeba>`
* :doc:`dihedral_style fourier <dihedral_fourier>`
* :doc:`improper_style amoeba <improper_amoeba>`
* :doc:`fix amoeba/pitorsion <fix_amoeba_pitorsion>`
* :doc:`fix amoeba/bitorsion <fix_amoeba_bitorsion>`
----------
To use the AMOEBA or HIPPO force fields in LAMMPS, use commands like
the following appropriately in your input script. The only change
needed for AMOEBA vs HIPPO simulation is for the :doc:`pair_style
<pair_style>` and :doc:`pair_coeff <pair_coeff>` commands, as shown
below. See examples/amoeba for example input scripts for both AMOEBA
and HIPPO.
.. code-block:: LAMMPS
units real # required
atom_style amoeba
bond_style class2 # CLASS2 package
angle_style amoeba
dihedral_style fourier # EXTRA-MOLECULE package
improper_style amoeba
# required per-atom data
fix amtype all property/atom i_amtype ghost yes
fix extra all property/atom &
i_amgroup i_ired i_xaxis i_yaxis i_zaxis d_pval ghost yes
fix polaxe all property/atom i_polaxe
fix pit all amoeba/pitorsion # PiTorsion terms in FF
fix_modify pit energy yes
# Bitorsion terms in FF
fix bit all amoeba/bitorsion bitorsion.ubiquitin.data
fix_modify bit energy yes
read_data data.ubiquitin fix amtype NULL "Tinker Types" &
fix pit "pitorsion types" "PiTorsion Coeffs" &
fix pit pitorsions PiTorsions &
fix bit bitorsions BiTorsions
pair_style amoeba # AMOEBA FF
pair_coeff * * amoeba_ubiquitin.prm amoeba_ubiquitin.key
pair_style hippo # HIPPO FF
pair_coeff * * hippo_water.prm hippo_water.key
special_bonds lj/coul 0.5 0.5 0.5 one/five yes # 1-5 neighbors
The data file read by the :doc:`read_data <read_data>` command should
be created by the tools/tinker/tinker2lmp.py conversion program
described below. It will create a section in the data file with the
header "Tinker Types". A :doc:`fix property/atom <fix_property_atom>`
command for the data must be specified before the read_data command.
In the example above the fix ID is *amtype*.
Similarly, if the system you are simulating defines AMOEBA/HIPPO
pitorsion or bitorsion interactions, there will be entries in the data
file for those interactions. They require a :doc:`fix
amoeba/pitortion <fix_amoeba_pitorsion>` and :doc:`fix
amoeba/bitorsion <fix_amoeba_bitorsion>` command be defined. In the
example above, the IDs for these two fixes are *pit* and *bit*.
Of course, if the system being modeled does not have one or more of
the following -- bond, angle, dihedral, improper, pitorsion,
bitorsion interactions -- then the corresponding style and fix
commands above do not need to be used. See the example scripts in
examples/amoeba for water systems as examples; they are simpler than
what is listed above.
The two :doc:`fix property/atom <fix_property_atom>` commands with IDs
(in the example above) *extra* and *polaxe* are also needed to define
internal per-atom quantities used by the AMOEBA and HIPPO force
fields.
The :doc:`pair_coeff <pair_coeff>` command used for either the AMOEBA
or HIPPO force field takes two arguments for Tinker force field files,
namely a PRM and KEY file. The keyfile can be specified as NULL and
default values for a various settings will be used. Note that these 2
files are meant to allow use of native Tinker files as-is. However
LAMMPS does not support all the options which can be included
in a Tinker PRM or KEY file. See specifics below.
A :doc:`special_bonds <special_bonds>` command with the *one/five*
option is required, since the AMOEBA/HIPPO force fields define
weighting factors for not only 1-2, 1-3, 1-4 interactions, but also
1-5 interactions. This command will trigger a per-atom list of 1-5
neighbors to be generated. The AMOEBA and HIPPO force fields define
their own custom weighting factors for all the 1-2, 1-3, 1-4, 1-5
terms which in the Tinker PRM and KEY files; they can be different for
different terms in the force field.
In addition to the list above, these command doc pages have additional
details:
* :doc:`atom_style amoeba <atom_style>`
* :doc:`fix property/atom <fix_property_atom>`
* :doc:`special_bonds <special_bonds>`
----------
Tinker PRM and KEY files
A Tinker PRM file is composed of sections, each of which has multiple
lines. This is the list of PRM sections LAMMPS knows how to parse and
use. Any other sections are skipped:
* Angle Bending Parameters
* Atom Type Definitions
* Atomic Multipole Parameters
* Bond Stretching Parameters
* Charge Penetration Parameters
* Charge Transfer Parameters
* Dipole Polarizability Parameters
* Dispersion Parameters
* Force Field Definition
* Literature References
* Out-of-Plane Bend Parameters
* Pauli Repulsion Parameters
* Pi-Torsion Parameters
* Stretch-Bend Parameters
* Torsion-Torsion Parameters
* Torsional Parameters
* Urey-Bradley Parameters
* Van der Waals Pair Parameters
* Van der Waals Parameters
A Tinker KEY file is composed of lines, each of which has a keyword
followed by zero or more parameters. This is the list of keywords
LAMMPS knows how to parse and use in the same manner Tinker does. Any
other keywords are skipped. The value in parenthesis is the default
value for the keyword if it is not specified, or if the keyfile in the
:doc:`pair_coeff <pair_coeff>` command is specified as NULL:
* a-axis (0.0)
* b-axis (0.0)
* c-axis (0.0)
* ctrn-cutoff (6.0)
* ctrn-taper (0.9 * ctrn-cutoff)
* cutoff
* delta-halgren (0.07)
* dewald (no long-range dispersion unless specified)
* dewald-alpha (0.4)
* dewald-cutoff (7.0)
* dispersion-cutoff (9.0)
* dispersion-taper (9.0 * dispersion-cutoff)
* dpme-grid
* dpme-order (4)
* ewald (no long-range electrostatics unless specified)
* ewald-alpha (0.4)
* ewald-cutoff (7.0)
* gamma-halgren (0.12)
* mpole-cutoff (9.0)
* mpole-taper (0.65 * mpole-cutoff)
* pcg-guess (enabled by default)
* pcg-noguess (disable pcg-guess if specified)
* pcg-noprecond (disable pcg-precond if specified)
* pcg-peek (1.0)
* pcg-precond (enabled by default)
* pewald-alpha (0.4)
* pme-grid
* pme-order (5)
* polar-eps (1.0e-6)
* polar-iter (100)
* polar-predict (no prediction operation unless specified)
* ppme-order (5)
* repulsion-cutoff (6.0)
* repulsion-taper (0.9 * repulsion-cutoff)
* taper
* usolve-cutoff (4.5)
* usolve-diag (2.0)
* vdw-cutoff (9.0)
* vdw-taper (0.9 * vdw-cutoff)
----------
Tinker2lmp.py tool
This conversion tool is found in the tools/tinker directory.
As shown in examples/amoeba/README, these commands produce
the data files found in examples/amoeba, and also illustrate
all the options available to use with the tinker2lmp.py script:
.. code-block:: bash
% python tinker2lmp.py -xyz water_dimer.xyz -amoeba amoeba_water.prm -data data.water_dimer.amoeba # AMOEBA non-periodic system
% python tinker2lmp.py -xyz water_dimer.xyz -hippo hippo_water.prm -data data.water_dimer.hippo # HIPPO non-periodic system
% python tinker2lmp.py -xyz water_box.xyz -amoeba amoeba_water.prm -data data.water_box.amoeba -pbc 18.643 18.643 18.643 # AMOEBA periodic system
% python tinker2lmp.py -xyz water_box.xyz -hippo hippo_water.prm -data data.water_box.hippo -pbc 18.643 18.643 18.643 # HIPPO periodic system
% python tinker2lmp.py -xyz ubiquitin.xyz -amoeba amoeba_ubiquitin.prm -data data.ubiquitin.new -pbc 54.99 41.91 41.91 -bitorsion bitorsion.ubiquitin.data.new # system with bitorsions
Switches and their arguments may be specified in any order.
The -xyz switch is required and specifies an input XYZ file as an
argument. The format of this file is an extended XYZ format defined
and used by Tinker for its input. Example \*.xyz files are in the
examples/amoeba directory. The file lists the atoms in the system.
Each atom has the following information: Tinker species name (ignored
by LAMMPS), xyz coordinates, Tinker numeric type, and a list of atom
IDs the atom is bonded to.
Here is more information about the extended XYZ format defined and
used by Tinker, and links to programs that convert standard PDB files
to the extended XYZ format:
* `http://openbabel.org/docs/current/FileFormats/Tinker_XYZ_format.html <http://openbabel.org/docs/current/FileFormats/Tinker_XYZ_format.html>`_
* `https://github.com/emleddin/pdbxyz-xyzpdb <https://github.com/emleddin/pdbxyz-xyzpdb>`_
* `https://github.com/TinkerTools/tinker/blob/release/source/pdbxyz.f <https://github.com/TinkerTools/tinker/blob/release/source/pdbxyz.f>`_
The -amoeba or -hippo switch is required. It specifies an input
AMOEBA or HIPPO PRM force field file as an argument. This should be
the same file used by the :doc:`pair_style <pair_style>` command in
the input script.
The -data switch is required. It specifies an output file name for
the LAMMPS data file that will be produced.
For periodic systems, the -pbc switch is required. It specifies the
periodic box size for each dimension (x,y,z). For a Tinker simulation
these are specified in the KEY file.
The -bitorsion switch is only needed if the system contains Tinker
bitorsion interactions. The data for each type of bitorsion
interaction will be written to the specified file, and read by the
:doc:`fix amoeba/bitorsion <fix_amoeba_bitorsion>` command. The data
includes 2d arrays of values to which splines are fit, and thus is not
compatible with the LAMMPS data file format.
----------
.. _howto-Ponder:
**(Ponder)** Ponder, Wu, Ren, Pande, Chodera, Schnieders, Haque, Mobley, Lambrecht, DiStasio Jr, M. Head-Gordon, Clark, Johnson, T. Head-Gordon, J Phys Chem B, 114, 2549-2564 (2010).
.. _howto-Rackers:
**(Rackers)** Rackers, Silva, Wang, Ponder, J Chem Theory Comput, 17, 7056-7084 (2021).
.. _howto-Ren:
**(Ren)** Ren and Ponder, J Phys Chem B, 107, 5933 (2003).
.. _howto-Shi:
**(Shi)** Shi, Xia, Zhang, Best, Wu, Ponder, Ren, J Chem Theory Comp, 9, 4046, 2013.

2
doc/src/Howto_body.rst
View File

@ -239,7 +239,7 @@ is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz iyz =
.. parsed-literal::
3 1 27
3 1 19
4
1 1 4 0 0 0
-0.7071 -0.7071 0

119
doc/src/Howto_bpm.rst Normal file
View File

@ -0,0 +1,119 @@
Bonded particle models
======================
The BPM package implements bonded particle models which can be used to
simulate mesoscale solids. Solids are constructed as a collection of
particles which each represent a coarse-grained region of space much
larger than the atomistic scale. Particles within a solid region are
then connected by a network of bonds to provide solid elasticity.
Unlike traditional bonds in molecular dynamics, the equilibrium bond
length can vary between bonds. Bonds store the reference state. This
includes setting the equilibrium length equal to the initial distance
between the two particles but can also include data on the bond
orientation for rotational models. This produces a stress free initial
state. Furthermore, bonds are allowed to break under large strains
producing fracture. The examples/bpm directory has sample input scripts
for simulations of the fragmentation of an impacted plate and the
pouring of extended, elastic bodies.
----------
Bonds can be created using a :doc:`read data <read_data>` or
:doc:`create bonds <create_bonds>` command. Alternatively, a
:doc:`molecule <molecule>` template with bonds can be used with
:doc:`fix deposit <fix_deposit>` or :doc:`fix pour <fix_pour>` to
create solid grains.
In this implementation, bonds store their reference state when they are
first computed in the setup of the first simulation run. Data is then
preserved across run commands and is written to :doc:`binary restart
files <restart>` such that restarting the system will not reset the
reference state of a bond. Bonds that are created midway into a run,
such as those created by pouring grains using :doc:`fix pour
<fix_pour>`, are initialized on that timestep.
As bonds can be broken between neighbor list builds, the
:doc:`special_bonds <special_bonds>` command works differently for BPM
bond styles. There are two possible settings which determine how pair
interactions work between bonded particles. First, one can turn off
all pair interactions between bonded particles. Unlike :doc:`bond
quartic <bond_quartic>`, this is not done by subtracting pair forces
during the bond computation but rather by dynamically updating the
special bond list. This is the default behavior of BPM bond styles and
is done by updating the 1-2 special bond list as bonds break. To do
this, LAMMPS requires :doc:`newton <newton>` bond off such that all
processors containing an atom know when a bond breaks. Additionally,
one must do either (A) or (B).
A) Use the following special bond settings
.. code-block:: LAMMPS
special_bonds lj 0 1 1 coul 1 1 1
These settings accomplish two goals. First, they turn off 1-3 and 1-4
special bond lists, which are not currently supported for BPMs. As
BPMs often have dense bond networks, generating 1-3 and 1-4 special
bond lists is expensive. By setting the lj weight for 1-2 bonds to
zero, this turns off pairwise interactions. Even though there are no
charges in BPM models, setting a nonzero coul weight for 1-2 bonds
ensures all bonded neighbors are still included in the neighbor list
in case bonds break between neighbor list builds.
B) Alternatively, one can simply overlay pair interactions such that all
bonded particles also feel pair interactions. This can be
accomplished by using the *overlay/pair* keyword present in all bpm
bond styles and by using the following special bond settings
.. code-block:: LAMMPS
special_bonds lj/coul 1 1 1
See the :doc:`Howto <Howto_broken_bonds>` page on broken bonds for
more information.
----------
Currently there are two types of bonds included in the BPM
package. The first bond style, :doc:`bond bpm/spring
<bond_bpm_spring>`, only applies pairwise, central body forces. Point
particles must have :doc:`bond atom style <atom_style>` and may be
thought of as nodes in a spring network. Alternatively, the second
bond style, :doc:`bond bpm/rotational <bond_bpm_rotational>`, resolves
tangential forces and torques arising with the shearing, bending, and
twisting of the bond due to rotation or displacement of particles.
Particles are similar to those used in the :doc:`granular package
<Howto_granular>`, :doc:`atom style sphere <atom_style>`. However,
they must also track the current orientation of particles and store bonds
and therefore use a :doc:`bpm/sphere atom style <atom_style>`.
This also requires a unique integrator :doc:`fix nve/bpm/sphere
<fix_nve_bpm_sphere>` which numerically integrates orientation similar
to :doc:`fix nve/asphere <fix_nve_asphere>`.
To monitor the fracture of bonds in the system, all BPM bond styles
have the ability to record instances of bond breakage to output using
the :doc:`dump local <dump>` command. Additionally, one can use
:doc:`compute nbond/atom <compute_nbond_atom>` to tally the current
number of bonds per atom.
In addition to bond styles, a new pair style :doc:`pair bpm/spring
<pair_bpm_spring>` was added to accompany the bpm/spring bond
style. This pair style is simply a hookean repulsion with similar
velocity damping as its sister bond style.
----------
While LAMMPS has many utilities to create and delete bonds, *only*
the following are currently compatible with BPM bond styles:
* :doc:`create_bonds <create_bonds>`
* :doc:`delete_bonds <delete_bonds>`
* :doc:`fix bond/create <fix_bond_create>`
* :doc:`fix bond/break <fix_bond_break>`
* :doc:`fix bond/swap <fix_bond_swap>`
Note :doc:`create_bonds <create_bonds>` requires certain special_bonds settings.
To subtract pair interactions, one will need to switch between different
special_bonds settings in the input script. An example is found in
examples/bpm/impact.

48
doc/src/Howto_broken_bonds.rst Normal file
View File

@ -0,0 +1,48 @@
Broken Bonds
============
Typically, bond interactions persist for the duration of a simulation
in LAMMPS. However, there are some exceptions that allow for bonds to
break including the :doc:`quartic bond style <bond_quartic>` and the
bond styles in the :doc:`BPM package <Howto_bpm>` which contains the
:doc:`bpm/spring <bond_bpm_spring>` and
:doc:`bpm/rotational <bond_bpm_rotational>` bond styles. In these cases,
a bond can be broken if it is stretched beyond a user-defined threshold.
LAMMPS accomplishes this by setting the bond type to zero such that the
bond force is no longer computed.
Users are normally able to weight the contribution of pair forces to atoms
that are bonded using the :doc:`special_bonds command <special_bonds>`.
When bonds break, this is not always the case. For the quartic bond style,
pair forces are always turned off between bonded particles. LAMMPS does
this via a computational sleight-of-hand. It subtracts the pairwise
interaction as part of the bond computation. When the bond breaks, the
subtraction stops. For this to work, the pairwise interaction must always
be computed by the :doc:`pair_style <pair_style>` command, whether the bond
is broken or not. This means that :doc:`special_bonds <special_bonds>` must
be set to 1,1,1. After the bond breaks, the pairwise interaction between the
two atoms is turned on, since they are no longer bonded.
In the BPM package, one can either turn off all pair interactions between
bonded particles or leave them on, overlaying pair forces on top of bond
forces. To remove pair forces, the special bond list is dynamically
updated. More details can be found on the :doc:`Howto BPM <Howto_bpm>`
page.
Bonds can also be broken by fixes which change bond topology, including
:doc:`fix bond/break <fix_bond_break>` and
:doc:`fix bond/react <fix_bond_react>`. These fixes will automatically
trigger a rebuild of the neighbor list and update special bond data structures
when bonds are broken.
Note that when bonds are dumped to a file via the :doc:`dump local <dump>` command, bonds with type 0 are not included. The
:doc:`delete_bonds <delete_bonds>` command can also be used to query the
status of broken bonds or permanently delete them, e.g.:
.. code-block:: LAMMPS
delete_bonds all stats
delete_bonds all bond 0 remove
The compute :doc:`nbond/atom <compute_nbond_atom>` can also be used
to tally the current number of bonds per atom, excluding broken bonds.

163
doc/src/Howto_client_server.rst
View File

@ -1,163 +0,0 @@
Using LAMMPS in client/server mode
==================================
Client/server coupling of two codes is where one code is the "client"
and sends request messages to a "server" code. The server responds to
each request with a reply message. This enables the two codes to work
in tandem to perform a simulation. LAMMPS can act as either a client
or server code.
Some advantages of client/server coupling are that the two codes run
as stand-alone executables; they are not linked together. Thus
neither code needs to have a library interface. This often makes it
easier to run the two codes on different numbers of processors. If a
message protocol (format and content) is defined for a particular kind
of simulation, then in principle any code that implements the
client-side protocol can be used in tandem with any code that
implements the server-side protocol, without the two codes needing to
know anything more specific about each other.
A simple example of client/server coupling is where LAMMPS is the
client code performing MD timestepping. Each timestep it sends a
message to a server quantum code containing current coords of all the
atoms. The quantum code computes energy and forces based on the
coords. It returns them as a message to LAMMPS, which completes the
timestep.
A more complex example is where LAMMPS is the client code and
processes a series of data files, sending each configuration to a
quantum code to compute energy and forces. Or LAMMPS runs dynamics
with an atomistic force field, but pauses every N steps to ask the
quantum code to compute energy and forces.
Alternate methods for code coupling with LAMMPS are described on
the :doc:`Howto couple <Howto_couple>` doc page.
The protocol for using LAMMPS as a client is to use these 3 commands
in this order (other commands may come in between):
* :doc:`message client <message>` # initiate client/server interaction
* :doc:`fix client/md <fix_client_md>` # any client fix which makes specific requests to the server
* :doc:`message quit <message>` # terminate client/server interaction
In between the two message commands, a client fix command and
:doc:`unfix <unfix>` command can be used multiple times. Similarly,
this sequence of 3 commands can be repeated multiple times, assuming
the server program operates in a similar fashion, to initiate and
terminate client/server communication.
The protocol for using LAMMPS as a server is to use these 2 commands
in this order (other commands may come in between):
* :doc:`message server <message>` # initiate client/server interaction
* :doc:`server md <server_md>` # any server command which responds to specific requests from the client
This sequence of 2 commands can be repeated multiple times, assuming
the client program operates in a similar fashion, to initiate and
terminate client/server communication.
LAMMPS support for client/server coupling is in its :ref:`MESSAGE package <PKG-MESSAGE>` which implements several
commands that enable LAMMPS to act as a client or server, as discussed
below. The MESSAGE package also wraps a client/server library called
CSlib which enables two codes to exchange messages in different ways,
either via files, sockets, or MPI. The CSlib is provided with LAMMPS
in the lib/message dir. The CSlib has its own
`website <https://cslib.sandia.gov>`_ with documentation and test
programs.
.. note::
For client/server coupling to work between LAMMPS and another
code, the other code also has to use the CSlib. This can sometimes be
done without any modifications to the other code by simply wrapping it
with a Python script that exchanges CSlib messages with LAMMPS and
prepares input for or processes output from the other code. The other
code also has to implement a matching protocol for the format and
content of messages that LAMMPS exchanges with it.
These are the commands currently in the MESSAGE package for two
protocols, MD and MC (Monte Carlo). New protocols can easily be
defined and added to this directory, where LAMMPS acts as either the
client or server.
* :doc:`message <message>`
* :doc:`fix client md <fix_client_md>` = LAMMPS is a client for running MD
* :doc:`server md <server_md>` = LAMMPS is a server for computing MD forces
* :doc:`server mc <server_mc>` = LAMMPS is a server for computing a Monte Carlo energy
The server doc files give details of the message protocols
for data that is exchanged between the client and server.
These example directories illustrate how to use LAMMPS as either a
client or server code:
* examples/message
* examples/COUPLE/README
* examples/COUPLE/lammps_mc
* examples/COUPLE/lammps_nwchem
* examples/COUPLE/lammps_vasp
The examples/message directory couples a client instance of LAMMPS to a
server instance of LAMMPS.
The files in the *lammps_mc* folder show how to couple LAMMPS as
a server to a simple Monte Carlo client code as the driver.
The files in the *lammps_nwchem* folder show how to couple LAMMPS
as a client code running MD timestepping to NWChem acting as a
server providing quantum DFT forces, through a Python wrapper script
on NWChem.
The files in the *lammps_vasp* folder show how to couple LAMMPS as
a client code running MD timestepping to VASP acting as a server
providing quantum DFT forces, through a Python wrapper script on VASP.
Here is how to launch a client and server code together for any of the
4 modes of message exchange that the :doc:`message <message>` command
and the CSlib support. Here LAMMPS is used as both the client and
server code. Another code could be substituted for either.
The examples below show launching both codes from the same window (or
batch script), using the "&" character to launch the first code in the
background. For all modes except *mpi/one*, you could also launch the
codes in separate windows on your desktop machine. It does not
matter whether you launch the client or server first.
In these examples either code can be run on one or more processors.
If running in a non-MPI mode (file or zmq) you can launch a code on a
single processor without using mpirun.
IMPORTANT: If you run in mpi/two mode, you must launch both codes via
mpirun, even if one or both of them runs on a single processor. This
is so that MPI can figure out how to connect both MPI processes
together to exchange MPI messages between them.
For message exchange in *file*, *zmq*, or *mpi/two* modes:
.. code-block:: bash
% mpirun -np 1 lmp_mpi -log log.client < in.client &
% mpirun -np 2 lmp_mpi -log log.server < in.server
% mpirun -np 4 lmp_mpi -log log.client < in.client &
% mpirun -np 1 lmp_mpi -log log.server < in.server
% mpirun -np 2 lmp_mpi -log log.client < in.client &
% mpirun -np 4 lmp_mpi -log log.server < in.server
For message exchange in *mpi/one* mode:
Launch both codes in a single mpirun command:
.. code-block:: bash
mpirun -np 2 lmp_mpi -mpicolor 0 -in in.message.client -log log.client : -np 4 lmp_mpi -mpicolor 1 -in in.message.server -log log.server
The two -np values determine how many procs the client and the server
run on.
A LAMMPS executable run in this manner must use the -mpicolor color
command-line option as their its option, where color is an integer
label that will be used to distinguish one executable from another in
the multiple executables that the mpirun command launches. In this
example the client was colored with a 0, and the server with a 1.

28
doc/src/Howto_couple.rst
View File

@ -12,16 +12,16 @@ LAMMPS can be coupled to other codes in at least 4 ways. Each has
advantages and disadvantages, which you will have to think about in the
context of your application.
1. Define a new :doc:`fix <fix>` command that calls the other code. In
this scenario, LAMMPS is the driver code. During timestepping,
1. Define a new :doc:`fix <fix>` command that calls the other code.
In this scenario, LAMMPS is the driver code. During timestepping,
the fix is invoked, and can make library calls to the other code,
which has been linked to LAMMPS as a library. This is the way how the
which has been linked to LAMMPS as a library. This is the way the
:ref:`LATTE <PKG-LATTE>` package, which performs density-functional
tight-binding calculations using the `LATTE software <https://github.com/lanl/LATTE>`_
to compute forces, is hooked to LAMMPS.
See the :doc:`fix latte <fix_latte>` command for more details.
Also see the :doc:`Modify <Modify>` doc pages for info on how to
add a new fix to LAMMPS.
tight-binding calculations using the `LATTE software
<https://github.com/lanl/LATTE>`_ to compute forces, is hooked to
LAMMPS. See the :doc:`fix latte <fix_latte>` command for more
details. Also see the :doc:`Modify <Modify>` doc pages for info on
how to add a new fix to LAMMPS.
.. spacer
@ -58,6 +58,12 @@ context of your application.
.. spacer
4. Couple LAMMPS with another code in a client/server mode. This is
described on the :doc:`Howto client/server <Howto_client_server>` doc
page.
4. Couple LAMMPS with another code in a client/server fashion, using
using the `MDI Library
<https://molssi-mdi.github.io/MDI_Library/html/index.html>`_
developed by the `Molecular Sciences Software Institute (MolSSI)
<https://molssi.org>`_ to run LAMMPS as either an MDI driver
(client) or an MDI engine (server). The MDI driver issues commands
to the MDI server to exchange data between them. See the
:doc:`Howto mdi <Howto_mdi>` page for more information about how
LAMMPS can operate in either of these modes.

39
doc/src/Howto_elastic.rst
View File

@ -18,23 +18,52 @@ At zero temperature, it is easy to estimate these derivatives by
deforming the simulation box in one of the six directions using the
:doc:`change_box <change_box>` command and measuring the change in the
stress tensor. A general-purpose script that does this is given in the
examples/elastic directory described on the :doc:`Examples <Examples>`
examples/ELASTIC directory described on the :doc:`Examples <Examples>`
doc page.
Calculating elastic constants at finite temperature is more
challenging, because it is necessary to run a simulation that performs
time averages of differential properties. One way to do this is to
measure the change in average stress tensor in an NVT simulations when
time averages of differential properties. There are at least
3 ways to do this in LAMMPS. The most reliable way to do this is
by exploiting the relationship between elastic constants, stress
fluctuations, and the Born matrix, the second derivatives of energy
w.r.t. strain :ref:`(Ray) <Ray>`.
The Born matrix calculation has been enabled by
the :doc:`compute born/matrix <compute_born_matrix>` command,
which works for any bonded or non-bonded potential in LAMMPS.
The most expensive part of the calculation is the sampling of
the stress fluctuations. Several examples of this method are
provided in the examples/ELASTIC_T/BORN_MATRIX directory
described on the :doc:`Examples <Examples>` doc page.
A second way is to measure
the change in average stress tensor in an NVT simulations when
the cell volume undergoes a finite deformation. In order to balance
the systematic and statistical errors in this method, the magnitude of
the deformation must be chosen judiciously, and care must be taken to
fully equilibrate the deformed cell before sampling the stress
tensor. Another approach is to sample the triclinic cell fluctuations
tensor. An example of this method is provided in the
examples/ELASTIC_T/DEFORMATION directory
described on the :doc:`Examples <Examples>` doc page.
Another approach is to sample the triclinic cell fluctuations
that occur in an NPT simulation. This method can also be slow to
converge and requires careful post-processing :ref:`(Shinoda) <Shinoda1>`
converge and requires careful post-processing :ref:`(Shinoda) <Shinoda1>`.
We do not provide an example of this method.
A nice review of the advantages and disadvantages of all of these methods
is provided in the paper by Clavier et al. :ref:`(Clavier) <Clavier>`.
----------
.. _Ray:
**(Ray)** J. R. Ray and A. Rahman, J Chem Phys, 80, 4423 (1984).
.. _Shinoda1:
**(Shinoda)** Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).
.. _Clavier:
**(Clavier)** G. Clavier, N. Desbiens, E. Bourasseau, V. Lachet, N. Brusselle-Dupend and B. Rousseau, Mol Sim, 43, 1413 (2017).

237
doc/src/Howto_mdi.rst
View File

@ -1,132 +1,163 @@
Using LAMMPS with the MDI library for code coupling
===================================================
.. note::
This Howto page will eventually replace the
:doc:`Howto client/server <Howto_client_server>` doc page.
Client/server coupling of two codes is where one code is the "client"
and sends request messages (data) to a "server" code. The server
responds to each request with a reply message. This enables the two
codes to work in tandem to perform a simulation. LAMMPS can act as
either a client or server code; it does this by using the `MolSSI
Driver Interface (MDI) library
<https://molssi-mdi.github.io/MDI_Library/html/index.html>`_,
Client/server coupling of two (or more) codes is where one code is the
"client" and sends request messages (data) to one (or more) "server"
code(s). A server responds to each request with a reply message
(data). This enables two (or more) codes to work in tandem to perform
a simulation. In this context, LAMMPS can act as either a client or
server code. It does this by using the `MolSSI Driver Interface (MDI)
library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_,
developed by the `Molecular Sciences Software Institute (MolSSI)
<https://molssi.org>`_.
<https://molssi.org>`_, which is supported by the :ref:`MDI <PKG-MDI>`
package.
Alternate methods for code coupling with LAMMPS are described on the
:doc:`Howto couple <Howto_couple>` doc page.
Some advantages of client/server coupling are that the two codes can run
Some advantages of client/server coupling are that the codes can run
as stand-alone executables; they need not be linked together. Thus
neither code needs to have a library interface. This also makes it easy
to run the two codes on different numbers of processors. If a message
protocol (format and content) is defined for a particular kind of
simulation, then in principle any code which implements the client-side
protocol can be used in tandem with any code which implements the
server-side protocol. Neither code needs to know what specific other
code it is working with.
neither code needs to have a library interface. This also makes it
easy to run the two codes on different numbers of processors. If a
message protocol (format and content) is defined for a particular kind
of simulation, then in principle any code which implements the
client-side protocol can be used in tandem with any code which
implements the server-side protocol. Neither code needs to know what
specific other code it is working with.
In MDI nomenclature, a client code is the "driver", and a server code is
an "engine". One driver code can communicate with one or more instances
of one or more engine codes. Driver and engine codes can be written in
any language: C, C++, Fortran, Python, etc.
In addition to allowing driver and engine(s) running to run as
stand-alone executables, MDI also enables a server code to be a
"plugin" to the client code. In this scenario, server code(s) are
compiled as shared libraries, and one (or more) instances of the
server are instantiated by the driver code. If the driver code runs
in parallel, it can split its MPI communicator into multiple
sub-communicators, and launch each plugin engine instance on a
sub-communicator. Driver processors in that sub-communicator exchange
messages with that engine instance, and can also send MPI messages to
other processors in the driver. The driver code can also destroy
engine instances and re-instantiate them.
In addition to allowing driver and engine(s) to run as stand-alone
executables, MDI also enables an engine to be a *plugin* to the client
code. In this scenario, server code(s) are compiled as shared
libraries, and one (or more) instances of the server are instantiated
by the driver code. If the driver code runs in parallel, it can split
its MPI communicator into multiple sub-communicators, and launch each
plugin engine instance on a sub-communicator. Driver processors
within that sub-communicator exchange messages with the corresponding
engine instance, and can also send MPI messages to other processors in
the driver. The driver code can also destroy engine instances and
re-instantiate them. LAMMPS can operate as either a stand-alone or
plugin MDI engine. When it operates as a driver, if can use either
stand-alone or plugin MDI engines.
The way that a driver communicates with an engine is by making
MDI_Send() and MDI_Recv() calls, which are conceptually similar to
MPI_Send() and MPI_Recv() calls. Each send or receive has a string
which identifies the command name, and optionally some data, which can
be a single value or vector of values of any data type. Inside the
MDI library, data is exchanged between the driver and engine via MPI
calls or sockets. This a run-time choice by the user.
The way in which an MDI driver communicates with an MDI engine is by
making MDI_Send() and MDI_Recv() calls, which are conceptually similar
to MPI_Send() and MPI_Recv() calls. Each send or receive operation
uses a string to identify the command name, and optionally some data,
which can be a single value or vector of values of any data type.
Inside the MDI library, data is exchanged between the driver and
engine via MPI calls or sockets. This a run-time choice by the user.
----------
The :ref:`MDI <PKG-MDI>` package provides a :doc:`mdi engine <mdi>`
command which enables LAMMPS to operate as an MDI engine. Its doc
page explains the variety of standard and custom MDI commands which
the LAMMPS engine recognizes and can respond to.
The package also provides a :doc:`mdi plugin <mdi>` command which
enables LAMMPS to operate as an MDI driver and load an MDI engine as a
plugin library.
The package also has a `fix mdi/qm <fix_mdi_qm>` command in which
LAMMPS operates as an MDI driver in conjunction with a quantum
mechanics code as an MDI engine. The post_force() method of the
fix_mdi_qm.cpp file shows how a driver issues MDI commands to another
code. This command can be used to couple to an MDI engine which is
either a stand-alone code or a plugin library.
As explained on the `fix mdi/qm <fix_mdi_qm>` command doc page, it can
be used to perform *ab initio* MD simulations or energy minimizations,
or to evaluate the quantum energy and forces for a series of
independent systems. The examples/mdi directory has example input
scripts for all of these use cases.
----------
The examples/mdi directory contains Python scripts and LAMMPS input
script which use LAMMPS as either an MDI driver or engine or both.
Currently, 5 example use cases are provided:
* Run ab initio MD (AIMD) using 2 instances of LAMMPS. As a driver
LAMMPS performs the timestepping in either NVE or NPT mode. As an
engine, LAMMPS computes forces and is a surrogate for a quantum
code.
* As a driver, LAMMPS runs an MD simulation. Every N steps it passes
the current snapshot to an MDI engine to evaluate the energy,
virial, and peratom forces. As the engine LAMMPS is a surrogate for
a quantum code.
* As a driver, LAMMPS loops over a series of data files and passes the
configuration to an MDI engine to evaluate the energy, virial, and
peratom forces. As the engine LAMMPS is a surrogate for a quantum
code.
* A Python script driver invokes a sequence of unrelated LAMMPS
calculations. Calculations can be single-point energy/force
evaluations, MD runs, or energy minimizations.
* Run AIMD with a Python driver code and 2 LAMMPS instances as
engines. The first LAMMPS instance performs MD timestepping. The
second LAMMPS instance acts as a surrogate QM code to compute
forces.
Note that in any of these example where LAMMPS is used as an engine,
an actual QM code (which supports MDI) could be used in its place,
without modifying the input scripts or launch commands, except to
specify the name of the QM code.
The examples/mdi/Run.sh file illustrates how to launch both driver and
engine codes so that they communicate using the MDI library via either
MPI or sockets. Or using the engine as a stand-alone code or plugin
library.
-------------
As an example, LAMMPS and the ``pw.x`` command from Quantum Espresso (a
suite of quantum DFT codes), can work together via the MDI library to
perform an ab initio MD (AIMD) simulation, where LAMMPS runs an MD
simulation and sends a message each timestep to ``pw.x`` asking it to
compute quantum forces on the current configuration of atoms. Here is
how the 2 codes are launched to communicate by MPI:
Currently there are at least two quantum DFT codes which have direct
MDI support, `Quantum ESPRESSO (QE)
<https://www.quantum-espresso.org/>`_ and `INQ
<https://qsg.llnl.gov/node/101.html>`_. There are also several QM
codes which have indirect support through QCEngine or i-PI. The
former means they require a wrapper program (QCEngine) with MDI
support which writes/read files to pass data to the quantum code
itself. The list of QCEngine-supported and i-PI-supported quantum
codes is on the `MDI webpage
<https://molssi-mdi.github.io/MDI_Library/html/index.html>`_.
Here is how to build QE as a stand-alone ``pw.x`` file which can be
used in stand-alone mode:
.. code-block:: bash
% mpirun -np 2 lmp_mpi -mdi "-role DRIVER -name d -method MPI" \
-in in.aimd : -np 16 pw.x -in qe.in -mdi "-role ENGINE -name e -method MPI"
% git clone --branch mdi_plugin https://github.com/MolSSI-MDI/q-e.git <base_path>/q-e
% build the executable pw.x, following the `QE build guide <https://gitlab.com/QEF/q-e/-/wikis/Developers/CMake-build-system>`_
In this case LAMMPS runs on 2 processors (MPI tasks), ``pw.x`` runs on 16
processors.
Here is how the 2 codes are launched to communicate by sockets:
Here is how to build QE as a shared library which can be used in plugin mode,
which results in a libqemdi.so file in <base_path>/q-e/MDI/src:
.. code-block:: bash
% mpirun -np 2 lmp_mpi -mdi "-role DRIVER -name d -method TCP -port 8021" -in in.aimd
% mpirun -np 16 pw.x -in qe.in -mdi "-role ENGINE -name e -method TCP -port 8021 -hostname localhost"
% git clone --branch mdi_plugin https://github.com/MolSSI-MDI/q-e.git <base_path>/q-e
% cd <base_path>/q-e
% ./configure --enable-parallel --enable-openmp --enable-shared FFLAGS="-fPIC" FCFLAGS="-fPIC" CFLAGS="-fPIC" foxflags="-fPIC" try_foxflags="-fPIC"
% make -j 4 mdi
These commands could be issued in different windows on a desktop
machine. Or in the same window, if the first command is ended with
"&" so as to run in the background. If "localhost" is replaced by an
IP address, ``pw.x`` could be run on another machine on the same network, or
even on another machine across the country.
INQ cannot be built as a stand-alone code; it is by design a library.
Here is how to build INQ as a shared library which can be used in
plugin mode, which results in a libinqmdi.so file in
<base_path>/inq/build/examples:
After both codes initialize themselves to model the same system, this is
what occurs each timestep:
.. code-block:: bash
* LAMMPS send a ">COORDS" message to ``pw.x`` with a 3*N vector of current atom coords
* ``pw.x`` receives the message/coords and computes quantum forces on all the atoms
* LAMMPS send a "<FORCES" message to ``pw.x`` and waits for the result
* ``pw.x`` receives the message (after its computation finishes) and sends a 3*N vector of forces
* LAMMPS receives the forces and time integrates to complete a single timestep
-------------
Examples scripts for using LAMMPS as an MDI engine are in the
examples/mdi directory. See the README file in that directory for
instructions on how to run the examples.
.. note::
Work is underway to add commands that allow LAMMPS to be used as an
MDI driver, e.g. for the AIMD example discussed above. Example
scripts for this usage mode will be added the same directory when
available.
If LAMMPS is used as a stand-alone engine it should set up the system
it will be modeling in its input script, then invoke the
:doc:`mdi/engine <mdi_engine>` command. This will put LAMMPS into
"engine mode" where it waits for messages and data from the driver.
When the driver sends an "EXIT" command, LAMMPS will exit engine mode
and the input script will continue.
If LAMMPS is used as a plugin engine it operates the same way, except
that the driver will pass LAMMPS an input script to initialize itself.
Upon receiving the "EXIT" command, LAMMPS will exit engine mode and the
input script will continue. After finishing execution of the input
script, the instance of LAMMPS will be destroyed.
LAMMPS supports the full set of MD-appropriate engine commands defined
by the MDI library. See the :doc:`mdi/engine <mdi_engine>` page for
a list of these.
If those commands are not sufficient for a user-developed driver to use
LAMMPS as an engine, then new commands can be easily added. See these
two files which implement the definition of MDI commands and the logic
for responding to them:
* src/MDI/mdi_engine.cpp
* src/MDI/fix_mdi_engine.cpp
% git clone --branch mdi --recurse-submodules https://gitlab.com/taylor-a-barnes/inq.git <base_path>/inq
% cd <base_path>/inq
% mkdir -p build
% cd build
% ../configure --prefix=<install_path>/install
% make -j 4
% make install

2
doc/src/Howto_spc.rst
View File

@ -19,7 +19,7 @@ atoms and the water molecule to run a rigid SPC model.
| LJ :math:`\sigma` of OO = 3.166
| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
| :math:`r_0` of OH bond = 1.0
| :math:`\theta` of HOH angle = 109.47\ :math:`^{\circ}`
| :math:`\theta_0` of HOH angle = 109.47\ :math:`^{\circ}`
|
Note that as originally proposed, the SPC model was run with a 9

140
doc/src/Howto_structured_data.rst
View File

@ -55,6 +55,9 @@ JSON
YAML format thermo_style output
===============================
Extracting data from log file
-----------------------------
.. versionadded:: 24Mar2022
LAMMPS supports the thermo style "yaml" and for "custom" style
@ -66,7 +69,7 @@ the following style:
.. code-block:: yaml
---
keywords: [Step, Temp, E_pair, E_mol, TotEng, Press, ]
keywords: ['Step', 'Temp', 'E_pair', 'E_mol', 'TotEng', 'Press', ]
data:
- [100, 0.757453103239935, -5.7585054860159, 0, -4.62236133677021, 0.207261053624721, ]
- [110, 0.759322359337036, -5.7614668389562, 0, -4.62251889318624, 0.194314975399602, ]
@ -79,6 +82,10 @@ This data can be extracted and parsed from a log file using python with:
.. code-block:: python
import re, yaml
try:
from yaml import CSafeLoader as Loader
except ImportError:
from yaml import SafeLoader as Loader
docs = ""
with open("log.lammps") as f:
@ -86,7 +93,7 @@ This data can be extracted and parsed from a log file using python with:
m = re.search(r"^(keywords:.*$|data:$|---$|\.\.\.$| - \[.*\]$)", line)
if m: docs += m.group(0) + '\n'
thermo = list(yaml.load_all(docs, Loader=yaml.SafeLoader))
thermo = list(yaml.load_all(docs, Loader=Loader))
print("Number of runs: ", len(thermo))
print(thermo[1]['keywords'][4], ' = ', thermo[1]['data'][2][4])
@ -105,6 +112,135 @@ of that run:
Number of runs: 2
TotEng = -4.62140097780047
.. versionadded:: 4May2022
YAML format output has been added to multiple commands in LAMMPS,
for example :doc:`dump yaml <dump>` or :doc:`fix ave/time <fix_ave_time>`
Depending on the kind of data being written, organization of the data
or the specific syntax used may change, but the principles are very
similar and all files should be readable with a suitable YAML parser.
Processing scalar data with Python
----------------------------------
.. figure:: JPG/thermo_bondeng.png
:figwidth: 33%
:align: right
After reading and parsing the YAML format data, it can be easily
imported for further processing and visualization with the `pandas
<https://pandas.pydata.org/>`_ and `matplotlib
<https://matplotlib.org/>`_ Python modules. Because of the organization
of the data in the YAML format thermo output, it needs to be told to
process only the 'data' part of the imported data to create a pandas
data frame, and one needs to set the column names from the 'keywords'
entry. The following Python script code example demonstrates this, and
creates the image shown on the right of a simple plot of various bonded
energy contributions versus the timestep from a run of the 'peptide'
example input after changing the :doc:`thermo style <thermo_style>` to
'yaml'. The properties to be used for x and y values can be
conveniently selected through the keywords. Please note that those
keywords can be changed to custom strings with the :doc:`thermo_modify
colname <thermo_modify>` command.
.. code-block:: python
import re, yaml
import pandas as pd
import matplotlib.pyplot as plt
try:
from yaml import CSafeLoader as Loader
except ImportError:
from yaml import SafeLoader as Loader
docs = ""
with open("log.lammps") as f:
for line in f:
m = re.search(r"^(keywords:.*$|data:$|---$|\.\.\.$| - \[.*\]$)", line)
if m: docs += m.group(0) + '\n'
thermo = list(yaml.load_all(docs, Loader=Loader))
df = pd.DataFrame(data=thermo[0]['data'], columns=thermo[0]['keywords'])
fig = df.plot(x='Step', y=['E_bond', 'E_angle', 'E_dihed', 'E_impro'], ylabel='Energy in kcal/mol')
plt.savefig('thermo_bondeng.png')
Processing vector data with Python
----------------------------------
Global *vector* data as produced by :doc:`fix ave/time <fix_ave_time>`
uses a slightly different organization of the data. You still have the
dictionary keys 'keywords' and 'data' for the column headers and the
data. But the data is a dictionary indexed by the time step and for
each step there are multiple rows of values each with a list of the
averaged properties. This requires a slightly different processing,
since the entire data cannot be directly imported into a single pandas
DataFrame class instance. The following Python script example
demonstrates how to read such data. The result will combine the data
for the different steps into one large "multi-index" table. The pandas
IndexSlice class can then be used to select data from this combined data
frame.
.. code-block:: python
import yaml
import pandas as pd
try:
from yaml import CSafeLoader as Loader
except ImportError:
from yaml import SafeLoader as Loader
with open("ave.yaml") as f:
ave = yaml.load(f, Loader=Loader)
keys = ave['keywords']
df = {}
for k in ave['data'].keys():
df[k] = pd.DataFrame(data=ave['data'][k], columns=keys)
# create multi-index data frame
df = pd.concat(df)
# output only the first 3 value for steps 200 to 300 of the column Pressure
idx = pd.IndexSlice
print(df['Pressure'].loc[idx[200:300, 0:2]])
Processing scalar data with Perl
--------------------------------
The ease of processing YAML data is not limited to Python. Here is an
example for extracting and processing a LAMMPS log file with Perl instead.
.. code-block:: perl
use YAML::XS;
open(LOG, "log.lammps") or die("could not open log.lammps: $!");
my $file = "";
while(my $line = <LOG>) {
if ($line =~ /^(keywords:.*$|data:$|---$|\.\.\.$| - \[.*\]$)/) {
$file .= $line;
}
}
close(LOG);
# convert YAML to perl as nested hash and array references
my $thermo = Load $file;
# convert references to real arrays
my @keywords = @{$thermo->{'keywords'}};
my @data = @{$thermo->{'data'}};
# print first two columns
print("$keywords[0] $keywords[1]\n");
foreach (@data) {
print("${$_}[0] ${$_}[1]\n");
}
Writing continuous data during a simulation
===========================================

17
doc/src/Howto_viscosity.rst
View File

@ -68,7 +68,8 @@ liquid Ar via the GK formalism:
# Sample LAMMPS input script for viscosity of liquid Ar
units real
variable T equal 86.4956
variable T equal 200.0 # run temperature
variable Tinit equal 250.0 # equilibration temperature
variable V equal vol
variable dt equal 4.0
variable p equal 400 # correlation length
@ -99,12 +100,14 @@ liquid Ar via the GK formalism:
# equilibration and thermalization
velocity all create $T 102486 mom yes rot yes dist gaussian
fix NVT all nvt temp $T $T 10 drag 0.2
velocity all create ${Tinit} 102486 mom yes rot yes dist gaussian
fix NVT all nvt temp ${Tinit} ${Tinit} 10 drag 0.2
run 8000
# viscosity calculation, switch to NVE if desired
velocity all create $T 102486 mom yes rot yes dist gaussian
fix NVT all nvt temp $T $T 10 drag 0.2
#unfix NVT
#fix NVE all nve
@ -122,7 +125,7 @@ liquid Ar via the GK formalism:
run 100000
variable v equal (v_v11+v_v22+v_v33)/3.0
variable ndens equal count(all)/vol
print "average viscosity: $v [Pa.s] @ $T K, ${ndens} /A^3"
print "average viscosity: $v [Pa.s] @ $T K, ${ndens} atoms/A^3"
The fifth method is related to the above Green-Kubo method,
but uses the Einstein formulation, analogous to the Einstein
@ -131,9 +134,9 @@ time-integrated momentum fluxes play the role of Cartesian
coordinates, whose mean-square displacement increases linearly
with time at sufficiently long times.
The sixth is periodic perturbation method. It is also a non-equilibrium MD method.
However, instead of measure the momentum flux in response of applied velocity gradient,
it measures the velocity profile in response of applied stress.
The sixth is the periodic perturbation method, which is also a non-equilibrium MD method.
However, instead of measuring the momentum flux in response to an applied velocity gradient,
it measures the velocity profile in response to applied stress.
A cosine-shaped periodic acceleration is added to the system via the
:doc:`fix accelerate/cos <fix_accelerate_cos>` command,
and the :doc:`compute viscosity/cos<compute_viscosity_cos>` command is used to monitor the

18
doc/src/Install.rst
View File

@ -3,10 +3,20 @@ Install LAMMPS
You can download LAMMPS as an executable or as source code.
With source code, you also have to :doc:`build LAMMPS <Build>`. But you
have more flexibility as to what features to include or exclude in the
build. If you plan to :doc:`modify or extend LAMMPS <Modify>`, then you
need the source code.
When downloading the LAMMPS source code, you also have to :doc:`build
LAMMPS <Build>`. But you have more flexibility as to what features to
include or exclude in the build. When you download and install
pre-compiled LAMMPS executables, you are limited to install which
version of LAMMPS is available and which features are included of these
builds. If you plan to :doc:`modify or extend LAMMPS <Modify>`, then
you **must** build LAMMPS from the source code.
.. note::
If you have questions about the pre-compiled LAMMPS executables, you
need to contact the people preparing those executables. The LAMMPS
developers have no control over their choices of how they configure
and build their packages and when they update them.
.. toctree::
:maxdepth: 1

7
doc/src/Install_conda.rst
View File

@ -38,3 +38,10 @@ up the Conda capability.
.. _openkim: https://openkim.org
.. _conda: https://docs.conda.io/en/latest/index.html
.. _mini_conda_install: https://docs.conda.io/en/latest/miniconda.html
.. note::
If you have questions about these pre-compiled LAMMPS executables,
you need to contact the people preparing those packages. The LAMMPS
developers have no control over their choices of how they configure
and build their packages and when they update them.

130
doc/src/Install_linux.rst
View File

@ -3,13 +3,19 @@ Download an executable for Linux
Binaries are available for different versions of Linux:
| :ref:`Pre-built Ubuntu Linux executables <ubuntu>`
| :ref:`Pre-built Fedora Linux executables <fedora>`
| :ref:`Pre-built EPEL Linux executables (RHEL, CentOS) <epel>`
| :ref:`Pre-built OpenSuse Linux executables <opensuse>`
| :ref:`Gentoo Linux executable <gentoo>`
| :ref:`Arch Linux build-script <arch>`
|
- :ref:`Pre-built Ubuntu Linux executables <ubuntu>`
- :ref:`Pre-built Fedora Linux executables <fedora>`
- :ref:`Pre-built EPEL Linux executables (RHEL, CentOS) <epel>`
- :ref:`Pre-built OpenSuse Linux executables <opensuse>`
- :ref:`Gentoo Linux executable <gentoo>`
- :ref:`Arch Linux build-script <arch>`
.. note::
If you have questions about these pre-compiled LAMMPS executables,
you need to contact the people preparing those packages. The LAMMPS
developers have no control over their choices of how they configure
and build their packages and when they update them.
----------
@ -18,41 +24,28 @@ Binaries are available for different versions of Linux:
Pre-built Ubuntu Linux executables
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A pre-built LAMMPS executable suitable for running on the latest
Ubuntu Linux versions, can be downloaded as a Debian package. This
allows you to install LAMMPS with a single command, and stay
up-to-date with the current stable version of LAMMPS by simply updating
your operating system. Please note, that the repository below offers
two LAMMPS packages, ``lammps-daily`` and ``lammps-stable``. The
LAMMPS developers recommend to use the ``lammps-stable`` package for
any production simulations. The ``lammps-daily`` package is built
from the LAMMPS development sources, and those versions may have known
issues and bugs when new features are added and the software has not
undergone full release testing.
To install the appropriate personal-package archives (PPAs), do the
following once:
.. code-block:: bash
$ sudo add-apt-repository ppa:gladky-anton/lammps
$ sudo add-apt-repository ppa:openkim/latest
$ sudo apt-get update
A pre-built LAMMPS executable suitable for running on the latest Ubuntu
Linux versions, can be downloaded as a Debian package. This allows you
to install LAMMPS with a single command, and stay (mostly) up-to-date
with the current stable version of LAMMPS by simply updating your
operating system.
To install LAMMPS do the following once:
.. code-block:: bash
$ sudo apt-get install lammps-stable
$ sudo apt-get install lammps
This downloads an executable named ``lmp_stable`` to your box, which
can then be used in the usual way to run input scripts:
This downloads an executable named ``lmp`` to your box and multiple
packages with supporting data, examples and libraries as well as any
missing dependencies. This executable can then be used in the usual way
to run input scripts:
.. code-block:: bash
$ lmp_stable -in in.lj
$ lmp -in in.lj
To update LAMMPS to the most current stable version, do the following:
To update LAMMPS to the latest packaged version, do the following:
.. code-block:: bash
@ -60,44 +53,24 @@ To update LAMMPS to the most current stable version, do the following:
which will also update other packages on your system.
To get a copy of the current documentation and examples:
.. code-block:: bash
$ sudo apt-get install lammps-stable-doc
which will download the doc files in
``/usr/share/doc/lammps-stable-doc/doc`` and example problems in
``/usr/share/doc/lammps-doc/examples``.
To get a copy of the current potentials files:
.. code-block:: bash
$ sudo apt-get install lammps-stable-data
which will download the potentials files to
``/usr/share/lammps-stable/potentials``. The ``lmp_stable`` binary is
hard-coded to look for potential files in this directory (it does not
use the ``LAMMPS_POTENTIALS`` environment variable, as described
in :doc:`pair_coeff <pair_coeff>` command).
The ``lmp_stable`` binary is built with the :ref:`KIM package <kim>` which
results in the above command also installing the ``kim-api`` binaries when LAMMPS
is installed. In order to use potentials from `openkim.org <openkim_>`_, you
can install the ``openkim-models`` package
The ``lmp`` binary is built with the :ref:`KIM package <kim>` included,
which results in the above command also installing the ``kim-api``
binaries when LAMMPS is installed. In order to use potentials from
`openkim.org <openkim_>`_, you can also install the ``openkim-models``
package
.. code-block:: bash
$ sudo apt-get install openkim-models
Or use the KIM-API commands to download and install individual models.
To un-install LAMMPS, do the following:
.. code-block:: bash
$ sudo apt-get remove lammps-stable
$ sudo apt-get remove lammps
Please use ``lmp_stable -help`` to see which compilation options, packages,
Please use ``lmp -help`` to see which compilation options, packages,
and styles are included in the binary.
Thanks to Anton Gladky (gladky.anton at gmail.com) for setting up this
@ -110,21 +83,21 @@ Ubuntu package capability.
Pre-built Fedora Linux executables
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Pre-built LAMMPS packages for stable releases are available
in the Fedora Linux distribution as of version 28. The packages
can be installed via the dnf package manager. There are 3 basic
varieties (lammps = no MPI, lammps-mpich = MPICH MPI library,
lammps-openmpi = OpenMPI MPI library) and for each support for
linking to the C library interface (lammps-devel, lammps-mpich-devel,
lammps-openmpi-devel), the header for compiling programs using
the C library interface (lammps-headers), and the LAMMPS python
module for Python 3. All packages can be installed at the same
time and the name of the LAMMPS executable is ``lmp`` and ``lmp_openmpi``
or ``lmp_mpich`` respectively. By default, ``lmp`` will refer to the
serial executable, unless one of the MPI environment modules is loaded
(``module load mpi/mpich-x86_64`` or ``module load mpi/openmpi-x86_64``).
Then the corresponding parallel LAMMPS executable can be used.
The same mechanism applies when loading the LAMMPS python module.
Pre-built LAMMPS packages for stable releases are available in the
Fedora Linux distribution as of Fedora version 28. The packages can be
installed via the dnf package manager. There are 3 basic varieties
(lammps = no MPI, lammps-mpich = MPICH MPI library, lammps-openmpi =
OpenMPI MPI library) and for each support for linking to the C library
interface (lammps-devel, lammps-mpich-devel, lammps-openmpi-devel), the
header for compiling programs using the C library interface
(lammps-headers), and the LAMMPS python module for Python 3. All
packages can be installed at the same time and the name of the LAMMPS
executable is ``lmp`` and ``lmp_openmpi`` or ``lmp_mpich`` respectively.
By default, ``lmp`` will refer to the serial executable, unless one of
the MPI environment modules is loaded (``module load mpi/mpich-x86_64``
or ``module load mpi/openmpi-x86_64``). Then the corresponding parallel
LAMMPS executable can be used. The same mechanism applies when loading
the LAMMPS python module.
To install LAMMPS with OpenMPI and run an input ``in.lj`` with 2 CPUs do:
@ -273,3 +246,10 @@ Alternatively, you may use an AUR helper to install these packages.
Note that the AUR provides build-scripts that download the source and
the build the package on your machine.
.. note::
It looks like the Arch Linux AUR repository build scripts for LAMMPS
have not been updated since the 29 October 2020 version. You may want
to consider installing a more current version of LAMMPS from source
directly.

2
doc/src/Install_mac.rst
View File

@ -5,7 +5,7 @@ LAMMPS can be downloaded, built, and configured for OS X on a Mac with
`Homebrew <homebrew_>`_. (Alternatively, see the install instructions for
:doc:`Download an executable via Conda <Install_conda>`.) The following LAMMPS
packages are unavailable at this time because of additional needs not yet met:
GPU, KOKKOS, LATTE, MSCG, MESSAGE, MPIIO POEMS VORONOI.
GPU, KOKKOS, LATTE, MSCG, MPIIO, POEMS, VORONOI.
After installing Homebrew, you can install LAMMPS on your system with
the following commands:

2
doc/src/Install_tarball.rst
View File

@ -6,7 +6,7 @@ of the `LAMMPS website <lws_>`_.
.. _download: https://www.lammps.org/download.html
.. _bug: https://www.lammps.org/bug.html
.. _older: https://www.lammps.org/tars
.. _older: https://download.lammps.org/tars/
.. _lws: https://www.lammps.org
You have two choices of tarballs, either the most recent stable

12
doc/src/Intro_citing.rst
View File

@ -30,12 +30,12 @@ initial versions of LAMMPS is:
`S. Plimpton, Fast Parallel Algorithms for Short-Range Molecular Dynamics, J Comp Phys, 117, 1-19 (1995). <http://www.sandia.gov/~sjplimp/papers/jcompphys95.pdf>`_
DOI for the LAMMPS code
^^^^^^^^^^^^^^^^^^^^^^^
DOI for the LAMMPS source code
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
LAMMPS developers use the `Zenodo service at CERN <https://zenodo.org/>`_
to create digital object identifies (DOI) for stable releases of the
LAMMPS source code. There are two types of DOIs for the LAMMPS source code.
The LAMMPS developers use the `Zenodo service at CERN <https://zenodo.org/>`_
to create digital object identifiers (DOI) for stable releases of the
LAMMPS source code. There are two types of DOIs for the LAMMPS source code.
The canonical DOI for **all** versions of LAMMPS, which will always
point to the **latest** stable release version is:
@ -46,7 +46,7 @@ In addition there are DOIs for individual stable releases. Currently there are:
- 3 March 2020 version: `DOI:10.5281/zenodo.3726417 <https://dx.doi.org/10.5281/zenodo.3726417>`_
- 29 October 2020 version: `DOI:10.5281/zenodo.4157471 <https://dx.doi.org/10.5281/zenodo.4157471>`_
- 29 September 2021 version: `DOI:10.5281/zenodo.6386596 <https//dx.doi.org/10.5281/zenodo.6386596>`_
Home page
^^^^^^^^^

1
doc/src/Intro_website.rst
View File

@ -20,7 +20,6 @@ available online are listed below.
* `Glossary of terms relevant to LAMMPS <https://www.lammps.org/glossary.html>`_
* `LAMMPS highlights with images <https://www.lammps.org/pictures.html>`_
* `LAMMPS highlights with movies <https://www.lammps.org/movies.html>`_
* `Mailing list <https://www.lammps.org/mail.html>`_
* `LAMMPS forum <https://www.lammps.org/forum.html>`_
* `Workshops <https://www.lammps.org/workshops.html>`_
* `Tutorials <https://www.lammps.org/tutorials.html>`_

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 32 KiB

BIN
doc/src/JPG/third_order_force_constant.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 24 KiB

16
doc/src/Manual.rst
View File

@ -14,11 +14,11 @@ LAMMPS is an open-source code, distributed freely under the terms of
the GNU Public License Version 2 (GPLv2).
The `LAMMPS website <lws_>`_ has a variety of information about the
code. It includes links to an on-line version of this manual, a
`mailing list <https://www.lammps.org/mail.html>`_ and
`online forum <https://www.lammps.org/forum.html>`_ where users can
post questions, and a `GitHub site <https://github.com/lammps/lammps>`_
where all LAMMPS development is coordinated.
code. It includes links to an on-line version of this manual, an
`online forum <https://www.lammps.org/forum.html>`_ where users can post
questions and discuss LAMMPS, and a `GitHub site
<https://github.com/lammps/lammps>`_ where all LAMMPS development is
coordinated.
----------
@ -49,12 +49,12 @@ descriptions of all commands included in the LAMMPS code.
----------
.. _user_documentation:
************
User Guide
************
.. _user_documentation:
.. toctree::
:maxdepth: 2
:numbered: 3
@ -75,11 +75,12 @@ User Guide
Errors
.. _programmer_documentation:
******************
Programmer Guide
******************
.. _programmer_documentation:
.. toctree::
:maxdepth: 2
:numbered: 3
@ -110,6 +111,7 @@ Command Reference
angles
dihedrals
impropers
dumps
fix_modify_atc_commands
Bibliography

81
doc/src/Modify_atom.rst
View File

@ -9,34 +9,34 @@ A new atom style can be created if one of the existing atom styles
does not define all the attributes you need to store and communicate
with atoms.
Atom_vec_atomic.cpp is the simplest example of an atom style.
The file ``atom_vec_atomic.cpp`` is the simplest example of an atom style.
Examining the code for others will make these instructions more clear.
Note that the :doc:`atom style hybrid <atom_style>` command can be
used to define atoms or particles which have the union of properties
of individual styles. Also the :doc:`fix property/atom <fix_property_atom>`
command can be used to add a single property (e.g. charge
or a molecule ID) to a style that does not have it. It can also be
used to add custom properties to an atom, with options to communicate
them with ghost atoms or read them from a data file. Other LAMMPS
commands can access these custom properties, as can new pair, fix,
compute styles that are written to work with these properties. For
Note that the :doc:`atom style hybrid <atom_style>` command can be used
to define atoms or particles which have the union of properties of
individual styles. Also the :doc:`fix property/atom
<fix_property_atom>` command can be used to add a single property
(e.g. charge or a molecule ID) to a style that does not have it. It can
also be used to add custom properties to an atom, with options to
communicate them with ghost atoms or read them from a data file. Other
LAMMPS commands can access these custom properties, as can new pair,
fix, compute styles that are written to work with these properties. For
example, the :doc:`set <set>` command can be used to set the values of
custom per-atom properties from an input script. All of these methods
are less work than writing code for a new atom style.
are less work than writing and testing(!) code for a new atom style.
If you follow these directions your new style will automatically work
in tandem with others via the :doc:`atom_style hybrid <atom_style>`
command.
The first step is to define a set of strings in the constructor of the
new derived class. Each string will have zero or more space-separated
variable names which are identical to those used in the atom.h header
file for per-atom properties. Note that some represent per-atom
The first step is to define a set of string lists in the constructor of
the new derived class. Each list will have zero or more comma-separated
strings that correspond to the variable names used in the ``atom.h``
header file for per-atom properties. Note that some represent per-atom
vectors (q, molecule) while other are per-atom arrays (x,v). For all
but the last 2 strings you do not need to specify any of
but the last two lists you do not need to specify any of
(id,type,x,v,f). Those are included automatically as needed in the
other strings.
other lists.
.. list-table::
@ -65,16 +65,16 @@ other strings.
* - fields_data_vel
- list of properties (in order) in the Velocities section of a data file, as read by :doc:`read_data <read_data>`
In these strings you can list variable names which LAMMPS already
defines (in some other atom style), or you can create new variable
names. You should not re-use a LAMMPS variable for something with
different meaning in your atom style. If the meaning is related, but
interpreted differently by your atom style, then using the same
variable name means a user should not use your style and the other
style together in a :doc:`atom_style hybrid <atom_style>` command.
Because there will only be one value of the variable and different
parts of LAMMPS will then likely use it differently. LAMMPS has
no way of checking for this.
In these lists you can list variable names which LAMMPS already defines
(in some other atom style), or you can create new variable names. You
should not re-use a LAMMPS variable in your atom style that is used for
something with a different meaning in another atom style. If the
meaning is related, but interpreted differently by your atom style, then
using the same variable name means a user must not use your style and
the other style together in a :doc:`atom_style hybrid <atom_style>`
command. Because there will only be one value of the variable and
different parts of LAMMPS will then likely use it differently. LAMMPS
has no way of checking for this.
If you are defining new variable names then make them descriptive and
unique to your new atom style. For example choosing "e" for energy is
@ -85,32 +85,31 @@ If any of the variable names in your new atom style do not exist in
LAMMPS, you need to add them to the src/atom.h and atom.cpp files.
Search for the word "customize" or "customization" in these 2 files to
see where to add your variable. Adding a flag to the 2nd
customization section in atom.h is only necessary if your code (e.g. a
pair style) needs to check that a per-atom property is defined. These
flags should also be set in the constructor of the atom style child
class.
see where to add your variable. Adding a flag to the 2nd customization
section in ``atom.h`` is only necessary if your code (e.g. a pair style)
needs to check that a per-atom property is defined. These flags should
also be set in the constructor of the atom style child class.
In atom.cpp, aside from the constructor and destructor, there are 3
In ``atom.cpp``, aside from the constructor and destructor, there are 3
methods that a new variable name or flag needs to be added to.
In Atom::peratom_create() when using the add_peratom() method, a
final length argument of 0 is for per-atom vectors, a length > 1 is
for per-atom arrays. Note the use of an extra per-thread flag and the
add_peratom_vary() method when last dimension of the array is
In ``Atom::peratom_create()`` when using the ``Atom::add_peratom()``
method, a cols argument of 0 is for per-atom vectors, a length >
1 is for per-atom arrays. Note the use of the extra per-thread flag and
the add_peratom_vary() method when last dimension of the array is
variable-length.
Adding the variable name to Atom::extract() enable the per-atom data
Adding the variable name to Atom::extract() enables the per-atom data
to be accessed through the :doc:`LAMMPS library interface
<Howto_library>` by a calling code, including from :doc:`Python
<Python_head>`.
The constructor of the new atom style will also typically set a few
flags which are defined at the top of atom_vec.h. If these are
flags which are defined at the top of ``atom_vec.h``. If these are
unclear, see how other atom styles use them.
The grow_pointers() method is also required to make
a copy of peratom data pointers, as explained in the code.
The grow_pointers() method is also required to make a copy of peratom
data pointers, as explained in the code.
There are a number of other optional methods which your atom style can
implement. These are only needed if you need to do something

9
doc/src/Modify_contribute.rst
View File

@ -27,11 +27,10 @@ join the `LAMMPS developers on Slack <https://lammps.slack.com>`_. This
slack work space is by invitation only. Thus for access, please send an
e-mail to ``slack@lammps.org`` explaining what part of LAMMPS you are
working on. Only discussions related to LAMMPS development are
tolerated in that work space, so this is **NOT** for people that look for
help with compiling, installing, or using LAMMPS. Please post a message
to the `lammps-users mailing list <https://www.lammps.org/mail.html>`_
or the `LAMMPS forum <https://www.lammps.org/forum.html>`_ for those
purposes.
tolerated in that work space, so this is **NOT** for people that look
for help with compiling, installing, or using LAMMPS. Please post a
message to the `LAMMPS forum <https://www.lammps.org/forum.html>`_ for
those purposes.
Packages versus individual files
--------------------------------

2
doc/src/Modify_fix.rst
View File

@ -23,6 +23,8 @@ derived class. See fix.h for details.
+---------------------------+--------------------------------------------------------------------------------------------+
| init | initialization before a run (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| init_list | store pointer to neighbor list; called by neighbor list code (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| setup_pre_exchange | called before atom exchange in setup (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| setup_pre_force | called before force computation in setup (optional) |

69
doc/src/Modify_style.rst
View File

@ -100,13 +100,14 @@ Documentation (strict)
Contributions that add new styles or commands or augment existing ones
must include the corresponding new or modified documentation in
`ReStructuredText format <rst>`_ (.rst files in the ``doc/src/`` folder). The
documentation shall be written in American English and the .rst file
must use only ASCII characters so it can be cleanly translated to PDF
files (via `sphinx <sphinx>`_ and PDFLaTeX). Special characters may be included via
embedded math expression typeset in a LaTeX subset.
`ReStructuredText format <rst_>`_ (.rst files in the ``doc/src/``
folder). The documentation shall be written in American English and the
.rst file must use only ASCII characters so it can be cleanly translated
to PDF files (via `sphinx <https://www.sphinx-doc.org>`_ and PDFLaTeX).
Special characters may be included via embedded math expression typeset
in a LaTeX subset.
.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
.. _rst: https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html
When adding new commands, they need to be integrated into the sphinx
documentation system, and the corresponding command tables and lists
@ -133,7 +134,7 @@ error free completion of the HTML and PDF build will be performed and
also a spell check, a check for correct anchors and labels, and a check
for completeness of references all styles in their corresponding tables
and lists is run. In case the spell check reports false positives they
can be added to the file doc/utils/sphinx-config/false_positives.txt
can be added to the file ``doc/utils/sphinx-config/false_positives.txt``
Contributions that add or modify the library interface or "public" APIs
from the C++ code or the Fortran module must include suitable doxygen
@ -223,6 +224,13 @@ and readable by all and no executable permissions. Executable
permissions (0755) should only be on shell scripts or python or similar
scripts for interpreted script languages.
You can check for these issues with the python scripts in the
:ref:`"tools/coding_standard" <coding_standard>` folder. When run
normally with a source file or a source folder as argument, they will
list all non-conforming lines. By adding the `-f` flag to the command
line, they will modify the flagged files to try removing the detected
issues.
Indentation and Placement of Braces (strongly preferred)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -240,6 +248,53 @@ reformatting from clang-format yields undesirable output may be
protected with placing a pair `// clang-format off` and `// clang-format
on` comments around that block.
Error or warning messages and explanations (preferred)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: 4May2022
Starting with LAMMPS version 4 May 2022 the LAMMPS developers have
agreed on a new policy for error and warning messages.
Previously, all error and warning strings were supposed to be listed in
the class header files with an explanation. Those would then be
regularly "harvested" and transferred to alphabetically sorted lists in
the manual. To avoid excessively long lists and to reduce effort, this
came with a requirement to have rather generic error messages (e.g.
"Illegal ... command"). To identify the specific cause, the name of the
source file and the line number of the error location would be printed,
so that one could look up the cause by reading the source code.
The new policy encourages more specific error messages that ideally
indicate the cause directly and no further lookup would be needed.
This is aided by using the `{fmt} library <https://fmt.dev>`_ to convert
the Error class commands so that they take a variable number of arguments
and error text will be treated like a {fmt} syntax format string.
Error messages should still kept to a single line or two lines at the most.
For more complex explanations or errors that have multiple possible
reasons, a paragraph should be added to the `Error_details` page with an
error code reference (e.g. ``.. _err0001:``) then the utility function
:cpp:func:`utils::errorurl() <LAMMPS_NS::utils::errorurl>` can be used
to generate an URL that will directly lead to that paragraph. An error
for missing arguments can be easily generated using the
:cpp:func:`utils::missing_cmd_args()
<LAMMPS_NS::utils::missing_cmd_args>` convenience function.
The transformation of existing LAMMPS code to this new scheme is ongoing
and - given the size of the LAMMPS source code - will take a significant
amount of time until completion. However, for new code following the
new approach is strongly preferred. The expectation is that the new
scheme will make it easier for LAMMPS users, developers, and
maintainers.
An example for this approach would be the
``src/read_data.cpp`` and ``src/atom.cpp`` files that implement the
:doc:`read_data <read_data>` and :doc:`atom_modify <atom_modify>`
commands and that may create :ref:`"Unknown identifier in data file" <err0001>`
errors that seem difficult to debug for users because they may have
one of multiple possible reasons, and thus require some additional explanations.
Programming language standards (required)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

BIN
doc/src/PDF/colvars-refman-lammps.pdf
View File

Binary file not shown.

198
doc/src/Packages_details.rst
View File

@ -27,14 +27,16 @@ page gives those details.
:columns: 6
* :ref:`ADIOS <PKG-ADIOS>`
* :ref:`AMOEBA <PKG-AMOEBA>`
* :ref:`ASPHERE <PKG-ASPHERE>`
* :ref:`ATC <PKG-ATC>`
* :ref:`AWPMD <PKG-AWPMD>`
* :ref:`BOCS <PKG-BOCS>`
* :ref:`BODY <PKG-BODY>`
* :ref:`BPM <PKG-BPM>`
* :ref:`BROWNIAN <PKG-BROWNIAN>`
* :ref:`CG-DNA <PKG-CG-DNA>`
* :ref:`CG-SDK <PKG-CG-SDK>`
* :ref:`CG-SPICA <PKG-CG-SPICA>`
* :ref:`CLASS2 <PKG-CLASS2>`
* :ref:`COLLOID <PKG-COLLOID>`
* :ref:`COLVARS <PKG-COLVARS>`
@ -49,6 +51,7 @@ page gives those details.
* :ref:`DPD-SMOOTH <PKG-DPD-SMOOTH>`
* :ref:`DRUDE <PKG-DRUDE>`
* :ref:`EFF <PKG-EFF>`
* :ref:`ELECTRODE <PKG-ELECTRODE>`
* :ref:`EXTRA-COMPUTE <PKG-EXTRA-COMPUTE>`
* :ref:`EXTRA-DUMP <PKG-EXTRA-DUMP>`
* :ref:`EXTRA-FIX <PKG-EXTRA-FIX>`
@ -72,7 +75,6 @@ page gives those details.
* :ref:`MDI <PKG-MDI>`
* :ref:`MEAM <PKG-MEAM>`
* :ref:`MESONT <PKG-MESONT>`
* :ref:`MESSAGE <PKG-MESSAGE>`
* :ref:`MGPT <PKG-MGPT>`
* :ref:`MISC <PKG-MISC>`
* :ref:`ML-HDNNP <PKG-ML-HDNNP>`
@ -148,6 +150,38 @@ This package has :ref:`specific installation instructions <adios>` on the :doc:`
----------
.. _PKG-AMOEBA:
AMOEBA package
---------------
**Contents:**
Implementation of the AMOEBA and HIPPO polarized force fields
originally developed by Jay Ponder's group at the U Washington at St
Louis. The LAMMPS implementation is based on Fortran 90 code
provided by the Ponder group in their
`Tinker MD software <https://dasher.wustl.edu/tinker/>`_.
**Authors:** Josh Rackers and Steve Plimpton (Sandia), Trung Nguyen (U
Chicago)
**Supporting info:**
* src/AMOEBA: filenames -> commands
* :doc:`AMOEBA and HIPPO howto <Howto_amoeba>`
* :doc:`pair_style amoeba <pair_amoeba>`
* :doc:`pair_style hippo <pair_amoeba>`
* :doc:`atom_style amoeba <atom_style>`
* :doc:`angle_style amoeba <angle_amoeba>`
* :doc:`improper_style amoeba <improper_amoeba>`
* :doc:`fix amoeba/bitorsion <fix_amoeba_bitorsion>`
* :doc:`fix amoeba/pitorsion <fix_amoeba_pitorsion>`
* tools/tinker/tinker2lmp.py
* examples/amoeba
----------
.. _PKG-ASPHERE:
ASPHERE package
@ -180,9 +214,10 @@ ATC package
**Contents:**
ATC stands for atoms-to-continuum. This package implements a :doc:`fix atc <fix_atc>` command to either couple molecular dynamics with
continuum finite element equations or perform on-the-fly conversion of
atomic information to continuum fields.
ATC stands for atoms-to-continuum. This package implements a
:doc:`fix atc <fix_atc>` command to either couple molecular dynamics
with continuum finite element equations or perform on-the-fly
conversion of atomic information to continuum fields.
**Authors:** Reese Jones, Jeremy Templeton, Jon Zimmerman (Sandia).
@ -284,6 +319,35 @@ overview.
----------
.. _PKG-BPM:
BPM package
------------
**Contents:**
Pair styles, bond styles, fixes, and computes for bonded particle
models for mesoscale simulations of solids and fracture. See the
:doc:`Howto bpm <Howto_bpm>` page for an overview.
**Authors:** Joel T. Clemmer (Sandia National Labs)
.. versionadded:: 4May2022
**Supporting info:**
* src/BPM filenames -> commands
* :doc:`Howto_bpm <Howto_bpm>`
* :doc:`atom_style bpm/sphere <atom_style>`
* :doc:`bond_style bpm/rotational <bond_bpm_rotational>`
* :doc:`bond_style bpm/spring <bond_bpm_spring>`
* :doc:`compute nbond/atom <compute_nbond_atom>`
* :doc:`fix nve/bpm/sphere <fix_nve_bpm_sphere>`
* :doc:`pair_style bpm/spring <pair_bpm_spring>`
* examples/bpm
----------
.. _PKG-BROWNIAN:
BROWNIAN package
@ -337,28 +401,30 @@ The CG-DNA package requires that also the `MOLECULE <PKG-MOLECULE>`_ and
----------
.. _PKG-CG-SDK:
.. _PKG-CG-SPICA:
CG-SDK package
CG-SPICA package
------------------
**Contents:**
Several pair styles and an angle style which implement the
coarse-grained SDK model of Shinoda, DeVane, and Klein which enables
simulation of ionic liquids, electrolytes, lipids and charged amino
acids.
coarse-grained SPICA (formerly called SDK) model which enables
simulation of biological or soft material systems.
**Author:** Axel Kohlmeyer (Temple U).
**Original Author:** Axel Kohlmeyer (Temple U).
**Maintainers:** Yusuke Miyazaki and Wataru Shinoda (Okayama U).
**Supporting info:**
* src/CG-SDK: filenames -> commands
* src/CG-SDK/README
* :doc:`pair_style lj/sdk/\* <pair_sdk>`
* :doc:`angle_style sdk <angle_sdk>`
* examples/PACKAGES/cgsdk
* src/CG-SPICA: filenames -> commands
* src/CG-SPICA/README
* :doc:`pair_style lj/spica/\* <pair_spica>`
* :doc:`angle_style spica <angle_spica>`
* examples/PACKAGES/cgspica
* https://www.lammps.org/pictures.html#cg
* https://www.spica-ff.org/
----------
@ -529,8 +595,20 @@ To use this package, also the :ref:`KSPACE <PKG-KSPACE>` and
**Supporting info:**
* src/DIELECTRIC: filenames -> commands
* :doc:`atom_style dielectric <atom_style>`
* :doc:`pair_style coul/cut/dielectric <pair_dielectric>`
* :doc:`pair_style coul/long/dielectric <pair_dielectric>`
* :doc:`pair_style lj/cut/coul/cut/dielectric <pair_dielectric>`
* :doc:`pair_style lj/cut/coul/debye/dielectric <pair_dielectric>`
* :doc:`pair_style lj/cut/coul/long/dielectric <pair_dielectric>`
* :doc:`pair_style lj/cut/coul/msm/dielectric <pair_dielectric>`
* :doc:`pair_style pppm/dielectric <kspace_style>`
* :doc:`pair_style pppm/disp/dielectric <kspace_style>`
* :doc:`pair_style msm/dielectric <kspace_style>`
* :doc:`fix_style polarize/bem/icc <fix_polarize>`
* :doc:`fix_style polarize/bem/gmres <fix_polarize>`
* :doc:`fix_style polarize/functional <fix_polarize>`
* :doc:`compute efield/atom <compute_efield_atom>`
* TODO: add all styles
* examples/PACKAGES/dielectric
----------
@ -617,7 +695,7 @@ advection-diffusion-reaction systems. The equations of motion of these
DPD extensions are integrated through a modified velocity-Verlet (MVV)
algorithm.
**Author:** Zhen Li (Division of Applied Mathematics, Brown University)
**Author:** Zhen Li (Department of Mechanical Engineering, Clemson University)
**Supporting info:**
@ -770,6 +848,33 @@ tools/eff; see its README file.
-------------------
.. _PKG-ELECTRODE:
ELECTRODE package
-----------------
**Contents:**
The ELECTRODE package allows the user to enforce a constant potential method for
groups of atoms that interact with the remaining atoms as electrolyte.
**Authors:** The ELECTRODE library is written and maintained by Ludwig
Ahrens-Iwers (TUHH, Hamburg, Germany), Shern Tee (UQ, Brisbane, Australia) and
Robert Meissner (TUHH, Hamburg, Germany).
.. versionadded:: 4May2022
**Install:**
This package has :ref:`specific installation instructions <electrode>` on the
:doc:`Build extras <Build_extras>` page.
**Supporting info:**
* :doc:`fix electrode/conp <fix_electrode_conp>`
----------
.. _PKG-EXTRA-COMPUTE:
EXTRA-COMPUTE package
@ -1396,17 +1501,25 @@ MDI package
**Contents:**
A LAMMPS command and fix to allow client-server coupling of LAMMPS to
other atomic or molecular simulation codes via the `MolSSI Driver Interface
A LAMMPS command and fixes to allow client-server coupling of LAMMPS
to other atomic or molecular simulation codes or materials modeling
workflows via the `MolSSI Driver Interface
(MDI) library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_.
**Author:** Taylor Barnes - MolSSI, taylor.a.barnes at gmail.com
**Install:**
This package has :ref:`specific installation instructions <mdi>` on
the :doc:`Build extras <Build_extras>` page.
**Supporting info:**
* src/MDI/README
* :doc:`mdi/engine <mdi_engine>`
* :doc:`fix mdi/engine <fix_mdi_engine>`
* lib/mdi/README
* :doc:`Howto MDI <Howto_mdi>`
* :doc:`mdi <mdi>`
* :doc:`fix mdi/qm <fix_mdi_qm>`
* examples/PACKAGES/mdi
----------
@ -1483,32 +1596,6 @@ Philipp Kloza (U Cambridge)
----------
.. _PKG-MESSAGE:
MESSAGE package
---------------
**Contents:**
Commands to use LAMMPS as either a client or server and couple it to
another application.
**Install:**
This package has :ref:`specific installation instructions <message>` on the :doc:`Build extras <Build_extras>` page.
**Supporting info:**
* src/MESSAGE: filenames -> commands
* lib/message/README
* :doc:`message <message>`
* :doc:`fix client/md <fix_client_md>`
* :doc:`server md <server_md>`
* :doc:`server mc <server_mc>`
* examples/message
----------
.. _PKG-MGPT:
MGPT package
@ -1564,7 +1651,6 @@ listing, "ls src/MISC", to see the list of commands.
* :doc:`pair_style list <pair_list>`
* :doc:`pair_style srp <pair_srp>`
* :doc:`pair_style tracker <pair_tracker>`
* :doc:`fix pair/tracker <fix_pair_tracker>`
----------
@ -1755,6 +1841,8 @@ computes which analyze attributes of the potential.
* src/ML-SNAP: filenames -> commands
* :doc:`pair_style snap <pair_snap>`
* :doc:`compute sna/atom <compute_sna_atom>`
* :doc:`compute sna/grid <compute_sna_atom>`
* :doc:`compute sna/grid/local <compute_sna_atom>`
* :doc:`compute snad/atom <compute_sna_atom>`
* :doc:`compute snav/atom <compute_sna_atom>`
* examples/snap
@ -2558,18 +2646,20 @@ SMTBQ package
**Contents:**
A pair style which implements a Second Moment Tight Binding model with
QEq charge equilibration (SMTBQ) potential for the description of
ionocovalent bonds in oxides.
Pair styles which implement Second Moment Tight Binding models.
One with QEq charge equilibration (SMTBQ) for the description of
ionocovalent bonds in oxides, and two more as plain SMATB models.
**Authors:** Nicolas Salles, Emile Maras, Olivier Politano, and Robert
Tetot (LAAS-CNRS, France).
**Authors:** SMTBQ: Nicolas Salles, Emile Maras, Olivier Politano, and Robert
Tetot (LAAS-CNRS, France);
SMATB: Daniele Rapetti (Politecnico di Torino)
**Supporting info:**
* src/SMTBQ: filenames -> commands
* src/SMTBQ/README
* :doc:`pair_style smtbq <pair_smtbq>`
* :doc:`pair_style smatb <pair_smatb>`, :doc:`pair_style smatb/single <pair_smatb>`
* examples/PACKAGES/smtbq
----------

34
doc/src/Packages_list.rst
View File

@ -33,6 +33,11 @@ whether an extra library is needed to build and use the package:
- :doc:`dump adios <dump_adios>`
- PACKAGES/adios
- ext
* - :ref:`AMOEBA <PKG-AMOEBA>`
- AMOEBA and HIPPO force fields
- :doc:`AMOEBA and HIPPO howto <Howto_amoeba>`
- amoeba
- no
* - :ref:`ASPHERE <PKG-ASPHERE>`
- aspherical particle models
- :doc:`Howto spherical <Howto_spherical>`
@ -58,6 +63,11 @@ whether an extra library is needed to build and use the package:
- :doc:`Howto body <Howto_body>`
- body
- no
* - :ref:`BPM <PKG-BPM>`
- bonded particle models
- :doc:`Howto bpm <Howto_bpm>`
- bpm
- no
* - :ref:`BROWNIAN <PKG-BROWNIAN>`
- Brownian dynamics, self-propelled particles
- :doc:`fix brownian <fix_brownian>`, :doc:`fix propel/self <fix_propel_self>`
@ -68,10 +78,10 @@ whether an extra library is needed to build and use the package:
- src/CG-DNA/README
- PACKAGES/cgdna
- no
* - :ref:`CG-SDK <PKG-CG-SDK>`
- SDK coarse-graining model
- :doc:`pair_style lj/sdk <pair_sdk>`
- PACKAGES/cgsdk
* - :ref:`CG-SPICA <PKG-CG-SPICA>`
- SPICA (SDK) coarse-graining model
- :doc:`pair_style lj/spica <pair_spica>`
- PACKAGES/cgspica
- no
* - :ref:`CLASS2 <PKG-CLASS2>`
- class 2 force fields
@ -143,6 +153,11 @@ whether an extra library is needed to build and use the package:
- :doc:`pair_style eff/cut <pair_eff>`
- PACKAGES/eff
- no
* - :ref:`ELECTRODE <PKG-ELECTRODE>`
- electrode charges to match potential
- :doc:`fix electrode/conp <fix_electrode_conp>`
- PACKAGES/electrode
- no
* - :ref:`EXTRA-COMPUTE <PKG-EXTRA-COMPUTE>`
- additional compute styles
- :doc:`compute <compute>`
@ -244,7 +259,7 @@ whether an extra library is needed to build and use the package:
- n/a
- no
* - :ref:`MDI <PKG-MDI>`
- client-server coupling
- client-server code coupling
- :doc:`MDI Howto <Howto_mdi>`
- PACKAGES/mdi
- ext
@ -258,11 +273,6 @@ whether an extra library is needed to build and use the package:
- pair styles :doc:`mesont/tpm <pair_mesont_tpm>`, :doc:`mesocnt <pair_mesocnt>`
- PACKAGES/mesont
- int
* - :ref:`MESSAGE <PKG-MESSAGE>`
- client/server messaging
- :doc:`message <message>`
- message
- int
* - :ref:`MGPT <PKG-MGPT>`
- fast MGPT multi-ion potentials
- :doc:`pair_style mgpt <pair_mgpt>`
@ -429,8 +439,8 @@ whether an extra library is needed to build and use the package:
- n/a
- no
* - :ref:`SMTBQ <PKG-SMTBQ>`
- second moment tight binding potential
- :doc:`pair_style smtbq <pair_smtbq>`
- second moment tight binding potentials
- :doc:`pair_style smtbq <pair_smtbq>` :doc:`pair_style smatb <pair_smatb>`
- PACKAGES/smtbq
- no
* - :ref:`SPH <PKG-SPH>`

9
doc/src/Run_options.rst
View File

@ -226,15 +226,6 @@ other executable(s) perform an MPI_Comm_split() with their own colors
to shrink the MPI_COMM_WORLD communication to be the subset of
processors they are actually running on.
Currently, this is only used in LAMMPS to perform client/server
messaging with another application. LAMMPS can act as either a client
or server (or both). More details are given on the :doc:`Howto client/server <Howto_client_server>` doc page.
Specifically, this refers to the "mpi/one" mode of messaging provided
by the :doc:`message <message>` command and the CSlib library LAMMPS
links with from the lib/message directory. See the
:doc:`message <message>` command for more details.
----------
.. _cite:

3
doc/src/Speed_measure.rst
View File

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

75
doc/src/Tools.rst
View File

@ -56,6 +56,7 @@ Pre-processing tools
* :ref:`moltemplate <moltemplate>`
* :ref:`msi2lmp <msi>`
* :ref:`polybond <polybond>`
* :ref:`stl_bin2txt <stlconvert>`
Post-processing tools
@ -87,14 +88,14 @@ Miscellaneous tools
.. table_from_list::
:columns: 6
* :ref:`CMake <cmake>`
* :ref:`LAMMPS coding standards <coding_standard>`
* :ref:`emacs <emacs>`
* :ref:`i-pi <ipi>`
* :ref:`kate <kate>`
* :ref:`LAMMPS shell <lammps_shell>`
* :ref:`LAMMPS magic patterns for file(1) <magic>`
* :ref:`Offline build tool <offline>`
* :ref:`singularity <singularity_tool>`
* :ref:`singularity/apptainer <singularity_tool>`
* :ref:`SWIG interface <swig>`
* :ref:`vim <vim>`
@ -189,27 +190,32 @@ for the :doc:`chain benchmark <Speed_bench>`.
----------
.. _cmake:
.. _coding_standard:
CMake tools
-----------
LAMMPS coding standard
----------------------
The ``cmbuild`` script is a wrapper around using ``cmake --build <dir>
--target`` and allows compiling LAMMPS in a :ref:`CMake build folder
<cmake_build>` with a make-like syntax regardless of the actual build
tool and the specific name of the program used (e.g. ``ninja-v1.10`` or
``gmake``) when using ``-D CMAKE_MAKE_PROGRAM=<name>``.
The ``coding_standard`` folder contains multiple python scripts to
check for and apply some LAMMPS coding conventions. The following
scripts are available:
.. parsed-literal::
Usage: cmbuild [-v] [-h] [-C <dir>] [-j <num>] [<target>]
permissions.py # detects if sources have executable permissions and scripts have not
whitespace.py # detects TAB characters and trailing whitespace
homepage.py # detects outdated LAMMPS homepage URLs (pointing to sandia.gov instead of lammps.org)
errordocs.py # detects deprecated error docs in header files
Options:
-h print this message
-j <NUM> allow processing of NUM concurrent tasks
-C DIRECTORY execute build in folder DIRECTORY
-v produce verbose output
The tools need to be given the main folder of the LAMMPS distribution
or individual file names as argument and will by default check them
and report any non-compliance. With the optional ``-f`` argument the
corresponding script will try to change the non-compliant file(s) to
match the conventions.
For convenience this scripts can also be invoked by the make file in
the ``src`` folder with, `make check-whitespace` or `make fix-whitespace`
to either detect or edit the files. Correspondingly for the other python
scripts. `make check` will run all checks.
----------
@ -1001,14 +1007,37 @@ Ivanov, at University of Iceland (ali5 at hi.is).
.. _singularity_tool:
singularity tool
----------------------------------------
singularity/apptainer tool
--------------------------
The singularity sub-directory contains container definitions files
that can be used to build container images for building and testing
LAMMPS on specific OS variants using the `Singularity <https://sylabs.io>`_
container software. Contributions for additional variants are welcome.
For more details please see the README.md file in that folder.
The singularity sub-directory contains container definitions files that
can be used to build container images for building and testing LAMMPS on
specific OS variants using the `Apptainer <https://apptainer.org>`_ or
`Singularity <https://sylabs.io>`_ container software. Contributions for
additional variants are welcome. For more details please see the
README.md file in that folder.
----------
.. _stlconvert:
stl_bin2txt tool
----------------
The file stl_bin2txt.cpp converts binary STL files - like they are
frequently offered for download on the web - into ASCII format STL files
that LAMMPS can read with the :doc:`create_atoms mesh <create_atoms>` or
the :doc:`fix smd/wall_surface <fix_smd_wall_surface>` commands. The syntax
for running the tool is
.. code-block:: bash
stl_bin2txt infile.stl outfile.stl
which creates outfile.stl from infile.stl. This tool must be compiled
on a platform compatible with the byte-ordering that was used to create
the binary file. This usually is a so-called little endian hardware
(like x86).
----------

138
doc/src/angle_amoeba.rst Normal file
View File

@ -0,0 +1,138 @@
.. index:: angle_style amoeba
angle_style amoeba command
==========================
Syntax
""""""
.. code-block:: LAMMPS
angle_style amoeba
Examples
""""""""
.. code-block:: LAMMPS
angle_style amoeba
angle_coeff * 75.0 -25.0 1.0 0.3 0.02 0.003
angle_coeff * ba 3.6551 24.895 1.0119 1.5228
angle_coeff * ub -7.6 1.5537
Description
"""""""""""
The *amoeba* angle style uses the potential
.. math::
E & = E_a + E_{ba} + E_{ub} \\
E_a & = K_2\left(\theta - \theta_0\right)^2 + K_3\left(\theta - \theta_0\right)^3 + K_4\left(\theta - \theta_0\right)^4 + K_5\left(\theta - \theta_0\right)^5 + K_6\left(\theta - \theta_0\right)^6 \\
E_{ba} & = N_1 (r_{ij} - r_1) (\theta - \theta_0) + N_2(r_{jk} - r_2)(\theta - \theta_0) \\
E_{UB} & = K_{ub} (r_{ik} - r_{ub})^2
where :math:`E_a` is the angle term, :math:`E_{ba}` is a bond-angle
term, :math:`E_{UB}` is a Urey-Bradley bond term, :math:`\theta_0` is
the equilibrium angle, :math:`r_1` and :math:`r_2` are the equilibrium
bond lengths, and :math:`r_{ub}` is the equilibrium Urey-Bradley bond
length.
These formulas match how the Tinker MD code performs its angle
calculations for the AMOEBA and HIPPO force fields. See the
:doc:`Howto amoeba <Howto_amoeba>` page for more information about
the implementation of AMOEBA and HIPPO in LAMMPS.
Note that the :math:`E_a` and :math:`E_{ba}` formulas are identical to
those used for the :doc:`angle_style class2/p6 <angle_class2>`
command, however there is no bond-bond cross term formula for
:math:`E_{bb}`. Additionally, there is a :math:`E_{UB}` term for a
Urey-Bradley bond. It is effectively a harmonic bond between the I
and K atoms of angle IJK, even though that bond is not enumerated in
the "Bonds" section of the data file.
There are also two ways that Tinker computes the angle :math:`\theta`
in the :math:`E_a` formula. The first is the standard way of treating
IJK as an "in-plane" angle. The second is an "out-of-plane" method
which Tinker may use if the center atom J in the angle is bonded to
one additional atom in addition to I and K. In this case, all 4 atoms
are used to compute the :math:`E_a` formula, resulting in forces on
all 4 atoms. In the Tinker PRM file, these 2 options are denoted by
*angle* versus *anglep* entries in the "Angle Bending Parameters"
section of the PRM force field file. The *pflag* coefficient
described below selects between the 2 options.
----------
Coefficients for the :math:`E_a`, :math:`E_{bb}`, and :math:`E_{ub}`
formulas 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.
These are the 8 coefficients for the :math:`E_a` formula:
* pflag = 0 or 1
* ubflag = 0 or 1
* :math:`\theta_0` (degrees)
* :math:`K_2` (energy)
* :math:`K_3` (energy)
* :math:`K_4` (energy)
* :math:`K_5` (energy)
* :math:`K_6` (energy)
A pflag value of 0 vs 1 selects between the "in-plane" and
"out-of-plane" options described above. Ubflag is 1 if there is a
Urey-Bradley term associated with this angle type, else it is 0.
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to
radians internally; hence the various :math:`K` values are effectively
energy per radian\^2 or radian\^3 or radian\^4 or radian\^5 or
radian\^6.
For the :math:`E_{ba}` formula, each line in a :doc:`angle_coeff
<angle_coeff>` command in the input script lists 5 coefficients, the
first of which is "ba" to indicate they are BondAngle coefficients.
In a data file, these coefficients should be listed under a "BondAngle
Coeffs" heading and you must leave out the "ba", i.e. only list 4
coefficients after the angle type.
* ba
* :math:`N_1` (energy/distance\^2)
* :math:`N_2` (energy/distance\^2)
* :math:`r_1` (distance)
* :math:`r_2` (distance)
The :math:`\theta_0` value in the :math:`E_{ba}` formula is not specified,
since it is the same value from the :math:`E_a` formula.
For the :math:`E_{ub}` formula, each line in a :doc:`angle_coeff
<angle_coeff>` command in the input script lists 3 coefficients, the
first of which is "ub" to indicate they are UreyBradley coefficients.
In a data file, these coefficients should be listed under a
"UreyBradley Coeffs" heading and you must leave out the "ub",
i.e. only list 2 coefficients after the angle type.
* ub
* :math:`K_{ub}` (energy/distance\^2)
* :math:`r_{ub}` (distance)
----------
Restrictions
""""""""""""
This angle style can only be used if LAMMPS was built with the AMOEBA
package. See the :doc:`Build package <Build_package>` doc page for
more info.
Related commands
""""""""""""""""
:doc:`angle_coeff <angle_coeff>`
Default
"""""""
none

2
doc/src/angle_class2.rst
View File

@ -24,7 +24,7 @@ Examples
.. code-block:: LAMMPS
angle_style class2
angle_coeff * 75.0
angle_coeff * 75.0 25.0 0.3 0.002
angle_coeff 1 bb 10.5872 1.0119 1.5228
angle_coeff * ba 3.6551 24.895 1.0119 1.5228

37
doc/src/angle_sdk.rst → doc/src/angle_spica.rst
View File

@ -1,32 +1,32 @@
.. index:: angle_style sdk
.. index:: angle_style sdk/omp
.. index:: angle_style spica
.. index:: angle_style spica/omp
angle_style sdk command
=======================
angle_style spica command
=========================
Accelerator Variants: *sdk/omp*
Accelerator Variants: *spica/omp*
Syntax
""""""
.. code-block:: LAMMPS
angle_style sdk
angle_style spica
angle_style sdk/omp
angle_style spica/omp
Examples
""""""""
.. code-block:: LAMMPS
angle_style sdk
angle_style spica
angle_coeff 1 300.0 107.0
Description
"""""""""""
The *sdk* angle style is a combination of the harmonic angle potential,
The *spica* angle style is a combination of the harmonic angle potential,
.. math::
@ -34,10 +34,10 @@ The *sdk* angle style is a combination of the harmonic angle potential,
where :math:`\theta_0` is the equilibrium value of the angle and
:math:`K` a prefactor, with the *repulsive* part of the non-bonded
*lj/sdk* pair style between the atoms 1 and 3. This angle potential is
intended for coarse grained MD simulations with the CMM parameterization
using the :doc:`pair_style lj/sdk <pair_sdk>`. Relative to the
pair_style *lj/sdk*, however, the energy is shifted by
*lj/spica* pair style between the atoms 1 and 3. This angle potential is
intended for coarse grained MD simulations with the SPICA (formerly called SDK) parameterization
using the :doc:`pair_style lj/spica <pair_spica>`. Relative to the
pair_style *lj/spica*, however, the energy is shifted by
:math:`\epsilon`, to avoid sudden jumps. Note that the usual 1/2 factor
is included in :math:`K`.
@ -51,9 +51,12 @@ The following coefficients must be defined for each angle type via the
radians internally; hence :math:`K` is effectively energy per
radian\^2.
The required *lj/sdk* parameters are extracted automatically from the
The required *lj/spica* parameters are extracted automatically from the
pair_style.
Style *sdk*, the original implementation of style *spica*, is available
for backward compatibility.
----------
.. include:: accel_styles.rst
@ -64,14 +67,14 @@ Restrictions
""""""""""""
This angle style can only be used if LAMMPS was built with the
CG-SDK package. See the :doc:`Build package <Build_package>` doc
CG-SPICA package. See the :doc:`Build package <Build_package>` doc
page for more info.
Related commands
""""""""""""""""
:doc:`angle_coeff <angle_coeff>`, :doc:`angle_style harmonic <angle_harmonic>`, :doc:`pair_style lj/sdk <pair_sdk>`,
:doc:`pair_style lj/sdk/coul/long <pair_sdk>`
:doc:`angle_coeff <angle_coeff>`, :doc:`angle_style harmonic <angle_harmonic>`, :doc:`pair_style lj/spica <pair_spica>`,
:doc:`pair_style lj/spica/coul/long <pair_spica>`
Default
"""""""

5
doc/src/angle_style.rst
View File

@ -73,6 +73,7 @@ of (g,i,k,o,t) to indicate which accelerated styles exist.
* :doc:`zero <angle_zero>` - topology but no interactions
* :doc:`hybrid <angle_hybrid>` - define multiple styles of angle interactions
* :doc:`amoeba <angle_amoeba>` - AMOEBA angle
* :doc:`charmm <angle_charmm>` - CHARMM angle
* :doc:`class2 <angle_class2>` - COMPASS (class 2) angle
* :doc:`class2/p6 <angle_class2>` - COMPASS (class 2) angle expanded to 6th order
@ -87,11 +88,11 @@ 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:`fourier <angle_fourier>` - angle with multiple cosine terms
* :doc:`fourier/simple <angle_fourier_simple>` - angle with a single cosine term
* :doc:`gaussian <angle_gaussian>` - multicentered Gaussian-based angle potential
* :doc:`gaussian <angle_gaussian>` - multi-centered Gaussian-based angle potential
* :doc:`harmonic <angle_harmonic>` - harmonic angle
* :doc:`mm3 <angle_mm3>` - anharmonic angle
* :doc:`quartic <angle_quartic>` - angle with cubic and quartic terms
* :doc:`sdk <angle_sdk>` - harmonic angle with repulsive SDK pair style between 1-3 atoms
* :doc:`spica <angle_spica>` - harmonic angle with repulsive SPICA pair style between 1-3 atoms
* :doc:`table <angle_table>` - tabulated by angle
----------

104
doc/src/atom_style.rst
View File

@ -10,7 +10,7 @@ Syntax
atom_style style args
* style = *angle* or *atomic* or *body* or *bond* or *charge* or *dipole* or *dpd* or *edpd* or *electron* or *ellipsoid* or *full* or *line* or *mdpd* or *molecular* or *oxdna* or *peri* or *smd* or *sph* or *sphere* or *spin* or *tdpd* or *tri* or *template* or *hybrid*
* style = *amoeba* or *angle* or *atomic* or *body* or *bond* or *charge* or *dielectric* or *dipole* or *dpd* or *edpd* or *electron* or *ellipsoid* or *full* or *line* or *mdpd* or *mesont* or *molecular* or *oxdna* or *peri* or *smd* or *sph* or *sphere* or *bpm/sphere* or *spin* or *tdpd* or *tri* or *template* or *wavepacket* or *hybrid*
.. parsed-literal::
@ -21,6 +21,7 @@ Syntax
see the :doc:`Howto body <Howto_body>` doc
page for details
*sphere* arg = 0/1 (optional) for static/dynamic particle radii
*bpm/sphere* arg = 0/1 (optional) for static/dynamic particle radii
*tdpd* arg = Nspecies
Nspecies = # of chemical species
*template* arg = template-ID
@ -77,6 +78,8 @@ coordinates, velocities, atom IDs and types. See the
:doc:`set <set>` commands for info on how to set these various
quantities.
+--------------+-----------------------------------------------------+--------------------------------------+
| *amoeba* | molecular + charge + 1/5 neighbors | AMOEBA/HIPPO polarized force fields |
+--------------+-----------------------------------------------------+--------------------------------------+
| *angle* | bonds and angles | bead-spring polymers with stiffness |
+--------------+-----------------------------------------------------+--------------------------------------+
@ -120,6 +123,8 @@ quantities.
+--------------+-----------------------------------------------------+--------------------------------------+
| *sphere* | diameter, mass, angular velocity | granular models |
+--------------+-----------------------------------------------------+--------------------------------------+
| *bpm/sphere* | diameter, mass, angular velocity, quaternion | granular bonded particle models (BPM)|
+--------------+-----------------------------------------------------+--------------------------------------+
| *spin* | magnetic moment | system with magnetic particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *tdpd* | chemical concentration | tDPD particles |
@ -134,15 +139,18 @@ quantities.
.. note::
It is possible to add some attributes, such as a molecule ID, to
atom styles that do not have them via the :doc:`fix property/atom <fix_property_atom>` command. This command also
allows new custom attributes consisting of extra integer or
floating-point values to be added to atoms. See the :doc:`fix property/atom <fix_property_atom>` page for examples of cases
where this is useful and details on how to initialize, access, and
output the custom values.
atom styles that do not have them via the :doc:`fix property/atom
<fix_property_atom>` command. This command also allows new custom
attributes consisting of extra integer or floating-point values to
be added to atoms. See the :doc:`fix property/atom
<fix_property_atom>` page for examples of cases where this is
useful and details on how to initialize, access, and output the
custom values.
All of the above styles define point particles, except the *sphere*,
*ellipsoid*, *electron*, *peri*, *wavepacket*, *line*, *tri*, and
*body* styles, which define finite-size particles. See the :doc:`Howto spherical <Howto_spherical>` page for an overview of using
*bpm/sphere*, *ellipsoid*, *electron*, *peri*, *wavepacket*, *line*,
*tri*, and *body* styles, which define finite-size particles. See the
:doc:`Howto spherical <Howto_spherical>` page for an overview of using
finite-size particle models with LAMMPS.
All of the point-particle styles assign mass to particles on a
@ -150,19 +158,20 @@ per-type basis, using the :doc:`mass <mass>` command, The finite-size
particle styles assign mass to individual particles on a per-particle
basis.
For the *sphere* style, the particles are spheres and each stores a
per-particle diameter and mass. If the diameter > 0.0, the particle
is a finite-size sphere. If the diameter = 0.0, it is a point
particle. Note that by use of the *disc* keyword with the :doc:`fix
nve/sphere <fix_nve_sphere>`, :doc:`fix nvt/sphere <fix_nvt_sphere>`,
:doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix npt/sphere
<fix_npt_sphere>` commands, spheres can be effectively treated as 2d
discs for a 2d simulation if desired. See also the :doc:`set
density/disc <set>` command. The *sphere* style takes an optional 0
or 1 argument. A value of 0 means the radius of each sphere is
constant for the duration of the simulation. A value of 1 means the
radii may vary dynamically during the simulation, e.g. due to use of
the :doc:`fix adapt <fix_adapt>` command.
For the *sphere* and *bpm/sphere* styles, the particles are spheres
and each stores a per-particle diameter and mass. If the diameter >
0.0, the particle is a finite-size sphere. If the diameter = 0.0, it
is a point particle. Note that by use of the *disc* keyword with the
:doc:`fix nve/sphere <fix_nve_sphere>`, :doc:`fix nvt/sphere
<fix_nvt_sphere>`, :doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix
npt/sphere <fix_npt_sphere>` commands for the *sphere* style, spheres
can be effectively treated as 2d discs for a 2d simulation if desired.
See also the :doc:`set density/disc <set>` command. The *sphere* and
*bpm/sphere* styles take an optional 0 or 1 argument. A value of 0
means the radius of each sphere is constant for the duration of the
simulation. A value of 1 means the radii may vary dynamically during
the simulation, e.g. due to use of the :doc:`fix adapt <fix_adapt>`
command.
For the *ellipsoid* style, the particles are ellipsoids and each
stores a flag which indicates whether it is a finite-size ellipsoid or
@ -171,15 +180,16 @@ vector with the 3 diameters of the ellipsoid and a quaternion 4-vector
with its orientation.
For the *dielectric* style, each particle can be either a physical
particle (e.g. an ion), or an interface particle representing a boundary
element. For physical particles, the per-particle properties are
the same as atom_style full. For interface particles, in addition to
these properties, each particle also has an area, a normal unit vector,
a mean local curvature, the mean and difference of the dielectric constants
of two sides of the interface, and the local dielectric constant at the
boundary element. The distinction between the physical and interface
particles is only meaningful when :doc:`fix polarize <fix_polarize>`
commands are applied to the interface particles.
particle (e.g. an ion), or an interface particle representing a
boundary element. For physical particles, the per-particle properties
are the same as atom_style full. For interface particles, in addition
to these properties, each particle also has an area, a normal unit
vector, a mean local curvature, the mean and difference of the
dielectric constants of two sides of the interface, and the local
dielectric constant at the boundary element. The distinction between
the physical and interface particles is only meaningful when :doc:`fix
polarize <fix_polarize>` commands are applied to the interface
particles.
For the *dipole* style, a point dipole is defined for each point
particle. Note that if you wish the particles to be finite-size
@ -195,6 +205,8 @@ position, which is represented by the eradius = electron size.
For the *peri* style, the particles are spherical and each stores a
per-particle mass and volume.
The *bpm/sphere* style is part of the BPM package.
The *oxdna* style is for coarse-grained nucleotides and stores the
3'-to-5' polarity of the nucleotide strand, which is set through
the bond topology in the data file. The first (second) atom in a
@ -266,16 +278,17 @@ showing the use of the *template* atom style versus *molecular*.
.. note::
When using the *template* style with a :doc:`molecule template <molecule>` that contains multiple molecules, you should
insure the atom types, bond types, angle_types, etc in all the
molecules are consistent. E.g. if one molecule represents H2O and
another CO2, then you probably do not want each molecule file to
define 2 atom types and a single bond type, because they will conflict
with each other when a mixture system of H2O and CO2 molecules is
defined, e.g. by the :doc:`read_data <read_data>` command. Rather the
H2O molecule should define atom types 1 and 2, and bond type 1. And
the CO2 molecule should define atom types 3 and 4 (or atom types 3 and
2 if a single oxygen type is desired), and bond type 2.
When using the *template* style with a :doc:`molecule template
<molecule>` that contains multiple molecules, you should insure the
atom types, bond types, angle_types, etc in all the molecules are
consistent. E.g. if one molecule represents H2O and another CO2,
then you probably do not want each molecule file to define 2 atom
types and a single bond type, because they will conflict with each
other when a mixture system of H2O and CO2 molecules is defined,
e.g. by the :doc:`read_data <read_data>` command. Rather the H2O
molecule should define atom types 1 and 2, and bond type 1. And
the CO2 molecule should define atom types 3 and 4 (or atom types 3
and 2 if a single oxygen type is desired), and bond type 2.
For the *body* style, the particles are arbitrary bodies with internal
attributes defined by the "style" of the bodies, which is specified by
@ -333,6 +346,8 @@ Many of the styles listed above are only enabled if LAMMPS was built
with a specific package, as listed below. See the :doc:`Build package
<Build_package>` page for more info.
The *amoeba* style is part of the AMOEBA package.
The *angle*, *bond*, *full*, *molecular*, and *template* styles are
part of the MOLECULE package.
@ -344,9 +359,11 @@ The *dipole* style is part of the DIPOLE package.
The *peri* style is part of the PERI package for Peridynamics.
The *oxdna* style is part of the CG-DNA package for coarse-grained simulation of DNA and RNA.
The *oxdna* style is part of the CG-DNA package for coarse-grained
simulation of DNA and RNA.
The *electron* style is part of the EFF package for :doc:`electronic force fields <pair_eff>`.
The *electron* style is part of the EFF package for :doc:`electronic
force fields <pair_eff>`.
The *dpd* style is part of the DPD-REACT package for dissipative
particle dynamics (DPD).
@ -357,7 +374,8 @@ dissipative particle dynamics (mDPD), and transport dissipative particle
dynamics (tDPD), respectively.
The *sph* style is part of the SPH package for smoothed particle
hydrodynamics (SPH). See `this PDF guide <PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
hydrodynamics (SPH). See `this PDF guide
<PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
The *mesont* style is part of the MESONT package.

257
doc/src/bond_bpm_rotational.rst Normal file
View File

@ -0,0 +1,257 @@
.. index:: bond_style bpm/rotational
bond_style bpm/rotational command
=================================
Syntax
""""""
.. code-block:: LAMMPS
bond_style bpm/rotational keyword value attribute1 attribute2 ...
* optional keyword = *overlay/pair* or *store/local* or *smooth*
.. parsed-literal::
*store/local* values = fix_ID N attributes ...
* fix_ID = ID of associated internal fix to store data
* N = prepare data for output every this many timesteps
* attributes = zero or more of the below attributes may be appended
*id1, id2* = IDs of 2 atoms in the bond
*time* = the timestep the bond broke
*x, y, z* = the center of mass position of the 2 atoms when the bond broke (distance units)
*x/ref, y/ref, z/ref* = the initial center of mass position of the 2 atoms (distance units)
*overlay/pair* value = none
bonded particles will still interact with pair forces
*smooth* value = *yes* or *no*
smooths bond forces near the breaking point
Examples
""""""""
.. code-block:: LAMMPS
bond_style bpm/rotational
bond_coeff 1 1.0 0.2 0.02 0.02 0.20 0.04 0.04 0.04 0.1 0.02 0.002 0.002
bond_style bpm/rotational store/local myfix 1000 time id1 id2
dump 1 all local 1000 dump.broken f_myfix[1] f_myfix[2] f_myfix[3]
dump_modify 1 write_header no
Description
"""""""""""
The *bpm/rotational* bond style computes forces and torques based on
deviations from the initial reference state of the two atoms. The
reference state is stored by each bond when it is first computed in
the setup of a run. Data is then preserved across run commands and is
written to :doc:`binary restart files <restart>` such that restarting
the system will not reset the reference state of a bond.
Forces include a normal and tangential component. The base normal force
has a magnitude of
.. math::
f_r = k_r (r - r_0)
where :math:`k_r` is a stiffness and :math:`r` is the current distance and
:math:`r_0` is the initial distance between the two particles.
A tangential force is applied perpendicular to the normal direction
which is proportional to the tangential shear displacement with a
stiffness of :math:`k_s`. This tangential force also induces a torque.
In addition, bending and twisting torques are also applied to
particles which are proportional to angular bending and twisting
displacements with stiffnesses of :math`k_b` and :math:`k_t',
respectively. Details on the calculations of shear displacements and
angular displacements can be found in :ref:`(Wang) <Wang2009>` and
:ref:`(Wang and Mora) <Wang2009b>`.
Bonds will break under sufficient stress. A breaking criteria is calculated
.. math::
B = \mathrm{max}\{0, \frac{f_r}{f_{r,c}} + \frac{|f_s|}{f_{s,c}} +
\frac{|\tau_b|}{\tau_{b,c}} + \frac{|\tau_t|}{\tau_{t,c}} \}
where :math:`|f_s|` is the magnitude of the shear force and
:math:`|\tau_b|` and :math:`|\tau_t|` are the magnitudes of the
bending and twisting forces, respectively. The corresponding variables
:math:`f_{r,c}` :math:`f_{s,c}`, :math:`\tau_{b,c}`, and
:math:`\tau_{t,c}` are critical limits to each force or torque. If
:math:`B` is ever equal to or exceeds one, the bond will break. This
is done by setting by setting its type to 0 such that forces and
torques are no longer computed.
After computing the base magnitudes of the forces and torques, they
can be optionally multiplied by an extra factor :math:`w` to smoothly
interpolate forces and torques to zero as the bond breaks. This term
is calculated as :math:`w = (1.0 - B^4)`. This smoothing factor can be
added or removed using the *smooth* keyword.
Finally, additional damping forces and torques are applied to the two
particles. A force is applied proportional to the difference in the
normal velocity of particles using a similar construction as
dissipative particle dynamics (:ref:`(Groot) <Groot3>`):
.. math::
F_D = - \gamma_n w (\hat{r} \bullet \vec{v})
where :math:`\gamma_n` is the damping strength, :math:`\hat{r}` is the
radial normal vector, and :math:`\vec{v}` is the velocity difference
between the two particles. Similarly, tangential forces are applied to
each atom proportional to the relative differences in sliding
velocities with a constant prefactor :math:`\gamma_s` (:ref:`(Wang et
al.) <Wang20152>`) along with their associated torques. The rolling and
twisting components of the relative angular velocities of the two
atoms are also damped by applying torques with prefactors of
:math:`\gamma_r` and :math:`\gamma_t`, respectively.
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:
* :math:`k_r` (force/distance units)
* :math:`k_s` (force/distance units)
* :math:`k_t` (force*distance/radians units)
* :math:`k_b` (force*distance/radians units)
* :math:`f_{r,c}` (force units)
* :math:`f_{s,c}` (force units)
* :math:`\tau_{b,c}` (force*distance units)
* :math:`\tau_{t,c}` (force*distance units)
* :math:`\gamma_n` (force/velocity units)
* :math:`\gamma_s` (force/velocity units)
* :math:`\gamma_r` (force*distance/velocity units)
* :math:`\gamma_t` (force*distance/velocity units)
By default, pair forces are not calculated between bonded particles.
Pair forces can alternatively be overlaid on top of bond forces using
the *overlay/pair* keyword. These settings require specific
:doc:`special_bonds <special_bonds>` settings described in the
restrictions. Further details can be found in the `:doc: how to
<Howto_BPM>` page on BPMs.
If the *store/local* keyword is used, this fix will track bonds that
break during the simulation. Whenever a bond breaks, data is processed
and transferred to an internal fix labeled *fix_ID*. This allows the
local data to be accessed by other LAMMPS commands.
Following any optional keyword/value arguments, a list of one or more
attributes is specified. These include the IDs of the two atoms in
the bond. The other attributes for the two atoms include the timestep
during which the bond broke and the current/initial center of mass
position of the two atoms.
Data is continuously accumulated over intervals of *N*
timesteps. At the end of each interval, all of the saved accumulated
data is deleted to make room for new data. Individual datum may
therefore persist anywhere between *1* to *N* timesteps depending on
when they are saved. This data can be accessed using the *fix_ID* and a
:doc:`dump local <dump>` command. To ensure all data is output,
the dump frequency should correspond to the same interval of *N*
timesteps. A dump frequency of an integer multiple of *N* can be used
to regularly output a sample of the accumulated data.
Note that when unbroken bonds are dumped to a file via the
:doc:`dump local <dump>` command, bonds with type 0 (broken bonds)
are not included.
The :doc:`delete_bonds <delete_bonds>` command can also be used to
query the status of broken bonds or permanently delete them, e.g.:
.. code-block:: LAMMPS
delete_bonds all stats
delete_bonds all bond 0 remove
----------
Restart and other info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This bond style writes the reference state of each bond to
:doc:`binary restart files <restart>`. Loading a restart file will
properly resume bonds.
The single() function of these pair styles returns 0.0 for the energy
of a pairwise interaction, since energy is not conserved in these
dissipative potentials. It also returns only the normal component of
the pairwise interaction force.
The accumulated data is not written to restart files and should be
output before a restart file is written to avoid missing data.
The internal fix calculates a local vector or local array depending on the
number of input values. The length of the vector or number of rows in
the array is the number of recorded, lost interactions. If a single
input is specified, a local vector is produced. If two or more inputs
are specified, a local array is produced where the number of columns =
the number of inputs. The vector or array can be accessed by any
command that uses local values from a compute as input. See the
:doc:`Howto output <Howto_output>` page for an overview of LAMMPS
output options.
The vector or array will be floating point values that correspond to
the specified attribute.
Restrictions
""""""""""""
This bond style can only be used if LAMMPS was built with the BPM
package. See the :doc:`Build package <Build_package>` doc page for
more info.
By default if pair interactions are to be disabled, this bond style
requires setting
.. code-block:: LAMMPS
special_bonds lj 0 1 1 coul 1 1 1
and :doc:`newton <newton>` must be set to bond off. If the
*overlay/pair* option is used, this bond style alternatively requires
setting
.. code-block:: LAMMPS
special_bonds lj/coul 1 1 1
The *bpm/rotational* style requires :doc:`atom style bpm/sphere <atom_style>`.
Related commands
""""""""""""""""
:doc:`bond_coeff <bond_coeff>`, :doc:`fix nve/bpm/sphere <fix_nve_bpm_sphere>`
Default
"""""""
The option defaults are *smooth* = *yes*
----------
.. _Wang2009:
**(Wang)** Wang, Acta Geotechnica, 4,
p 117-127 (2009).
.. _Wang2009b:
**(Wang and Mora)** Wang, Mora, Advances in Geocomputing,
119, p 183-228 (2009).
.. _Groot3:
**(Groot)** Groot and Warren, J Chem Phys, 107, 4423-35 (1997).
.. _Wang20152:
**(Wang et al, 2015)** Wang, Y., Alonso-Marroquin, F., & Guo,
W. W. (2015). Rolling and sliding in 3-D discrete element
models. Particuology, 23, 49-55.

202
doc/src/bond_bpm_spring.rst Normal file
View File

@ -0,0 +1,202 @@
.. index:: bond_style bpm/spring
bond_style bpm/spring command
=============================
Syntax
""""""
.. code-block:: LAMMPS
bond_style bpm/spring keyword value attribute1 attribute2 ...
* optional keyword = *overlay/pair* or *store/local* or *smooth*
.. parsed-literal::
*store/local* values = fix_ID N attributes ...
* fix_ID = ID of associated internal fix to store data
* N = prepare data for output every this many timesteps
* attributes = zero or more of the below attributes may be appended
*id1, id2* = IDs of 2 atoms in the bond
*time* = the timestep the bond broke
*x, y, z* = the center of mass position of the 2 atoms when the bond broke (distance units)
*x/ref, y/ref, z/ref* = the initial center of mass position of the 2 atoms (distance units)
*overlay/pair* value = none
bonded particles will still interact with pair forces
*smooth* value = *yes* or *no*
smooths bond forces near the breaking point
Examples
""""""""
.. code-block:: LAMMPS
bond_style bpm/spring
bond_coeff 1 1.0 0.05 0.1
bond_style bpm/spring myfix 1000 time id1 id2
dump 1 all local 1000 dump.broken f_myfix[1] f_myfix[2] f_myfix[3]
dump_modify 1 write_header no
Description
"""""""""""
The *bpm/spring* bond style computes forces and torques based on
deviations from the initial reference state of the two atoms. The
reference state is stored by each bond when it is first computed in
the setup of a run. Data is then preserved across run commands and is
written to :doc:`binary restart files <restart>` such that restarting
the system will not reset the reference state of a bond.
This bond style only applies central-body forces which conserve the
translational and rotational degrees of freedom of a bonded set of
particles. The force has a magnitude of
.. math::
F = k (r - r_0) w
where :math:`k_r` is a stiffness, :math:`r` is the current distance
and :math:`r_0` is the initial distance between the two particles, and
:math:`w` is an optional smoothing factor discussed below. Bonds will
break at a strain of :math:`\epsilon_c`. This is done by setting by
setting its type to 0 such that forces are no longer computed.
An additional damping force is applied to the bonded
particles. This forces is proportional to the difference in the
normal velocity of particles using a similar construction as
dissipative particle dynamics (:ref:`(Groot) <Groot4>`):
.. math::
F_D = - \gamma w (\hat{r} \bullet \vec{v})
where :math:`\gamma` is the damping strength, :math:`\hat{r}` is the
radial normal vector, and :math:`\vec{v}` is the velocity difference
between the two particles.
The smoothing factor :math:`w` can be added or removed using the
*smooth* keyword. It is constructed such that forces smoothly go
to zero, avoiding discontinuities, as bonds approach the critical strain
.. math::
w = 1.0 - \left( \frac{r - r_0}{r_0 \epsilon_c} \right)^8 .
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:
* :math:`k` (force/distance units)
* :math:`\epsilon_c` (unit less)
* :math:`\gamma` (force/velocity units)
By default, pair forces are not calculated between bonded particles.
Pair forces can alternatively be overlaid on top of bond forces using
the *overlay/pair* keyword. These settings require specific
:doc:`special_bonds <special_bonds>` settings described in the
restrictions. Further details can be found in the `:doc: how to
<Howto_BPM>` page on BPMs.
If the *store/local* keyword is used, this fix will track bonds that
break during the simulation. Whenever a bond breaks, data is processed
and transferred to an internal fix labeled *fix_ID*. This allows the
local data to be accessed by other LAMMPS commands.
Following any optional keyword/value arguments, a list of one or more
attributes is specified. These include the IDs of the two atoms in
the bond. The other attributes for the two atoms include the timestep
during which the bond broke and the current/initial center of mass
position of the two atoms.
Data is continuously accumulated over intervals of *N*
timesteps. At the end of each interval, all of the saved accumulated
data is deleted to make room for new data. Individual datum may
therefore persist anywhere between *1* to *N* timesteps depending on
when they are saved. This data can be accessed using the *fix_ID* and a
:doc:`dump local <dump>` command. To ensure all data is output,
the dump frequency should correspond to the same interval of *N*
timesteps. A dump frequency of an integer multiple of *N* can be used
to regularly output a sample of the accumulated data.
Note that when unbroken bonds are dumped to a file via the
:doc:`dump local <dump>` command, bonds with type 0 (broken bonds)
are not included.
The :doc:`delete_bonds <delete_bonds>` command can also be used to
query the status of broken bonds or permanently delete them, e.g.:
.. code-block:: LAMMPS
delete_bonds all stats
delete_bonds all bond 0 remove
----------
Restart and other info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This bond style writes the reference state of each bond to
:doc:`binary restart files <restart>`. Loading a restart
file will properly resume bonds.
The single() function of these pair styles returns 0.0 for the energy
of a pairwise interaction, since energy is not conserved in these
dissipative potentials.
The accumulated data is not written to restart files and should be
output before a restart file is written to avoid missing data.
The internal fix calculates a local vector or local array depending on the
number of input values. The length of the vector or number of rows in
the array is the number of recorded, lost interactions. If a single
input is specified, a local vector is produced. If two or more inputs
are specified, a local array is produced where the number of columns =
the number of inputs. The vector or array can be accessed by any
command that uses local values from a compute as input. See the
:doc:`Howto output <Howto_output>` page for an overview of LAMMPS
output options.
The vector or array will be floating point values that correspond to
the specified attribute.
Restrictions
""""""""""""
This bond style can only be used if LAMMPS was built with the BPM
package. See the :doc:`Build package <Build_package>` doc page for
more info.
By default if pair interactions are to be disabled, this bond style
requires setting
.. code-block:: LAMMPS
special_bonds lj 0 1 1 coul 1 1 1
and :doc:`newton <newton>` must be set to bond off. If the
*overlay/pair* option is used, this bond style alternatively requires
setting
.. code-block:: LAMMPS
special_bonds lj/coul 1 1 1
Related commands
""""""""""""""""
:doc:`bond_coeff <bond_coeff>`, :doc:`pair bpm/spring <pair_bpm_spring>`
Default
"""""""
The option defaults are *smooth* = *yes*
----------
.. _Groot4:
**(Groot)** Groot and Warren, J Chem Phys, 107, 4423-35 (1997).

3
doc/src/bond_quartic.rst
View File

@ -67,7 +67,8 @@ local maximum. If a bond length ever becomes :math:`> R_c`, LAMMPS "breaks"
the bond, which means two things. First, the bond potential is turned
off by setting its type to 0, and is no longer computed. Second, a
pairwise interaction between the two atoms is turned on, since they
are no longer bonded.
are no longer bonded. See the :doc:`Howto <Howto_broken_bonds>` page
on broken bonds for more information.
LAMMPS does the second task via a computational sleight-of-hand. It
subtracts the pairwise interaction as part of the bond computation.

2
doc/src/bond_style.rst
View File

@ -84,6 +84,8 @@ accelerated styles exist.
* :doc:`zero <bond_zero>` - topology but no interactions
* :doc:`hybrid <bond_hybrid>` - define multiple styles of bond interactions
* :doc:`bpm/rotational <bond_bpm_rotational>` - breakable bond with forces and torques based on deviation from reference state
* :doc:`bpm/spring <bond_bpm_spring>` - breakable bond with forces based on deviation from reference length
* :doc:`class2 <bond_class2>` - COMPASS (class 2) bond
* :doc:`fene <bond_fene>` - FENE (finite-extensible non-linear elastic) bond
* :doc:`fene/expand <bond_fene_expand>` - FENE bonds with variable size particles

6
doc/src/commands_list.rst
View File

@ -60,8 +60,7 @@ Commands
lattice
log
mass
mdi_engine
message
mdi
min_modify
min_spin
min_style
@ -97,9 +96,6 @@ Commands
restart
run
run_style
server
server_mc
server_md
set
shell
special_bonds

7
doc/src/compute.rst
View File

@ -179,6 +179,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`body/local <compute_body_local>` - attributes of body sub-particles
* :doc:`bond <compute_bond>` - energy of each bond sub-style
* :doc:`bond/local <compute_bond_local>` - distance and energy of each bond
* :doc:`born/matrix <compute_born_matrix>` - second derivative or potential with respect to strain
* :doc:`centro/atom <compute_centro_atom>` - centro-symmetry parameter for each atom
* :doc:`centroid/stress/atom <compute_stress_atom>` - centroid based stress tensor for each atom
* :doc:`chunk/atom <compute_chunk_atom>` - assign chunk IDs to each atom
@ -208,7 +209,8 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`erotate/sphere/atom <compute_erotate_sphere_atom>` - rotational energy for each spherical particle
* :doc:`event/displace <compute_event_displace>` - detect event on atom displacement
* :doc:`fabric <compute_fabric>` - calculates fabric tensors from pair interactions
* :doc:`fep <compute_fep>` -
* :doc:`fep <compute_fep>` - compute free energies for alchemical transformation from perturbation theory
* :doc:`fep/ta <compute_fep_ta>` - compute free energies for a test area perturbation
* :doc:`force/tally <compute_tally>` - force between two groups of atoms via the tally callback mechanism
* :doc:`fragment/atom <compute_cluster_atom>` - fragment ID for each atom
* :doc:`global/atom <compute_global_atom>` -
@ -235,6 +237,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`msd <compute_msd>` - mean-squared displacement of group of atoms
* :doc:`msd/chunk <compute_msd_chunk>` - mean-squared displacement for each chunk
* :doc:`msd/nongauss <compute_msd_nongauss>` - MSD and non-Gaussian parameter of group of atoms
* :doc:`nbond/atom <compute_nbond_atom>` - calculates number of bonds per atom
* :doc:`omega/chunk <compute_omega_chunk>` - angular velocity for each chunk
* :doc:`orientorder/atom <compute_orientorder_atom>` - Steinhardt bond orientational order parameters Ql
* :doc:`pair <compute_pair>` - values computed by a pair style
@ -281,6 +284,8 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`smd/vol <compute_smd_vol>` - per-particle volumes and their sum in Smooth Mach Dynamics
* :doc:`snap <compute_sna_atom>` - gradients of SNAP energy and forces w.r.t. linear coefficients and related quantities for fitting SNAP potentials
* :doc:`sna/atom <compute_sna_atom>` - bispectrum components for each atom
* :doc:`sna/grid <compute_sna_atom>` - global array of bispectrum components on a regular grid
* :doc:`sna/grid/local <compute_sna_atom>` - local array of bispectrum components on a regular grid
* :doc:`snad/atom <compute_sna_atom>` - derivative of bispectrum components for each atom
* :doc:`snav/atom <compute_sna_atom>` - virial contribution from bispectrum components for each atom
* :doc:`sph/e/atom <compute_sph_e_atom>` - per-atom internal energy of Smooth-Particle Hydrodynamics atoms

61
doc/src/compute_ave_sphere_atom.rst
View File

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

215
doc/src/compute_born_matrix.rst Normal file
View File

@ -0,0 +1,215 @@
.. index:: compute born/matrix
compute born/matrix command
===========================
Syntax
""""""
.. parsed-literal::
compute ID group-ID born/matrix keyword value ...
* ID, group-ID are documented in :doc:`compute <compute>` command
* born/matrix = style name of this compute command
* zero or more keyword/value pairs may be appended
.. parsed-literal::
keyword = *numdiff*
*numdiff* values = delta virial-ID
delta = magnitude of strain (dimensionless)
virial-ID = ID of pressure compute for virial (string)
Examples
""""""""
.. code-block:: LAMMPS
compute 1 all born/matrix
compute 1 all born/matrix bond angle
compute 1 all born/matrix numdiff 1.0e-4 myvirial
Description
"""""""""""
.. versionadded:: 4May2022
Define a compute that calculates
:math:`\frac{\partial{}^2U}{\partial\varepsilon_{i}\partial\varepsilon_{j}}` the
second derivatives of the potential energy :math:`U` w.r.t. strain
tensor :math:`\varepsilon` elements. These values are related to:
.. math::
C^{B}_{i,j}=\frac{1}{V}\frac{\partial{}^2U}{\partial{}\varepsilon_{i}\partial\varepsilon_{j}}
also called the Born term of elastic constants in the stress-stress fluctuation
formalism. This quantity can be used to compute the elastic constant tensor.
Using the symmetric Voigt notation, the elastic constant tensor can be written
as a 6x6 symmetric matrix:
.. math::
C_{i,j} = \langle{}C^{B}_{i,j}\rangle
+ \frac{V}{k_{B}T}\left(\langle\sigma_{i}\sigma_{j}\rangle\right.
\left.- \langle\sigma_{i}\rangle\langle\sigma_{j}\rangle\right)
+ \frac{Nk_{B}T}{V}
\left(\delta_{i,j}+(\delta_{1,i}+\delta_{2,i}+\delta_{3,i})\right.
\left.*(\delta_{1,j}+\delta_{2,j}+\delta_{3,j})\right)
In the above expression, :math:`\sigma` stands for the virial stress
tensor, :math:`\delta` is the Kronecker delta and the usual notation apply for
the number of particle, the temperature and volume respectively :math:`N`,
:math:`T` and :math:`V`. :math:`k_{B}` is the Boltzmann constant.
The Born term is a symmetric 6x6 matrix, as is the matrix of second derivatives
of potential energy w.r.t strain,
whose 21 independent elements are output in this order:
.. math::
\begin{matrix}
C_{1} & C_{7} & C_{8} & C_{9} & C_{10} & C_{11} \\
C_{7} & C_{2} & C_{12} & C_{13} & C_{14} & C_{15} \\
\vdots & C_{12} & C_{3} & C_{16} & C_{17} & C_{18} \\
\vdots & C_{13} & C_{16} & C_{4} & C_{19} & C_{20} \\
\vdots & \vdots & \vdots & C_{19} & C_{5} & C_{21} \\
\vdots & \vdots & \vdots & \vdots & C_{21} & C_{6}
\end{matrix}
in this matrix the indices of :math:`C_{k}` value are the corresponding element
:math:`k` in the global vector output by this compute. Each term comes from the sum
of the derivatives of every contribution to the potential energy
in the system as explained in :ref:`(VanWorkum)
<VanWorkum>`.
The output can be accessed using usual Lammps routines:
.. code-block:: LAMMPS
compute 1 all born/matrix
compute 2 all pressure NULL virial
variable S1 equal -c_2[1]
variable S2 equal -c_2[2]
variable S3 equal -c_2[3]
variable S4 equal -c_2[4]
variable S5 equal -c_2[5]
variable S6 equal -c_2[6]
fix 1 all ave/time 1 1 1 v_S1 v_S2 v_S3 v_S4 v_S5 v_S6 c_1[*] file born.out
In this example, the file *born.out* will contain the information needed to
compute the first and second terms of the elastic constant matrix in a post
processing procedure. The other required quantities can be accessed using any
other *LAMMPS* usual method. Several examples of this method are
provided in the examples/ELASTIC_T/BORN_MATRIX directory
described on the :doc:`Examples <Examples>` doc page.
NOTE: In the above :math:`C_{i,j}` computation, the fluctuation
term involving the virial stress tensor :math:`\sigma` is the
covariance between each elements. In a
solid the stress fluctuations can vary rapidly, while average
fluctuations can be slow to converge.
A detailed analysis of the convergence rate of all the terms in
the elastic tensor
is provided in the paper by Clavier et al. :ref:`(Clavier) <Clavier2>`.
Two different computation methods for the Born matrix are implemented in this
compute and are mutually exclusive.
The first one is a direct computation from the analytical formula from the
different terms of the potential used for the simulations :ref:`(VanWorkum)
<VanWorkum>`. However, the implementation of such derivations must be done
for every potential form. This has not been done yet and can be very
complicated for complex potentials. At the moment a warning message is
displayed for every term that is not supporting the compute at the moment.
This method is the default for now.
The second method uses finite differences of energy to numerically approximate
the second derivatives :ref:`(Zhen) <Zhen>`. This is useful when using
interaction styles for which the analytical second derivatives have not been
implemented. In this cases, the compute applies linear strain fields of
magnitude *delta* to all the atoms relative to a point at the center of the
box. The strain fields are in six different directions, corresponding to the
six Cartesian components of the stress tensor defined by LAMMPS. For each
direction it applies the strain field in both the positive and negative senses,
and the new stress virial tensor of the entire system is calculated after each.
The difference in these two virials divided by two times *delta*, approximates
the corresponding components of the second derivative, after applying a
suitable unit conversion.
.. note::
It is important to choose a suitable value for delta, the magnitude of
strains that are used to generate finite difference
approximations to the exact virial stress. For typical systems, a value in
the range of 1 part in 1e5 to 1e6 will be sufficient.
However, the best value will depend on a multitude of factors
including the stiffness of the interatomic potential, the thermodynamic
state of the material being probed, and so on. The only way to be sure
that you have made a good choice is to do a sensitivity study on a
representative atomic configuration, sweeping over a wide range of
values of delta. If delta is too small, the output values will vary
erratically due to truncation effects. If delta is increased beyond a
certain point, the output values will start to vary smoothly with
delta, due to growing contributions from higher order derivatives. In
between these two limits, the numerical virial values should be largely
independent of delta.
The keyword requires the additional arguments *delta* and *virial-ID*.
*delta* gives the size of the applied strains. *virial-ID* gives
the ID string of the pressure compute that provides the virial stress tensor,
requiring that it use the virial keyword e.g.
.. code-block:: LAMMPS
compute myvirial all pressure NULL virial
compute 1 all born/matrix numdiff 1.0e-4 myvirial
**Output info:**
This compute calculates a global vector with 21 values that are
the second derivatives of the potential energy w.r.t. strain.
The values are in energy units.
The values are ordered as explained above. These values can be used
by any command that uses global values from a compute as input. See
the :doc:`Howto output <Howto_output>` doc page for an overview of
LAMMPS output options.
The array values calculated by this compute are all "extensive".
Restrictions
""""""""""""
This compute is part of the EXTRA-COMPUTE package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info. LAMMPS was built with that package. See
the :doc:`Build package <Build_package>` page for more info.
The Born term can be decomposed as a product of two terms. The first one is a
general term which depends on the configuration. The second one is specific to
every interaction composing your force field (non-bonded, bonds, angle...).
Currently not all LAMMPS interaction styles implement the *born_matrix* method
giving first and second order derivatives and LAMMPS will exit with an error if
this compute is used with such interactions unless the *numdiff* option is
also used. The *numdiff* option cannot be used with any other keyword. In this
situation, LAMMPS will also exit with an error.
Default
"""""""
none
----------
.. _VanWorkum:
**(Van Workum)** K. Van Workum et al., J. Chem. Phys. 125 144506 (2006)
.. _Clavier2:
**(Clavier)** G. Clavier, N. Desbiens, E. Bourasseau, V. Lachet, N. Brusselle-Dupend and B. Rousseau, Mol Sim, 43, 1413 (2017).
.. _Zhen:
**(Zhen)** Y. Zhen, C. Chu, Computer Physics Communications 183(2012)261-265

6
doc/src/compute_chunk_atom.rst
View File

@ -15,7 +15,7 @@ Syntax
.. parsed-literal::
style = *bin/1d* or *bin/2d* or *bin/3d* or *bin/sphere* or *type* or *molecule* or c_ID, c_ID[I], f_ID, f_ID[I], v_name
style = *bin/1d* or *bin/2d* or *bin/3d* or *bin/sphere* or *bin/cylinder* or *type* or *molecule* or c_ID, c_ID[I], f_ID, f_ID[I], v_name
*bin/1d* args = dim origin delta
dim = *x* or *y* or *z*
origin = *lower* or *center* or *upper* or coordinate value (distance units)
@ -49,7 +49,7 @@ Syntax
v_name = per-atom vector calculated by an atom-style variable with name
* zero or more keyword/values pairs may be appended
* keyword = *region* or *nchunk* or *static* or *compress* or *bound* or *discard* or *pbc* or *units*
* keyword = *region* or *nchunk* or *limit* or *ids* or *compress* or *discard* or *bound* or *pbc* or *units*
.. parsed-literal::
@ -74,7 +74,7 @@ Syntax
no = keep atoms with out-of-range chunk IDs by assigning a valid chunk ID
mixed = keep or discard such atoms according to spatial binning rule
*bound* values = x/y/z lo hi
x/y/z = *x* or *y* or *z* to bound sptial bins in this dimension
x/y/z = *x* or *y* or *z* to bound spatial bins in this dimension
lo = *lower* or coordinate value (distance units)
hi = *upper* or coordinate value (distance units)
*pbc* value = *no* or *yes*

10
doc/src/compute_contact_atom.rst
View File

@ -8,10 +8,11 @@ Syntax
.. parsed-literal::
compute ID group-ID contact/atom
compute ID group-ID contact/atom group2-ID
* ID, group-ID are documented in :doc:`compute <compute>` command
* contact/atom = style name of this compute command
* group2-ID = optional argument to restrict which atoms to consider for contacts (see below)
Examples
""""""""
@ -19,6 +20,7 @@ Examples
.. code-block:: LAMMPS
compute 1 all contact/atom
compute 1 all contact/atom mygroup
Description
"""""""""""
@ -45,6 +47,9 @@ overview of LAMMPS output options.
The per-atom vector values will be a number >= 0.0, as explained
above.
The optional *group2-ID* argument allows to specify from which group atoms
contribute to the coordination number. Default setting is group 'all'.
Restrictions
""""""""""""
@ -63,4 +68,7 @@ Related commands
Default
"""""""
*group2-ID* = all
none

99
doc/src/compute_fep_ta.rst Normal file
View File

@ -0,0 +1,99 @@
.. index:: compute fep/ta
compute fep/ta command
======================
Syntax
""""""
.. parsed-literal::
compute ID group-ID fep/ta temp plane scale_factor keyword value ...
* ID, group-ID are documented in the :doc:`compute <compute>` command
* fep/ta = name of this compute command
* temp = external temperature (as specified for constant-temperature run)
* plane = *xy* or *xz* or *yz*
* scale_factor = multiplicative factor for change in plane area
* zero or more keyword/value pairs may be appended
* keyword = *tail*
.. parsed-literal::
*tail* value = *no* or *yes*
*no* = ignore tail correction to pair energies (usually small in fep)
*yes* = include tail correction to pair energies
Examples
""""""""
.. code-block:: LAMMPS
compute 1 all fep/ta 298 xy 1.0005
Description
"""""""""""
Define a computation that calculates the change in the free energy due
to a test-area (TA) perturbation :ref:`(Gloor) <Gloor>`. The test-area
approach can be used to determine the interfacial tension of the system
in a single simulation:
.. math::
\gamma = \lim_{\Delta \mathcal{A} \to 0} \left( \frac{\Delta A_{0 \to 1 }}{\Delta \mathcal{A}}\right)_{N,V,T}
= - \frac{kT}{\Delta \mathcal{A}} \ln \left< \exp(-(U_1 - U_0)/kT) \right>_0
During the perturbation, both axes of *plane* are scaled by multiplying
:math:`\sqrt{scale\_factor}`, while the other axis divided by
*scale_factor* such that the overall volume of the system is maintained.
The *tail* keyword controls the calculation of the tail correction to
"van der Waals" pair energies beyond the cutoff, if this has been
activated via the :doc:`pair_modify <pair_modify>` command. If the
perturbation is small, the tail contribution to the energy difference
between the reference and perturbed systems should be negligible.
----------
Output info
"""""""""""
This compute calculates a global vector of length 3 which contains the
energy difference ( :math:`U_1-U_0` ) as c_ID[1], the Boltzmann factor
:math:`\exp(-(U_1-U_0)/kT)`, as c_ID[2] and the change in the *plane*
area :math:`\Delta \mathcal{A}` as c_ID[3]. :math:`U_1` is the potential
energy of the perturbed state and :math:`U_0` is the potential energy of
the reference state. The energies include kspace terms if these are
used in the simulation.
These output results can be used by any command that uses a global
scalar or vector from a compute as input. See the :doc:`Howto output
<Howto_output>` page for an overview of LAMMPS output options. For
example, the computed values can be averaged using :doc:`fix ave/time
<fix_ave_time>`.
Restrictions
""""""""""""
Constraints, like fix shake, may lead to incorrect values for energy difference.
This compute is distributed as the FEP package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
Related commands
""""""""""""""""
:doc:`compute fep <compute_fep>`
Default
"""""""
The option defaults are *tail* = *no*\ .
----------
.. _Gloor:
**(Gloor)** Gloor, J Chem Phys, 123, 134703 (2005)

12
doc/src/compute_msd.rst
View File

@ -75,10 +75,11 @@ solids undergoing thermal motion.
.. note::
Initial coordinates are stored in "unwrapped" form, by using the
image flags associated with each atom. See the :doc:`dump custom <dump>` command for a discussion of "unwrapped" coordinates.
See the Atoms section of the :doc:`read_data <read_data>` command for a
discussion of image flags and how they are set for each atom. You can
reset the image flags (e.g. to 0) before invoking this compute by
image flags associated with each atom. See the :doc:`dump custom
<dump>` command for a discussion of "unwrapped" coordinates. See the
Atoms section of the :doc:`read_data <read_data>` command for a
discussion of image flags and how they are set for each atom. You
can reset the image flags (e.g. to 0) before invoking this compute by
using the :doc:`set image <set>` command.
.. note::
@ -108,7 +109,8 @@ distance\^2 :doc:`units <units>`.
Restrictions
""""""""""""
none
Compute *msd* cannot be used with a dynamic group.
Related commands
""""""""""""""""

7
doc/src/compute_msd_nongauss.rst
View File

@ -74,8 +74,11 @@ the third is dimensionless.
Restrictions
""""""""""""
This compute is part of the EXTRA-COMPUTE package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
Compute *msd/nongauss* cannot be used with a dynamic group.
This compute is part of the EXTRA-COMPUTE package. It is only enabled
if LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
Related commands
""""""""""""""""

52
doc/src/compute_nbond_atom.rst Normal file
View File

@ -0,0 +1,52 @@
.. index:: compute nbond/atom
compute nbond/atom command
==========================
Syntax
""""""
.. parsed-literal::
compute ID group-ID nbond/atom
* ID, group-ID are documented in :doc:`compute <compute>` command
* nbond/atom = style name of this compute command
Examples
""""""""
.. code-block:: LAMMPS
compute 1 all nbond/atom
Description
"""""""""""
Define a computation that computes the number of bonds each atom is
part of. Bonds which are broken are not counted in the tally. See
the :doc:`Howto broken bonds <Howto_bpm>` page for more information.
The number of bonds will be zero for atoms not in the specified
compute group. This compute does not depend on Newton bond settings.
Output info
"""""""""""
This compute calculates a per-atom vector, which can be accessed by
any command that uses per-atom values from a compute as input. See
the :doc:`Howto output <Howto_output>` doc page for an overview of
LAMMPS output options.
Restrictions
""""""""""""
This fix can only be used if LAMMPS was built with the BPM package.
See the :doc:`Build package <Build_package>` doc page for more info.
Related commands
""""""""""""""""
Default
"""""""
none

6
doc/src/compute_orientorder_atom.rst
View File

@ -19,12 +19,12 @@ Syntax
.. parsed-literal::
keyword = *cutoff* or *nnn* or *degrees* or *components* or *chunksize*
keyword = *cutoff* or *nnn* or *degrees* or *wl* or *wl/hat* or *components* or *chunksize*
*cutoff* value = distance cutoff
*nnn* value = number of nearest neighbors
*degrees* values = nlvalues, l1, l2,...
*wl* value = yes or no
*wl/hat* value = yes or no
*wl* value = *yes* or *no*
*wl/hat* value = *yes* or *no*
*components* value = ldegree
*chunksize* value = number of atoms in each pass

11
doc/src/compute_reduce.rst
View File

@ -23,7 +23,7 @@ Syntax
*reduce/region* arg = region-ID
region-ID = ID of region to use for choosing atoms
* mode = *sum* or *min* or *max* or *ave* or *sumsq* or *avesq*
* mode = *sum* or *min* or *max* or *ave* or *sumsq* or *avesq* or *sumabs* or *aveabs*
* one or more inputs can be listed
* input = x, y, z, vx, vy, vz, fx, fy, fz, c_ID, c_ID[N], f_ID, f_ID[N], v_name
@ -77,7 +77,10 @@ option sums the square of the values in the vector into a global
total. The *avesq* setting does the same as *sumsq*, then divides the
sum of squares by the number of values. The last two options can be
useful for calculating the variance of some quantity, e.g. variance =
sumsq - ave\^2.
sumsq - ave\^2. The *sumabs* option sums the absolute values in the
vector into a global total. The *aveabs* setting does the same as
*sumabs*, then divides the sum of absolute values by the number of
values.
Each listed input is operated on independently. For per-atom inputs,
the group specified with this command means only atoms within the
@ -189,7 +192,7 @@ value. If multiple inputs are specified, this compute produces a
global vector of values, the length of which is equal to the number of
inputs specified.
As discussed below, for the *sum* and *sumsq* modes, the value(s)
As discussed below, for the *sum*, *sumabs* and *sumsq* modes, the value(s)
produced by this compute are all "extensive", meaning their value
scales linearly with the number of atoms involved. If normalized
values are desired, this compute can be accessed by the :doc:`thermo_style custom <thermo_style>` command with :doc:`thermo_modify norm yes <thermo_modify>` set as an option. Or it can be accessed by a
@ -208,7 +211,7 @@ compute as input. See the :doc:`Howto output <Howto_output>` doc page
for an overview of LAMMPS output options.
All the scalar or vector values calculated by this compute are
"intensive", except when the *sum* or *sumsq* modes are used on
"intensive", except when the *sum*, *sumabs* or *sumsq* modes are used on
per-atom or local vectors, in which case the calculated values are
"extensive".

7
doc/src/compute_rigid_local.rst
View File

@ -127,19 +127,16 @@ The *vx*, *vy*, *vz*, *fx*, *fy*, *fz* attributes are components of
the COM velocity and force on the COM of the body.
The *omegax*, *omegay*, and *omegaz* attributes are the angular
velocity components of the body around its COM.
velocity components of the body in the system frame around its COM.
The *angmomx*, *angmomy*, and *angmomz* attributes are the angular
momentum components of the body around its COM.
momentum components of the body in the system frame around its COM.
The *quatw*, *quati*, *quatj*, and *quatk* attributes are the
components of the 4-vector quaternion representing the orientation of
the rigid body. See the :doc:`set <set>` command for an explanation of
the quaternion vector.
The *angmomx*, *angmomy*, and *angmomz* attributes are the angular
momentum components of the body around its COM.
The *tqx*, *tqy*, *tqz* attributes are components of the torque acting
on the body around its COM.

4
doc/src/compute_saed.rst
View File

@ -41,8 +41,8 @@ Examples
compute 1 all saed 0.0251 Al O Kmax 1.70 Zone 0 0 1 dR_Ewald 0.01 c 0.5 0.5 0.5
compute 2 all saed 0.0251 Ni Kmax 1.70 Zone 0 0 0 c 0.05 0.05 0.05 manual echo
fix saed/vtk 1 1 1 c_1 file Al2O3_001.saed
fix saed/vtk 1 1 1 c_2 file Ni_000.saed
fix 1 all saed/vtk 1 1 1 c_1 file Al2O3_001.saed
fix 2 all saed/vtk 1 1 1 c_2 file Ni_000.saed
Description
"""""""""""

2
doc/src/compute_smd_triangle_vertices.rst
View File

@ -18,7 +18,7 @@ Examples
.. code-block:: LAMMPS
compute 1 all smd/triangle/mesh/vertices
compute 1 all smd/triangle/vertices
Description
"""""""""""

199
doc/src/compute_sna_atom.rst
View File

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

4
doc/src/compute_tally.rst
View File

@ -198,7 +198,9 @@ potentials only include the pair potential portion of the EAM
interaction when used by this compute, not the embedding term. Also
bonded or Kspace interactions do not contribute to this compute.
The computes in this package are not compatible with dynamic groups.
When used with dynamic groups, a :doc:`run 0 <run>` command needs to
be inserted in order to initialize the dynamic groups before accessing
the computes.
Related commands
""""""""""""""""

45
doc/src/compute_temp_profile.rst
View File

@ -76,21 +76,28 @@ velocity for each atom. Note that if there is only one atom in the
bin, its thermal velocity will thus be 0.0.
After the spatially-averaged velocity field has been subtracted from
each atom, the temperature is calculated by the formula KE = (dim\*N
- dim\*Nx\*Ny\*Nz) k T/2, where KE = total kinetic energy of the group of
atoms (sum of 1/2 m v\^2), dim = 2 or 3 = dimensionality of the
simulation, N = number of atoms in the group, k = Boltzmann constant,
and T = temperature. The dim\*Nx\*Ny\*Nz term are degrees of freedom
subtracted to adjust for the removal of the center-of-mass velocity in
each of Nx\*Ny\*Nz bins, as discussed in the :ref:`(Evans) <Evans1>` paper.
each atom, the temperature is calculated by the formula
*KE* = (*dim\*N* - *Ns\*Nx\*Ny\*Nz* - *extra* ) *k* *T*/2, where *KE* = total
kinetic energy of the group of atoms (sum of 1/2 *m* *v*\^2), *dim* = 2
or 3 = dimensionality of the simulation, *Ns* = 0, 1, 2 or 3 for
streaming velocity subtracted in 0, 1, 2 or 3 dimensions, *extra* = extra
degrees-of-freedom, *N* = number of atoms in the group, *k* = Boltzmann
constant, and *T* = temperature. The *Ns\*Nx\*Ny\*Nz* term is degrees
of freedom subtracted to adjust for the removal of the center-of-mass
velocity in each direction of the *Nx\*Ny\*Nz* bins, as discussed in the
:ref:`(Evans) <Evans1>` paper. The extra term defaults to (*dim* - *Ns*)
and accounts for overall conservation of center-of-mass velocity across
the group in directions where streaming velocity is *not* subtracted. This
can be altered using the *extra* option of the
:doc:`compute_modify <compute_modify>` command.
If the *out* keyword is used with a *tensor* value, which is the
default, a kinetic energy tensor, stored as a 6-element vector, is
also calculated by this compute for use in the computation of a
pressure tensor. The formula for the components of the tensor is the
same as the above formula, except that v\^2 is replaced by vx\*vy for
the xy component, etc. The 6 components of the vector are ordered xx,
yy, zz, xy, xz, yz.
same as the above formula, except that *v*\^2 is replaced by *vx\*vy* for
the xy component, etc. The 6 components of the vector are ordered *xx,
yy, zz, xy, xz, yz.*
If the *out* keyword is used with a *bin* value, the count of atoms
and computed temperature for each bin are stored for output, as an
@ -123,10 +130,20 @@ needed, the subtracted degrees-of-freedom can be altered using the
.. note::
When using the *out* keyword with a value of *bin*, the
calculated temperature for each bin does not include the
degrees-of-freedom adjustment described in the preceding paragraph,
for fixes that constrain molecular motion. It does include the
adjustment due to the *extra* option, which is applied to each bin.
calculated temperature for each bin includes the degrees-of-freedom
adjustment described in the preceding paragraph for fixes that
constrain molecular motion, as well as the adjustment due to
the *extra* option (which defaults to *dim* - *Ns* as described above),
by fractionally applying them based on the fraction of atoms in each
bin. As a result, the bin degrees-of-freedom summed over all bins exactly
equals the degrees-of-freedom used in the scalar temperature calculation,
:math:`\Sigma N_{DOF_i} = N_{DOF}` and the corresponding relation for temperature
is also satisfied :math:`\Sigma N_{DOF_i} T_i = N_{DOF} T`.
These relations will breakdown in cases where the adjustment
exceeds the actual number of degrees-of-freedom in a bin. This could happen
if a bin is empty or in situations where rigid molecules
are non-uniformly distributed, in which case the reported
temperature within a bin may not be accurate.
See the :doc:`Howto thermostat <Howto_thermostat>` page for a
discussion of different ways to compute temperature and perform

5
doc/src/compute_viscosity_cos.rst
View File

@ -21,12 +21,13 @@ Examples
.. code-block:: LAMMPS
units real
compute cos all viscosity/cos
variable V equal c_cos[7]
variable A equal 0.02E-5
variable A equal 0.02E-5 # A/fs^2
variable density equal density
variable lz equal lz
variable reciprocalViscosity equal v_V/${A}/v_density*39.4784/v_lz/v_lz*100
variable reciprocalViscosity equal v_V/${A}/v_density*39.4784/v_lz/v_lz*100 # 1/(Pa*s)
Description
"""""""""""

383
doc/src/create_atoms.rst
View File

@ -11,7 +11,7 @@ Syntax
create_atoms type style args keyword values ...
* type = atom type (1-Ntypes) of atoms to create (offset for molecule creation)
* style = *box* or *region* or *single* or *random*
* style = *box* or *region* or *single* or *mesh* or *random*
.. parsed-literal::
@ -20,17 +20,19 @@ Syntax
region-ID = particles will only be created if contained in the region
*single* args = x y z
x,y,z = coordinates of a single particle (distance units)
*mesh* args = STL-file
STL-file = file with triangle mesh in STL format
*random* args = N seed region-ID
N = number of particles to create
seed = random # seed (positive integer)
region-ID = create atoms within this region, use NULL for entire simulation box
* zero or more keyword/value pairs may be appended
* keyword = *mol* or *basis* or *ratio* or *subset* or *remap* or *var* or *set* or *rotate* or *units*
* keyword = *mol* or *basis* or *ratio* or *subset* or *remap* or *var* or *set* or *rotate* or *overlap* or *maxtry* or *units*
.. parsed-literal::
*mol* value = template-ID seed
*mol* values = template-ID seed
template-ID = ID of molecule template specified in a separate :doc:`molecule <molecule>` command
seed = random # seed (positive integer)
*basis* values = M itype
@ -47,9 +49,21 @@ Syntax
*set* values = dim name
dim = *x* or *y* or *z*
name = name of variable to set with x, y, or z atom position
*radscale* value = factor
factor = scale factor for setting atom radius
*meshmode* values = mode arg
mode = *bisect* or *qrand*
*bisect* arg = radthresh
radthresh = threshold value for *mesh* to determine when to split triangles (distance units)
*qrand* arg = density
density = minimum number density for atoms place on *mesh* triangles (inverse distance squared units)
*rotate* values = theta Rx Ry Rz
theta = rotation angle for single molecule (degrees)
Rx,Ry,Rz = rotation vector for single molecule
*overlap* value = Doverlap
Doverlap = only insert if at least this distance from all existing atoms
*maxtry* value = Ntry
Ntry = number of attempts to insert a particle before failure
*units* value = *lattice* or *box*
*lattice* = the geometry is defined in lattice units
*box* = the geometry is defined in simulation box units
@ -64,17 +78,21 @@ Examples
create_atoms 3 region regsphere basis 2 3 ratio 0.5 74637
create_atoms 3 single 0 0 5
create_atoms 1 box var v set x xpos set y ypos
create_atoms 2 random 50 12345 NULL overlap 2.0 maxtry 50
create_atoms 1 mesh open_box.stl meshmode qrand 0.1 units box
create_atoms 1 mesh funnel.stl meshmode bisect 4.0 units box radscale 0.9
Description
"""""""""""
This command creates atoms (or molecules) on a lattice, or a single
atom (or molecule), or a random collection of atoms (or molecules), as
an alternative to reading in their coordinates explicitly via a
:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
command. A simulation box must already exist, which is typically
created via the :doc:`create_box <create_box>` command. Before using
this command, a lattice must also be defined using the
This command creates atoms (or molecules) within the simulation box,
either on a lattice, or a single atom (or molecule), or on a surface
defined by a triangulated mesh, or a random collection of atoms (or
molecules). It is an alternative to reading in atom coordinates
explicitly via a :doc:`read_data <read_data>` or :doc:`read_restart
<read_restart>` command. A simulation box must already exist, which is
typically created via the :doc:`create_box <create_box>` command.
Before using this command, a lattice must also be defined using the
:doc:`lattice <lattice>` command, unless you specify the *single* style
with units = box or the *random* style. For the remainder of this doc
page, a created atom or molecule is referred to as a "particle".
@ -97,58 +115,128 @@ particular dimension, LAMMPS is careful to put exactly one particle at
the boundary (on either side of the box), not zero or two.
For the *region* style, a geometric volume is filled with particles on
the lattice. This volume what is inside the simulation box and is
also consistent with the region volume. See the :doc:`region <region>`
command for details. Note that a region can be specified so that its
"volume" is either inside or outside a geometric boundary. Also note
that if your region is the same size as a periodic simulation box (in
some dimension), LAMMPS does not implement the same logic described
above as for the *box* style, to insure exactly one particle at
periodic boundaries. if this is what you desire, you should either
use the *box* style, or tweak the region size to get precisely the
particles you want.
the lattice. This volume is what is both inside the simulation box
and also consistent with the region volume. See the :doc:`region
<region>` command for details. Note that a region can be specified so
that its "volume" is either inside or outside its geometric boundary.
Also note that if a region is the same size as a periodic simulation
box (in some dimension), LAMMPS does NOT implement the same logic
described above for the *box* style, to insure exactly one particle at
periodic boundaries. If this is desired, you should either use the
*box* style, or tweak the region size to get precisely the particles
you want.
For the *single* style, a single particle is added to the system at
the specified coordinates. This can be useful for debugging purposes
or to create a tiny system with a handful of particles at specified
positions.
For the *random* style, N particles are added to the system at
randomly generated coordinates, which can be useful for generating an
amorphous system. The particles are created one by one using the
specified random number *seed*, resulting in the same set of particles
coordinates, independent of how many processors are being used in the
simulation. If the *region-ID* argument is specified as NULL, then
the created particles will be anywhere in the simulation box. If a
*region-ID* is specified, a geometric volume is filled which is both
inside the simulation box and is also consistent with the region
volume. See the :doc:`region <region>` command for details. Note that
a region can be specified so that its "volume" is either inside or
outside a geometric boundary.
.. figure:: img/marble_race.jpg
:figwidth: 33%
:align: right
:target: _images/marble_race.jpg
.. versionadded:: 2Jun2022
For the *mesh* style, a file with a triangle mesh in `STL format
<https://en.wikipedia.org/wiki/STL_(file_format)>`_ is read and one or
more particles are placed into the area of each triangle. The reader
supports both ASCII and binary files conforming to the format on the
Wikipedia page. Binary STL files (e.g. as frequently offered for
3d-printing) can also be first converted to ASCII for editing with the
:ref:`stl_bin2txt tool <stlconvert>`. The use of the *units box* option
is required. There are two algorithms available for placing atoms:
*bisect* and *qrand*. They can be selected via the *meshmode* option;
*bisect* is the default. If the atom style allows it, the radius will
be set to a value depending on the algorithm and the value of the
*radscale* parameter (see below), and the atoms created from the mesh
are assigned a new molecule ID.
In *bisect* mode a particle is created at the center of each triangle
unless the average distance of the triangle vertices from its center is
larger than the *radthresh* value (default is lattice spacing in
x-direction). In case the average distance is over the threshold, the
triangle is recursively split into two halves along the the longest side
until the threshold is reached. There will be at least one sphere per
triangle. The value of *radthresh* is set as an argument to *meshmode
bisect*. The average distance of the vertices from the center is also
used to set the radius.
In *qrand* mode a quasi-random sequence is used to distribute particles
on mesh triangles using an approach by :ref:`(Roberts) <Roberts2019>`.
Particles are added to the triangle until the minimum number density is
met or exceeded such that every triangle will have at least one
particle. The minimum number density is set as an argument to the
*qrand* option. The radius will be set so that the sum of the area of
the radius of the particles created in place of a triangle will be equal
to the area of that triangle.
.. note::
Particles generated by the *random* style will typically be
highly overlapped which will cause many interatomic potentials to
compute large energies and forces. Thus you should either perform an
:doc:`energy minimization <minimize>` or run dynamics with :doc:`fix nve/limit <fix_nve_limit>` to equilibrate such a system, before
running normal dynamics.
The atom placement algorithms in the *mesh* style benefit from meshes
where triangles are close to equilateral. It is therefore
recommended to pre-process STL files to optimize the mesh
accordingly. There are multiple open source and commercial software
tools available with the capability to generate optimized meshes.
Note that this command adds particles to those that already exist.
This means it can be used to add particles to a system previously read
in from a data or restart file. Or the create_atoms command can be
used multiple times, to add multiple sets of particles to the
simulation. For example, grain boundaries can be created, by
interleaving create_atoms with :doc:`lattice <lattice>` commands
specifying different orientations. By using the create_atoms command
in conjunction with the :doc:`delete_atoms <delete_atoms>` command,
reasonably complex geometries can be created, or a protein can be
solvated with a surrounding box of water molecules.
.. note::
In all these cases, care should be taken to insure that new atoms do
not overlap existing atoms inappropriately, especially if molecules
are being added. The :doc:`delete_atoms <delete_atoms>` command can be
used to remove overlapping atoms or molecules.
In most cases the atoms created in *mesh* style will become an
immobile or rigid object that would not be time integrated or moved
by :doc:`fix move <fix_move>` or :doc:`fix rigid <fix_rigid>`. For
computational efficiency *and* to avoid undesired contributions to
pressure and potential energy due to close contacts, it is usually
beneficial to exclude computing interactions between the created
particles using :doc:`neigh_modify exclude <neigh_modify>`.
For the *random* style, *N* particles are added to the system at
randomly generated coordinates, which can be useful for generating an
amorphous system. The particles are created one by one using the
specified random number *seed*, resulting in the same set of particle
coordinates, independent of how many processors are being used in the
simulation. Unless the *overlap* keyword is specified, particles
created by the *random* style will typically be highly overlapped.
Various additional criteria can be used to accept or reject a random
particle insertion; see the keyword discussion below. Multiple
attempts per particle are made (see the *maxtry* keyword) until the
insertion is either successful or fails. If this command fails to add
all requested *N* particles, a warning will be output.
If the *region-ID* argument is specified as NULL, then the randomly
created particles will be anywhere in the simulation box. If a
*region-ID* is specified, a geometric volume is filled which is both
inside the simulation box and is also consistent with the region
volume. See the :doc:`region <region>` command for details. Note
that a region can be specified so that its "volume" is either inside
or outside its geometric boundary.
Note that the create_atoms command adds particles to those that
already exist. This means it can be used to add particles to a system
previously read in from a data or restart file. Or the create_atoms
command can be used multiple times, to add multiple sets of particles
to the simulation. For example, grain boundaries can be created, by
interleaving the create_atoms command with :doc:`lattice <lattice>`
commands specifying different orientations.
When this command is used, care should be taken to insure the
resulting system does not contain particles which are highly
overlapped. Such overlaps will cause many interatomic potentials to
compute huge energies and forces, leading to bad dynamics. There are
several strategies to avoid this problem:
* Use the :doc:`delete_atoms overlap <delete_atoms>` command after
create_atoms. For example, this strategy can be used to overlay and
surround a large protein molecule with a volume of water molecules,
then delete water molecules that overlap with the protein atoms.
* For the *random* style, use the optional *overlap* keyword to avoid
overlaps when each new particle is created.
* Before running dynamics on an overlapped system, perform an
:doc:`energy minimization <minimize>`. Or run initial dynamics with
:doc:`pair_style soft <pair_soft>` or with :doc:`fix nve/limit
<fix_nve_limit>` to un-overlap the particles, before running normal
dynamics.
.. note::
@ -156,12 +244,13 @@ used to remove overlapping atoms or molecules.
that are outside the simulation box; they will just be ignored by
LAMMPS. This is true even if you are using shrink-wrapped box
boundaries, as specified by the :doc:`boundary <boundary>` command.
However, you can first use the :doc:`change_box <change_box>` command to
temporarily expand the box, then add atoms via create_atoms, then
finally use change_box command again if needed to re-shrink-wrap the
new atoms. See the :doc:`change_box <change_box>` page for an
example of how to do this, using the create_atoms *single* style to
insert a new atom outside the current simulation box.
However, you can first use the :doc:`change_box <change_box>`
command to temporarily expand the box, then add atoms via
create_atoms, then finally use change_box command again if needed
to re-shrink-wrap the new atoms. See the :doc:`change_box
<change_box>` doc page for an example of how to do this, using the
create_atoms *single* style to insert a new atom outside the
current simulation box.
----------
@ -180,17 +269,19 @@ Using a lattice to add molecules, e.g. via the *box* or *region* or
points, except that entire molecules are added at each point, i.e. on
the point defined by each basis atom in the unit cell as it tiles the
simulation box or region. This is done by placing the geometric
center of the molecule at the lattice point, and giving the molecule a
random orientation about the point. The random *seed* specified with
the *mol* keyword is used for this operation, and the random numbers
generated by each processor are different. This means the coordinates
of individual atoms (in the molecules) will be different when running
on different numbers of processors, unlike when atoms are being
created in parallel.
center of the molecule at the lattice point, and (by default) giving
the molecule a random orientation about the point. The random *seed*
specified with the *mol* keyword is used for this operation, and the
random numbers generated by each processor are different. This means
the coordinates of individual atoms (in the molecules) will be
different when running on different numbers of processors, unlike when
atoms are being created in parallel.
Also note that because of the random rotations, it may be important to
use a lattice with a large enough spacing that adjacent molecules will
not overlap, regardless of their relative orientations.
Note that with random rotations, it may be important to use a lattice
with a large enough spacing that adjacent molecules will not overlap,
regardless of their relative orientations. See the description of the
*rotate* keyword below, which overrides the default random orientation
and inserts all molecules at a specified orientation.
.. note::
@ -204,7 +295,7 @@ not overlap, regardless of their relative orientations.
----------
This is the meaning of the other allowed keywords.
This is the meaning of the other optional keywords.
The *basis* keyword is only used when atoms (not molecules) are being
created. It specifies an atom type that will be assigned to specific
@ -234,18 +325,24 @@ and no particle is created if its position is outside the box.
The *var* and *set* keywords can be used together to provide a
criterion for accepting or rejecting the addition of an individual
atom, based on its coordinates. The *name* specified for the *var*
keyword is the name of an :doc:`equal-style variable <variable>` which
should evaluate to a zero or non-zero value based on one or two or
three variables which will store the x, y, or z coordinates of an atom
(one variable per coordinate). If used, these other variables must be
:doc:`internal-style variables <variable>` defined in the input script;
their initial numeric value can be anything. They must be
atom, based on its coordinates. They apply to all styles except
*single*. The *name* specified for the *var* keyword is the name of
an :doc:`equal-style variable <variable>` which should evaluate to a
zero or non-zero value based on one or two or three variables which
will store the x, y, or z coordinates of an atom (one variable per
coordinate). If used, these other variables must be
:doc:`internal-style variables <variable>` defined in the input
script; their initial numeric value can be anything. They must be
internal-style variables, because this command resets their values
directly. The *set* keyword is used to identify the names of these
other variables, one variable for the x-coordinate of a created atom,
one for y, and one for z.
.. figure:: img/sinusoid.jpg
:figwidth: 50%
:align: right
:target: _images/sinusoid.jpg
When an atom is created, its x,y,z coordinates become the values for
any *set* variable that is defined. The *var* variable is then
evaluated. If the returned value is 0.0, the atom is not created. If
@ -259,28 +356,26 @@ the sinusoid would appear to be "smoother". Also note the use of the
"xlat" and "ylat" :doc:`thermo_style <thermo_style>` keywords which
converts lattice spacings to distance.
.. only:: html
(Click on the image for a larger version)
.. code-block:: LAMMPS
dimension 2
variable x equal 100
variable y equal 25
lattice hex 0.8442
region box block 0 $x 0 $y -0.5 0.5
create_box 1 box
dimension 2
variable x equal 100
variable y equal 25
lattice hex 0.8442
region box block 0 $x 0 $y -0.5 0.5
create_box 1 box
variable xx internal 0.0
variable yy internal 0.0
variable v equal "(0.2*v_y*ylat * cos(v_xx/xlat * 2.0*PI*4.0/v_x) + 0.5*v_y*ylat - v_yy) > 0.0"
create_atoms 1 box var v set x xx set y yy
write_dump all atom sinusoid.lammpstrj
variable xx internal 0.0
variable yy internal 0.0
variable v equal "(0.2*v_y*ylat * cos(v_xx/xlat * 2.0*PI*4.0/v_x) + 0.5*v_y*ylat - v_yy) > 0.0"
create_atoms 1 box var v set x xx set y yy
write_dump all atom sinusoid.lammpstrj
.. image:: img/sinusoid.jpg
:scale: 50%
:align: center
.. raw:: html
Click on the image for a larger version.
-----
The *rotate* keyword allows specification of the orientation
at which molecules are inserted. The axis of rotation is
@ -291,10 +386,81 @@ the atoms around the rotation axis is consistent with the right-hand
rule: if your right-hand's thumb points along *R*, then your fingers
wrap around the axis in the direction of rotation.
The *radscale* keyword only applies to the *mesh* style and adjusts the
radius of created particles (see above), provided this is supported by
the atom style. Its value is a prefactor (must be > 0.0, default is
1.0) that is applied to the atom radius inferred from the size of the
individual triangles in the triangle mesh that the particle corresponds
to.
.. versionadded:: 2Jun2022
The *overlap* keyword only applies to the *random* style. It prevents
newly created particles from being created closer than the specified
*Doverlap* distance from any other particle. When the particles being
created are molecules, the radius of the molecule (from its geometric
center) is added to *Doverlap*. If particles have finite size (see
:doc:`atom_style sphere <atom_style>` for example) *Doverlap* should
be specified large enough to include the particle size in the
non-overlapping criterion.
.. note::
Checking for overlaps is a costly O(N(N+M)) operation for inserting
*N* new particles into a system with *M* existing particles. This
is because distances to all *M* existing particles are computed for
each new particle that is added. Thus the intended use of this
keyword is to add relatively small numbers of particles to systems
which remain at a relatively low density even after the new
particles are created. Careful use of the *maxtry* keyword in
combination with *overlap* is recommended. See the discussion
above about systems with overlapped particles for alternate
strategies that allow for overlapped insertions.
The *maxtry* keyword only applies to the *random* style. It limits
the number of attempts to generate valid coordinates for a single new
particle that satisfy all requirements imposed by the *region*, *var*,
and *overlap* keywords. The default is 10 attempts per particle
before the loop over the requested *N* particles advances to the next
particle. Note that if insertion success is unlikely (e.g. inserting
new particles into a dense system using the *overlap* keyword),
setting the *maxtry* keyword to a large value may result in this
command running for a long time.
.. figure:: img/overlap.png
:figwidth: 30%
:align: right
:target: _images/overlap.png
Here is an example for the *random* style using these commands
.. code-block:: LAMMPS
units lj
dimension 2
region box block 0 50 0 50 -0.5 0.5
create_box 1 box
create_atoms 1 random 2000 13487 NULL overlap 1.0 maxtry 50
pair_style lj/cut 2.5
pair_coeff 1 1 1.0 1.0 2.5
to produce a system as shown in the image with 1520 particles (out of
2000 requested) that are moderately dense and which have no overlaps
sufficient to prevent the LJ pair_style from running properly (because
the overlap criterion = 1.0). The create_atoms command ran for 0.3 s
on a single CPU core.
.. only:: html
(Click on the image for a larger version)
-----
The *units* keyword determines the meaning of the distance units used
to specify the coordinates of the one particle created by the *single*
style. A *box* value selects standard distance units as defined by
the :doc:`units <units>` command, e.g. Angstroms for units = real or
style, or the overlap distance *Doverlap* by the *overlap* keyword. A
*box* value selects standard distance units as defined by the
:doc:`units <units>` command, e.g. Angstroms for units = real or
metal. A *lattice* value means the distance units are in lattice
spacings.
@ -315,9 +481,10 @@ assigned to created molecules in a similar fashion.
Aside from their ID, atom type, and xyz position, other properties of
created atoms are set to default values, depending on which quantities
are defined by the chosen :doc:`atom style <atom_style>`. See the :doc:`atom style <atom_style>` command for more details. See the
:doc:`set <set>` and :doc:`velocity <velocity>` commands for info on how
to change these values.
are defined by the chosen :doc:`atom style <atom_style>`. See the
:doc:`atom style <atom_style>` command for more details. See the
:doc:`set <set>` and :doc:`velocity <velocity>` commands for info on
how to change these values.
* charge = 0.0
* dipole moment magnitude = 0.0
@ -336,9 +503,11 @@ values specified in the file read by the :doc:`molecule <molecule>`
command. E.g. the file typically defines bonds (angles,etc) between
atoms in the molecule, and can optionally define charges on each atom.
Note that the *sphere* atom style sets the default particle diameter
to 1.0 as well as the density. This means the mass for the particle
is not 1.0, but is PI/6 \* diameter\^3 = 0.5236.
Note that the *sphere* atom style sets the default particle diameter to
1.0 as well as the density. This means the mass for the particle is not
1.0, but is PI/6 \* diameter\^3 = 0.5236. When using the *mesh* style,
the particle diameter is adjusted from the size of the individual
triangles in the triangle mesh.
Note that the *ellipsoid* atom style sets the default particle shape
to (0.0 0.0 0.0) and the density to 1.0 which means it is a point
@ -372,5 +541,13 @@ Default
The default for the *basis* keyword is that all created atoms are
assigned the argument *type* as their atom type (when single atoms are
being created). The other defaults are *remap* = no, *rotate* =
random, and *units* = lattice.
being created). The other defaults are *remap* = no, *rotate* = random,
*radscale* = 1.0, *radthresh* = x-lattice spacing, *overlap* not
checked, *maxtry* = 10, and *units* = lattice.
----------
.. _Roberts2019:
**(Roberts)** R. Roberts (2019) "Evenly Distributing Points in a Triangle." Extreme Learning.
`<http://extremelearning.com.au/evenly-distributing-points-in-a-triangle/>`_

2
doc/src/create_bonds.rst
View File

@ -10,7 +10,7 @@ Syntax
create_bonds style args ... keyword value ...
* style = *many* or *single/bond* or *single/angle* or *single/dihedral*
* style = *many* or *single/bond* or *single/angle* or *single/dihedral* or *single/improper*
.. parsed-literal::

72
doc/src/delete_atoms.rst
View File

@ -10,7 +10,7 @@ Syntax
delete_atoms style args keyword value ...
* style = *group* or *region* or *overlap* or *porosity*
* style = *group* or *region* or *overlap* or *random* or *variable*
.. parsed-literal::
@ -20,12 +20,19 @@ Syntax
cutoff = delete one atom from pairs of atoms within the cutoff (distance units)
group1-ID = one atom in pair must be in this group
group2-ID = other atom in pair must be in this group
*porosity* args = group-ID region-ID fraction seed
*random* args = ranstyle value eflag group-ID region-ID seed
ranstyle = *fraction* or *count*
for *fraction*:
value = fraction (0.0 to 1.0) of eligible atoms to delete
eflag = *no* for fast approximate deletion, *yes* for exact deletion
for *count*:
value = number of atoms to delete
eflag = *no* for warning if count > eligible atoms, *yes* for error
group-ID = group within which to perform deletions
region-ID = region within which to perform deletions
or NULL to only impose the group criterion
fraction = delete this fraction of atoms
seed = random number seed (positive integer)
*variable* args = variable-name
* zero or more keyword/value pairs may be appended
* keyword = *compress* or *bond* or *mol*
@ -45,15 +52,17 @@ Examples
delete_atoms region sphere compress no
delete_atoms overlap 0.3 all all
delete_atoms overlap 0.5 solvent colloid
delete_atoms porosity all cube 0.1 482793 bond yes
delete_atoms porosity polymer cube 0.1 482793 bond yes
delete_atoms random fraction 0.1 yes all cube 482793 bond yes
delete_atoms random fraction 0.3 no polymer NULL 482793 bond yes
delete_atoms random count 500 no ions NULL 482793
delete_atoms variable checkers
Description
"""""""""""
Delete the specified atoms. This command can be used to carve out
voids from a block of material or to delete created atoms that are too
close to each other (e.g. at a grain boundary).
Delete the specified atoms. This command can be used, for example, to
carve out voids from a block of material or to delete created atoms
that are too close to each other (e.g. at a grain boundary).
For style *group*, all atoms belonging to the group are deleted.
@ -79,17 +88,44 @@ have occurred that no atom pairs within the cutoff will remain
minimum number of atoms will be deleted, or that the same atoms will
be deleted when running on different numbers of processors.
For style *porosity* a specified *fraction* of atoms are deleted which
are both in the specified group and within the specified region. The
region-ID can be specified as NULL to only impose the group criterion.
Likewise, specifying the group-ID as *all* will only impose the region
criterion.
For style *random* a subset of eligible atoms are deleted. Which
atoms to delete are chosen randomly using the specified random number
*seed*. Which atoms are deleted may vary when running on different
numbers of processors.
For example, if fraction is 0.1, then 10% of the eligible atoms will
be deleted. The atoms to delete are chosen randomly. There is no
guarantee that the exact fraction of atoms will be deleted, or that
the same atoms will be deleted when running on different numbers of
processors.
For *ranstyle* = *fraction*, the specified fractional *value* (0.0 to
1.0) of eligible atoms are deleted. If *eflag* is set to *no*, then
the number of deleted atoms will be approximate, but the operation
will be fast. If *eflag* is set to *yes*, then the number deleted
will match the requested fraction, but for large systems the selection
of deleted atoms may take additional time to determine.
For *ranstyle* = *count*, the specified integer *value* is the number
of eligible atoms are deleted. If *eflag* is set to *no*, then if the
requested number is larger then the number of eligible atoms, a
warning is issued and only the eligible atoms are deleted instead of
the requested *value*. If *eflag* is set to *yes*, an error is
triggered instead and LAMMPS will exit. For large systems the
selection of atoms to delete may take additional time to determine,
the same as for requesting an exact fraction with *pstyle* =
*fraction*.
Which atoms are eligible for deletion for style *random* is determined
by the specified *group-ID* and *region-ID*. To be eligible, an atom
must be in both the specified group and region. If *group-ID* = all,
there is effectively no group criterion. If *region-ID* is specified
as NULL, no region criterion is imposed.
For style *variable*, all atoms for which the atom-style variable with
the given name evaluates to non-zero will be deleted. Additional atoms
can be deleted if they are in a molecule for which one or more atoms
were deleted within the region; see the *mol* keyword discussion below.
This option allows complex selections of atoms not covered by the
other options listed above.
----------
Here is the meaning of the optional keywords.
If the *compress* keyword is set to *yes*, then after atoms are
deleted, then atom IDs are re-assigned so that they run from 1 to the

5
doc/src/dihedral_zero.rst
View File

@ -8,7 +8,10 @@ Syntax
.. code-block:: LAMMPS
dihedral_style zero [nocoeff]
dihedral_style zero keyword
* zero or more keywords may be appended
* keyword = *nocoeff*
Examples
""""""""

2
doc/src/displace_atoms.rst
View File

@ -36,7 +36,7 @@ Syntax
.. parsed-literal::
keyword = *units*
value = *box* or *lattice*
*units* value = *box* or *lattice*
Examples
""""""""

158
doc/src/dump.rst
View File

@ -1,4 +1,26 @@
.. index:: dump
.. index:: dump atom
.. index:: dump cfg
.. index:: dump custom
.. index:: dump dcd
.. index:: dump local
.. index:: dump xtc
.. index:: dump yaml
.. index:: dump xyz
.. index:: dump atom/gz
.. index:: dump cfg/gz
.. index:: dump custom/gz
.. index:: dump local/gz
.. index:: dump xyz/gz
.. index:: dump atom/mpiio
.. index:: dump cfg/mpiio
.. index:: dump custom/mpiio
.. index:: dump xyz/mpiio
.. index:: dump atom/zstd
.. index:: dump cfg/zstd
.. index:: dump custom/zstd
.. index:: dump xyz/zstd
.. index:: dump local/zstd
dump command
============
@ -27,6 +49,9 @@ dump command
:doc:`dump custom/adios <dump_adios>` command
=============================================
:doc:`dump cfg/uef <dump_cfg_uef>` command
==========================================
Syntax
""""""
@ -36,7 +61,7 @@ Syntax
* ID = user-assigned name for the dump
* group-ID = ID of the group of atoms to be dumped
* style = *atom* or *atom/gz* or *atom/zstd or *atom/mpiio* or *cfg* or *cfg/gz* or *cfg/zstd* or *cfg/mpiio* or *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *dcd* or *h5md* or *image* or *local* or *local/gz* or *local/zstd* or *molfile* or *movie* or *netcdf* or *netcdf/mpiio* or *vtk* or *xtc* or *xyz* or *xyz/gz* or *xyz/zstd* or *xyz/mpiio*
* style = *atom* or *atom/gz* or *atom/zstd* or *atom/mpiio* or *cfg* or *cfg/gz* or *cfg/zstd* or *cfg/mpiio* or *cfg/uef* or *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *dcd* or *h5md* or *image* or *local* or *local/gz* or *local/zstd* or *molfile* or *movie* or *netcdf* or *netcdf/mpiio* or *vtk* or *xtc* or *xyz* or *xyz/gz* or *xyz/zstd* or *xyz/mpiio* or *yaml*
* N = dump every this many timesteps
* file = name of file to write dump info to
* args = list of arguments for a particular style
@ -47,29 +72,31 @@ Syntax
*atom/gz* args = none
*atom/zstd* args = none
*atom/mpiio* args = none
*atom/adios* args = none, discussed on :doc:`dump atom/adios <dump_adios>` doc page
*atom/adios* args = none, discussed on :doc:`dump atom/adios <dump_adios>` page
*cfg* args = same as *custom* args, see below
*cfg/gz* args = same as *custom* args, see below
*cfg/zstd* args = same as *custom* args, see below
*cfg/mpiio* args = same as *custom* args, see below
*cfg/uef* args = same as *custom* args, discussed on :doc:`dump cfg/uef <dump_cfg_uef>` page
*custom*, *custom/gz*, *custom/zstd*, *custom/mpiio* args = see below
*custom/adios* args = same as *custom* args, discussed on :doc:`dump custom/adios <dump_adios>` doc page
*custom/adios* args = same as *custom* args, discussed on :doc:`dump custom/adios <dump_adios>` page
*dcd* args = none
*h5md* args = discussed on :doc:`dump h5md <dump_h5md>` doc page
*image* args = discussed on :doc:`dump image <dump_image>` doc page
*h5md* args = discussed on :doc:`dump h5md <dump_h5md>` page
*image* args = discussed on :doc:`dump image <dump_image>` page
*local*, *local/gz*, *local/zstd* args = see below
*molfile* args = discussed on :doc:`dump molfile <dump_molfile>` doc page
*movie* args = discussed on :doc:`dump image <dump_image>` doc page
*netcdf* args = discussed on :doc:`dump netcdf <dump_netcdf>` doc page
*netcdf/mpiio* args = discussed on :doc:`dump netcdf <dump_netcdf>` doc page
*vtk* args = same as *custom* args, see below, also :doc:`dump vtk <dump_vtk>` doc page
*molfile* args = discussed on :doc:`dump molfile <dump_molfile>` page
*movie* args = discussed on :doc:`dump image <dump_image>` page
*netcdf* args = discussed on :doc:`dump netcdf <dump_netcdf>` page
*netcdf/mpiio* args = discussed on :doc:`dump netcdf <dump_netcdf>` page
*vtk* args = same as *custom* args, see below, also :doc:`dump vtk <dump_vtk>` page
*xtc* args = none
*xyz* args = none
*xyz/gz* args = none
*xyz/zstd* args = none
*xyz/mpiio* args = none
*yaml* args = same as *custom* args, see below
* *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *netcdf* or *netcdf/mpiio* args = list of atom attributes
* *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *cfg* or *cfg/gz* or *cfg/zstd* or *cfg/mpiio* or *cfg/uef* or *netcdf* or *netcdf/mpiio* or *yaml* args = list of atom attributes
.. parsed-literal::
@ -132,13 +159,14 @@ Examples
.. code-block:: LAMMPS
dump myDump all atom 100 dump.atom
dump myDump all atom 100 dump.lammpstrj
dump myDump all atom/mpiio 100 dump.atom.mpiio
dump myDump all atom/gz 100 dump.atom.gz
dump myDump all atom/zstd 100 dump.atom.zst
dump 2 subgroup atom 50 dump.run.bin
dump 2 subgroup atom/mpiio 50 dump.run.mpiio.bin
dump 4a all custom 100 dump.myforce.* id type x y vx fx
dump 4a all custom 100 dump.myvel.lammpsbin id type x y z vx vy vz
dump 4b flow custom 100 dump.%.myforce id type c_myF[3] v_ke
dump 4b flow custom 100 dump.%.myforce id type c_myF[*] v_ke
dump 2 inner cfg 10 dump.snap.*.cfg mass type xs ys zs vx vy vz
@ -153,7 +181,7 @@ timesteps in one of several styles. The *image* and *movie* styles are
the exception: the *image* style renders a JPG, PNG, or PPM image file
of the atom configuration every N timesteps while the *movie* style
combines and compresses them into a movie file; both are discussed in
detail on the :doc:`dump image <dump_image>` doc page. The timesteps on
detail on the :doc:`dump image <dump_image>` page. The timesteps on
which dump output is written can also be controlled by a variable.
See the :doc:`dump_modify every <dump_modify>` command.
@ -192,7 +220,7 @@ or multiple smaller files).
For the *atom*, *custom*, *cfg*, and *local* styles, sorting is off by
default. For the *dcd*, *xtc*, *xyz*, and *molfile* styles, sorting
by atom ID is on by default. See the :doc:`dump_modify <dump_modify>`
doc page for details.
page for details.
The *atom/gz*, *cfg/gz*, *custom/gz*, *local/gz*, and *xyz/gz* styles
are identical in command syntax to the corresponding styles without
@ -202,7 +230,7 @@ alternative approach to writing compressed files via a pipe, as done
by the regular dump styles, which may be required on clusters where
the interface to the high-speed network disallows using the fork()
library call (which is needed for a pipe). For the remainder of this
doc page, you should thus consider the *atom* and *atom/gz* styles
page, you should thus consider the *atom* and *atom/gz* styles
(etc) to be inter-changeable, with the exception of the required
filename suffix.
@ -216,7 +244,7 @@ As explained below, the *atom/mpiio*, *cfg/mpiio*, *custom/mpiio*, and
*xyz/mpiio* styles are identical in command syntax and in the format
of the dump files they create, to the corresponding styles without
"mpiio", except the single dump file they produce is written in
parallel via the MPI-IO library. For the remainder of this doc page,
parallel via the MPI-IO library. For the remainder of this page,
you should thus consider the *atom* and *atom/mpiio* styles (etc) to
be inter-changeable. The one exception is how the filename is
specified for the MPI-IO styles, as explained below.
@ -386,6 +414,73 @@ from using the (numerical) atom type to an element name (or some
other label). This will help many visualization programs to guess
bonds and colors.
.. versionadded:: 4May2022
Dump style *yaml* has the same command syntax as style *custom* and
writes YAML format files that can be easily parsed by a variety of data
processing tools and programming languages. Each timestep will be
written as a YAML "document" (i.e. starts with "---" and ends with
"..."). The style supports writing one file per timestep through the
"\*" wildcard but not multi-processor outputs with the "%" token in the
filename. In addition to per-atom data, :doc:`thermo <thermo>` data can
be included in the *yaml* style dump file using the :doc:`dump_modify
thermo yes <dump_modify>`. The data included in the dump file uses the
"thermo" tag and is otherwise identical to data specified by the
:doc:`thermo_style <thermo_style>` command.
Below is an example for a YAML format dump created by the following commands.
.. code-block:: LAMMPS
dump out all yaml 100 dump.yaml id type x y z vx vy vz ix iy iz
dump_modify out time yes units yes thermo yes format 1 %5d format "% 10.6e"
The tags "time", "units", and "thermo" are optional and enabled by the
dump_modify command. The list under the "box" tag has 3 lines for
orthogonal boxes and 4 lines with triclinic boxes, where the first 3 are
the box boundaries and the 4th the three tilt factors (xy, xz, yz). The
"thermo" data follows the format of the *yaml* thermo style. The
"keywords" tag lists the per-atom properties contained in the "data"
columns, which contain a list with one line per atom. The keywords may
be renamed using the dump_modify command same as for the *custom* dump
style.
.. code-block:: yaml
---
creator: LAMMPS
timestep: 0
units: lj
time: 0
natoms: 4000
boundary: [ p, p, p, p, p, p, ]
thermo:
- keywords: [ Step, Temp, E_pair, E_mol, TotEng, Press, ]
- data: [ 0, 0, -27093.472213010766, 0, 0, 0, ]
box:
- [ 0, 16.795961913825074 ]
- [ 0, 16.795961913825074 ]
- [ 0, 16.795961913825074 ]
- [ 0, 0, 0 ]
keywords: [ id, type, x, y, z, vx, vy, vz, ix, iy, iz, ]
data:
- [ 1 , 1 , 0.000000e+00 , 0.000000e+00 , 0.000000e+00 , -1.841579e-01 , -9.710036e-01 , -2.934617e+00 , 0 , 0 , 0, ]
- [ 2 , 1 , 8.397981e-01 , 8.397981e-01 , 0.000000e+00 , -1.799591e+00 , 2.127197e+00 , 2.298572e+00 , 0 , 0 , 0, ]
- [ 3 , 1 , 8.397981e-01 , 0.000000e+00 , 8.397981e-01 , -1.807682e+00 , -9.585130e-01 , 1.605884e+00 , 0 , 0 , 0, ]
[...]
...
---
timestep: 100
units: lj
time: 0.5
[...]
...
----------
Note that *atom*, *custom*, *dcd*, *xtc*, and *xyz* style dump files
can be read directly by `VMD <http://www.ks.uiuc.edu/Research/vmd>`_, a
popular molecular viewing program.
@ -427,9 +522,9 @@ If a "%" character appears in the filename, then each of P processors
writes a portion of the dump file, and the "%" character is replaced
with the processor ID from 0 to P-1. For example, tmp.dump.% becomes
tmp.dump.0, tmp.dump.1, ... tmp.dump.P-1, etc. This creates smaller
files and can be a fast mode of output on parallel machines that
support parallel I/O for output. This option is not available for the
*dcd*, *xtc*, and *xyz* styles.
files and can be a fast mode of output on parallel machines that support
parallel I/O for output. This option is **not** available for the *dcd*,
*xtc*, *xyz*, and *yaml* styles.
By default, P = the number of processors meaning one file per
processor, but P can be set to a smaller value via the *nfile* or
@ -469,11 +564,11 @@ MPI-IO.
Note that MPI-IO dump files are one large file which all processors
write to. You thus cannot use the "%" wildcard character described
above in the filename since that specifies generation of multiple
files. You can use the ".bin" suffix described below in an MPI-IO
files. You can use the ".bin" or ".lammpsbin" suffix described below in an MPI-IO
dump file; again this file will be written in parallel and have the
same binary format as if it were written without MPI-IO.
If the filename ends with ".bin", the dump file (or files, if "\*" or
If the filename ends with ".bin" or ".lammpsbin", the dump file (or files, if "\*" or
"%" is also used) is written in binary format. A binary dump file
will be about the same size as a text version, but will typically
write out much faster. Of course, when post-processing, you will need
@ -597,7 +692,7 @@ so that each value is 0.0 to 1.0. If the simulation box is triclinic
(tilted), then all atom coords will still be between 0.0 and 1.0.
I.e. actual unscaled (x,y,z) = xs\*A + ys\*B + zs\*C, where (A,B,C) are
the non-orthogonal vectors of the simulation box edges, as discussed
on the :doc:`Howto triclinic <Howto_triclinic>` doc page.
on the :doc:`Howto triclinic <Howto_triclinic>` page.
Use *xu*, *yu*, *zu* if you want the coordinates "unwrapped" by the
image flags for each atom. Unwrapped means that if the atom has
@ -712,6 +807,11 @@ To write gzipped dump files, you must either compile LAMMPS with the
-DLAMMPS_GZIP option or use the styles from the COMPRESS package.
See the :doc:`Build settings <Build_settings>` page for details.
While a dump command is active (i.e. has not been stopped by using
the undump command), no commands may be used that will change the
timestep (e.g. :doc:`reset_timestep <reset_timestep>`). LAMMPS
will terminate with an error otherwise.
The *atom/gz*, *cfg/gz*, *custom/gz*, and *xyz/gz* styles are part of
the COMPRESS package. They are only enabled if LAMMPS was built with
that package. See the :doc:`Build package <Build_package>` page for
@ -720,22 +820,22 @@ more info.
The *atom/mpiio*, *cfg/mpiio*, *custom/mpiio*, and *xyz/mpiio* styles
are part of the MPIIO package. They are only enabled if LAMMPS was
built with that package. See the :doc:`Build package <Build_package>`
doc page for more info.
page for more info.
The *xtc* and *dcd* styles are part of the EXTRA-DUMP package. They
are only enabled if LAMMPS was built with that package. See the
The *xtc*, *dcd* and *yaml* styles are part of the EXTRA-DUMP package.
They are only enabled if LAMMPS was built with that package. See the
:doc:`Build package <Build_package>` page for more info.
Related commands
""""""""""""""""
:doc:`dump atom/adios <dump_adios>`, :doc:`dump custom/adios <dump_adios>`,
:doc:`dump h5md <dump_h5md>`, :doc:`dump image <dump_image>`,
:doc:`dump molfile <dump_molfile>`, :doc:`dump_modify <dump_modify>`,
:doc:`undump <undump>`
:doc:`dump cfg/uef <dump_cfg_uef>`, :doc:`dump h5md <dump_h5md>`,
:doc:`dump image <dump_image>`, :doc:`dump molfile <dump_molfile>`,
:doc:`dump_modify <dump_modify>`, :doc:`undump <undump>`, :doc:`write_dump <write_dump>`
Default
"""""""
The defaults for the *image* and *movie* styles are listed on the
:doc:`dump image <dump_image>` doc page.
:doc:`dump image <dump_image>` page.

14
doc/src/dump_adios.rst
View File

@ -35,13 +35,21 @@ Examples
Description
"""""""""""
Dump a snapshot of atom coordinates every N timesteps in the
`ADIOS <adios_>`_ based "BP" file format, or using different I/O solutions in ADIOS,
to a stream that can be read on-line by another program.
Dump a snapshot of atom coordinates every N timesteps in the `ADIOS
<adios_>`_ based "BP" file format, or using different I/O solutions in
ADIOS, to a stream that can be read on-line by another program.
ADIOS-BP files are binary, portable and self-describing.
.. _adios: https://github.com/ornladios/ADIOS2
.. note::
To be able to use ADIOS, a file ``adios2_config.xml`` with specific
configuration settings is expected in the current working directory.
If the file is not present, LAMMPS will try to create a minimal
default file. Please refer to the ADIOS documentation for details on
how to adjust this file for optimal performance and desired features.
**Use from write_dump:**
It is possible to use these dump styles with the

32
doc/src/dump_h5md.rst
View File

@ -6,31 +6,31 @@ dump h5md command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
dump ID group-ID h5md N file.h5 args
* ID = user-assigned name for the dump
* group-ID = ID of the group of atoms to be imaged
* h5md = style of dump command (other styles *atom* or *cfg* or *dcd* or *xtc* or *xyz* or *local* or *custom* are discussed on the :doc:`dump <dump>` doc page)
* *h5md* = style of dump command (other styles *atom* or *cfg* or *dcd* or *xtc* or *xyz* or *local* or *custom* are discussed on the :doc:`dump <dump>` doc page)
* N = dump every this many timesteps
* file.h5 = name of file to write to
* args = *position* options or *image* or *velocity* options or *force* options or *species* options or *file_from* ID or *box* value or *create_group* value or *author* value = list of data elements to dump, with their dump "sub-intervals"
.. parsed-literal::
.. parsed-literal::
args = list of data elements to dump, with their dump "sub-intervals"
position options
image
velocity options
force options
species options
file_from ID: do not open a new file, re-use the already opened file from dump ID
box value = *yes* or *no*
create_group value = *yes* or *no*
author value = quoted string
*position* options
*image*
*velocity* options
*force* options
*species* options
*file_from* ID = do not open a new file, re-use the already opened file from dump ID
*box* value = *yes* or *no*
*create_group* value = *yes* or *no*
*author* value = quoted string
Note that at least one element must be specified and image may only be
present if position is specified first.
Note that at least one element must be specified and that *image* may only be
present if *position* is specified first.
For the elements *position*, *velocity*, *force* and *species*, a
sub-interval may be specified to write the data only every N_element
@ -39,7 +39,7 @@ specified by this option directly following the element declaration:
.. parsed-literal::
every N_element
options = *every* N_element
Examples
""""""""

19
doc/src/dump_image.rst
View File

@ -1,4 +1,5 @@
.. index:: dump image
.. index:: dump movie
dump image command
==================
@ -44,7 +45,7 @@ Syntax
color = *type*
bflag1,bflag2 = 2 numeric flags to affect how bodies are drawn
*fix* = fixID color fflag1 fflag2
fixID = ID of fix that generates objects to dray
fixID = ID of fix that generates objects to draw
color = *type*
fflag1,fflag2 = 2 numeric flags to affect how fix objects are drawn
*size* values = width height = size of images
@ -55,7 +56,7 @@ Syntax
phi = azimuthal view angle (degrees)
theta or phi can be a variable (see below)
*center* values = flag Cx Cy Cz = center point of image
flag = "s" for static, "d" for dynamic
flag = *s* for static, *d* for dynamic
Cx,Cy,Cz = center point of image as fraction of box dimension (0.5 = center of box)
Cx,Cy,Cz can be variables (see below)
*up* values = Ux Uy Uz = direction that is "up" in image
@ -109,13 +110,13 @@ Syntax
*amap* args = lo hi style delta N entry1 entry2 ... entryN
lo = number or *min* = lower bound of range of color map
hi = number or *max* = upper bound of range of color map
style = 2 letters = "c" or "d" or "s" plus "a" or "f"
"c" for continuous
"d" for discrete
"s" for sequential
"a" for absolute
"f" for fractional
delta = binsize (only used for style "s", otherwise ignored)
style = 2 letters = *c* or *d* or *s* plus *a* or *f*
*c* for continuous
*d* for discrete
*s* for sequential
*a* for absolute
*f* for fractional
delta = binsize (only used for style *s*, otherwise ignored)
binsize = range is divided into bins of this width
N = # of subsequent entries
entry = value color (for continuous style)

42
doc/src/dump_modify.rst
View File

@ -26,6 +26,10 @@ Syntax
N = index of frame written upon first dump
*balance* arg = *yes* or *no*
*buffer* arg = *yes* or *no*
*colname* values = ID string, or *default*
string = new column header name
ID = integer from 1 to N, or integer from -1 to -N, where N = # of quantities being output
*or* a custom dump keyword or reference to compute, fix, property or variable.
*delay* arg = Dstep
Dstep = delay output until this timestep
*element* args = E1 E2 ... EN, where N = # of atom types
@ -40,9 +44,10 @@ Syntax
Np = write one file for every this many processors
*first* arg = *yes* or *no*
*flush* arg = *yes* or *no*
*format* args = *line* string, *int* string, *float* string, M string, or *none*
*format* args = *line* string, *int* string, *float* string, ID string, or *none*
string = C-style format string
M = integer from 1 to N, where N = # of per-atom quantities being output
ID = integer from 1 to N, or integer from -1 to -N, where N = # of quantities being output
*or* a custom dump keyword or reference to compute, fix, property or variable.
*header* arg = *yes* or *no*
*yes* to write the header
*no* to not write the header
@ -375,6 +380,30 @@ performed with dump style *xtc*\ .
----------
.. versionadded:: 4May2022
The *colname* keyword can be used to change the default header keyword
for dump styles: *atom*, *custom*, and *cfg* and their compressed, ADIOS,
and MPIIO variants. The setting for *ID string* replaces the default
text with the provided string. *ID* can be a positive integer when it
represents the column number counting from the left, a negative integer
when it represents the column number from the right (i.e. -1 is the last
column/keyword), or a custom dump keyword (or compute, fix, property, or
variable reference) and then it replaces the string for that specific
keyword. For *atom* dump styles only the keywords "id", "type", "x",
"y", "z", "ix", "iy", "iz" can be accessed via string regardless of
whether scaled or unwrapped coordinates were enabled or disabled, and
it always assumes 8 columns for indexing regardless of whether image
flags are enabled or not. For dump style *cfg* only changes to the
"auxiliary" keywords (6th or later keyword) will become visible.
The *colname* keyword can be used multiple times. If multiple *colname*
settings refer to the same keyword, the last setting has precedence. A
setting of *default* clears all previous settings, reverting all values
to their default names.
----------
The *format* keyword can be used to change the default numeric format output
by the text-based dump styles: *atom*, *local*, *custom*, *cfg*, and
*xyz* styles, and their MPIIO variants. Only the *line* or *none*
@ -446,8 +475,9 @@ The *fileper* keyword is documented below with the *nfile* keyword.
The *header* keyword toggles whether the dump file will include a
header. Excluding a header will reduce the size of the dump file for
fixes such as :doc:`fix pair/tracker <fix_pair_tracker>` which do not
require the information typically written to the header.
data produced by :doc:`pair tracker <pair_tracker>` or
:doc:`bpm bond styles <Howto_bpm>` which may not require the
information typically written to the header.
----------
@ -684,8 +714,8 @@ run, this option is ignored since the output is already balanced.
----------
The *thermo* keyword only applies the dump *netcdf* style. It
triggers writing of :doc:`thermo <thermo>` information to the dump file
The *thermo* keyword only applies the dump styles *netcdf* and *yaml*.
It triggers writing of :doc:`thermo <thermo>` information to the dump file
alongside per-atom data. The values included in the dump file are
identical to the values specified by :doc:`thermo_style <thermo_style>`.

1
doc/src/dump_netcdf.rst
View File

@ -1,4 +1,5 @@
.. index:: dump netcdf
.. index:: dump netcdf/mpiio
dump netcdf command
===================

8
doc/src/dumps.rst Normal file
View File

@ -0,0 +1,8 @@
Dump Styles
###############
.. toctree::
:maxdepth: 1
:glob:
dump*

14
doc/src/fix.rst
View File

@ -171,6 +171,8 @@ accelerated styles exist.
* :doc:`adapt/fep <fix_adapt_fep>` - enhanced version of fix adapt
* :doc:`addforce <fix_addforce>` - add a force to each atom
* :doc:`addtorque <fix_addtorque>` - add a torque to a group of atoms
* :doc:`amoeba/bitorsion <fix_amoeba_bitorsion>` - torsion/torsion terms in AMOEBA force field
* :doc:`amoeba/pitorsion <fix_amoeba_pitorsion>` - 6-body terms in AMOEBA force field
* :doc:`append/atoms <fix_append_atoms>` - append atoms to a running simulation
* :doc:`atc <fix_atc>` - initiates a coupled MD/FE simulation
* :doc:`atom/swap <fix_atom_swap>` - Monte Carlo atom type swapping
@ -194,10 +196,10 @@ accelerated styles exist.
* :doc:`bond/swap <fix_bond_swap>` - Monte Carlo bond swapping
* :doc:`box/relax <fix_box_relax>` - relax box size during energy minimization
* :doc:`charge/regulation <fix_charge_regulation>` - Monte Carlo sampling of charge regulation
* :doc:`client/md <fix_client_md>` - MD client for client/server simulations
* :doc:`cmap <fix_cmap>` - enables CMAP cross-terms of the CHARMM force field
* :doc:`cmap <fix_cmap>` - CMAP torsion/torsion terms in CHARMM force field
* :doc:`colvars <fix_colvars>` - interface to the collective variables "Colvars" library
* :doc:`controller <fix_controller>` - apply control loop feedback mechanism
* :doc:`damping/cundall <fix_damping_cundall>` - Cundall non-viscous damping for granular simulations
* :doc:`deform <fix_deform>` - change the simulation box size/shape
* :doc:`deposit <fix_deposit>` - add new atoms above a surface
* :doc:`dpd/energy <fix_dpd_energy>` - constant energy dissipative particle dynamics
@ -209,6 +211,9 @@ accelerated styles exist.
* :doc:`edpd/source <fix_dpd_source>` - add heat source to eDPD simulations
* :doc:`efield <fix_efield>` - impose electric field on system
* :doc:`ehex <fix_ehex>` - enhanced heat exchange algorithm
* :doc:`electrode/conp <fix_electrode_conp>` - impose electric potential
* :doc:`electrode/conq <fix_electrode_conp>` - impose total electric charge
* :doc:`electrode/thermo <fix_electrode_conp>` - apply thermo-potentiostat
* :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
@ -243,7 +248,7 @@ accelerated styles exist.
* :doc:`lb/viscous <fix_lb_viscous>` -
* :doc:`lineforce <fix_lineforce>` - constrain atoms to move in a line
* :doc:`manifoldforce <fix_manifoldforce>` - restrain atoms to a manifold during minimization
* :doc:`mdi/engine <fix_mdi_engine>` - connect LAMMPS to external programs via the MolSSI Driver Interface (MDI)
* :doc:`mdi/qm <fix_mdi_qm>` - LAMMPS operates as driver for a quantum code via the MolSSI Driver Interface (MDI)
* :doc:`meso/move <fix_meso_move>` - move mesoscopic SPH/SDPD particles in a prescribed fashion
* :doc:`mol/swap <fix_mol_swap>` - Monte Carlo atom type swapping with a molecule
* :doc:`momentum <fix_momentum>` - zero the linear and/or angular momentum of a group of atoms
@ -284,6 +289,7 @@ accelerated styles exist.
* :doc:`nve/manifold/rattle <fix_nve_manifold_rattle>` -
* :doc:`nve/noforce <fix_nve_noforce>` - NVE without forces (v only)
* :doc:`nve/sphere <fix_nve_sphere>` - NVE for spherical particles
* :doc:`nve/bpm/sphere <fix_nve_bpm_sphere>` - NVE for spherical particles used in the BPM package
* :doc:`nve/spin <fix_nve_spin>` - NVE for a spin or spin-lattice system
* :doc:`nve/tri <fix_nve_tri>` - NVE for triangles
* :doc:`nvk <fix_nvk>` - constant kinetic energy time integration
@ -301,7 +307,6 @@ accelerated styles exist.
* :doc:`orient/fcc <fix_orient>` - add grain boundary migration force for FCC
* :doc:`orient/eco <fix_orient_eco>` - add generalized grain boundary migration force
* :doc:`pafi <fix_pafi>` - constrained force averages on hyper-planes to compute free energies (PAFI)
* :doc:`pair/tracker <fix_pair_tracker>` - track properties of pairwise interactions
* :doc:`phonon <fix_phonon>` - calculate dynamical matrix from MD simulations
* :doc:`pimd <fix_pimd>` - Feynman path integral molecular dynamics
* :doc:`planeforce <fix_planeforce>` - constrain atoms to move in a plane
@ -386,6 +391,7 @@ accelerated styles exist.
* :doc:`vector <fix_vector>` - accumulate a global vector every N timesteps
* :doc:`viscosity <fix_viscosity>` - Muller-Plathe momentum exchange for viscosity calculation
* :doc:`viscous <fix_viscous>` - viscous damping for granular simulations
* :doc:`viscous/sphere <fix_viscous_sphere>` - viscous damping on angular velocity for granular simulations
* :doc:`wall/body/polygon <fix_wall_body_polygon>` -
* :doc:`wall/body/polyhedron <fix_wall_body_polyhedron>` -
* :doc:`wall/colloid <fix_wall>` - Lennard-Jones wall interacting with finite-size particles

2
doc/src/fix_accelerate_cos.rst
View File

@ -13,7 +13,7 @@ Syntax
* ID, group-ID are documented in :doc:`fix <fix>` command
* accelerate/cos = style name of this fix command
* value = amplitude of acceleration (in unit of force/mass)
* value = amplitude of acceleration (in unit of velocity/time)
Examples

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