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

Merge branch 'develop' into stress_deform

Browse Source
This commit is contained in:
jtclemm
2023-12-14 10:02:46 -07:00
committed by GitHub
parent 5ff16da272 00c3f14a63
commit b94b9a311d
8699 changed files with 719549 additions and 470721 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/src/2001/basics.html
View File

@ -63,7 +63,7 @@ In the src directory, there is one top-level Makefile and several
low-level machine-specific files named Makefile.xxx where xxx = the
machine name. If a low-level Makefile exists for your platform, you do
not need to edit the top-level Makefile. However you should check the
system-specific section of the low-level Makefile to insure the
system-specific section of the low-level Makefile to ensure the
various paths are correct for your environment. If a low-level
Makefile does not exist for your platform, you will need to add a
suitable target to the top-level Makefile. You will also need to

2
doc/src/2001/input_commands.html
View File

@ -1206,7 +1206,7 @@ this command is not typically needed if the "nonbond style" and "
an exception to this is if a short cutoff is used initially,
but a longer cutoff will be used for a subsequent run (in the same
input script), in this case the "maximum cutoff" command should be
used to insure enough memory is allocated for the later run
used to ensure enough memory is allocated for the later run
note that a restart file contains nonbond cutoffs (so it is not necessary
to use a "nonbond style" command before "read restart"), but LAMMPS
still needs to know what the maximum cutoff will be before the

29
doc/src/Bibliography.rst
View File

@ -203,7 +203,7 @@ Bibliography
A Caro, DA Crowson, M Caro; Phys Rev Lett, 95, 075702 (2005)
**(CasP)**
CasP webpage: https://www.helmholtz-berlin.de/people/gregor-schiwietz/casp_en.html
CasP webpage: http://www.casp-program.org/
**(Cawkwell2012)**
A.\ M. N. Niklasson, M. J. Cawkwell, Phys. Rev. B, 86 (17), 174308 (2012).
@ -314,7 +314,7 @@ Bibliography
Espanol, Revenga, Physical Review E, 67, 026705 (2003).
**(Espanol1997)**
Espanol, Europhys Lett, 40(6): 631-636 (1997). DOI: 10.1209/epl/i1997-00515-8
Espanol, Europhys Lett, 40(6): 631-636 (1997). DOI:10.1209/epl/i1997-00515-8
**(Evans and Morriss)**
Evans and Morriss, Phys Rev A, 30, 1528 (1984).
@ -368,7 +368,7 @@ Bibliography
Frenkel and Smit, Understanding Molecular Simulation, Academic Press, London, 2002.
**(GLE4MD)**
`http://gle4md.org/ <http://gle4md.org/>`_
`https://gle4md.org/ <https://gle4md.org/>`_
**(Gao)**
Gao and Weber, Nuclear Instruments and Methods in Physics Research B 191 (2012) 504.
@ -401,13 +401,13 @@ Bibliography
Hayre, and Farago, Comp Phys Comm, 185, 524 (2014)
**(Groot)**
Groot and Warren, J Chem Phys, 107: 4423-4435 (1997). DOI: 10.1063/1.474784
Groot and Warren, J Chem Phys, 107: 4423-4435 (1997). DOI:10.1063/1.474784
**(Guenole)**
Guenole, Noehring, Vaid, Houlle, Xie, Prakash, Bitzek, Comput Mater Sci, 175, 109584 (2020).
**(Gullet)**
Gullet, Wagner, Slepoy, SANDIA Report 2003-8782 (2003).
Gullet, Wagner, Slepoy, SANDIA Report 2003-8782 (2003). DOI:10.2172/918395
**(Guo)**
Guo and Thirumalai, Journal of Molecular Biology, 263, 323-43 (1996).
@ -461,7 +461,7 @@ Bibliography
Hunt, Mol Simul, 42, 347 (2016).
**(IPI)**
`http://epfl-cosmo.github.io/gle4md/index.html?page=ipi <http://epfl-cosmo.github.io/gle4md/index.html?page=ipi>`_
`https://ipi-code.org/ <https://ipi-code.org/>`
**(IPI-CPC)**
Ceriotti, More and Manolopoulos, Comp Phys Comm, 185, 1019-1026 (2014).
@ -562,6 +562,9 @@ Bibliography
**(Kumar)**
Kumar and Skinner, J. Phys. Chem. B, 112, 8311 (2008)
**(Lafourcade)**
Lafourcade, Maillet, Denoual, Duval, Allera, Goryaeva, and Marinica, `Comp. Mat. Science, 230, 112534 (2023) <https://doi.org/10.1016/j.commatsci.2023.112534>`_
**(Lamoureux and Roux)**
G.\ Lamoureux, B. Roux, J. Chem. Phys 119, 3025 (2003)
@ -605,16 +608,16 @@ Bibliography
I.\ Leven et al, J. Chem.Theory Comput. 12, 2896-905 (2016).
**(Li2013_POF)**
Li, Hu, Wang, Ma, Zhou, Phys Fluids, 25: 072103 (2013). DOI: 10.1063/1.4812366.
Li, Hu, Wang, Ma, Zhou, Phys Fluids, 25: 072103 (2013). DOI:10.1063/1.4812366.
**(Li2014_JCP)**
Li, Tang, Lei, Caswell, Karniadakis, J Comput Phys, 265: 113-127 (2014). DOI: 10.1016/j.jcp.2014.02.003.
Li, Tang, Lei, Caswell, Karniadakis, J Comput Phys, 265: 113-127 (2014). DOI:10.1016/j.jcp.2014.02.003.
**(Li2015_CC)**
Li, Tang, Li, Karniadakis, Chem Commun, 51: 11038-11040 (2015). DOI: 10.1039/C5CC01684C.
Li, Tang, Li, Karniadakis, Chem Commun, 51: 11038-11040 (2015). DOI:10.1039/C5CC01684C.
**(Li2015_JCP)**
Li, Yazdani, Tartakovsky, Karniadakis, J Chem Phys, 143: 014101 (2015). DOI: 10.1063/1.4923254.
Li, Yazdani, Tartakovsky, Karniadakis, J Chem Phys, 143: 014101 (2015). DOI:10.1063/1.4923254.
**(Lisal)**
M.\ Lisal, J.K. Brennan, J. Bonet Avalos, "Dissipative particle dynamics at isothermal, isobaric, isoenergetic, and isoenthalpic conditions using Shardlow-like splitting algorithms.",
@ -733,8 +736,8 @@ Bibliography
**(Mishin)**
Mishin, Mehl, and Papaconstantopoulos, Acta Mater, 53, 4029 (2005).
**(Mitchell and Finchham)**
Mitchell, Finchham, J Phys Condensed Matter, 5, 1031-1038 (1993).
**(Mitchell and Fincham)**
Mitchell, Fincham, J Phys Condensed Matter, 5, 1031-1038 (1993).
**(Mitchell2011)**
Mitchell. A non-local, ordinary-state-based viscoelasticity model for peridynamics. Sandia National Lab Report, 8064:1-28 (2011).
@ -875,7 +878,7 @@ Bibliography
G.A. Tribello, M. Bonomi, D. Branduardi, C. Camilloni and G. Bussi, Comp. Phys. Comm 185, 604 (2014)
**(Paquay)**
Paquay and Kusters, Biophys. J., 110, 6, (2016). preprint available at `arXiv:1411.3019 <http://arxiv.org/abs/1411.3019/>`_.
Paquay and Kusters, Biophys. J., 110, 6, (2016). preprint available at `arXiv:1411.3019 <https://arxiv.org/abs/1411.3019/>`_.
**(Park)**
Park, Schulten, J. Chem. Phys. 120 (13), 5946 (2004)

6
doc/src/Build.rst
View File

@ -6,9 +6,9 @@ either traditional makefiles for use with GNU make (which may require
manual editing), or using a build environment generated by CMake (Unix
Makefiles, Ninja, Xcode, Visual Studio, KDevelop, CodeBlocks and more).
As an alternative you can download a package with pre-built executables
or automated build trees as described on the :doc:`Install <Install>`
page.
As an alternative, you can download a package with pre-built executables
or automated build trees, as described in the :doc:`Install <Install>`
section of the manual.
.. toctree::
:maxdepth: 1

95
doc/src/Build_basics.rst
View File

@ -44,7 +44,7 @@ standard. A more detailed discussion of that is below.
The executable created by CMake (after running make) is named
``lmp`` unless the ``LAMMPS_MACHINE`` option is set. When setting
``LAMMPS_MACHINE=name`` the executable will be called
``LAMMPS_MACHINE=name``, the executable will be called
``lmp_name``. Using ``BUILD_MPI=no`` will enforce building a
serial executable using the MPI STUBS library.
@ -60,7 +60,7 @@ standard. A more detailed discussion of that is below.
Any ``make machine`` command will look up the make settings from a
file ``Makefile.machine`` in the folder ``src/MAKE`` or one of its
sub-directories ``MINE``, ``MACHINES``, or ``OPTIONS``, create a
subdirectories ``MINE``, ``MACHINES``, or ``OPTIONS``, create a
folder ``Obj_machine`` with all objects and generated files and an
executable called ``lmp_machine``\ . The standard parallel build
with ``make mpi`` assumes a standard MPI installation with MPI
@ -90,7 +90,7 @@ standard. A more detailed discussion of that is below.
directory, or ``make`` from the ``src/STUBS`` dir. If the build
fails, you may need to edit the ``STUBS/Makefile`` for your
platform. The stubs library does not provide MPI/IO functions
required by some LAMMPS packages, e.g. ``MPIIO`` or ``LATBOLTZ``,
required by some LAMMPS packages, e.g. ``LATBOLTZ``,
and thus is not compatible with those packages.
.. note::
@ -107,9 +107,9 @@ MPI and OpenMP support in LAMMPS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you are installing MPI yourself to build a parallel LAMMPS
executable, we recommend either MPICH or OpenMPI which are regularly
executable, we recommend either MPICH or OpenMPI, which are regularly
used and tested with LAMMPS by the LAMMPS developers. MPICH can be
downloaded from the `MPICH home page <https://www.mpich.org>`_ and
downloaded from the `MPICH home page <https://www.mpich.org>`_, and
OpenMPI can be downloaded correspondingly from the `OpenMPI home page
<https://www.open-mpi.org>`_. Other MPI packages should also work. No
specific vendor provided and standard compliant MPI library is currently
@ -129,13 +129,12 @@ in particular the Intel compilers on top of OpenMP. Also, the ``KOKKOS``
package can be compiled to include OpenMP threading.
In addition, there are a few commands in LAMMPS that have native OpenMP
support included as well. These are commands in the ``MPIIO``,
``ML-SNAP``, ``DIFFRACTION``, and ``DPD-REACT`` packages. In addition
some packages support OpenMP threading indirectly through the libraries
they interface to: e.g. ``LATTE``, ``KSPACE``, and ``COLVARS``.
See the :doc:`Packages details <Packages_details>` page for more
info on these packages and the pages for their respective commands
for OpenMP threading info.
support included as well. These are commands in the ``ML-SNAP``,
``DIFFRACTION``, and ``DPD-REACT`` packages. Furthermore, some packages
support OpenMP threading indirectly through the libraries they interface
to: e.g. ``KSPACE``, and ``COLVARS``. See the :doc:`Packages details
<Packages_details>` page for more info on these packages, and the pages
for their respective commands for OpenMP threading info.
For CMake, if you use ``BUILD_OMP=yes``, you can use these packages
and turn on their native OpenMP support and turn on their native OpenMP
@ -144,9 +143,9 @@ variable before you launch LAMMPS.
For building via conventional make, the ``CCFLAGS`` and ``LINKFLAGS``
variables in Makefile.machine need to include the compiler flag that
enables OpenMP. For GNU compilers it is ``-fopenmp``\ . For (recent) Intel
compilers it is ``-qopenmp``\ . If you are using a different compiler,
please refer to its documentation.
enables OpenMP. For the GNU compilers or Clang, it is ``-fopenmp``\ .
For (recent) Intel compilers, it is ``-qopenmp``\ . If you are using a
different compiler, please refer to its documentation.
.. _default-none-issues:
@ -174,15 +173,16 @@ Choice of compiler and compile/link options
The choice of compiler and compiler flags can be important for maximum
performance. Vendor provided compilers for a specific hardware can
produce faster code than open-source compilers like the GNU compilers.
On the most common x86 hardware most popular C++ compilers are quite
similar in performance of C/C++ code at high optimization levels. When
using the ``INTEL`` package, there is a distinct advantage in using
the `Intel C++ compiler <intel_>`_ due to much improved vectorization
through SSE and AVX instructions on compatible hardware as the source
code includes changes and Intel compiler specific directives to enable
high degrees of vectorization. This may change over time as equivalent
vectorization directives are included into OpenMP standard revisions and
other compilers adopt them.
On the most common x86 hardware, the most popular C++ compilers are
quite similar in their ability to optimize regular C/C++ source code at
high optimization levels. When using the ``INTEL`` package, there is a
distinct advantage in using the `Intel C++ compiler <intel_>`_ due to
much improved vectorization through SSE and AVX instructions on
compatible hardware. The source code in that package conditionally
includes compiler specific directives to enable these high degrees of
vectorization. This may change over time as equivalent vectorization
directives are included into the OpenMP standard and other compilers
adopt them.
.. _intel: https://software.intel.com/en-us/intel-compilers
@ -196,7 +196,7 @@ LAMMPS.
.. tab:: CMake build
By default CMake will use the compiler it finds according to
internal preferences and it will add optimization flags
internal preferences, and it will add optimization flags
appropriate to that compiler and any :doc:`accelerator packages
<Speed_packages>` you have included in the build. CMake will
check if the detected or selected compiler is compatible with the
@ -250,9 +250,9 @@ LAMMPS.
and `-C ../cmake/presets/pgi.cmake`
will switch the compiler to the PGI compilers.
In addition you can set ``CMAKE_TUNE_FLAGS`` to specifically add
compiler flags to tune for optimal performance on given hosts. By
default this variable is empty.
Furthermore, you can set ``CMAKE_TUNE_FLAGS`` to specifically add
compiler flags to tune for optimal performance on given hosts.
This variable is empty by default.
.. note::
@ -276,7 +276,7 @@ LAMMPS.
Parallel build (see ``src/MAKE/Makefile.mpi``):
.. code-block:: bash
.. code-block:: make
CC = mpicxx
CCFLAGS = -g -O3
@ -296,7 +296,7 @@ LAMMPS.
If compilation stops with a message like the following:
.. code-block::
.. code-block:: output
g++ -g -O3 -DLAMMPS_GZIP -DLAMMPS_MEMALIGN=64 -I../STUBS -c ../main.cpp
In file included from ../pointers.h:24:0,
@ -368,10 +368,10 @@ running LAMMPS from Python via its library interface.
# no default value
The compilation will always produce a LAMMPS library and an
executable linked to it. By default this will be a static library
named ``liblammps.a`` and an executable named ``lmp`` Setting
``BUILD_SHARED_LIBS=yes`` will instead produce a shared library
called ``liblammps.so`` (or ``liblammps.dylib`` or
executable linked to it. By default, this will be a static
library named ``liblammps.a`` and an executable named ``lmp``
Setting ``BUILD_SHARED_LIBS=yes`` will instead produce a shared
library called ``liblammps.so`` (or ``liblammps.dylib`` or
``liblammps.dll`` depending on the platform) If
``LAMMPS_MACHINE=name`` is set in addition, the name of the
generated libraries will be changed to either ``liblammps_name.a``
@ -429,7 +429,7 @@ You may need to use ``sudo make install`` in place of the last line if
you do not have write privileges for ``/usr/local/lib`` or use the
``--prefix`` configuration option to select an installation folder,
where you do have write access. The end result should be the file
``/usr/local/lib/libmpich.so``. On many Linux installations the folder
``/usr/local/lib/libmpich.so``. On many Linux installations, the folder
``${HOME}/.local`` is an alternative to using ``/usr/local`` and does
not require superuser or sudo access. In that case the configuration
step becomes:
@ -438,9 +438,10 @@ step becomes:
./configure --enable-shared --prefix=${HOME}/.local
Avoiding to use "sudo" for custom software installation (i.e. from source
and not through a package manager tool provided by the OS) is generally
recommended to ensure the integrity of the system software installation.
Avoiding the use of "sudo" for custom software installation (i.e. from
source and not through a package manager tool provided by the OS) is
generally recommended to ensure the integrity of the system software
installation.
----------
@ -487,8 +488,9 @@ using CMake or Make.
.. code-block:: bash
-D BUILD_TOOLS=value # yes or no (default)
-D BUILD_LAMMPS_SHELL=value # yes or no (default)
-D BUILD_TOOLS=value # yes or no (default). Build binary2txt, chain.x, micelle2d.x, msi2lmp, phana, stl_bin2txt
-D BUILD_LAMMPS_SHELL=value # yes or no (default). Build lammps-shell
-D BUILD_LAMMPS_GUI=value # yes or no (default). Build lammps-gui
The generated binaries will also become part of the LAMMPS installation
(see below).
@ -502,7 +504,6 @@ using CMake or Make.
make binary2txt # build only binary2txt tool
make chain # build only chain tool
make micelle2d # build only micelle2d tool
make thermo_extract # build only thermo_extract tool
cd lammps/tools/lammps-shell
make # build LAMMPS shell
@ -514,11 +515,11 @@ using CMake or Make.
Install LAMMPS after a build
------------------------------------------
After building LAMMPS, you may wish to copy the LAMMPS executable of
library, along with other LAMMPS files (library header, doc files) to
a globally visible place on your system, for others to access. Note
that you may need super-user privileges (e.g. sudo) if the directory
you want to copy files to is protected.
After building LAMMPS, you may wish to copy the LAMMPS executable or
library, along with other LAMMPS files (library header, doc files), to a
globally visible place on your system, for others to access. Note that
you may need super-user privileges (e.g. sudo) if the directory you want
to copy files to is protected.
.. tabs::
@ -536,7 +537,7 @@ you want to copy files to is protected.
environment variable, if you are installing LAMMPS into a non-system
location and/or are linking to libraries in a non-system location that
depend on such runtime path settings.
As an alternative you may set the CMake variable ``LAMMPS_INSTALL_RPATH``
As an alternative, you may set the CMake variable ``LAMMPS_INSTALL_RPATH``
to ``on`` and then the runtime paths for any linked shared libraries
and the library installation folder for the LAMMPS library will be
embedded and thus the requirement to set environment variables is avoided.

105
doc/src/Build_cmake.rst
View File

@ -9,44 +9,42 @@ page.
The following text assumes some familiarity with CMake and focuses on
using the command line tool ``cmake`` and what settings are supported
for building LAMMPS. A more detailed tutorial on how to use ``cmake``
itself, the text mode or graphical user interface, change the generated
output files for different build tools and development environments is
on a :doc:`separate page <Howto_cmake>`.
for building LAMMPS. A more detailed tutorial on how to use CMake
itself, the text mode or graphical user interface, to change the
generated output files for different build tools and development
environments is on a :doc:`separate page <Howto_cmake>`.
.. note::
LAMMPS currently requires that CMake version 3.10 or later is available;
version 3.12 or later is preferred.
LAMMPS currently requires that CMake version 3.16 or later is available.
.. warning::
You must not mix the :doc:`traditional make based <Build_make>`
LAMMPS build procedure with using CMake. Thus no packages may be
LAMMPS build procedure with using CMake. No packages may be
installed or a build been previously attempted in the LAMMPS source
directory by using ``make <machine>``. CMake will detect if this is
the case and generate an error. To remove conflicting files from the
``src`` you can use the command ``make no-all purge`` which will
un-install all packages and delete all auto-generated files.
uninstall all packages and delete all auto-generated files.
Advantages of using CMake
^^^^^^^^^^^^^^^^^^^^^^^^^
CMake is an alternative to compiling LAMMPS in the traditional way
through :doc:`(manually customized) makefiles <Build_make>` and a recent
addition to LAMMPS thanks to the efforts of Christoph Junghans (LANL)
and Richard Berger (Temple U). Using CMake has multiple advantages that
are specifically helpful for people with limited experience in compiling
software or for people that want to modify or extend LAMMPS.
through :doc:`(manually customized) makefiles <Build_make>`. Using
CMake has multiple advantages that are specifically helpful for
people with limited experience in compiling software or for people
that want to modify or extend LAMMPS.
- CMake can detect available hardware, tools, features, and libraries
and adapt the LAMMPS default build configuration accordingly.
- CMake can generate files for different build tools and integrated
development environments (IDE).
- CMake supports customization of settings with a text mode or graphical
user interface. No knowledge of file formats or and complex command
line syntax required.
- CMake supports customization of settings with a command line, text
mode, or graphical user interface. No manual editing of files,
knowledge of file formats or complex command line syntax is required.
- All enabled components are compiled in a single build operation.
- Automated dependency tracking for all files and configuration options.
- Support for true out-of-source compilation. Multiple configurations
@ -55,23 +53,23 @@ software or for people that want to modify or extend LAMMPS.
source tree.
- Simplified packaging of LAMMPS for Linux distributions, environment
modules, or automated build tools like `Homebrew <https://brew.sh/>`_.
- Integration of automated regression testing (the LAMMPS side for that
is still under development).
- Integration of automated unit and regression testing (the LAMMPS side
of this is still under active development).
.. _cmake_build:
Getting started
^^^^^^^^^^^^^^^
Building LAMMPS with CMake is a two-step process. First you use CMake
to generate a build environment in a new directory. For that purpose
you can use either the command-line utility ``cmake`` (or ``cmake3``),
the text-mode UI utility ``ccmake`` (or ``ccmake3``) or the graphical
utility ``cmake-gui``, or use them interchangeably. The second step is
then the compilation and linking of all objects, libraries, and
executables. Here is a minimal example using the command line version of
CMake to build LAMMPS with no add-on packages enabled and no
customization:
Building LAMMPS with CMake is a two-step process. In the first step,
you use CMake to generate a build environment in a new directory. For
that purpose you can use either the command-line utility ``cmake`` (or
``cmake3``), the text-mode UI utility ``ccmake`` (or ``ccmake3``) or the
graphical utility ``cmake-gui``, or use them interchangeably. The
second step is then the compilation and linking of all objects,
libraries, and executables using the selected build tool. Here is a
minimal example using the command line version of CMake to build LAMMPS
with no add-on packages enabled and no customization:
.. code-block:: bash
@ -96,17 +94,17 @@ Compilation can take a long time, since LAMMPS is a large project with
many features. If your machine has multiple CPU cores (most do these
days), you can speed this up by compiling sources in parallel with
``make -j N`` (with N being the maximum number of concurrently executed
tasks). Also installation of the `ccache <https://ccache.dev/>`_ (=
Compiler Cache) software may speed up repeated compilation even more,
e.g. during code development.
tasks). Installation of the `ccache <https://ccache.dev/>`_ (= Compiler
Cache) software may speed up repeated compilation even more, e.g. during
code development, especially when repeatedly switching between branches.
After the initial build, whenever you edit LAMMPS source files, enable
or disable packages, change compiler flags or build options, you must
re-compile and relink the LAMMPS executable with ``cmake --build .`` (or
``make``). If the compilation fails for some reason, try running
``cmake .`` and then compile again. The included dependency tracking
should make certain that only the necessary subset of files are
re-compiled. You can also delete compiled objects, libraries and
should make certain that only the necessary subset of files is
re-compiled. You can also delete compiled objects, libraries, and
executables with ``cmake --build . --target clean`` (or ``make clean``).
After compilation, you may optionally install the LAMMPS executable into
@ -132,12 +130,12 @@ file called ``CMakeLists.txt`` (for LAMMPS it is located in the
``CMakeCache.txt``, which is generated at the end of the CMake
configuration step. The cache file contains all current CMake settings.
To modify settings, enable or disable features, you need to set *variables*
with either the *-D* command line flag (``-D VARIABLE1_NAME=value``) or
change them in the text mode of graphical user interface. The *-D* flag
can be used several times in one command.
To modify settings, enable or disable features, you need to set
*variables* with either the *-D* command line flag (``-D
VARIABLE1_NAME=value``) or change them in the text mode of the graphical
user interface. The *-D* flag can be used several times in one command.
For your convenience we provide :ref:`CMake presets <cmake_presets>`
For your convenience, we provide :ref:`CMake presets <cmake_presets>`
that combine multiple settings to enable optional LAMMPS packages or use
a different compiler tool chain. Those are loaded with the *-C* flag
(``-C ../cmake/presets/basic.cmake``). This step would only be needed
@ -155,22 +153,23 @@ specific CMake version is given when running ``cmake --help``.
Multi-configuration build systems
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Throughout this manual it is mostly assumed that LAMMPS is being built
Throughout this manual, it is mostly assumed that LAMMPS is being built
on a Unix-like operating system with "make" as the underlying "builder",
since this is the most common case. In this case the build "configuration"
is chose using ``-D CMAKE_BUILD_TYPE=<configuration>`` with ``<configuration>``
being one of "Release", "Debug", "RelWithDebInfo", or "MinSizeRel".
Some build tools, however, can also use or even require to have a so-called
multi-configuration build system setup. For those the built type (or
configuration) is chosen at compile time using the same build files. E.g.
with:
since this is the most common case. In this case the build
"configuration" is chose using ``-D CMAKE_BUILD_TYPE=<configuration>``
with ``<configuration>`` being one of "Release", "Debug",
"RelWithDebInfo", or "MinSizeRel". Some build tools, however, can also
use or even require having a so-called multi-configuration build system
setup. For a multi-configuration build, the built type (or
configuration) is selected at compile time using the same build
files. E.g. with:
.. code-block:: bash
cmake --build build-multi --config Release
In that case the resulting binaries are not in the build folder directly
but in sub-directories corresponding to the build type (i.e. Release in
but in subdirectories corresponding to the build type (i.e. Release in
the example from above). Similarly, for running unit tests the
configuration is selected with the *-C* flag:
@ -178,13 +177,13 @@ configuration is selected with the *-C* flag:
ctest -C Debug
The CMake scripts in LAMMPS have basic support for being compiled using a
multi-config build system, but not all of it has been ported. This is in
particular applicable to compiling packages that require additional libraries
that would be downloaded and compiled by CMake. The "windows" preset file
tries to keep track of which packages can be compiled natively with the
MSVC compilers out-of-the box. Not all of those external libraries are
portable to Windows either.
The CMake scripts in LAMMPS have basic support for being compiled using
a multi-config build system, but not all of it has been ported. This is
in particular applicable to compiling packages that require additional
libraries that would be downloaded and compiled by CMake. The
``windows.cmake`` preset file tries to keep track of which packages can
be compiled natively with the MSVC compilers out-of-the box. Not all of
the external libraries are portable to Windows, either.
Installing CMake

96
doc/src/Build_development.rst
View File

@ -46,7 +46,7 @@ It can be enabled for all C++ code with the following CMake flag
With this flag enabled all source files will be processed twice, first to
be compiled and then to be analyzed. Please note that the analysis can be
significantly more time consuming than the compilation itself.
significantly more time-consuming than the compilation itself.
----------
@ -140,36 +140,62 @@ of the LAMMPS project on GitHub.
The unit testing facility is integrated into the CMake build process
of the LAMMPS source code distribution itself. It can be enabled by
setting ``-D ENABLE_TESTING=on`` during the CMake configuration step.
It requires the `YAML <http://pyyaml.org/>`_ library and development
It requires the `YAML <https://pyyaml.org/>`_ library and development
headers (if those are not found locally a recent version will be
downloaded and compiled along with LAMMPS and the test program) to
compile and will download and compile a specific recent version of the
`Googletest <https://github.com/google/googletest/>`_ C++ test framework
for implementing the tests.
.. admonition:: Software version requirements for testing
:class: note
The compiler and library version requirements for the testing
framework are more strict than for the main part of LAMMPS. For
example the default GNU C++ and Fortran compilers of RHEL/CentOS 7.x
(version 4.8.x) are not sufficient. The CMake configuration will try
to detect incompatible versions and either skip incompatible tests or
stop with an error. Also the number of tests will depend on
installed LAMMPS packages, development environment, operating system,
and configuration settings.
After compilation is complete, the unit testing is started in the build
folder using the ``ctest`` command, which is part of the CMake software.
The output of this command will be looking something like this::
The output of this command will be looking something like this:
[...]$ ctest
Test project /home/akohlmey/compile/lammps/build-testing
Start 1: MolPairStyle:hybrid-overlay
1/109 Test #1: MolPairStyle:hybrid-overlay ......... Passed 0.02 sec
Start 2: MolPairStyle:hybrid
2/109 Test #2: MolPairStyle:hybrid ................. Passed 0.01 sec
Start 3: MolPairStyle:lj_class2
[...]
Start 107: PotentialFileReader
107/109 Test #107: PotentialFileReader ................ Passed 0.04 sec
Start 108: EIMPotentialFileReader
108/109 Test #108: EIMPotentialFileReader ............. Passed 0.03 sec
Start 109: TestSimpleCommands
109/109 Test #109: TestSimpleCommands ................. Passed 0.02 sec
.. code-block:: console
100% tests passed, 0 tests failed out of 26
$ ctest
Test project /home/akohlmey/compile/lammps/build-testing
Start 1: RunLammps
1/563 Test #1: RunLammps .......................................... Passed 0.28 sec
Start 2: HelpMessage
2/563 Test #2: HelpMessage ........................................ Passed 0.06 sec
Start 3: InvalidFlag
3/563 Test #3: InvalidFlag ........................................ Passed 0.06 sec
Start 4: Tokenizer
4/563 Test #4: Tokenizer .......................................... Passed 0.05 sec
Start 5: MemPool
5/563 Test #5: MemPool ............................................ Passed 0.05 sec
Start 6: ArgUtils
6/563 Test #6: ArgUtils ........................................... Passed 0.05 sec
[...]
Start 561: ImproperStyle:zero
561/563 Test #561: ImproperStyle:zero ................................. Passed 0.07 sec
Start 562: TestMliapPyUnified
562/563 Test #562: TestMliapPyUnified ................................. Passed 0.16 sec
Start 563: TestPairList
563/563 Test #563: TestPairList ....................................... Passed 0.06 sec
Total Test time (real) = 25.57 sec
100% tests passed, 0 tests failed out of 563
Label Time Summary:
generated = 0.85 sec*proc (3 tests)
noWindows = 4.16 sec*proc (2 tests)
slow = 78.33 sec*proc (67 tests)
unstable = 28.23 sec*proc (34 tests)
Total Test time (real) = 132.34 sec
The ``ctest`` command has many options, the most important ones are:
@ -200,11 +226,13 @@ Fortran) and testing different aspects of the LAMMPS software and its features.
The tests will adapt to the compilation settings of LAMMPS, so that tests
will be skipped if prerequisite features are not available in LAMMPS.
.. note::
.. admonition:: Work in Progress
:class: note
The unit test framework was added in spring 2020 and is under active
development. The coverage is not complete and will be expanded over
time.
time. Preference is given to parts of the code base that are easy to
test or commonly used.
Tests for styles of the same kind of style (e.g. pair styles or bond
styles) are performed with the same test executable using different
@ -238,9 +266,9 @@ the CMake option ``-D BUILD_MPI=off`` can significantly speed up testing,
since this will skip the MPI initialization for each test run.
Below is an example command and output:
.. parsed-literal::
.. code-block:: console
[tests]$ test_pair_style mol-pair-lj_cut.yaml
$ test_pair_style mol-pair-lj_cut.yaml
[==========] Running 6 tests from 1 test suite.
[----------] Global test environment set-up.
[----------] 6 tests from PairStyle
@ -490,11 +518,15 @@ The following options are available.
make fix-errordocs # remove error docs in header files
make check-permissions # search for files with permissions issues
make fix-permissions # correct permissions issues in files
make check-docs # search for several issues in the manual
make check-version # list files with pending release version tags
make check # run all check targets from above
These should help to make source and documentation files conforming
to some the coding style preferences of the LAMMPS developers.
.. _clang-format:
Clang-format support
--------------------
@ -520,7 +552,7 @@ commands like the following:
.. code-block:: bash
$ clang-format -i some_file.cpp
clang-format -i some_file.cpp
The following target are available for both, GNU make and CMake:
@ -529,3 +561,19 @@ The following target are available for both, GNU make and CMake:
make format-src # apply clang-format to all files in src and the package folders
make format-tests # apply clang-format to all files in the unittest tree
----------
.. _gh-cli:
GitHub command line interface
-----------------------------
GitHub is developing a `tool for the command line
<https://cli.github.com>`_ that interacts with the GitHub website via a
command called ``gh``. This can be extremely convenient when working
with a Git repository hosted on GitHub (like LAMMPS). It is thus highly
recommended to install it when doing LAMMPS development.
The capabilities of the ``gh`` command is continually expanding, so
please see the documentation at https://cli.github.com/manual/

843
doc/src/Build_extras.rst
View File

File diff suppressed because it is too large Load Diff

45
doc/src/Build_link.rst
View File

@ -1,33 +1,32 @@
Link LAMMPS as a library to another code
========================================
LAMMPS is designed as a library of C++ objects that can be
integrated into other applications including Python scripts.
The files ``src/library.cpp`` and ``src/library.h`` define a
C-style API for using LAMMPS as a library. See the
:doc:`Howto_library` page
for a description of the interface and how to use it for your needs.
LAMMPS is designed as a library of C++ objects that can be integrated
into other applications, including Python scripts. The files
``src/library.cpp`` and ``src/library.h`` define a C-style API for using
LAMMPS as a library. See the :doc:`Howto_library` page for a
description of the interface and how to use it for your needs.
The :doc:`Build_basics` page explains how to build
LAMMPS as either a shared or static library. This results in a file
in the compilation folder called ``liblammps.a`` or ``liblammps_<name>.a``
in case of building a static library. In case of a shared library
the name is the same only that the suffix is going to be either ``.so``
or ``.dylib`` or ``.dll`` instead of ``.a`` depending on the OS.
In some cases the ``.so`` file may be a symbolic link to a file with
the suffix ``.so.0`` (or some other number).
The :doc:`Build_basics` page explains how to build LAMMPS as either a
shared or static library. This results in a file in the compilation
folder called ``liblammps.a`` or ``liblammps_<name>.a`` in case of
building a static library. In case of a shared library, the name is the
same only that the suffix is going to be either ``.so`` or ``.dylib`` or
``.dll`` instead of ``.a`` depending on the OS. In some cases, the
``.so`` file may be a symbolic link to a file with the suffix ``.so.0``
(or some other number).
.. note::
Care should be taken to use the same MPI library for the calling code
and the LAMMPS library unless LAMMPS is to be compiled without (real)
MPI support using the include STUBS MPI library.
and the LAMMPS library, unless LAMMPS is to be compiled without (real)
MPI support using the included STUBS MPI library.
Link with LAMMPS as a static library
------------------------------------
The calling application can link to LAMMPS as a static library with
compilation and link commands as in the examples shown below. These
compilation and link commands, as in the examples shown below. These
are examples for a code written in C in the file ``caller.c``.
The benefit of linking to a static library is, that the resulting
executable is independent of that library since all required
@ -142,10 +141,10 @@ Link with LAMMPS as a shared library
When linking to LAMMPS built as a shared library, the situation becomes
much simpler, as all dependent libraries and objects are either included
in the shared library or registered as a dependent library in the shared
library file. Thus those libraries need not to be specified when
linking the calling executable. Only the *-I* flags are needed. So the
example case from above of the serial version static LAMMPS library with
the POEMS package installed becomes:
library file. Thus, those libraries need not be specified when linking
the calling executable. Only the *-I* flags are needed. So the example
case from above of the serial version static LAMMPS library with the
POEMS package installed becomes:
.. tabs::
@ -209,7 +208,7 @@ You can verify whether all required shared libraries are found with the
.. code-block:: bash
$ LD_LIBRARY_PATH=/home/user/lammps/src ldd caller
LD_LIBRARY_PATH=/home/user/lammps/src ldd caller
linux-vdso.so.1 (0x00007ffe729e0000)
liblammps.so => /home/user/lammps/src/liblammps.so (0x00007fc91bb9e000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fc91b984000)
@ -222,7 +221,7 @@ If a required library is missing, you would get a 'not found' entry:
.. code-block:: bash
$ ldd caller
ldd caller
linux-vdso.so.1 (0x00007ffd672fe000)
liblammps.so => not found
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb7c7e86000)

62
doc/src/Build_make.rst
View File

@ -20,21 +20,22 @@ with :doc:`CMake <Build_cmake>`. The makefiles of the traditional
make based build process and the scripts they are calling expect a few
additional tools to be available and functioning.
* a working C/C++ compiler toolchain supporting the C++11 standard; on
Linux these are often the GNU compilers. Some older compilers
* A working C/C++ compiler toolchain supporting the C++11 standard; on
Linux, these are often the GNU compilers. Some older compiler versions
require adding flags like ``-std=c++11`` to enable the C++11 mode.
* a Bourne shell compatible "Unix" shell program (often this is ``bash``)
* a few shell utilities: ``ls``, ``mv``, ``ln``, ``rm``, ``grep``, ``sed``, ``tr``, ``cat``, ``touch``, ``diff``, ``dirname``
* python (optional, required for ``make lib-<pkg>`` in the src folder).
python scripts are currently tested with python 2.7 and 3.6. The procedure
for :doc:`building the documentation <Build_manual>` requires python 3.5 or later.
* A Bourne shell compatible "Unix" shell program (frequently this is ``bash``)
* A few shell utilities: ``ls``, ``mv``, ``ln``, ``rm``, ``grep``, ``sed``, ``tr``, ``cat``, ``touch``, ``diff``, ``dirname``
* Python (optional, required for ``make lib-<pkg>`` in the src
folder). Python scripts are currently tested with python 2.7 and
3.6 to 3.11. The procedure for :doc:`building the documentation
<Build_manual>` *requires* Python 3.5 or later.
Getting started
^^^^^^^^^^^^^^^
To include LAMMPS packages (i.e. optional commands and styles) you must
enable (or "install") them first, as discussed on the :doc:`Build
package <Build_package>` page. If a packages requires (provided or
package <Build_package>` page. If a package requires (provided or
external) libraries, you must configure and build those libraries
**before** building LAMMPS itself and especially **before** enabling
such a package with ``make yes-<package>``. :doc:`Building LAMMPS with
@ -56,36 +57,36 @@ Compilation can take a long time, since LAMMPS is a large project with
many features. If your machine has multiple CPU cores (most do these
days), you can speed this up by compiling sources in parallel with
``make -j N`` (with N being the maximum number of concurrently executed
tasks). Also installation of the `ccache <https://ccache.dev/>`_ (=
Compiler Cache) software may speed up repeated compilation even more,
e.g. during code development.
tasks). Installation of the `ccache <https://ccache.dev/>`_ (= Compiler
Cache) software may speed up repeated compilation even more, e.g. during
code development, especially when repeatedly switching between branches.
After the initial build, whenever you edit LAMMPS source files, or add
or remove new files to the source directory (e.g. by installing or
uninstalling packages), you must re-compile and relink the LAMMPS
executable with the same ``make <machine>`` command. The makefile's
dependency tracking should insure that only the necessary subset of
files are re-compiled. If you change settings in the makefile, you have
to recompile *everything*. To delete all objects you can use ``make
dependency tracking should ensure that only the necessary subset of
files is re-compiled. If you change settings in the makefile, you have
to recompile *everything*. To delete all objects, you can use ``make
clean-<machine>``.
.. note::
Before the actual compilation starts, LAMMPS will perform several
steps to collect information from the configuration and setup that
is then embedded into the executable. When you build LAMMPS for
the first time, it will also compile a tool to quickly assemble
a list of dependencies, that are required for the make program to
correctly detect which parts need to be recompiled after changes
were made to the sources.
steps to collect information from the configuration and setup that is
then embedded into the executable. When you build LAMMPS for the
first time, it will also compile a tool to quickly determine a list
of dependencies. Those are required for the make program to
correctly detect, which files need to be recompiled or relinked
after changes were made to the sources.
Customized builds and alternate makefiles
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The ``src/MAKE`` directory tree contains the ``Makefile.<machine>``
files included in the LAMMPS distribution. Typing ``make example`` uses
``Makefile.example`` from one of those folders, if available. Thus the
``make serial`` and ``make mpi`` lines above use
``Makefile.example`` from one of those folders, if available. The
``make serial`` and ``make mpi`` lines above, for example, use
``src/MAKE/Makefile.serial`` and ``src/MAKE/Makefile.mpi``,
respectively. Other makefiles are in these directories:
@ -106,17 +107,18 @@ a new name, please edit the first line with the description and machine
name, so you will not confuse yourself, when looking at the machine
summary.
Makefiles you may wish to try include these (some require a package
first be installed). Many of these include specific compiler flags
for optimized performance. Please note, however, that some of these
customized machine Makefile are contributed by users. Since both
compilers, OS configurations, and LAMMPS itself keep changing, their
settings may become outdated:
Makefiles you may wish to try out, include those listed below (some
require a package first be installed). Many of these include specific
compiler flags for optimized performance. Please note, however, that
some of these customized machine Makefile are contributed by users, and
thus may have modifications specific to the systems of those users.
Since compilers, OS configurations, and LAMMPS itself keep changing,
their settings may become outdated, too:
.. code-block:: bash
make mac # build serial LAMMPS on a Mac
make mac_mpi # build parallel LAMMPS on a Mac
make mac # build serial LAMMPS on macOS
make mac_mpi # build parallel LAMMPS on macOS
make intel_cpu # build with the INTEL package optimized for CPUs
make knl # build with the INTEL package optimized for KNLs
make opt # build with the OPT package optimized for CPUs

57
doc/src/Build_manual.rst
View File

@ -2,7 +2,7 @@ Build the LAMMPS documentation
==============================
Depending on how you obtained LAMMPS and whether you have built the
manual yourself, this directory has a number of sub-directories and
manual yourself, this directory has a number of subdirectories and
files. Here is a list with descriptions:
.. code-block:: bash
@ -33,7 +33,7 @@ various tools and files. Some of them have to be installed (see below). For
the rest the build process will attempt to download and install them into
a python virtual environment and local folders.
A current version of the manual (latest patch release, that is the state
A current version of the manual (latest feature release, that is the state
of the *release* branch) is is available online at:
`https://docs.lammps.org/ <https://docs.lammps.org/>`_.
A version of the manual corresponding to the ongoing development (that is
@ -48,15 +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
<https://sphinx-doc.org>`_ document generator tool. It also
<https://www.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
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``.
Python interpreter version 3.8 or later, 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
@ -87,6 +87,7 @@ folder. The following ``make`` commands are available:
make anchor_check # check for duplicate anchor labels
make style_check # check for complete and consistent style lists
make package_check # check for complete and consistent package lists
make link_check # check for broken or outdated URLs
make spelling # spell-check the manual
----------
@ -125,38 +126,29 @@ common setups:
.. code-block:: bash
sudo apt-get install python-virtualenv git doxygen
sudo apt-get install git doxygen
.. tab:: RHEL or CentOS (Version 7.x)
.. code-block:: bash
sudo yum install python3-virtualenv git doxygen
sudo yum install git doxygen
.. tab:: Fedora or RHEL/CentOS (8.x or later)
.. code-block:: bash
sudo dnf install python3-virtualenv git doxygen
sudo dnf install git doxygen
.. tab:: MacOS X
.. tab:: macOS
*Python 3*
Download the latest Python 3 MacOS X package from
If Python 3 is not available on your macOS system, you can
download the latest Python 3 macOS package from
`https://www.python.org <https://www.python.org>`_ and install it.
This will install both Python 3 and pip3.
*virtualenv*
Once Python 3 is installed, open a Terminal and type
.. code-block:: bash
pip3 install virtualenv
This will install virtualenv from the Python Package Index.
Prerequisites for PDF
---------------------
@ -176,7 +168,7 @@ math expressions transparently into embedded images.
For converting the generated ePUB file to a MOBI format file (for e-book
readers, like Kindle, that cannot read ePUB), you also need to have the
``ebook-convert`` tool from the "calibre" software
installed. `http://calibre-ebook.com/ <http://calibre-ebook.com/>`_
installed. `https://calibre-ebook.com/ <https://calibre-ebook.com/>`_
Typing ``make mobi`` will first create the ePUB file and then convert
it. On the Kindle readers in particular, you also have support for PDF
files, so you could download and view the PDF version as an alternative.
@ -216,9 +208,20 @@ be multiple tests run automatically:
- A test that only standard, printable ASCII text characters are used.
This runs the command ``env LC_ALL=C grep -n '[^ -~]' src/*.rst`` and
thus prints all offending lines with filename and line number
prepended to the screen. Special characters like the Angstrom
:math:`\mathrm{\mathring{A}}` should be typeset with embedded math
(like this ``:math:`\mathrm{\mathring{A}}```\ ).
prepended to the screen. Special characters like Greek letters
(:math:`\alpha~~\sigma~~\epsilon`), super- or subscripts
(:math:`x^2~~\mathrm{U}_{LJ}`), mathematical expressions
(:math:`\frac{1}{2}\mathrm{N}~~x\to\infty`), or the Angstrom symbol
(:math:`\AA`) should be typeset with embedded LaTeX (like this
``:math:`\alpha \sigma \epsilon```, ``:math:`x^2 \mathrm{E}_{LJ}```,
``:math:`\frac{1}{2}\mathrm{N} x\to\infty```, or ``:math:`\AA```\ ).
- Embedded LaTeX is rendered in HTML output with `MathJax
<https://www.mathjax.org/>`_ and in PDF output by passing the embedded
text to LaTeX. Some care has to be taken, though, since there are
limitations which macros and features can be used in either mode, so
it is recommended to always check whether any new or changed
documentation does translate and render correctly with either output.
- A test whether all styles are documented and listed in their
respective overview pages. A typical output with warnings looks like this:

56
doc/src/Build_package.rst
View File

@ -4,13 +4,14 @@ Include packages in build
In LAMMPS, a package is a group of files that enable a specific set of
features. For example, force fields for molecular systems or
rigid-body constraints are in packages. In the src directory, each
package is a sub-directory with the package name in capital letters.
package is a subdirectory with the package name in capital letters.
An overview of packages is given on the :doc:`Packages <Packages>` doc
page. Brief overviews of each package are on the :doc:`Packages details <Packages_details>` page.
page. Brief overviews of each package are on the :doc:`Packages details
<Packages_details>` page.
When building LAMMPS, you can choose to include or exclude each
package. In general there is no need to include a package if you
package. Generally, there is no need to include a package if you
never plan to use its features.
If you get a run-time error that a LAMMPS command or style is
@ -30,26 +31,30 @@ steps, as explained on the :doc:`Build extras <Build_extras>` page.
These links take you to the extra instructions for those select
packages:
.. this list must be kept in sync with its counterpart in Build_extras.rst
.. table_from_list::
:columns: 6
* :ref:`ADIOS <adios>`
* :ref:`ATC <atc>`
* :ref:`AWPMD <awpmd>`
* :ref:`COLVARS <colvars>`
* :ref:`COLVARS <colvar>`
* :ref:`COMPRESS <compress>`
* :ref:`ELECTRODE <electrode>`
* :ref:`GPU <gpu>`
* :ref:`H5MD <h5md>`
* :ref:`INTEL <intel>`
* :ref:`KIM <kim>`
* :ref:`KOKKOS <kokkos>`
* :ref:`LATTE <latte>`
* :ref:`LEPTON <lepton>`
* :ref:`MACHDYN <machdyn>`
* :ref:`MDI <mdi>`
* :ref:`ML-HDNNP <ml-hdnnp>`
* :ref:`ML-IAP <mliap>`
* :ref:`ML-PACE <ml-pace>`
* :ref:`ML-POD <ml-pod>`
* :ref:`ML-QUIP <ml-quip>`
* :ref:`MOLFILE <molfile>`
* :ref:`MSCG <mscg>`
* :ref:`NETCDF <netcdf>`
* :ref:`OPENMP <openmp>`
* :ref:`OPT <opt>`
@ -87,7 +92,7 @@ versus make.
If you switch between building with CMake and make builds, no
packages in the src directory can be installed when you invoke
``cmake``. CMake will give an error if that is not the case,
indicating how you can un-install all packages in the src dir.
indicating how you can uninstall all packages in the src dir.
.. tab:: Traditional make
@ -96,7 +101,7 @@ versus make.
cd lammps/src
make ps # check which packages are currently installed
make yes-name # install a package with name
make no-name # un-install a package with name
make no-name # uninstall a package with name
make mpi # build LAMMPS with whatever packages are now installed
Examples:
@ -112,13 +117,13 @@ versus make.
.. note::
You must always re-build LAMMPS (via make) after installing or
un-installing a package, for the action to take effect. The
uninstalling a package, for the action to take effect. The
included dependency tracking will make certain only files that
are required to be rebuilt are recompiled.
.. note::
You cannot install or un-install packages and build LAMMPS in a
You cannot install or uninstall packages and build LAMMPS in a
single make command with multiple targets, e.g. ``make
yes-colloid mpi``. This is because the make procedure creates
a list of source files that will be out-of-date for the build
@ -143,7 +148,7 @@ other files dependent on that package are also excluded.
if you downloaded a tarball, 3 packages (KSPACE, MANYBODY, MOLECULE)
were pre-installed via the traditional make procedure in the ``src``
directory. That is no longer the case, so that CMake will build
as-is without needing to un-install those packages.
as-is without needing to uninstall those packages.
----------
@ -160,9 +165,9 @@ control flow constructs for more complex operations.
LAMMPS includes several of these files to define configuration
"presets", similar to the options that exist for the Make based
system. Using these files you can enable/disable portions of the
available packages in LAMMPS. If you need a custom preset you can take
one of them as a starting point and customize it to your needs.
system. Using these files, you can enable/disable portions of the
available packages in LAMMPS. If you need a custom preset, you can
make a copy of one of them and modify it to suit your needs.
.. code-block:: bash
@ -176,7 +181,8 @@ one of them as a starting point and customize it to your needs.
cmake -C ../cmake/presets/pgi.cmake [OPTIONS] ../cmake # change settings to use the PGI compilers by default
cmake -C ../cmake/presets/all_on.cmake [OPTIONS] ../cmake # enable all packages
cmake -C ../cmake/presets/all_off.cmake [OPTIONS] ../cmake # disable all packages
mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake # compile with MinGW cross compilers
mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake # compile with MinGW cross-compilers
cmake -C ../cmake/presets/macos-multiarch.cmake [OPTIONS] ../cmake # compile serial multi-arch binaries on macOS
Presets that have names starting with "windows" are specifically for
compiling LAMMPS :doc:`natively on Windows <Build_windows>` and
@ -220,7 +226,7 @@ The following commands are useful for managing package source files
and their installation when building LAMMPS via traditional make.
Just type ``make`` in lammps/src to see a one-line summary.
These commands install/un-install sets of packages:
These commands install/uninstall sets of packages:
.. code-block:: bash
@ -236,40 +242,40 @@ These commands install/un-install sets of packages:
make yes-ext # install packages that require external libraries
make no-ext # uninstall packages that require external libraries
which install/un-install various sets of packages. Typing ``make
which install/uninstall various sets of packages. Typing ``make
package`` will list all the these commands.
.. note::
Installing or un-installing a package for the make based build process
Installing or uninstalling a package for the make based build process
works by simply copying files back and forth between the main source
directory src and the sub-directories with the package name (e.g.
directory src and the subdirectories with the package name (e.g.
src/KSPACE, src/ATC), so that the files are included or excluded
when LAMMPS is built. Only source files in the src folder will be
compiled.
The following make commands help manage files that exist in both the
src directory and in package sub-directories. You do not normally
src directory and in package subdirectories. You do not normally
need to use these commands unless you are editing LAMMPS files or are
updating LAMMPS via git.
Type ``make package-status`` or ``make ps`` to show which packages are
currently installed. For those that are installed, it will list any
files that are different in the src directory and package
sub-directory.
subdirectory.
Type ``make package-installed`` or ``make pi`` to show which packages are
currently installed, without listing the status of packages that are
not installed.
Type ``make package-update`` or ``make pu`` to overwrite src files with
files from the package sub-directories if the package is installed. It
files from the package subdirectories if the package is installed. It
should be used after the checkout has been :doc:`updated or changed
withy git <Install_git>`, this will only update the files in the package
sub-directories, but not the copies in the src folder.
with git <Install_git>`, this will only update the files in the package
subdirectories, but not the copies in the src folder.
Type ``make package-overwrite`` to overwrite files in the package
sub-directories with src files.
subdirectories with src files.
Type ``make package-diff`` to list all differences between pairs of
files in both the source directory and the package directory.

158
doc/src/Build_settings.rst
View File

@ -1,8 +1,8 @@
Optional build settings
=======================
LAMMPS can be built with several optional settings. Each sub-section
explain how to do this for building both with CMake and make.
LAMMPS can be built with several optional settings. Each subsection
explains how to do this for building both with CMake and make.
* `C++11 standard compliance`_ when building all of LAMMPS
* `FFT library`_ for use with the :doc:`kspace_style pppm <kspace_style>` command
@ -41,9 +41,17 @@ FFT library
When the KSPACE package is included in a LAMMPS build, the
:doc:`kspace_style pppm <kspace_style>` command performs 3d FFTs which
require use of an FFT library to compute 1d FFTs. The KISS FFT
library is included with LAMMPS but other libraries can be faster.
library is included with LAMMPS, but other libraries can be faster.
LAMMPS can use them if they are available on your system.
.. versionadded:: TBD
Alternatively, LAMMPS can use the `heFFTe
<https://icl-utk-edu.github.io/heffte/>`_ library for the MPI
communication algorithms, which comes with many optimizations for
special cases, e.g. leveraging available 2D and 3D FFTs in the back end
libraries and better pipelining for packing and communication.
.. tabs::
.. tab:: CMake build
@ -53,6 +61,7 @@ LAMMPS can use them if they are available on your system.
-D FFT=value # FFTW3 or MKL or KISS, default is FFTW3 if found, else KISS
-D FFT_SINGLE=value # yes or no (default), no = double precision
-D FFT_PACK=value # array (default) or pointer or memcpy
-D FFT_USE_HEFFTE=value # yes or no (default), yes links to heFFTe
.. note::
@ -63,9 +72,9 @@ LAMMPS can use them if they are available on your system.
Usually these settings are all that is needed. If FFTW3 is
selected, then CMake will try to detect, if threaded FFTW
libraries are available and enable them by default. This setting
is independent of whether OpenMP threads are enabled and a
packages like KOKKOS or OPENMP is used. If CMake cannot detect
the FFT library, you can set these variables to assist:
is independent of whether OpenMP threads are enabled and a package
like KOKKOS or OPENMP is used. If CMake cannot detect the FFT
library, you can set these variables to assist:
.. code-block:: bash
@ -76,6 +85,16 @@ LAMMPS can use them if they are available on your system.
-D MKL_INCLUDE_DIR=path # ditto for Intel MKL library
-D FFT_MKL_THREADS=on # enable using threaded FFTs with MKL libraries
-D MKL_LIBRARY=path # path to MKL libraries
-D FFT_HEFFTE_BACKEND=value # FFTW or MKL or empty/undefined for the stock heFFTe back end
-D Heffte_ROOT=path # path to an existing heFFTe installation
.. note::
heFFTe comes with a builtin (= stock) back end for FFTs, i.e. a
default internal FFT implementation; however, this stock back
end is intended for testing purposes only and is not optimized
for production runs.
.. tab:: Traditional make
@ -111,26 +130,43 @@ LAMMPS can use them if they are available on your system.
files in its default search path. You must specify ``FFT_LIB``
with the appropriate FFT libraries to include in the link.
The `KISS FFT library <http://kissfft.sf.net>`_ is included in the LAMMPS
distribution. It is portable across all platforms. Depending on the size
of the FFTs and the number of processors used, the other libraries listed
here can be faster.
Traditional make can also link to heFFTe using an existing installation
.. code-block:: make
include <path-to-heffte-installation>/share/heffte/HeffteMakefile.in
FFT_INC = -DFFT_HEFFTE -DFFT_HEFFTE_FFTW $(heffte_include)
FFT_PATH =
FFT_LIB = $(heffte_link) $(heffte_libs)
The heFFTe install path will contain `HeffteMakefile.in`.
which will define the `heffte_` include variables needed to link to heFFTe from
an external project using traditional make.
The `-DFFT_HEFFTE` is required to switch to using heFFTe, while the optional `-DFFT_HEFFTE_FFTW`
selects the desired heFFTe back end, e.g., `-DFFT_HEFFTE_FFTW` or `-DFFT_HEFFTE_MKL`,
omitting the variable will default to the `stock` back end.
The heFFTe `stock` back end is intended to be used for testing and debugging,
but is not performance optimized for large scale production runs.
The `KISS FFT library <https://github.com/mborgerding/kissfft>`_ is
included in the LAMMPS distribution. It is portable across all
platforms. Depending on the size of the FFTs and the number of
processors used, the other libraries listed here can be faster.
However, note that long-range Coulombics are only a portion of the
per-timestep CPU cost, FFTs are only a portion of long-range
Coulombics, and 1d FFTs are only a portion of the FFT cost (parallel
communication can be costly). A breakdown of these timings is printed
to the screen at the end of a run when using the
:doc:`kspace_style pppm <kspace_style>` command. The
:doc:`Screen and logfile output <Run_output>`
page gives more details. A more detailed (and time consuming)
report of the FFT performance is generated with the
per-timestep CPU cost, FFTs are only a portion of long-range Coulombics,
and 1d FFTs are only a portion of the FFT cost (parallel communication
can be costly). A breakdown of these timings is printed to the screen
at the end of a run when using the :doc:`kspace_style pppm
<kspace_style>` command. The :doc:`Screen and logfile output
<Run_output>` page gives more details. A more detailed (and time
consuming) report of the FFT performance is generated with the
:doc:`kspace_modify fftbench yes <kspace_modify>` command.
FFTW is a fast, portable FFT library that should also work on any
platform and can be faster than the KISS FFT library. You can
download it from `www.fftw.org <http://www.fftw.org>`_. LAMMPS requires
version 3.X; the legacy version 2.1.X is no longer supported.
platform and can be faster than the KISS FFT library. You can download
it from `www.fftw.org <https://www.fftw.org>`_. LAMMPS requires version
3.X; the legacy version 2.1.X is no longer supported.
Building FFTW for your box should be as simple as ``./configure; make;
make install``. The install command typically requires root privileges
@ -142,18 +178,18 @@ The Intel MKL math library is part of the Intel compiler suite. It
can be used with the Intel or GNU compiler (see the ``FFT_LIB`` setting
above).
Performing 3d FFTs in parallel can be time consuming due to data
access and required communication. This cost can be reduced by
performing single-precision FFTs instead of double precision. Single
precision means the real and imaginary parts of a complex datum are
4-byte floats. Double precision means they are 8-byte doubles. Note
that Fourier transform and related PPPM operations are somewhat less
sensitive to floating point truncation errors and thus the resulting
error is less than the difference in precision. Using the ``-DFFT_SINGLE``
setting trades off a little accuracy for reduced memory use and
parallel communication costs for transposing 3d FFT data.
Performing 3d FFTs in parallel can be time-consuming due to data access
and required communication. This cost can be reduced by performing
single-precision FFTs instead of double precision. Single precision
means the real and imaginary parts of a complex datum are 4-byte floats.
Double precision means they are 8-byte doubles. Note that Fourier
transform and related PPPM operations are somewhat less sensitive to
floating point truncation errors, and thus the resulting error is
generally less than the difference in precision. Using the
``-DFFT_SINGLE`` setting trades off a little accuracy for reduced memory
use and parallel communication costs for transposing 3d FFT data.
When using ``-DFFT_SINGLE`` with FFTW3 you may need to build the FFTW
When using ``-DFFT_SINGLE`` with FFTW3, you may need to build the FFTW
library a second time with support for single-precision.
For FFTW3, do the following, which should produce the additional
@ -171,6 +207,16 @@ Depending on the machine, the size of the FFT grid, the number of
processors used, one option may be slightly faster. The default is
ARRAY mode.
When using ``-DFFT_HEFFTE`` CMake will first look for an existing
install with hints provided by ``-DHeffte_ROOT``, as recommended by the
CMake standard and note that the name is case sensitive. If CMake cannot
find a heFFTe installation with the correct back end (e.g., FFTW or
MKL), it will attempt to download and build the library automatically.
In this case, LAMMPS CMake will also accept all heFFTe specific
variables listed in the `heFFTe documentation
<https://mkstoyanov.bitbucket.io/heffte/md_doxygen_installation.html>`_
and those variables will be passed into the heFFTe build.
----------
.. _size:
@ -178,11 +224,11 @@ ARRAY mode.
Size of LAMMPS integer types and size limits
--------------------------------------------
LAMMPS has a few integer data types which can be defined as either
4-byte (= 32-bit) or 8-byte (= 64-bit) integers at compile time.
This has an impact on the size of a system that can be simulated
or how large counters can become before "rolling over".
The default setting of "smallbig" is almost always adequate.
LAMMPS uses a few custom integer data types, which can be defined as
either 4-byte (= 32-bit) or 8-byte (= 64-bit) integers at compile time.
This has an impact on the size of a system that can be simulated, or how
large counters can become before "rolling over". The default setting of
"smallbig" is almost always adequate.
.. tabs::
@ -255,7 +301,7 @@ topology information, though IDs are enabled by default. The
:doc:`atom_modify id no <atom_modify>` command will turn them off. Atom
IDs are required for molecular systems with bond topology (bonds,
angles, dihedrals, etc). Similarly, some force or compute or fix styles
require atom IDs. Thus if you model a molecular system or use one of
require atom IDs. Thus, if you model a molecular system or use one of
those styles with more than 2 billion atoms, you need the "bigbig"
setting.
@ -265,7 +311,7 @@ systems and 500 million for systems with bonds (the additional
restriction is due to using the 2 upper bits of the local atom index
in neighbor lists for storing special bonds info).
Image flags store 3 values per atom in a single integer which count the
Image flags store 3 values per atom in a single integer, which count the
number of times an atom has moved through the periodic box in each
dimension. See the :doc:`dump <dump>` manual page for a discussion. If
an atom moves through the periodic box more than this limit, the value
@ -286,7 +332,7 @@ 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
PNG image files. Likewise, the :doc:`dump movie <dump_image>` command
outputs movie files in a variety of movie formats. Using these options
requires the following settings:
@ -355,7 +401,7 @@ Read or write compressed files
If this option is enabled, large files can be read or written with
compression by ``gzip`` or similar tools by several LAMMPS commands,
including :doc:`read_data <read_data>`, :doc:`rerun <rerun>`, and
:doc:`dump <dump>`. Currently supported compression tools are:
:doc:`dump <dump>`. Supported compression tools are currently
``gzip``, ``bzip2``, ``zstd``, and ``lzma``.
.. tabs::
@ -395,7 +441,7 @@ Memory allocation alignment
---------------------------------------
This setting enables the use of the "posix_memalign()" call instead of
"malloc()" when LAMMPS allocates large chunks or memory. Vector
"malloc()" when LAMMPS allocates large chunks of memory. Vector
instructions on CPUs may become more efficient, if dynamically allocated
memory is aligned on larger-than-default byte boundaries. On most
current operating systems, the "malloc()" implementation returns
@ -460,27 +506,13 @@ those systems:
.. _exceptions:
Exception handling when using LAMMPS as a library
------------------------------------------------------------------
-------------------------------------------------
This setting is useful when external codes drive LAMMPS as a library.
With this option enabled, LAMMPS errors do not kill the calling code.
Instead, the call stack is unwound and control returns to the caller,
e.g. to Python. Of course, the calling code has to be set up to
*catch* exceptions thrown from within LAMMPS.
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D LAMMPS_EXCEPTIONS=value # yes or no (default)
.. tab:: Traditional make
.. code-block:: make
LMP_INC = -DLAMMPS_EXCEPTIONS <other LMP_INC settings>
LAMMPS errors do not kill the calling code, but throw an exception. In
the C-library interface, the call stack is unwound and control returns
to the caller, e.g. to Python or a code that is coupled to LAMMPS. The
error status can then be queried. When using C++ directly, the calling
code has to be set up to *catch* exceptions thrown from within LAMMPS.
.. note::
@ -497,7 +529,7 @@ Trigger selected floating-point exceptions
------------------------------------------
Many kinds of CPUs have the capability to detect when a calculation
results in an invalid math operation like a division by zero or calling
results in an invalid math operation, like a division by zero or calling
the square root with a negative argument. The default behavior on
most operating systems is to continue and have values for ``NaN`` (= not
a number) or ``Inf`` (= infinity). This allows software to detect and

7
doc/src/Commands_all.rst
View File

@ -24,6 +24,7 @@ table above.
* :doc:`angle_coeff <angle_coeff>`
* :doc:`angle_style <angle_style>`
* :doc:`angle_write <angle_write>`
* :doc:`atom_modify <atom_modify>`
* :doc:`atom_style <atom_style>`
* :doc:`balance <balance>`
@ -31,7 +32,6 @@ table above.
* :doc:`bond_style <bond_style>`
* :doc:`bond_write <bond_write>`
* :doc:`boundary <boundary>`
* :doc:`box <box>`
* :doc:`change_box <change_box>`
* :doc:`clear <clear>`
* :doc:`comm_modify <comm_modify>`
@ -46,6 +46,7 @@ table above.
* :doc:`dielectric <dielectric>`
* :doc:`dihedral_coeff <dihedral_coeff>`
* :doc:`dihedral_style <dihedral_style>`
* :doc:`dihedral_write <dihedral_write>`
* :doc:`dimension <dimension>`
* :doc:`displace_atoms <displace_atoms>`
* :doc:`dump <dump>`
@ -90,8 +91,7 @@ table above.
* :doc:`region <region>`
* :doc:`replicate <replicate>`
* :doc:`rerun <rerun>`
* :doc:`reset_atom_ids <reset_atom_ids>`
* :doc:`reset_mol_ids <reset_mol_ids>`
* :doc:`reset_atoms <reset_atoms>`
* :doc:`reset_timestep <reset_timestep>`
* :doc:`restart <restart>`
* :doc:`run <run>`
@ -127,6 +127,7 @@ additional letter in parenthesis: k = KOKKOS.
* :doc:`group2ndx <group2ndx>`
* :doc:`hyper <hyper>`
* :doc:`kim <kim_commands>`
* :doc:`fitpod <fitpod_command>`
* :doc:`mdi <mdi>`
* :doc:`ndx2group <group2ndx>`
* :doc:`neb <neb>`

4
doc/src/Commands_bond.rst
View File

@ -42,8 +42,10 @@ OPT.
* :doc:`gaussian <bond_gaussian>`
* :doc:`gromos (o) <bond_gromos>`
* :doc:`harmonic (iko) <bond_harmonic>`
* :doc:`harmonic/restrain <bond_harmonic_restrain>`
* :doc:`harmonic/shift (o) <bond_harmonic_shift>`
* :doc:`harmonic/shift/cut (o) <bond_harmonic_shift_cut>`
* :doc:`lepton (o) <bond_lepton>`
* :doc:`mesocnt <bond_mesocnt>`
* :doc:`mm3 <bond_mm3>`
* :doc:`morse (o) <bond_morse>`
@ -93,6 +95,7 @@ OPT.
* :doc:`fourier/simple (o) <angle_fourier_simple>`
* :doc:`gaussian <angle_gaussian>`
* :doc:`harmonic (iko) <angle_harmonic>`
* :doc:`lepton (o) <angle_lepton>`
* :doc:`mesocnt <angle_mesocnt>`
* :doc:`mm3 <angle_mm3>`
* :doc:`quartic (o) <angle_quartic>`
@ -127,6 +130,7 @@ OPT.
* :doc:`fourier (io) <dihedral_fourier>`
* :doc:`harmonic (iko) <dihedral_harmonic>`
* :doc:`helix (o) <dihedral_helix>`
* :doc:`lepton (o) <dihedral_lepton>`
* :doc:`multi/harmonic (o) <dihedral_multi_harmonic>`
* :doc:`nharmonic (o) <dihedral_nharmonic>`
* :doc:`opls (iko) <dihedral_opls>`

1
doc/src/Commands_category.rst
View File

@ -25,7 +25,6 @@ Setup simulation box:
:columns: 4
* :doc:`boundary <boundary>`
* :doc:`box <box>`
* :doc:`change_box <change_box>`
* :doc:`create_box <create_box>`
* :doc:`dimension <dimension>`

19
doc/src/Commands_compute.rst
View File

@ -46,21 +46,25 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`com/chunk <compute_com_chunk>`
* :doc:`contact/atom <compute_contact_atom>`
* :doc:`coord/atom (k) <compute_coord_atom>`
* :doc:`count/type <compute_count_type>`
* :doc:`damage/atom <compute_damage_atom>`
* :doc:`dihedral <compute_dihedral>`
* :doc:`dihedral/local <compute_dihedral_local>`
* :doc:`dilatation/atom <compute_dilatation_atom>`
* :doc:`dipole <compute_dipole>`
* :doc:`dipole/chunk <compute_dipole_chunk>`
* :doc:`dipole/tip4p <compute_dipole>`
* :doc:`dipole/tip4p/chunk <compute_dipole_chunk>`
* :doc:`displace/atom <compute_displace_atom>`
* :doc:`dpd <compute_dpd>`
* :doc:`dpd/atom <compute_dpd_atom>`
* :doc:`edpd/temp/atom <compute_edpd_temp_atom>`
* :doc:`efield/atom <compute_efield_atom>`
* :doc:`efield/wolf/atom <compute_efield_wolf_atom>`
* :doc:`entropy/atom <compute_entropy_atom>`
* :doc:`erotate/asphere <compute_erotate_asphere>`
* :doc:`erotate/rigid <compute_erotate_rigid>`
* :doc:`erotate/sphere <compute_erotate_sphere>`
* :doc:`erotate/sphere (k) <compute_erotate_sphere>`
* :doc:`erotate/sphere/atom <compute_erotate_sphere_atom>`
* :doc:`event/displace <compute_event_displace>`
* :doc:`fabric <compute_fabric>`
@ -87,7 +91,7 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`ke/atom/eff <compute_ke_atom_eff>`
* :doc:`ke/eff <compute_ke_eff>`
* :doc:`ke/rigid <compute_ke_rigid>`
* :doc:`mesont <compute_mesont>`
* :doc:`composition/atom (k) <compute_composition_atom>`
* :doc:`mliap <compute_mliap>`
* :doc:`momentum <compute_momentum>`
* :doc:`msd <compute_msd>`
@ -96,6 +100,7 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`nbond/atom <compute_nbond_atom>`
* :doc:`omega/chunk <compute_omega_chunk>`
* :doc:`orientorder/atom (k) <compute_orientorder_atom>`
* :doc:`pace <compute_pace>`
* :doc:`pair <compute_pair>`
* :doc:`pair/local <compute_pair_local>`
* :doc:`pe <compute_pe>`
@ -104,17 +109,21 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`pe/tally <compute_tally>`
* :doc:`plasticity/atom <compute_plasticity_atom>`
* :doc:`pressure <compute_pressure>`
* :doc:`pressure/alchemy <compute_pressure_alchemy>`
* :doc:`pressure/uef <compute_pressure_uef>`
* :doc:`property/atom <compute_property_atom>`
* :doc:`property/chunk <compute_property_chunk>`
* :doc:`property/grid <compute_property_grid>`
* :doc:`property/local <compute_property_local>`
* :doc:`ptm/atom <compute_ptm_atom>`
* :doc:`rattlers/atom <compute_rattlers_atom>`
* :doc:`rdf <compute_rdf>`
* :doc:`reduce <compute_reduce>`
* :doc:`reduce/chunk <compute_reduce_chunk>`
* :doc:`reduce/region <compute_reduce>`
* :doc:`rigid/local <compute_rigid_local>`
* :doc:`saed <compute_saed>`
* :doc:`slcsa/atom <compute_slcsa_atom>`
* :doc:`slice <compute_slice>`
* :doc:`smd/contact/radius <compute_smd_contact_radius>`
* :doc:`smd/damage <compute_smd_damage>`
@ -148,11 +157,11 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`sph/t/atom <compute_sph_t_atom>`
* :doc:`spin <compute_spin>`
* :doc:`stress/atom <compute_stress_atom>`
* :doc:`stress/cartesian <compute_stress_profile>`
* :doc:`stress/cylinder <compute_stress_profile>`
* :doc:`stress/cartesian <compute_stress_cartesian>`
* :doc:`stress/cylinder <compute_stress_curvilinear>`
* :doc:`stress/mop <compute_stress_mop>`
* :doc:`stress/mop/profile <compute_stress_mop>`
* :doc:`stress/spherical <compute_stress_profile>`
* :doc:`stress/spherical <compute_stress_curvilinear>`
* :doc:`stress/tally <compute_tally>`
* :doc:`tdpd/cc/atom <compute_tdpd_cc_atom>`
* :doc:`temp (k) <compute_temp>`

7
doc/src/Commands_dump.rst
View File

@ -23,20 +23,18 @@ An alphabetic list of all LAMMPS :doc:`dump <dump>` commands.
* :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:`grid <dump>`
* :doc:`grid/vtk <dump>`
* :doc:`h5md <dump_h5md>`
* :doc:`image <dump_image>`
* :doc:`local <dump>`
@ -50,7 +48,6 @@ An alphabetic list of all LAMMPS :doc:`dump <dump>` commands.
* :doc:`xtc <dump>`
* :doc:`xyz <dump>`
* :doc:`xyz/gz <dump>`
* :doc:`xyz/mpiio <dump>`
* :doc:`xyz/zstd <dump>`
* :doc:`yaml <dump>`

41
doc/src/Commands_fix.rst
View File

@ -29,6 +29,7 @@ OPT.
* :doc:`adapt/fep <fix_adapt_fep>`
* :doc:`addforce <fix_addforce>`
* :doc:`addtorque <fix_addtorque>`
* :doc:`alchemy <fix_alchemy>`
* :doc:`amoeba/bitorsion <fix_amoeba_bitorsion>`
* :doc:`amoeba/pitorsion <fix_amoeba_pitorsion>`
* :doc:`append/atoms <fix_append_atoms>`
@ -38,14 +39,12 @@ OPT.
* :doc:`ave/chunk <fix_ave_chunk>`
* :doc:`ave/correlate <fix_ave_correlate>`
* :doc:`ave/correlate/long <fix_ave_correlate_long>`
* :doc:`ave/grid <fix_ave_grid>`
* :doc:`ave/histo <fix_ave_histo>`
* :doc:`ave/histo/weight <fix_ave_histo>`
* :doc:`ave/time <fix_ave_time>`
* :doc:`aveforce <fix_aveforce>`
* :doc:`balance <fix_balance>`
* :doc:`brownian <fix_brownian>`
* :doc:`brownian/asphere <fix_brownian>`
* :doc:`brownian/sphere <fix_brownian>`
* :doc:`bocs <fix_bocs>`
* :doc:`bond/break <fix_bond_break>`
* :doc:`bond/create <fix_bond_create>`
@ -53,6 +52,9 @@ OPT.
* :doc:`bond/react <fix_bond_react>`
* :doc:`bond/swap <fix_bond_swap>`
* :doc:`box/relax <fix_box_relax>`
* :doc:`brownian <fix_brownian>`
* :doc:`brownian/asphere <fix_brownian>`
* :doc:`brownian/sphere <fix_brownian>`
* :doc:`charge/regulation <fix_charge_regulation>`
* :doc:`cmap <fix_cmap>`
* :doc:`colvars <fix_colvars>`
@ -65,13 +67,14 @@ OPT.
* :doc:`drude <fix_drude>`
* :doc:`drude/transform/direct <fix_drude_transform>`
* :doc:`drude/transform/inverse <fix_drude_transform>`
* :doc:`dt/reset <fix_dt_reset>`
* :doc:`dt/reset (k) <fix_dt_reset>`
* :doc:`edpd/source <fix_dpd_source>`
* :doc:`efield <fix_efield>`
* :doc:`efield (k) <fix_efield>`
* :doc:`efield/tip4p <fix_efield>`
* :doc:`ehex <fix_ehex>`
* :doc:`electrode/conp (i) <fix_electrode_conp>`
* :doc:`electrode/conq (i) <fix_electrode_conp>`
* :doc:`electrode/thermo (i) <fix_electrode_conp>`
* :doc:`electrode/conp (i) <fix_electrode>`
* :doc:`electrode/conq (i) <fix_electrode>`
* :doc:`electrode/thermo (i) <fix_electrode>`
* :doc:`electron/stopping <fix_electron_stopping>`
* :doc:`electron/stopping/fit <fix_electron_stopping>`
* :doc:`enforce2d (k) <fix_enforce2d>`
@ -91,6 +94,7 @@ OPT.
* :doc:`grem <fix_grem>`
* :doc:`halt <fix_halt>`
* :doc:`heat <fix_heat>`
* :doc:`heat/flow <fix_heat_flow>`
* :doc:`hyper/global <fix_hyper_global>`
* :doc:`hyper/local <fix_hyper_local>`
* :doc:`imd <fix_imd>`
@ -100,25 +104,25 @@ OPT.
* :doc:`langevin/drude <fix_langevin_drude>`
* :doc:`langevin/eff <fix_langevin_eff>`
* :doc:`langevin/spin <fix_langevin_spin>`
* :doc:`latte <fix_latte>`
* :doc:`lb/fluid <fix_lb_fluid>`
* :doc:`lb/momentum <fix_lb_momentum>`
* :doc:`lb/viscous <fix_lb_viscous>`
* :doc:`lineforce <fix_lineforce>`
* :doc:`manifoldforce <fix_manifoldforce>`
* :doc:`mdi/qm <fix_mdi_qm>`
* :doc:`mdi/qmmm <fix_mdi_qmmm>`
* :doc:`meso/move <fix_meso_move>`
* :doc:`mol/swap <fix_mol_swap>`
* :doc:`momentum (k) <fix_momentum>`
* :doc:`momentum/chunk <fix_momentum>`
* :doc:`move <fix_move>`
* :doc:`mscg <fix_mscg>`
* :doc:`msst <fix_msst>`
* :doc:`mvv/dpd <fix_mvv_dpd>`
* :doc:`mvv/edpd <fix_mvv_dpd>`
* :doc:`mvv/tdpd <fix_mvv_dpd>`
* :doc:`neb <fix_neb>`
* :doc:`neb/spin <fix_neb_spin>`
* :doc:`nonaffine/displacement <fix_nonaffine_displacement>`
* :doc:`nph (ko) <fix_nh>`
* :doc:`nph/asphere (o) <fix_nph_asphere>`
* :doc:`nph/body <fix_nph_body>`
@ -167,7 +171,8 @@ OPT.
* :doc:`pafi <fix_pafi>`
* :doc:`pair <fix_pair>`
* :doc:`phonon <fix_phonon>`
* :doc:`pimd <fix_pimd>`
* :doc:`pimd/langevin <fix_pimd>`
* :doc:`pimd/nvt <fix_pimd>`
* :doc:`planeforce <fix_planeforce>`
* :doc:`plumed <fix_plumed>`
* :doc:`poems <fix_poems>`
@ -177,6 +182,7 @@ OPT.
* :doc:`pour <fix_pour>`
* :doc:`precession/spin <fix_precession_spin>`
* :doc:`press/berendsen <fix_press_berendsen>`
* :doc:`press/langevin <fix_press_langevin>`
* :doc:`print <fix_print>`
* :doc:`propel/self <fix_propel_self>`
* :doc:`property/atom (k) <fix_property_atom>`
@ -213,6 +219,7 @@ OPT.
* :doc:`saed/vtk <fix_saed_vtk>`
* :doc:`setforce (k) <fix_setforce>`
* :doc:`setforce/spin <fix_setforce>`
* :doc:`sgcmc <fix_sgcmc>`
* :doc:`shake (k) <fix_shake>`
* :doc:`shardlow (k) <fix_shardlow>`
* :doc:`smd <fix_smd>`
@ -227,15 +234,15 @@ OPT.
* :doc:`spring <fix_spring>`
* :doc:`spring/chunk <fix_spring_chunk>`
* :doc:`spring/rg <fix_spring_rg>`
* :doc:`spring/self <fix_spring_self>`
* :doc:`spring/self (k) <fix_spring_self>`
* :doc:`srd <fix_srd>`
* :doc:`store/force <fix_store_force>`
* :doc:`store/state <fix_store_state>`
* :doc:`tdpd/source <fix_dpd_source>`
* :doc:`temp/berendsen <fix_temp_berendsen>`
* :doc:`temp/berendsen (k) <fix_temp_berendsen>`
* :doc:`temp/csld <fix_temp_csvr>`
* :doc:`temp/csvr <fix_temp_csvr>`
* :doc:`temp/rescale <fix_temp_rescale>`
* :doc:`temp/rescale (k) <fix_temp_rescale>`
* :doc:`temp/rescale/eff <fix_temp_rescale_eff>`
* :doc:`tfmc <fix_tfmc>`
* :doc:`tgnpt/drude <fix_tgnh_drude>`
@ -249,18 +256,19 @@ OPT.
* :doc:`tune/kspace <fix_tune_kspace>`
* :doc:`vector <fix_vector>`
* :doc:`viscosity <fix_viscosity>`
* :doc:`viscous <fix_viscous>`
* :doc:`viscous (k) <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>`
* :doc:`wall/ees <fix_wall_ees>`
* :doc:`wall/gran <fix_wall_gran>`
* :doc:`wall/gran (k) <fix_wall_gran>`
* :doc:`wall/gran/region <fix_wall_gran_region>`
* :doc:`wall/harmonic <fix_wall>`
* :doc:`wall/lj1043 <fix_wall>`
* :doc:`wall/lj126 <fix_wall>`
* :doc:`wall/lj93 (k) <fix_wall>`
* :doc:`wall/lepton <fix_wall>`
* :doc:`wall/morse <fix_wall>`
* :doc:`wall/piston <fix_wall_piston>`
* :doc:`wall/reflect (k) <fix_wall_reflect>`
@ -268,4 +276,5 @@ OPT.
* :doc:`wall/region <fix_wall_region>`
* :doc:`wall/region/ees <fix_wall_ees>`
* :doc:`wall/srd <fix_wall_srd>`
* :doc:`wall/table <fix_wall>`
* :doc:`widom <fix_widom>`

49
doc/src/Commands_pair.rst
View File

@ -37,9 +37,10 @@ OPT.
*
* :doc:`adp (ko) <pair_adp>`
* :doc:`agni (o) <pair_agni>`
* :doc:`aip/water/2dm (t) <pair_aip_water_2dm>`
* :doc:`airebo (io) <pair_airebo>`
* :doc:`airebo/morse (io) <pair_airebo>`
* :doc:`amoeba <pair_amoeba>`
* :doc:`amoeba (g) <pair_amoeba>`
* :doc:`atm <pair_atm>`
* :doc:`awpmd/cut <pair_awpmd>`
* :doc:`beck (go) <pair_beck>`
@ -55,6 +56,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:`born/gauss <pair_born_gauss>`
* :doc:`bpm/spring <pair_bpm_spring>`
* :doc:`brownian (o) <pair_brownian>`
* :doc:`brownian/poly (o) <pair_brownian>`
@ -85,7 +87,7 @@ OPT.
* :doc:`coul/long/soft (o) <pair_fep_soft>`
* :doc:`coul/msm (o) <pair_coul>`
* :doc:`coul/slater/cut <pair_coul_slater>`
* :doc:`coul/slater/long <pair_coul_slater>`
* :doc:`coul/slater/long (g) <pair_coul_slater>`
* :doc:`coul/shield <pair_coul_shield>`
* :doc:`coul/streitz <pair_coul>`
* :doc:`coul/tt <pair_coul_tt>`
@ -93,8 +95,8 @@ OPT.
* :doc:`coul/wolf/cs <pair_cs>`
* :doc:`dpd (giko) <pair_dpd>`
* :doc:`dpd/fdt <pair_dpd_fdt>`
* :doc:`dpd/ext (k) <pair_dpd_ext>`
* :doc:`dpd/ext/tstat (k) <pair_dpd_ext>`
* :doc:`dpd/ext (ko) <pair_dpd_ext>`
* :doc:`dpd/ext/tstat (ko) <pair_dpd_ext>`
* :doc:`dpd/fdt/energy (k) <pair_dpd_fdt>`
* :doc:`dpd/tstat (gko) <pair_dpd>`
* :doc:`dsmc <pair_dsmc>`
@ -108,7 +110,7 @@ OPT.
* :doc:`eam/he <pair_eam>`
* :doc:`edip (o) <pair_edip>`
* :doc:`edip/multi <pair_edip>`
* :doc:`edpd <pair_mesodpd>`
* :doc:`edpd (g) <pair_mesodpd>`
* :doc:`eff/cut <pair_eff>`
* :doc:`eim (o) <pair_eim>`
* :doc:`exp6/rx (k) <pair_exp6_rx>`
@ -126,7 +128,7 @@ OPT.
* :doc:`hbond/dreiding/lj (o) <pair_hbond_dreiding>`
* :doc:`hbond/dreiding/morse (o) <pair_hbond_dreiding>`
* :doc:`hdnnp <pair_hdnnp>`
* :doc:`hippo <pair_amoeba>`
* :doc:`hippo (g) <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>`
@ -134,6 +136,9 @@ OPT.
* :doc:`lcbop <pair_lcbop>`
* :doc:`lebedeva/z <pair_lebedeva_z>`
* :doc:`lennard/mdf <pair_mdf>`
* :doc:`lepton (o) <pair_lepton>`
* :doc:`lepton/coul (o) <pair_lepton>`
* :doc:`lepton/sphere (o) <pair_lepton>`
* :doc:`line/lj <pair_line_lj>`
* :doc:`lj/charmm/coul/charmm (giko) <pair_charmm>`
* :doc:`lj/charmm/coul/charmm/implicit (ko) <pair_charmm>`
@ -153,27 +158,29 @@ OPT.
* :doc:`lj/cut (gikot) <pair_lj>`
* :doc:`lj/cut/coul/cut (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/cut/dielectric (o) <pair_dielectric>`
* :doc:`lj/cut/coul/cut/soft (o) <pair_fep_soft>`
* :doc:`lj/cut/coul/cut/soft (go) <pair_fep_soft>`
* :doc:`lj/cut/coul/debye (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/debye/dielectric (o) <pair_dielectric>`
* :doc:`lj/cut/coul/dsf (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/long (gikot) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/long/cs <pair_cs>`
* :doc:`lj/cut/coul/long/dielectric (o) <pair_dielectric>`
* :doc:`lj/cut/coul/long/soft (o) <pair_fep_soft>`
* :doc:`lj/cut/coul/long/soft (go) <pair_fep_soft>`
* :doc:`lj/cut/coul/msm (go) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/msm/dielectric <pair_dielectric>`
* :doc:`lj/cut/coul/wolf (o) <pair_lj_cut_coul>`
* :doc:`lj/cut/dipole/cut (go) <pair_dipole>`
* :doc:`lj/cut/dipole/cut (gko) <pair_dipole>`
* :doc:`lj/cut/dipole/long (g) <pair_dipole>`
* :doc:`lj/cut/dipole/sf (go) <pair_dipole>`
* :doc:`lj/cut/soft (o) <pair_fep_soft>`
* :doc:`lj/cut/sphere (o) <pair_lj_cut_sphere>`
* :doc:`lj/cut/thole/long (o) <pair_thole>`
* :doc:`lj/cut/tip4p/cut (o) <pair_lj_cut_tip4p>`
* :doc:`lj/cut/tip4p/long (got) <pair_lj_cut_tip4p>`
* :doc:`lj/cut/tip4p/long/soft (o) <pair_fep_soft>`
* :doc:`lj/expand (gko) <pair_lj_expand>`
* :doc:`lj/expand/coul/long (g) <pair_lj_expand>`
* :doc:`lj/expand/coul/long (gk) <pair_lj_expand>`
* :doc:`lj/expand/sphere (o) <pair_lj_expand_sphere>`
* :doc:`lj/gromacs (gko) <pair_gromacs>`
* :doc:`lj/gromacs/coul/gromacs (ko) <pair_gromacs>`
* :doc:`lj/long/coul/long (iot) <pair_lj_long>`
@ -195,17 +202,17 @@ OPT.
* :doc:`lubricate/poly (o) <pair_lubricate>`
* :doc:`lubricateU <pair_lubricateU>`
* :doc:`lubricateU/poly <pair_lubricateU>`
* :doc:`mdpd <pair_mesodpd>`
* :doc:`mdpd (g) <pair_mesodpd>`
* :doc:`mdpd/rhosum <pair_mesodpd>`
* :doc:`meam (k) <pair_meam>`
* :doc:`meam/ms (k) <pair_meam>`
* :doc:`meam/spline (o) <pair_meam_spline>`
* :doc:`meam/sw/spline <pair_meam_sw_spline>`
* :doc:`mesocnt <pair_mesocnt>`
* :doc:`mesocnt/viscous <pair_mesocnt>`
* :doc:`mesont/tpm <pair_mesont_tpm>`
* :doc:`mgpt <pair_mgpt>`
* :doc:`mie/cut (g) <pair_mie>`
* :doc:`mliap <pair_mliap>`
* :doc:`mliap (k) <pair_mliap>`
* :doc:`mm3/switch3/coulgauss/long <pair_lj_switch3_coulgauss_long>`
* :doc:`momb <pair_momb>`
* :doc:`morse (gkot) <pair_morse>`
@ -213,7 +220,8 @@ OPT.
* :doc:`morse/soft <pair_fep_soft>`
* :doc:`multi/lucy <pair_multi_lucy>`
* :doc:`multi/lucy/rx (k) <pair_multi_lucy_rx>`
* :doc:`nb3b/harmonic <pair_nb3b_harmonic>`
* :doc:`nb3b/harmonic <pair_nb3b>`
* :doc:`nb3b/screened <pair_nb3b>`
* :doc:`nm/cut (o) <pair_nm>`
* :doc:`nm/cut/coul/cut (o) <pair_nm>`
* :doc:`nm/cut/coul/long (o) <pair_nm>`
@ -236,6 +244,8 @@ OPT.
* :doc:`oxrna2/xstk <pair_oxrna2>`
* :doc:`oxrna2/coaxstk <pair_oxrna2>`
* :doc:`pace (k) <pair_pace>`
* :doc:`pace/extrapolation (k) <pair_pace>`
* :doc:`pod <pair_pod>`
* :doc:`peri/eps <pair_peri>`
* :doc:`peri/lps (o) <pair_peri>`
* :doc:`peri/pmb (o) <pair_peri>`
@ -256,13 +266,13 @@ OPT.
* :doc:`smd/tri_surface <pair_smd_triangulated_surface>`
* :doc:`smd/ulsph <pair_smd_ulsph>`
* :doc:`smtbq <pair_smtbq>`
* :doc:`snap (k) <pair_snap>`
* :doc:`snap (ik) <pair_snap>`
* :doc:`soft (go) <pair_soft>`
* :doc:`sph/heatconduction <pair_sph_heatconduction>`
* :doc:`sph/heatconduction (g) <pair_sph_heatconduction>`
* :doc:`sph/idealgas <pair_sph_idealgas>`
* :doc:`sph/lj <pair_sph_lj>`
* :doc:`sph/lj (g) <pair_sph_lj>`
* :doc:`sph/rhosum <pair_sph_rhosum>`
* :doc:`sph/taitwater <pair_sph_taitwater>`
* :doc:`sph/taitwater (g) <pair_sph_taitwater>`
* :doc:`sph/taitwater/morris <pair_sph_taitwater_morris>`
* :doc:`spin/dipole/cut <pair_spin_dipole>`
* :doc:`spin/dipole/long <pair_spin_dipole>`
@ -294,6 +304,7 @@ OPT.
* :doc:`vashishta (gko) <pair_vashishta>`
* :doc:`vashishta/table (o) <pair_vashishta>`
* :doc:`wf/cut <pair_wf_cut>`
* :doc:`ylz <pair_ylz>`
* :doc:`yukawa (gko) <pair_yukawa>`
* :doc:`yukawa/colloid (go) <pair_yukawa_colloid>`
* :doc:`yukawa/colloid (gko) <pair_yukawa_colloid>`
* :doc:`zbl (gko) <pair_zbl>`

127
doc/src/Commands_removed.rst
View File

@ -2,14 +2,17 @@ Removed commands and packages
=============================
This page lists LAMMPS commands and packages that have been removed from
the distribution and provides suggestions for alternatives or replacements.
LAMMPS has special dummy styles implemented, that will stop LAMMPS and
print a suitable error message in most cases, when a style/command is used
that has been removed.
the distribution and provides suggestions for alternatives or
replacements. LAMMPS has special dummy styles implemented, that will
stop LAMMPS and print a suitable error message in most cases, when a
style/command is used that has been removed or will replace the command
with the direct alternative (if available) and print a warning.
Fix ave/spatial and fix ave/spatial/sphere
------------------------------------------
.. deprecated:: 11Dec2015
The fixes ave/spatial and ave/spatial/sphere have been removed from LAMMPS
since they were superseded by the more general and extensible "chunk
infrastructure". Here the system is partitioned in one of many possible
@ -17,10 +20,37 @@ ways through the :doc:`compute chunk/atom <compute_chunk_atom>` command
and then averaging is done using :doc:`fix ave/chunk <fix_ave_chunk>`.
Please refer to the :doc:`chunk HOWTO <Howto_chunk>` section for an overview.
Reset_ids command
-----------------
Box command
-----------
The reset_ids command has been renamed to :doc:`reset_atom_ids <reset_atom_ids>`.
.. deprecated:: 22Dec2022
The *box* command has been removed and the LAMMPS code changed so it won't
be needed. If present, LAMMPS will ignore the command and print a warning.
Reset_ids, reset_atom_ids, reset_mol_ids commands
-------------------------------------------------
.. deprecated:: 22Dec2022
The *reset_ids*, *reset_atom_ids*, and *reset_mol_ids* commands have
been folded into the :doc:`reset_atoms <reset_atoms>` command. If
present, LAMMPS will replace the commands accordingly and print a
warning.
LATTE package
-------------
.. deprecated:: 15Jun2023
The LATTE package with the fix latte command was removed from LAMMPS.
This functionality has been superseded by :doc:`fix mdi/qm <fix_mdi_qm>`
and :doc:`fix mdi/qmmm <fix_mdi_qmmm>` from the :ref:`MDI package
<PKG-MDI>`. These fixes are compatible with several quantum software
packages, including LATTE. See the ``examples/QUANTUM`` dir and the
:doc:`MDI coupling HOWTO <Howto_mdi>` page. MDI supports running LAMMPS
with LATTE as a plugin library (similar to the way fix latte worked), as
well as on a different set of MPI processors.
MEAM package
------------
@ -30,18 +60,82 @@ The code in the :ref:`MEAM package <PKG-MEAM>` is a translation of the
Fortran code of MEAM into C++, which removes several restrictions
(e.g. there can be multiple instances in hybrid pair styles) and allows
for some optimizations leading to better performance. The pair style
:doc:`meam <pair_meam>` has the exact same syntax.
:doc:`meam <pair_meam>` has the exact same syntax. For a transition
period the C++ version of MEAM was called USER-MEAMC so it could
coexist with the Fortran version.
Minimize style fire/old
-----------------------
.. deprecated:: 8Feb2023
Minimize style *fire/old* has been removed. Its functionality can be
reproduced with *fire* with specific options. Please see the
:doc:`min_modify command <min_modify>` documentation for details.
Pair style mesont/tpm, compute style mesont, atom style mesont
--------------------------------------------------------------
.. deprecated:: 8Feb2023
Pair style *mesont/tpm*, compute style *mesont*, and atom style
*mesont* have been removed from the :ref:`MESONT package <PKG-MESONT>`.
The same functionality is available through
:doc:`pair style mesocnt <pair_mesocnt>`,
:doc:`bond style mesocnt <bond_mesocnt>` and
:doc:`angle style mesocnt <angle_mesocnt>`.
MPIIO package
-------------
.. deprecated:: 21Nov2023
The MPIIO package has been removed from LAMMPS since it was unmaintained
for many years and thus not updated to incorporate required changes that
had been applied to the corresponding non-MPIIO commands. As a
consequence the MPIIO commands had become unreliable and sometimes
crashing LAMMPS or corrupting data. Similar functionality is available
through the :ref:`ADIOS package <PKG-ADIOS>` and the :ref:`NETCDF
package <PKG-NETCDF>`. Also, the :doc:`dump_modify nfile or dump_modify
fileper <dump_modify>` keywords may be used for an efficient way of
writing out dump files when running on large numbers of processors.
Similarly, the "nfile" and "fileper" keywords exist for restarts:
see :doc:`restart <restart>`, :doc:`read_restart <read_restart>`,
:doc:`write_restart <write_restart>`.
MSCG package
------------
.. deprecated:: 21Nov2023
The MSCG package has been removed from LAMMPS since it was unmaintained
for many years and instead superseded by the `OpenMSCG software
<https://software.rcc.uchicago.edu/mscg/>`_ of the Voth group at the
University of Chicago, which can be used independent from LAMMPS.
REAX package
------------
The REAX package has been removed since it was superseded by the
:ref:`REAXFF package <PKG-REAXFF>`. The REAXFF
package has been tested to yield equivalent results to the REAX package,
offers better performance, supports OpenMP multi-threading via OPENMP,
and GPU and threading parallelization through KOKKOS. The new pair styles
are not syntax compatible with the removed reax pair style, so input
files will have to be adapted.
:ref:`REAXFF package <PKG-REAXFF>`. The REAXFF package has been tested
to yield equivalent results to the REAX package, offers better
performance, supports OpenMP multi-threading via OPENMP, and GPU and
threading parallelization through KOKKOS. The new pair styles are not
syntax compatible with the removed reax pair style, so input files will
have to be adapted. The REAXFF package was originally called
USER-REAXC.
USER-REAXC package
------------------
.. deprecated:: TBD
The USER-REAXC package has been renamed to :ref:`REAXFF <PKG-REAXFF>`.
In the process also the pair style and related fixes were renamed to use
the "reaxff" string instead of "reax/c". For a while LAMMPS was maintaining
backward compatibility by providing aliases for the styles. These have
been removed, so using "reaxff" is now *required*.
USER-CUDA package
-----------------
@ -60,5 +154,6 @@ restart2data tool
The functionality of the restart2data tool has been folded into the
LAMMPS executable directly instead of having a separate tool. A
combination of the commands :doc:`read_restart <read_restart>` and
:doc:`write_data <write_data>` can be used to the same effect. For added
convenience this conversion can also be triggered by :doc:`command line flags <Run_options>`
:doc:`write_data <write_data>` can be used to the same effect. For
added convenience this conversion can also be triggered by
:doc:`command line flags <Run_options>`

2
doc/src/Developer.rst
View File

@ -13,6 +13,7 @@ of time and requests from the LAMMPS user community.
Developer_org
Developer_code_design
Developer_parallel
Developer_atom
Developer_comm_ops
Developer_flow
Developer_write
@ -23,3 +24,4 @@ of time and requests from the LAMMPS user community.
Classes
Developer_platform
Developer_utils
Developer_grid

88
doc/src/Developer_atom.rst Normal file
View File

@ -0,0 +1,88 @@
Accessing per-atom data
-----------------------
This page discusses how per-atom data is managed in LAMMPS, how it can
be accessed, what communication patters apply, and some of the utility
functions that exist for a variety of purposes.
Owned and ghost atoms
^^^^^^^^^^^^^^^^^^^^^
As described on the :doc:`parallel partitioning algorithms
<Developer_par_part>` page, LAMMPS uses a domain decomposition of the
simulation domain, either in a *brick* or *tiled* manner. Each MPI
process *owns* exactly one subdomain and the atoms within it. To compute
forces for tuples of atoms that are spread across sub-domain boundaries,
also a "halo" of *ghost* atoms are maintained within a the communication
cutoff distance of its subdomain.
The total number of atoms is stored in `Atom::natoms` (within any
typical class this can be referred to at `atom->natoms`. The number of
*owned* (or "local" atoms) are stored in `Atom::nlocal`; the number of
*ghost* atoms is stored in `Atom::nghost`. The sum of `Atom::nlocal`
over all MPI processes should be `Atom::natoms`. This is by default
regularly checked by the Thermo class, and if the sum does not match,
LAMMPS stops with a "lost atoms" error. For convenience also the
property `Atom::nmax` is available, this is the maximum of
`Atom::nlocal + Atom::nghost` across all MPI processes.
Per-atom properties are either managed by the atom style, or individual
classes. or as custom arrays by the individual classes. If only access
to *owned* atoms is needed, they are usually allocated to be of size
`Atom::nlocal`, otherwise of size `Atom::nmax`. Please note that not all
per-atom properties are available or updated on *ghost* atoms. For
example, per-atom velocities are only updated with :doc:`comm_modify vel
yes <comm_modify>`.
Atom indexing
^^^^^^^^^^^^^
When referring to individual atoms, they may be indexed by their local
*index*, their index in their `Atom::x` array. This is densely populated
containing first all *owned* atoms (index < `Atom::nlocal`) and then all
*ghost* atoms. The order of atoms in these arrays can change due to
atoms migrating between between subdomains, atoms being added or
deleted, or atoms being sorted for better cache efficiency. Atoms are
globally uniquely identified by their *atom ID*. There may be multiple
atoms with the same atom ID present, but only one of them may be an
*owned* atom.
To find the local *index* of an atom, when the *atom ID* is known, the
`Atom::map()` function may be used. It will return the local atom index
or -1. If the returned value is between 0 (inclusive) and `Atom::nlocal`
(exclusive) it is an *owned* or "local" atom; for larger values the atom
is present as a ghost atom; for a value of -1, the atom is not present
on the current subdomain at all.
If multiple atoms with the same tag exist in the same subdomain, they
can be found via the `Atom::sametag` array. It points to the next atom
index with the same tag or -1 if there are no more atoms with the same
tag. The list will be exhaustive when starting with an index of an
*owned* atom, since the atom IDs are unique, so there can only be one
such atom. Example code to count atoms with same atom ID in subdomain:
.. code-block:: c++
for (int i = 0; i < atom->nlocal; ++i) {
int count = 0;
while (sametag[i] >= 0) {
i = sametag[i];
++count;
}
printf("Atom ID: %ld is present %d times\n", atom->tag[i], count);
}
Atom class versus AtomVec classes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The `Atom` class contains all kinds of flags and counters about atoms in
the system and that includes pointers to **all** per-atom properties
available for atoms. However, only a subset of these pointers are
non-NULL and which those are depends on the atom style. For each atom
style there is a corresponding `AtomVecXXX` class derived from the
`AtomVec` base class, where the XXX indicates the atom style. This
`AtomVecXXX` class will update the counters and per-atom pointers if
atoms are added or removed to the system or migrate between subdomains.

255
doc/src/Developer_code_design.rst
View File

@ -1,56 +1,57 @@
Code design
-----------
This section explains some of the code design choices in LAMMPS with
the goal of helping developers write new code similar to the existing
code. Please see the section on :doc:`Requirements for contributed
code <Modify_style>` for more specific recommendations and guidelines.
While that section is organized more in the form of a checklist for
code contributors, the focus here is on overall code design strategy,
choices made between possible alternatives, and discussing some
relevant C++ programming language constructs.
This section explains some code design choices in LAMMPS with the goal
of helping developers write new code similar to the existing code.
Please see the section on :doc:`Requirements for contributed code
<Modify_style>` for more specific recommendations and guidelines. While
that section is organized more in the form of a checklist for code
contributors, the focus here is on overall code design strategy, choices
made between possible alternatives, and discussing some relevant C++
programming language constructs.
Historically, the basic design philosophy of the LAMMPS C++ code was a
"C with classes" style. The motivation was to make it easy to modify
LAMMPS for people without significant training in C++ programming.
Data structures and code constructs were used that resemble the
previous implementation(s) in Fortran. A contributing factor to this
choice also was that at the time, C++ compilers were often not mature
and some of the advanced features contained bugs or did not function
as the standard required. There were also disagreements between
compiler vendors as to how to interpret the C++ standard documents.
LAMMPS for people without significant training in C++ programming. Data
structures and code constructs were used that resemble the previous
implementation(s) in Fortran. A contributing factor to this choice was
that at the time, C++ compilers were often not mature and some advanced
features contained bugs or did not function as the standard required.
There were also disagreements between compiler vendors as to how to
interpret the C++ standard documents.
However, C++ compilers have now advanced significantly. In 2020 we
decided to to require the C++11 standard as the minimum C++ language
standard for LAMMPS. Since then we have begun to also replace some of
the C-style constructs with equivalent C++ functionality, either from
the C++ standard library or as custom classes or functions, in order
to improve readability of the code and to increase code reuse through
abstraction of commonly used functionality.
However, C++ compilers and the C++ programming language have advanced
significantly. In 2020, the LAMMPS developers decided to require the
C++11 standard as the minimum C++ language standard for LAMMPS. Since
then, we have begun to replace C-style constructs with equivalent C++
functionality. This was taken either from the C++ standard library or
implemented as custom classes or functions. The goal is to improve
readability of the code and to increase code reuse through abstraction
of commonly used functionality.
.. note::
Please note that as of spring 2022 there is still a sizable chunk
of legacy code in LAMMPS that has not yet been refactored to
reflect these style conventions in full. LAMMPS has a large code
base and many different contributors and there also is a hierarchy
of precedence in which the code is adapted. Highest priority has
been the code in the ``src`` folder, followed by code in packages
in order of their popularity and complexity (simpler code is
adapted sooner), followed by code in the ``lib`` folder. Source
code that is downloaded from external packages or libraries during
compilation is not subject to the conventions discussed here.
Please note that as of spring 2023 there is still a sizable chunk of
legacy code in LAMMPS that has not yet been refactored to reflect
these style conventions in full. LAMMPS has a large code base and
many contributors. There is also a hierarchy of precedence in which
the code is adapted. Highest priority has been the code in the
``src`` folder, followed by code in packages in order of their
popularity and complexity (simpler code gets adapted sooner), followed
by code in the ``lib`` folder. Source code that is downloaded from
external packages or libraries during compilation is not subject to
the conventions discussed here.
Object oriented code
Object-oriented code
^^^^^^^^^^^^^^^^^^^^
LAMMPS is designed to be an object oriented code. Each simulation is
LAMMPS is designed to be an object-oriented code. Each simulation is
represented by an instance of the LAMMPS class. When running in
parallel each MPI process creates such an instance. This can be seen
parallel, each MPI process creates such an instance. This can be seen
in the ``main.cpp`` file where the core steps of running a LAMMPS
simulation are the following 3 lines of code:
.. code-block:: C++
.. code-block:: c++
LAMMPS *lammps = new LAMMPS(argc, argv, lammps_comm);
lammps->input->file();
@ -67,29 +68,29 @@ other special features.
The basic LAMMPS class hierarchy which is created by the LAMMPS class
constructor is shown in :ref:`class-topology`. When input commands
are processed, additional class instances are created, or deleted, or
replaced. Likewise specific member functions of specific classes are
replaced. Likewise, specific member functions of specific classes are
called to trigger actions such creating atoms, computing forces,
computing properties, time-propagating the system, or writing output.
Compositing and Inheritance
===========================
LAMMPS makes extensive use of the object oriented programming (OOP)
LAMMPS makes extensive use of the object-oriented programming (OOP)
principles of *compositing* and *inheritance*. Classes like the
``LAMMPS`` class are a **composite** containing pointers to instances
of other classes like ``Atom``, ``Comm``, ``Force``, ``Neighbor``,
``Modify``, and so on. Each of these classes implement certain
``Modify``, and so on. Each of these classes implements certain
functionality by storing and manipulating data related to the
simulation and providing member functions that trigger certain
actions. Some of those classes like ``Force`` are themselves
composites, containing instances of classes describing different force
interactions. Similarly the ``Modify`` class contains a list of
interactions. Similarly, the ``Modify`` class contains a list of
``Fix`` and ``Compute`` classes. If the input commands that
correspond to these classes include the word *style*, then LAMMPS
stores only a single instance of that class. E.g. *atom_style*,
*comm_style*, *pair_style*, *bond_style*. It the input command does
not include the word *style*, there can be many instances of that
class defined. E.g. *region*, *fix*, *compute*, *dump*.
*comm_style*, *pair_style*, *bond_style*. If the input command does
**not** include the word *style*, then there may be many instances of
that class defined, for example *region*, *fix*, *compute*, *dump*.
**Inheritance** enables creation of *derived* classes that can share
common functionality in their base class while providing a consistent
@ -100,19 +101,18 @@ derived class variant was instantiated. In LAMMPS these derived
classes are often referred to as "styles", e.g. pair styles, fix
styles, atom styles and so on.
This is the origin of the flexibility of LAMMPS. For example pair
This is the origin of the flexibility of LAMMPS. For example, pair
styles implement a variety of different non-bonded interatomic
potentials functions. All details for the implementation of a
potential are stored and executed in a single class.
As mentioned above, there can be multiple instances of classes derived
from the ``Fix`` or ``Compute`` base classes. They represent a
different facet of LAMMPS flexibility as they provide methods which
can be called at different points in time within a timestep, as
explained in `Developer_flow`. This allows the input script to tailor
how a specific simulation is run, what diagnostic computations are
performed, and how the output of those computations is further
processed or output.
different facet of LAMMPS' flexibility, as they provide methods which
can be called at different points within a timestep, as explained in
`Developer_flow`. This allows the input script to tailor how a specific
simulation is run, what diagnostic computations are performed, and how
the output of those computations is further processed or output.
Additional code sharing is possible by creating derived classes from the
derived classes (e.g., to implement an accelerated version of a pair
@ -164,15 +164,15 @@ The difference in behavior of the ``normal()`` and the ``poly()`` member
functions is which of the two member functions is called when executing
`base1->call()` versus `base2->call()`. Without polymorphism, a
function within the base class can only call member functions within the
same scope, that is ``Base::call()`` will always call
``Base::normal()``. But for the `base2->call()` case the call of the
same scope: that is, ``Base::call()`` will always call
``Base::normal()``. But for the `base2->call()` case, the call of the
virtual member function will be dispatched to ``Derived::poly()``
instead. This mechanism means that functions are called within the
scope of the class type that was used to *create* the class instance are
invoked; even if they are assigned to a pointer using the type of a base
class. This is the desired behavior and this way LAMMPS can even use
styles that are loaded at runtime from a shared object file with the
:doc:`plugin command <plugin>`.
instead. This mechanism results in calling functions that are within
the scope of the class that was used to *create* the instance, even if
they are assigned to a pointer for their base class. This is the
desired behavior, and this way LAMMPS can even use styles that are loaded
at runtime from a shared object file with the :doc:`plugin command
<plugin>`.
A special case of virtual functions are so-called pure functions. These
are virtual functions that are initialized to 0 in the class declaration
@ -189,12 +189,12 @@ This has the effect that an instance of the base class cannot be
created and that derived classes **must** implement these functions.
Many of the functions listed with the various class styles in the
section :doc:`Modify` are pure functions. The motivation for this is
to define the interface or API of the functions but defer their
to define the interface or API of the functions, but defer their
implementation to the derived classes.
However, there are downsides to this. For example, calls to virtual
functions from within a constructor, will not be in the scope of the
derived class and thus it is good practice to either avoid calling them
functions from within a constructor, will *not* be in the scope of the
derived class, and thus it is good practice to either avoid calling them
or to provide an explicit scope such as ``Base::poly()`` or
``Derived::poly()``. Furthermore, any destructors in classes containing
virtual functions should be declared virtual too, so they will be
@ -208,8 +208,8 @@ dispatch.
that are intended to replace a virtual or pure function use the
``override`` property keyword. For the same reason, the use of
overloads or default arguments for virtual functions should be
avoided as they lead to confusion over which function is supposed to
override which and which arguments need to be declared.
avoided, as they lead to confusion over which function is supposed to
override which, and which arguments need to be declared.
Style Factories
===============
@ -219,10 +219,10 @@ uses a programming pattern called `Factory`. Those are functions that
create an instance of a specific derived class, say ``PairLJCut`` and
return a pointer to the type of the common base class of that style,
``Pair`` in this case. To associate the factory function with the
style keyword, an ``std::map`` class is used with function pointers
style keyword, a ``std::map`` class is used with function pointers
indexed by their keyword (for example "lj/cut" for ``PairLJCut`` and
"morse" for ``PairMorse``). A couple of typedefs help keep the code
readable and a template function is used to implement the actual
readable, and a template function is used to implement the actual
factory functions for the individual classes. Below is an example
of such a factory function from the ``Force`` class as declared in
``force.h`` and implemented in ``force.cpp``. The file ``style_pair.h``
@ -232,7 +232,7 @@ macro ``PairStyle()`` will associate the style name "lj/cut"
with a factory function creating an instance of the ``PairLJCut``
class.
.. code-block:: C++
.. code-block:: c++
// from force.h
typedef Pair *(*PairCreator)(LAMMPS *);
@ -279,26 +279,26 @@ from and writing to files and console instead of C++ "iostreams".
This is mainly motivated by better performance, better control over
formatting, and less effort to achieve specific formatting.
Since mixing "stdio" and "iostreams" can lead to unexpected
behavior. use of the latter is strongly discouraged. Also output to
the screen should not use the predefined ``stdout`` FILE pointer, but
rather the ``screen`` and ``logfile`` FILE pointers managed by the
LAMMPS class. Furthermore, output should generally only be done by
MPI rank 0 (``comm->me == 0``). Output that is sent to both
``screen`` and ``logfile`` should use the :cpp:func:`utils::logmesg()
convenience function <LAMMPS_NS::utils::logmesg>`.
Since mixing "stdio" and "iostreams" can lead to unexpected behavior,
use of the latter is strongly discouraged. Output to the screen should
*not* use the predefined ``stdout`` FILE pointer, but rather the
``screen`` and ``logfile`` FILE pointers managed by the LAMMPS class.
Furthermore, output should generally only be done by MPI rank 0
(``comm->me == 0``). Output that is sent to both ``screen`` and
``logfile`` should use the :cpp:func:`utils::logmesg() convenience
function <LAMMPS_NS::utils::logmesg>`.
We also discourage the use of stringstreams because the bundled {fmt}
library and the customized tokenizer classes can provide the same
functionality in a cleaner way with better performance. This also
helps maintain a consistent programming syntax with code from many
different contributors.
We discourage the use of stringstreams because the bundled {fmt} library
and the customized tokenizer classes provide the same functionality in a
cleaner way with better performance. This also helps maintain a
consistent programming syntax with code from many different
contributors.
Formatting with the {fmt} library
===================================
The LAMMPS source code includes a copy of the `{fmt} library
<https://fmt.dev>`_ which is preferred over formatting with the
<https://fmt.dev>`_, which is preferred over formatting with the
"printf()" family of functions. The primary reason is that it allows
a typesafe default format for any type of supported data. This is
particularly useful for formatting integers of a given size (32-bit or
@ -313,17 +313,16 @@ been included into the C++20 language standard, so changes to adopt it
are future-proof.
Formatted strings are frequently created by calling the
``fmt::format()`` function which will return a string as a
``std::string`` class instance. In contrast to the ``%`` placeholder
in ``printf()``, the {fmt} library uses ``{}`` to embed format
descriptors. In the simplest case, no additional characters are
needed as {fmt} will choose the default format based on the data type
of the argument. Otherwise the ``fmt::print()`` function may be
used instead of ``printf()`` or ``fprintf()``. In addition, several
LAMMPS output functions, that originally accepted a single string as
argument have been overloaded to accept a format string with optional
arguments as well (e.g., ``Error::all()``, ``Error::one()``,
``utils::logmesg()``).
``fmt::format()`` function, which will return a string as a
``std::string`` class instance. In contrast to the ``%`` placeholder in
``printf()``, the {fmt} library uses ``{}`` to embed format descriptors.
In the simplest case, no additional characters are needed, as {fmt} will
choose the default format based on the data type of the argument.
Otherwise, the ``fmt::print()`` function may be used instead of
``printf()`` or ``fprintf()``. In addition, several LAMMPS output
functions, that originally accepted a single string as argument have
been overloaded to accept a format string with optional arguments as
well (e.g., ``Error::all()``, ``Error::one()``, ``utils::logmesg()``).
Summary of the {fmt} format syntax
==================================
@ -332,10 +331,11 @@ The syntax of the format string is "{[<argument id>][:<format spec>]}",
where either the argument id or the format spec (separated by a colon
':') is optional. The argument id is usually a number starting from 0
that is the index to the arguments following the format string. By
default these are assigned in order (i.e. 0, 1, 2, 3, 4 etc.). The most
common case for using argument id would be to use the same argument in
multiple places in the format string without having to provide it as an
argument multiple times. In LAMMPS the argument id is rarely used.
default, these are assigned in order (i.e. 0, 1, 2, 3, 4 etc.). The
most common case for using argument id would be to use the same argument
in multiple places in the format string without having to provide it as
an argument multiple times. The argument id is rarely used in the LAMMPS
source code.
More common is the use of a format specifier, which starts with a colon.
This may optionally be followed by a fill character (default is ' '). If
@ -347,20 +347,21 @@ width, which may be followed by a dot '.' and a precision for floating
point numbers. The final character in the format string would be an
indicator for the "presentation", i.e. 'd' for decimal presentation of
integers, 'x' for hexadecimal, 'o' for octal, 'c' for character etc.
This mostly follows the "printf()" scheme but without requiring an
This mostly follows the "printf()" scheme, but without requiring an
additional length parameter to distinguish between different integer
widths. The {fmt} library will detect those and adapt the formatting
accordingly. For floating point numbers there are correspondingly, 'g'
for generic presentation, 'e' for exponential presentation, and 'f' for
fixed point presentation.
Thus "{:8}" would represent *any* type argument using at least 8
characters; "{:<8}" would do this as left aligned, "{:^8}" as centered,
"{:>8}" as right aligned. If a specific presentation is selected, the
argument type must be compatible or else the {fmt} formatting code will
throw an exception. Some format string examples are given below:
The format string "{:8}" would thus represent *any* type argument and be
replaced by at least 8 characters; "{:<8}" would do this as left
aligned, "{:^8}" as centered, "{:>8}" as right aligned. If a specific
presentation is selected, the argument type must be compatible or else
the {fmt} formatting code will throw an exception. Some format string
examples are given below:
.. code-block:: C
.. code-block:: c++
auto mesg = fmt::format(" CPU time: {:4d}:{:02d}:{:02d}\n", cpuh, cpum, cpus);
mesg = fmt::format("{:<8s}| {:<10.5g} | {:<10.5g} | {:<10.5g} |{:6.1f} |{:6.2f}\n",
@ -392,12 +393,12 @@ documentation <https://fmt.dev/latest/syntax.html>`_ website.
Memory management
^^^^^^^^^^^^^^^^^
Dynamical allocation of small data and objects can be done with the
the C++ commands "new" and "delete/delete[]. Large data should use
the member functions of the ``Memory`` class, most commonly,
``Memory::create()``, ``Memory::grow()``, and ``Memory::destroy()``,
which provide variants for vectors, 2d arrays, 3d arrays, etc.
These can also be used for small data.
Dynamical allocation of small data and objects can be done with the C++
commands "new" and "delete/delete[]". Large data should use the member
functions of the ``Memory`` class, most commonly, ``Memory::create()``,
``Memory::grow()``, and ``Memory::destroy()``, which provide variants
for vectors, 2d arrays, 3d arrays, etc. These can also be used for
small data.
The use of ``malloc()``, ``calloc()``, ``realloc()`` and ``free()``
directly is strongly discouraged. To simplify adapting legacy code
@ -408,26 +409,24 @@ perform additional error checks for safety.
Use of these custom memory allocation functions is motivated by the
following considerations:
- memory allocation failures on *any* MPI rank during a parallel run
will trigger an immediate abort of the entire parallel calculation
instead of stalling it
- a failing "new" will trigger an exception which is also captured by
LAMMPS and triggers a global abort
- allocation of multi-dimensional arrays will be done in a C compatible
fashion but so that the storage of the actual data is stored in one
large contiguous block. Thus when MPI communication is needed,
- Memory allocation failures on *any* MPI rank during a parallel run
will trigger an immediate abort of the entire parallel calculation.
- A failing "new" will trigger an exception, which is also captured by
LAMMPS and triggers a global abort.
- Allocation of multidimensional arrays will be done in a C compatible
fashion, but such that the storage of the actual data is stored in one
large contiguous block. Thus, when MPI communication is needed,
the data can be communicated directly (similar to Fortran arrays).
- the "destroy()" and "sfree()" functions may safely be called on NULL
pointers
- the "destroy()" functions will nullify the pointer variables making
"use after free" errors easy to detect
- it is possible to use a larger than default memory alignment (not on
- The "destroy()" and "sfree()" functions may safely be called on NULL
pointers.
- The "destroy()" functions will nullify the pointer variables, thus
making "use after free" errors easy to detect.
- It is possible to use a larger than default memory alignment (not on
all operating systems, since the allocated storage pointers must be
compatible with ``free()`` for technical reasons)
compatible with ``free()`` for technical reasons).
In the practical implementation of code this means that any pointer
variables that are class members should be initialized to a
``nullptr`` value in their respective constructors. That way it is
safe to call ``Memory::destroy()`` or ``delete[]`` on them before
*any* allocation outside the constructor. This helps prevent memory
leaks.
In the practical implementation of code this means, that any pointer
variables, that are class members should be initialized to a ``nullptr``
value in their respective constructors. That way, it is safe to call
``Memory::destroy()`` or ``delete[]`` on them before *any* allocation
outside the constructor. This helps prevent memory leaks.

22
doc/src/Developer_comm_ops.rst
View File

@ -14,8 +14,8 @@ Owned and ghost atoms
As described on the :doc:`parallel partitioning algorithms
<Developer_par_part>` page, LAMMPS spatially decomposes the simulation
domain, either in a *brick* or *tiled* manner. Each processor (MPI
task) owns atoms within its sub-domain and additionally stores ghost
atoms within a cutoff distance of its sub-domain.
task) owns atoms within its subdomain and additionally stores ghost
atoms within a cutoff distance of its subdomain.
Forward and reverse communication
=================================
@ -28,7 +28,7 @@ The need to do this communication arises when data from the owned atoms
is updated (e.g. their positions) and this updated information needs to
be **copied** to the corresponding ghost atoms.
And second, *reverse communication* which sends ghost atom information
And second, *reverse communication*, which sends ghost atom information
from each processor to the owning processor to **accumulate** (sum)
the values with the corresponding owned atoms. The need for this
arises when data is computed and also stored with ghost atoms
@ -58,7 +58,7 @@ embedded-atom method (EAM) which compute intermediate values in the
first part of the compute() function that need to be stored by both
owned and ghost atoms for the second part of the force computation.
The *Comm* class methods perform the MPI communication for buffers of
per-atom data. They "call back" to the *Pair* class so it can *pack*
per-atom data. They "call back" to the *Pair* class, so it can *pack*
or *unpack* the buffer with data the *Pair* class owns. There are 4
such methods that the *Pair* class must define, assuming it uses both
forward and reverse communication:
@ -70,22 +70,22 @@ forward and reverse communication:
The arguments to these methods include the buffer and a list of atoms
to pack or unpack. The *Pair* class also must set the *comm_forward*
and *comm_reverse* variables which store the number of values stored
and *comm_reverse* variables, which store the number of values stored
in the communication buffers for each operation. This means, if
desired, it can choose to store multiple per-atom values in the
buffer, and they will be communicated together to minimize
communication overhead. The communication buffers are defined vectors
containing ``double`` values. To correctly store integers that may be
64-bit (bigint, tagint, imageint) in the buffer, you need to use the
`ubuf union <Communication buffer coding with ubuf>`_ construct.
:ref:`ubuf union <communication_buffer_coding_with_ubuf>` construct.
The *Fix*, *Compute*, and *Dump* classes can also invoke the same kind
of forward and reverse communication operations using the same *Comm*
class methods. Likewise the same pack/unpack methods and
class methods. Likewise, the same pack/unpack methods and
comm_forward/comm_reverse variables must be defined by the calling
*Fix*, *Compute*, or *Dump* class.
For *Fix* classes there is an optional second argument to the
For *Fix* classes, there is an optional second argument to the
*forward_comm()* and *reverse_comm()* call which can be used when the
fix performs multiple modes of communication, with different numbers
of values per atom. The fix should set the *comm_forward* and
@ -150,7 +150,7 @@ latter case, when the *ring* operation is complete, each processor can
examine its original buffer to extract modified values.
Note that the *ring* operation is similar to an MPI_Alltoall()
operation where every processor effectively sends and receives data to
operation, where every processor effectively sends and receives data to
every other processor. The difference is that the *ring* operation
does it one step at a time, so the total volume of data does not need
to be stored by every processor. However, the *ring* operation is
@ -184,8 +184,8 @@ The *exchange_data()* method triggers the communication to be
performed. Each processor provides the vector of *N* datums to send,
and the size of each datum. All datums must be the same size.
The *create_atom()* and *exchange_atom()* methods are similar except
that the size of each datum can be different. Typically this is used
The *create_atom()* and *exchange_atom()* methods are similar, except
that the size of each datum can be different. Typically, this is used
to communicate atoms, each with a variable amount of per-atom data, to
other processors.

53
doc/src/Developer_flow.rst
View File

@ -45,9 +45,9 @@ other methods in the class.
zero before each timestep, so that forces (torques, etc) can be
accumulated.
Now for the ``Verlet::run()`` method. Its basic structure in hi-level pseudo
code is shown below. In the actual code in ``src/verlet.cpp`` some of
these operations are conditionally invoked.
Now for the ``Verlet::run()`` method. Its basic structure in hi-level
pseudocode is shown below. In the actual code in ``src/verlet.cpp``
some of these operations are conditionally invoked.
.. code-block:: python
@ -105,17 +105,17 @@ need it. These flags are passed to the various methods that compute
particle interactions, so that they either compute and tally the
corresponding data or can skip the extra calculations if the energy and
virial are not needed. See the comments for the ``Integrate::ev_set()``
method which document the flag values.
method, which document the flag values.
At various points of the timestep, fixes are invoked,
e.g. ``fix->initial_integrate()``. In the code, this is actually done
via the Modify class which stores all the Fix objects and lists of which
via the Modify class, which stores all the Fix objects and lists of which
should be invoked at what point in the timestep. Fixes are the LAMMPS
mechanism for tailoring the operations of a timestep for a particular
simulation. As described elsewhere, each fix has one or more methods,
each of which is invoked at a specific stage of the timestep, as show in
the timestep pseudo-code. All the active fixes defined in an input
script, that are flagged to have an ``initial_integrate()`` method are
the timestep pseudocode. All the active fixes defined in an input
script, that are flagged to have an ``initial_integrate()`` method, are
invoked at the beginning of each timestep. Examples are :doc:`fix nve
<fix_nve>` or :doc:`fix nvt or fix npt <fix_nh>` which perform the
start-of-timestep velocity-Verlet integration operations to update
@ -131,15 +131,15 @@ can be changed using the :doc:`neigh_modify every/delay/check
<neigh_modify>` command. If not, coordinates of ghost atoms are
acquired by each processor via the ``forward_comm()`` method of the Comm
class. If neighbor lists need to be built, several operations within
the inner if clause of the pseudo-code are first invoked. The
the inner if clause of the pseudocode are first invoked. The
``pre_exchange()`` method of any defined fixes is invoked first.
Typically this inserts or deletes particles from the system.
Typically, this inserts or deletes particles from the system.
Periodic boundary conditions are then applied by the Domain class via
its ``pbc()`` method to remap particles that have moved outside the
simulation box back into the box. Note that this is not done every
timestep, but only when neighbor lists are rebuilt. This is so that
each processor's sub-domain will have consistent (nearby) atom
each processor's subdomain will have consistent (nearby) atom
coordinates for its owned and ghost atoms. It is also why dumped atom
coordinates may be slightly outside the simulation box if not dumped
on a step where the neighbor lists are rebuilt.
@ -148,15 +148,15 @@ The box boundaries are then reset (if needed) via the ``reset_box()``
method of the Domain class, e.g. if box boundaries are shrink-wrapped to
current particle coordinates. A change in the box size or shape
requires internal information for communicating ghost atoms (Comm class)
and neighbor list bins (Neighbor class) be updated. The ``setup()``
and neighbor list bins (Neighbor class) to be updated. The ``setup()``
method of the Comm class and ``setup_bins()`` method of the Neighbor
class perform the update.
The code is now ready to migrate atoms that have left a processor's
geometric sub-domain to new processors. The ``exchange()`` method of
geometric subdomain to new processors. The ``exchange()`` method of
the Comm class performs this operation. The ``borders()`` method of the
Comm class then identifies ghost atoms surrounding each processor's
sub-domain and communicates ghost atom information to neighboring
subdomain and communicates ghost atom information to neighboring
processors. It does this by looping over all the atoms owned by a
processor to make lists of those to send to each neighbor processor. On
subsequent timesteps, the lists are used by the ``Comm::forward_comm()``
@ -217,20 +217,21 @@ file, and restart files. See the :doc:`thermo_style <thermo_style>`,
:doc:`dump <dump>`, and :doc:`restart <restart>` commands for more
details.
The the flow of control during energy minimization iterations is
similar to that of a molecular dynamics timestep. Forces are computed,
neighbor lists are built as needed, atoms migrate to new processors, and
atom coordinates and forces are communicated to neighboring processors.
The only difference is what Fix class operations are invoked when. Only
a subset of LAMMPS fixes are useful during energy minimization, as
The flow of control during energy minimization iterations is similar to
that of a molecular dynamics timestep. Forces are computed, neighbor
lists are built as needed, atoms migrate to new processors, and atom
coordinates and forces are communicated to neighboring processors. The
only difference is what Fix class operations are invoked when. Only a
subset of LAMMPS fixes are useful during energy minimization, as
explained in their individual doc pages. The relevant Fix class methods
are ``min_pre_exchange()``, ``min_pre_force()``, and ``min_post_force()``.
Each fix is invoked at the appropriate place within the minimization
iteration. For example, the ``min_post_force()`` method is analogous to
the ``post_force()`` method for dynamics; it is used to alter or constrain
forces on each atom, which affects the minimization procedure.
are ``min_pre_exchange()``, ``min_pre_force()``, and
``min_post_force()``. Each fix is invoked at the appropriate place
within the minimization iteration. For example, the
``min_post_force()`` method is analogous to the ``post_force()`` method
for dynamics; it is used to alter or constrain forces on each atom,
which affects the minimization procedure.
After all iterations are completed there is a ``cleanup`` step which
After all iterations are completed, there is a ``cleanup`` step which
calls the ``post_run()`` method of fixes to perform operations only required
at the end of a calculations (like freeing temporary storage or creating
at the end of a calculation (like freeing temporary storage or creating
final outputs).

845
doc/src/Developer_grid.rst Normal file
View File

@ -0,0 +1,845 @@
Use of distributed grids within style classes
---------------------------------------------
.. versionadded:: 22Dec2022
The LAMMPS source code includes two classes which facilitate the
creation and use of distributed grids. These are the Grid2d and
Grid3d classes in the src/grid2d.cpp.h and src/grid3d.cpp.h files
respectively. As the names imply, they are used for 2d or 3d
simulations, as defined by the :doc:`dimension <dimension>` command.
The :doc:`Howto_grid <Howto_grid>` page gives an overview of how
distributed grids are defined from a user perspective, lists LAMMPS
commands which use them, and explains how grid cell data is referenced
from an input script. Please read that page first as it motivates the
coding details discussed here.
This doc page is for users who wish to write new styles (input script
commands) which use distributed grids. There are a variety of
material models and analysis methods which use atoms (or
coarse-grained particles) and grids in tandem.
A *distributed* grid means each processor owns a subset of the grid
cells. In LAMMPS, the subset for each processor will be a sub-block
of grid cells with low and high index bounds in each dimension of the
grid. The union of the sub-blocks across all processors is the global
grid.
More specifically, a grid point is defined for each cell (by default
the center point), and a processor owns a grid cell if its point is
within the processor's spatial subdomain. The union of processor
subdomains is the global simulation box. If a grid point is on the
boundary of two subdomains, the lower processor owns the grid cell. A
processor may also store copies of ghost cells which surround its
owned cells.
----------
Style commands
^^^^^^^^^^^^^^
Style commands which can define and use distributed grids include the
:doc:`compute <compute>`, :doc:`fix <fix>`, :doc:`pair <pair_style>`,
and :doc:`kspace <kspace_style>` styles. If you wish grid cell data
to persist across timesteps, then use a fix. If you wish grid cell
data to be accessible by other commands, then use a fix or compute.
Currently in LAMMPS, the :doc:`pair_style amoeba <pair_amoeba>`,
:doc:`kspace_style pppm <kspace_style>`, and :doc:`kspace_style msm
<kspace_style>` commands use distributed grids but do not require
either of these capabilities; they thus create and use distributed
grids internally. Note that a pair style which needs grid cell data
to persist could be coded to work in tandem with a fix style which
provides that capability.
The *size* of a grid is specified by the number of grid cells in each
dimension of the simulation domain. In any dimension the size can be
any value >= 1. Thus a 10x10x1 grid for a 3d simulation is
effectively a 2d grid, where each grid cell spans the entire
z-dimension. A 1x100x1 grid for a 3d simulation is effectively a 1d
grid, where grid cells are a series of thin xz slabs in the
y-dimension. It is even possible to define a 1x1x1 3d grid, though it
may be inefficient to use it in a computational sense.
Note that the choice of grid size is independent of the number of
processors or their layout in a grid of processor subdomains which
overlays the simulations domain. Depending on the distributed grid
size, a single processor may own many 1000s or no grid cells.
A command can define multiple grids, each of a different size. Each
grid is an instantiation of the Grid2d or Grid3d class.
The command also defines what data it will store for each grid it
creates and it allocates the multidimensional array(s) needed to
store the data. No grid cell data is stored within the Grid2d or
Grid3d classes.
If a single value per grid cell is needed, the data array will have
the same dimension as the grid, i.e. a 2d array for a 2d grid,
likewise for 3d. If multiple values per grid cell are needed, the
data array will have one more dimension than the grid, i.e. a 3d array
for a 2d grid, or 4d array for a 3d grid. A command can choose to
define multiple data arrays for each grid it defines.
----------
Grid data allocation and access
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The simplest way for a command to allocate and access grid cell data
is to use the *create_offset()* methods provided by the Memory class.
Arguments for these methods can be values returned by the
*setup_grid()* method (described below), which define the extent of
the grid cells (owned+ghost) the processor owns. These 4 methods
allocate memory for 2d (first two) and 3d (second two) grid data. The
two methods that end in "_offset" allocate an array which stores a single
value per grid cell. The two that end in "_last" allocate an array
which stores *Nvalues* per grid cell.
.. code-block:: c++
// single value per cell for a 2d grid = 2d array
memory->create2d_offset(data2d_one, nylo_out, nyhi_out,
nxlo_out, nxhi_out, "data2d_one");
// nvalues per cell for a 2d grid = 3d array
memory->create3d_offset_last(data2d_multi, nylo_out, nyhi_out,
nxlo_out, nxhi_out, nvalues, "data2d_multi");
// single value per cell for a 3d grid = 3d array
memory->create3d_offset(data3d_one, nzlo_out, nzhi_out, nylo_out,
nyhi_out, nxlo_out, nxhi_out, "data3d_one");
// nvalues per cell for a 3d grid = 4d array
memory->create4d_offset_last(data3d_multi, nzlo_out, nzhi_out, nylo_out,
nyhi_out, nxlo_out, nxhi_out, nvalues,
"data3d_multi");
Note that these multidimensional arrays are allocated as contiguous
chunks of memory where the x-index of the grid varies fastest, then y,
and the z-index slowest. For multiple values per grid cell, the
Nvalues are contiguous, so their index varies even faster than the
x-index.
The key point is that the "offset" methods create arrays which are
indexed by the range of indices which are the bounds of the sub-block
of the global grid owned by this processor. This means loops like
these can be written in the caller code to loop over owned grid cells,
where the "i" loop bounds are the range of owned grid cells for the
processor. These are the bounds returned by the *setup_grid()*
method:
.. code-block:: c++
for (int iy = iylo; iy <= iyhi; iy++)
for (int ix = ixlo; ix <= ixhi; ix++)
data2d_one[iy][ix] = 0.0;
for (int iy = iylo; iy <= iyhi; iy++)
for (int ix = ixlo; ix <= ixhi; ix++)
for (int m = 0; m < nvalues; m++)
data2d_multi[iy][ix][m] = 0.0;
for (int iz = izlo; iz <= izhi; iz++)
for (int iy = iylo; iy <= iyhi; iy++)
for (int ix = ixlo; ix <= ixhi; ix++)
data3d_one[iz][iy][ix] = 0.0;
for (int iz = izlo; iz <= izhi; iz++)
for (int iy = iylo; iy <= iyhi; iy++)
for (int ix = ixlo; ix <= ixhi; ix++)
for (int m = 0; m < nvalues; m++)
data3d_multi[iz][iy][ix][m] = 0.0;
Simply replacing the "i" bounds with "o" bounds, also returned by the
*setup_grid()* method, would alter this code to loop over owned+ghost
cells (the entire allocated grid).
----------
Grid class constructors
^^^^^^^^^^^^^^^^^^^^^^^
The following subsections describe the public methods of the Grid3d
class which a style command can invoke. The Grid2d methods are
similar; simply remove arguments which refer to the z-dimension.
There are 2 constructors which can be used. They differ in the extra
i/o xyz lo/hi arguments:
.. code-block:: c++
Grid3d(class LAMMPS *lmp, MPI_Comm gcomm, int gnx, int gny, int gnz)
Grid3d(class LAMMPS *lmp, MPI_Comm gcomm, int gnx, int gny, int gnz,
int ixlo, int ixhi, int iylo, int iyhi, int izlo, int izhi,
int oxlo, int oxhi, int oylo, int oyhi, int ozlo, int ozhi)
Both constructors take the LAMMPS instance pointer and a communicator
over which the grid will be distributed. Typically this is the
*world* communicator the LAMMPS instance is using. The
:doc:`kspace_style msm <kspace_style>` command creates a series of
grids, each of different size, which are partitioned across different
sub-communicators of processors. Both constructors are also passed
the global grid size: *gnx* by *gny* by *gnz*.
The first constructor is used when the caller wants the Grid class to
partition the global grid across processors; the Grid class defines
which grid cells each processor owns and also which it stores as ghost
cells. A subsequent call to *setup_grid()*, discussed below, returns
this info to the caller.
The second constructor allows the caller to define the extent of owned
and ghost cells, and pass them to the Grid class. The 6 arguments
which start with "i" are the inclusive lower and upper index bounds of
the owned (inner) grid cells this processor owns in each of the 3
dimensions within the global grid. Owned grid cells are indexed from
0 to N-1 in each dimension.
The 6 arguments which start with "o" are the inclusive bounds of the
owned+ghost (outer) grid cells it stores. If the ghost cells are on
the other side of a periodic boundary, then these indices may be < 0
or >= N in any dimension, so that oxlo <= ixlo and ixhi >= ixhi is
always the case.
For example, if Nx = 100, then a processor might pass ixlo=50,
ixhi=60, oxlo=48, oxhi=62 to the Grid class. Or ixlo=0, ixhi=10,
oxlo=-2, oxhi=13. If a processor owns no grid cells in a dimension,
then the ihi value should be specified as one less than the ilo value.
Note that the only reason to use the second constructor is if the
logic for assigning ghost cells is too complex for the Grid class to
compute, using the various set() methods described next. Currently
only the kspace_style pppm/electrode and kspace_style msm commands use
the second constructor.
----------
Grid class set methods
^^^^^^^^^^^^^^^^^^^^^^
The following methods affect how the Grid class computes which owned
and ghost cells are assigned to each processor. *Set_shift_grid()* is
the only method which influences owned cell assignment; all the rest
influence ghost cell assignment. These methods are only used with the
first constructor; they are ignored if the second constructor is used.
These methods must be called before the *setup_grid()* method is
invoked, because they influence its operation.
.. code-block:: c++
void set_shift_grid(double shift);
void set_distance(double distance);
void set_stencil_atom(int lo, int hi);
void set_shift_atom(double shift_lo, double shift_hi);
void set_stencil_grid(int lo, int hi);
void set_zfactor(double factor);
Processors own a grid cell if a point within the grid cell is inside
the processor's subdomain. By default this is the center point of the
grid cell. The *set_shift_grid()* method can change this. The *shift*
argument is a value from 0.0 to 1.0 (inclusive) which is the offset of
the point within the grid cell in each dimension. The default is 0.5
for the center of the cell. A value of 0.0 is the lower left corner
point; a value of 1.0 is the upper right corner point. There is
typically no need to change the default as it is optimal for
minimizing the number of ghost cells needed.
If a processor maps its particles to grid cells, it needs to allow for
its particles being outside its subdomain between reneighboring. The
*distance* argument of the *set_distance()* method sets the furthest
distance outside a processor's subdomain which a particle can move.
Typically this is half the neighbor skin distance, assuming
reneighboring is done appropriately. This distance is used in
determining how many ghost cells a processor needs to store to enable
its particles to be mapped to grid cells. The default value is 0.0.
Some commands, like the :doc:`kspace_style pppm <kspace_style>`
command, map values (charge in the case of PPPM) to a stencil of grid
cells beyond the grid cell the particle is in. The stencil extent may
be different in the low and high directions. The *set_stencil_atom()*
method defines the maximum values of those 2 extents, assumed to be
the same in each of the 3 dimensions. Both the lo and hi values are
specified as positive integers. The default values are both 0.
Some commands, like the :doc:`kspace_style pppm <kspace_style>`
command, shift the position of an atom when mapping it to a grid cell,
based on the size of the stencil used to map values to the grid
(charge in the case of PPPM). The lo and hi arguments of the
*set_shift_atom()* method are the minimum shift in the low direction
and the maximum shift in the high direction, assumed to be the same in
each of the 3 dimensions. The shifts should be fractions of a grid
cell size with values between 0.0 and 1.0 inclusive. The default
values are both 0.0. See the src/pppm.cpp file for examples of these
lo/hi values for regular and staggered grids.
Some methods like the :doc:`fix ttm/grid <fix_ttm>` command, perform
finite difference kinds of operations on the grid, to diffuse electron
heat in the case of the two-temperature model (TTM). This operation
uses ghost grid values beyond the owned grid values the processor
updates. The *set_stencil_grid()* method defines the extent of this
stencil in both directions, assumed to be the same in each of the 3
dimensions. Both the lo and hi values are specified as positive
integers. The default values are both 0.
The kspace_style pppm commands allow a grid to be defined which
overlays a volume which extends beyond the simulation box in the z
dimension. This is for the purpose of modeling a 2d-periodic slab
(non-periodic in z) as if it were a larger 3d periodic system,
extended (with empty space) in the z dimension. The
:doc:`kspace_modify slab <kspace_modify>` command is used to specify
the ratio of the larger volume to the simulation volume; a volume
ratio of ~3 is typical. For this kind of model, the PPPM caller sets
the global grid size *gnz* ~3x larger than it would be otherwise.
This same ratio is passed by the PPPM caller as the *factor* argument
to the Grid class via the *set_zfactor()* method (*set_yfactor()* for
2d grids). The Grid class will then assign ownership of the 1/3 of
grid cells that overlay the simulation box to the processors which
also overlay the simulation box. The remaining 2/3 of the grid cells
are assigned to processors whose subdomains are adjacent to the upper
z boundary of the simulation box.
----------
Grid class setup_grid method
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The *setup_grid()* method is called after the first constructor
(above) to partition the grid across processors, which determines
which grid cells each processor owns. It also calculates how many
ghost grid cells in each dimension and each direction each processor
needs to store.
Note that this method is NOT called if the second constructor above is
used. In that case, the caller assigns owned and ghost cells to each
processor.
Also note that this method must be invoked after any *set_*()* methods have
been used, since they can influence the assignment of owned and ghost
cells.
.. code-block:: c++
void setup_grid(int &ixlo, int &ixhi, int &iylo, int &iyhi, int &izlo, int &izhi,
int &oxlo, int &oxhi, int &oylo, int &oyhi, int &ozlo, int &ozhi)
The 6 return arguments which start with "i" are the inclusive lower
and upper index bounds of the owned (inner) grid cells this processor
owns in each of the 3 dimensions within the global grid. Owned grid
cells are indexed from 0 to N-1 in each dimension.
The 6 return arguments which start with "o" are the inclusive bounds of
the owned+ghost cells it owns. If the ghost cells are on the other
side of a periodic boundary, then these indices may be < 0 or >= N in
any dimension, so that oxlo <= ixlo and ixhi >= ixhi is always the
case.
----------
More grid class set methods
^^^^^^^^^^^^^^^^^^^^^^^^^^^
The following 2 methods can be used to override settings made by the
constructors above. If used, they must be called called before the
*setup_comm()* method is invoked, since it uses the settings that
these methods override. In LAMMPS these methods are called by by the
:doc:`kspace_style msm <kspace_style>` command for the grids it
instantiates using the 2nd constructor above.
.. code-block:: c++
void set_proc_neighs(int pxlo, int pxhi, int pylo, int pyhi, int pzlo, int pzhi)
void set_caller_grid(int fxlo, int fxhi, int fylo, int fyhi, int fzlo, int fzhi)
The *set_proc_neighs()* method sets the processor IDs of the 6
neighboring processors for each processor. Normally these would match
the processor grid neighbors which LAMMPS creates to overlay the
simulation box (the default). However, MSM excludes non-participating
processors from coarse grid communication when less processors are
used. This method allows MSM to override the default values.
The *set_caller_grid()* method species the size of the data arrays the
caller allocates. Normally these would match the extent of the ghost
grid cells (the default). However the MSM caller allocates a larger
data array (more ghost cells) for its finest-level grid, for use in
other operations besides owned/ghost cell communication. This method
allows MSM to override the default values.
----------
Grid class get methods
^^^^^^^^^^^^^^^^^^^^^^
The following methods allow the caller to query the settings for a
specific grid, whether it created the grid or another command created
it.
.. code-block:: c++
void get_size(int &nxgrid, int &nygrid, int &nzgrid);
void get_bounds_owned(int &xlo, int &xhi, int &ylo, int &yhi, int &zlo, int &zhi)
void get_bounds_ghost(int &xlo, int &xhi, int &ylo, int &yhi, int &zlo, int &zhi)
The *get_size()* method returns the size of the global grid in each dimension.
The *get_bounds_owned()* method return the inclusive index bounds of
the grid cells this processor owns. The values range from 0 to N-1 in
each dimension. These values are the same as the "i" values returned
by *setup_grid()*.
The *get_bounds_ghost()* method return the inclusive index bounds of
the owned+ghost grid cells this processor stores. The owned cell
indices range from 0 to N-1, so these indices may be less than 0 or
greater than or equal to N in each dimension. These values are the
same as the "o" values returned by *setup_grid()*.
----------
Grid class owned/ghost communication
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If needed by the command, the following methods setup and perform
communication of grid data to/from neighboring processors. The
*forward_comm()* method sends owned grid cell data to the
corresponding ghost grid cells on other processors. The
*reverse_comm()* method sends ghost grid cell data to the
corresponding owned grid cells on another processor. The caller can
choose to sum ghost grid cell data to the owned grid cell or simply
copy it.
.. code-block:: c++
void setup_comm(int &nbuf1, int &nbuf2)
void forward_comm(int caller, void *ptr, int which, int nper, int nbyte,
void *buf1, void *buf2, MPI_Datatype datatype);
void reverse_comm(int caller, void *ptr, int which, int nper, int nbyte,
void *buf1, void *buf2, MPI_Datatype datatype)
int ghost_adjacent();
The *setup_comm()* method must be called one time before performing
*forward* or *reverse* communication (multiple times if needed). It
returns two integers, which should be used to allocate two buffers.
The *nbuf1* and *nbuf2* values are the number of grid cells whose data
will be stored in two buffers by the Grid class when *forward* or
*reverse* communication is performed. The caller should thus allocate
them to a size large enough to hold all the data used in any single
forward or reverse communication operation it performs. Note that the
caller may allocate and communicate multiple data arrays for a grid it
instantiates. This size includes the bytes needed for the data type
of the grid data it stores, e.g. double precision values.
The *forward_comm()* and *reverse_comm()* methods send grid cell data
from owned to ghost cells, or ghost to owned cells, respectively, as
described above. The *caller* argument should be one of these values
-- Grid3d::COMPUTE, Grid3d::FIX, Grid3d::KSPACE, Grid3d::PAIR --
depending on the style of the caller class. The *ptr* argument is the
"this" pointer to the caller class. These 2 arguments are used to
call back to pack()/unpack() functions in the caller class, as
explained below.
The *which* argument is a flag the caller can set which is passed to
the caller's pack()/unpack() methods. This allows a single callback
method to pack/unpack data for several different flavors of
forward/reverse communication, e.g. operating on different grids or
grid data.
The *nper* argument is the number of values per grid cell to be
communicated. The *nbyte* argument is the number of bytes per value,
e.g. 8 for double-precision values. The *buf1* and *buf2* arguments
are the two allocated buffers described above. So long as they are
allocated for the maximum size communication, they can be re-used for
any *forward_comm()/reverse_comm()* call. The *datatype* argument is
the MPI_Datatype setting, which should match the buffer allocation and
the *nbyte* argument. E.g. MPI_DOUBLE for buffers storing double
precision values.
To use the *forward_grid()* method, the caller must provide two
callback functions; likewise for use of the *reverse_grid()* methods.
These are the 4 functions, their arguments are all the same.
.. code-block:: c++
void pack_forward_grid(int which, void *vbuf, int nlist, int *list);
void unpack_forward_grid(int which, void *vbuf, int nlist, int *list);
void pack_reverse_grid(int which, void *vbuf, int nlist, int *list);
void unpack_reverse_grid(int which, void *vbuf, int nlist, int *list);
The *which* argument is set to the *which* value of the
*forward_comm()* or *reverse_comm()* calls. It allows the pack/unpack
function to select what data values to pack/unpack. *Vbuf* is the
buffer to pack/unpack the data to/from. It is a void pointer so that
the caller can cast it to whatever data type it chooses, e.g. double
precision values. *Nlist* is the number of grid cells to pack/unpack
and *list* is a vector (nlist in length) of offsets to where the data
for each grid cell resides in the caller's data arrays, which is best
illustrated with an example from the src/EXTRA-FIX/fix_ttm_grid.cpp
class which stores the scalar electron temperature for 3d system in a
3d grid (one value per grid cell):
.. code-block:: c++
void FixTTMGrid::pack_forward_grid(int /*which*/, void *vbuf, int nlist, int *list)
{
auto buf = (double *) vbuf;
double *src = &T_electron[nzlo_out][nylo_out][nxlo_out];
for (int i = 0; i < nlist; i++) buf[i] = src[list[i]];
}
In this case, the *which* argument is not used, *vbuf* points to a
buffer of doubles, and the electron temperature is stored by the
FixTTMGrid class in a 3d array of owned+ghost cells called T_electron.
That array is allocated by the *memory->create_3d_offset()* method
described above so that the first grid cell it stores is indexed as
T_electron[nzlo_out][nylo_out][nxlo_out]. The *nlist* values in
*list* are integer offsets from that first grid cell. Setting *src*
to the address of the first cell allows those offsets to be used to
access the temperatures to pack into the buffer.
Here is a similar portion of code from the src/fix_ave_grid.cpp class
which can store two kinds of data, a scalar count of atoms in a grid
cell, and one or more grid-cell-averaged atom properties. The code
from its *unpack_reverse_grid()* function for 2d grids and multiple
per-atom properties per grid cell (*nvalues*) is shown here:
.. code-block:: c++
void FixAveGrid::unpack_reverse_grid(int /*which*/, void *vbuf, int nlist, int *list)
{
auto buf = (double *) vbuf;
double *count,*data,*values;
count = &count2d[nylo_out][nxlo_out];
data = &array2d[nylo_out][nxlo_out][0];
m = 0;
for (i = 0; i < nlist; i++) {
count[list[i]] += buf[m++];
values = &data[nvalues*list[i]];
for (j = 0; j < nvalues; j++)
values[j] += buf[m++];
}
}
Both the count and the multiple values per grid cell are communicated
in *vbuf*. Note that *data* is now a pointer to the first value in
the first grid cell. And *values* points to where the first value in
*data* is for an offset of grid cells, calculated by multiplying
*nvalues* by *list[i]*. Finally, because this is reverse
communication, the communicated buffer values are summed to the caller
values.
The *ghost_adjacent()* method returns a 1 if every processor can
perform the necessary owned/ghost communication with only its nearest
neighbor processors (4 in 2d, 6 in 3d). It returns a 0 if any
processor's ghost cells extend further than nearest neighbor
processors.
This can be checked by callers who have the option to change the
global grid size to ensure more efficient nearest-neighbor-only
communication if they wish. In this case, they instantiate a grid of
a given size (resolution), then invoke *setup_comm()* followed by
*ghost_adjacent()*. If the ghost cells are not adjacent, they destroy
the grid instance and start over with a higher-resolution grid.
Several of the :doc:`kspace_style pppm <kspace_style>` command
variants have this option.
----------
Grid class remap methods for load balancing
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The following methods are used when a load-balancing operation,
triggered by the :doc:`balance <balance>` or :doc:`fix balance
<fix_balance>` commands, changes the partitioning of the simulation
domain into processor subdomains.
In order to work with load-balancing, any style command (compute, fix,
pair, or kspace style) which allocates a grid and stores per-grid data
should define a *reset_grid()* method; it takes no arguments. It will
be called by the two balance commands after they have reset processor
subdomains and migrated atoms (particles) to new owning processors.
The *reset_grid()* method will typically perform some or all of the
following operations. See the src/fix_ave_grid.cpp and
src/EXTRA_FIX/fix_ttm_grid.cpp files for examples of *reset_grid()*
methods, as well as the *pack_remap_grid()* and *unpack_remap_grid()*
functions.
First, the *reset_grid()* method can instantiate new grid(s) of the
same global size, then call *setup_grid()* to partition them via the
new processor subdomains. At this point, it can invoke the
*identical()* method which compares the owned and ghost grid cell
index bounds between two grids, the old grid passed as a pointer
argument, and the new grid whose *identical()* method is being called.
It returns 1 if the indices match on all processors, otherwise 0. If
they all match, then the new grids can be deleted; the command can
continue to use the old grids.
If not, then the command should allocate new grid data array(s) which
depend on the new partitioning. If the command does not need to
persist its grid data from the old partitioning to the new one, then
the command can simply delete the old data array(s) and grid
instance(s). It can then return.
If the grid data does need to persist, then the data for each grid
needs to be "remapped" from the old grid partitioning to the new grid
partitioning. The *setup_remap()* and *remap()* methods are used for
that purpose.
.. code-block:: c++
int identical(Grid3d *old);
void setup_remap(Grid3d *old, int &nremap_buf1, int &nremap_buf2)
void remap(int caller, void *ptr, int which, int nper, int nbyte,
void *buf1, void *buf2, MPI_Datatype datatype)
The arguments to these methods are identical to those for
the *setup_comm()* and *forward_comm()* or *reverse_comm()* methods.
However the returned *nremap_buf1* and *nremap2_buf* values will be
different than the *nbuf1* and *nbuf2* values. They should be used to
allocate two different remap buffers, separate from the owned/ghost
communication buffers.
To use the *remap()* method, the caller must provide two
callback functions:
.. code-block:: c++
void pack_remap_grid(int which, void *vbuf, int nlist, int *list);
void unpack_remap_grid(int which, void *vbuf, int list, int *list);
Their arguments are identical to those for the *pack_forward_grid()*
and *unpack_forward_grid()* callback functions (or the reverse
variants) discussed above. Normally, both these methods pack/unpack
all the data arrays for a given grid. The *which* argument of the
*remap()* method sets the *which* value for the pack/unpack functions.
If the command instantiates multiple grids (of different sizes), it
can be used within the pack/unpack methods to select which grid's data
is being remapped.
Note that the *pack_remap_grid()* function must copy values from the
OLD grid data arrays into the *vbuf* buffer. The *unpack_remap_grid()*
function must copy values from the *vbuf* buffer into the NEW grid
data arrays.
After the remap operation for grid cell data has been performed, the
*reset_grid()* method can deallocate the two remap buffers it created,
and can then exit.
----------
Grid class I/O methods
^^^^^^^^^^^^^^^^^^^^^^
There are two I/O methods in the Grid classes which can be used to
read and write grid cell data to files. The caller can decide on the
precise format of each file, e.g. whether header lines are prepended
or comment lines are allowed. Fundamentally, the file should contain
one line per grid cell for the entire global grid. Each line should
contain identifying info as to which grid cell it is, e.g. a unique
grid cell ID or the ix,iy,iz indices of the cell within a 3d grid.
The line should also contain one or more data values which are stored
within the grid data arrays created by the command
For grid cell IDs, the LAMMPS convention is that the IDs run from 1 to
N, where N = Nx * Ny for 2d grids and N = Nx * Ny * Nz for 3d grids.
The x-index of the grid cell varies fastest, then y, and the z-index
varies slowest. So for a 10x10x10 grid the cell IDs from 901-1000
would be in the top xy layer of the z dimension.
The *read_file()* method does something simple. It reads a chunk of
consecutive lines from the file and passes them back to the caller to
process. The caller provides a *unpack_read_grid()* function for this
purpose. The function checks the grid cell ID or indices and only
stores grid cell data for the grid cells it owns.
The *write_file()* method does something slightly more complex. Each
processor packs the data for its owned grid cells into a buffer. The
caller provides a *pack_write_grid()* function for this purpose. The
*write_file()* method then loops over all processors and each sends
its buffer one at a time to processor 0, along with the 3d (or 2d)
index bounds of its grid cell data within the global grid. Processor
0 calls back to the *unpack_write_grid()* function provided by the
caller with the buffer. The function writes one line per grid cell to
the file.
See the src/EXTRA_FIX/fix_ttm_grid.cpp file for examples of now both
these methods are used to read/write electron temperature values
from/to a file, as well as for implementations of the the pack/unpack
functions described below.
Here are the details of the two I/O methods and the 3 callback
functions. See the src/fix_ave_grid.cpp file for examples of all of
them.
.. code-block:: c++
void read_file(int caller, void *ptr, FILE *fp, int nchunk, int maxline)
void write_file(int caller, void *ptr, int which,
int nper, int nbyte, MPI_Datatype datatype
The *caller* argument in both methods should be one of these values --
Grid3d::COMPUTE, Grid3d::FIX, Grid3d::KSPACE, Grid3d::PAIR --
depending on the style of the caller class. The *ptr* argument in
both methods is the "this" pointer to the caller class. These 2
arguments are used to call back to pack()/unpack() functions in the
caller class, as explained below.
For the *read_file()* method, the *fp* argument is a file pointer to
the file to be read from, opened on processor 0 by the caller.
*Nchunk* is the number of lines to read per chunk, and *maxline* is
the maximum number of characters per line. The Grid class will
allocate a buffer for storing chunks of lines based on these values.
For the *write_file()* method, the *which* argument is a flag the
caller can set which is passed back to the caller's pack()/unpack()
methods. If the command instantiates multiple grids (of different
sizes), this flag can be used within the pack/unpack methods to select
which grid's data is being written out (presumably to different
files). the *nper* argument is the number of values per grid cell to
be written out. The *nbyte* argument is the number of bytes per
value, e.g. 8 for double-precision values. The *datatype* argument is
the MPI_Datatype setting, which should match the *nbyte* argument.
E.g. MPI_DOUBLE for double precision values.
To use the *read_grid()* method, the caller must provide one callback
function. To use the *write_grid()* method, it provides two callback
functions:
.. code-block:: c++
int unpack_read_grid(int nlines, char *buffer)
void pack_write_grid(int which, void *vbuf)
void unpack_write_grid(int which, void *vbuf, int *bounds)
For *unpack_read_grid()* the *nlines* argument is the number of lines
of character data read from the file and contained in *buffer*. The
lines each include a newline character at the end. When the function
processes the lines, it may choose to skip some of them (header or
comment lines). It returns an integer count of the number of grid
cell lines it processed. This enables the Grid class *read_file()*
method to know when it has read the correct number of lines.
For *pack_write_grid()* and *unpack_write_grid()*, the *vbuf* argument
is the buffer to pack/unpack data to/from. It is a void pointer so
that the caller can cast it to whatever data type it chooses,
e.g. double precision values. the *which* argument is set to the
*which* value of the *write_file()* method. It allows the caller to
choose which grid data to operate on.
For *unpack_write_grid()*, the *bounds* argument is a vector of 4 or 6
integer grid indices (4 for 2d, 6 for 3d). They are the
xlo,xhi,ylo,yhi,zlo,zhi index bounds of the portion of the global grid
which the *vbuf* holds owned grid cell data values for. The caller
should loop over the values in *vbuf* with a double loop (2d) or
triple loop (3d), similar to the code snippets listed above. The
x-index varies fastest, then y, and the z-index slowest. If there are
multiple values per grid cell, the index for those values varies
fastest of all. The caller can add the x,y,z indices of the grid cell
(or the corresponding grid cell ID) to the data value(s) written as
one line to the output file.
----------
Style class grid access methods
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A style command can enable its grid cell data to be accessible from
other commands. For example :doc:`fix ave/grid <fix_ave_grid>` or
:doc:`dump grid <dump>` or :doc:`dump grid/vtk <dump>`. Those
commands access the grid cell data by using a *grid reference* in
their input script syntax, as described on the :doc:`Howto_grid
<Howto_grid>` doc page. They look like this:
* c_ID:gname:dname
* c_ID:gname:dname[I]
* f_ID:gname:dname
* f_ID:gname:dname[I]
Each grid command instantiates has a unique *gname*, defined by the
command. Likewise each grid cell data structure (scalar or vector)
associated with a grid has a unique *dname*, also defined by the
command.
To provide access to its grid cell data, a style command needs to
implement the following 4 methods:
.. code-block:: c++
int get_grid_by_name(const std::string &name, int &dim);
void *get_grid_by_index(int index);
int get_griddata_by_name(int igrid, const std::string &name, int &ncol);
void *get_griddata_by_index(int index);
Currently only computes and fixes can implement these methods. If it
does so, the compute of fix should also set the variable
*pergrid_flag* to 1. See any of the compute or fix commands which set
"pergrid_flag = 1" for examples of how these 4 functions can be
implemented.
The *get_grid_by_name()* method takes a grid name as input and returns
two values. The *dim* argument is returned as 2 or 3 for the
dimensionality of the grid. The function return is a grid index from
0 to G-1 where *G* is the number of grids the command instantiates. A
value of -1 is returned if the grid name is not recognized.
The *get_grid_by_index()* method is called after the
*get_grid_by_name()* method, using the grid index it returned as its
argument. This method will return a pointer to the Grid2d or Grid3d
class. The caller can use this to query grid attributes, such as the
global size of the grid, to ensure it is of the expected size.
The *get_griddata_by_name()* method takes a grid index *igrid* and a
data name as input. It returns two values. The *ncol* argument is
returned as a 0 if the grid data is a single value (scalar) per grid
cell, or an integer M > 0 if there are M values (vector) per grid
cell. Note that even if M = 1, it is still a 1-length vector, not a
scalar. The function return is a data index from 0 to D-1 where *D*
is the number of data sets associated with that grid by the command.
A value of -1 is returned if the data name is not recognized.
The *get_griddata_by_index()* method is called after the
*get_griddata_by_name()* method, using the data index it returned as
its argument. This method will return a pointer to the
multidimensional array which stores the requested data.
As in the discussion above of the Memory class *create_offset()*
methods, the dimensionality of the array associated with the returned
pointer depends on whether it is a 2d or 3d grid and whether there is
a single or multiple values stored for each grid cell:
* single value per cell for a 2d grid = 2d array pointer
* multiple values per cell for a 2d grid = 3d array pointer
* single value per cell for a 3d grid = 3d array pointer
* multiple values per cell for a 3d grid = 4d array pointer
The caller will typically access the data by casting the void pointer
to the corresponding array pointer and using nested loops in x,y,z
between owned or ghost index bounds returned by the
*get_bounds_owned()* or *get_bounds_ghost()* methods to index into the
array. Example code snippets with this logic were listed above,
----------
Final notes
^^^^^^^^^^^
Finally, here are some additional issues to pay attention to for
writing any style command which uses distributed grids via the Grid2d
or Grid3d class.
The command destructor should delete all instances of the Grid class,
any buffers it allocated for forward/reverse or remap communication,
and any data arrays it allocated to store grid cell data.
If a command is intended to work for either 2d or 3d simulations, then
it should have logic to instantiate either 2d or 3d grids and their
associated data arrays, depending on the dimension of the simulation
box. The :doc:`fix ave/grid <fix_ave_grid>` command is an example of
such a command.
When a command maps its particles to the grid and updates grid cell
values, it should check that it is not updating or accessing a grid
cell value outside the range of its owned+ghost cells, and generate an
error message if that is the case. This could happen, for example, if
a particle has moved further than half the neighbor skin distance,
because the neighbor list update criterion are not adequate to prevent
it from happening. See the src/KSPACE/pppm.cpp file and its
*particle_map()* method for an example of this kind of error check.

47
doc/src/Developer_notes.rst
View File

@ -11,6 +11,7 @@ Available topics are:
- `Reading and parsing of text and text files`_
- `Requesting and accessing neighbor lists`_
- `Choosing between a custom atom style, fix property/atom, and fix STORE/ATOM`_
- `Fix contributions to instantaneous energy, virial, and cumulative energy`_
- `KSpace PPPM FFT grids`_
@ -73,6 +74,8 @@ when converting "12.5", while the ValueTokenizer class will throw an
:cpp:func:`ValueTokenizer::next_int()
<LAMMPS_NS::ValueTokenizer::next_int>` is called on the same string.
.. _request-neighbor-list:
Requesting and accessing neighbor lists
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -102,10 +105,10 @@ build is then :doc:`processed in parallel <Developer_par_neigh>`.
The most commonly required neighbor list is a so-called "half" neighbor
list, where each pair of atoms is listed only once (except when the
:doc:`newton command setting <newton>` for pair is off; in that case
pairs straddling sub-domains or periodic boundaries will be listed twice).
pairs straddling subdomains or periodic boundaries will be listed twice).
Thus these are the default settings when a neighbor list request is created in:
.. code-block:: C++
.. code-block:: c++
void Pair::init_style()
{
@ -129,7 +132,7 @@ neighbor list request to the specific needs of a style an additional
request flag is needed. The :doc:`tersoff <pair_tersoff>` pair style,
for example, needs a "full" neighbor list:
.. code-block:: C++
.. code-block:: c++
void PairTersoff::init_style()
{
@ -141,7 +144,7 @@ When a pair style supports r-RESPA time integration with different cutoff region
the request flag may depend on the corresponding r-RESPA settings. Here an example
from pair style lj/cut:
.. code-block:: C++
.. code-block:: c++
void PairLJCut::init_style()
{
@ -160,7 +163,7 @@ Granular pair styles need neighbor lists based on particle sizes and not cutoff
and also may require to have the list of previous neighbors available ("history").
For example with:
.. code-block:: C++
.. code-block:: c++
if (use_history) neighbor->add_request(this, NeighConst::REQ_SIZE | NeighConst::REQ_HISTORY);
else neighbor->add_request(this, NeighConst::REQ_SIZE);
@ -170,7 +173,7 @@ settings each request can set an id which is then used in the corresponding
``init_list()`` function to assign it to the suitable pointer variable. This is
done for example by the :doc:`pair style meam <pair_meam>`:
.. code-block:: C++
.. code-block:: c++
void PairMEAM::init_style()
{
@ -189,7 +192,7 @@ just once) and this can also be indicated by a flag. As an example here
is the request from the ``FixPeriNeigh`` class which is created
internally by :doc:`Peridynamics pair styles <pair_peri>`:
.. code-block:: C++
.. code-block:: c++
neighbor->add_request(this, NeighConst::REQ_FULL | NeighConst::REQ_OCCASIONAL);
@ -198,7 +201,7 @@ than what is usually inferred from the pair style settings (largest cutoff of
all pair styles plus neighbor list skin). The following is used in the
:doc:`compute rdf <compute_rdf>` command implementation:
.. code-block:: C++
.. code-block:: c++
if (cutflag)
neighbor->add_request(this, NeighConst::REQ_OCCASIONAL)->set_cutoff(mycutneigh);
@ -212,10 +215,34 @@ for printing the neighbor list summary the name of the requesting command
should be set. Below is the request from the :doc:`delete atoms <delete_atoms>`
command:
.. code-block:: C++
.. code-block:: c++
neighbor->add_request(this, "delete_atoms", NeighConst::REQ_FULL);
Choosing between a custom atom style, fix property/atom, and fix STORE/ATOM
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
There are multiple ways to manage per-atom data within LAMMPS. Often
the per-atom storage is only used locally and managed by the class that
uses it. If the data has to persist between multiple time steps and
migrate with atoms when they move from sub-domain to sub-domain or
across periodic boundaries, then using a custom atom style, or :doc:`fix
property/atom <fix_property_atom>`, or the internal fix STORE/ATOM are
possible options.
- Using the atom style is usually the most programming effort and mostly
needed when the per-atom data is an integral part of the model like a
per-atom charge or diameter and thus should be part of the Atoms
section of a :doc:`data file <read_data>`.
- Fix property/atom is useful if the data is optional or should be
entered by the user, or accessed as a (named) custom property. In this
case the fix should be entered as part of the input (and not
internally) which allows to enter and store its content with data files.
- Fix STORE/ATOM should be used when the data should be accessed internally
only and thus the fix can be created internally.
Fix contributions to instantaneous energy, virial, and cumulative energy
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -361,7 +388,7 @@ allocated as a 1d vector or 3d array. Either way, the ordering of
values within contiguous memory x fastest, then y, z slowest.
For the ``3d decomposition`` of the grid, the global grid is
partitioned into bricks that correspond to the sub-domains of the
partitioned into bricks that correspond to the subdomains of the
simulation box that each processor owns. Often, this is a regular 3d
array (Px by Py by Pz) of bricks, where P = number of processors =
Px * Py * Pz. More generally it can be a tiled decomposition, where

161
doc/src/Developer_org.rst
View File

@ -7,7 +7,7 @@ but there are small a number of files in several other languages like C,
Fortran, Shell script, or Python.
The core of the code is located in the ``src`` folder and its
sub-directories. A sizable number of these files are in the ``src``
subdirectories. A sizable number of these files are in the ``src``
directory itself, but there are plenty of :doc:`packages <Packages>`,
which can be included or excluded when LAMMPS is built. See the
:doc:`Include packages in build <Build_package>` section of the manual
@ -15,42 +15,42 @@ for more information about that part of the build process. LAMMPS
currently supports building with :doc:`conventional makefiles
<Build_make>` and through :doc:`CMake <Build_cmake>`. Those procedures
differ in how packages are enabled or disabled for inclusion into a
LAMMPS binary so they cannot be mixed. The source files for each
package are in all-uppercase sub-directories of the ``src`` folder, for
LAMMPS binary, so they cannot be mixed. The source files for each
package are in all-uppercase subdirectories of the ``src`` folder, for
example ``src/MOLECULE`` or ``src/EXTRA-MOLECULE``. The ``src/STUBS``
sub-directory is not a package but contains a dummy MPI library, that is
subdirectory is not a package but contains a dummy MPI library, that is
used when building a serial version of the code. The ``src/MAKE``
directory and its sub-directories contain makefiles with settings and
directory and its subdirectories contain makefiles with settings and
flags for a variety of configuration and machines for the build process
with traditional makefiles.
The ``lib`` directory contains the source code for several supporting
libraries or files with configuration settings to use globally installed
libraries, that are required by some of the optional packages. They may
libraries, that are required by some optional packages. They may
include python scripts that can transparently download additional source
code on request. Each sub-directory, like ``lib/poems`` or ``lib/gpu``,
code on request. Each subdirectory, like ``lib/poems`` or ``lib/gpu``,
contains the source files, some of which are in different languages such
as Fortran or CUDA. These libraries included in the LAMMPS build,
if the corresponding package is installed.
as Fortran or CUDA. These libraries included in the LAMMPS build, if the
corresponding package is installed.
LAMMPS C++ source files almost always come in pairs, such as
``src/run.cpp`` (implementation file) and ``src/run.h`` (header file).
Each pair of files defines a C++ class, for example the
:cpp:class:`LAMMPS_NS::Run` class which contains the code invoked by the
:doc:`run <run>` command in a LAMMPS input script. As this example
:cpp:class:`LAMMPS_NS::Run` class, which contains the code invoked by
the :doc:`run <run>` command in a LAMMPS input script. As this example
illustrates, source file and class names often have a one-to-one
correspondence with a command used in a LAMMPS input script. Some
source files and classes do not have a corresponding input script
command, e.g. ``src/force.cpp`` and the :cpp:class:`LAMMPS_NS::Force`
command, for example ``src/force.cpp`` and the :cpp:class:`LAMMPS_NS::Force`
class. They are discussed in the next section.
The names of all source files are in lower case and may use the
underscore character '_' to separate words. Outside of bundled libraries
which may have different conventions, all C and C++ header files have a
``.h`` extension, all C++ files have a ``.cpp`` extension, and C files a
``.c`` extension. A small number of C++ classes and utility functions
are implemented with only a ``.h`` file. Examples are the Pointers and
Commands classes or the MathVec functions.
underscore character '_' to separate words. Apart from bundled,
externally maintained libraries, which may have different conventions,
all C and C++ header files have a ``.h`` extension, all C++ files have a
``.cpp`` extension, and C files a ``.c`` extension. A few C++ classes
and utility functions are implemented with only a ``.h`` file. Examples
are the Pointers and Commands classes or the MathVec functions.
Class topology
--------------
@ -62,35 +62,36 @@ associated source files in the ``src`` folder, for example the class
:cpp:class:`LAMMPS_NS::Memory` corresponds to the files ``memory.cpp``
and ``memory.h``, or the class :cpp:class:`LAMMPS_NS::AtomVec`
corresponds to the files ``atom_vec.cpp`` and ``atom_vec.h``. Full
lines in the figure represent compositing: that is the class at the base
of the arrow holds a pointer to an instance of the class at the tip.
Dashed lines instead represent inheritance: the class to the tip of the
arrow is derived from the class at the base. Classes with a red boundary
are not instantiated directly, but they represent the base classes for
"styles". Those "styles" make up the bulk of the LAMMPS code and only
a few representative examples are included in the figure so it remains
readable.
lines in the figure represent compositing: that is, the class at the
base of the arrow holds a pointer to an instance of the class at the
tip. Dashed lines instead represent inheritance: the class at the tip
of the arrow is derived from the class at the base. Classes with a red
boundary are not instantiated directly, but they represent the base
classes for "styles". Those "styles" make up the bulk of the LAMMPS
code and only a few representative examples are included in the figure,
so it remains readable.
.. _class-topology:
.. figure:: JPG/lammps-classes.png
LAMMPS class topology
This figure shows some of the relations of the base classes of the
LAMMPS simulation package. Full lines indicate that a class holds an
instance of the class it is pointing to; dashed lines point to
derived classes that are given as examples of what classes may be
instantiated during a LAMMPS run based on the input commands and
accessed through the API define by their respective base classes. At
the core is the :cpp:class:`LAMMPS <LAMMPS_NS::LAMMPS>` class, which
holds pointers to class instances with specific purposes. Those may
hold instances of other classes, sometimes directly, or only
temporarily, sometimes as derived classes or derived classes of
derived classes, which may also hold instances of other classes.
This figure shows relations of base classes of the LAMMPS
simulation package. Full lines indicate that a class holds an
instance of the class it is pointing to; dashed lines point to
derived classes that are given as examples of what classes may be
instantiated during a LAMMPS run based on the input commands and
accessed through the API define by their respective base classes.
At the core is the :cpp:class:`LAMMPS <LAMMPS_NS::LAMMPS>` class,
which holds pointers to class instances with specific purposes.
Those may hold instances of other classes, sometimes directly, or
only temporarily, sometimes as derived classes or derived classes
of derived classes, which may also hold instances of other
classes.
The :cpp:class:`LAMMPS_NS::LAMMPS` class is the topmost class and
represents what is generally referred to an "instance" of LAMMPS. It is
a composite holding pointers to instances of other core classes
represents what is generally referred to as an "instance of LAMMPS". It
is a composite holding pointers to instances of other core classes
providing the core functionality of the MD engine in LAMMPS and through
them abstractions of the required operations. The constructor of the
LAMMPS class will instantiate those instances, process the command line
@ -102,42 +103,44 @@ LAMMPS while passing it the command line flags and input script. It
deletes the LAMMPS instance after the method reading the input returns
and shuts down the MPI environment before it exits the executable.
The :cpp:class:`LAMMPS_NS::Pointers` is not shown in the
The :cpp:class:`LAMMPS_NS::Pointers` class is not shown in the
:ref:`class-topology` figure for clarity. It holds references to many
of the members of the `LAMMPS_NS::LAMMPS`, so that all classes derived
from :cpp:class:`LAMMPS_NS::Pointers` have direct access to those
reference. From the class topology all classes with blue boundary are
references. From the class topology all classes with blue boundary are
referenced in the Pointers class and all classes in the second and third
columns, that are not listed as derived classes are instead derived from
:cpp:class:`LAMMPS_NS::Pointers`. To initialize the pointer references
in Pointers, a pointer to the LAMMPS class instance needs to be passed
to the constructor and thus all constructors for classes derived from it
must do so and pass this pointer to the constructor for Pointers.
columns, that are not listed as derived classes, are instead derived
from :cpp:class:`LAMMPS_NS::Pointers`. To initialize the pointer
references in Pointers, a pointer to the LAMMPS class instance needs to
be passed to the constructor. All constructors for classes derived from
it, must do so and thus pass that pointer to the constructor for
:cpp:class:`LAMMPS_NS::Pointers`. The default constructor for
:cpp:class:`LAMMPS_NS::Pointers` is disabled to enforce this.
Since all storage is supposed to be encapsulated (there are a few
exceptions), the LAMMPS class can also be instantiated multiple times by
a calling code. Outside of the aforementioned exceptions, those LAMMPS
a calling code. Outside the aforementioned exceptions, those LAMMPS
instances can be used alternately. As of the time of this writing
(early 2021) LAMMPS is not yet sufficiently thread-safe for concurrent
(early 2023) LAMMPS is not yet sufficiently thread-safe for concurrent
execution. When running in parallel with MPI, care has to be taken,
that suitable copies of communicators are used to not create conflicts
between different instances.
The LAMMPS class currently (early 2021) holds instances of 19 classes
representing the core functionality. There are a handful of virtual
parent classes in LAMMPS that define what LAMMPS calls ``styles``. They
are shaded red in the :ref:`class-topology` figure. Each of these are
parents of a number of child classes that implement the interface
defined by the parent class. There are two main categories of these
``styles``: some may only have one instance active at a time (e.g. atom,
pair, bond, angle, dihedral, improper, kspace, comm) and there is a
dedicated pointer variable for each of them in the composite class.
The LAMMPS class currently holds instances of 19 classes representing
the core functionality. There are a handful of virtual parent classes
in LAMMPS that define what LAMMPS calls ``styles``. These are shaded
red in the :ref:`class-topology` figure. Each of these are parents of a
number of child classes that implement the interface defined by the
parent class. There are two main categories of these ``styles``: some
may only have one instance active at a time (e.g. atom, pair, bond,
angle, dihedral, improper, kspace, comm) and there is a dedicated
pointer variable for each of them in the corresponding composite class.
Setups that require a mix of different such styles have to use a
*hybrid* class that takes the place of the one allowed instance and then
manages and forwards calls to the corresponding sub-styles for the
designated subset of atoms or data. The composite class may also have
lists of class instances, e.g. Modify handles lists of compute and fix
styles, while Output handles a list of dump class instances.
*hybrid* class instance that acts as a proxy, and manages and forwards
calls to the corresponding sub-style class instances for the designated
subset of atoms or data. The composite class may also have lists of
class instances, e.g. ``Modify`` handles lists of compute and fix
styles, while ``Output`` handles a list of dump class instances.
The exception to this scheme are the ``command`` style classes. These
implement specific commands that can be invoked before, after, or in
@ -146,19 +149,19 @@ command() method called and then, after completion, the class instance
deleted. Examples for this are the create_box, create_atoms, minimize,
run, set, or velocity command styles.
For all those ``styles`` certain naming conventions are employed: for
For all those ``styles``, certain naming conventions are employed: for
the fix nve command the class is called FixNVE and the source files are
``fix_nve.h`` and ``fix_nve.cpp``. Similarly for fix ave/time we have
``fix_nve.h`` and ``fix_nve.cpp``. Similarly, for fix ave/time we have
FixAveTime and ``fix_ave_time.h`` and ``fix_ave_time.cpp``. Style names
are lower case and without spaces or special characters. A suffix or
words are appended with a forward slash '/' which denotes a variant of
the corresponding class without the suffix. To connect the style name
and the class name, LAMMPS uses macros like: ``AtomStyle()``,
``PairStyle()``, ``BondStyle()``, ``RegionStyle()``, and so on in the
corresponding header file. During configuration or compilation files
corresponding header file. During configuration or compilation, files
with the pattern ``style_<name>.h`` are created that consist of a list
of include statements including all headers of all styles of a given
type that are currently active (or "installed).
type that are currently enabled (or "installed").
More details on individual classes in the :ref:`class-topology` are as
@ -172,8 +175,8 @@ follows:
that one or multiple simulations can be run, on the processors
allocated for a run, e.g. by the mpirun command.
- The Input class reads and processes input input strings and files,
stores variables, and invokes :doc:`commands <Commands_all>`.
- The Input class reads and processes input (strings and files), stores
variables, and invokes :doc:`commands <Commands_all>`.
- Command style classes are derived from the Command class. They provide
input script commands that perform one-time operations
@ -192,7 +195,7 @@ follows:
- The Atom class stores per-atom properties associated with atom styles.
More precisely, they are allocated and managed by a class derived from
the AtomVec class, and the Atom class simply stores pointers to them.
The classes derived from AtomVec represent the different atom styles
The classes derived from AtomVec represent the different atom styles,
and they are instantiated through the :doc:`atom_style <atom_style>`
command.
@ -206,18 +209,22 @@ follows:
class stores a single list (for all atoms). A NeighRequest class
instance is created by pair, fix, or compute styles when they need a
particular kind of neighbor list and use the NeighRequest properties
to select the neighbor list settings for the given request. There can
be multiple instances of the NeighRequest class and the Neighbor class
will try to optimize how they are computed by creating copies or
sub-lists where possible.
to select the neighbor list settings for the given request. There can
be multiple instances of the NeighRequest class. The Neighbor class
will try to optimize how the requests are processed. Depending on the
NeighRequest properties, neighbor lists are constructed from scratch,
aliased, or constructed by post-processing an existing list into
sub-lists.
- The Comm class performs inter-processor communication, typically of
ghost atom information. This usually involves MPI message exchanges
with 6 neighboring processors in the 3d logical grid of processors
mapped to the simulation box. There are two :doc:`communication styles
<comm_style>` enabling different ways to do the domain decomposition.
Sometimes the Irregular class is used, when atoms may migrate to
arbitrary processors.
<comm_style>`, enabling different ways to perform the domain
decomposition.
- The Irregular class is used, when atoms may migrate to arbitrary
processors.
- The Domain class stores the simulation box geometry, as well as
geometric Regions and any user definition of a Lattice. The latter
@ -246,7 +253,7 @@ follows:
file, dump file snapshots, and restart files. These correspond to the
:doc:`Thermo <thermo_style>`, :doc:`Dump <dump>`, and
:doc:`WriteRestart <write_restart>` classes respectively. The Dump
class is a base class with several derived classes implementing
class is a base class, with several derived classes implementing
various dump style variants.
- The Timer class logs timing information, output at the end

36
doc/src/Developer_par_comm.rst
View File

@ -1,22 +1,22 @@
Communication
^^^^^^^^^^^^^
Following the partitioning scheme in use all per-atom data is
Following the selected partitioning scheme, all per-atom data is
distributed across the MPI processes, which allows LAMMPS to handle very
large systems provided it uses a correspondingly large number of MPI
processes. Since The per-atom data (atom IDs, positions, velocities,
types, etc.) To be able to compute the short-range interactions MPI
processes need not only access to data of atoms they "own" but also
information about atoms from neighboring sub-domains, in LAMMPS referred
types, etc.) To be able to compute the short-range interactions, MPI
processes need not only access to the data of atoms they "own" but also
information about atoms from neighboring subdomains, in LAMMPS referred
to as "ghost" atoms. These are copies of atoms storing required
per-atom data for up to the communication cutoff distance. The green
dashed-line boxes in the :ref:`domain-decomposition` figure illustrate
the extended ghost-atom sub-domain for one processor.
the extended ghost-atom subdomain for one processor.
This approach is also used to implement periodic boundary
conditions: atoms that lie within the cutoff distance across a periodic
boundary are also stored as ghost atoms and taken from the periodic
replication of the sub-domain, which may be the same sub-domain, e.g. if
replication of the subdomain, which may be the same subdomain, e.g. if
running in serial. As a consequence of this, force computation in
LAMMPS is not subject to minimum image conventions and thus cutoffs may
be larger than half the simulation domain.
@ -28,10 +28,10 @@ be larger than half the simulation domain.
ghost atom communication
This figure shows the ghost atom communication patterns between
sub-domains for "brick" (left) and "tiled" communication styles for
subdomains for "brick" (left) and "tiled" communication styles for
2d simulations. The numbers indicate MPI process ranks. Here the
sub-domains are drawn spatially separated for clarity. The
dashed-line box is the extended sub-domain of processor 0 which
subdomains are drawn spatially separated for clarity. The
dashed-line box is the extended subdomain of processor 0 which
includes its ghost atoms. The red- and blue-shaded boxes are the
regions of communicated ghost atoms.
@ -42,7 +42,7 @@ atom communication is performed in two stages for a 2d simulation (three
in 3d) for both a regular and irregular partitioning of the simulation
box. For the regular case (left) atoms are exchanged first in the
*x*-direction, then in *y*, with four neighbors in the grid of processor
sub-domains.
subdomains.
In the *x* stage, processor ranks 1 and 2 send owned atoms in their
red-shaded regions to rank 0 (and vice versa). Then in the *y* stage,
@ -55,11 +55,11 @@ For the irregular case (right) the two stages are similar, but a
processor can have more than one neighbor in each direction. In the
*x* stage, MPI ranks 1,2,3 send owned atoms in their red-shaded regions to
rank 0 (and vice versa). These include only atoms between the lower
and upper *y*-boundary of rank 0's sub-domain. In the *y* stage, ranks
and upper *y*-boundary of rank 0's subdomain. In the *y* stage, ranks
4,5,6 send atoms in their blue-shaded regions to rank 0. This may
include ghost atoms they received in the *x* stage, but only if they
are needed by rank 0 to fill its extended ghost atom regions in the
+/-*y* directions (blue rectangles). Thus in this case, ranks 5 and
+/-*y* directions (blue rectangles). Thus, in this case, ranks 5 and
6 do not include ghost atoms they received from each other (in the *x*
stage) in the atoms they send to rank 0. The key point is that while
the pattern of communication is more complex in the irregular
@ -78,14 +78,14 @@ A "reverse" communication is when computed ghost atom attributes are
sent back to the processor who owns the atom. This is used (for
example) to sum partial forces on ghost atoms to the complete force on
owned atoms. The order of the two stages described in the
:ref:`ghost-atom-comm` figure is inverted and the same lists of atoms
:ref:`ghost-atom-comm` figure is inverted, and the same lists of atoms
are used to pack and unpack message buffers with per-atom forces. When
a received buffer is unpacked, the ghost forces are summed to owned atom
forces. As in forward communication, forces on atoms in the four blue
corners of the diagrams are sent, received, and summed twice (once at
each stage) before owning processors have the full force.
These two operations are used many places within LAMMPS aside from
These two operations are used in many places within LAMMPS aside from
exchange of coordinates and forces, for example by manybody potentials
to share intermediate per-atom values, or by rigid-body integrators to
enable each atom in a body to access body properties. Here are
@ -105,16 +105,16 @@ performed in LAMMPS:
atom pairs when building neighbor lists or computing forces.
- The cutoff distance for exchanging ghost atoms is typically equal to
the neighbor cutoff. But it can also chosen to be longer if needed,
the neighbor cutoff. But it can also set to a larger value if needed,
e.g. half the diameter of a rigid body composed of multiple atoms or
over 3x the length of a stretched bond for dihedral interactions. It
can also exceed the periodic box size. For the regular communication
pattern (left), if the cutoff distance extends beyond a neighbor
processor's sub-domain, then multiple exchanges are performed in the
processor's subdomain, then multiple exchanges are performed in the
same direction. Each exchange is with the same neighbor processor,
but buffers are packed/unpacked using a different list of atoms. For
forward communication, in the first exchange a processor sends only
forward communication, in the first exchange, a processor sends only
owned atoms. In subsequent exchanges, it sends ghost atoms received
in previous exchanges. For the irregular pattern (right) overlaps of
a processor's extended ghost-atom sub-domain with all other processors
a processor's extended ghost-atom subdomain with all other processors
in each dimension are detected.

70
doc/src/Developer_par_long.rst
View File

@ -20,7 +20,7 @@ e) electric field values from grid points near each atom are interpolated to com
For any of the spatial-decomposition partitioning schemes each processor
owns the brick-shaped portion of FFT grid points contained within its
sub-domain. The two interpolation operations use a stencil of grid
subdomain. The two interpolation operations use a stencil of grid
points surrounding each atom. To accommodate the stencil size, each
processor also stores a few layers of ghost grid points surrounding its
brick. Forward and reverse communication of grid point values is
@ -40,31 +40,31 @@ orthogonal boxes.
.. _fft-parallel:
.. figure:: img/fft-decomp-parallel.png
:align: center
parallel FFT in PPPM
Parallel FFT in PPPM
Stages of a parallel FFT for a simulation domain overlaid
with an 8x8x8 3d FFT grid, partitioned across 64 processors.
Within each of the 4 diagrams, grid cells of the same color are
owned by a single processor; for simplicity only cells owned by 4
or 8 of the 64 processors are colored. The two images on the left
illustrate brick-to-pencil communication. The two images on the
right illustrate pencil-to-pencil communication, which in this
case transposes the *y* and *z* dimensions of the grid.
Stages of a parallel FFT for a simulation domain overlaid with an
8x8x8 3d FFT grid, partitioned across 64 processors. Within each
of the 4 diagrams, grid cells of the same color are owned by a
single processor; for simplicity, only cells owned by 4 or 8 of
the 64 processors are colored. The two images on the left
illustrate brick-to-pencil communication. The two images on the
right illustrate pencil-to-pencil communication, which in this
case transposes the *y* and *z* dimensions of the grid.
Parallel 3d FFTs require substantial communication relative to their
computational cost. A 3d FFT is implemented by a series of 1d FFTs
along the *x-*, *y-*, and *z-*\ direction of the FFT grid. Thus the FFT
grid cannot be decomposed like atoms into 3 dimensions for parallel
along the *x-*, *y-*, and *z-*\ direction of the FFT grid. Thus, the
FFT grid cannot be decomposed like atoms into 3 dimensions for parallel
processing of the FFTs but only in 1 (as planes) or 2 (as pencils)
dimensions and in between the steps the grid needs to be transposed to
have the FFT grid portion "owned" by each MPI process complete in the
direction of the 1d FFTs it has to perform. LAMMPS uses the
pencil-decomposition algorithm as shown in the :ref:`fft-parallel` figure.
pencil-decomposition algorithm as shown in the :ref:`fft-parallel`
figure.
Initially (far left), each processor owns a brick of same-color grid
cells (actually grid points) contained within in its sub-domain. A
cells (actually grid points) contained within in its subdomain. A
brick-to-pencil communication operation converts this layout to 1d
pencils in the *x*-dimension (center left). Again, cells of the same
color are owned by the same processor. Each processor can then compute
@ -97,7 +97,7 @@ across all $P$ processors with a single call to ``MPI_Alltoall()``, but
this is typically much slower. However, for the specialized brick and
pencil tiling illustrated in :ref:`fft-parallel` figure, collective
communication across the entire MPI communicator is not required. In
the example an :math:`8^3` grid with 512 grid cells is partitioned
the example, an :math:`8^3` grid with 512 grid cells is partitioned
across 64 processors; each processor owns a 2x2x2 3d brick of grid
cells. The initial brick-to-pencil communication (upper left to upper
right) only requires collective communication within subgroups of 4
@ -132,7 +132,7 @@ grid/particle operations that LAMMPS supports:
- The fftMPI library allows each grid dimension to be a multiple of
small prime factors (2,3,5), and allows any number of processors to
perform the FFT. The resulting brick and pencil decompositions are
thus not always as well-aligned but the size of subgroups of
thus not always as well-aligned, but the size of subgroups of
processors for the two modes of communication (brick/pencil and
pencil/pencil) still scale as :math:`O(P^{\frac{1}{3}})` and
:math:`O(P^{\frac{1}{2}})`.
@ -143,26 +143,28 @@ grid/particle operations that LAMMPS supports:
in memory. This reordering can be done during the packing or
unpacking of buffers for MPI communication.
- For large systems and particularly a large number of MPI processes,
the dominant cost for parallel FFTs is often the communication, not
the computation of 1d FFTs, even though the latter scales as :math:`N
\log(N)` in the number of grid points *N* per grid direction. This is
due to the fact that only a 2d decomposition into pencils is possible
while atom data (and their corresponding short-range force and energy
computations) can be decomposed efficiently in 3d.
- For large systems and particularly many MPI processes, the dominant
cost for parallel FFTs is often the communication, not the computation
of 1d FFTs, even though the latter scales as :math:`N \log(N)` in the
number of grid points *N* per grid direction. This is due to the fact
that only a 2d decomposition into pencils is possible while atom data
(and their corresponding short-range force and energy computations)
can be decomposed efficiently in 3d.
This can be addressed by reducing the number of MPI processes involved
in the MPI communication by using :doc:`hybrid MPI + OpenMP
parallelization <Speed_omp>`. This will use OpenMP parallelization
inside the MPI domains and while that may have a lower parallel
efficiency, it reduces the communication overhead.
Reducing the number of MPI processes involved in the MPI communication
will reduce this kind of overhead. By using a :doc:`hybrid MPI +
OpenMP parallelization <Speed_omp>` it is still possible to use all
processes for parallel computation. It will use OpenMP
parallelization inside the MPI domains. While that may have a lower
parallel efficiency for some part of the computation, that can be less
than the communication overhead in the 3d FFTs.
As an alternative it is also possible to start a :ref:`multi-partition
As an alternative, it is also possible to start a :ref:`multi-partition
<partition>` calculation and then use the :doc:`verlet/split
integrator <run_style>` to perform the PPPM computation on a
dedicated, separate partition of MPI processes. This uses an integer
"1:*p*" mapping of *p* sub-domains of the atom decomposition to one
sub-domain of the FFT grid decomposition and where pairwise non-bonded
"1:*p*" mapping of *p* subdomains of the atom decomposition to one
subdomain of the FFT grid decomposition and where pairwise non-bonded
and bonded forces and energies are computed on the larger partition
and the PPPM kspace computation concurrently on the smaller partition.
@ -172,10 +174,10 @@ grid/particle operations that LAMMPS supports:
- LAMMPS implements a ``GridComm`` class which overlays the simulation
domain with a regular grid, partitions it across processors in a
manner consistent with processor sub-domains, and provides methods for
manner consistent with processor subdomains, and provides methods for
forward and reverse communication of owned and ghost grid point
values. It is used for PPPM as an FFT grid (as outlined above) and
also for the MSM algorithm which uses a cascade of grid sizes from
also for the MSM algorithm, which uses a cascade of grid sizes from
fine to coarse to compute long-range Coulombic forces. The GridComm
class is also useful for models where continuum fields interact with
particles. For example, the two-temperature model (TTM) defines heat

62
doc/src/Developer_par_neigh.rst
View File

@ -3,12 +3,12 @@ Neighbor lists
To compute forces efficiently, each processor creates a Verlet-style
neighbor list which enumerates all pairs of atoms *i,j* (*i* = owned,
*j* = owned or ghost) with separation less than the applicable
neighbor list cutoff distance. In LAMMPS the neighbor lists are stored
in a multiple-page data structure; each page is a contiguous chunk of
memory which stores vectors of neighbor atoms *j* for many *i* atoms.
This allows pages to be incrementally allocated or deallocated in blocks
as needed. Neighbor lists typically consume the most memory of any data
*j* = owned or ghost) with separation less than the applicable neighbor
list cutoff distance. In LAMMPS, the neighbor lists are stored in a
multiple-page data structure; each page is a contiguous chunk of memory
which stores vectors of neighbor atoms *j* for many *i* atoms. This
allows pages to be incrementally allocated or deallocated in blocks as
needed. Neighbor lists typically consume the most memory of any data
structure in LAMMPS. The neighbor list is rebuilt (from scratch) once
every few timesteps, then used repeatedly each step for force or other
computations. The neighbor cutoff distance is :math:`R_n = R_f +
@ -16,20 +16,20 @@ computations. The neighbor cutoff distance is :math:`R_n = R_f +
the interatomic potential for computing short-range pairwise or manybody
forces and :math:`\Delta_s` is a "skin" distance that allows the list to
be used for multiple steps assuming that atoms do not move very far
between consecutive time steps. Typically the code triggers
between consecutive time steps. Typically, the code triggers
reneighboring when any atom has moved half the skin distance since the
last reneighboring; this and other options of the neighbor list rebuild
can be adjusted with the :doc:`neigh_modify <neigh_modify>` command.
On steps when reneighboring is performed, atoms which have moved outside
their owning processor's sub-domain are first migrated to new processors
their owning processor's subdomain are first migrated to new processors
via communication. Periodic boundary conditions are also (only)
enforced on these steps to ensure each atom is re-assigned to the
correct processor. After migration, the atoms owned by each processor
are stored in a contiguous vector. Periodically each processor
are stored in a contiguous vector. Periodically, each processor
spatially sorts owned atoms within its vector to reorder it for improved
cache efficiency in force computations and neighbor list building. For
that atoms are spatially binned and then reordered so that atoms in the
that, atoms are spatially binned and then reordered so that atoms in the
same bin are adjacent in the vector. Atom sorting can be disabled or
its settings modified with the :doc:`atom_modify <atom_modify>` command.
@ -39,12 +39,12 @@ its settings modified with the :doc:`atom_modify <atom_modify>` command.
neighbor list stencils
A 2d simulation sub-domain (thick black line) and the corresponding
A 2d simulation subdomain (thick black line) and the corresponding
ghost atom cutoff region (dashed blue line) for both orthogonal
(left) and triclinic (right) domains. A regular grid of neighbor
bins (thin lines) overlays the entire simulation domain and need not
align with sub-domain boundaries; only the portion overlapping the
augmented sub-domain is shown. In the triclinic case it overlaps the
align with subdomain boundaries; only the portion overlapping the
augmented subdomain is shown. In the triclinic case, it overlaps the
bounding box of the tilted rectangle. The blue- and red-shaded bins
represent a stencil of bins searched to find neighbors of a particular
atom (black dot).
@ -52,13 +52,13 @@ its settings modified with the :doc:`atom_modify <atom_modify>` command.
To build a local neighbor list in linear time, the simulation domain is
overlaid (conceptually) with a regular 3d (or 2d) grid of neighbor bins,
as shown in the :ref:`neighbor-stencil` figure for 2d models and a
single MPI processor's sub-domain. Each processor stores a set of
neighbor bins which overlap its sub-domain extended by the neighbor
single MPI processor's subdomain. Each processor stores a set of
neighbor bins which overlap its subdomain, extended by the neighbor
cutoff distance :math:`R_n`. As illustrated, the bins need not align
with processor boundaries; an integer number in each dimension is fit to
the size of the entire simulation box.
Most often LAMMPS builds what it calls a "half" neighbor list where
Most often, LAMMPS builds what is called a "half" neighbor list where
each *i,j* neighbor pair is stored only once, with either atom *i* or
*j* as the central atom. The build can be done efficiently by using a
pre-computed "stencil" of bins around a central origin bin which
@ -67,18 +67,18 @@ is simply a list of integer offsets in *x,y,z* of nearby bins
surrounding the origin bin which are close enough to contain any
neighbor atom *j* within a distance :math:`R_n` from any atom *i* in the
origin bin. Note that for a half neighbor list, the stencil can be
asymmetric since each atom only need store half its nearby neighbors.
asymmetric, since each atom only need store half its nearby neighbors.
These stencils are illustrated in the figure for a half list and a bin
size of :math:`\frac{1}{2} R_n`. There are 13 red+blue stencil bins in
2d (for the orthogonal case, 15 for triclinic). In 3d there would be
63, 13 in the plane of bins that contain the origin bin and 25 in each
of the two planes above it in the *z* direction (75 for triclinic). The
reason the triclinic stencil has extra bins is because the bins tile the
bounding box of the entire triclinic domain and thus are not periodic
with respect to the simulation box itself. The stencil and logic for
determining which *i,j* pairs to include in the neighbor list are
altered slightly to account for this.
triclinic stencil has extra bins because the bins tile the bounding box
of the entire triclinic domain, and thus are not periodic with respect
to the simulation box itself. The stencil and logic for determining
which *i,j* pairs to include in the neighbor list are altered slightly
to account for this.
To build a neighbor list, a processor first loops over its "owned" plus
"ghost" atoms and assigns each to a neighbor bin. This uses an integer
@ -95,7 +95,7 @@ supports:
been found to be optimal for many typical cases. Smaller bins incur
additional overhead to loop over; larger bins require more distance
calculations. Note that for smaller bin sizes, the 2d stencil in the
figure would be more semi-circular in shape (hemispherical in 3d),
figure would be of a more semicircular shape (hemispherical in 3d),
with bins near the corners of the square eliminated due to their
distance from the origin bin.
@ -111,8 +111,8 @@ supports:
symmetric stencil. It also includes lists with partial enumeration of
ghost atom neighbors. The full and ghost-atom lists are used by
various manybody interatomic potentials. Lists may also use different
criteria for inclusion of a pair interaction. Typically this simply
depends only on the distance between two atoms and the cutoff
criteria for inclusion of a pairwise interaction. Typically, this
simply depends only on the distance between two atoms and the cutoff
distance. But for finite-size coarse-grained particles with
individual diameters (e.g. polydisperse granular particles), it can
also depend on the diameters of the two particles.
@ -121,11 +121,11 @@ supports:
of the master neighbor list for the full system need to be generated,
one for each sub-style, which contains only the *i,j* pairs needed to
compute interactions between subsets of atoms for the corresponding
potential. This means not all *i* or *j* atoms owned by a processor
potential. This means, not all *i* or *j* atoms owned by a processor
are included in a particular sub-list.
- Some models use different cutoff lengths for pairwise interactions
between different kinds of particles which are stored in a single
between different kinds of particles, which are stored in a single
neighbor list. One example is a solvated colloidal system with large
colloidal particles where colloid/colloid, colloid/solvent, and
solvent/solvent interaction cutoffs can be dramatically different.
@ -144,7 +144,7 @@ supports:
- For small and sparse systems and as a fallback method, LAMMPS also
supports neighbor list construction without binning by using a full
:math:`O(N^2)` loop over all *i,j* atom pairs in a sub-domain when
:math:`O(N^2)` loop over all *i,j* atom pairs in a subdomain when
using the :doc:`neighbor nsq <neighbor>` command.
- Dependent on the "pair" setting of the :doc:`newton <newton>` command,
@ -153,7 +153,7 @@ supports:
For the newton pair *on* setting the atom *j* is only added to the
list if its *z* coordinate is larger, or if equal the *y* coordinate
is larger, and that is equal, too, the *x* coordinate is larger. For
homogeneously dense systems that will result in picking neighbors from
homogeneously dense systems, that will result in picking neighbors from
a same size sector in always the same direction relative to the
"owned" atom and thus it should lead to similar length neighbor lists
and thus reduce the chance of a load imbalance.
"owned" atom, and thus it should lead to similar length neighbor lists
and reduce the chance of a load imbalance.

38
doc/src/Developer_par_openmp.rst
View File

@ -6,7 +6,7 @@ thread parallelism to predominantly distribute loops over local data
and thus follow an orthogonal parallelization strategy to the
decomposition into spatial domains used by the :doc:`MPI partitioning
<Developer_par_part>`. For clarity, this section discusses only the
implementation in the OPENMP package as it is the simplest. The INTEL
implementation in the OPENMP package, as it is the simplest. The INTEL
and KOKKOS package offer additional options and are more complex since
they support more features and different hardware like co-processors
or GPUs.
@ -14,7 +14,7 @@ or GPUs.
One of the key decisions when implementing the OPENMP package was to
keep the changes to the source code small, so that it would be easier to
maintain the code and keep it in sync with the non-threaded standard
implementation. this is achieved by a) making the OPENMP version a
implementation. This is achieved by a) making the OPENMP version a
derived class from the regular version (e.g. ``PairLJCutOMP`` from
``PairLJCut``) and overriding only methods that are multi-threaded or
need to be modified to support multi-threading (similar to what was done
@ -26,13 +26,13 @@ into three separate classes ``ThrOMP``, ``ThrData``, and ``FixOMP``.
available in the corresponding base class (e.g. ``Pair`` for
``PairLJCutOMP``) like multi-thread aware variants of the "tally"
functions. Those functions are made available through multiple
inheritance so those new functions have to have unique names to avoid
inheritance, so those new functions have to have unique names to avoid
ambiguities; typically ``_thr`` is appended to the name of the function.
``ThrData`` is a classes that manages per-thread data structures.
It is used instead of extending the corresponding storage to per-thread
arrays to avoid slowdowns due to "false sharing" when multiple threads
update adjacent elements in an array and thus force the CPU cache lines
to be reset and re-fetched. ``FixOMP`` finally manages the "multi-thread
``ThrData`` is a class that manages per-thread data structures. It is
used instead of extending the corresponding storage to per-thread arrays
to avoid slowdowns due to "false sharing" when multiple threads update
adjacent elements in an array and thus force the CPU cache lines to be
reset and re-fetched. ``FixOMP`` finally manages the "multi-thread
state" like settings and access to per-thread storage, it is activated
by the :doc:`package omp <package>` command.
@ -46,24 +46,24 @@ involve multiple atoms and thus there are race conditions when multiple
threads want to update per-atom data of the same atoms. Five possible
strategies have been considered to avoid this:
1) restructure the code so that there is no overlapping access possible
1. Restructure the code so that there is no overlapping access possible
when computing in parallel, e.g. by breaking lists into multiple
parts and synchronizing threads in between.
2) have each thread be "responsible" for a specific group of atoms and
2. Have each thread be "responsible" for a specific group of atoms and
compute these interactions multiple times, once on each thread that
is responsible for a given atom and then have each thread only update
is responsible for a given atom, and then have each thread only update
the properties of this atom.
3) use mutexes around functions and regions of code where the data race
could happen
4) use atomic operations when updating per-atom properties
5) use replicated per-thread data structures to accumulate data without
3. Use mutexes around functions and regions of code where the data race
could happen.
4. Use atomic operations when updating per-atom properties.
5. Use replicated per-thread data structures to accumulate data without
conflicts and then use a reduction to combine those results into the
data structures used by the regular style.
Option 5 was chosen for the OPENMP package because it would retain the
performance for the case of 1 thread and the code would be more
performance for the case of a single thread and the code would be more
maintainable. Option 1 would require extensive code changes,
particularly to the neighbor list code; options 2 would have incurred a
particularly to the neighbor list code; option 2 would have incurred a
2x or more performance penalty for the serial case; option 3 causes
significant overhead and would enforce serialization of operations in
inner loops and thus defeat the purpose of multi-threading; option 4
@ -80,7 +80,7 @@ equivalent to the number of CPU cores per CPU socket on high-end
supercomputers.
Thus arrays like the force array are dimensioned to the number of atoms
times the number of threads when enabling OpenMP support and inside the
times the number of threads when enabling OpenMP support, and inside the
compute functions a pointer to a different chunk is obtained by each thread.
Similarly, accumulators like potential energy or virial are kept in
per-thread instances of the ``ThrData`` class and then only reduced and
@ -91,7 +91,7 @@ Loop scheduling
"""""""""""""""
Multi-thread parallelization is applied by distributing (outer) loops
statically across threads. Typically this would be the loop over local
statically across threads. Typically, this would be the loop over local
atoms *i* when processing *i,j* pairs of atoms from a neighbor list.
The design of the neighbor list code results in atoms having a similar
number of neighbors for homogeneous systems and thus load imbalances

74
doc/src/Developer_par_part.rst
View File

@ -7,39 +7,39 @@ distributed-memory parallelism is set with the :doc:`comm_style command
.. _domain-decomposition:
.. figure:: img/domain-decomp.png
:align: center
domain decomposition
Domain decomposition schemes
This figure shows the different kinds of domain decomposition used
for MPI parallelization: "brick" on the left with an orthogonal
(left) and a triclinic (middle) simulation domain, and a "tiled"
decomposition (right). The black lines show the division into
sub-domains and the contained atoms are "owned" by the corresponding
MPI process. The green dashed lines indicate how sub-domains are
extended with "ghost" atoms up to the communication cutoff distance.
This figure shows the different kinds of domain decomposition used
for MPI parallelization: "brick" on the left with an orthogonal
(left) and a triclinic (middle) simulation domain, and a "tiled"
decomposition (right). The black lines show the division into
subdomains, and the contained atoms are "owned" by the
corresponding MPI process. The green dashed lines indicate how
subdomains are extended with "ghost" atoms up to the communication
cutoff distance.
The LAMMPS simulation box is a 3d or 2d volume, which can be orthogonal
or triclinic in shape, as illustrated in the :ref:`domain-decomposition`
figure for the 2d case. Orthogonal means the box edges are aligned with
the *x*, *y*, *z* Cartesian axes, and the box faces are thus all
rectangular. Triclinic allows for a more general parallelepiped shape
in which edges are aligned with three arbitrary vectors and the box
faces are parallelograms. In each dimension box faces can be periodic,
or non-periodic with fixed or shrink-wrapped boundaries. In the fixed
case, atoms which move outside the face are deleted; shrink-wrapped
means the position of the box face adjusts continuously to enclose all
the atoms.
The LAMMPS simulation box is a 3d or 2d volume, which can be of
orthogonal or triclinic shape, as illustrated in the
:ref:`domain-decomposition` figure for the 2d case. Orthogonal means
the box edges are aligned with the *x*, *y*, *z* Cartesian axes, and the
box faces are thus all rectangular. Triclinic allows for a more general
parallelepiped shape in which edges are aligned with three arbitrary
vectors and the box faces are parallelograms. In each dimension, box
faces can be periodic, or non-periodic with fixed or shrink-wrapped
boundaries. In the fixed case, atoms which move outside the face are
deleted; shrink-wrapped means the position of the box face adjusts
continuously to enclose all the atoms.
For distributed-memory MPI parallelism, the simulation box is spatially
decomposed (partitioned) into non-overlapping sub-domains which fill the
decomposed (partitioned) into non-overlapping subdomains which fill the
box. The default partitioning, "brick", is most suitable when atom
density is roughly uniform, as shown in the left-side images of the
:ref:`domain-decomposition` figure. The sub-domains comprise a regular
grid and all sub-domains are identical in size and shape. Both the
:ref:`domain-decomposition` figure. The subdomains comprise a regular
grid, and all subdomains are identical in size and shape. Both the
orthogonal and triclinic boxes can deform continuously during a
simulation, e.g. to compress a solid or shear a liquid, in which case
the processor sub-domains likewise deform.
the processor subdomains likewise deform.
For models with non-uniform density, the number of particles per
@ -50,14 +50,14 @@ load. For such models, LAMMPS supports multiple strategies to reduce
the load imbalance:
- The processor grid decomposition is by default based on the simulation
cell volume and tries to optimize the volume to surface ratio for the sub-domains.
cell volume and tries to optimize the volume to surface ratio for the subdomains.
This can be changed with the :doc:`processors command <processors>`.
- The parallel planes defining the size of the sub-domains can be shifted
- The parallel planes defining the size of the subdomains can be shifted
with the :doc:`balance command <balance>`. Which can be done in addition
to choosing a more optimal processor grid.
- The recursive bisectioning algorithm in combination with the "tiled"
communication style can produce a partitioning with equal numbers of
particles in each sub-domain.
particles in each subdomain.
.. |decomp1| image:: img/decomp-regular.png
@ -76,14 +76,14 @@ the load imbalance:
The pictures above demonstrate different decompositions for a 2d system
with 12 MPI ranks. The atom colors indicate the load imbalance of each
sub-domain with green being optimal and red the least optimal.
subdomain, with green being optimal and red the least optimal.
Due to the vacuum in the system, the default decomposition is unbalanced
with several MPI ranks without atoms (left). By forcing a 1x12x1
processor grid, every MPI rank does computations now, but number of
atoms per sub-domain is still uneven and the thin slice shape increases
the amount of communication between sub-domains (center left). With a
2x6x1 processor grid and shifting the sub-domain divisions, the load
imbalance is further reduced and the amount of communication required
between sub-domains is less (center right). And using the recursive
bisectioning leads to further improved decomposition (right).
Due to the vacuum in the system, the default decomposition is
unbalanced, with several MPI ranks without atoms (left). By forcing a
1x12x1 processor grid, every MPI rank does computations now, but the
number of atoms per subdomain is still uneven, and the thin slice shape
increases the amount of communication between subdomains (center
left). With a 2x6x1 processor grid and shifting the subdomain divisions,
the load imbalance is further reduced and the amount of communication
required between subdomains is less (center right). And using the
recursive bisectioning leads to further improved decomposition (right).

8
doc/src/Developer_parallel.rst
View File

@ -3,11 +3,11 @@ Parallel algorithms
LAMMPS is designed to enable running simulations in parallel using the
MPI parallel communication standard with distributed data via domain
decomposition. The parallelization aims to be efficient result in good
strong scaling (= good speedup for the same system) and good weak
scaling (= the computational cost of enlarging the system is
decomposition. The parallelization aims to be efficient, and resulting
in good strong scaling (= good speedup for the same system) and good
weak scaling (= the computational cost of enlarging the system is
proportional to the system size). Additional parallelization using GPUs
or OpenMP can also be applied within the sub-domain assigned to an MPI
or OpenMP can also be applied within the subdomain assigned to an MPI
process. For clarity, most of the following illustrations show the 2d
simulation case. The underlying algorithms in those cases, however,
apply to both 2d and 3d cases equally well.

6
doc/src/Developer_plugins.rst
View File

@ -95,7 +95,7 @@ a class ``PairMorse2`` in the files ``pair_morse2.h`` and
``pair_morse2.cpp`` with the factory function and initialization
function would look like this:
.. code-block:: C++
.. code-block:: c++
#include "lammpsplugin.h"
#include "version.h"
@ -141,7 +141,7 @@ list of argument strings), then the pointer type is ``lammpsplugin_factory2``
and it must be assigned to the *creator.v2* member of the plugin struct.
Below is an example for that:
.. code-block:: C++
.. code-block:: c++
#include "lammpsplugin.h"
#include "version.h"
@ -176,7 +176,7 @@ demonstrated in the following example, which also shows that the
implementation of the plugin class may be within the same source
file as the plugin interface code:
.. code-block:: C++
.. code-block:: c++
#include "lammpsplugin.h"

70
doc/src/Developer_unittest.rst
View File

@ -180,21 +180,13 @@ discarded but by setting the verbose flag (via setting the ``TEST_ARGS``
environment variable, ``TEST_ARGS=-v``) it can be printed and used to
understand why tests fail unexpectedly.
Another complexity of these tests stems from the need to capture
situations where LAMMPS will stop with an error, i.e. handle so-called
"death tests". Here the LAMMPS code will operate differently depending
on whether it was configured to throw C++ exceptions on errors or call
either ``exit()`` or ``MPI_Abort()``. In the latter case, the test code
also needs to detect whether LAMMPS was compiled with the OpenMPI
library, as OpenMPI is **only** compatible the death test options of the
GoogleTest library when C++ exceptions are enabled; otherwise those
"death tests" must be skipped to avoid reporting bogus failures. The
specifics of this step are implemented in the ``TEST_FAILURE()``
macro. These tests operate by capturing the screen output when executing
the failing command and then comparing that with a provided regular
expression string pattern. Example:
The specifics of so-called "death tests", i.e. conditions where LAMMPS
should fail and throw an exception, are implemented in the
``TEST_FAILURE()`` macro. These tests operate by capturing the screen
output when executing the failing command and then comparing that with a
provided regular expression string pattern. Example:
.. code-block:: C++
.. code-block:: c++
TEST_F(SimpleCommandsTest, UnknownCommand)
{
@ -226,9 +218,9 @@ The following test programs are currently available:
* - ``test_kim_commands.cpp``
- KimCommands
- Tests for several commands from the :ref:`KIM package <PKG-KIM>`
* - ``test_reset_ids.cpp``
- ResetIDs
- Tests to validate the :doc:`reset_atom_ids <reset_atom_ids>` and :doc:`reset_mol_ids <reset_mol_ids>` commands
* - ``test_reset_atoms.cpp``
- ResetAtoms
- Tests to validate the :doc:`reset_atoms <reset_atoms>` sub-commands
Tests for the C-style library interface
@ -249,7 +241,7 @@ MPI support. These include tests where LAMMPS is run in multi-partition
mode or only on a subset of the MPI world communicator. The CMake
script code for adding this kind of test looks like this:
.. code-block:: CMake
.. code-block:: cmake
if (BUILD_MPI)
add_executable(test_library_mpi test_library_mpi.cpp)
@ -282,9 +274,7 @@ Tests for using the Fortran module are in the ``unittest/fortran``
folder. Since they are also using the GoogleTest library, they require
to also implement test wrappers in C++ that will call fortran functions
which provide a C function interface through ISO_C_BINDINGS that will in
turn call the functions in the LAMMPS Fortran module. This part of the
unit tests is incomplete since the Fortran module it is based on is
incomplete as well.
turn call the functions in the LAMMPS Fortran module.
Tests for the C++-style library interface
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -405,10 +395,10 @@ compare with the reference and also start from the data file. A final
check will use multi-cutoff r-RESPA (if supported by the pair style) at
a 1:1 split and compare to the Verlet results. These sets of tests are
run with multiple test fixtures for accelerated styles (OPT, OPENMP,
INTEL) and for the latter two with 4 OpenMP threads enabled. For
these tests the relative error (epsilon) is lowered by a common factor
due to the additional numerical noise, but the tests are still comparing
to the same reference data.
INTEL, KOKKOS (OpenMP only)) and for the latter three with 4 OpenMP
threads enabled. For these tests the relative error (epsilon) is lowered
by a common factor due to the additional numerical noise, but the tests
are still comparing to the same reference data.
Additional tests will check whether all listed extract keywords are
supported and have the correct dimensionality and the final set of tests
@ -442,17 +432,19 @@ The ``test_pair_style`` tester is used with 4 categories of test inputs:
pair style is defined, but the computation of the pair style contributions
is disabled.
The ``test_bond_style`` and ``test_angle_style`` are set up in a similar
fashion and share support functions with the pair style tester. The final
group of tests in this section is for fix styles that add/manipulate forces
and velocities, e.g. for time integration, thermostats and more.
The ``test_bond_style``, ``test_angle_style``, ``test_dihedral_style``, and
``test_improper_style`` tester programs are set up in a similar fashion and
share support functions with the pair style tester. The final group of
tests in this section is for fix styles that add/manipulate forces and
velocities, e.g. for time integration, thermostats and more.
Adding a new test is easiest done by copying and modifying an existing test
for a style that is similar to one to be tested. The file name should follow
the naming conventions described above and after copying the file, the first
step is to replace the style names where needed. The coefficient values
do not have to be meaningful, just in a reasonable range for the given system.
It does not matter if some forces are large, for as long as they do not diverge.
Adding a new test is easiest done by copying and modifying an existing YAML
file for a style that is similar to one to be tested. The file name should
follow the naming conventions described above and after copying the file,
the first step is to replace the style names where needed. The coefficient
values do not have to be meaningful, just in a reasonable range for the
given system. It does not matter if some forces are large, for as long as
they do not diverge.
The template input files define a large number of index variables at the top
that can be modified inside the YAML file to control the behavior. For example,
@ -480,7 +472,7 @@ Note that this disables computing the kspace contribution, but still will run
the setup. The "gewald" parameter should be set explicitly to speed up the run.
For styles with long-range electrostatics, typically two tests are added one using
the (slower) analytic approximation of the erfc() function and the other using
the tabulated coulomb, to test both code paths. The reference results in the YAML
the tabulated coulomb, to test both code paths. The reference results in the YAML
files then should be compared manually, if they agree well enough within the limits
of those two approximations.
@ -489,7 +481,7 @@ to update the YAML files. Running a command like
.. code-block:: bash
$ test_pair_style mol-pair-lennard_mdf.yaml -g new.yaml
test_pair_style mol-pair-lennard_mdf.yaml -g new.yaml
will read the settings from the ``mol-pair-lennard_mdf.yaml`` file and then compute
the reference data and write a new file with to ``new.yaml``. If this step fails,
@ -500,13 +492,13 @@ It is also possible to do an update in place with:
.. code-block:: bash
$ test_pair_style mol-pair-lennard_mdf.yaml -u
test_pair_style mol-pair-lennard_mdf.yaml -u
And one can finally run the full set of tests with:
.. code-block:: bash
$ test_pair_style mol-pair-lennard_mdf.yaml
test_pair_style mol-pair-lennard_mdf.yaml
This will just print a summary of the groups of tests. When using the "-v" flag
the test will also keep any LAMMPS output and when using the "-s" flag, there

129
doc/src/Developer_updating.rst
View File

@ -7,7 +7,7 @@ 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
contact developers@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
@ -24,7 +24,9 @@ Available topics in mostly chronological order are:
- `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`_
- `Rename of fix STORE/PERATOM to fix STORE/ATOM and change of arguments`_
- `Use Output::get_dump_by_id() instead of Output::find_dump()`_
- `Refactored grid communication using Grid3d/Grid2d classes instead of GridComm`_
----
@ -61,7 +63,7 @@ header file needs to be updated accordingly.
Old:
.. code-block:: C++
.. code-block:: c++
int PairEAM::pack_comm(int n, int *list, double *buf, int pbc_flag, int *pbc)
{
@ -75,7 +77,7 @@ Old:
New:
.. code-block:: C++
.. code-block:: c++
int PairEAM::pack_forward_comm(int n, int *list, double *buf, int pbc_flag, int *pbc)
{
@ -112,14 +114,14 @@ Example from a pair style:
Old:
.. code-block:: C++
.. code-block:: c++
if (eflag || vflag) ev_setup(eflag, vflag);
else evflag = vflag_fdotr = eflag_global = eflag_atom = 0;
New:
.. code-block:: C++
.. code-block:: c++
ev_init(eflag, vflag);
@ -142,14 +144,14 @@ when they are called from only one or a subset of the MPI processes.
Old:
.. code-block:: C++
.. code-block:: c++
val = force->numeric(FLERR, arg[1]);
num = force->inumeric(FLERR, arg[2]);
New:
.. code-block:: C++
.. code-block:: c++
val = utils::numeric(FLERR, true, arg[1], lmp);
num = utils::inumeric(FLERR, false, arg[2], lmp);
@ -183,14 +185,14 @@ copy them around for simulations.
Old:
.. code-block:: C++
.. code-block:: c++
fp = force->open_potential(filename);
fp = fopen(filename, "r");
New:
.. code-block:: C++
.. code-block:: c++
fp = utils::open_potential(filename, lmp);
@ -207,7 +209,7 @@ Example:
Old:
.. code-block:: C++
.. code-block:: c++
if (fptr == NULL) {
char str[128];
@ -217,7 +219,7 @@ Old:
New:
.. code-block:: C++
.. code-block:: c++
if (fptr == nullptr)
error->one(FLERR, "Cannot open AEAM potential file {}: {}", filename, utils::getsyserror());
@ -237,7 +239,7 @@ an example from the ``FixWallReflect`` class:
Old:
.. code-block:: C++
.. code-block:: c++
FixWallReflect(class LAMMPS *, int, char **);
virtual ~FixWallReflect();
@ -247,7 +249,7 @@ Old:
New:
.. code-block:: C++
.. code-block:: c++
FixWallReflect(class LAMMPS *, int, char **);
~FixWallReflect() override;
@ -271,7 +273,7 @@ the type of the "this" pointer argument.
Old:
.. code-block:: C++
.. code-block:: c++
comm->forward_comm_pair(this);
comm->forward_comm_fix(this);
@ -284,7 +286,7 @@ Old:
New:
.. code-block:: C++
.. code-block:: c++
comm->forward_comm(this);
comm->reverse_comm(this);
@ -304,7 +306,7 @@ requests can be :doc:`found here <Developer_notes>`. Example from the
Old:
.. code-block:: C++
.. code-block:: c++
int irequest = neighbor->request(this,instance_me);
neighbor->requests[irequest]->pair = 0;
@ -317,7 +319,7 @@ Old:
New:
.. code-block:: C++
.. code-block:: c++
auto req = neighbor->add_request(this, NeighConst::REQ_OCCASIONAL);
if (cutflag) req->set_cutoff(mycutneigh);
@ -340,7 +342,7 @@ these are internal fixes, there is no user visible change.
Old:
.. code-block:: C++
.. code-block:: c++
#include "fix_store.h"
@ -351,7 +353,7 @@ Old:
New:
.. code-block:: C++
.. code-block:: c++
#include "fix_store_peratom.h"
@ -362,7 +364,7 @@ New:
Old:
.. code-block:: C++
.. code-block:: c++
#include "fix_store.h"
@ -373,7 +375,7 @@ Old:
New:
.. code-block:: C++
.. code-block:: c++
#include "fix_store_global.h"
@ -384,6 +386,34 @@ New:
This change is **required** or else the code will not compile.
Rename of fix STORE/PERATOM to fix STORE/ATOM and change of arguments
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: 28Mar2023
The available functionality of the internal fix to store per-atom
properties was expanded to enable storing data with ghost atoms and to
support binary restart files. With those changes, the fix was renamed
to fix STORE/ATOM and the number and order of (required) arguments has
changed.
Old syntax: ``ID group-ID STORE/PERATOM rflag n1 n2 [n3]``
- *rflag* = 0/1, *no*/*yes* store per-atom values in restart file
- :math:`n1 = 1, n2 = 1, \mathrm{no}\;n3 \to` per-atom vector, single value per atom
- :math:`n1 = 1, n2 > 1, \mathrm{no}\;n3 \to` per-atom array, *n2* values per atom
- :math:`n1 = 1, n2 > 0, n3 > 0 \to` per-atom tensor, *n2* x *n3* values per atom
New syntax: ``ID group-ID STORE/ATOM n1 n2 gflag rflag``
- :math:`n1 = 1, n2 = 0 \to` per-atom vector, single value per atom
- :math:`n1 > 1, n2 = 0 \to` per-atom array, *n1* values per atom
- :math:`n1 > 0, n2 > 0 \to` per-atom tensor, *n1* x *n2* values per atom
- *gflag* = 0/1, *no*/*yes* communicate per-atom values with ghost atoms
- *rflag* = 0/1, *no*/*yes* store per-atom values in restart file
Since this is an internal fix, there is no user visible change.
Use Output::get_dump_by_id() instead of Output::find_dump()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -396,7 +426,7 @@ the dump directly. Example:
Old:
.. code-block:: C++
.. code-block:: c++
int idump = output->find_dump(arg[iarg+1]);
if (idump < 0)
@ -412,7 +442,7 @@ Old:
New:
.. code-block:: C++
.. code-block:: c++
auto idump = output->get_dump_by_id(arg[iarg+1]);
if (!idump) error->all(FLERR,"Dump ID {} in hyper command does not exist", arg[iarg+1]);
@ -423,3 +453,56 @@ New:
if (dumpflag) for (auto idump : dumplist) idump->write();
This change is **required** or else the code will not compile.
Refactored grid communication using Grid3d/Grid2d classes instead of GridComm
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: 22Dec2022
The ``GridComm`` class was for creating and communicating distributed
grids was replaced by the ``Grid3d`` class with added functionality.
A ``Grid2d`` class was also added for additional flexibility.
The new functionality and commands using the two grid classes are
discussed on the following documentation pages:
- :doc:`Howto_grid`
- :doc:`Developer_grid`
If you have custom LAMMPS code, which uses the GridComm class, here are some notes
on how to adapt it for using the Grid3d class.
(1) The constructor has changed to allow the ``Grid3d`` / ``Grid2d``
classes to partition the global grid across processors, both for
owned and ghost grid cells. Previously any class which called
``GridComm`` performed the partitioning itself and that information
was passed in the ``GridComm::GridComm()`` constructor. There are
several "set" functions which can be called to alter how ``Grid3d``
/ ``Grid2d`` perform the partitioning. They should be sufficient
for most use cases of the grid classes.
(2) The partitioning is triggered by the ``setup_grid()`` method.
(3) The ``setup()`` method of the ``GridComm`` class has been replaced
by the ``setup_comm()`` method in the new grid classes. The syntax
for the ``forward_comm()`` and ``reverse_comm()`` methods is
slightly altered as is the syntax of the associated pack/unpack
callback methods. But the functionality of these operations is the
same as before.
(4) The new ``Grid3d`` / ``Grid2d`` classes have additional
functionality for dynamic load-balancing of grids and their
associated data across processors. This did not exist in the
``GridComm`` class.
This and more is explained in detail on the :doc:`Developer_grid` page.
The following LAMMPS source files can be used as illustrative examples
for how the new grid classes are used by computes, fixes, and various
KSpace solvers which use distributed FFT grids:
- ``src/fix_ave_grid.cpp``
- ``src/compute_property_grid.cpp``
- ``src/EXTRA-FIX/fix_ttm_grid.cpp``
- ``src/KSPACE/pppm.cpp``
This change is **required** or else the code will not compile.

20
doc/src/Developer_utils.rst
View File

@ -133,6 +133,9 @@ and parsing files or arguments.
.. doxygenfunction:: trim_comment
:project: progguide
.. doxygenfunction:: strip_style_suffix
:project: progguide
.. doxygenfunction:: star_subst
:project: progguide
@ -211,6 +214,9 @@ Argument processing
.. doxygenfunction:: expand_args
:project: progguide
.. doxygenfunction:: parse_grid_id
:project: progguide
.. doxygenfunction:: expand_type
:project: progguide
@ -317,7 +323,7 @@ are all "whitespace" characters, i.e. the space character, the tabulator
character, the carriage return character, the linefeed character, and
the form feed character.
.. code-block:: C++
.. code-block:: c++
:caption: Tokenizer class example listing entries of the PATH environment variable
#include "tokenizer.h"
@ -349,7 +355,7 @@ tokenizer into a ``try`` / ``catch`` block to handle errors. The
when a (type of) number is requested as next token that is not
compatible with the string representing the next word.
.. code-block:: C++
.. code-block:: c++
:caption: ValueTokenizer class example with exception handling
#include "tokenizer.h"
@ -427,7 +433,7 @@ one or two array indices "[<number>]" with numbers > 0.
A typical code segment would look like this:
.. code-block:: C++
.. code-block:: c++
:caption: Usage example for ArgInfo class
int nvalues = 0;
@ -476,7 +482,7 @@ open the file, and will call the :cpp:class:`LAMMPS_NS::Error` class in
case of failures to read or to convert numbers, so that LAMMPS will be
aborted.
.. code-block:: C++
.. code-block:: c++
:caption: Use of PotentialFileReader class in pair style coul/streitz
PotentialFileReader reader(lmp, file, "coul/streitz");
@ -555,7 +561,7 @@ chunk size needs to be known in advance, 2) with :cpp:func:`MyPage::vget()
its size is registered later with :cpp:func:`MyPage::vgot()
<LAMMPS_NS::MyPage::vgot>`.
.. code-block:: C++
.. code-block:: c++
:caption: Example of using :cpp:class:`MyPage <LAMMPS_NS::MyPage>`
#include "my_page.h"
@ -637,11 +643,13 @@ Tohoku University (under MIT license)
---------------------------
.. _communication_buffer_coding_with_ubuf:
Communication buffer coding with *ubuf*
---------------------------------------
LAMMPS uses communication buffers where it collects data from various
class instances and then exchanges the data with neighboring sub-domains.
class instances and then exchanges the data with neighboring subdomains.
For simplicity those buffers are defined as ``double`` buffers and
used for doubles and integer numbers. This presents a unique problem
when 64-bit integers are used. While the storage needed for a ``double``

249
doc/src/Developer_write.rst
View File

@ -6,250 +6,9 @@ be extended by writing new classes that derive from existing
parent classes in LAMMPS. Here, some specific coding
details are provided for writing code for LAMMPS.
Writing a new fix style
^^^^^^^^^^^^^^^^^^^^^^^
Writing fixes is a flexible way of extending LAMMPS. Users can
implement many things using fixes:
- changing particles attributes (positions, velocities, forces, etc.). Examples: FixNVE, FixFreeze.
- reading/writing data. Example: FixRestart.
- adding or modifying properties due to geometry. Example: FixWall.
- interacting with other subsystems or external code: Examples: FixTTM, FixExternal, FixLATTE
- saving information for analysis or future use (previous positions,
for instance). Examples: Fix AveTime, FixStoreState.
All fixes are derived from the Fix base class and must have a
constructor with the signature: ``FixPrintVel(class LAMMPS *, int, char **)``.
Every fix must be registered in LAMMPS by writing the following lines
of code in the header before include guards:
.. code-block:: c
#ifdef FIX_CLASS
// clang-format off
FixStyle(print/vel,FixPrintVel);
// clang-format on
#else
/* the definition of the FixPrintVel class comes here */
...
#endif
Where ``print/vel`` is the style name of your fix in the input script and
``FixPrintVel`` is the name of the class. The header file would be called
``fix_print_vel.h`` and the implementation file ``fix_print_vel.cpp``.
These conventions allow LAMMPS to automatically integrate it into the
executable when compiling and associate your new fix class with the designated
keyword when it parses the input script.
Let's write a simple fix which will print the average velocity at the end
of each timestep. First of all, implement a constructor:
.. code-block:: C++
FixPrintVel::FixPrintVel(LAMMPS *lmp, int narg, char **arg)
: Fix(lmp, narg, arg)
{
if (narg < 4)
error->all(FLERR,"Illegal fix print/vel command");
nevery = utils::inumeric(FLERR,arg[3],false,lmp);
if (nevery <= 0)
error->all(FLERR,"Illegal fix print/vel command");
}
In the constructor you should parse your fix arguments which are
specified in the script. All fixes have pretty much the same syntax:
``fix <fix-ID> <fix group> <fix name> <fix arguments ...>``. The
first 3 parameters are parsed by Fix base class constructor, while
``<fix arguments>`` should be parsed by you. In our case, we need to
specify how often we want to print an average velocity. For instance,
once in 50 timesteps: ``fix 1 print/vel 50``. There is a special variable
in the Fix class called ``nevery`` which specifies how often the method
``end_of_step()`` is called. Thus all we need to do is just set it up.
The next method we need to implement is ``setmask()``:
.. code-block:: C++
int FixPrintVel::setmask()
{
int mask = 0;
mask |= FixConst::END_OF_STEP;
return mask;
}
Here the user specifies which methods of your fix should be called
during execution. The constant ``END_OF_STEP`` corresponds to the
``end_of_step()`` method. The most important available methods that
are called during a timestep and the order in which they are called
are shown in the previous section.
.. code-block:: C++
void FixPrintVel::end_of_step()
{
// for add3, scale3
using namespace MathExtra;
double** v = atom->v;
int nlocal = atom->nlocal;
double localAvgVel[4]; // 4th element for particles count
memset(localAvgVel, 0, 4 * sizeof(double));
for (int particleInd = 0; particleInd < nlocal; ++particleInd) {
add3(localAvgVel, v[particleInd], localAvgVel);
}
localAvgVel[3] = nlocal;
double globalAvgVel[4];
memset(globalAvgVel, 0, 4 * sizeof(double));
MPI_Allreduce(localAvgVel, globalAvgVel, 4, MPI_DOUBLE, MPI_SUM, world);
scale3(1.0 / globalAvgVel[3], globalAvgVel);
if ((comm->me == 0) && screen) {
fmt::print(screen,"{}, {}, {}\n",
globalAvgVel[0], globalAvgVel[1], globalAvgVel[2]);
}
}
In the code above, we use MathExtra routines defined in
``math_extra.h``. There are bunch of math functions to work with
arrays of doubles as with math vectors. It is also important to note
that LAMMPS code should always assume to be run in parallel and that
atom data is thus distributed across the MPI ranks. Thus you can
only process data from local atoms directly and need to use MPI library
calls to combine or exchange data. For serial execution, LAMMPS
comes bundled with the MPI STUBS library that contains the MPI library
function calls in dummy versions that only work for a single MPI rank.
In this code we use an instance of Atom class. This object is stored
in the Pointers class (see ``pointers.h``) which is the base class of
the Fix base class. This object contains references to various class
instances (the original instances are created and held by the LAMMPS
class) with all global information about the simulation system.
Data from the Pointers class is available to all classes inherited from
it using protected inheritance. Hence when you write you own class,
which is going to use LAMMPS data, don't forget to inherit from Pointers
or pass an Pointer to it to all functions that need access. When writing
fixes we inherit from class Fix which is inherited from Pointers so
there is no need to inherit from it directly.
The code above computes average velocity for all particles in the
simulation. Yet you have one unused parameter in fix call from the
script: ``group_name``. This parameter specifies the group of atoms
used in the fix. So we should compute average for all particles in the
simulation only if ``group_name == "all"``, but it can be any group.
The group membership information of an atom is contained in the *mask*
property of and atom and the bit corresponding to a given group is
stored in the groupbit variable which is defined in Fix base class:
.. code-block:: C++
for (int i = 0; i < nlocal; ++i) {
if (atom->mask[i] & groupbit) {
// Do all job here
}
}
Class Atom encapsulates atoms positions, velocities, forces, etc. User
can access them using particle index. Note, that particle indexes are
usually changed every few timesteps because of neighbor list rebuilds
and spatial sorting (to improve cache efficiency).
Let us consider another Fix example: We want to have a fix which stores
atoms position from previous time step in your fix. The local atoms
indexes may not be valid on the next iteration. In order to handle
this situation there are several methods which should be implemented:
- ``double memory_usage()``: return how much memory the fix uses (optional)
- ``void grow_arrays(int)``: do reallocation of the per particle arrays in your fix
- ``void copy_arrays(int i, int j, int delflag)``: copy i-th per-particle
information to j-th. Used when atom sorting is performed. if delflag is set
and atom j owns a body, move the body information to atom i.
- ``void set_arrays(int i)``: sets i-th particle related information to zero
Note, that if your class implements these methods, it must call add calls of
add_callback and delete_callback to constructor and destructor. Since we want
to store positions of atoms from previous timestep, we need to add
``double** xold`` to the header file. Than add allocation code
to the constructor:
.. code-block:: C++
FixSavePos::FixSavePos(LAMMPS *lmp, int narg, char **arg), xold(nullptr)
{
//...
memory->create(xold, atom->nmax, 3, "FixSavePos:x");
atom->add_callback(0);
}
FixSavePos::~FixSavePos() {
atom->delete_callback(id, 0);
memory->destroy(xold);
}
Implement the aforementioned methods:
.. code-block:: C++
double FixSavePos::memory_usage()
{
int nmax = atom->nmax;
double bytes = 0.0;
bytes += nmax * 3 * sizeof(double);
return bytes;
}
void FixSavePos::grow_arrays(int nmax)
{
memory->grow(xold, nmax, 3, "FixSavePos:xold");
}
void FixSavePos::copy_arrays(int i, int j, int delflag)
{
memcpy(xold[j], xold[i], sizeof(double) * 3);
}
void FixSavePos::set_arrays(int i)
{
memset(xold[i], 0, sizeof(double) * 3);
}
int FixSavePos::pack_exchange(int i, double *buf)
{
int m = 0;
buf[m++] = xold[i][0];
buf[m++] = xold[i][1];
buf[m++] = xold[i][2];
return m;
}
int FixSavePos::unpack_exchange(int nlocal, double *buf)
{
int m = 0;
xold[nlocal][0] = buf[m++];
xold[nlocal][1] = buf[m++];
xold[nlocal][2] = buf[m++];
return m;
}
Now, a little bit about memory allocation. We use the Memory class which
is just a bunch of template functions for allocating 1D and 2D
arrays. So you need to add include ``memory.h`` to have access to them.
Finally, if you need to write/read some global information used in
your fix to the restart file, you might do it by setting flag
``restart_global = 1`` in the constructor and implementing methods void
``write_restart(FILE *fp)`` and ``void restart(char *buf)``.
If, in addition, you want to write the per-atom property to restart
files additional settings and functions are needed:
- a fix flag indicating this needs to be set ``restart_peratom = 1;``
- ``atom->add_callback()`` and ``atom->delete_callback()`` must be called
a second time with the final argument set to 1 instead of 0 (indicating
restart processing instead of per-atom data memory management).
- the functions ``void pack_restart(int i, double *buf)`` and
``void unpack_restart(int nlocal, int nth)`` need to be implemented
.. toctree::
:maxdepth: 1
Developer_write_pair
Developer_write_fix

245
doc/src/Developer_write_fix.rst Normal file
View File

@ -0,0 +1,245 @@
Writing a new fix style
^^^^^^^^^^^^^^^^^^^^^^^
Writing fix styles is a flexible way of extending LAMMPS. Users can
implement many things using fixes. Some fix styles are only used
internally to support compute styles or pair styles:
- change particles attributes (positions, velocities, forces, etc.). Examples: ``FixNVE``, ``FixFreeze``.
- read or write data. Example: ``FixRestart``.
- adding or modifying properties due to geometry. Example: ``FixWall``.
- interacting with other subsystems or external code: Examples: ``FixTTM``, ``FixExternal``, ``FixMDI``
- saving information for analysis or future use (previous positions,
for instance). Examples: ``FixAveTime``, ``FixStoreState``.
All fixes are derived from the ``Fix`` base class and must have a
constructor with the signature: ``FixPrintVel(class LAMMPS *, int, char **)``.
Every fix must be registered in LAMMPS by writing the following lines
of code in the header before include guards:
.. code-block:: c++
#ifdef FIX_CLASS
// clang-format off
FixStyle(print/vel,FixPrintVel);
// clang-format on
#else
/* the definition of the FixPrintVel class comes here */
...
#endif
Where ``print/vel`` is the style name of your fix in the input script and
``FixPrintVel`` is the name of the class. The header file would be called
``fix_print_vel.h`` and the implementation file ``fix_print_vel.cpp``.
These conventions allow LAMMPS to automatically integrate it into the
executable when compiling and associate your new fix class with the designated
keyword when it parses the input script.
Let's write a simple fix which will print the average velocity at the end
of each timestep. First of all, implement a constructor:
.. code-block:: c++
FixPrintVel::FixPrintVel(LAMMPS *lmp, int narg, char **arg)
: Fix(lmp, narg, arg)
{
if (narg < 4) utils::missing_cmd_args(FLERR, "fix print/vel", error);
nevery = utils::inumeric(FLERR,arg[3],false,lmp);
if (nevery <= 0)
error->all(FLERR,"Illegal fix print/vel nevery value: {}", nevery);
}
In the constructor you should parse the fix arguments which are
specified in the script. All fixes have pretty much the same syntax:
``fix <fix-ID> <fix group> <fix name> <fix arguments ...>``. The first 3
parameters are parsed by Fix base class constructor, while ``<fix
arguments>`` should be parsed by you. In our case, we need to specify
how often we want to print an average velocity. For instance, once in 50
timesteps: ``fix 1 print/vel 50``. There is a special variable in the
Fix class called ``nevery`` which specifies how often the method
``end_of_step()`` is called. Thus all we need to do is just set it up.
The next method we need to implement is ``setmask()``:
.. code-block:: c++
int FixPrintVel::setmask()
{
int mask = 0;
mask |= FixConst::END_OF_STEP;
return mask;
}
Here the we specify which methods of the fix should be called during
:doc:`execution of a timestep <Developer_flow>`. The constant
``END_OF_STEP`` corresponds to the ``end_of_step()`` method. The most
important available methods that are called during a timestep.
.. code-block:: c++
void FixPrintVel::end_of_step()
{
// for add3, scale3
using namespace MathExtra;
double** v = atom->v;
int nlocal = atom->nlocal;
double localAvgVel[4]; // 4th element for particles count
memset(localAvgVel, 0, 4 * sizeof(double));
for (int particleInd = 0; particleInd < nlocal; ++particleInd) {
add3(localAvgVel, v[particleInd], localAvgVel);
}
localAvgVel[3] = nlocal;
double globalAvgVel[4];
memset(globalAvgVel, 0, 4 * sizeof(double));
MPI_Allreduce(localAvgVel, globalAvgVel, 4, MPI_DOUBLE, MPI_SUM, world);
scale3(1.0 / globalAvgVel[3], globalAvgVel);
if ((comm->me == 0) && screen) {
fmt::print(screen,"{}, {}, {}\n",
globalAvgVel[0], globalAvgVel[1], globalAvgVel[2]);
}
}
In the code above, we use MathExtra routines defined in
``math_extra.h``. There are bunch of math functions to work with
arrays of doubles as with math vectors. It is also important to note
that LAMMPS code should always assume to be run in parallel and that
atom data is thus distributed across the MPI ranks. Thus you can
only process data from local atoms directly and need to use MPI library
calls to combine or exchange data. For serial execution, LAMMPS
comes bundled with the MPI STUBS library that contains the MPI library
function calls in dummy versions that only work for a single MPI rank.
In this code we use an instance of Atom class. This object is stored
in the Pointers class (see ``pointers.h``) which is the base class of
the Fix base class. This object contains references to various class
instances (the original instances are created and held by the LAMMPS
class) with all global information about the simulation system.
Data from the Pointers class is available to all classes inherited from
it using protected inheritance. Hence when you write you own class,
which is going to use LAMMPS data, don't forget to inherit from Pointers
or pass a Pointer to it to all functions that need access. When writing
fixes we inherit from class Fix which is inherited from Pointers so
there is no need to inherit from it directly.
The code above computes average velocity for all particles in the
simulation. Yet you have one unused parameter in fix call from the
script: ``group_name``. This parameter specifies the group of atoms
used in the fix. So we should compute average for all particles in the
simulation only if ``group_name == "all"``, but it can be any group.
The group membership information of an atom is contained in the *mask*
property of an atom and the bit corresponding to a given group is
stored in the groupbit variable which is defined in Fix base class:
.. code-block:: c++
for (int i = 0; i < nlocal; ++i) {
if (atom->mask[i] & groupbit) {
// Do all job here
}
}
Class Atom encapsulates atoms positions, velocities, forces, etc. Users
can access them using particle index. Note, that particle indexes are
usually changed every few timesteps because of neighbor list rebuilds
and spatial sorting (to improve cache efficiency).
Let us consider another Fix example: We want to have a fix which stores
atoms position from the previous time step in your fix. The local atoms
indexes may not be valid on the next iteration. In order to handle
this situation there are several methods which should be implemented:
- ``double memory_usage()``: return how much memory the fix uses (optional)
- ``void grow_arrays(int)``: do reallocation of the per-particle arrays in your fix
- ``void copy_arrays(int i, int j, int delflag)``: copy i-th per-particle
information to j-th. Used when atom sorting is performed. if delflag is set
and atom j owns a body, move the body information to atom i.
- ``void set_arrays(int i)``: sets i-th particle related information to zero
Note, that if your class implements these methods, it must add calls of
add_callback and delete_callback to the constructor and destructor. Since we want
to store positions of atoms from the previous timestep, we need to add
``double** xold`` to the header file. Than add allocation code
to the constructor:
.. code-block:: c++
FixSavePos::FixSavePos(LAMMPS *lmp, int narg, char **arg), xold(nullptr)
{
//...
memory->create(xold, atom->nmax, 3, "FixSavePos:x");
atom->add_callback(0);
}
FixSavePos::~FixSavePos() {
atom->delete_callback(id, 0);
memory->destroy(xold);
}
Implement the aforementioned methods:
.. code-block:: c++
double FixSavePos::memory_usage()
{
int nmax = atom->nmax;
double bytes = 0.0;
bytes += nmax * 3 * sizeof(double);
return bytes;
}
void FixSavePos::grow_arrays(int nmax)
{
memory->grow(xold, nmax, 3, "FixSavePos:xold");
}
void FixSavePos::copy_arrays(int i, int j, int delflag)
{
memcpy(xold[j], xold[i], sizeof(double) * 3);
}
void FixSavePos::set_arrays(int i)
{
memset(xold[i], 0, sizeof(double) * 3);
}
int FixSavePos::pack_exchange(int i, double *buf)
{
int m = 0;
buf[m++] = xold[i][0];
buf[m++] = xold[i][1];
buf[m++] = xold[i][2];
return m;
}
int FixSavePos::unpack_exchange(int nlocal, double *buf)
{
int m = 0;
xold[nlocal][0] = buf[m++];
xold[nlocal][1] = buf[m++];
xold[nlocal][2] = buf[m++];
return m;
}
Now, a little bit about memory allocation. We use the Memory class which
is just a bunch of template functions for allocating 1D and 2D
arrays. So you need to add include ``memory.h`` to have access to them.
Finally, if you need to write/read some global information used in
your fix to the restart file, you might do it by setting flag
``restart_global = 1`` in the constructor and implementing methods void
``write_restart(FILE *fp)`` and ``void restart(char *buf)``.
If, in addition, you want to write the per-atom property to restart
files additional settings and functions are needed:
- a fix flag indicating this needs to be set ``restart_peratom = 1;``
- ``atom->add_callback()`` and ``atom->delete_callback()`` must be called
a second time with the final argument set to 1 instead of 0 (indicating
restart processing instead of per-atom data memory management).
- the functions ``void pack_restart(int i, double *buf)`` and
``void unpack_restart(int nlocal, int nth)`` need to be implemented

1354
doc/src/Developer_write_pair.rst Normal file
View File

File diff suppressed because it is too large Load Diff

2
doc/src/Errors_common.rst
View File

@ -113,7 +113,7 @@ LAMMPS output, something is wrong with your simulation. If you
suspect this is happening, it is a good idea to print out
thermodynamic info frequently (e.g. every timestep) via the
:doc:`thermo <thermo>` so you can monitor what is happening.
Visualizing the atom movement is also a good idea to insure your model
Visualizing the atom movement is also a good idea to ensure your model
is behaving as you expect.
In parallel, one way LAMMPS can hang is due to how different MPI

15
doc/src/Errors_debug.rst
View File

@ -40,7 +40,7 @@ We use it to show how to identify the origin of a segmentation fault.
After recompiling LAMMPS and running the input you should get something like this:
.. code-block::
.. code-block:: console
$ ./lmp -in in.melt
LAMMPS (19 Mar 2020)
@ -75,7 +75,7 @@ Using the GDB debugger to get a stack trace
There are two options to use the GDB debugger for identifying the origin
of the segmentation fault or similar crash. The GDB debugger has many
more features and options, as can be seen for example its `online
documentation <http://sourceware.org/gdb/current/onlinedocs/gdb/>`_.
documentation <https://www.sourceware.org/gdb/documentation/>`_.
Run LAMMPS from within the debugger
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -90,8 +90,9 @@ it. When it reaches the code causing the segmentation fault, it will
stop with a message why it stopped, print the current line of code, and
drop back to the GDB prompt.
.. code-block::
.. code-block:: console
(gdb) run
[...]
Setting up Verlet run ...
Unit style : lj
@ -106,7 +107,7 @@ drop back to the GDB prompt.
Now typing the command "where" will show the stack of functions starting from
the current function back to "main()".
.. code-block::
.. code-block:: console
(gdb) where
#0 0x00000000006653ab in LAMMPS_NS::PairLJCut::compute (this=0x829740, eflag=1, vflag=<optimized out>) at /home/akohlmey/compile/lammps/src/pair_lj_cut.cpp:139
@ -124,7 +125,7 @@ You can also print the value of variables and see if there is anything
unexpected. Segmentation faults, for example, commonly happen when a
pointer variable is not assigned and still initialized to NULL.
.. code-block::
.. code-block:: console
(gdb) print x
$1 = (double **) 0x7ffff7ca1010
@ -153,7 +154,7 @@ utility to the current folder. Example: ``coredumpctl -o core dump lmp``.
Now you can launch the debugger to load the executable, its debug info
and the core dump and drop you to a prompt like before.
.. code-block::
.. code-block:: console
$ gdb lmp core
Reading symbols from lmp...
@ -186,7 +187,7 @@ recommended to redirect the valgrind output to a file (e.g. with
process ID) so that the messages of the multiple valgrind instances to
the console are not mixed.
.. code-block::
.. code-block:: console
$ valgrind ./lmp -in in.melt
==1933642== Memcheck, a memory error detector

26
doc/src/Errors_messages.rst
View File

@ -5635,7 +5635,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
Lost atoms are checked for each time thermo output is done. See the
thermo_modify lost command for options. Lost atoms usually indicate
bad dynamics, e.g. atoms have been blown far out of the simulation
box, or moved further than one processor's sub-domain away before
box, or moved further than one processor's subdomain away before
reneighboring.
*MEAM library error %d*
@ -6092,7 +6092,7 @@ keyword to allow for additional bonds to be formed
after a read_data, read_restart, or create_box command.
*Next command must list all universe and uloop variables*
This is to insure they stay in sync.
This is to ensure they stay in sync.
*No Kspace style defined for compute group/group*
Self-explanatory.
@ -6266,14 +6266,14 @@ keyword to allow for additional bonds to be formed
One or more atoms are attempting to map their charge to a MSM grid point
that is not owned by a processor. This is likely for one of two
reasons, both of them bad. First, it may mean that an atom near the
boundary of a processor's sub-domain has moved more than 1/2 the
boundary of a processor's subdomain has moved more than 1/2 the
:doc:`neighbor skin distance <neighbor>` without neighbor lists being
rebuilt and atoms being migrated to new processors. This also means
you may be missing pairwise interactions that need to be computed.
The solution is to change the re-neighboring criteria via the
:doc:`neigh_modify <neigh_modify>` command. The safest settings are
"delay 0 every 1 check yes". Second, it may mean that an atom has
moved far outside a processor's sub-domain or even the entire
moved far outside a processor's subdomain or even the entire
simulation box. This indicates bad physics, e.g. due to highly
overlapping atoms, too large a timestep, etc.
@ -6281,14 +6281,14 @@ keyword to allow for additional bonds to be formed
One or more atoms are attempting to map their charge to a PPPM grid
point that is not owned by a processor. This is likely for one of two
reasons, both of them bad. First, it may mean that an atom near the
boundary of a processor's sub-domain has moved more than 1/2 the
boundary of a processor's subdomain has moved more than 1/2 the
:doc:`neighbor skin distance <neighbor>` without neighbor lists being
rebuilt and atoms being migrated to new processors. This also means
you may be missing pairwise interactions that need to be computed.
The solution is to change the re-neighboring criteria via the
:doc:`neigh_modify <neigh_modify>` command. The safest settings are
"delay 0 every 1 check yes". Second, it may mean that an atom has
moved far outside a processor's sub-domain or even the entire
moved far outside a processor's subdomain or even the entire
simulation box. This indicates bad physics, e.g. due to highly
overlapping atoms, too large a timestep, etc.
@ -6296,14 +6296,14 @@ keyword to allow for additional bonds to be formed
One or more atoms are attempting to map their charge to a PPPM grid
point that is not owned by a processor. This is likely for one of two
reasons, both of them bad. First, it may mean that an atom near the
boundary of a processor's sub-domain has moved more than 1/2 the
boundary of a processor's subdomain has moved more than 1/2 the
:doc:`neighbor skin distance <neighbor>` without neighbor lists being
rebuilt and atoms being migrated to new processors. This also means
you may be missing pairwise interactions that need to be computed.
The solution is to change the re-neighboring criteria via the
:doc:`neigh_modify <neigh_modify>` command. The safest settings are
"delay 0 every 1 check yes". Second, it may mean that an atom has
moved far outside a processor's sub-domain or even the entire
moved far outside a processor's subdomain or even the entire
simulation box. This indicates bad physics, e.g. due to highly
overlapping atoms, too large a timestep, etc.
@ -7148,9 +7148,6 @@ keyword to allow for additional bonds to be formed
*Read_dump xyz fields do not have consistent scaling/wrapping*
Self-explanatory.
*Reading from MPI-IO filename when MPIIO package is not installed*
Self-explanatory.
*Reax_defs.h setting for NATDEF is too small*
Edit the setting in the ReaxFF library and re-compile the
library and re-build LAMMPS.
@ -7231,7 +7228,7 @@ keyword to allow for additional bonds to be formed
*Replacing a fix, but new style != old style*
A fix ID can be used a second time, but only if the style matches the
previous fix. In this case it is assumed you with to reset a fix's
previous fix. In this case it is assumed you want to reset a fix's
parameters. This error may mean you are mistakenly re-using a fix ID
when you do not intend to.
@ -7337,7 +7334,7 @@ keyword to allow for additional bonds to be formed
*Rigid body atoms %d %d missing on proc %d at step %ld*
This means that an atom cannot find the atom that owns the rigid body
it is part of, or vice versa. The solution is to use the communicate
cutoff command to insure ghost atoms are acquired from far enough away
cutoff command to ensure ghost atoms are acquired from far enough away
to encompass the max distance printed when the fix rigid/small command
was invoked.
@ -8489,9 +8486,6 @@ keyword to allow for additional bonds to be formed
The write_restart command cannot be used before a read_data,
read_restart, or create_box command.
*Writing to MPI-IO filename when MPIIO package is not installed*
Self-explanatory.
*Zero length rotation vector with displace_atoms*
Self-explanatory.

18
doc/src/Errors_warnings.rst
View File

@ -109,9 +109,9 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*Communication cutoff is shorter than a bond length based estimate. This may lead to errors.*
Since LAMMPS stores topology data with individual atoms, all atoms
comprising a bond, angle, dihedral or improper must be present on any
sub-domain that "owns" the atom with the information, either as a
subdomain that "owns" the atom with the information, either as a
local or a ghost atom. The communication cutoff is what determines up
to what distance from a sub-domain boundary ghost atoms are created.
to what distance from a subdomain boundary ghost atoms are created.
The communication cutoff is by default the largest non-bonded cutoff
plus the neighbor skin distance, but for short or non-bonded cutoffs
and/or long bonds, this may not be sufficient. This warning indicates
@ -351,7 +351,7 @@ This will most likely cause errors in kinetic fluctuations.
Self-explanatory.
*Kspace_modify slab param < 2.0 may cause unphysical behavior*
The kspace_modify slab parameter should be larger to insure periodic
The kspace_modify slab parameter should be larger to ensure periodic
grids padded with empty space do not overlap.
*Less insertions than requested*
@ -398,7 +398,7 @@ This will most likely cause errors in kinetic fluctuations.
Lost atoms are checked for each time thermo output is done. See the
thermo_modify lost command for options. Lost atoms usually indicate
bad dynamics, e.g. atoms have been blown far out of the simulation
box, or moved further than one processor's sub-domain away before
box, or moved further than one processor's subdomain away before
reneighboring.
*MSM mesh too small, increasing to 2 points in each direction*
@ -491,7 +491,7 @@ This will most likely cause errors in kinetic fluctuations.
*Neighbor exclusions used with KSpace solver may give inconsistent Coulombic energies*
This is because excluding specific pair interactions also excludes
them from long-range interactions which may not be the desired effect.
The special_bonds command handles this consistently by insuring
The special_bonds command handles this consistently by ensuring
excluded (or weighted) 1-2, 1-3, 1-4 interactions are treated
consistently by both the short-range pair style and the long-range
solver. This is not done for exclusions of charged atom pairs via the
@ -545,7 +545,7 @@ This will most likely cause errors in kinetic fluctuations.
If there are other fixes that act immediately after the initial stage
of time integration within a timestep (i.e. after atoms move), then
the command that sets up the dynamic group should appear after those
fixes. This will insure that dynamic group assignments are made
fixes. This will ensure that dynamic group assignments are made
after all atoms have moved.
*One or more respa levels compute no forces*
@ -582,13 +582,13 @@ This will most likely cause errors in kinetic fluctuations.
needed. The requested volume fraction may be too high, or other atoms
may be in the insertion region.
*Proc sub-domain size < neighbor skin, could lead to lost atoms*
*Proc subdomain size < neighbor skin, could lead to lost atoms*
The decomposition of the physical domain (likely due to load
balancing) has led to a processor's sub-domain being smaller than the
balancing) has led to a processor's subdomain being smaller than the
neighbor skin in one or more dimensions. Since reneighboring is
triggered by atoms moving the skin distance, this may lead to lost
atoms, if an atom moves all the way across a neighboring processor's
sub-domain before reneighboring is triggered.
subdomain before reneighboring is triggered.
*Reducing PPPM order b/c stencil extends beyond nearest neighbor processor*
This may lead to a larger grid than desired. See the kspace_modify overlap

12
doc/src/Examples.rst
View File

@ -1,7 +1,7 @@
Example scripts
===============
The LAMMPS distribution includes an examples sub-directory with many
The LAMMPS distribution includes an examples subdirectory with many
sample problems. Many are 2d models that run quickly and are
straightforward to visualize, requiring at most a couple of minutes to
run on a desktop machine. Each problem has an input script (in.\*) and
@ -29,7 +29,7 @@ be quickly post-processed into a movie using commands described on the
Animations of many of the examples can be viewed on the Movies section
of the `LAMMPS website <https://www.lammps.org/movies.html>`_.
There are two kinds of sub-directories in the examples folder. Lower
There are two kinds of subdirectories in the examples folder. Lower
case named directories contain one or a few simple, quick-to-run
problems. Upper case named directories contain up to several complex
scripts that illustrate a particular kind of simulation method or
@ -94,8 +94,6 @@ Lowercase directories
+-------------+------------------------------------------------------------------+
| kim | use of potentials from the `OpenKIM Repository <openkim_>`_ |
+-------------+------------------------------------------------------------------+
| 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) |
@ -106,8 +104,6 @@ Lowercase directories
+-------------+------------------------------------------------------------------+
| min | energy minimization of 2d LJ melt |
+-------------+------------------------------------------------------------------+
| mscg | parameterize a multi-scale coarse-graining (MSCG) model |
+-------------+------------------------------------------------------------------+
| msst | MSST shock dynamics |
+-------------+------------------------------------------------------------------+
| multi | multi neighboring for systems with large interaction disparities |
@ -221,10 +217,10 @@ Uppercase directories
Nearly all of these directories have README files which give more
details on how to understand and use their contents.
The PACKAGES directory has a large number of sub-directories which
The PACKAGES directory has a large number of subdirectories which
correspond by name to specific packages. They contain scripts that
illustrate how to use the command(s) provided in those packages. Many
of the sub-directories have their own README files which give further
of the subdirectories have their own README files which give further
instructions. See the :doc:`Packages_details <Packages_details>` doc
page for more info on specific packages.

3002
doc/src/Fortran.rst
View File

File diff suppressed because it is too large Load Diff

15
doc/src/Howto.rst
View File

@ -4,10 +4,10 @@ Howto discussions
These doc pages describe how to perform various tasks with LAMMPS,
both for users and developers. The
`glossary <https://www.lammps.org/glossary.html>`_ website page also lists MD
terminology with links to corresponding LAMMPS manual pages. The
example input scripts included in the examples directory of the LAMMPS
distribution and highlighted on the :doc:`Examples <Examples>` doc page
also show how to setup and run various kinds of simulations.
terminology, with links to corresponding LAMMPS manual pages. The
example input scripts included in the ``examples`` directory of the LAMMPS
source code distribution and highlighted on the :doc:`Examples` page
also show how to set up and run various kinds of simulations.
General howto
=============
@ -23,7 +23,6 @@ General howto
Howto_library
Howto_couple
Howto_mdi
Howto_bpm
Howto_broken_bonds
Settings howto
@ -51,6 +50,7 @@ Analysis howto
Howto_output
Howto_chunk
Howto_grid
Howto_temperature
Howto_elastic
Howto_kappa
@ -69,6 +69,7 @@ Force fields howto
Howto_amoeba
Howto_tip3p
Howto_tip4p
Howto_tip5p
Howto_spc
Packages howto
@ -81,10 +82,12 @@ Packages howto
Howto_spherical
Howto_granular
Howto_body
Howto_bpm
Howto_polarizable
Howto_coreshell
Howto_drude
Howto_drude2
Howto_peri
Howto_manifold
Howto_spins
@ -97,6 +100,8 @@ Tutorials howto
Howto_cmake
Howto_github
Howto_lammps_gui
Howto_moltemplate
Howto_pylammps
Howto_wsl

6
doc/src/Howto_2d.rst
View File

@ -13,16 +13,16 @@ box with a single z plane of atoms - e.g.
.. code-block:: LAMMPS
create box 1 -10 10 -10 10 -0.25 0.25
create_box 1 -10 10 -10 10 -0.25 0.25
If using the :doc:`read data <read_data>` command to read in a file of
If using the :doc:`read_data <read_data>` command to read in a file of
atom coordinates, set the "zlo zhi" values to be finite but narrow,
similar to the create_box command settings just described. For each
atom in the file, assign a z coordinate so it falls inside the
z-boundaries of the box - e.g. 0.0.
Use the :doc:`fix enforce2d <fix_enforce2d>` command as the last
defined fix to insure that the z-components of velocities and forces
defined fix to ensure that the z-components of velocities and forces
are zeroed out every timestep. The reason to make it the last fix is
so that any forces induced by other fixes will be zeroed out.

12
doc/src/Howto_amoeba.rst
View File

@ -261,11 +261,11 @@ 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
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.
@ -281,7 +281,7 @@ 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://openbabel.org/docs/current/FileFormats/Tinker_XYZ_format.html <https://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>`_

33
doc/src/Howto_bioFF.rst
View File

@ -3,24 +3,20 @@ CHARMM, AMBER, COMPASS, and DREIDING force fields
A force field has 2 parts: the formulas that define it and the
coefficients used for a particular system. Here we only discuss
formulas implemented in LAMMPS that correspond to formulas commonly
used in the CHARMM, AMBER, COMPASS, and DREIDING force fields. Setting
formulas implemented in LAMMPS that correspond to formulas commonly used
in the CHARMM, AMBER, COMPASS, and DREIDING force fields. Setting
coefficients is done either from special sections in an input data file
via the :doc:`read_data <read_data>` command or in the input script with
commands like :doc:`pair_coeff <pair_coeff>` or
:doc:`bond_coeff <bond_coeff>` and so on. See the :doc:`Tools <Tools>` doc
page for additional tools that can use CHARMM, AMBER, or Materials
Studio generated files to assign force field coefficients and convert
their output into LAMMPS input.
commands like :doc:`pair_coeff <pair_coeff>` or :doc:`bond_coeff
<bond_coeff>` and so on. See the :doc:`Tools <Tools>` doc page for
additional tools that can use CHARMM, AMBER, or Materials Studio
generated files to assign force field coefficients and convert their
output into LAMMPS input.
See :ref:`(MacKerell) <howto-MacKerell>` for a description of the CHARMM force
field. See :ref:`(Cornell) <howto-Cornell>` for a description of the AMBER
force field. See :ref:`(Sun) <howto-Sun>` for a description of the COMPASS
force field.
.. _charmm: http://www.scripps.edu/brooks
.. _amber: http://amber.scripps.edu
See :ref:`(MacKerell) <howto-MacKerell>` for a description of the CHARMM
force field. See :ref:`(Cornell) <howto-Cornell>` for a description of
the AMBER force field. See :ref:`(Sun) <howto-Sun>` for a description
of the COMPASS force field.
The interaction styles listed below compute force field formulas that
are consistent with common options in CHARMM or AMBER. See each
@ -41,9 +37,10 @@ command's documentation for the formula it computes.
.. note::
For CHARMM, newer *charmmfsw* or *charmmfsh* styles were released
in March 2017. We recommend they be used instead of the older *charmm*
styles. See discussion of the differences on the :doc:`pair charmm <pair_charmm>` and :doc:`dihedral charmm <dihedral_charmm>` doc
For CHARMM, newer *charmmfsw* or *charmmfsh* styles were released in
March 2017. We recommend they be used instead of the older *charmm*
styles. See discussion of the differences on the :doc:`pair charmm
<pair_charmm>` and :doc:`dihedral charmm <dihedral_charmm>` doc
pages.
COMPASS is a general force field for atomistic simulation of common

8
doc/src/Howto_body.rst
View File

@ -170,9 +170,9 @@ with this body style to compute body/body and body/non-body interactions.
The *rounded/polygon* body style represents body particles as a 2d
polygon with a variable number of N vertices. This style can only be
used for 2d models; see the :doc:`boundary <boundary>` command. See the
"pair_style body/rounded/polygon" page for a diagram of two
squares with rounded circles at the vertices. Special cases for N = 1
(circle) and N = 2 (rod with rounded ends) can also be specified.
:doc:`pair_style body/rounded/polygon <pair_body_rounded_polygon>` page for
a diagram of two squares with rounded circles at the vertices. Special cases
for N = 1 (circle) and N = 2 (rod with rounded ends) can also be specified.
One use of this body style is for 2d discrete element models, as
described in :ref:`Fraige <body-Fraige>`.
@ -335,7 +335,7 @@ faces are listed, so that M = 6 + 3\*N + 1.
The integer line has three values: number of vertices (N), number of
edges (E) and number of faces (F). The floating point line(s) list 6
moments of inertia followed by the coordinates of the N vertices (x1
to zN) as 3N values, followed by 2N vertex indices corresponding to
to zN) as 3N values, followed by 2E vertex indices corresponding to
the end points of the E edges, then 4\*F vertex indices defining F
faces. The last value is the diameter value = the rounded diameter of
the sphere that surrounds each vertex. The diameter value can be

177
doc/src/Howto_bpm.rst
View File

@ -3,16 +3,16 @@ 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
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
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.
@ -22,8 +22,8 @@ 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.
: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
@ -33,69 +33,22 @@ 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.
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>`.
In addition to bond styles, a new pair style :doc:`pair bpm/spring
<pair_bpm_spring>` was added to accompany the bpm/spring bond
@ -104,6 +57,83 @@ velocity damping as its sister bond style.
----------
Bond data can be output using a combination of standard LAMMPS commands.
A list of IDs for bonded atoms can be generated using the
:doc:`compute property/local <compute_property_local>` command.
Various properties of bonds can be computed using the
:doc:`compute bond/local <compute_bond_local>` command. This
command allows one to access data saved to the bond's history,
such as the reference length of the bond. More information on
bond history data can be found on the documentation pages for the specific
BPM bond styles. Finally, this data can be output using a :doc:`dump local <dump>`
command. As one may output many columns from the same compute, the
:doc:`dump modify <dump_modify>` *colname* option may be used to provide
more helpful column names. An example of this procedure is found in
/examples/bpm/pour/. External software, such as OVITO, can read these dump
files to render bond data.
----------
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 overlay
pair forces with bond forces such that all bonded particles also
feel pair interactions. This can be accomplished by setting the *overlay/pair*
keyword present in all bpm bond styles to *yes* and requires using the
following special bond settings
.. code-block:: LAMMPS
special_bonds lj/coul 1 1 1
Alternatively, 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 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. If bond breakage is
disabled during a simulation run by setting the *break* keyword to *no*,
a zero coul weight for 1-2 bonds can be used to exclude bonded atoms
from the neighbor list builds
.. code-block:: LAMMPS
special_bonds lj 0 1 1 coul 0 1 1
This can be useful for post-processing, or to determine pair interaction
properties between distinct bonded particles.
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. Since one may frequently output
a list of broken bonds and the time they broke, the
:doc:`dump modify <dump_modify>` option *header no* may be useful to
avoid repeatedly printing the header of the dump file. An example of
this procedure is found in /examples/bpm/impact/. Additionally,
one can use :doc:`compute nbond/atom <compute_nbond_atom>` to tally the
current number of bonds per atom.
See the :doc:`Howto <Howto_broken_bonds>` page on broken bonds for
more information.
----------
While LAMMPS has many utilities to create and delete bonds, *only*
the following are currently compatible with BPM bond styles:
@ -113,7 +143,10 @@ the following are currently compatible with BPM bond styles:
* :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.
.. note::
The :doc:`create_bonds <create_bonds>` command requires certain
:doc:`special_bonds <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``.

78
doc/src/Howto_broken_bonds.rst
View File

@ -1,48 +1,56 @@
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.
Typically, molecular bond interactions persist for the duration of a
simulation in LAMMPS. However, some commands break bonds dynamically,
including the following:
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.
* :doc:`bond_style quartic <bond_quartic>`
* :doc:`fix bond/break <fix_bond_break>`
* :doc:`fix bond/react <fix_bond_react>`
* :doc:`BPM package <Howto_bpm>` bond styles
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.
A bond can break if it is stretched beyond a user-defined threshold or
more generally if other criteria are met.
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.
For the quartic bond style, when a bond is broken its bond type is set
to 0 to effectively break it and pairwise forces between the two atoms
in the broken bond are "turned on". Angles, dihedrals, etc cannot be
defined for a system when :doc:`bond_style quartic <bond_quartic>` is
used.
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.:
Similarly, bond styles in the BPM package are also incompatible with
angles, dihedrals, etc. and when a bond breaks its type is set to zero.
However, 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.
The :doc:`fix bond/break <fix_bond_break>` and :doc:`fix bond/react
<fix_bond_react>` commands allow breaking of bonds within a molecular
topology with may also define angles, dihedrals, etc. These commands
update internal topology data structures to remove broken bonds, as
well as the appropriate angle, dihedral, etc interactions which
include the bond. They also trigger a rebuild of the neighbor list
when this occurs, to turn on the appropriate pairwise forces.
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 be used to query
the status of broken bonds with type = 0 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.
The compute :doc:`count/type <compute_count_type>` command tallies the
current number of bonds (or angles, etc) for each bond (angle, etc)
type. It also tallies broken bonds with type = 0.
The compute :doc:`nbond/atom <compute_nbond_atom>` command tallies the
current number of bonds each atom is part of, excluding broken bonds
with type = 0.

47
doc/src/Howto_cmake.rst
View File

@ -1,11 +1,11 @@
Using CMake with LAMMPS tutorial
================================
Using CMake with LAMMPS
=======================
The support for building LAMMPS with CMake is a recent addition to
LAMMPS thanks to the efforts of Christoph Junghans (LANL) and Richard
Berger (Temple U). One of the key strengths of CMake is that it is not
tied to a specific platform or build system and thus generate the files
necessary to build and develop for different build systems and on
Berger (LANL). One of the key strengths of CMake is that it is not
tied to a specific platform or build system. Instead it generates the
files necessary to build and develop for different build systems and on
different platforms. Note, that this applies to the build system itself
not the LAMMPS code. In other words, without additional porting effort,
it is not possible - for example - to compile LAMMPS with Visual C++ on
@ -14,7 +14,7 @@ necessary to program LAMMPS as a project in integrated development
environments (IDE) like Eclipse, Visual Studio, QtCreator, Xcode,
CodeBlocks, Kate and others.
A second important feature of CMake is, that it can detect and validate
A second important feature of CMake is that it can detect and validate
available libraries, optimal settings, available support tools and so
on, so that by default LAMMPS will take advantage of available tools
without requiring to provide the details about how to enable/integrate
@ -32,8 +32,8 @@ program ``cmake`` (or ``cmake3``), a text mode interactive user
interface (TUI) program ``ccmake`` (or ``ccmake3``), or a graphical user
interface (GUI) program ``cmake-gui``. All of them are portable
software available on all supported platforms and can be used
interchangeably. The minimum supported CMake version is 3.10 (3.12 or
later is recommended).
interchangeably. As of LAMMPS version 2 August 2023, the minimum
required CMake version is 3.16.
All details about features and settings for CMake are in the `CMake
online documentation <https://cmake.org/documentation/>`_. We focus
@ -43,11 +43,20 @@ Prerequisites
-------------
This tutorial assumes that you are operating in a command-line environment
using a shell like Bash.
using a shell like Bash or Zsh.
- Linux: any Terminal window will work
- MacOS X: launch the Terminal application.
- Windows 10: install and run the :doc:`Windows Subsystem for Linux <Howto_wsl>`
- Linux: any Terminal window will work or text console
- macOS: launch the Terminal application
- Windows 10 or 11: install and run the :doc:`Windows Subsystem for Linux <Howto_wsl>`
- other Unix-like operating systems like FreeBSD
.. note::
It is also possible to use CMake on Windows 10 or 11 through either the Microsoft
Visual Studio IDE with the bundled CMake or from the Windows command prompt using
a separately installed CMake package, both using the native Microsoft Visual C++
compilers and (optionally) the Microsoft MPI SDK. This tutorial, however, only
covers unix-like command line interfaces.
We also assume that you have downloaded and unpacked a recent LAMMPS source code package
or used Git to create a clone of the LAMMPS sources on your compilation machine.
@ -56,7 +65,7 @@ You should change into the top level directory of the LAMMPS source tree all
paths mentioned in the tutorial are relative to that. Immediately after downloading
it should look like this:
.. code-block:: bash
.. code-block:: console
$ ls
bench doc lib potentials README tools
@ -89,7 +98,7 @@ different options (``build-parallel``, ``build-serial``) or with
different compilers (``build-gnu``, ``build-clang``, ``build-intel``)
and so on. All the auxiliary files created by one build process
(executable, object files, log files, etc) are stored in this directory
or sub-directories within it that CMake creates.
or subdirectories within it that CMake creates.
Running CMake
@ -104,7 +113,7 @@ the progress of the configuration printed to the screen followed by a
summary of the enabled features, options and compiler settings. A typical
summary screen will look like this:
.. code-block::
.. code-block:: console
$ cmake ../cmake/
-- The CXX compiler identification is GNU 8.2.0
@ -338,8 +347,6 @@ Some common LAMMPS specific variables
- common compiler flags, for optimization or instrumentation (default:)
* - ``LAMMPS_MACHINE``
- when set to ``name`` the LAMMPS executable and library will be called ``lmp_name`` and ``liblammps_name.a``
* - ``LAMMPS_EXCEPTIONS``
- when set to ``on`` errors will throw a C++ exception instead of aborting (default: ``off``)
* - ``FFT``
- select which FFT library to use: ``FFTW3``, ``MKL``, ``KISS`` (default, unless FFTW3 is found)
* - ``FFT_SINGLE``
@ -412,9 +419,9 @@ interface (``ccmake`` or ``cmake-gui``).
Using a preset to select a compiler package (``clang.cmake``,
``gcc.cmake``, ``intel.cmake``, ``oneapi.cmake``, or ``pgi.cmake``)
are an exception to the mechanism of updating the configuration incrementally,
as they will trigger a reset of cached internal CMake settings and thus
reset settings to their default values.
are an exception to the mechanism of updating the configuration
incrementally, as they will trigger a reset of cached internal CMake
settings and thus reset settings to their default values.
Compilation and build targets
-----------------------------

2
doc/src/Howto_coreshell.rst
View File

@ -111,7 +111,7 @@ Therefore it is typically desirable to decouple the relative motion of
the core/shell pair, which is an imaginary degree of freedom, from the
real physical system. To do that, the :doc:`compute temp/cs <compute_temp_cs>` command can be used, in conjunction with
any of the thermostat fixes, such as :doc:`fix nvt <fix_nh>` or :doc:`fix langevin <fix_langevin>`. This compute uses the center-of-mass velocity
of the core/shell pairs to calculate a temperature, and insures that
of the core/shell pairs to calculate a temperature, and ensures that
velocity is what is rescaled for thermostatting purposes. This
compute also works for a system with both core/shell pairs and
non-polarized ions (ions without an attached satellite particle). The

62
doc/src/Howto_couple.rst
View File

@ -1,27 +1,27 @@
Coupling LAMMPS to other codes
==============================
LAMMPS is designed to allow it to be coupled to other codes. For
LAMMPS is designed to support being coupled to other codes. For
example, a quantum mechanics code might compute forces on a subset of
atoms and pass those forces to LAMMPS. Or a continuum finite element
(FE) simulation might use atom positions as boundary conditions on FE
nodal points, compute a FE solution, and return interpolated forces on
MD atoms.
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.
LAMMPS can be coupled to other codes in at least 4 different 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,
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 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.
1. Define a new :doc:`fix <fix>` or :doc:`compute <compute>` command
that calls the other code. In this scenario, LAMMPS is the driver
code. During timestepping, the fix or compute is invoked, and can
make library calls to the other code, which has been linked to LAMMPS
as a library. This is the way the :ref:`VORONOI <PKG-VORONOI>`
package, which computes Voronoi tesselations using the `Voro++
library <http://math.lbl.gov/voro++>`_, is interfaced to LAMMPS. See
the :doc:`compute voronoi <compute_voronoi_atom>` command for more
details. Also see the :doc:`Modify <Modify>` pages for information
on how to add a new fix or compute to LAMMPS.
.. spacer
@ -42,28 +42,26 @@ context of your application.
stand-alone code could communicate with LAMMPS through files that the
command writes and reads.
See the :doc:`Modify command <Modify_command>` page for info on how
to add a new command to LAMMPS.
See the :doc:`Modify command <Modify_command>` page for information
on how to add a new command to LAMMPS.
.. spacer
3. Use LAMMPS as a library called by another code. In this case the
other code is the driver and calls LAMMPS as needed. Or a wrapper
code could link and call both LAMMPS and another code as libraries.
Again, the :doc:`run <run>` command has options that allow it to be
invoked with minimal overhead (no setup or clean-up) if you wish to
do multiple short runs, driven by another program. Details about
using the library interface are given in the :doc:`library API
<Library>` documentation.
3. Use LAMMPS as a library called by another code. In this case, the
other code is the driver and calls LAMMPS as needed. Alternately, a
wrapper code could link and call both LAMMPS and another code as
libraries. Again, the :doc:`run <run>` command has options that
allow it to be invoked with minimal overhead (no setup or clean-up)
if you wish to do multiple short runs, driven by another program.
Details about using the library interface are given in the
:doc:`library API <Library>` documentation.
.. spacer
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>`_
4. Couple LAMMPS with another code in a client/server fashion, 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.
<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` page for
more information about how LAMMPS can operate in either of these modes.

92
doc/src/Howto_github.rst
View File

@ -10,7 +10,7 @@ changes or additions you have made to LAMMPS into the official LAMMPS
distribution. It uses the process of updating this very tutorial as an
example to describe the individual steps and options. You need to be
familiar with git and you may want to have a look at the `git book
<http://git-scm.com/book/>`_ to familiarize yourself with some of the
<https://git-scm.com/book/>`_ to familiarize yourself with some of the
more advanced git features used below.
As of fall 2016, submitting contributions to LAMMPS via pull requests
@ -78,13 +78,13 @@ machine via HTTPS:
.. code-block:: bash
$ git clone https://github.com/<your user name>/lammps.git <some name>
git clone https://github.com/<your user name>/lammps.git <some name>
or, if you have set up your GitHub account for using SSH keys, via SSH:
.. code-block:: bash
$ git clone git@github.com:<your user name>/lammps.git
git clone git@github.com:<your user name>/lammps.git
You can find the proper URL by clicking the "Clone or download"-button:
@ -103,21 +103,21 @@ and use git pull:
.. code-block:: bash
$ cd mylammps
$ git checkout develop
$ git pull https://github.com/lammps/lammps develop
cd mylammps
git checkout develop
git pull https://github.com/lammps/lammps develop
You can also add this URL as a remote:
.. code-block:: bash
$ git remote add upstream https://www.github.com/lammps/lammps
git remote add upstream https://www.github.com/lammps/lammps
From then on you can update your upstream branches with:
.. code-block:: bash
$ git fetch upstream
git fetch upstream
and then refer to the upstream repository branches with
`upstream/develop` or `upstream/release` and so on.
@ -129,8 +129,8 @@ workflow that updated this tutorial, and hence we will call the branch
.. code-block:: bash
$ git fetch upstream
$ git checkout -b github-tutorial-update upstream/develop
git fetch upstream
git checkout -b github-tutorial-update upstream/develop
Now that we have changed branches, we can make our changes to our local
repository. Just remember that if you want to start working on another,
@ -150,8 +150,8 @@ After everything is done, add the files to the branch and commit them:
.. code-block:: bash
$ git add doc/src/Howto_github.txt
$ git add doc/src/JPG/tutorial*.png
git add doc/src/Howto_github.txt
git add doc/src/JPG/tutorial*.png
.. warning::
@ -174,13 +174,13 @@ useful message that explains the change.
.. code-block:: bash
$ git commit -m 'Finally updated the GitHub tutorial'
git commit -m 'Finally updated the GitHub tutorial'
After the commit, the changes can be pushed to the same branch on GitHub:
.. code-block:: bash
$ git push
git push
Git will ask you for your user name and password on GitHub if you have
not configured anything. If your local branch is not present on GitHub yet,
@ -188,7 +188,7 @@ it will ask you to add it by running
.. code-block:: bash
$ git push --set-upstream origin github-tutorial-update
git push --set-upstream origin github-tutorial-update
If you correctly type your user name and
password, the feature branch should be added to your fork on GitHub.
@ -198,13 +198,13 @@ If you want to make really sure you push to the right repository
.. code-block:: bash
$ git push origin
git push origin
or using an explicit URL:
.. code-block:: bash
$ git push git@github.com:Pakketeretet2/lammps.git
git push git@github.com:Pakketeretet2/lammps.git
----------
@ -315,7 +315,7 @@ add changes. Please watch the comments to the pull requests. The two
"test" labels are used to trigger extended tests before the code is
merged. This is sometimes done by LAMMPS developers, if they suspect
that there may be some subtle side effects from your changes. It is not
done by default, because those tests are very time consuming. The
done by default, because those tests are very time-consuming. The
*ready_for_merge* label is usually attached when the LAMMPS developer
assigned to the pull request considers this request complete and to
trigger a final full test evaluation.
@ -412,10 +412,10 @@ we need to pull Axel's change back into our branch, and merge them:
.. code-block:: bash
$ git add Howto_github.txt
$ git add JPG/tutorial_reverse_pull_request*.png
$ git commit -m "Updated text and images on reverse pull requests"
$ git pull
git add Howto_github.txt
git add JPG/tutorial_reverse_pull_request*.png
git commit -m "Updated text and images on reverse pull requests"
git pull
In this case, the merge was painless because git could auto-merge:
@ -428,10 +428,10 @@ commit and push again:
.. code-block:: bash
$ git add Howto_github.txt
$ git add JPG/tutorial_reverse_pull_request6.png
$ git commit -m "Merged Axel's suggestions and updated text"
$ git push git@github.com:Pakketeretet2/lammps
git add Howto_github.txt
git add JPG/tutorial_reverse_pull_request6.png
git commit -m "Merged Axel's suggestions and updated text"
git push git@github.com:Pakketeretet2/lammps
This merge also shows up on the lammps GitHub page:
@ -456,9 +456,9 @@ branch!
.. code-block:: bash
$ git checkout develop
$ git pull https://github.com/lammps/lammps develop
$ git branch -d github-tutorial-update
git checkout develop
git pull https://github.com/lammps/lammps develop
git branch -d github-tutorial-update
If you do not pull first, it is not really a problem but git will warn
you at the next statement that you are deleting a local branch that
@ -472,19 +472,29 @@ to your remote(s) as well:
.. code-block:: bash
$ git push origin :github-tutorial-update
git push origin :github-tutorial-update
**Recent changes in the workflow**
Some changes to the workflow are not captured in this tutorial. For
example, in addition to the *develop* branch, to which all new features
should be submitted, there is also a *release* and a *stable* branch;
these have the same content as *develop*, but are only updated after a
patch release or stable release was made. Furthermore, the naming of
the patches now follow the pattern "patch_<Day><Month><Year>" to
simplify comparisons between releases. Finally, all patches and
submissions are subject to automatic testing and code checks to make
sure they at the very least compile.
Some recent changes to the workflow are not captured in this tutorial.
For example, in addition to the *develop* branch, to which all new
features should be submitted, there is also a *release*, a *stable*, and
a *maintenance* branch; the *release* branch is updated from the
*develop* as part of a feature release, and *stable* (together with
*release*) are updated from *develop* when a stable release is made. In
between stable releases, selected bug fixes and infrastructure updates
are back-ported from the *develop* branch to the *maintenance* branch
and occasionally merged to *stable* as an update release.
A discussion of the LAMMPS developer GitHub workflow can be found in the file
`doc/github-development-workflow.md <https://github.com/lammps/lammps/blob/develop/doc/github-development-workflow.md>`_
Furthermore, the naming of the release tags now follow the pattern
"patch_<Day><Month><Year>" to simplify comparisons between releases.
For stable releases additional "stable_<Day><Month><Year>" tags are
applied and update releases are tagged with
"stable_<Day><Month><Year>_update<Number>", Finally, all releases and
submissions are subject to automatic testing and code checks to make
sure they compile with a variety of compilers and popular operating
systems. Some unit and regression testing is applied as well.
A detailed discussion of the LAMMPS developer GitHub workflow can be
found in the file `doc/github-development-workflow.md
<https://github.com/lammps/lammps/blob/develop/doc/github-development-workflow.md>`_

12
doc/src/Howto_granular.rst
View File

@ -43,6 +43,15 @@ The fix style *freeze* zeroes both the force and torque of frozen
atoms, and should be used for granular system instead of the fix style
*setforce*\ .
To model heat conduction, one must add the temperature and heatflow
atom variables with:
* :doc:`fix property/atom <fix_property_atom>`
a temperature integration fix
* :doc:`fix heat/flow <fix_heat_flow>`
and a heat conduction option defined in both
* :doc:`pair_style granular <pair_granular>`
* :doc:`fix wall/gran <fix_wall_gran>`
For computational efficiency, you can eliminate needless pairwise
computations between frozen atoms by using this command:
@ -55,3 +64,6 @@ computations between frozen atoms by using this command:
will be the same as in 3d. If you wish to model granular particles in
2d as 2d discs, see the note on this topic on the :doc:`Howto 2d <Howto_2d>`
doc page, where 2d simulations are discussed.
To add custom granular contact models, see the
:doc:`modifying granular sub-models page <Modify_gran_sub_mod>`.

102
doc/src/Howto_grid.rst Normal file
View File

@ -0,0 +1,102 @@
Using distributed grids
=======================
.. versionadded:: 22Dec2022
LAMMPS has internal capabilities to create uniformly spaced grids
which overlay the simulation domain. For 2d and 3d simulations these
are 2d and 3d grids respectively. Conceptually a grid can be thought
of as a collection of grid cells. Each grid cell can store one or
more values (data).
The grid cells and data they store are distributed across processors.
Each processor owns the grid cells (and data) whose center points lie
within the spatial subdomain of the processor. If needed for its
computations, a processor may also store ghost grid cells with their
data.
Distributed grids can overlay orthogonal or triclinic simulation
boxes; see the :doc:`Howto triclinic <Howto_triclinic>` doc page for
an explanation of the latter. For a triclinic box, the grid cell
shape conforms to the shape of the simulation domain,
e.g. parallelograms instead of rectangles in 2d.
If the box size or shape changes during a simulation, the grid changes
with it, so that it always overlays the entire simulation domain. For
non-periodic dimensions, the grid size in that dimension matches the
box size, as set by the :doc:`boundary <boundary>` command for fixed
or shrink-wrapped boundaries.
If load-balancing is invoked by the :doc:`balance <balance>` or
:doc:`fix balance <fix_balance>` commands, then the subdomain owned
by a processor can change which may also change which grid cells they
own.
Post-processing and visualization of grid cell data can be enabled by
the :doc:`dump grid <dump>`, :doc:`dump grid/vtk <dump>`, and
:doc:`dump image <dump_image>` commands. The latter has an optional
*grid* keyword. The `OVITO visualization tool
<https://www.ovito.org>`_ also plans (as of Nov 2022) to add support
for visualizing grid cell data (along with atoms) using :doc:`dump
grid <dump>` output files as input.
.. note::
For developers, distributed grids are implemented within the code via
two classes: Grid2d and Grid3d. These partition the grid across
processors and have methods which allow forward and reverse
communication of ghost grid data as well as load balancing. If you
write a new compute or fix which needs a distributed grid, these are
the classes to look at. A new pair style could use a distributed
grid by having a fix define it. Please see the section on
:doc:`using distributed grids within style classes <Developer_grid>`
for a detailed description.
----------
These are the commands which currently define or use distributed
grids:
* :doc:`fix ttm/grid <fix_ttm>` - store electron temperature on grid
* :doc:`fix ave/grid <fix_ave_grid>` - time average per-atom or per-grid values
* :doc:`compute property/grid <compute_property_grid>` - generate grid IDs and coords
* :doc:`dump grid <dump>` - output per-grid values in LAMMPS format
* :doc:`dump grid/vtk <dump>` - output per-grid values in VTK format
* :doc:`dump image grid <dump_image>` - include colored grid in output images
* :doc:`pair_style amoeba <pair_amoeba>` - FFT grids
* :doc:`kspace_style pppm <kspace_style>` (and variants) - FFT grids
* :doc:`kspace_style msm <kspace_style>` (and variants) - MSM grids
The grids used by the :doc:`kspace_style <kspace_style>` can not be
referenced by an input script. However the grids and data created and
used by the other commands can be.
A compute or fix command may create one or more grids (of different
sizes). Each grid can store one or more data fields. A data field
can be a single value per grid point (per-grid vector) or multiple
values per grid point (per-grid array). See the :doc:`Howto output
<Howto_output>` doc page for an explanation of how per-grid data can
be generated by some commands and used by other commands.
A command accesses grid data from a compute or fix using a *grid
reference* with the following syntax:
* c_ID:gname:dname
* c_ID:gname:dname[I]
* f_ID:gname:dname
* f_ID:gname:dname[I]
The prefix "c\_" or "f\_" refers to the ID of the compute or fix; gname is
the name of the grid, which is assigned by the compute or fix; dname is
the name of the data field, which is also assigned by the compute or
fix.
If the data field is a per-grid vector (one value per grid point),
then no brackets are used to access the values. If the data field is
a per-grid array (multiple values per grid point), then brackets are
used to specify the column I of the array. I ranges from 1 to Ncol
inclusive, where Ncol is the number of columns in the array and is
defined by the compute or fix.
Currently, there are no per-grid variables implemented in LAMMPS. We
may add this feature at some point.

700
doc/src/Howto_lammps_gui.rst Normal file
View File

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

18
doc/src/Howto_library.rst
View File

@ -6,22 +6,22 @@ can be built as a static or shared library, so that it can be called by
another code, used in a :doc:`coupled manner <Howto_couple>` with other
codes, or driven through a :doc:`Python interface <Python_head>`.
At the core of LAMMPS is the ``LAMMPS`` class which encapsulates the
At the core of LAMMPS is the ``LAMMPS`` class, which encapsulates the
state of the simulation program through the state of the various class
instances that it is composed of. So a calculation using LAMMPS
requires to create an instance of the ``LAMMPS`` class and then send it
requires creating an instance of the ``LAMMPS`` class and then send it
(text) commands, either individually or from a file, or perform other
operations that modify the state stored inside that instance or drive
simulations. This is essentially what the ``src/main.cpp`` file does
as well for the standalone LAMMPS executable with reading commands
either from an input file or stdin.
simulations. This is essentially what the ``src/main.cpp`` file does as
well for the standalone LAMMPS executable, reading commands either from
an input file or the standard input.
Creating a LAMMPS instance can be done by using C++ code directly or
through a C-style interface library to LAMMPS that is provided in the
files ``src/library.cpp`` and ``library.h``. This
:ref:`C language API <lammps_c_api>`, can be used from C and C++,
and is also the basis for the :doc:`Python <Python_module>` and
:doc:`Fortran <Fortran>` interfaces or wrappers included in the
files ``src/library.cpp`` and ``src/library.h``. This :ref:`C language
API <lammps_c_api>`, can be used from C and C++, and is also the basis
for the :doc:`Python <Python_module>` and :doc:`Fortran <Fortran>`
interfaces or the :ref:`SWIG based wrappers <swig>` included in the
LAMMPS source code.
The ``examples/COUPLE`` and ``python/examples`` directories contain some

2
doc/src/Howto_manifold.rst
View File

@ -47,4 +47,4 @@ to the relevant fixes.
.. _Paquay1:
**(Paquay)** Paquay and Kusters, Biophys. J., 110, 6, (2016).
preprint available at `arXiv:1411.3019 <http://arxiv.org/abs/1411.3019/>`_.
preprint available at `arXiv:1411.3019 <https://arxiv.org/abs/1411.3019/>`_.

146
doc/src/Howto_mdi.rst
View File

@ -12,11 +12,11 @@ developed by the `Molecular Sciences Software Institute (MolSSI)
<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.
Alternate methods for coupling codes with LAMMPS are described on the
:doc:`Howto_couple` page.
Some advantages of client/server coupling are that the codes can run
as stand-alone executables; they need not be linked together. Thus
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
@ -41,7 +41,7 @@ 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
plugin MDI engine. When it operates as a driver, it can use either
stand-alone or plugin MDI engines.
The way in which an MDI driver communicates with an MDI engine is by
@ -50,114 +50,102 @@ 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.
engine via MPI calls or sockets. This is 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
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
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.
The package furthermore includes a :doc:`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.
As explained in the :doc:`fix mdi/qm <fix_mdi_qm>` command
documentation, 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 package also has a :doc:`fix mdi/qmmm <fix_mdi_qmmm>` command in
which LAMMPS operates as an MDI driver in conjunction with a quantum
mechanics code as an MDI engine to perform QM/MM simulations. The
LAMMPS input script partitions the system into QM and MM (molecular
mechanics) atoms. As described below the ``examples/QUANTUM`` directory
has examples for coupling to 3 different quantum codes in this manner.
----------
The examples/mdi directory contains Python scripts and LAMMPS input
script which use LAMMPS as either an MDI driver or engine or both.
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
* 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
* LAMMPS runs an MD simulation as a driver. 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.
* LAMMPS loops over a series of data files and passes the configuration
to an MDI engine to evaluate the energy, virial, and peratom forces
and thus acts as a simulation driver. As the engine, LAMMPS is used
as 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.
* 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.
.. note::
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.
In any of these examples where LAMMPS is used as an engine, an actual
QM code (provided it has support for 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
as a plugin library.
-------------
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
As of March 2023, these are quantum codes with MDI support provided via
Python wrapper scripts included in the LAMMPS distribution. These can
be used with the fix mdi/qm and fix mdi/qmmm commands to perform QM
calculations of an entire system (e.g. AIMD) or QM/MM simulations. See
the ``examples/QUANTUM`` sub-directories for more details:
* LATTE - AIMD only
* PySCF - QM/MM only
* NWChem - AIMD or QM/MM
There are also at least two quantum 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
% 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>`_
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
% 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
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:
.. code-block:: bash
% 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
These direct- and indirect-support codes should be usable for full
system calculations (e.g. AIMD). Whether they support QM/MM models
depends on the individual QM code.

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

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

2
doc/src/Howto_multiple.rst
View File

@ -4,7 +4,7 @@ Run multiple simulations from one input script
This can be done in several ways. See the documentation for
individual commands for more details on how these examples work.
If "multiple simulations" means continue a previous simulation for
If "multiple simulations" means to continue a previous simulation for
more timesteps, then you simply use the :doc:`run <run>` command
multiple times. For example, this script

405
doc/src/Howto_output.rst
View File

@ -1,7 +1,7 @@
Output from LAMMPS (thermo, dumps, computes, fixes, variables)
==============================================================
There are four basic kinds of LAMMPS output:
There are four basic forms of LAMMPS output:
* :doc:`Thermodynamic output <thermo_style>`, which is a list of
quantities printed every few timesteps to the screen and logfile.
@ -20,16 +20,18 @@ output files, depending on what :doc:`dump <dump>` and :doc:`fix <fix>`
commands you specify.
As discussed below, LAMMPS gives you a variety of ways to determine
what quantities are computed and printed when the thermodynamics,
what quantities are calculated and printed when the thermodynamics,
dump, or fix commands listed above perform output. Throughout this
discussion, note that users can also :doc:`add their own computes and fixes to LAMMPS <Modify>` which can then generate values that can then be
discussion, note that users can also :doc:`add their own computes and
fixes to LAMMPS <Modify>` which can generate values that can then be
output with these commands.
The following sub-sections discuss different LAMMPS command related
The following subsections discuss different LAMMPS commands related
to output and the kind of data they operate on and produce:
* :ref:`Global/per-atom/local data <global>`
* :ref:`Global/per-atom/local/per-grid data <global>`
* :ref:`Scalar/vector/array data <scalar>`
* :ref:`Disambiguation <disambiguation>`
* :ref:`Thermodynamic output <thermo>`
* :ref:`Dump file output <dump>`
* :ref:`Fixes that write output files <fixoutput>`
@ -42,32 +44,68 @@ to output and the kind of data they operate on and produce:
.. _global:
Global/per-atom/local data
--------------------------
Global/per-atom/local/per-grid data
-----------------------------------
Various output-related commands work with three different styles of
data: global, per-atom, or local. A global datum is one or more
system-wide values, e.g. the temperature of the system. A per-atom
datum is one or more values per atom, e.g. the kinetic energy of each
atom. Local datums are calculated by each processor based on the
atoms it owns, but there may be zero or more per atom, e.g. a list of
bond distances.
Various output-related commands work with four different "styles" of
data: global, per-atom, local, and per-grid. A global datum is one or
more system-wide values, e.g. the temperature of the system. A
per-atom datum is one or more values per atom, e.g. the kinetic energy
of each atom. Local datums are calculated by each processor based on
the atoms it owns, and there may be zero or more per atom, e.g. a list
of bond distances.
A per-grid datum is one or more values per grid cell, for a grid which
overlays the simulation domain. Similar to atoms and per-atom data,
the grid cells and the data they store are distributed across
processors; each processor owns the grid cells whose center points
fall within its subdomain.
.. _scalar:
Scalar/vector/array data
------------------------
Global, per-atom, and local datums can each come in three kinds: a
single scalar value, a vector of values, or a 2d array of values. The
doc page for a "compute" or "fix" or "variable" that generates data
will specify both the style and kind of data it produces, e.g. a
per-atom vector.
Global, per-atom, local, and per-grid datums can come in three
"kinds": a single scalar value, a vector of values, or a 2d array of
values. More specifically these are the valid kinds for each style:
When a quantity is accessed, as in many of the output commands
discussed below, it can be referenced via the following bracket
notation, where ID in this case is the ID of a compute. The leading
"c\_" would be replaced by "f\_" for a fix, or "v\_" for a variable:
* global scalar
* global vector
* global array
* per-atom vector
* per-atom array
* local vector
* local array
* per-grid vector
* per-grid array
A per-atom vector means a single value per atom; the "vector" is the
length of the number of atoms. A per-atom array means multiple values
per atom. Similarly a local vector or array means one or multiple
values per entity (e.g. per bond in the system). And a per-grid
vector or array means one or multiple values per grid cell.
The doc page for a compute or fix or variable that generates data will
specify both the styles and kinds of data it produces, e.g. a per-atom
vector. Note that a compute or fix may generate multiple styles and
kinds of output. However, for per-atom data only a vector or array is
output, never both. Likewise for per-local and per-grid data. An
example of a fix which generates multiple styles and kinds of data is
the :doc:`fix mdi/qm <fix_mdi_qm>` command. It outputs a global
scalar, global vector, and per-atom array for the quantum mechanical
energy and virial of the system and forces on each atom.
By contrast, different variable styles generate only a single kind of
data: a global scalar for an equal-style variable, global vector for a
vector-style variable, and a per-atom vector for an atom-style
variable.
When data is accessed by another command, as in many of the output
commands discussed below, it can be referenced via the following
bracket notation, where ID in this case is the ID of a compute. The
leading "c\_" would be replaced by "f\_" for a fix, or "v\_" for a
variable (and ID would be the name of the variable):
+-------------+--------------------------------------------+
| c_ID | entire scalar, vector, or array |
@ -77,28 +115,56 @@ notation, where ID in this case is the ID of a compute. The leading
| c_ID[I][J] | one element of array |
+-------------+--------------------------------------------+
In other words, using one bracket reduces the dimension of the data
once (vector -> scalar, array -> vector). Using two brackets reduces
the dimension twice (array -> scalar). Thus a command that uses
scalar values as input can typically also process elements of a vector
or array.
Note that using one bracket reduces the dimension of the data once
(vector -> scalar, array -> vector). Using two brackets reduces the
dimension twice (array -> scalar). Thus a command that uses scalar
values as input can also conceptually operate on an element of a
vector or array.
Per-grid vectors or arrays are accessed similarly, except that the ID
for the compute or fix includes a grid name and a data name. This is
because a fix or compute can create multiple grids (of different
sizes) and multiple sets of data (for each grid). The fix or compute
defines names for each grid and for each data set, so that all of them
can be accessed by other commands. See the :doc:`Howto grid
<Howto_grid>` doc page for more details.
.. _disambiguation:
Disambiguation
--------------
Some computes and fixes produce data in multiple styles, e.g. a global
scalar and a per-atom vector. Usually the context in which the input
script references the data determines which style is meant. Example: if
a compute provides both a global scalar and a per-atom vector, the
former will be accessed by using ``c_ID`` in an equal-style variable,
while the latter will be accessed by using ``c_ID`` in an atom-style
variable. Note that atom-style variable formulas can also access global
scalars, but in this case it is not possible to do directly because of
the ambiguity. Instead, an equal-style variable can be defined which
accesses the global scalar, and that variable used in the atom-style
variable formula in place of ``c_ID``.
When a compute or fix produces data in multiple styles, e.g. global
and per-atom, a reference to the data can sometimes be ambiguous.
Usually the context in which the input script references the data
determines which style is meant.
For example, if a compute outputs a global vector and a per-atom
array, an element of the global vector will be accessed by using
``c_ID[I]`` in :doc:`thermodynamic output <thermo_style>`, while a
column of the per-atom array will be accessed by using ``c_ID[I]`` in
a :doc:`dump custom <dump>` command.
However, if a :doc:`atom-style variable <variable>` references
``c_ID[I]``, then it could be intended to refer to a single element of
the global vector or a column of the per-atom array. The doc page for
any command that has a potential ambiguity (variables are the most
common) will explain how to resolve the ambiguity.
In this case, an atom-style variables references per-atom data if it
exists. If access to an element of a global vector is needed (as in
this example), an equal-style variable which references the value can
be defined and used in the atom-style variable formula instead.
Similarly, :doc:`thermodynamic output <thermo_style>` can only
reference global data from a compute or fix. But you can indirectly
access per-atom data as follows. The reference ``c_ID[245][2]`` for
the ID of a :doc:`compute displace/atom <compute_displace_atom>`
command, refers to the y-component of displacement for the atom with
ID 245. While you cannot use that reference directly in the
:doc:`thermo_style <thermo_style>` command, you can use it an
equal-style variable formula, and then reference the variable in
thermodynamic output.
.. _thermo:
@ -107,15 +173,14 @@ Thermodynamic output
The frequency and format of thermodynamic output is set by the
:doc:`thermo <thermo>`, :doc:`thermo_style <thermo_style>`, and
:doc:`thermo_modify <thermo_modify>` commands. The
:doc:`thermo_style <thermo_style>` command also specifies what values
are calculated and written out. Pre-defined keywords can be specified
(e.g. press, etotal, etc). Three additional kinds of keywords can
also be specified (c_ID, f_ID, v_name), where a :doc:`compute <compute>`
or :doc:`fix <fix>` or :doc:`variable <variable>` provides the value to be
output. In each case, the compute, fix, or variable must generate
global values for input to the :doc:`thermo_style custom <dump>`
command.
:doc:`thermo_modify <thermo_modify>` commands. The :doc:`thermo_style
<thermo_style>` command also specifies what values are calculated and
written out. Pre-defined keywords can be specified (e.g. press, etotal,
etc). Three additional kinds of keywords can also be specified (c_ID,
f_ID, v_name), where a :doc:`compute <compute>` or :doc:`fix <fix>` or
:doc:`variable <variable>` provides the value to be output. In each
case, the compute, fix, or variable must generate global values for
input to the :doc:`thermo_style custom <dump>` command.
Note that thermodynamic output values can be "extensive" or
"intensive". The former scale with the number of atoms in the system
@ -141,9 +206,10 @@ There is also a :doc:`dump custom <dump>` format where the user
specifies what values are output with each atom. Pre-defined atom
attributes can be specified (id, x, fx, etc). Three additional kinds
of keywords can also be specified (c_ID, f_ID, v_name), where a
:doc:`compute <compute>` or :doc:`fix <fix>` or :doc:`variable <variable>`
provides the values to be output. In each case, the compute, fix, or
variable must generate per-atom values for input to the :doc:`dump custom <dump>` command.
:doc:`compute <compute>` or :doc:`fix <fix>` or :doc:`variable
<variable>` provides the values to be output. In each case, the
compute, fix, or variable must generate per-atom values for input to
the :doc:`dump custom <dump>` command.
There is also a :doc:`dump local <dump>` format where the user specifies
what local values to output. A pre-defined index keyword can be
@ -154,18 +220,23 @@ provides the values to be output. In each case, the compute or fix
must generate local values for input to the :doc:`dump local <dump>`
command.
There is also a :doc:`dump grid <dump>` format where the user
specifies what per-grid values to output from computes or fixes that
generate per-grid data.
.. _fixoutput:
Fixes that write output files
-----------------------------
Several fixes take various quantities as input and can write output
files: :doc:`fix ave/time <fix_ave_time>`, :doc:`fix ave/chunk <fix_ave_chunk>`, :doc:`fix ave/histo <fix_ave_histo>`,
:doc:`fix ave/correlate <fix_ave_correlate>`, and :doc:`fix print <fix_print>`.
files: :doc:`fix ave/time <fix_ave_time>`, :doc:`fix ave/chunk
<fix_ave_chunk>`, :doc:`fix ave/histo <fix_ave_histo>`, :doc:`fix
ave/correlate <fix_ave_correlate>`, and :doc:`fix print <fix_print>`.
The :doc:`fix ave/time <fix_ave_time>` command enables direct output to
a file and/or time-averaging of global scalars or vectors. The user
specifies one or more quantities as input. These can be global
The :doc:`fix ave/time <fix_ave_time>` command enables direct output
to a file and/or time-averaging of global scalars or vectors. The
user specifies one or more quantities as input. These can be global
:doc:`compute <compute>` values, global :doc:`fix <fix>` values, or
:doc:`variables <variable>` of any style except the atom style which
produces per-atom values. Since a variable can refer to keywords used
@ -184,8 +255,14 @@ atoms, e.g. individual molecules. The per-atom quantities can be atom
density (mass or number) or atom attributes such as position,
velocity, force. They can also be per-atom quantities calculated by a
:doc:`compute <compute>`, by a :doc:`fix <fix>`, or by an atom-style
:doc:`variable <variable>`. The chunk-averaged output of this fix can
also be used as input to other output commands.
:doc:`variable <variable>`. The chunk-averaged output of this fix is
global and can also be used as input to other output commands.
Note that the :doc:`fix ave/grid <fix_ave_grid>` command can also
average the same per-atom quantities within spatial bins, but it does
this for a distributed grid whose grid cells are owned by different
processors. It outputs per-grid data, not global data, so it is more
efficient for large numbers of averaging bins.
The :doc:`fix ave/histo <fix_ave_histo>` command enables direct output
to a file of histogrammed quantities, which can be global or per-atom
@ -202,38 +279,53 @@ written to the screen and log file or to a separate file, periodically
during a running simulation. The line can contain one or more
:doc:`variable <variable>` values for any style variable except the
vector or atom styles). As explained above, variables themselves can
contain references to global values generated by :doc:`thermodynamic keywords <thermo_style>`, :doc:`computes <compute>`,
:doc:`fixes <fix>`, or other :doc:`variables <variable>`, or to per-atom
values for a specific atom. Thus the :doc:`fix print <fix_print>`
command is a means to output a wide variety of quantities separate
from normal thermodynamic or dump file output.
contain references to global values generated by :doc:`thermodynamic
keywords <thermo_style>`, :doc:`computes <compute>`, :doc:`fixes
<fix>`, or other :doc:`variables <variable>`, or to per-atom values
for a specific atom. Thus the :doc:`fix print <fix_print>` command is
a means to output a wide variety of quantities separate from normal
thermodynamic or dump file output.
.. _computeoutput:
Computes that process output quantities
---------------------------------------
The :doc:`compute reduce <compute_reduce>` and :doc:`compute reduce/region <compute_reduce>` commands take one or more per-atom
or local vector quantities as inputs and "reduce" them (sum, min, max,
The :doc:`compute reduce <compute_reduce>` and :doc:`compute
reduce/region <compute_reduce>` commands take one or more per-atom or
local vector quantities as inputs and "reduce" them (sum, min, max,
ave) to scalar quantities. These are produced as output values which
can be used as input to other output commands.
The :doc:`compute slice <compute_slice>` command take one or more global
vector or array quantities as inputs and extracts a subset of their
values to create a new vector or array. These are produced as output
values which can be used as input to other output commands.
The :doc:`compute slice <compute_slice>` command take one or more
global vector or array quantities as inputs and extracts a subset of
their values to create a new vector or array. These are produced as
output values which can be used as input to other output commands.
The :doc:`compute property/atom <compute_property_atom>` command takes a
list of one or more pre-defined atom attributes (id, x, fx, etc) and
The :doc:`compute property/atom <compute_property_atom>` command takes
a list of one or more pre-defined atom attributes (id, x, fx, etc) and
stores the values in a per-atom vector or array. These are produced
as output values which can be used as input to other output commands.
The list of atom attributes is the same as for the :doc:`dump custom <dump>` command.
The list of atom attributes is the same as for the :doc:`dump custom
<dump>` command.
The :doc:`compute property/local <compute_property_local>` command takes
a list of one or more pre-defined local attributes (bond info, angle
info, etc) and stores the values in a local vector or array. These
are produced as output values which can be used as input to other
output commands.
The :doc:`compute property/local <compute_property_local>` command
takes a list of one or more pre-defined local attributes (bond info,
angle info, etc) and stores the values in a local vector or array.
These are produced as output values which can be used as input to
other output commands.
The :doc:`compute property/grid <compute_property_grid>` command takes
a list of one or more pre-defined per-grid attributes (id, grid cell
coords, etc) and stores the values in a per-grid vector or array.
These are produced as output values which can be used as input to the
:doc:`dump grid <dump>` command.
The :doc:`compute property/chunk <compute_property_chunk>` command
takes a list of one or more pre-defined chunk attributes (id, count,
coords for spatial bins) and stores the values in a global vector or
array. These are produced as output values which can be used as input
to other output commands.
.. _fixprocoutput:
@ -247,18 +339,42 @@ a time.
The :doc:`fix ave/atom <fix_ave_atom>` command performs time-averaging
of per-atom vectors. The per-atom quantities can be atom attributes
such as position, velocity, force. They can also be per-atom
quantities calculated by a :doc:`compute <compute>`, by a
:doc:`fix <fix>`, or by an atom-style :doc:`variable <variable>`. The
quantities calculated by a :doc:`compute <compute>`, by a :doc:`fix
<fix>`, or by an atom-style :doc:`variable <variable>`. The
time-averaged per-atom output of this fix can be used as input to
other output commands.
The :doc:`fix store/state <fix_store_state>` command can archive one or
more per-atom attributes at a particular time, so that the old values
can be used in a future calculation or output. The list of atom
attributes is the same as for the :doc:`dump custom <dump>` command,
including per-atom quantities calculated by a :doc:`compute <compute>`,
by a :doc:`fix <fix>`, or by an atom-style :doc:`variable <variable>`.
The output of this fix can be used as input to other output commands.
The :doc:`fix store/state <fix_store_state>` command can archive one
or more per-atom attributes at a particular time, so that the old
values can be used in a future calculation or output. The list of
atom attributes is the same as for the :doc:`dump custom <dump>`
command, including per-atom quantities calculated by a :doc:`compute
<compute>`, by a :doc:`fix <fix>`, or by an atom-style :doc:`variable
<variable>`. The output of this fix can be used as input to other
output commands.
The :doc:`fix ave/grid <fix_ave_grid>` command performs time-averaging
of either per-atom or per-grid data.
For per-atom data it performs averaging for the atoms within each grid
cell, similar to the :doc:`fix ave/chunk <fix_ave_chunk>` command when
its chunks are defined as regular 2d or 3d bins. The per-atom
quantities can be atom density (mass or number) or atom attributes
such as position, velocity, force. They can also be per-atom
quantities calculated by a :doc:`compute <compute>`, by a :doc:`fix
<fix>`, or by an atom-style :doc:`variable <variable>`.
The chief difference between the :doc:`fix ave/grid <fix_ave_grid>`
and :doc:`fix ave/chunk <fix_ave_chunk>` commands when used in this
context is that the former uses a distributed grid, while the latter
uses a global grid. Distributed means that each processor owns the
subset of grid cells within its subdomain. Global means that each
processor owns a copy of the entire grid. The :doc:`fix ave/grid
<fix_ave_grid>` command is thus more efficient for large grids.
For per-grid data, the :doc:`fix ave/grid <fix_ave_grid>` command
takes inputs for grid data produced by other computes or fixes and
averages the values for each grid point over time.
.. _compute:
@ -266,24 +382,25 @@ Computes that generate values to output
---------------------------------------
Every :doc:`compute <compute>` in LAMMPS produces either global or
per-atom or local values. The values can be scalars or vectors or
arrays of data. These values can be output using the other commands
described in this section. The page for each compute command
per-atom or local or per-grid values. The values can be scalars or
vectors or arrays of data. These values can be output using the other
commands described in this section. The page for each compute command
describes what it produces. Computes that produce per-atom or local
values have the word "atom" or "local" in their style name. Computes
without the word "atom" or "local" produce global values.
or per-grid values have the word "atom" or "local" or "grid as the
last word in their style name. Computes without the word "atom" or
"local" or "grid" produce global values.
.. _fix:
Fixes that generate values to output
------------------------------------
Some :doc:`fixes <fix>` in LAMMPS produces either global or per-atom or
local values which can be accessed by other commands. The values can
be scalars or vectors or arrays of data. These values can be output
using the other commands described in this section. The page for
each fix command tells whether it produces any output quantities and
describes them.
Some :doc:`fixes <fix>` in LAMMPS produces either global or per-atom
or local or per-grid values which can be accessed by other commands.
The values can be scalars or vectors or arrays of data. These values
can be output using the other commands described in this section. The
page for each fix command tells whether it produces any output
quantities and describes them.
.. _variable:
@ -300,6 +417,8 @@ computes, fixes, and other variables. The values generated by
variables can be used as input to and thus output by the other
commands described in this section.
Per-grid variables have not (yet) been implemented.
.. _table:
Summary table of output options and data flow between commands
@ -316,47 +435,55 @@ output and input data types must match, e.g. global/per-atom/local
data and scalar/vector/array data.
Also note that, as described above, when a command takes a scalar as
input, that could be an element of a vector or array. Likewise a
input, that could also be an element of a vector or array. Likewise a
vector input could be a column of an array.
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| Command | Input | Output |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`thermo_style custom <thermo_style>` | global scalars | screen, log file |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`dump custom <dump>` | per-atom vectors | dump file |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`dump local <dump>` | local vectors | dump file |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`fix print <fix_print>` | global scalar from variable | screen, file |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`print <print>` | global scalar from variable | screen |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`computes <compute>` | N/A | global/per-atom/local scalar/vector/array |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`fixes <fix>` | N/A | global/per-atom/local scalar/vector/array |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`variables <variable>` | global scalars and vectors, per-atom vectors | global scalar and vector, per-atom vector |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`compute reduce <compute_reduce>` | per-atom/local vectors | global scalar/vector |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`compute slice <compute_slice>` | global vectors/arrays | global vector/array |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`compute property/atom <compute_property_atom>` | per-atom vectors | per-atom vector/array |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`compute property/local <compute_property_local>` | local vectors | local vector/array |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`fix vector <fix_vector>` | global scalars | global vector |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`fix ave/atom <fix_ave_atom>` | per-atom vectors | per-atom vector/array |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`fix ave/time <fix_ave_time>` | global scalars/vectors | global scalar/vector/array, file |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`fix ave/chunk <fix_ave_chunk>` | per-atom vectors | global array, file |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`fix ave/histo <fix_ave_histo>` | global/per-atom/local scalars and vectors | global array, file |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`fix ave/correlate <fix_ave_correlate>` | global scalars | global array, file |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
| :doc:`fix store/state <fix_store_state>` | per-atom vectors | per-atom vector/array |
+--------------------------------------------------------+----------------------------------------------+-------------------------------------------+
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| Command | Input | Output |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`thermo_style custom <thermo_style>` | global scalars | screen, log file |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`dump custom <dump>` | per-atom vectors | dump file |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`dump local <dump>` | local vectors | dump file |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`dump grid <dump>` | per-grid vectors | dump file |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`fix print <fix_print>` | global scalar from variable | screen, file |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`print <print>` | global scalar from variable | screen |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`computes <compute>` | N/A | global/per-atom/local/per-grid scalar/vector/array |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`fixes <fix>` | N/A | global/per-atom/local/per-grid scalar/vector/array |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`variables <variable>` | global scalars and vectors, per-atom vectors | global scalar and vector, per-atom vector |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`compute reduce <compute_reduce>` | per-atom/local vectors | global scalar/vector |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`compute slice <compute_slice>` | global vectors/arrays | global vector/array |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`compute property/atom <compute_property_atom>` | N/A | per-atom vector/array |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`compute property/local <compute_property_local>` | N/A | local vector/array |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`compute property/grid <compute_property_grid>` | N/A | per-grid vector/array |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`compute property/chunk <compute_property_chunk>` | N/A | global vector/array |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`fix vector <fix_vector>` | global scalars | global vector |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`fix ave/atom <fix_ave_atom>` | per-atom vectors | per-atom vector/array |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`fix ave/time <fix_ave_time>` | global scalars/vectors | global scalar/vector/array, file |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`fix ave/chunk <fix_ave_chunk>` | per-atom vectors | global array, file |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`fix ave/grid <fix_ave_grid>` | per-atom vectors or per-grid vectors | per-grid vector/array |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`fix ave/histo <fix_ave_histo>` | global/per-atom/local scalars and vectors | global array, file |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`fix ave/correlate <fix_ave_correlate>` | global scalars | global array, file |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
| :doc:`fix store/state <fix_store_state>` | per-atom vectors | per-atom vector/array |
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+

1078
doc/src/Howto_peri.rst Normal file
View File

File diff suppressed because it is too large Load Diff

68
doc/src/Howto_pylammps.rst
View File

@ -53,10 +53,10 @@ System-wide Installation
Step 1: Building LAMMPS as a shared library
"""""""""""""""""""""""""""""""""""""""""""
To use LAMMPS inside of Python it has to be compiled as shared library. This
library is then loaded by the Python interface. In this example we enable the
MOLECULE package and compile LAMMPS with C++ exceptions, PNG, JPEG and FFMPEG
output support enabled.
To use LAMMPS inside of Python it has to be compiled as shared
library. This library is then loaded by the Python interface. In this
example we enable the MOLECULE package and compile LAMMPS with PNG, JPEG
and FFMPEG output support enabled.
Step 1a: For the CMake based build system, the steps are:
@ -66,7 +66,7 @@ Step 1a: For the CMake based build system, the steps are:
cd $LAMMPS_DIR/build-shared
# MPI, PNG, Jpeg, FFMPEG are auto-detected
cmake ../cmake -DPKG_MOLECULE=yes -DLAMMPS_EXCEPTIONS=yes -DBUILD_LIB=yes -DBUILD_SHARED_LIBS=yes
cmake ../cmake -DPKG_MOLECULE=yes -DBUILD_LIB=yes -DBUILD_SHARED_LIBS=yes
make
Step 1b: For the legacy, make based build system, the steps are:
@ -79,7 +79,7 @@ Step 1b: For the legacy, make based build system, the steps are:
make yes-MOLECULE
# compile shared library using Makefile
make mpi mode=shlib LMP_INC="-DLAMMPS_PNG -DLAMMPS_JPEG -DLAMMPS_FFMPEG -DLAMMPS_EXCEPTIONS" JPG_LIB="-lpng -ljpeg"
make mpi mode=shlib LMP_INC="-DLAMMPS_PNG -DLAMMPS_JPEG -DLAMMPS_FFMPEG" JPG_LIB="-lpng -ljpeg"
Step 2: Installing the LAMMPS Python package
""""""""""""""""""""""""""""""""""""""""""""
@ -133,7 +133,7 @@ to the location in the virtual environment with:
.. code-block:: bash
cmake . -DPYTHON_EXECUTABLE=$(which python)
cmake . -DPython_EXECUTABLE=$(which python)
# install LAMMPS package in virtualenv
(testing) make install-python
@ -152,14 +152,14 @@ Creating a new instance of PyLammps
To create a PyLammps object you need to first import the class from the lammps
module. By using the default constructor, a new *lammps* instance is created.
.. code-block:: Python
.. code-block:: python
from lammps import PyLammps
L = PyLammps()
You can also initialize PyLammps on top of this existing *lammps* object:
.. code-block:: Python
.. code-block:: python
from lammps import lammps, PyLammps
lmp = lammps()
@ -180,14 +180,14 @@ For instance, let's take the following LAMMPS command:
In the original interface this command can be executed with the following
Python code if *L* was a lammps instance:
.. code-block:: Python
.. code-block:: python
L.command("region box block 0 10 0 5 -0.5 0.5")
With the PyLammps interface, any command can be split up into arbitrary parts
separated by white-space, passed as individual arguments to a region method.
.. code-block:: Python
.. code-block:: python
L.region("box block", 0, 10, 0, 5, -0.5, 0.5)
@ -199,14 +199,14 @@ The benefit of this approach is avoiding redundant command calls and easier
parameterization. In the original interface parameterization needed to be done
manually by creating formatted strings.
.. code-block:: Python
.. code-block:: python
L.command("region box block %f %f %f %f %f %f" % (xlo, xhi, ylo, yhi, zlo, zhi))
In contrast, methods of PyLammps accept parameters directly and will convert
them automatically to a final command string.
.. code-block:: Python
.. code-block:: python
L.region("box block", xlo, xhi, ylo, yhi, zlo, zhi)
@ -256,7 +256,7 @@ LAMMPS variables can be both defined and accessed via the PyLammps interface.
To define a variable you can use the :doc:`variable <variable>` command:
.. code-block:: Python
.. code-block:: python
L.variable("a index 2")
@ -265,14 +265,14 @@ A dictionary of all variables is returned by L.variables
you can access an individual variable by retrieving a variable object from the
L.variables dictionary by name
.. code-block:: Python
.. code-block:: python
a = L.variables['a']
The variable value can then be easily read and written by accessing the value
property of this object.
.. code-block:: Python
.. code-block:: python
print(a.value)
a.value = 4
@ -284,7 +284,7 @@ LAMMPS expressions can be immediately evaluated by using the eval method. The
passed string parameter can be any expression containing global thermo values,
variables, compute or fix data.
.. code-block:: Python
.. code-block:: python
result = L.eval("ke") # kinetic energy
result = L.eval("pe") # potential energy
@ -298,7 +298,7 @@ All atoms in the current simulation can be accessed by using the L.atoms list.
Each element of this list is an object which exposes its properties (id, type,
position, velocity, force, etc.).
.. code-block:: Python
.. code-block:: python
# access first atom
L.atoms[0].id
@ -311,7 +311,7 @@ position, velocity, force, etc.).
Some properties can also be used to set:
.. code-block:: Python
.. code-block:: python
# set position in 2D simulation
L.atoms[0].position = (1.0, 0.0)
@ -328,7 +328,7 @@ after a run via the L.runs list. This list contains a growing list of run data.
The first element is the output of the first run, the second element that of
the second run.
.. code-block:: Python
.. code-block:: python
L.run(1000)
L.runs[0] # data of first 1000 time steps
@ -339,14 +339,14 @@ the second run.
Each run contains a dictionary of all trajectories. Each trajectory is
accessible through its thermo name:
.. code-block:: Python
.. code-block:: python
L.runs[0].thermo.Step # list of time steps in first run
L.runs[0].thermo.Ke # list of kinetic energy values in first run
Together with matplotlib plotting data out of LAMMPS becomes simple:
.. code-block:: Python
.. code-block:: python
import matplotlib.plot as plt
steps = L.runs[0].thermo.Step
@ -356,18 +356,16 @@ Together with matplotlib plotting data out of LAMMPS becomes simple:
Error handling with PyLammps
----------------------------
Compiling the shared library with C++ exception support provides a better error
handling experience. Without exceptions the LAMMPS code will terminate the
current Python process with an error message. C++ exceptions allow capturing
them on the C++ side and rethrowing them on the Python side. This way you
can handle LAMMPS errors through the Python exception handling mechanism.
Using C++ exceptions in LAMMPS for errors allows capturing them on the
C++ side and rethrowing them on the Python side. This way you can handle
LAMMPS errors through the Python exception handling mechanism.
.. warning::
Capturing a LAMMPS exception in Python can still mean that the
current LAMMPS process is in an illegal state and must be terminated. It is
advised to save your data and terminate the Python instance as quickly as
possible.
current LAMMPS process is in an illegal state and must be
terminated. It is advised to save your data and terminate the Python
instance as quickly as possible.
Using PyLammps in IPython notebooks and Jupyter
-----------------------------------------------
@ -392,7 +390,7 @@ IPyLammps Examples
------------------
Examples of IPython notebooks can be found in the python/examples/pylammps
sub-directory. To open these notebooks launch *jupyter notebook* inside this
subdirectory. To open these notebooks launch *jupyter notebook* inside this
directory and navigate to one of them. If you compiled and installed
a LAMMPS shared library with exceptions, PNG, JPEG and FFMPEG support
you should be able to rerun all of these notebooks.
@ -406,7 +404,7 @@ Four atoms are placed in the simulation and the dihedral potential is applied on
them using a datafile. Then one of the atoms is rotated along the central axis by
setting its position from Python, which changes the dihedral angle.
.. code-block:: Python
.. code-block:: python
phi = [d \* math.pi / 180 for d in range(360)]
@ -439,7 +437,7 @@ Initially, a 2D system is created in a state with minimal energy.
It is then disordered by moving each atom by a random delta.
.. code-block:: Python
.. code-block:: python
random.seed(27848)
deltaperturb = 0.2
@ -458,7 +456,7 @@ It is then disordered by moving each atom by a random delta.
Finally, the Monte Carlo algorithm is implemented in Python. It continuously
moves random atoms by a random delta and only accepts certain moves.
.. code-block:: Python
.. code-block:: python
estart = L.eval("pe")
elast = estart
@ -517,7 +515,7 @@ PyLammps can be run in parallel using mpi4py. This python package can be install
The following is a short example which reads in an existing LAMMPS input file and
executes it in parallel. You can find in.melt in the examples/melt folder.
.. code-block:: Python
.. code-block:: python
from mpi4py import MPI
from lammps import PyLammps

4
doc/src/Howto_replica.rst
View File

@ -47,9 +47,9 @@ script which is required when running in multi-replica mode.
Also note that with MPI installed on a machine (e.g. your desktop), you
can run on more (virtual) processors than you have physical processors.
Thus the above commands could be run on a single-processor (or
Thus, the above commands could be run on a single-processor (or
few-processor) desktop so that you can run a multi-replica simulation on
more replicas than you have physical processors. This is useful for
testing and debugging, since with most modern processors and MPI
libraries the efficiency of a calculation can severely diminish when
libraries, the efficiency of a calculation can severely diminish when
oversubscribing processors.

13
doc/src/Howto_restart.rst
View File

@ -7,8 +7,9 @@ run will continue from where the previous run left off. Or binary
restart files can be saved to disk using the :doc:`restart <restart>`
command. At a later time, these binary files can be read via a
:doc:`read_restart <read_restart>` command in a new script. Or they can
be converted to text data files using the :doc:`-r command-line switch <Run_options>` and read by a :doc:`read_data <read_data>`
command in a new script.
be converted to text data files using the :doc:`-r command-line switch
<Run_options>` and read by a :doc:`read_data <read_data>` command in a
new script.
Here we give examples of 2 scripts that read either a binary restart
file or a converted data file and then issue a new run command to
@ -47,7 +48,7 @@ last 50 timesteps:
Note that the following commands do not need to be repeated because
their settings are included in the restart file: *units, atom_style,
special_bonds, pair_style, bond_style*. However these commands do
special_bonds, pair_style, bond_style*. However, these commands do
need to be used, since their settings are not in the restart file:
*neighbor, fix, timestep*\ .
@ -90,7 +91,7 @@ Then, this script could be used to re-run the last 50 steps:
Note that nearly all the settings specified in the original *in.chain*
script must be repeated, except the *pair_coeff* and *bond_coeff*
commands since the new data file lists the force field coefficients.
commands, since the new data file lists the force field coefficients.
Also, the :doc:`reset_timestep <reset_timestep>` command is used to tell
LAMMPS the current timestep. This value is stored in restart files,
but not in data files.
LAMMPS the current timestep. This value is stored in restart files, but
not in data files.

114
doc/src/Howto_spc.rst
View File

@ -20,7 +20,6 @@ atoms and the water molecule to run a rigid SPC model.
| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
| :math:`r_0` of OH bond = 1.0
| :math:`\theta_0` of HOH angle = 109.47\ :math:`^{\circ}`
|
Note that as originally proposed, the SPC model was run with a 9
Angstrom cutoff for both LJ and Coulomb terms. It can also be used
@ -33,16 +32,121 @@ the partial charge assignments change:
| O charge = -0.8476
| H charge = 0.4238
|
See the :ref:`(Berendsen) <howto-Berendsen>` reference for more details on both
the SPC and SPC/E models.
Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
Below is the code for a LAMMPS input file and a molecule file
(``spce.mol``) of SPC/E water for use with the :doc:`molecule command
<molecule>` demonstrating how to set up a small bulk water system for
SPC/E with rigid bonds.
.. code-block:: LAMMPS
units real
atom_style full
region box block -5 5 -5 5 -5 5
create_box 2 box bond/types 1 angle/types 1 &
extra/bond/per/atom 2 extra/angle/per/atom 1 extra/special/per/atom 2
mass 1 15.9994
mass 2 1.008
pair_style lj/cut/coul/cut 10.0
pair_coeff 1 1 0.1553 3.166
pair_coeff 1 2 0.0 1.0
pair_coeff 2 2 0.0 1.0
bond_style zero
bond_coeff 1 1.0
angle_style zero
angle_coeff 1 109.47
molecule water spce.mol
create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
timestep 1.0
fix rigid all shake 0.0001 10 10000 b 1 a 1
minimize 0.0 0.0 1000 10000
velocity all create 300.0 5463576
fix integrate all nvt temp 300.0 300.0 100.0
thermo_style custom step temp press etotal density pe ke
thermo 1000
run 20000 upto
write_data spce.data nocoeff
.. _spce_molecule:
.. code-block::
# Water molecule. SPC/E geometry
3 atoms
2 bonds
1 angles
Coords
1 0.00000 -0.06461 0.00000
2 0.81649 0.51275 0.00000
3 -0.81649 0.51275 0.00000
Types
1 1 # O
2 2 # H
3 2 # H
Charges
1 -0.8476
2 0.4238
3 0.4238
Bonds
1 1 1 2
2 1 1 3
Angles
1 1 2 1 3
Shake Flags
1 1
2 1
3 1
Shake Atoms
1 1 2 3
2 1 2 3
3 1 2 3
Shake Bond Types
1 1 1 1
2 1 1 1
3 1 1 1
Special Bond Counts
1 2 0 0
2 1 1 0
3 1 1 0
Special Bonds
1 2 3
2 1 3
3 1 2
Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
----------
.. _howto-Berendsen:
**(Berendsen)** Berendsen, Grigera, Straatsma, J Phys Chem, 91,
6269-6271 (1987).
**(Berendsen)** Berendsen, Grigera, Straatsma, J Phys Chem, 91, 6269-6271 (1987).

2
doc/src/Howto_spherical.rst
View File

@ -93,7 +93,7 @@ Some of the pair styles used to compute pairwise interactions between
finite-size particles also compute the correct interaction with point
particles as well, e.g. the interaction between a point particle and a
finite-size particle or between two point particles. If necessary,
:doc:`pair_style hybrid <pair_hybrid>` can be used to insure the correct
:doc:`pair_style hybrid <pair_hybrid>` can be used to ensure the correct
interactions are computed for the appropriate style of interactions.
Likewise, using groups to partition particles (ellipsoids versus
spheres versus point particles) will allow you to use the appropriate

16
doc/src/Howto_spins.rst
View File

@ -30,9 +30,11 @@ can be coupled to another Langevin thermostat applied to the atoms
using :doc:`fix langevin <fix_langevin>` in order to simulate
thermostatted spin-lattice systems.
The magnetic Gilbert damping can also be applied using :doc:`fix langevin/spin <fix_langevin_spin>`. It allows to either dissipate
the thermal energy of the Langevin thermostat, or to perform a
relaxation of the magnetic configuration toward an equilibrium state.
The magnetic damping can also be applied
using :doc:`fix langevin/spin <fix_langevin_spin>`.
It allows to either dissipate the thermal energy of the Langevin
thermostat, or to perform a relaxation of the magnetic configuration
toward an equilibrium state.
The command :doc:`fix setforce/spin <fix_setforce>` allows to set the
components of the magnetic precession vectors (while erasing and
@ -52,9 +54,11 @@ All the computed magnetic properties can be output by two main
commands. The first one is :doc:`compute spin <compute_spin>`, that
enables to evaluate magnetic averaged quantities, such as the total
magnetization of the system along x, y, or z, the spin temperature, or
the magnetic energy. The second command is :doc:`compute property/atom <compute_property_atom>`. It enables to output all the
per atom magnetic quantities. Typically, the orientation of a given
magnetic spin, or the magnetic force acting on this spin.
the magnetic energy. The second command
is :doc:`compute property/atom <compute_property_atom>`.
It enables to output all the per atom magnetic quantities. Typically,
the orientation of a given magnetic spin, or the magnetic force
acting on this spin.
----------

41
doc/src/Howto_structured_data.rst
View File

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

246
doc/src/Howto_tip3p.rst
View File

@ -1,55 +1,213 @@
TIP3P water model
=================
The TIP3P water model as implemented in CHARMM
:ref:`(MacKerell) <howto-tip3p>` specifies a 3-site rigid water molecule with
charges and Lennard-Jones parameters assigned to each of the 3 atoms.
In LAMMPS the :doc:`fix shake <fix_shake>` command can be used to hold
the two O-H bonds and the H-O-H angle rigid. A bond style of
*harmonic* and an angle style of *harmonic* or *charmm* should also be
used.
The TIP3P water model as implemented in CHARMM :ref:`(MacKerell)
<howto-tip3p>` specifies a 3-site rigid water molecule with charges and
Lennard-Jones parameters assigned to each of the 3 atoms.
These are the additional parameters (in real units) to set for O and H
atoms and the water molecule to run a rigid TIP3P-CHARMM model with a
cutoff. The K values can be used if a flexible TIP3P model (without
fix shake) is desired. If the LJ epsilon and sigma for HH and OH are
set to 0.0, it corresponds to the original 1983 TIP3P model
:ref:`(Jorgensen) <Jorgensen1>`.
A suitable pair style with cutoff Coulomb would be:
| O mass = 15.9994
| H mass = 1.008
| O charge = -0.834
| H charge = 0.417
| LJ :math:`\epsilon` of OO = 0.1521
| LJ :math:`\sigma` of OO = 3.1507
| LJ :math:`\epsilon` of HH = 0.0460
| LJ :math:`\sigma` of HH = 0.4000
| LJ :math:`\epsilon` of OH = 0.0836
| LJ :math:`\sigma` of OH = 1.7753
| K of OH bond = 450
| :math:`r_0` of OH bond = 0.9572
| K of HOH angle = 55
| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
|
* :doc:`pair_style lj/cut/coul/cut <pair_lj_cut_coul>`
These are the parameters to use for TIP3P with a long-range Coulomb
solver (e.g. Ewald or PPPM in LAMMPS), see :ref:`(Price) <Price1>` for
details:
or these commands for a long-range Coulomb model:
| O mass = 15.9994
| H mass = 1.008
| O charge = -0.830
| H charge = 0.415
| LJ :math:`\epsilon` of OO = 0.102
| LJ :math:`\sigma` of OO = 3.188
| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
| K of OH bond = 450
| :math:`r_0` of OH bond = 0.9572
| K of HOH angle = 55
| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
|
* :doc:`pair_style lj/cut/coul/long <pair_lj_cut_coul>`
* :doc:`pair_style lj/cut/coul/long/soft <pair_fep_soft>`
* :doc:`kspace_style pppm <kspace_style>`
* :doc:`kspace_style pppm/disp <kspace_style>`
Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
In LAMMPS the :doc:`fix shake or fix rattle <fix_shake>` command can be
used to hold the two O-H bonds and the H-O-H angle rigid. A bond style
of :doc:`harmonic <bond_harmonic>` and an angle style of :doc:`harmonic
<angle_harmonic>` or :doc:`charmm <angle_charmm>` should also be used.
In case of rigid bonds also bond style :doc:`zero <bond_zero>` and angle
style :doc:`zero <angle_zero>` can be used.
The table below lists the force field parameters (in real :doc:`units
<units>`) to for the water molecule atoms to run a rigid or flexible
TIP3P-CHARMM model with a cutoff, the original 1983 TIP3P model
:ref:`(Jorgensen) <Jorgensen1>`, or a TIP3P model with parameters
optimized for a long-range Coulomb solver (e.g. Ewald or PPPM in LAMMPS)
:ref:`(Price) <Price1>`. The K values can be used if a flexible TIP3P
model (without fix shake) is desired, for rigid bonds/angles they are
ignored.
.. list-table::
:header-rows: 1
:widths: auto
* - Parameter
- TIP3P-CHARMM
- TIP3P (original)
- TIP3P (Ewald)
* - O mass (amu)
- 15.9994
- 15.9994
- 15.9994
* - H mass (amu)
- 1.008
- 1.008
- 1.008
* - O charge (:math:`e`)
- -0.834
- -0.834
- -0.834
* - H charge (:math:`e`)
- 0.417
- 0.417
- 0.417
* - LJ :math:`\epsilon` of OO (kcal/mole)
- 0.1521
- 0.1521
- 0.1020
* - LJ :math:`\sigma` of OO (:math:`\AA`)
- 3.1507
- 3.1507
- 3.188
* - LJ :math:`\epsilon` of HH (kcal/mole)
- 0.0460
- 0.0
- 0.0
* - LJ :math:`\sigma` of HH (:math:`\AA`)
- 0.4
- 1.0
- 1.0
* - LJ :math:`\epsilon` of OH (kcal/mole)
- 0.0836
- 0.0
- 0.0
* - LJ :math:`\sigma` of OH (:math:`\AA`)
- 1.7753
- 1.0
- 1.0
* - K of OH bond (kcal/mole/:math:`\AA^2`)
- 450
- 450
- 450
* - :math:`r_0` of OH bond (:math:`\AA`)
- 0.9572
- 0.9572
- 0.9572
* - K of HOH angle (kcal/mole)
- 55.0
- 55.0
- 55.0
* - :math:`\theta_0` of HOH angle
- 104.52\ :math:`^{\circ}`
- 104.52\ :math:`^{\circ}`
- 104.52\ :math:`^{\circ}`
Below is the code for a LAMMPS input file and a molecule file
(``tip3p.mol``) of TIP3P water for use with the :doc:`molecule command
<molecule>` demonstrating how to set up a small bulk water system for
TIP3P with rigid bonds.
.. code-block:: LAMMPS
units real
atom_style full
region box block -5 5 -5 5 -5 5
create_box 2 box bond/types 1 angle/types 1 &
extra/bond/per/atom 2 extra/angle/per/atom 1 extra/special/per/atom 2
mass 1 15.9994
mass 2 1.008
pair_style lj/cut/coul/cut 8.0
pair_coeff 1 1 0.1521 3.1507
pair_coeff 2 2 0.0 1.0
bond_style zero
bond_coeff 1 0.9574
angle_style zero
angle_coeff 1 104.52
molecule water tip3p.mol
create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
fix rigid all shake 0.001 10 10000 b 1 a 1
minimize 0.0 0.0 1000 10000
reset_timestep 0
timestep 1.0
velocity all create 300.0 5463576
fix integrate all nvt temp 300 300 100.0
thermo_style custom step temp press etotal pe
thermo 1000
run 20000
write_data tip3p.data nocoeff
.. _tip3p_molecule:
.. code-block::
# Water molecule. TIP3P geometry
3 atoms
2 bonds
1 angles
Coords
1 0.00000 -0.06556 0.00000
2 0.75695 0.52032 0.00000
3 -0.75695 0.52032 0.00000
Types
1 1 # O
2 2 # H
3 2 # H
Charges
1 -0.834
2 0.417
3 0.417
Bonds
1 1 1 2
2 1 1 3
Angles
1 1 2 1 3
Shake Flags
1 1
2 1
3 1
Shake Atoms
1 1 2 3
2 1 2 3
3 1 2 3
Shake Bond Types
1 1 1 1
2 1 1 1
3 1 1 1
Special Bond Counts
1 2 0 0
2 1 1 0
3 1 1 0
Special Bonds
1 2 3
2 1 3
3 1 2
Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
----------

336
doc/src/Howto_tip4p.rst
View File

@ -2,102 +2,266 @@ TIP4P water model
=================
The four-point TIP4P rigid water model extends the traditional
three-point TIP3P model by adding an additional site, usually
massless, where the charge associated with the oxygen atom is placed.
This site M is located at a fixed distance away from the oxygen along
the bisector of the HOH bond angle. A bond style of *harmonic* and an
angle style of *harmonic* or *charmm* should also be used.
:doc:`three-point TIP3P <Howto_tip3p>` model by adding an additional
site M, usually massless, where the charge associated with the oxygen
atom is placed. This site M is located at a fixed distance away from
the oxygen along the bisector of the HOH bond angle. A bond style of
:doc:`harmonic <bond_harmonic>` and an angle style of :doc:`harmonic
<angle_harmonic>` or :doc:`charmm <angle_charmm>` should also be used.
In case of rigid bonds also bond style :doc:`zero <bond_zero>` and angle
style :doc:`zero <angle_zero>` can be used.
A TIP4P model is run with LAMMPS using either this command
for a cutoff model:
There are two ways to implement TIP4P water in LAMMPS:
* :doc:`pair_style lj/cut/tip4p/cut <pair_lj_cut_tip4p>`
#. Use a specially written pair style that uses the :ref:`TIP3P geometry
<tip3p_molecule>` without the point M. The point M location is then
implicitly derived from the other atoms or each water molecule and
used during the force computation. The forces on M are then
projected on the oxygen and the two hydrogen atoms. This is
computationally very efficient, but the charge distribution in space
is only correct within the tip4p labeled styles. So all other
computations using charges will "see" the negative charge incorrectly
on the oxygen atom.
or these two commands for a long-range model:
This can be done with the following pair styles for Coulomb with a cutoff:
* :doc:`pair_style lj/cut/tip4p/long <pair_lj_cut_tip4p>`
* :doc:`kspace_style pppm/tip4p <kspace_style>`
* :doc:`pair_style tip4p/cut <pair_lj_cut_tip4p>`
* :doc:`pair_style lj/cut/tip4p/cut <pair_lj_cut_tip4p>`
For both models, the bond lengths and bond angles should be held fixed
using the :doc:`fix shake <fix_shake>` command.
or these commands for a long-range Coulomb treatment:
These are the additional parameters (in real units) to set for O and H
atoms and the water molecule to run a rigid TIP4P model with a cutoff
:ref:`(Jorgensen) <Jorgensen5>`. Note that the OM distance is specified in
the :doc:`pair_style <pair_style>` command, not as part of the pair
coefficients.
* :doc:`pair_style tip4p/long <pair_coul>`
* :doc:`pair_style lj/cut/tip4p/long <pair_lj_cut_tip4p>`
* :doc:`pair_style lj/long/tip4p/long <pair_lj_long>`
* :doc:`pair_style tip4p/long/soft <pair_fep_soft>`
* :doc:`pair_style lj/cut/tip4p/long/soft <pair_fep_soft>`
* :doc:`kspace_style pppm/tip4p <kspace_style>`
* :doc:`kspace_style pppm/disp/tip4p <kspace_style>`
| O mass = 15.9994
| H mass = 1.008
| O charge = -1.040
| H charge = 0.520
| :math:`r_0` of OH bond = 0.9572
| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
| OM distance = 0.15
| LJ :math:`\epsilon` of O-O = 0.1550
| LJ :math:`\sigma` of O-O = 3.1536
| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
| Coulomb cutoff = 8.5
|
The bond lengths and bond angles should be held fixed using the
:doc:`fix shake <fix_shake>` or :doc:`fix rattle <fix_shake>` command,
unless a parameterization for a flexible TIP4P model is used. The
parameter sets listed below are all for rigid TIP4P model variants and
thus the bond and angle force constants are not used and can be set to
any legal value; only equilibrium length and angle are used.
For the TIP4/Ice model (J Chem Phys, 122, 234511 (2005);
https://doi.org/10.1063/1.1931662) these values can be used:
#. Use an :ref:`explicit 4 point TIP4P geometry <tip4p_molecule>` where
the oxygen atom carries no charge and the M point no Lennard-Jones
interactions. Since :doc:`fix shake <fix_shake>` or :doc:`fix rattle
<fix_shake>` may not be applied to this kind of geometry, :doc:`fix
rigid or fix rigid/small <fix_rigid>` or its thermostatted variants
are required to maintain a rigid geometry. This avoids some of the
issues with respect to analysis and non-tip4p styles, but it is a
more costly force computation (more atoms in the same volume and thus
more neighbors in the neighbor lists) and requires a much shorter
timestep for stable integration of the rigid body motion. Since no
bonds or angles are required, they do not need to be defined and atom
style charge would be sufficient for a bulk TIP4P water system. In
order to avoid that LAMMPS produces an error due to the massless M
site a tiny non-zero mass needs to be assigned.
| O mass = 15.9994
| H mass = 1.008
| O charge = -1.1794
| H charge = 0.5897
| :math:`r_0` of OH bond = 0.9572
| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
| OM distance = 0.1577
| LJ :math:`\epsilon` of O-O = 0.21084
| LJ :math:`\sigma` of O-O = 3.1668
| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
| Coulomb cutoff = 8.5
|
The table below lists the force field parameters (in real :doc:`units
<units>`) to for a selection of popular variants of the TIP4P model.
There is the rigid TIP4P model with a cutoff :ref:`(Jorgensen)
<Jorgensen5>`, the TIP4/Ice model :ref:`(Abascal1) <Abascal1>`, the
TIP4P/2005 model :ref:`(Abascal2) <Abascal2>` and a version of TIP4P
parameters adjusted for use with a long-range Coulombic solver
(e.g. Ewald or PPPM in LAMMPS). Note that for implicit TIP4P models the
OM distance is specified in the :doc:`pair_style <pair_style>` command,
not as part of the pair coefficients.
For the TIP4P/2005 model (J Chem Phys, 123, 234505 (2005);
https://doi.org/10.1063/1.2121687), these values can be used:
.. list-table::
:header-rows: 1
:widths: auto
| O mass = 15.9994
| H mass = 1.008
| O charge = -1.1128
| H charge = 0.5564
| :math:`r_0` of OH bond = 0.9572
| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
| OM distance = 0.1546
| LJ :math:`\epsilon` of O-O = 0.1852
| LJ :math:`\sigma` of O-O = 3.1589
| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
| Coulomb cutoff = 8.5
|
* - Parameter
- TIP4P (original)
- TIP4P/Ice
- TIP4P/2005
- TIP4P (Ewald)
* - O mass (amu)
- 15.9994
- 15.9994
- 15.9994
- 15.9994
* - H mass (amu)
- 1.008
- 1.008
- 1.008
- 1.008
* - O or M charge (:math:`e`)
- -1.040
- -1.1794
- -1.1128
- -1.04844
* - H charge (:math:`e`)
- 0.520
- 0.5897
- 0.5564
- 0.52422
* - LJ :math:`\epsilon` of OO (kcal/mole)
- 0.1550
- 0.21084
- 0.1852
- 0.16275
* - LJ :math:`\sigma` of OO (:math:`\AA`)
- 3.1536
- 3.1668
- 3.1589
- 3.16435
* - LJ :math:`\epsilon` of HH, MM, OH, OM, HM (kcal/mole)
- 0.0
- 0.0
- 0.0
- 0.0
* - LJ :math:`\sigma` of HH, MM, OH, OM, HM (:math:`\AA`)
- 1.0
- 1.0
- 1.0
- 1.0
* - :math:`r_0` of OH bond (:math:`\AA`)
- 0.9572
- 0.9572
- 0.9572
- 0.9572
* - :math:`\theta_0` of HOH angle
- 104.52\ :math:`^{\circ}`
- 104.52\ :math:`^{\circ}`
- 104.52\ :math:`^{\circ}`
- 104.52\ :math:`^{\circ}`
* - OM distance (:math:`\AA`)
- 0.15
- 0.1577
- 0.1546
- 0.1250
These are the parameters to use for TIP4P with a long-range Coulombic
solver (e.g. Ewald or PPPM in LAMMPS):
Note that the when using the TIP4P pair style, the neighbor list cutoff
for Coulomb interactions is effectively extended by a distance 2 \* (OM
distance), to account for the offset distance of the fictitious charges
on O atoms in water molecules. Thus it is typically best in an
efficiency sense to use a LJ cutoff >= Coulomb cutoff + 2\*(OM
distance), to shrink the size of the neighbor list. This leads to
slightly larger cost for the long-range calculation, so you can test the
trade-off for your model. The OM distance and the LJ and Coulombic
cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long
<pair_lj_cut_tip4p>` command.
| O mass = 15.9994
| H mass = 1.008
| O charge = -1.0484
| H charge = 0.5242
| :math:`r_0` of OH bond = 0.9572
| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
| OM distance = 0.1250
| LJ :math:`\epsilon` of O-O = 0.16275
| LJ :math:`\sigma` of O-O = 3.16435
| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
|
Below is the code for a LAMMPS input file using the implicit method and
the :ref:`TIP3P molecule file <tip3p_molecule>`. Because the TIP4P
charges are different from TIP3P they need to be reset (or the molecule
file changed):
Note that the when using the TIP4P pair style, the neighbor list
cutoff for Coulomb interactions is effectively extended by a distance
2 \* (OM distance), to account for the offset distance of the
fictitious charges on O atoms in water molecules. Thus it is
typically best in an efficiency sense to use a LJ cutoff >= Coulomb
cutoff + 2\*(OM distance), to shrink the size of the neighbor list.
This leads to slightly larger cost for the long-range calculation, so
you can test the trade-off for your model. The OM distance and the LJ
and Coulombic cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long <pair_lj_cut_tip4p>` command.
.. code-block:: LAMMPS
Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
units real
atom_style full
region box block -5 5 -5 5 -5 5
create_box 2 box bond/types 1 angle/types 1 &
extra/bond/per/atom 2 extra/angle/per/atom 1 extra/special/per/atom 2
mass 1 15.9994
mass 2 1.008
pair_style lj/cut/tip4p/cut 1 2 1 1 0.15 8.0
pair_coeff 1 1 0.1550 3.1536
pair_coeff 2 2 0.0 1.0
bond_style zero
bond_coeff 1 0.9574
angle_style zero
angle_coeff 1 104.52
molecule water tip3p.mol # this uses the TIP3P geometry
create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
# must change charges for TIP4P
set type 1 charge -1.040
set type 2 charge 0.520
fix rigid all shake 0.001 10 10000 b 1 a 1
minimize 0.0 0.0 1000 10000
reset_timestep 0
timestep 1.0
velocity all create 300.0 5463576
fix integrate all nvt temp 300 300 100.0
thermo_style custom step temp press etotal pe
thermo 1000
run 20000
write_data tip4p-implicit.data nocoeff
Below is the code for a LAMMPS input file using the explicit method and
a TIP4P molecule file. Because of using :doc:`fix rigid/small
<fix_rigid>` no bonds need to be defined and thus no extra storage needs
to be reserved for them, but we need to either switch to atom style full
or use :doc:`fix property/atom mol <fix_property_atom>` so that fix
rigid/small can identify rigid bodies by their molecule ID. Also a
:doc:`neigh_modify exclude <neigh_modify>` command is added to exclude
computing intramolecular non-bonded interactions, since those are
removed by the rigid fix anyway:
.. code-block:: LAMMPS
units real
atom_style charge
atom_modify map array
region box block -5 5 -5 5 -5 5
create_box 3 box
mass 1 15.9994
mass 2 1.008
mass 3 1.0e-100
pair_style lj/cut/coul/cut 8.0
pair_coeff 1 1 0.1550 3.1536
pair_coeff 2 2 0.0 1.0
pair_coeff 3 3 0.0 1.0
fix mol all property/atom mol ghost yes
molecule water tip4p.mol
create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
neigh_modify exclude molecule/intra all
timestep 0.5
fix integrate all rigid/small molecule langevin 300.0 300.0 100.0 2345634
thermo_style custom step temp press etotal density pe ke
thermo 2000
run 40000
write_data tip4p-explicit.data nocoeff
.. _tip4p_molecule:
.. code-block::
# Water molecule. Explicit TIP4P geometry for use with fix rigid
4 atoms
Coords
1 0.00000 -0.06556 0.00000
2 0.75695 0.52032 0.00000
3 -0.75695 0.52032 0.00000
4 0.00000 0.08444 0.00000
Types
1 1 # O
2 2 # H
3 2 # H
4 3 # M
Charges
1 0.000
2 0.520
3 0.520
4 -1.040
Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
----------
@ -105,3 +269,13 @@ Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki
**(Jorgensen)** Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
Phys, 79, 926 (1983).
.. _Abascal1:
**(Abascal1)** Abascal, Sanz, Fernandez, Vega, J Chem Phys, 122, 234511 (2005)
https://doi.org/10.1063/1.1931662
.. _Abascal2:
**(Abascal2)** Abascal, J Chem Phys, 123, 234505 (2005)
https://doi.org/10.1063/1.2121687

164
doc/src/Howto_tip5p.rst Normal file
View File

@ -0,0 +1,164 @@
TIP5P water model
=================
The five-point TIP5P rigid water model extends the :doc:`three-point
TIP3P model <Howto_tip3p>` by adding two additional sites L, usually
massless, where the charge associated with the oxygen atom is placed.
These sites L are located at a fixed distance away from the oxygen atom,
forming a tetrahedral angle that is rotated by 90 degrees from the HOH
plane. Those sites thus somewhat approximate lone pairs of the oxygen
and consequently improve the water structure to become even more
"tetrahedral" in comparison to the :doc:`four-point TIP4P model
<Howto_tip4p>`.
A suitable pair style with cutoff Coulomb would be:
* :doc:`pair_style lj/cut/coul/cut <pair_lj_cut_coul>`
or these commands for a long-range model:
* :doc:`pair_style lj/cut/coul/long <pair_lj_cut_coul>`
* :doc:`pair_style lj/cut/coul/long/soft <pair_fep_soft>`
* :doc:`kspace_style pppm <kspace_style>`
* :doc:`kspace_style pppm/disp <kspace_style>`
A TIP5P model *must* be run using a :doc:`rigid fix <fix_rigid>` since
there is no other option to keep this kind of structure rigid in LAMMPS.
In order to avoid that LAMMPS produces an error due to the massless L
sites, those need to be assigned a tiny non-zero mass.
The table below lists the force field parameters (in real :doc:`units
<units>`) to for a the TIP5P model with a cutoff :ref:`(Mahoney)
<Mahoney>` and the TIP5P-E model :ref:`(Rick) <Rick>` for use with a
long-range Coulombic solver (e.g. Ewald or PPPM in LAMMPS).
.. list-table::
:header-rows: 1
:widths: auto
* - Parameter
- TIP5P
- TIP5P-E
* - O mass (amu)
- 15.9994
- 15.9994
* - H mass (amu)
- 1.008
- 1.008
* - O charge (:math:`e`)
- 0.0
- 0.0
* - L charge (:math:`e`)
- -0.241
- -0.241
* - H charge (:math:`e`)
- 0.241
- 0.241
* - LJ :math:`\epsilon` of OO (kcal/mole)
- 0.1600
- 0.1780
* - LJ :math:`\sigma` of OO (:math:`\AA`)
- 3.1200
- 3.0970
* - LJ :math:`\epsilon` of HH, LL, OH, OL, HL (kcal/mole)
- 0.0
- 0.0
* - LJ :math:`\sigma` of HH, LL, OH, OL, HL (:math:`\AA`)
- 1.0
- 1.0
* - :math:`r_0` of OH bond (:math:`\AA`)
- 0.9572
- 0.9572
* - :math:`\theta_0` of HOH angle
- 104.52\ :math:`^{\circ}`
- 104.52\ :math:`^{\circ}`
* - OL distance (:math:`\AA`)
- 0.70
- 0.70
* - :math:`\theta_0` of LOL angle
- 109.47\ :math:`^{\circ}`
- 109.47\ :math:`^{\circ}`
Below is the code for a LAMMPS input file for setting up a simulation of
TIP5P water with a molecule file. Because of using :doc:`fix
rigid/small <fix_rigid>` no bonds need to be defined and thus no extra
storage needs to be reserved for them, but we need to either switch to
atom style full or use :doc:`fix property/atom mol <fix_property_atom>`
so that fix rigid/small can identify rigid bodies by their molecule ID.
Also a :doc:`neigh_modify exclude <neigh_modify>` command is added to
exclude computing intramolecular non-bonded interactions, since those
are removed by the rigid fix anyway:
.. code-block:: LAMMPS
units real
atom_style charge
atom_modify map array
region box block -5 5 -5 5 -5 5
create_box 3 box
mass 1 15.9994
mass 2 1.008
mass 3 1.0e-100
pair_style lj/cut/coul/cut 8.0
pair_coeff 1 1 0.160 3.12
pair_coeff 2 2 0.0 1.0
pair_coeff 3 3 0.0 1.0
fix mol all property/atom mol
molecule water tip5p.mol
create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
neigh_modify exclude molecule/intra all
timestep 0.5
fix integrate all rigid/small molecule langevin 300.0 300.0 50.0 235664
reset_timestep 0
thermo_style custom step temp press etotal density pe ke
thermo 1000
run 20000
write_data tip5p.data nocoeff
.. _tip5p_molecule:
.. code-block::
# Water molecule. Explicit TIP5P geometry for use with fix rigid
5 atoms
Coords
1 0.00000 -0.06556 0.00000
2 0.75695 0.52032 0.00000
3 -0.75695 0.52032 0.00000
4 0.00000 -0.46971 0.57154
5 0.00000 -0.46971 -0.57154
Types
1 1 # O
2 2 # H
3 2 # H
4 3 # L
5 3 # L
Charges
1 0.000
2 0.241
3 0.241
4 -0.241
5 -0.241
Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
----------
.. _Mahoney:
**(Mahoney)** Mahoney, Jorgensen, J Chem Phys 112, 8910 (2000)
.. _Rick:
**(Rick)** Rick, J Chem Phys 120, 6085 (2004)

10
doc/src/Howto_triclinic.rst
View File

@ -12,7 +12,8 @@ is created, e.g. by the :doc:`create_box <create_box>` or
:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
commands. Additionally, LAMMPS defines box size parameters lx,ly,lz
where lx = xhi-xlo, and similarly in the y and z dimensions. The 6
parameters, as well as lx,ly,lz, can be output via the :doc:`thermo_style custom <thermo_style>` command.
parameters, as well as lx,ly,lz, can be output via the
:doc:`thermo_style custom <thermo_style>` command.
LAMMPS also allows simulations to be performed in triclinic
(non-orthogonal) simulation boxes shaped as a parallelepiped with
@ -144,18 +145,13 @@ does not change the atom positions due to non-periodicity. In this
mode, if you tilt the system to extreme angles, the simulation will
simply become inefficient, due to the highly skewed simulation box.
The limitation on not creating a simulation box with a tilt factor
skewing the box more than half the distance of the parallel box length
can be overridden via the :doc:`box <box>` command. Setting the *tilt*
keyword to *large* allows any tilt factors to be specified.
Box flips that may occur using the :doc:`fix deform <fix_deform>` or
:doc:`fix npt <fix_nh>` commands can be turned off using the *flip no*
option with either of the commands.
Note that if a simulation box has a large tilt factor, LAMMPS will run
less efficiently, due to the large volume of communication needed to
acquire ghost atoms around a processor's irregular-shaped sub-domain.
acquire ghost atoms around a processor's irregular-shaped subdomain.
For extreme values of tilt, LAMMPS may also lose atoms and generate an
error.

41
doc/src/Howto_viz.rst
View File

@ -1,32 +1,21 @@
Visualize LAMMPS snapshots
==========================
LAMMPS itself does not do visualization, but snapshots from LAMMPS
simulations can be visualized (and analyzed) in a variety of ways.
Snapshots from LAMMPS simulations can be viewed, visualized, and
analyzed in a variety of ways.
Mention dump image and dump movie.
LAMMPS snapshots are created by the :doc:`dump <dump>` command, which
can create files in several formats. The native LAMMPS dump format is a
text file (see "dump atom" or "dump custom") which can be visualized by
`several visualization tools <https://www.lammps.org/viz.html>`_ for MD
simulation trajectories. `OVITO <https://www.ovito.org>`_ and `VMD
<https://www.ks.uiuc.edu/Research/vmd>`_ seem to be the most popular
choices among them.
LAMMPS snapshots are created by the :doc:`dump <dump>` command which can
create files in several formats. The native LAMMPS dump format is a
text file (see "dump atom" or "dump custom") which can be visualized
by several popular visualization tools. The :doc:`dump image <dump_image>` and :doc:`dump movie <dump_image>` styles can
output internally rendered images and convert a sequence of them to a
movie during the MD run. Several programs included with LAMMPS as
auxiliary tools can convert between LAMMPS format files and other
formats. See the :doc:`Tools <Tools>` page for details.
The :doc:`dump image <dump_image>` and :doc:`dump movie <dump_image>`
styles can output internally rendered images or convert them to a movie
during the MD run.
A Python-based toolkit distributed by our group can read native LAMMPS
dump files, including custom dump files with additional columns of
user-specified atom information, and convert them to various formats
or pipe them into visualization software directly. See the `Pizza.py WWW site <pizza_>`_ for details. Specifically, Pizza.py can convert
LAMMPS dump files into PDB, XYZ, `EnSight <ensight_>`_, and VTK formats.
Pizza.py can pipe LAMMPS dump files directly into the Raster3d and
RasMol visualization programs. Pizza.py has tools that do interactive
3d OpenGL visualization and one that creates SVG images of dump file
snapshots.
.. _pizza: https://lammps.github.io/pizza
.. _ensight: https://www.ansys.com/products/fluids/ansys-ensight
.. _atomeye: http://li.mit.edu/Archive/Graphics/A/
Programs included with LAMMPS as auxiliary tools can convert
between LAMMPS format files and other formats. See the :doc:`Tools
<Tools>` page for details. These are rarely needed these days.

14
doc/src/Howto_wsl.rst
View File

@ -11,12 +11,14 @@ LAMMPS in workshop settings, we had to redirect Windows users to
Linux Virtual Machines such as VirtualBox or Unix-like compilation with
Cygwin.
With the latest updates in Windows 10 (Version 2004, Build 19041 or higher),
Microsoft has added a new way to work on Linux-based code. The Windows
Subsystem for Linux (WSL). With WSL Version 2, you now get a Linux Virtual
Machine that transparently integrates into Windows. All you need is to ensure
you have the latest Windows updates installed and enable this new feature.
Linux VMs are then easily installed using the Microsoft Store.
With the latest updates in Windows 10 (Version 2004, Build 19041 or
higher), Microsoft has added a new way to work on Linux-based code. The
`Windows Subsystem for Linux (WSL)
<https://learn.microsoft.com/en-us/windows/wsl/>`_. With WSL Version 2,
you now get a Linux Virtual Machine that transparently integrates into
Windows. All you need is to ensure you have the latest Windows updates
installed and enable this new feature. Linux VMs are then easily
installed using the Microsoft Store.
In this tutorial, I'll show you how to set up and compile LAMMPS for both serial
and MPI usage in WSL2.

70
doc/src/Install.rst
View File

@ -18,6 +18,8 @@ you **must** build LAMMPS from the source code.
developers have no control over their choices of how they configure
and build their packages and when they update them.
----
.. toctree::
:maxdepth: 1
@ -29,38 +31,40 @@ you **must** build LAMMPS from the source code.
Install_tarball
Install_git
These are the files and sub-directories in the LAMMPS distribution:
----
+------------+-------------------------------------------+
| README | Short description of the LAMMPS package |
+------------+-------------------------------------------+
| LICENSE | GNU General Public License (GPL) |
+------------+-------------------------------------------+
| SECURITY.md| Security Policy for the LAMMPS package |
+------------+-------------------------------------------+
| bench | benchmark problems |
+------------+-------------------------------------------+
| cmake | CMake build files |
+------------+-------------------------------------------+
| doc | documentation |
+------------+-------------------------------------------+
| examples | simple test problems |
+------------+-------------------------------------------+
| fortran | Fortran wrapper for LAMMPS |
+------------+-------------------------------------------+
| lib | additional provided or external libraries |
+------------+-------------------------------------------+
| potentials | interatomic potential files |
+------------+-------------------------------------------+
| python | Python wrappers for LAMMPS |
+------------+-------------------------------------------+
| src | source files |
+------------+-------------------------------------------+
| tools | pre- and post-processing tools |
+------------+-------------------------------------------+
| unittest | sources and inputs for testing LAMMPS |
+------------+-------------------------------------------+
These are the files and subdirectories in the LAMMPS distribution:
You will have all of these if you download source. You will only have
some of them if you download executables, as explained on the pages
listed above.
+------------+---------------------------------------------+
| README | Short description of the LAMMPS package |
+------------+---------------------------------------------+
| LICENSE | GNU General Public License (GPL) |
+------------+---------------------------------------------+
| SECURITY.md| Security policy for the LAMMPS package |
+------------+---------------------------------------------+
| bench | benchmark inputs |
+------------+---------------------------------------------+
| cmake | CMake build files |
+------------+---------------------------------------------+
| doc | documentation and tools to build the manual |
+------------+---------------------------------------------+
| examples | example input files |
+------------+---------------------------------------------+
| fortran | Fortran module for LAMMPS library interface |
+------------+---------------------------------------------+
| lib | additional provided or external libraries |
+------------+---------------------------------------------+
| potentials | selected interatomic potential files |
+------------+---------------------------------------------+
| python | Python module for LAMMPS library interface |
+------------+---------------------------------------------+
| src | LAMMPS source files |
+------------+---------------------------------------------+
| tools | pre- and post-processing tools |
+------------+---------------------------------------------+
| unittest | source code and inputs for testing LAMMPS |
+------------+---------------------------------------------+
You will have all of these if you downloaded the LAMMPS source code.
You will have only some of them if you downloaded executables, as
explained on the pages listed above.

41
doc/src/Install_conda.rst
View File

@ -1,38 +1,39 @@
Download an executable for Linux or Mac via Conda
-------------------------------------------------
Download an executable for Linux or macOS via Conda
---------------------------------------------------
Binaries are available for MacOS or Linux via `Conda <conda_>`_.
Pre-compiled LAMMPS binaries are available for macOS and Linux via the
`Conda <conda_>`_ package management system.
First, one must setup the Conda package manager on your system. Follow the
instructions to install `Miniconda <mini_conda_install_>`_, then create a conda
environment (named `my-lammps-env` or whatever you prefer) for your lammps
install:
First, one must set up the Conda package manager on your system. Follow
the instructions to install `Miniconda <mini_conda_install_>`_, then
create a conda environment (named `my-lammps-env` or whatever you
prefer) for your LAMMPS install:
.. code-block:: bash
% conda config --add channels conda-forge
% conda create -n my-lammps-env
conda config --add channels conda-forge
conda create -n my-lammps-env
Then, you can install lammps on your system with the following command:
Then, you can install LAMMPS on your system with the following command:
.. code-block:: bash
% conda activate my-lammps-env
% conda install lammps
conda activate my-lammps-env
conda install lammps
The LAMMPS binary is built with the :ref:`KIM package <kim>` which
The LAMMPS binary is built with the :ref:`KIM package <kim>`, which
results in Conda 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
installed. In order to use potentials from `openkim.org <openkim_>`_,
you can install the `openkim-models` package
.. code-block:: bash
% conda install openkim-models
conda install openkim-models
If you have problems with the installation you can post issues to
`this link <conda_forge_lammps_>`_.
Thanks to Jan Janssen (Max-Planck-Institut fuer Eisenforschung) for setting
up the Conda capability.
If you have problems with the installation, you can post issues to `this
link <conda_forge_lammps_>`_. Thanks to Jan Janssen
(Max-Planck-Institut fuer Eisenforschung) for setting up the Conda
capability.
.. _conda_forge_lammps: https://github.com/conda-forge/lammps-feedstock/issues
.. _openkim: https://openkim.org

92
doc/src/Install_git.rst
View File

@ -1,16 +1,16 @@
Download the LAMMPS source with git
-----------------------------------
All LAMMPS development is coordinated through the "LAMMPS GitHub
site". If you clone the LAMMPS repository onto your local machine, it
has several advantages:
LAMMPS development is coordinated through the "LAMMPS GitHub site".
If you clone the LAMMPS repository onto your local machine, it has
several advantages:
* You can stay current with changes to LAMMPS with a single git
command.
* You can create your own development branches to add code to LAMMPS.
* You can submit your new features back to GitHub for inclusion in
LAMMPS. For that you should first create your own :doc:`fork on
GitHub <Howto_github>`.
LAMMPS. For that, you should first create your own :doc:`fork on
GitHub <Howto_github>`, though.
You must have `git <git_>`_ installed on your system to use the
commands explained below to communicate with the git servers on
@ -26,22 +26,25 @@ provides `limited support for subversion clients <svn_>`_.
.. _git: https://git-scm.com
.. _svn: https://help.github.com/en/github/importing-your-projects-to-github/working-with-subversion-on-github
You can follow the LAMMPS development on 3 different git branches:
You can follow the LAMMPS development on 4 different git branches:
* **stable** : this branch is updated from the *release* branch with
every stable release version and also has selected bug fixes and updates
back-ported from the *develop* branch
* **release** : this branch is updated with every patch release;
updates are always "fast forward" merges from *develop*
* **release** : this branch is updated with every patch or feature release;
updates are always "fast-forward" merges from *develop*
* **develop** : this branch follows the ongoing development and
is updated with every merge commit of a pull request
* **stable** : this branch is updated from the *release* branch with
every stable release version and also has selected bug fixes with every
update release when the *maintenance* branch is merged into it
* **maintenance** : this branch collects back-ported bug fixes from the
*develop* branch to the *stable* branch. It is used to update *stable*
for update releases and it synchronized with *stable* at each stable release.
To access the git repositories on your box, use the clone command to
create a local copy of the LAMMPS repository with a command like:
.. code-block:: bash
$ git clone -b release https://github.com/lammps/lammps.git mylammps
git clone -b release https://github.com/lammps/lammps.git mylammps
where "mylammps" is the name of the directory you wish to create on
your machine and "release" is one of the 3 branches listed above.
@ -58,19 +61,19 @@ between them at any time using "git checkout <branch name>".)
commit history (most people don't), you can speed up the "cloning"
process and reduce local disk space requirements by using the
*--depth* git command line flag. That will create a "shallow clone"
of the repository containing only a subset of the git history. Using
a depth of 1000 is usually sufficient to include the head commits of
the *develop* and the *release* branches. To include the head commit
of the *stable* branch you may need a depth of up to 10000. If you
later need more of the git history, you can always convert the
shallow clone into a "full clone".
of the repository, which contains only a subset of the git history.
Using a depth of 1000 is usually sufficient to include the head
commits of the *develop*, the *release*, and the *maintenance*
branches. To include the head commit of the *stable* branch you may
need a depth of up to 10000. If you later need more of the git
history, you can always convert the shallow clone into a "full
clone".
Once the command completes, your directory will contain the same files
as if you unpacked a current LAMMPS tarball, with the exception, that
the HTML documentation files are not included. They can be fetched
from the LAMMPS website by typing ``make fetch`` in the doc directory.
Or they can be generated from the content provided in ``doc/src`` by
typing ``make html`` from the ``doc`` directory.
the HTML documentation files are not included. They can be generated
from the content provided in ``doc/src`` by typing ``make html`` from
the ``doc`` directory.
After initial cloning, as bug fixes and new features are added to
LAMMPS you can stay up-to-date by typing the following git commands
@ -78,17 +81,18 @@ from within the "mylammps" directory:
.. code-block:: bash
$ git checkout release # not needed if you always stay in this branch
$ git checkout stable # use one of these 3 checkout commands
$ git checkout develop # to choose the branch to follow
$ git pull
git checkout release # not needed if you always stay in this branch
git checkout stable # use one of these 4 checkout commands
git checkout develop # to choose the branch to follow
git checkout maintenance
git pull
Doing a "pull" will not change any files you have added to the LAMMPS
directory structure. It will also not change any existing LAMMPS
files you have edited, unless those files have changed in the
repository. In that case, git will attempt to merge the new
repository file with your version of the file and tell you if there
are any conflicts. See the git documentation for details.
directory structure. It will also not change any existing LAMMPS files
you have edited, unless those files have changed in the repository. In
that case, git will attempt to merge the changes from the repository
file with your version of the file and tell you if there are any
conflicts. See the git documentation for details.
If you want to access a particular previous release version of LAMMPS,
you can instead "check out" any version with a published tag. See the
@ -97,7 +101,7 @@ this is as follows.
.. code-block:: bash
$ git checkout tagID
git checkout tagID
Stable versions and what tagID to use for a particular stable version
are discussed on `this page <https://www.lammps.org/bug.html#version>`_.
@ -138,31 +142,31 @@ changed. How to do this depends on the build system you are using.
.. code-block:: bash
$ make purge # remove any deprecated src files
$ make package-update # sync package files with src files
$ make foo # re-build for your machine (mpi, serial, etc)
make purge # remove any deprecated src files
make package-update # sync package files with src files
make foo # re-build for your machine (mpi, serial, etc)
to enforce consistency of the source between the src folder
and package directories. This is OK to do even if you don't
use any packages. The "make purge" command removes any deprecated
src files if they were removed by the patch from a package
sub-directory.
use any packages. The ``make purge`` command removes any deprecated
src files if they were removed by the update from a package
subdirectory.
.. warning::
If you wish to edit/change a src file that is from a package,
you should edit the version of the file inside the package
sub-directory with src, then re-install the package. The
subdirectory with src, then re-install the package. The
version in the source directory is merely a copy and will be
wiped out if you type "make package-update".
.. admonition:: Git protocols
:class: note
The servers at github.com support the "https://" access protocol for
anonymous, read-only access. If you have a suitably configured GitHub
account, you may also use SSH protocol with the
URL "git@github.com:lammps/lammps.git".
The servers at github.com support the "https" access protocol for
anonymous, read-only access. If you have a suitably configured
GitHub account, you may also use SSH protocol with the URL
``git@github.com:lammps/lammps.git``.
The LAMMPS GitHub project is currently managed by Axel Kohlmeyer
The LAMMPS GitHub project is currently overseen by Axel Kohlmeyer
(Temple U, akohlmey at gmail.com).

167
doc/src/Install_linux.rst
View File

@ -3,7 +3,8 @@ Download an executable for Linux
Binaries are available for different versions of Linux:
- :ref:`Pre-built Ubuntu Linux executables <ubuntu>`
- :ref:`Pre-built static Linux x86_64 executables <static>`
- :ref:`Pre-built Ubuntu and Debian 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>`
@ -14,61 +15,93 @@ Binaries are available for different versions of Linux:
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.
developers have no control over how they configure and build their
packages and when they update them. They may only provide packages
for stable release versions and not always update the packages in a
timely fashion after a new LAMMPS release is made.
----------
.. _static:
Pre-built static Linux x86_64 executables
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Pre-built LAMMPS executables for Linux, that are statically linked and
compiled for 64-bit x86 CPUs (x86_64 or AMD64) are available for download
at `https://download.lammps.org/static/ <https://download.lammps.org/static/>`_.
Because of that static linkage (and unlike the Linux distribution specific
packages listed below), they do not depend on any installed software and
thus should run on *any* 64-bit x86 machine with *any* Linux version.
These executable include most of the available packages and multi-thread
parallelization (via INTEL, KOKKOS, or OPENMP package). They are **not**
compatible with MPI. Several of the LAMMPS tools executables (e.g. ``msi2lmp``)
and the ``lammps-shell`` program are included as well. Because of the
static linkage, there is no ``liblammps.so`` library file and thus also the
LAMMPS python module, which depends on it, is not included.
The compressed tar archives available for download have names following
the pattern ``lammps-linux-x86_64-<version>.tar.gz`` and will all unpack
into a ``lammps-static`` folder. The executables are then in the
``lammps-static/bin/`` folder. Since they do not depend on any other
software, they may be freely moved or copied around.
----------
.. _ubuntu:
Pre-built Ubuntu Linux executables
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Pre-built Ubuntu and Debian 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 (mostly) up-to-date
with the current stable version of LAMMPS by simply updating your
operating system.
A pre-built LAMMPS executable, suitable for running on the latest Ubuntu
and Debian 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
sudo apt-get install lammps
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:
missing dependencies. For example, the LAMMPS binary in this package is
built with the :ref:`KIM package <kim>` enabled, which results in the
above command also installing the ``kim-api`` binaries when LAMMPS is
installed, unless they were installed already. In order to use
potentials from `openkim.org <openkim_>`_, you can also install the
``openkim-models`` package:
.. code-block:: bash
$ lmp -in in.lj
sudo apt-get install openkim-models
Or use the `KIM-API commands <https://openkim.org/doc/usage/obtaining-models/#installing_api>`_
to download and install individual models.
This LAMMPS executable can then be used in the usual way to run input
scripts:
.. code-block:: bash
lmp -in in.lj
To update LAMMPS to the latest packaged version, do the following:
.. code-block:: bash
$ sudo apt-get update
sudo apt-get update
which will also update other packages on your system.
This will also update other packages on your system.
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
To uninstall LAMMPS, do the following:
.. 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
sudo apt-get remove lammps
Please use ``lmp -help`` to see which compilation options, packages,
and styles are included in the binary.
@ -83,8 +116,9 @@ Ubuntu package capability.
Pre-built Fedora Linux executables
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Pre-built LAMMPS packages for stable releases are available in the
Fedora Linux distribution as of Fedora version 28. The packages can be
Pre-built `LAMMPS packages for stable releases
<https://packages.fedoraproject.org/pkgs/lammps/>`_ are available in the
Fedora Linux distribution since 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
@ -103,13 +137,13 @@ To install LAMMPS with OpenMPI and run an input ``in.lj`` with 2 CPUs do:
.. code-block:: bash
$ dnf install lammps-openmpi
$ module load mpi/openmpi-x86_64
$ mpirun -np 2 lmp -in in.lj
dnf install lammps-openmpi
module load mpi/openmpi-x86_64
mpirun -np 2 lmp -in in.lj
The ``dnf install`` command is needed only once. In case of a new LAMMPS
The ``dnf install`` command is needed only once. In case of a new LAMMPS
stable release, ``dnf update`` will automatically update to the newer
version as soon at the RPM files are built and uploaded to the download
version as soon as the RPM files are built and uploaded to the download
mirrors. The ``module load`` command is needed once per (shell) session
or shell terminal instance, unless it is automatically loaded from the
shell profile.
@ -121,7 +155,7 @@ can install the `openkim-models` package
.. code-block:: bash
$ dnf install openkim-models
dnf install openkim-models
Please use ``lmp -help`` to see which compilation options, packages,
and styles are included in the binary.
@ -138,7 +172,7 @@ Pre-built EPEL Linux executable
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Pre-built LAMMPS (and KIM) packages for stable releases are available
in the `Extra Packages for Enterprise Linux (EPEL) repository <https://fedoraproject.org/wiki/EPEL>`_
in the `Extra Packages for Enterprise Linux (EPEL) repository <https://docs.fedoraproject.org/en-US/epel/>`_
for use with Red Hat Enterprise Linux (RHEL) or CentOS version 7.x
and compatible Linux distributions. Names of packages, executable,
and content are the same as described above for Fedora Linux.
@ -162,14 +196,14 @@ in OpenSuse as of Leap 15.0. You can install the package with:
.. code-block:: bash
$ zypper install lammps
zypper install lammps
This includes support for OpenMPI. The name of the LAMMPS executable
is ``lmp``. Thus to run an input in parallel on 2 CPUs you would do:
is ``lmp``. To run an input in parallel on 2 CPUs you would do:
.. code-block:: bash
$ mpirun -np 2 lmp -in in.lj
mpirun -np 2 lmp -in in.lj
Please use ``lmp -help`` to see which compilation options, packages,
and styles are included in the binary.
@ -181,7 +215,7 @@ can install the `openkim-models` package
.. code-block:: bash
$ zypper install openkim-models
zypper install openkim-models
Thanks to Christoph Junghans (LANL) for making LAMMPS available in OpenSuse.
@ -192,21 +226,22 @@ Thanks to Christoph Junghans (LANL) for making LAMMPS available in OpenSuse.
Gentoo Linux executable
^^^^^^^^^^^^^^^^^^^^^^^
LAMMPS is part of Gentoo's main package tree and can be installed by
typing:
LAMMPS is part of `Gentoo's main package tree
<https://packages.gentoo.org/packages/sci-physics/lammps>`_ and can be
installed by typing:
.. code-block:: bash
% emerge --ask lammps
emerge --ask lammps
Note that in Gentoo the LAMMPS source is downloaded and the package is
built on the your machine.
Note that in Gentoo the LAMMPS source code is downloaded and the package is
then compiled and installed on your machine.
Certain LAMMPS packages can be enable via USE flags, type
Certain LAMMPS packages can be enabled via USE flags, type
.. code-block:: bash
% equery uses lammps
equery uses lammps
for details.
@ -221,35 +256,31 @@ Archlinux build-script
^^^^^^^^^^^^^^^^^^^^^^
LAMMPS is available via Arch's unofficial Arch User repository (AUR).
There are three scripts available, named lammps, lammps-beta and lammps-git.
They respectively package the stable, patch and git releases.
There are three scripts available, named `lammps
<https://aur.archlinux.org/packages/lammps>`_, `lammps-beta
<https://aur.archlinux.org/packages/lammps>`_ and `lammps-git
<https://aur.archlinux.org/packages/lammps>`_. They respectively
package the stable, feature, and git releases.
To install, you will need to have the git package installed. You may use
any of the above names in-place of lammps.
.. code-block:: bash
$ git clone https://aur.archlinux.org/lammps.git
$ cd lammps
$ makepkg -s
$ makepkg -i
git clone https://aur.archlinux.org/lammps.git
cd lammps
makepkg -s
makepkg -i
To update, you may repeat the above, or change into the cloned directory,
and execute the following, after which, if there are any changes, you may
use makepkg as above.
To update LAMMPS, you may repeat the above, or change into the cloned
directory, and execute the following, after which, if there are any
changes, you may use makepkg as above.
.. code-block:: bash
$ git pull
git pull
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.
Note that the AUR provides build-scripts that download the source code
and then build and install the package on your machine.

36
doc/src/Install_mac.rst
View File

@ -1,39 +1,41 @@
Download an executable for Mac
------------------------------
Download an executable for macOS
--------------------------------
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, MPIIO, POEMS, VORONOI.
LAMMPS can be downloaded, built, and configured for macOS with `Homebrew
<homebrew_>`_. (Alternatively, see the installation instructions for
:doc:`downloading an executable via Conda <Install_conda>`.) The
following LAMMPS packages are unavailable at this time because of
additional requirements not yet met: GPU, KOKKOS, MSCG, POEMS,
VORONOI.
After installing Homebrew, you can install LAMMPS on your system with
the following commands:
.. code-block:: bash
% brew install lammps
brew install lammps
This will install the executables "lammps_serial" and "lammps_mpi", as well as
the LAMMPS "doc", "potentials", "tools", "bench", and "examples" directories.
This will install the executables "lammps_serial" and "lammps_mpi", as
well as the LAMMPS "doc", "potentials", "tools", "bench", and "examples"
directories.
Once LAMMPS is installed, you can test the installation with the
Lennard-Jones benchmark file:
.. code-block:: bash
% brew test lammps -v
brew test lammps -v
The LAMMPS binary is built with the :ref:`KIM package <kim>` which
results in Homebrew 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 LAMMPS binary is built with the :ref:`KIM package <kim>`, which
results in Homebrew 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
.. code-block:: bash
% brew install openkim-models
brew install openkim-models
If you have problems with the installation you can post issues to
If you have problems with the installation, you can post issues to
`this link <https://github.com/Homebrew/homebrew-core/issues>`_.
.. _homebrew: https://brew.sh

39
doc/src/Install_tarball.rst
View File

@ -2,48 +2,51 @@ Download source and documentation as a tarball
----------------------------------------------
You can download a current LAMMPS tarball from the `download page <download_>`_
of the `LAMMPS website <lws_>`_.
of the `LAMMPS website <lws_>`_ or from GitHub (see below).
.. _download: https://www.lammps.org/download.html
.. _bug: https://www.lammps.org/bug.html
.. _older: https://download.lammps.org/tars/
.. _lws: https://www.lammps.org
You have two choices of tarballs, either the most recent stable
release or the most current patch release. Stable releases occur a
few times per year, and undergo more testing before release. Patch
releases occur a couple times per month. The new contents in all
releases are listed on the `bug and feature page <bug_>`_ of the website.
You have two choices of tarballs, either the most recent stable release
or the most recent feature release. Stable releases occur a few times
per year, and undergo more testing before release. Also, between stable
releases bug fixes from the feature releases are back-ported and the
tarball occasionally updated. Feature releases occur every 4 to 8
weeks. The new contents in all feature releases are listed on the `bug
and feature page <bug_>`_ of the LAMMPS homepage.
Both tarballs include LAMMPS documentation (HTML and PDF files)
corresponding to that version. The download page also has an option
to download the current-version LAMMPS documentation by itself.
Tarballs of older LAMMPS versions can also be downloaded from `this page
<older_>`_.
Older versions of LAMMPS can also be downloaded from `this page <older_>`_.
Tarballs downloaded from the LAMMPS homepage include the pre-translated
LAMMPS documentation (HTML and PDF files) corresponding to that version.
Once you have a tarball, unzip and untar it with the following
Once you have a tarball, uncompress and untar it with the following
command:
.. code-block:: bash
$ tar -xzvf lammps*.tar.gz
tar -xzvf lammps*.tar.gz
This will create a LAMMPS directory with the version date
in its name, e.g. lammps-23Jun18.
This will create a LAMMPS directory with the version date in its name,
e.g. lammps-28Mar23.
----------
You can also download a compressed tar or zip archives from the
"Assets" sections of the `LAMMPS GitHub releases site <git_>`_.
The file name will be lammps-<version>.zip which can be unzipped
with the following command, to create a lammps-<version> dir:
with the following command, to create a lammps-<version> directory:
.. code-block:: bash
$ unzip lammps*.zip
unzip lammps*.zip
This version corresponds to the selected LAMMPS patch or stable
release.
This version corresponds to the selected LAMMPS feature or stable
release (as indicated by the matching git tag) and will only contain the
source code and no pre-built documentation.
.. _git: https://github.com/lammps/lammps/releases

22
doc/src/Install_windows.rst
View File

@ -6,7 +6,7 @@ Windows system can be downloaded from this site:
.. parsed-literal::
`http://packages.lammps.org/windows.html <http://packages.lammps.org/windows.html>`_
`https://packages.lammps.org/windows.html <https://packages.lammps.org/windows.html>`_
Note that each installer package has a date in its name, which
corresponds to the LAMMPS version of the same date. Installers for
@ -17,11 +17,11 @@ install the Windows MPI package (MPICH2 from Argonne National Labs),
needed to run in parallel with MPI.
The LAMMPS binaries contain *all* :doc:`optional packages <Packages>`
included in the source distribution except: KIM, KOKKOS, MSCG, PYTHON,
ADIOS, H5MD, NETCDF, QMMM, ML-QUIP, and VTK.
The serial version also does not include the MPIIO and
LATBOLTZ packages. The GPU package is compiled for OpenCL with
mixed precision kernels.
included in the source distribution except: ADIOS, H5MD, KIM, ML-PACE,
ML-QUIP, MSCG, NETCDF, QMMM, SCAFACOS, and VTK. The serial version also
does not include the LATBOLTZ package. The PYTHON package is only
available in the Python installers that bundle a Python runtime. The
GPU package is compiled for OpenCL with mixed precision kernels.
The LAMMPS library is compiled as a shared library and the
:doc:`LAMMPS Python module <Python_module>` is installed, so that
@ -33,7 +33,7 @@ Windows, once it is installed, in both serial and parallel.
When you download the installer package, you run it on your Windows
machine. It will then prompt you with a dialog, where you can choose
the installation directory, unpack and copy several executables,
potential files, documentation pdfs, selected example files, etc. It
potential files, documentation PDFs, selected example files, etc. It
will then update a few system settings (e.g. PATH, LAMMPS_POTENTIALS)
and add an entry into the Start Menu (with references to the
documentation, LAMMPS homepage and more). From that menu, there is
@ -41,10 +41,10 @@ also a link to an uninstaller that removes the files and undoes the
environment manipulations.
Note that to update to a newer version of LAMMPS, you should typically
uninstall the version you currently have, download a new installer,
and go through the install procedure described above. I.e. the same
uninstall the version you currently have, download a new installer, and
go through the installation procedure described above. I.e. the same
procedure for installing/updating most Windows programs. You can
install multiple versions of LAMMPS (in different directories), but
only the executable for the last-installed package will be found
install multiple versions of LAMMPS (in different directories), but only
the executable for the last-installed package will be found
automatically, so this should only be done for debugging purposes.

1
doc/src/Intro.rst
View File

@ -10,6 +10,7 @@ These pages provide a brief introduction to LAMMPS.
Manual_version
Intro_features
Intro_nonfeatures
Intro_portability
Intro_opensource
Intro_authors
Intro_citing

10
doc/src/Intro_authors.rst
View File

@ -4,13 +4,13 @@ Authors of LAMMPS
The primary LAMMPS developers are at Sandia National Labs and Temple
University:
* `Steve Plimpton <sjp_>`_, sjplimp at sandia.gov
* `Steve Plimpton <sjp_>`_, sjplimp at gmail.com
* Aidan Thompson, athomps at sandia.gov
* Stan Moore, stamoor at sandia.gov
* Axel Kohlmeyer, akohlmey at gmail.com
* `Axel Kohlmeyer <https://sites.google.com/site/akohlmey/>`_, akohlmey at gmail.com
* Richard Berger, richard.berger at outlook.com
.. _sjp: http://www.cs.sandia.gov/~sjplimp
.. _sjp: https://sjplimp.github.io
.. _lws: https://www.lammps.org
Past developers include Paul Crozier and Mark Stevens, both at Sandia,
@ -37,10 +37,10 @@ general-purpose as it is without their expertise and efforts.
* Reese Jones (Sandia) and colleagues, ATC package for atom/continuum coupling
* Christoph Kloss (DCS Computing), LIGGGHTS code for granular materials, built on top of LAMMPS
* Rudra Mukherjee (JPL), POEMS package for articulated rigid body motion
* Trung Ngyuen (Northwestern U), GPU, RIGID, BODY, and DIELECTRIC packages
* Trung Ngyuen (U Chicago), GPU, RIGID, BODY, and DIELECTRIC packages
* Mike Parks (Sandia), PERI package for Peridynamics
* Roy Pollock (LLNL), Ewald and PPPM solvers
* Julien Tranchida (Sandia), SPIN package
* Julien Tranchida (CEA Cadarache), SPIN package
* Christian Trott (Sandia), CUDA and KOKKOS packages
* Ilya Valuev (JIHT), AWPMD package for wave packet MD
* Greg Wagner (Northwestern U), MEAM package for MEAM potential

14
doc/src/Intro_citing.rst
View File

@ -27,7 +27,7 @@ namely https://www.lammps.org.
The original publication describing the parallel algorithms used in the
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>`_
`S. Plimpton, Fast Parallel Algorithms for Short-Range Molecular Dynamics, J Comp Phys, 117, 1-19 (1995). <https://doi.org/10.1006/jcph.1995.1039>`_
DOI for the LAMMPS source code
@ -38,15 +38,15 @@ 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:
point to the **latest** stable release version, is:
- DOI: `10.5281/zenodo.3726416 <https://dx.doi.org/10.5281/zenodo.3726416>`_
In addition there are DOIs for individual stable releases. Currently there are:
In addition there are DOIs generated for individual stable releases:
- 3 March 2020 version: `DOI:10.5281/zenodo.3726417 <https://dx.doi.org/10.5281/zenodo.3726417>`_
- 29 October 2020 version: `DOI:10.5281/zenodo.4157471 <https://dx.doi.org/10.5281/zenodo.4157471>`_
- 29 September 2021 version: `DOI:10.5281/zenodo.6386596 <https//dx.doi.org/10.5281/zenodo.6386596>`_
- 29 September 2021 version: `DOI:10.5281/zenodo.6386596 <https://dx.doi.org/10.5281/zenodo.6386596>`_
Home page
^^^^^^^^^
@ -65,6 +65,6 @@ for optional features used in a specific run is printed to the screen
and log file. Style and output location can be selected with the
:ref:`-cite command-line switch <cite>`. Additional references are
given in the documentation of the :doc:`corresponding commands
<Commands_all>` or in the :doc:`Howto tutorials <Howto>`. So please
make certain, that you provide the proper acknowledgments and citations
in any published works using LAMMPS.
<Commands_all>` or in the :doc:`Howto tutorials <Howto>`. Please make
certain, that you provide the proper acknowledgments and citations in
any published works using LAMMPS.

62
doc/src/Intro_features.rst
View File

@ -27,7 +27,7 @@ General features
* distributed memory message-passing parallelism (MPI)
* shared memory multi-threading parallelism (OpenMP)
* spatial decomposition of simulation domain for MPI parallelism
* particle decomposition inside of spatial decomposition for OpenMP and GPU parallelism
* particle decomposition inside spatial decomposition for OpenMP and GPU parallelism
* GPLv2 licensed open-source distribution
* highly portable C++-11
* modular code with most functionality in optional packages
@ -39,8 +39,11 @@ General features
* syntax for defining and using variables and formulas
* syntax for looping over runs and breaking out of loops
* run one or multiple simulations simultaneously (in parallel) from one script
* build as library, invoke LAMMPS through library interface or provided Python wrapper or SWIG based wrappers
* couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both
* build as library, invoke LAMMPS through library interface (from C, C++, Fortran) or provided Python wrapper or SWIG based wrappers
* couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both, MDI coupling interface
* call out to Python for computing forces, time integration, or other tasks
* plugin interface for loading external features at runtime
* large integrated collection of tests
.. _particle:
@ -54,6 +57,7 @@ Particle and model types
* united-atom polymers or organic molecules
* all-atom polymers, organic molecules, proteins, DNA
* metals
* metal oxides
* granular materials
* coarse-grained mesoscale models
* finite-size spherical and ellipsoidal particles
@ -74,28 +78,29 @@ Interatomic potentials (force fields)
:doc:`improper style <improper_style>`, :doc:`kspace style <kspace_style>`
commands)
* pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
* pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, Yukawa, soft, Class II (COMPASS), hydrogen bond, harmonic, gaussian, tabulated, scripted
* charged pairwise potentials: Coulombic, point-dipole
* many-body potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, REBO, AIREBO, ReaxFF, COMB, Streitz-Mintmire, 3-body polymorphic, BOP, Vashishta
* machine learning potentials: SNAP, GAP, ACE, N2P2, RANN, AGNI
* long-range interactions for charge, point-dipoles, and LJ dispersion: Ewald, Wolf, PPPM (similar to particle-mesh Ewald), MSM
* polarization models: :doc:`QEq <fix_qeq>`, :doc:`core/shell model <Howto_coreshell>`, :doc:`Drude dipole model <Howto_drude>`
* many-body potentials: EAM, Finnis/Sinclair, MEAM, MEAM+SW, EIM, EDIP, ADP, Stillinger-Weber, Tersoff, REBO, AIREBO, ReaxFF, COMB, Streitz-Mintmire, 3-body polymorphic, BOP, Vashishta
* machine learning potentials: ACE, AGNI, GAP, Behler-Parrinello (N2P2), POD, RANN
* interfaces to ML potentials distributed by external groups: ANI, ChIMES, DeepPot, HIPNN, MTP
* long-range interactions for charge, point-dipoles, and LJ dispersion: Ewald, Wolf, PPPM (similar to particle-mesh Ewald), MSM, ScaFaCoS
* polarization models: :doc:`QEq <fix_qeq>`, :doc:`core/shell model <Howto_coreshell>`, :doc:`Drude dipole model <Howto_drude>`
* charge equilibration (QEq via dynamic, point, shielded, Slater methods)
* coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO
* coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO, oxDNA / oxRNA, SPICA
* mesoscopic potentials: granular, Peridynamics, SPH, mesoscopic tubular potential (MESONT)
* semi-empirical potentials: multi-ion generalized pseudopotential theory (MGPT), second moment tight binding + QEq (SMTB-Q), density functional tight-binding (LATTE)
* semi-empirical potentials: multi-ion generalized pseudopotential theory (MGPT), second moment tight binding + QEq (SMTB-Q)
* electron force field (eFF, AWPMD)
* bond potentials: harmonic, FENE, Morse, nonlinear, class 2, quartic (breakable), tabulated
* angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, class 2 (COMPASS), tabulated
* dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, class 2 (COMPASS), OPLS, tabulated
* improper potentials: harmonic, cvff, umbrella, class 2 (COMPASS), tabulated
* bond potentials: harmonic, FENE, Morse, nonlinear, Class II (COMPASS), quartic (breakable), tabulated, scripted
* angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, Class II (COMPASS), tabulated, scripted
* dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, Class II (COMPASS), OPLS, tabulated, scripted
* improper potentials: harmonic, cvff, umbrella, Class II (COMPASS), tabulated
* polymer potentials: all-atom, united-atom, bead-spring, breakable
* water potentials: TIP3P, TIP4P, SPC, SPC/E and variants
* interlayer potentials for graphene and analogues
* interlayer potentials for graphene and analogues, hetero-junctions
* metal-organic framework potentials (QuickFF, MO-FF)
* implicit solvent potentials: hydrodynamic lubrication, Debye
* force-field compatibility with common CHARMM, AMBER, DREIDING, OPLS, GROMACS, COMPASS options
* access to the `OpenKIM Repository <http://openkim.org>`_ of potentials via :doc:`kim command <kim_commands>`
* force-field compatibility with CHARMM, AMBER, DREIDING, OPLS, GROMACS, Class II (COMPASS), UFF, ClayFF, DREIDING, AMOEBA, INTERFACE
* access to the `OpenKIM Repository <https://openkim.org>`_ of potentials via the :doc:`kim command <kim_commands>`
* hybrid potentials: multiple pair, bond, angle, dihedral, improper potentials can be used in one simulation
* overlaid potentials: superposition of multiple pair potentials (including many-body) with optional scale factor
@ -108,7 +113,7 @@ Atom creation
:doc:`create_atoms <create_atoms>`, :doc:`delete_atoms <delete_atoms>`,
:doc:`displace_atoms <displace_atoms>`, :doc:`replicate <replicate>` commands)
* read in atom coords from files
* read in atom coordinates from files
* create atoms on one or more lattices (e.g. grain boundaries)
* delete geometric or logical groups of atoms (e.g. voids)
* replicate existing atoms multiple times
@ -129,7 +134,7 @@ Ensembles, constraints, and boundary conditions
* simulation box deformation (tensile and shear)
* harmonic (umbrella) constraint forces
* rigid body constraints
* SHAKE bond and angle constraints
* SHAKE / RATTLE bond and angle constraints
* motion constraints to manifold surfaces
* Monte Carlo bond breaking, formation, swapping, template based reaction modeling
* atom/molecule insertion and deletion
@ -147,8 +152,9 @@ Integrators
* velocity-Verlet integrator
* Brownian dynamics
* rigid body integration
* energy minimization via conjugate gradient or steepest descent relaxation
* energy minimization via conjugate gradient, steepest descent relaxation, or damped dynamics (FIRE, Quickmin)
* rRESPA hierarchical timestepping
* fixed or adaptive time step
* rerun command for post-processing of dump files
.. _diag:
@ -167,15 +173,17 @@ Output
(:doc:`dump <dump>`, :doc:`restart <restart>` commands)
* log file of thermodynamic info
* text dump files of atom coords, velocities, other per-atom quantities
* text dump files of atom coordinates, velocities, other per-atom quantities
* dump output on fixed and variable intervals, based timestep or simulated time
* binary restart files
* parallel I/O of dump and restart files
* per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc)
* per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc.)
* user-defined system-wide (log file) or per-atom (dump file) calculations
* custom partitioning (chunks) for binning, and static or dynamic grouping of atoms for analysis
* spatial, time, and per-chunk averaging of per-atom quantities
* time averaging and histogramming of system-wide quantities
* atom snapshots in native, XYZ, XTC, DCD, CFG formats
* atom snapshots in native, XYZ, XTC, DCD, CFG, NetCDF, HDF5, ADIOS2, YAML formats
* on-the-fly compression of output and decompression of read in files
.. _replica1:
@ -187,7 +195,7 @@ Multi-replica models
* :doc:`parallel replica dynamics <prd>`
* :doc:`temperature accelerated dynamics <tad>`
* :doc:`parallel tempering <temper>`
* path-integral MD: `first variant <fix_pimd>`, `second variant <fix_ipi>`
* path-integral MD: :doc:`first variant <fix_pimd>`, :doc:`second variant <fix_ipi>`
* multi-walker collective variables with :doc:`Colvars <fix_colvars>` and :doc:`Plumed <fix_plumed>`
.. _prepost:
@ -205,15 +213,15 @@ Pre- and post-processing
.. _pizza: https://lammps.github.io/pizza
.. _python: http://www.python.org
.. _python: https://www.python.org
.. _special:
Specialized features
^^^^^^^^^^^^^^^^^^^^
LAMMPS can be built with optional packages which implement a variety
of additional capabilities. See the :doc:`Optional Packages <Packages>`
LAMMPS can be built with optional packages which implement a variety of
additional capabilities. See the :doc:`Optional Packages <Packages>`
page for details.
These are LAMMPS capabilities which you may not think of as typical

91
doc/src/Intro_nonfeatures.rst
View File

@ -5,7 +5,7 @@ LAMMPS is designed to be a fast, parallel engine for molecular
dynamics (MD) simulations. It provides only a modest amount of
functionality for setting up simulations and analyzing their output.
Specifically, LAMMPS was not conceived and designed for:
Originally, LAMMPS was not conceived and designed for:
* being run through a GUI
* building molecular systems, or building molecular topologies
@ -14,28 +14,31 @@ Specifically, LAMMPS was not conceived and designed for:
* visualize your MD simulation interactively
* plot your output data
Over the years some of these limitations have been reduced or
removed, through features added to LAMMPS or external tools
that either closely interface with LAMMPS or extend LAMMPS.
Over the years many of these limitations have been reduced or
removed. In part through features added to LAMMPS and in part
through external tools that either closely interface with LAMMPS
or extend LAMMPS.
Here are suggestions on how to perform these tasks:
* **GUI:** LAMMPS can be built as a library and a Python wrapper that wraps
the library interface is provided. Thus, GUI interfaces can be
written in Python (or C or C++ if desired) that run LAMMPS and
visualize or plot its output. Examples of this are provided in the
python directory and described on the :doc:`Python <Python_head>` doc
page. Also, there are several external wrappers or GUI front ends.
* **Builder:** Several pre-processing tools are packaged with LAMMPS. Some
of them convert input files in formats produced by other MD codes such
as CHARMM, AMBER, or Insight into LAMMPS input formats. Some of them
are simple programs that will build simple molecular systems, such as
linear bead-spring polymer chains. The moltemplate program is a true
molecular builder that will generate complex molecular models. See
the :doc:`Tools <Tools>` page for details on tools packaged with
LAMMPS. The `Pre/post processing page <http:/www.lammps.org/prepost.html>`_ of the LAMMPS website
* **GUI:** LAMMPS can be built as a library and a Python module that
wraps the library interface is provided. Thus, GUI interfaces can be
written in Python or C/C++ that run LAMMPS and visualize or plot its
output. Examples of this are provided in the python directory and
described on the :doc:`Python <Python_head>` doc page. As of version
2 August 2023 :ref:`a GUI tool <lammps_gui>` is included in LAMMPS.
Also, there are several external wrappers or GUI front ends.
* **Builder:** Several pre-processing tools are packaged with LAMMPS.
Some of them convert input files in formats produced by other MD codes
such as CHARMM, AMBER, or Insight into LAMMPS input formats. Some of
them are simple programs that will build simple molecular systems,
such as linear bead-spring polymer chains. The moltemplate program is
a true molecular builder that will generate complex molecular models.
See the :doc:`Tools <Tools>` page for details on tools packaged with
LAMMPS. The `Pre-/post-processing page
<https://www.lammps.org/prepost.html>`_ of the LAMMPS homepage
describes a variety of third party tools for this task. Furthermore,
some LAMMPS internal commands allow to reconstruct, or selectively add
some internal LAMMPS commands allow reconstructing, or selectively adding
topology information, as well as provide the option to insert molecule
templates instead of atoms for building bulk molecular systems.
* **Force-field assignment:** The conversion tools described in the previous
@ -47,38 +50,38 @@ Here are suggestions on how to perform these tasks:
powerful and flexible in converting force field and topology data
between various MD simulation programs.
* **Simulation analysis:** If you want to perform analysis on-the-fly as
your simulation runs, see the :doc:`compute <compute>` and
:doc:`fix <fix>` doc pages, which list commands that can be used in a
LAMMPS input script. Also see the :doc:`Modify <Modify>` page for
info on how to add your own analysis code or algorithms to LAMMPS.
For post-processing, LAMMPS output such as :doc:`dump file snapshots <dump>` can be converted into formats used by other MD or
your simulation runs, see the :doc:`compute <compute>` and :doc:`fix
<fix>` doc pages, which list commands that can be used in a LAMMPS
input script. Also see the :doc:`Modify <Modify>` page for info on
how to add your own analysis code or algorithms to LAMMPS. For
post-processing, LAMMPS output such as :doc:`dump file snapshots
<dump>` can be converted into formats used by other MD or
post-processing codes. To some degree, that conversion can be done
directly inside of LAMMPS by interfacing to the VMD molfile plugins.
The :doc:`rerun <rerun>` command also allows to do some post-processing
of existing trajectories, and through being able to read a variety
of file formats, this can also be used for analyzing trajectories
from other MD codes. Some post-processing tools packaged with
LAMMPS will do these conversions. Scripts provided in the
tools/python directory can extract and massage data in dump files to
make it easier to import into other programs. See the
:doc:`Tools <Tools>` page for details on these various options.
* **Visualization:** LAMMPS can produce NETPBM, JPG or PNG snapshot images
on-the-fly via its :doc:`dump image <dump_image>` command and pass
them to an external program, `FFmpeg <https://www.ffmpeg.org>`_ to generate
movies from them. For high-quality, interactive visualization there are
many excellent and free tools available. See the
`Visualization Tools <https://www.lammps.org/viz.html>`_ page of the
LAMMPS website for
directly inside LAMMPS by interfacing to the VMD molfile plugins. The
:doc:`rerun <rerun>` command also allows post-processing of existing
trajectories, and through being able to read a variety of file
formats, this can also be used for analyzing trajectories from other
MD codes. Some post-processing tools packaged with LAMMPS will do
these conversions. Scripts provided in the tools/python directory can
extract and massage data in dump files to make it easier to import
into other programs. See the :doc:`Tools <Tools>` page for details on
these various options.
* **Visualization:** LAMMPS can produce NETPBM, JPG, or PNG format
snapshot images on-the-fly via its :doc:`dump image <dump_image>`
command and pass them to an external program, `FFmpeg <https://ffmpeg.org/>`_,
to generate movies from them. For high-quality, interactive visualization,
there are many excellent and free tools available. See the `Visualization Tools
<https://www.lammps.org/viz.html>`_ page of the LAMMPS website for
visualization packages that can process LAMMPS output data.
* **Plotting:** See the next bullet about Pizza.py as well as the
:doc:`Python <Python_head>` page for examples of plotting LAMMPS
output. Scripts provided with the *python* tool in the tools
directory will extract and massage data in log and dump files to make
output. Scripts provided with the *python* tool in the ``tools``
directory will extract and process data in log and dump files to make
it easier to analyze and plot. See the :doc:`Tools <Tools>` doc page
for more discussion of the various tools.
* **Pizza.py:** Our group has also written a separate toolkit called
`Pizza.py <https://lammps.github.io/pizza>`_ which can do certain kinds of
setup, analysis, plotting, and visualization (via OpenGL) for LAMMPS
simulations. It thus provides some functionality for several of the
above bullets. Pizza.py is written in `Python <http://www.python.org>`_
and is available for download from `this page <http://www.cs.sandia.gov/~sjplimp/download.html>`_.
above bullets. Pizza.py is written in `Python <https://www.python.org>`_
and is available for download from `this page <https://sjplimp.github.io/download.html>`_.

4
doc/src/Intro_opensource.rst
View File

@ -23,9 +23,9 @@ applies to LAMMPS is in the LICENSE file included in the LAMMPS distribution.
.. _lgpl: https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
.. _gnuorg: http://www.gnu.org
.. _gnuorg: https://www.gnu.org
.. _opensource: http://www.opensource.org
.. _opensource: https://www.opensource.org
Here is a more specific summary of what the GPL means for LAMMPS users:

55
doc/src/Intro_overview.rst
View File

@ -1,20 +1,20 @@
Overview of LAMMPS
------------------
LAMMPS is a classical molecular dynamics (MD) code that models
ensembles of particles in a liquid, solid, or gaseous state. It can
model atomic, polymeric, biological, solid-state (metals, ceramics,
oxides), granular, coarse-grained, or macroscopic systems using a
variety of interatomic potentials (force fields) and boundary
conditions. It can model 2d or 3d systems with only a few particles
up to millions or billions.
LAMMPS is a classical molecular dynamics (MD) code that models ensembles
of particles in a liquid, solid, or gaseous state. It can model atomic,
polymeric, biological, solid-state (metals, ceramics, oxides), granular,
coarse-grained, or macroscopic systems using a variety of interatomic
potentials (force fields) and boundary conditions. It can model 2d or
3d systems with sizes ranging from only a few particles up to billions.
LAMMPS can be built and run on a laptop or desktop machine, but is
LAMMPS can be built and run on single laptop or desktop machines, but is
designed for parallel computers. It will run in serial and on any
parallel machine that supports the `MPI <mpi_>`_ message-passing
library. This includes shared-memory boxes and distributed-memory
clusters and supercomputers. Parts of LAMMPS also support
`OpenMP multi-threading <omp_>`_, vectorization and GPU acceleration.
library. This includes shared-memory multicore, multi-CPU servers and
distributed-memory clusters and supercomputers. Parts of LAMMPS also
support `OpenMP multi-threading <omp_>`_, vectorization, and GPU
acceleration.
.. _mpi: https://en.wikipedia.org/wiki/Message_Passing_Interface
.. _lws: https://www.lammps.org
@ -29,25 +29,24 @@ versions can be downloaded as source code from the `LAMMPS website
LAMMPS is designed to be easy to modify or extend with new capabilities,
such as new force fields, atom types, boundary conditions, or
diagnostics. See the :doc:`Modify <Modify>` page for more details.
diagnostics. See the :doc:`Modify` section of for more details.
In the most general sense, LAMMPS integrates Newton's equations of
motion for a collection of interacting particles. A single particle
can be an atom or molecule or electron, a coarse-grained cluster of
atoms, or a mesoscopic or macroscopic clump of material. The
interaction models that LAMMPS includes are mostly short-range in
nature; some long-range models are included as well.
motion for a collection of interacting particles. A single particle can
be an atom or molecule or electron, a coarse-grained cluster of atoms,
or a mesoscopic or macroscopic clump of material. The interaction
models that LAMMPS includes are mostly short-ranged in nature; some
long-range models are included as well.
LAMMPS uses neighbor lists to keep track of nearby particles. The
lists are optimized for systems with particles that are repulsive at
short distances, so that the local density of particles never becomes
too large. This is in contrast to methods used for modeling plasma
or gravitational bodies (e.g. galaxy formation).
LAMMPS uses neighbor lists to keep track of nearby particles. The lists
are optimized for systems with particles that are repulsive at short
distances, so that the local density of particles never becomes too
large. This is in contrast to methods used for modeling plasma or
gravitational bodies (like galaxy formation).
On parallel machines, LAMMPS uses spatial-decomposition techniques with
MPI parallelization to partition the simulation domain into small
sub-domains of equal computational cost, one of which is assigned to
each processor. Processors communicate and store "ghost" atom
information for atoms that border their sub-domain. Multi-threading
parallelization and GPU acceleration with with particle-decomposition
can be used in addition.
MPI parallelization to partition the simulation domain into subdomains
of equal computational cost, one of which is assigned to each processor.
Processors communicate and store "ghost" atom information for atoms that
border their subdomain. Multi-threading parallelization and GPU
acceleration with particle-decomposition can be used in addition.

75
doc/src/Intro_portability.rst Normal file
View File

@ -0,0 +1,75 @@
LAMMPS portability and compatibility
------------------------------------
The primary form of distributing LAMMPS is through highly portable
source code. But also several ways of obtaining LAMMPS as :doc:`precompiled
packages or through automated build mechanisms <Install>` exist. Most
of LAMMPS is written in C++, some support tools are written in Fortran
or Python or MATLAB.
Programming language standards
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Most of the C++ code currently requires a compiler compatible with the
C++11 standard, the KOKKOS package currently requires C++17. Most of
the Python code is written to be compatible with Python 3.5 or later or
Python 2.7. Some Python scripts *require* Python 3 and a few others
still need to be ported from Python 2 to Python 3.
Build systems
^^^^^^^^^^^^^
LAMMPS can be compiled from source code using a (traditional) build
system based on shell scripts, a few shell utilities (grep, sed, cat,
tr) and the GNU make program. This requires running within a Bourne
shell (``/bin/sh``). Alternatively, a build system with different back ends
can be created using CMake. CMake must be at least version 3.16.
Operating systems
^^^^^^^^^^^^^^^^^
The primary development platform for LAMMPS is Linux. Thus, the chances
for LAMMPS to compile without problems on Linux machines are the best.
Also, compilation and correct execution on macOS and Windows (using
Microsoft Visual C++) is checked automatically for largest part of the
source code. Some (optional) features are not compatible with all
operating systems, either through limitations of the corresponding
LAMMPS source code or through source code or build system
incompatibilities of required libraries.
Executables for Windows may be created natively using either Cygwin or
Visual Studio or with a Linux to Windows MinGW cross-compiler.
Additionally, FreeBSD and Solaris have been tested successfully.
Compilers
^^^^^^^^^
The most commonly used compilers are the GNU compilers, but also Clang
and the Intel compilers have been successfully used on Linux, macOS, and
Windows. Also, the Nvidia HPC SDK (formerly PGI compilers) will compile
LAMMPS (tested on Linux).
CPU architectures
^^^^^^^^^^^^^^^^^
The primary CPU architecture for running LAMMPS is 64-bit x86, but also
32-bit x86, and 64-bit ARM and PowerPC (64-bit, Little Endian) are
regularly tested.
Portability compliance
^^^^^^^^^^^^^^^^^^^^^^
Only a subset of the LAMMPS source code is *fully* compliant to *all*
of the above mentioned standards. This is rather typical for projects
like LAMMPS that largely depend on contributions from the user community.
Not all contributors are trained as programmers and not all of them have
access to multiple platforms for testing. As part of the continuous
integration process, however, all contributions are automatically tested
to compile, link, and pass some runtime tests on a selection of Linux
flavors, macOS, and Windows, and on Linux with different compilers.
Thus portability issues are often found before a pull request is merged.
Other platforms may be checked occasionally or when portability bugs are
reported.

11
doc/src/Intro_website.rst
View File

@ -7,20 +7,15 @@ available online are listed below.
.. _lws: https://www.lammps.org
* `Brief intro and recently added significant features <lws_>`_
* `List of features <https://docs.lammps.org/Intro_features.html>`_
* `List of non-features <https://docs.lammps.org/Intro_nonfeatures.html>`_
* `Recent bug fixes and new features <https://www.lammps.org/bug.html>`_
* `LAMMPS source code repository on GitHub <https://github.com/lammps/lammps>`_
* `LAMMPS forum on matsci.org <https://matsci.org/lammps/>`_
* `Recent bug fixes and new features <https://www.lammps.org/bug.html>`_
* `Download info <https://www.lammps.org/download.html>`_
* `GitHub site <https://github.com/lammps/lammps>`_
* `SourceForge site <https://sourceforge.net/projects/lammps>`_
* `LAMMPS open-source license <https://docs.lammps.org/Intro_opensource.html>`_
* `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>`_
* `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/PolyNIPAM.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
doc/src/JPG/dump.peri.2000.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 200 KiB

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