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

Merge branch 'develop' into gran-temp

Browse Source
This commit is contained in:
jtclemm
2022-11-01 14:10:28 -06:00
committed by GitHub
parent 88be5a3781 a001707b22
commit f671cd7765
5545 changed files with 583048 additions and 69653 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
doc/src/Bibliography.rst
View File

@ -314,7 +314,7 @@ Bibliography
Espanol, Revenga, Physical Review E, 67, 026705 (2003).
**(Espanol1997)**
Espanol, Europhys Lett, 40(6): 631-636 (1997). DOI: 10.1209/epl/i1997-00515-8
Espanol, Europhys Lett, 40(6): 631-636 (1997). DOI:10.1209/epl/i1997-00515-8
**(Evans and Morriss)**
Evans and Morriss, Phys Rev A, 30, 1528 (1984).
@ -368,7 +368,7 @@ Bibliography
Frenkel and Smit, Understanding Molecular Simulation, Academic Press, London, 2002.
**(GLE4MD)**
`http://gle4md.org/ <http://gle4md.org/>`_
`https://gle4md.org/ <https://gle4md.org/>`_
**(Gao)**
Gao and Weber, Nuclear Instruments and Methods in Physics Research B 191 (2012) 504.
@ -401,13 +401,13 @@ Bibliography
Hayre, and Farago, Comp Phys Comm, 185, 524 (2014)
**(Groot)**
Groot and Warren, J Chem Phys, 107: 4423-4435 (1997). DOI: 10.1063/1.474784
Groot and Warren, J Chem Phys, 107: 4423-4435 (1997). DOI:10.1063/1.474784
**(Guenole)**
Guenole, Noehring, Vaid, Houlle, Xie, Prakash, Bitzek, Comput Mater Sci, 175, 109584 (2020).
**(Gullet)**
Gullet, Wagner, Slepoy, SANDIA Report 2003-8782 (2003).
Gullet, Wagner, Slepoy, SANDIA Report 2003-8782 (2003). DOI:10.2172/918395
**(Guo)**
Guo and Thirumalai, Journal of Molecular Biology, 263, 323-43 (1996).
@ -461,7 +461,7 @@ Bibliography
Hunt, Mol Simul, 42, 347 (2016).
**(IPI)**
`http://epfl-cosmo.github.io/gle4md/index.html?page=ipi <http://epfl-cosmo.github.io/gle4md/index.html?page=ipi>`_
`https://ipi-code.org/ <https://ipi-code.org/>`
**(IPI-CPC)**
Ceriotti, More and Manolopoulos, Comp Phys Comm, 185, 1019-1026 (2014).
@ -605,16 +605,16 @@ Bibliography
I.\ Leven et al, J. Chem.Theory Comput. 12, 2896-905 (2016).
**(Li2013_POF)**
Li, Hu, Wang, Ma, Zhou, Phys Fluids, 25: 072103 (2013). DOI: 10.1063/1.4812366.
Li, Hu, Wang, Ma, Zhou, Phys Fluids, 25: 072103 (2013). DOI:10.1063/1.4812366.
**(Li2014_JCP)**
Li, Tang, Lei, Caswell, Karniadakis, J Comput Phys, 265: 113-127 (2014). DOI: 10.1016/j.jcp.2014.02.003.
Li, Tang, Lei, Caswell, Karniadakis, J Comput Phys, 265: 113-127 (2014). DOI:10.1016/j.jcp.2014.02.003.
**(Li2015_CC)**
Li, Tang, Li, Karniadakis, Chem Commun, 51: 11038-11040 (2015). DOI: 10.1039/C5CC01684C.
Li, Tang, Li, Karniadakis, Chem Commun, 51: 11038-11040 (2015). DOI:10.1039/C5CC01684C.
**(Li2015_JCP)**
Li, Yazdani, Tartakovsky, Karniadakis, J Chem Phys, 143: 014101 (2015). DOI: 10.1063/1.4923254.
Li, Yazdani, Tartakovsky, Karniadakis, J Chem Phys, 143: 014101 (2015). DOI:10.1063/1.4923254.
**(Lisal)**
M.\ Lisal, J.K. Brennan, J. Bonet Avalos, "Dissipative particle dynamics at isothermal, isobaric, isoenergetic, and isoenthalpic conditions using Shardlow-like splitting algorithms.",
@ -733,8 +733,8 @@ Bibliography
**(Mishin)**
Mishin, Mehl, and Papaconstantopoulos, Acta Mater, 53, 4029 (2005).
**(Mitchell and Finchham)**
Mitchell, Finchham, J Phys Condensed Matter, 5, 1031-1038 (1993).
**(Mitchell and Fincham)**
Mitchell, Fincham, J Phys Condensed Matter, 5, 1031-1038 (1993).
**(Mitchell2011)**
Mitchell. A non-local, ordinary-state-based viscoelasticity model for peridynamics. Sandia National Lab Report, 8064:1-28 (2011).
@ -875,7 +875,7 @@ Bibliography
G.A. Tribello, M. Bonomi, D. Branduardi, C. Camilloni and G. Bussi, Comp. Phys. Comm 185, 604 (2014)
**(Paquay)**
Paquay and Kusters, Biophys. J., 110, 6, (2016). preprint available at `arXiv:1411.3019 <http://arxiv.org/abs/1411.3019/>`_.
Paquay and Kusters, Biophys. J., 110, 6, (2016). preprint available at `arXiv:1411.3019 <https://arxiv.org/abs/1411.3019/>`_.
**(Park)**
Park, Schulten, J. Chem. Phys. 120 (13), 5946 (2004)
@ -1373,7 +1373,7 @@ Bibliography
Zhu, Tajkhorshid, and Schulten, Biophys. J. 83, 154 (2002).
**(Ziegler)**
J.F. Ziegler, J. P. Biersack and U. Littmark, "The Stopping and Range of Ions in Matter," Volume 1, Pergamon, 1985.
J.F. Ziegler, J. P. Biersack and U. Littmark, "The Stopping and Range of Ions in Matter", Volume 1, Pergamon, 1985.
**(Zimmerman2004)**
Zimmerman, JA; Webb, EB; Hoyt, JJ;. Jones, RE; Klein, PA; Bammann, DJ, "Calculation of stress in atomistic simulation." Special Issue of Modelling and Simulation in Materials Science and Engineering (2004),12:S319.

12
doc/src/Build_development.rst
View File

@ -140,13 +140,23 @@ of the LAMMPS project on GitHub.
The unit testing facility is integrated into the CMake build process
of the LAMMPS source code distribution itself. It can be enabled by
setting ``-D ENABLE_TESTING=on`` during the CMake configuration step.
It requires the `YAML <http://pyyaml.org/>`_ library and development
It requires the `YAML <https://pyyaml.org/>`_ library and development
headers (if those are not found locally a recent version will be
downloaded and compiled along with LAMMPS and the test program) to
compile and will download and compile a specific recent version of the
`Googletest <https://github.com/google/googletest/>`_ C++ test framework
for implementing the tests.
.. admonition:: Software version requirements for testing
:class: note
The compiler and library version requirements for the testing
framework are more strict than for the main part of LAMMPS. For
example the default GNU C++ and Fortran compilers of RHEL/CentOS 7.x
(version 4.8.x) are not sufficient. The CMake configuration will try
to detect compatible versions and either skip incompatible tests or
stop with an error.
After compilation is complete, the unit testing is started in the build
folder using the ``ctest`` command, which is part of the CMake software.
The output of this command will be looking something like this::

151
doc/src/Build_extras.rst
View File

@ -123,6 +123,7 @@ CMake build
-D GPU_API=value # value = opencl (default) or cuda or hip
-D GPU_PREC=value # precision setting
# value = double or mixed (default) or single
-D HIP_PATH # path to HIP installation. Must be set if GPU_API=HIP
-D GPU_ARCH=value # primary GPU hardware choice for GPU_API=cuda
# value = sm_XX, see below
# default is sm_50
@ -179,10 +180,17 @@ set appropriate environment variables. Some variables such as
:code:`HCC_AMDGPU_TARGET` (for ROCm <= 4.0) or :code:`CUDA_PATH` are necessary for :code:`hipcc`
and the linker to work correctly.
Using CHIP-SPV implementation of HIP is now supported. It allows one to run HIP
code on Intel GPUs via the OpenCL or Level Zero backends. To use CHIP-SPV, you must
set :code:`-DHIP_USE_DEVICE_SORT=OFF` in your CMake command line as CHIP-SPV does not
yet support hipCUB. The use of HIP for Intel GPUs is still experimental so you
should only use this option in preparations to run on Aurora system at ANL.
.. code:: bash
# AMDGPU target (ROCm <= 4.0)
export HIP_PLATFORM=hcc
export HIP_PATH=/path/to/HIP/install
export HCC_AMDGPU_TARGET=gfx906
cmake -D PKG_GPU=on -D GPU_API=HIP -D HIP_ARCH=gfx906 -D CMAKE_CXX_COMPILER=hipcc ..
make -j 4
@ -191,6 +199,7 @@ and the linker to work correctly.
# AMDGPU target (ROCm >= 4.1)
export HIP_PLATFORM=amd
export HIP_PATH=/path/to/HIP/install
cmake -D PKG_GPU=on -D GPU_API=HIP -D HIP_ARCH=gfx906 -D CMAKE_CXX_COMPILER=hipcc ..
make -j 4
@ -199,10 +208,20 @@ and the linker to work correctly.
# CUDA target (not recommended, use GPU_ARCH=cuda)
# !!! DO NOT set CMAKE_CXX_COMPILER !!!
export HIP_PLATFORM=nvcc
export HIP_PATH=/path/to/HIP/install
export CUDA_PATH=/usr/local/cuda
cmake -D PKG_GPU=on -D GPU_API=HIP -D HIP_ARCH=sm_70 ..
make -j 4
.. code:: bash
# SPIR-V target (Intel GPUs)
export HIP_PLATFORM=spirv
export HIP_PATH=/path/to/HIP/install
export CMAKE_CXX_COMPILER=<hipcc/clang++>
cmake -D PKG_GPU=on -D GPU_API=HIP ..
make -j 4
Traditional make
^^^^^^^^^^^^^^^^
@ -215,7 +234,7 @@ LAMMPS code. This also applies to the ``-DLAMMPS_BIGBIG``\ ,
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``
using a command like these, which simply invokes the ``lib/gpu/Install.py``
script with the specified args:
.. code-block:: bash
@ -295,7 +314,7 @@ detailed information is available at:
In addition to installing the KIM API, it is also necessary to install the
library of KIM models (interatomic potentials).
See `Obtaining KIM Models <http://openkim.org/doc/usage/obtaining-models>`_ to
See `Obtaining KIM Models <https://openkim.org/doc/usage/obtaining-models>`_ to
learn how to install a pre-build binary of the OpenKIM Repository of Models.
See the list of all KIM models here: https://openkim.org/browse/models
@ -331,7 +350,7 @@ minutes to hours) to build. Of course you only need to do that once.)
You can download and build the KIM library manually if you prefer;
follow the instructions in ``lib/kim/README``. You can also do
this in one step from the lammps/src directory, using a command like
these, which simply invoke the ``lib/kim/Install.py`` script with
these, which simply invokes the ``lib/kim/Install.py`` script with
the specified args.
.. code-block:: bash
@ -413,7 +432,7 @@ Enabling the extra unit tests have some requirements,
``EAM_Dynamo_MendelevAckland_2007v3_Zr__MO_004835508849_000``,
``EAM_Dynamo_ErcolessiAdams_1994_Al__MO_123629422045_005``, and
``LennardJones612_UniversalShifted__MO_959249795837_003`` KIM models.
See `Obtaining KIM Models <http://openkim.org/doc/usage/obtaining-models>`_
See `Obtaining KIM Models <https://openkim.org/doc/usage/obtaining-models>`_
to learn how to install a pre-built binary of the OpenKIM Repository of
Models or see
`Installing KIM Models <https://openkim.org/doc/usage/obtaining-models/#installing_models>`_
@ -464,6 +483,9 @@ They must be specified in uppercase.
* - **Arch-ID**
- **HOST or GPU**
- **Description**
* - NATIVE
- HOST
- Local machine
* - AMDAVX
- HOST
- AMD 64-bit x86 CPU (AVX 1)
@ -503,9 +525,21 @@ They must be specified in uppercase.
* - BDW
- HOST
- Intel Broadwell Xeon E-class CPU (AVX 2 + transactional mem)
* - SKL
- HOST
- Intel Skylake Client CPU
* - SKX
- HOST
- Intel Sky Lake Xeon E-class HPC CPU (AVX512 + transactional mem)
- Intel Skylake Xeon Server CPU (AVX512)
* - ICL
- HOST
- Intel Ice Lake Client CPU (AVX512)
* - ICX
- HOST
- Intel Ice Lake Xeon Server CPU (AVX512)
* - SPR
- HOST
- Intel Sapphire Rapids Xeon Server CPU (AVX512)
* - KNC
- HOST
- Intel Knights Corner Xeon Phi
@ -577,7 +611,10 @@ They must be specified in uppercase.
- AMD GPU MI100 GFX908
* - VEGA90A
- GPU
- AMD GPU
- AMD GPU MI200 GFX90A
* - INTEL_GEN
- GPU
- SPIR64-based devices, e.g. Intel GPUs, using JIT
* - INTEL_DG1
- GPU
- Intel Iris XeMAX GPU
@ -592,9 +629,12 @@ They must be specified in uppercase.
- Intel GPU Gen12LP
* - INTEL_XEHP
- GPU
- Intel GPUs Xe-HP
- Intel GPU Xe-HP
* - INTEL_PVC
- GPU
- Intel GPU Ponte Vecchio
This list was last updated for version 3.5.0 of the Kokkos library.
This list was last updated for version 3.7.0 of the Kokkos library.
.. tabs::
@ -788,8 +828,10 @@ library.
.. code-block:: bash
-D DOWNLOAD_LATTE=value # download LATTE for build, value = no (default) or yes
-D LATTE_LIBRARY=path # LATTE library file (only needed if a custom location)
-D DOWNLOAD_LATTE=value # download LATTE for build, value = no (default) or yes
-D LATTE_LIBRARY=path # LATTE library file (only needed if a custom location)
-D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
# value = no (default) or yes
If ``DOWNLOAD_LATTE`` is set, the LATTE library will be downloaded
and built inside the CMake build directory. If the LATTE library
@ -797,6 +839,13 @@ library.
``LATTE_LIBRARY`` is the filename (plus path) of the LATTE library
file, not the directory the library file is in.
The LATTE library requires LAPACK (and BLAS) and CMake can identify
their locations and pass that info to the LATTE build script. But
on some systems this triggers a (current) limitation of CMake and
the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
those cases to use the bundled linear algebra library and work around
the limitation.
.. tab:: Traditional make
You can download and build the LATTE library manually if you
@ -905,7 +954,7 @@ more details.
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
command like these, which simply invokes the
``lib/mscg/Install.py`` script with the specified args:
.. code-block:: bash
@ -962,7 +1011,7 @@ POEMS package
``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`` dir, using a command like these,
which simply invoke the ``lib/poems/Install.py`` script with the
which simply invokes the ``lib/poems/Install.py`` script with the
specified args:
.. code-block:: bash
@ -1025,7 +1074,7 @@ VORONOI package
-----------------------------
To build with this package, you must download and build the
`Voro++ library <http://math.lbl.gov/voro++>`_ or install a
`Voro++ library <https://math.lbl.gov/voro++>`_ or install a
binary package provided by your operating system.
.. tabs::
@ -1051,7 +1100,7 @@ binary package provided by your operating system.
You can download and build the Voro++ library manually if you
prefer; follow the instructions in ``lib/voronoi/README``. You
can also do it in one step from the ``lammps/src`` dir, using a
command like these, which simply invoke the
command like these, which simply invokes the
``lib/voronoi/Install.py`` script with the specified args:
.. code-block:: bash
@ -1130,7 +1179,7 @@ The ATC package requires the MANYBODY package also be installed.
``lib/atc``. You can do this manually if you prefer; follow the
instructions in ``lib/atc/README``. You can also do it in one
step from the ``lammps/src`` dir, using a command like these,
which simply invoke the ``lib/atc/Install.py`` script with the
which simply invokes the ``lib/atc/Install.py`` script with the
specified args:
.. code-block:: bash
@ -1181,7 +1230,7 @@ AWPMD package
``lib/awpmd``. You can do this manually if you prefer; follow the
instructions in ``lib/awpmd/README``. You can also do it in one
step from the ``lammps/src`` dir, using a command like these,
which simply invoke the ``lib/awpmd/Install.py`` script with the
which simply invokes the ``lib/awpmd/Install.py`` script with the
specified args:
.. code-block:: bash
@ -1244,7 +1293,7 @@ be built for the most part with all major versions of the C++ language.
In general, it is safer to use build setting consistent with the
rest of LAMMPS. This is best carried out from the LAMMPS src
directory using a command like these, which simply invoke the
directory using a command like these, which simply invokes the
``lib/colvars/Install.py`` script with the specified args:
.. code-block:: bash
@ -1285,20 +1334,30 @@ This package depends on the KSPACE package.
.. tab:: CMake build
No additional settings are needed besides ``-D PKG_KSPACE=yes`` and ``-D
PKG_ELECTRODE=yes``.
No additional settings are needed besides ``-D PKG_KSPACE=yes`` and
``-D PKG_ELECTRODE=yes``.
.. tab:: Traditional make
The package is activated with ``make yes-KSPACE`` and ``make
yes-ELECTRODE``
Before building LAMMPS, you must configure the ELECTRODE support
libraries and settings in ``lib/electrode``. You can do this
manually, if you prefer, or do it in one step from the
``lammps/src`` dir, using a command like these, which simply
invokes the ``lib/electrode/Install.py`` script with the specified
args:
.. code-block:: bash
$ make lib-electrode # print help message
$ make lib-electrode args="-m serial" # build with GNU g++ compiler and MPI STUBS (settings as with "make serial")
$ make lib-electrode args="-m mpi" # build with default MPI compiler (settings as with "make mpi")
Note that the ``Makefile.lammps`` file has settings for the BLAS and
LAPACK linear algebra libraries. As explained in ``lib/awpmd/README``
these can either exist on your system, or you can use the files provided
in ``lib/linalg``. In the latter case you also need to build the library
in ``lib/linalg`` with a command like these:
Note that the ``Makefile.lammps`` file has settings for the BLAS
and LAPACK linear algebra libraries. These can either exist on
your system, or you can use the files provided in ``lib/linalg``.
In the latter case you also need to build the library in
``lib/linalg`` with a command like these:
.. code-block:: bash
@ -1307,6 +1366,9 @@ This package depends on the KSPACE package.
$ make lib-linalg args="-m mpi" # build with default MPI Fortran compiler (settings as with "make mpi")
$ make lib-linalg args="-m gfortran" # build with GNU Fortran compiler
The package itself is activated with ``make yes-KSPACE`` and
``make yes-ELECTRODE``
----------
.. _ml-pace:
@ -1506,7 +1568,7 @@ the HDF5 library.
``lib/h5md``. You can do this manually if you prefer; follow the
instructions in ``lib/h5md/README``. You can also do it in one
step from the ``lammps/src`` dir, using a command like these,
which simply invoke the ``lib/h5md/Install.py`` script with the
which simply invokes the ``lib/h5md/Install.py`` script with the
specified args:
.. code-block:: bash
@ -1562,7 +1624,7 @@ details please see ``lib/hdnnp/README`` and the `n2p2 build documentation
You can download and build the *n2p2* library manually if you prefer;
follow the instructions in ``lib/hdnnp/README``\ . You can also do it in
one step from the ``lammps/src`` dir, using a command like these, which
simply invoke the ``lib/hdnnp/Install.py`` script with the specified args:
simply invokes the ``lib/hdnnp/Install.py`` script with the specified args:
.. code-block:: bash
@ -1699,7 +1761,7 @@ they will be downloaded the first time this package is installed.
Before building LAMMPS, you must build the *mesont* library in
``lib/mesont``\ . You can also do it in one step from the
``lammps/src`` dir, using a command like these, which simply
invoke the ``lib/mesont/Install.py`` script with the specified
invokes the ``lib/mesont/Install.py`` script with the specified
args:
.. code-block:: bash
@ -1868,7 +1930,7 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to
``lib/qmmm``. You can do this manually if you prefer; follow the
first two steps explained in ``lib/qmmm/README``. You can also do
it in one step from the ``lammps/src`` dir, using a command like
these, which simply invoke the ``lib/qmmm/Install.py`` script with
these, which simply invokes the ``lib/qmmm/Install.py`` script with
the specified args:
.. code-block:: bash
@ -1913,14 +1975,25 @@ within CMake will download the non-commercial use version.
.. code-block:: bash
-D DOWNLOAD_QUIP=value # download OpenKIM API v2 for build, value = no (default) or yes
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
-D DOWNLOAD_QUIP=value # download QUIP library for build, value = no (default) or yes
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
-D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
# value = no (default) or yes
CMake will try to download and build the QUIP library from GitHub, if it is not
found on the local machine. This requires to have git installed. It will use the same compilers
and flags as used for compiling LAMMPS. Currently this is only supported for the GNU and the
Intel compilers. Set the ``QUIP_LIBRARY`` variable if you want to use a previously compiled
and installed QUIP library and CMake cannot find it.
CMake will try to download and build the QUIP library from GitHub,
if it is not found on the local machine. This requires to have git
installed. It will use the same compilers and flags as used for
compiling LAMMPS. Currently this is only supported for the GNU
and the Intel compilers. Set the ``QUIP_LIBRARY`` variable if you
want to use a previously compiled and installed QUIP library and
CMake cannot find it.
The QUIP library requires LAPACK (and BLAS) and CMake can identify
their locations and pass that info to the QUIP build script. But
on some systems this triggers a (current) limitation of CMake and
the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
those cases to use the bundled linear algebra library and work around
the limitation.
.. tab:: Traditional make
@ -1965,7 +2038,7 @@ To build with this package, you must download and build the
You can download and build the ScaFaCoS library manually if you
prefer; follow the instructions in ``lib/scafacos/README``. You
can also do it in one step from the ``lammps/src`` dir, using a
command like these, which simply invoke the
command like these, which simply invokes the
``lib/scafacos/Install.py`` script with the specified args:
.. code-block:: bash
@ -2009,7 +2082,7 @@ Eigen3 is a template library, so you do not need to build it.
You can download the Eigen3 library manually if you prefer; follow
the instructions in ``lib/smd/README``. You can also do it in one
step from the ``lammps/src`` dir, using a command like these,
which simply invoke the ``lib/smd/Install.py`` script with the
which simply invokes the ``lib/smd/Install.py`` script with the
specified args:
.. code-block:: bash

43
doc/src/Build_manual.rst
View File

@ -48,18 +48,15 @@ Build using GNU make
The LAMMPS manual is written in `reStructuredText <rst_>`_ format which
can be translated to different output format using the `Sphinx
<sphinx_>`_ document generator tool. It also incorporates programmer
documentation extracted from the LAMMPS C++ sources through the `Doxygen
<https://doxygen.nl>`_ program. Currently the translation to HTML, PDF
(via LaTeX), ePUB (for many e-book readers) and MOBI (for Amazon Kindle
readers) are supported. For that to work a Python 3 interpreter, the
``doxygen`` tools and internet access to download additional files and
tools are required. This download is usually only required once or
after the documentation folder is returned to a pristine state with
``make clean-all``.
.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
.. _sphinx: https://www.sphinx-doc.org
<https://sphinx-doc.org>`_ document generator tool. It also
incorporates programmer documentation extracted from the LAMMPS C++
sources through the `Doxygen <https://doxygen.nl>`_ program. Currently
the translation to HTML, PDF (via LaTeX), ePUB (for many e-book readers)
and MOBI (for Amazon Kindle readers) are supported. For that to work a
Python 3 interpreter, the ``doxygen`` tools and internet access to
download additional files and tools are required. This download is
usually only required once or after the documentation folder is returned
to a pristine state with ``make clean-all``.
For the documentation build a python virtual environment is set up in
the folder ``doc/docenv`` and various python packages are installed into
@ -179,7 +176,7 @@ math expressions transparently into embedded images.
For converting the generated ePUB file to a MOBI format file (for e-book
readers, like Kindle, that cannot read ePUB), you also need to have the
``ebook-convert`` tool from the "calibre" software
installed. `http://calibre-ebook.com/ <http://calibre-ebook.com/>`_
installed. `https://calibre-ebook.com/ <https://calibre-ebook.com/>`_
Typing ``make mobi`` will first create the ePUB file and then convert
it. On the Kindle readers in particular, you also have support for PDF
files, so you could download and view the PDF version as an alternative.
@ -219,9 +216,20 @@ be multiple tests run automatically:
- A test that only standard, printable ASCII text characters are used.
This runs the command ``env LC_ALL=C grep -n '[^ -~]' src/*.rst`` and
thus prints all offending lines with filename and line number
prepended to the screen. Special characters like the Angstrom
:math:`\mathrm{\mathring{A}}` should be typeset with embedded math
(like this ``:math:`\mathrm{\mathring{A}}```\ ).
prepended to the screen. Special characters like Greek letters
(:math:`\alpha~~\sigma~~\epsilon`), super- or subscripts
(:math:`x^2~~\mathrm{U}_{LJ}`), mathematical expressions
(:math:`\frac{1}{2}\mathrm{N}~~x\to\infty`), or the Angstrom symbol
(:math:`\AA`) should be typeset with embedded LaTeX (like this
``:math:`\alpha \sigma \epsilon```, ``:math:`x^2 \mathrm{E}_{LJ}```,
``:math:`\frac{1}{2}\mathrm{N} x\to\infty```, or ``:math:`\AA```\ ).
- Embedded LaTeX is rendered in HTML output with `MathJax
<https://www.mathjax.org/>`_ and in PDF output by passing the embedded
text to LaTeX. Some care has to be taken, though, since there are
limitations which macros and features can be used in either mode, so
it is recommended to always check whether any new or changed
documentation does translate and render correctly with either output.
- A test whether all styles are documented and listed in their
respective overview pages. A typical output with warnings looks like this:
@ -252,6 +260,5 @@ manual with ``make spelling``. This requires `a library called enchant
positives* (e.g. keywords, names, abbreviations) those can be added to
the file ``lammps/doc/utils/sphinx-config/false_positives.txt``.
.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
.. _lws: https://www.lammps.org
.. _rst: https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html

29
doc/src/Build_settings.rst
View File

@ -111,26 +111,25 @@ LAMMPS can use them if they are available on your system.
files in its default search path. You must specify ``FFT_LIB``
with the appropriate FFT libraries to include in the link.
The `KISS FFT library <http://kissfft.sf.net>`_ is included in the LAMMPS
distribution. It is portable across all platforms. Depending on the size
of the FFTs and the number of processors used, the other libraries listed
here can be faster.
The `KISS FFT library <https://github.com/mborgerding/kissfft>`_ is
included in the LAMMPS distribution. It is portable across all
platforms. Depending on the size of the FFTs and the number of
processors used, the other libraries listed here can be faster.
However, note that long-range Coulombics are only a portion of the
per-timestep CPU cost, FFTs are only a portion of long-range
Coulombics, and 1d FFTs are only a portion of the FFT cost (parallel
communication can be costly). A breakdown of these timings is printed
to the screen at the end of a run when using the
:doc:`kspace_style pppm <kspace_style>` command. The
:doc:`Screen and logfile output <Run_output>`
page gives more details. A more detailed (and time consuming)
report of the FFT performance is generated with the
per-timestep CPU cost, FFTs are only a portion of long-range Coulombics,
and 1d FFTs are only a portion of the FFT cost (parallel communication
can be costly). A breakdown of these timings is printed to the screen
at the end of a run when using the :doc:`kspace_style pppm
<kspace_style>` command. The :doc:`Screen and logfile output
<Run_output>` page gives more details. A more detailed (and time
consuming) report of the FFT performance is generated with the
:doc:`kspace_modify fftbench yes <kspace_modify>` command.
FFTW is a fast, portable FFT library that should also work on any
platform and can be faster than the KISS FFT library. You can
download it from `www.fftw.org <http://www.fftw.org>`_. LAMMPS requires
version 3.X; the legacy version 2.1.X is no longer supported.
platform and can be faster than the KISS FFT library. You can download
it from `www.fftw.org <https://www.fftw.org>`_. LAMMPS requires version
3.X; the legacy version 2.1.X is no longer supported.
Building FFTW for your box should be as simple as ``./configure; make;
make install``. The install command typically requires root privileges

1
doc/src/Commands.rst
View File

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

6
doc/src/Commands_all.rst
View File

@ -10,11 +10,14 @@
* :ref:`Dihedral styles <dihedral>`
* :ref:`Improper styles <improper>`
* :doc:`KSpace styles <Commands_kspace>`
* :doc:`Dump styles <Commands_dump>`
General commands
================
An alphabetic list of general LAMMPS commands.
An alphabetic list of general LAMMPS commands. Note that style
commands with many variants, can be more easily accessed via the small
table above.
.. table_from_list::
:columns: 5
@ -60,6 +63,7 @@ An alphabetic list of general LAMMPS commands.
* :doc:`kspace_modify <kspace_modify>`
* :doc:`kspace_style <kspace_style>`
* :doc:`label <label>`
* :doc:`labelmap <labelmap>`
* :doc:`lattice <lattice>`
* :doc:`log <log>`
* :doc:`mass <mass>`

7
doc/src/Commands_bond.rst
View File

@ -10,6 +10,7 @@
* :ref:`Dihedral styles <dihedral>`
* :ref:`Improper styles <improper>`
* :doc:`KSpace styles <Commands_kspace>`
* :doc:`Dump styles <Commands_dump>`
.. _bond:
@ -43,6 +44,7 @@ OPT.
* :doc:`harmonic (iko) <bond_harmonic>`
* :doc:`harmonic/shift (o) <bond_harmonic_shift>`
* :doc:`harmonic/shift/cut (o) <bond_harmonic_shift_cut>`
* :doc:`mesocnt <bond_mesocnt>`
* :doc:`mm3 <bond_mm3>`
* :doc:`morse (o) <bond_morse>`
* :doc:`nonlinear (o) <bond_nonlinear>`
@ -74,6 +76,7 @@ OPT.
*
*
*
* :doc:`amoeba <angle_amoeba>`
* :doc:`charmm (iko) <angle_charmm>`
* :doc:`class2 (ko) <angle_class2>`
* :doc:`class2/p6 <angle_class2>`
@ -90,9 +93,10 @@ OPT.
* :doc:`fourier/simple (o) <angle_fourier_simple>`
* :doc:`gaussian <angle_gaussian>`
* :doc:`harmonic (iko) <angle_harmonic>`
* :doc:`mesocnt <angle_mesocnt>`
* :doc:`mm3 <angle_mm3>`
* :doc:`quartic (o) <angle_quartic>`
* :doc:`sdk (o) <angle_sdk>`
* :doc:`spica (o) <angle_spica>`
* :doc:`table (o) <angle_table>`
.. _dihedral:
@ -152,6 +156,7 @@ OPT.
*
*
*
* :doc:`amoeba <improper_amoeba>`
* :doc:`class2 (ko) <improper_class2>`
* :doc:`cossq (o) <improper_cossq>`
* :doc:`cvff (io) <improper_cvff>`

3
doc/src/Commands_compute.rst
View File

@ -10,6 +10,7 @@
* :ref:`Dihedral styles <dihedral>`
* :ref:`Improper styles <improper>`
* :doc:`KSpace styles <Commands_kspace>`
* :doc:`Dump styles <Commands_dump>`
Compute commands
================
@ -138,6 +139,8 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`smd/vol <compute_smd_vol>`
* :doc:`snap <compute_sna_atom>`
* :doc:`sna/atom <compute_sna_atom>`
* :doc:`sna/grid <compute_sna_atom>`
* :doc:`sna/grid/local <compute_sna_atom>`
* :doc:`snad/atom <compute_sna_atom>`
* :doc:`snav/atom <compute_sna_atom>`
* :doc:`sph/e/atom <compute_sph_e_atom>`

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

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

6
doc/src/Commands_fix.rst
View File

@ -10,6 +10,7 @@
* :ref:`Dihedral styles <dihedral>`
* :ref:`Improper styles <improper>`
* :doc:`KSpace styles <Commands_kspace>`
* :doc:`Dump styles <Commands_dump>`
Fix commands
============
@ -28,6 +29,8 @@ OPT.
* :doc:`adapt/fep <fix_adapt_fep>`
* :doc:`addforce <fix_addforce>`
* :doc:`addtorque <fix_addtorque>`
* :doc:`amoeba/bitorsion <fix_amoeba_bitorsion>`
* :doc:`amoeba/pitorsion <fix_amoeba_pitorsion>`
* :doc:`append/atoms <fix_append_atoms>`
* :doc:`atc <fix_atc>`
* :doc:`atom/swap <fix_atom_swap>`
@ -103,7 +106,7 @@ OPT.
* :doc:`lb/viscous <fix_lb_viscous>`
* :doc:`lineforce <fix_lineforce>`
* :doc:`manifoldforce <fix_manifoldforce>`
* :doc:`mdi/aimd <fix_mdi_aimd>`
* :doc:`mdi/qm <fix_mdi_qm>`
* :doc:`meso/move <fix_meso_move>`
* :doc:`mol/swap <fix_mol_swap>`
* :doc:`momentum (k) <fix_momentum>`
@ -162,6 +165,7 @@ OPT.
* :doc:`orient/fcc <fix_orient>`
* :doc:`orient/eco <fix_orient_eco>`
* :doc:`pafi <fix_pafi>`
* :doc:`pair <fix_pair>`
* :doc:`phonon <fix_phonon>`
* :doc:`pimd <fix_pimd>`
* :doc:`planeforce <fix_planeforce>`

1
doc/src/Commands_kspace.rst
View File

@ -10,6 +10,7 @@
* :ref:`Dihedral styles <dihedral>`
* :ref:`Improper styles <improper>`
* :doc:`KSpace styles <Commands_kspace>`
* :doc:`Dump styles <Commands_dump>`
KSpace solvers
==============

17
doc/src/Commands_pair.rst
View File

@ -10,6 +10,7 @@
* :ref:`Dihedral styles <dihedral>`
* :ref:`Improper styles <improper>`
* :doc:`KSpace styles <Commands_kspace>`
* :doc:`Dump styles <Commands_dump>`
Pair_style potentials
======================
@ -38,6 +39,7 @@ OPT.
* :doc:`agni (o) <pair_agni>`
* :doc:`airebo (io) <pair_airebo>`
* :doc:`airebo/morse (io) <pair_airebo>`
* :doc:`amoeba <pair_amoeba>`
* :doc:`atm <pair_atm>`
* :doc:`awpmd/cut <pair_awpmd>`
* :doc:`beck (go) <pair_beck>`
@ -124,6 +126,7 @@ OPT.
* :doc:`hbond/dreiding/lj (o) <pair_hbond_dreiding>`
* :doc:`hbond/dreiding/morse (o) <pair_hbond_dreiding>`
* :doc:`hdnnp <pair_hdnnp>`
* :doc:`hippo <pair_amoeba>`
* :doc:`ilp/graphene/hbn (t) <pair_ilp_graphene_hbn>`
* :doc:`ilp/tmd (t) <pair_ilp_tmd>`
* :doc:`kolmogorov/crespi/full <pair_kolmogorov_crespi_full>`
@ -179,9 +182,9 @@ OPT.
* :doc:`lj/long/tip4p/long (o) <pair_lj_long>`
* :doc:`lj/mdf <pair_mdf>`
* :doc:`lj/relres (o) <pair_lj_relres>`
* :doc:`lj/sdk (gko) <pair_sdk>`
* :doc:`lj/sdk/coul/long (go) <pair_sdk>`
* :doc:`lj/sdk/coul/msm (o) <pair_sdk>`
* :doc:`lj/spica (gko) <pair_spica>`
* :doc:`lj/spica/coul/long (go) <pair_spica>`
* :doc:`lj/spica/coul/msm (o) <pair_spica>`
* :doc:`lj/sf/dipole/sf (go) <pair_dipole>`
* :doc:`lj/smooth (go) <pair_lj_smooth>`
* :doc:`lj/smooth/linear (o) <pair_lj_smooth_linear>`
@ -194,10 +197,11 @@ OPT.
* :doc:`lubricateU/poly <pair_lubricateU>`
* :doc:`mdpd <pair_mesodpd>`
* :doc:`mdpd/rhosum <pair_mesodpd>`
* :doc:`meam <pair_meam>`
* :doc:`meam (k) <pair_meam>`
* :doc:`meam/spline (o) <pair_meam_spline>`
* :doc:`meam/sw/spline <pair_meam_sw_spline>`
* :doc:`mesocnt <pair_mesocnt>`
* :doc:`mesocnt/viscous <pair_mesocnt>`
* :doc:`mesont/tpm <pair_mesont_tpm>`
* :doc:`mgpt <pair_mgpt>`
* :doc:`mie/cut (g) <pair_mie>`
@ -232,6 +236,7 @@ OPT.
* :doc:`oxrna2/xstk <pair_oxrna2>`
* :doc:`oxrna2/coaxstk <pair_oxrna2>`
* :doc:`pace (k) <pair_pace>`
* :doc:`pace/extrapolation <pair_pace>`
* :doc:`peri/eps <pair_peri>`
* :doc:`peri/lps (o) <pair_peri>`
* :doc:`peri/pmb (o) <pair_peri>`
@ -268,7 +273,9 @@ OPT.
* :doc:`spin/magelec <pair_spin_magelec>`
* :doc:`spin/neel <pair_spin_neel>`
* :doc:`srp <pair_srp>`
* :doc:`srp/react <pair_srp>`
* :doc:`sw (giko) <pair_sw>`
* :doc:`sw/angle/table <pair_sw_angle_table>`
* :doc:`sw/mod (o) <pair_sw>`
* :doc:`table (gko) <pair_table>`
* :doc:`table/rx (k) <pair_table_rx>`
@ -279,6 +286,7 @@ OPT.
* :doc:`tersoff/table (o) <pair_tersoff>`
* :doc:`tersoff/zbl (gko) <pair_tersoff_zbl>`
* :doc:`thole <pair_thole>`
* :doc:`threebody/table <pair_threebody_table>`
* :doc:`tip4p/cut (o) <pair_coul>`
* :doc:`tip4p/long (o) <pair_coul>`
* :doc:`tip4p/long/soft (o) <pair_fep_soft>`
@ -287,6 +295,7 @@ OPT.
* :doc:`vashishta (gko) <pair_vashishta>`
* :doc:`vashishta/table (o) <pair_vashishta>`
* :doc:`wf/cut <pair_wf_cut>`
* :doc:`ylz <pair_ylz>`
* :doc:`yukawa (gko) <pair_yukawa>`
* :doc:`yukawa/colloid (go) <pair_yukawa_colloid>`
* :doc:`zbl (gko) <pair_zbl>`

22
doc/src/Commands_parse.rst
View File

@ -123,14 +123,15 @@ LAMMPS:
.. _six:
6. If you want text with spaces to be treated as a single argument, it
can be enclosed in either single or double or triple quotes. A long
single argument enclosed in single or double quotes can span multiple
lines if the "&" character is used, as described above. When the
lines are concatenated together (and the "&" characters and line
breaks removed), the text will become a single line. If you want
multiple lines of an argument to retain their line breaks, the text
can be enclosed in triple quotes, in which case "&" characters are
not needed. For example:
can be enclosed in either single (') or double (") or triple (""")
quotes. A long single argument enclosed in single or double quotes
can span multiple lines if the "&" character is used, as described
in :ref:`1 <one>` above. When the lines are concatenated together
by LAMMPS (and the "&" characters and line breaks removed), the
combined text will become a single line. If you want multiple lines
of an argument to retain their line breaks, the text can be enclosed
in triple quotes, in which case "&" characters are not needed and do
not function as line continuation character. For example:
.. code-block:: LAMMPS
@ -144,8 +145,9 @@ LAMMPS:
System temperature = $t
"""
In each case, the single, double, or triple quotes are removed when
the single argument they enclose is stored internally.
In each of these cases, the single, double, or triple quotes are
removed and the enclosed text stored internally as a single
argument.
See the :doc:`dump modify format <dump_modify>`, :doc:`print
<print>`, :doc:`if <if>`, and :doc:`python <python>` commands for

1
doc/src/Developer.rst
View File

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

29
doc/src/Developer_plugins.rst
View File

@ -276,10 +276,27 @@ Compilation of the plugin can be managed via both, CMake or traditional
GNU makefiles. Some examples that can be used as a template are in the
``examples/plugins`` folder. The CMake script code has some small
adjustments to allow building the plugins for running unit tests with
them. Another example that converts the KIM package into a plugin can be
found in the ``examples/kim/plugin`` folder. No changes to the sources
of the KIM package themselves are needed; only the plugin interface and
loader code needs to be added. This example only supports building with
CMake, but is probably a more typical example. To compile you need to
run CMake with -DLAMMPS_SOURCE_DIR=<path/to/lammps/src/folder>. Other
them.
Another example that converts the KIM package into a plugin can be found
in the ``examples/kim/plugin`` folder. No changes to the sources of the
KIM package themselves are needed; only the plugin interface and loader
code needs to be added. This example only supports building with CMake,
but is probably a more typical example. To compile you need to run CMake
with -DLAMMPS_SOURCE_DIR=<path/to/lammps/src/folder>. Other
configuration setting are identical to those for compiling LAMMPS.
A second example for a plugin from a package is in the
``examples/PACKAGES/pace/plugin`` folder that will create a plugin from
the ML-PACE package. In this case the bulk of the code is in a static
external library that is being downloaded and compiled first and then
combined with the pair style wrapper and the plugin loader. This
example also contains a NSIS script that can be used to create an
Installer package for Windows (the mutual licensing terms of the
external library and LAMMPS conflict when distributing binaries, so the
ML-PACE package cannot be linked statically, but the LAMMPS headers
required to build the plugin are also available under a less restrictive
license). This will automatically set the required environment variable
and launching a (compatible) LAMMPS binary will load and register the
plugin and the ML-PACE package can then be used as it was linked into
LAMMPS.

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

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

14
doc/src/Developer_utils.rst
View File

@ -154,6 +154,9 @@ and parsing files or arguments.
.. doxygenfunction:: trim_and_count_words
:project: progguide
.. doxygenfunction:: join_words
:project: progguide
.. doxygenfunction:: split_words
:project: progguide
@ -172,6 +175,12 @@ and parsing files or arguments.
.. doxygenfunction:: is_double
:project: progguide
.. doxygenfunction:: is_id
:project: progguide
.. doxygenfunction:: is_type
:project: progguide
Potential file functions
^^^^^^^^^^^^^^^^^^^^^^^^
@ -202,10 +211,13 @@ Argument processing
.. doxygenfunction:: expand_args
:project: progguide
.. doxygenfunction:: expand_type
:project: progguide
Convenience functions
^^^^^^^^^^^^^^^^^^^^^
.. doxygenfunction:: logmesg(LAMMPS *lmp, const S &format, Args&&... args)
.. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &format, Args&&... args)
:project: progguide
.. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &mesg)

2
doc/src/Errors_debug.rst
View File

@ -75,7 +75,7 @@ Using the GDB debugger to get a stack trace
There are two options to use the GDB debugger for identifying the origin
of the segmentation fault or similar crash. The GDB debugger has many
more features and options, as can be seen for example its `online
documentation <http://sourceware.org/gdb/current/onlinedocs/gdb/>`_.
documentation <https://sourceware.org/gdb/current/onlinedocs/gdb/>`_.
Run LAMMPS from within the debugger
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

166
doc/src/Errors_messages.rst
View File

@ -476,65 +476,6 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
*Bonds defined but no bond types*
The data file header lists bonds but no bond types.
*Bond/react: Cannot use fix bond/react with non-molecular systems*
Only systems with bonds that can be changed can be used. Atom_style
template does not qualify.
*Bond/react: Invalid template atom ID in map file*
Atom IDs in molecule templates range from 1 to the number of atoms in the template.
*Bond/react: Rmax cutoff is longer than pairwise cutoff*
This is not allowed because bond creation is done using the pairwise
neighbor list.
*Bond/react: Molecule template ID for fix bond/react does not exist*
A valid molecule template must have been created with the molecule
command.
*Bond/react: Reaction templates must contain the same number of atoms*
There should be a one-to-one correspondence between atoms in the
pre-reacted and post-reacted templates, as specified by the map file.
*Bond/react: Unknown section in map file*
Please ensure reaction map files are properly formatted.
*Bond/react: Atom/Bond type affected by reaction too close to template edge*
This means an atom which changes type or connectivity during the
reaction is too close to an 'edge' atom defined in the map
file. This could cause incorrect assignment of bonds, angle, etc.
Generally, this means you must include more atoms in your templates,
such that there are at least two atoms between each atom involved in
the reaction and an edge atom.
*Bond/react: Fix bond/react needs ghost atoms from farther away*
This is because a processor needs to map the entire unreacted
molecule template onto simulation atoms it knows about. The
comm_modify cutoff command can be used to extend the communication
range.
*Bond/react: A deleted atom cannot remain bonded to an atom that is not deleted*
Self-explanatory.
*Bond/react: First neighbors of chiral atoms must be of mutually different types*
Self-explanatory.
*Bond/react: Chiral atoms must have exactly four first neighbors*
Self-explanatory.
*Bond/react: Molecule template 'Coords' section required for chiralIDs keyword*
The coordinates of atoms in the pre-reacted template are used to determine
chirality.
*Bond/react special bond generation overflow*
The number of special bonds per-atom created by a reaction exceeds the
system setting. See the read_data or create_box command for how to
specify this value.
*Bond/react topology/atom exceed system topology/atom*
The number of bonds, angles etc per-atom created by a reaction exceeds
the system setting. See the read_data or create_box command for how to
specify this value.
*Both restart files must use % or neither*
Self-explanatory.
@ -1291,7 +1232,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
*Cannot use chosen neighbor list style with lj/gromacs/kk*
Self-explanatory.
*Cannot use chosen neighbor list style with lj/sdk/kk*
*Cannot use chosen neighbor list style with lj/spica/kk*
That style is not supported by Kokkos.
*Cannot use chosen neighbor list style with pair eam/kk*
@ -1659,10 +1600,10 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
*Cannot use newton pair with lj/gromacs/gpu pair style*
Self-explanatory.
*Cannot use newton pair with lj/sdk/coul/long/gpu pair style*
*Cannot use newton pair with lj/spica/coul/long/gpu pair style*
Self-explanatory.
*Cannot use newton pair with lj/sdk/gpu pair style*
*Cannot use newton pair with lj/spica/gpu pair style*
Self-explanatory.
*Cannot use newton pair with lj96/cut/gpu pair style*
@ -3521,6 +3462,65 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
acquire needed info, The comm_modify cutoff command can be used to
extend the communication range.
*Fix bond/react: Cannot use fix bond/react with non-molecular systems*
Only systems with bonds that can be changed can be used. Atom_style
template does not qualify.
*Fix bond/react: Invalid template atom ID in map file*
Atom IDs in molecule templates range from 1 to the number of atoms in the template.
*Fix bond/react: Rmax cutoff is longer than pairwise cutoff*
This is not allowed because bond creation is done using the pairwise
neighbor list.
*Fix bond/react: Molecule template ID for fix bond/react does not exist*
A valid molecule template must have been created with the molecule
command.
*Fix bond/react: Reaction templates must contain the same number of atoms*
There should be a one-to-one correspondence between atoms in the
pre-reacted and post-reacted templates, as specified by the map file.
*Fix bond/react: Unknown section in map file*
Please ensure reaction map files are properly formatted.
*Fix bond/react: Atom/Bond type affected by reaction too close to template edge*
This means an atom which changes type or connectivity during the
reaction is too close to an 'edge' atom defined in the map
file. This could cause incorrect assignment of bonds, angle, etc.
Generally, this means you must include more atoms in your templates,
such that there are at least two atoms between each atom involved in
the reaction and an edge atom.
*Fix bond/react: Fix bond/react needs ghost atoms from farther away*
This is because a processor needs to map the entire unreacted
molecule template onto simulation atoms it knows about. The
comm_modify cutoff command can be used to extend the communication
range.
*Fix bond/react: A deleted atom cannot remain bonded to an atom that is not deleted*
Self-explanatory.
*Fix bond/react: First neighbors of chiral atoms must be of mutually different types*
Self-explanatory.
*Fix bond/react: Chiral atoms must have exactly four first neighbors*
Self-explanatory.
*Fix bond/react: Molecule template 'Coords' section required for chiralIDs keyword*
The coordinates of atoms in the pre-reacted template are used to determine
chirality.
*Fix bond/react special bond generation overflow*
The number of special bonds per-atom created by a reaction exceeds the
system setting. See the read_data or create_box command for how to
specify this value.
*Fix bond/react topology/atom exceed system topology/atom*
The number of bonds, angles etc per-atom created by a reaction exceeds
the system setting. See the read_data or create_box command for how to
specify this value.
*Fix bond/swap cannot use dihedral or improper styles*
These styles cannot be defined when using this fix.
@ -5453,6 +5453,11 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
Mass command must set a type from 1-N where N is the number of atom
types.
*Invalid label2type() function syntax in variable formula*
The first argument must be a label map kind (atom, bond, angle,
dihedral, or improper) and the second argument must be a valid type
label that has been assigned to a numeric type.
*Invalid use of library file() function*
This function is called through the library interface. This
error should not occur. Contact the developers if it does.
@ -5585,9 +5590,18 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
*LJ6 off not supported in pair_style buck/long/coul/long*
Self-explanatory.
*Label map is incomplete: all types must be assigned a unique type label*
For a given type-kind (atom types, bond types, etc.) to be written to
the data file, all associated types must be assigned a type label, and
each type label can be assigned to only one numeric type.
*Label wasn't found in input script*
Self-explanatory.
*Labelmap command before simulation box is defined*
The labelmap command cannot be used before a read_data,
read_restart, or create_box command.
*Lattice orient vectors are not orthogonal*
The three specified lattice orientation vectors must be mutually
orthogonal.
@ -5863,6 +5877,12 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
*Must not have multiple fixes change box parameter ...*
Self-explanatory.
*Must read Angle Type Labels before Angles*
An Angle Type Labels section of a data file must come before the Angles section.
*Must read Atom Type Labels before Atoms*
An Atom Type Labels section of a data file must come before the Atoms section.
*Must read Atoms before Angles*
The Atoms section of a data file must come before an Angles section.
@ -5893,6 +5913,15 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
The Atoms section of a data file must come before a Velocities
section.
*Must read Bond Type Labels before Bonds*
A Bond Type Labels section of a data file must come before the Bonds section.
*Must read Dihedral Type Labels before Dihedrals*
An Dihedral Type Labels section of a data file must come before the Dihedrals section.
*Must read Improper Type Labels before Impropers*
An Improper Type Labels section of a data file must come before the Impropers section.
*Must re-specify non-restarted pair style (xxx) after read_restart*
For pair styles, that do not store their settings in a restart file,
it must be defined with a new 'pair_style' command after read_restart.
@ -6782,7 +6811,7 @@ keyword to allow for additional bonds to be formed
This is because the computation of constraint forces within a water
molecule adds forces to atoms owned by other processors.
*Pair style lj/sdk/coul/long/gpu requires atom attribute q*
*Pair style lj/spica/coul/long/gpu requires atom attribute q*
The atom style defined does not have this attribute.
*Pair style nb3b/harmonic requires atom IDs*
@ -7849,6 +7878,10 @@ keyword to allow for additional bonds to be formed
Number of local atoms times number of columns must fit in a 32-bit
integer for dump.
*Topology type exceeds system topology type*
The number of bond, angle, etc types exceeds the system setting. See
the create_box or read_data command for how to specify these values.
*Tree structure in joint connections*
Fix poems cannot (yet) work with coupled bodies whose joints connect
the bodies in a tree structure.
@ -7873,6 +7906,13 @@ keyword to allow for additional bonds to be formed
*Two groups cannot be the same in fix spring couple*
Self-explanatory.
*The %s type label %s is already in use for type %s*
For a given type-kind (atom types, bond types, etc.), a given type
label can be assigned to only one numeric type.
*Type label string %s for %s type %s is invalid*
See the labelmap command documentation for valid type labels.
*Unable to initialize accelerator for use*
There was a problem initializing an accelerator for the gpu package

25
doc/src/Errors_warnings.rst
View File

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

2116
doc/src/Fortran.rst
View File

File diff suppressed because it is too large Load Diff

3
doc/src/Howto.rst
View File

@ -34,6 +34,7 @@ Settings howto
:maxdepth: 1
Howto_2d
Howto_type_labels
Howto_triclinic
Howto_thermostat
Howto_barostat
@ -65,6 +66,7 @@ Force fields howto
:maxdepth: 1
Howto_bioFF
Howto_amoeba
Howto_tip3p
Howto_tip4p
Howto_spc
@ -83,6 +85,7 @@ Packages howto
Howto_coreshell
Howto_drude
Howto_drude2
Howto_peri
Howto_manifold
Howto_spins

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

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

33
doc/src/Howto_bioFF.rst
View File

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

113
doc/src/Howto_bpm.rst
View File

@ -33,46 +33,6 @@ reference state of a bond. Bonds that are created midway into a run,
such as those created by pouring grains using :doc:`fix pour
<fix_pour>`, are initialized on that timestep.
As bonds can be broken between neighbor list builds, the
:doc:`special_bonds <special_bonds>` command works differently for BPM
bond styles. There are two possible settings which determine how pair
interactions work between bonded particles. First, one can turn off
all pair interactions between bonded particles. Unlike :doc:`bond
quartic <bond_quartic>`, this is not done by subtracting pair forces
during the bond computation but rather by dynamically updating the
special bond list. This is the default behavior of BPM bond styles and
is done by updating the 1-2 special bond list as bonds break. To do
this, LAMMPS requires :doc:`newton <newton>` bond off such that all
processors containing an atom know when a bond breaks. Additionally,
one must do either (A) or (B).
A) Use the following special bond settings
.. code-block:: LAMMPS
special_bonds lj 0 1 1 coul 1 1 1
These settings accomplish two goals. First, they turn off 1-3 and 1-4
special bond lists, which are not currently supported for BPMs. As
BPMs often have dense bond networks, generating 1-3 and 1-4 special
bond lists is expensive. By setting the lj weight for 1-2 bonds to
zero, this turns off pairwise interactions. Even though there are no
charges in BPM models, setting a nonzero coul weight for 1-2 bonds
ensures all bonded neighbors are still included in the neighbor list
in case bonds break between neighbor list builds.
B) Alternatively, one can simply overlay pair interactions such that all
bonded particles also feel pair interactions. This can be
accomplished by using the *overlay/pair* keyword present in all bpm
bond styles and by using the following special bond settings
.. code-block:: LAMMPS
special_bonds lj/coul 1 1 1
See the :doc:`Howto <Howto_broken_bonds>` page on broken bonds for
more information.
----------
Currently there are two types of bonds included in the BPM
@ -91,12 +51,6 @@ This also requires a unique integrator :doc:`fix nve/bpm/sphere
<fix_nve_bpm_sphere>` which numerically integrates orientation similar
to :doc:`fix nve/asphere <fix_nve_asphere>`.
To monitor the fracture of bonds in the system, all BPM bond styles
have the ability to record instances of bond breakage to output using
the :doc:`dump local <dump>` command. Additionally, one can use
:doc:`compute nbond/atom <compute_nbond_atom>` to tally the current
number of bonds per atom.
In addition to bond styles, a new pair style :doc:`pair bpm/spring
<pair_bpm_spring>` was added to accompany the bpm/spring bond
style. This pair style is simply a hookean repulsion with similar
@ -104,6 +58,73 @@ velocity damping as its sister bond style.
----------
Bond data can be output using a combination of standard LAMMPS commands.
A list of IDs for bonded atoms can be generated using the
:doc:`compute property/local <compute_property_local>` command.
Various properties of bonds can be computed using the
:doc:`compute bond/local <compute_bond_local>` command. This
command allows one to access data saved to the bond's history
such as the reference length of the bond. More information on
bond history data can be found on the documentation pages for the specific
BPM bond styles. Finally, this data can be output using a :doc:`dump local <dump>`
command. As one may output many columns from the same compute, the
:doc:`dump modify <dump_modify>` *colname* option may be used to provide
more helpful column names. An example of this procedure is found in
/examples/bpm/pour/. External software, such as OVITO, can read these dump
files to render bond data.
----------
As bonds can be broken between neighbor list builds, the
:doc:`special_bonds <special_bonds>` command works differently for BPM
bond styles. There are two possible settings which determine how pair
interactions work between bonded particles. First, one can overlay
pair forces with bond forces such that all bonded particles also
feel pair interactions. This can be accomplished by using the *overlay/pair*
keyword present in all bpm bond styles and by using the following special
bond settings
.. code-block:: LAMMPS
special_bonds lj/coul 1 1 1
Alternatively, one can turn off all pair interactions between bonded
particles. Unlike :doc:`bond quartic <bond_quartic>`, this is not done
by subtracting pair forces during the bond computation but rather by
dynamically updating the special bond list. This is the default behavior
of BPM bond styles and is done by updating the 1-2 special bond list as
bonds break. To do this, LAMMPS requires :doc:`newton <newton>` bond off
such that all processors containing an atom know when a bond breaks.
Additionally, one must use the following special bond settings
.. code-block:: LAMMPS
special_bonds lj 0 1 1 coul 1 1 1
These settings accomplish two goals. First, they turn off 1-3 and 1-4
special bond lists, which are not currently supported for BPMs. As
BPMs often have dense bond networks, generating 1-3 and 1-4 special
bond lists is expensive. By setting the lj weight for 1-2 bonds to
zero, this turns off pairwise interactions. Even though there are no
charges in BPM models, setting a nonzero coul weight for 1-2 bonds
ensures all bonded neighbors are still included in the neighbor list
in case bonds break between neighbor list builds.
To monitor the fracture of bonds in the system, all BPM bond styles
have the ability to record instances of bond breakage to output using
the :doc:`dump local <dump>` command. Since one may frequently output
a list of broken bonds and the time they broke, the
:doc:`dump modify <dump_modify>` option *header no* may be useful to
avoid repeatedly printing the header of the dump file. An example of
this procedure is found in /examples/bpm/impact/. Additionally,
one can use :doc:`compute nbond/atom <compute_nbond_atom>` to tally the
current number of bonds per atom.
See the :doc:`Howto <Howto_broken_bonds>` page on broken bonds for
more information.
----------
While LAMMPS has many utilities to create and delete bonds, *only*
the following are currently compatible with BPM bond styles:

2
doc/src/Howto_github.rst
View File

@ -10,7 +10,7 @@ changes or additions you have made to LAMMPS into the official LAMMPS
distribution. It uses the process of updating this very tutorial as an
example to describe the individual steps and options. You need to be
familiar with git and you may want to have a look at the `git book
<http://git-scm.com/book/>`_ to familiarize yourself with some of the
<https://git-scm.com/book/>`_ to familiarize yourself with some of the
more advanced git features used below.
As of fall 2016, submitting contributions to LAMMPS via pull requests

2
doc/src/Howto_manifold.rst
View File

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

63
doc/src/Howto_mdi.rst
View File

@ -5,9 +5,9 @@ Client/server coupling of two (or more) codes is where one code is the
"client" and sends request messages (data) to one (or more) "server"
code(s). A server responds to each request with a reply message
(data). This enables two (or more) codes to work in tandem to perform
a simulation. LAMMPS can act as either a client or server code; it
does this by using the `MolSSI Driver Interface (MDI) library
<https://molssi-mdi.github.io/MDI_Library/html/index.html>`_,
a simulation. In this context, LAMMPS can act as either a client or
server code. It does this by using the `MolSSI Driver Interface (MDI)
library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_,
developed by the `Molecular Sciences Software Institute (MolSSI)
<https://molssi.org>`_, which is supported by the :ref:`MDI <PKG-MDI>`
package.
@ -63,22 +63,39 @@ The package also provides a :doc:`mdi plugin <mdi>` command which
enables LAMMPS to operate as an MDI driver and load an MDI engine as a
plugin library.
The package also has a `fix mdi/aimd <fix_mdi_aimd>` command in which
LAMMPS operates as an MDI driver to perform *ab initio* MD simulations
in conjunction with a quantum mechanics code. Its post_force() method
illustrates how a driver issues MDI commands to another code. This
command can be used to couple to an MDI engine which is either a
stand-alone code or a plugin library.
The package also has a `fix mdi/qm <fix_mdi_qm>` command in which
LAMMPS operates as an MDI driver in conjunction with a quantum
mechanics code as an MDI engine. The post_force() method of the
fix_mdi_qm.cpp file shows how a driver issues MDI commands to another
code. This command can be used to couple to an MDI engine which is
either a stand-alone code or a plugin library.
As explained on the `fix mdi/qm <fix_mdi_qm>` command doc page, it can
be used to perform *ab initio* MD simulations or energy minimizations,
or to evaluate the quantum energy and forces for a series of
independent systems. The examples/mdi directory has example input
scripts for all of these use cases.
----------
The examples/mdi directory contains Python scripts and LAMMPS input
script which use LAMMPS as either an MDI driver or engine or both.
Three example use cases are provided:
Currently, 5 example use cases are provided:
* Run ab initio MD (AIMD) using 2 instances of LAMMPS, one as driver
and one as an engine. As an engine, LAMMPS is a surrogate for a
quantum code.
* Run ab initio MD (AIMD) using 2 instances of LAMMPS. As a driver
LAMMPS performs the timestepping in either NVE or NPT mode. As an
engine, LAMMPS computes forces and is a surrogate for a quantum
code.
* As a driver, LAMMPS runs an MD simulation. Every N steps it passes
the current snapshot to an MDI engine to evaluate the energy,
virial, and peratom forces. As the engine LAMMPS is a surrogate for
a quantum code.
* As a driver, LAMMPS loops over a series of data files and passes the
configuration to an MDI engine to evaluate the energy, virial, and
peratom forces. As the engine LAMMPS is a surrogate for a quantum
code.
* A Python script driver invokes a sequence of unrelated LAMMPS
calculations. Calculations can be single-point energy/force
@ -91,20 +108,22 @@ Three example use cases are provided:
Note that in any of these example where LAMMPS is used as an engine,
an actual QM code (which supports MDI) could be used in its place,
without modifying other code or scripts, except to specify the name of
the QM code.
without modifying the input scripts or launch commands, except to
specify the name of the QM code.
The examples/mdi/README file explains how to launch both driver and
The examples/mdi/Run.sh file illustrates how to launch both driver and
engine codes so that they communicate using the MDI library via either
MPI or sockets.
MPI or sockets. Or using the engine as a stand-alone code or plugin
library.
-------------
Currently there are two quantum DFT codes which have direct MDI
support, `Quantum ESPRESSO (QE) <https://www.quantum-espresso.org/>`_
and `INQ <https://qsg.llnl.gov/node/101.html>`_. There are also
several QM codes which have indirect support through QCEngine or i-PI.
The former means they require a wrapper program (QCEngine) with MDI
Currently there are at least two quantum DFT codes which have direct
MDI support, `Quantum ESPRESSO (QE)
<https://www.quantum-espresso.org/>`_ and `INQ
<https://qsg.llnl.gov/node/101.html>`_. There are also several QM
codes which have indirect support through QCEngine or i-PI. The
former means they require a wrapper program (QCEngine) with MDI
support which writes/read files to pass data to the quantum code
itself. The list of QCEngine-supported and i-PI-supported quantum
codes is on the `MDI webpage

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

File diff suppressed because it is too large Load Diff

2
doc/src/Howto_spc.rst
View File

@ -38,7 +38,7 @@ the partial charge assignments change:
See the :ref:`(Berendsen) <howto-Berendsen>` reference for more details on both
the SPC and SPC/E models.
Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
----------

16
doc/src/Howto_spins.rst
View File

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

4
doc/src/Howto_structured_data.rst
View File

@ -184,7 +184,7 @@ frame.
.. code-block:: python
import re, yaml
import yaml
import pandas as pd
try:
@ -193,7 +193,7 @@ frame.
from yaml import SafeLoader as Loader
with open("ave.yaml") as f:
ave = yaml.load(docs, Loader=Loader)
ave = yaml.load(f, Loader=Loader)
keys = ave['keywords']
df = {}

2
doc/src/Howto_tip3p.rst
View File

@ -49,7 +49,7 @@ details:
| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
|
Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
----------

39
doc/src/Howto_tip4p.rst
View File

@ -8,18 +8,28 @@ This site M is located at a fixed distance away from the oxygen along
the bisector of the HOH bond angle. A bond style of *harmonic* and an
angle style of *harmonic* or *charmm* should also be used.
A TIP4P model is run with LAMMPS using either this command
A TIP4P model is run with LAMMPS using either these commands
for a cutoff model:
* :doc:`pair_style tip4p/cut <pair_lj_cut_tip4p>`
* :doc:`pair_style lj/cut/tip4p/cut <pair_lj_cut_tip4p>`
or these two commands for a long-range model:
or these commands for a long-range model:
* :doc:`pair_style tip4p/long <pair_coul>`
* :doc:`pair_style lj/cut/tip4p/long <pair_lj_cut_tip4p>`
* :doc:`pair_style lj/long/tip4p/long <pair_lj_long>`
* :doc:`pair_style tip4p/long/soft <pair_fep_soft>`
* :doc:`pair_style lj/cut/tip4p/long/soft <pair_fep_soft>`
* :doc:`kspace_style pppm/tip4p <kspace_style>`
* :doc:`kspace_style pppm/disp/tip4p <kspace_style>`
For both models, the bond lengths and bond angles should be held fixed
using the :doc:`fix shake <fix_shake>` command.
The bond lengths and bond angles should be held fixed using the
:doc:`fix shake <fix_shake>` or :doc:`fix rattle <fix_shake>` command,
unless a parameterization for a flexible TIP4P model is used. The
parameter sets listed below are all for rigid TIP4P model variants and
thus the bond and angle force constants are not used and can be set to
any legal value; only equilibrium length and angle are used.
These are the additional parameters (in real units) to set for O and H
atoms and the water molecule to run a rigid TIP4P model with a cutoff
@ -87,17 +97,18 @@ solver (e.g. Ewald or PPPM in LAMMPS):
| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
|
Note that the when using the TIP4P pair style, the neighbor list
cutoff for Coulomb interactions is effectively extended by a distance
2 \* (OM distance), to account for the offset distance of the
fictitious charges on O atoms in water molecules. Thus it is
typically best in an efficiency sense to use a LJ cutoff >= Coulomb
cutoff + 2\*(OM distance), to shrink the size of the neighbor list.
This leads to slightly larger cost for the long-range calculation, so
you can test the trade-off for your model. The OM distance and the LJ
and Coulombic cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long <pair_lj_cut_tip4p>` command.
Note that the when using the TIP4P pair style, the neighbor list cutoff
for Coulomb interactions is effectively extended by a distance 2 \* (OM
distance), to account for the offset distance of the fictitious charges
on O atoms in water molecules. Thus it is typically best in an
efficiency sense to use a LJ cutoff >= Coulomb cutoff + 2\*(OM
distance), to shrink the size of the neighbor list. This leads to
slightly larger cost for the long-range calculation, so you can test the
trade-off for your model. The OM distance and the LJ and Coulombic
cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long
<pair_lj_cut_tip4p>` command.
Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
----------

126
doc/src/Howto_type_labels.rst Normal file
View File

@ -0,0 +1,126 @@
Type labels
===========
.. versionadded:: 15Sep2022
Each atom in LAMMPS has an associated numeric atom type. Similarly,
each bond, angle, dihedral, and improper is assigned a bond type,
angle type, and so on. The primary use of these types is to map
potential (force field) parameters to the interactions of the atom,
bond, angle, dihedral, and improper.
By default, type values are entered as integers from 1 to Ntypes
wherever they appear in LAMMPS input or output files. The total number
Ntypes for each interaction is "locked in" when the simulation box
is created.
A recent addition to LAMMPS is the option to use strings - referred
to as type labels - as an alternative. Using type labels instead of
numeric types can be advantageous in various scenarios. For example,
type labels can make inputs more readable and generic (i.e. usable through
the :doc:`include command <include>` for different systems with different
numerical values assigned to types. This generality also applies to
other inputs like data files read by :doc:`read_data <read_data>` or
molecule template files read by the :doc:`molecule <molecule>`
command. See below for a list of other commands that can use
type labels in different ways.
LAMMPS will *internally* continue to use numeric types, which means
that many previous restrictions still apply. For example, the total
number of types is locked in when creating the simulation box, and
potential parameters for each type must be provided even if not used
by any interactions.
A collection of type labels for all type-kinds (atom types, bond types,
etc.) is stored as a "label map" which is simply a list of numeric types
and their associated type labels. Within a type-kind, each type label
must be unique. It can be assigned to only one numeric type. To read
and write type labels to data files for a given type-kind, *all*
associated numeric types need have a type label assigned. Partial
maps can be saved with the :doc:`labelmap write <labelmap>` command
and read back with the :doc:`include <include>` command.
Valid type labels can contain most ASCII characters, but cannot start
with a number, a '#', or a '*'. Also, labels must not contain whitespace
characters. When using the :doc:`labelmap command <labelmap>` in the
LAMMPS input, if certain characters appear in the type label, such as
the single (') or double (") quote or the '#' character, the label
must be put in either double, single, or triple (""") quotes. Triple
quotes allow for the most generic type label strings, but they require
to have a leading and trailing blank space. When defining type labels
the blanks will be ignored. Example:
.. code-block:: LAMMPS
labelmap angle 1 """ C1'-C2"-C3# """
This command will map the string ```C1'-C2"-C3#``` to the angle type 1.
There are two ways to define label maps. One is via the :doc:`labelmap
<labelmap>` command. The other is via the :doc:`read_data <read_data>`
command. A data file can have sections such as *Atom Type Labels*, *Bond
Type Labels*, etc., which assign type labels to numeric types. The
label map can be written out to data files by the :doc:`write_data
<write_data>` command. This map is also written to and read from
restart files, by the :doc:`write_restart <write_restart>` and
:doc:`read_restart <read_restart>` commands.
----------
Use of type labels in LAMMPS input or output
""""""""""""""""""""""""""""""""""""""""""""
Many LAMMPS input script commands that take a numeric type as an
argument can use the associated type label instead. If a type label
is not defined for a particular numeric type, only its numeric type
can be used.
This example assigns labels to the atom types, and then uses the type
labels to redefine the pair coefficients.
.. code-block:: LAMMPS
pair_coeff 1 2 1.0 1.0 # numeric types
labelmap atom 1 C 2 H
pair_coeff C H 1.0 1.0 # type labels
Adding support for type labels to various commands is an ongoing
project. If an input script command (or a section in a file read by a
command) allows substituting a type label for a numeric type argument,
it will be explicitly mentioned in that command's documentation page.
As a temporary measure, input script commands can take advantage of
variables and how they can be expanded during processing of the input.
The variables can use functions that will translate type label strings
to their respective number as defined in the current label map. See the
:doc:`variable <variable>` command for details.
For example, here is how the pair_coeff command could be used with
type labels if it did not yet support them, either with an explicit
variable command or an implicit variable used in the pair_coeff
command.
.. code-block:: LAMMPS
labelmap atom 1 C 2 H
variable atom1 equal label2type(atom,C)
variable atom2 equal label2type(atom,H)
pair_coeff ${atom1} ${atom2} 1.0 1.0
.. code-block:: LAMMPS
labelmap atom 1 C 2 H
pair_coeff $(label2type(atom,C)) $(label2type(atom,H)) 80.0 1.2
----------
Commands that can use label types
"""""""""""""""""""""""""""""""""
Any workflow that involves reading multiple data files, molecule
templates or a combination of the two can be streamlined by using type
labels instead of numeric types, because types are automatically synced
between the files. The creation of simulation-ready reaction templates
for :doc:`fix bond/react <fix_bond_react>` is much simpler when using
type labels, and results in templates that can be used without
modification in multiple simulations or different systems.

17
doc/src/Howto_viscosity.rst
View File

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

7
doc/src/Howto_viz.rst
View File

@ -17,9 +17,10 @@ formats. See the :doc:`Tools <Tools>` page for details.
A Python-based toolkit distributed by our group can read native LAMMPS
dump files, including custom dump files with additional columns of
user-specified atom information, and convert them to various formats
or pipe them into visualization software directly. See the `Pizza.py WWW site <pizza_>`_ for details. Specifically, Pizza.py can convert
LAMMPS dump files into PDB, XYZ, `EnSight <ensight_>`_, and VTK formats.
user-specified atom information, and convert them to various formats or
pipe them into visualization software directly. See the `Pizza.py WWW
site <pizza_>`_ for details. Specifically, Pizza.py can convert LAMMPS
dump files into PDB, XYZ, `EnSight <ensight_>`_, and VTK formats.
Pizza.py can pipe LAMMPS dump files directly into the Raster3d and
RasMol visualization programs. Pizza.py has tools that do interactive
3d OpenGL visualization and one that creates SVG images of dump file

18
doc/src/Install.rst
View File

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

11
doc/src/Install_conda.rst
View File

@ -5,7 +5,7 @@ Binaries are available for MacOS or Linux via `Conda <conda_>`_.
First, one must setup the Conda package manager on your system. Follow the
instructions to install `Miniconda <mini_conda_install_>`_, then create a conda
environment (named `my-lammps-env` or whatever you prefer) for your lammps
environment (named `my-lammps-env` or whatever you prefer) for your LAMMPS
install:
.. code-block:: bash
@ -13,7 +13,7 @@ install:
% conda config --add channels conda-forge
% conda create -n my-lammps-env
Then, you can install lammps on your system with the following command:
Then, you can install LAMMPS on your system with the following command:
.. code-block:: bash
@ -38,3 +38,10 @@ up the Conda capability.
.. _openkim: https://openkim.org
.. _conda: https://docs.conda.io/en/latest/index.html
.. _mini_conda_install: https://docs.conda.io/en/latest/miniconda.html
.. note::
If you have questions about these pre-compiled LAMMPS executables,
you need to contact the people preparing those packages. The LAMMPS
developers have no control over their choices of how they configure
and build their packages and when they update them.

130
doc/src/Install_linux.rst
View File

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

2
doc/src/Install_windows.rst
View File

@ -6,7 +6,7 @@ Windows system can be downloaded from this site:
.. parsed-literal::
`http://packages.lammps.org/windows.html <http://packages.lammps.org/windows.html>`_
`https://packages.lammps.org/windows.html <https://packages.lammps.org/windows.html>`_
Note that each installer package has a date in its name, which
corresponds to the LAMMPS version of the same date. Installers for

4
doc/src/Intro_authors.rst
View File

@ -4,13 +4,13 @@ Authors of LAMMPS
The primary LAMMPS developers are at Sandia National Labs and Temple
University:
* `Steve Plimpton <sjp_>`_, sjplimp at sandia.gov
* `Steve Plimpton <sjp_>`_, sjplimp at gmail.com
* Aidan Thompson, athomps at sandia.gov
* Stan Moore, stamoor at sandia.gov
* Axel Kohlmeyer, akohlmey at gmail.com
* Richard Berger, richard.berger at outlook.com
.. _sjp: http://www.cs.sandia.gov/~sjplimp
.. _sjp: https://sjplimp.github.io
.. _lws: https://www.lammps.org
Past developers include Paul Crozier and Mark Stevens, both at Sandia,

8
doc/src/Intro_citing.rst
View File

@ -27,15 +27,15 @@ namely https://www.lammps.org.
The original publication describing the parallel algorithms used in the
initial versions of LAMMPS is:
`S. Plimpton, Fast Parallel Algorithms for Short-Range Molecular Dynamics, J Comp Phys, 117, 1-19 (1995). <http://www.sandia.gov/~sjplimp/papers/jcompphys95.pdf>`_
`S. Plimpton, Fast Parallel Algorithms for Short-Range Molecular Dynamics, J Comp Phys, 117, 1-19 (1995). <https://doi.org/10.1006/jcph.1995.1039>`_
DOI for the LAMMPS source code
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
LAMMPS developers use the `Zenodo service at CERN <https://zenodo.org/>`_
to create digital object identifies (DOI) for stable releases of the
LAMMPS source code. There are two types of DOIs for the LAMMPS source code.
The LAMMPS developers use the `Zenodo service at CERN <https://zenodo.org/>`_
to create digital object identifiers (DOI) for stable releases of the
LAMMPS source code. There are two types of DOIs for the LAMMPS source code.
The canonical DOI for **all** versions of LAMMPS, which will always
point to the **latest** stable release version is:

4
doc/src/Intro_features.rst
View File

@ -95,7 +95,7 @@ commands)
* metal-organic framework potentials (QuickFF, MO-FF)
* implicit solvent potentials: hydrodynamic lubrication, Debye
* force-field compatibility with common CHARMM, AMBER, DREIDING, OPLS, GROMACS, COMPASS options
* access to the `OpenKIM Repository <http://openkim.org>`_ of potentials via :doc:`kim command <kim_commands>`
* access to the `OpenKIM Repository <https://openkim.org>`_ of potentials via the :doc:`kim command <kim_commands>`
* hybrid potentials: multiple pair, bond, angle, dihedral, improper potentials can be used in one simulation
* overlaid potentials: superposition of multiple pair potentials (including many-body) with optional scale factor
@ -205,7 +205,7 @@ Pre- and post-processing
.. _pizza: https://lammps.github.io/pizza
.. _python: http://www.python.org
.. _python: https://www.python.org
.. _special:

6
doc/src/Intro_nonfeatures.rst
View File

@ -33,7 +33,7 @@ Here are suggestions on how to perform these tasks:
linear bead-spring polymer chains. The moltemplate program is a true
molecular builder that will generate complex molecular models. See
the :doc:`Tools <Tools>` page for details on tools packaged with
LAMMPS. The `Pre/post processing page <http:/www.lammps.org/prepost.html>`_ of the LAMMPS website
LAMMPS. The `Pre/post processing page <https:/www.lammps.org/prepost.html>`_ of the LAMMPS website
describes a variety of third party tools for this task. Furthermore,
some LAMMPS internal commands allow to reconstruct, or selectively add
topology information, as well as provide the option to insert molecule
@ -80,5 +80,5 @@ Here are suggestions on how to perform these tasks:
`Pizza.py <https://lammps.github.io/pizza>`_ which can do certain kinds of
setup, analysis, plotting, and visualization (via OpenGL) for LAMMPS
simulations. It thus provides some functionality for several of the
above bullets. Pizza.py is written in `Python <http://www.python.org>`_
and is available for download from `this page <http://www.cs.sandia.gov/~sjplimp/download.html>`_.
above bullets. Pizza.py is written in `Python <https://www.python.org>`_
and is available for download from `this page <https://sjplimp.github.io/download.html>`_.

4
doc/src/Intro_opensource.rst
View File

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

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 200 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 144 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 157 KiB

BIN
doc/src/JPG/ovito-peri-snap.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 494 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 160 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.5 MiB

25
doc/src/Library.rst
View File

@ -2,12 +2,13 @@ LAMMPS Library Interfaces
*************************
As described on the :doc:`library interface to LAMMPS <Howto_library>`
page, LAMMPS can be built as a library (static or shared), so that
it can be called by another code, used in a :doc:`coupled manner
page, LAMMPS can be built as a library (static or shared), so that it
can be called by another code, used in a :doc:`coupled manner
<Howto_couple>` with other codes, or driven through a :doc:`Python
script <Python_head>`. Even the LAMMPS standalone executable is
essentially a thin wrapper on top of the LAMMPS library, creating a
LAMMPS instance, processing input and then existing.
script <Python_head>`. The LAMMPS standalone executable itself is
essentially a thin wrapper on top of the LAMMPS library, which creates a
LAMMPS instance, passes the input for processing to that instance, and
then exits.
Most of the APIs described below are based on C language wrapper
functions in the files ``src/library.h`` and ``src/library.cpp``, but
@ -87,6 +88,18 @@ run LAMMPS in serial mode.
message retrieved <lammps_get_last_error_message>`. We thus
recommend enabling C++ exceptions when using the library interface,
.. admonition:: Using the C library interface as a plugin
:class: note
Rather than including the C library directly and link to the LAMMPS
library at compile time, you can use the ``liblammpsplugin.h`` header
file and the ``liblammpsplugin.c`` C code in the
``examples/COUPLE/plugin`` folder for an interface to LAMMPS that is
largely identical to the regular library interface, only that it will
load a LAMMPS shared library file at runtime. This can be useful for
applications where the interface to LAMMPS would be an optional
feature.
.. warning::
No checks are made on the arguments of the function calls of the C
@ -163,5 +176,3 @@ The following links provide some examples and references to the C++ API.
:maxdepth: 1
Cplusplus

6
doc/src/Library_create.rst
View File

@ -11,6 +11,7 @@ This section documents the following functions:
- :cpp:func:`lammps_mpi_finalize`
- :cpp:func:`lammps_kokkos_finalize`
- :cpp:func:`lammps_python_finalize`
- :cpp:func:`lammps_error`
--------------------
@ -115,3 +116,8 @@ calling program.
.. doxygenfunction:: lammps_python_finalize
:project: progguide
-----------------------
.. doxygenfunction:: lammps_error
:project: progguide

8
doc/src/Library_objects.rst
View File

@ -6,6 +6,7 @@ fixes, or variables in LAMMPS using the following functions:
- :cpp:func:`lammps_extract_compute`
- :cpp:func:`lammps_extract_fix`
- :cpp:func:`lammps_extract_variable_datatype`
- :cpp:func:`lammps_extract_variable`
- :cpp:func:`lammps_set_variable`
@ -21,6 +22,11 @@ fixes, or variables in LAMMPS using the following functions:
-----------------------
.. doxygenfunction:: lammps_extract_variable_datatype
:project: progguide
-----------------------
.. doxygenfunction:: lammps_extract_variable
:project: progguide
@ -36,3 +42,5 @@ fixes, or variables in LAMMPS using the following functions:
.. doxygenenum:: _LMP_STYLE_CONST
.. doxygenenum:: _LMP_TYPE_CONST
.. doxygenenum:: _LMP_VAR_CONST

30
doc/src/Library_properties.rst
View File

@ -15,21 +15,21 @@ This section documents the following functions:
--------------------
The library interface allows extraction of different kinds of
information about the active simulation instance and also
modifications to it. This enables combining of a LAMMPS simulation
with other processing and simulation methods computed by the calling
code, or by another code that is coupled to LAMMPS via the library
interface. In some cases the data returned is direct reference to the
original data inside LAMMPS, cast to a void pointer. In that case the
data needs to be cast to a suitable pointer for the calling program to
access it, and you may need to know the correct dimensions and
lengths. This also means you can directly change those value(s) from
the calling program, e.g. to modify atom positions. Of course, this
should be done with care. When accessing per-atom data, please note
that this data is the per-processor **local** data and is indexed
accordingly. Per-atom data can change sizes and ordering at every
neighbor list rebuild or atom sort event as atoms migrate between
The library interface allows the extraction of different kinds of
information about the active simulation instance and also---in some
cases---to apply modifications to it. This enables combining of a
LAMMPS simulation with other processing and simulation methods computed
by the calling code, or by another code that is coupled to LAMMPS via
the library interface. In some cases the data returned is direct
reference to the original data inside LAMMPS, cast to a void pointer.
In that case the data needs to be cast to a suitable pointer for the
calling program to access it, and you may need to know the correct
dimensions and lengths. This also means you can directly change those
value(s) from the calling program (e.g., to modify atom positions). Of
course, changing values should be done with care. When accessing per-atom
data, please note that these data are the per-processor **local** data and are
indexed accordingly. Per-atom data can change sizes and ordering at
every neighbor list rebuild or atom sort event as atoms migrate between
sub-domains and processors.
.. code-block:: C

7
doc/src/Library_utility.rst
View File

@ -19,6 +19,7 @@ functions. They do not directly call the LAMMPS library.
- :cpp:func:`lammps_force_timeout`
- :cpp:func:`lammps_has_error`
- :cpp:func:`lammps_get_last_error_message`
- :cpp:func:`lammps_python_api_version`
The :cpp:func:`lammps_free` function is a clean-up function to free
memory that the library had allocated previously via other function
@ -100,3 +101,9 @@ where such memory buffers were allocated that require the use of
.. doxygenfunction:: lammps_get_last_error_message
:project: progguide
-----------------------
.. doxygenfunction:: lammps_python_api_version
:project: progguide

8
doc/src/Manual.rst
View File

@ -42,19 +42,19 @@ descriptions of all commands included in the LAMMPS code.
.. only:: html
Once you are familiar with LAMMPS, you may want to bookmark
:doc:`this page <Commands_all>` since it gives quick access
:doc:`this page <Commands_all>` since it gives quick access to
the documentation for all LAMMPS commands.
.. _lws: https://www.lammps.org
----------
.. _user_documentation:
************
User Guide
************
.. _user_documentation:
.. toctree::
:maxdepth: 2
:numbered: 3
@ -75,11 +75,12 @@ User Guide
Errors
.. _programmer_documentation:
******************
Programmer Guide
******************
.. _programmer_documentation:
.. toctree::
:maxdepth: 2
:numbered: 3
@ -110,6 +111,7 @@ Command Reference
angles
dihedrals
impropers
dumps
fix_modify_atc_commands
Bibliography

2
doc/src/Modify_fix.rst
View File

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

21
doc/src/Modify_style.rst
View File

@ -100,13 +100,14 @@ Documentation (strict)
Contributions that add new styles or commands or augment existing ones
must include the corresponding new or modified documentation in
`ReStructuredText format <rst>`_ (.rst files in the ``doc/src/`` folder). The
documentation shall be written in American English and the .rst file
must use only ASCII characters so it can be cleanly translated to PDF
files (via `sphinx <sphinx>`_ and PDFLaTeX). Special characters may be included via
embedded math expression typeset in a LaTeX subset.
`ReStructuredText format <rst_>`_ (.rst files in the ``doc/src/``
folder). The documentation shall be written in American English and the
.rst file must use only ASCII characters so it can be cleanly translated
to PDF files (via `sphinx <https://www.sphinx-doc.org>`_ and PDFLaTeX).
Special characters may be included via embedded math expression typeset
in a LaTeX subset.
.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
.. _rst: https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html
When adding new commands, they need to be integrated into the sphinx
documentation system, and the corresponding command tables and lists
@ -133,7 +134,7 @@ error free completion of the HTML and PDF build will be performed and
also a spell check, a check for correct anchors and labels, and a check
for completeness of references all styles in their corresponding tables
and lists is run. In case the spell check reports false positives they
can be added to the file doc/utils/sphinx-config/false_positives.txt
can be added to the file ``doc/utils/sphinx-config/false_positives.txt``
Contributions that add or modify the library interface or "public" APIs
from the C++ code or the Fortran module must include suitable doxygen
@ -358,6 +359,12 @@ you are uncertain, please ask.
- I/O is done via the C-style stdio library and **not** iostreams.
- Do not use so-called "alternative tokens" like ``and``, ``or``,
``not`` and similar, but rather use the corresponding operators
``&&``, ``||``, and ``!``. The alternative tokens are not available
by default on all compilers, and also we want to maintain a consistent
programming style.
- Output to the screen and the logfile should be using the corresponding
FILE pointers and only be done on MPI rank 0. Use the :cpp:func:`utils::logmesg`
convenience function where possible.

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

Binary file not shown.

169
doc/src/Packages_details.rst
View File

@ -27,6 +27,7 @@ page gives those details.
:columns: 6
* :ref:`ADIOS <PKG-ADIOS>`
* :ref:`AMOEBA <PKG-AMOEBA>`
* :ref:`ASPHERE <PKG-ASPHERE>`
* :ref:`ATC <PKG-ATC>`
* :ref:`AWPMD <PKG-AWPMD>`
@ -35,7 +36,7 @@ page gives those details.
* :ref:`BPM <PKG-BPM>`
* :ref:`BROWNIAN <PKG-BROWNIAN>`
* :ref:`CG-DNA <PKG-CG-DNA>`
* :ref:`CG-SDK <PKG-CG-SDK>`
* :ref:`CG-SPICA <PKG-CG-SPICA>`
* :ref:`CLASS2 <PKG-CLASS2>`
* :ref:`COLLOID <PKG-COLLOID>`
* :ref:`COLVARS <PKG-COLVARS>`
@ -133,6 +134,8 @@ commands to write and read data using the ADIOS library.
**Authors:** Norbert Podhorszki (ORNL) from the ADIOS developer team.
.. versionadded:: 28Feb2019
**Install:**
This package has :ref:`specific installation instructions <adios>` on the :doc:`Build extras <Build_extras>` page.
@ -149,6 +152,38 @@ This package has :ref:`specific installation instructions <adios>` on the :doc:`
----------
.. _PKG-AMOEBA:
AMOEBA package
---------------
**Contents:**
Implementation of the AMOEBA and HIPPO polarized force fields
originally developed by Jay Ponder's group at the U Washington at St
Louis. The LAMMPS implementation is based on Fortran 90 code
provided by the Ponder group in their
`Tinker MD software <https://dasher.wustl.edu/tinker/>`_.
**Authors:** Josh Rackers and Steve Plimpton (Sandia), Trung Nguyen (U
Chicago)
**Supporting info:**
* src/AMOEBA: filenames -> commands
* :doc:`AMOEBA and HIPPO howto <Howto_amoeba>`
* :doc:`pair_style amoeba <pair_amoeba>`
* :doc:`pair_style hippo <pair_amoeba>`
* :doc:`atom_style amoeba <atom_style>`
* :doc:`angle_style amoeba <angle_amoeba>`
* :doc:`improper_style amoeba <improper_amoeba>`
* :doc:`fix amoeba/bitorsion <fix_amoeba_bitorsion>`
* :doc:`fix amoeba/pitorsion <fix_amoeba_pitorsion>`
* tools/tinker/tinker2lmp.py
* examples/amoeba
----------
.. _PKG-ASPHERE:
ASPHERE package
@ -165,6 +200,7 @@ 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:`pair_style ylz <pair_ylz>`
* `doc/PDF/pair_gayberne_extra.pdf <PDF/pair_gayberne_extra.pdf>`_
* `doc/PDF/pair_resquared_extra.pdf <PDF/pair_resquared_extra.pdf>`_
* examples/ASPHERE
@ -181,9 +217,10 @@ ATC package
**Contents:**
ATC stands for atoms-to-continuum. This package implements a :doc:`fix atc <fix_atc>` command to either couple molecular dynamics with
continuum finite element equations or perform on-the-fly conversion of
atomic information to continuum fields.
ATC stands for atoms-to-continuum. This package implements a
:doc:`fix atc <fix_atc>` command to either couple molecular dynamics
with continuum finite element equations or perform on-the-fly
conversion of atomic information to continuum fields.
**Authors:** Reese Jones, Jeremy Templeton, Jon Zimmerman (Sandia).
@ -242,7 +279,7 @@ the barostat as outlined in:
N. J. H. Dunn and W. G. Noid, "Bottom-up coarse-grained models that
accurately describe the structure, pressure, and compressibility of
molecular liquids," J. Chem. Phys. 143, 243148 (2015).
molecular liquids", J. Chem. Phys. 143, 243148 (2015).
**Authors:** Nicholas J. H. Dunn and Michael R. DeLyser (The
Pennsylvania State University)
@ -298,6 +335,8 @@ models for mesoscale simulations of solids and fracture. See the
**Authors:** Joel T. Clemmer (Sandia National Labs)
.. versionadded:: 4May2022
**Supporting info:**
* src/BPM filenames -> commands
@ -328,6 +367,8 @@ and also support self-propelled particles.
**Authors:** Sam Cameron (University of Bristol),
Stefan Paquay (while at Brandeis University) (initial version of fix propel/self)
.. versionadded:: 14May2021
Example inputs are in the examples/PACKAGES/brownian folder.
----------
@ -365,28 +406,30 @@ The CG-DNA package requires that also the `MOLECULE <PKG-MOLECULE>`_ and
----------
.. _PKG-CG-SDK:
.. _PKG-CG-SPICA:
CG-SDK package
CG-SPICA package
------------------
**Contents:**
Several pair styles and an angle style which implement the
coarse-grained SDK model of Shinoda, DeVane, and Klein which enables
simulation of ionic liquids, electrolytes, lipids and charged amino
acids.
coarse-grained SPICA (formerly called SDK) model which enables
simulation of biological or soft material systems.
**Author:** Axel Kohlmeyer (Temple U).
**Original Author:** Axel Kohlmeyer (Temple U).
**Maintainers:** Yusuke Miyazaki and Wataru Shinoda (Okayama U).
**Supporting info:**
* src/CG-SDK: filenames -> commands
* src/CG-SDK/README
* :doc:`pair_style lj/sdk/\* <pair_sdk>`
* :doc:`angle_style sdk <angle_sdk>`
* examples/PACKAGES/cgsdk
* src/CG-SPICA: filenames -> commands
* src/CG-SPICA/README
* :doc:`pair_style lj/spica/\* <pair_spica>`
* :doc:`angle_style spica <angle_spica>`
* examples/PACKAGES/cgspica
* https://www.lammps.org/pictures.html#cg
* https://www.spica-ff.org/
----------
@ -554,6 +597,8 @@ To use this package, also the :ref:`KSPACE <PKG-KSPACE>` and
**Author:** Trung Nguyen and Monica Olvera de la Cruz (Northwestern U)
.. versionadded:: 2Jul2021
**Supporting info:**
* src/DIELECTRIC: filenames -> commands
@ -614,7 +659,7 @@ short-range or long-range interactions.
* :doc:`pair_style lj/cut/dipole/cut <pair_dipole>`
* :doc:`pair_style lj/cut/dipole/long <pair_dipole>`
* :doc:`pair_style lj/long/dipole/long <pair_dipole>`
* :doc: `angle_style dipole <angle_dipole>`
* :doc:`angle_style dipole <angle_dipole>`
* examples/dipole
----------
@ -657,7 +702,7 @@ advection-diffusion-reaction systems. The equations of motion of these
DPD extensions are integrated through a modified velocity-Verlet (MVV)
algorithm.
**Author:** Zhen Li (Division of Applied Mathematics, Brown University)
**Author:** Zhen Li (Department of Mechanical Engineering, Clemson University)
**Supporting info:**
@ -824,6 +869,8 @@ groups of atoms that interact with the remaining atoms as electrolyte.
Ahrens-Iwers (TUHH, Hamburg, Germany), Shern Tee (UQ, Brisbane, Australia) and
Robert Meissner (TUHH, Hamburg, Germany).
.. versionadded:: 4May2022
**Install:**
This package has :ref:`specific installation instructions <electrode>` on the
@ -892,6 +939,10 @@ EXTRA-MOLECULE package
Additional bond, angle, dihedral, and improper styles that are less commonly used.
**Install:**
To use this package, also the :ref:`MOLECULE <PKG-MOLECULE>` package needs to be installed.
**Supporting info:**
* src/EXTRA-MOLECULE: filenames -> commands
@ -1027,7 +1078,7 @@ H5MD is a format for molecular simulations, built on top of HDF5.
This package implements a :doc:`dump h5md <dump_h5md>` command to output
LAMMPS snapshots in this format.
.. _HDF5: http://www.hdfgroup.org/HDF5
.. _HDF5: https://www.hdfgroup.org/solutions/hdf5
To use this package you must have the HDF5 library available on your
system.
@ -1364,7 +1415,7 @@ This package has :ref:`specific installation instructions <machdyn>` on the :doc
* src/MACHDYN: filenames -> commands
* src/MACHDYN/README
* doc/PDF/MACHDYN_LAMMPS_userguide.pdf
* `doc/PDF/MACHDYN_LAMMPS_userguide.pdf <PDF/MACHDYN_LAMMPS_userguide.pdf>`_
* examples/PACKAGES/machdyn
* https://www.lammps.org/movies.html#smd
@ -1468,6 +1519,8 @@ workflows via the `MolSSI Driver Interface
**Author:** Taylor Barnes - MolSSI, taylor.a.barnes at gmail.com
.. versionadded:: 14May2021
**Install:**
This package has :ref:`specific installation instructions <mdi>` on
@ -1479,7 +1532,7 @@ the :doc:`Build extras <Build_extras>` page.
* lib/mdi/README
* :doc:`Howto MDI <Howto_mdi>`
* :doc:`mdi <mdi>`
* :doc:`fix mdi/aimd <fix_mdi_aimd>`
* :doc:`fix mdi/qm <fix_mdi_qm>`
* examples/PACKAGES/mdi
----------
@ -1516,33 +1569,44 @@ MESONT package
**Contents:**
MESONT is a LAMMPS package for simulation of nanomechanics of
nanotubes (NTs). The model is based on a coarse-grained representation
of NTs as "flexible cylinders" consisting of a variable number of
MESONT is a LAMMPS package for simulation of nanomechanics of nanotubes
(NTs). The model is based on a coarse-grained representation of NTs as
"flexible cylinders" consisting of a variable number of
segments. Internal interactions within a NT and the van der Waals
interaction between the tubes are described by a mesoscopic force field
designed and parameterized based on the results of atomic-level
molecular dynamics simulations. The description of the force field is
provided in the papers listed below. This package contains two
independent implementations of this model: :doc:`pair_style mesocnt
<pair_mesocnt>` is a (minimal) C++ implementation, and :doc:`pair_style
mesont/tpm <pair_mesont_tpm>` is a more general and feature rich
implementation based on a Fortran library in the ``lib/mesont`` folder.
provided in the papers listed below.
This package contains two independent implementations of this model:
:doc:`pair_style mesont/tpm <pair_mesont_tpm>` is the original
implementation of the model based on a Fortran library in the
``lib/mesont`` folder. The second implementation is provided by the
mesocnt styles (:doc:`bond_style mesocnt <bond_mesocnt>`,
:doc:`angle_style mesocnt <angle_mesocnt>` and :doc:`pair_style mesocnt
<pair_mesocnt>`). The mesocnt implementation has the same features as
the original implementation with the addition of friction, but is
directly implemented in C++, interfaces more cleanly with general LAMMPS
functionality, and is typically faster. It also does not require its own
atom style and can be installed without any external libraries.
**Download of potential files:**
The potential files for these pair styles are *very* large and thus
are not included in the regular downloaded packages of LAMMPS or the
git repositories. Instead, they will be automatically downloaded
from a web server when the package is installed for the first time.
The potential files for these pair styles are *very* large and thus are
not included in the regular downloaded packages of LAMMPS or the git
repositories. Instead, they will be automatically downloaded from a web
server when the package is installed for the first time.
**Authors of the *mesont* styles:**
Maxim V. Shugaev (University of Virginia), Alexey N. Volkov (University of Alabama), Leonid V. Zhigilei (University of Virginia)
Maxim V. Shugaev (University of Virginia), Alexey N. Volkov (University
of Alabama), Leonid V. Zhigilei (University of Virginia)
**Author of the *mesocnt* pair style:**
**Author of the *mesocnt* styles:**
Philipp Kloza (U Cambridge)
.. versionadded:: 15Jun2020
**Supporting info:**
* src/MESONT: filenames -> commands
@ -1550,6 +1614,8 @@ Philipp Kloza (U Cambridge)
* :doc:`atom_style mesont <atom_style>`
* :doc:`pair_style mesont/tpm <pair_mesont_tpm>`
* :doc:`compute mesont <compute_mesont>`
* :doc:`bond_style mesocnt <bond_mesocnt>`
* :doc:`angle_style mesocnt <angle_mesocnt>`
* :doc:`pair_style mesocnt <pair_mesocnt>`
* examples/PACKAGES/mesont
* tools/mesont
@ -1633,6 +1699,8 @@ compiled on your system.
**Author:** Andreas Singraber
.. versionadded:: 27May2021
**Install:**
This package has :ref:`specific installation instructions <ml-hdnnp>` on the
@ -1667,6 +1735,8 @@ must be installed.
**Author:** Aidan Thompson (Sandia), Nicholas Lubbers (LANL).
.. versionadded:: 30Jun2020
**Supporting info:**
* src/ML-IAP: filenames -> commands
@ -1711,6 +1781,8 @@ Aidan Thompson^3, Gabor Csanyi^2, Christoph Ortner^4, Ralf Drautz^1.
^4: University of British Columbia, Vancouver, BC, Canada
.. versionadded:: 14May2021
**Install:**
This package has :ref:`specific installation instructions <ml-pace>` on the
@ -1774,6 +1846,8 @@ of a neural network.
This package was written by Christopher Barrett
with contributions by Doyl Dickel, Mississippi State University.
.. versionadded:: 27May2021
**Supporting info:**
* src/ML-RANN: filenames -> commands
@ -1801,6 +1875,8 @@ computes which analyze attributes of the potential.
* src/ML-SNAP: filenames -> commands
* :doc:`pair_style snap <pair_snap>`
* :doc:`compute sna/atom <compute_sna_atom>`
* :doc:`compute sna/grid <compute_sna_atom>`
* :doc:`compute sna/grid/local <compute_sna_atom>`
* :doc:`compute snad/atom <compute_sna_atom>`
* :doc:`compute snav/atom <compute_sna_atom>`
* examples/snap
@ -1897,7 +1973,7 @@ support for new file formats can be added to LAMMPS (or VMD or other
programs that use them) without having to re-compile the application
itself. More information about the VMD molfile plugins can be found
at
`http://www.ks.uiuc.edu/Research/vmd/plugins/molfile <http://www.ks.uiuc.edu/Research/vmd/plugins/molfile>`_.
`https://www.ks.uiuc.edu/Research/vmd/plugins/molfile <https://www.ks.uiuc.edu/Research/vmd/plugins/molfile>`_.
**Author:** Axel Kohlmeyer (Temple U).
@ -1988,7 +2064,7 @@ NETCDF package
Dump styles for writing NetCDF formatted dump files. NetCDF is a
portable, binary, self-describing file format developed on top of
HDF5. The file contents follow the AMBER NetCDF trajectory conventions
(http://ambermd.org/netcdf/nctraj.xhtml), but include extensions.
(https://ambermd.org/netcdf/nctraj.xhtml), but include extensions.
To use this package you must have the NetCDF library available on your
system.
@ -1999,7 +2075,7 @@ tools:
* `Ovito <ovito_>`_ (Ovito supports the AMBER convention and the extensions mentioned above)
* `VMD <vmd-home_>`_
.. _ovito: http://www.ovito.org
.. _ovito: https://www.ovito.org
.. _vmd-home: https://www.ks.uiuc.edu/Research/vmd/
@ -2143,6 +2219,7 @@ Foster (UTSA).
**Supporting info:**
* src/PERI: filenames -> commands
* :doc:`Peridynamics Howto <Howto_peri>`
* `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>`_
@ -2207,6 +2284,8 @@ try to load the contained plugins automatically at start-up.
**Authors:** Axel Kohlmeyer (Temple U)
.. versionadded:: 8Apr2021
**Supporting info:**
* src/PLUGIN: filenames -> commands
@ -2360,7 +2439,7 @@ A :doc:`fix qmmm <fix_qmmm>` command which allows LAMMPS to be used as
the MM code in a QM/MM simulation. This is currently only available
in combination with the `Quantum ESPRESSO <espresso_>`_ package.
.. _espresso: http://www.quantum-espresso.org
.. _espresso: https://www.quantum-espresso.org
To use this package you must have Quantum ESPRESSO (QE) available on
your system and include its coupling library in the compilation and
@ -2650,7 +2729,7 @@ Dynamics, Ernst Mach Institute, Germany).
* src/SPH: filenames -> commands
* src/SPH/README
* doc/PDF/SPH_LAMMPS_userguide.pdf
* `doc/PDF/SPH_LAMMPS_userguide.pdf <PDF/SPH_LAMMPS_userguide.pdf>`_
* examples/PACKAGES/sph
* https://www.lammps.org/movies.html#sph
@ -2772,7 +2851,7 @@ collection of atoms by wrapping the `Voro++ library <voro-home_>`_. This
can be used to calculate the local volume or each atoms or its near
neighbors.
.. _voro-home: http://math.lbl.gov/voro++
.. _voro-home: https://math.lbl.gov/voro++
To use this package you must have the Voro++ library available on your
system.
@ -2806,9 +2885,9 @@ A :doc:`dump vtk <dump_vtk>` command which outputs snapshot info in the
`VTK format <vtk_>`_, enabling visualization by `Paraview <paraview_>`_ or
other visualization packages.
.. _vtk: http://www.vtk.org
.. _vtk: https://www.vtk.org
.. _paraview: http://www.paraview.org
.. _paraview: https://www.paraview.org
To use this package you must have VTK library available on your
system.
@ -2845,11 +2924,13 @@ which discuss the `QuickFF <quickff_>`_ methodology.
.. _vanduyfhuys2015: https://doi.org/10.1002/jcc.23877
.. _vanduyfhuys2018: https://doi.org/10.1002/jcc.25173
.. _quickff: http://molmod.github.io/QuickFF
.. _quickff: https://molmod.github.io/QuickFF
.. _yaff: https://github.com/molmod/yaff
**Author:** Steven Vandenbrande.
.. versionadded:: 1Feb2019
**Supporting info:**
* src/YAFF/README

13
doc/src/Packages_list.rst
View File

@ -33,6 +33,11 @@ whether an extra library is needed to build and use the package:
- :doc:`dump adios <dump_adios>`
- PACKAGES/adios
- ext
* - :ref:`AMOEBA <PKG-AMOEBA>`
- AMOEBA and HIPPO force fields
- :doc:`AMOEBA and HIPPO howto <Howto_amoeba>`
- amoeba
- no
* - :ref:`ASPHERE <PKG-ASPHERE>`
- aspherical particle models
- :doc:`Howto spherical <Howto_spherical>`
@ -73,10 +78,10 @@ whether an extra library is needed to build and use the package:
- src/CG-DNA/README
- PACKAGES/cgdna
- no
* - :ref:`CG-SDK <PKG-CG-SDK>`
- SDK coarse-graining model
- :doc:`pair_style lj/sdk <pair_sdk>`
- PACKAGES/cgsdk
* - :ref:`CG-SPICA <PKG-CG-SPICA>`
- SPICA (SDK) coarse-graining model
- :doc:`pair_style lj/spica <pair_spica>`
- PACKAGES/cgspica
- no
* - :ref:`CLASS2 <PKG-CLASS2>`
- class 2 force fields

20
doc/src/Python_examples.rst
View File

@ -43,26 +43,18 @@ Note that for AtomEye, you need version 3, and there is a line in the
scripts that specifies the path and name of the executable. See the
AtomEye web pages for more details:
* `http://li.mit.edu/Archive/Graphics/A/ <atomeye_>`_
* `http://li.mit.edu/Archive/Graphics/A3/A3.html <atomeye3_>`_
* `http://li.mit.edu/Archive/Graphics/A/ <http://li.mit.edu/Archive/Graphics/A/>`_
* `http://li.mit.edu/Archive/Graphics/A3/A3.html <http://li.mit.edu/Archive/Graphics/A3/A3.html>`_
.. _atomeye: http://li.mit.edu/Archive/Graphics/A/
.. _atomeye3: http://li.mit.edu/Archive/Graphics/A3/A3.html
The latter link is to AtomEye 3 which has the scripting
capability needed by these Python scripts.
The latter link is to AtomEye 3 which has the scripting capability
needed by these Python scripts.
Note that for PyMol, you need to have built and installed the
open-source version of PyMol in your Python, so that you can import it
from a Python script. See the PyMol web pages for more details:
* `https://www.pymol.org <pymolhome_>`_
* `https://github.com/schrodinger/pymol-open-source <pymolopen_>`_
.. _pymolhome: https://www.pymol.org
.. _pymolopen: https://github.com/schrodinger/pymol-open-source
* `https://www.pymol.org <https://www.pymol.org>`_
* `https://github.com/schrodinger/pymol-open-source <https://github.com/schrodinger/pymol-open-source>`_
The latter link is to the open-source version.

10
doc/src/Python_head.rst
View File

@ -18,17 +18,17 @@ together.
Python_error
Python_trouble
If you are not familiar with `Python <http://www.python.org>`_, it is a
If you are not familiar with `Python <https://www.python.org>`_, it is a
powerful scripting and programming language which can do almost
everything that compiled languages like C, C++, or Fortran can do in
fewer lines of code. It also comes with a large collection of add-on
modules for many purposes (either bundled or easily installed from
Python code repositories). The major drawback is slower execution speed
of the script code compared to compiled programming languages. But when
the script code is interfaced to optimized compiled code, performance can
be on par with a standalone executable, for as long as the scripting is
restricted to high-level operations. Thus Python is also convenient to
use as a "glue" language to "drive" a program through its library
the script code is interfaced to optimized compiled code, performance
can be on par with a standalone executable, for as long as the scripting
is restricted to high-level operations. Thus Python is also convenient
to use as a "glue" language to "drive" a program through its library
interface, or to hook multiple pieces of software together, such as a
simulation code and a visualization tool, or to run a coupled
multi-scale or multi-physics model.

34
doc/src/Python_neighbor.rst
View File

@ -38,6 +38,40 @@ using the NumPy access method.
for n in np.nditer(nlist):
print(" atom {} with ID {}".format(n,tags[n]))
Another example for extracting a full neighbor list without evaluating a
potential is shown below.
.. code-block:: python
from lammps import lammps
import numpy as np
lmp = lammps()
lmp.commands_string("""
newton off
region box block -2 2 -2 2 -2 2
lattice fcc 1.0
create_box 1 box
create_atoms 1 box
mass 1 1.0
pair_style zero 1.0 full
pair_coeff * *
run 0 post no""")
# look up the neighbor list
nlidx = lmp.find_pair_neighlist('zero')
nl = lmp.numpy.get_neighlist(nlidx)
tags = lmp.extract_atom('id')
print("full neighbor list with {} entries".format(nl.size))
# print neighbor list contents
for i in range(0,nl.size):
idx, nlist = nl.get(i)
print("\natom {} with ID {} has {} neighbors:".format(idx,tags[idx],nlist.size))
if nlist.size > 0:
for n in np.nditer(nlist):
pass
print(" atom {} with ID {}".format(n,tags[n]))
**Methods:**
* :py:meth:`lammps.get_neighlist() <lammps.lammps.get_neighlist()>`: Get neighbor list for given index

9
doc/src/Run_basics.rst
View File

@ -30,12 +30,13 @@ executable itself can be placed elsewhere.
.. note::
The redirection operator "<" will not always work when running
in parallel with mpirun or mpiexec; for those systems the -in form is required.
The redirection operator "<" will not always work when running in
parallel with ``mpirun`` or ``mpiexec``; for those systems the -in
form is required.
As LAMMPS runs it prints info to the screen and a logfile named
*log.lammps*\ . More info about output is given on the
:doc:`screen and logfile output <Run_output>` page.
*log.lammps*\ . More info about output is given on the :doc:`screen and
logfile output <Run_output>` page.
If LAMMPS encounters errors in the input script or while running a
simulation it will print an ERROR message and stop or a WARNING

41
doc/src/Run_options.rst
View File

@ -14,6 +14,7 @@ letter abbreviation can be used:
* :ref:`-m or -mpicolor <mpicolor>`
* :ref:`-c or -cite <cite>`
* :ref:`-nc or -nocite <nocite>`
* :ref:`-nb or -nonbuf <nonbuf>`
* :ref:`-pk or -package <package>`
* :ref:`-p or -partition <partition>`
* :ref:`-pl or -plog <plog>`
@ -92,13 +93,13 @@ switch is not set (the default), LAMMPS will operate as if the KOKKOS
package were not installed; i.e. you can run standard LAMMPS or with
the GPU or OPENMP packages, for testing or benchmarking purposes.
Additional optional keyword/value pairs can be specified which
determine how Kokkos will use the underlying hardware on your
platform. These settings apply to each MPI task you launch via the
"mpirun" or "mpiexec" command. You may choose to run one or more MPI
tasks per physical node. Note that if you are running on a desktop
machine, you typically have one physical node. On a cluster or
supercomputer there may be dozens or 1000s of physical nodes.
Additional optional keyword/value pairs can be specified which determine
how Kokkos will use the underlying hardware on your platform. These
settings apply to each MPI task you launch via the ``mpirun`` or
``mpiexec`` command. You may choose to run one or more MPI tasks per
physical node. Note that if you are running on a desktop machine, you
typically have one physical node. On a cluster or supercomputer there
may be dozens or 1000s of physical nodes.
Either the full word or an abbreviation can be used for the keywords.
Note that the keywords do not use a leading minus sign. I.e. the
@ -147,9 +148,9 @@ one of these 4 environment variables
MV2_COMM_WORLD_LOCAL_RANK (Mvapich)
OMPI_COMM_WORLD_LOCAL_RANK (OpenMPI)
which are initialized by the "srun", "mpirun" or "mpiexec" commands.
The environment variable setting for each MPI rank is used to assign a
unique GPU ID to the MPI task.
which are initialized by the ``srun``, ``mpirun``, or ``mpiexec``
commands. The environment variable setting for each MPI rank is used to
assign a unique GPU ID to the MPI task.
.. parsed-literal::
@ -257,6 +258,24 @@ Disable generating a citation reminder (see above) at all.
----------
.. _nonbuf:
**-nonbuf**
Turn off buffering for screen and logfile output. For performance
reasons, output to the screen and logfile is usually buffered, i.e.
output is only written to a file if its buffer - typically 4096 bytes -
has been filled. When LAMMPS crashes for some reason, however, that can
mean that there is important output missing. With this flag the
buffering can be turned off (only for screen and logfile output) and any
output will be committed immediately. Note that when running in
parallel with MPI, the screen output may still be buffered by the MPI
library and this cannot be changed by LAMMPS. This flag should only be
used for debugging and not for production simulations as the performance
impact can be significant, especially for large parallel runs.
----------
.. _package:
**-package style args ....**
@ -476,7 +495,7 @@ run:
write_dump group-ID dumpstyle dumpfile arg1 arg2 ...
Note that the specified restartfile and dumpfile names may contain
wild-card characters ("\*","%") as explained on the
wild-card characters ("\*" or "%") as explained on the
:doc:`read_restart <read_restart>` and :doc:`write_dump <write_dump>` doc
pages. The use of "%" means that a parallel restart file and/or
parallel dump file can be read and/or written. Note that a filename

59
doc/src/Run_output.rst
View File

@ -16,46 +16,47 @@ simulation. An example set of statistics is shown here:
.. parsed-literal::
Loop time of 2.81192 on 4 procs for 300 steps with 2004 atoms
Loop time of 0.942801 on 4 procs for 300 steps with 2004 atoms
Performance: 18.436 ns/day 1.302 hours/ns 106.689 timesteps/s
97.0% CPU use with 4 MPI tasks x no OpenMP threads
Performance: 54.985 ns/day, 0.436 hours/ns, 318.201 timesteps/s, 637.674 katom-step/s
195.2% CPU use with 2 MPI tasks x 2 OpenMP threads
MPI task timings breakdown:
MPI task timing breakdown:
Section \| min time \| avg time \| max time \|%varavg\| %total
---------------------------------------------------------------
Pair \| 1.9808 \| 2.0134 \| 2.0318 \| 1.4 \| 71.60
Bond \| 0.0021894 \| 0.0060319 \| 0.010058 \| 4.7 \| 0.21
Kspace \| 0.3207 \| 0.3366 \| 0.36616 \| 3.1 \| 11.97
Neigh \| 0.28411 \| 0.28464 \| 0.28516 \| 0.1 \| 10.12
Comm \| 0.075732 \| 0.077018 \| 0.07883 \| 0.4 \| 2.74
Output \| 0.00030518 \| 0.00042665 \| 0.00078821 \| 1.0 \| 0.02
Modify \| 0.086606 \| 0.086631 \| 0.086668 \| 0.0 \| 3.08
Other \| \| 0.007178 \| \| \| 0.26
Pair \| 0.61419 \| 0.62872 \| 0.64325 \| 1.8 \| 66.69
Bond \| 0.0028608 \| 0.0028899 \| 0.002919 \| 0.1 \| 0.31
Kspace \| 0.12652 \| 0.14048 \| 0.15444 \| 3.7 \| 14.90
Neigh \| 0.10242 \| 0.10242 \| 0.10242 \| 0.0 \| 10.86
Comm \| 0.026753 \| 0.027593 \| 0.028434 \| 0.5 \| 2.93
Output \| 0.00018341 \| 0.00030942 \| 0.00043542 \| 0.0 \| 0.03
Modify \| 0.039117 \| 0.039348 \| 0.039579 \| 0.1 \| 4.17
Other \| \| 0.001041 \| \| \| 0.11
Nlocal: 501 ave 508 max 490 min
Histogram: 1 0 0 0 0 0 1 1 0 1
Nghost: 6586.25 ave 6628 max 6548 min
Histogram: 1 0 1 0 0 0 1 0 0 1
Neighs: 177007 ave 180562 max 170212 min
Histogram: 1 0 0 0 0 0 0 1 1 1
Nlocal: 1002 ave 1006 max 998 min
Histogram: 1 0 0 0 0 0 0 0 0 1
Nghost: 8670.5 ave 8691 max 8650 min
Histogram: 1 0 0 0 0 0 0 0 0 1
Neighs: 354010 ave 357257 max 350763 min
Histogram: 1 0 0 0 0 0 0 0 0 1
Total # of neighbors = 708028
Ave neighs/atom = 353.307
Ave special neighs/atom = 2.34032
Total # of neighbors = 708020
Ave neighs/atom = 353.30339
Ave special neighs/atom = 2.3403194
Neighbor list builds = 26
Dangerous builds = 0
----------
The first section provides a global loop timing summary. The *loop
time* is the total wall-clock time for the simulation to run. The
*Performance* line is provided for convenience to help predict how
long it will take to run a desired physical simulation. The *CPU use*
line provides the CPU utilization per MPI task; it should be close to
100% times the number of OpenMP threads (or 1 of not using OpenMP).
Lower numbers correspond to delays due to file I/O or insufficient
thread utilization.
The first section provides a global loop timing summary. The *loop time*
is the total wall-clock time for the simulation to run. The
*Performance* line is provided for convenience to help predict how long
it will take to run a desired physical simulation and to have numbers
useful for performance comparison between different simulation settings
or system sizes. The *CPU use* line provides the CPU utilization per
MPI task; it should be close to 100% times the number of OpenMP threads
(or 1 of not using OpenMP). Lower numbers correspond to delays due to
file I/O or insufficient thread utilization.
----------

4
doc/src/Run_windows.rst
View File

@ -25,8 +25,8 @@ in parallel, follow these steps.
Download and install a compatible MPI library binary package:
* for 32-bit Windows: `mpich2-1.4.1p1-win-ia32.msi <http://download.lammps.org/thirdparty/mpich2-1.4.1p1-win-ia32.msi>`_
* for 64-bit Windows: `mpich2-1.4.1p1-win-x86-64.msi <http://download.lammps.org/thirdparty/mpich2-1.4.1p1-win-x86-64.msi>`_
* for 32-bit Windows: `mpich2-1.4.1p1-win-ia32.msi <https://download.lammps.org/thirdparty/mpich2-1.4.1p1-win-ia32.msi>`_
* for 64-bit Windows: `mpich2-1.4.1p1-win-x86-64.msi <https://download.lammps.org/thirdparty/mpich2-1.4.1p1-win-x86-64.msi>`_
The LAMMPS Windows installer packages will automatically adjust your
path for the default location of this MPI package. After the

15
doc/src/Speed_gpu.rst
View File

@ -39,7 +39,7 @@ toolkit software on your system (this is only tested on Linux
and 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 https://developer.nvidia.com/cuda-downloads
* 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
list supported devices and properties
@ -76,10 +76,11 @@ instructions.
**Run with the GPU package from the command line:**
The mpirun or mpiexec command sets the total number of MPI tasks used
by LAMMPS (one or multiple per compute node) and the number of MPI
tasks used per node. E.g. the mpirun command in MPICH does this via
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.
The ``mpirun`` or ``mpiexec`` command sets the total number of MPI tasks
used by LAMMPS (one or multiple per compute node) and the number of MPI
tasks used per node. E.g. the ``mpirun`` command in MPICH does this via
its ``-np`` and ``-ppn`` switches. Ditto for OpenMPI via ``-np`` and
``-npernode``.
When using the GPU package, you cannot assign more than one GPU to a
single MPI task. However multiple MPI tasks can share the same GPU,
@ -129,8 +130,8 @@ GPU package pair styles.
**Or run with the GPU package by editing an input script:**
The discussion above for the mpirun/mpiexec command, MPI tasks/node,
and use of multiple MPI tasks/GPU is the same.
The discussion above for the ``mpirun`` or ``mpiexec`` command, MPI
tasks/node, 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.

4
doc/src/Speed_intel.rst
View File

@ -536,6 +536,6 @@ supported.
References
""""""""""
* Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakkar, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., "Optimizing Classical Molecular Dynamics in LAMMPS," in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann.
* Brown, W. M., Semin, A., Hebenstreit, M., Khvostov, S., Raman, K., Plimpton, S.J. `Increasing Molecular Dynamics Simulation Rates with an 8-Fold Increase in Electrical Power Efficiency. <http://dl.acm.org/citation.cfm?id=3014915>`_ 2016 High Performance Computing, Networking, Storage and Analysis, SC16: International Conference (pp. 82-95).
* Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakkar, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., "Optimizing Classical Molecular Dynamics in LAMMPS", in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann.
* Brown, W. M., Semin, A., Hebenstreit, M., Khvostov, S., Raman, K., Plimpton, S.J. `Increasing Molecular Dynamics Simulation Rates with an 8-Fold Increase in Electrical Power Efficiency. <https://dl.acm.org/citation.cfm?id=3014915>`_ 2016 High Performance Computing, Networking, Storage and Analysis, SC16: International Conference (pp. 82-95).
* Brown, W.M., Carrillo, J.-M.Y., Gavhane, N., Thakkar, F.M., Plimpton, S.J. Optimizing Legacy Molecular Dynamics Software with Directive-Based Offload. Computer Physics Communications. 2015. 195: p. 95-101.

17
doc/src/Speed_kokkos.rst
View File

@ -72,12 +72,12 @@ See the :ref:`Build extras <kokkos>` page for instructions.
Running LAMMPS with the KOKKOS package
""""""""""""""""""""""""""""""""""""""
All Kokkos operations occur within the context of an individual MPI
task running on a single node of the machine. The total number of MPI
tasks used by LAMMPS (one or multiple per compute node) is set in the
usual manner via the mpirun or mpiexec commands, and is independent of
Kokkos. E.g. the mpirun command in OpenMPI does this via its -np and
-npernode switches. Ditto for MPICH via -np and -ppn.
All Kokkos operations occur within the context of an individual MPI task
running on a single node of the machine. The total number of MPI tasks
used by LAMMPS (one or multiple per compute node) is set in the usual
manner via the ``mpirun`` or ``mpiexec`` commands, and is independent of
Kokkos. E.g. the mpirun command in OpenMPI does this via its ``-np`` and
``-npernode`` switches. Ditto for MPICH via ``-np`` and ``-ppn``.
Running on a multi-core CPU
^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -168,7 +168,7 @@ for your MPI installation), binding can be forced with these flags:
.. parsed-literal::
OpenMPI 1.8: mpirun -np 2 --bind-to socket --map-by socket ./lmp_openmpi ...
OpenMPI 1.8: mpirun -np 2 --bind-to socket --map-by socket ./lmp_openmpi ...
Mvapich2 2.0: mpiexec -np 2 --bind-to socket --map-by socket ./lmp_mvapich ...
For binding threads with KOKKOS OpenMP, use thread affinity environment
@ -310,7 +310,8 @@ Alternatively the effect of the "-sf" or "-pk" switches can be
duplicated by adding the :doc:`package kokkos <package>` or :doc:`suffix kk <suffix>` commands to your input script.
The discussion above for building LAMMPS with the KOKKOS package, the
mpirun/mpiexec command, and setting appropriate thread are the same.
``mpirun`` or ``mpiexec`` command, and setting appropriate thread
properties are the same.
You must still use the "-k on" :doc:`command-line switch <Run_options>`
to enable the KOKKOS package, and specify its additional arguments for

3
doc/src/Speed_measure.rst
View File

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

10
doc/src/Speed_omp.rst
View File

@ -33,8 +33,8 @@ These examples assume one or more 16-core nodes.
mpirun -np 4 lmp_omp -sf omp -pk omp 4 -in in.script # 4 MPI tasks, 4 threads/task
mpirun -np 32 -ppn 4 lmp_omp -sf omp -pk omp 4 -in in.script # 8 nodes, 4 MPI tasks/node, 4 threads/task
The mpirun or mpiexec command sets the total number of MPI tasks used
by LAMMPS (one or multiple per compute node) and the number of MPI
The ``mpirun`` or ``mpiexec`` command sets the total number of MPI tasks
used by LAMMPS (one or multiple per compute node) and the number of MPI
tasks used per node. E.g. the mpirun command in MPICH does this via
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.
@ -58,8 +58,8 @@ OMP_NUM_THREADS environment variable.
Or run with the OPENMP package by editing an input script
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
The discussion above for the mpirun/mpiexec command, MPI tasks/node,
and threads/MPI task is the same.
The discussion above for the ``mpirun`` or ``mpiexec`` command, MPI
tasks/node, 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.
@ -97,7 +97,7 @@ sub-section.
A description of the multi-threading strategy used in the OPENMP
package and some performance examples are
`presented here <http://sites.google.com/site/akohlmey/software/lammps-icms/lammps-icms-tms2011-talk.pdf?attredirects=0&d=1>`_.
`presented here <https://drive.google.com/file/d/1d1gLK6Ru6aPYB50Ld2tO10Li8zgPVNB8/view?usp=sharing>`_.
Guidelines for best performance
"""""""""""""""""""""""""""""""

24
doc/src/Speed_packages.rst
View File

@ -117,33 +117,15 @@ script.
with all its accelerator packages installed. Note however that the
INTEL and KOKKOS packages require you to choose one of their
hardware options when building for a specific platform. I.e. CPU or
Phi option for the INTEL package. Or the OpenMP, Cuda, or Phi
option for the KOKKOS package.
Phi option for the INTEL package. Or the OpenMP, CUDA, HIP, SYCL,
or Phi option for the KOKKOS package. Or the OpenCL, HIP, or CUDA
option for the GPU package.
These are the exceptions. You cannot build a single executable with:
* both the INTEL Phi and KOKKOS Phi options
* the INTEL Phi or Kokkos Phi option, and the GPU package
See the examples/accelerate/README and make.list files for sample
Make.py commands that build LAMMPS with any or all of the accelerator
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:
.. 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
The examples/accelerate directory also has input scripts that can be
used with all of the accelerator packages. See its README file for
details.
Likewise, the bench directory has FERMI and KEPLER and PHI
sub-directories with Make.py commands and input scripts for using all
the accelerator packages on various machines. See the README files in
those directories.
As mentioned above, the `Benchmark page <https://www.lammps.org/bench.html>`_ of the LAMMPS website gives
performance results for the various accelerator packages for several
of the standard LAMMPS benchmark problems, as a function of problem

30
doc/src/Tools.rst
View File

@ -95,7 +95,7 @@ Miscellaneous tools
* :ref:`LAMMPS shell <lammps_shell>`
* :ref:`LAMMPS magic patterns for file(1) <magic>`
* :ref:`Offline build tool <offline>`
* :ref:`singularity <singularity_tool>`
* :ref:`singularity/apptainer <singularity_tool>`
* :ref:`SWIG interface <swig>`
* :ref:`vim <vim>`
@ -205,6 +205,7 @@ scripts are available:
whitespace.py # detects TAB characters and trailing whitespace
homepage.py # detects outdated LAMMPS homepage URLs (pointing to sandia.gov instead of lammps.org)
errordocs.py # detects deprecated error docs in header files
versiontags.py # detects .. versionadded:: or .. versionchanged:: with pending version date
The tools need to be given the main folder of the LAMMPS distribution
or individual file names as argument and will by default check them
@ -397,7 +398,7 @@ ipp tool
------------------
The tools/ipp directory contains a Perl script ipp which can be used
to facilitate the creation of a complicated file (say, a lammps input
to facilitate the creation of a complicated file (say, a LAMMPS input
script or tools/createatoms input file) using a template file.
ipp was created and is maintained by Reese Jones (Sandia), rjones at
@ -512,8 +513,8 @@ with an ``.inputrc`` file in the home directory. For application
specific customization, the LAMMPS shell uses the name "lammps-shell".
For more information about using and customizing an application using
readline, please see the available documentation at:
`http://www.gnu.org/s/readline/#Documentation
<http://www.gnu.org/s/readline/#Documentation>`_
https://www.gnu.org/software/readline/
Additional commands
^^^^^^^^^^^^^^^^^^^
@ -715,7 +716,7 @@ See the README.pdf file for more information.
These scripts were written by Arun Subramaniyan at Purdue Univ
(asubrama at purdue.edu).
.. _matlabhome: http://www.mathworks.com
.. _matlabhome: https://www.mathworks.com
----------
@ -1007,14 +1008,15 @@ Ivanov, at University of Iceland (ali5 at hi.is).
.. _singularity_tool:
singularity tool
----------------------------------------
singularity/apptainer tool
--------------------------
The singularity sub-directory contains container definitions files
that can be used to build container images for building and testing
LAMMPS on specific OS variants using the `Singularity <https://sylabs.io>`_
container software. Contributions for additional variants are welcome.
For more details please see the README.md file in that folder.
The singularity sub-directory contains container definitions files that
can be used to build container images for building and testing LAMMPS on
specific OS variants using the `Apptainer <https://apptainer.org>`_ or
`Singularity <https://sylabs.io>`_ container software. Contributions for
additional variants are welcome. For more details please see the
README.md file in that folder.
----------
@ -1045,7 +1047,7 @@ the binary file. This usually is a so-called little endian hardware
SWIG interface
--------------
The `SWIG tool <http://swig.org>`_ offers a mostly automated way to
The `SWIG tool <https://swig.org>`_ offers a mostly automated way to
incorporate compiled code modules into scripting languages. It
processes the function prototypes in C and generates wrappers for a wide
variety of scripting languages from it. Thus it can also be applied to
@ -1125,7 +1127,7 @@ data passed or returned as pointers are included in the ``lammps.i``
file. So most of the functionality of the library interface should be
accessible. What works and what does not depends a bit on the
individual language for which the wrappers are built and how well SWIG
supports those. The `SWIG documentation <http://swig.org/doc.html>`_
supports those. The `SWIG documentation <https://swig.org/doc.html>`_
has very detailed instructions and recommendations.
Usage examples

2
doc/src/accel_styles.rst
View File

@ -6,7 +6,7 @@ page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, INTEL, KOKKOS,
OPENMP and OPT packages, respectively. They are only enabled if
OPENMP, and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` page for more info.
You can specify the accelerated styles explicitly in your input script

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

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

2
doc/src/angle_class2.rst
View File

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

50
doc/src/angle_coeff.rst
View File

@ -10,7 +10,7 @@ Syntax
angle_coeff N args
* N = angle type (see asterisk form below)
* N = numeric angle type (see asterisk form below), or type label
* args = coefficients for one or more angle types
Examples
@ -22,6 +22,9 @@ Examples
angle_coeff * 5.0
angle_coeff 2*10 5.0
labelmap angle 1 hydroxyl
angle_coeff hydroxyl 300.0 107.0
Description
"""""""""""
@ -30,18 +33,24 @@ The number and meaning of the coefficients depends on the angle style.
Angle coefficients can also be set in the data file read by the
:doc:`read_data <read_data>` command or in a restart file.
N can be specified in one of two ways. An explicit numeric value can
be used, as in the first example above. Or a wild-card asterisk can be
used to set the coefficients for multiple angle types. This takes the
form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of angle types,
then an asterisk with no numeric values means all types from 1 to N. A
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).
:math:`N` can be specified in one of two ways. An explicit numeric
value can be used, as in the first example above. Or :math:`N` can be a
type label, which is an alphanumeric string defined by the
:doc:`labelmap <labelmap>` command or in a section of a data file read
by the :doc:`read_data <read_data>` command.
Note that using an :doc:`angle_coeff <angle_coeff>` command can override a previous setting
for the same angle type. For example, these commands set the coeffs
for all angle types, then overwrite the coeffs for just angle type 2:
For numeric values only, a wild-card asterisk can be used to set the
coefficients for multiple angle types. This takes the form "\*" or
"\*n" or "n\*" or "m\*n". If :math:`N` is the number of angle types,
then an asterisk with no numeric values means all types from 1 to
:math:`N`. A leading asterisk means all types from 1 to n (inclusive).
A trailing asterisk means all types from n to :math:`N` (inclusive). A
middle asterisk means all types from m to n (inclusive).
Note that using an :doc:`angle_coeff <angle_coeff>` command can
override a previous setting for the same angle type. For example,
these commands set the coeffs for all angle types, then overwrite the
coeffs for just angle type 2:
.. code-block:: LAMMPS
@ -49,11 +58,11 @@ for all angle types, then overwrite the coeffs for just angle type 2:
angle_coeff 2 50.0 107.0
A line in a data file that specifies angle coefficients uses the exact
same format as the arguments of the :doc:`angle_coeff <angle_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 "Angle Coeffs" section of a data file, the line that
corresponds to the first example above would be listed as
same format as the arguments of the :doc:`angle_coeff <angle_coeff>`
command in an input script, except that wild-card asterisks should not
be used since coefficients for all :math:`N` types must be listed in the
file. For example, under the "Angle Coeffs" section of a data file, the
line that corresponds to the first example above would be listed as
.. parsed-literal::
@ -61,15 +70,14 @@ corresponds to the first example above would be listed as
The :doc:`angle_style class2 <angle_class2>` is an exception to this
rule, in that an additional argument is used in the input script to
allow specification of the cross-term coefficients. See its
doc page for details.
allow specification of the cross-term coefficients. See its doc page
for details.
----------
The list of all angle styles defined in LAMMPS is given on the
:doc:`angle_style <angle_style>` doc page. They are also listed in more
compact form on the :ref:`Commands angle <angle>` doc
page.
compact form on the :ref:`Commands angle <angle>` 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

146
doc/src/angle_mesocnt.rst Normal file
View File

@ -0,0 +1,146 @@
.. index:: angle_style mesocnt
angle_style mesocnt command
===========================
Syntax
""""""
.. code-block:: LAMMPS
angle_style mesocnt
Examples
""""""""
.. code-block:: LAMMPS
angle_style mesocnt
angle_coeff 1 buckling C 10 10 20.0
angle_coeff 4 harmonic C 8 4 10.0
angle_coeff 2 buckling custom 400.0 50.0 5.0
angle_coeff 1 harmonic custom 300.0
Description
"""""""""""
.. versionadded:: 15Sep2022
The *mesocnt* angle style uses the potential
.. math::
E = K_\text{H} \Delta \theta^2, \qquad |\Delta \theta| < \Delta
\theta_\text{B} \\
E = K_\text{H} \Delta \theta_\text{B}^2 +
K_\text{B} (\Delta \theta - \Delta \theta_\text{B}), \qquad |\Delta
\theta| \geq \Delta \theta_\text{B}
where :math:`\Delta \theta = \theta - \pi` is the bending angle of the
nanotube, :math:`K_\text{H}` and :math:`K_\text{B}` are prefactors for
the harmonic and linear regime respectively and :math:`\Delta
\theta_\text{B}` is the buckling angle. Note that the usual 1/2 factor
for the harmonic potential is included in :math:`K_\text{H}`.
The style implements parameterization presets of :math:`K_\text{H}`,
:math:`K_\text{B}` and :math:`\Delta \theta_\text{B}` for mesoscopic
simulations of carbon nanotubes based on the atomistic simulations of
:ref:`(Srivastava) <Srivastava_2>` and buckling considerations of
:ref:`(Zhigilei) <Zhigilei1_1>`.
The following coefficients must be defined for each angle type via the
:doc:`angle_coeff <angle_coeff>` command as in the examples above, or
in the data file or restart files read by the :doc:`read_data
<read_data>` or :doc:`read_restart <read_restart>` commands:
* mode = *buckling* or *harmonic*
* preset = *C* or *custom*
* additional parameters depending on preset
If mode *harmonic* is chosen, the potential is simply harmonic and
does not switch to the linear term when the buckling angle is
reached. In *buckling* mode, the full piecewise potential is used.
Preset *C* is for carbon nanotubes, and the additional parameters are:
* chiral index :math:`n` (unitless)
* chiral index :math:`m` (unitless)
* :math:`r_0` (distance)
Here, :math:`r_0` is the equilibrium distance of the bonds included in
the angle, see :doc:`bond_style mesocnt <bond_mesocnt>`.
In harmonic mode with preset *custom*, the additional parameter is:
* :math:`K_\text{H}` (energy)
Hence, this setting is simply a wrapper for :doc:`bond_style harmonic
<bond_harmonic>` with an equilibrium angle of 180 degrees.
In harmonic mode with preset *custom*, the additional parameters are:
* :math:`K_\text{H}` (energy)
* :math:`K_\text{B}` (energy)
* :math:`\Delta \theta_\text{B}` (degrees)
:math:`\Delta \theta_\text{B}` is specified in degrees, but LAMMPS
converts it to radians internally; hence :math:`K_\text{H}` is
effectively energy per radian\^2 and :math:`K_\text{B}` is energy per
radian.
----------
In *buckling* mode, this angle style adds the *buckled* property to
all atoms in the simulation, which is an integer flag indicating
whether the bending angle at a given atom has exceeded :math:`\Delta
\theta_\text{B}`. It can be accessed as an atomic variable, e.g. for
custom dump commands, as *i_buckled*.
.. note::
If the initial state of the simulation contains buckled nanotubes
and :doc:`pair_style mesocnt <pair_mesocnt>` is used, the
*i_buckled* atomic variable needs to be initialized before the
pair_style is defined by doing a *run 0* command straight after the
angle_style command. See below for an example.
If CNTs are already buckled at the start of the simulation, this
script will correctly initialize *i_buckled*:
.. code-block:: LAMMPS
angle_style mesocnt
angle_coeff 1 buckling C 10 10 20.0
run 0
pair_style mesocnt 60.0
pair_coeff * * C_10_10.mesocnt 1
Restrictions
""""""""""""
This angle style can only be used if LAMMPS was built with the
MOLECULE and MESONT packages. See the :doc:`Build package
<Build_package>` doc page for more info.
Related commands
""""""""""""""""
:doc:`angle_coeff <angle_coeff>`
Default
"""""""
none
----------
.. _Srivastava_2:
**(Srivastava)** Zhigilei, Wei, Srivastava, Phys. Rev. B 71, 165417
(2005).
.. _Zhigilei1_1:
**(Zhigilei)** Volkov and Zhigilei, ACS Nano 4, 6187 (2010).

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

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

6
doc/src/angle_style.rst
View File

@ -10,7 +10,7 @@ Syntax
angle_style style
* style = *none* or *hybrid* or *charmm* or *class2* or *cosine* or *cosine/squared* or *harmonic*
* style = *none* or *zero* or *hybrid* or *amoeba* or *charmm* or *class2* or *class2/p6* or *cosine* or *cosine/buck6d* or *cosine/delta* or *cosine/periodic* or *cosine/shift* or *cosine/shift/exp* or *cosine/squared* or *cross* or *dipole* or *fourier* or *fourier/simple* or *gaussian* or *harmonic* or *mm3* or *quartic* or *spica* or *table*
Examples
""""""""
@ -73,6 +73,7 @@ of (g,i,k,o,t) to indicate which accelerated styles exist.
* :doc:`zero <angle_zero>` - topology but no interactions
* :doc:`hybrid <angle_hybrid>` - define multiple styles of angle interactions
* :doc:`amoeba <angle_amoeba>` - AMOEBA angle
* :doc:`charmm <angle_charmm>` - CHARMM angle
* :doc:`class2 <angle_class2>` - COMPASS (class 2) angle
* :doc:`class2/p6 <angle_class2>` - COMPASS (class 2) angle expanded to 6th order
@ -89,9 +90,10 @@ of (g,i,k,o,t) to indicate which accelerated styles exist.
* :doc:`fourier/simple <angle_fourier_simple>` - angle with a single cosine term
* :doc:`gaussian <angle_gaussian>` - multi-centered Gaussian-based angle potential
* :doc:`harmonic <angle_harmonic>` - harmonic angle
* :doc:`mesocnt <angle_mesocnt>` - piecewise harmonic and linear angle for bending-buckling of nanotubes
* :doc:`mm3 <angle_mm3>` - anharmonic angle
* :doc:`quartic <angle_quartic>` - angle with cubic and quartic terms
* :doc:`sdk <angle_sdk>` - harmonic angle with repulsive SDK pair style between 1-3 atoms
* :doc:`spica <angle_spica>` - harmonic angle with repulsive SPICA pair style between 1-3 atoms
* :doc:`table <angle_table>` - tabulated by angle
----------

5
doc/src/angle_zero.rst
View File

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

94
doc/src/atom_style.rst
View File

@ -10,7 +10,7 @@ Syntax
atom_style style args
* style = *angle* or *atomic* or *body* or *bond* or *charge* or *dipole* or *dpd* or *edpd* or *electron* or *ellipsoid* or *full* or *line* or *mdpd* or *molecular* or *oxdna* or *peri* or *smd* or *sph* or *sphere* or *bpm/sphere* or *spin* or *tdpd* or *tri* or *template* or *hybrid*
* style = *amoeba* or *angle* or *atomic* or *body* or *bond* or *charge* or *dielectric* or *dipole* or *dpd* or *edpd* or *electron* or *ellipsoid* or *full* or *line* or *mdpd* or *mesont* or *molecular* or *oxdna* or *peri* or *smd* or *sph* or *sphere* or *bpm/sphere* or *spin* or *tdpd* or *tri* or *template* or *wavepacket* or *hybrid*
.. parsed-literal::
@ -78,6 +78,8 @@ coordinates, velocities, atom IDs and types. See the
:doc:`set <set>` commands for info on how to set these various
quantities.
+--------------+-----------------------------------------------------+--------------------------------------+
| *amoeba* | molecular + charge + 1/5 neighbors | AMOEBA/HIPPO polarized force fields |
+--------------+-----------------------------------------------------+--------------------------------------+
| *angle* | bonds and angles | bead-spring polymers with stiffness |
+--------------+-----------------------------------------------------+--------------------------------------+
@ -89,7 +91,7 @@ quantities.
+--------------+-----------------------------------------------------+--------------------------------------+
| *charge* | charge | atomic system with charges |
+--------------+-----------------------------------------------------+--------------------------------------+
| *dielectric* | dipole, area, curvature | system with surface polarization |
| *dielectric* | normx normy normz area/patch ed em epsilon curv | system with surface polarization |
+--------------+-----------------------------------------------------+--------------------------------------+
| *dipole* | charge and dipole moment | system with dipolar particles |
+--------------+-----------------------------------------------------+--------------------------------------+
@ -139,11 +141,13 @@ quantities.
.. note::
It is possible to add some attributes, such as a molecule ID, to
atom styles that do not have them via the :doc:`fix property/atom <fix_property_atom>` command. This command also
allows new custom attributes consisting of extra integer or
floating-point values to be added to atoms. See the :doc:`fix property/atom <fix_property_atom>` page for examples of cases
where this is useful and details on how to initialize, access, and
output the custom values.
atom styles that do not have them via the :doc:`fix property/atom
<fix_property_atom>` command. This command also allows new custom
attributes consisting of extra integer or floating-point values to
be added to atoms. See the :doc:`fix property/atom
<fix_property_atom>` page for examples of cases where this is
useful and details on how to initialize, access, and output the
custom values.
All of the above styles define point particles, except the *sphere*,
*sphere/temp*, *bpm/sphere*, *ellipsoid*, *electron*, *peri*, *wavepacket*, *line*,
@ -158,17 +162,17 @@ basis.
For the *sphere*, *sphere/temp*, and *bpm/sphere* styles, the particles
are spheres and each stores a per-particle diameter and mass. If the
diameter > 0.0, the particle is a finite-size sphere. If the diameter = 0.0,
it is a point particle. Note that by use of the *disc* keyword with the :doc:`fix
nve/sphere <fix_nve_sphere>`, :doc:`fix nvt/sphere <fix_nvt_sphere>`,
:doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix npt/sphere
<fix_npt_sphere>` commands for the *sphere* style, spheres can be effectively treated as 2d
discs for a 2d simulation if desired. See also the :doc:`set
density/disc <set>` command. These styles take an optional 0
or 1 argument. A value of 0 means the radius of each sphere is
constant for the duration of the simulation. A value of 1 means the
radii may vary dynamically during the simulation, e.g. due to use of
the :doc:`fix adapt <fix_adapt>` command.
diameter > 0.0, the particle is a finite-size sphere. If the diameter
= 0.0, it is a point particle. Note that by use of the *disc* keyword
with the :doc:`fix nve/sphere <fix_nve_sphere>`, :doc:`fix nvt/sphere
<fix_nvt_sphere>`, :doc:`fix nph/sphere <fix_nph_sphere>`,
:doc:`fix npt/sphere <fix_npt_sphere>` commands for the *sphere* style,
spheres can be effectively treated as 2d discs for a 2d simulation if
desired. See also the :doc:`set density/disc <set>` command. These
styles take an optional 0 or 1 argument. A value of 0 means the
radius of each sphere is constant for the duration of the simulation.
A value of 1 means the radii may vary dynamically during the simulation,
e.g. due to use of the :doc:`fix adapt <fix_adapt>` command.
For the *ellipsoid* style, the particles are ellipsoids and each
stores a flag which indicates whether it is a finite-size ellipsoid or
@ -178,14 +182,20 @@ with its orientation.
For the *dielectric* style, each particle can be either a physical
particle (e.g. an ion), or an interface particle representing a boundary
element. For physical particles, the per-particle properties are
the same as atom_style full. For interface particles, in addition to
these properties, each particle also has an area, a normal unit vector,
a mean local curvature, the mean and difference of the dielectric constants
of two sides of the interface, and the local dielectric constant at the
boundary element. The distinction between the physical and interface
particles is only meaningful when :doc:`fix polarize <fix_polarize>`
commands are applied to the interface particles.
element between two regions of different dielectric constant. For
interface particles, in addition to the properties associated with
atom_style full, each particle also should be assigned a normal unit
vector (defined by normx, normy, normz), an area (area/patch), the
difference and mean of the dielectric constants of two sides of the
interface along the direction of the normal vector (ed and em), the
local dielectric constant at the boundary element (epsilon), and a mean
local curvature (curv). Physical particles must be assigned these
values, as well, but only their local dielectric constants will be used;
see documentation for associated :doc:`pair styles <pair_dielectric>`
and :doc:`fixes <fix_polarize>`. The distinction between the physical
and interface particles is only meaningful when :doc:`fix polarize
<fix_polarize>` commands are applied to the interface particles. This
style is part of the DIELECTRIC package.
For the *dipole* style, a point dipole is defined for each point
particle. Note that if you wish the particles to be finite-size
@ -274,16 +284,17 @@ showing the use of the *template* atom style versus *molecular*.
.. note::
When using the *template* style with a :doc:`molecule template <molecule>` that contains multiple molecules, you should
insure the atom types, bond types, angle_types, etc in all the
molecules are consistent. E.g. if one molecule represents H2O and
another CO2, then you probably do not want each molecule file to
define 2 atom types and a single bond type, because they will conflict
with each other when a mixture system of H2O and CO2 molecules is
defined, e.g. by the :doc:`read_data <read_data>` command. Rather the
H2O molecule should define atom types 1 and 2, and bond type 1. And
the CO2 molecule should define atom types 3 and 4 (or atom types 3 and
2 if a single oxygen type is desired), and bond type 2.
When using the *template* style with a :doc:`molecule template
<molecule>` that contains multiple molecules, you should insure the
atom types, bond types, angle_types, etc in all the molecules are
consistent. E.g. if one molecule represents H2O and another CO2,
then you probably do not want each molecule file to define 2 atom
types and a single bond type, because they will conflict with each
other when a mixture system of H2O and CO2 molecules is defined,
e.g. by the :doc:`read_data <read_data>` command. Rather the H2O
molecule should define atom types 1 and 2, and bond type 1. And
the CO2 molecule should define atom types 3 and 4 (or atom types 3
and 2 if a single oxygen type is desired), and bond type 2.
For the *body* style, the particles are arbitrary bodies with internal
attributes defined by the "style" of the bodies, which is specified by
@ -341,6 +352,8 @@ Many of the styles listed above are only enabled if LAMMPS was built
with a specific package, as listed below. See the :doc:`Build package
<Build_package>` page for more info.
The *amoeba* style is part of the AMOEBA package.
The *angle*, *bond*, *full*, *molecular*, and *template* styles are
part of the MOLECULE package.
@ -352,9 +365,11 @@ The *dipole* style is part of the DIPOLE package.
The *peri* style is part of the PERI package for Peridynamics.
The *oxdna* style is part of the CG-DNA package for coarse-grained simulation of DNA and RNA.
The *oxdna* style is part of the CG-DNA package for coarse-grained
simulation of DNA and RNA.
The *electron* style is part of the EFF package for :doc:`electronic force fields <pair_eff>`.
The *electron* style is part of the EFF package for :doc:`electronic
force fields <pair_eff>`.
The *dpd* style is part of the DPD-REACT package for dissipative
particle dynamics (DPD).
@ -365,7 +380,8 @@ dissipative particle dynamics (mDPD), and transport dissipative particle
dynamics (tDPD), respectively.
The *sph* style is part of the SPH package for smoothed particle
hydrodynamics (SPH). See `this PDF guide <PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
hydrodynamics (SPH). See `this PDF guide
<PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
The *mesont* style is part of the MESONT package.

2
doc/src/balance.rst
View File

@ -6,7 +6,7 @@ balance command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
balance thresh style args ... keyword args ...

61
doc/src/bond_bpm_rotational.rst
View File

@ -38,8 +38,7 @@ Examples
bond_style bpm/rotational
bond_coeff 1 1.0 0.2 0.02 0.02 0.20 0.04 0.04 0.04 0.1 0.02 0.002 0.002
bond_style bpm/rotational myfix 1000 time id1 id2
fix myfix all store/local 1000 3
bond_style bpm/rotational store/local myfix 1000 time id1 id2
dump 1 all local 1000 dump.broken f_myfix[1] f_myfix[2] f_myfix[3]
dump_modify 1 write_header no
@ -139,15 +138,14 @@ the *overlay/pair* keyword. These settings require specific
restrictions. Further details can be found in the `:doc: how to
<Howto_BPM>` page on BPMs.
If the *store/local* keyword is used, this fix will track bonds that
If the *store/local* keyword is used, an internal fix will track bonds that
break during the simulation. Whenever a bond breaks, data is processed
and transferred to an internal fix labeled *fix_ID*. This allows the
local data to be accessed by other LAMMPS commands.
Following any optional keyword/value arguments, a list of one or more
attributes is specified. These include the IDs of the two atoms in
the bond. The other attributes for the two atoms include the timestep
during which the bond broke and the current/initial center of mass
position of the two atoms.
local data to be accessed by other LAMMPS commands. Following this optional
keyword, a list of one or more attributes is specified. These include the
IDs of the two atoms in the bond. The other attributes for the two atoms
include the timestep during which the bond broke and the current/initial
center of mass position of the two atoms.
Data is continuously accumulated over intervals of *N*
timesteps. At the end of each interval, all of the saved accumulated
@ -178,29 +176,38 @@ Restart and other info
This bond style writes the reference state of each bond to
:doc:`binary restart files <restart>`. Loading a restart file will
properly resume bonds.
properly resume bonds. However, the reference state is NOT
written to data files. Therefore reading a data file will not
restore bonds and will cause their reference states to be redefined.
The single() function of these pair styles returns 0.0 for the energy
of a pairwise interaction, since energy is not conserved in these
dissipative potentials. It also returns only the normal component of
the pairwise interaction force.
The accumulated data is not written to restart files and should be
output before a restart file is written to avoid missing data.
The internal fix calculates a local vector or local array depending on the
number of input values. The length of the vector or number of rows in
the array is the number of recorded, lost interactions. If a single
input is specified, a local vector is produced. If two or more inputs
are specified, a local array is produced where the number of columns =
the number of inputs. The vector or array can be accessed by any
command that uses local values from a compute as input. See the
:doc:`Howto output <Howto_output>` page for an overview of LAMMPS
output options.
If the *store/local* option is used, an internal fix will calculate
a local vector or local array depending on the number of input values.
The length of the vector or number of rows in the array is the number
of recorded, broken bonds. If a single input is specified, a local
vector is produced. If two or more inputs are specified, a local array
is produced where the number of columns = the number of inputs. The
vector or array can be accessed by any command that uses local values
from a compute as input. See the :doc:`Howto output <Howto_output>` page
for an overview of LAMMPS output options.
The vector or array will be floating point values that correspond to
the specified attribute.
The single() function of this bond style returns 0.0 for the energy
of a bonded interaction, since energy is not conserved in these
dissipative potentials. It also returns only the normal component of
the bonded interaction force. However, the single() function also
calculates 7 extra bond quantities. The first 4 are data from the
reference state of the bond including the initial distance between particles
:math:`r_0` followed by the :math:`x`, :math:`y`, and :math:`z` components
of the initial unit vector pointing to particle I from particle J. The next 3
quantities (5-7) are the :math:`x`, :math:`y`, and :math:`z` components
of the total force, including normal and tangential contributions, acting
on particle I.
These extra quantities can be accessed by the :doc:`compute bond/local <compute_bond_local>`
command, as *b1*, *b2*, ..., *b7*\ .
Restrictions
""""""""""""

49
doc/src/bond_bpm_spring.rst
View File

@ -103,15 +103,14 @@ the *overlay/pair* keyword. These settings require specific
restrictions. Further details can be found in the `:doc: how to
<Howto_BPM>` page on BPMs.
If the *store/local* keyword is used, this fix will track bonds that
If the *store/local* keyword is used, an internal fix will track bonds that
break during the simulation. Whenever a bond breaks, data is processed
and transferred to an internal fix labeled *fix_ID*. This allows the
local data to be accessed by other LAMMPS commands.
Following any optional keyword/value arguments, a list of one or more
attributes is specified. These include the IDs of the two atoms in
the bond. The other attributes for the two atoms include the timestep
during which the bond broke and the current/initial center of mass
position of the two atoms.
local data to be accessed by other LAMMPS commands. Following this optional
keyword, a list of one or more attributes is specified. These include the
IDs of the two atoms in the bond. The other attributes for the two atoms
include the timestep during which the bond broke and the current/initial
center of mass position of the two atoms.
Data is continuously accumulated over intervals of *N*
timesteps. At the end of each interval, all of the saved accumulated
@ -141,28 +140,30 @@ Restart and other info
This bond style writes the reference state of each bond to
:doc:`binary restart files <restart>`. Loading a restart
file will properly resume bonds.
file will properly restore bonds. However, the reference state is NOT
written to data files. Therefore reading a data file will not
restore bonds and will cause their reference states to be redefined.
The single() function of these pair styles returns 0.0 for the energy
of a pairwise interaction, since energy is not conserved in these
dissipative potentials.
The accumulated data is not written to restart files and should be
output before a restart file is written to avoid missing data.
The internal fix calculates a local vector or local array depending on the
number of input values. The length of the vector or number of rows in
the array is the number of recorded, lost interactions. If a single
input is specified, a local vector is produced. If two or more inputs
are specified, a local array is produced where the number of columns =
the number of inputs. The vector or array can be accessed by any
command that uses local values from a compute as input. See the
:doc:`Howto output <Howto_output>` page for an overview of LAMMPS
output options.
If the *store/local* option is used, an internal fix will calculate
a local vector or local array depending on the number of input values.
The length of the vector or number of rows in the array is the number
of recorded, broken bonds. If a single input is specified, a local
vector is produced. If two or more inputs are specified, a local array
is produced where the number of columns = the number of inputs. The
vector or array can be accessed by any command that uses local values
from a compute as input. See the :doc:`Howto output <Howto_output>` page
for an overview of LAMMPS output options.
The vector or array will be floating point values that correspond to
the specified attribute.
The single() function of this bond style returns 0.0 for the energy
of a bonded interaction, since energy is not conserved in these
dissipative potentials. The single() function also calculates an
extra bond quantity, the initial distance :math:`r_0`. This
extra quantity can be accessed by the
:doc:`compute bond/local <compute_bond_local>` command as *b1*\ .
Restrictions
""""""""""""

30
doc/src/bond_coeff.rst
View File

@ -10,7 +10,7 @@ Syntax
bond_coeff N args
* N = bond type (see asterisk form below)
* N = numeric bond type (see asterisk form below), or type label
* args = coefficients for one or more bond types
Examples
@ -21,7 +21,10 @@ Examples
bond_coeff 5 80.0 1.2
bond_coeff * 30.0 1.5 1.0 1.0
bond_coeff 1*4 30.0 1.5 1.0 1.0
bond_coeff 1 harmonic 200.0 1.0
bond_coeff 1 harmonic 200.0 1.0 # (for bond_style hybrid)
labelmap bond 5 carbonyl
bond_coeff carbonyl 80.0 1.2
Description
"""""""""""
@ -31,14 +34,19 @@ The number and meaning of the coefficients depends on the bond style.
Bond coefficients can also be set in the data file read by the
:doc:`read_data <read_data>` command or in a restart file.
N can be specified in one of two ways. An explicit numeric value can
be used, as in the first example above. Or a wild-card asterisk can be
used to set the coefficients for multiple bond types. This takes the
form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of bond types,
then an asterisk with no numeric values means all types from 1 to N. A
:math:`N` can be specified in one of several ways. An explicit numeric
value can be used, as in the first example above. Or :math:`N` can be a
type label, which is an alphanumeric string defined by the
:doc:`labelmap <labelmap>` command or in a section of a data file read
by the :doc:`read_data <read_data>` command.
For numeric values only, a wild-card asterisk can be used to set the
coefficients for multiple bond types. This takes the form "\*" or "\*n"
or "n\*" or "m\*n". If :math:`N` is the number of bond types, then an
asterisk with no numeric values means all types from 1 to :math:`N`. A
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).
asterisk means all types from n to :math:`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
for the same bond type. For example, these commands set the coeffs
@ -52,8 +60,8 @@ for all bond types, then overwrite the coeffs for just bond type 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
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
coefficients for all :math:`N` types must be listed in the file. For
example, under the "Bond Coeffs" section of a data file, the line that
corresponds to the first example above would be listed as
.. parsed-literal::

84
doc/src/bond_mesocnt.rst Normal file
View File

@ -0,0 +1,84 @@
.. index:: bond_style mesocnt
bond_style mesocnt command
===========================
Syntax
""""""
.. code-block:: LAMMPS
bond_style mesocnt
Examples
""""""""
.. code-block:: LAMMPS
bond_style mesocnt
bond_coeff 1 C 10 10 20.0
bond_coeff 4 custom 800.0 10.0
Description
"""""""""""
.. versionadded:: 15Sep2022
The *mesocnt* bond style is a wrapper for the :doc:`harmonic
<bond_harmonic>` style, and uses the potential
.. math::
E = K (r - r_0)^2
where :math:`r_0` is the equilibrium bond distance. Note that the
usual 1/2 factor is included in :math:`K`. The style implements
parameterization presets of :math:`K` for mesoscopic simulations of
carbon nanotubes based on the atomistic simulations of
:ref:`(Srivastava) <Srivastava_1>`.
Other presets can be readily implemented in the future.
The following coefficients must be defined for each bond type via the
:doc:`bond_coeff <bond_coeff>` command as in the example above, or in
the data file or restart files read by the :doc:`read_data
<read_data>` or :doc:`read_restart <read_restart>` commands:
* preset = *C* or *custom*
* additional parameters depending on preset
Preset *C* is for carbon nanotubes, and the additional parameters are:
* chiral index :math:`n` (unitless)
* chiral index :math:`m` (unitless)
* :math:`r_0` (distance)
Preset *custom* is simply a direct wrapper for the :doc:`harmonic
<bond_harmonic>` style, and the additional parameters are:
* :math:`K` (energy/distance\^2)
* :math:`r_0` (distance)
Restrictions
""""""""""""
This bond style can only be used if LAMMPS was built with the MOLECULE
and MESONT packages. See the :doc:`Build package <Build_package>`
page for more info.
Related commands
""""""""""""""""
:doc:`bond_coeff <bond_coeff>`, :doc:`delete_bonds <delete_bonds>`
Default
"""""""
none
----------
.. _Srivastava_1:
**(Srivastava)** Zhigilei, Wei and Srivastava, Phys. Rev. B 71, 165417
(2005).

10
doc/src/bond_mm3.rst
View File

@ -26,14 +26,14 @@ as defined in :ref:`(Allinger) <mm3-allinger1989>`
.. math::
E = K (r - r_0)^2 \left[ 1 - 2.55(r-r_0) + (7/12) 2.55^2(r-r_0)^2 \right]
E = K (r - r_0)^2 \left[ 1 - 2.55(r-r_0) + \frac{7}{12} 2.55^2(r-r_0)^2 \right]
where :math:`r_0` is the equilibrium value of the bond, and :math:`K` is a
prefactor. The anharmonic prefactors have units angstrom\^(-n):
-2.55 angstrom\^(-1) and (7/12)2.55\^2 angstrom\^(-2). The code takes
prefactor. The anharmonic prefactors have units :math:`\AA^{-n}`:
:math:`-2.55 \AA^{-1}` and :math:`\frac{7}{12} 2.55^2 \AA^{-2}`. The code takes
care of the necessary unit conversion for these factors internally.
Note that the MM3 papers contains an error in Eq (1):
(7/12)2.55 should be replaced with (7/12)2.55\^2
Note that the MM3 papers contain an error in Eq (1):
:math:`\frac{7}{12} 2.55` should be replaced with :math:`\frac{7}{12} 2.55^2`
The following coefficients must be defined for each bond type via the
:doc:`bond_coeff <bond_coeff>` command as in the example above, or in

19
doc/src/bond_quartic.rst
View File

@ -28,11 +28,18 @@ The *quartic* bond style uses the potential
.. math::
E = K (r - R_c)^ 2 (r - R_c - B_1) (r - R_c - B_2) + U_0 + 4 \epsilon \left[ \left(\frac{\sigma}{r}\right)^{12} - \left(\frac{\sigma}{r}\right)^6 \right] + \epsilon
E & = E_q + E_{LJ} \\
E_q & = K (r - R_c)^ 2 (r - R_c - B_1) (r - R_c - B_2) + U_0 \\
E_{LJ} & = \left\{ \begin{array} {l@{\quad:\quad}l}
4 \epsilon \left[ \left(\frac{\sigma}{r}\right)^{12} - \left(\frac{\sigma}{r}\right)^6 \right] + \epsilon & r < 2^{\frac{1}{6}}, \epsilon = 1, \sigma = 1 \\
0 & r >= 2^{\frac{1}{6}}
\end{array} \right.
to define a bond that can be broken as the simulation proceeds (e.g.
due to a polymer being stretched). The :math:`\sigma` and :math:`\epsilon` used in the
LJ portion of the formula are both set equal to 1.0 by LAMMPS.
due to a polymer being stretched). The :math:`\sigma` and
:math:`\epsilon` used in the LJ portion of the formula are both set
equal to 1.0 by LAMMPS and the LJ portion is cut off at its minimum,
i.e. at :math:`r_c = 2^{\frac{1}{6}}`.
The following coefficients must be defined for each bond type via the
:doc:`bond_coeff <bond_coeff>` command as in the example above, or in
@ -46,9 +53,9 @@ or :doc:`read_restart <read_restart>` commands:
* :math:`U_0` (energy)
This potential was constructed to mimic the FENE bond potential for
coarse-grained polymer chains. When monomers with :math:`\sigma = \epsilon = 1.0`
are used, the following choice of parameters gives a quartic potential that
looks nearly like the FENE potential:
coarse-grained polymer chains. When monomers with :math:`\sigma =
\epsilon = 1.0` are used, the following choice of parameters gives a
quartic potential that looks nearly like the FENE potential:
.. math::

3
doc/src/bond_style.rst
View File

@ -10,7 +10,7 @@ Syntax
bond_style style args
* style = *none* or *hybrid* or *class2* or *fene* or *fene/expand* or *harmonic* or *morse* or *nonlinear* or *quartic*
* style = *none* or *zero* or *hybrid* or *bpm/rotational* or *bpm/spring* or *class2* or *fene* or *fene/expand* or *fene/nm* or *gaussian* or *gromos* or *harmonic* or *harmonic/shift* or *harmonic/shift/cut* or *morse* or *nonlinear* or *oxdna/fene* or *oxdena2/fene* or *oxrna2/fene* or *quartic* or *special* or *table*
* args = none for any style except *hybrid*
@ -95,6 +95,7 @@ accelerated styles exist.
* :doc:`harmonic <bond_harmonic>` - harmonic bond
* :doc:`harmonic/shift <bond_harmonic_shift>` - shifted harmonic bond
* :doc:`harmonic/shift/cut <bond_harmonic_shift_cut>` - shifted harmonic bond with a cutoff
* :doc:`mesocnt <bond_mesocnt>` - Harmonic bond wrapper with parameterization presets for nanotubes
* :doc:`mm3 <bond_mm3>` - MM3 anharmonic bond
* :doc:`morse <bond_morse>` - Morse bond
* :doc:`nonlinear <bond_nonlinear>` - nonlinear bond

5
doc/src/bond_zero.rst
View File

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

2
doc/src/boundary.rst
View File

@ -6,7 +6,7 @@ boundary command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
boundary x y z

2
doc/src/box.rst
View File

@ -6,7 +6,7 @@ box command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
box keyword value ...

23
doc/src/clear.rst
View File

@ -6,32 +6,33 @@ clear command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
clear
Examples
""""""""
.. parsed-literal::
.. code-block:: LAMMPS
(commands for 1st simulation)
# (commands for 1st simulation)
clear
(commands for 2nd simulation)
# (commands for 2nd simulation)
Description
"""""""""""
This command deletes all atoms, restores all settings to their default
values, and frees all memory allocated by LAMMPS. Once a clear
command has been executed, it is almost as if LAMMPS were starting
over, with only the exceptions noted below. This command enables
multiple jobs to be run sequentially from one input script.
values, and frees all memory allocated by LAMMPS. Once a clear command
has been executed, it is almost as if LAMMPS were starting over, with
only the exceptions noted below. This command enables multiple jobs to
be run sequentially from one input script.
These settings are not affected by a clear command: the working
directory (:doc:`shell <shell>` command), log file status
(:doc:`log <log>` command), echo status (:doc:`echo <echo>` command), and
input script variables (:doc:`variable <variable>` command).
directory (:doc:`shell <shell>` command), log file status (:doc:`log
<log>` command), echo status (:doc:`echo <echo>` command), and input
script variables except for *atomfile* style variables (:doc:`variable
<variable>` command).
Restrictions
""""""""""""

4
doc/src/comm_modify.rst
View File

@ -10,8 +10,8 @@ Syntax
comm_modify keyword value ...
* zero or more keyword/value pairs may be appended
* keyword = *mode* or *cutoff* or *cutoff/multi* or *multi/reduce* or *group* or *vel*
* one or more keyword/value pairs may be appended
* keyword = *mode* or *cutoff* or *cutoff/multi* or *group* or *reduce/multi* or *vel*
.. parsed-literal::

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