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

Merge branch 'master' into bond_gaussian

Browse Source
This commit is contained in:
Axel Kohlmeyer
2020-11-25 15:50:54 -05:00
parent af179f9901 7cb644b425
commit abdfcceab2
303 changed files with 39068 additions and 5556 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/src/Build_development.rst
View File

@ -111,8 +111,10 @@ error margin). The status of this automated testing can be viewed on
The unit testing facility is integrated into the CMake build process
of the LAMMPS source code distribution itself. It can be enabled by
setting ``-D ENABLE_TESTING=on`` during the CMake configuration step.
It requires the `PyYAML <http://pyyaml.org/>`_ library and development
headers to compile and will download and compile a recent version of the
It requires the `YAML <http://pyyaml.org/>`_ library and development
headers (if not found locally a recent version will be downloaded
and compiled transparently) to compile and will download and compile
a specific recent version of the
`Googletest <https://github.com/google/googletest/>`_ C++ test framework
for implementing the tests.

4
doc/src/Build_manual.rst
View File

@ -73,8 +73,8 @@ after the documentation folder is returned to a pristine state with
For the documentation build a python virtual environment is set up in
the folder ``doc/docenv`` and various python packages are installed into
that virtual environment via the ``pip`` tool. For rendering embedded
LaTeX code also the `MathJax <https://www.mathjax.org/>`_ and the
`Polyfill <https://polyfill.io/>`_ JavaScript engines need to be downloaded.
LaTeX code also the `MathJax <https://www.mathjax.org/>`_ JavaScript
engine needs to be downloaded.
The actual translation is then done via ``make`` commands in the doc
folder. The following ``make`` commands are available:

2
doc/src/Commands_fix.rst
View File

@ -195,7 +195,7 @@ OPT.
* :doc:`saed/vtk <fix_saed_vtk>`
* :doc:`setforce (k) <fix_setforce>`
* :doc:`setforce/spin <fix_setforce>`
* :doc:`shake <fix_shake>`
* :doc:`shake (k) <fix_shake>`
* :doc:`shardlow (k) <fix_shardlow>`
* :doc:`smd <fix_smd>`
* :doc:`smd/adjust_dt <fix_smd_adjust_dt>`

1
doc/src/Commands_pair.rst
View File

@ -241,6 +241,7 @@ OPT.
* :doc:`spin/dipole/long <pair_spin_dipole>`
* :doc:`spin/dmi <pair_spin_dmi>`
* :doc:`spin/exchange <pair_spin_exchange>`
* :doc:`spin/exchange/biquadratic <pair_spin_exchange>`
* :doc:`spin/magelec <pair_spin_magelec>`
* :doc:`spin/neel <pair_spin_neel>`
* :doc:`srp <pair_srp>`

1
doc/src/Errors_warnings.rst
View File

@ -119,7 +119,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
:doc:`pair style zero <pair_zero>` with a suitable cutoff or use :doc:`comm_modify cutoff <comm_modify>`.
*Communication cutoff is shorter than a bond length based estimate. This may lead to errors.*
Since LAMMPS stores topology data with individual atoms, all atoms
comprising a bond, angle, dihedral or improper must be present on any
sub-domain that "owns" the atom with the information, either as a

4
doc/src/Howto_github.rst
View File

@ -72,7 +72,7 @@ explained in more detail here: `feature branch workflow <https://www.atlassian.c
**Feature branches**
First of all, create a clone of your version on github on your local
First of all, create a clone of your version on GitHub on your local
machine via HTTPS:
.. code-block:: bash
@ -155,7 +155,7 @@ useful message that explains the change.
.. code-block:: bash
$ git commit -m 'Finally updated the github tutorial'
$ git commit -m 'Finally updated the GitHub tutorial'
After the commit, the changes can be pushed to the same branch on GitHub:

2
doc/src/Howto_walls.rst
View File

@ -67,5 +67,5 @@ rotate.
The only frictional idealized walls currently in LAMMPS are flat or
curved surfaces specified by the :doc:`fix wall/gran <fix_wall_gran>`
command. At some point we plan to allow regoin surfaces to be used as
command. At some point we plan to allow region surfaces to be used as
frictional walls, as well as triangulated surfaces.

12
doc/src/Intro_citing.rst
View File

@ -24,13 +24,15 @@ DOI for the LAMMPS code
LAMMPS developers use the `Zenodo service at CERN
<https://zenodo.org/>`_ to create digital object identifies (DOI) for
stable releases of the LAMMPS code. There are two types of DOIs for the
LAMMPS source code: 1) the canonical DOI for **all** versions of LAMMPS,
which will always point to the latest stable release version is:
LAMMPS source code: the canonical DOI for **all** versions of LAMMPS,
which will always point to the **latest** stable release version is:
`DOI: 10.5281/zenodo.3726416 <https://dx.doi/org/10.5281/zenodo.3726416>`_
- DOI: `10.5281/zenodo.3726416 <https://dx.doi.org/10.5281/zenodo.3726416>`_
In addition there are DOIs for individual stable releases starting with
the `3 March 2020 version, DOI:10.5281/zenodo.3726417 <https://dx.doi/org/10.5281/zenodo.3726416>`_
In addition there are DOIs for individual stable releases. Currently there are:
- 3 March 2020 version: `DOI:10.5281/zenodo.3726417 <https://dx.doi.org/10.5281/zenodo.3726417>`_
- 29 October 2020 version: `DOI:10.5281/zenodo.4157471 <https://dx.doi.org/10.5281/zenodo.4157471>`_
Home page

11
doc/src/Library_create.rst
View File

@ -9,7 +9,6 @@ This section documents the following functions:
- :cpp:func:`lammps_close`
- :cpp:func:`lammps_mpi_init`
- :cpp:func:`lammps_mpi_finalize`
- :cpp:func:`lammps_free`
--------------------
@ -75,11 +74,6 @@ that may only be called once. See :cpp:func:`lammps_mpi_finalize` for
an alternative to invoking ``MPI_Finalize()`` explicitly from the
calling program.
The :cpp:func:`lammps_free` function is a clean-up
function to free memory that the library allocated previously
via other function calls. See below for notes in the descriptions
of the individual commands where such memory buffers were allocated.
-----------------------
.. doxygenfunction:: lammps_open
@ -109,8 +103,3 @@ of the individual commands where such memory buffers were allocated.
.. doxygenfunction:: lammps_mpi_finalize
:project: progguide
-----------------------
.. doxygenfunction:: lammps_free
:project: progguide

12
doc/src/Library_utility.rst
View File

@ -9,11 +9,18 @@ functions. They do not directly call the LAMMPS library.
- :cpp:func:`lammps_set_fix_external_callback`
- :cpp:func:`lammps_fix_external_set_energy_global`
- :cpp:func:`lammps_fix_external_set_virial_global`
- :cpp:func:`lammps_free`
- :cpp:func:`lammps_is_running`
- :cpp:func:`lammps_force_timeout`
- :cpp:func:`lammps_has_error`
- :cpp:func:`lammps_get_last_error_message`
The :cpp:func:`lammps_free` function is a clean-up function to free
memory that the library had allocated previously via other function
calls. Look for notes in the descriptions of the individual commands
where such memory buffers were allocated that require the use of
:cpp:func:`lammps_free`.
-----------------------
.. doxygenfunction:: lammps_encode_image_flags
@ -41,6 +48,11 @@ functions. They do not directly call the LAMMPS library.
-----------------------
.. doxygenfunction:: lammps_free
:project: progguide
-----------------------
.. doxygenfunction:: lammps_is_running
:project: progguide

26
doc/src/Manual.rst
View File

@ -21,10 +21,16 @@ where all LAMMPS development is coordinated.
----------
The content for this manual is part of the LAMMPS distribution. You can
build a local copy of the Manual as HTML pages or a PDF file, by
following the steps on the :doc:`Build_manual` page. The manual is
organized in two parts:
The content for this manual is part of the LAMMPS distribution. The
online version always corresponds to the latest development version.
If needed, you can download or build a local copy of the manual as
HTML pages or a PDF file by following the steps on the
:doc:`Build_manual` page. If you have difficulties viewing the pages
please :ref:`see this note <webbrowser>`.
-----------
The manual is organized in two parts:
1) the :ref:`User Guide <user_documentation>` for how to install
and use LAMMPS and 2) the :ref:`Programmer Guide <programmer_documentation>`
for how to write programs using the LAMMPS library from different
@ -107,3 +113,15 @@ Indices and tables
* :ref:`genindex`
* :ref:`search`
.. _webbrowser:
.. admonition:: Web Browser Compatibility
The HTML version of the manual makes use of advanced features present
int "modern" web browsers. This can lead to incompatibilities with older
web browsers (released more than 4 years ago) and specific vendor browsers
(e.g. Internet Explorer on Windows; Microsoft Edge works well though)
where parts of the pages are not rendered as expected (e.g. the layout is
broken or mathematical expressions not typeset). In that case we
recommend to install/use a different/newer web browser or use
the `PDF version of the manual <https://lammps.sandia.gov/doc/Manual.pdf>`_.

2
doc/src/Packages_details.rst
View File

@ -1036,9 +1036,11 @@ the usual manner via MD. Various pair, fix, and compute styles.
* :doc:`pair_style spin/dipole/long <pair_spin_dipole>`
* :doc:`pair_style spin/dmi <pair_spin_dmi>`
* :doc:`pair_style spin/exchange <pair_spin_exchange>`
* :doc:`pair_style spin/exchange/biquadratic <pair_spin_exchange>`
* :doc:`pair_style spin/magelec <pair_spin_magelec>`
* :doc:`pair_style spin/neel <pair_spin_neel>`
* :doc:`fix nve/spin <fix_nve_spin>`
* :doc:`fix langevin/spin <fix_langevin_spin>`
* :doc:`fix precession/spin <fix_precession_spin>`
* :doc:`compute spin <compute_spin>`
* :doc:`neb/spin <neb_spin>`

19
doc/src/Run_options.rst
View File

@ -62,15 +62,18 @@ used.
**-in file**
Specify a file to use as an input script. This is an optional switch
when running LAMMPS in one-partition mode. If it is not specified,
LAMMPS reads its script from standard input, typically from a script
via I/O redirection; e.g. lmp_linux < in.run. I/O redirection should
also work in parallel, but if it does not (in the unlikely case that
an MPI implementation does not support it), then use the -in flag.
Specify a file to use as an input script. This is an optional but
recommended switch when running LAMMPS in one-partition mode. If it
is not specified, LAMMPS reads its script from standard input, typically
from a script via I/O redirection; e.g. lmp_linux < in.run.
With many MPI implementations I/O redirection also works in parallel,
but using the -in flag will always work.
Note that this is a required switch when running LAMMPS in
multi-partition mode, since multiple processors cannot all read from
stdin.
stdin concurrently. The file name may be "none" for starting
multi-partition calculations without reading an initial input file
from the library interface.
----------
@ -296,7 +299,7 @@ command-line option.
**-pscreen file**
Specify the base name for the partition screen file, so partition N
writes screen information to file.N. If file is none, then no
writes screen information to file.N. If file is "none", then no
partition screen files are created. This overrides the filename
specified in the -screen command-line option. This option is useful
when working with large numbers of partitions, allowing the partition

2
doc/src/atc_output.rst
View File

@ -14,7 +14,7 @@ Syntax
* AtC fixID = ID of :doc:`fix atc <fix_atc>` instance
* *output* or *output index* = name of the AtC sub-command
* filename_prefix = prefix for data files (for *output*)
* frequency = frequency of output in time-steps (for *output*)
* frequency = frequency of output in timesteps (for *output*)
* optional keywords for *output*:
- text = creates text output of index, step and nodal variable values for unique nodes

3
doc/src/atom_style.rst
View File

@ -42,6 +42,7 @@ Examples
atom_style hybrid charge body nparticle 2 5
atom_style spin
atom_style template myMols
atom_style hybrid template twomols charge
atom_style tdpd 2
Description
@ -239,6 +240,8 @@ can save memory for systems comprised of a large number of small
molecules, all of a single type (or small number of types). See the
paper by Grime and Voth, in :ref:`(Grime) <Grime>`, for examples of how this
can be advantageous for large-scale coarse-grained systems.
The ``examples/template`` directory has a few demo inputs and examples
showing the use of the *template* atom style versus *molecular*.
.. note::

236
doc/src/compute_stress_atom.rst
View File

@ -33,32 +33,31 @@ Examples
Description
"""""""""""
Define a computation that computes per-atom stress
tensor for each atom in a group. In case of compute *stress/atom*,
the tensor for each atom is symmetric with 6
components and is stored as a 6-element vector in the following order:
:math:`xx`, :math:`yy`, :math:`zz`, :math:`xy`, :math:`xz`, :math:`yz`.
In case of compute *centroid/stress/atom*,
the tensor for each atom is asymmetric with 9 components
and is stored as a 9-element vector in the following order:
:math:`xx`, :math:`yy`, :math:`zz`, :math:`xy`, :math:`xz`, :math:`yz`,
:math:`yx`, :math:`zx`, :math:`zy`.
See the :doc:`compute pressure <compute_pressure>` command if you want the stress tensor
Define a computation that computes per-atom stress tensor for each
atom in a group. In case of compute *stress/atom*, the tensor for
each atom is symmetric with 6 components and is stored as a 6-element
vector in the following order: :math:`xx`, :math:`yy`, :math:`zz`,
:math:`xy`, :math:`xz`, :math:`yz`. In case of compute
*centroid/stress/atom*, the tensor for each atom is asymmetric with 9
components and is stored as a 9-element vector in the following order:
:math:`xx`, :math:`yy`, :math:`zz`, :math:`xy`, :math:`xz`,
:math:`yz`, :math:`yx`, :math:`zx`, :math:`zy`. See the :doc:`compute
pressure <compute_pressure>` command if you want the stress tensor
(pressure) of the entire system.
The stress tensor for atom :math:`I` is given by the following formula,
where :math:`a` and :math:`b` take on values :math:`x`, :math:`y`, :math:`z`
to generate the components of the tensor:
The stress tensor for atom :math:`I` is given by the following
formula, where :math:`a` and :math:`b` take on values :math:`x`,
:math:`y`, :math:`z` to generate the components of the tensor:
.. math::
S_{ab} = - m v_a v_b - W_{ab}
The first term is a kinetic energy contribution for atom :math:`I`. See
details below on how the specified *temp-ID* can affect the velocities
used in this calculation. The second term is the virial
contribution due to intra and intermolecular interactions,
where the exact computation details are determined by the compute style.
The first term is a kinetic energy contribution for atom :math:`I`.
See details below on how the specified *temp-ID* can affect the
velocities used in this calculation. The second term is the virial
contribution due to intra and intermolecular interactions, where the
exact computation details are determined by the compute style.
In case of compute *stress/atom*, the virial contribution is:
@ -68,29 +67,26 @@ In case of compute *stress/atom*, the virial contribution is:
& + \frac{1}{3} \sum_{n = 1}^{N_a} (r_{1_a} F_{1_b} + r_{2_a} F_{2_b} + r_{3_a} F_{3_b}) + \frac{1}{4} \sum_{n = 1}^{N_d} (r_{1_a} F_{1_b} + r_{2_a} F_{2_b} + r_{3_a} F_{3_b} + r_{4_a} F_{4_b}) \\
& + \frac{1}{4} \sum_{n = 1}^{N_i} (r_{1_a} F_{1_b} + r_{2_a} F_{2_b} + r_{3_a} F_{3_b} + r_{4_a} F_{4_b}) + {\rm Kspace}(r_{i_a},F_{i_b}) + \sum_{n = 1}^{N_f} r_{i_a} F_{i_b}
The first term is a pairwise energy
contribution where :math:`n` loops over the :math:`N_p`
neighbors of atom :math:`I`, :math:`\mathbf{r}_1` and :math:`\mathbf{r}_2`
are the positions of the 2 atoms in the pairwise interaction,
and :math:`\mathbf{F}_1` and :math:`\mathbf{F}_2` are the forces
on the 2 atoms resulting from the pairwise interaction.
The second term is a bond contribution of
similar form for the :math:`N_b` bonds which atom :math:`I` is part of.
There are similar terms for the :math:`N_a` angle, :math:`N_d` dihedral,
and :math:`N_i` improper interactions atom :math:`I` is part of.
There is also a term for the KSpace
contribution from long-range Coulombic interactions, if defined.
Finally, there is a term for the :math:`N_f` :doc:`fixes <fix>` that apply
internal constraint forces to atom :math:`I`. Currently, only the
:doc:`fix shake <fix_shake>` and :doc:`fix rigid <fix_rigid>` commands
contribute to this term.
As the coefficients in the formula imply, a virial contribution
produced by a small set of atoms (e.g. 4 atoms in a dihedral or 3
atoms in a Tersoff 3-body interaction) is assigned in equal portions
to each atom in the set. E.g. 1/4 of the dihedral virial to each of
the 4 atoms, or 1/3 of the fix virial due to SHAKE constraints applied
to atoms in a water molecule via the :doc:`fix shake <fix_shake>`
command.
The first term is a pairwise energy contribution where :math:`n` loops
over the :math:`N_p` neighbors of atom :math:`I`, :math:`\mathbf{r}_1`
and :math:`\mathbf{r}_2` are the positions of the 2 atoms in the
pairwise interaction, and :math:`\mathbf{F}_1` and
:math:`\mathbf{F}_2` are the forces on the 2 atoms resulting from the
pairwise interaction. The second term is a bond contribution of
similar form for the :math:`N_b` bonds which atom :math:`I` is part
of. There are similar terms for the :math:`N_a` angle, :math:`N_d`
dihedral, and :math:`N_i` improper interactions atom :math:`I` is part
of. There is also a term for the KSpace contribution from long-range
Coulombic interactions, if defined. Finally, there is a term for the
:math:`N_f` :doc:`fixes <fix>` that apply internal constraint forces
to atom :math:`I`. Currently, only the :doc:`fix shake <fix_shake>`
and :doc:`fix rigid <fix_rigid>` commands contribute to this term. As
the coefficients in the formula imply, a virial contribution produced
by a small set of atoms (e.g. 4 atoms in a dihedral or 3 atoms in a
Tersoff 3-body interaction) is assigned in equal portions to each atom
in the set. E.g. 1/4 of the dihedral virial to each of the 4 atoms,
or 1/3 of the fix virial due to SHAKE constraints applied to atoms in
a water molecule via the :doc:`fix shake <fix_shake>` command.
In case of compute *centroid/stress/atom*, the virial contribution is:
@ -99,71 +95,69 @@ In case of compute *centroid/stress/atom*, the virial contribution is:
W_{ab} & = \sum_{n = 1}^{N_p} r_{I0_a} F_{I_b} + \sum_{n = 1}^{N_b} r_{I0_a} F_{I_b} + \sum_{n = 1}^{N_a} r_{I0_a} F_{I_b} + \sum_{n = 1}^{N_d} r_{I0_a} F_{I_b} + \sum_{n = 1}^{N_i} r_{I0_a} F_{I_b} \\
& + {\rm Kspace}(r_{i_a},F_{i_b}) + \sum_{n = 1}^{N_f} r_{i_a} F_{i_b}
As with compute *stress/atom*, the first, second, third, fourth and fifth terms
are pairwise, bond, angle, dihedral and improper contributions,
but instead of assigning the virial contribution equally to each atom,
only the force :math:`\mathbf{F}_I` acting on atom :math:`I`
due to the interaction and the relative
position :math:`\mathbf{r}_{I0}` of the atom :math:`I` to the geometric center
of the interacting atoms, i.e. centroid, is used.
As the geometric center is different
for each interaction, the :math:`\mathbf{r}_{I0}` also differs.
The sixth and seventh terms, Kspace and :doc:`fix <fix>` contribution
respectively, are computed identical to compute *stress/atom*.
Although the total system virial is the same as compute *stress/atom*,
compute *centroid/stress/atom* is know to result in more consistent
heat flux values for angle, dihedrals and improper contributions
when computed via :doc:`compute heat/flux <compute_heat_flux>`.
As with compute *stress/atom*, the first, second, third, fourth and
fifth terms are pairwise, bond, angle, dihedral and improper
contributions, but instead of assigning the virial contribution
equally to each atom, only the force :math:`\mathbf{F}_I` acting on
atom :math:`I` due to the interaction and the relative position
:math:`\mathbf{r}_{I0}` of the atom :math:`I` to the geometric center
of the interacting atoms, i.e. centroid, is used. As the geometric
center is different for each interaction, the :math:`\mathbf{r}_{I0}`
also differs. The sixth and seventh terms, Kspace and :doc:`fix
<fix>` contribution respectively, are computed identical to compute
*stress/atom*. Although the total system virial is the same as
compute *stress/atom*, compute *centroid/stress/atom* is know to
result in more consistent heat flux values for angle, dihedrals and
improper contributions when computed via :doc:`compute heat/flux
<compute_heat_flux>`.
If no extra keywords are listed, the kinetic contribution
all of the virial contribution terms are
included in the per-atom stress tensor. If any extra keywords are
listed, only those terms are summed to compute the tensor. The
*virial* keyword means include all terms except the kinetic energy
*ke*\ .
If no extra keywords are listed, the kinetic contribution all of the
virial contribution terms are included in the per-atom stress tensor.
If any extra keywords are listed, only those terms are summed to
compute the tensor. The *virial* keyword means include all terms
except the kinetic energy *ke*\ .
Note that the stress for each atom is due to its interaction with all
other atoms in the simulation, not just with other atoms in the group.
Details of how compute *stress/atom* obtains the virial for individual atoms for
either pairwise or many-body potentials, and including the effects of
periodic boundary conditions is discussed in :ref:`(Thompson) <Thompson2>`.
The basic idea for many-body potentials is to treat each component of
the force computation between a small cluster of atoms in the same
manner as in the formula above for bond, angle, dihedral, etc
interactions. Namely the quantity :math:`\mathbf{r} \cdot \mathbf{F}`
is summed over the atoms in
the interaction, with the :math:`r` vectors unwrapped by periodic boundaries
so that the cluster of atoms is close together. The total
Details of how compute *stress/atom* obtains the virial for individual
atoms for either pairwise or many-body potentials, and including the
effects of periodic boundary conditions is discussed in
:ref:`(Thompson) <Thompson2>`. The basic idea for many-body
potentials is to treat each component of the force computation between
a small cluster of atoms in the same manner as in the formula above
for bond, angle, dihedral, etc interactions. Namely the quantity
:math:`\mathbf{r} \cdot \mathbf{F}` is summed over the atoms in the
interaction, with the :math:`r` vectors unwrapped by periodic
boundaries so that the cluster of atoms is close together. The total
contribution for the cluster interaction is divided evenly among those
atoms. Details of how compute *centroid/stress/atom* obtains
the virial for individual atoms
is given in :ref:`(Surblys) <Surblys1>`,
where the idea is that the virial of the atom :math:`I`
is the result of only the force :math:`\mathbf{F}_I` on the atom due
to the interaction
and its positional vector :math:`\mathbf{r}_{I0}`,
relative to the geometric center of the
interacting atoms, regardless of the number of participating atoms.
The periodic boundary treatment is identical to
atoms.
Details of how compute *centroid/stress/atom* obtains the virial for
individual atoms is given in :ref:`(Surblys) <Surblys1>`, where the
idea is that the virial of the atom :math:`I` is the result of only
the force :math:`\mathbf{F}_I` on the atom due to the interaction and
its positional vector :math:`\mathbf{r}_{I0}`, relative to the
geometric center of the interacting atoms, regardless of the number of
participating atoms. The periodic boundary treatment is identical to
that of compute *stress/atom*, and both of them reduce to identical
expressions for two-body interactions,
i.e. computed values for contributions from bonds and two-body pair styles,
such as :doc:`Lennard-Jones <pair_lj>`, will be the same,
while contributions from angles, dihedrals and impropers will be different.
expressions for two-body interactions, i.e. computed values for
contributions from bonds and two-body pair styles, such as
:doc:`Lennard-Jones <pair_lj>`, will be the same, while contributions
from angles, dihedrals and impropers will be different.
The :doc:`dihedral_style charmm <dihedral_charmm>` style calculates
pairwise interactions between 1-4 atoms. The virial contribution of
these terms is included in the pair virial, not the dihedral virial.
The KSpace contribution is calculated using the method in
:ref:`(Heyes) <Heyes2>` for the Ewald method and by the methodology described
in :ref:`(Sirk) <Sirk1>` for PPPM. The choice of KSpace solver is specified
by the :doc:`kspace_style pppm <kspace_style>` command. Note that for
PPPM, the calculation requires 6 extra FFTs each timestep that
per-atom stress is calculated. Thus it can significantly increase the
cost of the PPPM calculation if it is needed on a large fraction of
the simulation timesteps.
:ref:`(Heyes) <Heyes2>` for the Ewald method and by the methodology
described in :ref:`(Sirk) <Sirk1>` for PPPM. The choice of KSpace
solver is specified by the :doc:`kspace_style pppm <kspace_style>`
command. Note that for PPPM, the calculation requires 6 extra FFTs
each timestep that per-atom stress is calculated. Thus it can
significantly increase the cost of the PPPM calculation if it is
needed on a large fraction of the simulation timesteps.
The *temp-ID* argument can be used to affect the per-atom velocities
used in the kinetic energy contribution to the total stress. If the
@ -189,10 +183,10 @@ See the :doc:`compute voronoi/atom <compute_voronoi_atom>` command for
one possible way to estimate a per-atom volume.
Thus, if the diagonal components of the per-atom stress tensor are
summed for all atoms in the system and the sum is divided by :math:`dV`, where
:math:`d` = dimension and :math:`V` is the volume of the system,
the result should be :math:`-P`, where :math:`P`
is the total pressure of the system.
summed for all atoms in the system and the sum is divided by
:math:`dV`, where :math:`d` = dimension and :math:`V` is the volume of
the system, the result should be :math:`-P`, where :math:`P` is the
total pressure of the system.
These lines in an input script for a 3d system should yield that
result. I.e. the last 2 columns of thermo output will be the same:
@ -207,33 +201,43 @@ result. I.e. the last 2 columns of thermo output will be the same:
.. note::
The per-atom stress does not include any Lennard-Jones tail
corrections to the pressure added by the :doc:`pair_modify tail yes <pair_modify>` command, since those are contributions to the
global system pressure.
corrections to the pressure added by the :doc:`pair_modify tail yes
<pair_modify>` command, since those are contributions to the global
system pressure.
Output info
"""""""""""
This compute *stress/atom* calculates a per-atom array with 6 columns, which can be
accessed by indices 1-6 by any command that uses per-atom values from
a compute as input.
The compute *centroid/stress/atom* produces a per-atom array with 9 columns,
but otherwise can be used in an identical manner to compute *stress/atom*.
See the :doc:`Howto output <Howto_output>` doc page
for an overview of LAMMPS output options.
Compute *stress/atom* calculates a per-atom array with 6 columns,
which can be accessed by indices 1-6 by any command that uses per-atom
values from a compute as input. Compute *centroid/stress/atom*
produces a per-atom array with 9 columns, but otherwise can be used in
an identical manner to compute *stress/atom*. See the :doc:`Howto
output <Howto_output>` doc page for an overview of LAMMPS output
options.
The per-atom array values will be in pressure\*volume
:doc:`units <units>` as discussed above.
The per-atom array values will be in pressure\*volume :doc:`units
<units>` as discussed above.
Restrictions
""""""""""""
Currently (Spring 2020), compute *centroid/stress/atom* does not support
pair styles with many-body interactions, such as :doc:`Tersoff
<pair_tersoff>`, or pair styles with long-range Coulomb interactions.
LAMMPS will generate an error in such cases. In principal, equivalent
formulation to that of angle, dihedral and improper contributions in the
virial :math:`W_{ab}` formula can also be applied to the many-body pair
styles, and is planned in the future.
Currently, compute *centroid/stress/atom* does not support pair styles
with many-body interactions (:doc:`EAM <pair_eam>` is an exception,
since its computations are performed pairwise), nor granular pair
styles with pairwise forces which are not aligned with the vector
between the pair of particles. All bond styles are supported. All
angle, dihedral, improper styles are supported with the exception of
USER-INTEL and KOKKOS variants of specific styles. It also does not
support models with long-range Coulombic or dispersion forces,
i.e. the kspace_style command in LAMMPS. It also does not support the
following fixes which add rigid-body constraints: :doc:`fix shake
<fix_shake>`, :doc:`fix rattle <fix_rattle>`, :doc:`fix rigid
<fix_rigid>`, :doc:`fix rigid/small <fix_rigid>`.
LAMMPS will generate an error if one of these options is included in
your model. Extension of centroid stress calculations to these force
and fix styles is planned for the futre.
Related commands
""""""""""""""""

2
doc/src/create_atoms.rst
View File

@ -28,7 +28,7 @@ Syntax
* zero or more keyword/value pairs may be appended
* keyword = *mol* or *basis* or *ratio* or *subset* or *remap* or *var* or *set* or *rotate* or *units*
.. code-block:: LAMMPS
.. parsed-literal::
*mol* value = template-ID seed
template-ID = ID of molecule template specified in a separate :doc:`molecule <molecule>` command

43
doc/src/fix_bond_react.rst
View File

@ -174,10 +174,12 @@ integer.
Three physical conditions must be met for a reaction to occur. First,
a bonding atom pair must be identified within the reaction distance
cutoffs. Second, the topology surrounding the bonding atom pair must
match the topology of the pre-reaction template. Finally, any reaction
constraints listed in the map file (see below) must be satisfied. If
all of these conditions are met, the reaction site is eligible to be
modified to match the post-reaction template.
match the topology of the pre-reaction template. Only atom types and
bond connectivity are used to identify a valid reaction site (not bond
types, etc.). Finally, any reaction constraints listed in the map file
(see below) must be satisfied. If all of these conditions are met, the
reaction site is eligible to be modified to match the post-reaction
template.
A bonding atom pair will be identified if several conditions are met.
First, a pair of atoms I,J within the specified react-group-ID of type
@ -192,19 +194,26 @@ be a function of the reaction conversion using the following commands:
fix myrxn all bond/react react myrxn1 all 1 0 v_rmax mol1 mol2 map_file.txt
variable rmax equal 3+f_myrxn[1]/100 # arbitrary function of reaction count
It is possible that multiple bonding atom pairs are identified: if the
bonding atoms in the pre-reacted template are 1-2 neighbors, i.e.
directly bonded, the farthest bonding atom partner is set as its
bonding partner; otherwise, the closest potential partner is chosen.
Then, if both an atom I and atom J have each other as their bonding
partners, these two atoms are identified as the bonding atom pair of
the reaction site. Once this unique bonding atom pair is identified
for each reaction, there could two or more reactions that involve a
given atom on the same timestep. If this is the case, only one such
reaction is permitted to occur. This reaction is chosen randomly from
all potential reactions. This capability allows e.g. for different
reaction pathways to proceed from identical reaction sites with
user-specified probabilities.
The following criteria are used if multiple candidate bonding atom
pairs are identified within the cutoff distance: 1) If the bonding
atoms in the pre-reaction template are not 1-2 neighbors (i.e. not
directly bonded) the closest potential partner is chosen. 2)
Otherwise, if the bonding atoms in the pre-reaction template are 1-2
neighbors (i.e. directly bonded) the farthest potential partner is
chosen. 3) Then, if both an atom I and atom J have each other as their
bonding partners, these two atoms are identified as the bonding atom
pair of the reaction site. Note that it can be helpful to select
unique atom types for the bonding atoms: if a bonding atom pair is
identified, as described in the previous steps, but does not
correspond to the same pair specified in the pre-reaction template, an
otherwise eligible reaction could be prevented from occurring. Once
this unique bonding atom pair is identified for each reaction, there
could be two or more reactions that involve the same atom on the same
timestep. If this is the case, only one such reaction is permitted to
occur. This reaction is chosen randomly from all potential reactions
involving the overlapping atom. This capability allows e.g. for
different reaction pathways to proceed from identical reaction sites
with user-specified probabilities.
The pre-reacted molecule template is specified by a molecule command.
This molecule template file contains a sample reaction site and its

2
doc/src/fix_filter_corotate.rst
View File

@ -56,7 +56,7 @@ is slightly modified only for the computation of long-range forces. A
good cluster decomposition constitutes in building clusters which
contain the fastest covalent bonds inside clusters.
If the clusters are chosen suitably, the :doc:`run_style respa <run_style>` is stable for outer time-steps of at least 8fs.
If the clusters are chosen suitably, the :doc:`run_style respa <run_style>` is stable for outer timesteps of at least 8fs.
----------

2
doc/src/fix_precession_spin.rst
View File

@ -62,7 +62,7 @@ with:
The field value in Tesla is multiplied by the gyromagnetic
ratio, :math:`g \cdot \mu_B/\hbar`, converting it into a precession frequency in
rad.THz (in metal units and with :math:`\mu_B = 5.788 eV/T`).
rad.THz (in metal units and with :math:`\mu_B = 5.788\cdot 10^{-5}` eV/T).
As a comparison, the figure below displays the simulation of a
single spin (of norm :math:`\mu_i = 1.0`) submitted to an external

4
doc/src/fix_rx.rst
View File

@ -90,10 +90,10 @@ accepted, *h* is increased by a proportional amount, and the next ODE step is be
Otherwise, *h* is shrunk and the ODE step is repeated.
Run-time diagnostics are available for the rkf45 ODE solver. The frequency
(in time-steps) that diagnostics are reported is controlled by the last (optional)
(in timesteps) that diagnostics are reported is controlled by the last (optional)
12th argument. A negative frequency means that diagnostics are reported once at the
end of each run. A positive value N means that the diagnostics are reported once
per N time-steps.
per N timesteps.
The diagnostics report the average # of integrator steps and RHS function evaluations
and run-time per ODE as well as the average/RMS/min/max per process. If the

3
doc/src/fix_shake.rst
View File

@ -1,9 +1,12 @@
.. index:: fix shake
.. index:: fix shake/kk
.. index:: fix rattle
fix shake command
=================
Accelerator Variants: *shake/kk*
fix rattle command
==================

21
doc/src/molecule.rst
View File

@ -79,9 +79,9 @@ make it easy to use the same molecule file in different molecule
templates or in different simulations. You can specify the same file
multiple times with different optional keywords.
The *offset*\ , *toff*\ , *aoff*\ , *doff*\ , *ioff* keywords add the
specified offset values to the atom types, bond types, angle types,
dihedral types, and/or improper types as they are read from the
The *offset*\ , *toff*\ , *boff*\ , *aoff*\ , *doff*\ , *ioff* keywords
add the specified offset values to the atom types, bond types, angle
types, dihedral types, and/or improper types as they are read from the
molecule file. E.g. if *toff* = 2, and the file uses atom types
1,2,3, then each created molecule will have atom types 3,4,5. For the
*offset* keyword, all five offset values must be specified, but
@ -201,11 +201,12 @@ bonds between nuclear cores and Drude electrons in a different manner.
Each section is listed below in alphabetic order. The format of each
section is described including the number of lines it must contain and
rules (if any) for whether it can appear in the data file. In each
case the ID is ignored; it is simply included for readability, and
should be a number from 1 to Nlines for the section, indicating which
atom (or bond, etc) the entry applies to. The lines are assumed to be
listed in order from 1 to Nlines, but LAMMPS does not check for this.
rules (if any) for whether it can appear in the data file. For per-
atom sections, entries should be numbered from 1 to Natoms (where
Natoms is the number of atoms in the template), indicating which atom
(or bond, etc) the entry applies to. Per-atom sections need to
include a setting for every atom, but the atoms can be listed in any
order.
----------
@ -484,9 +485,7 @@ of SHAKE clusters.
Restrictions
""""""""""""
This command must come after the simulation box is define by a
:doc:`read_data <read_data>`, :doc:`read_restart <read_restart>`, or
:doc:`create_box <create_box>` command.
None
Related commands
""""""""""""""""

2
doc/src/pair_atm.rst
View File

@ -143,7 +143,7 @@ combinations, else an error will result.
Mixing, shift, table, tail correction, restart, rRESPA info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This pair styles do not support the :doc:`pair_modify <pair_modify>`
This pair style do not support the :doc:`pair_modify <pair_modify>`
mix, shift, table, and tail options.
This pair style writes its information to :doc:`binary restart files

2
doc/src/pair_buck_long.rst
View File

@ -117,7 +117,7 @@ global Coulombic cutoff is allowed.
Mixing, shift, table, tail correction, restart, rRESPA info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This pair styles does not support mixing. Thus, coefficients for all
This pair style does not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.
This pair style supports the :doc:`pair_modify <pair_modify>` shift

2
doc/src/pair_gayberne.rst
View File

@ -160,7 +160,7 @@ For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for this pair style can be mixed. The default mix
value is *geometric*\ . See the "pair_modify" command for details.
This pair styles supports the :doc:`pair_modify <pair_modify>` shift
This pair style supports the :doc:`pair_modify <pair_modify>` shift
option for the energy of the Lennard-Jones portion of the pair
interaction, but only for sphere-sphere interactions. There is no
shifting performed for ellipsoidal interactions due to the anisotropic

9
doc/src/pair_lcbop.rst
View File

@ -75,14 +75,15 @@ This pair style can only be used via the *pair* keyword of the
Restrictions
""""""""""""
This pair styles is part of the MANYBODY package. It is only enabled
if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` doc page for more info.
This pair style is part of the MANYBODY package. It is only enabled
if LAMMPS was built with that package.
See the :doc:`Build package <Build_package>` doc page for more info.
This pair potential requires the :doc:`newton <newton>` setting to be
"on" for pair interactions.
The C.lcbop potential file provided with LAMMPS (see the potentials
directory) is parameterized for metal :doc:`units <units>`. You can use
The ``C.lcbop`` potential file provided with LAMMPS (see the potentials
directory) is parameterized for :doc:`metal units <units>`. You can use
the LCBOP potential with any LAMMPS units, but you would need to
create your own LCBOP potential file with coefficients listed in the
appropriate units if your simulation does not use "metal" units.

2
doc/src/pair_polymorphic.rst
View File

@ -298,7 +298,7 @@ described above. For each of the F functions, nx values are listed.
Mixing, shift, table, tail correction, restart, rRESPA info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This pair styles does not support the :doc:`pair_modify <pair_modify>`
This pair style does not support the :doc:`pair_modify <pair_modify>`
shift, table, and tail options.
This pair style does not write their information to :doc:`binary restart

2
doc/src/pair_resquared.rst
View File

@ -173,7 +173,7 @@ equation for the Hamaker constant presented here. Mixing of sigma and
epsilon followed by calculation of the energy prefactors using the
equations above is recommended.
This pair styles supports the :doc:`pair_modify <pair_modify>` shift
This pair style supports the :doc:`pair_modify <pair_modify>` shift
option for the energy of the Lennard-Jones portion of the pair
interaction, but only for sphere-sphere interactions. There is no
shifting performed for ellipsoidal interactions due to the anisotropic

161
doc/src/pair_spin_exchange.rst
View File

@ -1,14 +1,19 @@
.. index:: pair_style spin/exchange
.. index:: pair_style spin/exchange/biquadratic
pair_style spin/exchange command
================================
pair_style spin/exchange/biquadratic command
============================================
Syntax
""""""
.. code-block:: LAMMPS
pair_style spin/exchange cutoff
pair_style spin/exchange/biquadratic cutoff
* cutoff = global cutoff pair (distance in metal units)
@ -19,7 +24,11 @@ Examples
pair_style spin/exchange 4.0
pair_coeff * * exchange 4.0 0.0446928 0.003496 1.4885
pair_coeff 1 2 exchange 6.0 -0.01575 0.0 1.965
pair_coeff 1 2 exchange 6.0 -0.01575 0.0 1.965 offset yes
pair_style spin/exchange/biquadratic 4.0
pair_coeff * * biquadratic 4.0 0.05 0.03 1.48 0.05 0.03 1.48 offset no
pair_coeff 1 2 biquadratic 6.0 -0.01 0.0 1.9 0.0 0.1 19
Description
"""""""""""
@ -31,69 +40,163 @@ pairs of magnetic spins:
H_{ex} = -\sum_{i,j}^N J_{ij} (r_{ij}) \,\vec{s}_i \cdot \vec{s}_j
where :math:`\vec{s}_i` and :math:`\vec{s}_j` are two neighboring magnetic spins of two particles,
:math:`r_{ij} = \vert \vec{r}_i - \vec{r}_j \vert` is the inter-atomic distance between the two
particles. The summation is over pairs of nearest neighbors.
:math:`J(r_{ij})` is a function defining the intensity and the sign of the exchange
interaction for different neighboring shells. This function is defined as:
where :math:`\vec{s}_i` and :math:`\vec{s}_j` are two unit vectors representing
the magnetic spins of two particles (usually atoms), and
:math:`r_{ij} = \vert \vec{r}_i - \vec{r}_j \vert` is the inter-atomic distance
between those two particles. The summation is over pairs of nearest neighbors.
:math:`J(r_{ij})` is a function defining the intensity and the sign of the
exchange interaction for different neighboring shells.
Style *spin/exchange/biquadratic* computes a biquadratic exchange interaction
between pairs of magnetic spins:
.. math::
{J}\left( r_{ij} \right) = 4 a \left( \frac{r_{ij}}{d} \right)^2 \left( 1 - b \left( \frac{r_{ij}}{d} \right)^2 \right) e^{-\left( \frac{r_{ij}}{d} \right)^2 }\Theta (R_c - r_{ij})
H_{bi} = -\sum_{i, j}^{N} {J}_{ij} \left(r_{ij} \right)\,
\vec{s}_{i}\cdot \vec{s}_{j}
-\sum_{i, j}^{N} {K}_{ij} \left(r_{ij} \right)\,
\left(\vec{s}_{i}\cdot
\vec{s}_{j}\right)^2
where :math:`a`, :math:`b` and :math:`d` are the three constant coefficients defined in the associated
"pair_coeff" command, and :math:`R_c` is the radius cutoff associated to
the pair interaction (see below for more explanations).
where :math:`\vec{s}_i`, :math:`\vec{s}_j`, :math:`r_{ij}` and
:math:`J(r_{ij})` have the same definitions as above, and :math:`K(r_{ij})` is
a second function, defining the intensity and the sign of the biquadratic term.
The coefficients :math:`a`, :math:`b`, and :math:`d` need to be fitted so that the function above matches with
the value of the exchange interaction for the :math:`N` neighbor shells taken into account.
Examples and more explanations about this function and its parameterization are reported
in :ref:`(Tranchida) <Tranchida3>`.
The interatomic dependence of :math:`J(r_{ij})` and :math:`K(r_{ij})` in both
interactions above is defined by the following function:
.. math::
{f}\left( r_{ij} \right) = 4 a \left( \frac{r_{ij}}{d} \right)^2
\left( 1 - b \left( \frac{r_{ij}}{d} \right)^2 \right)
e^{-\left( \frac{r_{ij}}{d} \right)^2 }\Theta (R_c - r_{ij})
where :math:`a`, :math:`b` and :math:`d` are the three constant coefficients
defined in the associated "pair_coeff" command, and :math:`R_c` is the radius
cutoff associated to the pair interaction (see below for more explanations).
The coefficients :math:`a`, :math:`b`, and :math:`d` need to be fitted so that
the function above matches with the value of the exchange interaction for the
:math:`N` neighbor shells taken into account.
Examples and more explanations about this function and its parameterization
are reported in :ref:`(Tranchida) <Tranchida3>`.
When a *spin/exchange/biquadratic* pair style is defined, six coefficients
(three for :math:`J(r_{ij})`, and three for :math:`K(r_{ij})`) have to be
fitted.
From this exchange interaction, each spin :math:`i` will be submitted
to a magnetic torque :math:`\vec{\omega}`, and its associated atom can be submitted to a
force :math:`\vec{F}` for spin-lattice calculations (see :doc:`fix nve/spin <fix_nve_spin>`),
such as:
to a magnetic torque :math:`\vec{\omega}_{i}`, and its associated atom can be
submitted to a force :math:`\vec{F}_{i}` for spin-lattice calculations (see
:doc:`fix nve/spin <fix_nve_spin>`), such as:
.. math::
\vec{\omega}_{i} = \frac{1}{\hbar} \sum_{j}^{Neighb} {J}
\left(r_{ij} \right)\,\vec{s}_{j}
~~{\rm and}~~
\vec{F}_{i} = \sum_{j}^{Neighb} \frac{\partial {J} \left(r_{ij} \right)}{ \partial r_{ij}} \left( \vec{s}_{i}\cdot \vec{s}_{j} \right) \vec{e}_{ij}
\vec{F}_{i} = \sum_{j}^{Neighb} \frac{\partial {J} \left(r_{ij} \right)}{
\partial r_{ij}} \left( \vec{s}_{i}\cdot \vec{s}_{j} \right) \vec{e}_{ij}
with :math:`\hbar` the Planck constant (in metal units), and :math:`\vec{e}_{ij} = \frac{\vec{r}_i - \vec{r}_j}{\vert \vec{r}_i-\vec{r}_j \vert}` the unit
with :math:`\hbar` the Planck constant (in metal units), and :math:`\vec{e}_{ij}
= \frac{\vec{r}_i - \vec{r}_j}{\vert \vec{r}_i-\vec{r}_j \vert}` the unit
vector between sites :math:`i` and :math:`j`.
Equivalent forces and magnetic torques are generated for the biquadratic term
when a *spin/exchange/biquadratic* pair style is defined.
More details about the derivation of these torques/forces are reported in
:ref:`(Tranchida) <Tranchida3>`.
For the *spin/exchange* pair style, the following coefficients must be defined
for each pair of atoms types via the :doc:`pair_coeff <pair_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, and
set in the following order:
For the *spin/exchange* and *spin/exchange/biquadratic* pair styles, the
following coefficients must be defined for each pair of atoms types via the
:doc:`pair_coeff <pair_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, and set in the following order:
* :math:`R_c` (distance units)
* :math:`a` (energy units)
* :math:`b` (adim parameter)
* :math:`d` (distance units)
Note that :math:`R_c` is the radius cutoff of the considered exchange interaction,
and :math:`a`, :math:`b` and :math:`d` are the three coefficients performing the parameterization
of the function :math:`J(r_{ij})` defined above.
for the *spin/exchange* pair style, and:
* :math:`R_c` (distance units)
* :math:`a_j` (energy units)
* :math:`b_j` (adim parameter)
* :math:`d_j` (distance units)
* :math:`a_k` (energy units)
* :math:`b_k` (adim parameter)
* :math:`d_k` (distance units)
for the *spin/exchange/biquadratic* pair style.
Note that :math:`R_c` is the radius cutoff of the considered exchange
interaction, and :math:`a`, :math:`b` and :math:`d` are the three coefficients
performing the parameterization of the function :math:`J(r_{ij})` defined
above (in the *biquadratic* style, :math:`a_j`, :math:`b_j`, :math:`d_j` and
:math:`a_k`, :math:`b_k`, :math:`d_k` are the coefficients of :math:`J(r_{ij})`
and :math:`K(r_{ij})` respectively).
None of those coefficients is optional. If not specified, the
*spin/exchange* pair style cannot be used.
----------
**Offsetting magnetic forces and energies**\ :
For spin-lattice simulation, it can be useful to offset the
mechanical forces and energies generated by the exchange
interaction.
The *offset* keyword allows to apply this offset.
By setting *offset* to *yes*, the energy definitions above are
replaced by:
.. math::
H_{ex} = -\sum_{i,j}^N J_{ij} (r_{ij}) \,[ \vec{s}_i \cdot \vec{s}_j-1 ]
for the *spin/exchange* pair style, and:
.. math::
H_{bi} = -\sum_{i, j}^{N} {J}_{ij} \left(r_{ij} \right)\,
[ \vec{s}_{i}\cdot \vec{s}_{j} -1 ]
-\sum_{i, j}^{N} {K}_{ij} \left(r_{ij} \right)\,
[ \left(\vec{s}_{i}\cdot
\vec{s}_{j}\right)^2 -1]
for the *spin/exchange/biquadratic* pair style.
Note that this offset only affects the calculation of the energy
and mechanical forces. It does not modify the calculation of the
precession vectors (and thus does no impact the purely magnetic
properties).
This ensures that when all spins are aligned, the magnetic energy
and the associated mechanical forces (and thus the pressure
generated by the magnetic potential) are null.
.. note::
This offset term can be very important when calculations such as
equations of state (energy vs volume, or energy vs pressure) are
being performed. Indeed, setting the *offset* term ensures that
at the ground state of the crystal and at the equilibrium magnetic
configuration (typically ferromagnetic), the pressure is null,
as expected.
Otherwise, magnetic forces could generate a residual pressure.
When the *offset* option is set to *no*, no offset is applied
(also corresponding to the default option).
----------
Restrictions
""""""""""""
All the *pair/spin* styles are part of the SPIN package. These styles
are only enabled if LAMMPS was built with this package, and if the
atom_style "spin" was declared. See the :doc:`Build package <Build_package>` doc page for more info.
atom_style "spin" was declared.
See the :doc:`Build package <Build_package>` doc page for more info.
Related commands
""""""""""""""""
@ -105,7 +208,7 @@ Default
"""""""
none
The default *offset* keyword value is *no*.
----------

2
doc/src/pair_srp.rst
View File

@ -124,7 +124,7 @@ at the cutoff distance :math:`r_c`.
Mixing, shift, table, tail correction, restart, rRESPA info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This pair styles does not support mixing.
This pair style does not support mixing.
This pair style does not support the :doc:`pair_modify <pair_modify>`
shift option for the energy of the pair interaction. Note that as

1
doc/src/pair_style.rst
View File

@ -305,6 +305,7 @@ accelerated styles exist.
* :doc:`spin/dipole/long <pair_spin_dipole>` -
* :doc:`spin/dmi <pair_spin_dmi>` -
* :doc:`spin/exchange <pair_spin_exchange>` -
* :doc:`spin/exchange/biquadratic <pair_spin_exchange>` -
* :doc:`spin/magelec <pair_spin_magelec>` -
* :doc:`spin/neel <pair_spin_neel>` -
* :doc:`srp <pair_srp>` -

8
doc/src/read_data.rst
View File

@ -618,7 +618,7 @@ of analysis.
* - tdpd
- atom-ID atom-type x y z cc1 cc2 ... ccNspecies
* - template
- atom-ID molecule-ID template-index template-atom atom-type x y z
- atom-ID atom-type molecule-ID template-index template-atom x y z
* - tri
- atom-ID molecule-ID atom-type triangleflag density x y z
* - wavepacket
@ -695,9 +695,9 @@ triangle, or body in the corresponding *Ellipsoids*\ , *Lines*\ ,
The *template-index* and *template-atom* are only defined used by
:doc:`atom_style template <atom_style>`. In this case the
:doc:`molecule <molecule>` command is used to define a molecule template
which contains one or more molecules. If an atom belongs to one of
those molecules, its *template-index* and *template-atom* are both set
to positive integers; if not the values are both 0. The
which contains one or more molecules (as separate files). If an atom
belongs to one of those molecules, its *template-index* and *template-atom*
are both set to positive integers; if not the values are both 0. The
*template-index* is which molecule (1 to Nmols) the atom belongs to.
The *template-atom* is which atom (1 to Natoms) within the molecule
the atom is.

2
doc/src/read_dump.rst
View File

@ -370,6 +370,8 @@ needed to generate absolute, unscaled coordinates.
Restrictions
""""""""""""
The *native* dump file reader does not support binary .bin dump files.
To read gzipped dump files, you must compile LAMMPS with the
-DLAMMPS_GZIP option. See the :doc:`Build settings <Build_settings>`
doc page for details.

29
doc/src/rerun.rst
View File

@ -99,14 +99,15 @@ files do not match the specified output frequency.
----------
If more than one dump file is specified, the dump files are read one
after the other. It is assumed that snapshot timesteps will be in
ascending order. If a snapshot is encountered that is not in
ascending order, it will skip the snapshot until it reads one that is.
after the other in the order specified. It is assumed that snapshot
timesteps will be in ascending order. If a snapshot is encountered that
is not in ascending order, it will skip the snapshot until it reads one
that is.
This allows skipping of a duplicate snapshot (same timestep),
e.g. that appeared at the end of one file and beginning of the next.
However if you specify a series of dump files in an incorrect order
(with respect to the timesteps they contain), you may skip large
numbers of snapshots
numbers of snapshots.
Note that the dump files specified as part of the *dump* keyword can be
parallel files, i.e. written as multiple files either per processor
@ -118,17 +119,24 @@ and write parallel dump files.
The *first*\ , *last*\ , *every*\ , *skip* keywords determine which
snapshots are read from the dump file(s). Snapshots are skipped until
they have a timestamp >= *Nfirst*\ . When a snapshot with a timestamp >
*Nlast* is encountered, the rerun command finishes. Note below that
they have a timestep >= *Nfirst*\ . When a snapshot with a timestep >
*Nlast* is encountered, the rerun command finishes. Note that
the defaults for *first* and *last* are to read all snapshots. If the
*every* keyword is set to a value > 0, then only snapshots with
timestamps that are a multiple of *Nevery* are read (the first
timesteps that are a multiple of *Nevery* are read (the first
snapshot is always read). If *Nevery* = 0, then this criterion is
ignored, i.e. every snapshot is read that meets the other criteria.
If the *skip* keyword is used, then after the first snapshot is read,
every Nth snapshot is read, where N = *Nskip*\ . E.g. if *Nskip* = 3,
then only 1 out of every 3 snapshots is read, assuming the snapshot
timestamp is also consistent with the other criteria.
timestep is also consistent with the other criteria.
.. note::
Not all dump formats contain the timestep and not all dump readers
support reading it. In that case individual snapshots are assigned
consecutive timestep numbers starting at 1.
The *start* and *stop* keywords do not affect which snapshots are read
from the dump file(s). Rather, they have the same meaning that they
@ -205,9 +213,8 @@ thermodynamic output or new dump file output.
Restrictions
""""""""""""
To read gzipped dump files, you must compile LAMMPS with the
-DLAMMPS_GZIP option. See the :doc:`Build settings <Build_settings>`
doc page for details.
The *rerun* command is subject to all restrictions of
the :doc:`read_dump <read_dump>` command.
Related commands
""""""""""""""""