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

fix up some more package designations and clean up some legacy formatting

Browse Source
This commit is contained in:
Axel Kohlmeyer
2021-07-25 20:23:37 -04:00
parent 18b1e10be8
commit 5a79429f03
592 changed files with 2074 additions and 2019 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
doc/src/Bibliography.rst
View File

@ -191,7 +191,7 @@ Bibliography
A.\ Calhoun, M. Pavese, G. Voth, Chem Phys Letters, 262, 415 (1996).
**(Campana)**
C.\ Campana and M. H. Muser, *Practical Green's function approach to the simulation of elastic semi-infinite solids*\ , `Phys. Rev. B [74], 075420 (2006) <https://doi.org/10.1103/PhysRevB.74.075420>`_
C.\ Campana and M. H. Muser, *Practical Green's function approach to the simulation of elastic semi-infinite solids*, `Phys. Rev. B [74], 075420 (2006) <https://doi.org/10.1103/PhysRevB.74.075420>`_
**(Cao1)**
J.\ Cao and B. Berne, J Chem Phys, 99, 2902 (1993).
@ -767,7 +767,7 @@ Bibliography
Morris, Fox, Zhu, J Comp Physics, 136, 214-226 (1997).
**(Moustafa)**
Sabry G. Moustafa, Andrew J. Schultz, and David A. Kofke, *Very fast averaging of thermal properties of crystals by molecular simulation*\ , `Phys. Rev. E [92], 043303 (2015) <https://link.aps.org/doi/10.1103/PhysRevE.92.043303>`_
Sabry G. Moustafa, Andrew J. Schultz, and David A. Kofke, *Very fast averaging of thermal properties of crystals by molecular simulation*, `Phys. Rev. E [92], 043303 (2015) <https://link.aps.org/doi/10.1103/PhysRevE.92.043303>`_
**(Muller-Plathe1)**
Muller-Plathe, J Chem Phys, 106, 6082 (1997).

2
doc/src/Commands_category.rst
View File

@ -2,7 +2,7 @@ Commands by category
====================
This page lists most of the LAMMPS commands, grouped by category. The
:doc:`General commands <Commands_all>` doc page lists all general commands
:doc:`General commands <Commands_all>` page lists all general commands
alphabetically. Style options for entries like fix, compute, pair etc.
have their own pages where they are listed alphabetically.

2
doc/src/Commands_input.rst
View File

@ -50,6 +50,6 @@ values are not desired, the :doc:`processors <processors>` and
tell LAMMPS how to map processors to the simulation box.
Many input script errors are detected by LAMMPS and an ERROR or
WARNING message is printed. The :doc:`Errors <Errors>` doc page gives
WARNING message is printed. The :doc:`Errors <Errors>` page gives
more information on what errors mean. The documentation for each
command lists restrictions on how the command can be used.

2
doc/src/Commands_parse.rst
View File

@ -47,7 +47,7 @@ LAMMPS:
named "x" followed by an "x" character.
How the variable is converted to a text string depends on what style
of variable it is; see the :doc:`variable <variable>` doc page for
of variable it is; see the :doc:`variable <variable>` page for
details. It can be a variable that stores multiple text strings, and
return one of them. The returned text string can be multiple "words"
(space separated) which will then be interpreted as multiple

32
doc/src/Errors_messages.rst
View File

@ -570,10 +570,10 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
See the region prism command for details.
*Can only use -plog with multiple partitions*
Self-explanatory. See doc page discussion of command-line switches.
Self-explanatory. See page discussion of command-line switches.
*Can only use -pscreen with multiple partitions*
Self-explanatory. See doc page discussion of command-line switches.
Self-explanatory. See page discussion of command-line switches.
*Can only use Kokkos supported regions with Kokkos package*
Self-explanatory.
@ -1154,7 +1154,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
Self-explanatory.
*Cannot use -reorder after -partition*
Self-explanatory. See doc page discussion of command-line switches.
Self-explanatory. See page discussion of command-line switches.
*Cannot use Ewald with 2d simulation*
The kspace style ewald cannot be used in 2d simulations. You can use
@ -2347,14 +2347,14 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
*Compute used in variable between runs is not current*
Computes cannot be invoked by a variable in between runs. Thus they
must have been evaluated on the last timestep of the previous run in
order for their value(s) to be accessed. See the doc page for the
order for their value(s) to be accessed. See the page for the
variable command for more info.
*Compute used in variable thermo keyword between runs is not current*
Some thermo keywords rely on a compute to calculate their value(s).
Computes cannot be invoked by a variable in between runs. Thus they
must have been evaluated on the last timestep of the previous run in
order for their value(s) to be accessed. See the doc page for the
order for their value(s) to be accessed. See the page for the
variable command for more info.
*Compute vcm/chunk does not use chunk/atom compute*
@ -3126,7 +3126,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
*Energy was not tallied on needed timestep*
You are using a thermo keyword that requires potentials to
have tallied energy, but they did not on this timestep. See the
variable doc page for ideas on how to make this work.
variable page for ideas on how to make this work.
*Epsilon or sigma reference not set by pair style in PPPMDisp*
Self-explanatory.
@ -4535,10 +4535,10 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
particles.
*Incorrect # of floating-point values in Bodies section of data file*
See doc page for body style.
See page for body style.
*Incorrect # of integer values in Bodies section of data file*
See doc page for body style.
See page for body style.
*Incorrect %s format in data file*
A section of the data file being read by fix property/atom does
@ -4573,7 +4573,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
The number of fields per line is not what expected.
*Incorrect bonus data format in data file*
See the read_data doc page for a description of how various kinds of
See the read_data page for a description of how various kinds of
bonus data must be formatted for certain atom styles.
*Incorrect boundaries with slab Ewald*
@ -4641,7 +4641,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
Incorrect number of words per line in the potential file.
*Incorrect integer value in Bodies section of data file*
See doc page for body style.
See page for body style.
*Incorrect multiplicity arg for dihedral coefficients*
Self-explanatory. Check the input script or data file.
@ -5996,7 +5996,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
Self-explanatory.
*Needed bonus data not in data file*
Some atom styles require bonus data. See the read_data doc page for
Some atom styles require bonus data. See the read_data page for
details.
*Needed molecular topology not in data file*
@ -6198,7 +6198,7 @@ keyword to allow for additional bonds to be formed
*One or more atom IDs is too big*
The limit on atom IDs is set by the SMALLBIG, BIGBIG, SMALLSMALL
setting in your LAMMPS build. See the :doc:`Build settings <Build_settings>` doc page for more info.
setting in your LAMMPS build. See the :doc:`Build settings <Build_settings>` page for more info.
*One or more atom IDs is zero*
Either all atoms IDs must be zero or none of them.
@ -6593,7 +6593,7 @@ keyword to allow for additional bonds to be formed
*Pair style bop requires comm ghost cutoff at least 3x larger than %g*
Use the communicate ghost command to set this. See the pair bop
doc page for more details.
page for more details.
*Pair style born/coul/long requires atom attribute q*
An atom style that defines this attribute must be used.
@ -6913,7 +6913,7 @@ keyword to allow for additional bonds to be formed
*Per-atom energy was not tallied on needed timestep*
You are using a thermo keyword that requires potentials to
have tallied energy, but they did not on this timestep. See the
variable doc page for ideas on how to make this work.
variable page for ideas on how to make this work.
*Per-atom fix in equal-style variable formula*
Equal-style variables cannot use per-atom quantities.
@ -6921,7 +6921,7 @@ keyword to allow for additional bonds to be formed
*Per-atom virial was not tallied on needed timestep*
You are using a thermo keyword that requires potentials to have
tallied the virial, but they did not on this timestep. See the
variable doc page for ideas on how to make this work.
variable page for ideas on how to make this work.
*Per-processor system is too big*
The number of owned atoms plus ghost atoms on a single
@ -8408,7 +8408,7 @@ keyword to allow for additional bonds to be formed
*Virial was not tallied on needed timestep*
You are using a thermo keyword that requires potentials to
have tallied the virial, but they did not on this timestep. See the
variable doc page for ideas on how to make this work.
variable page for ideas on how to make this work.
*Voro++ error: narea and neigh have a different size*
This error is returned by the Voro++ library.

2
doc/src/Errors_warnings.rst
View File

@ -213,7 +213,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
in unexpected behavior.
*Fix bond/swap will ignore defined angles*
See the doc page for fix bond/swap for more info on this
See the page for fix bond/swap for more info on this
restriction.
*Fix deposit near setting < possible overlap separation %g*

4
doc/src/Examples.rst
View File

@ -174,10 +174,10 @@ web site.
If you uncomment the :doc:`dump image <dump_image>` line(s) in the input
script a series of JPG images will be produced by the run (assuming
you built LAMMPS with JPG support; see the
:doc:`Build_settings <Build_settings>` doc page for details). These can
:doc:`Build_settings <Build_settings>` page for details). These can
be viewed individually or turned into a movie or animated by tools
like ImageMagick or QuickTime or various Windows-based tools. See the
:doc:`dump image <dump_image>` doc page for more details. E.g. this
:doc:`dump image <dump_image>` page for more details. E.g. this
Imagemagick command would create a GIF file suitable for viewing in a
browser.

2
doc/src/Howto_barostat.rst
View File

@ -50,7 +50,7 @@ a temperature or pressure compute to a barostatting fix.
Thermodynamic output, which can be setup via the
:doc:`thermo_style <thermo_style>` command, often includes pressure
values. As explained on the doc page for the
values. As explained on the page for the
:doc:`thermo_style <thermo_style>` command, the default pressure is
setup by the thermo command itself. It is NOT the pressure associated
with any barostatting fix you have defined or with any compute you

2
doc/src/Howto_bioFF.rst
View File

@ -49,7 +49,7 @@ command's documentation for the formula it computes.
COMPASS is a general force field for atomistic simulation of common
organic molecules, inorganic small molecules, and polymers which was
developed using ab initio and empirical parameterization techniques.
See the :doc:`Tools <Tools>` doc page for the msi2lmp tool for creating
See the :doc:`Tools <Tools>` page for the msi2lmp tool for creating
LAMMPS template input and data files from BIOVIA's Materials Studio
files. Please note that the msi2lmp tool is very old and largely
unmaintained, so it does not support all features of Materials Studio

10
doc/src/Howto_body.rst
View File

@ -10,7 +10,7 @@ deformable objects, etc. Note that other kinds of finite-size
spherical and aspherical particles are also supported by LAMMPS, such
as spheres, ellipsoids, line segments, and triangles, but they are
simpler entities than body particles. See the :doc:`Howto spherical
<Howto_spherical>` doc page for a general overview of all these
<Howto_spherical>` page for a general overview of all these
particle types.
Body particles are used via the :doc:`atom_style body <atom_style>`
@ -170,14 +170,14 @@ with this body style to compute body/body and body/non-body interactions.
The *rounded/polygon* body style represents body particles as a 2d
polygon with a variable number of N vertices. This style can only be
used for 2d models; see the :doc:`boundary <boundary>` command. See the
"pair_style body/rounded/polygon" doc page for a diagram of two
"pair_style body/rounded/polygon" page for a diagram of two
squares with rounded circles at the vertices. Special cases for N = 1
(circle) and N = 2 (rod with rounded ends) can also be specified.
One use of this body style is for 2d discrete element models, as
described in :ref:`Fraige <body-Fraige>`.
Similar to body style *nparticle*\ , the atom_style body command for
Similar to body style *nparticle*, the atom_style body command for
this body style takes two additional arguments:
.. parsed-literal::
@ -284,7 +284,7 @@ The *rounded/polyhedron* body style represents body particles as a 3d
polyhedron with a variable number of N vertices, E edges and F faces.
This style can only be used for 3d models; see the
:doc:`boundary <boundary>` command. See the "pair_style
body/rounded/polygon" doc page for a diagram of a two 2d squares with
body/rounded/polygon" page for a diagram of a two 2d squares with
rounded circles at the vertices. A 3d cube with rounded spheres at
the 8 vertices and 12 rounded edges would be similar. Special cases
for N = 1 (sphere) and N = 2 (rod with rounded ends) can also be
@ -293,7 +293,7 @@ specified.
This body style is for 3d discrete element models, as described in
:ref:`Wang <body-Wang>`.
Similar to body style *rounded/polygon*\ , the atom_style body command
Similar to body style *rounded/polygon*, the atom_style body command
for this body style takes two additional arguments:
.. parsed-literal::

2
doc/src/Howto_chunk.rst
View File

@ -51,7 +51,7 @@ scales the floating point value to spread it across multiple integers.
Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins =
pencils, 3d bins = boxes, spherical bins, cylindrical bins.
This compute also calculates the number of chunks *Nchunk*\ , which is
This compute also calculates the number of chunks *Nchunk*, which is
used by other commands to tally per-chunk data. *Nchunk* can be a
static value or change over time (e.g. the number of clusters). The
chunk ID for an individual atom can also be static (e.g. a molecule

4
doc/src/Howto_client_server.rst
View File

@ -119,7 +119,7 @@ server code. Another code could be substituted for either.
The examples below show launching both codes from the same window (or
batch script), using the "&" character to launch the first code in the
background. For all modes except *mpi/one*\ , you could also launch the
background. For all modes except *mpi/one*, you could also launch the
codes in separate windows on your desktop machine. It does not
matter whether you launch the client or server first.
@ -132,7 +132,7 @@ mpirun, even if one or both of them runs on a single processor. This
is so that MPI can figure out how to connect both MPI processes
together to exchange MPI messages between them.
For message exchange in *file*\ , *zmq*\ , or *mpi/two* modes:
For message exchange in *file*, *zmq*, or *mpi/two* modes:
.. code-block:: bash

4
doc/src/Howto_coreshell.rst
View File

@ -5,7 +5,7 @@ The adiabatic core-shell model by :ref:`Mitchell and Fincham <MitchellFincham>`
to a system. In order to mimic the electron shell of an ion, a
satellite particle is attached to it. This way the ions are split into
a core and a shell where the latter is meant to react to the
electrostatic environment inducing polarizability. See the :doc:`Howto polarizable <Howto_polarizable>` doc page for a discussion of all
electrostatic environment inducing polarizability. See the :doc:`Howto polarizable <Howto_polarizable>` page for a discussion of all
the polarizable models available in LAMMPS.
Technically, shells are attached to the cores by a spring force f =
@ -78,7 +78,7 @@ satellite particle if desired.
Since the core/shell model permits distances of r = 0.0 between the
core and shell, a pair style with a "cs" suffix needs to be used to
implement a valid long-range Coulombic correction. Several such pair
styles are provided in the CORESHELL package. See :doc:`this doc page <pair_cs>` for details. All of the core/shell enabled pair
styles are provided in the CORESHELL package. See :doc:`this page <pair_cs>` for details. All of the core/shell enabled pair
styles require the use of a long-range Coulombic solver, as specified
by the :doc:`kspace_style <kspace_style>` command. Either the PPPM or
Ewald solvers can be used.

2
doc/src/Howto_couple.rst
View File

@ -42,7 +42,7 @@ context of your application.
stand-alone code could communicate with LAMMPS through files that the
command writes and reads.
See the :doc:`Modify command <Modify_command>` doc page for info on how
See the :doc:`Modify command <Modify_command>` page for info on how
to add a new command to LAMMPS.
.. spacer

16
doc/src/Howto_drude2.rst
View File

@ -91,7 +91,7 @@ DRUDE package) to convert a non-polarizable data file (here
This will automatically insert the new atoms and bonds.
The masses and charges of DCs and DPs are computed
from *phenol.dff*\ , as well as the DC-DP bond constants. The file
from *phenol.dff*, as well as the DC-DP bond constants. The file
*phenol.dff* contains the polarizabilities of the atom types
and the mass of the Drude particles, for instance:
@ -106,7 +106,7 @@ and the mass of the Drude particles, for instance:
The hydrogen atoms are absent from this file, so they will be treated
as non-polarizable atoms. In the non-polarizable data file
*data.102494.lmp*\ , atom names corresponding to the atom type numbers
*data.102494.lmp*, atom names corresponding to the atom type numbers
have to be specified as comments at the end of lines of the *Masses*
section. You probably need to edit it to add these names. It should
look like
@ -125,7 +125,7 @@ look like
**Basic input file**
The atom style should be set to (or derive from) *full*\ , so that you
The atom style should be set to (or derive from) *full*, so that you
can define atomic charges and molecular bonds, angles, dihedrals...
The *polarizer* tool also outputs certain lines related to the input
@ -143,7 +143,7 @@ and N for non-polarizable atoms. Here the atom types 1 to 3 (C and O
atoms) are DC, atom types 4 and 5 (H atoms) are non-polarizable and
the atom types 6 to 8 are the newly created DPs.
By recognizing the fix *drude*\ , LAMMPS will find and store matching
By recognizing the fix *drude*, LAMMPS will find and store matching
DC-DP pairs and will treat DP as equivalent to their DC in the
*special bonds* relations. It may be necessary to extend the space
for storing such special relations. In this case extra space should
@ -340,11 +340,11 @@ For the *thole* pair style the coefficients are
The special neighbors have charge-charge and charge-dipole
interactions screened by the *coul* factors of the *special_bonds*
command (0.0, 0.0, and 0.5 in the example above). Without using the
pair_style *thole*\ , dipole-dipole interactions are screened by the
same factor. By using the pair_style *thole*\ , dipole-dipole
pair_style *thole*, dipole-dipole interactions are screened by the
same factor. By using the pair_style *thole*, dipole-dipole
interactions are screened by Thole's function, whatever their special
relationship (except within each DC-DP pair of course). Consider for
example 1-2 neighbors: using the pair_style *thole*\ , their dipoles
example 1-2 neighbors: using the pair_style *thole*, their dipoles
will see each other (despite the *coul* factor being 0.) and the
interactions between these dipoles will be damped by Thole's function.
@ -384,7 +384,7 @@ For our phenol example, the groups would be defined as
group CORES type 1 2 3 # DCs
group DRUDES type 6 7 8 # DPs
Note that with the fixes *drude/transform*\ , it is not required to
Note that with the fixes *drude/transform*, it is not required to
specify *comm_modify vel yes* because the fixes do it anyway (several
times and for the forces also).

4
doc/src/Howto_github.rst
View File

@ -140,8 +140,8 @@ After everything is done, add the files to the branch and commit them:
flag) will automatically include **all** modified **and** new files
and that is rarely the behavior you want. It can easily lead to
accidentally adding unrelated and unwanted changes into the
repository. Instead it is preferable to explicitly use *git add*\ ,
*git rm*\ , *git mv* for adding, removing, renaming individual files,
repository. Instead it is preferable to explicitly use *git add*,
*git rm*, *git mv* for adding, removing, renaming individual files,
respectively, and then *git commit* to finalize the commit.
Carefully check all pending changes with *git status* before
committing them. If you find doing this on the command line too

4
doc/src/Howto_kappa.rst
View File

@ -4,7 +4,7 @@ Calculate thermal conductivity
The thermal conductivity kappa of a material can be measured in at
least 4 ways using various options in LAMMPS. See the examples/KAPPA
directory for scripts that implement the 4 methods discussed here for
a simple Lennard-Jones fluid model. Also, see the :doc:`Howto viscosity <Howto_viscosity>` doc page for an analogous discussion
a simple Lennard-Jones fluid model. Also, see the :doc:`Howto viscosity <Howto_viscosity>` page for an analogous discussion
for viscosity.
The thermal conductivity tensor kappa is a measure of the propensity
@ -58,7 +58,7 @@ between hot and cold regions of the simulation box.
The :doc:`compute heat/flux <compute_heat_flux>` command can calculate
the needed heat flux and describes how to implement the Green_Kubo
formalism using additional LAMMPS commands, such as the :doc:`fix ave/correlate <fix_ave_correlate>` command to calculate the needed
auto-correlation. See the doc page for the :doc:`compute heat/flux <compute_heat_flux>` command for an example input script
auto-correlation. See the page for the :doc:`compute heat/flux <compute_heat_flux>` command for an example input script
that calculates the thermal conductivity of solid Ar via the GK
formalism.

2
doc/src/Howto_manifold.rst
View File

@ -3,7 +3,7 @@ Manifolds (surfaces)
**Overview:**
This doc page is not about a LAMMPS input script command, but about
This page is not about a LAMMPS input script command, but about
manifolds, which are generalized surfaces, as defined and used by the
MANIFOLD package, to track particle motion on the manifolds. See
the src/MANIFOLD/README file for more details about the package

4
doc/src/Howto_mdi.rst
View File

@ -3,7 +3,7 @@ Using LAMMPS with the MDI library for code coupling
.. note::
This Howto doc page will eventually replace the
This Howto page will eventually replace the
:doc:`Howto client/server <Howto_client_server>` doc page.
Client/server coupling of two codes is where one code is the "client"
@ -120,7 +120,7 @@ input script will continue. After finishing execution of the input
script, the instance of LAMMPS will be destroyed.
LAMMPS supports the full set of MD-appropriate engine commands defined
by the MDI library. See the :doc:`mdi/engine <mdi_engine>` doc page for
by the MDI library. See the :doc:`mdi/engine <mdi_engine>` page for
a list of these.
If those commands are not sufficient for a user-developed driver to use

4
doc/src/Howto_output.rst
View File

@ -268,7 +268,7 @@ Computes that generate values to output
Every :doc:`compute <compute>` in LAMMPS produces either global or
per-atom or local values. The values can be scalars or vectors or
arrays of data. These values can be output using the other commands
described in this section. The doc page for each compute command
described in this section. The page for each compute command
describes what it produces. Computes that produce per-atom or local
values have the word "atom" or "local" in their style name. Computes
without the word "atom" or "local" produce global values.
@ -281,7 +281,7 @@ Fixes that generate values to output
Some :doc:`fixes <fix>` in LAMMPS produces either global or per-atom or
local values which can be accessed by other commands. The values can
be scalars or vectors or arrays of data. These values can be output
using the other commands described in this section. The doc page for
using the other commands described in this section. The page for
each fix command tells whether it produces any output quantities and
describes them.

2
doc/src/Howto_replica.rst
View File

@ -27,7 +27,7 @@ replicas are coupled together by springs to model a system of ring-polymers whic
can represent the quantum nature of atom cores.
These commands can only be used if LAMMPS was built with the REPLICA
package. See the :doc:`Build package <Build_package>` doc page for more
package. See the :doc:`Build package <Build_package>` page for more
info.
In all these cases, you must run with one or more processors per

4
doc/src/Howto_thermostat.rst
View File

@ -28,7 +28,7 @@ can be invoked via the *dpd/tstat* pair style:
:doc:`Fix nvt <fix_nh>` only thermostats the translational velocity of
particles. :doc:`Fix nvt/sllod <fix_nvt_sllod>` also does this, except
that it subtracts out a velocity bias due to a deforming box and
integrates the SLLOD equations of motion. See the :doc:`Howto nemd <Howto_nemd>` doc page for further details. :doc:`Fix nvt/sphere <fix_nvt_sphere>` and :doc:`fix nvt/asphere <fix_nvt_asphere>` thermostat not only translation
integrates the SLLOD equations of motion. See the :doc:`Howto nemd <Howto_nemd>` page for further details. :doc:`Fix nvt/sphere <fix_nvt_sphere>` and :doc:`fix nvt/asphere <fix_nvt_asphere>` thermostat not only translation
velocities but also rotational velocities for spherical and aspherical
particles.
@ -88,7 +88,7 @@ Below is a list of some custom temperature computes that can be used like that:
Thermodynamic output, which can be setup via the
:doc:`thermo_style <thermo_style>` command, often includes temperature
values. As explained on the doc page for the
values. As explained on the page for the
:doc:`thermo_style <thermo_style>` command, the default temperature is
setup by the thermo command itself. It is NOT the temperature
associated with any thermostatting fix you have defined or with any

30
doc/src/Howto_triclinic.rst
View File

@ -23,21 +23,21 @@ origin given by **a** = (xhi-xlo,0,0); **b** = (xy,yhi-ylo,0); **c** =
and are called "tilt factors" because they are the amount of
displacement applied to faces of an originally orthogonal box to
transform it into the parallelepiped. In LAMMPS the triclinic
simulation box edge vectors **a**\ , **b**\ , and **c** cannot be arbitrary
simulation box edge vectors **a**, **b**, and **c** cannot be arbitrary
vectors. As indicated, **a** must lie on the positive x axis. **b** must
lie in the xy plane, with strictly positive y component. **c** may have
any orientation with strictly positive z component. The requirement
that **a**\ , **b**\ , and **c** have strictly positive x, y, and z components,
respectively, ensures that **a**\ , **b**\ , and **c** form a complete
that **a**, **b**, and **c** have strictly positive x, y, and z components,
respectively, ensures that **a**, **b**, and **c** form a complete
right-handed basis. These restrictions impose no loss of generality,
since it is possible to rotate/invert any set of 3 crystal basis
vectors so that they conform to the restrictions.
For example, assume that the 3 vectors **A**\ ,\ **B**\ ,\ **C** are the edge
For example, assume that the 3 vectors **A**,\ **B**,\ **C** are the edge
vectors of a general parallelepiped, where there is no restriction on
**A**\ ,\ **B**\ ,\ **C** other than they form a complete right-handed basis i.e.
**A** x **B** . **C** > 0. The equivalent LAMMPS **a**\ ,\ **b**\ ,\ **c** are a linear
rotation of **A**\ , **B**\ , and **C** and can be computed as follows:
**A**,\ **B**,\ **C** other than they form a complete right-handed basis i.e.
**A** x **B** . **C** > 0. The equivalent LAMMPS **a**,\ **b**,\ **c** are a linear
rotation of **A**, **B**, and **C** and can be computed as follows:
.. math::
@ -57,9 +57,9 @@ rotation of **A**\ , **B**\ , and **C** and can be computed as follows:
where A = \| **A** \| indicates the scalar length of **A**\ . The hat symbol (\^)
indicates the corresponding unit vector. :math:`\beta` and :math:`\gamma` are angles
between the vectors described below. Note that by construction,
**a**\ , **b**\ , and **c** have strictly positive x, y, and z components, respectively.
**a**, **b**, and **c** have strictly positive x, y, and z components, respectively.
If it should happen that
**A**\ , **B**\ , and **C** form a left-handed basis, then the above equations
**A**, **B**, and **C** form a left-handed basis, then the above equations
are not valid for **c**\ . In this case, it is necessary
to first apply an inversion. This can be achieved
by interchanging two basis vectors or by changing the sign of one of them.
@ -95,7 +95,7 @@ for details.
The 9 parameters (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) are defined at the
time the simulation box is created. This happens in one of 3 ways.
If the :doc:`create_box <create_box>` command is used with a region of
style *prism*\ , then a triclinic box is setup. See the
style *prism*, then a triclinic box is setup. See the
:doc:`region <region>` command for details. If the
:doc:`read_data <read_data>` command is used to define the simulation
box, and the header of the data file contains a line with the "xy xz
@ -135,7 +135,7 @@ example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
... are geometrically all equivalent. If the box tilt exceeds this
limit during a dynamics run (e.g. via the :doc:`fix deform <fix_deform>`
command), then the box is "flipped" to an equivalent shape with a tilt
factor within the bounds, so the run can continue. See the :doc:`fix deform <fix_deform>` doc page for further details.
factor within the bounds, so the run can continue. See the :doc:`fix deform <fix_deform>` page for further details.
One exception to this rule is if the first dimension in the tilt
factor (x for xy) is non-periodic. In that case, the limits on the
@ -160,10 +160,10 @@ For extreme values of tilt, LAMMPS may also lose atoms and generate an
error.
Triclinic crystal structures are often defined using three lattice
constants *a*\ , *b*\ , and *c*\ , and three angles :math:`\alpha`,
constants *a*, *b*, and *c*, and three angles :math:`\alpha`,
:math:`\beta`, and :math:`\gamma`. Note that in this nomenclature,
the a, b, and c lattice constants are the scalar lengths of the edge
vectors **a**\ , **b**\ , and **c** defined above. The relationship
vectors **a**, **b**, and **c** defined above. The relationship
between these 6 quantities (a, b, c, :math:`\alpha`, :math:`\beta`,
:math:`\gamma`) and the LAMMPS box sizes (lx,ly,lz) =
(xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:
@ -188,10 +188,10 @@ The inverse relationship can be written as follows:
{\rm yz} = & \frac{b*c \cos{\alpha} - {\rm xy}*{\rm xz}}{\rm ly} \\
{\rm lz}^2 = & c^2 - {\rm xz}^2 - {\rm yz}^2 \\
The values of *a*\ , *b*\ , *c* , :math:`\alpha` , :math:`\beta`, and
The values of *a*, *b*, *c*, :math:`\alpha` , :math:`\beta`, and
:math:`\gamma` can be printed out or accessed by computes using the
:doc:`thermo_style custom <thermo_style>` keywords
*cella*\ , *cellb*\ , *cellc*\ , *cellalpha*\ , *cellbeta*\ , *cellgamma*\ ,
*cella*, *cellb*, *cellc*, *cellalpha*, *cellbeta*, *cellgamma*,
respectively.
As discussed on the :doc:`dump <dump>` command doc page, when the BOX

2
doc/src/Howto_viscosity.rst
View File

@ -42,7 +42,7 @@ command, which determines grad(Vstream) in the equation above.
E.g. the derivative in the y-direction of the Vx component of fluid
motion or grad(Vstream) = dVx/dy. The Pxy off-diagonal component of
the pressure or stress tensor, as calculated by the :doc:`compute pressure <compute_pressure>` command, can also be monitored, which
is the J term in the equation above. See the :doc:`Howto nemd <Howto_nemd>` doc page for details on NEMD simulations.
is the J term in the equation above. See the :doc:`Howto nemd <Howto_nemd>` page for details on NEMD simulations.
The third method is to perform a reverse non-equilibrium MD simulation
using the :doc:`fix viscosity <fix_viscosity>` command which implements

2
doc/src/Howto_viz.rst
View File

@ -13,7 +13,7 @@ by several popular visualization tools. The :doc:`dump image <dump_image>` and :
output internally rendered images and convert a sequence of them to a
movie during the MD run. Several programs included with LAMMPS as
auxiliary tools can convert between LAMMPS format files and other
formats. See the :doc:`Tools <Tools>` doc page for details.
formats. See the :doc:`Tools <Tools>` page for details.
A Python-based toolkit distributed by our group can read native LAMMPS
dump files, including custom dump files with additional columns of

2
doc/src/Howto_walls.rst
View File

@ -53,7 +53,7 @@ granular particles; all the other commands create smooth walls.
* :doc:`fix wall/region <fix_wall_region>` - use region surface as wall
* :doc:`fix wall/gran <fix_wall_gran>` - flat or curved walls with :doc:`pair_style granular <pair_gran>` potential
The *lj93*\ , *lj126*\ , *colloid*\ , *harmonic*\ , and *morse* styles all
The *lj93*, *lj126*, *colloid*, *harmonic*, and *morse* styles all
allow the flat walls to move with a constant velocity, or oscillate in
time. The :doc:`fix wall/region <fix_wall_region>` command offers the
most generality, since the region surface is treated as a wall, and

8
doc/src/Intro_nonfeatures.rst
View File

@ -32,7 +32,7 @@ Here are suggestions on how to perform these tasks:
are simple programs that will build simple molecular systems, such as
linear bead-spring polymer chains. The moltemplate program is a true
molecular builder that will generate complex molecular models. See
the :doc:`Tools <Tools>` doc page for details on tools packaged with
the :doc:`Tools <Tools>` page for details on tools packaged with
LAMMPS. The `Pre/post processing page <http:/www.lammps.org/prepost.html>`_ of the LAMMPS website
describes a variety of third party tools for this task. Furthermore,
some LAMMPS internal commands allow to reconstruct, or selectively add
@ -49,7 +49,7 @@ Here are suggestions on how to perform these tasks:
* **Simulation analysis:** If you want to perform analysis on-the-fly as
your simulation runs, see the :doc:`compute <compute>` and
:doc:`fix <fix>` doc pages, which list commands that can be used in a
LAMMPS input script. Also see the :doc:`Modify <Modify>` doc page for
LAMMPS input script. Also see the :doc:`Modify <Modify>` page for
info on how to add your own analysis code or algorithms to LAMMPS.
For post-processing, LAMMPS output such as :doc:`dump file snapshots <dump>` can be converted into formats used by other MD or
post-processing codes. To some degree, that conversion can be done
@ -61,7 +61,7 @@ Here are suggestions on how to perform these tasks:
LAMMPS will do these conversions. Scripts provided in the
tools/python directory can extract and massage data in dump files to
make it easier to import into other programs. See the
:doc:`Tools <Tools>` doc page for details on these various options.
:doc:`Tools <Tools>` page for details on these various options.
* **Visualization:** LAMMPS can produce NETPBM, JPG or PNG snapshot images
on-the-fly via its :doc:`dump image <dump_image>` command and pass
them to an external program, `FFmpeg <https://www.ffmpeg.org>`_ to generate
@ -71,7 +71,7 @@ Here are suggestions on how to perform these tasks:
LAMMPS website for
visualization packages that can process LAMMPS output data.
* **Plotting:** See the next bullet about Pizza.py as well as the
:doc:`Python <Python_head>` doc page for examples of plotting LAMMPS
:doc:`Python <Python_head>` page for examples of plotting LAMMPS
output. Scripts provided with the *python* tool in the tools
directory will extract and massage data in log and dump files to make
it easier to analyze and plot. See the :doc:`Tools <Tools>` doc page

2
doc/src/Intro_overview.rst
View File

@ -25,7 +25,7 @@ the website for details. All versions can be downloaded from the
LAMMPS is designed to be easy to modify or extend with new
capabilities, such as new force fields, atom types, boundary
conditions, or diagnostics. See the :doc:`Modify <Modify>` doc page for
conditions, or diagnostics. See the :doc:`Modify <Modify>` page for
more details.
In the most general sense, LAMMPS integrates Newton's equations of

2
doc/src/Modify_body.rst
View File

@ -6,7 +6,7 @@ Body particles can represent complex entities, such as surface meshes
of discrete points, collections of sub-particles, deformable objects,
etc.
See the :doc:`Howto body <Howto_body>` doc page for an overview of using
See the :doc:`Howto body <Howto_body>` page for an overview of using
body particles and the various body styles LAMMPS supports. New
styles can be created to add new kinds of body particles to LAMMPS.

10
doc/src/Modify_contribute.rst
View File

@ -62,7 +62,7 @@ them open-source, i.e. we can release them under the terms of the GPL
a LGPL (version 2.1) distribution that we make available to developers
on request only and with files that are authorized for that kind of
distribution removed (e.g. interface to FFTW). See the
:doc:`LAMMPS license <Intro_opensource>` doc page for details.
:doc:`LAMMPS license <Intro_opensource>` page for details.
.. note::
@ -80,7 +80,7 @@ distribution removed (e.g. interface to FFTW). See the
.. _lws: https://www.lammps.org
The previous sections of this doc page describe how to add new "style"
The previous sections of this page describe how to add new "style"
files of various kinds to LAMMPS. Packages are simply collections of
one or more new class files which are invoked as a new style within a
LAMMPS input script. If designed correctly, these additions typically
@ -107,7 +107,7 @@ packages in the src directory for examples. If you are uncertain, please ask.
your contribution(s) to be added to main LAMMPS code or one of its
standard packages, it needs to be written in a style compatible with
other LAMMPS source files. This means: 2-character indentation per
level, **no tabs**\ , no lines over 100 characters. I/O is done via
level, **no tabs**, no lines over 100 characters. I/O is done via
the C-style stdio library (mixing of stdio and iostreams is generally
discouraged), class header files should not import any system headers
outside of <cstdio>, STL containers should be avoided in headers,
@ -203,11 +203,11 @@ packages in the src directory for examples. If you are uncertain, please ask.
pdf" in the doc folder. As appropriate, the text files can include
inline mathematical expression or figures (see doc/JPG for examples).
Additional PDF files with further details (see doc/PDF for examples)
may also be included. The doc page should also include literature
may also be included. The page should also include literature
citations as appropriate; see the bottom of doc/fix_nh.rst for
examples and the earlier part of the same file for how to format the
cite itself. Citation labels must be unique across all .rst files.
The "Restrictions" section of the doc page should indicate if your
The "Restrictions" section of the page should indicate if your
command is only available if LAMMPS is built with the appropriate
FOO package. See other package doc files for examples of
how to do this. Please run at least "make html" and "make spelling"

2
doc/src/Modify_fix.rst
View File

@ -129,7 +129,7 @@ derived class. See fix.h for details.
Typically, only a small fraction of these methods are defined for a
particular fix. Setmask is mandatory, as it determines when the fix
will be invoked during the timestep. Fixes that perform time
integration (\ *nve*\ , *nvt*\ , *npt*\ ) implement initial_integrate() and
integration (\ *nve*, *nvt*, *npt*\ ) implement initial_integrate() and
final_integrate() to perform velocity Verlet updates. Fixes that
constrain forces implement post_force().

2
doc/src/Packages.rst
View File

@ -7,7 +7,7 @@ specific set of features. For example, force fields for molecular
systems or rigid-body constraints are in packages. You can see the
list of all packages and "make" commands to manage them by typing
"make package" from within the src directory of the LAMMPS
distribution. The :doc:`Build package <Build_package>` doc page gives
distribution. The :doc:`Build package <Build_package>` page gives
general info on how to install and un-install packages as part of the
LAMMPS build process.

2
doc/src/Python_call.rst
View File

@ -43,7 +43,7 @@ complex loop with branching logic, than can be created using the
simple looping and branching logic enabled by the :doc:`next <next>` and
:doc:`if <if>` commands.
See the :doc:`python <python>` doc page and the :doc:`variable <variable>`
See the :doc:`python <python>` page and the :doc:`variable <variable>`
doc page for its python-style variables for more info, including
examples of Python code you can write for both pure Python operations
and callbacks to LAMMPS.

2
doc/src/Python_objects.rst
View File

@ -20,7 +20,7 @@ computes, fixes, or variables in LAMMPS using the :py:mod:`lammps` module.
global vector or array, a single double value from the vector or array
is returned, indexed by I (vector) or I and J (array). I,J are
zero-based indices.
See the :doc:`Howto output <Howto_output>` doc page for a discussion of
See the :doc:`Howto output <Howto_output>` page for a discussion of
global, per-atom, and local data, and of scalar, vector, and array
data types. See the doc pages for individual :doc:`computes <compute>`
and :doc:`fixes <fix>` for a description of what they calculate and

2
doc/src/Python_trouble.rst
View File

@ -41,4 +41,4 @@ first importing from the ``lammps`` module:
>>> CDLL("liblammps.so")
If an error occurs, carefully go through the steps in :ref:`python_install_guides` and on the
:doc:`Build_basics <Build_basics>` doc page about building a shared library.
:doc:`Build_basics <Build_basics>` page about building a shared library.

2
doc/src/Run_basics.rst
View File

@ -42,7 +42,7 @@ single processor. In theory you should get identical answers on any
number of processors and on any machine. In practice, numerical
round-off due to using floating-point math can cause slight differences
and an eventual divergence of molecular dynamics trajectories. See the
:doc:`Errors common <Errors_common>` doc page for discussion of this.
:doc:`Errors common <Errors_common>` page for discussion of this.
LAMMPS can run as large a problem as will fit in the physical memory of
one or more processors. If you run out of memory, you must run on more

12
doc/src/Run_options.rst
View File

@ -365,7 +365,7 @@ to insure that a specific Kspace processor (in the second partition) is
matched up with a specific set of processors in the first partition.
See the :doc:`General tips <Speed_tips>` page for more details.
If the keyword *nth* is used with a setting *N*\ , then it means every
If the keyword *nth* is used with a setting *N*, then it means every
Nth processor will be moved to the end of the ranking. This is useful
when using the :doc:`run_style verlet/split <run_style>` command with 2
partitions via the -partition command-line switch. The first set of
@ -397,7 +397,7 @@ so that the processors in each partition will be
See the "processors" command for how to insure processors from each
partition could then be grouped optimally for quad-core nodes.
If the keyword is *custom*\ , then a file that specifies a permutation
If the keyword is *custom*, then a file that specifies a permutation
of the processor ranks is also specified. The format of the reorder
file is as follows. Any number of initial blank or comment lines
(starting with a "#" character) can be present. These should be
@ -464,7 +464,7 @@ The syntax following restartfile (or remap), namely
datafile keyword value ...
is identical to the arguments of the :doc:`write_data <write_data>`
command. See its doc page for details. This includes its
command. See its page for details. This includes its
optional keyword/value settings.
----------
@ -505,11 +505,11 @@ The syntax following restartfile (or remap), namely
group-ID dumpstyle dumpfile arg1 arg2 ...
is identical to the arguments of the :doc:`write_dump <write_dump>`
command. See its doc page for details. This includes what per-atom
command. See its page for details. This includes what per-atom
fields are written to the dump file and optional dump_modify settings,
including ones that affect how parallel dump files are written, e.g.
the *nfile* and *fileper* keywords. See the
:doc:`dump_modify <dump_modify>` doc page for details.
:doc:`dump_modify <dump_modify>` page for details.
----------
@ -537,7 +537,7 @@ partition screen files file.N.
**-suffix style args**
Use variants of various styles if they exist. The specified style can
be *gpu*\ , *intel*\ , *kk*\ , *omp*\ , *opt*\ , or *hybrid*\ . These
be *gpu*, *intel*, *kk*, *omp*, *opt*, or *hybrid*\ . These
refer to optional packages that LAMMPS can be built with, as described
in :doc:`Accelerate performance <Speed>`. The "gpu" style corresponds to the
GPU package, the "intel" style to the INTEL package, the "kk"

2
doc/src/Run_output.rst
View File

@ -152,7 +152,7 @@ information is provided about the line search and statistics on how
many iterations and force-evaluations the minimizer required.
Multiple force evaluations are typically done at each iteration to
perform a 1d line minimization in the search direction. See the
:doc:`minimize <minimize>` doc page for more details.
:doc:`minimize <minimize>` page for more details.
----------

6
doc/src/Speed_gpu.rst
View File

@ -71,7 +71,7 @@ by AMD.
**Building LAMMPS with the GPU package:**
See the :ref:`Build extras <gpu>` doc page for
See the :ref:`Build extras <gpu>` page for
instructions.
**Run with the GPU package from the command line:**
@ -118,7 +118,7 @@ automatic selection of the number of GPUs to use.
Using the "-pk" switch explicitly allows for setting of the number of
GPUs/node to use and additional options. Its syntax is the same as
the "package gpu" command. See the :doc:`package <package>`
command doc page for details, including the default values used for
command page for details, including the default values used for
all its options if it is not specified.
Note that the default for the :doc:`package gpu <package>` command is to
@ -182,7 +182,7 @@ deterministic results.
calculations can be dynamically balanced across the CPU cores and
GPUs. GPU-specific settings can be made which can be optimized
for different hardware. See the :doc:`package <package>` command
doc page for details.
page for details.
* As described by the :doc:`package gpu <package>` command, GPU
accelerated pair styles can perform computations asynchronously with
CPU computations. The "Pair" time reported by LAMMPS will be the

4
doc/src/Speed_intel.rst
View File

@ -103,7 +103,7 @@ Quick Start for Experienced Users
"""""""""""""""""""""""""""""""""
LAMMPS should be built with the INTEL package installed.
Simulations should be run with 1 MPI task per physical *core*\ ,
Simulations should be run with 1 MPI task per physical *core*,
not *hardware thread*\ .
* Edit src/MAKE/OPTIONS/Makefile.intel_cpu_intelmpi as necessary.
@ -205,7 +205,7 @@ this information can normally be obtained with:
Building LAMMPS with the INTEL package
"""""""""""""""""""""""""""""""""""""""""""
See the :ref:`Build extras <intel>` doc page for
See the :ref:`Build extras <intel>` page for
instructions. Some additional details are covered here.
For building with make, several example Makefiles for building with

6
doc/src/Speed_kokkos.rst
View File

@ -67,7 +67,7 @@ produce an executable compatible with a specific hardware.
Building LAMMPS with the KOKKOS package
"""""""""""""""""""""""""""""""""""""""
See the :ref:`Build extras <kokkos>` doc page for instructions.
See the :ref:`Build extras <kokkos>` page for instructions.
Running LAMMPS with the KOKKOS package
""""""""""""""""""""""""""""""""""""""
@ -217,7 +217,7 @@ threads/task as Nt. The product of these two values should be N, i.e.
be best for many-body potentials. For simpler pair-wise potentials, it
may be faster to use a "full" neighbor list with Newton flag to "off".
Use the "-pk kokkos" :doc:`command-line switch <Run_options>` to change
the default :doc:`package kokkos <package>` options. See its doc page for
the default :doc:`package kokkos <package>` options. See its page for
details and default settings. Experimenting with its options can provide
a speed-up for specific calculations. For example:
@ -279,7 +279,7 @@ one or more nodes, each with two GPUs:
setting the neighbor binsize equal to twice the CPU default value will
give speedup, which is the default when running on GPUs. Use the "-pk
kokkos" :doc:`command-line switch <Run_options>` to change the default
:doc:`package kokkos <package>` options. See its doc page for details and
:doc:`package kokkos <package>` options. See its page for details and
default settings. Experimenting with its options can provide a speed-up
for specific calculations. For example:

6
doc/src/Speed_omp.rst
View File

@ -18,7 +18,7 @@ launched by each MPI task on the local node (using shared memory).
Building LAMMPS with the OPENMP package
"""""""""""""""""""""""""""""""""""""""""
See the :ref:`Build extras <openmp>` doc page for
See the :ref:`Build extras <openmp>` page for
instructions.
Run with the OPENMP package from the command line
@ -50,7 +50,7 @@ threads per MPI task via the OMP_NUM_THREADS environment variable.
You can also use the "-pk omp Nt" :doc:`command-line switch <Run_options>`, to explicitly set Nt = # of OpenMP threads
per MPI task to use, as well as additional options. Its syntax is the
same as the :doc:`package omp <package>` command whose doc page gives
same as the :doc:`package omp <package>` command whose page gives
details, including the default values used if it is not specified. It
also gives more details on how to set the number of threads via the
OMP_NUM_THREADS environment variable.
@ -70,7 +70,7 @@ Use the :doc:`suffix omp <suffix>` command, or you can explicitly add an
You must also use the :doc:`package omp <package>` command to enable the
OPENMP package. When you do this you also specify how many threads
per MPI task to use. The command doc page explains other options and
per MPI task to use. The command page explains other options and
how to set the number of threads via the OMP_NUM_THREADS environment
variable.

2
doc/src/Speed_opt.rst
View File

@ -15,7 +15,7 @@ Any hardware. Any compiler.
Building LAMMPS with the OPT package
""""""""""""""""""""""""""""""""""""
See the :ref:`Build extras <opt>` doc page for instructions.
See the :ref:`Build extras <opt>` page for instructions.
Run with the OPT package from the command line
""""""""""""""""""""""""""""""""""""""""""""""

2
doc/src/Tools.rst
View File

@ -363,7 +363,7 @@ michele.ceriotti at gmail.com, to interface to a variety of molecular
dynamics codes.
See the tools/i-pi/manual.pdf file for an overview of i-PI, and the
:doc:`fix ipi <fix_ipi>` doc page for further details on running PIMD
:doc:`fix ipi <fix_ipi>` page for further details on running PIMD
calculations with LAMMPS.
----------

6
doc/src/accel_styles.rst
View File

@ -1,4 +1,4 @@
Styles with a *gpu*\ , *intel*\ , *kk*\ , *omp*\ , or *opt* suffix are
Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
@ -7,11 +7,11 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, INTEL, KOKKOS,
OPENMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` doc page for more info.
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
:doc:`suffix <suffix>` command in your input script.
See the :doc:`Speed packages <Speed_packages>` doc page for more
See the :doc:`Speed packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.

6
doc/src/angle_charmm.rst
View File

@ -56,7 +56,7 @@ radian\^2.
----------
Styles with a *gpu*\ , *intel*\ , *kk*\ , *omp*\ , or *opt* suffix are
Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
@ -65,13 +65,13 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, INTEL, KOKKOS,
OPENMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` doc page for more info.
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
:doc:`suffix <suffix>` command in your input script.
See :doc:`Speed packages <Speed_packages>` doc page for more
See :doc:`Speed packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.
----------

2
doc/src/angle_cosine_delta.rst
View File

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

2
doc/src/angle_cosine_periodic.rst
View File

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

2
doc/src/angle_hybrid.rst
View File

@ -58,7 +58,7 @@ specifying additional BondBond (and BondAngle) coefficients either via
the input script or in the data file. I.e. *class2* must be added to
each line after the angle type. For lines in the BondBond (or
BondAngle) section of the data file for angle types that are not
*class2*\ , you must use an angle style of *skip* as a placeholder, e.g.
*class2*, you must use an angle style of *skip* as a placeholder, e.g.
.. parsed-literal::

2
doc/src/angle_sdk.rst
View File

@ -37,7 +37,7 @@ where :math:`\theta_0` is the equilibrium value of the angle and
*lj/sdk* pair style between the atoms 1 and 3. This angle potential is
intended for coarse grained MD simulations with the CMM parameterization
using the :doc:`pair_style lj/sdk <pair_sdk>`. Relative to the
pair_style *lj/sdk*\ , however, the energy is shifted by
pair_style *lj/sdk*, however, the energy is shifted by
:math:`\epsilon`, to avoid sudden jumps. Note that the usual 1/2 factor
is included in :math:`K`.

4
doc/src/angle_style.rst
View File

@ -66,7 +66,7 @@ specified by the associated :doc:`angle_coeff <angle_coeff>` command.
There are also additional accelerated pair styles included in the
LAMMPS distribution for faster performance on CPUs, GPUs, and KNLs.
The individual style names on the :ref:`Commands angle <angle>` doc page are followed by one or more
The individual style names on the :ref:`Commands angle <angle>` page are followed by one or more
of (g,i,k,o,t) to indicate which accelerated styles exist.
* :doc:`none <angle_none>` - turn off angle interactions
@ -103,7 +103,7 @@ Angle styles can only be set for atom_styles that allow angles to be
defined.
Most angle styles are part of the MOLECULE package. They are only
enabled if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` doc page for more info. The doc pages for
enabled if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info. The doc pages for
individual bond potentials tell if it is part of a package.
Related commands

2
doc/src/atc_control_thermal.rst
View File

@ -66,7 +66,7 @@ Restrictions
Only for be used with the specific controllers *thermal* or *momentum*.
They are ignored if a lumped solution is requested.
*control thermal* is only for be used with specific transfers: thermal (*rescale*\ , *hoover*\ , *flux*\ ), *two_temperature* (*flux*\ ).
*control thermal* is only for be used with specific transfers: thermal (*rescale*, *hoover*, *flux*\ ), *two_temperature* (*flux*\ ).
*rescale* not valid with time filtering activated
*correction_max_iterations* is only for use with *thermal* physics using

2
doc/src/atom_modify.rst
View File

@ -40,7 +40,7 @@ command. The *id* and *map* keywords must be specified before a
simulation box is defined; other keywords can be specified any time.
The *id* keyword determines whether non-zero atom IDs can be assigned
to each atom. If the value is *yes*\ , which is the default, IDs are
to each atom. If the value is *yes*, which is the default, IDs are
assigned, whether you use the :doc:`create atoms <create_atoms>` or
:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
commands to initialize atoms. If the value is *no* the IDs for all

26
doc/src/atom_style.rst
View File

@ -61,7 +61,7 @@ command.
Restrictions section.
Once a style is assigned, it cannot be changed, so use a style general
enough to encompass all attributes. E.g. with style *bond*\ , angular
enough to encompass all attributes. E.g. with style *bond*, angular
terms cannot be used or added later to the model. It is OK to use a
style more general than needed, though it may be slightly inefficient.
@ -136,13 +136,13 @@ quantities.
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>` doc page for examples of cases
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*\ ,
*ellipsoid*\ , *electron*\ , *peri*\ , *wavepacket*\ , *line*\ , *tri*\ , and
*body* styles, which define finite-size particles. See the :doc:`Howto spherical <Howto_spherical>` doc page for an overview of using
All of the above styles define point particles, except the *sphere*,
*ellipsoid*, *electron*, *peri*, *wavepacket*, *line*, *tri*, and
*body* styles, which define finite-size particles. See the :doc:`Howto spherical <Howto_spherical>` page for an overview of using
finite-size particle models with LAMMPS.
All of the point-particle styles assign mass to particles on a
@ -236,7 +236,7 @@ individual physical bodies from penetrating each other.
For the *spin* style, a magnetic spin is associated to each atom.
Those spins have a norm (their magnetic moment) and a direction.
The *wavepacket* style is similar to *electron*\ , but the electrons may
The *wavepacket* style is similar to *electron*, but the electrons may
consist of several Gaussian wave packets, summed up with coefficients
cs= (cs_re,cs_im). Each of the wave packets is treated as a separate
particle in LAMMPS, wave packets belonging to the same electron must
@ -256,7 +256,7 @@ command. The template stores one or more molecules with a single copy
of the topology info (bonds,angles,etc) of each. Individual atoms
only store a template index and template atom to identify which
molecule and which atom-within-the-molecule they represent. Using the
*template* style instead of the *bond*\ , *angle*\ , *molecular* styles
*template* style instead of the *bond*, *angle*, *molecular* styles
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
@ -283,7 +283,7 @@ the *bstyle* argument. Body particles can represent complex entities,
such as surface meshes of discrete points, collections of
sub-particles, deformable objects, etc.
The :doc:`Howto body <Howto_body>` doc page describes the body styles
The :doc:`Howto body <Howto_body>` page describes the body styles
LAMMPS currently supports, and provides more details as to the kind of
body particles they represent. For all styles, each body particle
stores moments of inertia and a quaternion 4-vector, so that its
@ -332,14 +332,14 @@ styles.
The accelerated styles are part of the KOKKOS package. They are only
enabled if LAMMPS was built with those packages. See the :doc:`Build
package <Build_package>` doc page for more info.
package <Build_package>` page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line
switch <Run_options>` when you invoke LAMMPS, or you can use the
:doc:`suffix <suffix>` command in your input script.
See the :doc:`Speed packages <Speed_packages>` doc page for more
See the :doc:`Speed packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.
Restrictions
@ -350,9 +350,9 @@ This command cannot be used after the simulation box is defined by a
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>` doc page for more info.
<Build_package>` page for more info.
The *angle*\ , *bond*\ , *full*\ , *molecular*\ , and *template* styles are
The *angle*, *bond*, *full*, *molecular*, and *template* styles are
part of the MOLECULE package.
The *line* and *tri* styles are part of the ASPHERE package.
@ -370,7 +370,7 @@ The *electron* style is part of the EFF package for :doc:`electronic force field
The *dpd* style is part of the DPD-REACT package for dissipative
particle dynamics (DPD).
The *edpd*\ , *mdpd*\ , and *tdpd* styles are part of the DPD-MESO package
The *edpd*, *mdpd*, and *tdpd* styles are part of the DPD-MESO package
for energy-conserving dissipative particle dynamics (eDPD), many-body
dissipative particle dynamics (mDPD), and transport dissipative particle
dynamics (tDPD), respectively.

16
doc/src/balance.rst
View File

@ -11,7 +11,7 @@ Syntax
balance thresh style args ... keyword args ...
* thresh = imbalance threshold that must be exceeded to perform a re-balance
* one style/arg pair can be used (or multiple for *x*\ ,\ *y*\ ,\ *z*\ )
* one style/arg pair can be used (or multiple for *x*,\ *y*,\ *z*\ )
* style = *x* or *y* or *z* or *shift* or *rcb*
.. parsed-literal::
@ -170,10 +170,10 @@ fractions of the box length) are also printed.
----------
The method used to perform a load balance is specified by one of the
listed styles (or more in the case of *x*\ ,\ *y*\ ,\ *z*\ ), which are
listed styles (or more in the case of *x*,\ *y*,\ *z*\ ), which are
described in detail below. There are 2 kinds of styles.
The *x*\ , *y*\ , *z*\ , and *shift* styles are "grid" methods which
The *x*, *y*, *z*, and *shift* styles are "grid" methods which
produce a logical 3d grid of processors. They operate by changing the
cutting planes (or lines) between processors in 3d (or 2d), to adjust
the volume (area in 2d) assigned to each processor, as in the
@ -222,7 +222,7 @@ from scratch.
----------
The *x*\ , *y*\ , and *z* styles invoke a "grid" method for balancing, as
The *x*, *y*, and *z* styles invoke a "grid" method for balancing, as
described above. Note that any or all of these 3 styles can be
specified together, one after the other, but they cannot be used with
any other style. This style adjusts the position of cutting planes
@ -263,7 +263,7 @@ once. You should normally only list dimensions where you expect there
to be a density variation in the particles.
Balancing proceeds by adjusting the cutting planes in each of the
dimensions listed in *dimstr*\ , one dimension at a time. For a single
dimensions listed in *dimstr*, one dimension at a time. For a single
dimension, the balancing operation (described below) is iterated on up
to *Niter* times. After each dimension finishes, the imbalance factor
is re-computed, and the balancing operation halts if the *stopthresh*
@ -428,8 +428,8 @@ weights. It assigns the same weight to each particle owned by a
processor based on the total computational time spent by that
processor. See details below on what time window is used. It uses
the same timing information as is used for the :doc:`MPI task timing
breakdown <Run_output>`, namely, for sections *Pair*\ , *Bond*\ ,
*Kspace*\ , and *Neigh*\ . The time spent in those portions of the
breakdown <Run_output>`, namely, for sections *Pair*, *Bond*,
*Kspace*, and *Neigh*\ . The time spent in those portions of the
timestep are measured for each MPI rank, summed, then divided by the
number of particles owned by that processor. I.e. the weight is an
effective CPU time/particle averaged over the particles on that
@ -455,7 +455,7 @@ are for the entire previous run. For the *fix balance* command the
timing data is for only the timesteps since the last balancing
operation was performed. If timing information for the required
sections is not available, e.g. at the beginning of a run, or when the
:doc:`timer <timer>` command is set to either *loop* or *off*\ , a warning
:doc:`timer <timer>` command is set to either *loop* or *off*, a warning
is issued. In this case no weights are computed.
.. note::

2
doc/src/bond_class2.rst
View File

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

2
doc/src/bond_fene.rst
View File

@ -58,7 +58,7 @@ Restrictions
""""""""""""
This bond style can only be used if LAMMPS was built with the MOLECULE
package. See the :doc:`Build package <Build_package>` doc page for more
package. See the :doc:`Build package <Build_package>` page for more
info.
You typically should specify :doc:`special_bonds fene <special_bonds>`

2
doc/src/bond_fene_expand.rst
View File

@ -60,7 +60,7 @@ Restrictions
""""""""""""
This bond style can only be used if LAMMPS was built with the MOLECULE
package. See the :doc:`Build package <Build_package>` doc page for more
package. See the :doc:`Build package <Build_package>` page for more
info.
You typically should specify :doc:`special_bonds fene <special_bonds>`

2
doc/src/bond_gromos.rst
View File

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

2
doc/src/bond_harmonic.rst
View File

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

2
doc/src/bond_hybrid.rst
View File

@ -64,7 +64,7 @@ Restrictions
""""""""""""
This bond style can only be used if LAMMPS was built with the MOLECULE
package. See the :doc:`Build package <Build_package>` doc page for more
package. See the :doc:`Build package <Build_package>` page for more
info.
Unlike other bond styles, the hybrid bond style does not store bond

2
doc/src/bond_morse.rst
View File

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

4
doc/src/bond_nonlinear.rst
View File

@ -51,8 +51,8 @@ or :doc:`read_restart <read_restart>` commands:
Restrictions
""""""""""""
This bond style can only be used if LAMMPS was built with the MOLECULE
package. See the :doc:`Build package <Build_package>` doc page for more
This bond style can only be used if LAMMPS was built with the EXTRA-MOLECULE
package. See the :doc:`Build package <Build_package>` page for more
info.
Related commands

4
doc/src/bond_oxdna.rst
View File

@ -39,7 +39,7 @@ Examples
Description
"""""""""""
The *oxdna/fene* , *oxdna2/fene* and *oxrna2/fene* bond styles use the potential
The *oxdna/fene*, *oxdna2/fene*, and *oxrna2/fene* bond styles use the potential
.. math::
@ -118,7 +118,7 @@ Restrictions
This bond style can only be used if LAMMPS was built with the
CG-DNA package and the MOLECULE and ASPHERE package. See the
:doc:`Build package <Build_package>` doc page for more info.
:doc:`Build package <Build_package>` page for more info.
Related commands
""""""""""""""""

2
doc/src/bond_quartic.rst
View File

@ -96,7 +96,7 @@ Restrictions
""""""""""""
This bond style can only be used if LAMMPS was built with the MOLECULE
package. See the :doc:`Build package <Build_package>` doc page for more
package. See the :doc:`Build package <Build_package>` page for more
info.
The *quartic* style requires that :doc:`special_bonds <special_bonds>`

2
doc/src/bond_style.rst
View File

@ -111,7 +111,7 @@ Bond styles can only be set for atom styles that allow bonds to be
defined.
Most bond styles are part of the MOLECULE package. They are only
enabled if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` doc page for more info. The doc pages for
enabled if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info. The doc pages for
individual bond potentials tell if it is part of a package.
Related commands

2
doc/src/bond_table.rst
View File

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

12
doc/src/boundary.rst
View File

@ -10,7 +10,7 @@ Syntax
boundary x y z
* x,y,z = *p* or *s* or *f* or *m*\ , one or two letters
* x,y,z = *p* or *s* or *f* or *m*, one or two letters
.. parsed-literal::
@ -45,17 +45,17 @@ the other end. A periodic dimension can change in size due to
constant pressure boundary conditions or box deformation (see the :doc:`fix npt <fix_nh>` and :doc:`fix deform <fix_deform>` commands). The *p*
style must be applied to both faces of a dimension.
The styles *f*\ , *s*\ , and *m* mean the box is non-periodic, so that
The styles *f*, *s*, and *m* mean the box is non-periodic, so that
particles do not interact across the boundary and do not move from one
side of the box to the other.
For style *f*\ , the position of the face is fixed. If an atom moves
For style *f*, the position of the face is fixed. If an atom moves
outside the face it will be deleted on the next timestep that
reneighboring occurs. This will typically generate an error unless
you have set the :doc:`thermo_modify lost <thermo_modify>` option to
allow for lost atoms.
For style *s*\ , the position of the face is set so as to encompass the
For style *s*, the position of the face is set so as to encompass the
atoms in that dimension (shrink-wrapping), no matter how far they
move. Note that when the difference between the current box dimensions
and the shrink-wrap box dimensions is large, this can lead to lost
@ -67,7 +67,7 @@ This is best addressed by setting initial box dimensions to match the
shrink-wrapped dimensions more closely, by using *m* style boundaries
(see below).
For style *m*\ , shrink-wrapping occurs, but is bounded by the value
For style *m*, shrink-wrapping occurs, but is bounded by the value
specified in the data or restart file or set by the
:doc:`create_box <create_box>` command. For example, if the upper z
face has a value of 50.0 in the data file, the face will always be
@ -85,7 +85,7 @@ and xhi faces of the box are planes tilting in the +y direction as y
increases. These tilted planes are shrink-wrapped around the atoms to
determine the x extent of the box.
See the :doc:`Howto triclinic <Howto_triclinic>` doc page for a
See the :doc:`Howto triclinic <Howto_triclinic>` page for a
geometric description of triclinic boxes, as defined by LAMMPS, and
how to transform these parameters to and from other commonly used
triclinic representations.

6
doc/src/box.rst
View File

@ -34,15 +34,15 @@ For triclinic (non-orthogonal) simulation boxes, the *tilt* keyword
allows simulation domains to be created with arbitrary tilt factors,
e.g. via the :doc:`create_box <create_box>` or
:doc:`read_data <read_data>` commands. Tilt factors determine how
skewed the triclinic box is; see the :doc:`Howto triclinic <Howto_triclinic>` doc page for a discussion of triclinic
skewed the triclinic box is; see the :doc:`Howto triclinic <Howto_triclinic>` page for a discussion of triclinic
boxes in LAMMPS.
LAMMPS normally requires that no tilt factor can skew the box more
than half the distance of the parallel box length, which is the first
dimension in the tilt factor (x for xz). If *tilt* is set to
*small*\ , which is the default, then an error will be
*small*, which is the default, then an error will be
generated if a box is created which exceeds this limit. If *tilt*
is set to *large*\ , then no limit is enforced. You can create
is set to *large*, then no limit is enforced. You can create
a box with any tilt factors you wish.
Note that if a simulation box has a large tilt factor, LAMMPS will run

30
doc/src/change_box.rst
View File

@ -16,7 +16,7 @@ Syntax
.. parsed-literal::
parameter = *x* or *y* or *z* or *xy* or *xz* or *yz* or *boundary* or *ortho* or *triclinic* or *set* or *remap*
*x*\ , *y*\ , *z* args = style value(s)
*x*, *y*, *z* args = style value(s)
style = *final* or *delta* or *scale* or *volume*
*final* values = lo hi
lo hi = box boundaries after displacement (distance units)
@ -25,14 +25,14 @@ Syntax
*scale* values = factor
factor = multiplicative factor for change in box length after displacement
*volume* value = none = adjust this dim to preserve volume of system
*xy*\ , *xz*\ , *yz* args = style value
*xy*, *xz*, *yz* args = style value
style = *final* or *delta*
*final* value = tilt
tilt = tilt factor after displacement (distance units)
*delta* value = dtilt
dtilt = change in tilt factor after displacement (distance units)
*boundary* args = x y z
x,y,z = *p* or *s* or *f* or *m*\ , one or two letters
x,y,z = *p* or *s* or *f* or *m*, one or two letters
*p* is periodic
*f* is non-periodic and fixed
*s* is non-periodic and shrink-wrapped
@ -82,7 +82,7 @@ The :doc:`create_box <create_box>`, :doc:`read data <read_data>`, and
simulation box is orthogonal or triclinic and their doc pages explain
the meaning of the xy,xz,yz tilt factors.
See the :doc:`Howto triclinic <Howto_triclinic>` doc page for a
See the :doc:`Howto triclinic <Howto_triclinic>` page for a
geometric description of triclinic boxes, as defined by LAMMPS, and
how to transform these parameters to and from other commonly used
triclinic representations.
@ -179,18 +179,18 @@ new owning processors.
----------
For the *x*\ , *y*\ , and *z* parameters, this is the meaning of their
For the *x*, *y*, and *z* parameters, this is the meaning of their
styles and values.
For style *final*\ , the final lo and hi box boundaries of a dimension
For style *final*, the final lo and hi box boundaries of a dimension
are specified. The values can be in lattice or box distance units.
See the discussion of the units keyword below.
For style *delta*\ , plus or minus changes in the lo/hi box boundaries
For style *delta*, plus or minus changes in the lo/hi box boundaries
of a dimension are specified. The values can be in lattice or box
distance units. See the discussion of the units keyword below.
For style *scale*\ , a multiplicative factor to apply to the box length
For style *scale*, a multiplicative factor to apply to the box length
of a dimension is specified. For example, if the initial box length
is 10, and the factor is 1.1, then the final box length will be 11. A
factor less than 1.0 means compression.
@ -199,7 +199,7 @@ The *volume* style changes the specified dimension in such a way that
the overall box volume remains constant with respect to the operation
performed by the preceding keyword. The *volume* style can only be
used following a keyword that changed the volume, which is any of the
*x*\ , *y*\ , *z* keywords. If the preceding keyword "key" had a *volume*
*x*, *y*, *z* keywords. If the preceding keyword "key" had a *volume*
style, then both it and the current keyword apply to the keyword
preceding "key". I.e. this sequence of keywords is allowed:
@ -249,15 +249,15 @@ compressed around its mid point.
----------
For the *xy*\ , *xz*\ , and *yz* parameters, this is the meaning of their
For the *xy*, *xz*, and *yz* parameters, this is the meaning of their
styles and values. Note that changing the tilt factors of a triclinic
box does not change its volume.
For style *final*\ , the final tilt factor is specified. The value
For style *final*, the final tilt factor is specified. The value
can be in lattice or box distance units. See the discussion of the
units keyword below.
For style *delta*\ , a plus or minus change in the tilt factor is
For style *delta*, a plus or minus change in the tilt factor is
specified. The value can be in lattice or box distance units. See
the discussion of the units keyword below.
@ -281,10 +281,10 @@ and upper face of the box. Two letters assigns the first style to the
lower face and the second style to the upper face.
The style *p* means the box is periodic; the other styles mean
non-periodic. For style *f*\ , the position of the face is fixed. For
style *s*\ , the position of the face is set so as to encompass the
non-periodic. For style *f*, the position of the face is fixed. For
style *s*, the position of the face is set so as to encompass the
atoms in that dimension (shrink-wrapping), no matter how far they
move. For style *m*\ , shrink-wrapping occurs, but is bounded by the
move. For style *m*, shrink-wrapping occurs, but is bounded by the
current box edge in that dimension, so that the box will become no
smaller. See the :doc:`boundary <boundary>` command for more
explanation of these style options.

10
doc/src/comm_modify.rst
View File

@ -80,7 +80,7 @@ with the *multi* neighbor style. The *multi/old* communication mode is comparabl
with both the *multi* and *multi/old* neighbor styles.
The *cutoff* keyword allows you to extend the ghost cutoff distance
for communication mode *single*\ , which is the distance from the borders
for communication mode *single*, which is the distance from the borders
of a processor's sub-domain at which ghost atoms are acquired from other
processors. By default the ghost cutoff = neighbor cutoff = pairwise
force cutoff + neighbor skin. See the :doc:`neighbor <neighbor>` command
@ -96,7 +96,7 @@ style present and no *comm_modify cutoff* command used. Otherwise a
warning is printed, if this bond based estimate is larger than the
communication cutoff used.
The *cutoff/multi* option is equivalent to *cutoff*\ , but applies to
The *cutoff/multi* option is equivalent to *cutoff*, but applies to
communication mode *multi* instead. Since the communication cutoffs are
determined per atom collections, a collection specifier is needed and
cutoff for one or multiple collections can be extended. Also ranges of
@ -132,9 +132,9 @@ different processors, or when the interaction straddles a periodic
boundary.
The appropriate ghost cutoff depends on the :doc:`newton bond <newton>`
setting. For newton bond *off*\ , the distance needs to be the furthest
setting. For newton bond *off*, the distance needs to be the furthest
distance between any two atoms in the bond, angle, etc. E.g. the
distance between 1-4 atoms in a dihedral. For newton bond *on*\ , the
distance between 1-4 atoms in a dihedral. For newton bond *on*, the
distance between the central atom in the bond, angle, etc and any
other atom is sufficient. E.g. the distance between 2-4 atoms in a
dihedral.
@ -173,7 +173,7 @@ The *vel* keyword enables velocity information to be communicated with
ghost particles. Depending on the :doc:`atom_style <atom_style>`,
velocity info includes the translational velocity, angular velocity,
and angular momentum of a particle. If the *vel* option is set to
*yes*\ , then ghost atoms store these quantities; if *no* then they do
*yes*, then ghost atoms store these quantities; if *no* then they do
not. The *yes* setting is needed by some pair styles which require
the velocity state of both the I and J particles to compute a pairwise
I,J interaction, as well as by some compute and fix commands.

12
doc/src/compute.rst
View File

@ -35,7 +35,7 @@ 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.
See the :doc:`Howto output <Howto_output>` doc page for a summary of
See the :doc:`Howto output <Howto_output>` page for a summary of
various LAMMPS output options, many of which involve computes.
The ID of a compute can only contain alphanumeric characters and
@ -59,7 +59,7 @@ style produce global quantities.
Note that a single compute can produce either global or per-atom or
local quantities, but not both global and per-atom. It can produce
local quantities in tandem with global or per-atom quantities. The
compute doc page will explain.
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
@ -119,7 +119,7 @@ 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
intensive or extensive value. See the doc page for individual
intensive or extensive value. See the page for individual
computes for further info.
----------
@ -153,19 +153,19 @@ via the :doc:`compute_modify <compute_modify>` command.
Computes can be deleted with the :doc:`uncompute <uncompute>` command.
Code for new computes can be added to LAMMPS; see the
:doc:`Modify <Modify>` doc page for details. The results of their
:doc:`Modify <Modify>` page for details. The results of their
calculations accessed in the various ways described above.
----------
Each compute style has its own doc page which describes its arguments
Each compute style has its own page which describes its arguments
and what it does. Here is an alphabetic list of compute styles
available in LAMMPS. They are also listed in more compact form on the
:doc:`Commands compute <Commands_compute>` doc page.
There are also additional accelerated compute styles included in the
LAMMPS distribution for faster performance on CPUs, GPUs, and KNLs.
The individual style names on the :doc:`Commands compute <Commands_compute>` doc page are followed by one or more of
The individual style names on the :doc:`Commands compute <Commands_compute>` page are followed by one or more of
(g,i,k,o,t) to indicate which accelerated styles exist.
* :doc:`ackland/atom <compute_ackland_atom>` - determines the local lattice structure based on the Ackland formulation

4
doc/src/compute_ackland_atom.rst
View File

@ -63,14 +63,14 @@ Output info
This compute calculates 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>` doc page for an overview of
the :doc:`Howto output <Howto_output>` 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>` doc page for more info.
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
The per-atom vector values will be unitless since they are the
integers defined above.

23
doc/src/compute_adf.rst
View File

@ -62,7 +62,7 @@ neighbor atom in each requested ADF.
command, and means those pairwise interactions do not appear in the
neighbor list. Because this fix uses a neighbor list, it also means
those pairs will not be included in the ADF. This does not apply when
using long-range coulomb interactions (\ *coul/long*\ , *coul/msm*\ ,
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
@ -81,7 +81,7 @@ neighbor atom in each requested ADF.
cannot be performed, and LAMMPS will give an error message. The *skin* value
is what is specified with the :doc:`neighbor <neighbor>` command.
The *itypeN*\ ,\ *jtypeN*\ ,\ *ktypeN* settings can be specified in one of two
The *itypeN*,\ *jtypeN*,\ *ktypeN* settings can be specified in one of two
ways. An explicit numeric value can be used, as in the first example
above. Or a wild-card asterisk can be used to specify a range of atom
types as in the second example above.
@ -92,10 +92,10 @@ all types from 1 to N. A leading asterisk means all types from 1 to n
(inclusive). A middle asterisk means all types from m to n
(inclusive).
If *itypeN*\ , *jtypeN*\ , and *ktypeN* are single values, as in the first example
If *itypeN*, *jtypeN*, and *ktypeN* are single values, as in the first example
above, this means that the ADF is computed where atoms of type *itypeN*
are the central atom, and neighbor atoms of type *jtypeN* and *ktypeN*
are forming the angle. If any of *itypeN*\ , *jtypeN*\ , or *ktypeN*
are forming the angle. If any of *itypeN*, *jtypeN*, or *ktypeN*
represent a range of values via
the wild-card asterisk, as in the second example above, this means that the
ADF is computed where atoms of any of the range of types represented
@ -103,7 +103,7 @@ by *itypeN* are the central atom, and the angle is formed by two neighbors,
one neighbor in the range of types represented by *jtypeN* and another neighbor
in the range of types represented by *ktypeN*\ .
If no *itypeN*\ , *jtypeN*\ , *ktypeN* settings are specified, then
If no *itypeN*, *jtypeN*, *ktypeN* settings are specified, then
LAMMPS will generate a single ADF for all atoms in the group.
The inner cutoff is set to zero and the outer cutoff is set
to the force cutoff. If no pair_style is specified, there is no
@ -135,7 +135,7 @@ Each unique angle satisfying the above criteria is counted only once, regardless
of whether either or both of the neighbor atoms making up the
angle appear in both the J and K lists.
It is OK if a particular angle is included in more than
one individual histogram, due to the way the *itypeN*\ , *jtypeN*\ , *ktypeN*
one individual histogram, due to the way the *itypeN*, *jtypeN*, *ktypeN*
arguments are specified.
The first ADF value for a bin is calculated from the histogram count by
@ -177,13 +177,13 @@ 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
*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
coordinate (angle-related ordinate at midpoint of bin). Each subsequent column has
the two ADF values for a specific set of (\ *itypeN*\ ,\ *jtypeN*\ ,\ *ktypeN*\ )
the two ADF values for a specific set of (\ *itypeN*,\ *jtypeN*,\ *ktypeN*\ )
interactions, as described above. These values can be used
by any command that uses a global values from a compute as input. See
the :doc:`Howto output <Howto_output>` doc page for an overview of
the :doc:`Howto output <Howto_output>` page for an overview of
LAMMPS output options.
The array values calculated by this compute are all "intensive".
@ -191,7 +191,7 @@ The array values calculated by this compute are all "intensive".
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
for a specific set of (\ *itypeN*,\ *jtypeN*,\ *ktypeN*\ ). The values
in the first ADF column are normalized numbers >= 0.0,
whose integral w.r.t. the ordinate is 1,
i.e. the first ADF is a normalized probability distribution.
@ -204,6 +204,9 @@ angles per atom satisfying the ADF criteria.
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.
The ADF is not computed for neighbors outside the force cutoff,
since processors (in parallel) don't know about atom coordinates for
atoms further away than that distance. If you want an ADF for larger

2
doc/src/compute_angle.rst
View File

@ -38,7 +38,7 @@ 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>` doc page for an overview of LAMMPS output
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

2
doc/src/compute_angle_local.rst
View File

@ -128,7 +128,7 @@ array is the number of angles. 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
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>` doc 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 *theta* will be in degrees. The output for *eng* will

2
doc/src/compute_angmom_chunk.rst
View File

@ -75,7 +75,7 @@ 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.
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
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

2
doc/src/compute_basal_atom.rst
View File

@ -59,7 +59,7 @@ 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>` doc page for more info.
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
The output of this compute will be meaningless unless the atoms are on
(or near) hcp lattice sites, since the calculation assumes a

6
doc/src/compute_body_local.rst
View File

@ -36,7 +36,7 @@ Define a computation that calculates properties of individual body
sub-particles. The number of datums 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>` doc page for
explained below. See the :doc:`Howto body <Howto_body>` page for
more details on using body particles.
The local data stored by this command is generated by looping over all
@ -52,7 +52,7 @@ For both body particles and non-body particles, the *type* keyword
will store the type of the particle.
The *integer* keywords mean different things for body and non-body
particles. If the atom is not a body particle, only its *x*\ , *y*\ , *z*
particles. If the atom is not a body particle, only its *x*, *y*, *z*
coordinates can be referenced, using the *integer* keywords 1,2,3.
Note that this means that if you want to access more fields than this
for body particles, then you cannot include non-body particles in the
@ -84,7 +84,7 @@ 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
command that uses local values from a compute as input. See the
:doc:`Howto output <Howto_output>` doc page for an overview of LAMMPS
:doc:`Howto output <Howto_output>` page for an overview of LAMMPS
output options.
The :doc:`units <units>` for output values depend on the body style.

2
doc/src/compute_bond.rst
View File

@ -38,7 +38,7 @@ 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.
These values can be used by any command that uses global scalar or
vector values from a compute as input. See the :doc:`Howto output <Howto_output>` doc page for an overview of LAMMPS output
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

8
doc/src/compute_bond_local.rst
View File

@ -21,7 +21,7 @@ Syntax
*engpot* = bond potential energy
*force* = bond force
*fx*\ ,\ *fy*\ ,\ *fz* = components of bond force
*fx*,\ *fy*,\ *fz* = components of bond force
*engvib* = bond kinetic energy of vibration
*engrot* = bond kinetic energy of rotation
*engtrans* = bond kinetic energy of translation
@ -70,7 +70,7 @@ based on the current separation of the pair of atoms in the bond.
The value *force* is the magnitude of the force acting between the
pair of atoms in the bond.
The values *fx*\ , *fy*\ , and *fz* are the xyz components of
The values *fx*, *fy*, and *fz* are the xyz components of
*force* between the pair of atoms in the bond.
The remaining properties are all computed for motion of the two atoms
@ -178,13 +178,13 @@ array is the number of bonds. 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 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>` doc page for an overview of LAMMPS output
values from a compute as input. See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
options.
The output for *dist* will be in distance :doc:`units <units>`. The
output for *velvib* will be in velocity :doc:`units <units>`. The output
for *omega* will be in velocity/distance :doc:`units <units>`. The
output for *engtrans*\ , *engvib*\ , *engrot*\ , and *engpot* will be in
output for *engtrans*, *engvib*, *engrot*, and *engpot* will be in
energy :doc:`units <units>`. The output for *force* will be in force
:doc:`units <units>`.

6
doc/src/compute_centro_atom.rst
View File

@ -76,7 +76,7 @@ positive parameter. If the atom does not have :math:`N` neighbors
(within the potential cutoff), then its centro-symmetry parameter is
set to 0.0.
If the keyword *axes* has the setting *yes*\ , then this compute also
If the keyword *axes* has the setting *yes*, then this compute also
estimates three symmetry axes for each atom's local neighborhood. The
first two of these are the vectors joining the two pairs of neighbor
atoms with smallest contributions to the centrosymmetry parameter,
@ -106,10 +106,10 @@ Output info
By default, this compute calculates the centrosymmetry 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>` doc 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.
If the *axes* keyword setting is *yes*\ , then a per-atom array is
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
symmetry axis, followed by the second, and third symmetry axes in

128
doc/src/compute_chunk_atom.rst
View File

@ -108,7 +108,7 @@ can simply be accessed by any command that uses per-atom values from a
compute as input, as discussed on the :doc:`Howto output <Howto_output>`
doc page.
See the :doc:`Howto chunk <Howto_chunk>` doc page for an overview of how
See the :doc:`Howto chunk <Howto_chunk>` page for an overview of how
this compute can be used with a variety of other commands to tabulate
properties of a simulation. The page gives several examples of input
script commands that can be used to calculate interesting properties.
@ -130,7 +130,7 @@ those chunks, or not assigned to any chunk.
There are many options for specifying for how and when *Nchunk* is
calculated, and how and when chunk IDs are assigned to atoms. The
details depend on the chunk *style* and its *args*\ , as well as
details depend on the chunk *style* and its *args*, as well as
optional keyword settings. They can also depend on whether a :doc:`fix ave/chunk <fix_ave_chunk>` command is using this compute, since
that command requires *Nchunk* to remain static across windows of
timesteps it specifies, while it accumulates per-chunk averages.
@ -153,13 +153,13 @@ 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.
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*
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
dimension given by *delta*\ . In each dimension, bins are defined
relative to a specified *origin*\ , which may be the lower/upper edge of
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
specified coordinate value. Starting at the origin, sufficient bins
are created in both directions to completely span the simulation box
@ -168,7 +168,7 @@ or the bounds specified by the optional *bounds* keyword.
For orthogonal simulation boxes, the bins are layers, pencils, or
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>` doc page for a discussion of 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"
@ -188,7 +188,7 @@ 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
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
@ -199,12 +199,12 @@ 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,
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
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
@ -216,12 +216,12 @@ scaled differently in the two different dimensions to transform them
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
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
third dimension. For *bin/sphere*\ , the bin with smallest radii is chunk
third dimension. For *bin/sphere*, the bin with smallest radii is chunk
1 and the bni with largest radii is chunk Nchunk = *ncbin*\ . For
*bin/cylinder*\ , the numbering varies most rapidly in the dimension
*bin/cylinder*, the numbering varies most rapidly in the dimension
along the cylinder axis and most slowly in the radial direction.
Each time this compute is invoked, each atom is mapped to a bin based
@ -254,7 +254,7 @@ only the first time that *Nchunk* is calculated.
Note that atoms with a molecule ID = 0, which may be non-molecular
solvent atoms, have an out-of-range chunk ID. These atoms are
discarded (not assigned to any chunk) or assigned to *Nchunk*\ ,
discarded (not assigned to any chunk) or assigned to *Nchunk*,
depending on the value of the *discard* keyword.
----------
@ -304,14 +304,14 @@ explained below, the *nchunk* keyword can be set to *once* which means
If a :doc:`fix ave/chunk <fix_ave_chunk>` command uses this compute, it
can also turn off the re-calculation of *Nchunk* for one or more
windows of timesteps. The extent of the windows, during which Nchunk
is held constant, are determined by the *Nevery*\ , *Nrepeat*\ , *Nfreq*
is held constant, are determined by the *Nevery*, *Nrepeat*, *Nfreq*
values and the *ave* keyword setting that are used by the :doc:`fix ave/chunk <fix_ave_chunk>` command.
Specifically, if *ave* = *one*\ , then for each span of *Nfreq*
Specifically, if *ave* = *one*, then for each span of *Nfreq*
timesteps, *Nchunk* is held constant between the first timestep when
averaging is done (within the Nfreq-length window), and the last
timestep when averaging is done (multiple of Nfreq). If *ave* =
*running* or *window*\ , then *Nchunk* is held constant forever,
*running* or *window*, then *Nchunk* is held constant forever,
starting on the first timestep when the :doc:`fix ave/chunk <fix_ave_chunk>` command invokes this compute.
Note that multiple :doc:`fix ave/chunk <fix_ave_chunk>` commands can use
@ -336,9 +336,9 @@ The *nchunk* keyword applies to all chunk styles. It specifies how
often *Nchunk* is recalculated, which in turn can affect the chunk IDs
assigned to individual atoms.
If *nchunk* is set to *once*\ , then *Nchunk* is only calculated once,
If *nchunk* is set to *once*, then *Nchunk* is only calculated once,
the first time this compute is invoked. If *nchunk* is set to
*every*\ , then *Nchunk* is re-calculated every time the compute is
*every*, then *Nchunk* is re-calculated every time the compute is
invoked. Note that, as described above, the use of this compute
by the :doc:`fix ave/chunk <fix_ave_chunk>` command can override
the *every* setting.
@ -358,12 +358,12 @@ any atom. The *limit* keyword is used by all chunk styles except the
can be tailored using the *bound* keyword (described below) which
effectively limits the size of *Nchunk*\ .
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
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
the *compress* keyword is also used with a setting of *yes*\ , and
the *compress* keyword is also used with a setting of *yes*, and
whether the *compress* keyword is specified before the *limit* keyword
or after.
@ -371,11 +371,11 @@ In all cases, *Nchunk* is first calculated in the usual way for each
chunk style, as described above.
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*\ .
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 >
*Nchunk* will be reset to 0 or *Nchunk*\ , depending on the setting of
*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,21 +384,21 @@ 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
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.
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* < *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 > *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
*Nchunk* is reset to *Nc*\ , which results in extra chunks with no atoms
*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
chunk IDs <= *Nc*, and their original values (e.g. molecule ID or
compute/fix/variable value) will also have been <= *Nc*\ .
----------
@ -413,7 +413,7 @@ time windows (discussed above), the chunk ID's assigned to atoms on
the first step of the time window will persist until the end of the
time window.
If the setting is *every*\ , which is the default, then chunk IDs are
If the setting is *every*, which is the default, then chunk IDs are
re-calculated on any timestep this compute is invoked.
.. note::
@ -435,18 +435,18 @@ set of IDs, where every chunk has one or more atoms assigned to it.
Two possible use cases are as follows. If a large simulation box is
mostly empty space, then the *binning* style may produce many bins
with no atoms. If *compress* is set to *yes*\ , only bins with atoms
with no atoms. If *compress* is set to *yes*, only bins with atoms
will be contribute to *Nchunk*\ . Likewise, the *molecule* or
*compute/fix/variable* styles may produce large *Nchunk* values. For
example, the :doc:`compute cluster/atom <compute_cluster_atom>` command
assigns every atom an atom ID for one of the atoms it is clustered
with. For a million-atom system with 5 clusters, there would only be
5 unique chunk IDs, but the largest chunk ID might be 1 million,
resulting in *Nchunk* = 1 million. If *compress* is set to *yes*\ ,
resulting in *Nchunk* = 1 million. If *compress* is set to *yes*,
*Nchunk* will be reset to 5.
If *compress* is set to *no*\ , which is the default, no compression is
done. If it is set to *yes*\ , all chunk IDs with no atoms are removed
If *compress* is set to *no*, which is the default, no compression is
done. If it is set to *yes*, all chunk IDs with no atoms are removed
from the list of chunk IDs, and the list is sorted. The remaining
chunk IDs are renumbered from 1 to *Nchunk* where *Nchunk* is the new
length of the list. The chunk IDs assigned to each atom reflect
@ -498,23 +498,23 @@ return chunk IDs that are invalid for the previously calculated
*Nchunk*\ .
All the chunk styles except the *binning* styles, must use *discard*
set to either *yes* or *no*\ . If *discard* is set to *yes*\ , which is
set to either *yes* or *no*\ . If *discard* is set to *yes*, which is
the default, then every "discard" atom has its chunk ID set to 0. If
*discard* is set to *no*\ , every "discard" atom has its chunk ID set to
*discard* is set to *no*, every "discard" atom has its chunk ID set to
*Nchunk*\ . I.e. it becomes part of the last chunk.
The *binning* styles use the *discard* keyword to decide whether to
discard atoms outside the spatial domain covered by bins, or to assign
them to the bin they are nearest to.
For the *bin/1d*\ , *bin/2d*\ , *bin/3d* styles the details are as
follows. If *discard* is set to *yes*\ , an out-of-domain atom will
have its chunk ID set to 0. If *discard* is set to *no*\ , the atom
For the *bin/1d*, *bin/2d*, *bin/3d* styles the details are as
follows. If *discard* is set to *yes*, an out-of-domain atom will
have its chunk ID set to 0. If *discard* is set to *no*, the atom
will have its chunk ID set to the first or last bin in that dimension.
If *discard* is set to *mixed*\ , which is the default, it will only
If *discard* is set to *mixed*, which is the default, it will only
have its chunk ID set to the first or last bin if bins extend to the
simulation box boundary in that dimension. This is the case if the
*bound* keyword settings are *lower* and *upper*\ , which is the
*bound* keyword settings are *lower* and *upper*, which is the
default. If the *bound* keyword settings are numeric values, then the
atom will have its chunk ID set to 0 if it is outside the bounds of
any bin. Note that in this case, it is possible that the first or
@ -524,24 +524,24 @@ is only set to 0 if it is outside the first or last bin, not if it is
simply outside the numeric *bounds* setting.
For the *bin/sphere* style the details are as follows. If *discard*
is set to *yes*\ , an out-of-domain atom will have its chunk ID set to
0. If *discard* is set to *no* or *mixed*\ , the atom will have its
is set to *yes*, an out-of-domain atom will have its chunk ID set to
0. If *discard* is set to *no* or *mixed*, the atom will have its
chunk ID set to the first or last bin, i.e. the innermost or outermost
spherical shell. If the distance of the atom from the origin is less
than *rmin*\ , it will be assigned to the first bin. If the distance of
the atom from the origin is greater than *rmax*\ , it will be assigned
than *rmin*, it will be assigned to the first bin. If the distance of
the atom from the origin is greater than *rmax*, it will be assigned
to the last bin.
For the *bin/cylinder* style the details are as follows. If *discard*
is set to *yes*\ , an out-of-domain atom will have its chunk ID set to
0. If *discard* is set to *no*\ , the atom will have its chunk ID set
is set to *yes*, an out-of-domain atom will have its chunk ID set to
0. If *discard* is set to *no*, the atom will have its chunk ID set
to the first or last bin in both the radial and axis dimensions. If
*discard* is set to *mixed*\ , which is the default, the radial
*discard* is set to *mixed*, which is the default, the radial
dimension is treated the same as for *discard* = no. But for the axis
dimension, it will only have its chunk ID set to the first or last
bin if bins extend to the simulation box boundary in the axis
dimension. This is the case if the *bound* keyword settings are
*lower* and *upper*\ , which is the default. If the *bound* keyword
*lower* and *upper*, which is the default. If the *bound* keyword
settings are numeric values, then the atom will have its chunk ID set
to 0 if it is outside the bounds of any bin. Note that in this case,
it is possible that the first or last bin extends beyond the numeric
@ -550,22 +550,22 @@ the case, the chunk ID of the atom is only set to 0 if it is outside
the first or last bin, not if it is simply outside the numeric
*bounds* setting.
If *discard* is set to *no* or *mixed*\ , the atom will have its
If *discard* is set to *no* or *mixed*, the atom will have its
chunk ID set to the first or last bin, i.e. the innermost or outermost
spherical shell. If the distance of the atom from the origin is less
than *rmin*\ , it will be assigned to the first bin. If the distance of
the atom from the origin is greater than *rmax*\ , it will be assigned
than *rmin*, it will be assigned to the first bin. If the distance of
the atom from the origin is greater than *rmax*, it will be assigned
to the last bin.
----------
The *bound* keyword only applies to the *bin/1d*\ , *bin/2d*\ , *bin/3d*
The *bound* keyword only applies to the *bin/1d*, *bin/2d*, *bin/3d*
styles and to the axis dimension of the *bin/cylinder* style;
otherwise it is ignored. It can be used one or more times to limit
the extent of bin coverage in a specified dimension, i.e. to only bin
a portion of the box. If the *lo* setting is *lower* or the *hi*
setting is *upper*\ , the bin extent in that direction extends to the
box boundary. If a numeric value is used for *lo* and/or *hi*\ , then
setting is *upper*, the bin extent in that direction extends to the
box boundary. If a numeric value is used for *lo* and/or *hi*, then
the bin extent in the *lo* or *hi* direction extends only to that
value, which is assumed to be inside (or at least near) the simulation
box boundaries, though LAMMPS does not check for this. Note that
@ -573,7 +573,7 @@ using the *bound* keyword typically reduces the total number of bins
and thus the number of chunks *Nchunk*\ .
The *pbc* keyword only applies to the *bin/sphere* and *bin/cylinder*
styles. If set to *yes*\ , the distance an atom is from the sphere
styles. If set to *yes*, the distance an atom is from the sphere
origin or cylinder axis is calculated in a minimum image sense with
respect to periodic dimensions, when determining which bin the atom is
in. I.e. if x is a periodic dimension and the distance between the
@ -582,18 +582,18 @@ simulation box length in x, then a box length is subtracted to give a
distance < 0.5 \* simulation box length. This allosws the sphere or
cylinder center to be near a box edge, and atoms on the other side of
the periodic box will still be close to the center point/axis. Note
that with a setting of *yes*\ , the outer sphere or cylinder radius must
that with a setting of *yes*, the outer sphere or cylinder radius must
also be <= 0.5 \* simulation box length in any periodic dimension
except for the cylinder axis dimension, or an error is generated.
The *units* keyword only applies to the *binning* styles; otherwise it
is ignored. For the *bin/1d*\ , *bin/2d*\ , *bin/3d* styles, it
is ignored. For the *bin/1d*, *bin/2d*, *bin/3d* styles, it
determines the meaning of the distance units used for the bin sizes
*delta* and for *origin* and *bounds* values if they are coordinate
values. For the *bin/sphere* style it determines the meaning of the
distance units used for *xorig*\ ,\ *yorig*\ ,\ *zorig* and the radii *srmin*
distance units used for *xorig*,\ *yorig*,\ *zorig* and the radii *srmin*
and *srmax*\ . For the *bin/cylinder* style it determines the meaning
of the distance units used for *delta*\ ,\ *c1*\ ,\ *c2* and the radii *crmin*
of the distance units used for *delta*,\ *c1*,\ *c2* and the radii *crmin*
and *crmax*\ .
For orthogonal simulation boxes, any of the 3 options may
@ -627,7 +627,7 @@ This compute calculates a per-atom vector (the chunk ID), which can
be accessed by any command that uses per-atom values from a compute
as input. It also calculates a global scalar (the number of chunks),
which can be similarly accessed everywhere outside of a per-atom context.
See the :doc:`Howto output <Howto_output>` doc page for an overview of
See the :doc:`Howto output <Howto_output>` page for an overview of
LAMMPS output options.
The per-atom vector values are unitless chunk IDs, ranging from 1 to
@ -637,7 +637,7 @@ belonging to a chunk. The scalar contains the value of *Nchunk*.
Restrictions
""""""""""""
Even if the *nchunk* keyword is set to *once*\ , the chunk IDs assigned
Even if the *nchunk* keyword is set to *once*, the chunk IDs assigned
to each atom are not stored in a restart files. This means you cannot
expect those assignments to persist in a restarted simulation.
Instead you must re-specify this command and assign atoms to chunks when

2
doc/src/compute_chunk_spread_atom.rst
View File

@ -193,7 +193,7 @@ Output info
This compute calculates a per-atom vector or array, which 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
input. See the :doc:`Howto output <Howto_output>` page for an
overview of LAMMPS output options.
The output is a per-atom vector if a single input value is specified,

9
doc/src/compute_cluster_atom.rst
View File

@ -89,7 +89,7 @@ style computes.
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 when computing the clusters. This
does not apply when using long-range coulomb (\ *coul/long*\ , *coul/msm*\ ,
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
@ -111,14 +111,16 @@ Output info
This compute calculates 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>` doc page for an overview of
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.
Restrictions
""""""""""""
none
These computes are part of the EXTRA-COMPUTE package. They are only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
Related commands
""""""""""""""""
@ -128,6 +130,5 @@ Related commands
Default
"""""""
The default for fragment/atom is single no.

2
doc/src/compute_cna_atom.rst
View File

@ -84,7 +84,7 @@ Output info
This compute calculates 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>` doc page for an overview of
the :doc:`Howto output <Howto_output>` page for an overview of
LAMMPS output options.
The per-atom vector values will be a number from 0 to 5, as explained

6
doc/src/compute_cnp_atom.rst
View File

@ -43,7 +43,7 @@ This parameter is computed using the following formula from
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}
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
*i*, and the index *k* goes over the :math:`n_{ij}` common nearest neighbors
between atom *i* and atom *j*\ . :math:`\vec{R}_{ik}` and
:math:`\vec{R}_{jk}` are the vectors connecting atom *k* to atoms *i*
and *j*\ . The quantity in the double sum is computed
@ -91,7 +91,7 @@ Output info
This compute calculates 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>` doc page for an overview of
the :doc:`Howto output <Howto_output>` page for an overview of
LAMMPS output options.
The per-atom vector values will be real positive numbers. Some typical CNP
@ -111,7 +111,7 @@ 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>` doc page for more info.
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
Related commands
""""""""""""""""

6
doc/src/compute_contact_atom.rst
View File

@ -39,7 +39,7 @@ Output info
This compute calculates a per-atom vector, whose 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
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
@ -48,6 +48,10 @@ above.
Restrictions
""""""""""""
This compute is part of the GRANULAR 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 requires that atoms store a radius as defined by the
:doc:`atom_style sphere <atom_style>` command.

4
doc/src/compute_coord_atom.rst
View File

@ -73,7 +73,7 @@ from 1 to N. A leading asterisk means all types from 1 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
@ -85,7 +85,7 @@ 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
orientorder/atom compute is larger than the specified *threshold*\ ,
orientorder/atom compute is larger than the specified *threshold*,
then I and J are connected, and the coordination value of I is
incremented by one.

4
doc/src/compute_damage_atom.rst
View File

@ -45,7 +45,7 @@ Output info
This compute calculates 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>` doc page for an overview of
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.
@ -54,7 +54,7 @@ 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>` doc page for more info.
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
Related commands
""""""""""""""""

2
doc/src/compute_dihedral.rst
View File

@ -37,7 +37,7 @@ 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>` doc page for an overview of LAMMPS output
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

2
doc/src/compute_dihedral_local.rst
View File

@ -122,7 +122,7 @@ 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
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>` doc 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.

4
doc/src/compute_dilatation_atom.rst
View File

@ -48,7 +48,7 @@ Output info
This compute calculates 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>` doc page for an overview of
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.
@ -57,7 +57,7 @@ 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>` doc page for more info.
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
Related commands
""""""""""""""""

4
doc/src/compute_dipole.rst
View File

@ -12,7 +12,7 @@ Syntax
* 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)
* charge-correction = *mass* or *geometry*, use COM or geometric center for charged chunk correction (optional)
Examples
""""""""
@ -51,7 +51,7 @@ Output info
This compute calculations a global scalar containing the magnitude of
the computed dipole moment and a global vector of length 3 with the
dipole vector. See the :doc:`Howto output <Howto_output>` doc page for
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

4
doc/src/compute_dipole_chunk.rst
View File

@ -13,7 +13,7 @@ Syntax
* 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)
* charge-correction = *mass* or *geometry*, use COM or geometric center for charged chunk correction (optional)
Examples
""""""""
@ -84,7 +84,7 @@ 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. 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.
<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>`.

4
doc/src/compute_dpd.rst
View File

@ -52,7 +52,7 @@ 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.
See the :doc:`Howto output <Howto_output>` doc page for an overview of
See the :doc:`Howto output <Howto_output>` page for an overview of
LAMMPS output options.
The vector values will be in energy and temperature :doc:`units <units>`.
@ -61,7 +61,7 @@ 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>` doc 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.

4
doc/src/compute_dpd_atom.rst
View File

@ -40,7 +40,7 @@ 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
command that uses per-particle values from a compute as input. See
the :doc:`Howto output <Howto_output>` doc page for an overview of
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}`,
@ -51,7 +51,7 @@ 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>` doc 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.

4
doc/src/compute_edpd_temp_atom.rst
View File

@ -36,7 +36,7 @@ Output info
This compute calculates 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>` doc page for an overview of LAMMPS
:doc:`Howto output <Howto_output>` page for an overview of LAMMPS
output options.
The per-atom vector values will be in temperature :doc:`units <units>`.
@ -45,7 +45,7 @@ Restrictions
""""""""""""
This compute is part of the DPD-MESO package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` doc page for more info.
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
Related commands
""""""""""""""""

2
doc/src/compute_efield_atom.rst
View File

@ -52,7 +52,7 @@ Output info
This compute calculates 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>` doc page for an overview of
the :doc:`Howto output <Howto_output>` page for an overview of
LAMMPS output options.
The per-atom vector values will be in electric field :doc:`units <units>`.

6
doc/src/compute_entropy_atom.rst
View File

@ -67,7 +67,7 @@ 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).
If the keyword *avg* has the setting *yes*\ , then this compute also
If the keyword *avg* has the setting *yes*, then this compute also
averages the parameter over the neighbors of atom i according to:
.. math::
@ -114,7 +114,7 @@ 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>` doc 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
@ -125,7 +125,7 @@ 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>` doc page for more info.
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
Related commands
""""""""""""""""

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