<li class="toctree-l2"><a class="reference internal" href="#general-strategies">5.2. General strategies</a></li>
<li class="toctree-l2"><a class="reference internal" href="#packages-with-optimized-styles">5.3. Packages with optimized styles</a></li>
<li class="toctree-l2"><a class="reference internal" href="#comparison-of-various-accelerator-packages">5.4. Comparison of various accelerator packages</a></li>
<p>Before trying to make your simulation run faster, you should
understand how it currently performs and where the bottlenecks are.</p>
<p>The best way to do this is run the your system (actual number of
atoms) for a modest number of timesteps (say 100 steps) on several
different processor counts, including a single processor if possible.
Do this for an equilibrium version of your system, so that the
100-step timings are representative of a much longer run. There is
typically no need to run for 1000s of timesteps to get accurate
timings; you can simply extrapolate from short runs.</p>
<p>For the set of runs, look at the timing data printed to the screen and
log file at the end of each LAMMPS run. <a class="reference internal" href="Section_start.html#start-8"><span class="std std-ref">This section</span></a> of the manual has an overview.</p>
<p>Running on one (or a few processors) should give a good estimate of
the serial performance and what portions of the timestep are taking
the most time. Running the same problem on a few different processor
counts should give an estimate of parallel scalability. I.e. if the
simulation runs 16x faster on 16 processors, its 100% parallel
efficient; if it runs 8x faster on 16 processors, it’s 50% efficient.</p>
<p>The most important data to look at in the timing info is the timing
breakdown and relative percentages. For example, trying different
options for speeding up the long-range solvers will have little impact
if they only consume 10% of the run time. If the pairwise time is
dominating, you may want to look at GPU or OMP versions of the pair
style, as discussed below. Comparing how the percentages change as
you increase the processor count gives you a sense of how different
operations within the timestep are scaling. Note that if you are
running with a Kspace solver, there is additional output on the
breakdown of the Kspace time. For PPPM, this includes the fraction
spent on FFTs, which can be communication intensive.</p>
<p>Another important detail in the timing info are the histograms of
atoms counts and neighbor counts. If these vary widely across
processors, you have a load-imbalance issue. This often results in
inaccurate relative timing data, because processors have to wait when
communication occurs for other processors to catch up. Thus the
reported times for “Communication” or “Other” may be higher than they
really are, due to load-imbalance. If this is an issue, you can
uncomment the MPI_Barrier() lines in src/timer.cpp, and recompile
LAMMPS, to obtain synchronized timings.</p>
<hr class="docutils" />
</div>
<div class="section" id="general-strategies">
<span id="acc-2"></span><h2>5.2. General strategies</h2>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">this section 5.2 is still a work in progress</p>
</div>
<p>Here is a list of general ideas for improving simulation performance.
Most of them are only applicable to certain models and certain
bottlenecks in the current performance, so let the timing data you
generate be your guide. It is hard, if not impossible, to predict how
much difference these options will make, since it is a function of
problem size, number of processors used, and your machine. There is
no substitute for identifying performance bottlenecks, and trying out
various options.</p>
<ul class="simple">
<li>rRESPA</li>
<li>2-FFT PPPM</li>
<li>Staggered PPPM</li>
<li>single vs double PPPM</li>
<li>partial charge PPPM</li>
<li>verlet/split run style</li>
<li>processor command for proc layout and numa layout</li>
<li>load-balancing: balance and fix balance</li>
</ul>
<p>2-FFT PPPM, also called <em>analytic differentiation</em> or <em>ad</em> PPPM, uses
2 FFTs instead of the 4 FFTs used by the default <em>ik differentiation</em>
PPPM. However, 2-FFT PPPM also requires a slightly larger mesh size to
achieve the same accuracy as 4-FFT PPPM. For problems where the FFT
cost is the performance bottleneck (typically large problems running
on many processors), 2-FFT PPPM may be faster than 4-FFT PPPM.</p>
<p>Staggered PPPM performs calculations using two different meshes, one
shifted slightly with respect to the other. This can reduce force
aliasing errors and increase the accuracy of the method, but also
doubles the amount of work required. For high relative accuracy, using
staggered PPPM allows one to half the mesh size in each dimension as
compared to regular PPPM, which can give around a 4x speedup in the
kspace time. However, for low relative accuracy, using staggered PPPM
gives little benefit and can be up to 2x slower in the kspace
time. For example, the rhodopsin benchmark was run on a single
processor, and results for kspace time vs. relative accuracy for the
different methods are shown in the figure below. For this system,
staggered PPPM (using ik differentiation) becomes useful when using a
relative accuracy of slightly greater than 1e-5 and above.</p>
<span id="acc-3"></span><h2>5.3. Packages with optimized styles</h2>
<p>Accelerated versions of various <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a>,
<a class="reference internal" href="fix.html"><span class="doc">fixes</span></a>, <a class="reference internal" href="compute.html"><span class="doc">computes</span></a>, and other commands have
been added to LAMMPS, which will typically run faster than the
standard non-accelerated versions. Some require appropriate hardware
to be present on your system, e.g. GPUs or Intel Xeon Phi
coprocessors.</p>
<p>All of these commands are in packages provided with LAMMPS. An
overview of packages is give in <a class="reference internal" href="Section_packages.html"><span class="doc">Section packages</span></a>.</p>
<p>These are the accelerator packages
currently in LAMMPS, either as standard or user packages:</p>
<tr class="row-even"><td>enable specific accelerator support via ‘-k on’ <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>,</td>
<td>only needed for KOKKOS package</td>
</tr>
<tr class="row-odd"><td>set any needed options for the package via “-pk” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> or <a class="reference internal" href="package.html"><span class="doc">package</span></a> command,</td>
<td>only if defaults need to be changed</td>
</tr>
<tr class="row-even"><td>use accelerated styles in your input via “-sf” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> or <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command</td>
<td>lmp_machine -in in.script -sf gpu</td>
</tr>
</tbody>
</table>
<p>Note that the first 4 steps can be done as a single command, using the
src/Make.py tool. This tool is discussed in <a class="reference internal" href="Section_start.html#start-4"><span class="std std-ref">Section 2.4</span></a> of the manual, and its use is
illustrated in the individual accelerator sections. Typically these
steps only need to be done once, to create an executable that uses one
or more accelerator packages.</p>
<p>The last 4 steps can all be done from the command-line when LAMMPS is
launched, without changing your input script, as illustrated in the
individual accelerator sections. Or you can add
<a class="reference internal" href="package.html"><span class="doc">package</span></a> and <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> commands to your input
script.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">With a few exceptions, you can build a single LAMMPS executable
with all its accelerator packages installed. Note however that the
USER-INTEL and KOKKOS packages require you to choose one of their
hardware options when building for a specific platform. I.e. CPU or
Phi option for the USER-INTEL package. Or the OpenMP, Cuda, or Phi
option for the KOKKOS package.</p>
</div>
<p>These are the exceptions. You cannot build a single executable with:</p>
<ul class="simple">
<li>both the USER-INTEL Phi and KOKKOS Phi options</li>
<li>the USER-INTEL Phi or Kokkos Phi option, and the GPU package</li>
</ul>
<p>See the examples/accelerate/README and make.list files for sample
Make.py commands that build LAMMPS with any or all of the accelerator
packages. As an example, here is a command that builds with all the
GPU related packages installed (GPU, KOKKOS with Cuda), including
settings to build the needed auxiliary GPU libraries for Kepler GPUs:</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<a class="reference internal" href="if.html"><span class="doc">if</span></a>, and <a class="reference internal" href="python.html"><span class="doc">python</span></a> commands for examples.</p>
<p>A “#” or “$” character that is between quotes will not be treated as a
comment indicator in (2) or substituted for as a variable in (3).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If the argument is itself a command that requires a quoted
argument (e.g. using a <a class="reference internal" href="print.html"><span class="doc">print</span></a> command as part of an
<a class="reference internal" href="if.html"><span class="doc">if</span></a> or <a class="reference internal" href="run.html"><span class="doc">run every</span></a> command), then single, double, or
triple quotes can be nested in the usual manner. See the doc pages
for those commands for examples. Only one of level of nesting is
allowed, but that should be sufficient for most use cases.</p>
<p>This section describes the structure of a typical LAMMPS input script.
The “examples” directory in the LAMMPS distribution contains many
sample input scripts; the corresponding problems are discussed in
<a class="reference internal" href="Section_example.html"><span class="doc">Section_example</span></a>, and animated on the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>.</p>
<p>A LAMMPS input script typically has 4 parts:</p>
<ol class="arabic simple">
<li>Initialization</li>
<li>Atom definition</li>
<li>Settings</li>
<li>Run a simulation</li>
</ol>
<p>The last 2 parts can be repeated as many times as desired. I.e. run a
simulation, change some settings, run some more, etc. Each of the 4
parts is now described in more detail. Remember that almost all the
commands need only be used if a non-default value is desired.</p>
<ol class="arabic simple">
<li>Initialization</li>
</ol>
<p>Set parameters that need to be defined before atoms are created or
read-in from a file.</p>
<p>The relevant commands are <a class="reference internal" href="units.html"><span class="doc">units</span></a>,
<p>Output options are set by the <a class="reference internal" href="thermo.html"><span class="doc">thermo</span></a>, <a class="reference internal" href="dump.html"><span class="doc">dump</span></a>,
and <a class="reference internal" href="restart.html"><span class="doc">restart</span></a> commands.</p>
<ol class="arabic simple" start="4">
<li>Run a simulation</li>
</ol>
<p>A molecular dynamics simulation is run using the <a class="reference internal" href="run.html"><span class="doc">run</span></a>
command. Energy minimization (molecular statics) is performed using
the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command. A parallel tempering
(replica-exchange) simulation can be run using the
<p>This section lists all LAMMPS commands alphabetically, with a separate
listing below of styles within certain commands. The <a class="reference internal" href="#cmd-4"><span class="std std-ref">previous section</span></a> lists the same commands, grouped by category. Note
that some style options for some commands are part of specific LAMMPS
packages, which means they cannot be used unless the package was
included when LAMMPS was built. Not all packages are included in a
default LAMMPS build. These dependencies are listed as Restrictions
<p>See the <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command for one-line descriptions of
each style or click on the style itself for a full description. Some
of the styles have accelerated versions, which can be used if LAMMPS
is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k =
<p>These are additional compute styles in USER packages, which can be
used if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> command for an overview of pair
potentials. Click on the style itself for a full description. Many
of the styles have accelerated versions, which can be used if LAMMPS
is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k =
<p>These are additional pair styles in USER packages, which can be used
if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="bond_style.html"><span class="doc">bond_style</span></a> command for an overview of bond
potentials. Click on the style itself for a full description. Some
of the styles have accelerated versions, which can be used if LAMMPS
is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k =
<p>These are additional bond styles in USER packages, which can be used
if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="angle_style.html"><span class="doc">angle_style</span></a> command for an overview of
angle potentials. Click on the style itself for a full description.
Some of the styles have accelerated versions, which can be used if
LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
<p>These are additional angle styles in USER packages, which can be used
if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="dihedral_style.html"><span class="doc">dihedral_style</span></a> command for an overview
of dihedral potentials. Click on the style itself for a full
description. Some of the styles have accelerated versions, which can
be used if LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
<p>These are additional dihedral styles in USER packages, which can be
used if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="improper_style.html"><span class="doc">improper_style</span></a> command for an overview
of improper potentials. Click on the style itself for a full
description. Some of the styles have accelerated versions, which can
be used if LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
<p>These are additional improper styles in USER packages, which can be
used if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command for an overview of
Kspace solvers. Click on the style itself for a full description.
Some of the styles have accelerated versions, which can be used if
LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<span id="err-1"></span><h2>12.1. Common problems</h2>
<p>If two LAMMPS runs do not produce the same answer on different
machines or different numbers of processors, this is typically not a
bug. In theory you should get identical answers on any number of
processors and on any machine. In practice, numerical round-off can
cause slight differences and eventual divergence of molecular dynamics
phase space trajectories within a few 100s or few 1000s of timesteps.
However, the statistical properties of the two runs (e.g. average
energy or temperature) should still be the same.</p>
<p>If the <a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> command is used to set initial atom
velocities, a particular atom can be assigned a different velocity
when the problem is run on a different number of processors or on
different machines. If this happens, the phase space trajectories of
the two simulations will rapidly diverge. See the discussion of the
<em>loop</em> option in the <a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> command for details and
options that avoid this issue.</p>
<p>Similarly, the <a class="reference internal" href="create_atoms.html"><span class="doc">create_atoms</span></a> command generates a
lattice of atoms. For the same physical system, the ordering and
numbering of atoms by atom ID may be different depending on the number
of processors.</p>
<p>Some commands use random number generators which may be setup to
produce different random number streams on each processor and hence
will produce different effects when run on different numbers of
processors. A commonly-used example is the <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> command for thermostatting.</p>
<p>A LAMMPS simulation typically has two stages, setup and run. Most
LAMMPS errors are detected at setup time; others like a bond
stretching too far may not occur until the middle of a run.</p>
<p>LAMMPS tries to flag errors and print informative error messages so
you can fix the problem. Of course, LAMMPS cannot figure out your
physics or numerical mistakes, like choosing too big a timestep,
specifying erroneous force field coefficients, or putting 2 atoms on
top of each other! If you run into errors that LAMMPS doesn’t catch
that you think it should flag, please send an email to the
<p>If you get an error message about an invalid command in your input
script, you can determine what command is causing the problem by
looking in the log.lammps file or using the <a class="reference internal" href="echo.html"><span class="doc">echo command</span></a>
to see it on the screen. If you get an error like “Invalid ...
style”, with ... being fix, compute, pair, etc, it means that you
mistyped the style name or that the command is part of an optional
package which was not compiled into your executable. The list of
available styles in your executable can be listed by using <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">the -h command-line argument</span></a>. The installation
and compilation of optional packages is explained in the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">installation instructions</span></a>.</p>
<p>For a given command, LAMMPS expects certain arguments in a specified
order. If you mess this up, LAMMPS will often flag the error, but it
may also simply read a bogus argument and assign a value that is
valid, but not what you wanted. E.g. trying to read the string “abc”
as an integer value of 0. Careful reading of the associated doc page
for the command should allow you to fix these problems. Note that
some commands allow for variables to be specified in place of numeric
constants so that the value can be evaluated and change over the
course of a run. This is typically done with the syntax <em>v_name</em> for
a parameter, where name is the name of the variable. This is only
allowed if the command documentation says it is.</p>
<p>Generally, LAMMPS will print a message to the screen and logfile and
exit gracefully when it encounters a fatal error. Sometimes it will
print a WARNING to the screen and logfile and continue on; you can
decide if the WARNING is important or not. A WARNING message that is
generated in the middle of a run is only printed to the screen, not to
the logfile, to avoid cluttering up thermodynamic output. If LAMMPS
crashes or hangs without spitting out an error message first then it
could be a bug (see <a class="reference internal" href="#err-2"><span class="std std-ref">this section</span></a>) or one of the following
cases:</p>
<p>LAMMPS runs in the available memory a processor allows to be
allocated. Most reasonable MD runs are compute limited, not memory
limited, so this shouldn’t be a bottleneck on most platforms. Almost
all large memory allocations in the code are done via C-style malloc’s
which will generate an error message if you run out of memory.
Smaller chunks of memory are allocated via C++ “new” statements. If
you are unlucky you could run out of memory just when one of these
small requests is made, in which case the code will crash or hang (in
parallel), since LAMMPS doesn’t trap on those errors.</p>
<p>Illegal arithmetic can cause LAMMPS to run slow or crash. This is
typically due to invalid physics and numerics that your simulation is
computing. If you see wild thermodynamic values or NaN values in your
LAMMPS output, something is wrong with your simulation. If you
suspect this is happening, it is a good idea to print out
thermodynamic info frequently (e.g. every timestep) via the
<a class="reference internal" href="thermo.html"><span class="doc">thermo</span></a> so you can monitor what is happening.
Visualizing the atom movement is also a good idea to insure your model
is behaving as you expect.</p>
<p>In parallel, one way LAMMPS can hang is due to how different MPI
implementations handle buffering of messages. If the code hangs
without an error message, it may be that you need to specify an MPI
setting or two (usually via an environment variable) to enable
buffering or boost the sizes of messages that can be buffered.</p>
<p>If you are confident that you have found a bug in LAMMPS, follow these
steps.</p>
<p>Check the <a class="reference external" href="http://lammps.sandia.gov/bug.html">New features and bug fixes</a> section of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW site</a> to see if the bug has already been reported or fixed or the
<a class="reference external" href="http://lammps.sandia.gov/unbug.html">Unfixed bug</a> to see if a fix is
pending.</p>
<p>Check the <a class="reference external" href="http://lammps.sandia.gov/mail.html">mailing list</a>
to see if it has been discussed before.</p>
<p>If not, send an email to the mailing list describing the problem with
any ideas you have as to what is causing it or where in the code the
problem might be. The developers will ask for more info if needed,
such as an input script or data files.</p>
<p>The most useful thing you can do to help us fix the bug is to isolate
the problem. Run it on the smallest number of atoms and fewest number
of processors and with the simplest input script that reproduces the
bug and try to identify what command or combination of commands is
causing the problem.</p>
<p>As a last resort, you can send an email directly to the
<p>means that line #78 in the file src/velocity.cpp generated the error.
Looking in the source code may help you figure out what went wrong.</p>
<p>Note that error messages from <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">user-contributed packages</span></a> are not listed here. If such an
error occurs and is not self-explanatory, you’ll need to look in the
source code or contact the author of the package.</p>
</div>
<div class="section" id="error">
<span id="id2"></span><h2>12.4. Errors:</h2>
<dl class="docutils">
<dt><em>1-3 bond count is inconsistent</em></dt>
<dd>An inconsistency was detected when computing the number of 1-3
neighbors for each atom. This likely means something is wrong with
the bond topologies you have defined.</dd>
<dt><em>1-4 bond count is inconsistent</em></dt>
<dd>An inconsistency was detected when computing the number of 1-4
neighbors for each atom. This likely means something is wrong with
the bond topologies you have defined.</dd>
<dt><em>Accelerator sharing is not currently supported on system</em></dt>
<dd>Multiple MPI processes cannot share the accelerator on your
system. For NVIDIA GPUs, see the nvidia-smi command to change this
setting.</dd>
<dt><em>All angle coeffs are not set</em></dt>
<dd>All angle coefficients must be set in the data file or by the
angle_coeff command before running a simulation.</dd>
<dt><em>All atom IDs = 0 but atom_modify id = yes</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>All atoms of a swapped type must have same charge.</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>All atoms of a swapped type must have the same charge.</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>All bond coeffs are not set</em></dt>
<dd>All bond coefficients must be set in the data file or by the
bond_coeff command before running a simulation.</dd>
<dt><em>All dihedral coeffs are not set</em></dt>
<dd>All dihedral coefficients must be set in the data file or by the
dihedral_coeff command before running a simulation.</dd>
<dt><em>All improper coeffs are not set</em></dt>
<dd>All improper coefficients must be set in the data file or by the
improper_coeff command before running a simulation.</dd>
<dt><em>All masses are not set</em></dt>
<dd>For atom styles that define masses for each atom type, all masses must
be set in the data file or by the mass command before running a
simulation. They must also be set before using the velocity
command.</dd>
<dt><em>All mol IDs should be set for fix gcmc group atoms</em></dt>
<dd>The molecule flag is on, yet not all molecule ids in the fix group
have been set to non-zero positive values by the user. This is an
error since all atoms in the fix gcmc group are eligible for deletion,
rotation, and translation and therefore must have valid molecule ids.</dd>
<dt><em>All pair coeffs are not set</em></dt>
<dd>All pair coefficients must be set in the data file or by the
pair_coeff command before running a simulation.</dd>
<dt><em>All read_dump x,y,z fields must be specified for scaled, triclinic coords</em></dt>
<dd>For triclinic boxes and scaled coordinates you must specify all 3 of
the x,y,z fields, else LAMMPS cannot reconstruct the unscaled
coordinates.</dd>
<dt><em>All universe/uloop variables must have same # of values</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>All variables in next command must be same style</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Angle atom missing in delete_bonds</em></dt>
<dd>The delete_bonds command cannot find one or more atoms in a particular
angle on a particular processor. The pairwise cutoff is too short or
the atoms are too far apart to make a valid angle.</dd>
<dt><em>Angle atom missing in set command</em></dt>
<dd>The set command cannot find one or more atoms in a particular angle on
a particular processor. The pairwise cutoff is too short or the atoms
are too far apart to make a valid angle.</dd>
<dt><em>Angle atoms %d %d %d missing on proc %d at step %ld</em></dt>
<dd>One or more of 3 atoms needed to compute a particular angle are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the angle has blown apart and an atom is
too far away.</dd>
<dt><em>Angle atoms missing on proc %d at step %ld</em></dt>
<dd>One or more of 3 atoms needed to compute a particular angle are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the angle has blown apart and an atom is
too far away.</dd>
<dt><em>Angle coeff for hybrid has invalid style</em></dt>
<dd>Angle style hybrid uses another angle style as one of its
coefficients. The angle style used in the angle_coeff command or read
from a restart file is not recognized.</dd>
<dt><em>Angle coeffs are not set</em></dt>
<dd>No angle coefficients have been assigned in the data file or via the
angle_coeff command.</dd>
<dt><em>Angle extent > half of periodic box length</em></dt>
<dd>This error was detected by the neigh_modify check yes setting. It is
an error because the angle atoms are so far apart it is ambiguous how
it should be defined.</dd>
<dt><em>Angle potential must be defined for SHAKE</em></dt>
<dd>When shaking angles, an angle_style potential must be used.</dd>
<dt><em>Angle style hybrid cannot have hybrid as an argument</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Angle style hybrid cannot have none as an argument</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Angle style hybrid cannot use same angle style twice</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Angle table must range from 0 to 180 degrees</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Angle table parameters did not set N</em></dt>
<dd>List of angle table parameters must include N setting.</dd>
<dt><em>Angle_coeff command before angle_style is defined</em></dt>
<dd>Coefficients cannot be set in the data file or via the angle_coeff
command until an angle_style has been assigned.</dd>
<dt><em>Angle_coeff command before simulation box is defined</em></dt>
<dd>The angle_coeff command cannot be used before a read_data,
read_restart, or create_box command.</dd>
<dt><em>Angle_coeff command when no angles allowed</em></dt>
<dd>The chosen atom style does not allow for angles to be defined.</dd>
<dt><em>Angle_style command when no angles allowed</em></dt>
<dd>The chosen atom style does not allow for angles to be defined.</dd>
<dt><em>Angles assigned incorrectly</em></dt>
<dd>Angles read in from the data file were not assigned correctly to
atoms. This means there is something invalid about the topology
definitions.</dd>
<dt><em>Angles defined but no angle types</em></dt>
<dd>The data file header lists angles but no angle types.</dd>
<dt><em>Append boundary must be shrink/minimum</em></dt>
<dd>The boundary style of the face where atoms are added
must be of type m (shrink/minimum).</dd>
<dt><em>Arccos of invalid value in variable formula</em></dt>
<dd>Argument of arccos() must be between -1 and 1.</dd>
<dt><em>Arcsin of invalid value in variable formula</em></dt>
<dd>Argument of arcsin() must be between -1 and 1.</dd>
<dt><em>Assigning body parameters to non-body atom</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Assigning ellipsoid parameters to non-ellipsoid atom</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Assigning line parameters to non-line atom</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Assigning quat to non-body atom</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Assigning tri parameters to non-tri atom</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>At least one atom of each swapped type must be present to define charges.</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom IDs must be consecutive for velocity create loop all</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom IDs must be used for molecular systems</em></dt>
<dd>Atom IDs are used to identify and find partner atoms in bonds.</dd>
<dt><em>Atom count changed in fix neb</em></dt>
<dd>This is not allowed in a NEB calculation.</dd>
<dt><em>Atom count is inconsistent, cannot write data file</em></dt>
<dd>The sum of atoms across processors does not equal the global number
of atoms. Probably some atoms have been lost.</dd>
<dt><em>Atom count is inconsistent, cannot write restart file</em></dt>
<dd>Sum of atoms across processors does not equal initial total count.
This is probably because you have lost some atoms.</dd>
<dt><em>Atom in too many rigid bodies - boost MAXBODY</em></dt>
<dd>Fix poems has a parameter MAXBODY (in fix_poems.cpp) which determines
the maximum number of rigid bodies a single atom can belong to (i.e. a
multibody joint). The bodies you have defined exceed this limit.</dd>
<dt><em>Atom sort did not operate correctly</em></dt>
<dd>This is an internal LAMMPS error. Please report it to the
developers.</dd>
<dt><em>Atom sorting has bin size = 0.0</em></dt>
<dd>The neighbor cutoff is being used as the bin size, but it is zero.
Thus you must explicitly list a bin size in the atom_modify sort
command or turn off sorting.</dd>
<dt><em>Atom style hybrid cannot have hybrid as an argument</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom style hybrid cannot use same atom style twice</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom style template molecule must have atom types</em></dt>
<dd>The defined molecule(s) does not specify atom types.</dd>
<dt><em>Atom style was redefined after using fix property/atom</em></dt>
<dd>This is not allowed.</dd>
<dt><em>Atom type must be zero in fix gcmc mol command</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom vector in equal-style variable formula</em></dt>
<dd>Atom vectors generate one value per atom which is not allowed
in an equal-style variable.</dd>
<dt><em>Atom-style variable in equal-style variable formula</em></dt>
<dd>Atom-style variables generate one value per atom which is not allowed
in an equal-style variable.</dd>
<dt><em>Atom_modify id command after simulation box is defined</em></dt>
<dd>The atom_modify id command cannot be used after a read_data,
read_restart, or create_box command.</dd>
<dt><em>Atom_modify map command after simulation box is defined</em></dt>
<dd>The atom_modify map command cannot be used after a read_data,
read_restart, or create_box command.</dd>
<dt><em>Atom_modify sort and first options cannot be used together</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom_style command after simulation box is defined</em></dt>
<dd>The atom_style command cannot be used after a read_data,
read_restart, or create_box command.</dd>
<dt><em>Atom_style line can only be used in 2d simulations</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom_style tri can only be used in 3d simulations</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atomfile variable could not read values</em></dt>
<dd>Check the file assigned to the variable.</dd>
<dt><em>Atomfile variable in equal-style variable formula</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atomfile-style variable in equal-style variable formula</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Attempt to pop empty stack in fix box/relax</em></dt>
<dd>Internal LAMMPS error. Please report it to the developers.</dd>
<dt><em>Attempt to push beyond stack limit in fix box/relax</em></dt>
<dd>Internal LAMMPS error. Please report it to the developers.</dd>
<dt><em>Attempting to rescale a 0.0 temperature</em></dt>
<dd>Cannot rescale a temperature that is already 0.0.</dd>
<dt><em>Bad FENE bond</em></dt>
<dd>Two atoms in a FENE bond have become so far apart that the bond cannot
be computed.</dd>
<dt><em>Bad TIP4P angle type for PPPM/TIP4P</em></dt>
<dd>Specified angle type is not valid.</dd>
<dt><em>Bad TIP4P angle type for PPPMDisp/TIP4P</em></dt>
<dd>Specified angle type is not valid.</dd>
<dt><em>Bad TIP4P bond type for PPPM/TIP4P</em></dt>
<dd>Specified bond type is not valid.</dd>
<dt><em>Bad TIP4P bond type for PPPMDisp/TIP4P</em></dt>
<dd>Specified bond type is not valid.</dd>
<dt><em>Bad fix ID in fix append/atoms command</em></dt>
-<dd>The value of the fix_id for keyword spatial must start with ‘<a href="#id6"><span class="problematic" id="id7">f_</span></a>‘.</dd>
+<dd>The value of the fix_id for keyword spatial must start with ‘f_’.</dd>
<dt><em>Bad grid of processors</em></dt>
<dd>The 3d grid of processors defined by the processors command does not
match the number of processors LAMMPS is being run on.</dd>
<dd>This is not allowed if the kspace_modify overlap setting is no.</dd>
<dt><em>PPPM order < minimum allowed order</em></dt>
<dd>The default minimum order is 2. This can be reset by the
kspace_modify minorder command.</dd>
<dt><em>PPPM order cannot be < 2 or > than %d</em></dt>
<dd>This is a limitation of the PPPM implementation in LAMMPS.</dd>
<dt><em>PPPMDisp Coulomb grid is too large</em></dt>
<dd>The global PPPM grid is larger than OFFSET in one or more dimensions.
OFFSET is currently set to 4096. You likely need to decrease the
requested accuracy.</dd>
<dt><em>PPPMDisp Dispersion grid is too large</em></dt>
<dd>The global PPPM grid is larger than OFFSET in one or more dimensions.
OFFSET is currently set to 4096. You likely need to decrease the
requested accuracy.</dd>
<dt><em>PPPMDisp can only currently be used with comm_style brick</em></dt>
<dd>This is a current restriction in LAMMPS.</dd>
<dt><em>PPPMDisp coulomb order cannot be greater than %d</em></dt>
<dd>This is a limitation of the PPPM implementation in LAMMPS.</dd>
<dt><em>PPPMDisp used but no parameters set, for further information please see the pppm/disp documentation</em></dt>
<dd>An efficient and accurate usage of the pppm/disp requires settings via the kspace_modify command. Please see the pppm/disp documentation for further instructions.</dd>
<dt><em>PRD command before simulation box is defined</em></dt>
<dd>The prd command cannot be used before a read_data,
read_restart, or create_box command.</dd>
<dt><em>PRD nsteps must be multiple of t_event</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>PRD t_corr must be multiple of t_event</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Package command after simulation box is defined</em></dt>
<dd>The package command cannot be used afer a read_data, read_restart, or
create_box command.</dd>
<dt><em>Package cuda command without USER-CUDA package enabled</em></dt>
<dd>The USER-CUDA package must be installed via “make yes-user-cuda”
before LAMMPS is built, and the “-c on” must be used to enable the
package.</dd>
<dt><em>Package gpu command without GPU package installed</em></dt>
<dd>The GPU package must be installed via “make yes-gpu” before LAMMPS is
built.</dd>
<dt><em>Package intel command without USER-INTEL package installed</em></dt>
<dd>The USER-INTEL package must be installed via “make yes-user-intel”
before LAMMPS is built.</dd>
<dt><em>Package kokkos command without KOKKOS package enabled</em></dt>
<dd>The KOKKOS package must be installed via “make yes-kokkos” before
LAMMPS is built, and the “-k on” must be used to enable the package.</dd>
<dt><em>Package omp command without USER-OMP package installed</em></dt>
<dd>The USER-OMP package must be installed via “make yes-user-omp” before
LAMMPS is built.</dd>
<dt><em>Pair body requires atom style body</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Pair body requires body style nparticle</em></dt>
<dd>This pair style is specific to the nparticle body style.</dd>
<dt><em>Pair brownian requires atom style sphere</em></dt>
<dd>You specified an inner cutoff for a Coulombic table that is longer
than the global cutoff. Probably not what you wanted.</dd>
<dt><em>Temperature for MSST is not for group all</em></dt>
<dd>User-assigned temperature to MSST fix does not compute temperature for
all atoms. Since MSST computes a global pressure, the kinetic energy
contribution from the temperature is assumed to also be for all atoms.
Thus the pressure used by MSST could be inaccurate.</dd>
<dt><em>Temperature for NPT is not for group all</em></dt>
<dd>User-assigned temperature to NPT fix does not compute temperature for
all atoms. Since NPT computes a global pressure, the kinetic energy
contribution from the temperature is assumed to also be for all atoms.
Thus the pressure used by NPT could be inaccurate.</dd>
<dt><em>Temperature for fix modify is not for group all</em></dt>
<dd>The temperature compute is being used with a pressure calculation
which does operate on group all, so this may be inconsistent.</dd>
<dt><em>Temperature for thermo pressure is not for group all</em></dt>
<dd>User-assigned temperature to thermo via the thermo_modify command does
not compute temperature for all atoms. Since thermo computes a global
pressure, the kinetic energy contribution from the temperature is
assumed to also be for all atoms. Thus the pressure printed by thermo
could be inaccurate.</dd>
<dt><em>The fix ave/spatial command has been replaced by the more flexible fix ave/chunk and compute chunk/atom commands – fix ave/spatial will be removed in the summer of 2015</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>The minimizer does not re-orient dipoles when using fix efield</em></dt>
<dd>This means that only the atom coordinates will be minimized,
not the orientation of the dipoles.</dd>
<dt><em>Too many common neighbors in CNA %d times</em></dt>
<dd>More than the maximum # of neighbors was found multiple times. This
was unexpected.</dd>
<dt><em>Too many inner timesteps in fix ttm</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Too many neighbors in CNA for %d atoms</em></dt>
<dd>More than the maximum # of neighbors was found multiple times. This
was unexpected.</dd>
<dt><em>Triclinic box skew is large</em></dt>
<dd>The displacement in a skewed direction is normally required to be less
than half the box length in that dimension. E.g. the xy tilt must be
between -half and +half of the x box length. You have relaxed the
constraint using the box tilt command, but the warning means that a
LAMMPS simulation may be inefficient as a result.</dd>
<dt><em>Use special bonds = 0,1,1 with bond style fene</em></dt>
<dd>Most FENE models need this setting for the special_bonds command.</dd>
<dt><em>Use special bonds = 0,1,1 with bond style fene/expand</em></dt>
<dd>Most FENE models need this setting for the special_bonds command.</dd>
<dt><em>Using a manybody potential with bonds/angles/dihedrals and special_bond exclusions</em></dt>
<dd>This is likely not what you want to do. The exclusion settings will
eliminate neighbors in the neighbor list, which the manybody potential
needs to calculated its terms correctly.</dd>
<dt><em>Using compute temp/deform with inconsistent fix deform remap option</em></dt>
<dd>Fix nvt/sllod assumes deforming atoms have a velocity profile provided
by “remap v” or “remap none” as a fix deform option.</dd>
<dt><em>Using compute temp/deform with no fix deform defined</em></dt>
<dd>This is probably an error, since it makes little sense to use
compute temp/deform in this case.</dd>
<dt><em>Using fix srd with box deformation but no SRD thermostat</em></dt>
<dd>The deformation will heat the SRD particles so this can
be dangerous.</dd>
<dt><em>Using kspace solver on system with no charge</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Using largest cut-off for lj/long/dipole/long long long</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Using largest cutoff for buck/long/coul/long</em></dt>
<dd>Self-exlanatory.</dd>
<dt><em>Using largest cutoff for lj/long/coul/long</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Using largest cutoff for pair_style lj/long/tip4p/long</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Using package gpu without any pair style defined</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Using pair potential shift with pair_modify compute no</em></dt>
<dd>The shift effects will thus not be computed.</dd>
<dt><em>Using pair tail corrections with nonperiodic system</em></dt>
<dd>This is probably a bogus thing to do, since tail corrections are
computed by integrating the density of a periodic system out to
infinity.</dd>
<dt><em>Using pair tail corrections with pair_modify compute no</em></dt>
<dd>The tail corrections will thus not be computed.</dd>
<dt><em>pair style reax is now deprecated and will soon be retired. Users should switch to pair_style reax/c</em></dt>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The LAMMPS distribution includes an examples sub-directory with many
sample problems. Many are 2d models that run quickly are are
straightforward to visualize, requiring at most a couple of minutes to
run on a desktop machine. Each problem has an input script (in.*) and
produces a log file (log.*) when it runs. Some use a data file
(data.*) of initial coordinates as additional input. A few sample log
file run on different machines and different numbers of processors are
included in the directories to compare your answers to. E.g. a log
file like log.date.crack.foo.P means the “crack” example was run on P
processors of machine “foo” on that date (i.e. with that version of
LAMMPS).</p>
<p>Many of the input files have commented-out lines for creating dump
files and image files.</p>
<p>If you uncomment the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command in the input script, a
text dump file will be produced, which can be animated by various
<a class="reference external" href="http://lammps.sandia.gov/viz.html">visualization programs</a>. It can
also be animated using the xmovie tool described in the <a class="reference internal" href="Section_tools.html"><span class="doc">Additional Tools</span></a> section of the LAMMPS documentation.</p>
<p>If you uncomment the <a class="reference internal" href="dump.html"><span class="doc">dump image</span></a> command in the input
script, and assuming you have built LAMMPS with a JPG library, JPG
snapshot images will be produced when the simulation runs. They can
be quickly post-processed into a movie using commands described on the
-<span class="n">cp</span> <span class="o">../../</span><span class="n">src</span><span class="o">/</span><span class="n">lmp_linux</span> <span class="o">.</span> <span class="c1"># copy LAMMPS executable to this dir</span>
-<span class="n">lmp_linux</span> <span class="o">-</span><span class="ow">in</span> <span class="ow">in</span><span class="o">.</span><span class="n">indent</span> <span class="c1"># run the problem</span>
-</pre></div>
-</div>
+<pre class="literal-block">
+cd indent
+cp ../../src/lmp_linux . # copy LAMMPS executable to this dir
+lmp_linux -in in.indent # run the problem
+</pre>
<p>Running the simulation produces the files <em>dump.indent</em> and
<em>log.lammps</em>. You can visualize the dump file of snapshots with a
variety of 3rd-party tools highlighted on the
<a class="reference external" href="http://lammps.sandia.gov/viz.html">Visualization</a> page of the LAMMPS
web site.</p>
<p>If you uncomment the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a> 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 <a class="reference internal" href="Section_start.html"><span class="doc">Section start 2.2</span></a> 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
<a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a> doc page for more details. E.g. this
Imagemagick command would create a GIF file suitable for viewing in a
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li class="toctree-l3"><a class="reference internal" href="#fixes-that-write-output-files">6.15.5. Fixes that write output files</a></li>
<li class="toctree-l3"><a class="reference internal" href="#computes-that-process-output-quantities">6.15.6. Computes that process output quantities</a></li>
<li class="toctree-l3"><a class="reference internal" href="#fixes-that-process-output-quantities">6.15.7. Fixes that process output quantities</a></li>
<li class="toctree-l3"><a class="reference internal" href="#computes-that-generate-values-to-output">6.15.8. Computes that generate values to output</a></li>
<li class="toctree-l3"><a class="reference internal" href="#fixes-that-generate-values-to-output">6.15.9. Fixes that generate values to output</a></li>
<li class="toctree-l3"><a class="reference internal" href="#variables-that-generate-values-to-output">6.15.10. Variables that generate values to output</a></li>
<li class="toctree-l3"><a class="reference internal" href="#summary-table-of-output-options-and-data-flow-between-commands">6.15.11. Summary table of output options and data flow between commands</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#thermostatting-barostatting-and-computing-temperature">6.16. Thermostatting, barostatting, and computing temperature</a></li>
<li class="toctree-l2"><a class="reference internal" href="#calculating-a-diffusion-coefficient">6.22. Calculating a diffusion coefficient</a></li>
<li class="toctree-l2"><a class="reference internal" href="#using-chunks-to-calculate-system-properties">6.23. Using chunks to calculate system properties</a><ul>
<span id="howto-1"></span><h2>6.1. Restarting a simulation</h2>
<p>There are 3 ways to continue a long LAMMPS simulation. Multiple
<a class="reference internal" href="run.html"><span class="doc">run</span></a> commands can be used in the same input script. Each
run will continue from where the previous run left off. Or binary
restart files can be saved to disk using the <a class="reference internal" href="restart.html"><span class="doc">restart</span></a>
command. At a later time, these binary files can be read via a
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command in a new script. Or they can
be converted to text data files using the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-r command-line switch</span></a> and read by a
<a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command in a new script.</p>
<p>Here we give examples of 2 scripts that read either a binary restart
file or a converted data file and then issue a new run command to
continue where the previous run left off. They illustrate what
settings must be made in the new script. Details are discussed in the
documentation for the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> and
<p>DREIDING is a generic force field developed by the <a class="reference external" href="http://www.wag.caltech.edu">Goddard group</a> at Caltech and is useful for
predicting structures and dynamics of organic, biological and
main-group inorganic molecules. The philosophy in DREIDING is to use
general force constants and geometry parameters based on simple
hybridization considerations, rather than individual force constants
and geometric parameters that depend on the particular combinations of
atoms involved in the bond, angle, or torsion terms. DREIDING has an
<a class="reference internal" href="pair_hbond_dreiding.html"><span class="doc">explicit hydrogen bond term</span></a> to describe
interactions involving a hydrogen atom on very electronegative atoms
(N, O, F).</p>
<p>See <a class="reference internal" href="#howto-mayo"><span class="std std-ref">(Mayo)</span></a> for a description of the DREIDING force field</p>
<p>These style choices compute force field formulas that are consistent
with the DREIDING force field. See each command’s
<p>would run 2 independent simulations, one after the other.</p>
<p>For large numbers of independent simulations, you can use
<a class="reference internal" href="variable.html"><span class="doc">variables</span></a> and the <a class="reference internal" href="next.html"><span class="doc">next</span></a> and
<a class="reference internal" href="jump.html"><span class="doc">jump</span></a> commands to loop over the same input script
multiple times with different settings. For example, this
script, named in.polymer</p>
-<div class="highlight-default"><div class="highlight"><pre><span></span>variable d index run1 run2 run3 run4 run5 run6 run7 run8
+<pre class="literal-block">
+variable d index run1 run2 run3 run4 run5 run6 run7 run8
shell cd $d
read_data data.polymer
run 10000
shell cd ..
clear
next d
jump in.polymer
-</pre></div>
-</div>
+</pre>
<p>would run 8 simulations in different directories, using a data.polymer
file in each directory. The same concept could be used to run the
same system at 8 different temperatures, using a temperature variable
and storing the output in different log and dump files, for example</p>
<div class="highlight-default"><div class="highlight"><pre><span></span>variable a loop 8
variable t index 0.8 0.85 0.9 0.95 1.0 1.05 1.1 1.15
log log.$a
read data.polymer
velocity all create $t 352839
fix 1 all nvt $t $t 100.0
dump 1 all atom 1000 dump.$a
run 100000
clear
next t
next a
jump in.polymer
</pre></div>
</div>
<p>All of the above examples work whether you are running on 1 or
multiple processors, but assumed you are running LAMMPS on a single
partition of processors. LAMMPS can be run on multiple partitions via
the “-partition” command-line switch as described in <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">this section</span></a> of the manual.</p>
<p>In the last 2 examples, if LAMMPS were run on 3 partitions, the same
scripts could be used if the “index” and “loop” variables were
replaced with <em>universe</em>-style variables, as described in the
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command. Also, the “next t” and “next a”
commands would need to be replaced with a single “next a t” command.
With these modifications, the 8 simulations of each script would run
on the 3 partitions one after the other until all were finished.
Initially, 3 simulations would be started simultaneously, one on each
partition. When one finished, that partition would then start
the 4th simulation, and so forth, until all 8 were completed.</p>
<p>NEB is a method for finding transition states and barrier energies.
PRD and TAD are methods for performing accelerated dynamics to find
and perform infrequent events. Parallel tempering or replica exchange
runs different replicas at a series of temperature to facilitate
rare-event sampling.</p>
<p>These commands can only be used if LAMMPS was built with the REPLICA
package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
for more info on packages.</p>
<p>PIMD runs different replicas whose individual particles are coupled
together by springs to model a system or ring-polymers.</p>
<p>This commands can only be used if LAMMPS was built with the USER-MISC
package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
for more info on packages.</p>
<p>In all these cases, you must run with one or more processors per
replica. The processors assigned to each replica are determined at
run-time by using the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-partition command-line switch</span></a> to launch LAMMPS on multiple
partitions, which in this context are the same as replicas. E.g.
<p>calculates rotational kinetic energy which can be <a class="reference internal" href="#howto-15"><span class="std std-ref">output with thermodynamic info</span></a>.</p>
<p>Use one of these 3 pair potentials, which compute forces and torques
<div class="line">theta of HOH angle = 104.52</div>
<div class="line"><br /></div>
</div>
<p>These are the parameters to use for TIP3P with a long-range Coulombic
solver (e.g. Ewald or PPPM in LAMMPS), see <a class="reference internal" href="pair_dipole.html#price"><span class="std std-ref">(Price)</span></a> for
details:</p>
<div class="line-block">
<div class="line">O mass = 15.9994</div>
<div class="line">H mass = 1.008</div>
<div class="line">O charge = -0.830</div>
<div class="line">H charge = 0.415</div>
<div class="line">LJ epsilon of OO = 0.102</div>
<div class="line">LJ sigma of OO = 3.188</div>
<div class="line">LJ epsilon, sigma of OH, HH = 0.0</div>
<div class="line">K of OH bond = 450</div>
<div class="line">r0 of OH bond = 0.9572</div>
<div class="line">K of HOH angle = 55</div>
<div class="line">theta of HOH angle = 104.52</div>
<div class="line"><br /></div>
</div>
<p>Wikipedia also has a nice article on <a class="reference external" href="http://en.wikipedia.org/wiki/Water_model">water models</a>.</p>
<hr class="docutils" />
</div>
<div class="section" id="tip4p-water-model">
<span id="howto-8"></span><h2>6.8. TIP4P water model</h2>
<p>The four-point TIP4P rigid water model extends the traditional
three-point TIP3P model by adding an additional site, usually
massless, where the charge associated with the oxygen atom is placed.
This site M is located at a fixed distance away from the oxygen along
the bisector of the HOH bond angle. A bond style of <em>harmonic</em> and an
angle style of <em>harmonic</em> or <em>charmm</em> should also be used.</p>
<p>A TIP4P model is run with LAMMPS using either this command
<p>For both models, the bond lengths and bond angles should be held fixed
using the <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command.</p>
<p>These are the additional parameters (in real units) to set for O and H
atoms and the water molecule to run a rigid TIP4P model with a cutoff
<a class="reference internal" href="pair_lj.html#jorgensen"><span class="std std-ref">(Jorgensen)</span></a>. Note that the OM distance is specified in
the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> command, not as part of the pair
coefficients.</p>
<div class="line-block">
<div class="line">O mass = 15.9994</div>
<div class="line">H mass = 1.008</div>
<div class="line">O charge = -1.040</div>
<div class="line">H charge = 0.520</div>
<div class="line">r0 of OH bond = 0.9572</div>
<div class="line">theta of HOH angle = 104.52</div>
<div class="line">OM distance = 0.15</div>
<div class="line">LJ epsilon of O-O = 0.1550</div>
<div class="line">LJ sigma of O-O = 3.1536</div>
<div class="line">LJ epsilon, sigma of OH, HH = 0.0</div>
<div class="line">Coulombic cutoff = 8.5</div>
<div class="line"><br /></div>
</div>
<p>For the TIP4/Ice model (J Chem Phys, 122, 234511 (2005);
<a class="reference external" href="http://dx.doi.org/10.1063/1.1931662">http://dx.doi.org/10.1063/1.1931662</a>) these values can be used:</p>
<div class="line-block">
<div class="line">O mass = 15.9994</div>
<div class="line">H mass = 1.008</div>
<div class="line">O charge = -1.1794</div>
<div class="line">H charge = 0.5897</div>
<div class="line">r0 of OH bond = 0.9572</div>
<div class="line">theta of HOH angle = 104.52</div>
<div class="line">OM distance = 0.1577</div>
<div class="line">LJ epsilon of O-O = 0.21084</div>
<div class="line">LJ sigma of O-O = 3.1668</div>
<div class="line">LJ epsilon, sigma of OH, HH = 0.0</div>
<div class="line">Coulombic cutoff = 8.5</div>
<div class="line"><br /></div>
</div>
<p>For the TIP4P/2005 model (J Chem Phys, 123, 234505 (2005);
<a class="reference external" href="http://dx.doi.org/10.1063/1.2121687">http://dx.doi.org/10.1063/1.2121687</a>), these values can be used:</p>
<div class="line-block">
<div class="line">O mass = 15.9994</div>
<div class="line">H mass = 1.008</div>
<div class="line">O charge = -1.1128</div>
<div class="line">H charge = 0.5564</div>
<div class="line">r0 of OH bond = 0.9572</div>
<div class="line">theta of HOH angle = 104.52</div>
<div class="line">OM distance = 0.1546</div>
<div class="line">LJ epsilon of O-O = 0.1852</div>
<div class="line">LJ sigma of O-O = 3.1589</div>
<div class="line">LJ epsilon, sigma of OH, HH = 0.0</div>
<div class="line">Coulombic cutoff = 8.5</div>
<div class="line"><br /></div>
</div>
<p>These are the parameters to use for TIP4P with a long-range Coulombic
solver (e.g. Ewald or PPPM in LAMMPS):</p>
<div class="line-block">
<div class="line">O mass = 15.9994</div>
<div class="line">H mass = 1.008</div>
<div class="line">O charge = -1.0484</div>
<div class="line">H charge = 0.5242</div>
<div class="line">r0 of OH bond = 0.9572</div>
<div class="line">theta of HOH angle = 104.52</div>
<div class="line">OM distance = 0.1250</div>
<div class="line">LJ epsilon of O-O = 0.16275</div>
<div class="line">LJ sigma of O-O = 3.16435</div>
<div class="line">LJ epsilon, sigma of OH, HH = 0.0</div>
<div class="line"><br /></div>
</div>
<p>Note that the when using the TIP4P pair style, the neighobr list
cutoff for Coulomb interactions is effectively extended by a distance
2 * (OM distance), to account for the offset distance of the
fictitious charges on O atoms in water molecules. Thus it is
typically best in an efficiency sense to use a LJ cutoff >= Coulomb
cutoff + 2*(OM distance), to shrink the size of the neighbor list.
This leads to slightly larger cost for the long-range calculation, so
you can test the trade-off for your model. The OM distance and the LJ
and Coulombic cutoffs are set in the <a class="reference internal" href="pair_lj.html"><span class="doc">pair_style lj/cut/tip4p/long</span></a> command.</p>
<p>Wikipedia also has a nice article on <a class="reference external" href="http://en.wikipedia.org/wiki/Water_model">water models</a>.</p>
<hr class="docutils" />
</div>
<div class="section" id="spc-water-model">
<span id="howto-9"></span><h2>6.9. SPC water model</h2>
<p>The SPC water model specifies a 3-site rigid water molecule with
charges and Lennard-Jones parameters assigned to each of the 3 atoms.
In LAMMPS the <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command can be used to hold
the two O-H bonds and the H-O-H angle rigid. A bond style of
<em>harmonic</em> and an angle style of <em>harmonic</em> or <em>charmm</em> should also be
used.</p>
<p>These are the additional parameters (in real units) to set for O and H
atoms and the water molecule to run a rigid SPC model.</p>
<div class="line-block">
<div class="line">O mass = 15.9994</div>
<div class="line">H mass = 1.008</div>
<div class="line">O charge = -0.820</div>
<div class="line">H charge = 0.410</div>
<div class="line">LJ epsilon of OO = 0.1553</div>
<div class="line">LJ sigma of OO = 3.166</div>
<div class="line">LJ epsilon, sigma of OH, HH = 0.0</div>
<div class="line">r0 of OH bond = 1.0</div>
<div class="line">theta of HOH angle = 109.47</div>
<div class="line"><br /></div>
</div>
<p>Note that as originally proposed, the SPC model was run with a 9
Angstrom cutoff for both LJ and Coulommbic terms. It can also be used
with long-range Coulombics (Ewald or PPPM in LAMMPS), without changing
any of the parameters above, though it becomes a different model in
that mode of usage.</p>
<p>The SPC/E (extended) water model is the same, except
the partial charge assignemnts change:</p>
<div class="line-block">
<div class="line">O charge = -0.8476</div>
<div class="line">H charge = 0.4238</div>
<div class="line"><br /></div>
</div>
<p>See the <a class="reference internal" href="#howto-berendsen"><span class="std std-ref">(Berendsen)</span></a> reference for more details on both
the SPC and SPC/E models.</p>
<p>Wikipedia also has a nice article on <a class="reference external" href="http://en.wikipedia.org/wiki/Water_model">water models</a>.</p>
<span id="howto-10"></span><h2>6.10. Coupling LAMMPS to other codes</h2>
<p>LAMMPS is designed to allow it to be coupled to other codes. For
example, a quantum mechanics code might compute forces on a subset of
atoms and pass those forces to LAMMPS. Or a continuum finite element
(FE) simulation might use atom positions as boundary conditions on FE
nodal points, compute a FE solution, and return interpolated forces on
MD atoms.</p>
<p>LAMMPS can be coupled to other codes in at least 3 ways. Each has
advantages and disadvantages, which you’ll have to think about in the
context of your application.</p>
<p>(1) Define a new <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command that calls the other code. In
this scenario, LAMMPS is the driver code. During its timestepping,
the fix is invoked, and can make library calls to the other code,
which has been linked to LAMMPS as a library. This is the way the
<a class="reference external" href="http://www.rpi.edu/~anderk5/lab">POEMS</a> package that performs constrained rigid-body motion on
groups of atoms is hooked to LAMMPS. See the
<a class="reference internal" href="fix_poems.html"><span class="doc">fix poems</span></a> command for more details. See <a class="reference internal" href="Section_modify.html"><span class="doc">this section</span></a> of the documentation for info on how to add
a new fix to LAMMPS.</p>
<p>(2) Define a new LAMMPS command that calls the other code. This is
conceptually similar to method (1), but in this case LAMMPS and the
other code are on a more equal footing. Note that now the other code
is not called during the timestepping of a LAMMPS run, but between
runs. The LAMMPS input script can be used to alternate LAMMPS runs
with calls to the other code, invoked via the new command. The
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command facilitates this with its <em>every</em> option, which
makes it easy to run a few steps, invoke the command, run a few steps,
invoke the command, etc.</p>
<p>In this scenario, the other code can be called as a library, as in
(1), or it could be a stand-alone code, invoked by a system() call
made by the command (assuming your parallel machine allows one or more
processors to start up another program). In the latter case the
stand-alone code could communicate with LAMMPS thru files that the
command writes and reads.</p>
<p>See <a class="reference internal" href="Section_modify.html"><span class="doc">Section_modify</span></a> of the documentation for how
to add a new command to LAMMPS.</p>
<p>(3) Use LAMMPS as a library called by another code. In this case the
other code is the driver and calls LAMMPS as needed. Or a wrapper
code could link and call both LAMMPS and another code as libraries.
Again, the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command has options that allow it to be
invoked with minimal overhead (no setup or clean-up) if you wish to do
multiple short runs, driven by another program.</p>
<p>Examples of driver codes that call LAMMPS as a library are included in
the examples/COUPLE directory of the LAMMPS distribution; see
examples/COUPLE/README for more details:</p>
<ul class="simple">
<li>simple: simple driver programs in C++ and C which invoke LAMMPS as a
library</li>
<li>lammps_quest: coupling of LAMMPS and <a class="reference external" href="http://dft.sandia.gov/Quest">Quest</a>, to run classical
MD with quantum forces calculated by a density functional code</li>
<li>lammps_spparks: coupling of LAMMPS and <a class="reference external" href="http://www.sandia.gov/~sjplimp/spparks.html">SPPARKS</a>, to couple
a kinetic Monte Carlo model for grain growth using MD to calculate
strain induced across grain boundaries</li>
</ul>
<p><a class="reference internal" href="Section_start.html#start-5"><span class="std std-ref">This section</span></a> of the documentation
describes how to build LAMMPS as a library. Once this is done, you
can interface with LAMMPS either via C++, C, Fortran, or Python (or
any other language that supports a vanilla C-like interface). For
example, from C++ you could create one (or more) “instances” of
LAMMPS, pass it an input script to process, or execute individual
commands, all by invoking the correct class methods in LAMMPS. From C
or Fortran you can make function calls to do the same things. See
<a class="reference internal" href="Section_python.html"><span class="doc">Section_python</span></a> of the manual for a description
of the Python wrapper provided with LAMMPS that operates through the
LAMMPS library interface.</p>
<p>The files src/library.cpp and library.h contain the C-style interface
to LAMMPS. See <a class="reference internal" href="#howto-19"><span class="std std-ref">Section_howto 19</span></a> of the
manual for a description of the interface and how to extend it for
your needs.</p>
<p>Note that the lammps_open() function that creates an instance of
LAMMPS takes an MPI communicator as an argument. This means that
instance of LAMMPS will run on the set of processors in the
communicator. Thus the calling code can run LAMMPS on all or a subset
of processors. For example, a wrapper script might decide to
alternate between LAMMPS and another code, allowing them both to run
on all the processors. Or it might allocate half the processors to
LAMMPS and half to the other code and run both codes simultaneously
before syncing them up periodically. Or it might instantiate multiple
instances of LAMMPS to perform different calculations.</p>
<p>A Python-based toolkit distributed by our group can read native LAMMPS
dump files, including custom dump files with additional columns of
user-specified atom information, and convert them to various formats
or pipe them into visualization software directly. See the <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py WWW site</a> for details. Specifically, Pizza.py can convert
LAMMPS dump files into PDB, XYZ, <a class="reference external" href="http://www.ensight.com">Ensight</a>, and VTK formats.
Pizza.py can pipe LAMMPS dump files directly into the Raster3d and
RasMol visualization programs. Pizza.py has tools that do interactive
3d OpenGL visualization and one that creates SVG images of dump file
snapshots.</p>
<p>LAMMPS can create XYZ files directly (via “dump xyz”) which is a
simple text-based file format used by many visualization programs
including <a class="reference external" href="http://www.ks.uiuc.edu/Research/vmd">VMD</a>.</p>
<p>LAMMPS can create DCD files directly (via “dump dcd”) which can be
read by <a class="reference external" href="http://www.ks.uiuc.edu/Research/vmd">VMD</a> in conjunction with a CHARMM PSF file. Using this
form of output avoids the need to convert LAMMPS snapshots to PDB
files. See the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command for more information on DCD
files.</p>
<p>LAMMPS can create XTC files directly (via “dump xtc”) which is GROMACS
file format which can also be read by <a class="reference external" href="http://www.ks.uiuc.edu/Research/vmd">VMD</a> for visualization.
See the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command for more information on XTC files.</p>
where lx = xhi-xlo, and similarly in the y and z dimensions. The 6
parameters, as well as lx,ly,lz, can be output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command.</p>
<p>LAMMPS also allows simulations to be performed in triclinic
(non-orthogonal) simulation boxes shaped as a parallelepiped with
triclinic symmetry. The parallelepiped has its “origin” at
(xlo,ylo,zlo) and is defined by 3 edge vectors starting from the
origin given by <strong>a</strong> = (xhi-xlo,0,0); <strong>b</strong> = (xy,yhi-ylo,0); <strong>c</strong> =
(xz,yz,zhi-zlo). <em>xy,xz,yz</em> can be 0.0 or positive or negative values
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 <strong>a</strong>, <strong>b</strong>, and <strong>c</strong> cannot be arbitrary
vectors. As indicated, <strong>a</strong> must lie on the positive x axis. <strong>b</strong> must
lie in the xy plane, with strictly positive y component. <strong>c</strong> may have
any orientation with strictly positive z component. The requirement
that <strong>a</strong>, <strong>b</strong>, and <strong>c</strong> have strictly positive x, y, and z components,
respectively, ensures that <strong>a</strong>, <strong>b</strong>, and <strong>c</strong> 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.</p>
<p>For example, assume that the 3 vectors <strong>A</strong>,<strong>B</strong>,<strong>C</strong> are the edge
vectors of a general parallelepiped, where there is no restriction on
<strong>A</strong>,<strong>B</strong>,<strong>C</strong> other than they form a complete right-handed basis i.e.
<strong>A</strong> x <strong>B</strong> . <strong>C</strong> > 0. The equivalent LAMMPS <strong>a</strong>,<strong>b</strong>,<strong>c</strong> are a linear
rotation of <strong>A</strong>, <strong>B</strong>, and <strong>C</strong> and can be computed as follows:</p>
-<p>where A = <a href="#id3"><span class="problematic" id="id4">|</span></a><strong>A</strong>| indicates the scalar length of <strong>A</strong>. The hat symbol
+<p>where A = | <strong>A</strong> | indicates the scalar length of <strong>A</strong>. The hat symbol (^)
indicates the corresponding unit vector. <em>beta</em> and <em>gamma</em> are angles
between the vectors described below. Note that by construction,
<strong>a</strong>, <strong>b</strong>, and <strong>c</strong> have strictly positive x, y, and z components, respectively.
If it should happen that
<strong>A</strong>, <strong>B</strong>, and <strong>C</strong> form a left-handed basis, then the above equations
are not valid for <strong>c</strong>. 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.</p>
<p>For consistency, the same rotation/inversion applied to the basis vectors
must also be applied to atom positions, velocities,
and any other vector quantities.
This can be conveniently achieved by first converting to
fractional coordinates in the
old basis and then converting to distance coordinates in the new basis.
The transformation is given by the following equation:</p>
<p>where <em>V</em> is the volume of the box, <strong>X</strong> is the original vector quantity and
<strong>x</strong> is the vector in the LAMMPS basis.</p>
<p>There is no requirement that a triclinic box be periodic in any
dimension, though it typically should be in at least the 2nd dimension
of the tilt (y in xy) if you want to enforce a shift in periodic
boundary conditions across that boundary. Some commands that work
with triclinic boxes, e.g. the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> and <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> commands, require periodicity or non-shrink-wrap
boundary conditions in specific dimensions. See the command doc pages
for details.</p>
<p>The 9 parameters (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) are defined at the
time the simluation box is created. This happens in one of 3 ways.
If the <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> command is used with a region of
style <em>prism</em>, then a triclinic box is setup. See the
<a class="reference internal" href="region.html"><span class="doc">region</span></a> command for details. If the
<a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command is used to define the simulation
box, and the header of the data file contains a line with the “xy xz
yz” keyword, then a triclinic box is setup. See the
<a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command for details. Finally, if the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command reads a restart file which
was written from a simulation using a triclinic box, then a triclinic
box will be setup for the restarted simulation.</p>
<p>Note that you can define a triclinic box with all 3 tilt factors =
0.0, so that it is initially orthogonal. This is necessary if the box
will become non-orthogonal, e.g. due to the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> or
<a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> commands. Alternatively, you can use the
<a class="reference internal" href="change_box.html"><span class="doc">change_box</span></a> command to convert a simulation box from
orthogonal to triclinic and vice versa.</p>
<p>As with orthogonal boxes, LAMMPS defines triclinic box size parameters
lx,ly,lz where lx = xhi-xlo, and similarly in the y and z dimensions.
The 9 parameters, as well as lx,ly,lz, can be output via the
as well as when the box shape changes dynamically during a simulation,
e.g. via the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> or <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a>
commands.</p>
<p>For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
the xy tilt factor must be between -5 and 5. Similarly, both xz and
yz must be between -(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is
not a limitation, since if the maximum tilt factor is 5 (as in this
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 <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a>
command), then the box is “flipped” to an equivalent shape with a tilt
factor within the bounds, so the run can continue. See the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> doc page for further details.</p>
<p>One exception to this rule is if the 1st dimension in the tilt
factor (x for xy) is non-periodic. In that case, the limits on the
tilt factor are not enforced, since flipping the box in that dimension
does not change the atom positions due to non-periodicity. In this
mode, if you tilt the system to extreme angles, the simulation will
simply become inefficient, due to the highly skewed simulation box.</p>
<p>The limitation on not creating a simulation box with a tilt factor
skewing the box more than half the distance of the parallel box length
can be overridden via the <a class="reference internal" href="box.html"><span class="doc">box</span></a> command. Setting the <em>tilt</em>
keyword to <em>large</em> allows any tilt factors to be specified.</p>
<p>Box flips that may occur using the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> or
<a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> commands can be turned off using the <em>flip no</em>
option with either of the commands.</p>
<p>Note that if a simulation box has a large tilt factor, LAMMPS will run
less efficiently, due to the large volume of communication needed to
acquire ghost atoms around a processor’s irregular-shaped sub-domain.
For extreme values of tilt, LAMMPS may also lose atoms and generate an
error.</p>
<p>Triclinic crystal structures are often defined using three lattice
constants <em>a</em>, <em>b</em>, and <em>c</em>, and three angles <em>alpha</em>, <em>beta</em> and
<em>gamma</em>. Note that in this nomenclature, the a, b, and c lattice
constants are the scalar lengths of the edge vectors <strong>a</strong>, <strong>b</strong>, and <strong>c</strong>
defined above. The relationship between these 6 quantities
(a,b,c,alpha,beta,gamma) and the LAMMPS box sizes (lx,ly,lz) =
(xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:</p>
<p>A second use is to run Parinello-Rahman dyanamics via the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command, which will adjust the xy, xz, yz tilt
factors to compensate for off-diagonal components of the pressure
tensor. The analalog for an <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a> is
the <a class="reference internal" href="fix_box_relax.html"><span class="doc">fix box/relax</span></a> command.</p>
<p>A third use is to shear a bulk solid to study the response of the
material. The <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> command can be used for
this purpose. It allows dynamic control of the xy, xz, yz tilt
factors as a simulation runs. This is discussed in the next section
<p>Non-equilibrium molecular dynamics or NEMD simulations are typically
used to measure a fluid’s rheological properties such as viscosity.
In LAMMPS, such simulations can be performed by first setting up a
non-orthogonal simulation box (see the preceding Howto section).</p>
<p>A shear strain can be applied to the simulation box at a desired
strain rate by using the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> command. The
<a class="reference internal" href="fix_nvt_sllod.html"><span class="doc">fix nvt/sllod</span></a> command can be used to thermostat
the sheared fluid and integrate the SLLOD equations of motion for the
system. Fix nvt/sllod uses <a class="reference internal" href="compute_temp_deform.html"><span class="doc">compute temp/deform</span></a> to compute a thermal temperature
by subtracting out the streaming velocity of the shearing atoms. The
velocity profile or other properties of the fluid can be monitored via
the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> command.</p>
<p>As discussed in the previous section on non-orthogonal simulation
boxes, the amount of tilt or skew that can be applied is limited by
LAMMPS for computational efficiency to be 1/2 of the parallel box
length. However, <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> can continuously strain
a box by an arbitrary amount. As discussed in the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> command, when the tilt value reaches a limit,
the box is flipped to the opposite limit which is an equivalent tiling
of periodic space. The strain rate can then continue to change as
before. In a long NEMD simulation these box re-shaping events may
occur many times.</p>
<p>In a NEMD simulation, the “remap” option of <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> should be set to “remap v”, since that is what
<a class="reference internal" href="fix_nvt_sllod.html"><span class="doc">fix nvt/sllod</span></a> assumes to generate a velocity
profile consistent with the applied shear strain rate.</p>
<p>An alternative method for calculating viscosities is provided via the
<p>This is because when dipoles interact with each other, they induce
torques, and a particle must be finite-size (i.e. have a moment of
inertia) in order to respond and rotate. See the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style dipole</span></a> command for details. The “set” command can be
used to modify the orientation and length of the dipole moment of
individual particles, after then are created.</p>
<p>The ellipsoid style defines particles that are ellipsoids and thus can
be aspherical. Each particle has a shape, specified by 3 diameters,
and mass (or density). These particles store an angular momentum and
their orientation (quaternion), and can be acted upon by torque. They
do not store an angular velocity (omega), which can be in a different
direction than angular momentum, rather they compute it as needed.
The “set” command can be used to modify the diameter, orientation, and
mass of individual particles, after then are created. It also has a
brief explanation of what quaternions are.</p>
<p>The line style defines line segment particles with two end points and
a mass (or density). They can be used in 2d simulations, and they can
be joined together to form rigid bodies which represent arbitrary
polygons.</p>
<p>The tri style defines triangular particles with three corner points
and a mass (or density). They can be used in 3d simulations, and they
can be joined together to form rigid bodies which represent arbitrary
particles with a triangulated surface.</p>
<p>The peri style is used with <a class="reference internal" href="pair_peri.html"><span class="doc">Peridynamic models</span></a> and
defines particles as having a volume, that is used internally in the
<p>The body style allows for definition of particles which can represent
complex entities, such as surface meshes of discrete points,
collections of sub-particles, deformable objects, etc. The body style
is discussed in more detail on the <a class="reference internal" href="body.html"><span class="doc">body</span></a> doc page.</p>
<p>Note that if one of these atom styles is used (or multiple styles via
the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style hybrid</span></a> command), not all particles in
the system are required to be finite-size or aspherical.</p>
<p>For example, in the ellipsoid style, if the 3 shape parameters are set
to the same value, the particle will be a sphere rather than an
ellipsoid. If the 3 shape parameters are all set to 0.0 or if the
diameter is set to 0.0, it will be a point particle. In the line or
tri style, if the lineflag or triflag is specified as 0, then it
will be a point particle.</p>
<p>Some of the pair styles used to compute pairwise interactions between
finite-size particles also compute the correct interaction with point
particles as well, e.g. the interaction between a point particle and a
finite-size particle or between two point particles. If necessary,
<a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid</span></a> can be used to insure the correct
interactions are computed for the appropriate style of interactions.
Likewise, using groups to partition particles (ellipsoids versus
spheres versus point particles) will allow you to use the appropriate
time integrators and temperature computations for each class of
particles. See the doc pages for various commands for details.</p>
<p>Also note that for <a class="reference internal" href="dimension.html"><span class="doc">2d simulations</span></a>, atom styles sphere
and ellipsoid still use 3d particles, rather than as circular disks or
ellipses. This means they have the same moment of inertia as the 3d
object. When temperature is computed, the correct degrees of freedom
are used for rotation in a 2d versus 3d system.</p>
</div>
<div class="section" id="pair-potentials">
<h3>6.14.2. Pair potentials</h3>
<p>When a system with finite-size particles is defined, the particles
will only rotate and experience torque if the force field computes
such interactions. These are the various <a class="reference internal" href="pair_style.html"><span class="doc">pair styles</span></a> that generate torque:</p>
<h3>6.14.5. Rigid bodies composed of finite-size particles</h3>
<p>The <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> command treats a collection of
particles as a rigid body, computes its inertia tensor, sums the total
force and torque on the rigid body each timestep due to forces on its
constituent particles, and integrates the motion of the rigid body.</p>
<p>If any of the constituent particles of a rigid body are finite-size
particles (spheres or ellipsoids or line segments or triangles), then
their contribution to the inertia tensor of the body is different than
if they were point particles. This means the rotational dynamics of
the rigid body will be different. Thus a model of a dimer is
different if the dimer consists of two point masses versus two
spheroids, even if the two particles have the same mass. Finite-size
particles that experience torque due to their interaction with other
particles will also impart that torque to a rigid body they are part
of.</p>
<p>See the “fix rigid” command for example of complex rigid-body models
it is possible to define in LAMMPS.</p>
<p>Note that the <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command can also be used to
treat 2, 3, or 4 particles as a rigid body, but it always assumes the
particles are point masses.</p>
<p>Also note that body particles cannot be modeled with the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> command. Body particles are treated by LAMMPS
as single particles, though they can store internal state, such as a
list of sub-particles. Individual body partices are typically treated
as rigid bodies, and their motion integrated with a command like <a class="reference internal" href="fix_nve_body.html"><span class="doc">fix nve/body</span></a>. Interactions between pairs of body
particles are computed via a command like <a class="reference internal" href="pair_body.html"><span class="doc">pair_style body</span></a>.</p>
<span id="howto-15"></span><h2>6.15. Output from LAMMPS (thermo, dumps, computes, fixes, variables)</h2>
<p>There are four basic kinds of LAMMPS output:</p>
<ul class="simple">
<li><a class="reference internal" href="thermo_style.html"><span class="doc">Thermodynamic output</span></a>, which is a list
of quantities printed every few timesteps to the screen and logfile.</li>
<li><a class="reference internal" href="dump.html"><span class="doc">Dump files</span></a>, which contain snapshots of atoms and various
per-atom values and are written at a specified frequency.</li>
<li>Certain fixes can output user-specified quantities to files: <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a> for time averaging, <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> for spatial or other averaging, and <a class="reference internal" href="fix_print.html"><span class="doc">fix print</span></a> for single-line output of
<a class="reference internal" href="variable.html"><span class="doc">variables</span></a>. Fix print can also output to the
<p>A simulation prints one set of thermodynamic output and (optionally)
restart files. It can generate any number of dump files and fix
output files, depending on what <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> and <a class="reference internal" href="fix.html"><span class="doc">fix</span></a>
commands you specify.</p>
<p>As discussed below, LAMMPS gives you a variety of ways to determine
what quantities are computed and printed when the thermodynamics,
dump, or fix commands listed above perform output. Throughout this
discussion, note that users can also <a class="reference internal" href="Section_modify.html"><span class="doc">add their own computes and fixes to LAMMPS</span></a> which can then generate values that can
then be output with these commands.</p>
<p>The following sub-sections discuss different LAMMPS command related
to output and the kind of data they operate on and produce:</p>
<li><a class="reference internal" href="#fixoutput"><span class="std std-ref">Fixes that write output files</span></a></li>
<li><a class="reference internal" href="#computeoutput"><span class="std std-ref">Computes that process output quantities</span></a></li>
<li><a class="reference internal" href="#fixprocoutput"><span class="std std-ref">Fixes that process output quantities</span></a></li>
<li><a class="reference internal" href="#compute"><span class="std std-ref">Computes that generate values to output</span></a></li>
<li><a class="reference internal" href="#fix"><span class="std std-ref">Fixes that generate values to output</span></a></li>
<li><a class="reference internal" href="#variable"><span class="std std-ref">Variables that generate values to output</span></a></li>
<li><a class="reference internal" href="#table"><span class="std std-ref">Summary table of output options and data flow between commands</span></a></li>
<p>Global, per-atom, and local datums can each come in three kinds: a
single scalar value, a vector of values, or a 2d array of values. The
doc page for a “compute” or “fix” or “variable” that generates data
will specify both the style and kind of data it produces, e.g. a
per-atom vector.</p>
<p>When a quantity is accessed, as in many of the output commands
discussed below, it can be referenced via the following bracket
notation, where ID in this case is the ID of a compute. The leading
-“<a href="#id74"><span class="problematic" id="id75">c_</span></a>” would be replaced by “<a href="#id76"><span class="problematic" id="id77">f_</span></a>” for a fix, or “<a href="#id78"><span class="problematic" id="id79">v_</span></a>” for a variable:</p>
+“c_” would be replaced by “f_” for a fix, or “v_” for a variable:</p>
<table border="1" class="docutils">
<colgroup>
-<col width="21%" />
-<col width="79%" />
+<col width="23%" />
+<col width="77%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>c_ID</td>
<td>entire scalar, vector, or array</td>
</tr>
<tr class="row-even"><td>c_ID[I]</td>
<td>one element of vector, one column of array</td>
</tr>
<tr class="row-odd"><td>c_ID[I][J]</td>
<td>one element of array</td>
</tr>
</tbody>
</table>
<p>In other words, using one bracket reduces the dimension of the data
once (vector -> scalar, array -> vector). Using two brackets reduces
the dimension twice (array -> scalar). Thus a command that uses
scalar values as input can typically also process elements of a vector
<a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify</span></a> commands. The
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command also specifies what values
are calculated and written out. Pre-defined keywords can be specified
(e.g. press, etotal, etc). Three additional kinds of keywords can
also be specified (c_ID, f_ID, v_name), where a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>
or <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> or <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> provides the value to be
output. In each case, the compute, fix, or variable must generate
global values for input to the <a class="reference internal" href="dump.html"><span class="doc">thermo_style custom</span></a>
command.</p>
<p>Note that thermodynamic output values can be “extensive” or
“intensive”. The former scale with the number of atoms in the system
(e.g. total energy), the latter do not (e.g. temperature). The
setting for <a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify norm</span></a> determines whether
extensive quantities are normalized or not. Computes and fixes
produce either extensive or intensive values; see their individual doc
pages for details. <a class="reference internal" href="variable.html"><span class="doc">Equal-style variables</span></a> produce only
intensive values; you can include a division by “natoms” in the
formula if desired, to make an extensive calculation produce an
<p>There is also a <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> format where the user
specifies what values are output with each atom. Pre-defined atom
attributes can be specified (id, x, fx, etc). Three additional kinds
of keywords can also be specified (c_ID, f_ID, v_name), where a
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> or <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> or <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>
provides the values to be output. In each case, the compute, fix, or
variable must generate per-atom values for input to the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command.</p>
<p>There is also a <a class="reference internal" href="dump.html"><span class="doc">dump local</span></a> format where the user specifies
what local values to output. A pre-defined index keyword can be
specified to enumuerate the local values. Two additional kinds of
keywords can also be specified (c_ID, f_ID), where a
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> or <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> or <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>
provides the values to be output. In each case, the compute or fix
must generate local values for input to the <a class="reference internal" href="dump.html"><span class="doc">dump local</span></a>
to a file of chunk-averaged per-atom quantities like those output in
dump files. Chunks can represent spatial bins or other collections of
atoms, e.g. individual molecules. The per-atom quantities can be atom
density (mass or number) or atom attributes such as position,
velocity, force. They can also be per-atom quantities calculated by a
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a>, by a <a class="reference internal" href="fix.html"><span class="doc">fix</span></a>, or by an atom-style
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a>. The chunk-averaged output of this fix can
also be used as input to other output commands.</p>
to a file of histogrammed quantities, which can be global or per-atom
or local quantities. The histogram output of this fix can also be
used as input to other output commands.</p>
<p>The <a class="reference internal" href="fix_ave_correlate.html"><span class="doc">fix ave/correlate</span></a> command enables direct
output to a file of time-correlated quantities, which can be global
values. The correlation matrix output of this fix can also be used as
input to other output commands.</p>
<p>The <a class="reference internal" href="fix_print.html"><span class="doc">fix print</span></a> command can generate a line of output
written to the screen and log file or to a separate file, periodically
during a running simulation. The line can contain one or more
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> values for any style variable except the
vector or atom styles). As explained above, variables themselves can
contain references to global values generated by <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic keywords</span></a>, <a class="reference internal" href="compute.html"><span class="doc">computes</span></a>,
<a class="reference internal" href="fix.html"><span class="doc">fixes</span></a>, or other <a class="reference internal" href="variable.html"><span class="doc">variables</span></a>, or to per-atom
values for a specific atom. Thus the <a class="reference internal" href="fix_print.html"><span class="doc">fix print</span></a>
command is a means to output a wide variety of quantities separate
from normal thermodynamic or dump file output.</p>
<span id="computeoutput"></span><h3>6.15.6. Computes that process output quantities</h3>
<p>The <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a> and <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce/region</span></a> commands take one or more per-atom
or local vector quantities as inputs and “reduce” them (sum, min, max,
ave) to scalar quantities. These are produced as output values which
can be used as input to other output commands.</p>
<p>The <a class="reference internal" href="compute_slice.html"><span class="doc">compute slice</span></a> command take one or more global
vector or array quantities as inputs and extracts a subset of their
values to create a new vector or array. These are produced as output
values which can be used as input to other output commands.</p>
<p>The <a class="reference internal" href="compute_property_atom.html"><span class="doc">compute property/atom</span></a> command takes a
list of one or more pre-defined atom attributes (id, x, fx, etc) and
stores the values in a per-atom vector or array. These are produced
as output values which can be used as input to other output commands.
The list of atom attributes is the same as for the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command.</p>
of per-atom vectors. The per-atom quantities can be atom attributes
such as position, velocity, force. They can also be per-atom
quantities calculated by a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>, by a
<a class="reference internal" href="fix.html"><span class="doc">fix</span></a>, or by an atom-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>. The
time-averaged per-atom output of this fix can be used as input to
other output commands.</p>
<p>The <a class="reference internal" href="fix_store_state.html"><span class="doc">fix store/state</span></a> command can archive one or
more per-atom attributes at a particular time, so that the old values
can be used in a future calculation or output. The list of atom
attributes is the same as for the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command,
including per-atom quantities calculated by a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>,
by a <a class="reference internal" href="fix.html"><span class="doc">fix</span></a>, or by an atom-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>.
The output of this fix can be used as input to other output commands.</p>
<span id="howto-16"></span><h2>6.16. Thermostatting, barostatting, and computing temperature</h2>
<p>Thermostatting means controlling the temperature of particles in an MD
simulation. Barostatting means controlling the pressure. Since the
pressure includes a kinetic component due to particle velocities, both
these operations require calculation of the temperature. Typically a
target temperature (T) and/or pressure (P) is specified by the user,
and the thermostat or barostat attempts to equilibrate the system to
the requested T and/or P.</p>
<p>Temperature is computed as kinetic energy divided by some number of
degrees of freedom (and the Boltzmann constant). Since kinetic energy
is a function of particle velocity, there is often a need to
distinguish between a particle’s advection velocity (due to some
aggregate motiion of particles) and its thermal velocity. The sum of
the two is the particle’s total velocity, but the latter is often what
is wanted to compute a temperature.</p>
<p>LAMMPS has several options for computing temperatures, any of which
can be used in thermostatting and barostatting. These <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> calculate temperature, and the <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> command calculates pressure.</p>
<p><a class="reference internal" href="fix_nh.html"><span class="doc">Fix nvt</span></a> only thermostats the translational velocity of
particles. <a class="reference internal" href="fix_nvt_sllod.html"><span class="doc">Fix nvt/sllod</span></a> 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 <a class="reference internal" href="#howto-13"><span class="std std-ref">NEMD simulations</span></a> section of this page for further details. <a class="reference internal" href="fix_nvt_sphere.html"><span class="doc">Fix nvt/sphere</span></a> and <a class="reference internal" href="fix_nvt_asphere.html"><span class="doc">fix nvt/asphere</span></a> thermostat not only translation
velocities but also rotational velocities for spherical and aspherical
particles.</p>
<p>DPD thermostatting alters pairwise interactions in a manner analagous
to the per-particle thermostatting of <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a>.</p>
<p>Any of the thermostatting fixes can use temperature computes that
remove bias which has two effects. First, the current calculated
temperature, which is compared to the requested target temperature, is
caluclated with the velocity bias removed. Second, the thermostat
adjusts only the thermal temperature component of the particle’s
velocities, which are the velocities with the bias removed. The
removed bias is then added back to the adjusted velocities. See the
doc pages for the individual fixes and for the
<a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command for instructions on how to assign
a temperature compute to a thermostatting fix. For example, you can
apply a thermostat to only the x and z components of velocity by using
it in conjunction with <a class="reference internal" href="compute_temp_partial.html"><span class="doc">compute temp/partial</span></a>. Of you could thermostat only
the thermal temperature of a streaming flow of particles without
affecting the streaming velocity, by using <a class="reference internal" href="compute_temp_profile.html"><span class="doc">compute temp/profile</span></a>.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Only the nvt fixes perform time integration, meaning they update
the velocities and positions of particles due to forces and velocities
respectively. The other thermostat fixes only adjust velocities; they
do NOT perform time integration updates. Thus they should be used in
conjunction with a constant NVE integration fix such as these:</p>
<p>The <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> commands include a Nose-Hoover thermostat
and barostat. <a class="reference internal" href="fix_nh.html"><span class="doc">Fix nph</span></a> is just a Nose/Hoover barostat;
it does no thermostatting. Both <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> and <a class="reference internal" href="fix_press_berendsen.html"><span class="doc">fix press/bernendsen</span></a> can be used in conjunction
with any of the thermostatting fixes.</p>
<p>As with the thermostats, <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> and <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> only use translational motion of the particles in
computing T and P and performing thermo/barostatting. <a class="reference internal" href="fix_npt_sphere.html"><span class="doc">Fix npt/sphere</span></a> and <a class="reference internal" href="fix_npt_asphere.html"><span class="doc">fix npt/asphere</span></a> thermo/barostat using not only
translation velocities but also rotational velocities for spherical
and aspherical particles.</p>
<p>All of the barostatting fixes use the <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> compute to calculate a current
pressure. By default, this compute is created with a simple <a class="reference internal" href="compute_temp.html"><span class="doc">compute temp</span></a> (see the last argument of the <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> command), which is used to calculated
the kinetic component of the pressure. The barostatting fixes can
also use temperature computes that remove bias for the purpose of
computing the kinetic component which contributes to the current
pressure. See the doc pages for the individual fixes and for the
<a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command for instructions on how to assign
a temperature or pressure compute to a barostatting fix.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">As with the thermostats, the Nose/Hoover methods (<a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> and <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a>) perform time integration.
<a class="reference internal" href="fix_press_berendsen.html"><span class="doc">Fix press/berendsen</span></a> does NOT, so it should
be used with one of the constant NVE fixes or with one of the NVT
fixes.</p>
</div>
<p>Finally, thermodynamic output, which can be setup via the
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command, often includes temperature
and pressure values. As explained on the doc page for the
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command, the default T and P are
setup by the thermo command itself. They are NOT the ones associated
with any thermostatting or barostatting fix you have defined or with
any compute that calculates a temperature or pressure. Thus if you
want to view these values of T and P, you need to specify them
explicitly via a <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command. Or
you can use the <a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify</span></a> command to
re-define what temperature or pressure compute is used for default
thermodynamic output.</p>
<hr class="docutils" />
</div>
<div class="section" id="walls">
<span id="howto-17"></span><h2>6.17. Walls</h2>
<p>Walls in an MD simulation are typically used to bound particle motion,
i.e. to serve as a boundary condition.</p>
<p>Walls in LAMMPS can be of rough (made of particles) or idealized
surfaces. Ideal walls can be smooth, generating forces only in the
normal direction, or frictional, generating forces also in the
tangential direction.</p>
<p>Rough walls, built of particles, can be created in various ways. The
particles themselves can be generated like any other particle, via the
or read in via the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command.</p>
<p>Their motion can be constrained by many different commands, so that
they do not move at all, move together as a group at constant velocity
or in response to a net force acting on them, move in a prescribed
fashion (e.g. rotate around a point), etc. Note that if a time
integration fix like <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> or <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>
is not used with the group that contains wall particles, their
positions and velocities will not be updated.</p>
<ul class="simple">
<li><a class="reference internal" href="fix_aveforce.html"><span class="doc">fix aveforce</span></a> - set force on particles to average value, so they move together</li>
<li><a class="reference internal" href="fix_setforce.html"><span class="doc">fix setforce</span></a> - set force on particles to a value, e.g. 0.0</li>
<li><a class="reference internal" href="fix_freeze.html"><span class="doc">fix freeze</span></a> - freeze particles for use as granular walls</li>
<li><a class="reference internal" href="fix_nve_noforce.html"><span class="doc">fix nve/noforce</span></a> - advect particles by their velocity, but without force</li>
<li><a class="reference internal" href="fix_move.html"><span class="doc">fix move</span></a> - prescribe motion of particles by a linear velocity, oscillation, rotation, variable</li>
</ul>
<p>The <a class="reference internal" href="fix_move.html"><span class="doc">fix move</span></a> command offers the most generality, since
the motion of individual particles can be specified with
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> formula which depends on time and/or the
particle position.</p>
<p>For rough walls, it may be useful to turn off pairwise interactions
between wall particles via the <a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify exclude</span></a> command.</p>
<p>Rough walls can also be created by specifying frozen particles that do
not move and do not interact with mobile particles, and then tethering
other particles to the fixed particles, via a <a class="reference internal" href="bond_style.html"><span class="doc">bond</span></a>.
The bonded particles do interact with other mobile particles.</p>
<p>Idealized walls can be specified via several fix commands. <a class="reference internal" href="fix_wall_gran.html"><span class="doc">Fix wall/gran</span></a> creates frictional walls for use with
granular particles; all the other commands create smooth walls.</p>
<p>The lammps_open() function is used to initialize LAMMPS, passing in a
list of strings as if they were <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line arguments</span></a> when LAMMPS is run in
stand-alone mode from the command line, and a MPI communicator for
LAMMPS to run under. It returns a ptr to the LAMMPS object that is
created, and which is used in subsequent library calls. The
lammps_open() function can be called multiple times, to create
multiple instances of LAMMPS.</p>
<p>LAMMPS will run on the set of processors in the communicator. This
means the calling code can run LAMMPS on all or a subset of
processors. For example, a wrapper script might decide to alternate
between LAMMPS and another code, allowing them both to run on all the
processors. Or it might allocate half the processors to LAMMPS and
half to the other code and run both codes simultaneously before
syncing them up periodically. Or it might instantiate multiple
instances of LAMMPS to perform different calculations.</p>
<p>The lammps_close() function is used to shut down an instance of LAMMPS
and free all its memory.</p>
<p>The lammps_version() function can be used to determined the specific
version of the underlying LAMMPS code. This is particularly useful
when loading LAMMPS as a shared library via dlopen(). The code using
the library interface can than use this information to adapt to
changes to the LAMMPS command syntax between versions. The returned
LAMMPS version code is an integer (e.g. 2 Sep 2015 results in
20150902) that grows with every new LAMMPS version.</p>
<p>The lammps_file() and lammps_command() functions are used to pass a
file or string to LAMMPS as if it were an input script or single
command in an input script. Thus the calling code can read or
generate a series of LAMMPS commands one line at a time and pass it
thru the library interface to setup a problem and then run it,
interleaving the lammps_command() calls with other calls to extract
information from LAMMPS, perform its own operations, or call another
code’s library.</p>
<p>Other useful functions are also included in library.cpp. For example:</p>
<p>These can extract various global or per-atom quantities from LAMMPS as
well as values calculated by a compute, fix, or variable. The
“set_variable” function can set an existing string-style variable to a
new value, so that subsequent LAMMPS commands can access the variable.
The “get” and “put” operations can retrieve and reset atom
coordinates. See the library.cpp file and its associated header file
library.h for details.</p>
<p>The key idea of the library interface is that you can write any
functions you wish to define how your code talks to LAMMPS and add
them to src/library.cpp and src/library.h, as well as to the <a class="reference internal" href="Section_python.html"><span class="doc">Python interface</span></a>. The routines you add can access or
change any LAMMPS data you wish. The examples/COUPLE and python
directories have example C++ and C and Python codes which show how a
driver code can link to LAMMPS as a library, run LAMMPS on a subset of
processors, grab data from LAMMPS, change it, and put it back into
<p>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 <a class="reference internal" href="#howto-21"><span class="std std-ref">this section</span></a> of the manual for an analogous
discussion for viscosity.</p>
<p>The thermal conducitivity tensor kappa is a measure of the propensity
of a material to transmit heat energy in a diffusive manner as given
by Fourier’s law</p>
<p>J = -kappa grad(T)</p>
<p>where J is the heat flux in units of energy per area per time and
grad(T) is the spatial gradient of temperature. The thermal
conductivity thus has units of energy per distance per time per degree
K and is often approximated as an isotropic quantity, i.e. as a
scalar.</p>
<p>The first method is to setup two thermostatted regions at opposite
ends of a simulation box, or one in the middle and one at the end of a
periodic box. By holding the two regions at different temperatures
with a <a class="reference internal" href="#howto-13"><span class="std std-ref">thermostatting fix</span></a>, the energy
added to the hot region should equal the energy subtracted from the
cold region and be proportional to the heat flux moving between the
regions. See the papers by <a class="reference internal" href="#howto-ikeshoji"><span class="std std-ref">Ikeshoji and Hafskjold</span></a>
and <a class="reference internal" href="#howto-wirnsberger"><span class="std std-ref">Wirnsberger et al</span></a> for details of this idea.
Note that thermostatting fixes such as <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>, <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a>, and <a class="reference internal" href="fix_temp_rescale.html"><span class="doc">fix temp/rescale</span></a> store the cumulative energy they
add/subtract.</p>
<p>Alternatively, as a second method, the <a class="reference internal" href="fix_heat.html"><span class="doc">fix heat</span></a> or
<a class="reference internal" href="fix_ehex.html"><span class="doc">fix ehex</span></a> commands can be used in place of thermostats
on each of two regions to add/subtract specified amounts of energy to
both regions. In both cases, the resulting temperatures of the two
regions can be monitored with the “compute temp/region” command and
the temperature profile of the intermediate region can be monitored
with the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> and <a class="reference internal" href="compute_ke_atom.html"><span class="doc">compute ke/atom</span></a> commands.</p>
<p>The third method is to perform a reverse non-equilibrium MD simulation
using the <a class="reference internal" href="fix_thermal_conductivity.html"><span class="doc">fix thermal/conductivity</span></a>
command which implements the rNEMD algorithm of Muller-Plathe.
Kinetic energy is swapped between atoms in two different layers of the
simulation box. This induces a temperature gradient between the two
layers which can be monitored with the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> and <a class="reference internal" href="compute_ke_atom.html"><span class="doc">compute ke/atom</span></a> commands. The fix tallies the
cumulative energy transfer that it performs. See the <a class="reference internal" href="fix_thermal_conductivity.html"><span class="doc">fix thermal/conductivity</span></a> command for
details.</p>
<p>The fourth method is based on the Green-Kubo (GK) formula which
relates the ensemble average of the auto-correlation of the heat flux
to kappa. The heat flux can be calculated from the fluctuations of
per-atom potential and kinetic energies and per-atom stress tensor in
a steady-state equilibrated simulation. This is in contrast to the
two preceding non-equilibrium methods, where energy flows continuously
between hot and cold regions of the simulation box.</p>
<p>The <a class="reference internal" href="compute_heat_flux.html"><span class="doc">compute heat/flux</span></a> command can calculate
the needed heat flux and describes how to implement the Green_Kubo
formalism using additional LAMMPS commands, such as the <a class="reference internal" href="fix_ave_correlate.html"><span class="doc">fix ave/correlate</span></a> command to calculate the needed
auto-correlation. See the doc page for the <a class="reference internal" href="compute_heat_flux.html"><span class="doc">compute heat/flux</span></a> command for an example input script
that calculates the thermal conductivity of solid Ar via the GK
<p>The shear viscosity eta of a fluid can be measured in at least 5 ways
using various options in LAMMPS. See the examples/VISCOSITY directory
for scripts that implement the 5 methods discussed here for a simple
Lennard-Jones fluid model. Also, see <a class="reference internal" href="#howto-20"><span class="std std-ref">this section</span></a> of the manual for an analogous
discussion for thermal conductivity.</p>
<p>Eta is a measure of the propensity of a fluid to transmit momentum in
a direction perpendicular to the direction of velocity or momentum
flow. Alternatively it is the resistance the fluid has to being
sheared. It is given by</p>
<p>J = -eta grad(Vstream)</p>
<p>where J is the momentum flux in units of momentum per area per time.
and grad(Vstream) is the spatial gradient of the velocity of the fluid
moving in another direction, normal to the area through which the
momentum flows. Viscosity thus has units of pressure-time.</p>
<p>The first method is to perform a non-equlibrium MD (NEMD) simulation
by shearing the simulation box via the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a>
command, and using the <a class="reference internal" href="fix_nvt_sllod.html"><span class="doc">fix nvt/sllod</span></a> command to
thermostat the fluid via the SLLOD equations of motion.
Alternatively, as a second method, one or more moving walls can be
used to shear the fluid in between them, again with some kind of
thermostat that modifies only the thermal (non-shearing) components of
velocity to prevent the fluid from heating up.</p>
<p>In both cases, the velocity profile setup in the fluid by this
procedure can be monitored by the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> 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 <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a>
command, can also be monitored, which is the J term in the equation
above. See <a class="reference internal" href="#howto-13"><span class="std std-ref">this section</span></a> of the manual
for details on NEMD simulations.</p>
<p>The third method is to perform a reverse non-equilibrium MD simulation
using the <a class="reference internal" href="fix_viscosity.html"><span class="doc">fix viscosity</span></a> command which implements
the rNEMD algorithm of Muller-Plathe. Momentum in one dimension is
swapped between atoms in two different layers of the simulation box in
a different dimension. This induces a velocity gradient which can be
monitored with the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> command.
The fix tallies the cummulative momentum transfer that it performs.
See the <a class="reference internal" href="fix_viscosity.html"><span class="doc">fix viscosity</span></a> command for details.</p>
<p>The fourth method is based on the Green-Kubo (GK) formula which
relates the ensemble average of the auto-correlation of the
stress/pressure tensor to eta. This can be done in a fully
equilibrated simulation which is in contrast to the two preceding
non-equilibrium methods, where momentum flows continuously through the
simulation box.</p>
<p>Here is an example input script that calculates the viscosity of
liquid Ar via the GK formalism:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># Sample LAMMPS input script for viscosity of liquid Ar</span>
</pre></div>
</div>
-<div class="highlight-default"><div class="highlight"><pre><span></span>units real
+<pre class="literal-block">
+units real
variable T equal 86.4956
variable V equal vol
variable dt equal 4.0
variable p equal 400 # correlation length
variable s equal 5 # sample interval
variable d equal $p*$s # dump interval
-</pre></div>
-</div>
+</pre>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># convert from LAMMPS real units to SI</span>
<a class="reference internal" href="variable.html"><span class="doc">variables</span></a> to be used to define chunk IDs for each
atom. This means you can write your own compute or fix to output a
per-atom quantity to use as chunk ID. See
<a class="reference internal" href="Section_modify.html"><span class="doc">Section_modify</span></a> of the documentation for how to
do this. You can also define a <a class="reference internal" href="variable.html"><span class="doc">per-atom variable</span></a> in
the input script that uses a formula to generate a chunk ID for each
atom.</p>
</div>
<div class="section" id="fix-ave-chunk-command">
<h3>6.23.2. Fix ave/chunk command:</h3>
<p>This fix takes the ID of a <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command as input. For each chunk,
it then sums one or more specified per-atom values over the atoms in
each chunk. The per-atom values can be any atom property, such as
etc. Additional keywords are defined for per-chunk properties like
density and temperature. More generally any per-atom value generated
by other <a class="reference internal" href="compute.html"><span class="doc">computes</span></a>, <a class="reference internal" href="fix.html"><span class="doc">fixes</span></a>, and <a class="reference internal" href="variable.html"><span class="doc">per-atom variables</span></a>, can be summed over atoms in each chunk.</p>
<p>Similar to other averaging fixes, this fix allows the summed per-chunk
values to be time-averaged in various ways, and output to a file. The
fix produces a global array as output with one row of values per
<p>They each take the ID of a <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command as input. As their names
indicate, they calculate the center-of-mass, radius of gyration,
moments of inertia, mean-squared displacement, temperature, torque,
and velocity of center-of-mass for each chunk of atoms. The <a class="reference internal" href="compute_property_chunk.html"><span class="doc">compute property/chunk</span></a> command can tally the
count of atoms in each chunk and extract other per-chunk properties.</p>
<p>The reason these various calculations are not part of the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk command</span></a>, is that each requires a more
complicated operation than simply summing and averaging over per-atom
values in each chunk. For example, many of them require calculation
of a center of mass, which requires summing mass*position over the
atoms and then dividing by summed mass.</p>
<p>All of these computes produce a global vector or global array as
output, wih one or more values per chunk. They can be used
in various ways:</p>
<ul class="simple">
<li>As input to the <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a> command, which can
write the values to a file and optionally time average them.</li>
<li>As input to the <a class="reference internal" href="fix_ave_histo.html"><span class="doc">fix ave/histo</span></a> command to
histogram values across chunks. E.g. a histogram of cluster sizes or
molecule diffusion rates.</li>
<li>As input to special functions of <a class="reference internal" href="variable.html"><span class="doc">equal-style variables</span></a>, like sum() and max(). E.g. to find the
largest cluster or fastest diffusing molecule.</li>
<p>The adiabatic core-shell model by <a class="reference internal" href="pair_cs.html#mitchellfinchham"><span class="std std-ref">Mitchell and Finchham</span></a> is a simple method for adding
polarizability 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.</p>
<p>Technically, shells are attached to the cores by a spring force f =
k*r where k is a parametrized spring constant and r is the distance
between the core and the shell. The charges of the core and the shell
add up to the ion charge, thus q(ion) = q(core) + q(shell). This
setup introduces the ion polarizability (alpha) given by
alpha = q(shell)^2 / k. In a
similar fashion the mass of the ion is distributed on the core and the
shell with the core having the larger mass.</p>
<p>To run this model in LAMMPS, <a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a> <em>full</em> can
be used since atom charge and bonds are needed. Each kind of
core/shell pair requires two atom types and a bond type. The core and
shell of a core/shell pair should be bonded to each other with a
harmonic bond that provides the spring force. For example, a data file
for NaCl, as found in examples/coreshell, has this format:</p>
<span class="mi">216</span> <span class="n">bonds</span> <span class="c1"># number of core/shell springs</span>
</pre></div>
</div>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="mi">4</span> <span class="n">atom</span> <span class="n">types</span> <span class="c1"># 2 cores and 2 shells for Na and Cl</span>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">Bonds</span> <span class="c1"># Bond topology for spring forces</span>
</pre></div>
</div>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="mi">1</span> <span class="mi">2</span> <span class="mi">1</span> <span class="mi">2</span> <span class="c1"># spring for core/shell pair 1</span>
<span class="mi">2</span> <span class="mi">2</span> <span class="mi">3</span> <span class="mi">4</span> <span class="c1"># spring for core/shell pair 2</span>
<p>Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only
defined between the shells. Coulombic interactions are defined
between all cores and shells. If desired, additional bonds can be
specified between cores.</p>
<p>The <a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command should be used to
turn-off the Coulombic interaction within core/shell pairs, since that
interaction is set by the bond spring. This is done using the
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command with a 1-2 weight = 0.0,
which is the default value. It needs to be considered whether one has
to adjust the <a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> weighting according
to the molecular topology since the interactions of the shells are
bypassed over an extra bond.</p>
<p>Note that this core/shell implementation does not require all ions to
be polarized. One can mix core/shell pairs and ions without a
satellite particle if desired.</p>
<p>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 <a class="reference internal" href="pair_cs.html"><span class="doc">this doc page</span></a> for details. All of the core/shell enabled pair
styles require the use of a long-range Coulombic solver, as specified
by the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command. Either the PPPM or
Ewald solvers can be used.</p>
<p>For the NaCL example problem, these pair style and bond style settings
<p>When running dynamics with the adiabatic core/shell model, the
following issues should be considered. Since the relative motion of
the core and shell particles corresponds to the polarization, typical
thermostats can alter the polarization behaviour, meaning the shell
will not react freely to its electrostatic environment. This is
critical during the equilibration of the system. Therefore
it’s typically desirable to decouple the relative motion of the
core/shell pair, which is an imaginary degree of freedom, from the
real physical system. To do that, the <a class="reference internal" href="compute_temp_cs.html"><span class="doc">compute temp/cs</span></a> command can be used, in conjunction with
any of the thermostat fixes, such as <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> or <a class="reference external" href="fix_langevin">fix langevin</a>. This compute uses the center-of-mass velocity
of the core/shell pairs to calculate a temperature, and insures that
velocity is what is rescaled for thermostatting purposes. This
compute also works for a system with both core/shell pairs and
non-polarized ions (ions without an attached satellite particle). The
<a class="reference internal" href="compute_temp_cs.html"><span class="doc">compute temp/cs</span></a> command requires input of two
groups, one for the core atoms, another for the shell atoms.
Non-polarized ions which might also be included in the treated system
should not be included into either of these groups, they are taken
into account by the <em>group-ID</em> (2nd argument) of the compute. The
groups can be defined using the <a class="reference internal" href="group.html"><span class="doc">group *type*</span></a> command.
Note that to perform thermostatting using this definition of
temperature, the <a class="reference internal" href="fix_modify.html"><span class="doc">fix modify temp</span></a> command should be
used to assign the compute to the thermostat fix. Likewise the
<a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify temp</span></a> command can be used to make
this temperature be output for the overall system.</p>
<p>For the NaCl example, this can be done as follows:</p>
+fix thermoberendsen all temp/berendsen 1427 1427 0.4 # thermostat for the true physical system
+fix thermostatequ all nve # integrator as needed for the berendsen thermostat
+fix_modify thermoberendsen temp CSequ
+thermo_modify temp CSequ # output of center-of-mass derived temperature
+</pre>
<p>If <a class="reference internal" href="compute_temp_cs.html"><span class="doc">compute temp/cs</span></a> is used, the decoupled
relative motion of the core and the shell should in theory be
stable. However numerical fluctuation can introduce a small
momentum to the system, which is noticable over long trajectories.
Therefore it is recomendable to use the <a class="reference internal" href="fix_momentum.html"><span class="doc">fix momentum</span></a> command in combination with <a class="reference internal" href="compute_temp_cs.html"><span class="doc">compute temp/cs</span></a> when equilibrating the system to
prevent any drift.</p>
<p>When intializing the velocities of a system with core/shell pairs, it
is also desirable to not introduce energy into the relative motion of
the core/shell particles, but only assign a center-of-mass velocity to
the pairs. This can be done by using the <em>bias</em> keyword of the
<a class="reference internal" href="velocity.html"><span class="doc">velocity create</span></a> command and assigning the <a class="reference internal" href="compute_temp_cs.html"><span class="doc">compute temp/cs</span></a> command to the <em>temp</em> keyword of the
<p>It is important to note that the polarizability of the core/shell
pairs is based on their relative motion. Therefore the choice of
spring force and mass ratio need to ensure much faster relative motion
of the 2 atoms within the core/shell pair than their center-of-mass
velocity. This allow the shells to effectively react instantaneously
to the electrostatic environment. This fast movement also limits the
timestep size that can be used.</p>
<p>The primary literature of the adiabatic core/shell model suggests that
the fast relative motion of the core/shell pairs only allows negligible
energy transfer to the environment. Therefore it is not intended to
decouple the core/shell degree of freedom from the physical system
during production runs. In other words, the <a class="reference internal" href="compute_temp_cs.html"><span class="doc">compute temp/cs</span></a> command should not be used during
production runs and is only required during equilibration. This way one
is consistent with literature (based on the code packages DL_POLY or
GULP for instance).</p>
<p>The mentioned energy transfer will typically lead to a a small drift
in total energy over time. This internal energy can be monitored
using the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> and <a class="reference internal" href="compute_temp_chunk.html"><span class="doc">compute temp/chunk</span></a> commands. The internal kinetic
energies of each core/shell pair can then be summed using the sum()
special function of the <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command. Or they can
be time/averaged and output using the <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a>
command. To use these commands, each core/shell pair must be defined
as a “chunk”. If each core/shell pair is defined as its own molecule,
the molecule ID can be used to define the chunks. If cores are bonded
to each other to form larger molecules, the chunks can be identified
by the <a class="reference internal" href="fix_property_atom.html"><span class="doc">fix property/atom</span></a> via assigning a
core/shell ID to each atom using a special field in the data file read
by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command. This field can then be
accessed by the <a class="reference internal" href="compute_property_atom.html"><span class="doc">compute property/atom</span></a>
command, to use as input to the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command to define the core/shell
<p>The thermalized Drude model, similarly to the <a class="reference internal" href="#howto-26"><span class="std std-ref">core-shell</span></a>
model, representes induced dipoles by a pair of charges (the core atom
and the Drude particle) connected by a harmonic spring. The Drude
model has a number of features aimed at its use in molecular systems
(<a class="reference internal" href="#howto-lamoureux"><span class="std std-ref">Lamoureux and Roux</span></a>):</p>
<ul class="simple">
<li>Thermostating of the additional degrees of freedom associated with the
induced dipoles at very low temperature, in terms of the reduced
coordinates of the Drude particles with respect to their cores. This
makes the trajectory close to that of relaxed induced dipoles.</li>
<li>Consistent definition of 1-2 to 1-4 neighbors. A core-Drude particle
pair represents a single (polarizable) atom, so the special screening
factors in a covalent structure should be the same for the core and
the Drude particle. Drude particles have to inherit the 1-2, 1-3, 1-4
special neighbor relations from their respective cores.</li>
<li>Stabilization of the interactions between induced dipoles. Drude
dipoles on covalently bonded atoms interact too strongly due to the
short distances, so an atom may capture the Drude particle of a
neighbor, or the induced dipoles within the same molecule may align
too much. To avoid this, damping at short range can be done by Thole
functions (for which there are physical grounds). This Thole damping
is applied to the point charges composing the induced dipole (the
charge of the Drude particle and the opposite charge on the core, not
to the total charge of the core atom).</li>
</ul>
<p>A detailed tutorial covering the usage of Drude induced dipoles in
LAMMPS is <a class="reference internal" href="tutorial_drude.html"><span class="doc">available here</span></a>.</p>
<p>As with the core-shell model, the cores and Drude particles should
appear in the data file as standard atoms. The same holds for the
springs between them, which are described by standard harmonic bonds.
The nature of the atoms (core, Drude particle or non-polarizable) is
specified via the <a class="reference internal" href="fix_drude.html"><span class="doc">fix drude</span></a> command. The special
list of neighbors is automatically refactored to account for the
equivalence of core and Drude particles as regards special 1-2 to 1-4
screening. It may be necessary to use the <em>extra</em> keyword of the
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command. If using <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a>, make sure no Drude particle is in this fix
group.</p>
<p>There are two ways to thermostat the Drude particles at a low
temperature: use either <a class="reference internal" href="fix_langevin_drude.html"><span class="doc">fix langevin/drude</span></a>
for a Langevin thermostat, or <a class="reference internal" href="fix_drude_transform.html"><span class="doc">fix drude/transform/*</span></a> for a Nose-Hoover
thermostat. The former requires use of the command <a class="reference internal" href="comm_modify.html"><span class="doc">comm_modify vel yes</span></a>. The latter requires two separate integration
fixes like <em>nvt</em> or <em>npt</em>. The correct temperatures of the reduced
degrees of freedom can be calculated using the <a class="reference internal" href="compute_temp_drude.html"><span class="doc">compute temp/drude</span></a>. This requires also to use the
command <em>comm_modify vel yes</em>.</p>
<p>Short-range damping of the induced dipole interactions can be achieved
using Thole functions through the the <a class="reference internal" href="pair_thole.html"><span class="doc">pair style thole</span></a> in <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid/overlay</span></a>
with a Coulomb pair style. It may be useful to use <em>coul/long/cs</em> or
similar from the CORESHELL package if the core and Drude particle come
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li class="toctree-l2"><a class="reference internal" href="#submitting-new-features-for-inclusion-in-lammps">10.15. Submitting new features for inclusion in LAMMPS</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
<div class="line">10.6 <a class="reference internal" href="#mod-6"><span class="std std-ref">Fix styles</span></a> which include integrators, temperature and pressure control, force constraints, boundary conditions, diagnostic output, etc</div>
<div class="line">10.15 <a class="reference internal" href="#mod-15"><span class="std std-ref">Submitting new features for inclusion in LAMMPS</span></a></div>
<div class="line"><br /></div>
</div>
<p>LAMMPS is designed in a modular fashion so as to be easy to modify and
extend with new functionality. In fact, about 75% of its source code
is files added in this fashion.</p>
<p>In this section, changes and additions users can make are listed along
with minimal instructions. If you add a new feature to LAMMPS and
think it will be of interest to general users, we encourage you to
submit it to the developers for inclusion in the released version of
LAMMPS. Information about how to do this is provided
<td>retreive extra info unique to this atom style (optional)</td>
</tr>
<tr class="row-odd"><td>pack_exchange</td>
<td>store all an atom’s info to migrate to another processor (required)</td>
</tr>
<tr class="row-even"><td>unpack_exchange</td>
<td>retrieve an atom’s info from the buffer (required)</td>
</tr>
<tr class="row-odd"><td>size_restart</td>
<td>number of restart quantities associated with proc’s atoms (required)</td>
</tr>
<tr class="row-even"><td>pack_restart</td>
<td>pack atom quantities into a buffer (required)</td>
</tr>
<tr class="row-odd"><td>unpack_restart</td>
<td>unpack atom quantities from a buffer (required)</td>
</tr>
<tr class="row-even"><td>create_atom</td>
<td>create an individual atom of this style (required)</td>
</tr>
<tr class="row-odd"><td>data_atom</td>
<td>parse an atom line from the data file (required)</td>
</tr>
<tr class="row-even"><td>data_atom_hybrid</td>
<td>parse additional atom info unique to this atom style (optional)</td>
</tr>
<tr class="row-odd"><td>data_vel</td>
<td>parse one line of velocity information from data file (optional)</td>
</tr>
<tr class="row-even"><td>data_vel_hybrid</td>
<td>parse additional velocity data unique to this atom style (optional)</td>
</tr>
<tr class="row-odd"><td>memory_usage</td>
<td>tally memory allocated by atom arrays (required)</td>
</tr>
</tbody>
</table>
<p>The constructor of the derived class sets values for several variables
that you must set when defining a new atom style, which are documented
in atom_vec.h. New atom arrays are defined in atom.cpp. Search for
the word “customize” and you will find locations you will need to
modify.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">It is possible to add some attributes, such as a molecule ID, to
atom styles that do not have them via the <a class="reference internal" href="fix_property_atom.html"><span class="doc">fix property/atom</span></a> command. This command also
allows new custom attributes consisting of extra integer or
floating-point values to be added to atoms. See the <a class="reference internal" href="fix_property_atom.html"><span class="doc">fix property/atom</span></a> doc page for examples of cases
where this is useful and details on how to initialize, access, and
+int index = atom->find_custom(char *name, int &flag);
+</pre>
<p>The “name” of a custom attribute, as specified in the <a class="reference internal" href="fix_property_atom.html"><span class="doc">fix property/atom</span></a> command, is checked to verify
that it exists and its index is returned. The method also sets flag =
0/1 depending on whether it is an integer or floating-point attribute.
The vector of values associated with the attribute can then be
<p>There is one class that computes and prints thermodynamic information
to the screen and log file; see the file thermo.cpp.</p>
<p>There are two styles defined in thermo.cpp: “one” and “multi”. There
is also a flexible “custom” style which allows the user to explicitly
list keywords for quantities to print when thermodynamic info is
output. See the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command for a list
of defined quantities.</p>
<p>The thermo styles (one, multi, etc) are simply lists of keywords.
Adding a new style thus only requires defining a new list of keywords.
Search for the word “customize” with references to “thermo style” in
thermo.cpp to see the two locations where code will need to be added.</p>
<p>New keywords can also be added to thermo.cpp to compute new quantities
for output. Search for the word “customize” with references to
“keyword” in thermo.cpp to see the several locations where code will
need to be added.</p>
<p>Note that the <a class="reference internal" href="thermo.html"><span class="doc">thermo_style custom</span></a> command already allows
for thermo output of quantities calculated by <a class="reference internal" href="fix.html"><span class="doc">fixes</span></a>,
<a class="reference internal" href="compute.html"><span class="doc">computes</span></a>, and <a class="reference internal" href="variable.html"><span class="doc">variables</span></a>. Thus, it may
be simpler to compute what you wish via one of those constructs, than
by adding a new keyword to the thermo command.</p>
<p>There is one class that computes and stores <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>
information in LAMMPS; see the file variable.cpp. The value
associated with a variable can be periodically printed to the screen
via the <a class="reference internal" href="print.html"><span class="doc">print</span></a>, <a class="reference internal" href="fix_print.html"><span class="doc">fix print</span></a>, or
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> commands. Variables of style
“equal” can compute complex equations that involve the following types
<span id="mod-15"></span><h2>10.15. Submitting new features for inclusion in LAMMPS</h2>
<p>We encourage users to submit new features or modifications for
LAMMPS to <a class="reference external" href="http://lammps.sandia.gov/authors.html">the core developers</a>
so they can be added to the LAMMPS distribution. The preferred way to
manage and coordinate this is as of Fall 2016 via the LAMMPS project on
<a class="reference external" href="https://github.com/lammps/lammps">GitHub</a>. An alternative is to contact
the LAMMPS developers or the indicated developer of a package or feature
directly and send in your contribution via e-mail.</p>
<p>For any larger modifications or programming project, you are encouraged
to contact the LAMMPS developers ahead of time, in order to discuss
implementation strategies and coding guidelines, that will make it
easier to integrate your contribution and result in less work for
everybody involved. You are also encouraged to search through the list
of <a class="reference external" href="https://github.com/lammps/lammps/issues">open issues on GitHub</a> and
submit a new issue for a planned feature, so you would not duplicate
the work of others (and possibly get scooped by them) or have your work
duplicated by others.</p>
<p>How quickly your contribution will be integrated
depends largely on how much effort it will cause to integrate and test
it, how much it requires changes to the core codebase, and of how much
interest it is to the larger LAMMPS community. Please see below for a
checklist of typical requirements. Once you have prepared everything,
see <a class="reference internal" href="tutorial_github.html"><span class="doc">this tutorial</span></a> for instructions on how to
submit your changes or new files through a GitHub pull request. If you
prefer to submit patches or full files, you should first make certain,
that your code works correctly with the latest patch-level version of
LAMMPS and contains all bugfixes from it. Then create a gzipped tar
file of all changed or added files or a corresponding patch file using
‘diff -u’ or ‘diff -c’ and compress it with gzip. Please only use
gzip compression, as this works well on all platforms.</p>
<p>If the new features/files are broadly useful we may add them as core
files to LAMMPS or as part of a <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">standard package</span></a>. Else we will add them as a
user-contributed file or package. Examples of user packages are in
src sub-directories that start with USER. The USER-MISC package is
simply a collection of (mostly) unrelated single files, which is the
simplest way to have your contribution quickly added to the LAMMPS
distribution. You can see a list of the both standard and user
packages by typing “make package” in the LAMMPS src directory.</p>
<p>Note that by providing us files to release, you are agreeing to make
them open-source, i.e. we can release them under the terms of the GPL,
used as a license for the rest of LAMMPS. See <a class="reference internal" href="Section_intro.html#intro-4"><span class="std std-ref">Section 1.4</span></a> for details.</p>
<p>With user packages and files, all we are really providing (aside from
the fame and fortune that accompanies having your name in the source
code and on the <a class="reference external" href="http://lammps.sandia.gov/authors.html">Authors page</a>
of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW site</a>), is a means for you to distribute your
work to the LAMMPS user community, and a mechanism for others to
easily try out your new feature. This may help you find bugs or make
contact with new collaborators. Note that you’re also implicitly
agreeing to support your code which means answer questions, fix bugs,
and maintain it if LAMMPS changes in some way that breaks it (an
unusual event).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you prefer to actively develop and support your add-on
feature yourself, then you may wish to make it available for download
from your own website, as a user package that LAMMPS users can add to
their copy of LAMMPS. See the <a class="reference external" href="http://lammps.sandia.gov/offsite.html">Offsite LAMMPS packages and tools</a> page of the LAMMPS web
site for examples of groups that do this. We are happy to advertise
your package and web site from that page. Simply email the
<a class="reference external" href="http://lammps.sandia.gov/authors.html">developers</a> with info about
your package and we will post it there.</p>
</div>
<p>The previous sections of this doc 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
do not require changes to the main core of LAMMPS; they are simply
add-on files. If you think your new feature requires non-trivial
changes in core LAMMPS files, you’ll need to <a class="reference external" href="http://lammps.sandia.gov/authors.html">communicate with the developers</a>, since we may or may
not want to make those changes. An example of a trivial change is
making a parent-class method “virtual” when you derive a new child
class from it.</p>
<p>Here is a checklist of steps you need to follow to submit a single file
or user package for our consideration. Following these steps will save
both you and us time. See existing files in packages in the src dir for
examples. If you are uncertain, please ask.</p>
<ul class="simple">
<li>All source files you provide must compile with the most current
version of LAMMPS with multiple configurations. In particular you
need to test compiling LAMMPS from scratch with -DLAMMPS_BIGBIG
set in addition to the default -DLAMMPS_SMALLBIG setting. Your code
will need to work correctly in serial and in parallel using MPI.</li>
<li>For consistency with the rest of LAMMPS and especially, if you want
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, <strong>no tabs</strong>, no lines over 80 characters. I/O is done via
the C-style stdio library, class header files should not import any
system headers outside <stdio.h>, STL containers should be avoided
in headers, and forward declarations used where possible or needed.
All added code should be placed into the LAMMPS_NS namespace or a
sub-namespace; global or static variables should be avoided, as they
conflict with the modular nature of LAMMPS and the C++ class structure.
Header files must <strong>not</strong> import namespaces with <em>using</em>.
This all is so the developers can more easily understand, integrate,
and maintain your contribution and reduce conflicts with other parts
of LAMMPS. This basically means that the code accesses data
structures, performs its operations, and is formatted similar to other
LAMMPS source files, including the use of the error class for error
and warning messages.</li>
<li>If you want your contribution to be added as a user-contributed
-feature, and it’s a single file (actually a <a href="#id8"><span class="problematic" id="id9">*</span></a>.cpp and <a href="#id10"><span class="problematic" id="id11">*</span></a>.h file) it can
+feature, and it’s a single file (actually a *.cpp and *.h file) it can
rapidly be added to the USER-MISC directory. Send us the one-line
entry to add to the USER-MISC/README file in that dir, along with the
2 source files. You can do this multiple times if you wish to
contribute several individual features.</li>
<li>If you want your contribution to be added as a user-contribution and
it is several related featues, it is probably best to make it a user
package directory with a name like USER-FOO. In addition to your new
files, the directory should contain a README text file. The README
should contain your name and contact information and a brief
description of what your new package does. If your files depend on
other LAMMPS style files also being installed (e.g. because your file
is a derived class from the other LAMMPS class), then an Install.sh
file is also needed to check for those dependencies. See other README
and Install.sh files in other USER directories as examples. Send us a
tarball of this USER-FOO directory.</li>
<li>Your new source files need to have the LAMMPS copyright, GPL notice,
and your name and email address at the top, like other
user-contributed LAMMPS source files. They need to create a class
that is inside the LAMMPS namespace. If the file is for one of the
USER packages, including USER-MISC, then we are not as picky about the
coding style (see above). I.e. the files do not need to be in the
same stylistic format and syntax as other LAMMPS files, though that
would be nice for developers as well as users who try to read your
code.</li>
<li>You <strong>must</strong> also create a <strong>documentation</strong> file for each new command or
style you are adding to LAMMPS. For simplicity and convenience, the
documentation of groups of closely related commands or styles may be
combined into a single file. This will be one file for a single-file
feature. For a package, it might be several files. These are simple
text files with a specific markup language, that are then auto-converted
to HTML and PDF. The tools for this conversion are included in the
source distribution, and the translation can be as simple as doing
“make html pdf” in the doc folder.
Thus the documentation source files must be in the same format and
-style as other <em>.txt files in the lammps/doc/src directory for similar
+style as other *.txt files in the lammps/doc/src directory for similar
commands and styles; use one or more of them as a starting point.
A description of the markup can also be found in
lammps/doc/utils/txt2html/README.html
As appropriate, the text files can include links to equations
-(see doc/Eqs/</em>.tex for examples, we auto-create the associated JPG
+(see doc/Eqs/*.tex for examples, we auto-create the associated JPG
files), or figures (see doc/JPG for examples), or even additional PDF
files with further details (see doc/PDF for examples). The doc page
should also include literature citations as appropriate; see the
bottom of doc/fix_nh.txt for examples and the earlier part of the same
file for how to format the cite itself. The “Restrictions” section of
the doc page should indicate that your command is only available if
LAMMPS is built with the appropriate USER-MISC or USER-FOO package.
See other user package doc files for examples of how to do this. The
prerequiste for building the HTML format files are Python 3.x and
virtualenv, the requirement for generating the PDF format manual
is the <a class="reference external" href="http://www.htmldoc.org/">htmldoc</a> software. Please run at least
“make html” and carefully inspect and proofread the resuling HTML format
doc page before submitting your code.</li>
<li>For a new package (or even a single command) you should include one or
more example scripts demonstrating its use. These should run in no
more than a couple minutes, even on a single processor, and not require
large data files as input. See directories under examples/USER for
examples of input scripts other users provided for their packages.
These example inputs are also required for validating memory accesses
and testing for memory leaks with valgrind</li>
<li>If there is a paper of yours describing your feature (either the
algorithm/science behind the feature itself, or its initial usage, or
-its implementation in LAMMPS), you can add the citation to the <a href="#id12"><span class="problematic" id="id13">*</span></a>.cpp
+its implementation in LAMMPS), you can add the citation to the *.cpp
source file. See src/USER-EFF/atom_vec_electron.cpp for an example.
A LaTeX citation is stored in a variable at the top of the file and a
single line of code that references the variable is added to the
constructor of the class. Whenever a user invokes your feature from
their input script, this will cause LAMMPS to output the citation to a
log.cite file and prompt the user to examine the file. Note that you
should only use this for a paper you or your group authored.
E.g. adding a cite in the code for a paper by Nose and Hoover if you
write a fix that implements their integrator is not the intended
usage. That kind of citation should just be in the doc page you
provide.</li>
</ul>
<p>Finally, as a general rule-of-thumb, the more clear and
self-explanatory you make your documentation and README files, and the
easier you make it for people to get started, e.g. by providing example
scripts, the more likely it is that users will try out your new feature.</p>
<p id="foo"><strong>(Foo)</strong> Foo, Morefoo, and Maxfoo, J of Classic Potentials, 75, 345 (1997).</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Contents: Compute and pair styles that implement the adiabatic
core/shell model for polarizability. The compute temp/cs command
measures the temperature of a system with core/shell particles. The
pair styles augment Born, Buckingham, and Lennard-Jones styles with
core/shell capabilities. See <a class="reference internal" href="Section_howto.html#howto-26"><span class="std std-ref">Section howto 6.26</span></a> for an overview of how to use the
<p>Contents: Dozens of atom, pair, bond, angle, dihedral, improper styles
which run with the Kokkos library to provide optimization for
multicore CPUs (via OpenMP), NVIDIA GPUs, or the Intel Xeon Phi (in
native mode). All of them have a “kk” in their style name. <a class="reference internal" href="accelerate_kokkos.html"><span class="doc">Section accelerate kokkos</span></a> gives details of what
hardware and software is required on your system, and how to build and
use this package. See the GPU, OPT, USER-INTEL, USER-OMP packages,
which also provide optimizations for the same range of hardware.</p>
<p>Building with the KOKKOS package requires choosing which of 3 hardware
options you are optimizing for: CPU acceleration via OpenMP, GPU
acceleration, or Intel Xeon Phi. (You can build multiple times to
create LAMMPS executables for different hardware.) It also requires a
C++11 compatible compiler. For GPUs, the NVIDIA “nvcc” compiler is
used, and an appopriate KOKKOS_ARCH setting should be made in your
Makefile.machine for your GPU hardware and NVIDIA software.</p>
<p>The simplest way to do this is to use Makefile.kokkos_cuda or
Makefile.kokkos_omp or Makefile.kokkos_phi in src/MAKE/OPTIONS, via
“make kokkos_cuda” or “make kokkos_omp” or “make kokkos_phi”. (Check
the KOKKOS_ARCH setting in Makefile.kokkos_cuda), Or, as illustrated
below, you can use the Make.py script with its “-kokkos” option to
choose which hardware to build for. Type “python src/Make.py -h
-kokkos” to see the details. If these methods do not work on your
system, you will need to read the <a class="reference internal" href="accelerate_kokkos.html"><span class="doc">Section accelerate kokkos</span></a> doc page for details of what
Makefile.machine settings are needed.</p>
<p>To install via make or Make.py for each of 3 hardware options:</p>
-<span class="n">make</span> <span class="n">kokkos_omp</span> <span class="c1"># for CPUs with OpenMP</span>
-<span class="n">make</span> <span class="n">kokkos_cuda</span> <span class="c1"># for GPUs, check the KOKKOS_ARCH setting in Makefile.kokkos_cuda</span>
-<span class="n">make</span> <span class="n">kokkos_phi</span> <span class="c1"># for Xeon Phis</span>
-</pre></div>
-</div>
+<pre class="literal-block">
+make yes-kokkos
+make kokkos_omp # for CPUs with OpenMP
+make kokkos_cuda # for GPUs, check the KOKKOS_ARCH setting in Makefile.kokkos_cuda
+make kokkos_phi # for Xeon Phis
+</pre>
<p>Make.py -p kokkos -kokkos omp -a machine # for CPUs with OpenMP
Make.py -p kokkos -kokkos cuda arch=35 -a machine # for GPUs of style arch
Make.py -p kokkos -kokkos phi -a machine # for Xeon Phis</p>
<p>Contents: A variety of long-range Coulombic solvers, and pair styles
which compute the corresponding short-range portion of the pairwise
Coulombic interactions. These include Ewald, particle-particle
particle-mesh (PPPM), and multilevel summation method (MSM) solvers.</p>
<p>Building with the KSPACE package requires a 1d FFT library be present
on your system for use by the PPPM solvers. This can be the KISS FFT
library provided with LAMMPS, or 3rd party libraries like FFTW or a
vendor-supplied FFT library. See step 6 of <a class="reference internal" href="Section_start.html#start-2-2"><span class="std std-ref">Section start 2.2.2</span></a> of the manual for details of how
to select different FFT options in your machine Makefile. The Make.py
tool has an “-fft” option which can insert these settings into your
machine Makefile automatically. Type “python src/Make.py -h -fft” to
<p>Contents: A handful of pair styles with an “opt” in their style name
which are optimized for improved CPU performance on single or multiple
cores. These include EAM, LJ, CHARMM, and Morse potentials. <a class="reference internal" href="accelerate_opt.html"><span class="doc">Section accelerate opt</span></a> gives details of how to build and
use this package. See the KOKKOS, USER-INTEL, and USER-OMP packages,
which also have styles optimized for CPU performance.</p>
<p>Some C++ compilers, like the Intel compiler, require the compile flag
“-restrict” to build LAMMPS with the OPT package. It should be added
to the CCFLAGS line of your Makefile.machine. Or use Makefile.opt in
src/MAKE/OPTIONS, via “make opt”. For compilers that use the flag,
the Make.py command adds it automatically to the Makefile.auto file it
<p>Contents: A <a class="reference internal" href="python.html"><span class="doc">python</span></a> command which allow you to execute
Python code from a LAMMPS input script. The code can be in a separate
file or embedded in the input script itself. See <a class="reference external" href="Section_python.html"">Section python 11.2</a> for an overview of using Python from
LAMMPS and for other ways to use LAMMPS and Python together.</p>
<p>Building with the PYTHON package assumes you have a Python shared
library available on your system, which needs to be a Python 2
version, 2.6 or later. Python 3 is not supported. The build uses the
contents of the lib/python/Makefile.lammps file to find all the Python
files required in the build/link process. See the lib/python/README
file if the settings in that file do not work on your system. Note
that the Make.py script has a “-python” option to allow an alternate
lib/python/Makefile.lammps file to be specified and LAMMPS to be built
in one step. Type “python src/Make.py -h -python” to see the details.</p>
<p>Contents: A collection of multi-replica methods that are used by
invoking multiple instances (replicas) of LAMMPS
simulations. Communication between individual replicas is performed in
different ways by the different methods. See <a class="reference internal" href="Section_howto.html#howto-5"><span class="std std-ref">Section howto 6.5</span></a> for an overview of how to run
multi-replica simulations in LAMMPS. Multi-replica methods included
in the package are nudged elastic band (NEB), parallel replica
dynamics (PRD), temperature accelerated dynamics (TAD), parallel
tempering, and a verlet/split algorithm for performing long-range
Coulombics on one set of processors, and the remainded of the force
Sampling and Restraints. This package implements a <a class="reference internal" href="fix_colvars.html"><span class="doc">fix colvars</span></a> command which wraps a COLVARS library which
can perform those kinds of simulations. See src/USER-COLVARS/README
<p>Contents: This package contains methods for simulating polarizable
systems using thermalized Drude oscillators. It has computes, fixes,
and pair styles for this purpose. See <a class="reference internal" href="Section_howto.html#howto-27"><span class="std std-ref">Section howto 6.27</span></a> for an overview of how to use the
package. See src/USER-DRUDE/README for additional details. There are
auxiliary tools for using this package in tools/drude.</p>
<p>Contents: FEP stands for free energy perturbation. This package
provides methods for performing FEP simulations by using a <a class="reference internal" href="fix_adapt_fep.html"><span class="doc">fix adapt/fep</span></a> command with soft-core pair potentials,
which have a “soft” in their style name. See src/USER-FEP/README for
more details. There are auxiliary tools for using this package in
<p>Contents: Dozens of pair, bond, angle, dihedral, and improper styles
that are optimized for Intel CPUs and the Intel Xeon Phi (in offload
mode). All of them have an “intel” in their style name. <a class="reference internal" href="accelerate_intel.html"><span class="doc">Section accelerate intel</span></a> gives details of what hardware
and compilers are required on your system, and how to build and use
this package. Also see src/USER-INTEL/README for more details. See
the KOKKOS, OPT, and USER-OMP packages, which also have CPU and
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li class="toctree-l2"><a class="reference internal" href="#overview-of-running-lammps-from-python">11.1. Overview of running LAMMPS from Python</a></li>
<li class="toctree-l2"><a class="reference internal" href="#overview-of-using-python-from-a-lammps-script">11.2. Overview of using Python from a LAMMPS script</a></li>
<li class="toctree-l2"><a class="reference internal" href="#building-lammps-as-a-shared-library">11.3. Building LAMMPS as a shared library</a></li>
<li class="toctree-l2"><a class="reference internal" href="#installing-the-python-wrapper-into-python">11.4. Installing the Python wrapper into Python</a></li>
<li class="toctree-l2"><a class="reference internal" href="#extending-python-with-mpi-to-run-in-parallel">11.5. Extending Python with MPI to run in parallel</a></li>
<li class="toctree-l2"><a class="reference internal" href="#testing-the-python-lammps-interface">11.6. Testing the Python-LAMMPS interface</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#test-lammps-and-python-in-serial">11.6.1. <strong>Test LAMMPS and Python in serial:</strong></a></li>
<li class="toctree-l3"><a class="reference internal" href="#test-lammps-and-python-in-parallel">11.6.2. <strong>Test LAMMPS and Python in parallel:</strong></a></li>
<li class="toctree-l2"><a class="reference internal" href="#using-lammps-from-python">11.7. Using LAMMPS from Python</a></li>
<li class="toctree-l2"><a class="reference internal" href="#example-python-scripts-that-use-lammps">11.8. Example Python scripts that use LAMMPS</a></li>
<p>LAMMPS can work together with Python in two ways. First, Python can
wrap LAMMPS through the <a class="reference internal" href="Section_howto.html#howto-19"><span class="std std-ref">LAMMPS library interface</span></a>, so that a Python script can
create one or more instances of LAMMPS and launch one or more
simulations. In Python lingo, this is “extending” Python with LAMMPS.</p>
<p>Second, LAMMPS can use the Python interpreter, so that a LAMMPS input
script can invoke Python code, and pass information back-and-forth
between the input script and Python functions you write. The Python
code can also callback to LAMMPS to query or change its attributes.
In Python lingo, this is “embedding” Python in LAMMPS.</p>
<p>This section describes how to do both.</p>
<ul class="simple">
<li>11.1 <a class="reference internal" href="#py-1"><span class="std std-ref">Overview of running LAMMPS from Python</span></a></li>
<li>11.2 <a class="reference internal" href="#py-2"><span class="std std-ref">Overview of using Python from a LAMMPS script</span></a></li>
<li>11.3 <a class="reference internal" href="#py-3"><span class="std std-ref">Building LAMMPS as a shared library</span></a></li>
<li>11.4 <a class="reference internal" href="#py-4"><span class="std std-ref">Installing the Python wrapper into Python</span></a></li>
<li>11.5 <a class="reference internal" href="#py-5"><span class="std std-ref">Extending Python with MPI to run in parallel</span></a></li>
<li>11.6 <a class="reference internal" href="#py-6"><span class="std std-ref">Testing the Python-LAMMPS interface</span></a></li>
<li>11.7 <a class="reference internal" href="#py-7"><span class="std std-ref">Using LAMMPS from Python</span></a></li>
<li>11.8 <a class="reference internal" href="#py-8"><span class="std std-ref">Example Python scripts that use LAMMPS</span></a></li>
</ul>
<p>If you are not familiar with it, <a class="reference external" href="http://www.python.org">Python</a> is a
powerful scripting and programming language which can essentially do
anything that faster, lower-level languages like C or C++ can do, but
typically with much fewer lines of code. When used in embedded mode,
Python can perform operations that the simplistic LAMMPS input script
syntax cannot. Python can be also be used as a “glue” language to
drive a program through its library interface, or to hook multiple
pieces of software together, such as a simulation package plus a
visualization package, or to run a coupled multiscale or multiphysics
model.</p>
<p>See <a class="reference internal" href="Section_howto.html#howto-10"><span class="std std-ref">Section_howto 10</span></a> of the manual and
the couple directory of the distribution for more ideas about coupling
LAMMPS to other codes. See <a class="reference internal" href="Section_howto.html#howto-19"><span class="std std-ref">Section_howto 19</span></a> for a description of the LAMMPS
library interface provided in src/library.cpp and src/library.h, and
how to extend it for your needs. As described below, that interface
is what is exposed to Python either when calling LAMMPS from Python or
when calling Python from a LAMMPS input script and then calling back
to LAMMPS from Python code. The library interface is designed to be
easy to add functions to. Thus the Python interface to LAMMPS is also
easy to extend as well.</p>
<p>If you create interesting Python scripts that run LAMMPS or
interesting Python functions that can be called from a LAMMPS input
script, that you think would be useful to other users, please <a class="reference external" href="http://lammps.sandia.gov/authors.html">email them to the developers</a>. We can
<p>If an error occurs, carefully go thru the steps in <a class="reference internal" href="Section_start.html#start-5"><span class="std std-ref">Section_start 5</span></a> and above about building a shared
library and about insuring Python can find the necessary two files
-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">flag</span> <span class="o">=</span> <span class="n">lmp</span><span class="o">.</span><span class="n">set_variable</span><span class="p">(</span><span class="n">name</span><span class="p">,</span><span class="n">value</span><span class="p">)</span> <span class="c1"># set existing named string-style variable to value, flag = 0 if successful</span>
-<span class="n">natoms</span> <span class="o">=</span> <span class="n">lmp</span><span class="o">.</span><span class="n">get_natoms</span><span class="p">()</span> <span class="c1"># total # of atoms as int</span>
-<span class="n">data</span> <span class="o">=</span> <span class="n">lmp</span><span class="o">.</span><span class="n">gather_atoms</span><span class="p">(</span><span class="n">name</span><span class="p">,</span><span class="nb">type</span><span class="p">,</span><span class="n">count</span><span class="p">)</span> <span class="c1"># return atom attribute of all atoms gathered into data, ordered by atom ID</span>
- <span class="c1"># name = "x", "charge", "type", etc</span>
- <span class="c1"># count = # of per-atom values, 1 or 3, etc</span>
-<span class="n">lmp</span><span class="o">.</span><span class="n">scatter_atoms</span><span class="p">(</span><span class="n">name</span><span class="p">,</span><span class="nb">type</span><span class="p">,</span><span class="n">count</span><span class="p">,</span><span class="n">data</span><span class="p">)</span> <span class="c1"># scatter atom attribute of all atoms from data, ordered by atom ID</span>
- <span class="c1"># name = "x", "charge", "type", etc</span>
- <span class="c1"># count = # of per-atom values, 1 or 3, etc</span>
-</pre></div>
-</div>
+<pre class="literal-block">
+xlo = lmp.extract_global(name,type) # extract a global quantity
+ # name = "boxxlo", "nlocal", etc
+ # type = 0 = int
+ # 1 = double
+</pre>
+<pre class="literal-block">
+coords = lmp.extract_atom(name,type) # extract a per-atom quantity
+ # name = "x", "type", etc
+ # type = 0 = vector of ints
+ # 1 = array of ints
+ # 2 = vector of doubles
+ # 3 = array of doubles
+</pre>
+<pre class="literal-block">
+eng = lmp.extract_compute(id,style,type) # extract value(s) from a compute
+v3 = lmp.extract_fix(id,style,type,i,j) # extract value(s) from a fix
+ # id = ID of compute or fix
+ # style = 0 = global data
+ # 1 = per-atom data
+ # 2 = local data
+ # type = 0 = scalar
+ # 1 = vector
+ # 2 = array
+ # i,j = indices of value in global vector or array
+</pre>
+<pre class="literal-block">
+var = lmp.extract_variable(name,group,flag) # extract value(s) from a variable
+ # name = name of variable
+ # group = group ID (ignored for equal-style variables)
+ # flag = 0 = equal-style variable
+ # 1 = atom-style variable
+</pre>
+<pre class="literal-block">
+flag = lmp.set_variable(name,value) # set existing named string-style variable to value, flag = 0 if successful
+natoms = lmp.get_natoms() # total # of atoms as int
+data = lmp.gather_atoms(name,type,count) # return atom attribute of all atoms gathered into data, ordered by atom ID
+ # name = "x", "charge", "type", etc
+ # count = # of per-atom values, 1 or 3, etc
+lmp.scatter_atoms(name,type,count,data) # scatter atom attribute of all atoms from data, ordered by atom ID
+ # name = "x", "charge", "type", etc
extract_fix(), and extract_variable() methods return values or
pointers to data structures internal to LAMMPS.</p>
<p>For extract_global() see the src/library.cpp file for the list of
valid names. New names could easily be added. A double or integer is
returned. You need to specify the appropriate data type via the type
argument.</p>
<p>For extract_atom(), a pointer to internal LAMMPS atom-based data is
returned, which you can use via normal Python subscripting. See the
extract() method in the src/atom.cpp file for a list of valid names.
Again, new names could easily be added. A pointer to a vector of
-doubles or integers, or a pointer to an array of doubles (double <a href="#id3"><span class="problematic" id="id4">**</span></a>)
-or integers (int <a href="#id5"><span class="problematic" id="id6">**</span></a>) is returned. You need to specify the appropriate
+doubles or integers, or a pointer to an array of doubles (double **)
+or integers (int **) is returned. You need to specify the appropriate
data type via the type argument.</p>
<p>For extract_compute() and extract_fix(), the global, per-atom, or
local data calulated by the compute or fix can be accessed. What is
returned depends on whether the compute or fix calculates a scalar or
vector or array. For a scalar, a single double value is returned. If
the compute or fix calculates a vector or array, a pointer to the
internal LAMMPS data is returned, which you can use via normal Python
subscripting. The one exception is that for a fix that calculates a
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. The I,J arguments can be left out if not needed.
See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section_howto 15</span></a> of the manual for a
discussion of global, per-atom, and local data, and of scalar, vector,
and array data types. See the doc pages for individual
<a class="reference internal" href="compute.html"><span class="doc">computes</span></a> and <a class="reference internal" href="fix.html"><span class="doc">fixes</span></a> for a description of what
they calculate and store.</p>
<p>For extract_variable(), an <a class="reference internal" href="variable.html"><span class="doc">equal-style or atom-style variable</span></a> is evaluated and its result returned.</p>
<p>For equal-style variables a single double value is returned and the
group argument is ignored. For atom-style variables, a vector of
doubles is returned, one value per atom, which you can use via normal
Python subscripting. The values will be zero for atoms not in the
specified group.</p>
<p>The get_natoms() method returns the total number of atoms in the
simulation, as an int.</p>
<p>The gather_atoms() method returns a ctypes vector of ints or doubles
as specified by type, of length count*natoms, for the property of all
the atoms in the simulation specified by name, ordered by count and
then by atom ID. The vector can be used via normal Python
subscripting. If atom IDs are not consecutively ordered within
LAMMPS, a None is returned as indication of an error.</p>
<p>Note that the data structure gather_atoms(“x”) returns is different
from the data structure returned by extract_atom(“x”) in four ways.
(1) Gather_atoms() returns a vector which you index as x[i];
extract_atom() returns an array which you index as x[i][j]. (2)
Gather_atoms() orders the atoms by atom ID while extract_atom() does
not. (3) Gathert_atoms() returns a list of all atoms in the
simulation; extract_atoms() returns just the atoms local to each
processor. (4) Finally, the gather_atoms() data structure is a copy
of the atom coords stored internally in LAMMPS, whereas extract_atom()
returns an array that effectively points directly to the internal
data. This means you can change values inside LAMMPS from Python by
assigning a new values to the extract_atom() array. To do this with
the gather_atoms() vector, you need to change values in the vector,
then invoke the scatter_atoms() method.</p>
<p>The scatter_atoms() method takes a vector of ints or doubles as
specified by type, of length count*natoms, for the property of all the
atoms in the simulation specified by name, ordered by bount and then
by atom ID. It uses the vector of data to overwrite the corresponding
properties for each atom inside LAMMPS. This requires LAMMPS to have
its “map” option enabled; see the <a class="reference internal" href="atom_modify.html"><span class="doc">atom_modify</span></a>
command for details. If it is not, or if atom IDs are not
consecutively ordered, no coordinates are reset.</p>
<p>The array of coordinates passed to scatter_atoms() must be a ctypes
vector of ints or doubles, allocated and initialized something like
<span id="py-8"></span><h2>11.8. Example Python scripts that use LAMMPS</h2>
<p>These are the Python scripts included as demos in the python/examples
directory of the LAMMPS distribution, to illustrate the kinds of
things that are possible when Python wraps LAMMPS. If you create your
own scripts, send them to us and we can include them in the LAMMPS
distribution.</p>
<table border="1" class="docutils">
<colgroup>
<col width="56%" />
<col width="44%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>trivial.py</td>
<td>read/run a LAMMPS input script thru Python</td>
</tr>
<tr class="row-even"><td>demo.py</td>
<td>invoke various LAMMPS library interface routines</td>
</tr>
<tr class="row-odd"><td>simple.py</td>
<td>run in parallel</td>
</tr>
<tr class="row-even"><td>similar to examples/COUPLE/simple/simple.cpp</td>
<td>split.py</td>
</tr>
<tr class="row-odd"><td>same as simple.py but running in parallel on a subset of procs</td>
<td>gui.py</td>
</tr>
<tr class="row-even"><td>GUI go/stop/temperature-slider to control LAMMPS</td>
<td>plot.py</td>
</tr>
<tr class="row-odd"><td>real-time temeperature plot with GnuPlot via Pizza.py</td>
<td>viz_tool.py</td>
</tr>
<tr class="row-even"><td>real-time viz via some viz package</td>
<td>vizplotgui_tool.py</td>
</tr>
<tr class="row-odd"><td>combination of viz_tool.py and plot.py and gui.py</td>
<td> </td>
</tr>
</tbody>
</table>
<hr class="docutils" />
<p>For the viz_tool.py and vizplotgui_tool.py commands, replace “tool”
with “gl” or “atomeye” or “pymol” or “vmd”, depending on what
visualization package you have installed.</p>
<p>Note that for GL, you need to be able to run the Pizza.py GL tool,
which is included in the pizza sub-directory. See the <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py doc pages</a> for more info:</p>
<p>Note that for AtomEye, you need version 3, and there is a line in the
scripts that specifies the path and name of the executable. See the
AtomEye WWW pages <a class="reference external" href="http://mt.seas.upenn.edu/Archive/Graphics/A">here</a> or <a class="reference external" href="http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html">here</a> for more details:</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li class="toctree-l3"><a class="reference internal" href="#additional-requirement-for-using-a-shared-library">2.5.3. <strong>Additional requirement for using a shared library:</strong></a></li>
<li class="toctree-l3"><a class="reference internal" href="#calling-the-lammps-library">2.5.4. <strong>Calling the LAMMPS library:</strong></a></li>
<p>This will create a LAMMPS directory containing two files and several
sub-directories:</p>
<table border="1" class="docutils">
<colgroup>
<col width="21%" />
<col width="79%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>README</td>
<td>text file</td>
</tr>
<tr class="row-even"><td>LICENSE</td>
<td>the GNU General Public License (GPL)</td>
</tr>
<tr class="row-odd"><td>bench</td>
<td>benchmark problems</td>
</tr>
<tr class="row-even"><td>doc</td>
<td>documentation</td>
</tr>
<tr class="row-odd"><td>examples</td>
<td>simple test problems</td>
</tr>
<tr class="row-even"><td>potentials</td>
<td>embedded atom method (EAM) potential files</td>
</tr>
<tr class="row-odd"><td>src</td>
<td>source files</td>
</tr>
<tr class="row-even"><td>tools</td>
<td>pre- and post-processing tools</td>
</tr>
</tbody>
</table>
<p>Note that the <a class="reference external" href="http://lammps.sandia.gov/download.html">download page</a> also has links to download
Windows exectubles and installers, as well as pre-built executables
for a few specific Linux distributions. It also has instructions for
how to download/install LAMMPS for Macs (via Homebrew), and to
download and update LAMMPS from SVN and Git repositories, which gives
you the same files that are in the download tarball.</p>
<p>The Windows and Linux executables for serial or parallel only include
certain packages and bug-fixes/upgrades listed on <a class="reference external" href="http://lammps.sandia.gov/bug.html">this page</a> up to a certain date, as
stated on the download page. If you want an executable with
non-included packages or that is more current, then you’ll need to
build LAMMPS yourself, as discussed in the next section.</p>
<p>Skip to the <a class="reference internal" href="#start-6"><span class="std std-ref">Running LAMMPS</span></a> sections for info on how to
launch a LAMMPS Windows executable on a Windows box.</p>
<hr class="docutils" />
</div>
<div class="section" id="making-lammps">
<span id="start-2"></span><h2>2.2. Making LAMMPS</h2>
<p>This section has the following sub-sections:</p>
<ul class="simple">
<li><a class="reference internal" href="#start-2-1"><span class="std std-ref">Read this first</span></a></li>
<li><a class="reference internal" href="#start-2-2"><span class="std std-ref">Steps to build a LAMMPS executable</span></a></li>
<li><a class="reference internal" href="#start-2-3"><span class="std std-ref">Common errors that can occur when making LAMMPS</span></a></li>
This gives preference to a file you have created/edited and put in
src/MAKE/MINE.</p>
<p>Note that on a multi-processor or multi-core platform you can launch a
parallel make, by using the “-j” switch with the make command, which
will build LAMMPS more quickly.</p>
<p>If you get no errors and an executable like lmp_mpi or lmp_g++_serial
or lmp_mac is produced, then you’re done; it’s your lucky day.</p>
<p>Note that by default only a few of LAMMPS optional packages are
installed. To build LAMMPS with optional packages, see <a class="reference internal" href="#start-3"><span class="std std-ref">this section</span></a> below.</p>
<p><strong>Step 1</strong></p>
<p>If Step 0 did not work, you will need to create a low-level Makefile
for your machine, like Makefile.foo. You should make a copy of an
existing Makefile.* in src/MAKE or one of its sub-directories as a
starting point. The only portions of the file you need to edit are
the first line, the “compiler/linker settings” section, and the
“LAMMPS-specific settings” section. When it works, put the edited
file in src/MAKE/MINE and it will not be altered by any future LAMMPS
updates.</p>
<p><strong>Step 2</strong></p>
<p>Change the first line of Makefile.foo to list the word “foo” after the
“#”, and whatever other options it will set. This is the line you
will see if you just type “make”.</p>
<p><strong>Step 3</strong></p>
<p>The “compiler/linker settings” section lists compiler and linker
settings for your C++ compiler, including optimization flags. You can
use g++, the open-source GNU compiler, which is available on all Unix
systems. You can also use mpicxx which will typically be available if
MPI is installed on your system, though you should check which actual
compiler it wraps. Vendor compilers often produce faster code. On
boxes with Intel CPUs, we suggest using the Intel icc compiler, which
can be downloaded from <a class="reference external" href="http://www.intel.com/software/products/noncom">Intel’s compiler site</a>.</p>
<p>If building a C++ code on your machine requires additional libraries,
then you should list them as part of the LIB variable. You should
not need to do this if you use mpicxx.</p>
<p>The DEPFLAGS setting is what triggers the C++ compiler to create a
dependency list for a source file. This speeds re-compilation when
-source (<em>.cpp) or header (</em>.h) files are edited. Some compilers do
+source (*.cpp) or header (*.h) files are edited. Some compilers do
not support dependency file creation, or may use a different switch
than -D. GNU g++ and Intel icc works with -D. If your compiler can’t
create dependency files, then you’ll need to create a Makefile.foo
patterned after Makefile.storm, which uses different rules that do not
involve dependency files. Note that when you build LAMMPS for the
-first time on a new platform, a long list of <a href="#id5"><span class="problematic" id="id6">*</span></a>.d files will be printed
+first time on a new platform, a long list of *.d files will be printed
out rapidly. This is not an error; it is the Makefile doing its
normal creation of dependencies.</p>
<p><strong>Step 4</strong></p>
<p>The “system-specific settings” section has several parts. Note that
if you change any -D setting in this section, you should do a full
re-compile, after typing “make clean” (which will describe different
clean options).</p>
<p>The LMP_INC variable is used to include options that turn on ifdefs
within the LAMMPS code. The options that are currently recogized are:</p>
<ul class="simple">
<li>-DLAMMPS_GZIP</li>
<li>-DLAMMPS_JPEG</li>
<li>-DLAMMPS_PNG</li>
<li>-DLAMMPS_FFMPEG</li>
<li>-DLAMMPS_MEMALIGN</li>
<li>-DLAMMPS_XDR</li>
<li>-DLAMMPS_SMALLBIG</li>
<li>-DLAMMPS_BIGBIG</li>
<li>-DLAMMPS_SMALLSMALL</li>
<li>-DLAMMPS_LONGLONG_TO_LONG</li>
<li>-DLAMMPS_EXCEPTIONS</li>
<li>-DPACK_ARRAY</li>
<li>-DPACK_POINTER</li>
<li>-DPACK_MEMCPY</li>
</ul>
<p>The read_data and dump commands will read/write gzipped files if you
compile with -DLAMMPS_GZIP. It requires that your machine supports
the “popen()” function in the standard runtime library and that a gzip
executable can be found by LAMMPS during a run.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">on some clusters with high-speed networks, using the fork()
library calls (required by popen()) can interfere with the fast
communication library and lead to simulations using compressed output
or input to hang or crash. For selected operations, compressed file
I/O is also available using a compression library instead, which are
provided in the COMPRESS package. From more details about compiling
LAMMPS with packages, please see below.</p>
</div>
<p>If you use -DLAMMPS_JPEG, the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a> command
will be able to write out JPEG image files. For JPEG files, you must
also link LAMMPS with a JPEG library, as described below. If you use
-DLAMMPS_PNG, the <a class="reference internal" href="dump.html"><span class="doc">dump image</span></a> command will be able to write
out PNG image files. For PNG files, you must also link LAMMPS with a
PNG library, as described below. If neither of those two defines are
used, LAMMPS will only be able to write out uncompressed PPM image
files.</p>
<p>If you use -DLAMMPS_FFMPEG, the <a class="reference internal" href="dump_image.html"><span class="doc">dump movie</span></a> command
will be available to support on-the-fly generation of rendered movies
the need to store intermediate image files. It requires that your
machines supports the “popen” function in the standard runtime library
and that an FFmpeg executable can be found by LAMMPS during the run.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Similar to the note above, this option can conflict with
high-speed networks, because it uses popen().</p>
</div>
<p>Using -DLAMMPS_MEMALIGN=<bytes> enables the use of the
posix_memalign() call instead of malloc() when large chunks or memory
are allocated by LAMMPS. This can help to make more efficient use of
vector instructions of modern CPUS, since dynamically allocated memory
has to be aligned on larger than default byte boundaries (e.g. 16
bytes instead of 8 bytes on x86 type platforms) for optimal
performance.</p>
<p>If you use -DLAMMPS_XDR, the build will include XDR compatibility
files for doing particle dumps in XTC format. This is only necessary
if your platform does have its own XDR files available. See the
Restrictions section of the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command for details.</p>
<p>Use at most one of the -DLAMMPS_SMALLBIG, -DLAMMPS_BIGBIG,
-DLAMMPS_SMALLSMALL settings. The default is -DLAMMPS_SMALLBIG. These
settings refer to use of 4-byte (small) vs 8-byte (big) integers
within LAMMPS, as specified in src/lmptype.h. The only reason to use
the BIGBIG setting is to enable simulation of huge molecular systems
(which store bond topology info) with more than 2 billion atoms, or to
track the image flags of moving atoms that wrap around a periodic box
more than 512 times. Normally, the only reason to use SMALLSMALL is
if your machine does not support 64-bit integers, though you can use
SMALLSMALL setting if you are running in serial or on a desktop
machine or small cluster where you will never run large systems or for
long time (more than 2 billion atoms, more than 2 billion timesteps).
See the <a class="reference internal" href="#start-2-4"><span class="std std-ref">Additional build tips</span></a> section below for more
details on these settings.</p>
<p>Note that the USER-ATC package is not currently compatible with
-DLAMMPS_BIGBIG. Also the GPU package requires the lib/gpu library to
be compiled with the same setting, or the link will fail.</p>
<p>The -DLAMMPS_LONGLONG_TO_LONG setting may be needed if your system or
MPI version does not recognize “long long” data types. In this case a
“long” data type is likely already 64-bits, in which case this setting
will convert to that data type.</p>
<p>The -DLAMMPS_EXCEPTIONS setting can be used to activate alternative
versions of error handling inside of LAMMPS. This is useful when
external codes drive LAMMPS as a library. Using this option, LAMMPS
errors do not kill the caller. Instead, the call stack is unwound and
control returns to the caller. The library interface provides the
lammps_has_error() and lammps_get_last_error_message() functions to
detect and find out more about a LAMMPS error.</p>
<p>Using one of the -DPACK_ARRAY, -DPACK_POINTER, and -DPACK_MEMCPY
options can make for faster parallel FFTs (in the PPPM solver) on some
platforms. The -DPACK_ARRAY setting is the default. See the
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command for info about PPPM. See
Step 6 below for info about building LAMMPS with an FFT library.</p>
<p><strong>Step 5</strong></p>
<p>The 3 MPI variables are used to specify an MPI library to build LAMMPS
with. Note that you do not need to set these if you use the MPI
compiler mpicxx for your CC and LINK setting in the section above.
The MPI wrapper knows where to find the needed files.</p>
<p>If you want LAMMPS to run in parallel, you must have an MPI library
installed on your platform. If MPI is installed on your system in the
usual place (under /usr/local), you also may not need to specify these
3 variables, assuming /usr/local is in your path. On some large
parallel machines which use “modules” for their compile/link
environements, you may simply need to include the correct module in
your build environment, before building LAMMPS. Or the parallel
machine may have a vendor-provided MPI which the compiler has no
trouble finding.</p>
<p>Failing this, these 3 variables can be used to specify where the mpi.h
file (MPI_INC) and the MPI library file (MPI_PATH) are found and the
name of the library file (MPI_LIB).</p>
<p>If you are installing MPI yourself, we recommend Argonne’s MPICH2
or OpenMPI. MPICH can be downloaded from the <a class="reference external" href="http://www.mcs.anl.gov/research/projects/mpich2/">Argonne MPI site</a>. OpenMPI can
be downloaded from the <a class="reference external" href="http://www.open-mpi.org">OpenMPI site</a>.
Other MPI packages should also work. If you are running on a big
parallel platform, your system people or the vendor should have
already installed a version of MPI, which is likely to be faster
than a self-installed MPICH or OpenMPI, so find out how to build
and link with it. If you use MPICH or OpenMPI, you will have to
configure and build it for your platform. The MPI configure script
should have compiler options to enable you to use the same compiler
you are using for the LAMMPS build, which can avoid problems that can
arise when linking LAMMPS to the MPI library.</p>
<p>If you just want to run LAMMPS on a single processor, you can use the
dummy MPI library provided in src/STUBS, since you don’t need a true
MPI library installed on your system. See src/MAKE/Makefile.serial
for how to specify the 3 MPI variables in this case. You will also
need to build the STUBS library for your platform before making LAMMPS
itself. Note that if you are building with src/MAKE/Makefile.serial,
e.g. by typing “make serial”, then the STUBS library is built for you.</p>
<p>To build the STUBS library from the src directory, type “make
mpi-stubs”, or from the src/STUBS dir, type “make”. This should
create a libmpi_stubs.a file suitable for linking to LAMMPS. If the
build fails, you will need to edit the STUBS/Makefile for your
platform.</p>
<p>The file STUBS/mpi.c provides a CPU timer function called MPI_Wtime()
that calls gettimeofday() . If your system doesn’t support
gettimeofday() , you’ll need to insert code to call another timer.
Note that the ANSI-standard function clock() rolls over after an hour
or so, and is therefore insufficient for timing long LAMMPS
simulations.</p>
<p><strong>Step 6</strong></p>
<p>The 3 FFT variables allow you to specify an FFT library which LAMMPS
uses (for performing 1d FFTs) when running the particle-particle
particle-mesh (PPPM) option for long-range Coulombics via the
ACML, and T3E. For backward compatability, using -DFFT_FFTW will use
the FFTW2 library. Using -DFFT_NONE will use the KISS library
described above.</p>
<p>You may also need to set the FFT_INC, FFT_PATH, and FFT_LIB variables,
so the compiler and linker can find the needed FFT header and library
files. Note that on some large parallel machines which use “modules”
for their compile/link environements, you may simply need to include
the correct module in your build environment. Or the parallel machine
may have a vendor-provided FFT library which the compiler has no
trouble finding.</p>
<p>FFTW is a fast, portable library that should also work on any
platform. You can download it from
<a class="reference external" href="http://www.fftw.org">www.fftw.org</a>. Both the legacy version 2.1.X and
the newer 3.X versions are supported as -DFFT_FFTW2 or -DFFT_FFTW3.
Building FFTW for your box should be as simple as ./configure; make.
Note that on some platforms FFTW2 has been pre-installed, and uses
renamed files indicating the precision it was compiled with,
e.g. sfftw.h, or dfftw.h instead of fftw.h. In this case, you can
specify an additional define variable for FFT_INC called -DFFTW_SIZE,
which will select the correct include file. In this case, for FFT_LIB
you must also manually specify the correct library, namely -lsfftw or
-ldfftw.</p>
<p>The FFT_INC variable also allows for a -DFFT_SINGLE setting that will
use single-precision FFTs with PPPM, which can speed-up long-range
calulations, particularly in parallel or on GPUs. Fourier transform
and related PPPM operations are somewhat insensitive to floating point
truncation errors and thus do not always need to be performed in
double precision. Using the -DFFT_SINGLE setting trades off a little
accuracy for reduced memory use and parallel communication costs for
transposing 3d FFT data. Note that single precision FFTs have only
been tested with the FFTW3, FFTW2, MKL, and KISS FFT options.</p>
<p><strong>Step 7</strong></p>
<p>The 3 JPG variables allow you to specify a JPEG and/or PNG library
which LAMMPS uses when writing out JPEG or PNG files via the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a> command. These can be left blank if you do not
use the -DLAMMPS_JPEG or -DLAMMPS_PNG switches discussed above in Step
4, since in that case JPEG/PNG output will be disabled.</p>
<p>A standard JPEG library usually goes by the name libjpeg.a or
libjpeg.so and has an associated header file jpeglib.h. Whichever
JPEG library you have on your platform, you’ll need to set the
appropriate JPG_INC, JPG_PATH, and JPG_LIB variables, so that the
compiler and linker can find it.</p>
<p>A standard PNG library usually goes by the name libpng.a or libpng.so
and has an associated header file png.h. Whichever PNG library you
have on your platform, you’ll need to set the appropriate JPG_INC,
JPG_PATH, and JPG_LIB variables, so that the compiler and linker can
find it.</p>
<p>As before, if these header and library files are in the usual place on
your machine, you may not need to set these variables.</p>
<p><strong>Step 8</strong></p>
<p>Note that by default only a few of LAMMPS optional packages are
installed. To build LAMMPS with optional packages, see <a class="reference internal" href="#start-3"><span class="std std-ref">this section</span></a> below, before proceeding to Step 9.</p>
<p><strong>Step 9</strong></p>
<p>That’s it. Once you have a correct Makefile.foo, and you have
pre-built any other needed libraries (e.g. MPI, FFT, etc) all you need
to do from the src directory is type something like this:</p>
<p>You can make LAMMPS for multiple platforms from the same src
directory. Each target creates its own object sub-directory called
-Obj_target where it stores the system-specific <a href="#id11"><span class="problematic" id="id12">*</span></a>.o files.</p>
+Obj_target where it stores the system-specific *.o files.</p>
<ol class="arabic simple" start="2">
<li>Cleaning up.</li>
</ol>
-<p>Typing “make clean-all” or “make clean-machine” will delete <a href="#id13"><span class="problematic" id="id14">*</span></a>.o object
+<p>Typing “make clean-all” or “make clean-machine” will delete *.o object
files created when LAMMPS is built, for either all builds or for a
particular machine.</p>
<p>(3) Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or
-DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL</p>
<p>As explained above, any of these 3 settings can be specified on the
LMP_INC line in your low-level src/MAKE/Makefile.foo.</p>
<p>The default is -DLAMMPS_SMALLBIG which allows for systems with up to
2^63 atoms and 2^63 timesteps (about 9e18). The atom limit is for
atomic systems which do not store bond topology info and thus do not
require atom IDs. If you use atom IDs for atomic systems (which is
the default) or if you use a molecular model, which stores bond
topology info and thus requires atom IDs, the limit is 2^31 atoms
(about 2 billion). This is because the IDs are stored in 32-bit
integers.</p>
<p>Likewise, with this setting, the 3 image flags for each atom (see the
<a class="reference internal" href="dump.html"><span class="doc">dump</span></a> doc page for a discussion) are stored in a 32-bit
integer, which means the atoms can only wrap around a periodic box (in
each dimension) at most 512 times. If atoms move through the periodic
box more than this many times, the image flags will “roll over”,
e.g. from 511 to -512, which can cause diagnostics like the
mean-squared displacement, as calculated by the <a class="reference internal" href="compute_msd.html"><span class="doc">compute msd</span></a> command, to be faulty.</p>
<p>To allow for larger atomic systems with atom IDs or larger molecular
systems or larger image flags, compile with -DLAMMPS_BIGBIG. This
stores atom IDs and image flags in 64-bit integers. This enables
atomic or molecular systems with atom IDS of up to 2^63 atoms (about
9e18). And image flags will not “roll over” until they reach 2^20 =
1048576.</p>
<p>If your system does not support 8-byte integers, you will need to
compile with the -DLAMMPS_SMALLSMALL setting. This will restrict the
total number of atoms (for atomic or molecular systems) and timesteps
to 2^31 (about 2 billion). Image flags will roll over at 2^9 = 512.</p>
<p>Note that in src/lmptype.h there are definitions of all these data
types as well as the MPI data types associated with them. The MPI
types need to be consistent with the associated C data types, or else
LAMMPS will generate a run-time error. As far as we know, the
settings defined in src/lmptype.h are portable and work on every
current system.</p>
<p>In all cases, the size of problem that can be run on a per-processor
basis is limited by 4-byte integer storage to 2^31 atoms per processor
(about 2 billion). This should not normally be a limitation since such
a problem would have a huge per-processor memory footprint due to
neighbor lists and would run very slowly in terms of CPU secs/timestep.</p>
<hr class="docutils" />
-<p id="start-2-5"><a href="#id15"><span class="problematic" id="id16">**</span></a><em>Building for a Mac:</em>**</p>
+<p id="start-2-5"><a href="#id9"><span class="problematic" id="id10">**</span></a><em>Building for a Mac:</em>**</p>
<p>OS X is BSD Unix, so it should just work. See the
src/MAKE/MACHINES/Makefile.mac and Makefile.mac_mpi files.</p>
<hr class="docutils" />
-<p id="start-2-6"><a href="#id17"><span class="problematic" id="id18">**</span></a><em>Building for Windows:</em>**</p>
+<p id="start-2-6"><a href="#id11"><span class="problematic" id="id12">**</span></a><em>Building for Windows:</em>**</p>
<p>The LAMMPS download page has an option to download both a serial and
parallel pre-built Windows executable. See the <a class="reference internal" href="#start-6"><span class="std std-ref">Running LAMMPS</span></a> section for instructions on running these executables
on a Windows box.</p>
<p>The pre-built executables hosted on the <a class="reference external" href="http://lammps.sandia.gov/download.html">LAMMPS download page</a> are built with a subset
of the available packages; see the download page for the list. These
are single executable files. No examples or documentation in
included. You will need to download the full source code package to
obtain those.</p>
<p>As an alternative, you can download “daily builds” (and some older
<p>to run your executable with the optional <a class="reference internal" href="#start-7"><span class="std std-ref">-h command-line switch</span></a> for “help”, which will simply list the styles and
commands known to your executable, and immediately exit.</p>
<p>There are two kinds of packages in LAMMPS, standard and user packages.
More information about the contents of standard and user packages is
given in <a class="reference internal" href="Section_packages.html"><span class="doc">Section_packages</span></a> of the manual. The
difference between standard and user packages is as follows:</p>
<p>Standard packages, such as molecule or kspace, are supported by the
LAMMPS developers and are written in a syntax and style consistent
with the rest of LAMMPS. This means we will answer questions about
them, debug and fix them if necessary, and keep them compatible with
future changes to LAMMPS.</p>
<p>User packages, such as user-atc or user-omp, have been contributed by
users, and always begin with the user prefix. If they are a single
command (single file), they are typically in the user-misc package.
Otherwise, they are a a set of files grouped together which add a
specific functionality to the code.</p>
<p>User packages don’t necessarily meet the requirements of the standard
packages. If you have problems using a feature provided in a user
package, you may need to contact the contributor directly to get help.
Information on how to submit additions you make to LAMMPS as single
files or either a standard or user-contributed package are given in
<a class="reference internal" href="Section_modify.html#mod-15"><span class="std std-ref">this section</span></a> of the documentation.</p>
no-user”, “make yes-lib”, “make no-lib”, “make yes-all”, or “make
no-all” to include/exclude various sets of packages. Type “make
package” to see all of the package-related make options.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Inclusion/exclusion of a package works by simply moving files
back and forth between the main src directory and sub-directories with
the package name (e.g. src/KSPACE, src/USER-ATC), so that the files
are seen or not seen when LAMMPS is built. After you have included or
excluded a package, you must re-build LAMMPS.</p>
</div>
<p>Additional package-related make options exist to help manage LAMMPS
files that exist in both the src directory and in package
sub-directories. You do not normally need to use these commands
unless you are editing LAMMPS files or have downloaded a patch from
the LAMMPS WWW site.</p>
<p>Typing “make package-update” or “make pu” will overwrite src files
with files from the package sub-directories if the package has been
included. It should be used after a patch is installed, since patches
only update the files in the package sub-directory, but not the src
files. Typing “make package-overwrite” will overwrite files in the
package sub-directories with src files.</p>
<p>Typing “make package-status” or “make ps” will show which packages are
currently included. For those that are included, it will list any
files that are different in the src directory and package
sub-directory. Typing “make package-diff” lists all differences
between these files. Again, type “make package” to see all of the
package-related make options.</p>
<hr class="docutils" />
-<p id="start-3-3"><a href="#id23"><span class="problematic" id="id24">**</span></a><em>Packages that require extra libraries:</em>**</p>
+<p id="start-3-3"><a href="#id17"><span class="problematic" id="id18">**</span></a><em>Packages that require extra libraries:</em>**</p>
<p>A few of the standard and user packages require additional auxiliary
libraries. Many of them are provided with LAMMPS, in which case they
must be compiled first, before LAMMPS is built, if you wish to include
that package. If you get a LAMMPS build error about a missing
library, this is likely the reason. See the
<a class="reference internal" href="Section_packages.html"><span class="doc">Section_packages</span></a> doc page for a list of
packages that have these kinds of auxiliary libraries.</p>
<p>The lib directory in the distribution has sub-directories with package
names that correspond to the needed auxiliary libs, e.g. lib/gpu.
Each sub-directory has a README file that gives more details. Code
for most of the auxiliary libraries is included in that directory.
Examples are the USER-ATC and MEAM packages.</p>
<p>A few of the lib sub-directories do not include code, but do include
instructions (and sometimes scripts) that automate the process of
downloading the auxiliary library and installing it so LAMMPS can link
to it. Examples are the KIM, VORONOI, USER-MOLFILE, and USER-SMD
packages.</p>
<p>The lib/python directory (for the PYTHON package) contains only a
choice of Makefile.lammps.* files. This is because no auxiliary code
or libraries are needed, only the Python library and other system libs
that should already available on your system. However, the
Makefile.lammps file is needed to tell LAMMPS which libs to use and
where to find them.</p>
<p>For libraries with provided code, the sub-directory README file
(e.g. lib/atc/README) has instructions on how to build that library.
This information is also summarized in <a class="reference internal" href="Section_packages.html"><span class="doc">Section packages</span></a>. Typically this is done by typing
<p>The Makefile.lammps file will typically be a copy of one of the
Makefile.lammps.* files in the library directory.</p>
<p>Note that you must insure that the settings in Makefile.lammps are
appropriate for your system. If they are not, the LAMMPS build may
fail. To fix this, you can edit or create a new Makefile.lammps.*
file for your system, and copy it to Makefile.lammps.</p>
<p>As explained in the lib/package/README files, the settings in
Makefile.lammps are used to specify additional system libraries and
their locations so that LAMMPS can build with the auxiliary library.
For example, if the MEAM package is used, the auxiliary library
consists of F90 code, built with a Fortran complier. To link that
library with LAMMPS (a C++ code) via whatever C++ compiler LAMMPS is
built with, typically requires additional Fortran-to-C libraries be
included in the link. Another example are the BLAS and LAPACK
libraries needed to use the USER-ATC or USER-AWPMD packages.</p>
<p>For libraries without provided code, the sub-directory README file has
information on where to download the library and how to build it,
e.g. lib/voronoi/README and lib/smd/README. The README files also
describe how you must either (a) create soft links, via the “ln”
command, in those directories to point to where you built or installed
the packages, or (b) check or edit the Makefile.lammps file in the
same directory to provide that information.</p>
<p>Some of the sub-directories, e.g. lib/voronoi, also have an install.py
script which can be used to automate the process of
downloading/building/installing the auxiliary library, and setting the
needed soft links. Type “python install.py” for further instructions.</p>
<p>As with the sub-directories containing library code, if the soft links
or settings in the lib/package/Makefile.lammps files are not correct,
the LAMMPS build will typically fail.</p>
<hr class="docutils" />
-<p id="start-3-4"><a href="#id25"><span class="problematic" id="id26">**</span></a><em>Packages that require Makefile.machine settings</em>**</p>
+<p id="start-3-4"><a href="#id19"><span class="problematic" id="id20">**</span></a><em>Packages that require Makefile.machine settings</em>**</p>
<p>A few packages require specific settings in Makefile.machine, to
either build or use the package effectively. These are the
USER-INTEL, KOKKOS, USER-OMP, and OPT packages, used for accelerating
code performance on CPUs or other hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section acclerate</span></a>.</p>
<p>A summary of what Makefile.machine changes are needed for each of
these packages is given in <a class="reference internal" href="Section_packages.html"><span class="doc">Section packages</span></a>.
The details are given on the doc pages that describe each of these
<p>You can also look at the following machine Makefiles in
src/MAKE/OPTIONS, which include the changes. Note that the USER-INTEL
and KOKKOS packages allow for settings that build LAMMPS for different
hardware. The USER-INTEL package builds for CPU and the Xeon Phi, the
KOKKOS package builds for OpenMP, GPUs (Cuda), and the Xeon Phi.</p>
<ul class="simple">
<li>Makefile.intel_cpu</li>
<li>Makefile.intel_phi</li>
<li>Makefile.kokkos_omp</li>
<li>Makefile.kokkos_cuda</li>
<li>Makefile.kokkos_phi</li>
<li>Makefile.omp</li>
<li>Makefile.opt</li>
</ul>
<p>Also note that the Make.py tool, described in the next <a class="reference internal" href="#start-4"><span class="std std-ref">Section 2.4</span></a> can automatically add the needed info to an existing
machine Makefile, using simple command-line arguments.</p>
+relocation R_X86_64_32 against '__pthread_key_create' can not be used
when making a shared object; recompile with -fPIC
../../lib/colvars/libcolvars.a: error adding symbols: Bad value
-</pre></div>
-</div>
+</pre>
<p>As an example, here is how to build and install the <a class="reference external" href="http://www-unix.mcs.anl.gov/mpi">MPICH library</a>, a popular open-source version of MPI, distributed by
Argonne National Labs, as a shared library in the default
<h3>2.5.4. <strong>Calling the LAMMPS library:</strong></h3>
<p>Either flavor of library (static or shared) allows one or more LAMMPS
objects to be instantiated from the calling program.</p>
<p>When used from a C++ program, all of LAMMPS is wrapped in a LAMMPS_NS
namespace; you can safely use any of its classes and methods from
within the calling code, as needed.</p>
<p>When used from a C or Fortran program or a scripting language like
Python, the library has a simple function-style interface, provided in
src/library.cpp and src/library.h.</p>
<p>See the sample codes in examples/COUPLE/simple for examples of C++ and
C and Fortran codes that invoke LAMMPS thru its library interface.
There are other examples as well in the COUPLE directory which are
discussed in <a class="reference internal" href="Section_howto.html#howto-10"><span class="std std-ref">Section_howto 10</span></a> of the
manual. See <a class="reference internal" href="Section_python.html"><span class="doc">Section_python</span></a> of the manual for a
description of the Python wrapper provided with LAMMPS that operates
through the LAMMPS library interface.</p>
<p>The files src/library.cpp and library.h define the C-style API for
using LAMMPS as a library. See <a class="reference internal" href="Section_howto.html#howto-19"><span class="std std-ref">Section_howto 19</span></a> of the manual for a description of the
interface and how to extend it for your needs.</p>
<p>Explicitly enable or disable KOKKOS support, as provided by the KOKKOS
package. Even if LAMMPS is built with this package, as described
above in <a class="reference internal" href="#start-3"><span class="std std-ref">Section 2.3</span></a>, this switch must be set to enable
running with the KOKKOS-enabled styles the package provides. If the
switch is not set (the default), LAMMPS will operate as if the KOKKOS
package were not installed; i.e. you can run standard LAMMPS or with
the GPU or USER-OMP packages, for testing or benchmarking purposes.</p>
<p>Additional optional keyword/value pairs can be specified which
determine how Kokkos will use the underlying hardware on your
platform. These settings apply to each MPI task you launch via the
“mpirun” or “mpiexec” command. You may choose to run one or more MPI
tasks per physical node. Note that if you are running on a desktop
machine, you typically have one physical node. On a cluster or
supercomputer there may be dozens or 1000s of physical nodes.</p>
<p>Either the full word or an abbreviation can be used for the keywords.
Note that the keywords do not use a leading minus sign. I.e. the
keyword is “t”, not “-t”. Also note that each of the keywords has a
default setting. Example of when to use these options and what
settings to use on different platforms is given in <a class="reference internal" href="Section_accelerate.html#acc-3"><span class="std std-ref">Section 5.8</span></a>.</p>
<p>Use variants of various styles if they exist. The specified style can
be <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, <em>opt</em>, or <em>hybrid</em>. These
refer to optional packages that LAMMPS can be built with, as described
above in <a class="reference internal" href="#start-3"><span class="std std-ref">Section 2.3</span></a>. The “gpu” style corresponds to the
GPU package, the “intel” style to the USER-INTEL package, the “kk”
style to the KOKKOS package, the “opt” style to the OPT package, and
the “omp” style to the USER-OMP package. The hybrid style is the only
style that accepts arguments. It allows for two packages to be
specified. The first package specified is the default and will be used
if it is available. If no style is available for the first package,
the style for the second package will be used if available. For
example, “-suffix hybrid intel omp” will use styles from the
USER-INTEL package if they are installed and available, but styles for
the USER-OMP package otherwise.</p>
<p>Along with the “-package” command-line switch, this is a convenient
mechanism for invoking accelerator packages and their options without
having to edit an input script.</p>
<p>As an example, all of the packages provide a <a class="reference internal" href="pair_lj.html"><span class="doc">pair_style lj/cut</span></a> variant, with style names lj/cut/gpu,
lj/cut/intel, lj/cut/kk, lj/cut/omp, and lj/cut/opt. A variant style
can be specified explicitly in your input script, e.g. pair_style
lj/cut/gpu. If the -suffix switch is used the specified suffix
(gpu,intel,kk,omp,opt) is automatically appended whenever your input
script command creates a new <a class="reference internal" href="atom_style.html"><span class="doc">atom</span></a>,
<a class="reference internal" href="run_style.html"><span class="doc">run</span></a> style. If the variant version does not exist,
the standard version is created.</p>
<p>For the GPU package, using this command-line switch also invokes the
default GPU settings, as if the command “package gpu 1” were used at
the top of your input script. These settings can be changed by using
the “-package gpu” command-line switch or the <a class="reference internal" href="package.html"><span class="doc">package gpu</span></a> command in your script.</p>
<p>For the USER-INTEL package, using this command-line switch also
invokes the default USER-INTEL settings, as if the command “package
intel 1” were used at the top of your input script. These settings
can be changed by using the “-package intel” command-line switch or
the <a class="reference internal" href="package.html"><span class="doc">package intel</span></a> command in your script. If the
USER-OMP package is also installed, the hybrid style with “intel omp”
arguments can be used to make the omp suffix a second choice, if a
requested style is not available in the USER-INTEL package. It will
also invoke the default USER-OMP settings, as if the command “package
omp 0” were used at the top of your input script. These settings can
be changed by using the “-package omp” command-line switch or the
<a class="reference internal" href="package.html"><span class="doc">package omp</span></a> command in your script.</p>
<p>For the KOKKOS package, using this command-line switch also invokes
the default KOKKOS settings, as if the command “package kokkos” were
used at the top of your input script. These settings can be changed
by using the “-package kokkos” command-line switch or the <a class="reference internal" href="package.html"><span class="doc">package kokkos</span></a> command in your script.</p>
<p>For the OMP package, using this command-line switch also invokes the
default OMP settings, as if the command “package omp 0” were used at
the top of your input script. These settings can be changed by using
the “-package omp” command-line switch or the <a class="reference internal" href="package.html"><span class="doc">package omp</span></a> command in your script.</p>
<p>The <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command can also be used within an input
script to set a suffix, or to turn off or back on any suffix setting
<p>Specify a variable that will be defined for substitution purposes when
the input script is read. This switch can be used multiple times to
define multiple variables. “Name” is the variable name which can be a
single character (referenced as $x in the input script) or a full
string (referenced as ${abc}). An <a class="reference internal" href="variable.html"><span class="doc">index-style variable</span></a> will be created and populated with the
subsequent values, e.g. a set of filenames. Using this command-line
option is equivalent to putting the line “variable name index value1
value2 ...” at the beginning of the input script. Defining an index
variable as a command-line argument overrides any setting for the same
index variable in the input script, since index variables cannot be
re-defined. See the <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command for more info on
defining index and other kinds of variables and <a class="reference internal" href="Section_commands.html#cmd-2"><span class="std std-ref">this section</span></a> for more info on using variables
in input scripts.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Currently, the command-line parser looks for arguments that
start with “-” to indicate new switches. Thus you cannot specify
multiple variable values if any of they start with a “-”, e.g. a
negative numeric value. It is OK if the first value1 starts with a
“-”, since it is automatically skipped.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>LAMMPS is designed to be a computational kernel for performing
molecular dynamics computations. Additional pre- and post-processing
steps are often necessary to setup and analyze a simulation. A few
additional tools are provided with the LAMMPS distribution and are
described in this section.</p>
<p>Our group has also written and released a separate toolkit called
<a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</a> which provides tools for doing setup, analysis,
plotting, and visualization for LAMMPS simulations. Pizza.py is
written in <a class="reference external" href="http://www.python.org">Python</a> and is available for download from <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">the Pizza.py WWW site</a>.</p>
<p>Note that many users write their own setup or analysis tools or use
other existing codes and convert their output to a LAMMPS input format
or vice versa. The tools listed here are included in the LAMMPS
distribution as examples of auxiliary tools. Some of them are not
actively supported by Sandia, as they were contributed by LAMMPS
users. If you have problems using them, we can direct you to the
authors.</p>
<p>The source code for each of these codes is in the tools sub-directory
of the LAMMPS distribution. There is a Makefile (which you may need
to edit for your platform) which will build several of the tools which
reside in that directory. Some of them are larger packages in their
Zr. The files can then be used with the <a class="reference internal" href="pair_eam.html"><span class="doc">pair_style eam/alloy</span></a> command.</p>
<p>The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov,
and is based on his paper:</p>
<p>X. W. Zhou, R. A. Johnson, and H. N. G. Wadley, Phys. Rev. B, 69,
144113 (2004).</p>
<hr class="docutils" />
</div>
<div class="section" id="eam-generate-tool">
<span id="eamgn"></span><h2>9.9. eam generate tool</h2>
<p>The tools/eam_generate directory contains several one-file C programs
that convert an analytic formula into a tabulated <a class="reference internal" href="pair_eam.html"><span class="doc">embedded atom method (EAM)</span></a> setfl potential file. The potentials they
produce are in the potentials directory, and can be used with the
<p>The source files and potentials were provided by Gerolf Ziegenhain
(gerolf at ziegenhain.com).</p>
<hr class="docutils" />
</div>
<div class="section" id="eff-tool">
<span id="eff"></span><h2>9.10. eff tool</h2>
<p>The tools/eff directory contains various scripts for generating
structures and post-processing output for simulations using the
electron force field (eFF).</p>
<p>These tools were provided by Andres Jaramillo-Botero at CalTech
(ajaramil at wag.caltech.edu).</p>
<hr class="docutils" />
</div>
<div class="section" id="emacs-tool">
<span id="emacs"></span><h2>9.11. emacs tool</h2>
<p>The tools/emacs directory contains a Lips add-on file for Emacs that
enables a lammps-mode for editing of input scripts when using Emacs,
with various highlighting options setup.</p>
<p>These tools were provided by Aidan Thompson at Sandia
(athomps at sandia.gov).</p>
<hr class="docutils" />
</div>
<div class="section" id="fep-tool">
<span id="fep"></span><h2>9.12. fep tool</h2>
<p>The tools/fep directory contains Python scripts useful for
post-processing results from performing free-energy perturbation
simulations using the USER-FEP package.</p>
<p>The scripts were contributed by Agilio Padua (Universite Blaise
Pascal Clermont-Ferrand), agilio.padua at univ-bpclermont.fr.</p>
<p>See README file in the tools/fep directory.</p>
<hr class="docutils" />
</div>
<div class="section" id="i-pi-tool">
<span id="ipi"></span><h2>9.13. i-pi tool</h2>
<p>The tools/i-pi directory contains a version of the i-PI package, with
all the LAMMPS-unrelated files removed. It is provided so that it can
be used with the <a class="reference internal" href="fix_ipi.html"><span class="doc">fix ipi</span></a> command to perform
path-integral molecular dynamics (PIMD).</p>
<p>The i-PI package was created and is maintained by Michele Ceriotti,
michele.ceriotti at gmail.com, to interface to a variety of molecular
dynamics codes.</p>
<p>See the tools/i-pi/manual.pdf file for an overview of i-PI, and the
<a class="reference internal" href="fix_ipi.html"><span class="doc">fix ipi</span></a> doc page for further details on running PIMD
calculations with LAMMPS.</p>
<hr class="docutils" />
</div>
<div class="section" id="ipp-tool">
<span id="ipp"></span><h2>9.14. ipp tool</h2>
<p>The tools/ipp directory contains a Perl script ipp which can be used
to facilitate the creation of a complicated file (say, a lammps input
script or tools/createatoms input file) using a template file.</p>
<p>ipp was created and is maintained by Reese Jones (Sandia), rjones at
sandia.gov.</p>
<p>See two examples in the tools/ipp directory. One of them is for the
tools/createatoms tool’s input file.</p>
<hr class="docutils" />
</div>
<div class="section" id="kate-tool">
<span id="kate"></span><h2>9.15. kate tool</h2>
<p>The file in the tools/kate directory is an add-on to the Kate editor
in the KDE suite that allow syntax highlighting of LAMMPS input
scripts. See the README.txt file for details.</p>
<p>The file was provided by Alessandro Luigi Sellerio
(alessandro.sellerio at ieni.cnr.it).</p>
<hr class="docutils" />
</div>
<div class="section" id="lmp2arc-tool">
<span id="arc"></span><h2>9.16. lmp2arc tool</h2>
<p>The lmp2arc sub-directory contains a tool for converting LAMMPS output
files to the format for Accelrys’ Insight MD code (formerly
MSI/Biosym and its Discover MD code). See the README file for more
information.</p>
<p>This tool was written by John Carpenter (Cray), Michael Peachey
(Cray), and Steve Lustig (Dupont). John is now at the Mayo Clinic
(jec at mayo.edu), but still fields questions about the tool.</p>
<p>This tool was updated for the current LAMMPS C++ version by Jeff
Greathouse at Sandia (jagreat at sandia.gov).</p>
<hr class="docutils" />
</div>
<div class="section" id="lmp2cfg-tool">
<span id="cfg"></span><h2>9.17. lmp2cfg tool</h2>
<p>The lmp2cfg sub-directory contains a tool for converting LAMMPS output
-files into a series of <a href="#id1"><span class="problematic" id="id2">*</span></a>.cfg files which can be read into the
+files into a series of *.cfg files which can be read into the
<a class="reference external" href="http://mt.seas.upenn.edu/Archive/Graphics/A">AtomEye</a> visualizer. See
the README file for more information.</p>
<p>This tool was written by Ara Kooser at Sandia (askoose at sandia.gov).</p>
<hr class="docutils" />
</div>
<div class="section" id="lmp2vmd-tool">
<span id="vmd"></span><h2>9.18. lmp2vmd tool</h2>
<p>The lmp2vmd sub-directory contains a README.txt file that describes
details of scripts and plugin support within the <a class="reference external" href="http://www.ks.uiuc.edu/Research/vmd">VMD package</a> for visualizing LAMMPS
dump files.</p>
<p>The VMD plugins and other supporting scripts were written by Axel
Kohlmeyer (akohlmey at cmm.chem.upenn.edu) at U Penn.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>You must also use the <a class="reference internal" href="package.html"><span class="doc">package gpu</span></a> command to enable the
GPU package, unless the “-sf gpu” or “-pk gpu” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switches</span></a> were used. It specifies the
number of GPUs/node to use, as well as other options.</p>
<p><strong>Speed-ups to expect:</strong></p>
<p>The performance of a GPU versus a multi-core CPU is a function of your
hardware, which pair style is used, the number of atoms/GPU, and the
precision used on the GPU (double, single, mixed).</p>
<p>See the <a class="reference external" href="http://lammps.sandia.gov/bench.html">Benchmark page</a> of the
LAMMPS web site for performance of the GPU package on various
hardware, including the Titan HPC platform at ORNL.</p>
<p>You should also experiment with how many MPI tasks per GPU to use to
give the best performance for your problem and machine. This is also
a function of the problem size and the pair style being using.
Likewise, you should experiment with the precision setting for the GPU
library to see if single or mixed precision will give accurate
results, since they will typically be faster.</p>
<p><strong>Guidelines for best performance:</strong></p>
<ul class="simple">
<li>Using multiple MPI tasks per GPU will often give the best performance,
as allowed my most multi-core CPU/GPU configurations.</li>
<li>If the number of particles per MPI task is small (e.g. 100s of
particles), it can be more efficient to run with fewer MPI tasks per
GPU, even if you do not use all the cores on the compute node.</li>
<li>The <a class="reference internal" href="package.html"><span class="doc">package gpu</span></a> command has several options for tuning
performance. Neighbor lists can be built on the GPU or CPU. Force
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 <a class="reference internal" href="package.html"><span class="doc">packakge</span></a> command
doc page for details.</li>
<li>As described by the <a class="reference internal" href="package.html"><span class="doc">package gpu</span></a> command, GPU
accelerated pair styles can perform computations asynchronously with
CPU computations. The “Pair” time reported by LAMMPS will be the
maximum of the time required to complete the CPU pair style
computations and the time required to complete the GPU pair style
computations. Any time spent for GPU-enabled pair styles for
computations that run simultaneously with <a class="reference internal" href="bond_style.html"><span class="doc">bond</span></a>,
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Results are speedups obtained on Intel Xeon E5-2697v4 processors
(code-named Broadwell) and Intel Xeon Phi 7250 processors
(code-named Knights Landing) with “18 Jun 2016” LAMMPS built with
Intel Parallel Studio 2016 update 3. Results are with 1 MPI task
per physical core. See <em>src/USER-INTEL/TEST/README</em> for the raw
simulation rates and instructions to reproduce.</p>
<hr class="docutils" />
<p><strong>Quick Start for Experienced Users:</strong></p>
<p>LAMMPS should be built with the USER-INTEL package installed.
Simulations should be run with 1 MPI task per physical <em>core</em>,
not <em>hardware thread</em>.</p>
<p>For Intel Xeon CPUs:</p>
<ul class="simple">
<li>Edit src/MAKE/OPTIONS/Makefile.intel_cpu_intelmpi as necessary.</li>
<li>If using <em>kspace_style pppm</em> in the input script, add “neigh_modify binsize 3” and “kspace_modify diff ad” to the input script for better
+mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script -pk intel 0 omp 2 mode double # Don't use any coprocessors that might be available, use 2 OpenMP threads for each task, use double precision
+</pre>
<p><strong>Or run with the USER-INTEL package by editing an input script:</strong></p>
<p>As an alternative to adding command-line arguments, the input script
can be edited to enable the USER-INTEL package. This requires adding
the <a class="reference internal" href="package.html"><span class="doc">package intel</span></a> command to the top of the input
script. For the second example above, this would be:</p>
<p>Alternatively, the <a class="reference internal" href="suffix.html"><span class="doc">suffix intel</span></a> command can be added to
the input script to enable USER-INTEL styles for the commands that
follow in the input script.</p>
<p><strong>Tuning for Performance:</strong></p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The USER-INTEL package will perform better with modifications
to the input script when <a class="reference internal" href="kspace_style.html"><span class="doc">PPPM</span></a> is used:
<a class="reference internal" href="kspace_modify.html"><span class="doc">kspace_modify diff ad</span></a> and <a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify binsize 3</span></a> should be added to the input script.</p>
</div>
<p>Long-Range Thread (LRT) mode is an option to the <a class="reference internal" href="package.html"><span class="doc">package intel</span></a> command that can improve performance when using
<a class="reference internal" href="kspace_style.html"><span class="doc">PPPM</span></a> for long-range electrostatics on processors
with SMT. It generates an extra pthread for each MPI task. The thread
is dedicated to performing some of the PPPM calculations and MPI
communications. On Intel Xeon Phi x200 series CPUs, this will likely
always improve performance, even on a single node. On Intel Xeon
processors, using this mode might result in better performance when
using multiple nodes, depending on the machine. To use this mode,
specify that the number of OpenMP threads is one less than would
normally be used for the run and add the “lrt yes” option to the “-pk”
command-line suffix or “package intel” command. For example, if a run
would normally perform best with “-pk intel 0 omp 4”, instead use
“-pk intel 0 omp 3 lrt yes”. When using LRT, you should set the
environment variable “KMP_AFFINITY=none”. LRT mode is not supported
when using offload.</p>
<p>Not all styles are supported in the USER-INTEL package. You can mix
the USER-INTEL package with styles from the <a class="reference internal" href="accelerate_opt.html"><span class="doc">OPT</span></a>
package or the <a class="reference external" href="accelerate_omp.html"">USER-OMP package</a>. Of course,
this requires that these packages were installed at build time. This
can performed automatically by using “-sf hybrid intel opt” or
“-sf hybrid intel omp” command-line options. Alternatively, the “opt”
and “omp” suffixes can be appended manually in the input script. For
the latter, the <a class="reference internal" href="package.html"><span class="doc">package omp</span></a> command must be in the
input script or the “-pk omp Nt” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> must be used where Nt is the
number of OpenMP threads. The number of OpenMP threads should not be
set differently for the different packages. Note that the <a class="reference internal" href="suffix.html"><span class="doc">suffix hybrid intel omp</span></a> command can also be used within the
input script to automatically append the “omp” suffix to styles when
USER-INTEL styles are not available.</p>
<p>When running on many nodes, performance might be better when using
fewer OpenMP threads and more MPI tasks. This will depend on the
simulation and the machine. Using the <a class="reference internal" href="run_style.html"><span class="doc">verlet/split</span></a>
run style might also give better performance for simulations with
<a class="reference internal" href="kspace_style.html"><span class="doc">PPPM</span></a> electrostatics. Note that this is an
alternative to LRT mode and the two cannot be used together.</p>
<p>Currently, when using Intel MPI with Intel Xeon Phi x200 series
CPUs, better performance might be obtained by setting the
environment variable “I_MPI_SHM_LMT=shm” for Linux kernels that do
not yet have full support for AVX-512. Runs on Intel Xeon Phi x200
series processors will always perform better using MCDRAM. Please
consult your system documentation for the best approach to specify
that MPI runs are performed in MCDRAM.</p>
<p><strong>Tuning for Offload Performance:</strong></p>
<p>The default settings for offload should give good performance.</p>
<p>When using LAMMPS with offload to Intel coprocessors, best performance
will typically be achieved with concurrent calculations performed on
both the CPU and the coprocessor. This is achieved by offloading only
a fraction of the neighbor and pair computations to the coprocessor or
using <a class="reference internal" href="pair_hybrid.html"><span class="doc">hybrid</span></a> pair styles where only one style uses
the “intel” suffix. For simulations with long-range electrostatics or
bond, angle, dihedral, improper calculations, computation and data
transfer to the coprocessor will run concurrently with computations
and MPI communications for these calculations on the host CPU. This
is illustrated in the figure below for the rhodopsin protein benchmark
running on E5-2697v2 processors with a Intel Xeon Phi 7120p
coprocessor. In this plot, the vertical access is time and routines
running at the same time are running concurrently on both the host and
<p>The fraction of the offloaded work is controlled by the <em>balance</em>
keyword in the <a class="reference internal" href="package.html"><span class="doc">package intel</span></a> command. A balance of 0
runs all calculations on the CPU. A balance of 1 runs all
supported calculations on the coprocessor. A balance of 0.5 runs half
of the calculations on the coprocessor. Setting the balance to -1
(the default) will enable dynamic load balancing that continously
adjusts the fraction of offloaded work throughout the simulation.
Because data transfer cannot be timed, this option typically produces
results within 5 to 10 percent of the optimal fixed balance.</p>
<p>If running short benchmark runs with dynamic load balancing, adding a
short warm-up run (10-20 steps) will allow the load-balancer to find a
near-optimal setting that will carry over to additional runs.</p>
<p>The default for the <a class="reference internal" href="package.html"><span class="doc">package intel</span></a> command is to have
all the MPI tasks on a given compute node use a single Xeon Phi
coprocessor. In general, running with a large number of MPI tasks on
each node will perform best with offload. Each MPI task will
automatically get affinity to a subset of the hardware threads
available on the coprocessor. For example, if your card has 61 cores,
with 60 cores available for offload and 4 hardware threads per core
(240 total threads), running with 24 MPI tasks per node will cause
each MPI task to use a subset of 10 threads on the coprocessor. Fine
tuning of the number of threads to use per MPI task or the number of
threads to use per core can be accomplished with keyword settings of
the <a class="reference internal" href="package.html"><span class="doc">package intel</span></a> command.</p>
<p>The USER-INTEL package has two modes for deciding which atoms will be
handled by the coprocessor. This choice is controlled with the <em>ghost</em>
keyword of the <a class="reference internal" href="package.html"><span class="doc">package intel</span></a> command. When set to 0,
ghost atoms (atoms at the borders between MPI tasks) are not offloaded
to the card. This allows for overlap of MPI communication of forces
with computation on the coprocessor when the <a class="reference internal" href="newton.html"><span class="doc">newton</span></a>
setting is “on”. The default is dependent on the style being used,
however, better performance may be achieved by setting this option
explictly.</p>
<p>When using offload with CPU Hyper-Threading disabled, it may help
performance to use fewer MPI tasks and OpenMP threads than available
cores. This is due to the fact that additional threads are generated
internally to handle the asynchronous offload tasks.</p>
<p>If pair computations are being offloaded to an Intel Xeon Phi
coprocessor, a diagnostic line is printed to the screen (not to the
log file), during the setup phase of a run, indicating that offload
mode is being used and indicating the number of coprocessor threads
per MPI task. Additionally, an offload timing summary is printed at
the end of each run. When offloading, the frequency for <a class="reference internal" href="atom_modify.html"><span class="doc">atom sorting</span></a> is changed to 1 so that the per-atom data is
effectively sorted at every rebuild of the neighbor lists. All the
available coprocessor threads on each Phi will be divided among MPI
tasks, unless the <em>tptask</em> option of the “-pk intel” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> is used to limit the coprocessor
threads per MPI task.</p>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>When offloading to a coprocessor, <a class="reference internal" href="pair_hybrid.html"><span class="doc">hybrid</span></a> styles
that require skip lists for neighbor builds cannot be offloaded.
Using <a class="reference internal" href="pair_hybrid.html"><span class="doc">hybrid/overlay</span></a> is allowed. Only one intel
accelerated style may be used with hybrid styles.
<a class="reference internal" href="special_bonds.html"><span class="doc">Special_bonds</span></a> exclusion lists are not currently
supported with offload, however, the same effect can often be
accomplished by setting cutoffs for excluded atom types to 0. None of
the pair styles in the USER-INTEL package currently support the
“inner”, “middle”, “outer” options for rRESPA integration via the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command; only the “pair” option is
supported.</p>
<p><strong>References:</strong></p>
<ul class="simple">
<li>Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakker, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., “Optimizing Classical Molecular Dynamics in LAMMPS,” in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann.</li>
<li>Brown, W. M., Semin, A., Hebenstreit, M., Khvostov, S., Raman, K., Plimpton, S.J. Increasing Molecular Dynamics Simulation Rates with an 8-Fold Increase in Electrical Power Efficiency. 2016 International Conference for High Performance Computing. In press.</li>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
respectively. Or the effect of the “-pk” or “-sf” switches can be
duplicated by adding the <a class="reference internal" href="package.html"><span class="doc">package kokkos</span></a> or <a class="reference internal" href="suffix.html"><span class="doc">suffix kk</span></a> commands respectively to your input script.</p>
<p>Or you can follow these steps:</p>
<p>CPU-only (run all-MPI or with OpenMP threading):</p>
<p>KOKKOS_DEVICE sets the parallelization method used for Kokkos code
(within LAMMPS). KOKKOS_DEVICES=OpenMP means that OpenMP will be
used. KOKKOS_DEVICES=Pthreads means that pthreads will be used.
KOKKOS_DEVICES=Cuda means an NVIDIA GPU running CUDA will be used.</p>
<p>If KOKKOS_DEVICES=Cuda, then the lo-level Makefile in the src/MAKE
directory must use “nvcc” as its compiler, via its CC setting. For
best performance its CCFLAGS setting should use -O3 and have a
KOKKOS_ARCH setting that matches the compute capability of your NVIDIA
hardware and software installation, e.g. KOKKOS_ARCH=Kepler30. Note
the minimal required compute capability is 2.0, but this will give
signicantly reduced performance compared to Kepler generation GPUs
with compute capability 3.x. For the LINK setting, “nvcc” should not
be used; instead use g++ or another compiler suitable for linking C++
applications. Often you will want to use your MPI compiler wrapper
for this setting (i.e. mpicxx). Finally, the lo-level Makefile must
-also have a “Compilation rule” for creating <a href="#id1"><span class="problematic" id="id2">*</span></a>.o files from <a href="#id3"><span class="problematic" id="id4">*</span></a>.cu files.
+also have a “Compilation rule” for creating *.o files from *.cu files.
See src/Makefile.cuda for an example of a lo-level Makefile with all
of these settings.</p>
<p>KOKKOS_USE_TPLS=hwloc binds threads to hardware cores, so they do not
migrate during a simulation. KOKKOS_USE_TPLS=hwloc should always be
used if running with KOKKOS_DEVICES=Pthreads for pthreads. It is not
necessary for KOKKOS_DEVICES=OpenMP for OpenMP, because OpenMP
provides alternative methods via environment variables for binding
threads to hardware cores. More info on binding threads to cores is
given in <a class="reference internal" href="Section_accelerate.html#acc-3"><span class="std std-ref">this section</span></a>.</p>
<p>KOKKOS_ARCH=KNC enables compiler switches needed when compling for an
Intel Phi processor.</p>
<p>KOKKOS_USE_TPLS=librt enables use of a more accurate timer mechanism
on most Unix platforms. This library is not available on all
platforms.</p>
<p>KOKKOS_DEBUG is only useful when developing a Kokkos-enabled style
within LAMMPS. KOKKOS_DEBUG=yes enables printing of run-time
debugging information that can be useful. It also enables runtime
bounds checking on Kokkos data structures.</p>
<p>KOKKOS_CUDA_OPTIONS are additional options for CUDA.</p>
<p>For more information on Kokkos see the Kokkos programmers’ guide here:
/lib/kokkos/doc/Kokkos_PG.pdf.</p>
<p><strong>Run with the KOKKOS package from the command line:</strong></p>
<p>The mpirun or mpiexec command sets the total number of MPI tasks used
by LAMMPS (one or multiple per compute node) and the number of MPI
tasks used per node. E.g. the mpirun command in MPICH does this via
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.</p>
<p>When using KOKKOS built with host=OMP, you need to choose how many
OpenMP threads per MPI task will be used (via the “-k” command-line
switch discussed below). Note that the product of MPI tasks * OpenMP
threads/task should not exceed the physical number of cores (on a
node), otherwise performance will suffer.</p>
<p>When using the KOKKOS package built with device=CUDA, you must use
exactly one MPI task per physical GPU.</p>
<p>When using the KOKKOS package built with host=MIC for Intel Xeon Phi
coprocessor support you need to insure there are one or more MPI tasks
per coprocessor, and choose the number of coprocessor threads to use
per MPI task (via the “-k” command-line switch discussed below). The
product of MPI tasks * coprocessor threads/task should not exceed the
maximum number of threads the coproprocessor is designed to run,
otherwise performance will suffer. This value is 240 for current
generation Xeon Phi(TM) chips, which is 60 physical cores * 4
threads/core. Note that with the KOKKOS package you do not need to
specify how many Phi coprocessors there are per node; each
coprocessors is simply treated as running some number of MPI tasks.</p>
<p>You must use the “-k on” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> to enable the KOKKOS package. It
takes additional arguments for hardware settings appropriate to your
system. Those arguments are <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">documented here</span></a>. The two most commonly used
which will automatically append “kk” to styles that support it. Use
the “-pk kokkos” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> if
you wish to change any of the default <a class="reference internal" href="package.html"><span class="doc">package kokkos</span></a>
optionns set by the “-k on” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>.</p>
<p>Note that the default for the <a class="reference internal" href="package.html"><span class="doc">package kokkos</span></a> command is
to use “full” neighbor lists and set the Newton flag to “off” for both
pairwise and bonded interactions. This typically gives fastest
performance. If the <a class="reference internal" href="newton.html"><span class="doc">newton</span></a> command is used in the input
script, it can override the Newton flag defaults.</p>
<p>However, when running in MPI-only mode with 1 thread per MPI task, it
will typically be faster to use “half” neighbor lists and set the
Newton flag to “on”, just as is the case for non-accelerated pair
styles. You can do this with the “-pk” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>.</p>
<p><strong>Or run with the KOKKOS package by editing an input script:</strong></p>
<p>The discussion above for the mpirun/mpiexec command and setting
appropriate thread and GPU values for host=OMP or host=MIC or
device=CUDA are the same.</p>
<p>You must still use the “-k on” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> to enable the KOKKOS package, and
specify its additional arguments for hardware options appopriate to
your system, as documented above.</p>
<p>Use the <a class="reference internal" href="suffix.html"><span class="doc">suffix kk</span></a> command, or you can explicitly add a
“kk” suffix to individual styles in your input script, e.g.</p>
<p>The performance of KOKKOS running in different modes is a function of
your hardware, which KOKKOS-enable styles are used, and the problem
size.</p>
<p>Generally speaking, the following rules of thumb apply:</p>
<ul class="simple">
<li>When running on CPUs only, with a single thread per MPI task,
performance of a KOKKOS style is somewhere between the standard
(un-accelerated) styles (MPI-only mode), and those provided by the
USER-OMP package. However the difference between all 3 is small (less
than 20%).</li>
<li>When running on CPUs only, with multiple threads per MPI task,
performance of a KOKKOS style is a bit slower than the USER-OMP
package.</li>
<li>When running large number of atoms per GPU, KOKKOS is typically faster
than the GPU package.</li>
<li>When running on Intel Xeon Phi, KOKKOS is not as fast as
the USER-INTEL package, which is optimized for that hardware.</li>
</ul>
<p>See the <a class="reference external" href="http://lammps.sandia.gov/bench.html">Benchmark page</a> of the
LAMMPS web site for performance of the KOKKOS package on different
hardware.</p>
<p><strong>Guidelines for best performance:</strong></p>
<p>Here are guidline for using the KOKKOS package on the different
hardware configurations listed above.</p>
<p>Many of the guidelines use the <a class="reference internal" href="package.html"><span class="doc">package kokkos</span></a> command
See its doc page for details and default settings. Experimenting with
its options can provide a speed-up for specific calculations.</p>
<p><strong>Running on a multi-core CPU:</strong></p>
<p>If N is the number of physical cores/node, then the number of MPI
tasks/node * number of threads/task should not exceed N, and should
typically equal N. Note that the default threads/task is 1, as set by
the “t” keyword of the “-k” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>. If you do not change this, no
additional parallelism (beyond MPI) will be invoked on the host
CPU(s).</p>
<p>You can compare the performance running in different modes:</p>
<ul class="simple">
<li>run with 1 MPI task/node and N threads/task</li>
<li>run with N MPI tasks/node and 1 thread/task</li>
<li>run with settings in between these extremes</li>
</ul>
<p>Examples of mpirun commands in these modes are shown above.</p>
<p>When using KOKKOS to perform multi-threading, it is important for
performance to bind both MPI tasks to physical cores, and threads to
physical cores, so they do not migrate during a simulation.</p>
<p>If you are not certain MPI tasks are being bound (check the defaults
for your MPI installation), binding can be forced with these flags:</p>
<p>For binding threads with the KOKKOS OMP option, use thread affinity
environment variables to force binding. With OpenMP 3.1 (gcc 4.7 or
later, intel 12 or later) setting the environment variable
OMP_PROC_BIND=true should be sufficient. For binding threads with the
KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option, as
discussed in <a class="reference internal" href="Section_start.html#start-3-4"><span class="std std-ref">Section 2.3.4</span></a> of the
manual.</p>
<p><strong>Running on GPUs:</strong></p>
<p>Insure the -arch setting in the machine makefile you are using,
e.g. src/MAKE/Makefile.cuda, is correct for your GPU hardware/software
(see <a class="reference internal" href="Section_start.html#start-3-4"><span class="std std-ref">this section</span></a> of the manual for
details).</p>
<p>The -np setting of the mpirun command should set the number of MPI
tasks/node to be equal to the # of physical GPUs on the node.</p>
<p>Use the “-k” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> to
specify the number of GPUs per node, and the number of threads per MPI
task. As above for multi-core CPUs (and no GPU), if N is the number
of physical cores/node, then the number of MPI tasks/node * number of
threads/task should not exceed N. With one GPU (and one MPI task) it
may be faster to use less than all the available cores, by setting
threads/task to a smaller value. This is because using all the cores
on a dual-socket node will incur extra cost to copy memory from the
2nd socket to the GPU.</p>
<p>Examples of mpirun commands that follow these rules are shown above.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When using a GPU, you will achieve the best performance if your
input script does not use any fix or compute styles which are not yet
Kokkos-enabled. This allows data to stay on the GPU for multiple
timesteps, without being copied back to the host CPU. Invoking a
non-Kokkos fix or compute, or performing I/O for
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo</span></a> or <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> output will cause data
to be copied back to the CPU.</p>
</div>
<p>You cannot yet assign multiple MPI tasks to the same GPU with the
KOKKOS package. We plan to support this in the future, similar to the
GPU package in LAMMPS.</p>
<p>You cannot yet use both the host (multi-threaded) and device (GPU)
together to compute pairwise interactions with the KOKKOS package. We
hope to support this in the future, similar to the GPU package in
LAMMPS.</p>
<p><strong>Running on an Intel Phi:</strong></p>
<p>Kokkos only uses Intel Phi processors in their “native” mode, i.e.
not hosted by a CPU.</p>
<p>As illustrated above, build LAMMPS with OMP=yes (the default) and
MIC=yes. The latter insures code is correctly compiled for the Intel
Phi. The OMP setting means OpenMP will be used for parallelization on
the Phi, which is currently the best option within Kokkos. In the
future, other options may be added.</p>
<p>Current-generation Intel Phi chips have either 61 or 57 cores. One
core should be excluded for running the OS, leaving 60 or 56 cores.
Each core is hyperthreaded, so there are effectively N = 240 (4*60) or
N = 224 (4*56) cores to run on.</p>
<p>The -np setting of the mpirun command sets the number of MPI
tasks/node. The “-k on t Nt” command-line switch sets the number of
threads/task as Nt. The product of these 2 values should be N, i.e.
240 or 224. Also, the number of threads/task should be a multiple of
4 so that logical threads from more than one MPI task do not run on
the same physical core.</p>
<p>Examples of mpirun commands that follow these rules are shown above.</p>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>As noted above, if using GPUs, the number of MPI tasks per compute
node should equal to the number of GPUs per compute node. In the
future Kokkos will support assigning multiple MPI tasks to a single
GPU.</p>
<p>Currently Kokkos does not support AMD GPUs due to limits in the
available backend programming models. Specifically, Kokkos requires
extensive C++ support from the Kernel language. This is expected to
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Your compiler must support the OpenMP interface. You should have one
or more multi-core CPUs so that multiple threads can be launched by
each MPI task running on a CPU.</p>
<p><strong>Building LAMMPS with the USER-OMP package:</strong></p>
<p>The lines above illustrate how to include/build with the USER-OMP
package in two steps, using the “make” command. Or how to do it with
one command via the src/Make.py script, described in <a class="reference internal" href="Section_start.html#start-4"><span class="std std-ref">Section 2.4</span></a> of the manual. Type “Make.py -h” for
help.</p>
<p>Note that the CCFLAGS and LINKFLAGS settings in Makefile.machine must
include “-fopenmp”. Likewise, if you use an Intel compiler, the
CCFLAGS setting must include “-restrict”. The Make.py command will
add these automatically.</p>
<p><strong>Run with the USER-OMP package from the command line:</strong></p>
<p>The mpirun or mpiexec command sets the total number of MPI tasks used
by LAMMPS (one or multiple per compute node) and the number of MPI
tasks used per node. E.g. the mpirun command in MPICH does this via
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.</p>
<p>You need to choose how many OpenMP threads per MPI task will be used
by the USER-OMP package. Note that the product of MPI tasks *
threads/task should not exceed the physical number of cores (on a
node), otherwise performance will suffer.</p>
<p>As in the lines above, use the “-sf omp” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>, which will automatically append
“omp” to styles that support it. The “-sf omp” switch also issues a
default <a class="reference internal" href="package.html"><span class="doc">package omp 0</span></a> command, which will set the
number of threads per MPI task via the OMP_NUM_THREADS environment
variable.</p>
<p>You can also use the “-pk omp Nt” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>, to explicitly set Nt = # of OpenMP
threads per MPI task to use, as well as additional options. Its
syntax is the same as the <a class="reference internal" href="package.html"><span class="doc">package omp</span></a> command whose doc
page gives details, including the default values used if it is not
specified. It also gives more details on how to set the number of
threads via the OMP_NUM_THREADS environment variable.</p>
<p><strong>Or run with the USER-OMP package by editing an input script:</strong></p>
<p>The discussion above for the mpirun/mpiexec command, MPI tasks/node,
and threads/MPI task is the same.</p>
<p>Use the <a class="reference internal" href="suffix.html"><span class="doc">suffix omp</span></a> command, or you can explicitly add an
“omp” suffix to individual styles in your input script, e.g.</p>
<p>You must also use the <a class="reference internal" href="package.html"><span class="doc">package omp</span></a> command to enable the
USER-OMP package. When you do this you also specify how many threads
per MPI task to use. The command doc page explains other options and
how to set the number of threads via the OMP_NUM_THREADS environment
variable.</p>
<p><strong>Speed-ups to expect:</strong></p>
<p>Depending on which styles are accelerated, you should look for a
reduction in the “Pair time”, “Bond time”, “KSpace time”, and “Loop
time” values printed at the end of a run.</p>
<p>You may see a small performance advantage (5 to 20%) when running a
USER-OMP style (in serial or parallel) with a single thread per MPI
task, versus running standard LAMMPS with its standard un-accelerated
styles (in serial or all-MPI parallelization with 1 task/core). This
is because many of the USER-OMP styles contain similar optimizations
to those used in the OPT package, described in <a class="reference internal" href="accelerate_opt.html"><span class="doc">Section accelerate 5.3.6</span></a>.</p>
<p>With multiple threads/task, the optimal choice of number of MPI
tasks/node and OpenMP threads/task can vary a lot and should always be
tested via benchmark runs for a specific simulation running on a
specific machine, paying attention to guidelines discussed in the next
sub-section.</p>
<p>A description of the multi-threading strategy used in the USER-OMP
package and some performance examples are <a class="reference external" href="http://sites.google.com/site/akohlmey/software/lammps-icms/lammps-icms-tms2011-talk.pdf?attredirects=0&d=1">presented here</a></p>
<p><strong>Guidelines for best performance:</strong></p>
<p>For many problems on current generation CPUs, running the USER-OMP
package with a single thread/task is faster than running with multiple
threads/task. This is because the MPI parallelization in LAMMPS is
often more efficient than multi-threading as implemented in the
USER-OMP package. The parallel efficiency (in a threaded sense) also
varies for different USER-OMP styles.</p>
<p>Using multiple threads/task can be more effective under the following
circumstances:</p>
<ul class="simple">
<li>Individual compute nodes have a significant number of CPU cores but
the CPU itself has limited memory bandwidth, e.g. for Intel Xeon 53xx
(Clovertown) and 54xx (Harpertown) quad-core processors. Running one
MPI task per CPU core will result in significant performance
degradation, so that running with 4 or even only 2 MPI tasks per node
is faster. Running in hybrid MPI+OpenMP mode will reduce the
inter-node communication bandwidth contention in the same way, but
offers an additional speedup by utilizing the otherwise idle CPU
cores.</li>
<li>The interconnect used for MPI communication does not provide
sufficient bandwidth for a large number of MPI tasks per node. For
example, this applies to running over gigabit ethernet or on Cray XT4
or XT5 series supercomputers. As in the aforementioned case, this
effect worsens when using an increasing number of nodes.</li>
<li>The system has a spatially inhomogeneous particle density which does
not map well to the <a class="reference internal" href="processors.html"><span class="doc">domain decomposition scheme</span></a> or
<a class="reference internal" href="balance.html"><span class="doc">load-balancing</span></a> options that LAMMPS provides. This is
because multi-threading achives parallelism over the number of
particles, not via their distribution in space.</li>
<li>A machine is being used in “capability mode”, i.e. near the point
where MPI parallelism is maxed out. For example, this can happen when
using the <a class="reference internal" href="kspace_style.html"><span class="doc">PPPM solver</span></a> for long-range
electrostatics on large numbers of nodes. The scaling of the KSpace
calculation (see the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command) becomes
the performance-limiting factor. Using multi-threading allows less
MPI tasks to be invoked and can speed-up the long-range solver, while
increasing overall performance by parallelizing the pairwise and
bonded calculations via OpenMP. Likewise additional speedup can be
sometimes be achived by increasing the length of the Coulombic cutoff
and thus reducing the work done by the long-range solver. Using the
<a class="reference internal" href="run_style.html"><span class="doc">run_style verlet/split</span></a> command, which is compatible
with the USER-OMP package, is an alternative way to reduce the number
of MPI tasks assigned to the KSpace calculation.</li>
</ul>
<p>Additional performance tips are as follows:</p>
<ul class="simple">
<li>The best parallel efficiency from <em>omp</em> styles is typically achieved
when there is at least one MPI task per physical CPU chip, i.e. socket
or die.</li>
<li>It is usually most efficient to restrict threading to a single
socket, i.e. use one or more MPI task per socket.</li>
<li>NOTE: By default, several current MPI implementations use a processor
affinity setting that restricts each MPI task to a single CPU core.
Using multi-threading in this mode will force all threads to share the
one core and thus is likely to be counterproductive. Instead, binding
MPI tasks to a (multi-core) socket, should solve this issue.</li>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>with an additional Urey_Bradley term based on the distance <em>r</em> between
the 1st and 3rd atoms in the angle. K, theta0, Kub, and Rub are
coefficients defined for each angle type.</p>
<p>See <a class="reference internal" href="#angle-mackerell"><span class="std std-ref">(MacKerell)</span></a> for a description of the CHARMM force
field.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy/radian^2)</li>
<li>theta0 (degrees)</li>
<li>K_ub (energy/distance^2)</li>
<li>r_ub (distance)</li>
</ul>
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where Ea is the angle term, Ebb is a bond-bond term, and Eba is a
bond-angle term. Theta0 is the equilibrium angle and r1 and r2 are
the equilibrium bond lengths.</p>
<p>See <a class="reference internal" href="#angle-sun"><span class="std std-ref">(Sun)</span></a> for a description of the COMPASS class2 force field.</p>
<p>Coefficients for the Ea, Ebb, and Eba formulas must be defined for
each angle type via the <a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in
the example above, or in the data file or restart files read by the
<p>These are the 4 coefficients for the Ea formula:</p>
<ul class="simple">
<li>theta0 (degrees)</li>
<li>K2 (energy/radian^2)</li>
<li>K3 (energy/radian^3)</li>
<li>K4 (energy/radian^4)</li>
</ul>
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of the various K are in per-radian.</p>
<p>For the Ebb formula, each line in a <a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a>
command in the input script lists 4 coefficients, the first of which
is “bb” to indicate they are BondBond coefficients. In a data file,
these coefficients should be listed under a “BondBond Coeffs” heading
and you must leave out the “bb”, i.e. only list 3 coefficients after
the angle type.</p>
<ul class="simple">
<li>bb</li>
<li>M (energy/distance^2)</li>
<li>r1 (distance)</li>
<li>r2 (distance)</li>
</ul>
<p>For the Eba formula, each line in a <a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a>
command in the input script lists 5 coefficients, the first of which
is “ba” to indicate they are BondAngle coefficients. In a data file,
these coefficients should be listed under a “BondAngle Coeffs” heading
and you must leave out the “ba”, i.e. only list 4 coefficients after
the angle type.</p>
<ul class="simple">
<li>ba</li>
<li>N1 (energy/distance^2)</li>
<li>N2 (energy/distance^2)</li>
<li>r1 (distance)</li>
<li>r2 (distance)</li>
</ul>
<p>The theta0 value in the Eba formula is not specified, since it is the
same value from the Ea formula.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the CLASS2
package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where theta0 is the equilibrium value of the angle, and K is a
prefactor. Note that the usual 1/2 factor is included in K.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy)</li>
<li>theta0 (degrees)</li>
</ul>
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
internally.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where C, B and n are coefficients defined for each angle type.</p>
<p>See <a class="reference internal" href="#cosine-mayo"><span class="std std-ref">(Mayo)</span></a> for a description of the DREIDING force field</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>C (energy)</li>
<li>B = 1 or -1</li>
<li>n = 1, 2, 3, 4, 5 or 6 for periodicity</li>
</ul>
<p>Note that the prefactor C is specified and not the overall force
constant K = C / n^2. When B = 1, it leads to a minimum for the
linear geometry. When B = -1, it leads to a maximum for the linear
geometry.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where theta0 is the equilibrium angle. The potential is bounded
between -Umin and zero. In the neighborhood of the minimum E=- Umin +
Umin/4(theta-theta0)^2 hence the spring constant is umin/2.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>umin (energy)</li>
<li>theta (angle)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where Umin, theta, and a are defined for each angle type.</p>
<p>The potential is bounded between [-Umin:0] and the minimum is
located at the angle theta0. The a parameter can be both positive or
negative and is used to control the spring constant at the
equilibrium.</p>
<p>The spring constant is given by k = A exp(A) Umin / [2 (Exp(a)-1)].
For a > 3, k/Umin = a/2 to better than 5% relative error. For negative
values of the a parameter, the spring constant is essentially zero,
and anharmonic terms takes over. The potential is furthermore well
behaved in the limit a -> 0, where it has been implemented to linear
order in a for a < 0.001. In this limit the potential reduces to the
cosineshifted potential.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>umin (energy)</li>
<li>theta (angle)</li>
<li>A (real number)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where theta0 is the equilibrium value of the angle, and K is a
prefactor. Note that the usual 1/2 factor is included in K.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy)</li>
<li>theta0 (degrees)</li>
</ul>
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
internally.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where F_i and F_j are applied on atoms i and j, respectively.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy)</li>
<li>gamma0 (degrees)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-6"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-2-3"><span class="std std-ref">Making LAMMPS</span></a>
section for more info on packages.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">In the “Angles” section of the data file, the atom ID ‘j’
corresponding to the dipole to restrain must come before the atom ID
of the reference atom ‘i’. A third atom ID ‘k’ must also be provided,
although ‘k’ is just a ‘dummy’ atom which can be any atom; it may be
useful to choose a convention (e.g., ‘k’=’i’) and adhere to it. For
example, if ID=1 for the dipolar atom to restrain, and ID=2 for the
reference atom, the corresponding line in the “Angles” section of the
data file would read: X X 1 2 2</p>
</div>
<p>The “newton” command for intramolecular interactions must be “on”
(which is the default).</p>
<p>This angle style should not be used with SHAKE.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy)</li>
<li>C0 (real)</li>
<li>C1 (real)</li>
<li>C2 (real)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy)</li>
<li>c (real)</li>
<li>n (real)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where theta0 is the equilibrium value of the angle, and K is a
prefactor. Note that the usual 1/2 factor is included in K.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy/radian^2)</li>
<li>theta0 (degrees)</li>
</ul>
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<blockquote>
<div>none</div></blockquote>
<p>This angle style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where theta0 is the equilibrium value of the angle, and K is a
prefactor. Note that the usual 1/2 factor is included in K.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>theta0 (degrees)</li>
<li>K2 (energy/radian^2)</li>
<li>K3 (energy/radian^3)</li>
<li>K4 (energy/radian^4)</li>
</ul>
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where theta0 is the equilibrium value of the angle and K a prefactor,
with the <em>repulsive</em> part of the non-bonded <em>lj/sdk</em> pair style
between the atoms 1 and 3. This angle potential is intended for
coarse grained MD simulations with the CMM parametrization using the
<a class="reference internal" href="pair_sdk.html"><span class="doc">pair_style lj/sdk</span></a>. Relative to the pair_style
<em>lj/sdk</em>, however, the energy is shifted by <em>epsilon</em>, to avoid sudden
jumps. Note that the usual 1/2 factor is included in K.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above:</p>
<ul class="simple">
<li>K (energy/radian^2)</li>
<li>theta0 (degrees)</li>
</ul>
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.
The also required <em>lj/sdk</em> parameters will be extracted automatically
from the pair_style.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER-CG-CMM package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
commands to initialize atoms. If the value is <em>no</em> the IDs for all
atoms are assumed to be 0.</p>
<p>If atom IDs are used, they must all be positive integers. They should
also be unique, though LAMMPS does not check for this. Typically they
should also be consecutively numbered (from 1 to Natoms), though this
is not required. Molecular <a class="reference internal" href="atom_style.html"><span class="doc">atom styles</span></a> are those
that store bond topology information (styles bond, angle, molecular,
full). These styles require atom IDs since the IDs are used to encode
the topology. Some other LAMMPS commands also require the use of atom
IDs. E.g. some many-body pair styles use them to avoid double
computation of the I-J interaction between two atoms.</p>
<p>The only reason not to use atom IDs is if you are running an atomic
simulation so large that IDs cannot be uniquely assigned. For a
default LAMMPS build this limit is 2^31 or about 2 billion atoms.
However, even in this case, you can use 64-bit atom IDs, allowing 2^63
or about 9e18 atoms, if you build LAMMPS with the - DLAMMPS_BIGBIG
switch. This is described in <a class="reference internal" href="Section_start.html#start-2"><span class="std std-ref">Section 2.2</span></a>
of the manual. If atom IDs are not used, they must be specified as 0
for all atoms, e.g. in a data or restart file.</p>
<p>The <em>map</em> keyword determines how atom ID lookup is done for molecular
atom styles. Lookups are performed by bond (angle, etc) routines in
LAMMPS to find the local atom index associated with a global atom ID.</p>
<p>When the <em>array</em> value is used, each processor stores a lookup table
of length N, where N is the largest atom ID in the system. This is a
fast, simple method for many simulations, but requires too much memory
for large simulations. The <em>hash</em> value uses a hash table to perform
the lookups. This can be slightly slower than the <em>array</em> method, but
its memory cost is proportional to the number of atoms owned by a
processor, i.e. N/P when N is the total number of atoms in the system
and P is the number of processors.</p>
<p>When this setting is not specified in your input script, LAMMPS
creates a map, if one is needed, as an array or hash. See the
discussion of default values below for how LAMMPS chooses which kind
of map to build. Note that atomic systems do not normally need to
create a map. However, even in this case some LAMMPS commands will
create a map to find atoms (and then destroy it), or require a
permanent map. An example of the former is the <a class="reference internal" href="velocity.html"><span class="doc">velocity loop all</span></a> command, which uses a map when looping over all
atoms and insuring the same velocity values are assigned to an atom
ID, no matter which processor owns it.</p>
<p>The <em>first</em> keyword allows a <a class="reference internal" href="group.html"><span class="doc">group</span></a> to be specified whose
atoms will be maintained as the first atoms in each processor’s list
of owned atoms. This in only useful when the specified group is a
small fraction of all the atoms, and there are other operations LAMMPS
is performing that will be sped-up significantly by being able to loop
over the smaller set of atoms. Otherwise the reordering required by
this option will be a net slow-down. The <a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify include</span></a> and <a class="reference internal" href="comm_modify.html"><span class="doc">comm_modify group</span></a>
commands are two examples of commands that require this setting to
work efficiently. Several <a class="reference internal" href="fix.html"><span class="doc">fixes</span></a>, most notably time
integration fixes like <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a>, also take advantage of
this setting if the group they operate on is the group specified by
this command. Note that specifying “all” as the group-ID effectively
turns off the <em>first</em> option.</p>
<p>It is OK to use the <em>first</em> keyword with a group that has not yet been
defined, e.g. to use the atom_modify first command at the beginning of
your input script. LAMMPS does not use the group until a simullation
is run.</p>
<p>The <em>sort</em> keyword turns on a spatial sorting or reordering of atoms
within each processor’s sub-domain every <em>Nfreq</em> timesteps. If
<em>Nfreq</em> is set to 0, then sorting is turned off. Sorting can improve
cache performance and thus speed-up a LAMMPS simulation, as discussed
in a paper by <a class="reference internal" href="#meloni"><span class="std std-ref">(Meloni)</span></a>. Its efficacy depends on the problem
size (atoms/processor), how quickly the system becomes disordered, and
various other factors. As a general rule, sorting is typically more
effective at speeding up simulations of liquids as opposed to solids.
In tests we have done, the speed-up can range from zero to 3-4x.</p>
<p>Reordering is peformed every <em>Nfreq</em> timesteps during a dynamics run
or iterations during a minimization. More precisely, reordering
occurs at the first reneighboring that occurs after the target
timestep. The reordering is performed locally by each processor,
using bins of the specified <em>binsize</em>. If <em>binsize</em> is set to 0.0,
then a binsize equal to half the <a class="reference internal" href="neighbor.html"><span class="doc">neighbor</span></a> cutoff
distance (force cutoff plus skin distance) is used, which is a
reasonable value. After the atoms have been binned, they are
reordered so that atoms in the same bin are adjacent to each other in
the processor’s 1d list of atoms.</p>
<p>The goal of this procedure is for atoms to put atoms close to each
other in the processor’s one-dimensional list of atoms that are also
near to each other spatially. This can improve cache performance when
pairwise intereractions and neighbor lists are computed. Note that if
bins are too small, there will be few atoms/bin. Likewise if bins are
too large, there will be many atoms/bin. In both cases, the goal of
cache locality will be undermined.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Running a simulation with sorting on versus off should not
change the simulation results in a statistical sense. However, a
different ordering will induce round-off differences, which will lead
to diverging trajectories over time when comparing two simluations.
Various commands, particularly those which use random numbers
(e.g. <a class="reference internal" href="velocity.html"><span class="doc">velocity create</span></a>, and <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a>), may generate (statistically identical)
results which depend on the order in which atoms are processed. The
order of atoms in a <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> file will also typically change
if sorting is enabled.</p>
</div>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The <em>first</em> and <em>sort</em> options cannot be used together. Since sorting
is on by default, it will be turned off if the <em>first</em> keyword is
used with a group-ID that is not “all”.</p>
<p><strong>Related commands:</strong> none</p>
</div>
<div class="section" id="default">
<h2>Default</h2>
<p>By default, <em>id</em> is yes. By default, atomic systems (no bond topology
info) do not use a map. For molecular systems (with bond topology
info), a map is used. The default map style is array if no atom ID is
larger than 1 million, otherwise the default is hash. By default, a
“first” group is not defined. By default, sorting is enabled with a
frequency of 1000 and a binsize of 0.0, which means the neighbor
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>style = <em>angle</em> or <em>atomic</em> or <em>body</em> or <em>bond</em> or <em>charge</em> or <em>dipole</em> or <em>dpd</em> or <em>electron</em> or <em>ellipsoid</em> or <em>full</em> or <em>line</em> or <em>meso</em> or <em>molecular</em> or <em>peri</em> or <em>smd</em> or <em>sphere</em> or <em>tri</em> or <em>template</em> or <em>hybrid</em></li>
</ul>
<pre class="literal-block">
args = none for any style except the following
<em>body</em> args = bstyle bstyle-args
bstyle = style of body particles
bstyle-args = additional arguments specific to the bstyle
see the <a class="reference internal" href="body.html"><span class="doc">body</span></a> doc page for details
<em>template</em> args = template-ID
template-ID = ID of molecule template specified in a separate <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command
<em>hybrid</em> args = list of one or more sub-styles, each with their args
</pre>
<ul class="simple">
<li>accelerated styles (with same args) = <em>angle/kk</em> or <em>atomic/kk</em> or <em>bond/kk</em> or <em>charge/kk</em> or <em>full/kk</em> or <em>molecular/kk</em></li>
<p class="last">It is possible to add some attributes, such as a molecule ID, to
atom styles that do not have them via the <a class="reference internal" href="fix_property_atom.html"><span class="doc">fix property/atom</span></a> command. This command also
allows new custom attributes consisting of extra integer or
floating-point values to be added to atoms. See the <a class="reference internal" href="fix_property_atom.html"><span class="doc">fix property/atom</span></a> doc page for examples of cases
where this is useful and details on how to initialize, access, and
output the custom values.</p>
</div>
<p>All of the above styles define point particles, except the <em>sphere</em>,
<em>ellipsoid</em>, <em>electron</em>, <em>peri</em>, <em>wavepacket</em>, <em>line</em>, <em>tri</em>, and
<em>body</em> styles, which define finite-size particles. See <a class="reference internal" href="Section_howto.html#howto-14"><span class="std std-ref">Section_howto 14</span></a> for an overview of using finite-size
particle models with LAMMPS.</p>
<p>All of the point-particle styles assign mass to particles on a
per-type basis, using the <a class="reference internal" href="mass.html"><span class="doc">mass</span></a> command, The finite-size
particle styles assign mass to individual particles on a per-particle
basis.</p>
<p>For the <em>sphere</em> style, the particles are spheres and each stores a
per-particle diameter and mass. If the diameter > 0.0, the particle
is a finite-size sphere. If the diameter = 0.0, it is a point
particle.</p>
<p>For the <em>ellipsoid</em> style, the particles are ellipsoids and each
stores a flag which indicates whether it is a finite-size ellipsoid or
a point particle. If it is an ellipsoid, it also stores a shape
vector with the 3 diamters of the ellipsoid and a quaternion 4-vector
with its orientation.</p>
<p>For the <em>dipole</em> style, a point dipole is defined for each point
particle. Note that if you wish the particles to be finite-size
spheres as in a Stockmayer potential for a dipolar fluid, so that the
particles can rotate due to dipole-dipole interactions, then you need
to use atom_style hybrid sphere dipole, which will assign both a
diameter and dipole moment to each particle.</p>
<p>For the <em>electron</em> style, the particles representing electrons are 3d
Gaussians with a specified position and bandwidth or uncertainty in
position, which is represented by the eradius = electron size.</p>
<p>For the <em>peri</em> style, the particles are spherical and each stores a
per-particle mass and volume.</p>
<p>The <em>dpd</em> style is for dissipative particle dynamics (DPD) particles.
Note that it is part of the USER-DPD package, and is not for use with
the <a class="reference internal" href="pair_dpd.html"><span class="doc">pair_style dpd or dpd/stat</span></a> commands, which can
simply use atom_style atomic. Atom_style dpd extends DPD particle
properties with internal temperature (dpdTheta), internal conductive
energy (uCond), internal mechanical energy (uMech), and internal
chemical energy (uChem).</p>
<p>The <em>meso</em> style is for smoothed particle hydrodynamics (SPH)
particles which store a density (rho), energy (e), and heat capacity
(cv).</p>
<p>The <em>smd</em> style is for a general formulation of Smooth Particle
Hydrodynamics. Both fluids and solids can be modeled. Particles
store the mass and volume of an integration point, a kernel diameter
used for calculating the field variables (e.g. stress and deformation)
and a contact radius for calculating repulsive forces which prevent
individual physical bodies from penetretating each other.</p>
<p>The <em>wavepacket</em> style is similar to <em>electron</em>, 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
have identical <em>etag</em> values.</p>
<p>For the <em>line</em> style, the particles are idealized line segments and
each stores a per-particle mass and length and orientation (i.e. the
end points of the line segment).</p>
<p>For the <em>tri</em> style, the particles are planar triangles and each
stores a per-particle mass and size and orientation (i.e. the corner
points of the triangle).</p>
<p>The <em>template</em> style allows molecular topolgy (bonds,angles,etc) to be
defined via a molecule template using the <a class="reference external" href="molecule.txt">molecule</a>
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
<em>template</em> style instead of the <em>bond</em>, <em>angle</em>, <em>molecular</em> 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 <a class="reference internal" href="#grime"><span class="std std-ref">(Grime)</span></a>, for examples of how this
can be advantageous for large-scale coarse-grained systems.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When using the <em>template</em> style with a <a class="reference internal" href="molecule.html"><span class="doc">molecule template</span></a> that contains multiple molecules, you should
insure the atom types, bond types, angle_types, etc in all the
molecules are consistent. E.g. if one molecule represents H2O and
another CO2, then you probably do not want each molecule file to
define 2 atom types and a single bond type, because they will conflict
with each other when a mixture system of H2O and CO2 molecules is
defined, e.g. by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command. Rather the
H2O molecule should define atom types 1 and 2, and bond type 1. And
the CO2 molecule should define atom types 3 and 4 (or atom types 3 and
2 if a single oxygen type is desired), and bond type 2.</p>
</div>
<p>For the <em>body</em> style, the particles are arbitrary bodies with internal
attributes defined by the “style” of the bodies, which is specified by
the <em>bstyle</em> argument. Body particles can represent complex entities,
such as surface meshes of discrete points, collections of
sub-particles, deformable objects, etc.</p>
<p>The <a class="reference internal" href="body.html"><span class="doc">body</span></a> doc page descibes 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 orientation
and position can be time integrated due to forces and torques.</p>
<p>Note that there may be additional arguments required along with the
<em>bstyle</em> specification, in the atom_style body command. These
arguments are described in the <a class="reference internal" href="body.html"><span class="doc">body</span></a> doc page.</p>
<hr class="docutils" />
<p>Typically, simulations require only a single (non-hybrid) atom style.
If some atoms in the simulation do not have all the properties defined
by a particular style, use the simplest style that defines all the
needed properties by any atom. For example, if some atoms in a
simulation are charged, but others are not, use the <em>charge</em> style.
If some atoms have bonds, but others do not, use the <em>bond</em> style.</p>
<p>The only scenario where the <em>hybrid</em> style is needed is if there is no
single style which defines all needed properties of all atoms. For
example, as mentioned above, if you want dipolar particles which will
rotate due to torque, you need to use “atom_style hybrid sphere
dipole”. When a hybrid style is used, atoms store and communicate the
union of all quantities implied by the individual styles.</p>
<p>When using the <em>hybrid</em> style, you cannot combine the <em>template</em> style
with another molecular style that stores bond,angle,etc info on a
per-atom basis.</p>
<p>LAMMPS can be extended with new atom styles as well as new body
styles; see <a class="reference internal" href="Section_modify.html"><span class="doc">this section</span></a>.</p>
<hr class="docutils" />
<p>Styles with a <em>kk</em> 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 in
<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.</p>
<p>Note that other acceleration packages in LAMMPS, specifically the GPU,
USER-INTEL, USER-OMP, and OPT packages do not use accelerated atom
styles.</p>
<p>The accelerated styles are part of the KOKKOS package. They are only
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This command cannot be used after the simulation box is defined by a
<p>Many of the styles listed above are only enabled if LAMMPS was built
with a specific package, as listed below. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The <em>angle</em>, <em>bond</em>, <em>full</em>, <em>molecular</em>, and <em>template</em> styles are
part of the MOLECULE package.</p>
<p>The <em>line</em> and <em>tri</em> styles are part of the ASPHERE package.</p>
<p>The <em>body</em> style is part of the BODY package.</p>
<p>The <em>dipole</em> style is part of the DIPOLE package.</p>
<p>The <em>peri</em> style is part of the PERI package for Peridynamics.</p>
<p>The <em>electron</em> style is part of the USER-EFF package for <a class="reference internal" href="pair_eff.html"><span class="doc">electronic force fields</span></a>.</p>
<p>The <em>dpd</em> style is part of the USER-DPD package for dissipative
particle dynamics (DPD).</p>
<p>The <em>meso</em> style is part of the USER-SPH package for smoothed particle
hydrodyanmics (SPH). See <a class="reference external" href="USER/sph/SPH_LAMMPS_userguide.pdf">this PDF guide</a> to using SPH in LAMMPS.</p>
<p>The <em>wavepacket</em> style is part of the USER-AWPMD package for the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This doc page is not about a LAMMPS input script command, but about
body particles, which are generalized finite-size particles.
Individual body particles can represent complex entities, such as
surface meshes of discrete points, collections of sub-particles,
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 that body particles. See <a class="reference internal" href="Section_howto.html#howto-14"><span class="std std-ref">Section_howto 14</span></a> for a general overview of all these
particle types.</p>
<p>Body particles are used via the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style body</span></a>
command. It takes a body style as an argument. The current body
styles supported by LAMMPS are as follows. The name in the first
column is used as the <em>bstyle</em> argument for the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style body</span></a> command.</p>
<p>The body style determines what attributes are stored for each body and
thus how they can be used to compute pairwise body/body or
bond/non-body (point particle) interactions. More details of each
style are described below.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The rounded/polygon style listed in the table above and
described below has not yet been relesed in LAMMPS. It will be soon.</p>
</div>
<p>We hope to add more styles in the future. See <a class="reference internal" href="Section_modify.html#mod-12"><span class="std std-ref">Section_modify 12</span></a> for details on how to add a new body
style to the code.</p>
<hr class="docutils" />
<p><strong>When to use body particles:</strong></p>
<p>You should not use body particles to model a rigid body made of
simpler particles (e.g. point, sphere, ellipsoid, line segment,
triangular particles), if the interaction between pairs of rigid
bodies is just the summation of pairwise interactions between the
simpler particles. LAMMPS already supports this kind of model via the
<a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> command. Any of the numerous pair styles
that compute interactions between simpler particles can be used. The
<a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> command time integrates the motion of the
rigid bodies. All of the standard LAMMPS commands for thermostatting,
adding constraints, performing output, etc will operate as expected on
the simple particles.</p>
<p>By contrast, when body particles are used, LAMMPS treats an entire
body as a single particle for purposes of computing pairwise
interactions, building neighbor lists, migrating particles between
processors, outputting particles to a dump file, etc. This means that
interactions between pairs of bodies or between a body and non-body
(point) particle need to be encoded in an appropriate pair style. If
such a pair style were to mimic the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> model,
it would need to loop over the entire collection of interactions
between pairs of simple particles within the two bodies, each time a
single body/body interaction was computed.</p>
<p>Thus it only makes sense to use body particles and develop such a pair
style, when particle/particle interactions are more complex than what
the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> command can already calculate. For
example, if particles have one or more of the following attributes:</p>
<ul class="simple">
<li>represented by a surface mesh</li>
<li>represented by a collection of geometric entities (e.g. planes + spheres)</li>
<li>deformable</li>
<li>internal stress that induces fragmentation</li>
</ul>
<p>then the interaction between pairs of particles is likely to be more
complex than the summation of simple sub-particle interactions. An
example is contact or frictional forces between particles with planar
sufaces that inter-penetrate.</p>
<p>These are additional LAMMPS commands that can be used with body
-<span class="n">Nmin</span> <span class="o">=</span> <span class="n">minimum</span> <span class="c1"># of sub-particles in any body in the system</span>
-<span class="n">Nmax</span> <span class="o">=</span> <span class="n">maximum</span> <span class="c1"># of sub-particles in any body in the system</span>
-</pre></div>
-</div>
+<pre class="literal-block">
+atom_style body nparticle Nmin Nmax
+Nmin = minimum # of sub-particles in any body in the system
+Nmax = maximum # of sub-particles in any body in the system
+</pre>
<p>The Nmin and Nmax arguments are used to bound the size of data
structures used internally by each particle.</p>
<p>When the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command reads a data file for this
body style, the following information must be provided for each entry
in the <em>Bodies</em> section of the data file:</p>
<p>These values are the current position of the vertex within the
simulation domain, not a displacement from the center-of-mass (COM) of
the body particle itself. These values are calculated using the
current COM and orientation of the body particle.</p>
<p>For images created by the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a> command, if the
<em>body</em> keyword is set, then each body particle is drawn as a convex
polygon consisting of N line segments. Note that the line segments
are drawn between the N vertices, which does not correspond exactly to
the physical extent of the body (because the <a class="reference external" href="pair_body_rounded_polygon.cpp">pair_style rounded/polygon</a> defines finite-size
spheres at those point and the line segments between the spheres are
tangent to the spheres). The drawn diameter of each line segment is
determined by the <em>bflag1</em> parameter for the <em>body</em> keyword. The
<em>bflag2</em> argument is ignored.</p>
<hr class="docutils" />
<p id="fraige"><strong>(Fraige)</strong> F. Y. Fraige, P. A. Langston, A. J. Matchett, J. Dodds,
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>See <a class="reference internal" href="#bond-sun"><span class="std std-ref">(Sun)</span></a> for a description of the COMPASS class2 force field.</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>R0 (distance)</li>
<li>K2 (energy/distance^2)</li>
<li>K3 (energy/distance^3)</li>
<li>K4 (energy/distance^4)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the CLASS2
package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>to define a finite extensible nonlinear elastic (FENE) potential
<a class="reference internal" href="#fene-kremer"><span class="std std-ref">(Kremer)</span></a>, used for bead-spring polymer models. The first
term is attractive, the 2nd Lennard-Jones term is repulsive. The
first term extends to R0, the maximum extent of the bond. The 2nd
term is cutoff at 2^(1/6) sigma, the minimum of the LJ potential.</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy/distance^2)</li>
<li>R0 (distance)</li>
<li>epsilon (energy)</li>
<li>sigma (distance)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
<p>You typically should specify <a class="reference external" href="special_bonds.html"">special_bonds fene</a>
or <a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds lj/coul 0 1 1</span></a> to use this bond
style. LAMMPS will issue a warning it that’s not the case.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>to define a finite extensible nonlinear elastic (FENE) potential
<a class="reference internal" href="#feneexpand-kremer"><span class="std std-ref">(Kremer)</span></a>, used for bead-spring polymer models. The first
term is attractive, the 2nd Lennard-Jones term is repulsive.</p>
<p>The <em>fene/expand</em> bond style is similar to <em>fene</em> except that an extra
shift factor of delta (positive or negative) is added to <em>r</em> to
effectively change the bead size of the bonded atoms. The first term
now extends to R0 + delta and the 2nd term is cutoff at 2^(1/6) sigma
+ delta.</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy/distance^2)</li>
<li>R0 (distance)</li>
<li>epsilon (energy)</li>
<li>sigma (distance)</li>
<li>delta (distance)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
<p>You typically should specify <a class="reference external" href="special_bonds.html"">special_bonds fene</a>
or <a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds lj/coul 0 1 1</span></a> to use this bond
style. LAMMPS will issue a warning it that’s not the case.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where r0 is the equilibrium bond distance. Note that the usual 1/2
factor is included in K.</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy/distance^2)</li>
<li>r0 (distance)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where r0 is the equilibrium bond distance, and rc the critical distance.
The potential is -Umin at r0 and zero at rc. The spring constant is
k = Umin / [ 2 (r0-rc)^2].</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>Umin (energy)</li>
<li>r0 (distance)</li>
<li>rc (distance)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where r0 is the equilibrium bond distance, and rc the critical distance.
The bond potential is zero for distances r > rc. The potential is -Umin
at r0 and zero at rc. The spring constant is k = Umin / [ 2 (r0-rc)^2].</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>Umin (energy)</li>
<li>r0 (distance)</li>
<li>rc (distance)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where r0 is the equilibrium bond distance, alpha is a stiffness
parameter, and D determines the depth of the potential well.</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>D (energy)</li>
<li>alpha (inverse distance)</li>
<li>r0 (distance)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>to define an anharmonic spring <a class="reference internal" href="#rector"><span class="std std-ref">(Rector)</span></a> of equilibrium
length r0 and maximum extension lamda.</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>epsilon (energy)</li>
<li>r0 (distance)</li>
<li>lamda (distance)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>to define a bond that can be broken as the simulation proceeds (e.g.
due to a polymer being stretched). The sigma and epsilon used in the
LJ portion of the formula are both set equal to 1.0 by LAMMPS.</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy/distance^4)</li>
<li>B1 (distance)</li>
<li>B2 (distance)</li>
<li>Rc (distance)</li>
<li>U0 (energy)</li>
</ul>
<p>This potential was constructed to mimic the FENE bond potential for
coarse-grained polymer chains. When monomers with sigma = epsilon =
1.0 are used, the following choice of parameters gives a quartic
potential that looks nearly like the FENE potential: K = 1200, B1 =
-0.55, B2 = 0.25, Rc = 1.3, and U0 = 34.6878. Different parameters
can be specified using the <a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command, but
you will need to choose them carefully so they form a suitable bond
potential.</p>
<p>Rc is the cutoff length at which the bond potential goes smoothly to a
local maximum. If a bond length ever becomes > Rc, LAMMPS “breaks”
the bond, which means two things. First, the bond potential is turned
off by setting its type to 0, and is no longer computed. Second, a
pairwise interaction between the two atoms is turned on, since they
are no longer bonded.</p>
<p>LAMMPS does the second task via a computational sleight-of-hand. It
subtracts the pairwise interaction as part of the bond computation.
When the bond breaks, the subtraction stops. For this to work, the
pairwise interaction must always be computed by the
<a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> command, whether the bond is broken or
not. This means that <a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> must be set
to 1,1,1, as indicated as a restriction below.</p>
<p>Note that when bonds are dumped to a file via the <a class="reference internal" href="dump.html"><span class="doc">dump local</span></a> command, bonds with type 0 are not included. The
<a class="reference internal" href="delete_bonds.html"><span class="doc">delete_bonds</span></a> command can also be used to query the
status of broken bonds or permanently delete them, e.g.:</p>
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
<p>The <em>quartic</em> style requires that <a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a>
parameters be set to 1,1,1. Three- and four-body interactions (angle,
dihedral, etc) cannot be used with <em>quartic</em> bonds.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>group-ID = ID of group of atoms to (optionally) displace</li>
<li>one or more parameter/arg pairs may be appended</li>
</ul>
<pre class="literal-block">
parameter = <em>x</em> or <em>y</em> or <em>z</em> or <em>xy</em> or <em>xz</em> or <em>yz</em> or <em>boundary</em> or <em>ortho</em> or <em>triclinic</em> or <em>set</em> or <em>remap</em>
-<span class="n">change_box</span> <span class="n">boundary</span> <span class="n">s</span> <span class="n">s</span> <span class="n">s</span> <span class="c1"># this will work</span>
-</pre></div>
-</div>
+<pre class="literal-block">
+change_box all x final -10 20
+create_atoms 1 single -5 5 5 # this will fail to insert an atom
+</pre>
+<pre class="literal-block">
+change_box all x final -10 20 boundary f s s
+create_atoms 1 single -5 5 5
+change_box boundary s s s # this will work
+</pre>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Unlike the earlier “displace_box” version of this command, atom
remapping is NOT performed by default. This command allows remapping
to be done in a more general way, exactly when you specify it (zero or
more times) in the sequence of transformations. Thus if you do not
use the <em>remap</em> keyword, atom coordinates will not be changed even if
the box size/shape changes. If a uniformly strained state is desired,
the <em>remap</em> keyword should be specified.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">It is possible to lose atoms with this command. E.g. by
changing the box without remapping the atoms, and having atoms end up
outside of non-periodic boundaries. It is also possible to alter
bonds between atoms straddling a boundary in bad ways. E.g. by
converting a boundary from periodic to non-periodic. It is also
possible when remapping atoms to put them (nearly) on top of each
other. E.g. by converting a boundary from non-periodic to periodic.
All of these will typically lead to bad dynamics and/or generate error
messages.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The simulation box size/shape can be changed by arbitrarily
large amounts by this command. This is not a problem, except that the
mapping of processors to the simulation box is not changed from its
initial 3d configuration; see the <a class="reference internal" href="processors.html"><span class="doc">processors</span></a>
command. Thus, if the box size/shape changes dramatically, the
mapping of processors to the simulation box may not end up as optimal
as the initial mapping attempted to be.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Because the keywords used in this command are applied one at a
time to the simulation box and the atoms in it, care must be taken
with triclinic cells to avoid exceeding the limits on skew after each
transformation in the sequence. If skew is exceeded before the final
transformation this can be avoided by changing the order of the
sequence, or breaking the transformation into two or more smaller
transformations. For more information on the allowed limits for box
skew see the discussion on triclinic boxes on <a class="reference internal" href="Section_howto.html#howto-12"><span class="std std-ref">this page</span></a>.</p>
</div>
<hr class="docutils" />
<p>For the <em>x</em>, <em>y</em>, and <em>z</em> parameters, this is the meaning of their
styles and values.</p>
<p>For style <em>final</em>, 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.</p>
<p>For style <em>delta</em>, 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.</p>
<p>For style <em>scale</em>, 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.</p>
<p>The <em>volume</em> 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 <em>volume</em> style can only be
used following a keyword that changed the volume, which is any of the
<em>x</em>, <em>y</em>, <em>z</em> keywords. If the preceding keyword “key” had a <em>volume</em>
style, then both it and the current keyword apply to the keyword
preceding “key”. I.e. this sequence of keywords is allowed:</p>
command. This command allows the boundary conditions to be changed
later in your input script. Also note that the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> will change boundary conditions to
match what is stored in the restart file. So if you wish to change
them, you should use the change_box command after the read_restart
command.</p>
<hr class="docutils" />
<p>The <em>ortho</em> and <em>triclinic</em> keywords convert the simulation box to be
orthogonal or triclinic (non-orthongonal). See <a class="reference internal" href="Section_howto.html#howto-13"><span class="std std-ref">this section</span></a> for a discussion of how non-orthongal
boxes are represented in LAMMPS.</p>
<p>The simulation box is defined as either orthogonal or triclinic when
it is created via the <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a>,
<p>These keywords allow you to toggle the existing simulation box from
orthogonal to triclinic and vice versa. For example, an initial
equilibration simulation can be run in an orthogonal box, the box can
be toggled to triclinic, and then a <a class="reference internal" href="Section_howto.html#howto-13"><span class="std std-ref">non-equilibrium MD (NEMD) simulation</span></a> can be run with deformation
via the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> command.</p>
<p>If the simulation box is currently triclinic and has non-zero tilt in
xy, yz, or xz, then it cannot be converted to an orthogonal box.</p>
<hr class="docutils" />
<p>The <em>set</em> keyword saves the current box size/shape. This can be
useful if you wish to use the <em>remap</em> keyword more than once or if you
wish it to be applied to an intermediate box size/shape in a sequence
of keyword operations. Note that the box size/shape is saved before
any of the keywords are processed, i.e. the box size/shape at the time
the create_box command is encountered in the input script.</p>
<p>The <em>remap</em> keyword remaps atom coordinates from the last saved box
size/shape to the current box state. For example, if you stretch the
box in the x dimension or tilt it in the xy plane via the <em>x</em> and <em>xy</em>
keywords, then the <em>remap</em> commmand will dilate or tilt the atoms to
conform to the new box size/shape, as if the atoms moved with the box
as it deformed.</p>
<p>Note that this operation is performed without regard to periodic
boundaries. Also, any shrink-wrapping of non-periodic boundaries (see
the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command) occurs after all keywords,
including this one, have been processed.</p>
<p>Only atoms in the specified group are remapped.</p>
<hr class="docutils" />
<p>The <em>units</em> keyword determines the meaning of the distance units used
to define various arguments. A <em>box</em> value selects standard distance
units as defined by the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command, e.g. Angstroms for
units = real or metal. A <em>lattice</em> value means the distance units are
in lattice spacings. The <a class="reference internal" href="lattice.html"><span class="doc">lattice</span></a> command must have
been previously used to define the lattice spacing.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>If you use the <em>ortho</em> or <em>triclinic</em> keywords, then at the point in
the input script when this command is issued, no <a class="reference internal" href="dump.html"><span class="doc">dumps</span></a> can
be active, nor can a <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> be active. This is
because these commands test whether the simulation box is orthogonal
when they are first issued. Note that these commands can be used in
your script before a change_box command is issued, so long as an
<a class="reference internal" href="undump.html"><span class="doc">undump</span></a> or <a class="reference internal" href="unfix.html"><span class="doc">unfix</span></a> command is also used to
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Define a computation that will be performed on a group of atoms.
Quantities calculated by a compute are instantaneous values, meaning
they are calculated from information about atoms on the current
timestep or iteration, though a compute may internally store some
information about a previous state of the system. Defining a compute
does not perform a computation. Instead computes are invoked by other
LAMMPS commands as needed, e.g. to calculate a temperature needed for
a thermostat fix or to generate thermodynamic or dump file output.
See this <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">howto section</span></a> for a summary of
various LAMMPS output options, many of which involve computes.</p>
<p>The ID of a compute can only contain alphanumeric characters and
underscores.</p>
<hr class="docutils" />
<p>Computes calculate one of three styles of quantities: global,
per-atom, or local. A global quantity is one or more system-wide
values, e.g. the temperature of the system. A per-atom quantity is
one or more values per atom, e.g. the kinetic energy of each atom.
Per-atom values are set to 0.0 for atoms not in the specified compute
group. Local quantities are calculated by each processor based on the
atoms it owns, but there may be zero or more per atom, e.g. a list of
bond distances. Computes that produce per-atom quantities have the
word “atom” in their style, e.g. <em>ke/atom</em>. Computes that produce
local quantities have the word “local” in their style,
e.g. <em>bond/local</em>. Styles with neither “atom” or “local” in their
style produce global quantities.</p>
<p>Note that a single compute produces either global or per-atom or local
quantities, but never more than one of these (with only a few
exceptions, as documented by individual compute commands).</p>
<p>Global, per-atom, and local quantities each come in three kinds: a
single scalar value, a vector of values, or a 2d array of values. The
doc page for each compute describes the style and kind of values it
produces, e.g. a per-atom vector. Some computes produce more than one
kind of a single style, e.g. a global scalar and a global vector.</p>
<p>When a compute quantity is accessed, as in many of the output commands
discussed below, it can be referenced via the following bracket
notation, where ID is the ID of the compute:</p>
<table border="1" class="docutils">
<colgroup>
-<col width="21%" />
-<col width="79%" />
+<col width="23%" />
+<col width="77%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>c_ID</td>
<td>entire scalar, vector, or array</td>
</tr>
<tr class="row-even"><td>c_ID[I]</td>
<td>one element of vector, one column of array</td>
</tr>
<tr class="row-odd"><td>c_ID[I][J]</td>
<td>one element of array</td>
</tr>
</tbody>
</table>
<p>In other words, using one bracket reduces the dimension of the
quantity once (vector -> scalar, array -> vector). Using two brackets
reduces the dimension twice (array -> scalar). Thus a command that
uses scalar compute values as input can also process elements of a
vector or array.</p>
<p>Note that commands and <a class="reference internal" href="variable.html"><span class="doc">variables</span></a> which use compute
quantities typically do not allow for all kinds, e.g. a command may
require a vector of values, not a scalar. This means there is no
ambiguity about referring to a compute quantity as c_ID even if it
produces, for example, both a scalar and vector. The doc pages for
various commands explain the details.</p>
<hr class="docutils" />
<p>In LAMMPS, the values generated by a compute can be used in several
ways:</p>
<ul class="simple">
<li>The results of computes that calculate a global temperature or
pressure can be used by fixes that do thermostatting or barostatting
or when atom velocities are created.</li>
<li>Global values can be output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> or <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a> command.
Or the values can be referenced in a <a class="reference internal" href="variable.html"><span class="doc">variable equal</span></a> or
<li>Per-atom values can be output via the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command.
Or they can be time-averaged via the <a class="reference internal" href="fix_ave_atom.html"><span class="doc">fix ave/atom</span></a>
command or reduced by the <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a>
command. Or the per-atom values can be referenced in an <a class="reference internal" href="variable.html"><span class="doc">atom-style variable</span></a>.</li>
<li>Local values can be reduced by the <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a> command, or histogrammed by the <a class="reference internal" href="fix_ave_histo.html"><span class="doc">fix ave/histo</span></a> command, or output by the <a class="reference internal" href="dump.html"><span class="doc">dump local</span></a> command.</li>
</ul>
<p>The results of computes that calculate global quantities can be either
“intensive” or “extensive” values. Intensive means the value is
independent of the number of atoms in the simulation,
e.g. temperature. Extensive means the value scales with the number of
atoms in the simulation, e.g. total rotational kinetic energy.
<a class="reference internal" href="thermo_style.html"><span class="doc">Thermodynamic output</span></a> will normalize extensive
values by the number of atoms in the system, depending on the
“thermo_modify norm” setting. It will not normalize intensive values.
If a compute value is accessed in another way, e.g. by a
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a>, you may want to know whether it is an
intensive or extensive value. See the doc page for individual
computes for further info.</p>
<hr class="docutils" />
<p>LAMMPS creates its own computes internally for thermodynamic output.
Three computes are always created, named “thermo_temp”,
“thermo_press”, and “thermo_pe”, as if these commands had been invoked
<p>Fixes that calculate temperature or pressure, i.e. for thermostatting
or barostatting, may also create computes. These are discussed in the
documentation for specific <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> commands.</p>
<p>In all these cases, the default computes LAMMPS creates can be
replaced by computes defined by the user in the input script, as
described by the <a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify</span></a> and <a class="reference internal" href="fix_modify.html"><span class="doc">fix modify</span></a> commands.</p>
<p>Properties of either a default or user-defined compute can be modified
via the <a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command.</p>
<p>Computes can be deleted with the <a class="reference internal" href="uncompute.html"><span class="doc">uncompute</span></a> command.</p>
<p>Code for new computes can be added to LAMMPS (see <a class="reference internal" href="Section_modify.html"><span class="doc">this section</span></a> of the manual) and the results of their
calculations accessed in the various ways described above.</p>
<hr class="docutils" />
<p>Each compute style has its own doc page which describes its arguments
and what it does. Here is an alphabetic list of compute styles
available in LAMMPS. They are also given in more compact form in the
Compute section of <a class="reference internal" href="Section_commands.html#cmd-5"><span class="std std-ref">this page</span></a>.</p>
<p>There are also additional compute styles (not listed here) submitted
by users which are included in the LAMMPS distribution. The list of
these with links to the individual styles are given in the compute
section of <a class="reference internal" href="Section_commands.html#cmd-5"><span class="std std-ref">this page</span></a>.</p>
<ul class="simple">
<li><a class="reference internal" href="compute_bond_local.html"><span class="doc">angle/local</span></a> - theta and energy of each angle</li>
<li><a class="reference internal" href="compute_angmom_chunk.html"><span class="doc">angmom/chunk</span></a> - angular momentum for each chunk</li>
<li><a class="reference internal" href="compute_body_local.html"><span class="doc">body/local</span></a> - attributes of body sub-particles</li>
<li><a class="reference internal" href="compute_bond.html"><span class="doc">bond</span></a> - values computed by a bond style</li>
<li><a class="reference internal" href="compute_bond_local.html"><span class="doc">bond/local</span></a> - distance and energy of each bond</li>
<li><a class="reference internal" href="compute_centro_atom.html"><span class="doc">centro/atom</span></a> - centro-symmetry parameter for each atom</li>
<li><a class="reference internal" href="compute_chunk_atom.html"><span class="doc">chunk/atom</span></a> - assign chunk IDs to each atom</li>
<li><a class="reference internal" href="compute_cluster_atom.html"><span class="doc">cluster/atom</span></a> - cluster ID for each atom</li>
<li><a class="reference internal" href="compute_cna_atom.html"><span class="doc">cna/atom</span></a> - common neighbor analysis (CNA) for each atom</li>
<li><a class="reference internal" href="compute_com.html"><span class="doc">com</span></a> - center-of-mass of group of atoms</li>
<li><a class="reference internal" href="compute_com_chunk.html"><span class="doc">com/chunk</span></a> - center-of-mass for each chunk</li>
<li><a class="reference internal" href="compute_contact_atom.html"><span class="doc">contact/atom</span></a> - contact count for each spherical particle</li>
<li><a class="reference internal" href="compute_coord_atom.html"><span class="doc">coord/atom</span></a> - coordination number for each atom</li>
<li><a class="reference internal" href="compute_damage_atom.html"><span class="doc">damage/atom</span></a> - Peridynamic damage for each atom</li>
<li><a class="reference internal" href="compute_dihedral_local.html"><span class="doc">dihedral/local</span></a> - angle of each dihedral</li>
<li><a class="reference internal" href="compute_dilatation_atom.html"><span class="doc">dilatation/atom</span></a> - Peridynamic dilatation for each atom</li>
<li><a class="reference internal" href="compute_displace_atom.html"><span class="doc">displace/atom</span></a> - displacement of each atom</li>
<li><a class="reference internal" href="compute_erotate_asphere.html"><span class="doc">erotate/asphere</span></a> - rotational energy of aspherical particles</li>
<li><a class="reference internal" href="compute_erotate_rigid.html"><span class="doc">erotate/rigid</span></a> - rotational energy of rigid bodies</li>
<li><a class="reference internal" href="compute_erotate_sphere.html"><span class="doc">erotate/sphere</span></a> - rotational energy of spherical particles</li>
<li><a class="reference internal" href="compute_erotate_sphere.html"><span class="doc">erotate/sphere/atom</span></a> - rotational energy for each spherical particle</li>
<li><a class="reference internal" href="compute_event_displace.html"><span class="doc">event/displace</span></a> - detect event on atom displacement</li>
<li><a class="reference internal" href="compute_group_group.html"><span class="doc">group/group</span></a> - energy/force between two groups of atoms</li>
<li><a class="reference internal" href="compute_gyration.html"><span class="doc">gyration</span></a> - radius of gyration of group of atoms</li>
<li><a class="reference internal" href="compute_gyration_chunk.html"><span class="doc">gyration/chunk</span></a> - radius of gyration for each chunk</li>
<li><a class="reference internal" href="compute_heat_flux.html"><span class="doc">heat/flux</span></a> - heat flux through a group of atoms</li>
<li><a class="reference internal" href="compute_hexorder_atom.html"><span class="doc">hexorder/atom</span></a> - bond orientational order parameter q6</li>
<li><a class="reference internal" href="compute_improper_local.html"><span class="doc">improper/local</span></a> - angle of each improper</li>
<li><a class="reference internal" href="compute_inertia_chunk.html"><span class="doc">inertia/chunk</span></a> - inertia tensor for each chunk</li>
<li><a class="reference internal" href="compute_ke_atom.html"><span class="doc">ke/atom</span></a> - kinetic energy for each atom</li>
<li><a class="reference internal" href="compute_ke_rigid.html"><span class="doc">ke/rigid</span></a> - translational kinetic energy of rigid bodies</li>
<li><a class="reference internal" href="compute_msd.html"><span class="doc">msd</span></a> - mean-squared displacement of group of atoms</li>
<li><a class="reference internal" href="compute_msd_chunk.html"><span class="doc">msd/chunk</span></a> - mean-squared displacement for each chunk</li>
<li><a class="reference internal" href="compute_msd_nongauss.html"><span class="doc">msd/nongauss</span></a> - MSD and non-Gaussian parameter of group of atoms</li>
<li><a class="reference internal" href="compute_omega_chunk.html"><span class="doc">omega/chunk</span></a> - angular velocity for each chunk</li>
<li><a class="reference internal" href="compute_orientorder_atom.html"><span class="doc">orientorder/atom</span></a> - Steinhardt bond orientational order parameters Ql</li>
<li><a class="reference internal" href="compute_pair.html"><span class="doc">pair</span></a> - values computed by a pair style</li>
<li><a class="reference internal" href="compute_pair_local.html"><span class="doc">pair/local</span></a> - distance/energy/force of each pairwise interaction</li>
<li><a class="reference internal" href="compute_pe_atom.html"><span class="doc">pe/atom</span></a> - potential energy for each atom</li>
<li><a class="reference internal" href="compute_plasticity_atom.html"><span class="doc">plasticity/atom</span></a> - Peridynamic plasticity for each atom</li>
<li><a class="reference internal" href="compute_pressure.html"><span class="doc">pressure</span></a> - total pressure and pressure tensor</li>
<li><a class="reference internal" href="compute_property_atom.html"><span class="doc">property/atom</span></a> - convert atom attributes to per-atom vectors/arrays</li>
<li><a class="reference internal" href="compute_property_local.html"><span class="doc">property/local</span></a> - convert local attributes to localvectors/arrays</li>
<li><a class="reference internal" href="compute_property_chunk.html"><span class="doc">property/chunk</span></a> - extract various per-chunk attributes</li>
<li><a class="reference internal" href="compute_rdf.html"><span class="doc">rdf</span></a> - radial distribution function g(r) histogram of group of atoms</li>
<li><a class="reference internal" href="compute_reduce.html"><span class="doc">reduce</span></a> - combine per-atom quantities into a single global value</li>
<li><a class="reference internal" href="compute_reduce.html"><span class="doc">reduce/region</span></a> - same as compute reduce, within a region</li>
<li><a class="reference internal" href="compute_rigid_local.html"><span class="doc">rigid/local</span></a> - extract rigid body attributes</li>
<li><a class="reference internal" href="compute_slice.html"><span class="doc">slice</span></a> - extract values from global vector or array</li>
<li><a class="reference internal" href="compute_sna_atom.html"><span class="doc">sna/atom</span></a> - calculate bispectrum coefficients for each atom</li>
<li><a class="reference internal" href="compute_sna_atom.html"><span class="doc">snad/atom</span></a> - derivative of bispectrum coefficients for each atom</li>
<li><a class="reference internal" href="compute_sna_atom.html"><span class="doc">snav/atom</span></a> - virial contribution from bispectrum coefficients for each atom</li>
<li><a class="reference internal" href="compute_stress_atom.html"><span class="doc">stress/atom</span></a> - stress tensor for each atom</li>
<li><a class="reference internal" href="compute_temp.html"><span class="doc">temp</span></a> - temperature of group of atoms</li>
<li><a class="reference internal" href="compute_temp_asphere.html"><span class="doc">temp/asphere</span></a> - temperature of aspherical particles</li>
<li><a class="reference internal" href="compute_temp_body.html"><span class="doc">temp/body</span></a> - temperature of body particles</li>
<li><a class="reference internal" href="compute_temp_chunk.html"><span class="doc">temp/chunk</span></a> - temperature of each chunk</li>
<li><a class="reference internal" href="compute_temp_com.html"><span class="doc">temp/com</span></a> - temperature after subtracting center-of-mass velocity</li>
<li><a class="reference internal" href="compute_temp_partial.html"><span class="doc">temp/partial</span></a> - temperature excluding one or more dimensions of velocity</li>
<li><a class="reference internal" href="compute_temp_profile.html"><span class="doc">temp/profile</span></a> - temperature excluding a binned velocity profile</li>
<li><a class="reference internal" href="compute_torque_chunk.html"><span class="doc">torque/chunk</span></a> - torque applied on each chunk</li>
<li><a class="reference internal" href="compute_vacf.html"><span class="doc">vacf</span></a> - velocity-autocorrelation function of group of atoms</li>
<li><a class="reference internal" href="compute_vcm_chunk.html"><span class="doc">vcm/chunk</span></a> - velocity of center-of-mass for each chunk</li>
<li><a class="reference internal" href="compute_voronoi_atom.html"><span class="doc">voronoi/atom</span></a> - Voronoi volume and neighbors for each atom</li>
</ul>
<p>There are also additional compute styles submitted by users which are
included in the LAMMPS distribution. The list of these with links to
the individual styles are given in the compute section of <a class="reference internal" href="Section_commands.html#cmd-5"><span class="std std-ref">this page</span></a>.</p>
<p>There are also additional accelerated compute styles included in the
LAMMPS distribution for faster performance on CPUs and GPUs. The list
of these with links to the individual styles are given in the pair
section of <a class="reference internal" href="Section_commands.html#cmd-5"><span class="std std-ref">this page</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Define a computation that calculates properties of individual bond
interactions. The number of datums generated, aggregated across all
processors, equals the number of bonds in the system, modified
by the group parameter as explained below.</p>
<p>The value <em>dist</em> is the length of the bond.</p>
<p>The value <em>eng</em> is the interaction energy for the bond.</p>
<p>The value <em>force</em> is the force acting between the pair of atoms in the
bond.</p>
<p>The local data stored by this command is generated by looping over all
the atoms owned on a processor and their bonds. A bond will only be
included if both atoms in the bond are in the specified compute group.
Any bonds that have been broken (see the <a class="reference internal" href="bond_style.html"><span class="doc">bond_style</span></a>
command) by setting their bond type to 0 are not included. Bonds that
have been turned off (see the <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> or
<a class="reference internal" href="delete_bonds.html"><span class="doc">delete_bonds</span></a> commands) by setting their bond type
negative are written into the file, but their energy will be 0.0.</p>
<p>Note that as atoms migrate from processor to processor, there will be
no consistent ordering of the entries within the local vector or array
from one timestep to the next. The only consistency that is
guaranteed is that the ordering on a particular timestep will be the
same for local vectors or arrays generated by other compute commands.
For example, bond output from the <a class="reference internal" href="compute_property_local.html"><span class="doc">compute property/local</span></a> command can be combined
with data from this command and output by the <a class="reference internal" href="dump.html"><span class="doc">dump local</span></a>
+dump 1 all local 1000 tmp.dump index c_1[1] c_1[2] c_1[3] c_2[1] c_2[2]
+</pre>
<p><strong>Output info:</strong></p>
<p>This compute calculates a local vector or local array depending on the
number of keywords. The length of the vector or number of rows in the
array is the number of bonds. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
uses local values from a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">this section</span></a> for an overview of LAMMPS output
options.</p>
<p>The output for <em>dist</em> will be in distance <a class="reference internal" href="units.html"><span class="doc">units</span></a>. The
output for <em>eng</em> will be in energy <a class="reference internal" href="units.html"><span class="doc">units</span></a>. The output for
<em>force</em> will be in force <a class="reference internal" href="units.html"><span class="doc">units</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where the <em>N</em> nearest neighbors of each atom are identified and Ri and
Ri+N/2 are vectors from the central atom to a particular pair of
nearest neighbors. There are N*(N-1)/2 possible neighbor pairs that
can contribute to this formula. The quantity in the sum is computed
for each, and the N/2 smallest are used. This will typically be for
pairs of atoms in symmetrically opposite positions with respect to the
central atom; hence the i+N/2 notation.</p>
<p><em>N</em> is an input parameter, which should be set to correspond to the
number of nearest neighbors in the underlying lattice of atoms. If
the keyword <em>fcc</em> or <em>bcc</em> is used, <em>N</em> is set to 12 and 8
respectively. More generally, <em>N</em> can be set to a positive, even
integer.</p>
<p>For an atom on a lattice site, surrounded by atoms on a perfect
lattice, the centro-symmetry parameter will be 0. It will be near 0
for small thermal perturbations of a perfect lattice. If a point
defect exists, the symmetry is broken, and the parameter will be a
larger positive value. An atom at a surface will have a large
positive parameter. If the atom does not have <em>N</em> neighbors (within
the potential cutoff), then its centro-symmetry parameter is set to
0.0.</p>
<p>If the keyword <em>axes</em> has the setting <em>yes</em>, 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,
i.e. the two most symmetric pairs of atoms. The third vector is
normal to the first two by the right-hand rule. All three vectors are
normalized to unit length. For FCC crystals, the first two vectors
will lie along a <110> direction, while the third vector will lie
along either a <100> or <111> direction. For HCP crystals, the first
two vectors will lie along <1000> directions, while the third vector
will lie along <0001>. This provides a simple way to measure local
orientation in HCP structures. In general, the <em>axes</em> keyword can be
used to estimate the orientation of symmetry axes in the neighborhood
of any atom.</p>
<p>Only atoms within the cutoff of the pairwise neighbor list are
considered as possible neighbors. Atoms not in the compute group are
included in the <em>N</em> neighbors used in this calculation.</p>
<p>The neighbor list needed to compute this quantity is constructed each
time the calculation is performed (e.g. each time a snapshot of atoms
is dumped). Thus it can be inefficient to compute/dump this quantity
too frequently or to have multiple compute/dump commands, each with a
<em>centro/atom</em> style.</p>
<p><strong>Output info:</strong></p>
<p>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 <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section_howto 15</span></a> for an overview of LAMMPS output
options.</p>
<p>If the <em>axes</em> keyword setting is <em>yes</em>, 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
columns 5-7 and 8-10.</p>
<p>The centrosymmetry values are unitless values >= 0.0. Their magnitude
depends on the lattice style due to the number of contibuting neighbor
pairs in the summation in the formula above. And it depends on the
local defects surrounding the central atom, as described above. For
the <em>axes yes</em> case, the vector components are also unitless, since
they represent spatial directions.</p>
<p>Here are typical centro-symmetry values, from a a nanoindentation
simulation into gold (FCC). These were provided by Jon Zimmerman
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Define a computation that calculates the dipole vector and total dipole
for multiple chunks of atoms.</p>
<p>In LAMMPS, chunks are collections of atoms defined by a <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> doc page and “<a class="reference internal" href="Section_howto.html#howto-23"><span class="std std-ref">Section_howto 23</span></a> for details of how chunks can be
defined and examples of how they can be used to measure properties of
a system.</p>
<p>This compute calculates the x,y,z coordinates of the dipole vector
and the total dipole moment for each chunk, which includes all effects
due to atoms passing thru periodic boundaries. For chunks with a net
charge the resulting dipole is made position independent by subtracting
the position vector of the center of mass or geometric center times the
net charge from the computed dipole vector.</p>
<p>Note that only atoms in the specified group contribute to the
calculation. The <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command
defines its own group; atoms will have a chunk ID = 0 if they are not
in that group, signifying they are not assigned to a chunk, and will
thus also not contribute to this calculation. You can specify the
“all” group for this command if you simply want to include atoms with
non-zero chunk IDs.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The coordinates of an atom contribute to the chunk’s
dipole in “unwrapped” form, by using the image flags
associated with each atom. See the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command
for a discussion of “unwrapped” coordinates. See the Atoms section of
the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command for a discussion of image flags
and how they are set for each atom. You can reset the image flags
(e.g. to 0) before invoking this compute by using the <a class="reference internal" href="set.html"><span class="doc">set image</span></a> command.</p>
</div>
<p>The simplest way to output the results of the compute com/chunk
calculation to a file is to use the <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a>
<p>This compute calculates a global array where the number of rows = the
number of chunks <em>Nchunk</em> as calculated by the specified <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> 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 <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section_howto 15</span></a> for an overview of LAMMPS output
options.</p>
<p>The array values are “intensive”. The array values will be in
dipole units, i.e. charge units times distance <a class="reference internal" href="units.html"><span class="doc">units</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where <span class="math">\(w_i\)</span> are weights of a numerical quadrature. The <a class="reference internal" href="fix_adapt.html"><span class="doc">fix adapt</span></a> command can be used to define the stages of
<span class="math">\(\lambda\)</span> at which the derivative is calculated and averaged.</p>
<p>The compute fep calculates the exponential Boltzmann term and also the
potential energy difference <span class="math">\(U_1 -U_0\)</span>. By
choosing a very small perturbation <span class="math">\(\delta\)</span> the thermodynamic
integration method can be implemented using a numerical evaluation of
the derivative of the potential energy with respect to <span class="math">\(\lambda\)</span>:</p>
<p>The value of the free energy difference is determined by numerical
root finding to establish the equality.</p>
<p>Concerning the choice of how the atomic parameters are perturbed in
order to setup an alchemical transformation route, several strategies
are available, such as single-topology or double-topology strategies
<a class="reference internal" href="#pearlman"><span class="std std-ref">(Pearlman)</span></a>. The latter does not require modification of
bond lengths, angles or other internal coordinates.</p>
<p>NOTES: This compute command does not take kinetic energy into account,
therefore the masses of the particles should not be modified between
the reference and perturbed states, or along the alchemical
transformation route. This compute command does not change bond
lengths or other internal coordinates <a class="reference internal" href="#boreschkarplus"><span class="std std-ref">(Boresch, Karplus)</span></a>.</p>
<hr class="docutils" />
<p>The <em>pair</em> attribute enables various parameters of potentials defined
by the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> and <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a>
commands to be changed, if the pair style supports it.</p>
<p>The <em>pstyle</em> argument is the name of the pair style. For example,
<em>pstyle</em> could be specified as “lj/cut”. The <em>pparam</em> argument is the
name of the parameter to change. This is a (non-exclusive) list of
pair styles and parameters that can be used with this compute. See
the doc pages for individual pair styles and their energy formulas for
<p>Note that it is easy to add new potentials and their parameters to
this list. All it typically takes is adding an extract() method to
the pair_*.cpp file associated with the potential.</p>
<p>Similar to the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command, I and J can be
specified in one of two ways. Explicit numeric values can be used for
each, as in the 1st example above. I <= J is required. LAMMPS sets
the coefficients for the symmetric J,I interaction to the same
values. A wild-card asterisk can be used in place of or in conjunction
with the I,J arguments to set the coefficients for multiple pairs of
-atom types. This takes the form “*” or “<em>n” or “n</em>” or “m*n”. If N =
+atom types. This takes the form “*” or “*n” or “n*” or “m*n”. If N =
the number of atom types, then an asterisk with no numeric values
means all types from 1 to N. A leading asterisk means all types from
1 to n (inclusive). A trailing asterisk means all types from n to N
(inclusive). A middle asterisk means all types from m to n
(inclusive). Note that only type pairs with I <= J are considered; if
asterisks imply type pairs where J < I, they are ignored.</p>
<p>If <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid or hybrid/overlay</span></a> is being
used, then the <em>pstyle</em> will be a sub-style name. You must specify
I,J arguments that correspond to type pair values defined (via the
<a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command) for that sub-style.</p>
<p>The <em>v_name</em> argument for keyword <em>pair</em> is the name of an
<a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> which will be evaluated each time
this compute is invoked. It should be specified as v_name, where name
is the variable name.</p>
<hr class="docutils" />
<p>The <em>atom</em> attribute enables atom properties to be changed. The
<em>aparam</em> argument is the name of the parameter to change. This is the
current list of atom parameters that can be used with this compute:</p>
<ul class="simple">
<li>charge = charge on particle</li>
</ul>
<p>The <em>v_name</em> argument for keyword <em>pair</em> is the name of an
<a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> which will be evaluated each time
this compute is invoked. It should be specified as v_name, where name
is the variable name.</p>
<hr class="docutils" />
<p>The <em>tail</em> keyword controls the calculation of the tail correction to
“van der Waals” pair energies beyond the cutoff, if this has been
activated via the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> command. If the
perturbation is small, the tail contribution to the energy difference
between the reference and perturbed systems should be negligible.</p>
<p>If the keyword <em>volume</em> = <em>yes</em>, then the Boltzmann term is multiplied
by the volume so that correct ensemble averaging can be performed over
trajectories during which the volume fluctuates or changes <a class="reference internal" href="#allentildesley"><span class="std std-ref">(Allen and Tildesley)</span></a>:</p>
<p>This compute calculates a global vector of length 3 which contains the
energy difference ( <span class="math">\(U_1-U_0\)</span> ) as c_ID[1], the
Boltzmann factor <span class="math">\(\exp(-(U_1-U_0)/kT)\)</span>, or
<span class="math">\(V \exp(-(U_1-U_0)/kT)\)</span>, as c_ID[2] and the
volume of the simulation box <span class="math">\(V\)</span> as c_ID[3]. <span class="math">\(U_1\)</span> is the
pair potential energy obtained with the perturbed parameters and
<span class="math">\(U_0\)</span> is the pair potential energy obtained with the
unperturbed parameters. The energies include kspace terms if these
are used in the simulation.</p>
<p>These output results can be used by any command that uses a global
scalar or vector from a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section_howto 15</span></a> for an overview of LAMMPS output
options. For example, the computed values can be averaged using <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a>.</p>
<p>The values calculated by this compute are “extensive”.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This compute is distributed as the USER-FEP package. It is only
enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Define a computation that calculates the radius of gyration Rg for
multiple chunks of atoms.</p>
<p>In LAMMPS, chunks are collections of atoms defined by a <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> doc page and “<a class="reference internal" href="Section_howto.html#howto-23"><span class="std std-ref">Section_howto 23</span></a> for details of how chunks can be
defined and examples of how they can be used to measure properties of
a system.</p>
<p>This compute calculates the radius of gyration Rg for each chunk,
which includes all effects due to atoms passing thru periodic
boundaries.</p>
<p>Rg is a measure of the size of a chunk, and is computed by this
<p>where M is the total mass of the chunk, Rcm is the center-of-mass
position of the chunk, and the sum is over all atoms in the
chunk.</p>
<p>Note that only atoms in the specified group contribute to the
calculation. The <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command
defines its own group; atoms will have a chunk ID = 0 if they are not
in that group, signifying they are not assigned to a chunk, and will
thus also not contribute to this calculation. You can specify the
“all” group for this command if you simply want to include atoms with
non-zero chunk IDs.</p>
<p>If the <em>tensor</em> keyword is specified, then the scalar Rg value is not
calculated, but an Rg tensor is instead calculated for each chunk.
The formula for the components of the tensor is the same as the above
formula, except that (Ri - Rcm)^2 is replaced by (Rix - Rcmx) * (Riy -
Rcmy) for the xy component, etc. The 6 components of the tensor are
ordered xx, yy, zz, xy, xz, yz.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The coordinates of an atom contribute to Rg in “unwrapped” form,
by using the image flags associated with each atom. See the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command for a discussion of “unwrapped” coordinates.
See the Atoms section of the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command for a
discussion of image flags and how they are set for each atom. You can
reset the image flags (e.g. to 0) before invoking this compute by
using the <a class="reference internal" href="set.html"><span class="doc">set image</span></a> command.</p>
</div>
<p>The simplest way to output the results of the compute gyration/chunk
calculation to a file is to use the <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a>
<p>This compute calculates a global vector if the <em>tensor</em> keyword is not
specified and a global array if it is. The length of the vector or
number of rows in the array = the number of chunks <em>Nchunk</em> as
calculated by the specified <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command. If the <em>tensor</em> keyword
is specified, the global array has 6 columns. The vector or array can
be accessed by any command that uses global values from a compute as
input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">this section</span></a> for an overview
of LAMMPS output options.</p>
<p>All the vector or array values calculated by this compute are
“intensive”. The vector or array values will be in distance
<a class="reference internal" href="units.html"><span class="doc">units</span></a>, since they are the square root of values
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Define a computation that calculates the heat flux vector based on
contributions from atoms in the specified group. This can be used by
itself to measure the heat flux into or out of a reservoir of atoms,
or to calculate a thermal conductivity using the Green-Kubo formalism.</p>
<p>See the <a class="reference internal" href="fix_thermal_conductivity.html"><span class="doc">fix thermal/conductivity</span></a>
command for details on how to compute thermal conductivity in an
alternate way, via the Muller-Plathe method. See the <a class="reference internal" href="fix_heat.html"><span class="doc">fix heat</span></a> command for a way to control the heat added or
subtracted to a group of atoms.</p>
<p>The compute takes three arguments which are IDs of other
<a class="reference internal" href="compute.html"><span class="doc">computes</span></a>. One calculates per-atom kinetic energy
(<em>ke-ID</em>), one calculates per-atom potential energy (<em>pe-ID)</em>, and the
third calcualtes per-atom stress (<em>stress-ID</em>).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">These other computes should provide values for all the atoms in
the group this compute specifies. That means the other computes could
use the same group as this compute, or they can just use group “all”
(or any group whose atoms are superset of the atoms in this compute’s
group). LAMMPS does not check for this.</p>
</div>
<p>The Green-Kubo formulas relate the ensemble average of the
auto-correlation of the heat flux J to the thermal conductivity kappa:</p>
<p>Ei in the first term of the equation for J is the per-atom energy
(potential and kinetic). This is calculated by the computes <em>ke-ID</em>
and <em>pe-ID</em>. Si in the second term of the equation for J is the
per-atom stress tensor calculated by the compute <em>stress-ID</em>. The
tensor multiplies Vi as a 3x3 matrix-vector multiply to yield a
vector. Note that as discussed below, the 1/V scaling factor in the
equation for J is NOT included in the calculation performed by this
compute; you need to add it for a volume appropriate to the atoms
included in the calculation.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The <a class="reference internal" href="compute_pe_atom.html"><span class="doc">compute pe/atom</span></a> and <a class="reference internal" href="compute_stress_atom.html"><span class="doc">compute stress/atom</span></a> commands have options for which
terms to include in their calculation (pair, bond, etc). The heat
flux calculation will thus include exactly the same terms. Normally
you should use <a class="reference internal" href="compute_stress_atom.html"><span class="doc">compute stress/atom virial</span></a>
so as not to include a kinetic energy term in the heat flux.</p>
</div>
<p>This compute calculates 6 quantities and stores them in a 6-component
vector. The first 3 components are the x, y, z components of the full
heat flux vector, i.e. (Jx, Jy, Jz). The next 3 components are the x,
y, z components of just the convective portion of the flux, i.e. the
first term in the equation for J above.</p>
<hr class="docutils" />
<p>The heat flux can be output every so many timesteps (e.g. via the
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command). Then as a
post-processing operation, an autocorrelation can be performed, its
integral estimated, and the Green-Kubo formula above evaluated.</p>
<p>The <a class="reference internal" href="fix_ave_correlate.html"><span class="doc">fix ave/correlate</span></a> command can calclate
the autocorrelation. The trap() function in the
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command can calculate the integral.</p>
<p>An example LAMMPS input script for solid Ar is appended below. The
result should be: average conductivity ~0.29 in W/mK.</p>
<hr class="docutils" />
<p><strong>Output info:</strong></p>
<p>This compute calculates a global vector of length 6 (total heat flux
vector, followed by convective heat flux vector), which can be
accessed by indices 1-6. These values can be used by any command that
uses global vector values from a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">this section</span></a> for an overview of LAMMPS output
options.</p>
<p>The vector values calculated by this compute are “extensive”, meaning
they scale with the number of atoms in the simulation. They can be
divided by the appropriate volume to get a flux, which would then be
an “intensive” value, meaning independent of the number of atoms in
the simulation. Note that if the compute is “all”, then the
appropriate volume to divide by is the simulation box volume.
However, if a sub-group is used, it should be the volume containing
those atoms.</p>
<p>The vector values will be in energy*velocity <a class="reference internal" href="units.html"><span class="doc">units</span></a>. Once
divided by a volume the units will be that of flux, namely
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Define a computation that calculates the inertia tensor for multiple
chunks of atoms.</p>
<p>In LAMMPS, chunks are collections of atoms defined by a <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> doc page and “<a class="reference internal" href="Section_howto.html#howto-23"><span class="std std-ref">Section_howto 23</span></a> for details of how chunks can be
defined and examples of how they can be used to measure properties of
a system.</p>
<p>This compute calculates the 6 components of the symmetric intertia
tensor for each chunk, ordered Ixx,Iyy,Izz,Ixy,Iyz,Ixz. The
calculation includes all effects due to atoms passing thru periodic
boundaries.</p>
<p>Note that only atoms in the specified group contribute to the
calculation. The <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command
defines its own group; atoms will have a chunk ID = 0 if they are not
in that group, signifying they are not assigned to a chunk, and will
thus also not contribute to this calculation. You can specify the
“all” group for this command if you simply want to include atoms with
non-zero chunk IDs.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The coordinates of an atom contribute to the chunk’s inertia
tensor in “unwrapped” form, by using the image flags associated with
each atom. See the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command for a discussion
of “unwrapped” coordinates. See the Atoms section of the
<a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command for a discussion of image flags and
how they are set for each atom. You can reset the image flags
(e.g. to 0) before invoking this compute by using the <a class="reference internal" href="set.html"><span class="doc">set image</span></a> command.</p>
</div>
<p>The simplest way to output the results of the compute inertia/chunk
calculation to a file is to use the <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a>
<p>This compute calculates a global array where the number of rows = the
number of chunks <em>Nchunk</em> as calculated by the specified <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command. The number of columns =
6 for the 6 components of the inertia tensor for each chunk, ordered
as listed above. These values can be accessed by any command that
uses global array values from a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section_howto 15</span></a> for an overview of LAMMPS output
options.</p>
<p>The array values are “intensive”. The array values will be in
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Define a computation that calculates the per-atom translational
(nuclei and electrons) and radial kinetic energy (electron only) in a
group. The particles are assumed to be nuclei and electrons modeled
with the <a class="reference internal" href="pair_eff.html"><span class="doc">electronic force field</span></a>.</p>
<p>The kinetic energy for each nucleus is computed as 1/2 m v^2, where m
corresponds to the corresponding nuclear mass, and the kinetic energy
for each electron is computed as 1/2 (me v^2 + 3/4 me s^2), where me
and v correspond to the mass and translational velocity of each
electron, and s to its radial velocity, respectively.</p>
<p>There is a subtle difference between the quantity calculated by this
compute and the kinetic energy calculated by the <em>ke</em> or <em>etotal</em>
keyword used in thermodynamic output, as specified by the
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command. For this compute, kinetic
energy is “translational” plus electronic “radial” kinetic energy,
calculated by the simple formula above. For thermodynamic output, the
<em>ke</em> keyword infers kinetic energy from the temperature of the system
with 1/2 Kb T of energy for each (nuclear-only) degree of freedom in
eFF.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The temperature in eFF should be monitored via the <a class="reference internal" href="compute_temp_eff.html"><span class="doc">compute temp/eff</span></a> command, which can be printed with
thermodynamic output by using the <a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify</span></a>
<p>The value of the kinetic energy will be 0.0 for atoms (nuclei or
electrons) not in the specified compute group.</p>
<p><strong>Output info:</strong></p>
<p>This compute calculates a scalar quantity for each atom, which can be
accessed by any command that uses per-atom computes as input. See
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section_howto 15</span></a> for an overview of
LAMMPS output options.</p>
<p>The per-atom vector values will be in energy <a class="reference internal" href="units.html"><span class="doc">units</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This compute is part of the USER-EFF package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Define a computation that calculates the kinetic energy of motion of a
group of eFF particles (nuclei and electrons), as modeled with the
<a class="reference internal" href="pair_eff.html"><span class="doc">electronic force field</span></a>.</p>
<p>The kinetic energy for each nucleus is computed as 1/2 m v^2 and the
kinetic energy for each electron is computed as 1/2(me v^2 + 3/4 me
s^2), where m corresponds to the nuclear mass, me to the electron
mass, v to the translational velocity of each particle, and s to the
radial velocity of the electron, respectively.</p>
<p>There is a subtle difference between the quantity calculated by this
compute and the kinetic energy calculated by the <em>ke</em> or <em>etotal</em>
keyword used in thermodynamic output, as specified by the
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command. For this compute, kinetic
energy is “translational” and “radial” (only for electrons) kinetic
energy, calculated by the simple formula above. For thermodynamic
output, the <em>ke</em> keyword infers kinetic energy from the temperature of
the system with 1/2 Kb T of energy for each degree of freedom. For
the eFF temperature computation via the <a class="reference internal" href="compute_temp_eff.html"><span class="doc">compute temp_eff</span></a> command, these are the same. But
different computes that calculate temperature can subtract out
different non-thermal components of velocity and/or include other
degrees of freedom.</p>
<p>IMPRORTANT NOTE: The temperature in eFF models should be monitored via
the <a class="reference internal" href="compute_temp_eff.html"><span class="doc">compute temp/eff</span></a> command, which can be
printed with thermodynamic output by using the
<a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify</span></a> command, as shown in the following
<p>This compute calculates a global scalar (the KE). This value can be
used by any command that uses a global scalar value from a compute as
input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section_howto 15</span></a> for an
overview of LAMMPS output options.</p>
<p>The scalar value calculated by this compute is “extensive”. The
scalar value will be in energy <a class="reference internal" href="units.html"><span class="doc">units</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This compute is part of the USER-EFF package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Modify one or more parameters of a previously defined compute. Not
all compute styles support all parameters.</p>
<p>The <em>extra</em> keyword refers to how many degrees-of-freedom are
subtracted (typically from 3N) as a normalizing factor in a
temperature computation. Only computes that compute a temperature use
this option. The default is 2 or 3 for <a class="reference internal" href="dimension.html"><span class="doc">2d or 3d systems</span></a> which is a correction factor for an ensemble
of velocities with zero total linear momentum. For compute
temp/partial, if one or more velocity components are excluded, the
value used for <em>extra</em> is scaled accordingly. You can use a negative
number for the <em>extra</em> parameter if you need to add
degrees-of-freedom. See the <a class="reference internal" href="compute_temp_asphere.html"><span class="doc">compute temp/asphere</span></a> command for an example.</p>
<p>The <em>dynamic</em> keyword determines whether the number of atoms N in the
compute group is re-computed each time a temperature is computed.
Only compute styles that calculate a temperature use this option. By
default, N is assumed to be constant. If you are adding atoms to the
system (see the <a class="reference internal" href="fix_pour.html"><span class="doc">fix pour</span></a> or <a class="reference internal" href="fix_deposit.html"><span class="doc">fix deposit</span></a> commands) or expect atoms to be lost
(e.g. due to evaporation), then this option should be used to insure
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
pairwise interactions between 1-4 atoms. The energy contribution of
these terms is included in the pair energy, not the dihedral energy.</p>
<p>The KSpace contribution is calculated using the method in
<a class="reference internal" href="compute_stress_atom.html#heyes"><span class="std std-ref">(Heyes)</span></a> for the Ewald method and a related method for PPPM,
as specified by the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style pppm</span></a> command.
For PPPM, the calcluation requires 1 extra FFT each timestep that
per-atom energy is calculated. Thie <a class="reference external" href="PDF/kspace.pdf">document</a>
describes how the long-range per-atom energy calculation is performed.</p>
<p>Various fixes can contribute to the per-atom potential energy of the
system if the <em>fix</em> contribution is included. See the doc pages for
<a class="reference internal" href="fix.html"><span class="doc">individual fixes</span></a> for details of which ones compute a
per-atom potential energy.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify energy yes</span></a> command must also be
specified if a fix is to contribute per-atom potential energy to this
command.</p>
</div>
<p>As an example of per-atom potential energy compared to total potential
energy, these lines in an input script should yield the same result
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command</li>
<li>pressure = style name of this compute command</li>
<li>temp-ID = ID of compute that calculates temperature, can be NULL if not needed</li>
<li>zero or more keywords may be appended</li>
<li>keyword = <em>ke</em> or <em>pair</em> or <em>bond</em> or <em>angle</em> or <em>dihedral</em> or <em>improper</em> or <em>kspace</em> or <em>fix</em> or <em>virial</em></li>
<p>Define a computation that calculates the pressure of the entire system
of atoms. The specified group must be “all”. See the <a class="reference internal" href="compute_stress_atom.html"><span class="doc">compute stress/atom</span></a> command if you want per-atom
pressure (stress). These per-atom values could be summed for a group
of atoms via the <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a> command.</p>
<p>If no extra keywords are listed, the entire equations above are
calculated. This includes a kinetic energy (temperature) term and the
virial as the sum of pair, bond, angle, dihedral, improper, kspace
(long-range), and fix contributions to the force on each atom. If any
extra keywords are listed, then only those components are summed to
compute temperature or ke and/or the virial. The <em>virial</em> keyword
means include all terms except the kinetic energy <em>ke</em>.</p>
<p>Details of how LAMMPS computes the virial efficiently for the entire
system, including the effects of periodic boundary conditions is
discussed in <a class="reference internal" href="compute_stress_atom.html#thompson"><span class="std std-ref">(Thompson)</span></a>.</p>
<p>The temperature and kinetic energy tensor is not calculated by this
compute, but rather by the temperature compute specified with the
command. If the kinetic energy is not included in the pressure, than
the temperature compute is not used and can be specified as NULL.
Normally the temperature compute used by compute pressure should
calculate the temperature of all atoms for consistency with the virial
term, but any compute style that calculates temperature can be used,
e.g. one that excludes frozen atoms or other degrees of freedom.</p>
<p>Note that if desired the specified temperature compute can be one that
subtracts off a bias to calculate a temperature using only the thermal
velocity of the atoms, e.g. by subtracting a background streaming
velocity. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias.</p>
<p>Also note that the N in the first formula above is really
degrees-of-freedom divided by d = dimensionality, where the DOF value
is calcluated by the temperature compute. See the various <a class="reference internal" href="compute.html"><span class="doc">compute temperature</span></a> styles for details.</p>
<p>A compute of this style with the ID of “thermo_press” is created when
LAMMPS starts up, as if this command were in the input script:</p>
<p>where “thermo_temp” is the ID of a similarly defined compute of style
“temp”. See the “thermo_style” command for more details.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<hr class="docutils" />
<p><strong>Output info:</strong></p>
<p>This compute calculates a global scalar (the pressure) and a global
vector of length 6 (pressure tensor), which can be accessed by indices
1-6. These values can be used by any command that uses global scalar
or vector values from a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">this section</span></a> for an overview of LAMMPS output
options.</p>
<p>The scalar and vector values calculated by this compute are
“intensive”. The scalar and vector values will be in pressure
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The list of possible attributes is the same as that used by the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command, which describes their meaning, with some
additional quantities that are only defined for certain <a class="reference internal" href="atom_style.html"><span class="doc">atom styles</span></a>. Basically, this augmented list gives an
input script access to any per-atom quantity stored by LAMMPS.</p>
<p>The values are stored in a per-atom vector or array as discussed
below. Zeroes are stored for atoms not in the specified group or for
quantities that are not defined for a particular particle in the group
(e.g. <em>shapex</em> if the particle is not an ellipsoid).</p>
<p>The additional quantities only accessible via this command, and not
directly via the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command, are as follows.</p>
<p><em>Shapex</em>, <em>shapey</em>, and <em>shapez</em> are defined for ellipsoidal particles
and define the 3d shape of each particle.</p>
<p><em>Quatw</em>, <em>quati</em>, <em>quatj</em>, and <em>quatk</em> are defined for ellipsoidal
particles and body particles and store the 4-vector quaternion
representing the orientation of each particle. See the <a class="reference internal" href="set.html"><span class="doc">set</span></a>
command for an explanation of the quaternion vector.</p>
<p><em>End1x</em>, <em>end1y</em>, <em>end1z</em>, <em>end2x</em>, <em>end2y</em>, <em>end2z</em>, are defined for
line segment particles and define the end points of each line segment.</p>
<em>corner2z</em>, <em>corner3x</em>, <em>corner3y</em>, <em>corner3z</em>, are defined for
triangular particles and define the corner points of each triangle.</p>
<p><em>Nbonds</em> is available for all molecular atom styles and refers to the
number of explicit bonds assigned to an atom. Note that if the
<a class="reference internal" href="newton.html"><span class="doc">newton bond</span></a> command is set to <em>on</em>, which is the
default, then every bond in the system is assigned to only one of the
two atoms in the bond. Thus a bond between atoms I,J may be tallied
for either atom I or atom J. If <a class="reference internal" href="newton.html"><span class="doc">newton bond off</span></a> is set,
it will be tallied with both atom I and atom J.</p>
<p>The <em>i_name</em> and <em>d_name</em> attributes refer to custom integer and
floating-point properties that have been added to each atom via the
<a class="reference internal" href="fix_property_atom.html"><span class="doc">fix property/atom</span></a> command. When that command
is used specific names are given to each attribute which are what is
specified as the “name” portion of <em>i_name</em> or <em>d_name</em>.</p>
<p><strong>Output info:</strong></p>
<p>This compute calculates a per-atom vector or per-atom array depending
on the number of input values. If a single input is specified, a
per-atom vector is produced. If two or more inputs are specified, a
per-atom array is produced where the number of columns = the number of
inputs. The vector or array can be accessed by any command that uses
per-atom values from a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">this section</span></a> for an overview of LAMMPS output
options.</p>
<p>The vector or array values will be in whatever <a class="reference internal" href="units.html"><span class="doc">units</span></a> the
corresponding attribute is in, e.g. velocity units for vx, charge
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command</li>
<li>property/chunk = style name of this compute command</li>
<li>input = one or more attributes</li>
</ul>
<pre class="literal-block">
attributes = count, id, coord1, coord2, coord3
count = # of atoms in chunk
id = original chunk IDs before compression by <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a>
coord123 = coordinates for spatial bins calculated by <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a>
<p>Define a computation that stores the specified attributes of chunks of
atoms.</p>
<p>In LAMMPS, chunks are collections of atoms defined by a <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> doc page and “<a class="reference internal" href="Section_howto.html#howto-23"><span class="std std-ref">Section_howto 23</span></a> for details of how chunks can be
defined and examples of how they can be used to measure properties of
a system.</p>
<p>This compute calculates and stores the specified attributes of chunks
as global data so they can be accessed by other <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a> and used in conjunction with
other commands that generate per-chunk data, such as <a class="reference internal" href="compute_com_chunk.html"><span class="doc">compute com/chunk</span></a> or <a class="reference internal" href="compute_msd_chunk.html"><span class="doc">compute msd/chunk</span></a>.</p>
<p>Note that only atoms in the specified group contribute to the
calculation of the <em>count</em> attribute. The <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command defines its own group;
atoms will have a chunk ID = 0 if they are not in that group,
signifying they are not assigned to a chunk, and will thus also not
contribute to this calculation. You can specify the “all” group for
this command if you simply want to include atoms with non-zero chunk
IDs.</p>
<p>The <em>count</em> attribute is the number of atoms in the chunk.</p>
<p>The <em>id</em> attribute stores the original chunk ID for each chunk. It
can only be used if the <em>compress</em> keyword was set to <em>yes</em> for the
<a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command referenced by
chunkID. This means that the original chunk IDs (e.g. molecule IDs)
will have been compressed to remove chunk IDs with no atoms assigned
to them. Thus a compresed chunk ID of 3 may correspond to an original
chunk ID (molecule ID in this case) of 415. The <em>id</em> attribute will
then be 415 for the 3rd chunk.</p>
<p>The <em>coordN</em> attributes can only be used if a <em>binning</em> style was used
in the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command referenced
by chunkID. For <em>bin/1d</em>, <em>bin/2d</em>, and <em>bin/3d</em> styles the attribute
is the center point of the bin in the corresponding dimension. Style
<em>bin/1d</em> only defines a <em>coord1</em> attribute. Style <em>bin/2d</em> adds a
<em>coord2</em> attribute. Style <em>bin/3d</em> adds a <em>coord3</em> attribute.</p>
<p>Note that if the value of the <em>units</em> keyword used in the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom command</span></a> is <em>box</em> or <em>lattice</em>, the
<em>coordN</em> attributes will be in distance <a class="reference internal" href="units.html"><span class="doc">units</span></a>. If the
value of the <em>units</em> keyword is <em>reduced</em>, the <em>coordN</em> attributes
will be in unitless reduced units (0-1).</p>
<p>The simplest way to output the results of the compute property/chunk
calculation to a file is to use the <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Define a calculation that “reduces” one or more vector inputs into
scalar values, one per listed input. The inputs can be per-atom or
local quantities; they cannot be global quantities. Atom attributes
are per-atom quantities, <a class="reference internal" href="compute.html"><span class="doc">computes</span></a> and <a class="reference internal" href="fix.html"><span class="doc">fixes</span></a>
may generate any of the three kinds of quantities, and <a class="reference internal" href="variable.html"><span class="doc">atom-style variables</span></a> generate per-atom quantities. See the
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command and its special functions which can
perform the same operations as the compute reduce command on global
vectors.</p>
<p>The reduction operation is specified by the <em>mode</em> setting. The <em>sum</em>
option adds the values in the vector into a global total. The <em>min</em>
or <em>max</em> options find the minimum or maximum value across all vector
values. The <em>ave</em> setting adds the vector values into a global total,
then divides by the number of values in the vector. The <em>sumsq</em>
option sums the square of the values in the vector into a global
total. The <em>avesq</em> setting does the same as <em>sumsq</em>, then divdes the
sum of squares by the number of values. The last two options can be
useful for calculating the variance of some quantity, e.g. variance =
sumsq - ave^2.</p>
<p>Each listed input is operated on independently. For per-atom inputs,
the group specified with this command means only atoms within the
group contribute to the result. For per-atom inputs, if the compute
reduce/region command is used, the atoms must also currently be within
the region. Note that an input that produces per-atom quantities may
define its own group which affects the quantities it returns. For
example, if a compute is used as an input which generates a per-atom
vector, it will generate values of 0.0 for atoms that are not in the
group specified for that compute.</p>
<p>Each listed input can be an atom attribute (position, velocity, force
component) or can be the result of a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> or
<a class="reference internal" href="fix.html"><span class="doc">fix</span></a> or the evaluation of an atom-style
+compute 2 all reduce min myPress[1] myPress[2] myPress[3] &
+ myPress[4] myPress[5] myPress[6]
+</pre>
<hr class="docutils" />
<p>The atom attribute values (x,y,z,vx,vy,vz,fx,fy,fz) are
self-explanatory. Note that other atom attributes can be used as
inputs to this fix by using the <a class="reference internal" href="compute_property_atom.html"><span class="doc">compute property/atom</span></a> command and then specifying
an input value from that compute.</p>
-<p>If a value begins with “<a href="#id1"><span class="problematic" id="id2">c_</span></a>”, a compute ID must follow which has been
+<p>If a value begins with “c_”, a compute ID must follow which has been
previously defined in the input script. Computes can generate
per-atom or local quantities. See the individual
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> doc page for details. If no bracketed integer
is appended, the vector calculated by the compute is used. If a
bracketed integer is appended, the Ith column of the array calculated
by the compute is used. Users can also write code for their own
compute styles and <a class="reference internal" href="Section_modify.html"><span class="doc">add them to LAMMPS</span></a>. See the
discussion above for how I can be specified with a wildcard asterisk
to effectively specify multiple values.</p>
-<p>If a value begins with “<a href="#id3"><span class="problematic" id="id4">f_</span></a>”, a fix ID must follow which has been
+<p>If a value begins with “f_”, a fix ID must follow which has been
previously defined in the input script. Fixes can generate per-atom
or local quantities. See the individual <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> doc page for
details. Note that some fixes only produce their values on certain
timesteps, which must be compatible with when compute reduce
references the values, else an error results. If no bracketed integer
is appended, the vector calculated by the fix is used. If a bracketed
integer is appended, the Ith column of the array calculated by the fix
is used. Users can also write code for their own fix style and <a class="reference internal" href="Section_modify.html"><span class="doc">add them to LAMMPS</span></a>. See the discussion above for how
I can be specified with a wildcard asterisk to effectively specify
multiple values.</p>
-<p>If a value begins with “<a href="#id5"><span class="problematic" id="id6">v_</span></a>”, a variable name must follow which has
+<p>If a value begins with “v_”, a variable name must follow which has
been previously defined in the input script. It must be an
<a class="reference internal" href="variable.html"><span class="doc">atom-style variable</span></a>. Atom-style variables can
reference thermodynamic keywords and various per-atom attributes, or
invoke other computes, fixes, or variables when they are evaluated, so
this is a very general means of generating per-atom quantities to
reduce.</p>
<hr class="docutils" />
<p>If the <em>replace</em> keyword is used, two indices <em>vec1</em> and <em>vec2</em> are
specified, where each index ranges from 1 to the # of input values.
The replace keyword can only be used if the <em>mode</em> is <em>min</em> or <em>max</em>.
It works as follows. A min/max is computed as usual on the <em>vec2</em>
input vector. The index N of that value within <em>vec2</em> is also stored.
Then, instead of performing a min/max on the <em>vec1</em> input vector, the
stored index is used to select the Nth element of the <em>vec1</em> vector.</p>
<p>Thus, for example, if you wish to use this compute to find the bond
with maximum stretch, you can do it as follows:</p>
<p>The first two input values in the compute reduce command are vectors
with the IDs of the 2 atoms in each bond, using the <a class="reference internal" href="compute_property_local.html"><span class="doc">compute property/local</span></a> command. The last input
value is bond distance, using the <a class="reference internal" href="compute_bond_local.html"><span class="doc">compute bond/local</span></a> command. Instead of taking the
max of the two atom ID vectors, which does not yield useful
information in this context, the <em>replace</em> keywords will extract the
atom IDs for the two atoms in the bond of maximum stretch. These atom
IDs and the bond stretch will be printed with thermodynamic output.</p>
<hr class="docutils" />
<p>If a single input is specified this compute produces a global scalar
value. If multiple inputs are specified, this compute produces a
global vector of values, the length of which is equal to the number of
inputs specified.</p>
<p>As discussed below, for the <em>sum</em> and <em>sumsq</em> modes, the value(s)
produced by this compute are all “extensive”, meaning their value
scales linearly with the number of atoms involved. If normalized
values are desired, this compute can be accessed by the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command with <a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify norm yes</span></a> set as an option. Or it can be accessed by a
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> that divides by the appropriate atom count.</p>
<hr class="docutils" />
<p><strong>Output info:</strong></p>
<p>This compute calculates a global scalar if a single input value is
specified or a global vector of length N where N is the number of
inputs, and which can be accessed by indices 1 to N. These values can
be used by any command that uses global scalar or vector values from a
compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section_howto 15</span></a>
for an overview of LAMMPS output options.</p>
<p>All the scalar or vector values calculated by this compute are
“intensive”, except when the <em>sum</em> or <em>sumsq</em> modes are used on
per-atom or local vectors, in which case the calculated values are
“extensive”.</p>
<p>The scalar or vector values will be in whatever <a class="reference internal" href="units.html"><span class="doc">units</span></a> the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Define a computation that simply stores rigid body attributes for
rigid bodies defined by the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid/small</span></a> command
or one of its NVE, NVT, NPT, NPH variants. The data is stored as
local data so it can be accessed by other <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a> that process local data, such as
the <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a> or <a class="reference internal" href="dump.html"><span class="doc">dump local</span></a>
commands.</p>
<p>Note that this command only works with the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid/small</span></a> command or its variants, not the fix rigid
command and its variants. The ID of the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid/small</span></a> command used to define rigid bodies must
be specified as <em>rigidID</em>. The <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> command is
typically used to define a handful of (potentially very large) rigid
bodies. It outputs similar per-body information as this command
directly from the fix as global data; see the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> doc page for details</p>
<p>The local data stored by this command is generated by looping over all
the atoms owned on a processor. If the atom is not in the specified
<em>group-ID</em> or is not part of a rigid body it is skipped. If it is not
the atom within a body that is assigned to store the body information
it is skipped (only one atom per body is so assigned). If it is the
assigned atom, then the info for that body is output. This means that
information for N bodies is generated. N may be less than the # of
bodies defined by the fix rigid command, if the atoms in some bodies
are not in the <em>group-ID</em>.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Which atom in a body owns the body info is determined internal
to LAMMPS; it’s the one nearest the geometric center of the body.
Typically you should avoid this complication, by defining the group
associated with this fix to include/exclude entire bodies.</p>
</div>
<p>Note that as atoms and bodies migrate from processor to processor,
there will be no consistent ordering of the entries within the local
vector or array from one timestep to the next.</p>
<p>Here is an example of how to use this compute to dump rigid body info
+compute 1 all rigid/local myRigid mol x y z fx fy fz
+dump 1 all local 1000 tmp.dump index c_1[1] c_1[2] c_1[3] c_1[4] c_1[5] c_1[6] c_1[7]
+</pre>
<hr class="docutils" />
<p>This section explains the rigid body attributes that can be specified.</p>
<p>The <em>id</em> attribute is the atomID of the atom which owns the rigid body, which is
assigned by the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid/small</span></a> command.</p>
<p>The <em>mol</em> attribute is the molecule ID of the rigid body. It should
be the molecule ID which all of the atoms in the body belong to, since
that is how the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid/small</span></a> command defines its
rigid bodies.</p>
<p>The <em>mass</em> attribute is the total mass of the rigid body.</p>
<p>There are two options for outputting the coordinates of the center of
mass (COM) of the body. The <em>x</em>, <em>y</em>, <em>z</em> attributes write the COM
“unscaled”, in the appropriate distance <a class="reference internal" href="units.html"><span class="doc">units</span></a> (Angstroms,
sigma, etc). Use <em>xu</em>, <em>yu</em>, <em>zu</em> if you want the COM “unwrapped” by
the image flags for each atobody. Unwrapped means that if the body
COM has passed thru a periodic boundary one or more times, the value
is generated what the COM coordinate would be if it had not been
wrapped back into the periodic box.</p>
<p>The image flags for the body can be generated directly using the <em>ix</em>,
<em>iy</em>, <em>iz</em> attributes. For periodic dimensions, they specify which
image of the simulation box the COM is considered to be in. An image
of 0 means it is inside the box as defined. A value of 2 means add 2
box lengths to get the true value. A value of -1 means subtract 1 box
length to get the true value. LAMMPS updates these flags as the rigid
body COMs cross periodic boundaries during the simulation.</p>
<p>The <em>vx</em>, <em>vy</em>, <em>vz</em>, <em>fx</em>, <em>fy</em>, <em>fz</em> attributes are components of
the COM velocity and force on the COM of the body.</p>
<p>The <em>omegax</em>, <em>omegay</em>, and <em>omegaz</em> attributes are the angular
velocity componennts of the body around its COM.</p>
<p>The <em>angmomx</em>, <em>angmomy</em>, and <em>angmomz</em> attributes are the angular
momentum components of the body around its COM.</p>
<p>The <em>quatw</em>, <em>quati</em>, <em>quatj</em>, and <em>quatk</em> attributes are the
components of the 4-vector quaternion representing the orientation of
the rigid body. See the <a class="reference internal" href="set.html"><span class="doc">set</span></a> command for an explanation of
the quaternion vector.</p>
<p>The <em>angmomx</em>, <em>angmomy</em>, and <em>angmomz</em> attributes are the angular
momentum components of the body around its COM.</p>
<p>The <em>tqx</em>, <em>tqy</em>, <em>tqz</em> attributes are components of the torque acting
on the body around its COM.</p>
<p>The <em>inertiax</em>, <em>inertiay</em>, <em>inertiaz</em> attributes are components of
diagonalized inertia tensor for the body, i.e the 3 moments of inertia
for the body around its principal axes, as computed internally by
LAMMPS.</p>
<hr class="docutils" />
<p><strong>Output info:</strong></p>
<p>This compute calculates a local vector or local array depending on the
number of keywords. The length of the vector or number of rows in the
array is the number of rigid bodies. If a single keyword is
specified, a local vector is produced. If two or more keywords are
specified, a local array is produced where the number of columns = the
number of keywords. The vector or array can be accessed by any
command that uses local values from a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">this section</span></a> for an overview of LAMMPS output
options.</p>
<p>The vector or array values will be in whatever <a class="reference internal" href="units.html"><span class="doc">units</span></a> the
<p>This compute is part of the RIGID package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Coefficients parameterized by <a class="reference internal" href="#fox"><span class="std std-ref">(Fox)</span></a> are assigned for each
atom type designating the chemical symbol and charge of each atom
type. Valid chemical symbols for compute saed are:</p>
<dl class="docutils">
<dt>H: He: Li: Be: B:</dt>
<dd><blockquote class="first">
<div>C: N: O: F: Ne:</div></blockquote>
<dl class="docutils">
<dt>Na: Mg: Al: Si: P:</dt>
<dd>S: Cl: Ar: K: Ca:</dd>
</dl>
<p class="last">Sc: Ti: V: Cr: Mn:
Fe: Co: Ni: Cu: Zn:
Ga: Ge: As: Se: Br:
Kr: Rb: Sr: Y: Zr:
Nb: Mo: Tc: Ru: Rh:
Pd: Ag: Cd: In: Sn:
Sb: Te: I: Xe: Cs:
Ba: La: Ce: Pr: Nd:
Pm: Sm: Eu: Gd: Tb:
Dy: Ho: Er: Tm: Yb:
Lu: Hf: Ta: W: Re:
Os: Ir: Pt: Au: Hg:
Tl: Pb: Bi: Po: At:
Rn: Fr: Ra: Ac: Th:
Pa: U: Np: Pu: Am:
Cm: Bk: Cf:tb(c=5,s=:)</p>
</dd>
</dl>
<p>If the <em>echo</em> keyword is specified, compute saed will provide extra
reporting information to the screen.</p>
<p><strong>Output info:</strong></p>
<p>This compute calculates a global vector. The length of the vector is
the number of reciprocal lattice nodes that are explored by the mesh.
The entries of the global vector are the computed diffraction
intensities as described above.</p>
<p>The vector can be accessed by any command that uses global values
from a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">this section</span></a> for an overview of LAMMPS output
options.</p>
<p>All array values calculated by this compute are “intensive”.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This compute is part of the USER-DIFFRACTION package. It is only
enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The compute_saed command does not work for triclinic cells.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The position of a neighbor atom <em>i’</em> relative to a central atom <em>i</em> is
a point within the 3D ball of radius <em>R_ii’ = rcutfac*(R_i + R_i’)</em></p>
<p>Bartok et al. <a class="reference internal" href="pair_snap.html#bartok2010"><span class="std std-ref">(Bartok)</span></a>, proposed mapping this 3D ball
onto the 3-sphere, the surface of the unit ball in a four-dimensional
space. The radial distance <em>r</em> within <em>R_ii’</em> is mapped on to a third
<p>Compute <em>snad/atom</em> evaluates a per-atom array. The columns are
arranged into <em>ntypes</em> blocks, listed in order of atom type <em>I</em>. Each
block contains three sub-blocks corresponding to the <em>x</em>, <em>y</em>, and <em>z</em>
components of the atom position. Each of these sub-blocks contains
one column for each bispectrum component, the same as for compute
<em>sna/atom</em></p>
<p>Compute <em>snav/atom</em> evaluates a per-atom array. The columns are
arranged into <em>ntypes</em> blocks, listed in order of atom type <em>I</em>. Each
block contains six sub-blocks corresponding to the <em>xx</em>, <em>yy</em>, <em>zz</em>,
<em>yz</em>, <em>xz</em>, and <em>xy</em> components of the virial tensor in Voigt
notation. Each of these sub-blocks contains one column for each
bispectrum component, the same as for compute <em>sna/atom</em></p>
<p>These values can be accessed by any command that uses per-atom values
from a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section_howto 15</span></a> for an overview of LAMMPS output
options.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>These computes are part of the SNAP package. They are only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command</li>
<li>stress/atom = style name of this compute command</li>
<li>temp-ID = ID of compute that calculates temperature, can be NULL if not needed</li>
<li>zero or more keywords may be appended</li>
<li>keyword = <em>ke</em> or <em>pair</em> or <em>bond</em> or <em>angle</em> or <em>dihedral</em> or <em>improper</em> or <em>kspace</em> or <em>fix</em> or <em>virial</em></li>
<p>Define a computation that computes the symmetric per-atom stress
tensor for each atom in a group. The tensor for each atom has 6
components and is stored as a 6-element vector in the following order:
xx, yy, zz, xy, xz, yz. See the <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> command if you want the stress tensor
(pressure) of the entire system.</p>
<p>The stress tensor for atom <em>I</em> is given by the following formula,
where <em>a</em> and <em>b</em> take on values x,y,z to generate the 6 components of
<p>The first term is a kinetic energy contribution for atom <em>I</em>. See
details below on how the specified <em>temp-ID</em> can affect the velocities
used in this calculation. The second term is a pairwise energy
contribution where <em>n</em> loops over the <em>Np</em> neighbors of atom <em>I</em>, <em>r1</em>
and <em>r2</em> are the positions of the 2 atoms in the pairwise interaction,
and <em>F1</em> and <em>F2</em> are the forces on the 2 atoms resulting from the
pairwise interaction. The third term is a bond contribution of
similar form for the <em>Nb</em> bonds which atom <em>I</em> is part of. There are
similar terms for the <em>Na</em> angle, <em>Nd</em> dihedral, and <em>Ni</em> improper
interactions atom <em>I</em> is part of. There is also a term for the KSpace
contribution from long-range Coulombic interactions, if defined.
Finally, there is a term for the <em>Nf</em> <a class="reference internal" href="fix.html"><span class="doc">fixes</span></a> that apply
internal constraint forces to atom <em>I</em>. Currently, only the <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> and <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> commands
contribute to this term.</p>
<p>As the coefficients in the formula imply, a virial contribution
produced by a small set of atoms (e.g. 4 atoms in a dihedral or 3
atoms in a Tersoff 3-body interaction) is assigned in equal portions
to each atom in the set. E.g. 1/4 of the dihedral virial to each of
the 4 atoms, or 1/3 of the fix virial due to SHAKE constraints applied
to atoms in a a water molecule via the <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a>
command.</p>
<p>If no extra keywords are listed, all of the terms in this formula are
included in the per-atom stress tensor. If any extra keywords are
listed, only those terms are summed to compute the tensor. The
<em>virial</em> keyword means include all terms except the kinetic energy
<em>ke</em>.</p>
<p>Note that the stress for each atom is due to its interaction with all
other atoms in the simulation, not just with other atoms in the group.</p>
<p>Details of how LAMMPS computes the virial for individual atoms for
either pairwise or manybody potentials, and including the effects of
periodic boundary conditions is discussed in <a class="reference internal" href="#thompson"><span class="std std-ref">(Thompson)</span></a>.
The basic idea for manybody potentials is to treat each component of
the force computation between a small cluster of atoms in the same
manner as in the formula above for bond, angle, dihedral, etc
interactions. Namely the quantity R dot F is summed over the atoms in
the interaction, with the R vectors unwrapped by periodic boundaries
so that the cluster of atoms is close together. The total
contribution for the cluster interaction is divided evenly among those
pairwise interactions between 1-4 atoms. The virial contribution of
these terms is included in the pair virial, not the dihedral virial.</p>
<p>The KSpace contribution is calculated using the method in
<a class="reference internal" href="#heyes"><span class="std std-ref">(Heyes)</span></a> for the Ewald method and by the methodology described
in <a class="reference internal" href="pair_srp.html#sirk"><span class="std std-ref">(Sirk)</span></a> for PPPM. The choice of KSpace solver is specified
by the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style pppm</span></a> command. Note that for
PPPM, the calcluation requires 6 extra FFTs each timestep that
per-atom stress is calculated. Thus it can significantly increase the
cost of the PPPM calculation if it is needed on a large fraction of
the simulation timesteps.</p>
<p>The <em>temp-ID</em> argument can be used to affect the per-atom velocities
used in the kinetic energy contribution to the total stress. If the
kinetic energy is not included in the stress, than the temperature
compute is not used and can be specified as NULL. If the kinetic
energy is included and you wish to use atom velocities as-is, then
<em>temp-ID</em> can also be specified as NULL. If desired, the specified
temperature compute can be one that subtracts off a bias to leave each
atom with only a thermal velocity to use in the formula above, e.g. by
subtracting a background streaming velocity. See the doc pages for
individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones
include a bias.</p>
<hr class="docutils" />
<p>Note that as defined in the formula, per-atom stress is the negative
of the per-atom pressure tensor. It is also really a stress*volume
formulation, meaning the computed quantity is in units of
pressure*volume. It would need to be divided by a per-atom volume to
have units of stress (pressure), but an individual atom’s volume is
not well defined or easy to compute in a deformed solid or a liquid.
See the <a class="reference internal" href="compute_voronoi_atom.html"><span class="doc">compute voronoi/atom</span></a> command for
one possible way to estimate a per-atom volume.</p>
<p>Thus, if the diagonal components of the per-atom stress tensor are
summed for all atoms in the system and the sum is divided by dV, where
d = dimension and V is the volume of the system, the result should be
-P, where P is the total pressure of the system.</p>
<p>These lines in an input script for a 3d system should yield that
result. I.e. the last 2 columns of thermo output will be the same:</p>
<p>This compute calculates a per-atom array with 6 columns, which can be
accessed by indices 1-6 by any command that uses per-atom values from
a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section_howto 15</span></a> for an overview of LAMMPS output
options.</p>
<p>The per-atom array values will be in pressure*volume
<a class="reference internal" href="units.html"><span class="doc">units</span></a> as discussed above.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Define a computation that calculates the temperature of a system based
on the center-of-mass velocity of atom pairs that are bonded to each
other. This compute is designed to be used with the adiabatic
core/shell model of <a class="reference internal" href="pair_cs.html#mitchellfinchham"><span class="std std-ref">(Mitchell and Finchham)</span></a>. See
<a class="reference internal" href="Section_howto.html#howto-25"><span class="std std-ref">Section_howto 25</span></a> of the manual for an
overview of the model as implemented in LAMMPS. Specifically, this
compute enables correct temperature calculation and thermostatting of
core/shell pairs where it is desirable for the internal degrees of
freedom of the core/shell pairs to not be influenced by a thermostat.
A compute of this style can be used by any command that computes a
temperature via <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> e.g. <a class="reference internal" href="fix_temp_rescale.html"><span class="doc">fix temp/rescale</span></a>, <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a>, etc.</p>
<p>Note that this compute does not require all ions to be polarized,
hence defined as core/shell pairs. One can mix core/shell pairs and
ions without a satellite particle if desired. The compute will
consider the non-polarized ions according to the physical system.</p>
<p>For this compute, core and shell particles are specified by two
respective group IDs, which can be defined using the
<a class="reference internal" href="group.html"><span class="doc">group</span></a> command. The number of atoms in the two groups
must be the same and there should be one bond defined between a pair
of atoms in the two groups. Non-polarized ions which might also be
included in the treated system should not be included into either of
these groups, they are taken into account by the <em>group-ID</em> (2nd
argument) of the compute.</p>
<p>The temperature is calculated by the formula KE = dim/2 N k T, where
KE = total kinetic energy of the group of atoms (sum of 1/2 m v^2),
dim = 2 or 3 = dimensionality of the simulation, N = number of atoms
in the group, k = Boltzmann constant, and T = temperature. Note that
the velocity of each core or shell atom used in the KE calculation is
the velocity of the center-of-mass (COM) of the core/shell pair the
atom is part of.</p>
<p>A kinetic energy tensor, stored as a 6-element vector, is also
calculated by this compute for use in the computation of a pressure
tensor. The formula for the components of the tensor is the same as
the above formula, except that v^2 is replaced by vx*vy for the xy
component, etc. The 6 components of the vector are ordered xx, yy,
zz, xy, xz, yz. In contrast to the temperature, the velocity of
each core or shell atom is taken individually.</p>
<p>The change this fix makes to core/shell atom velocities is essentially
computing the temperature after a “bias” has been removed from the
velocity of the atoms. This “bias” is the velocity of the atom
relative to the COM velocity of the core/shell pair. If this compute
is used with a fix command that performs thermostatting then this bias
will be subtracted from each atom, thermostatting of the remaining COM
velocity will be performed, and the bias will be added back in. This
means the thermostating will effectively be performed on the
core/shell pairs, instead of on the individual core and shell atoms.
Thermostatting fixes that work in this way include <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>, <a class="reference internal" href="fix_temp_rescale.html"><span class="doc">fix temp/rescale</span></a>, <a class="reference internal" href="fix_temp_berendsen.html"><span class="doc">fix temp/berendsen</span></a>, and <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a>.</p>
<p>The internal energy of core/shell pairs can be calculated by the
<a class="reference internal" href="compute_temp_chunk.html"><span class="doc">compute temp/chunk</span></a> command, if chunks are
defined as core/shell pairs. See <a class="reference internal" href="Section_howto.html#howto-25"><span class="std std-ref">Section_howto 25</span></a> for more discussion on how to do this.</p>
<p><strong>Output info:</strong></p>
<p>This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
vector values from a compute as input.</p>
<p>The scalar value calculated by this compute is “intensive”. The
vector values are “extensive”.</p>
<p>The scalar value will be in temperature <a class="reference internal" href="units.html"><span class="doc">units</span></a>. The
vector values will be in energy <a class="reference internal" href="units.html"><span class="doc">units</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The number of core/shell pairs contributing to the temperature is
assumed to be constant for the duration of the run. No fixes should
be used which generate new molecules or atoms during a simulation.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>A 6-component kinetic energy tensor is also calculated by this compute
for use in the computation of a pressure tensor. The formula for the
components of the tensor is the same as the above formula, except that
v^2 is replaced by vx * vy for the xy component, etc. For the eFF,
again, the radial electronic velocities are also considered.</p>
<p>The number of atoms contributing to the temperature is assumed to be
constant for the duration of the run; use the <em>dynamic</em> option of the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command if this is not the case.</p>
<p>This compute subtracts out degrees-of-freedom due to fixes that
constrain molecular motion, such as <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> and
<a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a>. This means the temperature of groups of
atoms that include these constraints will be computed correctly. If
needed, the subtracted degrees-of-freedom can be altered using the
<em>extra</em> option of the <a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command.</p>
<p>See <a class="reference internal" href="Section_howto.html#howto-16"><span class="std std-ref">this howto section</span></a> of the manual for
a discussion of different ways to compute temperature and perform
thermostatting.</p>
<p><strong>Output info:</strong></p>
<p>The scalar value calculated by this compute is “intensive”, meaning it
is independent of the number of atoms in the simulation. The vector
values are “extensive”, meaning they scale with the number of atoms in
the simulation.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This compute is part of the USER-EFF package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+compute 1 all ti lj/cut 1 v_lj v_dlj coul/long 2 v_c v_dc kspace 1 v_ks v_dks
+compute 1 all ti lj/cut 1*3 v_lj v_dlj coul/long * v_c v_dc kspace * v_ks v_dks
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Define a computation that calculates the derivative of the interaction
potential with respect to <em>lambda</em>, the coupling parameter used in a
thermodynamic integration. This derivative can be used to infer a
free energy difference resulting from an alchemical simulation, as
described in <a class="reference internal" href="#eike"><span class="std std-ref">Eike</span></a>.</p>
<p>Typically this compute will be used in conjunction with the <a class="reference internal" href="fix_adapt.html"><span class="doc">fix adapt</span></a> command which can perform alchemical
transformations by adusting the strength of an interaction potential
<p>which is the derivative of the system’s scaled potential energy Us
with respect to <em>lambda</em>.</p>
<p>To perform this calculation, you provide one or more atom types as
<em>atype</em>. <em>Atype</em> can be specified in one of two ways. An explicit
numeric values can be used, as in the 1st example above. Or a
wildcard asterisk can be used in place of or in conjunction with the
<em>atype</em> argument to select multiple atom types. This takes the form
-“*” or “<em>n” or “n</em>” or “m*n”. If N = the number of atom types, then
+“*” or “*n” or “n*” or “m*n”. If N = the number of atom types, then
an asterisk with no numeric values means all types from 1 to N. A
leading asterisk means all types from 1 to n (inclusive). A trailing
asterisk means all types from n to N (inclusive). A middle asterisk
means all types from m to n (inclusive).</p>
<p>You also specify two functions, as <a class="reference internal" href="variable.html"><span class="doc">equal-style variables</span></a>. The first is specified as <em>v_name1</em>, where
<em>name1</em> is the name of the variable, and is f(lambda) in the notation
above. The second is specified as <em>v_name2</em>, where <em>name2</em> is the
name of the variable, and is df(lambda) / dlambda in the notation
above. I.e. it is the analytic derivative of f() with respect to
lambda. Note that the <em>name1</em> variable is also typically given as an
argument to the <a class="reference internal" href="fix_adapt.html"><span class="doc">fix adapt</span></a> command.</p>
<p>An alchemical simulation may use several pair potentials together,
invoked via the <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid or hybrid/overlay</span></a>
command. The total dUs/dlambda for the overall system is calculated
as the sum of each contributing term as listed by the keywords in the
compute ti command. Individual pair potentials can be listed, which
will be sub-styles in the hybrid case. You can also include a K-space
term via the <em>kspace</em> keyword. You can also include a pairwise
long-range tail correction to the energy via the <em>tail</em> keyword.</p>
<p>For each term you can specify a different (or the same) scale factor
by the two variables that you list. Again, these will typically
correspond toe the scale factors applied to these various potentials
and the K-Space contribution via the <a class="reference internal" href="fix_adapt.html"><span class="doc">fix adapt</span></a>
command.</p>
<p>More details about the exact functional forms for the computation of
du/dl can be found in the paper by <a class="reference internal" href="#eike"><span class="std std-ref">Eike</span></a>.</p>
<hr class="docutils" />
<p><strong>Output info:</strong></p>
<p>This compute calculates a global scalar, namely dUs/dlambda. This
value can be used by any command that uses a global scalar value from
a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section_howto 15</span></a> for an overview of LAMMPS output
options.</p>
<p>The scalar value calculated by this compute is “extensive”.</p>
<p>The scalar value will be in energy <a class="reference internal" href="units.html"><span class="doc">units</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This compute is part of the MISC package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Here v_r1 specifies a per-type radius of 0.1 units for type 1 atoms
and 0.4 units for type 2 atoms, and v_r2 accesses the radius property
present in atom_style sphere for granular models.</p>
<p>The <em>edge_histo</em> keyword activates the compilation of a histogram of
number of edges on the faces of the Voronoi cells in the compute
group. The argument <em>maxedge</em> of the this keyword is the largest number
of edges on a single Voronoi cell face expected to occur in the
sample. This keyword adds the generation of a global vector with
<em>maxedge</em>+1 entries. The last entry in the vector contains the number of
faces with with more than <em>maxedge</em> edges. Since the polygon with the
smallest amount of edges is a triangle, entries 1 and 2 of the vector
will always be zero.</p>
<p>The <em>edge_threshold</em> and <em>face_threshold</em> keywords allow the
suppression of edges below a given minimum length and faces below a
given minimum area. Ultra short edges and ultra small faces can occur
as artifacts of the Voronoi tessellation. These keywords will affect
the neighbor count and edge histogram outputs.</p>
<p>If the <em>occupation</em> keyword is specified the tessellation is only
performed for the first invocation of the compute and then stored.
For all following invocations of the compute the number of atoms in
each Voronoi cell in the stored tessellation is counted. In this mode
the compute returns a per-atom array with 2 columns. The first column
is the number of atoms currently in the Voronoi volume defined by this
atom at the time of the first invocation of the compute (note that the
atom may have moved significantly). The second column contains the
total number of atoms sharing the Voronoi cell of the stored
tessellation at the location of the current atom. Numbers in column
one can be any positive integer including zero, while column two
values will always be greater than zero. Column one data can be used
to locate vacancies (the coordinates are given by the atom coordinates
at the time step when the compute was first invoked), while column two
data can be used to identify interstitial atoms.</p>
<p>If the <em>neighbors</em> value is set to yes, then
this compute creates a local array with 3 columns. There
is one row for each face of each Voronoi cell. The
3 columns are the atom ID of the atom that owns the cell,
the atom ID of the atom in the neighboring cell
(or zero if the face is external), and the area of the face.
The array can be accessed by any command that
uses local values from a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">this section</span></a> for an overview of LAMMPS output
options. More specifically, the array can be accessed by a
<a class="reference internal" href="dump.html"><span class="doc">dump local</span></a> command to write a file containing
+dump d2 all local 1 dump.neighbors index c_6[1] c_6[2] c_6[3]
+</pre>
<p>If the <em>face_threshold</em> keyword is used, then only faces
with areas greater than the threshold are stored.</p>
<hr class="docutils" />
<p>The Voronoi calculation is performed by the freely available <a class="reference external" href="http://math.lbl.gov/voro++/">Voro++ package</a>, written by Chris Rycroft at UC Berkeley and LBL,
which must be installed on your system when building LAMMPS for use
with this compute. See instructions on obtaining and installing the
Voro++ software in the src/VORONOI/README file.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The calculation of Voronoi volumes is performed by each
processor for the atoms it owns, and includes the effect of ghost
atoms stored by the processor. This assumes that the Voronoi cells of
owned atoms are not affected by atoms beyond the ghost atom cut-off
distance. This is usually a good assumption for liquid and solid
systems, but may lead to underestimation of Voronoi volumes in low
density systems. By default, the set of ghost atoms stored by each
processor is determined by the cutoff used for
<a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> interactions. The cutoff can be set
explicitly via the <a class="reference internal" href="comm_modify.html"><span class="doc">comm_modify cutoff</span></a> command. The
Voronoi cells for atoms adjacent to empty regions will extend into
those regions up to the communication cutoff in x, y, or z. In that
situation, an exterior face is created at the cutoff distance normal
to the x, y, or z direction. For triclinic systems, the exterior face
is parallel to the corresponding reciprocal lattice vector.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The Voro++ package performs its calculation in 3d. This will
still work for a 2d LAMMPS simulation, provided all the atoms have the
same z coordinate. The Voronoi cell of each atom will be a columnar
polyhedron with constant cross-sectional area along the z direction
and two exterior faces at the top and bottom of the simulation box. If
the atoms do not all have the same z coordinate, then the columnar
cells will be accordingly distorted. The cross-sectional area of each
Voronoi cell can be obtained by dividing its volume by the z extent of
the simulation box. Note that you define the z extent of the
<p>By default, this compute calculates a per-atom array with 2
columns. In regular dynamic tessellation mode the first column is the
Voronoi volume, the second is the neighbor count, as described above
(read above for the output data in case the <em>occupation</em> keyword is
specified). These values can be accessed by any command that uses
per-atom values from a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section_howto 15</span></a> for an overview of LAMMPS output
options. If the <em>peratom</em> keyword is set to “no”, the per-atom array
is still created, but it is not accessible.</p>
<p>If the <em>edge_histo</em> keyword is used, then this compute generates a
global vector of length <em>maxedge</em>+1, containing a histogram of the
number of edges per face.</p>
<p>If the <em>neighbors</em> value is set to yes, then this compute calculates a
local array with 3 columns. There is one row for each face of each
Voronoi cell.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Some LAMMPS commands such as the <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a> command can accept either a per-atom or
local quantity. If this compute produces both quantities, the command
may access the per-atom quantity, even if you want to access the local
quantity. This effect can be eliminated by using the <em>peratom</em>
keyword to turn off the production of the per-atom quantities. For
the default value <em>yes</em> both quantities are produced. For the value
<em>no</em>, only the local array is produced.</p>
</div>
<p>The Voronoi cell volume will be in distance <a class="reference internal" href="units.html"><span class="doc">units</span></a> cubed.
The Voronoi face area will be in distance <a class="reference internal" href="units.html"><span class="doc">units</span></a> squared.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This compute is part of the VORONOI package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Coefficients parameterized by <a class="reference internal" href="#peng"><span class="std std-ref">(Peng)</span></a> are assigned for each
atom type designating the chemical symbol and charge of each atom
type. Valid chemical symbols for compute xrd are:</p>
<dl class="docutils">
<dt>H: He1-: He: Li: Li1+:</dt>
<dd><blockquote class="first">
<div><blockquote>
<div><dl class="docutils">
<dt>Be: Be2+: B: C: Cval:</dt>
<dd>N: O: O1-: F: F1-:</dd>
</dl>
<p>Ne: Na: Na1+: Mg: Mg2+:
Al: Al3+: Si: Sival: Si4+:</p>
<blockquote>
<div>P: S: Cl: Cl1-: Ar:
K: Ca: Ca2+: Sc: Sc3+:</div></blockquote>
<p>Ti: Ti2+: Ti3+: Ti4+: V:</p>
</div></blockquote>
<p>V2+: V3+: V5+: Cr: Cr2+:</p>
</div></blockquote>
<dl class="docutils">
<dt>Cr3+: Mn: Mn2+: Mn3+: Mn4+:</dt>
<dd>Fe: Fe2+: Fe3+: Co: Co2+:
Co: Ni: Ni2+: Ni3+: Cu:</dd>
</dl>
<p>Cu1+: Cu2+: Zn: Zn2+: Ga:
Ga3+: Ge: Ge4+: As: Se:</p>
<blockquote>
<div>Br: Br1-: Kr: Rb: Rb1+:
Sr: Sr2+: Y: Y3+: Zr:</div></blockquote>
<p>Zr4+: Nb: Nb3+: Nb5+: Mo:
Mo3+: Mo5+: Mo6+: Tc: Ru:
Ru3+: Ru4+: Rh: Rh3+: Rh4+:</p>
<blockquote>
<div>Pd: Pd2+: Pd4+: Ag: Ag1+:</div></blockquote>
<dl class="docutils">
<dt>Ag2+: Cd: Cd2+: In: In3+:</dt>
<dd>Sn: Sn2+: Sn4+: Sb: Sb3+:</dd>
<dt>Sb5+: Te: I: I1-: Xe:</dt>
<dd>Cs: Cs1+: Ba: Ba2+: La:</dd>
</dl>
<p>La3+: Ce: Ce3+: Ce4+: Pr:
Pr3+: Pr4+: Nd: Nd3+: Pm:
Pm3+: Sm: Sm3+: Eu: Eu2+:
Eu3+: Gd: Gd3+: Tb: Tb3+:</p>
<blockquote>
<div>Dy: Dy3+: Ho: Ho3+: Er:</div></blockquote>
<p>Er3+: Tm: Tm3+: Yb: Yb2+:
Yb3+: Lu: Lu3+: Hf: Hf4+:</p>
<blockquote>
<div>Ta: Ta5+: W: W6+: Re:
Os: Os4+: Ir: Ir3+: Ir4+:
Pt: Pt2+: Pt4+: Au: Au1+:</div></blockquote>
<p>Au3+: Hg: Hg1+: Hg2+: Tl:
Tl1+: Tl3+: Pb: Pb2+: Pb4+:</p>
<blockquote>
<div>Bi: Bi3+: Bi5+: Po: At:
Rn: Fr: Ra: Ra2+: Ac:</div></blockquote>
<dl class="docutils">
<dt>Ac3+: Th: Th4+: Pa: U:</dt>
<dd>U3+: U4+: U6+: Np: Np3+:</dd>
</dl>
<p class="last">Np4+: Np6+: Pu: Pu3+: Pu4+:
Pu6+: Am: Cm: Bk: Cf:tb(c=5,s=:)</p>
</dd>
</dl>
<p>If the <em>echo</em> keyword is specified, compute xrd will provide extra
reporting information to the screen.</p>
<p><strong>Output info:</strong></p>
<p>This compute calculates a global array. The number of rows in the
array is the number of reciprocal lattice nodes that are explored
which by the mesh. The global array has 2 columns.</p>
<p>The first column contains the diffraction angle in the units (radians
or degrees) provided with the <em>2Theta</em> values. The second column contains
the computed diffraction intensities as described above.</p>
<p>The array can be accessed by any command that uses global values from
a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">this section</span></a>
for an overview of LAMMPS output options.</p>
<p>All array values calculated by this compute are “intensive”.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This compute is part of the USER-DIFFRACTION package. It is only
enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The compute_xrd command does not work for triclinic cells.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>type = atom type (1-Ntypes) of atoms to create (offset for molecule creation)</li>
<li>style = <em>box</em> or <em>region</em> or <em>single</em> or <em>random</em></li>
</ul>
<pre class="literal-block">
<em>box</em> args = none
<em>region</em> args = region-ID
region-ID = particles will only be created if contained in the region
<em>single</em> args = x y z
x,y,z = coordinates of a single particle (distance units)
<em>random</em> args = N seed region-ID
N = number of particles to create
seed = random # seed (positive integer)
region-ID = create atoms within this region, use NULL for entire simulation box
</pre>
<ul class="simple">
<li>zero or more keyword/value pairs may be appended</li>
<li>keyword = <em>mol</em> or <em>basis</em> or <em>remap</em> or <em>var</em> or <em>set</em> or <em>units</em></li>
</ul>
<pre class="literal-block">
<em>mol</em> value = template-ID seed
template-ID = ID of molecule template specified in a separate <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command
seed = random # seed (positive integer)
<em>basis</em> values = M itype
M = which basis atom
itype = atom type (1-N) to assign to this basis atom
<em>remap</em> value = <em>yes</em> or <em>no</em>
<em>var</em> value = name = variable name to evaluate for test of atom creation
<em>set</em> values = dim name
dim = <em>x</em> or <em>y</em> or <em>z</em>
name = name of variable to set with x, y, or z atom position
<em>rotate</em> values = Rx Ry Rz theta
Rx,Ry,Rz = rotation vector for single molecule
theta = rotation angle for single molecule (degrees)
<em>units</em> value = <em>lattice</em> or <em>box</em>
<em>lattice</em> = the geometry is defined in lattice units
<em>box</em> = the geometry is defined in simulation box units
command. A simulation box must already exist, which is typically
created via the <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> command. Before using
this command, a lattice must also be defined using the
<a class="reference internal" href="lattice.html"><span class="doc">lattice</span></a> command, unless you specify the <em>single</em> style
with units = box or the <em>random</em> style. For the remainder of this doc
page, a created atom or molecule is referred to as a “particle”.</p>
<p>If created particles are individual atoms, they are assigned the
specified atom <em>type</em>, though this can be altered via the <em>basis</em>
keyword as discussed below. If molecules are being created, the type
of each atom in the created molecule is specified in the file read by
the <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command, and those values are added to
the specified atom <em>type</em>. E.g. if <em>type</em> = 2, and the file specifies
atom types 1,2,3, then each created molecule will have atom types
3,4,5.</p>
<p>For the <em>box</em> style, the create_atoms command fills the entire
simulation box with particles on the lattice. If your simulation box
is periodic, you should insure its size is a multiple of the lattice
spacings, to avoid unwanted atom overlaps at the box boundaries. If
your box is periodic and a multiple of the lattice spacing in a
particular dimension, LAMMPS is careful to put exactly one particle at
the boundary (on either side of the box), not zero or two.</p>
<p>For the <em>region</em> style, a geometric volume is filled with particles on
the lattice. This volume what is inside the simulation box and is
also consistent with the region volume. See the <a class="reference internal" href="region.html"><span class="doc">region</span></a>
command for details. Note that a region can be specified so that its
“volume” is either inside or outside a geometric boundary. Also note
that if your region is the same size as a periodic simulation box (in
some dimension), LAMMPS does not implement the same logic described
above as for the <em>box</em> style, to insure exactly one particle at
periodic boundaries. if this is what you desire, you should either
use the <em>box</em> style, or tweak the region size to get precisely the
particles you want.</p>
<p>For the <em>single</em> style, a single particle is added to the system at
the specified coordinates. This can be useful for debugging purposes
or to create a tiny system with a handful of particles at specified
positions.</p>
<p>For the <em>random</em> style, N particles are added to the system at
randomly generated coordinates, which can be useful for generating an
amorphous system. The particles are created one by one using the
speficied random number <em>seed</em>, resulting in the same set of particles
coordinates, independent of how many processors are being used in the
simulation. If the <em>region-ID</em> argument is specified as NULL, then
the created particles will be anywhere in the simulation box. If a
<em>region-ID</em> is specified, a geometric volume is filled which is both
inside the simulation box and is also consistent with the region
volume. See the <a class="reference internal" href="region.html"><span class="doc">region</span></a> command for details. Note that
a region can be specified so that its “volume” is either inside or
outside a geometric boundary.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Particles generated by the <em>random</em> style will typically be
highly overlapped which will cause many interatomic potentials to
compute large energies and forces. Thus you should either perform an
<a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a> or run dynamics with <a class="reference internal" href="fix_nve_limit.html"><span class="doc">fix nve/limit</span></a> to equilibrate such a system, before
running normal dynamics.</p>
</div>
<p>Note that this command adds particles to those that already exist.
This means it can be used to add particles to a system previously read
in from a data or restart file. Or the create_atoms command can be
used multiple times, to add multiple sets of particles to the
simulation. For example, grain boundaries can be created, by
interleaving create_atoms with <a class="reference internal" href="lattice.html"><span class="doc">lattice</span></a> commands
specifying different orientations. By using the create_atoms command
in conjunction with the <a class="reference internal" href="delete_atoms.html"><span class="doc">delete_atoms</span></a> command,
reasonably complex geometries can be created, or a protein can be
solvated with a surrounding box of water molecules.</p>
<p>In all these cases, care should be taken to insure that new atoms do
not overlap existing atoms inappropriately, especially if molecules
are being added. The <a class="reference internal" href="delete_atoms.html"><span class="doc">delete_atoms</span></a> command can be
used to remove overlapping atoms or molecules.</p>
<hr class="docutils" />
<p>Individual atoms are inserted by this command, unless the <em>mol</em>
keyword is used. It specifies a <em>template-ID</em> previously defined
using the <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command, which reads a file that
defines the molecule. The coordinates, atom types, charges, etc, as
well as any bond/angle/etc and special neighbor information for the
molecule can be specified in the molecule file. See the
<a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command for details. The only settings
required to be in this file are the coordinates and types of atoms in
the molecule.</p>
<p>Using a lattice to add molecules, e.g. via the <em>box</em> or <em>region</em> or
<em>single</em> styles, is exactly the same as adding atoms on lattice
points, except that entire molecules are added at each point, i.e. on
the point defined by each basis atom in the unit cell as it tiles the
simulation box or region. This is done by placing the geometric
center of the molecule at the lattice point, and giving the molecule a
random orientation about the point. The random <em>seed</em> specified with
the <em>mol</em> keyword is used for this operation, and the random numbers
generated by each processor are different. This means the coordinates
of individual atoms (in the molecules) will be different when running
on different numbers of processors, unlike when atoms are being
created in parallel.</p>
<p>Also note that because of the random rotations, it may be important to
use a lattice with a large enough spacing that adjacent molecules will
not overlap, regardless of their relative orientations.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If the <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> command is used to create
the simulation box, followed by the create_atoms command with its
<em>mol</em> option for adding molecules, then you typically need to use the
optional keywords allowed by the <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> command
for extra bonds (angles,etc) or extra special neighbors. This is
because by default, the <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> command sets up a
non-molecular system which doesn’t allow molecules to be added.</p>
</div>
<hr class="docutils" />
<p>This is the meaning of the other allowed keywords.</p>
<p>The <em>basis</em> keyword is only used when atoms (not molecules) are being
created. It specifies an atom type that will be assigned to specific
basis atoms as they are created. See the <a class="reference internal" href="lattice.html"><span class="doc">lattice</span></a>
command for specifics on how basis atoms are defined for the unit cell
of the lattice. By default, all created atoms are assigned the
argument <em>type</em> as their atom type.</p>
<p>The <em>remap</em> keyword only applies to the <em>single</em> style. If it is set
to <em>yes</em>, then if the specified position is outside the simulation
box, it will mapped back into the box, assuming the relevant
dimensions are periodic. If it is set to <em>no</em>, no remapping is done
and no particle is created if its position is outside the box.</p>
<p>The <em>var</em> and <em>set</em> keywords can be used together to provide a
criterion for accepting or rejecting the addition of an individual
atom, based on its coordinates. The <em>name</em> specified for the <em>var</em>
keyword is the name of an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> which
should evaluate to a zero or non-zero value based on one or two or
three variables which will store the x, y, or z coordinates of an atom
(one variable per coordinate). If used, these other variables must be
<a class="reference internal" href="variable.html"><span class="doc">internal-style variables</span></a> defined in the input script;
their initial numeric value can be anything. They must be
internal-style variables, because this command resets their values
directly. The <em>set</em> keyword is used to identify the names of these
other variables, one variable for the x-coordinate of a created atom,
one for y, and one for z.</p>
<p>When an atom is created, its x,y,z coordinates become the values for
any <em>set</em> variable that is defined. The <em>var</em> variable is then
evaluated. If the returned value is 0.0, the atom is not created. If
it is non-zero, the atom is created.</p>
<p>As an example, these commands can be used in a 2d simulation, to
create a sinusoidal surface. Note that the surface is “rough” due to
individual lattice points being “above” or “below” the mathematical
expression for the sinusoidal curve. If a finer lattice were used,
the sinusoid would appear to be “smoother”. Also note the use of the
“xlat” and “ylat” <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> keywords which
converts lattice spacings to distance. Click on the image for a
larger version.</p>
-<div class="highlight-default"><div class="highlight"><pre><span></span>variable x equal 100
</a><p>The <em>rotate</em> keyword can be used with the <em>single</em> style, when adding
a single molecule to specify the orientation at which the molecule is
inserted. The axis of rotation is determined by the rotation vector
(Rx,Ry,Rz) that goes through the insertion point. The specified
<em>theta</em> determines the angle of rotation around that axis. Note that
the direction of rotation for the atoms around the rotation axis is
consistent with the right-hand rule: if your right-hand’s thumb points
along <em>R</em>, then your fingers wrap around the axis in the direction of
rotation.</p>
<p>The <em>units</em> keyword determines the meaning of the distance units used
to specify the coordinates of the one particle created by the <em>single</em>
style. A <em>box</em> value selects standard distance units as defined by
the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command, e.g. Angstroms for units = real or
metal. A <em>lattice</em> value means the distance units are in lattice
spacings.</p>
<hr class="docutils" />
<p>Atom IDs are assigned to created atoms in the following way. The
collection of created atoms are assigned consecutive IDs that start
immediately following the largest atom ID existing before the
create_atoms command was invoked. When a simulation is performed on
different numbers of processors, there is no guarantee a particular
created atom will be assigned the same ID. If molecules are being
created, molecule IDs are assigned to created molecules in a similar
fashion.</p>
<p>Aside from their ID, atom type, and xyz position, other properties of
created atoms are set to default values, depending on which quantities
are defined by the chosen <a class="reference internal" href="atom_style.html"><span class="doc">atom style</span></a>. See the <a class="reference internal" href="atom_style.html"><span class="doc">atom style</span></a> command for more details. See the
<a class="reference internal" href="set.html"><span class="doc">set</span></a> and <a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> commands for info on how
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Turn off (or on) molecular topology interactions, i.e. bonds, angles,
dihedrals, impropers. This command is useful for deleting
interactions that have been previously turned off by bond-breaking
potentials. It is also useful for turning off topology interactions
between frozen or rigid atoms. Pairwise interactions can be turned
off via the <a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify exclude</span></a> command. The
<a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command also effectively turns off certain
bond and angle interactions.</p>
<p>For all styles, by default, an interaction is only turned off (or on)
if all the atoms involved are in the specified group. See the <em>any</em>
keyword to change the behavior.</p>
<p>Several of the styles (<em>atom</em>, <em>bond</em>, <em>angle</em>, <em>dihedral</em>,
<em>improper</em>) take a <em>type</em> as an argument. The specified <em>type</em> should
be an integer from 0 to N, where N is the number of relevant types
(atom types, bond types, etc). A value of 0 is only relevant for
style <em>bond</em>; see details below. In all cases, a wildcard asterisk
can be used in place of or in conjunction with the <em>type</em> argument to
-specify a range of types. This takes the form “*” or “<em>n” or “n</em>” or
+specify a range of types. This takes the form “*” or “*n” or “n*” or
“m*n”. If N = the number of types, then an asterisk with no numeric
values means all types from 0 to N. A leading asterisk means all
types from 0 to n (inclusive). A trailing asterisk means all types
from n to N (inclusive). A middle asterisk means all types from m to
n (inclusive). Note that it is fine to include a type of 0 for
non-bond styles; it will simply be ignored.</p>
<p>For style <em>multi</em> all bond, angle, dihedral, and improper interactions
of any type, involving atoms in the group, are turned off.</p>
<p>Style <em>atom</em> is the same as style <em>multi</em> except that in addition, one
or more of the atoms involved in the bond, angle, dihedral, or
improper interaction must also be of the specified atom type.</p>
<p>For style <em>bond</em>, only bonds are candidates for turn-off, and the bond
must also be of the specified type. Styles <em>angle</em>, <em>dihedral</em>, and
<em>improper</em> are treated similarly.</p>
<p>For style <em>bond</em>, you can set the type to 0 to delete bonds that have
been previously broken by a bond-breaking potential (which sets the
bond type to 0 when a bond is broken); e.g. see the <a class="reference internal" href="bond_style.html"><span class="doc">bond_style quartic</span></a> command.</p>
<p>For style <em>stats</em> no interactions are turned off (or on); the status
of all interactions in the specified group is simply reported. This
is useful for diagnostic purposes if bonds have been turned off by a
bond-breaking potential during a previous run.</p>
<p>The default behavior of the delete_bonds command is to turn off
interactions by toggling their type to a negative value, but not to
permanently remove the interaction. E.g. a bond_type of 2 is set to
-2. The neighbor list creation routines will not include such an
interaction in their interaction lists. The default is also to not
alter the list of 1-2, 1-3, 1-4 neighbors computed by the
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command and used to weight pairwise
force and energy calculations. This means that pairwise computations
will proceed as if the bond (or angle, etc) were still turned on.</p>
<p>Several keywords can be appended to the argument list to alter the
default behaviors.</p>
<p>The <em>any</em> keyword changes the requirement that all atoms in the bond
(angle, etc) must be in the specified group in order to turn-off the
interaction. Instead, if any of the atoms in the interaction are in
the specified group, it will be turned off (or on if the <em>undo</em>
keyword is used).</p>
<p>The <em>undo</em> keyword inverts the delete_bonds command so that the
specified bonds, angles, etc are turned on if they are currently
turned off. This means a negative value is toggled to positive. For
example, for style <em>angle</em>, if <em>type</em> is specified as 2, then all
angles with current type = -2, are reset to type = 2. Note that the
<a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command also sets bond and angle types
negative, so this option should not be used on those interactions.</p>
<p>The <em>remove</em> keyword is invoked at the end of the delete_bonds
operation. It causes turned-off bonds (angles, etc) to be removed
from each atom’s data structure and then adjusts the global bond
(angle, etc) counts accordingly. Removal is a permanent change;
removed bonds cannot be turned back on via the <em>undo</em> keyword.
Removal does not alter the pairwise 1-2, 1-3, 1-4 weighting list.</p>
<p>The <em>special</em> keyword is invoked at the end of the delete_bonds
operation, after (optional) removal. It re-computes the pairwise 1-2,
1-3, 1-4 weighting list. The weighting list computation treats
turned-off bonds the same as turned-on. Thus, turned-off bonds must
be removed if you wish to change the weighting list.</p>
<p>Note that the choice of <em>remove</em> and <em>special</em> options affects how
1-2, 1-3, 1-4 pairwise interactions will be computed across bonds that
have been modified by the delete_bonds command.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This command requires inter-processor communication to acquire ghost
atoms, to coordinate the deleting of bonds, angles, etc between atoms
shared by multiple processors. This means that your system must be
ready to perform a simulation before using this command (force fields
setup, atom masses set, etc). Just as would be needed to run
dynamics, the force field you define should define a cutoff
(e.g. through a <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> command) which is long
enough for a processor to acquire the ghost atoms its needs to compute
bond, angle, etc interactions.</p>
<p>If deleted bonds (angles, etc) are removed but the 1-2, 1-3, 1-4
weighting list is not recomputed, this can cause a later <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command to fail due to an atom’s bonds being
inconsistent with the weighting list. This should only happen if the
group used in the fix command includes both atoms in the bond, in
which case you probably should be recomputing the weighting list.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
In 6-membered rings, the same 1-4 interaction would be computed twice
(once for the clockwise 1-4 pair in dihedral 1-2-3-4 and once in the
counterclockwise dihedral 1-6-5-4) and thus the weighting factor has
to be 0.5 in this case. In 4-membered or 5-membered rings, the 1-4
dihedral also is counted as a 1-2 or 1-3 interaction when going around
the ring in the opposite direction and thus the weighting factor is
0.0, as the 1-2 and 1-3 exclusions take precedence.</p>
<p>Note that this dihedral weighting factor is unrelated to the scaling
factor specified by the <a class="reference internal" href="special_bonds.html"><span class="doc">special bonds</span></a> command
which applies to all 1-4 interactions in the system. For CHARMM force
fields, the special_bonds 1-4 interaction scaling factor should be set
to 0.0. Since the corresponding 1-4 non-bonded interactions are
computed with the dihedral. This means that if any of the weighting
factors defined as dihedral coefficients (4th coeff above) are
non-zero, then you must use a pair style with “lj/charmm” and set the
special_bonds 1-4 scaling factor to 0.0 (which is the
default). Otherwise 1-4 non-bonded interactions in dihedrals will be
computed twice.</p>
<p>Also note that for AMBER force fields, which use pair styles with
“lj/cut”, the special_bonds 1-4 scaling factor should be set to the
AMBER defaults (1/2 and 5/6) and all the dihedral weighting factors
(4th coeff above) must be set to 0.0. In this case, you can use any
pair style you wish, since the dihedral does not need any
Lennard-Jones parameter information and will not compute any 1-4
non-bonded interactions.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where Ed is the dihedral term, Embt is a middle-bond-torsion term,
Eebt is an end-bond-torsion term, Eat is an angle-torsion term, Eaat
is an angle-angle-torsion term, and Ebb13 is a bond-bond-13 term.</p>
<p>Theta1 and theta2 are equilibrium angles and r1 r2 r3 are equilibrium
bond lengths.</p>
<p>See <a class="reference internal" href="#dihedral-sun"><span class="std std-ref">(Sun)</span></a> for a description of the COMPASS class2 force field.</p>
<p>Coefficients for the Ed, Embt, Eebt, Eat, Eaat, and Ebb13 formulas
must be defined for each dihedral type via the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command as in the example above,
<p>These are the 6 coefficients for the Ed formula:</p>
<ul class="simple">
<li>K1 (energy)</li>
<li>phi1 (degrees)</li>
<li>K2 (energy)</li>
<li>phi2 (degrees)</li>
<li>K3 (energy)</li>
<li>phi3 (degrees)</li>
</ul>
<p>For the Embt formula, each line in a
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command in the input script lists
5 coefficients, the first of which is “mbt” to indicate they are
MiddleBondTorsion coefficients. In a data file, these coefficients
should be listed under a “MiddleBondTorsion Coeffs” heading and you
must leave out the “mbt”, i.e. only list 4 coefficients after the
dihedral type.</p>
<ul class="simple">
<li>mbt</li>
<li>A1 (energy/distance)</li>
<li>A2 (energy/distance)</li>
<li>A3 (energy/distance)</li>
<li>r2 (distance)</li>
</ul>
<p>For the Eebt formula, each line in a
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command in the input script lists
9 coefficients, the first of which is “ebt” to indicate they are
EndBondTorsion coefficients. In a data file, these coefficients
should be listed under a “EndBondTorsion Coeffs” heading and you must
leave out the “ebt”, i.e. only list 8 coefficients after the dihedral
type.</p>
<ul class="simple">
<li>ebt</li>
<li>B1 (energy/distance)</li>
<li>B2 (energy/distance)</li>
<li>B3 (energy/distance)</li>
<li>C1 (energy/distance)</li>
<li>C2 (energy/distance)</li>
<li>C3 (energy/distance)</li>
<li>r1 (distance)</li>
<li>r3 (distance)</li>
</ul>
<p>For the Eat formula, each line in a
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command in the input script lists
9 coefficients, the first of which is “at” to indicate they are
AngleTorsion coefficients. In a data file, these coefficients should
be listed under a “AngleTorsion Coeffs” heading and you must leave out
the “at”, i.e. only list 8 coefficients after the dihedral type.</p>
<ul class="simple">
<li>at</li>
<li>D1 (energy/radian)</li>
<li>D2 (energy/radian)</li>
<li>D3 (energy/radian)</li>
<li>E1 (energy/radian)</li>
<li>E2 (energy/radian)</li>
<li>E3 (energy/radian)</li>
<li>theta1 (degrees)</li>
<li>theta2 (degrees)</li>
</ul>
<p>Theta1 and theta2 are specified in degrees, but LAMMPS converts them
to radians internally; hence the units of D and E are in
energy/radian.</p>
<p>For the Eaat formula, each line in a
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command in the input script lists
4 coefficients, the first of which is “aat” to indicate they are
AngleAngleTorsion coefficients. In a data file, these coefficients
should be listed under a “AngleAngleTorsion Coeffs” heading and you
must leave out the “aat”, i.e. only list 3 coefficients after the
dihedral type.</p>
<ul class="simple">
<li>aat</li>
<li>M (energy/radian^2)</li>
<li>theta1 (degrees)</li>
<li>theta2 (degrees)</li>
</ul>
<p>Theta1 and theta2 are specified in degrees, but LAMMPS converts them
to radians internally; hence the units of M are in energy/radian^2.</p>
<p>For the Ebb13 formula, each line in a
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command in the input script lists
4 coefficients, the first of which is “bb13” to indicate they are
BondBond13 coefficients. In a data file, these coefficients should be
listed under a “BondBond13 Coeffs” heading and you must leave out the
“bb13”, i.e. only list 3 coefficients after the dihedral type.</p>
<ul class="simple">
<li>bb13</li>
<li>N (energy/distance^2)</li>
<li>r1 (distance)</li>
<li>r3 (distance)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
CLASS2 package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The following coefficients must be defined for each dihedral type via the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>m (integer >=1)</li>
<li>K1 (energy)</li>
<li>n1 (integer >= 0)</li>
<li>d1 (degrees)</li>
<li></li>
<li>Km (energy)</li>
<li>nm (integer >= 0)</li>
<li>dm (degrees)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The following coefficients must be defined for each dihedral type via the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy)</li>
<li>d (+1 or -1)</li>
<li>n (integer >= 0)</li>
</ul>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Here are important points to take note of when defining LAMMPS
dihedral coefficients for the harmonic style, so that they are
compatible with how harmonic dihedrals are defined by other force
fields:</p>
</div>
<ul class="simple">
<li>The LAMMPS convention is that the trans position = 180 degrees, while
in some force fields trans = 0 degrees.</li>
<li>Some force fields reverse the sign convention on <em>d</em>.</li>
<li>Some force fields let <em>n</em> be positive or negative which corresponds to
<em>d</em> = 1 or -1 for the harmonic style.</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This coarse-grain dihedral potential is described in <a class="reference internal" href="#guo"><span class="std std-ref">(Guo)</span></a>.
For dihedral angles in the helical region, the energy function is
represented by a standard potential consisting of three minima, one
corresponding to the trans (t) state and the other to gauche states
(g+ and g-). The paper describes how the A,B,C parameters are chosen
so as to balance secondary (largely driven by local interactions) and
tertiary structure (driven by long-range interactions).</p>
<p>The following coefficients must be defined for each dihedral type via the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>A (energy)</li>
<li>B (energy)</li>
<li>C (energy)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The following coefficients must be defined for each dihedral type via the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>A1 (energy)</li>
<li>A2 (energy)</li>
<li>A3 (energy)</li>
<li>A4 (energy)</li>
<li>A5 (energy)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The following coefficients must be defined for each dihedral type via the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>n (integer >=1)</li>
<li>A1 (energy)</li>
<li>A2 (energy)</li>
<li>...</li>
<li>An (energy)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Note that the usual 1/2 factor is not included in the K values.</p>
<p>This dihedral potential is used in the OPLS force field and is
described in <a class="reference internal" href="#watkins"><span class="std std-ref">(Watkins)</span></a>.</p>
<p>The following coefficients must be defined for each dihedral type via the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K1 (energy)</li>
<li>K2 (energy)</li>
<li>K3 (energy)</li>
<li>K4 (energy)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>style = <em>none</em> or <em>hybrid</em> or <em>charmm</em> or <em>class2</em> or <em>harmonic</em> or <em>helix</em> or <em>multi/harmonic</em> or <em>opls</em></li>
<p>Dihedral styles can only be set for atom styles that allow dihedrals
to be defined.</p>
<p>Most dihedral styles are part of the MOLECULE package. They are only
enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.
The doc pages for individual dihedral potentials tell if it is part of
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>A section begins with a non-blank line whose 1st character is not a
“#”; blank lines or lines starting with “#” can be used as comments
between sections. The first line begins with a keyword which
identifies the section. The line can contain additional text, but the
initial text must match the argument specified in the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command. The next line lists (in
any order) one or more parameters for the table. Each parameter is a
keyword followed by one or more numeric values.</p>
<p>Following a blank line, the next N lines list the tabulated values. On
each line, the 1st value is the index from 1 to N, the 2nd value is
the angle value, the 3rd value is the energy (in energy units), and
the 4th is -dE/d(phi) also in energy units). The 3rd term is the
energy of the 4-atom configuration for the specified angle. The 4th
term (when present) is the negative derivative of the energy with
respect to the angle (in degrees, or radians depending on whether the
user selected DEGREES or RADIANS). Thus the units of the last term
are still energy, not force. The dihedral angle values must increase
from one line to the next.</p>
<p>Dihedral table splines are cyclic. There is no discontinuity at 180
degrees (or at any other angle). Although in the examples above, the
angles range from -180 to 180 degrees, in general, the first angle in
the list can have any value (positive, zero, or negative). However
the <em>range</em> of angles represented in the table must be <em>strictly</em> less
than 360 degrees (2pi radians) to avoid angle overlap. (You may not
supply entries in the table for both 180 and -180, for example.) If
the user’s table covers only a narrow range of dihedral angles,
strange numerical behavior can occur in the large remaining gap.</p>
<p><strong>Parameters:</strong></p>
<p>The parameter “N” is required and its value is the number of table
entries that follow. Note that this may be different than the N
specified in the <a class="reference internal" href="dihedral_style.html"><span class="doc">dihedral_style table</span></a> command.
Let <em>Ntable</em> is the number of table entries requested dihedral_style
command, and let <em>Nfile</em> be the parameter following “N” in the
tabulated file (“30” in the sparse example above). What LAMMPS does
is a preliminary interpolation by creating splines using the <em>Nfile</em>
tabulated values as nodal points. It uses these to interpolate as
needed to generate energy and derivative values at <em>Ntable</em> different
points (which are evenly spaced over a 360 degree range, even if the
angles in the file are not). The resulting tables of length <em>Ntable</em>
are then used as described above, when computing energy and force for
individual dihedral angles and their atoms. This means that if you
want the interpolation tables of length <em>Ntable</em> to match exactly what
is in the tabulated file (with effectively nopreliminary
interpolation), you should set <em>Ntable</em> = <em>Nfile</em>. To insure the
nodal points in the user’s file are aligned with the interpolated
table entries, the angles in the table should be integer multiples of
360/<em>Ntable</em> degrees, or 2*PI/<em>Ntable</em> radians (depending on your
choice of angle units).</p>
<p>The optional “NOF” keyword allows the user to omit the forces
(negative energy derivatives) from the table file (normally located in
the 4th column). In their place, forces will be calculated
automatically by differentiating the potential energy function
indicated by the 3rd column of the table (using either linear or
spline interpolation).</p>
<p>The optional “DEGREES” keyword allows the user to specify angles in
degrees instead of radians (default).</p>
<p>The optional “RADIANS” keyword allows the user to specify angles in
radians instead of degrees. (Note: This changes the way the forces
are scaled in the 4th column of the data file.)</p>
<p>The optional “CHECKU” keyword is followed by a filename. This allows
the user to save all of the the <em>Ntable</em> different entries in the
interpolated energy table to a file to make sure that the interpolated
function agrees with the user’s expectations. (Note: You can
temporarily increase the <em>Ntable</em> parameter to a high value for this
purpose. “<em>Ntable</em>” is explained above.)</p>
<p>The optional “CHECKF” keyword is analogous to the “CHECKU” keyword.
It is followed by a filename, and it allows the user to check the
interpolated force table. This option is available even if the user
selected the “NOF” option.</p>
<p>Note that one file can contain many sections, each with a tabulated
potential. LAMMPS reads the file section by section until it finds one
that matches the specified keyword.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-6"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>group-ID = ID of the group of atoms to be dumped</li>
<li>style = <em>atom</em> or <em>atom/gz</em> or <em>atom/mpiio</em> or <em>cfg</em> or <em>cfg/gz</em> or <em>cfg/mpiio</em> or <em>dcd</em> or <em>xtc</em> or <em>xyz</em> or <em>xyz/gz</em> or <em>xyz/mpiio</em> or <em>h5md</em> or <em>image</em> or <em>movie</em> or <em>molfile</em> or <em>local</em> or <em>custom</em> or <em>custom/gz</em> or <em>custom/mpiio</em></li>
<li>N = dump every this many timesteps</li>
<li>file = name of file to write dump info to</li>
<li>args = list of arguments for a particular style</li>
</ul>
<pre class="literal-block">
<em>atom</em> args = none
<em>atom/gz</em> args = none
<em>atom/mpiio</em> args = none
<em>cfg</em> args = same as <em>custom</em> args, see below
<em>cfg/gz</em> args = same as <em>custom</em> args, see below
<em>cfg/mpiio</em> args = same as <em>custom</em> args, see below
<em>dcd</em> args = none
<em>xtc</em> args = none
<em>xyz</em> args = none
</pre>
<pre class="literal-block">
<em>xyz/gz</em> args = none
</pre>
<pre class="literal-block">
<em>xyz/mpiio</em> args = none
</pre>
<pre class="literal-block">
<em>custom/vtk</em> args = similar to custom args below, discussed on <a class="reference internal" href="dump_custom_vtk.html"><span class="doc">dump custom/vtk</span></a> doc page
+dump 4a all custom 100 dump.myforce.* id type x y vx fx
+dump 4b flow custom 100 dump.%.myforce id type c_myF[3] v_ke
+dump 4b flow custom 100 dump.%.myforce id type c_myF[*] v_ke
+dump 2 inner cfg 10 dump.snap.*.cfg mass type xs ys zs vx vy vz
+dump snap all cfg 100 dump.config.*.cfg mass type xs ys zs id type c_Stress[2]
+dump 1 all xtc 1000 file.xtc
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Dump a snapshot of atom quantities to one or more files every N
timesteps in one of several styles. The <em>image</em> and <em>movie</em> styles are
the exception: the <em>image</em> style renders a JPG, PNG, or PPM image file
of the atom configuration every N timesteps while the <em>movie</em> style
combines and compresses them into a movie file; both are discussed in
detail on the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a> doc page. The timesteps on
which dump output is written can also be controlled by a variable.
See the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify every</span></a> command.</p>
<p>Only information for atoms in the specified group is dumped. The
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify thresh and region</span></a> commands can also
alter what atoms are included. Not all styles support all these
options; see details below.</p>
<p>As described below, the filename determines the kind of output (text
or binary or gzipped, one big file or one per timestep, one big file
or multiple smaller files).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Because periodic boundary conditions are enforced only on
timesteps when neighbor lists are rebuilt, the coordinates of an atom
written to a dump file may be slightly outside the simulation box.
Re-neighbor timesteps will not typically coincide with the timesteps
dump snapshots are written. See the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify pbc</span></a> command if you with to force coordinates to be
strictly inside the simulation box.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Unless the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify sort</span></a> option is
invoked, the lines of atom information written to dump files
(typically one line per atom) will be in an indeterminate order for
each snapshot. This is even true when running on a single processor,
if the <a class="reference internal" href="atom_modify.html"><span class="doc">atom_modify sort</span></a> option is on, which it is
by default. In this case atoms are re-ordered periodically during a
simulation, due to spatial sorting. It is also true when running in
parallel, because data for a single snapshot is collected from
multiple processors, each of which owns a subset of the atoms.</p>
</div>
<p>For the <em>atom</em>, <em>custom</em>, <em>cfg</em>, and <em>local</em> styles, sorting is off by
default. For the <em>dcd</em>, <em>xtc</em>, <em>xyz</em>, and <em>molfile</em> styles, sorting by
atom ID is on by default. See the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> doc
page for details.</p>
<p>The <em>atom/gz</em>, <em>cfg/gz</em>, <em>custom/gz</em>, and <em>xyz/gz</em> styles are identical
in command syntax to the corresponding styles without “gz”, however,
they generate compressed files using the zlib library. Thus the filename
suffix ”.gz” is mandatory. This is an alternative approach to writing
compressed files via a pipe, as done by the regular dump styles, which
may be required on clusters where the interface to the high-speed network
disallows using the fork() library call (which is needed for a pipe).
For the remainder of this doc page, you should thus consider the <em>atom</em>
and <em>atom/gz</em> styles (etc) to be inter-changeable, with the exception
of the required filename suffix.</p>
<p>As explained below, the <em>atom/mpiio</em>, <em>cfg/mpiio</em>, <em>custom/mpiio</em>, and
<em>xyz/mpiio</em> styles are identical in command syntax and in the format
of the dump files they create, to the corresponding styles without
“mpiio”, except the single dump file they produce is written in
parallel via the MPI-IO library. For the remainder of this doc page,
you should thus consider the <em>atom</em> and <em>atom/mpiio</em> styles (etc) to
be inter-changeable. The one exception is how the filename is
specified for the MPI-IO styles, as explained below.</p>
<p>The precision of values output to text-based dump files can be
controlled by the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify format</span></a> command and
its options.</p>
<hr class="docutils" />
<p>The <em>style</em> keyword determines what atom quantities are written to the
file and in what format. Settings made via the
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command can also alter the format of
individual values and the file itself.</p>
<p>The <em>atom</em>, <em>local</em>, and <em>custom</em> styles create files in a simple text
format that is self-explanatory when viewing a dump file. Many of the
LAMMPS <a class="reference internal" href="Section_tools.html"><span class="doc">post-processing tools</span></a>, including
<a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</a>, work with this
format, as does the <a class="reference internal" href="rerun.html"><span class="doc">rerun</span></a> command.</p>
<p>For post-processing purposes the <em>atom</em>, <em>local</em>, and <em>custom</em> text
files are self-describing in the following sense.</p>
<p>The dimensions of the simulation box are included in each snapshot.
For an orthogonal simulation box this information is is formatted as:</p>
<p>The presence of the text “xy xz yz” in the ITEM line indicates that
the 3 tilt factors will be included on each of the 3 following lines.
This bounding box is convenient for many visualization programs. The
meaning of the 6 character flags for “xx yy zz” is the same as above.</p>
<p>Note that the first two numbers on each line are now xlo_bound instead
of xlo, etc, since they repesent a bounding box. See <a class="reference internal" href="Section_howto.html#howto-12"><span class="std std-ref">this section</span></a> of the doc pages for a geometric
description of triclinic boxes, as defined by LAMMPS, simple formulas
for how the 6 bounding box extents (xlo_bound,xhi_bound,etc) are
calculated from the triclinic parameters, and how to transform those
parameters to and from other commonly used triclinic representations.</p>
<p>The “ITEM: ATOMS” line in each snapshot lists column descriptors for
the per-atom lines that follow. For example, the descriptors would be
“id type xs ys zs” for the default <em>atom</em> style, and would be the atom
attributes you specify in the dump command for the <em>custom</em> style.</p>
<p>For style <em>atom</em>, atom coordinates are written to the file, along with
the atom ID and atom type. By default, atom coords are written in a
scaled format (from 0 to 1). I.e. an x value of 0.25 means the atom
is at a location 1/4 of the distance from xlo to xhi of the box
boundaries. The format can be changed to unscaled coords via the
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> settings. Image flags can also be
added for each atom via dump_modify.</p>
<p>Style <em>custom</em> allows you to specify a list of atom attributes to be
written to the dump file for each atom. Possible attributes are
listed above and will appear in the order specified. You cannot
specify a quantity that is not defined for a particular simulation -
such as <em>q</em> for atom style <em>bond</em>, since that atom style doesn’t
assign charges. Dumps occur at the very end of a timestep, so atom
attributes will include effects due to fixes that are applied during
the timestep. An explanation of the possible dump custom attributes
is given below.</p>
<p>For style <em>local</em>, local output generated by <a class="reference internal" href="compute.html"><span class="doc">computes</span></a>
and <a class="reference internal" href="fix.html"><span class="doc">fixes</span></a> is used to generate lines of output that is
written to the dump file. This local data is typically calculated by
each processor based on the atoms it owns, but there may be zero or
more entities per atom, e.g. a list of bond distances. An explanation
of the possible dump local attributes is given below. Note that by
using input from the <a class="reference internal" href="compute_property_local.html"><span class="doc">compute property/local</span></a> command with dump local,
it is possible to generate information on bonds, angles, etc that can
be cut and pasted directly into a data file read by the
The precision used in XTC files can be adjusted via the
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command. The default value of 1000
means that coordinates are stored to 1/1000 nanometer accuracy. XTC
files are portable binary files written in the NFS XDR data format,
so that any machine which supports XDR should be able to read them.
The number of atoms per snapshot cannot change with the <em>xtc</em> style.
The <em>unwrap</em> option of the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command allows
XTC coordinates to be written “unwrapped” by the image flags for each
atom. Unwrapped means that if the atom has passed thru a periodic
boundary one or more times, the value is printed for what the
coordinate would be if it had not been wrapped back into the periodic
box. Note that these coordinates may thus be far outside the box size
stored with the snapshot.</p>
<p>The <em>xyz</em> style writes XYZ files, which is a simple text-based
coordinate format that many codes can read. Specifically it has
a line with the number of atoms, then a comment line that is
usually ignored followed by one line per atom with the atom type
and the x-, y-, and z-coordinate of that atom. You can use the
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify element</span></a> option to change the output
from using the (numerical) atom type to an element name (or some
other label). This will help many visualization programs to guess
bonds and colors.</p>
<p>Note that <em>atom</em>, <em>custom</em>, <em>dcd</em>, <em>xtc</em>, and <em>xyz</em> style dump files
can be read directly by <a class="reference external" href="http://www.ks.uiuc.edu/Research/vmd">VMD</a>, a
popular molecular viewing program. See <a class="reference internal" href="Section_tools.html#vmd"><span class="std std-ref">Section tools</span></a> of the manual and the
tools/lmp2vmd/README.txt file for more information about support in
VMD for reading and visualizing LAMMPS dump files.</p>
<hr class="docutils" />
<p>Dumps are performed on timesteps that are a multiple of N (including
timestep 0) and on the last timestep of a minimization if the
minimization converges. Note that this means a dump will not be
performed on the initial timestep after the dump command is invoked,
if the current timestep is not a multiple of N. This behavior can be
changed via the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify first</span></a> command, which
can also be useful if the dump command is invoked after a minimization
ended on an arbitrary timestep. N can be changed between runs by
using the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify every</span></a> command (not allowed
for <em>dcd</em> style). The <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify every</span></a> command
also allows a variable to be used to determine the sequence of
timesteps on which dump files are written. In this mode a dump on the
first timestep of a run will also not be written unless the
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify first</span></a> command is used.</p>
<p>The specified filename determines how the dump file(s) is written.
The default is to write one large text file, which is opened when the
dump command is invoked and closed when an <a class="reference internal" href="undump.html"><span class="doc">undump</span></a>
command is used or when LAMMPS exits. For the <em>dcd</em> and <em>xtc</em> styles,
this is a single large binary file.</p>
<p>Dump filenames can contain two wildcard characters. If a “*”
character appears in the filename, then one file per snapshot is
written and the “*” character is replaced with the timestep value.
For example, tmp.dump.* becomes tmp.dump.0, tmp.dump.10000,
tmp.dump.20000, etc. This option is not available for the <em>dcd</em> and
<em>xtc</em> styles. Note that the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify pad</span></a>
command can be used to insure all timestep numbers are the same length
(e.g. 00010), which can make it easier to read a series of dump files
in order with some post-processing tools.</p>
<p>If a “%” character appears in the filename, then each of P processors
writes a portion of the dump file, and the “%” character is replaced
with the processor ID from 0 to P-1. For example, tmp.dump.% becomes
tmp.dump.0, tmp.dump.1, ... tmp.dump.P-1, etc. This creates smaller
files and can be a fast mode of output on parallel machines that
support parallel I/O for output. This option is not available for the
<em>dcd</em>, <em>xtc</em>, and <em>xyz</em> styles.</p>
<p>By default, P = the number of processors meaning one file per
processor, but P can be set to a smaller value via the <em>nfile</em> or
<em>fileper</em> keywords of the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command.
These options can be the most efficient way of writing out dump files
when running on large numbers of processors.</p>
<p>Note that using the “*” and “%” characters together can produce a
large number of small dump files!</p>
<p>For the <em>atom/mpiio</em>, <em>cfg/mpiio</em>, <em>custom/mpiio</em>, and <em>xyz/mpiio</em>
styles, a single dump file is written in parallel via the MPI-IO
library, which is part of the MPI standard for versions 2.0 and above.
Using MPI-IO requires two steps. First, build LAMMPS with its MPIIO
<span class="n">make</span> <span class="n">g</span><span class="o">++</span> <span class="c1"># build LAMMPS for your platform</span>
</pre></div>
</div>
<p>Second, use a dump filename which contains ”.mpiio”. Note that it
does not have to end in ”.mpiio”, just contain those characters.
Unlike MPI-IO restart files, which must be both written and read using
MPI-IO, the dump files produced by these MPI-IO styles are identical
in format to the files produced by their non-MPI-IO style
counterparts. This means you can write a dump file using MPI-IO and
use the <a class="reference internal" href="read_dump.html"><span class="doc">read_dump</span></a> command or perform other
post-processing, just as if the dump file was not written using
MPI-IO.</p>
<p>Note that MPI-IO dump files are one large file which all processors
write to. You thus cannot use the “%” wildcard character described
above in the filename since that specifies generation of multiple
files. You can use the ”.bin” suffix described below in an MPI-IO
dump file; again this file will be written in parallel and have the
same binary format as if it were written without MPI-IO.</p>
<p>If the filename ends with ”.bin”, the dump file (or files, if “*” or
“%” is also used) is written in binary format. A binary dump file
will be about the same size as a text version, but will typically
write out much faster. Of course, when post-processing, you will need
to convert it back to text format (see the <a class="reference internal" href="Section_tools.html#binary"><span class="std std-ref">binary2txt tool</span></a>) or write your own code to read the
binary file. The format of the binary file can be understood by
looking at the tools/binary2txt.cpp file. This option is only
available for the <em>atom</em> and <em>custom</em> styles.</p>
<p>If the filename ends with ”.gz”, the dump file (or files, if “*” or “%”
is also used) is written in gzipped format. A gzipped dump file will
be about 3x smaller than the text version, but will also take longer
to write. This option is not available for the <em>dcd</em> and <em>xtc</em>
styles.</p>
<hr class="docutils" />
<p>Note that in the discussion which follows, for styles which can
reference values from a compute or fix, like the <em>custom</em>, <em>cfg</em>, or
<em>local</em> styles, the bracketed index I can be specified using a
wildcard asterisk with the index to effectively specify multiple
-values. This takes the form “*” or “<em>n” or “n</em>” or “m*n”. If N = the
+values. This takes the form “*” or “*n” or “n*” or “m*n”. If N = the
size of the vector (for <em>mode</em> = scalar) or the number of columns in
the array (for <em>mode</em> = vector), then an asterisk with no numeric
values means all indices from 1 to N. A leading asterisk means all
indices from 1 to n (inclusive). A trailing asterisk means all
indices from n to N (inclusive). A middle asterisk means all indices
from m to n (inclusive).</p>
<p>Using a wildcard is the same as if the individual columns of the array
had been listed one by one. E.g. these 2 dump commands are
equivalent, since the <a class="reference internal" href="compute_stress_atom.html"><span class="doc">compute stress/atom</span></a>
command creates a per-atom array with 6 columns:</p>
+dump 2 all custom 100 tmp.dump id myPress[1] myPress[2] myPress[3] &
+ myPress[4] myPress[5] myPress[6]
+</pre>
<hr class="docutils" />
<p>This section explains the local attributes that can be specified as
part of the <em>local</em> style.</p>
<p>The <em>index</em> attribute can be used to generate an index number from 1
to N for each line written into the dump file, where N is the total
number of local datums from all processors, or lines of output that
will appear in the snapshot. Note that because data from different
processors depend on what atoms they currently own, and atoms migrate
between processor, there is no guarantee that the same index will be
used for the same info (e.g. a particular bond) in successive
snapshots.</p>
<p>The <em>c_ID</em> and <em>c_ID[I]</em> attributes allow local vectors or arrays
calculated by a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> to be output. The ID in the
attribute should be replaced by the actual ID of the compute that has
been defined previously in the input script. See the
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command for details. There are computes for
calculating local information such as indices, types, and energies for
bonds and angles.</p>
<p>Note that computes which calculate global or per-atom quantities, as
opposed to local quantities, cannot be output in a dump local command.
Instead, global quantities can be output by the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command, and per-atom quantities can be
output by the dump custom command.</p>
<p>If <em>c_ID</em> is used as a attribute, then the local vector calculated by
the compute is printed. If <em>c_ID[I]</em> is used, then I must be in the
range from 1-M, which will print the Ith column of the local array
with M columns calculated by the compute. See the discussion above
for how I can be specified with a wildcard asterisk to effectively
specify multiple values.</p>
<p>The <em>f_ID</em> and <em>f_ID[I]</em> attributes allow local vectors or arrays
calculated by a <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> to be output. The ID in the attribute
should be replaced by the actual ID of the fix that has been defined
previously in the input script.</p>
<p>If <em>f_ID</em> is used as a attribute, then the local vector calculated by
the fix is printed. If <em>f_ID[I]</em> is used, then I must be in the
range from 1-M, which will print the Ith column of the local with M
columns calculated by the fix. See the discussion above for how I can
be specified with a wildcard asterisk to effectively specify multiple
values.</p>
<p>Here is an example of how to dump bond info for a system, including
<em>vy</em>, <em>vz</em>, <em>fx</em>, <em>fy</em>, <em>fz</em>, <em>q</em> attributes are self-explanatory.</p>
<p><em>Id</em> is the atom ID. <em>Mol</em> is the molecule ID, included in the data
file for molecular systems. <em>Proc</em> is the ID of the processor (0 to
Nprocs-1) that currently owns the atom. <em>Procp1</em> is the proc ID+1,
which can be convenient in place of a <em>type</em> attribute (1 to Ntypes)
for coloring atoms in a visualization program. <em>Type</em> is the atom
type (1 to Ntypes). <em>Element</em> is typically the chemical name of an
element, which you must assign to each type via the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify element</span></a> command. More generally, it can be any
string you wish to associated with an atom type. <em>Mass</em> is the atom
mass. <em>Vx</em>, <em>vy</em>, <em>vz</em>, <em>fx</em>, <em>fy</em>, <em>fz</em>, and <em>q</em> are components of
atom velocity and force and atomic charge.</p>
<p>There are several options for outputting atom coordinates. The <em>x</em>,
<em>y</em>, <em>z</em> attributes write atom coordinates “unscaled”, in the
<em>xs</em>, <em>ys</em>, <em>zs</em> if you want the coordinates “scaled” to the box size,
so that each value is 0.0 to 1.0. If the simulation box is triclinic
(tilted), then all atom coords will still be between 0.0 and 1.0.
I.e. actual unscaled (x,y,z) = xs*A + ys*B + zs*C, where (A,B,C) are
the non-orthogonal vectors of the simulation box edges, as discussed
in <a class="reference internal" href="Section_howto.html#howto-12"><span class="std std-ref">Section howto 6.12</span></a>.</p>
<p>Use <em>xu</em>, <em>yu</em>, <em>zu</em> if you want the coordinates “unwrapped” by the
image flags for each atom. Unwrapped means that if the atom has
passed thru a periodic boundary one or more times, the value is
printed for what the coordinate would be if it had not been wrapped
back into the periodic box. Note that using <em>xu</em>, <em>yu</em>, <em>zu</em> means
that the coordinate values may be far outside the box bounds printed
with the snapshot. Using <em>xsu</em>, <em>ysu</em>, <em>zsu</em> is similar to using
<em>xu</em>, <em>yu</em>, <em>zu</em>, except that the unwrapped coordinates are scaled by
the box size. Atoms that have passed through a periodic boundary will
have the corresponding cooordinate increased or decreased by 1.0.</p>
<p>The image flags can be printed directly using the <em>ix</em>, <em>iy</em>, <em>iz</em>
attributes. For periodic dimensions, they specify which image of the
simulation box the atom is considered to be in. An image of 0 means
it is inside the box as defined. A value of 2 means add 2 box lengths
to get the true value. A value of -1 means subtract 1 box length to
get the true value. LAMMPS updates these flags as atoms cross
periodic boundaries during the simulation.</p>
<p>The <em>mux</em>, <em>muy</em>, <em>muz</em> attributes are specific to dipolar systems
defined with an atom style of <em>dipole</em>. They give the orientation of
the atom’s point dipole moment. The <em>mu</em> attribute gives the
magnitude of the atom’s dipole moment.</p>
<p>The <em>radius</em> and <em>diameter</em> attributes are specific to spherical
particles that have a finite size, such as those defined with an atom
style of <em>sphere</em>.</p>
<p>The <em>omegax</em>, <em>omegay</em>, and <em>omegaz</em> attributes are specific to
finite-size spherical particles that have an angular velocity. Only
certain atom styles, such as <em>sphere</em> define this quantity.</p>
<p>The <em>angmomx</em>, <em>angmomy</em>, and <em>angmomz</em> attributes are specific to
finite-size aspherical particles that have an angular momentum. Only
the <em>ellipsoid</em> atom style defines this quantity.</p>
<p>The <em>tqx</em>, <em>tqy</em>, <em>tqz</em> attributes are for finite-size particles that
can sustain a rotational torque due to interactions with other
particles.</p>
<p>The <em>c_ID</em> and <em>c_ID[I]</em> attributes allow per-atom vectors or arrays
calculated by a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> to be output. The ID in the
attribute should be replaced by the actual ID of the compute that has
been defined previously in the input script. See the
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command for details. There are computes for
calculating the per-atom energy, stress, centro-symmetry parameter,
and coordination number of individual atoms.</p>
<p>Note that computes which calculate global or local quantities, as
opposed to per-atom quantities, cannot be output in a dump custom
command. Instead, global quantities can be output by the
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command, and local quantities
can be output by the dump local command.</p>
<p>If <em>c_ID</em> is used as a attribute, then the per-atom vector calculated
by the compute is printed. If <em>c_ID[I]</em> is used, then I must be in
the range from 1-M, which will print the Ith column of the per-atom
array with M columns calculated by the compute. See the discussion
above for how I can be specified with a wildcard asterisk to
effectively specify multiple values.</p>
<p>The <em>f_ID</em> and <em>f_ID[I]</em> attributes allow vector or array per-atom
quantities calculated by a <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> to be output. The ID in the
attribute should be replaced by the actual ID of the fix that has been
defined previously in the input script. The <a class="reference internal" href="fix_ave_atom.html"><span class="doc">fix ave/atom</span></a> command is one that calculates per-atom
quantities. Since it can time-average per-atom quantities produced by
any <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>, <a class="reference internal" href="fix.html"><span class="doc">fix</span></a>, or atom-style
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a>, this allows those time-averaged results to
be written to a dump file.</p>
<p>If <em>f_ID</em> is used as a attribute, then the per-atom vector calculated
by the fix is printed. If <em>f_ID[I]</em> is used, then I must be in the
range from 1-M, which will print the Ith column of the per-atom array
with M columns calculated by the fix. See the discussion above for
how I can be specified with a wildcard asterisk to effectively specify
multiple values.</p>
<p>The <em>v_name</em> attribute allows per-atom vectors calculated by a
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> to be output. The name in the attribute
should be replaced by the actual name of the variable that has been
defined previously in the input script. Only an atom-style variable
can be referenced, since it is the only style that generates per-atom
values. Variables of style <em>atom</em> can reference individual atom
attributes, per-atom atom attributes, thermodynamic keywords, or
invoke other computes, fixes, or variables when they are evaluated, so
this is a very general means of creating quantities to output to a
dump file.</p>
<p>The <em>d_name</em> and <em>i_name</em> attributes allow to output custom per atom
floating point or integer properties that are managed by
<p>See <a class="reference internal" href="Section_modify.html"><span class="doc">Section_modify</span></a> of the manual for information
on how to add new compute and fix styles to LAMMPS to calculate
per-atom quantities which could then be output into dump files.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>To write gzipped dump files, you must either compile LAMMPS with the
-DLAMMPS_GZIP option or use the styles from the COMPRESS package
- see the <a class="reference internal" href="Section_start.html#start-2"><span class="std std-ref">Making LAMMPS</span></a> section of
the documentation.</p>
<p>The <em>atom/gz</em>, <em>cfg/gz</em>, <em>custom/gz</em>, and <em>xyz/gz</em> styles are part
of the COMPRESS package. They are only enabled if LAMMPS was built
with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The <em>atom/mpiio</em>, <em>cfg/mpiio</em>, <em>custom/mpiio</em>, and <em>xyz/mpiio</em> styles
are part of the MPIIO package. They are only enabled if LAMMPS was
built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The <em>xtc</em> style is part of the MISC package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info. This is
because some machines may not support the low-level XDR data format
that XTC files are written with, which will result in a compile-time
error when a low-level include file is not found. Putting this style
in a package makes it easy to exclude from a LAMMPS build for those
machines. However, the MISC package also includes two compatibility
header files and associated functions, which should be a suitable
substitute on machines that do not have the appropriate native header
files. This option can be invoked at build time by adding
-DLAMMPS_XDR to the CCFLAGS variable in the appropriate low-level
Makefile, e.g. src/MAKE/Makefile.foo. This compatibility mode has
been tested successfully on Cray XT3/XT4/XT5 and IBM BlueGene/L
machines and should also work on IBM BG/P, and Windows XP/Vista/7
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+dump dmpvtk all custom/vtk 100 dump*.myforce.vtk id type vx fx
+dump dmpvtp flow custom/vtk 100 dump*.%.displace.vtp id type c_myD[1] c_myD[2] c_myD[3] v_ke
+dump e_data all custom/vtk 100 dump*.vtu id type spin eradius fx fy fz eforce
+</pre>
<p>The style <em>custom/vtk</em> is similar to the <a class="reference internal" href="dump.html"><span class="doc">custom</span></a> style but
uses the VTK library to write data to VTK simple legacy or XML format
depending on the filename extension specified. This can be either
-<a href="#id1"><span class="problematic" id="id2">**</span></a>.vtk* for the legacy format or <a href="#id3"><span class="problematic" id="id4">**</span></a>.vtp* and <a href="#id5"><span class="problematic" id="id6">**</span></a>.vtu*, respectively,
+<em>*.vtk</em> for the legacy format or <em>*.vtp</em> and <em>*.vtu</em>, respectively,
for the XML format; see the <a class="reference external" href="http://www.vtk.org/VTK/img/file-formats.pdf">VTK homepage</a> for a detailed
description of these formats. Since this naming convention conflicts
with the way binary output is usually specified (see below),
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify binary</span></a> allows to set the binary
flag for this dump style explicitly.</p>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Dump a snapshot of atom quantities to one or more files every N
timesteps in a format readable by the <a class="reference external" href="http://www.vtk.org">VTK visualization toolkit</a> or other visualization tools that use it,
e.g. <a class="reference external" href="http://www.paraview.org">ParaView</a>. The timesteps on which dump
output is written can also be controlled by a variable; see the
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify every</span></a> command for details.</p>
<p>Only information for atoms in the specified group is dumped. The
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify thresh and region</span></a> commands can also
alter what atoms are included; see details below.</p>
<p>As described below, special characters (“*”, “%”) in the filename
determine the kind of output.</p>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">Because periodic boundary conditions are enforced only
on timesteps when neighbor lists are rebuilt, the coordinates of an
atom written to a dump file may be slightly outside the simulation
box.</p>
</div>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">Unless the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify sort</span></a>
option is invoked, the lines of atom information written to dump files
will be in an indeterminate order for each snapshot. This is even
true when running on a single processor, if the <a class="reference internal" href="atom_modify.html"><span class="doc">atom_modify sort</span></a> option is on, which it is by default. In this
case atoms are re-ordered periodically during a simulation, due to
spatial sorting. It is also true when running in parallel, because
data for a single snapshot is collected from multiple processors, each
of which owns a subset of the atoms.</p>
</div>
<p>For the <em>custom/vtk</em> style, sorting is off by default. See the
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> doc page for details.</p>
<hr class="docutils" />
<p>The dimensions of the simulation box are written to a separate file
for each snapshot (either in legacy VTK or XML format depending on
the format of the main dump file) with the suffix <em>_boundingBox</em>
appended to the given dump filename.</p>
<p>For an orthogonal simulation box this information is saved as a
rectilinear grid (legacy .vtk or .vtr XML format).</p>
<p>Triclinic simulation boxes (non-orthogonal) are saved as
hexahedrons in either legacy .vtk or .vtu XML format.</p>
<p>Style <em>custom/vtk</em> allows you to specify a list of atom attributes
to be written to the dump file for each atom. Possible attributes
are listed above. In contrast to the <em>custom</em> style, the attributes
are rearranged to ensure correct ordering of vector components
(except for computes and fixes - these have to be given in the right
order) and duplicate entries are removed.</p>
<p>You cannot specify a quantity that is not defined for a particular
simulation - such as <em>q</em> for atom style <em>bond</em>, since that atom style
doesn’t assign charges. Dumps occur at the very end of a timestep,
so atom attributes will include effects due to fixes that are applied
during the timestep. An explanation of the possible dump custom/vtk attributes
is given below. Since position data is required to write VTK files “x y z”
do not have to be specified explicitly.</p>
<p>The VTK format uses a single snapshot of the system per file, thus
a wildcard “*” must be included in the filename, as discussed below.
Otherwise the dump files will get overwritten with the new snapshot
each time.</p>
<hr class="docutils" />
<p>Dumps are performed on timesteps that are a multiple of N (including
timestep 0) and on the last timestep of a minimization if the
minimization converges. Note that this means a dump will not be
performed on the initial timestep after the dump command is invoked,
if the current timestep is not a multiple of N. This behavior can be
changed via the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify first</span></a> command, which
can also be useful if the dump command is invoked after a minimization
ended on an arbitrary timestep. N can be changed between runs by
using the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify every</span></a> command.
The <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify every</span></a> command
also allows a variable to be used to determine the sequence of
timesteps on which dump files are written. In this mode a dump on the
first timestep of a run will also not be written unless the
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify first</span></a> command is used.</p>
<p>Dump filenames can contain two wildcard characters. If a “*”
character appears in the filename, then one file per snapshot is
written and the “*” character is replaced with the timestep value.
For example, tmp.dump*.vtk becomes tmp.dump0.vtk, tmp.dump10000.vtk,
tmp.dump20000.vtk, etc. Note that the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify pad</span></a>
command can be used to insure all timestep numbers are the same length
(e.g. 00010), which can make it easier to read a series of dump files
in order with some post-processing tools.</p>
<p>If a “%” character appears in the filename, then each of P processors
writes a portion of the dump file, and the “%” character is replaced
with the processor ID from 0 to P-1 preceded by an underscore character.
For example, tmp.dump%.vtp becomes tmp.dump_0.vtp, tmp.dump_1.vtp, ...
tmp.dump_P-1.vtp, etc. This creates smaller files and can be a fast
mode of output on parallel machines that support parallel I/O for output.</p>
<p>By default, P = the number of processors meaning one file per
processor, but P can be set to a smaller value via the <em>nfile</em> or
<em>fileper</em> keywords of the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command.
These options can be the most efficient way of writing out dump files
when running on large numbers of processors.</p>
<p>For the legacy VTK format “%” is ignored and P = 1, i.e., only
processor 0 does write files.</p>
<p>Note that using the “*” and “%” characters together can produce a
large number of small dump files!</p>
<p>If <em>dump_modify binary</em> is used, the dump file (or files, if “*” or
“%” is also used) is written in binary format. A binary dump file
will be about the same size as a text version, but will typically
write out much faster.</p>
<hr class="docutils" />
<p>This section explains the atom attributes that can be specified as
Additionaly, you can use <em>xs</em>, <em>ys</em>, <em>zs</em> if you want to also save the
coordinates “scaled” to the box size, so that each value is 0.0 to
1.0. If the simulation box is triclinic (tilted), then all atom
coords will still be between 0.0 and 1.0. Use <em>xu</em>, <em>yu</em>, <em>zu</em> if you
want the coordinates “unwrapped” by the image flags for each atom.
Unwrapped means that if the atom has passed through a periodic
boundary one or more times, the value is printed for what the
coordinate would be if it had not been wrapped back into the periodic
box. Note that using <em>xu</em>, <em>yu</em>, <em>zu</em> means that the coordinate
values may be far outside the box bounds printed with the snapshot.
Using <em>xsu</em>, <em>ysu</em>, <em>zsu</em> is similar to using <em>xu</em>, <em>yu</em>, <em>zu</em>, except
that the unwrapped coordinates are scaled by the box size. Atoms that
have passed through a periodic boundary will have the corresponding
cooordinate increased or decreased by 1.0.</p>
<p>The image flags can be printed directly using the <em>ix</em>, <em>iy</em>, <em>iz</em>
attributes. For periodic dimensions, they specify which image of the
simulation box the atom is considered to be in. An image of 0 means
it is inside the box as defined. A value of 2 means add 2 box lengths
to get the true value. A value of -1 means subtract 1 box length to
get the true value. LAMMPS updates these flags as atoms cross
periodic boundaries during the simulation.</p>
<p>The <em>mux</em>, <em>muy</em>, <em>muz</em> attributes are specific to dipolar systems
defined with an atom style of <em>dipole</em>. They give the orientation of
the atom’s point dipole moment. The <em>mu</em> attribute gives the
magnitude of the atom’s dipole moment.</p>
<p>The <em>radius</em> and <em>diameter</em> attributes are specific to spherical
particles that have a finite size, such as those defined with an atom
style of <em>sphere</em>.</p>
<p>The <em>omegax</em>, <em>omegay</em>, and <em>omegaz</em> attributes are specific to
finite-size spherical particles that have an angular velocity. Only
certain atom styles, such as <em>sphere</em> define this quantity.</p>
<p>The <em>angmomx</em>, <em>angmomy</em>, and <em>angmomz</em> attributes are specific to
finite-size aspherical particles that have an angular momentum. Only
the <em>ellipsoid</em> atom style defines this quantity.</p>
<p>The <em>tqx</em>, <em>tqy</em>, <em>tqz</em> attributes are for finite-size particles that
can sustain a rotational torque due to interactions with other
particles.</p>
<p>The <em>spin</em>, <em>eradius</em>, <em>ervel</em>, and <em>erforce</em> attributes are for
particles that represent nuclei and electrons modeled with the
electronic force field (EFF). See <a class="reference internal" href="atom_style.html"><span class="doc">atom_style electron</span></a> and <a class="reference internal" href="pair_eff.html"><span class="doc">pair_style eff</span></a> for more
details.</p>
<p>The <em>c_ID</em> and <em>c_ID[N]</em> attributes allow per-atom vectors or arrays
calculated by a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> to be output. The ID in the
attribute should be replaced by the actual ID of the compute that has
been defined previously in the input script. See the
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command for details. There are computes for
calculating the per-atom energy, stress, centro-symmetry parameter,
and coordination number of individual atoms.</p>
<p>Note that computes which calculate global or local quantities, as
opposed to per-atom quantities, cannot be output in a dump custom/vtk
command. Instead, global quantities can be output by the
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command, and local quantities
can be output by the dump local command.</p>
<p>If <em>c_ID</em> is used as an attribute, then the per-atom vector calculated
by the compute is printed. If <em>c_ID[N]</em> is used, then N must be in
the range from 1-M, which will print the Nth column of the M-length
per-atom array calculated by the compute.</p>
<p>The <em>f_ID</em> and <em>f_ID[N]</em> attributes allow vector or array per-atom
quantities calculated by a <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> to be output. The ID in the
attribute should be replaced by the actual ID of the fix that has been
defined previously in the input script. The <a class="reference internal" href="fix_ave_atom.html"><span class="doc">fix ave/atom</span></a> command is one that calculates per-atom
quantities. Since it can time-average per-atom quantities produced by
any <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>, <a class="reference internal" href="fix.html"><span class="doc">fix</span></a>, or atom-style
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a>, this allows those time-averaged results to
be written to a dump file.</p>
<p>If <em>f_ID</em> is used as a attribute, then the per-atom vector calculated
by the fix is printed. If <em>f_ID[N]</em> is used, then N must be in the
range from 1-M, which will print the Nth column of the M-length
per-atom array calculated by the fix.</p>
<p>The <em>v_name</em> attribute allows per-atom vectors calculated by a
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> to be output. The name in the attribute
should be replaced by the actual name of the variable that has been
defined previously in the input script. Only an atom-style variable
can be referenced, since it is the only style that generates per-atom
values. Variables of style <em>atom</em> can reference individual atom
attributes, per-atom atom attributes, thermodynamic keywords, or
invoke other computes, fixes, or variables when they are evaluated, so
this is a very general means of creating quantities to output to a
dump file.</p>
<p>See <a class="reference internal" href="Section_modify.html"><span class="doc">Section_modify</span></a> of the manual for information
on how to add new compute and fix styles to LAMMPS to calculate
per-atom quantities which could then be output into dump files.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The <em>custom/vtk</em> style does not support writing of gzipped dump files.</p>
<p>The <em>custom/vtk</em> dump style is part of the USER-VTK package. It is
only enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>To use this dump style, you also must link to the VTK library. See
the info in lib/vtk/README and insure the Makefile.lammps file in that
directory is appropriate for your machine.</p>
<p>The <em>custom/vtk</em> dump style neither supports buffering nor custom
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>group-ID = ID of the group of atoms to be imaged</li>
<li>style = <em>image</em> or <em>movie</em> = style of dump command (other styles <em>atom</em> or <em>cfg</em> or <em>dcd</em> or <em>xtc</em> or <em>xyz</em> or <em>local</em> or <em>custom</em> are discussed on the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> doc page)</li>
<li>N = dump every this many timesteps</li>
<li>file = name of file to write image to</li>
<li>color = atom attribute that determines color of each atom</li>
<li>diameter = atom attribute that determines size of each atom</li>
<li>zero or more keyword/value pairs may be appended</li>
<li>keyword = <em>atom</em> or <em>adiam</em> or <em>bond</em> or <em>line</em> or <em>tri</em> or <em>body</em> or <em>fix</em> or <em>size</em> or <em>view</em> or <em>center</em> or <em>up</em> or <em>zoom</em> or <em>persp</em> or <em>box</em> or <em>axes</em> or <em>subbox</em> or <em>shiny</em> or <em>ssao</em></li>
</ul>
<pre class="literal-block">
<em>atom</em> = yes/no = do or do not draw atoms
<em>adiam</em> size = numeric value for atom diameter (distance units)
<em>bond</em> values = color width = color and width of bonds
color = <em>atom</em> or <em>type</em> or <em>none</em>
width = number or <em>atom</em> or <em>type</em> or <em>none</em>
number = numeric value for bond width (distance units)
<em>line</em> = color width
color = <em>type</em>
width = numeric value for line width (distance units)
<em>tri</em> = color tflag width
color = <em>type</em>
tflag = 1 for just triangle, 2 for just tri edges, 3 for both
width = numeric value for tringle edge width (distance units)
<em>body</em> = color bflag1 bflag2
color = <em>type</em>
bflag1,bflag2 = 2 numeric flags to affect how bodies are drawn
<em>fix</em> = fixID color fflag1 fflag2
fixID = ID of fix that generates objects to dray
color = <em>type</em>
fflag1,fflag2 = 2 numeric flags to affect how fix objects are drawn
<em>size</em> values = width height = size of images
width = width of image in # of pixels
height = height of image in # of pixels
<em>view</em> values = theta phi = view of simulation box
theta = view angle from +z axis (degrees)
phi = azimuthal view angle (degrees)
theta or phi can be a variable (see below)
<em>center</em> values = flag Cx Cy Cz = center point of image
flag = "s" for static, "d" for dynamic
Cx,Cy,Cz = center point of image as fraction of box dimension (0.5 = center of box)
Cx,Cy,Cz can be variables (see below)
<em>up</em> values = Ux Uy Uz = direction that is "up" in image
Ux,Uy,Uz = components of up vector
Ux,Uy,Uz can be variables (see below)
<em>zoom</em> value = zfactor = size that simulation box appears in image
zfactor = scale image size by factor > 1 to enlarge, factor < 1 to shrink
zfactor can be a variable (see below)
<em>persp</em> value = pfactor = amount of "perspective" in image
-which are prefixed by “<a href="#id9"><span class="problematic" id="id10">c_</span></a>”, “<a href="#id11"><span class="problematic" id="id12">f_</span></a>”, or “<a href="#id13"><span class="problematic" id="id14">v_</span></a>” respectively. Note that the
+which are prefixed by “c_”, “f_”, or “v_” respectively. Note that the
<em>diameter</em> setting can be overridden with a numeric value applied to
all atoms by the optional <em>adiam</em> keyword.</p>
<p>If <em>type</em> is specified for the <em>color</em> setting, then the color of each
atom is determined by its atom type. By default the mapping of types
to colors is as follows:</p>
<ul class="simple">
<li>type 1 = red</li>
<li>type 2 = green</li>
<li>type 3 = blue</li>
<li>type 4 = yellow</li>
<li>type 5 = aqua</li>
<li>type 6 = cyan</li>
</ul>
<p>and repeats itself for types > 6. This mapping can be changed by the
<p>If <em>type</em> is specified for the <em>diameter</em> setting then the diameter of
each atom is determined by its atom type. By default all types have
diameter 1.0. This mapping can be changed by the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify adiam</span></a> command.</p>
<p>If <em>element</em> is specified for the <em>color</em> and/or <em>diameter</em> setting,
then the color and/or diameter of each atom is determined by which
element it is, which in turn is specified by the element-to-type
mapping specified by the “dump_modify element” command. By default
every atom type is C (carbon). Every element has a color and diameter
associated with it, which is the same as the colors and sizes used by
the <a class="reference external" href="http://mt.seas.upenn.edu/Archive/Graphics/A">AtomEye</a> visualization package.</p>
<p>If other atom attributes are used for the <em>color</em> or <em>diameter</em>
settings, they are interpreted in the following way.</p>
<p>If “vx”, for example, is used as the <em>color</em> setting, then the color
of the atom will depend on the x-component of its velocity. The
association of a per-atom value with a specific color is determined by
a “color map”, which can be specified via the
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command. The basic idea is that the
atom-attribute will be within a range of values, and every value
within the range is mapped to a specific color. Depending on how the
color map is defined, that mapping can take place via interpolation so
that a value of -3.2 is halfway between “red” and “blue”, or
discretely so that the value of -3.2 is “orange”.</p>
<p>If “vx”, for example, is used as the <em>diameter</em> setting, then the atom
will be rendered using the x-component of its velocity as the
diameter. If the per-atom value <= 0.0, them the atom will not be
drawn. Note that finite-size spherical particles, as defined by
<a class="reference internal" href="atom_style.html"><span class="doc">atom_style sphere</span></a> define a per-particle radius or
diameter, which can be used as the <em>diameter</em> setting.</p>
<hr class="docutils" />
<p>The various kewords listed above control how the image is rendered.
As listed below, all of the keywords have defaults, most of which you
will likely not need to change. The <a class="reference internal" href="dump_modify.html"><span class="doc">dump modify</span></a>
also has options specific to the dump image style, particularly for
assigning colors to atoms, bonds, and other image features.</p>
<hr class="docutils" />
<p>The <em>atom</em> keyword allow you to turn off the drawing of all atoms, if
the specified value is <em>no</em>. Note that this will not turn off the
drawing of particles that are represented as lines, triangles, or
bodies, as discussed below. These particles can be drawn separately
if the <em>line</em>, <em>tri</em>, or <em>body</em> keywords are used.</p>
<p>The <em>adiam</em> keyword allows you to override the <em>diameter</em> setting to
set a single numeric <em>size</em>. All atoms will be drawn with that
diameter, e.g. 1.5, which is in whatever distance <a class="reference internal" href="units.html"><span class="doc">units</span></a>
the input script defines, e.g. Angstroms.</p>
<hr class="docutils" />
<p>The <em>bond</em> keyword allows to you to alter how bonds are drawn. A bond
is only drawn if both atoms in the bond are being drawn due to being
in the specified group and due to other selection criteria
(e.g. region, threshhold settings of the
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command). By default, bonds are drawn
if they are defined in the input data file as read by the
<a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command. Using <em>none</em> for both the bond
<em>color</em> and <em>width</em> value will turn off the drawing of all bonds.</p>
<p>If <em>atom</em> is specified for the bond <em>color</em> value, then each bond is
drawn in 2 halves, with the color of each half being the color of the
atom at that end of the bond.</p>
<p>If <em>type</em> is specified for the <em>color</em> value, then the color of each
bond is determined by its bond type. By default the mapping of bond
types to colors is as follows:</p>
<ul class="simple">
<li>type 1 = red</li>
<li>type 2 = green</li>
<li>type 3 = blue</li>
<li>type 4 = yellow</li>
<li>type 5 = aqua</li>
<li>type 6 = cyan</li>
</ul>
<p>and repeats itself for bond types > 6. This mapping can be changed by
the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify bcolor</span></a> command.</p>
<p>The bond <em>width</em> value can be a numeric value or <em>atom</em> or <em>type</em> (or
<em>none</em> as indicated above).</p>
<p>If a numeric value is specified, then all bonds will be drawn as
cylinders with that diameter, e.g. 1.0, which is in whatever distance
<a class="reference internal" href="units.html"><span class="doc">units</span></a> the input script defines, e.g. Angstroms.</p>
<p>If <em>atom</em> is specified for the <em>width</em> value, then each bond
will be drawn with a width corresponding to the minimum diameter
of the 2 atoms in the bond.</p>
<p>If <em>type</em> is specified for the <em>width</em> value then the diameter of each
bond is determined by its bond type. By default all types have
diameter 0.5. This mapping can be changed by the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify bdiam</span></a> command.</p>
<hr class="docutils" />
<p>The <em>line</em> keyword can be used when <a class="reference internal" href="atom_style.html"><span class="doc">atom_style line</span></a>
is used to define particles as line segments, and will draw them as
lines. If this keyword is not used, such particles will be drawn as
spheres, the same as if they were regular atoms. The only setting
currently allowed for the <em>color</em> value is <em>type</em>, which will color
the lines according to the atom type of the particle. By default the
mapping of types to colors is as follows:</p>
<ul class="simple">
<li>type 1 = red</li>
<li>type 2 = green</li>
<li>type 3 = blue</li>
<li>type 4 = yellow</li>
<li>type 5 = aqua</li>
<li>type 6 = cyan</li>
</ul>
<p>and repeats itself for types > 6. There is not yet an option to
change this via the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command.</p>
<p>The line <em>width</em> can only be a numeric value, which specifies that all
lines will be drawn as cylinders with that diameter, e.g. 1.0, which
is in whatever distance <a class="reference internal" href="units.html"><span class="doc">units</span></a> the input script defines,
e.g. Angstroms.</p>
<hr class="docutils" />
<p>The <em>tri</em> keyword can be used when <a class="reference internal" href="atom_style.html"><span class="doc">atom_style tri</span></a> is
used to define particles as triangles, and will draw them as triangles
or edges (3 lines) or both, depending on the setting for <em>tflag</em>. If
edges are drawn, the <em>width</em> setting determines the diameters of the
line segments. If this keyword is not used, triangle particles will
be drawn as spheres, the same as if they were regular atoms. The only
setting currently allowed for the <em>color</em> value is <em>type</em>, which will
color the triangles according to the atom type of the particle. By
default the mapping of types to colors is as follows:</p>
<ul class="simple">
<li>type 1 = red</li>
<li>type 2 = green</li>
<li>type 3 = blue</li>
<li>type 4 = yellow</li>
<li>type 5 = aqua</li>
<li>type 6 = cyan</li>
</ul>
<p>and repeats itself for types > 6. There is not yet an option to
change this via the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command.</p>
<hr class="docutils" />
<p>The <em>body</em> keyword can be used when <a class="reference internal" href="atom_style.html"><span class="doc">atom_style body</span></a>
is used to define body particles with internal state
(e.g. sub-particles), and will drawn them in a manner specific to the
body style. If this keyword is not used, such particles will be drawn
as spheres, the same as if they were regular atoms.</p>
<p>The <a class="reference internal" href="body.html"><span class="doc">body</span></a> doc page descibes the body styles LAMMPS
currently supports, and provides more details as to the kind of body
particles they represent and how they are drawn by this dump image
command. For all the body styles, individual atoms can be either a
body particle or a usual point (non-body) particle. Non-body
particles will be drawn the same way they would be as a regular atom.
The <em>bflag1</em> and <em>bflag2</em> settings are numerical values which are
passed to the body style to affect how the drawing of a body particle
is done. See the <a class="reference internal" href="body.html"><span class="doc">body</span></a> doc page for a description of what
these parameters mean for each body style.</p>
<p>The only setting currently allowed for the <em>color</em> value is <em>type</em>,
which will color the body particles according to the atom type of the
particle. By default the mapping of types to colors is as follows:</p>
<ul class="simple">
<li>type 1 = red</li>
<li>type 2 = green</li>
<li>type 3 = blue</li>
<li>type 4 = yellow</li>
<li>type 5 = aqua</li>
<li>type 6 = cyan</li>
</ul>
<p>and repeats itself for types > 6. There is not yet an option to
change this via the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command.</p>
<hr class="docutils" />
<p>The <em>fix</em> keyword can be used with a <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> that produces
objects to be drawn. An example is the <span class="xref doc">fix surface/global</span> command which can draw lines
or triangles for 2d/3d simulations.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Aug 2016 - The fix surface/global command is not yet added to
LAMMPS.</p>
</div>
<p>The <em>fflag1</em> and <em>fflag2</em> settings are numerical values which are
passed to the fix to affect how the drawing of its objects is done.
See the individual fix doc page for a description of what these
parameters mean for a particular fix.</p>
<p>The only setting currently allowed for the <em>color</em> value is <em>type</em>,
which will color the fix objects according to their type. By default
the mapping of types to colors is as follows:</p>
<ul class="simple">
<li>type 1 = red</li>
<li>type 2 = green</li>
<li>type 3 = blue</li>
<li>type 4 = yellow</li>
<li>type 5 = aqua</li>
<li>type 6 = cyan</li>
</ul>
<p>and repeats itself for types > 6. There is not yet an option to
change this via the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command.</p>
<hr class="docutils" />
<p>The <em>size</em> keyword sets the width and height of the created images,
i.e. the number of pixels in each direction.</p>
<hr class="docutils" />
<p>The <em>view</em>, <em>center</em>, <em>up</em>, <em>zoom</em>, and <em>persp</em> values determine how
3d simulation space is mapped to the 2d plane of the image. Basically
they control how the simulation box appears in the image.</p>
<p>All of the <em>view</em>, <em>center</em>, <em>up</em>, <em>zoom</em>, and <em>persp</em> values can be
specified as numeric quantities, whose meaning is explained below.
Any of them can also be specified as an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a>, by using v_name as the value, where “name” is
the variable name. In this case the variable will be evaluated on the
timestep each image is created to create a new value. If the
equal-style variable is time-dependent, this is a means of changing
the way the simulation box appears from image to image, effectively
doing a pan or fly-by view of your simulation.</p>
<p>The <em>view</em> keyword determines the viewpoint from which the simulation
box is viewed, looking towards the <em>center</em> point. The <em>theta</em> value
is the vertical angle from the +z axis, and must be an angle from 0 to
180 degrees. The <em>phi</em> value is an azimuthal angle around the z axis
and can be positive or negative. A value of 0.0 is a view along the
+x axis, towards the <em>center</em> point. If <em>theta</em> or <em>phi</em> are
specified via variables, then the variable values should be in
degrees.</p>
<p>The <em>center</em> keyword determines the point in simulation space that
will be at the center of the image. <em>Cx</em>, <em>Cy</em>, and <em>Cz</em> are
speficied as fractions of the box dimensions, so that (0.5,0.5,0.5) is
the center of the simulation box. These values do not have to be
between 0.0 and 1.0, if you want the simulation box to be offset from
the center of the image. Note, however, that if you choose strange
values for <em>Cx</em>, <em>Cy</em>, or <em>Cz</em> you may get a blank image. Internally,
<em>Cx</em>, <em>Cy</em>, and <em>Cz</em> are converted into a point in simulation space.
If <em>flag</em> is set to “s” for static, then this conversion is done once,
at the time the dump command is issued. If <em>flag</em> is set to “d” for
dynamic then the conversion is performed every time a new image is
created. If the box size or shape is changing, this will adjust the
center point in simulation space.</p>
<p>The <em>up</em> keyword determines what direction in simulation space will be
“up” in the image. Internally it is stored as a vector that is in the
plane perpendicular to the view vector implied by the <em>theta</em> and
<em>pni</em> values, and which is also in the plane defined by the view
vector and user-specified up vector. Thus this internal vector is
computed from the user-specified <em>up</em> vector as</p>
<p>This means the only restriction on the specified <em>up</em> vector is that
it cannot be parallel to the <em>view</em> vector, implied by the <em>theta</em> and
<em>phi</em> values.</p>
<p>The <em>zoom</em> keyword scales the size of the simulation box as it appears
in the image. The default <em>zfactor</em> value of 1 should display an
image mostly filled by the atoms in the simulation box. A <em>zfactor</em> >
1 will make the simulation box larger; a <em>zfactor</em> < 1 will make it
smaller. <em>Zfactor</em> must be a value > 0.0.</p>
<p>The <em>persp</em> keyword determines how much depth perspective is present
in the image. Depth perspective makes lines that are parallel in
simulation space appear non-parallel in the image. A <em>pfactor</em> value
of 0.0 means that parallel lines will meet at infininty (1.0/pfactor),
which is an orthographic rendering with no persepctive. A <em>pfactor</em>
value between 0.0 and 1.0 will introduce more perspective. A <em>pfactor</em>
value > 1 will create a highly skewed image with a large amount of
perspective.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The <em>persp</em> keyword is not yet supported as an option.</p>
</div>
<hr class="docutils" />
<p>The <em>box</em> keyword determines if and how the simulation box boundaries
are rendered as thin cylinders in the image. If <em>no</em> is set, then the
box boundaries are not drawn and the <em>diam</em> setting is ignored. If
<em>yes</em> is set, the 12 edges of the box are drawn, with a diameter that
is a fraction of the shortest box length in x,y,z (for 3d) or x,y (for
2d). The color of the box boundaries can be set with the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify boxcolor</span></a> command.</p>
<p>The <em>axes</em> keyword determines if and how the coordinate axes are
rendered as thin cylinders in the image. If <em>no</em> is set, then the
axes are not drawn and the <em>length</em> and <em>diam</em> settings are ignored.
If <em>yes</em> is set, 3 thin cylinders are drawn to represent the x,y,z
axes in colors red,green,blue. The origin of these cylinders will be
offset from the lower left corner of the box by 10%. The <em>length</em>
setting determines how long the cylinders will be as a fraction of the
respective box lengths. The <em>diam</em> setting determines their thickness
as a fraction of the shortest box length in x,y,z (for 3d) or x,y (for
2d).</p>
<p>The <em>subbox</em> keyword determines if and how processor sub-domain
boundaries are rendered as thin cylinders in the image. If <em>no</em> is
set (default), then the sub-domain boundaries are not drawn and the
<em>diam</em> setting is ignored. If <em>yes</em> is set, the 12 edges of each
processor sub-domain are drawn, with a diameter that is a fraction of
the shortest box length in x,y,z (for 3d) or x,y (for 2d). The color
of the sub-domain boundaries can be set with the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify boxcolor</span></a> command.</p>
<hr class="docutils" />
<p>The <em>shiny</em> keyword determines how shiny the objects rendered in the
image will appear. The <em>sfactor</em> value must be a value 0.0 <=
<em>sfactor</em> <= 1.0, where <em>sfactor</em> = 1 is a highly reflective surface
and <em>sfactor</em> = 0 is a rough non-shiny surface.</p>
<p>The <em>ssao</em> keyword turns on/off a screen space ambient occlusion
(SSAO) model for depth shading. If <em>yes</em> is set, then atoms further
away from the viewer are darkened via a randomized process, which is
perceived as depth. The calculation of this effect can increase the
cost of computing the image by roughly 2x. The strength of the effect
can be scaled by the <em>dfactor</em> parameter. If <em>no</em> is set, no depth
shading is performed.</p>
<hr class="docutils" />
<p>A series of JPEG, PNG, or PPM images can be converted into a movie
file and then played as a movie using commonly available tools. Using
dump style <em>movie</em> automates this step and avoids the intermediate
step of writing (many) image snapshot file. But LAMMPS has to be
compiled with -DLAMMPS_FFMPEG and an FFmpeg executable have to be
installed.</p>
<p>To manually convert JPEG, PNG or PPM files into an animated GIF or
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>one or more keyword/value pairs may be appended</li>
<li>these keywords apply to various dump styles</li>
<li>keyword = <em>append</em> or <em>buffer</em> or <em>element</em> or <em>every</em> or <em>fileper</em> or <em>first</em> or <em>flush</em> or <em>format</em> or <em>image</em> or <em>label</em> or <em>nfile</em> or <em>pad</em> or <em>precision</em> or <em>region</em> or <em>scale</em> or <em>sort</em> or <em>thresh</em> or <em>unwrap</em></li>
</ul>
<pre class="literal-block">
<em>append</em> arg = <em>yes</em> or <em>no</em>
<em>buffer</em> arg = <em>yes</em> or <em>no</em>
<em>element</em> args = E1 E2 ... EN, where N = # of atom types
E1,...,EN = element name, e.g. C or Fe or Ga
<em>every</em> arg = N
N = dump every this many timesteps
N can be a variable (see below)
<em>fileper</em> arg = Np
Np = write one file for every this many processors
<em>first</em> arg = <em>yes</em> or <em>no</em>
<em>format</em> args = <em>line</em> string, <em>int</em> string, <em>float</em> string, M string, or <em>none</em>
string = C-style format string
M = integer from 1 to N, where N = # of per-atom quantities being output
<em>flush</em> arg = <em>yes</em> or <em>no</em>
<em>image</em> arg = <em>yes</em> or <em>no</em>
<em>label</em> arg = string
string = character string (e.g. BONDS) to use in header of dump local file
<em>nfile</em> arg = Nf
Nf = write this many files, one from each of Nf processors
<em>pad</em> arg = Nchar = # of characters to convert timestep to
<em>pbc</em> arg = <em>yes</em> or <em>no</em> = remap atoms via periodic boundary conditions
<em>precision</em> arg = power-of-10 value from 10 to 1000000
<em>region</em> arg = region-ID or "none"
<em>tfactor</em> arg = time scaling factor (> 0.0)
<em>sort</em> arg = <em>off</em> or <em>id</em> or N or -N
off = no sorting of per-atom lines within a snapshot
id = sort per-atom lines by atom ID
N = sort per-atom lines in ascending order by the Nth column
-N = sort per-atom lines in descending order by the Nth column
<em>thresh</em> args = attribute operation value
attribute = same attributes (x,fy,etotal,sxx,etc) used by dump custom style
operation = "<" or "<=" or ">" or ">=" or "==" or "!="
value = numeric value to compare to
these 3 args can be replaced by the word "none" to turn off thresholding
<em>unwrap</em> arg = <em>yes</em> or <em>no</em>
</pre>
<ul class="simple">
<li>these keywords apply only to the <em>image</em> and <em>movie</em> <a class="reference internal" href="dump_image.html"><span class="doc">styles</span></a></li>
<li>keyword = <em>acolor</em> or <em>adiam</em> or <em>amap</em> or <em>backcolor</em> or <em>bcolor</em> or <em>bdiam</em> or <em>boxcolor</em> or <em>color</em> or <em>bitrate</em> or <em>framerate</em></li>
</ul>
<pre class="literal-block">
<em>acolor</em> args = type color
type = atom type or range of types (see below)
color = name of color or color1/color2/...
<em>adiam</em> args = type diam
type = atom type or range of types (see below)
diam = diameter of atoms of that type (distance units)
<em>amap</em> args = lo hi style delta N entry1 entry2 ... entryN
lo = number or <em>min</em> = lower bound of range of color map
hi = number or <em>max</em> = upper bound of range of color map
style = 2 letters = "c" or "d" or "s" plus "a" or "f"
"c" for continuous
"d" for discrete
"s" for sequential
"a" for absolute
"f" for fractional
delta = binsize (only used for style "s", otherwise ignored)
binsize = range is divided into bins of this width
N = # of subsequent entries
entry = value color (for continuous style)
value = number or <em>min</em> or <em>max</em> = single value within range
color = name of color used for that value
entry = lo hi color (for discrete style)
lo/hi = number or <em>min</em> or <em>max</em> = lower/upper bound of subset of range
color = name of color used for that subset of values
entry = color (for sequential style)
color = name of color used for a bin of values
<em>backcolor</em> arg = color
color = name of color for background
<em>bcolor</em> args = type color
type = bond type or range of types (see below)
color = name of color or color1/color2/...
<em>bdiam</em> args = type diam
type = bond type or range of types (see below)
diam = diameter of bonds of that type (distance units)
<em>boxcolor</em> arg = color
color = name of color for simulation box lines and processor sub-domain lines
<em>color</em> args = name R G B
name = name of color
R,G,B = red/green/blue numeric values from 0.0 to 1.0
+dump_modify 1 format line "%d %d %20.15g %g %g" scale yes
+dump_modify 1 format float %20.15g scale yes
+dump_modify myDump image yes scale no flush yes
+dump_modify 1 region mySphere thresh x < 0.0 thresh epair >= 3.2
+dump_modify xtcdump precision 10000 sfactor 0.1
+dump_modify 1 every 1000 nfile 20
+dump_modify 1 every v_myVar
+dump_modify 1 amap min max cf 0.0 3 min green 0.5 yellow max blue boxcolor red
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Modify the parameters of a previously defined dump command. Not all
parameters are relevant to all dump styles.</p>
<p>As explained on the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> doc page, the <em>atom/mpiio</em>,
<em>custom/mpiio</em>, and <em>xyz/mpiio</em> dump styles are identical in command
syntax and in the format of the dump files they create, to the
corresponding styles without “mpiio”, except the single dump file they
produce is written in parallel via the MPI-IO library. Thus if a
dump_modify option below is valid for the <em>atom</em> style, it is also
valid for the <em>atom/mpiio</em> style, and similarly for the other styles
which allow for use of MPI-IO.</p>
<p>These keywords apply to various dump styles, including the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a> and <a class="reference internal" href="dump_image.html"><span class="doc">dump movie</span></a> styles. The
description gives details.</p>
<hr class="docutils" />
<p>The <em>append</em> keyword applies to all dump styles except <em>cfg</em> and <em>xtc</em>
and <em>dcd</em>. It also applies only to text output files, not to binary
or gzipped or image/movie files. If specified as <em>yes</em>, then dump
snapshots are appended to the end of an existing dump file. If
specified as <em>no</em>, then a new dump file will be created which will
overwrite an existing file with the same name. This keyword can only
take effect if the dump_modify command is used after the
<a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command, but before the first command that causes
dump snapshots to be output, e.g. a <a class="reference internal" href="run.html"><span class="doc">run</span></a> or
<a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command. Once the dump file has been opened,
this keyword has no further effect.</p>
<hr class="docutils" />
<p>The <em>buffer</em> keyword applies only to dump styles <em>atom</em>, <em>cfg</em>,
<em>custom</em>, <em>local</em>, and <em>xyz</em>. It also applies only to text output
files, not to binary or gzipped files. If specified as <em>yes</em>, which
is the default, then each processor writes its output into an internal
text buffer, which is then sent to the processor(s) which perform file
writes, and written by those processors(s) as one large chunk of text.
If specified as <em>no</em>, each processor sends its per-atom data in binary
format to the processor(s) which perform file wirtes, and those
processor(s) format and write it line by line into the output file.</p>
<p>The buffering mode is typically faster since each processor does the
relatively expensive task of formatting the output for its own atoms.
However it requires about twice the memory (per processor) for the
extra buffering.</p>
<hr class="docutils" />
<p>The <em>element</em> keyword applies only to the the dump <em>cfg</em>, <em>xyz</em>, and
<em>image</em> styles. It associates element names (e.g. H, C, Fe) with
LAMMPS atom types. See the list of element names at the bottom of
this page.</p>
<p>In the case of dump <em>cfg</em>, this allows the <a class="reference external" href="http://mt.seas.upenn.edu/Archive/Graphics/A">AtomEye</a>
visualization package to read the dump file and render atoms with the
appropriate size and color.</p>
<p>In the case of dump <em>image</em>, the output images will follow the same
<a class="reference external" href="http://mt.seas.upenn.edu/Archive/Graphics/A">AtomEye</a> convention. An element name is specified for each
atom type (1 to Ntype) in the simulation. The same element name can
be given to multiple atom types.</p>
<p>In the case of <em>xyz</em> format dumps, there are no restrictions to what
label can be used as an element name. Any whitespace separated text
will be accepted.</p>
<hr class="docutils" />
<p>The <em>every</em> keyword changes the dump frequency originally specified by
the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command to a new value. The every keyword can be
specified in one of two ways. It can be a numeric value in which case
it must be > 0. Or it can be an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a>,
which should be specified as v_name, where name is the variable name.</p>
<p>In this case, the variable is evaluated at the beginning of a run to
determine the next timestep at which a dump snapshot will be written
out. On that timestep the variable will be evaluated again to
determine the next timestep, etc. Thus the variable should return
timestep values. See the stagger() and logfreq() and stride() math
functions for <a class="reference internal" href="variable.html"><span class="doc">equal-style variables</span></a>, as examples of
useful functions to use in this context. Other similar math functions
could easily be added as options for <a class="reference internal" href="variable.html"><span class="doc">equal-style variables</span></a>. Also see the next() function, which allows
use of a file-style variable which reads successive values from a
file, each time the variable is evaluated. Used with the <em>every</em>
keyword, if the file contains a list of ascending timesteps, you can
output snapshots whenever you wish.</p>
<p>Note that when using the variable option with the <em>every</em> keyword, you
need to use the <em>first</em> option if you want an initial snapshot written
to the dump file. The <em>every</em> keyword cannot be used with the dump
<em>dcd</em> style.</p>
<p>For example, the following commands will
write snapshots at timesteps 0,10,20,30,100,200,300,1000,2000,etc:</p>
<p class="last">When using a file-style variable with the <em>every</em> keyword, the
file of timesteps must list a first timestep that is beyond the
current timestep (e.g. it cannot be 0). And it must list one or more
timesteps beyond the length of the run you perform. This is because
the dump command will generate an error if the next timestep it reads
from the file is not a value greater than the current timestep. Thus
if you wanted output on steps 0,15,100 of a 100-timestep run, the file
should contain the values 15,100,101 and you should also use the
dump_modify first command. Any final value > 100 could be used in
place of 101.</p>
</div>
<hr class="docutils" />
<p>The <em>first</em> keyword determines whether a dump snapshot is written on
the very first timestep after the dump command is invoked. This will
always occur if the current timestep is a multiple of N, the frequency
specified in the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command, including timestep 0. But
if this is not the case, a dump snapshot will only be written if the
setting of this keyword is <em>yes</em>. If it is <em>no</em>, which is the
default, then it will not be written.</p>
<hr class="docutils" />
<p>The <em>flush</em> keyword determines whether a flush operation is invoked
after a dump snapshot is written to the dump file. A flush insures
the output in that file is current (no buffering by the OS), even if
LAMMPS halts before the simulation completes. Flushes cannot be
performed with dump style <em>xtc</em>.</p>
<hr class="docutils" />
<p>The <em>format</em> keyword can be used to change the default numeric format
output by the text-based dump styles: <em>atom</em>, <em>custom</em>, <em>cfg</em>, and
<em>xyz</em> styles, and their MPIIO variants. Only the <em>line</em> or <em>none</em>
options can be used with the <em>atom</em> and <em>xyz</em> styles.</p>
<p>All the specified format strings are C-style formats, e.g. as used by
the C/C++ printf() command. The <em>line</em> keyword takes a single
argument which is the format string for an entire line of output for
each atom (do not include a trailing “n”), with N fields, which you
must enclose in quotes if it is more than one field. The <em>int</em> and
<em>float</em> keywords take a single format argument and are applied to all
integer or floating-point quantities output. The setting for <em>M
string</em> also takes a single format argument which is used for the Mth
value output in each line, e.g. the 5th column is output in high
precision for “format 5 %20.15g”.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When using the <em>line</em> keyword for the <em>cfg</em> style, the first two
fields (atom ID and type) are not actually written into the CFG file,
however you must include formats for them in the format string.</p>
</div>
<p>The <em>format</em> keyword can be used multiple times. The precedence is
that for each value in a line of output, the <em>M</em> format (if specified)
is used, else the <em>int</em> or <em>float</em> setting (if specified) is used,
else the <em>line</em> setting (if specified) for that value is used, else
the default setting is used. A setting of <em>none</em> clears all previous
settings, reverting all values to their default format.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Atom and molecule IDs are stored internally as 4-byte or 8-byte
signed integers, depending on how LAMMPS was compiled. When
specifying the <em>format int</em> option you can use a “%d”-style format
identifier in the format string and LAMMPS will convert this to the
corresponding 8-byte form it it is needed when outputting those
values. However, when specifying the <em>line</em> option or <em>format M
string</em> option for those values, you should specify a format string
appropriate for an 8-byte signed integer, e.g. one with “%ld”, if
LAMMPS was compiled with the -DLAMMPS_BIGBIG option for 8-byte IDs.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Any value written to a text-based dump file that is a per-atom
quantity calculated by a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> or <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> is
stored internally as a floating-point value. If the value is actually
an integer and you wish it to appear in the text dump file as a
(large) integer, then you need to use an appropriate format. For
<p>The word “ENTRIES” will be replaced with the string specified,
e.g. BONDS or ANGLES.</p>
<hr class="docutils" />
<p>The <em>nfile</em> or <em>fileper</em> keywords can be used in conjunction with the
“%” wildcard character in the specified dump file name, for all dump
styles except the <em>dcd</em>, <em>image</em>, <em>movie</em>, <em>xtc</em>, and <em>xyz</em> styles
(for which “%” is not allowed). As explained on the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a>
command doc page, the “%” character causes the dump file to be written
in pieces, one piece for each of P processors. By default P = the
number of processors the simulation is running on. The <em>nfile</em> or
<em>fileper</em> keyword can be used to set P to a smaller value, which can
be more efficient when running on a large number of processors.</p>
<p>The <em>nfile</em> keyword sets P to the specified Nf value. For example, if
Nf = 4, and the simulation is running on 100 processors, 4 files will
be written, by processors 0,25,50,75. Each will collect information
from itself and the next 24 processors and write it to a dump file.</p>
<p>For the <em>fileper</em> keyword, the specified value of Np means write one
file for every Np processors. For example, if Np = 4, every 4th
processor (0,4,8,12,etc) will collect information from itself and the
next 3 processors and write it to a dump file.</p>
<hr class="docutils" />
<p>The <em>pad</em> keyword only applies when the dump filename is specified
with a wildcard “*” character which becomes the timestep. If <em>pad</em> is
0, which is the default, the timestep is converted into a string of
unpadded length, e.g. 100 or 12000 or 2000000. When <em>pad</em> is
specified with <em>Nchar</em> > 0, the string is padded with leading zeroes
so they are all the same length = <em>Nchar</em>. For example, pad 7 would
yield 0000100, 0012000, 2000000. This can be useful so that
post-processing programs can easily read the files in ascending
timestep order.</p>
<hr class="docutils" />
<p>The <em>pbc</em> keyword applies to all the dump styles. As explained on the
<a class="reference internal" href="dump.html"><span class="doc">dump</span></a> doc page, atom coordinates in a dump file may be
slightly outside the simulation box. This is because periodic
boundary conditions are enforced only on timesteps when neighbor lists
are rebuilt, which will not typically coincide with the timesteps dump
snapshots are written. If the setting of this keyword is set to
<em>yes</em>, then all atoms will be remapped to the periodic box before the
snapshot is written, then restored to their original position. If it
is set to <em>no</em> they will not be. The <em>no</em> setting is the default
because it requires no extra computation.</p>
<hr class="docutils" />
<p>The <em>precision</em> keyword only applies to the dump <em>xtc</em> style. A
specified value of N means that coordinates are stored to 1/N
nanometer accuracy, e.g. for N = 1000, the coordinates are written to
1/1000 nanometer accuracy.</p>
<hr class="docutils" />
<p>The <em>sfactor</em> and <em>tfactor</em> keywords only apply to the dump <em>xtc</em>
style. They allow customization of the unit conversion factors used
when writing to XTC files. By default they are initialized for
whatever <a class="reference internal" href="units.html"><span class="doc">units</span></a> style is being used, to write out
coordinates in nanometers and time in picoseconds. I.e. for <em>real</em>
units, LAMMPS defines <em>sfactor</em> = 0.1 and <em>tfactor</em> = 0.001, since the
Angstroms and fmsec used by <em>real</em> units are 0.1 nm and 0.001 psec
respectively. If you are using a units system with distance and time
units far from nm and psec, you may wish to write XTC files with
different units, since the compression algorithm used in XTC files is
most effective when the typical magnitude of position data is between
10.0 and 0.1.</p>
<hr class="docutils" />
<p>The <em>region</em> keyword only applies to the dump <em>custom</em>, <em>cfg</em>,
<em>image</em>, and <em>movie</em> styles. If specified, only atoms in the region
will be written to the dump file or included in the image/movie. Only
one region can be applied as a filter (the last one specified). See
the <a class="reference internal" href="region.html"><span class="doc">region</span></a> command for more details. Note that a region
can be defined as the “inside” or “outside” of a geometric shape, and
it can be the “union” or “intersection” of a series of simpler
regions.</p>
<hr class="docutils" />
<p>The <em>scale</em> keyword applies only to the dump <em>atom</em> style. A scale
value of <em>yes</em> means atom coords are written in normalized units from
0.0 to 1.0 in each box dimension. If the simluation box is triclinic
(tilted), then all atom coords will still be between 0.0 and 1.0. A
value of <em>no</em> means they are written in absolute distance units
(e.g. Angstroms or sigma).</p>
<hr class="docutils" />
<p>The <em>sort</em> keyword determines whether lines of per-atom output in a
snapshot are sorted or not. A sort value of <em>off</em> means they will
typically be written in indeterminate order, either in serial or
parallel. This is the case even in serial if the <a class="reference internal" href="atom_modify.html"><span class="doc">atom_modify sort</span></a> option is turned on, which it is by default, to
improve performance. A sort value of <em>id</em> means sort the output by
atom ID. A sort value of N or -N means sort the output by the value
in the Nth column of per-atom info in either ascending or descending
order.</p>
<p>The dump <em>local</em> style cannot be sorted by atom ID, since there are
typically multiple lines of output per atom. Some dump styles, such
as <em>dcd</em> and <em>xtc</em>, require sorting by atom ID to format the output
file correctly. If multiple processors are writing the dump file, via
the “%” wildcard in the dump filename, then sorting cannot be
performed.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Unless it is required by the dump style, sorting dump file
output requires extra overhead in terms of CPU and communication cost,
as well as memory, versus unsorted output.</p>
</div>
<hr class="docutils" />
<p>The <em>thresh</em> keyword only applies to the dump <em>custom</em>, <em>cfg</em>,
<em>image</em>, and <em>movie</em> styles. Multiple thresholds can be specified.
Specifying “none” turns off all threshold criteria. If thresholds are
specified, only atoms whose attributes meet all the threshold criteria
are written to the dump file or included in the image. The possible
attributes that can be tested for are the same as those that can be
specified in the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command, with the exception
of the <em>element</em> attribute, since it is not a numeric value. Note
that different attributes can be output by the dump custom command
than are used as threshold criteria by the dump_modify command.
E.g. you can output the coordinates and stress of atoms whose energy
is above some threshold.</p>
<hr class="docutils" />
<p>The <em>unwrap</em> keyword only applies to the dump <em>dcd</em> and <em>xtc</em> styles.
If set to <em>yes</em>, coordinates will be written “unwrapped” by the image
flags for each atom. Unwrapped means that if the atom has passed thru
a periodic boundary one or more times, the value is printed for what
the coordinate would be if it had not been wrapped back into the
periodic box. Note that these coordinates may thus be far outside the
box size stored with the snapshot.</p>
<p>These keywords apply only to the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a> and
<a class="reference internal" href="dump_image.html"><span class="doc">dump movie</span></a> styles. Any keyword that affects an
image, also affects a movie, since the movie is simply a collection of
images. Some of the keywords only affect the <a class="reference internal" href="dump_image.html"><span class="doc">dump movie</span></a> style. The descriptions give details.</p>
<hr class="docutils" />
<p>The <em>acolor</em> keyword can be used with the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a>
command, when its atom color setting is <em>type</em>, to set the color that
atoms of each type will be drawn in the image.</p>
<p>The specified <em>type</em> should be an integer from 1 to Ntypes = the
number of atom types. A wildcard asterisk can be used in place of or
in conjunction with the <em>type</em> argument to specify a range of atom
-types. This takes the form “*” or “<em>n” or “n</em>” or “m*n”. If N = the
+types. This takes the form “*” or “*n” or “n*” or “m*n”. If N = the
number of atom types, then an asterisk with no numeric values means
all types from 1 to N. A leading asterisk means all types from 1 to n
(inclusive). A trailing asterisk means all types from n to N
(inclusive). A middle asterisk means all types from m to n
(inclusive).</p>
<p>The specified <em>color</em> can be a single color which is any of the 140
pre-defined colors (see below) or a color name defined by the
dump_modify color option. Or it can be two or more colors separated
by a “/” character, e.g. red/green/blue. In the former case, that
color is assigned to all the specified atom types. In the latter
case, the list of colors are assigned in a round-robin fashion to each
of the specified atom types.</p>
<hr class="docutils" />
<p>The <em>adiam</em> keyword can be used with the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a>
command, when its atom diameter setting is <em>type</em>, to set the size
that atoms of each type will be drawn in the image. The specified
<em>type</em> should be an integer from 1 to Ntypes. As with the <em>acolor</em>
keyword, a wildcard asterisk can be used as part of the <em>type</em>
argument to specify a range of atomt types. The specified <em>diam</em> is
the size in whatever distance <a class="reference internal" href="units.html"><span class="doc">units</span></a> the input script is
using, e.g. Angstroms.</p>
<hr class="docutils" />
<p>The <em>amap</em> keyword can be used with the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a>
command, with its <em>atom</em> keyword, when its atom setting is an
atom-attribute, to setup a color map. The color map is used to assign
a specific RGB (red/green/blue) color value to an individual atom when
it is drawn, based on the atom’s attribute, which is a numeric value,
e.g. its x-component of velocity if the atom-attribute “vx” was
specified.</p>
<p>The basic idea of a color map is that the atom-attribute will be
within a range of values, and that range is associated with a a series
of colors (e.g. red, blue, green). An atom’s specific value (vx =
-3.2) can then mapped to the series of colors (e.g. halfway between
red and blue), and a specific color is determined via an interpolation
procedure.</p>
<p>There are many possible options for the color map, enabled by the
<em>amap</em> keyword. Here are the details.</p>
<p>The <em>lo</em> and <em>hi</em> settings determine the range of values allowed for
the atom attribute. If numeric values are used for <em>lo</em> and/or <em>hi</em>,
then values that are lower/higher than that value are set to the
value. I.e. the range is static. If <em>lo</em> is specified as <em>min</em> or
<em>hi</em> as <em>max</em> then the range is dynamic, and the lower and/or
upper bound will be calculated each time an image is drawn, based
on the set of atoms being visualized.</p>
<p>The <em>style</em> setting is two letters, such as “ca”. The first letter is
either “c” for continuous, “d” for discrete, or “s” for sequential.
The second letter is either “a” for absolute, or “f” for fractional.</p>
<p>A continuous color map is one in which the color changes continuously
from value to value within the range. A discrete color map is one in
which discrete colors are assigned to sub-ranges of values within the
range. A sequential color map is one in which discrete colors are
assigned to a sequence of sub-ranges of values covering the entire
range.</p>
<p>An absolute color map is one in which the values to which colors are
assigned are specified explicitly as values within the range. A
fractional color map is one in which the values to which colors are
assigned are specified as a fractional portion of the range. For
example if the range is from -10.0 to 10.0, and the color red is to be
assigned to atoms with a value of 5.0, then for an absolute color map
the number 5.0 would be used. But for a fractional map, the number
0.75 would be used since 5.0 is 3/4 of the way from -10.0 to 10.0.</p>
<p>The <em>delta</em> setting must be specified for all styles, but is only used
for the sequential style; otherwise the value is ignored. It
specifies the bin size to use within the range for assigning
consecutive colors to. For example, if the range is from -10.0 to
10.0 and a <em>delta</em> of 1.0 is used, then 20 colors will be assigned to
the range. The first will be from -10.0 <= color1 < -9.0, then 2nd
from -9.0 <= color2 < -8.0, etc.</p>
<p>The <em>N</em> setting is how many entries follow. The format of the entries
depends on whether the color map style is continuous, discrete or
sequential. In all cases the <em>color</em> setting can be any of the 140
pre-defined colors (see below) or a color name defined by the
dump_modify color option.</p>
<p>For continuous color maps, each entry has a <em>value</em> and a <em>color</em>.
The <em>value</em> is either a number within the range of values or <em>min</em> or
<em>max</em>. The <em>value</em> of the first entry must be <em>min</em> and the <em>value</em>
of the last entry must be <em>max</em>. Any entries in between must have
increasing values. Note that numeric values can be specified either
as absolute numbers or as fractions (0.0 to 1.0) of the range,
depending on the “a” or “f” in the style setting for the color map.</p>
<p>Here is how the entries are used to determine the color of an
individual atom, given the value X of its atom attribute. X will fall
between 2 of the entry values. The color of the atom is linearly
interpolated (in each of the RGB values) between the 2 colors
associated with those entries. For example, if X = -5.0 and the 2
surrounding entries are “red” at -10.0 and “blue” at 0.0, then the
atom’s color will be halfway between “red” and “blue”, which happens
to be “purple”.</p>
<p>For discrete color maps, each entry has a <em>lo</em> and <em>hi</em> value and a
<em>color</em>. The <em>lo</em> and <em>hi</em> settings are either numbers within the
range of values or <em>lo</em> can be <em>min</em> or <em>hi</em> can be <em>max</em>. The <em>lo</em>
and <em>hi</em> settings of the last entry must be <em>min</em> and <em>max</em>. Other
entries can have any <em>lo</em> and <em>hi</em> values and the sub-ranges of
different values can overlap. Note that numeric <em>lo</em> and <em>hi</em> values
can be specified either as absolute numbers or as fractions (0.0 to
1.0) of the range, depending on the “a” or “f” in the style setting
for the color map.</p>
<p>Here is how the entries are used to determine the color of an
individual atom, given the value X of its atom attribute. The entries
are scanned from first to last. The first time that <em>lo</em> <= X <=
<em>hi</em>, X is assigned the color associated with that entry. You can
think of the last entry as assigning a default color (since it will
always be matched by X), and the earlier entries as colors that
override the default. Also note that no interpolation of a color RGB
is done. All atoms will be drawn with one of the colors in the list
of entries.</p>
<p>For sequential color maps, each entry has only a <em>color</em>. Here is how
the entries are used to determine the color of an individual atom,
given the value X of its atom attribute. The range is partitioned
into N bins of width <em>binsize</em>. Thus X will fall in a specific bin
from 1 to N, say the Mth bin. If it falls on a boundary between 2
bins, it is considered to be in the higher of the 2 bins. Each bin is
assigned a color from the E entries. If E < N, then the colors are
repeated. For example if 2 entries with colors red and green are
specified, then the odd numbered bins will be red and the even bins
green. The color of the atom is the color of its bin. Note that the
sequential color map is really a shorthand way of defining a discrete
color map without having to specify where all the bin boundaries are.</p>
<p>Here is an example of using a sequential color map to color all the
atoms in individual molecules with a different color. See the
examples/pour/in.pour.2d.molecule input script for an example of how
this is used.</p>
-<div class="highlight-default"><div class="highlight"><pre><span></span>variable colors string &
+<pre class="literal-block">
+variable colors string &
"red green blue yellow white &
purple pink orange lime gray"
variable mol atom mol%10
dump 1 all image 250 image.*.jpg v_mol type &
zoom 1.6 adiam 1.5
-dump_modify 1 pad 5 amap 0 10 sa 1 10 ${colors}
-</pre></div>
-</div>
+dump_modify 1 pad 5 amap 0 10 sa 1 10 ${colors}
+</pre>
<p>In this case, 10 colors are defined, and molecule IDs are
mapped to one of the colors, even if there are 1000s of molecules.</p>
<hr class="docutils" />
<p>The <em>backcolor</em> sets the background color of the images. The color
name can be any of the 140 pre-defined colors (see below) or a color
name defined by the dump_modify color option.</p>
<hr class="docutils" />
<p>The <em>bcolor</em> keyword can be used with the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a>
command, with its <em>bond</em> keyword, when its color setting is <em>type</em>, to
set the color that bonds of each type will be drawn in the image.</p>
<p>The specified <em>type</em> should be an integer from 1 to Nbondtypes = the
number of bond types. A wildcard asterisk can be used in place of or
in conjunction with the <em>type</em> argument to specify a range of bond
-types. This takes the form “*” or “<em>n” or “n</em>” or “m*n”. If N = the
+types. This takes the form “*” or “*n” or “n*” or “m*n”. If N = the
number of bond types, then an asterisk with no numeric values means
all types from 1 to N. A leading asterisk means all types from 1 to n
(inclusive). A trailing asterisk means all types from n to N
(inclusive). A middle asterisk means all types from m to n
(inclusive).</p>
<p>The specified <em>color</em> can be a single color which is any of the 140
pre-defined colors (see below) or a color name defined by the
dump_modify color option. Or it can be two or more colors separated
by a “/” character, e.g. red/green/blue. In the former case, that
color is assigned to all the specified bond types. In the latter
case, the list of colors are assigned in a round-robin fashion to each
of the specified bond types.</p>
<hr class="docutils" />
<p>The <em>bdiam</em> keyword can be used with the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a>
command, with its <em>bond</em> keyword, when its diam setting is <em>type</em>, to
set the diameter that bonds of each type will be drawn in the image.
The specified <em>type</em> should be an integer from 1 to Nbondtypes. As
with the <em>bcolor</em> keyword, a wildcard asterisk can be used as part of
the <em>type</em> argument to specify a range of bond types. The specified
<em>diam</em> is the size in whatever distance <a class="reference internal" href="units.html"><span class="doc">units</span></a> you are
using, e.g. Angstroms.</p>
<hr class="docutils" />
<p>The <em>bitrate</em> keyword can be used with the <a class="reference internal" href="dump_image.html"><span class="doc">dump movie</span></a> command to define the size of the resulting
movie file and its quality via setting how many kbits per second are
to be used for the movie file. Higher bitrates require less
compression and will result in higher quality movies. The quality is
also determined by the compression format and encoder. The default
setting is 2000 kbit/s, which will result in average quality with
older compression formats.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Not all movie file formats supported by dump movie allow the
bitrate to be set. If not, the setting is silently ignored.</p>
</div>
<hr class="docutils" />
<p>The <em>boxcolor</em> keyword sets the color of the simulation box drawn
around the atoms in each image as well as the color of processor
sub-domain boundaries. See the “dump image box” command for how to
specify that a box be drawn via the <em>box</em> keyword, and the sub-domain
boundaries via the <em>subbox</em> keyword. The color name can be any of the
140 pre-defined colors (see below) or a color name defined by the
dump_modify color option.</p>
<hr class="docutils" />
<p>The <em>color</em> keyword allows definition of a new color name, in addition
to the 140-predefined colors (see below), and associates 3
red/green/blue RGB values with that color name. The color name can
then be used with any other dump_modify keyword that takes a color
name as a value. The RGB values should each be floating point values
between 0.0 and 1.0 inclusive.</p>
<p>When a color name is converted to RGB values, the user-defined color
names are searched first, then the 140 pre-defined color names. This
means you can also use the <em>color</em> keyword to overwrite one of the
pre-defined color names with new RBG values.</p>
<hr class="docutils" />
<p>The <em>framerate</em> keyword can be used with the <a class="reference internal" href="dump_image.html"><span class="doc">dump movie</span></a> command to define the duration of the resulting
movie file. Movie files written by the dump <em>movie</em> command have a
default frame rate of 24 frames per second and the images generated
will be converted at that rate. Thus a sequence of 1000 dump images
will result in a movie of about 42 seconds. To make a movie run
longer you can either generate images more frequently or lower the
frame rate. To speed a movie up, you can do the inverse. Using a
frame rate higher than 24 is not recommended, as it will result in
simply dropping the rendered images. It is more efficient to dump
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Set a fix that will be applied to a group of atoms. In LAMMPS, a
“fix” is any operation that is applied to the system during
timestepping or minimization. Examples include updating of atom
positions and velocities due to time integration, controlling
temperature, applying constraint forces to atoms, enforcing boundary
conditions, computing diagnostics, etc. There are dozens of fixes
defined in LAMMPS and new ones can be added; see <a class="reference internal" href="Section_modify.html"><span class="doc">this section</span></a> for a discussion.</p>
<p>Fixes perform their operations at different stages of the timestep.
If 2 or more fixes operate at the same stage of the timestep, they are
invoked in the order they were specified in the input script.</p>
<p>The ID of a fix can only contain alphanumeric characters and
underscores.</p>
<p>Fixes can be deleted with the <a class="reference internal" href="unfix.html"><span class="doc">unfix</span></a> command.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The <a class="reference internal" href="unfix.html"><span class="doc">unfix</span></a> command is the only way to turn off a
fix; simply specifying a new fix with a similar style will not turn
off the first one. This is especially important to realize for
integration fixes. For example, using a <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a>
command for a second run after using a <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command
for the first run, will not cancel out the NVT time integration
invoked by the “fix nvt” command. Thus two time integrators would be
in place!</p>
</div>
<p>If you specify a new fix with the same ID and style as an existing
fix, the old fix is deleted and the new one is created (presumably
with new settings). This is the same as if an “unfix” command were
first performed on the old fix, except that the new fix is kept in the
same order relative to the existing fixes as the old one originally
was. Note that this operation also wipes out any additional changes
made to the old fix via the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix modify</span></a> command allows settings for some
fixes to be reset. See the doc page for individual fixes for details.</p>
<p>Some fixes store an internal “state” which is written to binary
restart files via the <a class="reference internal" href="restart.html"><span class="doc">restart</span></a> or
<a class="reference internal" href="write_restart.html"><span class="doc">write_restart</span></a> commands. This allows the fix to
continue on with its calculations in a restarted simulation. See the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for info on how to re-specify
a fix in an input script that reads a restart file. See the doc pages
for individual fixes for info on which ones can be restarted.</p>
<hr class="docutils" />
<p>Some fixes calculate one of three styles of quantities: global,
per-atom, or local, which can be used by other commands or output as
described below. A global quantity is one or more system-wide values,
e.g. the energy of a wall interacting with particles. A per-atom
quantity is one or more values per atom, e.g. the displacement vector
for each atom since time 0. Per-atom values are set to 0.0 for atoms
not in the specified fix group. Local quantities are calculated by
each processor based on the atoms it owns, but there may be zero or
more per atoms.</p>
<p>Note that a single fix may produces either global or per-atom or local
quantities (or none at all), but never more than one of these.</p>
<p>Global, per-atom, and local quantities each come in three kinds: a
single scalar value, a vector of values, or a 2d array of values. The
doc page for each fix describes the style and kind of values it
produces, e.g. a per-atom vector. Some fixes produce more than one
kind of a single style, e.g. a global scalar and a global vector.</p>
<p>When a fix quantity is accessed, as in many of the output commands
discussed below, it can be referenced via the following bracket
notation, where ID is the ID of the fix:</p>
<table border="1" class="docutils">
<colgroup>
-<col width="21%" />
-<col width="79%" />
+<col width="23%" />
+<col width="77%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>f_ID</td>
<td>entire scalar, vector, or array</td>
</tr>
<tr class="row-even"><td>f_ID[I]</td>
<td>one element of vector, one column of array</td>
</tr>
<tr class="row-odd"><td>f_ID[I][J]</td>
<td>one element of array</td>
</tr>
</tbody>
</table>
<p>In other words, using one bracket reduces the dimension of the
quantity once (vector -> scalar, array -> vector). Using two brackets
reduces the dimension twice (array -> scalar). Thus a command that
uses scalar fix values as input can also process elements of a vector
or array.</p>
<p>Note that commands and <a class="reference internal" href="variable.html"><span class="doc">variables</span></a> which use fix
quantities typically do not allow for all kinds, e.g. a command may
require a vector of values, not a scalar. This means there is no
ambiguity about referring to a fix quantity as f_ID even if it
produces, for example, both a scalar and vector. The doc pages for
various commands explain the details.</p>
<hr class="docutils" />
<p>In LAMMPS, the values generated by a fix can be used in several ways:</p>
<ul class="simple">
<li>Global values can be output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> or <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a> command.
Or the values can be referenced in a <a class="reference internal" href="variable.html"><span class="doc">variable equal</span></a> or
<li>Per-atom values can be output via the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command.
Or they can be time-averaged via the <a class="reference internal" href="fix_ave_atom.html"><span class="doc">fix ave/atom</span></a>
command or reduced by the <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a>
command. Or the per-atom values can be referenced in an <a class="reference internal" href="variable.html"><span class="doc">atom-style variable</span></a>.</li>
<li>Local values can be reduced by the <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a> command, or histogrammed by the <a class="reference internal" href="fix_ave_histo.html"><span class="doc">fix ave/histo</span></a> command.</li>
</ul>
<p>See this <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">howto section</span></a> for a summary of
various LAMMPS output options, many of which involve fixes.</p>
<p>The results of fixes that calculate global quantities can be either
“intensive” or “extensive” values. Intensive means the value is
independent of the number of atoms in the simulation,
e.g. temperature. Extensive means the value scales with the number of
atoms in the simulation, e.g. total rotational kinetic energy.
<a class="reference internal" href="thermo_style.html"><span class="doc">Thermodynamic output</span></a> will normalize extensive
values by the number of atoms in the system, depending on the
“thermo_modify norm” setting. It will not normalize intensive values.
If a fix value is accessed in another way, e.g. by a
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a>, you may want to know whether it is an
intensive or extensive value. See the doc page for individual fixes
for further info.</p>
<hr class="docutils" />
<p>Each fix style has its own documentation page which describes its
arguments and what it does, as listed below. Here is an alphabetic
list of fix styles available in LAMMPS. They are also given in more
compact form in the Fix section of <a class="reference internal" href="Section_commands.html#cmd-5"><span class="std std-ref">this page</span></a>.</p>
<p>There are also additional fix styles (not listed here) submitted by
users which are included in the LAMMPS distribution. The list of
these with links to the individual styles are given in the fix section
of <a class="reference internal" href="Section_commands.html#cmd-5"><span class="std std-ref">this page</span></a>.</p>
<ul class="simple">
<li><a class="reference internal" href="fix_adapt.html"><span class="doc">adapt</span></a> - change a simulation parameter over time</li>
<li><a class="reference internal" href="fix_addforce.html"><span class="doc">addforce</span></a> - add a force to each atom</li>
<li><a class="reference internal" href="fix_append_atoms.html"><span class="doc">append/atoms</span></a> - append atoms to a running simulation</li>
<li><a class="reference internal" href="fix_atom_swap.html"><span class="doc">atom/swap</span></a> - Monte Carlo atom type swapping</li>
<li><a class="reference internal" href="fix_aveforce.html"><span class="doc">aveforce</span></a> - add an averaged force to each atom</li>
<li><a class="reference internal" href="fix_indent.html"><span class="doc">indent</span></a> - impose force due to an indenter</li>
<li><a class="reference internal" href="fix_langevin.html"><span class="doc">langevin</span></a> - Langevin temperature control</li>
<li><a class="reference internal" href="fix_lineforce.html"><span class="doc">lineforce</span></a> - constrain atoms to move in a line</li>
<li><a class="reference internal" href="fix_momentum.html"><span class="doc">momentum</span></a> - zero the linear and/or angular momentum of a group of atoms</li>
<li><a class="reference internal" href="fix_move.html"><span class="doc">move</span></a> - move atoms in a prescribed fashion</li>
<li><a class="reference internal" href="fix_nve_line.html"><span class="doc">nve/line</span></a> - NVE for line segments</li>
<li><a class="reference internal" href="fix_nve_noforce.html"><span class="doc">nve/noforce</span></a> - NVE without forces (v only)</li>
<li><a class="reference internal" href="fix_nve_sphere.html"><span class="doc">nve/sphere</span></a> - NVE for spherical particles</li>
<li><a class="reference internal" href="fix_nve_tri.html"><span class="doc">nve/tri</span></a> - NVE for triangles</li>
<li><a class="reference internal" href="fix_nh.html"><span class="doc">nvt</span></a> - constant NVT time integration via Nose/Hoover</li>
<li><a class="reference internal" href="fix_nvt_asphere.html"><span class="doc">nvt/asphere</span></a> - NVT for aspherical particles</li>
<li><a class="reference internal" href="fix_nve_body.html"><span class="doc">nvt/body</span></a> - NVT for body particles</li>
<li><a class="reference internal" href="fix_nvt_sllod.html"><span class="doc">nvt/sllod</span></a> - NVT for NEMD with SLLOD equations</li>
<li><a class="reference internal" href="fix_nvt_sphere.html"><span class="doc">nvt/sphere</span></a> - NVT for spherical particles</li>
<li><a class="reference internal" href="fix_oneway.html"><span class="doc">oneway</span></a> - constrain particles on move in one direction</li>
<li><a class="reference internal" href="fix_orient.html"><span class="doc">orient/bcc</span></a> - add grain boundary migration force for BCC</li>
<li><a class="reference internal" href="fix_orient.html"><span class="doc">orient/fcc</span></a> - add grain boundary migration force for FCC</li>
<li><a class="reference internal" href="fix_planeforce.html"><span class="doc">planeforce</span></a> - constrain atoms to move in a plane</li>
<li><a class="reference internal" href="fix_poems.html"><span class="doc">poems</span></a> - constrain clusters of atoms to move as coupled rigid bodies</li>
<li><a class="reference internal" href="fix_pour.html"><span class="doc">pour</span></a> - pour new atoms/molecules into a granular simulation domain</li>
<li><a class="reference internal" href="fix_press_berendsen.html"><span class="doc">press/berendsen</span></a> - pressure control by Berendsen barostat</li>
<li><a class="reference internal" href="fix_print.html"><span class="doc">print</span></a> - print text and variables during a simulation</li>
<li><a class="reference internal" href="fix_qeq_comb.html"><span class="doc">qeq/comb</span></a> - charge equilibration for COMB potential <a class="reference internal" href="fix_qeq.html"><span class="doc">qeq/dynamic</span></a> - charge equilibration via dynamic method <a class="reference internal" href="fix_qeq.html"><span class="doc">qeq/fire</span></a> - charge equilibration via FIRE minimizer <a class="reference internal" href="fix_qeq.html"><span class="doc">qeq/point</span></a> - charge equilibration via point method <a class="reference internal" href="fix_qeq.html"><span class="doc">qeq/shielded</span></a> - charge equilibration via shielded method <a class="reference internal" href="fix_qeq.html"><span class="doc">qeq/slater</span></a> - charge equilibration via Slater method <a class="reference internal" href="fix_shake.html"><span class="doc">rattle</span></a> - RATTLE constraints on bonds and/or angles</li>
<li><a class="reference internal" href="fix_reax_bonds.html"><span class="doc">reax/bonds</span></a> - write out ReaxFF bond information <a class="reference internal" href="fix_recenter.html"><span class="doc">recenter</span></a> - constrain the center-of-mass position of a group of atoms</li>
<li><a class="reference internal" href="fix_rigid.html"><span class="doc">rigid</span></a> - constrain one or more clusters of atoms to move as a rigid body with NVE integration</li>
<li><a class="reference internal" href="fix_rigid.html"><span class="doc">rigid/nph</span></a> - constrain one or more clusters of atoms to move as a rigid body with NPH integration</li>
<li><a class="reference internal" href="fix_rigid.html"><span class="doc">rigid/npt</span></a> - constrain one or more clusters of atoms to move as a rigid body with NPT integration</li>
<li><a class="reference internal" href="fix_rigid.html"><span class="doc">rigid/nve</span></a> - constrain one or more clusters of atoms to move as a rigid body with alternate NVE integration</li>
<li><a class="reference internal" href="fix_rigid.html"><span class="doc">rigid/nvt</span></a> - constrain one or more clusters of atoms to move as a rigid body with NVT integration</li>
<li><a class="reference internal" href="fix_rigid.html"><span class="doc">rigid/small</span></a> - constrain many small clusters of atoms to move as a rigid body with NVE integration</li>
<li><a class="reference internal" href="fix_rigid.html"><span class="doc">rigid/small/nph</span></a> - constrain many small clusters of atoms to move as a rigid body with NPH integration</li>
<li><a class="reference internal" href="fix_rigid.html"><span class="doc">rigid/small/npt</span></a> - constrain many small clusters of atoms to move as a rigid body with NPT integration</li>
<li><a class="reference internal" href="fix_rigid.html"><span class="doc">rigid/small/nve</span></a> - constrain many small clusters of atoms to move as a rigid body with alternate NVE integration</li>
<li><a class="reference internal" href="fix_rigid.html"><span class="doc">rigid/small/nvt</span></a> - constrain many small clusters of atoms to move as a rigid body with NVT integration</li>
<li><a class="reference internal" href="fix_setforce.html"><span class="doc">setforce</span></a> - set the force on each atom</li>
<li><a class="reference internal" href="fix_spring.html"><span class="doc">spring</span></a> - apply harmonic spring force to group of atoms</li>
<li><a class="reference internal" href="fix_spring_chunk.html"><span class="doc">spring/chunk</span></a> - apply harmonic spring force to each chunk of atoms</li>
<li><a class="reference internal" href="fix_spring_rg.html"><span class="doc">spring/rg</span></a> - spring on radius of gyration of group of atoms</li>
<li><a class="reference internal" href="fix_spring_self.html"><span class="doc">spring/self</span></a> - spring from each atom to its origin</li>
<li><a class="reference internal" href="fix_store_force.html"><span class="doc">store/force</span></a> - store force on each atom</li>
<li><a class="reference internal" href="fix_store_state.html"><span class="doc">store/state</span></a> - store attributes for each atom</li>
<li><a class="reference internal" href="fix_temp_berendsen.html"><span class="doc">temp/berendsen</span></a> - temperature control by Berendsen thermostat</li>
<li><a class="reference internal" href="fix_temp_rescale.html"><span class="doc">temp/rescale</span></a> - temperature control by velocity rescaling</li>
<li><a class="reference internal" href="fix_tfmc.html"><span class="doc">tfmc</span></a> - perform force-bias Monte Carlo with time-stamped method</li>
<li><a class="reference internal" href="fix_thermal_conductivity.html"><span class="doc">thermal/conductivity</span></a> - Muller-Plathe kinetic energy exchange for thermal conductivity calculation</li>
<li><a class="reference internal" href="fix_tmd.html"><span class="doc">tmd</span></a> - guide a group of atoms to a new configuration</li>
<li><a class="reference internal" href="fix_ttm.html"><span class="doc">ttm</span></a> - two-temperature model for electronic/atomic coupling</li>
<p>Some fix styles are part of specific packages. They are only enabled
if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.
The doc pages for individual fixes tell if it is part of a package.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>If <em>N</em> is specified as 0, the specified attributes are only changed
once, before the simulation begins. This is all that is needed if the
associated variables are not time-dependent. If <em>N</em> > 0, then changes
are made every <em>N</em> steps during the simulation, presumably with a
variable that is time-dependent.</p>
<p>Depending on the value of the <em>reset</em> keyword, attributes changed by
this fix will or will not be reset back to their original values at
the end of a simulation. Even if <em>reset</em> is specified as <em>yes</em>, a
restart file written during a simulation will contain the modified
settings.</p>
<p>If the <em>scale</em> keyword is set to <em>no</em>, then the value the parameter is
set to will be whatever the variable generates. If the <em>scale</em>
keyword is set to <em>yes</em>, then the value of the altered parameter will
be the initial value of that parameter multiplied by whatever the
variable generates. I.e. the variable is now a “scale factor” applied
in (presumably) a time-varying fashion to the parameter. Internally,
the parameters themselves are actually altered; make sure you use the
<em>reset yes</em> option if you want the parameters to be restored to their
initial values after the run.</p>
<p>If the <em>after</em> keyword is set to <em>yes</em>, then the parameters are
changed one timestep after the multiple of N. In this manner, if a fix
such as “fix ave/time” is used to calculate averages at every N
timesteps, all the contributions to the average will be obtained with
the same values of the parameters.</p>
<hr class="docutils" />
<p>The <em>pair</em> keyword enables various parameters of potentials defined by
the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> command to be changed, if the pair
style supports it. Note that the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> and
<a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> commands must be used in the usual manner
to specify these parameters initially; the fix adapt command simply
overrides the parameters.</p>
<p>The <em>pstyle</em> argument is the name of the pair style. If <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid or hybrid/overlay</span></a> is used, <em>pstyle</em> should be
a sub-style name. For example, <em>pstyle</em> could be specified as “soft”
or “lubricate”. The <em>pparam</em> argument is the name of the parameter to
change. This is the current list of pair styles and parameters that
can be varied by this fix. See the doc pages for individual pair
styles and their energy formulas for the meaning of these parameters:</p>
<p class="last">It is easy to add new potentials and their parameters to this
list. All it typically takes is adding an extract() method to the
pair_*.cpp file associated with the potential.</p>
</div>
<p>Some parameters are global settings for the pair style, e.g. the
viscosity setting “mu” for <a class="reference internal" href="pair_lubricate.html"><span class="doc">pair_style lubricate</span></a>.
Other parameters apply to atom type pairs within the pair style,
e.g. the prefactor “a” for <a class="reference internal" href="pair_soft.html"><span class="doc">pair_style soft</span></a>.</p>
<p>Note that for many of the potentials, the parameter that can be varied
is effectively a prefactor on the entire energy expression for the
potential, e.g. the lj/cut epsilon. The parameters listed as “scale”
are exactly that, since the energy expression for the
<a class="reference internal" href="pair_coul.html"><span class="doc">coul/cut</span></a> potential (for example) has no labeled
prefactor in its formula. To apply an effective prefactor to some
potentials, multiple parameters need to be altered. For example, the
<a class="reference internal" href="pair_buck.html"><span class="doc">Buckingham potential</span></a> needs both the A and C terms
altered together. To scale the Buckingham potential, you should thus
list the pair style twice, once for A and once for C.</p>
<p>If a type pair parameter is specified, the <em>I</em> and <em>J</em> settings should
be specified to indicate which type pairs to apply it to. If a global
parameter is specified, the <em>I</em> and <em>J</em> settings still need to be
specified, but are ignored.</p>
<p>Similar to the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff command</span></a>, I and J can be
specified in one of two ways. Explicit numeric values can be used for
each, as in the 1st example above. I <= J is required. LAMMPS sets
the coefficients for the symmetric J,I interaction to the same values.</p>
<p>A wild-card asterisk can be used in place of or in conjunction with
the I,J arguments to set the coefficients for multiple pairs of atom
-types. This takes the form “*” or “<em>n” or “n</em>” or “m*n”. If N = the
+types. This takes the form “*” or “*n” or “n*” or “m*n”. If N = the
number of atom types, then an asterisk with no numeric values means
all types from 1 to N. A leading asterisk means all types from 1 to n
(inclusive). A trailing asterisk means all types from n to N
(inclusive). A middle asterisk means all types from m to n
(inclusive). Note that only type pairs with I <= J are considered; if
asterisks imply type pairs where J < I, they are ignored.</p>
<p>IMPROTANT NOTE: If <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid or hybrid/overlay</span></a> is being used, then the <em>pstyle</em> will
be a sub-style name. You must specify I,J arguments that correspond
to type pair values defined (via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a>
command) for that sub-style.</p>
<p>The <em>v_name</em> argument for keyword <em>pair</em> is the name of an
<a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> which will be evaluated each time
this fix is invoked to set the parameter to a new value. It should be
specified as v_name, where name is the variable name. Equal-style
variables can specify formulas with various mathematical functions,
and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command keywords for the
simulation box parameters and timestep and elapsed time. Thus it is
easy to specify parameters that change as a function of time or span
consecutive runs in a continuous fashion. For the latter, see the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command and the
<em>elaplong</em> keyword of <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> for
details.</p>
<p>For example, these commands would change the prefactor coefficient of
the <a class="reference internal" href="pair_soft.html"><span class="doc">pair_style soft</span></a> potential from 10.0 to 30.0 in a
linear fashion over the course of a simulation:</p>
<p>The <em>kspace</em> keyword used the specified variable as a scale factor on
the energy, forces, virial calculated by whatever K-Space solver is
defined by the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command. If the
variable has a value of 1.0, then the solver is unaltered.</p>
<p>The <em>kspace</em> keyword works this way whether the <em>scale</em> keyword
is set to <em>no</em> or <em>yes</em>.</p>
<hr class="docutils" />
<p>The <em>atom</em> keyword enables various atom properties to be changed. The
<em>aparam</em> argument is the name of the parameter to change. This is the
current list of atom parameters that can be varied by this fix:</p>
<ul class="simple">
<li>charge = charge on particle</li>
<li>diameter = diameter of particle</li>
</ul>
<p>The <em>I</em> argument indicates which atom types are affected. A wild-card
asterisk can be used in place of or in conjunction with the I argument
to set the coefficients for multiple atom types.</p>
<p>The <em>v_name</em> argument of the <em>atom</em> keyword is the name of an
<a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> which will be evaluated each time
this fix is invoked to set the parameter to a new value. It should be
specified as v_name, where name is the variable name. See the
discussion above describing the formulas associated with equal-style
variables. The new value is assigned to the corresponding attribute
for all atoms in the fix group.</p>
<p>If the atom parameter is <em>diameter</em> and per-atom density and per-atom
mass are defined for particles (e.g. <a class="reference internal" href="atom_style.html"><span class="doc">atom_style granular</span></a>), then the mass of each particle is also
changed when the diameter changes (density is assumed to stay
constant).</p>
<p>For example, these commands would shrink the diameter of all granular
particles in the “center” group from 1.0 to 0.1 in a linear fashion
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the potential “energy” inferred by the added forces to the
system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>. This is a fictitious quantity but is
needed so that the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command can include the
forces added by this fix in a consistent manner. I.e. there is a
decrease in potential energy when atoms move in the direction of the
added forces.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>respa</em> option is supported by
this fix. This allows to set at which level of the <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA</span></a>
integrator the fix is adding its torque. Default is the outermost level.</p>
<p>This fix computes a global scalar and a global 3-vector, which can be
accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>.
The scalar is the potential energy discussed above. The vector is the
total torque on the group of atoms before the forces on individual
atoms are changed by the fix. The scalar and vector values calculated
by this fix are “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>The forces due to this fix are imposed during an energy minimization,
invoked by the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command. You should not
specify force components with a variable that has time-dependence for
use with a minimizer, since the minimizer increments the timestep as
the iteration count during the minimization.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-MISC package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This fix is the beginning to creating a coupled FE/MD simulation and/or an on-the-fly estimation of continuum fields. The coupled versions of this fix do Verlet integration and the post-processing does not. After instantiating this fix, several other fix_modify commands will be needed to set up the problem, e.g. define the finite element mesh and prescribe initial and boundary conditions.</p>
<span class="c1"># ... commands to create and initialize the MD system</span>
</pre></div>
</div>
-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># initial fix to designate coupling type and group to apply it to</span>
-<span class="c1"># tag group physics material_file</span>
-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># create a uniform 12 x 2 x 2 mesh that covers region contain the group</span>
-<span class="c1"># nx ny nz region periodicity</span>
-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># specify the initial values for the empirical field "temperature"</span>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># ... commands to create and initialize the MD system</span>
</pre></div>
</div>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># initial fix to designate post-processing and the group to apply it to</span>
<span class="c1"># no material file is allowed nor required</span>
-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># for hardy fix, specific kernel function (function type and range) to # be used as a localization function</span>
-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># create a uniform 1 x 1 x 1 mesh that covers region contain the group</span>
-<span class="c1"># with periodicity this effectively creats a system average</span>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options relevant to this fix are listed below. No global scalar or vector or per-atom quantities are stored by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>Thermal and two_temperature (coupling) types use a Verlet time-integration algorithm. The hardy type does not contain its own time-integrator and must be used with a separate fix that does contain one, e.g. nve, nvt, etc.</p>
<ul class="simple">
<li>Currently,</li>
<li><ul class="first">
<li>the coupling is restricted to thermal physics</li>
</ul>
</li>
<li><ul class="first">
<li>the FE computations are done in serial on each processor.</li>
</ul>
</li>
</ul>
</div>
<div class="section" id="related-commands">
<h2>Related commands</h2>
<p>After specifying this fix in your input script, several other <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> commands are used to setup the problem, e.g. define the finite element mesh and prescribe initial and boundary conditions.</p>
<p>Note: a set of example input files with the attendant material files are included with this package</p>
</div>
<div class="section" id="default">
<h2>Default</h2>
<p>None</p>
<hr class="docutils" />
<p>For detailed exposition of the theory and algorithms please see:</p>
<p id="wagner"><strong>(Wagner)</strong> Wagner, GJ; Jones, RE; Templeton, JA; Parks, MA, “An atomistic-to-continuum coupling method for heat transfer in solids.” Special Issue of Computer Methods and Applied Mechanics (2008) 197:3351.</p>
<p id="zimmeman2004"><strong>(Zimmerman2004)</strong> Zimmerman, JA; Webb, EB; Hoyt, JJ;. Jones, RE; Klein, PA; Bammann, DJ, “Calculation of stress in atomistic simulation.” Special Issue of Modelling and Simulation in Materials Science and Engineering (2004), 12:S319.</p>
<p id="zimmerman2010"><strong>(Zimmerman2010)</strong> Zimmerman, JA; Jones, RE; Templeton, JA, “A material frame approach for evaluating continuum variables in atomistic simulations.” Journal of Computational Physics (2010), 229:2364.</p>
<p id="templeton2010"><strong>(Templeton2010)</strong> Templeton, JA; Jones, RE; Wagner, GJ, “Application of a field-based method to spatially varying thermal transport problems in molecular dynamics.” Modelling and Simulation in Materials Science and Engineering (2010), 18:085007.</p>
<p id="jones"><strong>(Jones)</strong> Jones, RE; Templeton, JA; Wagner, GJ; Olmsted, D; Modine, JA, “Electron transport enhanced molecular dynamics for metals and semi-metals.” International Journal for Numerical Methods in Engineering (2010), 83:940.</p>
<p id="templeton2011"><strong>(Templeton2011)</strong> Templeton, JA; Jones, RE; Lee, JW; Zimmerman, JA; Wong, BM, “A long-range electric field solver for molecular dynamics based on atomistic-to-continuum modeling.” Journal of Chemical Theory and Computation (2011), 7:1736.</p>
<p id="mandadapu"><strong>(Mandadapu)</strong> Mandadapu, KK; Templeton, JA; Lee, JW, “Polarization as a field variable from molecular dynamics simulations.” Journal of Chemical Physics (2013), 139:054115.</p>
<p>Please refer to the standard finite element (FE) texts, e.g. T.J.R Hughes ” The finite element method ”, Dover 2003, for the basics of FE simulation.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the state of the fix to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. This includes information about the random
number generator seed, the next timestep for MC exchanges, etc. See
the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for info on how to
re-specify a fix in an input script that reads a restart file, so that
the operation of the fix continues in an uninterrupted fashion.</p>
<p>None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options are relevant to this
fix.</p>
<p>This fix computes a global vector of length 2, which can be accessed
by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The vector
values are the following global cumulative quantities:</p>
<ul class="simple">
<li>1 = swap attempts</li>
<li>2 = swap successes</li>
</ul>
<p>The vector values calculated by this fix are “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the MC package. It is only enabled if LAMMPS was
built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Use one or more per-atom vectors as inputs every few timesteps, and
average them atom by atom over longer timescales. The resulting
per-atom averages can be used by other <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a> such as the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> or <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> commands.</p>
<p>The group specified with the command means only atoms within the group
have their averages computed. Results are set to 0.0 for atoms not in
the group.</p>
<p>Each input value can be an atom attribute (position, velocity, force
component) or can be the result of a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> or
<a class="reference internal" href="fix.html"><span class="doc">fix</span></a> or the evaluation of an atom-style
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a>. In the latter cases, the compute, fix, or
variable must produce a per-atom vector, not a global quantity or
local quantity. If you wish to time-average global quantities from a
compute, fix, or variable, then see the <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a> command.</p>
<p>Each per-atom value of each input vector is averaged independently.</p>
<p><a class="reference internal" href="compute.html"><span class="doc">Computes</span></a> that produce per-atom vectors or arrays are
those which have the word <em>atom</em> in their style name. See the doc
pages for individual <a class="reference internal" href="fix.html"><span class="doc">fixes</span></a> to determine which ones produce
per-atom vectors or arrays. <a class="reference internal" href="variable.html"><span class="doc">Variables</span></a> of style <em>atom</em>
are the only ones that can be used with this fix since they produce
per-atom vectors.</p>
<p>Note that for values from a compute or fix, the bracketed index I can
be specified using a wildcard asterisk with the index to effectively
-specify multiple values. This takes the form “*” or “<em>n” or “n</em>” or
+specify multiple values. This takes the form “*” or “*n” or “n*” or
“m*n”. If N = the size of the vector (for <em>mode</em> = scalar) or the
number of columns in the array (for <em>mode</em> = vector), then an asterisk
with no numeric values means all indices from 1 to N. A leading
asterisk means all indices from 1 to n (inclusive). A trailing
asterisk means all indices from n to N (inclusive). A middle asterisk
means all indices from m to n (inclusive).</p>
<p>Using a wildcard is the same as if the individual columns of the array
had been listed one by one. E.g. these 2 fix ave/atom commands are
equivalent, since the <a class="reference internal" href="compute_stress_atom.html"><span class="doc">compute stress/atom</span></a>
command creates a per-atom array with 6 columns:</p>
+fix 1 all ave/atom 10 20 1000 c_my_stress[1] c_my_stress[1] &
+ c_my_stress[3] c_my_stress[4] &
+ c_my_stress[5] c_my_stress[6]
+</pre>
<hr class="docutils" />
<p>The <em>Nevery</em>, <em>Nrepeat</em>, and <em>Nfreq</em> arguments specify on what
timesteps the input values will be used in order to contribute to the
average. The final averaged quantities are generated on timesteps
that are a multiple of <em>Nfreq</em>. The average is over <em>Nrepeat</em>
quantities, computed in the preceding portion of the simulation every
<em>Nevery</em> timesteps. <em>Nfreq</em> must be a multiple of <em>Nevery</em> and
<em>Nevery</em> must be non-zero even if <em>Nrepeat</em> is 1. Also, the timesteps
contributing to the average value cannot overlap,
i.e. Nrepeat*Nevery can not exceed Nfreq.</p>
<p>For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then values on
timesteps 90,92,94,96,98,100 will be used to compute the final average
on timestep 100. Similarly for timesteps 190,192,194,196,198,200 on
timestep 200, etc.</p>
<hr class="docutils" />
<p>The atom attribute values (x,y,z,vx,vy,vz,fx,fy,fz) are
self-explanatory. Note that other atom attributes can be used as
inputs to this fix by using the <a class="reference internal" href="compute_property_atom.html"><span class="doc">compute property/atom</span></a> command and then specifying
an input value from that compute.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The x,y,z attributes are values that are re-wrapped inside the
periodic box whenever an atom crosses a periodic boundary. Thus if
you time average an atom that spends half its time on either side of
the periodic box, you will get a value in the middle of the box. If
this is not what you want, consider averaging unwrapped coordinates,
which can be provided by the <a class="reference internal" href="compute_property_atom.html"><span class="doc">compute property/atom</span></a> command via its xu,yu,zu
attributes.</p>
</div>
-<p>If a value begins with “<a href="#id1"><span class="problematic" id="id2">c_</span></a>”, a compute ID must follow which has been
+<p>If a value begins with “c_”, a compute ID must follow which has been
previously defined in the input script. If no bracketed term is
appended, the per-atom vector calculated by the compute is used. If a
bracketed term containing an index I is appended, the Ith column of
the per-atom array calculated by the compute is used. Users can also
write code for their own compute styles and <a class="reference internal" href="Section_modify.html"><span class="doc">add them to LAMMPS</span></a>. See the discussion above for how I can
be specified with a wildcard asterisk to effectively specify multiple
values.</p>
-<p>If a value begins with “<a href="#id3"><span class="problematic" id="id4">f_</span></a>”, a fix ID must follow which has been
+<p>If a value begins with “f_”, a fix ID must follow which has been
previously defined in the input script. If no bracketed term is
appended, the per-atom vector calculated by the fix is used. If a
bracketed term containing an index I is appended, the Ith column of
the per-atom array calculated by the fix is used. Note that some
fixes only produce their values on certain timesteps, which must be
compatible with <em>Nevery</em>, else an error will result. Users can also
write code for their own fix styles and <a class="reference internal" href="Section_modify.html"><span class="doc">add them to LAMMPS</span></a>. See the discussion above for how I can
be specified with a wildcard asterisk to effectively specify multiple
values.</p>
-<p>If a value begins with “<a href="#id5"><span class="problematic" id="id6">v_</span></a>”, a variable name must follow which has
+<p>If a value begins with “v_”, a variable name must follow which has
been previously defined in the input script as an <a class="reference internal" href="variable.html"><span class="doc">atom-style variable</span></a> Variables of style <em>atom</em> can reference
thermodynamic keywords, or invoke other computes, fixes, or variables
when they are evaluated, so this is a very general means of generating
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global scalar or vector quantities are
stored by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>.</p>
<p>This fix produces a per-atom vector or array which can be accessed by
various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. A vector is
produced if only a single quantity is averaged by this fix. If two or
more quantities are averaged, then an array of values is produced.
The per-atom values can only be accessed on timesteps that are
multiples of <em>Nfreq</em> since that is when averaging is performed.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+vx,vy,vz,fx,fy,fz = atom attribute (velocity, force component)
+density/number, density/mass = number or mass density
+temp = temperature
+c_ID = per-atom vector calculated by a compute with ID
+c_ID[I] = Ith column of per-atom array calculated by a compute with ID, I can include wildcard (see below)
+f_ID = per-atom vector calculated by a fix with ID
+f_ID[I] = Ith column of per-atom array calculated by a fix with ID, I can include wildcard (see below)
+v_name = per-atom vector calculated by an atom-style variable with name
+</pre>
<ul class="simple">
<li>zero or more keyword/arg pairs may be appended</li>
<li>keyword = <em>norm</em> or <em>ave</em> or <em>bias</em> or <em>adof</em> or <em>cdof</em> or <em>file</em> or <em>overwrite</em> or <em>title1</em> or <em>title2</em> or <em>title3</em></li>
</ul>
<pre class="literal-block">
<em>norm</em> arg = <em>all</em> or <em>sample</em> or <em>none</em> = how output on <em>Nfreq</em> steps is normalized
all = output is sum of atoms across all <em>Nrepeat</em> samples, divided by atom count
sample = output is sum of <em>Nrepeat</em> sample averages, divided by <em>Nrepeat</em>
none = output is sum of <em>Nrepeat</em> sample sums, divided by <em>Nrepeat</em>
<em>ave</em> args = <em>one</em> or <em>running</em> or <em>window M</em>
one = output new average value every Nfreq steps
running = output cumulative average of all previous Nfreq steps
window M = output average of M most recent Nfreq steps
<em>bias</em> arg = bias-ID
bias-ID = ID of a temperature compute that removes a velocity bias for temperature calculation
<em>adof</em> value = dof_per_atom
dof_per_atom = define this many degrees-of-freedom per atom for temperature calculation
<em>cdof</em> value = dof_per_chunk
dof_per_chunk = define this many degrees-of-freedom per chunk for temperature calculation
<em>file</em> arg = filename
filename = file to write results to
<em>overwrite</em> arg = none = overwrite output file with only latest output
<p>If you are trying to replace a deprectated fix ave/spatial command
with the newer, more flexible fix ave/chunk and <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> commands, you simply need to split
the fix ave/spatial arguments across the two new commands. For
<p>Use one or more per-atom vectors as inputs every few timesteps, sum
the values over the atoms in each chunk at each timestep, then average
the per-chunk values over longer timescales. The resulting chunk
averages can be used by other <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a> such as <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a>, and can also be written to a file.</p>
<p>In LAMMPS, chunks are collections of atoms defined by a <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> doc page and “<a class="reference internal" href="Section_howto.html#howto-23"><span class="std std-ref">Section_howto 23</span></a> for details of how chunks can be
defined and examples of how they can be used to measure properties of
a system.</p>
<p>Note that only atoms in the specified group contribute to the summing
and averaging calculations. The <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command defines its own group as
well as an optional region. Atoms will have a chunk ID = 0, meaning
they belong to no chunk, if they are not in that group or region.
Thus you can specify the “all” group for this command if you simply
want to use the chunk definitions provided by chunkID.</p>
<p>Each specified per-atom value can be an atom attribute (position,
velocity, force component), a mass or number density, or the result of
a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> or <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> or the evaluation of an
atom-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>. In the latter cases, the
compute, fix, or variable must produce a per-atom quantity, not a
global quantity. Note that the <a class="reference internal" href="compute_property_atom.html"><span class="doc">compute property/atom</span></a> command provides access to
any attribute defined and stored by atoms. If you wish to
time-average global quantities from a compute, fix, or variable, then
see the <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a> command.</p>
<p>The per-atom values of each input vector are summed and averaged
independently of the per-atom values in other input vectors.</p>
<p><a class="reference internal" href="compute.html"><span class="doc">Computes</span></a> that produce per-atom quantities are those
which have the word <em>atom</em> in their style name. See the doc pages for
individual <a class="reference internal" href="fix.html"><span class="doc">fixes</span></a> to determine which ones produce per-atom
quantities. <a class="reference internal" href="variable.html"><span class="doc">Variables</span></a> of style <em>atom</em> are the only
ones that can be used with this fix since all other styles of variable
produce global quantities.</p>
<p>Note that for values from a compute or fix, the bracketed index I can
be specified using a wildcard asterisk with the index to effectively
-specify multiple values. This takes the form “*” or “<em>n” or “n</em>” or
+specify multiple values. This takes the form “*” or “*n” or “n*” or
“m*n”. If N = the size of the vector (for <em>mode</em> = scalar) or the
number of columns in the array (for <em>mode</em> = vector), then an asterisk
with no numeric values means all indices from 1 to N. A leading
asterisk means all indices from 1 to n (inclusive). A trailing
asterisk means all indices from n to N (inclusive). A middle asterisk
means all indices from m to n (inclusive).</p>
<p>Using a wildcard is the same as if the individual columns of the array
had been listed one by one. E.g. these 2 fix ave/chunk commands are
equivalent, since the <a class="reference internal" href="compute_property_atom.html"><span class="doc">compute property/atom</span></a> command creates, in this
<p class="last">This fix works by creating an array of size <em>Nchunk</em> by Nvalues
on each processor. <em>Nchunk</em> is the number of chunks which is defined
by the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command.
Nvalues is the number of input values specified. Each processor loops
over its atoms, tallying its values to the appropriate chunk. Then
the entire array is summed across all processors. This means that
using a large number of chunks will incur an overhead in memory and
computational cost (summing across processors), so be careful to
define a reasonable number of chunks.</p>
</div>
<hr class="docutils" />
<p>The <em>Nevery</em>, <em>Nrepeat</em>, and <em>Nfreq</em> arguments specify on what
timesteps the input values will be accessed and contribute to the
average. The final averaged quantities are generated on timesteps
that are a multiples of <em>Nfreq</em>. The average is over <em>Nrepeat</em>
quantities, computed in the preceding portion of the simulation every
<em>Nevery</em> timesteps. <em>Nfreq</em> must be a multiple of <em>Nevery</em> and
<em>Nevery</em> must be non-zero even if <em>Nrepeat</em> is 1. Also, the timesteps
contributing to the average value cannot overlap, i.e. Nrepeat*Nevery
can not exceed Nfreq.</p>
<p>For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then values on
timesteps 90,92,94,96,98,100 will be used to compute the final average
on timestep 100. Similarly for timesteps 190,192,194,196,198,200 on
timestep 200, etc. If Nrepeat=1 and Nfreq = 100, then no time
averaging is done; values are simply generated on timesteps
100,200,etc.</p>
<p>Each input value can also be averaged over the atoms in each chunk.
The way the averaging is done across the <em>Nrepeat</em> timesteps to
produce output on the <em>Nfreq</em> timesteps, and across multiple <em>Nfreq</em>
outputs, is determined by the <em>norm</em> and <em>ave</em> keyword settings, as
discussed below.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">To perform per-chunk averaging within a <em>Nfreq</em> time window, the
number of chunks <em>Nchunk</em> defined by the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command must remain constant. If
the <em>ave</em> keyword is set to <em>running</em> or <em>window</em> then <em>Nchunk</em> must
remain constant for the duration of the simulation. This fix forces
the chunk/atom compute specified by chunkID to hold <em>Nchunk</em> constant
for the appropriate time windows, by not allowing it to re-calcualte
<em>Nchunk</em>, which can also affect how it assigns chunk IDs to atoms.
More details are given on the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> doc page.</p>
</div>
<hr class="docutils" />
<p>The atom attribute values (vx,vy,vz,fx,fy,fz) are self-explanatory.
As noted above, any other atom attributes can be used as input values
to this fix by using the <a class="reference internal" href="compute_property_atom.html"><span class="doc">compute property/atom</span></a> command and then specifying
an input value from that compute.</p>
<p>The <em>density/number</em> value means the number density is computed for
each chunk, i.e. number/volume. The <em>density/mass</em> value means the
mass density is computed for each chunk, i.e. total-mass/volume. The
output values are in units of 1/volume or density (mass/volume). See
the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command doc page for the definition of density
for each choice of units, e.g. gram/cm^3. If the chunks defined by
the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command are spatial
bins, the volume is the bin volume. Otherwise it is the volume of the
entire simulation box.</p>
<p>The <em>temp</em> value means the temperature is computed for each chunk, by
the formula KE = DOF/2 k T, where KE = total kinetic energy of the
chunk of atoms (sum of 1/2 m v^2), DOF = the total number of degrees
of freedom for all atoms in the chunk, k = Boltzmann constant, and T =
temperature.</p>
<p>The DOF is calculated as N*adof + cdof, where N = number of atoms in
the chunk, adof = degrees of freedom per atom, and cdof = degrees of
freedom per chunk. By default adof = 2 or 3 = dimensionality of
system, as set via the <a class="reference internal" href="dimension.html"><span class="doc">dimension</span></a> command, and cdof =
0.0. This gives the usual formula for temperature.</p>
<p>Note that currently this temperature only includes translational
degrees of freedom for each atom. No rotational degrees of freedom
are included for finite-size particles. Also no degrees of freedom
are subtracted for any velocity bias or constraints that are applied,
such as <a class="reference internal" href="compute_temp_partial.html"><span class="doc">compute temp/partial</span></a>, or <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> or <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a>. This is because
those degrees of freedom (e.g. a constrained bond) could apply to sets
of atoms that are both included and excluded from a specific chunk,
and hence the concept is somewhat ill-defined. In some cases, you can
use the <em>adof</em> and <em>cdof</em> keywords to adjust the calculated degress of
freedom appropriately, as explained below.</p>
<p>Also note that a bias can be subtracted from atom velocities before
they are used in the above formula for KE, by using the <em>bias</em>
keyword. This allows, for example, a thermal temperature to be
computed after removal of a flow velocity profile.</p>
<p>Note that the per-chunk temperature calculated by this fix and the
<a class="reference internal" href="compute_temp_chunk.html"><span class="doc">compute temp/chunk</span></a> command can be different.
The compute calculates the temperature for each chunk for a single
snapshot. This fix can do that but can also time average those values
over many snapshots, or it can compute a temperature as if the atoms
in the chunk on different timesteps were collected together as one set
of atoms to calculate their temperature. The compute allows the
center-of-mass velocity of each chunk to be subtracted before
calculating the temperature; this fix does not.</p>
-<p>If a value begins with “<a href="#id1"><span class="problematic" id="id2">c_</span></a>”, a compute ID must follow which has been
+<p>If a value begins with “c_”, a compute ID must follow which has been
previously defined in the input script. If no bracketed integer is
appended, the per-atom vector calculated by the compute is used. If a
bracketed integer is appended, the Ith column of the per-atom array
calculated by the compute is used. Users can also write code for
their own compute styles and <a class="reference internal" href="Section_modify.html"><span class="doc">add them to LAMMPS</span></a>.
See the discussion above for how I can be specified with a wildcard
asterisk to effectively specify multiple values.</p>
-<p>If a value begins with “<a href="#id3"><span class="problematic" id="id4">f_</span></a>”, a fix ID must follow which has been
+<p>If a value begins with “f_”, a fix ID must follow which has been
previously defined in the input script. If no bracketed integer is
appended, the per-atom vector calculated by the fix is used. If a
bracketed integer is appended, the Ith column of the per-atom array
calculated by the fix is used. Note that some fixes only produce
their values on certain timesteps, which must be compatible with
<em>Nevery</em>, else an error results. Users can also write code for their
own fix styles and <a class="reference internal" href="Section_modify.html"><span class="doc">add them to LAMMPS</span></a>. See the
discussion above for how I can be specified with a wildcard asterisk
to effectively specify multiple values.</p>
-<p>If a value begins with “<a href="#id5"><span class="problematic" id="id6">v_</span></a>”, a variable name must follow which has
+<p>If a value begins with “v_”, a variable name must follow which has
been previously defined in the input script. Variables of style
<em>atom</em> can reference thermodynamic keywords and various per-atom
attributes, or invoke other computes, fixes, or variables when they
are evaluated, so this is a very general means of generating per-atom
quantities to average within chunks.</p>
<hr class="docutils" />
<p>Additional optional keywords also affect the operation of this fix
and its outputs.</p>
<p>The <em>norm</em> keyword affects how averaging is done for the per-chunk
values that are output every <em>Nfreq</em> timesteps.</p>
<p>It the <em>norm</em> setting is <em>all</em>, which is the default, a chunk value is
summed over all atoms in all <em>Nrepeat</em> samples, as is the count of
atoms in the chunk. The averaged output value for the chunk on the
<em>Nfreq</em> timesteps is Total-sum / Total-count. In other words it is an
average over atoms across the entire <em>Nfreq</em> timescale.</p>
<p>If the <em>norm</em> setting is <em>sample</em>, the chunk value is summed over atoms
for each sample, as is the count, and an “average sample value” is
computed for each sample, i.e. Sample-sum / Sample-count. The output
value for the chunk on the <em>Nfreq</em> timesteps is the average of the
<em>Nrepeat</em> “average sample values”, i.e. the sum of <em>Nrepeat</em> “average
sample values” divided by <em>Nrepeat</em>. In other words it is an average
of an average.</p>
<p>If the <em>norm</em> setting is <em>none</em>, a similar computation as for the
<em>sample</em> seting is done, except the individual “average sample values”
are “summed sample values”. A summed sample value is simply the chunk
value summed over atoms in the sample, without dividing by the number
of atoms in the sample. The output value for the chunk on the
<em>Nfreq</em> timesteps is the average of the <em>Nrepeat</em> “summed sample
values”, i.e. the sum of <em>Nrepeat</em> “summed sample values” divided by
<em>Nrepeat</em>.</p>
<p>The <em>ave</em> keyword determines how the per-chunk values produced every
<em>Nfreq</em> steps are averaged with values produced on previous steps that
were multiples of <em>Nfreq</em>, before they are accessed by another output
command or written to a file.</p>
<p>If the <em>ave</em> setting is <em>one</em>, which is the default, then the chunk
values produced on timesteps that are multiples of <em>Nfreq</em> are
independent of each other; they are output as-is without further
averaging.</p>
<p>If the <em>ave</em> setting is <em>running</em>, then the chunk values produced on
timesteps that are multiples of <em>Nfreq</em> are summed and averaged in a
cumulative sense before being output. Each output chunk value is thus
the average of the chunk value produced on that timestep with all
preceding values for the same chunk. This running average begins when
the fix is defined; it can only be restarted by deleting the fix via
the <a class="reference internal" href="unfix.html"><span class="doc">unfix</span></a> command, or re-defining the fix by
re-specifying it.</p>
<p>If the <em>ave</em> setting is <em>window</em>, then the chunk values produced on
timesteps that are multiples of <em>Nfreq</em> are summed and averaged within
a moving “window” of time, so that the last M values for the same
chunk are used to produce the output. E.g. if M = 3 and Nfreq = 1000,
then the output on step 10000 will be the average of the individual
chunk values on steps 8000,9000,10000. Outputs on early steps will
average over less than M values if they are not available.</p>
<p>The <em>bias</em> keyword specifies the ID of a temperature compute that
removes a “bias” velocity from each atom, specified as <em>bias-ID</em>. It
is only used when the <em>temp</em> value is calculated, to compute the
thermal temperature of each chunk after the translational kinetic
energy components have been altered in a prescribed way, e.g. to
remove a flow velocity profile. See the doc pages for individual
computes that calculate a temperature to see which ones implement a
bias.</p>
<p>The <em>adof</em> and <em>cdof</em> keywords define the values used in the degree of
freedom (DOF) formula described above for for temperature calculation
for each chunk. They are only used when the <em>temp</em> value is
calculated. They can be used to calculate a more appropriate
temperature for some kinds of chunks. Here are 3 examples:</p>
<p>If spatially binned chunks contain some number of water molecules and
<a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> is used to make each molecule rigid, then
you could calculate a temperature with 6 degrees of freedom (DOF) (3
translational, 3 rotational) per molecule by setting <em>adof</em> to 2.0.</p>
<p>If <a class="reference internal" href="compute_temp_partial.html"><span class="doc">compute temp/partial</span></a> is used with the
<em>bias</em> keyword to only allow the x component of velocity to contribute
to the temperature, then <em>adof</em> = 1.0 would be appropriate.</p>
<p>If each chunk consists of a large molecule, with some number of its
bonds constrained by <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> or the entire molecule
by <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid/small</span></a>, <em>adof</em> = 0.0 and <em>cdof</em> could be
set to the remaining degrees of freedom for the entire molecule
(entire chunk in this case), e.g. 6 for 3d, or 3 for 2d, for a rigid
molecule.</p>
<p>The <em>file</em> keyword allows a filename to be specified. Every <em>Nfreq</em>
timesteps, a section of chunk info will be written to a text file in
the following format. A line with the timestep and number of chunks
is written. Then one line per chunk is written, containing the chunk
ID (1-Nchunk), an optional original ID value, optional coordinate
values for chunks that represent spatial bins, the number of atoms in
the chunk, and one or more calculated values. More explanation of the
optional values is given below. The number of values in each line
corresponds to the number of values specified in the fix ave/chunk
command. The number of atoms and the value(s) are summed or average
quantities, as explained above.</p>
<p>The <em>overwrite</em> keyword will continuously overwrite the output file
with the latest output, so that it only contains one timestep worth of
output. This option can only be used with the <em>ave running</em> setting.</p>
<p>The <em>format</em> keyword sets the numeric format of each value when it is
printed to a file via the <em>file</em> keyword. Note that all values are
floating point quantities. The default format is %g. You can specify
a higher precision if desired, e.g. %20.16g.</p>
<p>The <em>title1</em> and <em>title2</em> and <em>title3</em> keywords allow specification of
the strings that will be printed as the first 3 lines of the output
file, assuming the <em>file</em> keyword was used. LAMMPS uses default
values for each of these, so they do not need to be specified.</p>
<p>By default, these header lines are as follows:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># Chunk-averaged data for fix ID and group name</span>
<p>In the first line, ID and name are replaced with the fix-ID and group
name. The second line describes the two values that are printed at
the first of each section of output. In the third line the values are
replaced with the appropriate value names, e.g. fx or c_myCompute<strong>2</strong>.</p>
<p>The words in parenthesis only appear with corresponding columns if the
chunk style specified for the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command supports them. The OrigID
column is only used if the <em>compress</em> keyword was set to <em>yes</em> for the
<a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command. This means that
the original chunk IDs (e.g. molecule IDs) will have been compressed
to remove chunk IDs with no atoms assigned to them. Thus a compresed
chunk ID of 3 may correspond to an original chunk ID or molecule ID of
415. The OrigID column will list 415 for the 3rd chunk.</p>
<p>The CoordN columns only appear if a <em>binning</em> style was used in the
<a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command. For <em>bin/1d</em>,
<em>bin/2d</em>, and <em>bin/3d</em> styles the column values are the center point
of the bin in the corresponding dimension. Just Coord1 is used for
<em>bin/1d</em>, Coord2 is added for <em>bin/2d</em>, Coord3 is added for <em>bin/3d</em>.
For <em>bin/sphere</em>, just Coord1 is used, and it is the radial
coordinate. For <em>bin/cylinder</em>, Coord1 and Coord2 are used. Coord1
is the radial coordinate (away from the cylinder axis), and coord2 is
the coordinate along the cylinder axis.</p>
<p>Note that if the value of the <em>units</em> keyword used in the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom command</span></a> is <em>box</em> or <em>lattice</em>, the
coordinate values will be in distance <a class="reference internal" href="units.html"><span class="doc">units</span></a>. If the
value of the <em>units</em> keyword is <em>reduced</em>, the coordinate values will
be in unitless reduced units (0-1). This is not true for the Coord1 value
of style <em>bin/sphere</em> or <em>bin/cylinder</em> which both represent radial
dimensions. Those values are always in distance <a class="reference internal" href="units.html"><span class="doc">units</span></a>.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>This fix computes a global array of values which can be accessed by
various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The values can
only be accessed on timesteps that are multiples of <em>Nfreq</em> since that
is when averaging is performed. The global array has # of rows =
the number of chunks <em>Nchunk</em> as calculated by the specified <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command. The # of columns =
M+1+Nvalues, where M = 1 to 4, depending on whether the optional
columns for OrigID and CoordN are used, as explained above.
Following the optional columns, the next column contains the count of
atoms in the chunk, and the remaining columns are the Nvalue
quantities. When the array is accessed with a row I that exceeds the
current number of chunks, than a 0.0 is returned by the fix instead of
an error, since the number of chunks can vary as a simulation runs
depending on how that value is computed by the compute chunk/atom
command.</p>
<p>The array values calculated by this fix are treated as “intensive”,
since they are typically already normalized by the count of atoms in
each chunk.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+c_ID = global scalar calculated by a compute with ID
+c_ID[I] = Ith component of global vector calculated by a compute with ID, I can include wildcard (see below)
+f_ID = global scalar calculated by a fix with ID
+f_ID[I] = Ith component of global vector calculated by a fix with ID, I can include wildcard (see below)
+v_name = global value calculated by an equal-style variable with name
+v_name[I] = Ith component of a vector-style variable with name
+</pre>
<ul class="simple">
<li>zero or more keyword/arg pairs may be appended</li>
<li>keyword = <em>type</em> or <em>ave</em> or <em>start</em> or <em>prefactor</em> or <em>file</em> or <em>overwrite</em> or <em>title1</em> or <em>title2</em> or <em>title3</em></li>
</ul>
<pre class="literal-block">
<em>type</em> arg = <em>auto</em> or <em>upper</em> or <em>lower</em> or <em>auto/upper</em> or <em>auto/lower</em> or <em>full</em>
auto = correlate each value with itself
upper = correlate each value with each succeeding value
lower = correlate each value with each preceding value
auto/upper = auto + upper
auto/lower = auto + lower
full = correlate each value with every other value, including itself = auto + upper + lower
<em>ave</em> args = <em>one</em> or <em>running</em>
one = zero the correlation accumulation every Nfreq steps
running = accumulate correlations continuously
<em>start</em> args = Nstart
Nstart = start accumulating correlations on this timestep
<em>prefactor</em> args = value
value = prefactor to scale all the correlation data by
<em>file</em> arg = filename
filename = name of file to output correlation data to
<em>overwrite</em> arg = none = overwrite output file with only latest output
+fix 1 all ave/correlate 5 100 1000 c_myTemp file temp.correlate
+fix 1 all ave/correlate 1 50 10000 &
+ c_thermo_press[1] c_thermo_press[2] c_thermo_press[3] &
+ type upper ave running title1 "My correlation data"
+</pre>
<p>fix 1 all ave/correlate 1 50 10000 c_thermo_press[*]</p>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Use one or more global scalar values as inputs every few timesteps,
calculate time correlations bewteen them at varying time intervals,
and average the correlation data over longer timescales. The
resulting correlation values can be time integrated by
<a class="reference internal" href="variable.html"><span class="doc">variables</span></a> or used by other <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a> such as <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a>, and can also be written to a file. See the
<a class="reference internal" href="fix_ave_correlate_long.html"><span class="doc">fix ave/correlate/long</span></a> command for an
alternate method for computing correlation functions efficiently over
very long time windows.</p>
<p>The group specified with this command is ignored. However, note that
specified values may represent calculations performed by computes and
fixes which store their own “group” definitions.</p>
<p>Each listed value can be the result of a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> or
<a class="reference internal" href="fix.html"><span class="doc">fix</span></a> or the evaluation of an equal-style or vector-style
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a>. In each case, the compute, fix, or variable
must produce a global quantity, not a per-atom or local quantity. If
you wish to spatial- or time-average or histogram per-atom quantities
from a compute, fix, or variable, then see the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a>, <a class="reference internal" href="fix_ave_atom.html"><span class="doc">fix ave/atom</span></a>, or
<a class="reference internal" href="fix_ave_histo.html"><span class="doc">fix ave/histo</span></a> commands. If you wish to convert a
per-atom quantity into a single global value, see the <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a> command.</p>
<p>The input values must either be all scalars. What kinds of
correlations between input values are calculated is determined by the
<em>type</em> keyword as discussed below.</p>
<p><a class="reference internal" href="compute.html"><span class="doc">Computes</span></a> that produce global quantities are those which
do not have the word <em>atom</em> in their style name. Only a few
<a class="reference internal" href="fix.html"><span class="doc">fixes</span></a> produce global quantities. See the doc pages for
individual fixes for info on which ones produce such values.
<a class="reference internal" href="variable.html"><span class="doc">Variables</span></a> of style <em>equal</em> and <em>vector</em> are the only
ones that can be used with this fix. Variables of style <em>atom</em> cannot
be used, since they produce per-atom values.</p>
<p>Note that for values from a compute or fix, the bracketed index I can
be specified using a wildcard asterisk with the index to effectively
-specify multiple values. This takes the form “*” or “<em>n” or “n</em>” or
+specify multiple values. This takes the form “*” or “*n” or “n*” or
“m*n”. If N = the size of the vector (for <em>mode</em> = scalar) or the
number of columns in the array (for <em>mode</em> = vector), then an asterisk
with no numeric values means all indices from 1 to N. A leading
asterisk means all indices from 1 to n (inclusive). A trailing
asterisk means all indices from n to N (inclusive). A middle asterisk
means all indices from m to n (inclusive).</p>
<p>Using a wildcard is the same as if the individual elements of the
vector had been listed one by one. E.g. these 2 fix ave/correlate
commands are equivalent, since the <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> command creates a global vector with 6
<p><em>Nfreq</em> must be a multiple of <em>Nevery</em>; <em>Nevery</em> and <em>Nrepeat</em> must be
non-zero. Also, if the <em>ave</em> keyword is set to <em>one</em> which is the
default, then <em>Nfreq</em> >= (<em>Nrepeat</em>-1)*<em>Nevery</em> is required.</p>
<hr class="docutils" />
-<p>If a value begins with “<a href="#id3"><span class="problematic" id="id4">c_</span></a>”, a compute ID must follow which has been
+<p>If a value begins with “c_”, a compute ID must follow which has been
previously defined in the input script. If no bracketed term is
appended, the global scalar calculated by the compute is used. If a
bracketed term is appended, the Ith element of the global vector
calculated by the compute is used. See the discussion above for how I
can be specified with a wildcard asterisk to effectively specify
multiple values.</p>
<p>Note that there is a <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a> command
which can sum per-atom quantities into a global scalar or vector which
can thus be accessed by fix ave/correlate. Or it can be a compute
defined not in your input script, but by <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a> or other fixes such as <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>
or <a class="reference internal" href="fix_temp_rescale.html"><span class="doc">fix temp/rescale</span></a>. See the doc pages for
these commands which give the IDs of these computes. Users can also
write code for their own compute styles and <a class="reference internal" href="Section_modify.html"><span class="doc">add them to LAMMPS</span></a>.</p>
-<p>If a value begins with “<a href="#id5"><span class="problematic" id="id6">f_</span></a>”, a fix ID must follow which has been
+<p>If a value begins with “f_”, a fix ID must follow which has been
previously defined in the input script. If no bracketed term is
appended, the global scalar calculated by the fix is used. If a
bracketed term is appended, the Ith element of the global vector
calculated by the fix is used. See the discussion above for how I can
be specified with a wildcard asterisk to effectively specify multiple
values.</p>
<p>Note that some fixes only produce their values on certain timesteps,
which must be compatible with <em>Nevery</em>, else an error will result.
Users can also write code for their own fix styles and <a class="reference internal" href="Section_modify.html"><span class="doc">add them to LAMMPS</span></a>.</p>
-<p>If a value begins with “<a href="#id7"><span class="problematic" id="id8">v_</span></a>”, a variable name must follow which has
+<p>If a value begins with “v_”, a variable name must follow which has
been previously defined in the input script. Only equal-style or
vector-style variables can be referenced; the latter requires a
bracketed term to specify the Ith element of the vector calculated by
the variable. See the <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command for details.
Note that variables of style <em>equal</em> or <em>vector</em> define a formula
which can reference individual atom properties or thermodynamic
keywords, or they can invoke other computes, fixes, or variables when
they are evaluated, so this is a very general means of specifying
quantities to time correlate.</p>
<hr class="docutils" />
<p>Additional optional keywords also affect the operation of this fix.</p>
<p>The <em>type</em> keyword determines which pairs of input values are
correlated with each other. For N input values Vi, for i = 1 to N,
let the number of pairs = Npair. Note that the second value in the
pair Vi(t)*Vj(t+delta) is always the one sampled at the later time.</p>
<ul class="simple">
<li>If <em>type</em> is set to <em>auto</em> then each input value is correlated with
itself. I.e. Cii = Vi*Vi, for i = 1 to N, so Npair = N.</li>
<li>If <em>type</em> is set
to <em>upper</em> then each input value is correlated with every succeeding
value. I.e. Cij = Vi*Vj, for i < j, so Npair = N*(N-1)/2.</li>
<li>If <em>type</em> is set
to <em>lower</em> then each input value is correlated with every preceeding
value. I.e. Cij = Vi*Vj, for i > j, so Npair = N*(N-1)/2.</li>
<li>If <em>type</em> is set to <em>auto/upper</em> then each input value is correlated
with itself and every succeeding value. I.e. Cij = Vi*Vj, for i >= j,
so Npair = N*(N+1)/2.</li>
<li>If <em>type</em> is set to <em>auto/lower</em> then each input value is correlated
with itself and every preceding value. I.e. Cij = Vi*Vj, for i <= j,
so Npair = N*(N+1)/2.</li>
<li>If <em>type</em> is set to <em>full</em> then each input value is correlated with
itself and every other value. I.e. Cij = Vi*Vj, for i,j = 1,N so
Npair = N^2.</li>
</ul>
<p>The <em>ave</em> keyword determines what happens to the accumulation of
correlation samples every <em>Nfreq</em> timesteps. If the <em>ave</em> setting is
<em>one</em>, then the accumulation is restarted or zeroed every <em>Nfreq</em>
timesteps. Thus the outputs on successive <em>Nfreq</em> timesteps are
essentially independent of each other. The exception is that the
Cij(0) = Vi(T)*Vj(T) value at a timestep T, where T is a multiple of
<em>Nfreq</em>, contributes to the correlation output both at time T and at
time T+Nfreq.</p>
<p>If the <em>ave</em> setting is <em>running</em>, then the accumulation is never
zeroed. Thus the output of correlation data at any timestep is the
average over samples accumulated every <em>Nevery</em> steps since the fix
was defined. it can only be restarted by deleting the fix via the
<a class="reference internal" href="unfix.html"><span class="doc">unfix</span></a> command, or by re-defining the fix by re-specifying
it.</p>
<p>The <em>start</em> keyword specifies what timestep the accumulation of
correlation samples will begin on. The default is step 0. Setting it
to a larger value can avoid adding non-equilibrated data to the
correlation averages.</p>
<p>The <em>prefactor</em> keyword specifies a constant which will be used as a
multiplier on the correlation data after it is averaged. It is
effectively a scale factor on Vi*Vj, which can be used to account for
the size of the time window or other unit conversions.</p>
<p>The <em>file</em> keyword allows a filename to be specified. Every <em>Nfreq</em>
steps, an array of correlation data is written to the file. The
number of rows is <em>Nrepeat</em>, as described above. The number of
columns is the Npair+2, also as described above. Thus the file ends
up to be a series of these array sections.</p>
<p>The <em>overwrite</em> keyword will continuously overwrite the output file
with the latest output, so that it only contains one timestep worth of
output. This option can only be used with the <em>ave running</em> setting.</p>
<p>The <em>title1</em> and <em>title2</em> and <em>title3</em> keywords allow specification of
the strings that will be printed as the first 3 lines of the output
file, assuming the <em>file</em> keyword was used. LAMMPS uses default
values for each of these, so they do not need to be specified.</p>
<p>By default, these header lines are as follows:</p>
-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># Time-correlated data for fix ID</span>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>This fix computes a global array of values which can be accessed by
various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The values can
only be accessed on timesteps that are multiples of <em>Nfreq</em> since that
is when averaging is performed. The global array has # of rows =
<em>Nrepeat</em> and # of columns = Npair+2. The first column has the time
delta (in timesteps) between the pairs of input values used to
calculate the correlation, as described above. The 2nd column has the
number of samples contributing to the correlation average, as
described above. The remaining Npair columns are for I,J pairs of the
N input values, as determined by the <em>type</em> keyword, as described
above.</p>
<ul class="simple">
<li>For <em>type</em> = <em>auto</em>, the Npair = N columns are ordered: C11, C22, ...,
CNN.</li>
<li>For <em>type</em> = <em>upper</em>, the Npair = N*(N-1)/2 columns are ordered: C12,
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+c_ID = global scalar calculated by a compute with ID
+c_ID[I] = Ith component of global vector calculated by a compute with ID
+f_ID = global scalar calculated by a fix with ID
+f_ID[I] = Ith component of global vector calculated by a fix with ID
+v_name = global value calculated by an equal-style variable with name
+</pre>
<ul class="simple">
<li>zero or more keyword/arg pairs may be appended</li>
<li>keyword = <em>type</em> or <em>start</em> or <em>file</em> or <em>overwrite</em> or <em>title1</em> or <em>title2</em> or <em>ncorr</em> or <em>p</em> or <em>m</em></li>
</ul>
<pre class="literal-block">
<em>type</em> arg = <em>auto</em> or <em>upper</em> or <em>lower</em> or <em>auto/upper</em> or <em>auto/lower</em> or <em>full</em>
auto = correlate each value with itself
upper = correlate each value with each succeeding value
lower = correlate each value with each preceding value
auto/upper = auto + upper
auto/lower = auto + lower
full = correlate each value with every other value, including itself = auto + upper + lower
<em>start</em> args = Nstart
Nstart = start accumulating correlations on this timestep
<em>file</em> arg = filename
filename = name of file to output correlation data to
<em>overwrite</em> arg = none = overwrite output file with only latest output
<em>title1</em> arg = string
string = text to print as 1st line of output file
<em>title2</em> arg = string
string = text to print as 2nd line of output file
<em>ncorr</em> arg = Ncorrelators
Ncorrelators = number of correlators to store
<em>nlen</em> args = Nlen
Nlen = length of each correlator
<em>ncount</em> args = Ncount
Ncount = number of values over which succesive correlators are averaged
<p>This fix is similar in spirit and syntax to the <a class="reference internal" href="fix_ave_correlate.html"><span class="doc">fix ave/correlate</span></a>. However, this fix allows the
efficient calculation of time correlation functions on the fly over
extremely long time windows without too much CPU overhead, using a
multiple-tau method <a class="reference internal" href="#ramirez"><span class="std std-ref">(Ramirez)</span></a> that decreases the resolution
of the stored correlation function with time.</p>
<p>The group specified with this command is ignored. However, note that
specified values may represent calculations performed by computes and
fixes which store their own “group” definitions.</p>
<p>Each listed value can be the result of a compute or fix or the
evaluation of an equal-style variable. See the <a class="reference internal" href="fix_ave_correlate.html"><span class="doc">fix ave/correlate</span></a> doc page for details.</p>
<p>The <em>Nevery</em> and <em>Nfreq</em> arguments specify on what timesteps the input
values will be used to calculate correlation data, and the frequency
with which the time correlation functions will be output to a file.
Note that there is no <em>Nrepeat</em> argument, unlike the <a class="reference internal" href="fix_ave_correlate.html"><span class="doc">fix ave/correlate</span></a> command.</p>
<p>The optional keywords <em>ncorr</em>, <em>nlen</em>, and <em>ncount</em> are unique to this
command and determine the number of correlation points calculated and
the memory and CPU overhead used by this calculation. <em>Nlen</em> and
<em>ncount</em> determine the amount of averaging done at longer correlation
times. The default values <em>nlen=16</em>, <em>ncount=2</em> ensure that the
systematic error of the multiple-tau correlator is always below the
level of the statistical error of a typical simulation (which depends
on the ensemble size and the simulation length).</p>
<p>The maximum correlation time (in time steps) that can be reached is
given by the formula (nlen-1) * ncount^(ncorr-1). Longer correlation
times are discarded and not calculated. With the default values of
the parameters (ncorr=20, nlen=16 and ncount=2), this corresponds to
7864320 time steps. If longer correlation times are needed, the value
of ncorr should be increased. Using nlen=16 and ncount=2, with
ncorr=30, the maximum number of steps that can be correlated is
80530636808. If ncorr=40, correlation times in excess of 8e12 time
steps can be calculated.</p>
<p>The total memory needed for each correlation pair is roughly
4*ncorr*nlen*8 bytes. With the default values of the parameters, this
corresponds to about 10 KB.</p>
<p>For the meaning of the additional optional keywords, see the <a class="reference internal" href="fix_ave_correlate.html"><span class="doc">fix ave/correlate</span></a> doc page.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>Since this fix in intended for the calculation of time correlation
functions over very long MD simulations, the information about this
fix is written automatically to binary restart files, so that the time
correlation calculation can continue in subsequent simulations. None
of the fix_modify options are relevant to this fix.</p>
<p>No parameter of this fix can be used with the start/stop keywords of
the run command. This fix is not invoked during energy minimization.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This compute is part of the USER-MISC package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The option defaults for keywords that are also keywords for the <a class="reference internal" href="fix_ave_correlate.html"><span class="doc">fix ave/correlate</span></a> command are as follows: type =
auto, start = 0, no file output, title 1,2 = strings as described on
the <a class="reference internal" href="fix_ave_correlate.html"><span class="doc">fix ave/correlate</span></a> doc page.</p>
<p>The option defaults for keywords unique to this command are as
follows: ncorr=20, nlen=16, ncount=2.</p>
<hr class="docutils" />
<p id="ramirez"><strong>(Ramirez)</strong> J. Ramirez, S.K. Sukumaran, B. Vorselaars and
A.E. Likhtman, J. Chem. Phys. 133, 154103 (2010).</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+x,y,z,vx,vy,vz,fx,fy,fz = atom attribute (position, velocity, force component)
+c_ID = scalar or vector calculated by a compute with ID
+c_ID[I] = Ith component of vector or Ith column of array calculated by a compute with ID, I can include wildcard (see below)
+f_ID = scalar or vector calculated by a fix with ID
+f_ID[I] = Ith component of vector or Ith column of array calculated by a fix with ID, I can include wildcard (see below)
+v_name = value(s) calculated by an equal-style or vector-style or atom-style variable with name
+v_name[I] = value calculated by a vector-style variable with name
+</pre>
<ul class="simple">
<li>zero or more keyword/arg pairs may be appended</li>
<li>keyword = <em>mode</em> or <em>file</em> or <em>ave</em> or <em>start</em> or <em>beyond</em> or <em>overwrite</em> or <em>title1</em> or <em>title2</em> or <em>title3</em></li>
</ul>
<pre class="literal-block">
<em>mode</em> arg = <em>scalar</em> or <em>vector</em>
scalar = all input values are scalars
vector = all input values are vectors
<em>file</em> arg = filename
filename = name of file to output histogram(s) to
<em>ave</em> args = <em>one</em> or <em>running</em> or <em>window</em>
one = output a new average value every Nfreq steps
running = output cumulative average of all previous Nfreq steps
window M = output average of M most recent Nfreq steps
<em>start</em> args = Nstart
Nstart = start averaging on this timestep
<em>beyond</em> arg = <em>ignore</em> or <em>end</em> or <em>extra</em>
<p>Use one or more values as inputs every few timesteps to create a
single histogram. The histogram can then be averaged over longer
timescales. The resulting histogram can be used by other <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>, and can also be written to a
file. The fix ave/histo/weight command has identical syntax to fix
ave/histo, except that exactly two values must be specified. See
details below.</p>
<p>The group specified with this command is ignored for global and local
input values. For per-atom input values, only atoms in the group
contribute to the histogram. Note that regardless of the specified
group, specified values may represent calculations performed by
computes and fixes which store their own “group” definition.</p>
<p>A histogram is simply a count of the number of values that fall within
a histogram bin. <em>Nbins</em> are defined, with even spacing between <em>lo</em>
and <em>hi</em>. Values that fall outside the lo/hi bounds can be treated in
different ways; see the discussion of the <em>beyond</em> keyword below.</p>
<p>Each input value can be an atom attribute (position, velocity, force
component) or can be the result of a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> or
<a class="reference internal" href="fix.html"><span class="doc">fix</span></a> or the evaluation of an equal-style or vector-style or
atom-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>. The set of input values can be
either all global, all per-atom, or all local quantities. Inputs of
different kinds (e.g. global and per-atom) cannot be mixed. Atom
attributes are per-atom vector values. See the doc page for
individual “compute” and “fix” commands to see what kinds of
quantities they generate.</p>
<p>Note that the output of this command is a single histogram for all
input values combined together, not one histogram per input value.
See below for details on the format of the output of this fix.</p>
<p>The input values must either be all scalars or all vectors (or
arrays), depending on the setting of the <em>mode</em> keyword.</p>
<p>If <em>mode</em> = scalar, then the input values must be scalars, or vectors
with a bracketed term appended, indicating the Ith value of the vector
is used.</p>
<p>If <em>mode</em> = vector, then the input values must be vectors, or arrays
with a bracketed term appended, indicating the Ith column of the array
is used.</p>
<p>Note that for values from a compute or fix, the bracketed index I can
be specified using a wildcard asterisk with the index to effectively
-specify multiple values. This takes the form “*” or “<em>n” or “n</em>” or
+specify multiple values. This takes the form “*” or “*n” or “n*” or
“m*n”. If N = the size of the vector (for <em>mode</em> = scalar) or the
number of columns in the array (for <em>mode</em> = vector), then an asterisk
with no numeric values means all indices from 1 to N. A leading
asterisk means all indices from 1 to n (inclusive). A trailing
asterisk means all indices from n to N (inclusive). A middle asterisk
means all indices from m to n (inclusive).</p>
<p>Using a wildcard is the same as if the individual elements of the
vector or columns of the array had been listed one by one. E.g. these
2 fix ave/histo commands are equivalent, since the <a class="reference internal" href="compute_com_chunk.html"><span class="doc">compute com/chunk</span></a> command creates a global array with
<p>If the fix ave/histo/weight command is used, exactly two values must
be specified. If the values are vectors, they must be the same
length. The first value (a scalar or vector) is what is histogrammed
into bins, in the same manner the fix ave/histo command operates. The
second value (a scalar or vector) is used as a “weight”. This means
that instead of each value tallying a “1” to its bin, the
corresponding weight is tallied. E.g. The Nth entry (weight) in the
second vector is tallied to the bin corresponding to the Nth entry in
the first vector.</p>
<hr class="docutils" />
<p>The <em>Nevery</em>, <em>Nrepeat</em>, and <em>Nfreq</em> arguments specify on what
timesteps the input values will be used in order to contribute to the
histogram. The final histogram is generated on timesteps that are
multiple of <em>Nfreq</em>. It is averaged over <em>Nrepeat</em> histograms,
computed in the preceding portion of the simulation every <em>Nevery</em>
timesteps. <em>Nfreq</em> must be a multiple of <em>Nevery</em> and <em>Nevery</em> must
be non-zero even if <em>Nrepeat</em> is 1. Also, the timesteps
contributing to the histogram value cannot overlap,
i.e. Nrepeat*Nevery can not exceed Nfreq.</p>
<p>For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then input values
on timesteps 90,92,94,96,98,100 will be used to compute the final
histogram on timestep 100. Similarly for timesteps
190,192,194,196,198,200 on timestep 200, etc. If Nrepeat=1 and Nfreq
= 100, then no time averaging of the histogram is done; a histogram is
simply generated on timesteps 100,200,etc.</p>
<hr class="docutils" />
<p>The atom attribute values (x,y,z,vx,vy,vz,fx,fy,fz) are
self-explanatory. Note that other atom attributes can be used as
inputs to this fix by using the <a class="reference internal" href="compute_property_atom.html"><span class="doc">compute property/atom</span></a> command and then specifying
an input value from that compute.</p>
-<p>If a value begins with “<a href="#id1"><span class="problematic" id="id2">c_</span></a>”, a compute ID must follow which has been
+<p>If a value begins with “c_”, a compute ID must follow which has been
previously defined in the input script. If <em>mode</em> = scalar, then if
no bracketed term is appended, the global scalar calculated by the
compute is used. If a bracketed term is appended, the Ith element of
the global vector calculated by the compute is used. If <em>mode</em> =
vector, then if no bracketed term is appended, the global or per-atom
or local vector calculated by the compute is used. If a bracketed
term is appended, the Ith column of the global or per-atom or local
array calculated by the compute is used. See the discussion above for
how I can be specified with a wildcard asterisk to effectively specify
multiple values.</p>
<p>Note that there is a <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a> command
which can sum per-atom quantities into a global scalar or vector which
can thus be accessed by fix ave/histo. Or it can be a compute defined
not in your input script, but by <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a> or other fixes such as <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> or <a class="reference internal" href="fix_temp_rescale.html"><span class="doc">fix temp/rescale</span></a>. See
the doc pages for these commands which give the IDs of these computes.
Users can also write code for their own compute styles and <a class="reference internal" href="Section_modify.html"><span class="doc">add them to LAMMPS</span></a>.</p>
-<p>If a value begins with “<a href="#id3"><span class="problematic" id="id4">f_</span></a>”, a fix ID must follow which has been
+<p>If a value begins with “f_”, a fix ID must follow which has been
previously defined in the input script. If <em>mode</em> = scalar, then if
no bracketed term is appended, the global scalar calculated by the fix
is used. If a bracketed term is appended, the Ith element of the
global vector calculated by the fix is used. If <em>mode</em> = vector, then
if no bracketed term is appended, the global or per-atom or local
vector calculated by the fix is used. If a bracketed term is
appended, the Ith column of the global or per-atom or local array
calculated by the fix is used. See the discussion above for how I can
be specified with a wildcard asterisk to effectively specify multiple
values.</p>
<p>Note that some fixes only produce their values on certain timesteps,
which must be compatible with <em>Nevery</em>, else an error will result.
Users can also write code for their own fix styles and <a class="reference internal" href="Section_modify.html"><span class="doc">add them to LAMMPS</span></a>.</p>
-<p>If a value begins with “<a href="#id5"><span class="problematic" id="id6">v_</span></a>”, a variable name must follow which has
+<p>If a value begins with “v_”, a variable name must follow which has
been previously defined in the input script. If <em>mode</em> = scalar, then
only equal-style or vector-style variables can be used, which both
produce global values. In this mode, a vector-style variable requires
a bracketed term to specify the Ith element of the vector calculated
by the variable. If <em>mode</em> = vector, then only vector-style or
atom-style variables can be used, which produce a global or per-atom
vector respectively. The vector-style variable must be used without a
bracketed term. See the <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command for details.</p>
<p>Note that variables of style <em>equal</em>, <em>vector</em>, and <em>atom</em> define a
formula which can reference individual atom properties or
thermodynamic keywords, or they can invoke other computes, fixes, or
variables when they are evaluated, so this is a very general means of
specifying quantities to histogram.</p>
<hr class="docutils" />
<p>Additional optional keywords also affect the operation of this fix.</p>
<p>If the <em>mode</em> keyword is set to <em>scalar</em>, then all input values must
be global scalars, or elements of global vectors. If the <em>mode</em>
keyword is set to <em>vector</em>, then all input values must be global or
per-atom or local vectors, or columns of global or per-atom or local
arrays.</p>
<p>The <em>beyond</em> keyword determines how input values that fall outside the
<em>lo</em> to <em>hi</em> bounds are treated. Values such that <em>lo</em> <= value <=
<em>hi</em> are assigned to one bin. Values on a bin boundary are assigned
to the lower of the 2 bins. If <em>beyond</em> is set to <em>ignore</em> then
values < <em>lo</em> and values > <em>hi</em> are ignored, i.e. they are not binned.
If <em>beyond</em> is set to <em>end</em> then values < <em>lo</em> are counted in the
first bin and values > <em>hi</em> are counted in the last bin. If <em>beyond</em>
is set to <em>extend</em> then two extra bins are created, so that there are
Nbins+2 total bins. Values < <em>lo</em> are counted in the first bin and
values > <em>hi</em> are counted in the last bin (Nbins+1). Values between
<em>lo</em> and <em>hi</em> (inclusive) are counted in bins 2 thru Nbins+1. The
“coordinate” stored and printed for these two extra bins is <em>lo</em> and
<em>hi</em>.</p>
<p>The <em>ave</em> keyword determines how the histogram produced every <em>Nfreq</em>
steps are averaged with histograms produced on previous steps that
were multiples of <em>Nfreq</em>, before they are accessed by another output
command or written to a file.</p>
<p>If the <em>ave</em> setting is <em>one</em>, then the histograms produced on
timesteps that are multiples of <em>Nfreq</em> are independent of each other;
they are output as-is without further averaging.</p>
<p>If the <em>ave</em> setting is <em>running</em>, then the histograms produced on
timesteps that are multiples of <em>Nfreq</em> are summed and averaged in a
cumulative sense before being output. Each bin value in the histogram
is thus the average of the bin value produced on that timestep with
all preceding values for the same bin. This running average begins
when the fix is defined; it can only be restarted by deleting the fix
via the <a class="reference internal" href="unfix.html"><span class="doc">unfix</span></a> command, or by re-defining the fix by
re-specifying it.</p>
<p>If the <em>ave</em> setting is <em>window</em>, then the histograms produced on
timesteps that are multiples of <em>Nfreq</em> are summed within a moving
“window” of time, so that the last M histograms are used to produce
the output. E.g. if M = 3 and Nfreq = 1000, then the output on step
10000 will be the combined histogram of the individual histograms on
steps 8000,9000,10000. Outputs on early steps will be sums over less
than M histograms if they are not available.</p>
<p>The <em>start</em> keyword specifies what timestep histogramming will begin
on. The default is step 0. Often input values can be 0.0 at time 0,
so setting <em>start</em> to a larger value can avoid including a 0.0 in
a running or windowed histogram.</p>
<p>The <em>file</em> keyword allows a filename to be specified. Every <em>Nfreq</em>
steps, one histogram is written to the file. This includes a leading
line that contains the timestep, number of bins, the total count of
values contributing to the histogram, the count of values that were
not histogrammed (see the <em>beyond</em> keyword), the minimum value
encountered, and the maximum value encountered. The min/max values
include values that were not histogrammed. Following the leading
line, one line per bin is written into the file. Each line contains
the bin #, the coordinate for the center of the bin (between <em>lo</em> and
<em>hi</em>), the count of values in the bin, and the normalized count. The
normalized count is the bin count divided by the total count (not
including values not histogrammed), so that the normalized values sum
to 1.0 across all bins.</p>
<p>The <em>overwrite</em> keyword will continuously overwrite the output file
with the latest output, so that it only contains one timestep worth of
output. This option can only be used with the <em>ave running</em> setting.</p>
<p>The <em>title1</em> and <em>title2</em> and <em>title3</em> keywords allow specification of
the strings that will be printed as the first 3 lines of the output
file, assuming the <em>file</em> keyword was used. LAMMPS uses default
values for each of these, so they do not need to be specified.</p>
<p>By default, these header lines are as follows:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># Histogram for fix ID</span>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>This fix produces a global vector and global array which can be
accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>.
The values can only be accessed on timesteps that are multiples of
<em>Nfreq</em> since that is when a histogram is generated. The global
vector has 4 values:</p>
<ul class="simple">
<li>1 = total counts in the histogram</li>
<li>2 = values that were not histogrammed (see <em>beyond</em> keyword)</li>
<li>3 = min value of all input values, including ones not histogrammed</li>
<li>4 = max value of all input values, including ones not histogrammed</li>
</ul>
<p>The global array has # of rows = Nbins and # of columns = 3. The
first column has the bin coordinate, the 2nd column has the count of
values in that histogram bin, and the 3rd column has the bin count
divided by the total count (not including missing counts), so that the
values in the 3rd column sum to 1.0.</p>
<p>The vector and array values calculated by this fix are all treated as
intensive. If this is not the case, e.g. due to histogramming
per-atom input values, then you will need to account for that when
interpreting the values produced by this fix.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+c_ID = global scalar or vector calculated by a compute with ID
+c_ID[I] = Ith component of global vector or Ith column of global array calculated by a compute with ID, I can include wildcard (see below)
+f_ID = global scalar or vector calculated by a fix with ID
+f_ID[I] = Ith component of global vector or Ith column of global array calculated by a fix with ID, I can include wildcard (see below)
+v_name = value(s) calculated by an equal-style or vector-style variable with name
+v_name[I] = value calculated by a vector-style variable with name
+</pre>
<ul class="simple">
<li>zero or more keyword/arg pairs may be appended</li>
<li>keyword = <em>mode</em> or <em>file</em> or <em>ave</em> or <em>start</em> or <em>off</em> or <em>overwrite</em> or <em>title1</em> or <em>title2</em> or <em>title3</em></li>
</ul>
<pre class="literal-block">
<em>mode</em> arg = <em>scalar</em> or <em>vector</em>
scalar = all input values are global scalars
vector = all input values are global vectors or global arrays
<em>ave</em> args = <em>one</em> or <em>running</em> or <em>window M</em>
one = output a new average value every Nfreq steps
running = output cummulative average of all previous Nfreq steps
window M = output average of M most recent Nfreq steps
<em>start</em> args = Nstart
Nstart = start averaging on this timestep
<em>off</em> arg = M = do not average this value
M = value # from 1 to Nvalues
<em>file</em> arg = filename
filename = name of file to output time averages to
<em>overwrite</em> arg = none = overwrite output file with only latest output
<em>format</em> arg = string
string = C-style format string
<em>title1</em> arg = string
string = text to print as 1st line of output file
<em>title2</em> arg = string
string = text to print as 2nd line of output file
<em>title3</em> arg = string
string = text to print as 3rd line of output file, only for vector mode
+fix 1 all ave/time 100 5 1000 c_thermo_press[2] ave window 20 &
+ title1 "My output values"
+fix 1 all ave/time 100 5 1000 c_thermo_press[*]
+fix 1 all ave/time 1 100 1000 f_indent f_indent[1] file temp.indent off 1
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Use one or more global values as inputs every few timesteps, and
average them over longer timescales. The resulting averages can be
used by other <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a> such as
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a>, and can also be written to a
file. Note that if no time averaging is done, this command can be
used as a convenient way to simply output one or more global values to
a file.</p>
<p>The group specified with this command is ignored. However, note that
specified values may represent calculations performed by computes and
fixes which store their own “group” definitions.</p>
<p>Each listed value can be the result of a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> or
<a class="reference internal" href="fix.html"><span class="doc">fix</span></a> or the evaluation of an equal-style or vector-style
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a>. In each case, the compute, fix, or variable
must produce a global quantity, not a per-atom or local quantity. If
you wish to spatial- or time-average or histogram per-atom quantities
from a compute, fix, or variable, then see the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a>, <a class="reference internal" href="fix_ave_atom.html"><span class="doc">fix ave/atom</span></a>,
or <a class="reference internal" href="fix_ave_histo.html"><span class="doc">fix ave/histo</span></a> commands. If you wish to sum a
per-atom quantity into a single global quantity, see the <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a> command.</p>
<p><a class="reference internal" href="compute.html"><span class="doc">Computes</span></a> that produce global quantities are those which
do not have the word <em>atom</em> in their style name. Only a few
<a class="reference internal" href="fix.html"><span class="doc">fixes</span></a> produce global quantities. See the doc pages for
individual fixes for info on which ones produce such values.
<a class="reference internal" href="variable.html"><span class="doc">Variables</span></a> of style <em>equal</em> and <em>vector</em> are the only
ones that can be used with this fix. Variables of style <em>atom</em> cannot
be used, since they produce per-atom values.</p>
<p>The input values must either be all scalars or all vectors depending
on the setting of the <em>mode</em> keyword. In both cases, the averaging is
performed independently on each input value. I.e. each input scalar
is averaged independently or each element of each input vector is
averaged independently.</p>
<p>If <em>mode</em> = scalar, then the input values must be scalars, or vectors
with a bracketed term appended, indicating the Ith value of the vector
is used.</p>
<p>If <em>mode</em> = vector, then the input values must be vectors, or arrays
with a bracketed term appended, indicating the Ith column of the array
is used. All vectors must be the same length, which is the length of
the vector or number of rows in the array.</p>
<p>Note that for values from a compute or fix, the bracketed index I can
be specified using a wildcard asterisk with the index to effectively
-specify multiple values. This takes the form “*” or “<em>n” or “n</em>” or
+specify multiple values. This takes the form “*” or “*n” or “n*” or
“m*n”. If N = the size of the vector (for <em>mode</em> = scalar) or the
number of columns in the array (for <em>mode</em> = vector), then an asterisk
with no numeric values means all indices from 1 to N. A leading
asterisk means all indices from 1 to n (inclusive). A trailing
asterisk means all indices from n to N (inclusive). A middle asterisk
means all indices from m to n (inclusive).</p>
<p>Using a wildcard is the same as if the individual elements of the
vector or columns of the array had been listed one by one. E.g. these
2 fix ave/time commands are equivalent, since the <a class="reference internal" href="compute_rdf.html"><span class="doc">compute rdf</span></a> command creates, in this case, a global array
<p>The <em>Nevery</em>, <em>Nrepeat</em>, and <em>Nfreq</em> arguments specify on what
timesteps the input values will be used in order to contribute to the
average. The final averaged quantities are generated on timesteps
that are a mlutiple of <em>Nfreq</em>. The average is over <em>Nrepeat</em>
quantities, computed in the preceding portion of the simulation every
<em>Nevery</em> timesteps. <em>Nfreq</em> must be a multiple of <em>Nevery</em> and
<em>Nevery</em> must be non-zero even if <em>Nrepeat</em> is 1. Also, the timesteps
contributing to the average value cannot overlap,
i.e. Nrepeat*Nevery can not exceed Nfreq.</p>
<p>For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then values on
timesteps 90,92,94,96,98,100 will be used to compute the final average
on timestep 100. Similarly for timesteps 190,192,194,196,198,200 on
timestep 200, etc. If Nrepeat=1 and Nfreq = 100, then no time
averaging is done; values are simply generated on timesteps
100,200,etc.</p>
<hr class="docutils" />
-<p>If a value begins with “<a href="#id1"><span class="problematic" id="id2">c_</span></a>”, a compute ID must follow which has been
+<p>If a value begins with “c_”, a compute ID must follow which has been
previously defined in the input script. If <em>mode</em> = scalar, then if
no bracketed term is appended, the global scalar calculated by the
compute is used. If a bracketed term is appended, the Ith element of
the global vector calculated by the compute is used. If <em>mode</em> =
vector, then if no bracketed term is appended, the global vector
calculated by the compute is used. If a bracketed term is appended,
the Ith column of the global array calculated by the compute is used.
See the discussion above for how I can be specified with a wildcard
asterisk to effectively specify multiple values.</p>
<p>Note that there is a <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a> command
which can sum per-atom quantities into a global scalar or vector which
can thus be accessed by fix ave/time. Or it can be a compute defined
not in your input script, but by <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a> or other fixes such as <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> or <a class="reference internal" href="fix_temp_rescale.html"><span class="doc">fix temp/rescale</span></a>. See
the doc pages for these commands which give the IDs of these computes.
Users can also write code for their own compute styles and <a class="reference internal" href="Section_modify.html"><span class="doc">add them to LAMMPS</span></a>.</p>
-<p>If a value begins with “<a href="#id3"><span class="problematic" id="id4">f_</span></a>”, a fix ID must follow which has been
+<p>If a value begins with “f_”, a fix ID must follow which has been
previously defined in the input script. If <em>mode</em> = scalar, then if
no bracketed term is appended, the global scalar calculated by the fix
is used. If a bracketed term is appended, the Ith element of the
global vector calculated by the fix is used. If <em>mode</em> = vector, then
if no bracketed term is appended, the global vector calculated by the
fix is used. If a bracketed term is appended, the Ith column of the
global array calculated by the fix is used. See the discussion above
for how I can be specified with a wildcard asterisk to effectively
specify multiple values.</p>
<p>Note that some fixes only produce their values on certain timesteps,
which must be compatible with <em>Nevery</em>, else an error will result.
Users can also write code for their own fix styles and <a class="reference internal" href="Section_modify.html"><span class="doc">add them to LAMMPS</span></a>.</p>
-<p>If a value begins with “<a href="#id5"><span class="problematic" id="id6">v_</span></a>”, a variable name must follow which has
+<p>If a value begins with “v_”, a variable name must follow which has
been previously defined in the input script. If <em>mode</em> = scalar, then
only equal-style or vector-style variables can be used, which both
produce global values. In this mode, a vector-style variable requires
a bracketed term to specify the Ith element of the vector calculated
by the variable. If <em>mode</em> = vector, then only a vector-style
variable can be used, without a bracketed term. See the
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command for details.</p>
<p>Note that variables of style <em>equal</em> and <em>vector</em> define a formula
which can reference individual atom properties or thermodynamic
keywords, or they can invoke other computes, fixes, or variables when
they are evaluated, so this is a very general means of specifying
quantities to time average.</p>
<hr class="docutils" />
<p>Additional optional keywords also affect the operation of this fix.</p>
<p>If the <em>mode</em> keyword is set to <em>scalar</em>, then all input values must
be global scalars, or elements of global vectors. If the <em>mode</em>
keyword is set to <em>vector</em>, then all input values must be global
vectors, or columns of global arrays. They can also be global arrays,
which are converted into a series of global vectors (one per column),
as explained above.</p>
<p>The <em>ave</em> keyword determines how the values produced every <em>Nfreq</em>
steps are averaged with values produced on previous steps that were
multiples of <em>Nfreq</em>, before they are accessed by another output
command or written to a file.</p>
<p>If the <em>ave</em> setting is <em>one</em>, then the values produced on timesteps
that are multiples of <em>Nfreq</em> are independent of each other; they are
output as-is without further averaging.</p>
<p>If the <em>ave</em> setting is <em>running</em>, then the values produced on
timesteps that are multiples of <em>Nfreq</em> are summed and averaged in a
cummulative sense before being output. Each output value is thus the
average of the value produced on that timestep with all preceding
values. This running average begins when the fix is defined; it can
only be restarted by deleting the fix via the <a class="reference internal" href="unfix.html"><span class="doc">unfix</span></a>
command, or by re-defining the fix by re-specifying it.</p>
<p>If the <em>ave</em> setting is <em>window</em>, then the values produced on
timesteps that are multiples of <em>Nfreq</em> are summed and averaged within
a moving “window” of time, so that the last M values are used to
produce the output. E.g. if M = 3 and Nfreq = 1000, then the output
on step 10000 will be the average of the individual values on steps
8000,9000,10000. Outputs on early steps will average over less than M
values if they are not available.</p>
<p>The <em>start</em> keyword specifies what timestep averaging will begin on.
The default is step 0. Often input values can be 0.0 at time 0, so
setting <em>start</em> to a larger value can avoid including a 0.0 in a
running or windowed average.</p>
<p>The <em>off</em> keyword can be used to flag any of the input values. If a
value is flagged, it will not be time averaged. Instead the most
recent input value will always be stored and output. This is useful
if one of more of the inputs produced by a compute or fix or variable
are effectively constant or are simply current values. E.g. they are
being written to a file with other time-averaged values for purposes
of creating well-formatted output.</p>
<p>The <em>file</em> keyword allows a filename to be specified. Every <em>Nfreq</em>
steps, one quantity or vector of quantities is written to the file for
each input value specified in the fix ave/time command. For <em>mode</em> =
scalar, this means a single line is written each time output is
performed. Thus the file ends up to be a series of lines, i.e. one
column of numbers for each input value. For <em>mode</em> = vector, an array
of numbers is written each time output is performed. The number of
rows is the length of the input vectors, and the number of columns is
the number of values. Thus the file ends up to be a series of these
array sections.</p>
<p>The <em>overwrite</em> keyword will continuously overwrite the output file
with the latest output, so that it only contains one timestep worth of
output. This option can only be used with the <em>ave running</em> setting.</p>
<p>The <em>format</em> keyword sets the numeric format of each value when it is
printed to a file via the <em>file</em> keyword. Note that all values are
floating point quantities. The default format is %g. You can specify
a higher precision if desired, e.g. %20.16g.</p>
<p>The <em>title1</em> and <em>title2</em> and <em>title3</em> keywords allow specification of
the strings that will be printed as the first 2 or 3 lines of the
output file, assuming the <em>file</em> keyword was used. LAMMPS uses
default values for each of these, so they do not need to be specified.</p>
<p>By default, these header lines are as follows for <em>mode</em> = scalar:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># Time-averaged data for fix ID</span>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>This fix produces a global scalar or global vector or global array
which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The values can only be
accessed on timesteps that are multiples of <em>Nfreq</em> since that is when
averaging is performed.</p>
<p>A scalar is produced if only a single input value is averaged and
<em>mode</em> = scalar. A vector is produced if multiple input values are
averaged for <em>mode</em> = scalar, or a single input value for <em>mode</em> =
vector. In the first case, the length of the vector is the number of
inputs. In the second case, the length of the vector is the same as
the length of the input vector. An array is produced if multiple
input values are averaged and <em>mode</em> = vector. The global array has #
of rows = length of the input vectors and # of columns = number of
inputs.</p>
<p>If the fix prouduces a scalar or vector, then the scalar and each
element of the vector can be either “intensive” or “extensive”,
depending on whether the values contributing to the scalar or vector
element are “intensive” or “extensive”. If the fix produces an array,
then all elements in the array must be the same, either “intensive” or
“extensive”. If a compute or fix provides the value being time
averaged, then the compute or fix determines whether the value is
intensive or extensive; see the doc page for that compute or fix for
further info. Values produced by a variable are treated as intensive.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Load-balancing is typically only useful if the particles in the
simulation box have a spatially-varying density distribution. E.g. a
model of a vapor/liquid interface, or a solid with an irregular-shaped
geometry containing void regions. In this case, the LAMMPS default of
dividing the simulation box volume into a regular-spaced grid of 3d
bricks, with one equal-volume sub-domain per processor, may assign
very different numbers of particles per processor. This can lead to
poor performance when the simulation is run in parallel.</p>
<p>Note that the <a class="reference internal" href="processors.html"><span class="doc">processors</span></a> command allows some control
over how the box volume is split across processors. Specifically, for
a Px by Py by Pz grid of processors, it allows choice of Px, Py, and
Pz, subject to the constraint that Px * Py * Pz = P, the total number
of processors. This is sufficient to achieve good load-balance for
some problems on some processor counts. However, all the processor
sub-domains will still have the same shape and same volume.</p>
<p>On a particular timestep, a load-balancing operation is only performed
if the current “imbalance factor” in particles owned by each processor
exceeds the specified <em>thresh</em> parameter. The imbalance factor is
defined as the maximum number of particles owned by any processor,
divided by the average number of particles per processor. Thus an
imbalance factor of 1.0 is perfect balance.</p>
<p>As an example, for 10000 particles running on 10 processors, if the
most heavily loaded processor has 1200 particles, then the factor is
1.2, meaning there is a 20% imbalance. Note that re-balances can be
forced even if the current balance is perfect (1.0) be specifying a
<em>thresh</em> < 1.0.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">This command attempts to minimize the imbalance factor, as
defined above. But depending on the method a perfect balance (1.0)
may not be achieved. For example, “grid” methods (defined below) that
create a logical 3d grid cannot achieve perfect balance for many
irregular distributions of particles. Likewise, if a portion of the
system is a perfect lattice, e.g. the initial system is generated by
the <a class="reference internal" href="create_atoms.html"><span class="doc">create_atoms</span></a> command, then “grid” methods may
be unable to achieve exact balance. This is because entire lattice
planes will be owned or not owned by a single processor.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The imbalance factor is also an estimate of the maximum speed-up
you can hope to achieve by running a perfectly balanced simulation
versus an imbalanced one. In the example above, the 10000 particle
simulation could run up to 20% faster if it were perfectly balanced,
versus when imbalanced. However, computational cost is not strictly
proportional to particle count, and changing the relative size and
shape of processor sub-domains may lead to additional computational
and communication overheads, e.g. in the PPPM solver used via the
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command. Thus you should benchmark
the run times of a simulation before and after balancing.</p>
</div>
<hr class="docutils" />
<p>The method used to perform a load balance is specified by one of the
listed styles, which are described in detail below. There are 2 kinds
of styles.</p>
<p>The <em>shift</em> style is a “grid” method which produces a logical 3d grid
of processors. It operates 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 following 2d diagram where
processor sub-domains are shown and atoms are colored by the processor
that owns them. The leftmost diagram is the default partitioning of
the simulation box across processors (one sub-box for each of 16
processors); the middle diagram is after a “grid” method has been
applied.</p>
<a class=""
data-lightbox="group-default"
href="_images/balance_uniform.jpg"
title=""
data-title=""
><img src="_images/balance_uniform.jpg"
class="align-center"
width="25%"
height="auto"
alt=""/>
</a><a class=""
data-lightbox="group-default"
href="_images/balance_nonuniform.jpg"
title=""
data-title=""
><img src="_images/balance_nonuniform.jpg"
class="align-center"
width="25%"
height="auto"
alt=""/>
</a><a class=""
data-lightbox="group-default"
href="_images/balance_rcb.jpg"
title=""
data-title=""
><img src="_images/balance_rcb.jpg"
class="align-center"
width="25%"
height="auto"
alt=""/>
</a><p>The <em>rcb</em> style is a “tiling” method which does not produce a logical
3d grid of processors. Rather it tiles the simulation domain with
rectangular sub-boxes of varying size and shape in an irregular
fashion so as to have equal numbers of particles in each sub-box, as
in the rightmost diagram above.</p>
<p>The “grid” methods can be used with either of the
<a class="reference internal" href="comm_style.html"><span class="doc">comm_style</span></a> command options, <em>brick</em> or <em>tiled</em>. The
“tiling” methods can only be used with <a class="reference internal" href="comm_style.html"><span class="doc">comm_style tiled</span></a>.</p>
<p>When a “grid” method is specified, the current domain partitioning can
be either a logical 3d grid or a tiled partitioning. In the former
case, the current logical 3d grid is used as a starting point and
changes are made to improve the imbalance factor. In the latter case,
the tiled partitioning is discarded and a logical 3d grid is created
with uniform spacing in all dimensions. This is the starting point
for the balancing operation.</p>
<p>When a “tiling” method is specified, the current domain partitioning
(“grid” or “tiled”) is ignored, and a new partitioning is computed
from scratch.</p>
<hr class="docutils" />
<p>The <em>group-ID</em> is currently ignored. In the future it may be used to
determine what particles are considered for balancing. Normally it
would only makes sense to use the <em>all</em> group. But in some cases it
may be useful to balance on a subset of the particles, e.g. when
modeling large nanoparticles in a background of small solvent
particles.</p>
<p>The <em>Nfreq</em> setting determines how often a rebalance is performed. If
<em>Nfreq</em> > 0, then rebalancing will occur every <em>Nfreq</em> steps. Each
time a rebalance occurs, a reneighboring is triggered, so <em>Nfreq</em>
should not be too small. If <em>Nfreq</em> = 0, then rebalancing will be
done every time reneighboring normally occurs, as determined by the
the <a class="reference internal" href="neighbor.html"><span class="doc">neighbor</span></a> and <a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify</span></a>
command settings.</p>
<p>On rebalance steps, rebalancing will only be attempted if the current
imbalance factor, as defined above, exceeds the <em>thresh</em> setting.</p>
<hr class="docutils" />
<p>The <em>shift</em> style invokes a “grid” method for balancing, as described
above. It changes the positions of cutting planes between processors
in an iterative fashion, seeking to reduce the imbalance factor.</p>
<p>The <em>dimstr</em> argument is a string of characters, each of which must be
an “x” or “y” or “z”. Eacn character can appear zero or one time,
since there is no advantage to balancing on a dimension more than
once. You should normally only list dimensions where you expect there
to be a density variation in the particles.</p>
<p>Balancing proceeds by adjusting the cutting planes in each of the
dimensions listed in <em>dimstr</em>, one dimension at a time. For a single
dimension, the balancing operation (described below) is iterated on up
to <em>Niter</em> times. After each dimension finishes, the imbalance factor
is re-computed, and the balancing operation halts if the <em>stopthresh</em>
criterion is met.</p>
<p>A rebalance operation in a single dimension is performed using a
density-dependent recursive multisectioning algorithm, where the
position of each cutting plane (line in 2d) in the dimension is
adjusted independently. This is similar to a recursive bisectioning
for a single value, except that the bounds used for each bisectioning
take advantage of information from neighboring cuts if possible, as
well as counts of particles at the bounds on either side of each cuts,
which themselves were cuts in previous iterations. The latter is used
to infer a density of pariticles near each of the current cuts. At
each iteration, the count of particles on either side of each plane is
tallied. If the counts do not match the target value for the plane,
the position of the cut is adjusted based on the local density. The
low and high bounds are adjusted on each iteration, using new count
information, so that they become closer together over time. Thus as
the recursion progresses, the count of particles on either side of the
plane gets closer to the target value.</p>
<p>The density-dependent part of this algorithm is often an advantage
when you rebalance a system that is already nearly balanced. It
typically converges more quickly than the geometric bisectioning
algorithm used by the <a class="reference internal" href="balance.html"><span class="doc">balance</span></a> command. However, if can
be a disadvantage if you attempt to rebalance a system that is far
from balanced, and converge more slowly. In this case you probably
want to use the <a class="reference internal" href="balance.html"><span class="doc">balance</span></a> command before starting a run,
so that you begin the run with a balanced system.</p>
<p>Once the rebalancing is complete and final processor sub-domains
assigned, particles migrate to their new owning processor as part of
the normal reneighboring procedure.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">At each rebalance operation, the bisectioning for each cutting
plane (line in 2d) typcially starts with low and high bounds separated
by the extent of a processor’s sub-domain in one dimension. The size
of this bracketing region shrinks based on the local density, as
described above, which should typically be 1/2 or more every
iteration. Thus if <em>Niter</em> is specified as 10, the cutting plane will
typically be positioned to better than 1 part in 1000 accuracy
(relative to the perfect target position). For <em>Niter</em> = 20, it will
be accurate to better than 1 part in a million. Thus there is no need
to set <em>Niter</em> to a large value. This is especially true if you are
rebalancing often enough that each time you expect only an incremental
adjustement in the cutting planes is necessary. LAMMPS will check if
the threshold accuracy is reached (in a dimension) is less iterations
than <em>Niter</em> and exit early.</p>
</div>
<hr class="docutils" />
<p>The <em>rcb</em> style invokes a “tiled” method for balancing, as described
above. It performs a recursive coordinate bisectioning (RCB) of the
simulation domain. The basic idea is as follows.</p>
<p>The simulation domain is cut into 2 boxes by an axis-aligned cut in
the longest dimension, leaving one new box on either side of the cut.
All the processors are also partitioned into 2 groups, half assigned
to the box on the lower side of the cut, and half to the box on the
upper side. (If the processor count is odd, one side gets an extra
processor.) The cut is positioned so that the number of atoms in the
lower box is exactly the number that the processors assigned to that
box should own for load balance to be perfect. This also makes load
balance for the upper box perfect. The positioning is done
iteratively, by a bisectioning method. Note that counting atoms on
either side of the cut requires communication between all processors
at each iteration.</p>
<p>That is the procedure for the first cut. Subsequent cuts are made
recursively, in exactly the same manner. The subset of processors
assigned to each box make a new cut in the longest dimension of that
box, splitting the box, the subset of processsors, and the atoms in
the box in two. The recursion continues until every processor is
assigned a sub-box of the entire simulation domain, and owns the atoms
in that sub-box.</p>
<hr class="docutils" />
<p>The <em>out</em> keyword writes a text file to the specified <em>filename</em> with
the results of each rebalancing operation. The file contains the
bounds of the sub-domain for each processor after the balancing
operation completes. The format of the file is compatible with the
<a class="reference external" href="pizza">Pizza.py</a> <em>mdump</em> tool which has support for manipulating and
visualizing mesh files. An example is shown here for a balancing by 4
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>This fix computes a global scalar which is the imbalance factor
after the most recent rebalance and a global vector of length 3 with
additional information about the most recent rebalancing. The 3
values in the vector are as follows:</p>
<ul class="simple">
<li>1 = max # of particles per processor</li>
<li>2 = total # iterations performed in last rebalance</li>
<li>3 = imbalance factor right before the last rebalance was performed</li>
</ul>
<p>As explained above, the imbalance factor is the ratio of the maximum
number of particles on any processor to the average number of
particles per processor.</p>
<p>These quantities can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar and vector values
calculated by this fix are “intensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>For 2d simulations, a “z” cannot appear in <em>dimstr</em> for the <em>shift</em>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Break bonds between pairs of atoms as a simulation runs according to
specified criteria. This can be used to model the dissolution of a
polymer network due to stretching of the simulation box or other
deformations. In this context, a bond means an interaction between a
pair of atoms computed by the <a class="reference internal" href="bond_style.html"><span class="doc">bond_style</span></a> command.
Once the bond is broken it will be permanently deleted, as will all
angle, dihedral, and improper interactions that bond is part of.</p>
<p>This is different than a <a class="reference internal" href="pair_style.html"><span class="doc">pairwise</span></a> bond-order
potential such as Tersoff or AIREBO which infers bonds and many-body
interactions based on the current geometry of a small cluster of atoms
and effectively creates and destroys bonds and higher-order many-body
interactions from timestep to timestep as atoms move.</p>
<p>A check for possible bond breakage is performed every <em>Nevery</em>
timesteps. If two bonded atoms I,J are further than a distance <em>Rmax</em>
of each other, if the bond is of type <em>bondtype</em>, and if both I and J
are in the specified fix group, then I,J is labeled as a “possible”
bond to break.</p>
<p>If several bonds involving an atom are stretched, it may have multiple
possible bonds to break. Every atom checks its list of possible bonds
to break and labels the longest such bond as its “sole” bond to break.
After this is done, if atom I is bonded to atom J in its sole bond,
and atom J is bonded to atom I in its sole bond, then the I,J bond is
“eligible” to be broken.</p>
<p>Note that these rules mean an atom will only be part of at most one
broken bond on a given timestep. It also means that if atom I chooses
atom J as its sole partner, but atom J chooses atom K is its sole
partner (due to Rjk > Rij), then this means atom I will not be part of
a broken bond on this timestep, even if it has other possible bond
partners.</p>
<p>The <em>prob</em> keyword can effect whether an eligible bond is actually
broken. The <em>fraction</em> setting must be a value between 0.0 and 1.0.
A uniform random number between 0.0 and 1.0 is generated and the
eligible bond is only broken if the random number < fraction.</p>
<p>When a bond is broken, data structures within LAMMPS that store bond
topology are updated to reflect the breakage. Likewise, if the bond
is part of a 3-body (angle) or 4-body (dihedral, improper)
interaction, that interaction is removed as well. These changes
typically affect pairwise interactions between atoms that used to be
part of bonds, angles, etc.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">One data structure that is not updated when a bond breaks are
the molecule IDs stored by each atom. Even though one molecule
becomes two moleclues due to the broken bond, all atoms in both new
moleclues retain their original molecule IDs.</p>
</div>
<p>Computationally, each timestep this fix operates, it loops over all
the bonds in the system and computes distances between pairs of bonded
atoms. It also communicates between neighboring processors to
coordinate which bonds are broken. Moreover, if any bonds are broken,
neighbor lists must be immediately updated on the same timestep. This
is to insure that any pairwise interactions that should be turned “on”
due to a bond breaking, because they are no longer excluded by the
presence of the bond and the settings of the
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command, will be immediately
recognized. All of these operations increase the cost of a timestep.
Thus you should be cautious about invoking this fix too frequently.</p>
<p>You can dump out snapshots of the current bond topology via the <a class="reference internal" href="dump.html"><span class="doc">dump local</span></a> command.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Breaking a bond typically alters the energy of a system. You
should be careful not to choose bond breaking criteria that induce a
dramatic change in energy. For example, if you define a very stiff
harmonic bond and break it when 2 atoms are separated by a distance
far from the equilibribum bond length, then the 2 atoms will be
dramatically released when the bond is broken. More generally, you
may need to thermostat your system to compensate for energy changes
resulting from broken bonds (and angles, dihedrals, impropers).</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>This fix computes two statistics which it stores in a global vector of
length 2, which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The vector values calculated
by this fix are “intensive”.</p>
<p>These are the 2 quantities:</p>
<ul class="simple">
<li><ol class="first arabic">
<li># of bonds broken on the most recent breakage timestep</li>
</ol>
</li>
<li><ol class="first arabic" start="2">
<li>cummulative # of bonds broken</li>
</ol>
</li>
</ul>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the MC package. It is only enabled if LAMMPS was
built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Note that even if your simulation starts with no bonds, you must
define a <a class="reference internal" href="bond_style.html"><span class="doc">bond_style</span></a> and use the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command to specify coefficients for the
<em>bondtype</em>. Similarly, if new atom types are specified by the
<em>iparam</em> or <em>jparam</em> keywords, they must be within the range of atom
types allowed by the simulation and pairwise coefficients must be
specified for the new types.</p>
<p>Computationally, each timestep this fix operates, it loops over
neighbor lists and computes distances between pairs of atoms in the
list. It also communicates between neighboring processors to
coordinate which bonds are created. Moreover, if any bonds are
created, neighbor lists must be immediately updated on the same
timestep. This is to insure that any pairwise interactions that
should be turned “off” due to a bond creation, because they are now
excluded by the presence of the bond and the settings of the
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command, will be immediately
recognized. All of these operations increase the cost of a timestep.
Thus you should be cautious about invoking this fix too frequently.</p>
<p>You can dump out snapshots of the current bond topology via the <a class="reference internal" href="dump.html"><span class="doc">dump local</span></a> command.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Creating a bond typically alters the energy of a system. You
should be careful not to choose bond creation criteria that induce a
dramatic change in energy. For example, if you define a very stiff
harmonic bond and create it when 2 atoms are separated by a distance
far from the equilibribum bond length, then the 2 atoms will oscillate
dramatically when the bond is formed. More generally, you may need to
thermostat your system to compensate for energy changes resulting from
created bonds (and angles, dihedrals, impropers).</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>This fix computes two statistics which it stores in a global vector of
length 2, which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The vector values calculated
by this fix are “intensive”.</p>
<p>These are the 2 quantities:</p>
<ul class="simple">
<li><ol class="first arabic">
<li># of bonds created on the most recent creation timestep</li>
</ol>
</li>
<li><ol class="first arabic" start="2">
<li>cummulative # of bonds created</li>
</ol>
</li>
</ul>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the MC package. It is only enabled if LAMMPS was
built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>See the <a class="reference internal" href="compute_temp.html"><span class="doc">compute temp</span></a> command for details. Note
that the ID of the new compute is the fix-ID with underscore + “temp”
appended and the group for the new compute is “all”, so that the
temperature of the entire system is used.</p>
<p>Note that this is NOT the compute used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>.
This means you can change the attributes of this fix’s temperature
(e.g. its degrees-of-freedom) via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
during thermodyanmic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> will have no
effect on this fix.</p>
<hr class="docutils" />
<p><strong>Restart, fix_modify, thermo output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Because the state of the random number generator
is not saved in restart files, this means you cannot do “exact”
restarts with this fix, where the simulation continues on the same as
if no restart had taken place. However, in a statistical sense, a
restarted simulation should produce the same behavior. Also note that
each processor generates possible swaps independently of other
processors. Thus if you repeat the same simulation on a different number
of processors, the specific swaps performed will be different.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to assign a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> you have
defined to this fix which will be used to compute the temperature for
the Boltzmann criterion.</p>
<p>This fix computes two statistical quantities as a global 2-vector of
output, which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The first component of the
vector is the cummulative number of swaps performed by all processors.
The second component of the vector is the cummulative number of swaps
attempted (whether accepted or rejected). Note that a swap “attempt”
only occurs when swap partners meeting the criteria described above
are found on a particular timestep. The vector values calculated by
this fix are “intensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the MC package. It is only enabled if LAMMPS was
built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The setings of the “special_bond” command must be 0,1,1 in order to
use this fix, which is typical of bead-spring chains with FENE or
harmonic bonds. This means that pairwise interactions between bonded
atoms are turned off, but are turned on between atoms two or three
hops away along the chain backbone.</p>
<p>Currently, energy changes in dihedral and improper interactions due to
a bond swap are not considered. Thus a simulation that uses this fix
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>box/relax = style name of this fix command</li>
</ul>
<pre class="literal-block">
one or more keyword value pairs may be appended
keyword = <em>iso</em> or <em>aniso</em> or <em>tri</em> or <em>x</em> or <em>y</em> or <em>z</em> or <em>xy</em> or <em>yz</em> or <em>xz</em> or <em>couple</em> or <em>nreset</em> or <em>vmax</em> or <em>dilate</em> or <em>scaleyz</em> or <em>scalexz</em> or <em>scalexy</em> or <em>fixedpoint</em>
<em>iso</em> or <em>aniso</em> or <em>tri</em> value = Ptarget = desired pressure (pressure units)
<em>x</em> or <em>y</em> or <em>z</em> or <em>xy</em> or <em>yz</em> or <em>xz</em> value = Ptarget = desired pressure (pressure units)
<em>couple</em> = <em>none</em> or <em>xyz</em> or <em>xy</em> or <em>yz</em> or <em>xz</em>
<em>nreset</em> value = reset reference cell every this many minimizer iterations
<em>vmax</em> value = fraction = max allowed volume change in one iteration
<em>dilate</em> value = <em>all</em> or <em>partial</em>
<em>scaleyz</em> value = <em>yes</em> or <em>no</em> = scale yz with lz
<em>scalexz</em> value = <em>yes</em> or <em>no</em> = scale xz with lz
<em>scalexy</em> value = <em>yes</em> or <em>no</em> = scale xy with ly
<em>fixedpoint</em> values = x y z
x,y,z = perform relaxation dilation/contraction around this point (distance units)
<p>where <strong>I</strong> is the identity matrix, <strong>h</strong>_0 is the box dimension tensor of
the reference cell, and <strong>h</strong>_0<em>d</em> is the diagonal part of
<strong>h</strong>_0. <strong>S</strong>_<em>t</em> is a symmetric stress tensor that is chosen by LAMMPS
so that the upper-triangular components of <strong>P</strong> equal the stress tensor
specified by the user.</p>
<p>This equation only applies when the box dimensions are equal to those
of the reference dimensions. If this is not the case, then the
converged stress tensor will not equal that specified by the user. We
can resolve this problem by periodically resetting the reference
dimensions. The keyword <em>nreset_ref</em> controls how often this is done.
If this keyword is not used, or is given a value of zero, then the
reference dimensions are set to those of the initial simulation domain
and are never changed. A value of <em>nstep</em> means that every <em>nstep</em>
minimization steps, the reference dimensions are set to those of the
current simulation domain. Note that resetting the reference
dimensions changes the objective function and gradients, which
sometimes causes the minimization to fail. This can be resolved by
changing the value of <em>nreset</em>, or simply continuing the minimization
from a restart file.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">As normally computed, pressure includes a kinetic- energy or
temperature-dependent component; see the <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> command. However, atom velocities are
ignored during a minimization, and the applied pressure(s) specified
with this command are assumed to only be the virial component of the
pressure (the non-kinetic portion). Thus if atoms have a non-zero
temperature and you print the usual thermodynamic pressure, it may not
appear the system is converging to your specified pressure. The
solution for this is to either (a) zero the velocities of all atoms
before performing the minimization, or (b) make sure you are
monitoring the pressure without its kinetic component. The latter can
be done by outputting the pressure from the fix this command creates
(see below) or a pressure fix you define yourself.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Because pressure is often a very sensitive function of volume,
it can be difficult for the minimizer to equilibrate the system the
desired pressure with high precision, particularly for solids. Some
techniques that seem to help are (a) use the “min_modify line
quadratic” option when minimizing with box relaxations, (b) minimize
several times in succession if need be, to drive the pressure closer
to the target pressure, (c) relax the atom positions before relaxing
the box, and (d) relax the box to the target hydrostatic pressure
before relaxing to a target shear stress state. Also note that some
systems (e.g. liquids) will not sustain a non-hydrostatic applied
pressure, which means the minimizer will not converge.</p>
</div>
<hr class="docutils" />
<p>This fix computes a temperature and pressure each timestep. The
temperature is used to compute the kinetic contribution to the
pressure, even though this is subsequently ignored by default. To do
this, the fix creates its own computes of style “temp” and “pressure”,
<p>See the <a class="reference internal" href="compute_temp.html"><span class="doc">compute temp</span></a> and <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + “temp” or fix_ID
+ underscore + “press”, and the group for the new computes is the same
as the fix group. Also note that the pressure compute does not
include a kinetic component.</p>
<p>Note that these are NOT the computes used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>
and <em>thermo_press</em>. This means you can change the attributes of this
fix’s temperature or pressure via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
or pressure during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> or
<em>thermo_press</em> will have no effect on this fix.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> and <em>press</em> options are
supported by this fix. You can use them to assign a
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> you have defined to this fix which will be used
in its temperature and pressure calculation, as described above. Note
that as described above, if you assign a pressure compute to this fix
that includes a kinetic energy component it will affect the
minimization, most likely in an undesirable way.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If both the <em>temp</em> and <em>press</em> keywords are used in a single
thermo_modify command (or in two separate commands), then the order in
which the keywords are specified is important. Note that a <a class="reference internal" href="compute_pressure.html"><span class="doc">pressure compute</span></a> defines its own temperature compute as
an argument when it is specified. The <em>temp</em> keyword will override
this (for the pressure compute being used by fix npt), but only if the
<em>temp</em> keyword comes after the <em>press</em> keyword. If the <em>temp</em> keyword
comes before the <em>press</em> keyword, then the new pressure compute
specified by the <em>press</em> keyword will be unaffected by the <em>temp</em>
setting.</p>
</div>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
pressure-volume energy, plus the strain energy, if it exists.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is given
by the energy expression shown above. The energy values reported
at the end of a minimization run under “Minimization stats” include
this energy, and so differ from what LAMMPS normally reports as
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the current status of the colvars module into
<a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. This is in addition to the text
mode status file that is written by the colvars module itself and the
kind of information in both files is identical.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change from the biasing force added by the fix
to the system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
cummulative energy change due to this fix. The scalar value
calculated by this fix is “extensive”.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-COLVARS package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>There can only be one colvars fix active at a time. Since the interface
communicates only the minimum amount of information and colvars module
itself can handle an arbitrary number of collective variables, this is
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where <em>tau</em> = <em>Nevery</em> * <em>timestep</em> is the time interval between updates,
and the subscripted variables indicate the values of <em>c</em> and <em>e</em> at
successive updates.</p>
<p>From the first equation, it is clear that if the three gain values
<em>Kp</em>, <em>Ki</em>, <em>Kd</em> are dimensionless constants, then <em>alpha</em> must have
units of [unit <em>cvar</em>]/[unit <em>pvar</em>]/[unit time] e.g. [ eV/K/ps
]. The advantage of this unit scheme is that the value of the
constants should be invariant under a change of either the MD timestep
size or the value of <em>Nevery</em>. Similarly, if the LAMMPS <a class="reference internal" href="units.html"><span class="doc">unit style</span></a> is changed, it should only be necessary to change
the value of <em>alpha</em> to reflect this, while leaving <em>Kp</em>, <em>Ki</em>, and
<em>Kd</em> unaltered.</p>
<p>When choosing the values of the four constants, it is best to first
pick a value and sign for <em>alpha</em> that is consistent with the
magnitudes and signs of <em>pvar</em> and <em>cvar</em>. The magnitude of <em>Kp</em>
should then be tested over a large positive range keeping <em>Ki</em>=<em>Kd</em>=0.
A good value for <em>Kp</em> will produce a fast reponse in <em>pvar</em>, without
overshooting the <em>setpoint</em>. For many applications, proportional
feedback is sufficient, and so <em>Ki</em>=<em>Kd</em>=0 can be used. In cases where
there is a substantial lag time in the response of <em>pvar</em> to a change
in <em>cvar</em>, this can be counteracted by increasing <em>Kd</em>. In situations
where <em>pvar</em> plateaus without reaching <em>setpoint</em>, this can be
counteracted by increasing <em>Ki</em>. In the language of Charles Dickens,
<em>Kp</em> represents the error of the present, <em>Ki</em> the error of the past,
and <em>Kd</em> the error yet to come.</p>
<p>Because this fix updates <em>cvar</em>, but does not initialize its value,
the initial value is that assigned by the user in the input script via
the <a class="reference internal" href="variable.html"><span class="doc">internal-style variable</span></a> command. This value is
used (by the other LAMMPS command that used the variable) until this
fix performs its first update of <em>cvar</em> after <em>Nevery</em> timesteps. On
the first update, the value of the derivative term is set to zero,
because the value of <em>e_n-1</em> is not yet defined.</p>
<hr class="docutils" />
<p>The process variable <em>pvar</em> can be specified as the output of a
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> or <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> or the evaluation of a
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a>. In each case, the compute, fix, or variable
must produce a global quantity, not a per-atom or local quantity.</p>
-<p>If <em>pvar</em> begins with “<a href="#id1"><span class="problematic" id="id2">c_</span></a>”, a compute ID must follow which has been
+<p>If <em>pvar</em> begins with “c_”, a compute ID must follow which has been
previously defined in the input script and which generates a global
scalar or vector. See the individual <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> doc page
for details. If no bracketed integer is appended, the scalar
calculated by the compute is used. If a bracketed integer is
appended, the Ith value of the vector calculated by the compute is
used. Users can also write code for their own compute styles and <a class="reference internal" href="Section_modify.html"><span class="doc">add them to LAMMPS</span></a>.</p>
-<p>If <em>pvar</em> begins with “<a href="#id3"><span class="problematic" id="id4">f_</span></a>”, a fix ID must follow which has been
+<p>If <em>pvar</em> begins with “f_”, a fix ID must follow which has been
previously defined in the input script and which generates a global
scalar or vector. See the individual <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> doc page for
details. Note that some fixes only produce their values on certain
timesteps, which must be compatible with when fix controller
references the values, or else an error results. If no bracketed integer
is appended, the scalar calculated by the fix is used. If a bracketed
integer is appended, the Ith value of the vector calculated by the fix
is used. Users can also write code for their own fix style and <a class="reference internal" href="Section_modify.html"><span class="doc">add them to LAMMPS</span></a>.</p>
-<p>If <em>pvar</em> begins with “<a href="#id5"><span class="problematic" id="id6">v_</span></a>”, a variable name must follow which has been
+<p>If <em>pvar</em> begins with “v_”, a variable name must follow which has been
previously defined in the input script. Only equal-style variables
can be referenced. See the <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command for
details. Note that variables of style <em>equal</em> define a formula which
can reference individual atom properties or thermodynamic keywords, or
they can invoke other computes, fixes, or variables when they are
evaluated, so this is a very general means of specifying the process
variable.</p>
<p>The target value <em>setpoint</em> for the process variable must be a numeric
value, in whatever units <em>pvar</em> is defined for.</p>
<p>The control variable <em>cvar</em> must be the name of an <a class="reference internal" href="variable.html"><span class="doc">internal-style variable</span></a> previously defined in the input script. Note
-that it is not specified with a “<a href="#id7"><span class="problematic" id="id8">v_</span></a>” prefix, just the name of the
+that it is not specified with a “v_” prefix, just the name of the
variable. It must be an internal-style variable, because this fix
updates its value directly. Note that other commands can use an
equal-style versus internal-style variable interchangeably.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>Currenlty, no information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>This fix produces a global vector with 3 values which can be accessed
by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The values
can be accessed on any timestep, though they are only updated on
timesteps that are a multiple of <em>Nevery</em>.</p>
<p>The three values are the most recent updates made to the control
variable by each of the 3 terms in the PID equation above. The first
value is the proportional term, the second is the integral term, the
third is the derivative term.</p>
<p>The units of the vector values will be whatever units the control
variable is in. The vector values calculated by this fix are
“extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
style = <em>final</em> or <em>delta</em> or <em>scale</em> or <em>vel</em> or <em>erate</em> or <em>trate</em> or <em>volume</em> or <em>wiggle</em> or <em>variable</em>
<em>final</em> values = lo hi
lo hi = box boundaries at end of run (distance units)
<em>delta</em> values = dlo dhi
dlo dhi = change in box boundaries at end of run (distance units)
<em>scale</em> values = factor
factor = multiplicative factor for change in box length at end of run
<em>vel</em> value = V
V = change box length at this velocity (distance/time units),
effectively an engineering strain rate
<em>erate</em> value = R
R = engineering strain rate (1/time units)
<em>trate</em> value = R
R = true strain rate (1/time units)
<em>volume</em> value = none = adjust this dim to preserve volume of system
<em>wiggle</em> values = A Tp
A = amplitude of oscillation (distance units)
Tp = period of oscillation (time units)
<em>variable</em> values = v_name1 v_name2
v_name1 = variable with name1 for box length change as function of time
v_name2 = variable with name2 for change rate as function of time
<em>xy</em>, <em>xz</em>, <em>yz</em> args = style value
style = <em>final</em> or <em>delta</em> or <em>vel</em> or <em>erate</em> or <em>trate</em> or <em>wiggle</em>
<em>final</em> value = tilt
tilt = tilt factor at end of run (distance units)
<em>delta</em> value = dtilt
dtilt = change in tilt factor at end of run (distance units)
<em>vel</em> value = V
V = change tilt factor at this velocity (distance/time units),
effectively an engineering shear strain rate
<em>erate</em> value = R
R = engineering shear strain rate (1/time units)
<em>trate</em> value = R
R = true shear strain rate (1/time units)
<em>wiggle</em> values = A Tp
A = amplitude of oscillation (distance units)
Tp = period of oscillation (time units)
<em>variable</em> values = v_name1 v_name2
v_name1 = variable with name1 for tilt change as function of time
v_name2 = variable with name2 for change rate as function of time
</pre>
<ul class="simple">
<li>zero or more keyword/value pairs may be appended</li>
<li>keyword = <em>remap</em> or <em>flip</em> or <em>units</em></li>
</ul>
<pre class="literal-block">
<em>remap</em> value = <em>x</em> or <em>v</em> or <em>none</em>
x = remap coords of atoms in group into deforming box
v = remap velocities of all atoms when they cross periodic boundaries
none = no remapping of x or v
<em>flip</em> value = <em>yes</em> or <em>no</em>
allow or disallow box flips when it becomes highly skewed
<em>units</em> value = <em>lattice</em> or <em>box</em>
lattice = distances are defined in lattice units
box = distances are defined in simulation box units
<p>Change the volume and/or shape of the simulation box during a dynamics
run. Orthogonal simulation boxes have 3 adjustable parameters
(x,y,z). Triclinic (non-orthogonal) simulation boxes have 6
adjustable parameters (x,y,z,xy,xz,yz). Any or all of them can be
adjusted independently and simultaneously by this command. This fix
can be used to perform non-equilibrium MD (NEMD) simulations of a
continuously strained system. See the <a class="reference internal" href="fix_nvt_sllod.html"><span class="doc">fix nvt/sllod</span></a> and <a class="reference internal" href="compute_temp_deform.html"><span class="doc">compute temp/deform</span></a> commands for more details.</p>
<p>For the <em>x</em>, <em>y</em>, <em>z</em> parameters, the associated dimension cannot be
shrink-wrapped. For the <em>xy</em>, <em>yz</em>, <em>xz</em> parameters, the associated
2nd dimension cannot be shrink-wrapped. Dimensions not varied by this
command can be periodic or non-periodic. Dimensions corresponding to
unspecified parameters can also be controlled by a <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> or <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> command.</p>
<p>The size and shape of the simulation box at the beginning of the
simulation run were either specified by the
<a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> or <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> or
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command used to setup the simulation
initially if it is the first run, or they are the values from the end
of the previous run. The <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a>, <a class="reference internal" href="read_data.html"><span class="doc">read data</span></a>, and <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands
specify whether the simulation box is orthogonal or non-orthogonal
(triclinic) and explain the meaning of the xy,xz,yz tilt factors. If
fix deform changes the xy,xz,yz tilt factors, then the simulation box
must be triclinic, even if its initial tilt factors are 0.0.</p>
<p>As described below, the desired simulation box size and shape at the
end of the run are determined by the parameters of the fix deform
command. Every Nth timestep during the run, the simulation box is
expanded, contracted, or tilted to ramped values between the initial
and final values.</p>
<hr class="docutils" />
<p>For the <em>x</em>, <em>y</em>, and <em>z</em> parameters, this is the meaning of their
styles and values.</p>
<p>The <em>final</em>, <em>delta</em>, <em>scale</em>, <em>vel</em>, and <em>erate</em> styles all change
the specified dimension of the box via “constant displacement” which
is effectively a “constant engineering strain rate”. This means the
box dimension changes linearly with time from its initial to final
value.</p>
<p>For style <em>final</em>, 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.</p>
<p>For style <em>delta</em>, 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.</p>
<p>For style <em>scale</em>, 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.</p>
<p>For style <em>vel</em>, a velocity at which the box length changes is
specified in units of distance/time. This is effectively a “constant
engineering strain rate”, where rate = V/L0 and L0 is the initial box
length. The distance can be in lattice or box distance units. See
the discussion of the units keyword below. For example, if the
initial box length is 100 Angstroms, and V is 10 Angstroms/psec, then
after 10 psec, the box length will have doubled. After 20 psec, it
will have tripled.</p>
<p>The <em>erate</em> style changes a dimension of the the box at a “constant
engineering strain rate”. The units of the specified strain rate are
1/time. See the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command for the time units
associated with different choices of simulation units,
e.g. picoseconds for “metal” units). Tensile strain is unitless and
is defined as delta/L0, where L0 is the original box length and delta
is the change relative to the original length. The box length L as a
<p>where L0 is its initial length. If the amplitude A is a positive
number the box initially expands, then contracts, etc. If A is
negative then the box initially contracts, then expands, etc. The
amplitude can be in lattice or box distance units. See the discussion
of the units keyword below.</p>
<p>The <em>variable</em> style changes the specified box length dimension by
evaluating a variable, which presumably is a function of time. The
variable with <em>name1</em> must be an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a>
and should calculate a change in box length in units of distance.
Note that this distance is in box units, not lattice units; see the
discussion of the <em>units</em> keyword below. The formula associated with
variable <em>name1</em> can reference the current timestep. Note that it
should return the “change” in box length, not the absolute box length.
This means it should evaluate to 0.0 when invoked on the initial
timestep of the run following the definition of fix deform. It should
evaluate to a value > 0.0 to dilate the box at future times, or a
value < 0.0 to compress the box.</p>
<p>The variable <em>name2</em> must also be an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> and should calculate the rate of box length
change, in units of distance/time, i.e. the time-derivative of the
<em>name1</em> variable. This quantity is used internally by LAMMPS to reset
atom velocities when they cross periodic boundaries. It is computed
internally for the other styles, but you must provide it when using an
arbitrary variable.</p>
<p>Here is an example of using the <em>variable</em> style to perform the same
box deformation as the <em>wiggle</em> style formula listed above, where we
<p>where T0 is its initial value. If the amplitude A is a positive
number the tilt factor initially becomes more positive, then more
negative, etc. If A is negative then the tilt factor initially
becomes more negative, then more positive, etc. The amplitude can be
in lattice or box distance units. See the discussion of the units
keyword below.</p>
<p>The <em>variable</em> style changes the specified tilt factor by evaluating a
variable, which presumably is a function of time. The variable with
<em>name1</em> must be an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> and should
calculate a change in tilt in units of distance. Note that this
distance is in box units, not lattice units; see the discussion of the
<em>units</em> keyword below. The formula associated with variable <em>name1</em>
can reference the current timestep. Note that it should return the
“change” in tilt factor, not the absolute tilt factor. This means it
should evaluate to 0.0 when invoked on the initial timestep of the run
following the definition of fix deform.</p>
<p>The variable <em>name2</em> must also be an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> and should calculate the rate of tilt change,
in units of distance/time, i.e. the time-derivative of the <em>name1</em>
variable. This quantity is used internally by LAMMPS to reset atom
velocities when they cross periodic boundaries. It is computed
internally for the other styles, but you must provide it when using an
arbitrary variable.</p>
<p>Here is an example of using the <em>variable</em> style to perform the same
box deformation as the <em>wiggle</em> style formula listed above, where we
+fix 2 all deform 1 xy variable v_displace v_rate remap v
+</pre>
<hr class="docutils" />
<p>All of the tilt styles change the xy, xz, yz tilt factors during a
simulation. In LAMMPS, tilt factors (xy,xz,yz) for triclinic boxes
are normally bounded by half the distance of the parallel box length.
See the discussion of the <em>flip</em> keyword below, to allow this bound to
be exceeded, if desired.</p>
<p>For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
the xy tilt factor must be between -5 and 5. Similarly, both xz and
yz must be between -(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is
not a limitation, since if the maximum tilt factor is 5 (as in this
example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
... are all equivalent.</p>
<p>To obey this constraint and allow for large shear deformations to be
applied via the <em>xy</em>, <em>xz</em>, or <em>yz</em> parameters, the following
algorithm is used. If <em>prd</em> is the associated parallel box length (10
in the example above), then if the tilt factor exceeds the accepted
range of -5 to 5 during the simulation, then the box is flipped to the
other limit (an equivalent box) and the simulation continues. Thus
for this example, if the initial xy tilt factor was 0.0 and “xy final
100.0” was specified, then during the simulation the xy tilt factor
would increase from 0.0 to 5.0, the box would be flipped so that the
tilt factor becomes -5.0, the tilt factor would increase from -5.0 to
5.0, the box would be flipped again, etc. The flip occurs 10 times
and the final tilt factor at the end of the simulation would be 0.0.
During each flip event, atoms are remapped into the new box in the
appropriate manner.</p>
<p>The one exception to this rule is if the 1st dimension in the tilt
factor (x for xy) is non-periodic. In that case, the limits on the
tilt factor are not enforced, since flipping the box in that dimension
does not change the atom positions due to non-periodicity. In this
mode, if you tilt the system to extreme angles, the simulation will
simply become inefficient due to the highly skewed simulation box.</p>
<hr class="docutils" />
<p>Each time the box size or shape is changed, the <em>remap</em> keyword
determines whether atom positions are remapped to the new box. If
<em>remap</em> is set to <em>x</em> (the default), atoms in the fix group are
remapped; otherwise they are not. Note that their velocities are not
changed, just their positions are altered. If <em>remap</em> is set to <em>v</em>,
then any atom in the fix group that crosses a periodic boundary will
have a delta added to its velocity equal to the difference in
velocities between the lo and hi boundaries. Note that this velocity
difference can include tilt components, e.g. a delta in the x velocity
when an atom crosses the y periodic boundary. If <em>remap</em> is set to
<em>none</em>, then neither of these remappings take place.</p>
<p>Conceptually, setting <em>remap</em> to <em>x</em> forces the atoms to deform via an
affine transformation that exactly matches the box deformation. This
setting is typically appropriate for solids. Note that though the
atoms are effectively “moving” with the box over time, it is not due
to their having a velocity that tracks the box change, but only due to
the remapping. By contrast, setting <em>remap</em> to <em>v</em> is typically
appropriate for fluids, where you want the atoms to respond to the
change in box size/shape on their own and acquire a velocity that
matches the box change, so that their motion will naturally track the
box without explicit remapping of their coordinates.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When non-equilibrium MD (NEMD) simulations are performed using
this fix, the option “remap v” should normally be used. This is
because <a class="reference internal" href="fix_nvt_sllod.html"><span class="doc">fix nvt/sllod</span></a> adjusts the atom positions
and velocities to induce a velocity profile that matches the changing
box size/shape. Thus atom coordinates should NOT be remapped by fix
deform, but velocities SHOULD be when atoms cross periodic boundaries,
since that is consistent with maintaining the velocity profile already
created by fix nvt/sllod. LAMMPS will warn you if the <em>remap</em> setting
is not consistent with fix nvt/sllod.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For non-equilibrium MD (NEMD) simulations using “remap v” it is
usually desirable that the fluid (or flowing material, e.g. granular
particles) stream with a velocity profile consistent with the
deforming box. As mentioned above, using a thermostat such as <a class="reference internal" href="fix_nvt_sllod.html"><span class="doc">fix nvt/sllod</span></a> or <a class="reference internal" href="fix_langevin.html"><span class="doc">fix lavgevin</span></a>
(with a bias provided by <a class="reference internal" href="compute_temp_deform.html"><span class="doc">compute temp/deform</span></a>), will typically accomplish
that. If you do not use a thermostat, then there is no driving force
pushing the atoms to flow in a manner consistent with the deforming
box. E.g. for a shearing system the box deformation velocity may vary
from 0 at the bottom to 10 at the top of the box. But the stream
velocity profile of the atoms may vary from -5 at the bottom to +5 at
the top. You can monitor these effects using the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a>, <a class="reference internal" href="compute_temp_deform.html"><span class="doc">compute temp/deform</span></a>, and <a class="reference internal" href="compute_temp_profile.html"><span class="doc">compute temp/profile</span></a> commands. One way to induce
atoms to stream consistent with the box deformation is to give them an
initial velocity profile, via the <a class="reference internal" href="velocity.html"><span class="doc">velocity ramp</span></a>
command, that matches the box deformation rate. This also typically
helps the system come to equilibrium more quickly, even if a
thermostat is used.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If a <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> is defined for rigid bodies, and
<em>remap</em> is set to <em>x</em>, then the center-of-mass coordinates of rigid
bodies will be remapped to the changing simulation box. This will be
done regardless of whether atoms in the rigid bodies are in the fix
deform group or not. The velocity of the centers of mass are not
remapped even if <em>remap</em> is set to <em>v</em>, since <a class="reference internal" href="fix_nvt_sllod.html"><span class="doc">fix nvt/sllod</span></a> does not currently do anything special
for rigid particles. If you wish to perform a NEMD simulation of
rigid particles, you can either thermostat them independently or
include a background fluid and thermostat the fluid via <a class="reference internal" href="fix_nvt_sllod.html"><span class="doc">fix nvt/sllod</span></a>.</p>
</div>
<p>The <em>flip</em> keyword allows the tilt factors for a triclinic box to
exceed half the distance of the parallel box length, as discussed
above. If the <em>flip</em> value is set to <em>yes</em>, the bound is enforced by
flipping the box when it is exceeded. If the <em>flip</em> value is set to
<em>no</em>, the tilt will continue to change without flipping. Note that if
you apply large deformations, this means the box shape can tilt
dramatically LAMMPS will run less efficiently, due to the large volume
of communication needed to acquire ghost atoms around a processor’s
irregular-shaped sub-domain. For extreme values of tilt, LAMMPS may
also lose atoms and generate an error.</p>
<p>The <em>units</em> keyword determines the meaning of the distance units used
to define various arguments. A <em>box</em> value selects standard distance
units as defined by the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command, e.g. Angstroms for
units = real or metal. A <em>lattice</em> value means the distance units are
in lattice spacings. The <a class="reference internal" href="lattice.html"><span class="doc">lattice</span></a> command must have
been previously used to define the lattice spacing. Note that the
units choice also affects the <em>vel</em> style parameters since it is
defined in terms of distance/time. Also note that the units keyword
does not affect the <em>variable</em> style. You should use the <em>xlat</em>,
<em>ylat</em>, <em>zlat</em> keywords of the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a>
command if you want to include lattice spacings in a variable formula.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>.</p>
<p>This fix can perform deformation over multiple runs, using the <em>start</em>
and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>You cannot apply x, y, or z deformations to a dimension that is
shrink-wrapped via the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> comamnd.</p>
<p>You cannot apply xy, yz, or xz deformations to a 2nd dimension (y in
xy) that is shrink-wrapped via the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> comamnd.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>deposit = style name of this fix command</li>
<li>N = # of atoms or molecules to insert</li>
<li>type = atom type to assign to inserted atoms (offset for moleclue insertion)</li>
<li>M = insert a single atom or molecule every M steps</li>
<li>seed = random # seed (positive integer)</li>
<li>one or more keyword/value pairs may be appended to args</li>
<li>keyword = <em>region</em> or <em>id</em> or <em>global</em> or <em>local</em> or <em>near</em> or <em>gaussian</em> or <em>attempt</em> or <em>rate</em> or <em>vx</em> or <em>vy</em> or <em>vz</em> or <em>mol</em> or <em>rigid</em> or <em>shake</em> or <em>units</em></li>
</ul>
<pre class="literal-block">
<em>region</em> value = region-ID
region-ID = ID of region to use as insertion volume
<em>id</em> value = <em>max</em> or <em>next</em>
max = atom ID for new atom(s) is max ID of all current atoms plus one
next = atom ID for new atom(s) increments by one for every deposition
<em>global</em> values = lo hi
lo,hi = put new atom/molecule a distance lo-hi above all other atoms (distance units)
<em>local</em> values = lo hi delta
lo,hi = put new atom/molecule a distance lo-hi above any nearby atom beneath it (distance units)
delta = lateral distance within which a neighbor is considered "nearby" (distance units)
<em>near</em> value = R
R = only insert atom/molecule if further than R from existing particles (distance units)
<em>gaussian</em> values = xmid ymid zmid sigma
xmid,ymid,zmid = center of the gaussian distribution (distance units)
sigma = width of gaussian distribution (distance units)
<em>attempt</em> value = Q
Q = attempt a single insertion up to Q times
<em>rate</em> value = V
V = z velocity (y in 2d) at which insertion volume moves (velocity units)
<em>vx</em> values = vxlo vxhi
vxlo,vxhi = range of x velocities for inserted atom/molecule (velocity units)
<em>vy</em> values = vylo vyhi
vylo,vyhi = range of y velocities for inserted atom/molecule (velocity units)
<em>vz</em> values = vzlo vzhi
vzlo,vzhi = range of z velocities for inserted atom/molecule (velocity units)
<em>target</em> values = tx ty tz
tx,ty,tz = location of target point (distance units)
<em>mol</em> value = template-ID
template-ID = ID of molecule template specified in a separate <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command
<em>molfrac</em> values = f1 f2 ... fN
f1 to fN = relative probability of creating each of N molecules in template-ID
<em>rigid</em> value = fix-ID
fix-ID = ID of <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid/small</span></a> command
<em>shake</em> value = fix-ID
fix-ID = ID of <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command
<em>units</em> value = <em>lattice</em> or <em>box</em>
lattice = the geometry is defined in lattice units
box = the geometry is defined in simulation box units
<p>The fix deposit command must use the <em>region</em> keyword to define an
insertion volume. The specified region must have been previously
defined with a <a class="reference internal" href="region.html"><span class="doc">region</span></a> command. It must be defined with
side = <em>in</em>.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">LAMMPS checks that the specified region is wholly inside the
simulation box. It can do this correctly for orthonormal simulation
boxes. However for <a class="reference internal" href="Section_howto.html#howto-12"><span class="std std-ref">triclinic boxes</span></a>, it
only tests against the larger orthonormal box that bounds the tilted
simulation box. If the specified region includes volume outside the
tilted box, then an insertion will likely fail, leading to a “lost
atoms” error. Thus for triclinic boxes you should insure the
specified region is wholly inside the simulation box.</p>
</div>
<p>The locations of inserted particles are taken from uniform distributed
random numbers, unless the <em>gaussian</em> keyword is used. Then the
individual coordinates are taken from a gaussian distribution of
width <em>sigma</em> centered on <em>xmid,ymid,zmid</em>.</p>
<p>Individual atoms are inserted, unless the <em>mol</em> keyword is used. It
specifies a <em>template-ID</em> previously defined using the
<a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command, which reads files that define one or
more molecules. The coordinates, atom types, charges, etc, as well as
any bond/angle/etc and special neighbor information for the molecule
can be specified in the molecule file. See the
<a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command for details. The only settings
required to be in each file are the coordinates and types of atoms in
the molecule.</p>
<p>If the molecule template contains more than one molecule, the relative
probability of depositing each molecule can be specified by the
<em>molfrac</em> keyword. N relative probablities, each from 0.0 to 1.0, are
specified, where N is the number of molecules in the template. Each
time a molecule is deposited, a random number is used to sample from
the list of relative probabilities. The N values must sum to 1.0.</p>
<p>If you wish to insert molecules via the <em>mol</em> keyword, that will be
treated as rigid bodies, use the <em>rigid</em> keyword, specifying as its
value the ID of a separate <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid/small</span></a>
command which also appears in your input script.</p>
<p>If you wish to insert molecules via the <em>mol</em> keyword, that will have
their bonds or angles constrained via SHAKE, use the <em>shake</em> keyword,
specifying as its value the ID of a separate <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command which also appears in your input script.</p>
<p>Each timestep a particle is inserted, the coordinates for its atoms
are chosen as follows. For insertion of individual atoms, the
“position” referred to in the following description is the coordinate
of the atom. For insertion of molecule, the “position” is the
geometric center of the molecule; see the <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> doc
page for details. A random rotation of the molecule around its center
point is performed, which determines the coordinates all the
individual atoms.</p>
<p>A random position within the region insertion volume is generated. If
neither the <em>global</em> or <em>local</em> keyword is used, the random position
is the trial position. If the <em>global</em> keyword is used, the random
x,y values are used, but the z position of the new particle is set
above the highest current atom in the simulation by a distance
randomly chosen between lo/hi. (For a 2d simulation, this is done for
the y position.) If the <em>local</em> keyword is used, the z position is
set a distance between lo/hi above the highest current atom in the
simulation that is “nearby” the chosen x,y position. In this context,
“nearby” means the lateral distance (in x,y) between the new and old
particles is less than the <em>delta</em> setting.</p>
<p>Once a trial x,y,z position has been selected, the insertion is only
performed if no current atom in the simulation is within a distance R
of any atom in the new particle, including the effect of periodic
boundary conditions if applicable. R is defined by the <em>near</em>
keyword. Note that the default value for R is 0.0, which will allow
atoms to strongly overlap if you are inserting where other atoms are
present. This distance test is performed independently for each atom
in an inserted molecule, based on the randomly rotated configuration
of the molecule. If this test fails, a new random position within the
insertion volume is chosen and another trial is made. Up to Q
attempts are made. If the particle is not successfully inserted,
LAMMPS prints a warning message.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you are inserting finite size particles or a molecule or
rigid body consisting of finite-size particles, then you should
typically set R larger than the distance at which any inserted
particle may overlap with either a previouly inserted particle or an
existing particle. LAMMPS will issue a warning if R is smaller than
this value, based on the radii of existing and inserted particles.</p>
</div>
<p>The <em>rate</em> option moves the insertion volume in the z direction (3d)
or y direction (2d). This enables particles to be inserted from a
successively higher height over time. Note that this parameter is
ignored if the <em>global</em> or <em>local</em> keywords are used, since those
options choose a z-coordinate for insertion independently.</p>
<p>The vx, vy, and vz components of velocity for the inserted particle
are set using the values specified for the <em>vx</em>, <em>vy</em>, and <em>vz</em>
keywords. Note that normally, new particles should be a assigned a
negative vertical velocity so that they move towards the surface. For
molecules, the same velocity is given to every particle (no rotation
or bond vibration).</p>
<p>If the <em>target</em> option is used, the velocity vector of the inserted
particle is changed so that it points from the insertion position
towards the specified target point. The magnitude of the velocity is
unchanged. This can be useful, for example, for simulating a
sputtering process. E.g. the target point can be far away, so that
all incident particles strike the surface as if they are in an
incident beam of particles at a prescribed angle.</p>
<p>The <em>id</em> keyword determines how atom IDs and molecule IDs are assigned
to newly deposited particles. Molecule IDs are only assigned if
molecules are being inserted. For the <em>max</em> setting, the atom and
molecule IDs of all current atoms are checked. Atoms in the new
particle are assigned IDs starting with the current maximum plus one.
If a molecule is inserted it is assigned an ID = current maximum plus
one. This means that if particles leave the system, the new IDs may
replace the lost ones. For the <em>next</em> setting, the maximum ID of any
atom and molecule is stored at the time the fix is defined. Each time
a new particle is added, this value is incremented to assign IDs to
the new atom(s) or molecule. Thus atom and molecule IDs for deposited
particles will be consecutive even if particles leave the system over
time.</p>
<p>The <em>units</em> keyword determines the meaning of the distance units used
for the other deposition parameters. A <em>box</em> value selects standard
distance units as defined by the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command,
e.g. Angstroms for units = real or metal. A <em>lattice</em> value means the
distance units are in lattice spacings. The <a class="reference internal" href="lattice.html"><span class="doc">lattice</span></a>
command must have been previously used to define the lattice spacing.
Note that the units choice affects all the keyword values that have
units of distance or velocity.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you are monitoring the temperature of a system where the atom
count is changing due to adding particles, you typically should use
the <a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify dynamic yes</span></a> command for the
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the state of the deposition to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. This includes information about how many
particles have been depositied, the random number generator seed, the
next timestep for deposition, etc. See the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for info on how to re-specify
a fix in an input script that reads a restart file, so that the
operation of the fix continues in an uninterrupted fashion.</p>
<p>None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options are relevant to this
fix. No global or per-atom quantities are stored by this fix for
access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No
parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the MISC package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The specified insertion region cannot be a “dynamic” region, as
defined by the <a class="reference internal" href="region.html"><span class="doc">region</span></a> command.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>respa</em> option is supported by this
fix. This allows to set at which level of the <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA</span></a>
integrator the fix is adding its forces. Default is the outermost level.</p>
<p>This fix computes a global 3-vector of forces, which can be accessed
by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. This is the
total force on the group of atoms by the drag force. The vector
values calculated by this fix are “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Transform the coordinates of Drude oscillators from real to reduced
and back for thermalizing the Drude oscillators as described in
<a class="reference internal" href="tutorial_drude.html#lamoureux"><span class="std std-ref">(Lamoureux)</span></a> using a Nose-Hoover thermostat. This fix is
designed to be used with the <a class="reference internal" href="tutorial_drude.html"><span class="doc">thermalized Drude oscillator model</span></a>. Polarizable models in LAMMPS are
described in <a class="reference internal" href="Section_howto.html#howto-25"><span class="std std-ref">this Section</span></a>.</p>
<p>Drude oscillators are a pair of atoms representing a single
polarizable atom. Ideally, the mass of Drude particles would vanish
and their positions would be determined self-consistently by iterative
minimization of the energy, the cores’ positions being fixed. It is
however more efficient and it yields comparable results, if the Drude
oscillators (the motion of the Drude particle relative to the core)
are thermalized at a low temperature. In that case, the Drude
particles need a small mass.</p>
<p>The thermostats act on the reduced degrees of freedom, which are
defined by the following equations. Note that in these equations
upper case denotes atomic or center of mass values and lower case
denotes Drude particle or dipole values. Primes denote the transformed
(reduced) values, while bare letters denote the original values.</p>
<p>Masses:</p>
<div class="math">
\[\begin{equation} M' = M + m \end{equation}\]</div>
<div class="math">
\[\begin{equation} m' = \frac {M\, m } {M'} \end{equation}\]</div>
<p>Positions:</p>
<div class="math">
\[\begin{equation} X' = \frac {M\, X + m\, x} {M'}\end{equation}\]</div>
<div class="math">
\[\begin{equation} x' = x - X \end{equation}\]</div>
<p>Velocities:</p>
<div class="math">
\[\begin{equation} V' = \frac {M\, V + m\, v} {M'}\end{equation}\]</div>
<div class="math">
\[\begin{equation} v' = v - V \end{equation}\]</div>
<p>Forces:</p>
<div class="math">
\[\begin{equation} F' = F + f \end{equation}\]</div>
<div class="math">
\[\begin{equation} f' = \frac { M\, f - m\, F} {M'}\end{equation}\]</div>
<p>This transform conserves the total kinetic energy</p>
<p>and the virial defined with absolute positions</p>
<div class="math">
\[\begin{equation} X\, F + x\, f = X'\, F' + x'\, f' \end{equation}\]</div>
<hr class="docutils" />
<p>This fix requires each atom know whether it is a Drude particle or
not. You must therefore use the <a class="reference internal" href="fix_drude.html"><span class="doc">fix drude</span></a> command to
specify the Drude status of each atom type.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">only the Drude core atoms need to be in the group specified for
this fix. A Drude electron will be transformed together with its core
even if it is not itself in the group. It is safe to include Drude
electrons or non-polarizable atoms in the group. The non-polarizable
atoms will simply not be transformed.</p>
</div>
<hr class="docutils" />
<p>This fix does NOT perform time integration. It only transform masses,
coordinates, velocities and forces. Thus you must use separate time
integration fixes, like <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> or <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> to actually update the velocities and positions of
atoms. In order to thermalize the reduced degrees of freedom at
different temperatures, two Nose-Hoover thermostats must be defined,
acting on two distinct groups.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The <em>fix drude/transform/direct</em> command must appear before any
Nose-Hoover thermostating fixes. The <em>fix drude/transform/inverse</em>
command must appear after any Nose-Hoover thermostating fixes.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Add a force F = qE to each charged atom in the group due to an
external electric field being applied to the system. If the system
contains point-dipoles, also add a torque on the dipoles due to the
external electric field.</p>
<p>For charges, any of the 3 quantities defining the E-field components
can be specified as an equal-style or atom-style
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a>, namely <em>ex</em>, <em>ey</em>, <em>ez</em>. If the value is a
variable, it should be specified as v_name, where name is the variable
name. In this case, the variable will be evaluated each timestep, and
its value used to determine the E-field component.</p>
<p>For point-dipoles, equal-style variables can be used, but atom-style
variables are not currently supported, since they imply a spatial
gradient in the electric field which means additional terms with
gradients of the field are required for the force and torque on
dipoles.</p>
<p>Equal-style variables can specify formulas with various mathematical
functions, and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent E-field.</p>
<p>Atom-style variables can specify the same formulas as equal-style
variables but can also include per-atom values, such as atom
coordinates. Thus it is easy to specify a spatially-dependent E-field
with optional time-dependence as well.</p>
<p>If the <em>region</em> keyword is used, the atom must also be in the
specified geometric <a class="reference internal" href="region.html"><span class="doc">region</span></a> in order to have force added
to it.</p>
<hr class="docutils" />
<p>Adding a force or torque to atoms implies a change in their potential
energy as they move or rotate due to the applied E-field.</p>
<p>For dynamics via the “run” command, this energy can be optionally
added to the system’s potential energy for thermodynamic output (see
below). For energy minimization via the “minimize” command, this
energy must be added to the system’s potential energy to formulate a
self-consistent minimization problem (see below).</p>
<p>The <em>energy</em> keyword is not allowed if the added field is a constant
vector (ex,ey,ez), with all components defined as numeric constants
and not as variables. This is because LAMMPS can compute the energy
for each charged particle directly as E = -x dot qE = -q (x*ex + y*ey
+ z*ez), so that -Grad(E) = F. Similarly for point-dipole particles
the energy can be computed as E = -mu dot E = -(mux*ex + muy*ey +
muz*ez).</p>
<p>The <em>energy</em> keyword is optional if the added force is defined with
one or more variables, and if you are performing dynamics via the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command. If the keyword is not used, LAMMPS will set
the energy to 0.0, which is typically fine for dynamics.</p>
<p>The <em>energy</em> keyword is required if the added force is defined with
one or more variables, and you are performing energy minimization via
the “minimize” command for charged particles. It is not required for
point-dipoles, but a warning is issued since the minimizer in LAMMPS
does not rotate dipoles, so you should not expect to be able to
minimize the orientation of dipoles in an applied electric field.</p>
<p>The <em>energy</em> keyword specifies the name of an atom-style
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> which is used to compute the energy of each
atom as function of its position. Like variables used for <em>ex</em>, <em>ey</em>,
<em>ez</em>, the energy variable is specified as v_name, where name is the
variable name.</p>
<p>Note that when the <em>energy</em> keyword is used during an energy
minimization, you must insure that the formula defined for the
atom-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> is consistent with the force
variable formulas, i.e. that -Grad(E) = F. For example, if the force
due to the electric field were a spring-like F = kx, then the energy
formula should be E = -0.5kx^2. If you don’t do this correctly, the
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the potential “energy” inferred by the added force due to
the electric field to the system’s potential energy as part of
<a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>. This is a fictitious
quantity but is needed so that the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command
can include the forces added by this fix in a consistent manner.
I.e. there is a decrease in potential energy when atoms move in the
direction of the added force due to the electric field.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>respa</em> option is supported by this
fix. This allows to set at which level of the <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA</span></a>
integrator the fix adding its forces. Default is the outermost level.</p>
<p>This fix computes a global scalar and a global 3-vector of forces,
which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the potential
energy discussed above. The vector is the total force added to the
group of atoms. The scalar and vector values calculated by this fix
are “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>The forces due to this fix are imposed during an energy minimization,
invoked by the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command. You should not
specify force components with a variable that has time-dependence for
use with a minimizer, since the minimizer increments the timestep as
the iteration count during the minimization.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you want the fictitious potential energy associated with the
added forces to be included in the total potential energy of the
system (the quantity being minimized), you MUST enable the
<a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option for this fix.</p>
</div>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the MISC package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where <span class="math">\(m_i\)</span> is the mass and <span class="math">\(k(\mathbf r_i)\)</span> maps the particle
position to the respective reservoir. The quantity
<span class="math">\(F_{\Gamma_{k(\mathbf r_i)}}\)</span> corresponds to the input parameter
<em>F</em>, which is the energy flux into the reservoir. Furthermore,
<span class="math">\(K_{\Gamma_{k(\mathbf r_i)}}\)</span> and <span class="math">\(v_{\Gamma_{k(\mathbf r_i)}}\)</span>
denote the non-translational kinetic energy and the centre of mass
velocity of that reservoir. The thermostatting force does not affect
the centre of mass velocities of the individual reservoirs and the
entire simulation box. A derivation of the equations and details on
the numerical implementation with velocity Verlet in LAMMPS can be
found in reference “(Wirnsberger)”#_Wirnsberger.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">This fix only integrates the thermostatting force and must be
combined with another integrator, such as <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a>, to
solve the full equations of motion.</p>
</div>
<p>This fix is different from a thermostat such as <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>
or <a class="reference internal" href="fix_temp_rescale.html"><span class="doc">fix temp/rescale</span></a> in that energy is
added/subtracted continually. Thus if there isn’t another mechanism
in place to counterbalance this effect, the entire system will heat or
cool continuously.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If heat is subtracted from the system too aggressively so that
the group’s kinetic energy would go to zero, then LAMMPS will halt
with an error message. Increasing the value of <em>nevery</em> means that
heat is added/subtracted less frequently but in larger portions. The
resulting temperature profile will therefore be the same.</p>
</div>
<p>This fix will default to <a class="reference internal" href="fix_heat.html"><span class="doc">fix_heat</span></a> (HEX algorithm) if
the keyword <em>hex</em> is specified.</p>
<hr class="docutils" />
<p><strong>Compatibility with SHAKE and RATTLE (rigid molecules)</strong>:</p>
<p>This fix is compatible with <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> and <a class="reference internal" href="fix_shake.html"><span class="doc">fix rattle</span></a>. If either of these constraining algorithms is
specified in the input script and the keyword <em>constrain</em> is set, the
bond distances will be corrected a second time at the end of the
integration step. It is recommended to specify the keyword <em>com</em> in
addition to the keyword <em>constrain</em>. With this option all sites of a
constrained cluster are rescaled, if its centre of mass is located
inside the region. Rescaling all sites of a cluster by the same factor
does not introduce any velocity components along fixed bonds. No
rescaling takes place if the centre of mass lies outside the region.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">You can only use the keyword <em>com</em> along with <em>constrain</em>.</p>
</div>
<p>To achieve the highest accuracy it is recommended to use <a class="reference internal" href="fix_shake.html"><span class="doc">fix rattle</span></a> with the keywords <em>constrain</em> and <em>com</em> as
shown in the second example. Only if RATTLE is employed, the velocity
constraints will be satisfied.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Even if RATTLE is used and the keywords <em>com</em> and <em>constrain</em>
are both set, the coordinate constraints will not necessarily be
satisfied up to the target precision. The velocity constraints are
satisfied as long as all sites of a cluster are rescaled (keyword
<em>com</em>) and the cluster does not span adjacent reservoirs. The current
implementation of the eHEX algorithm introduces a small error in the
bond distances, which goes to zero with order three in the
timestep. For example, in a simulation of SPC/E water with a timestep
of 2 fs the maximum relative error in the bond distances was found to
be on the order of <span class="math">\(10^{-7}\)</span> for relatively large
temperature gradients. A higher precision can be achieved by
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the RIGID package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This fix allows external programs that are running LAMMPS through its
<a class="reference internal" href="Section_howto.html#howto-19"><span class="std std-ref">library interface</span></a> to modify certain
LAMMPS properties on specific timesteps, similar to the way other
fixes do. The external driver can be a <a class="reference internal" href="Section_howto.html#howto-19"><span class="std std-ref">C/C++ or Fortran program</span></a> or a <a class="reference internal" href="Section_python.html"><span class="doc">Python script</span></a>.</p>
<hr class="docutils" />
<p>If mode is <em>pf/callback</em> then the fix will make a callback every
<em>Ncall</em> timesteps or minimization iterations to the external program.
The external program computes forces on atoms by setting values in an
array owned by the fix. The fix then adds these forces to each atom
in the group, once every <em>Napply</em> steps, similar to the way the <a class="reference internal" href="fix_addforce.html"><span class="doc">fix addforce</span></a> command works. Note that if <em>Ncall</em> >
<em>Napply</em>, the force values produced by one callback will persist, and
be used multiple times to update atom forces.</p>
<p>The callback function “foo” is invoked by the fix as:</p>
<p>If mode is <em>pf/array</em> then the fix simply stores force values in an
array. The fix adds these forces to each atom in the group, once
every <em>Napply</em> steps, similar to the way the <a class="reference internal" href="fix_addforce.html"><span class="doc">fix addforce</span></a> command works.</p>
<p>The name of the public force array provided by the FixExternal
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the potential “energy” set by the external driver to the
system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>. This is a fictitious quantity but is
needed so that the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command can include the
forces added by this fix in a consistent manner. I.e. there is a
decrease in potential energy when atoms move in the direction of the
added force.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
potential energy discussed above. The scalar stored by this fix
is “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>The forces due to this fix are imposed during an energy minimization,
invoked by the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you want the fictitious potential energy associated with the
added forces to be included in the total potential energy of the
system (the quantity being minimized), you MUST enable the
<a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option for this fix.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
template-ID = ID of molecule template specified in a separate <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command
<em>shake</em> value = fix-ID
fix-ID = ID of <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command
<em>region</em> value = region-ID
region-ID = ID of region where MC moves are allowed
<em>maxangle</em> value = maximum molecular rotation angle (degrees)
<em>pressure</em> value = pressure of the gas reservoir (pressure units)
<em>fugacity_coeff</em> value = fugacity coefficient of the gas reservoir (unitless)
<em>full_energy</em> = compute the entire system energy when performing MC moves
<em>charge</em> value = charge of inserted atoms (charge units)
<em>group</em> value = group-ID
group-ID = group-ID for inserted atoms (string)
<em>grouptype</em> values = type group-ID
type = atom type (int)
group-ID = group-ID for inserted atoms (string)
<em>intra_energy</em> value = intramolecular energy (energy units)
<em>tfac_insert</em> value = scale up/down temperature of inserted atoms (unitless)
+fix 4 my_gas gcmc 1 10 10 1 123456543 300.0 -12.5 1.0 region disk
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>This fix performs grand canonical Monte Carlo (GCMC) exchanges of
atoms or molecules of the given type with an imaginary ideal gas reservoir at
the specified T and chemical potential (mu) as discussed in
<a class="reference internal" href="fix_ti_spring.html#frenkel"><span class="std std-ref">(Frenkel)</span></a>. If used with the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command,
simulations in the grand canonical ensemble (muVT, constant chemical
potential, constant volume, and constant temperature) can be
performed. Specific uses include computing isotherms in microporous
materials, or computing vapor-liquid coexistence curves.</p>
<p>Every N timesteps the fix attempts a number of GCMC exchanges (insertions
or deletions) of gas atoms or molecules of
the given type between the simulation cell and the imaginary
reservoir. It also attempts a number of Monte Carlo
moves (translations and molecule rotations) of gas of the given type
within the simulation cell or region. The average number of
attempted GCMC exchanges is X. The average number of attempted MC moves is M.
M should typically be chosen to be
approximately equal to the expected number of gas atoms or molecules
of the given type within the simulation cell or region,
which will result in roughly one
MC translation per atom or molecule per MC cycle.</p>
<p>For MC moves of molecular gasses, rotations and translations are each
attempted with 50% probability. For MC moves of atomic gasses,
translations are attempted 100% of the time. For MC exchanges of
either molecular or atomic gasses, deletions and insertions are each
attempted with 50% probability.</p>
<p>All inserted particles are always assigned to two groups: the default group
“all” and the group specified in the fix gcmc command (which can also
be “all”). In addition, particles are also added to any groups specified
by the <em>group</em> and <em>grouptype</em> keywords.
If inserted particles are individual atoms, they are
assigned the atom type given by the type argument. If they are molecules,
the type argument has no effect and must be set to zero. Instead,
the type of each atom in the inserted molecule is specified
in the file read by the <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command.</p>
<p>This fix cannot be used to perform MC insertions of gas atoms or
molecules other than the exchanged type, but MC deletions,
translations, and rotations can be performed on any atom/molecule in
the fix group. All atoms in the simulation cell can be moved using
regular time integration translations, e.g. via
<a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>, resulting in a hybrid GCMC+MD simulation. A
smaller-than-usual timestep size may be needed when running such a
hybrid simulation, especially if the inserted molecules are not well
equilibrated.</p>
<p>This command may optionally use the <em>region</em> keyword to define an
exchange and move volume. The specified region must have been
previously defined with a <a class="reference internal" href="region.html"><span class="doc">region</span></a> command. It must be
defined with side = <em>in</em>. Insertion attempts occur only within the
specified region. For non-rectangular regions, random trial
points are generated within the rectangular bounding box until a point is found
that lies inside the region. If no valid point is generated after 1000 trials,
no insertion is performed, but it is counted as an attempted insertion.
Move and deletion attempt candidates are selected
from gas atoms or molecules within the region. If there are no candidates,
no move or deletion is performed, but it is counted as an attempt move
or deletion. If an attempted move places the atom or molecule center-of-mass outside
the specified region, a new attempted move is generated. This process is repeated
until the atom or molecule center-of-mass is inside the specified region.</p>
<p>If used with <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>, the temperature of the imaginary
reservoir, T, should be set to be equivalent to the target temperature
used in fix nvt. Otherwise, the imaginary reservoir
will not be in thermal equilibrium with the simulation cell. Also,
it is important that the temperature used by fix nvt be dynamic,
<p>Note that neighbor lists are re-built every timestep that this fix is
invoked, so you should not set N to be too small. However, periodic
rebuilds are necessary in order to avoid dangerous rebuilds and missed
interactions. Specifically, avoid performing so many MC translations
per timestep that atoms can move beyond the neighbor list skin
distance. See the <a class="reference internal" href="neighbor.html"><span class="doc">neighbor</span></a> command for details.</p>
<p>When an atom or molecule is to be inserted, its
coordinates are chosen at a random position within the current
simulation cell or region, and new atom velocities are randomly chosen from
the specified temperature distribution given by T. The effective
temperature for new atom velocities can be increased or decreased
using the optional keyword <em>tfac_insert</em> (see below). Relative
coordinates for atoms in a molecule are taken from the template
molecule provided by the user. The center of mass of the molecule
is placed at the insertion point. The orientation of the molecule
is chosen at random by rotating about this point.</p>
<p>Individual atoms are inserted, unless the <em>mol</em> keyword is used. It
specifies a <em>template-ID</em> previously defined using the
<a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command, which reads a file that defines the
molecule. The coordinates, atom types, charges, etc, as well as any
bond/angle/etc and special neighbor information for the molecule can
be specified in the molecule file. See the <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a>
command for details. The only settings required to be in this file
are the coordinates and types of atoms in the molecule.</p>
<p>When not using the <em>mol</em> keyword, you should ensure you do not delete
atoms that are bonded to other atoms, or LAMMPS will
soon generate an error when it tries to find bonded neighbors. LAMMPS will
warn you if any of the atoms eligible for deletion have a non-zero
molecule ID, but does not check for this at the time of deletion.</p>
<p>If you wish to insert molecules via the <em>mol</em> keyword, that will have
their bonds or angles constrained via SHAKE, use the <em>shake</em> keyword,
specifying as its value the ID of a separate <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command which also appears in your input script.</p>
<p>Optionally, users may specify the maximum rotation angle for
molecular rotations using the <em>maxangle</em> keyword and specifying
the angle in degrees. Rotations are performed by generating a random
point on the unit sphere and a random rotation angle on the
range [0,maxangle). The molecule is then rotated by that angle about an
axis passing through the molecule center of mass. The axis is parallel
to the unit vector defined by the point on the unit sphere.
The same procedure is used for randomly rotating molecules when they
are inserted, except that the maximum angle is 360 degrees.</p>
<p>Note that fix GCMC does not use configurational bias
MC or any other kind of sampling of intramolecular degrees of freedom.
Inserted molecules can have different orientations, but they will all
have the same intramolecular configuration,
which was specified in the molecule command input.</p>
<p>For atomic gasses, inserted atoms have the specified atom type, but
deleted atoms are any atoms that have been inserted or that belong
to the user-specified fix group. For molecular gasses, exchanged
molecules use the same atom types as in the template molecule
supplied by the user. In both cases, exchanged
atoms/molecules are assigned to two groups: the default group “all”
and the group specified in the fix gcmc command (which can also be
“all”).</p>
<p>The gas reservoir pressure can be specified using the <em>pressure</em>
keyword, in which case the user-specified chemical potential is
ignored. For non-ideal gas reservoirs, the user may also specify the
fugacity coefficient using the <em>fugacity_coeff</em> keyword.</p>
<p>The <em>full_energy</em> option means that fix GCMC will compute the total
potential energy of the entire simulated system. The total system
energy before and after the proposed GCMC move is then used in the
Metropolis criterion to determine whether or not to accept the
proposed GCMC move. By default, this option is off, in which case
only partial energies are computed to determine the difference in
energy that would be caused by the proposed GCMC move.</p>
<p>The <em>full_energy</em> option is needed for systems with complicated
potential energy calculations, including the following:</p>
<ul class="simple">
<li>long-range electrostatics (kspace)</li>
<li>many-body pair styles</li>
<li>hybrid pair styles</li>
<li>eam pair styles</li>
<li>triclinic systems</li>
<li>need to include potential energy contributions from other fixes</li>
</ul>
<p>In these cases, LAMMPS will automatically apply the <em>full_energy</em>
keyword and issue a warning message.</p>
<p>When the <em>mol</em> keyword is used, the <em>full_energy</em> option also includes
the intramolecular energy of inserted and deleted molecules. If this
is not desired, the <em>intra_energy</em> keyword can be used to define an
amount of energy that is subtracted from the final energy when a molecule
is inserted, and added to the initial energy when a molecule is
deleted. For molecules that have a non-zero intramolecular energy, this
will ensure roughly the same behavior whether or not the <em>full_energy</em>
option is used.</p>
<p>Inserted atoms and molecules are assigned random velocities based on the
specified temperature T. Because the relative velocity of
all atoms in the molecule is zero, this may result in inserted molecules
that are systematically too cold. In addition, the intramolecular potential
energy of the inserted molecule may cause the kinetic energy
of the molecule to quickly increase or decrease after insertion.
The <em>tfac_insert</em> keyword allows the user to counteract these effects
by changing the temperature used to assign velocities to
inserted atoms and molecules by a constant factor. For a
particular application, some experimentation may be required
to find a value of <em>tfac_insert</em> that results in inserted molecules that
equilibrate quickly to the correct temperature.</p>
<p>Some fixes have an associated potential energy. Examples of such fixes
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the state of the fix to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. This includes information about the random
number generator seed, the next timestep for MC exchanges, etc. See
the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for info on how to
re-specify a fix in an input script that reads a restart file, so that
the operation of the fix continues in an uninterrupted fashion.</p>
<p>None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options are relevant to this
fix.</p>
<p>This fix computes a global vector of length 8, which can be accessed
by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The vector
values are the following global cumulative quantities:</p>
<ul class="simple">
<li>1 = translation attempts</li>
<li>2 = translation successes</li>
<li>3 = insertion attempts</li>
<li>4 = insertion successes</li>
<li>5 = deletion attempts</li>
<li>6 = deletion successes</li>
<li>7 = rotation attempts</li>
<li>8 = rotation successes</li>
</ul>
<p>The vector values calculated by this fix are “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the MC package. It is only enabled if LAMMPS was
built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Do not set “neigh_modify once yes” or else this fix will never be
called. Reneighboring is required.</p>
<p>Can be run in parallel, but aspects of the GCMC part will not scale
well in parallel. Only usable for 3D simulations.</p>
<p>Note that very lengthy simulations involving insertions/deletions of
billions of gas molecules may run out of atom or molecule IDs and
trigger an error, so it is better to run multiple shorter-duration
simulations. Likewise, very large molecules have not been tested
and may turn out to be problematic.</p>
<p>Use of multiple fix gcmc commands in the same input script can be
problematic if using a template molecule. The issue is that the
user-referenced template molecule in the second fix gcmc command
may no longer exist since it might have been deleted by the first
fix gcmc command. An existing template molecule will need to be
referenced by the user for each subsequent fix gcmc command.</p>
<p>Because molecule insertion does not work in combination with
fix rigid, simulataneous use of fix rigid or fix rigid/small
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Applies Generalized Langevin Dynamics to a group of atoms, as
described in <a class="reference internal" href="#baczewski"><span class="std std-ref">(Baczewski)</span></a>. This is intended to model the
effect of an implicit solvent with a temporally non-local dissipative
force and a colored Gaussian random force, consistent with the
Fluctuation-Dissipation Theorem. The functional form of the memory
kernel associated with the temporally non-local force is constrained
to be a Prony series.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">While this fix bears many similarities to <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a>, it has one significant
whereas <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> does NOT. To this end, the
specification of another fix to perform time integration, such as <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a>, is NOT necessary.</p>
</div>
<p>With this fix active, the force on the <em>j</em>th atom is given as</p>
<p>The desired temperature at each timestep is ramped from <em>Tstart</em> to
<em>Tstop</em> over the course of the next run.</p>
<p>The random # <em>seed</em> must be a positive integer. A Marsaglia random
number generator is used. Each processor uses the input seed to
generate its own unique seed and its own stream of random
numbers. Thus the dynamics of the system will not be identical on two
runs on different numbers of processors.</p>
<hr class="docutils" />
<p>The keyword/value option pairs are used in the following ways.</p>
<p>The keyword <em>frozen</em> can be used to specify how the extended variables
associated with the GLD memory kernel are initialized. Specifying no
(the default), the initial values are drawn at random from an
equilibrium distribution at <em>Tstart</em>, consistent with the
Fluctuation-Dissipation Theorem. Specifying yes, initializes the
extended variables to zero.</p>
<p>The keyword <em>zero</em> can be used to eliminate drift due to the
thermostat. Because the random forces on different atoms are
independent, they do not sum exactly to zero. As a result, this fix
applies a small random force to the entire system, and the
center-of-mass of the system undergoes a slow random walk. If the
keyword <em>zero</em> is set to <em>yes</em>, the total random force is set exactly
to zero by subtracting off an equal part of it from each atom in the
group. As a result, the center-of-mass of a system with zero initial
momentum will not drift over time.</p>
<hr class="docutils" />
<p><strong>Restart, run start/stop, minimize info:</strong></p>
<p>The instantaneous values of the extended variables are written to
<a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Because the state of the random
number generator is not saved in restart files, this means you cannot
do “exact” restarts with this fix, where the simulation continues on
the same as if no restart had taken place. However, in a statistical
sense, a restarted simulation should produce the same behavior.</p>
<p>None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options are relevant to this
fix. No global or per-atom quantities are stored by this fix for
access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>.</p>
<p>This fix can ramp its target temperature over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the MISC package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>The instantaneous values of the extended variables are written to
<a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Because the state of the random
number generator is not saved in restart files, this means you cannot
do “exact” restarts with this fix, where the simulation continues on
the same as if no restart had taken place. However, in a statistical
sense, a restarted simulation should produce the same behavior.
Note however that you should use a different seed each time you
restart, otherwise the same sequence of random numbers will be used
each time, which might lead to stochastic synchronization and
subtle artefacts in the sampling.</p>
<p>This fix can ramp its target temperature over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change induced by Langevin thermostatting to the
system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
cummulative energy change due to this fix. The scalar value
calculated by this fix is “extensive”.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The GLE thermostat in its current implementation should not be used
with rigid bodies, SHAKE or RATTLE. It is expected that all the
thermostatted degrees of freedom are fully flexible, and the sampled
ensemble will not be correct otherwise.</p>
<p>In order to perform constant-pressure simulations please use
<a class="reference internal" href="fix_press_berendsen.html"><span class="doc">fix press/berendsen</span></a>, rather than
<a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a>, to avoid duplicate integration of the
equations of motion.</p>
<p>This fix is part of the USER-MISC package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Impose an additional acceleration on each particle in the group. This
fix is typically used with granular systems to include a “gravity”
term acting on the macroscopic particles. More generally, it can
represent any kind of driving field, e.g. a pressure gradient inducing
a Poiseuille flow in a fluid. Note that this fix operates differently
than the <a class="reference internal" href="fix_addforce.html"><span class="doc">fix addforce</span></a> command. The addforce fix
adds the same force to each atom, independent of its mass. This
command imparts the same acceleration to each atom (force/mass).</p>
<p>The <em>magnitude</em> of the acceleration is specified in force/mass units.
For granular systems (LJ units) this is typically 1.0. See the
<a class="reference internal" href="units.html"><span class="doc">units</span></a> command for details.</p>
<p>Style <em>chute</em> is typically used for simulations of chute flow where
the specified <em>angle</em> is the chute angle, with flow occurring in the +x
direction. For 3d systems, the tilt is away from the z axis; for 2d
systems, the tilt is away from the y axis.</p>
<p>Style <em>spherical</em> allows an arbitrary 3d direction to be specified for
the acceleration vector. <em>Phi</em> and <em>theta</em> are defined in the usual
spherical coordinates. Thus for acceleration acting in the -z
direction, <em>theta</em> would be 180.0 (or -180.0). <em>Theta</em> = 90.0 and
<em>phi</em> = -90.0 would mean acceleration acts in the -y direction. For
2d systems, <em>phi</em> is ignored and <em>theta</em> is an angle in the xy plane
where <em>theta</em> = 0.0 is the y-axis.</p>
<p>Style <em>vector</em> imposes an acceleration in the vector direction given
by (x,y,z). Only the direction of the vector is important; it’s
length is ignored. For 2d systems, the <em>z</em> component is ignored.</p>
<p>Any of the quantities <em>magnitude</em>, <em>angle</em>, <em>phi</em>, <em>theta</em>, <em>x</em>, <em>y</em>,
<em>z</em> which define the gravitational magnitude and direction, can be
specified as an equal-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>. If the value is
a variable, it should be specified as v_name, where name is the
variable name. In this case, the variable will be evaluated each
timestep, and its value used to determine the quantity. You should
insure that the variable calculates a result in the approriate units,
e.g. force/mass or degrees.</p>
<p>Equal-style variables can specify formulas with various mathematical
functions, and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent gravitational
field.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the gravitational potential energy of the system to the
system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>respa</em> option is supported by this
fix. This allows to set at which level of the <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA</span></a>
integrator the fix is adding its forces. Default is the outermost level.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. This scalar is the
gravitational potential energy of the particles in the defined field,
namely mass * (g dot x) for each particles, where x and mass are the
particles position and mass, and g is the gravitational field. The
scalar value calculated by this fix is “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Add non-translational kinetic energy (heat) to a group of atoms in a
manner that conserves their aggregate momentum. Two of these fixes
can be used to establish a temperature gradient across a simulation
domain by adding heat (energy) to one group of atoms (hot reservoir)
and subtracting heat from another (cold reservoir). E.g. a simulation
sampling from the McDLT ensemble.</p>
<p>If the <em>region</em> keyword is used, the atom must be in both the group
and the specified geometric <a class="reference internal" href="region.html"><span class="doc">region</span></a> in order to have
energy added or subtracted to it. If not specified, then the atoms in
the group are affected wherever they may move to.</p>
<p>Heat addition/subtraction is performed every N timesteps. The <em>eflux</em>
parameter can be specified as a numeric constant or as a variable (see
below). If it is a numeric constant or equal-style variable which
evaluates to a scalar value, then the <em>eflux</em> determines the change in
aggregate energy of the entire group of atoms per unit time, e.g. in
eV/psec for <a class="reference internal" href="units.html"><span class="doc">metal units</span></a>. In this case it is an
“extensive” quantity, meaning its magnitude should be scaled with the
number of atoms in the group. Note that since <em>eflux</em> has per-time
units (i.e. it is a flux), this means that a larger value of N will
add/subtract a larger amount of energy each time the fix is invoked.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The heat-exchange (HEX) algorithm implemented by this fix is
known to exhibit a pronounced energy drift. An improved algorithm
(eHEX) is available as a <a class="reference internal" href="fix_ehex.html"><span class="doc">fix ehex</span></a> command and might be
preferable if energy conservation is important.</p>
</div>
<p>If <em>eflux</em> is specified as an atom-style variable (see below), then
the variable computes one value per atom. In this case, each value is
the energy flux for a single atom, again in units of energy per unit
time. In this case, each value is an “intensive” quantity, which need
not be scaled with the number of atoms in the group.</p>
<p>As mentioned above, the <em>eflux</em> parameter can be specified as an
equal-style or atom_style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>. If the value is a
variable, it should be specified as v_name, where name is the variable
name. In this case, the variable will be evaluated each timestep, and
its value(s) used to determine the flux.</p>
<p>Equal-style variables can specify formulas with various mathematical
functions, and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent flux.</p>
<p>Atom-style variables can specify the same formulas as equal-style
variables but can also include per-atom values, such as atom
coordinates. Thus it is easy to specify a spatially-dependent flux
with optional time-dependence as well.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If heat is subtracted from the system too aggressively so that
the group’s kinetic energy would go to zero, or any individual atom’s
kinetic energy would go to zero for the case where <em>eflux</em> is an
atom-style variable, then LAMMPS will halt with an error message.</p>
</div>
<p>Fix heat is different from a thermostat such as <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>
or <a class="reference internal" href="fix_temp_rescale.html"><span class="doc">fix temp/rescale</span></a> in that energy is
added/subtracted continually. Thus if there isn’t another mechanism
in place to counterbalance this effect, the entire system will heat or
cool continuously. You can use multiple heat fixes so that the net
energy change is 0.0 or use <a class="reference internal" href="fix_viscous.html"><span class="doc">fix viscous</span></a> to drain
energy from the system.</p>
<p>This fix does not change the coordinates of its atoms; it only scales
their velocities. Thus you must still use an integration fix
(e.g. <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a>) on the affected atoms. This fix should
not normally be used on atoms that have their temperature controlled
by another fix - e.g. <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> or <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> fix.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. This scalar is the
most recent value by which velocites were scaled. The scalar value
calculated by this fix is “intensive”. If <em>eflux</em> is specified as
an atom-style variable, this fix computes the average value by which
the velocities were scaled for all of the atoms that had their
velocities scaled.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This fix implements the “Interactive MD” (IMD) protocol which allows
realtime visualization and manipulation of MD simulations through the
IMD protocol, as initially implemented in VMD and NAMD. Specifically
it allows LAMMPS to connect an IMD client, for example the <a class="reference external" href="http://www.ks.uiuc.edu/Research/vmd">VMD visualization program</a>, so that it can monitor the progress of the
simulation and interactively apply forces to selected atoms.</p>
<p>If LAMMPS is compiled with the preprocessor flag -DLAMMPS_ASYNC_IMD
then fix imd will use POSIX threads to spawn a IMD communication
thread on MPI rank 0 in order to offload data reading and writing
from the main execution thread and potentially lower the inferred
latencies for slow communication links. This feature has only been
tested under linux.</p>
<p>There are example scripts for using this package with LAMMPS in
examples/USER/imd. Additional examples and a driver for use with the
Novint Falcon game controller as haptic device can be found at:
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global scalar or vector or per-atom
quantities are stored by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-MISC package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>When used in combination with VMD, a topology or coordinate file has
to be loaded, which matches (in number and ordering of atoms) the
group the fix is applied to. The fix internally sorts atom IDs by
ascending integer value; in VMD (and thus the IMD protocol) those will
be assigned 0-based consecutive index numbers.</p>
<p>When using multiple active IMD connections at the same time, each
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>There is no restart information associated with this fix, since all
the dynamical parameters are dealt with by i-PI.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>Using this fix on anything other than all atoms requires particular
care, since i-PI will know nothing on atoms that are not those whose
coordinates are transferred. However, one could use this strategy to
define an external potential acting on the atoms that are moved by
i-PI.</p>
<p>This fix is part of the USER-MISC package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info. Because of
the use of UNIX domain sockets, this fix will only work in a UNIX
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Apply a Langevin thermostat as described in <a class="reference internal" href="fix_langevin_eff.html#schneider"><span class="std std-ref">(Schneider)</span></a>
to a group of atoms which models an interaction with a background
implicit solvent. Used with <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a>, this command
performs Brownian dynamics (BD), since the total force on each atom
<p>The Ff and Fr terms are added by this fix on a per-particle basis.
See the <a class="reference internal" href="pair_dpd.html"><span class="doc">pair_style dpd/tstat</span></a> command for a
thermostatting option that adds similar terms on a pairwise basis to
pairs of interacting particles.</p>
<p>Ff is a frictional drag or viscous damping term proportional to the
particle’s velocity. The proportionality constant for each atom is
computed as m/damp, where m is the mass of the particle and damp is
the damping factor specified by the user.</p>
<p>Fr is a force due to solvent atoms at a temperature T randomly bumping
into the particle. As derived from the fluctuation/dissipation
theorem, its magnitude as shown above is proportional to sqrt(Kb T m /
dt damp), where Kb is the Boltzmann constant, T is the desired
temperature, m is the mass of the particle, dt is the timestep size,
and damp is the damping factor. Random numbers are used to randomize
the direction and magnitude of this force as described in
<a class="reference internal" href="fix_langevin_eff.html#dunweg"><span class="std std-ref">(Dunweg)</span></a>, where a uniform random number is used (instead of
a Gaussian random number) for speed.</p>
<p>Note that unless you use the <em>omega</em> or <em>angmom</em> keywords, the
thermostat effect of this fix is applied to only the translational
degrees of freedom for the particles, which is an important
consideration for finite-size particles, which have rotational degrees
of freedom, are being thermostatted. The translational degrees of
freedom can also have a bias velocity removed from them before
thermostatting takes place; see the description below.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Unlike the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command which performs
Nose/Hoover thermostatting AND time integration, this fix does NOT
perform time integration. It only modifies forces to effect
thermostatting. Thus you must use a separate time integration fix,
like <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> to actually update the velocities and
positions of atoms using the modified forces. Likewise, this fix
should not normally be used on atoms that also have their temperature
controlled by another fix - e.g. by <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> or <a class="reference internal" href="fix_temp_rescale.html"><span class="doc">fix temp/rescale</span></a> commands.</p>
</div>
<p>See <a class="reference internal" href="Section_howto.html#howto-16"><span class="std std-ref">this howto section</span></a> of the manual for
a discussion of different ways to compute temperature and perform
thermostatting.</p>
<p>The desired temperature at each timestep is a ramped value during the
run from <em>Tstart</em> to <em>Tstop</em>.</p>
<p><em>Tstart</em> can be specified as an equal-style or atom-style
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a>. In this case, the <em>Tstop</em> setting is
ignored. If the value is a variable, it should be specified as
v_name, where name is the variable name. In this case, the variable
will be evaluated each timestep, and its value used to determine the
target temperature.</p>
<p>Equal-style variables can specify formulas with various mathematical
functions, and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent temperature.</p>
<p>Atom-style variables can specify the same formulas as equal-style
variables but can also include per-atom values, such as atom
coordinates. Thus it is easy to specify a spatially-dependent
temperature with optional time-dependence as well.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that remove a “bias” from the
atom velocities. E.g. removing the center-of-mass velocity from a
group of atoms or removing the x-component of velocity from the
calculation. This is not done by default, but only if the
<a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used to assign a temperature
compute to this fix that includes such a bias term. See the doc pages
for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones
include a bias. In this case, the thermostat works in the following
manner: bias is removed from each atom, thermostatting is performed on
the remaining thermal degrees of freedom, and the bias is added back
in.</p>
<p>The <em>damp</em> parameter is specified in time units and determines how
rapidly the temperature is relaxed. For example, a value of 100.0
means to relax the temperature in a timespan of (roughly) 100 time
units (tau or fmsec or psec - see the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command).
The damp factor can be thought of as inversely related to the
viscosity of the solvent. I.e. a small relaxation time implies a
hi-viscosity solvent and vice versa. See the discussion about gamma
and viscosity in the documentation for the <a class="reference internal" href="fix_viscous.html"><span class="doc">fix viscous</span></a> command for more details.</p>
<p>The random # <em>seed</em> must be a positive integer. A Marsaglia random
number generator is used. Each processor uses the input seed to
generate its own unique seed and its own stream of random numbers.
Thus the dynamics of the system will not be identical on two runs on
different numbers of processors.</p>
<hr class="docutils" />
<p>The keyword/value option pairs are used in the following ways.</p>
<p>The keyword <em>angmom</em> and <em>omega</em> keywords enable thermostatting of
rotational degrees of freedom in addition to the usual translational
degrees of freedom. This can only be done for finite-size particles.</p>
<p>A simulation using atom_style sphere defines an omega for finite-size
spheres. A simulation using atom_style ellipsoid defines a finite
size and shape for aspherical particles and an angular momentum.
The Langevin formulas for thermostatting the rotational degrees of
freedom are the same as those above, where force is replaced by
torque, m is replaced by the moment of inertia I, and v is replaced by
omega (which is derived from the angular momentum in the case of
aspherical particles).</p>
<p>The rotational temperature of the particles can be monitored by the
<a class="reference internal" href="compute_temp_sphere.html"><span class="doc">compute temp/sphere</span></a> and <a class="reference internal" href="compute_temp_asphere.html"><span class="doc">compute temp/asphere</span></a> commands with their rotate
options.</p>
<p>For the <em>omega</em> keyword there is also a scale factor of 10.0/3.0 that
is applied as a multiplier on the Ff (damping) term in the equation
above and of sqrt(10.0/3.0) as a multiplier on the Fr term. This does
not affect the thermostatting behaviour of the Langevin formalism but
insures that the randomized rotational diffusivity of spherical
particles is correct.</p>
<p>For the <em>angmom</em> keyword a similar scale factor is needed which is
10.0/3.0 for spherical particles, but is anisotropic for aspherical
particles (e.g. ellipsoids). Currently LAMMPS only applies an
isotropic scale factor, and you can choose its magnitude as the
specified value of the <em>angmom</em> keyword. If your aspherical particles
are (nearly) spherical than a value of 10.0/3.0 = 3.333 is a good
choice. If they are highly aspherical, a value of 1.0 is as good a
choice as any, since the effects on rotational diffusivity of the
particles will be incorrect regardless. Note that for any reasonable
scale factor, the thermostatting effect of the <em>angmom</em> keyword on the
rotational temperature of the aspherical particles should still be
valid.</p>
<p>The keyword <em>scale</em> allows the damp factor to be scaled up or down by
the specified factor for atoms of that type. This can be useful when
different atom types have different sizes or masses. It can be used
multiple times to adjust damp for several atom types. Note that
specifying a ratio of 2 increases the relaxation time which is
equivalent to the solvent’s viscosity acting on particles with 1/2 the
diameter. This is the opposite effect of scale factors used by the
<a class="reference internal" href="fix_viscous.html"><span class="doc">fix viscous</span></a> command, since the damp factor in fix
<em>langevin</em> is inversely related to the gamma factor in fix <em>viscous</em>.
Also note that the damping factor in fix <em>langevin</em> includes the
particle mass in Ff, unlike fix <em>viscous</em>. Thus the mass and size of
different atom types should be accounted for in the choice of ratio
values.</p>
<p>The keyword <em>tally</em> enables the calculation of the cumulative energy
added/subtracted to the atoms as they are thermostatted. Effectively
it is the energy exchanged between the infinite thermal reservoir and
the particles. As described below, this energy can then be printed
out or added to the potential energy of the system to monitor energy
conservation.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">this accumulated energy does NOT include kinetic energy removed
by the <em>zero</em> flag. LAMMPS will print a warning when both options are
active.</p>
</div>
<p>The keyword <em>zero</em> can be used to eliminate drift due to the
thermostat. Because the random forces on different atoms are
independent, they do not sum exactly to zero. As a result, this fix
applies a small random force to the entire system, and the
center-of-mass of the system undergoes a slow random walk. If the
keyword <em>zero</em> is set to <em>yes</em>, the total random force is set exactly
to zero by subtracting off an equal part of it from each atom in the
group. As a result, the center-of-mass of a system with zero initial
momentum will not drift over time.</p>
<p>The keyword <em>gjf</em> can be used to run the <a class="reference internal" href="#gronbech-jensen"><span class="std std-ref">Gronbech-Jensen/Farago</span></a> time-discretization of the Langevin model. As
described in the papers cited below, the purpose of this method is to
enable longer timesteps to be used (up to the numerical stability
limit of the integrator), while still producing the correct Boltzmann
distribution of atom positions. It is implemented within LAMMPS, by
changing how the the random force is applied so that it is composed of
the average of two random forces representing half-contributions from
the previous and current time intervals.</p>
<p>In common with all methods based on Verlet integration, the
discretized velocities generated by this method in conjunction with
velocity-Verlet time integration are not exactly conjugate to the
positions. As a result the temperature (computed from the discretized
velocities) will be systematically lower than the target temperature,
by a small amount which grows with the timestep. Nonetheless, the
distribution of atom positions will still be consistent with the
target temperature.</p>
<p>As an example of using the <em>gjf</em> keyword, for molecules containing C-H
bonds, configurational properties generated with dt = 2.5 fs and tdamp
= 100 fs are indistinguishable from dt = 0.5 fs. Because the velocity
distribution systematically decreases with increasing timestep, the
method should not be used to generate properties that depend on the
velocity distribution, such as the velocity autocorrelation function
(VACF). In this example, the velocity distribution at dt = 2.5fs
generates an average temperature of 220 K, instead of 300 K.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Because the state of the random number generator
is not saved in restart files, this means you cannot do “exact”
restarts with this fix, where the simulation continues on the same as
if no restart had taken place. However, in a statistical sense, a
restarted simulation should produce the same behavior.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to assign a temperature <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>
you have defined to this fix which will be used in its thermostatting
procedure, as described above. For consistency, the group used by
this fix and by the compute should be the same.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change induced by Langevin thermostatting to the
system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>. Note that use of this option requires
setting the <em>tally</em> keyword to <em>yes</em>.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
cummulative energy change due to this fix. The scalar value
calculated by this fix is “extensive”. Note that calculation of this
quantity requires setting the <em>tally</em> keyword to <em>yes</em>.</p>
<p>This fix can ramp its target temperature over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Apply two Langevin thermostats as described in <a class="reference internal" href="tutorial_drude.html#jiang"><span class="std std-ref">(Jiang)</span></a> for
thermalizing the reduced degrees of freedom of Drude oscillators.
This link describes how to use the <a class="reference internal" href="tutorial_drude.html"><span class="doc">thermalized Drude oscillator model</span></a> in LAMMPS and polarizable models in LAMMPS
are discussed in <a class="reference internal" href="Section_howto.html#howto-25"><span class="std std-ref">this Section</span></a>.</p>
<p>Drude oscillators are a way to simulate polarizables atoms, by
splitting them into a core and a Drude particle bound by a harmonic
bond. The thermalization works by transforming the particles degrees
of freedom by these equations. In these equations upper case denotes
atomic or center of mass values and lower case denotes Drude particle
or dipole values. Primes denote the transformed (reduced) values,
while bare letters denote the original values.</p>
<p><span class="math">\(F_r'\)</span> is a random force proportional to
<span class="math">\(\sqrt { \frac {2\, k_B \mathtt{Tcom}\, m'} {\mathrm dt\, \mathtt{damp\_com} } }\)</span>. <a href="#id1"><span class="problematic" id="id2">:b:math:`f_r’`</span></a> is a random force proportional to
Then the real forces acting on the particles are computed from the inverse
transform:</p>
<div class="math">
\[\begin{equation} F = \frac M {M'}\, F' - f' \end{equation}\]</div>
<div class="math">
\[\begin{equation} f = \frac m {M'}\, F' + f' \end{equation}\]</div>
<p>This fix also thermostates non-polarizable atoms in the group at
temperature <em>Tcom</em>, as if they had a massless Drude partner. The
Drude particles themselves need not be in the group. The center of
mass and the dipole are thermostated iff the core atom is in the
group.</p>
<p>Note that the thermostat effect of this fix is applied to only the
translational degrees of freedom of the particles, which is an
important consideration if finite-size particles, which have
rotational degrees of freedom, are being thermostated. The
translational degrees of freedom can also have a bias velocity removed
from them before thermostating takes place; see the description below.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Like the <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> command, this fix does
NOT perform time integration. It only modifies forces to effect
thermostating. Thus you must use a separate time integration fix, like
<a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> or <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> to actually update the
velocities and positions of atoms using the modified forces.
Likewise, this fix should not normally be used on atoms that also have
their temperature controlled by another fix - e.g. by <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> or <a class="reference internal" href="fix_temp_rescale.html"><span class="doc">fix temp/rescale</span></a> commands.</p>
</div>
<p>See <a class="reference internal" href="Section_howto.html#howto-16"><span class="std std-ref">this howto section</span></a> of the manual for
a discussion of different ways to compute temperature and perform
thermostating.</p>
<hr class="docutils" />
<p>This fix requires each atom know whether it is a Drude particle or
not. You must therefore use the <a class="reference internal" href="fix_drude.html"><span class="doc">fix drude</span></a> command to
specify the Drude status of each atom type.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">only the Drude core atoms need to be in the group specified for
this fix. A Drude electron will be transformed together with its cores
even if it is not itself in the group. It is safe to include Drude
electrons or non-polarizable atoms in the group. The non-polarizable
atoms will simply be thermostatted as if they had a massless Drude
partner (electron).</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Ghost atoms need to know their velocity for this fix to act
correctly. You must use the <a class="reference internal" href="comm_modify.html"><span class="doc">comm_modify</span></a> command to
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Because the state of the random number generator
is not saved in restart files, this means you cannot do “exact”
restarts with this fix, where the simulation continues on the same as
if no restart had taken place. However, in a statistical sense, a
restarted simulation should produce the same behavior.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to assign a temperature <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>
you have defined to this fix which will be used in its thermostating
procedure, as described above. For consistency, the group used by the
compute should include the group of this fix and the Drude particles.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Apply a Langevin thermostat as described in <a class="reference internal" href="#schneider"><span class="std std-ref">(Schneider)</span></a>
to a group of nuclei and electrons in the <a class="reference internal" href="pair_eff.html"><span class="doc">electron force field</span></a> model. Used with <a class="reference internal" href="fix_nve_eff.html"><span class="doc">fix nve/eff</span></a>,
this command performs Brownian dynamics (BD), since the total force on
<p>The Ff and Fr terms are added by this fix on a per-particle basis.</p>
<p>The operation of this fix is exactly like that described by the <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> command, except that the thermostatting
is also applied to the radial electron velocity for electron
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Because the state of the random number generator
is not saved in restart files, this means you cannot do “exact”
restarts with this fix, where the simulation continues on the same as
if no restart had taken place. However, in a statistical sense, a
restarted simulation should produce the same behavior.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to assign a temperature <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>
you have defined to this fix which will be used in its thermostatting
procedure, as described above. For consistency, the group used by
this fix and by the compute should be the same.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change induced by Langevin thermostatting to the
system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>. Note that use of this option requires
setting the <em>tally</em> keyword to <em>yes</em>.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
cummulative energy change due to this fix. The scalar value
calculated by this fix is “extensive”. Note that calculation of this
quantity requires setting the <em>tally</em> keyword to <em>yes</em>.</p>
<p>This fix can ramp its target temperature over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<blockquote>
<div>none</div></blockquote>
<p>This fix is part of the USER-EFF package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>lb/fluid = style name of this fix command</li>
<li>nevery = update the lattice-Boltzmann fluid every this many timesteps</li>
<li>LBtype = 1 to use the standard finite difference LB integrator,
2 to use the LB integrator of <a class="reference internal" href="#ollila"><span class="std std-ref">Ollila et al.</span></a></li>
<li>viscosity = the fluid viscosity (units of mass/(time*length)).</li>
<li>density = the fluid density.</li>
<li>zero or more keyword/value pairs may be appended</li>
<li>keyword = <em>setArea</em> or <em>setGamma</em> or <em>scaleGamma</em> or <em>dx</em> or <em>dm</em> or <em>a0</em> or <em>noise</em> or <em>calcforce</em> or <em>trilinear</em> or <em>D3Q19</em> or <em>read_restart</em> or <em>write_restart</em> or <em>zwall_velocity</em> or <em>bodyforce</em> or <em>printfluid</em></li>
</ul>
<pre class="literal-block">
<em>setArea</em> values = type node_area
type = atom type (1-N)
node_area = portion of the surface area of the composite object associated with the particular atom type (used when the force coupling constant is set by default).
<em>setGamma</em> values = gamma
gamma = user set value for the force coupling constant.
<em>scaleGamma</em> values = type gammaFactor
type = atom type (1-N)
gammaFactor = factor to scale the <em>setGamma</em> gamma value by, for the specified atom type.
<em>dx</em> values = dx_LB = the lattice spacing.
<em>dm</em> values = dm_LB = the lattice-Boltzmann mass unit.
<em>a0</em> values = a_0_real = the square of the speed of sound in the fluid.
<em>noise</em> values = Temperature seed
Temperature = fluid temperature.
seed = random number generator seed (positive integer)
<em>calcforce</em> values = N forcegroup-ID
N = output the force and torque every N timesteps
forcegroup-ID = ID of the particle group to calculate the force and torque of
<em>trilinear</em> values = none (used to switch from the default Peskin interpolation stencil to the trilinear stencil).
<em>D3Q19</em> values = none (used to switch from the default D3Q15, 15 velocity lattice, to the D3Q19, 19 velocity lattice).
<em>read_restart</em> values = restart file = name of the restart file to use to restart a fluid run.
<em>write_restart</em> values = N = write a restart file every N MD timesteps.
<em>zwall_velocity</em> values = velocity_bottom velocity_top = velocities along the y-direction of the bottom and top walls (located at z=zmin and z=zmax).
<em>bodyforce</em> values = bodyforcex bodyforcey bodyforcez = the x,y and z components of a constant body force added to the fluid.
<em>printfluid</em> values = N = print the fluid density and velocity at each grid point every N timesteps.
<p>Here, m_v is the mass of the MD particle, m_u is a representative
fluid mass at the particle location, and dt_collision is a collision
time, chosen such that tau/dt_collision = 1 (see <a class="reference internal" href="#mackay2"><span class="std std-ref">Mackay and Denniston</span></a> for full details). In order to calculate m_u, the
fluid density is interpolated to the MD particle location, and
multiplied by a volume, node_area*dx_lb, where node_area represents
the portion of the surface area of the composite object associated
with a given MD particle. By default, node_area is set equal to
dx_lb*dx_lb; however specific values for given atom types can be set
using the <em>setArea</em> keyword.</p>
<p>The user also has the option of specifying their own value for the
force coupling constant, for all the MD particles associated with the
fix, through the use of the <em>setGamma</em> keyword. This may be useful
when modelling porous particles. See <a class="reference internal" href="#fluid-mackay"><span class="std std-ref">Mackay et al.</span></a> for a
detailed description of the method by which the user can choose an
appropriate gamma value.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">while this fix applies the force of the particles on the fluid,
it does not apply the force of the fluid to the particles. When the
force coupling constant is set using the default method, there is only
one option to include this hydrodynamic force on the particles, and
that is through the use of the <a class="reference internal" href="fix_lb_viscous.html"><span class="doc">lb/viscous</span></a> fix.
This fix adds the hydrodynamic force to the total force acting on the
particles, after which any of the built-in LAMMPS integrators can be
used to integrate the particle motion. However, if the user specifies
their own value for the force coupling constant, as mentioned in
<a class="reference internal" href="#fluid-mackay"><span class="std std-ref">Mackay et al.</span></a>, the built-in LAMMPS integrators may prove to
be unstable. Therefore, we have included our own integrators <a class="reference internal" href="fix_lb_rigid_pc_sphere.html"><span class="doc">fix lb/rigid/pc/sphere</span></a>, and <a class="reference internal" href="fix_lb_pc.html"><span class="doc">fix lb/pc</span></a>, to solve for the particle motion in these
cases. These integrators should not be used with the
<a class="reference internal" href="fix_lb_viscous.html"><span class="doc">lb/viscous</span></a> fix, as they add hydrodynamic forces
to the particles directly. In addition, they can not be used if the
force coupling constant has been set the default way.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">if the force coupling constant is set using the default method,
and the <a class="reference internal" href="fix_lb_viscous.html"><span class="doc">lb/viscous</span></a> fix is NOT used to add the
hydrodynamic force to the total force acting on the particles, this
physically corresponds to a situation in which an infinitely massive
particle is moving through the fluid (since collisions between the
particle and the fluid do not act to change the particle’s velocity).
Therefore, the user should set the mass of the particle to be
significantly larger than the mass of the fluid at the particle
location, in order to approximate an infinitely massive particle (see
the dragforce test run for an example).</p>
</div>
<hr class="docutils" />
<p>Inside the fix, parameters are scaled by the lattice-Boltzmann
timestep, dt, grid spacing, dx, and mass unit, dm. dt is set equal to
(nevery*dt_MD), where dt_MD is the MD timestep. By default, dm is set
equal to 1.0, and dx is chosen so that tau/(dt) =
(3*eta*dt)/(rho*dx^2) is approximately equal to 1. However, the user
has the option of specifying their own values for dm, and dx, by using
the optional keywords <em>dm</em>, and <em>dx</em> respectively.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Care must be taken when choosing both a value for dx, and a
simulation domain size. This fix uses the same subdivision of the
simulation domain among processors as the main LAMMPS program. In
order to uniformly cover the simulation domain with lattice sites, the
lengths of the individual LAMMPS subdomains must all be evenly
divisible by dx. If the simulation domain size is cubic, with equal
lengths in all dimensions, and the default value for dx is used, this
will automatically be satisfied.</p>
</div>
<p>Physical parameters describing the fluid are specified through
<em>viscosity</em>, <em>density</em>, and <em>a0</em>. If the force coupling constant is
set the default way, the surface area associated with the MD particles
is specified using the <em>setArea</em> keyword. If the user chooses to
specify a value for the force coupling constant, this is set using the
<em>setGamma</em> keyword. These parameters should all be given in terms of
the mass, distance, and time units chosen for the main LAMMPS run, as
they are scaled by the LB timestep, lattice spacing, and mass unit,
inside the fix.</p>
<hr class="docutils" />
<p>The <em>setArea</em> keyword allows the user to associate a surface area with
a given atom type. For example if a spherical composite object of
radius R is represented as a spherical shell of N evenly distributed
MD particles, all of the same type, the surface area per particle
associated with that atom type should be set equal to 4*pi*R^2/N.
This keyword should only be used if the force coupling constant,
gamma, is set the default way.</p>
<p>The <em>setGamma</em> keyword allows the user to specify their own value for
the force coupling constant, gamma, instead of using the default
value.</p>
<p>The <em>scaleGamma</em> keyword should be used in conjunction with the
<em>setGamma</em> keyword, when the user wishes to specify different gamma
values for different atom types. This keyword allows the user to
scale the <em>setGamma</em> gamma value by a factor, gammaFactor, for a given
atom type.</p>
<p>The <em>dx</em> keyword allows the user to specify a value for the LB grid
spacing.</p>
<p>The <em>dm</em> keyword allows the user to specify the LB mass unit.</p>
<p>If the <em>a0</em> keyword is used, the value specified is used for the
square of the speed of sound in the fluid. If this keyword is not
present, the speed of sound squared is set equal to (1/3)*(dx/dt)^2.
Setting a0 > (dx/dt)^2 is not allowed, as this may lead to
instabilities.</p>
<p>If the <em>noise</em> keyword is used, followed by a a positive temperature
value, and a positive integer random number seed, a thermal
lattice-Boltzmann algorithm is used. If <em>LBtype</em> is set equal to 1
(i.e. the standard LB integrator is chosen), the thermal LB algorithm
of <a class="reference internal" href="#adhikari"><span class="std std-ref">Adhikari et al.</span></a> is used; however if <em>LBtype</em> is set
equal to 2 both the LB integrator, and thermal LB algorithm described
in <a class="reference internal" href="#ollila"><span class="std std-ref">Ollila et al.</span></a> are used.</p>
<p>If the <em>calcforce</em> keyword is used, both the fluid force and torque
acting on the specified particle group are printed to the screen every
N timesteps.</p>
<p>If the keyword <em>trilinear</em> is used, the trilinear stencil is used to
interpolate the particle nodes onto the fluid mesh. By default, the
immersed boundary method, Peskin stencil is used. Both of these
interpolation methods are described in <a class="reference internal" href="#fluid-mackay"><span class="std std-ref">Mackay et al.</span></a>.</p>
<p>If the keyword <em>D3Q19</em> is used, the 19 velocity (D3Q19) lattice is
used by the lattice-Boltzmann algorithm. By default, the 15 velocity
(D3Q15) lattice is used.</p>
<p>If the keyword <em>write_restart</em> is used, followed by a positive
integer, N, a binary restart file is printed every N LB timesteps.
This restart file only contains information about the fluid.
Therefore, a LAMMPS restart file should also be written in order to
print out full details of the simulation.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When a large number of lattice grid points are used, the restart
files may become quite large.</p>
</div>
<p>In order to restart the fluid portion of the simulation, the keyword
<em>read_restart</em> is specified, followed by the name of the binary
lb_fluid restart file to be used.</p>
<p>If the <em>zwall_velocity</em> keyword is used y-velocities are assigned to
the lower and upper walls. This keyword requires the presence of
walls in the z-direction. This is set by assigning fixed boundary
conditions in the z-direction. If fixed boundary conditions are
present in the z-direction, and this keyword is not used, the walls
are assumed to be stationary.</p>
<p>If the <em>bodyforce</em> keyword is used, a constant body force is added to
the fluid, defined by it’s x, y and z components.</p>
<p>If the <em>printfluid</em> keyword is used, followed by a positive integer, N,
the fluid densities and velocities at each lattice site are printed to the
screen every N timesteps.</p>
<hr class="docutils" />
<p>For further details, as well as descriptions and results of several
test runs, see <a class="reference internal" href="#fluid-mackay"><span class="std std-ref">Mackay et al.</span></a>. Please include a citation to
this paper if the lb_fluid fix is used in work contributing to
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>Due to the large size of the fluid data, this fix writes it’s own
binary restart files, if requested, independent of the main LAMMPS
<a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>; no information about <em>lb_fluid</em>
is written to the main LAMMPS <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options are relevant to this
fix. No global or per-atom quantities are stored by this fix for
access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No
parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-LB package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix can only be used with an orthogonal simulation domain.</p>
<p>Walls have only been implemented in the z-direction. Therefore, the
boundary conditions, as specified via the main LAMMPS boundary command
must be periodic for x and y, and either fixed or periodic for z.
Shrink-wrapped boundary conditions are not permitted with this fix.</p>
<p>This fix must be used before any of <a class="reference internal" href="fix_lb_viscous.html"><span class="doc">fix lb/viscous</span></a>, <a class="reference internal" href="fix_lb_momentum.html"><span class="doc">fix lb/momentum</span></a>, <a class="reference internal" href="fix_lb_rigid_pc_sphere.html"><span class="doc">fix lb/rigid/pc/sphere</span></a>, and/ or <a class="reference internal" href="fix_lb_pc.html"><span class="doc">fix lb/pc</span></a> , as the fluid needs to be initialized before
any of these routines try to access its properties. In addition, in
order for the hydrodynamic forces to be added to the particles, this
fix must be used in conjunction with the
<a class="reference internal" href="fix_lb_viscous.html"><span class="doc">lb/viscous</span></a> fix if the force coupling constant is
set by default, or either the <a class="reference internal" href="fix_lb_viscous.html"><span class="doc">lb/viscous</span></a> fix or
one of the <a class="reference internal" href="fix_lb_rigid_pc_sphere.html"><span class="doc">lb/rigid/pc/sphere</span></a> or
<a class="reference internal" href="fix_lb_pc.html"><span class="doc">lb/pc</span></a> integrators, if the user chooses to specifiy
their own value for the force coupling constant.</p>
<p>and an area of dx_lb^2 per node, used to calculate the fluid mass at
the particle node location, is assumed.</p>
<p>dx is chosen such that tau/(delta t_LB) =
(3 eta dt_LB)/(rho dx_lb^2) is approximately equal to 1.
dm is set equal to 1.0.
a0 is set equal to (1/3)*(dx_lb/dt_lb)^2.
The Peskin stencil is used as the default interpolation method.
The D3Q15 lattice is used for the lattice-Boltzmann algorithm.
If walls are present, they are assumed to be stationary.</p>
<hr class="docutils" />
<p id="ollila"><strong>(Ollila et al.)</strong> Ollila, S.T.T., Denniston, C., Karttunen, M., and Ala-Nissila, T., Fluctuating lattice-Boltzmann model for complex fluids, J. Chem. Phys. 134 (2011) 064902.</p>
<p id="fluid-mackay"><strong>(Mackay et al.)</strong> Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.</p>
<p id="mackay2"><strong>(Mackay and Denniston)</strong> Mackay, F. E., and Denniston, C., Coupling MD particles to a lattice-Boltzmann fluid through the use of conservative forces, J. Comput. Phys. 237 (2013) 289-298.</p>
<p id="adhikari"><strong>(Adhikari et al.)</strong> Adhikari, R., Stratford, K., Cates, M. E., and Wagner, A. J., Fluctuating lattice Boltzmann, Europhys. Lett. 71 (2005) 473-479.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can be
used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>Can only be used if a lattice-Boltzmann fluid has been created via the
<a class="reference internal" href="fix_lb_fluid.html"><span class="doc">fix lb/fluid</span></a> command, and must come after this
command.</p>
<p>This fix is part of the USER-LB package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Update the positions and velocities of the individual particles
described by <em>group-ID</em>, experiencing velocity-dependent hydrodynamic
-forces, using the integration algorithm described in <a class="reference internal" href="#mackay"><span class="std std-ref">Mackay et al.</span></a>. This integration algorithm should only be used if a
+forces, using the integration algorithm described in <a class="reference internal" href="fix_lb_viscous.html#mackay"><span class="std std-ref">Mackay et al.</span></a>. This integration algorithm should only be used if a
user-specified value for the force-coupling constant used in <a class="reference internal" href="fix_lb_fluid.html"><span class="doc">fix lb/fluid</span></a> has been set; do not use this integration
algorithm if the force coupling constant has been set by default.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can be
used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-LB package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Can only be used if a lattice-Boltzmann fluid has been created via the
<a class="reference internal" href="fix_lb_fluid.html"><span class="doc">fix lb/fluid</span></a> command, and must come after this
<p id="mackay"><strong>(Mackay et al.)</strong> Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This fix is based on the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> command, and was
created to be used in place of that fix, to integrate the equations of
motion of spherical rigid bodies when a lattice-Boltzmann fluid is
present with a user-specified value of the force-coupling constant.
The fix uses the integration algorithm described in <a class="reference internal" href="fix_lb_viscous.html#mackay"><span class="std std-ref">Mackay et al.</span></a> to update the positions, velocities, and orientations of
a set of spherical rigid bodies experiencing velocity dependent
hydrodynamic forces. The spherical bodies are assumed to rotate as
solid, uniform density spheres, with moments of inertia calculated
using the combined sum of the masses of all the constituent particles
(which are assumed to be point particles).</p>
<hr class="docutils" />
<p>By default, all of the atoms that this fix acts on experience a
hydrodynamic force due to the presence of the lattice-Boltzmann fluid.
However, the <em>innerNodes</em> keyword allows the user to specify atoms
belonging to a rigid object which do not interact with the
lattice-Boltzmann fluid (i.e. these atoms do not feel a hydrodynamic
force from the lattice-Boltzmann fluid). This can be used to
distinguish between atoms on the surface of a non-porous object, and
those on the inside.</p>
<p>This feature can be used, for example, when implementing a hard sphere
interaction between two spherical objects. Instead of interactions
occurring between the particles on the surfaces of the two spheres, it
is desirable simply to place an atom at the center of each sphere,
which does not contribute to the hydrodynamic force, and have these
central atoms interact with one another.</p>
<hr class="docutils" />
<p>Apart from the features described above, this fix is very similar to
the rigid fix (although it includes fewer optional arguments, and
assumes the constituent atoms are point particles); see
<a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> for a complete documentation.</p>
<p>Similar to the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> command: The rigid
fix computes a global scalar which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar value calculated by
these fixes is “intensive”. The scalar is the current temperature of
the collection of rigid bodies. This is averaged over all rigid
bodies and their translational and rotational degrees of freedom. The
translational energy of a rigid body is 1/2 m v^2, where m = total
mass of the body and v = the velocity of its center of mass. The
rotational energy of a rigid body is 1/2 I w^2, where I = the moment
of inertia tensor of the body and w = its angular velocity. Degrees
of freedom constrained by the <em>force</em> and <em>torque</em> keywords are
removed from this calculation.</p>
<p>All of these fixes compute a global array of values which can be
accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>.
The number of rows in the array is equal to the number of rigid
bodies. The number of columns is 15. Thus for each rigid body, 15
values are stored: the xyz coords of the center of mass (COM), the xyz
components of the COM velocity, the xyz components of the force acting
on the COM, the xyz components of the torque acting on the COM, and
the xyz image flags of the COM, which have the same meaning as image
flags for atom positions (see the “dump” command). The force and
torque values in the array are not affected by the <em>force</em> and
<em>torque</em> keywords in the fix rigid command; they reflect values before
any changes are made by those keywords.</p>
<p>The ordering of the rigid bodies (by row in the array) is as follows.
For the <em>single</em> keyword there is just one rigid body. For the
<em>molecule</em> keyword, the bodies are ordered by ascending molecule ID.
For the <em>group</em> keyword, the list of group IDs determines the ordering
of bodies.</p>
<p>The array values calculated by these fixes are “intensive”, meaning
they are independent of the number of atoms in the simulation.</p>
<p>No parameter of these fixes can be used with the <em>start/stop</em> keywords
of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. These fixes are not invoked during
<p>This fix is part of the USER-LB package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Can only be used if a lattice-Boltzmann fluid has been created via the
<a class="reference internal" href="fix_lb_fluid.html"><span class="doc">fix lb/fluid</span></a> command, and must come after this
command. Should only be used if the force coupling constant used in
<a class="reference internal" href="fix_lb_fluid.html"><span class="doc">fix lb/fluid</span></a> has been set by the user; this
integration fix cannot be used if the force coupling constant is set
<p>The defaults are force * on on on, and torque * on on on.</p>
<hr class="docutils" />
<p id="mackay"><strong>(Mackay et al.)</strong> Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>lb/viscous = style name of this fix command</li>
</ul>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<p>fix 1 flow lb/viscous</p>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>This fix is similar to the <a class="reference internal" href="fix_viscous.html"><span class="doc">fix viscous</span></a> command, and
is to be used in place of that command when a lattice-Boltzmann fluid
is present, and the user wishes to integrate the particle motion using
one of the built in LAMMPS integrators.</p>
<p>This fix adds a force, F = - Gamma*(velocity-fluid_velocity), to each
atom, where Gamma is the force coupling constant described in the <a class="reference internal" href="fix_lb_fluid.html"><span class="doc">fix lb/fluid</span></a> command (which applies an equal and
opposite force to the fluid).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">This fix should only be used in conjunction with one of the
built in LAMMPS integrators; it should not be used with the <a class="reference internal" href="fix_lb_pc.html"><span class="doc">fix lb/pc</span></a> or <a class="reference internal" href="fix_lb_rigid_pc_sphere.html"><span class="doc">fix lb/rigid/pc/sphere</span></a> integrators, which
already include the hydrodynamic forces. These latter fixes should
only be used if the force coupling constant has been set by the user
(instead of using the default value); if the default force coupling
value is used, then this fix provides the only method for adding the
hydrodynamic forces to the particles.</p>
</div>
<hr class="docutils" />
<p>For further details, as well as descriptions and results of several
test runs, see <a class="reference internal" href="#mackay"><span class="std std-ref">Mackay et al.</span></a>. Please include a citation to
this paper if this fix is used in work contributing to published
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>As described in the <a class="reference internal" href="fix_viscous.html"><span class="doc">fix viscous</span></a> documentation:</p>
<p>“No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>The forces due to this fix are imposed during an energy minimization,
invoked by the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command. This fix should only
be used with damped dynamics minimizers that allow for
non-conservative forces. See the <a class="reference internal" href="min_style.html"><span class="doc">min_style</span></a> command
for details.”</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-LB package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Can only be used if a lattice-Boltzmann fluid has been created via the
<a class="reference internal" href="fix_lb_fluid.html"><span class="doc">fix lb/fluid</span></a> command, and must come after this
command.</p>
<p>This fix should not be used if either the <a class="reference internal" href="fix_lb_pc.html"><span class="doc">fix lb/pc</span></a>
or <a class="reference internal" href="fix_lb_rigid_pc_sphere.html"><span class="doc">fix lb/rigid/pc/sphere</span></a> integrator is
<p id="mackay"><strong>(Mackay et al.)</strong> Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>The forces due to this fix are imposed during an energy minimization,
invoked by the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Perform updates of position and velocity for atoms in the group each
timestep using the specified settings or formulas, without regard to
forces on the atoms. This can be useful for boundary or other atoms,
whose movement can influence nearby atoms.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The atoms affected by this fix should not normally be time
integrated by other fixes (e.g. <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a>, <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>), since that will change their positions and
velocities twice.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">As atoms move due to this fix, they will pass thru periodic
boundaries and be remapped to the other side of the simulation box,
just as they would during normal time integration (e.g. via the <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> command). It is up to you to decide whether
periodic boundaries are appropriate with the kind of atom motion you
are prescribing with this fix.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">As dicsussed below, atoms are moved relative to their initial
position at the time the fix is specified. These initial coordinates
are stored by the fix in “unwrapped” form, by using the image flags
associated with each atom. See the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command
for a discussion of “unwrapped” coordinates. See the Atoms section of
the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command for a discussion of image flags
and how they are set for each atom. You can reset the image flags
(e.g. to 0) before invoking this fix by using the <a class="reference internal" href="set.html"><span class="doc">set image</span></a>
command.</p>
</div>
<hr class="docutils" />
<p>The <em>linear</em> style moves atoms at a constant velocity, so that their
position <em>X</em> = (x,y,z) as a function of time is given in vector
<p>The <em>rotate</em> style rotates atoms around a rotation axis <em>R</em> =
(Rx,Ry,Rz) that goes thru a point <em>P</em> = (Px,Py,Pz). The <em>period</em> of
the rotation is also specified. The direction of rotation for the
atoms around the rotation axis is consistent with the right-hand rule:
if your right-hand thumb points along <em>R</em>, then your fingers wrap
around the axis in the direction of rotation.</p>
<p>This style also sets the velocity of each atom to (omega cross Rperp)
where omega is its angular velocity around the rotation axis and Rperp
is a perpendicular vector from the rotation axis to the atom. If the
defined <a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a> assigns an angular velocity or
angular moementum or orientation to each atom (<a class="reference internal" href="atom_style.html"><span class="doc">atom styles</span></a> sphere, ellipsoid, line, tri, body), then
those properties are also updated appropriately to correspond to the
atom’s motion and rotation over time.</p>
<p>The <em>variable</em> style allows the position and velocity components of
each atom to be set by formulas specified via the
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command. Each of the 6 variables is
specified as an argument to the fix as v_name, where name is the
variable name that is defined elsewhere in the input script.</p>
<p>Each variable must be of either the <em>equal</em> or <em>atom</em> style.
<em>Equal</em>-style variables compute a single numeric quantity, that can be
a function of the timestep as well as of other simulation values.
<em>Atom</em>-style variables compute a numeric quantity for each atom, that
can be a function per-atom quantities, such as the atom’s position, as
well as of the timestep and other simulation values. Note that this
fix stores the original coordinates of each atom (see note below) so
that per-atom quantity can be used in an atom-style variable formula.
See the <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command for details.</p>
<p>The first 3 variables (v_dx,v_dy,v_dz) specified for the <em>variable</em>
style are used to calculate a displacement from the atom’s original
position at the time the fix was specified. The second 3 variables
(v_vx,v_vy,v_vz) specified are used to compute a velocity for each
atom.</p>
<p>Any of the 6 variables can be specified as NULL. If both the
displacement and velocity variables for a particular x,y,z component
are specified as NULL, then the position and velocity of that
component is time integrated the same as the <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a>
command would perform, using the corresponding force component on the
atom. If only the velocity variable for a component is specified as
NULL, then the displacement variable will be used to set the position
of the atom, and its velocity component will not be changed. If only
the displacement variable for a component is specified as NULL, then
the velocity variable will be used to set the velocity of the atom,
and the position of the atom will be time integrated using that
velocity.</p>
<p>The <em>units</em> keyword determines the meaning of the distance units used
to define the <em>linear</em> velocity and <em>wiggle</em> amplitude and <em>rotate</em>
origin. This setting is ignored for the <em>variable</em> style. A <em>box</em>
value selects standard units as defined by the <a class="reference internal" href="units.html"><span class="doc">units</span></a>
command, e.g. velocity in Angstroms/fmsec and amplitude and position
in Angstroms for units = real. A <em>lattice</em> value means the velocity
units are in lattice spacings per time and the amplitude and position
are in lattice spacings. The <a class="reference internal" href="lattice.html"><span class="doc">lattice</span></a> command must have
been previously used to define the lattice spacing. Each of these 3
quantities may be dependent on the x,y,z dimension, since the lattice
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the original coordinates of moving atoms to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, as well as the initial timestep, so that
the motion can be continuous in a restarted simulation. See the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for info on how to re-specify
a fix in an input script that reads a restart file, so that the
operation of the fix continues in an uninterrupted fashion.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Because the move positions are a function of the current
timestep and the initial timestep, you cannot reset the timestep to a
different value after reading a restart file, if you expect a fix move
command to work in an uninterrupted fashion.</p>
</div>
<p>None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options are relevant to this
fix.</p>
<p>This fix produces a per-atom array which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The number of columns
for each atom is 3, and the columns store the original unwrapped x,y,z
coords of each atom. The per-atom values can be accessed on any
timestep.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
<p>For <a class="reference internal" href="run_style.html"><span class="doc">rRESPA time integration</span></a>, this fix adjusts the
position and velocity of atoms on the outermost rRESPA level.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>See the <a class="reference internal" href="compute_temp.html"><span class="doc">compute temp</span></a> and <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + “temp” or fix_ID
+ underscore + “press”. The group for the new computes is “all”.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the state of all internal variables to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command
for info on how to re-specify a fix in an input script that reads a
restart file, so that the operation of the fix continues in an
uninterrupted fashion.</p>
<p>The progress of the MSST can be monitored by printing the global
scalar and global vector quantities computed by the fix.</p>
<p>The scalar is the cumulative energy change due to the fix. This is
also the energy added to the potential energy by the
<a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> command. With this command, the
thermo keyword <em>etotal</em> prints the conserved quantity of the MSST
dynamic equations. This can be used to test if the MD timestep is
sufficiently small for accurate integration of the dynamic
equations. See also <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command.</p>
<p>The global vector contains four values in this order:</p>
<li><em>dhugoniot</em> is the departure from the Hugoniot (temperature units).</li>
<li><em>drayleigh</em> is the departure from the Rayleigh line (pressure units).</li>
<li><em>lagrangian_speed</em> is the laboratory-frame Lagrangian speed (particle velocity) of the computational cell (velocity units).</li>
<li><em>lagrangian_position</em> is the computational cell position in the reference frame moving at the shock speed. This is usually a good estimate of distance of the computational cell behind the shock front.</li>
</ol>
<p>To print these quantities to the log file with descriptive column
headers, the following LAMMPS commands are suggested:</p>
+thermo_style custom step temp ke pe lz pzz etotal v_dhug v_dray v_lgr_vel v_lgr_pos f_msst
+</pre>
<p>These fixes compute a global scalar and a global vector of 4
quantities, which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar values calculated
by this fix are “extensive”; the vector values are “intensive”.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix style is part of the SHOCK package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>All cell dimensions must be periodic. This fix can not be used with a
triclinic cell. The MSST fix has been tested only for the group-ID
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>The forces due to this fix are imposed during an energy minimization,
as invoked by the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command via the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>style_name = <em>nvt</em> or <em>npt</em> or <em>nph</em></li>
<li>one or more keyword/value pairs may be appended</li>
</ul>
<pre class="literal-block">
keyword = <em>temp</em> or <em>iso</em> or <em>aniso</em> or <em>tri</em> or <em>x</em> or <em>y</em> or <em>z</em> or <em>xy</em> or <em>yz</em> or <em>xz</em> or <em>couple</em> or <em>tchain</em> or <em>pchain</em> or <em>mtk</em> or <em>tloop</em> or <em>ploop</em> or <em>nreset</em> or <em>drag</em> or <em>dilate</em> or <em>scalexy</em> or <em>scaleyz</em> or <em>scalexz</em> or <em>flip</em> or <em>fixedpoint</em> or <em>update</em>
<em>temp</em> values = Tstart Tstop Tdamp
Tstart,Tstop = external temperature at start/end of run
Tdamp = temperature damping parameter (time units)
<em>iso</em> or <em>aniso</em> or <em>tri</em> values = Pstart Pstop Pdamp
Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
Pdamp = pressure damping parameter (time units)
<em>x</em> or <em>y</em> or <em>z</em> or <em>xy</em> or <em>yz</em> or <em>xz</em> values = Pstart Pstop Pdamp
Pstart,Pstop = external stress tensor component at start/end of run (pressure units)
Pdamp = stress damping parameter (time units)
<em>couple</em> = <em>none</em> or <em>xyz</em> or <em>xy</em> or <em>yz</em> or <em>xz</em>
<em>tchain</em> value = N
N = length of thermostat chain (1 = single thermostat)
<em>pchain</em> values = N
N length of thermostat chain on barostat (0 = no thermostat)
<em>mtk</em> value = <em>yes</em> or <em>no</em> = add in MTK adjustment term or not
<em>tloop</em> value = M
M = number of sub-cycles to perform on thermostat
<em>ploop</em> value = M
M = number of sub-cycles to perform on barostat thermostat
<em>nreset</em> value = reset reference cell every this many timesteps
<em>drag</em> value = Df
Df = drag factor added to barostat/thermostat (0.0 = no drag)
<em>dilate</em> value = dilate-group-ID
dilate-group-ID = only dilate atoms in this group due to barostat volume changes
<em>scalexy</em> value = <em>yes</em> or <em>no</em> = scale xy with ly
<em>scaleyz</em> value = <em>yes</em> or <em>no</em> = scale yz with lz
<em>scalexz</em> value = <em>yes</em> or <em>no</em> = scale xz with lz
<em>flip</em> value = <em>yes</em> or <em>no</em> = allow or disallow box flips when it becomes highly skewed
<em>fixedpoint</em> values = x y z
x,y,z = perform barostat dilation/contraction around this point (distance units)
<em>update</em> value = <em>dipole</em> or <em>dipole/dlm</em>
dipole = update dipole orientation (only for sphere variants)
dipole/dlm = use DLM integrator to update dipole orientation (only for sphere variants)
specify whether the simulation box is orthogonal or non-orthogonal
(triclinic) and explain the meaning of the xy,xz,yz tilt factors.</p>
<p>The target pressures for each of the 6 components of the stress tensor
can be specified independently via the <em>x</em>, <em>y</em>, <em>z</em>, <em>xy</em>, <em>xz</em>, <em>yz</em>
keywords, which correspond to the 6 simulation box dimensions. For
each component, the external pressure or tensor component at each
timestep is a ramped value during the run from <em>Pstart</em> to <em>Pstop</em>.
If a target pressure is specified for a component, then the
corresponding box dimension will change during a simulation. For
example, if the <em>y</em> keyword is used, the y-box length will change. If
the <em>xy</em> keyword is used, the xy tilt factor will change. A box
dimension will not change if that component is not specified, although
you have the option to change that dimension via the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> command.</p>
<p>Note that in order to use the <em>xy</em>, <em>xz</em>, or <em>yz</em> keywords, the
simulation box must be triclinic, even if its initial tilt factors are
0.0.</p>
<p>For all barostat keywords, the <em>Pdamp</em> parameter operates like the
<em>Tdamp</em> parameter, determining the time scale on which pressure is
relaxed. For example, a value of 10.0 means to relax the pressure in
a timespan of (roughly) 10 time units (e.g. tau or fmsec or psec - see
the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">A Nose-Hoover barostat will not work well for arbitrary values
of <em>Pdamp</em>. If <em>Pdamp</em> is too small, the pressure and volume can
fluctuate wildly; if it is too large, the pressure will take a very
long time to equilibrate. A good choice for many models is a <em>Pdamp</em>
of around 1000 timesteps. However, note that <em>Pdamp</em> is specified in
time units, and that timesteps are NOT the same as time units for most
does the same thing for the barostat thermostat.</p>
<p>The keyword <em>nreset</em> controls how often the reference dimensions used
to define the strain energy are reset. If this keyword is not used,
or is given a value of zero, then the reference dimensions are set to
those of the initial simulation domain and are never changed. If the
simulation domain changes significantly during the simulation, then
the final average pressure tensor will differ significantly from the
specified values of the external stress tensor. A value of <em>nstep</em>
means that every <em>nstep</em> timesteps, the reference dimensions are set
to those of the current simulation domain.</p>
<p>The <em>scaleyz</em>, <em>scalexz</em>, and <em>scalexy</em> keywords control whether or
not the corresponding tilt factors are scaled with the associated box
dimensions when barostatting triclinic periodic cells. The default
values <em>yes</em> will turn on scaling, which corresponds to adjusting the
linear dimensions of the cell while preserving its shape. Choosing
<em>no</em> ensures that the tilt factors are not scaled with the box
dimensions. See below for restrictions and default values in different
situations. In older versions of LAMMPS, scaling of tilt factors was
not performed. The old behavior can be recovered by setting all three
scale keywords to <em>no</em>.</p>
<p>The <em>flip</em> keyword allows the tilt factors for a triclinic box to
exceed half the distance of the parallel box length, as discussed
below. If the <em>flip</em> value is set to <em>yes</em>, the bound is enforced by
flipping the box when it is exceeded. If the <em>flip</em> value is set to
<em>no</em>, the tilt will continue to change without flipping. Note that if
applied stress induces large deformations (e.g. in a liquid), this
means the box shape can tilt dramatically and LAMMPS will run less
efficiently, due to the large volume of communication needed to
acquire ghost atoms around a processor’s irregular-shaped sub-domain.
For extreme values of tilt, LAMMPS may also lose atoms and generate an
error.</p>
<p>The <em>fixedpoint</em> keyword specifies the fixed point for barostat volume
changes. By default, it is the center of the box. Whatever point is
chosen will not move during the simulation. For example, if the lower
periodic boundaries pass through (0,0,0), and this point is provided
to <em>fixedpoint</em>, then the lower periodic boundaries will remain at
(0,0,0), while the upper periodic boundaries will move twice as
far. In all cases, the particle trajectories are unaffected by the
chosen value, except for a time-dependent constant translation of
positions.</p>
<p>If the <em>update</em> keyword is used with the <em>dipole</em> value, then the
orientation of the dipole moment of each particle is also updated
during the time integration. This option should be used for models
where a dipole moment is assigned to finite-size particles,
e.g. spheroids via use of the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style hybrid sphere dipole</span></a> command.</p>
<p>The default dipole orientation integrator can be changed to the
Dullweber-Leimkuhler-McLachlan integration scheme
<a class="reference internal" href="#nh-dullweber"><span class="std std-ref">(Dullweber)</span></a> when using <em>update</em> with the value
<em>dipole/dlm</em>. This integrator is symplectic and time-reversible,
giving better energy conservation and allows slightly longer timesteps
at only a small additional computational cost.</p>
<hr class="docutils" />
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Using a barostat coupled to tilt dimensions <em>xy</em>, <em>xz</em>, <em>yz</em> can
sometimes result in arbitrarily large values of the tilt dimensions,
i.e. a dramatically deformed simulation box. LAMMPS allows the tilt
factors to grow a small amount beyond the normal limit of half the box
length (0.6 times the box length), and then performs a box “flip” to
an equivalent periodic cell. See the discussion of the <em>flip</em> keyword
above, to allow this bound to be exceeded, if desired.</p>
</div>
<p>The flip operation is described in more detail in the doc page for
<a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a>. Both the barostat dynamics and the atom
trajectories are unaffected by this operation. However, if a tilt
factor is incremented by a large amount (1.5 times the box length) on
a single timestep, LAMMPS can not accomodate this event and will
terminate the simulation with an error. This error typically indicates
that there is something badly wrong with how the simulation was
constructed, such as specifying values of <em>Pstart</em> that are too far
from the current stress value, or specifying a timestep that is too
large. Triclinic barostatting should be used with care. This also is
true for other barostat styles, although they tend to be more
forgiving of insults. In particular, it is important to recognize that
equilibrium liquids can not support a shear stress and that
equilibrium solids can not support shear stresses that exceed the
yield stress.</p>
<p>One exception to this rule is if the 1st dimension in the tilt factor
(x for xy) is non-periodic. In that case, the limits on the tilt
factor are not enforced, since flipping the box in that dimension does
not change the atom positions due to non-periodicity. In this mode,
if you tilt the system to extreme angles, the simulation will simply
become inefficient due to the highly skewed simulation box.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Unlike the <a class="reference internal" href="fix_temp_berendsen.html"><span class="doc">fix temp/berendsen</span></a> command
which performs thermostatting but NO time integration, these fixes
perform thermostatting/barostatting AND time integration. Thus you
should not use any other time integration fix, such as <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> on atoms to which this fix is applied. Likewise,
fix nvt and fix npt should not normally be used on atoms that also
have their temperature controlled by another fix - e.g. by <a class="reference internal" href="#"><span class="doc">fix langevin</span></a> or <a class="reference internal" href="fix_temp_rescale.html"><span class="doc">fix temp/rescale</span></a>
commands.</p>
</div>
<p>See <a class="reference internal" href="Section_howto.html#howto-16"><span class="std std-ref">this howto section</span></a> of the manual for
a discussion of different ways to compute temperature and perform
thermostatting and barostatting.</p>
<hr class="docutils" />
<p>These fixes compute a temperature and pressure each timestep. To do
this, the fix creates its own computes of style “temp” and “pressure”,
as if one of these two sets of commands had been issued:</p>
<p>See the <a class="reference internal" href="compute_temp.html"><span class="doc">compute temp</span></a> and <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + “temp” or fix_ID
+ underscore + “press”. For fix nvt, the group for the new computes
is the same as the fix group. For fix nph and fix npt, the group for
the new computes is “all” since pressure is computed for the entire
system.</p>
<p>Note that these are NOT the computes used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>
and <em>thermo_press</em>. This means you can change the attributes of this
fix’s temperature or pressure via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
or pressure during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> or
<em>thermo_press</em> will have no effect on this fix.</p>
<p>Like other fixes that perform thermostatting, fix nvt and fix npt can
be used with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a
temperature after removing a “bias” from the atom velocities.
E.g. removing the center-of-mass velocity from a group of atoms or
only calculating temperature on the x-component of velocity or only
calculating temperature for atoms in a geometric region. This is not
done by default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command
is used to assign a temperature compute to this fix that includes such
a bias term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
<hr class="docutils" />
<p>These fixes can be used with either the <em>verlet</em> or <em>respa</em>
<a class="reference internal" href="run_style.html"><span class="doc">integrators</span></a>. When using one of the barostat fixes
with <em>respa</em>, LAMMPS uses an integrator constructed
according to the following factorization of the Liouville propagator
<p>The fix npt and fix nph commands can be used with rigid bodies or
mixtures of rigid bodies and non-rigid particles (e.g. solvent). But
there are also <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid/npt</span></a> and <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid/nph</span></a> commands, which are typically a more natural
choice. See the doc page for those commands for more discussion of
the various ways to do this.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>These fixes writes the state of all the thermostat and barostat
variables to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. See the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for info on how to re-specify
a fix in an input script that reads a restart file, so that the
operation of the fix continues in an uninterrupted fashion.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> and <em>press</em> options are
supported by these fixes. You can use them to assign a
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> you have defined to this fix which will be used
in its thermostatting or barostatting procedure, as described above.
If you do this, note that the kinetic energy derived from the compute
temperature should be consistent with the virial term computed using
all atoms for the pressure. LAMMPS will warn you if you choose to
compute temperature on a subset of atoms.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If both the <em>temp</em> and <em>press</em> keywords are used in a single
thermo_modify command (or in two separate commands), then the order in
which the keywords are specified is important. Note that a <a class="reference internal" href="compute_pressure.html"><span class="doc">pressure compute</span></a> defines its own temperature compute as
an argument when it is specified. The <em>temp</em> keyword will override
this (for the pressure compute being used by fix npt), but only if the
<em>temp</em> keyword comes after the <em>press</em> keyword. If the <em>temp</em> keyword
comes before the <em>press</em> keyword, then the new pressure compute
specified by the <em>press</em> keyword will be unaffected by the <em>temp</em>
setting.</p>
</div>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by these
fixes to add the energy change induced by Nose/Hoover thermostatting
and barostatting to the system’s potential energy as part of
<p>These fixes compute a global scalar and a global vector of quantities,
which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar value calculated by
these fixes is “extensive”; the vector values are “intensive”.</p>
<p>The scalar is the cumulative energy change due to the fix.</p>
<p>The vector stores internal Nose/Hoover thermostat and barostat
variables. The number and meaning of the vector values depends on
which fix is used and the settings for keywords <em>tchain</em> and <em>pchain</em>,
which specify the number of Nose/Hoover chains for the thermostat and
barostat. If no thermostatting is done, then <em>tchain</em> is 0. If no
barostatting is done, then <em>pchain</em> is 0. In the following list,
“ndof” is 0, 1, 3, or 6, and is the number of degrees of freedom in
the barostat. Its value is 0 if no barostat is used, else its value
is 6 if any off-diagonal stress tensor component is barostatted, else
its value is 1 if <em>couple xyz</em> is used or <em>couple xy</em> for a 2d
simulation, otherwise its value is 3.</p>
<p>The order of values in the global vector and their meaning is as
follows. The notation means there are tchain values for eta, followed
by tchain for eta_dot, followed by ndof for omega, etc:</p>
<li>PE_eta[tchain] = potential energy of each particle thermostat displacement (energy units)</li>
<li>KE_eta_dot[tchain] = kinetic energy of each particle thermostat velocity (energy units)</li>
<li>PE_omega[ndof] = potential energy of each barostat displacement (energy units)</li>
<li>KE_omega_dot[ndof] = kinetic energy of each barostat velocity (energy units)</li>
<li>PE_etap[pchain] = potential energy of each barostat thermostat displacement (energy units)</li>
<li>KE_etap_dot[pchain] = kinetic energy of each barostat thermostat velocity (energy units)</li>
<li>PE_strain[1] = scalar strain energy (energy units)</li>
</ul>
<p>These fixes can ramp their external temperature and pressure over
multiple runs, using the <em>start</em> and <em>stop</em> keywords of the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of
how to do this.</p>
<p>These fixes are not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p><em>X</em>, <em>y</em>, <em>z</em> cannot be barostatted if the associated dimension is not
periodic. <em>Xy</em>, <em>xz</em>, and <em>yz</em> can only be barostatted if the
simulation domain is triclinic and the 2nd dimension in the keyword
(<em>y</em> dimension in <em>xy</em>) is periodic. <em>Z</em>, <em>xz</em>, and <em>yz</em>, cannot be
barostatted for 2D simulations. The <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a>,
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>style_name = <em>nvt/eff</em> or <em>npt/eff</em> or <em>nph/eff</em></li>
</ul>
<pre class="literal-block">
one or more keyword value pairs may be appended
keyword = <em>temp</em> or <em>iso</em> or <em>aniso</em> or <em>tri</em> or <em>x</em> or <em>y</em> or <em>z</em> or <em>xy</em> or <em>yz</em> or <em>xz</em> or <em>couple</em> or <em>tchain</em> or <em>pchain</em> or <em>mtk</em> or <em>tloop</em> or <em>ploop</em> or <em>nreset</em> or <em>drag</em> or <em>dilate</em>
<em>temp</em> values = Tstart Tstop Tdamp
Tstart,Tstop = external temperature at start/end of run
Tdamp = temperature damping parameter (time units)
<em>iso</em> or <em>aniso</em> or <em>tri</em> values = Pstart Pstop Pdamp
Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
Pdamp = pressure damping parameter (time units)
<em>x</em> or <em>y</em> or <em>z</em> or <em>xy</em> or <em>yz</em> or <em>xz</em> values = Pstart Pstop Pdamp
Pstart,Pstop = external stress tensor component at start/end of run (pressure units)
Pdamp = stress damping parameter (time units)
<em>couple</em> = <em>none</em> or <em>xyz</em> or <em>xy</em> or <em>yz</em> or <em>xz</em>
<em>tchain</em> value = length of thermostat chain (1 = single thermostat)
<em>pchain</em> values = length of thermostat chain on barostat (0 = no thermostat)
<em>mtk</em> value = <em>yes</em> or <em>no</em> = add in MTK adjustment term or not
<em>tloop</em> value = number of sub-cycles to perform on thermostat
<em>ploop</em> value = number of sub-cycles to perform on barostat thermostat
<em>nreset</em> value = reset reference cell every this many timesteps
<em>drag</em> value = drag factor added to barostat/thermostat (0.0 = no drag)
<em>dilate</em> value = <em>all</em> or <em>partial</em>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>See the doc page for the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt, npt, and nph</span></a> commands
for details.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-EFF package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Other restriction discussed on the doc page for the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt, npt, and nph</span></a> commands also apply.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The temperature for systems (regions or groups) with only
electrons and no nuclei is 0.0 (i.e. not defined) in the current
temperature calculations, a practical example would be a uniform
electron gas or a very hot plasma, where electrons remain delocalized
from the nuclei. This is because, even though electron virials are
included in the temperature calculation, these are averaged over the
nuclear degrees of freedom only. In such cases a corrective term must
be added to the pressure to get the correct kinetic contribution.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>nph/asphere = style name of this fix command</li>
<li>additional barostat related keyword/value pairs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> command can be appended</li>
<p>See the <a class="reference internal" href="compute_temp_asphere.html"><span class="doc">compute temp/asphere</span></a> and <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + “temp” or fix_ID
+ underscore + “press”, and the group for the new computes is “all”
since pressure is computed for the entire system.</p>
<p>Note that these are NOT the computes used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>
and <em>thermo_press</em>. This means you can change the attributes of this
fix’s temperature or pressure via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
or pressure during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> or
<em>thermo_press</em> will have no effect on this fix.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the state of the Nose/Hoover barostat to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> and <em>press</em> options are
supported by this fix. You can use them to assign a
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> you have defined to this fix which will be used
in its thermostatting or barostatting procedure. If you do this, note
that the kinetic energy derived from the compute temperature should be
consistent with the virial term computed using all atoms for the
pressure. LAMMPS will warn you if you choose to compute temperature
on a subset of atoms.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change induced by Nose/Hoover barostatting to
the system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes the same global scalar and global vector of
quantities as does the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> command.</p>
<p>This fix can ramp its target pressure over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the ASPHERE package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires that atoms store torque and angular momementum and a
quaternion as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a>
command.</p>
<p>All particles in the group must be finite-size. They cannot be point
particles, but they can be aspherical or spherical as defined by their
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>nph/sphere = style name of this fix command</li>
<li>additional barostat related keyword/value pairs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> command can be appended</li>
<p>See the <a class="reference internal" href="compute_temp_sphere.html"><span class="doc">compute temp/sphere</span></a> and <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + “temp” or fix_ID
+ underscore + “press”, and the group for the new computes is “all”
since pressure is computed for the entire system.</p>
<p>Note that these are NOT the computes used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>
and <em>thermo_press</em>. This means you can change the attributes of this
fix’s temperature or pressure via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
or pressure during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> or
<em>thermo_press</em> will have no effect on this fix.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the state of the Nose/Hoover barostat to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> and <em>press</em> options are
supported by this fix. You can use them to assign a
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> you have defined to this fix which will be used
in its thermostatting or barostatting procedure. If you do this, note
that the kinetic energy derived from the compute temperature should be
consistent with the virial term computed using all atoms for the
pressure. LAMMPS will warn you if you choose to compute temperature
on a subset of atoms.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change induced by Nose/Hoover barostatting to
the system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes the same global scalar and global vector of
quantities as does the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> command.</p>
<p>This fix can ramp its target pressure over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix requires that atoms store torque and angular velocity (omega)
and a radius as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style sphere</span></a>
command.</p>
<p>All particles in the group must be finite-size spheres. They cannot
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
</ul>
<pre class="literal-block">
one or more keyword value pairs may be appended
keyword = <em>temp</em> or <em>iso</em> or <em>aniso</em> or <em>tri</em> or <em>x</em> or <em>y</em> or <em>z</em> or <em>couple</em> or <em>tchain</em> or <em>pchain</em> or <em>mtk</em> or <em>tloop</em> or <em>ploop</em> or <em>nreset</em> or <em>drag</em> or <em>dilate</em> or <em>scaleyz</em> or <em>scalexz</em> or <em>scalexy</em>
<em>temp</em> values = Value1 Value2 Tdamp
Value1, Value2 = Nose-Hoover target temperatures, ignored by Hugoniostat
Tdamp = temperature damping parameter (time units)
<em>iso</em> or <em>aniso</em> or <em>tri</em> values = Pstart Pstop Pdamp
Pstart,Pstop = scalar external pressures, must be equal (pressure units)
Pdamp = pressure damping parameter (time units)
<em>x</em> or <em>y</em> or <em>z</em> or <em>xy</em> or <em>yz</em> or <em>xz</em> values = Pstart Pstop Pdamp
Pstart,Pstop = external stress tensor components, must be equal (pressure units)
Pdamp = stress damping parameter (time units)
<em>couple</em> = <em>none</em> or <em>xyz</em> or <em>xy</em> or <em>yz</em> or <em>xz</em>
<em>tchain</em> value = length of thermostat chain (1 = single thermostat)
<em>pchain</em> values = length of thermostat chain on barostat (0 = no thermostat)
<em>mtk</em> value = <em>yes</em> or <em>no</em> = add in MTK adjustment term or not
<em>tloop</em> value = number of sub-cycles to perform on thermostat
<em>ploop</em> value = number of sub-cycles to perform on barostat thermostat
<em>nreset</em> value = reset reference cell every this many timesteps
<em>drag</em> value = drag factor added to barostat/thermostat (0.0 = no drag)
<em>dilate</em> value = <em>all</em> or <em>partial</em>
<em>scaleyz</em> value = <em>yes</em> or <em>no</em> = scale yz with lz
<em>scalexz</em> value = <em>yes</em> or <em>no</em> = scale xz with lz
<em>scalexy</em> value = <em>yes</em> or <em>no</em> = scale xy with ly
It performs time integration of the Hugoniostat equations
of motion developed by Ravelo et al. <a class="reference internal" href="pair_lj_cubic.html#ravelo"><span class="std std-ref">(Ravelo)</span></a>.
These equations compress the system to a state with average
axial stress or pressure equal to the specified target value
and that satisfies the Rankine-Hugoniot (RH)
jump conditions for steady shocks.</p>
<p>The compression can be performed
either
hydrostatically (using keyword <em>iso</em>, <em>aniso</em>, or <em>tri</em>) or uniaxially
(using keywords <em>x</em>, <em>y</em>, or <em>z</em>). In the hydrostatic case,
the cell dimensions change dynamically so that the average axial stress
in all three directions converges towards the specified target value.
In the uniaxial case, the chosen cell dimension changes dynamically
so that the average
axial stress in that direction converges towards the target value. The
other two cell dimensions are kept fixed (zero lateral strain).</p>
<p>This leads to the following additional restrictions on the keywords:</p>
<ul class="simple">
<li>One and only one of the following keywords should be used: <em>iso</em>, <em>aniso</em>, <em>tri</em>, <em>x</em>, <em>y</em>, <em>z</em></li>
<li>The specified initial and final target pressures must be the same.</li>
<li>The keywords <em>xy</em>, <em>xz</em>, <em>yz</em> may not be used.</li>
<li>The only admissible value for the couple keyword is <em>xyz</em>, which has the same effect as keyword <em>iso</em></li>
<li>The <em>temp</em> keyword must be used to specify the time constant for kinetic energy relaxation, but initial and final target temperature values are ignored.</li>
</ul>
<p>Essentially, a Hugoniostat simulation is an NPT simulation in which the
user-specified target temperature is replaced with a time-dependent
target temperature Tt obtained from the following equation:</p>
<p>where T and Tt are the instantaneous and target temperatures,
P and P0 are the instantaneous and reference pressures or axial stresses,
depending on whether hydrostatic or uniaxial compression is being
performed, V and V0 are the instantaneous and reference volumes,
E and E0 are the instantaneous and reference internal energy (potential
plus kinetic), Ndof is the number of degrees of freedom used in the
definition of temperature, and kB is the Boltzmann constant. Delta is the
negative deviation of the instantaneous temperature from the target temperature.
When the system reaches a stable equilibrium, the value of Delta should
fluctuate about zero.</p>
<p>The values of E0, V0, and P0 are the instantaneous values at the start of
the simulation. These can be overridden using the fix_modify keywords <em>e0</em>,
<em>v0</em>, and <em>p0</em> described below.</p>
<hr class="docutils" />
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Unlike the <a class="reference internal" href="fix_temp_berendsen.html"><span class="doc">fix temp/berendsen</span></a> command
which performs thermostatting but NO time integration, this fix
performs thermostatting/barostatting AND time integration. Thus you
should not use any other time integration fix, such as <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> on atoms to which this fix is applied. Likewise,
this fix should not be used on atoms that have their temperature
controlled by another fix - e.g. by <a class="reference internal" href="fix_nh.html"><span class="doc">fix langevin</span></a> or <a class="reference internal" href="fix_temp_rescale.html"><span class="doc">fix temp/rescale</span></a> commands.</p>
</div>
<hr class="docutils" />
<p>This fix computes a temperature and pressure at each timestep. To do
this, the fix creates its own computes of style “temp” and “pressure”,
as if one of these two sets of commands had been issued:</p>
<p>See the <a class="reference internal" href="compute_temp.html"><span class="doc">compute temp</span></a> and <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + “temp” or fix_ID
+ underscore + “press”. The group for
the new computes is “all” since pressure is computed for the entire
system.</p>
<p>Note that these are NOT the computes used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>
and <em>thermo_press</em>. This means you can change the attributes of this
fix’s temperature or pressure via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
or pressure during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> or
<em>thermo_press</em> will have no effect on this fix.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
can be used to define the values of E0, V0, and P0. Note the
the values for <em>e0</em> and <em>v0</em> are extensive, and so must correspond
to the total energy and volume of the entire system, not energy and
volume per atom. If any of these quantities are not specified, then the
instantaneous value in the system at the start of the simulation is used.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> and <em>press</em> options are
supported by these fixes. You can use them to assign a
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> you have defined to this fix which will be used
in its thermostatting or barostatting procedure, as described above.
If you do this, note that the kinetic energy derived from the compute
temperature should be consistent with the virial term computed using
all atoms for the pressure. LAMMPS will warn you if you choose to
compute temperature on a subset of atoms.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by these
fixes to add the energy change induced by Nose/Hoover thermostatting
and barostatting to the system’s potential energy as part of
-<a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>. Either way, this energy is <em>not</em>
+<a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>. Either way, this energy is *not*
included in the definition of internal energy E when calculating the value
of Delta in the above equation.</p>
<p>These fixes compute a global scalar and a global vector of quantities,
which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar value calculated by
these fixes is “extensive”; the vector values are “intensive”.</p>
<p>The scalar is the cumulative energy change due to the fix.</p>
<p>The vector stores three quantities unique to this fix (Delta, Us, and up),
followed by all the internal Nose/Hoover thermostat and barostat
variables defined for <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a>. Delta is the deviation
of the temperature from the target temperature, given by the above equation.
Us and up are the shock and particle velocity corresponding to a steady
shock calculated from the RH conditions. They have units of distance/time.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix style is part of the SHOCK package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>All the usual restrictions for <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> apply,
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>npt/asphere = style name of this fix command</li>
<li>additional thermostat and barostat related keyword/value pairs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command can be appended</li>
<p>Perform constant NPT integration to update position, velocity,
orientation, and angular velocity each timestep for aspherical or
ellipsoidal particles in the group using a Nose/Hoover temperature
thermostat and Nose/Hoover pressure barostat. P is pressure; T is
temperature. This creates a system trajectory consistent with the
isothermal-isobaric ensemble.</p>
<p>This fix differs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command, which
assumes point particles and only updates their position and velocity.</p>
<p>The thermostat is applied to both the translational and rotational
degrees of freedom for the aspherical particles, assuming a compute is
used which calculates a temperature that includes the rotational
degrees of freedom (see below). The translational degrees of freedom
can also have a bias velocity removed from them before thermostatting
takes place; see the description below.</p>
<p>Additional parameters affecting the thermostat and barostat are
specified by keywords and values documented with the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command. See, for example, discussion of the <em>temp</em>,
<em>iso</em>, <em>aniso</em>, and <em>dilate</em> keywords.</p>
<p>The particles in the fix group are the only ones whose velocities and
positions are updated by the velocity/position update portion of the
NPT integration.</p>
<p>Regardless of what particles are in the fix group, a global pressure is
computed for all particles. Similarly, when the size of the simulation
box is changed, all particles are re-scaled to new positions, unless the
keyword <em>dilate</em> is specified with a value of <em>partial</em>, in which case
only the particles in the fix group are re-scaled. The latter can be
useful for leaving the coordinates of particles in a solid substrate
unchanged and controlling the pressure of a surrounding fluid.</p>
<hr class="docutils" />
<p>This fix computes a temperature and pressure each timestep. To do
this, the fix creates its own computes of style “temp/asphere” and
“pressure”, as if these commands had been issued:</p>
<p>See the <a class="reference internal" href="compute_temp_asphere.html"><span class="doc">compute temp/asphere</span></a> and <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + “temp” or fix_ID
+ underscore + “press”, and the group for the new computes is “all”
since pressure is computed for the entire system.</p>
<p>Note that these are NOT the computes used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>
and <em>thermo_press</em>. This means you can change the attributes of this
fix’s temperature or pressure via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
or pressure during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> or
<em>thermo_press</em> will have no effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>This fix computes the same global scalar and global vector of
quantities as does the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command.</p>
<p>This fix can ramp its target temperature and pressure over multiple
runs, using the <em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a>
command. See the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do
this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the ASPHERE package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires that atoms store torque and angular momementum and a
quaternion as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a>
command.</p>
<p>All particles in the group must be finite-size. They cannot be point
particles, but they can be aspherical or spherical as defined by their
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>npt/body = style name of this fix command</li>
<li>additional thermostat and barostat related keyword/value pairs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command can be appended</li>
<p>Perform constant NPT integration to update position, velocity,
orientation, and angular velocity each timestep for body
particles in the group using a Nose/Hoover temperature
thermostat and Nose/Hoover pressure barostat. P is pressure; T is
temperature. This creates a system trajectory consistent with the
isothermal-isobaric ensemble.</p>
<p>This fix differs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command, which
assumes point particles and only updates their position and velocity.</p>
<p>The thermostat is applied to both the translational and rotational
degrees of freedom for the body particles, assuming a compute is
used which calculates a temperature that includes the rotational
degrees of freedom (see below). The translational degrees of freedom
can also have a bias velocity removed from them before thermostatting
takes place; see the description below.</p>
<p>Additional parameters affecting the thermostat and barostat are
specified by keywords and values documented with the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command. See, for example, discussion of the <em>temp</em>,
<em>iso</em>, <em>aniso</em>, and <em>dilate</em> keywords.</p>
<p>The particles in the fix group are the only ones whose velocities and
positions are updated by the velocity/position update portion of the
NPT integration.</p>
<p>Regardless of what particles are in the fix group, a global pressure is
computed for all particles. Similarly, when the size of the simulation
box is changed, all particles are re-scaled to new positions, unless the
keyword <em>dilate</em> is specified with a value of <em>partial</em>, in which case
only the particles in the fix group are re-scaled. The latter can be
useful for leaving the coordinates of particles in a solid substrate
unchanged and controlling the pressure of a surrounding fluid.</p>
<hr class="docutils" />
<p>This fix computes a temperature and pressure each timestep. To do
this, the fix creates its own computes of style “temp/body” and
“pressure”, as if these commands had been issued:</p>
<p>See the <a class="reference internal" href="compute_temp_body.html"><span class="doc">compute temp/body</span></a> and <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + “temp” or fix_ID
+ underscore + “press”, and the group for the new computes is “all”
since pressure is computed for the entire system.</p>
<p>Note that these are NOT the computes used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>
and <em>thermo_press</em>. This means you can change the attributes of this
fix’s temperature or pressure via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
or pressure during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> or
<em>thermo_press</em> will have no effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>This fix computes the same global scalar and global vector of
quantities as does the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command.</p>
<p>This fix can ramp its target temperature and pressure over multiple
runs, using the <em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a>
command. See the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do
this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the BODY package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires that atoms store torque and angular momementum and a
quaternion as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style body</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>npt/sphere = style name of this fix command</li>
<li>additional thermostat and barostat related keyword/value pairs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command can be appended</li>
<p>Perform constant NPT integration to update position, velocity, and
angular velocity each timestep for finite-sizex spherical particles in
the group using a Nose/Hoover temperature thermostat and Nose/Hoover
pressure barostat. P is pressure; T is temperature. This creates a
system trajectory consistent with the isothermal-isobaric ensemble.</p>
<p>This fix differs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command, which
assumes point particles and only updates their position and velocity.</p>
<p>The thermostat is applied to both the translational and rotational
degrees of freedom for the spherical particles, assuming a compute is
used which calculates a temperature that includes the rotational
degrees of freedom (see below). The translational degrees of freedom
can also have a bias velocity removed from them before thermostatting
takes place; see the description below.</p>
<p>Additional parameters affecting the thermostat and barostat are
specified by keywords and values documented with the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command. See, for example, discussion of the <em>temp</em>,
<em>iso</em>, <em>aniso</em>, and <em>dilate</em> keywords.</p>
<p>The particles in the fix group are the only ones whose velocities and
positions are updated by the velocity/position update portion of the
NPT integration.</p>
<p>Regardless of what particles are in the fix group, a global pressure is
computed for all particles. Similarly, when the size of the simulation
box is changed, all particles are re-scaled to new positions, unless the
keyword <em>dilate</em> is specified with a value of <em>partial</em>, in which case
only the particles in the fix group are re-scaled. The latter can be
useful for leaving the coordinates of particles in a solid substrate
unchanged and controlling the pressure of a surrounding fluid.</p>
<hr class="docutils" />
<p>This fix computes a temperature and pressure each timestep. To do
this, the fix creates its own computes of style “temp/sphere” and
“pressure”, as if these commands had been issued:</p>
<p>See the <a class="reference internal" href="compute_temp_sphere.html"><span class="doc">compute temp/sphere</span></a> and <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + “temp” or fix_ID
+ underscore + “press”, and the group for the new computes is “all”
since pressure is computed for the entire system.</p>
<p>Note that these are NOT the computes used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>
and <em>thermo_press</em>. This means you can change the attributes of this
fix’s temperature or pressure via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
or pressure during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> or
<em>thermo_press</em> will have no effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the ASPHERE package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires that atoms store torque and angular momementum and a
quaternion as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a>
command.</p>
<p>All particles in the group must be finite-size. They cannot be point
particles, but they can be aspherical or spherical as defined by their
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the ASPHERE package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires that atoms store torque and angular momementum and a
quaternion as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a>
command.</p>
<p>All particles in the group must be finite-size. They cannot be point
particles, but they can be aspherical or spherical as defined by their
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Perform constant NVE integration to update position, velocity,
orientation, and angular velocity for body particles in the group each
timestep. V is volume; E is energy. This creates a system trajectory
consistent with the microcanonical ensemble. See <a class="reference internal" href="Section_howto.html#howto-14"><span class="std std-ref">Section_howto 14</span></a> of the manual and the <a class="reference internal" href="body.html"><span class="doc">body</span></a>
doc page for more details on using body particles.</p>
<p>This fix differs from the <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> command, which
assumes point particles and only updates their position and velocity.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the BODY package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires that atoms store torque and angular momementum and a
quaternion as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style body</span></a>
command.</p>
<p>All particles in the group must be body particles. They cannot be
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the ASPHERE package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires that particles be line segments as defined by the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Perform constant NVE integration to update position and velocity for
atoms constrained to a curved surface (manifold) in the group each
timestep. The constraint is handled by RATTLE <a class="reference internal" href="fix_shake.html#andersen"><span class="std std-ref">(Andersen)</span></a>
written out for the special case of single-particle constraints as
-explained in <a class="reference internal" href="manifolds.html#paquay"><span class="std std-ref">(Paquay)</span></a>. V is volume; E is energy. This way,
+explained in <a class="reference internal" href="#paquay"><span class="std std-ref">(Paquay)</span></a>. V is volume; E is energy. This way,
the dynamics of particles constrained to curved surfaces can be
studied. If combined with <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a>, this
generates Brownian motion of particles constrained to a curved
surface. For a list of currently supported manifolds and their
parameters, see <a class="reference internal" href="manifolds.html"><span class="doc">manifolds</span></a>.</p>
<p>Note that the particles must initially be close to the manifold in
question. If not, RATTLE will not be able to iterate until the
constraint is satisfied, and an error is generated. For simple
manifolds this can be achieved with <em>region</em> and <em>create_atoms</em>
commands, but for more complex surfaces it might be more useful to
write a script.</p>
<p>The manifold args may be equal-style variables, like so:</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-MANIFOLD package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Perform constant NVE integration to update position, velocity, and
angular velocity for finite-size spherical particles in the group each
timestep. V is volume; E is energy. This creates a system trajectory
consistent with the microcanonical ensemble.</p>
<p>This fix differs from the <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> command, which
assumes point particles and only updates their position and velocity.</p>
<p>If the <em>update</em> keyword is used with the <em>dipole</em> value, then the
orientation of the dipole moment of each particle is also updated
during the time integration. This option should be used for models
where a dipole moment is assigned to finite-size particles,
e.g. spheroids via use of the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style hybrid sphere dipole</span></a> command.</p>
<p>The default dipole orientation integrator can be changed to the
Dullweber-Leimkuhler-McLachlan integration scheme
<a class="reference internal" href="fix_nh.html#nh-dullweber"><span class="std std-ref">(Dullweber)</span></a> when using <em>update</em> with the value
<em>dipole/dlm</em>. This integrator is symplectic and time-reversible,
giving better energy conservation and allows slightly longer timesteps
at only a small additional computational cost.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix requires that atoms store torque and angular velocity (omega)
and a radius as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style sphere</span></a>
command. If the <em>dipole</em> keyword is used, then they must also store a
dipole moment as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style dipole</span></a>
command.</p>
<p>All particles in the group must be finite-size spheres. They cannot
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the ASPHERE package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires that particles be triangles as defined by the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>nvt/asphere = style name of this fix command</li>
<li>additional thermostat related keyword/value pairs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command can be appended</li>
<p>See the <a class="reference internal" href="compute_temp_asphere.html"><span class="doc">compute temp/asphere</span></a> command for
details. Note that the ID of the new compute is the fix-ID +
underscore + “temp”, and the group for the new compute is the same as
the fix group.</p>
<p>Note that this is NOT the compute used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>.
This means you can change the attributes of this fix’s temperature
(e.g. its degrees-of-freedom) via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> will have no
effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the state of the Nose/Hoover thermostat to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to assign a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> you have
defined to this fix which will be used in its thermostatting
procedure.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change induced by Nose/Hoover thermostatting to
the system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes the same global scalar and global vector of
quantities as does the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command.</p>
<p>This fix can ramp its target temperature over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the ASPHERE package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires that atoms store torque and angular momementum and a
quaternion as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a>
command.</p>
<p>All particles in the group must be finite-size. They cannot be point
particles, but they can be aspherical or spherical as defined by their
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>nvt/body = style name of this fix command</li>
<li>additional thermostat related keyword/value pairs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command can be appended</li>
<p>See the <a class="reference internal" href="compute_temp_body.html"><span class="doc">compute temp/body</span></a> command for
details. Note that the ID of the new compute is the fix-ID +
underscore + “temp”, and the group for the new compute is the same as
the fix group.</p>
<p>Note that this is NOT the compute used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>.
This means you can change the attributes of this fix’s temperature
(e.g. its degrees-of-freedom) via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> will have no
effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the state of the Nose/Hoover thermostat to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to assign a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> you have
defined to this fix which will be used in its thermostatting
procedure.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change induced by Nose/Hoover thermostatting to
the system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes the same global scalar and global vector of
quantities as does the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command.</p>
<p>This fix can ramp its target temperature over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the BODY package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires that atoms store torque and angular momementum and a
quaternion as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style body</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>nvt/sllod = style name of this fix command</li>
<li>additional thermostat related keyword/value pairs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command can be appended</li>
<p>Perform constant NVT integration to update positions and velocities
each timestep for atoms in the group using a Nose/Hoover temperature
thermostat. V is volume; T is temperature. This creates a system
trajectory consistent with the canonical ensemble.</p>
<p>This thermostat is used for a simulation box that is changing size
and/or shape, for example in a non-equilibrium MD (NEMD) simulation.
The size/shape change is induced by use of the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> command, so each point in the simulation box
can be thought of as having a “streaming” velocity. This
position-dependent streaming velocity is subtracted from each atom’s
actual velocity to yield a thermal velocity which is used for
temperature computation and thermostatting. For example, if the box
is being sheared in x, relative to y, then points at the bottom of the
box (low y) have a small x velocity, while points at the top of the
box (hi y) have a large x velocity. These velocities do not
contribute to the thermal “temperature” of the atom.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last"><a class="reference internal" href="fix_deform.html"><span class="doc">Fix deform</span></a> has an option for remapping either
atom coordinates or velocities to the changing simulation box. To use
fix nvt/sllod, fix deform should NOT remap atom positions, because fix
nvt/sllod adjusts the atom positions and velocities to create a
velocity profile that matches the changing box size/shape. Fix deform
SHOULD remap atom velocities when atoms cross periodic boundaries
since that is consistent with maintaining the velocity profile created
by fix nvt/sllod. LAMMPS will give an error if this setting is not
consistent.</p>
</div>
<p>The SLLOD equations of motion, originally proposed by Hoover and Ladd
(see <a class="reference internal" href="#evans"><span class="std std-ref">(Evans and Morriss)</span></a>), were proven to be equivalent to
Newton’s equations of motion for shear flow by <a class="reference internal" href="#evans"><span class="std std-ref">(Evans and Morriss)</span></a>. They were later shown to generate the desired
velocity gradient and the correct production of work by stresses for
all forms of homogeneous flow by <a class="reference internal" href="#daivis"><span class="std std-ref">(Daivis and Todd)</span></a>. As
implemented in LAMMPS, they are coupled to a Nose/Hoover chain
thermostat in a velocity Verlet formulation, closely following the
implementation used for the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command.</p>
<p>Additional parameters affecting the thermostat are specified by
keywords and values documented with the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>
command. See, for example, discussion of the <em>temp</em> and <em>drag</em>
keywords.</p>
<p>This fix computes a temperature each timestep. To do this, the fix
creates its own compute of style “temp/deform”, as if this command had
<p>See the <a class="reference internal" href="compute_temp_deform.html"><span class="doc">compute temp/deform</span></a> command for
details. Note that the ID of the new compute is the fix-ID +
underscore + “temp”, and the group for the new compute is the same as
the fix group.</p>
<p>Note that this is NOT the compute used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>.
This means you can change the attributes of this fix’s temperature
(e.g. its degrees-of-freedom) via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> will have no
effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the state of the Nose/Hoover thermostat to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to assign a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> you have
defined to this fix which will be used in its thermostatting
procedure.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change induced by Nose/Hoover thermostatting to
the system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes the same global scalar and global vector of
quantities as does the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command.</p>
<p>This fix can ramp its target temperature over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix works best without Nose-Hoover chain thermostats, i.e. using
tchain = 1. Setting tchain to larger values can result in poor
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>nvt/sllod/eff = style name of this fix command</li>
<li>additional thermostat related keyword/value pairs from the <a class="reference internal" href="fix_nh_eff.html"><span class="doc">fix nvt/eff</span></a> command can be appended</li>
<p>Perform constant NVT integration to update positions and velocities
each timestep for nuclei and electrons in the group for the <a class="reference internal" href="pair_eff.html"><span class="doc">electron force field</span></a> model, using a Nose/Hoover temperature
thermostat. V is volume; T is temperature. This creates a system
trajectory consistent with the canonical ensemble.</p>
<p>The operation of this fix is exactly like that described by the <a class="reference internal" href="fix_nvt_sllod.html"><span class="doc">fix nvt/sllod</span></a> command, except that the radius and
radial velocity of electrons are also updated and thermostatted.
Likewise the temperature calculated by the fix, using the compute it
creates (as discussed in the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt, npt, and nph</span></a> doc
page), is performed with a <a class="reference internal" href="compute_temp_deform_eff.html"><span class="doc">compute temp/deform/eff</span></a> commmand that includes
the eFF contribution to the temperature from the electron radial
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the state of the Nose/Hoover thermostat to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to assign a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> you have
defined to this fix which will be used in its thermostatting
procedure.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change induced by Nose/Hoover thermostatting to
the system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes the same global scalar and global vector of
quantities as does the <a class="reference internal" href="fix_nh_eff.html"><span class="doc">fix nvt/eff</span></a> command.</p>
<p>This fix can ramp its target temperature over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-EFF package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix works best without Nose-Hoover chain thermostats, i.e. using
tchain = 1. Setting tchain to larger values can result in poor
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>nvt/sphere = style name of this fix command</li>
<li>additional thermostat related keyword/value pairs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command can be appended</li>
<p>See the <a class="reference internal" href="compute_temp_sphere.html"><span class="doc">compute temp/sphere</span></a> command for
details. Note that the ID of the new compute is the fix-ID +
underscore + “temp”, and the group for the new compute is the same as
the fix group.</p>
<p>Note that this is NOT the compute used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>.
This means you can change the attributes of this fix’s temperature
(e.g. its degrees-of-freedom) via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> will have no
effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the state of the Nose/Hoover thermostat to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to assign a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> you have
defined to this fix which will be used in its thermostatting
procedure.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change induced by Nose/Hoover thermostatting to
the system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes the same global scalar and global vector of
quantities as does the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command.</p>
<p>This fix can ramp its target temperature over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix requires that atoms store torque and angular velocity (omega)
and a radius as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style sphere</span></a>
command.</p>
<p>All particles in the group must be finite-size spheres. They cannot
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the potential energy of atom interactions with the grain
boundary driving force to the system’s potential energy as part of
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>respa</em> option is supported by these
fixes. This allows to set at which level of the <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA</span></a>
integrator a fix is adding its forces. Default is the outermost level.</p>
<p>This fix calculates a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
potential energy change due to this fix. The scalar value calculated
by this fix is “extensive”.</p>
<p>This fix also calculates a per-atom array which can be accessed by
various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The array
stores the order parameter Xi and normalized order parameter (0 to 1)
for each atom. The per-atom values can be accessed on any timestep.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the MISC package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix should only be used with fcc or bcc lattices.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Calculate the dynamical matrix from molecular dynamics simulations
based on fluctuation-dissipation theory for a group of atoms.</p>
<p>Consider a crystal with <span class="math">\(N\)</span> unit cells in three dimensions labelled <span class="math">\(l = (l_1, l_2, l_3)\)</span> where <span class="math">\(l_i\)</span>
are integers. Each unit cell is defined by three linearly independent
vectors <span class="math">\(\mathbf{a}_1\)</span>, <span class="math">\(\mathbf{a}_2\)</span>, <span class="math">\(\mathbf{a}_3\)</span> forming a
<p>where <span class="math">\(\mathbf{R}\)</span> is the instantaneous positions of atoms, and <span class="math">\(\left<\mathbf{R}\right>\)</span> is the
averaged atomic positions. It gives essentially the same results as
the displacement method and is easier to implement in an MD code.</p>
<p>Once the force constant matrix is known, the dynamical matrix <span class="math">\(\mathbf{D}\)</span> can
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to change the temperature compute from thermo_temp
to the one that reflects the true temperature of atoms in the group.</p>
<p>No global scalar or vector or per-atom quantities are stored by this
fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>.</p>
<p>Instead, this fix outputs its initialization information (including
mapping information) and the calculated dynamical matrices to the file
<em>prefix</em>.log, with the specified <em>prefix</em>. The dynamical matrices are
also written to files <em>prefix</em>.bin.timestep in binary format. These
can be read by the post-processing tool in tools/phonon to compute the
phonon density of states and/or phonon dispersion curves.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords
of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix assumes a crystalline system with periodical lattice. The
temperature of the system should not exceed the melting temperature to
keep the system in its solid state.</p>
<p>This fix is part of the USER-PHONON package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires LAMMPS be built with an FFT library. See the
<a class="reference internal" href="Section_start.html#start-2"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The option defaults are sysdim = the same dimemsion as specified by
the <a class="reference external" href="dimension">dimension</a> command, and nasr = 20.</p>
<hr class="docutils" />
<p id="campana"><strong>(Campana)</strong> C. Campana and
M. H. Muser, <em>Practical Green’s function approach to the
simulation of elastic semi-infinite solids</em>, <a class="reference external" href="http://dx.doi.org/10.1103/PhysRevB.74.075420">Phys. Rev. B [74], 075420 (2006)</a></p>
<p id="kong"><strong>(Kong)</strong> L.T. Kong, G. Bartels, C. Campana,
C. Denniston, and Martin H. Muser, <em>Implementation of Green’s
function molecular dynamics: An extension to LAMMPS</em>, <a class="reference external" href="http://dx.doi.org/10.1016/j.cpc.2008.12.035">Computer Physics Communications [180](6):1004-1010 (2009).</a></p>
<p>L.T. Kong, C. Denniston, and Martin H. Muser,
<em>An improved version of the Green’s function molecular dynamics
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This fix is part of the USER-MISC package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>A PIMD simulation can be initialized with a single data file read via
the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command. However, this means all
quasi-beads in a ring polymer will have identical positions and
velocities, resulting in identical trajectories for all quasi-beads.
To avoid this, users can simply initialize velocities with different
random number seeds assigned to each partition, as defined by the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>pour = style name of this fix command</li>
<li>N = # of particles to insert</li>
<li>type = atom type to assign to inserted particles (offset for molecule insertion)</li>
<li>seed = random # seed (positive integer)</li>
<li>one or more keyword/value pairs may be appended to args</li>
<li>keyword = <em>region</em> or <em>diam</em> or <em>vol</em> or <em>rate</em> or <em>dens</em> or <em>vel</em> or <em>mol</em> or <em>rigid</em> or <em>shake</em> or <em>ignore</em></li>
</ul>
<pre class="literal-block">
<em>region</em> value = region-ID
region-ID = ID of region to use as insertion volume
<em>diam</em> values = dstyle args
dstyle = <em>one</em> or <em>range</em> or <em>poly</em>
<em>one</em> args = D
D = single diameter for inserted particles (distance units)
<em>range</em> args = Dlo Dhi
Dlo,Dhi = range of diameters for inserted particles (distance units)
<em>poly</em> args = Npoly D1 P1 D2 P2 ...
Npoly = # of (D,P) pairs
D1,D2,... = diameter for subset of inserted particles (distance units)
P1,P2,... = percentage of inserted particles with this diameter (0-1)
<em>id</em> values = idflag
idflag = <em>max</em> or <em>next</em> = how to choose IDs for inserted particles and molecules
<em>vol</em> values = fraction Nattempt
fraction = desired volume fraction for filling insertion volume
Nattempt = max # of insertion attempts per particle
<em>rate</em> value = V
V = z velocity (3d) or y velocity (2d) at which
insertion volume moves (velocity units)
<em>dens</em> values = Rholo Rhohi
Rholo,Rhohi = range of densities for inserted particles (mass/volume units)
<em>vel</em> values (3d) = vxlo vxhi vylo vyhi vz
<em>vel</em> values (2d) = vxlo vxhi vy
vxlo,vxhi = range of x velocities for inserted particles (velocity units)
vylo,vyhi = range of y velocities for inserted particles (velocity units)
vz = z velocity (3d) assigned to inserted particles (velocity units)
vy = y velocity (2d) assigned to inserted particles (velocity units)
<em>mol</em> value = template-ID
template-ID = ID of molecule template specified in a separate <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command
<em>molfrac</em> values = f1 f2 ... fN
f1 to fN = relative probability of creating each of N molecules in template-ID
<em>rigid</em> value = fix-ID
fix-ID = ID of <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid/small</span></a> command
<em>shake</em> value = fix-ID
fix-ID = ID of <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command
<em>ignore</em> value = none
skip any line or triangle particles when detecting possible
<p>Insert finite-size particles or molecules into the simulation box
every few timesteps within a specified region until N particles or
molecules have been inserted. This is typically used to model the
pouring of granular particles into a container under the influence of
gravity. For the remainder of this doc page, a single inserted atom
or molecule is referred to as a “particle”.</p>
<p>If inserted particles are individual atoms, they are assigned the
specified atom type. If they are molecules, the type of each atom in
the inserted molecule is specified in the file read by the
<a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command, and those values are added to the
specified atom type. E.g. if the file specifies atom types 1,2,3, and
those are the atom types you want for inserted molecules, then specify
<em>type</em> = 0. If you specify <em>type</em> = 2, the in the inserted molecule
will have atom types 3,4,5.</p>
<p>All atoms in the inserted particle are assigned to two groups: the
default group “all” and the group specified in the fix pour command
(which can also be “all”).</p>
<p>This command must use the <em>region</em> keyword to define an insertion
volume. The specified region must have been previously defined with a
<a class="reference internal" href="region.html"><span class="doc">region</span></a> command. It must be of type <em>block</em> or a z-axis
<em>cylinder</em> and must be defined with side = <em>in</em>. The cylinder style
of region can only be used with 3d simulations.</p>
<p>Individual atoms are inserted, unless the <em>mol</em> keyword is used. It
specifies a <em>template-ID</em> previously defined using the
<a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command, which reads a file that defines the
molecule. The coordinates, atom types, center-of-mass, moments of
inertia, etc, as well as any bond/angle/etc and special neighbor
information for the molecule can be specified in the molecule file.
See the <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command for details. The only
settings required to be in this file are the coordinates and types of
atoms in the molecule.</p>
<p>If the molecule template contains more than one molecule, the relative
probability of depositing each molecule can be specified by the
<em>molfrac</em> keyword. N relative probablities, each from 0.0 to 1.0, are
specified, where N is the number of molecules in the template. Each
time a molecule is inserted, a random number is used to sample from
the list of relative probabilities. The N values must sum to 1.0.</p>
<p>If you wish to insert molecules via the <em>mol</em> keyword, that will be
treated as rigid bodies, use the <em>rigid</em> keyword, specifying as its
value the ID of a separate <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid/small</span></a>
command which also appears in your input script.</p>
<p>If you wish to insert molecules via the <em>mol</em> keyword, that will have
their bonds or angles constrained via SHAKE, use the <em>shake</em> keyword,
specifying as its value the ID of a separate <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command which also appears in your input script.</p>
<p>Each timestep particles are inserted, they are placed randomly inside
the insertion volume so as to mimic a stream of poured particles. If
they are molecules they are also oriented randomly. Each atom in the
particle is tested for overlaps with existing particles, including
effects due to periodic boundary conditions if applicable. If an
overlap is detected, another random insertion attempt is made; see the
<em>vol</em> keyword discussion below. The larger the volume of the
insertion region, the more particles that can be inserted at any one
timestep. Particles are inserted again after enough time has elapsed
that the previously inserted particles fall out of the insertion
volume under the influence of gravity. Insertions continue every so
many timesteps until the desired # of particles has been inserted.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you are monitoring the temperature of a system where the
particle count is changing due to adding particles, you typically
should use the <a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify dynamic yes</span></a>
command for the temperature compute you are using.</p>
</div>
<hr class="docutils" />
<p>All other keywords are optional with defaults as shown below.</p>
<p>The <em>diam</em> option is only used when inserting atoms and specifes the
diameters of inserted particles. There are 3 styles: <em>one</em>, <em>range</em>,
or <em>poly</em>. For <em>one</em>, all particles will have diameter <em>D</em>. For
<em>range</em>, the diameter of each particle will be chosen randomly and
uniformly between the specified <em>Dlo</em> and <em>Dhi</em> bounds. For <em>poly</em>, a
series of <em>Npoly</em> diameters is specified. For each diameter a
percentage value from 0.0 to 1.0 is also specified. The <em>Npoly</em>
percentages must sum to 1.0. For the example shown above with “diam 2
0.7 0.4 1.5 0.6”, all inserted particles will have a diameter of 0.7
or 1.5. 40% of the particles will be small; 60% will be large.</p>
<p>Note that for molecule insertion, the diameters of individual atoms in
the molecule can be specified in the file read by the
<a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command. If not specified, the diameter of
each atom in the molecule has a default diameter of 1.0.</p>
<p>The <em>id</em> option has two settings which are used to determine the atom
or molecule IDs to assign to inserted particles/molecules. In both
cases a check is done of the current system to find the maximum
current atom and molecule ID of any existing particle. Newly inserted
particles and molecules are assigned IDs that increment those max
values. For the <em>max</em> setting, which is the default, this check is
done at every insertion step, which allows for particles to leave the
system, and their IDs to potentially be re-used. For the <em>next</em>
setting this check is done only once when the fix is specified, which
can be more efficient if you are sure particles will not be added in
some other way.</p>
<p>The <em>vol</em> option specifies what volume fraction of the insertion
volume will be filled with particles. For particles with a size
specified by the <em>diam range</em> keyword, they are assumed to all be of
maximum diamter <em>Dhi</em> for purposes of computing their contribution to
the volume fraction.</p>
<p>The higher the volume fraction value, the more particles are inserted
each timestep. Since inserted particles cannot overlap, the maximum
volume fraction should be no higher than about 0.6. Each timestep
particles are inserted, LAMMPS will make up to a total of M tries to
insert the new particles without overlaps, where M = # of inserted
particles * Nattempt. If LAMMPS is unsuccessful at completing all
insertions, it prints a warning.</p>
<p>The <em>dens</em> and <em>vel</em> options enable inserted particles to have a range
of densities or xy velocities. The specific values for a particular
inserted particle will be chosen randomly and uniformly between the
specified bounds. Internally, the density value for a particle is
converted to a mass, based on the radius (volume) of the particle.
The <em>vz</em> or <em>vy</em> value for option <em>vel</em> assigns a z-velocity (3d) or
y-velocity (2d) to each inserted particle.</p>
<p>The <em>rate</em> option moves the insertion volume in the z direction (3d)
or y direction (2d). This enables pouring particles from a
successively higher height over time.</p>
<p>The <em>ignore</em> option is useful when running a simulation that used line
segment (2d) or triangle (3d) particles, typically to define
boundaries for spherical granular particles to interact with. See the
<a class="reference internal" href="atom_style.html"><span class="doc">atom_style line or tri</span></a> command for details. Lines
and triangles store their size, and if the size is large it may
overlap (in a spherical sense) with the insertion region, even if the
line/triangle is oriented such that there is no actual overlap. This
can prevent particles from being inserted. The <em>ignore</em> keyword
causes the overlap check to skip any line or triangle particles.
Obviously you should only use it if there is in fact no overlap of the
line or triangle particles with the insertion region.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. This means you must be careful when restarting a
pouring simulation, when the restart file was written in the middle of
the pouring operation. Specifically, you should use a new fix pour
command in the input script for the restarted simulation that
continues the operation. You will need to adjust the arguments of the
original fix pour command to do this.</p>
<p>Also note that because the state of the random number generator is not
saved in restart files, you cannot do “exact” restarts with this fix,
where the simulation continues on the same as if no restart had taken
place. However, in a statistical sense, a restarted simulation should
produce the same behavior if you adjust the fix pour parameters
appropriately.</p>
<p>None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options are relevant to this
fix. No global or per-atom quantities are stored by this fix for
access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No
parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the GRANULAR package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>For 3d simulations, a gravity fix in the -z direction must be defined
for use in conjunction with this fix. For 2d simulations, gravity
must be defined in the -y direction.</p>
<p>The specified insertion region cannot be a “dynamic” region, as
defined by the <a class="reference internal" href="region.html"><span class="doc">region</span></a> command.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>zero or more keyword/value pairs may be appended</li>
<li>keyword = <em>q</em> or <em>mu</em> or <em>p0</em> or <em>v0</em> or <em>e0</em> or <em>tscale</em> or <em>damp</em> or <em>seed</em>or <em>f_max</em> or <em>N_f</em> or <em>eta</em> or <em>beta</em> or <em>T_init</em></li>
</ul>
<pre class="literal-block">
<em>q</em> value = cell mass-like parameter (mass^2/distance^4 units)
<em>mu</em> value = artificial viscosity (mass/distance/time units)
<em>p0</em> value = initial pressure in the shock equations (pressure units)
<em>v0</em> value = initial simulation cell volume in the shock equations (distance^3 units)
<em>e0</em> value = initial total energy (energy units)
<em>tscale</em> value = reduction in initial temperature (unitless fraction between 0.0 and 1.0)
<em>damp</em> value = damping parameter (time units) inverse of friction <i>&gamma;</i>
<em>seed</em> value = random number seed (positive integer)
<em>f_max</em> value = upper cutoff frequency of the vibration spectrum (1/time units)
<em>N_f</em> value = number of frequency bins (positive integer)
<em>eta</em> value = coupling constant between the shock system and the quantum thermal bath (positive unitless)
<em>beta</em> value = the quantum temperature is updated every beta time steps (positive integer)
<em>T_init</em> value = quantum temperature for the initial state (temperature units)
+fix 1 all qbmsst z 0.122 q 25 mu 0.9 tscale 0.01 damp 200 seed 35082 f_max 0.3 N_f 100 eta 1 beta 400 T_init 110 (liquid methane modeled with the REAX force field, real units)
+fix 2 all qbmsst z 72 q 40 tscale 0.05 damp 1 seed 47508 f_max 120.0 N_f 100 eta 1.0 beta 500 T_init 300 (quartz modeled with the BKS force field, metal units)
+</pre>
<p>Two example input scripts are given, including shocked alpha quartz
and shocked liquid methane. The input script first equilibrate an
initial state with the quantum thermal bath at the target temperature
and then apply the qbmsst to simulate shock compression with quantum
nuclear correction. The following two figures plot related quantities
<p>The fix qbmsst command couples the shock system to a quantum thermal
bath with a rate that is proportional to the change of the total
energy of the shock system, <i>etot</i> - <i>etot</i><sub>0</sub>.
Here <i>etot</i> consists of both the system energy and a thermal
term, see <a class="reference internal" href="#qi"><span class="std std-ref">(Qi)</span></a>, and <i>etot</i><sub>0</sub> = <em>e0</em> is the
initial total energy.</p>
<p>The <em>eta</em> (<i>&eta;</i>) parameter is a unitless coupling constant
between the shock system and the quantum thermal bath. A small <em>eta</em>
value cannot adjust the quantum temperature fast enough during the
temperature ramping period of shock compression while large <em>eta</em>
leads to big temperature oscillation. A value of <em>eta</em> between 0.3 and
1 is usually appropriate for simulating most systems under shock
compression. We observe that different values of <em>eta</em> lead to almost
the same final thermodynamic state behind the shock, as expected.</p>
<p>The quantum temperature is updated every <em>beta</em> (<i>&beta;</i>) steps
with an integration time interval <em>beta</em> times longer than the
simulation time step. In that case, <i>etot</i> is taken as its
average over the past <em>beta</em> steps. The temperature of the quantum
thermal bath <i>T</i><sup>qm</sup> changes dynamically according to
the following equation where &Delta;<i>t</i> is the MD time step and
<i>&gamma;</i> is the friction constant which is equal to the inverse
<li><em>dhugoniot</em> is the departure from the Hugoniot (temperature units).</li>
<li><em>drayleigh</em> is the departure from the Rayleigh line (pressure units).</li>
<li><em>lagrangian_speed</em> is the laboratory-frame Lagrangian speed (particle velocity) of the computational cell (velocity units).</li>
<li><em>lagrangian_position</em> is the computational cell position in the reference frame moving at the shock speed. This is the distance of the computational cell behind the shock front.</li>
<li><em>quantum_temperature</em> is the temperature of the quantum thermal bath <i>T</i><sup>qm</sup>.</li>
</ol>
<p>To print these quantities to the log file with descriptive column
headers, the following LAMMPS commands are suggested. Here the
<a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> energy command is also enabled to allow
the thermo keyword <em>etotal</em> to print the quantity <i>etot</i>. See
also the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command.</p>
+thermo_style custom step temp ke pe lz pzz etotal v_dhug v_dray v_lgr_vel v_lgr_pos v_T_qm f_fix_id
+</pre>
<p>The global scalar under the entry f_fix_id is the quantity of thermo
energy as an extra part of <i>etot</i>. This global scalar and the
vector of 5 quantities can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. It is worth noting that the
temp keyword under the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command print
the instantaneous classical temperature <i>T</i><sup>cl</sup> as
described in the command <a class="reference internal" href="fix_qtb.html"><span class="doc">fix qtb</span></a>.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix style is part of the USER-QTB package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>All cell dimensions must be periodic. This fix can not be used with a
triclinic cell. The QBMSST fix has been tested only for the group-ID
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Perform the charge equilibration (QEq) method as described in <a class="reference internal" href="fix_qeq_reax.html#rappe"><span class="std std-ref">(Rappe and Goddard)</span></a> and formulated in <a class="reference internal" href="neb.html#nakano"><span class="std std-ref">(Nakano)</span></a> (also known
as the matrix inversion method) and in <a class="reference internal" href="pair_smtbq.html#rick"><span class="std std-ref">(Rick and Stuart)</span></a> (also
known as the extended Lagrangian method) based on the
electronegativity equilization principle.</p>
<p>These fixes can be used with any <a class="reference internal" href="pair_style.html"><span class="doc">pair style</span></a> in
LAMMPS, so long as per-atom charges are defined. The most typical
use-case is in conjunction with a <a class="reference internal" href="pair_style.html"><span class="doc">pair style</span></a> that
performs charge equilibration periodically (e.g. every timestep), such
as the ReaxFF or Streitz-Mintmire potential.
But these fixes can also be used with
potentials that normally assume per-atom charges are fixed, e.g. a
<p>Because the charge equilibration calculation is effectively
independent of the pair style, these fixes can also be used to perform
a one-time assignment of charges to atoms. For example, you could
define the QEq fix, perform a zero-timestep run via the <a class="reference internal" href="run.html"><span class="doc">run</span></a>
command without any pair style defined which would set per-atom
charges (based on the current atom configuration), then remove the fix
via the <a class="reference internal" href="unfix.html"><span class="doc">unfix</span></a> command before performing further dynamics.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Computing and using charge values different from published
values defined for a fixed-charge potential like Buckingham or CHARMM
or AMBER, can have a strong effect on energies and forces, and
produces a different model than the published versions.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The <a class="reference internal" href="fix_qeq_comb.html"><span class="doc">fix qeq/comb</span></a> command must still be used
to perform charge equliibration with the <a class="reference internal" href="pair_comb.html"><span class="doc">COMB potential</span></a>. The <a class="reference internal" href="fix_qeq_reax.html"><span class="doc">fix qeq/reax</span></a>
command can be used to perform charge equilibration with the <a class="reference internal" href="pair_reax_c.html"><span class="doc">ReaxFF force field</span></a>, although fix qeq/shielded yields the
same results as fix qeq/reax if <em>Nevery</em>, <em>cutoff</em>, and <em>tolerance</em>
are the same. Eventually the fix qeq/reax command will be deprecated.</p>
</div>
<p>The QEq method minimizes the electrostatic energy of the system (or
equalizes the derivative of energy with respect to charge of all the
atoms) by adjusting the partial charge on individual atoms based on
interactions with their neighbors within <em>cutoff</em>. It reqires a few
parameters, in <em>metal</em> units, for each atom type which provided in a
file specified by <em>qfile</em>. The file has the following format</p>
<p>There is one line per atom type with the following parameters.
Only a subset of the parameters is used by each QEq style as descibed
below, thus the others can be set to 0.0 if desired.</p>
<ul class="simple">
<li><em>chi</em> = electronegativity in energy units</li>
<li><em>eta</em> = self-Coulomb potential in energy units</li>
<li><em>gamma</em> = shielded Coulomb constant defined by <a class="reference internal" href="#vanduin"><span class="std std-ref">ReaxFF force field</span></a> in distance units</li>
<li><em>zeta</em> = Slater type orbital exponent defined by the <a class="reference internal" href="pair_coul.html#streitz"><span class="std std-ref">Streitz-Mintmire</span></a> potential in reverse distance units</li>
<li><em>qcore</em> = charge of the nucleus defined by the <a class="reference internal" href="pair_coul.html#streitz"><span class="std std-ref">Streitz-Mintmire potential</span></a> potential in charge units</li>
</ul>
<p>The <em>qeq/point</em> style describes partial charges on atoms as point
charges. Interaction between a pair of charged particles is 1/r,
which is the simplest description of the interaction between charges.
Only the <em>chi</em> and <em>eta</em> parameters from the <em>qfile</em> file are used.
Note that Coulomb catastrophe can occur if repulsion between the pair
of charged particles is too weak. This style solves partial charges
on atoms via the matrix inversion method. A tolerance of 1.0e-6 is
usually a good number.</p>
<p>The <em>qeq/shielded</em> style describes partial charges on atoms also as
point charges, but uses a shielded Coulomb potential to describe the
interaction between a pair of charged particles. Interaction through
the shielded Coulomb is given by equation (13) of the <a class="reference internal" href="#vanduin"><span class="std std-ref">ReaxFF force field</span></a> paper. The shielding accounts for charge overlap
between charged particles at small separation. This style is the same
as <a class="reference internal" href="fix_qeq_reax.html"><span class="doc">fix qeq/reax</span></a>, and can be used with <a class="reference internal" href="pair_reax_c.html"><span class="doc">pair_style reax/c</span></a>. Only the <em>chi</em>, <em>eta</em>, and <em>gamma</em>
parameters from the <em>qfile</em> file are used. This style solves partial
charges on atoms via the matrix inversion method. A tolerance of
1.0e-6 is usually a good number.</p>
<p>The <em>qeq/slater</em> style describes partial charges on atoms as spherical
charge densities centered around atoms via the Slater 1<em>s</em> orbital, so
that the interaction between a pair of charged particles is the
product of two Slater 1<em>s</em> orbitals. The expression for the Slater
1<em>s</em> orbital is given under equation (6) of the
<a class="reference internal" href="pair_coul.html#streitz"><span class="std std-ref">Streitz-Mintmire</span></a> paper. Only the <em>chi</em>, <em>eta</em>, <em>zeta</em>, and
<em>qcore</em> parameters from the <em>qfile</em> file are used. This style solves
partial charges on atoms via the matrix inversion method. A tolerance
of 1.0e-6 is usually a good number. Keyword <em>alpha</em> can be used to
change the Slater type orbital exponent.</p>
<p>The <em>qeq/dynamic</em> style describes partial charges on atoms as point
charges that interact through 1/r, but the extended Lagrangian method
is used to solve partial charges on atoms. Only the <em>chi</em> and <em>eta</em>
parameters from the <em>qfile</em> file are used. Note that Coulomb
catastrophe can occur if repulsion between the pair of charged
particles is too weak. A tolerance of 1.0e-3 is usually a good
number. Keyword <em>qdamp</em> can be used to change the damping factor, while
keyword <em>qstep</em> can be used to change the time step size.</p>
<p>The <a class="reference internal" href="#shan"><span class="std std-ref">*qeq/fire*</span></a> style describes the same charge model and charge
solver as the <em>qeq/dynamic</em> style, but employs a FIRE minimization
algorithm to solve for equilibrium charges.
Keyword <em>qdamp</em> can be used to change the damping factor, while
keyword <em>qstep</em> can be used to change the time step size.</p>
<p>Note that <em>qeq/point</em>, <em>qeq/shielded</em>, and <em>qeq/slater</em> describe
different charge models, whereas the matrix inversion method and the
extended Lagrangian method (<em>qeq/dynamic</em> and <em>qeq/fire</em>) are
different solvers.</p>
<p>Note that <em>qeq/point</em>, <em>qeq/dynamic</em> and <em>qeq/fire</em> styles all describe
charges as point charges that interact through 1/r relationship, but
solve partial charges on atoms using different solvers. These three
styles should yield comparable results if
the QEq parameters and <em>Nevery</em>, <em>cutoff</em>, and <em>tolerance</em> are the
same. Style <em>qeq/point</em> is typically faster, <em>qeq/dynamic</em> scales
better on larger sizes, and <em>qeq/fire</em> is faster than <em>qeq/dynamic</em>.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">To avoid the evaluation of the derivative of charge with respect
to position, which is typically ill-defined, the system should have a
zero net charge.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Developing QEq parameters (chi, eta, gamma, zeta, and qcore) is
non-trivial. Charges on atoms are not guaranteed to equilibrate with
arbitrary choices of these parameters. We do not develop these QEq
paramters. See the examples/qeq directory for some examples.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about these fixes is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. No global scalar or vector or per-atom
quantities are stored by these fixes for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of these fixes
can be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a>
command.</p>
<p>Thexe fixes are invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>These fixes are part of the QEQ package. They are only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Perform charge equilibration (QeQ) in conjunction with the COMB
(Charge-Optimized Many-Body) potential as described in
<a class="reference internal" href="#comb-1"><span class="std std-ref">(COMB_1)</span></a> and <a class="reference internal" href="#comb-2"><span class="std std-ref">(COMB_2)</span></a>. It performs the charge
equilibration portion of the calculation using the so-called QEq
method, whereby the charge on each atom is adjusted to minimize the
energy of the system. This fix can only be used with the COMB
potential; see the <a class="reference internal" href="fix_qeq_reax.html"><span class="doc">fix qeq/reax</span></a> command for a QeQ
calculation that can be used with any potential.</p>
<p>Only charges on the atoms in the specified group are equilibrated.
The fix relies on the pair style (COMB in this case) to calculate the
per-atom electronegativity (effective force on the charges). An
electronegativity equalization calculation (or QEq) is performed in an
interative fashion, which in parallel requires communication at each
iteration for processors to exchange charge information about nearby
atoms with each other. See <a class="reference internal" href="#rappe-and-goddard"><span class="std std-ref">Rappe_and_Goddard</span></a> and
<a class="reference internal" href="#rick-and-stuart"><span class="std std-ref">Rick_and_Stuart</span></a> for details.</p>
<p>During a run, charge equilibration is peformed every <em>Nevery</em> time
steps. Charge equilibration is also always enforced on the first step
of each run. The <em>precision</em> argument controls the tolerance for the
difference in electronegativity for all atoms during charge
equilibration. <em>Precision</em> is a trade-off between the cost of
performing charge equilibration (more iterations) and accuracy.</p>
<p>If the <em>file</em> keyword is used, then information about each
equilibration calculation is written to the specifed file.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>respa</em> option is supported by this
fix. This allows to set at which level of the <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA</span></a>
integrator the fix is performing charge equilibration. Default is
the outermost level.</p>
<p>This fix produces a per-atom vector which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The vector stores the
gradient of the charge on each atom. The per-atom values be accessed
on any timestep.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>This fix can be invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix command currently only supports <a class="reference internal" href="pair_comb.html"><span class="doc">pair style *comb*</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Perform the charge equilibration (QEq) method as described in <a class="reference internal" href="#rappe"><span class="std std-ref">(Rappe and Goddard)</span></a> and formulated in <a class="reference internal" href="neb.html#nakano"><span class="std std-ref">(Nakano)</span></a>. It is
typically used in conjunction with the ReaxFF force field model as
implemented in the <a class="reference internal" href="pair_reax_c.html"><span class="doc">pair_style reax/c</span></a> command, but
it can be used with any potential in LAMMPS, so long as it defines and
uses charges on each atom. The <a class="reference internal" href="fix_qeq_comb.html"><span class="doc">fix qeq/comb</span></a>
command should be used to perform charge equliibration with the <a class="reference internal" href="pair_comb.html"><span class="doc">COMB potential</span></a>. For more technical details about the
charge equilibration performed by fix qeq/reax, see the
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. No global scalar or vector or per-atom
quantities are stored by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>This fix is invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-REAXC package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix does not correctly handle interactions
involving multiple periodic images of the same atom. Hence, it should not
be used for periodic cell dimensions less than 10 angstroms.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global scalar or vector or per-atom
quantities are stored by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-QMMM package. It is only enabled if
LAMMPS was built with that package. It also requires building a
library provided with LAMMPS. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The fix is only functional when LAMMPS is built as a library and
linked with a compatible QM program and a QM/MM frontend into a QM/MM
executable. See the lib/qmmm/README file for details.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+fix 1 all qtb temp 110 damp 200 seed 35082 f_max 0.3 N_f 100 (liquid methane modeled with the REAX force field, real units)
+fix 2 all nph iso 1.01325 1.01325 1
+fix 2 all qtb temp 300 damp 1 seed 47508 f_max 120.0 N_f 100 (quartz modeled with the BKS force field, metal units)
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>This command performs the quantum thermal bath scheme proposed by
<a class="reference internal" href="#dammak"><span class="std std-ref">(Dammak)</span></a> to include self-consistent quantum nuclear effects,
when used in conjunction with the <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> or <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> commands.</p>
<p>Classical molecular dynamics simulation does not include any quantum
nuclear effect. Quantum treatment of the vibrational modes will
introduce zero point energy into the system, alter the energy power
spectrum and bias the heat capacity from the classical limit. Missing
all the quantum nuclear effects, classical MD cannot model systems at
temperatures lower than their classical limits. This effect is
especially important for materials with a large population of hydrogen
atoms and thus higher classical limits.</p>
<p>The equation of motion implemented by this command follows a Langevin
</font></center><p>To efficiently generate the random forces, we employ the method
of <a class="reference internal" href="#barrat"><span class="std std-ref">(Barrat)</span></a>, that circumvents the need to generate all
random forces for all times before the simulation. The memory
requirement of this approach is less demanding and independent
of the simulation duration. Since the total random force <i>R</i><sub>tot</sub>
does not necessarily vanish for a finite number of atoms,
<i>R<sub>i</sub></i> is replaced by <i>R<sub>i</sub></i> - <i>R</i><sub>tot</sub>/<i>N</i><sub>tot</sub>
to avoid collective motion of the system.</p>
<p>The <em>temp</em> parameter sets the target quantum temperature. LAMMPS will
still have an output temperature in its thermo style. That is the
instantaneous classical temperature <i>T</i><sup>cl</sup> derived from
the atom velocities at thermal equilibrium. A non-zero
<i>T</i><sup>cl</sup> will be present even when the quantum
temperature approaches zero. This is associated with zero-point energy
</font></center><p>The <em>damp</em> parameter is specified in time units, and it equals the
inverse of the frictional coefficient <i>&gamma;</i>. <i>&gamma;</i>
should be as small as possible but slightly larger than the timescale
of anharmonic coupling in the system which is about 10 ps to 100
ps. When <i>&gamma;</i> is too large, it gives an energy spectrum that
differs from the desired Bose-Einstein spectrum. When <i>&gamma;</i>
is too small, the quantum thermal bath coupling to the system will be
less significant than anharmonic effects, reducing to a classical
limit. We find that setting <i>&gamma;</i> between 5 THz and 1 THz
could be appropriate depending on the system.</p>
<p>The random number <em>seed</em> is a positive integer used to initiate a
Marsaglia random number generator. Each processor uses the input seed
to generate its own unique seed and its own stream of random
numbers. Thus the dynamics of the system will not be identical on two
runs on different numbers of processors.</p>
<p>The <em>f_max</em> parameter truncate the noise frequency domain so that
vibrational modes with frequencies higher than <em>f_max</em> will not be
modulated. If we denote &Delta;<i>t</i> as the time interval for the
MD integration, <em>f_max</em> is always reset by the code to make
-<i>&alpha;</i> = (int)(2<em>f_max</em>&Delta;<i>t</i>)<sup><i>-1</i></sup> a
+<i>&alpha;</i> = (int)(2*f_max*&Delta;<i>t</i>)<sup><i>-1</i></sup> a
positive integer and print out relative information. An appropriate
value for the cutoff frequency <em>f_max</em> would be around 2~3
<i>f</i><sub>D</sub>, where <i>f</i><sub>D</sub> is the Debye
frequency.</p>
<p>The <em>N_f</em> parameter is the frequency grid size, the number of points
from 0 to <em>f_max</em> in the frequency domain that will be
sampled. <i>3&times;2</i> <em>N_f</em> per-atom random numbers are required
in the random force generation and there could be as many atoms as in
the whole simulation that can migrate into every individual
processor. A larger <em>N_f</em> provides a more accurate sampling of the
spectrum while consumes more memory. With fixed <em>f_max</em> and
<i>&gamma;</i>, <em>N_f</em> should be big enough to converge the classical
temperature <i>T</i><sup>cl</sup> as a function of target quantum bath
temperature. Memory usage per processor could be from 10 to 100
Mbytes.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Unlike the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command which performs
Nose/Hoover thermostatting AND time integration, this fix does NOT
perform time integration. It only modifies forces to a colored
thermostat. Thus you must use a separate time integration fix, like
<a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> or <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> to actually update the
velocities and positions of atoms (as shown in the
examples). Likewise, this fix should not normally be used with other
fixes or commands that also specify system temperatures , e.g. <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> and <a class="reference internal" href="fix_temp_rescale.html"><span class="doc">fix temp/rescale</span></a>.</p>
</div>
<hr class="docutils" />
<p><strong>Restart, fix_modify, output, run start/stop, minimizie info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Because the state of the random number generator
is not saved in restart files, this means you cannot do “exact”
restarts with this fix. However, in a statistical sense, a restarted
simulation should produce similar behaviors of the system.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix style is part of the USER-QTB package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Write out the bond information computed by the ReaxFF potential
specified by <a class="reference internal" href="pair_reax.html"><span class="doc">pair_style reax</span></a> or <a class="reference internal" href="pair_reax_c.html"><span class="doc">pair_style reax/c</span></a> in the exact same format as the original
stand-alone ReaxFF code of Adri van Duin. The bond information is
written to <em>filename</em> on timesteps that are multiples of <em>Nevery</em>,
including timestep 0. For time-averaged chemical species analysis,
please see the <a class="reference internal" href="fix_reaxc_species.html"><span class="doc">fix reaxc/c/species</span></a> command.</p>
<p>The format of the output file should be self-explantory.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The fix reax/bonds command requires that the <a class="reference internal" href="pair_reax.html"><span class="doc">pair_style reax</span></a> be invoked. This fix is part of the REAX
package. It is only enabled if LAMMPS was built with that package,
which also requires the REAX library be built and linked with LAMMPS.
The fix reax/c/bonds command requires that the <a class="reference internal" href="pair_reax_c.html"><span class="doc">pair_style reax/c</span></a> be invoked. This fix is part of the
USER-REAXC package. It is only enabled if LAMMPS was built with that
package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>This fix computes both a global vector of length 2 and a per-atom
vector, either of which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The values in the global
vector are “intensive”.</p>
<p>The 2 values in the global vector are as follows:</p>
<ul class="simple">
<li>1 = total number of molecules</li>
<li>2 = total number of distinct species</li>
</ul>
<p>The per-atom vector stores the molecule ID for each atom as identified
by the fix. If an atom is not in a molecule, its ID will be 0.
For atoms in the same molecule, the molecule ID for all of them
will be the same and will be equal to the smallest atom ID of
any atom in the molecule.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The fix species currently only works with
<a class="reference internal" href="pair_reax_c.html"><span class="doc">pair_style reax/c</span></a> and it requires that the <a class="reference internal" href="pair_reax_c.html"><span class="doc">pair_style reax/c</span></a> be invoked. This fix is part of the
USER-REAXC package. It is only enabled if LAMMPS was built with that
package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
for more info.</p>
<p>It should be possible to extend it to other reactive pair_styles (such as
<a class="reference internal" href="pair_comb.html"><span class="doc">comb</span></a>, and <a class="reference internal" href="pair_bop.html"><span class="doc">bop</span></a>), but this has not yet been done.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The <em>bond</em> keyword applies a bond restraint to the specified atoms
using the same functional form used by the <a class="reference internal" href="bond_harmonic.html"><span class="doc">bond_style harmonic</span></a> command. The potential associated with
<p>K and r0 are specified with the fix. Note that the usual 1/2 factor
is included in K.</p>
<hr class="docutils" />
<p>The <em>angle</em> keyword applies an angle restraint to the specified atoms
using the same functional form used by the <a class="reference internal" href="angle_harmonic.html"><span class="doc">angle_style harmonic</span></a> command. The potential associated with
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the potential energy associated with this fix to the
system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>respa</em> option is supported by this
fix. This allows to set at which level of the <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA</span></a>
integrator the fix is adding its forces. Default is the outermost level.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you want the fictitious potential energy associated with the
added forces to be included in the total potential energy of the
system (the quantity being minimized), you MUST enable the
<a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option for this fix.</p>
</div>
<p>This fix computes a global scalar, which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
potential energy for all the restraints as discussed above. The scalar
value calculated by this fix is “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>style = <em>rigid</em> or <em>rigid/nve</em> or <em>rigid/nvt</em> or <em>rigid/npt</em> or <em>rigid/nph</em> or <em>rigid/small</em> or <em>rigid/nve/small</em> or <em>rigid/nvt/small</em> or <em>rigid/npt/small</em> or <em>rigid/nph/small</em></li>
<li>bodystyle = <em>single</em> or <em>molecule</em> or <em>group</em></li>
</ul>
<pre class="literal-block">
<em>single</em> args = none
<em>molecule</em> args = none
<em>group</em> args = N groupID1 groupID2 ...
N = # of groups
groupID1, groupID2, ... = list of N group IDs
</pre>
<ul class="simple">
<li>zero or more keyword/value pairs may be appended</li>
<li>keyword = <em>langevin</em> or <em>temp</em> or <em>iso</em> or <em>aniso</em> or <em>x</em> or <em>y</em> or <em>z</em> or <em>couple</em> or <em>tparam</em> or <em>pchain</em> or <em>dilate</em> or <em>force</em> or <em>torque</em> or <em>infile</em></li>
Tstart,Tstop = desired temperature at start/stop of run (temperature units)
Tdamp = temperature damping parameter (time units)
seed = random number seed to use for white noise (positive integer)
<em>temp</em> values = Tstart Tstop Tdamp
Tstart,Tstop = desired temperature at start/stop of run (temperature units)
Tdamp = temperature damping parameter (time units)
<em>iso</em> or <em>aniso</em> values = Pstart Pstop Pdamp
Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
Pdamp = pressure damping parameter (time units)
<em>x</em> or <em>y</em> or <em>z</em> values = Pstart Pstop Pdamp
Pstart,Pstop = external stress tensor component at start/end of run (pressure units)
Pdamp = stress damping parameter (time units)
<em>couple</em> = <em>none</em> or <em>xyz</em> or <em>xy</em> or <em>yz</em> or <em>xz</em>
<em>tparam</em> values = Tchain Titer Torder
Tchain = length of Nose/Hoover thermostat chain
Titer = number of thermostat iterations performed
Torder = 3 or 5 = Yoshida-Suzuki integration parameters
<em>pchain</em> values = Pchain
Pchain = length of the Nose/Hoover thermostat chain coupled with the barostat
<em>dilate</em> value = dilate-group-ID
dilate-group-ID = only dilate atoms in this group due to barostat volume changes
<em>force</em> values = M xflag yflag zflag
M = which rigid body from 1-Nbody (see asterisk form below)
xflag,yflag,zflag = off/on if component of center-of-mass force is active
<em>torque</em> values = M xflag yflag zflag
M = which rigid body from 1-Nbody (see asterisk form below)
xflag,yflag,zflag = off/on if component of center-of-mass torque is active
<em>infile</em> filename
filename = file with per-body values of mass, center-of-mass, moments of inertia
<em>mol</em> value = template-ID
template-ID = ID of molecule template specified in a separate <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command
<p>Treat one or more sets of atoms as independent rigid bodies. This
means that each timestep the total force and torque on each rigid body
is computed as the sum of the forces and torques on its constituent
particles. The coordinates, velocities, and orientations of the atoms
in each body are then updated so that the body moves and rotates as a
single entity.</p>
<p>Examples of large rigid bodies are a colloidal particle, or portions
of a biomolecule such as a protein.</p>
<p>Example of small rigid bodies are patchy nanoparticles, such as those
modeled in <a class="reference internal" href="pair_gran.html#zhang"><span class="std std-ref">this paper</span></a> by Sharon Glotzer’s group, clumps of
granular particles, lipid molecules consiting of one or more point
dipoles connected to other spheroids or ellipsoids, irregular
particles built from line segments (2d) or triangles (3d), and
coarse-grain models of nano or colloidal particles consisting of a
small number of constituent particles. Note that the <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command can also be used to rigidify small
molecules of 2, 3, or 4 atoms, e.g. water molecules. That fix treats
the constituent atoms as point masses.</p>
<p>These fixes also update the positions and velocities of the atoms in
each rigid body via time integration, in the NVE, NVT, NPT, or NPH
ensemble, as described below.</p>
<p>There are two main variants of this fix, fix rigid and fix
rigid/small. The NVE/NVT/NPT/NHT versions belong to one of the two
variants, as their style names indicate.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Not all of the <em>bodystyle</em> options and keyword/value options are
available for both the <em>rigid</em> and <em>rigid/small</em> variants. See
details below.</p>
</div>
<p>The <em>rigid</em> styles are typically the best choice for a system with a
small number of large rigid bodies, each of which can extend across
the domain of many processors. It operates by creating a single
global list of rigid bodies, which all processors contribute to.
MPI_Allreduce operations are performed each timestep to sum the
contributions from each processor to the force and torque on all the
bodies. This operation will not scale well in parallel if large
numbers of rigid bodies are simulated.</p>
<p>The <em>rigid/small</em> styles are typically best for a system with a large
number of small rigid bodies. Each body is assigned to the atom
closest to the geometrical center of the body. The fix operates using
local lists of rigid bodies owned by each processor and information is
exchanged and summed via local communication between neighboring
processors when ghost atom info is accumlated.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">To use the <em>rigid/small</em> styles the ghost atom cutoff must be
large enough to span the distance between the atom that owns the body
and every other atom in the body. This distance value is printed out
when the rigid bodies are defined. If the
<a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> cutoff plus neighbor skin does not span
this distance, then you should use the <a class="reference internal" href="comm_modify.html"><span class="doc">comm_modify cutoff</span></a> command with a setting epsilon larger than
the distance.</p>
</div>
<p>Which of the two variants is faster for a particular problem is hard
to predict. The best way to decide is to perform a short test run.
Both variants should give identical numerical answers for short runs.
Long runs should give statistically similar results, but round-off
differences may accumulate to produce divergent trajectories.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">You should not update the atoms in rigid bodies via other
time-integration fixes (e.g. <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a>, <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>, <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a>), or you will be integrating
their motion more than once each timestep. When performing a hybrid
simulation with some atoms in rigid bodies, and some not, a separate
time integration fix like <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> or <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> should be used for the non-rigid particles.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">These fixes are overkill if you simply want to hold a collection
of atoms stationary or have them move with a constant velocity. A
simpler way to hold atoms stationary is to not include those atoms in
your time integration fix. E.g. use “fix 1 mobile nve” instead of
“fix 1 all nve”, where “mobile” is the group of atoms that you want to
move. You can move atoms with a constant velocity by assigning them
an initial velocity (via the <a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> command),
setting the force on them to 0.0 (via the <a class="reference internal" href="fix_setforce.html"><span class="doc">fix setforce</span></a> command), and integrating them as usual
(e.g. via the <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> command).</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The aggregate properties of each rigid body are calculated one
time at the start of the first simulation run after these fixes are
specified. The properties include the position and velocity of the
center-of-mass of the body, its moments of inertia, and its angular
momentum. This is done using the properties of the constituent atoms
of the body at that point in time (or see the <em>infile</em> keyword
option). Thereafter, changing properties of individual atoms in the
body will have no effect on a rigid body’s dynamics, unless they
affect the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> interactions that individual
particles are part of. For example, you might think you could
displace the atoms in a body or add a large velocity to each atom in a
body to make it move in a desired direction before a 2nd run is
performed, using the <a class="reference internal" href="set.html"><span class="doc">set</span></a> or
command. But these commands will not affect the internal attributes
of the body, and the position and velocity of individual atoms in the
body will be reset when time integration starts.</p>
</div>
<hr class="docutils" />
<p>Each rigid body must have two or more atoms. An atom can belong to at
most one rigid body. Which atoms are in which bodies can be defined
via several options.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">With the <em>rigid/small</em> styles, which require that <em>bodystyle</em> be
specified as <em>molecule</em>, you can define a system that has no rigid
bodies initially. This is useful when you are using the <em>mol</em> keyword
in conjunction with another fix that is adding rigid bodies on-the-fly
as molecules, such as <a class="reference internal" href="fix_deposit.html"><span class="doc">fix deposit</span></a> or <a class="reference internal" href="fix_pour.html"><span class="doc">fix pour</span></a>.</p>
</div>
<p>For bodystyle <em>single</em> the entire fix group of atoms is treated as one
rigid body. This option is only allowed for the <em>rigid</em> styles.</p>
<p>For bodystyle <em>molecule</em>, each set of atoms in the fix group with a
different molecule ID is treated as a rigid body. This option is
allowed for both the <em>rigid</em> and <em>rigid/small</em> styles. Note that
atoms with a molecule ID = 0 will be treated as a single rigid body.
For a system with atomic solvent (typically this is atoms with
molecule ID = 0) surrounding rigid bodies, this may not be what you
want. Thus you should be careful to use a fix group that only
includes atoms you want to be part of rigid bodies.</p>
<p>For bodystyle <em>group</em>, each of the listed groups is treated as a
separate rigid body. Only atoms that are also in the fix group are
included in each rigid body. This option is only allowed for the
<em>rigid</em> styles.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">To compute the initial center-of-mass position and other
properties of each rigid body, the image flags for each atom in the
body are used to “unwrap” the atom coordinates. Thus you must insure
that these image flags are consistent so that the unwrapping creates a
valid rigid body (one where the atoms are close together),
particularly if the atoms in a single rigid body straddle a periodic
boundary. This means the input data file or restart file must define
the image flags for each atom consistently or that you have used the
<a class="reference internal" href="set.html"><span class="doc">set</span></a> command to specify them correctly. If a dimension is
non-periodic then the image flag of each atom must be 0 in that
dimension, else an error is generated.</p>
</div>
<p>The <em>force</em> and <em>torque</em> keywords discussed next are only allowed for
the <em>rigid</em> styles.</p>
<p>By default, each rigid body is acted on by other atoms which induce an
external force and torque on its center of mass, causing it to
translate and rotate. Components of the external center-of-mass force
and torque can be turned off by the <em>force</em> and <em>torque</em> keywords.
This may be useful if you wish a body to rotate but not translate, or
vice versa, or if you wish it to rotate or translate continuously
unaffected by interactions with other particles. Note that if you
expect a rigid body not to move or rotate by using these keywords, you
must insure its initial center-of-mass translational or angular
velocity is 0.0. Otherwise the initial translational or angular
momentum the body has will persist.</p>
<p>An xflag, yflag, or zflag set to <em>off</em> means turn off the component of
force of torque in that dimension. A setting of <em>on</em> means turn on
the component, which is the default. Which rigid body(s) the settings
apply to is determined by the first argument of the <em>force</em> and
<em>torque</em> keywords. It can be an integer M from 1 to Nbody, where
Nbody is the number of rigid bodies defined. A wild-card asterisk can
be used in place of, or in conjunction with, the M argument to set the
-flags for multiple rigid bodies. This takes the form “*” or “<em>n” or
-“n</em>” or “m*n”. If N = the number of rigid bodies, then an asterisk
+flags for multiple rigid bodies. This takes the form “*” or “*n” or
+“n*” or “m*n”. If N = the number of rigid bodies, then an asterisk
with no numeric values means all bodies from 1 to N. A leading
asterisk means all bodies from 1 to n (inclusive). A trailing
asterisk means all bodies from n to N (inclusive). A middle asterisk
means all types from m to n (inclusive). Note that you can use the
<em>force</em> or <em>torque</em> keywords as many times as you like. If a
particular rigid body has its component flags set multiple times, the
settings from the final keyword are used.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For computational efficiency, you may wish to turn off pairwise
and bond interactions within each rigid body, as they no longer
contribute to the motion. The <a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify exclude</span></a> and <a class="reference internal" href="delete_bonds.html"><span class="doc">delete_bonds</span></a>
commands are used to do this. If the rigid bodies have strongly
overalapping atoms, you may need to turn off these interactions to
avoid numerical problems due to large equal/opposite intra-body forces
swamping the contribution of small inter-body forces.</p>
</div>
<p>For computational efficiency, you should typically define one fix
rigid or fix rigid/small command which includes all the desired rigid
bodies. LAMMPS will allow multiple rigid fixes to be defined, but it
is more expensive.</p>
<hr class="docutils" />
<p>The constituent particles within a rigid body can be point particles
(the default in LAMMPS) or finite-size particles, such as spheres or
ellipsoids or line segments or triangles. See the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style sphere and ellipsoid and line and tri</span></a> commands for more
details on these kinds of particles. Finite-size particles contribute
differently to the moment of inertia of a rigid body than do point
particles. Finite-size particles can also experience torque (e.g. due
to <a class="reference internal" href="pair_gran.html"><span class="doc">frictional granular interactions</span></a>) and have an
orientation. These contributions are accounted for by these fixes.</p>
<p>Forces between particles within a body do not contribute to the
external force or torque on the body. Thus for computational
efficiency, you may wish to turn off pairwise and bond interactions
between particles within each rigid body. The <a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify exclude</span></a> and <a class="reference internal" href="delete_bonds.html"><span class="doc">delete_bonds</span></a>
commands are used to do this. For finite-size particles this also
means the particles can be highly overlapped when creating the rigid
body.</p>
<hr class="docutils" />
<p>The <em>rigid</em>, <em>rigid/nve</em>, <em>rigid/small</em>, and <em>rigid/small/nve</em> styles
perform constant NVE time integration. They are referred to below as
the 4 NVE rigid styles. The only difference is that the <em>rigid</em> and
<em>rigid/small</em> styles use an integration technique based on Richardson
iterations. The <em>rigid/nve</em> and <em>rigid/small/nve</em> styles uses the
methods described in the paper by <a class="reference internal" href="#miller"><span class="std std-ref">Miller</span></a>, which are thought
to provide better energy conservation than an iterative approach.</p>
<p>The <em>rigid/nvt</em> and <em>rigid/nvt/small</em> styles performs constant NVT
integration using a Nose/Hoover thermostat with chains as described
originally in <a class="reference internal" href="#hoover"><span class="std std-ref">(Hoover)</span></a> and <a class="reference internal" href="#martyna"><span class="std std-ref">(Martyna)</span></a>, which
thermostats both the translational and rotational degrees of freedom
of the rigid bodies. They are referred to below as the 2 NVT rigid
styles. The rigid-body algorithm used by <em>rigid/nvt</em> is described in
the paper by <a class="reference internal" href="#kamberaj"><span class="std std-ref">Kamberaj</span></a>.</p>
<p>The <em>rigid/npt</em>, <em>rigid/nph</em>, <em>rigid/npt/small</em>, and <em>rigid/nph/small</em>
styles perform constant NPT or NPH integration using a Nose/Hoover
barostat with chains. They are referred to below as the 4 NPT and NPH
rigid styles. For the NPT case, the same Nose/Hoover thermostat is
also used as with <em>rigid/nvt</em> and <em>rigid/nvt/small</em>.</p>
<p>The barostat parameters are specified using one or more of the <em>iso</em>,
<em>aniso</em>, <em>x</em>, <em>y</em>, <em>z</em> and <em>couple</em> keywords. These keywords give you
the ability to specify 3 diagonal components of the external stress
tensor, and to couple these components together so that the dimensions
they represent are varied together during a constant-pressure
simulation. The effects of these keywords are similar to those
defined in <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt/nph</span></a></p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Currently the <em>rigid/npt</em>, <em>rigid/nph</em>, <em>rigid/npt/small</em>, and
<em>rigid/nph/small</em> styles do not support triclinic (non-orthongonal)
boxes.</p>
</div>
<p>The target pressures for each of the 6 components of the stress tensor
can be specified independently via the <em>x</em>, <em>y</em>, <em>z</em> keywords, which
correspond to the 3 simulation box dimensions. For each component,
the external pressure or tensor component at each timestep is a ramped
value during the run from <em>Pstart</em> to <em>Pstop</em>. If a target pressure is
specified for a component, then the corresponding box dimension will
change during a simulation. For example, if the <em>y</em> keyword is used,
the y-box length will change. A box dimension will not change if that
component is not specified, although you have the option to change
that dimension via the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> command.</p>
<p>For all barostat keywords, the <em>Pdamp</em> parameter operates like the
<em>Tdamp</em> parameter, determining the time scale on which pressure is
relaxed. For example, a value of 10.0 means to relax the pressure in
a timespan of (roughly) 10 time units (e.g. tau or fmsec or psec - see
the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command).</p>
<p>Regardless of what atoms are in the fix group (the only atoms which
are time integrated), a global pressure or stress tensor is computed
for all atoms. Similarly, when the size of the simulation box is
changed, all atoms are re-scaled to new positions, unless the keyword
<em>dilate</em> is specified with a <em>dilate-group-ID</em> for a group that
represents a subset of the atoms. This can be useful, for example, to
leave the coordinates of atoms in a solid substrate unchanged and
controlling the pressure of a surrounding fluid. Another example is a
system consisting of rigid bodies and point particles where the
barostat is only coupled with the rigid bodies. This option should be
used with care, since it can be unphysical to dilate some atoms and
not others, because it can introduce large, instantaneous
displacements between a pair of atoms (one dilated, one not) that are
far from the dilation origin.</p>
<p>The <em>couple</em> keyword allows two or three of the diagonal components of
the pressure tensor to be “coupled” together. The value specified
with the keyword determines which are coupled. For example, <em>xz</em>
means the <em>Pxx</em> and <em>Pzz</em> components of the stress tensor are coupled.
<em>Xyz</em> means all 3 diagonal components are coupled. Coupling means two
things: the instantaneous stress will be computed as an average of the
corresponding diagonal components, and the coupled box dimensions will
be changed together in lockstep, meaning coupled dimensions will be
dilated or contracted by the same percentage every timestep. The
<em>Pstart</em>, <em>Pstop</em>, <em>Pdamp</em> parameters for any coupled dimensions must
be identical. <em>Couple xyz</em> can be used for a 2d simulation; the <em>z</em>
dimension is simply ignored.</p>
<p>The <em>iso</em> and <em>aniso</em> keywords are simply shortcuts that are
equivalent to specifying several other keywords together.</p>
<p>The keyword <em>iso</em> means couple all 3 diagonal components together when
pressure is computed (hydrostatic pressure), and dilate/contract the
dimensions together. Using “iso Pstart Pstop Pdamp” is the same as
<p>The keyword/value option pairs are used in the following ways.</p>
<p>The <em>langevin</em> and <em>temp</em> and <em>tparam</em> keywords perform thermostatting
of the rigid bodies, altering both their translational and rotational
degrees of freedom. What is meant by “temperature” of a collection of
rigid bodies and how it can be monitored via the fix output is
discussed below.</p>
<p>The <em>langevin</em> keyword applies a Langevin thermostat to the constant
NVE time integration performed by any of the 4 NVE rigid styles:
<em>rigid</em>, <em>rigid/nve</em>, <em>rigid/small</em>, <em>rigid/small/nve</em>. It cannot be
used with the 2 NVT rigid styles: <em>rigid/nvt</em>, <em>rigid/small/nvt</em>. The
desired temperature at each timestep is a ramped value during the run
from <em>Tstart</em> to <em>Tstop</em>. The <em>Tdamp</em> parameter is specified in time
units and determines how rapidly the temperature is relaxed. For
example, a value of 100.0 means to relax the temperature in a timespan
of (roughly) 100 time units (tau or fmsec or psec - see the
<a class="reference internal" href="units.html"><span class="doc">units</span></a> command). The random # <em>seed</em> must be a positive
integer.</p>
<p>The way that Langevin thermostatting operates is explained on the <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> doc page. If you wish to simply viscously
damp the rotational motion without thermostatting, you can set
<em>Tstart</em> and <em>Tstop</em> to 0.0, which means only the viscous drag term in
the Langevin thermostat will be applied. See the discussion on the
<a class="reference internal" href="fix_viscous.html"><span class="doc">fix viscous</span></a> doc page for details.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When the <em>langevin</em> keyword is used with fix rigid versus fix
rigid/small, different dynamics will result for parallel runs. This
is because of the way random numbers are used in the two cases. The
dynamics for the two cases should be statistically similar, but will
not be identical, even for a single timestep.</p>
</div>
<p>The <em>temp</em> and <em>tparam</em> keywords apply a Nose/Hoover thermostat to the
NVT time integration performed by the 2 NVT rigid styles. They cannot
be used with the 4 NVE rigid styles. The desired temperature at each
timestep is a ramped value during the run from <em>Tstart</em> to <em>Tstop</em>.
The <em>Tdamp</em> parameter is specified in time units and determines how
rapidly the temperature is relaxed. For example, a value of 100.0
means to relax the temperature in a timespan of (roughly) 100 time
units (tau or fmsec or psec - see the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command).</p>
<p>Nose/Hoover chains are used in conjunction with this thermostat. The
<em>tparam</em> keyword can optionally be used to change the chain settings
used. <em>Tchain</em> is the number of thermostats in the Nose Hoover chain.
This value, along with <em>Tdamp</em> can be varied to dampen undesirable
oscillations in temperature that can occur in a simulation. As a rule
of thumb, increasing the chain length should lead to smaller
oscillations. The keyword <em>pchain</em> specifies the number of
thermostats in the chain thermostatting the barostat degrees of
freedom.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">There are alternate ways to thermostat a system of rigid bodies.
You can use <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> to treat the individual
particles in the rigid bodies as effectively immersed in an implicit
solvent, e.g. a Brownian dynamics model. For hybrid systems with both
rigid bodies and solvent particles, you can thermostat only the
solvent particles that surround one or more rigid bodies by
appropriate choice of groups in the compute and fix commands for
temperature and thermostatting. The solvent interactions with the
rigid bodies should then effectively thermostat the rigid body
temperature as well without use of the Langevin or Nose/Hoover options
associated with the fix rigid commands.</p>
</div>
<hr class="docutils" />
<p>The <em>mol</em> keyword can only be used with the <em>rigid/small</em> styles. It
must be used when other commands, such as <a class="reference internal" href="fix_deposit.html"><span class="doc">fix deposit</span></a> or <a class="reference internal" href="fix_pour.html"><span class="doc">fix pour</span></a>, add rigid
bodies on-the-fly during a simulation. You specify a <em>template-ID</em>
previously defined using the <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command, which
reads a file that defines the molecule. You must use the same
<em>template-ID</em> that the other fix which is adding rigid bodies uses.
The coordinates, atom types, atom diameters, center-of-mass, and
moments of inertia can be specified in the molecule file. See the
<a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command for details. The only settings
required to be in this file are the coordinates and types of atoms in
the molecule, in which case the molecule command calculates the other
quantities itself.</p>
<p>Note that these other fixes create new rigid bodies, in addition to
those defined initially by this fix via the <em>bodystyle</em> setting.</p>
<p>Also note that when using the <em>mol</em> keyword, extra restart information
about all rigid bodies is written out whenever a restart file is
written out. See the NOTE in the next section for details.</p>
<hr class="docutils" />
<p>The <em>infile</em> keyword allows a file of rigid body attributes to be read
in from a file, rather then having LAMMPS compute them. There are 5
such attributes: the total mass of the rigid body, its center-of-mass
position, its 6 moments of inertia, its center-of-mass velocity, and
the 3 image flags of the center-of-mass position. For rigid bodies
consisting of point particles or non-overlapping finite-size
particles, LAMMPS can compute these values accurately. However, for
rigid bodies consisting of finite-size particles which overlap each
other, LAMMPS will ignore the overlaps when computing these 4
attributes. The amount of error this induces depends on the amount of
overlap. To avoid this issue, the values can be pre-computed
(e.g. using Monte Carlo integration).</p>
<p>The format of the file is as follows. Note that the file does not
have to list attributes for every rigid body integrated by fix rigid.
Only bodies which the file specifies will have their computed
attributes overridden. The file can contain initial blank lines or
comment lines starting with “#” which are ignored. The first
non-blank, non-comment line should list N = the number of lines to
follow. The N successive lines contain the following information:</p>
<p>The rigid body IDs are all positive integers. For the <em>single</em>
bodystyle, only an ID of 1 can be used. For the <em>group</em> bodystyle,
IDs from 1 to Ng can be used where Ng is the number of specified
groups. For the <em>molecule</em> bodystyle, use the molecule ID for the
atoms in a specific rigid body as the rigid body ID.</p>
<p>The masstotal and center-of-mass coordinates (xcm,ycm,zcm) are
self-explanatory. The center-of-mass should be consistent with what
is calculated for the position of the rigid body with all its atoms
unwrapped by their respective image flags. If this produces a
center-of-mass that is outside the simulation box, LAMMPS wraps it
back into the box.</p>
<p>The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
values consistent with the current orientation of the rigid body
around its center of mass. The values are with respect to the
simulation box XYZ axes, not with respect to the prinicpal axes of the
rigid body itself. LAMMPS performs the latter calculation internally.</p>
<p>The (vxcm,vycm,vzcm) values are the velocity of the center of mass.
The (lx,ly,lz) values are the angular momentum of the body. The
(vxcm,vycm,vzcm) and (lx,ly,lz) values can simply be set to 0 if you
wish the body to have no initial motion.</p>
<p>The (ixcm,iycm,izcm) values are the image flags of the center of mass
of the body. For periodic dimensions, they specify which image of the
simulation box the body is considered to be in. An image of 0 means
it is inside the box as defined. A value of 2 means add 2 box lengths
to get the true value. A value of -1 means subtract 1 box length to
get the true value. LAMMPS updates these flags as the rigid bodies
cross periodic boundaries during the simulation.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you use the <em>infile</em> or <em>mol</em> keywords and write restart
files during a simulation, then each time a restart file is written,
the fix also write an auxiliary restart file with the name
rfile.rigid, where “rfile” is the name of the restart file,
e.g. tmp.restart.10000 and tmp.restart.10000.rigid. This auxiliary
file is in the same format described above. Thus it can be used in a
new input script that restarts the run and re-specifies a rigid fix
using an <em>infile</em> keyword and the appropriate filename. Note that the
auxiliary file will contain one line for every rigid body, even if the
original file only listed a subset of the rigid bodies.</p>
</div>
<hr class="docutils" />
<p>If you use a <a class="reference internal" href="compute.html"><span class="doc">temperature compute</span></a> with a group that
includes particles in rigid bodies, the degrees-of-freedom removed by
each rigid body are accounted for in the temperature (and pressure)
computation, but only if the temperature group includes all the
particles in a particular rigid body.</p>
<p>A 3d rigid body has 6 degrees of freedom (3 translational, 3
rotational), except for a collection of point particles lying on a
straight line, which has only 5, e.g a dimer. A 2d rigid body has 3
degrees of freedom (2 translational, 1 rotational).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">You may wish to explicitly subtract additional
degrees-of-freedom if you use the <em>force</em> and <em>torque</em> keywords to
eliminate certain motions of one or more rigid bodies. LAMMPS does
not do this automatically.</p>
</div>
<p>The rigid body contribution to the pressure of the system (virial) is
also accounted for by this fix.</p>
<hr class="docutils" />
<p>If your simlulation is a hybrid model with a mixture of rigid bodies
and non-rigid particles (e.g. solvent) there are several ways these
rigid fixes can be used in tandem with <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a>, <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>, <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a>, and <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a>.</p>
<p>If you wish to perform NVE dynamics (no thermostatting or
barostatting), use one of 4 NVE rigid styles to integrate the rigid
bodies, and <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> to integrate the non-rigid
particles.</p>
<p>If you wish to perform NVT dynamics (thermostatting, but no
barostatting), you can use one of the 2 NVT rigid styles for the rigid
bodies, and any thermostatting fix for the non-rigid particles (<a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>, <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a>, <a class="reference internal" href="fix_temp_berendsen.html"><span class="doc">fix temp/berendsen</span></a>). You can also use one of the
4 NVE rigid styles for the rigid bodies and thermostat them using <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> on the group that contains all the
particles in the rigid bodies. The net force added by <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> to each rigid body effectively thermostats
its translational center-of-mass motion. Not sure how well it does at
thermostatting its rotational motion.</p>
<p>If you with to perform NPT or NPH dynamics (barostatting), you cannot
use both <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> and the NPT or NPH rigid styles. This
is because there can only be one fix which monitors the global
pressure and changes the simulation box dimensions. So you have 3
choices:</p>
<ul class="simple">
<li>Use one of the 4 NPT or NPH styles for the rigid bodies. Use the
<em>dilate</em> all option so that it will dilate the positions of the
non-rigid particles as well. Use <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> (or any other
thermostat) for the non-rigid particles.</li>
<li>Use <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> for the group of non-rigid particles. Use
the <em>dilate</em> all option so that it will dilate the center-of-mass
positions of the rigid bodies as well. Use one of the 4 NVE or 2 NVT
rigid styles for the rigid bodies.</li>
<li>Use <a class="reference internal" href="fix_press_berendsen.html"><span class="doc">fix press/berendsen</span></a> to compute the
pressure and change the box dimensions. Use one of the 4 NVE or 2 NVT
rigid styles for the rigid bodies. Use <a class="reference external" href="fix_nh.thml">fix nvt</a> (or any
other thermostat) for the non-rigid particles.</li>
</ul>
<p>In all case, the rigid bodies and non-rigid particles both contribute
to the global pressure and the box is scaled the same by any of the
barostatting fixes.</p>
<p>You could even use the 2nd and 3rd options for a non-hybrid simulation
consisting of only rigid bodies, assuming you give <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> an empty group, though it’s an odd thing to do. The
barostatting fixes (<a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> and <a class="reference internal" href="fix_press_berendsen.html"><span class="doc">fix press/berensen</span></a>) will monitor the pressure
and change the box dimensions, but not time integrate any particles.
The integration of the rigid bodies will be performed by fix
rigid/nvt.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about the 4 NVE rigid styles is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. The exception is if the <em>infile</em> or
<em>mol</em> keyword is used, in which case an auxiliary file is written out
with rigid body information each time a restart file is written, as
explained above for the <em>infile</em> keyword. For the 2 NVT rigid styles,
the state of the Nose/Hoover thermostat is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Ditto for the 4 NPT and NPH rigid styles, and
the state of the Nose/Hoover barostat. See the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for info on how to re-specify
a fix in an input script that reads a restart file, so that the
operation of the fix continues in an uninterrupted fashion.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by the 6
NVT, NPT, NPH rigid styles to add the energy change induced by the
thermostatting to the system’s potential energy as part of
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> and <em>press</em> options are
supported by the 4 NPT and NPH rigid styles to change the computes
used to calculate the instantaneous pressure tensor. Note that the 2
NVT rigid fixes do not use any external compute to compute
instantaneous temperature.</p>
<p>The 2 NVE rigid fixes compute a global scalar which can be accessed by
various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar
value calculated by these fixes is “intensive”. The scalar is the
current temperature of the collection of rigid bodies. This is
averaged over all rigid bodies and their translational and rotational
degrees of freedom. The translational energy of a rigid body is 1/2 m
v^2, where m = total mass of the body and v = the velocity of its
center of mass. The rotational energy of a rigid body is 1/2 I w^2,
where I = the moment of inertia tensor of the body and w = its angular
velocity. Degrees of freedom constrained by the <em>force</em> and <em>torque</em>
keywords are removed from this calculation, but only for the <em>rigid</em>
and <em>rigid/nve</em> fixes.</p>
<p>The 6 NVT, NPT, NPH rigid fixes compute a global scalar which can be
accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>.
The scalar value calculated by these fixes is “extensive”. The scalar
is the cumulative energy change due to the thermostatting and
barostatting the fix performs.</p>
<p>All of the <em>rigid</em> styles (not the <em>rigid/small</em> styles) compute a
global array of values which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. Similar information about the
bodies defined by the <em>rigid/small</em> styles can be accessed via the
<p>These fixes are all part of the RIGID package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Assigning a temperature via the <a class="reference internal" href="velocity.html"><span class="doc">velocity create</span></a>
command to a system with <a class="reference internal" href="#"><span class="doc">rigid bodies</span></a> may not have
the desired outcome for two reasons. First, the velocity command can
be invoked before the rigid-body fix is invoked or initialized and the
number of adjusted degrees of freedom (DOFs) is known. Thus it is not
possible to compute the target temperature correctly. Second, the
assigned velocities may be partially canceled when constraints are
first enforced, leading to a different temperature than desired. A
workaround for this is to perform a <a class="reference internal" href="run.html"><span class="doc">run 0</span></a> command, which
insures all DOFs are accounted for properly, and then rescale the
temperature to the desired value before performing a simulation. For
<span class="n">run</span> <span class="mi">0</span> <span class="c1"># temperature may not be 300K</span>
<span class="n">velocity</span> <span class="nb">all</span> <span class="n">scale</span> <span class="mf">300.0</span> <span class="c1"># now it should be</span>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>rx = style name of this fix command</li>
<li>file = filename containing the reaction kinetic equations and Arrhenius parameters</li>
<li>localTemp = <em>none,lucy</em> = no local temperature averaging or local temperature defined through Lucy weighting function</li>
<li>matrix = <em>sparse, dense</em> format for the stoichiometric matrix</li>
<li>solver = <em>lammps_rk4,rkf45</em> = rk4 is an explicit 4th order Runge-Kutta method; rkf45 is an adaptive 4th-order Runge-Kutta-Fehlberg method</li>
<li>minSteps = # of steps for rk4 solver or minimum # of steps for rkf45 (rk4 or rkf45)</li>
<li>maxSteps = maximum number of steps for the rkf45 solver (rkf45 only)</li>
<li>relTol = relative tolerance for the rkf45 solver (rkf45 only)</li>
<li>absTol = absolute tolernace for the rkf45 solver (rkf45 only)</li>
<li>diag = Diagnostics frequency for the rkf45 solver (optional, rkf45 only)</li>
<p>In the current implementation, the exponents are defined to be equal
to the stoichiometric coefficients. A given reaction set consisting
of <em>n</em> reaction equations will contain a total of <em>m</em> species. A set
of <em>m</em> ordinary differential equations (ODEs) that describe the change
in concentration of a given species as a function of time are then
constructed based on the <em>n</em> reaction rate equations.</p>
<p>The ODE systems are solved over the full DPD timestep <em>dt</em> using either a 4th
order Runge-Kutta <em>rk4</em> method with a fixed step-size <em>h</em>, specified
by the <em>lammps_rk4</em> keyword, or a 4th order Runge-Kutta-Fehlberg (rkf45) method
with an adaptive step-size for <em>h</em>. The number of ODE steps per DPD timestep
for the rk4 method is optionally specified immediately after the rk4
keyword. The ODE step-size is set as <em>dt/num_steps</em>. Smaller
step-sizes tend to yield more accurate results but there is not
control on the error. For error control, use the rkf45 ODE solver.</p>
<p>The rkf45 method adjusts the step-size so that the local truncation error is held
within the specified absolute and relative tolerances. The initial step-size <em>h0</em>
can be specified by the user or estimated internally. It is recommeded that the user
specify <em>h0</em> since this will generally reduced the number of ODE integration steps
required. <em>h0</em> is defined as <em>dt / min_steps</em> if min_steps >= 1. If min_steps == 0,
<em>h0</em> is estimated such that an explicit Euler method would likely produce
an acceptable solution. This is generally overly conservative for the 4th-order
method and users are advised to specify <em>h0</em> as some fraction of the DPD timestep.
For small DPD timesteps, only one step may be necessary depending upon the tolerances.
Note that more than min_steps ODE steps may be taken depending upon the ODE stiffness
but no more than max_steps will be taken. If max_steps is reached, an error warning
is printed and the simulation is stopped.</p>
<p>After each ODE step, the solution error <em>e</em> is tested and weighted using the absTol
and relTol values. The error vector is weighted as <em>e</em> / (relTol * <a href="#id1"><span class="problematic" id="id2">|</span></a><em>u</em>| + absTol)
where <em>u</em> is the solution vector. If the norm of the error is <= 1, the solution is
accepted, <em>h</em> is increased by a proportional amount, and the next ODE step is begun.
Otherwise, <em>h</em> is shrunk and the ODE step is repeated.</p>
<p>Run-time diagnostics are available for the rkf45 ODE solver. The frequency
(in time-steps) that diagnostics are reported is controlled by the last (optional)
12th argument. A negative frequency means that diagnostics are reported once at the
end of each run. A positive value N means that the diagnostics are reported once
per N time-steps.</p>
<p>The diagnostics report the average # of integrator steps and RHS function evaluations
and run-time per ODE as well as the the average/RMS/min/max per process. If the
reporting frequency is 1, the RMS/min/max per ODE are also reported. The per ODE
statistics can be used to adjust the tolerance and min/max step parameters. The
statistics per MPI process can be useful to examine any load imbalance caused by the
adaptive ODE solver. (Some DPD particles can take longer to solve than others. This
can lead to an imbalance across the MPI processes.)</p>
<hr class="docutils" />
<p>The filename specifies a file that contains the entire set of reaction
kinetic equations and corresponding Arrhenius parameters. The format of
this file is described below.</p>
<p>There is no restriction on the total number or reaction equations that
are specified. The species names are arbitrary string names that are
associated with the species concentrations. Each species in a given
reaction must be preceded by it’s stoichiometric coefficient. The
only delimiters that are recognized between the species are either a
<em>+</em> or <em>=</em> character. The <em>=</em> character corresponds to an
irreversible reaction. After specifying the reaction, the reaction
rate constant is determined through the temperature dependent
<p>The self-particle interaction is included in the above equation.</p>
<p>The stoichiometric coefficients for the reaction mechanism are stored
in either a sparse or dense matrix format. The dense matrix should only be
used for small reaction mechanisms. The sparse matrix should be used when there
are many reactions (e.g., more than 5). This allows the number of reactions and
species to grow while keeping the computational cost tractable. The matrix
format can be specified as using either the <em>sparse</em> or <em>dense</em> keywords.
If all stoichiometric coefficients for a reaction are small integers (whole
numbers <= 3), a fast exponential function is used. This can save significant
computational time so users are encouraged to use integer coefficients
where possible.</p>
<hr class="docutils" />
<p>The format of a tabulated file is as follows (without the
parenthesized comments):</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># Rxn equations and parameters (one or more comment or blank lines)</span>
<p>A section begins with a non-blank line whose 1st character is not a
“#”; blank lines or lines starting with “#” can be used as comments
between sections.</p>
<p>Following a blank line, the next N lines list the N reaction
equations. Each species within the reaction equation is specified
through its stoichiometric coefficient and a species tag. Reactant
species are specified on the left-hand side of the equation and
product species are specified on the right-hand side of the equation.
After specifying the reactant and product species, the final three
arguments of each line represent the Arrhenius parameter <em>A</em>, the
temperature exponent <em>n</em>, and the activation energy <em>Ea</em>.</p>
<p>Note that the species tags that are defined in the reaction equations
are used by the <a class="reference internal" href="fix_eos_table_rx.html"><span class="doc">fix eos/table/rx</span></a> command to
define the thermodynamic properties of each species. Furthermore, the
number of species molecules (i.e., concentration) can be specified
-either with the <a class="reference internal" href="set.html"><span class="doc">set</span></a> command using the “<a href="#id3"><span class="problematic" id="id4">d_</span></a>” prefix or by
+either with the <a class="reference internal" href="set.html"><span class="doc">set</span></a> command using the “d_” prefix or by
reading directly the concentrations from a data file. For the latter
case, the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command with the fix keyword
should be specified, where the fix-ID will be the “fix rx`ID with a <SPECIES”>`_ suffix, e.g.</p>
<p>This command is part of the USER-DPD package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This command also requires use of the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style dpd</span></a>
command.</p>
<p>This command can only be used with a constant energy or constant
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The attributes for fix_saed_vtk must match the values assigned in the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>style = shake or rattle = style name of this fix command</li>
<li>tol = accuracy tolerance of SHAKE solution</li>
<li>iter = max # of iterations in each SHAKE solution</li>
<li>N = print SHAKE statistics every this many timesteps (0 = never)</li>
<li>one or more constraint/value pairs are appended</li>
<li>constraint = <em>b</em> or <em>a</em> or <em>t</em> or <em>m</em></li>
</ul>
<pre class="literal-block">
<em>b</em> values = one or more bond types
<em>a</em> values = one or more angle types
<em>t</em> values = one or more atom types
<em>m</em> value = one or more mass values
</pre>
<ul class="simple">
<li>zero or more keyword/value pairs may be appended</li>
<li>keyword = <em>mol</em></li>
</ul>
<pre class="literal-block">
<em>mol</em> value = template-ID
template-ID = ID of molecule template specified in a separate <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command
<p>The SHAKE algorithm satisfies the first condition, i.e. the sites at
time <em>n+1</em> will have the desired separations Dij immediately after the
coordinates are integrated. If we also enforce the second condition,
the velocity components along the bonds will vanish. RATTLE satisfies
both conditions. As implemented in LAMMPS, fix rattle uses fix shake
for satisfying the coordinate constraints. Therefore the settings and
optional keywords are the same for both fixes, and all the information
below about SHAKE is also relevant for RATTLE.</p>
<p><strong>SHAKE:</strong></p>
<p>Each timestep the specified bonds and angles are reset to their
equilibrium lengths and angular values via the SHAKE algorithm
(<a class="reference internal" href="#ryckaert"><span class="std std-ref">Ryckaert et al. (1977)</span></a>). This is done by applying an
additional constraint force so that the new positions preserve the
desired atom separations. The equations for the additional force are
solved via an iterative method that typically converges to an accurate
solution in a few iterations. The desired tolerance (e.g. 1.0e-4 = 1
part in 10000) and maximum # of iterations are specified as arguments.
Setting the N argument will print statistics to the screen and log
file about regarding the lengths of bonds and angles that are being
constrained. Small delta values mean SHAKE is doing a good job.</p>
<p>In LAMMPS, only small clusters of atoms can be constrained. This is
so the constraint calculation for a cluster can be performed by a
single processor, to enable good parallel performance. A cluster is
defined as a central atom connected to others in the cluster by
constrained bonds. LAMMPS allows for the following kinds of clusters
to be constrained: one central atom bonded to 1 or 2 or 3 atoms, or
one central atom bonded to 2 others and the angle between the 3 atoms
also constrained. This means water molecules or CH2 or CH3 groups may
be constrained, but not all the C-C backbone bonds of a long polymer
chain.</p>
<p>The <em>b</em> constraint lists bond types that will be constrained. The <em>t</em>
constraint lists atom types. All bonds connected to an atom of the
specified type will be constrained. The <em>m</em> constraint lists atom
masses. All bonds connected to atoms of the specified masses will be
constrained (within a fudge factor of MASSDELTA specified in
fix_shake.cpp). The <em>a</em> constraint lists angle types. If both bonds
in the angle are constrained then the angle will also be constrained
if its type is in the list.</p>
<p>For all constraints, a particular bond is only constrained if both
atoms in the bond are in the group specified with the SHAKE fix.</p>
<p>The degrees-of-freedom removed by SHAKE bonds and angles are accounted
for in temperature and pressure computations. Similarly, the SHAKE
contribution to the pressure of the system (virial) is also accounted
for.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">This command works by using the current forces on atoms to
caculate an additional constraint force which when added will leave
the atoms in positions that satisfy the SHAKE constraints (e.g. bond
length) after the next time integration step. If you define fixes
(e.g. <a class="reference internal" href="fix_efield.html"><span class="doc">fix efield</span></a>) that add additional force to the
atoms after fix shake operates, then this fix will not take them into
account and the time integration will typically not satisfy the SHAKE
constraints. The solution for this is to make sure that fix shake is
defined in your input script after any other fixes which add or change
forces (to atoms that fix shake operates on).</p>
</div>
<hr class="docutils" />
<p>The <em>mol</em> keyword should be used when other commands, such as <a class="reference internal" href="fix_deposit.html"><span class="doc">fix deposit</span></a> or <a class="reference internal" href="fix_pour.html"><span class="doc">fix pour</span></a>, add molecules
on-the-fly during a simulation, and you wish to contrain the new
molecules via SHAKE. You specify a <em>template-ID</em> previously defined
using the <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command, which reads a file that
defines the molecule. You must use the same <em>template-ID</em> that the
command adding molecules uses. The coordinates, atom types, special
bond restrictions, and SHAKE info can be specified in the molecule
file. See the <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command for details. The only
settings required to be in this file (by this command) are the SHAKE
info of atoms in the molecule.</p>
<hr class="docutils" />
<p>Styles with a 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 in
<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<hr class="docutils" />
<p><strong>RATTLE:</strong></p>
<p>The velocity constraints lead to a linear system of equations which
can be solved analytically. The implementation of the algorithm in
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about these fixes is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to these fixes. No global or per-atom quantities are
stored by these fixes for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of these fixes
can be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a>
command. These fixes are not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>These fixes are part of the RIGID package. They are only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>For computational efficiency, there can only be one shake or rattle
fix defined in a simulation.</p>
<p>If you use a tolerance that is too large or a max-iteration count that
is too small, the constraints will not be enforced very strongly,
which can lead to poor energy conservation. You can test for this in
your system by running a constant NVE simulation with a particular set
of SHAKE parameters and monitoring the energy versus time.</p>
<p>SHAKE or RATTLE should not be used to contrain an angle at 180 degrees
(e.g. linear CO2 molecule). This causes numeric difficulties.</p>
<p><strong>Related commands:</strong> none</p>
<p><strong>Default:</strong> none</p>
<hr class="docutils" />
<p id="ryckaert"><strong>(Ryckaert)</strong> J.-P. Ryckaert, G. Ciccotti and H. J. C. Berendsen,
J of Comp Phys, 23, 327-341 (1977).</p>
<p id="andersen"><strong>(Andersen)</strong> H. Andersen, J of Comp Phys, 52, 24-34 (1983).</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>The fix stores the direction of the spring, current pulling target
distance and the running PMF to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.
See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for info on how to
re-specify a fix in an input script that reads a restart file, so that
the operation of the fix continues in an uninterrupted fashion.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>respa</em> option is supported by
this fix. This allows to set at which level of the <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA</span></a>
integrator the fix is adding its forces. Default is the outermost level.</p>
<p>This fix computes a vector list of 7 quantities, which can be accessed
by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The
quantities in the vector are in this order: the x-, y-, and
z-component of the pulling force, the total force in direction of the
pull, the equilibrium distance of the spring, the distance between the
two reference points, and finally the accumulated PMF (the sum of
pulling forces times displacement).</p>
<p>The force is the total force on the group of atoms by the spring. In
the case of the <em>couple</em> style, it is the force on the fix group
(group-ID) or the negative of the force on the 2nd group (group-ID2).
The vector values calculated by this fix are “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-MISC package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>Currently, no part of USER-SMD supports restarting nor minimization.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-SMD package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>Currently, no part of USER-SMD supports restarting nor minimization. This fix has no outputs.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-SMD package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+fix 1 all smd/integrate_ulsph adjust_radius 1.02 25 50
+</pre>
+<pre class="literal-block">
+fix 1 all smd/integrate_ulsph limit_velocity 1000
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>The fix performs explicit time integration for particles which interact with the updated Lagrangian SPH pair style.
See <a class="reference external" href="USER/smd/SMD_LAMMPS_userguide.pdf">this PDF guide</a> to using Smooth Mach Dynamics in LAMMPS.</p>
<p>The <em>adjust_radius</em> keyword activates dynamic adjustment of the per-particle SPH smoothing kernel radius such that the number of neighbors per particles remains
within the interval <em>min_nn</em> to <em>max_nn</em>. The parameter <em>adjust_radius_factor</em> determines the amount of adjustment per timestep. Typical values are
-<em>adjust_radius_factor</em>=1.02, <em>min_nn</em>=15, and <em>max_nn</em>=20.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>Currently, no part of USER-SMD supports restarting nor minimization. This fix has no outputs.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-SMD package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This fix applies only to rigid surfaces read from .STL files via fix <a class="reference internal" href="fix_smd_wall_surface.html"><span class="doc">smd/wall_surface</span></a> .
It updates position and velocity for the particles in the group each timestep without regard to forces on the particles.
The rigid surfaces can thus be moved along simple trajectories during the simulation.</p>
-<p>The <a href="#id19"><span class="problematic" id="id20">**</span></a>LINEAR* style moves particles with the specified constant velocity
+<p>The <em>*LINEAR</em> style moves particles with the specified constant velocity
vector V = (Vx,Vy,Vz). This style also sets the velocity of each particle
to V = (Vx,Vy,Vz).</p>
-<p>The <a href="#id21"><span class="problematic" id="id22">**</span></a>WIGGLE* style moves particles in an oscillatory fashion.
+<p>The <em>*WIGGLE</em> style moves particles in an oscillatory fashion.
Particles are moved along (vx, vy, vz) with constant velocity until a
displacement of max_travel is reached. Then, the velocity vector is
reversed. This process is repeated.</p>
-<p>The <a href="#id23"><span class="problematic" id="id24">**</span></a>ROTATE* style rotates particles around a rotation axis R = (Rx,Ry,Rz) that
+<p>The <em>*ROTATE</em> style rotates particles around a rotation axis R = (Rx,Ry,Rz) that
goes through a point P = (Px,Py,Pz). The period of the rotation is also
specified. This style also sets the velocity of each particle to (omega cross
Rperp) where omega is its angular velocity around the rotation axis and
Rperp is a perpendicular vector from the rotation axis to the particle.</p>
<p>See <a class="reference external" href="USER/smd/SMD_LAMMPS_userguide.pdf">this PDF guide</a> to using Smooth Mach Dynamics in LAMMPS.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>Currently, no part of USER-SMD supports restarting nor minimization. This fix has no outputs.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-SMD package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Set each component of velocity on each particle in the group to the specified
values vx,vy,vz, regardless of the forces acting on the particle. This command can
be used to impose velocity boundary conditions.</p>
<p>Any of the vx,vy,vz values can be specified as NULL which means do not
alter the velocity component in that dimension.</p>
<p>This fix is indented to be used together with a time integration fix.</p>
<p>Any of the 3 quantities defining the velocity components can be specified
as an equal-style or atom-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>, namely <em>vx</em>,
<em>vy</em>, <em>vz</em>. If the value is a variable, it should be specified as
v_name, where name is the variable name. In this case, the variable
will be evaluated each timestep, and its value used to determine the
force component.</p>
<p>Equal-style variables can specify formulas with various mathematical
functions, and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent velocity field.</p>
<p>Atom-style variables can specify the same formulas as equal-style
variables but can also include per-atom values, such as atom
coordinates. Thus it is easy to specify a spatially-dependent velocity
field with optional time-dependence as well.</p>
<p>If the <em>region</em> keyword is used, the particle must also be in the
specified geometric <a class="reference internal" href="region.html"><span class="doc">region</span></a> in order to have its velocity set by this command.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>Currently, no part of USER-SMD supports restarting nor minimization
None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>This fix computes a global 3-vector of forces, which can be accessed
by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. This is the
total force on the group of atoms. The vector values calculated by this
fix are “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-SMD package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+fix stl_surf all smd/wall_surface tool.stl 2 65535
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>This fix creates reads a traingulated surface from a file in .STL format.
For each triangle, a new particle is created which stores the barycenter of the triangle and the vertex positions.
The radius of the new particle is that of the minimum circle which encompasses the triangle vertices.</p>
<p>The triangulated surface can be used as a complex rigid wall via the <a class="reference internal" href="pair_smd_triangulated_surface.html"><span class="doc">smd/tri_surface</span></a> pair style.
It is possible to move the triangulated surface via the <a class="reference internal" href="fix_smd_move_triangulated_surface.html"><span class="doc">smd/move_tri_surf</span></a> fix style.</p>
<p>Immediately after a .STL file has been read, the simulation needs to be run for 0 timesteps in order to properly register the new particles
in the system. See the “funnel_flow” example in the USER-SMD examples directory.</p>
<p>See <a class="reference external" href="USER/smd/SMD_LAMMPS_userguide.pdf">this PDF guide</a> to use Smooth Mach Dynamics in LAMMPS.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>Currently, no part of USER-SMD supports restarting nor minimization. This fix has no outputs.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-SMD package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
section for more info. The molecule ID given to the particles created by this fix have to be equal to or larger than 65535.</p>
<p>Within each .STL file, only a single triangulated object must be present, even though the STL format allows for the possibility of multiple objects in one file.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy stored in the spring to the system’s potential
energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>respa</em> option is supported by this
fix. This allows to set at which level of the <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA</span></a>
integrator the fix is adding its forces. Default is the outermost level.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
spring energy = 0.5 * K * r^2.</p>
<p>This fix also computes global 4-vector which can be accessed by
various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The first 3
quantities in the vector are xyz components of the total force added
to the group of atoms by the spring. In the case of the <em>couple</em>
style, it is the force on the fix group (group-ID) or the negative of
the force on the 2nd group (group-ID2). The 4th quantity in the
vector is the magnitude of the force added by the spring, as a
positive value if (r-R0) > 0 and a negative value if (r-R0) < 0. This
sign convention can be useful when using the spring force to compute a
potential of mean force (PMF).</p>
<p>The scalar and vector values calculated by this fix are “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>The forces due to this fix are imposed during an energy minimization,
invoked by the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you want the spring energy to be included in the total
potential energy of the system (the quantity being minimized), you
MUST enable the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option for this
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy stored in all the springs to the system’s potential
energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>respa</em> option is supported by this
fix. This allows to set at which level of the <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA</span></a>
integrator the fix is adding its forces. Default is the outermost level.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
energy of all the springs, i.e. 0.5 * K * r^2 per-spring.</p>
<p>The scalar value calculated by this fix is “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>The forces due to this fix are imposed during an energy minimization,
invoked by the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you want the spring energies to be included in the total
potential energy of the system (the quantity being minimized), you
MUST enable the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option for this
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>respa</em> option is supported by this
fix. This allows to set at which level of the <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA</span></a>
integrator the fix is adding its forces. Default is the outermost level.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the original coordinates of tethered atoms to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so that the spring effect will be the
same in a restarted simulation. See the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for info on how to re-specify
a fix in an input script that reads a restart file, so that the
operation of the fix continues in an uninterrupted fashion.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy stored in the per-atom springs to the system’s
potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>respa</em> option is supported by
this fix. This allows to set at which level of the <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA</span></a>
integrator the fix is adding its forces. Default is the outermost level.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is an
energy which is the sum of the spring energy for each atom, where the
per-atom energy is 0.5 * K * r^2. The scalar value calculated by this
fix is “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>The forces due to this fix are imposed during an energy minimization,
invoked by the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you want the per-atom spring energy to be included in the
total potential energy of the system (the quantity being minimized),
you MUST enable the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option for
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Define a fix that stores attributes for each atom in the group at the
time the fix is defined. If <em>N</em> is 0, then the values are never
updated, so this is a way of archiving an atom attribute at a given
time for future use in a calculation or output. See the discussion of
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a> that take fixes as
inputs.</p>
<p>If <em>N</em> is not zero, then the attributes will be updated every <em>N</em>
steps.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Actually, only atom attributes specified by keywords like <em>xu</em>
or <em>vy</em> or <em>radius</em> are initially stored immediately at the point in
your input script when the fix is defined. Attributes specified by a
compute, fix, or variable are not initially stored until the first run
following the fix definition begins. This is because calculating
those attributes may require quantities that are not defined in
between runs.</p>
</div>
<p>The list of possible attributes is the same as that used by the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command, which describes their meaning.</p>
<p>If the <em>com</em> keyword is set to <em>yes</em> then the <em>xu</em>, <em>yu</em>, and <em>zu</em>
inputs store the position of each atom relative to the center-of-mass
of the group of atoms, instead of storing the absolute position.</p>
<p>The requested values are stored in a per-atom vector or array as
discussed below. Zeroes are stored for atoms not in the specified
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the per-atom values it stores to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so that the values can be restored when a
simulation is restarted. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.</p>
<p>None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options are relevant to this
fix.</p>
<p>If a single input is specified, this fix produces a per-atom vector.
If multiple inputs are specified, a per-atom array is produced where
the number of columns for each atom is the number of inputs. These
can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The per-atom values be
accessed on any timestep.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p><em>Tstart</em> can be specified as an equal-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>.
In this case, the <em>Tstop</em> setting is ignored. If the value is a
variable, it should be specified as v_name, where name is the variable
name. In this case, the variable will be evaluated each timestep, and
its value used to determine the target temperature.</p>
<p>Equal-style variables can specify formulas with various mathematical
functions, and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent temperature.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Unlike the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command which performs
Nose/Hoover thermostatting AND time integration, this fix does NOT
perform time integration. It only modifies velocities to effect
thermostatting. Thus you must use a separate time integration fix,
like <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> to actually update the positions of atoms
using the modified velocities. Likewise, this fix should not normally
be used on atoms that also have their temperature controlled by
another fix - e.g. by <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> or <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> commands.</p>
</div>
<p>See <a class="reference internal" href="Section_howto.html#howto-16"><span class="std std-ref">this howto section</span></a> of the manual for
a discussion of different ways to compute temperature and perform
thermostatting.</p>
<p>This fix computes a temperature each timestep. To do this, the fix
creates its own compute of style “temp”, as if this command had been
<p>See the <a class="reference internal" href="compute_temp.html"><span class="doc">compute temp</span></a> command for details. Note
that the ID of the new compute is the fix-ID + underscore + “temp”,
and the group for the new compute is the same as the fix group.</p>
<p>Note that this is NOT the compute used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>.
This means you can change the attributes of this fix’s temperature
(e.g. its degrees-of-freedom) via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> will have no
effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to assign a temperature <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>
you have defined to this fix which will be used in its thermostatting
procedure, as described above. For consistency, the group used by
this fix and by the compute should be the same.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change implied by a velocity rescaling to the
system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
cummulative energy change due to this fix. The scalar value
calculated by this fix is “extensive”.</p>
<p>This fix can ramp its target temperature over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix can be used with dynamic groups as defined by the
<a class="reference internal" href="group.html"><span class="doc">group</span></a> command. Likewise it can be used with groups to
which atoms are added or deleted over time, e.g. a deposition
simulation. However, the conservation properties of the thermostat
and barostat are defined for systems with a static set of atoms. You
may observe odd behavior if the atoms in a group vary dramatically
over time or the atom count becomes very small.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p><em>Tstart</em> can be specified as an equal-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>.
In this case, the <em>Tstop</em> setting is ignored. If the value is a
variable, it should be specified as v_name, where name is the variable
name. In this case, the variable will be evaluated each timestep, and
its value used to determine the target temperature.</p>
<p>Equal-style variables can specify formulas with various mathematical
functions, and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent temperature.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Unlike the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command which performs
Nose/Hoover thermostatting AND time integration, these fixes do NOT
perform time integration. They only modify velocities to effect
thermostatting. Thus you must use a separate time integration fix,
like <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> to actually update the positions of atoms
using the modified velocities. Likewise, these fixes should not
normally be used on atoms that also have their temperature controlled
by another fix - e.g. by <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> or <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> commands.</p>
</div>
<p>See <a class="reference internal" href="Section_howto.html#howto-16"><span class="std std-ref">this howto section</span></a> of the manual for
a discussion of different ways to compute temperature and perform
thermostatting.</p>
<p>These fixes compute a temperature each timestep. To do this, the fix
creates its own compute of style “temp”, as if this command had been
<p>See the <a class="reference internal" href="compute_temp.html"><span class="doc">compute temp</span></a> command for details. Note
that the ID of the new compute is the fix-ID + underscore + “temp”,
and the group for the new compute is the same as the fix group.</p>
<p>Note that this is NOT the compute used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>.
This means you can change the attributes of this fix’s temperature
(e.g. its degrees-of-freedom) via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> will have no
effect on this fix.</p>
<p>Like other fixes that perform thermostatting, these fixes can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about these fixes are written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by these
fixes. You can use it to assign a temperature <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>
you have defined to these fixes which will be used in its thermostatting
procedure, as described above. For consistency, the group used by
these fixes and by the compute should be the same.</p>
<p>These fixes can ramp its target temperature over multiple runs, using
the <em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>These fixes are not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
<p>These fixes compute a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
cummulative energy change due to the fix. The scalar value
calculated by this fix is “extensive”.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>These fixes are not compatible with <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a>.</p>
<p>The fix can be used with dynamic groups as defined by the
<a class="reference internal" href="group.html"><span class="doc">group</span></a> command. Likewise it can be used with groups to
which atoms are added or deleted over time, e.g. a deposition
simulation. However, the conservation properties of the thermostat
and barostat are defined for systems with a static set of atoms. You
may observe odd behavior if the atoms in a group vary dramatically
over time or the atom count becomes very small.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Reset the temperature of a group of atoms by explicitly rescaling
their velocities.</p>
<p>The rescaling is applied to only the translational degrees of freedom
for the particles, which is an important consideration if finite-size
particles which have rotational degrees of freedom are being
thermostatted with this fix. The translational degrees of freedom can
also have a bias velocity removed from them before thermostatting
takes place; see the description below.</p>
<p>Rescaling is performed every N timesteps. The target temperature is a
ramped value between the <em>Tstart</em> and <em>Tstop</em> temperatures at the
beginning and end of the run.</p>
<p><em>Tstart</em> can be specified as an equal-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>.
In this case, the <em>Tstop</em> setting is ignored. If the value is a
variable, it should be specified as v_name, where name is the variable
name. In this case, the variable will be evaluated each timestep, and
its value used to determine the target temperature.</p>
<p>Equal-style variables can specify formulas with various mathematical
functions, and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent temperature.</p>
<p>Rescaling is only performed if the difference between the current and
desired temperatures is greater than the <em>window</em> value. The amount
of rescaling that is applied is a <em>fraction</em> (from 0.0 to 1.0) of the
difference between the actual and desired temperature. E.g. if
<em>fraction</em> = 1.0, the temperature is reset to exactly the desired
value.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Unlike the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command which performs
Nose/Hoover thermostatting AND time integration, this fix does NOT
perform time integration. It only modifies velocities to effect
thermostatting. Thus you must use a separate time integration fix,
like <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> to actually update the positions of atoms
using the modified velocities. Likewise, this fix should not normally
be used on atoms that also have their temperature controlled by
another fix - e.g. by <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> or <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> commands.</p>
</div>
<p>See <a class="reference internal" href="Section_howto.html#howto-16"><span class="std std-ref">this howto section</span></a> of the manual for
a discussion of different ways to compute temperature and perform
thermostatting.</p>
<p>This fix computes a temperature each timestep. To do this, the fix
creates its own compute of style “temp”, as if one of this command had
<p>See the <a class="reference internal" href="compute_temp.html"><span class="doc">compute temp</span></a> for details. Note that the
ID of the new compute is the fix-ID + underscore + “temp”, and the
group for the new compute is the same as the fix group.</p>
<p>Note that this is NOT the compute used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>.
This means you can change the attributes of this fix’s temperature
(e.g. its degrees-of-freedom) via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> will have no
effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to assign a temperature <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>
you have defined to this fix which will be used in its thermostatting
procedure, as described above. For consistency, the group used by
this fix and by the compute should be the same.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change implied by a velocity rescaling to the
system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
cummulative energy change due to this fix. The scalar value
calculated by this fix is “extensive”.</p>
<p>This fix can ramp its target temperature over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Reset the temperature of a group of nuclei and electrons in the
<a class="reference internal" href="pair_eff.html"><span class="doc">electron force field</span></a> model by explicitly rescaling
their velocities.</p>
<p>The operation of this fix is exactly like that described by the <a class="reference internal" href="fix_temp_rescale.html"><span class="doc">fix temp/rescale</span></a> command, except that the rescaling
is also applied to the radial electron velocity for electron
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to assign a temperature <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>
you have defined to this fix which will be used in its thermostatting
procedure, as described above. For consistency, the group used by
this fix and by the compute should be the same.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change implied by a velocity rescaling to the
system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
cummulative energy change due to this fix. The scalar value
calculated by this fix is “extensive”.</p>
<p>This fix can ramp its target temperature over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-EFF package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Perform uniform-acceptance force-bias Monte Carlo (fbMC) simulations,
using the time-stamped force-bias Monte Carlo (tfMC) algorithm
described in <a class="reference internal" href="#mees"><span class="std std-ref">(Mees)</span></a> and <a class="reference internal" href="#bal"><span class="std std-ref">(Bal)</span></a>.</p>
<p>One successful use case of force-bias Monte Carlo methods is that they
can be used to extend the time scale of atomistic simulations, in
particular when long time scale relaxation effects must be considered;
some interesting examples are given in the review by <a class="reference internal" href="#neyts"><span class="std std-ref">(Neyts)</span></a>.
An example of a typical use case would be the modelling of chemical
vapour deposition (CVD) processes on a surface, in which impacts by
gas-phase species can be performed using MD, but subsequent relaxation
of the surface is too slow to be done using MD only. Using tfMC can
allow for a much faster relaxation of the surface, so that higher
fluxes can be used, effectively extending the time scale of the
simulation. (Such an alternating simulation approach could be set up
using a <a class="reference internal" href="jump.html"><span class="doc">loop</span></a>.)</p>
<p>The initial version of tfMC algorithm in <a class="reference internal" href="#mees"><span class="std std-ref">(Mees)</span></a> contained an
estimation of the effective time scale of such a simulation, but it
was later shown that the speed-up one can gain from a tfMC simulation
is system- and process-dependent, ranging from none to several orders
of magnitude. In general, solid-state processes such as
(re)crystallisation or growth can be accelerated by up to two or three
orders of magnitude, whereas diffusion in the liquid phase is not
accelerated at all. The observed pseudodynamics when using the tfMC
method is not the actual dynamics one would obtain using MD, but the
relative importance of processes can match the actual relative
dynamics of the system quite well, provided <em>Delta</em> is chosen with
care. Thus, the system’s equilibrium is reached faster than in MD,
along a path that is generally roughly similar to a typical MD
simulation (but not necessarily so). See <a class="reference internal" href="#bal"><span class="std std-ref">(Bal)</span></a> for details.</p>
<p>Each step, all atoms in the selected group are displaced using the
stochastic tfMC algorithm, which is designed to sample the canonical
(NVT) ensemble at the temperature <em>Temp</em>. Although tfMC is a Monte
Carlo algorithm and thus strictly speaking does not perform time
integration, it is similar in the sense that it uses the forces on all
atoms in order to update their positions. Therefore, it is implemented
as a time integration fix, and no other fixes of this type (such as
<a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a>) should be used at the same time. Because
velocities do not play a role in this kind of Monte Carlo simulations,
instantaneous temperatures as calculated by <a class="reference internal" href="compute_temp.html"><span class="doc">temperature computes</span></a> or <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a> have no meaning: the only relevant
temperature is the sampling temperature <em>Temp</em>. Similarly, performing
tfMC simulations does not require setting a <a class="reference internal" href="timestep.html"><span class="doc">timestep</span></a>
and the <a class="reference internal" href="thermo_style.html"><span class="doc">simulated time</span></a> as calculated by LAMMPS is
meaningless.</p>
<p>The critical parameter determining the success of a tfMC simulation is
<em>Delta</em>, the maximal displacement length of the lightest element in
the system: the larger it is, the longer the effective time scale of
the simulation will be (there is an approximately quadratic
dependence). However, <em>Delta</em> must also be chosen sufficiently small
in order to comply with detailed balance; in general values between 5
and 10 % of the nearest neighbor distance are found to be a good
choice. For a more extensive discussion with specific examples, please
refer to <a class="reference internal" href="#bal"><span class="std std-ref">(Bal)</span></a>, which also describes how the code calculates
element-specific maximal displacements from <em>Delta</em>, based on the
fourth root of their mass.</p>
<p>Because of the uncorrelated movements of the atoms, the center-of-mass
of the fix group will not necessarily be stationary, just like its
orientation. When the <em>com</em> keyword is used, all atom positions will
be shifted (after every tfMC iteration) in order to fix the position
of the center-of-mass along the included directions, by setting the
corresponding flag to 1. The <em>rot</em> keyword does the same for the
rotational component of the tfMC displacements after every iteration.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">the <em>com</em> and <em>rot</em> keywords should not be used if an external
force is acting on the specified fix group, along the included
directions. This can be either a true external force (e.g. through
<a class="reference internal" href="fix_wall.html"><span class="doc">fix wall</span></a>) or forces due to the interaction with atoms
not included in the fix group. This is because in such cases,
translations or rotations of the fix group could be induced by these
external forces, and removing them will lead to a violation of
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options are relevant to this
fix.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the MC package. It is only enabled if LAMMPS was
built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix is not compatible with <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Use the Muller-Plathe algorithm described in <a class="reference internal" href="fix_viscosity.html#muller-plathe"><span class="std std-ref">this paper</span></a> to exchange kinetic energy between two particles
in different regions of the simulation box every N steps. This
induces a temperature gradient in the system. As described below this
enables the thermal conductivity of a material to be calculated. This
algorithm is sometimes called a reverse non-equilibrium MD (reverse
NEMD) approach to computing thermal conductivity. This is because the
usual NEMD approach is to impose a temperature gradient on the system
and measure the response as the resulting heat flux. In the
Muller-Plathe method, the heat flux is imposed, and the temperature
gradient is the system’s response.</p>
<p>See the <a class="reference internal" href="compute_heat_flux.html"><span class="doc">compute heat/flux</span></a> command for details
on how to compute thermal conductivity in an alternate way, via the
Green-Kubo formalism.</p>
<p>The simulation box is divided into <em>Nbin</em> layers in the <em>edim</em>
direction, where the layer 1 is at the low end of that dimension and
the layer <em>Nbin</em> is at the high end. Every N steps, Nswap pairs of
atoms are chosen in the following manner. Only atoms in the fix group
are considered. The hottest Nswap atoms in layer 1 are selected.
Similarly, the coldest Nswap atoms in the “middle” layer (see below)
are selected. The two sets of Nswap atoms are paired up and their
velocities are exchanged. This effectively swaps their kinetic
energies, assuming their masses are the same. If the masses are
different, an exchange of velocities relative to center of mass motion
of the 2 atoms is performed, to conserve kinetic energy. Over time,
this induces a temperature gradient in the system which can be
measured using commands such as the following, which writes the
temperature profile (assuming z = edim) to the file tmp.profile:</p>
<p>Note that by default, Nswap = 1, though this can be changed by the
optional <em>swap</em> keyword. Setting this parameter appropriately, in
conjunction with the swap rate N, allows the heat flux to be adjusted
across a wide range of values, and the kinetic energy to be exchanged
in large chunks or more smoothly.</p>
<p>The “middle” layer for velocity swapping is defined as the <em>Nbin</em>/2 +
1 layer. Thus if <em>Nbin</em> = 20, the two swapping layers are 1 and 11.
This should lead to a symmetric temperature profile since the two
layers are separated by the same distance in both directions in a
periodic sense. This is why <em>Nbin</em> is restricted to being an even
number.</p>
<p>As described below, the total kinetic energy transferred by these
swaps is computed by the fix and can be output. Dividing this
quantity by time and the cross-sectional area of the simulation box
yields a heat flux. The ratio of heat flux to the slope of the
temperature profile is proportional to the thermal conductivity of the
fluid, in appropriate units. See the <a class="reference internal" href="fix_viscosity.html#muller-plathe"><span class="std std-ref">Muller-Plathe paper</span></a> for details.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If your system is periodic in the direction of the heat flux,
then the flux is going in 2 directions. This means the effective heat
flux in one direction is reduced by a factor of 2. You will see this
in the equations for thermal conductivity (kappa) in the Muller-Plathe
paper. LAMMPS is simply tallying kinetic energy which does not
account for whether or not your system is periodic; you must use the
value appropriately to yield a kappa for your system.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">After equilibration, if the temperature gradient you observe is
not linear, then you are likely swapping energy too frequently and are
not in a regime of linear response. In this case you cannot
accurately infer a thermal conductivity and should try increasing the
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
cummulative kinetic energy transferred between the bottom and middle
of the simulation box (in the <em>edim</em> direction) is stored as a scalar
quantity by this fix. This quantity is zeroed when the fix is defined
and accumlates thereafter, once every N steps. The units of the
quantity are energy; see the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command for details.
The scalar value calculated by this fix is “intensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the MISC package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Swaps conserve both momentum and kinetic energy, even if the masses of
the swapped atoms are not equal. Thus you should not need to
thermostat the system. If you do use a thermostat, you may want to
apply it only to the non-swapped dimensions (other than <em>vdim</em>).</p>
<p>LAMMPS does not check, but you should not use this fix to swap the
kinetic energy of atoms that are in constrained molecules, e.g. via
<a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> or <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a>. This is
because application of the constraints will alter the amount of
transferred momentum. You should, however, be able to use flexible
molecules. See the <a class="reference internal" href="pair_gran.html#zhang"><span class="std std-ref">Zhang paper</span></a> for a discussion and results
of this idea.</p>
<p>When running a simulation with large, massive particles or molecules
in a background solvent, you may want to only exchange kinetic energy
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>This fix computes a global vector quantitie which can be accessed by
various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The vector has
2 positions, the first one is the coupling parameter lambda and the
second one is the time derivative of lambda. The scalar and vector
values calculated by this fix are “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>The forces due to this fix are imposed during an energy minimization,
invoked by the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command.</p>
<p>This command is part of the USER-MISC package. It is only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
</div>
<div class="section" id="default">
<h2>Default</h2>
<p>The keyword default is function = 1.</p>
<hr class="docutils" />
<p id="dekoning99"><strong>(de Koning 99)</strong> M. de Koning, A. Antonelli and S. Yip, Phys Rev Lett, 83, 3973 (1999).</p>
<p id="watanabe"><strong>(Watanabe)</strong> M. Watanabe and W. P. Reinhardt, Phys Rev Lett, 65, 3301 (1990).</p>
<p id="dekoning96"><strong>(de Koning 96)</strong> M. de Koning and A. Antonelli, Phys Rev E, 53, 465 (1996).</p>
<p id="dekoning00a"><strong>(de Koning 00a)</strong> M. de Koning, A. Antonelli and S. Yip, J Chem Phys, 115, 11025 (2000).</p>
<p id="dekoning00b"><strong>(de Koning 00b)</strong> M. de Koning et al., Computing in Science & Engineering, 2, 88 (2000).</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>A spring force is applied independently to each atom in the group to
tether it to its initial position. The initial position for each atom
is its location at the time the fix command was issued. More details
about the springs are available in <a class="reference internal" href="fix_spring_self.html"><span class="doc">fix spring/self</span></a>. The forces on the atoms are
dynamically scaled during the simulation, the rescaling is done in the
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the original coordinates of tethered atoms to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so that the spring effect will be the
same in a restarted simulation. See the <a class="reference internal" href="read_restart.html"><span class="doc">read restart</span></a> command for info on how to re-specify a fix
in an input script that reads a restart file, so that the operation of
the fix continues in an uninterrupted fashion.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix modify</span></a> <em>energy</em> option is supported by this
fix to add the energy stored in the per-atom springs to the system’s
potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes a global scalar and a global vector quantities which
can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is an energy which
is the sum of the spring energy for each atom, where the per-atom
energy is 0.5 * K * r^2. The vector has 2 positions, the first one is
the coupling parameter lambda and the second one is the time
derivative of lambda. The scalar and vector values calculated by this
fix are “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>The forces due to this fix are imposed during an energy minimization,
invoked by the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you want the per-atom spring energy to be included in the
total potential energy of the system (the quantity being minimized),
you MUST enable the <a class="reference internal" href="fix_modify.html"><span class="doc">fix modify</span></a> <em>energy</em> option for
this fix.</p>
</div>
<p>An example script using this command is provided in the
<p>This command is part of the USER-MISC package. It is only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
</div>
<div class="section" id="default">
<h2>Default</h2>
<p>The keyword default is function = 1.</p>
<hr class="docutils" />
<p id="frenkel"><strong>(Frenkel)</strong> Daan Frenkel and Anthony J. C. Ladd, J. Chem. Phys. 81, 3188
(1984).</p>
<p id="watanabe"><strong>(Watanabe)</strong> M. Watanabe and W. P. Reinhardt, Phys Rev Lett, 65, 3301 (1990).</p>
<p id="dekoning96"><strong>(de Koning 96)</strong> M. de Koning and A. Antonelli, Phys Rev E, 53, 465 (1996).</p>
<p id="dekoning97"><strong>(de Koning 97)</strong> M. de Koning and A. Antonelli, Phys Rev B, 55, 735 (1997).</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Use a two-temperature model (TTM) to represent heat transfer through
and between electronic and atomic subsystems. LAMMPS models the
atomic subsystem as usual with a molecular dynamics model and the
classical force field specified by the user, but the electronic
subsystem is modeled as a continuum, or a background “gas”, on a
regular grid. Energy can be transferred spatially within the grid
representing the electrons. Energy can also be transferred between
the electronic and the atomic subsystems. The algorithm underlying
this fix was derived by D. M. Duffy and A. M. Rutherford and is
discussed in two J Physics: Condensed Matter papers: <a class="reference internal" href="#duffy"><span class="std std-ref">(Duffy)</span></a>
and <a class="reference internal" href="#rutherford"><span class="std std-ref">(Rutherford)</span></a>. They used this algorithm in cascade
simulations where a primary knock-on atom (PKA) was initialized with a
high velocity to simulate a radiation event.</p>
<p>The description in this sub-section applies to both fix ttm and fix
ttm/mod. Fix ttm/mod adds options to account for external heat
sources (e.g. at a surface) and for specifying parameters that allow
the electronic heat capacity to depend strongly on electronic
temperature. It is more expensive computationally than fix ttm
because it treats the thermal diffusion equation as non-linear. More
details on fix ttm/mod are given below.</p>
<p>Heat transfer between the electronic and atomic subsystems is carried
out via an inhomogeneous Langevin thermostat. This thermostat differs
from the regular Langevin thermostat (<a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a>) in three important ways. First, the
Langevin thermostat is applied uniformly to all atoms in the
user-specified group for a single target temperature, whereas the TTM
fix applies Langevin thermostatting locally to atoms within the
volumes represented by the user-specified grid points with a target
temperature specific to that grid point. Second, the Langevin
thermostat couples the temperature of the atoms to an infinite heat
reservoir, whereas the heat reservoir for fix TTM is finite and
represents the local electrons. Third, the TTM fix allows users to
specify not just one friction coefficient, but rather two independent
friction coefficients: one for the electron-ion interactions
(<em>gamma_p</em>), and one for electron stopping (<em>gamma_s</em>).</p>
<p>When the friction coefficient due to electron stopping, <em>gamma_s</em>, is
non-zero, electron stopping effects are included for atoms moving
faster than the electron stopping critical velocity, <em>v_0</em>. For
further details about this algorithm, see <a class="reference internal" href="#duffy"><span class="std std-ref">(Duffy)</span></a> and
<p>where the electronic temperatures along the y=0 plane have been set to
1.0, and the electronic temperatures along the y=1 plane have been set
to 2.0. The order of lines in this file is no important. If all the
nodal values are not specified, LAMMPS will generate an error.</p>
<p>The temperature output file, <em>T_oufile</em>, is created and written by
this fix. Temperatures for both the electronic and atomic subsystems
at every node and every N timesteps are output. If N is specified as
zero, no output is generated, and no output filename is needed. The
format of the output is as follows. One long line is written every
output timestep. The timestep itself is given in the first column.
The next Nx*Ny*Nz columns contain the temperatures for the atomic
subsystem, and the final Nx*Ny*Nz columns contain the temperatures for
the electronic subsystem. The ordering of the Nx*Ny*Nz columns is
with the z index varing fastest, y the next fastest, and x the
slowest.</p>
<p>These fixes do not change the coordinates of their atoms; they only
scales their velocities. Thus a time integration fix (e.g. <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a>) should still be used to time integrate the affected
atoms. The fixes should not normally be used on atoms that have their
temperature controlled by another fix - e.g. <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> or
<p>where <em>X</em> = T_e/1000, and the thermal conductivity is defined as
kappa_e = D_e*rho_e*C_e, where D_e is the thermal diffusion
coefficient.</p>
<p>Electronic pressure effects are included in the TTM model to account
for the blast force acting on ions because of electronic pressure
gradient (see <a class="reference internal" href="#chen"><span class="std std-ref">(Chen)</span></a>, <a class="reference internal" href="#norman"><span class="std std-ref">(Norman)</span></a>). The total force
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>These fixes write the state of the electronic subsystem and the energy
exchange between the subsystems to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command
for info on how to re-specify a fix in an input script that reads a
restart file, so that the operation of the fix continues in an
uninterrupted fashion.</p>
<p>Because the state of the random number generator is not saved in the
restart files, this means you cannot do “exact” restarts with this
fix, where the simulation continues on the same as if no restart had
taken place. However, in a statistical sense, a restarted simulation
should produce the same behavior.</p>
<p>None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options are relevant to these
fixes.</p>
<p>Both fixes compute 2 output quantities stored in a vector of length 2,
which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The first quantity is the
total energy of the electronic subsystem. The second quantity is the
energy transferred from the electronic to the atomic subsystem on that
timestep. Note that the velocity verlet integrator applies the fix ttm
forces to the atomic subsystem as two half-step velocity updates: one
on the current timestep and one on the subsequent timestep.
Consequently, the change in the atomic subsystem energy is lagged by
half a timestep relative to the change in the electronic subsystem
energy. As a result of this, users may notice slight fluctuations in
the sum of the atomic and electronic subsystem energies reported at
the end of the timestep.</p>
<p>The vector values calculated are “extensive”.</p>
<p>No parameter of the fixes can be used with the <em>start/stop</em> keywords
of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. The fixes are not invoked during
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Use the Muller-Plathe algorithm described in <a class="reference internal" href="#muller-plathe"><span class="std std-ref">this paper</span></a> to exchange momenta between two particles in
different regions of the simulation box every N steps. This induces a
shear velocity profile in the system. As described below this enables
a viscosity of the fluid to be calculated. This algorithm is
sometimes called a reverse non-equilibrium MD (reverse NEMD) approach
to computing viscosity. This is because the usual NEMD approach is to
impose a shear velocity profile on the system and measure the response
via an off-diagonal component of the stress tensor, which is
proportional to the momentum flux. In the Muller-Plathe method, the
momentum flux is imposed, and the shear velocity profile is the
system’s response.</p>
<p>The simulation box is divided into <em>Nbin</em> layers in the <em>pdim</em>
direction, where the layer 1 is at the low end of that dimension and
the layer <em>Nbin</em> is at the high end. Every N steps, Nswap pairs of
atoms are chosen in the following manner. Only atoms in the fix group
are considered. Nswap atoms in layer 1 with positive velocity
components in the <em>vdim</em> direction closest to the target value <em>V</em> are
selected. Similarly, Nswap atoms in the “middle” layer (see below) with
negative velocity components in the <em>vdim</em> direction closest to the
negative of the target value <em>V</em> are selected. The two sets of Nswap
atoms are paired up and their <em>vdim</em> momenta components are swapped
within each pair. This resets their velocities, typically in opposite
directions. Over time, this induces a shear velocity profile in the
system which can be measured using commands such as the following,
which writes the profile to the file tmp.profile:</p>
<p>Note that by default, Nswap = 1 and vtarget = INF, though this can be
changed by the optional <em>swap</em> and <em>vtarget</em> keywords. When vtarget =
INF, one or more atoms with the most positive and negative velocity
components are selected. Setting these parameters appropriately, in
conjunction with the swap rate N, allows the momentum flux rate to be
adjusted across a wide range of values, and the momenta to be
exchanged in large chunks or more smoothly.</p>
<p>The “middle” layer for momenta swapping is defined as the <em>Nbin</em>/2 + 1
layer. Thus if <em>Nbin</em> = 20, the two swapping layers are 1 and 11.
This should lead to a symmetric velocity profile since the two layers
are separated by the same distance in both directions in a periodic
sense. This is why <em>Nbin</em> is restricted to being an even number.</p>
<p>As described below, the total momentum transferred by these velocity
swaps is computed by the fix and can be output. Dividing this
quantity by time and the cross-sectional area of the simulation box
yields a momentum flux. The ratio of momentum flux to the slope of
the shear velocity profile is proportional to the viscosity of the
fluid, in appropriate units. See the <a class="reference internal" href="#muller-plathe"><span class="std std-ref">Muller-Plathe paper</span></a> for details.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If your system is periodic in the direction of the momentum
flux, then the flux is going in 2 directions. This means the
effective momentum flux in one direction is reduced by a factor of 2.
You will see this in the equations for viscosity in the Muller-Plathe
paper. LAMMPS is simply tallying momentum which does not account for
whether or not your system is periodic; you must use the value
appropriately to yield a viscosity for your system.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">After equilibration, if the velocity profile you observe is not
linear, then you are likely swapping momentum too frequently and are
not in a regime of linear response. In this case you cannot
accurately infer a viscosity and should try increasing the Nevery
parameter.</p>
</div>
<p>An alternative method for calculating a viscosity is to run a NEMD
simulation, as described in <a class="reference internal" href="Section_howto.html#howto-13"><span class="std std-ref">Section_howto 13</span></a> of the manual. NEMD simulations
deform the simmulation box via the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a>
command. Thus they cannot be run on a charged system using a <a class="reference internal" href="kspace_style.html"><span class="doc">PPPM solver</span></a> since PPPM does not currently support
non-orthogonal boxes. Using fix viscosity keeps the box orthogonal;
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
cummulative momentum transferred between the bottom and middle of the
simulation box (in the <em>pdim</em> direction) is stored as a scalar
quantity by this fix. This quantity is zeroed when the fix is defined
and accumlates thereafter, once every N steps. The units of the
quantity are momentum = mass*velocity. The scalar value calculated by
this fix is “intensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the MISC package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Swaps conserve both momentum and kinetic energy, even if the masses of
the swapped atoms are not equal. Thus you should not need to
thermostat the system. If you do use a thermostat, you may want to
apply it only to the non-swapped dimensions (other than <em>vdim</em>).</p>
<p>LAMMPS does not check, but you should not use this fix to swap
velocities of atoms that are in constrained molecules, e.g. via <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> or <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a>. This is because
application of the constraints will alter the amount of transferred
momentum. You should, however, be able to use flexible molecules.
See the <a class="reference internal" href="#maginn"><span class="std std-ref">Maginn paper</span></a> for an example of using this algorithm
in a computation of alcohol molecule properties.</p>
<p>When running a simulation with large, massive particles or molecules
in a background solvent, you may want to only exchange momenta bewteen
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Add a viscous damping force to atoms in the group that is proportional
to the velocity of the atom. The added force can be thought of as a
frictional interaction with implicit solvent, i.e. the no-slip Stokes
drag on a spherical particle. In granular simulations this can be
useful for draining the kinetic energy from the system in a controlled
fashion. If used without additional thermostatting (to add kinetic
energy to the system), it has the effect of slowly (or rapidly)
freezing the system; hence it can also be used as a simple energy
minimization technique.</p>
<p>The damping force F is given by F = - gamma * velocity. The larger
the coefficient, the faster the kinetic energy is reduced. If the
optional keyword <em>scale</em> is used, gamma can scaled up or down by the
specified factor for atoms of that type. It can be used multiple
times to adjust gamma for several atom types.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">You should specify gamma in force/velocity units. This is not
the same as mass/time units, at least for some of the LAMMPS
<a class="reference internal" href="units.html"><span class="doc">units</span></a> options like “real” or “metal” that are not
self-consistent.</p>
</div>
<p>In a Brownian dynamics context, gamma = Kb T / D, where Kb =
Boltzmann’s constant, T = temperature, and D = particle diffusion
coefficient. D can be written as Kb T / (3 pi eta d), where eta =
dynamic viscosity of the frictional fluid and d = diameter of
particle. This means gamma = 3 pi eta d, and thus is proportional to
the viscosity of the fluid and the particle diameter.</p>
<p>In the current implementation, rather than have the user specify a
viscosity, gamma is specified directly in force/velocity units. If
needed, gamma can be adjusted for atoms of different sizes
(i.e. sigma) by using the <em>scale</em> keyword.</p>
<p>Note that Brownian dynamics models also typically include a randomized
force term to thermostat the system at a chosen temperature. The <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> command does this. It has the same
viscous damping term as fix viscous and adds a random force to each
atom. The random force term is proportional to the sqrt of the chosen
thermostatting temperature. Thus if you use fix langevin with a
target T = 0, its random force term is zero, and you are essentially
performing the same operation as fix viscous. Also note that the
gamma of fix viscous is related to the damping parameter of <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a>, however the former is specified in units
of force/velocity and the latter in units of time, so that it can more
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>respa</em> option is supported by this
fix. This allows to set at which level of the <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA</span></a>
integrator the fix is modifying forces. Default is the outermost level.</p>
<p>The forces due to this fix are imposed during an energy minimization,
invoked by the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command. This fix should only
be used with damped dynamics minimizers that allow for
non-conservative forces. See the <a class="reference internal" href="min_style.html"><span class="doc">min_style</span></a> command
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy of interaction between atoms and each wall to
the system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>respa</em> option is supported by this
fix. This allows to set at which level of the <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA</span></a>
integrator the fix is adding its forces. Default is the outermost level.</p>
<p>This fix computes a global scalar energy and a global vector of
forces, which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. Note that the scalar energy is
the sum of interactions with all defined walls. If you want the
energy on a per-wall basis, you need to use multiple fix wall
commands. The length of the vector is equal to the number of walls
defined by the fix. Each vector value is the normal force on a
specific wall. Note that an outward force on a wall will be a
negative value for <em>lo</em> walls and a positive value for <em>hi</em> walls.
The scalar and vector values calculated by this fix are “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>The forces due to this fix are imposed during an energy minimization,
invoked by the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you want the atom/wall interaction energy to be included in
the total potential energy of the system (the quantity being
minimized), you MUST enable the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Bound the simulation domain of a granular system with a frictional
wall. All particles in the group interact with the wall when they are
close enough to touch it.</p>
<p>The nature of the wall/particle interactions are determined by the
<em>fstyle</em> setting. It can be any of the styles defined by the
<a class="reference internal" href="pair_gran.html"><span class="doc">pair_style granular</span></a> commands. Currently this is
<em>hooke</em>, <em>hooke/history</em>, or <em>hertz/history</em>. The equation for the
force between the wall and particles touching it is the same as the
corresponding equation on the <a class="reference internal" href="pair_gran.html"><span class="doc">pair_style granular</span></a> doc
page, in the limit of one of the two particles going to infinite
radius and mass (flat wall). I.e. delta = radius - r = overlap of
particle with wall, m_eff = mass of particle, and sqrt(RiRj/Ri+Rj)
becomes sqrt(radius of particle). The units for Kn, Kt, gamma_n, and
gamma_t are as described on that doc page. The meaning of xmu and
dampflag are also as described on that page. Note that you can choose
a different force styles and/or different values for the 6
wall/particle coefficients than for particle/particle interactions.
E.g. if you wish to model the wall as a different material.</p>
<p>The parameters <em>Kn</em>, <em>Kt</em>, <em>gamma_n</em>, <em>gamma_t</em>, <em>xmu</em> and <em>dampflag</em>
have the same meaning as those specified with the <a class="reference internal" href="pair_gran.html"><span class="doc">pair_style granular</span></a> commands. This means a NULL can be used for
either <em>Kt</em> or <em>gamma_t</em> as described on that page. If a NULL is used
for <em>Kt</em>, then a default value is used where <em>Kt</em> = 2/7 <em>Kn</em>. If a
NULL is used for <em>gamma_t</em>, then a default value is used where
<em>gamma_t</em> = 1/2 <em>gamma_n</em>.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">As discussed on the doc page for <a class="reference internal" href="pair_gran.html"><span class="doc">pair_style granular</span></a>, versions of LAMMPS before 9Jan09 used a
different equation for Hertzian interactions. This means Hertizian
wall/particle interactions have also changed. They now include a
sqrt(radius) term which was not present before. Also the previous
versions used Kn and Kt from the pairwise interaction and hardwired
dampflag to 1, rather than letting them be specified directly. This
means you can set the values of the wall/particle coefficients
appropriately in the current code to reproduce the results of a
prevoius Hertzian monodisperse calculation. For example, for the
common case of a monodisperse system with particles of diameter 1, Kn,
Kt, gamma_n, and gamma_s should be set sqrt(2.0) larger than they were
previously.</p>
</div>
<p>The effective mass <em>m_eff</em> in the formulas listed on the <a class="reference internal" href="pair_gran.html"><span class="doc">pair_style granular</span></a> doc page is the mass of the particle for
particle/wall interactions (mass of wall is infinite). If the
particle is part of a rigid body, its mass is replaced by the mass of
the rigid body in those formulas. This is determined by searching for
a <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> command (or its variants).</p>
<p>The <em>wallstyle</em> can be planar or cylindrical. The 3 planar options
specify a pair of walls in a dimension. Wall positions are given by
<em>lo</em> and <em>hi</em>. Either of the values can be specified as NULL if a
single wall is desired. For a <em>zcylinder</em> wallstyle, the cylinder’s
axis is at x = y = 0.0, and the radius of the cylinder is specified.</p>
<p>Optionally, the wall can be moving, if the <em>wiggle</em> or <em>shear</em>
keywords are appended. Both keywords cannot be used together.</p>
<p>For the <em>wiggle</em> keyword, the wall oscillates sinusoidally, similar to
the oscillations of particles which can be specified by the
<a class="reference internal" href="fix_move.html"><span class="doc">fix move</span></a> command. This is useful in packing
simulations of granular particles. The arguments to the <em>wiggle</em>
keyword specify a dimension for the motion, as well as it’s
<em>amplitude</em> and <em>period</em>. Note that if the dimension is in the plane
of the wall, this is effectively a shearing motion. If the dimension
is perpendicular to the wall, it is more of a shaking motion. A
<em>zcylinder</em> wall can only be wiggled in the z dimension.</p>
<p>Each timestep, the position of a wiggled wall in the appropriate <em>dim</em>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the shear friction state of atoms interacting with the
wall to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so that a simulation can
continue correctly if granular potentials with shear “history” effects
are being used. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for
info on how to re-specify a fix in an input script that reads a
restart file, so that the operation of the fix continues in an
uninterrupted fashion.</p>
<p>None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options are relevant to this
fix. No global or per-atom quantities are stored by this fix for
access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No
parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the GRANULAR package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Any dimension (xyz) that has a granular wall must be non-periodic.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix style is part of the SHOCK package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The face that has the wall/piston must be boundary type ‘s’
(shrink-wrapped). The opposing face can be
any boundary type other than periodic.</p>
<p>A wall/piston should not be used with rigid bodies such as those
defined by a “fix rigid” command. This is because the wall/piston
displaces atoms directly rather than exerting a force on them.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+fix walls all wall/reflect xlo 0.0 ylo 10.0 units box
+fix top all wall/reflect zhi v_pressdown
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Bound the simulation with one or more walls which reflect particles
in the specified group when they attempt to move thru them.</p>
<p>Reflection means that if an atom moves outside the wall on a timestep
by a distance delta (e.g. due to <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a>), then it is
put back inside the face by the same delta, and the sign of the
corresponding component of its velocity is flipped.</p>
<p>When used in conjunction with <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> and <a class="reference internal" href="run_style.html"><span class="doc">run_style verlet</span></a>, the resultant time-integration algorithm is
equivalent to the primitive splitting algorithm (PSA) described by
<a class="reference internal" href="#bond"><span class="std std-ref">Bond</span></a>. Because each reflection event divides
the corresponding timestep asymmetrically, energy conservation is only
satisfied to O(dt), rather than to O(dt^2) as it would be for
velocity-Verlet integration without reflective walls.</p>
<p>Up to 6 walls or faces can be specified in a single command: <em>xlo</em>,
<em>xhi</em>, <em>ylo</em>, <em>yhi</em>, <em>zlo</em>, <em>zhi</em>. A <em>lo</em> face reflects particles
that move to a coordinate less than the wall position, back in the
<em>hi</em> direction. A <em>hi</em> face reflects particles that move to a
coordinate higher than the wall position, back in the <em>lo</em> direction.</p>
<p>The position of each wall can be specified in one of 3 ways: as the
EDGE of the simulation box, as a constant value, or as a variable. If
EDGE is used, then the corresponding boundary of the current
simulation box is used. If a numeric constant is specified then the
wall is placed at that position in the appropriate dimension (x, y, or
z). In both the EDGE and constant cases, the wall will never move.
If the wall position is a variable, it should be specified as v_name,
where name is an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> name. In this
case the variable is evaluated each timestep and the result becomes
the current position of the reflecting wall. Equal-style variables
can specify formulas with various mathematical functions, and include
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command keywords for the simulation
box parameters and timestep and elapsed time. Thus it is easy to
specify a time-dependent wall position.</p>
<p>The <em>units</em> keyword determines the meaning of the distance units used
to define a wall position, but only when a numeric constant or
variable is used. It is not relevant when EDGE is used to specify a
face position. In the variable case, the variable is assumed to
produce a value compatible with the <em>units</em> setting you specify.</p>
<p>A <em>box</em> value selects standard distance units as defined by the
<a class="reference internal" href="units.html"><span class="doc">units</span></a> command, e.g. Angstroms for units = real or metal.
A <em>lattice</em> value means the distance units are in lattice spacings.
The <a class="reference internal" href="lattice.html"><span class="doc">lattice</span></a> command must have been previously used to
define the lattice spacings.</p>
<hr class="docutils" />
<p>Here are examples of variable definitions that move the wall position
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>Any dimension (xyz) that has a reflecting wall must be non-periodic.</p>
<p>A reflecting wall should not be used with rigid bodies such as those
defined by a “fix rigid” command. This is because the wall/reflect
displaces atoms directly rather than exerts a force on them. For
rigid bodies, use a soft wall instead, such as <a class="reference internal" href="fix_wall.html"><span class="doc">fix wall/lj93</span></a>. LAMMPS will flag the use of a rigid
fix with fix wall/reflect with a warning, but will not generate an
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy of interaction between atoms and the wall to the
system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>respa</em> option is supported by this
fix. This allows to set at which level of the <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA</span></a>
integrator the fix is adding its forces. Default is the outermost level.</p>
<p>This fix computes a global scalar energy and a global 3-length vector
of forces, which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar energy is the sum
of energy interactions for all particles interacting with the wall
represented by the region surface. The 3 vector quantities are the
x,y,z components of the total force acting on the wall due to the
particles. The scalar and vector values calculated by this fix are
“extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>The forces due to this fix are imposed during an energy minimization,
invoked by the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you want the atom/wall interaction energy to be included in
the total potential energy of the system (the quantity being
minimized), you MUST enable the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>style = <em>delete</em> or <em>region</em> or <em>type</em> or <em>id</em> or <em>molecule</em> or <em>variable</em> or <em>include</em> or <em>subtract</em> or <em>union</em> or <em>intersect</em> or <em>dynamic</em> or <em>static</em></li>
</ul>
<pre class="literal-block">
<em>delete</em> = no args
<em>clear</em> = no args
<em>region</em> args = region-ID
<em>type</em> or <em>id</em> or <em>molecule</em>
args = list of one or more atom types, atom IDs, or molecule IDs
any entry in list can be a sequence formatted as A:B or A:B:C where
A = starting index, B = ending index,
C = increment between indices, 1 if not specified
args = logical value
logical = "<" or "<=" or ">" or ">=" or "==" or "!="
value = an atom type or atom ID or molecule ID (depending on <em>style</em>)
args = logical value1 value2
logical = "<>"
value1,value2 = atom types or atom IDs or molecule IDs (depending on <em>style</em>)
<em>variable</em> args = variable-name
<em>include</em> args = molecule
molecule = add atoms to group with same molecule ID as atoms already in group
<em>subtract</em> args = two or more group IDs
<em>union</em> args = one or more group IDs
<em>intersect</em> args = two or more group IDs
<em>dynamic</em> args = parent-ID keyword value ...
one or more keyword/value pairs may be appended
keyword = <em>region</em> or <em>var</em> or <em>every</em>
<em>region</em> value = region-ID
<em>var</em> value = name of variable
<em>every</em> value = N = update group every this many timesteps
<p>If the group ID already exists, the group command adds the specified
atoms to the group.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">By default groups are static, meaning the atoms are permanently
assigned to the group. For example, if the <em>region</em> style is used to
assign atoms to a group, the atoms will remain in the group even if
they later move out of the region. As explained below, the <em>dynamic</em>
style can be used to make a group dynamic so that a periodic
determination is made as to which atoms are in the group. Since many
LAMMPS commands operate on groups of atoms, you should think carefully
about whether making a group dynamic makes sense for your model.</p>
</div>
<p>A group with the ID <em>all</em> is predefined. All atoms belong to this
group. This group cannot be deleted, or made dynamic.</p>
<p>The <em>delete</em> style removes the named group and un-assigns all atoms
that were assigned to that group. Since there is a restriction (see
below) that no more than 32 groups can be defined at any time, the
<em>delete</em> style allows you to remove groups that are no longer needed,
so that more can be specified. You cannot delete a group if it has
been used to define a current <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> or <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>
or <a class="reference internal" href="dump.html"><span class="doc">dump</span></a>.</p>
<p>The <em>clear</em> style un-assigns all atoms that were assigned to that
group. This may be dangerous to do during a simulation run,
e.g. using the <a class="reference internal" href="run.html"><span class="doc">run every</span></a> command if a fix or compute or
other operation expects the atoms in the group to remain constant, but
LAMMPS does not check for this.</p>
<p>The <em>region</em> style puts all atoms in the region volume into the group.
Note that this is a static one-time assignment. The atoms remain
assigned (or not assigned) to the group even in they later move out of
the region volume.</p>
<p>The <em>type</em>, <em>id</em>, and <em>molecule</em> styles put all atoms with the
specified atom types, atom IDs, or molecule IDs into the group. These
3 styles can use arguments specified in one of two formats.</p>
<p>The first format is a list of values (types or IDs). For example, the
2nd command in the examples above puts all atoms of type 3 or 4 into
the group named <em>water</em>. Each entry in the list can be a
colon-separated sequence A:B or A:B:C, as in two of the examples
above. A “sequence” generates a sequence of values (types or IDs),
with an optional increment. The first example with 500:1000 has the
default increment of 1 and would add all atom IDs from 500 to 1000
(inclusive) to the group sub, along with 10,25,50 since they also
appear in the list of values. The second example with 100:10000:10
uses an increment of 10 and would thus would add atoms IDs
100,110,120, ... 9990,10000 to the group sub.</p>
<p>The second format is a <em>logical</em> followed by one or two values (type
or ID). The 7 valid logicals are listed above. All the logicals
except <> take a single argument. The 3rd example above adds all
atoms with IDs from 1 to 150 to the group named <em>sub</em>. The logical <>
means “between” and takes 2 arguments. The 4th example above adds all
atoms belonging to molecules with IDs from 50 to 250 (inclusive) to
the group named polyA.</p>
<p>The <em>variable</em> style evaluates a variable to determine which atoms to
add to the group. It must be an <a class="reference internal" href="variable.html"><span class="doc">atom-style variable</span></a>
previously defined in the input script. If the variable evaluates
to a non-zero value for a particular atom, then that atom is added
to the specified group.</p>
<p>Atom-style variables can specify formulas that include thermodynamic
quantities, per-atom values such as atom coordinates, or per-atom
quantities calculated by computes, fixes, or other variables. They
can also include Boolean logic where 2 numeric values are compared to
yield a 1 or 0 (effectively a true or false). Thus using the
<em>variable</em> style, is a general way to flag specific atoms to include
or exclude from a group.</p>
<p>For example, these lines define a variable “eatom” that calculates the
potential energy of each atom and includes it in the group if its
potential energy is above the threshhold value -3.0.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Note that if one of the commands to execute is <a class="reference internal" href="quit.html"><span class="doc">quit</span></a>, as in
the first example above, then executing the command will cause LAMMPS
to halt.</p>
<p>Note that by jumping to a label in the same input script, the if
command can be used to break out of a loop. See the <a class="reference internal" href="variable.html"><span class="doc">variable delete</span></a> command for info on how to delete the associated
loop variable, so that it can be re-used later in the input script.</p>
<p>Here is an example of a loop which checks every 1000 steps if the
system temperature has reached a certain value, and if so, breaks out
of the loop to finish the run. Note that any variable could be
checked, so long as it is current on the timestep when the run
completes. As explained on the <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> doc page,
this can be insured by includig the variable in thermodynamic output.</p>
<div class="highlight-default"><div class="highlight"><pre><span></span>A == B, A != B, A < B, A <= B, A > B, A >= B, A && B, A || B, !A
</pre></div>
</div>
<p>Each A and B is a number or string or a variable reference like $a or
${abc}, or A or B can be another Boolean expression.</p>
<p>If a variable is used it can produce a number when evaluated, like an
<a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a>. Or it can produce a string,
like an <a class="reference internal" href="variable.html"><span class="doc">index-style variable</span></a>. For an individual
Boolean operator, A and B must both be numbers or must both be
strings. You cannot compare a number to a string.</p>
<p>Expressions are evaluated left to right and have the usual C-style
precedence: the unary logical NOT operator ”!” has the highest
precedence, the 4 relational operators “<”, “<=”, “>”, and “>=” are
next; the two remaining relational operators “==” and ”!=” are next;
then the logical AND operator “&&”; and finally the logical OR
operator “||” has the lowest precedence. Parenthesis can be used to
group one or more portions of an expression and/or enforce a different
order of evaluation than what would occur with the default precedence.</p>
<p>When the 6 relational operators (first 6 in list above) compare 2
numbers, they return either a 1.0 or 0.0 depending on whether the
relationship between A and B is TRUE or FALSE. When the 6 relational
operators compare 2 strings, they also return a 1.0 or 0.0 for TRUE or
FALSE, but the comparison is done by the C function strcmp().</p>
<p>When the 3 logical operators (last 3 in list above) compare 2 numbers,
they also return either a 1.0 or 0.0 depending on whether the
relationship between A and B is TRUE or FALSE (or just A). The
logical AND operator will return 1.0 if both its arguments are
non-zero, else it returns 0.0. The logical OR operator will return
1.0 if either of its arguments is non-zero, else it returns 0.0. The
logical NOT operator returns 1.0 if its argument is 0.0, else it
returns 0.0. The 3 logical operators can only be used to operate on
numbers, not on strings.</p>
<p>The overall Boolean expression produces a TRUE result if the result is
non-zero. If the result is zero, the expression result is FALSE.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where Ei is the improper term and Eaa is an angle-angle term. The 3 X
terms in Ei are an average over 3 out-of-plane angles.</p>
<p>The 4 atoms in an improper quadruplet (listed in the data file read by
the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command) are ordered I,J,K,L. X_IJKL
refers to the angle between the plane of I,J,K and the plane of J,K,L,
and the bond JK lies in both planes. Similarly for X_KJLI and X_LJIK.
Note that atom J appears in the common bonds (JI, JK, JL) of all 3 X
terms. Thus J (the 2nd atom in the quadruplet) is the atom of
symmetry in the 3 X angles.</p>
<p>The subscripts on the various theta’s refer to different combinations
of 3 atoms (I,J,K,L) used to form a particular angle. E.g. Theta_IJL
is the angle formed by atoms I,J,L with J in the middle. Theta1,
theta2, theta3 are the equilibrium positions of those angles. Again,
atom J (the 2nd atom in the quadruplet) is the atom of symmetry in the
theta angles, since it is always the center atom.</p>
<p>Since atom J is the atom of symmetry, normally the bonds J-I, J-K, J-L
would exist for an improper to be defined between the 4 atoms, but
this is not required.</p>
<p>See <a class="reference internal" href="#improper-sun"><span class="std std-ref">(Sun)</span></a> for a description of the COMPASS class2 force field.</p>
<p>Coefficients for the Ei and Eaa formulas must be defined for each
improper type via the <a class="reference internal" href="improper_coeff.html"><span class="doc">improper_coeff</span></a> command as
in the example above, or in the data file or restart files read by the
<p>These are the 2 coefficients for the Ei formula:</p>
<ul class="simple">
<li>K (energy/radian^2)</li>
<li>X0 (degrees)</li>
</ul>
<p>X0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.</p>
<p>For the Eaa formula, each line in a
<a class="reference internal" href="improper_coeff.html"><span class="doc">improper_coeff</span></a> command in the input script lists
7 coefficients, the first of which is “aa” to indicate they are
AngleAngle coefficients. In a data file, these coefficients should be
listed under a “AngleAngle Coeffs” heading and you must leave out the
“aa”, i.e. only list 6 coefficients after the improper type.</p>
<ul class="simple">
<li>aa</li>
<li>M1 (energy/distance)</li>
<li>M2 (energy/distance)</li>
<li>M3 (energy/distance)</li>
<li>theta1 (degrees)</li>
<li>theta2 (degrees)</li>
<li>theta3 (degrees)</li>
</ul>
<p>The theta values are specified in degrees, but LAMMPS converts them to
radians internally; hence the units of M are in energy/radian^2.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This improper style can only be used if LAMMPS was built with the
CLASS2 package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>X0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This improper style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This improper style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>X0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This improper style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where K is a prefactor, theta is the angle formed by the atoms
specified by (i,j,k,l) indices and theta0 its equilibrium value.</p>
<p>If the 4 atoms in an improper quadruplet (listed in the data file read
by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command) are ordered i,j,k,l then
-<a href="#id1"><span class="problematic" id="id2">theta_</span></a><em>ijl</em> is the angle between atoms i,j and l, <a href="#id3"><span class="problematic" id="id4">theta_</span></a><em>ijk</em> is the
-angle between atoms i,j and k, <a href="#id5"><span class="problematic" id="id6">theta_</span></a><em>kjl</em> is the angle between atoms
+theta_<em>ijl</em> is the angle between atoms i,j and l, theta_<em>ijk</em> is the
+angle between atoms i,j and k, theta_<em>kjl</em> is the angle between atoms
j,k, and l.</p>
<p>The “ring” improper style implements the improper potential introduced
by Destree et al., in Equation (9) of <a class="reference internal" href="#destree"><span class="std std-ref">(Destree)</span></a>. This
potential does not affect small amplitude vibrations but is used in an
ad-hoc way to prevent the onset of accidentially large amplitude
fluctuations leading to the occurrence of a planar conformation of the
three bonds i-j, j-k and j-l, an intermediate conformation toward the
chiral inversion of a methine carbon. In the “Impropers” section of
data file four atoms: i, j, k and l are specified with i,j and l lying
on the backbone of the chain and k specifying the chirality of j.</p>
<p>The following coefficients must be defined for each improper type via
the <a class="reference internal" href="improper_coeff.html"><span class="doc">improper_coeff</span></a> command as in the example
above, or in the data file or restart files read by the
<p>theta0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This improper style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>If omega0 = 0 the potential term has a minimum for the planar
structure. Otherwise it has two minima at +/- omega0, with a barrier
in between.</p>
<p>See <a class="reference internal" href="#umbrella-mayo"><span class="std std-ref">(Mayo)</span></a> for a description of the DREIDING force field.</p>
<p>The following coefficients must be defined for each improper type via
the <a class="reference internal" href="improper_coeff.html"><span class="doc">improper_coeff</span></a> command as in the example
above, or in the data file or restart files read by the
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This improper style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>since the SELF option invokes the C-library rewind() call, which may
not be supported for stdin on some systems or by some MPI
implementations. This can be worked around by using the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-in command-line argument</span></a>, e.g.</p>
<p>or by using the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-var command-line argument</span></a> to pass the script name as a
variable to the input script. In the latter case, a
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> called “fname” could be used in place of
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>one or more keyword/value pairs may be listed</li>
</ul>
<pre class="literal-block">
keyword = <em>mesh</em> or <em>order</em> or <em>order/disp</em> or <em>mix/disp</em> or <em>overlap</em> or <em>minorder</em> or <em>force</em> or <em>gewald</em> or <em>gewald/disp</em> or <em>slab</em> or (nozforce* or <em>compute</em> or <em>cutoff/adjust</em> or <em>fftbench</em> or <em>collective</em> or <em>diff</em> or <em>kmax/ewald</em> or <em>force/disp/real</em> or <em>force/disp/kspace</em> or <em>splittol</em> or <em>disp/auto</em>:l
<em>mesh</em> value = x y z
x,y,z = grid size in each dimension for long-range Coulombics
<em>mesh/disp</em> value = x y z
x,y,z = grid size in each dimension for 1/r^6 dispersion
<em>order</em> value = N
N = extent of Gaussian for PPPM or MSM mapping of charge to grid
<em>order/disp</em> value = N
N = extent of Gaussian for PPPM mapping of dispersion term to grid
<em>mix/disp</em> value = <em>pair</em> or <em>geom</em> or <em>none</em>
<em>overlap</em> = <em>yes</em> or <em>no</em> = whether the grid stencil for PPPM is allowed to overlap into more than the nearest-neighbor processor
<em>minorder</em> value = M
M = min allowed extent of Gaussian when auto-adjusting to minimize grid communication
<em>force</em> value = accuracy (force units)
<em>gewald</em> value = rinv (1/distance units)
rinv = G-ewald parameter for Coulombics
<em>gewald/disp</em> value = rinv (1/distance units)
rinv = G-ewald parameter for dispersion
<em>slab</em> value = volfactor or <em>nozforce</em>
volfactor = ratio of the total extended volume used in the
2d approximation compared with the volume of the simulation domain
<em>nozforce</em> turns off kspace forces in the z direction
<em>compute</em> value = <em>yes</em> or <em>no</em>
<em>cutoff/adjust</em> value = <em>yes</em> or <em>no</em>
<em>pressure/scalar</em> value = <em>yes</em> or <em>no</em>
<em>fftbench</em> value = <em>yes</em> or <em>no</em>
<em>collective</em> value = <em>yes</em> or <em>no</em>
<em>diff</em> value = <em>ad</em> or <em>ik</em> = 2 or 4 FFTs for PPPM in smoothed or non-smoothed mode
<em>kmax/ewald</em> value = kx ky kz
kx,ky,kz = number of Ewald sum kspace vectors in each dimension
<em>force/disp/real</em> value = accuracy (force units)
<em>force/disp/kspace</em> value = accuracy (force units)
<em>splittol</em> value = tol
tol = relative size of two eigenvalues (see discussion below)
<p class="last">If you wish to apply an electric field in the Z-direction, in
conjunction with the <em>slab</em> keyword, you should do it by adding
explicit charged particles to the +/- Z surfaces. If you do it via
the <a class="reference internal" href="fix_efield.html"><span class="doc">fix efield</span></a> command, it will not give the correct
dielectric constant due to the Yeh/Berkowitz <a class="reference internal" href="#yeh"><span class="std std-ref">(Yeh)</span></a> correction
not being compatible with how <a class="reference internal" href="fix_efield.html"><span class="doc">fix efield</span></a> works.</p>
</div>
<p>The <em>compute</em> keyword allows Kspace computations to be turned off,
even though a <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> is defined. This is
not useful for running a real simulation, but can be useful for
debugging purposes or for computing only partial forces that do not
include the Kspace contribution. You can also do this by simply not
defining a <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a>, but a Kspace-compatible
<a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> requires a kspace style to be defined.
This keyword gives you that option.</p>
<p>The <em>cutoff/adjust</em> keyword applies only to MSM. If this option is
turned on, the Coulombic cutoff will be automatically adjusted at the
beginning of the run to give the desired estimated error. Other
cutoffs such as LJ will not be affected. If the grid is not set using
the <em>mesh</em> command, this command will also attempt to use the optimal
grid that minimizes cost using an estimate given by
<a class="reference internal" href="kspace_style.html#hardy"><span class="std std-ref">(Hardy)</span></a>. Note that this cost estimate is not exact, somewhat
experimental, and still may not yield the optimal parameters.</p>
<p>The <em>pressure/scalar</em> keyword applies only to MSM. If this option is
turned on, only the scalar pressure (i.e. (Pxx + Pyy + Pzz)/3.0) will
be computed, which can be used, for example, to run an isotropic barostat.
Computing the full pressure tensor with MSM is expensive, and this option
provides a faster alternative. The scalar pressure is computed using a
relationship between the Coulombic energy and pressure <a class="reference internal" href="#hummer"><span class="std std-ref">(Hummer)</span></a>
instead of using the virial equation. This option cannot be used to access
individual components of the pressure tensor, to compute per-atom virial,
or with suffix kspace/pair styles of MSM, like OMP or GPU.</p>
<p>The <em>fftbench</em> keyword applies only to PPPM. It is on by default. If
this option is turned off, LAMMPS will not take the time at the end
of a run to give FFT benchmark timings, and will finish a few seconds
faster than it would if this option were on.</p>
<p>The <em>collective</em> keyword applies only to PPPM. It is set to <em>no</em> by
default, except on IBM BlueGene machines. If this option is set to
<em>yes</em>, LAMMPS will use MPI collective operations to remap data for
3d-FFT operations instead of the default point-to-point communication.
This is faster on IBM BlueGene machines, and may also be faster on
other machines if they have an efficient implementation of MPI
collective operations and adequate hardware.</p>
<p>The <em>diff</em> keyword specifies the differentiation scheme used by the
PPPM method to compute forces on particles given electrostatic
potentials on the PPPM mesh. The <em>ik</em> approach is the default for
PPPM and is the original formulation used in <a class="reference internal" href="kspace_style.html#hockney"><span class="std std-ref">(Hockney)</span></a>. It
performs differentiation in Kspace, and uses 3 FFTs to transfer each
component of the computed fields back to real space for total of 4
FFTs per timestep.</p>
<p>The analytic differentiation <em>ad</em> approach uses only 1 FFT to transfer
information back to real space for a total of 2 FFTs per timestep. It
then performs analytic differentiation on the single quantity to
generate the 3 components of the electric field at each grid point.
This is sometimes referred to as “smoothed” PPPM. This approach
requires a somewhat larger PPPM mesh to achieve the same accuracy as
the <em>ik</em> method. Currently, only the <em>ik</em> method (default) can be
used for a triclinic simulation cell with PPPM. The <em>ad</em> method is
always used for MSM.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Currently, not all PPPM styles support the <em>ad</em> option. Support
for those PPPM variants will be added later.</p>
</div>
<p>The <em>kmax/ewald</em> keyword sets the number of kspace vectors in each
dimension for kspace style <em>ewald</em>. The three values must be positive
integers, or else (0,0,0), which unsets the option. When this option
is not set, the Ewald sum scheme chooses its own kspace vectors,
consistent with the user-specified accuracy and pairwise cutoff. In
any case, if kspace style <em>ewald</em> is invoked, the values used are
printed to the screen and the log file at the start of the run.</p>
<p>With the <em>mix/disp</em> keyword one can select the mixing rule for the
dispersion coefficients. With <em>pair</em>, the dispersion coefficients of
unlike types are computed as indicated with
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>. With <em>geom</em>, geometric mixing is
enforced on the dispersion coefficients in the kspace
coefficients. When using the arithmetic mixing rule, this will
speed-up the simulations but introduces some error in the force
computations, as shown in <a class="reference internal" href="#wennberg"><span class="std std-ref">(Wennberg)</span></a>. With <em>none</em>, it is
assumed that no mixing rule is applicable. Splitting of the dispersion
coefficients will be performed as described in
<a class="reference internal" href="kspace_style.html#isele-holder"><span class="std std-ref">(Isele-Holder)</span></a>. This splitting can be influenced with
the <em>splittol</em> keywords. Only the eigenvalues that are larger than tol
compared to the largest eigenvalues are included. Using this keywords
the original matrix of dispersion coefficients is approximated. This
leads to faster computations, but the accuracy in the reciprocal space
computations of the dispersion part is decreased.</p>
<p>The <em>force/disp/real</em> and <em>force/disp/kspace</em> keywords set the force
accuracy for the real and space computations for the dispersion part
of pppm/disp. As shown in <a class="reference internal" href="kspace_style.html#isele-holder"><span class="std std-ref">(Isele-Holder)</span></a>, optimal
performance and accuracy in the results is obtained when these values
are different.</p>
<p>The <em>disp/auto</em> option controlls whether the pppm/disp is allowed to
generate PPPM parameters automatically. If set to <em>no</em>, parameters have
to be specified using the <em>gewald/disp</em>, <em>mesh/disp</em>,
<em>force/disp/real</em> or <em>force/disp/kspace</em> keywords, or
the code will stop with an error message. When this option is set to
<em>yes</em>, the error message will not appear and the simulation will start.
For a typical application, using the automatic parameter generation will provide
simulations that are either inaccurate or slow. Using this option is thus not
recommended. For guidelines on how to obtain good parameters, see the <a class="reference internal" href="Section_howto.html#howto-23"><span class="std std-ref">How-To</span></a> discussion.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>style = <em>none</em> or <em>ewald</em> or <em>ewald/disp</em> or <em>ewald/omp</em> or <em>pppm</em> or <em>pppm/cg</em> or <em>pppm/disp</em> or <em>pppm/tip4p</em> or <em>pppm/stagger</em> or <em>pppm/disp/tip4p</em> or <em>pppm/gpu</em> or <em>pppm/kk</em> or <em>pppm/omp</em> or <em>pppm/cg/omp</em> or <em>pppm/tip4p/omp</em> or <em>msm</em> or <em>msm/cg</em> or <em>msm/omp</em> or <em>msm/cg/omp</em></li>
</ul>
<pre class="literal-block">
<em>none</em> value = none
<em>ewald</em> value = accuracy
accuracy = desired relative error in forces
<em>ewald/disp</em> value = accuracy
accuracy = desired relative error in forces
<em>ewald/omp</em> value = accuracy
accuracy = desired relative error in forces
<em>pppm</em> value = accuracy
accuracy = desired relative error in forces
<em>pppm/cg</em> value = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units)
<em>pppm/disp</em> value = accuracy
accuracy = desired relative error in forces
<em>pppm/tip4p</em> value = accuracy
accuracy = desired relative error in forces
<em>pppm/disp/tip4p</em> value = accuracy
accuracy = desired relative error in forces
<em>pppm/gpu</em> value = accuracy
accuracy = desired relative error in forces
<em>pppm/kk</em> value = accuracy
accuracy = desired relative error in forces
<em>pppm/omp</em> value = accuracy
accuracy = desired relative error in forces
<em>pppm/cg/omp</em> value = accuracy
accuracy = desired relative error in forces
<em>pppm/tip4p/omp</em> value = accuracy
accuracy = desired relative error in forces
<em>pppm/stagger</em> value = accuracy
accuracy = desired relative error in forces
<em>msm</em> value = accuracy
accuracy = desired relative error in forces
<em>msm/cg</em> value = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units)
<em>msm/omp</em> value = accuracy
accuracy = desired relative error in forces
<em>msm/cg/omp</em> value = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units)
<p>Define a long-range solver for LAMMPS to use each timestep to compute
long-range Coulombic interactions or long-range 1/r^6 interactions.
Most of the long-range solvers perform their computation in K-space,
hence the name of this command.</p>
<p>When such a solver is used in conjunction with an appropriate pair
style, the cutoff for Coulombic or 1/r^N interactions is effectively
infinite. If the Coulombic case, this means each charge in the system
interacts with charges in an infinite array of periodic images of the
simulation domain.</p>
<p>Note that using a long-range solver requires use of a matching <a class="reference internal" href="pair_style.html"><span class="doc">pair style</span></a> to perform consistent short-range pairwise
calculations. This means that the name of the pair style contains a
matching keyword to the name of the KSpace style, as in this table:</p>
<table border="1" class="docutils">
<colgroup>
<col width="49%" />
<col width="51%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>Pair style</td>
<td>KSpace style</td>
</tr>
<tr class="row-even"><td>coul/long</td>
<td>ewald or pppm</td>
</tr>
<tr class="row-odd"><td>coul/msm</td>
<td>msm</td>
</tr>
<tr class="row-even"><td>lj/long or buck/long</td>
<td>disp (for dispersion)</td>
</tr>
<tr class="row-odd"><td>tip4p/long</td>
<td>tip4p</td>
</tr>
</tbody>
</table>
<hr class="docutils" />
<p>The <em>ewald</em> style performs a standard Ewald summation as described in
any solid-state physics text.</p>
<p>The <em>ewald/disp</em> style adds a long-range dispersion sum option for
1/r^6 potentials and is useful for simulation of interfaces
<a class="reference internal" href="pair_lj_long.html#veld"><span class="std std-ref">(Veld)</span></a>. It also performs standard Coulombic Ewald summations,
but in a more efficient manner than the <em>ewald</em> style. The 1/r^6
capability means that Lennard-Jones or Buckingham potentials can be
used without a cutoff, i.e. they become full long-range potentials.
The <em>ewald/disp</em> style can also be used with point-dipoles
<a class="reference internal" href="pair_dipole.html#toukmaji"><span class="std std-ref">(Toukmaji)</span></a> and is currently the only kspace solver in
LAMMPS with this capability.</p>
<hr class="docutils" />
<p>The <em>pppm</em> style invokes a particle-particle particle-mesh solver
<a class="reference internal" href="#hockney"><span class="std std-ref">(Hockney)</span></a> which maps atom charge to a 3d mesh, uses 3d FFTs
to solve Poisson’s equation on the mesh, then interpolates electric
fields on the mesh points back to the atoms. It is closely related to
the particle-mesh Ewald technique (PME) <a class="reference internal" href="#darden"><span class="std std-ref">(Darden)</span></a> used in
AMBER and CHARMM. The cost of traditional Ewald summation scales as
N^(3/2) where N is the number of atoms in the system. The PPPM solver
scales as Nlog(N) due to the FFTs, so it is almost always a faster
<p class="last">All of the PPPM styles can be used with single-precision FFTs by
using the compiler switch -DFFT_SINGLE for the FFT_INC setting in your
lo-level Makefile. This setting also changes some of the PPPM
operations (e.g. mapping charge to mesh and interpolating electric
fields to particles) to be performed in single precision. This option
can speed-up long-range calulations, particularly in parallel or on
GPUs. The use of the -DFFT_SINGLE flag is discussed in <a class="reference internal" href="Section_start.html#start-2-4"><span class="std std-ref">this section</span></a> of the manual. MSM does not
currently support the -DFFT_SINGLE compiler switch.</p>
</div>
<hr class="docutils" />
<p>The <em>msm</em> style invokes a multi-level summation method MSM solver,
<a class="reference internal" href="#hardy"><span class="std std-ref">(Hardy)</span></a> or <a class="reference internal" href="#hardy2"><span class="std std-ref">(Hardy2)</span></a>, which maps atom charge to a 3d
mesh, and uses a multi-level hierarchy of coarser and coarser meshes
on which direct coulomb solves are done. This method does not use
FFTs and scales as N. It may therefore be faster than the other
K-space solvers for relatively large problems when running on large
core counts. MSM can also be used for non-periodic boundary conditions and
for mixed periodic and non-periodic boundaries.</p>
<p>MSM is most competitive versus Ewald and PPPM when only relatively
low accuracy forces, about 1e-4 relative error or less accurate,
are needed. Note that use of a larger coulomb cutoff (i.e. 15
angstroms instead of 10 angstroms) provides better MSM accuracy for
both the real space and grid computed forces.</p>
<p>Currently calculation of the full pressure tensor in MSM is expensive.
Using the <a class="reference internal" href="kspace_modify.html"><span class="doc">kspace_modify</span></a> <em>pressure/scalar yes</em>
command provides a less expensive way to compute the scalar pressure
(Pxx + Pyy + Pzz)/3.0. The scalar pressure can be used, for example,
to run an isotropic barostat. If the full pressure tensor is needed,
then calculating the pressure at every timestep or using a fixed
pressure simulation with MSM will cause the code to run slower.</p>
<hr class="docutils" />
<p>The specified <em>accuracy</em> determines the relative RMS error in per-atom
forces calculated by the long-range solver. It is set as a
dimensionless number, relative to the force that two unit point
charges (e.g. 2 monovalent ions) exert on each other at a distance of
1 Angstrom. This reference value was chosen as representative of the
magnitude of electrostatic forces in atomic systems. Thus an accuracy
value of 1.0e-4 means that the RMS error will be a factor of 10000
smaller than the reference force.</p>
<p>The accuracy setting is used in conjunction with the pairwise cutoff
to determine the number of K-space vectors for style <em>ewald</em> or the
grid size for style <em>pppm</em> or <em>msm</em>.</p>
<p>Note that style <em>pppm</em> only computes the grid size at the beginning of
a simulation, so if the length or triclinic tilt of the simulation
cell increases dramatically during the course of the simulation, the
accuracy of the simulation may degrade. Likewise, if the
<a class="reference internal" href="kspace_modify.html"><span class="doc">kspace_modify slab</span></a> option is used with
shrink-wrap boundaries in the z-dimension, and the box size changes
dramatically in z. For example, for a triclinic system with all three
tilt factors set to the maximum limit, the PPPM grid should be
increased roughly by a factor of 1.5 in the y direction and 2.0 in the
z direction as compared to the same system using a cubic orthogonal
simulation cell. One way to ensure the accuracy requirement is being
met is to run a short simulation at the maximum expected tilt or
length, note the required grid size, and then use the
<a class="reference internal" href="kspace_modify.html"><span class="doc">kspace_modify</span></a> <em>mesh</em> command to manually set the
PPPM grid size to this value.</p>
<p>RMS force errors in real space for <em>ewald</em> and <em>pppm</em> are estimated
using equation 18 of <a class="reference internal" href="#kolafa"><span class="std std-ref">(Kolafa)</span></a>, which is also referenced as
equation 9 of <a class="reference internal" href="#petersen"><span class="std std-ref">(Petersen)</span></a>. RMS force errors in K-space for
<em>ewald</em> are estimated using equation 11 of <a class="reference internal" href="#petersen"><span class="std std-ref">(Petersen)</span></a>,
which is similar to equation 32 of <a class="reference internal" href="#kolafa"><span class="std std-ref">(Kolafa)</span></a>. RMS force
errors in K-space for <em>pppm</em> are estimated using equation 38 of
<a class="reference internal" href="#deserno"><span class="std std-ref">(Deserno)</span></a>. RMS force errors for <em>msm</em> are estimated
using ideas from chapter 3 of <a class="reference internal" href="#hardy"><span class="std std-ref">(Hardy)</span></a>, with equation 3.197
of particular note. When using <em>msm</em> with non-periodic boundary
conditions, it is expected that the error estimation will be too
pessimistic. RMS force errors for dipoles when using <em>ewald/disp</em>
are estimated using equations 33 and 46 of <a class="reference internal" href="pair_polymorphic.html#wang"><span class="std std-ref">(Wang)</span></a>.</p>
<p>See the <a class="reference internal" href="kspace_modify.html"><span class="doc">kspace_modify</span></a> command for additional
options of the K-space solvers that can be set, including a <em>force</em>
option for setting an absoulte RMS error in forces, as opposed to a
relative RMS error.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>More specifically, the <em>pppm/gpu</em> style performs charge assignment and
force interpolation calculations on the GPU. These processes are
performed either in single or double precision, depending on whether
the -DFFT_SINGLE setting was specified in your lo-level Makefile, as
discussed above. The FFTs themselves are still calculated on the CPU.
If <em>pppm/gpu</em> is used with a GPU-enabled pair style, part of the PPPM
calculation can be performed concurrently on the GPU while other
calculations for non-bonded and bonded force calculation are performed
on the CPU.</p>
<p>The <em>pppm/kk</em> style also performs charge assignment and force
interpolation calculations on the GPU while the FFTs themselves are
calculated on the CPU in non-threaded mode.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL,
KOKKOS, USER-OMP, and OPT packages respectively. They are only
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>Note that the long-range electrostatic solvers in LAMMPS assume conducting
metal (tinfoil) boundary conditions for both charge and dipole
interactions. Vacuum boundary conditions are not currently supported.</p>
<p>The <em>ewald/disp</em>, <em>ewald</em>, <em>pppm</em>, and <em>msm</em> styles support
non-orthogonal (triclinic symmetry) simulation boxes. However,
triclinic simulation cells may not yet be supported by suffix versions
of these styles.</p>
<p>All of the kspace styles are part of the KSPACE package. They are
only enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info. Note that
the KSPACE package is installed by default.</p>
<p>For MSM, a simulation must be 3d and one can use any combination of
periodic, non-periodic, or shrink-wrapped boundaries (specified using
the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command).</p>
<p>For Ewald and PPPM, a simulation must be 3d and periodic in all
dimensions. The only exception is if the slab option is set with
<a class="reference internal" href="kspace_modify.html"><span class="doc">kspace_modify</span></a>, in which case the xy dimensions
must be periodic and the z dimension must be non-periodic.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>style = <em>none</em> or <em>sc</em> or <em>bcc</em> or <em>fcc</em> or <em>hcp</em> or <em>diamond</em> or <em>sq</em> or <em>sq2</em> or <em>hex</em> or <em>custom</em></li>
<li>scale = scale factor between lattice and simulation box</li>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>one or more keyword/value pairs may be listed</li>
</ul>
<pre class="literal-block">
keyword = <em>delay</em> or <em>every</em> or <em>check</em> or <em>once</em> or <em>cluster</em> or <em>include</em> or <em>exclude</em> or <em>page</em> or <em>one</em> or <em>binsize</em>
<em>delay</em> value = N
N = delay building until this many steps since last build
<em>every</em> value = M
M = build neighbor list every this many steps
<em>check</em> value = <em>yes</em> or <em>no</em>
<em>yes</em> = only build if some atom has moved half the skin distance or more
<em>no</em> = always build on 1st step that <em>every</em> and <em>delay</em> are satisfied
<em>once</em>
<em>yes</em> = only build neighbor list once at start of run and never rebuild
<em>no</em> = rebuild neighbor list according to other settings
<em>cluster</em>
<em>yes</em> = check bond,angle,etc neighbor list for nearby clusters
<em>no</em> = do not check bond,angle,etc neighbor list for nearby clusters
<em>include</em> value = group-ID
group-ID = only build pair neighbor lists for atoms in this group
<em>exclude</em> values:
type M N
M,N = exclude if one atom in pair is type M, other is type N
group group1-ID group2-ID
group1-ID,group2-ID = exclude if one atom is in 1st group, other in 2nd
molecule group-ID
groupname = exclude if both atoms are in the same molecule and in the same group
none
delete all exclude settings
<em>page</em> value = N
N = number of pairs stored in a single neighbor page
<em>one</em> value = N
N = max number of neighbors of one atom
<em>binsize</em> value = size
size = bin size for neighbor list construction (distance units)
+neigh_modify every 2 delay 10 check yes page 100000
+neigh_modify exclude type 2 3
+neigh_modify exclude group frozen frozen check no
+neigh_modify exclude group residue1 chain3
+neigh_modify exclude molecule rigid
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>This command sets parameters that affect the building and use of
pairwise neighbor lists. Depending on what pair interactions and
other commands are defined, a simulation may require one or more
neighbor lists.</p>
<p>The <em>every</em>, <em>delay</em>, <em>check</em>, and <em>once</em> options affect how often
lists are built as a simulation runs. The <em>delay</em> setting means never
build new lists until at least N steps after the previous build. The
<em>every</em> setting means build lists every M steps (after the delay has
passed). If the <em>check</em> setting is <em>no</em>, the lists are built on the
first step that satisfies the <em>delay</em> and <em>every</em> settings. If the
<em>check</em> setting is <em>yes</em>, then the <em>every</em> and <em>delay</em> settings
determine when a build may possibly be performed, but an actual build
only occurs if some atom has moved more than half the skin distance
(specified in the <a class="reference internal" href="neighbor.html"><span class="doc">neighbor</span></a> command) since the last
build.</p>
<p>If the <em>once</em> setting is yes, then the neighbor list is only built
once at the beginning of each run, and never rebuilt, except on steps
when a restart file is written, or steps when a fix forces a rebuild
to occur (e.g. fixes that create or delete atoms, such as <a class="reference internal" href="fix_deposit.html"><span class="doc">fix deposit</span></a> or <a class="reference internal" href="fix_evaporate.html"><span class="doc">fix evaporate</span></a>).
This setting should only be made if you are certain atoms will not
move far enough that the neighbor list should be rebuilt, e.g. running
a simulation of a cold crystal. Note that it is not that expensive to
check if neighbor lists should be rebuilt.</p>
<p>When the rRESPA integrator is used (see the <a class="reference internal" href="run_style.html"><span class="doc">run_style</span></a>
command), the <em>every</em> and <em>delay</em> parameters refer to the longest
(outermost) timestep.</p>
<p>The <em>cluster</em> option does a sanity test every time neighbor lists are
built for bond, angle, dihedral, and improper interactions, to check
that each set of 2, 3, or 4 atoms is a cluster of nearby atoms. It
does this by computing the distance between pairs of atoms in the
interaction and insuring they are not further apart than half the
periodic box length. If they are, an error is generated, since the
interaction would be computed between far-away atoms instead of their
nearby periodic images. The only way this should happen is if the
pairwise cutoff is so short that atoms that are part of the same
interaction are not communicated as ghost atoms. This is an unusual
model (e.g. no pair interactions at all) and the problem can be fixed
by use of the <a class="reference internal" href="comm_modify.html"><span class="doc">comm_modify cutoff</span></a> command. Note
that to save time, the default <em>cluster</em> setting is <em>no</em>, so that this
check is not performed.</p>
<p>The <em>include</em> option limits the building of pairwise neighbor lists to
atoms in the specified group. This can be useful for models where a
large portion of the simulation is particles that do not interact with
other particles or with each other via pairwise interactions. The
group specified with this option must also be specified via the
<p>The <em>exclude</em> option turns off pairwise interactions between certain
pairs of atoms, by not including them in the neighbor list. These are
sample scenarios where this is useful:</p>
<ul class="simple">
<li>In crack simulations, pairwise interactions can be shut off between 2
slabs of atoms to effectively create a crack.</li>
<li>When a large collection of atoms is treated as frozen, interactions
between those atoms can be turned off to save needless
computation. E.g. Using the <a class="reference internal" href="fix_setforce.html"><span class="doc">fix setforce</span></a> command
to freeze a wall or portion of a bio-molecule.</li>
<li>When one or more rigid bodies are specified, interactions within each
body can be turned off to save needless computation. See the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> command for more details.</li>
</ul>
<p>The <em>exclude type</em> option turns off the pairwise interaction if one
atom is of type M and the other of type N. M can equal N. The
<em>exclude group</em> option turns off the interaction if one atom is in the
first group and the other is the second. Group1-ID can equal
group2-ID. The <em>exclude molecule</em> option turns off the interaction if
both atoms are in the specified group and in the same molecule, as
determined by their molecule ID.</p>
<p>Each of the exclude options can be specified multiple times. The
<em>exclude type</em> option is the most efficient option to use; it requires
only a single check, no matter how many times it has been specified.
The other exclude options are more expensive if specified multiple
times; they require one check for each time they have been specified.</p>
<p>Note that the exclude options only affect pairwise interactions; see
the <a class="reference internal" href="delete_bonds.html"><span class="doc">delete_bonds</span></a> command for information on
turning off bond interactions.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Excluding pairwise interactions will not work correctly when
also using a long-range solver via the
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command. LAMMPS will give a warning
to this effect. This is because the short-range pairwise interaction
needs to subtract off a term from the total energy for pairs whose
short-range interaction is excluded, to compensate for how the
long-range solver treats the interaction. This is done correctly for
pairwise interactions that are excluded (or weighted) via the
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command. But it is not done for
interactions that are excluded via these neigh_modify exclude options.</p>
</div>
<p>The <em>page</em> and <em>one</em> options affect how memory is allocated for the
neighbor lists. For most simulations the default settings for these
options are fine, but if a very large problem is being run or a very
long cutoff is being used, these parameters can be tuned. The indices
of neighboring atoms are stored in “pages”, which are allocated one
after another as they fill up. The size of each page is set by the
<em>page</em> value. A new page is allocated when the next atom’s neighbors
could potentially overflow the list. This threshold is set by the
<em>one</em> value which tells LAMMPS the maximum number of neighbor’s one
atom can have.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">LAMMPS can crash without an error message if the number of
neighbors for a single particle is larger than the <em>page</em> setting,
which means it is much, much larger than the <em>one</em> setting. This is
because LAMMPS doesn’t error check these limits for every pairwise
interaction (too costly), but only after all the particle’s neighbors
have been found. This problem usually means something is very wrong
with the way you’ve setup your problem (particle spacing, cutoff
length, neighbor skin distance, etc). If you really expect that many
neighbors per particle, then boost the <em>one</em> and <em>page</em> settings
accordingly.</p>
</div>
<p>The <em>binsize</em> option allows you to specify what size of bins will be
used in neighbor list construction to sort and find neighboring atoms.
By default, for <a class="reference internal" href="neighbor.html"><span class="doc">neighbor style bin</span></a>, LAMMPS uses bins
that are 1/2 the size of the maximum pair cutoff. For <a class="reference internal" href="neighbor.html"><span class="doc">neighbor style multi</span></a>, the bins are 1/2 the size of the minimum pair
cutoff. Typically these are good values values for minimizing the
time for neighbor list construction. This setting overrides the
default. If you make it too big, there is little overhead due to
looping over bins, but more atoms are checked. If you make it too
small, the optimal number of atoms is checked, but bin overhead goes
up. If you set the binsize to 0.0, LAMMPS will use the default
binsize of 1/2 the cutoff.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>If the “delay” setting is non-zero, then it must be a multiple of the
“every” setting.</p>
<p>The exclude molecule option can only be used with atom styles that
define molecule IDs.</p>
<p>The value of the <em>page</em> setting must be at least 10x larger than the
<em>one</em> setting. This insures neighbor pages are not mostly empty
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>style = <em>gpu</em> or <em>intel</em> or <em>kokkos</em> or <em>omp</em></li>
<li>args = arguments specific to the style</li>
</ul>
<pre class="literal-block">
<em>gpu</em> args = Ngpu keyword value ...
Ngpu = # of GPUs per node
zero or more keyword/value pairs may be appended
keywords = <em>neigh</em> or <em>newton</em> or <em>binsize</em> or <em>split</em> or <em>gpuID</em> or <em>tpa</em> or <em>device</em> or <em>blocksize</em>
<em>neigh</em> value = <em>yes</em> or <em>no</em>
yes = neighbor list build on GPU (default)
no = neighbor list build on CPU
<em>newton</em> = <em>off</em> or <em>on</em>
off = set Newton pairwise flag off (default and required)
on = set Newton pairwise flag on (currently not allowed)
<em>binsize</em> value = size
size = bin size for neighbor list construction (distance units)
<em>split</em> = fraction
fraction = fraction of atoms assigned to GPU (default = 1.0)
<em>gpuID</em> values = first last
first = ID of first GPU to be used on each node
last = ID of last GPU to be used on each node
<em>tpa</em> value = Nthreads
Nthreads = # of GPU threads used per atom
<em>device</em> value = device_type
device_type = <em>kepler</em> or <em>fermi</em> or <em>cypress</em> or <em>generic</em>
<em>blocksize</em> value = size
size = thread block size for pair force computation
<em>intel</em> args = NPhi keyword value ...
Nphi = # of coprocessors per node
zero or more keyword/value pairs may be appended
keywords = <em>mode</em> or <em>omp</em> or <em>lrt</em> or <em>balance</em> or <em>ghost</em> or <em>tpc</em> or <em>tptask</em> or <em>no_affinity</em>
<em>mode</em> value = <em>single</em> or <em>mixed</em> or <em>double</em>
single = perform force calculations in single precision
mixed = perform force calculations in mixed precision
double = perform force calculations in double precision
<em>omp</em> value = Nthreads
Nthreads = number of OpenMP threads to use on CPU (default = 0)
<em>lrt</em> value = <em>yes</em> or <em>no</em>
yes = use additional thread dedicated for some PPPM calculations
no = do not dedicate an extra thread for some PPPM calculations
<em>balance</em> value = split
split = fraction of work to offload to coprocessor, -1 for dynamic
<em>ghost</em> value = <em>yes</em> or <em>no</em>
yes = include ghost atoms for offload
no = do not include ghost atoms for offload
<em>tpc</em> value = Ntpc
Ntpc = max number of coprocessor threads per coprocessor core (default = 4)
<em>tptask</em> value = Ntptask
Ntptask = max number of coprocessor threads per MPI task (default = 240)
<em>no_affinity</em> values = none
<em>kokkos</em> args = keyword value ...
zero or more keyword/value pairs may be appended
keywords = <em>neigh</em> or <em>newton</em> or <em>binsize</em> or <em>comm</em> or <em>comm/exchange</em> or <em>comm/forward</em>
<em>neigh</em> value = <em>full</em> or <em>half</em> or <em>n2</em> or <em>full/cluster</em>
full = full neighbor list
half = half neighbor list built in thread-safe manner
n2 = non-binning neighbor list build, O(N^2) algorithm
full/cluster = full neighbor list with clustered groups of atoms
<em>newton</em> = <em>off</em> or <em>on</em>
off = set Newton pairwise and bonded flags off (default)
on = set Newton pairwise and bonded flags on
<em>binsize</em> value = size
size = bin size for neighbor list construction (distance units)
<em>comm</em> value = <em>no</em> or <em>host</em> or <em>device</em>
use value for both comm/exchange and comm/forward
<em>comm/exchange</em> value = <em>no</em> or <em>host</em> or <em>device</em>
<em>comm/forward</em> value = <em>no</em> or <em>host</em> or <em>device</em>
no = perform communication pack/unpack in non-KOKKOS mode
host = perform pack/unpack on host (e.g. with OpenMP threading)
device = perform pack/unpack on device (e.g. on GPU)
<em>omp</em> args = Nthreads keyword value ...
Nthread = # of OpenMP threads to associate with each MPI process
zero or more keyword/value pairs may be appended
keywords = <em>neigh</em>
<em>neigh</em> value = <em>yes</em> or <em>no</em>
<p>This command invokes package-specific settings for the various
accelerator packages available in LAMMPS. Currently the following
packages use settings from this command: GPU, USER-INTEL, KOKKOS, and
USER-OMP.</p>
<p>If this command is specified in an input script, it must be near the
top of the script, before the simulation box has been defined. This
is because it specifies settings that the accelerator packages use in
their intialization, before a simultion is defined.</p>
<p>This command can also be specified from the command-line when
launching LAMMPS, using the “-pk” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>. The syntax is exactly the same as
when used in an input script.</p>
<p>Note that all of the accelerator packages require the package command
to be specified (except the OPT package), if the package is to be used
in a simulation (LAMMPS can be built with an accelerator package
without using it in a particular simulation). However, in all cases,
a default version of the command is typically invoked by other
accelerator settings.</p>
<p>The KOKKOS package requires a “-k on” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> respectively, which invokes a
“package kokkos” command with default settings.</p>
<p>For the GPU, USER-INTEL, and USER-OMP packages, if a “-sf gpu” or “-sf
is used to auto-append accelerator suffixes to various styles in the
input script, then those switches also invoke a “package gpu”,
“package intel”, or “package omp” command with default settings.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">A package command for a particular style can be invoked multiple
times when a simulation is setup, e.g. by the “-c on”, “-k on”, “-sf”,
and “-pk” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switches</span></a>, and by
using this command in an input script. Each time it is used all of
the style options are set, either to default values or to specified
settings. I.e. settings from previous invocations do not persist
across multiple invocations.</p>
</div>
<p>See the <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section Accelerate</span></a> section of the
manual for more details about using the various accelerator packages
for speeding up LAMMPS simulations.</p>
<hr class="docutils" />
<p>The <em>gpu</em> style invokes settings associated with the use of the GPU
package.</p>
<p>The <em>Ngpu</em> argument sets the number of GPUs per node. There must be
at least as many MPI tasks per node as GPUs, as set by the mpirun or
mpiexec command. If there are more MPI tasks (per node)
than GPUs, multiple MPI tasks will share each GPU.</p>
<p>Optional keyword/value pairs can also be specified. Each has a
default value as listed below.</p>
<p>The <em>neigh</em> keyword specifies where neighbor lists for pair style
computation will be built. If <em>neigh</em> is <em>yes</em>, which is the default,
neighbor list building is performed on the GPU. If <em>neigh</em> is <em>no</em>,
neighbor list building is performed on the CPU. GPU neighbor list
building currently cannot be used with a triclinic box. GPU neighbor
list calculation currently cannot be used with
<a class="reference internal" href="pair_hybrid.html"><span class="doc">hybrid</span></a> pair styles. GPU neighbor lists are not
compatible with comannds that are not GPU-enabled. When a non-GPU
enabled command requires a neighbor list, it will also be built on the
CPU. In these cases, it will typically be more efficient to only use
CPU neighbor list builds.</p>
<p>The <em>newton</em> keyword sets the Newton flags for pairwise (not bonded)
interactions to <em>off</em> or <em>on</em>, the same as the <a class="reference internal" href="newton.html"><span class="doc">newton</span></a>
command allows. Currently, only an <em>off</em> value is allowed, since all
the GPU package pair styles require this setting. This means more
computation is done, but less communication. In the future a value of
<em>on</em> may be allowed, so the <em>newton</em> keyword is included as an option
for compatibility with the package command for other accelerator
styles. Note that the newton setting for bonded interactions is not
affected by this keyword.</p>
<p>The <em>binsize</em> keyword sets the size of bins used to bin atoms in
neighbor list builds performed on the GPU, if <em>neigh</em> = <em>yes</em> is set.
If <em>binsize</em> is set to 0.0 (the default), then bins = the size of the
pairwise cutoff + neighbor skin distance. This is 2x larger than the
LAMMPS default used for neighbor list building on the CPU. This will
be close to optimal for the GPU, so you do not normally need to use
this keyword. Note that if you use a longer-than-usual pairwise
cutoff, e.g. to allow for a smaller fraction of KSpace work with a
<a class="reference internal" href="kspace_style.html"><span class="doc">long-range Coulombic solver</span></a> because the GPU is
faster at performing pairwise interactions, then it may be optimal to
make the <em>binsize</em> smaller than the default. For example, with a
cutoff of 20*sigma in LJ <a class="reference internal" href="units.html"><span class="doc">units</span></a> and a neighbor skin
distance of sigma, a <em>binsize</em> = 5.25*sigma can be more efficient than
the default.</p>
<p>The <em>split</em> keyword can be used for load balancing force calculations
between CPU and GPU cores in GPU-enabled pair styles. If 0 < <em>split</em> <
1.0, a fixed fraction of particles is offloaded to the GPU while force
calculation for the other particles occurs simulataneously on the CPU.
If <em>split</em> < 0.0, the optimal fraction (based on CPU and GPU timings)
is calculated every 25 timesteps, i.e. dynamic load-balancing across
the CPU and GPU is performed. If <em>split</em> = 1.0, all force
calculations for GPU accelerated pair styles are performed on the GPU.
In this case, other <a class="reference internal" href="pair_hybrid.html"><span class="doc">hybrid</span></a> pair interactions,
<p>In this case, all CPU cores and GPU devices on the nodes would be
utilized. Each GPU device would be shared by 4 CPU cores. The CPU
cores would perform force calculations for some fraction of the
particles at the same time the GPUs performed force calculation for
the other particles.</p>
<p>The <em>gpuID</em> keyword allows selection of which GPUs on each node will
be used for a simulation. The <em>first</em> and <em>last</em> values specify the
GPU IDs to use (from 0 to Ngpu-1). By default, first = 0 and last =
Ngpu-1, so that all GPUs are used, assuming Ngpu is set to the number
of physical GPUs. If you only wish to use a subset, set Ngpu to a
smaller number and first/last to a sub-range of the available GPUs.</p>
<p>The <em>tpa</em> keyword sets the number of GPU thread per atom used to
perform force calculations. With a default value of 1, the number of
threads will be chosen based on the pair style, however, the value can
be set explicitly with this keyword to fine-tune performance. For
large cutoffs or with a small number of particles per GPU, increasing
the value can improve performance. The number of threads per atom must
be a power of 2 and currently cannot be greater than 32.</p>
<p>The <em>device</em> keyword can be used to tune parameters optimized for a
specific accelerator, when using OpenCL. For CUDA, the <em>device</em>
keyword is ignored. Currently, the device type is limited to NVIDIA
Kepler, NVIDIA Fermi, AMD Cypress, or a generic device. More devices
may be added later. The default device type can be specified when
building LAMMPS with the GPU library, via settings in the
lib/gpu/Makefile that is used.</p>
<p>The <em>blocksize</em> keyword allows you to tweak the number of threads used
per thread block. This number should be a multiple of 32 (for GPUs)
and its maximum depends on the specific GPU hardware. Typical choices
are 64, 128, or 256. A larger blocksize increases occupancy of
individual GPU cores, but reduces the total number of thread blocks,
thus may lead to load imbalance.</p>
<hr class="docutils" />
<p>The <em>intel</em> style invokes settings associated with the use of the
USER-INTEL package. All of its settings, except the <em>omp</em> and <em>mode</em>
keywords, are ignored if LAMMPS was not built with Xeon Phi
coprocessor support. All of its settings, including the <em>omp</em> and
<em>mode</em> keyword are applicable if LAMMPS was built with coprocessor
support.</p>
<p>The <em>Nphi</em> argument sets the number of coprocessors per node.
This can be set to any value, including 0, if LAMMPS was not
built with coprocessor support.</p>
<p>Optional keyword/value pairs can also be specified. Each has a
default value as listed below.</p>
<p>The <em>omp</em> keyword determines the number of OpenMP threads allocated
for each MPI task when any portion of the interactions computed by a
USER-INTEL pair style are run on the CPU. This can be the case even
if LAMMPS was built with coprocessor support; see the <em>balance</em>
keyword discussion below. If you are running with less MPI tasks/node
than there are CPUs, it can be advantageous to use OpenMP threading on
the CPUs.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The <em>omp</em> keyword has nothing to do with coprocessor threads on
the Xeon Phi; see the <em>tpc</em> and <em>tptask</em> keywords below for a
discussion of coprocessor threads.</p>
</div>
<p>The <em>Nthread</em> value for the <em>omp</em> keyword sets the number of OpenMP
threads allocated for each MPI task. Setting <em>Nthread</em> = 0 (the
default) instructs LAMMPS to use whatever value is the default for the
given OpenMP environment. This is usually determined via the
<em>OMP_NUM_THREADS</em> environment variable or the compiler runtime, which
is usually a value of 1.</p>
<p>For more details, including examples of how to set the OMP_NUM_THREADS
environment variable, see the discussion of the <em>Nthreads</em> setting on
this doc page for the “package omp” command. Nthreads is a required
argument for the USER-OMP package. Its meaning is exactly the same
for the USER-INTEL pacakge.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you build LAMMPS with both the USER-INTEL and USER-OMP
packages, be aware that both packages allow setting of the <em>Nthreads</em>
value via their package commands, but there is only a single global
<em>Nthreads</em> value used by OpenMP. Thus if both package commands are
invoked, you should insure the two values are consistent. If they are
not, the last one invoked will take precedence, for both packages.
Also note that if the “-sf hybrid intel omp” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> is used, it invokes a “package
intel” command, followed by a “package omp” command, both with a
setting of <em>Nthreads</em> = 0.</p>
</div>
<p>The <em>mode</em> keyword determines the precision mode to use for
computing pair style forces, either on the CPU or on the coprocessor,
when using a USER-INTEL supported <a class="reference internal" href="pair_style.html"><span class="doc">pair style</span></a>. It
can take a value of <em>single</em>, <em>mixed</em> which is the default, or
<em>double</em>. <em>Single</em> means single precision is used for the entire
force calculation. <em>Mixed</em> means forces between a pair of atoms are
computed in single precision, but accumulated and stored in double
precision, including storage of forces, torques, energies, and virial
quantities. <em>Double</em> means double precision is used for the entire
force calculation.</p>
<p>The <em>lrt</em> keyword can be used to enable “Long Range Thread (LRT)”
mode. It can take a value of <em>yes</em> to enable and <em>no</em> to disable.
LRT mode generates an extra thread (in addition to any OpenMP threads
specified with the OMP_NUM_THREADS environment variable or the <em>omp</em>
keyword). The extra thread is dedicated for performing part of the
<a class="reference internal" href="kspace_style.html"><span class="doc">PPPM solver</span></a> computations and communications. This
can improve parallel performance on processors supporting
Simultaneous Multithreading (SMT) such as Hyperthreading on Intel
processors. In this mode, one additional thread is generated per MPI
process. LAMMPS will generate a warning in the case that more threads
are used than available in SMT hardware on a node. If the PPPM solver
from the USER-INTEL package is not used, then the LRT setting is
ignored and no extra threads are generated. Enabling LRT will replace
the <a class="reference internal" href="run_style.html"><span class="doc">run_style</span></a> with the <em>verlet/lrt/intel</em> style that
is identical to the default <em>verlet</em> style aside from supporting the
LRT feature.</p>
<p>The <em>balance</em> keyword sets the fraction of <a class="reference internal" href="pair_style.html"><span class="doc">pair style</span></a> work offloaded to the coprocessor for split
values between 0.0 and 1.0 inclusive. While this fraction of work is
running on the coprocessor, other calculations will run on the host,
including neighbor and pair calculations that are not offloaded, as
well as angle, bond, dihedral, kspace, and some MPI communications.
If <em>split</em> is set to -1, the fraction of work is dynamically adjusted
automatically throughout the run. This typically give performance
within 5 to 10 percent of the optimal fixed fraction.</p>
<p>The <em>ghost</em> keyword determines whether or not ghost atoms, i.e. atoms
at the boundaries of proessor sub-domains, are offloaded for neighbor
and force calculations. When the value = “no”, ghost atoms are not
offloaded. This option can reduce the amount of data transfer with
the coprocessor and can also overlap MPI communication of forces with
computation on the coprocessor when the <a class="reference internal" href="newton.html"><span class="doc">newton pair</span></a>
setting is “on”. When the value = “yes”, ghost atoms are offloaded.
In some cases this can provide better performance, especially if the
<em>balance</em> fraction is high.</p>
<p>The <em>tpc</em> keyword sets the max # of coprocessor threads <em>Ntpc</em> that
will run on each core of the coprocessor. The default value = 4,
which is the number of hardware threads per core supported by the
current generation Xeon Phi chips.</p>
<p>The <em>tptask</em> keyword sets the max # of coprocessor threads (Ntptask*
assigned to each MPI task. The default value = 240, which is the
total # of threads an entire current generation Xeon Phi chip can run
(240 = 60 cores * 4 threads/core). This means each MPI task assigned
to the Phi will enough threads for the chip to run the max allowed,
even if only 1 MPI task is assigned. If 8 MPI tasks are assigned to
the Phi, each will run with 30 threads. If you wish to limit the
number of threads per MPI task, set <em>tptask</em> to a smaller value.
E.g. for <em>tptask</em> = 16, if 8 MPI tasks are assigned, each will run
with 16 threads, for a total of 128.</p>
<p>Note that the default settings for <em>tpc</em> and <em>tptask</em> are fine for
most problems, regardless of how many MPI tasks you assign to a Phi.</p>
<p>The <em>no_affinity</em> keyword will turn off automatic setting of core
affinity for MPI tasks and OpenMP threads on the host when using
offload to a coprocessor. Affinity settings are used when possible
to prevent MPI tasks and OpenMP threads from being on separate NUMA
domains and to prevent offload threads from interfering with other
processes/threads used for LAMMPS.</p>
<hr class="docutils" />
<p>The <em>kokkos</em> style invokes settings associated with the use of the
KOKKOS package.</p>
<p>All of the settings are optional keyword/value pairs. Each has a
default value as listed below.</p>
<p>The <em>neigh</em> keyword determines how neighbor lists are built. A value
of <em>half</em> uses a thread-safe variant of half-neighbor lists,
the same as used by most pair styles in LAMMPS. A value of
<em>n2</em> uses an O(N^2) algorithm to build the neighbor list without
binning, where N = # of atoms on a processor. It is typically slower
than the other methods, which use binning.</p>
<p>A value of <em>full</em> uses a full neighbor lists and is the default. This
performs twice as much computation as the <em>half</em> option, however that
is often a win because it is thread-safe and doesn’t require atomic
operations in the calculation of pair forces. For that reason, <em>full</em>
is the default setting. However, when running in MPI-only mode with 1
thread per MPI task, <em>half</em> neighbor lists will typically be faster,
just as it is for non-accelerated pair styles.</p>
<p>A value of <em>full/cluster</em> is an experimental neighbor style, where
particles interact with all particles within a small cluster, if at
least one of the clusters particles is within the neighbor cutoff
range. This potentially allows for better vectorization on
architectures such as the Intel Phi. If also reduces the size of the
neighbor list by roughly a factor of the cluster size, thus reducing
the total memory footprint considerably.</p>
<p>The <em>newton</em> keyword sets the Newton flags for pairwise and bonded
interactions to <em>off</em> or <em>on</em>, the same as the <a class="reference internal" href="newton.html"><span class="doc">newton</span></a>
command allows. The default is <em>off</em> because this will almost always
give better performance for the KOKKOS package. This means more
computation is done, but less communication. However, when running in
MPI-only mode with 1 thread per MPI task, a value of <em>on</em> will
typically be faster, just as it is for non-accelerated pair styles.</p>
<p>The <em>binsize</em> keyword sets the size of bins used to bin atoms in
neighbor list builds. The same value can be set by the <a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify binsize</span></a> command. Making it an option in the
package kokkos command allows it to be set from the command line. The
default value is 0.0, which means the LAMMPS default will be used,
which is bins = 1/2 the size of the pairwise cutoff + neighbor skin
distance. This is fine when neighbor lists are built on the CPU. For
GPU builds, a 2x larger binsize equal to the pairwise cutoff +
neighbor skin, is often faster, which can be set by this keyword.
Note that if you use a longer-than-usual pairwise cutoff, e.g. to
allow for a smaller fraction of KSpace work with a <a class="reference internal" href="kspace_style.html"><span class="doc">long-range Coulombic solver</span></a> because the GPU is faster at
performing pairwise interactions, then this rule of thumb may give too
large a binsize.</p>
<p>The <em>comm</em> and <em>comm/exchange</em> and <em>comm/forward</em> keywords determine
whether the host or device performs the packing and unpacking of data
when communicating per-atom data between processors. “Exchange”
communication happens only on timesteps that neighbor lists are
rebuilt. The data is only for atoms that migrate to new processors.
“Forward” communication happens every timestep. The data is for atom
coordinates and any other atom properties that needs to be updated for
ghost atoms owned by each processor.</p>
<p>The <em>comm</em> keyword is simply a short-cut to set the same value
for both the <em>comm/exchange</em> and <em>comm/forward</em> keywords.</p>
<p>The value options for all 3 keywords are <em>no</em> or <em>host</em> or <em>device</em>.
A value of <em>no</em> means to use the standard non-KOKKOS method of
packing/unpacking data for the communication. A value of <em>host</em> means
to use the host, typically a multi-core CPU, and perform the
packing/unpacking in parallel with threads. A value of <em>device</em> means
to use the device, typically a GPU, to perform the packing/unpacking
operation.</p>
<p>The optimal choice for these keywords depends on the input script and
the hardware used. The <em>no</em> value is useful for verifying that the
Kokkos-based <em>host</em> and <em>device</em> values are working correctly. It may
also be the fastest choice when using Kokkos styles in MPI-only mode
(i.e. with a thread count of 1).</p>
<p>When running on CPUs or Xeon Phi, the <em>host</em> and <em>device</em> values work
identically. When using GPUs, the <em>device</em> value will typically be
optimal if all of your styles used in your input script are supported
by the KOKKOS package. In this case data can stay on the GPU for many
timesteps without being moved between the host and GPU, if you use the
<em>device</em> value. This requires that your MPI is able to access GPU
memory directly. Currently that is true for OpenMPI 1.8 (or later
versions), Mvapich2 1.9 (or later), and CrayMPI. If your script uses
styles (e.g. fixes) which are not yet supported by the KOKKOS package,
then data has to be move between the host and device anyway, so it is
typically faster to let the host handle communication, by using the
<em>host</em> value. Using <em>host</em> instead of <em>no</em> will enable use of
multiple threads to pack/unpack communicated data.</p>
<hr class="docutils" />
<p>The <em>omp</em> style invokes settings associated with the use of the
USER-OMP package.</p>
<p>The <em>Nthread</em> argument sets the number of OpenMP threads allocated for
each MPI task. For example, if your system has nodes with dual
quad-core processors, it has a total of 8 cores per node. You could
use two MPI tasks per node (e.g. using the -ppn option of the mpirun
command in MPICH or -npernode in OpenMPI), and set <em>Nthreads</em> = 4.
This would use all 8 cores on each node. Note that the product of MPI
tasks * threads/task should not exceed the physical number of cores
(on a node), otherwise performance will suffer.</p>
<p>Setting <em>Nthread</em> = 0 instructs LAMMPS to use whatever value is the
default for the given OpenMP environment. This is usually determined
via the <em>OMP_NUM_THREADS</em> environment variable or the compiler
runtime. Note that in most cases the default for OpenMP capable
compilers is to use one thread for each available CPU core when
<em>OMP_NUM_THREADS</em> is not explicitly set, which can lead to poor
performance.</p>
<p>Here are examples of how to set the environment variable when
<p>The gpu style of this command can only be invoked if LAMMPS was built
with the GPU package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The intel style of this command can only be invoked if LAMMPS was
built with the USER-INTEL package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The kk style of this command can only be invoked if LAMMPS was built
with the KOKKOS package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The omp style of this command can only be invoked if LAMMPS was built
with the USER-OMP package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>For the GPU package, the default is Ngpu = 1 and the option defaults
are neigh = yes, newton = off, binsize = 0.0, split = 1.0, gpuID = 0
to Ngpu-1, tpa = 1, and device = not used. These settings are made
automatically if the “-sf gpu” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> is used. If it is not used, you
must invoke the package gpu command in your input script or via the
<p>For the USER-INTEL package, the default is Nphi = 1 and the option
defaults are omp = 0, mode = mixed, lrt = no, balance = -1, tpc = 4,
tptask = 240. The default ghost option is determined by the pair
style being used. This value is output to the screen in the offload
report at the end of each run. Note that all of these settings,
except “omp” and “mode”, are ignored if LAMMPS was not built with
Xeon Phi coprocessor support. These settings are made automatically
if the “-sf intel” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>
is used. If it is not used, you must invoke the package intel
command in your input script or or via the “-pk intel” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>.</p>
<p>For the KOKKOS package, the option defaults neigh = full, newton =
off, binsize = 0.0, and comm = device. These settings are made
automatically by the required “-k on” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>. You can change them bu using the
package kokkos command in your input script or via the “-pk kokkos”
<p>For the OMP package, the default is Nthreads = 0 and the option
defaults are neigh = yes. These settings are made automatically if
the “-sf omp” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> is
used. If it is not used, you must invoke the package omp command in
your input script or via the “-pk omp” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Style <em>adp</em> computes pairwise interactions for metals and metal alloys
using the angular dependent potential (ADP) of <a class="reference internal" href="#mishin"><span class="std std-ref">(Mishin)</span></a>,
which is a generalization of the <a class="reference internal" href="pair_eam.html"><span class="doc">embedded atom method (EAM) potential</span></a>. The LAMMPS implementation is discussed in
<a class="reference internal" href="#singh"><span class="std std-ref">(Singh)</span></a>. The total energy Ei of an atom I is given by</p>
Nelements). The tabulated values for each phi function are listed as
r*phi (in units of eV-Angstroms), since they are for atom pairs, the
same as for <a class="reference internal" href="pair_eam.html"><span class="doc">other EAM files</span></a>.</p>
<p>After the phi(r) arrays, each of the u(r) arrays are listed in the
same order with the same assumptions of symmetry. Directly following
the u(r), the w(r) arrays are listed. Note that phi(r) is the only
array tabulated with a scaling by r.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, no special mixing rules are needed, since
the ADP potential files specify alloy interactions explicitly.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in tabulated potential files.
Thus, you need to re-specify the pair_style and pair_coeff commands in
an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The first three C arguments map LAMMPS atom types 1,2,3 to the C
element in the AIREBO file. The final H argument maps LAMMPS atom
type 4 to the H element in the SW file. If a mapping value is
specified as NULL, the mapping is not performed. This can be used
when a <em>airebo</em> potential is used as part of the <em>hybrid</em> pair style.
The NULL values are placeholders for atom types that will be used with
other potentials.</p>
<p>The parameters/coefficients for the AIREBO potentials are listed in
the CH.airebo file to agree with the original <a class="reference internal" href="#stuart"><span class="std std-ref">(Stuart)</span></a>
paper. Thus the parameters are specific to this potential and the way
it was fit, so modifying the file should be done cautiously.</p>
<p>Similarly the parameters/coefficients for the AIREBO-M potentials are
listed in the CH.airebo-m file to agree with the <a class="reference internal" href="#oconnor"><span class="std std-ref">(O’Connor)</span></a>
paper. Thus the parameters are specific to this potential and the way
it was fit, so modifying the file should be done cautiously. The
AIREBO-M Morse potentials were parameterized using a cutoff of
3.0 (sigma). Modifying this cutoff may impact simulation accuracy.</p>
<p>This pair style tallies a breakdown of the total AIREBO potential
energy into sub-categories, which can be accessed via the <a class="reference internal" href="compute_pair.html"><span class="doc">compute pair</span></a> command as a vector of values of length 3.
The 3 values correspond to the following sub-categories:</p>
<ol class="arabic simple">
<li><em>E_REBO</em> = REBO energy</li>
<li><em>E_LJ</em> = Lennard-Jones energy</li>
<li><em>E_TORSION</em> = Torsion energy</li>
</ol>
<p>To print these quantities to the log file (with descriptive column
headings) the following commands could be included in an input script:</p>
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>These pair styles do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
mix, shift, table, and tail options.</p>
<p>These pair styles do not write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The last coefficient is optional. If not specified, the global cutoff
Rc is used.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, coeffiecients must be specified.
No default mixing rules are used.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift
option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of this pair style can be mixed. The
default mix value is <em>geometric</em>. See the “pair_modify” command for
details.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>This style is part of the BODY package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-2-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Defining particles to be bodies so they participate in body/body or
body/particle interactions requires the use of the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style body</span></a> command.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The first three Cd arguments map LAMMPS atom types 1,2,3 to the Cd
element in the BOP file. The final Te argument maps LAMMPS atom type
4 to the Te element in the BOP file.</p>
<p>BOP files in the <em>potentials</em> directory of the LAMMPS distribution
have a ”.bop” suffix. The potentials are in tabulated form containing
pre-tabulated pair functions for phi_ij(r_ij), beta_(sigma,ij)(r_ij),
and beta_pi,ij)(r_ij).</p>
<p>The parameters/coefficients format for the different kinds of BOP
files are given below with variables matching the formulation of Ward
(<a class="reference internal" href="#ward"><span class="std std-ref">Ward</span></a>) and Zhou (<a class="reference internal" href="pair_polymorphic.html#zhou"><span class="std std-ref">Zhou</span></a>). Each header line containing a
<p>The parameters/coefficients format for the BOP potentials input file
containing pre-tabulated functions of g is given below with variables
matching the formulation of Ward (<a class="reference internal" href="#ward"><span class="std std-ref">Ward</span></a>). This format also
assumes the angular functions have the formulation of (<a class="reference internal" href="pair_polymorphic.html#zhou"><span class="std std-ref">Zhou</span></a>).</p>
<ul class="simple">
<li>Line 1: # elements N</li>
</ul>
<p>The first line is followed by N lines containing the atomic
number, mass, and element symbol of each element.</p>
<p>Following the definition of the elements several global variables for
the tabulated functions are given.</p>
<ul class="simple">
<li>Line 1: nr, ntheta, nBOt (nr is the number of divisions the radius is broken
into for function tables and MUST be a factor of 5; ntheta is the power of the
power of the spline used to fit the angular function; nBOt is the number
of divisions for the tabulated values of THETA_(S,ij)</li>
<li>Line 2: delta_1-delta_7 (if all are not used in the particular</li>
<li>formulation, set unused values to 0.0)</li>
</ul>
<p>Following this N lines for e_1-e_N containing p_pi.</p>
<ul class="simple">
<li>Line 3: p_pi (for e_1)</li>
<li>Line 4: p_pi (for e_2 and continues to e_N)</li>
</ul>
<p>The next section contains several pair constants for the number of
interaction types e_i-e_j, with i=1->N, j=i->N</p>
<ul class="simple">
<li>Line 1: r_cut (for e_1-e_1 interactions)</li>
<li>Line 2: c_sigma, a_sigma, c_pi, a_pi</li>
<li>Line 3: delta_sigma, delta_pi</li>
<li>Line 4: f_sigma, k_sigma, delta_3 (This delta_3 is similar to that of
the previous section but is interaction type dependent)</li>
</ul>
<p>The next section contains a line for each three body interaction type
e_j-e_i-e_k with i=0->N, j=0->N, k=j->N</p>
<ul class="simple">
<li>Line 1: g0, g1, g2... (These are coefficients for the angular spline
of the g_(sigma,jik)(THETA_ijk) for e_1-e_1-e_1 interaction. The
function can contain up to 10 term thus 10 constants. The first line
can contain up to five constants. If the spline has more than five
terms the second line will contain the remaining constants The
following lines will then contain the constants for the remainaing g0,
g1, g2... (for e_1-e_1-e_2) and the other three body
interactions</li>
</ul>
<p>The rest of the table has the same structure as the previous section
<p>The parameters/coefficients format for the BOP potentials input file
containing pre-tabulated functions of g is given below with variables
matching the formulation of Ward (<a class="reference internal" href="#ward"><span class="std std-ref">Ward</span></a>). This format also
assumes the angular functions have the formulation of (<a class="reference internal" href="pair_polymorphic.html#zhou"><span class="std std-ref">Zhou</span></a>).</p>
<ul class="simple">
<li>Line 1: # elements N</li>
</ul>
<p>The first two lines are followed by N lines containing the atomic
number, mass, and element symbol of each element.</p>
<p>Following the definition of the elements several global variables for
the tabulated functions are given.</p>
<ul class="simple">
<li>Line 1: nr, ntheta, nBOt (nr is the number of divisions the radius is broken
into for function tables and MUST be a factor of 5; ntheta is the number of
divisions for the tabulated values of the g angular function; nBOt is the number
of divisions for the tabulated values of THETA_(S,ij)</li>
<li>Line 2: delta_1-delta_7 (if all are not used in the particular</li>
<li>formulation, set unused values to 0.0)</li>
</ul>
<p>Following this N lines for e_1-e_N containing p_pi.</p>
<ul class="simple">
<li>Line 3: p_pi (for e_1)</li>
<li>Line 4: p_pi (for e_2 and continues to e_N)</li>
</ul>
<p>The next section contains several pair constants for the number of
interaction types e_i-e_j, with i=1->N, j=i->N</p>
<ul class="simple">
<li>Line 1: r_cut (for e_1-e_1 interactions)</li>
<li>Line 2: c_sigma, a_sigma, c_pi, a_pi</li>
<li>Line 3: delta_sigma, delta_pi</li>
<li>Line 4: f_sigma, k_sigma, delta_3 (This delta_3 is similar to that of
the previous section but is interaction type dependent)</li>
</ul>
<p>The next section contains a line for each three body interaction type
e_j-e_i-e_k with i=0->N, j=0->N, k=j->N</p>
<ul class="simple">
<li>Line 1: g(theta1), g(theta2), g(theta3), g(theta4), g(theta5) (for the e_1-e_1-e_1
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
mix, shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where sigma is an interaction-dependent length parameter, rho is an
ionic-pair dependent length parameter, and Rc is the cutoff.</p>
<p>The styles with <em>coul/long</em> or <em>coul/msm</em> add a Coulombic term as
described for the <a class="reference internal" href="pair_lj.html"><span class="doc">lj/cut</span></a> pair styles. An additional
damping factor is applied to the Coulombic term so it can be used in
conjunction with the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command and its
<em>ewald</em> or <em>pppm</em> of <em>msm</em> option. The Coulombic cutoff specified for
this style means that pairwise interactions within this distance are
computed directly; interactions outside that distance are computed in
reciprocal space.</p>
<p>If one cutoff is specified for the <em>born/coul/long</em> and
<em>born/coul/msm</em> style, it is used for both the A,C,D and Coulombic
terms. If two cutoffs are specified, the first is used as the cutoff
for the A,C,D terms, and the second is the cutoff for the Coulombic
term.</p>
<p>The <em>born/coul/wolf</em> style adds a Coulombic term as described for the
Wolf potential in the <a class="reference internal" href="pair_coul.html"><span class="doc">coul/wolf</span></a> pair style.</p>
<p>Style <em>born/coul/long/cs</em> is identical to <em>born/coul/long</em> except that
a term is added for the <a class="reference internal" href="Section_howto.html#howto-25"><span class="std std-ref">core/shell model</span></a>
to allow charges on core and shell particles to be separated by r =
0.0.</p>
<p>Note that these potentials are related to the <a class="reference internal" href="pair_buck.html"><span class="doc">Buckingham potential</span></a>.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<p>The second coefficient, rho, must be greater than zero.</p>
<p>The last coefficient is optional. If not specified, the global A,C,D
cutoff specified in the pair_style command is used.</p>
<p>For <em>born/coul/long</em> and <em>born/coul/wolf</em> no Coulombic cutoff can be
specified for an individual I,J type pair. All type pairs use the
same global Coulombic cutoff specified in the pair_style command.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>These pair styles do not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>These styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option
for the energy of the exp(), 1/r^6, and 1/r^8 portion of the pair
interaction.</p>
<p>The <em>born/coul/long</em> pair style supports the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option ti tabulate the
short-range portion of the long-range Coulombic interaction.</p>
<p>These styles support the pair_modify tail option for adding long-range
tail corrections to energy and pressure.</p>
<p>Thess styles writes thei information to binary <a class="reference internal" href="restart.html"><span class="doc">restart</span></a>
files, so pair_style and pair_coeff commands do not need to be
specified in an input script that reads a restart file.</p>
<p>These styles can only be used via the <em>pair</em> keyword of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the <em>inner</em>,
<em>middle</em>, <em>outer</em> keywords.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The <em>born/coul/long</em> style is part of the KSPACE package. It is only
enabled if LAMMPS was built with that package (which it is by
default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Styles <em>brownian</em> and <em>brownian/poly</em> compute Brownian forces and
torques on finite-size spherical particles. The former requires
monodisperse spherical particles; the latter allows for polydisperse
spherical particles.</p>
<p>These pair styles are designed to be used with either the <a class="reference internal" href="pair_lubricate.html"><span class="doc">pair_style lubricate</span></a> or <a class="reference internal" href="pair_lubricateU.html"><span class="doc">pair_style lubricateU</span></a> commands to provide thermostatting
when dissipative lubrication forces are acting. Thus the parameters
<em>mu</em>, <em>flaglog</em>, <em>flagfld</em>, <em>cutinner</em>, and <em>cutoff</em> should be
specified consistent with the settings in the lubrication pair styles.
For details, refer to either of the lubrication pair styles.</p>
<p>The <em>t_target</em> setting is used to specify the target temperature of
the system. The random number <em>seed</em> is used to generate random
numbers for the thermostatting procedure.</p>
<p>The <em>flagHI</em> and <em>flagVF</em> settings are optional. Neither should be
used, or both must be defined.</p>
<hr class="docutils" />
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<p>The two coefficients are optional. If neither is specified, the two
cutoffs specified in the pair_style command are used. Otherwise both
must be specified.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">this section</span></a> of
the manual. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">this section</span></a> of the manual for more
instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the two cutoff distances for this
pair style can be mixed. The default mix value is <em>geometric</em>. See
the “pair_modify” command for details.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>These styles are part of the COLLOID package. They are only enabled
if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Only spherical monodisperse particles are allowed for pair_style
brownian.</p>
<p>Only spherical particles are allowed for pair_style brownian/poly.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where rho is an ionic-pair dependent length parameter, and Rc is the
cutoff on both terms.</p>
<p>The styles with <em>coul/cut</em> or <em>coul/long</em> or <em>coul/msm</em> add a
Coulombic term as described for the <a class="reference internal" href="pair_lj.html"><span class="doc">lj/cut</span></a> pair styles.
For <em>buck/coul/long</em> and <em>buc/coul/msm</em>, an additional damping factor
is applied to the Coulombic term so it can be used in conjunction with
the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command and its <em>ewald</em> or <em>pppm</em>
or <em>msm</em> option. The Coulombic cutoff specified for this style means
that pairwise interactions within this distance are computed directly;
interactions outside that distance are computed in reciprocal space.</p>
<p>If one cutoff is specified for the <em>born/coul/cut</em> and
<em>born/coul/long</em> and <em>born/coul/msm</em> styles, it is used for both the
A,C and Coulombic terms. If two cutoffs are specified, the first is
used as the cutoff for the A,C terms, and the second is the cutoff for
the Coulombic term.</p>
<p>Style <em>buck/coul/long/cs</em> is identical to <em>buck/coul/long</em> except that
a term is added for the <a class="reference internal" href="Section_howto.html#howto-25"><span class="std std-ref">core/shell model</span></a>
to allow charges on core and shell particles to be separated by r =
0.0.</p>
<p>Note that these potentials are related to the <a class="reference internal" href="pair_born.html"><span class="doc">Born-Mayer-Huggins potential</span></a>.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For all these pair styles, the terms with A and C are always
cutoff. The additional Coulombic term can be cutoff or long-range (no
cutoff) depending on whether the style name includes coul/cut or
coul/long or coul/msm. If you wish the C/r^6 term to be long-range
(no cutoff), then see the <a class="reference internal" href="pair_buck_long.html"><span class="doc">pair_style buck/long/coul/long</span></a> command.</p>
</div>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<p>The second coefficient, rho, must be greater than zero.</p>
<p>The latter 2 coefficients are optional. If not specified, the global
A,C and Coulombic cutoffs are used. If only one cutoff is specified,
it is used as the cutoff for both A,C and Coulombic interactions for
this type pair. If both coefficients are specified, they are used as
the A,C and Coulombic cutoffs for this type pair. You cannot specify
2 cutoffs for style <em>buck</em>, since it has no Coulombic terms.</p>
<p>For <em>buck/coul/long</em> only the LJ cutoff can be specified since a
Coulombic cutoff cannot be specified for an individual I,J type pair.
All type pairs use the same global Coulombic cutoff specified in the
pair_style command.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>These pair styles do not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>These styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option
for the energy of the exp() and 1/r^6 portion of the pair interaction.</p>
<p>The <em>buck/coul/long</em> pair style supports the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option to tabulate the
short-range portion of the long-range Coulombic interaction.</p>
<p>These styles support the pair_modify tail option for adding long-range
tail corrections to energy and pressure for the A,C terms in the
pair interaction.</p>
<p>These styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>These styles can only be used via the <em>pair</em> keyword of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the <em>inner</em>,
<em>middle</em>, <em>outer</em> keywords.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The <em>buck/coul/long</em> style is part of the KSPACE package. The
<em>buck/coul/long/cs</em> style is part of the CORESHELL package. They are
only enabled if LAMMPS was built with that package (which it is by
default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The second coefficient, rho, must be greater than zero.</p>
<p>The latter 2 coefficients are optional. If not specified, the global
Buckingham and Coulombic cutoffs specified in the pair_style command
are used. If only one cutoff is specified, it is used as the cutoff
for both Buckingham and Coulombic interactions for this type pair. If
both coefficients are specified, they are used as the Buckingham and
Coulombic cutoffs for this type pair. Note that if you are using
<em>flag_buck</em> set to <em>long</em>, you cannot specify a Buckingham cutoff for
an atom type pair, since only one global Buckingham cutoff is allowed.
Similarly, if you are using <em>flag_coul</em> set to <em>long</em>, you cannot
specify a Coulombic cutoff for an atom type pair, since only one
global Coulombic cutoff is allowed.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the exp() and 1/r^6 portion of the pair
interaction, assuming <em>flag_buck</em> is <em>cut</em>.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the Buckingham portion of the pair
interaction.</p>
<p>This pair style supports the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table and
table/disp options since they can tabulate the short-range portion of
the long-range Coulombic and dispersion interactions.</p>
<p>This pair style write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style supports the use of the <em>inner</em>, <em>middle</em>, and <em>outer</em>
keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command, meaning the
pairwise forces can be partitioned by distance at different levels of
the rRESPA hierarchy. See the <a class="reference internal" href="run_style.html"><span class="doc">run_style</span></a> command for
details.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This style is part of the KSPACE package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info. Note that
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>style = <em>lj/charmm/coul/charmm</em> or <em>lj/charmm/coul/charmm/implicit</em> or <em>lj/charmm/coul/long</em> or <em>lj/charmm/coul/msm</em></li>
<li>args = list of arguments for a particular style</li>
<p>Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum at 2^(1/6)
sigma.</p>
<p>The latter 2 coefficients are optional. If they are specified, they
are used in the LJ formula between 2 atoms of these types which are
also first and fourth atoms in any dihedral. No cutoffs are specified
because this CHARMM force field does not allow varying cutoffs for
individual atom pairs; all pairs use the global cutoff(s) specified in
the pair_style command.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
corrections to energy and pressure, since the Lennard-Jones portion of
the pair interaction is smoothed to 0.0 at the cutoff.</p>
<p>All of the lj/charmm pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.</p>
<p>The lj/charmm/coul/long pair style supports the use of the <em>inner</em>,
<em>middle</em>, and <em>outer</em> keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a>
command, meaning the pairwise forces can be partitioned by distance at
different levels of the rRESPA hierarchy. The other styles only
support the <em>pair</em> keyword of run_style respa. See the
<a class="reference internal" href="run_style.html"><span class="doc">run_style</span></a> command for details.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The <em>lj/charmm/coul/charmm</em> and <em>lj/charmm/coul/charmm/implicit</em>
styles are part of the MOLECULE package. The <em>lj/charmm/coul/long</em>
style is part of the KSPACE package. They are only enabled if LAMMPS
was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info. Note that
the MOLECULE and KSPACE packages are installed by default.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The <em>lj/class2/coul/cut</em> and <em>lj/class2/coul/long</em> styles add a
Coulombic term as described for the <a class="reference internal" href="pair_lj.html"><span class="doc">lj/cut</span></a> pair styles.</p>
<p>See <a class="reference internal" href="#pair-sun"><span class="std std-ref">(Sun)</span></a> for a description of the COMPASS class2 force field.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<p>The latter 2 coefficients are optional. If not specified, the global
class 2 and Coulombic cutoffs are used. If only one cutoff is
specified, it is used as the cutoff for both class 2 and Coulombic
interactions for this type pair. If both coefficients are specified,
they are used as the class 2 and Coulombic cutoffs for this type pair.
You cannot specify 2 cutoffs for style <em>lj/class2</em>, since it has no
Coulombic terms.</p>
<p>For <em>lj/class2/coul/long</em> only the class 2 cutoff can be specified
since a Coulombic cutoff cannot be specified for an individual I,J
type pair. All type pairs use the same global Coulombic cutoff
specified in the pair_style command.</p>
<hr class="docutils" />
<p>If the pair_coeff command is not used to define coefficients for a
particular I != J type pair, the mixing rule for epsilon and sigma for
all class2 potentials is to use the <em>sixthpower</em> formulas documented
by the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> command. The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify mix</span></a> setting is thus ignored for class2 potentials
for epsilon and sigma. However it is still followed for mixing the
cutoff distance.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/class2 pair styles can be mixed.
Epsilon and sigma are always mixed with the value <em>sixthpower</em>. The
cutoff distance is mixed by whatever option is set by the pair_modify
command (default = geometric). See the “pair_modify” command for
details.</p>
<p>All of the lj/class2 pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option for the energy of the
Lennard-Jones portion of the pair interaction.</p>
<p>The <em>lj/class2/coul/long</em> pair style does not support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option since a tabulation
capability has not yet been added to this potential.</p>
<p>All of the lj/class2 pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> tail option for adding a long-range
tail correction to the energy and pressure of the Lennard-Jones
portion of the pair interaction.</p>
<p>All of the lj/class2 pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.</p>
<p>All of the lj/class2 pair styles can only be used via the <em>pair</em>
keyword of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not
support the <em>inner</em>, <em>middle</em>, <em>outer</em> keywords.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>These styles are part of the CLASS2 package. They are only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>with A_ss set appropriately, which results from letting both particle
sizes go to zero.</p>
<p>When used in combination with <a class="reference internal" href="#"><span class="doc">pair_style yukawa/colloid</span></a>, the two terms become the so-called
DLVO potential, which combines electrostatic repulsion and van der
Waals attraction.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>This style is part of the COLLOID package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Normally, this pair style should be used with finite-size particles
which have a diameter, e.g. see the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style sphere</span></a> command. However, this is not a requirement,
since the only definition of particle size is via the pair_coeff
parameters for each type. In other words, the physical radius of the
particle is ignored. Thus you should insure that the d1,d2 parameters
you specify are consistent with the physical size of the particles of
that type.</p>
<p>Per-particle polydispersity is not yet supported by this pair style;
only per-type polydispersity is enabled via the pair_coeff parameters.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+pair_coeff * * ../potentials/ffield.comb3 O Cu N C O
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Style <em>comb</em> computes the second-generation variable charge COMB
(Charge-Optimized Many-Body) potential. Style <em>comb3</em> computes the
third-generation COMB potential. These COMB potentials are described
in <a class="reference internal" href="#comb"><span class="std std-ref">(COMB)</span></a> and <a class="reference internal" href="#comb3"><span class="std std-ref">(COMB3)</span></a>. Briefly, the total energy
<em>E<sub>T</sub></em> of a system of atoms is given by</p>
<p>where <em>E<sub>i</sub><sup>self</sup></em> is the self-energy of atom <em>i</em>
(including atomic ionization energies and electron affinities),
<em>E<sub>ij</sub><sup>short</sup></em> is the bond-order potential between
atoms <em>i</em> and <em>j</em>,
<em>E<sub>ij</sub><sup>Coul</sup></em> is the Coulomb interactions,
<em>E<sup>polar</sup></em> is the polarization term for organic systems
(style <em>comb3</em> only),
<em>E<sup>vdW</sup></em> is the van der Waals energy (style <em>comb3</em> only),
<em>E<sup>barr</sup></em> is a charge barrier function, and
<em>E<sup>corr</sup></em> are angular correction terms.</p>
<p>The COMB potentials (styles <em>comb</em> and <em>comb3</em>) are variable charge
potentials. The equilibrium charge on each atom is calculated by the
electronegativity equalization (QEq) method. See <a class="reference internal" href="pair_smtbq.html#rick"><span class="std std-ref">Rick</span></a> for
further details. This is implemented by the <a class="reference internal" href="fix_qeq_comb.html"><span class="doc">fix qeq/comb</span></a> command, which should normally be
specified in the input script when running a model with the COMB
potential. The <a class="reference internal" href="fix_qeq_comb.html"><span class="doc">fix qeq/comb</span></a> command has options
that determine how often charge equilibration is performed, its
convergence criterion, and which atoms are included in the
calculation.</p>
<p>Only a single pair_coeff command is used with the <em>comb</em> and <em>comb3</em>
styles which specifies the COMB potential file with parameters for all
needed elements. These are mapped to LAMMPS atom types by specifying
N additional arguments after the potential file in the pair_coeff
command, where N is the number of LAMMPS atom types.</p>
<p>For example, if your LAMMPS simulation of a Si/SiO<sub>2</sub>/
HfO<sub>2</sub> interface has 4 atom types, and you want the 1st and
last to be Si, the 2nd to be Hf, and the 3rd to be O, and you would
<p>For style <em>comb3</em>, in addition to ffield.comb3, a special parameter
file, <em>lib.comb3</em>, that is exclusively used for C/O/H systems, will be
automatically loaded if carbon atom is detected in LAMMPS input
structure. This file must be in your working directory or in the
directory pointed to by the environment variable LAMMPS_POTENTIALS, as
described on the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command doc page.</p>
<p>Keyword <em>polar</em> indicates whether the force field includes
the atomic polarization. Since the equilibration of the polarization
has not yet been implemented, it can only set polar_off at present.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">You can not use potential file <em>ffield.comb</em> with style <em>comb3</em>,
nor file <em>ffield.comb3</em> with style <em>comb</em>.</p>
</div>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.</p>
<p>These pair styles does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>These pair styles do not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style, pair_coeff, and <a class="reference internal" href="fix_qeq_comb.html"><span class="doc">fix qeq/comb</span></a> commands in an input script that reads a
restart file.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where <em>alpha</em> is the damping parameter, and erc() and erfc() are
error-fuction and complementary error-function terms. This potential
is essentially a short-range, spherically-truncated,
charge-neutralized, shifted, pairwise <em>1/r</em> summation. With a
manipulation of adding and substracting a self term (for i = j) to the
first and second term on the right-hand-side, respectively, and a
small enough <em>alpha</em> damping parameter, the second term shrinks and
the potential becomes a rapidly-converging real-space summation. With
a long enough cutoff and small enough alpha parameter, the energy and
forces calcluated by the Wolf summation method approach those of the
Ewald sum. So it is a means of getting effective long-range
interactions with a short-range potential.</p>
<hr class="docutils" />
<p>Style <em>coul/streitz</em> is the Coulomb pair interaction defined as part
of the Streitz-Mintmire potential, as described in <a class="reference internal" href="#streitz"><span class="std std-ref">this paper</span></a>, in which charge distribution about an atom is modeled
as a Slater 1<em>s</em> orbital. More details can be found in the referenced
paper. To fully reproduce the published Streitz-Mintmire potential,
which is a variable charge potential, style <em>coul/streitz</em> must be
used with <a class="reference internal" href="pair_eam.html"><span class="doc">pair_style eam/alloy</span></a> (or some other
short-range potential that has been parameterized appropriately) via
the <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid/overlay</span></a> command. Likewise,
charge equilibration must be performed via the <a class="reference internal" href="fix_qeq.html"><span class="doc">fix qeq/slater</span></a> command. For example:</p>
<p>Keyword <em>ewald</em> does not need a damping parameter, but a
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> must be defined, which can be style
<em>ewald</em> or <em>pppm</em>. The Ewald method was used in Streitz and
Mintmire’s original paper, but a Wolf summation offers a speed-up in
some cases.</p>
<p>For the fix qeq/slater command, the <em>qfile</em> can be a filename that
contains QEq parameters as discussed on the <a class="reference internal" href="fix_qeq.html"><span class="doc">fix qeq</span></a>
command doc page. Alternatively <em>qfile</em> can be replaced by
“coul/streitz”, in which case the fix will extract QEq parameters from
the coul/streitz pair style itself.</p>
<p>See the examples/strietz directory for an example input script that
uses the Streitz-Mintmire potential. The potentials directory has the
AlO.eam.alloy and AlO.streitz potential files used by the example.</p>
<p>Note that the Streiz-Mintmire potential is generally used for oxides,
but there is no conceptual problem with extending it to nitrides and
carbides (such as SiC, TiN). Pair coul/strietz used by itself or with
any other pair style such as EAM, MEAM, Tersoff, or LJ in
hybrid/overlay mode. To do this, you would need to provide a
Streitz-Mintmire parameterizaion for the material being modeled.</p>
<hr class="docutils" />
<p>Styles <em>coul/long</em> and <em>coul/msm</em> compute the same Coulombic
interactions as style <em>coul/cut</em> except that an additional damping
factor is applied so it can be used in conjunction with the
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command and its <em>ewald</em> or <em>pppm</em>
option. The Coulombic cutoff specified for this style means that
pairwise interactions within this distance are computed directly;
interactions outside that distance are computed in reciprocal space.</p>
<p>Style <em>coul/long/cs</em> is identical to <em>coul/long</em> except that a term is
added for the <a class="reference internal" href="Section_howto.html#howto-25"><span class="std std-ref">core/shell model</span></a> to allow
charges on core and shell particles to be separated by r = 0.0.</p>
<p>Styles <em>tip4p/cut</em> and <em>tip4p/long</em> implement the coulomb part of
the TIP4P water model of <a class="reference internal" href="pair_lj.html#jorgensen"><span class="std std-ref">(Jorgensen)</span></a>, which introduces
a massless site located a short distance away from the oxygen atom
along the bisector of the HOH angle. The atomic types of the oxygen and
hydrogen atoms, the bond and angle types for OH and HOH interactions,
and the distance to the massless charge site are specified as
pair_style arguments. Style <em>tip4p/cut</em> uses a global cutoff for
Coulomb interactions; style <em>tip4p/long</em> is for use with a long-range
Coulombic solver (Ewald or PPPM).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For each TIP4P water molecule in your system, the atom IDs for
the O and 2 H atoms must be consecutive, with the O atom first. This
is to enable LAMMPS to “find” the 2 H atoms associated with each O
atom. For example, if the atom ID of an O atom in a TIP4P water
molecule is 500, then its 2 H atoms must have IDs 501 and 502.</p>
</div>
<p>See the <a class="reference internal" href="Section_howto.html#howto-8"><span class="std std-ref">howto section</span></a> for more
information on how to use the TIP4P pair styles and lists of
parameters to set. Note that the neighobr list cutoff for Coulomb
interactions is effectively extended by a distance 2*qdist when using
the TIP4P pair style, to account for the offset distance of the
fictitious charges on O atoms in water molecules. Thus it is
typically best in an efficiency sense to use a LJ cutoff >= Coulomb
cutoff + 2*qdist, to shrink the size of the neighbor list. This leads
to slightly larger cost for the long-range calculation, so you can
test the trade-off for your model.</p>
<hr class="docutils" />
<p>Note that these potentials are designed to be combined with other pair
potentials via the <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid/overlay</span></a>
command. This is because they have no repulsive core. Hence if they
are used by themselves, there will be no repulsion to keep two
oppositely charged particles from moving arbitrarily close to each
other.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<p>For <em>coul/cut</em> and <em>coul/debye</em>, the cutoff coefficient is optional.
If it is not used (as in some of the examples above), the default
global value specified in the pair_style command is used.</p>
<p>For <em>coul/long</em> and <em>coul/msm</em> no cutoff can be specified for an
individual I,J type pair via the pair_coeff command. All type pairs
use the same global Coulombic cutoff specified in the pair_style
command.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the cutoff distance for the
<em>coul/cut</em> style can be mixed. The default mix value is <em>geometric</em>.
See the “pair_modify” command for details.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option is not relevant
for these pair styles.</p>
<p>The <em>coul/long</em> style supports the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
table option for tabulation of the short-range portion of the
long-range Coulombic interaction.</p>
<p>These pair styles do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>These pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>The <em>coul/long</em>, <em>coul/msm</em> and <em>tip4p/long</em> styles are part of the
KSPACE package. The <em>coul/long/cs</em> style is part of the CORESHELL
package. They are only enabled if LAMMPS was built with that package
(which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where r_me is the inflection point of epsilon_D(r) and sigma_e is a slope
defining length scale. C is the same Coulomb conversion factor as in the
pair_styles coul/cut, coul/long, and coul/debye. In this way the Coulomb
interaction between ions is corrected at small distances r. The lower
limit of epsilon_D(r->0)=5.2 due to dielectric saturation <a class="reference internal" href="#stiles"><span class="std std-ref">(Stiles)</span></a>
while the Coulomb interaction reaches its bulk limit by setting
epsilon_D(r->infty)=epsilon, the bulk value of the solvent which is 78
for water at 298K.</p>
<p>Examples of the use of this type of Coulomb interaction include implicit
solvent simulations of salt ions
<a class="reference internal" href="pair_gauss.html#lenart"><span class="std std-ref">(Lenart)</span></a> and of ionic surfactants <a class="reference internal" href="pair_gauss.html#jusufi"><span class="std std-ref">(Jusufi)</span></a>.
Note that this potential is only reasonable for implicit solvent simulations
and in combiantion with coul/cut or coul/long. It is also usually combined
with gauss/cut, see <a class="reference internal" href="pair_gauss.html#lenart"><span class="std std-ref">(Lenart)</span></a> or <a class="reference internal" href="pair_gauss.html#jusufi"><span class="std std-ref">(Jusufi)</span></a>.</p>
<p>The following coefficients must be defined for each pair of atom
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the example
above, or in the data file or restart files read by the
<p>This style is part of the “user-misc” package. It is only enabled
if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-2-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>These pair styles are designed to be used with the adiabatic
core/shell model of <a class="reference internal" href="#mitchellfinchham"><span class="std std-ref">(Mitchell and Finchham)</span></a>. See
<a class="reference internal" href="Section_howto.html#howto-25"><span class="std std-ref">Section_howto 25</span></a> of the manual for an
overview of the model as implemented in LAMMPS.</p>
<p>These pair styles are identical to the <a class="reference internal" href="pair_born.html"><span class="doc">pair_style born/coul/long</span></a> and <a class="reference internal" href="pair_buck.html"><span class="doc">pair_style buck/coul/long</span></a> styles, except they correctly treat the
special case where the distance between two charged core and shell
atoms in the same core/shell pair approach r = 0.0. This needs
special treatment when a long-range solver for Coulombic interactions
is also used, i.e. via the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command.</p>
<p>More specifically, the short-range Coulomb interaction between a core
and its shell should be turned off using the
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command by setting the 1-2 weight
to 0.0, which works because the core and shell atoms are bonded to
each other. This induces a long-range correction approximation which
fails at small distances (~< 10e-8). Therefore, the Coulomb term which
is used to calculate the correction factor is extended by a minimal
distance (r_min = 1.0-6) when the interaction between a core/shell
<p>where C is an energy-conversion constant, Qi and Qj are the charges on
the core and shell, epsilon is the dielectric constant and r_min is the
minimal distance.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>These pair styles are part of the CORESHELL package. They are only
enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where qi and qj are the charges on the two particles, pi and pj are
the dipole moment vectors of the two particles, r is their separation
distance, and the vector r = Ri - Rj is the separation vector between
the two particles. Note that Eqq and Fqq are simply Coulombic energy
and force, Fij = -Fji as symmetric forces, and Tij != -Tji since the
torques do not act symmetrically. These formulas are discussed in
<a class="reference internal" href="pair_gayberne.html#allen"><span class="std std-ref">(Allen)</span></a> and in <a class="reference internal" href="#toukmaji"><span class="std std-ref">(Toukmaji)</span></a>.</p>
<p>Style <em>lj/sf/dipole/sf</em> computes “shifted-force” interactions between
pairs of particles that each have a charge and/or a point dipole
moment. In general, a shifted-force potential is a (sligthly) modified
potential containing extra terms that make both the energy and its
derivative go to zero at the cutoff distance; this removes
(cutoff-related) problems in energy conservation and any numerical
instability in the equations of motion <a class="reference internal" href="pair_gayberne.html#allen"><span class="std std-ref">(Allen)</span></a>. Shifted-force
interactions for the Lennard-Jones (E_LJ), charge-charge (Eqq),
charge-dipole (Eqp), dipole-charge (Epq) and dipole-dipole (Epp)
potentials are computed by these formulas for the energy (E), force
(F), and torque (T) between particles I and J:</p>
<p>where epsilon and sigma are the standard LJ parameters, r_c is the
cutoff, qi and qj are the charges on the two particles, pi and pj are
the dipole moment vectors of the two particles, r is their separation
distance, and the vector r = Ri - Rj is the separation vector between
the two particles. Note that Eqq and Fqq are simply Coulombic energy
and force, Fij = -Fji as symmetric forces, and Tij != -Tji since the
torques do not act symmetrically. The shifted-force formula for the
Lennard-Jones potential is reported in <a class="reference internal" href="#stoddard"><span class="std std-ref">(Stoddard)</span></a>. The
original (unshifted) formulas for the electrostatic potentials, forces
and torques can be found in <a class="reference internal" href="#price"><span class="std std-ref">(Price)</span></a>. The shifted-force
electrostatic potentials have been obtained by applying equation 5.13
of <a class="reference internal" href="pair_gayberne.html#allen"><span class="std std-ref">(Allen)</span></a>. The formulas for the corresponding forces and
torques have been obtained by applying the ‘chain rule’ as in appendix
C.3 of <a class="reference internal" href="pair_gayberne.html#allen"><span class="std std-ref">(Allen)</span></a>.</p>
<p>If one cutoff is specified in the pair_style command, it is used for
both the LJ and Coulombic (q,p) terms. If two cutoffs are specified,
they are used as cutoffs for the LJ and Coulombic (q,p) terms
interactions as discussed in <a class="reference internal" href="#toukmaji"><span class="std std-ref">(Toukmaji)</span></a>. Dipole-dipole,
dipole-charge, and charge-charge interactions are all supported, along
with the standard 12/6 Lennard-Jones interactions, which are computed
with a cutoff. A <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> must be defined to
use this pair style. Currently, only <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style ewald/disp</span></a> support long-range point-dipole
interactions.</p>
<p>Style <em>lj/long/dipole/long</em> also computes point-dipole interactions as
discussed in <a class="reference internal" href="#toukmaji"><span class="std std-ref">(Toukmaji)</span></a>. Long-range dipole-dipole,
dipole-charge, and charge-charge interactions are all supported, along
with the standard 12/6 Lennard-Jones interactions. LJ interactions
can be cutoff or long-ranged.</p>
<p>For style <em>lj/long/dipole/long</em>, if <em>flag_lj</em> is set to <em>long</em>, no
cutoff is used on the LJ 1/r^6 dispersion term. The long-range
portion is calculated by using the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style ewald_disp</span></a> command. The specified LJ cutoff then
determines which portion of the LJ interactions are computed directly
by the pair potential versus which part is computed in reciprocal
space via the Kspace style. If <em>flag_lj</em> is set to <em>cut</em>, the LJ
interactions are simply cutoff, as with <a class="reference internal" href="pair_lj.html"><span class="doc">pair_style lj/cut</span></a>. If <em>flag_lj</em> is set to <em>off</em>, LJ interactions
are not computed at all.</p>
<p>If <em>flag_coul</em> is set to <em>long</em>, no cutoff is used on the Coulombic or
dipole interactions. The long-range portion is calculated by using
<em>ewald_disp</em> of the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command. If
<em>flag_coul</em> is set to <em>off</em>, Coulombic and dipole interactions are not
computed at all.</p>
<p>Atoms with dipole moments should be integrated using the <a class="reference internal" href="fix_nve_sphere.html"><span class="doc">fix nve/sphere update dipole</span></a> or the <a class="reference internal" href="fix_nvt_sphere.html"><span class="doc">fix nvt/sphere update dipole</span></a> command to rotate the
dipole moments. The <em>omega</em> option on the <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> command can be used to thermostat the
rotational motion. The <a class="reference internal" href="compute_temp_sphere.html"><span class="doc">compute temp/sphere</span></a>
command can be used to monitor the temperature, since it includes
rotational degrees of freedom. The <a class="reference internal" href="atom_style.html"><span class="doc">atom_style hybrid dipole sphere</span></a> command should be used since
it defines the point dipoles and their rotational state.
The magnitude and orientation of the dipole moment for each particle
can be defined by the <a class="reference internal" href="set.html"><span class="doc">set</span></a> command or in the “Atoms” section
of the data file read in by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<p>The latter 2 coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distances for this pair style can be mixed. The default
mix value is <em>geometric</em>. See the “pair_modify” command for details.</p>
<p>For atom type pairs I,J and I != J, the A, sigma, d1, and d2
coefficients and cutoff distance for this pair style can be mixed. A
is an energy value mixed like a LJ epsilon. D1 and d2 are distance
values and are mixed like sigma. The default mix value is
<em>geometric</em>. See the “pair_modify” command for details.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the Lennard-Jones portion of the pair
interaction; such energy goes to zero at the cutoff by construction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>The <em>lj/cut/dipole/cut</em>, <em>lj/cut/dipole/long</em>, and
<em>lj/long/dipole/long</em> styles are part of the DIPOLE package. They are
only enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The <em>lj/sf/dipole/sf</em> style is part of the USER-MISC package. It is
only enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Using dipole pair styles with <em>electron</em> <a class="reference internal" href="units.html"><span class="doc">units</span></a> is not
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Style <em>dpd</em> computes a force field for dissipative particle dynamics
(DPD) following the exposition in <a class="reference internal" href="#groot"><span class="std std-ref">(Groot)</span></a>.</p>
<p>Style <em>dpd/tstat</em> invokes a DPD thermostat on pairwise interactions,
which is equivalent to the non-conservative portion of the DPD force
field. This pair-wise thermostat can be used in conjunction with any
<a class="reference internal" href="pair_style.html"><span class="doc">pair style</span></a>, and in leiu of per-particle thermostats
like <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> or ensemble thermostats like
Nose Hoover as implemented by <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>. To use
<em>dpd/tstat</em> as a thermostat for another pair style, use the <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid/overlay</span></a> command to compute both the desired
pair interaction and the thermostat for each pair of particles.</p>
<p>For style <em>dpd</em>, the force on atom I due to atom J is given as a sum
<p>The last coefficient is optional. If not specified, the global DPD
cutoff is used. Note that sigma is set equal to sqrt(2 T gamma),
where T is the temperature set by the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a>
command so it does not need to be specified.</p>
<p>For style <em>dpd/tstat</em>, the coefficiencts defined for each pair of
atoms types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command is the same,
except that A is not included.</p>
<p>The GPU-accelerated versions of these styles are implemented based on
the work of <a class="reference internal" href="#afshar"><span class="std std-ref">(Afshar)</span></a> and <a class="reference internal" href="#phillips"><span class="std std-ref">(Phillips)</span></a>.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you are modeling DPD polymer chains, you may want to use the
<a class="reference internal" href="pair_srp.html"><span class="doc">pair_style srp</span></a> command in conjuction with these pair
styles. It is a soft segmental repulsive potential (SRP) that can
prevent DPD polymer chains from crossing each other.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The virial calculation for pressure when using this pair style
includes all the components of force listed above, including the
random force.</p>
</div>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>These pair styles do not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>These pair styles do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the pair interaction. Note that as
discussed above, the energy due to the conservative Fc term is already
shifted to be 0.0 at the cutoff distance Rc.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for these pair styles.</p>
<p>These pair style do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>These pair styles writes their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file. Note
that the user-specified random number seed is stored in the restart
file, so when a simulation is restarted, each processor will
re-initialize its random number generator the same way it did
initially. This means the random forces will be random, but will not
be the same as they would have been if the original simulation had
continued past the restart time.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
<p>The <em>dpd/tstat</em> style can ramp its target temperature over multiple
runs, using the <em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a>
command. See the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do
this.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The default frequency for rebuilding neighbor lists is every 10 steps
(see the <a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify</span></a> command). This may be too
infrequent for style <em>dpd</em> simulations since particles move rapidly
and can overlap by large amounts. If this setting yields a non-zero
number of “dangerous” reneighborings (printed at the end of a
simulation), you should experiment with forcing reneighboring more
often and see if system energies/trajectories change.</p>
<p>These pair styles requires you to use the <a class="reference internal" href="comm_modify.html"><span class="doc">comm_modify vel yes</span></a> command so that velocites are stored by ghost
atoms.</p>
<p>These pair styles will not restart exactly when using the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command, though they should provide
statistically similar results. This is because the forces they
compute depend on atom velocities. See the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for more details.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where Rij is a unit vector in the direction Ri - Rj, and Rc is the
cutoff. Note that alternative definitions of the weighting function
exist, but would have to be implemented as a separate pair style
command.</p>
<p>These pair style differ from the other dpd styles in that the
dissipative and random forces are not computed within the pair style.
This style can be combined with the <a class="reference internal" href="fix_shardlow.html"><span class="doc">fix shardlow</span></a>
to perform the stochastic integration of the dissipative and random
forces through the Shardlow splitting algorithm approach.</p>
<p>The pairwise energy associated with styles <em>dpd/fdt</em> and
<em>dpd/fdt/energy</em> is only due to the conservative force term Fc, and is
shifted to be zero at the cutoff distance Rc. The pairwise virial is
calculated using only the conservative term.</p>
<p>For style <em>dpd/fdt</em>, the fluctuation-dissipation theorem defines gamma
to be set equal to sigma*sigma/(2 T), where T is the set point
temperature specified as a pair style parameter in the above examples.
This style can be combined with <a class="reference internal" href="fix_shardlow.html"><span class="doc">fix shardlow</span></a> to
perform DPD simulations under isothermal and isobaric conditions (see
<a class="reference internal" href="#lisal"><span class="std std-ref">(Lisal)</span></a>). The following coefficients must be defined for
each pair of atoms types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command
as in the examples above, or in the data file or restart files read by
the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
commands:</p>
<ul class="simple">
<li>A (force units)</li>
<li>sigma (force*time^(1/2) units)</li>
<li>cutoff (distance units)</li>
</ul>
<p>The last coefficient is optional. If not specified, the global DPD
cutoff is used.</p>
<p>For style <em>dpd/fdt/energy</em>, the fluctuation-dissipation theorem
defines gamma to be set equal to sigma*sigma/(2 dpdTheta), where
dpdTheta is the average internal temperature for the pair.
Furthermore, the fluctuation-dissipation defines alpha*alpha to be set
equal to 2*kB*kappa, where kappa is the mesoparticle thermal
conductivity parameter. This style can be combined with <a class="reference internal" href="fix_shardlow.html"><span class="doc">fix shardlow</span></a> to perform DPD simulations under
isoenergetic and isoenthalpic conditions (see <a class="reference internal" href="#lisal"><span class="std std-ref">(Lisal)</span></a>). The
following coefficients must be defined for each pair of atoms types
via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples above,
<p>The last coefficient is optional. If not specified, the global DPD
cutoff is used.</p>
<p>For style <em>dpd/fdt/energy</em>, the particle internal temperature is
related to the particle internal energy through a mesoparticle
equation of state. Thus, an an additional <a class="reference internal" href="fix.html"><span class="doc">fix eos</span></a> must be
specified.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>These commands are part of the USER-DPD package. They are only
enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Pair styles <em>dpd/fdt</em> and <em>dpd/fdt/energy</em> require use of the
<a class="reference internal" href="comm_modify.html"><span class="doc">comm_modify vel yes</span></a> option so that velocites are
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This pair style does not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file. Note
that the user-specified random number seed is stored in the restart
file, so when a simulation is restarted, each processor will
re-initialize its random number generator the same way it did
initially. This means the random forces will be random, but will not
be the same as they would have been if the original simulation had
continued past the restart time.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>This style is part of the MC package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+pair_coeff * * ../potentials/NiAlH_jea.eam.alloy Ni Al Ni Ni
+</pre>
+<pre class="literal-block">
+pair_style eam/cd
+pair_coeff * * ../potentials/FeCr.cdeam Fe Cr
+</pre>
+<pre class="literal-block">
+pair_style eam/fs
+pair_coeff * * NiAlH_jea.eam.fs Ni Al Ni Ni
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Style <em>eam</em> computes pairwise interactions for metals and metal alloys
using embedded-atom method (EAM) potentials <a class="reference internal" href="pair_polymorphic.html#daw"><span class="std std-ref">(Daw)</span></a>. The total
<li>density function rho(r) for element I at element 1 (Nr values)</li>
<li>density function rho(r) for element I at element 2</li>
<li>...</li>
<li>density function rho(r) for element I at element Nelement</li>
</ul>
<p>The units of these quantities in line 1 are the same as for <em>setfl</em>
files. Note that the rho(r) arrays in Finnis/Sinclair can be
asymmetric (i,j != j,i) so there are Nelements^2 of them listed in the
file.</p>
<p>Following the Nelements sections, Nr values for each pair potential
phi(r) array are listed in the same manner (r*phi, units of
eV-Angstroms) as in EAM <em>setfl</em> files. Note that in Finnis/Sinclair,
the phi(r) arrays are still symmetric, so only phi arrays for i >= j
are listed.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accerlate</span></a> of the manual for more
instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above with the individual styles. You never need to specify
a pair_coeff command with I != J arguments for the eam styles.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>The eam pair styles do not write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in tabulated potential files.
Thus, you need to re-specify the pair_style and pair_coeff commands in
an input script that reads a restart file.</p>
<p>The eam pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
<p>All of these styles except the <em>eam/cd</em> style are part of the MANYBODY
package. They are only enabled if LAMMPS was built with that package
(which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The <em>eam/cd</em> style is part of the USER-MISC package and also requires
the MANYBODY package. It is only enabled if LAMMPS was built with
those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
specify EDIP parameters for all permutations of the two elements
interacting in three-body configurations. Thus for 3 elements, 27
entries would be required, etc.</p>
<p>At the moment, only a single element parametrization is
implemented. However, the author is not aware of other
multi-element EDIP parametrizations. If you know any and
you are interest in that, please contact the author of
the EDIP package.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The overall electrostatics energy is given in Hartree units of energy
by default and can be modified by an energy-conversion constant,
according to the units chosen (see <a class="reference internal" href="units.html"><span class="doc">electron_units</span></a>). The
cutoff Rc, given in Bohrs (by default), truncates the interaction
distance. The recommended cutoff for this pair style should follow
the minimum image criterion, i.e. half of the minimum unit cell
length.</p>
<p>Style <em>eff/long</em> (not yet available) computes the same interactions as
style <em>eff/cut</em> except that an additional damping factor is applied so
it can be used in conjunction with the
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command and its <em>ewald</em> or <em>pppm</em>
option. The Coulombic cutoff specified for this style means that
pairwise interactions within this distance are computed directly;
interactions outside that distance are computed in reciprocal space.</p>
<p>This potential is designed to be used with <a class="reference internal" href="atom_style.html"><span class="doc">atom_style electron</span></a> definitions, in order to handle the
description of systems with interacting nuclei and explicit electrons.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<p>For atom type pairs I,J and I != J, the cutoff distance for the
<em>eff/cut</em> style can be mixed. The default mix value is <em>geometric</em>.
See the “pair_modify” command for details.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option is not relevant for
these pair styles.</p>
<p>The <em>eff/long</em> (not yet available) style supports the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option for tabulation of the
short-range portion of the long-range Coulombic interaction.</p>
<p>These pair styles do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>These pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
<p>These pair styles will only be enabled if LAMMPS is built with the
USER-EFF package. It will only be enabled if LAMMPS was built with
that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
section for more info.</p>
<p>These pair styles require that particles store electron attributes
such as radius, radial velocity, and radital force, as defined by the
<a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a>. The <em>electron</em> atom style does all of
this.</p>
<p>Thes pair styles require you to use the <a class="reference internal" href="comm_modify.html"><span class="doc">comm_modify vel yes</span></a> command so that velocites are stored by ghost
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The lines in the file can be in any order; LAMMPS extracts the info it
needs.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This style is part of the MANYBODY package. It is only enabled if
LAMMPS was built with that package (which it is by default).</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where the <em>epsilon</em> parameter determines the depth of the potential
minimum located at <em>Rm</em>, and <em>alpha</em> determines the softness of the repulsion.</p>
<p>The coefficients must be defined for each species in a given particle
type via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, where the first argument is the filename that includes the
exponential-6 parameters for each species. The file includes the
species tag followed by the <em>alpha</em>, <em>epsilon</em> and <em>Rm</em>
parameters. The format of the file is described below.</p>
<p>The second and third arguments specify the site-site interaction
potential between two species contained within two different
particles. The species tags must either correspond to the species
defined in the reaction kinetics files specified with the <a class="reference internal" href="fix_rx.html"><span class="doc">fix rx</span></a> command or they must correspond to the tag “1fluid”,
signifying interaction with a product species mixture determined
through a one-fluid approximation. The interaction potential is
weighted by the geometric average of the concentrations of the two
species. The coarse-grained potential is stored before and after the
reaction kinetics solver is applied, where the difference is defined
to be the internal chemical energy (uChem).</p>
<p>The fourth and fifth arguments specify the <em>Rm</em> and <em>epsilon</em> scaling exponents.</p>
<p>The final argument specifies the interaction cutoff.</p>
<hr class="docutils" />
<p>The format of a tabulated file is as follows (without the
parenthesized comments):</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># exponential-6 parameters for various species (one or more comment or blank lines)</span>
<p>This pair style does not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>This style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option
for the energy of the exp() and 1/r^6 portion of the pair interaction.</p>
<p>This style does not support the pair_modify tail option for adding long-range
tail corrections to energy and pressure for the A,C terms in the
pair interaction.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This command is part of the USER-DPD package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The global cutoff (r_c) specified in the pair_style command is used.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the “-suffix command-line
switch7_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the Gauss-potential portion of the pair
interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table and tail options are not
relevant for these pair styles.</p>
<p>These pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
<p>The <em>gauss</em> pair style tallies an “occupancy” count of how many Gaussian-well
sites have an atom within the distance at which the force is a maximum
= sqrt(0.5/b). This quantity can be accessed via the <a class="reference internal" href="compute_pair.html"><span class="doc">compute pair</span></a> command as a vector of values of length 1.</p>
<p>To print this quantity to the log file (with a descriptive column
heading) the following commands could be included in an input script:</p>
<p>The <em>gauss/cut</em> style is part of the “user-misc” package. It is only
enabled if LAMMPS is build with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making of LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The variable names utilized as potential parameters are for the most
part taken from <a class="reference internal" href="pair_resquared.html#everaers"><span class="std std-ref">(Everaers)</span></a> in order to be consistent with
the <a class="reference internal" href="pair_resquared.html"><span class="doc">RE-squared pair potential</span></a>. Details on the
<p>More details of the Gay-Berne formulation are given in the references
listed below and in <a class="reference external" href="PDF/pair_gayberne_extra.pdf">this supplementary document</a>.</p>
<p>Use of this pair style requires the NVE, NVT, or NPT fixes with the
<em>asphere</em> extension (e.g. <a class="reference internal" href="fix_nve_asphere.html"><span class="doc">fix nve/asphere</span></a>) in
order to integrate particle rotation. Additionally, <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a> should be used since it defines the
rotational state and the size and shape of each ellipsoidal particle.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<li>epsilon_i_a = relative well depth of type I for side-to-side interactions</li>
<li>epsilon_i_b = relative well depth of type I for face-to-face interactions</li>
<li>epsilon_i_c = relative well depth of type I for end-to-end interactions</li>
<li>epsilon_j_a = relative well depth of type J for side-to-side interactions</li>
<li>epsilon_j_b = relative well depth of type J for face-to-face interactions</li>
<li>epsilon_j_c = relative well depth of type J for end-to-end interactions</li>
<li>cutoff (distance units)</li>
</ul>
<p>The last coefficient is optional. If not specified, the global
cutoff specified in the pair_style command is used.</p>
<p>It is typical with the Gay-Berne potential to define <em>sigma</em> as the
minimum of the 3 shape diameters of the particles involved in an I,I
interaction, though this is not required. Note that this is a
different meaning for <em>sigma</em> than the <a class="reference internal" href="pair_resquared.html"><span class="doc">pair_style resquared</span></a> potential uses.</p>
<p>The epsilon_i and epsilon_j coefficients are actually defined for atom
types, not for pairs of atom types. Thus, in a series of pair_coeff
commands, they only need to be specified once for each atom type.</p>
<p>Specifically, if any of epsilon_i_a, epsilon_i_b, epsilon_i_c are
non-zero, the three values are assigned to atom type I. If all the
epsilon_i values are zero, they are ignored. If any of epsilon_j_a,
epsilon_j_b, epsilon_j_c are non-zero, the three values are assigned
to atom type J. If all three epsilon_j values are zero, they are
ignored. Thus the typical way to define the epsilon_i and epsilon_j
coefficients is to list their values in “pair_coeff I J” commands when
I = J, but set them to 0.0 when I != J. If you do list them when I !=
J, you should insure they are consistent with their values in other
pair_coeff commands, since only the last setting will be in effect.</p>
<p>Note that if this potential is being used as a sub-style of
<a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid</span></a>, and there is no “pair_coeff I I”
setting made for Gay-Berne for a particular type I (because I-I
interactions are computed by another hybrid pair potential), then you
still need to insure the epsilon a,b,c coefficients are assigned to
that type. e.g. in a “pair_coeff I J” command.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If the epsilon a = b = c for an atom type, and if the shape of
the particle itself is spherical, meaning its 3 shape parameters are
all the same, then the particle is treated as an LJ sphere by the
Gay-Berne potential. This is significant because if two LJ spheres
interact, then the simple Lennard-Jones formula is used to compute
their interaction energy/force using the specified epsilon and sigma
as the standard LJ parameters. This is much cheaper to compute than
the full Gay-Berne formula. To treat the particle as a LJ sphere with
sigma = D, you should normally set epsilon a = b = c = 1.0, set the
pair_coeff sigma = D, and also set the 3 shape parameters for the
particle to D. The one exception is that if the 3 shape parameters
are set to 0.0, which is a valid way in LAMMPS to specify a point
particle, then the Gay-Berne potential will treat that as shape
parameters of 1.0 (i.e. a LJ particle with sigma = 1), since it
requires finite-size particles. In this case you should still set the
pair_coeff sigma to 1.0 as well.</p>
</div>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the Lennard-Jones portion of the pair
interaction, but only for sphere-sphere interactions. There is no
shifting performed for ellipsoidal interactions due to the anisotropic
dependence of the interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>The <em>gayberne</em> style is part of the ASPHERE package. It is only
enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>These pair style require that atoms store torque and a quaternion to
represent their orientation, as defined by the
<a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a>. It also require they store a per-type
<a class="reference internal" href="set.html"><span class="doc">shape</span></a>. The particles cannot store a per-particle
diameter.</p>
<p>This pair style requires that atoms be ellipsoids as defined by the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>should be used if all atoms in the simulation interact via a granular
potential (i.e. one of the pair styles above is used). If a granular
potential is used as a sub-style of <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid</span></a>, then specific atom types can be used in the
pair_coeff command to determine which atoms interact via a granular
potential.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>These pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so a pair_style command does not need to be
specified in an input script that reads a restart file.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
<p>The single() function of these pair styles returns 0.0 for the energy
of a pairwise interaction, since energy is not conserved in these
dissipative potentials. It also returns only the normal component of
the pairwise interaction force. However, the single() function also
calculates 10 extra pairwise quantities. The first 3 are the
components of the tangential force between particles I and J, acting
on particle I. The 4th is the magnitude of this tangential force.
The next 3 (5-7) are the components of the relative velocity in the
normal direction (along the line joining the 2 sphere centers). The
last 3 (8-10) the components of the relative velocity in the
tangential direction.</p>
<p>These extra quantites can be accessed by the <a class="reference internal" href="compute_pair_local.html"><span class="doc">compute pair/local</span></a> command, as <em>p1</em>, <em>p2</em>, ...,
<em>p10</em>.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>All the granular pair styles are part of the GRANULAR package. It is
only enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>These pair styles require that atoms store torque and angular velocity
(omega) as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a>. They also
require a per-particle radius is stored. The <em>sphere</em> atom style does
all of this.</p>
<p>This pair style requires you to use the <a class="reference internal" href="comm_modify.html"><span class="doc">comm_modify vel yes</span></a> command so that velocites are stored by ghost
atoms.</p>
<p>These pair styles will not restart exactly when using the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command, though they should provide
statistically similar results. This is because the forces they
compute depend on atom velocities. See the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for more details.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum at 2^(1/6)
sigma.</p>
<p>The last 2 coefficients are optional inner and outer cutoffs for style
<em>lj/gromacs</em>. If not specified, the global <em>inner</em> and <em>outer</em> values
are used.</p>
<p>The last 2 coefficients cannot be used with style
<em>lj/gromacs/coul/gromacs</em> because this force field does not allow
varying cutoffs for individual atom pairs; all pairs use the global
cutoff(s) specified in the pair_style command.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
corrections to energy and pressure, since there are no corrections for
a potential that goes to 0.0 at the cutoff.</p>
<p>All of the GROMACS pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.</p>
<p>All of the GROMACS pair styles can only be used via the <em>pair</em>
keyword of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not
support the <em>inner</em>, <em>middle</em>, <em>outer</em> keywords.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>These 3-body interactions can be defined for pairs of acceptor and
donor atoms, based on atom types. For each donor/acceptor atom pair,
the 3rd atom in the interaction is a hydrogen permanently bonded to
the donor atom, e.g. in a bond list read in from a data file via the
<a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command. The atom types of possible
hydrogen atoms for each donor/acceptor type pair are specified by the
<a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command (see below).</p>
<p>Style <em>hbond/dreiding/lj</em> is the original DREIDING potential of
<a class="reference internal" href="#pair-mayo"><span class="std std-ref">(Mayo)</span></a>. It uses a LJ 12/10 functional for the Donor-Acceptor
interactions. To match the results in the original paper, use n = 4.</p>
<p>Style <em>hbond/dreiding/morse</em> is an improved version using a Morse
potential for the Donor-Acceptor interactions. <a class="reference internal" href="#liu"><span class="std std-ref">(Liu)</span></a> showed
that the Morse form gives improved results for Dendrimer simulations,
when n = 2.</p>
<p>See this <a class="reference internal" href="Section_howto.html#howto-4"><span class="std std-ref">howto section</span></a> of the manual for
more information on the DREIDING forcefield.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Because the Dreiding hydrogen bond potential is only one portion
of an overall force field which typically includes other pairwise
interactions, it is common to use it as a sub-style in a <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid/overlay</span></a> command, where another pair style
provides the repulsive core interaction between pairs of atoms, e.g. a
1/r^12 Lennard-Jones repulsion.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When using the hbond/dreiding pair styles with <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid/overlay</span></a>, you should explicitly define pair
interactions between the donor atom and acceptor atoms, (as well as
between these atoms and ALL other atoms in your system). Whenever
<a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid/overlay</span></a> is used, ordinary mixing
rules are not applied to atoms like the donor and acceptor atoms
because they are typically referenced in multiple pair styles.
Neglecting to do this can cause difficult-to-detect physics problems.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">In the original Dreiding force field paper 1-4 non-bonded
interactions ARE allowed. If this is desired for your model, use the
special_bonds command (e.g. “special_bonds lj 0.0 0.0 1.0”) to turn
these interactions on.</p>
</div>
<hr class="docutils" />
<p>The following coefficients must be defined for pairs of eligible
donor/acceptor types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as
in the examples above.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Unlike other pair styles and their associated
<a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> commands, you do not need to specify
pair_coeff settings for all possible I,J type pairs. Only I,J type
pairs for atoms which act as joint donors/acceptors need to be
specified; all other type pairs are assumed to be inactive.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">A <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command can be speficied multiple
times for the same donor/acceptor type pair. This enables multiple
hydrogen types to be assigned to the same donor/acceptor type pair.
For other pair_styles, if the pair_coeff command is re-used for the
same I.J type pair, the settings for that type pair are overwritten.
For the hydrogen bond potentials this is not the case; the settings
are cummulative. This means the only way to turn off a previous
setting, is to re-use the pair_style command and start over.</p>
</div>
<p>For the <em>hbond/dreiding/lj</em> style the list of coefficients is as
follows:</p>
<ul class="simple">
<li>K = hydrogen atom type = 1 to Ntypes</li>
<li>donor flag = <em>i</em> or <em>j</em></li>
<li>epsilon (energy units)</li>
<li>sigma (distance units)</li>
<li>n = exponent in formula above</li>
<li>distance cutoff Rin (distance units)</li>
<li>distance cutoff Rout (distance units)</li>
<li>angle cutoff (degrees)</li>
</ul>
<p>For the <em>hbond/dreiding/morse</em> style the list of coefficients is as
follows:</p>
<ul class="simple">
<li>K = hydrogen atom type = 1 to Ntypes</li>
<li>donor flag = <em>i</em> or <em>j</em></li>
<li>D0 (energy units)</li>
<li>alpha (1/distance units)</li>
<li>r0 (distance units)</li>
<li>n = exponent in formula above</li>
<li>distance cutoff Rin (distance units)</li>
<li>distance cutoff Rout (distance units)</li>
<li>angle cutoff (degrees)</li>
</ul>
<p>A single hydrogen atom type K can be specified, or a wild-card
asterisk can be used in place of or in conjunction with the K
arguments to select multiple types as hydrogens. This takes the form
-“*” or “<em>n” or “n</em>” or “m*n”. See the <a class="reference external" href="pair_coeff">pair_coeff</a> command
+“*” or “*n” or “n*” or “m*n”. See the <a class="reference external" href="pair_coeff">pair_coeff</a> command
doc page for details.</p>
<p>If the donor flag is <em>i</em>, then the atom of type I in the pair_coeff
command is treated as the donor, and J is the acceptor. If the donor
flag is <em>j</em>, then the atom of type J in the pair_coeff command is
treated as the donor and I is the donor. This option is required
because the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command requires that I <= J.</p>
<p>Epsilon and sigma are settings for the hydrogen bond potential based
on a Lennard-Jones functional form. Note that sigma is defined as the
zero-crossing distance for the potential, not as the energy minimum at
2^(1/6) sigma.</p>
<p>D0 and alpha and r0 are settings for the hydrogen bond potential based
on a Morse functional form.</p>
<p>The last 3 coefficients for both styles are optional. If not
specified, the global n, distance cutoff, and angle cutoff specified
in the pair_style command are used. If you wish to only override the
2nd or 3rd optional parameter, you must also specify the preceding
optional parameters.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>These pair styles do not support mixing. You must explicitly identify
each donor/acceptor type pair.</p>
<p>These styles do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift
option for the energy of the interactions.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant for
these pair styles.</p>
<p>These pair styles do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>These pair styles do not write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands need to be
re-specified in an input script that reads a restart file.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>If an assignment to <em>none</em> is made in a simulation with the
<em>hybrid/overlay</em> pair style, it wipes out all previous assignments of
that atom type pair to sub-styles.</p>
<p>Note that you may need to use an <a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a> hybrid
command in your input script, if atoms in the simulation will need
attributes from several atom styles, due to using multiple pair
potentials.</p>
<hr class="docutils" />
<p>Different force fields (e.g. CHARMM vs AMBER) may have different rules
for applying weightings that change the strength of pairwise
interactions bewteen pairs of atoms that are also 1-2, 1-3, and 1-4
neighbors in the molecular bond topology, as normally set by the
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command. Different weights can be
assigned to different pair hybrid sub-styles via the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify special</span></a> command. This allows multiple force fields
to be used in a model of a hybrid system, however, there is no consistent
approach to determine parameters automatically for the interactions
between the two force fields, this is only recommended when particles
described by the different force fields do not mix.</p>
<p>Here is an example for mixing CHARMM and AMBER: The global <em>amber</em>
setting sets the 1-4 interactions to non-zero scaling factors and
+pair_modify pair tersoff special lj/coul 1.0 1.0 1.0
+</pre>
<p>See the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> doc page for details on
the specific syntax, requirements and restrictions.</p>
<hr class="docutils" />
<p>The potential energy contribution to the overall system due to an
individual sub-style can be accessed and output via the <a class="reference internal" href="compute_pair.html"><span class="doc">compute pair</span></a> command.</p>
<hr class="docutils" />
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Several of the potentials defined via the pair_style command in
LAMMPS are really many-body potentials, such as Tersoff, AIREBO, MEAM,
ReaxFF, etc. The way to think about using these potentials in a
hybrid setting is as follows.</p>
</div>
<p>A subset of atom types is assigned to the many-body potential with a
-single <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command, using “* <a href="#id1"><span class="problematic" id="id2">*</span></a>” to include
+single <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command, using “* *” to include
all types and the NULL keywords described above to exclude specific
types not assigned to that potential. If types 1,3,4 were assigned in
that way (but not type 2), this means that all many-body interactions
between all atoms of types 1,3,4 will be computed by that potential.
Pair_style hybrid allows interactions between type pairs 2-2, 1-2,
2-3, 2-4 to be specified for computation by other pair styles. You
could even add a second interaction for 1-1 to be computed by another
pair style, assuming pair_style hybrid/overlay is used.</p>
<p>But you should not, as a general rule, attempt to exclude the
many-body interactions for some subset of the type pairs within the
set of 1,3,4 interactions, e.g. exclude 1-1 or 1-3 interactions. That
is not conceptually well-defined for many-body interactions, since the
potential will typically calculate energies and foces for small groups
of atoms, e.g. 3 or 4 atoms, using the neighbor lists of the atoms to
find the additional atoms in the group. It is typically non-physical
to think of excluding an interaction between a particular pair of
atoms when the potential computes 3-body or 4-body interactions.</p>
<p>However, you can still use the pair_coeff none setting or the
<a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify exclude</span></a> command to exclude certain
type pairs from the neighbor list that will be passed to a manybody
sub-style. This will alter the calculations made by a many-body
potential, since it builds its list of 3-body, 4-body, etc
interactions from the pair list. You will need to think carefully as
to whether it produces a physically meaningful result for your model.</p>
<p>For example, imagine you have two atom types in your model, type 1 for
atoms in one surface, and type 2 for atoms in the other, and you wish
to use a Tersoff potential to compute interactions within each
surface, but not between surfaces. Then either of these two command
<p>Note that to prevent the Tersoff potential from computing C/C
interactions, you would need to modify the SiC.tersoff file to turn
off C/C interaction, i.e. by setting the appropriate coefficients to
0.0.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual.</p>
<p>Since the <em>hybrid</em> and <em>hybrid/overlay</em> styles delegate computation to
the individual sub-styles, the suffix versions of the <em>hybrid</em> and
<em>hybrid/overlay</em> styles are used to propagate the corresponding suffix
to all sub-styles, if those versions exist. Otherwise the
non-accelerated version will be used.</p>
<p>The individual accelerated sub-styles are part of the GPU,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the
<a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
shift, table, and tail options for an I,J pair interaction, if the
associated sub-style supports it.</p>
<p>For the hybrid pair styles, the list of sub-styles and their
respective settings are written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so a <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> command does
not need to specified in an input script that reads a restart file.
However, the coefficient information is not stored in the restart
file. Thus, pair_coeff commands need to be re-specified in the
restart input script.</p>
<p>These pair styles support the use of the <em>inner</em>, <em>middle</em>, and
<em>outer</em> keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command, if
their sub-styles do.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>When using a long-range Coulombic solver (via the
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command) with a hybrid pair_style,
one or more sub-styles will be of the “long” variety,
e.g. <em>lj/cut/coul/long</em> or <em>buck/coul/long</em>. You must insure that the
short-range Coulombic cutoff used by each of these long pair styles is
the same or else LAMMPS will generate an error.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Style <em>line/lj</em> treats particles which are line segments as a set of
small spherical particles that tile the line segment length as
explained below. Interactions between two line segments, each with N1
and N2 spherical particles, are calculated as the pairwise sum of
N1*N2 Lennard-Jones interactions. Interactions between a line segment
with N spherical particles and a point particle are treated as the
pairwise sum of N Lennard-Jones interactions. See the <a class="reference internal" href="pair_lj.html"><span class="doc">pair_style lj/cut</span></a> doc page for the definition of Lennard-Jones
interactions.</p>
<p>The set of non-overlapping spherical sub-particles that represent a
line segment are generated in the following manner. Their size is a
function of the line segment length and the specified sub-particle
size for that particle type. If a line segment has a length L and is
of type I, then the number of spheres N that represent the segment is
calculated as N = L/sizeI, rounded up to an integer value. Thus if L
is not evenly divisibly by sizeI, N is incremented to include one
extra sphere. The centers of the spheres are spaced equally along the
line segment. Imagine N+1 equally-space points, which include the 2
end points of the segment. The sphere centers are halfway between
each pair of points.</p>
<p>The LJ interaction between 2 spheres on different line segments (or a
sphere on a line segment and a point particles) is computed with
sub-particle epsilon, sigma, and cutoff values that are set by the
pair_coeff command, as described below. If the distance bewteen the 2
spheres is greater than the sub-particle cutoff, there is no
interaction. This means that some pairs of sub-particles on 2 line
segments may interact, but others may not.</p>
<p>For purposes of creating the neighbor list for pairs of interacting
line segments or lines/point particles, a regular particle-particle
cutoff is used, as defined by the <em>cutoff</em> setting above in the
pair_style command or overridden with an optional argument in the
pair_coeff command for a type pair as discussed below. The distance
between the centers of 2 line segments, or the center of a line
segment and a point particle, must be less than this distance (plus
the neighbor skin; see the <a class="reference external" href="neighbor">neighbor</a> command), for the pair
of particles to be included in the neighbor list.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">This means that a too-short value for the <em>cutoff</em> setting can
exclude a pair of particles from the neighbor list even if pairs of
their sub-particle spheres would interact, based on the sub-particle
cutoff specified in the pair_coeff command. E.g. sub-particles at the
ends of the line segments that are close to each other. Which may not
be what you want, since it means the ends of 2 line segments could
pass through each other. It is up to you to specify a <em>cutoff</em>
setting that is consistent with the length of the line segments you
are using and the sub-particle cutoff settings.</p>
</div>
<p>For style <em>line/lj</em>, the following coefficients must be defined for
each pair of atom types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command
as in the examples above, or in the data file or restart files read by
the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
commands:</p>
<ul class="simple">
<li>sizeI (distance units)</li>
<li>sizeJ (distance units)</li>
<li>epsilon (energy units)</li>
<li>sigma (distance units)</li>
<li>subcutoff (distance units)</li>
<li>cutoff (distance units)</li>
</ul>
<p>The <em>sizeI</em> and <em>sizeJ</em> coefficients are the sub-particle sizes for
line particles of type I and type J. They are used to define the N
sub-particles per segment as described above. These coefficients are
actually stored on a per-type basis. Thus if there are multiple
pair_coeff commmands that involve type I, as either the first or
second atom type, you should use consistent values for sizeI or sizeJ
in all of them. If you do not do this, the last value specified for
sizeI will apply to all segments of type I. If typeI or typeJ refers
to point particles, the corresponding sizeI or sizeJ is ignored; it
can be set to 0.0.</p>
<p>The <em>epsilon</em>, <em>sigma</em>, and <em>subcutoff</em> coefficients are used to
compute an LJ interactions between a pair of sub-particles on 2 line
segments (of type I and J), or between a sub particle/point particle
pair. As discussed above, the <em>subcutoff</em> and <em>cutoff</em> params are
different. The latter is only used for building the neighbor list
when the distance between centers of two line segments or one segment
and a point particle is calculated.</p>
<p>The <em>cutoff</em> coefficient is optional. If not specified, the global
<p>For atom type pairs I,J and I != J, coeffiecients must be specified.
No default mixing rules are used.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>This style is part of the ASPHERE package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Defining particles to be line segments so they participate in
line/line or line/particle interactions requires the use the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This pair style does not support mixing since all parameters are
explicit for each pair.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option is supported by this
pair style.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table and tail options are not
relevant for this pair style.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>This pair style does not use a neighbor list and instead identifies
atoms by their IDs. This has two consequences: 1) The cutoff has to be
chosen sufficiently large, so that the second atom of a pair has to be
a ghost atom on the same node on which the first atom is local;
otherwise the interaction will be skipped. You can use the <em>check</em>
option to detect, if interactions are missing. 2) Unlike other pair
styles in LAMMPS, an atom I will not interact with multiple images of
atom J (assuming the images are within the cutoff distance), but only
with the nearest image.</p>
<p>This style is part of the USER-MISC package. It is only enabled if
LAMMPS is build with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making of LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>style = <em>lj/cut</em> or <em>lj/cut/coul/cut</em> or <em>lj/cut/coul/debye</em> or <em>lj/cut/coul/dsf</em> or <em>lj/cut/coul/long</em> or <em>lj/cut/coul/long/cs</em> or <em>lj/cut/coul/msm</em> or <em>lj/cut/tip4p/long</em></li>
<li>args = list of arguments for a particular style</li>
</ul>
<pre class="literal-block">
<em>lj/cut</em> args = cutoff
cutoff = global cutoff for Lennard Jones interactions (distance units)
<em>lj/cut/coul/cut</em> args = cutoff (cutoff2)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
summation. The potential is based on Wolf summation, proposed as an
alternative to Ewald summation for condensed phase systems where
charge screening causes electrostatic interactions to become
effectively short-ranged. In order for the electrostatic sum to be
absolutely convergent, charge neutralization within the cutoff radius
is enforced by shifting the potential through placement of image
charges on the cutoff sphere. Convergence can often be improved by
setting <em>alpha</em> to a small non-zero value.</p>
<p>Styles <em>lj/cut/coul/long</em> and <em>lj/cut/coul/msm</em> compute the same
Coulombic interactions as style <em>lj/cut/coul/cut</em> except that an
additional damping factor is applied to the Coulombic term so it can
be used in conjunction with the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a>
command and its <em>ewald</em> or <em>pppm</em> option. The Coulombic cutoff
specified for this style means that pairwise interactions within this
distance are computed directly; interactions outside that distance are
computed in reciprocal space.</p>
<p>Style <em>lj/cut/coul/long/cs</em> is identical to <em>lj/cut/coul/long</em> except
that a term is added for the <a class="reference internal" href="Section_howto.html#howto-25"><span class="std std-ref">core/shell model</span></a> to allow charges on core and shell
particles to be separated by r = 0.0.</p>
<p>Styles <em>lj/cut/tip4p/cut</em> and <em>lj/cut/tip4p/long</em> implement the TIP4P
water model of <a class="reference internal" href="#jorgensen"><span class="std std-ref">(Jorgensen)</span></a>, which introduces a massless
site located a short distance away from the oxygen atom along the
bisector of the HOH angle. The atomic types of the oxygen and
hydrogen atoms, the bond and angle types for OH and HOH interactions,
and the distance to the massless charge site are specified as
pair_style arguments. Style <em>lj/cut/tip4p/cut</em> uses a cutoff for
Coulomb interactions; style <em>lj/cut/tip4p/long</em> is for use with a
long-range Coulombic solver (Ewald or PPPM).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For each TIP4P water molecule in your system, the atom IDs for
the O and 2 H atoms must be consecutive, with the O atom first. This
is to enable LAMMPS to “find” the 2 H atoms associated with each O
atom. For example, if the atom ID of an O atom in a TIP4P water
molecule is 500, then its 2 H atoms must have IDs 501 and 502.</p>
</div>
<p>See the <a class="reference internal" href="Section_howto.html#howto-8"><span class="std std-ref">howto section</span></a> for more
information on how to use the TIP4P pair styles and lists of
parameters to set. Note that the neighobr list cutoff for Coulomb
interactions is effectively extended by a distance 2*qdist when using
the TIP4P pair style, to account for the offset distance of the
fictitious charges on O atoms in water molecules. Thus it is
typically best in an efficiency sense to use a LJ cutoff >= Coulomb
cutoff + 2*qdist, to shrink the size of the neighbor list. This leads
to slightly larger cost for the long-range calculation, so you can
test the trade-off for your model.</p>
<p>For all of the <em>lj/cut</em> pair styles, the following coefficients must
be defined for each pair of atoms types via the
<a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands, or by mixing as
described below:</p>
<ul class="simple">
<li>epsilon (energy units)</li>
<li>sigma (distance units)</li>
<li>cutoff1 (distance units)</li>
<li>cutoff2 (distance units)</li>
</ul>
<p>Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum at 2^(1/6)
sigma.</p>
<p>The latter 2 coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair. You cannot specify 2 cutoffs for style <em>lj/cut</em>, since it
has no Coulombic terms.</p>
<p>For <em>lj/cut/coul/long</em> and <em>lj/cut/coul/msm</em> and <em>lj/cut/tip4p/cut</em>
and <em>lj/cut/tip4p/long</em> only the LJ cutoff can be specified since a
Coulombic cutoff cannot be specified for an individual I,J type pair.
All type pairs use the same global Coulombic cutoff specified in the
pair_style command.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/cut pair styles can be mixed.
The default mix value is <em>geometric</em>. See the “pair_modify” command
for details.</p>
<p>All of the <em>lj/cut</em> pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option for the energy of the
Lennard-Jones portion of the pair interaction.</p>
<p>The <em>lj/cut/coul/long</em> and <em>lj/cut/tip4p/long</em> pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option since they can tabulate
the short-range portion of the long-range Coulombic interaction.</p>
<p>All of the <em>lj/cut</em> pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> tail option for adding a long-range
tail correction to the energy and pressure for the Lennard-Jones
portion of the pair interaction.</p>
<p>All of the <em>lj/cut</em> pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.</p>
<p>The <em>lj/cut</em> and <em>lj/cut/coul/long</em> pair styles support the use of the
<em>inner</em>, <em>middle</em>, and <em>outer</em> keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command, meaning the pairwise forces can be
partitioned by distance at different levels of the rRESPA hierarchy.
The other styles only support the <em>pair</em> keyword of run_style respa.
See the <a class="reference internal" href="run_style.html"><span class="doc">run_style</span></a> command for details.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The <em>lj/cut/coul/long</em> and <em>lj/cut/tip4p/long</em> styles are part of the
KSPACE package. The <em>lj/cut/tip4p/cut</em> style is part of the MOLECULE
package. These styles are only enabled if LAMMPS was built with those
packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
for more info. Note that the KSPACE and MOLECULE packages are
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The last coefficient is optional. If not specified, the global LJ
cutoff specified in the pair_style command is used.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for adding a long-range tail correction to the energy and
pressure of the pair interaction.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style supports the use of the <em>inner</em>, <em>middle</em>, and <em>outer</em>
keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command, meaning the
pairwise forces can be partitioned by distance at different levels of
the rRESPA hierarchy. See the <a class="reference internal" href="run_style.html"><span class="doc">run_style</span></a> command for
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum, which is
located at rmin = 2^(1/6)*sigma. In the above example, sigma =
0.8908987, so rmin = 1.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
corrections to energy and pressure, since there are no corrections for
a potential that goes to 0.0 at the cutoff.</p>
<p>The lj/cubic pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.</p>
<p>The lj/cubic pair style can only be used via the <em>pair</em>
keyword of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not
support the <em>inner</em>, <em>middle</em>, <em>outer</em> keywords.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The delta values can be positive or negative. The last coefficient is
optional. If not specified, the global LJ cutoff is used.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for adding a long-range tail correction to the energy and
pressure of the pair interaction.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where C is an energy-conversion constant, Qi and Qj are the charges on
the 2 atoms, epsilon is the dielectric constant which can be set by
the <a class="reference internal" href="dielectric.html"><span class="doc">dielectric</span></a> command, and Rc is the cutoff. If
one cutoff is specified in the pair_style command, it is used for both
the LJ and Coulombic terms. If two cutoffs are specified, they are
used as cutoffs for the LJ and Coulombic terms respectively.</p>
<p>The purpose of this pair style is to capture long-range interactions
resulting from both attractive 1/r^6 Lennard-Jones and Coulombic 1/r
interactions. This is done by use of the <em>flag_lj</em> and <em>flag_coul</em>
settings. The <a class="reference internal" href="#veld"><span class="std std-ref">In ‘t Veld</span></a> paper has more details on when it is
appropriate to include long-range 1/r^6 interactions, using this
potential.</p>
<p>Style <em>lj/long/tip4p/long</em> implements the TIP4P water model of
<a class="reference internal" href="pair_lj.html#jorgensen"><span class="std std-ref">(Jorgensen)</span></a>, which introduces a massless site located a
short distance away from the oxygen atom along the bisector of the HOH
angle. The atomic types of the oxygen and hydrogen atoms, the bond
and angle types for OH and HOH interactions, and the distance to the
massless charge site are specified as pair_style arguments.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For each TIP4P water molecule in your system, the atom IDs for
the O and 2 H atoms must be consecutive, with the O atom first. This
is to enable LAMMPS to “find” the 2 H atoms associated with each O
atom. For example, if the atom ID of an O atom in a TIP4P water
molecule is 500, then its 2 H atoms must have IDs 501 and 502.</p>
</div>
<p>See the <a class="reference internal" href="Section_howto.html#howto-8"><span class="std std-ref">howto section</span></a> for more
information on how to use the TIP4P pair style. Note that the
neighobr list cutoff for Coulomb interactions is effectively extended
by a distance 2*qdist when using the TIP4P pair style, to account for
the offset distance of the fictitious charges on O atoms in water
molecules. Thus it is typically best in an efficiency sense to use a
LJ cutoff >= Coulomb cutoff + 2*qdist, to shrink the size of the
neighbor list. This leads to slightly larger cost for the long-range
calculation, so you can test the trade-off for your model.</p>
<p>If <em>flag_lj</em> is set to <em>long</em>, no cutoff is used on the LJ 1/r^6
dispersion term. The long-range portion can be calculated by using
the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style ewald/disp or pppm/disp</span></a> commands.
The specified LJ cutoff then determines which portion of the LJ
interactions are computed directly by the pair potential versus which
part is computed in reciprocal space via the Kspace style. If
<em>flag_lj</em> is set to <em>cut</em>, the LJ interactions are simply cutoff, as
with <a class="reference internal" href="pair_lj.html"><span class="doc">pair_style lj/cut</span></a>.</p>
<p>If <em>flag_coul</em> is set to <em>long</em>, no cutoff is used on the Coulombic
interactions. The long-range portion can calculated by using any of
several <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command options such as
<em>pppm</em> or <em>ewald</em>. Note that if <em>flag_lj</em> is also set to long, then
the <em>ewald/disp</em> or <em>pppm/disp</em> Kspace style needs to be used to
perform the long-range calculations for both the LJ and Coulombic
interactions. If <em>flag_coul</em> is set to <em>off</em>, Coulombic interactions
are not computed.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<p>Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum at 2^(1/6)
sigma.</p>
<p>The latter 2 coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair.</p>
<p>Note that if you are using <em>flag_lj</em> set to <em>long</em>, you
cannot specify a LJ cutoff for an atom type pair, since only one
global LJ cutoff is allowed. Similarly, if you are using <em>flag_coul</em>
set to <em>long</em>, you cannot specify a Coulombic cutoff for an atom type
pair, since only one global Coulombic cutoff is allowed.</p>
<p>For <em>lj/long/tip4p/long</em> only the LJ cutoff can be specified
since a Coulombic cutoff cannot be specified for an individual I,J
type pair. All type pairs use the same global Coulombic cutoff
specified in the pair_style command.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/long pair styles can be mixed.
The default mix value is <em>geometric</em>. See the “pair_modify” command
for details.</p>
<p>These pair styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift
option for the energy of the Lennard-Jones portion of the pair
interaction, assuming <em>flag_lj</em> is <em>cut</em>.</p>
<p>These pair styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table and
table/disp options since they can tabulate the short-range portion of
the long-range Coulombic and dispersion interactions.</p>
<p>Thes pair styles do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding a long-range tail correction to the
Lennard-Jones portion of the energy and pressure.</p>
<p>These pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>The pair lj/long/coul/long styles support the use of the <em>inner</em>,
<em>middle</em>, and <em>outer</em> keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a>
command, meaning the pairwise forces can be partitioned by distance at
different levels of the rRESPA hierarchy. See the
<a class="reference internal" href="run_style.html"><span class="doc">run_style</span></a> command for details.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>These styles are part of the KSPACE package. They are only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info. Note that
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The last coefficient is optional. If not specified, the global
LJ cutoff specified in the pair_style command is used.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma
coefficients and cutoff distance for this pair style can be mixed.
Rin is a cutoff value and is mixed like the cutoff. The
default mix value is <em>geometric</em>. See the “pair_modify” command for
details.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option is not relevant for
this pair style, since the pair interaction goes to 0.0 at the cutoff.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure, since the energy of the pair interaction is smoothed to 0.0
at the cutoff.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>This pair style is part of the USER-MISC package. It is only enabled
if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The last 2 coefficients are optional inner and outer cutoffs. If not
specified, the global values for Rin and Rc are used.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure, since the energy of the pair interaction is smoothed to 0.0
at the cutoff.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The last coefficient is optional. If not specified, the global value
for Rc is used.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance can be mixed. The default mix value is geometric.
See the “pair_modify” command for details.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant for
this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure, since the energy of the pair interaction is smoothed to 0.0
at the cutoff.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>style = <em>lj/cut/soft</em> or <em>lj/cut/coul/cut/soft</em> or <em>lj/cut/coul/long/soft</em> or <em>lj/cut/tip4p/long/soft</em> or <em>lj/charmm/coul/long/soft</em> or <em>coul/cut/soft</em> or <em>coul/long/soft</em> or <em>tip4p/long/soft</em></li>
<li>args = list of arguments for a particular style</li>
</ul>
<pre class="literal-block">
<em>lj/cut/soft</em> args = n alpha_lj cutoff
n, alpha_LJ = parameters of soft-core potential
cutoff = global cutoff for Lennard-Jones interactions (distance units)
<em>lj/cut/coul/cut/soft</em> args = n alpha_LJ alpha_C cutoff (cutoff2)
n, alpha_LJ, alpha_C = parameters of soft-core potential
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
<em>lj/cut/coul/long/soft</em> args = n alpha_LJ alpha_C cutoff
n, alpha_LJ, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
<li>lambda (activation parameter between 0 and 1)</li>
<li>cutoff1 (distance units)</li>
<li>cutoff2 (distance units)</li>
</ul>
<p>The latter two coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair. You cannot specify 2 cutoffs for style <em>lj/cut/soft</em>,
since it has no Coulombic terms. For the <em>coul/cut/soft</em> and
<em>coul/long/soft</em> only lambda and the optional cutoff2 are to be
specified.</p>
<p>Style <em>lj/cut/tip4p/long/soft</em> implements a soft-core version of the
TIP4P water model. The usage of this pair style is documented in the
<a class="reference internal" href="pair_lj.html"><span class="doc">pair_lj</span></a> styles. The soft-core version introduces the
lambda parameter to the list of arguments, after epsilon and sigma in
the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command. The paratemers n, alpha_LJ
and alpha_C are set in the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> command,
before the cutoffs.</p>
<p>Style <em>lj/charmm/coul/long/soft</em> implements a soft-core version of the
CHARMM version of LJ interactions with an additional switching
function S(r) that ramps the energy and force smoothly to zero between
an inner and outer cutoff. The usage of this pair style is documented
in the <a class="reference internal" href="pair_charmm.html"><span class="doc">pair_charmm</span></a> styles. The soft-core version
introduces the lambda parameter to the list of arguments, after
epsilon and sigma in the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command (and
before the optional eps14 and sigma14). The paratemers n,
alpha_LJ and alpha_C are set in the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a>
command, before the cutoffs.</p>
<p>The <em>coul/cut/soft</em>, <em>coul/long/soft</em> and <em>tip4p/long/soft</em> substyles
are designed to be combined with other pair potentials via the
<a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid/overlay</span></a> command. This is because
they have no repulsive core. Hence, if used by themselves, there will
be no repulsion to keep two oppositely charged particles from
overlapping each other. In this case, if lambda = 1, a singularity may
occur. These substyles are suitable to represent charges embedded in
the Lennard-Jones radius of another site (for example hydrogen atoms
in several water models).</p>
<p>NOTES: When using the core-softed Coulomb potentials with long-range
solvers (<em>coul/long/soft</em>, <em>lj/cut/coul/long/soft</em>, etc.) in a free
energy calculation in which sites holding electrostatic charges are
being created or anihilated (using <a class="reference internal" href="fix_adapt_fep.html"><span class="doc">fix adapt/fep</span></a>
and <a class="reference internal" href="compute_fep.html"><span class="doc">compute fep</span></a>) it is important to adapt both the
lambda activation parameter (from 0 to 1, or the reverse) and the
value of the charge (from 0 to its final value, or the reverse). This
ensures that long-range electrostatic terms (kspace) are correct. It
is not necessary to use core-softed Coulomb potentials if the van der
Waals site is present during the free-energy route, thus avoiding
overlap of the charges. Examples are provided in the LAMMPS source
directory tree, under examples/USER/fep.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for this pair style can be mixed.
The default mix value is <em>geometric</em>. See the “pair_modify” command
for details.</p>
<p>These pair styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift
option for the energy of the Lennard-Jones portion of the pair
interaction.</p>
<p>These pair styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> tail
option for adding a long-range tail correction to the energy and
pressure for the Lennard-Jones portion of the pair interaction.</p>
<p>These pair styles write information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>To avoid division by zero do not set sigma = 0; use the lambda
parameter instead to activate/deactivate interactions, or use
epsilon = 0 and sigma = 1. Alternatively, when sites do not
interact though the Lennard-Jones term the <em>coul/long/soft</em> or
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Styles <em>lubricate</em> and <em>lubricate/poly</em> compute hydrodynamic
interactions between mono-disperse finite-size spherical particles in
a pairwise fashion. The interactions have 2 components. The first is
Ball-Melrose lubrication terms via the formulas in <a class="reference internal" href="pair_lubricateU.html#ball"><span class="std std-ref">(Ball and Melrose)</span></a></p>
<p>where U represents the velocities and angular velocities of the
particles, U^<em>infty</em> represents the velocity and the angular velocity
of the undisturbed fluid, and E^<em>infty</em> represents the rate of strain
tensor of the undisturbed fluid with viscosity <em>mu</em>. Again, note that
this is dynamic viscosity which has units of mass/distance/time, not
kinematic viscosity. Volume fraction corrections to R_FU are included
as long as <em>flagVF</em> is set to 1 (default).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When using the FLD terms, these pair styles are designed to be
used with explicit time integration and a correspondingly small
timestep. Thus either <a class="reference internal" href="fix_nve_sphere.html"><span class="doc">fix nve/sphere</span></a> or <a class="reference internal" href="fix_nve_asphere.html"><span class="doc">fix nve/asphere</span></a> should be used for time integration.
To perform implicit FLD, see the <a class="reference internal" href="pair_lubricateU.html"><span class="doc">pair_style lubricateU</span></a> command.</p>
<p>The two coefficients are optional. If neither is specified, the two
cutoffs specified in the pair_style command are used. Otherwise both
must be specified.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">this section</span></a> of
the manual. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">this section</span></a> of the manual for more
instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the two cutoff distances for this
pair style can be mixed. The default mix value is <em>geometric</em>. See
the “pair_modify” command for details.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>These styles are part of the COLLOID package. They are only enabled
if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-2-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Only spherical monodisperse particles are allowed for pair_style
lubricate.</p>
<p>Only spherical particles are allowed for pair_style lubricate/poly.</p>
<p>These pair styles will not restart exactly when using the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command, though they should provide
statistically similar results. This is because the forces they
compute depend on atom velocities. See the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for more details.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Styles <em>lubricateU</em> and <em>lubricateU/poly</em> compute velocities and
angular velocities for finite-size spherical particles such that the
hydrodynamic interaction balances the force and torque due to all
other types of interactions.</p>
<p>The interactions have 2 components. The first is
Ball-Melrose lubrication terms via the formulas in <a class="reference internal" href="#ball"><span class="std std-ref">(Ball and Melrose)</span></a></p>
<p>where U represents the velocities and angular velocities of the
particles, U^<em>infty</em> represents the velocities and the angular
velocities of the undisturbed fluid, and E^<em>infty</em> represents the rate
of strain tensor of the undisturbed fluid flow with viscosity
<em>mu</em>. Again, note that this is dynamic viscosity which has units of
mass/distance/time, not kinematic viscosity. Volume fraction
corrections to R_FU are included if <em>flagVF</em> is set to 1 (default).</p>
<p>F<em>rest</em> represents the forces and torques due to all other types of
interactions, e.g. Brownian, electrostatic etc. Note that this
algorithm neglects the inertial terms, thereby removing the
restriction of resolving the small interial time scale, which may not
be of interest for colloidal particles. This pair style solves for
the velocity such that the hydrodynamic force balances all other types
of forces, thereby resulting in a net zero force (zero inertia limit).
When defining this pair style, it must be defined last so that when
this style is invoked all other types of forces have already been
computed. For the same reason, it won’t work if additional non-pair
styles are defined (such as bond or Kspace forces) as they are
calculated in LAMMPS after the pairwise interactions have been
computed.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When using these styles, the these pair styles are designed to
be used with implicit time integration and a correspondingly larger
timestep. Thus either <a class="reference internal" href="fix_nve_noforce.html"><span class="doc">fix nve/noforce</span></a> should
be used for spherical particles defined via <a class="reference internal" href="atom_style.html"><span class="doc">atom_style sphere</span></a> or <a class="reference internal" href="fix_nve_asphere_noforce.html"><span class="doc">fix nve/asphere/noforce</span></a> should be used for
spherical particles defined via <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a>. This is because the velocity and angular
momentum of each particle is set by the pair style, and should not be
<p>For atom type pairs I,J and I != J, the two cutoff distances for this
pair style can be mixed. The default mix value is <em>geometric</em>. See
the “pair_modify” command for details.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>These styles are part of the COLLOID package. They are only enabled
if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-2-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Currently, these pair styles assume that all other types of
forces/torques on the particles have been already been computed when
it is invoked. This requires this style to be defined as the last of
the pair styles, and that no fixes apply additional constraint forces.
One exception is the <a class="reference internal" href="fix_wall.html"><span class="doc">fix wall/colloid</span></a> commands, which
has an “fld” option to apply their wall forces correctly.</p>
<p>Only spherical monodisperse particles are allowed for pair_style
lubricateU.</p>
<p>Only spherical particles are allowed for pair_style lubricateU/poly.</p>
<p>For sheared suspensions, it is assumed that the shearing is done in
the xy plane, with x being the velocity direction and y being the
velocity-gradient direction. In this case, one must use <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> with the same rate of shear (erate).</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/cut pair styles can be mixed.
The default mix value is <em>geometric</em>. See the “pair_modify” command
for details.</p>
<p>All of the <em>lj/cut</em> pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option for the energy of the
Lennard-Jones portion of the pair interaction.</p>
<p>The <em>lj/cut/coul/long</em> and <em>lj/cut/tip4p/long</em> pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option since they can tabulate
the short-range portion of the long-range Coulombic interaction.</p>
<p>All of the <em>lj/cut</em> pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> tail option for adding a long-range
tail correction to the energy and pressure for the Lennard-Jones
portion of the pair interaction.</p>
<p>All of the <em>lj/cut</em> pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.</p>
<p>The <em>lj/cut</em> and <em>lj/cut/coul/long</em> pair styles support the use of the
<em>inner</em>, <em>middle</em>, and <em>outer</em> keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command, meaning the pairwise forces can be
partitioned by distance at different levels of the rRESPA hierarchy.
The other styles only support the <em>pair</em> keyword of run_style respa.
See the <a class="reference internal" href="run_style.html"><span class="doc">run_style</span></a> command for details.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>These pair styles can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>set rho0 for the 2nd element to the value 2.25 and set alpha for the
alloy interaction between elements 1 and 2 to 4.37.</p>
<p>The augt1 parameter is related to modifications in the MEAM
formulation of the partial electron density function. In recent
literature, an extra term is included in the expression for the
third-order density in order to make the densities orthogonal (see for
example <a class="reference internal" href="pair_polymorphic.html#wang"><span class="std std-ref">(Wang)</span></a>, equation 3d); this term is included in the
MEAM implementation in lammps. However, in earlier published work
this term was not included when deriving parameters, including most of
those provided in the library.meam file included with lammps, and to
account for this difference the parameter t1 must be augmented by
3/5*t3. If augt1=1, the default, this augmentation is done
automatically. When parameter values are fit using the modified
density function, as in more recent literature, augt1 should be set to
0.</p>
<p>The mixture_ref_t parameter is available to match results with those
of previous versions of lammps (before January 2011). Newer versions
of lammps, by default, use the single-element values of the t
parameters to compute the background reference density. This is the
proper way to compute these parameters. Earlier versions of lammps
used an alloy mixture averaged value of t to compute the background
reference density. Setting mixture_ref_t=1 gives the old behavior.
WARNING: using mixture_ref_t=1 will give results that are demonstrably
incorrect for second-neighbor MEAM, and non-standard for
first-neighbor MEAM; this option is included only for matching with
previous versions of lammps and should be avoided if possible.</p>
<p>The parameters attrac and repuls, along with the integer selection
parameter erose_form, can be used to modify the Rose energy function
used to compute the pair potential. This function gives the energy of
the reference state as a function of interatomic spacing. The form of
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS with
user-specifiable parameters as described above. You never need to
specify a pair_coeff command with I != J arguments for this style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>This style is part of the MEAM package. It is only enabled if LAMMPS
was built with that package, which also requires the MEAM library be
built and linked with LAMMPS. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The <em>meam/spline</em> style computes pairwise interactions for metals
using a variant of modified embedded-atom method (MEAM) potentials
<a class="reference internal" href="pair_meam_sw_spline.html#lenosky"><span class="std std-ref">(Lenosky)</span></a>. The total energy E is given by</p>
<p>The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The three Ti arguments map LAMMPS atom types 1,2,3 to the Ti element
in the potential file. If a mapping value is specified as NULL, the
mapping is not performed. This can be used when a <em>meam/spline</em>
potential is used as part of the <em>hybrid</em> pair style. The NULL values
are placeholders for atom types that will be used with other
potentials.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The <em>meam/spline</em> style currently supports only single-element
MEAM potentials. It may be extended for alloy systems in the future.</p>
</div>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>The current version of this pair style does not support multiple
element types or mixing. It has been designed for pure elements only.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>The <em>meam/spline</em> pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in an external
potential parameter file. Thus, you need to re-specify the pair_style
and pair_coeff commands in an input script that reads a restart file.</p>
<p>The <em>meam/spline</em> pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The <em>meam/sw/spline</em> style computes pairwise interactions for metals
using a variant of modified embedded-atom method (MEAM) potentials
<a class="reference internal" href="#lenosky"><span class="std std-ref">(Lenosky)</span></a> with an additional Stillinger-Weber (SW) term
<a class="reference internal" href="pair_sw.html#stillinger"><span class="std std-ref">(Stillinger)</span></a> in the energy. This form of the potential
was first proposed by Nicklas, Fellinger, and Park
<a class="reference internal" href="#nicklas"><span class="std std-ref">(Nicklas)</span></a>. We refer to it as MEAM+SW. The total energy E
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
mix, shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
needs to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>This pair style is part of the USER-MGPT package and is only enabled
if LAMMPS is built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The MGPT potentials require the <a class="reference internal" href="newton.html"><span class="doc">newtion</span></a> setting to be
“on” for pair style interactions.</p>
<p>The stored parmin and potin potential files provided with LAMMPS in
the “potentials” directory are written in Rydberg atomic units, with
energies in Rydbergs and distances in Bohr radii. The <em>mgpt</em> pair
style converts Rydbergs to Hartrees to make the potential files
compatible with LAMMPS electron <a class="reference internal" href="units.html"><span class="doc">units</span></a>.</p>
<p>The form of E_tot used in the <em>mgpt</em> pair style is only appropriate
for elemental bulk solids and liquids. This includes solids with
point and extended defects such as vacancies, interstitials, grain
boundaries and dislocations. Alloys and free surfaces, however,
require significant modifications, which are not included in the
<em>mgpt</em> pair style. Likewise, the <em>hybrid</em> pair style is not allowed,
where MGPT would be used for some atoms but not for others.</p>
<p>Electron-thermal effects are not included in the standard MGPT
potentials provided in the “potentials” directory, where the
potentials have been constructed at zero electron temperature.
Physically, electron-thermal effects may be important in 3d (e.g., V)
and 4d (e.g., Mo) transition metals at high temperatures near melt and
above. It is expected that temperature-dependent MGPT potentials for
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
option for adding a long-range tail correction to the energy and
pressure of the pair interaction.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style supports the use of the <em>inner</em>, <em>middle</em>, and <em>outer</em>
keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command, meaning the
pairwise forces can be partitioned by distance at different levels of
the rRESPA hierarchy. See the <a class="reference internal" href="run_style.html"><span class="doc">run_style</span></a> command for
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>one or more keyword/value pairs may be listed</li>
<li>keyword = <em>pair</em> or <em>shift</em> or <em>mix</em> or <em>table</em> or <em>table/disp</em> or <em>tabinner</em> or <em>tabinner/disp</em> or <em>tail</em> or <em>compute</em></li>
</ul>
<pre class="literal-block">
<em>pair</em> values = sub-style N <em>special</em> which wt1 wt2 wt3
sub-style = sub-style of <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair hybrid</span></a>
N = which instance of sub-style (only if sub-style is used multiple times)
<em>special</em> which wt1 wt2 wt3 = override <em>special_bonds</em> settings (optional)
which = <em>lj/coul</em> or <em>lj</em> or <em>coul</em>
w1,w2,w3 = 1-2, 1-3, and 1-4 weights from 0.0 to 1.0 inclusive
<em>mix</em> value = <em>geometric</em> or <em>arithmetic</em> or <em>sixthpower</em>
<em>shift</em> value = <em>yes</em> or <em>no</em>
<em>table</em> value = N
2^N = # of values in table
<em>table/disp</em> value = N
2^N = # of values in table
<em>tabinner</em> value = cutoff
cutoff = inner cutoff at which to begin table (distance units)
<em>tabinner/disp</em> value = cutoff
cutoff = inner cutoff at which to begin table (distance units)
<em>tail</em> value = <em>yes</em> or <em>no</em>
<em>compute</em> value = <em>yes</em> or <em>no</em>
+pair_modify pair lj/cut/coul/long 1 special lj/coul 0.0 0.0 0.0
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Modify the parameters of the currently defined pair style. Not all
parameters are relevant to all pair styles.</p>
<p>If used, the <em>pair</em> keyword must appear first in the list of keywords.
It can only be used with the <a class="reference internal" href="pair_hybrid.html"><span class="doc">hybrid and hybrid/overlay</span></a> pair styles. It means that all the
following parameters will only be modified for the specified
sub-style. If the sub-style is defined multiple times, then an
additional numeric argument <em>N</em> must also be specified, which is a
number from 1 to M where M is the number of times the sub-style was
listed in the <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid</span></a> command. The extra
number indicates which instance of the sub-style the remaining
keywords will be applied to. Note that if the <em>pair</em> keyword is not
used, and the pair style is <em>hybrid</em> or <em>hybrid/overlay</em>, then all the
specified keywords will be applied to all sub-styles.</p>
<p>The <em>special</em> keyword can only be used in conjunction with the <em>pair</em>
keyword and must directly follow it. It allows to override the
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> settings for the specified sub-style.
More details are given below.</p>
<p>The <em>mix</em> keyword affects pair coefficients for interactions between
atoms of type I and J, when I != J and the coefficients are not
explicitly set in the input script. Note that coefficients for I = J
must be set explicitly, either in the input script via the
“pair_coeff” command or in the “Pair Coeffs” section of the <a class="reference internal" href="read_data.html"><span class="doc">data file</span></a>. For some pair styles it is not necessary to
specify coefficients when I != J, since a “mixing” rule will create
them from the I,I and J,J settings. The pair_modify <em>mix</em> value
determines what formulas are used to compute the mixed coefficients.
In each case, the cutoff distance is mixed the same way as sigma.</p>
<p>Note that not all pair styles support mixing. Also, some mix options
are not available for certain pair styles. See the doc page for
individual pair styles for those restrictions. Note also that the
<a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command also can be to directly set
coefficients for a specific I != J pairing, in which case no mixing is
<p>The <em>shift</em> keyword determines whether a Lennard-Jones potential is
shifted at its cutoff to 0.0. If so, this adds an energy term to each
pairwise interaction which will be included in the thermodynamic
output, but does not affect pair forces or atom trajectories. See the
doc page for individual pair styles to see which ones support this
option.</p>
<p>The <em>table</em> and <em>table/disp</em> keywords apply to pair styles with a
long-range Coulombic term or long-range dispersion term respectively;
see the doc page for individual styles to see which potentials support
these options. If N is non-zero, a table of length 2^N is
pre-computed for forces and energies, which can shrink their
computational cost by up to a factor of 2. The table is indexed via a
bit-mapping technique <a class="reference internal" href="pair_table_rx.html#wolff"><span class="std std-ref">(Wolff)</span></a> and a linear interpolation is
performed between adjacent table values. In our experiments with
different table styles (lookup, linear, spline), this method typically
gave the best performance in terms of speed and accuracy.</p>
<p>The choice of table length is a tradeoff in accuracy versus speed. A
larger N yields more accurate force computations, but requires more
memory which can slow down the computation due to cache misses. A
reasonable value of N is between 8 and 16. The default value of 12
(table of length 4096) gives approximately the same accuracy as the
no-table (N = 0) option. For N = 0, forces and energies are computed
directly, using a polynomial fit for the needed erfc() function
evaluation, which is what earlier versions of LAMMPS did. Values
greater than 16 typically slow down the simulation and will not
improve accuracy; values from 1 to 8 give unreliable results.</p>
<p>The <em>tabinner</em> and <em>tabinner/disp</em> keywords set an inner cutoff above
which the pairwise computation is done by table lookup (if tables are
invoked), for the corresponding Coulombic and dispersion tables
discussed with the <em>table</em> and <em>table/disp</em> keywords. The smaller the
cutoff is set, the less accurate the table becomes (for a given number
of table values), which can require use of larger tables. The default
cutoff value is sqrt(2.0) distance units which means nearly all
pairwise interactions are computed via table lookup for simulations
with “real” units, but some close pairs may be computed directly
(non-table) for simulations with “lj” units.</p>
<p>When the <em>tail</em> keyword is set to <em>yes</em>, certain pair styles will add
a long-range VanderWaals tail “correction” to the energy and pressure.
These corrections are bookkeeping terms which do not affect dynamics,
unless a constant-pressure simulation is being performed. See the doc
page for individual styles to see which support this option. These
corrections are included in the calculation and printing of
thermodynamic quantities (see the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a>
command). Their effect will also be included in constant NPT or NPH
simulations where the pressure influences the simulation box
dimensions (e.g. the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> and <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a>
commands). The formulas used for the long-range corrections come from
equation 5 of <a class="reference internal" href="#sun"><span class="std std-ref">(Sun)</span></a>.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The tail correction terms are computed at the beginning of each
run, using the current atom counts of each atom type. If atoms are
deleted (or lost) or created during a simulation, e.g. via the <a class="reference internal" href="fix_gcmc.html"><span class="doc">fix gcmc</span></a> command, the correction factors are not
re-computed. If you expect the counts to change dramatically, you can
break a run into a series of shorter runs so that the correction
factors are re-computed more frequently.</p>
</div>
<p>Several additional assumptions are inherent in using tail corrections,
including the following:</p>
<ul class="simple">
<li>The simulated system is a 3d bulk homogeneous liquid. This option
should not be used for systems that are non-liquid, 2d, have a slab
geometry (only 2d periodic), or inhomogeneous.</li>
<li>G(r), the radial distribution function (rdf), is unity beyond the
cutoff, so a fairly large cutoff should be used (i.e. 2.5 sigma for an
LJ fluid), and it is probably a good idea to verify this assumption by
checking the rdf. The rdf is not exactly unity beyond the cutoff for
each pair of interaction types, so the tail correction is necessarily
an approximation.</li>
</ul>
<p>The tail corrections are computed at the beginning of each simulation
run. If the number of atoms changes during the run, e.g. due to atoms
leaving the simulation domain, or use of the <a class="reference internal" href="fix_gcmc.html"><span class="doc">fix gcmc</span></a>
command, then the corrections are not updates to relect the changed
atom count. If this is a large effect in your simulation, you should
break the long run into several short runs, so that the correction
factors are re-computed multiple times.</p>
<ul class="simple">
<li>Thermophysical properties obtained from calculations with this option
enabled will not be thermodynamically consistent with the truncated
force-field that was used. In other words, atoms do not feel any LJ
pair interactions beyond the cutoff, but the energy and pressure
reported by the simulation include an estimated contribution from
those interactions.</li>
</ul>
<p>The <em>compute</em> keyword allows pairwise computations to be turned off,
even though a <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> is defined. This is not
useful for running a real simulation, but can be useful for debugging
purposes or for performing a <a class="reference internal" href="rerun.html"><span class="doc">rerun</span></a> simulation, when you
only wish to compute partial forces that do not include the pairwise
contribution.</p>
<p>Two examples are as follows. First, this option allows you to perform
a simulation with <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid</span></a> with only a
subset of the hybrid sub-styles enabled. Second, this option allows
you to perform a simulation with only long-range interactions but no
short-range pairwise interactions. Doing this by simply not defining
a pair style will not work, because the
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command requires a Kspace-compatible
pair style be defined.</p>
<hr class="docutils" />
<p>The <em>special</em> keyword allows to override the 1-2, 1-3, and 1-4
exclusion settings for individual sub-styles of a
<a class="reference internal" href="pair_hybrid.html"><span class="doc">hybrid pair style</span></a>. It requires 4 arguments similar
to the <a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command, <em>which</em> and
wt1,wt2,wt3. The <em>which</em> argument can be <em>lj</em> to change the
Lennard-Jones settings, <em>coul</em> to change the Coulombic settings,
or <em>lj/coul</em> to change both to the same set of 3 values. The wt1,wt2,wt3
values are numeric weights from 0.0 to 1.0 inclusive, for the 1-2,
1-3, and 1-4 bond topology neighbors, respectively. The <em>special</em>
keyword can only be used in conjunction with the <em>pair</em> keyword
and has to directly follow it.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The global settings specified by the
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command affect the construction of
neighbor lists. Weights of 0.0 (for 1-2, 1-3, or 1-4 neighbors)
exclude those pairs from the neighbor list entirely. Weights of 1.0
store the neighbor with no weighting applied. Thus only global values
different from exactly 0.0 or 1.0 can be overridden and an error is
generated if the requested setting is not compatible with the global
setting. Substituting 1.0e-10 for 0.0 and 0.9999999999 for 1.0 is
usually a sufficient workaround in this case without causing a
significant error.</p>
</div>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<blockquote>
<div>none</div></blockquote>
<p>You cannot use <em>shift</em> yes with <em>tail</em> yes, since those are
conflicting options. You cannot use <em>tail</em> yes with 2d simulations.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The <em>morse/soft</em> style requires the following pair coefficients:</p>
<ul class="simple">
<li>D0 (energy units)</li>
<li>alpha (1/distance units)</li>
<li>r0 (distance units)</li>
<li>lamda (unitless, between 0.0 and 1.0)</li>
<li>cutoff (distance units)</li>
</ul>
<p>The last coefficient is optional. If not specified, the global morse
cutoff is used.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>None of these pair styles support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>All of these pair styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table options is not relevant for
the Morse pair styles.</p>
<p>None of these pair styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>All of these pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
<p>The <em>morse/smooth/linear</em> pair style is only enabled if LAMMPS was
built with the USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The <em>morse/soft</em> pair style is only enabled if LAMMPS was built with
the USER-FEP package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>See the supporting information of <a class="reference internal" href="pair_multi_lucy_rx.html#brennan"><span class="std std-ref">(Brennan)</span></a> or the
publication by <a class="reference internal" href="pair_multi_lucy_rx.html#moore"><span class="std std-ref">(Moore)</span></a> for more details on the functional
form.</p>
<p>An interpolation table is used to evaluate the density-dependent
energy (Integral(A(rho)drho) and force (A(rho)). Note that the
pre-factor to the energy is computed after the interpolation, thus the
Integral(A(rho)drho will have units of energy / length^4.</p>
<p>The interpolation table is created as a pre-computation by fitting
cubic splines to the file values and interpolating the
density-dependent energy and force at each of <em>N</em> densities. During a
simulation, the tables are used to interpolate the density-dependent
energy and force as needed for each pair of particles separated by a
distance <em>R</em>. The interpolation is done in one of 2 styles: <em>lookup</em>
and <em>linear</em>.</p>
<p>For the <em>lookup</em> style, the density is used to find the nearest table
entry, which is the density-dependent energy and force.</p>
<p>For the <em>linear</em> style, the density is used to find the 2 surrounding
table values from which the density-dependent energy and force are
computed by linear interpolation.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above.</p>
<ul class="simple">
<li>filename</li>
<li>keyword</li>
<li>cutoff (distance units)</li>
</ul>
<p>The filename specifies a file containing the tabulated
density-dependent energy and force. The keyword specifies a section
of the file. The cutoff is an optional coefficient. If not
specified, the outer cutoff in the table itself (see below) will be
used to build an interpolation table that extend to the largest
tabulated distance. If specified, only file values up to the cutoff
are used to create the interpolation table. The format of this file
is described below.</p>
<hr class="docutils" />
<p>The format of a tabulated file is a series of one or more sections,
defined as follows (without the parenthesized comments):</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># Density-dependent function (one or more comment or blank lines)</span>
<p>This command is part of the USER-DPD package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>See the supporting information of <a class="reference internal" href="#brennan"><span class="std std-ref">(Brennan)</span></a> or the
publication by <a class="reference internal" href="#moore"><span class="std std-ref">(Moore)</span></a> for more details on the functional
form.</p>
<p>An interpolation table is used to evaluate the density-dependent
energy (Integral(A(rho)drho) and force (A(rho)). Note that the
pre-factor to the energy is computed after the interpolation, thus the
Integral(A(rho)drho will have units of energy / length^4.</p>
<p>The interpolation table is created as a pre-computation by fitting
cubic splines to the file values and interpolating the
density-dependent energy and force at each of <em>N</em> densities. During a
simulation, the tables are used to interpolate the density-dependent
energy and force as needed for each pair of particles separated by a
distance <em>R</em>. The interpolation is done in one of 2 styles: <em>lookup</em>
and <em>linear</em>.</p>
<p>For the <em>lookup</em> style, the density is used to find the nearest table
entry, which is the density-dependent energy and force.</p>
<p>For the <em>linear</em> style, the density is used to find the 2 surrounding
table values from which the density-dependent energy and force are
computed by linear interpolation.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above.</p>
<ul class="simple">
<li>filename</li>
<li>keyword</li>
<li>species1</li>
<li>species2</li>
<li>cutoff (distance units)</li>
</ul>
<p>The filename specifies a file containing the tabulated
density-dependent energy and force. The keyword specifies a section
of the file. The cutoff is an optional coefficient. If not
specified, the outer cutoff in the table itself (see below) will be
used to build an interpolation table that extend to the largest
tabulated distance. If specified, only file values up to the cutoff
are used to create the interpolation table. The format of this file
is described below.</p>
<p>The species tags define the site-site interaction potential between
two species contained within two different particles. The species
tags must either correspond to the species defined in the reaction
kinetics files specified with the <a class="reference internal" href="fix_rx.html"><span class="doc">fix rx</span></a> command or they
must correspond to the tag “1fluid”, signifying interaction with a
product species mixture determined through a one-fluid approximation.
The interaction potential is weighted by the geometric average of the
concentrations of the two species. The coarse-grained potential is
stored before and after the reaction kinetics solver is applied, where
the difference is defined to be the internal chemical energy (uChem).</p>
<hr class="docutils" />
<p>The format of a tabulated file is a series of one or more sections,
defined as follows (without the parenthesized comments):</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># Density-dependent function (one or more comment or blank lines)</span>
<p>This command is part of the USER-DPD package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The first three Si arguments map LAMMPS atom types 1,2,3 to the Si
element in the potential file. The final C argument maps LAMMPS atom
type 4 to the C element in the potential file. If a mapping value is
specified as NULL, the mapping is not performed. This can be used
when the potential is used as part of the <em>hybrid</em> pair style. The
NULL values are placeholders for atom types that will be used with
other potentials. An example of a pair_coeff command for use with the
<em>hybrid</em> pair style is:</p>
<p>pair_coeff * * nb3b/harmonic MgOH.nb3b.harmonic Mg O H</p>
<p>Three-body nonbonded harmonic files in the <em>potentials</em> directory of
the LAMMPS distribution have a ”.nb3b.harmonic” suffix. Lines that
are not blank or comments (starting with #) define parameters for a
triplet of elements.</p>
<p>Each entry has six arguments. The first three are atom types as
referenced in the LAMMPS input file. The first argument specifies the
central atom. The fourth argument indicates the <em>K</em> parameter. The
fifth argument indicates <em>theta_0</em>. The sixth argument indicates a
separation cutoff in Angstroms.</p>
<p>For a given entry, if the second and third arguments are identical,
then the entry is for a cutoff for the distance between types 1 and 2
(values for <em>K</em> and <em>theta_0</em> are irrelevant in this case).</p>
<p>For a given entry, if the first three arguments are all different,
then the entry is for the <em>K</em> and <em>theta_0</em> parameters (the cutoff in
this case is irrelevant).</p>
<p>It is <em>not</em> required that the potential file contain entries for all
of the elements listed in the pair_coeff command. It can also contain
entries for additional elements not being used in a particular
simulation; LAMMPS ignores those entries.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This pair style can only be used if LAMMPS was built with the MANYBODY
package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>These pair styles do not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>All of the <em>nm</em> pair styles supports the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option for the energy of the pair
interaction.</p>
<p>The <em>nm/cut/coul/long</em> pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option since they can tabulate
the short-range portion of the long-range Coulombic interaction.</p>
<p>All of the <em>nm</em> pair styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding a long-range tail correction to the energy and
pressure for the NM portion of the pair interaction.</p>
<p>All of the <em>nm</em> pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>All of the <em>nm</em> pair styles can only be used via the <em>pair</em> keyword of
the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>These pair styles are part of the MISC package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The peridynamic pair styles implement material models that can be used
at the mescscopic and macroscopic scales. See <a class="reference external" href="PDF/PDLammps_overview.pdf">this document</a> for an overview of LAMMPS commands
for Peridynamics modeling.</p>
<p>Style <em>peri/pmb</em> implements the Peridynamic bond-based prototype
microelastic brittle (PMB) model.</p>
<p>Style <em>peri/lps</em> implements the Peridynamic state-based linear
peridynamic solid (LPS) model.</p>
<p>Style <em>peri/ves</em> implements the Peridynamic state-based linear
peridynamic viscoelastic solid (VES) model.</p>
<p>Style <em>peri/eps</em> implements the Peridynamic state-based elastic-plastic
solid (EPS) model.</p>
<p>The canonical papers on Peridynamics are <a class="reference internal" href="#silling2000"><span class="std std-ref">(Silling 2000)</span></a>
and <a class="reference internal" href="#silling2007"><span class="std std-ref">(Silling 2007)</span></a>. The implementation of Peridynamics
in LAMMPS is described in <a class="reference internal" href="#parks"><span class="std std-ref">(Parks)</span></a>. Also see the <a class="reference external" href="http://www.sandia.gov/~mlparks/papers/PDLAMMPS.pdf">PDLAMMPS user guide</a> for
more details about its implementation.</p>
<p>The peridynamic VES and EPS models in PDLAMMPS were implemented by
R. Rahman and J. T. Foster at University of Texas at San Antonio. The
original VES formulation is described in “(Mitchell2011)” and the
original EPS formulation is in “(Mitchell2011a)”. Additional PDF docs
that describe the VES and EPS implementations are include in the
LAMMPS distro in <a class="reference external" href="PDF/PDLammps_VES.pdf">doc/PDF/PDLammps_VES.pdf</a> and
<a class="reference external" href="PDF/PDLammps_EPS.pdf">doc/PDF/PDLammps_EPS.pdf</a>. For questions
regarding the VES and EPS models in LAMMPS you can contact R. Rahman
(rezwanur.rahman at utsa.edu).</p>
<p>The following coefficients must be defined for each pair of atom types
via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples above,
<p>C is the effectively a spring constant for Peridynamic bonds, the
horizon is a cutoff distance for truncating interactions, and s00 and
alpha are used as a bond breaking criteria. The units of c are such
that c/distance = stiffness/volume^2, where stiffness is
energy/distance^2 and volume is distance^3. See the users guide for
more details.</p>
<p>For the <em>peri/lps</em> style:</p>
<ul class="simple">
<li>K (force/area units)</li>
<li>G (force/area units)</li>
<li>horizon (distance units)</li>
<li>s00 (unitless)</li>
<li>alpha (unitless)</li>
</ul>
<p>K is the bulk modulus and G is the shear modulus. The horizon is a
cutoff distance for truncating interactions, and s00 and alpha are
used as a bond breaking criteria. See the users guide for more
details.</p>
<p>For the <em>peri/ves</em> style:</p>
<ul class="simple">
<li>K (force/area units)</li>
<li>G (force/area units)</li>
<li>horizon (distance units)</li>
<li>s00 (unitless)</li>
<li>alpha (unitless)</li>
<li>m_lambdai (unitless)</li>
<li>m_taubi (unitless)</li>
</ul>
<p>K is the bulk modulus and G is the shear modulus. The horizon is a
cutoff distance for truncating interactions, and s00 and alpha are
used as a bond breaking criteria. m_lambdai and m_taubi are the
viscoelastic relaxation parameter and time constant,
respectively. m_lambdai varies within zero to one. For very small
values of m_lambdai the viscoelsatic model responds very similar to a
linear elastic model. For details please see the description in
“(Mtchell2011)”.</p>
<p>For the <em>peri/eps</em> style:</p>
<p>K (force/area units)
G (force/area units)
horizon (distance units)
s00 (unitless)
alpha (unitless)
m_yield_stress (force/area units)</p>
<p>K is the bulk modulus and G is the shear modulus. The horizon is a
cutoff distance and s00 and alpha are used as a bond breaking
criteria. m_yield_stress is the yield stress of the material. For
details please see the description in “(Mtchell2011a)”.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>These pair styles do not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>These pair styles do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table and tail options are not
relevant for these pair styles.</p>
<p>These pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
<p>All of these styles are part of the PERI package. They are only
enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This pair styles does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>If using create_atoms command, atomic masses must be defined in the
input script. If using read_data, atomic masses must be defined in the
atomic structure data file.</p>
<p>This pair style is part of the MANYBODY package. It is only enabled if
LAMMPS was built with that package (which it is by default). See the
<a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This pair potential requires the <a class="reference internal" href="newton.html"><span class="doc">newtion</span></a> setting to be
“on” for pair interactions.</p>
<p>The potential files provided with LAMMPS (see the potentials
directory) are parameterized for metal <a class="reference internal" href="units.html"><span class="doc">units</span></a>. You can use
any LAMMPS units, but you would need to create your own potential
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
mix, shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>This pair style is part of the USER-QUIP package. It is only enabled
if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>QUIP potentials are parametrized in electron-volts and Angstroms and
therefore should be used with LAMMPS metal <a class="reference internal" href="units.html"><span class="doc">units</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Style <em>reax</em> computes the ReaxFF potential of van Duin, Goddard and
co-workers. ReaxFF uses distance-dependent bond-order functions to
represent the contributions of chemical bonding to the potential
energy. There is more than one version of ReaxFF. The version
implemented in LAMMPS uses the functional forms documented in the
supplemental information of the following paper:
<a class="reference internal" href="pair_reax_c.html#chenoweth-2008"><span class="std std-ref">(Chenoweth)</span></a>. The version integrated into LAMMPS matches
the most up-to-date version of ReaxFF as of summer 2010.</p>
<p>WARNING: pair style reax is now deprecated and will soon be retired. Users
should switch to <a class="reference internal" href="pair_reax_c.html"><span class="doc">pair_style reax/c</span></a>. The <em>reax</em> style
differs from the <em>reax/c</em> style in the lo-level implementation details.
The <em>reax</em> style is a
Fortran library, linked to LAMMPS. The <em>reax/c</em> style was initially
implemented as stand-alone C code and is now integrated into LAMMPS as
a package.</p>
<p>LAMMPS requires that a file called ffield.reax be provided, containing
the ReaxFF parameters for each atom type, bond type, etc. The format
is identical to the ffield file used by van Duin and co-workers. The
filename is required as an argument in the pair_coeff command. Any
value other than “ffield.reax” will be rejected (see below).</p>
<p>LAMMPS provides several different versions of ffield.reax in its
potentials dir, each called potentials/ffield.reax.label. These are
documented in potentials/README.reax. The default ffield.reax
contains parameterizations for the following elements: C, H, O, N.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">We do not distribute a wide variety of ReaxFF force field files
with LAMMPS. Adri van Duin’s group at PSU is the central repository
for this kind of data as they are continuously deriving and updating
parameterizations for different classes of materials. You can submit
a contact request at the Materials Computation Center (MCC) website
<p>This pair style tallies a breakdown of the total ReaxFF potential
energy into sub-categories, which can be accessed via the <a class="reference internal" href="compute_pair.html"><span class="doc">compute pair</span></a> command as a vector of values of length 14.
The 14 values correspond to the following sub-categories (the variable
names in italics match those used in the ReaxFF FORTRAN library):</p>
<ol class="arabic simple">
<li><em>eb</em> = bond energy</li>
<li><em>ea</em> = atom energy</li>
<li><em>elp</em> = lone-pair energy</li>
<li><em>emol</em> = molecule energy (always 0.0)</li>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
mix, shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Style <em>reax/c</em> computes the ReaxFF potential of van Duin, Goddard and
co-workers. ReaxFF uses distance-dependent bond-order functions to
represent the contributions of chemical bonding to the potential
energy. There is more than one version of ReaxFF. The version
implemented in LAMMPS uses the functional forms documented in the
supplemental information of the following paper: <a class="reference internal" href="#chenoweth-2008"><span class="std std-ref">(Chenoweth et al., 2008)</span></a>. The version integrated into LAMMPS matches
the most up-to-date version of ReaxFF as of summer 2010. For more
technical details about the pair reax/c implementation of ReaxFF, see
the <a class="reference internal" href="#aktulga"><span class="std std-ref">(Aktulga)</span></a> paper.</p>
<p>The <em>reax/c/kk</em> style is a Kokkos version of the ReaxFF potential that is
derived from the <em>reax/c</em> style. The Kokkos version can run on GPUs and
can also use OpenMP multithreading. For more information about the Kokkos package,
see <a class="reference internal" href="Section_packages.html#kokkos"><span class="std std-ref">Section_packages</span></a> and <a class="reference internal" href="accelerate_kokkos.html"><span class="doc">Section_accelerate</span></a>.
One important consideration when using the <em>reax/c/kk</em> style is the choice of either
half or full neighbor lists. This setting can be changed using the Kokkos <a class="reference internal" href="package.html"><span class="doc">package</span></a>
command.</p>
<p>The <em>reax/c</em> style differs from the <a class="reference internal" href="pair_reax.html"><span class="doc">pair_style reax</span></a>
command in the lo-level implementation details. The <em>reax</em> style is a
Fortran library, linked to LAMMPS. The <em>reax/c</em> style was initially
implemented as stand-alone C code and is now integrated into LAMMPS as
a package.</p>
<p>LAMMPS provides several different versions of ffield.reax in its
potentials dir, each called potentials/ffield.reax.label. These are
documented in potentials/README.reax. The default ffield.reax
contains parameterizations for the following elements: C, H, O, N.</p>
<p>The format of these files is identical to that used originally by van
Duin. We have tested the accuracy of <em>pair_style reax/c</em> potential
against the original ReaxFF code for the systems mentioned above. You
can use other ffield files for specific chemical systems that may be
available elsewhere (but note that their accuracy may not have been
tested).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">We do not distribute a wide variety of ReaxFF force field files
with LAMMPS. Adri van Duin’s group at PSU is the central repository
for this kind of data as they are continuously deriving and updating
parameterizations for different classes of materials. You can submit
a contact request at the Materials Computation Center (MCC) website
<p>Use of this pair style requires that a charge be defined for every
atom. See the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a> and
<a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> commands for details on how to specify
charges.</p>
<p>The ReaxFF parameter files provided were created using a charge
equilibration (QEq) model for handling the electrostatic interactions.
Therefore, by default, LAMMPS requires that the <a class="reference internal" href="fix_qeq_reax.html"><span class="doc">fix qeq/reax</span></a> command be used with <em>pair_style reax/c</em>
when simulating a ReaxFF model, to equilibrate charge each timestep.
Using the keyword <em>checkqeq</em> with the value <em>no</em>
turns off the check for <em>fix qeq/reax</em>,
allowing a simulation to be run without charge equilibration.
In this case, the static charges you
assign to each atom will be used for computing the electrostatic
interactions in the system.
See the <a class="reference internal" href="fix_qeq_reax.html"><span class="doc">fix qeq/reax</span></a> command for details.</p>
<p>Using the optional keyword <em>lgvdw</em> with the value <em>yes</em> turns on
the low-gradient correction of the ReaxFF/C for long-range
London Dispersion, as described in the <a class="reference internal" href="#liu-2011"><span class="std std-ref">(Liu)</span></a> paper. Force field
file <em>ffield.reax.lg</em> is designed for this correction, and is trained
for several energetic materials (see “Liu”). When using lg-correction,
recommended value for parameter <em>thb</em> is 0.01, which can be set in the
control file. Note: Force field files are different for the original
or lg corrected pair styles, using wrong ffield file generates an error message.</p>
<p>Optional keywords <em>safezone</em> and <em>mincap</em> are used for allocating
reax/c arrays. Increasing these values can avoid memory problems, such
as segmentation faults and bondchk failed errors, that could occur under
certain conditions. These keywords aren’t used by the Kokkos version, which
instead uses a more robust memory allocation scheme that checks if the sizes of
the arrays have been exceeded and automatically allocates more memory.</p>
<p>The thermo variable <em>evdwl</em> stores the sum of all the ReaxFF potential
energy contributions, with the exception of the Coulombic and charge
equilibration contributions which are stored in the thermo variable
<em>ecoul</em>. The output of these quantities is controlled by the
<p>This pair style tallies a breakdown of the total ReaxFF potential
energy into sub-categories, which can be accessed via the <a class="reference internal" href="compute_pair.html"><span class="doc">compute pair</span></a> command as a vector of values of length 14.
The 14 values correspond to the following sub-categories (the variable
names in italics match those used in the original FORTRAN ReaxFF code):</p>
<ol class="arabic simple">
<li><em>eb</em> = bond energy</li>
<li><em>ea</em> = atom energy</li>
<li><em>elp</em> = lone-pair energy</li>
<li><em>emol</em> = molecule energy (always 0.0)</li>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
mix, shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This pair style is part of the USER-REAXC package. It is only enabled
if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The ReaxFF potential files provided with LAMMPS in the potentials
directory are parameterized for real <a class="reference internal" href="units.html"><span class="doc">units</span></a>. You can use
the ReaxFF potential with any LAMMPS units, but you would need to
create your own potential file with coefficients listed in the
appropriate units if your simulation doesn’t use “real” units.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Style <em>resquared</em> computes the RE-squared anisotropic interaction
<a class="reference internal" href="#everaers"><span class="std std-ref">(Everaers)</span></a>, <a class="reference internal" href="#babadi"><span class="std std-ref">(Babadi)</span></a> between pairs of
ellipsoidal and/or spherical Lennard-Jones particles. For ellipsoidal
interactions, the potential considers the ellipsoid as being comprised
of small spheres of size sigma. LJ particles are a single sphere of
size sigma. The distinction is made to allow the pair style to make
efficient calculations of ellipsoid/solvent interactions.</p>
<p>Details for the equations used are given in the references below and
in <a class="reference external" href="PDF/pair_resquared_extra.pdf">this supplementary document</a>.</p>
<p>Use of this pair style requires the NVE, NVT, or NPT fixes with the
<em>asphere</em> extension (e.g. <a class="reference internal" href="fix_nve_asphere.html"><span class="doc">fix nve/asphere</span></a>) in
order to integrate particle rotation. Additionally, <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a> should be used since it defines the
rotational state and the size and shape of each ellipsoidal particle.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<p>where a, b, and c give the particle diameters.</p>
<p>The last coefficient is optional. If not specified, the global cutoff
specified in the pair_style command is used.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the Lennard-Jones portion of the pair
interaction, but only for sphere-sphere interactions. There is no
shifting performed for ellipsoidal interactions due to the anisotropic
dependence of the interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<em>inner</em>, <em>middle</em>, <em>outer</em> keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style command</span></a>.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This style is part of the ASPHERE package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This pair style requires that atoms be ellipsoids as defined by the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum. The prefactors
are chosen so that the potential minimum is at -epsilon.</p>
<p>The latter 2 coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair.</p>
<p>For <em>lj/sdk/coul/long</em> only the LJ cutoff can be specified since a
Coulombic cutoff cannot be specified for an individual I,J type pair.
All type pairs use the same global Coulombic cutoff specified in the
pair_style command.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em> or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP, and OPT packages respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<hr class="docutils" />
<p><strong>Mixing, shift, table, tail correction, restart, and rRESPA info</strong>:</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/sdk pair styles <em>cannot</em> be mixed,
since different pairs may have different exponents. So all parameters
for all pairs have to be specified explicitly through the “pair_coeff”
command. Defining then in a data file is also not supported, due to
limitations of that file format.</p>
<p>All of the lj/sdk pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option for the energy of the
Lennard-Jones portion of the pair interaction.</p>
<p>The <em>lj/sdk/coul/long</em> pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option since they can tabulate
the short-range portion of the long-range Coulombic interaction.</p>
<p>All of the lj/sdk pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.</p>
<p>The lj/sdk and lj/cut/coul/long pair styles do not support
the use of the <em>inner</em>, <em>middle</em>, and <em>outer</em> keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>All of the lj/sdk pair styles are part of the USER-CG-CMM package.
The <em>lj/sdk/coul/long</em> style also requires the KSPACE package to be
built (which is enabled by default). They are only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
Currently, no part of USER-SMD supports restarting nor minimization.
rRESPA does not apply to this pair style.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-SMD package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
Currently, no part of USER-SMD supports restarting nor minimization.
rRESPA does not apply to this pair style.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the USER-SMD package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+pair_coeff * * PathToLammps/potentials/ffield.smtbq.TiO2 O Ti
+</pre>
<p>The electrostatic part of the energy consists of two components</p>
<p>self-energy of atom <em>i</em> in the form of a second order charge dependent
polynomial and a long-range Coulombic electrostatic interaction. The
latter uses the wolf summation method described in <a class="reference internal" href="#wolf"><span class="std std-ref">Wolf</span></a>,
spherically truncated at a longer cutoff, <em>R<sub>coul</sub></em>. The
charge of each ion is modeled by an orbital Slater which depends on
the principal quantum number (<em>n</em>) of the outer orbital shared by the
ion.</p>
<p>Interaction between oxygen, <em>E<sub>OO</sub></em>, consists of two parts,
an attractive and a repulsive part. The attractive part is effective
only at short range (< r<sub>2</sub><sup>OO</sup>). The attractive
contribution was optimized to study surfaces reconstruction
(e.g. <a class="reference internal" href="#smtb-q-2"><span class="std std-ref">SMTB-Q_2</span></a> in TiO<sub>2</sub>) and is not necessary
for oxide bulk modeling. The repulsive part is the Pauli interaction
between the electron clouds of oxygen. The Pauli repulsion and the
coulombic electrostatic interaction have same cut off value. In the
ffield.SMTBQ.Syst, the keyword <em>‘buck’</em> allows to consider only the
repulsive O-O interactions. The keyword <em>‘buckPlusAttr’</em> allows to
consider the repulsive and the attractive O-O interactions.</p>
<p>The short-range interaction between metal-oxygen, <em>E<sub>MO</sub></em> is
based on the second moment approximation of the density of states with
a N-body potential for the band energy term,
<em>E<sup>i</sup><sub>cov</sub></em>, and a Born-Mayer type repulsive terms
as indicated by the keyword <em>‘second_moment’</em> in the
ffield.SMTBQ.Syst. The energy band term is given by:</p>
<p>Thus parameter &#956, indicated above, is given by : &#956 = (&#8730n
+ &#8730m) &#8260 2</p>
<p>The potential offers the possibility to consider the polarizability of
the electron clouds of oxygen by changing the slater radius of the
charge density around the oxygens through the parameters <em>rBB, rB and
rS</em> in the ffield.SMTBQ.Syst. This change in radius is performed
according to the method developed by E. Maras
<a class="reference internal" href="#smtb-q-2"><span class="std std-ref">SMTB-Q_2</span></a>. This method needs to determine the number of
nearest neighbors around the oxygen. This calculation is based on
first (<em>r<sub>1n</sub></em>) and second (<em>r<sub>2n</sub></em>) distances
neighbors.</p>
<p>The SMTB-Q potential is a variable charge potential. The equilibrium
charge on each atom is calculated by the electronegativity
equalization (QEq) method. See <a class="reference internal" href="#rick"><span class="std std-ref">Rick</span></a> for further detail. One
can adjust the frequency, the maximum number of iterative loop and the
convergence of the equilibrium charge calculation. To obtain the
energy conservation in NVE thermodynamic ensemble, we recommend to use
a convergence parameter in the interval 10<sup>-5</sup> -
10<sup>-6</sup> eV.</p>
<p>The ffield.SMTBQ.Syst files are provided for few systems. They consist
of nine parts and the lines beginning with ‘#’ are comments (note that
the number of comment lines matter). The first sections are on the
potential parameters and others are on the simulation options and
might be modified. Keywords are character type and must be enclosed in
quotation marks (‘’).</p>
<ol class="arabic simple">
<li>Number of different element in the oxide:</li>
</ol>
<ul class="simple">
<li>N<sub>elem</sub>= 2 or 3</li>
<li>Divided line</li>
</ul>
<ol class="arabic simple" start="2">
<li>Atomic parameters</li>
</ol>
<p>For the anion (oxygen)</p>
<ul class="simple">
<li>Name of element (char) and stoichiometry in oxide</li>
<li>Formal charge and mass of element</li>
<li>Principal quantic number of outer orbital (<em>n</em>), electronegativity (<em>&#967<sup>0</sup><sub>i</simulationub></em>) and hardness (<em>J<sup>0</sup><sub>i</sub></em>)</li>
<li>Ionic radius parameters : max coordination number (<em>coordBB</em> = 6 by default), bulk coordination number <em>(coordB)</em>, surface coordination number <em>(coordS)</em> and <em>rBB, rB and rS</em> the slater radius for each coordination number. (<b>note : If you don’t want to change the slater radius, use three identical radius values</b>)</li>
<li>Number of orbital shared by the element in the oxide (<em>d<sub>i</sub></em>)</li>
<li>Divided line</li>
</ul>
<p>For each cations (metal):</p>
<ul class="simple">
<li>Name of element (char) and stoichiometry in oxide</li>
<li>Formal charge and mass of element</li>
<li>Number of electron in outer orbital <em>(ne)</em>, electronegativity (<em>&#967<sup>0</sup><sub>i</simulationub></em>), hardness (<em>J<sup>0</sup><sub>i</sub></em>) and <em>r<sub>Salter</sub></em> the slater radius for the cation.</li>
<li>Number of orbitals shared by the elements in the oxide (<em>d<sub>i</sub></em>)</li>
<li>Divided line</li>
</ul>
<ol class="arabic simple" start="3">
<li>Potential parameters:</li>
</ol>
<ul class="simple">
<li>Keyword for element1, element2 and interaction potential (‘second_moment’ or ‘buck’ or ‘buckPlusAttr’) between element 1 and 2. If the potential is ‘second_moment’, specify ‘oxide’ or ‘metal’ for metal-oxygen or metal-metal interactions respectively.</li>
-<li>Potential parameter: <pre><br/> If type of potential is ‘second_moment’ : <em>A (eV)</em>, <em>p</em>, <em>&#958<sup>0</sup></em> (eV) and <em>q</em> <br/> <em>r<sub>c1</sub></em> (&#197), <em>r<sub>c2</sub></em> (&#197) and <em>r<sub>0</sub></em> (&#197) <br/> If type of potential is ‘buck’ : <em>C</em> (eV) and <em>&#961</em> (&#197) <br/> If type of potential is ‘buckPlusAttr’ : <em>C</em> (eV) and <em>&#961</em> (&#197) <br/> <em>D</em> (eV), <em>B</em> (&#197<sup>-1</sup>), <em>r<sub>1</sub><sup>OO</sup></em> (&#197) and <em>r<sub>2</sub><sup>OO</sup></em> (&#197) </pre></li>
+<li>Potential parameter: <pre><br/> If type of potential is ‘second_moment’ : <em>A (eV)</em>, <em>p</em>, <em>&#958<sup>0</sup></em> (eV) and <em>q</em> <br/> <em>r<sub>c1</sub></em> (&#197), <em>r<sub>c2</sub></em> (&#197) and <em>r<sub>0</sub></em> (&#197) <br/> If type of potential is ‘buck’ : <em>C</em> (eV) and <em>&#961</em> (&#197) <br/> If type of potential is ‘buckPlusAttr’ : <em>C</em> (eV) and <em>&#961</em> (&#197) <br/> <em>D</em> (eV), <em>B</em> (&#197<sup>-1</sup>), <em>r<sub>1</sub><sup>OO</sup></em> (&#197) and <em>r<sub>2</sub><sup>OO</sup></em> (&#197) </pre></li>
<li>Divided line</li>
</ul>
<ol class="arabic simple" start="4">
<li>Tables parameters:</li>
</ol>
<ul class="simple">
<li>Cutoff radius for the Coulomb interaction (<em>R<sub>coul</sub></em>)</li>
<li>Starting radius (<em>r<sub>min</sub></em> = 1,18845 &#197) and increments (<em>dr</em> = 0,001 &#197) for creating the potential table.</li>
<li>Divided line</li>
</ul>
<ol class="arabic simple" start="5">
<li>Rick model parameter:</li>
</ol>
<ul class="simple">
<li><em>Nevery</em> : parameter to set the frequency (<em>1/Nevery</em>) of the charge resolution. The charges are evaluated each <em>Nevery</em> time steps.</li>
<li>Max number of iterative loop (<em>loopmax</em>) and precision criterion (<em>prec</em>) in eV of the charge resolution</li>
<li>Divided line</li>
</ul>
<ol class="arabic simple" start="6">
<li>Coordination parameter:</li>
</ol>
<ul class="simple">
<li>First (<em>r<sub>1n</sub></em>) and second (<em>r<sub>2n</sub></em>) neighbor distances in &#197</li>
<li>Divided line</li>
</ul>
<ol class="arabic simple" start="7">
<li>Charge initialization mode:</li>
</ol>
<ul class="simple">
<li>Keyword (<em>QInitMode</em>) and initial oxygen charge (<em>Q<sub>init</sub></em>). If keyword = ‘true’, all oxygen charges are initially set equal to <em>Q<sub>init</sub></em>. The charges on the cations are initially set in order to respect the neutrality of the box. If keyword = ‘false’, all atom charges are initially set equal to 0 if you use “create_atom”#create_atom command or the charge specified in the file structure using <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command.</li>
<li>Divided line</li>
</ul>
<ol class="arabic simple" start="8">
<li>Mode for the electronegativity equalization (Qeq)</li>
</ol>
<ul class="simple">
<li>Keyword mode: <pre> <br/> QEqAll (one QEq group) | no parameters <br/> QEqAllParallel (several QEq groups) | no parameters <br/> Surface | zlim (QEq only for z>zlim) </pre></li>
<li>Parameter if necessary</li>
<li>Divided line</li>
</ul>
<ol class="arabic simple" start="9">
<li>Verbose</li>
</ol>
<ul class="simple">
<li>If you want the code to work in verbose mode or not : ‘true’ or ‘false’</li>
<li>If you want to print or not in file ‘Energy_component.txt’ the three main contributions to the energy of the system according to the description presented above : ‘true’ or ‘false’ and <em>N<sub>Energy</sub></em>. This option writes in file every <em>N<sub>Energy</sub></em> time step. If the value is ‘false’ then <em>N<sub>Energy</sub></em> = 0. The file take into account the possibility to have several QEq group <em>g</em> then it writes: time step, number of atoms in group <em>g</em>, electrostatic part of energy, <em>E<sub>ES</sub></em>, the interaction between oxygen, <em>E<sub>OO</sub></em>, and short range metal-oxygen interaction, <em>E<sub>MO</sub></em>.</li>
<li>If you want to print in file ‘Electroneg_component.txt’ the electronegativity component (<em>&#8706E<sub>tot</sub> &#8260&#8706Q<sub>i</sub></em>) or not: ‘true’ or ‘false’ and <em>N<sub>Electroneg</sub></em>.This option writes in file every <em>N<sub>Electroneg</sub></em> time step. If the value is ‘false’ then <em>N<sub>Electroneg</sub></em> = 0. The file consist in atom number <em>i</em>, atom type (1 for oxygen and # higher than 1 for metal), atom position: <em>x</em>, <em>y</em> and <em>z</em>, atomic charge of atom <em>i</em>, electrostatic part of atom <em>i</em> electronegativity, covalent part of atom <em>i</em> electronegativity, the hopping integral of atom <em>i</em> <em>(Z&#946<sup>2</sup>)<sub>i<sub></em> and box electronegativity.</li>
</ul>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">This last option slows down the calculation dramatically. Use
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
mix, shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
needs to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>This pair style is part of the USER-SMTBQ package and is only enabled
if LAMMPS is built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This potential requires using atom type 1 for oxygen and atom type
higher than 1 for metal atoms.</p>
<p>This pair style requires the <a class="reference internal" href="newton.html"><span class="doc">newton</span></a> setting to be “on”
for pair interactions.</p>
<p>The SMTB-Q potential files provided with LAMMPS (see the potentials
directory) are parameterized for metal <a class="reference internal" href="units.html"><span class="doc">units</span></a>.</p>
<hr class="docutils" />
<p><strong>Citing this work:</strong></p>
<p>Please cite related publication: N. Salles, O. Politano, E. Amzallag
and R. Tetot, Comput. Mater. Sci. 111 (2016) 181-189</p>
<hr class="docutils" />
<p id="smtb-q-1"><strong>(SMTB-Q_1)</strong> N. Salles, O. Politano, E. Amzallag, R. Tetot,
Comput. Mater. Sci. 111 (2016) 181-189</p>
<p id="smtb-q-2"><strong>(SMTB-Q_2)</strong> E. Maras, N. Salles, R. Tetot, T. Ala-Nissila,
H. Jonsson, J. Phys. Chem. C 2015, 119, 10391-10399</p>
<p id="smtb-q-3"><strong>(SMTB-Q_3)</strong> R. Tetot, N. Salles, S. Landron, E. Amzallag, Surface
Science 616, 19-8722 28 (2013)</p>
<p id="wolf"><strong>(Wolf)</strong> D. Wolf, P. Keblinski, S. R. Phillpot, J. Eggebrecht, J Chem
Phys, 110, 8254 (1999).</p>
<p id="rick"><strong>(Rick)</strong> S. W. Rick, S. J. Stuart, B. J. Berne, J Chem Phys 101, 6141
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
pair_coeff * * snap ../potentials/Ta06A.snapcoeff Ta &
../potentials/Ta06A.snapparam Ta
-</pre></div>
-</div>
+</pre>
<p>It is convenient to keep these commands in a separate file that can
be inserted in any LAMMPS input script using the <a class="reference internal" href="include.html"><span class="doc">include</span></a>
command.</p>
<p>The top of the SNAP element file can contain any number of blank and comment
lines (start with #), but follows a strict
format after that. The first non-blank non-comment
line must contain two integers:</p>
<ul class="simple">
<li>nelem = Number of elements</li>
<li>ncoeff = Number of coefficients</li>
</ul>
<p>This is followed by one block for each of the <em>nelem</em> elements.
The first line of each block contains three entries:</p>
<ul class="simple">
<li>Element symbol (text string)</li>
<li>R = Element radius (distance units)</li>
<li>w = Element weight (dimensionless)</li>
</ul>
<p>This line is followed by <em>ncoeff</em> coefficients, one per line.</p>
<p>The SNAP parameter file can contain blank and comment lines (start
with #) anywhere. Each non-blank non-comment line must contain one
keyword/value pair. The required keywords are <em>rcutfac</em> and
<em>twojmax</em>. Optional keywords are <em>rfac0</em>, <em>rmin0</em>, <em>diagonalstyle</em>,
and <em>switchflag</em>.</p>
<p>The default values for these keywords are</p>
<ul class="simple">
<li><em>rfac0</em> = 0.99363</li>
<li><em>rmin0</em> = 0.0</li>
<li><em>diagonalstyle</em> = 3</li>
<li><em>switchflag</em> = 0</li>
</ul>
<p>Detailed definitions of these keywords are given on the <a class="reference internal" href="compute_sna_atom.html"><span class="doc">compute sna/atom</span></a> doc page.</p>
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS with
user-specifiable parameters as described above. You never need to
specify a pair_coeff command with I != J arguments for this style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>This style is part of the SNAP package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>It is useful for pushing apart overlapping atoms, since it does not
blow up as r goes to 0. A is a pre-factor that can be made to vary in
time from the start to the end of the run (see discussion below),
e.g. to start with a very soft potential and slowly harden the
interactions over time. Rc is the cutoff. See the <a class="reference internal" href="fix_nve_limit.html"><span class="doc">fix nve/limit</span></a> command for another way to push apart
overlapping atoms.</p>
<p>The following coefficients must be defined for each pair of atom types
via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples above,
<p>Note that a formula defined by an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a>
can use the current timestep, elapsed time in the current run, elapsed
time since the beginning of a series of runs, as well as access other
variables.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the A coefficient and cutoff
distance for this pair style can be mixed. A is always mixed via a
<em>geometric</em> rule. The cutoff is mixed according to the pair_modify
mix value. The default mix value is <em>geometric</em>. See the
“pair_modify” command for details.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option, since the pair interaction goes to 0.0 at the cutoff.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table and tail options are not
relevant for this pair style.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This style does not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>This style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This style does not write information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Thus, you need to re-specify the pair_style and
pair_coeff commands in an input script that reads a restart file.</p>
<p>This style can only be used via the <em>pair</em> keyword of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the <em>inner</em>,
<em>middle</em>, <em>outer</em> keywords.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This pair style is part of the USER-SPH package. It is only enabled
if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This style does not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>This style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This style does not write information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Thus, you need to re-specify the pair_style and
pair_coeff commands in an input script that reads a restart file.</p>
<p>This style can only be used via the <em>pair</em> keyword of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the <em>inner</em>,
<em>middle</em>, <em>outer</em> keywords.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This pair style is part of the USER-SPH package. It is only enabled
if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This style does not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>This style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This style does not write information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Thus, you need to re-specify the pair_style and
pair_coeff commands in an input script that reads a restart file.</p>
<p>This style can only be used via the <em>pair</em> keyword of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the <em>inner</em>,
<em>middle</em>, <em>outer</em> keywords.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This pair style is part of the USER-SPH package. It is only enabled
if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where <em>L</em> is the normalized distance from the atom to the point of
closest approach of bond <em>i</em> and <em>j</em>. The <em>mid</em> option takes <em>L</em> as
0.5 for each interaction as described in <a class="reference internal" href="#sirk"><span class="std std-ref">(Sirk)</span></a>.</p>
<p>The following coefficients must be defined via the
<a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples above, or in
the data file or restart file read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li><em>C</em> (force units)</li>
<li><em>rc</em> (distance units)</li>
</ul>
<p>The last coefficient is optional. If not specified, the global cutoff
is used.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Pair style srp considers each bond of type <em>btype</em> to be a
fictitious “particle” of type <em>bptype</em>, where <em>bptype</em> is either the
largest atom type in the system, or the type set by the <em>bptype</em> flag.
Any actual existing particles with this atom type will be deleted at
the beginning of a run. This means you must specify the number of
types in your system accordingly; usually to be one larger than what
would normally be the case, e.g. via the <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a>
or by changing the header in your <a class="reference internal" href="read_data.html"><span class="doc">data file</span></a>. The
ficitious “bond particles” are inserted at the beginning of the run,
and serve as placeholders that define the position of the bonds. This
allows neighbor lists to be constructed and pairwise interactions to
be computed in almost the same way as is done for actual particles.
Because bonds interact only with other bonds, <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid</span></a> should be used to turn off interactions
between atom type <em>bptype</em> and all other types of atoms. An error
will be flagged if <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid</span></a> is not used.</p>
</div>
<p>The optional <em>exclude</em> keyword determines if forces are computed
between first neighbor (directly connected) bonds. For a setting of
<em>no</em>, first neighbor forces are computed; for <em>yes</em> they are not
computed. A setting of <em>no</em> cannot be used with the <em>min</em> option for
distance calculation because the the minimum distance between directly
connected bonds is zero.</p>
<p>Pair style <em>srp</em> turns off normalization of thermodynamic properties
by particle number, as if the command <a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify norm no</span></a> had been issued.</p>
<p>The pairwise energy associated with style <em>srp</em> is shifted to be zero
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the pair interaction. Note that as
discussed above, the energy term is already shifted to be 0.0 at the
cutoff distance <em>rc</em>.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant for
this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes global and per-atom information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Pair srp should be used with <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid</span></a>, thus the pair_coeff commands need to be
specified in the input script when reading a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> command sets options for mixing of
type I-J interaction coefficients and adding energy offsets or tail
corrections to Lennard-Jones potentials. Details on these options as
they pertain to individual potentials are described on the doc page
for the potential. Likewise, info on whether the potential
information is stored in a <a class="reference internal" href="write_restart.html"><span class="doc">restart file</span></a> is listed
on the potential doc page.</p>
<p>In the formulas listed for each pair style, <em>E</em> is the energy of a
pairwise interaction between two atoms separated by a distance <em>r</em>.
The force between the atoms is the negative derivative of this
expression.</p>
<p>If the pair_style command has a cutoff argument, it sets global
cutoffs for all pairs of atom types. The distance(s) can be smaller
or larger than the dimensions of the simulation box.</p>
<p>Typically, the global cutoff value can be overridden for a specific
pair of atom types by the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command. The
pair style settings (including global cutoffs) can be changed by a
subsequent pair_style command using the same style. This will reset
the cutoffs for all atom type pairs, including those previously set
explicitly by a <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command. The exceptions
to this are that pair_style <em>table</em> and <em>hybrid</em> settings cannot be
reset. A new pair_style command for these styles will wipe out all
previously specified pair_coeff values.</p>
<hr class="docutils" />
<p>Here is an alphabetic list of pair styles defined in LAMMPS. They are
also given in more compact form in the pair section of <a class="reference internal" href="Section_commands.html#cmd-5"><span class="std std-ref">this page</span></a>.</p>
<p>Click on the style to display the formula it computes, arguments
specified in the pair_style command, and coefficients specified by the
<li><a class="reference internal" href="pair_born.html"><span class="doc">pair_style born/coul/wolf</span></a> - Born-Mayer-Huggins with Coulombics via Wolf potential</li>
<li><a class="reference internal" href="pair_brownian.html"><span class="doc">pair_style brownian</span></a> - Brownian potential for Fast Lubrication Dynamics</li>
<li><a class="reference internal" href="pair_brownian.html"><span class="doc">pair_style brownian/poly</span></a> - Brownian potential for Fast Lubrication Dynamics with polydispersity</li>
<li><a class="reference internal" href="pair_kim.html"><span class="doc">pair_style kim</span></a> - interface to potentials provided by KIM project</li>
<li><a class="reference internal" href="pair_class2.html"><span class="doc">pair_style lj/class2</span></a> - COMPASS (class 2) force field with no Coulomb</li>
<li><a class="reference internal" href="pair_lubricateU.html"><span class="doc">pair_style lubricateU</span></a> - hydrodynamic lubrication forces for Fast Lubrication Dynamics</li>
<li><a class="reference internal" href="pair_lubricateU.html"><span class="doc">pair_style lubricateU/poly</span></a> - hydrodynamic lubrication forces for Fast Lubrication with polydispersity</li>
<p>Some pair styles are part of specific packages. They are only enabled
if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.
The doc pages for individual pair potentials tell if it is part of a
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
specify SW parameters for all permutations of the two elements
interacting in three-body configurations. Thus for 3 elements, 27
entries would be required, etc.</p>
<p>As annotated above, the first element in the entry is the center atom
in a three-body interaction. Thus an entry for SiCC means a Si atom
with 2 C atoms as neighbors. The parameter values used for the
two-body interaction come from the entry where the 2nd and 3rd
elements are the same. Thus the two-body parameters for Si
interacting with C, comes from the SiCC entry. The three-body
parameters can in principle be specific to the three elements of the
configuration. In the literature, however, the three-body parameters
are usually defined by simple formulas involving two sets of pair-wise
parameters, corresponding to the ij and ik pairs, where i is the
center atom. The user must ensure that the correct combining rule is
used to calculate the values of the threebody parameters for
alloys. Note also that the function phi3 contains two exponential
screening factors with parameter values from the ij pair and ik
pairs. So phi3 for a C atom bonded to a Si atom and a second C atom
will depend on the three-body parameters for the CSiC entry, and also
on the two-body parameters for the CCC and CSiSi entries. Since the
order of the two neighbors is arbitrary, the threebody parameters for
entries CSiC and CCSi should be the same. Similarly, the two-body
parameters for entries SiCC and CSiSi should also be the same. The
parameters used only for two-body interactions (A, B, p, and q) in
entries whose 2nd and 3rd element are different (e.g. SiCSi) are not
used for anything and can be set to 0.0 if desired.
This is also true for the parameters in phi3 that are
taken from the ij and ik pairs (sigma, a, gamma)</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>When using the USER-INTEL package with this style, there is an
additional 5 to 10 percent performance improvement when the
Stillinger-Weber parameters p and q are set to 4 and 0 respectively.
These parameters are common for modeling silicon and water.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Style <em>table</em> creates interpolation tables from potential energy and
force values listed in a file(s) as a function of distance. When
performing dynamics or minimation, the interpolation tables are used
to evaluate energy and forces for pairwise interactions between
particles, similar to how analytic formulas are used for other pair
styles.</p>
<p>The interpolation tables are created as a pre-computation by fitting
cubic splines to the file values and interpolating energy and force
values at each of <em>N</em> distances. During a simulation, the tables are
used to interpolate energy and force values as needed for each pair of
particles separated by a distance <em>R</em>. The interpolation is done in
one of 4 styles: <em>lookup</em>, <em>linear</em>, <em>spline</em>, or <em>bitmap</em>.</p>
<p>For the <em>lookup</em> style, the distance <em>R</em> is used to find the nearest
table entry, which is the energy or force.</p>
<p>For the <em>linear</em> style, the distance <em>R</em> is used to find the 2
surrounding table values from which an energy or force is computed by
linear interpolation.</p>
<p>For the <em>spline</em> style, a cubic spline coefficients are computed and
stored for each of the <em>N</em> values in the table, one set of splines for
energy, another for force. Note that these splines are different than
the ones used to pre-compute the <em>N</em> values. Those splines were fit
to the <em>Nfile</em> values in the tabulated file, where often <em>Nfile</em> <
<em>N</em>. The distance <em>R</em> is used to find the appropriate set of spline
coefficients which are used to evaluate a cubic polynomial which
computes the energy or force.</p>
<p>For the <em>bitmap</em> style, the specified <em>N</em> is used to create
interpolation tables that are 2^N in length. The distance <em>R</em> is used
to index into the table via a fast bit-mapping technique due to
<a class="reference internal" href="pair_table_rx.html#wolff"><span class="std std-ref">(Wolff)</span></a>, and a linear interpolation is performed between
adjacent table values.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above.</p>
<ul class="simple">
<li>filename</li>
<li>keyword</li>
<li>cutoff (distance units)</li>
</ul>
<p>The filename specifies a file containing tabulated energy and force
values. The keyword specifies a section of the file. The cutoff is
an optional coefficient. If not specified, the outer cutoff in the
table itself (see below) will be used to build an interpolation table
that extend to the largest tabulated distance. If specified, only
file values up to the cutoff are used to create the interpolation
table. The format of this file is described below.</p>
<p>If your tabulated potential(s) are designed to be used as the
short-range part of one of the long-range solvers specified by the
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command, then you must use one or
more of the optional keywords listed above for the pair_style command.
These are <em>ewald</em> or <em>pppm</em> or <em>msm</em> or <em>dispersion</em> or <em>tip4p</em>. This
is so LAMMPS can insure the short-range potential and long-range
solver are compatible with each other, as it does for other
short-range pair styles, such as <a class="reference internal" href="pair_lj.html"><span class="doc">pair_style lj/cut/coul/long</span></a>. Note that it is up to you to insure
the tabulated values for each pair of atom types has the correct
functional form to be compatible with the matching long-range solver.</p>
<hr class="docutils" />
<p>Here are some guidelines for using the pair_style table command to
best effect:</p>
<ul class="simple">
<li>Vary the number of table points; you may need to use more than you think
to get good resolution.</li>
<li>Always use the <a class="reference internal" href="pair_write.html"><span class="doc">pair_write</span></a> command to produce a plot
of what the final interpolated potential looks like. This can show up
interpolation “features” you may not like.</li>
<li>Start with the linear style; it’s the style least likely to have problems.</li>
<li>Use <em>N</em> in the pair_style command equal to the “N” in the tabulation
file, and use the “RSQ” or “BITMAP” parameter, so additional interpolation
is not needed. See discussion below.</li>
<li>Make sure that your tabulated forces and tabulated energies are
consistent (dE/dr = -F) over the entire range of r values. LAMMPS
will warn if this is not the case.</li>
<li>Use as large an inner cutoff as possible. This avoids fitting splines
to very steep parts of the potential.</li>
</ul>
<hr class="docutils" />
<p>The format of a tabulated file is a series of one or more sections,
defined as follows (without the parenthesized comments):</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># Morse potential for Fe (one or more comment or blank lines)</span>
<p>A section begins with a non-blank line whose 1st character is not a
“#”; blank lines or lines starting with “#” can be used as comments
between sections. The first line begins with a keyword which
identifies the section. The line can contain additional text, but the
initial text must match the argument specified in the pair_coeff
command. The next line lists (in any order) one or more parameters
for the table. Each parameter is a keyword followed by one or more
numeric values.</p>
<p>The parameter “N” is required and its value is the number of table
entries that follow. Note that this may be different than the <em>N</em>
specified in the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style table</span></a> command. Let
Ntable = <em>N</em> in the pair_style command, and Nfile = “N” in the
tabulated file. What LAMMPS does is a preliminary interpolation by
creating splines using the Nfile tabulated values as nodal points. It
uses these to interpolate energy and force values at Ntable different
points. The resulting tables of length Ntable are then used as
described above, when computing energy and force for individual pair
distances. This means that if you want the interpolation tables of
length Ntable to match exactly what is in the tabulated file (with
effectively no preliminary interpolation), you should set Ntable =
Nfile, and use the “RSQ” or “BITMAP” parameter. This is because the
internal table abscissa is always RSQ (separation distance squared),
for efficient lookup.</p>
<p>All other parameters are optional. If “R” or “RSQ” or “BITMAP” does
not appear, then the distances in each line of the table are used
as-is to perform spline interpolation. In this case, the table values
can be spaced in <em>r</em> uniformly or however you wish to position table
values in regions of large gradients.</p>
<p>If used, the parameters “R” or “RSQ” are followed by 2 values <em>rlo</em>
and <em>rhi</em>. If specified, the distance associated with each energy and
force value is computed from these 2 values (at high accuracy), rather
than using the (low-accuracy) value listed in each line of the table.
The distance values in the table file are ignored in this case.
For “R”, distances uniformly spaced between <em>rlo</em> and <em>rhi</em> are
computed; for “RSQ”, squared distances uniformly spaced between
<em>rlo*rlo</em> and <em>rhi*rhi</em> are computed.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you use “R” or “RSQ”, the tabulated distance values in the
file are effectively ignored, and replaced by new values as described
in the previous paragraph. If the distance value in the table is not
very close to the new value (i.e. round-off difference), then you will
be assingning energy/force values to a different distance, which is
probably not what you want. LAMMPS will warn if this is occurring.</p>
</div>
<p>If used, the parameter “BITMAP” is also followed by 2 values <em>rlo</em> and
<em>rhi</em>. These values, along with the “N” value determine the ordering
of the N lines that follow and what distance is associated with each.
This ordering is complex, so it is not documented here, since this
file is typically produced by the <a class="reference internal" href="pair_write.html"><span class="doc">pair_write</span></a> command
with its <em>bitmap</em> option. When the table is in BITMAP format, the “N”
parameter in the file must be equal to 2^M where M is the value
specified in the pair_style command. Also, a cutoff parameter cannot
be used as an optional 3rd argument in the pair_coeff command; the
entire table extent as specified in the file must be used.</p>
<p>If used, the parameter “FPRIME” is followed by 2 values <em>fplo</em> and
<em>fphi</em> which are the derivative of the force at the innermost and
outermost distances listed in the table. These values are needed by
the spline construction routines. If not specified by the “FPRIME”
parameter, they are estimated (less accurately) by the first 2 and
last 2 force values in the table. This parameter is not used by
BITMAP tables.</p>
<p>Following a blank line, the next N lines list the tabulated values.
On each line, the 1st value is the index from 1 to N, the 2nd value is
r (in distance units), the 3rd value is the energy (in energy units),
and the 4th is the force (in force units). The r values must increase
from one line to the next (unless the BITMAP parameter is specified).</p>
<p>Note that one file can contain many sections, each with a tabulated
potential. LAMMPS reads the file section by section until it finds
one that matches the specified keyword.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Style <em>table/rx</em> is used in reaction DPD simulations,where the
coarse-grained (CG) particles are composed of <em>m</em> species whose
reaction rate kinetics are determined from a set of <em>n</em> reaction rate
equations through the <a class="reference internal" href="fix_rx.html"><span class="doc">fix rx</span></a> command. The species of
one CG particle can interact with a species in a neighboring CG
particle through a site-site interaction potential model. Style
<em>table/rx</em> creates interpolation tables of length <em>N</em> from pair
potential and force values listed in a file(s) as a function of
distance. The files are read by the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a>
command.</p>
<p>The interpolation tables are created by fitting cubic splines to the
file values and interpolating energy and force values at each of <em>N</em>
distances. During a simulation, these tables are used to interpolate
energy and force values as needed. The interpolation is done in one
of 4 styles: <em>lookup</em>, <em>linear</em>, <em>spline</em>, or <em>bitmap</em>.</p>
<p>For the <em>lookup</em> style, the distance between 2 atoms is used to find
the nearest table entry, which is the energy or force.</p>
<p>For the <em>linear</em> style, the pair distance is used to find 2
surrounding table values from which an energy or force is computed by
linear interpolation.</p>
<p>For the <em>spline</em> style, a cubic spline coefficients are computed and
stored at each of the <em>N</em> values in the table. The pair distance is
used to find the appropriate set of coefficients which are used to
evaluate a cubic polynomial which computes the energy or force.</p>
<p>For the <em>bitmap</em> style, the N means to create interpolation tables
that are 2^N in length. The pair distance is used to index into the
table via a fast bit-mapping technique <a class="reference internal" href="#wolff"><span class="std std-ref">(Wolff)</span></a> and a linear
interpolation is performed between adjacent table values.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above.</p>
<ul class="simple">
<li>filename</li>
<li>keyword</li>
<li>species1</li>
<li>species2</li>
<li>cutoff (distance units)</li>
</ul>
<p>The filename specifies a file containing tabulated energy and force
values. The keyword specifies a section of the file. The cutoff is
an optional coefficient. If not specified, the outer cutoff in the
table itself (see below) will be used to build an interpolation table
that extend to the largest tabulated distance. If specified, only
file values up to the cutoff are used to create the interpolation
table. The format of this file is described below.</p>
<p>The species tags define the site-site interaction potential between
two species contained within two different particles. The species
tags must either correspond to the species defined in the reaction
kinetics files specified with the <a class="reference internal" href="fix_rx.html"><span class="doc">fix rx</span></a> command or they
must correspond to the tag “1fluid”, signifying interaction with a
product species mixture determined through a one-fluid approximation.
The interaction potential is weighted by the geometric average of the
concentrations of the two species. The coarse-grained potential is
stored before and after the reaction kinetics solver is applied, where
the difference is defined to be the internal chemical energy (uChem).</p>
<hr class="docutils" />
<p>Here are some guidelines for using the pair_style table/rx command to
best effect:</p>
<ul class="simple">
<li>Vary the number of table points; you may need to use more than you think
to get good resolution.</li>
<li>Always use the <a class="reference internal" href="pair_write.html"><span class="doc">pair_write</span></a> command to produce a plot
of what the final interpolated potential looks like. This can show up
interpolation “features” you may not like.</li>
<li>Start with the linear style; it’s the style least likely to have problems.</li>
<li>Use <em>N</em> in the pair_style command equal to the “N” in the tabulation
file, and use the “RSQ” or “BITMAP” parameter, so additional interpolation
is not needed. See discussion below.</li>
<li>Make sure that your tabulated forces and tabulated energies are consistent
(dE/dr = -F) along the entire range of r values.</li>
<li>Use as large an inner cutoff as possible. This avoids fitting splines
to very steep parts of the potential.</li>
</ul>
<hr class="docutils" />
<p>The format of a tabulated file is a series of one or more sections,
defined as follows (without the parenthesized comments):</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># Morse potential for Fe (one or more comment or blank lines)</span>
<p>This command is part of the USER-DPD package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The <em>tersoff</em> style computes a 3-body Tersoff potential
<a class="reference internal" href="pair_tersoff_zbl.html#tersoff-1"><span class="std std-ref">(Tersoff_1)</span></a> for the energy E of a system of atoms as</p>
specify Tersoff parameters for all permutations of the two elements
interacting in three-body configurations. Thus for 3 elements, 27
entries would be required, etc.</p>
<p>As annotated above, the first element in the entry is the center atom
in a three-body interaction and it is bonded to the 2nd atom and the
bond is influenced by the 3rd atom. Thus an entry for SiCC means Si
bonded to a C with another C atom influencing the bond. Thus
three-body parameters for SiCSi and SiSiC entries will not, in
general, be the same. The parameters used for the two-body
interaction come from the entry where the 2nd element is repeated.
Thus the two-body parameters for Si interacting with C, comes from the
SiCC entry.</p>
<p>The parameters used for a particular
three-body interaction come from the entry with the corresponding
three elements. The parameters used only for two-body interactions
(n, beta, lambda2, B, lambda1, and A) in entries whose 2nd and 3rd
element are different (e.g. SiCSi) are not used for anything and can
be set to 0.0 if desired.</p>
<p>Note that the twobody parameters in entries such as SiCC and CSiSi
are often the same, due to the common use of symmetric mixing rules,
but this is not always the case. For example, the beta and n parameters in
Tersoff_2 <a class="reference internal" href="pair_tersoff_zbl.html#tersoff-2"><span class="std std-ref">(Tersoff_2)</span></a> are not symmetric.</p>
<p>We chose the above form so as to enable users to define all commonly
used variants of the Tersoff potential. In particular, our form
reduces to the original Tersoff form when m = 3 and gamma = 1, while
it reduces to the form of <a class="reference internal" href="pair_tersoff_zbl.html#albe"><span class="std std-ref">Albe et al.</span></a> when beta = 1 and m = 1.
Note that in the current Tersoff implementation in LAMMPS, m must be
specified as either 3 or 1. Tersoff used a slightly different but
equivalent form for alloys, which we will refer to as Tersoff_2
<p>Tersoff_2 parameters R and S must be converted to the LAMMPS
parameters R and D (R is different in both forms), using the following
relations: R=(R’+S’)/2 and D=(S’-R’)/2, where the primes indicate the
Tersoff_2 parameters.</p>
<p>In the potentials directory, the file SiCGe.tersoff provides the
LAMMPS parameters for Tersoff’s various versions of Si, as well as his
alloy parameters for Si, C, and Ge. This file can be used for pure Si,
(three different versions), pure C, pure Ge, binary SiC, and binary
SiGe. LAMMPS will generate an error if this file is used with any
combination involving C and Ge, since there are no entries for the GeC
interactions (Tersoff did not publish parameters for this
cross-interaction.) Tersoff files are also provided for the SiC alloy
(SiC.tersoff) and the GaN (GaN.tersoff) alloys.</p>
<p>Many thanks to Rutuparna Narulkar, David Farrell, and Xiaowang Zhou
for helping clarify how Tersoff parameters for alloys have been
defined in various papers.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The three Si arguments map LAMMPS atom types 1,2,3 to the Si element
in the Tersoff/MOD file. If a mapping value is specified as NULL, the
mapping is not performed. This can be used when a <em>tersoff/mod</em>
potential is used as part of the <em>hybrid</em> pair style. The NULL values
are placeholders for atom types that will be used with other
potentials.</p>
<p>Tersoff/MOD file in the <em>potentials</em> directory of the LAMMPS
distribution have a ”.tersoff.mod” suffix. Lines that are not blank
or comments (starting with #) define parameters for a triplet of
elements. The parameters in a single entry correspond to coefficients
in the formula above:</p>
<ul class="simple">
<li>element 1 (the center atom in a 3-body interaction)</li>
<li>element 2 (the atom bonded to the center atom)</li>
<li>element 3 (the atom influencing the 1-2 bond in a bond-order sense)</li>
<li>beta</li>
<li>alpha</li>
<li>h</li>
<li>eta</li>
<li>beta_ters = 1 (dummy parameter)</li>
<li>lambda2 (1/distance units)</li>
<li>B (energy units)</li>
<li>R (distance units)</li>
<li>D (distance units)</li>
<li>lambda1 (1/distance units)</li>
<li>A (energy units)</li>
<li>n</li>
<li>c1</li>
<li>c2</li>
<li>c3</li>
<li>c4</li>
<li>c5</li>
</ul>
<p>The n, eta, lambda2, B, lambda1, and A parameters are only used for
two-body interactions. The beta, alpha, c1, c2, c3, c4, c5, h
parameters are only used for three-body interactions. The R and D
parameters are used for both two-body and three-body interactions. The
non-annotated parameters are unitless.</p>
<p>The Tersoff/MOD potential file must contain entries for all the elements
listed in the pair_coeff command. It can also contain entries for
additional elements not being used in a particular simulation; LAMMPS
ignores those entries.</p>
<p>For a single-element simulation, only a single entry is required
(e.g. SiSiSi). As annotated above, the first element in the entry is
the center atom in a three-body interaction and it is bonded to the
2nd atom and the bond is influenced by the 3rd atom. Thus an entry
for SiSiSi means Si bonded to a Si with another Si atom influencing the bond.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Tersoff_2 parameters R and S must be converted to the LAMMPS
parameters R and D (R is different in both forms), using the following
relations: R=(R’+S’)/2 and D=(S’-R’)/2, where the primes indicate the
Tersoff_2 parameters.</p>
<p>In the potentials directory, the file SiCGe.tersoff provides the
LAMMPS parameters for Tersoff’s various versions of Si, as well as his
alloy parameters for Si, C, and Ge. This file can be used for pure Si,
(three different versions), pure C, pure Ge, binary SiC, and binary
SiGe. LAMMPS will generate an error if this file is used with any
combination involving C and Ge, since there are no entries for the GeC
interactions (Tersoff did not publish parameters for this
cross-interaction.) Tersoff files are also provided for the SiC alloy
(SiC.tersoff) and the GaN (GaN.tersoff) alloys.</p>
<p>Many thanks to Rutuparna Narulkar, David Farrell, and Xiaowang Zhou
for helping clarify how Tersoff parameters for alloys have been
defined in various papers. Also thanks to Ram Devanathan for
providing the base ZBL implementation.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The <em>thole</em> pair styles are meant to be used with force fields that
include explicit polarization through Drude dipoles. This link
describes how to use the <a class="reference internal" href="tutorial_drude.html"><span class="doc">thermalized Drude oscillator model</span></a> in LAMMPS and polarizable models in LAMMPS
are discussed in <a class="reference internal" href="Section_howto.html#howto-25"><span class="std std-ref">this Section</span></a>.</p>
<p>The <em>thole</em> pair style should be used as a sub-style within in the
<a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_hybrid/overlay</span></a> command, in conjunction with a
main pair style including Coulomb interactions, i.e. any pair style
containing <em>coul/cut</em> or <em>coul/long</em> in its style name.</p>
<p>The <em>lj/cut/thole/long</em> pair style is equivalent to, but more convenient that
the frequent combination <em>hybrid/overlay lj/cut/coul/long cutoff thole damp
cutoff2</em>. It is not only a shorthand for this pair_style combination, but
it also allows for mixing pair coefficients instead of listing them all.
The <em>lj/cut/thole/long</em> pair style is also a bit faster because it avoids an
overlay and can benefit from OMP acceleration. Moreover, it uses a more
precise approximation of the direct Coulomb interaction at short range similar
to <a class="reference internal" href="pair_cs.html"><span class="doc">coul/long/cs</span></a>, which stabilizes the temperature of
Drude particles.</p>
<p>The <em>thole</em> pair styles compute the Coulomb interaction damped at
<p>This function results from an adaptation to point charges
-<a class="reference internal" href="#noskov"><span class="std std-ref">(Noskov)</span></a> of the dipole screening scheme originally proposed
-by <a class="reference internal" href="#thole"><span class="std std-ref">Thole</span></a>. The scaling coefficient <span class="math">\(s_{ij}\)</span> is determined
+<a class="reference internal" href="tutorial_drude.html#noskov"><span class="std std-ref">(Noskov)</span></a> of the dipole screening scheme originally proposed
+by <a class="reference internal" href="tutorial_drude.html#thole"><span class="std std-ref">Thole</span></a>. The scaling coefficient <span class="math">\(s_{ij}\)</span> is determined
by the polarizability of the atoms, <span class="math">\(\alpha_i\)</span>, and by a Thole
damping parameter <span class="math">\(a\)</span>. This Thole damping parameter usually takes
a value of 2.6, but in certain force fields the value can depend upon
the atom types. The mixing rule for Thole damping parameters is the
arithmetic average, and for polarizabilities the geometric average
<p>The damping function is only applied to the interactions between the
point charges representing the induced dipoles on polarizable sites,
that is, charges on Drude particles, <span class="math">\(q_{D,i}\)</span>, and opposite
charges, <span class="math">\(-q_{D,i}\)</span>, located on the respective core particles
(to which each Drude particle is bonded). Therefore, Thole screening
is not applied to the full charge of the core particle <span class="math">\(q_i\)</span>, but
only to the <span class="math">\(-q_{D,i}\)</span> part of it.</p>
<p>The interactions between core charges are subject to the weighting
factors set by the <a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command. The
interactions between Drude particles and core charges or
non-polarizable atoms are also subject to these weighting factors. The
Drude particles inherit the 1-2, 1-3 and 1-4 neighbor relations from
their respective cores.</p>
<p>For pair_style <em>thole</em>, the following coefficients must be defined for
each pair of atoms types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command
as in the example above.</p>
<ul class="simple">
<li>alpha (distance units^3)</li>
<li>damp</li>
<li>cutoff (distance units)</li>
</ul>
<p>The last two coefficients are optional. If not specified the global
Thole damping parameter or global cutoff specified in the pair_style
command are used. In order to specify a cutoff (third argument) a damp
parameter (second argument) must also be specified.</p>
<p>For pair style <em>lj/cut/thole/long</em>, the following coefficients must be
defined for each pair of atoms types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a>
command.</p>
<ul class="simple">
<li>epsilon (energy units)</li>
<li>sigma (length units)</li>
<li>alpha (distance units^3)</li>
<li>damps</li>
<li>LJ cutoff (distance units)</li>
</ul>
<p>The last two coefficients are optional and default to the global values from
the <em>pair_style</em> command line.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p><strong>Mixing</strong>:</p>
<p>The <em>thole</em> pair style does not support mixing. Thus, coefficients
for all I,J pairs must be specified explicitly.</p>
<p>The <em>lj/cut/thole/long</em> pair style does support mixing. Mixed coefficients
<p>These pair styles are part of the USER-DRUDE package. They are only
enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This pair_style should currently not be used with the <a class="reference internal" href="dihedral_charmm.html"><span class="doc">charmm dihedral style</span></a> if the latter has non-zero 1-4 weighting
factors. This is because the <em>thole</em> pair style does not know which
pairs are 1-4 partners of which dihedrals.</p>
<p>The <em>lj/cut/thole/long</em> pair style should be used with a <a class="reference internal" href="kspace_style.html"><span class="doc">Kspace solver</span></a>
like PPPM or Ewald, which is only enabled if LAMMPS was built with the kspace
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of this pair style can be mixed. The
default mix value is <em>geometric</em>. See the “pair_modify” command for
details.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>This style is part of the ASPHERE package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Defining particles to be triangles so they participate in tri/tri or
tri/particle interactions requires the use the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style tri</span></a> command.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
specify parameters for all permutations of the two elements
interacting in three-body configurations. Thus for 3 elements, 27
entries would be required, etc.</p>
<p>Depending on the particular version of the Vashishta potential,
the values of these parameters may be keyed to the identities of
zero, one, two, or three elements.
In order to make the input file format unambiguous, general,
and simple to code,
LAMMPS uses a slightly confusing method for specifying parameters.
All parameters are divided into two classes: two-body and three-body.
Two-body and three-body parameters are handled differently,
as described below.
The two-body parameters are H, eta, lambda1, D, lambda4, W, rc, gamma, and r0.
They appear in the above formulae with two subscripts.
The parameters Zi and Zj are also classified as two-body parameters,
even though they only have 1 subscript.
The three-body parameters are B, C, costheta0.
They appear in the above formulae with three subscripts.
Two-body and three-body parameters are handled differently,
as described below.</p>
<p>The first element in each entry is the center atom
in a three-body interaction, while the second and third elements
are two neighbor atoms. Three-body parameters for a central atom I
and two neighbors J and K are taken from the IJK entry.
Note that even though three-body parameters do not depend on the order of
J and K, LAMMPS stores three-body parameters for both IJK and IKJ.
The user must ensure that these values are equal.
Two-body parameters for an atom I interacting with atom J are taken from
the IJJ entry, where the 2nd and 3rd
elements are the same. Thus the two-body parameters
for Si interacting with C come from the SiCC entry. Note that even
though two-body parameters (except possibly gamma and r0 in U3)
do not depend on the order of the two elements,
LAMMPS will get the Si-C value from the SiCC entry
and the C-Si value from the CSiSi entry. The user must ensure
that these values are equal. Two-body parameters appearing
in entries where the 2nd and 3rd elements are different are
stored but never used. It is good practice to enter zero for
these values. Note that the three-body function U3 above
contains the two-body parameters gamma and r0. So U3 for a
central C atom bonded to an Si atom and a second C atom
will take three-body parameters from the CSiC entry, but
two-body parameters from the CCC and CSiSi entries.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The last coefficient is optional. If not specified, the global yukawa
cutoff is used.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The last coefficient is optional. If not specified, the global
yukawa/colloid cutoff is used.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>This style is part of the COLLOID package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This pair style requires that atoms be finite-size spheres with a
diameter, as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style sphere</span></a>
command.</p>
<p>Per-particle polydispersity is not yet supported by this pair style;
per-type polydispersity is allowed. This means all particles of the
same type must have the same diameter. Each type can have a different
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where e is the electron charge, epsilon_0 is the electrical
permittivity of vacuum, and Z_i and Z_j are the nuclear charges of the
two atoms. The switching function S(r) is identical to that used by
<a class="reference internal" href="pair_gromacs.html"><span class="doc">pair_style lj/gromacs</span></a>. Here, the inner and outer
cutoff are the same for all pairs of atom types.</p>
<p>The following coefficients must be defined for each pair of atom types
via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples above,
or in the LAMMPS data file.</p>
<ul class="simple">
<li>Z_i (atomic number for first atom type, e.g. 13.0 for aluminum)</li>
<li>Z_j (ditto for second atom type)</li>
</ul>
<p>The values of Z_i and Z_j are normally equal to the atomic
numbers of the two atom types. Thus, the user may optionally
specify only the coefficients for each I==I pair, and rely
on the obvious mixing rule for cross interactions (see below).
Note that when I==I it is required that Z_i == Z_j. When used
with <a class="reference internal" href="pair_hybrid.html"><span class="doc">hybrid/overlay</span></a> and pairs are assigned
to more than one sub-style, the mixing rule is not used and
each pair of types interacting with the ZBL sub-style must
be included in a pair_coeff command.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The numerical values of the exponential decay constants in the
screening function depend on the unit of distance. In the above
equation they are given for units of angstroms. LAMMPS will
automatically convert these values to the distance unit of the
specified LAMMPS <a class="reference internal" href="units.html"><span class="doc">units</span></a> setting. The values of Z should
always be given as multiples of a proton’s charge, e.g. 29.0 for
copper.</p>
</div>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> 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 in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the Z_i and Z_j coefficients
can be mixed by taking Z_i and Z_j from the values specified for
I == I and J == J cases. When used
with <a class="reference internal" href="pair_hybrid.html"><span class="doc">hybrid/overlay</span></a> and pairs are assigned
to more than one sub-style, the mixing rule is not used and
each pair of types interacting with the ZBL sub-style
must be included in a pair_coeff command.
The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> mix option has no effect on
the mixing behavior</p>
<p>The ZBL pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option, since the ZBL interaction is already smoothed to 0.0 at
the cutoff.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant for
this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure, since there are no corrections for a potential that goes to
0.0 at the cutoff.</p>
<p>This pair style does not write information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands must be
specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Run a parallel replica dynamics (PRD) simulation using multiple
replicas of a system. One or more replicas can be used. The total
number of steps <em>N</em> to run can be interpreted in one of two ways; see
discussion of the <em>time</em> keyword below.</p>
<p>PRD is described in <a class="reference internal" href="tad.html#voter"><span class="std std-ref">this paper</span></a> by Art Voter. It is a method
for performing accelerated dynamics that is suitable for
infrequent-event systems that obey first-order kinetics. A good
overview of accelerated dynamics methods for such systems in given in
<a class="reference internal" href="tad.html#voter2"><span class="std std-ref">this review paper</span></a> from the same group. To quote from the
paper: “The dynamical evolution is characterized by vibrational
excursions within a potential basin, punctuated by occasional
transitions between basins.” The transition probability is
characterized by p(t) = k*exp(-kt) where k is the rate constant.
Running multiple replicas gives an effective enhancement in the
timescale spanned by the multiple simulations, while waiting for an
event to occur.</p>
<p>Each replica runs on a partition of one or more processors. Processor
partitions are defined at run-time using the -partition command-line
switch; see <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">Section_start 6</span></a> of the
manual. Note that if you have MPI installed, you can run a
multi-replica simulation with more replicas (partitions) than you have
physical processors, e.g you can run a 10-replica simulation on one or
two processors. For PRD, this makes little sense, since this offers
no effective parallel speed-up in searching for infrequent events. See
<a class="reference internal" href="Section_howto.html#howto-5"><span class="std std-ref">Section_howto 5</span></a> of the manual for further
discussion.</p>
<p>When a PRD simulation is performed, it is assumed that each replica is
running the same model, though LAMMPS does not check for this.
I.e. the simulation domain, the number of atoms, the interaction
potentials, etc should be the same for every replica.</p>
<p>A PRD run has several stages, which are repeated each time an “event”
occurs in one of the replicas, as defined below. The logic for a PRD
<p>Before this loop begins, the state of the system on replica 0 is
shared with all replicas, so that all replicas begin from the same
initial state. The first potential energy basin is identified by
quenching (an energy minimization, see below) the initial state and
storing the resulting coordinates for reference.</p>
<p>In the first stage, dephasing is performed by each replica
independently to eliminate correlations between replicas. This is
done by choosing a random set of velocities, based on the
<em>random_seed</em> that is specified, and running <em>t_dephase</em> timesteps of
dynamics. This is repeated <em>n_dephase</em> times. At each of the
<em>n_dephase</em> stages, if an event occurs during the <em>t_dephase</em> steps of
dynamics for a particular replica, the replica repeats the stage until
no event occurs.</p>
<p>If the <em>temp</em> keyword is not specified, the target temperature for
velocity randomization for each replica is the current temperature of
that replica. Otherwise, it is the specified <em>Tdephase</em> temperature.
The style of velocity randomization is controlled using the keyword
<em>vel</em> with arguments that have the same meaning as their counterparts
in the <a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> command.</p>
<p>In the second stage, each replica runs dynamics continuously, stopping
every <em>t_event</em> steps to check if a transition event has occurred.
This check is performed by quenching the system and comparing the
resulting atom coordinates to the coordinates from the previous basin.
The first time through the PRD loop, the “previous basin” is the set
of quenched coordinates from the initial state of the system.</p>
<p>A quench is an energy minimization and is performed by whichever
algorithm has been defined by the <a class="reference internal" href="min_style.html"><span class="doc">min_style</span></a> command.
Minimization parameters may be set via the
<a class="reference internal" href="min_modify.html"><span class="doc">min_modify</span></a> command and by the <em>min</em> keyword of the
PRD command. The latter are the settings that would be used with the
<a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command. Note that typically, you do not
need to perform a highly-converged minimization to detect a transition
event.</p>
<p>The event check is performed by a compute with the specified
<em>compute-ID</em>. Currently there is only one compute that works with the
PRD commmand, which is the <a class="reference internal" href="compute_event_displace.html"><span class="doc">compute event/displace</span></a> command. Other
event-checking computes may be added. <a class="reference internal" href="compute_event_displace.html"><span class="doc">Compute event/displace</span></a> checks whether any atom in
the compute group has moved further than a specified threshold
distance. If so, an “event” has occurred.</p>
<p>In the third stage, the replica on which the event occurred (event
replica) continues to run dynamics to search for correlated events.
This is done by running dynamics for <em>t_correlate</em> steps, quenching
every <em>t_event</em> steps, and checking if another event has occurred.</p>
<p>The first time no correlated event occurs, the final state of the
event replica is shared with all replicas, the new basin reference
coordinates are updated with the quenched state, and the outer loop
begins again. While the replica event is searching for correlated
events, all the other replicas also run dynamics and event checking
with the same schedule, but the final states are always overwritten by
the state of the event replica.</p>
<p>The outer loop of the pseudo-code above continues until <em>N</em> steps of
dynamics have been performed. Note that <em>N</em> only includes the
dynamics of stages 2 and 3, not the steps taken during dephasing or
the minimization iterations of quenching. The specified <em>N</em> is
interpreted in one of two ways, depending on the <em>time</em> keyword. If
the <em>time</em> value is <em>steps</em>, which is the default, then each replica
runs for <em>N</em> timesteps. If the <em>time</em> value is <em>clock</em>, then the
simulation runs until <em>N</em> aggregate timesteps across all replicas have
elapsed. This aggregate time is the “clock” time defined below, which
typically advances nearly M times faster than the timestepping on a
single replica.</p>
<hr class="docutils" />
<p>Four kinds of output can be generated during a PRD run: event
statistics, thermodynamic output by each replica, dump files, and
restart files.</p>
<p>When running with multiple partitions (each of which is a replica in
this case), the print-out to the screen and master log.lammps file is
limited to event statistics. Note that if a PRD run is performed on
only a single replica then the event statistics will be intermixed
with the usual thermodynamic output discussed below.</p>
<p>The quantities printed each time an event occurs are the timestep, CPU
time, clock, event number, a correlation flag, the number of
coincident events, and the replica number of the chosen event.</p>
<p>The timestep is the usual LAMMPS timestep, except that time does not
advance during dephasing or quenches, but only during dynamics. Note
that are two kinds of dynamics in the PRD loop listed above. The
first is when all replicas are performing independent dynamics,
waiting for an event to occur. The second is when correlated events
are being searched for and only one replica is running dynamics.</p>
<p>The CPU time is the total processor time since the start of the PRD
run.</p>
<p>The clock is the same as the timestep except that it advances by M
steps every timestep during the first kind of dynamics when the M
replicas are running independently. The clock advances by only 1 step
per timestep during the second kind of dynamics, since only a single
replica is checking for a correlated event. Thus “clock” time
represents the aggregate time (in steps) that effectively elapses
during a PRD simulation on M replicas. If most of the PRD run is
spent in the second stage of the loop above, searching for infrequent
events, then the clock will advance nearly M times faster than it
would if a single replica was running. Note the clock time between
events will be drawn from p(t).</p>
<p>The event number is a counter that increments with each event, whether
it is uncorrelated or correlated.</p>
<p>The correlation flag will be 0 when an uncorrelated event occurs
during the second stage of the loop listed above, i.e. when all
replicas are running independently. The correlation flag will be 1
when a correlated event occurs during the third stage of the loop
listed above, i.e. when only one replica is running dynamics.</p>
<p>When more than one replica detects an event at the end of the second
stage, then one of them is chosen at random. The number of coincident
events is the number of replicas that detected an event. Normally, we
expect this value to be 1. If it is often greater than 1, then either
the number of replicas is too large, or <em>t_event</em> is too large.</p>
<p>The replica number is the ID of the replica (from 0 to M-1) that
found the event.</p>
<hr class="docutils" />
<p>When running on multiple partitions, LAMMPS produces additional log
files for each partition, e.g. log.lammps.0, log.lammps.1, etc. For
the PRD command, these contain the thermodynamic output for each
replica. You will see short runs and minimizations corresponding to
the dynamics and quench operations of the loop listed above. The
timestep will be reset aprpopriately depending on whether the
operation advances time or not.</p>
<p>After the PRD command completes, timing statistics for the PRD run are
printed in each replica’s log file, giving a breakdown of how much CPU
time was spent in each stage (dephasing, dynamics, quenching, etc).</p>
<hr class="docutils" />
<p>Any <a class="reference internal" href="dump.html"><span class="doc">dump files</span></a> defined in the input script, will be
written to during a PRD run at timesteps corresponding to both
uncorrelated and correlated events. This means the the requested dump
frequency in the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command is ignored. There will be
one dump file (per dump command) created for all partitions.</p>
<p>The atom coordinates of the dump snapshot are those of the minimum
energy configuration resulting from quenching following a transition
event. The timesteps written into the dump files correspond to the
timestep at which the event occurred and NOT the clock. A dump
snapshot corresponding to the initial minimum state used for event
detection is written to the dump file at the beginning of each PRD
run.</p>
<hr class="docutils" />
<p>If the <a class="reference internal" href="restart.html"><span class="doc">restart</span></a> command is used, a single restart file
for all the partitions is generated, which allows a PRD run to be
continued by a new input script in the usual manner.</p>
<p>The restart file is generated at the end of the loop listed above. If
no correlated events are found, this means it contains a snapshot of
the system at time T + <em>t_correlate</em>, where T is the time at which the
uncorrelated event occurred. If correlated events were found, then it
contains a snapshot of the system at time T + <em>t_correlate</em>, where T
is the time of the last correlated event.</p>
<p>The restart frequency specified in the <a class="reference internal" href="restart.html"><span class="doc">restart</span></a> command
is interpreted differently when performing a PRD run. It does not
mean the timestep interval between restart files. Instead it means an
event interval for uncorrelated events. Thus a frequency of 1 means
write a restart file every time an uncorrelated event occurs. A
frequency of 10 means write a restart file every 10th uncorrelated
event.</p>
<p>When an input script reads a restart file from a previous PRD run, the
new script can be run on a different number of replicas or processors.
However, it is assumed that <em>t_correlate</em> in the new PRD command is
the same as it was previously. If not, the calculation of the “clock”
value for the first event in the new run will be slightly off.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This command can only be used if LAMMPS was built with the REPLICA
package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
for more info on packages.</p>
<p><em>N</em> and <em>t_correlate</em> settings must be integer multiples of
<em>t_event</em>.</p>
<p>Runs restarted from restart file written during a PRD run will not
produce identical results due to changes in the random numbers used
for dephasing.</p>
<p>This command cannot be used when any fixes are defined that keep track
of elapsed time to perform time-dependent operations. Examples
include the “ave” fixes such as <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a>.
Also <a class="reference internal" href="fix_dt_reset.html"><span class="doc">fix dt/reset</span></a> and <a class="reference internal" href="fix_deposit.html"><span class="doc">fix deposit</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>Px,Py,Pz = # of processors in each dimension of 3d grid overlaying the simulation domain</li>
<li>zero or more keyword/arg pairs may be appended</li>
<li>keyword = <em>grid</em> or <em>map</em> or <em>part</em> or <em>file</em></li>
</ul>
<pre class="literal-block">
<em>grid</em> arg = gstyle params ...
gstyle = <em>onelevel</em> or <em>twolevel</em> or <em>numa</em> or <em>custom</em>
onelevel params = none
twolevel params = Nc Cx Cy Cz
Nc = number of cores per node
Cx,Cy,Cz = # of cores in each dimension of 3d sub-grid assigned to each node
numa params = none
custom params = infile
infile = file containing grid layout
<em>map</em> arg = <em>cart</em> or <em>cart/reorder</em> or <em>xyz</em> or <em>xzy</em> or <em>yxz</em> or <em>yzx</em> or <em>zxy</em> or <em>zyx</em>
cart = use MPI_Cart() methods to map processors to 3d grid with reorder = 0
cart/reorder = use MPI_Cart() methods to map processors to 3d grid with reorder = 1
xyz,xzy,yxz,yzx,zxy,zyx = map procesors to 3d grid in IJK ordering
<em>numa</em> arg = none
<em>part</em> args = Psend Precv cstyle
Psend = partition # (1 to Np) which will send its processor layout
Precv = partition # (1 to Np) which will recv the processor layout
cstyle = <em>multiple</em>
<em>multiple</em> = Psend grid will be multiple of Precv grid in each dimension
<em>file</em> arg = outfile
outfile = name of file to write 3d grid of processors to
<p>Specify how processors are mapped as a regular 3d grid to the global
simulation box. The mapping involves 2 steps. First if there are P
processors it means choosing a factorization P = Px by Py by Pz so
that there are Px processors in the x dimension, and similarly for the
y and z dimensions. Second, the P processors are mapped to the
regular 3d grid. The arguments to this command control each of these
2 steps.</p>
<p>The Px, Py, Pz parameters affect the factorization. Any of the 3
parameters can be specified with an asterisk “*”, which means LAMMPS
will choose the number of processors in that dimension of the grid.
It will do this based on the size and shape of the global simulation
box so as to minimize the surface-to-volume ratio of each processor’s
sub-domain.</p>
<p>Choosing explicit values for Px or Py or Pz can be used to override
the default manner in which LAMMPS will create the regular 3d grid of
processors, if it is known to be sub-optimal for a particular problem.
E.g. a problem where the extent of atoms will change dramatically in a
particular dimension over the course of the simulation.</p>
<p>The product of Px, Py, Pz must equal P, the total # of processors
LAMMPS is running on. For a <a class="reference internal" href="dimension.html"><span class="doc">2d simulation</span></a>, Pz must
equal 1.</p>
<p>Note that if you run on a prime number of processors P, then a grid
such as 1 x P x 1 will be required, which may incur extra
communication costs due to the high surface area of each processor’s
sub-domain.</p>
<p>Also note that if multiple partitions are being used then P is the
number of processors in this partition; see <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">this section</span></a> for an explanation of the
-partition command-line switch. Also note that you can prefix the
processors command with the <a class="reference internal" href="partition.html"><span class="doc">partition</span></a> command to
easily specify different Px,Py,Pz values for different partitions.</p>
<p>You can use the <a class="reference internal" href="partition.html"><span class="doc">partition</span></a> command to specify
different processor grids for different partitions, e.g.</p>
<p>Note that, in principle, an MPI implementation on a particular machine
should be aware of both the machine’s network topology and the
specific subset of processors and nodes that were assigned to your
simulation. Thus its MPI_Cart calls can optimize the assignment of
MPI processes to the 3d grid to minimize communication costs. In
practice, however, few if any MPI implementations actually do this.
So it is likely that the <em>cart</em> and <em>cart/reorder</em> styles simply give
the same result as one of the IJK styles.</p>
<p>Also note, that for the <em>twolevel</em> grid style, the <em>map</em> setting is
used to first map the nodes to the 3d grid, then again to the cores
within each node. For the latter step, the <em>cart</em> and <em>cart/reorder</em>
styles are not supported, so an <em>xyz</em> style is used in their place.</p>
<hr class="docutils" />
<p>The <em>part</em> keyword affects the factorization of P into Px,Py,Pz.</p>
<p>It can be useful when running in multi-partition mode, e.g. with the
<a class="reference internal" href="run_style.html"><span class="doc">run_style verlet/split</span></a> command. It specifies a
dependency bewteen a sending partition <em>Psend</em> and a receiving
partition <em>Precv</em> which is enforced when each is setting up their own
mapping of their processors to the simulation box. Each of <em>Psend</em>
and <em>Precv</em> must be integers from 1 to Np, where Np is the number of
partitions you have defined via the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-partition command-line switch</span></a>.</p>
<p>A “dependency” means that the sending partition will create its
regular 3d grid as Px by Py by Pz and after it has done this, it will
send the Px,Py,Pz values to the receiving partition. The receiving
partition will wait to receive these values before creating its own
regular 3d grid and will use the sender’s Px,Py,Pz values as a
constraint. The nature of the constraint is determined by the
<em>cstyle</em> argument.</p>
<p>For a <em>cstyle</em> of <em>multiple</em>, each dimension of the sender’s processor
grid is required to be an integer multiple of the corresponding
dimension in the receiver’s processor grid. This is a requirement of
the <a class="reference internal" href="run_style.html"><span class="doc">run_style verlet/split</span></a> command.</p>
<p>For example, assume the sending partition creates a 4x6x10 grid = 240
processor grid. If the receiving partition is running on 80
processors, it could create a 4x2x10 grid, but it will not create a
2x4x10 grid, since in the y-dimension, 6 is not an integer multiple of
4.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you use the <a class="reference internal" href="partition.html"><span class="doc">partition</span></a> command to invoke
different “processsors” commands on different partitions, and you also
use the <em>part</em> keyword, then you must insure that both the sending and
receiving partitions invoke the “processors” command that connects the
2 partitions via the <em>part</em> keyword. LAMMPS cannot easily check for
this, but your simulation will likely hang in its setup phase if this
error has been made.</p>
</div>
<hr class="docutils" />
<p>The <em>file</em> keyword writes the mapping of the factorization of P
processors and their mapping to the 3d grid to the specified file
<em>outfile</em>. This is useful to check that you assigned physical
processors in the manner you desired, which can be tricky to figure
out, especially when running on multiple partitions or on, a multicore
machine or when the processor ranks were reordered by use of the
<a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-reorder command-line switch</span></a> or due to
use of MPI-specific launch options such as a config file.</p>
<p>If you have multiple partitions you should insure that each one writes
to a different file, e.g. using a <a class="reference internal" href="variable.html"><span class="doc">world-style variable</span></a>
for the filename. The file has a self-explanatory header, followed by
one-line per processor in this format:</p>
<p>world-ID universe-ID original-ID: I J K: name</p>
<p>The IDs are the processor’s rank in this simulation (the world), the
universe (of multiple simulations), and the original MPI communicator
used to instantiate LAMMPS, respectively. The world and universe IDs
will only be different if you are running on more than one partition;
see the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-partition command-line switch</span></a>.
The universe and original IDs will only be different if you used the
<a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-reorder command-line switch</span></a> to reorder
the processors differently than their rank in the original
communicator LAMMPS was instantiated with.</p>
<p>I,J,K are the indices of the processor in the regular 3d grid, each
from 1 to Nd, where Nd is the number of processors in that dimension
of the grid.</p>
<p>The <em>name</em> is what is returned by a call to MPI_Get_processor_name()
and should represent an identifier relevant to the physical processors
in your machine. Note that depending on the MPI implementation,
multiple cores can have the same <em>name</em>.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This command cannot be used after the simulation box is defined by a
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+python myMultiply return v_foo format f file funcs.py
+</pre>
<p>The two commands can appear in either order in the input script so
long as both are specified before the Python function is invoked for
the first time.</p>
<p>The <em>format</em> keyword must be used if the <em>input</em> or <em>return</em> keyword
is used. It defines an <em>fstring</em> with M characters, where M = sum of
number of inputs and outputs. The order of characters corresponds to
the N inputs, followed by the return value (if it exists). Each
character must be one of the following: “i” for integer, “f” for
floating point, “s” for string, or “p” for SELF. Each character
defines the type of the corresponding input or output value of the
Python function and affects the type conversion that is performed
internally as data is passed back and forth between LAMMPS and Python.
Note that it is permissible to use a <a class="reference internal" href="variable.html"><span class="doc">python-style variable</span></a> in a LAMMPS command that allows for an
equal-style variable as an argument, but only if the output of the
Python function is flagged as a numeric value (“i” or “f”) via the
<em>format</em> keyword.</p>
<p>Either the <em>file</em>, <em>here</em>, or <em>exists</em> keyword must be used, but only
one of them. These keywords specify what Python code to load into the
Python interpreter. The <em>file</em> keyword gives the name of a file,
which should end with a ”.py” suffix, which contains Python code. The
code will be immediately loaded into and run in the “main” module of
the Python interpreter. Note that Python code which contains a
function definition does not “execute” the function when it is run; it
simply defines the function so that it can be invoked later.</p>
<p>The <em>here</em> keyword does the same thing, except that the Python code
follows as a single argument to the <em>here</em> keyword. This can be done
using triple quotes as delimiters, as in the examples above. This
allows Python code to be listed verbatim in your input script, with
proper indentation, blank lines, and comments, as desired. See
<a class="reference internal" href="Section_commands.html#cmd-2"><span class="std std-ref">Section 3.2</span></a>, for an explanation of how
triple quotes can be used as part of input script syntax.</p>
<p>The <em>exists</em> keyword takes no argument. It means that Python code
containing the required Python function defined by the <em>func</em> setting,
is assumed to have been previously loaded by another python command.</p>
<p>Note that the Python code that is loaded and run must contain a
function with the specified <em>func</em> name. To operate properly when
later invoked, the the function code must match the <em>input</em> and
<em>return</em> and <em>format</em> keywords specified by the python command.
Otherwise Python will generate an error.</p>
<hr class="docutils" />
<p>This section describes how Python code can be written to work with
LAMMPS.</p>
<p>Whether you load Python code from a file or directly from your input
script, via the <em>file</em> and <em>here</em> keywords, the code can be identical.
It must be indented properly as Python requires. It can contain
comments or blank lines. If the code is in your input script, it
cannot however contain triple-quoted Python strings, since that will
conflict with the triple-quote parsing that the LAMMPS input script
performs.</p>
<p>All the Python code you specify via one or more python commands is
loaded into the Python “main” module, i.e. __main__. The code can
define global variables or statements that are outside of function
definitions. It can contain multiple functions, only one of which
matches the <em>func</em> setting in the python command. This means you can
use the <em>file</em> keyword once to load several functions, and the
<em>exists</em> keyword thereafter in subsequent python commands to access
the other functions previously loaded.</p>
<p>A Python function you define (or more generally, the code you load)
can import other Python modules or classes, it can make calls to other
system functions or functions you define, and it can access or modify
global variables (in the “main” module) which will persist between
successive function calls. The latter can be useful, for example, to
prevent a function from being invoke multiple times per timestep by
different commands in a LAMMPS input script that access the returned
python-style variable associated with the function. For example,
consider this function loaded with two global variables defined
<p>Several LAMMPS library functions are called from the loop function.
Get_natoms() returns the number of atoms in the simulation, so that it
can be used to normalize the potential energy that is returned by
extract_compute() for the “thermo_pe” compute that is defined by
default for LAMMPS thermodynamic output. Set_variable() sets the
value of a string variable defined in LAMMPS. This library function
is a useful way for a Python function to return multiple values to
LAMMPS, more than the single value that can be passed back via a
return statement. This cutoff value in the “cut” variable is then
substituted (by LAMMPS) in the pair_style command that is executed
next. Alternatively, the “LAMMPS command option” line could be used
in place of the 2 preceeding lines, to have Python insert the value
into the LAMMPS command string.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When using the callback mechanism just described, recognize that
there are some operations you should not attempt because LAMMPS cannot
execute them correctly. If the Python function is invoked between
runs in the LAMMPS input script, then it should be OK to invoke any
LAMMPS input script command via the library interface command() or
file() functions, so long as the command would work if it were
executed in the LAMMPS input script directly at the same point.</p>
</div>
<p>However, a Python function can also be invoked during a run, whenever
an associated LAMMPS variable it is assigned to is evaluted. If the
variable is an input argument to another LAMMPS command (e.g. <a class="reference internal" href="fix_setforce.html"><span class="doc">fix setforce</span></a>), then the Python function will be invoked
inside the class for that command, in one of its methods that is
invoked in the middle of a timestep. You cannot execute arbitrary
input script commands from the Python function (again, via the
command() or file() functions) at that point in the run and expect it
to work. Other library functions such as those that invoke computes
or other variables may have hidden side effects as well. In these
cases, LAMMPS has no simple way to check that something illogical is
being attempted.</p>
<hr class="docutils" />
<p>If you run Python code directly on your workstation, either
interactively or by using Python to launch a Python script stored in a
file, and your code has an error, you will typically see informative
error messages. That is not the case when you run Python code from
LAMMPS using an embedded Python interpreter. The code will typically
fail silently. LAMMPS will catch some errors but cannot tell you
where in the Python code the problem occurred. For example, if the
Python code cannot be loaded and run because it has syntax or other
logic errors, you may get an error from Python pointing to the
offending line, or you may get one of these generic errors from
<p>If there is no error in the try statements, then nothing is printed.
Either way the function continues on (unless you put a return or
sys.exit() in the except clause).</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This command is part of the PYTHON package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Building LAMMPS with the PYTHON package will link LAMMPS with the
Python library on your system. Settings to enable this are in the
lib/python/Makefile.lammps file. See the lib/python/README file for
information on those settings.</p>
<p>If you use Python code which calls back to LAMMPS, via the SELF input
argument explained above, there is an extra step required when
building LAMMPS. LAMMPS must also be built as a shared library and
your Python function must be able to to load the Python module in
python/lammps.py that wraps the LAMMPS library interface. These are
the same steps required to use Python by itself to wrap LAMMPS.
Details on these steps are explained in <a class="reference internal" href="Section_python.html"><span class="doc">Section python</span></a>. Note that it is important that the
stand-alone LAMMPS executable and the LAMMPS shared library be
consistent (built from the same source code files) in order for this
to work. If the two have been built at different times using
different source files, problems may occur.</p>
<p>As described above, you can use the python command to invoke a Python
function which calls back to LAMMPS through its Python-wrapped library
interface. However you cannot do the opposite. I.e. you cannot call
LAMMPS from Python and invoke the python command to “callback” to
Python and execute a Python function. LAMMPS will generate an error
if you try to do that. Note that we think there actually should be a
way to do that, but haven’t yet been able to figure out how to do it
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>zero or more keyword/arg pairs may be appended</li>
<li>keyword = <em>add</em> or <em>offset</em> or <em>shift</em> or <em>extra/atom/types</em> or <em>extra/bond/types</em> or <em>extra/angle/types</em> or <em>extra/dihedral/types</em> or <em>extra/improper/types</em> or <em>group</em> or <em>nocoeff</em> or <em>fix</em></li>
</ul>
<pre class="literal-block">
<em>add</em> arg = <em>append</em> or <em>Nstart</em> or <em>merge</em>
append = add new atoms with IDs appended to current IDs
Nstart = add new atoms with IDs starting with Nstart
merge = add new atoms with their IDs unchanged
<em>offset</em> args = toff boff aoff doff ioff
toff = offset to add to atom types
boff = offset to add to bond types
aoff = offset to add to angle types
doff = offset to add to dihedral types
ioff = offset to add to improper types
<em>shift</em> args = Sx Sy Sz
Sx,Sy,Sz = distance to shift atoms when adding to system (distance units)
<em>extra/atom/types</em> arg = # of extra atom types
<em>extra/bond/types</em> arg = # of extra bond types
<em>extra/angle/types</em> arg = # of extra angle types
<em>extra/dihedral/types</em> arg = # of extra dihedral types
<em>extra/improper/types</em> arg = # of extra improper types
<p>Read in a data file containing information LAMMPS needs to run a
simulation. The file can be ASCII text or a gzipped text file
(detected by a .gz suffix). This is one of 3 ways to specify initial
atom coordinates; see the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> and
<a class="reference internal" href="create_atoms.html"><span class="doc">create_atoms</span></a> commands for alternative methods.
Also see the explanation of the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-restart command-line switch</span></a> which can convert a restart file to
a data file.</p>
<p>This command can be used multiple times to add new atoms and their
properties to an existing system by using the <em>add</em>, <em>offset</em>, and
<em>shift</em> keywords. See more details below, which includes the use case
for the <em>extra</em> keywords.</p>
<p>The <em>group</em> keyword adds all the atoms in the data file to the
specified group-ID. The group will be created if it does not already
exist. This is useful if you are reading multiple data files and wish
to put sets of atoms into different groups so they can be operated on
later. E.g. a group of added atoms can be moved to new positions via
the <a class="reference internal" href="displace_atoms.html"><span class="doc">displace_atoms</span></a> command. Note that atoms
read from the data file are also always added to the “all” group. The
<a class="reference internal" href="group.html"><span class="doc">group</span></a> command discusses atom groups, as used in LAMMPS.</p>
<p>The <em>nocoeff</em> keyword tells read_data to ignore force field parameters.
The various Coeff sections are still read and have to have the correct
number of lines, but they are not applied. This also allows to read a
data file without having any pair, bond, angle, dihedral or improper
styles defined, or to read a data file for a different force field.</p>
<p>The use of the <em>fix</em> keyword is discussed below.</p>
<hr class="docutils" />
<p><strong>Reading multiple data files</strong></p>
<p>The read_data command can be used multiple times with the same or
different data files to build up a complex system from components
contained in individual data files. For example one data file could
contain fluid in a confined domain; a second could contain wall atoms,
and the second file could be read a third time to create a wall on the
other side of the fluid. The third set of atoms could be rotated to
an opposing direction using the <a class="reference internal" href="displace_atoms.html"><span class="doc">displace_atoms</span></a>
command, after the third read_data command is used.</p>
<p>The <em>add</em>, <em>offset</em>, <em>shift</em>, <em>extra</em>, and <em>group</em> keywords are
useful in this context.</p>
<p>If a simulation box does not yet exist, the <em>add</em> keyword
cannot be used; the read_data command is being used for the first
time. If a simulation box does exist, due to using the
<a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> command, or a previous read_data command,
then the <em>add</em> keyword must be used.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The simulation box size (xlo to xhi, ylo to yhi, zlo to zhi) in
the new data file will be merged with the existing simulation box to
create a large enough box in each dimension to contain both the
existing and new atoms. Each box dimension never shrinks due to this
merge operation, it only stays the same or grows. Care must be used if
you are growing the existing simulation box in a periodic dimension.
If there are existing atoms with bonds that straddle that periodic
boundary, then the atoms may become far apart if the box size grows.
This will separate the atoms in the bond, which can lead to “lost”
bond atoms or bad dynamics.</p>
</div>
<p>The three choices for the <em>add</em> argument affect how the IDs of atoms
in the data file are treated. If <em>append</em> is specified, atoms in the
data file are added to the current system, with their atom IDs reset
so that an atomID = M in the data file becomes atomID = N+M, where N
is the largest atom ID in the current system. This rule is applied to
all occurrences of atom IDs in the data file, e.g. in the Velocity or
Bonds section. If <em>Nstart</em> is specified, then <em>Nstart</em> is a numeric
value is given, e.g. 1000, so that an atomID = M in the data file
becomes atomID = 1000+M. If <em>merge</em> is specified, the data file atoms
are added to the current system without changing their IDs. They are
assumed to merge (without duplication) with the currently defined
atoms. It is up to you to insure there are no multiply defined atom
IDs, as LAMMPS only performs an incomplete check that this is the case
by insuring the resulting max atomID >= the number of atoms.</p>
<p>The <em>offset</em> and <em>shift</em> keywords can only be used if the <em>add</em>
keyword is also specified.</p>
<p>The <em>offset</em> keyword adds the specified offset values to the atom
types, bond types, angle types, dihedral types, and improper types as
they are read from the data file. E.g. if <em>toff</em> = 2, and the file
uses atom types 1,2,3, then the added atoms will have atom types
3,4,5. These offsets apply to all occurrences of types in the data
file, e.g. for the Atoms or Masses or Pair Coeffs or Bond Coeffs
sections. This makes it easy to use atoms and molecules and their
attributes from a data file in different simulations, where you want
their types (atom, bond, angle, etc) to be different depending on what
other types already exist. All five offset values must be specified,
but individual values will be ignored if the data file does not use
that attribute (e.g. no bonds).</p>
<p>The <em>shift</em> keyword can be used to specify an (Sx, Sy, Sz)
displacement applied to the coordinates of each atom. Sz must be 0.0
for a 2d simulation. This is a mechanism for adding structured
collections of atoms at different locations within the simulation box,
to build up a complex geometry. It is up to you to insure atoms do
not end up overlapping unphysically which would lead to bad dynamics.
Note that the <a class="reference internal" href="displace_atoms.html"><span class="doc">displace_atoms</span></a> command can be used
to move a subset of atoms after they have been read from a data file.
Likewise, the <a class="reference internal" href="delete_atoms.html"><span class="doc">delete_atoms</span></a> command can be used to
remove overlapping atoms. Note that the shift values (Sx, Sy, Sz) are
also added to the simulation box information (xlo, xhi, ylo, yhi, zlo,
zhi) in the data file to shift its boundaries. E.g. xlo_new = xlo +
Sx, xhi_new = xhi + Sx.</p>
<p>The <em>extra</em> keywords can only be used the first time the read_data
command is used. They are useful if you intend to add new atom, bond,
angle, etc types later with additional read_data commands. This is
because the maximum number of allowed atom, bond, angle, etc types is
set by LAMMPS when the system is first initialized. If you do not use
the <em>extra</em> keywords, then the number of these types will be limited
to what appears in the first data file you read. For example, if the
first data file is a solid substrate of Si, it will likely specify a
single atom type. If you read a second data file with a different
material (water molecules) that sit on top of the substrate, you will
want to use different atom types for those atoms. You can only do
this if you set the <em>extra/atom/types</em> keyword to a sufficiently large
value when reading the substrate data file. Note that use of the
<em>extra</em> keywords also allows each data file to contain sections like
Masses or Pair Coeffs or Bond Coeffs which are sized appropriately for
the number of types in that data file. If the <em>offset</em> keyword is
used appropriately when each data file is read, the values in those
sections will be stored correctly in the larger data structures
allocated by the use of the <em>extra</em> keywords. E.g. the substrate file
can list mass and pair coefficients for type 1 silicon atoms. The
water file can list mass and pair coeffcients for type 1 and type 2
hydrogen and oxygen atoms. Use of the <em>extra</em> and <em>offset</em> keywords
will store those mass and pair coefficient values appropriately in
data structures that allow for 3 atom types (Si, H, O). Of course,
you would still need to specify coefficients for H/Si and O/Si
interactions in your input script to have a complete pairwise
interaction model.</p>
<p>An alternative to using the <em>extra</em> keywords with the read_data
command, is to use the <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> command to
initialize the simulation box and all the various type limits you need
via its <em>extra</em> keywords. Then use the read_data command one or more
times to populate the system with atoms, bonds, angles, etc, using the
<em>offset</em> keyword if desired to alter types used in the various data
files you read.</p>
<hr class="docutils" />
<p><strong>Format of a data file</strong></p>
<p>The structure of the data file is important, though many settings and
sections are optional or can come in any order. See the examples
directory for sample data files for different problems.</p>
<p>A data file has a header and a body. The header appears first. The
first line of the header is always skipped; it typically contains a
description of the file. Then lines are read one at a time. Lines
can have a trailing comment starting with ‘#’ that is ignored. If the
line is blank (only whitespace after comment is deleted), it is
skipped. If the line contains a header keyword, the corresponding
value(s) is read from the line. If it doesn’t contain a header
keyword, the line begins the body of the file.</p>
<p>The body of the file contains zero or more sections. The first line
of a section has only a keyword. This line can have a trailing
comment starting with ‘#’ that is either ignored or can be used to
check for a style match, as described below. The next line is
skipped. The remaining lines of the section contain values. The
number of lines depends on the section keyword as described below.
Zero or more blank lines can be used between sections. Sections can
appear in any order, with a few exceptions as noted below.</p>
<p>The keyword <em>fix</em> can be used one or more times. Each usage specifies
a fix that will be used to process a specific portion of the data
file. Any header line containing <em>header-string</em> and any section with
a name containing <em>section-string</em> will be passed to the specified
fix. See the <a class="reference internal" href="fix_property_atom.html"><span class="doc">fix property/atom</span></a> command for
an example of a fix that operates in this manner. The doc page for
the fix defines the syntax of the header line(s) and section(s) that
it reads from the data file. Note that the <em>header-string</em> can be
specified as NULL, in which case no header lines are passed to the
fix. This means that it can infer the length of its Section from
standard header settings, such as the number of atoms.</p>
<p>The formatting of individual lines in the data file (indentation,
spacing between words and numbers) is not important except that header
and section keywords (e.g. atoms, xlo xhi, Masses, Bond Coeffs) must
be capitalized as shown and can’t have extra white space between their
words - e.g. two spaces or a tab between the 2 words in “xlo xhi” or
the 2 words in “Bond Coeffs”, is not valid.</p>
<hr class="docutils" />
<p><strong>Format of the header of a data file</strong></p>
<p>These are the recognized header keywords. Header lines can come in
any order. The value(s) are read from the beginning of the line.
Thus the keyword <em>atoms</em> should be in a line like “1000 atoms”; the
keyword <em>ylo yhi</em> should be in a line like “-10.0 10.0 ylo yhi”; the
keyword <em>xy xz yz</em> should be in a line like “0.0 5.0 6.0 xy xz yz”.
All these settings have a default value of 0, except the lo/hi box
size defaults are -0.5 and 0.5. A line need only appear if the value
is different than the default.</p>
<ul class="simple">
<li><em>atoms</em> = # of atoms in system</li>
<li><em>bonds</em> = # of bonds in system</li>
<li><em>angles</em> = # of angles in system</li>
<li><em>dihedrals</em> = # of dihedrals in system</li>
<li><em>impropers</em> = # of impropers in system</li>
<li><em>atom types</em> = # of atom types in system</li>
<li><em>bond types</em> = # of bond types in system</li>
<li><em>angle types</em> = # of angle types in system</li>
<li><em>dihedral types</em> = # of dihedral types in system</li>
<li><em>improper types</em> = # of improper types in system</li>
<li><em>extra bond per atom</em> = leave space for this many new bonds per atom</li>
<li><em>extra angle per atom</em> = leave space for this many new angles per atom</li>
<li><em>extra dihedral per atom</em> = leave space for this many new dihedrals per atom</li>
<li><em>extra improper per atom</em> = leave space for this many new impropers per atom</li>
<li><em>extra special per atom</em> = leave space for this many new special bonds per atom</li>
<li><em>ellipsoids</em> = # of ellipsoids in system</li>
<li><em>lines</em> = # of line segments in system</li>
<li><em>triangles</em> = # of triangles in system</li>
<li><em>bodies</em> = # of bodies in system</li>
<li><em>xlo xhi</em> = simulation box boundaries in x dimension</li>
<li><em>ylo yhi</em> = simulation box boundaries in y dimension</li>
<li><em>zlo zhi</em> = simulation box boundaries in z dimension</li>
<p>If the <em>xy xz yz</em> line does not appear, LAMMPS will set up an
axis-aligned (orthogonal) simulation box. If the line does appear,
LAMMPS creates a non-orthogonal simulation domain shaped as a
parallelepiped with triclinic symmetry. The parallelepiped has its
“origin” at (xlo,ylo,zlo) and is defined by 3 edge vectors starting
from the origin given by A = (xhi-xlo,0,0); B = (xy,yhi-ylo,0); C =
(xz,yz,zhi-zlo). <em>Xy,xz,yz</em> can be 0.0 or positive or negative values
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.</p>
<p>By default, the tilt factors (xy,xz,yz) can not skew the box more than
half the distance of the corresponding parallel box length. For
example, if xlo = 2 and xhi = 12, then the x box length is 10 and the
xy tilt factor must be between -5 and 5. Similarly, both xz and yz
must be between -(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is not
a limitation, since if the maximum tilt factor is 5 (as in this
example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
... are all geometrically equivalent. If you wish to define a box
with tilt factors that exceed these limits, you can use the <a class="reference internal" href="box.html"><span class="doc">box tilt</span></a> command, with a setting of <em>large</em>; a setting of
<em>small</em> is the default.</p>
<p>See <a class="reference internal" href="Section_howto.html#howto-12"><span class="std std-ref">Section_howto 12</span></a> of the doc pages
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.</p>
<p>When a triclinic system is used, the simulation domain should normally
be periodic in the dimension that the tilt is applied to, which is
given by the second dimension of the tilt factor (e.g. y for xy tilt).
This is so that pairs of atoms interacting across that boundary will
have one of them shifted by the tilt factor. Periodicity is set by
the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command. For example, if the xy tilt
factor is non-zero, then the y dimension should be periodic.
Similarly, the z dimension should be periodic if xz or yz is non-zero.
LAMMPS does not require this periodicity, but you may lose atoms if
this is not the case.</p>
<p>Also note that if your simulation will tilt the box, e.g. via the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> command, the simulation box must be setup to
be triclinic, even if the tilt factors are initially 0.0. You can
also change an orthogonal box to a triclinic box or vice versa by
using the <a class="reference internal" href="change_box.html"><span class="doc">change box</span></a> command with its <em>ortho</em> and
<em>triclinic</em> options.</p>
<p>For 2d simulations, the <em>zlo zhi</em> values should be set to bound the z
coords for atoms that appear in the file; the default of -0.5 0.5 is
valid if all z coords are 0.0. For 2d triclinic simulations, the xz
and yz tilt factors must be 0.0.</p>
<p>If the system is periodic (in a dimension), then atom coordinates can
be outside the bounds (in that dimension); they will be remapped (in a
periodic sense) back inside the box. Note that if the <em>add</em> option is
being used to add atoms to a simulation box that already exists, this
periodic remapping will be performed using simulation box bounds that
are the union of the existing box and the box boundaries in the new
data file.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If the system is non-periodic (in a dimension), then all atoms
in the data file must have coordinates (in that dimension) that are
“greater than or equal to” the lo value and “less than or equal to”
the hi value. If the non-periodic dimension is of style “fixed” (see
the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command), then the atom coords must be
strictly “less than” the hi value, due to the way LAMMPS assign atoms
to processors. Note that you should not make the lo/hi values
radically smaller/larger than the extent of the atoms. For example,
if your atoms extend from 0 to 50, you should not specify the box
bounds as -10000 and 10000. This is because LAMMPS uses the specified
box size to layout the 3d grid of processors. A huge (mostly empty)
box will be sub-optimal for performance when using “fixed” boundary
conditions (see the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command). When using
“shrink-wrap” boundary conditions (see the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a>
command), a huge (mostly empty) box may cause a parallel simulation to
lose atoms when LAMMPS shrink-wraps the box around the atoms. The
read_data command will generate an error in this case.</p>
</div>
<p>The “extra bond per atom” setting (angle, dihedral, improper) is only
needed if new bonds (angles, dihedrals, impropers) will be added to
the system when a simulation runs, e.g. by using the <a class="reference internal" href="fix_bond_create.html"><span class="doc">fix bond/create</span></a> command. This will pre-allocate
space in LAMMPS data structures for storing the new bonds (angles,
dihedrals, impropers).</p>
<p>The “extra special per atom” setting is typically only needed if new
bonds/angles/etc will be added to the system, e.g. by using the <a class="reference internal" href="fix_bond_create.html"><span class="doc">fix bond/create</span></a> command. Or if entire new molecules
will be added to the system, e.g. by using the <a class="reference internal" href="fix_deposit.html"><span class="doc">fix deposit</span></a> or <a class="reference internal" href="fix_pour.html"><span class="doc">fix pour</span></a> commands, which
will have more special 1-2,1-3,1-4 neighbors than any other molecules
defined in the data file. Using this setting will pre-allocate space
in the LAMMPS data structures for storing these neighbors. See the
pages for more discussion of 1-2,1-3,1-4 neighbors.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">All of the “extra” settings are only used if they appear in the
first data file read; see the description of the <em>add</em> keyword above
for reading multiple data files. If they appear in later data files,
they are ignored.</p>
</div>
<p>The “ellipsoids” and “lines” and “triangles” and “bodies” settings are
only used with <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid or line or tri or body</span></a> and specify how many of the atoms are
finite-size ellipsoids or lines or triangles or bodies; the remainder
are point particles. See the discussion of ellipsoidflag and the
<em>Ellipsoids</em> section below. See the discussion of lineflag and the
<em>Lines</em> section below. See the discussion of triangleflag and the
<em>Triangles</em> section below. See the discussion of bodyflag and the
<em>Bodies</em> section below.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For <a class="reference internal" href="atom_style.html"><span class="doc">atom_style template</span></a>, the molecular
topology (bonds,angles,etc) is contained in the molecule templates
read-in by the <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command. This means you
cannot set the <em>bonds</em>, <em>angles</em>, etc header keywords in the data
file, nor can you define <em>Bonds</em>, <em>Angles</em>, etc sections as discussed
below. You can set the <em>bond types</em>, <em>angle types</em>, etc header
keywords, though it is not necessary. If specified, they must match
the maximum values defined in any of the template molecules.</p>
</div>
<hr class="docutils" />
<p><strong>Format of the body of a data file</strong></p>
<p>These are the section keywords for the body of the file.</p>
<p>Atom lines specify the (x,y,z) coordinates of atoms. These can be
inside or outside the simulation box. When the data file is read,
LAMMPS wraps coordinates outside the box back into the box for
dimensions that are periodic. As discussed above, if an atom is
outside the box in a non-periodic dimension, it will be lost.</p>
<p>LAMMPS always stores atom coordinates as values which are inside the
simulation box. It also stores 3 flags which indicate which image of
the simulation box (in each dimension) the atom would be in if its
coordinates were unwrapped across periodic boundaries. An image flag
of 0 means the atom is still inside the box when unwrapped. A value
of 2 means add 2 box lengths to get the unwrapped coordinate. A value
of -1 means subtract 1 box length to get the unwrapped coordinate.
LAMMPS updates these flags as atoms cross periodic boundaries during
the simulation. The <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command can output atom atom
coordinates in wrapped or unwrapped form, as well as the 3 image
flags.</p>
<p>In the data file, atom lines (all lines or none of them) can
optionally list 3 trailing integer values (nx,ny,nz), which are used
to initialize the atom’s image flags. If nx,ny,nz values are not
listed in the data file, LAMMPS initializes them to 0. Note that the
image flags are immediately updated if an atom’s coordinates need to
wrapped back into the simulation box.</p>
<p>It is only important to set image flags correctly in a data file if a
simulation model relies on unwrapped coordinates for some calculation;
otherwise they can be left unspecified. Examples of LAMMPS commands
that use unwrapped coordinates internally are as follows:</p>
<ul class="simple">
<li>Atoms in a rigid body (see <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a>, <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid/small</span></a>) must have consistent image flags, so that
when the atoms are unwrapped, they are near each other, i.e. as a
single body.</li>
<li>If the <a class="reference internal" href="replicate.html"><span class="doc">replicate</span></a> command is used to generate a larger
system, image flags must be consistent for bonded atoms when the bond
crosses a periodic boundary. I.e. the values of the image flags
should be different by 1 (in the appropriate dimension) for the two
atoms in such a bond.</li>
<li>If you plan to <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> image flags and perform post-analysis
that will unwrap atom coordinates, it may be important that a
continued run (restarted from a data file) begins with image flags
that are consistent with the previous run.</li>
</ul>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If your system is an infinite periodic crystal with bonds then
it is impossible to have fully consistent image flags. This is because
some bonds will cross periodic boundaries and connect two atoms with the
same image flag.</p>
</div>
<p>Atom velocities and other atom quantities not defined above are set to
0.0 when the <em>Atoms</em> section is read. Velocities can be set later by
a <em>Velocities</em> section in the data file or by a
<a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> or <a class="reference internal" href="set.html"><span class="doc">set</span></a> command in the input
script.</p>
<hr class="docutils" />
<p><em>Bodies</em> section:</p>
<ul class="simple">
<li>one or more lines per body</li>
<li>first line syntax: atom-ID Ninteger Ndouble</li>
</ul>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">Ninteger</span> <span class="o">=</span> <span class="c1"># of integer quantities for this particle</span>
<span class="n">Ndouble</span> <span class="o">=</span> <span class="c1"># of floating-point quantities for this particle</span>
</pre></div>
</div>
<ul class="simple">
<li>0 or more integer lines with total of Ninteger values</li>
<li>0 or more double lines with total of Ndouble values</li>
<p>The <em>Ellipsoids</em> section must appear if <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a> is used and any atoms are listed in the
<em>Atoms</em> section with an ellipsoidflag = 1. The number of ellipsoids
should be specified in the header section via the “ellipsoids”
keyword.</p>
<p>The 3 shape values specify the 3 diameters or aspect ratios of a
finite-size ellipsoidal particle, when it is oriented along the 3
coordinate axes. They must all be non-zero values.</p>
<p>The values <em>quatw</em>, <em>quati</em>, <em>quatj</em>, and <em>quatk</em> set the orientation
of the atom as a quaternion (4-vector). Note that the shape
attributes specify the aspect ratios of an ellipsoidal particle, which
is oriented by default with its x-axis along the simulation box’s
x-axis, and similarly for y and z. If this body is rotated (via the
right-hand rule) by an angle theta around a unit vector (a,b,c), then
the quaternion that represents its new orientation is given by
(cos(theta/2), a*sin(theta/2), b*sin(theta/2), c*sin(theta/2)). These
4 components are quatw, quati, quatj, and quatk as specified above.
LAMMPS normalizes each atom’s quaternion in case (a,b,c) is not
specified as a unit vector.</p>
<p>The <em>Ellipsoids</em> section must appear after the <em>Atoms</em> section.</p>
<hr class="docutils" />
<p><em>EndBondTorsion Coeffs</em> section:</p>
<ul class="simple">
<li>one line per dihedral type</li>
<li>line syntax: ID coeffs</li>
</ul>
<pre class="literal-block">
ID = dihedral type (1-N)
coeffs = list of coeffs (see class 2 section of <a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a>)
<p>The ordering of the 4 atoms determines the definition of the improper
angle used in the formula for each <a class="reference internal" href="improper_style.html"><span class="doc">improper style</span></a>. See the doc pages for individual styles
for details.</p>
<p>The <em>Impropers</em> section must appear after the <em>Atoms</em> section. All
values in this section must be integers (1, not 1.0).</p>
<p>The number and meaning of the coefficients are specific to the defined
pair style. See the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> and
<a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> commands for details. Since pair
coefficients for types I != J are not specified, these will be
generated automatically by the pair style’s mixing rule. See the
individual pair_style doc pages and the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify mix</span></a> command for details. Pair coefficients can also
be set via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command in the input
script.</p>
<hr class="docutils" />
<p><em>PairIJ Coeffs</em> section:</p>
<ul class="simple">
<li>one line per pair of atom types for all I,J with I <= J</li>
<p>This section must have N*(N+1)/2 lines where N = # of atom types. The
number and meaning of the coefficients are specific to the defined
pair style. See the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> and
<a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> commands for details. Since pair
coefficients for types I != J are all specified, these values will
turn off the default mixing rule defined by the pair style. See the
individual pair_style doc pages and the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify mix</span></a> command for details. Pair coefficients can also
be set via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command in the input
<p>The <em>Triangles</em> section must appear if <a class="reference internal" href="atom_style.html"><span class="doc">atom_style tri</span></a> is used and any atoms are listed in the <em>Atoms</em>
section with a triangleflag = 1. The number of lines should be
specified in the header section via the “triangles” keyword.</p>
<p>The 3 corner points are the corner points of the triangle. The
ordering of the 3 points should be such that using a right-hand rule
to go from point1 to point2 to point3 gives an “outward” normal vector
to the face of the triangle. I.e. normal = (c2-c1) x (c3-c1). This
orientation may be important for defining some interactions.</p>
<p>The <em>Triangles</em> section must appear after the <em>Atoms</em> section.</p>
<hr class="docutils" />
<p><em>Velocities</em> section:</p>
<ul class="simple">
<li>one line per atom</li>
<li>line syntax: depends on atom style</li>
</ul>
<table border="1" class="docutils">
<colgroup>
<col width="42%" />
<col width="58%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>all styles except those listed</td>
<p>Translational velocities can also be set by the
<a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> command in the input script.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>To read gzipped data files, you must compile LAMMPS with the
-DLAMMPS_GZIP option - see the <a class="reference internal" href="Section_start.html#start-2"><span class="std std-ref">Making LAMMPS</span></a> section of the documentation.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<em>ix</em>,<em>iy</em>,<em>iz</em> = image flags in each dimension
</pre>
<ul class="simple">
<li>zero or more keyword/value pairs may be appended</li>
<li>keyword = <em>box</em> or <em>replace</em> or <em>purge</em> or <em>trim</em> or <em>add</em> or <em>label</em> or <em>scaled</em> or <em>wrapped</em> or <em>format</em></li>
</ul>
<pre class="literal-block">
<em>box</em> value = <em>yes</em> or <em>no</em> = replace simulation box with dump box
<em>replace</em> value = <em>yes</em> or <em>no</em> = overwrite atoms with dump atoms
<em>purge</em> value = <em>yes</em> or <em>no</em> = delete all atoms before adding dump atoms
<em>trim</em> value = <em>yes</em> or <em>no</em> = trim atoms not in dump snapshot
<em>add</em> value = <em>yes</em> or <em>no</em> = add new dump atoms to system
<em>label</em> value = field column
field = one of the listed fields or <em>id</em> or <em>type</em>
column = label on corresponding column in dump file
<em>scaled</em> value = <em>yes</em> or <em>no</em> = coords in dump file are scaled/unscaled
<em>wrapped</em> value = <em>yes</em> or <em>no</em> = coords in dump file are wrapped/unwrapped
<em>format</em> values = format of dump file, must be last keyword if used
<p>Atom coordinates read from the dump file are first converted into
unscaled coordinates, relative to the box dimensions of the snapshot.
These coordinates are then be assigned to an existing or new atom in
the current simulation. The coordinates will then be remapped to the
simulation box, whether it is the original box or the dump snapshot
box. If periodic boundary conditions apply, this means the atom will
be remapped back into the simulation box if necessary. If shrink-wrap
boundary conditions apply, the new coordinates may change the
simulation box dimensions. If fixed boundary conditions apply, the
atom will be lost if it is outside the simulation box.</p>
<p>For <em>native</em> format dump files, the 3 xyz image flags for an atom in
the dump file are set to the corresponding values appearing in the
dump file if the <em>ix</em>, <em>iy</em>, <em>iz</em> fields are specified. If not
specified, the image flags for replaced atoms are not changed and
image flags for new atoms are set to default values. If coordinates
read from the dump file are in unwrapped format (e.g. <em>xu</em>) then the
image flags for read-in atoms are also set to default values. The
remapping procedure described in the previous paragraph will then
change images flags for all atoms (old and new) if periodic boundary
conditions are applied to remap an atom back into the simulation box.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you get a warning about inconsistent image flags after
reading in a dump snapshot, it means one or more pairs of bonded atoms
now have inconsistent image flags. As discussed in <a class="reference internal" href="Section_errors.html"><span class="doc">Section errors</span></a> this may or may not cause problems for
subsequent simulations, One way this can happen is if you read image
flag fields from the dump file but do not also use the dump file box
parameters.</p>
</div>
<p>LAMMPS knows how to compute unscaled and remapped coordinates for the
snapshot column labels discussed above, e.g. <em>x</em>, <em>xs</em>, <em>xu</em>, <em>xsu</em>.
If another column label is assigned to the <em>x</em> or <em>y</em> or <em>z</em> field via
the <em>label</em> keyword, e.g. for coordinates output by the <a class="reference internal" href="fix_ave_atom.html"><span class="doc">fix ave/atom</span></a> command, then LAMMPS needs to know whether
the coordinate information in the dump file is scaled and/or wrapped.
This can be set via the <em>scaled</em> and <em>wrapped</em> keywords. Note that
the value of the <em>scaled</em> and <em>wrapped</em> keywords is ignored for fields
<em>x</em> or <em>y</em> or <em>z</em> if the <em>label</em> keyword is not used to assign a
column label to that field.</p>
<p>The scaled/unscaled and wrapped/unwrapped setting must be identical
for any of the <em>x</em>, <em>y</em>, <em>z</em> fields that are specified. Thus you
cannot read <em>xs</em> and <em>yu</em> from the dump file. Also, if the dump file
coordinates are scaled and the simulation box is triclinic, then all 3
of the <em>x</em>, <em>y</em>, <em>z</em> fields must be specified, since they are all
needed to generate absolute, unscaled coordinates.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>To read gzipped dump files, you must compile LAMMPS with the
-DLAMMPS_GZIP option - see the <a class="reference internal" href="Section_start.html#start-2"><span class="std std-ref">Making LAMMPS</span></a> section of the documentation.</p>
<p>The <em>molfile</em> dump file formats are part of the USER-MOLFILE package.
They are only enabled if LAMMPS was built with that packages. See the
<a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>style = <em>delete</em> or <em>block</em> or <em>cone</em> or <em>cylinder</em> or <em>plane</em> or <em>prism</em> or <em>sphere</em> or <em>union</em> or <em>intersect</em></li>
</ul>
<pre class="literal-block">
<em>delete</em> = no args
<em>block</em> args = xlo xhi ylo yhi zlo zhi
xlo,xhi,ylo,yhi,zlo,zhi = bounds of block in all dimensions (distance units)
<em>cone</em> args = dim c1 c2 radlo radhi lo hi
dim = <em>x</em> or <em>y</em> or <em>z</em> = axis of cone
c1,c2 = coords of cone axis in other 2 dimensions (distance units)
radlo,radhi = cone radii at lo and hi end (distance units)
lo,hi = bounds of cone in dim (distance units)
<em>cylinder</em> args = dim c1 c2 radius lo hi
dim = <em>x</em> or <em>y</em> or <em>z</em> = axis of cylinder
c1,c2 = coords of cylinder axis in other 2 dimensions (distance units)
radius = cylinder radius (distance units)
radius can be a variable (see below)
lo,hi = bounds of cylinder in dim (distance units)
<em>plane</em> args = px py pz nx ny nz
px,py,pz = point on the plane (distance units)
nx,ny,nz = direction normal to plane (distance units)
+region 2 sphere 0.0 0.0 0.0 5 side out move v_left v_up NULL
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>This command defines a geometric region of space. Various other
commands use regions. For example, the region can be filled with
atoms via the <a class="reference internal" href="create_atoms.html"><span class="doc">create_atoms</span></a> command. Or a bounding
box around the region, can be used to define the simulation box via
the <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> command. Or the atoms in the region
can be identified as a group via the <a class="reference internal" href="group.html"><span class="doc">group</span></a> command, or
deleted via the <a class="reference internal" href="delete_atoms.html"><span class="doc">delete_atoms</span></a> command. Or the
surface of the region can be used as a boundary wall via the <a class="reference internal" href="fix_wall_region.html"><span class="doc">fix wall/region</span></a> command.</p>
<p>Commands which use regions typically test whether an atom’s position
is contained in the region or not. For this purpose, coordinates
exactly on the region boundary are considered to be interior to the
region. This means, for example, for a spherical region, an atom on
the sphere surface would be part of the region if the sphere were
defined with the <em>side in</em> keyword, but would not be part of the
region if it were defined using the <em>side out</em> keyword. See more
details on the <em>side</em> keyword below.</p>
<p>Normally, regions in LAMMPS are “static”, meaning their geometric
extent does not change with time. If the <em>move</em> or <em>rotate</em> keyword
is used, as described below, the region becomes “dynamic”, meaning
it’s location or orientation changes with time. This may be useful,
for example, when thermostatting a region, via the compute temp/region
command, or when the fix wall/region command uses a region surface as
a bounding wall on particle motion, i.e. a rotating container.</p>
<p>The <em>delete</em> style removes the named region. Since there is little
overhead to defining extra regions, there is normally no need to do
this, unless you are defining and discarding large numbers of regions
in your input script.</p>
<p>The lo/hi values for <em>block</em> or <em>cone</em> or <em>cylinder</em> or <em>prism</em> styles
can be specified as EDGE or INF. EDGE means they extend all the way
to the global simulation box boundary. Note that this is the current
box boundary; if the box changes size during a simulation, the region
does not. INF means a large negative or positive number (1.0e20), so
it should encompass the simulation box even if it changes size. If a
region is defined before the simulation box has been created (via
<a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> or <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> or
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands), then an EDGE or INF
parameter cannot be used. For a <em>prism</em> region, a non-zero tilt
factor in any pair of dimensions cannot be used if both the lo/hi
values in either of those dimensions are INF. E.g. if the xy tilt is
non-zero, then xlo and xhi cannot both be INF, nor can ylo and yhi.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Regions in LAMMPS do not get wrapped across periodic boundaries,
as specified by the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command. For example, a
spherical region that is defined so that it overlaps a periodic
boundary is not treated as 2 half-spheres, one on either side of the
simulation box.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Regions in LAMMPS are always 3d geometric objects, regardless of
whether the <a class="reference internal" href="dimension.html"><span class="doc">dimension</span></a> of a simulation is 2d or 3d.
Thus when using regions in a 2d simulation, you should be careful to
define the region so that its intersection with the 2d x-y plane of
the simulation has the 2d geometric extent you want.</p>
</div>
<p>For style <em>cone</em>, an axis-aligned cone is defined which is like a
<em>cylinder</em> except that two different radii (one at each end) can be
defined. Either of the radii (but not both) can be 0.0.</p>
<p>For style <em>cone</em> and <em>cylinder</em>, the c1,c2 params are coordinates in
the 2 other dimensions besides the cylinder axis dimension. For dim =
x, c1/c2 = y/z; for dim = y, c1/c2 = x/z; for dim = z, c1/c2 = x/y.
Thus the third example above specifies a cylinder with its axis in the
y-direction located at x = 2.0 and z = 3.0, with a radius of 5.0, and
extending in the y-direction from -5.0 to the upper box boundary.</p>
<p>For style <em>plane</em>, a plane is defined which contain the point
(px,py,pz) and has a normal vector (nx,ny,nz). The normal vector does
not have to be of unit length. The “inside” of the plane is the
half-space in the direction of the normal vector; see the discussion
of the <em>side</em> option below.</p>
<p>For style <em>prism</em>, a parallelepiped is defined (it’s too hard to spell
parallelepiped in an input script!). The parallelepiped has its
“origin” at (xlo,ylo,zlo) and is defined by 3 edge vectors starting
from the origin given by A = (xhi-xlo,0,0); B = (xy,yhi-ylo,0); C =
(xz,yz,zhi-zlo). <em>Xy,xz,yz</em> can be 0.0 or positive or negative values
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.</p>
<p>A prism region that will be used with the <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a>
command to define a triclinic simulation box must have tilt factors
(xy,xz,yz) that do not skew the box more than half the distance of
corresponding the parallel box length. For example, if xlo = 2 and
xhi = 12, then the x box length is 10 and the xy tilt factor must be
between -5 and 5. Similarly, both xz and yz must be between
-(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is not a limitation,
since if the maximum tilt factor is 5 (as in this example), then
configurations with tilt = ..., -15, -5, 5, 15, 25, ... are all
geometrically equivalent.</p>
<p>The <em>radius</em> value for style <em>sphere</em> and <em>cylinder</em> can be specified
as an equal-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>. If the value is a
variable, it should be specified as v_name, where name is the variable
name. In this case, the variable will be evaluated each timestep, and
its value used to determine the radius of the region.</p>
<p>Equal-style variables can specify formulas with various mathematical
functions, and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent radius.</p>
<p>See <a class="reference internal" href="Section_howto.html#howto-12"><span class="std std-ref">Section_howto 12</span></a> of the doc pages
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.</p>
<p>The <em>union</em> style creates a region consisting of the volume of all the
listed regions combined. The <em>intersect</em> style creates a region
consisting of the volume that is common to all the listed regions.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The <em>union</em> and <em>intersect</em> regions operate by invoking methods
from their list of sub-regions. Thus you cannot delete the
sub-regions after defining the <em>union</em> or <em>intersection</em> region.</p>
</div>
<hr class="docutils" />
<p>The <em>side</em> keyword determines whether the region is considered to be
inside or outside of the specified geometry. Using this keyword in
conjunction with <em>union</em> and <em>intersect</em> regions, complex geometries
can be built up. For example, if the interior of two spheres were
each defined as regions, and a <em>union</em> style with <em>side</em> = out was
constructed listing the region-IDs of the 2 spheres, the resulting
region would be all the volume in the simulation box that was outside
both of the spheres.</p>
<p>The <em>units</em> keyword determines the meaning of the distance units used
to define the region for any argument above listed as having distance
units. It also affects the scaling of the velocity vector specfied
with the <em>vel</em> keyword, the amplitude vector specified with the
<em>wiggle</em> keyword, and the rotation point specified with the <em>rotate</em>
keyword, since they each involve a distance metric.</p>
<p>A <em>box</em> value selects standard distance units as defined by the
<a class="reference internal" href="units.html"><span class="doc">units</span></a> command, e.g. Angstroms for units = real or metal.
A <em>lattice</em> value means the distance units are in lattice spacings.
The <a class="reference internal" href="lattice.html"><span class="doc">lattice</span></a> command must have been previously used to
define the lattice spacings which are used as follows:</p>
<ul class="simple">
<li>For style <em>block</em>, the lattice spacing in dimension x is applied to
xlo and xhi, similarly the spacings in dimensions y,z are applied to
ylo/yhi and zlo/zhi.</li>
<li>For style <em>cone</em>, the lattice spacing in argument <em>dim</em> is applied to
lo and hi. The spacings in the two radial dimensions are applied to
c1 and c2. The two cone radii are scaled by the lattice
spacing in the dimension corresponding to c1.</li>
<li>For style <em>cylinder</em>, the lattice spacing in argument <em>dim</em> is applied
to lo and hi. The spacings in the two radial dimensions are applied
to c1 and c2. The cylinder radius is scaled by the lattice
spacing in the dimension corresponding to c1.</li>
<li>For style <em>plane</em>, the lattice spacing in dimension x is applied to
px and nx, similarly the spacings in dimensions y,z are applied to
py/ny and pz/nz.</li>
<li>For style <em>prism</em>, the lattice spacing in dimension x is applied to
xlo and xhi, similarly for ylo/yhi and zlo/zhi. The lattice spacing
in dimension x is applied to xy and xz, and the spacing in dimension y
to yz.</li>
<li>For style <em>sphere</em>, the lattice spacing in dimensions x,y,z are
applied to the sphere center x,y,z. The spacing in dimension x is
applied to the sphere radius.</li>
</ul>
<hr class="docutils" />
<p>If the <em>move</em> or <em>rotate</em> keywords are used, the region is “dynamic”,
meaning its location or orientation changes with time. These keywords
cannot be used with a <em>union</em> or <em>intersect</em> style region. Instead,
the keywords should be used to make the individual sub-regions of the
<em>union</em> or <em>intersect</em> region dynamic. Normally, each sub-region
should be “dynamic” in the same manner (e.g. rotate around the same
point), though this is not a requirement.</p>
<p>The <em>move</em> keyword allows one or more <a class="reference internal" href="variable.html"><span class="doc">equal-style variables</span></a> to be used to specify the x,y,z displacement
of the region, typically as a function of time. A variable is
specified as v_name, where name is the variable name. Any of the
three variables can be specified as NULL, in which case no
displacement is calculated in that dimension.</p>
<p>Note that equal-style variables can specify formulas with various
mathematical functions, and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a>
command keywords for the simulation box parameters and timestep and
elapsed time. Thus it is easy to specify a region displacement that
change as a function of time or spans consecutive runs in a continuous
fashion. For the latter, see the <em>start</em> and <em>stop</em> keywords of the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command and the <em>elaplong</em> keyword of <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> for details.</p>
<p>For example, these commands would displace a region from its initial
position, in the positive x direction, effectively at a constant
<p>The <em>rotate</em> keyword rotates the region around a rotation axis <em>R</em> =
(Rx,Ry,Rz) that goes thru a point <em>P</em> = (Px,Py,Pz). The rotation
angle is calculated, presumably as a function of time, by a variable
specified as v_theta, where theta is the variable name. The variable
should generate its result in radians. The direction of rotation for
the region around the rotation axis is consistent with the right-hand
rule: if your right-hand thumb points along <em>R</em>, then your fingers
wrap around the axis in the direction of rotation.</p>
<p>The <em>move</em> and <em>rotate</em> keywords can be used together. In this case,
the displacement specified by the <em>move</em> keyword is applied to the <em>P</em>
point of the <em>rotate</em> keyword.</p>
<hr class="docutils" />
<p>Styles with a <em>kk</em> 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 in
<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.</p>
<p>The code using the region (such as a fix or compute) must also be supported
by Kokkos or no acceleration will occur. Currently, only <em>block</em> style
regions are supported by Kokkos.</p>
<p>These accelerated styles are part of the Kokkos package. They are
only enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>A prism cannot be of 0.0 thickness in any dimension; use a small z
thickness for 2d simulations. For 2d simulations, the xz and yz
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<span class="n">make</span> <span class="n">g</span><span class="o">++</span> <span class="c1"># build LAMMPS for your platform</span>
</pre></div>
</div>
<p>Second, use a restart filename which contains ”.mpiio”. Note that it
does not have to end in ”.mpiio”, just contain those characters.
Unlike MPI-IO dump files, a particular restart file must be both
written and read using MPI-IO.</p>
<p>Restart files are written on timesteps that are a multiple of N but
not on the first timestep of a run or minimization. You can use the
<a class="reference internal" href="write_restart.html"><span class="doc">write_restart</span></a> command to write a restart file
before a run begins. A restart file is not written on the last
timestep of a run unless it is a multiple of N. A restart file is
written on the last timestep of a minimization if N > 0 and the
minimization converges.</p>
<p>Instead of a numeric value, N can be specifed as an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a>, which should be specified as v_name, where
name is the variable name. In this case, the variable is evaluated at
the beginning of a run to determine the next timestep at which a
restart file will be written out. On that timestep, the variable will
be evaluated again to determine the next timestep, etc. Thus the
variable should return timestep values. See the stagger() and
logfreq() and stride() math functions for <a class="reference internal" href="variable.html"><span class="doc">equal-style variables</span></a>, as examples of useful functions to use in
this context. Other similar math functions could easily be added as
options for <a class="reference internal" href="variable.html"><span class="doc">equal-style variables</span></a>.</p>
<p>For example, the following commands will write restart files
every step from 1100 to 1200, and could be useful for debugging
a simulation where something goes wrong at step 1163:</p>
<p>See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for information about
what is stored in a restart file.</p>
<p>Restart files can be read by a <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
command to restart a simulation from a particular state. Because the
file is binary (to enable exact restarts), it may not be readable on
another machine. In this case, you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-r command-line switch</span></a> to convert a restart file to a data
file.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Although the purpose of restart files is to enable restarting a
simulation from where it left off, not all information about a
simulation is stored in the file. For example, the list of fixes that
were specified during the initial run is not stored, which means the
new input script must specify any fixes you want to use. Even when
restart information is stored in the file, as it is for some fixes,
commands may need to be re-specified in the new input script, in order
to re-use that information. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
command for information about what is stored in a restart file.</p>
</div>
<hr class="docutils" />
<p>The optional <em>nfile</em> or <em>fileper</em> keywords can be used in conjunction
with the “%” wildcard character in the specified restart file name(s).
As explained above, the “%” character causes the restart file to be
written in pieces, one piece for each of P processors. By default P =
the number of processors the simulation is running on. The <em>nfile</em> or
<em>fileper</em> keyword can be used to set P to a smaller value, which can
be more efficient when running on a large number of processors.</p>
<p>The <em>nfile</em> keyword sets P to the specified Nf value. For example, if
Nf = 4, and the simulation is running on 100 processors, 4 files will
be written, by processors 0,25,50,75. Each will collect information
from itself and the next 24 processors and write it to a restart file.</p>
<p>For the <em>fileper</em> keyword, the specified value of Np means write one
file for every Np processors. For example, if Np = 4, every 4th
processor (0,4,8,12,etc) will collect information from itself and the
next 3 processors and write it to a restart file.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>To write and read restart files in parallel with MPI-IO, the MPIIO
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>When you run in 2-partition mode with the <em>verlet/split</em> style, the
thermodyanmic data for the entire simulation will be output to the log
and screen file of the 1st partition, which are log.lammps.0 and
screen.0 by default; see the “-plog and -pscreen command-line
switches”Section_start.html#start_7 to change this. The log and
screen file for the 2nd partition will not contain thermodynamic
output beyone the 1st timestep of the run.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
performance details of the speed-up offered by the <em>verlet/split</em>
style. One important performance consideration is the assignemnt of
logical processors in the 2 partitions to the physical cores of a
parallel machine. The <a class="reference internal" href="processors.html"><span class="doc">processors</span></a> command has
options to support this, and strategies are discussed in
<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual.</p>
<hr class="docutils" />
<p>The <em>respa</em> style implements the rRESPA multi-timescale integrator
<a class="reference internal" href="#tuckerman"><span class="std std-ref">(Tuckerman)</span></a> with N hierarchical levels, where level 1 is
the innermost loop (shortest timestep) and level N is the outermost
loop (largest timestep). The loop factor arguments specify what the
looping factor is between levels. N1 specifies the number of
iterations of level 1 for a single iteration of level 2, N2 is the
iterations of level 2 per iteration of level 3, etc. N-1 looping
parameters must be specified.</p>
<p>The <a class="reference internal" href="timestep.html"><span class="doc">timestep</span></a> command sets the timestep for the
outermost rRESPA level. Thus if the example command above for a
4-level rRESPA had an outer timestep of 4.0 fmsec, the inner timestep
would be 8x smaller or 0.5 fmsec. All other LAMMPS commands that
specify number of timesteps (e.g. <a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify</span></a>
parameters, <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> every N timesteps, etc) refer to the
outermost timesteps.</p>
<p>The rRESPA keywords enable you to specify at what level of the
hierarchy various forces will be computed. If not specified, the
defaults are that bond forces are computed at level 1 (innermost
loop), angle forces are computed where bond forces are, dihedral
forces are computed where angle forces are, improper forces are
computed where dihedral forces are, pair forces are computed at the
outermost level, and kspace forces are computed where pair forces are.
The inner, middle, outer forces have no defaults.</p>
<p>For fixes that support it, the rRESPA level at which a given fix is
active, can be selected through the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command.</p>
<p>The <em>inner</em> and <em>middle</em> keywords take additional arguments for
cutoffs that are used by the pairwise force computations. If the 2
cutoffs for <em>inner</em> are 5.0 and 6.0, this means that all pairs up to
6.0 apart are computed by the inner force. Those between 5.0 and 6.0
have their force go ramped to 0.0 so the overlap with the next regime
(middle or outer) is smooth. The next regime (middle or outer) will
compute forces for all pairs from 5.0 outward, with those from 5.0 to
6.0 having their value ramped in an inverse manner.</p>
<p>Only some pair potentials support the use of the <em>inner</em> and <em>middle</em>
and <em>outer</em> keywords. If not, only the <em>pair</em> keyword can be used
with that pair style, meaning all pairwise forces are computed at the
same rRESPA level. See the doc pages for individual pair styles for
details.i</p>
<p>Another option for using pair potentials with rRESPA is with the
<em>hybrid</em> keyword, which requires the use of the <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid or hybrid/overlay</span></a> command. In this scenario, different
sub-styles of the hybrid pair style are evaluated at different rRESPA
levels. This can be useful, for example, to set different timesteps
for hybrid coarse-grained/all-atom models. The <em>hybrid</em> keyword
requires as many level assignments as there are hybrid substyles,
which assigns each sub-style to a rRESPA level, following their order
of definition in the pair_style command. Since the <em>hybrid</em> keyword
operates on pair style computations, it is mututally exclusive with
either the <em>pair</em> or the <em>inner</em>/<em>middle</em>/<em>outer</em> keywords.</p>
<p>When using rRESPA (or for any MD simulation) care must be taken to
choose a timestep size(s) that insures the Hamiltonian for the chosen
ensemble is conserved. For the constant NVE ensemble, total energy
must be conserved. Unfortunately, it is difficult to know <em>a priori</em>
how well energy will be conserved, and a fairly long test simulation
(~10 ps) is usually necessary in order to verify that no long-term
drift in energy occurs with the trial set of parameters.</p>
<p>With that caveat, a few rules-of-thumb may be useful in selecting
<em>respa</em> settings. The following applies mostly to biomolecular
simulations using the CHARMM or a similar all-atom force field, but
the concepts are adaptable to other problems. Without SHAKE, bonds
involving hydrogen atoms exhibit high-frequency vibrations and require
a timestep on the order of 0.5 fmsec in order to conserve energy. The
relatively inexpensive force computations for the bonds, angles,
impropers, and dihedrals can be computed on this innermost 0.5 fmsec
step. The outermost timestep cannot be greater than 4.0 fmsec without
risking energy drift. Smooth switching of forces between the levels
of the rRESPA hierarchy is also necessary to avoid drift, and a 1-2
angstrom “healing distance” (the distance between the outer and inner
cutoffs) works reasonably well. We thus recommend the following
settings for use of the <em>respa</em> style without SHAKE in biomolecular
<p>The <em>respa/omp</em> styles is a variant of <em>respa</em> adapted for use with
pair, bond, angle, dihedral, improper, or kspace styles with an <em>omp</em>
suffix. It is functionally equivalent to <em>respa</em> but performs additional
operations required for managing <em>omp</em> styles. For more on <em>omp</em> styles
see the <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual.
Accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.</p>
<p>You can specify <em>respa/omp</em> explicitly in your input script, or
you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a>
when you invoke LAMMPS, or you can use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a>
command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The <em>verlet/split</em> style can only be used if LAMMPS was built with the
REPLICA package. Correspondingly the <em>respa/omp</em> style is available only
if the USER-OMP package was included. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
section for more info on packages.</p>
<p>Whenever using rRESPA, the user should experiment with trade-offs in
speed and accuracy for their system, and verify that they are
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>style = <em>atom</em> or <em>type</em> or <em>mol</em> or <em>group</em> or <em>region</em></li>
<li>ID = atom ID range or type range or mol ID range or group ID or region ID</li>
<li>one or more keyword/value pairs may be appended</li>
<li>keyword = <em>type</em> or <em>type/fraction</em> or <em>mol</em> or <em>x</em> or <em>y</em> or <em>z</em> or <em>charge</em> or <em>dipole</em> or <em>dipole/random</em> or <em>quat</em> or <em>quat/random</em> or <em>diameter</em> or <em>shape</em> or <em>length</em> or <em>tri</em> or <em>theta</em> or <em>theta/random</em> or <em>angmom</em> or <em>omega</em> or <em>mass</em> or <em>density</em> or <em>volume</em> or <em>image</em> or <em>bond</em> or <em>angle</em> or <em>dihedral</em> or <em>improper</em> or <em>meso/e</em> or <em>meso/cv</em> or <em>meso/rho</em> or <em>smd/contact/radius</em> or <em>smd/mass/density</em> or <em>dpd/theta</em> or <em>i_name</em> or <em>d_name</em></li>
</ul>
<pre class="literal-block">
<em>type</em> value = atom type
value can be an atom-style variable (see below)
<em>type/fraction</em> values = type fraction seed
type = new atom type
fraction = fraction of selected atoms to set to new atom type
seed = random # seed (positive integer)
<em>mol</em> value = molecule ID
value can be an atom-style variable (see below)
<em>x</em>,<em>y</em>,<em>z</em> value = atom coordinate (distance units)
value can be an atom-style variable (see below)
<em>charge</em> value = atomic charge (charge units)
value can be an atom-style variable (see below)
<em>dipole</em> values = x y z
x,y,z = orientation of dipole moment vector
any of x,y,z can be an atom-style variable (see below)
<em>dipole/random</em> value = seed Dlen
seed = random # seed (positive integer) for dipole moment orientations
Dlen = magnitude of dipole moment (dipole units)
<em>quat</em> values = a b c theta
a,b,c = unit vector to rotate particle around via right-hand rule
theta = rotation angle (degrees)
any of a,b,c,theta can be an atom-style variable (see below)
<em>quat/random</em> value = seed
seed = random # seed (positive integer) for quaternion orientations
<em>diameter</em> value = diameter of spherical particle (distance units)
value can be an atom-style variable (see below)
<em>shape</em> value = Sx Sy Sz
Sx,Sy,Sz = 3 diameters of ellipsoid (distance units)
<em>length</em> value = len
len = length of line segment (distance units)
len can be an atom-style variable (see below)
<em>tri</em> value = side
side = side length of equilateral triangle (distance units)
side can be an atom-style variable (see below)
<em>theta</em> value = angle (degrees)
angle = orientation of line segment with respect to x-axis
angle can be an atom-style variable (see below)
<em>theta/random</em> value = seed
seed = random # seed (positive integer) for line segment orienations
<em>angmom</em> values = Lx Ly Lz
Lx,Ly,Lz = components of angular momentum vector (distance-mass-velocity units)
any of Lx,Ly,Lz can be an atom-style variable (see below)
<em>omega</em> values = Wx Wy Wz
Wx,Wy,Wz = components of angular velocity vector (radians/time units)
any of wx,wy,wz can be an atom-style variable (see below)
<em>mass</em> value = per-atom mass (mass units)
value can be an atom-style variable (see below)
<em>density</em> value = particle density for sphere or ellipsoid (mass/distance^3 or mass/distance^2 or mass/distance units, depending on dimensionality of particle)
value can be an atom-style variable (see below)
<em>volume</em> value = particle volume for Peridynamic particle (distance^3 units)
value can be an atom-style variable (see below)
<em>image</em> nx ny nz
nx,ny,nz = which periodic image of the simulation box the atom is in
<em>bond</em> value = bond type for all bonds between selected atoms
<em>angle</em> value = angle type for all angles between selected atoms
<em>dihedral</em> value = dihedral type for all dihedrals between selected atoms
<em>improper</em> value = improper type for all impropers between selected atoms
<em>meso/e</em> value = energy of SPH particles (need units)
value can be an atom-style variable (see below)
<em>meso/cv</em> value = heat capacity of SPH particles (need units)
value can be an atom-style variable (see below)
<em>meso/rho</em> value = density of SPH particles (need units)
value can be an atom-style variable (see below)
<em>smd/contact/radius</em> = radius for short range interactions, i.e. contact and friction
value can be an atom-style variable (see below)
<em>smd/mass/density</em> = set particle mass based on volume by providing a mass density
value can be an atom-style variable (see below)
<em>dpd/theta</em> value = internal temperature of DPD particles (temperature units)
value can be an atom-style variable (see below)
value can be NULL which sets internal temp of each particle to KE temp
<em>i_name</em> value = value for custom integer vector with name
<em>d_name</em> value = value for custom floating-point vector with name
commands, this command changes those assignments. This can be useful
for overriding the default values assigned by the
<a class="reference internal" href="create_atoms.html"><span class="doc">create_atoms</span></a> command (e.g. charge = 0.0). It can
be useful for altering pairwise and molecular force interactions,
since force-field coefficients are defined in terms of types. It can
be used to change the labeling of atoms by atom type or molecule ID
when they are output in <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> files. It can also be useful
for debugging purposes; i.e. positioning an atom at a precise location
to compute subsequent forces or energy.</p>
<p>Note that the <em>style</em> and <em>ID</em> arguments determine which atoms have
their properties reset. The remaining keywords specify which
properties to reset and what the new values are. Some strings like
<em>type</em> or <em>mol</em> can be used as a style and/or a keyword.</p>
<hr class="docutils" />
<p>This section describes how to select which atoms to change
the properties of, via the <em>style</em> and <em>ID</em> arguments.</p>
<p>The style <em>atom</em> selects all the atoms in a range of atom IDs. The
style <em>type</em> selects all the atoms in a range of types. The style
<em>mol</em> selects all the atoms in a range of molecule IDs.</p>
<p>In each of the range cases, the range can be specified as a single
numeric value, or a wildcard asterisk can be used to specify a range
-of values. This takes the form “*” or “<em>n” or “n</em>” or “m*n”. For
+of values. This takes the form “*” or “*n” or “n*” or “m*n”. For
example, for the style <em>type</em>, if N = the number of atom types, then
an asterisk with no numeric values means all types from 1 to N. A
leading asterisk means all types from 1 to n (inclusive). A trailing
asterisk means all types from n to N (inclusive). A middle asterisk
means all types from m to n (inclusive). For all the styles except
<em>mol</em>, the lowest value for the wildcard is 1; for <em>mol</em> it is 0.</p>
<p>The style <em>group</em> selects all the atoms in the specified group. The
style <em>region</em> selects all the atoms in the specified geometric
region. See the <a class="reference internal" href="group.html"><span class="doc">group</span></a> and <a class="reference internal" href="region.html"><span class="doc">region</span></a> commands
for details of how to specify a group or region.</p>
<hr class="docutils" />
<p>This section describes the keyword options for which properties to
change, for the selected atoms.</p>
<p>Note that except where explicitly prohibited below, all of the
keywords allow an <a class="reference internal" href="variable.html"><span class="doc">atom-style or atomfile-style variable</span></a> to be used as the specified value(s). If the
value is a variable, it should be specified as v_name, where name is
the variable name. In this case, the variable will be evaluated, and
its resulting per-atom value used to determine the value assigned to
each selected atom. Note that the per-atom value from the variable
will be ignored for atoms that are not selected via the <em>style</em> and
<em>ID</em> settings explained above. A simple way to use per-atom values
from the variable to reset a property for all atoms is to use style
<em>atom</em> with <em>ID</em> = “*”; this selects all atom IDs.</p>
<p>Atom-style variables can specify formulas with various mathematical
functions, and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command
keywords for the simulation box parameters and timestep and elapsed
time. They can also include per-atom values, such as atom
coordinates. Thus it is easy to specify a time-dependent or
spatially-dependent set of per-atom values. As explained on the
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> doc page, atomfile-style variables can be
used in place of atom-style variables, and thus as arguments to the
set command. Atomfile-style variables read their per-atoms values
from a file.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Atom-style and atomfile-style variables return floating point
per-atom values. If the values are assigned to an integer variable,
such as the molecule ID, then the floating point value is truncated to
its integer portion, e.g. a value of 2.6 would become 2.</p>
</div>
<p>Keyword <em>type</em> sets the atom type for all selected atoms. The
specified value must be from 1 to ntypes, where ntypes was set by the
<a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> command or the <em>atom types</em> field in the
header of the data file read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
command.</p>
<p>Keyword <em>type/fraction</em> sets the atom type for a fraction of the
selected atoms. The actual number of atoms changed is not guaranteed
to be exactly the requested fraction, but should be statistically
close. Random numbers are used in such a way that a particular atom
is changed or not changed, regardless of how many processors are being
used. This keyword does not allow use of an atom-style variable.</p>
<p>Keyword <em>mol</em> sets the molecule ID for all selected atoms. The <a class="reference internal" href="atom_style.html"><span class="doc">atom style</span></a> being used must support the use of molecule
IDs.</p>
<p>Keywords <em>x</em>, <em>y</em>, <em>z</em>, and <em>charge</em> set the coordinates or charge of
all selected atoms. For <em>charge</em>, the <a class="reference internal" href="atom_style.html"><span class="doc">atom style</span></a>
being used must support the use of atomic charge.</p>
<p>Keyword <em>dipole</em> uses the specified x,y,z values as components of a
vector to set as the orientation of the dipole moment vectors of the
selected atoms. The magnitude of the dipole moment is set
by the length of this orientation vector.</p>
<p>Keyword <em>dipole/random</em> randomizes the orientation of the dipole
moment vectors for the selected atoms and sets the magnitude of each
to the specified <em>Dlen</em> value. For 2d systems, the z component of the
orientation is set to 0.0. Random numbers are used in such a way that
the orientation of a particular atom is the same, regardless of how
many processors are being used. This keyword does not allow use of an
atom-style variable.</p>
<p>Keyword <em>quat</em> uses the specified values to create a quaternion
(4-vector) that represents the orientation of the selected atoms. The
particles must define a quaternion for their orientation
(e.g. ellipsoids, triangles, body particles) as defined by the
<a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a> command. Note that particles defined by
<a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a> have 3 shape parameters. The 3
values must be non-zero for each particle set by this command. They
are used to specify the aspect ratios of an ellipsoidal particle,
which is oriented by default with its x-axis along the simulation
box’s x-axis, and similarly for y and z. If this body is rotated (via
the right-hand rule) by an angle theta around a unit rotation vector
(a,b,c), then the quaternion that represents its new orientation is
given by (cos(theta/2), a*sin(theta/2), b*sin(theta/2),
c*sin(theta/2)). The theta and a,b,c values are the arguments to the
<em>quat</em> keyword. LAMMPS normalizes the quaternion in case (a,b,c) was
not specified as a unit vector. For 2d systems, the a,b,c values are
ignored, since a rotation vector of (0,0,1) is the only valid choice.</p>
<p>Keyword <em>quat/random</em> randomizes the orientation of the quaternion for
the selected atoms. The particles must define a quaternion for their
orientation (e.g. ellipsoids, triangles, body particles) as defined by
the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a> command. Random numbers are used in
such a way that the orientation of a particular atom is the same,
regardless of how many processors are being used. For 2d systems,
only orientations in the xy plane are generated. As with keyword
<em>quat</em>, for ellipsoidal particles, the 3 shape values must be non-zero
for each particle set by this command. This keyword does not allow
use of an atom-style variable.</p>
<p>Keyword <em>diameter</em> sets the size of the selected atoms. The particles
must be finite-size spheres as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style sphere</span></a> command. The diameter of a particle can be
set to 0.0, which means they will be treated as point particles. Note
that this command does not adjust the particle mass, even if it was
defined with a density, e.g. via the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
command.</p>
<p>Keyword <em>shape</em> sets the size and shape of the selected atoms. The
particles must be ellipsoids as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a> command. The <em>Sx</em>, <em>Sy</em>, <em>Sz</em> settings are
the 3 diameters of the ellipsoid in each direction. All 3 can be set
to the same value, which means the ellipsoid is effectively a sphere.
They can also all be set to 0.0 which means the particle will be
treated as a point particle. Note that this command does not adjust
the particle mass, even if it was defined with a density, e.g. via the
<p>Keyword <em>length</em> sets the length of selected atoms. The particles
must be line segments as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style line</span></a> command. If the specified value is non-zero the
line segment is (re)set to a length = the specified value, centered
around the particle position, with an orientation along the x-axis.
If the specified value is 0.0, the particle will become a point
particle. Note that this command does not adjust the particle mass,
even if it was defined with a density, e.g. via the
<p>Keyword <em>tri</em> sets the size of selected atoms. The particles must be
triangles as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style tri</span></a> command.
If the specified value is non-zero the triangle is (re)set to be an
equilateral triangle in the xy plane with side length = the specified
value, with a centroid at the particle position, with its base
parallel to the x axis, and the y-axis running from the center of the
base to the top point of the triangle. If the specified value is 0.0,
the particle will become a point particle. Note that this command
does not adjust the particle mass, even if it was defined with a
density, e.g. via the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command.</p>
<p>Keyword <em>theta</em> sets the orientation of selected atoms. The particles
must be line segments as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style line</span></a> command. The specified value is used to set the
orientation angle of the line segments with respect to the x axis.</p>
<p>Keyword <em>theta/random</em> randomizes the orientation of theta for the
selected atoms. The particles must be line segments as defined by the
<a class="reference internal" href="atom_style.html"><span class="doc">atom_style line</span></a> command. Random numbers are used in
such a way that the orientation of a particular atom is the same,
regardless of how many processors are being used. This keyword does
not allow use of an atom-style variable.</p>
<p>Keyword <em>angmom</em> sets the angular momentum of selected atoms. The
particles must be ellipsoids as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a> command or triangles as defined by the
of the particles is set to the 3 specified components.</p>
<p>Keyword <em>omega</em> sets the angular velocity of selected atoms. The
particles must be spheres as defined by the “atom_style sphere”_
atom_style.html command. The angular velocity vector of the particles
is set to the 3 specified components.</p>
<p>Keyword <em>mass</em> sets the mass of all selected particles. The particles
must have a per-atom mass attribute, as defined by the
<a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a> command. See the “mass” command for how
to set mass values on a per-type basis.</p>
<p>Keyword <em>density</em> also sets the mass of all selected particles, but in
a different way. The particles must have a per-atom mass attribute,
as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a> command. If the atom
has a radius attribute (see <a class="reference internal" href="atom_style.html"><span class="doc">atom_style sphere</span></a>) and
its radius is non-zero, its mass is set from the density and particle
volume. If the atom has a shape attribute (see <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a>) and its 3 shape parameters are non-zero,
then its mass is set from the density and particle volume. If the
atom has a length attribute (see <a class="reference internal" href="atom_style.html"><span class="doc">atom_style line</span></a>)
and its length is non-zero, then its mass is set from the density and
line segment length (the input density is assumed to be in
mass/distance units). If the atom has an area attribute (see
<a class="reference internal" href="atom_style.html"><span class="doc">atom_style tri</span></a>) and its area is non-zero, then its
mass is set from the density and triangle area (the input density is
assumed to be in mass/distance^2 units). If none of these cases are
valid, then the mass is set to the density value directly (the input
density is assumed to be in mass units).</p>
<p>Keyword <em>volume</em> sets the volume of all selected particles.
Currently, only the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style peri</span></a> command defines
particles with a volume attribute. Note that this command does not
adjust the particle mass.</p>
<p>Keyword <em>image</em> sets which image of the simulation box the atom is
considered to be in. An image of 0 means it is inside the box as
defined. A value of 2 means add 2 box lengths to get the true value.
A value of -1 means subtract 1 box length to get the true value.
LAMMPS updates these flags as atoms cross periodic boundaries during
the simulation. The flags can be output with atom snapshots via the
<a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command. If a value of NULL is specified for any of
nx,ny,nz, then the current image value for that dimension is
unchanged. For non-periodic dimensions only a value of 0 can be
specified. This keyword does not allow use of atom-style variables.
This command can be useful after a system has been equilibrated and
atoms have diffused one or more box lengths in various directions.
This command can then reset the image values for atoms so that they
are effectively inside the simulation box, e.g if a diffusion
coefficient is about to be measured via the <a class="reference internal" href="compute_msd.html"><span class="doc">compute msd</span></a> command. Care should be taken not to reset the
image flags of two atoms in a bond to the same value if the bond
straddles a periodic boundary (rather they should be different by +/-
1). This will not affect the dynamics of a simulation, but may mess
up analysis of the trajectories if a LAMMPS diagnostic or your own
analysis relies on the image flags to unwrap a molecule which
straddles the periodic box.</p>
<p>Keywords <em>bond</em>, <em>angle</em>, <em>dihedral</em>, and <em>improper</em>, set the bond
type (angle type, etc) of all bonds (angles, etc) of selected atoms to
the specified value from 1 to nbondtypes (nangletypes, etc). All
atoms in a particular bond (angle, etc) must be selected atoms in
order for the change to be made. The value of nbondtype (nangletypes,
etc) was set by the <em>bond types</em> (<em>angle types</em>, etc) field in the
header of the data file read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
command. These keywords do not allow use of an atom-style variable.</p>
<p>Keywords <em>meso/e</em>, <em>meso/cv</em>, and <em>meso/rho</em> set the energy, heat
capacity, and density of smmothed particle hydrodynamics (SPH)
particles. See <a class="reference external" href="USER/sph/SPH_LAMMPS_userguide.pdf">this PDF guide</a> to
using SPH in LAMMPS.</p>
<p>Keyword <em>smd/mass/density</em> sets the mass of all selected particles,
but it is only applicable to the Smooth Mach Dynamics package
USER-SMD. It assumes that the particle volume has already been
correctly set and calculates particle mass from the provided mass
density value.</p>
<p>Keyword <em>smd/contact/radius</em> only applies to simulations with the
Smooth Mach Dynamics package USER-SMD. Itsets an interaction radius
for computing short-range interactions, e.g. repulsive forces to
prevent different individual physical bodies from penetrating each
other. Note that the SPH smoothing kernel diameter used for computing
long range, nonlocal interactions, is set using the <em>diameter</em>
keyword.</p>
<p>Keyword <em>dpd/theta</em> sets the internal temperature of a DPD particle as
defined by the USER-DPD package. If the specified value is a number
it must be >= 0.0. If the specified value is NULL, then the kinetic
temperature Tkin of each particle is computed as 3/2 k Tkin = KE = 1/2
m v^2 = 1/2 m (vx*vx+vy*vy+vz*vz). Each particle’s internal
temperature is set to Tkin. If the specified value is an atom-style
variable, then the variable is evaluated for each particle. If a
value >= 0.0, the internal temperature is set to that value. If it is
< 0.0, the computation of Tkin is performed and the internal
temperature is set to that value.</p>
<p>Keywords <em>i_name</em> and <em>d_name</em> refer to custom integer and
floating-point properties that have been added to each atom via the
<a class="reference internal" href="fix_property_atom.html"><span class="doc">fix property/atom</span></a> command. When that command
is used specific names are given to each attribute which are what is
specified as the “name” portion of <em>i_name</em> or <em>d_name</em>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>You cannot set an atom attribute (e.g. <em>mol</em> or <em>q</em> or <em>volume</em>) if
the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a> does not have that attribute.</p>
<p>This command requires inter-processor communication to coordinate the
setting of bond types (angle types, etc). This means that your system
must be ready to perform a simulation before using one of these
keywords (force fields set, atom mass set, etc). This is not
necessary for other keywords.</p>
<p>Using the <em>region</em> style with the bond (angle, etc) keywords can give
unpredictable results if there are bonds (angles, etc) that straddle
periodic boundaries. This is because the region may only extend up to
the boundary and partner atoms in the bond (angle, etc) may have
coordinates outside the simulation box if they are ghost atoms.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>one or more keyword/value pairs may be appended</li>
<li>keyword = <em>amber</em> or <em>charmm</em> or <em>dreiding</em> or <em>fene</em> or <em>lj/coul</em> or <em>lj</em> or <em>coul</em> or <em>angle</em> or <em>dihedral</em> or <em>extra</em></li>
</ul>
<pre class="literal-block">
<em>amber</em> values = none
<em>charmm</em> values = none
<em>dreiding</em> values = none
<em>fene</em> values = none
<em>lj/coul</em> values = w1,w2,w3
w1,w2,w3 = weights (0.0 to 1.0) on pairwise Lennard-Jones and Coulombic interactions
<em>lj</em> values = w1,w2,w3
w1,w2,w3 = weights (0.0 to 1.0) on pairwise Lennard-Jones interactions
<em>coul</em> values = w1,w2,w3
w1,w2,w3 = weights (0.0 to 1.0) on pairwise Coulombic interactions
<em>angle</em> value = <em>yes</em> or <em>no</em>
<em>dihedral</em> value = <em>yes</em> or <em>no</em>
<em>extra</em> value = N
N = number of extra 1-2,1-3,1-4 interactions to save space for
<p>Set weighting coefficients for pairwise energy and force contributions
between pairs of atoms that are also permanently bonded to each other,
either directly or via one or two intermediate bonds. These weighting
factors are used by nearly all <a class="reference internal" href="pair_style.html"><span class="doc">pair styles</span></a> in LAMMPS
that compute simple pairwise interactions. Permanent bonds between
atoms are specified by defining the bond topology in the data file
read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command. Typically a
<a class="reference internal" href="bond_style.html"><span class="doc">bond_style</span></a> command is also used to define a bond
potential. The rationale for using these weighting factors is that
the interaction between a pair of bonded atoms is all (or mostly)
specified by the bond, angle, dihedral potentials, and thus the
non-bonded Lennard-Jones or Coulombic interaction between the pair of
atoms should be excluded (or reduced by a weighting factor).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">These weighting factors are NOT used by <a class="reference internal" href="pair_style.html"><span class="doc">pair styles</span></a> that compute many-body interactions, since the
“bonds” that result from such interactions are not permanent, but are
created and broken dynamically as atom conformations change. Examples
of pair styles in this category are EAM, MEAM, Stillinger-Weber,
Tersoff, COMB, AIREBO, and ReaxFF. In fact, it generally makes no
sense to define permanent bonds between atoms that interact via these
potentials, though such bonds may exist elsewhere in your system,
e.g. when using the <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid</span></a> command.
Thus LAMMPS ignores special_bonds settings when manybody potentials
are calculated.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Unlike some commands in LAMMPS, you cannot use this command
multiple times in an incremental fashion: e.g. to first set the LJ
settings and then the Coulombic ones. Each time you use this command
it sets all the coefficients to default values and only overrides the
one you specify, so you should set all the options you need each time
you use it. See more details at the bottom of this page.</p>
</div>
<p>The Coulomb factors are applied to any Coulomb (charge interaction)
term that the potential calculates. The LJ factors are applied to the
remaining terms that the potential calculates, whether they represent
LJ interactions or not. The weighting factors are a scaling
pre-factor on the energy and force between the pair of atoms. A value
of 1.0 means include the full interaction; a value of 0.0 means
exclude it completely.</p>
<p>The 1st of the 3 coefficients (LJ or Coulombic) is the weighting
factor on 1-2 atom pairs, which are pairs of atoms directly bonded to
each other. The 2nd coefficient is the weighting factor on 1-3 atom
pairs which are those separated by 2 bonds (e.g. the two H atoms in a
water molecule). The 3rd coefficient is the weighting factor on 1-4
atom pairs which are those separated by 3 bonds (e.g. the 1st and 4th
atoms in a dihedral interaction). Thus if the 1-2 coefficient is set
to 0.0, then the pairwise interaction is effectively turned off for
all pairs of atoms bonded to each other. If it is set to 1.0, then
that interaction will be at full strength.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For purposes of computing weighted pairwise interactions, 1-3
and 1-4 interactions are not defined from the list of angles or
dihedrals used by the simulation. Rather, they are inferred
topologically from the set of bonds specified when the simulation is
defined from a data or restart file (see <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> or
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands). Thus the set of
1-2,1-3,1-4 interactions that the weights apply to is the same whether
angle and dihedral potentials are computed or not, and remains the
same even if bonds are constrained, or turned off, or removed during a
simulation.</p>
</div>
<p>The two exceptions to this rule are (a) if the <em>angle</em> or <em>dihedral</em>
keywords are set to <em>yes</em> (see below), or (b) if the
<a class="reference internal" href="delete_bonds.html"><span class="doc">delete_bonds</span></a> command is used with the <em>special</em>
option that recomputes the 1-2,1-3,1-4 topologies after bonds are
deleted; see the <a class="reference internal" href="delete_bonds.html"><span class="doc">delete_bonds</span></a> command for more
details.</p>
<p>The <em>amber</em> keyword sets the 3 coefficients to 0.0, 0.0, 0.5 for LJ
interactions and to 0.0, 0.0, 0.8333 for Coulombic interactions, which
is the default for a commonly used version of the AMBER force field,
where the last value is really 5/6. See <a class="reference internal" href="#cornell"><span class="std std-ref">(Cornell)</span></a> for a
description of the AMBER force field.</p>
<p>The <em>charmm</em> keyword sets the 3 coefficients to 0.0, 0.0, 0.0 for both
LJ and Coulombic interactions, which is the default for a commonly
used version of the CHARMM force field. Note that in pair styles
<em>lj/charmm/coul/charmm</em> and <em>lj/charmm/coul/long</em> the 1-4 coefficients
are defined explicitly, and these pairwise contributions are computed
commands for more information. See <a class="reference internal" href="#mackerell"><span class="std std-ref">(MacKerell)</span></a> for a
description of the CHARMM force field.</p>
<p>The <em>dreiding</em> keyword sets the 3 coefficients to 0.0, 0.0, 1.0 for both
LJ and Coulombic interactions, which is the default for the Dreiding
force field, as discussed in <a class="reference internal" href="#mayo"><span class="std std-ref">(Mayo)</span></a>.</p>
<p>The <em>fene</em> keyword sets the 3 coefficients to 0.0, 1.0, 1.0 for both
LJ and Coulombic interactions, which is consistent with a
coarse-grained polymer model with <a class="reference internal" href="bond_fene.html"><span class="doc">FENE bonds</span></a>. See
<a class="reference internal" href="#kremer"><span class="std std-ref">(Kremer)</span></a> for a description of FENE bonds.</p>
<p>The <em>lj/coul</em>, <em>lj</em>, and <em>coul</em> keywords allow the 3 coefficients to
be set explicitly. The <em>lj/coul</em> keyword sets both the LJ and
Coulombic coefficients to the same 3 values. The <em>lj</em> and <em>coul</em>
keywords only set either the LJ or Coulombic coefficients. Use both
of them if you wish to set the LJ coefficients to different values
than the Coulombic coefficients.</p>
<p>The <em>angle</em> keyword allows the 1-3 weighting factor to be ignored for
individual atom pairs if they are not listed as the first and last
atoms in any angle defined in the simulation or as 1,3 or 2,4 atoms in
any dihedral defined in the simulation. For example, imagine the 1-3
weighting factor is set to 0.5 and you have a linear molecule with 4
atoms and bonds as follows: 1-2-3-4. If your data file defines 1-2-3
as an angle, but does not define 2-3-4 as an angle or 1-2-3-4 as a
dihedral, then the pairwise interaction between atoms 1 and 3 will
always be weighted by 0.5, but different force fields use different
rules for weighting the pairwise interaction between atoms 2 and 4.
If the <em>angle</em> keyword is specified as <em>yes</em>, then the pairwise
interaction between atoms 2 and 4 will be unaffected (full weighting
of 1.0). If the <em>angle</em> keyword is specified as <em>no</em> which is the
default, then the 2,4 interaction will also be weighted by 0.5.</p>
<p>The <em>dihedral</em> keyword allows the 1-4 weighting factor to be ignored
for individual atom pairs if they are not listed as the first and last
atoms in any dihedral defined in the simulation. For example, imagine
the 1-4 weighting factor is set to 0.5 and you have a linear molecule
with 5 atoms and bonds as follows: 1-2-3-4-5. If your data file
defines 1-2-3-4 as a dihedral, but does not define 2-3-4-5 as a
dihedral, then the pairwise interaction between atoms 1 and 4 will
always be weighted by 0.5, but different force fields use different
rules for weighting the pairwise interaction between atoms 2 and 5.
If the <em>dihedral</em> keyword is specified as <em>yes</em>, then the pairwise
interaction between atoms 2 and 5 will be unaffected (full weighting
of 1.0). If the <em>dihedral</em> keyword is specified as <em>no</em> which is the
default, then the 2,5 interaction will also be weighted by 0.5.</p>
<p>The <em>extra</em> keyword can be used when additional bonds will be created
during a simulation run, e.g. by the <a class="reference internal" href="fix_bond_create.html"><span class="doc">fix bond/create</span></a> command. It can also be used if
molecules will be added to the system, e.g. via the <a class="reference internal" href="fix_deposit.html"><span class="doc">fix deposit</span></a>, or <a class="reference internal" href="fix_pour.html"><span class="doc">fix pour</span></a> commands, which
will have atoms with more special neighbors than any atom in the
current system has.</p>
<hr class="docutils" />
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">LAMMPS stores and maintains a data structure with a list of the
1st, 2nd, and 3rd neighbors of each atom (within the bond topology of
the system). If new bonds are created (or molecules added containing
atoms with more special neighbors), the size of this list needs to
grow. Note that adding a single bond always adds a new 1st neighbor
-but may also induce <em>many</em> new 2nd and 3rd neighbors, depending on the
+but may also induce *many* new 2nd and 3rd neighbors, depending on the
molecular topology of your system. Using the <em>extra</em> keyword leaves
empty space in the list for this N additional 1st, 2nd, or 3rd
neighbors to be added. If you do not do this, you may get an error
when bonds (or molecules) are added.</p>
</div>
<hr class="docutils" />
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you reuse this command in an input script, you should set all
the options you need each time. This command cannot be used a 2nd
time incrementally, e.g. to add some extra storage locations via the
<em>extra</em> keyword. E.g. these two commands:</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Run a temperature accelerated dynamics (TAD) simulation. This method
requires two or more partitions to perform NEB transition state
searches.</p>
<p>TAD is described in <a class="reference internal" href="#voter"><span class="std std-ref">this paper</span></a> by Art Voter. It is a method
that uses accelerated dynamics at an elevated temperature to generate
results at a specified lower temperature. A good overview of
accelerated dynamics methods for such systems is given in <a class="reference internal" href="#voter2"><span class="std std-ref">this review paper</span></a> from the same group. In general, these methods assume
that the long-time dynamics is dominated by infrequent events i.e. the
system is is confined to low energy basins for long periods,
punctuated by brief, randomly-occurring transitions to adjacent
basins. TAD is suitable for infrequent-event systems, where in
addition, the transition kinetics are well-approximated by harmonic
transition state theory (hTST). In hTST, the temperature dependence of
transition rates follows the Arrhenius relation. As a consequence a
set of event times generated in a high-temperature simulation can be
mapped to a set of much longer estimated times in the low-temperature
system. However, because this mapping involves the energy barrier of
the transition event, which is different for each event, the first
event at the high temperature may not be the earliest event at the low
temperature. TAD handles this by first generating a set of possible
events from the current basin. After each event, the simulation is
reflected backwards into the current basin. This is repeated until
the stopping criterion is satisfied, at which point the event with the
earliest low-temperature occurrence time is selected. The stopping
criterion is that the confidence measure be greater than
1-<em>delta</em>. The confidence measure is the probability that no earlier
low-temperature event will occur at some later time in the
high-temperature simulation. hTST provides an lower bound for this
probability, based on the user-specified minimum pre-exponential
factor (reciprocal of <em>tmax</em>).</p>
<p>In order to estimate the energy barrier for each event, the TAD method
invokes the <a class="reference internal" href="neb.html"><span class="doc">NEB</span></a> method. Each NEB replica runs on a
partition of processors. The current NEB implementation in LAMMPS
restricts you to having exactly one processor per replica. For more
information, see the documentation for the <a class="reference internal" href="neb.html"><span class="doc">neb</span></a> command. In
the current LAMMPS implementation of TAD, all the non-NEB TAD
operations are performed on the first partition, while the other
partitions remain idle. See <a class="reference internal" href="Section_howto.html#howto-5"><span class="std std-ref">Section_howto 5</span></a> of the manual for further discussion of
multi-replica simulations.</p>
<p>A TAD run has several stages, which are repeated each time an event is
performed. The logic for a TAD run is as follows:</p>
<p>Before this outer loop begins, the initial potential energy basin is
identified by quenching (an energy minimization, see below) the
initial state and storing the resulting coordinates for reference.</p>
<p>Inside the inner loop, dynamics is run continuously according to
whatever integrator has been specified by the user, stopping every
<em>t_event</em> steps to check if a transition event has occurred. This
check is performed by quenching the system and comparing the resulting
atom coordinates to the coordinates from the previous basin.</p>
<p>A quench is an energy minimization and is performed by whichever
algorithm has been defined by the <a class="reference internal" href="min_style.html"><span class="doc">min_style</span></a> command;
its default is the CG minimizer. The tolerances and limits for each
quench can be set by the <em>min</em> keyword. Note that typically, you do
not need to perform a highly-converged minimization to detect a
transition event.</p>
<p>The event check is performed by a compute with the specified
<em>compute-ID</em>. Currently there is only one compute that works with the
TAD commmand, which is the <a class="reference internal" href="compute_event_displace.html"><span class="doc">compute event/displace</span></a> command. Other
event-checking computes may be added. <a class="reference internal" href="compute_event_displace.html"><span class="doc">Compute event/displace</span></a> checks whether any atom in
the compute group has moved further than a specified threshold
distance. If so, an “event” has occurred.</p>
<p>The NEB calculation is similar to that invoked by the <a class="reference internal" href="neb.html"><span class="doc">neb</span></a>
command, except that the final state is generated internally, instead
of being read in from a file. The style of minimization performed by
NEB is determined by the <em>neb_style</em> keyword and must be a damped
dynamics minimizer. The tolerances and limits for each NEB
calculation can be set by the <em>neb</em> keyword. As discussed on the
<a class="reference internal" href="neb.html"><span class="doc">neb</span></a>, it is often advantageous to use a larger timestep for
NEB than for normal dyanmics. Since the size of the timestep set by
the <a class="reference internal" href="timestep.html"><span class="doc">timestep</span></a> command is used by TAD for performing
dynamics, there is a <em>neb_step</em> keyword which can be used to set a
larger timestep for each NEB calculation if desired.</p>
<hr class="docutils" />
<p>A key aspect of the TAD method is setting the stopping criterion
appropriately. If this criterion is too conservative, then many
events must be generated before one is finally executed. Conversely,
if this criterion is too aggressive, high-entropy high-barrier events
will be over-sampled, while low-entropy low-barrier events will be
under-sampled. If the lowest pre-exponential factor is known fairly
accurately, then it can be used to estimate <em>tmax</em>, and the value of
<em>delta</em> can be set to the desired confidence level e.g. <em>delta</em> = 0.05
corresponds to 95% confidence. However, for systems where the dynamics
are not well characterized (the most common case), it will be
necessary to experiment with the values of <em>delta</em> and <em>tmax</em> to get a
good trade-off between accuracy and performance.</p>
<p>A second key aspect is the choice of <em>t_hi</em>. A larger value greatly
increases the rate at which new events are generated. However, too
large a value introduces errors due to anharmonicity (not accounted
for within hTST). Once again, for any given system, experimentation is
necessary to determine the best value of <em>t_hi</em>.</p>
<hr class="docutils" />
<p>Five kinds of output can be generated during a TAD run: event
statistics, NEB statistics, thermodynamic output by each replica, dump
files, and restart files.</p>
<p>Event statistics are printed to the screen and master log.lammps file
each time an event is executed. The quantities are the timestep, CPU
time, global event number <em>N</em>, local event number <em>M</em>, event status,
energy barrier, time margin, <em>t_lo</em> and <em>delt_lo</em>. The timestep is
the usual LAMMPS timestep, which corresponds to the high-temperature
time at which the event was detected, in units of timestep. The CPU
time is the total processor time since the start of the TAD run. The
global event number <em>N</em> is a counter that increments with each
executed event. The local event number <em>M</em> is a counter that resets to
zero upon entering each new basin. The event status is <em>E</em> when an
event is executed, and is <em>D</em> for an event that is detected, while
<em>DF</em> is for a detected event that is also the earliest (first) event
at the low temperature.</p>
<p>The time margin is the ratio of the high temperature time in the
current basin to the stopping time. This last number can be used to
judge whether the stopping time is too short or too long (see above).</p>
<p><em>t_lo</em> is the low-temperature event time when the current basin was
-entered, in units of timestep. del<em>t_lo</em> is the time of each detected
+entered, in units of timestep. del*t_lo* is the time of each detected
event, measured relative to <em>t_lo</em>. <em>delt_lo</em> is equal to the
high-temperature time since entering the current basin, scaled by an
exponential factor that depends on the hi/lo temperature ratio and the
energy barrier for that event.</p>
<p>On lines for executed events, with status <em>E</em>, the global event number
is incremented by one,
the local event number and time margin are reset to zero,
while the global event number, energy barrier, and
<em>delt_lo</em> match the last event with status <em>DF</em>
in the immediately preceding block of detected events.
The low-temperature event time <em>t_lo</em> is incremented by <em>delt_lo</em>.</p>
<p>NEB statistics are written to the file specified by the <em>neb_log</em>
keyword. If the keyword value is “none”, then no NEB statistics are
printed out. The statistics are written every <em>Nevery</em> timesteps. See
the <a class="reference internal" href="neb.html"><span class="doc">neb</span></a> command for a full description of the NEB
statistics. When invoked from TAD, NEB statistics are never printed to
the screen.</p>
<p>Because the NEB calculation must run on multiple partitions, LAMMPS
produces additional screen and log files for each partition,
e.g. log.lammps.0, log.lammps.1, etc. For the TAD command, these
contain the thermodynamic output of each NEB replica. In addition, the
log file for the first partition, log.lammps.0, will contain
thermodynamic output from short runs and minimizations corresponding
to the dynamics and quench operations, as well as a line for each new
detected event, as described above.</p>
<p>After the TAD command completes, timing statistics for the TAD run are
printed in each replica’s log file, giving a breakdown of how much CPU
time was spent in each stage (NEB, dynamics, quenching, etc).</p>
<p>Any <a class="reference internal" href="dump.html"><span class="doc">dump files</span></a> defined in the input script will be written
to during a TAD run at timesteps when an event is executed. This
means the the requested dump frequency in the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command
is ignored. There will be one dump file (per dump command) created
for all partitions. The atom coordinates of the dump snapshot are
those of the minimum energy configuration resulting from quenching
following the executed event. The timesteps written into the dump
files correspond to the timestep at which the event occurred and NOT
the clock. A dump snapshot corresponding to the initial minimum state
used for event detection is written to the dump file at the beginning
of each TAD run.</p>
<p>If the <a class="reference internal" href="restart.html"><span class="doc">restart</span></a> command is used, a single restart file
for all the partitions is generated, which allows a TAD run to be
continued by a new input script in the usual manner. The restart file
is generated after an event is executed. The restart file contains a
snapshot of the system in the new quenched state, including the event
number and the low-temperature time. The restart frequency specified
in the <a class="reference internal" href="restart.html"><span class="doc">restart</span></a> command is interpreted differently when
performing a TAD run. It does not mean the timestep interval between
restart files. Instead it means an event interval for executed
events. Thus a frequency of 1 means write a restart file every time
an event is executed. A frequency of 10 means write a restart file
every 10th executed event. When an input script reads a restart file
from a previous TAD run, the new script can be run on a different
number of replicas or processors.</p>
<p>Note that within a single state, the dynamics will typically
temporarily continue beyond the event that is ultimately chosen, until
the stopping criterionis satisfied. When the event is eventually
executed, the timestep counter is reset to the value when the event
was detected. Similarly, after each quench and NEB minimization, the
timestep counter is reset to the value at the start of the
minimization. This means that the timesteps listed in the replica log
files do not always increase monotonically. However, the timestep
values printed to the master log file, dump files, and restart files
are always monotonically increasing.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This command can only be used if LAMMPS was built with the REPLICA
package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
for more info on packages.</p>
<p><em>N</em> setting must be integer multiple of <em>t_event</em>.</p>
<p>Runs restarted from restart files written during a TAD run will only
produce identical results if the user-specified integrator supports
exact restarts. So <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> will produce an exact
restart, but <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> will not.</p>
<p>This command cannot be used when any fixes are defined that keep track
of elapsed time to perform time-dependent operations. Examples
include the “ave” fixes such as <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a>.
Also <a class="reference internal" href="fix_dt_reset.html"><span class="doc">fix dt/reset</span></a> and <a class="reference internal" href="fix_deposit.html"><span class="doc">fix deposit</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Instead of a numeric value, N can be specifed as an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a>, which should be specified as v_name, where
name is the variable name. In this case, the variable is evaluated at
the beginning of a run to determine the next timestep at which
thermodynamic info will be written out. On that timestep, the
variable will be evaluated again to determine the next timestep, etc.
Thus the variable should return timestep values. See the stagger()
and logfreq() and stride() math functions for <a class="reference internal" href="variable.html"><span class="doc">equal-style variables</span></a>, as examples of useful functions to use in
this context. Other similar math functions could easily be added as
options for <a class="reference internal" href="variable.html"><span class="doc">equal-style variables</span></a>.</p>
<p>For example, the following commands will output thermodynamic info at
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The kinetic energy of the system <em>ke</em> is inferred from the temperature
of the system with 1/2 Kb T of energy for each degree of freedom.
Thus, using different <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> for calculating
temperature, via the <a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify temp</span></a> command,
may yield different kinetic energies, since different computes that
calculate temperature can subtract out different non-thermal
components of velocity and/or include different degrees of freedom
(translational, rotational, etc).</p>
<p>The potential energy of the system <em>pe</em> will include contributions
from fixes if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify thermo</span></a> option is set
for a fix that calculates such a contribution. For example, the <a class="reference internal" href="fix_wall.html"><span class="doc">fix wall/lj93</span></a> fix calculates the energy of atoms
interacting with the wall. See the doc pages for “individual fixes”
to see which ones contribute.</p>
<p>A long-range tail correction <em>etail</em> for the VanderWaal pairwise
energy will be non-zero only if the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify tail</span></a> option is turned on. The <em>etail</em> contribution
is included in <em>evdwl</em>, <em>epair</em>, <em>pe</em>, and <em>etotal</em>, and the
corresponding tail correction to the pressure is included in <em>press</em>
and <em>pxx</em>, <em>pyy</em>, etc.</p>
<hr class="docutils" />
<p>The <em>step</em>, <em>elapsed</em>, and <em>elaplong</em> keywords refer to timestep
count. <em>Step</em> is the current timestep, or iteration count when a
<a class="reference internal" href="minimize.html"><span class="doc">minimization</span></a> is being performed. <em>Elapsed</em> is the
number of timesteps elapsed since the beginning of this run.
<em>Elaplong</em> is the number of timesteps elapsed since the beginning of
an initial run in a series of runs. See the <em>start</em> and <em>stop</em>
keywords for the <a class="reference internal" href="run.html"><span class="doc">run</span></a> for info on how to invoke a series of
runs that keep track of an initial starting time. If these keywords
are not used, then <em>elapsed</em> and <em>elaplong</em> are the same value.</p>
<p>The <em>dt</em> keyword is the current timestep size in time
<a class="reference internal" href="units.html"><span class="doc">units</span></a>. The <em>time</em> keyword is the current elapsed
simulation time, also in time <a class="reference internal" href="units.html"><span class="doc">units</span></a>, which is simply
(step*dt) if the timestep size has not changed and the timestep has
not been reset. If the timestep has changed (e.g. via <a class="reference internal" href="fix_dt_reset.html"><span class="doc">fix dt/reset</span></a>) or the timestep has been reset (e.g. via
the “reset_timestep” command), then the simulation time is effectively
a cummulative value up to the current point.</p>
<p>The <em>cpu</em> keyword is elapsed CPU seconds since the beginning of this
run. The <em>tpcpu</em> and <em>spcpu</em> keywords are measures of how fast your
simulation is currently running. The <em>tpcpu</em> keyword is simulation
time per CPU second, where simulation time is in time
<a class="reference internal" href="units.html"><span class="doc">units</span></a>. E.g. for metal units, the <em>tpcpu</em> value would be
picoseconds per CPU second. The <em>spcpu</em> keyword is the number of
timesteps per CPU second. Both quantities are on-the-fly metrics,
measured relative to the last time they were invoked. Thus if you are
printing out thermodyamic output every 100 timesteps, the two keywords
will continually output the time and timestep rate for the last 100
steps. The <em>tpcpu</em> keyword does not attempt to track any changes in
timestep size, e.g. due to using the <a class="reference internal" href="fix_dt_reset.html"><span class="doc">fix dt/reset</span></a>
command.</p>
<p>The <em>cpuremain</em> keyword estimates the CPU time remaining in the
current run, based on the time elapsed thus far. It will only be a
good estimate if the CPU time/timestep for the rest of the run is
similar to the preceding timesteps. On the initial timestep the value
will be 0.0 since there is no history to estimate from. For a
minimization run performed by the “minimize” command, the estimate is
based on the <em>maxiter</em> parameter, assuming the minimization will
proceed for the maximum number of allowed iterations.</p>
<p>The <em>part</em> keyword is useful for multi-replica or multi-partition
simulations to indicate which partition this output and this file
corresponds to, or for use in a <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> to append to
a filename for output specific to this partition. See <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">Section_start 7</span></a> of the manual for details on running in
multi-partition mode.</p>
<p>The <em>timeremain</em> keyword returns the remaining seconds when a
timeout has been configured via the <a class="reference internal" href="timer.html"><span class="doc">timer timeout</span></a> command.
If the timeout timer is inactive, the value of this keyword is 0.0 and
if the timer is expired, it is negative. This allows for example to exit
loops cleanly, if the timeout is expired with:</p>
<em>cellgamma</em>, correspond to the usual crystallographic quantities that
define the periodic unit cell of a crystal. See <a class="reference internal" href="Section_howto.html#howto-12"><span class="std std-ref">this section</span></a> of the doc pages for a geometric
description of triclinic periodic cells, including a precise defintion
of these quantities in terms of the internal LAMMPS cell dimensions
per-atom, or local values. Only global values can be referenced by
this command. However, per-atom compute values for an individual atom
can be referenced in a <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> and the variable
referenced by thermo_style custom, as discussed below. See the
discussion above for how the I in <em>c_ID[I]</em> can be specified with a
wildcard asterisk to effectively specify multiple values from a global
compute vector.</p>
<p>The ID in the keyword should be replaced by the actual ID of a compute
that has been defined elsewhere in the input script. See the
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command for details. If the compute calculates
a global scalar, vector, or array, then the keyword formats with 0, 1,
or 2 brackets will reference a scalar value from the compute.</p>
<p>Note that some computes calculate “intensive” global quantities like
temperature; others calculate “extensive” global quantities like
kinetic energy that are summed over all atoms in the compute group.
Intensive quantities are printed directly without normalization by
thermo_style custom. Extensive quantities may be normalized by the
total number of atoms in the simulation (NOT the number of atoms in
the compute group) when output, depending on the <a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify norm</span></a> option being used.</p>
<p>The <em>f_ID</em> and <em>f_ID[I]</em> and <em>f_ID[I][J]</em> keywords allow global
values calculated by a fix to be output. As discussed on the
<a class="reference internal" href="fix.html"><span class="doc">fix</span></a> doc page, fixes can calculate global, per-atom, or
local values. Only global values can be referenced by this command.
However, per-atom fix values can be referenced for an individual atom
in a <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> and the variable referenced by
thermo_style custom, as discussed below. See the discussion above for
how the I in <em>f_ID[I]</em> can be specified with a wildcard asterisk to
effectively specify multiple values from a global fix vector.</p>
<p>The ID in the keyword should be replaced by the actual ID of a fix
that has been defined elsewhere in the input script. See the
<a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command for details. If the fix calculates a global
scalar, vector, or array, then the keyword formats with 0, 1, or 2
brackets will reference a scalar value from the fix.</p>
<p>Note that some fixes calculate “intensive” global quantities like
timestep size; others calculate “extensive” global quantities like
energy that are summed over all atoms in the fix group. Intensive
quantities are printed directly without normalization by thermo_style
custom. Extensive quantities may be normalized by the total number of
atoms in the simulation (NOT the number of atoms in the fix group)
when output, depending on the <a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify norm</span></a>
option being used.</p>
<p>The <em>v_name</em> keyword allow the current value of a variable to be
output. The name in the keyword should be replaced by the variable
name that has been defined elsewhere in the input script. Only
equal-style and vector-style variables can be referenced; the latter
requires a bracketed term to specify the Ith element of the vector
calculated by the variable. However, an atom-style variable can be
referenced for an individual atom by an equal-style variable and that
variable referenced. See the <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command for
details. Variables of style <em>equal</em> and <em>vector</em> and <em>atom</em> define a
formula which can reference per-atom properties or thermodynamic
keywords, or they can invoke other computes, fixes, or variables when
evaluated, so this is a very general means of creating thermodynamic
output.</p>
<p>Note that equal-style and vector-style variables are assumed to
produce “intensive” global quantities, which are thus printed as-is,
without normalization by thermo_style custom. You can include a
division by “natoms” in the variable formula if this is not the case.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This command must come after the simulation box is defined by a
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Ideally, the mass of the Drude particle should be small, and the
stiffness of the harmonic bond should be large, so that the Drude
particle remains close ot the core. The values of Drude mass, Drude
charge, and force constant can be chosen following different
strategies, as in the following examples of polarizable force
fields:</p>
<ul class="simple">
<li><a class="reference internal" href="#lamoureux"><span class="std std-ref">Lamoureux and Roux</span></a> suggest adopting a global half-stiffness, <span class="math">\(K_D\)</span> = 500 kcal/(mol Ang <span class="math">\({}^2\)</span>) - which corresponds to a force constant <span class="math">\(k_D\)</span> = 4184 kJ/(mol Ang <span class="math">\({}^2\)</span>) - for all types of core-Drude bond, a global mass <span class="math">\(m_D\)</span> = 0.4 g/mol (or u) for all types of Drude particles, and to calculate the Drude charges for individual atom types from the atom polarizabilities using equation (1). This choice is followed in the polarizable CHARMM force field.</li>
<li>Alternately <a class="reference internal" href="#schroeder"><span class="std std-ref">Schroeder and Steinhauser</span></a> suggest adopting a global charge <span class="math">\(q_D\)</span> = -1.0e and a global mass <span class="math">\(m_D\)</span> = 0.1 g/mol (or u) for all Drude particles, and to calculate the force constant for each type of core-Drude bond from equation (1). The timesteps used by these authors are between 0.5 and 2 fs, with the degrees of freedom of the Drude oscillators kept cold at 1 K.</li>
<li>In both these force fields hydrogen atoms are treated as non-polarizable.</li>
</ul>
<p>The motion of of the Drude particles can be calculated by minimizing
the energy of the induced dipoles at each timestep, by an interative,
self-consistent procedure. The Drude particles can be massless and
therefore do not contribute to the kinetic energy. However, the
relaxed method is computationall slow. An extended-lagrangian method
can be used to calculate the positions of the Drude particles, but
this requires them to have mass. It is important in this case to
decouple the degrees of freedom associated with the Drude oscillators
from those of the normal atoms. Thermalizing the Drude dipoles at
temperatures comparable to the rest of the simulation leads to several
problems (kinetic energy transfer, very short timestep, etc.), which
can be remediated by the “cold Drude” technique (<a class="reference internal" href="#lamoureux"><span class="std std-ref">Lamoureux and Roux</span></a>).</p>
<p>Two closely related models are used to represent polarization through
“charges on a spring”: the core-shell model and the Drude
model. Although the basic idea is the same, the core-shell model is
normally used for ionic/crystalline materials, whereas the Drude model
is normally used for molecular systems and fluid states. In ionic
crystals the symmetry around each ion and the distance between them
are such that the core-shell model is sufficiently stable. But to be
applicable to molecular/covalent systems the Drude model includes two
important features:</p>
<ol class="arabic simple">
<li>The possibility to thermostat the additional degrees of freedom associated with the induced dipoles at very low temperature, in terms of the reduced coordinates of the Drude particles with respect to their cores. This makes the trajectory close to that of relaxed induced dipoles.</li>
<li>The Drude dipoles on covalently bonded atoms interact too strongly due to the short distances, so an atom may capture the Drude particle (shell) of a neighbor, or the induced dipoles within the same molecule may align too much. To avoid this, damping at short of the interactions between the point charges composing the induced dipole can be done by <a class="reference internal" href="#thole"><span class="std std-ref">Thole</span></a> functions.</li>
</ol>
<hr class="docutils" />
<p><strong>Preparation of the data file</strong></p>
<p>The data file is similar to a standard LAMMPS data file for
<em>atom_style full</em>. The DPs and the <em>harmonic bonds</em> connecting them
to their DC should appear in the data file as normal atoms and bonds.</p>
<p>You can use the <em>polarizer</em> tool (Python script distributed with the
USER-DRUDE package) to convert a non-polarizable data file (here
<em>data.102494.lmp</em>) to a polarizable data file (<em>data-p.lmp</em>)</p>
<p>Now for the thermalization, the simplest choice is to use the <a class="reference internal" href="fix_langevin_drude.html"><span class="doc">fix langevin/drude</span></a>.</p>
<p>It is also possible to use a Nose-Hoover instead of a Langevin
thermostat. This requires to use <a class="reference internal" href="fix_drude_transform.html"><span class="doc">*fix drude/transform*</span></a> just before and after the
time intergation fixes. The <em>fix drude/transform/direct</em> converts the
atomic masses, positions, velocities and forces into a reduced
representation, where the DCs transform into the centers of mass of
the DC-DP pairs and the DPs transform into their relative position
with respect to their DC. The <em>fix drude/transform/inverse</em> performs
the reverse transformation. For a NVT simulation, with the DCs and
atoms at 300 K and the DPs at 1 K relative to their DC one would use</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This document briefly describes how to use GitHub to merge changes you
make into LAMMPS, using GitHub. It assumes that you are familiar with
git. You may want to have a look at the <a class="reference external" href="http://git-scm.com/book/">Git book</a> to reacquaint yourself.</p>
<hr class="docutils" />
<p><strong>Making an account</strong></p>
<p>First of all, you need a GitHub account. This is fairly simple, just
go to <a class="reference external" href="https://github.com">GitHub</a> and create an account by clicking
-the <a href="#id1"><span class="problematic" id="id2">``</span></a>Sign up for GitHub’’ button. Once your account is created, you
+the “Sign up for GitHub” button. Once your account is created, you
can sign in by clicking the button in the top left and filling in your
username or e-mail address and password.</p>
<hr class="docutils" />
<p><strong>Forking the repository</strong></p>
<p>To get changes into LAMMPS, you need to first fork the repository. At
the time of writing, LAMMPS-ICMS is the preferred fork. Go to <a class="reference external" href="https://github.com/lammps/lammps">LAMMPS on GitHub</a> and make sure branch is
-set to <a href="#id3"><span class="problematic" id="id4">``</span></a>lammps-icms’‘, see the figure below.</p>
+set to “lammps-icms”, see the figure below.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This command sets the style of units used for a simulation. It
determines the units of all quantities specified in the input script
and data file, as well as quantities output to the screen, log file,
and dump files. Typically, this command is used at the very beginning
of an input script.</p>
<p>For all units except <em>lj</em>, LAMMPS uses physical constants from
www.physics.nist.gov. For the definition of Kcal in real units,
LAMMPS uses the thermochemical calorie = 4.184 J.</p>
<p>The choice you make for units simply sets some internal conversion
factors within LAMMPS. This means that any simulation you perform for
one choice of units can be duplicated with any other unit setting
LAMMPS supports. In this context “duplicate” means the particles will
have identical trajectories and all output generated by the simulation
will be identical. This will be the case for some number of timesteps
until round-off effects accumulate, since the conversion factors for
two different unit systems are not identical to infinite precision.</p>
<p>To perform the same simulation in a different set of units you must
change all the unit-based input parameters in your input script and
other input files (data file, potential files, etc) correctly to the
new units. And you must correctly convert all output from the new
units to the old units when comparing to the original results. That
is often not simple to do.</p>
<hr class="docutils" />
<p>For style <em>lj</em>, all quantities are unitless. Without loss of
generality, LAMMPS sets the fundamental quantities mass, sigma,
epsilon, and the Boltzmann constant = 1. The masses, distances,
energies you specify are multiples of these fundamental values. The
formulas relating the reduced or unitless quantity (with an asterisk)
to the same quantity with units is also given. Thus you can use the
mass & sigma & epsilon values for a specific material and convert the
results from a unitless LJ simulation into physical quantities.</p>
<ul class="simple">
<li>mass = mass or m</li>
<li>distance = sigma, where x* = x / sigma</li>
<li>time = tau, where t* = t (epsilon / m / sigma^2)^1/2</li>
<li>energy = epsilon, where E* = E / epsilon</li>
<li>velocity = sigma/tau, where v* = v tau / sigma</li>
<li>force = epsilon/sigma, where f* = f sigma / epsilon</li>
<li>torque = epsilon, where t* = t / epsilon</li>
<li>temperature = reduced LJ temperature, where T* = T Kb / epsilon</li>
<li>pressure = reduced LJ pressure, where P* = P sigma^3 / epsilon</li>
<li>dynamic viscosity = reduced LJ viscosity, where eta* = eta sigma^3 / epsilon / tau</li>
<li>charge = reduced LJ charge, where q* = q / (4 pi perm0 sigma epsilon)^1/2</li>
-<li>dipole = reduced LJ dipole, moment where <a href="#id1"><span class="problematic" id="id2">*</span></a>mu = mu / (4 pi perm0 sigma^3 epsilon)^1/2</li>
+<li>dipole = reduced LJ dipole, moment where *mu = mu / (4 pi perm0 sigma^3 epsilon)^1/2</li>
<li>electric field = force/charge, where E* = E (4 pi perm0 sigma epsilon)^1/2 sigma / epsilon</li>
<li>density = mass/volume, where rho* = rho sigma^dim</li>
</ul>
<p>Note that for LJ units, the default mode of thermodyamic output via
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command is to normalize all
extensive quantities by the number of atoms. E.g. potential energy is
extensive because it is summed over atoms, so it is output as
energy/atom. Temperature is intensive since it is already normalized
by the number of atoms, so it is output as-is. This behavior can be
changed via the <a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify norm</span></a> command.</p>
<p>For style <em>real</em>, these are the units:</p>
<ul class="simple">
<li>mass = grams/mole</li>
<li>distance = Angstroms</li>
<li>time = femtoseconds</li>
<li>energy = Kcal/mole</li>
<li>velocity = Angstroms/femtosecond</li>
<li>force = Kcal/mole-Angstrom</li>
<li>torque = Kcal/mole</li>
<li>temperature = Kelvin</li>
<li>pressure = atmospheres</li>
<li>dynamic viscosity = Poise</li>
<li>charge = multiple of electron charge (1.0 is a proton)</li>
<li>dipole = charge*Angstroms</li>
<li>electric field = volts/Angstrom</li>
<li>density = gram/cm^dim</li>
</ul>
<p>For style <em>metal</em>, these are the units:</p>
<ul class="simple">
<li>mass = grams/mole</li>
<li>distance = Angstroms</li>
<li>time = picoseconds</li>
<li>energy = eV</li>
<li>velocity = Angstroms/picosecond</li>
<li>force = eV/Angstrom</li>
<li>torque = eV</li>
<li>temperature = Kelvin</li>
<li>pressure = bars</li>
<li>dynamic viscosity = Poise</li>
<li>charge = multiple of electron charge (1.0 is a proton)</li>
<li>dipole = charge*Angstroms</li>
<li>electric field = volts/Angstrom</li>
<li>density = gram/cm^dim</li>
</ul>
<p>For style <em>si</em>, these are the units:</p>
<ul class="simple">
<li>mass = kilograms</li>
<li>distance = meters</li>
<li>time = seconds</li>
<li>energy = Joules</li>
<li>velocity = meters/second</li>
<li>force = Newtons</li>
<li>torque = Newton-meters</li>
<li>temperature = Kelvin</li>
<li>pressure = Pascals</li>
<li>dynamic viscosity = Pascal*second</li>
<li>charge = Coulombs (1.6021765e-19 is a proton)</li>
<li>dipole = Coulombs*meters</li>
<li>electric field = volts/meter</li>
<li>density = kilograms/meter^dim</li>
</ul>
<p>For style <em>cgs</em>, these are the units:</p>
<ul class="simple">
<li>mass = grams</li>
<li>distance = centimeters</li>
<li>time = seconds</li>
<li>energy = ergs</li>
<li>velocity = centimeters/second</li>
<li>force = dynes</li>
<li>torque = dyne-centimeters</li>
<li>temperature = Kelvin</li>
<li>pressure = dyne/cm^2 or barye = 1.0e-6 bars</li>
<li>dynamic viscosity = Poise</li>
<li>charge = statcoulombs or esu (4.8032044e-10 is a proton)</li>
<li>dipole = statcoul-cm = 10^18 debye</li>
<li>electric field = statvolt/cm or dyne/esu</li>
<li>density = grams/cm^dim</li>
</ul>
<p>For style <em>electron</em>, these are the units:</p>
<ul class="simple">
<li>mass = atomic mass units</li>
<li>distance = Bohr</li>
<li>time = femtoseconds</li>
<li>energy = Hartrees</li>
<li>velocity = Bohr/atomic time units [1.03275e-15 seconds]</li>
<li>force = Hartrees/Bohr</li>
<li>temperature = Kelvin</li>
<li>pressure = Pascals</li>
<li>charge = multiple of electron charge (1.0 is a proton)</li>
<li>dipole moment = Debye</li>
<li>electric field = volts/cm</li>
</ul>
<p>For style <em>micro</em>, these are the units:</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>style = <em>delete</em> or <em>index</em> or <em>loop</em> or <em>world</em> or <em>universe</em> or <em>uloop</em> or <em>string</em> or <em>format</em> or <em>getenv</em> or <em>file</em> or <em>atomfile</em> or <em>python</em> or <em>internal</em> or <em>equal</em> or <em>vector</em> or <em>atom</em></li>
</ul>
<pre class="literal-block">
<em>delete</em> = no args
<em>index</em> args = one or more strings
<em>loop</em> args = N
N = integer size of loop, loop from 1 to N inclusive
<em>loop</em> args = N pad
N = integer size of loop, loop from 1 to N inclusive
pad = all values will be same length, e.g. 001, 002, ..., 100
<em>loop</em> args = N1 N2
N1,N2 = loop from N1 to N2 inclusive
<em>loop</em> args = N1 N2 pad
N1,N2 = loop from N1 to N2 inclusive
pad = all values will be same length, e.g. 050, 051, ..., 100
<em>world</em> args = one string for each partition of processors
<em>universe</em> args = one or more strings
<em>uloop</em> args = N
N = integer size of loop
<em>uloop</em> args = N pad
N = integer size of loop
pad = all values will be same length, e.g. 001, 002, ..., 100
<em>string</em> arg = one string
<em>format</em> args = vname fstr
vname = name of equal-style variable to evaluate
fstr = C-style format string
<em>getenv</em> arg = one string
<em>file</em> arg = filename
<em>atomfile</em> arg = filename
<em>python</em> arg = function
<em>internal</em> arg = numeric value
<em>equal</em> or <em>vector</em> or <em>atom</em> args = one formula containing numbers, thermo keywords, math operations, group functions, atom values and vectors, compute/fix/variable references
numbers = 0.0, 100, -5.4, 2.8e-4, etc
constants = PI, version, on, off, true, false, yes, no
<p>This command assigns one or more strings to a variable name for
evaluation later in the input script or during a simulation.</p>
<p>Variables can thus be useful in several contexts. A variable can be
defined and then referenced elsewhere in an input script to become
part of a new input command. For variable styles that store multiple
strings, the <a class="reference internal" href="next.html"><span class="doc">next</span></a> command can be used to increment which
string is assigned to the variable. Variables of style <em>equal</em> store
a formula which when evaluated produces a single numeric value which
can be output either directly (see the <a class="reference internal" href="print.html"><span class="doc">print</span></a>, <a class="reference internal" href="fix_print.html"><span class="doc">fix print</span></a>, and <a class="reference internal" href="run.html"><span class="doc">run every</span></a> commands) or as part
of thermodynamic output (see the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a>
command), or used as input to an averaging fix (see the <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a> command). Variables of style <em>vector</em>
store a formula which produces a vector of such values which can be
used as input to various averaging fixes, or elements of which can be
part of thermodynamic output. Variables of style <em>atom</em> store a
formula which when evaluated produces one numeric value per atom which
can be output to a dump file (see the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command)
or used as input to an averaging fix (see the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> and <a class="reference internal" href="fix_ave_atom.html"><span class="doc">fix ave/atom</span></a>
commands). Variables of style <em>atomfile</em> can be used anywhere in an
input script that atom-style variables are used; they get their
per-atom values from a file rather than from a formula. Variables of
style <em>python</em> can be hooked to Python functions using code you
provide, so that the variable gets its value from the evaluation of
the Python code. Variables of style <em>internal</em> are used by a few
commands which set their value directly.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">As discussed in <a class="reference internal" href="Section_commands.html#cmd-2"><span class="std std-ref">Section 3.2</span></a> of the
manual, an input script can use “immediate” variables, specified as
$(formula) with parenthesis, where the formula has the same syntax as
equal-style variables described on this page. This is a convenient
way to evaluate a formula immediately without using the variable
command to define a named variable and then evaluate that
variable. See below for a more detailed discussion of this feature.</p>
</div>
<p>In the discussion that follows, the “name” of the variable is the
arbitrary string that is the 1st argument in the variable command.
This name can only contain alphanumeric characters and underscores.
The “string” is one or more of the subsequent arguments. The “string”
can be simple text as in the 1st example above, it can contain other
variables as in the 2nd example, or it can be a formula as in the 3rd
example. The “value” is the numeric quantity resulting from
evaluation of the string. Note that the same string can generate
different values when it is evaluated at different times during a
simulation.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When an input script line is encountered that defines a variable
of style <em>equal</em> or <em>vector</em> or <em>atom</em> or <em>python</em> that contains a
formula or Python code, the formula is NOT immediately evaluated. It
will be evaluated every time when the variable is <strong>used</strong> instead. If
you simply want to evaluate a formula in place you can use as
so-called. See the section below about “Immediate Evaluation of
Variables” for more details on the topic. This is also true of a
<em>format</em> style variable since it evaluates another variable when it is
invoked.</p>
</div>
<p>Variables of style <em>equal</em> and <em>vector</em> and <em>atom</em> can be used as
inputs to various other commands which evaluate their formulas as
needed, e.g. at different timesteps during a <a class="reference internal" href="run.html"><span class="doc">run</span></a>.</p>
<p>Variables of style <em>internal</em> can be used in place of an equal-style
variable, except by commands that set the value stored by the
internal-style variable. Thus any command that states it can use an
equal-style variable as an argument, can also use an internal-style
variable. This means that when the command evaluates the variable, it
will use the value set (internally) by another command.</p>
<p>Variables of style <em>python</em> can be used in place of an equal-style
variable so long as the associated Python function, as defined by the
<a class="reference internal" href="python.html"><span class="doc">python</span></a> command, returns a numeric value. Thus any
command that states it can use an equal-style variable as an argument,
can also use such a python-style variable. This means that when the
LAMMPS command evaluates the variable, the Python function will be
executed.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When a variable command is encountered in the input script and
the variable name has already been specified, the command is ignored.
This means variables can NOT be re-defined in an input script (with
two exceptions, read further). This is to allow an input script to be
processed multiple times without resetting the variables; see the
<a class="reference internal" href="jump.html"><span class="doc">jump</span></a> or <a class="reference internal" href="include.html"><span class="doc">include</span></a> commands. It also means
that using the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> -var
will override a corresponding index variable setting in the input
script.</p>
</div>
<p>There are two exceptions to this rule. First, variables of style
<em>string</em>, <em>getenv</em>, <em>internal</em>, <em>equal</em>, <em>vector</em>, <em>atom</em>, and
<em>python</em> ARE redefined each time the command is encountered. This
allows these style of variables to be redefined multiple times in an
input script. In a loop, this means the formula associated with an
<em>equal</em> or <em>atom</em> style variable can change if it contains a
substitution for another variable, e.g. $x or v_x.</p>
<p>Second, as described below, if a variable is iterated on to the end of
its list of strings via the <a class="reference internal" href="next.html"><span class="doc">next</span></a> command, it is removed
from the list of active variables, and is thus available to be
re-defined in a subsequent variable command. The <em>delete</em> style does
the same thing.</p>
<hr class="docutils" />
<p><a class="reference internal" href="Section_commands.html#cmd-2"><span class="std std-ref">This section</span></a> of the manual explains how
occurrences of a variable name in an input script line are replaced by
the variable’s string. The variable name can be referenced as $x if
the name “x” is a single character, or as ${LoopVar} if the name
“LoopVar” is one or more characters.</p>
<p>As described below, for variable styles <em>index</em>, <em>loop</em>, <em>file</em>,
<em>universe</em>, and <em>uloop</em>, which string is assigned to a variable can be
incremented via the <a class="reference internal" href="next.html"><span class="doc">next</span></a> command. When there are no more
strings to assign, the variable is exhausted and a flag is set that
causes the next <a class="reference internal" href="jump.html"><span class="doc">jump</span></a> command encountered in the input
script to be skipped. This enables the construction of simple loops
in the input script that are iterated over and then exited from.</p>
<p>As explained above, an exhausted variable can be re-used in an input
script. The <em>delete</em> style also removes the variable, the same as if
it were exhausted, allowing it to be redefined later in the input
script or when the input script is looped over. This can be useful
when breaking out of a loop via the <a class="reference internal" href="if.html"><span class="doc">if</span></a> and <a class="reference internal" href="jump.html"><span class="doc">jump</span></a>
commands before the variable would become exhausted. For example,</p>
<p>This section describes how all the various variable styles are defined
and what they store. Except for the <em>equal</em> and <em>vector</em> and <em>atom</em>
styles, which are explained in the next section.</p>
<p>Many of the styles store one or more strings. Note that a single
string can contain spaces (multiple words), if it is enclosed in
quotes in the variable command. When the variable is substituted for
in another input script command, its returned string will then be
interpreted as multiple arguments in the expanded command.</p>
<p>For the <em>index</em> style, one or more strings are specified. Initially,
the 1st string is assigned to the variable. Each time a
<a class="reference internal" href="next.html"><span class="doc">next</span></a> command is used with the variable name, the next
string is assigned. All processors assign the same string to the
variable.</p>
<p><em>Index</em> style variables with a single string value can also be set by
using the command-line switch -var; see <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">this section</span></a> for details.</p>
<p>The <em>loop</em> style is identical to the <em>index</em> style except that the
strings are the integers from 1 to N inclusive, if only one argument N
is specified. This allows generation of a long list of runs
(e.g. 1000) without having to list N strings in the input script.
Initially, the string “1” is assigned to the variable. Each time a
<a class="reference internal" href="next.html"><span class="doc">next</span></a> command is used with the variable name, the next
string (“2”, “3”, etc) is assigned. All processors assign the same
string to the variable. The <em>loop</em> style can also be specified with
two arguments N1 and N2. In this case the loop runs from N1 to N2
inclusive, and the string N1 is initially assigned to the variable.
N1 <= N2 and N2 >= 0 is required.</p>
<p>For the <em>world</em> style, one or more strings are specified. There must
be one string for each processor partition or “world”. See <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">this section</span></a> of the manual for information on
running LAMMPS with multiple partitions via the “-partition”
command-line switch. This variable command assigns one string to each
world. All processors in the world are assigned the same string. The
next command cannot be used with <em>equal</em> style variables, since there
is only one value per world. This style of variable is useful when
you wish to run different simulations on different partitions, or when
performing a parallel tempering simulation (see the
<a class="reference internal" href="temper.html"><span class="doc">temper</span></a> command), to assign different temperatures to
different partitions.</p>
<p>For the <em>universe</em> style, one or more strings are specified. There
must be at least as many strings as there are processor partitions or
“worlds”. See <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">this page</span></a> for information
on running LAMMPS with multiple partitions via the “-partition”
command-line switch. This variable command initially assigns one
string to each world. When a <a class="reference internal" href="next.html"><span class="doc">next</span></a> command is encountered
using this variable, the first processor partition to encounter it, is
assigned the next available string. This continues until all the
variable strings are consumed. Thus, this command can be used to run
50 simulations on 8 processor partitions. The simulations will be run
one after the other on whatever partition becomes available, until
they are all finished. <em>Universe</em> style variables are incremented
using the files “tmp.lammps.variable” and “tmp.lammps.variable.lock”
which you will see in your directory during such a LAMMPS run.</p>
<p>The <em>uloop</em> style is identical to the <em>universe</em> style except that the
strings are the integers from 1 to N. This allows generation of long
list of runs (e.g. 1000) without having to list N strings in the input
script.</p>
<p>For the <em>string</em> style, a single string is assigned to the variable.
The only difference between this and using the <em>index</em> style with a
single string is that a variable with <em>string</em> style can be redefined.
E.g. by another command later in the input script, or if the script is
read again in a loop.</p>
<p>For the <em>format</em> style, an equal-style variable is specified along
with a C-style format string, e.g. “%f” or “%.10g”, which must be
appropriate for formatting a double-precision floating-point value.
This allows an equal-style variable to be formatted specifically for
output as a string, e.g. by the <a class="reference internal" href="print.html"><span class="doc">print</span></a> command, if the
default format “%.15g” has too much precision.</p>
<p>For the <em>getenv</em> style, a single string is assigned to the variable
which should be the name of an environment variable. When the
variable is evaluated, it returns the value of the environment
variable, or an empty string if it not defined. This style of
variable can be used to adapt the behavior of LAMMPS input scripts via
environment variable settings, or to retrieve information that has
been previously stored with the <a class="reference internal" href="shell.html"><span class="doc">shell putenv</span></a> command.
Note that because environment variable settings are stored by the
operating systems, they persist beyond a <a class="reference internal" href="clear.html"><span class="doc">clear</span></a> command.</p>
<p>For the <em>file</em> style, a filename is provided which contains a list of
strings to assign to the variable, one per line. The strings can be
numeric values if desired. See the discussion of the next() function
below for equal-style variables, which will convert the string of a
file-style variable into a numeric value in a formula.</p>
<p>When a file-style variable is defined, the file is opened and the
string on the first line is read and stored with the variable. This
means the variable can then be evaluated as many times as desired and
will return that string. There are two ways to cause the next string
from the file to be read: use the <a class="reference internal" href="next.html"><span class="doc">next</span></a> command or the
next() function in an equal- or atom-style variable, as discussed
below.</p>
<p>The rules for formatting the file are as follows. A comment character
“#” can be used anywhere on a line; text starting with the comment
character is stripped. Blank lines are skipped. The first “word” of
a non-blank line, delimited by white space, is the “string” assigned
to the variable.</p>
<p>For the <em>atomfile</em> style, a filename is provided which contains one or
more sets of values, to assign on a per-atom basis to the variable.
The format of the file is described below.</p>
<p>When an atomfile-style variable is defined, the file is opened and the
first set of per-atom values are read and stored with the variable.
This means the variable can then be evaluated as many times as desired
and will return those values. There are two ways to cause the next
set of per-atom values from the file to be read: use the
<a class="reference internal" href="next.html"><span class="doc">next</span></a> command or the next() function in an atom-style
variable, as discussed below.</p>
<p>The rules for formatting the file are as follows. Each time a set of
per-atom values is read, a non-blank line is searched for in the file.
A comment character “#” can be used anywhere on a line; text starting
with the comment character is stripped. Blank lines are skipped. The
first “word” of a non-blank line, delimited by white space, is read as
the count N of per-atom lines to immediately follow. N can be be the
total number of atoms in the system, or only a subset. The next N
<p>Most of the formula elements produce a scalar value. Some produce a
global or per-atom vector of values. Global vectors can be produced
by computes or fixes or by other vector-style variables. Per-atom
vectors are produced by atom vectors, compute references that
represent a per-atom vector, fix references that represent a per-atom
vector, and variables that are atom-style variables. Math functions
that operate on scalar values produce a scalar value; math function
that operate on global or per-atom vectors do so element-by-element
and produce a global or per-atom vector.</p>
<p>A formula for equal-style variables cannot use any formula element
that produces a global or per-atom vector. A formula for a
vector-style variable can use formula elements that produce either a
scalar value or a global vector value, but cannot use a formula
element that produces a per-atom vector. A formula for an atom-style
variable can use formula elements that produce either a scalar value
or a per-atom vector, but not one that produces a global vector.
Atom-style variables are evaluated by other commands that define a
<a class="reference internal" href="group.html"><span class="doc">group</span></a> on which they operate, e.g. a <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> or
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> or <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command. When they invoke
the atom-style variable, only atoms in the group are included in the
formula evaluation. The variable evaluates to 0.0 for atoms not in
<p>Numbers can contain digits, scientific notation
(3.0e20,3.0e-20,3.0E20,3.0E-20), and leading minus signs.</p>
<p>Constants are set at compile time and cannot be changed. <em>PI</em> will
return the number 3.14159265358979323846; <em>on</em>, <em>true</em> or <em>yes</em> will
return 1.0; <em>off</em>, <em>false</em> or <em>no</em> will return 0.0; <em>version</em> will
return a numeric version code of the current LAMMPS version (e.g.
version 2 Sep 2015 will return the number 20150902). The corresponding
value for newer versions of LAMMPS will be larger, for older versions
of LAMMPS will be smaller. This can be used to have input scripts
adapt automatically to LAMMPS versions, when non-backwards compatible
syntax changes are introduced. Here is an illustrative example (which
will not work, since the <em>version</em> has been introduced more recently):</p>
-<div class="highlight-default"><div class="highlight"><pre><span></span>if $(version<20140513) then "communicate vel yes" else "comm_modify vel yes"
-</pre></div>
-</div>
+<pre class="literal-block">
+if $(version<20140513) then "communicate vel yes" else "comm_modify vel yes"
+</pre>
<p>The thermo keywords allowed in a formula are those defined by the
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command. Thermo keywords that
require a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> to calculate their values such as
“temp” or “press”, use computes stored and invoked by the
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command. This means that you can
only use those keywords in a variable if the style you are using with
the thermo_style command (and the thermo keywords associated with that
style) also define and use the needed compute. Note that some thermo
keywords use a compute indirectly to calculate their value (e.g. the
enthalpy keyword uses temp, pe, and pressure). If a variable is
evaluated directly in an input script (not during a run), then the
values accessed by the thermo keyword must be current. See the
discussion below about “Variable Accuracy”.</p>
</div>
<hr class="docutils" />
<div class="section" id="math-operators">
<h3>Math Operators</h3>
<p>Math operators are written in the usual way, where the “x” and “y” in
the examples can themselves be arbitrarily complex formulas, as in the
examples above. In this syntax, “x” and “y” can be scalar values or
per-atom vectors. For example, “ke/natoms” is the division of two
scalars, where “vy+vz” is the element-by-element sum of two per-atom
vectors of y and z velocities.</p>
<p>Operators are evaluated left to right and have the usual C-style
precedence: unary minus and unary logical NOT operator ”!” have the
highest precedence, exponentiation “^” is next; multiplication and
division and the modulo operator “%” are next; addition and
subtraction are next; the 4 relational operators “<”, “<=”, “>”, and
“>=” are next; the two remaining relational operators “==” and ”!=”
are next; then the logical AND operator “&&”; and finally the logical
OR operator “||” has the lowest precedence. Parenthesis can be used
to group one or more portions of a formula and/or enforce a different
order of evaluation than what would occur with the default precedence.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Because a unary minus is higher precedence than exponentiation,
the formula “-2^2” will evaluate to 4, not -4. This convention is
compatible with some programming languages, but not others. As
mentioned, this behavior can be easily overridden with parenthesis;
the formula “-(2^2)” will evaluate to -4.</p>
</div>
<p>The 6 relational operators return either a 1.0 or 0.0 depending on
whether the relationship between x and y is TRUE or FALSE. For
example the expression x<10.0 in an atom-style variable formula will
return 1.0 for all atoms whose x-coordinate is less than 10.0, and 0.0
for the others. The logical AND operator will return 1.0 if both its
arguments are non-zero, else it returns 0.0. The logical OR operator
will return 1.0 if either of its arguments is non-zero, else it
returns 0.0. The logical NOT operator returns 1.0 if its argument is
0.0, else it returns 0.0.</p>
<p>These relational and logical operators can be used as a masking or
selection operation in a formula. For example, the number of atoms
whose properties satifsy one or more criteria could be calculated by
taking the returned per-atom vector of ones and zeroes and passing it
to the <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a> command.</p>
</div>
<hr class="docutils" />
<div class="section" id="math-functions">
<h3>Math Functions</h3>
<p>Math functions are specified as keywords followed by one or more
parenthesized arguments “x”, “y”, “z”, each of which can themselves be
arbitrarily complex formulas. In this syntax, the arguments can
represent scalar values or global vectors or per-atom vectors. In the
latter case, the math operation is performed on each element of the
vector. For example, “sqrt(natoms)” is the sqrt() of a scalar, where
“sqrt(y*z)” yields a per-atom vector with each element being the
sqrt() of the product of one atom’s y and z coordinates.</p>
<p>Most of the math functions perform obvious operations. The ln() is
the natural log; log() is the base 10 log.</p>
<p>The random(x,y,z) function takes 3 arguments: x = lo, y = hi, and z =
seed. It generates a uniform random number between lo and hi. The
normal(x,y,z) function also takes 3 arguments: x = mu, y = sigma, and
z = seed. It generates a Gaussian variate centered on mu with
variance sigma^2. In both cases the seed is used the first time the
internal random number generator is invoked, to initialize it. For
equal-style and vector-style variables, every processor uses the same
seed so that they each generate the same sequence of random numbers.
For atom-style variables, a unique seed is created for each processor,
based on the specified seed. This effectively generates a different
random number for each atom being looped over in the atom-style
variable.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Internally, there is just one random number generator for all
equal-style and vector-style variables and another one for all
atom-style variables. If you define multiple variables (of each
style) which use the random() or normal() math functions, then the
internal random number generators will only be initialized once, which
means only one of the specified seeds will determine the sequence of
generated random numbers.</p>
</div>
<p>The ceil(), floor(), and round() functions are those in the C math
library. Ceil() is the smallest integer not less than its argument.
Floor() if the largest integer not greater than its argument. Round()
is the nearest integer to its argument.</p>
<p>The ramp(x,y) function uses the current timestep to generate a value
linearly intepolated between the specified x,y values over the course
+value = x + (y-x) * (timestep-startstep) / (stopstep-startstep)
+</pre>
<p>The run begins on startstep and ends on stopstep. Startstep and
stopstep can span multiple runs, using the <em>start</em> and <em>stop</em> keywords
of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command for
details of how to do this.</p>
<p>The stagger(x,y) function uses the current timestep to generate a new
timestep. X,y > 0 and x > y are required. The generated timesteps
increase in a staggered fashion, as the sequence
x,x+y,2x,2x+y,3x,3x+y,etc. For any current timestep, the next
timestep in the sequence is returned. Thus if stagger(1000,100) is
used in a variable by the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify every</span></a>
command, it will generate the sequence of output timesteps:</p>
<p>The logfreq(x,y,z) function uses the current timestep to generate a
new timestep. X,y,z > 0 and y < z are required. The generated
timesteps are on a base-z logarithmic scale, starting with x, and the
y value is how many of the z-1 possible timesteps within one
logarithmic interval are generated. I.e. the timesteps follow the
sequence x,2x,3x,...y*x,x*z,2x*z,3x*z,...y*x*z,x*z^2,2x*z^2,etc. For
any current timestep, the next timestep in the sequence is returned.
Thus if logfreq(100,4,10) is used in a variable by the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify every</span></a> command, it will generate this sequence of
<p>The logfreq2(x,y,z) function is similar to logfreq, except a single
logarithmic interval is divided into y equally-spaced timesteps and
all of them are output. Y < z is not required. Thus, if
logfreq2(100,18,10) is used in a variable by the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify every</span></a> command, then the interval between 100 and
1000 is divided as 900/18 = 50 steps, and it will generate the
<p>Group functions are specified as keywords followed by one or two
parenthesized arguments. The first argument <em>ID</em> is the group-ID.
The <em>dim</em> argument, if it exists, is <em>x</em> or <em>y</em> or <em>z</em>. The <em>dir</em>
argument, if it exists, is <em>xmin</em>, <em>xmax</em>, <em>ymin</em>, <em>ymax</em>, <em>zmin</em>, or
<em>zmax</em>. The <em>dimdim</em> argument, if it exists, is <em>xx</em> or <em>yy</em> or <em>zz</em>
or <em>xy</em> or <em>yz</em> or <em>xz</em>.</p>
<p>The group function count() is the number of atoms in the group. The
group functions mass() and charge() are the total mass and charge of
the group. Xcm() and vcm() return components of the position and
velocity of the center of mass of the group. Fcm() returns a
component of the total force on the group of atoms. Bound() returns
the min/max of a particular coordinate for all atoms in the group.
Gyration() computes the radius-of-gyration of the group of atoms. See
the <a class="reference internal" href="compute_gyration.html"><span class="doc">compute gyration</span></a> command for a definition
of the formula. Angmom() returns components of the angular momentum
of the group of atoms around its center of mass. Torque() returns
components of the torque on the group of atoms around its center of
mass, based on current forces on the atoms. Inertia() returns one of
6 components of the symmetric inertia tensor of the group of atoms
around its center of mass, ordered as Ixx,Iyy,Izz,Ixy,Iyz,Ixz.
Omega() returns components of the angular velocity of the group of
atoms around its center of mass.</p>
<p>Region functions are specified exactly the same way as group functions
except they take an extra final argument <em>IDR</em> which is the region ID.
The function is computed for all atoms that are in both the group and
the region. If the group is “all”, then the only criteria for atom
inclusion is that it be in the region.</p>
</div>
<hr class="docutils" />
<div class="section" id="special-functions">
<h3>Special Functions</h3>
<p>Special functions take specific kinds of arguments, meaning their
arguments cannot be formulas themselves.</p>
<p>The sum(x), min(x), max(x), ave(x), trap(x), and slope(x) functions
each take 1 argument which is of the form “c_ID” or “c_ID[N]” or
“f_ID” or “f_ID[N]” or “v_name”. The first two are computes and the
second two are fixes; the ID in the reference should be replaced by
the ID of a compute or fix defined elsewhere in the input script. The
compute or fix must produce either a global vector or array. If it
produces a global vector, then the notation without “[N]” should be
used. If it produces a global array, then the notation with “[N]”
should be used, when N is an integer, to specify which column of the
global array is being referenced. The last form of argument “v_name”
is for a vector-style variable where “name” is replaced by the name of
the variable.</p>
<p>These functions operate on a global vector of inputs and reduce it to
a single scalar value. This is analagous to the operation of the
<a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a> command, which performs similar
operations on per-atom and local vectors.</p>
<p>The sum() function calculates the sum of all the vector elements. The
min() and max() functions find the minimum and maximum element
respectively. The ave() function is the same as sum() except that it
divides the result by the length of the vector.</p>
<p>The trap() function is the same as sum() except the first and last
elements are multiplied by a weighting factor of 1/2 when performing
the sum. This effectively implements an integration via the
trapezoidal rule on the global vector of data. I.e. consider a set of
points, equally spaced by 1 in their x coordinate: (1,V1), (2,V2),
..., (N,VN), where the Vi are the values in the global vector of
length N. The integral from 1 to N of these points is trap(). When
appropriately normalized by the timestep size, this function is useful
for calculating integrals of time-series data, like that generated by
the <a class="reference internal" href="fix_ave_correlate.html"><span class="doc">fix ave/correlate</span></a> command.</p>
<p>The slope() function uses linear regression to fit a line to the set
of points, equally spaced by 1 in their x coordinate: (1,V1), (2,V2),
..., (N,VN), where the Vi are the values in the global vector of
length N. The returned value is the slope of the line. If the line
has a single point or is vertical, it returns 1.0e20.</p>
<p>The gmask(x) function takes 1 argument which is a group ID. It
can only be used in atom-style variables. It returns a 1 for
atoms that are in the group, and a 0 for atoms that are not.</p>
<p>The rmask(x) function takes 1 argument which is a region ID. It can
only be used in atom-style variables. It returns a 1 for atoms that
are in the geometric region, and a 0 for atoms that are not.</p>
<p>The grmask(x,y) function takes 2 arguments. The first is a group ID,
and the second is a region ID. It can only be used in atom-style
variables. It returns a 1 for atoms that are in both the group and
region, and a 0 for atoms that are not in both.</p>
<p>The next(x) function takes 1 argument which is a variable ID (not
“v_foo”, just “foo”). It must be for a file-style or atomfile-style
variable. Each time the next() function is invoked (i.e. each time
the equal-style or atom-style variable is evaluated), the following
steps occur.</p>
<p>For file-style variables, the current string value stored by the
file-style variable is converted to a numeric value and returned by
the function. And the next string value in the file is read and
stored. Note that if the line previously read from the file was not a
numeric string, then it will typically evaluate to 0.0, which is
likely not what you want.</p>
<p>For atomfile-style variables, the current per-atom values stored by
the atomfile-style variable are returned by the function. And the
next set of per-atom values in the file is read and stored.</p>
<p>Since file-style and atomfile-style variables read and store the first
line of the file or first set of per-atoms values when they are
defined in the input script, these are the value(s) that will be
returned the first time the next() function is invoked. If next() is
invoked more times than there are lines or sets of lines in the file,
the variable is deleted, similar to how the <a class="reference internal" href="next.html"><span class="doc">next</span></a> command
operates.</p>
</div>
<hr class="docutils" />
<div class="section" id="feature-functions">
<h3>Feature Functions</h3>
<p>Feature functions allow to probe the running LAMMPS executable for
whether specific features are either active, defined, or available.
The functions take two arguments, a <em>category</em> and a corresponding
<em>argument</em>. The arguments are strings thus cannot be formulas
themselves (only $-style immediate variable expansion is possible).
Return value is either 1.0 or 0.0 depending on whether the function
evaluates to true or false, respectively.</p>
<p>The <em>is_active()</em> function allows to query for active settings which
are grouped by categories. Currently supported categories and
arguments are:</p>
<ul class="simple">
<li><em>package</em> (argument = <em>cuda</em> or <em>gpu</em> or <em>intel</em> or <em>kokkos</em> or <em>omp</em>)</li>
<li><em>newton</em> (argument = <em>pair</em> or <em>bond</em> or <em>any</em>)</li>
<li><em>pair</em> (argument = <em>single</em> or <em>respa</em> or <em>manybody</em> or <em>tail</em> or <em>shift</em>)</li>
<li><em>comm_style</em> (argument = <em>brick</em> or <em>tiled</em>)</li>
<li><em>min_style</em> (argument = any of the compiled in minimizer styles)</li>
<li><em>run_style</em> (argument = any of the compiled in run styles)</li>
<li><em>atom_style</em> (argument = any of the compiled in atom styles)</li>
<li><em>pair_style</em> (argument = any of the compiled in pair styles)</li>
<li><em>bond_style</em> (argument = any of the compiled in bond styles)</li>
<li><em>angle_style</em> (argument = any of the compiled in angle styles)</li>
<li><em>dihedral_style</em> (argument = any of the compiled in dihedral styles)</li>
<li><em>improper_style</em> (argument = any of the compiled in improper styles)</li>
<li><em>kspace_style</em> (argument = any of the compiled in kspace styles)</li>
</ul>
<p>Most of the settings are self-explanatory, the <em>single</em> argument in the
<em>pair</em> category allows to check whether a pair style supports a
Pair::single() function as needed by compute group/group and others
features or LAMMPS, <em>respa</em> allows to check whether the inner/middle/outer
mode of r-RESPA is supported. In the various style categories,
the checking is also done using suffix flags, if available and enabled.</p>
<p>Example 1: disable use of suffix for pppm when using GPU package (i.e. run it on the CPU concurrently to running the pair style on the GPU), but do use the suffix otherwise (e.g. with USER-OMP).</p>
<p>Atom values take an integer argument I from 1 to N, where I is the
atom-ID, e.g. x[243], which means use the x coordinate of the atom
with ID = 243. Or they can take a variable name, specified as v_name,
where name is the name of the variable, like x[v_myIndex]. The
variable can be of any style except <em>vector</em> or <em>atom</em> or <em>atomfile</em>
variables. The variable is evaluated and the result is expected to be
numeric and is cast to an integer (i.e. 3.4 becomes 3), to use an an
index, which must be a value from 1 to N. Note that a “formula”
cannot be used as the argument between the brackets, e.g. x[243+10]
or x[v_myIndex+1] are not allowed. To do this a single variable can
be defined that contains the needed formula.</p>
<p>Note that the 0 < atom-ID <= N, where N is the largest atom ID
in the system. If an ID is specified for an atom that does not
currently exist, then the generated value is 0.0.</p>
<p>Atom vectors generate one value per atom, so that a reference like
“vx” means the x-component of each atom’s velocity will be used when
evaluating the variable.</p>
<p>The meaning of the different atom values and vectors is mostly
self-explanatory. <em>Mol</em> refers to the molecule ID of an atom, and is
only defined if an <a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a> is being used that
defines molecule IDs.</p>
<p>Note that many other atom attributes can be used as inputs to a
variable by using the <a class="reference internal" href="compute_property_atom.html"><span class="doc">compute property/atom</span></a> command and then specifying
a quantity from that compute.</p>
</div>
<hr class="docutils" />
<div class="section" id="compute-references">
<h3>Compute References</h3>
<p>Compute references access quantities calculated by a
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a>. The ID in the reference should be replaced by
the ID of a compute defined elsewhere in the input script. As
discussed in the doc page for the <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command,
computes can produce global, per-atom, or local values. Only global
and per-atom values can be used in a variable. Computes can also
produce a scalar, vector, or array.</p>
<p>An equal-style variable can only use scalar values, which means a
global scalar, or an element of a global or per-atom vector or array.
A vector-style variable can use scalar values or a global vector of
values, or a column of a global array of values. Atom-style variables
can use global scalar values. They can also use per-atom vector
values, or a column of a per-atom array. See the doc pages for
individual computes to see what kind of values they produce.</p>
<p>Examples of different kinds of compute references are as follows.
There is typically no ambiguity (see exception below) as to what a
reference means, since computes only produce either global or per-atom
quantities, never both.</p>
<table border="1" class="docutils">
<colgroup>
-<col width="10%" />
-<col width="90%" />
+<col width="11%" />
+<col width="89%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>c_ID</td>
<td>global scalar, or per-atom vector</td>
</tr>
<tr class="row-even"><td>c_ID[I]</td>
<td>Ith element of global vector, or atom I’s value in per-atom vector, or Ith column from per-atom array</td>
</tr>
<tr class="row-odd"><td>c_ID[I][J]</td>
<td>I,J element of global array, or atom I’s Jth value in per-atom array</td>
</tr>
</tbody>
</table>
<p>For I and J indices, integers can be specified or a variable name,
specified as v_name, where name is the name of the variable. The
rules for this syntax are the same as for the “Atom Values and
Vectors” discussion above.</p>
<p>One source of ambiguity for compute references is when a vector-style
variable refers to a compute that produces both a global scalar and a
global vector. Consider a compute with ID “foo” that does this,
referenced as follows by variable “a”, where “myVec” is another
<p>The reference “c_foo” could refer to either the global scalar or
global vector produced by compute “foo”. In this case, “c_foo” will
always refer to the global scalar, and “C_foo” can be used to
reference the global vector. Similarly if the compute produces both a
global vector and global array, then “c_foo[I]” will always refer to
an element of the global vector, and “C_foo[I]” can be used to
reference the Ith column of the global array.</p>
<p>Note that if a variable containing a compute is evaluated directly in
an input script (not during a run), then the values accessed by the
compute must be current. See the discussion below about “Variable
Accuracy”.</p>
</div>
<hr class="docutils" />
<div class="section" id="fix-references">
<h3>Fix References</h3>
<p>Fix references access quantities calculated by a <a class="reference internal" href="compute.html"><span class="doc">fix</span></a>.
The ID in the reference should be replaced by the ID of a fix defined
elsewhere in the input script. As discussed in the doc page for the
<a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command, fixes can produce global, per-atom, or local
values. Only global and per-atom values can be used in a variable.
Fixes can also produce a scalar, vector, or array. An equal-style
variable can only use scalar values, which means a global scalar, or
an element of a global or per-atom vector or array. Atom-style
variables can use the same scalar values. They can also use per-atom
vector values. A vector value can be a per-atom vector itself, or a
column of an per-atom array. See the doc pages for individual fixes
to see what kind of values they produce.</p>
<p>The different kinds of fix references are exactly the same as the
-compute references listed in the above table, where “<a href="#id1"><span class="problematic" id="id2">c_</span></a>” is replaced
-by “<a href="#id3"><span class="problematic" id="id4">f_</span></a>”. Again, there is typically no ambiguity (see exception below)
+compute references listed in the above table, where “c_” is replaced
+by “f_”. Again, there is typically no ambiguity (see exception below)
as to what a reference means, since fixes only produce either global
or per-atom quantities, never both.</p>
<table border="1" class="docutils">
<colgroup>
-<col width="10%" />
-<col width="90%" />
+<col width="11%" />
+<col width="89%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>f_ID</td>
<td>global scalar, or per-atom vector</td>
</tr>
<tr class="row-even"><td>f_ID[I]</td>
<td>Ith element of global vector, or atom I’s value in per-atom vector, or Ith column from per-atom array</td>
</tr>
<tr class="row-odd"><td>f_ID[I][J]</td>
<td>I,J element of global array, or atom I’s Jth value in per-atom array</td>
</tr>
</tbody>
</table>
<p>For I and J indices, integers can be specified or a variable name,
specified as v_name, where name is the name of the variable. The
rules for this syntax are the same as for the “Atom Values and
Vectors” discussion above.</p>
<p>One source of ambiguity for fix references is the same ambiguity
discussed for compute references above. Namely when a vector-style
variable refers to a fix that produces both a global scalar and a
global vector. The solution is the same as for compute references.
For a fix with ID “foo”, “f_foo” will always refer to the global
scalar, and “F_foo” can be used to reference the global vector. And
similarly for distinguishing between a fix’s global vector versus
global array with “f_foo[I]” versus “F_foo[I]”.</p>
<p>Note that if a variable containing a fix is evaluated directly in an
input script (not during a run), then the values accessed by the fix
should be current. See the discussion below about “Variable
Accuracy”.</p>
<p>Note that some fixes only generate quantities on certain timesteps.
If a variable attempts to access the fix on non-allowed timesteps, an
error is generated. For example, the <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a>
command may only generate averaged quantities every 100 steps. See
the doc pages for individual fix commands for details.</p>
</div>
<hr class="docutils" />
<div class="section" id="variable-references">
<h3>Variable References</h3>
<p>Variable references access quantities stored or calculated by other
variables, which will cause those variables to be evaluated. The name
in the reference should be replaced by the name of a variable defined
elsewhere in the input script.</p>
<p>As discussed on this doc page, equal-style variables generate a single
global numeric value, vector-style variables gerarate a vector of
global numeric values, and atom-style and atomfile-style variables
generate a per-atom vector of numeric values. All other variables
store one or more strings.</p>
<p>The formula for an equal-style variable can use any style of variable
including a vector_style or atom-style or atomfile-style. For these
3 styles, a subscript must be used to access a single value from
the vector-, atom-, or atomfile-style variable. If a string-storing
variable is used, the string is converted to a numeric value. Note
that this will typically produce a 0.0 if the string is not a numeric
string, which is likely not what you want.</p>
<p>The formula for a vector-style variable can use any style of variable,
including atom-style or atomfile-style variables. For these 2 styles,
a subscript must be used to access a single value from the atom-, or
atomfile-style variable.</p>
<p>The formula for an atom-style variable can use any style of variable,
including other atom-style or atomfile-style variables. If it uses a
vector-style variable, a subscript must be used to access a single
value from the vector-style variable.</p>
<p>Examples of different kinds of variable references are as follows.
There is no ambiguity as to what a reference means, since variables
produce only a global scalar or global vector or per-atom vector.</p>
<table border="1" class="docutils">
<colgroup>
-<col width="14%" />
-<col width="86%" />
+<col width="15%" />
+<col width="85%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>v_name</td>
<td>global scalar from equal-style variable</td>
</tr>
<tr class="row-even"><td>v_name</td>
<td>global vector from vector-style variable</td>
</tr>
<tr class="row-odd"><td>v_name</td>
<td>per-atom vector from atom-style or atomfile-style variable</td>
</tr>
<tr class="row-even"><td>v_name[I]</td>
<td>Ith element of a global vector from vector-style variable</td>
</tr>
<tr class="row-odd"><td>v_name[I]</td>
<td>value of atom with ID = I from atom-style or atomfile-style variable</td>
</tr>
</tbody>
</table>
<p>For the I index, an integer can be specified or a variable name,
specified as v_name, where name is the name of the variable. The
rules for this syntax are the same as for the “Atom Values and
Vectors” discussion above.</p>
<hr class="docutils" />
<p><strong>Immediate Evaluation of Variables:</strong></p>
<p>If you want an equal-style variable to be evaluated immediately, it
may be the case that you do not need to define a variable at all. See
<a class="reference internal" href="Section_commands.html#cmd-2"><span class="std std-ref">Section 3.2</span></a> of the manual, which
describes the use of “immediate” variables in an input script,
specified as $(formula) with parenthesis, where the formula has the
same syntax as equal-style variables described on this page. This
effectively evaluates a formula immediately without using the variable
command to define a named variable.</p>
<p>More generally, there is a difference between referencing a variable
-with a leading $ sign (e.g. $x or ${abc}) versus with a leading “<a href="#id5"><span class="problematic" id="id6">v_</span></a>”
+with a leading $ sign (e.g. $x or ${abc}) versus with a leading “v_”
(e.g. v_x or v_abc). The former can be used in any input script
command, including a variable command. The input script parser
evaluates the reference variable immediately and substitutes its value
into the command. As explained in <a class="reference internal" href="Section_commands.html#cmd-2"><span class="std std-ref">Section commands 3.2</span></a> for “Parsing rules”, you can also use
un-named “immediate” variables for this purpose. For example, a
string like this $((xlo+xhi)/2+sqrt(v_area)) in an input script
command evaluates the string between the parenthesis as an equal-style
variable formula.</p>
-<p>Referencing a variable with a leading “<a href="#id7"><span class="problematic" id="id8">v_</span></a>” is an optional or required
+<p>Referencing a variable with a leading “v_” is an optional or required
kind of argument for some commands (e.g. the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> or <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> or
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> commands) if you wish it to evaluate
a variable periodically during a run. It can also be used in a
variable formula if you wish to reference a second variable. The
second variable will be evaluated whenever the first variable is
evaluated.</p>
<p>As an example, suppose you use this command in your input script to
<p>before a run where the simulation box size changes. You might think
this will assign the initial volume to the variable “v”. That is not
the case. Rather it assigns a formula which evaluates the volume
(using the thermo_style keyword “vol”) to the variable “v”. If you
use the variable “v” in some other command like <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a> then the current volume of the box will be
evaluated continuously during the run.</p>
<p>If you want to store the initial volume of the system, you can do it
this way:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span>variable v equal vol
variable v0 equal $v
</pre></div>
</div>
<p>The second command will force “v” to be evaluated (yielding the
initial volume) and assign that value to the variable “v0”. Thus the
<p>This is because the quotes prevent variable substitution (see <a class="reference internal" href="Section_commands.html#cmd-2"><span class="std std-ref">this section</span></a> on parsing input script
commands), and thus an error will occur when the formula for “vratio”
is evaluated later.</p>
<hr class="docutils" />
<p><strong>Variable Accuracy:</strong></p>
<p>Obviously, LAMMPS attempts to evaluate variables containing formulas
(<em>equal</em> and <em>atom</em> style variables) accurately whenever the
evaluation is performed. Depending on what is included in the
formula, this may require invoking a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>, either
directly or indirectly via a thermo keyword, or accessing a value
previously calculated by a compute, or accessing a value calculated
and stored by a <a class="reference internal" href="fix.html"><span class="doc">fix</span></a>. If the compute is one that calculates
the pressure or energy of the system, then these quantities need to be
tallied during the evaluation of the interatomic potentials (pair,
bond, etc) on timesteps that the variable will need the values.</p>
<p>LAMMPS keeps track of all of this during a <a class="reference internal" href="run.html"><span class="doc">run</span></a> or <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>. An error will be generated if you
attempt to evaluate a variable on timesteps when it cannot produce
accurate values. For example, if a <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command prints a variable which accesses
values stored by a <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a> command and the
timesteps on which thermo output is generated are not multiples of the
averaging frequency used in the fix command, then an error will occur.</p>
<p>An input script can also request variables be evaluated before or
after or in between runs, e.g. by including them in a
<a class="reference internal" href="print.html"><span class="doc">print</span></a> command. In this case, if a compute is needed to
evaluate a variable (either directly or indirectly), LAMMPS will not
invoke the compute, but it will use a value previously calculated by
the compute, and can do this only if it was invoked on the current
timestep. Fixes will always provide a quantity needed by a variable,
but the quantity may or may not be current. This leads to one of
three kinds of behavior:</p>
<p>(1) The variable may be evaluated accurately. If it contains
references to a compute or fix, and these values were calculated on
the last timestep of a preceeding run, then they will be accessed and
used by the variable and the result will be accurate.</p>
<p>(2) LAMMPS may not be able to evaluate the variable and will generate
an error message stating so. For example, if the variable requires a
quantity from a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> that has not been invoked on
the current timestep, LAMMPS will generate an error. This means, for
example, that such a variable cannot be evaluated before the first run
has occurred. Likewise, in between runs, a variable containing a
compute cannot be evaluated unless the compute was invoked on the last
timestep of the preceding run, e.g. by thermodynamic output.</p>
<p>One way to get around this problem is to perform a 0-timestep run
before using the variable. For example, these commands</p>
-<span class="nb">print</span> <span class="s2">"Final potential energy = $e"</span>
-</pre></div>
-</div>
+<pre class="literal-block">
+pair_coeff 1 1 1.0 1.0
+run 1000
+pair_coeff 1 1 1.5 1.0
+variable e equal pe
+print "Final potential energy = $e"
+</pre>
<p>The first run is performed using one setting for the pairwise
potential defined by the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> and
<a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> commands. The potential energy is
evaluated on the final timestep and stored by the <a class="reference internal" href="compute_pe.html"><span class="doc">compute pe</span></a> compute (this is done by the
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command). Then a pair coefficient is
changed, altering the potential energy of the system. When the
potential energy is printed via the “e” variable, LAMMPS will use the
potential energy value stored by the <a class="reference internal" href="compute_pe.html"><span class="doc">compute pe</span></a>
compute, thinking it is current. There are many other commands which
could alter the state of the system between runs, causing a variable
to evaluate incorrectly.</p>
<p>The solution to this issue is the same as for case (2) above, namely
perform a 0-timestep run before the variable is evaluated to insure
the system is up-to-date. For example, this sequence of commands
would print a potential energy that reflected the changed pairwise
-<span class="nb">print</span> <span class="s2">"Final potential energy = $e"</span>
-</pre></div>
-</div>
+<pre class="literal-block">
+pair_coeff 1 1 1.0 1.0
+run 1000
+pair_coeff 1 1 1.5 1.0
+run 0
+variable e equal pe
+print "Final potential energy = $e"
+</pre>
</div>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>Indexing any formula element by global atom ID, such as an atom value,
requires the <a class="reference internal" href="atom_style.html"><span class="doc">atom style</span></a> to use a global mapping in
order to look up the vector indices. By default, only atom styles
with molecular information create global maps. The <a class="reference internal" href="atom_modify.html"><span class="doc">atom_modify map</span></a> command can override the default, e.g. for
atomic-style atom styles.</p>
<p>All <em>universe</em>- and <em>uloop</em>-style variables defined in an input script
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+velocity all create 300.0 4928459 rot yes dist gaussian
+velocity border set NULL 4.0 v_vz sum yes units box
+velocity flow scale 300.0
+velocity flow ramp vx 0.0 5.0 y 5 25 temp mytemp
+velocity all zero linear
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Set or change the velocities of a group of atoms in one of several
styles. For each style, there are required arguments and optional
keyword/value parameters. Not all options are used by each style.
Each option has a default as listed below.</p>
<p>The <em>create</em> style generates an ensemble of velocities using a random
number generator with the specified seed as the specified temperature.</p>
<p>The <em>set</em> style sets the velocities of all atoms in the group to the
specified values. If any component is specified as NULL, then it is
not set. Any of the vx,vy,vz velocity components can be specified as
an equal-style or atom-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>. If the value
is a variable, it should be specified as v_name, where name is the
variable name. In this case, the variable will be evaluated, and its
value used to determine the velocity component. Note that if a
variable is used, the velocity it calculates must be in box units, not
lattice units; see the discussion of the <em>units</em> keyword below.</p>
<p>Equal-style variables can specify formulas with various mathematical
functions, and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command
keywords for the simulation box parameters or other parameters.</p>
<p>Atom-style variables can specify the same formulas as equal-style
variables but can also include per-atom values, such as atom
coordinates. Thus it is easy to specify a spatially-dependent
velocity field.</p>
<p>The <em>scale</em> style computes the current temperature of the group of
atoms and then rescales the velocities to the specified temperature.</p>
<p>The <em>ramp</em> style is similar to that used by the <a class="reference internal" href="compute_temp_ramp.html"><span class="doc">compute temp/ramp</span></a> command. Velocities ramped
uniformly from vlo to vhi are applied to dimension vx, or vy, or vz.
The value assigned to a particular atom depends on its relative
coordinate value (in dim) from clo to chi. For the example above, an
atom with y-coordinate of 10 (1/4 of the way from 5 to 25), would be
assigned a x-velocity of 1.25 (1/4 of the way from 0.0 to 5.0). Atoms
outside the coordinate bounds (less than 5 or greater than 25 in this
case), are assigned velocities equal to vlo or vhi (0.0 or 5.0 in this
case).</p>
<p>The <em>zero</em> style adjusts the velocities of the group of atoms so that
the aggregate linear or angular momentum is zero. No other changes
are made to the velocities of the atoms. If the <em>rigid</em> option is
specified (see below), then the zeroing is performed on individual
rigid bodies, as defined by the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid or fix rigid/small</span></a> commands. In other words, zero linear
will set the linear momentum of each rigid body to zero, and zero
angular will set the angular momentum of each rigid body to zero.
This is done by adjusting the velocities of the atoms in each rigid
body.</p>
<p>All temperatures specified in the velocity command are in temperature
units; see the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command. The units of velocities and
coordinates depend on whether the <em>units</em> keyword is set to <em>box</em> or
<em>lattice</em>, as discussed below.</p>
<p>For all styles, no atoms are assigned z-component velocities if the
simulation is 2d; see the <a class="reference internal" href="dimension.html"><span class="doc">dimension</span></a> command.</p>
<hr class="docutils" />
<p>The keyword/value options are used in the following ways by the
various styles.</p>
<p>The <em>dist</em> keyword is used by <em>create</em>. The ensemble of generated
velocities can be a <em>uniform</em> distribution from some minimum to
maximum value, scaled to produce the requested temperature. Or it can
be a <em>gaussian</em> distribution with a mean of 0.0 and a sigma scaled to
produce the requested temperature.</p>
<p>The <em>sum</em> keyword is used by all styles, except <em>zero</em>. The new
velocities will be added to the existing ones if sum = yes, or will
replace them if sum = no.</p>
<p>The <em>mom</em> and <em>rot</em> keywords are used by <em>create</em>. If mom = yes, the
linear momentum of the newly created ensemble of velocities is zeroed;
<p>where group-ID is the same ID used in the velocity command. i.e. the
group of atoms whose velocity is being altered. This compute is
deleted when the velocity command is finished. See the <a class="reference internal" href="compute_temp.html"><span class="doc">compute temp</span></a> command for details. If the calculated
temperature should have degrees-of-freedom removed due to fix
constraints (e.g. SHAKE or rigid-body constraints), then the
appropriate fix command must be specified before the velocity command
is issued.</p>
<p>The <em>bias</em> keyword with a <em>yes</em> setting is used by <em>create</em> and
<em>scale</em>, but only if the <em>temp</em> keyword is also used to specify a
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> that calculates temperature in a desired way.
If the temperature compute also calculates a velocity bias, the the
bias is subtracted from atom velocities before the <em>create</em> and
<em>scale</em> operations are performed. After the operations, the bias is
added back to the atom velocities. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section howto 16</span></a> of the doc pages for more discussion
of temperature computes with biases. Note that the velocity bias is
only applied to atoms in the temperature compute specified with the
<em>temp</em> keyword.</p>
<p>As an example, assume atoms are currently streaming in a flow
direction (which could be separately initialized with the <em>ramp</em>
style), and you wish to initialize their thermal velocity to a desired
temperature. In this context thermal velocity means the per-particle
velocity that remains when the streaming velocity is subtracted. This
can be done using the <em>create</em> style with the <em>temp</em> keyword
specifying the ID of a <a class="reference internal" href="compute_temp_ramp.html"><span class="doc">compute temp/ramp</span></a> or
<a class="reference internal" href="compute_temp_profile.html"><span class="doc">compute temp/profile</span></a> command, and the
<em>bias</em> keyword set to a <em>yes</em> value.</p>
<hr class="docutils" />
<p>The <em>loop</em> keyword is used by <em>create</em> in the following ways.</p>
<p>If loop = all, then each processor loops over all atoms in the
simulation to create velocities, but only stores velocities for atoms
it owns. This can be a slow loop for a large simulation. If atoms
were read from a data file, the velocity assigned to a particular atom
will be the same, independent of how many processors are being used.
This will not be the case if atoms were created using the
<a class="reference internal" href="create_atoms.html"><span class="doc">create_atoms</span></a> command, since atom IDs will likely
be assigned to atoms differently.</p>
<p>If loop = local, then each processor loops over only its atoms to
produce velocities. The random number seed is adjusted to give a
different set of velocities on each processor. This is a fast loop,
but the velocity assigned to a particular atom will depend on which
processor owns it. Thus the results will always be different when a
simulation is run on a different number of processors.</p>
<p>If loop = geom, then each processor loops over only its atoms. For
each atom a unique random number seed is created, based on the atom’s
xyz coordinates. A velocity is generated using that seed. This is a
fast loop and the velocity assigned to a particular atom will be the
same, independent of how many processors are used. However, the set
of generated velocities may be more correlated than if the <em>all</em> or
<em>local</em> keywords are used.</p>
<p>Note that the <em>loop geom</em> keyword will not necessarily assign
identical velocities for two simulations run on different machines.
This is because the computations based on xyz coordinates are
sensitive to tiny differences in the double-precision value for a
coordinate as stored on a particular machine.</p>
<hr class="docutils" />
<p>The <em>rigid</em> keyword only has meaning when used with the <em>zero</em> style.
It allows specification of a fix-ID for one of the <a class="reference internal" href="fix_rigid.html"><span class="doc">rigid-body fix</span></a> variants which defines a set of rigid bodies. The
zeroing of linear or angular momentum is then performed for each rigid
body defined by the fix, as described above.</p>
<p>The <em>units</em> keyword is used by <em>set</em> and <em>ramp</em>. If units = box,
the velocities and coordinates specified in the velocity command are
in the standard units described by the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command
(e.g. Angstroms/fmsec for real units). If units = lattice, velocities
are in units of lattice spacings per time (e.g. spacings/fmsec) and
coordinates are in lattice spacings. The <a class="reference internal" href="lattice.html"><span class="doc">lattice</span></a>
command must have been previously used to define the lattice spacing.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>Assigning a temperature via the <em>create</em> style to a system with <a class="reference internal" href="fix_rigid.html"><span class="doc">rigid bodies</span></a> or <a class="reference internal" href="fix_shake.html"><span class="doc">SHAKE constraints</span></a> may not
have the desired outcome for two reasons. First, the velocity command
can be invoked before all of the relevant fixes are created and
initialized and the number of adjusted degrees of freedom (DOFs) is
known. Thus it is not possible to compute the target temperature
correctly. Second, the assigned velocities may be partially canceled
when constraints are first enforced, leading to a different
temperature than desired. A workaround for this is to perform a <a class="reference internal" href="run.html"><span class="doc">run 0</span></a> command, which insures all DOFs are accounted for
properly, and then rescale the temperature to the desired value before
<span class="n">run</span> <span class="mi">0</span> <span class="c1"># temperature may not be 300K</span>
<span class="n">velocity</span> <span class="nb">all</span> <span class="n">scale</span> <span class="mf">300.0</span> <span class="c1"># now it should be</span>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>group-ID = ID of the group of atoms to be dumped</li>
<li>style = any of the supported <a class="reference internal" href="dump.html"><span class="doc">dump styles</span></a></li>
<li>file = name of file to write dump info to</li>
<li>dump-args = any additional args needed for a particular <a class="reference internal" href="dump.html"><span class="doc">dump style</span></a></li>
<li>modify = all args after this keyword are passed to <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> (optional)</li>
<li>dump-modify-args = args for <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> (optional)</li>
+write_dump all custom dump.myforce.* id type x y vx fx
+write_dump flow custom dump.%.myforce id type c_myF[3] v_ke modify sort id
+write_dump all xyz system.xyz modify sort id elements O H
+write_dump all image snap*.jpg type type size 960 960 modify backcolor white
+write_dump all image snap*.jpg element element &
+ bond atom 0.3 shiny 0.1 ssao yes 6345 0.2 size 1600 1600 &
+ modify backcolor white element C C O H N C C C O H H S O H
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Dump a single snapshot of atom quantities to one or more files for the
current state of the system. This is a one-time immediate operation,
in contrast to the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command which will will set up a
dump style to write out snapshots periodically during a running
simulation.</p>
<p>The syntax for this command is mostly identical to that of the
<a class="reference internal" href="dump.html"><span class="doc">dump</span></a> and <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> commands as if
they were concatenated together, with the following exceptions: There
is no need for a dump ID or dump frequency and the keyword <em>modify</em> is
added. The latter is so that the full range of
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> options can be specified for the single
snapshot, just as they can be for multiple snapshots. The <em>modify</em>
keyword separates the arguments that would normally be passed to the
<em>dump</em> command from those that would be given the <em>dump_modify</em>. Both
support optional arguments and thus LAMMPS needs to be able to cleanly
separate the two sets of args.</p>
<p>Note that if the specified filename uses wildcard characters “*” or
“%”, as supported by the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> commmand, they will operate
in the same fashion to create the new filename(s). Normally, <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a> files require a filename with a “*” character
for the timestep. That is not the case for the write_dump command; no
wildcard “*” character is necessary.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>All restrictions for the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> and
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> commands apply to this command as well,
with the exception of the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a> filename not
requiring a wildcard “*” character, as noted above.</p>
<p>Since dumps are normally written during a <a class="reference internal" href="run.html"><span class="doc">run</span></a> or <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>, the simulation has to be ready to run
before this command can be used. Similarly, if the dump requires
information from a compute, fix, or variable, the information needs to
have been calculated for the current timestep (e.g. by a prior run),
else LAMMPS will generate an error message.</p>
<p>For example, it is not possible to dump per-atom energy with this
command before a run has been performed, since no energies and forces
have yet been calculated. See the <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> doc page
sectinn on Variable Accuracy for more information on this topic.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.