jianmu
/
lammps
forked from lijiext/lammps
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'master' into atc-doc-to-rst 

# Conflicts:
#	doc/src/fix_atc.rst
This commit is contained in:
Axel Kohlmeyer 2020-03-13 21:12:12 -04:00
parent 80d413b86c 7c6353731e
commit b3040db1e7
No known key found for this signature in database
GPG Key ID: D9B44E93BF0C375A
518 changed files with 3687 additions and 3734 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

107
doc/src/Build_basics.rst
View File

@ -40,14 +40,14 @@ is below.
-D LAMMPS_MACHINE=name # name = mpi, serial, mybox, titan, laptop, etc
# no default value
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 named *lmp\_name*\. Using `BUILD\_MPI=no` will
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 ``lmp_name``. Using ``BUILD_MPI=no`` will
enforce building a serial executable using the MPI STUBS library.
**Traditional make**\ :
The build with traditional makefiles has to be done inside the source folder `src`.
The build with traditional makefiles has to be done inside the source folder ``src``.
.. code-block:: bash
@ -56,17 +56,17 @@ The build with traditional makefiles has to be done inside the source folder `sr
make mybox # uses Makefile.mybox to produce lmp_mybox
Any "make machine" command will look up the make settings from a file
Makefile.machine, 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
Makefile.machine, 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 compiler wrappers where all necessary compiler and linker flags to
get access and link with the suitable MPI headers and libraries are set
by the wrapper programs. For other cases or the serial build, you have
to adjust the make file variables MPI\_INC, MPI\_PATH, MPI\_LIB as well
as CC and LINK. To enable OpenMP threading usually a compiler specific
flag needs to be added to the compile and link commands. For the GNU
compilers, this is *-fopenmp*\ , which can be added to the CC and LINK
makefile variables.
to adjust the make file variables ``MPI_INC``, ``MPI_PATH``, ``MPI_LIB``
as well as ``CC`` and ``LINK``\ . To enable OpenMP threading usually
a compiler specific flag needs to be added to the compile and link
commands. For the GNU compilers, this is ``-fopenmp``\ , which can be
added to the ``CC`` and ``LINK`` makefile variables.
For the serial build the following make variables are set (see src/MAKE/Makefile.serial):
@ -79,8 +79,8 @@ For the serial build the following make variables are set (see src/MAKE/Makefile
MPI_LIB = -lmpi_stubs
You also need to build the STUBS library for your platform before making
LAMMPS itself. A "make serial" build does this for you automatically,
otherwise, type "make mpi-stubs" from the src directory, or "make" from
LAMMPS itself. A ``make serial`` build does this for you automatically,
otherwise, type ``make mpi-stubs`` from the src directory, or ``make`` from
the src/STUBS dir. If the build fails, you will 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 USER-LB,
@ -88,8 +88,8 @@ and thus is not compatible with those packages.
.. note::
The file STUBS/mpi.c provides a CPU timer function called
MPI\_Wtime() that calls gettimeofday() . If your operating system
The file ``src/STUBS/mpi.c`` provides a CPU timer function called
MPI_Wtime() that calls gettimeofday() . If your operating system
does not support gettimeofday() , you will need to insert code to
call another timer. Note that the ANSI-standard function clock()
rolls over after an hour or so, and is therefore insufficient for
@ -126,29 +126,29 @@ to: e.g. LATTE and USER-COLVARS. See the :doc:`Packages details
<Packages_details>` doc page for more info on these packages and the doc
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
support at run time, by setting the OMP\_NUM\_THREADS environment
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
support at run time, by setting the ``OMP_NUM_THREADS`` environment
variable before you launch LAMMPS.
For building via conventional make, the CCFLAGS and LINKFLAGS
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,
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.
.. _default-none-issues:
**OpenMP Compiler compatibility info**\ :
Some compilers do not fully support the 'default(none)' directive
Some compilers do not fully support the ``default(none)`` directive
and others (e.g. GCC version 9 and beyond) may implement OpenMP 4.0
semantics, which are incompatible with the OpenMP 3.1 directives used
semantics, which are incompatible with the OpenMP 3.1 semantics used
in LAMMPS (for maximal compatibility with compiler versions in use).
In those case, all 'default(none)' directives (which aid in detecting
incorrect and unwanted sharing) can be replaced with 'default(shared)'
while dropping all 'shared()' directives. The script
'src/USER-OMP/hack\_openmp\_for\_pgi\_gcc9.sh' can be used to automate
In those case, all ``default(none)`` directives (which aid in detecting
incorrect and unwanted sharing) can be replaced with ``default(shared)``
while dropping all ``shared()`` directives. The script
'src/USER-OMP/hack_openmp_for_pgi_gcc9.sh' can be used to automate
this conversion.
----------
@ -183,11 +183,11 @@ optimization flags appropriate to that compiler and any
build.
You can tell CMake to look for a specific compiler with these variable
settings. Likewise you can specify the FLAGS variables if you want to
experiment with alternate optimization flags. You should specify all
3 compilers, so that the small number of LAMMPS source files written
in C or Fortran are built with a compiler consistent with the one used
for all the C++ files:
settings. Likewise you can specify the corresponding ``CMAKE_*_FLAGS``
variables if you want to experiment with alternate optimization flags.
You should specify all 3 compilers, so that the small number of LAMMPS
source files written in C or Fortran are built with a compiler consistent
with the one used for all the C++ files:
.. code-block:: bash
@ -300,19 +300,18 @@ are set, defaults are applied.
-D LAMMPS_LIB_SUFFIX=name # name = mpi, serial, mybox, titan, laptop, etc
# no default value
Setting BUILD\_EXE=no will not produce an executable. Setting
BUILD\_LIB=yes will produce a static library named *liblammps.a*\ .
Setting both BUILD\_LIB=yes and BUILD\_SHARED\_LIBS=yes will produce a
shared library named *liblammps.so* instead. If LAMMPS\_LIB\_SUFFIX is
set to *name* in addition, the name of the generated libraries will be
changed to either *liblammps\_name.a* or *liblammps\_name.so*\ ,
respectively.
Setting ``BUILD_EXE=no`` will not produce an executable. Setting
``BUILD_LIB=yes`` will produce a static library named ``liblammps.a``\ .
Setting both ``BUILD_LIB=yes`` and ``BUILD_SHARED_LIBS=yes`` will produce a
shared library named ``liblammps.so`` instead. If ``LAMMPS_LIB_SUFFIX=name``
is set in addition, the name of the generated libraries will be changed to
either ``liblammps_name.a`` or ``liblammps_name.so``\ , respectively.
**Traditional make**\ :
With the traditional makefile based build process, the choice of
the generated executable or library depends on the "mode" setting.
Several options are available and "mode=exe" is the default.
Several options are available and ``mode=exe`` is the default.
.. code-block:: bash
@ -322,11 +321,11 @@ Several options are available and "mode=exe" is the default.
make mode=shlib machine # build LAMMPS shared lib liblammps_machine.so
make mode=shexe machine # same as "mode=exe" but uses objects from "mode=shlib"
The two "exe" builds will generate and executable *lmp\_machine*\ ,
while the two library builds will create a file *liblammps\_machine.a*
or *liblammps\_machine.so*\ . They will also create generic soft links,
named *liblammps.a* and *liblammps.so*\ , which point to the specific
*liblammps\_machine.a/so* files.
The two "exe" builds will generate and executable ``lmp_machine``\ ,
while the two library builds will create a file ``liblammps_machine.a``
or ``liblammps_machine.so``\ . They will also create generic soft links,
named ``liblammps.a`` and ``liblammps.so``\ , which point to the specific
``liblammps_machine.a/so`` files.
**CMake and make info**\ :
@ -335,7 +334,7 @@ the auxiliary libraries it depends on must also exist as shared
libraries. This will be the case for libraries included with LAMMPS,
such as the dummy MPI library in src/STUBS or any package libraries in
the lib/packages directory, since they are always built in a shared
library compatible way using the -fPIC switch. However, if a library
library compatible way using the ``-fPIC`` switch. However, if a library
like MPI or FFTW does not exist as a shared library, the shared library
build may generate an error. This means you will need to install a
shared library version of the auxiliary library. The build instructions
@ -353,10 +352,10 @@ in the default /usr/local/lib location:
make
make install
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. The end result should
be the file /usr/local/lib/libmpich.so. On many Linux installations the
folder "${HOME}/.local" is an alternative to using /usr/local and does
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``. The end result should
be the file ``/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:
@ -420,7 +419,7 @@ It is also possible to create the HTML version of the manual within
the :doc:`CMake build directory <Build_cmake>`. The reason for this
option is to include the installation of the HTML manual pages into
the "install" step when installing LAMMPS after the CMake build via
"make install".
``make install``.
.. code-block:: bash
@ -479,6 +478,6 @@ you want to copy files to is protected.
**Traditional make**\ :
There is no "install" option in the src/Makefile for LAMMPS. If you
wish to do this you will need to first build LAMMPS, then manually
There is no "install" option in the ``src/Makefile`` for LAMMPS. If
you wish to do this you will need to first build LAMMPS, then manually
copy the desired LAMMPS files to the appropriate system directories.

44
doc/src/Build_cmake.rst
View File

@ -13,8 +13,8 @@ good place to start.
Building LAMMPS with CMake is a two-step process. First you use CMake
to create a build environment in a new directory. On Linux systems,
this will be based on makefiles for use with make. Then you use the
make command to build LAMMPS, which uses the created
this will be by default based on Unix-style makefiles for use with make.
Then you use the *make* command to build LAMMPS, which uses the created
Makefile(s). Example:
.. code-block:: bash
@ -28,8 +28,8 @@ The cmake command will detect available features, enable selected
packages and options, and will generate the build environment. By default
this build environment will be created for "Unix Makefiles" on most
platforms and particularly on Linux. However, alternate build tools
(e.g. Ninja) and support files for Integrated Development Environments
(IDE) like Eclipse, CodeBlocks, or Kate can be generated, too. This is
(e.g. Ninja) and project files for Integrated Development Environments
(IDEs) like Eclipse, CodeBlocks, or Kate can be generated, too. This is
selected via the "-G" command line flag. For the rest of the documentation
we will assume that the build environment is generated for makefiles
and thus the make command will be used to compile and link LAMMPS as
@ -55,16 +55,17 @@ your system with:
This will install the lammps executable and library (if requested), some
tools (if configured) and additional files like library API headers,
manpages, potential and force field files. The location of the installation
tree is set by the CMake variable "CMAKE\_INSTALL\_PREFIX" which defaults
tree is set by the CMake variable "CMAKE_INSTALL_PREFIX" which defaults
to ${HOME}/.local
----------
There are 3 variants of CMake: a command-line version (cmake), a text mode
UI version (ccmake), and a graphical GUI version (cmake-GUI). You can use
any of them interchangeably to configure and create the LAMMPS build
environment. On Linux all the versions produce a Makefile as their
output. See more details on each below.
There are 3 variants of the CMake command itself: a command-line version
(*cmake* or *cmake3*), a text mode UI version (*ccmake* or *ccmake3*),
and a graphical GUI version (*cmake-gui*). You can use any of them
interchangeably to configure and create the LAMMPS build environment.
On Linux all the versions produce a Makefile as their output by default.
See more details on each below.
You can specify a variety of options with any of the 3 versions, which
affect how the build is performed and what is included in the LAMMPS
@ -82,12 +83,13 @@ this directory or sub-directories within it that CMake creates.
.. note::
To perform a CMake build, no packages can be installed or a
build been previously attempted in the LAMMPS src directory by using
"make" commands to :doc:`perform a conventional LAMMPS build <Build_make>`. CMake detects if this is the case and
generates an error, telling you to type "make no-all purge" in the src
directory to un-install all packages. The purge removes all the \*.h
files auto-generated by make.
To perform a CMake build, no packages can be installed or a build
been previously attempted in the LAMMPS src directory by using "make"
commands to :doc:`perform a conventional LAMMPS build <Build_make>`.
CMake detects if this is the case and generates an error, telling you
to type "make no-all purge" in the src directory to un-install all
packages. The purge removes all the \*.h files auto-generated by
make.
You must have CMake version 3.10 or later on your system to build
LAMMPS. Installation instructions for CMake are below.
@ -106,8 +108,9 @@ folder, recreate the directory and start over.
.. code-block:: bash
cmake [options ...] /path/to/lammps/cmake # build from any dir
cmake [options ...] ../cmake # build from lammps/build
cmake [options ...] /path/to/lammps/cmake # build from any dir
cmake [options ...] ../cmake # build from lammps/build
cmake3 [options ...] ../cmake # build from lammps/build
The cmake command takes one required argument, which is the LAMMPS
cmake directory which contains the CMakeLists.txt file.
@ -119,7 +122,8 @@ command-line options. Several useful ones are:
-D CMAKE_INSTALL_PREFIX=path # where to install LAMMPS executable/lib if desired
-D CMAKE_BUILD_TYPE=type # type = RelWithDebInfo (default), Release, MinSizeRel, or Debug
-G output # style of output CMake generates
-G output # style of output CMake generates (e.g. "Unix Makefiles" or "Ninja")
-D CMAKE_MAKE_PROGRAM=builder # name of the builder executable (e.g. set to "gmake" instead of "make")
-DVARIABLE=value # setting for a LAMMPS feature to enable
-D VARIABLE=value # ditto, but cannot come after CMakeLists.txt dir
-C path/to/preset/file # load some CMake settings before configuring
@ -127,7 +131,7 @@ command-line options. Several useful ones are:
All the LAMMPS-specific -D variables that a LAMMPS build supports are
described on the pages linked to from the :doc:`Build <Build>` doc page.
All of these variable names are upper-case and their values are
lower-case, e.g. -D LAMMPS\_SIZES=smallbig. For boolean values, any of
lower-case, e.g. -D LAMMPS_SIZES=smallbig. For boolean values, any of
these forms can be used: yes/no, on/off, 1/0.
On Unix/Linux machines, CMake generates a Makefile by default to

241
doc/src/Build_extras.rst
View File

@ -14,7 +14,7 @@ or
$ make yes-name
as described on the :doc:`Build\_package <Build_package>` doc page.
as described on the :doc:`Build_package <Build_package>` doc page.
For a CMake build there may be additional optional or required
variables to set. For a build with make, a provided library under the
@ -107,37 +107,37 @@ which GPU hardware to build for.
-D CUDA_MPS_SUPPORT=value # enables some tweaks required to run with active nvidia-cuda-mps daemon
# value = yes or no (default)
GPU\_ARCH settings for different GPU hardware is as follows:
GPU_ARCH settings for different GPU hardware is as follows:
* sm\_12 or sm\_13 for GT200 (supported by CUDA 3.2 until CUDA 6.5)
* sm\_20 or sm\_21 for Fermi (supported by CUDA 3.2 until CUDA 7.5)
* sm\_30 or sm\_35 or sm\_37 for Kepler (supported since CUDA 5)
* sm\_50 or sm\_52 for Maxwell (supported since CUDA 6)
* sm\_60 or sm\_61 for Pascal (supported since CUDA 8)
* sm\_70 for Volta (supported since CUDA 9)
* sm\_75 for Turing (supported since CUDA 10)
* sm_12 or sm_13 for GT200 (supported by CUDA 3.2 until CUDA 6.5)
* sm_20 or sm_21 for Fermi (supported by CUDA 3.2 until CUDA 7.5)
* sm_30 or sm_35 or sm_37 for Kepler (supported since CUDA 5)
* sm_50 or sm_52 for Maxwell (supported since CUDA 6)
* sm_60 or sm_61 for Pascal (supported since CUDA 8)
* sm_70 for Volta (supported since CUDA 9)
* sm_75 for Turing (supported since CUDA 10)
A more detailed list can be found, for example,
at `Wikipedia's CUDA article <https://en.wikipedia.org/wiki/CUDA#GPUs_supported>`_
CMake can detect which version of the CUDA toolkit is used and thus can
include support for **all** major GPU architectures supported by this toolkit.
Thus the GPU\_ARCH setting is merely an optimization, to have code for
Thus the GPU_ARCH setting is merely an optimization, to have code for
the preferred GPU architecture directly included rather than having to wait
for the JIT compiler of the CUDA driver to translate it.
**Traditional make**\ :
Before building LAMMPS, you must build the GPU library in lib/gpu.
Before building LAMMPS, you must build the GPU library in ``lib/gpu``\ .
You can do this manually if you prefer; follow the instructions in
lib/gpu/README. Note that the GPU library uses MPI calls, so you must
``lib/gpu/README``. Note that the GPU library uses MPI calls, so you must
use the same MPI library (or the STUBS library) settings as the main
LAMMPS code. This also applies to the -DLAMMPS\_BIGBIG,
-DLAMMPS\_SMALLBIG, or -DLAMMPS\_SMALLSMALL settings in whichever
LAMMPS code. This also applies to the ``-DLAMMPS_BIGBIG``\ ,
``-DLAMMPS_SMALLBIG``\ , or ``-DLAMMPS_SMALLSMALL`` settings in whichever
Makefile you use.
You can also build the library in one step from the lammps/src dir,
using a command like these, which simply invoke the lib/gpu/Install.py
You can also build the library in one step from the ``lammps/src`` dir,
using a command like these, which simply invoke the ``lib/gpu/Install.py``
script with the specified args:
.. code-block:: bash
@ -156,22 +156,22 @@ Makefile.machine you start from via the corresponding -c, -a, -p, -e
switches (as in the examples above), and also save a copy of the new
Makefile if desired:
* CUDA\_HOME = where NVIDIA CUDA software is installed on your system
* CUDA\_ARCH = sm\_XX, what GPU hardware you have, same as CMake GPU\_ARCH above
* CUDA\_PRECISION = precision (double, mixed, single)
* EXTRAMAKE = which Makefile.lammps.\* file to copy to Makefile.lammps
* ``CUDA_HOME`` = where NVIDIA CUDA software is installed on your system
* ``CUDA_ARCH`` = sm_XX, what GPU hardware you have, same as CMake GPU_ARCH above
* ``CUDA_PRECISION`` = precision (double, mixed, single)
* ``EXTRAMAKE`` = which Makefile.lammps.\* file to copy to Makefile.lammps
The file Makefile.linux\_multi is set up to include support for multiple
The file Makefile.linux_multi is set up to include support for multiple
GPU architectures as supported by the CUDA toolkit in use. This is done
through using the "--gencode " flag, which can be used multiple times and
thus support all GPU architectures supported by your CUDA compiler.
If the library build is successful, 3 files should be created:
lib/gpu/libgpu.a, lib/gpu/nvc\_get\_devices, and
lib/gpu/Makefile.lammps. The latter has settings that enable LAMMPS
to link with CUDA libraries. If the settings in Makefile.lammps for
``lib/gpu/libgpu.a``\ , ``lib/gpu/nvc_get_devices``\ , and
``lib/gpu/Makefile.lammps``\ . The latter has settings that enable LAMMPS
to link with CUDA libraries. If the settings in ``Makefile.lammps`` for
your machine are not correct, the LAMMPS build will fail, and
lib/gpu/Makefile.lammps may need to be edited.
``lib/gpu/Makefile.lammps`` may need to be edited.
.. note::
@ -211,35 +211,36 @@ minutes to hours) to build. Of course you only need to do that once.)
-D LMP_DEBUG_CURL=value # set libcurl verbose mode on/off, value = off (default) or on
-D LMP_NO_SSL_CHECK=value # tell libcurl to not verify the peer, value = no (default) or yes
If DOWNLOAD\_KIM is set, the KIM library will be downloaded and built
If ``DOWNLOAD_KIM`` is set, the KIM library will be downloaded and built
inside the CMake build directory. If the KIM library is already on
your system (in a location CMake cannot find it), set the PKG\_CONFIG\_PATH
your system (in a location CMake cannot find it), set the ``PKG_CONFIG_PATH``
environment variable so that libkim-api can be found.
*For using OpenKIM web queries in LAMMPS*\ :
If LMP\_DEBUG\_CURL is set, the libcurl verbose mode will be on, and any
libcurl calls within the KIM web query display a lot of information about
libcurl operations. You hardly ever want this set in production use, you will
almost always want this when you debug/report problems.
If the ``LMP_DEBUG_CURL`` environment variable is set, the libcurl verbose
mode will be on, and any libcurl calls within the KIM web query display a
lot of information about libcurl operations. You hardly ever want this
set in production use, you will almost always want this when you debug or
report problems.
The libcurl performs peer SSL certificate verification by default. This
verification is done using a CA certificate store that the SSL library can
use to make sure the peer's server certificate is valid. If SSL reports an
error ("certificate verify failed") during the handshake and thus refuses
further communication with that server, you can set LMP\_NO\_SSL\_CHECK.
If LMP\_NO\_SSL\_CHECK is set, libcurl does not verify the peer and connection
further communication with that server, you can set ``LMP_NO_SSL_CHECK``\ .
If ``LMP_NO_SSL_CHECK`` is set, libcurl does not verify the peer and connection
succeeds regardless of the names in the certificate. This option is insecure.
As an alternative, you can specify your own CA cert path by setting the
environment variable CURL\_CA\_BUNDLE to the path of your choice. A call to the
KIM web query would get this value from the environmental variable.
environment variable ``CURL_CA_BUNDLE`` to the path of your choice. A call
to the KIM web query would get this value from the environmental variable.
**Traditional make**\ :
You can download and build the KIM library manually if you prefer;
follow the instructions in lib/kim/README. You can also do it in one
follow the instructions in ``lib/kim/README``\ . You can also do it in one
step from the lammps/src dir, using a command like these, which simply
invoke the lib/kim/Install.py script with the specified args.
invoke the ``lib/kim/Install.py`` script with the specified args.
.. code-block:: bash
@ -252,7 +253,7 @@ invoke the lib/kim/Install.py script with the specified args.
$ make lib-kim args="-p /usr/local -a EAM_Dynamo_Ackland_W__MO_141627196590_002" # ditto but add one model or driver
Settings for OpenKIM web queries discussed above need to be applied by adding
them to the LMP\_INC variable through editing the Makefile.machine you are
them to the ``LMP_INC`` variable through editing the Makefile.machine you are
using. For example:
.. code-block:: make
@ -271,7 +272,7 @@ build for, either CPUs (multi-threading via OpenMP) or KNLs (OpenMP)
or GPUs (NVIDIA Cuda).
For a CMake or make build, these are the possible choices for the
KOKKOS\_ARCH settings described below. Note that for CMake, these are
``KOKKOS_ARCH`` settings described below. Note that for CMake, these are
really Kokkos variables, not LAMMPS variables. Hence you must use
case-sensitive values, e.g. BDW, not bdw.
@ -334,7 +335,7 @@ For NVIDIA GPUs using CUDA, set these 4 variables:
-D CMAKE_CXX_COMPILER=wrapper # wrapper = full path to Cuda nvcc wrapper
The wrapper value is the Cuda nvcc compiler wrapper provided in the
Kokkos library: lib/kokkos/bin/nvcc\_wrapper. The setting should
Kokkos library: ``lib/kokkos/bin/nvcc_wrapper``\ . The setting should
include the full path name to the wrapper, e.g.
.. code-block:: bash
@ -343,9 +344,9 @@ include the full path name to the wrapper, e.g.
**Traditional make**\ :
Choose which hardware to support in Makefile.machine via
KOKKOS\_DEVICES and KOKKOS\_ARCH settings. See the
src/MAKE/OPTIONS/Makefile.kokkos\* files for examples.
Choose which hardware to support in ``Makefile.machine`` via
``KOKKOS_DEVICES`` and ``KOKKOS_ARCH`` settings. See the
``src/MAKE/OPTIONS/Makefile.kokkos\*`` files for examples.
For multicore CPUs using OpenMP:
@ -400,18 +401,18 @@ library.
-D DOWNLOAD_LATTE=value # download LATTE for build, value = no (default) or yes
-D LATTE_LIBRARY=path # LATTE library file (only needed if a custom location)
If DOWNLOAD\_LATTE is set, the LATTE library will be downloaded and
If ``DOWNLOAD_LATTE`` is set, the LATTE library will be downloaded and
built inside the CMake build directory. If the LATTE library is
already on your system (in a location CMake cannot find it),
LATTE\_LIBRARY is the filename (plus path) of the LATTE library file,
``LATTE_LIBRARY`` is the filename (plus path) of the LATTE library file,
not the directory the library file is in.
**Traditional make**\ :
You can download and build the LATTE library manually if you prefer;
follow the instructions in lib/latte/README. You can also do it in
one step from the lammps/src dir, using a command like these, which
simply invokes the lib/latte/Install.py script with the specified
follow the instructions in ``lib/latte/README``\ . You can also do it in
one step from the ``lammps/src`` dir, using a command like these, which
simply invokes the ``lib/latte/Install.py`` script with the specified
args:
.. code-block:: bash
@ -450,10 +451,10 @@ be installed on your system.
**Traditional make**\ :
Before building LAMMPS, you must build the CSlib library in
lib/message. You can build the CSlib library manually if you prefer;
follow the instructions in lib/message/README. You can also do it in
one step from the lammps/src dir, using a command like these, which
simply invoke the lib/message/Install.py script with the specified args:
``lib/message``\ . You can build the CSlib library manually if you prefer;
follow the instructions in ``lib/message/README``\ . You can also do it in
one step from the ``lammps/src`` dir, using a command like these, which
simply invoke the ``lib/message/Install.py`` script with the specified args:
.. code-block:: bash
@ -461,9 +462,9 @@ simply invoke the lib/message/Install.py script with the specified args:
$ make lib-message args="-m -z" # build with MPI and socket (ZMQ) support
$ make lib-message args="-s" # build as serial lib with no ZMQ support
The build should produce two files: lib/message/cslib/src/libmessage.a
and lib/message/Makefile.lammps. The latter is copied from an
existing Makefile.lammps.\* and has settings to link with the ZeroMQ
The build should produce two files: ``lib/message/cslib/src/libmessage.a``
and ``lib/message/Makefile.lammps``\ . The latter is copied from an
existing ``Makefile.lammps.\*`` and has settings to link with the ZeroMQ
library if requested in the build.
----------
@ -474,10 +475,10 @@ MSCG package
-----------------------
To build with this package, you must download and build the MS-CG
library. Building the MS-CG library and using it from LAMMPS requires
a C++11 compatible compiler and that the GSL (GNU Scientific Library)
headers and libraries are installed on your machine. See the
lib/mscg/README and MSCG/Install files for more details.
library. Building the MS-CG library requires that the GSL
(GNU Scientific Library) headers and libraries are installed on your
machine. See the ``lib/mscg/README`` and ``MSCG/Install`` files for
more details.
**CMake build**\ :
@ -487,19 +488,19 @@ lib/mscg/README and MSCG/Install files for more details.
-D MSCG_LIBRARY=path # MSCG library file (only needed if a custom location)
-D MSCG_INCLUDE_DIR=path # MSCG include directory (only needed if a custom location)
If DOWNLOAD\_MSCG is set, the MSCG library will be downloaded and built
If ``DOWNLOAD_MSCG`` is set, the MSCG library will be downloaded and built
inside the CMake build directory. If the MSCG library is already on
your system (in a location CMake cannot find it), MSCG\_LIBRARY is the
your system (in a location CMake cannot find it), ``MSCG_LIBRARY`` is the
filename (plus path) of the MSCG library file, not the directory the
library file is in. MSCG\_INCLUDE\_DIR is the directory the MSCG
library file is in. ``MSCG_INCLUDE_DIR`` is the directory the MSCG
include file is in.
**Traditional make**\ :
You can download and build the MS-CG library manually if you prefer;
follow the instructions in lib/mscg/README. You can also do it in one
step from the lammps/src dir, using a command like these, which simply
invoke the lib/mscg/Install.py script with the specified args:
follow the instructions in ``lib/mscg/README``\ . You can also do it in one
step from the ``lammps/src`` dir, using a command like these, which simply
invoke the ``lib/mscg/Install.py`` script with the specified args:
.. code-block:: bash
@ -511,9 +512,9 @@ invoke the lib/mscg/Install.py script with the specified args:
$ make lib-mscg args="-p /usr/local/mscg-release" # use the existing MS-CG installation in /usr/local/mscg-release
Note that 2 symbolic (soft) links, "includelink" and "liblink", will
be created in lib/mscg to point to the MS-CG src/installation dir.
When LAMMPS is built in src it will use these links. You should not
need to edit the lib/mscg/Makefile.lammps file.
be created in ``lib/mscg`` to point to the MS-CG ``src/installation``
dir. When LAMMPS is built in src it will use these links. You should
not need to edit the ``lib/mscg/Makefile.lammps`` file.
----------
@ -524,7 +525,7 @@ OPT package
**CMake build**\ :
No additional settings are needed besides "-D PKG\_OPT=yes".
No additional settings are needed besides ``-D PKG_OPT=yes``
**Traditional make**\ :
@ -542,15 +543,15 @@ POEMS package
**CMake build**\ :
No additional settings are needed besides "-D PKG\_OPT=yes".
No additional settings are needed besides ``-D PKG_OPT=yes``
**Traditional make**\ :
Before building LAMMPS, you must build the POEMS library in lib/poems.
Before building LAMMPS, you must build the POEMS library in ``lib/poems``\ .
You can do this manually if you prefer; follow the instructions in
lib/poems/README. You can also do it in one step from the lammps/src
``lib/poems/README``\ . You can also do it in one step from the ``lammps/src``
dir, using a command like these, which simply invoke the
lib/poems/Install.py script with the specified args:
``lib/poems/Install.py`` script with the specified args:
.. code-block:: bash
@ -559,13 +560,13 @@ lib/poems/Install.py script with the specified args:
$ make lib-poems args="-m mpi" # build with default MPI C++ compiler (settings as with "make mpi")
$ make lib-poems args="-m icc" # build with Intel icc compiler
The build should produce two files: lib/poems/libpoems.a and
lib/poems/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.\* and has settings needed to build LAMMPS with the
The build should produce two files: ``lib/poems/libpoems.a`` and
``lib/poems/Makefile.lammps``\ . The latter is copied from an existing
``Makefile.lammps.\*`` and has settings needed to build LAMMPS with the
POEMS library (though typically the settings are just blank). If
necessary, you can edit/create a new lib/poems/Makefile.machine file
for your system, which should define an EXTRAMAKE variable to specify
a corresponding Makefile.lammps.machine file.
necessary, you can edit/create a new ``lib/poems/Makefile.machine`` file
for your system, which should define an ``EXTRAMAKE`` variable to specify
a corresponding ``Makefile.lammps.machine`` file.
----------
@ -575,9 +576,9 @@ PYTHON package
---------------------------
Building with the PYTHON package requires you have a Python shared
library available on your system, which needs to be a Python 2
version, 2.6 or later. Python 3 is not yet supported. See
lib/python/README for more details.
library available on your system, which needs to be a Python 2.7
version or a Python 3.x version. See ``lib/python/README`` for more
details.
**CMake build**\ :
@ -588,16 +589,16 @@ lib/python/README for more details.
Without this setting, CMake will guess the default Python on your
system. To use a different Python version, you can either create a
virtualenv, activate it and then run cmake. Or you can set the
PYTHON\_EXECUTABLE variable to specify which Python interpreter should
PYTHON_EXECUTABLE variable to specify which Python interpreter should
be used. Note note that you will also need to have the development
headers installed for this version, e.g. python2-devel.
**Traditional make**\ :
The build uses the lib/python/Makefile.lammps file in the compile/link
The build uses the ``lib/python/Makefile.lammps`` file in the compile/link
process to find Python. You should only need to create a new
Makefile.lammps.\* file (and copy it to Makefile.lammps) if the LAMMPS
build fails.
``Makefile.lammps.\*`` file (and copy it to ``Makefile.lammps``\ ) if
the LAMMPS build fails.
----------
@ -618,11 +619,11 @@ To build with this package, you must download and build the `Voro++ library <vor
-D VORO_LIBRARY=path # Voro++ library file (only needed if at custom location)
-D VORO_INCLUDE_DIR=path # Voro++ include directory (only needed if at custom location)
If DOWNLOAD\_VORO is set, the Voro++ library will be downloaded and
If DOWNLOAD_VORO is set, the Voro++ library will be downloaded and
built inside the CMake build directory. If the Voro++ library is
already on your system (in a location CMake cannot find it),
VORO\_LIBRARY is the filename (plus path) of the Voro++ library file,
not the directory the library file is in. VORO\_INCLUDE\_DIR is the
VORO_LIBRARY is the filename (plus path) of the Voro++ library file,
not the directory the library file is in. VORO_INCLUDE_DIR is the
directory the Voro++ include file is in.
**Traditional make**\ :
@ -656,7 +657,7 @@ The USER-ADIOS package requires the `ADIOS I/O library <https://github.com/ornla
version 2.3.1 or newer. Make sure that you have ADIOS built either with or
without MPI to match if you build LAMMPS with or without MPI.
ADIOS compilation settings for LAMMPS are automatically detected, if the PATH
and LD\_LIBRARY\_PATH environment variables have been updated for the local ADIOS
and LD_LIBRARY_PATH environment variables have been updated for the local ADIOS
installation and the instructions below are followed for the respective build systems.
**CMake build**\ :
@ -674,7 +675,7 @@ Turn on the USER-ADIOS package before building LAMMPS. If the ADIOS 2.x software
$ make yes-user-adios
otherwise, set ADIOS2\_DIR environment variable when turning on the package:
otherwise, set ADIOS2_DIR environment variable when turning on the package:
.. code-block:: bash
@ -691,8 +692,8 @@ The USER-ATC package requires the MANYBODY package also be installed.
**CMake build**\ :
No additional settings are needed besides "-D PKG\_USER-ATC=yes"
and "-D PKG\_MANYBODY=yes".
No additional settings are needed besides "-D PKG_USER-ATC=yes"
and "-D PKG_MANYBODY=yes".
**Traditional make**\ :
@ -739,7 +740,7 @@ USER-AWPMD package
**CMake build**\ :
No additional settings are needed besides "-D PKG\_USER-AQPMD=yes".
No additional settings are needed besides "-D PKG_USER-AQPMD=yes".
**Traditional make**\ :
@ -800,12 +801,12 @@ C++11-only features.
**CMake build**\ :
This is the recommended build recipe: no additional settings are normally
needed besides "-D PKG\_USER-COLVARS=yes".
needed besides "-D PKG_USER-COLVARS=yes".
Building and linking of Lepton (or other C++11-only features) is enabled
automatically when compilation is carried out with C++11 support, and disabled
otherwise. Optionally, Lepton build may be manually controlled with the flag
"-D COLVARS\_LEPTON=yes\|no".
"-D COLVARS_LEPTON=yes\|no".
**Traditional make**\ :
@ -850,7 +851,7 @@ not need to be edited.
USER-PLUMED package
-------------------------------------
.. _plumedinstall: https://plumed.github.io/doc-master/user-doc/html/\_installation.html
.. _plumedinstall: https://plumed.github.io/doc-master/user-doc/html/_installation.html
Before building LAMMPS with this package, you must first build PLUMED.
PLUMED can be built as part of the LAMMPS build or installed separately
@ -872,7 +873,7 @@ LAMMPS uses can be updated without the need for a recompile of LAMMPS
for as long as the shared PLUMED library is ABI-compatible.
The third linkage mode is "runtime" which allows the user to specify
which PLUMED kernel should be used at runtime by using the PLUMED\_KERNEL
which PLUMED kernel should be used at runtime by using the PLUMED_KERNEL
environment variable. This variable should point to the location of the
libplumedKernel.so dynamical shared object, which is then loaded at
runtime. This mode of linking is particularly convenient for doing
@ -889,7 +890,7 @@ LAMMPS build.
**CMake build**\ :
When the "-D PKG\_USER-PLUMED" flag is included in the cmake command you
When the "-D PKG_USER-PLUMED" flag is included in the cmake command you
must ensure that GSL is installed in locations that are specified in
your environment. There are then two additional commands that control
the manner in which PLUMED is obtained and linked into LAMMPS.
@ -899,21 +900,21 @@ the manner in which PLUMED is obtained and linked into LAMMPS.
-D DOWNLOAD_PLUMED=value # download PLUMED for build, value = no (default) or yes
-D PLUMED_MODE=value # Linkage mode for PLUMED, value = static (default), shared, or runtime
If DOWNLOAD\_PLUMED is set to "yes", the PLUMED library will be
If DOWNLOAD_PLUMED is set to "yes", the PLUMED library will be
downloaded (the version of PLUMED that will be downloaded is hard-coded
to a vetted version of PLUMED, usually a recent stable release version)
and built inside the CMake build directory. If DOWNLOAD\_PLUMED is set
and built inside the CMake build directory. If DOWNLOAD_PLUMED is set
to "no" (the default), CMake will try to detect and link to an installed
version of PLUMED. For this to work, the PLUMED library has to be
installed into a location where the pkg-config tool can find it or the
PKG\_CONFIG\_PATH environment variable has to be set up accordingly.
PKG_CONFIG_PATH environment variable has to be set up accordingly.
PLUMED should be installed in such a location if you compile it using
the default make; make install commands.
The PLUMED\_MODE setting determines the linkage mode for the PLUMED
The PLUMED_MODE setting determines the linkage mode for the PLUMED
library. The allowed values for this flag are "static" (default),
"shared", or "runtime". For a discussion of PLUMED linkage modes,
please see above. When DOWNLOAD\_PLUMED is enabled the static linkage
please see above. When DOWNLOAD_PLUMED is enabled the static linkage
mode is recommended.
**Traditional make**\ :
@ -952,7 +953,7 @@ package and compile LAMMPS in the usual manner:
Once this compilation completes you should be able to run LAMMPS in the
usual way. For shared linkage mode, libplumed.so must be found by the
LAMMPS executable, which on many operating systems means, you have to
set the LD\_LIBRARY\_PATH environment variable accordingly.
set the LD_LIBRARY_PATH environment variable accordingly.
Support for the different linkage modes in LAMMPS varies for different
operating systems, using the static linkage is expected to be the most
@ -976,7 +977,7 @@ the HDF5 library.
**CMake build**\ :
No additional settings are needed besides "-D PKG\_USER-H5MD=yes".
No additional settings are needed besides "-D PKG_USER-H5MD=yes".
This should auto-detect the H5MD library on your system. Several
advanced CMake H5MD options exist if you need to specify where it is
@ -1040,7 +1041,7 @@ runs with other compilers and without TBB and MKL.
**Traditional make**\ :
Choose which hardware to compile for in Makefile.machine via the
following settings. See src/MAKE/OPTIONS/Makefile.intel\_cpu\* and
following settings. See src/MAKE/OPTIONS/Makefile.intel_cpu\* and
Makefile.knl files for examples. and src/USER-INTEL/README for
additional information.
@ -1076,8 +1077,8 @@ USER-MOLFILE package
-D MOLFILE_INCLUDE_DIRS=path # (optional) path where VMD molfile plugin headers are installed
-D PKG_USER-MOLFILE=yes
Using "-D PKG\_USER-MOLFILE=yes" enables the package, and setting
"-D MOLFILE\_INCLUDE DIRS" allows to provide a custom location for
Using "-D PKG_USER-MOLFILE=yes" enables the package, and setting
"-D MOLFILE_INCLUDE DIRS" allows to provide a custom location for
the molfile plugin header files. These should match the ABI of the
plugin files used, and thus one typically sets them to include
folder of the local VMD installation in use. LAMMPS ships with a
@ -1109,7 +1110,7 @@ on your system.
**CMake build**\ :
No additional settings are needed besides "-D PKG\_USER-NETCDF=yes".
No additional settings are needed besides "-D PKG_USER-NETCDF=yes".
This should auto-detect the NETCDF library if it is installed on your
system at standard locations. Several advanced CMake NETCDF options
@ -1133,7 +1134,7 @@ USER-OMP package
**CMake build**\ :
No additional settings are required besides "-D PKG\_USER-OMP=yes". If
No additional settings are required besides "-D PKG_USER-OMP=yes". If
CMake detects OpenMP support, the USER-OMP code will be compiled with
multi-threading support enabled, otherwise as optimized serial code.
@ -1246,14 +1247,14 @@ lib/quip/README file for details on how to do this.
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
CMake will not download and build the QUIP library. But once you have
done that, a CMake build of LAMMPS with "-D PKG\_USER-QUIP=yes" should
work. Set QUIP\_LIBRARY if CMake cannot find the QUIP library.
done that, a CMake build of LAMMPS with "-D PKG_USER-QUIP=yes" should
work. Set QUIP_LIBRARY if CMake cannot find the QUIP library.
**Traditional make**\ :
The download/build procedure for the QUIP library, described in
lib/quip/README file requires setting two environment variables,
QUIP\_ROOT and QUIP\_ARCH. These are accessed by the
QUIP_ROOT and QUIP_ARCH. These are accessed by the
lib/quip/Makefile.lammps file which is used when you compile and link
LAMMPS with this package. You should only need to edit
Makefile.lammps if the LAMMPS build can not use its settings to
@ -1278,11 +1279,11 @@ To build with this package, you must download and build the `ScaFaCoS Coulomb so
-D SCAFACOS_LIBRARY=path # ScaFaCos library file (only needed if at custom location)
-D SCAFACOS_INCLUDE_DIR=path # ScaFaCoS include directory (only needed if at custom location)
If DOWNLOAD\_SCAFACOS is set, the ScaFaCoS library will be downloaded
If DOWNLOAD_SCAFACOS is set, the ScaFaCoS library will be downloaded
and built inside the CMake build directory. If the ScaFaCoS library
is already on your system (in a location CMake cannot find it),
SCAFACOS\_LIBRARY is the filename (plus path) of the ScaFaCoS library
file, not the directory the library file is in. SCAFACOS\_INCLUDE\_DIR
SCAFACOS_LIBRARY is the filename (plus path) of the ScaFaCoS library
file, not the directory the library file is in. SCAFACOS_INCLUDE_DIR
is the directory the ScaFaCoS include file is in.
**Traditional make**\ :
@ -1319,9 +1320,9 @@ Eigen3 is a template library, so you do not need to build it.
-D DOWNLOAD_EIGEN3 # download Eigen3, value = no (default) or yes
-D EIGEN3_INCLUDE_DIR=path # path to Eigen library (only needed if a custom location)
If DOWNLOAD\_EIGEN3 is set, the Eigen3 library will be downloaded and
If DOWNLOAD_EIGEN3 is set, the Eigen3 library will be downloaded and
inside the CMake build directory. If the Eigen3 library is already on
your system (in a location CMake cannot find it), EIGEN3\_INCLUDE\_DIR
your system (in a location CMake cannot find it), EIGEN3_INCLUDE_DIR
is the directory the Eigen3++ include file is in.
**Traditional make**\ :
@ -1354,7 +1355,7 @@ your system.
**CMake build**\ :
No additional settings are needed besides "-D PKG\_USER-VTK=yes".
No additional settings are needed besides "-D PKG_USER-VTK=yes".
This should auto-detect the VTK library if it is installed on your
system at standard locations. Several advanced VTK options exist if

12
doc/src/Build_link.rst
View File

@ -11,7 +11,7 @@ The :doc:`Build basics <Build_basics>` doc page explains how to build
LAMMPS as either a shared or static library. This results in one of
these 2 files:
.. parsed-literal::
.. code-block:: bash
liblammps.so # shared library
liblammps.a # static library
@ -25,7 +25,7 @@ these 2 files:
then its mpi.h file needs to be included. While it is technically
possible to use a full MPI library in the calling code and link to
a serial LAMMPS library compiled with MPI STUBS, it is recommended
to use the *same* MPI library for both, and then use MPI\_Comm\_split()
to use the *same* MPI library for both, and then use MPI_Comm_split()
in the calling code to pass a suitable communicator with a subset
of MPI ranks to the function creating the LAMMPS instance.
@ -43,7 +43,7 @@ executable code from the library is copied into the calling executable.
*CMake build*\ :
This assumes that LAMMPS has been configured with "-D BUILD_LIB=yes"
and installed with "make install" and the PKG\_CONFIG\_PATH environment
and installed with "make install" and the PKG_CONFIG_PATH environment
variable updated to include the *liblammps.pc* file installed into the
configured destination folder, if needed. The commands to compile and
link the coupled executable are then:
@ -167,7 +167,7 @@ traditional make build using "make mode=shlib serial" becomes:
However, now the `liblammps.so` file is required at runtime and needs
to be in a folder, where the shared linker program of the operating
system can find it. This would be either a folder like "/usr/local/lib64"
or "${HOME}/.local/lib64" or a folder pointed to by the LD\_LIBRARY\_PATH
or "${HOME}/.local/lib64" or a folder pointed to by the LD_LIBRARY_PATH
environment variable. You can type
.. code-block:: bash
@ -177,7 +177,7 @@ environment variable. You can type
to see what directories are in that list.
Or you can add the LAMMPS src directory (or the directory you performed
a CMake style build in) to your LD\_LIBRARY\_PATH, so that the current
a CMake style build in) to your LD_LIBRARY_PATH, so that the current
version of the shared library is always available to programs that use it.
For the Bourne or Korn shells (/bin/sh, /bin/ksh, /bin/bash etc.), you
@ -229,7 +229,7 @@ If a required library is missing, you would get a 'not found' entry:
Either flavor of library (static or shared) allows one or more LAMMPS
objects to be instantiated from the calling program. When used from a
C++ program, most of the symbols and functions in LAMMPS are wrapped
in a LAMMPS\_NS namespace; you can safely use any of its classes and
in a LAMMPS_NS namespace; you can safely use any of its classes and
methods from within the calling code, as needed, and you will not incur
conflicts with functions and variables in your code that share the name.
This, however, does not extend to all additional libraries bundled with

4
doc/src/Build_make.rst
View File

@ -31,7 +31,7 @@ machines, especially workstations, desktops, and laptops, so we suggest
you try it first when building LAMMPS in those cases.
The commands below perform a default LAMMPS build, producing the LAMMPS
executable lmp\_serial and lmp\_mpi in lammps/src:
executable lmp_serial and lmp_mpi in lammps/src:
.. code-block:: bash
@ -73,7 +73,7 @@ in the LAMMPS distribution. Typing "make machine" uses
use Makefile.serial and Makefile.mpi, respectively. Other makefiles
are in these directories:
.. parsed-literal::
.. code-block:: bash
OPTIONS # Makefiles which enable specific options
MACHINES # Makefiles for specific machines

20
doc/src/Build_package.rst
View File

@ -47,13 +47,13 @@ versus make.
**CMake build**\ :
.. code-block:: bash
.. code-block:: csh
-D PKG_NAME=value # yes or no (default)
Examples:
.. code-block:: bash
.. code-block:: csh
-D PKG_MANYBODY=yes
-D PKG_USER-INTEL=yes
@ -185,7 +185,7 @@ one of them as a starting point and customize it to your needs.
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.
Just type ``make`` in lammps/src to see a one-line summary.
These commands install/un-install sets of packages:
@ -202,8 +202,8 @@ 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
package" will list all the these commands.
which install/un-install various sets of packages. Typing ``make
package`` will list all the these commands.
.. note::
@ -220,23 +220,23 @@ need to use these commands unless you are editing LAMMPS files or are
:doc:`installing a patch <Install_patch>` downloaded from the LAMMPS web
site.
Type "make package-status" or "make ps" to show which packages are
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.
Type "make package-installed" or "make pi" to show which packages are
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
Type ``make package-update`` or ``make pu`` to overwrite src files with
files from the package sub-directories if the package is installed.
It should be used after a :doc:`patch has been applied <Install_patch>`,
since patches only update the files in the package sub-directory, but
not the src files.
Type "make package-overwrite" to overwrite files in the package
Type ``make package-overwrite`` to overwrite files in the package
sub-directories with src files.
Type "make package-diff" to list all differences between pairs of
Type ``make package-diff`` to list all differences between pairs of
files in both the source directory and the package directory.

43
doc/src/Build_settings.rst
View File

@ -85,7 +85,7 @@ to assist:
FFT_INC = -DFFT_MKL_THREADS # enable using threaded FFTs with MKL libraries
FFT_INC = -DFFT_PACK_ARRAY # or -DFFT_PACK_POINTER or -DFFT_PACK_MEMCPY
# default is FFT\_PACK\_ARRAY if not specified
# default is FFT_PACK_ARRAY if not specified
.. code-block:: make
@ -100,9 +100,9 @@ to assist:
FFT_LIB = -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core # MKL with GNU compiler, threaded interface
FFT_LIB = -lmkl_rt # MKL with automatic runtime selection of interface libs
As with CMake, you do not need to set paths in FFT\_INC or FFT\_PATH, if
As with CMake, you do not need to set paths in ``FFT_INC`` or ``FFT_PATH``, if
the compiler can find the FFT header and library files in its default search path.
You must specify FFT\_LIB with the appropriate FFT libraries to include in the link.
You must specify ``FFT_LIB`` with the appropriate FFT libraries to include in the link.
**CMake and make info**\ :
@ -126,14 +126,15 @@ 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.
Building FFTW for your box should be as simple as ./configure; make;
make install. The install command typically requires root privileges
Building FFTW for your box should be as simple as ``./configure; make;
make install``\ . The install command typically requires root privileges
(e.g. invoke it via sudo), unless you specify a local directory with
the "--prefix" option of configure. Type "./configure --help" to see
the "--prefix" option of configure. Type ``./configure --help`` to see
various options.
The Intel MKL math library is part of the Intel compiler suite. It
can be used with the Intel or GNU compiler (see FFT\_LIB setting above).
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
@ -142,15 +143,15 @@ 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
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.
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
library libfftw3f.a or libfftw3f.so.
library ``libfftw3f.a`` or ``libfftw3f.so``\ .
.. code-block:: bash
@ -159,7 +160,7 @@ library libfftw3f.a or libfftw3f.so.
Performing 3d FFTs requires communication to transpose the 3d FFT
grid. The data packing/unpacking for this can be done in one of 3
modes (ARRAY, POINTER, MEMCPY) as set by the FFT\_PACK syntax above.
modes (ARRAY, POINTER, MEMCPY) as set by the FFT_PACK syntax above.
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.
@ -187,7 +188,8 @@ adequate.
LMP_INC = -DLAMMPS_SMALLBIG # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL
# default is LAMMPS\_SMALLBIG if not specified
The default setting is ``-DLAMMPS_SMALLBIG`` if nothing is specified
**CMake and make info**\ :
The default "smallbig" setting allows for simulations with:
@ -235,7 +237,7 @@ than crashing randomly or corrupting data.
Also note that the GPU package requires its lib/gpu library to be
compiled with the same size setting, or the link will fail. A CMake
build does this automatically. When building with make, the setting
in whichever lib/gpu/Makefile is used must be the same as above.
in whichever ``lib/gpu/Makefile`` is used must be the same as above.
----------
@ -286,15 +288,16 @@ variables:
JPG_PATH = -L/usr/lib # paths to libjpeg.a, libpng.a, libz.a (.so) files if make cannot find them
JPG_LIB = -ljpeg -lpng -lz # library names
As with CMake, you do not need to set JPG\_INC or JPG\_PATH, if make can
find the graphics header and library files. You must specify JPG\_LIB
As with CMake, you do not need to set ``JPG_INC`` or ``JPG_PATH``,
if make can find the graphics header and library files. You must
specify ``JPG_LIB``
with a list of graphics libraries to include in the link. You must
insure ffmpeg is in a directory where LAMMPS can find it at runtime,
that is a directory in your PATH environment variable.
**CMake and make info**\ :
Using ffmpeg to output movie files requires that your machine
Using ``ffmpeg`` to output movie files requires that your machine
supports the "popen" function in the standard runtime library.
.. note::
@ -351,7 +354,7 @@ found by LAMMPS during a run.
Memory allocation alignment
---------------------------------------
This setting enables the use of the posix\_memalign() call instead of
This setting enables the use of the posix_memalign() call instead of
malloc() when LAMMPS allocates large chunks or memory. This can make
vector instructions on CPUs more efficient, if dynamically allocated
memory is aligned on larger-than-default byte boundaries.
@ -366,7 +369,7 @@ aligned on 64-byte boundaries.
-D LAMMPS_MEMALIGN=value # 0, 8, 16, 32, 64 (default)
Use a LAMMPS\_MEMALIGN value of 0 to disable using posix\_memalign()
Use a ``LAMMPS_MEMALIGN`` value of 0 to disable using posix_memalign()
and revert to using the malloc() C-library function instead. When
compiling LAMMPS for Windows systems, malloc() will always be used
and this setting ignored.
@ -377,8 +380,8 @@ and this setting ignored.
LMP_INC = -DLAMMPS_MEMALIGN=value # 8, 16, 32, 64
Do not set -DLAMMPS\_MEMALIGN, if you want to have memory allocated
with the malloc() function call instead. -DLAMMPS\_MEMALIGN **cannot**
Do not set ``-DLAMMPS_MEMALIGN``, if you want to have memory allocated
with the malloc() function call instead. ``-DLAMMPS_MEMALIGN`` **cannot**
be used on Windows, as it does use different function calls for
allocating aligned memory, that are not compatible with how LAMMPS
manages its dynamical memory.

4
doc/src/Build_windows.rst
View File

@ -55,8 +55,8 @@ and the corresponding new code. A machine makefile for using cygwin for
the old build system is provided. Using CMake for this mode of compilation
is untested and not likely to work.
When compiling for Windows do **not** set the -DLAMMPS\_MEMALIGN define
in the LMP\_INC makefile variable and add -lwsock32 -lpsapi to the linker
When compiling for Windows do **not** set the -DLAMMPS_MEMALIGN define
in the LMP_INC makefile variable and add -lwsock32 -lpsapi to the linker
flags in LIB makefile variable. Try adding -static-libgcc or -static or
both to the linker flags when your resulting LAMMPS Windows executable
complains about missing .dll files. The CMake configuration should set

2
doc/src/Commands_input.rst
View File

@ -46,7 +46,7 @@ is to have the desired effect. For example, the
:doc:`read_data <read_data>` command initializes the system by setting
up the simulation box and assigning atoms to processors. If default
values are not desired, the :doc:`processors <processors>` and
:doc:`boundary <boundary>` commands need to be used before read\_data to
:doc:`boundary <boundary>` commands need to be used before read_data to
tell LAMMPS how to map processors to the simulation box.
Many input script errors are detected by LAMMPS and an ERROR or

2
doc/src/Commands_parse.rst
View File

@ -101,7 +101,7 @@ LAMMPS:
print "B2 = ${b$a}"
Nor can you specify an expression like "$($x-1.0)" for an immediate
variable, but you could use $(v\_x-1.0), since the latter is valid
variable, but you could use $(v_x-1.0), since the latter is valid
syntax for an :doc:`equal-style variable <variable>`.
See the :doc:`variable <variable>` command for more details of how

4
doc/src/Errors_common.rst
View File

@ -69,14 +69,14 @@ but a floating-point number 1.0 is provided):
Some commands allow for using variable references in place of numeric
constants so that the value can be evaluated and may change over the
course of a run. This is typically done with the syntax *v\_name* for a
course of a run. This is typically done with the syntax *v_name* for a
parameter, where name is the name of the variable. On the other hand,
immediate variable expansion with the syntax ${name} is performed while
reading the input and before parsing commands,
.. note::
Using a variable reference (i.e. *v\_name*) is only allowed if
Using a variable reference (i.e. *v_name*) is only allowed if
the documentation of the corresponding command explicitly says it is.
Otherwise, you will receive an error message of this kind:

1080
doc/src/Errors_messages.rst
View File

File diff suppressed because it is too large Load Diff

102
doc/src/Errors_warnings.rst
View File

@ -37,7 +37,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*Angles are defined but no angle style is set*
The topology contains angles, but there are no angle forces computed
since there was no angle\_style command.
since there was no angle_style command.
*Atom style in data file differs from currently defined atom style*
Self-explanatory.
@ -62,7 +62,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*Bonds are defined but no bond style is set*
The topology contains bonds, but there are no bond forces computed
since there was no bond\_style command.
since there was no bond_style command.
*Bond/angle/dihedral extent > half of periodic box length*
This is a restriction because LAMMPS can be confused about which image
@ -83,8 +83,8 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero*
Self-explanatory.
*Calling write\_dump before a full system init.*
The write\_dump command is used before the system has been fully
*Calling write_dump before a full system init.*
The write_dump command is used before the system has been fully
initialized as part of a 'run' or 'minimize' command. Not all dump
styles and features are fully supported at this point and thus the
command may fail or produce incomplete or incorrect output. Insert
@ -131,11 +131,11 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
degrees-of-freedom for the atoms in those partial rigid bodies will
not be accounted for.
*Create\_bonds max distance > minimum neighbor cutoff*
*Create_bonds max distance > minimum neighbor cutoff*
This means atom pairs for some atom types may not be in the neighbor
list and thus no bond can be created between them.
*Delete\_atoms cutoff > minimum neighbor cutoff*
*Delete_atoms cutoff > minimum neighbor cutoff*
This means atom pairs for some atom types may not be in the neighbor
list and thus an atom in that pair cannot be deleted.
@ -158,7 +158,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*Dihedrals are defined but no dihedral style is set*
The topology contains dihedrals, but there are no dihedral forces computed
since there was no dihedral\_style command.
since there was no dihedral_style command.
*Dump dcd/xtc timestamp may be wrong with fix dt/reset*
If the fix changes the timestep, the dump dcd file will not
@ -172,7 +172,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*Estimated error in splitting of dispersion coeffs is %g*
Error is greater than 0.0001 percent.
*Ewald/disp Newton solver failed, using old method to estimate g\_ewald*
*Ewald/disp Newton solver failed, using old method to estimate g_ewald*
Self-explanatory. Choosing a different cutoff value may help.
*FENE bond too long*
@ -209,8 +209,8 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
This is probably an error, since you should not delete only one atom
of a molecule.
*Fix gcmc using full\_energy option*
Fix gcmc has automatically turned on the full\_energy option since it
*Fix gcmc using full_energy option*
Fix gcmc has automatically turned on the full_energy option since it
is required for systems like the one specified by the user. User input
included one or more of the following: kspace, triclinic, a hybrid
pair style, an eam pair style, or no "single" function for the pair
@ -265,19 +265,19 @@ This will most likely cause errors in kinetic fluctuations.
*Fixes cannot send data in Kokkos communication, switching to classic communication*
This is current restriction with Kokkos.
*For better accuracy use 'pair\_modify table 0'*
*For better accuracy use 'pair_modify table 0'*
The user-specified force accuracy cannot be achieved unless the table
feature is disabled by using 'pair\_modify table 0'.
feature is disabled by using 'pair_modify table 0'.
*Geometric mixing assumed for 1/r\^6 coefficients*
Self-explanatory.
*Group for fix\_modify temp != fix group*
The fix\_modify command is specifying a temperature computation that
*Group for fix_modify temp != fix group*
The fix_modify command is specifying a temperature computation that
computes a temperature on a different group of atoms than the fix
itself operates on. This is probably not what you want to do.
*H matrix size has been exceeded: m\_fill=%d H.m=%d\n*
*H matrix size has been exceeded: m_fill=%d H.m=%d\n*
This is the size of the matrix.
*Ignoring unknown or incorrect info command flag*
@ -299,7 +299,7 @@ This will most likely cause errors in kinetic fluctuations.
*Impropers are defined but no improper style is set*
The topology contains impropers, but there are no improper forces computed
since there was no improper\_style command.
since there was no improper_style command.
*Inconsistent image flags*
The image flags for a pair on bonded atoms appear to be inconsistent.
@ -334,22 +334,22 @@ This will most likely cause errors in kinetic fluctuations.
*KIM Model does not provide 'particleVirial'; virial per atom will be zero*
Self-explanatory.
*Kspace\_modify slab param < 2.0 may cause unphysical behavior*
The kspace\_modify slab parameter should be larger to insure periodic
*Kspace_modify slab param < 2.0 may cause unphysical behavior*
The kspace_modify slab parameter should be larger to insure periodic
grids padded with empty space do not overlap.
*Less insertions than requested*
The fix pour command was unsuccessful at finding open space
for as many particles as it tried to insert.
*Library error in lammps\_gather\_atoms*
*Library error in lammps_gather_atoms*
This library function cannot be used if atom IDs are not defined
or are not consecutively numbered.
*Library error in lammps\_scatter\_atoms*
*Library error in lammps_scatter_atoms*
This library function cannot be used if atom IDs are not defined or
are not consecutively numbered, or if no atom map is defined. See the
atom\_modify command for details about atom maps.
atom_modify command for details about atom maps.
*Likewise 1-2 special neighbor interactions != 1.0*
The topology contains bonds, but there is no bond style defined
@ -372,15 +372,15 @@ This will most likely cause errors in kinetic fluctuations.
pairs in the neighbor list in expectation of interactions for
those pairs being computed from the dihedral style.
*Lost atoms via change\_box: original %ld current %ld*
*Lost atoms via change_box: original %ld current %ld*
The command options you have used caused atoms to be lost.
*Lost atoms via displace\_atoms: original %ld current %ld*
*Lost atoms via displace_atoms: original %ld current %ld*
The command options you have used caused atoms to be lost.
*Lost atoms: original %ld current %ld*
Lost atoms are checked for each time thermo output is done. See the
thermo\_modify lost command for options. Lost atoms usually indicate
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
reneighboring.
@ -403,8 +403,8 @@ This will most likely cause errors in kinetic fluctuations.
This means the bonded atoms will not be excluded in pair-wise
interactions.
*Molecule template for create\_atoms has multiple molecules*
The create\_atoms command will only create molecules of a single type,
*Molecule template for create_atoms has multiple molecules*
The create_atoms command will only create molecules of a single type,
i.e. the first molecule in the template.
*Molecule template for fix gcmc has multiple molecules*
@ -469,21 +469,21 @@ 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 insuring
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
neigh\_modify exclude command.
neigh_modify exclude command.
*New thermo\_style command, previous thermo\_modify settings will be lost*
If a thermo\_style command is used after a thermo\_modify command, the
settings changed by the thermo\_modify command will be reset to their
default values. This is because the thermo\_modify command acts on
the currently defined thermo style, and a thermo\_style command creates
*New thermo_style command, previous thermo_modify settings will be lost*
If a thermo_style command is used after a thermo_modify command, the
settings changed by the thermo_modify command will be reset to their
default values. This is because the thermo_modify command acts on
the currently defined thermo style, and a thermo_style command creates
a new style.
*No Kspace calculation with verlet/split*
The 2nd partition performs a kspace calculation so the kspace\_style
The 2nd partition performs a kspace calculation so the kspace_style
command must be used.
*No automatic unit conversion to XTC file format conventions possible for units lj*
@ -507,7 +507,7 @@ This will most likely cause errors in kinetic fluctuations.
of two and the number of grid points in one or more directions have been
adjusted to meet this requirement.
*OMP\_NUM\_THREADS environment is not set.*
*OMP_NUM_THREADS environment is not set.*
This environment variable must be set appropriately to use the
USER-OMP package.
@ -541,10 +541,10 @@ This will most likely cause errors in kinetic fluctuations.
*Pair dpd needs newton pair on for momentum conservation*
Self-explanatory.
*Pair dsmc: num\_of\_collisions > number\_of\_A*
*Pair dsmc: num_of_collisions > number_of_A*
Collision model in DSMC is breaking down.
*Pair dsmc: num\_of\_collisions > number\_of\_B*
*Pair dsmc: num_of_collisions > number_of_B*
Collision model in DSMC is breaking down.
*Pair style in data file differs from currently defined pair style*
@ -569,15 +569,15 @@ This will most likely cause errors in kinetic fluctuations.
sub-domain 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
This may lead to a larger grid than desired. See the kspace_modify overlap
command to prevent changing of the PPPM order.
*Reducing PPPMDisp Coulomb order b/c stencil extends beyond neighbor processor*
This may lead to a larger grid than desired. See the kspace\_modify overlap
This may lead to a larger grid than desired. See the kspace_modify overlap
command to prevent changing of the PPPM order.
*Reducing PPPMDisp dispersion order b/c stencil extends beyond neighbor processor*
This may lead to a larger grid than desired. See the kspace\_modify overlap
This may lead to a larger grid than desired. See the kspace_modify overlap
command to prevent changing of the PPPM order.
*Replacing a fix, but new group != old group*
@ -590,19 +590,19 @@ This will most likely cause errors in kinetic fluctuations.
dimension to be replicated; this may cause unwanted behavior.
*Resetting reneighboring criteria during PRD*
A PRD simulation requires that neigh\_modify settings be delay = 0,
A PRD simulation requires that neigh_modify settings be delay = 0,
every = 1, check = yes. Since these settings were not in place,
LAMMPS changed them and will restore them to their original values
after the PRD simulation.
*Resetting reneighboring criteria during TAD*
A TAD simulation requires that neigh\_modify settings be delay = 0,
A TAD simulation requires that neigh_modify settings be delay = 0,
every = 1, check = yes. Since these settings were not in place,
LAMMPS changed them and will restore them to their original values
after the PRD simulation.
*Resetting reneighboring criteria during minimization*
Minimization requires that neigh\_modify settings be delay = 0, every =
Minimization requires that neigh_modify settings be delay = 0, every =
1, check = yes. Since these settings were not in place, LAMMPS
changed them and will restore them to their original values after the
minimization.
@ -706,7 +706,7 @@ This will most likely cause errors in kinetic fluctuations.
which does operate on group all, so this may be inconsistent.
*Temperature for thermo pressure is not for group all*
User-assigned temperature to thermo via the thermo\_modify command does
User-assigned temperature to thermo via the thermo_modify command does
not compute temperature for all atoms. Since thermo computes a global
pressure, the kinetic energy contribution from the temperature is
assumed to also be for all atoms. Thus the pressure printed by thermo
@ -738,12 +738,12 @@ This will most likely cause errors in kinetic fluctuations.
LAMMPS simulation may be inefficient as a result.
*Use special bonds = 0,1,1 with bond style fene*
Most FENE models need this setting for the special\_bonds command.
Most FENE models need this setting for the special_bonds command.
*Use special bonds = 0,1,1 with bond style fene/expand*
Most FENE models need this setting for the special\_bonds command.
Most FENE models need this setting for the special_bonds command.
*Using a many-body potential with bonds/angles/dihedrals and special\_bond exclusions*
*Using a many-body potential with bonds/angles/dihedrals and special_bond exclusions*
This is likely not what you want to do. The exclusion settings will
eliminate neighbors in the neighbor list, which the many-body potential
needs to calculated its terms correctly.
@ -772,13 +772,13 @@ This will most likely cause errors in kinetic fluctuations.
*Using largest cutoff for lj/long/coul/long*
Self-explanatory.
*Using largest cutoff for pair\_style lj/long/tip4p/long*
*Using largest cutoff for pair_style lj/long/tip4p/long*
Self-explanatory.
*Using package gpu without any pair style defined*
Self-explanatory.
*Using pair potential shift with pair\_modify compute no*
*Using pair potential shift with pair_modify compute no*
The shift effects will thus not be computed.
*Using pair tail corrections with nonperiodic system*
@ -786,8 +786,8 @@ This will most likely cause errors in kinetic fluctuations.
computed by integrating the density of a periodic system out to
infinity.
*Using pair tail corrections with pair\_modify compute no*
*Using pair tail corrections with pair_modify compute no*
The tail corrections will thus not be computed.
*pair style reax is now deprecated and will soon be retired. Users should switch to pair\_style reax/c*
*pair style reax is now deprecated and will soon be retired. Users should switch to pair_style reax/c*
Self-explanatory.

14
doc/src/Examples.rst
View File

@ -132,7 +132,7 @@ Lowercase directories
+-------------+------------------------------------------------------------------+
| reax | RDX and TATB models using the ReaxFF |
+-------------+------------------------------------------------------------------+
| rerun | use of rerun and read\_dump commands |
| rerun | use of rerun and read_dump commands |
+-------------+------------------------------------------------------------------+
| rigid | rigid bodies modeled as independent or coupled |
+-------------+------------------------------------------------------------------+
@ -155,7 +155,7 @@ Lowercase directories
Here is how you can run and visualize one of the sample problems:
.. parsed-literal::
.. code-block:: bash
cd indent
cp ../../src/lmp_linux . # copy LAMMPS executable to this dir
@ -170,16 +170,16 @@ web site.
If you uncomment the :doc:`dump image <dump_image>` line(s) in the input
script a series of JPG images will be produced by the run (assuming
you built LAMMPS with JPG support; see the
:doc:`Build\_settings <Build_settings>` doc page for details). These can
:doc:`Build_settings <Build_settings>` doc page for details). These can
be viewed individually or turned into a movie or animated by tools
like ImageMagick or QuickTime or various Windows-based tools. See the
:doc:`dump image <dump_image>` doc page for more details. E.g. this
Imagemagick command would create a GIF file suitable for viewing in a
browser.
.. parsed-literal::
.. code-block:: bash
% convert -loop 1 \*.jpg foo.gif
% convert -loop 1 *.jpg foo.gif
----------
@ -195,7 +195,7 @@ Uppercase directories
+------------+--------------------------------------------------------------------------------------------------+
| ELASTIC | compute elastic constants at zero temperature |
+------------+--------------------------------------------------------------------------------------------------+
| ELASTIC\_T | compute elastic constants at finite temperature |
| ELASTIC_T | compute elastic constants at finite temperature |
+------------+--------------------------------------------------------------------------------------------------+
| HEAT | compute thermal conductivity for LJ and water via fix ehex |
+------------+--------------------------------------------------------------------------------------------------+
@ -219,7 +219,7 @@ The USER directory has a large number of sub-directories which
correspond by name to a USER package. They contain scripts that
illustrate how to use the command(s) provided in that package. Many
of the sub-directories have their own README files which give further
instructions. See the :doc:`Packages\_details <Packages_details>` doc
instructions. See the :doc:`Packages_details <Packages_details>` doc
page for more info on specific USER packages.
.. _openkim: https://openkim.org

4
doc/src/Howto_2d.rst
View File

@ -8,7 +8,7 @@ command. This is the default.
If using the :doc:`create box <create_box>` command to define a
simulation box, set the z dimensions narrow, but finite, so that the
create\_atoms command will tile the 3d simulation box with a single z
create_atoms command will tile the 3d simulation box with a single z
plane of atoms - e.g.
.. code-block:: LAMMPS
@ -17,7 +17,7 @@ plane of atoms - e.g.
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
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.

12
doc/src/Howto_bash.rst
View File

@ -147,7 +147,7 @@ Compiling serial version
cd src/
make -j 4 serial
This will create an executable called lmp\_serial in the src/ directory
This will create an executable called lmp_serial in the src/ directory
Compiling MPI version
"""""""""""""""""""""
@ -157,7 +157,7 @@ Compiling MPI version
cd src/
make -j 4 mpi
This will create an executable called lmp\_mpi in the src/ directory
This will create an executable called lmp_mpi in the src/ directory
----------
@ -192,8 +192,8 @@ examples/melt folder
cd ../examples/melt
The full path of the serial executable is $LAMMPS\_DIR/lmp\_serial, while the mpi
version is $LAMMPS\_DIR/lmp\_mpi. You can run the melt example with either
The full path of the serial executable is $LAMMPS_DIR/lmp_serial, while the mpi
version is $LAMMPS_DIR/lmp_mpi. You can run the melt example with either
version as follows:
.. code-block:: bash
@ -206,7 +206,7 @@ or
mpirun -np 4 $LAMMPS_DIR/lmp_mpi -in in.melt
Note the use of our variable $LAMMPS\_DIR, which expands into the full path of
Note the use of our variable $LAMMPS_DIR, which expands into the full path of
the LAMMPS src folder we saved earlier.
Adding your executable directory to your PATH
@ -241,7 +241,7 @@ and add this line
**Example:**
For an executable lmp\_serial with a full path
For an executable lmp_serial with a full path
.. code-block:: bash

10
doc/src/Howto_body.rst
View File

@ -112,7 +112,7 @@ vanilla, prototypical example of a body particle, although as
mentioned above, the :doc:`fix rigid <fix_rigid>` command already
duplicates its functionality.
The atom\_style body command for this body style takes two additional
The atom_style body command for this body style takes two additional
arguments:
.. parsed-literal::
@ -188,14 +188,14 @@ The *bflag2* argument is ignored.
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" doc page for a diagram of two
"pair_style body/rounded/polygon" doc 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>`.
Similar to body style *nparticle*\ , the atom\_style body command for
Similar to body style *nparticle*\ , the atom_style body command for
this body style takes two additional arguments:
.. parsed-literal::
@ -301,7 +301,7 @@ body particles with a wall.
The *rounded/polyhedron* body style represents body particles as a 3d
polyhedron with a variable number of N vertices, E edges and F faces.
This style can only be used for 3d models; see the
:doc:`boundary <boundary>` command. See the "pair\_style
:doc:`boundary <boundary>` command. See the "pair_style
body/rounded/polygon" doc page for a diagram of a two 2d squares with
rounded circles at the vertices. A 3d cube with rounded spheres at
the 8 vertices and 12 rounded edges would be similar. Special cases
@ -311,7 +311,7 @@ specified.
This body style is for 3d discrete element models, as described in
:ref:`Wang <body-Wang>`.
Similar to body style *rounded/polygon*\ , the atom\_style body command
Similar to body style *rounded/polygon*\ , the atom_style body command
for this body style takes two additional arguments:
.. parsed-literal::

12
doc/src/Howto_client_server.rst
View File

@ -93,22 +93,22 @@ client or server code:
* examples/message
* examples/COUPLE/README
* examples/COUPLE/lammps\_mc
* examples/COUPLE/lammps\_nwchem
* examples/COUPLE/lammps\_vasp
* examples/COUPLE/lammps_mc
* examples/COUPLE/lammps_nwchem
* examples/COUPLE/lammps_vasp
The examples/message directory couples a client instance of LAMMPS to a
server instance of LAMMPS.
The files in the *lammps\_mc* folder show how to couple LAMMPS as
The files in the *lammps_mc* folder show how to couple LAMMPS as
a server to a simple Monte Carlo client code as the driver.
The files in the *lammps\_nwchem* folder show how to couple LAMMPS
The files in the *lammps_nwchem* folder show how to couple LAMMPS
as a client code running MD timestepping to NWChem acting as a
server providing quantum DFT forces, through a Python wrapper script
on NWChem.
The files in the *lammps\_vasp* folder show how to couple LAMMPS as
The files in the *lammps_vasp* folder show how to couple LAMMPS as
a client code running MD timestepping to VASP acting as a server
providing quantum DFT forces, through a Python wrapper script on VASP.

6
doc/src/Howto_couple.rst
View File

@ -64,9 +64,9 @@ examples/COUPLE/README for more details:
library
* plugin: simple driver program in C which invokes LAMMPS as a plugin
from a shared library.
* lammps\_quest: coupling of LAMMPS and `Quest <quest_>`_, to run classical
* lammps_quest: coupling of LAMMPS and `Quest <quest_>`_, to run classical
MD with quantum forces calculated by a density functional code
* lammps\_spparks: coupling of LAMMPS and `SPPARKS <spparks_>`_, to couple
* lammps_spparks: coupling of LAMMPS and `SPPARKS <spparks_>`_, to couple
a kinetic Monte Carlo model for grain growth using MD to calculate
strain induced across grain boundaries
@ -89,7 +89,7 @@ The files src/library.cpp and library.h contain the C-style interface
to LAMMPS. See the :doc:`Howto library <Howto_library>` doc page for a
description of the interface and how to extend it for your needs.
Note that the lammps\_open() function that creates an instance of
Note that the lammps_open() function that creates an instance of
LAMMPS takes an MPI communicator as an argument. This means that
instance of LAMMPS will run on the set of processors in the
communicator. Thus the calling code can run LAMMPS on all or a subset

22
doc/src/Howto_dispersion.rst
View File

@ -29,7 +29,7 @@ that provide fast and accurate simulations, there are two approaches,
which both have their up- and downsides.
The first approach is to set desired real-space an kspace accuracies
via the *kspace\_modify force/disp/real* and *kspace\_modify
via the *kspace_modify force/disp/real* and *kspace_modify
force/disp/kspace* commands. Note that the accuracies have to be
specified in force units and are thus dependent on the chosen unit
settings. For real units, 0.0001 and 0.002 seem to provide reasonable
@ -37,14 +37,14 @@ accurate and efficient computations for the real-space and kspace
accuracies. 0.002 and 0.05 work well for most systems using lj
units. PPPM parameters will be generated based on the desired
accuracies. The upside of this approach is that it usually provides a
good set of parameters and will work for both the *kspace\_modify diff
ad* and *kspace\_modify diff ik* options. The downside of the method
good set of parameters and will work for both the *kspace_modify diff
ad* and *kspace_modify diff ik* options. The downside of the method
is that setting the PPPM parameters will take some time during the
initialization of the simulation.
The second approach is to set the parameters for the pppm/disp
explicitly using the *kspace\_modify mesh/disp*, *kspace\_modify
order/disp*, and *kspace\_modify gewald/disp* commands. This approach
explicitly using the *kspace_modify mesh/disp*, *kspace_modify
order/disp*, and *kspace_modify gewald/disp* commands. This approach
requires a more experienced user who understands well the impact of
the choice of parameters on the simulation accuracy and
performance. This approach provides a fast initialization of the
@ -60,12 +60,12 @@ To avoid inaccurate or inefficient simulations, the pppm/disp stops
simulations with an error message if no action is taken to control the
PPPM parameters. If the automatic parameter generation is desired and
real-space and kspace accuracies are desired to be equal, this error
message can be suppressed using the *kspace\_modify disp/auto yes*
message can be suppressed using the *kspace_modify disp/auto yes*
command.
A reasonable approach that combines the upsides of both methods is to
make the first run using the *kspace\_modify force/disp/real* and
*kspace\_modify force/disp/kspace* commands, write down the PPPM
make the first run using the *kspace_modify force/disp/real* and
*kspace_modify force/disp/kspace* commands, write down the PPPM
parameters from the output, and specify these parameters using the
second approach in subsequent runs (which have the same composition,
force field, and approximately the same volume).
@ -82,8 +82,8 @@ The second is that the mixing rule of the pair style has an impact on
the computation time when using the pppm/disp. Fastest computations
are achieved when using the geometric mixing rule. Using the
arithmetic mixing rule substantially increases the computational cost.
The computational overhead can be reduced using the *kspace\_modify
mix/disp geom* and *kspace\_modify splittol* commands. The first
The computational overhead can be reduced using the *kspace_modify
mix/disp geom* and *kspace_modify splittol* commands. The first
command simply enforces geometric mixing of the dispersion
coefficients in kspace computations. This introduces some error in
the computations but will also significantly speed-up the
@ -94,7 +94,7 @@ command, but will usually also not provide an equally good increase of
efficiency.
Finally, pppm/disp can also be used when no mixing rules apply.
This can be achieved using the *kspace\_modify mix/disp none* command.
This can be achieved using the *kspace_modify mix/disp none* command.
Note that the code does not check automatically whether any mixing
rule is fulfilled. If mixing rules do not apply, the user will have
to specify this command explicitly.

2
doc/src/Howto_drude.rst
View File

@ -48,7 +48,7 @@ for a Langevin thermostat, or :doc:`fix drude/transform/\* <fix_drude_transform>
thermostat. The former requires use of the command :doc:`comm_modify vel yes <comm_modify>`. The latter requires two separate integration
fixes like *nvt* or *npt*\ . The correct temperatures of the reduced
degrees of freedom can be calculated using the :doc:`compute temp/drude <compute_temp_drude>`. This requires also to use the
command *comm\_modify vel yes*.
command *comm_modify vel yes*.
Short-range damping of the induced dipole interactions can be achieved
using Thole functions through the :doc:`pair style thole <pair_thole>` in :doc:`pair_style hybrid/overlay <pair_hybrid>`

48
doc/src/Howto_drude2.rst
View File

@ -76,14 +76,14 @@ important features:
**Preparation of the data file**
The data file is similar to a standard LAMMPS data file for
*atom\_style full*. The DPs and the *harmonic bonds* connecting them
*atom_style full*. The DPs and the *harmonic bonds* connecting them
to their DC should appear in the data file as normal atoms and bonds.
You can use the *polarizer* tool (Python script distributed with the
USER-DRUDE package) to convert a non-polarizable data file (here
*data.102494.lmp*\ ) to a polarizable data file (\ *data-p.lmp*\ )
.. parsed-literal::
.. code-block:: bash
polarizer -q -f phenol.dff data.102494.lmp data-p.lmp
@ -159,9 +159,9 @@ Let us assume we want to run a simple NVT simulation at 300 K. Note
that Drude oscillators need to be thermalized at a low temperature in
order to approximate a self-consistent field (SCF), therefore it is not
possible to simulate an NVE ensemble with this package. Since dipoles
are approximated by a charged DC-DP pair, the *pair\_style* must
are approximated by a charged DC-DP pair, the *pair_style* must
include Coulomb interactions, for instance *lj/cut/coul/long* with
*kspace\_style pppm*. For example, with a cutoff of 10. and a precision
*kspace_style pppm*. For example, with a cutoff of 10. and a precision
1.e-4:
.. code-block:: LAMMPS
@ -169,9 +169,9 @@ include Coulomb interactions, for instance *lj/cut/coul/long* with
pair_style lj/cut/coul/long 10.0
kspace_style pppm 1.0e-4
As compared to the non-polarizable input file, *pair\_coeff* lines need
As compared to the non-polarizable input file, *pair_coeff* lines need
to be added for the DPs. Since the DPs have no Lennard-Jones
interactions, their :math:`\epsilon` is 0. so the only *pair\_coeff* line
interactions, their :math:`\epsilon` is 0. so the only *pair_coeff* line
that needs to be added is
.. code-block:: LAMMPS
@ -222,7 +222,7 @@ modification of forces but no position/velocity updates), the fix
fix NVE all nve
Finally, do not forget to update the atom type elements if you use
them in a *dump\_modify ... element ...* command, by adding the element
them in a *dump_modify ... element ...* command, by adding the element
type of the DPs. Here for instance
.. code-block:: LAMMPS
@ -232,19 +232,19 @@ type of the DPs. Here for instance
The input file should now be ready for use!
You will notice that the global temperature *thermo\_temp* computed by
You will notice that the global temperature *thermo_temp* computed by
LAMMPS is not 300. K as wanted. This is because LAMMPS treats DPs as
standard atoms in his default compute. If you want to output the
temperatures of the DC-DP pair centers of mass and of the DPs relative
to their DCs, you should use the :doc:`compute temp\_drude <compute_temp_drude>`
to their DCs, you should use the :doc:`compute temp_drude <compute_temp_drude>`
.. code-block:: LAMMPS
compute TDRUDE all temp/drude
And then output the correct temperatures of the Drude oscillators
using *thermo\_style custom* with respectively *c\_TDRUDE[1]* and
*c\_TDRUDE[2]*. These should be close to 300.0 and 1.0 on average.
using *thermo_style custom* with respectively *c_TDRUDE[1]* and
*c_TDRUDE[2]*. These should be close to 300.0 and 1.0 on average.
.. code-block:: LAMMPS
@ -263,8 +263,8 @@ between nearby dipoles on the same molecule may be exaggerated. Often,
special bond relations prevent bonded neighboring atoms to see the
charge of each other's DP, so that the problem does not always appear.
It is possible to use screened dipole-dipole interactions by using the
:doc:`*pair\_style thole* <pair_thole>`. This is implemented as a
correction to the Coulomb pair\_styles, which dampens at short distance
:doc:`*pair_style thole* <pair_thole>`. This is implemented as a
correction to the Coulomb pair_styles, which dampens at short distance
the interactions between the charges representing the induced dipoles.
It is to be used as *hybrid/overlay* with any standard *coul* pair
style. In our example, we would use
@ -273,15 +273,15 @@ style. In our example, we would use
pair_style hybrid/overlay lj/cut/coul/long 10.0 thole 2.6 10.0
This tells LAMMPS that we are using two pair\_styles. The first one is
This tells LAMMPS that we are using two pair_styles. The first one is
as above (\ *lj/cut/coul/long 10.0*\ ). The second one is a *thole*
pair\_style with default screening factor 2.6 (:ref:`Noskov <Noskov2>`) and
pair_style with default screening factor 2.6 (:ref:`Noskov <Noskov2>`) and
cutoff 10.0.
Since *hybrid/overlay* does not support mixing rules, the interaction
coefficients of all the pairs of atom types with i < j should be
explicitly defined. The output of the *polarizer* script can be used
to complete the *pair\_coeff* section of the input file. In our
to complete the *pair_coeff* section of the input file. In our
example, this will look like:
.. code-block:: LAMMPS
@ -324,17 +324,17 @@ For the *thole* pair style the coefficients are
#. the atom polarizability in units of cubic length
#. the screening factor of the Thole function (optional, default value
specified by the pair\_style command)
#. the cutoff (optional, default value defined by the pair\_style command)
specified by the pair_style command)
#. the cutoff (optional, default value defined by the pair_style command)
The special neighbors have charge-charge and charge-dipole
interactions screened by the *coul* factors of the *special\_bonds*
interactions screened by the *coul* factors of the *special_bonds*
command (0.0, 0.0, and 0.5 in the example above). Without using the
pair\_style *thole*\ , dipole-dipole interactions are screened by the
same factor. By using the pair\_style *thole*\ , dipole-dipole
pair_style *thole*\ , dipole-dipole interactions are screened by the
same factor. By using the pair_style *thole*\ , dipole-dipole
interactions are screened by Thole's function, whatever their special
relationship (except within each DC-DP pair of course). Consider for
example 1-2 neighbors: using the pair\_style *thole*\ , their dipoles
example 1-2 neighbors: using the pair_style *thole*\ , their dipoles
will see each other (despite the *coul* factor being 0.) and the
interactions between these dipoles will be damped by Thole's function.
@ -375,7 +375,7 @@ For our phenol example, the groups would be defined as
group DRUDES type 6 7 8 # DPs
Note that with the fixes *drude/transform*\ , it is not required to
specify *comm\_modify vel yes* because the fixes do it anyway (several
specify *comm_modify vel yes* because the fixes do it anyway (several
times and for the forces also). To avoid the flying ice cube artifact
:ref:`(Lamoureux) <Lamoureux2>`, where the atoms progressively freeze and the
center of mass of the whole system drifts faster and faster, the *fix
@ -392,7 +392,7 @@ DPs should be *nvt* (or vice versa). Second, the *fix npt* computes a
global pressure and thus a global temperature whatever the fix group.
We do want the pressure to correspond to the whole system, but we want
the temperature to correspond to the fix group only. We must then use
the *fix\_modify* command for this. In the end, the block of
the *fix_modify* command for this. In the end, the block of
instructions for thermostatting and barostatting will look like
.. code-block:: LAMMPS

14
doc/src/Howto_elastic.rst
View File

@ -4,14 +4,14 @@ Calculate elastic constants
Elastic constants characterize the stiffness of a material. The formal
definition is provided by the linear relation that holds between the
stress and strain tensors in the limit of infinitesimal deformation.
In tensor notation, this is expressed as s\_ij = C\_ijkl \* e\_kl, where
the repeated indices imply summation. s\_ij are the elements of the
symmetric stress tensor. e\_kl are the elements of the symmetric strain
tensor. C\_ijkl are the elements of the fourth rank tensor of elastic
In tensor notation, this is expressed as s_ij = C_ijkl \* e_kl, where
the repeated indices imply summation. s_ij are the elements of the
symmetric stress tensor. e_kl are the elements of the symmetric strain
tensor. C_ijkl are the elements of the fourth rank tensor of elastic
constants. In three dimensions, this tensor has 3\^4=81 elements. Using
Voigt notation, the tensor can be written as a 6x6 matrix, where C\_ij
is now the derivative of s\_i w.r.t. e\_j. Because s\_i is itself a
derivative w.r.t. e\_i, it follows that C\_ij is also symmetric, with at
Voigt notation, the tensor can be written as a 6x6 matrix, where C_ij
is now the derivative of s_i w.r.t. e_j. Because s_i is itself a
derivative w.r.t. e_i, it follows that C_ij is also symmetric, with at
most 7\*6/2 = 21 distinct elements.
At zero temperature, it is easy to estimate these derivatives by

8
doc/src/Howto_github.rst
View File

@ -287,10 +287,10 @@ After each push, the automated checks are run again.
LAMMPS developers may add labels to your pull request to assign it to
categories (mostly for bookkeeping purposes), but a few of them are
important: needs\_work, work\_in\_progress, test-for-regression, and
important: needs_work, work_in_progress, test-for-regression, and
full-regression-test. The first two indicate, that your pull request
is not considered to be complete. With "needs\_work" the burden is on
exclusively on you; while "work\_in\_progress" can also mean, that a
is not considered to be complete. With "needs_work" the burden is on
exclusively on you; while "work_in_progress" can also mean, that a
LAMMPS developer may want to 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
@ -458,7 +458,7 @@ should be submitted, there is now also an "unstable" and a "stable"
branch; these have the same content as "master", 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.
"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.

2
doc/src/Howto_granular.rst
View File

@ -22,7 +22,7 @@ Use one of these 3 pair potentials, which compute forces and torques
between interacting pairs of particles:
* :doc:`pair_style <pair_style>` gran/history
* :doc:`pair_style <pair_style>` gran/no\_history
* :doc:`pair_style <pair_style>` gran/no_history
* :doc:`pair_style <pair_style>` gran/hertzian
These commands implement fix options specific to granular systems:

2
doc/src/Howto_kappa.rst
View File

@ -56,7 +56,7 @@ two preceding non-equilibrium methods, where energy flows continuously
between hot and cold regions of the simulation box.
The :doc:`compute heat/flux <compute_heat_flux>` command can calculate
the needed heat flux and describes how to implement the Green\_Kubo
the needed heat flux and describes how to implement the Green_Kubo
formalism using additional LAMMPS commands, such as the :doc:`fix ave/correlate <fix_ave_correlate>` command to calculate the needed
auto-correlation. See the doc page for the :doc:`compute heat/flux <compute_heat_flux>` command for an example input script
that calculates the thermal conductivity of solid Ar via the GK

68
doc/src/Howto_library.rst
View File

@ -12,7 +12,7 @@ functions therein have a C-style argument list, but contain C++ code
you could write yourself in a C++ application that was invoking LAMMPS
directly. The C++ code in the functions illustrates how to invoke
internal LAMMPS operations. Note that LAMMPS classes are defined
within a LAMMPS namespace (LAMMPS\_NS) if you use them from another C++
within a LAMMPS namespace (LAMMPS_NS) if you use them from another C++
application.
The examples/COUPLE and python/examples directories have example C++
@ -34,7 +34,7 @@ interface LAMMPS to Fortran libraries, or the code uses static variables
Another major issue to deal with is to correctly handle MPI. Creating
a LAMMPS instance requires passing an MPI communicator, or it assumes
the MPI\_COMM\_WORLD communicator, which spans all MPI processor ranks.
the MPI_COMM_WORLD communicator, which spans all MPI processor ranks.
When creating multiple LAMMPS object instances from different threads,
this communicator has to be different for each thread or else collisions
can happen, or it has to be guaranteed, that only one thread at a time
@ -70,11 +70,11 @@ details.
void lammps_commands_string(void *, char *)
void lammps_free(void *)
The lammps\_open() function is used to initialize LAMMPS, passing in a
The lammps_open() function is used to initialize LAMMPS, passing in a
list of strings as if they were :doc:`command-line arguments <Run_options>` when LAMMPS is run in stand-alone mode
from the command line, and a MPI communicator for LAMMPS to run under.
It returns a ptr to the LAMMPS object that is created, and which is
used in subsequent library calls. The lammps\_open() function can be
used in subsequent library calls. The lammps_open() function can be
called multiple times, to create multiple instances of LAMMPS.
LAMMPS will run on the set of processors in the communicator. This
@ -86,14 +86,14 @@ half to the other code and run both codes simultaneously before
syncing them up periodically. Or it might instantiate multiple
instances of LAMMPS to perform different calculations.
The lammps\_open\_no\_mpi() function is similar except that no MPI
communicator is passed from the caller. Instead, MPI\_COMM\_WORLD is
The lammps_open_no_mpi() function is similar except that no MPI
communicator is passed from the caller. Instead, MPI_COMM_WORLD is
used to instantiate LAMMPS, and MPI is initialized if necessary.
The lammps\_close() function is used to shut down an instance of LAMMPS
The lammps_close() function is used to shut down an instance of LAMMPS
and free all its memory.
The lammps\_version() function can be used to determined the specific
The lammps_version() function can be used to determined the specific
version of the underlying LAMMPS code. This is particularly useful
when loading LAMMPS as a shared library via dlopen(). The code using
the library interface can than use this information to adapt to
@ -101,8 +101,8 @@ changes to the LAMMPS command syntax between versions. The returned
LAMMPS version code is an integer (e.g. 2 Sep 2015 results in
20150902) that grows with every new LAMMPS version.
The lammps\_file(), lammps\_command(), lammps\_commands\_list(), and
lammps\_commands\_string() functions are used to pass one or more
The lammps_file(), lammps_command(), lammps_commands_list(), and
lammps_commands_string() functions are used to pass one or more
commands to LAMMPS to execute, the same as if they were coming from an
input script.
@ -113,19 +113,19 @@ can interleave the command function calls with operations it performs,
calls to extract information from or set information within LAMMPS, or
calls to another code's library.
The lammps\_file() function passes the filename of an input script.
The lammps\_command() function passes a single command as a string.
The lammps\_commands\_list() function passes multiple commands in a
char\*\* list. In both lammps\_command() and lammps\_commands\_list(),
The lammps_file() function passes the filename of an input script.
The lammps_command() function passes a single command as a string.
The lammps_commands_list() function passes multiple commands in a
char\*\* list. In both lammps_command() and lammps_commands_list(),
individual commands may or may not have a trailing newline. The
lammps\_commands\_string() function passes multiple commands
lammps_commands_string() function passes multiple commands
concatenated into one long string, separated by newline characters.
In both lammps\_commands\_list() and lammps\_commands\_string(), a single
In both lammps_commands_list() and lammps_commands_string(), a single
command can be spread across multiple lines, if the last printable
character of all but the last line is "&", the same as if the lines
appeared in an input script.
The lammps\_free() function is a clean-up function to free memory that
The lammps_free() function is a clean-up function to free memory that
the library allocated previously via other function calls. See
comments in src/library.cpp file for which other functions need this
clean-up.
@ -146,15 +146,15 @@ which quantities can be queried by name:
void *lammps_extract_fix(void *, char *, int, int, int, int)
void *lammps_extract_variable(void *, char *, char *)
The extract\_setting() function returns info on the size
The extract_setting() function returns info on the size
of data types (e.g. 32-bit or 64-bit atom IDs) used
by the LAMMPS executable (a compile-time choice).
The other extract functions return a pointer to various global or
per-atom quantities stored in LAMMPS or to values calculated by a
compute, fix, or variable. The pointer returned by the
extract\_global() function can be used as a permanent reference to a
value which may change. For the extract\_atom() method, see the
extract_global() function can be used as a permanent reference to a
value which may change. For the extract_atom() method, see the
extract() method in the src/atom.cpp file for a list of valid per-atom
properties. New names could easily be added if the property you want
is not listed. For the other extract functions, the underlying
@ -169,18 +169,18 @@ function to assure a current pointer or returned value(s).
int lammps_set_variable(void *, char *, char *)
void lammps_reset_box(void *, double *, double *, double, double, double)
The lammps\_get\_thermo() function returns the current value of a thermo
The lammps_get_thermo() function returns the current value of a thermo
keyword as a double precision value.
The lammps\_get\_natoms() function returns the total number of atoms in
The lammps_get_natoms() function returns the total number of atoms in
the system and can be used by the caller to allocate memory for the
lammps\_gather\_atoms() and lammps\_scatter\_atoms() functions.
lammps_gather_atoms() and lammps_scatter_atoms() functions.
The lammps\_set\_variable() function can set an existing string-style
The lammps_set_variable() function can set an existing string-style
variable to a new string value, so that subsequent LAMMPS commands can
access the variable.
The lammps\_reset\_box() function resets the size and shape of the
The lammps_reset_box() function resets the size and shape of the
simulation box, e.g. as part of restoring a previously extracted and
saved state of a simulation.
@ -202,17 +202,17 @@ owned by different processors.
.. warning::
These functions are not compatible with the
-DLAMMPS\_BIGBIG setting when compiling LAMMPS. Dummy functions
-DLAMMPS_BIGBIG setting when compiling LAMMPS. Dummy functions
that result in an error message and abort will be substituted
instead of resulting in random crashes and memory corruption.
The lammps\_gather\_atoms() function does this for all N atoms in the
The lammps_gather_atoms() function does this for all N atoms in the
system, ordered by atom ID, from 1 to N. The
lammps\_gather\_atoms\_concat() function does it for all N atoms, but
lammps_gather_atoms_concat() function does it for all N atoms, but
simply concatenates the subset of atoms owned by each processor. The
resulting vector is not ordered by atom ID. Atom IDs can be requested
by the same function if the caller needs to know the ordering. The
lammps\_gather\_subset() function allows the caller to request values
lammps_gather_subset() function allows the caller to request values
for only a subset of atoms (identified by ID).
For all 3 gather function, per-atom image flags can be retrieved in 2 ways.
If the count is specified as 1, they are returned
@ -220,10 +220,10 @@ in a packed format with all three image flags stored in a single integer.
If the count is specified as 3, the values are unpacked into xyz flags
by the library before returning them.
The lammps\_scatter\_atoms() function takes a list of values for all N
The lammps_scatter_atoms() function takes a list of values for all N
atoms in the system, ordered by atom ID, from 1 to N, and assigns
those values to each atom in the system. The
lammps\_scatter\_atoms\_subset() function takes a subset of IDs as an
lammps_scatter_atoms_subset() function takes a subset of IDs as an
argument and only scatters those values to the owning atoms.
.. code-block:: c
@ -231,12 +231,12 @@ argument and only scatters those values to the owning atoms.
void lammps_create_atoms(void *, int, tagint *, int *, double *, double *,
imageint *, int)
The lammps\_create\_atoms() function takes a list of N atoms as input
The lammps_create_atoms() function takes a list of N atoms as input
with atom types and coords (required), an optionally atom IDs and
velocities and image flags. It uses the coords of each atom to assign
it as a new atom to the processor that owns it. This function is
useful to add atoms to a simulation or (in tandem with
lammps\_reset\_box()) to restore a previously extracted and saved state
lammps_reset_box()) to restore a previously extracted and saved state
of a simulation. Additional properties for the new atoms can then be
assigned via the lammps\_scatter\_atoms() or lammps\_extract\_atom()
assigned via the lammps_scatter_atoms() or lammps_extract_atom()
functions.

8
doc/src/Howto_manifold.rst
View File

@ -19,17 +19,17 @@ to the relevant fixes.
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
| cylinder | R | x\^2 + y\^2 - R\^2 = 0 | Cylinder along z-axis, axis going through (0,0,0) |
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
| cylinder\_dent | R l a | x\^2 + y\^2 - r(z)\^2 = 0, r(x) = R if \| z \| > l, r(z) = R - a\*(1 + cos(z/l))/2 otherwise | A cylinder with a dent around z = 0 |
| cylinder_dent | R l a | x\^2 + y\^2 - r(z)\^2 = 0, r(x) = R if \| z \| > l, r(z) = R - a\*(1 + cos(z/l))/2 otherwise | A cylinder with a dent around z = 0 |
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
| dumbbell | a A B c | -( x\^2 + y\^2 ) + (a\^2 - z\^2/c\^2) \* ( 1 + (A\*sin(B\*z\^2))\^4) = 0 | A dumbbell |
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
| ellipsoid | a b c | (x/a)\^2 + (y/b)\^2 + (z/c)\^2 = 0 | An ellipsoid |
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
| gaussian\_bump | A l rc1 rc2 | if( x < rc1) -z + A \* exp( -x\^2 / (2 l\^2) ); else if( x < rc2 ) -z + a + b\*x + c\*x\^2 + d\*x\^3; else z | A Gaussian bump at x = y = 0, smoothly tapered to a flat plane z = 0. |
| gaussian_bump | A l rc1 rc2 | if( x < rc1) -z + A \* exp( -x\^2 / (2 l\^2) ); else if( x < rc2 ) -z + a + b\*x + c\*x\^2 + d\*x\^3; else z | A Gaussian bump at x = y = 0, smoothly tapered to a flat plane z = 0. |
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
| plane | a b c x0 y0 z0 | a\*(x-x0) + b\*(y-y0) + c\*(z-z0) = 0 | A plane with normal (a,b,c) going through point (x0,y0,z0) |
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
| plane\_wiggle | a w | z - a\*sin(w\*x) = 0 | A plane with a sinusoidal modulation on z along x. |
| plane_wiggle | a w | z - a\*sin(w\*x) = 0 | A plane with a sinusoidal modulation on z along x. |
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
| sphere | R | x\^2 + y\^2 + z\^2 - R\^2 = 0 | A sphere of radius R |
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
@ -37,7 +37,7 @@ to the relevant fixes.
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
| spine | a, A, B, B2, c | -(x\^2 + y\^2) + (a\^2 - z\^2/f(z)\^2)\*(1 + (A\*sin(g(z)\*z\^2))\^4), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise | An approximation to a dendritic spine |
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
| spine\_two | a, A, B, B2, c | -(x\^2 + y\^2) + (a\^2 - z\^2/f(z)\^2)\*(1 + (A\*sin(g(z)\*z\^2))\^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise | Another approximation to a dendritic spine |
| spine_two | a, A, B, B2, c | -(x\^2 + y\^2) + (a\^2 - z\^2/f(z)\^2)\*(1 + (A\*sin(g(z)\*z\^2))\^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise | Another approximation to a dendritic spine |
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
| thylakoid | wB LB lB | Various, see :ref:`(Paquay) <Paquay1>` | A model grana thylakoid consisting of two block-like compartments connected by a bridge of width wB, length LB and taper length lB |
+----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+

12
doc/src/Howto_output.rst
View File

@ -68,11 +68,11 @@ 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:
+-------------+--------------------------------------------+
| c\_ID | entire scalar, vector, or array |
| c_ID | entire scalar, vector, or array |
+-------------+--------------------------------------------+
| c\_ID[I] | one element of vector, one column of array |
| c_ID[I] | one element of vector, one column of array |
+-------------+--------------------------------------------+
| c\_ID[I][J] | one element of array |
| c_ID[I][J] | one element of array |
+-------------+--------------------------------------------+
In other words, using one bracket reduces the dimension of the data
@ -92,7 +92,7 @@ The frequency and format of thermodynamic output is set by 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>`
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>`
@ -121,7 +121,7 @@ pre-defined formats (dump atom, dump xtc, etc).
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
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.
@ -129,7 +129,7 @@ variable must generate per-atom values for input to the :doc:`dump custom <dump>
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
specified to enumerate the local values. Two additional kinds of
keywords can also be specified (c\_ID, f\_ID), where a
keywords can also be specified (c_ID, f_ID), where a
:doc:`compute <compute>` or :doc:`fix <fix>` or :doc:`variable <variable>`
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>`

6
doc/src/Howto_restart.rst
View File

@ -46,8 +46,8 @@ last 50 timesteps:
run 50
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
their settings are included in the restart file: *units, atom_style,
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*\ .
@ -89,7 +89,7 @@ Then, this script could be used to re-run the last 50 steps:
run 50
Note that nearly all the settings specified in the original *in.chain*
script must be repeated, except the *pair\_coeff* and *bond\_coeff*
script must be repeated, except the *pair_coeff* and *bond_coeff*
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,

2
doc/src/Howto_spherical.rst
View File

@ -115,7 +115,7 @@ such interactions. These are the various :doc:`pair styles <pair_style>` that g
* :doc:`pair_style gran/history <pair_gran>`
* :doc:`pair_style gran/hertzian <pair_gran>`
* :doc:`pair_style gran/no\_history <pair_gran>`
* :doc:`pair_style gran/no_history <pair_gran>`
* :doc:`pair_style dipole/cut <pair_dipole>`
* :doc:`pair_style gayberne <pair_gayberne>`
* :doc:`pair_style resquared <pair_resquared>`

2
doc/src/Howto_triclinic.rst
View File

@ -221,7 +221,7 @@ calculated from the 9 triclinic box parameters
zhi_bound = zhi
These formulas can be inverted if you need to convert the bounding box
back into the triclinic box parameters, e.g. xlo = xlo\_bound -
back into the triclinic box parameters, e.g. xlo = xlo_bound -
MIN(0.0,xy,xz,xy+xz).
One use of triclinic simulation boxes is to model solid-state crystals

2
doc/src/Install_git.rst
View File

@ -16,7 +16,7 @@ commands explained below to communicate with the git servers on
GitHub. For people still using subversion (svn), GitHub also
provides `limited support for subversion clients <svn_>`_.
.. warning::
.. note::
As of October 2016, the official home of public LAMMPS development is
on GitHub. The previously advertised LAMMPS git repositories on

8
doc/src/Install_linux.rst
View File

@ -38,7 +38,7 @@ To install LAMMPS do the following once:
$ sudo apt-get install lammps-daily
This downloads an executable named "lmp\_daily" to your box, which
This downloads an executable named "lmp_daily" to your box, which
can then be used in the usual way to run input scripts:
.. code-block:: bash
@ -103,10 +103,10 @@ linking to the C library interface (lammps-devel, lammps-mpich-devel,
lammps-openmpi-devel), the header for compiling programs using
the C library interface (lammps-headers), and the LAMMPS python
module for Python 3. All packages can be installed at the same
time and the name of the LAMMPS executable is *lmp* and *lmp\_openmpi*
or *lmp\_mpich* respectively. By default, *lmp* will refer to the
time and the name of the LAMMPS executable is *lmp* and *lmp_openmpi*
or *lmp_mpich* respectively. By default, *lmp* will refer to the
serial executable, unless one of the MPI environment modules is loaded
("module load mpi/mpich-x86\_64" or "module load mpi/openmpi-x86\_64").
("module load mpi/mpich-x86_64" or "module load mpi/openmpi-x86_64").
Then the corresponding parallel LAMMPS executable can be used.
The same mechanism applies when loading the LAMMPS python module.

2
doc/src/Install_mac.rst
View File

@ -14,7 +14,7 @@ the following commands:
% brew install lammps
This will install the executables "lammps\_serial" and "lammps\_mpi", as well as
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

4
doc/src/Install_tarball.rst
View File

@ -26,7 +26,7 @@ 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.
@ -40,7 +40,7 @@ a lammps-master dir:
.. code-block:: bash
$ unzip lammps\*.zip
$ unzip lammps*.zip
This version is the most up-to-date LAMMPS development version. It
will have the date of the most recent patch release (see the file

6
doc/src/Install_windows.rst
View File

@ -4,7 +4,9 @@ Download an executable for Windows
Pre-compiled Windows installers which install LAMMPS executables on a
Windows system can be downloaded from this site:
`http://packages.lammps.org/windows.html <http://packages.lammps.org/windows.html>`_
.. parsed-literal::
`http://packages.lammps.org/windows.html <http://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
@ -26,7 +28,7 @@ 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
will then update a few system settings (e.g. PATH, LAMMPS\_POTENTIALS)
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
also a link to an uninstaller that removes the files and undoes the

6
doc/src/Manual_build.rst
View File

@ -5,7 +5,7 @@ Depending on how you obtained LAMMPS, the doc directory has up
to 6 sub-directories, 2 Nroff files, and optionally 2 PDF files
plus 2 e-book format files:
.. parsed-literal::
.. code-block:: bash
src # content files for LAMMPS documentation
html # HTML version of the LAMMPS manual (see html/Manual.html)
@ -28,8 +28,8 @@ and PDF files are not included. Instead you need to create them, in one
of two ways:
a. You can "fetch" the current HTML and PDF files from the LAMMPS web
site. Just type "make fetch". This should download a html\_www
directory and Manual\_www.pdf/Developer\_www.pdf files. Note that if
site. Just type "make fetch". This should download a html_www
directory and Manual_www.pdf/Developer_www.pdf files. Note that if
new LAMMPS features have been added more recently than the date of
your LAMMPS version, the fetched documentation will include those
changes (but your source code will not, unless you update your local

74
doc/src/Modify_atom.rst
View File

@ -8,78 +8,78 @@ style can be created if one of the existing atom styles does not
define all the attributes you need to store and communicate with
atoms.
Atom\_vec\_atomic.cpp is a simple example of an atom style.
Atom_vec_atomic.cpp is a simple example of an atom style.
Here is a brief description of methods you define in your new derived
class. See atom\_vec.h for details.
class. See atom_vec.h for details.
+-------------------------+--------------------------------------------------------------------------------+
| init | one time setup (optional) |
+-------------------------+--------------------------------------------------------------------------------+
| grow | re-allocate atom arrays to longer lengths (required) |
+-------------------------+--------------------------------------------------------------------------------+
| grow\_reset | make array pointers in Atom and AtomVec classes consistent (required) |
| grow_reset | make array pointers in Atom and AtomVec classes consistent (required) |
+-------------------------+--------------------------------------------------------------------------------+
| copy | copy info for one atom to another atom's array locations (required) |
+-------------------------+--------------------------------------------------------------------------------+
| pack\_comm | store an atom's info in a buffer communicated every timestep (required) |
| pack_comm | store an atom's info in a buffer communicated every timestep (required) |
+-------------------------+--------------------------------------------------------------------------------+
| pack\_comm\_vel | add velocity info to communication buffer (required) |
| pack_comm_vel | add velocity info to communication buffer (required) |
+-------------------------+--------------------------------------------------------------------------------+
| pack\_comm\_hybrid | store extra info unique to this atom style (optional) |
| pack_comm_hybrid | store extra info unique to this atom style (optional) |
+-------------------------+--------------------------------------------------------------------------------+
| unpack\_comm | retrieve an atom's info from the buffer (required) |
| unpack_comm | retrieve an atom's info from the buffer (required) |
+-------------------------+--------------------------------------------------------------------------------+
| unpack\_comm\_vel | also retrieve velocity info (required) |
| unpack_comm_vel | also retrieve velocity info (required) |
+-------------------------+--------------------------------------------------------------------------------+
| unpack\_comm\_hybrid | retrieve extra info unique to this atom style (optional) |
| unpack_comm_hybrid | retrieve extra info unique to this atom style (optional) |
+-------------------------+--------------------------------------------------------------------------------+
| pack\_reverse | store an atom's info in a buffer communicating partial forces (required) |
| pack_reverse | store an atom's info in a buffer communicating partial forces (required) |
+-------------------------+--------------------------------------------------------------------------------+
| pack\_reverse\_hybrid | store extra info unique to this atom style (optional) |
| pack_reverse_hybrid | store extra info unique to this atom style (optional) |
+-------------------------+--------------------------------------------------------------------------------+
| unpack\_reverse | retrieve an atom's info from the buffer (required) |
| unpack_reverse | retrieve an atom's info from the buffer (required) |
+-------------------------+--------------------------------------------------------------------------------+
| unpack\_reverse\_hybrid | retrieve extra info unique to this atom style (optional) |
| unpack_reverse_hybrid | retrieve extra info unique to this atom style (optional) |
+-------------------------+--------------------------------------------------------------------------------+
| pack\_border | store an atom's info in a buffer communicated on neighbor re-builds (required) |
| pack_border | store an atom's info in a buffer communicated on neighbor re-builds (required) |
+-------------------------+--------------------------------------------------------------------------------+
| pack\_border\_vel | add velocity info to buffer (required) |
| pack_border_vel | add velocity info to buffer (required) |
+-------------------------+--------------------------------------------------------------------------------+
| pack\_border\_hybrid | store extra info unique to this atom style (optional) |
| pack_border_hybrid | store extra info unique to this atom style (optional) |
+-------------------------+--------------------------------------------------------------------------------+
| unpack\_border | retrieve an atom's info from the buffer (required) |
| unpack_border | retrieve an atom's info from the buffer (required) |
+-------------------------+--------------------------------------------------------------------------------+
| unpack\_border\_vel | also retrieve velocity info (required) |
| unpack_border_vel | also retrieve velocity info (required) |
+-------------------------+--------------------------------------------------------------------------------+
| unpack\_border\_hybrid | retrieve extra info unique to this atom style (optional) |
| unpack_border_hybrid | retrieve extra info unique to this atom style (optional) |
+-------------------------+--------------------------------------------------------------------------------+
| pack\_exchange | store all an atom's info to migrate to another processor (required) |
| pack_exchange | store all an atom's info to migrate to another processor (required) |
+-------------------------+--------------------------------------------------------------------------------+
| unpack\_exchange | retrieve an atom's info from the buffer (required) |
| unpack_exchange | retrieve an atom's info from the buffer (required) |
+-------------------------+--------------------------------------------------------------------------------+
| size\_restart | number of restart quantities associated with proc's atoms (required) |
| size_restart | number of restart quantities associated with proc's atoms (required) |
+-------------------------+--------------------------------------------------------------------------------+
| pack\_restart | pack atom quantities into a buffer (required) |
| pack_restart | pack atom quantities into a buffer (required) |
+-------------------------+--------------------------------------------------------------------------------+
| unpack\_restart | unpack atom quantities from a buffer (required) |
| unpack_restart | unpack atom quantities from a buffer (required) |
+-------------------------+--------------------------------------------------------------------------------+
| create\_atom | create an individual atom of this style (required) |
| create_atom | create an individual atom of this style (required) |
+-------------------------+--------------------------------------------------------------------------------+
| data\_atom | parse an atom line from the data file (required) |
| data_atom | parse an atom line from the data file (required) |
+-------------------------+--------------------------------------------------------------------------------+
| data\_atom\_hybrid | parse additional atom info unique to this atom style (optional) |
| data_atom_hybrid | parse additional atom info unique to this atom style (optional) |
+-------------------------+--------------------------------------------------------------------------------+
| data\_vel | parse one line of velocity information from data file (optional) |
| data_vel | parse one line of velocity information from data file (optional) |
+-------------------------+--------------------------------------------------------------------------------+
| data\_vel\_hybrid | parse additional velocity data unique to this atom style (optional) |
| data_vel_hybrid | parse additional velocity data unique to this atom style (optional) |
+-------------------------+--------------------------------------------------------------------------------+
| memory\_usage | tally memory allocated by atom arrays (required) |
| memory_usage | tally memory allocated by atom arrays (required) |
+-------------------------+--------------------------------------------------------------------------------+
The constructor of the derived class sets values for several variables
that you must set when defining a new atom style, which are documented
in atom\_vec.h. New atom arrays are defined in atom.cpp. Search for
in atom_vec.h. New atom arrays are defined in atom.cpp. Search for
the word "customize" and you will find locations you will need to
modify.
@ -95,12 +95,12 @@ modify.
New :doc:`pair styles <pair_style>`, :doc:`fixes <fix>`, or
:doc:`computes <compute>` can be added to LAMMPS, as discussed below.
The code for these classes can use the per-atom properties defined by
fix property/atom. The Atom class has a find\_custom() method that is
fix property/atom. The Atom class has a find_custom() method that is
useful in this context:
.. parsed-literal::
.. code-block:: c++
int index = atom->find_custom(char \*name, int &flag);
int index = atom->find_custom(char *name, int &flag);
The "name" of a custom attribute, as specified in the :doc:`fix property/atom <fix_property_atom>` command, is checked to verify
that it exists and its index is returned. The method also sets flag =
@ -108,10 +108,10 @@ that it exists and its index is returned. The method also sets flag =
The vector of values associated with the attribute can then be
accessed using the returned index as
.. parsed-literal::
.. code-block:: c++
int \*ivector = atom->ivector[index];
double \*dvector = atom->dvector[index];
int *ivector = atom->ivector[index];
double *dvector = atom->dvector[index];
Ivector or dvector are vectors of length Nlocal = # of owned atoms,
which store the attributes of individual atoms.

12
doc/src/Modify_body.rst
View File

@ -10,14 +10,14 @@ See the :doc:`Howto body <Howto_body>` doc page for an overview of using
body particles and the various body styles LAMMPS supports. New
styles can be created to add new kinds of body particles to LAMMPS.
Body\_nparticle.cpp is an example of a body particle that is treated as
Body_nparticle.cpp is an example of a body particle that is treated as
a rigid body containing N sub-particles.
Here is a brief description of methods you define in your new derived
class. See body.h for details.
+----------------------+-----------------------------------------------------------+
| data\_body | process a line from the Bodies section of a data file |
| data_body | process a line from the Bodies section of a data file |
+----------------------+-----------------------------------------------------------+
| noutrow | number of sub-particles output is generated for |
+----------------------+-----------------------------------------------------------+
@ -25,11 +25,11 @@ class. See body.h for details.
+----------------------+-----------------------------------------------------------+
| output | output values for the Mth sub-particle |
+----------------------+-----------------------------------------------------------+
| pack\_comm\_body | body attributes to communicate every timestep |
| pack_comm_body | body attributes to communicate every timestep |
+----------------------+-----------------------------------------------------------+
| unpack\_comm\_body | unpacking of those attributes |
| unpack_comm_body | unpacking of those attributes |
+----------------------+-----------------------------------------------------------+
| pack\_border\_body | body attributes to communicate when reneighboring is done |
| pack_border_body | body attributes to communicate when reneighboring is done |
+----------------------+-----------------------------------------------------------+
| unpack\_border\_body | unpacking of those attributes |
| unpack_border_body | unpacking of those attributes |
+----------------------+-----------------------------------------------------------+

14
doc/src/Modify_bond.rst
View File

@ -5,7 +5,7 @@ Classes that compute molecular interactions are derived from the Bond,
Angle, Dihedral, and Improper classes. New styles can be created to
add new potentials to LAMMPS.
Bond\_harmonic.cpp is the simplest example of a bond style. Ditto for
Bond_harmonic.cpp is the simplest example of a bond style. Ditto for
the harmonic forms of the angle, dihedral, and improper style
commands.
@ -14,9 +14,9 @@ new derived class. See bond.h, angle.h, dihedral.h, and improper.h
for details and specific additional methods.
+-----------------------+---------------------------------------------------------------------------+
| init | check if all coefficients are set, calls *init\_style* (optional) |
| init | check if all coefficients are set, calls *init_style* (optional) |
+-----------------------+---------------------------------------------------------------------------+
| init\_style | check if style specific conditions are met (optional) |
| init_style | check if style specific conditions are met (optional) |
+-----------------------+---------------------------------------------------------------------------+
| compute | compute the molecular interactions (required) |
+-----------------------+---------------------------------------------------------------------------+
@ -24,13 +24,13 @@ for details and specific additional methods.
+-----------------------+---------------------------------------------------------------------------+
| coeff | set coefficients for one type (required) |
+-----------------------+---------------------------------------------------------------------------+
| equilibrium\_distance | length of bond, used by SHAKE (required, bond only) |
| equilibrium_distance | length of bond, used by SHAKE (required, bond only) |
+-----------------------+---------------------------------------------------------------------------+
| equilibrium\_angle | opening of angle, used by SHAKE (required, angle only) |
| equilibrium_angle | opening of angle, used by SHAKE (required, angle only) |
+-----------------------+---------------------------------------------------------------------------+
| write & read\_restart | writes/reads coeffs to restart files (required) |
| write & read_restart | writes/reads coeffs to restart files (required) |
+-----------------------+---------------------------------------------------------------------------+
| single | force and energy of a single bond or angle (required, bond or angle only) |
+-----------------------+---------------------------------------------------------------------------+
| memory\_usage | tally memory allocated by the style (optional) |
| memory_usage | tally memory allocated by the style (optional) |
+-----------------------+---------------------------------------------------------------------------+

4
doc/src/Modify_command.rst
View File

@ -2,8 +2,8 @@ Input script command style
==========================
New commands can be added to LAMMPS input scripts by adding new
classes that have a "command" method. For example, the create\_atoms,
read\_data, velocity, and run commands are all implemented in this
classes that have a "command" method. For example, the create_atoms,
read_data, velocity, and run commands are all implemented in this
fashion. When such a command is encountered in the LAMMPS input
script, LAMMPS simply creates a class with the corresponding name,
invokes the "command" method of the class, and passes it the arguments

42
doc/src/Modify_compute.rst
View File

@ -7,8 +7,8 @@ quantities like kinetic energy and the centro-symmetry parameter
are derived from the Compute class. New styles can be created
to add new calculations to LAMMPS.
Compute\_temp.cpp is a simple example of computing a scalar
temperature. Compute\_ke\_atom.cpp is a simple example of computing
Compute_temp.cpp is a simple example of computing a scalar
temperature. Compute_ke_atom.cpp is a simple example of computing
per-atom kinetic energy.
Here is a brief description of methods you define in your new derived
@ -17,41 +17,41 @@ class. See compute.h for details.
+-----------------------+------------------------------------------------------------------+
| init | perform one time setup (required) |
+-----------------------+------------------------------------------------------------------+
| init\_list | neighbor list setup, if needed (optional) |
| init_list | neighbor list setup, if needed (optional) |
+-----------------------+------------------------------------------------------------------+
| compute\_scalar | compute a scalar quantity (optional) |
| compute_scalar | compute a scalar quantity (optional) |
+-----------------------+------------------------------------------------------------------+
| compute\_vector | compute a vector of quantities (optional) |
| compute_vector | compute a vector of quantities (optional) |
+-----------------------+------------------------------------------------------------------+
| compute\_peratom | compute one or more quantities per atom (optional) |
| compute_peratom | compute one or more quantities per atom (optional) |
+-----------------------+------------------------------------------------------------------+
| compute\_local | compute one or more quantities per processor (optional) |
| compute_local | compute one or more quantities per processor (optional) |
+-----------------------+------------------------------------------------------------------+
| pack\_comm | pack a buffer with items to communicate (optional) |
| pack_comm | pack a buffer with items to communicate (optional) |
+-----------------------+------------------------------------------------------------------+
| unpack\_comm | unpack the buffer (optional) |
| unpack_comm | unpack the buffer (optional) |
+-----------------------+------------------------------------------------------------------+
| pack\_reverse | pack a buffer with items to reverse communicate (optional) |
| pack_reverse | pack a buffer with items to reverse communicate (optional) |
+-----------------------+------------------------------------------------------------------+
| unpack\_reverse | unpack the buffer (optional) |
| unpack_reverse | unpack the buffer (optional) |
+-----------------------+------------------------------------------------------------------+
| remove\_bias | remove velocity bias from one atom (optional) |
| remove_bias | remove velocity bias from one atom (optional) |
+-----------------------+------------------------------------------------------------------+
| remove\_bias\_all | remove velocity bias from all atoms in group (optional) |
| remove_bias_all | remove velocity bias from all atoms in group (optional) |
+-----------------------+------------------------------------------------------------------+
| restore\_bias | restore velocity bias for one atom after remove\_bias (optional) |
| restore_bias | restore velocity bias for one atom after remove_bias (optional) |
+-----------------------+------------------------------------------------------------------+
| restore\_bias\_all | same as before, but for all atoms in group (optional) |
| restore_bias_all | same as before, but for all atoms in group (optional) |
+-----------------------+------------------------------------------------------------------+
| pair\_tally\_callback | callback function for *tally*\ -style computes (optional). |
| pair_tally_callback | callback function for *tally*\ -style computes (optional). |
+-----------------------+------------------------------------------------------------------+
| memory\_usage | tally memory usage (optional) |
| memory_usage | tally memory usage (optional) |
+-----------------------+------------------------------------------------------------------+
Tally-style computes are a special case, as their computation is done
in two stages: the callback function is registered with the pair style
and then called from the Pair::ev\_tally() function, which is called for
and then called from the Pair::ev_tally() function, which is called for
each pair after force and energy has been computed for this pair. Then
the tallied values are retrieved with the standard compute\_scalar or
compute\_vector or compute\_peratom methods. The USER-TALLY package
provides *examples*\ \_compute\_tally.html for utilizing this mechanism.
the tallied values are retrieved with the standard compute_scalar or
compute_vector or compute_peratom methods. The USER-TALLY package
provides *examples*\ _compute_tally.html for utilizing this mechanism.

10
doc/src/Modify_contribute.rst
View File

@ -90,8 +90,8 @@ packages in the src directory for examples. If you are uncertain, please ask.
* All source files you provide must compile with the most current
version of LAMMPS with multiple configurations. In particular you
need to test compiling LAMMPS from scratch with -DLAMMPS\_BIGBIG
set in addition to the default -DLAMMPS\_SMALLBIG setting. Your code
need to test compiling LAMMPS from scratch with -DLAMMPS_BIGBIG
set in addition to the default -DLAMMPS_SMALLBIG setting. Your code
will need to work correctly in serial and in parallel using MPI.
* For consistency with the rest of LAMMPS and especially, if you want
@ -106,7 +106,7 @@ packages in the src directory for examples. If you are uncertain, please ask.
(<cstdlib>, <cstdio>, or <cstring>) instead of the C-style names
<stdlib.h>, <stdio.h>, or <string.h>), and forward declarations
used where possible or needed to avoid including headers.
All added code should be placed into the LAMMPS\_NS namespace or a
All added code should be placed into the LAMMPS_NS namespace or a
sub-namespace; global or static variables should be avoided, as they
conflict with the modular nature of LAMMPS and the C++ class structure.
Header files must **not** import namespaces with *using*\ .
@ -164,7 +164,7 @@ packages in the src directory for examples. If you are uncertain, please ask.
mathematical expression or figures (see doc/JPG for examples).
Additional PDF files with further details (see doc/PDF for examples)
may also be included. The doc page should also include literature
citations as appropriate; see the bottom of doc/fix\_nh.rst for
citations as appropriate; see the bottom of doc/fix_nh.rst for
examples and the earlier part of the same file for how to format the
cite itself. Citation labels must be unique across all .rst files.
The "Restrictions" section of the doc page should indicate if your
@ -191,7 +191,7 @@ packages in the src directory for examples. If you are uncertain, please ask.
* If there is a paper of yours describing your feature (either the
algorithm/science behind the feature itself, or its initial usage, or
its implementation in LAMMPS), you can add the citation to the \*.cpp
source file. See src/USER-EFF/atom\_vec\_electron.cpp for an example.
source file. See src/USER-EFF/atom_vec_electron.cpp for an example.
A LaTeX citation is stored in a variable at the top of the file and a
single line of code that references the variable is added to the
constructor of the class. Whenever a user invokes your feature from

8
doc/src/Modify_dump.rst
View File

@ -4,21 +4,21 @@ Dump styles
Classes that dump per-atom info to files are derived from the Dump
class. To dump new quantities or in a new format, a new derived dump
class can be added, but it is typically simpler to modify the
DumpCustom class contained in the dump\_custom.cpp file.
DumpCustom class contained in the dump_custom.cpp file.
Dump\_atom.cpp is a simple example of a derived dump class.
Dump_atom.cpp is a simple example of a derived dump class.
Here is a brief description of methods you define in your new derived
class. See dump.h for details.
+---------------+---------------------------------------------------+
| write\_header | write the header section of a snapshot of atoms |
| write_header | write the header section of a snapshot of atoms |
+---------------+---------------------------------------------------+
| count | count the number of lines a processor will output |
+---------------+---------------------------------------------------+
| pack | pack a proc's output data into a buffer |
+---------------+---------------------------------------------------+
| write\_data | write a proc's data to a file |
| write_data | write a proc's data to a file |
+---------------+---------------------------------------------------+
See the :doc:`dump <dump>` command and its *custom* style for a list of

114
doc/src/Modify_fix.rst
View File

@ -10,7 +10,7 @@ constraints or boundary conditions (SHAKE or walls), and diagnostics
(compute a diffusion coefficient). New styles can be created to add
new options to LAMMPS.
Fix\_setforce.cpp is a simple example of setting forces on atoms to
Fix_setforce.cpp is a simple example of setting forces on atoms to
prescribed values. There are dozens of fix options already in LAMMPS;
choose one as a template that is similar to what you want to
implement.
@ -23,105 +23,105 @@ derived class. See fix.h for details.
+---------------------------+--------------------------------------------------------------------------------------------+
| init | initialization before a run (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| setup\_pre\_exchange | called before atom exchange in setup (optional) |
| setup_pre_exchange | called before atom exchange in setup (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| setup\_pre\_force | called before force computation in setup (optional) |
| setup_pre_force | called before force computation in setup (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| setup | called immediately before the 1st timestep and after forces are computed (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| min\_setup\_pre\_force | like setup\_pre\_force, but for minimizations instead of MD runs (optional) |
| min_setup_pre_force | like setup_pre_force, but for minimizations instead of MD runs (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| min\_setup | like setup, but for minimizations instead of MD runs (optional) |
| min_setup | like setup, but for minimizations instead of MD runs (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| initial\_integrate | called at very beginning of each timestep (optional) |
| initial_integrate | called at very beginning of each timestep (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| pre\_exchange | called before atom exchange on re-neighboring steps (optional) |
| pre_exchange | called before atom exchange on re-neighboring steps (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| pre\_neighbor | called before neighbor list build (optional) |
| pre_neighbor | called before neighbor list build (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| pre\_force | called before pair & molecular forces are computed (optional) |
| pre_force | called before pair & molecular forces are computed (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| post\_force | called after pair & molecular forces are computed and communicated (optional) |
| post_force | called after pair & molecular forces are computed and communicated (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| final\_integrate | called at end of each timestep (optional) |
| final_integrate | called at end of each timestep (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| end\_of\_step | called at very end of timestep (optional) |
| end_of_step | called at very end of timestep (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| write\_restart | dumps fix info to restart file (optional) |
| write_restart | dumps fix info to restart file (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| restart | uses info from restart file to re-initialize the fix (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| grow\_arrays | allocate memory for atom-based arrays used by fix (optional) |
| grow_arrays | allocate memory for atom-based arrays used by fix (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| copy\_arrays | copy atom info when an atom migrates to a new processor (optional) |
| copy_arrays | copy atom info when an atom migrates to a new processor (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| pack\_exchange | store atom's data in a buffer (optional) |
| pack_exchange | store atom's data in a buffer (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| unpack\_exchange | retrieve atom's data from a buffer (optional) |
| unpack_exchange | retrieve atom's data from a buffer (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| pack\_restart | store atom's data for writing to restart file (optional) |
| pack_restart | store atom's data for writing to restart file (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| unpack\_restart | retrieve atom's data from a restart file buffer (optional) |
| unpack_restart | retrieve atom's data from a restart file buffer (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| size\_restart | size of atom's data (optional) |
| size_restart | size of atom's data (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| maxsize\_restart | max size of atom's data (optional) |
| maxsize_restart | max size of atom's data (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| setup\_pre\_force\_respa | same as setup\_pre\_force, but for rRESPA (optional) |
| setup_pre_force_respa | same as setup_pre_force, but for rRESPA (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| initial\_integrate\_respa | same as initial\_integrate, but for rRESPA (optional) |
| initial_integrate_respa | same as initial_integrate, but for rRESPA (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| post\_integrate\_respa | called after the first half integration step is done in rRESPA (optional) |
| post_integrate_respa | called after the first half integration step is done in rRESPA (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| pre\_force\_respa | same as pre\_force, but for rRESPA (optional) |
| pre_force_respa | same as pre_force, but for rRESPA (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| post\_force\_respa | same as post\_force, but for rRESPA (optional) |
| post_force_respa | same as post_force, but for rRESPA (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| final\_integrate\_respa | same as final\_integrate, but for rRESPA (optional) |
| final_integrate_respa | same as final_integrate, but for rRESPA (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| min\_pre\_force | called after pair & molecular forces are computed in minimizer (optional) |
| min_pre_force | called after pair & molecular forces are computed in minimizer (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| min\_post\_force | called after pair & molecular forces are computed and communicated in minimizer (optional) |
| min_post_force | called after pair & molecular forces are computed and communicated in minimizer (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| min\_store | store extra data for linesearch based minimization on a LIFO stack (optional) |
| min_store | store extra data for linesearch based minimization on a LIFO stack (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| min\_pushstore | push the minimization LIFO stack one element down (optional) |
| min_pushstore | push the minimization LIFO stack one element down (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| min\_popstore | pop the minimization LIFO stack one element up (optional) |
| min_popstore | pop the minimization LIFO stack one element up (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| min\_clearstore | clear minimization LIFO stack (optional) |
| min_clearstore | clear minimization LIFO stack (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| min\_step | reset or move forward on line search minimization (optional) |
| min_step | reset or move forward on line search minimization (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| min\_dof | report number of degrees of freedom *added* by this fix in minimization (optional) |
| min_dof | report number of degrees of freedom *added* by this fix in minimization (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| max\_alpha | report maximum allowed step size during linesearch minimization (optional) |
| max_alpha | report maximum allowed step size during linesearch minimization (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| pack\_comm | pack a buffer to communicate a per-atom quantity (optional) |
| pack_comm | pack a buffer to communicate a per-atom quantity (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| unpack\_comm | unpack a buffer to communicate a per-atom quantity (optional) |
| unpack_comm | unpack a buffer to communicate a per-atom quantity (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| pack\_reverse\_comm | pack a buffer to reverse communicate a per-atom quantity (optional) |
| pack_reverse_comm | pack a buffer to reverse communicate a per-atom quantity (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| unpack\_reverse\_comm | unpack a buffer to reverse communicate a per-atom quantity (optional) |
| unpack_reverse_comm | unpack a buffer to reverse communicate a per-atom quantity (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| dof | report number of degrees of freedom *removed* by this fix during MD (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| compute\_scalar | return a global scalar property that the fix computes (optional) |
| compute_scalar | return a global scalar property that the fix computes (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| compute\_vector | return a component of a vector property that the fix computes (optional) |
| compute_vector | return a component of a vector property that the fix computes (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| compute\_array | return a component of an array property that the fix computes (optional) |
| compute_array | return a component of an array property that the fix computes (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| deform | called when the box size is changed (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| reset\_target | called when a change of the target temperature is requested during a run (optional) |
| reset_target | called when a change of the target temperature is requested during a run (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| reset\_dt | is called when a change of the time step is requested during a run (optional) |
| reset_dt | is called when a change of the time step is requested during a run (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| modify\_param | called when a fix\_modify request is executed (optional) |
| modify_param | called when a fix_modify request is executed (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| memory\_usage | report memory used by fix (optional) |
| memory_usage | report memory used by fix (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| thermo | compute quantities for thermodynamic output (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
@ -129,12 +129,12 @@ derived class. See fix.h for details.
Typically, only a small fraction of these methods are defined for a
particular fix. Setmask is mandatory, as it determines when the fix
will be invoked during the timestep. Fixes that perform time
integration (\ *nve*\ , *nvt*\ , *npt*\ ) implement initial\_integrate() and
final\_integrate() to perform velocity Verlet updates. Fixes that
constrain forces implement post\_force().
integration (\ *nve*\ , *nvt*\ , *npt*\ ) implement initial_integrate() and
final_integrate() to perform velocity Verlet updates. Fixes that
constrain forces implement post_force().
Fixes that perform diagnostics typically implement end\_of\_step(). For
an end\_of\_step fix, one of your fix arguments must be the variable
Fixes that perform diagnostics typically implement end_of_step(). For
an end_of_step fix, one of your fix arguments must be the variable
"nevery" which is used to determine when to call the fix and you must
set this variable in the constructor of your fix. By convention, this
is the first argument the fix defines (after the ID, group-ID, style).
@ -142,12 +142,12 @@ is the first argument the fix defines (after the ID, group-ID, style).
If the fix needs to store information for each atom that persists from
timestep to timestep, it can manage that memory and migrate the info
with the atoms as they move from processors to processor by
implementing the grow\_arrays, copy\_arrays, pack\_exchange, and
unpack\_exchange methods. Similarly, the pack\_restart and
unpack\_restart methods can be implemented to store information about
implementing the grow_arrays, copy_arrays, pack_exchange, and
unpack_exchange methods. Similarly, the pack_restart and
unpack_restart methods can be implemented to store information about
the fix in restart files. If you wish an integrator or force
constraint fix to work with rRESPA (see the :doc:`run_style <run_style>`
command), the initial\_integrate, post\_force\_integrate, and
final\_integrate\_respa methods can be implemented. The thermo method
command), the initial_integrate, post_force_integrate, and
final_integrate_respa methods can be implemented. The thermo method
enables a fix to contribute values to thermodynamic output, as printed
quantities and/or to be summed to the potential energy of the system.

2
doc/src/Modify_kspace.rst
View File

@ -17,5 +17,5 @@ class. See kspace.h for details.
+---------------+----------------------------------------------+
| compute | every-timestep computation |
+---------------+----------------------------------------------+
| memory\_usage | tally of memory usage |
| memory_usage | tally of memory usage |
+---------------+----------------------------------------------+

4
doc/src/Modify_min.rst
View File

@ -5,7 +5,7 @@ Classes that perform energy minimization derived from the Min class.
New styles can be created to add new minimization algorithms to
LAMMPS.
Min\_cg.cpp is an example of conjugate gradient minimization.
Min_cg.cpp is an example of conjugate gradient minimization.
Here is a brief description of methods you define in your new derived
class. See min.h for details.
@ -15,5 +15,5 @@ class. See min.h for details.
+---------------+------------------------------------------+
| run | perform the minimization |
+---------------+------------------------------------------+
| memory\_usage | tally of memory usage |
| memory_usage | tally of memory usage |
+---------------+------------------------------------------+

14
doc/src/Modify_overview.rst
View File

@ -25,8 +25,8 @@ and variables needed to define the new feature are in the 2 files you
write, and thus shouldn't make the rest of LAMMPS more complex or
cause side-effect bugs.
Here is a concrete example. Suppose you write 2 files pair\_foo.cpp
and pair\_foo.h that define a new class PairFoo that computes pairwise
Here is a concrete example. Suppose you write 2 files pair_foo.cpp
and pair_foo.h that define a new class PairFoo that computes pairwise
potentials described in the classic 1997 :ref:`paper <Foo>` by Foo, et al.
If you wish to invoke those potentials in a LAMMPS input script with a
command like
@ -35,7 +35,7 @@ command like
pair_style foo 0.1 3.5
then your pair\_foo.h file should be structured as follows:
then your pair_foo.h file should be structured as follows:
.. code-block:: c++
@ -47,12 +47,12 @@ then your pair\_foo.h file should be structured as follows:
...
#endif
where "foo" is the style keyword in the pair\_style command, and
PairFoo is the class name defined in your pair\_foo.cpp and pair\_foo.h
where "foo" is the style keyword in the pair_style command, and
PairFoo is the class name defined in your pair_foo.cpp and pair_foo.h
files.
When you re-build LAMMPS, your new pairwise potential becomes part of
the executable and can be invoked with a pair\_style command like the
the executable and can be invoked with a pair_style command like the
example above. Arguments like 0.1 and 3.5 can be defined and
processed by your new class.
@ -80,7 +80,7 @@ that are not set to 0 are functions you may override or not. Those
are usually defined with an empty function body.
Additionally, new output options can be added directly to the
thermo.cpp, dump\_custom.cpp, and variable.cpp files. These are also
thermo.cpp, dump_custom.cpp, and variable.cpp files. These are also
listed on the :doc:`Modify page <Modify>`.
Here are additional guidelines for modifying LAMMPS and adding new

12
doc/src/Modify_pair.rst
View File

@ -7,7 +7,7 @@ such as EAM or Tersoff where particles interact without a static bond
topology. New styles can be created to add new pair potentials to
LAMMPS.
Pair\_lj\_cut.cpp is a simple example of a Pair class, though it
Pair_lj_cut.cpp is a simple example of a Pair class, though it
includes some optional methods to enable its use with rRESPA.
Here is a brief description of the class methods in pair.h:
@ -19,17 +19,17 @@ Here is a brief description of the class methods in pair.h:
+---------------------------------+-------------------------------------------------------------------+
| coeff | set coefficients for one i,j type pair |
+---------------------------------+-------------------------------------------------------------------+
| init\_one | perform initialization for one i,j type pair |
| init_one | perform initialization for one i,j type pair |
+---------------------------------+-------------------------------------------------------------------+
| init\_style | initialization specific to this pair style |
| init_style | initialization specific to this pair style |
+---------------------------------+-------------------------------------------------------------------+
| write & read\_restart | write/read i,j pair coeffs to restart files |
| write & read_restart | write/read i,j pair coeffs to restart files |
+---------------------------------+-------------------------------------------------------------------+
| write & read\_restart\_settings | write/read global settings to restart files |
| write & read_restart_settings | write/read global settings to restart files |
+---------------------------------+-------------------------------------------------------------------+
| single | force and energy of a single pairwise interaction between 2 atoms |
+---------------------------------+-------------------------------------------------------------------+
| compute\_inner/middle/outer | versions of compute used by rRESPA |
| compute_inner/middle/outer | versions of compute used by rRESPA |
+---------------------------------+-------------------------------------------------------------------+
The inner/middle/outer routines are optional.

8
doc/src/Modify_region.rst
View File

@ -6,7 +6,7 @@ class. Regions are used elsewhere in LAMMPS to group atoms, delete
atoms to create a void, insert atoms in a specified region, etc. New
styles can be created to add new region shapes to LAMMPS.
Region\_sphere.cpp is an example of a spherical region.
Region_sphere.cpp is an example of a spherical region.
Here is a brief description of methods you define in your new derived
class. See region.h for details.
@ -14,9 +14,9 @@ class. See region.h for details.
+-------------------+---------------------------------------------------------------------+
| inside | determine whether a point is in the region |
+-------------------+---------------------------------------------------------------------+
| surface\_interior | determine if a point is within a cutoff distance inside of surface |
| surface_interior | determine if a point is within a cutoff distance inside of surface |
+-------------------+---------------------------------------------------------------------+
| surface\_exterior | determine if a point is within a cutoff distance outside of surface |
| surface_exterior | determine if a point is within a cutoff distance outside of surface |
+-------------------+---------------------------------------------------------------------+
| shape\_update | change region shape if set by time-dependent variable |
| shape_update | change region shape if set by time-dependent variable |
+-------------------+---------------------------------------------------------------------+

32
doc/src/Packages_details.rst
View File

@ -10,7 +10,7 @@ scripts, and pictures/movies (if available) that illustrate use of the
package.
The majority of packages can be included in a LAMMPS build with a
single setting (-D PGK\_NAME for CMake) or command ("make yes-name" for
single setting (-D PGK_NAME for CMake) or command ("make yes-name" for
make). See the :doc:`Build package <Build_package>` doc page for more
info. A few packages may require additional steps; this is indicated
in the descriptions below. The :doc:`Build extras <Build_extras>` doc
@ -123,8 +123,8 @@ particle models including ellipsoids, 2d lines, and 3d triangles.
* :doc:`Howto spherical <Howto_spherical>`
* :doc:`pair_style gayberne <pair_gayberne>`
* :doc:`pair_style resquared <pair_resquared>`
* `doc/PDF/pair\_gayberne\_extra.pdf <PDF/pair_gayberne_extra.pdf>`_
* `doc/PDF/pair\_resquared\_extra.pdf <PDF/pair_resquared_extra.pdf>`_
* `doc/PDF/pair_gayberne_extra.pdf <PDF/pair_gayberne_extra.pdf>`_
* `doc/PDF/pair_resquared_extra.pdf <PDF/pair_resquared_extra.pdf>`_
* examples/ASPHERE
* examples/ellipse
* https://lammps.sandia.gov/movies.html#line
@ -147,7 +147,7 @@ overview.
**Supporting info:**
* src/BODY filenames -> commands
* :doc:`Howto\_body <Howto_body>`
* :doc:`Howto_body <Howto_body>`
* :doc:`atom_style body <atom_style>`
* :doc:`fix nve/body <fix_nve_body>`
* :doc:`pair_style body/nparticle <pair_body_nparticle>`
@ -367,7 +367,7 @@ This package contains a set of commands that serve as a wrapper on the
`Open Knowledgebase of Interatomic Models (OpenKIM) <https://openkim.org>`_
repository of interatomic models (IMs)
enabling compatible ones to be used in LAMMPS simulations.
This includes :doc:`kim_init and kim\_interactions <kim_commands>`
This includes :doc:`kim_init and kim_interactions <kim_commands>`
commands to select, initialize and instantiate the IM, and a
:doc:`kim_query <kim_commands>` command to perform web queries
for material property predictions of OpenKIM IMs.
@ -377,7 +377,7 @@ is provided by the :doc:`pair_style kim <pair_kim>` command.
.. note::
The command *pair\_style kim* is called by *kim\_interactions* and
The command *pair_style kim* is called by *kim_interactions* and
is not recommended to be directly used in input scripts.
To use this package you must have the KIM API library available on your
@ -392,7 +392,7 @@ The KIM project is led by Ellad Tadmor and Ryan Elliott (U Minnesota)
and is funded by the `National Science Foundation <https://www.nsf.gov/>`_.
**Authors:** Ryan Elliott (U Minnesota) is the main developer for the KIM
API and the *pair\_style kim* command. Axel Kohlmeyer (Temple U) and
API and the *pair_style kim* command. Axel Kohlmeyer (Temple U) and
Ellad Tadmor (U Minnesota) contributed to the :doc:`kim_commands <kim_commands>`
interface in close collaboration with Ryan Elliott.
@ -782,9 +782,9 @@ Foster (UTSA).
**Supporting info:**
* src/PERI: filenames -> commands
* `doc/PDF/PDLammps\_overview.pdf <PDF/PDLammps_overview.pdf>`_
* `doc/PDF/PDLammps\_EPS.pdf <PDF/PDLammps_EPS.pdf>`_
* `doc/PDF/PDLammps\_VES.pdf <PDF/PDLammps_VES.pdf>`_
* `doc/PDF/PDLammps_overview.pdf <PDF/PDLammps_overview.pdf>`_
* `doc/PDF/PDLammps_EPS.pdf <PDF/PDLammps_EPS.pdf>`_
* `doc/PDF/PDLammps_VES.pdf <PDF/PDLammps_VES.pdf>`_
* :doc:`atom_style peri <atom_style>`
* :doc:`pair_style peri/\* <pair_peri>`
* :doc:`compute damage/atom <compute_damage_atom>`
@ -1890,7 +1890,7 @@ And a :doc:`dynamical_matrix <dynamical_matrix>` as well as a
and third order tensor from finite differences.
**Authors:** Ling-Ti Kong (Shanghai Jiao Tong University) for "fix phonon"
and Charlie Sievers (UC Davis) for "dynamical\_matrix" and "third\_order"
and Charlie Sievers (UC Davis) for "dynamical_matrix" and "third_order"
**Supporting info:**
@ -1918,8 +1918,8 @@ Matching methodology.
**Supporting info:**
* src/USER-PTM: filenames not starting with ptm\\_ -> commands
* src/USER-PTM: filenames starting with ptm\\_ -> supporting code
* src/USER-PTM: filenames not starting with ptm\_ -> commands
* src/USER-PTM: filenames starting with ptm\_ -> supporting code
* src/USER-PTM/LICENSE
* :doc:`compute ptm/atom <compute_ptm_atom>`
@ -2132,7 +2132,7 @@ is an extension of smoothed particle hydrodynamics (SPH) to mesoscale
where thermal fluctuations are important (see the
:ref:`USER-SPH package <PKG-USER-SPH>`).
Also two fixes for moving and rigid body integration of SPH/SDPD particles
(particles of atom\_style meso).
(particles of atom_style meso).
**Author:** Morteza Jalalvand (Institute for Advanced Studies in Basic
Sciences, Iran).
@ -2180,7 +2180,7 @@ This package has :ref:`specific installation instructions <user-smd>` on the :do
* src/USER-SMD: filenames -> commands
* src/USER-SMD/README
* doc/PDF/SMD\_LAMMPS\_userguide.pdf
* doc/PDF/SMD_LAMMPS_userguide.pdf
* examples/USER/smd
* https://lammps.sandia.gov/movies.html#smd
@ -2237,7 +2237,7 @@ Dynamics, Ernst Mach Institute, Germany).
* src/USER-SPH: filenames -> commands
* src/USER-SPH/README
* doc/PDF/SPH\_LAMMPS\_userguide.pdf
* doc/PDF/SPH_LAMMPS_userguide.pdf
* examples/USER/sph
* https://lammps.sandia.gov/movies.html#sph

2
doc/src/Python_call.rst
View File

@ -59,7 +59,7 @@ new potential.
To use any of these commands, you only need to build LAMMPS with the
PYTHON package installed:
.. parsed-literal::
.. code-block:: bash
make yes-python
make machine

10
doc/src/Python_examples.rst
View File

@ -20,16 +20,16 @@ distribution.
+----------------------------------------------------------------+--------------------------------------------------+
| GUI go/stop/temperature-slider to control LAMMPS | plot.py |
+----------------------------------------------------------------+--------------------------------------------------+
| real-time temperature plot with GnuPlot via Pizza.py | viz\_tool.py |
| real-time temperature plot with GnuPlot via Pizza.py | viz_tool.py |
+----------------------------------------------------------------+--------------------------------------------------+
| real-time viz via some viz package | vizplotgui\_tool.py |
| real-time viz via some viz package | vizplotgui_tool.py |
+----------------------------------------------------------------+--------------------------------------------------+
| combination of viz\_tool.py and plot.py and gui.py | |
| combination of viz_tool.py and plot.py and gui.py | |
+----------------------------------------------------------------+--------------------------------------------------+
----------
For the viz\_tool.py and vizplotgui\_tool.py commands, replace "tool"
For the viz_tool.py and vizplotgui_tool.py commands, replace "tool"
with "gl" or "atomeye" or "pymol" or "vmd", depending on what
visualization package you have installed.
@ -79,7 +79,7 @@ variables that have to match the VMD installation on your system.
See the python/README file for instructions on how to run them and the
source code for individual scripts for comments about what they do.
Here are screenshots of the vizplotgui\_tool.py script in action for
Here are screenshots of the vizplotgui_tool.py script in action for
different visualization package options. Click to see larger images:
.. image:: JPG/screenshot_gl_small.jpg

2
doc/src/Python_head.rst
View File

@ -27,7 +27,7 @@ its library interface, or to hook multiple pieces of software
together, such as a simulation code plus a visualization tool, or to
run a coupled multiscale or multiphysics model.
See the :doc:`Howto\_couple <Howto_couple>` doc page for more ideas about
See the :doc:`Howto_couple <Howto_couple>` doc page for more ideas about
coupling LAMMPS to other codes. See the :doc:`Howto library <Howto_library>` doc page for a description of the LAMMPS
library interface provided in src/library.h and src/library.h. That
interface is exposed to Python either when calling LAMMPS from Python

10
doc/src/Python_install.rst
View File

@ -31,12 +31,12 @@ If you set the paths to these files as environment variables, you only
have to do it once. For the csh or tcsh shells, add something like
this to your ~/.cshrc file, one line for each of the two files:
.. parsed-literal::
.. code-block:: csh
setenv PYTHONPATH ${PYTHONPATH}:/home/sjplimp/lammps/python
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:/home/sjplimp/lammps/src
On MacOSX you may also need to set DYLD\_LIBRARY\_PATH accordingly.
On MacOSX you may also need to set DYLD_LIBRARY_PATH accordingly.
For Bourne/Korn shells accordingly into the corresponding files using
the "export" shell builtin.
@ -58,11 +58,11 @@ you can invoke install.py from the python directory manually as
* and the optional -d flag to a custom (legacy) installation folder
If you use a legacy installation folder, you will need to set your
PYTHONPATH and LD\_LIBRARY\_PATH (and/or DYLD\_LIBRARY\_PATH) environment
PYTHONPATH and LD_LIBRARY_PATH (and/or DYLD_LIBRARY_PATH) environment
variables accordingly, as described above.
Note that if you want Python to be able to load different versions of
the LAMMPS shared library (see :doc:`this section <Python_shlib>`), you will
need to manually copy files like liblammps\_g++.so into the appropriate
system directory. This is not needed if you set the LD\_LIBRARY\_PATH
need to manually copy files like liblammps_g++.so into the appropriate
system directory. This is not needed if you set the LD_LIBRARY_PATH
environment variable as described above.

44
doc/src/Python_library.rst
View File

@ -135,21 +135,21 @@ script, and coordinate and run multiple simulations, e.g.
lmp1.file("in.file1")
lmp2.file("in.file2")
The file(), command(), commands\_list(), commands\_string() methods
The file(), command(), commands_list(), commands_string() methods
allow an input script, a single command, or multiple commands to be
invoked.
The extract\_setting(), extract\_global(), extract\_box(),
extract\_atom(), extract\_compute(), extract\_fix(), and
extract\_variable() methods return values or pointers to data
The extract_setting(), extract_global(), extract_box(),
extract_atom(), extract_compute(), extract_fix(), and
extract_variable() methods return values or pointers to data
structures internal to LAMMPS.
For extract\_global() see the src/library.cpp file for the list of
For extract_global() see the src/library.cpp file for the list of
valid names. New names could easily be added. A double or integer is
returned. You need to specify the appropriate data type via the type
argument.
For extract\_atom(), a pointer to internal LAMMPS atom-based data is
For extract_atom(), a pointer to internal LAMMPS atom-based data is
returned, which you can use via normal Python subscripting. See the
extract() method in the src/atom.cpp file for a list of valid names.
Again, new names could easily be added if the property you want is not
@ -157,7 +157,7 @@ listed. A pointer to a vector of doubles or integers, or a pointer to
an array of doubles (double \*\*) or integers (int \*\*) is returned. You
need to specify the appropriate data type via the type argument.
For extract\_compute() and extract\_fix(), the global, per-atom, or
For extract_compute() and extract_fix(), the global, per-atom, or
local data calculated by the compute or fix can be accessed. What is
returned depends on whether the compute or fix calculates a scalar or
vector or array. For a scalar, a single double value is returned. If
@ -173,7 +173,7 @@ data types. See the doc pages for individual :doc:`computes <compute>`
and :doc:`fixes <fix>` for a description of what they calculate and
store.
For extract\_variable(), an :doc:`equal-style or atom-style variable <variable>` is evaluated and its result returned.
For extract_variable(), an :doc:`equal-style or atom-style variable <variable>` is evaluated and its result returned.
For equal-style variables a single double value is returned and the
group argument is ignored. For atom-style variables, a vector of
@ -181,17 +181,17 @@ doubles is returned, one value per atom, which you can use via normal
Python subscripting. The values will be zero for atoms not in the
specified group.
The get\_thermo() method returns the current value of a thermo
The get_thermo() method returns the current value of a thermo
keyword as a float.
The get\_natoms() method returns the total number of atoms in the
The get_natoms() method returns the total number of atoms in the
simulation, as an int.
The set\_variable() method sets an existing string-style variable to a
The set_variable() method sets an existing string-style variable to a
new string value, so that subsequent LAMMPS commands can access the
variable.
The reset\_box() method resets the size and shape of the simulation
The reset_box() method resets the size and shape of the simulation
box, e.g. as part of restoring a previously extracted and saved state
of a simulation.
@ -203,19 +203,19 @@ passed by all calling processors, to individual atoms, which may be
owned by different processors.
Note that the data returned by the gather methods,
e.g. gather\_atoms("x"), is different from the data structure returned
by extract\_atom("x") in four ways. (1) Gather\_atoms() returns a
vector which you index as x[i]; extract\_atom() returns an array
which you index as x[i][j]. (2) Gather\_atoms() orders the atoms
by atom ID while extract\_atom() does not. (3) Gather\_atoms() returns
a list of all atoms in the simulation; extract\_atoms() returns just
the atoms local to each processor. (4) Finally, the gather\_atoms()
e.g. gather_atoms("x"), is different from the data structure returned
by extract_atom("x") in four ways. (1) Gather_atoms() returns a
vector which you index as x[i]; extract_atom() returns an array
which you index as x[i][j]. (2) Gather_atoms() orders the atoms
by atom ID while extract_atom() does not. (3) Gather_atoms() returns
a list of all atoms in the simulation; extract_atoms() returns just
the atoms local to each processor. (4) Finally, the gather_atoms()
data structure is a copy of the atom coords stored internally in
LAMMPS, whereas extract\_atom() returns an array that effectively
LAMMPS, whereas extract_atom() returns an array that effectively
points directly to the internal data. This means you can change
values inside LAMMPS from Python by assigning a new values to the
extract\_atom() array. To do this with the gather\_atoms() vector, you
need to change values in the vector, then invoke the scatter\_atoms()
extract_atom() array. To do this with the gather_atoms() vector, you
need to change values in the vector, then invoke the scatter_atoms()
method.
For the scatter methods, the array of coordinates passed to must be a

12
doc/src/Python_mpi.rst
View File

@ -18,7 +18,7 @@ LAMMPS instances on subsets of the total MPI ranks.
To install mpi4py (version mpi4py-3.0.3 as of Nov 2019), unpack it
and from its main directory, type
.. parsed-literal::
.. code-block:: bash
python setup.py build
sudo python setup.py install
@ -27,27 +27,27 @@ Again, the "sudo" is only needed if required to copy mpi4py files into
your Python distribution's site-packages directory. To install with
user privilege into the user local directory type
.. parsed-literal::
.. code-block:: bash
python setup.py install --user
If you have successfully installed mpi4py, you should be able to run
Python and type
.. parsed-literal::
.. code-block:: python
from mpi4py import MPI
without error. You should also be able to run python in parallel
on a simple test script
.. parsed-literal::
.. code-block:: bash
% mpirun -np 4 python test.py
where test.py contains the lines
.. parsed-literal::
.. code-block:: python
from mpi4py import MPI
comm = MPI.COMM_WORLD
@ -64,7 +64,7 @@ and see one line of output for each processor you run on.
it is using, since you specify the details in your low-level
src/MAKE/Makefile.foo file. Mpi4py uses the "mpicc" command to find
information about the MPI it uses to build against. And it tries to
load "libmpi.so" from the LD\_LIBRARY\_PATH. This may or may not find
load "libmpi.so" from the LD_LIBRARY_PATH. This may or may not find
the MPI library that LAMMPS is using. If you have problems running
both mpi4py and LAMMPS together, this is an issue you may need to
address, e.g. by moving other MPI installations so that mpi4py finds

22
doc/src/Python_shlib.rst
View File

@ -5,19 +5,19 @@ Build LAMMPS as a shared library using make
-------------------------------------------
Instructions on how to build LAMMPS as a shared library are given on
the :doc:`Build\_basics <Build_basics>` doc page. A shared library is
the :doc:`Build_basics <Build_basics>` doc page. A shared library is
one that is dynamically loadable, which is what Python requires to
wrap LAMMPS. On Linux this is a library file that ends in ".so", not
".a".
From the src directory, type
.. parsed-literal::
.. code-block:: bash
make foo mode=shlib
where foo is the machine target name, such as mpi or serial.
This should create the file liblammps\_foo.so in the src directory, as
This should create the file liblammps_foo.so in the src directory, as
well as a soft link liblammps.so, which is what the Python wrapper will
load by default. Note that if you are building multiple machine
versions of the shared library, the soft link is always set to the
@ -29,7 +29,7 @@ most recently built version.
auxiliary libraries (used by various packages), then all of these
extra libraries must also be shared libraries. If the LAMMPS
shared-library build fails with an error complaining about this, see
the :doc:`Build\_basics <Build_basics>` doc page.
the :doc:`Build_basics <Build_basics>` doc page.
Build LAMMPS as a shared library using CMake
--------------------------------------------
@ -37,7 +37,7 @@ Build LAMMPS as a shared library using CMake
When using CMake the following two options are necessary to generate the LAMMPS
shared library:
.. parsed-literal::
.. code-block:: bash
-D BUILD_LIB=on # enable building LAMMPS as a library
-D BUILD_SHARED_LIBS=on # enable building of LAMMPS shared library (both options are needed!)
@ -45,12 +45,12 @@ shared library:
What this does is create a liblammps.so which contains the majority of LAMMPS
code. The generated lmp binary also dynamically links to this library. This
means that either this liblammps.so file has to be in the same directory, a system
library path (e.g. /usr/lib64/) or in the LD\_LIBRARY\_PATH.
library path (e.g. /usr/lib64/) or in the LD_LIBRARY_PATH.
If you want to use the shared library with Python the recommended way is to create a virtualenv and use it as
CMAKE\_INSTALL\_PREFIX.
CMAKE_INSTALL_PREFIX.
.. parsed-literal::
.. code-block:: bash
# create virtualenv
virtualenv --python=$(which python3) myenv3
@ -66,12 +66,12 @@ CMAKE\_INSTALL\_PREFIX.
make install
This will also install the Python module into your virtualenv. Since virtualenv
doesn't change your LD\_LIBRARY\_PATH, you still need to add its lib64 folder to
doesn't change your LD_LIBRARY_PATH, you still need to add its lib64 folder to
it, which contains the installed liblammps.so.
.. parsed-literal::
.. code-block:: bash
export LD_LIBRARY_PATH=$VIRTUAL_ENV/lib64:$LD_LIBRARY_PATH
Starting Python outside (!) of your build directory, but with the virtualenv
enabled and with the LD\_LIBRARY\_PATH set gives you access to LAMMPS via Python.
enabled and with the LD_LIBRARY_PATH set gives you access to LAMMPS via Python.

20
doc/src/Python_test.rst
View File

@ -31,8 +31,8 @@ first importing from the lammps.py file:
>>> CDLL("liblammps.so")
If an error occurs, carefully go through the steps on the
:doc:`Build\_basics <Build_basics>` doc page about building a shared
library and the :doc:`Python\_install <Python_install>` doc page about
:doc:`Build_basics <Build_basics>` doc page about building a shared
library and the :doc:`Python_install <Python_install>` doc page about
insuring Python can find the necessary two files it needs.
Test LAMMPS and Python in serial:
@ -49,7 +49,7 @@ interactively from the bench directory:
Or put the same lines in the file test.py and run it as
.. parsed-literal::
.. code-block:: bash
% python test.py
@ -68,7 +68,7 @@ To run LAMMPS in parallel, assuming you have installed the
`PyPar <https://github.com/daleroberts/pypar>`_ package as discussed
above, create a test.py file containing these lines:
.. parsed-literal::
.. code-block:: python
import pypar
from lammps import lammps
@ -81,7 +81,7 @@ To run LAMMPS in parallel, assuming you have installed the
`mpi4py <https://bitbucket.org/mpi4py/mpi4py>`_ package as discussed
above, create a test.py file containing these lines:
.. parsed-literal::
.. code-block:: python
from mpi4py import MPI
from lammps import lammps
@ -94,13 +94,13 @@ above, create a test.py file containing these lines:
You can either script in parallel as:
.. parsed-literal::
.. code-block:: bash
% mpirun -np 4 python test.py
and you should see the same output as if you had typed
.. parsed-literal::
.. code-block:: bash
% mpirun -np 4 lmp_g++ -in in.lj
@ -124,7 +124,7 @@ Running Python scripts:
Note that any Python script (not just for LAMMPS) can be invoked in
one of several ways:
.. parsed-literal::
.. code-block:: bash
% python foo.script
% python -i foo.script
@ -133,7 +133,7 @@ one of several ways:
The last command requires that the first line of the script be
something like this:
.. parsed-literal::
.. code-block:: bash
#!/usr/local/bin/python
#!/usr/local/bin/python -i
@ -141,7 +141,7 @@ something like this:
where the path points to where you have Python installed, and that you
have made the script file executable:
.. parsed-literal::
.. code-block:: bash
% chmod +x foo.script

2
doc/src/Run_basics.rst
View File

@ -65,7 +65,7 @@ or "-bind-to core" (MPICH) can be used.
If the LAMMPS command(s) you are using support multi-threading, you
can set the number of threads per MPI task via the environment
variable OMP\_NUM\_THREADS, before you launch LAMMPS:
variable OMP_NUM_THREADS, before you launch LAMMPS:
.. code-block:: bash

20
doc/src/Run_options.rst
View File

@ -23,7 +23,7 @@ letter abbreviation can be used:
* :ref:`-sf or -suffix <suffix>`
* :ref:`-v or -var <var>`
For example, the lmp\_mpi executable might be launched as follows:
For example, the lmp_mpi executable might be launched as follows:
.. code-block:: bash
@ -50,8 +50,8 @@ set by using the :doc:`echo <echo>` command in the input script itself.
**-help**
Print a brief help summary and a list of options compiled into this
executable for each LAMMPS style (atom\_style, fix, compute,
pair\_style, bond\_style, etc). This can tell you if the command you
executable for each LAMMPS style (atom_style, fix, compute,
pair_style, bond_style, etc). This can tell you if the command you
want to use was included via the appropriate package at compile time.
LAMMPS will print the info and immediately exit if this switch is
used.
@ -65,7 +65,7 @@ used.
Specify a file to use as an input script. This is an optional switch
when running LAMMPS in one-partition mode. If it is not specified,
LAMMPS reads its script from standard input, typically from a script
via I/O redirection; e.g. lmp\_linux < in.run. I/O redirection should
via I/O redirection; e.g. lmp_linux < in.run. I/O redirection should
also work in parallel, but if it does not (in the unlikely case that
an MPI implementation does not support it), then use the -in flag.
Note that this is a required switch when running LAMMPS in
@ -201,8 +201,8 @@ command which also launches another executable(s) at the same time.
(The other executable could be LAMMPS as well.) The color is an
integer value which should be different for each executable (another
application may set this value in a different way). LAMMPS and the
other executable(s) perform an MPI\_Comm\_split() with their own colors
to shrink the MPI\_COMM\_WORLD communication to be the subset of
other executable(s) perform an MPI_Comm_split() with their own colors
to shrink the MPI_COMM_WORLD communication to be the subset of
processors they are actually running on.
Currently, this is only used in LAMMPS to perform client/server
@ -284,7 +284,7 @@ log files are created. This overrides the filename specified in the
-log command-line option. This option is useful when working with
large numbers of partitions, allowing the partition log files to be
suppressed (-plog none) or placed in a sub-directory (-plog
replica\_files/log.lammps) If this option is not used the log file for
replica_files/log.lammps) If this option is not used the log file for
partition N is log.lammps.N or whatever is specified by the -log
command-line option.
@ -300,7 +300,7 @@ partition screen files are created. This overrides the filename
specified in the -screen command-line option. This option is useful
when working with large numbers of partitions, allowing the partition
screen files to be suppressed (-pscreen none) or placed in a
sub-directory (-pscreen replica\_files/screen). If this option is not
sub-directory (-pscreen replica_files/screen). If this option is not
used the screen file for partition N is screen.N or whatever is
specified by the -screen command-line option.
@ -469,7 +469,7 @@ The syntax following restartfile (or remap), namely
is identical to the arguments of the :doc:`write_dump <write_dump>`
command. See its doc page for details. This includes what per-atom
fields are written to the dump file and optional dump\_modify settings,
fields are written to the dump file and optional dump_modify settings,
including ones that affect how parallel dump files are written, e.g.
the *nfile* and *fileper* keywords. See the
:doc:`dump_modify <dump_modify>` doc page for details.
@ -520,7 +520,7 @@ having to edit an input script.
As an example, all of the packages provide a :doc:`pair_style lj/cut <pair_lj>` variant, with style names lj/cut/gpu,
lj/cut/intel, lj/cut/kk, lj/cut/omp, and lj/cut/opt. A variant style
can be specified explicitly in your input script, e.g. pair\_style
can be specified explicitly in your input script, e.g. pair_style
lj/cut/gpu. If the -suffix switch is used the specified suffix
(gpu,intel,kk,omp,opt) is automatically appended whenever your input
script command creates a new :doc:`atom <atom_style>`,

2
doc/src/Run_output.rst
View File

@ -168,7 +168,7 @@ additional information is printed, e.g.
The first line is the time spent doing 3d FFTs (several per timestep)
and the fraction it represents of the total KSpace time (listed
above). Each 3d FFT requires computation (3 sets of 1d FFTs) and
communication (transposes). The total flops performed is 5Nlog\_2(N),
communication (transposes). The total flops performed is 5Nlog_2(N),
where N is the number of points in the 3d grid. The FFTs are timed
with and without the communication and a Gflop rate is computed. The
3d rate is with communication; the 1d rate is without (just the 1d

10
doc/src/Run_windows.rst
View File

@ -7,14 +7,14 @@ To run a serial (non-MPI) executable, follow these steps:
then typing "cmd".
* Move to the directory where you have your input script,
(e.g. by typing: cd "Documents").
* At the command prompt, type "lmp\_serial -in in.file", where
* At the command prompt, type "lmp_serial -in in.file", where
in.file is the name of your LAMMPS input script.
Note that the serial executable includes support for multi-threading
parallelization from the styles in the USER-OMP packages. To run with
4 threads, you can type this:
.. parsed-literal::
.. code-block:: bash
lmp_serial -in in.lj -pk omp 4 -sf omp
@ -43,7 +43,7 @@ into the MPICH2 installation directory, then into the sub-directory
Then type something like this:
.. parsed-literal::
.. code-block:: bash
mpiexec -localonly 4 lmp_mpi -in in.file
mpiexec -np 4 lmp_mpi -in in.file
@ -58,13 +58,13 @@ patient before the output shows up.
The parallel executable can also run on a single processor by typing
something like this:
.. parsed-literal::
.. code-block:: bash
lmp_mpi -in in.lj
Note that the parallel executable also includes OpenMP
multi-threading, which can be combined with MPI using something like:
.. parsed-literal::
.. code-block:: bash
mpiexec -localonly 2 lmp_mpi -in in.lj -pk omp 2 -sf omp

2
doc/src/Speed_compare.rst
View File

@ -66,7 +66,7 @@ section below for examples where this has been done.
acceleration and instead run it - concurrently with a GPU accelerated
pair style - on the CPU. This can often be easily achieved with placing
a *suffix off* command before and a *suffix on* command after the
*kspace\_style pppm* command.
*kspace_style pppm* command.
* The KOKKOS/OpenMP and USER-OMP package have different thread management
strategies, which should result in USER-OMP being more efficient for a
small number of threads with increasing overhead as the number of threads

10
doc/src/Speed_gpu.rst
View File

@ -35,9 +35,9 @@ toolkit software on your system (this is primarily tested on Linux
and completely unsupported on Windows):
* Check if you have an NVIDIA GPU: cat /proc/driver/nvidia/gpus/\*/information
* Go to http://www.nvidia.com/object/cuda\_get.html
* Go to http://www.nvidia.com/object/cuda_get.html
* Install a driver and toolkit appropriate for your system (SDK is not necessary)
* Run lammps/lib/gpu/nvc\_get\_devices (after building the GPU library, see below) to
* Run lammps/lib/gpu/nvc_get_devices (after building the GPU library, see below) to
list supported devices and properties
To compile and use this package in OpenCL mode, you currently need
@ -47,7 +47,7 @@ installed. There can be multiple of them for the same or different hardware
(GPUs, CPUs, Accelerators) installed at the same time. OpenCL refers to those
as 'platforms'. The GPU library will select the **first** suitable platform,
but this can be overridden using the device option of the :doc:`package <package>`
command. run lammps/lib/gpu/ocl\_get\_devices to get a list of available
command. run lammps/lib/gpu/ocl_get_devices to get a list of available
platforms and devices with a suitable ICD available.
**Building LAMMPS with the GPU package:**
@ -76,7 +76,7 @@ automatically append "gpu" to styles that support it. Use the "-pk
gpu Ng" :doc:`command-line switch <Run_options>` to set Ng = # of
GPUs/node to use.
.. parsed-literal::
.. code-block:: bash
lmp_machine -sf gpu -pk gpu 1 -in in.script # 1 MPI task uses 1 GPU
mpirun -np 12 lmp_machine -sf gpu -pk gpu 2 -in in.script # 12 MPI tasks share 2 GPUs on a single 16-core (or whatever) node
@ -106,7 +106,7 @@ and use of multiple MPI tasks/GPU is the same.
Use the :doc:`suffix gpu <suffix>` command, or you can explicitly add an
"gpu" suffix to individual styles in your input script, e.g.
.. parsed-literal::
.. code-block:: LAMMPS
pair_style lj/cut/gpu 2.5

48
doc/src/Speed_intel.rst
View File

@ -79,7 +79,7 @@ order of operations compared to LAMMPS without acceleration:
* The *newton* setting applies to all atoms, not just atoms shared
between MPI tasks
* Vectorization can change the order for adding pairwise forces
* When using the -DLMP\_USE\_MKL\_RNG define (all included intel optimized
* When using the -DLMP_USE_MKL_RNG define (all included intel optimized
makefiles do) at build time, the random number generator for
dissipative particle dynamics (pair style dpd/intel) uses the Mersenne
Twister generator included in the Intel MKL library (that should be
@ -102,8 +102,8 @@ LAMMPS should be built with the USER-INTEL package installed.
Simulations should be run with 1 MPI task per physical *core*\ ,
not *hardware thread*\ .
* Edit src/MAKE/OPTIONS/Makefile.intel\_cpu\_intelmpi as necessary.
* Set the environment variable KMP\_BLOCKTIME=0
* Edit src/MAKE/OPTIONS/Makefile.intel_cpu_intelmpi as necessary.
* Set the environment variable KMP_BLOCKTIME=0
* "-pk intel 0 omp $t -sf intel" added to LAMMPS command-line
* $t should be 2 for Intel Xeon CPUs and 2 or 4 for Intel Xeon Phi
* For some of the simple 2-body potentials without long-range
@ -111,26 +111,26 @@ not *hardware thread*\ .
the "newton off" setting added to the input script
* For simulations on higher node counts, add "processors \* \* \* grid
numa" to the beginning of the input script for better scalability
* If using *kspace\_style pppm* in the input script, add
"kspace\_modify diff ad" for better performance
* If using *kspace_style pppm* in the input script, add
"kspace_modify diff ad" for better performance
For Intel Xeon Phi CPUs:
* Runs should be performed using MCDRAM.
For simulations using *kspace\_style pppm* on Intel CPUs supporting
For simulations using *kspace_style pppm* on Intel CPUs supporting
AVX-512:
* Add "kspace\_modify diff ad" to the input script
* Add "kspace_modify diff ad" to the input script
* The command-line option should be changed to
"-pk intel 0 omp $r lrt yes -sf intel" where $r is the number of
threads minus 1.
* Do not use thread affinity (set KMP\_AFFINITY=none)
* Do not use thread affinity (set KMP_AFFINITY=none)
* The "newton off" setting may provide better scalability
For Intel Xeon Phi co-processors (Offload):
* Edit src/MAKE/OPTIONS/Makefile.intel\_co-processor as necessary
* Edit src/MAKE/OPTIONS/Makefile.intel_co-processor as necessary
* "-pk intel N omp 1" added to command-line where N is the number of
co-processors per node.
@ -205,7 +205,7 @@ For building with make, several example Makefiles for building with
the Intel compiler are included with LAMMPS in the src/MAKE/OPTIONS/
directory:
.. parsed-literal::
.. code-block:: bash
Makefile.intel_cpu_intelmpi # Intel Compiler, Intel MPI, No Offload
Makefile.knl # Intel Compiler, Intel MPI, No Offload
@ -213,7 +213,7 @@ directory:
Makefile.intel_cpu_openpmi # Intel Compiler, OpenMPI, No Offload
Makefile.intel_co-processor # Intel Compiler, Intel MPI, Offload
Makefile.knl is identical to Makefile.intel\_cpu\_intelmpi except that
Makefile.knl is identical to Makefile.intel_cpu_intelmpi except that
it explicitly specifies that vectorization should be for Intel Xeon
Phi x200 processors making it easier to cross-compile. For users with
recent installations of Intel Parallel Studio, the process can be as
@ -234,12 +234,12 @@ without offload support will produce a smaller binary.
The general requirements for Makefiles with the USER-INTEL package
are as follows. When using Intel compilers, "-restrict" is required
and "-qopenmp" is highly recommended for CCFLAGS and LINKFLAGS.
CCFLAGS should include "-DLMP\_INTEL\_USELRT" (unless POSIX Threads
are not supported in the build environment) and "-DLMP\_USE\_MKL\_RNG"
CCFLAGS should include "-DLMP_INTEL_USELRT" (unless POSIX Threads
are not supported in the build environment) and "-DLMP_USE_MKL_RNG"
(unless Intel Math Kernel Library (MKL) is not available in the build
environment). For Intel compilers, LIB should include "-ltbbmalloc"
or if the library is not available, "-DLMP\_INTEL\_NO\_TBB" can be added
to CCFLAGS. For builds supporting offload, "-DLMP\_INTEL\_OFFLOAD" is
or if the library is not available, "-DLMP_INTEL_NO_TBB" can be added
to CCFLAGS. For builds supporting offload, "-DLMP_INTEL_OFFLOAD" is
required for CCFLAGS and "-qoffload" is required for LINKFLAGS. Other
recommended CCFLAG options for best performance are "-O2 -fno-alias
-ansi-alias -qoverride-limits fp-model fast=2 -no-prec-div".
@ -297,9 +297,9 @@ almost all cases.
OpenMP threads on the host (CPU) will be set by default on the host
*when using offload to a co-processor*\ . In this case, it is unnecessary
to use other methods to control affinity (e.g. taskset, numactl,
I\_MPI\_PIN\_DOMAIN, etc.). This can be disabled with the *no\_affinity*
I_MPI_PIN_DOMAIN, etc.). This can be disabled with the *no_affinity*
option to the :doc:`package intel <package>` command or by disabling the
option at build time (by adding -DINTEL\_OFFLOAD\_NOAFFINITY to the
option at build time (by adding -DINTEL_OFFLOAD_NOAFFINITY to the
CCFLAGS line of your Makefile). Disabling this option is not
recommended, especially when running on a machine with Intel
Hyper-Threading technology disabled.
@ -313,7 +313,7 @@ editing the input script. This switch will automatically append
:doc:`package intel 1 <package>`. This package command is used to set
options for the USER-INTEL package. The default package command will
specify that USER-INTEL calculations are performed in mixed precision,
that the number of OpenMP threads is specified by the OMP\_NUM\_THREADS
that the number of OpenMP threads is specified by the OMP_NUM_THREADS
environment variable, and that if co-processors are present and the
binary was built with offload support, that 1 co-processor per node
will be used with automatic balancing of work between the CPU and the
@ -324,11 +324,11 @@ the "-pk intel Nphi" :doc:`command-line switch <Run_options>` with
keyword/value pairs as specified in the documentation. Here, Nphi = #
of Xeon Phi co-processors/node (ignored without offload
support). Common options to the USER-INTEL package include *omp* to
override any OMP\_NUM\_THREADS setting and specify the number of OpenMP
override any OMP_NUM_THREADS setting and specify the number of OpenMP
threads, *mode* to set the floating-point precision mode, and *lrt* to
enable Long-Range Thread mode as described below. See the :doc:`package intel <package>` command for details, including the default values
used for all its options if not specified, and how to set the number
of OpenMP threads via the OMP\_NUM\_THREADS environment variable if
of OpenMP threads via the OMP_NUM_THREADS environment variable if
desired.
Examples (see documentation for your MPI/Machine for differences in
@ -375,7 +375,7 @@ Long-Range Thread (LRT) mode is an option to the :doc:`package intel <package>`
with SMT. It generates an extra pthread for each MPI task. The thread
is dedicated to performing some of the PPPM calculations and MPI
communications. This feature requires setting the pre-processor flag
-DLMP\_INTEL\_USELRT in the makefile when compiling LAMMPS. It is unset
-DLMP_INTEL_USELRT in the makefile when compiling LAMMPS. It is unset
in the default makefiles (\ *Makefile.mpi* and *Makefile.serial*\ ) but
it is set in all makefiles tuned for the USER-INTEL package. On Intel
Xeon Phi x200 series CPUs, the LRT feature will likely improve
@ -387,7 +387,7 @@ normally be used for the run and add the "lrt yes" option to the "-pk"
command-line suffix or "package intel" command. For example, if a run
would normally perform best with "-pk intel 0 omp 4", instead use
"-pk intel 0 omp 3 lrt yes". When using LRT, you should set the
environment variable "KMP\_AFFINITY=none". LRT mode is not supported
environment variable "KMP_AFFINITY=none". LRT mode is not supported
when using offload.
.. note::
@ -425,7 +425,7 @@ alternative to LRT mode and the two cannot be used together.
Currently, when using Intel MPI with Intel Xeon Phi x200 series
CPUs, better performance might be obtained by setting the
environment variable "I\_MPI\_SHM\_LMT=shm" for Linux kernels that do
environment variable "I_MPI_SHM_LMT=shm" for Linux kernels that do
not yet have full support for AVX-512. Runs on Intel Xeon Phi x200
series processors will always perform better using MCDRAM. Please
consult your system documentation for the best approach to specify
@ -513,7 +513,7 @@ When offloading to a co-processor, :doc:`hybrid <pair_hybrid>` styles
that require skip lists for neighbor builds cannot be offloaded.
Using :doc:`hybrid/overlay <pair_hybrid>` is allowed. Only one intel
accelerated style may be used with hybrid styles when offloading.
:doc:`Special\_bonds <special_bonds>` exclusion lists are not currently
:doc:`Special_bonds <special_bonds>` exclusion lists are not currently
supported with offload, however, the same effect can often be
accomplished by setting cutoffs for excluded atom types to 0. None of
the pair styles in the USER-INTEL package currently support the

54
doc/src/Speed_kokkos.rst
View File

@ -21,7 +21,7 @@ package was developed primarily by Christian Trott (Sandia) and Stan
Moore (Sandia) with contributions of various styles by others,
including Sikandar Mashayak (UIUC), Ray Shan (Sandia), and Dan Ibanez
(Sandia). For more information on developing using Kokkos abstractions
see the Kokkos programmers' guide at /lib/kokkos/doc/Kokkos\_PG.pdf.
see the Kokkos programmers' guide at /lib/kokkos/doc/Kokkos_PG.pdf.
Kokkos currently provides support for 3 modes of execution (per MPI
task). These are Serial (MPI-only for CPUs and Intel Phi), OpenMP
@ -108,8 +108,8 @@ below.
.. note::
When using a single OpenMP thread, the Kokkos Serial back end (i.e.
Makefile.kokkos\_mpi\_only) will give better performance than the OpenMP
back end (i.e. Makefile.kokkos\_omp) because some of the overhead to make
Makefile.kokkos_mpi_only) will give better performance than the OpenMP
back end (i.e. Makefile.kokkos_omp) because some of the overhead to make
the code thread-safe is removed.
.. note::
@ -134,8 +134,8 @@ small numbers of threads (i.e. 8 or less) but does increase memory
footprint and is not scalable to large numbers of threads. An
alternative to data duplication is to use thread-level atomic operations
which do not require data duplication. The use of atomic operations can
be enforced by compiling LAMMPS with the "-DLMP\_KOKKOS\_USE\_ATOMICS"
pre-processor flag. Most but not all Kokkos-enabled pair\_styles support
be enforced by compiling LAMMPS with the "-DLMP_KOKKOS_USE_ATOMICS"
pre-processor flag. Most but not all Kokkos-enabled pair_styles support
data duplication. Alternatively, full neighbor lists avoid the need for
duplication or atomic operations but require more compute operations per
atom. When using the Kokkos Serial back end or the OpenMP back end with
@ -159,9 +159,9 @@ for your MPI installation), binding can be forced with these flags:
For binding threads with KOKKOS OpenMP, use thread affinity
environment variables to force binding. With OpenMP 3.1 (gcc 4.7 or
later, intel 12 or later) setting the environment variable
OMP\_PROC\_BIND=true should be sufficient. In general, for best
performance with OpenMP 4.0 or better set OMP\_PROC\_BIND=spread and
OMP\_PLACES=threads. For binding threads with the KOKKOS pthreads
OMP_PROC_BIND=true should be sufficient. In general, for best
performance with OpenMP 4.0 or better set OMP_PROC_BIND=spread and
OMP_PLACES=threads. For binding threads with the KOKKOS pthreads
option, compile LAMMPS the KOKKOS HWLOC=yes option as described below.
**Running on Knight's Landing (KNL) Intel Xeon Phi:**
@ -290,7 +290,7 @@ one or more nodes, each with two GPUs:
.. note::
To get an accurate timing breakdown between time spend in pair,
kspace, etc., you must set the environment variable CUDA\_LAUNCH\_BLOCKING=1.
kspace, etc., you must set the environment variable CUDA_LAUNCH_BLOCKING=1.
However, this will reduce performance and is not recommended for production runs.
**Run with the KOKKOS package by editing an input script:**
@ -320,8 +320,8 @@ wish to change any of its option defaults, as set by the "-k on"
With the KOKKOS package, both OpenMP multi-threading and GPUs can be
used together in a few special cases. In the Makefile, the
KOKKOS\_DEVICES variable must include both "Cuda" and "OpenMP", as is
the case for /src/MAKE/OPTIONS/Makefile.kokkos\_cuda\_mpi
KOKKOS_DEVICES variable must include both "Cuda" and "OpenMP", as is
the case for /src/MAKE/OPTIONS/Makefile.kokkos_cuda_mpi
.. code-block:: bash
@ -357,7 +357,7 @@ GPU. First compile with "--default-stream per-thread" added to CCFLAGS
in the Kokkos CUDA Makefile. Then explicitly use the "/kk/host"
suffix for kspace and bonds, angles, etc. in the input file and the
"kk" suffix (equal to "kk/device") on the command line. Also make
sure the environment variable CUDA\_LAUNCH\_BLOCKING is not set to "1"
sure the environment variable CUDA_LAUNCH_BLOCKING is not set to "1"
so CPU/GPU overlap can occur.
**Speed-ups to expect:**
@ -394,34 +394,34 @@ Makefile.machine, or they can be specified as CMake variables. Each
takes a value shown below. The default value is listed, which is set
in the lib/kokkos/Makefile.kokkos file.
* KOKKOS\_DEBUG, values = *yes*\ , *no*\ , default = *no*
* KOKKOS\_USE\_TPLS, values = *hwloc*\ , *librt*\ , *experimental\_memkind*, default = *none*
* KOKKOS\_CXX\_STANDARD, values = *c++11*\ , *c++1z*\ , default = *c++11*
* KOKKOS\_OPTIONS, values = *aggressive\_vectorization*, *disable\_profiling*, default = *none*
* KOKKOS\_CUDA\_OPTIONS, values = *force\_uvm*, *use\_ldg*, *rdc*\ , *enable\_lambda*, default = *enable\_lambda*
* KOKKOS_DEBUG, values = *yes*\ , *no*\ , default = *no*
* KOKKOS_USE_TPLS, values = *hwloc*\ , *librt*\ , *experimental_memkind*, default = *none*
* KOKKOS_CXX_STANDARD, values = *c++11*\ , *c++1z*\ , default = *c++11*
* KOKKOS_OPTIONS, values = *aggressive_vectorization*, *disable_profiling*, default = *none*
* KOKKOS_CUDA_OPTIONS, values = *force_uvm*, *use_ldg*, *rdc*\ , *enable_lambda*, default = *enable_lambda*
KOKKOS\_USE\_TPLS=hwloc binds threads to hardware cores, so they do not
migrate during a simulation. KOKKOS\_USE\_TPLS=hwloc should always be
used if running with KOKKOS\_DEVICES=Pthreads for pthreads. It is not
necessary for KOKKOS\_DEVICES=OpenMP for OpenMP, because OpenMP
KOKKOS_USE_TPLS=hwloc binds threads to hardware cores, so they do not
migrate during a simulation. KOKKOS_USE_TPLS=hwloc should always be
used if running with KOKKOS_DEVICES=Pthreads for pthreads. It is not
necessary for KOKKOS_DEVICES=OpenMP for OpenMP, because OpenMP
provides alternative methods via environment variables for binding
threads to hardware cores. More info on binding threads to cores is
given on the :doc:`Speed omp <Speed_omp>` doc page.
KOKKOS\_USE\_TPLS=librt enables use of a more accurate timer mechanism
KOKKOS_USE_TPLS=librt enables use of a more accurate timer mechanism
on most Unix platforms. This library is not available on all
platforms.
KOKKOS\_DEBUG is only useful when developing a Kokkos-enabled style
within LAMMPS. KOKKOS\_DEBUG=yes enables printing of run-time
KOKKOS_DEBUG is only useful when developing a Kokkos-enabled style
within LAMMPS. KOKKOS_DEBUG=yes enables printing of run-time
debugging information that can be useful. It also enables runtime
bounds checking on Kokkos data structures.
KOKKOS\_CXX\_STANDARD and KOKKOS\_OPTIONS are typically not changed when
KOKKOS_CXX_STANDARD and KOKKOS_OPTIONS are typically not changed when
building LAMMPS.
KOKKOS\_CUDA\_OPTIONS are additional options for CUDA. The LAMMPS KOKKOS
package must be compiled with the *enable\_lambda* option when using
KOKKOS_CUDA_OPTIONS are additional options for CUDA. The LAMMPS KOKKOS
package must be compiled with the *enable_lambda* option when using
GPUs.
Restrictions

4
doc/src/Speed_measure.rst
View File

@ -14,7 +14,7 @@ timings; you can simply extrapolate from short runs.
For the set of runs, look at the timing data printed to the screen and
log file at the end of each LAMMPS run. The
:doc:`Run\_output <Run_output>` doc page gives an overview.
:doc:`Run_output <Run_output>` doc page gives an overview.
Running on one (or a few processors) should give a good estimate of
the serial performance and what portions of the timestep are taking
@ -42,5 +42,5 @@ inaccurate relative timing data, because processors have to wait when
communication occurs for other processors to catch up. Thus the
reported times for "Communication" or "Other" may be higher than they
really are, due to load-imbalance. If this is an issue, you can
uncomment the MPI\_Barrier() lines in src/timer.cpp, and re-compile
uncomment the MPI_Barrier() lines in src/timer.cpp, and re-compile
LAMMPS, to obtain synchronized timings.

10
doc/src/Speed_omp.rst
View File

@ -23,7 +23,7 @@ instructions.
These examples assume one or more 16-core nodes.
.. parsed-literal::
.. code-block:: bash
env OMP_NUM_THREADS=16 lmp_omp -sf omp -in in.script # 1 MPI task, 16 threads according to OMP_NUM_THREADS
lmp_mpi -sf omp -in in.script # 1 MPI task, no threads, optimized kernels
@ -43,14 +43,14 @@ node), otherwise performance will suffer.
As in the lines above, use the "-sf omp" :doc:`command-line switch <Run_options>`, which will automatically append "omp" to
styles that support it. The "-sf omp" switch also issues a default
:doc:`package omp 0 <package>` command, which will set the number of
threads per MPI task via the OMP\_NUM\_THREADS environment variable.
threads per MPI task via the OMP_NUM_THREADS environment variable.
You can also use the "-pk omp Nt" :doc:`command-line switch <Run_options>`, to explicitly set Nt = # of OpenMP threads
per MPI task to use, as well as additional options. Its syntax is the
same as the :doc:`package omp <package>` command whose doc page gives
details, including the default values used if it is not specified. It
also gives more details on how to set the number of threads via the
OMP\_NUM\_THREADS environment variable.
OMP_NUM_THREADS environment variable.
**Or run with the USER-OMP package by editing an input script:**
@ -60,14 +60,14 @@ and threads/MPI task is the same.
Use the :doc:`suffix omp <suffix>` command, or you can explicitly add an
"omp" suffix to individual styles in your input script, e.g.
.. parsed-literal::
.. code-block:: LAMMPS
pair_style lj/cut/omp 2.5
You must also use the :doc:`package omp <package>` command to enable the
USER-OMP package. When you do this you also specify how many threads
per MPI task to use. The command doc page explains other options and
how to set the number of threads via the OMP\_NUM\_THREADS environment
how to set the number of threads via the OMP_NUM_THREADS environment
variable.
**Speed-ups to expect:**

4
doc/src/Speed_opt.rst
View File

@ -17,7 +17,7 @@ See the :ref:`Build extras <opt>` doc page for instructions.
**Run with the OPT package from the command line:**
.. parsed-literal::
.. code-block:: bash
lmp_mpi -sf opt -in in.script # run in serial
mpirun -np 4 lmp_mpi -sf opt -in in.script # run in parallel
@ -30,7 +30,7 @@ automatically append "opt" to styles that support it.
Use the :doc:`suffix opt <suffix>` command, or you can explicitly add an
"opt" suffix to individual styles in your input script, e.g.
.. parsed-literal::
.. code-block:: LAMMPS
pair_style lj/cut/opt 2.5

6
doc/src/Speed_packages.rst
View File

@ -90,13 +90,13 @@ listed above:
+--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
| re-build LAMMPS | make machine |
+--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
| prepare and test a regular LAMMPS simulation | lmp\_machine -in in.script; mpirun -np 32 lmp\_machine -in in.script |
| prepare and test a regular LAMMPS simulation | lmp_machine -in in.script; mpirun -np 32 lmp_machine -in in.script |
+--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
| enable specific accelerator support via '-k on' :doc:`command-line switch <Run_options>`, | only needed for KOKKOS package |
+--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
| set any needed options for the package via "-pk" :doc:`command-line switch <Run_options>` or :doc:`package <package>` command, | only if defaults need to be changed |
+--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
| use accelerated styles in your input via "-sf" :doc:`command-line switch <Run_options>` or :doc:`suffix <suffix>` command | lmp\_machine -in in.script -sf gpu |
| use accelerated styles in your input via "-sf" :doc:`command-line switch <Run_options>` or :doc:`suffix <suffix>` command | lmp_machine -in in.script -sf gpu |
+--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
Note that the first 4 steps can be done as a single command with
@ -132,7 +132,7 @@ packages. As an example, here is a command that builds with all the
GPU related packages installed (GPU, KOKKOS with Cuda), including
settings to build the needed auxiliary GPU libraries for Kepler GPUs:
.. parsed-literal::
.. code-block:: bash
Make.py -j 16 -p omp gpu kokkos -cc nvcc wrap=mpi -gpu mode=double arch=35 -kokkos cuda arch=35 lib-all file mpi

32
doc/src/Tools.rst
View File

@ -99,7 +99,7 @@ binary2txt tool
The file binary2txt.cpp converts one or more binary LAMMPS dump file
into ASCII text files. The syntax for running the tool is
.. parsed-literal::
.. code-block:: bash
binary2txt file1 file2 ...
@ -149,7 +149,7 @@ chains and solvent atoms can strongly overlap, so LAMMPS needs to run
the system initially with a "soft" pair potential to un-overlap it.
The syntax for running the tool is
.. parsed-literal::
.. code-block:: bash
chain < def.chain > data.file
@ -171,18 +171,18 @@ To compile the tools, edit the makefile for your system and run "make".
Please report problems and issues the colvars library and its tools
at: https://github.com/colvars/colvars/issues
abf\_integrate:
abf_integrate:
MC-based integration of multidimensional free energy gradient
Version 20110511
.. parsed-literal::
Syntax: ./abf_integrate < filename > [-n < nsteps >] [-t < temp >] [-m [0\|1] (metadynamics)] [-h < hill_height >] [-f < variable_hill_factor >]
./abf_integrate < filename > [-n < nsteps >] [-t < temp >] [-m [0\|1] (metadynamics)] [-h < hill_height >] [-f < variable_hill_factor >]
The LAMMPS interface to the colvars collective variable library, as
well as these tools, were created by Axel Kohlmeyer (akohlmey at
gmail.com) at ICTP, Italy.
gmail.com) while at ICTP, Italy.
----------
@ -238,7 +238,7 @@ at univ-bpclermont.fr, alain.dequidt at univ-bpclermont.fr
eam database tool
-----------------------------
The tools/eam\_database directory contains a Fortran program that will
The tools/eam_database directory contains a Fortran program that will
generate EAM alloy setfl potential files for any combination of 16
elements: Cu, Ag, Au, Ni, Pd, Pt, Al, Pb, Fe, Mo, Ta, W, Mg, Co, Ti,
Zr. The files can then be used with the :doc:`pair_style eam/alloy <pair_eam>` command.
@ -256,7 +256,7 @@ X. W. Zhou, R. A. Johnson, and H. N. G. Wadley, Phys. Rev. B, 69,
eam generate tool
-----------------------------
The tools/eam\_generate directory contains several one-file C programs
The tools/eam_generate directory contains several one-file C programs
that convert an analytic formula into a tabulated :doc:`embedded atom method (EAM) <pair_eam>` setfl potential file. The potentials they
produce are in the potentials directory, and can be used with the
:doc:`pair_style eam/alloy <pair_eam>` command.
@ -427,7 +427,7 @@ atoms can strongly overlap, so LAMMPS needs to run the system
initially with a "soft" pair potential to un-overlap it. The syntax
for running the tool is
.. parsed-literal::
.. code-block:: bash
micelle2d < def.micelle2d > data.file
@ -512,10 +512,10 @@ This tool was written by Zachary Kraus at Georgia Tech.
.. _pymol:
pymol\_asphere tool
pymol_asphere tool
-------------------------------
The pymol\_asphere sub-directory contains a tool for converting a
The pymol_asphere sub-directory contains a tool for converting a
LAMMPS dump file that contains orientation info for ellipsoidal
particles into an input file for the `PyMol visualization package <pymolhome_>`_ or its `open source variant <pymolopen_>`_.
@ -525,7 +525,7 @@ particles into an input file for the `PyMol visualization package <pymolhome_>`_
Specifically, the tool triangulates the ellipsoids so they can be
viewed as true ellipsoidal particles within PyMol. See the README and
examples directory within pymol\_asphere for more information.
examples directory within pymol_asphere for more information.
This tool was written by Mike Brown at Sandia.
@ -555,7 +555,7 @@ README for more info on Pizza.py and how to use these scripts.
replica tool
--------------------------
The tools/replica directory contains the reorder\_remd\_traj python script which
The tools/replica directory contains the reorder_remd_traj python script which
can be used to reorder the replica trajectories (resulting from the use of the
temper command) according to temperature. This will produce discontinuous
trajectories with all frames at the same temperature in each trajectory.
@ -568,7 +568,7 @@ while at the Shell lab at UC Santa Barbara. (tanmoy dot 7989 at gmail.com)
----------
.. _reax\_tool:
.. _reax_tool:
reax tool
--------------------------
@ -587,7 +587,7 @@ These tools were written by Aidan Thompson at Sandia.
smd tool
------------------
The smd sub-directory contains a C++ file dump2vtk\_tris.cpp and
The smd sub-directory contains a C++ file dump2vtk_tris.cpp and
Makefile which can be compiled and used to convert triangle output
files created by the Smooth-Mach Dynamics (USER-SMD) package into a
VTK-compatible unstructured grid file. It could then be read in and
@ -610,7 +610,7 @@ The spin sub-directory contains a C file interpolate.c which can
be compiled and used to perform a cubic polynomial interpolation of
the MEP following a GNEB calculation.
See the README file in tools/spin/interpolate\_gneb for more details.
See the README file in tools/spin/interpolate_gneb for more details.
This tool was written by the SPIN package author, Julien
Tranchida at Sandia National Labs (jtranch at sandia.gov, and by Aleksei
@ -618,7 +618,7 @@ Ivanov, at University of Iceland (ali5 at hi.is).
----------
.. _singularity\_tool:
.. _singularity_tool:
singularity tool
----------------------------------------

2
doc/src/angle_charmm.rst
View File

@ -36,7 +36,7 @@ The *charmm* angle style uses the potential
E = K (\theta - \theta_0)^2 + K_{ub} (r - r_{ub})^2
with an additional Urey\_Bradley term based on the distance :math:`r` between
with an additional Urey_Bradley term based on the distance :math:`r` between
the 1st and 3rd atoms in the angle. :math:`K`, :math:`\theta_0`,
:math:`K_{ub}`, and :math:`R_{ub}` are coefficients defined for each angle
type.

2
doc/src/angle_cross.rst
View File

@ -53,7 +53,7 @@ Restrictions
""""""""""""
This angle style can only be used if LAMMPS was built with the
USER\_YAFF package. See the :doc:`Build package <Build_package>` doc
USER_YAFF package. See the :doc:`Build package <Build_package>` doc
page for more info.
Related commands

2
doc/src/angle_fourier.rst
View File

@ -66,7 +66,7 @@ Restrictions
""""""""""""
This angle style can only be used if LAMMPS was built with the
USER\_MISC package. See the :doc:`Build package <Build_package>` doc
USER_MISC package. See the :doc:`Build package <Build_package>` doc
page for more info.
Related commands

2
doc/src/angle_fourier_simple.rst
View File

@ -65,7 +65,7 @@ Restrictions
""""""""""""
This angle style can only be used if LAMMPS was built with the
USER\_MISC package. See the :doc:`Build package <Build_package>` doc
USER_MISC package. See the :doc:`Build package <Build_package>` doc
page for more info.
Related commands

2
doc/src/angle_hybrid.rst
View File

@ -34,7 +34,7 @@ command or in the data file.
In the :doc:`angle_coeff <angle_coeff>` commands, the name of an angle style must be added
after the angle type, with the remaining coefficients being those
appropriate to that style. In the example above, the 2 angle\_coeff
appropriate to that style. In the example above, the 2 angle_coeff
commands set angles of angle type 1 to be computed with a *harmonic*
potential with coefficients 80.0, 30.0 for :math:`K`, :math:`\theta_0`. All other angle
types :math:`(2 - N)` are computed with a *cosine* potential with coefficient

2
doc/src/angle_mm3.rst
View File

@ -47,7 +47,7 @@ Restrictions
""""""""""""
This angle style can only be used if LAMMPS was built with the
USER\_YAFF package. See the :doc:`Build package <Build_package>` doc
USER_YAFF package. See the :doc:`Build package <Build_package>` doc
page for more info.
Related commands

2
doc/src/angle_quartic.rst
View File

@ -72,7 +72,7 @@ Restrictions
""""""""""""
This angle style can only be used if LAMMPS was built with the
USER\_MISC package. See the :doc:`Build package <Build_package>` doc
USER_MISC package. See the :doc:`Build package <Build_package>` doc
page for more info.
Related commands

4
doc/src/angle_sdk.rst
View File

@ -37,7 +37,7 @@ where :math:`\theta_0` is the equilibrium value of the angle and
*lj/sdk* pair style between the atoms 1 and 3. This angle potential is
intended for coarse grained MD simulations with the CMM parameterization
using the :doc:`pair_style lj/sdk <pair_sdk>`. Relative to the
pair\_style *lj/sdk*\ , however, the energy is shifted by
pair_style *lj/sdk*\ , however, the energy is shifted by
:math:`\epsilon`, to avoid sudden jumps. Note that the usual 1/2 factor
is included in :math:`K`.
@ -50,7 +50,7 @@ The following coefficients must be defined for each angle type via the
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of :math:`K` are in energy/radian\^2.
The also required *lj/sdk* parameters will be extracted automatically
from the pair\_style.
from the pair_style.
----------

6
doc/src/angle_style.rst
View File

@ -41,7 +41,7 @@ files which means angle_style and :doc:`angle_coeff <angle_coeff>`
commands do not need to be re-specified in an input script that
restarts a simulation. See the :doc:`read_restart <read_restart>`
command for details on how to do this. The one exception is that
angle\_style *hybrid* only stores the list of sub-styles in the restart
angle_style *hybrid* only stores the list of sub-styles in the restart
file; angle coefficients need to be re-specified.
.. note::
@ -61,7 +61,7 @@ the style to display the formula it computes and coefficients
specified by the associated :doc:`angle_coeff <angle_coeff>` command.
Click on the style to display the formula it computes, any additional
arguments specified in the angle\_style command, and coefficients
arguments specified in the angle_style command, and coefficients
specified by the associated :doc:`angle_coeff <angle_coeff>` command.
There are also additional accelerated pair styles included in the
@ -98,7 +98,7 @@ of (g,i,k,o,t) to indicate which accelerated styles exist.
Restrictions
""""""""""""
Angle styles can only be set for atom\_styles that allow angles to be
Angle styles can only be set for atom_styles that allow angles to be
defined.
Most angle styles are part of the MOLECULE package. They are only

8
doc/src/angle_table.rst
View File

@ -87,7 +87,7 @@ keyword followed by one or more numeric values.
The parameter "N" is required and its value is the number of table
entries that follow. Note that this may be different than the *N*
specified in the :doc:`angle_style table <angle_style>` command. Let
Ntable = *N* in the angle\_style command, and Nfile = "N" in the
Ntable = *N* in the angle_style command, and Nfile = "N" in the
tabulated file. What LAMMPS does is a preliminary interpolation by
creating splines using the Nfile tabulated values as nodal points. It
uses these to interpolate as needed to generate energy and derivative
@ -148,12 +148,12 @@ instructions on how to use the accelerated styles effectively.
**Restart info:**
This angle style writes the settings for the "angle\_style table"
command to :doc:`binary restart files <restart>`, so a angle\_style
This angle style writes the settings for the "angle_style table"
command to :doc:`binary restart files <restart>`, so a angle_style
command does not need to specified in an input script that reads a
restart file. However, the coefficient information is not stored in
the restart file, since it is tabulated in the potential files. Thus,
angle\_coeff commands do need to be specified in the restart input
angle_coeff commands do need to be specified in the restart input
script.
Restrictions

6
doc/src/atom_modify.rst
View File

@ -60,8 +60,8 @@ The only reason not to use atom IDs is if you are running an atomic
simulation so large that IDs cannot be uniquely assigned. For a
default LAMMPS build this limit is 2\^31 or about 2 billion atoms.
However, even in this case, you can use 64-bit atom IDs, allowing 2\^63
or about 9e18 atoms, if you build LAMMPS with the - DLAMMPS\_BIGBIG
switch. This is described on the :doc:`Build\_settings <Build_settings>`
or about 9e18 atoms, if you build LAMMPS with the - DLAMMPS_BIGBIG
switch. This is described on the :doc:`Build_settings <Build_settings>`
doc page. If atom IDs are not used, they must be specified as 0 for
all atoms, e.g. in a data or restart file.
@ -108,7 +108,7 @@ this command. Note that specifying "all" as the group-ID effectively
turns off the *first* option.
It is OK to use the *first* keyword with a group that has not yet been
defined, e.g. to use the atom\_modify first command at the beginning of
defined, e.g. to use the atom_modify first command at the beginning of
your input script. LAMMPS does not use the group until a simulation
is run.

22
doc/src/atom_style.rst
View File

@ -119,7 +119,7 @@ quantities.
+--------------+-----------------------------------------------------+--------------------------------------+
| *tri* | corner points, angular momentum | rigid bodies |
+--------------+-----------------------------------------------------+--------------------------------------+
| *wavepacket* | charge, spin, eradius, etag, cs\_re, cs\_im | AWPMD |
| *wavepacket* | charge, spin, eradius, etag, cs_re, cs_im | AWPMD |
+--------------+-----------------------------------------------------+--------------------------------------+
.. note::
@ -158,7 +158,7 @@ For the *dipole* style, a point dipole is defined for each point
particle. Note that if you wish the particles to be finite-size
spheres as in a Stockmayer potential for a dipolar fluid, so that the
particles can rotate due to dipole-dipole interactions, then you need
to use atom\_style hybrid sphere dipole, which will assign both a
to use atom_style hybrid sphere dipole, which will assign both a
diameter and dipole moment to each particle.
For the *electron* style, the particles representing electrons are 3d
@ -171,14 +171,14 @@ per-particle mass and volume.
The *dpd* style is for dissipative particle dynamics (DPD) particles.
Note that it is part of the USER-DPD package, and is not for use with
the :doc:`pair_style dpd or dpd/stat <pair_dpd>` commands, which can
simply use atom\_style atomic. Atom\_style dpd extends DPD particle
simply use atom_style atomic. Atom_style dpd extends DPD particle
properties with internal temperature (dpdTheta), internal conductive
energy (uCond), internal mechanical energy (uMech), and internal
chemical energy (uChem).
The *edpd* style is for energy-conserving dissipative particle
dynamics (eDPD) particles which store a temperature (edpd\_temp), and
heat capacity(edpd\_cv).
dynamics (eDPD) particles which store a temperature (edpd_temp), and
heat capacity(edpd_cv).
The *mdpd* style is for many-body dissipative particle dynamics (mDPD)
particles which store a density (rho) for considering
@ -186,7 +186,7 @@ density-dependent many-body interactions.
The *tdpd* style is for transport dissipative particle dynamics (tDPD)
particles which store a set of chemical concentration. An integer
"cc\_species" is required to specify the number of chemical species
"cc_species" is required to specify the number of chemical species
involved in a tDPD system.
The *meso* style is for smoothed particle hydrodynamics (SPH)
@ -205,7 +205,7 @@ Those spins have a norm (their magnetic moment) and a direction.
The *wavepacket* style is similar to *electron*\ , but the electrons may
consist of several Gaussian wave packets, summed up with coefficients
cs= (cs\_re,cs\_im). Each of the wave packets is treated as a separate
cs= (cs_re,cs_im). Each of the wave packets is treated as a separate
particle in LAMMPS, wave packets belonging to the same electron must
have identical *etag* values.
@ -232,7 +232,7 @@ can be advantageous for large-scale coarse-grained systems.
.. note::
When using the *template* style with a :doc:`molecule template <molecule>` that contains multiple molecules, you should
insure the atom types, bond types, angle\_types, etc in all the
insure the atom types, bond types, angle_types, etc in all the
molecules are consistent. E.g. if one molecule represents H2O and
another CO2, then you probably do not want each molecule file to
define 2 atom types and a single bond type, because they will conflict
@ -256,7 +256,7 @@ orientation and position can be time integrated due to forces and
torques.
Note that there may be additional arguments required along with the
*bstyle* specification, in the atom\_style body command. These
*bstyle* specification, in the atom_style body command. These
arguments are described on the :doc:`Howto body <Howto_body>` doc page.
----------
@ -271,7 +271,7 @@ If some atoms have bonds, but others do not, use the *bond* style.
The only scenario where the *hybrid* style is needed is if there is no
single style which defines all needed properties of all atoms. For
example, as mentioned above, if you want dipolar particles which will
rotate due to torque, you need to use "atom\_style hybrid sphere
rotate due to torque, you need to use "atom_style hybrid sphere
dipole". When a hybrid style is used, atoms store and communicate the
union of all quantities implied by the individual styles.
@ -351,7 +351,7 @@ Related commands
Default
"""""""
atom\_style atomic
atom_style atomic
----------

8
doc/src/balance.rst
View File

@ -197,7 +197,7 @@ The "grid" methods can be used with either of the
:doc:`comm_style <comm_style>` command options, *brick* or *tiled*\ . The
"tiling" methods can only be used with :doc:`comm_style tiled <comm_style>`. Note that it can be useful to use a "grid"
method with :doc:`comm_style tiled <comm_style>` to return the domain
partitioning to a logical 3d grid of processors so that "comm\_style
partitioning to a logical 3d grid of processors so that "comm_style
brick" can afterwords be specified for subsequent :doc:`run <run>`
commands.
@ -228,7 +228,7 @@ that specify the position of the cutting planes. This requires
knowing Ps = Px or Py or Pz = the number of processors assigned by
LAMMPS to the relevant dimension. This assignment is made (and the
Px, Py, Pz values printed out) when the simulation box is created by
the "create\_box" or "read\_data" or "read\_restart" command and is
the "create_box" or "read_data" or "read_restart" command and is
influenced by the settings of the :doc:`processors <processors>`
command.
@ -333,7 +333,7 @@ particles in that sub-box.
----------
.. _weighted\_balance:
.. _weighted_balance:
This sub-section describes how to perform weighted load balancing
using the *weight* keyword.
@ -462,7 +462,7 @@ velocity, the volume of its Voronoi cell, etc.
The *store* weight style does not compute a weight factor. Instead it
stores the current accumulated weights in a custom per-atom property
specified by *name*\ . This must be a property defined as *d\_name* via
specified by *name*\ . This must be a property defined as *d_name* via
the :doc:`fix property/atom <fix_property_atom>` command. Note that
these custom per-atom properties can be output in a :doc:`dump <dump>`
file, so this is a way to examine, debug, or visualize the

6
doc/src/bond_coeff.rst
View File

@ -40,7 +40,7 @@ leading asterisk means all types from 1 to n (inclusive). A trailing
asterisk means all types from n to N (inclusive). A middle asterisk
means all types from m to n (inclusive).
Note that using a bond\_coeff command can override a previous setting
Note that using a bond_coeff command can override a previous setting
for the same bond type. For example, these commands set the coeffs
for all bond types, then overwrite the coeffs for just bond type 2:
@ -50,7 +50,7 @@ for all bond types, then overwrite the coeffs for just bond type 2:
bond_coeff 2 200.0 1.2
A line in a data file that specifies bond coefficients uses the exact
same format as the arguments of the bond\_coeff command in an input
same format as the arguments of the bond_coeff command in an input
script, except that wild-card asterisks should not be used since
coefficients for all N types must be listed in the file. For example,
under the "Bond Coeffs" section of a data file, the line that
@ -68,7 +68,7 @@ compact form on the :doc:`Commands bond <Commands_bond>` doc page.
On either of those pages, click on the style to display the formula it
computes and its coefficients as specified by the associated
bond\_coeff command.
bond_coeff command.
----------

8
doc/src/bond_hybrid.rst
View File

@ -32,9 +32,9 @@ be computed with a *harmonic* potential. The assignment of bond type
to style is made via the :doc:`bond_coeff <bond_coeff>` command or in
the data file.
In the bond\_coeff commands, the name of a bond style must be added
In the bond_coeff commands, the name of a bond style must be added
after the bond type, with the remaining coefficients being those
appropriate to that style. In the example above, the 2 bond\_coeff
appropriate to that style. In the example above, the 2 bond_coeff
commands set bonds of bond type 1 to be computed with a *harmonic*
potential with coefficients 80.0, 1.2 for :math:`K`, :math:`r_0`. All other bond types
(2-N) are computed with a *fene* potential with coefficients 30.0,
@ -54,7 +54,7 @@ line in the "Bond Coeffs" section, e.g.
...
A bond style of *none* with no additional coefficients can be used in
place of a bond style, either in a input script bond\_coeff command or
place of a bond style, either in a input script bond_coeff command or
in the data file, if you desire to turn off interactions for specific
bond types.
@ -69,7 +69,7 @@ info.
Unlike other bond styles, the hybrid bond style does not store bond
coefficient info for individual sub-styles in a :doc:`binary restart files <restart>`. Thus when restarting a simulation from a restart
file, you need to re-specify bond\_coeff commands.
file, you need to re-specify bond_coeff commands.
Related commands
""""""""""""""""

2
doc/src/bond_mm3.rst
View File

@ -47,7 +47,7 @@ Restrictions
""""""""""""
This bond style can only be used if LAMMPS was built with the
USER\_YAFF package. See the :doc:`Build package <Build_package>` doc
USER_YAFF package. See the :doc:`Build package <Build_package>` doc
page for more info.
Related commands

6
doc/src/bond_style.rst
View File

@ -47,10 +47,10 @@ The coefficients associated with a bond style can be specified in a
data or restart file or via the :doc:`bond_coeff <bond_coeff>` command.
All bond potentials store their coefficient data in binary restart
files which means bond\_style and :doc:`bond_coeff <bond_coeff>` commands
files which means bond_style and :doc:`bond_coeff <bond_coeff>` commands
do not need to be re-specified in an input script that restarts a
simulation. See the :doc:`read_restart <read_restart>` command for
details on how to do this. The one exception is that bond\_style
details on how to do this. The one exception is that bond_style
*hybrid* only stores the list of sub-styles in the restart file; bond
coefficients need to be re-specified.
@ -71,7 +71,7 @@ the style to display the formula it computes and coefficients
specified by the associated :doc:`bond_coeff <bond_coeff>` command.
Click on the style to display the formula it computes, any additional
arguments specified in the bond\_style command, and coefficients
arguments specified in the bond_style command, and coefficients
specified by the associated :doc:`bond_coeff <bond_coeff>` command.
There are also additional accelerated pair styles included in the

6
doc/src/bond_table.rst
View File

@ -146,12 +146,12 @@ instructions on how to use the accelerated styles effectively.
**Restart info:**
This bond style writes the settings for the "bond\_style table"
command to :doc:`binary restart files <restart>`, so a bond\_style
This bond style writes the settings for the "bond_style table"
command to :doc:`binary restart files <restart>`, so a bond_style
command does not need to specified in an input script that reads a
restart file. However, the coefficient information is not stored in
the restart file, since it is tabulated in the potential files. Thus,
bond\_coeff commands do need to be specified in the restart input
bond_coeff commands do need to be specified in the restart input
script.
Restrictions

2
doc/src/bond_zero.rst
View File

@ -33,7 +33,7 @@ atoms listed in the data file read by the :doc:`read_data <read_data>`
command. If no bond style is defined, this command cannot be used.
The optional *nocoeff* flag allows to read data files with a BondCoeff
section for any bond style. Similarly, any bond\_coeff commands
section for any bond style. Similarly, any bond_coeff commands
will only be checked for the bond type number and the rest ignored.
Note that the :doc:`bond_coeff <bond_coeff>` command must be used for

12
doc/src/change_box.rst
View File

@ -102,10 +102,10 @@ new owning processors.
.. note::
This means that you cannot use the change\_box command to enlarge
This means that you cannot use the change_box command to enlarge
a shrink-wrapped box, e.g. to make room to insert more atoms via the
:doc:`create_atoms <create_atoms>` command, because the simulation box
will be re-shrink-wrapped before the change\_box command completes.
will be re-shrink-wrapped before the change_box command completes.
Instead you could do something like this, assuming the simulation box
is non-periodic and atoms extend from 0 to 20 in all dimensions:
@ -120,7 +120,7 @@ new owning processors.
.. note::
Unlike the earlier "displace\_box" version of this command, atom
Unlike the earlier "displace_box" version of this command, atom
remapping is NOT performed by default. This command allows remapping
to be done in a more general way, exactly when you specify it (zero or
more times) in the sequence of transformations. Thus if you do not
@ -280,7 +280,7 @@ command. This command allows the boundary conditions to be changed
later in your input script. Also note that the
:doc:`read_restart <read_restart>` will change boundary conditions to
match what is stored in the restart file. So if you wish to change
them, you should use the change\_box command after the read\_restart
them, you should use the change_box command after the read_restart
command.
----------
@ -308,7 +308,7 @@ useful if you wish to use the *remap* keyword more than once or if you
wish it to be applied to an intermediate box size/shape in a sequence
of keyword operations. Note that the box size/shape is saved before
any of the keywords are processed, i.e. the box size/shape at the time
the create\_box command is encountered in the input script.
the create_box command is encountered in the input script.
The *remap* keyword remaps atom coordinates from the last saved box
size/shape to the current box state. For example, if you stretch the
@ -343,7 +343,7 @@ the input script when this command is issued, no :doc:`dumps <dump>` can
be active, nor can a :doc:`fix deform <fix_deform>` be active. This is
because these commands test whether the simulation box is orthogonal
when they are first issued. Note that these commands can be used in
your script before a change\_box command is issued, so long as an
your script before a change_box command is issued, so long as an
:doc:`undump <undump>` or :doc:`unfix <unfix>` command is also used to
turn them off.

8
doc/src/comm_modify.rst
View File

@ -49,9 +49,9 @@ processors and stored as properties of ghost atoms.
you specify a :doc:`comm_style <comm_style>` or
:doc:`read_restart <read_restart>` command, all communication settings
are restored to their default or stored values, including those
previously reset by a comm\_modify command. Thus if your input script
specifies a comm\_style or read\_restart command, you should use the
comm\_modify command after it.
previously reset by a comm_modify command. Thus if your input script
specifies a comm_style or read_restart command, you should use the
comm_modify command after it.
The *mode* keyword determines whether a single or multiple cutoff
distances are used to determine which atoms to communicate.
@ -82,7 +82,7 @@ printed. Specifying a cutoff value of 0.0 will reset any previous value
to the default. If bonded interactions exist and equilibrium bond length
information is available, then also a heuristic based on that bond length
is computed. It is used as communication cutoff, if there is no pair
style present and no *comm\_modify cutoff* command used. Otherwise a
style present and no *comm_modify cutoff* command used. Otherwise a
warning is printed, if this bond based estimate is larger than the
communication cutoff used. A

14
doc/src/compute.rst
View File

@ -72,11 +72,11 @@ discussed below, it can be referenced via the following bracket
notation, where ID is the ID of the compute:
+-------------+--------------------------------------------+
| c\_ID | entire scalar, vector, or array |
| c_ID | entire scalar, vector, or array |
+-------------+--------------------------------------------+
| c\_ID[I] | one element of vector, one column of array |
| c_ID[I] | one element of vector, one column of array |
+-------------+--------------------------------------------+
| c\_ID[I][J] | one element of array |
| c_ID[I][J] | one element of array |
+-------------+--------------------------------------------+
In other words, using one bracket reduces the dimension of the
@ -88,7 +88,7 @@ vector or array.
Note that commands and :doc:`variables <variable>` which use compute
quantities typically do not allow for all kinds, e.g. a command may
require a vector of values, not a scalar. This means there is no
ambiguity about referring to a compute quantity as c\_ID even if it
ambiguity about referring to a compute quantity as c_ID even if it
produces, for example, both a scalar and vector. The doc pages for
various commands explain the details.
@ -116,7 +116,7 @@ e.g. temperature. Extensive means the value scales with the number of
atoms in the simulation, e.g. total rotational kinetic energy.
:doc:`Thermodynamic output <thermo_style>` will normalize extensive
values by the number of atoms in the system, depending on the
"thermo\_modify norm" setting. It will not normalize intensive values.
"thermo_modify norm" setting. It will not normalize intensive values.
If a compute value is accessed in another way, e.g. by a
:doc:`variable <variable>`, you may want to know whether it is an
intensive or extensive value. See the doc page for individual
@ -125,8 +125,8 @@ computes for further info.
----------
LAMMPS creates its own computes internally for thermodynamic output.
Three computes are always created, named "thermo\_temp",
"thermo\_press", and "thermo\_pe", as if these commands had been invoked
Three computes are always created, named "thermo_temp",
"thermo_press", and "thermo_pe", as if these commands had been invoked
in the input script:
.. code-block:: LAMMPS

4
doc/src/compute_adf.rst
View File

@ -64,7 +64,7 @@ neighbor atom in each requested ADF.
those pairs will not be included in the ADF. This does not apply when
using long-range coulomb interactions (\ *coul/long*\ , *coul/msm*\ ,
*coul/wolf* or similar. One way to get around this would be to set
special\_bond scaling factors to very tiny numbers that are not exactly
special_bond scaling factors to very tiny numbers that are not exactly
zero (e.g. 1.0e-50). Another workaround is to write a dump file, and
use the :doc:`rerun <rerun>` command to compute the ADF for snapshots in
the dump file. The rerun script can use a
@ -106,7 +106,7 @@ in the range of types represented by *ktypeN*\ .
If no *itypeN*\ , *jtypeN*\ , *ktypeN* settings are specified, then
LAMMPS will generate a single ADF for all atoms in the group.
The inner cutoff is set to zero and the outer cutoff is set
to the force cutoff. If no pair\_style is specified, there is no
to the force cutoff. If no pair_style is specified, there is no
force cutoff and LAMMPS will give an error message. Note that
in most cases, generating an ADF for all atoms is not a good thing.
Such an ADF is both uninformative and

6
doc/src/compute_angle.rst
View File

@ -24,8 +24,8 @@ Description
"""""""""""
Define a computation that extracts the angle energy calculated by each
of the angle sub-styles used in the "angle\_style
hybrid" angle\_hybrid.html command. These values are made accessible
of the angle sub-styles used in the "angle_style
hybrid" angle_hybrid.html command. These values are made accessible
for output or further processing by other commands. The group
specified for this command is ignored.
@ -35,7 +35,7 @@ energy contributed by one or more of the hybrid sub-styles.
**Output info:**
This compute calculates a global vector of length N where N is the
number of sub\_styles defined by the :doc:`angle_style hybrid <angle_style>` command, which can be accessed by indices
number of sub_styles defined by the :doc:`angle_style hybrid <angle_style>` command, which can be accessed by indices
1-N. These values can be used by any command that uses global scalar
or vector values from a compute as input. See the :doc:`Howto output <Howto_output>` doc page for an overview of LAMMPS output
options.

6
doc/src/compute_angle_local.rst
View File

@ -13,7 +13,7 @@ Syntax
* ID, group-ID are documented in :doc:`compute <compute>` command
* angle/local = style name of this compute command
* one or more values may be appended
* value = *theta* or *eng* or *v\_name*
* value = *theta* or *eng* or *v_name*
.. parsed-literal::
@ -51,9 +51,9 @@ The value *theta* is the angle for the 3 atoms in the interaction.
The value *eng* is the interaction energy for the angle.
The value *v\_name* can be used together with the *set* keyword to
The value *v_name* can be used together with the *set* keyword to
compute a user-specified function of the angle theta. The *name*
specified for the *v\_name* value is the name of an :doc:`equal-style variable <variable>` which should evaluate a formula based on a
specified for the *v_name* value is the name of an :doc:`equal-style variable <variable>` which should evaluate a formula based on a
variable which will store the angle theta. This other variable must
be an :doc:`internal-style variable <variable>` defined in the input
script; its initial numeric value can be anything. It must be an

2
doc/src/compute_body_local.rst
View File

@ -61,7 +61,7 @@ group.
For a body particle, the *integer* keywords refer to fields calculated
by the body style for each sub-particle. The body style, as specified
by the :doc:`atom_style body <atom_style>`, determines how many fields
exist and what they are. See the :doc:`Howto\_body <Howto_body>` doc
exist and what they are. See the :doc:`Howto_body <Howto_body>` doc
page for details of the different styles.
Here is an example of how to output body information using the :doc:`dump local <dump>` command with this compute. If fields 1,2,3 for the

2
doc/src/compute_bond.rst
View File

@ -35,7 +35,7 @@ or more of the hybrid sub-styles.
**Output info:**
This compute calculates a global vector of length N where N is the
number of sub\_styles defined by the :doc:`bond_style hybrid <bond_style>` command, which can be accessed by indices 1-N.
number of sub_styles defined by the :doc:`bond_style hybrid <bond_style>` command, which can be accessed by indices 1-N.
These values can be used by any command that uses global scalar or
vector values from a compute as input. See the :doc:`Howto output <Howto_output>` doc page for an overview of LAMMPS output
options.

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