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

Fixing merge conflicts

Browse Source
This commit is contained in:
jtclemm
2022-09-03 12:35:32 -06:00
parent 8fafd4d8fb 8315f9996b
commit 1d0db98403
1450 changed files with 443803 additions and 21431 deletions
Download Patch File Download Diff File Expand all files Collapse all files

57
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
^^^^^^^^^^^^^^^^
@ -788,8 +807,10 @@ library.
.. code-block:: bash
-D DOWNLOAD_LATTE=value # download LATTE for build, value = no (default) or yes
-D LATTE_LIBRARY=path # LATTE library file (only needed if a custom location)
-D DOWNLOAD_LATTE=value # download LATTE for build, value = no (default) or yes
-D LATTE_LIBRARY=path # LATTE library file (only needed if a custom location)
-D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
# value = no (default) or yes
If ``DOWNLOAD_LATTE`` is set, the LATTE library will be downloaded
and built inside the CMake build directory. If the LATTE library
@ -797,6 +818,13 @@ library.
``LATTE_LIBRARY`` is the filename (plus path) of the LATTE library
file, not the directory the library file is in.
The LATTE library requires LAPACK (and BLAS) and CMake can identify
their locations and pass that info to the LATTE build script. But
on some systems this triggers a (current) limitation of CMake and
the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
those cases to use the bundled linear algebra library and work around
the limitation.
.. tab:: Traditional make
You can download and build the LATTE library manually if you
@ -1913,14 +1941,25 @@ within CMake will download the non-commercial use version.
.. code-block:: bash
-D DOWNLOAD_QUIP=value # download OpenKIM API v2 for build, value = no (default) or yes
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
-D DOWNLOAD_QUIP=value # download QUIP library for build, value = no (default) or yes
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
-D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
# value = no (default) or yes
CMake will try to download and build the QUIP library from GitHub, if it is not
found on the local machine. This requires to have git installed. It will use the same compilers
and flags as used for compiling LAMMPS. Currently this is only supported for the GNU and the
Intel compilers. Set the ``QUIP_LIBRARY`` variable if you want to use a previously compiled
and installed QUIP library and CMake cannot find it.
CMake will try to download and build the QUIP library from GitHub,
if it is not found on the local machine. This requires to have git
installed. It will use the same compilers and flags as used for
compiling LAMMPS. Currently this is only supported for the GNU
and the Intel compilers. Set the ``QUIP_LIBRARY`` variable if you
want to use a previously compiled and installed QUIP library and
CMake cannot find it.
The QUIP library requires LAPACK (and BLAS) and CMake can identify
their locations and pass that info to the QUIP build script. But
on some systems this triggers a (current) limitation of CMake and
the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
those cases to use the bundled linear algebra library and work around
the limitation.
.. tab:: Traditional make

24
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
@ -252,6 +249,5 @@ manual with ``make spelling``. This requires `a library called enchant
positives* (e.g. keywords, names, abbreviations) those can be added to
the file ``lammps/doc/utils/sphinx-config/false_positives.txt``.
.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
.. _lws: https://www.lammps.org
.. _rst: https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html

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

1
doc/src/Commands_all.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>`
General commands
================

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>`

5
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>`

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
==============

15
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>`
@ -268,7 +272,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 +285,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>`

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 developer@lammps.org in case you run across an issue that is not
(yet) listed here. Please also review the latest information about the
LAMMPS :doc:`programming style conventions <Modify_style>`, especially
if you are considering to submit the updated version for inclusion into
the LAMMPS distribution.
Available topics in mostly chronological order are:
- `Setting flags in the constructor`_
- `Rename of pack/unpack_comm() to pack/unpack_forward_comm()`_
- `Use ev_init() to initialize variables derived from eflag and vflag`_
- `Use utils::numeric() functions instead of force->numeric()`_
- `Use utils::open_potential() function to open potential files`_
- `Simplify customized error messages`_
- `Use of "override" instead of "virtual"`_
- `Simplified and more compact neighbor list requests`_
- `Split of fix STORE into fix STORE/GLOBAL and fix STORE/PERATOM`_
- `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:: TBD
This change splits the GLOBAL and PERATOM modes of fix STORE into two
separate fixes STORE/GLOBAL and STORE/PERATOM. There was very little
shared code between the two fix STORE modes and the two different code
paths had to be prefixed with if statements. Furthermore, some flags
were used differently in the two modes leading to confusion. Splitting
the code into two fix styles, makes it more easily maintainable. Since
these are internal fixes, there is no user visible change.
Old:
.. code-block:: C++
#include "fix_store.h"
FixStore *fix = dynamic_cast<FixStore *>(
modify->add_fix(fmt::format("{} {} STORE peratom 1 13",id_pole,group->names[0]));
FixStore *fix = dynamic_cast<FixStore *>(modify->get_fix_by_id(id_pole));
New:
.. code-block:: C++
#include "fix_store_peratom.h"
FixStorePeratom *fix = dynamic_cast<FixStorePeratom *>(
modify->add_fix(fmt::format("{} {} STORE/PERATOM 1 13",id_pole,group->names[0]));
FixStorePeratom *fix = dynamic_cast<FixStorePeratom *>(modify->get_fix_by_id(id_pole));
Old:
.. code-block:: C++
#include "fix_store.h"
FixStore *fix = dynamic_cast<FixStore *>(
modify->add_fix(fmt::format("{} {} STORE global 1 1",id_fix,group->names[igroup]));
FixStore *fix = dynamic_cast<FixStore *>(modify->get_fix_by_id(id_fix));
New:
.. code-block:: C++
#include "fix_store_global.h"
FixStoreGlobal *fix = dynamic_cast<FixStoreGlobal *>(
modify->add_fix(fmt::format("{} {} STORE/GLOBAL 1 1",id_fix,group->names[igroup]));
FixStoreGlobal *fix = dynamic_cast<FixStoreGlobal *>(modify->get_fix_by_id(id_fix));
This change is **required** or else the code will not compile.
Use Output::get_dump_by_id() instead of Output::find_dump()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: TBD
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.

5
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
@ -205,7 +208,7 @@ Argument processing
Convenience functions
^^^^^^^^^^^^^^^^^^^^^
.. doxygenfunction:: logmesg(LAMMPS *lmp, const S &format, Args&&... args)
.. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &format, Args&&... args)
:project: progguide
.. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &mesg)

126
doc/src/Errors_messages.rst
View File

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

25
doc/src/Errors_warnings.rst
View File

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

65
doc/src/Fortran.rst
View File

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

1
doc/src/Howto.rst
View File

@ -65,6 +65,7 @@ Force fields howto
:maxdepth: 1
Howto_bioFF
Howto_amoeba
Howto_tip3p
Howto_tip4p
Howto_spc

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

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

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

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 = {}

17
doc/src/Howto_viscosity.rst
View File

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

18
doc/src/Install.rst
View File

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

7
doc/src/Install_conda.rst
View File

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

130
doc/src/Install_linux.rst
View File

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

6
doc/src/Intro_citing.rst
View File

@ -33,9 +33,9 @@ initial versions of LAMMPS is:
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:

6
doc/src/Manual.rst
View File

@ -49,12 +49,12 @@ descriptions of all commands included in the LAMMPS code.
----------
.. _user_documentation:
************
User Guide
************
.. _user_documentation:
.. toctree::
:maxdepth: 2
:numbered: 3
@ -75,11 +75,12 @@ User Guide
Errors
.. _programmer_documentation:
******************
Programmer Guide
******************
.. _programmer_documentation:
.. toctree::
:maxdepth: 2
:numbered: 3
@ -110,6 +111,7 @@ Command Reference
angles
dihedrals
impropers
dumps
fix_modify_atc_commands
Bibliography

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) |

15
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

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

Binary file not shown.

115
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>`
@ -149,6 +150,38 @@ This package has :ref:`specific installation instructions <adios>` on the :doc:`
----------
.. _PKG-AMOEBA:
AMOEBA package
---------------
**Contents:**
Implementation of the AMOEBA and HIPPO polarized force fields
originally developed by Jay Ponder's group at the U Washington at St
Louis. The LAMMPS implementation is based on Fortran 90 code
provided by the Ponder group in their
`Tinker MD software <https://dasher.wustl.edu/tinker/>`_.
**Authors:** Josh Rackers and Steve Plimpton (Sandia), Trung Nguyen (U
Chicago)
**Supporting info:**
* src/AMOEBA: filenames -> commands
* :doc:`AMOEBA and HIPPO howto <Howto_amoeba>`
* :doc:`pair_style amoeba <pair_amoeba>`
* :doc:`pair_style hippo <pair_amoeba>`
* :doc:`atom_style amoeba <atom_style>`
* :doc:`angle_style amoeba <angle_amoeba>`
* :doc:`improper_style amoeba <improper_amoeba>`
* :doc:`fix amoeba/bitorsion <fix_amoeba_bitorsion>`
* :doc:`fix amoeba/pitorsion <fix_amoeba_pitorsion>`
* tools/tinker/tinker2lmp.py
* examples/amoeba
----------
.. _PKG-ASPHERE:
ASPHERE package
@ -181,9 +214,10 @@ ATC package
**Contents:**
ATC stands for atoms-to-continuum. This package implements a :doc:`fix atc <fix_atc>` command to either couple molecular dynamics with
continuum finite element equations or perform on-the-fly conversion of
atomic information to continuum fields.
ATC stands for atoms-to-continuum. This package implements a
:doc:`fix atc <fix_atc>` command to either couple molecular dynamics
with continuum finite element equations or perform on-the-fly
conversion of atomic information to continuum fields.
**Authors:** Reese Jones, Jeremy Templeton, Jon Zimmerman (Sandia).
@ -298,6 +332,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
@ -365,28 +401,30 @@ The CG-DNA package requires that also the `MOLECULE <PKG-MOLECULE>`_ and
----------
.. _PKG-CG-SDK:
.. _PKG-CG-SPICA:
CG-SDK package
CG-SPICA package
------------------
**Contents:**
Several pair styles and an angle style which implement the
coarse-grained SDK model of Shinoda, DeVane, and Klein which enables
simulation of ionic liquids, electrolytes, lipids and charged amino
acids.
coarse-grained SPICA (formerly called SDK) model which enables
simulation of biological or soft material systems.
**Author:** Axel Kohlmeyer (Temple U).
**Original Author:** Axel Kohlmeyer (Temple U).
**Maintainers:** Yusuke Miyazaki and Wataru Shinoda (Okayama U).
**Supporting info:**
* src/CG-SDK: filenames -> commands
* src/CG-SDK/README
* :doc:`pair_style lj/sdk/\* <pair_sdk>`
* :doc:`angle_style sdk <angle_sdk>`
* examples/PACKAGES/cgsdk
* src/CG-SPICA: filenames -> commands
* src/CG-SPICA/README
* :doc:`pair_style lj/spica/\* <pair_spica>`
* :doc:`angle_style spica <angle_spica>`
* examples/PACKAGES/cgspica
* https://www.lammps.org/pictures.html#cg
* https://www.spica-ff.org/
----------
@ -657,7 +695,7 @@ advection-diffusion-reaction systems. The equations of motion of these
DPD extensions are integrated through a modified velocity-Verlet (MVV)
algorithm.
**Author:** Zhen Li (Division of Applied Mathematics, Brown University)
**Author:** Zhen Li (Department of Mechanical Engineering, Clemson University)
**Supporting info:**
@ -824,6 +862,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
@ -1479,7 +1519,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,31 +1556,40 @@ 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)
**Supporting info:**
@ -1550,6 +1599,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
@ -1801,6 +1852,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

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

19
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>`
@ -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 ....**

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.

17
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>`
@ -1007,14 +1007,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.
----------

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

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:: TBD
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 |
+--------------+-----------------------------------------------------+--------------------------------------+
@ -137,11 +139,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*,
*bpm/sphere*, *ellipsoid*, *electron*, *peri*, *wavepacket*, *line*,
@ -154,19 +158,20 @@ per-type basis, using the :doc:`mass <mass>` command, The finite-size
particle styles assign mass to individual particles on a per-particle
basis.
For the *sphere* and *bpm/sphere* styles, the particles are spheres and each stores a
per-particle diameter and mass. If the diameter > 0.0, the particle
is a finite-size sphere. If the diameter = 0.0, it is a point
particle. Note that by use of the *disc* keyword with the :doc:`fix
nve/sphere <fix_nve_sphere>`, :doc:`fix nvt/sphere <fix_nvt_sphere>`,
:doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix npt/sphere
<fix_npt_sphere>` commands for the *sphere* style, spheres can be effectively treated as 2d
discs for a 2d simulation if desired. See also the :doc:`set
density/disc <set>` command. The *sphere* and *bpm/sphere* styles take an optional 0
or 1 argument. A value of 0 means the radius of each sphere is
constant for the duration of the simulation. A value of 1 means the
radii may vary dynamically during the simulation, e.g. due to use of
the :doc:`fix adapt <fix_adapt>` command.
For the *sphere* and *bpm/sphere* styles, the particles are spheres
and each stores a per-particle diameter and mass. If the diameter >
0.0, the particle is a finite-size sphere. If the diameter = 0.0, it
is a point particle. Note that by use of the *disc* keyword with the
:doc:`fix nve/sphere <fix_nve_sphere>`, :doc:`fix nvt/sphere
<fix_nvt_sphere>`, :doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix
npt/sphere <fix_npt_sphere>` commands for the *sphere* style, spheres
can be effectively treated as 2d discs for a 2d simulation if desired.
See also the :doc:`set density/disc <set>` command. The *sphere* and
*bpm/sphere* styles take an optional 0 or 1 argument. A value of 0
means the radius of each sphere is constant for the duration of the
simulation. A value of 1 means the radii may vary dynamically during
the simulation, e.g. due to use of the :doc:`fix adapt <fix_adapt>`
command.
For the *ellipsoid* style, the particles are ellipsoids and each
stores a flag which indicates whether it is a finite-size ellipsoid or
@ -175,15 +180,16 @@ vector with the 3 diameters of the ellipsoid and a quaternion 4-vector
with its orientation.
For the *dielectric* style, each particle can be either a physical
particle (e.g. an ion), or an interface particle representing a boundary
element. For physical particles, the per-particle properties are
the same as atom_style full. For interface particles, in addition to
these properties, each particle also has an area, a normal unit vector,
a mean local curvature, the mean and difference of the dielectric constants
of two sides of the interface, and the local dielectric constant at the
boundary element. The distinction between the physical and interface
particles is only meaningful when :doc:`fix polarize <fix_polarize>`
commands are applied to the interface particles.
particle (e.g. an ion), or an interface particle representing a
boundary element. For physical particles, the per-particle properties
are the same as atom_style full. For interface particles, in addition
to these properties, each particle also has an area, a normal unit
vector, a mean local curvature, the mean and difference of the
dielectric constants of two sides of the interface, and the local
dielectric constant at the boundary element. The distinction between
the physical and interface particles is only meaningful when :doc:`fix
polarize <fix_polarize>` commands are applied to the interface
particles.
For the *dipole* style, a point dipole is defined for each point
particle. Note that if you wish the particles to be finite-size
@ -272,16 +278,17 @@ showing the use of the *template* atom style versus *molecular*.
.. note::
When using the *template* style with a :doc:`molecule template <molecule>` that contains multiple molecules, you should
insure the atom types, bond types, angle_types, etc in all the
molecules are consistent. E.g. if one molecule represents H2O and
another CO2, then you probably do not want each molecule file to
define 2 atom types and a single bond type, because they will conflict
with each other when a mixture system of H2O and CO2 molecules is
defined, e.g. by the :doc:`read_data <read_data>` command. Rather the
H2O molecule should define atom types 1 and 2, and bond type 1. And
the CO2 molecule should define atom types 3 and 4 (or atom types 3 and
2 if a single oxygen type is desired), and bond type 2.
When using the *template* style with a :doc:`molecule template
<molecule>` that contains multiple molecules, you should insure the
atom types, bond types, angle_types, etc in all the molecules are
consistent. E.g. if one molecule represents H2O and another CO2,
then you probably do not want each molecule file to define 2 atom
types and a single bond type, because they will conflict with each
other when a mixture system of H2O and CO2 molecules is defined,
e.g. by the :doc:`read_data <read_data>` command. Rather the H2O
molecule should define atom types 1 and 2, and bond type 1. And
the CO2 molecule should define atom types 3 and 4 (or atom types 3
and 2 if a single oxygen type is desired), and bond type 2.
For the *body* style, the particles are arbitrary bodies with internal
attributes defined by the "style" of the bodies, which is specified by
@ -339,6 +346,8 @@ Many of the styles listed above are only enabled if LAMMPS was built
with a specific package, as listed below. See the :doc:`Build package
<Build_package>` page for more info.
The *amoeba* style is part of the AMOEBA package.
The *angle*, *bond*, *full*, *molecular*, and *template* styles are
part of the MOLECULE package.
@ -350,9 +359,11 @@ The *dipole* style is part of the DIPOLE package.
The *peri* style is part of the PERI package for Peridynamics.
The *oxdna* style is part of the CG-DNA package for coarse-grained simulation of DNA and RNA.
The *oxdna* style is part of the CG-DNA package for coarse-grained
simulation of DNA and RNA.
The *electron* style is part of the EFF package for :doc:`electronic force fields <pair_eff>`.
The *electron* style is part of the EFF package for :doc:`electronic
force fields <pair_eff>`.
The *dpd* style is part of the DPD-REACT package for dissipative
particle dynamics (DPD).
@ -363,7 +374,8 @@ dissipative particle dynamics (mDPD), and transport dissipative particle
dynamics (tDPD), respectively.
The *sph* style is part of the SPH package for smoothed particle
hydrodynamics (SPH). See `this PDF guide <PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
hydrodynamics (SPH). See `this PDF guide
<PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
The *mesont* style is part of the MESONT package.

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 ...

3
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

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:: TBD
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).

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 ...

8
doc/src/clear.rst
View File

@ -6,18 +6,18 @@ 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
"""""""""""

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::

92
doc/src/compute.rst
View File

@ -6,7 +6,7 @@ compute command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID style args
@ -33,8 +33,8 @@ they are calculated from information about atoms on the current
timestep or iteration, though a compute may internally store some
information about a previous state of the system. Defining a compute
does not perform a computation. Instead computes are invoked by other
LAMMPS commands as needed, e.g. to calculate a temperature needed for
a thermostat fix or to generate thermodynamic or dump file output.
LAMMPS commands as needed (e.g., to calculate a temperature needed for
a thermostat fix or to generate thermodynamic or dump file output).
See the :doc:`Howto output <Howto_output>` page for a summary of
various LAMMPS output options, many of which involve computes.
@ -45,15 +45,15 @@ underscores.
Computes calculate one of three styles of quantities: global,
per-atom, or local. A global quantity is one or more system-wide
values, e.g. the temperature of the system. A per-atom quantity is
one or more values per atom, e.g. the kinetic energy of each atom.
values (e.g., the temperature of the system). A per-atom quantity is
one or more values per atom (e.g., the kinetic energy of each atom).
Per-atom values are set to 0.0 for atoms not in the specified compute
group. Local quantities are calculated by each processor based on the
atoms it owns, but there may be zero or more per atom, e.g. a list of
bond distances. Computes that produce per-atom quantities have the
word "atom" in their style, e.g. *ke/atom*\ . Computes that produce
local quantities have the word "local" in their style,
e.g. *bond/local*\ . Styles with neither "atom" or "local" in their
atoms it owns, but there may be zero or more per atom (e.g., a list of
bond distances). Computes that produce per-atom quantities have the
word "atom" in their style (e.g., *ke/atom*\ ). Computes that produce
local quantities have the word "local" in their style
(e.g., *bond/local*\ ). Styles with neither "atom" or "local" in their
style produce global quantities.
Note that a single compute can produce either global or per-atom or
@ -64,8 +64,8 @@ compute page will explain.
Global, per-atom, and local quantities each come in three kinds: a
single scalar value, a vector of values, or a 2d array of values. The
doc page for each compute describes the style and kind of values it
produces, e.g. a per-atom vector. Some computes produce more than one
kind of a single style, e.g. a global scalar and a global vector.
produces (e.g., a per-atom vector). Some computes produce more than one
kind of a single style (e.g., a global scalar and a global vector).
When a compute quantity is accessed, as in many of the output commands
discussed below, it can be referenced via the following bracket
@ -80,14 +80,14 @@ notation, where ID is the ID of the compute:
+-------------+--------------------------------------------+
In other words, using one bracket reduces the dimension of the
quantity once (vector -> scalar, array -> vector). Using two brackets
reduces the dimension twice (array -> scalar). Thus a command that
uses scalar compute values as input can also process elements of a
quantity once (vector :math:`\to` scalar, array :math:`\to` vector). Using two
brackets reduces the dimension twice (array :math:`\to` scalar). Thus a
command that uses scalar compute values as input can also process elements of a
vector or array.
Note that commands and :doc:`variables <variable>` which use compute
quantities typically do not allow for all kinds, e.g. a command may
require a vector of values, not a scalar. This means there is no
quantities typically do not allow for all kinds (e.g., a command may
require a vector of values, not a scalar). This means there is no
ambiguity about referring to a compute quantity as c_ID even if it
produces, for example, both a scalar and vector. The doc pages for
various commands explain the details.
@ -111,14 +111,14 @@ ways:
The results of computes that calculate global quantities can be either
"intensive" or "extensive" values. Intensive means the value is
independent of the number of atoms in the simulation,
e.g. temperature. Extensive means the value scales with the number of
atoms in the simulation, e.g. total rotational kinetic energy.
independent of the number of atoms in the simulation
(e.g., temperature). Extensive means the value scales with the number of
atoms in the simulation (e.g., total rotational kinetic energy).
:doc:`Thermodynamic output <thermo_style>` will normalize extensive
values by the number of atoms in the system, depending on the
"thermo_modify norm" setting. It will not normalize intensive values.
If a compute value is accessed in another way, e.g. by a
:doc:`variable <variable>`, you may want to know whether it is an
If a compute value is accessed in another way (e.g., by a
:doc:`variable <variable>`), you may want to know whether it is an
intensive or extensive value. See the page for individual
computes for further info.
@ -187,8 +187,8 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`cluster/atom <compute_cluster_atom>` - cluster ID for each atom
* :doc:`cna/atom <compute_cna_atom>` - common neighbor analysis (CNA) for each atom
* :doc:`cnp/atom <compute_cnp_atom>` - common neighborhood parameter (CNP) for each atom
* :doc:`com <compute_com>` - center-of-mass of group of atoms
* :doc:`com/chunk <compute_com_chunk>` - center-of-mass for each chunk
* :doc:`com <compute_com>` - center of mass of group of atoms
* :doc:`com/chunk <compute_com_chunk>` - center of mass for each chunk
* :doc:`contact/atom <compute_contact_atom>` - contact count for each spherical particle
* :doc:`coord/atom <compute_coord_atom>` - coordination number for each atom
* :doc:`damage/atom <compute_damage_atom>` - Peridynamic damage for each atom
@ -198,10 +198,10 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`dipole <compute_dipole>` - dipole vector and total dipole
* :doc:`dipole/chunk <compute_dipole_chunk>` - dipole vector and total dipole for each chunk
* :doc:`displace/atom <compute_displace_atom>` - displacement of each atom
* :doc:`dpd <compute_dpd>` -
* :doc:`dpd/atom <compute_dpd_atom>` -
* :doc:`dpd <compute_dpd>` - total values of internal conductive energy, internal mechanical energy, chemical energy, and harmonic average of internal temperature
* :doc:`dpd/atom <compute_dpd_atom>` - per-particle values of internal conductive energy, internal mechanical energy, chemical energy, and internal temperature
* :doc:`edpd/temp/atom <compute_edpd_temp_atom>` - per-atom temperature for each eDPD particle in a group
* :doc:`efield/atom <compute_efield_atom>` -
* :doc:`efield/atom <compute_efield_atom>` - electric field at each atom
* :doc:`entropy/atom <compute_entropy_atom>` - pair entropy fingerprint of each atom
* :doc:`erotate/asphere <compute_erotate_asphere>` - rotational energy of aspherical particles
* :doc:`erotate/rigid <compute_erotate_rigid>` - rotational energy of rigid bodies
@ -213,7 +213,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`fep/ta <compute_fep_ta>` - compute free energies for a test area perturbation
* :doc:`force/tally <compute_tally>` - force between two groups of atoms via the tally callback mechanism
* :doc:`fragment/atom <compute_cluster_atom>` - fragment ID for each atom
* :doc:`global/atom <compute_global_atom>` -
* :doc:`global/atom <compute_global_atom>` - assign global values to each atom from arrays of global values
* :doc:`group/group <compute_group_group>` - energy/force between two groups of atoms
* :doc:`gyration <compute_gyration>` - radius of gyration of group of atoms
* :doc:`gyration/chunk <compute_gyration_chunk>` - radius of gyration for each chunk
@ -232,7 +232,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`ke/atom/eff <compute_ke_atom_eff>` - per-atom translational and radial kinetic energy in the electron force field model
* :doc:`ke/eff <compute_ke_eff>` - kinetic energy of a group of nuclei and electrons in the electron force field model
* :doc:`ke/rigid <compute_ke_rigid>` - translational kinetic energy of rigid bodies
* :doc:`mliap <compute_mliap>` - gradients of energy and forces w.r.t. model parameters and related quantities for training machine learning interatomic potentials
* :doc:`mliap <compute_mliap>` - gradients of energy and forces with respect to model parameters and related quantities for training machine learning interatomic potentials
* :doc:`momentum <compute_momentum>` - translational momentum
* :doc:`msd <compute_msd>` - mean-squared displacement of group of atoms
* :doc:`msd/chunk <compute_msd_chunk>` - mean-squared displacement for each chunk
@ -254,36 +254,38 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`property/chunk <compute_property_chunk>` - extract various per-chunk attributes
* :doc:`property/local <compute_property_local>` - convert local attributes to localvectors/arrays
* :doc:`ptm/atom <compute_ptm_atom>` - determines the local lattice structure based on the Polyhedral Template Matching method
* :doc:`rdf <compute_rdf>` - radial distribution function g(r) histogram of group of atoms
* :doc:`rdf <compute_rdf>` - radial distribution function :math:`g(r)` histogram of group of atoms
* :doc:`reduce <compute_reduce>` - combine per-atom quantities into a single global value
* :doc:`reduce/chunk <compute_reduce_chunk>` - reduce per-atom quantities within each chunk
* :doc:`reduce/region <compute_reduce>` - same as compute reduce, within a region
* :doc:`rigid/local <compute_rigid_local>` - extract rigid body attributes
* :doc:`saed <compute_saed>` - electron diffraction intensity on a mesh of reciprocal lattice nodes
* :doc:`slice <compute_slice>` - extract values from global vector or array
* :doc:`smd/contact/radius <compute_smd_contact_radius>` -
* :doc:`smd/contact/radius <compute_smd_contact_radius>` - contact radius for Smooth Mach Dynamics
* :doc:`smd/damage <compute_smd_damage>` - damage status of SPH particles in Smooth Mach Dynamics
* :doc:`smd/hourglass/error <compute_smd_hourglass_error>` -
* :doc:`smd/hourglass/error <compute_smd_hourglass_error>` - error associated with approximated relative separation in Smooth Mach Dynamics
* :doc:`smd/internal/energy <compute_smd_internal_energy>` - per-particle enthalpy in Smooth Mach Dynamics
* :doc:`smd/plastic/strain <compute_smd_plastic_strain>` - equivalent plastic strain per particle in Smooth Mach Dynamics
* :doc:`smd/plastic/strain/rate <compute_smd_plastic_strain_rate>` - time rate of the equivalent plastic strain in Smooth Mach Dynamics
* :doc:`smd/rho <compute_smd_rho>` - per-particle mass density in Smooth Mach Dynamics
* :doc:`smd/tlsph/defgrad <compute_smd_tlsph_defgrad>` - deformation gradient in Smooth Mach Dynamics
* :doc:`smd/tlsph/dt <compute_smd_tlsph_dt>` - CFL-stable time increment per particle in Smooth Mach Dynamics
* :doc:`smd/tlsph/num/neighs <compute_smd_tlsph_num_neighs>` -
* :doc:`smd/tlsph/shape <compute_smd_tlsph_shape>` -
* :doc:`smd/tlsph/strain <compute_smd_tlsph_strain>` -
* :doc:`smd/tlsph/strain/rate <compute_smd_tlsph_strain_rate>` -
* :doc:`smd/tlsph/num/neighs <compute_smd_tlsph_num_neighs>` - number of particles inside the smoothing kernel radius for Smooth Mach Dynamics
* :doc:`smd/tlsph/shape <compute_smd_tlsph_shape>` - current shape of the volume of a particle for Smooth Mach Dynamics
* :doc:`smd/tlsph/strain <compute_smd_tlsph_strain>` - Green--Lagrange strain tensor for Smooth Mach Dynamics
* :doc:`smd/tlsph/strain/rate <compute_smd_tlsph_strain_rate>` - rate of strain for Smooth Mach Dynamics
* :doc:`smd/tlsph/stress <compute_smd_tlsph_stress>` - per-particle Cauchy stress tensor for SPH particles
* :doc:`smd/triangle/vertices <compute_smd_triangle_vertices>` -
* :doc:`smd/triangle/vertices <compute_smd_triangle_vertices>` - coordinates of vertices corresponding to the triangle elements of a mesh for Smooth Mach Dynamics
* :doc:`smd/ulsph/effm <compute_smd_ulsph_effm>` - per-particle effective shear modulus
* :doc:`smd/ulsph/num/neighs <compute_smd_ulsph_num_neighs>` -
* :doc:`smd/ulsph/strain <compute_smd_ulsph_strain>` -
* :doc:`smd/ulsph/strain/rate <compute_smd_ulsph_strain_rate>` -
* :doc:`smd/ulsph/num/neighs <compute_smd_ulsph_num_neighs>` - number of neighbor particles inside the smoothing kernel radius for Smooth Mach Dynamics
* :doc:`smd/ulsph/strain <compute_smd_ulsph_strain>` - logarithmic strain tensor for Smooth Mach Dynamics
* :doc:`smd/ulsph/strain/rate <compute_smd_ulsph_strain_rate>` - logarithmic strain rate for Smooth Mach Dynamics
* :doc:`smd/ulsph/stress <compute_smd_ulsph_stress>` - per-particle Cauchy stress tensor and von Mises equivalent stress in Smooth Mach Dynamics
* :doc:`smd/vol <compute_smd_vol>` - per-particle volumes and their sum in Smooth Mach Dynamics
* :doc:`snap <compute_sna_atom>` - gradients of SNAP energy and forces w.r.t. linear coefficients and related quantities for fitting SNAP potentials
* :doc:`snap <compute_sna_atom>` - gradients of SNAP energy and forces with respect to linear coefficients and related quantities for fitting SNAP potentials
* :doc:`sna/atom <compute_sna_atom>` - bispectrum components for each atom
* :doc:`sna/grid <compute_sna_atom>` - global array of bispectrum components on a regular grid
* :doc:`sna/grid/local <compute_sna_atom>` - local array of bispectrum components on a regular grid
* :doc:`snad/atom <compute_sna_atom>` - derivative of bispectrum components for each atom
* :doc:`snav/atom <compute_sna_atom>` - virial contribution from bispectrum components for each atom
* :doc:`sph/e/atom <compute_sph_e_atom>` - per-atom internal energy of Smooth-Particle Hydrodynamics atoms
@ -306,7 +308,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`temp/cs <compute_temp_cs>` - temperature based on the center-of-mass velocity of atom pairs that are bonded to each other
* :doc:`temp/deform <compute_temp_deform>` - temperature excluding box deformation velocity
* :doc:`temp/deform/eff <compute_temp_deform_eff>` - temperature excluding box deformation velocity in the electron force field model
* :doc:`temp/drude <compute_temp_drude>` - temperature of Core-Drude pairs
* :doc:`temp/drude <compute_temp_drude>` - temperature of Core--Drude pairs
* :doc:`temp/eff <compute_temp_eff>` - temperature of a group of nuclei and electrons in the electron force field model
* :doc:`temp/partial <compute_temp_partial>` - temperature excluding one or more dimensions of velocity
* :doc:`temp/profile <compute_temp_profile>` - temperature excluding a binned velocity profile
@ -322,7 +324,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`vcm/chunk <compute_vcm_chunk>` - velocity of center-of-mass for each chunk
* :doc:`viscosity/cos <compute_viscosity_cos>` - velocity profile under cosine-shaped acceleration
* :doc:`voronoi/atom <compute_voronoi_atom>` - Voronoi volume and neighbors for each atom
* :doc:`xrd <compute_xrd>` - x-ray diffraction intensity on a mesh of reciprocal lattice nodes
* :doc:`xrd <compute_xrd>` - X-ray diffraction intensity on a mesh of reciprocal lattice nodes
Restrictions
""""""""""""
@ -331,7 +333,9 @@ Restrictions
Related commands
""""""""""""""""
:doc:`uncompute <uncompute>`, :doc:`compute_modify <compute_modify>`, :doc:`fix ave/atom <fix_ave_atom>`, :doc:`fix ave/time <fix_ave_time>`, :doc:`fix ave/histo <fix_ave_histo>`
:doc:`uncompute <uncompute>`, :doc:`compute_modify <compute_modify>`,
:doc:`fix ave/atom <fix_ave_atom>`, :doc:`fix ave/time <fix_ave_time>`,
:doc:`fix ave/histo <fix_ave_histo>`
Default
"""""""

4
doc/src/compute_ackland_atom.rst
View File

@ -6,7 +6,7 @@ compute ackland/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID ackland/atom keyword/value
@ -17,7 +17,7 @@ Syntax
.. parsed-literal::
*legacy* yes/no = use (\ *yes*\ ) or do not use (\ *no*\ ) legacy ackland algorithm implementation
*legacy* args = *yes* or *no* = use (\ *yes*\ ) or do not use (\ *no*\ ) legacy Ackland algorithm implementation
Examples
""""""""

16
doc/src/compute_adf.rst
View File

@ -6,7 +6,7 @@ compute adf command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID adf Nbin itype1 jtype1 ktype1 Rjinner1 Rjouter1 Rkinner1 Rkouter1 ...
@ -16,10 +16,10 @@ Syntax
* itypeN = central atom type for Nth ADF histogram (see asterisk form below)
* jtypeN = J atom type for Nth ADF histogram (see asterisk form below)
* ktypeN = K atom type for Nth ADF histogram (see asterisk form below)
* RjinnerN = inner radius of J atom shell for Nth ADF histogram (distance units)
* RjouterN = outer radius of J atom shell for Nth ADF histogram (distance units)
* RjinnerN = inner radius of J atom shell for Nth ADF histogram (distance units)
* RjouterN = outer radius of J atom shell for Nth ADF histogram (distance units)
* RkinnerN = inner radius of K atom shell for Nth ADF histogram (distance units)
* RkouterN = outer radius of K atom shell for Nth ADF histogram (distance units)
* RkouterN = outer radius of K atom shell for Nth ADF histogram (distance units)
* zero or one keyword/value pairs may be appended
* keyword = *ordinate*
@ -177,8 +177,8 @@ Output info
"""""""""""
This compute calculates a global array with the number of rows =
*Nbins*, and the number of columns = 1 + 2\*Ntriples, where Ntriples is the
number of I,J,K triples specified. The first column has the bin
*Nbins* and the number of columns = :math:`1 + 2 \times` *Ntriples*, where *Ntriples*
is the number of I,J,K triples specified. The first column has the bin
coordinate (angle-related ordinate at midpoint of bin). Each subsequent column has
the two ADF values for a specific set of (\ *itypeN*,\ *jtypeN*,\ *ktypeN*\ )
interactions, as described above. These values can be used
@ -192,10 +192,10 @@ The first column of array values is the angle-related ordinate, either
the angle in degrees or radians, or the cosine of the angle. Each
subsequent pair of columns gives the first and second kinds of ADF
for a specific set of (\ *itypeN*,\ *jtypeN*,\ *ktypeN*\ ). The values
in the first ADF column are normalized numbers >= 0.0,
in the first ADF column are normalized numbers :math:`\ge 0.0`,
whose integral w.r.t. the ordinate is 1,
i.e. the first ADF is a normalized probability distribution.
The values in the second ADF column are also numbers >= 0.0.
The values in the second ADF column are also numbers :math:`\ge 0.0`.
They are the cumulative density distribution of angles per atom.
By definition, this ADF is monotonically increasing from zero to
a maximum value equal to the average total number of

14
doc/src/compute_angle.rst
View File

@ -6,7 +6,7 @@ compute angle command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID angle
@ -35,12 +35,12 @@ the hybrid sub-styles.
Output info
"""""""""""
This compute calculates a global vector of length N where N is the number of
sub_styles defined by the :doc:`angle_style hybrid <angle_style>` command,
which can be accessed by indices 1-N. These values can be used by any command
that uses global scalar or vector values from a compute as input. See the
:doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
options.
This compute calculates a global vector of length *N*, where *N* is the number
of sub_styles defined by the :doc:`angle_style hybrid <angle_style>` command,
which can be accessed by indices 1 through *N*. These values can be used by
any command that uses global scalar or vector values from a compute as input.
See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS
output options.
The vector values are "extensive" and will be in energy
:doc:`units <units>`.

23
doc/src/compute_angle_local.rst
View File

@ -6,7 +6,7 @@ compute angle/local command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID angle/local value1 value2 ... keyword args ...
@ -47,7 +47,7 @@ interactions. The number of datums generated, aggregated across all
processors, equals the number of angles in the system, modified by the
group parameter as explained below.
The value *theta* is the angle for the 3 atoms in the interaction.
The value *theta* is the angle for the three atoms in the interaction.
The value *eng* is the interaction energy for the angle.
@ -65,8 +65,8 @@ Note that the value of theta for each angle which stored in the
internal variable is in radians, not degrees.
As an example, these commands can be added to the bench/in.rhodo
script to compute the cosine and cosine\^2 of every angle in the system
and output the statistics in various ways:
script to compute the cosine and cosine-squared of every angle in the
system and output the statistics in various ways:
.. code-block:: LAMMPS
@ -83,19 +83,20 @@ and output the statistics in various ways:
fix 10 all ave/histo 10 10 100 -1 1 20 c_2[3] mode vector file tmp.histo
The :doc:`dump local <dump>` command will output the energy, angle,
cosine(angle), cosine\^2(angle) for every angle in the system. The
:doc:`thermo_style <thermo_style>` command will print the average of
those quantities via the :doc:`compute reduce <compute_reduce>` command
with thermo output. And the :doc:`fix ave/histo <fix_ave_histo>`
command will histogram the cosine(angle) values and write them to a
The :doc:`dump local <dump>` command will output the potential energy
(:math:`\phi`), the angle (:math:`\theta`), :math:`\cos(\theta`), and
:math:`\cos^2(\theta)` for every angle :math:`\theta` in the system.
The :doc:`thermo_style <thermo_style>` command will print the
average of those quantities via the :doc:`compute reduce <compute_reduce>`
command with thermo output. And the :doc:`fix ave/histo <fix_ave_histo>`
command will histogram the :math:`\cos(\theta)` values and write them to a
file.
----------
The local data stored by this command is generated by looping over all
the atoms owned on a processor and their angles. An angle will only
be included if all 3 atoms in the angle are in the specified compute
be included if all three atoms in the angle are in the specified compute
group. Any angles that have been broken (see the
:doc:`angle_style <angle_style>` command) by setting their angle type to
0 are not included. Angles that have been turned off (see the :doc:`fix shake <fix_shake>` or :doc:`delete_bonds <delete_bonds>` commands) by

8
doc/src/compute_angmom_chunk.rst
View File

@ -6,7 +6,7 @@ compute angmom/chunk command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID angmom/chunk chunkID
@ -72,13 +72,13 @@ Output info
"""""""""""
This compute calculates a global array where the number of rows = the
number of chunks *Nchunk* as calculated by the specified :doc:`compute chunk/atom <compute_chunk_atom>` command. The number of columns =
3 for the 3 xyz components of the angular momentum for each chunk.
number of chunks *Nchunk* as calculated by the specified :doc:`compute chunk/atom <compute_chunk_atom>` command. The number of columns = 3 for the three
(*x*, *y*, *z*) components of the angular momentum for each chunk.
These values can be accessed by any command that uses global array
values from a compute as input. See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
options.
The array values are "intensive". The array values will be in
The array values are "intensive." The array values will be in
mass-velocity-distance :doc:`units <units>`.
Restrictions

63
doc/src/compute_ave_sphere_atom.rst
View File

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

8
doc/src/compute_basal_atom.rst
View File

@ -6,7 +6,7 @@ compute basal/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID basal/atom
@ -47,12 +47,12 @@ in examples/PACKAGES/basal.
Output info
"""""""""""
This compute calculates a per-atom array with 3 columns, which can be
accessed by indices 1-3 by any command that uses per-atom values from
This compute calculates a per-atom array with three columns, which can be
accessed by indices 1--3 by any command that uses per-atom values from
a compute as input. See the :doc:`Howto output <Howto_output>` doc page
for an overview of LAMMPS output options.
The per-atom vector values are unitless since the 3 columns represent
The per-atom vector values are unitless since the three columns represent
components of a unit vector.
Restrictions

14
doc/src/compute_body_local.rst
View File

@ -6,7 +6,7 @@ compute body/local command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID body/local input1 input2 ...
@ -33,7 +33,7 @@ Description
"""""""""""
Define a computation that calculates properties of individual body
sub-particles. The number of datums generated, aggregated across all
sub-particles. The number of data generated, aggregated across all
processors, equals the number of body sub-particles plus the number of
non-body particles in the system, modified by the group parameter as
explained below. See the :doc:`Howto body <Howto_body>` page for
@ -41,8 +41,8 @@ more details on using body particles.
The local data stored by this command is generated by looping over all
the atoms. An atom will only be included if it is in the group. If
the atom is a body particle, then its N sub-particles will be looped
over, and it will contribute N datums to the count of datums. If it
the atom is a body particle, then its :math:`N` sub-particles will be looped
over, and it will contribute :math:`N` data to the count of data. If it
is not a body particle, it will contribute 1 datum.
For both body particles and non-body particles, the *id* keyword
@ -64,8 +64,8 @@ by the :doc:`atom_style body <atom_style>`, determines how many fields
exist and what they are. See the :doc:`Howto_body <Howto_body>` doc
page for details of the different styles.
Here is an example of how to output body information using the :doc:`dump local <dump>` command with this compute. If fields 1,2,3 for the
body sub-particles are x,y,z coordinates, then the dump file will be
Here is an example of how to output body information using the :doc:`dump local <dump>` command with this compute. If fields 1, 2, and 3 for the
body sub-particles are (*x*, *y*, *z*) coordinates, then the dump file will be
formatted similar to the output of a :doc:`dump atom or custom <dump>`
command.
@ -79,7 +79,7 @@ Output info
This compute calculates a local vector or local array depending on the
number of keywords. The length of the vector or number of rows in the
array is the number of datums as described above. If a single keyword
array is the number of data as described above. If a single keyword
is specified, a local vector is produced. If two or more keywords are
specified, a local array is produced where the number of columns = the
number of keywords. The vector or array can be accessed by any

11
doc/src/compute_bond.rst
View File

@ -6,7 +6,7 @@ compute bond command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID bond
@ -35,10 +35,13 @@ or more of the hybrid sub-styles.
Output info
"""""""""""
This compute calculates a global vector of length N where N is the
number of sub_styles defined by the :doc:`bond_style hybrid <bond_style>` command, which can be accessed by indices 1-N.
This compute calculates a global vector of length :math:`N`, where :math:`N`
is the number of sub_styles defined by the
:doc:`bond_style hybrid <bond_style>` command,
which can be accessed by indices 1 through :math:`N`.
These values can be used by any command that uses global scalar or
vector values from a compute as input. See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
vector values from a compute as input. See the
:doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
options.
The vector values are "extensive" and will be in energy

54
doc/src/compute_bond_local.rst
View File

@ -6,7 +6,7 @@ compute bond/local command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID bond/local value1 value2 ... keyword args ...
@ -36,8 +36,8 @@ Syntax
.. parsed-literal::
*set* args = dist name
dist = only currently allowed arg
*set* args = *dist* name
*dist* = only currently allowed arg
name = name of variable to set with distance (dist)
Examples
@ -50,7 +50,7 @@ Examples
compute 1 all bond/local dist fx fy fz b1 b2
compute 1 all angle/local dist v_distsq set dist d
compute 1 all bond/local dist v_distsq set dist d
Description
"""""""""""
@ -83,32 +83,34 @@ relative to the center of mass (COM) velocity of the 2 atoms in the
bond.
The value *engvib* is the vibrational kinetic energy of the two atoms
in the bond, which is simply 1/2 m1 v1\^2 + 1/2 m2 v2\^2, where v1 and
v2 are the magnitude of the velocity of the 2 atoms along the bond
direction, after the COM velocity has been subtracted from each.
The value *engrot* is the rotational kinetic energy of the two atoms
in the bond, which is simply 1/2 m1 v1\^2 + 1/2 m2 v2\^2, where v1 and
v2 are the magnitude of the velocity of the 2 atoms perpendicular to
the bond direction, after the COM velocity has been subtracted from
in the bond, which is simply :math:`\frac12 m_1 v_1^2 + \frac12 m_2 v_2^2,`
where :math:`v_1` and :math:`v_2` are the magnitude of the velocity of the two
atoms along the bond direction, after the COM velocity has been subtracted from
each.
The value *engtrans* is the translational kinetic energy associated
with the motion of the COM of the system itself, namely 1/2 (m1+m2)
Vcm\^2 where Vcm = magnitude of the velocity of the COM.
The value *engrot* is the rotational kinetic energy of the two atoms
in the bond, which is simply :math:`\frac12 m_1 v_1^2 + \frac12 m_2 v_2^2,`
where :math:`v_1` and :math:`v_2` are the magnitude of the velocity of the two
atoms perpendicular to the bond direction, after the COM velocity has been
subtracted from each.
Note that these 3 kinetic energy terms are simply a partitioning of
the summed kinetic energy of the 2 atoms themselves. I.e. total KE =
1/2 m1 v1\^2 + 1/2 m2 v2\^2 = engvib + engrot + engtrans, where v1,v2
are the magnitude of the velocities of the 2 atoms, without any
adjustment for the COM velocity.
The value *engtrans* is the translational kinetic energy associated
with the motion of the COM of the system itself, namely :math:`\frac12(m_1+m_2)
V_{\mathrm{cm}}^2`, where `Vcm` = magnitude of the velocity of the COM.
Note that these three kinetic energy terms are simply a partitioning of
the summed kinetic energy of the two atoms themselves. That is, the total
kinetic energy is
:math:`\frac12 m_1 v_1^2 + \frac12 m_2 v_2^2` = engvib + engrot + engtrans,
where :math:`v_1` and :math:`v_2` are the magnitude of the velocities of the
two atoms, without any adjustment for the COM velocity.
The value *omega* is the magnitude of the angular velocity of the
two atoms around their COM position.
The value *velvib* is the magnitude of the relative velocity of the
two atoms in the bond towards each other. A negative value means the
2 atoms are moving toward each other; a positive value means they are
two atoms are moving toward each other; a positive value means they are
moving apart.
The value *v_name* can be used together with the *set* keyword to
@ -122,7 +124,7 @@ directly. The *set* keyword is used to identify the name of this
other variable associated with theta.
As an example, these commands can be added to the bench/in.rhodo
script to compute the distance\^2 of every bond in the system and
script to compute the length\ :math:`^2` of every bond in the system and
output the statistics in various ways:
.. code-block:: LAMMPS
@ -139,12 +141,12 @@ output the statistics in various ways:
fix 10 all ave/histo 10 10 100 0 6 20 c_2[3] mode vector file tmp.histo
The :doc:`dump local <dump>` command will output the energy, distance,
distance\^2 for every bond in the system. The
The :doc:`dump local <dump>` command will output the energy, length,
and length\ :math:`^2` for every bond in the system. The
:doc:`thermo_style <thermo_style>` command will print the average of
those quantities via the :doc:`compute reduce <compute_reduce>` command
with thermo output. And the :doc:`fix ave/histo <fix_ave_histo>`
command will histogram the distance\^2 values and write them to a file.
with thermo output, and the :doc:`fix ave/histo <fix_ave_histo>`
command will histogram the length\ :math:`^2` values and write them to a file.
A bond style may define additional bond quantities which can be
accessed as *b1* to *bN*, where N is defined by the bond style. Most

28
doc/src/compute_born_matrix.rst
View File

@ -6,20 +6,26 @@ compute born/matrix command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID born/matrix keyword value ...
* ID, group-ID are documented in :doc:`compute <compute>` command
* born/matrix = style name of this compute command
* zero or more keyword/value pairs may be appended
* zero or more keywords or keyword/value pairs may be appended
.. parsed-literal::
keyword = *numdiff*
keyword = *numdiff* or *pair* or *bond* or *angle* or *dihedral* or *improper*
*numdiff* values = delta virial-ID
delta = magnitude of strain (dimensionless)
virial-ID = ID of pressure compute for virial (string)
(*numdiff* cannot be used with any other keyword)
*pair* = compute pair-wise contributions
*bond* = compute bonding contributions
*angle* = compute angle contributions
*dihedral* = compute dihedral contributions
*improper* = compute improper contributions
Examples
""""""""
@ -33,9 +39,11 @@ Examples
Description
"""""""""""
.. versionadded:: 4May2022
Define a compute that calculates
:math:`\frac{\partial{}^2U}{\partial\varepsilon_{i}\partial\varepsilon_{j}}` the
second derivatives of the potential energy :math:`U` w.r.t. strain
:math:`\frac{\partial{}^2U}{\partial\varepsilon_{i}\partial\varepsilon_{j}},` the
second derivatives of the potential energy :math:`U` with respect to the strain
tensor :math:`\varepsilon` elements. These values are related to:
.. math::
@ -67,14 +75,14 @@ whose 21 independent elements are output in this order:
.. math::
\begin{matrix}
\begin{bmatrix}
C_{1} & C_{7} & C_{8} & C_{9} & C_{10} & C_{11} \\
C_{7} & C_{2} & C_{12} & C_{13} & C_{14} & C_{15} \\
\vdots & C_{12} & C_{3} & C_{16} & C_{17} & C_{18} \\
\vdots & C_{13} & C_{16} & C_{4} & C_{19} & C_{20} \\
\vdots & \vdots & \vdots & C_{19} & C_{5} & C_{21} \\
\vdots & \vdots & \vdots & \vdots & C_{21} & C_{6}
\end{matrix}
\end{bmatrix}
in this matrix the indices of :math:`C_{k}` value are the corresponding element
:math:`k` in the global vector output by this compute. Each term comes from the sum
@ -167,14 +175,14 @@ requiring that it use the virial keyword e.g.
**Output info:**
This compute calculates a global vector with 21 values that are
the second derivatives of the potential energy w.r.t. strain.
the second derivatives of the potential energy with respect to strain.
The values are in energy units.
The values are ordered as explained above. These values can be used
by any command that uses global values from a compute as input. See
the :doc:`Howto output <Howto_output>` doc page for an overview of
LAMMPS output options.
The array values calculated by this compute are all "extensive".
The array values calculated by this compute are all "extensive."
Restrictions
""""""""""""
@ -186,7 +194,7 @@ the :doc:`Build package <Build_package>` page for more info.
The Born term can be decomposed as a product of two terms. The first one is a
general term which depends on the configuration. The second one is specific to
every interaction composing your force field (non-bonded, bonds, angle...).
every interaction composing your force field (non-bonded, bonds, angle, ...).
Currently not all LAMMPS interaction styles implement the *born_matrix* method
giving first and second order derivatives and LAMMPS will exit with an error if
this compute is used with such interactions unless the *numdiff* option is

29
doc/src/compute_centro_atom.rst
View File

@ -6,17 +6,17 @@ compute centro/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID centro/atom lattice keyword value ...
* ID, group-ID are documented in :doc:`compute <compute>` command
centro/atom = style name of this compute command
lattice = *fcc* or *bcc* or N = # of neighbors per atom to include
* centro/atom = style name of this compute command
* lattice = *fcc* or *bcc* or N = # of neighbors per atom to include
* zero or more keyword/value pairs may be appended
* keyword = *axes*
.. parsed-literal::
.. parsed-literal::
*axes* value = *no* or *yes*
*no* = do not calculate 3 symmetry axes
@ -83,12 +83,13 @@ atoms with smallest contributions to the centrosymmetry parameter,
i.e. the two most symmetric pairs of atoms. The third vector is
normal to the first two by the right-hand rule. All three vectors are
normalized to unit length. For FCC crystals, the first two vectors
will lie along a <110> direction, while the third vector will lie
along either a <100> or <111> direction. For HCP crystals, the first
two vectors will lie along <1000> directions, while the third vector
will lie along <0001>. This provides a simple way to measure local
orientation in HCP structures. In general, the *axes* keyword can be
used to estimate the orientation of symmetry axes in the neighborhood
will lie along a :math:`\langle110\rangle` direction, while the third vector
will lie along either a :math:`\langle100\rangle` or :math:`\langle111\rangle`
direction. For HCP crystals, the first two vectors will lie along
:math:`\langle1000\rangle` directions, while the third vector
will lie along :math:`\langle0001\rangle`. This provides a simple way to
measure local orientation in HCP structures. In general, the *axes* keyword
can be used to estimate the orientation of symmetry axes in the neighborhood
of any atom.
Only atoms within the cutoff of the pairwise neighbor list are
@ -96,7 +97,7 @@ considered as possible neighbors. Atoms not in the compute group are
included in the :math:`N` neighbors used in this calculation.
The neighbor list needed to compute this quantity is constructed each
time the calculation is performed (e.g. each time a snapshot of atoms
time the calculation is performed (e.g., each time a snapshot of atoms
is dumped). Thus it can be inefficient to compute/dump this quantity
too frequently or to have multiple compute/dump commands, each with a
*centro/atom* style.
@ -111,11 +112,11 @@ options.
If the *axes* keyword setting is *yes*, then a per-atom array is
calculated. The first column is the centrosymmetry parameter. The
next three columns are the x, y, and z components of the first
next three columns are the *x*, *y*, and *z* components of the first
symmetry axis, followed by the second, and third symmetry axes in
columns 5-7 and 8-10.
columns 5--7 and 8--10.
The centrosymmetry values are unitless values >= 0.0. Their magnitude
The centrosymmetry values are unitless values :math:`\ge 0.0`. Their magnitude
depends on the lattice style due to the number of contributing neighbor
pairs in the summation in the formula above. And it depends on the
local defects surrounding the central atom, as described above. For

104
doc/src/compute_chunk_atom.rst
View File

@ -6,7 +6,7 @@ compute chunk/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID chunk/atom style args keyword values ...
@ -15,7 +15,7 @@ Syntax
.. parsed-literal::
style = *bin/1d* or *bin/2d* or *bin/3d* or *bin/sphere* or *type* or *molecule* or c_ID, c_ID[I], f_ID, f_ID[I], v_name
style = *bin/1d* or *bin/2d* or *bin/3d* or *bin/sphere* or *bin/cylinder* or *type* or *molecule* or c_ID, c_ID[I], f_ID, f_ID[I], v_name
*bin/1d* args = dim origin delta
dim = *x* or *y* or *z*
origin = *lower* or *center* or *upper* or coordinate value (distance units)
@ -49,7 +49,7 @@ Syntax
v_name = per-atom vector calculated by an atom-style variable with name
* zero or more keyword/values pairs may be appended
* keyword = *region* or *nchunk* or *static* or *compress* or *bound* or *discard* or *pbc* or *units*
* keyword = *region* or *nchunk* or *limit* or *ids* or *compress* or *discard* or *bound* or *pbc* or *units*
.. parsed-literal::
@ -74,7 +74,7 @@ Syntax
no = keep atoms with out-of-range chunk IDs by assigning a valid chunk ID
mixed = keep or discard such atoms according to spatial binning rule
*bound* values = x/y/z lo hi
x/y/z = *x* or *y* or *z* to bound sptial bins in this dimension
x/y/z = *x* or *y* or *z* to bound spatial bins in this dimension
lo = *lower* or coordinate value (distance units)
hi = *upper* or coordinate value (distance units)
*pbc* value = *no* or *yes*
@ -150,14 +150,14 @@ The *binning* styles perform a spatial binning of atoms, and assign an
atom the chunk ID corresponding to the bin number it is in. *Nchunk*
is set to the number of bins, which can change if the simulation box
size changes. This also depends on the setting of the *units*
keyword; e.g. for *reduced* units the number of chunks may not change
even if the box size does.
keyword (e.g., for *reduced* units the number of chunks may not change
even if the box size does).
The *bin/1d*, *bin/2d*, and *bin/3d* styles define bins as 1d layers
(slabs), 2d pencils, or 3d boxes. The *dim*, *origin*, and *delta*
settings are specified 1, 2, or 3 times. For 2d or 3d bins, there is
no restriction on specifying dim = x before dim = y or z, or dim = y
before dim = z. Bins in a particular *dim* have a bin size in that
no restriction on specifying dim = *x* before dim = *y* or *z*, or dim = *y*
before dim = *z*. Bins in a particular *dim* have a bin size in that
dimension given by *delta*\ . In each dimension, bins are defined
relative to a specified *origin*, which may be the lower/upper edge of
the simulation box (in that dimension), or its center point, or a
@ -170,10 +170,11 @@ boxes aligned with the xyz coordinate axes. For triclinic
(non-orthogonal) simulation boxes, the bin faces are parallel to the
tilted faces of the simulation box. See the :doc:`Howto triclinic <Howto_triclinic>` page for a discussion of the
geometry of triclinic boxes in LAMMPS. As described there, a tilted
simulation box has edge vectors a,b,c. In that nomenclature, bins in
the x dimension have faces with normals in the "b" cross "c"
direction. Bins in y have faces normal to the "a" cross "c"
direction. And bins in z have faces normal to the "a" cross "b"
simulation box has edge vectors :math:`\vec a`, :math:`\vec b`, and
:math:`\vec c`. In that nomenclature, bins in
the *x* dimension have faces with normals in the :math:`\vec b \times \vec c`
direction, bins in *y* have faces normal to the :math:`\vec a \times \vec c`
direction, and bins in *z* have faces normal to the :math:`\vec a \times \vec b`
direction. Note that in order to define the size and position of
these bins in an unambiguous fashion, the *units* option must be set
to *reduced* when using a triclinic simulation box, as noted below.
@ -181,46 +182,46 @@ to *reduced* when using a triclinic simulation box, as noted below.
The meaning of *origin* and *delta* for triclinic boxes is as follows.
Consider a triclinic box with bins that are 1d layers or slabs in the
x dimension. No matter how the box is tilted, an *origin* of 0.0
means start layers at the lower "b" cross "c" plane of the simulation
box and an *origin* of 1.0 means to start layers at the upper "b"
cross "c" face of the box. A *delta* value of 0.1 in *reduced* units
means there will be 10 layers from 0.0 to 1.0, regardless of the
current size or shape of the simulation box.
means start layers at the lower :math:`\vec b \times \vec c` plane of the
simulation box and an *origin* of 1.0 means to start layers at the upper
:math:`\vec b \times \vec c` face of the box. A *delta* value of 0.1 in
*reduced* units means there will be 10 layers from 0.0 to 1.0, regardless of
the current size or shape of the simulation box.
The *bin/sphere* style defines a set of spherical shell bins around
the origin (\ *xorig*,\ *yorig*,\ *zorig*\ ), using *nsbin* bins with radii
equally spaced between *srmin* and *srmax*\ . This is effectively a 1d
vector of bins. For example, if *srmin* = 1.0 and *srmax* = 10.0 and
*nsbin* = 9, then the first bin spans 1.0 < r < 2.0, and the last bin
spans 9.0 < r 10.0. The geometry of the bins is the same whether the
simulation box is orthogonal or triclinic; i.e. the spherical shells
*nsbin* = 9, then the first bin spans :math:`1.0 < r < 2.0`, and the last bin
spans :math:`9.0 < r < 10.0`. The geometry of the bins is the same whether the
simulation box is orthogonal or triclinic (i.e., the spherical shells
are not tilted or scaled differently in different dimensions to
transform them into ellipsoidal shells.
transform them into ellipsoidal shells).
The *bin/cylinder* style defines bins for a cylinder oriented along
the axis *dim* with the axis coordinates in the other two radial
dimensions at (\ *c1*,\ *c2*\ ). For dim = x, c1/c2 = y/z; for dim = y,
c1/c2 = x/z; for dim = z, c1/c2 = x/y. This is effectively a 2d array
of bins. The first dimension is along the cylinder axis, the second
dimension is radially outward from the cylinder axis. The bin size
and positions along the cylinder axis are specified by the *origin*
and *delta* values, the same as for the *bin/1d*, *bin/2d*, and
*bin/3d* styles. There are *ncbin* concentric circle bins in the
dimensions at (\ *c1*,\ *c2*\ ). For dim = *x*, :math:`c_1/c_2 = y/z`;
for dim = *y*, :math:`c_1/c_2 = x/z`; for dim = *z*,
:math:`c_1/c_2 = x/y`. This is effectively a 2d array of bins. The first
dimension is along the cylinder axis, the second dimension is radially outward
from the cylinder axis. The bin size and positions along the cylinder axis are
specified by the *origin* and *delta* values, the same as for the *bin/1d*,
*bin/2d*, and *bin/3d* styles. There are *ncbin* concentric circle bins in the
radial direction from the cylinder axis with radii equally spaced
between *crmin* and *crmax*\ . For example, if *crmin* = 1.0 and
*crmax* = 10.0 and *ncbin* = 9, then the first bin spans 1.0 < r <
2.0, and the last bin spans 9.0 < r 10.0. The geometry of the bins in
*crmax* = 10.0 and *ncbin* = 9, then the first bin spans :math:`1.0 < r < 2.0`
and the last bin spans :math:`9.0 < r < 10.0`. The geometry of the bins in
the radial dimensions is the same whether the simulation box is
orthogonal or triclinic; i.e. the concentric circles are not tilted or
orthogonal or triclinic (i.e., the concentric circles are not tilted or
scaled differently in the two different dimensions to transform them
into ellipses.
into ellipses).
The created bins (and hence the chunk IDs) are numbered consecutively
from 1 to the number of bins = *Nchunk*\ . For *bin2d* and *bin3d*, the
numbering varies most rapidly in the first dimension (which could be
x, y, or z), next rapidly in the second dimension, and most slowly in the
*x*, *y*, or *z*), next rapidly in the second dimension, and most slowly in the
third dimension. For *bin/sphere*, the bin with smallest radii is chunk
1 and the bni with largest radii is chunk Nchunk = *ncbin*\ . For
1 and the bin with largest radii is chunk Nchunk = *ncbin*\ . For
*bin/cylinder*, the numbering varies most rapidly in the dimension
along the cylinder axis and most slowly in the radial direction.
@ -236,8 +237,8 @@ assigned to the atom.
----------
The *type* style uses the atom type as the chunk ID. *Nchunk* is set
to the number of atom types defined for the simulation, e.g. via the
:doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands.
to the number of atom types defined for the simulation (e.g., via the
:doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands).
----------
@ -264,8 +265,8 @@ on a quantity calculated and stored by a compute, fix, or variable.
In each case, it must be a per-atom quantity. In each case the
referenced floating point values are converted to an integer chunk ID
as follows. The floating point value is truncated (rounded down) to
an integer value. If the integer value is <= 0, then a chunk ID of 0
is assigned to the atom. If the integer value is > 0, it becomes the
an integer value. If the integer value is :math:`\le 0`, then a chunk ID of 0
is assigned to the atom. If the integer value is :math:`> 0`, it becomes the
chunk ID to the atom. *Nchunk* is set to the largest chunk ID. Note
that this excludes atoms which are not in the specified group or
optional region.
@ -362,7 +363,7 @@ If *limit* is set to *Nc* = 0, then no limit is imposed on *Nchunk*,
though the *compress* keyword can still be used to reduce *Nchunk*, as
described below.
If *Nc* > 0, then the effect of the *limit* keyword depends on whether
If *Nc* :math:`>` 0, then the effect of the *limit* keyword depends on whether
the *compress* keyword is also used with a setting of *yes*, and
whether the *compress* keyword is specified before the *limit* keyword
or after.
@ -374,7 +375,7 @@ First, here is what occurs if *compress yes* is not set. If *limit*
is set to *Nc max*, then *Nchunk* is reset to the smaller of *Nchunk*
and *Nc*\ . If *limit* is set to *Nc exact*, then *Nchunk* is reset to
*Nc*, whether the original *Nchunk* was larger or smaller than *Nc*\ .
If *Nchunk* shrank due to the *limit* setting, then atom chunk IDs >
If *Nchunk* shrank due to the *limit* setting, then atom chunk IDs :math:`>`
*Nchunk* will be reset to 0 or *Nchunk*, depending on the setting of
the *discard* keyword. If *Nchunk* grew, there will simply be some
chunks with no atoms assigned to them.
@ -384,22 +385,22 @@ If *compress yes* is set, and the *compress* keyword comes before the
described below, which resets *Nchunk*\ . The *limit* keyword is then
applied to the new *Nchunk* value, exactly as described in the
preceding paragraph. Note that in this case, all atoms will end up
with chunk IDs <= *Nc*, but their original values (e.g. molecule ID or
compute/fix/variable) may have been > *Nc*, because of the compression
operation.
with chunk IDs :math:`\le` *Nc*, but their original values (e.g., molecule ID
or compute/fix/variable) may have been :math:`>` *Nc*, because of the
compression operation.
If *compress yes* is set, and the *compress* keyword comes after the
*limit* keyword, then the *limit* value of *Nc* is applied first to
the uncompressed value of *Nchunk*, but only if *Nc* < *Nchunk*
the uncompressed value of *Nchunk*, but only if *Nc* :math:`<` *Nchunk*
(whether *Nc max* or *Nc exact* is used). This effectively means all
atoms with chunk IDs > *Nc* have their chunk IDs reset to 0 or *Nc*,
atoms with chunk IDs :math:`>` *Nc* have their chunk IDs reset to 0 or *Nc*,
depending on the setting of the *discard* keyword. The compression
operation is then performed, which may shrink *Nchunk* further. If
the new *Nchunk* < *Nc* and *limit* = *Nc exact* is specified, then
the new *Nchunk* :math:`<` *Nc* and *limit* = *Nc exact* is specified, then
*Nchunk* is reset to *Nc*, which results in extra chunks with no atoms
assigned to them. Note that in this case, all atoms will end up with
chunk IDs <= *Nc*, and their original values (e.g. molecule ID or
compute/fix/variable value) will also have been <= *Nc*\ .
chunk IDs :math:`\le` *Nc*, and their original values (e.g., molecule ID or
compute/fix/variable value) will also have been :math:`\le` *Nc*\ .
----------
@ -601,7 +602,8 @@ be used. For non-orthogonal (triclinic) simulation boxes, only the
*reduced* option may be used.
A *box* value selects standard distance units as defined by the
:doc:`units <units>` command, e.g. Angstroms for units = real or metal.
:doc:`units <units>` command (e.g., :math:`\mathrm{\mathring A}`
for units = *real* or *metal*).
A *lattice* value means the distance units are in lattice spacings.
The :doc:`lattice <lattice>` command must have been previously used to
define the lattice spacing. A *reduced* value means normalized
@ -615,8 +617,8 @@ scaled by the lattice spacing or reduced value of the *x* dimension.
Note that for the *bin/cylinder* style, the radii *crmin* and *crmax*
are scaled by the lattice spacing or reduced value of the first
dimension perpendicular to the cylinder axis. E.g. y for an x-axis
cylinder, x for a y-axis cylinder, and x for a z-axis cylinder.
dimension perpendicular to the cylinder axis (e.g., *y* for an *x*-axis
cylinder, *x* for a *y*-axis cylinder, and *x* for a *z*-axis cylinder).
----------

10
doc/src/compute_chunk_spread_atom.rst
View File

@ -6,7 +6,7 @@ compute chunk/spread/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID chunk/spread/atom chunkID input1 input2 ...
@ -18,10 +18,10 @@ Syntax
.. parsed-literal::
c_ID = global vector calculated by a compute with ID
c_ID[I] = Ith column of global array calculated by a compute with ID, I can include wildcard (see below)
f_ID = global vector calculated by a fix with ID
f_ID[I] = Ith column of global array calculated by a fix with ID, I can include wildcard (see below)
c_ID = global vector calculated by a compute with ID
c_ID[I] = Ith column of global array calculated by a compute with ID, I can include wildcard (see below)
f_ID = global vector calculated by a fix with ID
f_ID[I] = Ith column of global array calculated by a fix with ID, I can include wildcard (see below)
Examples
""""""""

16
doc/src/compute_cluster_atom.rst
View File

@ -14,7 +14,7 @@ compute aggregate/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID cluster/atom cutoff
compute ID group-ID fragment/atom keyword value ...
@ -69,9 +69,9 @@ fragments or not, based on the *yes* or *no* setting. If the setting
is *no* (the default), their fragment IDs are set to 0.
An aggregate is defined by combining the rules for clusters and
fragments, i.e. a set of atoms, where each of it is within the cutoff
fragments (i.e., a set of atoms, where each of them is within the cutoff
distance from one or more atoms within a fragment that is part of
the same cluster. This measure can be used to track molecular assemblies
the same cluster). This measure can be used to track molecular assemblies
like micelles.
For computes *cluster/atom* and *aggregate/atom* a neighbor list
@ -92,9 +92,9 @@ style computes.
does not apply when using long-range coulomb (\ *coul/long*, *coul/msm*,
*coul/wolf* or similar. One way to get around this would be to set
special_bond scaling factors to very tiny numbers that are not exactly
zero (e.g. 1.0e-50). Another workaround is to write a dump file, and
use the :doc:`rerun <rerun>` command to compute the clusters for
snapshots in the dump file. The rerun script can use a
zero (e.g., :math:`1.0 \times 10^{-50}`). Another workaround is to write a
dump file and use the :doc:`rerun <rerun>` command to compute the clusters
for snapshots in the dump file. The rerun script can use a
:doc:`special_bonds <special_bonds>` command that includes all pairs in
the neighbor list.
@ -114,7 +114,7 @@ any command that uses per-atom values from a compute as input. See
the :doc:`Howto output <Howto_output>` page for an overview of
LAMMPS output options.
The per-atom vector values will be an ID > 0, as explained above.
The per-atom vector values will be an ID :math:`> 0`, as explained above.
Restrictions
""""""""""""
@ -129,5 +129,5 @@ Related commands
Default
"""""""
The default for fragment/atom is single no.
The default for fragment/atom is single=no.

22
doc/src/compute_cna_atom.rst
View File

@ -6,7 +6,7 @@ compute cna/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID cna/atom cutoff
@ -44,20 +44,22 @@ performed on mono-component systems.
The CNA calculation can be sensitive to the specified cutoff value.
You should insure the appropriate nearest neighbors of an atom are
found within the cutoff distance for the presumed crystal structure.
E.g. 12 nearest neighbor for perfect FCC and HCP crystals, 14 nearest
neighbors for perfect BCC crystals. These formulas can be used to
found within the cutoff distance for the presumed crystal structure
(e.g., 12 nearest neighbor for perfect FCC and HCP crystals, 14 nearest
neighbors for perfect BCC crystals). These formulas can be used to
obtain a good cutoff distance:
.. math::
r_{c}^{fcc} = & \frac{1}{2} \left(\frac{\sqrt{2}}{2} + 1\right) \mathrm{a} \simeq 0.8536 \:\mathrm{a} \\
r_{c}^{bcc} = & \frac{1}{2}(\sqrt{2} + 1) \mathrm{a} \simeq 1.207 \:\mathrm{a} \\
r_{c}^{hcp} = & \frac{1}{2}\left(1+\sqrt{\frac{4+2x^{2}}{3}}\right) \mathrm{a}
r_{c}^{\mathrm{fcc}} = & \frac{1}{2} \left(\frac{\sqrt{2}}{2} + 1\right) a
\approx 0.8536 a \\
r_{c}^{\mathrm{bcc}} = & \frac{1}{2}(\sqrt{2} + 1) a
\approx 1.207 a \\
r_{c}^{\mathrm{hcp}} = & \frac{1}{2}\left(1+\sqrt{\frac{4+2x^{2}}{3}}\right) a
where a is the lattice constant for the crystal structure concerned
and in the HCP case, x = (c/a) / 1.633, where 1.633 is the ideal c/a
for HCP crystals.
where :math:`a` is the lattice constant for the crystal structure concerned
and in the HCP case, :math:`x = (c/a) / 1.633`, where 1.633 is the ideal
:math:`c/a` for HCP crystals.
Also note that since the CNA calculation in LAMMPS uses the neighbors
of an owned atom to find the nearest neighbors of a ghost atom, the

28
doc/src/compute_cnp_atom.rst
View File

@ -6,7 +6,7 @@ compute cnp/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID cnp/atom cutoff
@ -28,7 +28,7 @@ Define a computation that calculates the Common Neighborhood
Parameter (CNP) for each atom in the group. In solid-state systems
the CNP is a useful measure of the local crystal structure
around an atom and can be used to characterize whether the
atom is part of a perfect lattice, a local defect (e.g. a dislocation
atom is part of a perfect lattice, a local defect (e.g., a dislocation
or stacking fault), or at a surface.
The value of the CNP parameter will be 0.0 for atoms not in the
@ -40,7 +40,7 @@ This parameter is computed using the following formula from
.. math::
Q_{i} = \frac{1}{n_i}\sum_{j = 1}^{n_i} \left | \sum_{k = 1}^{n_{ij}} \vec{R}_{ik} + \vec{R}_{jk} \right | ^{2}
Q_{i} = \frac{1}{n_i}\sum_{j = 1}^{n_i} \left\lVert \sum_{k = 1}^{n_{ij}} \vec{R}_{ik} + \vec{R}_{jk} \right\rVert^{2}
where the index *j* goes over the :math:`n_i` nearest neighbors of atom
*i*, and the index *k* goes over the :math:`n_{ij}` common nearest neighbors
@ -58,13 +58,15 @@ obtain a good cutoff distance:
.. math::
r_{c}^{fcc} = & \frac{1}{2} \left(\frac{\sqrt{2}}{2} + 1\right) \mathrm{a} \simeq 0.8536 \:\mathrm{a} \\
r_{c}^{bcc} = & \frac{1}{2}(\sqrt{2} + 1) \mathrm{a} \simeq 1.207 \:\mathrm{a} \\
r_{c}^{hcp} = & \frac{1}{2}\left(1+\sqrt{\frac{4+2x^{2}}{3}}\right) \mathrm{a}
r_{c}^{\mathrm{fcc}} = & \frac{1}{2} \left(\frac{\sqrt{2}}{2} + 1\right) a
\approx 0.8536 a \\
r_{c}^{\mathrm{bcc}} = & \frac{1}{2}(\sqrt{2} + 1) a
\approx 1.207 a \\
r_{c}^{\mathrm{hcp}} = & \frac{1}{2}\left(1+\sqrt{\frac{4+2x^{2}}{3}}\right) a
where a is the lattice constant for the crystal structure concerned
and in the HCP case, x = (c/a) / 1.633, where 1.633 is the ideal c/a
for HCP crystals.
where :math:`a` is the lattice constant for the crystal structure concerned
and in the HCP case, :math:`x = (c/a) / 1.633`, where 1.633 is the ideal
:math:`c/a` for HCP crystals.
Also note that since the CNP calculation in LAMMPS uses the neighbors
of an owned atom to find the nearest neighbors of a ghost atom, the
@ -81,7 +83,7 @@ cutoff is the argument used with the compute cnp/atom command. LAMMPS
will issue a warning if this is not the case.
The neighbor list needed to compute this quantity is constructed each
time the calculation is performed (e.g. each time a snapshot of atoms
time the calculation is performed (e.g., each time a snapshot of atoms
is dumped). Thus it can be inefficient to compute/dump this quantity
too frequently or to have multiple compute/dump commands, each with a
*cnp/atom* style.
@ -103,9 +105,9 @@ values:
BCC lattice = 0.0
HCP lattice = 4.4
FCC (111) surface ~ 13.0
FCC (100) surface ~ 26.5
FCC dislocation core ~ 11
FCC (111) surface = 13.0
FCC (100) surface = 26.5
FCC dislocation core = 11
Restrictions
""""""""""""

11
doc/src/compute_com.rst
View File

@ -6,7 +6,7 @@ compute com command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID com
@ -28,7 +28,7 @@ of atoms, including all effects due to atoms passing through periodic
boundaries.
A vector of three quantities is calculated by this compute, which
are the x,y,z coordinates of the center of mass.
are the :math:`(x,y,z)` coordinates of the center of mass.
.. note::
@ -38,17 +38,18 @@ are the x,y,z coordinates of the center of mass.
"unwrapped" coordinates. See the Atoms section of the
:doc:`read_data <read_data>` command for a discussion of image flags and
how they are set for each atom. You can reset the image flags
(e.g. to 0) before invoking this compute by using the :doc:`set image <set>` command.
(e.g., to 0) before invoking this compute by using the
:doc:`set image <set>` command.
Output info
"""""""""""
This compute calculates a global vector of length 3, which can be
accessed by indices 1-3 by any command that uses global vector values
accessed by indices 1--3 by any command that uses global vector values
from a compute as input. See the :doc:`Howto output <Howto_output>` doc
page for an overview of LAMMPS output options.
The vector values are "intensive". The vector values will be in
The vector values are "intensive." The vector values will be in
distance :doc:`units <units>`.
Restrictions

13
doc/src/compute_com_chunk.rst
View File

@ -6,7 +6,7 @@ compute com/chunk command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID com/chunk chunkID
@ -34,7 +34,7 @@ molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_c
doc pages for details of how chunks can be defined and examples of how
they can be used to measure properties of a system.
This compute calculates the x,y,z coordinates of the center-of-mass
This compute calculates the :math:`(x,y,z)` coordinates of the center of mass
for each chunk, which includes all effects due to atoms passing through
periodic boundaries.
@ -54,7 +54,8 @@ non-zero chunk IDs.
for a discussion of "unwrapped" coordinates. See the Atoms section of
the :doc:`read_data <read_data>` command for a discussion of image flags
and how they are set for each atom. You can reset the image flags
(e.g. to 0) before invoking this compute by using the :doc:`set image <set>` command.
(e.g., to 0) before invoking this compute by using the
:doc:`set image <set>` command.
The simplest way to output the results of the compute com/chunk
calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
@ -70,13 +71,13 @@ Output info
"""""""""""
This compute calculates a global array where the number of rows = the
number of chunks *Nchunk* as calculated by the specified :doc:`compute chunk/atom <compute_chunk_atom>` command. The number of columns =
3 for the x,y,z center-of-mass coordinates of each chunk. These
number of chunks *Nchunk* as calculated by the specified :doc:`compute chunk/atom <compute_chunk_atom>` command. The number of columns is
3 for the :math:`(x,y,z)` center-of-mass coordinates of each chunk. These
values can be accessed by any command that uses global array values
from a compute as input. See the :doc:`Howto output <Howto_output>` doc
page for an overview of LAMMPS output options.
The array values are "intensive". The array values will be in
The array values are "intensive." The array values will be in
distance :doc:`units <units>`.
Restrictions

14
doc/src/compute_contact_atom.rst
View File

@ -6,12 +6,13 @@ compute contact/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID contact/atom
compute ID group-ID contact/atom group2-ID
* ID, group-ID are documented in :doc:`compute <compute>` command
* contact/atom = style name of this compute command
* group2-ID = optional argument to restrict which atoms to consider for contacts (see below)
Examples
""""""""
@ -19,6 +20,7 @@ Examples
.. code-block:: LAMMPS
compute 1 all contact/atom
compute 1 all contact/atom mygroup
Description
"""""""""""
@ -42,9 +44,12 @@ accessed by any command that uses per-atom values from a compute as
input. See the :doc:`Howto output <Howto_output>` page for an
overview of LAMMPS output options.
The per-atom vector values will be a number >= 0.0, as explained
The per-atom vector values will be a number :math:`\ge 0.0`, as explained
above.
The optional *group2-ID* argument allows to specify from which group atoms
contribute to the coordination number. Default setting is group 'all.'
Restrictions
""""""""""""
@ -63,4 +68,7 @@ Related commands
Default
"""""""
*group2-ID* = all
none

40
doc/src/compute_coord_atom.rst
View File

@ -9,23 +9,23 @@ Accelerator Variants: *coord/atom/kk*
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID coord/atom cstyle args ...
compute ID group-ID coord/atom style args ...
* ID, group-ID are documented in :doc:`compute <compute>` command
* coord/atom = style name of this compute command
* cstyle = *cutoff* or *orientorder*
* style = *cutoff* or *orientorder*
.. parsed-literal::
*cutoff* args = cutoff [group group2-ID] typeN
cutoff = distance within which to count coordination neighbors (distance units)
group *group2-ID* = select group-ID to restrict which atoms to consider for coordination number (optional)
typeN = atom type for Nth coordination count (see asterisk form below)
*orientorder* args = orientorderID threshold
orientorderID = ID of an orientorder/atom compute
threshold = minimum value of the product of two "connected" atoms
*cutoff* args = cutoff [*group* group2-ID] typeN
cutoff = distance within which to count coordination neighbors (distance units)
*group* group2-ID = select group-ID to restrict which atoms to consider for coordination number (optional)
typeN = atom type for Nth coordination count (see asterisk form below)
*orientorder* args = orientorderID threshold
orientorderID = ID of an orientorder/atom compute
threshold = minimum value of the product of two "connected" atoms
Examples
""""""""
@ -54,7 +54,7 @@ neighboring atoms, unless selected by type, type range, or group option,
are included in the coordination number tally.
The optional *group* keyword allows to specify from which group atoms
contribute to the coordination number. Default setting is group 'all'.
contribute to the coordination number. Default setting is group 'all.'
The *typeN* keywords allow specification of which atom types
contribute to each coordination number. One coordination number is
@ -65,15 +65,15 @@ includes atoms of all types (same as the "\*" format, see below).
The *typeN* keywords can be specified in one of two ways. An explicit
numeric value can be used, as in the second example above. Or a
wild-card asterisk can be used to specify a range of atom types. This
takes the form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of
takes the form "\*" or "\*n" or "m\*" or "m\*n". If :math:`N` is the number of
atom 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
from 1 to :math:`N`. A leading asterisk means all types from 1 to n
(inclusive). A trailing asterisk means all types from m to :math:`N`
(inclusive). A middle asterisk means all types from m to n
(inclusive).
The *orientorder* cstyle calculates the number of "connected" neighbor
atoms J around each central atom I. For this *cstyle*, connected is
atoms *j* around each central atom *i*\ . For this *cstyle*, connected is
defined by the orientational order parameter calculated by the
:doc:`compute orientorder/atom <compute_orientorder_atom>` command.
This *cstyle* thus allows one to apply the ten Wolde's criterion to
@ -84,16 +84,16 @@ The ID of the previously specified :doc:`compute orientorder/atom <compute_orien
calculate components of the *Ybar_lm* vector for each atoms, as
described in its documentation. Note that orientorder/atom compute
defines its own criteria for identifying neighboring atoms. If the
scalar product (*Ybar_lm(i)*,*Ybar_lm(j)*), calculated by the
scalar product (*Ybar_lm(i)*, *Ybar_lm(j)*), calculated by the
orientorder/atom compute is larger than the specified *threshold*,
then I and J are connected, and the coordination value of I is
then *i* and *j* are connected, and the coordination value of *i* is
incremented by one.
For all *cstyle* settings, all coordination values will be 0.0 for
atoms not in the specified compute group.
The neighbor list needed to compute this quantity is constructed each
time the calculation is performed (i.e. each time a snapshot of atoms
time the calculation is performed (i.e., each time a snapshot of atoms
is dumped). Thus it can be inefficient to compute/dump this quantity
too frequently.
@ -127,7 +127,7 @@ For *cstyle* cutoff, this compute can calculate a per-atom vector or
array. If single *type1* keyword is specified (or if none are
specified), this compute calculates a per-atom vector. If multiple
*typeN* keywords are specified, this compute calculates a per-atom
array, with N columns.
array, with :math:`N` columns.
For *cstyle* orientorder, this compute calculates a per-atom vector.
@ -135,7 +135,7 @@ These values can be accessed by any command that uses per-atom values
from a compute as input. See the :doc:`Howto output <Howto_output>` doc
page for an overview of LAMMPS output options.
The per-atom vector or array values will be a number >= 0.0, as
The per-atom vector or array values will be a number :math:`\ge 0.0`, as
explained above.
Restrictions

4
doc/src/compute_damage_atom.rst
View File

@ -6,7 +6,7 @@ compute damage/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID damage/atom
@ -48,7 +48,7 @@ any command that uses per-atom values from a compute as input. See
the :doc:`Howto output <Howto_output>` page for an overview of
LAMMPS output options.
The per-atom vector values are unitless numbers (damage) >= 0.0.
The per-atom vector values are unitless numbers (damage) :math:`\ge 0.0`.
Restrictions
""""""""""""

12
doc/src/compute_dihedral.rst
View File

@ -6,7 +6,7 @@ compute dihedral command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID dihedral
@ -34,10 +34,12 @@ total energy contributed by one or more of the hybrid sub-styles.
Output info
"""""""""""
This compute calculates a global vector of length N where N is the
number of sub_styles defined by the :doc:`dihedral_style hybrid <dihedral_style>` command. which can be accessed by indices
1-N. These values can be used by any command that uses global scalar
or vector values from a compute as input. See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
This compute calculates a global vector of length :math:`N`, where :math:`N`
is the number of sub_styles defined by the
:doc:`dihedral_style hybrid <dihedral_style>` command, which can be accessed by
the indices 1 through :math:`N`. These values can be used by any command that
uses global scalar or vector values from a compute as input. See the
:doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
options.
The vector values are "extensive" and will be in energy

43
doc/src/compute_dihedral_local.rst
View File

@ -6,7 +6,7 @@ compute dihedral/local command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID dihedral/local value1 value2 ... keyword args ...
@ -35,7 +35,6 @@ Examples
.. code-block:: LAMMPS
compute 1 all dihedral/local phi
compute 1 all dihedral/local phi v_cos set phi p
Description
@ -46,25 +45,26 @@ interactions. The number of datums generated, aggregated across all
processors, equals the number of dihedral angles in the system, modified
by the group parameter as explained below.
The value *phi* is the dihedral angle, as defined in the diagram on
the :doc:`dihedral_style <dihedral_style>` doc page.
The value *phi* (:math:`\phi`) is the dihedral angle, as defined in the diagram
on the :doc:`dihedral_style <dihedral_style>` doc page.
The value *v_name* can be used together with the *set* keyword to
compute a user-specified function of the dihedral angle phi. The
*name* specified for the *v_name* value is the name of an :doc:`equal-style variable <variable>` which should evaluate a formula based on a
variable which will store the angle phi. This other variable must
The value *v_name* can be used together with the *set* keyword to compute a
user-specified function of the dihedral angle :math:`\phi`. The *name*
specified for the *v_name* value is the name of an
:doc:`equal-style variable <variable>` which should evaluate a formula based on
a variable which will store the angle :math:`\phi`. This other variable must
be an :doc:`internal-style variable <variable>` defined in the input
script; its initial numeric value can be anything. It must be an
internal-style variable, because this command resets its value
directly. The *set* keyword is used to identify the name of this
other variable associated with phi.
other variable associated with :math:`\phi`.
Note that the value of phi for each angle which stored in the internal
Note that the value of :math:`\phi` for each angle which stored in the internal
variable is in radians, not degrees.
As an example, these commands can be added to the bench/in.rhodo
script to compute the cosine and cosine\^2 of every dihedral angle in
the system and output the statistics in various ways:
script to compute the :math:`\cos\phi` and :math:`\cos^2\phi` of every dihedral
angle in the system and output the statistics in various ways:
.. code-block:: LAMMPS
@ -81,19 +81,18 @@ the system and output the statistics in various ways:
fix 10 all ave/histo 10 10 100 -1 1 20 c_2[2] mode vector file tmp.histo
The :doc:`dump local <dump>` command will output the angle,
cosine(angle), cosine\^2(angle) for every dihedral in the system. The
:doc:`thermo_style <thermo_style>` command will print the average of
The :doc:`dump local <dump>` command will output the angle (:math:`\phi`),
:math:`\cos(\phi)`, and :math:`\cos^2(\phi)` for every dihedral in the system.
The :doc:`thermo_style <thermo_style>` command will print the average of
those quantities via the :doc:`compute reduce <compute_reduce>` command
with thermo output. And the :doc:`fix ave/histo <fix_ave_histo>`
command will histogram the cosine(angle) values and write them to a
file.
command will histogram the cosine(angle) values and write them to a file.
----------
The local data stored by this command is generated by looping over all
the atoms owned on a processor and their dihedrals. A dihedral will
only be included if all 4 atoms in the dihedral are in the specified
only be included if all four atoms in the dihedral are in the specified
compute group.
Note that as atoms migrate from processor to processor, there will be
@ -101,7 +100,8 @@ no consistent ordering of the entries within the local vector or array
from one timestep to the next. The only consistency that is
guaranteed is that the ordering on a particular timestep will be the
same for local vectors or arrays generated by other compute commands.
For example, dihedral output from the :doc:`compute property/local <compute_property_local>` command can be combined
For example, dihedral output from the
:doc:`compute property/local <compute_property_local>` command can be combined
with data from this command and output by the :doc:`dump local <dump>`
command in a consistent way.
@ -120,9 +120,10 @@ This compute calculates a local vector or local array depending on the
number of values. The length of the vector or number of rows in the
array is the number of dihedrals. If a single value is specified, a
local vector is produced. If two or more values are specified, a
local array is produced where the number of columns = the number of
local array is produced where the number of columns is equal to the number of
values. 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
local values from a compute as input. See the
:doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
options.
The output for *phi* will be in degrees.

19
doc/src/compute_dilatation_atom.rst
View File

@ -6,12 +6,12 @@ compute dilatation/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID dilatation/atom
* ID, group-ID are documented in compute command
* dilation/atom = style name of this compute command
* dilatation/atom = style name of this compute command
Examples
""""""""
@ -30,13 +30,13 @@ for an overview of LAMMPS commands for Peridynamics modeling.
For small deformation, dilatation of is the measure of the volumetric
strain.
The dilatation "theta" for each peridynamic particle I is calculated
as a sum over its neighbors with unbroken bonds, where the
contribution of the IJ pair is a function of the change in bond length
The dilatation :math:`\theta` for each peridynamic particle :math:`i` is
calculated as a sum over its neighbors with unbroken bonds, where the
contribution of the :math:`ij` pair is a function of the change in bond length
(versus the initial length in the reference state), the volume
fraction of the particles and an influence function. See the
`PDLAMMPS user guide <http://www.sandia.gov/~mlparks/papers/PDLAMMPS.pdf>`_ for a formal
definition of dilatation.
`PDLAMMPS user guide <http://www.sandia.gov/~mlparks/papers/PDLAMMPS.pdf>`_ for
a formal definition of dilatation.
This command can only be used with a subset of the Peridynamic :doc:`pair styles <pair_peri>`: peri/lps, peri/ves and peri/eps.
@ -51,13 +51,14 @@ any command that uses per-atom values from a compute as input. See
the :doc:`Howto output <Howto_output>` page for an overview of
LAMMPS output options.
The per-atom vector values are unitless numbers (theta) >= 0.0.
The per-atom vector values are unitless numbers :math:`(\theta \ge 0.0)`.
Restrictions
""""""""""""
This compute is part of the PERI package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
LAMMPS was built with that package. See the
:doc:`Build package <Build_package>` page for more info.
Related commands
""""""""""""""""

13
doc/src/compute_dipole.rst
View File

@ -6,13 +6,13 @@ compute dipole command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID dipole charge-correction
compute ID group-ID dipole arg
* ID, group-ID are documented in :doc:`compute <compute>` command
* dipole = style name of this compute command
* charge-correction = *mass* or *geometry*, use COM or geometric center for charged chunk correction (optional)
* arg = *mass* or *geometry* = use COM or geometric center for charged chunk correction (optional)
Examples
""""""""
@ -43,7 +43,7 @@ and per-atom dipole moments, if present, contribute to the computed dipole.
:doc:`dump custom <dump>` command for a discussion of "unwrapped"
coordinates. See the Atoms section of the :doc:`read_data
<read_data>` command for a discussion of image flags and how they are
set for each atom. You can reset the image flags (e.g. to 0) before
set for each atom. You can reset the image flags (e.g., to 0) before
invoking this compute by using the :doc:`set image <set>` command.
Output info
@ -54,8 +54,9 @@ the computed dipole moment and a global vector of length 3 with the
dipole vector. See the :doc:`Howto output <Howto_output>` page for
an overview of LAMMPS output options.
The computed values are "intensive". The array values will be in
dipole units, i.e. charge units times distance :doc:`units <units>`.
The computed values are "intensive." The array values will be in
dipole units (i.e., charge :doc:`units <units>` times distance
:doc:`units <units>`).
Restrictions
""""""""""""

21
doc/src/compute_dipole_chunk.rst
View File

@ -6,14 +6,14 @@ compute dipole/chunk command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID dipole/chunk chunkID charge-correction
compute ID group-ID dipole/chunk chunkID arg
* ID, group-ID are documented in :doc:`compute <compute>` command
* dipole/chunk = style name of this compute command
* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
* charge-correction = *mass* or *geometry*, use COM or geometric center for charged chunk correction (optional)
* arg = *mass* or *geometry* = use COM or geometric center for charged chunk correction (optional)
Examples
""""""""
@ -38,8 +38,8 @@ or atoms in a spatial bin. See the :doc:`compute chunk/atom
details of how chunks can be defined and examples of how they can be
used to measure properties of a system.
This compute calculates the x,y,z coordinates of the dipole vector and
the total dipole moment for each chunk, which includes all effects due
This compute calculates the :math:`(x,y,z)` coordinates of the dipole vector
and the total dipole moment for each chunk, which includes all effects due
to atoms passing through periodic boundaries. For chunks with a net
charge the resulting dipole is made position independent by subtracting
the position vector of the center of mass or geometric center times the
@ -62,7 +62,7 @@ chunk IDs.
"unwrapped" coordinates. See the Atoms section of the
:doc:`read_data <read_data>` command for a discussion of image flags
and how they are set for each atom. You can reset the image flags
(e.g. to 0) before invoking this compute by using the :doc:`set image
(e.g., to 0) before invoking this compute by using the :doc:`set image
<set>` command.
The simplest way to output the results of the compute com/chunk
@ -80,14 +80,15 @@ Output info
This compute calculates a global array where the number of rows = the
number of chunks *Nchunk* as calculated by the specified :doc:`compute
chunk/atom <compute_chunk_atom>` command. The number of columns = 4 for
the x,y,z dipole vector components and the total dipole of each
chunk/atom <compute_chunk_atom>` command. The number of columns is 4 for
the :math:`(x,y,z)` dipole vector components and the total dipole of each
chunk. These values can be accessed by any command that uses global
array values from a compute as input. See the :doc:`Howto output
<Howto_output>` page for an overview of LAMMPS output options.
The array values are "intensive". The array values will be in
dipole units, i.e. charge units times distance :doc:`units <units>`.
The array values are "intensive." The array values will be in
dipole units (i.e., charge :doc:`units <units>` times distance
:doc:`units <units>`).
Restrictions
""""""""""""

27
doc/src/compute_displace_atom.rst
View File

@ -6,7 +6,7 @@ compute displace/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID displace/atom
@ -35,9 +35,9 @@ atom in the group from its original (reference) coordinates, including
all effects due to atoms passing through periodic boundaries.
A vector of four quantities per atom is calculated by this compute.
The first 3 elements of the vector are the dx,dy,dz displacements.
The fourth component is the total displacement, i.e. sqrt(dx\*dx + dy\*dy +
dz\*dz).
The first three elements of the vector are the :math:`(dx,dy,dz)`
displacements. The fourth component is the total displacement
(i.e., :math:`\sqrt{dx^2 + dy^2 + dz^2}`).
The displacement of an atom is from its original position at the time
the compute command was issued. The value of the displacement will be
@ -50,7 +50,7 @@ the compute command was issued. The value of the displacement will be
<dump>` command for a discussion of "unwrapped" coordinates. See
the Atoms section of the :doc:`read_data <read_data>` command for a
discussion of image flags and how they are set for each atom. You
can reset the image flags (e.g. to 0) before invoking this compute
can reset the image flags (e.g., to 0) before invoking this compute
by using the :doc:`set image <set>` command.
.. note::
@ -60,7 +60,7 @@ the compute command was issued. The value of the displacement will be
you should use the same ID for this compute, as in the original run.
This is so that the fix this compute creates to store per-atom
quantities will also have the same ID, and thus be initialized
correctly with time=0 atom coordinates from the restart file.
correctly with time = 0 atom coordinates from the restart file.
----------
@ -95,14 +95,15 @@ something like the following commands:
refresh c_dsp delay 100
The :doc:`dump_modify thresh <dump_modify>` command will only output
atoms that have displaced more than 0.6 Angstroms on each snapshot
(assuming metal units). The dump_modify *refresh* option triggers a
atoms that have displaced more than :math:`0.6~\mathrm{\mathring A}` on each
snapshot (assuming metal units). The dump_modify *refresh* option triggers a
call to this compute at the end of every dump.
The *refresh* argument for this compute is the ID of an :doc:`atom-style variable <variable>` which calculates a Boolean value (0 or 1)
The *refresh* argument for this compute is the ID of an
:doc:`atom-style variable <variable>` which calculates a Boolean value (0 or 1)
based on the same criterion used by dump_modify thresh. This compute
evaluates the atom-style variable. For each atom that returns 1
(true), the original (reference) coordinates of the atom (stored by
evaluates the atom-style variable. For each atom that returns 1 (true),
the original (reference) coordinates of the atom (stored by
this compute) are updated.
The effect of these commands is that a particular atom will only be
@ -125,8 +126,8 @@ would be empty.
Output info
"""""""""""
This compute calculates a per-atom array with 4 columns, which can be
accessed by indices 1-4 by any command that uses per-atom values from
This compute calculates a per-atom array with four columns, which can be
accessed by indices 1--4 by any command that uses per-atom values from
a compute as input. See the :doc:`Howto output <Howto_output>` doc page
for an overview of LAMMPS output options.

31
doc/src/compute_dpd.rst
View File

@ -6,7 +6,7 @@ compute dpd command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID dpd
@ -24,9 +24,9 @@ Description
"""""""""""
Define a computation that accumulates the total internal conductive
energy (:math:`U^{cond}`), the total internal mechanical energy
(:math:`U^{mech}`), the total chemical energy (:math:`U^{chem}`)
and the *harmonic* average of the internal temperature (:math:`\theta_{avg}`)
energy (:math:`U^{\text{cond}}`), the total internal mechanical energy
(:math:`U^{\text{mech}}`), the total chemical energy (:math:`U^\text{chem}`)
and the *harmonic* average of the internal temperature (:math:`\theta_\text{avg}`)
for the entire system of particles. See the
:doc:`compute dpd/atom <compute_dpd_atom>` command if you want
per-particle internal energies and internal temperatures.
@ -36,22 +36,24 @@ relations:
.. math::
U^{cond} = & \displaystyle\sum_{i=1}^{N} u_{i}^{cond} \\
U^{mech} = & \displaystyle\sum_{i=1}^{N} u_{i}^{mech} \\
U^{chem} = & \displaystyle\sum_{i=1}^{N} u_{i}^{chem} \\
U = & \displaystyle\sum_{i=1}^{N} (u_{i}^{cond} + u_{i}^{mech} + u_{i}^{chem}) \\
\theta_{avg} = & (\frac{1}{N}\displaystyle\sum_{i=1}^{N} \frac{1}{\theta_{i}})^{-1} \\
U^\text{cond} = & \sum_{i=1}^{N} u_{i}^\text{cond} \\
U^\text{mech} = & \sum_{i=1}^{N} u_{i}^\text{mech} \\
U^\text{chem} = & \sum_{i=1}^{N} u_{i}^\text{chem} \\
U = & \sum_{i=1}^{N} (u_{i}^\text{cond}
+ u_{i}^\text{mech} + u_{i}^\text{chem}) \\
\theta_{avg} = & \biggl(\frac{1}{N}\sum_{i=1}^{N}
\frac{1}{\theta_{i}}\biggr)^{-1} \\
where :math:`N` is the number of particles in the system
where :math:`N` is the number of particles in the system.
----------
Output info
"""""""""""
This compute calculates a global vector of length 5 (:math:`U^{cond}`,
:math:`U^{mech}`, :math:`U^{chem}`, :math:`\theta_{avg}`, :math:`N`),
which can be accessed by indices 1-5.
This compute calculates a global vector of length 5 (:math:`U^\text{cond}`,
:math:`U^\text{mech}`, :math:`U^\text{chem}`, :math:`\theta_\text{avg}`,
:math:`N`), which can be accessed by indices 1 through 5.
See the :doc:`Howto output <Howto_output>` page for an overview of
LAMMPS output options.
@ -61,7 +63,8 @@ Restrictions
""""""""""""
This command is part of the DPD-REACT package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
LAMMPS was built with that package.
See the :doc:`Build package <Build_package>` page for more info.
This command also requires use of the :doc:`atom_style dpd <atom_style>`
command.

27
doc/src/compute_dpd_atom.rst
View File

@ -6,7 +6,7 @@ compute dpd/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID dpd/atom
@ -23,29 +23,28 @@ Examples
Description
"""""""""""
Define a computation that accesses the per-particle internal
conductive energy (:math:`u^{cond}`), internal mechanical
energy (:math:`u^{mech}`), internal chemical energy (:math:`u^{chem}`)
and internal temperatures (:math:`\theta`) for each particle in a group.
Define a computation that accesses the per-particle internal conductive energy
(:math:`u^\text{cond}`), internal mechanical energy (:math:`u^\text{mech}`),
internal chemical energy (:math:`u^\text{chem}`) and internal temperatures
(:math:`\theta`) for each particle in a group.
See the :doc:`compute dpd <compute_dpd>` command if you want the total
internal conductive energy, the total internal mechanical energy, the
total chemical energy and
average internal temperature of the entire system or group of dpd
particles.
total chemical energy and average internal temperature of the entire system or
group of dpd particles.
Output info
"""""""""""
This compute calculates a per-particle array with 4 columns (:math:`u^{cond}`,
:math:`u^{mech}`, :math:`u^{chem}`, :math:`\theta`), which can be accessed
by indices 1-4 by any
This compute calculates a per-particle array with four columns
(:math:`u^\text{cond}`, :math:`u^\text{mech}`, :math:`u^\text{chem}`,
:math:`\theta`), which can be accessed by indices 1--4 by any
command that uses per-particle values from a compute as input. See
the :doc:`Howto output <Howto_output>` page for an overview of
LAMMPS output options.
The per-particle array values will be in energy (:math:`u^{cond}`,
:math:`u^{mech}`, :math:`u^{chem}`)
and temperature (:math:`theta`) :doc:`units <units>`.
The per-particle array values will be in energy (:math:`u^\text{cond}`,
:math:`u^\text{mech}`, :math:`u^\text{chem}`)
and temperature (:math:`\theta`) :doc:`units <units>`.
Restrictions
""""""""""""

2
doc/src/compute_edpd_temp_atom.rst
View File

@ -6,7 +6,7 @@ compute edpd/temp/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID edpd/temp/atom

17
doc/src/compute_efield_atom.rst
View File

@ -6,12 +6,19 @@ compute efield/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID efield/atom
compute ID group-ID efield/atom keyword val
* ID, group-ID are documented in :doc:`compute <compute>` command
* efield/atom = style name of this compute command
* zero or more keyword/value pairs may be appended
* keyword = *pair* or *kspace*
.. parsed-literal::
*pair* args = *yes* or *no*
*kspace* args = *yes* or *no*
Examples
""""""""
@ -23,10 +30,10 @@ Examples
Used in input scripts:
.. parsed-literal::
.. parsed-literal::
examples/PACKAGES/dielectric/in.confined
examples/PACKAGES/dielectric/in.nopbc
examples/PACKAGES/dielectric/in.confined
examples/PACKAGES/dielectric/in.nopbc
Description
"""""""""""

45
doc/src/compute_entropy_atom.rst
View File

@ -6,24 +6,23 @@ compute entropy/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID entropy/atom sigma cutoff keyword value ...
* ID, group-ID are documented in :doc:`compute <compute>` command
* entropy/atom = style name of this compute command
* sigma = width of gaussians used in the g(r) smoothing
* cutoff = cutoff for the g(r) calculation
* sigma = width of Gaussians used in the :math:`g(r)` smoothing
* cutoff = cutoff for the :math:`g(r)` calculation
* one or more keyword/value pairs may be appended
.. parsed-literal::
keyword = *avg* or *local*
*avg* values = *yes* or *no* cutoff2
*yes* = average the pair entropy over neighbors
*no* = do not average the pair entropy over neighbors
*avg* args = neigh cutoff2
neigh value = *yes* or *no* = whether to average the pair entropy over neighbors
cutoff2 = cutoff for the averaging over neighbors
*local* values = *yes* or *no* = use the local density around each atom to normalize the g(r)
*local* arg = *yes* or *no* = use the local density around each atom to normalize the g(r)
Examples
""""""""
@ -53,31 +52,32 @@ This parameter for atom i is computed using the following formula from
s_S^i=-2\pi\rho k_B \int\limits_0^{r_m} \left [ g(r) \ln g(r) - g(r) + 1 \right ] r^2 dr
where r is a distance, g(r) is the radial distribution function of atom
i and rho is the density of the system. The g(r) computed for each
atom i can be noisy and therefore it is smoothed using:
where :math:`r` is a distance, :math:`g(r)` is the radial distribution function
of atom :math:`i`, and :math:`\rho` is the density of the system.
The :math:`g(r)` computed for each atom :math:`i` can be noisy and therefore it
is smoothed using
.. math::
g_m^i(r) = \frac{1}{4 \pi \rho r^2} \sum\limits_{j} \frac{1}{\sqrt{2 \pi \sigma^2}} e^{-(r-r_{ij})^2/(2\sigma^2)}
where the sum in j goes through the neighbors of atom i, and :math:`\sigma`
is a parameter to control the smoothing.
where the sum over :math:`j` goes through the neighbors of atom :math:`i` and
:math:`\sigma` is a parameter to control the smoothing.
The input parameters are *sigma* the smoothing parameter :math:`\sigma`,
and the *cutoff* for the calculation of g(r).
and the *cutoff* for the calculation of :math:`g(r)`.
If the keyword *avg* has the setting *yes*, then this compute also
averages the parameter over the neighbors of atom i according to:
averages the parameter over the neighbors of atom :math:`i` according to
.. math::
\left< s_S^i \right> = \frac{\sum_j s_S^j + s_S^i}{N + 1}
\left< s_S^i \right> = \frac{\sum_j s_S^j + s_S^i}{N + 1},
where the sum j goes over the neighbors of atom i and N is the number
of neighbors. This procedure provides a sharper distinction between
order and disorder environments. In this case the input parameter
*cutoff2* is the cutoff for the averaging over the neighbors and
where the sum over :math:`j` goes over the neighbors of atom :math:`i` and
:math:`N` is the number of neighbors. This procedure provides a sharper
distinction between order and disorder environments. In this case the input
parameter *cutoff2* is the cutoff for the averaging over the neighbors and
must also be specified.
If the *avg yes* option is used, the effective cutoff of the neighbor
@ -90,14 +90,14 @@ to increase the skin of the neighbor list with:
See :doc:`neighbor <neighbor>` for details.
If the *local yes* option is used, the g(r) is normalized by the
If the *local yes* option is used, the :math:`g(r)` is normalized by the
local density around each atom, that is to say the density around each
atom is the number of neighbors within the neighbor list cutoff divided
by the corresponding volume. This option can be useful when dealing with
inhomogeneous systems such as those that have surfaces.
Here are typical input parameters for fcc aluminum (lattice
constant 4.05 Angstroms),
constant :math:`4.05~\mathrm{\mathring A}`),
.. parsed-literal::
@ -114,7 +114,8 @@ Output info
By default, this compute calculates the pair entropy value for each
atom as a per-atom vector, which can be accessed by any command that
uses per-atom values from a compute as input. See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
uses per-atom values from a compute as input. See the
:doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
options.
The pair entropy values have units of the Boltzmann constant. They are

12
doc/src/compute_erotate_asphere.rst
View File

@ -6,7 +6,7 @@ compute erotate/asphere command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID erotate/asphere
@ -30,9 +30,9 @@ ellipsoids, or line segments, or triangles. See the
for descriptions of these options.
For all 3 types of particles, the rotational kinetic energy is
computed as 1/2 I w\^2, where I is the inertia tensor for the
aspherical particle and w is its angular velocity, which is computed
from its angular momentum if needed.
computed as :math:`\frac12 I \omega^2`, where :math:`I` is the inertia tensor
for the aspherical particle and :math:`\omega` is its angular velocity, which
is computed from its angular momentum if needed.
.. note::
@ -48,7 +48,7 @@ used by any command that uses a global scalar value from a compute as
input. See the :doc:`Howto output <Howto_output>` page for an
overview of LAMMPS output options.
The scalar value calculated by this compute is "extensive". The
The scalar value calculated by this compute is "extensive." The
scalar value will be in energy :doc:`units <units>`.
Restrictions
@ -65,7 +65,7 @@ This compute requires that triangular particles atoms store a size and
shape and quaternion orientation and angular momentum as defined by
the :doc:`atom_style tri <atom_style>` command.
All particles in the group must be finite-size. They cannot be point
All particles in the group must be of finite size. They cannot be point
particles.
Related commands

23
doc/src/compute_erotate_rigid.rst
View File

@ -6,7 +6,7 @@ compute erotate/rigid command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID erotate/rigid fix-ID
@ -25,18 +25,20 @@ Description
"""""""""""
Define a computation that calculates the rotational kinetic energy of
a collection of rigid bodies, as defined by one of the :doc:`fix rigid <fix_rigid>` command variants.
a collection of rigid bodies, as defined by one of the
:doc:`fix rigid <fix_rigid>` command variants.
The rotational energy of each rigid body is computed as 1/2 I Wbody\^2,
where I is the inertia tensor for the rigid body, and Wbody is its
angular velocity vector. Both I and Wbody are in the frame of
reference of the rigid body, i.e. I is diagonalized.
The rotational energy of each rigid body is computed as
:math:`\frac12 I \omega_\text{body}^2`,
where :math:`I` is the inertia tensor for the rigid body and
:math:`\omega_\text{body}` is its angular velocity vector.
Both :math:`I` and :math:`\omega_\text{body}` are in the frame of
reference of the rigid body (i.e., :math:`I` is diagonal).
The *fix-ID* should be the ID of one of the :doc:`fix rigid <fix_rigid>`
commands which defines the rigid bodies. The group specified in the
compute command is ignored. The rotational energy of all the rigid
bodies defined by the fix rigid command in included in the
calculation.
bodies defined by the fix rigid command in included in the calculation.
Output info
"""""""""""
@ -46,14 +48,15 @@ of all the rigid bodies). This value can be used by any command that
uses a global scalar value from a compute as input. See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "extensive". The
The scalar value calculated by this compute is "extensive." The
scalar value will be in energy :doc:`units <units>`.
Restrictions
""""""""""""
This compute is part of the RIGID package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
LAMMPS was built with that package. See the
:doc:`Build package <Build_package>` page for more info.
Related commands
""""""""""""""""

9
doc/src/compute_erotate_sphere.rst
View File

@ -6,7 +6,7 @@ compute erotate/sphere command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID erotate/sphere
@ -26,8 +26,9 @@ Description
Define a computation that calculates the rotational kinetic energy of
a group of spherical particles.
The rotational energy is computed as 1/2 I w\^2, where I is the moment
of inertia for a sphere and w is the particle's angular velocity.
The rotational energy is computed as :math:`\frac12 I \omega^2`,
where :math:`I` is the moment of inertia for a sphere and :math:`\omega`
is the particle's angular velocity.
.. note::
@ -43,7 +44,7 @@ used by any command that uses a global scalar value from a compute as
input. See the :doc:`Howto output <Howto_output>` page for an
overview of LAMMPS output options.
The scalar value calculated by this compute is "extensive". The
The scalar value calculated by this compute is "extensive." The
scalar value will be in energy :doc:`units <units>`.
Restrictions

10
doc/src/compute_erotate_sphere_atom.rst
View File

@ -6,7 +6,7 @@ compute erotate/sphere/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID erotate/sphere/atom
@ -26,8 +26,9 @@ Description
Define a computation that calculates the rotational kinetic energy for
each particle in a group.
The rotational energy is computed as 1/2 I w\^2, where I is the moment
of inertia for a sphere and w is the particle's angular velocity.
The rotational energy is computed as :math:`\frac12 I \omega^2`, where
:math:`I` is the moment of inertia for a sphere and :math:`\omega` is the
particle's angular velocity.
.. note::
@ -36,8 +37,7 @@ of inertia for a sphere and w is the particle's angular velocity.
as in 3d.
The value of the rotational kinetic energy will be 0.0 for atoms not
in the specified compute group or for point particles with a radius =
0.0.
in the specified compute group or for point particles with a radius of 0.0.
Output info
"""""""""""

9
doc/src/compute_event_displace.rst
View File

@ -6,7 +6,7 @@ compute event/displace command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID event/displace threshold
@ -27,10 +27,9 @@ Description
Define a computation that flags an "event" if any particle in the
group has moved a distance greater than the specified threshold
distance when compared to a previously stored reference state
(i.e. the previous event). This compute is typically used in
(i.e., the previous event). This compute is typically used in
conjunction with the :doc:`prd <prd>` and :doc:`tad <tad>` commands,
to detect if a transition
to a new minimum energy basin has occurred.
to detect if a transition to a new minimum energy basin has occurred.
This value calculated by the compute is equal to 0 if no particle has
moved far enough, and equal to 1 if one or more particles have moved
@ -51,7 +50,7 @@ used by any command that uses a global scalar value from a compute as
input. See the :doc:`Howto output <Howto_output>` page for an
overview of LAMMPS output options.
The scalar value calculated by this compute is "intensive". The
The scalar value calculated by this compute is "intensive." The
scalar value will be a 0 or 1 as explained above.
Restrictions

47
doc/src/compute_fabric.rst
View File

@ -6,9 +6,9 @@ compute fabric command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID fabric cutoff attribute1 attribute2 ... keyword values ...
compute ID group-ID fabric cutoff attribute ... keyword values ...
* ID, group-ID are documented in :doc:`compute <compute>` command
* fabric = style name of this compute command
@ -20,6 +20,7 @@ Syntax
*radius* = cutoffs determined based on atom diameters (atom style sphere)
* one or more attributes may be appended
* attribute = *contact* or *branch* or *force/normal* or *force/tangential*
.. parsed-literal::
@ -63,7 +64,7 @@ tangential force tensor. The contact tensor is calculated as
.. math::
C_{ab} = \frac{15}{2} (\phi_{ab} - \mathrm{tr}(\phi) \delta_{ab})
C_{ab} = \frac{15}{2} (\phi_{ab} - \mathrm{Tr}(\phi) \delta_{ab})
where :math:`a` and :math:`b` are the :math:`x`, :math:`y`, :math:`z`
directions, :math:`\delta_{ab}` is the Kronecker delta function, and
@ -75,13 +76,14 @@ the tensor :math:`\phi` is defined as
where :math:`n` loops over the :math:`N_p` pair interactions in the simulation,
:math:`r_{a}` is the :math:`a` component of the radial vector between the
two pairwise interacting particles, and :math:`r` is the magnitude of the radial vector.
two pairwise interacting particles, and :math:`r` is the magnitude of the
radial vector.
The branch tensor is calculated as
.. math::
B_{ab} = \frac{15}{6 \mathrm{tr}(D)} (D_{ab} - \mathrm{tr}(D) \delta_{ab})
B_{ab} = \frac{15}{6 \mathrm{Tr}(D)} (D_{ab} - \mathrm{Tr}(D) \delta_{ab})
where the tensor :math:`D` is defined as
@ -91,14 +93,15 @@ where the tensor :math:`D` is defined as
\frac{1}{N_c (r^2 + C_{cd} r_c r_d)}
\frac{r_{a} r_{b}}{r}
where :math:`N_c` is the total number of contacts in the system and the subscripts
:math:`c` and :math:`d` indices are summed according to Einstein notation.
where :math:`N_c` is the total number of contacts in the system and the
subscripts :math:`c` and :math:`d` indices are summed according to Einstein
notation.
The normal force fabric tensor is calculated as
.. math::
F^n_{ab} = \frac{15}{6 \mathrm{tr}(N)} (N_{ab} - \mathrm{tr}(N) \delta_{ab})
F^n_{ab} = \frac{15}{6\, \mathrm{Tr}(N)} (N_{ab} - \mathrm{Tr}(N) \delta_{ab})
where the tensor :math:`N` is defined as
@ -116,7 +119,7 @@ as
.. math::
F^t_{ab} = \frac{15}{9 \mathrm{tr}(N)} (T_{ab} - \mathrm{tr}(T) \delta_{ab})
F^t_{ab} = \frac{15}{9\, \mathrm{Tr}(N)} (T_{ab} - \mathrm{Tr}(T) \delta_{ab})
where the tensor :math:`T` is defined as
@ -133,21 +136,23 @@ Interactions between two atoms are only included in calculations if the atom typ
are in the two lists. Each list consists of a series of type
ranges separated by commas. The range can be specified as a
single numeric value, or a wildcard asterisk can be used to specify a range
of values. This takes the form "\*" or "\*n" or "n\*" or "m\*n". For
example, if M = the number of atom types, then an asterisk with no numeric
values means all types from 1 to M. A leading asterisk means all types
from 1 to n (inclusive). A trailing asterisk means all types from n to M
(inclusive). A middle asterisk means all types from m to n (inclusive).
Multiple *type/include* keywords may be added.
of values. This takes the form "\*" or "\*n" or "m\*" or "m\*n". For
example, if :math:`M` is the number of atom types, then an asterisk with no
numeric values means all types from 1 to :math:`M`. A leading asterisk means
all types from 1 to n (inclusive). A trailing asterisk means all types from
m to :math:`M` (inclusive). A middle asterisk means all types from m to n
(inclusive). Multiple *type/include* keywords may be added.
Output info
"""""""""""
This compute calculates a local vector of doubles and a scalar. The vector stores the
unique components of the first requested tensor in the order xx, yy, zz, xy, xz, yz
followed by the same components for all subsequent tensors. The length of the vector
is therefore six times the number of requested tensors. The scalar output is the
number of pairwise interactions included in the calculation of the fabric tensor.
This compute calculates a local vector of doubles and a scalar. The vector
stores the unique components of the first requested tensor in the order
:math:`xx`, :math:`yy`, :math:`zz`, :math:`xy`, :math:`xz`, :math:`yz`
followed by the same components for all subsequent tensors.
The length of the vector is therefore six times the number of requested
tensors. The scalar output is the number of pairwise interactions included in
the calculation of the fabric tensor.
Restrictions
""""""""""""
@ -164,7 +169,7 @@ following fixes which add rigid-body constraints: :doc:`fix shake
<fix_shake>`, :doc:`fix rattle <fix_shake>`, :doc:`fix rigid
<fix_rigid>`, :doc:`fix rigid/small <fix_rigid>`. It does not support
granular pair styles that extend beyond the contact of atomic radii
(e.g. JKR and DMT).
(e.g., JKR and DMT).
Related commands
""""""""""""""""

49
doc/src/compute_fep.rst
View File

@ -6,7 +6,7 @@ compute fep command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID fep temp attribute args ... keyword value ...
@ -19,12 +19,12 @@ Syntax
.. parsed-literal::
*pair* args = pstyle pparam I J v_delta
pstyle = pair style name, e.g. lj/cut
pstyle = pair style name (e.g., *lj/cut*)
pparam = parameter to perturb
I,J = type pair(s) to set parameter for
v_delta = variable with perturbation to apply (in the units of the parameter)
*atom* args = aparam I v_delta
aparam = parameter to perturb
aparam = *charge* = parameter to perturb
I = type to set parameter for
v_delta = variable with perturbation to apply (in the units of the parameter)
@ -37,8 +37,8 @@ Syntax
*no* = ignore tail correction to pair energies (usually small in fep)
*yes* = include tail correction to pair energies
*volume* value = *no* or *yes*
*no* = ignore volume changes (e.g. in *NVE* or *NVT* trajectories)
*yes* = include volume changes (e.g. in *NpT* trajectories)
*no* = ignore volume changes (e.g., in *NVE* or *NVT* trajectories)
*yes* = include volume changes (e.g., in *NPT* trajectories)
Examples
""""""""
@ -84,7 +84,7 @@ It is possible but not necessary that the coupling parameter (or a
function thereof) appears as a multiplication factor of the potential
energy. Therefore, this compute can apply perturbations to interaction
parameters that are not directly proportional to the potential energy
(e.g. :math:`\sigma` in Lennard-Jones potentials).
(e.g., :math:`\sigma` in Lennard-Jones potentials).
This command can be combined with :doc:`fix adapt <fix_adapt>` to
perform multistage free-energy perturbation calculations along
@ -92,9 +92,9 @@ stepwise alchemical transformations during a simulation run:
.. math::
\Delta_0^1 A = \sum_{i=0}^{n-1} \Delta_{\lambda_i}^{\lambda_{i+1}} A = - kT
\Delta_0^1 A = \sum_{i=0}^{n-1} \Delta_{\lambda_i}^{\lambda_{i+1}} A = - k_B T
\sum_{i=0}^{n-1} \ln \left< \exp \left( - \frac{U(\lambda_{i+1}) -
U(\lambda_i)}{kT} \right) \right>_{\lambda_i}
U(\lambda_i)}{k_B T} \right) \right>_{\lambda_i}
This compute is suitable for the finite-difference thermodynamic
integration (FDTI) method :ref:`(Mezei) <Mezei>`, which is based on an
@ -107,7 +107,8 @@ perturbation method using a very small :math:`\delta`:
A(\lambda)}{\partial\lambda} \right)_\lambda \mathrm{d}\lambda \approx
\sum_{i=0}^{n-1} w_i \frac{A(\lambda_{i} + \delta) - A(\lambda_i)}{\delta}
where :math:`w_i` are weights of a numerical quadrature. The :doc:`fix adapt <fix_adapt>` command can be used to define the stages of
where :math:`w_i` are weights of a numerical quadrature. The
:doc:`fix adapt <fix_adapt>` command can be used to define the stages of
:math:`\lambda` at which the derivative is calculated and averaged.
The compute fep calculates the exponential Boltzmann term and also the
@ -125,14 +126,14 @@ the derivative of the potential energy with respect to :math:`\lambda`:
Another technique to calculate free energy differences is the
acceptance ratio method :ref:`(Bennet) <Bennet>`, which can be implemented
by calculating the potential energy differences with :math:`\delta` = 1.0 on
by calculating the potential energy differences with :math:`\delta = 1.0` on
both the forward and reverse routes:
.. math::
\left< \frac{1}{1 + \exp\left[\left(U_1 - U_0 - \Delta_0^1A \right) /kT
\left< \frac{1}{1 + \exp\left[\left(U_1 - U_0 - \Delta_0^1A \right) /k_B T
\right]} \right>_0 = \left< \frac{1}{1 + \exp\left[\left(U_0 - U_1 +
\Delta_0^1A \right) /kT \right]} \right>_1
\Delta_0^1A \right) /k_B T \right]} \right>_1
The value of the free energy difference is determined by numerical
root finding to establish the equality.
@ -226,17 +227,17 @@ the pair\_\*.cpp file associated with the potential.
Similar to the :doc:`pair_coeff <pair_coeff>` command, I and J can be
specified in one of two ways. Explicit numeric values can be used for
each, as in the first example above. I <= J is required. LAMMPS sets
each, as in the first example above. I :math:`\le` J is required. LAMMPS sets
the coefficients for the symmetric J,I interaction to the same
values. A wild-card asterisk can be used in place of or in conjunction
with the I,J arguments to set the coefficients for multiple pairs of
atom types. This takes the form "\*" or "\*n" or "n\*" or "m\*n". If N =
the number of atom 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
atom types. This takes the form "\*" or "\*n" or "m\*" or "m\*n". If
:math:`N` is the number of atom 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 m to N
(inclusive). A middle asterisk means all types from m to n
(inclusive). Note that only type pairs with I <= J are considered; if
asterisks imply type pairs where J < I, they are ignored.
(inclusive). Note that only type pairs with I :math:`\le` J are considered; if
asterisks imply type pairs where J :math:`<` I, they are ignored.
If :doc:`pair_style hybrid or hybrid/overlay <pair_hybrid>` is being
used, then the *pstyle* will be a sub-style name. You must specify
@ -275,8 +276,8 @@ trajectories during which the volume fluctuates or changes :ref:`(Allen and Tild
.. math::
\Delta_0^1 A = - kT \sum_{i=0}^{n-1} \ln \frac{\left< V \exp \left( -
\frac{U(\lambda_{i+1}) - U(\lambda_i)}{kT} \right)
\Delta_0^1 A = - k_B T \sum_{i=0}^{n-1} \ln \frac{\left< V \exp \left( -
\frac{U(\lambda_{i+1}) - U(\lambda_i)}{k_B T} \right)
\right>_{\lambda_i}}{\left< V \right>_{\lambda_i}}
----------
@ -286,8 +287,8 @@ Output info
This compute calculates a global vector of length 3 which contains the
energy difference ( :math:`U_1-U_0` ) as c_ID[1], the
Boltzmann factor :math:`\exp(-(U_1-U_0)/kT)`, or
:math:`V \exp(-(U_1-U_0)/kT)`, as c_ID[2] and the
Boltzmann factor :math:`\exp(-(U_1-U_0)/k_B T)`, or
:math:`V \exp(-(U_1-U_0)/k_B T)`, as c_ID[2] and the
volume of the simulation box :math:`V` as c_ID[3]. :math:`U_1` is the
pair potential energy obtained with the perturbed parameters and
:math:`U_0` is the pair potential energy obtained with the
@ -298,7 +299,7 @@ These output results can be used by any command that uses a global
scalar or vector from a compute as input. See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
options. For example, the computed values can be averaged using :doc:`fix ave/time <fix_ave_time>`.
The values calculated by this compute are "extensive".
The values calculated by this compute are "extensive."
Restrictions
""""""""""""

19
doc/src/compute_fep_ta.rst
View File

@ -6,7 +6,7 @@ compute fep/ta command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID fep/ta temp plane scale_factor keyword value ...
@ -20,9 +20,9 @@ Syntax
.. parsed-literal::
*tail* value = *no* or *yes*
*no* = ignore tail correction to pair energies (usually small in fep)
*yes* = include tail correction to pair energies
*tail* value = *no* or *yes*
*no* = ignore tail correction to pair energies (usually small in fep)
*yes* = include tail correction to pair energies
Examples
""""""""
@ -42,11 +42,12 @@ in a single simulation:
.. math::
\gamma = \lim_{\Delta \mathcal{A} \to 0} \left( \frac{\Delta A_{0 \to 1 }}{\Delta \mathcal{A}}\right)_{N,V,T}
= - \frac{kT}{\Delta \mathcal{A}} \ln \left< \exp(-(U_1 - U_0)/kT) \right>_0
= - \frac{k_B T}{\Delta \mathcal{A}} \ln \left\langle \exp\left(\frac{-(U_1 - U_0)}{k_B T}\right) \right\rangle_0
During the perturbation, both axes of *plane* are scaled by multiplying
:math:`\sqrt{scale\_factor}`, while the other axis divided by
*scale_factor* such that the overall volume of the system is maintained.
:math:`\sqrt{\mathrm{scale\_factor}}`, while the other axis divided by
:math:`\mathrm{scale\_factor}` such that the overall volume of the system is
maintained.
The *tail* keyword controls the calculation of the tail correction to
"van der Waals" pair energies beyond the cutoff, if this has been
@ -60,8 +61,8 @@ Output info
"""""""""""
This compute calculates a global vector of length 3 which contains the
energy difference ( :math:`U_1-U_0` ) as c_ID[1], the Boltzmann factor
:math:`\exp(-(U_1-U_0)/kT)`, as c_ID[2] and the change in the *plane*
energy difference :math:`(U_1-U_0)` as c_ID[1], the Boltzmann factor
:math:`\exp\bigl(-(U_1-U_0)/k_B T\bigr)`, as c_ID[2] and the change in the *plane*
area :math:`\Delta \mathcal{A}` as c_ID[3]. :math:`U_1` is the potential
energy of the perturbed state and :math:`U_0` is the potential energy of
the reference state. The energies include kspace terms if these are

44
doc/src/compute_global_atom.rst
View File

@ -6,7 +6,7 @@ compute global/atom command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID style index input1 input2 ...
@ -55,18 +55,20 @@ reference a global vector or array from a :doc:`compute <compute>` or
:doc:`fix <fix>` or the evaluation of an vector-style
:doc:`variable <variable>`. Details are given below.
The *index* value for an atom is used as a index I (from 1 to N) into
the vector associated with each of the input values. The Ith value
The *index* value for an atom is used as an index :math:`I` (from 1 to
:math:`N`, where :math:`N` is the number of atoms) into the vector
associated with each of the input values. The :math:`I`\ th value
from the input vector becomes one output value for that atom. If the
atom is not in the specified group, or the index I < 1 or I > M, where
M is the actual length of the input vector, then an output value of
0.0 is assigned to the atom.
atom is not in the specified group, or the index :math:`I < 1` or
:math:`I > M`, where :math:`M` is the actual length of the input vector,
then an output value of 0.0 is assigned to the atom.
An example of how this command is useful, is in the context of
"chunks" which are static or dynamic subsets of atoms. The :doc:`compute chunk/atom <compute_chunk_atom>` command assigns unique chunk IDs
to each atom. It's output can be used as the *index* parameter for
to each atom. Its output can be used as the *index* parameter for
this command. Various other computes with "chunk" in their style
name, such as :doc:`compute com/chunk <compute_com_chunk>` or :doc:`compute msd/chunk <compute_msd_chunk>`, calculate properties for each
name, such as :doc:`compute com/chunk <compute_com_chunk>` or
:doc:`compute msd/chunk <compute_msd_chunk>`, calculate properties for each
chunk. The output of these commands are global vectors or arrays,
with one or more values per chunk, and can be used as input values for
this command. This command will then assign the global chunk value to
@ -102,17 +104,18 @@ they work.
Note that for input values from a compute or fix, the bracketed index
I can be specified using a wildcard asterisk with the index to
effectively specify multiple values. This takes the form "\*" or "\*n"
or "n\*" or "m\*n". If N = the size of the vector (for *mode* = scalar)
or "m\*" or "m\*n". If :math:`N` is the size of the vector
(for *mode* = scalar)
or the number of columns in the array (for *mode* = vector), then an
asterisk with no numeric values means all indices from 1 to N. A
leading asterisk means all indices from 1 to n (inclusive). A
trailing asterisk means all indices from n to N (inclusive). A middle
asterisk means all indices from m to n (inclusive).
asterisk with no numeric values means all indices from 1 to :math:`N`.
A leading asterisk means all indices from 1 to n (inclusive). A
trailing asterisk means all indices from m to :math:`N` (inclusive).
A middle asterisk means all indices from m to n (inclusive).
Using a wildcard is the same as if the individual columns of the array
had been listed one by one. E.g. these 2 compute global/atom commands
are equivalent, since the :doc:`compute com/chunk <compute_com_chunk>`
command creates a global array with 3 columns:
had been listed one by one. For example, the following two compute global/atom
commands are equivalent, since the :doc:`compute com/chunk <compute_com_chunk>`
command creates a global array with three columns:
.. code-block:: LAMMPS
@ -124,14 +127,14 @@ command creates a global array with 3 columns:
----------
This section explains the *index* parameter. Note that it must
reference per-atom values, as contrasted with the *input* values which
reference per-atom values, as contrasted with the *input* values, which
must reference global values.
Note that all of these options generate floating point values. When
they are used as an index into the specified input vectors, they
simple rounded down to convert the value to integer indices. The
final values should range from 1 to N (inclusive), since they are used
to access values from N-length vectors.
final values should range from 1 to :math:`N` (inclusive), since they are used
to access values from :math:`N`-length vectors.
If *index* begins with "c\_", a compute ID must follow which has been
previously defined in the input script. The compute must generate
@ -177,7 +180,8 @@ global vector or array. See the individual :doc:`compute <compute>` doc
page for details. If no bracketed integer is appended, the vector
calculated by the compute is used. If a bracketed integer is
appended, the Ith column of the array calculated by the compute is
used. Users can also write code for their own compute styles and :doc:`add them to LAMMPS <Modify>`. See the discussion above for how
used. Users can also write code for their own compute styles and
:doc:`add them to LAMMPS <Modify>`. See the discussion above for how
I can be specified with a wildcard asterisk to effectively specify
multiple values.

38
doc/src/compute_group_group.rst
View File

@ -6,7 +6,7 @@ compute group/group command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID group/group group2-ID keyword value ...
@ -102,19 +102,20 @@ frequently.
If you have a bonded system, then the settings of
:doc:`special_bonds <special_bonds>` command can remove pairwise
interactions between atoms in the same bond, angle, or dihedral. This
is the default setting for the :doc:`special_bonds <special_bonds>`
command, and means those pairwise interactions do not appear in the
neighbor list. Because this compute uses a neighbor list, it also
means those pairs will not be included in the group/group interaction.
This does not apply when using long-range coulomb interactions
(\ *coul/long*, *coul/msm*, *coul/wolf* or similar. One way to get
around this would be to set special_bond scaling factors to very tiny
numbers that are not exactly zero (e.g. 1.0e-50). Another workaround
is to write a dump file, and use the :doc:`rerun <rerun>` command to
compute the group/group interactions for snapshots in the dump file.
The rerun script can use a :doc:`special_bonds <special_bonds>` command
that includes all pairs in the neighbor list.
interactions between atoms in the same bond, angle, or dihedral. This is
the default setting for the :doc:`special_bonds <special_bonds>` command,
and means those pairwise interactions do not appear in the neighbor list.
Because this compute uses a neighbor list, it also means those pairs will
not be included in the group/group interaction. This does not apply when
using long-range Coulomb interactions
(\ *coul/long*, *coul/msm*, *coul/wolf* or similar). One way to get
around this would be to set *special_bond* scaling factors to very tiny
numbers that are not exactly zero (e.g., :math:`1.0 \times 10^{-50}`).
Another workaround would be to write a dump file and use the
:doc:`rerun <rerun>` command to compute the group/group interactions for
snapshots in the dump file. The rerun script can use a
:doc:`special_bonds <special_bonds>` command that includes all pairs in the
neighbor list.
If you desire a breakdown of the interactions into a pairwise and
Kspace component, simply invoke the compute twice with the appropriate
@ -132,20 +133,21 @@ Output info
"""""""""""
This compute calculates a global scalar (the energy) and a global
vector of length 3 (force), which can be accessed by indices 1-3.
vector of length 3 (force), which can be accessed by indices 1--3.
These values can be used by any command that uses global scalar or
vector values from a compute as input. See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
vector values from a compute as input. See the
:doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
options.
Both the scalar and vector values calculated by this compute are
"extensive". The scalar value will be in energy :doc:`units <units>`.
"extensive." The scalar value will be in energy :doc:`units <units>`.
The vector values will be in force :doc:`units <units>`.
Restrictions
""""""""""""
Not all pair styles can be evaluated in a pairwise mode as required by
this compute. For example, 3-body and other many-body potentials,
this compute. For example, three-body and other many-body potentials,
such as :doc:`Tersoff <pair_tersoff>` and
:doc:`Stillinger-Weber <pair_sw>` cannot be used. :doc:`EAM <pair_eam>`
potentials will re-use previously computed embedding term contributions,

37
doc/src/compute_gyration.rst
View File

@ -6,7 +6,7 @@ compute gyration command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID gyration
@ -23,51 +23,54 @@ Examples
Description
"""""""""""
Define a computation that calculates the radius of gyration Rg of the
Define a computation that calculates the radius of gyration :math:`R_g` of the
group of atoms, including all effects due to atoms passing through
periodic boundaries.
Rg is a measure of the size of the group of atoms, and is computed as
the square root of the Rg\^2 value in this formula
:math:`R_g` is a measure of the size of the group of atoms, and is computed as
the square root of the :math:`R_g^2` value in this formula
.. math::
{R_g}^2 = \frac{1}{M} \sum_i m_i (r_i - r_{cm})^2
R_g^2 = \frac{1}{M} \sum_i m_i (r_i - r_{\text{cm}})^2
where :math:`M` is the total mass of the group, :math:`r_{cm}` is the
where :math:`M` is the total mass of the group, :math:`r_{\text{cm}}` is the
center-of-mass position of the group, and the sum is over all atoms in
the group.
A :math:`{R_g}^2` tensor, stored as a 6-element vector, is also calculated
A :math:`R_g^2` tensor, stored as a 6-element vector, is also calculated
by this compute. The formula for the components of the tensor is the
same as the above formula, except that :math:`(r_i - r_{cm})^2` is replaced
by :math:`(r_{i,x} - r_{cm,x}) \cdot (r_{i,y} - r_{cm,y})` for the xy component,
and so on. The 6 components of the vector are ordered xx, yy, zz, xy, xz, yz.
Note that unlike the scalar :math:`R_g`, each of the 6 values of the tensor
same as the above formula, except that :math:`(r_i - r_{\text{cm}})^2` is
replaced by
:math:`(r_{i,x} - r_{\text{cm},x}) \cdot (r_{i,y} - r_{\text{cm},y})` for the
:math:`xy` component, and so on. The six components of the vector are ordered
:math:`xx`, :math:`yy`, :math:`zz`, :math:`xy`, :math:`xz`, :math:`yz`.
Note that unlike the scalar :math:`R_g`, each of the six values of the tensor
is effectively a "squared" value, since the cross-terms may be negative
and taking a sqrt() would be invalid.
and taking a square root would be invalid.
.. note::
The coordinates of an atom contribute to :math:`R_g` in "unwrapped" form,
by using the image flags associated with each atom. See the :doc:`dump custom <dump>` command for a discussion of "unwrapped" coordinates.
by using the image flags associated with each atom. See the
:doc:`dump custom <dump>` command for a discussion of "unwrapped" coordinates.
See the Atoms section of the :doc:`read_data <read_data>` command for a
discussion of image flags and how they are set for each atom. You can
reset the image flags (e.g. to 0) before invoking this compute by
reset the image flags (e.g., to 0) before invoking this compute by
using the :doc:`set image <set>` command.
Output info
"""""""""""
This compute calculates a global scalar (:math:`R_g`) and a global vector of
length 6 (:math:`{R_g}^2` tensor), which can be accessed by indices 1-6. These
length 6 (:math:`R_g^2` tensor), which can be accessed by indices 1--6. These
values can be used by any command that uses a global scalar value or
vector values from a compute as input. See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
options.
The scalar and vector values calculated by this compute are
"intensive". The scalar and vector values will be in distance and
distance\^2 :doc:`units <units>` respectively.
"intensive." The scalar and vector values will be in distance and
distance\ :math:`^2` :doc:`units <units>`, respectively.
Restrictions
""""""""""""

38
doc/src/compute_gyration_chunk.rst
View File

@ -6,7 +6,7 @@ compute gyration/chunk command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID gyration/chunk chunkID keyword value ...
@ -31,28 +31,31 @@ Examples
Description
"""""""""""
Define a computation that calculates the radius of gyration Rg for
Define a computation that calculates the radius of gyration :math:`R_g` for
multiple chunks of atoms.
In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
In LAMMPS, chunks are collections of atoms defined by a
:doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` and :doc:`Howto chunk <Howto_chunk>`
molecule or atoms in a spatial bin.
See the :doc:`compute chunk/atom <compute_chunk_atom>` and
:doc:`Howto chunk <Howto_chunk>`
doc pages for details of how chunks can be defined and examples of how
they can be used to measure properties of a system.
This compute calculates the radius of gyration Rg for each chunk,
This compute calculates the radius of gyration :math:`R_g` for each chunk,
which includes all effects due to atoms passing through periodic
boundaries.
Rg is a measure of the size of a chunk, and is computed by this
:math:`R_g` is a measure of the size of a chunk, and is computed by the
formula
.. math::
{R_g}^2 = \frac{1}{M} \sum_i m_i (r_i - r_{cm})^2
R_g^2 = \frac{1}{M} \sum_i m_i (r_i - r_{\text{cm}})^2
where :math:`M` is the total mass of the chunk, :math:`r_{cm}` is
where :math:`M` is the total mass of the chunk, :math:`r_{\text{cm}}` is
the center-of-mass position of the chunk, and the sum is over all atoms in the
chunk.
@ -64,13 +67,13 @@ thus also not contribute to this calculation. You can specify the
"all" group for this command if you simply want to include atoms with
non-zero chunk IDs.
If the *tensor* keyword is specified, then the scalar Rg value is not
calculated, but an Rg tensor is instead calculated for each chunk.
If the *tensor* keyword is specified, then the scalar :math:`R_g` value is not
calculated, but an :math:`R_g` tensor is instead calculated for each chunk.
The formula for the components of the tensor is the same as the above
formula, except that :math:`(r_i - r_{cm})^2` is replaced by
:math:`(r_{i,x} - r_{cm,x}) \cdot (r_{i,y} - r_{cm,y})` for the xy
component, and so on. The 6 components of the tensor are
ordered xx, yy, zz, xy, xz, yz.
formula, except that :math:`(r_i - r_{\text{cm}})^2` is replaced by
:math:`(r_{i,x} - r_{\text{cm},x}) \cdot (r_{i,y} - r_{\text{cm},y})` for the
:math:`xy` component, and so on. The six components of the tensor are
ordered :math:`xx`, :math:`yy`, :math:`zz`, :math:`xy`, :math:`xz`, :math:`yz`.
.. note::
@ -79,7 +82,7 @@ ordered xx, yy, zz, xy, xz, yz.
command for a discussion of "unwrapped" coordinates.
See the Atoms section of the :doc:`read_data <read_data>` command for a
discussion of image flags and how they are set for each atom. You can
reset the image flags (e.g. to 0) before invoking this compute by
reset the image flags (e.g., to 0) before invoking this compute by
using the :doc:`set image <set>` command.
The simplest way to output the results of the compute gyration/chunk
@ -98,8 +101,9 @@ Output info
This compute calculates a global vector if the *tensor* keyword is not
specified and a global array if it is. The length of the vector or
number of rows in the array = the number of chunks *Nchunk* as
calculated by the specified :doc:`compute chunk/atom <compute_chunk_atom>` command. If the *tensor* keyword
is specified, the global array has 6 columns. The vector or array can
calculated by the specified :doc:`compute chunk/atom <compute_chunk_atom>`
command. If the *tensor* keyword is specified, the global array has six
columns. The vector or array can
be accessed by any command that uses global values from a compute as
input. See the :doc:`Howto output <Howto_output>` page for an
overview of LAMMPS output options.

60
doc/src/compute_gyration_shape.rst
View File

@ -6,7 +6,7 @@ compute gyration/shape command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID gyration/shape compute-ID
@ -28,30 +28,33 @@ Define a computation that calculates the eigenvalues of the gyration tensor of a
group of atoms and three shape parameters. The computation includes all effects
due to atoms passing through periodic boundaries.
The three computed shape parameters are the asphericity, b, the acylindricity, c,
and the relative shape anisotropy, k:
The three computed shape parameters are the asphericity, :math:`b`,
the acylindricity, :math:`c`, and the relative shape anisotropy, :math:`k`,
viz.,
.. math::
c = & l_z - 0.5(l_y+l_x) \\
b = & l_y - l_x \\
k = & \frac{3}{2} \frac{l_x^2+l_y^2+l_z^2}{(l_x+l_y+l_z)^2} - \frac{1}{2}
b &= l_z - \frac12(l_y+l_x) \\
c &= l_y - l_x \\
k &= \frac{3}{2} \frac{l_x^2+l_y^2+l_z^2}{(l_x+l_y+l_z)^2} - \frac{1}{2}
where :math:`l_x` <= :math:`l_y` <= :math:`l_z` are the three eigenvalues of the gyration tensor. A general description
of these parameters is provided in :ref:`(Mattice) <Mattice1>` while an application to polymer systems
where :math:`l_x \le l_y \le l_z` are the three eigenvalues of the gyration
tensor. A general description of these parameters is provided in
:ref:`(Mattice) <Mattice1>` while an application to polymer systems
can be found in :ref:`(Theodorou) <Theodorou1>`.
The asphericity is always non-negative and zero only when the three principal
moments are equal. This zero condition is met when the distribution of particles
is spherically symmetric (hence the name asphericity) but also whenever the particle
distribution is symmetric with respect to the three coordinate axes, e.g.,
when the particles are distributed uniformly on a cube, tetrahedron or other Platonic
solid. The acylindricity is always non-negative and zero only when the two principal
moments are equal. This zero condition is met when the distribution of particles is
cylindrically symmetric (hence the name, acylindricity), but also whenever the particle
distribution is symmetric with respect to the two coordinate axes, e.g., when the
particles are distributed uniformly on a regular prism. the relative shape anisotropy
is bounded between zero (if all points are spherically symmetric) and one
(if all points lie on a line).
The asphericity is always non-negative and zero only when the three principal
moments are equal. This zero condition is met when the distribution of
particles is spherically symmetric (hence the name asphericity) but also
whenever the particle distribution is symmetric with respect to the three
coordinate axes (e.g., when the particles are distributed uniformly on a cube,
tetrahedron or other Platonic solid). The acylindricity is always non-negative
and zero only when the two principal moments are equal. This zero condition is
met when the distribution of particles is cylindrically symmetric (hence the
name, acylindricity), but also whenever the particle distribution is symmetric
with respect to the two coordinate axes (e.g., when the
particles are distributed uniformly on a regular prism).
The relative shape anisotropy is bounded between zero (if all points are
spherically symmetric) and one (if all points lie on a line).
.. note::
@ -60,22 +63,23 @@ is bounded between zero (if all points are spherically symmetric) and one
See the :doc:`dump custom <dump>` command for a discussion of "unwrapped"
coordinates. See the Atoms section of the :doc:`read_data <read_data>`
command for a discussion of image flags and how they are set for each
atom. You can reset the image flags (e.g. to 0) before invoking this
atom. You can reset the image flags (e.g., to 0) before invoking this
compute by using the :doc:`set image <set>` command.
Output info
"""""""""""
This compute calculates a global vector of
length 6, which can be accessed by indices 1-6. The first three values are the
eigenvalues of the gyration tensor followed by the asphericity, the acylindricity
and the relative shape anisotropy. The computed values can be used by any command
that uses global vector values from a compute as input. See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
This compute calculates a global vector of length 6, which can be accessed by
indices 1--6. The first three values are the eigenvalues of the gyration tensor
followed by the asphericity, the acylindricity and the relative shape
anisotropy. The computed values can be used by any command that uses global
vector values from a compute as input. See the
:doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
options.
The vector values calculated by this compute are
"intensive". The first five vector values will be in
distance\^2 :doc:`units <units>` while the sixth one is dimensionless.
"intensive." The first five vector values will be in
distance\ :math:`2` :doc:`units <units>` while the sixth one is dimensionless.
Restrictions
""""""""""""

59
doc/src/compute_gyration_shape_chunk.rst
View File

@ -6,7 +6,7 @@ compute gyration/shape/chunk command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
compute ID group-ID gyration/shape/chunk compute-ID
@ -28,28 +28,32 @@ Define a computation that calculates the eigenvalues of the gyration tensor and
three shape parameters of multiple chunks of atoms. The computation includes
all effects due to atoms passing through periodic boundaries.
The three computed shape parameters are the asphericity, b, the acylindricity, c,
and the relative shape anisotropy, k:
The three computed shape parameters are the asphericity, :math:`b`,
the acylindricity, :math:`c`, and the relative shape anisotropy, :math:`k`,
viz.,
.. math::
c = & l_z - 0.5(l_y+l_x) \\
b = & l_y - l_x \\
k = & \frac{3}{2} \frac{l_x^2+l_y^2+l_z^2}{(l_x+l_y+l_z)^2} - \frac{1}{2}
b &= l_z - \frac12(l_y+l_x) \\
c &= l_y - l_x \\
k &= \frac{3}{2} \frac{l_x^2+l_y^2+l_z^2}{(l_x+l_y+l_z)^2} - \frac{1}{2}
where :math:`l_x` <= :math:`l_y` <= :math:`l_z` are the three eigenvalues of the gyration tensor. A general description
of these parameters is provided in :ref:`(Mattice) <Mattice2>` while an application to polymer systems
can be found in :ref:`(Theodorou) <Theodorou2>`. The asphericity is always non-negative and zero
only when the three principal moments are equal. This zero condition is met when the distribution
of particles is spherically symmetric (hence the name asphericity) but also whenever the particle
distribution is symmetric with respect to the three coordinate axes, e.g.,
when the particles are distributed uniformly on a cube, tetrahedron or other Platonic
solid. The acylindricity is always non-negative and zero only when the two principal
moments are equal. This zero condition is met when the distribution of particles is
cylindrically symmetric (hence the name, acylindricity), but also whenever the particle
distribution is symmetric with respect to the two coordinate axes, e.g., when the
particles are distributed uniformly on a regular prism. the relative shape anisotropy
is bounded between zero (if all points are spherically symmetric) and one
where :math:`l_x \le l_y \le l_z` are the three eigenvalues of the gyration
tensor. A general description of these parameters is provided in
:ref:`(Mattice) <Mattice2>` while an application to polymer systems
can be found in :ref:`(Theodorou) <Theodorou2>`. The asphericity is always
non-negative and zero only when the three principal moments are equal.
This zero condition is met when the distribution of particles is spherically
symmetric (hence the name asphericity) but also whenever the particle
distribution is symmetric with respect to the three coordinate axes (e.g.,
when the particles are distributed uniformly on a cube, tetrahedron, or other
Platonic solid). The acylindricity is always non-negative and zero only when
the two principal moments are equal. This zero condition is met when the
distribution of particles is cylindrically symmetric (hence the name,
acylindricity), but also whenever the particle distribution is symmetric with
respect to the two coordinate axes (e.g., when the particles are distributed
uniformly on a regular prism). The relative shape anisotropy
is bounded between 0 (if all points are spherically symmetric) and 1
(if all points lie on a line).
The tensor keyword must be specified in the compute gyration/chunk command.
@ -61,22 +65,23 @@ The tensor keyword must be specified in the compute gyration/chunk command.
See the :doc:`dump custom <dump>` command for a discussion of "unwrapped"
coordinates. See the Atoms section of the :doc:`read_data <read_data>`
command for a discussion of image flags and how they are set for each
atom. You can reset the image flags (e.g. to 0) before invoking this
atom. You can reset the image flags (e.g., to 0) before invoking this
compute by using the :doc:`set image <set>` command.
Output info
"""""""""""
This compute calculates a global array with six columns,
which can be accessed by indices 1-6. The first three columns are the
eigenvalues of the gyration tensor followed by the asphericity, the acylindricity
and the relative shape anisotropy. The computed values can be used by any command
that uses global array values from a compute as input. See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
options.
which can be accessed by indices 1--6. The first three columns are the
eigenvalues of the gyration tensor followed by the asphericity, the
acylindricity and the relative shape anisotropy. The computed values can be
used by any command that uses global array values from a compute as input.
See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS
output options.
The array calculated by this compute is
"intensive". The first five columns will be in
distance\^2 :doc:`units <units>` while the sixth one is dimensionless.
"intensive." The first five columns will be in
distance\ :math:`^2` :doc:`units <units>` while the sixth one is dimensionless.
Restrictions
""""""""""""

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