<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>.
<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>.
<p><strong>Building LAMMPS with the OPT package:</strong></p>
<p>The lines above illustrate how to build LAMMPS with the OPT 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 if you use an Intel compiler to build with the OPT package,
the CCFLAGS setting in your Makefile.machine must include “-restrict”.
The Make.py command will add this automatically.</p>
<p><strong>Run with the OPT package from the command line:</strong></p>
<p>As in the lines above, use the “-sf opt” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>, which will automatically append
“opt” to styles that support it.</p>
<p><strong>Or run with the OPT package by editing an input script:</strong></p>
<p>Use the <a class="reference internal" href="suffix.html"><span class="doc">suffix opt</span></a> command, or you can explicitly add an
“opt” suffix to individual styles in your input script, e.g.</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 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 <a class="reference internal" href="angle_class2.html"><span class="doc">angle_style class2</span></a> is an exception to this
rule, in that an additional argument is used in the input script to
allow specification of the cross-term coefficients. See its
doc page for details.</p>
<hr class="docutils" />
<p>Here is an alphabetic list of angle styles defined in LAMMPS. Click on
the style to display the formula it computes and coefficients
specified by the associated <a class="reference internal" href="#"><span class="doc">angle_coeff</span></a> command.</p>
<p>Note that there are also additional angle 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 angle 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>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>Note that it is not necessary to use the angle style <em>skip</em> in the
input script, since BondBond (or BondAngle) coefficients need not be
specified at all for angle types that are not <em>class2</em>.</p>
<p>An angle style of <em>none</em> with no additional coefficients can be used
in place of an angle style, either in a input script angle_coeff
command or in the data file, if you desire to turn off interactions
for specific angle types.</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>
<p>Unlike other angle styles, the hybrid angle style does not store angle
coefficient info for individual sub-styles in a <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Thus when retarting a simulation from a restart
file, you need to re-specify angle_coeff 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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>.
<li>style = <em>none</em> or <em>hybrid</em> or <em>charmm</em> or <em>class2</em> or <em>cosine</em> or <em>cosine/squared</em> or <em>harmonic</em></li>
<p>Hybrid models where angles are computed using different angle
potentials can be setup using the <em>hybrid</em> angle style.</p>
<p>The coefficients associated with a angle style can be specified in a
data or restart file or via the <a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command.</p>
<p>All angle potentials store their coefficient data in binary restart
files which means angle_style and <a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a>
commands do not need to be re-specified in an input script that
restarts a simulation. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
command for details on how to do this. The one exception is that
angle_style <em>hybrid</em> only stores the list of sub-styles in the restart
file; angle coefficients need to be re-specified.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When both an angle and pair style is defined, the
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command often needs to be used to
turn off (or weight) the pairwise interaction that would otherwise
exist between 3 bonded atoms.</p>
</div>
<p>In the formulas listed for each angle style, <em>theta</em> is the angle
between the 3 atoms in the angle.</p>
<hr class="docutils" />
<p>Here is an alphabetic list of angle styles defined in LAMMPS. Click on
the style to display the formula it computes and coefficients
specified by the associated <a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command.</p>
<p>Note that there are also additional angle 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 angle section of <a class="reference internal" href="Section_commands.html#cmd-5"><span class="std std-ref">this page</span></a>.</p>
<li><a class="reference internal" href="angle_table.html"><span class="doc">angle_style table</span></a> - tabulated by angle</li>
</ul>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>Angle styles can only be set for atom_styles that allow angles to be
defined.</p>
<p>Most angle 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 bond 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>.
<p>Style <em>table</em> creates interpolation tables of length <em>N</em> from angle
potential and derivative values listed in a file(s) as a function of
angle The files are read by the <a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a>
command.</p>
<p>The interpolation tables are created by fitting cubic splines to the
file values and interpolating energy and derivative values at each of
<em>N</em> angles. During a simulation, these tables are used to interpolate
energy and force values on individual atoms as needed. The
interpolation is done in one of 2 styles: <em>linear</em> or <em>spline</em>.</p>
<p>For the <em>linear</em> style, the angle is used to find 2 surrounding table
values from which an energy or its derivative 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 angle is used to
find the appropriate set of coefficients which are used to evaluate a
cubic polynomial which computes the energy or derivative.</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>filename</li>
<li>keyword</li>
</ul>
<p>The filename specifies a file containing tabulated energy and
derivative values. The keyword specifies a section of the file. The
format of this file is described below.</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"># Angle potential for harmonic (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
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_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>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="angle_style.html"><span class="doc">angle_style table</span></a> command. Let
Ntable = <em>N</em> in the angle_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 as needed to generate energy and derivative
values at Ntable different points. The resulting tables of length
Ntable are then used as described above, when computing energy and
force for individual angles and their atoms. 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.</p>
<p>The “FP” parameter is optional. If used, it is followed by two values
fplo and fphi, which are the 2nd derivatives at the innermost and
outermost angle settings. These values are needed by the spline
construction routines. If not specified by the “FP” parameter, they
are estimated (less accurately) by the first two and last two
derivative values in the table.</p>
<p>The “EQ” parameter is also optional. If used, it is followed by a the
equilibrium angle value, which is used, for example, by the <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command. If not used, the equilibrium angle is
set to 180.0.</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 (in degrees), the 3rd value is the energy (in energy
units), and the 4th is -dE/d(theta) (also in energy units). The 3rd
term is the energy of the 3-atom configuration for the specified
angle. The last term is the derivative of the energy with respect to
the angle (in degrees, not radians). Thus the units of the last term
are still energy, not force. The angle values must increase from one
line to the next. The angle values must also begin with 0.0 and end
with 180.0, i.e. span the full range of possible angles.</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>
</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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>Here is an alphabetic list of bond styles defined in LAMMPS. Click on
the style to display the formula it computes and coefficients
specified by the associated <a class="reference internal" href="#"><span class="doc">bond_coeff</span></a> command.</p>
<p>Note that here are also additional bond 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 bond 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>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>A bond style of <em>none</em> with no additional coefficients can be used in
place of a bond style, either in a input script bond_coeff command or
in the data file, if you desire to turn off interactions for specific
bond types.</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>Unlike other bond styles, the hybrid bond style does not store bond
coefficient info for individual sub-styles in a <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Thus when retarting a simulation from a restart
file, you need to re-specify bond_coeff 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>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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>style = <em>none</em> or <em>hybrid</em> or <em>class2</em> or <em>fene</em> or <em>fene/expand</em> or <em>harmonic</em> or <em>morse</em> or <em>nonlinear</em> or <em>quartic</em></li>
<p>Set the formula(s) LAMMPS uses to compute bond interactions between
pairs of atoms. In LAMMPS, a bond differs from a pairwise
interaction, which are set via the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a>
command. Bonds are defined between specified pairs of atoms and
remain in force for the duration of the simulation (unless the bond
breaks which is possible in some bond potentials). The list of bonded
atoms is read in by a <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 from a data or restart file.
By contrast, pair potentials are typically defined between all pairs
of atoms within a cutoff distance and the set of active interactions
changes over time.</p>
<p>Hybrid models where bonds are computed using different bond potentials
can be setup using the <em>hybrid</em> bond style.</p>
<p>The coefficients associated with a bond style can be specified in a
data or restart file or via the <a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command.</p>
<p>All bond potentials store their coefficient data in binary restart
files which means bond_style and <a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> commands
do not need to be re-specified in an input script that restarts a
simulation. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for
details on how to do this. The one exception is that bond_style
<em>hybrid</em> only stores the list of sub-styles in the restart file; bond
coefficients need to be re-specified.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When both a bond and pair style is defined, the
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command often needs to be used to
turn off (or weight) the pairwise interaction that would otherwise
exist between 2 bonded atoms.</p>
</div>
<p>In the formulas listed for each bond style, <em>r</em> is the distance
between the 2 atoms in the bond.</p>
<hr class="docutils" />
<p>Here is an alphabetic list of bond styles defined in LAMMPS. Click on
the style to display the formula it computes and coefficients
specified by the associated <a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command.</p>
<p>Note that there are also additional bond 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 bond section of <a class="reference internal" href="Section_commands.html#cmd-5"><span class="std std-ref">this page</span></a>.</p>
<li><a class="reference internal" href="bond_table.html"><span class="doc">bond_style table</span></a> - tabulated by bond length</li>
</ul>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>Bond styles can only be set for atom styles that allow bonds to be
defined.</p>
<p>Most bond 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 bond 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>.
<p>Style <em>table</em> creates interpolation tables of length <em>N</em> from bond
potential and force values listed in a file(s) as a function of bond
length. The files are read by the <a class="reference internal" href="bond_coeff.html"><span class="doc">bond_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 2 styles: <em>linear</em> or <em>spline</em>.</p>
<p>For the <em>linear</em> style, the bond length 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 bond length 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>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.</p>
<ul class="simple">
<li>filename</li>
<li>keyword</li>
</ul>
<p>The filename specifies a file containing tabulated energy and force
values. The keyword specifies a section of the file. The format of
this file is described below.</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"># Bond potential for harmonic (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
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_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>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="bond_style.html"><span class="doc">bond_style table</span></a> command. Let
Ntable = <em>N</em> in the bond_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 as needed to generate 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 bond lengths. 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.</p>
<p>The “FP” parameter is optional. If used, it is followed by two values
fplo and fphi, which are the derivatives of the force at the innermost
and outermost bond lengths. These values are needed by the spline
construction routines. If not specified by the “FP” parameter, they
are estimated (less accurately) by the first two and last two force
values in the table.</p>
<p>The “EQ” parameter is also optional. If used, it is followed by a the
equilibrium bond length, which is used, for example, by the <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command. If not used, the equilibrium bond
length is to the distance in the table with the lowest potential energy.</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 bond length r (in distance units), the 3rd value is the energy (in
energy units), and the 4th is the force (in force units). The bond
lengths must range from a LO value to a HI value, and increase from
one line to the next. If the actual bond length is ever smaller than
the LO value or larger than the HI value, then the bond energy and
force is evaluated as if the bond were the LO or HI length.</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>
</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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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 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>This command sets the style of inter-processor communication of atom
information that occurs each timestep as coordinates and other
properties are exchanged between neighboring processors and stored as
properties of ghost atoms.</p>
<p>For the default <em>brick</em> style, the domain decomposition used by LAMMPS
to partition the simulation box must be a regular 3d grid of bricks,
one per processor. Each processor communicates with its 6 Cartesian
neighbors in the grid to acquire information for nearby atoms.</p>
<p>For the <em>tiled</em> style, a more general domain decomposition can be
used, as triggered by the <a class="reference internal" href="balance.html"><span class="doc">balance</span></a> or <a class="reference internal" href="fix_balance.html"><span class="doc">fix balance</span></a> commands. The simulation box can be
partitioned into non-overlapping rectangular-shaped “tiles” or varying
sizes and shapes. Again there is one tile per processor. To acquire
information for nearby atoms, communication must now be done with a
more complex pattern of neighboring processors.</p>
<p>Note that this command does not actually define a partitoining of the
simulation box (a domain decomposition), rather it determines what
kinds of decompositions are allowed and the pattern of communication
used to enable the decomposition. A decomposition is created when the
simulation box is first created, via 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>
commands. For both the <em>brick</em> and <em>tiled</em> styles, the initial
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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 angle
interactions. The number of datums generated, aggregated across all
processors, equals the number of angles in the system, modified by the
group parameter as explained below.</p>
<p>The value <em>theta</em> is the angle for the 3 atoms in the interaction.</p>
<p>The value <em>eng</em> is the interaction energy for the angle.</p>
<p>The local data stored by this command is generated by looping over all
the atoms owned on a processor and their angles. An angle will only
be included if all 3 atoms in the angle are in the specified compute
group. Any angles that have been broken (see the
<a class="reference internal" href="angle_style.html"><span class="doc">angle_style</span></a> command) by setting their angle type to
0 are not included. Angles 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 angle 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, angle 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>
+compute 1 all property/local atype aatom1 aatom2 aatom3
+compute 2 all angle/local theta eng
+dump 1 all local 1000 tmp.dump index c_1[1] c_1[2] c_1[3] c_1[4] 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 angles. 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>theta</em> will be in degrees. The output for <em>eng</em> will
be in energy <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>Define a computation that calculates the angular momemtum of 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 3 components of the angular momentum
vector for each chunk, due to the velocity/momentum of the individual
atoms in the chunk around the center-of-mass of the chunk. 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 angular
momentum 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 angmom/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 =
3 for the 3 xyz components of the angular momentum for each chunk.
These values can be accessed by any command that uses global array
values from a compute as input. See <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 properties of individual body
sub-particles. The number of datums generated, aggregated across all
processors, equals the number of body sub-particles plus the number of
non-body particles in the system, modified by the group parameter as
explained below. See <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>The local data stored by this command is generated by looping over all
the atoms. An atom will only be included if it is in the group. If
the atom is a body particle, then its N sub-particles will be looped
over, and it will contribute N datums to the count of datums. If it
is not a body particle, it will contribute 1 datum.</p>
<p>For both body particles and non-body particles, the <em>id</em> keyword
will store the ID of the particle.</p>
<p>For both body particles and non-body particles, the <em>type</em> keyword
will store the type of the particle.</p>
<p>The <em>integer</em> keywords mean different things for body and non-body
particles. If the atom is not a body particle, only its <em>x</em>, <em>y</em>, <em>z</em>
coordinates can be referenced, using the <em>integer</em> keywords 1,2,3.
Note that this means that if you want to access more fields than this
for body particles, then you cannot include non-body particles in the
group.</p>
<p>For a body particle, the <em>integer</em> keywords refer to fields calculated
by the body style for each sub-particle. The body style, as specified
by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style body</span></a>, determines how many fields
exist and what they are. See the <a class="reference internal" href="body.html"><span class="doc">body</span></a> doc page for
details of the different styles.</p>
<p>Here is an example of how to output body information using the <a class="reference internal" href="dump.html"><span class="doc">dump local</span></a> command with this compute. If fields 1,2,3 for the
body sub-particles are x,y,z coordinates, then the dump file will be
formatted similar to the output of a <a class="reference internal" href="dump.html"><span class="doc">dump atom or custom</span></a>
+dump 1 all local 1000 tmp.dump index c_1[1] c_1[2] c_1[3] c_1[4]
+</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 datums as described above. If a single keyword
is specified, a local vector is produced. If two or more keywords are
specified, a local array is produced where the number of columns = the
number of keywords. The vector or array can be accessed by any
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 <a class="reference internal" href="units.html"><span class="doc">units</span></a> for output values depend on the body style.</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>.
<li>ID, group-ID are documented in <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command</li>
<li>chunk/atom = style name of this compute command</li>
</ul>
<pre class="literal-block">
style = <em>bin/1d</em> or <em>bin/2d</em> or <em>bin/3d</em> or <em>bin/sphere</em> or <em>type</em> or <em>molecule</em> or <em>compute/fix/variable</em>
<em>bin/1d</em> args = dim origin delta
dim = <em>x</em> or <em>y</em> or <em>z</em>
origin = <em>lower</em> or <em>center</em> or <em>upper</em> or coordinate value (distance units)
delta = thickness of spatial bins in dim (distance units)
<em>bin/2d</em> args = dim origin delta dim origin delta
dim = <em>x</em> or <em>y</em> or <em>z</em>
origin = <em>lower</em> or <em>center</em> or <em>upper</em> or coordinate value (distance units)
delta = thickness of spatial bins in dim (distance units)
<em>bin/3d</em> args = dim origin delta dim origin delta dim origin delta
dim = <em>x</em> or <em>y</em> or <em>z</em>
origin = <em>lower</em> or <em>center</em> or <em>upper</em> or coordinate value (distance units)
delta = thickness of spatial bins in dim (distance units)
dim = <em>x</em> or <em>y</em> or <em>z</em> = axis of cylinder axis
origin = <em>lower</em> or <em>center</em> or <em>upper</em> or coordinate value (distance units)
delta = thickness of spatial bins in dim (distance units)
c1,c2 = coords of cylinder axis in other 2 dimensions (distance units)
crmin,crmax = bin from cylinder radius rmin to rmax (distance units)
ncbin = # of concentric circle bins between rmin and rmax
<em>type</em> args = none
<em>molecule</em> args = none
<em>compute/fix/variable</em> = c_ID, c_ID[I], f_ID, f_ID[I], v_name with no args
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
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
v_name = per-atom vector calculated by an atom-style variable with name
</pre>
<ul class="simple">
<li>zero or more keyword/values pairs may be appended</li>
<li>keyword = <em>region</em> or <em>nchunk</em> or <em>static</em> or <em>compress</em> or <em>bound</em> or <em>discard</em> or <em>pbc</em> or <em>units</em></li>
</ul>
<pre class="literal-block">
<em>region</em> value = region-ID
region-ID = ID of region atoms must be in to be part of a chunk
<em>nchunk</em> value = <em>once</em> or <em>every</em>
once = only compute the number of chunks once
every = re-compute the number of chunks whenever invoked
<em>limit</em> values = 0 or Nc max or Nc exact
0 = no limit on the number of chunks
Nc max = limit number of chunks to be <= Nc
Nc exact = set number of chunks to exactly Nc
<em>ids</em> value = <em>once</em> or <em>nfreq</em> or <em>every</em>
once = assign chunk IDs to atoms only once, they persist thereafter
nfreq = assign chunk IDs to atoms only once every Nfreq steps (if invoked by <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> which sets Nfreq)
every = assign chunk IDs to atoms whenever invoked
<em>compress</em> value = <em>yes</em> or <em>no</em>
yes = compress chunk IDs to eliminate IDs with no atoms
no = do not compress chunk IDs even if some IDs have no atoms
<em>discard</em> value = <em>yes</em> or <em>no</em> or <em>mixed</em>
yes = discard atoms with out-of-range chunk IDs by assigning a chunk ID = 0
no = keep atoms with out-of-range chunk IDs by assigning a valid chunk ID
mixed = keep or discard such atoms according to spatial binning rule
<em>bound</em> values = x/y/z lo hi
x/y/z = <em>x</em> or <em>y</em> or <em>z</em> to bound sptial bins in this dimension
lo = <em>lower</em> or coordinate value (distance units)
hi = <em>upper</em> or coordinate value (distance units)
<em>pbc</em> value = <em>no</em> or <em>yes</em>
yes = use periodic distance for bin/sphere and bin/cylinder styles
<em>units</em> value = <em>box</em> or <em>lattice</em> or <em>reduced</em>
<p>Define a computation that calculates an integer chunk ID from 1 to
Nchunk for each atom in the group. Values of chunk IDs are determined
by the <em>style</em> of chunk, which can be based on atom type or molecule
ID or spatial binning or a per-atom property or value calculated by
another <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 <a class="reference internal" href="variable.html"><span class="doc">atom-style variable</span></a>. Per-atom chunk IDs can be used by other
computes with “chunk” in their style name, 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>. Or they can be used by the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> command to sum and time average a
variety of per-atom properties over the atoms in each chunk. Or they
can simply be accessed by any command that uses per-atom values from a
compute as input, as discussed in <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section_howto 15</span></a>.</p>
<p>See <a class="reference internal" href="Section_howto.html#howto-23"><span class="std std-ref">Section_howto 23</span></a> for an overview of
how this compute can be used with a variety of other commands to
tabulate properties of a simulation. The howto section gives several
examples of input script commands that can be used to calculate
interesting properties.</p>
<p>Conceptually it is important to realize that this compute does two
simple things. First, it sets the value of <em>Nchunk</em> = the number of
chunks, which can be a constant value or change over time. Second, it
assigns each atom to a chunk via a chunk ID. Chunk IDs range from 1
to <em>Nchunk</em> inclusive; some chunks may have no atoms assigned to them.
Atoms that do not belong to any chunk are assigned a value of 0. Note
that the two operations are not always performed together. For
example, spatial bins can be setup once (which sets <em>Nchunk</em>), and
atoms assigned to those bins many times thereafter (setting their
chunk IDs).</p>
<p>All other commands in LAMMPS that use chunk IDs assume there are
<em>Nchunk</em> number of chunks, and that every atom is assigned to one of
those chunks, or not assigned to any chunk.</p>
<p>There are many options for specifying for how and when <em>Nchunk</em> is
calculated, and how and when chunk IDs are assigned to atoms. The
details depend on the chunk <em>style</em> and its <em>args</em>, as well as
optional keyword settings. They can also depend on whether a <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> command is using this compute, since
that command requires <em>Nchunk</em> to remain static across windows of
timesteps it specifies, while it accumulates per-chunk averages.</p>
<p>The details are described below.</p>
<p>The different chunk styles operate as follows. For each style, how it
calculates <em>Nchunk</em> and assigns chunk IDs to atoms is explained. Note
that using the optional keywords can change both of those actions, as
described further below where the keywords are discussed.</p>
<hr class="docutils" />
<p>The <em>binning</em> styles perform a spatial binning of atoms, and assign an
atom the chunk ID corresponding to the bin number it is in. <em>Nchunk</em>
is set to the number of bins, which can change if the simulation box
size changes.</p>
<p>The <em>bin/1d</em>, <em>bin/2d</em>, and <em>bin/3d</em> styles define bins as 1d layers
(slabs), 2d pencils, or 3d boxes. The <em>dim</em>, <em>origin</em>, and <em>delta</em>
settings are specified 1, 2, or 3 times. For 2d or 3d bins, there is
no restriction on specifying dim = x before dim = y or z, or dim = y
before dim = z. Bins in a particular <em>dim</em> have a bin size in that
dimension given by <em>delta</em>. In each dimension, bins are defined
relative to a specified <em>origin</em>, which may be the lower/upper edge of
the simulation box (in that dimension), or its center point, or a
specified coordinate value. Starting at the origin, sufficient bins
are created in both directions to completely span the simulation box
or the bounds specified by the optional <em>bounds</em> keyword.</p>
<p>For orthogonal simulation boxes, the bins are layers, pencils, or
boxes aligned with the xyz coordinate axes. For triclinic
(non-orthogonal) simulation boxes, the bin faces are parallel to the
tilted faces of the simulation box. See <a class="reference internal" href="Section_howto.html#howto-12"><span class="std std-ref">this section</span></a> of the manual for a discussion of
the geometry of triclinic boxes in LAMMPS. As described there, a
tilted simulation box has edge vectors a,b,c. In that nomenclature,
bins in the x dimension have faces with normals in the “b” cross “c”
direction. Bins in y have faces normal to the “a” cross “c”
direction. And bins in z have faces normal to the “a” cross “b”
direction. Note that in order to define the size and position of
these bins in an unambiguous fashion, the <em>units</em> option must be set
to <em>reduced</em> when using a triclinic simulation box, as noted below.</p>
<p>The meaning of <em>origin</em> and <em>delta</em> for triclinic boxes is as follows.
Consider a triclinic box with bins that are 1d layers or slabs in the
x dimension. No matter how the box is tilted, an <em>origin</em> of 0.0
means start layers at the lower “b” cross “c” plane of the simulation
box and an <em>origin</em> of 1.0 means to start layers at the upper “b”
cross “c” face of the box. A <em>delta</em> value of 0.1 in <em>reduced</em> units
means there will be 10 layers from 0.0 to 1.0, regardless of the
current size or shape of the simulation box.</p>
<p>The <em>bin/sphere</em> style defines a set of spherical shell bins around
the origin (<em>xorig</em>,<em>yorig</em>,<em>zorig</em>), using <em>nsbin</em> bins with radii
equally spaced between <em>srmin</em> and <em>srmax</em>. This is effectively a 1d
vector of bins. For example, if <em>srmin</em> = 1.0 and <em>srmax</em> = 10.0 and
<em>nsbin</em> = 9, then the first bin spans 1.0 < r < 2.0, and the last bin
spans 9.0 < r 10.0. The geometry of the bins is the same whether the
simulation box is orthogonal or triclinic; i.e. the spherical shells
are not tilted or scaled differently in different dimensions to
transform them into ellipsoidal shells.</p>
<p>The <em>bin/cylinder</em> style defines bins for a cylinder oriented along
the axis <em>dim</em> with the axis coordinates in the other two radial
dimensions at (<em>c1</em>,<em>c2</em>). For dim = x, c1/c2 = y/z; for dim = y,
c1/c2 = x/z; for dim = z, c1/c2 = x/y. This is effectively a 2d array
of bins. The first dimension is along the cylinder axis, the second
dimension is radially outward from the cylinder axis. The bin size
and positions along the cylinder axis are specified by the <em>origin</em>
and <em>delta</em> values, the same as for the <em>bin/1d</em>, <em>bin/2d</em>, and
<em>bin/3d</em> styles. There are <em>ncbin</em> concentric circle bins in the
radial direction from the cylinder axis with radii equally spaced
between <em>crmin</em> and <em>crmax</em>. For example, if <em>crmin</em> = 1.0 and
<em>crmax</em> = 10.0 and <em>ncbin</em> = 9, then the first bin spans 1.0 < r <
2.0, and the last bin spans 9.0 < r 10.0. The geometry of the bins in
the radial dimensions is the same whether the simulation box is
orthogonal or triclinic; i.e. the concetric circles are not tilted or
scaled differently in the two different dimensions to transform them
into ellipses.</p>
<p>The created bins (and hence the chunk IDs) are numbered consecutively
from 1 to the number of bins = <em>Nchunk</em>. For <em>bin2d</em> and <em>bin3d</em>, the
numbering varies most rapidly in the first dimension (which could be
x, y, or z), next rapidly in the 2nd dimension, and most slowly in the
3rd dimension. For <em>bin/sphere</em>, the bin with smallest radii is chunk
1 and the bni with largest radii is chunk Nchunk = <em>ncbin</em>. For
<em>bin/cylinder</em>, the numbering varies most rapidly in the dimension
along the cylinder axis and most slowly in the radial direction.</p>
<p>Each time this compute is invoked, each atom is mapped to a bin based
on its current position. Note that between reneighboring timesteps,
atoms can move outside the current simulation box. If the box is
periodic (in that dimension) the atom is remapping into the periodic
box for purposes of binning. If the box in not periodic, the atom may
have moved outside the bounds of all bins. If an atom is not inside
any bin, the <em>discard</em> keyword is used to determine how a chunk ID is
assigned to the atom.</p>
<hr class="docutils" />
<p>The <em>type</em> style uses the atom type as the chunk ID. <em>Nchunk</em> is set
to the number of atom types defined for the simulation, e.g. via the
<p>The <em>molecule</em> style uses the molecule ID of each atom as its chunk
ID. <em>Nchunk</em> is set to the largest chunk ID. Note that this excludes
molecule IDs for atoms which are not in the specified group or
optional region.</p>
<p>There is no requirement that all atoms in a particular molecule are
assigned the same chunk ID (zero or non-zero), though you probably
want that to be the case, if you wish to compute a per-molecule
property. LAMMPS will issue a warning if that is not the case, but
only the first time that <em>Nchunk</em> is calculated.</p>
<p>Note that atoms with a molecule ID = 0, which may be non-molecular
solvent atoms, have an out-of-range chunk ID. These atoms are
discarded (not assigned to any chunk) or assigned to <em>Nchunk</em>,
depending on the value of the <em>discard</em> keyword.</p>
<hr class="docutils" />
<p>The <em>compute/fix/variable</em> styles set the chunk ID of each atom based
on a quantity calculated and stored by a compute, fix, or variable.
In each case, it must be a per-atom quantity. In each case the
referenced floating point values are converted to an integer chunk ID
as follows. The floating point value is truncated (rounded down) to
an integer value. If the integer value is <= 0, then a chunk ID of 0
is assigned to the atom. If the integer value is > 0, it becomes the
chunk ID to the atom. <em>Nchunk</em> is set to the largest chunk ID. Note
that this excludes atoms which are not in the specified group or
optional region.</p>
-<p>If the style begins with “<a href="#id1"><span class="problematic" id="id2">c_</span></a>”, a compute ID must follow which has been
+<p>If the style 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>.</p>
-<p>If the style begins with “<a href="#id3"><span class="problematic" id="id4">f_</span></a>”, a fix ID must follow which has been
+<p>If the style 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 the
timestep on which this compute accesses the fix, 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>.</p>
-<p>If a value begins with “<a href="#id5"><span class="problematic" id="id6">v_</span></a>”, a variable name for an <em>atom</em> or
+<p>If a value begins with “v_”, a variable name for an <em>atom</em> or
<em>atomfile</em> style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> 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
treat as a chunk ID.</p>
<p>Normally, <em>Nchunk</em> = the number of chunks, is re-calculated every time
this fix is invoked, though the value may or may not change. As
explained below, the <em>nchunk</em> keyword can be set to <em>once</em> which means
<em>Nchunk</em> will never change.</p>
<p>If a <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> command uses this compute, it
can also turn off the re-calculation of <em>Nchunk</em> for one or more
windows of timesteps. The extent of the windows, during which Nchunk
is held constant, are determined by the <em>Nevery</em>, <em>Nrepeat</em>, <em>Nfreq</em>
values and the <em>ave</em> keyword setting that are used by the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> command.</p>
<p>Specifically, if <em>ave</em> = <em>one</em>, then for each span of <em>Nfreq</em>
timesteps, <em>Nchunk</em> is held constant between the first timestep when
averaging is done (within the Nfreq-length window), and the last
timestep when averaging is done (multiple of Nfreq). If <em>ave</em> =
<em>running</em> or <em>window</em>, then <em>Nchunk</em> is held constant forever,
starting on the first timestep when the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> command invokes this compute.</p>
<p>Note that multiple <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> commands can use
the same compute chunk/atom compute. However, the time windows they
induce for holding <em>Nchunk</em> constant must be identical, else an error
will be generated.</p>
<p>The various optional keywords operate as follows. Note that some of
them function differently or are ignored by different chunk styles.
Some of them also have different default values, depending on
the chunk style, as listed below.</p>
<p>The <em>region</em> keyword applies to all chunk styles. If used, an atom
must be in both the specified group and the specified geometric
<a class="reference internal" href="region.html"><span class="doc">region</span></a> to be assigned to a chunk.</p>
<hr class="docutils" />
<p>The <em>nchunk</em> keyword applies to all chunk styles. It specifies how
often <em>Nchunk</em> is recalculated, which in turn can affect the chunk IDs
assigned to individual atoms.</p>
<p>If <em>nchunk</em> is set to <em>once</em>, then <em>Nchunk</em> is only calculated once,
the first time this compute is invoked. If <em>nchunk</em> is set to
<em>every</em>, then <em>Nchunk</em> is re-calculated every time the compute is
invoked. Note that, as described above, the use of this compute
by the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> command can override
the <em>every</em> setting.</p>
<p>The default values for <em>nchunk</em> are listed below and depend on the
chunk style and other system and keyword settings. They attempt to
represent typical use cases for the various chunk styles. The
<em>nchunk</em> value can always be set explicitly if desired.</p>
<hr class="docutils" />
<p>The <em>limit</em> keyword can be used to limit the calculated value of
<em>Nchunk</em> = the number of chunks. The limit is applied each time
<em>Nchunk</em> is calculated, which also limits the chunk IDs assigned to
any atom. The <em>limit</em> keyword is used by all chunk styles except the
<em>binning</em> styles, which ignore it. This is because the number of bins
can be tailored using the <em>bound</em> keyword (described below) which
effectively limits the size of <em>Nchunk</em>.</p>
<p>If <em>limit</em> is set to <em>Nc</em> = 0, then no limit is imposed on <em>Nchunk</em>,
though the <em>compress</em> keyword can still be used to reduce <em>Nchunk</em>, as
described below.</p>
<p>If <em>Nc</em> > 0, then the effect of the <em>limit</em> keyword depends on whether
the <em>compress</em> keyword is also used with a setting of <em>yes</em>, and
whether the <em>compress</em> keyword is specified before the <em>limit</em> keyword
or after.</p>
<p>In all cases, <em>Nchunk</em> is first calculated in the usual way for each
chunk style, as described above.</p>
<p>First, here is what occurs if <em>compress yes</em> is not set. If <em>limit</em>
is set to <em>Nc max</em>, then <em>Nchunk</em> is reset to the smaller of <em>Nchunk</em>
and <em>Nc</em>. If <em>limit</em> is set to <em>Nc exact</em>, then <em>Nchunk</em> is reset to
<em>Nc</em>, whether the original <em>Nchunk</em> was larger or smaller than <em>Nc</em>.
If <em>Nchunk</em> shrank due to the <em>limit</em> setting, then atom chunk IDs >
<em>Nchunk</em> will be reset to 0 or <em>Nchunk</em>, depending on the setting of
the <em>discard</em> keyword. If <em>Nchunk</em> grew, there will simply be some
chunks with no atoms assigned to them.</p>
<p>If <em>compress yes</em> is set, and the <em>compress</em> keyword comes before the
<em>limit</em> keyword, the compression operation is performed first, as
described below, which resets <em>Nchunk</em>. The <em>limit</em> keyword is then
applied to the new <em>Nchunk</em> value, exactly as described in the
preceeding paragraph. Note that in this case, all atoms will end up
with chunk IDs <= <em>Nc</em>, but their original values (e.g. molecule ID or
compute/fix/variable value) may have been > <em>Nc</em>, because of the
compression operation.</p>
<p>If <em>compress yes</em> is set, and the <em>compress</em> keyword comes after the
<em>limit</em> keyword, then the <em>limit</em> value of <em>Nc</em> is applied first to
the uncompressed value of <em>Nchunk</em>, but only if <em>Nc</em> < <em>Nchunk</em>
(whether <em>Nc max</em> or <em>Nc exact</em> is used). This effectively means all
atoms with chunk IDs > <em>Nc</em> have their chunk IDs reset to 0 or <em>Nc</em>,
depending on the setting of the <em>discard</em> keyword. The compression
operation is then performed, which may shrink <em>Nchunk</em> further. If
the new <em>Nchunk</em> < <em>Nc</em> and <em>limit</em> = <em>Nc exact</em> is specified, then
<em>Nchunk</em> is reset to <em>Nc</em>, which results in extra chunks with no atoms
assigned to them. Note that in this case, all atoms will end up with
chunk IDs <= <em>Nc</em>, and their original values (e.g. molecule ID or
compute/fix/variable value) will also have been <= <em>Nc</em>.</p>
<hr class="docutils" />
<p>The <em>ids</em> keyword applies to all chunk styles. If the setting is
<em>once</em> then the chunk IDs assigned to atoms the first time this
compute is invoked will be permanent, and never be re-computed.</p>
<p>If the setting is <em>nfreq</em> and if a <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a>
command is using this compute, then in each of the <em>Nchunk</em> = constant
time windows (discussed above), the chunk ID’s assigned to atoms on
the first step of the time window will persist until the end of the
time window.</p>
<p>If the setting is <em>every</em>, which is the default, then chunk IDs are
re-calculated on any timestep this compute is invoked.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you want the persistent chunk-IDs calculated by this compute
to be continuous when running from a <a class="reference internal" href="read_restart.html"><span class="doc">restart file</span></a>,
then you should use the same ID for this compute, as in the original
run. This is so that the fix this compute creates to store per-atom
quantities will also have the same ID, and thus be initialized
correctly with chunk IDs from the restart file.</p>
</div>
<hr class="docutils" />
<p>The <em>compress</em> keyword applies to all chunk styles and affects how
<em>Nchunk</em> is calculated, which in turn affects the chunk IDs assigned
to each atom. It is useful for converting a “sparse” set of chunk IDs
(with many IDs that have no atoms assigned to them), into a “dense”
set of IDs, where every chunk has one or more atoms assigned to it.</p>
<p>Two possible use cases are as follows. If a large simulation box is
mostly empty space, then the <em>binning</em> style may produce many bins
with no atoms. If <em>compress</em> is set to <em>yes</em>, only bins with atoms
will be contribute to <em>Nchunk</em>. Likewise, the <em>molecule</em> or
<em>compute/fix/variable</em> styles may produce large <em>Nchunk</em> values. For
example, the <a class="reference internal" href="compute_cluster_atom.html"><span class="doc">compute cluster/atom</span></a> command
assigns every atom an atom ID for one of the atoms it is clustered
with. For a million-atom system with 5 clusters, there would only be
5 unique chunk IDs, but the largest chunk ID might be 1 million,
resulting in <em>Nchunk</em> = 1 million. If <em>compress</em> is set to <em>yes</em>,
<em>Nchunk</em> will be reset to 5.</p>
<p>If <em>compress</em> is set to <em>no</em>, which is the default, no compression is
done. If it is set to <em>yes</em>, all chunk IDs with no atoms are removed
from the list of chunk IDs, and the list is sorted. The remaining
chunk IDs are renumbered from 1 to <em>Nchunk</em> where <em>Nchunk</em> is the new
length of the list. The chunk IDs assigned to each atom reflect
the new renumbering from 1 to <em>Nchunk</em>.</p>
<p>The original chunk IDs (before renumbering) can be accessed by the
<a class="reference internal" href="compute_property_chunk.html"><span class="doc">compute property/chunk</span></a> command and its
<em>id</em> keyword, or by the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> command
which outputs the original IDs as one of the columns in its global
output array. For example, using the “compute cluster/atom” command
discussed above, the original 5 unique chunk IDs might be atom IDs
(27,4982,58374,857838,1000000). After compresion, these will be
renumbered to (1,2,3,4,5). The original values (27,...,1000000) can
be output to a file by the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> command,
or by using the <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a> command in
conjunction with the <a class="reference internal" href="compute_property_chunk.html"><span class="doc">compute property/chunk</span></a> command.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The compression operation requires global communication across
all processors to share their chunk ID values. It can require large
memory on every processor to store them, even after they are
compressed, if there are are a large number of unique chunk IDs with
atoms assigned to them. It uses a STL map to find unique chunk IDs
and store them in sorted order. Each time an atom is assigned a
compressed chunk ID, it must access the STL map. All of this means
that compression can be expensive, both in memory and CPU time. The
use of the <em>limit</em> keyword in conjunction with the <em>compress</em> keyword
can affect these costs, depending on which keyword is used first. So
use this option with care.</p>
</div>
<hr class="docutils" />
<p>The <em>discard</em> keyword applies to all chunk styles. It affects what
chunk IDs are assigned to atoms that do not match one of the valid
chunk IDs from 1 to <em>Nchunk</em>. Note that it does not apply to atoms
that are not in the specified group or optionally specified region.
Those atoms are always assigned a chunk ID = 0.</p>
<p>If the calculated chunk ID for an atom is not within the range 1 to
<em>Nchunk</em> then it is a “discard” atom. Note that <em>Nchunk</em> may have
been shrunk by the <em>limit</em> keyword. Or the <em>compress</em> keyword may
have eliminated chunk IDs that were valid before the compression took
place, and are now not in the compressed list. Also note that for the
<em>molecule</em> chunk style, if new molecules are added to the system,
their chunk IDs may exceed a previously calculated <em>Nchunk</em>.
Likewise, evaluation of a compute/fix/variable on a later timestep may
return chunk IDs that are invalid for the previously calculated
<em>Nchunk</em>.</p>
<p>All the chunk styles except the <em>binning</em> styles, must use <em>discard</em>
set to either <em>yes</em> or <em>no</em>. If <em>discard</em> is set to <em>yes</em>, which is
the default, then every “discard” atom has its chunk ID set to 0. If
<em>discard</em> is set to <em>no</em>, every “discard” atom has its chunk ID set to
<em>Nchunk</em>. I.e. it becomes part of the last chunk.</p>
<p>The <em>binning</em> styles use the <em>discard</em> keyword to decide whether to
discard atoms outside the spatial domain covered by bins, or to assign
them to the bin they are nearest to.</p>
<p>For the <em>bin/1d</em>, <em>bin/2d</em>, <em>bin/3d</em> styles the details are as
follows. If <em>discard</em> is set to <em>yes</em>, an out-of-domain atom will
have its chunk ID set to 0. If <em>discard</em> is set to <em>no</em>, the atom
will have its chunk ID set to the first or last bin in that dimension.
If <em>discard</em> is set to <em>mixed</em>, which is the default, it will only
have its chunk ID set to the first or last bin if bins extend to the
simulation box boundary in that dimension. This is the case if the
<em>bound</em> keyword settings are <em>lower</em> and <em>upper</em>, which is the
default. If the <em>bound</em> keyword settings are numeric values, then the
atom will have its chunk ID set to 0 if it is outside the bounds of
any bin. Note that in this case, it is possible that the first or
last bin extends beyond the numeric <em>bounds</em> settings, depending on
the specified <em>origin</em>. If this is the case, the chunk ID of the atom
is only set to 0 if it is outside the first or last bin, not if it is
simply outside the numeric <em>bounds</em> setting.</p>
<p>For the <em>bin/sphere</em> style the details are as follows. If <em>discard</em>
is set to <em>yes</em>, an out-of-domain atom will have its chunk ID set to
0. If <em>discard</em> is set to <em>no</em> or <em>mixed</em>, the atom will have its
chunk ID set to the first or last bin, i.e. the innermost or outermost
spherical shell. If the distance of the atom from the origin is less
than <em>rmin</em>, it will be assigned to the first bin. If the distance of
the atom from the origin is greater than <em>rmax</em>, it will be assigned
to the last bin.</p>
<p>For the <em>bin/cylinder</em> style the details are as follows. If <em>discard</em>
is set to <em>yes</em>, an out-of-domain atom will have its chunk ID set to
0. If <em>discard</em> is set to <em>no</em>, the atom will have its chunk ID set
to the first or last bin in both the radial and axis dimensions. If
<em>discard</em> is set to <em>mixed</em>, which is the default, the the radial
dimension is treated the same as for <em>discard</em> = no. But for the axis
dimensinon, it will only have its chunk ID set to the first or last
bin if bins extend to the simulation box boundary in the axis
dimension. This is the case if the <em>bound</em> keyword settings are
<em>lower</em> and <em>upper</em>, which is the default. If the <em>bound</em> keyword
settings are numeric values, then the atom will have its chunk ID set
to 0 if it is outside the bounds of any bin. Note that in this case,
it is possible that the first or last bin extends beyond the numeric
<em>bounds</em> settings, depending on the specified <em>origin</em>. If this is
the case, the chunk ID of the atom is only set to 0 if it is outside
the first or last bin, not if it is simply outside the numeric
<em>bounds</em> setting.</p>
<p>If <em>discard</em> is set to <em>no</em> or <em>mixed</em>, the atom will have its
chunk ID set to the first or last bin, i.e. the innermost or outermost
spherical shell. If the distance of the atom from the origin is less
than <em>rmin</em>, it will be assigned to the first bin. If the distance of
the atom from the origin is greater than <em>rmax</em>, it will be assigned
to the last bin.</p>
<hr class="docutils" />
<p>The <em>bound</em> keyword only applies to the <em>bin/1d</em>, <em>bin/2d</em>, <em>bin/3d</em>
styles and to the axis dimension of the <em>bin/cylinder</em> style;
otherwise it is ignored. It can be used one or more times to limit
the extent of bin coverage in a specified dimension, i.e. to only bin
a portion of the box. If the <em>lo</em> setting is <em>lower</em> or the <em>hi</em>
setting is <em>upper</em>, the bin extent in that direction extends to the
box boundary. If a numeric value is used for <em>lo</em> and/or <em>hi</em>, then
the bin extent in the <em>lo</em> or <em>hi</em> direction extends only to that
value, which is assumed to be inside (or at least near) the simulation
box boundaries, though LAMMPS does not check for this. Note that
using the <em>bound</em> keyword typically reduces the total number of bins
and thus the number of chunks <em>Nchunk</em>.</p>
<p>The <em>pbc</em> keyword only applies to the <em>bin/sphere</em> and <em>bin/cylinder</em>
styles. If set to <em>yes</em>, the distance an atom is from the sphere
origin or cylinder axis is calculated in a minimum image sense with
respect to periodic dimensions, when determining which bin the atom is
in. I.e. if x is a periodic dimension and the distance between the
atom and the sphere center in the x dimension is greater than 0.5 *
simulation box length in x, then a box length is subtracted to give a
distance < 0.5 * simulation box length. This allosws the sphere or
cylinder center to be near a box edge, and atoms on the other side of
the periodic box will still be close to the center point/axis. Note
that with a setting of <em>yes</em>, the outer sphere or cylinder radius must
also be <= 0.5 * simulation box length in any periodic dimension
except for the cylinder axis dimension, or an error is generated.</p>
<p>The <em>units</em> keyword only applies to the <em>binning</em> styles; otherwise it
is ignored. For the <em>bin/1d</em>, <em>bin/2d</em>, <em>bin/3d</em> styles, it
determines the meaning of the distance units used for the bin sizes
<em>delta</em> and for <em>origin</em> and <em>bounds</em> values if they are coordinate
values. For the <em>bin/sphere</em> style it determines the meaning of the
distance units used for <em>xorig</em>,<em>yorig</em>,<em>zorig</em> and the radii <em>srmin</em>
and <em>srmax</em>. For the <em>bin/cylinder</em> style it determines the meaning
of the distance units used for <em>delta</em>,<em>c1</em>,<em>c2</em> and the radii <em>crmin</em>
and <em>crmax</em>.</p>
<p>For orthogonal simulation boxes, any of the 3 options may
be used. For non-orthogonal (triclinic) simulation boxes, only the
<em>reduced</em> option may be used.</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 spacing. A <em>reduced</em> value means normalized
unitless values between 0 and 1, which represent the lower and upper
faces of the simulation box respectively. Thus an <em>origin</em> value of
0.5 means the center of the box in any dimension. A <em>delta</em> value of
0.1 means 10 bins span the box in that dimension.</p>
<p>Note that for the <em>bin/sphere</em> style, the radii <em>srmin</em> and <em>srmax</em> are
scaled by the lattice spacing or reduced value of the <em>x</em> dimension.</p>
<p>Note that for the <em>bin/cylinder</em> style, the radii <em>crmin</em> and <em>crmax</em>
are scaled by the lattice spacing or reduced value of the 1st
dimension perpendicular to the cylinder axis. E.g. y for an x-axis
cylinder, x for a y-axis cylinder, and x for a z-axis cylinder.</p>
<hr class="docutils" />
<p><strong>Output info:</strong></p>
<p>This compute calculates a per-atom vector, which can be accessed by
any command that uses per-atom values from a compute as input. See
<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 are unitless chunk IDs, ranging from 1 to
<em>Nchunk</em> (inclusive) for atoms assigned to chunks, and 0 for atoms not
belonging to a chunk.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>Even if the <em>nchunk</em> keyword is set to <em>once</em>, the chunk IDs assigned
to each atom are not stored in a restart files. This means you cannot
expect those assignments to persist in a restarted simulation.
Instead you must re-specify this command and assign atoms to chunks when
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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 center-of-mass 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 center-of-mass
for each chunk, which 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
center-of-mass 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 =
3 for the x,y,z center-of-mass coordinates of each chunk. These
values can be accessed by any command that uses global array values
from a compute as input. See <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 one or more coordination numbers
for each atom in a group.</p>
<p>A coordination number is defined as the number of neighbor atoms with
specified atom type(s) that are within the specified cutoff distance
from the central atom. Atoms not in the group are included in a
coordination number of atoms in the group.</p>
<p>The <em>typeN</em> keywords allow you to specify which atom types contribute
to each coordination number. One coordination number is computed for
each of the <em>typeN</em> keywords listed. If no <em>typeN</em> keywords are
listed, a single coordination number is calculated, which includes
atoms of all types (same as the “*” format, see below).</p>
<p>The <em>typeN</em> keywords can be specified in one of two ways. An explicit
numeric value can be used, as in the 2nd example above. Or a
wild-card asterisk can be used to specify a range of atom types. This
-takes the form “*” or “<em>n” or “n</em>” or “m*n”. If N = the number of
+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 value of all coordination numbers will be 0.0 for atoms not in the
specified compute group.</p>
<p>The neighbor list needed to compute this quantity is constructed each
time the calculation is performed (i.e. each time a snapshot of atoms
is dumped). Thus it can be inefficient to compute/dump this quantity
too frequently.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you have a bonded system, then the settings of
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command can remove pairwise
interactions between atoms in the same bond, angle, or dihedral. This
is the default setting for the <a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a>
command, and means those pairwise interactions do not appear in the
neighbor list. Because this fix uses the neighbor list, it also means
those pairs will not be included in the coordination count. One way
to get around this, is to write a dump file, and use the
<a class="reference internal" href="rerun.html"><span class="doc">rerun</span></a> command to compute the coordination for snapshots
in the dump file. The rerun script can use a
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command that includes all pairs in
the neighbor list.</p>
</div>
<p><strong>Output info:</strong></p>
<p>If single <em>type1</em> keyword is specified (or if none are specified),
this compute calculates a per-atom vector. If multiple <em>typeN</em>
keywords are specified, this compute calculates a per-atom array, with
N columns. 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>
<p>The per-atom vector or array values will be a number >= 0.0, 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>.
<p>Define a computation that calculates properties of individual dihedral
interactions. The number of datums generated, aggregated across all
processors, equals the number of angles in the system, modified by the
group parameter as explained below.</p>
<p>The value <em>phi</em> is the dihedral angle, as defined in the diagram on
the <a class="reference internal" href="dihedral_style.html"><span class="doc">dihedral_style</span></a> doc page.</p>
<p>The local data stored by this command is generated by looping over all
the atoms owned on a processor and their dihedrals. A dihedral will
only be included if all 4 atoms in the dihedral are in the specified
compute group.</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, dihedral 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>
+compute 1 all property/local dtype datom1 datom2 datom3 datom4
+compute 2 all dihedral/local phi
+dump 1 all local 1000 tmp.dump index c_1[1] c_1[2] c_1[3] c_1[4] c_1[5] c_2[1]
+</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 dihedrals. 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>phi</em> will be in degrees.</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 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>The local data stored by this command is generated by looping over all
the atoms owned on a processor and their impropers. An improper will
only be included if all 4 atoms in the improper are in the specified
compute group.</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, improper 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>
+compute 1 all property/local itype iatom1 iatom2 iatom3 iatom4
+compute 2 all improper/local chi
+dump 1 all local 1000 tmp.dump index c_1[1] c_1[2] c_1[3] c_1[4] c_1[5] c_2[1]
+</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 impropers. 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>chi</em> will be in degrees.</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 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>See <a class="reference external" href="USER/sph/SPH_LAMMPS_userguide.pdf">this PDF guide</a> to using SPH in
LAMMPS.</p>
<p>The value of the internal energy will be 0.0 for atoms not in the
specified compute group.</p>
<p><strong>Output info:</strong></p>
<p>This compute calculates a per-atom vector, which can be accessed by
any command that uses per-atom values from a compute as input. See
<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 temperature <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-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>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>.
<p>Define a computation that calculates the mean-squared displacement
(MSD) 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>Four quantites are calculated by this compute for each chunk. The
first 3 quantities are the squared dx,dy,dz displacements of the
center-of-mass. The 4th component is the total squared displacement,
i.e. (dx*dx + dy*dy + dz*dz) of the center-of-mass. These
calculations include 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>
<p>The slope of the mean-squared displacement (MSD) versus time is
proportional to the diffusion coefficient of the diffusing chunks.</p>
<p>The displacement of the center-of-mass of the chunk is from its
original center-of-mass position, calculated on the timestep this
compute command was first invoked.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The number of chunks <em>Nchunk</em> calculated by the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command must remain constant each
time this compute is invoked, so that the displacement for each chunk
from its original position can be computed consistently. If <em>Nchunk</em>
does not remain constant, an error will be generated. If needed, you
can enforce a constant <em>Nchunk</em> by using the <em>nchunk once</em> or <em>ids
once</em> options when specifying the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">This compute stores the original position (of the
center-of-mass) of each chunk. When a displacement is calculated on a
later timestep, it is assumed that the same atoms are assigned to the
same chunk ID. However LAMMPS has no simple way to insure this is the
case, though you can use the <em>ids once</em> option when specifying the
<a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command. Note that if
this is not the case, the MSD calculation does not have a sensible
meaning.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The initial coordinates of the atoms in each chunk are stored 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>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you want the quantities calculated by this compute to be
continuous when running from a <a class="reference internal" href="read_restart.html"><span class="doc">restart file</span></a>, then
you should use the same ID for this compute, as in the original run.
This is so that the fix this compute creates to store per-chunk
quantities will also have the same ID, and thus be initialized
correctly with chunk reference positions from the restart file.</p>
</div>
<p>The simplest way to output the results of the compute com/msd
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 dx,dy,dz and the total displacement. 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">this section</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 angular velocity (omega) of
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 3 components of the angular velocity
vector for each chunk, via the formula L = Iw where L is the angular
momentum vector of the chunk, I is its moment of inertia tensor, and w
is omega = angular velocity of the chunk. 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 angular
velocity 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 omega/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 =
3 for the 3 xyz components of the angular velocity for 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
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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 value <em>dist</em> is the distance bewteen the pair of atoms.</p>
<p>The value <em>eng</em> is the interaction energy for the pair of atoms.</p>
<p>The value <em>force</em> is the force acting between the pair of atoms, which
is positive for a repulsive force and negative for an attractive
force. The values <em>fx</em>, <em>fy</em>, and <em>fz</em> are the xyz components of
<em>force</em> on atom I.</p>
<p>A pair style may define additional pairwise quantities which can be
accessed as <em>p1</em> to <em>pN</em>, where N is defined by the pair style. Most
pair styles do not define any additional quantities, so N = 0. An
example of ones that do are the <a class="reference internal" href="pair_gran.html"><span class="doc">granular pair styles</span></a>
which calculate the tangential force between two particles and return
its components and magnitude acting on atom I for N = 1,2,3,4. See
individual pair styles for detils.</p>
<p>The value <em>dist</em> will be in distance <a class="reference internal" href="units.html"><span class="doc">units</span></a>. The value
<em>eng</em> will be in energy <a class="reference internal" href="units.html"><span class="doc">units</span></a>. The values <em>force</em>, <em>fx</em>,
<em>fy</em>, and <em>fz</em> will be in force <a class="reference internal" href="units.html"><span class="doc">units</span></a>. The values <em>pN</em>
will be in whatever units the pair style defines.</p>
<p>The optional <em>cutoff</em> keyword determines how the force cutoff distance
for an interaction is determined. For the default setting of <em>type</em>,
the pairwise cutoff defined by the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a>
command for the types of the two atoms is used. For the <em>radius</em>
setting, the sum of the radii of the two particles is used as a
cutoff. For example, this is appropriate for granular particles which
only interact when they are overlapping, as computed by <a class="reference external" href="pair_gran.txt">granular pair styles</a>.</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, pair 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_2[1] c_2[2] c_2[3]
+</pre>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For pairs, if two atoms I,J are involved in 1-2, 1-3, 1-4
interactions within the molecular topology, their pairwise interaction
may be turned off, and thus they may not appear in the neighbor list,
and will not be part of the local data created by this command. More
specifically, this will be true of I,J pairs with a weighting factor
of 0.0; pairs with a non-zero weighting factor are included. The
weighting factors for 1-2, 1-3, and 1-4 pairwise interactions are set
by the <a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command. An exception is if
long-range Coulombics are being computed via the
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command, then atom pairs with
weighting factors of zero are still included in the neighbor list, so
that a portion of the long-range interaction contribution can be
computed in the pair style. Hence in that case, those atom pairs will
be part of the local data created by this command.</p>
</div>
<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 pairs. 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>, <em>fx</em>, <em>fy</em>, and <em>fz</em> will be in force <a class="reference internal" href="units.html"><span class="doc">units</span></a>.
The outpur for <em>pN</em> will be in whatever units the pair style defines.</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 potential energy of the
entire system of atoms. The specified group must be “all”. See the
<a class="reference internal" href="compute_pe_atom.html"><span class="doc">compute pe/atom</span></a> command if you want per-atom
energies. 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>The energy is calculated by the various pair, bond, etc potentials
defined for the simulation. If no extra keywords are listed, then the
potential energy is the sum of pair, bond, angle, dihedral, improper,
kspace (long-range), and fix energy. I.e. it is as if all the
keywords were listed. If any extra keywords are listed, then only
those components are summed to compute the potential energy.</p>
<p>The Kspace contribution requires 1 extra FFT each timestep the energy
is calculated, if using the PPPM solver via the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style pppm</span></a> command. Thus it can increase the cost of the
PPPM calculation if it is needed on a large fraction of the simulation
timesteps.</p>
<p>Various fixes can contribute to the total 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
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 potential energy to this command.</p>
</div>
<p>A compute of this style with the ID of “thermo_pe” is created when
LAMMPS starts up, as if this command were in the input script:</p>
<p>See the “thermo_style” command for more details.</p>
<hr class="docutils" />
<p><strong>Output info:</strong></p>
<p>This compute calculates a global scalar (the potential energy). 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>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>If an input value begins with “<a href="#id1"><span class="problematic" id="id2">c_</span></a>”, a compute ID must follow which has
+<p>If an input value begins with “c_”, a compute ID must follow which has
been previously defined in the input script and which generates a
global vector or array. 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>.</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 and which generates a global
vector or array. 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 slice 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>.</p>
-<p>If an input value begins with “<a href="#id5"><span class="problematic" id="id6">v_</span></a>”, a variable name must follow which
+<p>If an input value begins with “v_”, a variable name must follow which
has been previously defined in the input script. Only vector-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>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 slice.</p>
<p>If a single input is specified this compute produces a global vector,
even if the length of the vector is 1. If multiple inputs are
specified, then a global array of values is produced, with the number
of columns equal to the number of inputs specified.</p>
<hr class="docutils" />
<p><strong>Output info:</strong></p>
<p>This compute calculates a global vector if a single input value is
specified or a global array with N columns where N is the number of
inputs. The length of the vector or the number of rows in the array
is equal to the number of values extracted from each input vector.
These values can be used by any command that uses global vector or
array 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 calculated by this compute are simply
copies of values generated by computes or fixes or variables that are
input vectors to this compute. If there is a single input vector of
intensive and/or extensive values, then each value in the vector of
values calculated by this compute will be “intensive” or “extensive”,
depending on the corresponding input value. If there are multiple
input vectors, and all the values in them are intensive, then the
array values calculated by this compute are “intensive”. If there are
multiple input vectors, and any value in them is extensive, then the
array values calculated by this compute are “extensive”. Values
produced by a variable are treated as intensive.</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
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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 returns the coordinates of the vertices
-corresponding to the triangle-elements of a mesh created by the <a href="#id4"><span class="problematic" id="id5">`fix smd/wall_surface <ls_>`_</span></a>.</p>
+corresponding to the triangle-elements of a mesh created by the <a href="#id4"><span class="problematic" id="id5">`fix smd/wall\_surface <ls_>`_</span></a>.</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>
<p><strong>Output info:</strong></p>
<p>This compute returns a per-particle vector of vectors, which can be
accessed by any command that uses per-particle values from a compute as
<p>The per-particle vector has nine entries, (x1/y1/z1), (x2/y2/z2), and
(x3/y3/z3) corresponding to the first, second, and third vertex of
each triangle.</p>
<p>It is only meaningful to use this compute for a group of particles
-which is created via the <a href="#id6"><span class="problematic" id="id7">`fix smd/wall_surface <ls_>`_</span></a> command.</p>
+which is created via the <a href="#id6"><span class="problematic" id="id7">`fix smd/wall\_surface <ls_>`_</span></a> command.</p>
<p>The output of this compute can be used with the dump2vtk_tris tool to
generate a VTK representation of the smd/wall_surace mesh for
visualization purposes.</p>
<p>The values will be given in <a class="reference internal" href="units.html"><span class="doc">units</span></a> of distance.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This compute 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.</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>See the “thermo_style” command for more details.</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>
<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 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. 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 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>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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 group of
atoms that are also in chunks, after optionally subtracting out the
center-of-mass velocity of each chunk. By specifying optional values,
it can also calulate the per-chunk temperature or energies of the
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>The temperature is calculated by the formula KE = DOF/2 k T, where KE =
total kinetic energy of all atoms assigned to chunks (sum of 1/2 m
v^2), DOF = the total number of degrees of freedom for those atoms, k
= Boltzmann constant, and T = temperature.</p>
<p>The DOF is calculated as N*adof + Nchunk*cdof, where N = number of
atoms contributing to the KE, 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>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.</p>
<p>Note that the number of atoms contributing to the temperature is
calculated each time the temperature is evaluated since it is assumed
the atoms may be dynamically assigned to chunks. Thus there is no
need to use the <em>dynamic</em> option of the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command for this compute style.</p>
<p>If any optional values are specified, then per-chunk quantities are
also calculated and stored in a global array, as described below.</p>
<p>The <em>temp</em> value calculates the temperature 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 in this case 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>The <em>kecom</em> value calculates the kinetic energy of each chunk as if
all its atoms were moving with the velocity of the center-of-mass of
the chunk.</p>
<p>The <em>internal</em> value calculates the internal kinetic energy of each
chunk. The interal KE is summed over the atoms in the chunk using an
internal “thermal” velocity for each atom, which is its velocity minus
the center-of-mass velocity of the chunk.</p>
<hr class="docutils" />
<p>Note that currently the global and per-chunk temperatures calculated
by this compute only include 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>Note that the per-chunk temperature calulated by this compute and the
<a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk temp</span></a> command can be different.
This compute calculates the temperature for each chunk for a single
snapshot. Fix ave/chunk 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. This compute allows
the center-of-mass velocity of each chunk to be subtracted before
calculating the temperature; fix ave/chunk does not.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Only atoms in the specified group contribute to the calculations
performed by this compute. 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>
<p>The simplest way to output the per-chunk results of the compute
temp/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> command, for example:</p>
<p>The keyword/value option pairs are used in the following ways.</p>
<p>The <em>com</em> keyword can be used with a value of <em>yes</em> to subtract the
velocity of the center-of-mass for each chunk from the velocity of the
atoms in that chunk, before calculating either the global or per-chunk
temperature. This can be useful if the atoms are streaming or
otherwise moving collectively, and you wish to calculate only the
thermal temperature.</p>
<p>For the <em>bias</em> keyword, <em>bias-ID</em> refers to the ID of a temperature
compute that removes a “bias” velocity from each atom. This also
allows calculation of the global or per-chunk temperature using only
the thermal temperature of atoms in each chunk after the translational
kinetic energy components have been altered in a prescribed way,
e.g. to remove a velocity profile. It also applies to the calculation
of the other per-chunk values, such as <em>kecom</em> or <em>internal</em>, which
involve the center-of-mass velocity of each chunk, which is calculated
after the velocity bias is removed from each atom. Note that the
temperature compute will apply its bias globally to the entire system,
not on a per-chunk basis.</p>
<p>The <em>adof</em> and <em>cdof</em> keywords define the values used in the degree of
freedom (DOF) formulas used for the global or per-chunk temperature,
as described above. 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>
<hr class="docutils" />
<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. 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>This compute also optionally calculates a global array, if one or more
of the optional values are specified. The 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. The number of
columns is the number of specifed values (1 or more). These values
can be accessed by any command that uses global array values from a
compute as input. Again, 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 “intensive”. The
vector values are “extensive”. The array values are “intensive”.</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>. The array values
will be in temperature <a class="reference internal" href="units.html"><span class="doc">units</span></a> for the <em>temp</em> value, and in
energy <a class="reference internal" href="units.html"><span class="doc">units</span></a> for the <em>kecom</em> and <em>internal</em> values.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The <em>com</em> and <em>bias</em> keywords cannot be used together.</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>Define a computation that calculates the torque on 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 3 components of the torque vector for eqch
chunk, due to the forces on the individual atoms in the chunk around
the center-of-mass of the chunk. 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 torque 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 torque/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 =
3 for the 3 xyz components of the torque for 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
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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 class="last">If you want the quantities calculated by this compute to be
continuous when running from a <a class="reference internal" href="read_restart.html"><span class="doc">restart file</span></a>, then
you should use the same ID for this compute, as in the original run.
This is so that the fix this compute creates to store per-atom
quantities will also have the same ID, and thus be initialized
correctly with time=0 atom velocities from the restart file.</p>
</div>
<p><strong>Output info:</strong></p>
<p>This compute calculates a global vector of length 4, which can be
accessed by indices 1-4 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 are “intensive”. The vector 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 center-of-mass velocity 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 components of the center-of-mass
velocity for each chunk. This is done by summing mass*velocity for
each atom in the chunk and dividing the sum by the total mass of 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>The simplest way to output the results of the compute vcm/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 =
3 for the x,y,z center-of-mass velocity coordinates 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
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>N = # of atom types to use in this simulation</li>
<li>region-ID = ID of region to use as simulation domain</li>
<li>zero or more keyword/value pairs may be appended</li>
<li>keyword = <em>bond/types</em> or <em>angle/types</em> or <em>dihedral/types</em> or <em>improper/types</em> or <em>extra/bond/per/atom</em> or <em>extra/angle/per/atom</em> or <em>extra/dihedral/per/atom</em> or <em>extra/improper/per/atom</em></li>
</ul>
<pre class="literal-block">
<em>bond/types</em> value = # of bond types
<em>angle/types</em> value = # of angle types
<em>dihedral/types</em> value = # of dihedral types
<em>improper/types</em> value = # of improper types
<em>extra/bond/per/atom</em> value = # of bonds per atom
<em>extra/angle/per/atom</em> value = # of angles per atom
<em>extra/dihedral/per/atom</em> value = # of dihedrals per atom
<em>extra/improper/per/atom</em> value = # of impropers per atom
<em>extra/special/per/atom</em> value = # of special neighbors per atom
<p>This command creates a simulation box based on the specified region.
Thus a <a class="reference internal" href="region.html"><span class="doc">region</span></a> command must first be used to define a
geometric domain. It also partitions the simulation box into a
regular 3d grid of rectangular bricks, one per processor, based on the
number of processors being used and the settings of the
<a class="reference internal" href="processors.html"><span class="doc">processors</span></a> command. The partitioning can later be
changed by the <a class="reference internal" href="balance.html"><span class="doc">balance</span></a> or <a class="reference internal" href="fix_balance.html"><span class="doc">fix balance</span></a> commands.</p>
<p>The argument N is the number of atom types that will be used in the
simulation.</p>
<p>If the region is not of style <em>prism</em>, then LAMMPS encloses the region
(block, sphere, etc) with an axis-aligned orthogonal bounding box
which becomes the simulation domain.</p>
<p>If the region is of style <em>prism</em>, LAMMPS creates a non-orthogonal
simulation domain shaped as a parallelepiped with triclinic symmetry.
As defined by the <a class="reference internal" href="region.html"><span class="doc">region prism</span></a> command, 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 parallelipiped.</p>
<p>By default, a <em>prism</em> region used with the create_box command must
have tilt factors (xy,xz,yz) that do not skew the box more than half
the distance of 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. 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 prism region 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>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If the system is non-periodic (in a dimension), then you should
not make the lo/hi box dimensions (as defined in your
<a class="reference internal" href="region.html"><span class="doc">region</span></a> command) radically smaller/larger than the extent
of the atoms you eventually plan to create, e.g. via the
<a class="reference internal" href="create_atoms.html"><span class="doc">create_atoms</span></a> command. For example, if your atoms
extend from 0 to 50, you should not specify the box bounds as -10000
and 10000. This is because as described above, 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 the first time that LAMMPS
shrink-wraps the box around the atoms.</p>
</div>
<hr class="docutils" />
<p>The optional keywords can be used to create a system that allows for
bond (angle, dihedral, improper) interactions, or for molecules with
special 1-2,1-3,1-4 neighbors to be added later. These optional
keywords serve the same purpose as the analogous keywords that can be
used in a data file which are recognized by the
<a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command when it sets up a system.</p>
<p>Note that if these keywords are not used, then the create_box command
creates an atomic (non-molecular) simulation that does not allow bonds
between pairs of atoms to be defined, or a <a class="reference internal" href="bond_style.html"><span class="doc">bond potential</span></a> to be specified, or for molecules with
special neighbors to be added to the system by commands such as
or <a class="reference internal" href="fix_pour.html"><span class="doc">fix pour</span></a>.</p>
<p>As an example, see the examples/deposit/in.deposit.molecule script,
which deposits molecules onto a substrate. Initially there are no
molecules in the system, but they are added later by the <a class="reference internal" href="fix_deposit.html"><span class="doc">fix deposit</span></a> command. The create_box command in the
script uses the bond/types and extra/bond/per/atom keywords to allow
this. If the added molecule contained more than 1 special bond
(allowed by default), an extra/special/per/atom keyword would also
need to be specified.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>An <a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a> and <a class="reference internal" href="region.html"><span class="doc">region</span></a> must have
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>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>Note that it is not necessary to use the dihedral style <em>skip</em> in the
input script, since AngleTorsion (or EndBondTorsion, etc) coefficients
need not be specified at all for dihedral types that are not <em>class2</em>.</p>
<p>A dihedral style of <em>none</em> with no additional coefficients can be used
in place of a dihedral style, either in a input script dihedral_coeff
command or in the data file, if you desire to turn off interactions
for specific dihedral types.</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>
<p>Unlike other dihedral styles, the hybrid dihedral style does not store
dihedral coefficient info for individual sub-styles in a <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Thus when retarting a simulation from a
restart file, you need to re-specify dihedral_coeff 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>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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>.
<p>Using a dihedral style of zero means dihedral forces and energies are
not computed, but the geometry of dihedral quadruplets is still
accessible to other commands.</p>
<p>As an example, the <a class="reference internal" href="compute_dihedral_local.html"><span class="doc">compute dihedral/local</span></a> command can be used to
compute the theta values for the list of quadruplets of dihedral atoms
listed in the data file read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
command. If no dihedral style is defined, this command cannot be
used.</p>
<p>The optional <em>nocoeff</em> flag allows to read data files with a DihedralCoeff
section for any dihedral style. Similarly, any dihedral_coeff commands
will only be checked for the dihedral type number and the rest ignored.</p>
<p>Note that the <a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command must be
used for all dihedral types, though no additional values 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>Displace a group of atoms. This can be used to move atoms a large
distance before beginning a simulation or to randomize atoms initially
on a lattice. For example, in a shear simulation, an initial strain
can be imposed on the system. Or two groups of atoms can be brought
into closer proximity.</p>
<p>The <em>move</em> style displaces the group of atoms by the specified 3d
displacement vector. Any of the 3 quantities defining the vector
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(s) used for the
displacement(s). The scale factor implied by the <em>units</em> keyword will
also be applied to the variable result.</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. Atom-style variables can specify the same formulas as
equal-style variables but can also include per-atom values, such as
atom coordinates or per-atom values read from a file. Note that if
the variable references other <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>
commands, those values must be up-to-date for the current timestep.
See the “Variable Accuracy” section of the <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>
doc page for more details.</p>
<p>The <em>ramp</em> style displaces atoms a variable amount in one dimension
depending on the atom’s coordinate in a (possibly) different
dimension. For example, the second example command displaces atoms in
the x-direction an amount between 0.0 and 5.0 distance units. Each
atom’s displacement depends on the fractional distance its y
coordinate is between 2.0 and 20.5. Atoms with y-coordinates outside
those bounds will be moved the minimum (0.0) or maximum (5.0) amount.</p>
<p>The <em>random</em> style independently moves each atom in the group by a
random displacement, uniformly sampled from a value between -dx and
+dx in the x dimension, and similarly for y and z. Random numbers are
used in such a way that the displacement of a particular atom is the
same, regardless of how many processors are being used.</p>
<p>The <em>rotate</em> style rotates each atom in the group by the angle <em>theta</em>
around a rotation axis <em>R</em> = (Rx,Ry,Rz) that goes thru a point <em>P</em> =
(Px,Py,Pz). 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 positive theta.</p>
<p>If the defined <a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a> assigns an orientation to
each atom (<a class="reference internal" href="atom_style.html"><span class="doc">atom styles</span></a> ellipsoid, line, tri, body),
then that property is also updated appropriately to correspond to the
atom’s rotation.</p>
<p>Distance units for displacements and the origin point of the <em>rotate</em>
style are determined by the setting of <em>box</em> or <em>lattice</em> for the
<em>units</em> keyword. <em>Box</em> means distance units as defined by the
<a class="reference internal" href="units.html"><span class="doc">units</span></a> command - e.g. Angstroms for <em>real</em> units.
<em>Lattice</em> means 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>
<hr class="docutils" />
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Care should be taken not to move atoms on top of other atoms.
After the move, atoms are remapped into the periodic simulation box if
needed, and any shrink-wrap boundary conditions (see the
<a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command) are enforced which may change the
box size. Other than this effect, this command does not change the
size or shape of the simulation box. See the
<a class="reference internal" href="change_box.html"><span class="doc">change_box</span></a> command if that effect is desired.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Atoms can be moved arbitrarily long distances by this command.
If the simulation box is non-periodic and shrink-wrapped (see the
<a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command), this can change its size or shape.
This is not a problem, except that the mapping of processors to the
simulation box is not changed by this command 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>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>For a 2d simulation, only rotations around the a vector parallel 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>.
<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>h5md = 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.h5 = name of file to write to</li>
<li>args = list of data elements to dump, with their dump “subintervals”.
At least one element must be given and image may only be present if
position is specified first.</li>
</ul>
<pre class="literal-block">
position options
image
velocity options
force options
species options
file_from ID: do not open a new file, re-use the already opened file from dump ID
box value = <em>yes</em> or <em>no</em>
create_group value = <em>yes</em> or <em>no</em>
author value = quoted string
</pre>
<p>For the elements <em>position</em>, <em>velocity</em>, <em>force</em> and <em>species</em>, one
may specify a sub-interval to write the data only every N_element
iterations of the dump (i.e. every N*N_element time steps). This is
+write_dump all h5md dump.h5 file_from h5md1 species
+</pre>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The number of atoms per snapshot cannot change with the h5md style.
The position data is stored wrapped (box boundaries not enforced, see
note above). Only orthogonal domains are currently supported. This is
a limitation of the present dump h5md command and not of H5MD itself.</p>
<p>The <em>h5md</em> dump style is part of the USER-H5MD 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. It also
requires (i) building the ch5md 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.) and
-(ii) having the <a class="reference external" href="http://www.hdfgroup.org/HDF5/">HDF5</a> library installed (C bindings are
+(ii) having the <a class="reference external" href="HDF5_ws">HDF5</a> library installed (C bindings are
sufficient) on your system. The library ch5md is compiled with 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>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>.
<li>group-ID = ID of the group of atoms to be imaged</li>
<li>molfile = 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>
+dump mf3 all molfile 50 melt3.xyz xyz .:/home/akohlmey/vmd/plugins/LINUX/molfile
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Dump a snapshot of atom coordinates and selected additional quantities
to one or more files every N timesteps in one of several formats.
Only information for atoms in the specified group is dumped. This
specific dump style uses molfile plugins that are bundled with the
<a class="reference external" href="http://www.ks.uiuc.edu/Research/vmd">VMD</a> molecular visualization and
analysis 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 native LAMMPS dump
files.</p>
<p>Unless the filename contains a * character, the output will be written
to one single file with the specified format. Otherwise there will be
one file per snapshot and the * will be replaced by the time step number
when the snapshot is written.</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.</p>
</div>
<p>The molfile plugin API has a few restrictions that have to be honored
by this dump style: the number of atoms must not change, the atoms
must be sorted, outside of the coordinates no change in atom properties
(like type, mass, charge) will be recorded.</p>
<hr class="docutils" />
<p>The <em>format</em> keyword determines what format is used to write out the
dump. For this to work, LAMMPS must be able to find and load a
compatible molfile plugin that supports this format. Settings made via
the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command can alter per atom properties
like element names.</p>
<p>The <em>path</em> keyword determines which in directories. This is a “path”
like other search paths, i.e. it can contain multiple directories
separated by a colon (or semi-colon on windows). This keyword is
optional and default to ”.”, the current directory.</p>
<p>The <em>unwrap</em> option of the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command allows
coordinates to be written “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 these
coordinates may thus be far outside the box size stored with the
snapshot.</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
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.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The <em>molfile</em> dump style is part of the USER-MOLFILE 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>Molfile plugins provide a consistent programming interface to read and
write file formats commonly used in molecular simulations. The
USER-MOLFILE package only provides the interface code, not the plugins.
These can be obtained from a VMD installation which has to match the
platform that you are using to compile LAMMPS for. By adding plugins
to VMD, support for new file formats can be added to LAMMPS (or VMD
or other programs that use them) without having to recompile the
application itself. The plugins are installed in the directory:
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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 ff boundary addforce 0.0 0.0 v_push energy v_espace
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Add fx,fy,fz to the corresponding component of force for each atom in
the group. This command can be used to give an additional push to
atoms in a simulation, such as for a simulation of Poiseuille flow in
a channel.</p>
<p>Any of the 3 quantities defining the force 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>fx</em>,
<em>fy</em>, <em>fz</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(s) 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 force 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 force
field with optional time-dependence as well.</p>
<p>If the <em>every</em> keyword is used, the <em>Nevery</em> setting determines how
often the forces are applied. The default value is 1, for every
timestep.</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 to atoms implies a change in their potential energy as
they move due to the applied force field. 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 force is a constant
vector F = (fx,fy,fz), with all components defined as numeric
constants and not as variables. This is because LAMMPS can compute
the energy for each atom directly as E = -x dot F = -(x*fx + y*fy +
z*fz), so that -Grad(E) = F.</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. The 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>fx</em>, <em>fy</em>, <em>fz</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
were a spring-like F = kx, then the energy formula should be E =
-0.5kx^2. If you don’t do this correctly, the minimization will not
converge properly.</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>
-<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 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>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 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 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 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>.
-<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 boundary on which atoms are added with append/atoms must be
shrink/minimum. The opposite boundary may be any boundary type other
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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
+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>.
+fix 2 bottomwall aveforce NULL -1.0 0.0 region top
+fix 2 bottomwall aveforce NULL -1.0 v_oscillate region top
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Apply an additional external force to a group of atoms in such a way
that every atom experiences the same force. This is useful for
pushing on wall or boundary atoms so that the structure of the wall
does not change over time.</p>
<p>The existing force is averaged for the group of atoms, component by
component. The actual force on each atom is then set to the average
value plus the component specified in this command. This means each
atom in the group receives the same force.</p>
<p>Any of the fx,fy,fz values can be specified as NULL which means the
force in that dimension is not changed. Note that this is not the
same as specifying a 0.0 value, since that sets all forces to the same
average value without adding in any additional force.</p>
<p>Any of the 3 quantities defining the force components can be specified
as an equal-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>, namely <em>fx</em>, <em>fy</em>, <em>fz</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 average
force.</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 average force.</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>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>
-<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 before the forces on individual
atoms are changed by the fix. 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>
<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
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>.
-<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 stores
the last timestep on which the timestep was reset to a new value.</p>
<p>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>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>Zero out the z-dimension velocity and force on each atom in the group.
This is useful when running a 2d simulation to insure that atoms do
not move from their initial z coordinate.</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>
-<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>.
-<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 number of deleted atoms. 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>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>.
<p>This fix implements the Gaussian dynamics (GD) method to simulate a
system at constant mass flux <a class="reference internal" href="#strong"><span class="std std-ref">(Strong)</span></a>. GD is a
nonequilibrium molecular dynamics simulation method that can be used
to study fluid flows through pores, pipes, and channels. In its
original implementation GD was used to compute the pressure required
to achieve a fixed mass flux through an opening. The flux can be
conserved in any combination of the directions, x, y, or z, using
xflag,yflag,zflag. This fix does not initialize a net flux through a
system, it only conserves the center-of-mass momentum that is present
when the fix is declared in the input script. Use the
<a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> command to generate an initial center-of-mass
momentum.</p>
<p>GD applies an external fluctuating gravitational field that acts as a
driving force to keep the system away from equilibrium. To maintain
steady state, a profile-unbiased thermostat must be implemented to
dissipate the heat that is added by the driving force. <a class="reference internal" href="compute_temp_profile.html"><span class="doc">Compute temp/profile</span></a> can be used to implement a
profile-unbiased thermostat.</p>
<p>A common use of this fix is to compute a pressure drop across a pipe,
pore, or membrane. The pressure profile can be computed in LAMMPS with
<a class="reference internal" href="compute_stress_atom.html"><span class="doc">compute stress/atom</span></a> and <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a>, or with the hardy method in <a class="reference internal" href="fix_atc.html"><span class="doc">fix atc</span></a>. Note that the simple <a class="reference internal" href="compute_stress_atom.html"><span class="doc">compute stress/atom</span></a> method is only accurate away
from inhomogeneities in the fluid, such as fixed wall atoms. Further,
the computed pressure profile must be corrected for the acceleration
applied by GD before computing a pressure drop or comparing it to
other methods, such as the pump method <a class="reference internal" href="#zhu"><span class="std std-ref">(Zhu)</span></a>. The pressure
correction is discussed and described in <a class="reference internal" href="#strong"><span class="std std-ref">(Strong)</span></a>.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For a complete example including the considerations discussed
above, see the examples/USER/flow_gauss directory.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Only the flux of the atoms in group-ID will be conserved. If the
velocities of the group-ID atoms are coupled to the velocities of
other atoms in the simulation, the flux will not be conserved. For
example, in a simulation with fluid atoms and harmonically constrained
wall atoms, if a single thermostat is applied to group <em>all</em>, the
fluid atom velocities will be coupled to the wall atom velocities, and
the flux will not be conserved. This issue can be avoided by
thermostatting the fluid and wall groups separately.</p>
</div>
<p>Adding an acceleration to atoms does work on the system. This added
energy can be optionally subtracted from the potential energy for the
thermodynamic output (see below) to check that the timestep is small
enough to conserve energy. Since the applied acceleration is
fluctuating in time, the work cannot be computed from a potential. As
a result, computing the work is slightly more computationally
expensive than usual, so it is not performed by default. To invoke the
work calculation, use the <em>energy</em> keyword. The
<a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option also invokes the work
calculation, and overrides an <em>energy no</em> setting here. If neither
<em>energy yes</em> or <em>fix_modify energy yes</em> are set, the global scalar
computed by the fix will return zero.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">In order to check energy conservation, any other fixes that do
work on the system must have <em>fix_modify energy yes</em> set as well. This
includes thermostat fixes and any constraints that hold the positions
of wall atoms fixed, such as <a class="reference internal" href="fix_spring_self.html"><span class="doc">fix spring/self</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>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>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 subtract the work done from 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 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 negative of the
work done on the system, see above discussion. The vector is the total force
that this fix applied to the group of atoms on the current timestep.
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>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>Zero out the force and torque on a granular particle. This is useful
for preventing certain particles from moving in a simulation. The
<a class="reference internal" href="pair_gran.html"><span class="doc">granular pair styles</span></a> also detect if this fix has been
defined and compute interactions between frozen and non-frozen
particles appropriately, as if the frozen particle has infinite mass.
A similar functionality for normal (point) particles can be obtained
using <a class="reference internal" href="fix_setforce.html"><span class="doc">fix setforce</span></a>.</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>
-<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 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 before the forces on individual
atoms are changed by the fix. 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 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>There can only be a single freeze fix defined. This is because other
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>.
<p>on each atom where <em>K</em> is the specified force constant, <em>r</em> is the
distance from the atom to the center of the indenter, and <em>R</em> is the
radius of the indenter. The force is repulsive and F(r) = 0 for <em>r</em> >
<em>R</em>.</p>
<p>A cylindrical indenter exerts the same force, except that <em>r</em> is the
distance from the atom to the center axis of the cylinder. The
cylinder extends infinitely along its axis.</p>
<p>Spherical and cylindrical indenters account for periodic boundaries in
two ways. First, the center point of a spherical indenter (x,y,z) or
axis of a cylindrical indenter (c1,c2) is remapped back into the
simulation box, if the box is periodic in a particular dimension.
This occurs every timestep if the indenter geometry is specified with
a variable (see below), e.g. it is moving over time. Second, the
calculation of distance to the indenter center or axis accounts for
periodic boundaries. Both of these mean that an indenter can
effectively move through and straddle one or more periodic boundaries.</p>
<p>A planar indenter is really an axis-aligned infinite-extent wall
exerting the same force on atoms in the system, where <em>R</em> is the
position of the plane and <em>r-R</em> is the distance from the plane. If
the <em>side</em> parameter of the plane is specified as <em>lo</em> then it will
indent from the lo end of the simulation box, meaning that atoms with
a coordinate less than the plane’s current position will be pushed
towards the hi end of the box and atoms with a coordinate higher than
the plane’s current position will feel no force. Vice versa if <em>side</em>
is specified as <em>hi</em>.</p>
<p>Any of the 4 quantities defining a spherical indenter’s geometry can
be specified as an equal-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>, namely <em>x</em>,
<em>y</em>, <em>z</em>, or <em>R</em>. Similarly, for a cylindrical indenter, any of <em>c1</em>,
<em>c2</em>, or <em>R</em>, can be a variable. For a planar indenter, <em>pos</em> can be
a variable. 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 define the
indenter geometry.</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 indenter properties 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, if a spherical indenter’s x-position is specfied as v_x,
then this variable definition will keep it’s center at a relative
position in the simulation box, 1/4 of the way from the left edge 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>.</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 indenter to
the system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>. The energy of each particle interacting
with the indenter is K/3 (r - R)^3.</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-vector of
forces (on the indenter), 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 and vector values
calculated by this fix are “extensive”.</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. Note that if you
define the indenter geometry with a variable using a time-dependent
formula, LAMMPS uses the iteration count in the minimizer as the
timestep. But it is almost certainly a bad idea to have the indenter
change its position or size during a minimization. LAMMPS does not
check if you have done this.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you want the atom/indenter 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>
option for this fix.</p>
</div>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<blockquote>
<div>none</div></blockquote>
<p><strong>Related commands:</strong> none</p>
</div>
<div class="section" id="default">
<h2>Default</h2>
<p>The option defaults are side = out and units = lattice.</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>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 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="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>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>manifold = name of the manifold</li>
<li>manifold-args = parameters for the manifold</li>
</ul>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<p>fix constrain all manifoldforce sphere 5.0</p>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>This fix subtracts each time step from the force the component along the normal of the specified <a class="reference internal" href="manifolds.html"><span class="doc">manifold</span></a>.
This can be used in combination with <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> to remove overlap between particles while
keeping them (roughly) constrained to the given manifold, e.g. to set up a run with <a class="reference internal" href="fix_nve_manifold_rattle.html"><span class="doc">fix nve/manifold/rattle</span></a>.
I have found that only <em>hftn</em> and <em>quickmin</em> with a very small time step perform adequately though.</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 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>
<p>Only use this with <em>min_style hftn</em> or <em>min_style quickmin</em>. If not, the constraints
will not be satisfied very well at all. A warning is generated if the <em>min_style</em> 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>.
-<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-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>.
-<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-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>Modify one or more parameters of a previously defined fix. Only
specific fix styles support specific parameters. See the doc pages
for individual fix commands for info on which ones support which
fix_modify parameters.</p>
<p>The <em>temp</em> keyword is used to determine how a fix computes
temperature. The specified compute ID must have been previously
defined by the user via the <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command and it must
be a style of compute that calculates a temperature. All fixes that
compute temperatures define their own compute by default, as described
in their documentation. Thus this option allows the user to override
the default method for computing T.</p>
<p>The <em>press</em> keyword is used to determine how a fix computes pressure.
The specified compute ID must have been previously defined by the user
via the <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command and it must be a style of
compute that calculates a pressure. All fixes that compute pressures
define their own compute by default, as described in their
documentation. Thus this option allows the user to override the
default method for computing P.</p>
<p>For fixes that calculate a contribution to the potential energy of the
system, the <em>energy</em> keyword will include that contribution in
thermodynamic output of potential energy. This is because the <em>energy
yes</em> setting must be specfied to include the fix’s global or per-atom
energy in the calculation performed by the <a class="reference internal" href="compute_pe.html"><span class="doc">compute pe</span></a> or <a class="reference internal" href="compute_pe_atom.html"><span class="doc">compute pe/atom</span></a>
commands. See the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command for info
on how potential energy is output. For fixes that tally a global
energy, it can be printed by using the keyword f_ID in the
thermo_style custom command, where ID is the fix-ID of the appropriate
fix.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">You must also specify the <em>energy yes</em> setting for a fix if you
are using it when performing an <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>
and if you want the energy and forces it produces to be part of the
optimization criteria.</p>
</div>
<p>For fixes that set or modify forces, it may be possible to select at
which <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA</span></a> level the fix operates via the <em>respa</em>
keyword. The RESPA level at which the fix is active can be selected.
This is a number ranging from 1 to the number of levels. If the RESPA
level is larger than the current maximum, the outermost level will be
used, which is also the default setting. This default can be restored
using a value of <em>0</em> for the RESPA level. The affected fix has to be
enabled to support this feature; if not, <em>fix_modify</em> will report an
error. Active fixes with a custom RESPA level setting are reported
with their specified level at the beginning of a r-RESPA run.</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>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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/body = 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_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>
<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 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>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>.
<p>Perform constant NVE integration to update position and velocity for
atoms in the group each timestep. V is volume; E is energy. This
creates a system trajectory consistent with the microcanonical
ensemble.</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>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>.
<p>Perform constant NVE integration to update position and velocity 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. V is volume; E is energy. This creates a
system trajectory consistent with the microcanonical ensemble.</p>
<p>The operation of this fix is exactly like that described by the <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> command, except that the radius and radial velocity
-<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-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>.
-<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
count of how many updates of atom’s velocity/position were limited by
the maximum distance criterion. This should be roughly the number of
atoms so affected, except that updates occur at both the beginning and
end of a timestep in a velocity Verlet timestepping algorithm. This
is a cumulative quantity for the current run, but is re-initialized to
zero each time a run is performed. 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>.
-<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,
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>.
-<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>.
<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>.
<p>This fix combines the RATTLE-based <a class="reference internal" href="fix_shake.html#andersen"><span class="std std-ref">(Andersen)</span></a> time integrator of <a class="reference internal" href="fix_nve_manifold_rattle.html"><span class="doc">fix nve/manifold/rattle</span></a> <a class="reference internal" href="manifolds.html#paquay"><span class="std std-ref">(Paquay)</span></a> with a Nose-Hoover-chain thermostat to sample the
canonical ensemble of particles constrained to a curved surface (manifold). This sampling does suffer from discretization bias of O(dt).
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>
-<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>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>oneway = style name of this fix command</li>
<li>N = apply this fix every this many timesteps</li>
<li>region-ID = ID of region where fix is active</li>
<li>direction = <em>x</em> or <em>-x</em> or <em>y</em> or <em>-y</em> or <em>z</em> or <em>-z</em> = coordinate and direction of the oneway constraint</li>
-<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 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>.
-<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>Treats one or more sets of atoms as coupled rigid bodies. This means
that each timestep the total force and torque on each rigid body is
computed and the coordinates and velocities of the atoms are updated
so that the collection of bodies move as a coupled set. This can be
useful for treating a large biomolecule as a collection of connected,
coarse-grained particles.</p>
<p>The coupling, associated motion constraints, and time integration is
performed by the software package <a class="reference external" href="http://www.rpi.edu/~anderk5/lab">Parallelizable Open source Efficient Multibody Software (POEMS)</a> which computes the
constrained rigid-body motion of articulated (jointed) multibody
systems <a class="reference internal" href="#anderson"><span class="std std-ref">(Anderson)</span></a>. POEMS was written and is distributed
by Prof Kurt Anderson, his graduate student Rudranarayan Mukherjee,
and other members of his group at Rensselaer Polytechnic Institute
(RPI). Rudranarayan developed the LAMMPS/POEMS interface. For
copyright information on POEMS and other details, please refer to the
documents in the poems directory distributed with LAMMPS.</p>
<p>This fix updates the positions and velocities of the rigid atoms with
a constant-energy time integration, so you should not update the same
atoms via other fixes (e.g. nve, nvt, npt, temp/rescale, langevin).</p>
<p>Each body must have a non-degenerate inertia tensor, which means if
must contain at least 3 non-collinear atoms. Which atoms are in which
bodies can be defined via several options.</p>
<p>For option <em>group</em>, each of the listed groups is treated as a rigid
body. Note that only atoms that are also in the fix group are
included in each rigid body.</p>
<p>For option <em>molecule</em>, each set of atoms in the group with a different
molecule ID is treated as a rigid body.</p>
<p>For option <em>file</em>, sets of atoms are read from the specified file and
each set is treated as a rigid body. Each line of the file specifies
a rigid body in the following format:</p>
<p>ID type atom1-ID atom2-ID atom3-ID ...</p>
<p>ID as an integer from 1 to M (the number of rigid bodies). Type is
any integer; it is not used by the fix poems command. The remaining
arguments are IDs of atoms in the rigid body, each typically from 1 to
N (the number of atoms in the system). Only atoms that are also in
the fix group are included in each rigid body. Blank lines and lines
that begin with ‘#’ are skipped.</p>
<p>A connection between a pair of rigid bodies is inferred if one atom is
common to both bodies. The POEMS solver treats that atom as a
spherical joint with 3 degrees of freedom. Currently, a collection of
bodies can only be connected by joints as a linear chain. The entire
collection of rigid bodies can represent one or more chains. Other
connection topologies (tree, ring) are not allowed, but will be added
later. Note that if no joints exist, it is more efficient to use the
<a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> command to simulate the system.</p>
<p>When the poems fix is defined, it will print out statistics on the
total # of clusters, bodies, joints, atoms involved. A cluster in
this context means a set of rigid bodies connected by joints.</p>
<p>For computational efficiency, you should turn off pairwise and bond
interactions within each rigid body, as they no longer contribute to
the motion. The “neigh_modify exclude” and “delete_bonds” commands
can be used to do this if each rigid body is a group.</p>
<p>For computational efficiency, you should only define one fix poems
which includes all the desired rigid bodies. LAMMPS will allow
multiple poems fixes to be defined, but it is more expensive.</p>
<p>The degrees-of-freedom removed by coupled rigid bodies are accounted
for in temperature and pressure computations. Similarly, the rigid
body contribution to the pressure virial is also accounted for. The
latter is only correct if forces within the bodies have been turned
off, and there is only a single fix poems defined.</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 POEMS package. It is only enabled if LAMMPS
was built with that package, which also requires the POEMS 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>.
<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>.
<p>Reset the pressure of the system by using a Berendsen barostat
<a class="reference internal" href="fix_temp_berendsen.html#berendsen"><span class="std std-ref">(Berendsen)</span></a>, which rescales the system volume and
(optionally) the atoms coordinates within the simulation box every
timestep.</p>
<p>Regardless of what atoms are in the fix group, a global pressure 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 value of <em>partial</em>, in which case
only the atoms in the fix group are re-scaled. The latter can be
useful for leaving the coordinates of atoms in a solid substrate
unchanged and controlling the pressure of a surrounding fluid.</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 npt</span></a> or <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a>
commands which perform Nose/Hoover barostatting AND time integration,
this fix does NOT perform time integration. It only modifies the box
size and atom coordinates to effect barostatting. 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 nvt</span></a> to actually update the positions and velocities of
atoms. This fix can be used in conjunction with thermostatting fixes
to control the temperature, such as <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> or <a class="reference internal" href="fix_temp_berendsen.html"><span class="doc">fix temp/berendsen</span></a>.</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>The barostat is 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 the 3 diagonal components of an external stress
tensor, and to couple various of these components together so that the
dimensions they represent are varied together during a
constant-pressure simulation. Unlike 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, this fix cannot be used with triclinic
(non-orthogonal) simulation boxes to control all 6 components of the
general pressure tensor.</p>
<p>The target pressures for each of the 3 diagonal 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 determines 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
(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 Berendsen 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
<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.</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 calculations. 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>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 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>Any dimension being adjusted by this fix must be 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>.
<p>Print a text string every N steps during a simulation run. This can
be used for diagnostic purposes or as a debugging tool to monitor some
quantity during a run. The text string must be a single argument, so
it should be enclosed in double quotes if it is more than one word.
If it contains variables it must be enclosed in double quotes to
insure they are not evaluated when the input script line is read, but
will instead be evaluated each time the string is printed.</p>
<p>The specified group-ID is ignored by this fix.</p>
<p>See the <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command for a description of <em>equal</em>
style variables which are the most useful ones to use with the fix
print command, since they are evaluated afresh each timestep that the
fix print line is output. Equal-style variables calculate formulas
involving mathematical operations, atom properties, group properties,
thermodynamic properties, global values 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>, or references to other
-<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>.
<p>Create one or more additional per-atom vectors to store information
about atoms and to use during a simulation. The specified <em>group-ID</em>
is ignored by this fix.</p>
<p>The atom style used for a simulation defines a set of per-atom
properties, as explained on 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> doc pages. The latter command allows these
properties to be defined for each atom in the system when a data file
is read. This fix will augment the set of properties with new custom
ones. This can be useful in several scenarios.</p>
<p>If the atom style does not define molecule IDs, per-atom charge,
or per-atom mass, they can be added using the <em>mol</em>, <em>q</em> or <em>rmass</em>
keywords. This can be useful, e.g, to define “molecules” to use as
rigid bodies with the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> command, or just to
carry around an extra flag with the atoms (stored as a molecule ID)
that can be used to group atoms without having to use the group
command (which is limited to a total of 32 groups including <em>all</em>).</p>
<p>Another application would be to use the <em>rmass</em> flag in order to have
per-atom masses instead of per-type masses, for example this can be
useful to study isotope effects with partial isotope substitution.
Please <a class="reference internal" href="#isotopes"><span class="std std-ref">see below</span></a> for an example of simulating a mixture
of light and heavy water with the TIP4P water potential.</p>
<p>An alternative to using fix <em>property/atom</em> in these ways is to
use an atom style that does define molecule IDs or charge or per-atom
mass (indirectly via diameter and density) or to use a hybrid atom
style that combines two or more atom styles
to provide the union of all atom properties. However, this has two
practical drawbacks: first, it typically necessitates changing the
format of the data file, which can be tedious for large systems;
and second, it may define additional properties that are not needed
such as bond lists, which has some overhead when there are no bonds.</p>
<p>In the future, we may add additional per-atom properties similar to
<em>mol</em>, <em>q</em> or <em>rmass</em>, which “turn-on” specific properties defined
by some atom styles, so they can be used by atom styles that do not
define them.</p>
<p>More generally, the <em>i_name</em> and <em>d_name</em> vectors allow one or more
new custom per-atom properties to be defined. Each name must be
unique and can use alphanumeric or underscore characters. These
vectors can store whatever values you decide are useful in your
simulation. As explained below there are several ways to initialize
and access and output these values, both via input script commands and
in new code that you add to LAMMPS.</p>
<p>This is effectively a simple way to add per-atom properties to a model
without needing to write code for a new <a class="reference internal" href="atom_style.html"><span class="doc">atom style</span></a>
that defines the properties. Note however that implementing a new
atom style allows new atom properties to be more tightly and
seamlessly integrated with the rest of the code.</p>
<p>The new atom properties encode values that migrate with atoms to new
processors and are written to restart files. If you want the new
properties to also be defined for ghost atoms, then use the <em>ghost</em>
keyword with a value of <em>yes</em>. This will invoke extra communication
when ghost atoms are created (at every re-neighboring) to insure the
new properties are also defined for the ghost atoms.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you use this command with the <em>mol</em>, <em>q</em> or <em>rmass</em> vectors,
then you most likely want to set <em>ghost</em> yes, since these properties
are stored with ghost atoms if you use an <a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a>
that defines them, and many LAMMPS operations that use molecule IDs or
charge, such as neighbor lists and pair styles, will expect ghost
atoms to have these valuse. LAMMPS will issue a warning it you define
those vectors but do not set <em>ghost</em> yes.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The properties for ghost atoms are not updated every timestep,
but only once every few steps when neighbor lists are re-built. Thus
the <em>ghost</em> keyword is suitable for static properties, like molecule
IDs, but not for dynamic properties that change every step. For the
latter, the code you add to LAMMPS to change the properties will also
need to communicate their new values to/from ghost atoms, an operation
that can be invoked from within a <a class="reference internal" href="pair_style.html"><span class="doc">pair style</span></a> or
<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> that you write.</p>
</div>
<hr class="docutils" />
<p>This fix is one of a small number that can be defined in an input
script before the simulation box is created or atoms are defined.
This is so it can be used with the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command
as described below.</p>
<p>Per-atom properties that are defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom style</span></a> are initialized when atoms are created, e.g. by
the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> or <a class="reference internal" href="create_atoms.html"><span class="doc">create_atoms</span></a>
commands. The per-atom properaties defined by this fix are not. So
you need to initialize them explicitly. This can be done by the
<a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command, using its <em>fix</em> keyword and
<p>The <a class="reference internal" href="variable.html"><span class="doc">atom-style variable</span></a> will create values for atoms
with IDs 31,32,33,...40 that are 4.0,4.1,4.2,...,4.9. When the
<a class="reference internal" href="set.html"><span class="doc">set</span></a> commands assigns them to the molecule ID for each atom,
they will be truncated to an integer value, so atoms 31-40 will all be
assigned a molecule ID of 4.</p>
<p>Note that <a class="reference internal" href="variable.html"><span class="doc">atomfile-style variables</span></a> can also be used in
place of atom-style variables, which means in this case that the
molecule IDs could be read-in from a separate file and assinged by the
<a class="reference internal" href="set.html"><span class="doc">set</span></a> command. This allows you to initialize new per-atom
properties in a completely general fashion.</p>
<hr class="docutils" />
<p>For new atom properties specified as <em>i_name</em> or <em>d_name</em>, the
<a class="reference internal" href="compute_property_atom.html"><span class="doc">compute property/atom</span></a> command can access
their values. This means that the values can be output via the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command, accessed by fixes like <a class="reference internal" href="fix_ave_atom.html"><span class="doc">fix ave/atom</span></a>, accessed by other computes like <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a>, or used in <a class="reference external" href="variables">atom-style variables</a>.</p>
<p>For example, these commands will output two new properties to a custom
+dump 1 all custom 100 tmp.dump id x y z c_1[1] c_1[2]
+</pre>
<hr class="docutils" />
<p>If you wish to add new <a class="reference internal" href="pair_style.html"><span class="doc">pair styles</span></a>,
<a class="reference internal" href="fix.html"><span class="doc">fixes</span></a>, or <a class="reference internal" href="compute.html"><span class="doc">computes</span></a> that use the per-atom
properties defined by this fix, see <a class="reference internal" href="Section_modify.html#mod-1"><span class="std std-ref">Section modify</span></a> of the manual which has some details
on how the properties can be accessed from added classes.</p>
<hr class="docutils" />
<p id="isotopes">Example for using per-atom masses with TIP4P water to study isotope
effects. When setting up simulations with the <a class="reference internal" href="Section_howto.html#howto-8"><span class="std std-ref">TIP4P pair styles</span></a> for water, you have to provide
exactly one atom type each to identify the water oxygen and hydrogen
atoms. Since the atom mass is normally tied to the atom type, this
makes it impossible to study multiple isotopes in the same simulation.
With <em>fix property/atom rmass</em> however, the per-type masses are
replaced by per-atom masses. Asumming you have a working input deck
for regular TIP4P water, where water oxygen is atom type 1 and
water hydrogen is atom type 2, the following lines of input script
-<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. 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>.
<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>Distance units for the x,y,z values are determined by the setting of
the <em>units</em> keyword, as discussed below. One or more x,y,z values can
also be specified as NULL, which means exclude that dimension from
this operation. Or it can be specified as INIT which means to
constrain the center-of-mass to its initial value at the beginning of
the run.</p>
<p>The center-of-mass (COM) is computed for the group specified by the
fix. If the current COM is different than the specified x,y,z, then a
group of atoms has their coordinates shifted by the difference. By
default the shifted group is also the group specified by the fix. A
different group can be shifted by using the <em>shift</em> keyword. For
example, the COM could be computed on a protein to keep it in the
center of the simulation box. But the entire system (protein + water)
could be shifted.</p>
<p>If the <em>units</em> keyword is set to <em>box</em>, then the distance units of
x,y,z are defined by the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command - e.g. Angstroms
for <em>real</em> units. 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. A <em>fraction</em> value
means a fractional distance between the lo/hi box boundaries, e.g. 0.5
= middle of the box. The default is to use lattice units.</p>
<p>Note that the <a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> command can be used to create
velocities with zero aggregate linear and/or angular momentum.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">This fix performs its operations at the same point in the
timestep as other time integration fixes, such as <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>, or <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a>.
Thus fix recenter should normally be the last such fix specified in
the input script, since the adjustments it makes to atom coordinates
should come after the changes made by time integration. LAMMPS will
warn you if your fixes are not ordered this way.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you use this fix on a small group of atoms (e.g. a molecule
in solvent) without using the <em>shift</em> keyword to adjust the positions
of all atoms in the system, then the results can be unpredictable.
For example, if the molecule is pushed consistently in one direction
by a flowing solvent, its velocity will increase. But its coordinates
will be recentered, meaning it is moved back towards the force. Thus
over time, the velocity and effective temperature of the molecule
could become very large, though it won’t actually be moving due to the
recentering. If you are thermostatting the entire system, then the
solvent would be cooled to compensate. A better solution for this
simulation scenario is to use the <a class="reference internal" href="fix_spring.html"><span class="doc">fix spring</span></a> command
-<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
distance the group is moved by fix recenter.</p>
<p>This fix also computes 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 3
quantities in the vector are xyz components of displacement applied to
the group of atoms by the fix.</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. 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 should not be used with an x,y,z setting that causes a large
shift in the system on the 1st timestep, due to the requested COM
being very different from the initial COM. This could cause atoms to
be lost, especially in parallel. Instead, use the
<a class="reference internal" href="displace_atoms.html"><span class="doc">displace_atoms</span></a> command, which can be 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>.
<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>.
<p>Set each component of force on each atom in the group to the specified
values fx,fy,fz. This erases all previously computed forces on the
atom, though additional fixes could add new forces. This command can
be used to freeze certain atoms in the simulation by zeroing their
force, either for running dynamics or performing an energy
minimization. For dynamics, this assumes their initial velocity is
also zero.</p>
<p>Any of the fx,fy,fz values can be specified as NULL which means do not
alter the force component in that dimension.</p>
<p>Any of the 3 quantities defining the force 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>fx</em>,
<em>fy</em>, <em>fz</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 force 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 force
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>Styles with a r <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 region keyword is also supported by Kokkos, but a Kokkos-enabled
region must be used. See the region <a class="reference internal" href="region.html"><span class="doc">region</span></a> command for
more information.</p>
<p>These accelerated styles are part of the r 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>
-<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 setting the forces to the desired values; on all
other levels, the force is set to 0.0 for the atoms in the fix group,
so that setforce values are not counted multiple times. Default is to
to override forces at 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 before the forces on individual
atoms are changed by the fix. 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>
<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, but you cannot set
forces to any value besides zero when performing a minimization. Use
the <a class="reference internal" href="fix_addforce.html"><span class="doc">fix addforce</span></a> command if you want to apply a
non-zero force to atoms during a minimization.</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 = 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>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>srd = style name of this fix command</li>
<li>N = reset SRD particle velocities every this many timesteps</li>
<li>groupbig-ID = ID of group of large particles that SRDs interact with</li>
<li>Tsrd = temperature of SRD particles (temperature units)</li>
<li>hgrid = grid spacing for SRD grouping (distance units)</li>
<li>seed = random # seed (positive integer)</li>
<li>zero or more keyword/value pairs may be appended</li>
<li>keyword = <em>lamda</em> or <em>collision</em> or <em>overlap</em> or <em>inside</em> or <em>exact</em> or <em>radius</em> or <em>bounce</em> or <em>search</em> or <em>cubic</em> or <em>shift</em> or <em>tstat</em> or <em>rescale</em></li>
</ul>
<pre class="literal-block">
<em>lamda</em> value = mean free path of SRD particles (distance units)
<em>collision</em> value = <em>noslip</em> or <em>slip</em> = collision model
<em>overlap</em> value = <em>yes</em> or <em>no</em> = whether big particles may overlap
<em>inside</em> value = <em>error</em> or <em>warn</em> or <em>ignore</em> = how SRD particles which end up inside a big particle are treated
<em>exact</em> value = <em>yes</em> or <em>no</em>
<em>radius</em> value = rfactor = scale collision radius by this factor
<em>bounce</em> value = Nbounce = max # of collisions an SRD particle can undergo in one timestep
<em>search</em> value = sgrid = grid spacing for collision partner searching (distance units)
<em>cubic</em> values = style tolerance
style = <em>error</em> or <em>warn</em>
tolerance = fractional difference allowed (0 <= tol <= 1)
<em>shift</em> values = flag shiftseed
flag = <em>yes</em> or <em>no</em> or <em>possible</em> = SRD bin shifting for better statistics
<em>yes</em> = perform bin shifting each time SRD velocities are rescaled
<em>no</em> = no shifting
<em>possible</em> = shift depending on mean free path and bin size
shiftseed = random # seed (positive integer)
<em>tstat</em> value = <em>yes</em> or <em>no</em> = thermostat SRD particles or not
<em>rescale</em> value = <em>yes</em> or <em>no</em> or <em>rotate</em> or <em>collide</em> = rescaling of SRD velocities
<em>yes</em> = rescale during velocity rotation and collisions
<em>no</em> = no rescaling
<em>rotate</em> = rescale during velocity rotation, but not collisions
<em>collide</em> = rescale during collisions, but not velocity rotation
<p>Treat a group of partilces as stochastic rotation dynamics (SRD)
particles that serve as a background solvent when interacting with big
(colloidal) particles in groupbig-ID. The SRD formalism is described
in <a class="reference internal" href="#hecht"><span class="std std-ref">(Hecht)</span></a>. The key idea behind using SRD particles as a
cheap coarse-grained solvent is that SRD particles do not interact
with each other, but only with the solute particles, which in LAMMPS
can be spheroids, ellipsoids, or line segments, or triangles, or rigid
bodies containing multiple spherioids or ellipsoids or line segments
or triangles. The collision and rotation properties of the model
imbue the SRD particles with fluid-like properties, including an
effective viscosity. Thus simulations with large solute particles can
be run more quickly, to measure solute propoerties like diffusivity
and viscosity in a background fluid. The usual LAMMPS fixes for such
simulations, such as <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a>, <a class="reference internal" href="fix_viscosity.html"><span class="doc">fix viscosity</span></a>, and <a class="reference internal" href="fix_nvt_sllod.html"><span class="doc">fix nvt/sllod</span></a>,
can be used in conjunction with the SRD model.</p>
<p>For more details on how the SRD model is implemented in LAMMPS, <a class="reference internal" href="kspace_style.html#petersen"><span class="std std-ref">this paper</span></a> describes the implementation and usage of pure SRD
fluids. <a class="reference internal" href="#lechman"><span class="std std-ref">This paper</span></a>, which is nearly complete, describes
the implementation and usage of mixture systems (solute particles in
an SRD fluid). See the examples/srd directory for sample input
scripts using SRD particles in both settings.</p>
<p>This fix does 2 things:</p>
<p>(1) It advects the SRD particles, performing collisions between SRD
and big particles or walls every timestep, imparting force and torque
to the big particles. Collisions also change the position and
velocity of SRD particles.</p>
<p>(2) It resets the velocity distribution of SRD particles via random
rotations every N timesteps.</p>
<p>SRD particles have a mass, temperature, characteristic timestep
dt_SRD, and mean free path between collisions (lamda). The
fundamental equation relating these 4 quantities is</p>
<p>The mass of SRD particles is set by the <a class="reference internal" href="mass.html"><span class="doc">mass</span></a> command
elsewhere in the input script. The SRD timestep dt_SRD is N times the
step dt defined by the <a class="reference internal" href="timestep.html"><span class="doc">timestep</span></a> command. Big
particles move in the normal way via a time integration <a class="reference internal" href="fix.html"><span class="doc">fix</span></a>
with a short timestep dt. SRD particles advect with a large timestep
dt_SRD >= dt.</p>
<p>If the <em>lamda</em> keyword is not specified, the the SRD temperature
<em>Tsrd</em> is used in the above formula to compute lamda. If the <em>lamda</em>
keyword is specified, then the <em>Tsrd</em> setting is ignored and the above
equation is used to compute the SRD temperature.</p>
<p>The characteristic length scale for the SRD fluid is set by <em>hgrid</em>
which is used to bin SRD particles for purposes of resetting their
velocities. Normally hgrid is set to be 1/4 of the big particle
diameter or smaller, to adequately resolve fluid properties around the
big particles.</p>
<p>Lamda cannot be smaller than 0.6 * hgrid, else an error is generated
(unless the <em>shift</em> keyword is used, see below). The velocities of
SRD particles are bounded by Vmax, which is set so that an SRD
particle will not advect further than Dmax = 4*lamda in dt_SRD. This
means that roughly speaking, Dmax should not be larger than a big
particle diameter, else SRDs may pass thru big particles without
colliding. A warning is generated if this is the case.</p>
<p>Collisions between SRD particles and big particles or walls are
modeled as a lightweight SRD point particle hitting a heavy big
particle of given diameter or a wall at a point on its surface and
bouncing off with a new velocity. The collision changes the momentum
of the SRD particle. It imparts a force and torque to the big
particle. It imparts a force to a wall. Static or moving SRD walls
are setup via the <a class="reference internal" href="fix_wall_srd.html"><span class="doc">fix wall/srd</span></a> command. For the
remainder of this doc page, a collision of an SRD particle with a wall
can be viewed as a collision with a big particle of infinite radius
and mass.</p>
<p>The <em>collision</em> keyword sets the style of collisions. The <em>slip</em>
style means that the tangential component of the SRD particle momentum
is preserved. Thus a force is imparted to a big particle, but no
torque. The normal component of the new SRD velocity is sampled from
a Gaussian distribution at temperature <em>Tsrd</em>.</p>
<p>For the <em>noslip</em> style, both the normal and tangential components of
the new SRD velocity are sampled from a Gaussian distribution at
temperature <em>Tsrd</em>. Additionally, a new tangential direction for the
SRD velocity is chosen randomly. This collision style imparts torque
to a big particle. Thus a time integrator <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> that rotates
the big particles appropriately should be used.</p>
<hr class="docutils" />
<p>The <em>overlap</em> keyword should be set to <em>yes</em> if two (or more) big
particles can ever overlap. This depends on the pair potential
interaction used for big-big interactions, or could be the case if
multiple big particles are held together as rigid bodies via the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> command. If the <em>overlap</em> keyword is <em>no</em> and
big particles do in fact overlap, then SRD/big collisions can generate
an error if an SRD ends up inside two (or more) big particles at once.
How this error is treated is determined by the <em>inside</em> keyword.
Running with <em>overlap</em> set to <em>no</em> allows for faster collision
checking, so it should only be set to <em>yes</em> if needed.</p>
<p>The <em>inside</em> keyword determines how a collision is treated if the
computation determines that the timestep started with the SRD particle
already inside a big particle. If the setting is <em>error</em> then this
generates an error message and LAMMPS stops. If the setting is <em>warn</em>
then this generates a warning message and the code continues. If the
setting is <em>ignore</em> then no message is generated. One of the output
quantities logged by the fix (see below) tallies the number of such
events, so it can be monitored. Note that once an SRD particle is
inside a big particle, it may remain there for several steps until it
drifts outside the big particle.</p>
<p>The <em>exact</em> keyword determines how accurately collisions are computed.
A setting of <em>yes</em> computes the time and position of each collision as
SRD and big particles move together. A setting of <em>no</em> estimates the
position of each collision based on the end-of-timestep positions of
the SRD and big particle. If <em>overlap</em> is set to yes, the setting of
the <em>exact</em> keyword is ignored since time-accurate collisions are
needed.</p>
<p>The <em>radius</em> keyword scales the effective size of big particles. If
big particles will overlap as they undergo dynamics, then this keyword
can be used to scale down their effective collision radius by an
amount <em>rfactor</em>, so that SRD particle will only collide with one big
particle at a time. For example, in a Lennard-Jones system at a
temperature of 1.0 (in reduced LJ units), the minimum separation
bewteen two big particles is as small as about 0.88 sigma. Thus an
<em>rfactor</em> value of 0.85 should prevent dual collisions.</p>
<p>The <em>bounce</em> keyword can be used to limit the maximum number of
collisions an SRD particle undergoes in a single timestep as it
bounces between nearby big particles. Note that if the limit is
reached, the SRD can be left inside a big particle. A setting of 0 is
the same as no limit.</p>
<hr class="docutils" />
<p>There are 2 kinds of bins created and maintained when running an SRD
simulation. The first are “SRD bins” which are used to bin SRD
particles and reset their velocities, as discussed above. The second
are “search bins” which are used to identify SRD/big particle
collisions.</p>
<p>The <em>search</em> keyword can be used to choose a search bin size for
identifying SRD/big particle collisions. The default is to use the
<em>hgrid</em> parameter for SRD bins as the search bin size. Choosing a
smaller or large value may be more efficient, depending on the
problem. But, in a statistical sense, it should not change the
simulation results.</p>
<p>The <em>cubic</em> keyword can be used to generate an error or warning when
the bin size chosen by LAMMPS creates SRD bins that are non-cubic or
different than the requested value of <em>hgrid</em> by a specified
<em>tolerance</em>. Note that using non-cubic SRD bins can lead to
undetermined behavior when rotating the velocities of SRD particles,
hence LAMMPS tries to protect you from this problem.</p>
<p>LAMMPS attempts to set the SRD bin size to exactly <em>hgrid</em>. However,
there must be an integer number of bins in each dimension of the
simulation box. Thus the actual bin size will depend on the size and
shape of the overall simulation box. The actual bin size is printed
as part of the SRD output when a simulation begins.</p>
<p>If the actual bin size in non-cubic by an amount exceeding the
tolerance, an error or warning is printed, depending on the style of
the <em>cubic</em> keyword. Likewise, if the actual bin size differs from
the requested <em>hgrid</em> value by an amount exceeding the tolerance, then
an error or warning is printed. The <em>tolerance</em> is a fractional
difference. E.g. a tolerance setting of 0.01 on the shape means that
if the ratio of any 2 bin dimensions exceeds (1 +/- tolerance) then an
error or warning is generated. Similarly, if the ratio of any bin
dimension with <em>hgrid</em> exceeds (1 +/- tolerance), then an error or
warning is generated.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The fix srd command can be used with simluations the size and/or
shape of the simulation box changes. This can be due to non-periodic
boundary conditions or the use of fixes such as the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> or <a class="reference internal" href="fix_wall_srd.html"><span class="doc">fix wall/srd</span></a> commands
to impose a shear on an SRD fluid or an interaction with an external
wall. If the box size changes then the size of SRD bins must be
recalculated every reneighboring. This is not necessary if only the
box shape changes. This re-binning is always done so as to fit an
integer number of bins in the current box dimension, whether it be a
fixed, shrink-wrapped, or periodic boundary, as set by the
<a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command. If the box size or shape changes,
then the size of the search bins must be recalculated avery
reneighboring. Note that changing the SRD bin size may alter the
properties of the SRD fluid, such as its viscosity.</p>
</div>
<p>The <em>shift</em> keyword determines whether the coordinates of SRD
particles are randomly shifted when binned for purposes of rotating
their velocities. When no shifting is performed, SRD particles are
binned and the velocity distribution of the set of SRD particles in
each bin is adjusted via a rotation operator. This is a statistically
valid operation if SRD particles move sufficiently far between
successive rotations. This is determined by their mean-free path
lamda. If lamda is less than 0.6 of the SRD bin size, then shifting
is required. A shift means that all of the SRD particles are shifted
by a vector whose coordinates are chosen randomly in the range [-1/2
bin size, 1/2 bin size]. Note that all particles are shifted by the
same vector. The specified random number <em>shiftseed</em> is used to
generate these vectors. This operation sufficiently randomizes which
SRD particles are in the same bin, even if lamda is small.</p>
<p>If the <em>shift</em> flag is set to <em>no</em>, then no shifting is performed, but
bin data will be communicated if bins overlap processor boundaries.
An error will be generated if lamda < 0.6 of the SRD bin size. If the
<em>shift</em> flag is set to <em>possible</em>, then shifting is performed only if
lamda < 0.6 of the SRD bin size. A warning is generated to let you
know this is occurring. If the <em>shift</em> flag is set to <em>yes</em> then
shifting is performed regardless of the magnitude of lamda. Note that
the <em>shiftseed</em> is not used if the <em>shift</em> flag is set to <em>no</em>, but
must still be specified.</p>
<p>Note that shifting of SRD coordinates requires extra communication,
hence it should not normally be enabled unless required.</p>
<p>The <em>tstat</em> keyword will thermostat the SRD particles to the specified
<em>Tsrd</em>. This is done every N timesteps, during the velocity rotation
operation, by rescaling the thermal velocity of particles in each SRD
bin to the desired temperature. If there is a streaming velocity
associated with the system, e.g. due to use of the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> command to perform a simulation undergoing
shear, then that is also accounted for. The mean velocity of each bin
of SRD particles is set to the position-dependent streaming velocity,
based on the coordinates of the center of the SRD bin. Note that
collisions of SRD particles with big particles or walls has a
thermostatting effect on the colliding particles, so it may not be
necessary to thermostat the SRD particles on a bin by bin basis in
that case. Also note that for streaming simulations, if no
thermostatting is performed (the default), then it may take a long
time for the SRD fluid to come to equilibrium with a velocity profile
that matches the simulation box deformation.</p>
<p>The <em>rescale</em> keyword enables rescaling of an SRD particle’s velocity
if it would travel more than 4 mean-free paths in an SRD timestep. If
an SRD particle exceeds this velocity it is possible it will be lost
when migrating to other processors or that collisions with big
particles will be missed, either of which will generate errors. Thus
the safest mode is to run with rescaling enabled. However rescaling
removes kinetic energy from the system (the particle’s velocity is
reduced). The latter will not typically be a problem if
thermostatting is enabled via the <em>tstat</em> keyword or if SRD collisions
with big particles or walls effectively thermostat the system. If you
wish to turn off rescaling (on is the default), e.g. for a pure SRD
system with no thermostatting so that the temperature does not decline
over time, the <em>rescale</em> keyword can be used. The <em>no</em> value turns
rescaling off during collisions and the per-bin velocity rotation
operation. The <em>collide</em> and <em>rotate</em> values turn it on for
one of the operations and off for the other.</p>
<hr class="docutils" />
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">This fix is normally used for simulations with a huge number of
SRD particles relative to the number of big particles, e.g. 100 to 1.
In this scenario, computations that involve only big particles
(neighbor list creation, communication, time integration) can slow
down dramatically due to the large number of background SRD particles.</p>
</div>
<p>Three other input script commands will largely overcome this effect,
speeding up an SRD simulation by a significant amount. These are 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 tabulates several SRD statistics which are stored in a vector
of length 12, 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”, meaning they do not scale with the size
of the simulation. Technically, the first 8 do scale with the size of
the simulation, but treating them as intensive means they are not
scaled when printed as part of thermodyanmic output.</p>
<p>These are the 12 quantities. All are values for the current timestep,
except for quantity 5 and the last three, each of which are
cummulative quantities since the beginning of the run.</p>
<ul class="simple">
<li><ol class="first arabic">
<li># of SRD/big collision checks performed</li>
</ol>
</li>
<li><ol class="first arabic" start="2">
<li># of SRDs which had a collision</li>
</ol>
</li>
<li><ol class="first arabic" start="3">
<li># of SRD/big colllisions (including multiple bounces)</li>
</ol>
</li>
<li><ol class="first arabic" start="4">
<li># of SRD particles inside a big particle</li>
</ol>
</li>
<li><ol class="first arabic" start="5">
<li># of SRD particles whose velocity was rescaled to be < Vmax</li>
</ol>
</li>
<li><ol class="first arabic" start="6">
<li># of bins for collision searching</li>
</ol>
</li>
<li><ol class="first arabic" start="7">
<li># of bins for SRD velocity rotation</li>
</ol>
</li>
<li><ol class="first arabic" start="8">
<li># of bins in which SRD temperature was computed</li>
</ol>
</li>
<li><ol class="first arabic" start="9">
<li>SRD temperature</li>
</ol>
</li>
<li><ol class="first arabic" start="10">
<li># of SRD particles which have undergone max # of bounces</li>
</ol>
</li>
<li><ol class="first arabic" start="11">
<li>max # of bounces any SRD particle has had in a single step</li>
</ol>
</li>
<li><ol class="first arabic" start="12">
<li># of reneighborings due to SRD particles moving too far</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 command can only be used if LAMMPS was built with the SRD
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>Store the forces on atoms in the group at the point during each
timestep when the fix is invoked, as described below. This is useful
for storing forces before constraints or other boundary conditions are
computed which modify the forces, so that unmodified forces can be
<a class="reference internal" href="dump.html"><span class="doc">written to a dump file</span></a> or accessed by other <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a> that use per-atom quantities.</p>
<p>This fix is invoked at the point in the velocity-Verlet timestepping
-<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 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 x,y,z forces 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. 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>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>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>.
-<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 ramp its rho parameter 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>All TMD fixes must be listed in the input script after all integrator
fixes (nve, nvt, npt) are applied. This ensures that atoms are moved
before their positions are corrected to comply with the constraint.</p>
<p>Atoms that have a TMD fix applied should not be part of a group to
which a SHAKE fix is applied. This is because LAMMPS assumes there
are not multiple competing holonomic constraints applied to the same
atoms.</p>
<p>To read gzipped target 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>.
<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>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. And
the global quantity must be a scalar, not a vector or array.</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> or <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 <em>Nevery</em> argument specifies on what timesteps the input values
will be used in order to be stored. Only timesteps that are a
multiple of <em>Nevery</em>, including timestep 0, will contribute values.</p>
<p>Note that if you perform multiple runs, using the “pre no” option of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command to avoid initialization on subsequent runs,
then you need to use the <em>stop</em> keyword with the first <a class="reference internal" href="run.html"><span class="doc">run</span></a>
command with a timestep value that encompasses all the runs. This is
so that the vector or array stored by this fix can be allocated to a
sufficient size.</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 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.</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 vector. 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 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.</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. An equal-style or
vector-style variable 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> 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
-<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 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>Nevery</em>.</p>
<p>A vector is produced if only a single input value is specified.
An array is produced if multiple input values are specified.
The length of the vector or the number of rows in the array grows
by 1 every <em>Nevery</em> timesteps.</p>
<p>If the fix prouduces a vector, then the entire vector will be either
“intensive” or “extensive”, depending on whether the values stored in
the vector 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
stored, 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>This fix can allocate storage for stored values accumulated 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. If using the <a class="reference internal" href="run.html"><span class="doc">run pre no</span></a> command option,
this is required to allow the fix to allocate sufficient storage for
stored values.</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>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>.
+fix walls all wall/srd xlo 0.0 ylo 10.0 units box
+fix top all wall/srd zhi v_pressdown
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Bound the simulation with one or more walls which interact with
stochastic reaction dynamics (SRD) particles as slip (smooth) or
no-slip (rough) flat surfaces. The wall interaction is actually
invoked via the <a class="reference internal" href="fix_srd.html"><span class="doc">fix srd</span></a> command, only on the group of
SRD particles it defines, so the group setting for the fix wall/srd
command is ignored.</p>
<p>A particle/wall collision occurs if an SRD particle moves outside the
wall on a timestep. This alters the position and velocity of the SRD
particle and imparts a force to the wall.</p>
<p>The <em>collision</em> and <em>Tsrd</em> settings specified via the <a class="reference internal" href="fix_srd.html"><span class="doc">fix srd</span></a> command affect the SRD/wall collisions. A <em>slip</em>
setting for the <em>collision</em> keyword means that the tangential
component of the SRD particle momentum is preserved. Thus only a
normal force is imparted to the wall. The normal component of the new
SRD velocity is sampled from a Gaussian distribution at temperature
<em>Tsrd</em>.</p>
<p>For a <em>noslip</em> setting of the <em>collision</em> keyword, both the normal and
tangential components of the new SRD velocity are sampled from a
Gaussian distribution at temperature <em>Tsrd</em>. Additionally, a new
tangential direction for the SRD velocity is chosen randomly. This
collision style imparts both a normal and tangential force to the
wall.</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>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Because the trajectory of the SRD particle is tracked as it
collides with the wall, you must insure that r = distance of the
particle from the wall, is always > 0 for SRD particles, or LAMMPS
will generate an error. This means you cannot start your simulation
with SRD particles at the wall position <em>coord</em> (r = 0) or with
particles on the wrong side of the wall (r < 0).</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you have 2 or more walls that come together at an edge or
corner (e.g. walls in the x and y dimensions), then be sure to set the
<em>overlap</em> keyword to <em>yes</em> in the <a class="reference internal" href="fix_srd.html"><span class="doc">fix srd</span></a> command,
since the walls effectively overlap when SRD particles collide with
them. LAMMPS will issue a warning if you do not do this.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The walls of this fix only interact with SRD particles, as
defined by the <a class="reference internal" href="fix_srd.html"><span class="doc">fix srd</span></a> command. If you are simulating
a mixture containing other kinds of particles, then you should
typically use <a class="reference internal" href="fix_wall.html"><span class="doc">another wall command</span></a> to act on the other
particles. Since SRD particles will be colliding both with the walls
and the other particles, it is important to insure that the other
particle’s finite extent does not overlap an SRD wall. If you do not
do this, you may generate errors when SRD particles end up “inside”
another particle or a wall at the beginning of a collision step.</p>
</div>
<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 is used.
It is not relevant when EDGE or a variable is used to specify a face
position.</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
-<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 number of
rows in the array is equal to the number of walls defined by the fix.
The number of columns is 3, for the x,y,z components of force on each
wall.</p>
<p>Note that an outward normal force on a wall will be a negative value
for <em>lo</em> walls and a positive value for <em>hi</em> walls. The array 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>Any dimension (xyz) that has an SRD 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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>The <em>hybrid</em> style enables the use of multiple improper styles in one
simulation. An improper style is assigned to each improper type. For
example, impropers in a polymer flow (of improper type 1) could be
computed with a <em>harmonic</em> potential and impropers in the wall
boundary (of improper type 2) could be computed with a <em>cvff</em>
potential. The assignment of improper type to style is made via the
<a class="reference internal" href="improper_coeff.html"><span class="doc">improper_coeff</span></a> command or in the data file.</p>
<p>In the improper_coeff command, the first coefficient sets the improper
style and the remaining coefficients are those appropriate to that
style. In the example above, the 2 improper_coeff commands would set
impropers of improper type 1 to be computed with a <em>harmonic</em>
potential with coefficients 120.0, 30 for K, X0. Improper type 2
would be computed with a <em>cvff</em> potential with coefficients 20.0, -1,
2 for K, d, n.</p>
<p>If the improper <em>class2</em> potential is one of the hybrid styles, it
requires additional AngleAngle coefficients be specified in the data
file. These lines must also have an additional “class2” argument
added after the improper type. For improper types which are assigned
to other hybrid styles, use the style name (e.g. “harmonic”)
appropriate to that style. The AngleAngle coeffs for that improper
type will then be ignored.</p>
<p>An improper style of <em>none</em> can be specified as the 2nd argument to
the improper_coeff command, if you desire to turn off certain improper
types.</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>
<p>Unlike other improper styles, the hybrid improper style does not store
improper coefficient info for individual sub-styles in a <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Thus when retarting a simulation from a
restart file, you need to re-specify improper_coeff 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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>Improper styles can only be set for atom_style choices that allow
impropers to be defined.</p>
<p>Most improper 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 improper 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>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>Using an improper style of zero means improper forces and energies are
not computed, but the geometry of improper quadruplets is still
accessible to other commands.</p>
<p>As an example, the <a class="reference internal" href="compute_improper_local.html"><span class="doc">compute improper/local</span></a> command can be used to
compute the chi values for the list of quadruplets of improper atoms
listed in the data file read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
command. If no improper style is defined, this command cannot be
used.</p>
<p>The optional <em>nocoeff</em> flag allows to read data files with a ImproperCoeff
section for any improper style. Similarly, any improper_coeff commands
will only be checked for the improper type number and the rest ignored.</p>
<p>Note that the <a class="reference internal" href="improper_coeff.html"><span class="doc">improper_coeff</span></a> command must be
used for all improper types, though no additional values 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>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>.
<p>Note that the mass command can only be used if the <a class="reference internal" href="atom_style.html"><span class="doc">atom style</span></a> requires per-type atom mass to be set.
Currently, all but the <em>sphere</em> and <em>ellipsoid</em> and <em>peri</em> styles do.
They require mass to be set for individual particles, not types.
Per-atom masses are defined in the data file read by the
<a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command, or set to default values by the
<a class="reference internal" href="create_atoms.html"><span class="doc">create_atoms</span></a> command. Per-atom masses can also be
set to new values by the <a class="reference internal" href="set.html"><span class="doc">set mass</span></a> or <a class="reference internal" href="set.html"><span class="doc">set density</span></a>
commands.</p>
<p>Also note that <a class="reference internal" href="pair_eam.html"><span class="doc">pair_style eam</span></a> and <a class="reference internal" href="pair_bop.html"><span class="doc">pair_style bop</span></a> commands define the masses of atom types in their
respective potential files, in which case the mass command is normally
not used.</p>
<p>If you define a <a class="reference internal" href="atom_style.html"><span class="doc">hybrid atom style</span></a> which includes one
(or more) sub-styles which require per-type mass and one (or more)
sub-styles which require per-atom mass, then you must define both.
However, in this case the per-type mass will be ignored; only the
per-atom mass will be used by LAMMPS.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This command must come after the simulation box is defined by a
<p>All masses must be defined before a simulation is run. They must also
all be defined before a <a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> or <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command is used.</p>
<p>The mass assigned to any type or atom must be > 0.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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>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>.
<li>Rc = global cutoff, -1 means cutoff of half the shortest box length</li>
<li>zero or more keyword/value pairs may be appended</li>
<li>keyword = <em>hartree</em> or <em>dproduct</em> or <em>uhf</em> or <em>free</em> or <em>pbc</em> or <em>fix</em> or <em>harm</em> or <em>ermscale</em> or <em>flex_press</em></li>
</ul>
<pre class="literal-block">
<em>hartree</em> value = none
<em>dproduct</em> value = none
<em>uhf</em> value = none
<em>free</em> value = none
<em>pbc</em> value = Plen
Plen = periodic width of electron = -1 or positive value (distance units)
<em>fix</em> value = Flen
Flen = fixed width of electron = -1 or positive value (distance units)
<em>harm</em> value = width
width = harmonic width constraint
<em>ermscale</em> value = factor
factor = scaling between electron mass and width variable mass
<p>This pair style contains an implementation of the Antisymmetrized Wave
Packet Molecular Dynamics (AWPMD) method. Need citation here. Need
basic formulas here. Could be links to other documents.</p>
<p>Rc is the cutoff.</p>
<p>The pair_style command allows for several optional keywords
to be specified.</p>
<p>The <em>hartree</em>, <em>dproduct</em>, and <em>uhf</em> keywords specify the form of the
initial trial wave function for the system. If the <em>hartree</em> keyword
is used, then a Hartree multielectron trial wave function is used. If
the <em>dproduct</em> keyword is used, then a trial function which is a
product of two determinants for each spin type is used. If the <em>uhf</em>
keyword is used, then an unrestricted Hartree-Fock trial wave function
is used.</p>
<p>The <em>free</em>, <em>pbc</em>, and <em>fix</em> keywords specify a width constraint on
the electron wavepackets. If the <em>free</em> keyword is specified, then there is no
constraint. If the <em>pbc</em> keyword is used and <em>Plen</em> is specified as
-1, then the maximum width is half the shortest box length. If <em>Plen</em>
is a positive value, then the value is the maximum width. If the
<em>fix</em> keyword is used and <em>Flen</em> is specified as -1, then electrons
have a constant width that is read from the data file. If <em>Flen</em> is a
positive value, then the constant width for all electrons is set to
<em>Flen</em>.</p>
<p>The <em>harm</em> keyword allow oscillations in the width of the
electron wavepackets. More details are needed.</p>
<p>The <em>ermscale</em> keyword specifies a unitless scaling factor
between the electron masses and the width variable mass. More
details needed.</p>
<p>If the <em>flex_press</em> keyword is used, then a contribution from the
electrons is added to the total virial and pressure of the system.</p>
<p>This potential is designed to be used with <a class="reference internal" href="atom_style.html"><span class="doc">atom_style wavepacket</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>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 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>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>.
<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>.
% set LAMMPS_POTENTIALS="C:\Path to LAMMPS\Potentials"
</pre>
<hr class="docutils" />
<p>The alphabetic list of pair styles defined in LAMMPS is given on the
<a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> doc page. 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
<p>Note that there are also additional pair styles (not listed on the
<a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> doc page) submitted by users which are
included in the LAMMPS distribution. 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>
<p>There are also additional accelerated pair styles (not listed on the
<a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> doc page) 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>
</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>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>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>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>This pair style is a wrapper on the <a class="reference external" href="https://openkim.org">Knowledge Base for Interatomic Models (KIM)</a> repository of interatomic potentials,
so that they can be used by LAMMPS scripts.</p>
<p>In KIM lingo, a potential is a “model” and a model contains both the
analytic formulas that define the potential as well as the parameters
needed to run it for one or more materials, including coefficients and
cutoffs.</p>
<p>The argument <em>virialmode</em> determines how the global virial is
calculated. If <em>KIMvirial</em> is specified, the KIM model performs the
global virial calculation (if it knows how). If <em>LAMMPSvirial</em> is
specified, LAMMPS computes the global virial using its fdotr mechanism.</p>
<p>The argument <em>model</em> is the name of the KIM model for a specific
potential as KIM defines it. In principle, LAMMPS can invoke any KIM
model. You should get an error or warning message from either LAMMPS
or KIM if there is an incompatibility.</p>
<p>The argument <em>printflag</em> is optional. If it is set to a non-zero
value then a KIM dsecriptor file is printed when KIM is invoked. This
can be useful for debugging. The default is to not print this file.</p>
<p>Only a single pair_coeff command is used with the <em>kim</em> style which
specifies the mapping of LAMMPS atom types to KIM elements. This is
done by specifying N additional arguments after the * * in the
pair_coeff command, where N is the number of LAMMPS atom types:</p>
<ul class="simple">
<li>N element names = mapping of KIM elements to atom types</li>
</ul>
<p>As an example, imagine the KIM model supports Si and C atoms. If your
LAMMPS simulation has 4 atom types and you want the 1st 3 to be Si,
and the 4th to be C, you would use the following pair_coeff command:</p>
<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 KIM stores the potential parameters.
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 KIM 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 current version of pair_style kim is compatible with 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 C argument maps LAMMPS atom type 1 to the C element in the
LCBOP file. If a mapping value is specified as NULL, the mapping is
not performed. This can be used when a <em>lcbop</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 LCBOP potential as applied to C
are listed in the C.lcbop file to agree with the original <a class="reference internal" href="#los"><span class="std std-ref">(Los and Fasolino)</span></a> paper. Thus the parameters are specific to this
potential and the way it was fit, so modifying the file should be done
<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>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>.
<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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>.
<p>The <em>smd/tlsph</em> style computes particle interactions according to continuum mechanics constitutive laws and a Total-Lagrangian Smooth-Particle Hydrodynamics algorithm.</p>
<p>This pair style is invoked with the following command:</p>
+pair_coeff i j *COMMON rho0 E nu Q1 Q2 hg Cp &
+ *END
+</pre>
<p>Here, <em>i</em> and <em>j</em> denote the <em>LAMMPS</em> particle types for which this pair style is
defined. Note that <em>i</em> and <em>j</em> must be equal, i.e., no <em>tlsph</em> cross interactions
between different particle types are allowed.
In contrast to the usual <em>LAMMPS</em> <em>pair coeff</em> definitions, which are given solely a
number of floats and integers, the <em>tlsph</em> <em>pair coeff</em> definition is organised using
keywords. These keywords mark the beginning of different sets of parameters for particle properties,
material constitutive models, and damage models. The <em>pair coeff</em> line must be terminated with
-the <a href="#id5"><span class="problematic" id="id6">**</span></a>END* keyword. The use the line continuation operator <em>&</em> is recommended. A typical
+the <em>*END</em> keyword. The use the line continuation operator <em>&</em> is recommended. A typical
invocation of the <em>tlsph</em> for a solid body would consist of an equation of state for computing
the pressure (the diagonal components of the stress tensor), and a material model to compute shear
stresses (the off-diagonal components of the stress tensor). Damage and failure models can also be added.</p>
<p>Please see the <a class="reference external" href="USER/smd/SMD_LAMMPS_userguide.pdf">SMD user guide</a> for a complete listing of the possible keywords and material models.</p>
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>.
-<p>keyword = <a href="#id1"><span class="problematic" id="id2">**</span></a>DENSITY_SUMMATION* or <a href="#id3"><span class="problematic" id="id4">**</span></a>DENSITY_CONTINUITY* and <a href="#id5"><span class="problematic" id="id6">**</span></a>VELOCITY_GRADIENT* or <a href="#id7"><span class="problematic" id="id8">**</span></a>NO_VELOCITY_GRADIENT* and <a href="#id9"><span class="problematic" id="id10">**</span></a>GRADIENT_CORRECTION* or <a href="#id11"><span class="problematic" id="id12">**</span></a>NO_GRADIENT_CORRECTION*</p>
+<p>keyword = <em>*DENSITY_SUMMATION</em> or <em>*DENSITY_CONTINUITY</em> and <em>*VELOCITY_GRADIENT</em> or <em>*NO_VELOCITY_GRADIENT</em> and <em>*GRADIENT_CORRECTION</em> or <em>*NO_GRADIENT_CORRECTION</em></p>
<p>The <em>smd/ulsph</em> style computes particle interactions according to continuum mechanics constitutive laws and an updated Lagrangian Smooth-Particle Hydrodynamics algorithm.</p>
<p>This pair style is invoked similar to the following command:</p>
<p>Here, <em>i</em> and <em>j</em> denote the <em>LAMMPS</em> particle types for which this pair style is
defined. Note that <em>i</em> and <em>j</em> can be different, i.e., <em>ulsph</em> cross interactions
between different particle types are allowed. However, <em>i</em>–<em>i</em> respectively <em>j</em>–<em>j</em> pair_coeff lines have to preceed a cross interaction.
In contrast to the usual <em>LAMMPS</em> <em>pair coeff</em> definitions, which are given solely a
number of floats and integers, the <em>ulsph</em> <em>pair coeff</em> definition is organised using
keywords. These keywords mark the beginning of different sets of parameters for particle properties,
material constitutive models, and damage models. The <em>pair coeff</em> line must be terminated with
-the <a href="#id29"><span class="problematic" id="id30">**</span></a>END* keyword. The use the line continuation operator <em>&</em> is recommended. A typical
+the <em>*END</em> keyword. The use the line continuation operator <em>&</em> is recommended. A typical
invocation of the <em>ulsph</em> for a solid body would consist of an equation of state for computing
the pressure (the diagonal components of the stress tensor), and a material model to compute shear
stresses (the off-diagonal components of the stress tensor).</p>
-<p>Note that the use of <a href="#id31"><span class="problematic" id="id32">*</span></a>GRADIENT_CORRECTION can lead to severe numerical instabilities. For a general fluid simulation, <a href="#id33"><span class="problematic" id="id34">*</span></a>NO_GRADIENT_CORRECTION is recommended.</p>
+<p>Note that the use of *GRADIENT_CORRECTION can lead to severe numerical instabilities. For a general fluid simulation, *NO_GRADIENT_CORRECTION is recommended.</p>
<p>Please see the <a class="reference external" href="USER/smd/SMD_LAMMPS_userguide.pdf">SMD user guide</a> for a complete listing of the possible keywords and material models.</p>
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>As noted above, the Lennard-Jones parameters epsilon and sigma are set
to unity.</p>
<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>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>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="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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>The 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>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 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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>.
<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>.
so that all atoms in the restart file are inside the simulation box.
If this is not the case, the read_restart command will print an error
that atoms were “lost” when the file is read. This error should be
reported to the LAMMPS developers so the invalid writing of the
restart file can be fixed. If you still wish to use the restart file,
the optional <em>remap</em> flag can be appended to the read_restart command.
This should avoid the error, by explicitly remapping each atom back
into the simulation box, updating image flags for the atom
appropriately.</p>
</div>
<p>Restart files are saved in binary format to enable exact restarts,
meaning that the trajectories of a restarted run will precisely match
those produced by the original run had it continued on.</p>
<p>Several things can prevent exact restarts due to round-off effects, in
which case the trajectories in the 2 runs will slowly diverge. These
include running on a different number of processors or changing
certain settings such as those set by the <a class="reference internal" href="newton.html"><span class="doc">newton</span></a> or
<a class="reference internal" href="processors.html"><span class="doc">processors</span></a> commands. LAMMPS will issue a warning in
these cases.</p>
<p>Certain fixes will not restart exactly, though they should provide
statistically similar results. These include <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> and <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a>.</p>
<p>Certain pair styles will not restart exactly, though they should
provide statistically similar results. This is because the forces
they compute depend on atom velocities, which are used at half-step
values every timestep when forces are computed. When a run restarts,
forces are initially evaluated with a full-step velocity, which is
different than if the run had continued. These pair styles include
<p>If a restarted run is immediately different than the run which
produced the restart file, it could be a LAMMPS bug, so consider
<a class="reference internal" href="Section_errors.html#err-2"><span class="std std-ref">reporting it</span></a> if you think the behavior is
wrong.</p>
<p>Because restart files are binary, they may not be portable to other
machines. In this case, you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-restart command-line switch</span></a> to convert a restart file to a data
file.</p>
<p>Similar to how restart files are written (see the
<p>As indicated in the above list, the <a class="reference internal" href="fix.html"><span class="doc">fixes</span></a> used for a
simulation are not stored in the restart file. This means the new
input script should specify all fixes it will use. However, note that
some fixes store an internal “state” which is written to the restart
file. This allows the fix to continue on with its calculations in a
restarted simulation. To re-enable such a fix, the fix command in the
new input script must use the same fix-ID and group-ID as was used in
the input script that wrote the restart file. If a match is found,
LAMMPS prints a message indicating that the fix is being re-enabled.
If no match is found before the first run or minimization is performed
by the new script, the “state” information for the saved fix is
discarded. See the doc pages for individual fixes for info on which
ones can be restarted in this manner.</p>
<p>Likewise, the <a class="reference internal" href="fix.html"><span class="doc">computes</span></a> used for a simulation are not stored
in the restart file. This means the new input script should specify
all computes it will use. However, some computes create a fix
internally to store “state” information that persists from timestep to
timestep. An example is the <a class="reference internal" href="compute_msd.html"><span class="doc">compute msd</span></a> command
which uses a fix to store a reference coordinate for each atom, so
that a displacement can be calculated at any later time. If the
compute command in the new input script uses the same compute-ID and
group-ID as was used in the input script that wrote the restart file,
then it will create the same fix in the restarted run. This means the
re-created fix will be re-enabled with the stored state information as
described in the previous paragraph, so that the compute can continue
its calculations in a consistent manner.</p>
<p>Some pair styles, like the <a class="reference internal" href="pair_gran.html"><span class="doc">granular pair styles</span></a>, also
use a fix to store “state” information that persists from timestep to
timestep. In the case of granular potentials, it is contact
information between pairs of touching particles. This info will also
be re-enabled in the restart script, assuming you re-use the same
granular pair style.</p>
<p>LAMMPS allows bond interactions (angle, etc) to be turned off or
deleted in various ways, which can affect how their info is stored in
a restart file.</p>
<p>If bonds (angles, etc) have been turned off by 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> command,
their info will be written to a restart file as if they are turned on.
This means they will need to be turned off again in a new run after
the restart file is read.</p>
<p>Bonds that are broken (e.g. by a bond-breaking potential) are written
to the restart file as broken bonds with a type of 0. Thus these
bonds will still be broken when the restart file is read.</p>
<p>Bonds that have been broken by the <a class="reference internal" href="fix_bond_break.html"><span class="doc">fix bond/break</span></a> command have disappeared from the
system. No information about these bonds is written to the 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>.
commands set the timestep to 0; the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
command sets the timestep to the value it had when the restart file
was written.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<blockquote>
<div>none</div></blockquote>
<p>This command cannot be used when any fixes are defined that keep track
of elapsed time to perform certain kinds of time-dependent operations.
Examples are the <a class="reference internal" href="fix_deposit.html"><span class="doc">fix deposit</span></a> and <a class="reference internal" href="fix_dt_reset.html"><span class="doc">fix dt/reset</span></a> commands. The former adds atoms on
specific timesteps. The latter keeps track of accumulated time.</p>
<p>Various fixes use the current timestep to calculate related
quantities. If the timestep is reset, this may produce unexpected
behavior, but LAMMPS allows the fixes to be defined even if the
timestep is reset. For example, commands which thermostat the system,
e.g. <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>, allow you to specify a target temperature
which ramps from Tstart to Tstop which may persist over several runs.
If you change the timestep, you may induce an instantaneous change in
the target temperature.</p>
<p>Resetting the timestep clears flags for <a class="reference internal" href="compute.html"><span class="doc">computes</span></a> that
may have calculated some quantity from a previous run. This means
these quantity cannot be accessed by a variable in between runs until
a new run is performed. See the <a class="reference internal" href="variable.html"><span class="doc">variable</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>.
<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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>.
<li>one or more keyword/value pairs may be listed</li>
</ul>
<pre class="literal-block">
keyword = <em>lost</em> or <em>lost/bond</em> or <em>norm</em> or <em>flush</em> or <em>line</em> or <em>format</em> or <em>temp</em> or <em>press</em>:l
<em>lost</em> value = <em>error</em> or <em>warn</em> or <em>ignore</em>
<em>lost/bond</em> value = <em>error</em> or <em>warn</em> or <em>ignore</em>
<em>norm</em> value = <em>yes</em> or <em>no</em>
<em>flush</em> value = <em>yes</em> or <em>no</em>
<em>line</em> value = <em>one</em> or <em>multi</em>
<em>format</em> values = <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 quantities being output
<em>temp</em> value = compute ID that calculates a temperature
<em>press</em> value = compute ID that calculates a pressure
+thermo_modify temp myTemp format line "%ld %g %g %15.8g"
+thermo_modify line multi format float %g
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Set options for how thermodynamic information is computed and printed
by LAMMPS.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">These options apply to the currently defined thermo style. When
you specify a <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command, all
thermodynamic settings are restored to their default values, including
those previously reset by a thermo_modify command. Thus if your input
script specifies a thermo_style command, you should use the
thermo_modify command after it.</p>
</div>
<p>The <em>lost</em> keyword determines whether LAMMPS checks for lost atoms
each time it computes thermodynamics and what it does if atoms are
lost. An atom can be “lost” if it moves across a non-periodic
simulation box <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> or if it moves more than a box
length outside the simulation domain (or more than a processor
sub-domain length) before reneighboring occurs. The latter case is
typically due to bad dynamics, e.g. too large a timestep or huge
forces and velocities. If the value is <em>ignore</em>, LAMMPS does not
check for lost atoms. If the value is <em>error</em> or <em>warn</em>, LAMMPS
checks and either issues an error or warning. The code will exit with
an error and continue with a warning. A warning will only be issued
once, the first time an atom is lost. This can be a useful debugging
option.</p>
<p>The <em>lost/bond</em> keyword determines whether LAMMPS throws an error or
not if an atom in a bonded interaction (bond, angle, etc) cannot be
found when it creates bonded neighbor lists. By default this is a
fatal error. However in some scenarios it may be desirable to only
issue a warning or ignore it and skip the computation of the missing
bond, angle, etc. An example would be when gas molecules in a vapor
are drifting out of the box through a fixed boundary condition (see
the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command). In this case one atom may be
deleted before the rest of the molecule is, on a later timestep.</p>
<p>The <em>norm</em> keyword determines whether various thermodynamic output
values are normalized by the number of atoms or not, depending on
whether it is set to <em>yes</em> or <em>no</em>. Different unit styles have
different defaults for this setting (see below). Even if <em>norm</em> is
set to <em>yes</em>, a value is only normalized if it is an “extensive”
quantity, meaning that it scales with the number of atoms in the
system. For the thermo keywords described by the doc page for the
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command, all energy-related keywords
are extensive, such as <em>pe</em> or <em>ebond</em> or <em>enthalpy</em>. Other keywords
such as <em>temp</em> or <em>press</em> are “intensive” meaning their value is
independent (in a statistical sense) of the number of atoms in the
system and thus are never normalized. For thermodynamic output values
extracted from fixes and computes in a <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command, the doc page for the individual
<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> lists whether the value is
“extensive” or “intensive” and thus whether it is normalized.
Thermodynamic output values calculated by a variable formula are
assumed to be “intensive” and thus are never normalized. You can
always include a divide by the number of atoms in the variable formula
if this is not the case.</p>
<p>The <em>flush</em> keyword invokes a flush operation after thermodynamic info
is written to the log file. This insures the output in that file is
current (no buffering by the OS), even if LAMMPS halts before the
simulation completes.</p>
<p>The <em>line</em> keyword determines whether thermodynamics will be output as
a series of numeric values on one line or in a multi-line format with
3 quantities with text strings per line and a dashed-line header
containing the timestep and CPU time. This modify option overrides
the <em>one</em> and <em>multi</em> thermo_style settings.</p>
<p>The <em>format</em> keyword can be used to change the default numeric format
of any of quantities the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command
outputs. 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 the entire line of
thermo output, 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>
<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">The thermo output values <em>step</em> and <em>atoms</em> are stored
internally as 8-byte signed integers, rather than the usual 4-byte
signed integers. 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 when it is applied to
those keywords. However, when specifying the <em>line</em> option or <em>format
M string</em> option for <em>step</em> and <em>natoms</em>, you should specify a format
string appropriate for an 8-byte signed integer, e.g. one with “%ld”.</p>
</div>
<p>The <em>temp</em> keyword is used to determine how thermodynamic temperature
is calculated, which is used by all thermo quantities that require a
temperature (“temp”, “press”, “ke”, “etotal”, “enthalpy”, “pxx”, etc).
The specified compute ID must have been previously defined by the user
via the <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command and it must be a style of
compute that calculates a temperature. As described in the
compute for pressure with ID = <em>thermo_press</em>. This option allows the
user to override the default.</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 thermodynamics), 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
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>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>.
<p>Write a data file in text format of the current state of the
simulation. Data files can be read by the <a class="reference internal" href="read_data.html"><span class="doc">read data</span></a>
command to begin a simulation. The <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command
also describes their format.</p>
<p>Similar to <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> files, the data filename can contain a “*”
wild-card character. The “*” is replaced with the current timestep
value.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The write-data command is not yet fully implemented in two
respects. First, most pair styles do not yet write their coefficient
information into the data file. This means you will need to specify
that information in your input script that reads the data file, via
the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command. Second, a few of the <a class="reference internal" href="atom_style.html"><span class="doc">atom styles</span></a> (body, ellipsoid, line, tri) that store
auxiliary “bonus” information about aspherical particles, do not yet
write the bonus info into the data file. Both these functionalities
will be added to the write_data command later.</p>
</div>
<p>Because a data file is in text format, if you use a data file written
out by this command to restart a simulation, the initial state of the
new run will be slightly different than the final state of the old run
(when the file was written) which was represented internally by LAMMPS
in binary format. A new simulation which reads the data file will
thus typically diverge from a simulation that continued in the
original input script.</p>
<p>If you want to do more exact restarts, using binary files, see the
<p>Bond interactions (angle, etc) that have been turned off by 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> command will
be written to a data file as if they are turned on. This means they
will need to be turned off again in a new run after the data file is
read.</p>
<p>Bonds that are broken (e.g. by a bond-breaking potential) are not
written to the data file. Thus these bonds will not exist when the
data file is read.</p>
<hr class="docutils" />
<p>The <em>nocoeff</em> keyword requests that no force field parameters should
be written to the data file. This can be very helpful, if one wants
to make significant changes to the force field or if the parameters
are read in separately anyway, e.g. from an include file.</p>
<p>The <em>pair</em> keyword lets you specify in what format the pair
coefficient information is written into the data file. If the value
is specified as <em>ii</em>, then one line per atom type is written, to
specify the coefficients for each of the I=J interactions. This means
that no cross-interactions for I != J will be specified in the data
file and the pair style will apply its mixing rule, as documented on
individual <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> doc pages. Of course this
behavior can be overridden in the input script after reading the data
file, by specifying additional <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> commands
for any desired I,J pairs.</p>
<p>If the value is specified as <em>ij</em>, then one line of coefficients is
written for all I,J pairs where I <= J. These coefficients will
include any specific settings made in the input script up to that
point. The presence of these I != J coefficients in the data file
will effectively turn off the default mixing rule for the pair style.
Again, the coefficient values in the data file can can be overridden
in the input script after reading the data file, by specifying
additional <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> commands for any desired I,J
pairs.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This command requires inter-processor communication to migrate atoms
before the data file is written. This means that your system must be
ready to perform a simulation before using this command (force fields
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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 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. Details are usually given in the
documentation of the respective command. Also, see the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for general 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.
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>This command requires inter-processor communication to migrate atoms
before the restart file is written. This means that your system must
be ready to perform a simulation before using this command (force
fields setup, atom masses initialized, etc).</p>
<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>.