<p>The LAMMPS “version” is the date when it was released, such as 1 May
2010. LAMMPS is updated continuously. Whenever we fix a bug or add a
feature, we release it immediately, and post a notice on <a class="reference external" href="http://lammps.sandia.gov/bug.html">this page of the WWW site</a>. Every 2-4 months one of the incremental releases
is subjected to more thorough testing and labeled as a <em>stable</em> version.</p>
<p>Each dated copy of LAMMPS contains all the
features and bug-fixes up to and including that version date. The
version date is printed to the screen and logfile every time you run
LAMMPS. It is also in the file src/version.h and in the LAMMPS
directory name created when you unpack a tarball, and at the top of
the first page of the manual (this page).</p>
<ul class="simple">
<li>If you browse the HTML doc pages on the LAMMPS WWW site, they always
describe the most current version of LAMMPS.</li>
<li>If you browse the HTML doc pages included in your tarball, they
describe the version you have.</li>
<li>The <a class="reference external" href="Manual.pdf">PDF file</a> on the WWW site or in the tarball is updated
about once per month. This is because it is large, and we don’t want
it to be part of every patch.</li>
<li>There is also a <a class="reference external" href="Developer.pdf">Developer.pdf</a> file in the doc
directory, which describes the internal structure and algorithms of
LAMMPS.</li>
</ul>
<p>LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel
Simulator.</p>
<p>LAMMPS is a classical molecular dynamics simulation code designed to
run efficiently on parallel computers. It was developed at Sandia
National Laboratories, a US Department of Energy facility, with
funding from the DOE. It is an open-source code, distributed freely
under the terms of the GNU Public License (GPL).</p>
<p>The current core group of LAMMPS developers is at Sandia National
Labs and Temple University:</p>
<ul class="simple">
<li><a class="reference external" href="http://www.sandia.gov/~sjplimp">Steve Plimpton</a>, sjplimp at sandia.gov</li>
<li>Aidan Thompson, athomps at sandia.gov</li>
<li>Stan Moore, stamoore at sandia.gov</li>
<li><a class="reference external" href="http://goo.gl/1wk0">Axel Kohlmeyer</a>, akohlmey at gmail.com</li>
</ul>
<p>Past core developers include Paul Crozier, Ray Shan and Mark Stevens,
all at Sandia. The <strong>LAMMPS home page</strong> at
<a class="reference external" href="http://lammps.sandia.gov">http://lammps.sandia.gov</a> has more information
about the code and its uses. Interaction with external LAMMPS developers,
bug reports and feature requests are mainly coordinated through the
-<a class="reference external" href="https://github.com/lammps/lammps">LAMMPS project on GitHub.</a></p>
+<a class="reference external" href="https://github.com/lammps/lammps">LAMMPS project on GitHub.</a>
+The lammps.org domain, currently hosting <a class="reference external" href="https://ci.lammps.org/job/lammps/">public continuous integration testing</a> and <a class="reference external" href="http://rpm.lammps.org">precompiled Linux RPM and Windows installer packages</a> is located
+at Temple University and managed by Richard Berger,
+richard.berger at temple.edu.</p>
<hr class="docutils" />
<p>The LAMMPS documentation is organized into the following sections. If
you find errors or omissions in this manual or have suggestions for
useful information to add, please send an email to the developers so
we can improve the LAMMPS documentation.</p>
<p>Once you are familiar with LAMMPS, you may want to bookmark <a class="reference internal" href="Section_commands.html#comm"><span class="std std-ref">this page</span></a> at Section_commands.html#comm since
it gives quick access to documentation for all LAMMPS commands.</p>
<p><a class="reference external" href="Manual.pdf">PDF file</a> of the entire manual, generated by
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#what-s-in-the-lammps-distribution">2.1. What’s in the LAMMPS distribution</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#making-lammps">2.2. Making LAMMPS</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#making-lammps-with-optional-packages">2.3. Making LAMMPS with optional packages</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#building-lammps-via-the-make-py-tool">2.4. Building LAMMPS via the Make.py tool</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#building-lammps-as-a-library">2.5. Building LAMMPS as a library</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#general-strategies">5.2. General strategies</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#packages-with-optimized-styles">5.3. Packages with optimized styles</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#comparison-of-various-accelerator-packages">5.4. Comparison of various accelerator packages</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#tip3p-water-model">6.7. TIP3P water model</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#tip4p-water-model">6.8. TIP4P water model</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#spc-water-model">6.9. SPC water model</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#coupling-lammps-to-other-codes">6.10. Coupling LAMMPS to other codes</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#calculating-a-diffusion-coefficient">6.22. Calculating a diffusion coefficient</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#using-chunks-to-calculate-system-properties">6.23. Using chunks to calculate system properties</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#setting-parameters-for-the-kspace-style-pppm-disp-command">6.24. Setting parameters for the <code class="docutils literal"><span class="pre">kspace_style</span> <span class="pre">pppm/disp</span></code> command</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#submitting-new-features-for-inclusion-in-lammps">10.15. Submitting new features for inclusion in LAMMPS</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a><ul>
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#overview-of-running-lammps-from-python">11.1. Overview of running LAMMPS from Python</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#overview-of-using-python-from-a-lammps-script">11.2. Overview of using Python from a LAMMPS script</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#building-lammps-as-a-shared-library">11.3. Building LAMMPS as a shared library</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#installing-the-python-wrapper-into-python">11.4. Installing the Python wrapper into Python</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#extending-python-with-mpi-to-run-in-parallel">11.5. Extending Python with MPI to run in parallel</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#testing-the-python-lammps-interface">11.6. Testing the Python-LAMMPS interface</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#using-lammps-from-python">11.7. Using LAMMPS from Python</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#example-python-scripts-that-use-lammps">11.8. Example Python scripts that use LAMMPS</a></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>.
<li class="toctree-l2"><a class="reference internal" href="#general-strategies">5.2. General strategies</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#packages-with-optimized-styles">5.3. Packages with optimized styles</a></li>
+<li class="toctree-l2"><a class="reference internal" href="#packages-with-optimized-styles">5.3. Packages with optimized styles</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="#gpu-package-with-cuda-and-opencl-support-for-nvidia-gpus-and-others">5.3.1. <code class="docutils literal"><span class="pre">GPU</span> <span class="pre">Package</span></code> with CUDA and OpenCL support for Nvidia GPUs and others</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#user-intel-package-for-intel-cpus-and-intel-xeon-phi">5.3.2. <code class="docutils literal"><span class="pre">USER-INTEL</span> <span class="pre">Package</span></code> for Intel CPUs and Intel Xeon Phi</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#kokkos-package-for-nvidia-gpus-intel-xeon-phi-and-openmp-threading">5.3.3. <code class="docutils literal"><span class="pre">KOKKOS</span> <span class="pre">Package</span></code> for Nvidia GPUs, Intel Xeon Phi, and OpenMP threading</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#user-omp-package-for-openmp-threading-and-generic-cpu-optimizations">5.3.4. <code class="docutils literal"><span class="pre">USER-OMP</span> <span class="pre">Package</span></code> for OpenMP threading and generic CPU optimizations</a></li>
<li class="toctree-l2"><a class="reference internal" href="#comparison-of-various-accelerator-packages">5.4. Comparison of various accelerator packages</a></li>
<p>Before trying to make your simulation run faster, you should
understand how it currently performs and where the bottlenecks are.</p>
<p>The best way to do this is run the your system (actual number of
atoms) for a modest number of timesteps (say 100 steps) on several
different processor counts, including a single processor if possible.
Do this for an equilibrium version of your system, so that the
100-step timings are representative of a much longer run. There is
typically no need to run for 1000s of timesteps to get accurate
timings; you can simply extrapolate from short runs.</p>
<p>For the set of runs, look at the timing data printed to the screen and
log file at the end of each LAMMPS run. <a class="reference internal" href="Section_start.html#start-8"><span class="std std-ref">This section</span></a> of the manual has an overview.</p>
<p>Running on one (or a few processors) should give a good estimate of
the serial performance and what portions of the timestep are taking
the most time. Running the same problem on a few different processor
counts should give an estimate of parallel scalability. I.e. if the
simulation runs 16x faster on 16 processors, its 100% parallel
efficient; if it runs 8x faster on 16 processors, it’s 50% efficient.</p>
<p>The most important data to look at in the timing info is the timing
breakdown and relative percentages. For example, trying different
options for speeding up the long-range solvers will have little impact
if they only consume 10% of the run time. If the pairwise time is
dominating, you may want to look at GPU or OMP versions of the pair
style, as discussed below. Comparing how the percentages change as
you increase the processor count gives you a sense of how different
operations within the timestep are scaling. Note that if you are
running with a Kspace solver, there is additional output on the
breakdown of the Kspace time. For PPPM, this includes the fraction
spent on FFTs, which can be communication intensive.</p>
<p>Another important detail in the timing info are the histograms of
atoms counts and neighbor counts. If these vary widely across
processors, you have a load-imbalance issue. This often results in
inaccurate relative timing data, because processors have to wait when
communication occurs for other processors to catch up. Thus the
reported times for “Communication” or “Other” may be higher than they
really are, due to load-imbalance. If this is an issue, you can
uncomment the MPI_Barrier() lines in src/timer.cpp, and recompile
LAMMPS, to obtain synchronized timings.</p>
<hr class="docutils" />
</div>
<div class="section" id="general-strategies">
<span id="acc-2"></span><h2>5.2. General strategies</h2>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">this section 5.2 is still a work in progress</p>
</div>
<p>Here is a list of general ideas for improving simulation performance.
Most of them are only applicable to certain models and certain
bottlenecks in the current performance, so let the timing data you
generate be your guide. It is hard, if not impossible, to predict how
much difference these options will make, since it is a function of
problem size, number of processors used, and your machine. There is
no substitute for identifying performance bottlenecks, and trying out
various options.</p>
<ul class="simple">
<li>rRESPA</li>
<li>2-FFT PPPM</li>
<li>Staggered PPPM</li>
<li>single vs double PPPM</li>
<li>partial charge PPPM</li>
<li>verlet/split run style</li>
<li>processor command for proc layout and numa layout</li>
<li>load-balancing: balance and fix balance</li>
</ul>
<p>2-FFT PPPM, also called <em>analytic differentiation</em> or <em>ad</em> PPPM, uses
2 FFTs instead of the 4 FFTs used by the default <em>ik differentiation</em>
PPPM. However, 2-FFT PPPM also requires a slightly larger mesh size to
achieve the same accuracy as 4-FFT PPPM. For problems where the FFT
cost is the performance bottleneck (typically large problems running
on many processors), 2-FFT PPPM may be faster than 4-FFT PPPM.</p>
<p>Staggered PPPM performs calculations using two different meshes, one
shifted slightly with respect to the other. This can reduce force
aliasing errors and increase the accuracy of the method, but also
doubles the amount of work required. For high relative accuracy, using
staggered PPPM allows one to half the mesh size in each dimension as
compared to regular PPPM, which can give around a 4x speedup in the
kspace time. However, for low relative accuracy, using staggered PPPM
gives little benefit and can be up to 2x slower in the kspace
time. For example, the rhodopsin benchmark was run on a single
processor, and results for kspace time vs. relative accuracy for the
different methods are shown in the figure below. For this system,
staggered PPPM (using ik differentiation) becomes useful when using a
relative accuracy of slightly greater than 1e-5 and above.</p>
<span id="acc-3"></span><h2>5.3. Packages with optimized styles</h2>
<p>Accelerated versions of various <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a>,
<a class="reference internal" href="fix.html"><span class="doc">fixes</span></a>, <a class="reference internal" href="compute.html"><span class="doc">computes</span></a>, and other commands have
been added to LAMMPS, which will typically run faster than the
standard non-accelerated versions. Some require appropriate hardware
to be present on your system, e.g. GPUs or Intel Xeon Phi
coprocessors.</p>
<p>All of these commands are in packages provided with LAMMPS. An
overview of packages is give in <a class="reference internal" href="Section_packages.html"><span class="doc">Section packages</span></a>.</p>
<p>These are the accelerator packages
currently in LAMMPS, either as standard or user packages:</p>
+<h3>5.3.1. <a class="reference internal" href="accelerate_gpu.html"><span class="doc">GPU Package</span></a> with CUDA and OpenCL support for Nvidia GPUs and others</h3>
+<h3>5.3.4. <a class="reference internal" href="accelerate_omp.html"><span class="doc">USER-OMP Package</span></a> for OpenMP threading and generic CPU optimizations</h3>
<tr class="row-even"><td>enable specific accelerator support via ‘-k on’ <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>,</td>
<td>only needed for KOKKOS package</td>
</tr>
<tr class="row-odd"><td>set any needed options for the package via “-pk” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> or <a class="reference internal" href="package.html"><span class="doc">package</span></a> command,</td>
<td>only if defaults need to be changed</td>
</tr>
<tr class="row-even"><td>use accelerated styles in your input via “-sf” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> or <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command</td>
<td>lmp_machine -in in.script -sf gpu</td>
</tr>
</tbody>
</table>
<p>Note that the first 4 steps can be done as a single command, using the
src/Make.py tool. This tool is discussed in <a class="reference internal" href="Section_start.html#start-4"><span class="std std-ref">Section 2.4</span></a> of the manual, and its use is
illustrated in the individual accelerator sections. Typically these
steps only need to be done once, to create an executable that uses one
or more accelerator packages.</p>
<p>The last 4 steps can all be done from the command-line when LAMMPS is
launched, without changing your input script, as illustrated in the
individual accelerator sections. Or you can add
<a class="reference internal" href="package.html"><span class="doc">package</span></a> and <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> commands to your input
script.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">With a few exceptions, you can build a single LAMMPS executable
with all its accelerator packages installed. Note however that the
USER-INTEL and KOKKOS packages require you to choose one of their
hardware options when building for a specific platform. I.e. CPU or
Phi option for the USER-INTEL package. Or the OpenMP, Cuda, or Phi
option for the KOKKOS package.</p>
</div>
<p>These are the exceptions. You cannot build a single executable with:</p>
<ul class="simple">
<li>both the USER-INTEL Phi and KOKKOS Phi options</li>
<li>the USER-INTEL Phi or Kokkos Phi option, and the GPU package</li>
</ul>
<p>See the examples/accelerate/README and make.list files for sample
Make.py commands that build LAMMPS with any or all of the accelerator
packages. As an example, here is a command that builds with all the
GPU related packages installed (GPU, KOKKOS with Cuda), including
settings to build the needed auxiliary GPU libraries for Kepler GPUs:</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<a class="reference internal" href="if.html"><span class="doc">if</span></a>, and <a class="reference internal" href="python.html"><span class="doc">python</span></a> commands for examples.</p>
<p>A “#” or “$” character that is between quotes will not be treated as a
comment indicator in (2) or substituted for as a variable in (3).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If the argument is itself a command that requires a quoted
argument (e.g. using a <a class="reference internal" href="print.html"><span class="doc">print</span></a> command as part of an
<a class="reference internal" href="if.html"><span class="doc">if</span></a> or <a class="reference internal" href="run.html"><span class="doc">run every</span></a> command), then single, double, or
triple quotes can be nested in the usual manner. See the doc pages
for those commands for examples. Only one of level of nesting is
allowed, but that should be sufficient for most use cases.</p>
<p>This section describes the structure of a typical LAMMPS input script.
The “examples” directory in the LAMMPS distribution contains many
sample input scripts; the corresponding problems are discussed in
-<a class="reference internal" href="Section_example.html"><span class="doc">Section_example</span></a>, and animated on the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>.</p>
+<a class="reference internal" href="Section_example.html"><span class="doc">Section 7</span></a>, and animated on the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>.</p>
<p>A LAMMPS input script typically has 4 parts:</p>
<ol class="arabic simple">
<li>Initialization</li>
<li>Atom definition</li>
<li>Settings</li>
<li>Run a simulation</li>
</ol>
<p>The last 2 parts can be repeated as many times as desired. I.e. run a
simulation, change some settings, run some more, etc. Each of the 4
parts is now described in more detail. Remember that almost all the
commands need only be used if a non-default value is desired.</p>
<ol class="arabic simple">
<li>Initialization</li>
</ol>
<p>Set parameters that need to be defined before atoms are created or
read-in from a file.</p>
<p>The relevant commands are <a class="reference internal" href="units.html"><span class="doc">units</span></a>,
<p>Output options are set by the <a class="reference internal" href="thermo.html"><span class="doc">thermo</span></a>, <a class="reference internal" href="dump.html"><span class="doc">dump</span></a>,
and <a class="reference internal" href="restart.html"><span class="doc">restart</span></a> commands.</p>
<ol class="arabic simple" start="4">
<li>Run a simulation</li>
</ol>
<p>A molecular dynamics simulation is run using the <a class="reference internal" href="run.html"><span class="doc">run</span></a>
command. Energy minimization (molecular statics) is performed using
the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command. A parallel tempering
(replica-exchange) simulation can be run using the
<p>This section lists all LAMMPS commands alphabetically, with a separate
listing below of styles within certain commands. The <a class="reference internal" href="#cmd-4"><span class="std std-ref">previous section</span></a> lists the same commands, grouped by category. Note
that some style options for some commands are part of specific LAMMPS
packages, which means they cannot be used unless the package was
included when LAMMPS was built. Not all packages are included in a
default LAMMPS build. These dependencies are listed as Restrictions
<p>See the <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command for one-line descriptions of
each style or click on the style itself for a full description. Some
of the styles have accelerated versions, which can be used if LAMMPS
is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k =
<p>These are additional compute styles in USER packages, which can be
used if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> command for an overview of pair
potentials. Click on the style itself for a full description. Many
of the styles have accelerated versions, which can be used if LAMMPS
is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k =
<p>These are additional pair styles in USER packages, which can be used
if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="bond_style.html"><span class="doc">bond_style</span></a> command for an overview of bond
potentials. Click on the style itself for a full description. Some
of the styles have accelerated versions, which can be used if LAMMPS
is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k =
<p>These are additional bond styles in USER packages, which can be used
if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="angle_style.html"><span class="doc">angle_style</span></a> command for an overview of
angle potentials. Click on the style itself for a full description.
Some of the styles have accelerated versions, which can be used if
LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
<p>These are additional angle styles in USER packages, which can be used
if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="dihedral_style.html"><span class="doc">dihedral_style</span></a> command for an overview
of dihedral potentials. Click on the style itself for a full
description. Some of the styles have accelerated versions, which can
be used if LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
<p>These are additional dihedral styles in USER packages, which can be
used if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="improper_style.html"><span class="doc">improper_style</span></a> command for an overview
of improper potentials. Click on the style itself for a full
description. Some of the styles have accelerated versions, which can
be used if LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
<p>These are additional improper styles in USER packages, which can be
used if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command for an overview of
Kspace solvers. Click on the style itself for a full description.
Some of the styles have accelerated versions, which can be used if
LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<span id="err-1"></span><h2>12.1. Common problems</h2>
<p>If two LAMMPS runs do not produce the same answer on different
machines or different numbers of processors, this is typically not a
bug. In theory you should get identical answers on any number of
processors and on any machine. In practice, numerical round-off can
cause slight differences and eventual divergence of molecular dynamics
phase space trajectories within a few 100s or few 1000s of timesteps.
However, the statistical properties of the two runs (e.g. average
energy or temperature) should still be the same.</p>
<p>If the <a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> command is used to set initial atom
velocities, a particular atom can be assigned a different velocity
when the problem is run on a different number of processors or on
different machines. If this happens, the phase space trajectories of
the two simulations will rapidly diverge. See the discussion of the
<em>loop</em> option in the <a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> command for details and
options that avoid this issue.</p>
<p>Similarly, the <a class="reference internal" href="create_atoms.html"><span class="doc">create_atoms</span></a> command generates a
lattice of atoms. For the same physical system, the ordering and
numbering of atoms by atom ID may be different depending on the number
of processors.</p>
<p>Some commands use random number generators which may be setup to
produce different random number streams on each processor and hence
will produce different effects when run on different numbers of
processors. A commonly-used example is the <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> command for thermostatting.</p>
<p>A LAMMPS simulation typically has two stages, setup and run. Most
LAMMPS errors are detected at setup time; others like a bond
stretching too far may not occur until the middle of a run.</p>
<p>LAMMPS tries to flag errors and print informative error messages so
you can fix the problem. Of course, LAMMPS cannot figure out your
physics or numerical mistakes, like choosing too big a timestep,
specifying erroneous force field coefficients, or putting 2 atoms on
top of each other! If you run into errors that LAMMPS doesn’t catch
that you think it should flag, please send an email to the
<p>If you get an error message about an invalid command in your input
script, you can determine what command is causing the problem by
looking in the log.lammps file or using the <a class="reference internal" href="echo.html"><span class="doc">echo command</span></a>
to see it on the screen. If you get an error like “Invalid ...
style”, with ... being fix, compute, pair, etc, it means that you
mistyped the style name or that the command is part of an optional
package which was not compiled into your executable. The list of
available styles in your executable can be listed by using <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">the -h command-line argument</span></a>. The installation
and compilation of optional packages is explained in the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">installation instructions</span></a>.</p>
<p>For a given command, LAMMPS expects certain arguments in a specified
order. If you mess this up, LAMMPS will often flag the error, but it
may also simply read a bogus argument and assign a value that is
valid, but not what you wanted. E.g. trying to read the string “abc”
as an integer value of 0. Careful reading of the associated doc page
for the command should allow you to fix these problems. Note that
some commands allow for variables to be specified in place of numeric
constants so that the value can be evaluated and change over the
course of a run. This is typically done with the syntax <em>v_name</em> for
a parameter, where name is the name of the variable. This is only
allowed if the command documentation says it is.</p>
<p>Generally, LAMMPS will print a message to the screen and logfile and
exit gracefully when it encounters a fatal error. Sometimes it will
print a WARNING to the screen and logfile and continue on; you can
decide if the WARNING is important or not. A WARNING message that is
generated in the middle of a run is only printed to the screen, not to
the logfile, to avoid cluttering up thermodynamic output. If LAMMPS
crashes or hangs without spitting out an error message first then it
could be a bug (see <a class="reference internal" href="#err-2"><span class="std std-ref">this section</span></a>) or one of the following
cases:</p>
<p>LAMMPS runs in the available memory a processor allows to be
allocated. Most reasonable MD runs are compute limited, not memory
limited, so this shouldn’t be a bottleneck on most platforms. Almost
all large memory allocations in the code are done via C-style malloc’s
which will generate an error message if you run out of memory.
Smaller chunks of memory are allocated via C++ “new” statements. If
you are unlucky you could run out of memory just when one of these
small requests is made, in which case the code will crash or hang (in
parallel), since LAMMPS doesn’t trap on those errors.</p>
<p>Illegal arithmetic can cause LAMMPS to run slow or crash. This is
typically due to invalid physics and numerics that your simulation is
computing. If you see wild thermodynamic values or NaN values in your
LAMMPS output, something is wrong with your simulation. If you
suspect this is happening, it is a good idea to print out
thermodynamic info frequently (e.g. every timestep) via the
<a class="reference internal" href="thermo.html"><span class="doc">thermo</span></a> so you can monitor what is happening.
Visualizing the atom movement is also a good idea to insure your model
is behaving as you expect.</p>
<p>In parallel, one way LAMMPS can hang is due to how different MPI
implementations handle buffering of messages. If the code hangs
without an error message, it may be that you need to specify an MPI
setting or two (usually via an environment variable) to enable
buffering or boost the sizes of messages that can be buffered.</p>
<p>If you are confident that you have found a bug in LAMMPS, follow these
steps.</p>
<p>Check the <a class="reference external" href="http://lammps.sandia.gov/bug.html">New features and bug fixes</a> section of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW site</a> to see if the bug has already been reported or fixed or the
<a class="reference external" href="http://lammps.sandia.gov/unbug.html">Unfixed bug</a> to see if a fix is
pending.</p>
<p>Check the <a class="reference external" href="http://lammps.sandia.gov/mail.html">mailing list</a>
to see if it has been discussed before.</p>
<p>If not, send an email to the mailing list describing the problem with
any ideas you have as to what is causing it or where in the code the
problem might be. The developers will ask for more info if needed,
such as an input script or data files.</p>
<p>The most useful thing you can do to help us fix the bug is to isolate
the problem. Run it on the smallest number of atoms and fewest number
of processors and with the simplest input script that reproduces the
bug and try to identify what command or combination of commands is
causing the problem.</p>
<p>As a last resort, you can send an email directly to the
<p>means that line #78 in the file src/velocity.cpp generated the error.
Looking in the source code may help you figure out what went wrong.</p>
<p>Note that error messages from <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">user-contributed packages</span></a> are not listed here. If such an
error occurs and is not self-explanatory, you’ll need to look in the
source code or contact the author of the package.</p>
</div>
<div class="section" id="error">
<span id="id2"></span><h2>12.4. Errors:</h2>
<dl class="docutils">
<dt><em>1-3 bond count is inconsistent</em></dt>
<dd>An inconsistency was detected when computing the number of 1-3
neighbors for each atom. This likely means something is wrong with
the bond topologies you have defined.</dd>
<dt><em>1-4 bond count is inconsistent</em></dt>
<dd>An inconsistency was detected when computing the number of 1-4
neighbors for each atom. This likely means something is wrong with
the bond topologies you have defined.</dd>
<dt><em>Accelerator sharing is not currently supported on system</em></dt>
<dd>Multiple MPI processes cannot share the accelerator on your
system. For NVIDIA GPUs, see the nvidia-smi command to change this
setting.</dd>
<dt><em>All angle coeffs are not set</em></dt>
<dd>All angle coefficients must be set in the data file or by the
angle_coeff command before running a simulation.</dd>
<dt><em>All atom IDs = 0 but atom_modify id = yes</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>All atoms of a swapped type must have same charge.</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>All atoms of a swapped type must have the same charge.</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>All bond coeffs are not set</em></dt>
<dd>All bond coefficients must be set in the data file or by the
bond_coeff command before running a simulation.</dd>
<dt><em>All dihedral coeffs are not set</em></dt>
<dd>All dihedral coefficients must be set in the data file or by the
dihedral_coeff command before running a simulation.</dd>
<dt><em>All improper coeffs are not set</em></dt>
<dd>All improper coefficients must be set in the data file or by the
improper_coeff command before running a simulation.</dd>
<dt><em>All masses are not set</em></dt>
<dd>For atom styles that define masses for each atom type, all masses must
be set in the data file or by the mass command before running a
simulation. They must also be set before using the velocity
command.</dd>
<dt><em>All mol IDs should be set for fix gcmc group atoms</em></dt>
<dd>The molecule flag is on, yet not all molecule ids in the fix group
have been set to non-zero positive values by the user. This is an
error since all atoms in the fix gcmc group are eligible for deletion,
rotation, and translation and therefore must have valid molecule ids.</dd>
<dt><em>All pair coeffs are not set</em></dt>
<dd>All pair coefficients must be set in the data file or by the
pair_coeff command before running a simulation.</dd>
<dt><em>All read_dump x,y,z fields must be specified for scaled, triclinic coords</em></dt>
<dd>For triclinic boxes and scaled coordinates you must specify all 3 of
the x,y,z fields, else LAMMPS cannot reconstruct the unscaled
coordinates.</dd>
<dt><em>All universe/uloop variables must have same # of values</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>All variables in next command must be same style</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Angle atom missing in delete_bonds</em></dt>
<dd>The delete_bonds command cannot find one or more atoms in a particular
angle on a particular processor. The pairwise cutoff is too short or
the atoms are too far apart to make a valid angle.</dd>
<dt><em>Angle atom missing in set command</em></dt>
<dd>The set command cannot find one or more atoms in a particular angle on
a particular processor. The pairwise cutoff is too short or the atoms
are too far apart to make a valid angle.</dd>
<dt><em>Angle atoms %d %d %d missing on proc %d at step %ld</em></dt>
<dd>One or more of 3 atoms needed to compute a particular angle are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the angle has blown apart and an atom is
too far away.</dd>
<dt><em>Angle atoms missing on proc %d at step %ld</em></dt>
<dd>One or more of 3 atoms needed to compute a particular angle are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the angle has blown apart and an atom is
too far away.</dd>
<dt><em>Angle coeff for hybrid has invalid style</em></dt>
<dd>Angle style hybrid uses another angle style as one of its
coefficients. The angle style used in the angle_coeff command or read
from a restart file is not recognized.</dd>
<dt><em>Angle coeffs are not set</em></dt>
<dd>No angle coefficients have been assigned in the data file or via the
angle_coeff command.</dd>
<dt><em>Angle extent > half of periodic box length</em></dt>
<dd>This error was detected by the neigh_modify check yes setting. It is
an error because the angle atoms are so far apart it is ambiguous how
it should be defined.</dd>
<dt><em>Angle potential must be defined for SHAKE</em></dt>
<dd>When shaking angles, an angle_style potential must be used.</dd>
<dt><em>Angle style hybrid cannot have hybrid as an argument</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Angle style hybrid cannot have none as an argument</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Angle style hybrid cannot use same angle style twice</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Angle table must range from 0 to 180 degrees</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Angle table parameters did not set N</em></dt>
<dd>List of angle table parameters must include N setting.</dd>
<dt><em>Angle_coeff command before angle_style is defined</em></dt>
<dd>Coefficients cannot be set in the data file or via the angle_coeff
command until an angle_style has been assigned.</dd>
<dt><em>Angle_coeff command before simulation box is defined</em></dt>
<dd>The angle_coeff command cannot be used before a read_data,
read_restart, or create_box command.</dd>
<dt><em>Angle_coeff command when no angles allowed</em></dt>
<dd>The chosen atom style does not allow for angles to be defined.</dd>
<dt><em>Angle_style command when no angles allowed</em></dt>
<dd>The chosen atom style does not allow for angles to be defined.</dd>
<dt><em>Angles assigned incorrectly</em></dt>
<dd>Angles read in from the data file were not assigned correctly to
atoms. This means there is something invalid about the topology
definitions.</dd>
<dt><em>Angles defined but no angle types</em></dt>
<dd>The data file header lists angles but no angle types.</dd>
<dt><em>Append boundary must be shrink/minimum</em></dt>
<dd>The boundary style of the face where atoms are added
must be of type m (shrink/minimum).</dd>
<dt><em>Arccos of invalid value in variable formula</em></dt>
<dd>Argument of arccos() must be between -1 and 1.</dd>
<dt><em>Arcsin of invalid value in variable formula</em></dt>
<dd>Argument of arcsin() must be between -1 and 1.</dd>
<dt><em>Assigning body parameters to non-body atom</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Assigning ellipsoid parameters to non-ellipsoid atom</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Assigning line parameters to non-line atom</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Assigning quat to non-body atom</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Assigning tri parameters to non-tri atom</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>At least one atom of each swapped type must be present to define charges.</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom IDs must be consecutive for velocity create loop all</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom IDs must be used for molecular systems</em></dt>
<dd>Atom IDs are used to identify and find partner atoms in bonds.</dd>
<dt><em>Atom count changed in fix neb</em></dt>
<dd>This is not allowed in a NEB calculation.</dd>
<dt><em>Atom count is inconsistent, cannot write data file</em></dt>
<dd>The sum of atoms across processors does not equal the global number
of atoms. Probably some atoms have been lost.</dd>
<dt><em>Atom count is inconsistent, cannot write restart file</em></dt>
<dd>Sum of atoms across processors does not equal initial total count.
This is probably because you have lost some atoms.</dd>
<dt><em>Atom in too many rigid bodies - boost MAXBODY</em></dt>
<dd>Fix poems has a parameter MAXBODY (in fix_poems.cpp) which determines
the maximum number of rigid bodies a single atom can belong to (i.e. a
multibody joint). The bodies you have defined exceed this limit.</dd>
<dt><em>Atom sort did not operate correctly</em></dt>
<dd>This is an internal LAMMPS error. Please report it to the
developers.</dd>
<dt><em>Atom sorting has bin size = 0.0</em></dt>
<dd>The neighbor cutoff is being used as the bin size, but it is zero.
Thus you must explicitly list a bin size in the atom_modify sort
command or turn off sorting.</dd>
<dt><em>Atom style hybrid cannot have hybrid as an argument</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom style hybrid cannot use same atom style twice</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom style template molecule must have atom types</em></dt>
<dd>The defined molecule(s) does not specify atom types.</dd>
<dt><em>Atom style was redefined after using fix property/atom</em></dt>
<dd>This is not allowed.</dd>
<dt><em>Atom type must be zero in fix gcmc mol command</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom vector in equal-style variable formula</em></dt>
<dd>Atom vectors generate one value per atom which is not allowed
in an equal-style variable.</dd>
<dt><em>Atom-style variable in equal-style variable formula</em></dt>
<dd>Atom-style variables generate one value per atom which is not allowed
in an equal-style variable.</dd>
<dt><em>Atom_modify id command after simulation box is defined</em></dt>
<dd>The atom_modify id command cannot be used after a read_data,
read_restart, or create_box command.</dd>
<dt><em>Atom_modify map command after simulation box is defined</em></dt>
<dd>The atom_modify map command cannot be used after a read_data,
read_restart, or create_box command.</dd>
<dt><em>Atom_modify sort and first options cannot be used together</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom_style command after simulation box is defined</em></dt>
<dd>The atom_style command cannot be used after a read_data,
read_restart, or create_box command.</dd>
<dt><em>Atom_style line can only be used in 2d simulations</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom_style tri can only be used in 3d simulations</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atomfile variable could not read values</em></dt>
<dd>Check the file assigned to the variable.</dd>
<dt><em>Atomfile variable in equal-style variable formula</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atomfile-style variable in equal-style variable formula</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Attempt to pop empty stack in fix box/relax</em></dt>
<dd>Internal LAMMPS error. Please report it to the developers.</dd>
<dt><em>Attempt to push beyond stack limit in fix box/relax</em></dt>
<dd>Internal LAMMPS error. Please report it to the developers.</dd>
<dt><em>Attempting to rescale a 0.0 temperature</em></dt>
<dd>Cannot rescale a temperature that is already 0.0.</dd>
<dt><em>Bad FENE bond</em></dt>
<dd>Two atoms in a FENE bond have become so far apart that the bond cannot
be computed.</dd>
<dt><em>Bad TIP4P angle type for PPPM/TIP4P</em></dt>
<dd>Specified angle type is not valid.</dd>
<dt><em>Bad TIP4P angle type for PPPMDisp/TIP4P</em></dt>
<dd>Specified angle type is not valid.</dd>
<dt><em>Bad TIP4P bond type for PPPM/TIP4P</em></dt>
<dd>Specified bond type is not valid.</dd>
<dt><em>Bad TIP4P bond type for PPPMDisp/TIP4P</em></dt>
<dd>Specified bond type is not valid.</dd>
<dt><em>Bad fix ID in fix append/atoms command</em></dt>
<dd>The value of the fix_id for keyword spatial must start with ‘f_’.</dd>
<dt><em>Bad grid of processors</em></dt>
<dd>The 3d grid of processors defined by the processors command does not
match the number of processors LAMMPS is being run on.</dd>
<dd>This is not allowed if the kspace_modify overlap setting is no.</dd>
<dt><em>PPPM order < minimum allowed order</em></dt>
<dd>The default minimum order is 2. This can be reset by the
kspace_modify minorder command.</dd>
<dt><em>PPPM order cannot be < 2 or > than %d</em></dt>
<dd>This is a limitation of the PPPM implementation in LAMMPS.</dd>
<dt><em>PPPMDisp Coulomb grid is too large</em></dt>
<dd>The global PPPM grid is larger than OFFSET in one or more dimensions.
OFFSET is currently set to 4096. You likely need to decrease the
requested accuracy.</dd>
<dt><em>PPPMDisp Dispersion grid is too large</em></dt>
<dd>The global PPPM grid is larger than OFFSET in one or more dimensions.
OFFSET is currently set to 4096. You likely need to decrease the
requested accuracy.</dd>
<dt><em>PPPMDisp can only currently be used with comm_style brick</em></dt>
<dd>This is a current restriction in LAMMPS.</dd>
<dt><em>PPPMDisp coulomb order cannot be greater than %d</em></dt>
<dd>This is a limitation of the PPPM implementation in LAMMPS.</dd>
<dt><em>PPPMDisp used but no parameters set, for further information please see the pppm/disp documentation</em></dt>
<dd>An efficient and accurate usage of the pppm/disp requires settings via the kspace_modify command. Please see the pppm/disp documentation for further instructions.</dd>
<dt><em>PRD command before simulation box is defined</em></dt>
<dd>The prd command cannot be used before a read_data,
read_restart, or create_box command.</dd>
<dt><em>PRD nsteps must be multiple of t_event</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>PRD t_corr must be multiple of t_event</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Package command after simulation box is defined</em></dt>
<dd>The package command cannot be used afer a read_data, read_restart, or
create_box command.</dd>
<dt><em>Package cuda command without USER-CUDA package enabled</em></dt>
<dd>The USER-CUDA package must be installed via “make yes-user-cuda”
before LAMMPS is built, and the “-c on” must be used to enable the
package.</dd>
<dt><em>Package gpu command without GPU package installed</em></dt>
<dd>The GPU package must be installed via “make yes-gpu” before LAMMPS is
built.</dd>
<dt><em>Package intel command without USER-INTEL package installed</em></dt>
<dd>The USER-INTEL package must be installed via “make yes-user-intel”
before LAMMPS is built.</dd>
<dt><em>Package kokkos command without KOKKOS package enabled</em></dt>
<dd>The KOKKOS package must be installed via “make yes-kokkos” before
LAMMPS is built, and the “-k on” must be used to enable the package.</dd>
<dt><em>Package omp command without USER-OMP package installed</em></dt>
<dd>The USER-OMP package must be installed via “make yes-user-omp” before
LAMMPS is built.</dd>
<dt><em>Pair body requires atom style body</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Pair body requires body style nparticle</em></dt>
<dd>This pair style is specific to the nparticle body style.</dd>
<dt><em>Pair brownian requires atom style sphere</em></dt>
<dd>You specified an inner cutoff for a Coulombic table that is longer
than the global cutoff. Probably not what you wanted.</dd>
<dt><em>Temperature for MSST is not for group all</em></dt>
<dd>User-assigned temperature to MSST fix does not compute temperature for
all atoms. Since MSST computes a global pressure, the kinetic energy
contribution from the temperature is assumed to also be for all atoms.
Thus the pressure used by MSST could be inaccurate.</dd>
<dt><em>Temperature for NPT is not for group all</em></dt>
<dd>User-assigned temperature to NPT fix does not compute temperature for
all atoms. Since NPT computes a global pressure, the kinetic energy
contribution from the temperature is assumed to also be for all atoms.
Thus the pressure used by NPT could be inaccurate.</dd>
<dt><em>Temperature for fix modify is not for group all</em></dt>
<dd>The temperature compute is being used with a pressure calculation
which does operate on group all, so this may be inconsistent.</dd>
<dt><em>Temperature for thermo pressure is not for group all</em></dt>
<dd>User-assigned temperature to thermo via the thermo_modify command does
not compute temperature for all atoms. Since thermo computes a global
pressure, the kinetic energy contribution from the temperature is
assumed to also be for all atoms. Thus the pressure printed by thermo
could be inaccurate.</dd>
<dt><em>The fix ave/spatial command has been replaced by the more flexible fix ave/chunk and compute chunk/atom commands – fix ave/spatial will be removed in the summer of 2015</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>The minimizer does not re-orient dipoles when using fix efield</em></dt>
<dd>This means that only the atom coordinates will be minimized,
not the orientation of the dipoles.</dd>
<dt><em>Too many common neighbors in CNA %d times</em></dt>
<dd>More than the maximum # of neighbors was found multiple times. This
was unexpected.</dd>
<dt><em>Too many inner timesteps in fix ttm</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Too many neighbors in CNA for %d atoms</em></dt>
<dd>More than the maximum # of neighbors was found multiple times. This
was unexpected.</dd>
<dt><em>Triclinic box skew is large</em></dt>
<dd>The displacement in a skewed direction is normally required to be less
than half the box length in that dimension. E.g. the xy tilt must be
between -half and +half of the x box length. You have relaxed the
constraint using the box tilt command, but the warning means that a
LAMMPS simulation may be inefficient as a result.</dd>
<dt><em>Use special bonds = 0,1,1 with bond style fene</em></dt>
<dd>Most FENE models need this setting for the special_bonds command.</dd>
<dt><em>Use special bonds = 0,1,1 with bond style fene/expand</em></dt>
<dd>Most FENE models need this setting for the special_bonds command.</dd>
<dt><em>Using a manybody potential with bonds/angles/dihedrals and special_bond exclusions</em></dt>
<dd>This is likely not what you want to do. The exclusion settings will
eliminate neighbors in the neighbor list, which the manybody potential
needs to calculated its terms correctly.</dd>
<dt><em>Using compute temp/deform with inconsistent fix deform remap option</em></dt>
<dd>Fix nvt/sllod assumes deforming atoms have a velocity profile provided
by “remap v” or “remap none” as a fix deform option.</dd>
<dt><em>Using compute temp/deform with no fix deform defined</em></dt>
<dd>This is probably an error, since it makes little sense to use
compute temp/deform in this case.</dd>
<dt><em>Using fix srd with box deformation but no SRD thermostat</em></dt>
<dd>The deformation will heat the SRD particles so this can
be dangerous.</dd>
<dt><em>Using kspace solver on system with no charge</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Using largest cut-off for lj/long/dipole/long long long</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Using largest cutoff for buck/long/coul/long</em></dt>
<dd>Self-exlanatory.</dd>
<dt><em>Using largest cutoff for lj/long/coul/long</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Using largest cutoff for pair_style lj/long/tip4p/long</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Using package gpu without any pair style defined</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Using pair potential shift with pair_modify compute no</em></dt>
<dd>The shift effects will thus not be computed.</dd>
<dt><em>Using pair tail corrections with nonperiodic system</em></dt>
<dd>This is probably a bogus thing to do, since tail corrections are
computed by integrating the density of a periodic system out to
infinity.</dd>
<dt><em>Using pair tail corrections with pair_modify compute no</em></dt>
<dd>The tail corrections will thus not be computed.</dd>
<dt><em>pair style reax is now deprecated and will soon be retired. Users should switch to pair_style reax/c</em></dt>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<p>The <a class="reference external" href="http://lammps.sandia.gov/future.html">Wish list link</a> on the
-LAMMPS WWW page gives a list of features we are hoping to add to
-LAMMPS in the future, including contact names of individuals you can
-email if you are interested in contributing to the developement or
-would be a future user of that feature.</p>
-<p>You can also send <a class="reference external" href="http://lammps.sandia.gov/authors.html">email to the developers</a> if you want to add
-your wish to the list.</p>
+<p>As of summer 2016 we are using the <a class="reference external" href="https://github.com/lammps/lammps/issues">LAMMPS project issue tracker on GitHub</a> for keeping
+track of suggested, planned or pending new features. This includes
+discussions of how to best implement them, or why they would be
+useful. Especially if a planned or proposed feature is non-trivial
+to add, e.g. because it requires changes to some of the core
+classes of LAMMPS, people planning to contribute a new feature to
+LAMMS are encouraged to submit an issue about their planned
+implementation this way in order to receive feedback from the
+LAMMPS core developers. They will provide suggestions about
+the validity of the proposed approach and possible improvements,
+pitfalls or alternatives.</p>
+<p>Please see some of the closed issues for examples of how to
+suggest code enhancements, submit proposed changes, or report
+elated issues and how they are resoved.</p>
+<p>As an alternative to using GitHub, you may e-mail the
+<a class="reference external" href="http://lammps.sandia.gov/authors.html">core developers</a> or send
+an e-mail to the <a class="reference external" href="http://lammps.sandia.gov/mail.html">LAMMPS Mail list</a>
+if you want to have your suggestion added to the list.</p>
<hr class="docutils" />
</div>
<div class="section" id="past-versions">
<span id="hist-2"></span><h2>13.2. Past versions</h2>
<p>LAMMPS development began in the mid 1990s under a cooperative research
& development agreement (CRADA) between two DOE labs (Sandia and LLNL)
and 3 companies (Cray, Bristol Myers Squibb, and Dupont). The goal was
to develop a large-scale parallel classical MD code; the coding effort
was led by Steve Plimpton at Sandia.</p>
<p>After the CRADA ended, a final F77 version, LAMMPS 99, was
released. As development of LAMMPS continued at Sandia, its memory
management was converted to F90; a final F90 version was released as
LAMMPS 2001.</p>
<p>The current LAMMPS is a rewrite in C++ and was first publicly released
as an open source code in 2004. It includes many new features beyond
those in LAMMPS 99 or 2001. It also includes features from older
parallel MD codes written at Sandia, namely ParaDyn, Warp, and
GranFlow (see below).</p>
<p>In late 2006 we began merging new capabilities into LAMMPS that were
developed by Aidan Thompson at Sandia for his MD code GRASP, which has
a parallel framework similar to LAMMPS. Most notably, these have
included many-body potentials - Stillinger-Weber, Tersoff, ReaxFF -
and the associated charge-equilibration routines needed for ReaxFF.</p>
<p>The <a class="reference external" href="http://lammps.sandia.gov/history.html">History link</a> on the
LAMMPS WWW page gives a timeline of features added to the
C++ open-source version of LAMMPS over the last several years.</p>
<p>These older codes are available for download from the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW site</a>, except for Warp & GranFlow which were primarily used
internally. A brief listing of their features is given here.</p>
<p>LAMMPS 2001</p>
<ul class="simple">
<li>F90 + MPI</li>
<li>dynamic memory</li>
<li>spatial-decomposition parallelism</li>
<li>NVE, NVT, NPT, NPH, rRESPA integrators</li>
<li>LJ and Coulombic pairwise force fields</li>
<li>all-atom, united-atom, bead-spring polymer force fields</li>
<li>CHARMM-compatible force fields</li>
<li>class 2 force fields</li>
<li>3d/2d Ewald & PPPM</li>
<li>various force and temperature constraints</li>
<li>SHAKE</li>
<li>Hessian-free truncated-Newton minimizer</li>
<li>user-defined diagnostics</li>
</ul>
<p>LAMMPS 99</p>
<ul class="simple">
<li>F77 + MPI</li>
<li>static memory allocation</li>
<li>spatial-decomposition parallelism</li>
<li>most of the LAMMPS 2001 features with a few exceptions</li>
<li>no 2d Ewald & PPPM</li>
<li>molecular force fields are missing a few CHARMM terms</li>
<li>no SHAKE</li>
</ul>
<p>Warp</p>
<ul class="simple">
<li>F90 + MPI</li>
<li>spatial-decomposition parallelism</li>
<li>embedded atom method (EAM) metal potentials + LJ</li>
<li>lattice and grain-boundary atom creation</li>
<li>NVE, NVT integrators</li>
<li>boundary conditions for applying shear stresses</li>
<li>temperature controls for actively sheared systems</li>
<li>per-atom energy and centro-symmetry computation and output</li>
</ul>
<p>ParaDyn</p>
<ul class="simple">
<li>F77 + MPI</li>
<li>atom- and force-decomposition parallelism</li>
<li>embedded atom method (EAM) metal potentials</li>
<li>lattice atom creation</li>
<li>NVE, NVT, NPT integrators</li>
<li>all serial DYNAMO features for controls and constraints</li>
</ul>
<p>GranFlow</p>
<ul class="simple">
<li>F90 + MPI</li>
<li>spatial-decomposition parallelism</li>
<li>frictional granular potentials</li>
<li>NVE integrator</li>
<li>boundary conditions for granular flow and packing and walls</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>.
<li class="toctree-l3"><a class="reference internal" href="#fixes-that-write-output-files">6.15.5. Fixes that write output files</a></li>
<li class="toctree-l3"><a class="reference internal" href="#computes-that-process-output-quantities">6.15.6. Computes that process output quantities</a></li>
<li class="toctree-l3"><a class="reference internal" href="#fixes-that-process-output-quantities">6.15.7. Fixes that process output quantities</a></li>
<li class="toctree-l3"><a class="reference internal" href="#computes-that-generate-values-to-output">6.15.8. Computes that generate values to output</a></li>
<li class="toctree-l3"><a class="reference internal" href="#fixes-that-generate-values-to-output">6.15.9. Fixes that generate values to output</a></li>
<li class="toctree-l3"><a class="reference internal" href="#variables-that-generate-values-to-output">6.15.10. Variables that generate values to output</a></li>
<li class="toctree-l3"><a class="reference internal" href="#summary-table-of-output-options-and-data-flow-between-commands">6.15.11. Summary table of output options and data flow between commands</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#thermostatting-barostatting-and-computing-temperature">6.16. Thermostatting, barostatting, and computing temperature</a></li>
<li class="toctree-l2"><a class="reference internal" href="#calculating-a-diffusion-coefficient">6.22. Calculating a diffusion coefficient</a></li>
<li class="toctree-l2"><a class="reference internal" href="#using-chunks-to-calculate-system-properties">6.23. Using chunks to calculate system properties</a><ul>
<span id="howto-1"></span><h2>6.1. Restarting a simulation</h2>
<p>There are 3 ways to continue a long LAMMPS simulation. Multiple
<a class="reference internal" href="run.html"><span class="doc">run</span></a> commands can be used in the same input script. Each
run will continue from where the previous run left off. Or binary
restart files can be saved to disk using the <a class="reference internal" href="restart.html"><span class="doc">restart</span></a>
command. At a later time, these binary files can be read via a
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command in a new script. Or they can
be converted to text data files using the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-r command-line switch</span></a> and read by a
<a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command in a new script.</p>
<p>Here we give examples of 2 scripts that read either a binary restart
file or a converted data file and then issue a new run command to
continue where the previous run left off. They illustrate what
settings must be made in the new script. Details are discussed in the
documentation for the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> and
<p>DREIDING is a generic force field developed by the <a class="reference external" href="http://www.wag.caltech.edu">Goddard group</a> at Caltech and is useful for
predicting structures and dynamics of organic, biological and
main-group inorganic molecules. The philosophy in DREIDING is to use
general force constants and geometry parameters based on simple
hybridization considerations, rather than individual force constants
and geometric parameters that depend on the particular combinations of
atoms involved in the bond, angle, or torsion terms. DREIDING has an
<a class="reference internal" href="pair_hbond_dreiding.html"><span class="doc">explicit hydrogen bond term</span></a> to describe
interactions involving a hydrogen atom on very electronegative atoms
(N, O, F).</p>
<p>See <a class="reference internal" href="#howto-mayo"><span class="std std-ref">(Mayo)</span></a> for a description of the DREIDING force field</p>
<p>These style choices compute force field formulas that are consistent
with the DREIDING force field. See each command’s
<span id="howto-4"></span><h2>6.4. Running multiple simulations from one input script</h2>
<p>This can be done in several ways. See the documentation for
individual commands for more details on how these examples work.</p>
<p>If “multiple simulations” means continue a previous simulation for
more timesteps, then you simply use the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command
multiple times. For example, this script</p>
<pre class="literal-block">
units lj
atom_style atomic
read_data data.lj
run 10000
run 10000
run 10000
run 10000
run 10000
</pre>
<p>would run 5 successive simulations of the same system for a total of
50,000 timesteps.</p>
<p>If you wish to run totally different simulations, one after the other,
the <a class="reference internal" href="clear.html"><span class="doc">clear</span></a> command can be used in between them to
re-initialize LAMMPS. For example, this script</p>
<pre class="literal-block">
units lj
atom_style atomic
read_data data.lj
run 10000
clear
units lj
atom_style atomic
read_data data.lj.new
run 10000
</pre>
<p>would run 2 independent simulations, one after the other.</p>
<p>For large numbers of independent simulations, you can use
<a class="reference internal" href="variable.html"><span class="doc">variables</span></a> and the <a class="reference internal" href="next.html"><span class="doc">next</span></a> and
<a class="reference internal" href="jump.html"><span class="doc">jump</span></a> commands to loop over the same input script
multiple times with different settings. For example, this
script, named in.polymer</p>
<pre class="literal-block">
variable d index run1 run2 run3 run4 run5 run6 run7 run8
shell cd $d
read_data data.polymer
run 10000
shell cd ..
clear
next d
jump in.polymer
</pre>
<p>would run 8 simulations in different directories, using a data.polymer
file in each directory. The same concept could be used to run the
same system at 8 different temperatures, using a temperature variable
and storing the output in different log and dump files, for example</p>
<div class="highlight-default"><div class="highlight"><pre><span></span>variable a loop 8
variable t index 0.8 0.85 0.9 0.95 1.0 1.05 1.1 1.15
log log.$a
read data.polymer
velocity all create $t 352839
fix 1 all nvt $t $t 100.0
dump 1 all atom 1000 dump.$a
run 100000
clear
next t
next a
jump in.polymer
</pre></div>
</div>
<p>All of the above examples work whether you are running on 1 or
multiple processors, but assumed you are running LAMMPS on a single
partition of processors. LAMMPS can be run on multiple partitions via
the “-partition” command-line switch as described in <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">this section</span></a> of the manual.</p>
<p>In the last 2 examples, if LAMMPS were run on 3 partitions, the same
scripts could be used if the “index” and “loop” variables were
replaced with <em>universe</em>-style variables, as described in the
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command. Also, the “next t” and “next a”
commands would need to be replaced with a single “next a t” command.
With these modifications, the 8 simulations of each script would run
on the 3 partitions one after the other until all were finished.
Initially, 3 simulations would be started simultaneously, one on each
partition. When one finished, that partition would then start
the 4th simulation, and so forth, until all 8 were completed.</p>
<p>NEB is a method for finding transition states and barrier energies.
PRD and TAD are methods for performing accelerated dynamics to find
and perform infrequent events. Parallel tempering or replica exchange
runs different replicas at a series of temperature to facilitate
rare-event sampling.</p>
<p>These commands can only be used if LAMMPS was built with the REPLICA
package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
for more info on packages.</p>
<p>PIMD runs different replicas whose individual particles are coupled
together by springs to model a system or ring-polymers.</p>
<p>This commands can only be used if LAMMPS was built with the USER-MISC
package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
for more info on packages.</p>
<p>In all these cases, you must run with one or more processors per
replica. The processors assigned to each replica are determined at
run-time by using the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-partition command-line switch</span></a> to launch LAMMPS on multiple
partitions, which in this context are the same as replicas. E.g.
<p>calculates rotational kinetic energy which can be <a class="reference internal" href="#howto-15"><span class="std std-ref">output with thermodynamic info</span></a>.</p>
<p>Use one of these 3 pair potentials, which compute forces and torques
<div class="line">theta of HOH angle = 104.52</div>
<div class="line"><br /></div>
</div>
<p>These are the parameters to use for TIP3P with a long-range Coulombic
solver (e.g. Ewald or PPPM in LAMMPS), see <a class="reference internal" href="pair_dipole.html#price"><span class="std std-ref">(Price)</span></a> for
details:</p>
<div class="line-block">
<div class="line">O mass = 15.9994</div>
<div class="line">H mass = 1.008</div>
<div class="line">O charge = -0.830</div>
<div class="line">H charge = 0.415</div>
<div class="line">LJ epsilon of OO = 0.102</div>
<div class="line">LJ sigma of OO = 3.188</div>
<div class="line">LJ epsilon, sigma of OH, HH = 0.0</div>
<div class="line">K of OH bond = 450</div>
<div class="line">r0 of OH bond = 0.9572</div>
<div class="line">K of HOH angle = 55</div>
<div class="line">theta of HOH angle = 104.52</div>
<div class="line"><br /></div>
</div>
<p>Wikipedia also has a nice article on <a class="reference external" href="http://en.wikipedia.org/wiki/Water_model">water models</a>.</p>
<hr class="docutils" />
</div>
<div class="section" id="tip4p-water-model">
<span id="howto-8"></span><h2>6.8. TIP4P water model</h2>
<p>The four-point TIP4P rigid water model extends the traditional
three-point TIP3P model by adding an additional site, usually
massless, where the charge associated with the oxygen atom is placed.
This site M is located at a fixed distance away from the oxygen along
the bisector of the HOH bond angle. A bond style of <em>harmonic</em> and an
angle style of <em>harmonic</em> or <em>charmm</em> should also be used.</p>
<p>A TIP4P model is run with LAMMPS using either this command
<p>For both models, the bond lengths and bond angles should be held fixed
using the <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command.</p>
<p>These are the additional parameters (in real units) to set for O and H
atoms and the water molecule to run a rigid TIP4P model with a cutoff
<a class="reference internal" href="pair_lj.html#jorgensen"><span class="std std-ref">(Jorgensen)</span></a>. Note that the OM distance is specified in
the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> command, not as part of the pair
coefficients.</p>
<div class="line-block">
<div class="line">O mass = 15.9994</div>
<div class="line">H mass = 1.008</div>
<div class="line">O charge = -1.040</div>
<div class="line">H charge = 0.520</div>
<div class="line">r0 of OH bond = 0.9572</div>
<div class="line">theta of HOH angle = 104.52</div>
<div class="line">OM distance = 0.15</div>
<div class="line">LJ epsilon of O-O = 0.1550</div>
<div class="line">LJ sigma of O-O = 3.1536</div>
<div class="line">LJ epsilon, sigma of OH, HH = 0.0</div>
<div class="line">Coulombic cutoff = 8.5</div>
<div class="line"><br /></div>
</div>
<p>For the TIP4/Ice model (J Chem Phys, 122, 234511 (2005);
<a class="reference external" href="http://dx.doi.org/10.1063/1.1931662">http://dx.doi.org/10.1063/1.1931662</a>) these values can be used:</p>
<div class="line-block">
<div class="line">O mass = 15.9994</div>
<div class="line">H mass = 1.008</div>
<div class="line">O charge = -1.1794</div>
<div class="line">H charge = 0.5897</div>
<div class="line">r0 of OH bond = 0.9572</div>
<div class="line">theta of HOH angle = 104.52</div>
<div class="line">OM distance = 0.1577</div>
<div class="line">LJ epsilon of O-O = 0.21084</div>
<div class="line">LJ sigma of O-O = 3.1668</div>
<div class="line">LJ epsilon, sigma of OH, HH = 0.0</div>
<div class="line">Coulombic cutoff = 8.5</div>
<div class="line"><br /></div>
</div>
<p>For the TIP4P/2005 model (J Chem Phys, 123, 234505 (2005);
<a class="reference external" href="http://dx.doi.org/10.1063/1.2121687">http://dx.doi.org/10.1063/1.2121687</a>), these values can be used:</p>
<div class="line-block">
<div class="line">O mass = 15.9994</div>
<div class="line">H mass = 1.008</div>
<div class="line">O charge = -1.1128</div>
<div class="line">H charge = 0.5564</div>
<div class="line">r0 of OH bond = 0.9572</div>
<div class="line">theta of HOH angle = 104.52</div>
<div class="line">OM distance = 0.1546</div>
<div class="line">LJ epsilon of O-O = 0.1852</div>
<div class="line">LJ sigma of O-O = 3.1589</div>
<div class="line">LJ epsilon, sigma of OH, HH = 0.0</div>
<div class="line">Coulombic cutoff = 8.5</div>
<div class="line"><br /></div>
</div>
<p>These are the parameters to use for TIP4P with a long-range Coulombic
solver (e.g. Ewald or PPPM in LAMMPS):</p>
<div class="line-block">
<div class="line">O mass = 15.9994</div>
<div class="line">H mass = 1.008</div>
<div class="line">O charge = -1.0484</div>
<div class="line">H charge = 0.5242</div>
<div class="line">r0 of OH bond = 0.9572</div>
<div class="line">theta of HOH angle = 104.52</div>
<div class="line">OM distance = 0.1250</div>
<div class="line">LJ epsilon of O-O = 0.16275</div>
<div class="line">LJ sigma of O-O = 3.16435</div>
<div class="line">LJ epsilon, sigma of OH, HH = 0.0</div>
<div class="line"><br /></div>
</div>
<p>Note that the when using the TIP4P pair style, the neighobr list
cutoff for Coulomb interactions is effectively extended by a distance
2 * (OM distance), to account for the offset distance of the
fictitious charges on O atoms in water molecules. Thus it is
typically best in an efficiency sense to use a LJ cutoff >= Coulomb
cutoff + 2*(OM distance), to shrink the size of the neighbor list.
This leads to slightly larger cost for the long-range calculation, so
you can test the trade-off for your model. The OM distance and the LJ
and Coulombic cutoffs are set in the <a class="reference internal" href="pair_lj.html"><span class="doc">pair_style lj/cut/tip4p/long</span></a> command.</p>
<p>Wikipedia also has a nice article on <a class="reference external" href="http://en.wikipedia.org/wiki/Water_model">water models</a>.</p>
<hr class="docutils" />
</div>
<div class="section" id="spc-water-model">
<span id="howto-9"></span><h2>6.9. SPC water model</h2>
<p>The SPC water model specifies a 3-site rigid water molecule with
charges and Lennard-Jones parameters assigned to each of the 3 atoms.
In LAMMPS the <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command can be used to hold
the two O-H bonds and the H-O-H angle rigid. A bond style of
<em>harmonic</em> and an angle style of <em>harmonic</em> or <em>charmm</em> should also be
used.</p>
<p>These are the additional parameters (in real units) to set for O and H
atoms and the water molecule to run a rigid SPC model.</p>
<div class="line-block">
<div class="line">O mass = 15.9994</div>
<div class="line">H mass = 1.008</div>
<div class="line">O charge = -0.820</div>
<div class="line">H charge = 0.410</div>
<div class="line">LJ epsilon of OO = 0.1553</div>
<div class="line">LJ sigma of OO = 3.166</div>
<div class="line">LJ epsilon, sigma of OH, HH = 0.0</div>
<div class="line">r0 of OH bond = 1.0</div>
<div class="line">theta of HOH angle = 109.47</div>
<div class="line"><br /></div>
</div>
<p>Note that as originally proposed, the SPC model was run with a 9
Angstrom cutoff for both LJ and Coulommbic terms. It can also be used
with long-range Coulombics (Ewald or PPPM in LAMMPS), without changing
any of the parameters above, though it becomes a different model in
that mode of usage.</p>
<p>The SPC/E (extended) water model is the same, except
the partial charge assignemnts change:</p>
<div class="line-block">
<div class="line">O charge = -0.8476</div>
<div class="line">H charge = 0.4238</div>
<div class="line"><br /></div>
</div>
<p>See the <a class="reference internal" href="#howto-berendsen"><span class="std std-ref">(Berendsen)</span></a> reference for more details on both
the SPC and SPC/E models.</p>
<p>Wikipedia also has a nice article on <a class="reference external" href="http://en.wikipedia.org/wiki/Water_model">water models</a>.</p>
<span id="howto-10"></span><h2>6.10. Coupling LAMMPS to other codes</h2>
<p>LAMMPS is designed to allow it to be coupled to other codes. For
example, a quantum mechanics code might compute forces on a subset of
atoms and pass those forces to LAMMPS. Or a continuum finite element
(FE) simulation might use atom positions as boundary conditions on FE
nodal points, compute a FE solution, and return interpolated forces on
MD atoms.</p>
<p>LAMMPS can be coupled to other codes in at least 3 ways. Each has
advantages and disadvantages, which you’ll have to think about in the
context of your application.</p>
<p>(1) Define a new <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command that calls the other code. In
this scenario, LAMMPS is the driver code. During its timestepping,
the fix is invoked, and can make library calls to the other code,
which has been linked to LAMMPS as a library. This is the way the
<a class="reference external" href="http://www.rpi.edu/~anderk5/lab">POEMS</a> package that performs constrained rigid-body motion on
groups of atoms is hooked to LAMMPS. See the
<a class="reference internal" href="fix_poems.html"><span class="doc">fix poems</span></a> command for more details. See <a class="reference internal" href="Section_modify.html"><span class="doc">this section</span></a> of the documentation for info on how to add
a new fix to LAMMPS.</p>
<p>(2) Define a new LAMMPS command that calls the other code. This is
conceptually similar to method (1), but in this case LAMMPS and the
other code are on a more equal footing. Note that now the other code
is not called during the timestepping of a LAMMPS run, but between
runs. The LAMMPS input script can be used to alternate LAMMPS runs
with calls to the other code, invoked via the new command. The
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command facilitates this with its <em>every</em> option, which
makes it easy to run a few steps, invoke the command, run a few steps,
invoke the command, etc.</p>
<p>In this scenario, the other code can be called as a library, as in
(1), or it could be a stand-alone code, invoked by a system() call
made by the command (assuming your parallel machine allows one or more
processors to start up another program). In the latter case the
stand-alone code could communicate with LAMMPS thru files that the
command writes and reads.</p>
-<p>See <a class="reference internal" href="Section_modify.html"><span class="doc">Section_modify</span></a> of the documentation for how
+<p>See <a class="reference internal" href="Section_modify.html"><span class="doc">Section 10</span></a> of the documentation for how
to add a new command to LAMMPS.</p>
<p>(3) Use LAMMPS as a library called by another code. In this case the
other code is the driver and calls LAMMPS as needed. Or a wrapper
code could link and call both LAMMPS and another code as libraries.
Again, the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command has options that allow it to be
invoked with minimal overhead (no setup or clean-up) if you wish to do
multiple short runs, driven by another program.</p>
<p>Examples of driver codes that call LAMMPS as a library are included in
the examples/COUPLE directory of the LAMMPS distribution; see
examples/COUPLE/README for more details:</p>
<ul class="simple">
<li>simple: simple driver programs in C++ and C which invoke LAMMPS as a
library</li>
<li>lammps_quest: coupling of LAMMPS and <a class="reference external" href="http://dft.sandia.gov/Quest">Quest</a>, to run classical
MD with quantum forces calculated by a density functional code</li>
<li>lammps_spparks: coupling of LAMMPS and <a class="reference external" href="http://www.sandia.gov/~sjplimp/spparks.html">SPPARKS</a>, to couple
a kinetic Monte Carlo model for grain growth using MD to calculate
strain induced across grain boundaries</li>
</ul>
<p><a class="reference internal" href="Section_start.html#start-5"><span class="std std-ref">This section</span></a> of the documentation
describes how to build LAMMPS as a library. Once this is done, you
can interface with LAMMPS either via C++, C, Fortran, or Python (or
any other language that supports a vanilla C-like interface). For
example, from C++ you could create one (or more) “instances” of
LAMMPS, pass it an input script to process, or execute individual
commands, all by invoking the correct class methods in LAMMPS. From C
or Fortran you can make function calls to do the same things. See
-<a class="reference internal" href="Section_python.html"><span class="doc">Section_python</span></a> of the manual for a description
+<a class="reference internal" href="Section_python.html"><span class="doc">Section 11</span></a> of the manual for a description
of the Python wrapper provided with LAMMPS that operates through the
LAMMPS library interface.</p>
<p>The files src/library.cpp and library.h contain the C-style interface
-to LAMMPS. See <a class="reference internal" href="#howto-19"><span class="std std-ref">Section_howto 19</span></a> of the
+to LAMMPS. See <a class="reference internal" href="#howto-19"><span class="std std-ref">Section 6.19</span></a> of the
manual for a description of the interface and how to extend it for
your needs.</p>
<p>Note that the lammps_open() function that creates an instance of
LAMMPS takes an MPI communicator as an argument. This means that
instance of LAMMPS will run on the set of processors in the
communicator. Thus the calling code can run LAMMPS on all or a subset
of processors. For example, a wrapper script might decide to
alternate between LAMMPS and another code, allowing them both to run
on all the processors. Or it might allocate half the processors to
LAMMPS and half to the other code and run both codes simultaneously
before syncing them up periodically. Or it might instantiate multiple
instances of LAMMPS to perform different calculations.</p>
<p>A Python-based toolkit distributed by our group can read native LAMMPS
dump files, including custom dump files with additional columns of
user-specified atom information, and convert them to various formats
or pipe them into visualization software directly. See the <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py WWW site</a> for details. Specifically, Pizza.py can convert
LAMMPS dump files into PDB, XYZ, <a class="reference external" href="http://www.ensight.com">Ensight</a>, and VTK formats.
Pizza.py can pipe LAMMPS dump files directly into the Raster3d and
RasMol visualization programs. Pizza.py has tools that do interactive
3d OpenGL visualization and one that creates SVG images of dump file
snapshots.</p>
<p>LAMMPS can create XYZ files directly (via “dump xyz”) which is a
simple text-based file format used by many visualization programs
including <a class="reference external" href="http://www.ks.uiuc.edu/Research/vmd">VMD</a>.</p>
<p>LAMMPS can create DCD files directly (via “dump dcd”) which can be
read by <a class="reference external" href="http://www.ks.uiuc.edu/Research/vmd">VMD</a> in conjunction with a CHARMM PSF file. Using this
form of output avoids the need to convert LAMMPS snapshots to PDB
files. See the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command for more information on DCD
files.</p>
<p>LAMMPS can create XTC files directly (via “dump xtc”) which is GROMACS
file format which can also be read by <a class="reference external" href="http://www.ks.uiuc.edu/Research/vmd">VMD</a> for visualization.
See the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command for more information on XTC files.</p>
where lx = xhi-xlo, and similarly in the y and z dimensions. The 6
parameters, as well as lx,ly,lz, can be output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command.</p>
<p>LAMMPS also allows simulations to be performed in triclinic
(non-orthogonal) simulation boxes shaped as a parallelepiped with
triclinic symmetry. The parallelepiped has its “origin” at
(xlo,ylo,zlo) and is defined by 3 edge vectors starting from the
origin given by <strong>a</strong> = (xhi-xlo,0,0); <strong>b</strong> = (xy,yhi-ylo,0); <strong>c</strong> =
(xz,yz,zhi-zlo). <em>xy,xz,yz</em> can be 0.0 or positive or negative values
and are called “tilt factors” because they are the amount of
displacement applied to faces of an originally orthogonal box to
transform it into the parallelepiped. In LAMMPS the triclinic
simulation box edge vectors <strong>a</strong>, <strong>b</strong>, and <strong>c</strong> cannot be arbitrary
vectors. As indicated, <strong>a</strong> must lie on the positive x axis. <strong>b</strong> must
lie in the xy plane, with strictly positive y component. <strong>c</strong> may have
any orientation with strictly positive z component. The requirement
that <strong>a</strong>, <strong>b</strong>, and <strong>c</strong> have strictly positive x, y, and z components,
respectively, ensures that <strong>a</strong>, <strong>b</strong>, and <strong>c</strong> form a complete
right-handed basis. These restrictions impose no loss of generality,
since it is possible to rotate/invert any set of 3 crystal basis
vectors so that they conform to the restrictions.</p>
<p>For example, assume that the 3 vectors <strong>A</strong>,<strong>B</strong>,<strong>C</strong> are the edge
vectors of a general parallelepiped, where there is no restriction on
<strong>A</strong>,<strong>B</strong>,<strong>C</strong> other than they form a complete right-handed basis i.e.
<strong>A</strong> x <strong>B</strong> . <strong>C</strong> > 0. The equivalent LAMMPS <strong>a</strong>,<strong>b</strong>,<strong>c</strong> are a linear
rotation of <strong>A</strong>, <strong>B</strong>, and <strong>C</strong> and can be computed as follows:</p>
<p>where <em>V</em> is the volume of the box, <strong>X</strong> is the original vector quantity and
<strong>x</strong> is the vector in the LAMMPS basis.</p>
<p>There is no requirement that a triclinic box be periodic in any
dimension, though it typically should be in at least the 2nd dimension
of the tilt (y in xy) if you want to enforce a shift in periodic
boundary conditions across that boundary. Some commands that work
with triclinic boxes, e.g. the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> and <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> commands, require periodicity or non-shrink-wrap
boundary conditions in specific dimensions. See the command doc pages
for details.</p>
<p>The 9 parameters (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) are defined at the
time the simluation box is created. This happens in one of 3 ways.
If the <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> command is used with a region of
style <em>prism</em>, then a triclinic box is setup. See the
<a class="reference internal" href="region.html"><span class="doc">region</span></a> command for details. If the
<a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command is used to define the simulation
box, and the header of the data file contains a line with the “xy xz
yz” keyword, then a triclinic box is setup. See the
<a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command for details. Finally, if the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command reads a restart file which
was written from a simulation using a triclinic box, then a triclinic
box will be setup for the restarted simulation.</p>
<p>Note that you can define a triclinic box with all 3 tilt factors =
0.0, so that it is initially orthogonal. This is necessary if the box
will become non-orthogonal, e.g. due to the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> or
<a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> commands. Alternatively, you can use the
<a class="reference internal" href="change_box.html"><span class="doc">change_box</span></a> command to convert a simulation box from
orthogonal to triclinic and vice versa.</p>
<p>As with orthogonal boxes, LAMMPS defines triclinic box size parameters
lx,ly,lz where lx = xhi-xlo, and similarly in the y and z dimensions.
The 9 parameters, as well as lx,ly,lz, can be output via the
as well as when the box shape changes dynamically during a simulation,
e.g. via the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> or <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a>
commands.</p>
<p>For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
the xy tilt factor must be between -5 and 5. Similarly, both xz and
yz must be between -(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is
not a limitation, since if the maximum tilt factor is 5 (as in this
example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
... are geometrically all equivalent. If the box tilt exceeds this
limit during a dynamics run (e.g. via the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a>
command), then the box is “flipped” to an equivalent shape with a tilt
factor within the bounds, so the run can continue. See the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> doc page for further details.</p>
<p>One exception to this rule is if the 1st dimension in the tilt
factor (x for xy) is non-periodic. In that case, the limits on the
tilt factor are not enforced, since flipping the box in that dimension
does not change the atom positions due to non-periodicity. In this
mode, if you tilt the system to extreme angles, the simulation will
simply become inefficient, due to the highly skewed simulation box.</p>
<p>The limitation on not creating a simulation box with a tilt factor
skewing the box more than half the distance of the parallel box length
can be overridden via the <a class="reference internal" href="box.html"><span class="doc">box</span></a> command. Setting the <em>tilt</em>
keyword to <em>large</em> allows any tilt factors to be specified.</p>
<p>Box flips that may occur using the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> or
<a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> commands can be turned off using the <em>flip no</em>
option with either of the commands.</p>
<p>Note that if a simulation box has a large tilt factor, LAMMPS will run
less efficiently, due to the large volume of communication needed to
acquire ghost atoms around a processor’s irregular-shaped sub-domain.
For extreme values of tilt, LAMMPS may also lose atoms and generate an
error.</p>
<p>Triclinic crystal structures are often defined using three lattice
constants <em>a</em>, <em>b</em>, and <em>c</em>, and three angles <em>alpha</em>, <em>beta</em> and
<em>gamma</em>. Note that in this nomenclature, the a, b, and c lattice
constants are the scalar lengths of the edge vectors <strong>a</strong>, <strong>b</strong>, and <strong>c</strong>
defined above. The relationship between these 6 quantities
(a,b,c,alpha,beta,gamma) and the LAMMPS box sizes (lx,ly,lz) =
(xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:</p>
<p>A second use is to run Parinello-Rahman dyanamics via the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command, which will adjust the xy, xz, yz tilt
factors to compensate for off-diagonal components of the pressure
tensor. The analalog for an <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a> is
the <a class="reference internal" href="fix_box_relax.html"><span class="doc">fix box/relax</span></a> command.</p>
<p>A third use is to shear a bulk solid to study the response of the
material. The <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> command can be used for
this purpose. It allows dynamic control of the xy, xz, yz tilt
factors as a simulation runs. This is discussed in the next section
<p>Non-equilibrium molecular dynamics or NEMD simulations are typically
used to measure a fluid’s rheological properties such as viscosity.
In LAMMPS, such simulations can be performed by first setting up a
non-orthogonal simulation box (see the preceding Howto section).</p>
<p>A shear strain can be applied to the simulation box at a desired
strain rate by using the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> command. The
<a class="reference internal" href="fix_nvt_sllod.html"><span class="doc">fix nvt/sllod</span></a> command can be used to thermostat
the sheared fluid and integrate the SLLOD equations of motion for the
system. Fix nvt/sllod uses <a class="reference internal" href="compute_temp_deform.html"><span class="doc">compute temp/deform</span></a> to compute a thermal temperature
by subtracting out the streaming velocity of the shearing atoms. The
velocity profile or other properties of the fluid can be monitored via
the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> command.</p>
<p>As discussed in the previous section on non-orthogonal simulation
boxes, the amount of tilt or skew that can be applied is limited by
LAMMPS for computational efficiency to be 1/2 of the parallel box
length. However, <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> can continuously strain
a box by an arbitrary amount. As discussed in the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> command, when the tilt value reaches a limit,
the box is flipped to the opposite limit which is an equivalent tiling
of periodic space. The strain rate can then continue to change as
before. In a long NEMD simulation these box re-shaping events may
occur many times.</p>
<p>In a NEMD simulation, the “remap” option of <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> should be set to “remap v”, since that is what
<a class="reference internal" href="fix_nvt_sllod.html"><span class="doc">fix nvt/sllod</span></a> assumes to generate a velocity
profile consistent with the applied shear strain rate.</p>
<p>An alternative method for calculating viscosities is provided via the
<span id="howto-14"></span><h2>6.14. Finite-size spherical and aspherical particles</h2>
<p>Typical MD models treat atoms or particles as point masses. Sometimes
it is desirable to have a model with finite-size particles such as
spheroids or ellipsoids or generalized aspherical bodies. The
difference is that such particles have a moment of inertia, rotational
energy, and angular momentum. Rotation is induced by torque coming
from interactions with other particles.</p>
<p>LAMMPS has several options for running simulations with these kinds of
particles. The following aspects are discussed in turn:</p>
<ul class="simple">
<li>atom styles</li>
<li>pair potentials</li>
<li>time integration</li>
<li>computes, thermodynamics, and dump output</li>
<li>rigid bodies composed of finite-size particles</li>
</ul>
<p>Example input scripts for these kinds of models are in the body,
colloid, dipole, ellipse, line, peri, pour, and tri directories of the
<a class="reference internal" href="Section_example.html"><span class="doc">examples directory</span></a> in the LAMMPS distribution.</p>
<div class="section" id="atom-styles">
<h3>6.14.1. Atom styles</h3>
<p>There are several <a class="reference internal" href="atom_style.html"><span class="doc">atom styles</span></a> that allow for
definition of finite-size particles: sphere, dipole, ellipsoid, line,
tri, peri, and body.</p>
<p>The sphere style defines particles that are spheriods and each
particle can have a unique diameter and mass (or density). These
particles store an angular velocity (omega) and can be acted upon by
torque. The “set” command can be used to modify the diameter and mass
of individual particles, after then are created.</p>
<p>The dipole style does not actually define finite-size particles, but
is often used in conjunction with spherical particles, via a command
like</p>
<pre class="literal-block">
atom_style hybrid sphere dipole
</pre>
<p>This is because when dipoles interact with each other, they induce
torques, and a particle must be finite-size (i.e. have a moment of
inertia) in order to respond and rotate. See the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style dipole</span></a> command for details. The “set” command can be
used to modify the orientation and length of the dipole moment of
individual particles, after then are created.</p>
<p>The ellipsoid style defines particles that are ellipsoids and thus can
be aspherical. Each particle has a shape, specified by 3 diameters,
and mass (or density). These particles store an angular momentum and
their orientation (quaternion), and can be acted upon by torque. They
do not store an angular velocity (omega), which can be in a different
direction than angular momentum, rather they compute it as needed.
The “set” command can be used to modify the diameter, orientation, and
mass of individual particles, after then are created. It also has a
brief explanation of what quaternions are.</p>
<p>The line style defines line segment particles with two end points and
a mass (or density). They can be used in 2d simulations, and they can
be joined together to form rigid bodies which represent arbitrary
polygons.</p>
<p>The tri style defines triangular particles with three corner points
and a mass (or density). They can be used in 3d simulations, and they
can be joined together to form rigid bodies which represent arbitrary
particles with a triangulated surface.</p>
<p>The peri style is used with <a class="reference internal" href="pair_peri.html"><span class="doc">Peridynamic models</span></a> and
defines particles as having a volume, that is used internally in the
<p>The body style allows for definition of particles which can represent
complex entities, such as surface meshes of discrete points,
collections of sub-particles, deformable objects, etc. The body style
is discussed in more detail on the <a class="reference internal" href="body.html"><span class="doc">body</span></a> doc page.</p>
<p>Note that if one of these atom styles is used (or multiple styles via
the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style hybrid</span></a> command), not all particles in
the system are required to be finite-size or aspherical.</p>
<p>For example, in the ellipsoid style, if the 3 shape parameters are set
to the same value, the particle will be a sphere rather than an
ellipsoid. If the 3 shape parameters are all set to 0.0 or if the
diameter is set to 0.0, it will be a point particle. In the line or
tri style, if the lineflag or triflag is specified as 0, then it
will be a point particle.</p>
<p>Some of the pair styles used to compute pairwise interactions between
finite-size particles also compute the correct interaction with point
particles as well, e.g. the interaction between a point particle and a
finite-size particle or between two point particles. If necessary,
<a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid</span></a> can be used to insure the correct
interactions are computed for the appropriate style of interactions.
Likewise, using groups to partition particles (ellipsoids versus
spheres versus point particles) will allow you to use the appropriate
time integrators and temperature computations for each class of
particles. See the doc pages for various commands for details.</p>
<p>Also note that for <a class="reference internal" href="dimension.html"><span class="doc">2d simulations</span></a>, atom styles sphere
and ellipsoid still use 3d particles, rather than as circular disks or
ellipses. This means they have the same moment of inertia as the 3d
object. When temperature is computed, the correct degrees of freedom
are used for rotation in a 2d versus 3d system.</p>
</div>
<div class="section" id="pair-potentials">
<h3>6.14.2. Pair potentials</h3>
<p>When a system with finite-size particles is defined, the particles
will only rotate and experience torque if the force field computes
such interactions. These are the various <a class="reference internal" href="pair_style.html"><span class="doc">pair styles</span></a> that generate torque:</p>
<h3>6.14.5. Rigid bodies composed of finite-size particles</h3>
<p>The <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> command treats a collection of
particles as a rigid body, computes its inertia tensor, sums the total
force and torque on the rigid body each timestep due to forces on its
constituent particles, and integrates the motion of the rigid body.</p>
<p>If any of the constituent particles of a rigid body are finite-size
particles (spheres or ellipsoids or line segments or triangles), then
their contribution to the inertia tensor of the body is different than
if they were point particles. This means the rotational dynamics of
the rigid body will be different. Thus a model of a dimer is
different if the dimer consists of two point masses versus two
spheroids, even if the two particles have the same mass. Finite-size
particles that experience torque due to their interaction with other
particles will also impart that torque to a rigid body they are part
of.</p>
<p>See the “fix rigid” command for example of complex rigid-body models
it is possible to define in LAMMPS.</p>
<p>Note that the <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command can also be used to
treat 2, 3, or 4 particles as a rigid body, but it always assumes the
particles are point masses.</p>
<p>Also note that body particles cannot be modeled with the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> command. Body particles are treated by LAMMPS
as single particles, though they can store internal state, such as a
list of sub-particles. Individual body partices are typically treated
as rigid bodies, and their motion integrated with a command like <a class="reference internal" href="fix_nve_body.html"><span class="doc">fix nve/body</span></a>. Interactions between pairs of body
particles are computed via a command like <a class="reference internal" href="pair_body.html"><span class="doc">pair_style body</span></a>.</p>
<span id="howto-15"></span><h2>6.15. Output from LAMMPS (thermo, dumps, computes, fixes, variables)</h2>
<p>There are four basic kinds of LAMMPS output:</p>
<ul class="simple">
<li><a class="reference internal" href="thermo_style.html"><span class="doc">Thermodynamic output</span></a>, which is a list
of quantities printed every few timesteps to the screen and logfile.</li>
<li><a class="reference internal" href="dump.html"><span class="doc">Dump files</span></a>, which contain snapshots of atoms and various
per-atom values and are written at a specified frequency.</li>
<li>Certain fixes can output user-specified quantities to files: <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a> for time averaging, <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> for spatial or other averaging, and <a class="reference internal" href="fix_print.html"><span class="doc">fix print</span></a> for single-line output of
<a class="reference internal" href="variable.html"><span class="doc">variables</span></a>. Fix print can also output to the
<p>A simulation prints one set of thermodynamic output and (optionally)
restart files. It can generate any number of dump files and fix
output files, depending on what <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> and <a class="reference internal" href="fix.html"><span class="doc">fix</span></a>
commands you specify.</p>
<p>As discussed below, LAMMPS gives you a variety of ways to determine
what quantities are computed and printed when the thermodynamics,
dump, or fix commands listed above perform output. Throughout this
discussion, note that users can also <a class="reference internal" href="Section_modify.html"><span class="doc">add their own computes and fixes to LAMMPS</span></a> which can then generate values that can
then be output with these commands.</p>
<p>The following sub-sections discuss different LAMMPS command related
to output and the kind of data they operate on and produce:</p>
<li><a class="reference internal" href="#fixoutput"><span class="std std-ref">Fixes that write output files</span></a></li>
<li><a class="reference internal" href="#computeoutput"><span class="std std-ref">Computes that process output quantities</span></a></li>
<li><a class="reference internal" href="#fixprocoutput"><span class="std std-ref">Fixes that process output quantities</span></a></li>
<li><a class="reference internal" href="#compute"><span class="std std-ref">Computes that generate values to output</span></a></li>
<li><a class="reference internal" href="#fix"><span class="std std-ref">Fixes that generate values to output</span></a></li>
<li><a class="reference internal" href="#variable"><span class="std std-ref">Variables that generate values to output</span></a></li>
<li><a class="reference internal" href="#table"><span class="std std-ref">Summary table of output options and data flow between commands</span></a></li>
<a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify</span></a> commands. The
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command also specifies what values
are calculated and written out. Pre-defined keywords can be specified
(e.g. press, etotal, etc). Three additional kinds of keywords can
also be specified (c_ID, f_ID, v_name), where a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>
or <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> or <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> provides the value to be
output. In each case, the compute, fix, or variable must generate
global values for input to the <a class="reference internal" href="dump.html"><span class="doc">thermo_style custom</span></a>
command.</p>
<p>Note that thermodynamic output values can be “extensive” or
“intensive”. The former scale with the number of atoms in the system
(e.g. total energy), the latter do not (e.g. temperature). The
setting for <a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify norm</span></a> determines whether
extensive quantities are normalized or not. Computes and fixes
produce either extensive or intensive values; see their individual doc
pages for details. <a class="reference internal" href="variable.html"><span class="doc">Equal-style variables</span></a> produce only
intensive values; you can include a division by “natoms” in the
formula if desired, to make an extensive calculation produce an
<p>There is also a <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> format where the user
specifies what values are output with each atom. Pre-defined atom
attributes can be specified (id, x, fx, etc). Three additional kinds
of keywords can also be specified (c_ID, f_ID, v_name), where a
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> or <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> or <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>
provides the values to be output. In each case, the compute, fix, or
variable must generate per-atom values for input to the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command.</p>
<p>There is also a <a class="reference internal" href="dump.html"><span class="doc">dump local</span></a> format where the user specifies
what local values to output. A pre-defined index keyword can be
specified to enumuerate the local values. Two additional kinds of
keywords can also be specified (c_ID, f_ID), where a
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> or <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> or <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>
provides the values to be output. In each case, the compute or fix
must generate local values for input to the <a class="reference internal" href="dump.html"><span class="doc">dump local</span></a>
to a file of chunk-averaged per-atom quantities like those output in
dump files. Chunks can represent spatial bins or other collections of
atoms, e.g. individual molecules. The per-atom quantities can be atom
density (mass or number) or atom attributes such as position,
velocity, force. They can also be per-atom quantities calculated by a
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a>, by a <a class="reference internal" href="fix.html"><span class="doc">fix</span></a>, or by an atom-style
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a>. The chunk-averaged output of this fix can
also be used as input to other output commands.</p>
to a file of histogrammed quantities, which can be global or per-atom
or local quantities. The histogram output of this fix can also be
used as input to other output commands.</p>
<p>The <a class="reference internal" href="fix_ave_correlate.html"><span class="doc">fix ave/correlate</span></a> command enables direct
output to a file of time-correlated quantities, which can be global
values. The correlation matrix output of this fix can also be used as
input to other output commands.</p>
<p>The <a class="reference internal" href="fix_print.html"><span class="doc">fix print</span></a> command can generate a line of output
written to the screen and log file or to a separate file, periodically
during a running simulation. The line can contain one or more
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> values for any style variable except the
vector or atom styles). As explained above, variables themselves can
contain references to global values generated by <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic keywords</span></a>, <a class="reference internal" href="compute.html"><span class="doc">computes</span></a>,
<a class="reference internal" href="fix.html"><span class="doc">fixes</span></a>, or other <a class="reference internal" href="variable.html"><span class="doc">variables</span></a>, or to per-atom
values for a specific atom. Thus the <a class="reference internal" href="fix_print.html"><span class="doc">fix print</span></a>
command is a means to output a wide variety of quantities separate
from normal thermodynamic or dump file output.</p>
<span id="computeoutput"></span><h3>6.15.6. Computes that process output quantities</h3>
<p>The <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a> and <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce/region</span></a> commands take one or more per-atom
or local vector quantities as inputs and “reduce” them (sum, min, max,
ave) to scalar quantities. These are produced as output values which
can be used as input to other output commands.</p>
<p>The <a class="reference internal" href="compute_slice.html"><span class="doc">compute slice</span></a> command take one or more global
vector or array quantities as inputs and extracts a subset of their
values to create a new vector or array. These are produced as output
values which can be used as input to other output commands.</p>
<p>The <a class="reference internal" href="compute_property_atom.html"><span class="doc">compute property/atom</span></a> command takes a
list of one or more pre-defined atom attributes (id, x, fx, etc) and
stores the values in a per-atom vector or array. These are produced
as output values which can be used as input to other output commands.
The list of atom attributes is the same as for the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command.</p>
of per-atom vectors. The per-atom quantities can be atom attributes
such as position, velocity, force. They can also be per-atom
quantities calculated by a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>, by a
<a class="reference internal" href="fix.html"><span class="doc">fix</span></a>, or by an atom-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>. The
time-averaged per-atom output of this fix can be used as input to
other output commands.</p>
<p>The <a class="reference internal" href="fix_store_state.html"><span class="doc">fix store/state</span></a> command can archive one or
more per-atom attributes at a particular time, so that the old values
can be used in a future calculation or output. The list of atom
attributes is the same as for the <a class="reference internal" href="dump.html"><span class="doc">dump custom</span></a> command,
including per-atom quantities calculated by a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>,
by a <a class="reference internal" href="fix.html"><span class="doc">fix</span></a>, or by an atom-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>.
The output of this fix can be used as input to other output commands.</p>
<span id="howto-16"></span><h2>6.16. Thermostatting, barostatting, and computing temperature</h2>
<p>Thermostatting means controlling the temperature of particles in an MD
simulation. Barostatting means controlling the pressure. Since the
pressure includes a kinetic component due to particle velocities, both
these operations require calculation of the temperature. Typically a
target temperature (T) and/or pressure (P) is specified by the user,
and the thermostat or barostat attempts to equilibrate the system to
the requested T and/or P.</p>
<p>Temperature is computed as kinetic energy divided by some number of
degrees of freedom (and the Boltzmann constant). Since kinetic energy
is a function of particle velocity, there is often a need to
distinguish between a particle’s advection velocity (due to some
aggregate motiion of particles) and its thermal velocity. The sum of
the two is the particle’s total velocity, but the latter is often what
is wanted to compute a temperature.</p>
<p>LAMMPS has several options for computing temperatures, any of which
can be used in thermostatting and barostatting. These <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> calculate temperature, and the <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> command calculates pressure.</p>
<p><a class="reference internal" href="fix_nh.html"><span class="doc">Fix nvt</span></a> only thermostats the translational velocity of
particles. <a class="reference internal" href="fix_nvt_sllod.html"><span class="doc">Fix nvt/sllod</span></a> also does this, except
that it subtracts out a velocity bias due to a deforming box and
integrates the SLLOD equations of motion. See the <a class="reference internal" href="#howto-13"><span class="std std-ref">NEMD simulations</span></a> section of this page for further details. <a class="reference internal" href="fix_nvt_sphere.html"><span class="doc">Fix nvt/sphere</span></a> and <a class="reference internal" href="fix_nvt_asphere.html"><span class="doc">fix nvt/asphere</span></a> thermostat not only translation
velocities but also rotational velocities for spherical and aspherical
particles.</p>
<p>DPD thermostatting alters pairwise interactions in a manner analagous
to the per-particle thermostatting of <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a>.</p>
<p>Any of the thermostatting fixes can use temperature computes that
remove bias which has two effects. First, the current calculated
temperature, which is compared to the requested target temperature, is
caluclated with the velocity bias removed. Second, the thermostat
adjusts only the thermal temperature component of the particle’s
velocities, which are the velocities with the bias removed. The
removed bias is then added back to the adjusted velocities. See the
doc pages for the individual fixes and for the
<a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command for instructions on how to assign
a temperature compute to a thermostatting fix. For example, you can
apply a thermostat to only the x and z components of velocity by using
it in conjunction with <a class="reference internal" href="compute_temp_partial.html"><span class="doc">compute temp/partial</span></a>. Of you could thermostat only
the thermal temperature of a streaming flow of particles without
affecting the streaming velocity, by using <a class="reference internal" href="compute_temp_profile.html"><span class="doc">compute temp/profile</span></a>.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Only the nvt fixes perform time integration, meaning they update
the velocities and positions of particles due to forces and velocities
respectively. The other thermostat fixes only adjust velocities; they
do NOT perform time integration updates. Thus they should be used in
conjunction with a constant NVE integration fix such as these:</p>
<p>The <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> commands include a Nose-Hoover thermostat
and barostat. <a class="reference internal" href="fix_nh.html"><span class="doc">Fix nph</span></a> is just a Nose/Hoover barostat;
it does no thermostatting. Both <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> and <a class="reference internal" href="fix_press_berendsen.html"><span class="doc">fix press/bernendsen</span></a> can be used in conjunction
with any of the thermostatting fixes.</p>
<p>As with the thermostats, <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> and <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> only use translational motion of the particles in
computing T and P and performing thermo/barostatting. <a class="reference internal" href="fix_npt_sphere.html"><span class="doc">Fix npt/sphere</span></a> and <a class="reference internal" href="fix_npt_asphere.html"><span class="doc">fix npt/asphere</span></a> thermo/barostat using not only
translation velocities but also rotational velocities for spherical
and aspherical particles.</p>
<p>All of the barostatting fixes use the <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> compute to calculate a current
pressure. By default, this compute is created with a simple <a class="reference internal" href="compute_temp.html"><span class="doc">compute temp</span></a> (see the last argument of the <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> command), which is used to calculated
the kinetic component of the pressure. The barostatting fixes can
also use temperature computes that remove bias for the purpose of
computing the kinetic component which contributes to the current
pressure. See the doc pages for the individual fixes and for the
<a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command for instructions on how to assign
a temperature or pressure compute to a barostatting fix.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">As with the thermostats, the Nose/Hoover methods (<a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> and <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a>) perform time integration.
<a class="reference internal" href="fix_press_berendsen.html"><span class="doc">Fix press/berendsen</span></a> does NOT, so it should
be used with one of the constant NVE fixes or with one of the NVT
fixes.</p>
</div>
<p>Finally, thermodynamic output, which can be setup via the
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command, often includes temperature
and pressure values. As explained on the doc page for the
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command, the default T and P are
setup by the thermo command itself. They are NOT the ones associated
with any thermostatting or barostatting fix you have defined or with
any compute that calculates a temperature or pressure. Thus if you
want to view these values of T and P, you need to specify them
explicitly via a <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command. Or
you can use the <a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify</span></a> command to
re-define what temperature or pressure compute is used for default
thermodynamic output.</p>
<hr class="docutils" />
</div>
<div class="section" id="walls">
<span id="howto-17"></span><h2>6.17. Walls</h2>
<p>Walls in an MD simulation are typically used to bound particle motion,
i.e. to serve as a boundary condition.</p>
<p>Walls in LAMMPS can be of rough (made of particles) or idealized
surfaces. Ideal walls can be smooth, generating forces only in the
normal direction, or frictional, generating forces also in the
tangential direction.</p>
<p>Rough walls, built of particles, can be created in various ways. The
particles themselves can be generated like any other particle, via the
or read in via the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command.</p>
<p>Their motion can be constrained by many different commands, so that
they do not move at all, move together as a group at constant velocity
or in response to a net force acting on them, move in a prescribed
fashion (e.g. rotate around a point), etc. Note that if a time
integration fix like <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> or <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>
is not used with the group that contains wall particles, their
positions and velocities will not be updated.</p>
<ul class="simple">
<li><a class="reference internal" href="fix_aveforce.html"><span class="doc">fix aveforce</span></a> - set force on particles to average value, so they move together</li>
<li><a class="reference internal" href="fix_setforce.html"><span class="doc">fix setforce</span></a> - set force on particles to a value, e.g. 0.0</li>
<li><a class="reference internal" href="fix_freeze.html"><span class="doc">fix freeze</span></a> - freeze particles for use as granular walls</li>
<li><a class="reference internal" href="fix_nve_noforce.html"><span class="doc">fix nve/noforce</span></a> - advect particles by their velocity, but without force</li>
<li><a class="reference internal" href="fix_move.html"><span class="doc">fix move</span></a> - prescribe motion of particles by a linear velocity, oscillation, rotation, variable</li>
</ul>
<p>The <a class="reference internal" href="fix_move.html"><span class="doc">fix move</span></a> command offers the most generality, since
the motion of individual particles can be specified with
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> formula which depends on time and/or the
particle position.</p>
<p>For rough walls, it may be useful to turn off pairwise interactions
between wall particles via the <a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify exclude</span></a> command.</p>
<p>Rough walls can also be created by specifying frozen particles that do
not move and do not interact with mobile particles, and then tethering
other particles to the fixed particles, via a <a class="reference internal" href="bond_style.html"><span class="doc">bond</span></a>.
The bonded particles do interact with other mobile particles.</p>
<p>Idealized walls can be specified via several fix commands. <a class="reference internal" href="fix_wall_gran.html"><span class="doc">Fix wall/gran</span></a> creates frictional walls for use with
granular particles; all the other commands create smooth walls.</p>
<span id="howto-19"></span><h2>6.19. Library interface to LAMMPS</h2>
-<p>As described in <a class="reference internal" href="Section_start.html#start-5"><span class="std std-ref">Section_start 5</span></a>, LAMMPS
+<p>As described in <a class="reference internal" href="Section_start.html#start-5"><span class="std std-ref">Section 2.5</span></a>, LAMMPS
can be built as a library, so that it can be called by another code,
used in a <a class="reference internal" href="#howto-10"><span class="std std-ref">coupled manner</span></a> with other
codes, or driven through a <a class="reference internal" href="Section_python.html"><span class="doc">Python interface</span></a>.</p>
<p>All of these methodologies use a C-style interface to LAMMPS that is
provided in the files src/library.cpp and src/library.h. The
functions therein have a C-style argument list, but contain C++ code
you could write yourself in a C++ application that was invoking LAMMPS
directly. The C++ code in the functions illustrates how to invoke
internal LAMMPS operations. Note that LAMMPS classes are defined
within a LAMMPS namespace (LAMMPS_NS) if you use them from another C++
application.</p>
<p>Library.cpp contains these 5 basic functions:</p>
<pre class="literal-block">
void lammps_open(int, char **, MPI_Comm, void **)
void lammps_close(void *)
int lammps_version(void *)
void lammps_file(void *, char *)
char *lammps_command(void *, char *)
</pre>
<p>The lammps_open() function is used to initialize LAMMPS, passing in a
list of strings as if they were <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line arguments</span></a> when LAMMPS is run in
stand-alone mode from the command line, and a MPI communicator for
LAMMPS to run under. It returns a ptr to the LAMMPS object that is
created, and which is used in subsequent library calls. The
lammps_open() function can be called multiple times, to create
multiple instances of LAMMPS.</p>
<p>LAMMPS will run on the set of processors in the communicator. This
means the calling code can run LAMMPS on all or a subset of
processors. For example, a wrapper script might decide to alternate
between LAMMPS and another code, allowing them both to run on all the
processors. Or it might allocate half the processors to LAMMPS and
half to the other code and run both codes simultaneously before
syncing them up periodically. Or it might instantiate multiple
instances of LAMMPS to perform different calculations.</p>
<p>The lammps_close() function is used to shut down an instance of LAMMPS
and free all its memory.</p>
<p>The lammps_version() function can be used to determined the specific
version of the underlying LAMMPS code. This is particularly useful
when loading LAMMPS as a shared library via dlopen(). The code using
the library interface can than use this information to adapt to
changes to the LAMMPS command syntax between versions. The returned
LAMMPS version code is an integer (e.g. 2 Sep 2015 results in
20150902) that grows with every new LAMMPS version.</p>
<p>The lammps_file() and lammps_command() functions are used to pass a
file or string to LAMMPS as if it were an input script or single
command in an input script. Thus the calling code can read or
generate a series of LAMMPS commands one line at a time and pass it
thru the library interface to setup a problem and then run it,
interleaving the lammps_command() calls with other calls to extract
information from LAMMPS, perform its own operations, or call another
code’s library.</p>
<p>Other useful functions are also included in library.cpp. For example:</p>
<p>These can extract various global or per-atom quantities from LAMMPS as
well as values calculated by a compute, fix, or variable. The
“set_variable” function can set an existing string-style variable to a
new value, so that subsequent LAMMPS commands can access the variable.
The “get” and “put” operations can retrieve and reset atom
coordinates. See the library.cpp file and its associated header file
library.h for details.</p>
<p>The key idea of the library interface is that you can write any
functions you wish to define how your code talks to LAMMPS and add
them to src/library.cpp and src/library.h, as well as to the <a class="reference internal" href="Section_python.html"><span class="doc">Python interface</span></a>. The routines you add can access or
change any LAMMPS data you wish. The examples/COUPLE and python
directories have example C++ and C and Python codes which show how a
driver code can link to LAMMPS as a library, run LAMMPS on a subset of
processors, grab data from LAMMPS, change it, and put it back into
<p>The thermal conductivity kappa of a material can be measured in at
least 4 ways using various options in LAMMPS. See the examples/KAPPA
directory for scripts that implement the 4 methods discussed here for
a simple Lennard-Jones fluid model. Also, see <a class="reference internal" href="#howto-21"><span class="std std-ref">this section</span></a> of the manual for an analogous
discussion for viscosity.</p>
<p>The thermal conducitivity tensor kappa is a measure of the propensity
of a material to transmit heat energy in a diffusive manner as given
by Fourier’s law</p>
<p>J = -kappa grad(T)</p>
<p>where J is the heat flux in units of energy per area per time and
grad(T) is the spatial gradient of temperature. The thermal
conductivity thus has units of energy per distance per time per degree
K and is often approximated as an isotropic quantity, i.e. as a
scalar.</p>
<p>The first method is to setup two thermostatted regions at opposite
ends of a simulation box, or one in the middle and one at the end of a
periodic box. By holding the two regions at different temperatures
with a <a class="reference internal" href="#howto-13"><span class="std std-ref">thermostatting fix</span></a>, the energy
added to the hot region should equal the energy subtracted from the
cold region and be proportional to the heat flux moving between the
regions. See the papers by <a class="reference internal" href="#howto-ikeshoji"><span class="std std-ref">Ikeshoji and Hafskjold</span></a>
and <a class="reference internal" href="#howto-wirnsberger"><span class="std std-ref">Wirnsberger et al</span></a> for details of this idea.
Note that thermostatting fixes such as <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>, <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a>, and <a class="reference internal" href="fix_temp_rescale.html"><span class="doc">fix temp/rescale</span></a> store the cumulative energy they
add/subtract.</p>
<p>Alternatively, as a second method, the <a class="reference internal" href="fix_heat.html"><span class="doc">fix heat</span></a> or
<a class="reference internal" href="fix_ehex.html"><span class="doc">fix ehex</span></a> commands can be used in place of thermostats
on each of two regions to add/subtract specified amounts of energy to
both regions. In both cases, the resulting temperatures of the two
regions can be monitored with the “compute temp/region” command and
the temperature profile of the intermediate region can be monitored
with the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> and <a class="reference internal" href="compute_ke_atom.html"><span class="doc">compute ke/atom</span></a> commands.</p>
<p>The third method is to perform a reverse non-equilibrium MD simulation
using the <a class="reference internal" href="fix_thermal_conductivity.html"><span class="doc">fix thermal/conductivity</span></a>
command which implements the rNEMD algorithm of Muller-Plathe.
Kinetic energy is swapped between atoms in two different layers of the
simulation box. This induces a temperature gradient between the two
layers which can be monitored with the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> and <a class="reference internal" href="compute_ke_atom.html"><span class="doc">compute ke/atom</span></a> commands. The fix tallies the
cumulative energy transfer that it performs. See the <a class="reference internal" href="fix_thermal_conductivity.html"><span class="doc">fix thermal/conductivity</span></a> command for
details.</p>
<p>The fourth method is based on the Green-Kubo (GK) formula which
relates the ensemble average of the auto-correlation of the heat flux
to kappa. The heat flux can be calculated from the fluctuations of
per-atom potential and kinetic energies and per-atom stress tensor in
a steady-state equilibrated simulation. This is in contrast to the
two preceding non-equilibrium methods, where energy flows continuously
between hot and cold regions of the simulation box.</p>
<p>The <a class="reference internal" href="compute_heat_flux.html"><span class="doc">compute heat/flux</span></a> command can calculate
the needed heat flux and describes how to implement the Green_Kubo
formalism using additional LAMMPS commands, such as the <a class="reference internal" href="fix_ave_correlate.html"><span class="doc">fix ave/correlate</span></a> command to calculate the needed
auto-correlation. See the doc page for the <a class="reference internal" href="compute_heat_flux.html"><span class="doc">compute heat/flux</span></a> command for an example input script
that calculates the thermal conductivity of solid Ar via the GK
<p>The shear viscosity eta of a fluid can be measured in at least 5 ways
using various options in LAMMPS. See the examples/VISCOSITY directory
for scripts that implement the 5 methods discussed here for a simple
Lennard-Jones fluid model. Also, see <a class="reference internal" href="#howto-20"><span class="std std-ref">this section</span></a> of the manual for an analogous
discussion for thermal conductivity.</p>
<p>Eta is a measure of the propensity of a fluid to transmit momentum in
a direction perpendicular to the direction of velocity or momentum
flow. Alternatively it is the resistance the fluid has to being
sheared. It is given by</p>
<p>J = -eta grad(Vstream)</p>
<p>where J is the momentum flux in units of momentum per area per time.
and grad(Vstream) is the spatial gradient of the velocity of the fluid
moving in another direction, normal to the area through which the
momentum flows. Viscosity thus has units of pressure-time.</p>
<p>The first method is to perform a non-equlibrium MD (NEMD) simulation
by shearing the simulation box via the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a>
command, and using the <a class="reference internal" href="fix_nvt_sllod.html"><span class="doc">fix nvt/sllod</span></a> command to
thermostat the fluid via the SLLOD equations of motion.
Alternatively, as a second method, one or more moving walls can be
used to shear the fluid in between them, again with some kind of
thermostat that modifies only the thermal (non-shearing) components of
velocity to prevent the fluid from heating up.</p>
<p>In both cases, the velocity profile setup in the fluid by this
procedure can be monitored by the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> command, which determines
grad(Vstream) in the equation above. E.g. the derivative in the
y-direction of the Vx component of fluid motion or grad(Vstream) =
dVx/dy. The Pxy off-diagonal component of the pressure or stress
tensor, as calculated by the <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a>
command, can also be monitored, which is the J term in the equation
above. See <a class="reference internal" href="#howto-13"><span class="std std-ref">this section</span></a> of the manual
for details on NEMD simulations.</p>
<p>The third method is to perform a reverse non-equilibrium MD simulation
using the <a class="reference internal" href="fix_viscosity.html"><span class="doc">fix viscosity</span></a> command which implements
the rNEMD algorithm of Muller-Plathe. Momentum in one dimension is
swapped between atoms in two different layers of the simulation box in
a different dimension. This induces a velocity gradient which can be
monitored with the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a> command.
The fix tallies the cummulative momentum transfer that it performs.
See the <a class="reference internal" href="fix_viscosity.html"><span class="doc">fix viscosity</span></a> command for details.</p>
<p>The fourth method is based on the Green-Kubo (GK) formula which
relates the ensemble average of the auto-correlation of the
stress/pressure tensor to eta. This can be done in a fully
equilibrated simulation which is in contrast to the two preceding
non-equilibrium methods, where momentum flows continuously through the
simulation box.</p>
<p>Here is an example input script that calculates the viscosity of
liquid Ar via the GK formalism:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># Sample LAMMPS input script for viscosity of liquid Ar</span>
</pre></div>
</div>
<pre class="literal-block">
units real
variable T equal 86.4956
variable V equal vol
variable dt equal 4.0
variable p equal 400 # correlation length
variable s equal 5 # sample interval
variable d equal $p*$s # dump interval
</pre>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># convert from LAMMPS real units to SI</span>
<a class="reference internal" href="variable.html"><span class="doc">variables</span></a> to be used to define chunk IDs for each
atom. This means you can write your own compute or fix to output a
per-atom quantity to use as chunk ID. See
-<a class="reference internal" href="Section_modify.html"><span class="doc">Section_modify</span></a> of the documentation for how to
+<a class="reference internal" href="Section_modify.html"><span class="doc">Section 10</span></a> of the documentation for how to
do this. You can also define a <a class="reference internal" href="variable.html"><span class="doc">per-atom variable</span></a> in
the input script that uses a formula to generate a chunk ID for each
atom.</p>
</div>
<div class="section" id="fix-ave-chunk-command">
<h3>6.23.2. Fix ave/chunk command:</h3>
<p>This fix takes the ID of a <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command as input. For each chunk,
it then sums one or more specified per-atom values over the atoms in
each chunk. The per-atom values can be any atom property, such as
etc. Additional keywords are defined for per-chunk properties like
density and temperature. More generally any per-atom value generated
by other <a class="reference internal" href="compute.html"><span class="doc">computes</span></a>, <a class="reference internal" href="fix.html"><span class="doc">fixes</span></a>, and <a class="reference internal" href="variable.html"><span class="doc">per-atom variables</span></a>, can be summed over atoms in each chunk.</p>
<p>Similar to other averaging fixes, this fix allows the summed per-chunk
values to be time-averaged in various ways, and output to a file. The
fix produces a global array as output with one row of values per
chunk.</p>
</div>
<div class="section" id="compute-chunk-commands">
<h3>6.23.3. Compute */chunk commands:</h3>
<p>Currently the following computes operate on chunks of atoms to produce
<p>They each take the ID of a <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command as input. As their names
indicate, they calculate the center-of-mass, radius of gyration,
moments of inertia, mean-squared displacement, temperature, torque,
and velocity of center-of-mass for each chunk of atoms. The <a class="reference internal" href="compute_property_chunk.html"><span class="doc">compute property/chunk</span></a> command can tally the
count of atoms in each chunk and extract other per-chunk properties.</p>
<p>The reason these various calculations are not part of the <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk command</span></a>, is that each requires a more
complicated operation than simply summing and averaging over per-atom
values in each chunk. For example, many of them require calculation
of a center of mass, which requires summing mass*position over the
atoms and then dividing by summed mass.</p>
<p>All of these computes produce a global vector or global array as
output, wih one or more values per chunk. They can be used
in various ways:</p>
<ul class="simple">
<li>As input to the <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a> command, which can
write the values to a file and optionally time average them.</li>
<li>As input to the <a class="reference internal" href="fix_ave_histo.html"><span class="doc">fix ave/histo</span></a> command to
histogram values across chunks. E.g. a histogram of cluster sizes or
molecule diffusion rates.</li>
<li>As input to special functions of <a class="reference internal" href="variable.html"><span class="doc">equal-style variables</span></a>, like sum() and max(). E.g. to find the
largest cluster or fastest diffusing molecule.</li>
<p>The adiabatic core-shell model by <a class="reference internal" href="pair_cs.html#mitchellfinchham"><span class="std std-ref">Mitchell and Finchham</span></a> is a simple method for adding
polarizability to a system. In order to mimic the electron shell of
an ion, a satellite particle is attached to it. This way the ions are
split into a core and a shell where the latter is meant to react to
the electrostatic environment inducing polarizability.</p>
<p>Technically, shells are attached to the cores by a spring force f =
k*r where k is a parametrized spring constant and r is the distance
between the core and the shell. The charges of the core and the shell
add up to the ion charge, thus q(ion) = q(core) + q(shell). This
setup introduces the ion polarizability (alpha) given by
alpha = q(shell)^2 / k. In a
similar fashion the mass of the ion is distributed on the core and the
shell with the core having the larger mass.</p>
<p>To run this model in LAMMPS, <a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a> <em>full</em> can
be used since atom charge and bonds are needed. Each kind of
core/shell pair requires two atom types and a bond type. The core and
shell of a core/shell pair should be bonded to each other with a
harmonic bond that provides the spring force. For example, a data file
for NaCl, as found in examples/coreshell, has this format:</p>
<span class="mi">216</span> <span class="n">bonds</span> <span class="c1"># number of core/shell springs</span>
</pre></div>
</div>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="mi">4</span> <span class="n">atom</span> <span class="n">types</span> <span class="c1"># 2 cores and 2 shells for Na and Cl</span>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">Bonds</span> <span class="c1"># Bond topology for spring forces</span>
</pre></div>
</div>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="mi">1</span> <span class="mi">2</span> <span class="mi">1</span> <span class="mi">2</span> <span class="c1"># spring for core/shell pair 1</span>
<span class="mi">2</span> <span class="mi">2</span> <span class="mi">3</span> <span class="mi">4</span> <span class="c1"># spring for core/shell pair 2</span>
<p>Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only
defined between the shells. Coulombic interactions are defined
between all cores and shells. If desired, additional bonds can be
specified between cores.</p>
<p>The <a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command should be used to
turn-off the Coulombic interaction within core/shell pairs, since that
interaction is set by the bond spring. This is done using the
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command with a 1-2 weight = 0.0,
which is the default value. It needs to be considered whether one has
to adjust the <a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> weighting according
to the molecular topology since the interactions of the shells are
bypassed over an extra bond.</p>
<p>Note that this core/shell implementation does not require all ions to
be polarized. One can mix core/shell pairs and ions without a
satellite particle if desired.</p>
<p>Since the core/shell model permits distances of r = 0.0 between the
core and shell, a pair style with a “cs” suffix needs to be used to
implement a valid long-range Coulombic correction. Several such pair
styles are provided in the CORESHELL package. See <a class="reference internal" href="pair_cs.html"><span class="doc">this doc page</span></a> for details. All of the core/shell enabled pair
styles require the use of a long-range Coulombic solver, as specified
by the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command. Either the PPPM or
Ewald solvers can be used.</p>
<p>For the NaCL example problem, these pair style and bond style settings
<p>When running dynamics with the adiabatic core/shell model, the
following issues should be considered. Since the relative motion of
the core and shell particles corresponds to the polarization, typical
thermostats can alter the polarization behaviour, meaning the shell
will not react freely to its electrostatic environment. This is
critical during the equilibration of the system. Therefore
it’s typically desirable to decouple the relative motion of the
core/shell pair, which is an imaginary degree of freedom, from the
real physical system. To do that, the <a class="reference internal" href="compute_temp_cs.html"><span class="doc">compute temp/cs</span></a> command can be used, in conjunction with
any of the thermostat fixes, such as <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> or <a class="reference external" href="fix_langevin">fix langevin</a>. This compute uses the center-of-mass velocity
of the core/shell pairs to calculate a temperature, and insures that
velocity is what is rescaled for thermostatting purposes. This
compute also works for a system with both core/shell pairs and
non-polarized ions (ions without an attached satellite particle). The
<a class="reference internal" href="compute_temp_cs.html"><span class="doc">compute temp/cs</span></a> command requires input of two
groups, one for the core atoms, another for the shell atoms.
Non-polarized ions which might also be included in the treated system
should not be included into either of these groups, they are taken
into account by the <em>group-ID</em> (2nd argument) of the compute. The
groups can be defined using the <a class="reference internal" href="group.html"><span class="doc">group *type*</span></a> command.
Note that to perform thermostatting using this definition of
temperature, the <a class="reference internal" href="fix_modify.html"><span class="doc">fix modify temp</span></a> command should be
used to assign the compute to the thermostat fix. Likewise the
<a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify temp</span></a> command can be used to make
this temperature be output for the overall system.</p>
<p>For the NaCl example, this can be done as follows:</p>
<pre class="literal-block">
group cores type 1 2
group shells type 3 4
compute CSequ all temp/cs cores shells
fix thermoberendsen all temp/berendsen 1427 1427 0.4 # thermostat for the true physical system
fix thermostatequ all nve # integrator as needed for the berendsen thermostat
fix_modify thermoberendsen temp CSequ
thermo_modify temp CSequ # output of center-of-mass derived temperature
</pre>
<p>If <a class="reference internal" href="compute_temp_cs.html"><span class="doc">compute temp/cs</span></a> is used, the decoupled
relative motion of the core and the shell should in theory be
stable. However numerical fluctuation can introduce a small
momentum to the system, which is noticable over long trajectories.
Therefore it is recomendable to use the <a class="reference internal" href="fix_momentum.html"><span class="doc">fix momentum</span></a> command in combination with <a class="reference internal" href="compute_temp_cs.html"><span class="doc">compute temp/cs</span></a> when equilibrating the system to
prevent any drift.</p>
<p>When intializing the velocities of a system with core/shell pairs, it
is also desirable to not introduce energy into the relative motion of
the core/shell particles, but only assign a center-of-mass velocity to
the pairs. This can be done by using the <em>bias</em> keyword of the
<a class="reference internal" href="velocity.html"><span class="doc">velocity create</span></a> command and assigning the <a class="reference internal" href="compute_temp_cs.html"><span class="doc">compute temp/cs</span></a> command to the <em>temp</em> keyword of the
<p>It is important to note that the polarizability of the core/shell
pairs is based on their relative motion. Therefore the choice of
spring force and mass ratio need to ensure much faster relative motion
of the 2 atoms within the core/shell pair than their center-of-mass
velocity. This allow the shells to effectively react instantaneously
to the electrostatic environment. This fast movement also limits the
timestep size that can be used.</p>
<p>The primary literature of the adiabatic core/shell model suggests that
the fast relative motion of the core/shell pairs only allows negligible
energy transfer to the environment. Therefore it is not intended to
decouple the core/shell degree of freedom from the physical system
during production runs. In other words, the <a class="reference internal" href="compute_temp_cs.html"><span class="doc">compute temp/cs</span></a> command should not be used during
production runs and is only required during equilibration. This way one
is consistent with literature (based on the code packages DL_POLY or
GULP for instance).</p>
<p>The mentioned energy transfer will typically lead to a a small drift
in total energy over time. This internal energy can be monitored
using the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> and <a class="reference internal" href="compute_temp_chunk.html"><span class="doc">compute temp/chunk</span></a> commands. The internal kinetic
energies of each core/shell pair can then be summed using the sum()
special function of the <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command. Or they can
be time/averaged and output using the <a class="reference internal" href="fix_ave_time.html"><span class="doc">fix ave/time</span></a>
command. To use these commands, each core/shell pair must be defined
as a “chunk”. If each core/shell pair is defined as its own molecule,
the molecule ID can be used to define the chunks. If cores are bonded
to each other to form larger molecules, the chunks can be identified
by the <a class="reference internal" href="fix_property_atom.html"><span class="doc">fix property/atom</span></a> via assigning a
core/shell ID to each atom using a special field in the data file read
by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command. This field can then be
accessed by the <a class="reference internal" href="compute_property_atom.html"><span class="doc">compute property/atom</span></a>
command, to use as input to the <a class="reference internal" href="compute_chunk_atom.html"><span class="doc">compute chunk/atom</span></a> command to define the core/shell
pairs as chunks.</p>
<p>For example,</p>
<pre class="literal-block">
fix csinfo all property/atom i_CSID # property/atom command
read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info # atom property added in the data-file
compute prop all property/atom i_CSID
compute cs_chunk all chunk/atom c_prop
compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0 # note the chosen degrees of freedom for the core/shell pairs
<p>The thermalized Drude model, similarly to the <a class="reference internal" href="#howto-26"><span class="std std-ref">core-shell</span></a>
model, representes induced dipoles by a pair of charges (the core atom
and the Drude particle) connected by a harmonic spring. The Drude
model has a number of features aimed at its use in molecular systems
(<a class="reference internal" href="#howto-lamoureux"><span class="std std-ref">Lamoureux and Roux</span></a>):</p>
<ul class="simple">
<li>Thermostating of the additional degrees of freedom associated with the
induced dipoles at very low temperature, in terms of the reduced
coordinates of the Drude particles with respect to their cores. This
makes the trajectory close to that of relaxed induced dipoles.</li>
<li>Consistent definition of 1-2 to 1-4 neighbors. A core-Drude particle
pair represents a single (polarizable) atom, so the special screening
factors in a covalent structure should be the same for the core and
the Drude particle. Drude particles have to inherit the 1-2, 1-3, 1-4
special neighbor relations from their respective cores.</li>
<li>Stabilization of the interactions between induced dipoles. Drude
dipoles on covalently bonded atoms interact too strongly due to the
short distances, so an atom may capture the Drude particle of a
neighbor, or the induced dipoles within the same molecule may align
too much. To avoid this, damping at short range can be done by Thole
functions (for which there are physical grounds). This Thole damping
is applied to the point charges composing the induced dipole (the
charge of the Drude particle and the opposite charge on the core, not
to the total charge of the core atom).</li>
</ul>
<p>A detailed tutorial covering the usage of Drude induced dipoles in
LAMMPS is <a class="reference internal" href="tutorial_drude.html"><span class="doc">available here</span></a>.</p>
<p>As with the core-shell model, the cores and Drude particles should
appear in the data file as standard atoms. The same holds for the
springs between them, which are described by standard harmonic bonds.
The nature of the atoms (core, Drude particle or non-polarizable) is
specified via the <a class="reference internal" href="fix_drude.html"><span class="doc">fix drude</span></a> command. The special
list of neighbors is automatically refactored to account for the
equivalence of core and Drude particles as regards special 1-2 to 1-4
screening. It may be necessary to use the <em>extra</em> keyword of the
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command. If using <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a>, make sure no Drude particle is in this fix
group.</p>
<p>There are two ways to thermostat the Drude particles at a low
temperature: use either <a class="reference internal" href="fix_langevin_drude.html"><span class="doc">fix langevin/drude</span></a>
for a Langevin thermostat, or <a class="reference internal" href="fix_drude_transform.html"><span class="doc">fix drude/transform/*</span></a> for a Nose-Hoover
thermostat. The former requires use of the command <a class="reference internal" href="comm_modify.html"><span class="doc">comm_modify vel yes</span></a>. The latter requires two separate integration
fixes like <em>nvt</em> or <em>npt</em>. The correct temperatures of the reduced
degrees of freedom can be calculated using the <a class="reference internal" href="compute_temp_drude.html"><span class="doc">compute temp/drude</span></a>. This requires also to use the
command <em>comm_modify vel yes</em>.</p>
<p>Short-range damping of the induced dipole interactions can be achieved
using Thole functions through the the <a class="reference internal" href="pair_thole.html"><span class="doc">pair style thole</span></a> in <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid/overlay</span></a>
with a Coulomb pair style. It may be useful to use <em>coul/long/cs</em> or
similar from the CORESHELL package if the core and Drude particle come
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>energy minimization via conjugate gradient or steepest descent relaxation</li>
<li>rRESPA hierarchical timestepping</li>
<li>rerun command for post-processing of dump files</li>
</ul>
</div>
<div class="section" id="diagnostics">
<h3>1.2.7. Diagnostics</h3>
<ul class="simple">
<li>see the various flavors of the <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> and <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> commands</li>
<li>Various pre- and post-processing serial tools are packaged
with LAMMPS; see these <a class="reference internal" href="Section_tools.html"><span class="doc">doc pages</span></a>.</li>
<li>Our group has also written and released a separate toolkit called
<a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</a> which provides tools for doing setup, analysis,
plotting, and visualization for LAMMPS simulations. Pizza.py is
written in <a class="reference external" href="http://www.python.org">Python</a> and is available for download from <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">the Pizza.py WWW site</a>.</li>
</ul>
</div>
<div class="section" id="specialized-features">
<h3>1.2.11. Specialized features</h3>
<p>These are LAMMPS capabilities which you may not think of as typical
<li>perform sophisticated analyses of your MD simulation</li>
<li>visualize your MD simulation</li>
<li>plot your output data</li>
</ul>
<p>A few tools for pre- and post-processing tasks are provided as part of
the LAMMPS package; they are described in <a class="reference internal" href="Section_tools.html"><span class="doc">this section</span></a>. However, many people use other codes or
write their own tools for these tasks.</p>
<p>As noted above, our group has also written and released a separate
toolkit called <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</a> which addresses some of the listed
bullets. It provides tools for doing setup, analysis, plotting, and
visualization for LAMMPS simulations. Pizza.py is written in
<a class="reference external" href="http://www.python.org">Python</a> and is available for download from <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">the Pizza.py WWW site</a>.</p>
<p>LAMMPS requires as input a list of initial atom coordinates and types,
molecular topology information, and force-field coefficients assigned
to all atoms and bonds. LAMMPS will not build molecular systems and
assign force-field parameters for you.</p>
<p>For atomic systems LAMMPS provides a <a class="reference internal" href="create_atoms.html"><span class="doc">create_atoms</span></a>
command which places atoms on solid-state lattices (fcc, bcc,
user-defined, etc). Assigning small numbers of force field
coefficients can be done via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair coeff</span></a>, <a class="reference internal" href="bond_coeff.html"><span class="doc">bond coeff</span></a>, <a class="reference internal" href="angle_coeff.html"><span class="doc">angle coeff</span></a>, etc commands.
For molecular systems or more complicated simulation geometries, users
typically use another code as a builder and convert its output to
LAMMPS input format, or write their own code to generate atom
coordinate and molecular topology for LAMMPS to read in.</p>
<p>For complicated molecular systems (e.g. a protein), a multitude of
topology information and hundreds of force-field coefficients must
typically be specified. We suggest you use a program like
<a class="reference external" href="http://www.scripps.edu/brooks">CHARMM</a> or <a class="reference external" href="http://amber.scripps.edu">AMBER</a> or other molecular builders to setup
such problems and dump its information to a file. You can then
reformat the file as LAMMPS input. Some of the tools in <a class="reference internal" href="Section_tools.html"><span class="doc">this section</span></a> can assist in this process.</p>
<p>Similarly, LAMMPS creates output files in a simple format. Most users
post-process these files with their own analysis tools or re-format
them for input into other programs, including visualization packages.
If you are convinced you need to compute something on-the-fly as
-LAMMPS runs, see <a class="reference internal" href="Section_modify.html"><span class="doc">Section_modify</span></a> for a discussion
+LAMMPS runs, see <a class="reference internal" href="Section_modify.html"><span class="doc">Section 10</span></a> for a discussion
of how you can use the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> and <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> and
<a class="reference internal" href="fix.html"><span class="doc">fix</span></a> commands to print out data of your choosing. Keep in
mind that complicated computations can slow down the molecular
dynamics timestepping, particularly if the computations are not
parallel, so it is often better to leave such analysis to
post-processing codes.</p>
<p>A very simple (yet fast) visualizer is provided with the LAMMPS
package - see the <a class="reference internal" href="Section_tools.html#xmovie"><span class="std std-ref">xmovie</span></a> tool in <a class="reference internal" href="Section_tools.html"><span class="doc">this section</span></a>. It creates xyz projection views of
atomic coordinates and animates them. We find it very useful for
debugging purposes. For high-quality visualization we recommend the
<span id="intro-4"></span><h2>1.4. Open source distribution</h2>
<p>LAMMPS comes with no warranty of any kind. As each source file states
in its header, it is a copyrighted code that is distributed free-of-
charge, under the terms of the <a class="reference external" href="http://www.gnu.org/copyleft/gpl.html">GNU Public License</a> (GPL). This
is often referred to as open-source distribution - see
<a class="reference external" href="http://www.gnu.org">www.gnu.org</a> or <a class="reference external" href="http://www.opensource.org">www.opensource.org</a> for more
details. The legal text of the GPL is in the LICENSE file that is
included in the LAMMPS distribution.</p>
<p>Here is a summary of what the GPL means for LAMMPS users:</p>
<p>(1) Anyone is free to use, modify, or extend LAMMPS in any way they
choose, including for commercial purposes.</p>
<p>(2) If you distribute a modified version of LAMMPS, it must remain
open-source, meaning you distribute it under the terms of the GPL.
You should clearly annotate such a code as a derivative version of
LAMMPS.</p>
<p>(3) If you release any code that includes LAMMPS source code, then it
must also be open-sourced, meaning you distribute it under the terms
of the GPL.</p>
<p>(4) If you give LAMMPS files to someone else, the GPL LICENSE file and
source file headers (including the copyright and GPL notices) should
remain part of the code.</p>
<p>In the spirit of an open-source code, these are various ways you can
contribute to making LAMMPS better. You can send email to the
<a class="reference external" href="http://lammps.sandia.gov/authors.html">developers</a> on any of these
items.</p>
<ul class="simple">
<li>Point prospective users to the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>. Mention it in
talks or link to it from your WWW site.</li>
<li>If you find an error or omission in this manual or on the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>, or have a suggestion for something to clarify or include,
-<li>If you find a bug, <a class="reference internal" href="Section_errors.html#err-2"><span class="std std-ref">Section_errors 2</span></a>
+<li>If you find a bug, <a class="reference internal" href="Section_errors.html#err-2"><span class="std std-ref">Section 12.2</span></a>
describes how to report it.</li>
<li>If you publish a paper using LAMMPS results, send the citation (and
any cool pictures or movies if you like) to add to the Publications,
Pictures, and Movies pages of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>, with links
and attributions back to you.</li>
<li>Create a new Makefile.machine that can be added to the src/MAKE
directory.</li>
<li>The tools sub-directory of the LAMMPS distribution has various
stand-alone codes for pre- and post-processing of LAMMPS data. More
-details are given in <a class="reference internal" href="Section_tools.html"><span class="doc">Section_tools</span></a>. If you write
+details are given in <a class="reference internal" href="Section_tools.html"><span class="doc">Section 9</span></a>. If you write
a new tool that users will find useful, it can be added to the LAMMPS
distribution.</li>
<li>LAMMPS is designed to be easy to extend with new code for features
like potentials, boundary conditions, diagnostic computations, etc.
<a class="reference internal" href="Section_modify.html"><span class="doc">This section</span></a> gives details. If you add a
feature of general interest, it can be added to the LAMMPS
distribution.</li>
<li>The Benchmark page of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a> lists LAMMPS
performance on various platforms. The files needed to run the
benchmarks are part of the LAMMPS distribution. If your machine is
sufficiently different from those listed, your timing data can be
added to the page.</li>
<li>You can send feedback for the User Comments page of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>. It might be added to the page. No promises.</li>
<li>Cash. Small denominations, unmarked bills preferred. Paper sack OK.
Leave on desk. VISA also accepted. Chocolate chip cookies
<span id="intro-5"></span><h2>1.5. Acknowledgments and citations</h2>
<p>LAMMPS development has been funded by the <a class="reference external" href="http://www.doe.gov">US Department of Energy</a> (DOE), through its CRADA, LDRD, ASCI, and Genomes-to-Life
programs and its <a class="reference external" href="http://www.sc.doe.gov/ascr/home.html">OASCR</a> and <a class="reference external" href="http://www.er.doe.gov/production/ober/ober_top.html">OBER</a> offices.</p>
<p>Specifically, work on the latest version was funded in part by the US
Department of Energy’s Genomics:GTL program
(<a class="reference external" href="http://www.doegenomestolife.org">www.doegenomestolife.org</a>) under the <a class="reference external" href="http://www.genomes2life.org">project</a>, “Carbon
Sequestration in Synechococcus Sp.: From Molecular Machines to
Hierarchical Modeling”.</p>
<p>The following paper describe the basic parallel algorithms used in
LAMMPS. If you use LAMMPS results in your published work, please cite
this paper and include a pointer to the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>
<p>Other papers describing specific algorithms used in LAMMPS are listed
under the <a class="reference external" href="http://lammps.sandia.gov/cite.html">Citing LAMMPS link</a> of
the LAMMPS WWW page.</p>
<p>The <a class="reference external" href="http://lammps.sandia.gov/papers.html">Publications link</a> on the
LAMMPS WWW page lists papers that have cited LAMMPS. If your paper is
not listed there for some reason, feel free to send us the info. If
the simulations in your paper produced cool pictures or animations,
we’ll be pleased to add them to the
<a class="reference external" href="http://lammps.sandia.gov/pictures.html">Pictures</a> or
<a class="reference external" href="http://lammps.sandia.gov/movies.html">Movies</a> pages of the LAMMPS WWW
site.</p>
<p>The core group of LAMMPS developers is at Sandia National Labs:</p>
<ul class="simple">
<li>Steve Plimpton, sjplimp at sandia.gov</li>
<li>Aidan Thompson, athomps at sandia.gov</li>
<li>Paul Crozier, pscrozi at sandia.gov</li>
</ul>
<p>The following folks are responsible for significant contributions to
the code, or other aspects of the LAMMPS development effort. Many of
the packages they have written are somewhat unique to LAMMPS and the
code would not be as general-purpose as it is without their expertise
and efforts.</p>
<ul class="simple">
<li>Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CG-CMM and USER-OMP packages</li>
<li>Roy Pollock (LLNL), Ewald and PPPM solvers</li>
<li>Mike Brown (ORNL), brownw at ornl.gov, GPU package</li>
<li>Greg Wagner (Sandia), gjwagne at sandia.gov, MEAM package for MEAM potential</li>
<li>Mike Parks (Sandia), mlparks at sandia.gov, PERI package for Peridynamics</li>
<li>Rudra Mukherjee (JPL), Rudranarayan.M.Mukherjee at jpl.nasa.gov, POEMS package for articulated rigid body motion</li>
<li>Reese Jones (Sandia) and collaborators, rjones at sandia.gov, USER-ATC package for atom/continuum coupling</li>
<li>Ilya Valuev (JIHT), valuev at physik.hu-berlin.de, USER-AWPMD package for wave-packet MD</li>
<li>Christian Trott (U Tech Ilmenau), christian.trott at tu-ilmenau.de, USER-CUDA package</li>
<li>Andres Jaramillo-Botero (Caltech), ajaramil at wag.caltech.edu, USER-EFF package for electron force field</li>
<li>Christoph Kloss (JKU), Christoph.Kloss at jku.at, USER-LIGGGHTS package for granular models and granular/fluid coupling</li>
<li>Metin Aktulga (LBL), hmaktulga at lbl.gov, USER-REAXC package for C version of ReaxFF</li>
<li>Georg Gunzenmuller (EMI), georg.ganzenmueller at emi.fhg.de, USER-SPH package</li>
</ul>
-<p>As discussed in <a class="reference internal" href="Section_history.html"><span class="doc">Section_history</span></a>, LAMMPS
+<p>As discussed in <a class="reference internal" href="Section_history.html"><span class="doc">Section 13</span></a>, LAMMPS
originated as a cooperative project between DOE labs and industrial
partners. Folks involved in the design and testing of the original
version of LAMMPS were the following:</p>
<ul class="simple">
<li>John Carpenter (Mayo Clinic, formerly at Cray Research)</li>
<li>Terry Stouch (Lexicon Pharmaceuticals, formerly at Bristol Myers Squibb)</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>.
<li class="toctree-l2"><a class="reference internal" href="#submitting-new-features-for-inclusion-in-lammps">10.15. Submitting new features for inclusion in LAMMPS</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
<div class="line">10.6 <a class="reference internal" href="#mod-6"><span class="std std-ref">Fix styles</span></a> which include integrators, temperature and pressure control, force constraints, boundary conditions, diagnostic output, etc</div>
<div class="line">10.15 <a class="reference internal" href="#mod-15"><span class="std std-ref">Submitting new features for inclusion in LAMMPS</span></a></div>
<div class="line"><br /></div>
</div>
<p>LAMMPS is designed in a modular fashion so as to be easy to modify and
extend with new functionality. In fact, about 75% of its source code
is files added in this fashion.</p>
<p>In this section, changes and additions users can make are listed along
with minimal instructions. If you add a new feature to LAMMPS and
think it will be of interest to general users, we encourage you to
submit it to the developers for inclusion in the released version of
LAMMPS. Information about how to do this is provided
<td>retreive extra info unique to this atom style (optional)</td>
</tr>
<tr class="row-odd"><td>pack_exchange</td>
<td>store all an atom’s info to migrate to another processor (required)</td>
</tr>
<tr class="row-even"><td>unpack_exchange</td>
<td>retrieve an atom’s info from the buffer (required)</td>
</tr>
<tr class="row-odd"><td>size_restart</td>
<td>number of restart quantities associated with proc’s atoms (required)</td>
</tr>
<tr class="row-even"><td>pack_restart</td>
<td>pack atom quantities into a buffer (required)</td>
</tr>
<tr class="row-odd"><td>unpack_restart</td>
<td>unpack atom quantities from a buffer (required)</td>
</tr>
<tr class="row-even"><td>create_atom</td>
<td>create an individual atom of this style (required)</td>
</tr>
<tr class="row-odd"><td>data_atom</td>
<td>parse an atom line from the data file (required)</td>
</tr>
<tr class="row-even"><td>data_atom_hybrid</td>
<td>parse additional atom info unique to this atom style (optional)</td>
</tr>
<tr class="row-odd"><td>data_vel</td>
<td>parse one line of velocity information from data file (optional)</td>
</tr>
<tr class="row-even"><td>data_vel_hybrid</td>
<td>parse additional velocity data unique to this atom style (optional)</td>
</tr>
<tr class="row-odd"><td>memory_usage</td>
<td>tally memory allocated by atom arrays (required)</td>
</tr>
</tbody>
</table>
<p>The constructor of the derived class sets values for several variables
that you must set when defining a new atom style, which are documented
in atom_vec.h. New atom arrays are defined in atom.cpp. Search for
the word “customize” and you will find locations you will need to
modify.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">It is possible to add some attributes, such as a molecule ID, to
atom styles that do not have them via the <a class="reference internal" href="fix_property_atom.html"><span class="doc">fix property/atom</span></a> command. This command also
allows new custom attributes consisting of extra integer or
floating-point values to be added to atoms. See the <a class="reference internal" href="fix_property_atom.html"><span class="doc">fix property/atom</span></a> doc page for examples of cases
where this is useful and details on how to initialize, access, and
<a class="reference internal" href="compute.html"><span class="doc">computes</span></a> can be added to LAMMPS, as discussed below.
The code for these classes can use the per-atom properties defined by
fix property/atom. The Atom class has a find_custom() method that is
useful in this context:</p>
<pre class="literal-block">
int index = atom->find_custom(char *name, int &flag);
</pre>
<p>The “name” of a custom attribute, as specified in the <a class="reference internal" href="fix_property_atom.html"><span class="doc">fix property/atom</span></a> command, is checked to verify
that it exists and its index is returned. The method also sets flag =
0/1 depending on whether it is an integer or floating-point attribute.
The vector of values associated with the attribute can then be
accessed using the returned index as</p>
<pre class="literal-block">
int *ivector = atom->ivector[index];
double *dvector = atom->dvector[index];
</pre>
<p>Ivector or dvector are vectors of length Nlocal = # of owned atoms,
which store the attributes of individual atoms.</p>
<p>There is one class that computes and prints thermodynamic information
to the screen and log file; see the file thermo.cpp.</p>
<p>There are two styles defined in thermo.cpp: “one” and “multi”. There
is also a flexible “custom” style which allows the user to explicitly
list keywords for quantities to print when thermodynamic info is
output. See the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command for a list
of defined quantities.</p>
<p>The thermo styles (one, multi, etc) are simply lists of keywords.
Adding a new style thus only requires defining a new list of keywords.
Search for the word “customize” with references to “thermo style” in
thermo.cpp to see the two locations where code will need to be added.</p>
<p>New keywords can also be added to thermo.cpp to compute new quantities
for output. Search for the word “customize” with references to
“keyword” in thermo.cpp to see the several locations where code will
need to be added.</p>
<p>Note that the <a class="reference internal" href="thermo.html"><span class="doc">thermo_style custom</span></a> command already allows
for thermo output of quantities calculated by <a class="reference internal" href="fix.html"><span class="doc">fixes</span></a>,
<a class="reference internal" href="compute.html"><span class="doc">computes</span></a>, and <a class="reference internal" href="variable.html"><span class="doc">variables</span></a>. Thus, it may
be simpler to compute what you wish via one of those constructs, than
by adding a new keyword to the thermo command.</p>
<p>There is one class that computes and stores <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>
information in LAMMPS; see the file variable.cpp. The value
associated with a variable can be periodically printed to the screen
via the <a class="reference internal" href="print.html"><span class="doc">print</span></a>, <a class="reference internal" href="fix_print.html"><span class="doc">fix print</span></a>, or
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> commands. Variables of style
“equal” can compute complex equations that involve the following types
of arguments:</p>
<pre class="literal-block">
thermo keywords = ke, vol, atoms, ...
other variables = v_a, v_myvar, ...
math functions = div(x,y), mult(x,y), add(x,y), ...
<span id="mod-15"></span><h2>10.15. Submitting new features for inclusion in LAMMPS</h2>
<p>We encourage users to submit new features or modifications for
LAMMPS to <a class="reference external" href="http://lammps.sandia.gov/authors.html">the core developers</a>
so they can be added to the LAMMPS distribution. The preferred way to
manage and coordinate this is as of Fall 2016 via the LAMMPS project on
<a class="reference external" href="https://github.com/lammps/lammps">GitHub</a>. An alternative is to contact
the LAMMPS developers or the indicated developer of a package or feature
directly and send in your contribution via e-mail.</p>
<p>For any larger modifications or programming project, you are encouraged
to contact the LAMMPS developers ahead of time, in order to discuss
implementation strategies and coding guidelines, that will make it
easier to integrate your contribution and result in less work for
everybody involved. You are also encouraged to search through the list
of <a class="reference external" href="https://github.com/lammps/lammps/issues">open issues on GitHub</a> and
submit a new issue for a planned feature, so you would not duplicate
the work of others (and possibly get scooped by them) or have your work
duplicated by others.</p>
<p>How quickly your contribution will be integrated
depends largely on how much effort it will cause to integrate and test
it, how much it requires changes to the core codebase, and of how much
interest it is to the larger LAMMPS community. Please see below for a
checklist of typical requirements. Once you have prepared everything,
see <a class="reference internal" href="tutorial_github.html"><span class="doc">this tutorial</span></a> for instructions on how to
submit your changes or new files through a GitHub pull request. If you
prefer to submit patches or full files, you should first make certain,
that your code works correctly with the latest patch-level version of
LAMMPS and contains all bugfixes from it. Then create a gzipped tar
file of all changed or added files or a corresponding patch file using
‘diff -u’ or ‘diff -c’ and compress it with gzip. Please only use
gzip compression, as this works well on all platforms.</p>
<p>If the new features/files are broadly useful we may add them as core
files to LAMMPS or as part of a <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">standard package</span></a>. Else we will add them as a
user-contributed file or package. Examples of user packages are in
src sub-directories that start with USER. The USER-MISC package is
simply a collection of (mostly) unrelated single files, which is the
simplest way to have your contribution quickly added to the LAMMPS
distribution. You can see a list of the both standard and user
packages by typing “make package” in the LAMMPS src directory.</p>
<p>Note that by providing us files to release, you are agreeing to make
them open-source, i.e. we can release them under the terms of the GPL,
used as a license for the rest of LAMMPS. See <a class="reference internal" href="Section_intro.html#intro-4"><span class="std std-ref">Section 1.4</span></a> for details.</p>
<p>With user packages and files, all we are really providing (aside from
the fame and fortune that accompanies having your name in the source
code and on the <a class="reference external" href="http://lammps.sandia.gov/authors.html">Authors page</a>
of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW site</a>), is a means for you to distribute your
work to the LAMMPS user community, and a mechanism for others to
easily try out your new feature. This may help you find bugs or make
contact with new collaborators. Note that you’re also implicitly
agreeing to support your code which means answer questions, fix bugs,
and maintain it if LAMMPS changes in some way that breaks it (an
unusual event).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you prefer to actively develop and support your add-on
feature yourself, then you may wish to make it available for download
from your own website, as a user package that LAMMPS users can add to
their copy of LAMMPS. See the <a class="reference external" href="http://lammps.sandia.gov/offsite.html">Offsite LAMMPS packages and tools</a> page of the LAMMPS web
site for examples of groups that do this. We are happy to advertise
your package and web site from that page. Simply email the
<a class="reference external" href="http://lammps.sandia.gov/authors.html">developers</a> with info about
your package and we will post it there.</p>
</div>
<p>The previous sections of this doc page describe how to add new “style”
files of various kinds to LAMMPS. Packages are simply collections of
one or more new class files which are invoked as a new style within a
LAMMPS input script. If designed correctly, these additions typically
do not require changes to the main core of LAMMPS; they are simply
add-on files. If you think your new feature requires non-trivial
changes in core LAMMPS files, you’ll need to <a class="reference external" href="http://lammps.sandia.gov/authors.html">communicate with the developers</a>, since we may or may
not want to make those changes. An example of a trivial change is
making a parent-class method “virtual” when you derive a new child
class from it.</p>
<p>Here is a checklist of steps you need to follow to submit a single file
or user package for our consideration. Following these steps will save
both you and us time. See existing files in packages in the src dir for
examples. If you are uncertain, please ask.</p>
<ul class="simple">
<li>All source files you provide must compile with the most current
version of LAMMPS with multiple configurations. In particular you
need to test compiling LAMMPS from scratch with -DLAMMPS_BIGBIG
set in addition to the default -DLAMMPS_SMALLBIG setting. Your code
will need to work correctly in serial and in parallel using MPI.</li>
<li>For consistency with the rest of LAMMPS and especially, if you want
your contribution(s) to be added to main LAMMPS code or one of its
standard packages, it needs to be written in a style compatible with
other LAMMPS source files. This means: 2-character indentation per
level, <strong>no tabs</strong>, no lines over 80 characters. I/O is done via
the C-style stdio library, class header files should not import any
system headers outside <stdio.h>, STL containers should be avoided
in headers, and forward declarations used where possible or needed.
All added code should be placed into the LAMMPS_NS namespace or a
sub-namespace; global or static variables should be avoided, as they
conflict with the modular nature of LAMMPS and the C++ class structure.
Header files must <strong>not</strong> import namespaces with <em>using</em>.
This all is so the developers can more easily understand, integrate,
and maintain your contribution and reduce conflicts with other parts
of LAMMPS. This basically means that the code accesses data
structures, performs its operations, and is formatted similar to other
LAMMPS source files, including the use of the error class for error
and warning messages.</li>
<li>If you want your contribution to be added as a user-contributed
feature, and it’s a single file (actually a *.cpp and *.h file) it can
rapidly be added to the USER-MISC directory. Send us the one-line
entry to add to the USER-MISC/README file in that dir, along with the
2 source files. You can do this multiple times if you wish to
contribute several individual features.</li>
<li>If you want your contribution to be added as a user-contribution and
it is several related featues, it is probably best to make it a user
package directory with a name like USER-FOO. In addition to your new
files, the directory should contain a README text file. The README
should contain your name and contact information and a brief
description of what your new package does. If your files depend on
other LAMMPS style files also being installed (e.g. because your file
is a derived class from the other LAMMPS class), then an Install.sh
file is also needed to check for those dependencies. See other README
and Install.sh files in other USER directories as examples. Send us a
tarball of this USER-FOO directory.</li>
<li>Your new source files need to have the LAMMPS copyright, GPL notice,
and your name and email address at the top, like other
user-contributed LAMMPS source files. They need to create a class
that is inside the LAMMPS namespace. If the file is for one of the
USER packages, including USER-MISC, then we are not as picky about the
coding style (see above). I.e. the files do not need to be in the
same stylistic format and syntax as other LAMMPS files, though that
would be nice for developers as well as users who try to read your
code.</li>
<li>You <strong>must</strong> also create a <strong>documentation</strong> file for each new command or
style you are adding to LAMMPS. For simplicity and convenience, the
documentation of groups of closely related commands or styles may be
combined into a single file. This will be one file for a single-file
feature. For a package, it might be several files. These are simple
text files with a specific markup language, that are then auto-converted
to HTML and PDF. The tools for this conversion are included in the
source distribution, and the translation can be as simple as doing
“make html pdf” in the doc folder.
Thus the documentation source files must be in the same format and
style as other *.txt files in the lammps/doc/src directory for similar
commands and styles; use one or more of them as a starting point.
A description of the markup can also be found in
lammps/doc/utils/txt2html/README.html
As appropriate, the text files can include links to equations
(see doc/Eqs/*.tex for examples, we auto-create the associated JPG
files), or figures (see doc/JPG for examples), or even additional PDF
files with further details (see doc/PDF for examples). The doc page
should also include literature citations as appropriate; see the
bottom of doc/fix_nh.txt for examples and the earlier part of the same
file for how to format the cite itself. The “Restrictions” section of
the doc page should indicate that your command is only available if
LAMMPS is built with the appropriate USER-MISC or USER-FOO package.
See other user package doc files for examples of how to do this. The
prerequiste for building the HTML format files are Python 3.x and
virtualenv, the requirement for generating the PDF format manual
is the <a class="reference external" href="http://www.htmldoc.org/">htmldoc</a> software. Please run at least
“make html” and carefully inspect and proofread the resuling HTML format
doc page before submitting your code.</li>
<li>For a new package (or even a single command) you should include one or
more example scripts demonstrating its use. These should run in no
more than a couple minutes, even on a single processor, and not require
large data files as input. See directories under examples/USER for
examples of input scripts other users provided for their packages.
These example inputs are also required for validating memory accesses
and testing for memory leaks with valgrind</li>
<li>If there is a paper of yours describing your feature (either the
algorithm/science behind the feature itself, or its initial usage, or
its implementation in LAMMPS), you can add the citation to the *.cpp
source file. See src/USER-EFF/atom_vec_electron.cpp for an example.
A LaTeX citation is stored in a variable at the top of the file and a
single line of code that references the variable is added to the
constructor of the class. Whenever a user invokes your feature from
their input script, this will cause LAMMPS to output the citation to a
log.cite file and prompt the user to examine the file. Note that you
should only use this for a paper you or your group authored.
E.g. adding a cite in the code for a paper by Nose and Hoover if you
write a fix that implements their integrator is not the intended
usage. That kind of citation should just be in the doc page you
provide.</li>
</ul>
<p>Finally, as a general rule-of-thumb, the more clear and
self-explanatory you make your documentation and README files, and the
easier you make it for people to get started, e.g. by providing example
scripts, the more likely it is that users will try out your new feature.</p>
<p id="foo"><strong>(Foo)</strong> Foo, Morefoo, and Maxfoo, J of Classic Potentials, 75, 345 (1997).</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Contents: Compute and pair styles that implement the adiabatic
core/shell model for polarizability. The compute temp/cs command
measures the temperature of a system with core/shell particles. The
pair styles augment Born, Buckingham, and Lennard-Jones styles with
core/shell capabilities. See <a class="reference internal" href="Section_howto.html#howto-26"><span class="std std-ref">Section howto 6.26</span></a> for an overview of how to use the
<p>Contents: Dozens of atom, pair, bond, angle, dihedral, improper styles
which run with the Kokkos library to provide optimization for
multicore CPUs (via OpenMP), NVIDIA GPUs, or the Intel Xeon Phi (in
native mode). All of them have a “kk” in their style name. <a class="reference internal" href="accelerate_kokkos.html"><span class="doc">Section accelerate kokkos</span></a> gives details of what
hardware and software is required on your system, and how to build and
use this package. See the GPU, OPT, USER-INTEL, USER-OMP packages,
which also provide optimizations for the same range of hardware.</p>
<p>Building with the KOKKOS package requires choosing which of 3 hardware
options you are optimizing for: CPU acceleration via OpenMP, GPU
acceleration, or Intel Xeon Phi. (You can build multiple times to
create LAMMPS executables for different hardware.) It also requires a
C++11 compatible compiler. For GPUs, the NVIDIA “nvcc” compiler is
used, and an appopriate KOKKOS_ARCH setting should be made in your
Makefile.machine for your GPU hardware and NVIDIA software.</p>
<p>The simplest way to do this is to use Makefile.kokkos_cuda or
Makefile.kokkos_omp or Makefile.kokkos_phi in src/MAKE/OPTIONS, via
“make kokkos_cuda” or “make kokkos_omp” or “make kokkos_phi”. (Check
the KOKKOS_ARCH setting in Makefile.kokkos_cuda), Or, as illustrated
below, you can use the Make.py script with its “-kokkos” option to
choose which hardware to build for. Type “python src/Make.py -h
-kokkos” to see the details. If these methods do not work on your
system, you will need to read the <a class="reference internal" href="accelerate_kokkos.html"><span class="doc">Section accelerate kokkos</span></a> doc page for details of what
Makefile.machine settings are needed.</p>
<p>To install via make or Make.py for each of 3 hardware options:</p>
<pre class="literal-block">
make yes-kokkos
make kokkos_omp # for CPUs with OpenMP
make kokkos_cuda # for GPUs, check the KOKKOS_ARCH setting in Makefile.kokkos_cuda
make kokkos_phi # for Xeon Phis
</pre>
<p>Make.py -p kokkos -kokkos omp -a machine # for CPUs with OpenMP
Make.py -p kokkos -kokkos cuda arch=35 -a machine # for GPUs of style arch
Make.py -p kokkos -kokkos phi -a machine # for Xeon Phis</p>
<p>Contents: A variety of long-range Coulombic solvers, and pair styles
which compute the corresponding short-range portion of the pairwise
Coulombic interactions. These include Ewald, particle-particle
particle-mesh (PPPM), and multilevel summation method (MSM) solvers.</p>
<p>Building with the KSPACE package requires a 1d FFT library be present
on your system for use by the PPPM solvers. This can be the KISS FFT
library provided with LAMMPS, or 3rd party libraries like FFTW or a
vendor-supplied FFT library. See step 6 of <a class="reference internal" href="Section_start.html#start-2-2"><span class="std std-ref">Section start 2.2.2</span></a> of the manual for details of how
to select different FFT options in your machine Makefile. The Make.py
tool has an “-fft” option which can insert these settings into your
machine Makefile automatically. Type “python src/Make.py -h -fft” to
<p>Contents: A handful of pair styles with an “opt” in their style name
which are optimized for improved CPU performance on single or multiple
cores. These include EAM, LJ, CHARMM, and Morse potentials. <a class="reference internal" href="accelerate_opt.html"><span class="doc">Section accelerate opt</span></a> gives details of how to build and
use this package. See the KOKKOS, USER-INTEL, and USER-OMP packages,
which also have styles optimized for CPU performance.</p>
<p>Some C++ compilers, like the Intel compiler, require the compile flag
“-restrict” to build LAMMPS with the OPT package. It should be added
to the CCFLAGS line of your Makefile.machine. Or use Makefile.opt in
src/MAKE/OPTIONS, via “make opt”. For compilers that use the flag,
the Make.py command adds it automatically to the Makefile.auto file it
<p>Contents: A <a class="reference internal" href="python.html"><span class="doc">python</span></a> command which allow you to execute
Python code from a LAMMPS input script. The code can be in a separate
file or embedded in the input script itself. See <a class="reference external" href="Section_python.html"">Section python 11.2</a> for an overview of using Python from
LAMMPS and for other ways to use LAMMPS and Python together.</p>
<p>Building with the PYTHON package assumes you have a Python shared
library available on your system, which needs to be a Python 2
version, 2.6 or later. Python 3 is not supported. The build uses the
contents of the lib/python/Makefile.lammps file to find all the Python
files required in the build/link process. See the lib/python/README
file if the settings in that file do not work on your system. Note
that the Make.py script has a “-python” option to allow an alternate
lib/python/Makefile.lammps file to be specified and LAMMPS to be built
in one step. Type “python src/Make.py -h -python” to see the details.</p>
<p>Contents: A collection of multi-replica methods that are used by
invoking multiple instances (replicas) of LAMMPS
simulations. Communication between individual replicas is performed in
different ways by the different methods. See <a class="reference internal" href="Section_howto.html#howto-5"><span class="std std-ref">Section howto 6.5</span></a> for an overview of how to run
multi-replica simulations in LAMMPS. Multi-replica methods included
in the package are nudged elastic band (NEB), parallel replica
dynamics (PRD), temperature accelerated dynamics (TAD), parallel
tempering, and a verlet/split algorithm for performing long-range
Coulombics on one set of processors, and the remainded of the force
Sampling and Restraints. This package implements a <a class="reference internal" href="fix_colvars.html"><span class="doc">fix colvars</span></a> command which wraps a COLVARS library which
can perform those kinds of simulations. See src/USER-COLVARS/README
<p>Contents: This package contains methods for simulating polarizable
systems using thermalized Drude oscillators. It has computes, fixes,
and pair styles for this purpose. See <a class="reference internal" href="Section_howto.html#howto-27"><span class="std std-ref">Section howto 6.27</span></a> for an overview of how to use the
package. See src/USER-DRUDE/README for additional details. There are
auxiliary tools for using this package in tools/drude.</p>
<p>Contents: FEP stands for free energy perturbation. This package
provides methods for performing FEP simulations by using a <a class="reference internal" href="fix_adapt_fep.html"><span class="doc">fix adapt/fep</span></a> command with soft-core pair potentials,
which have a “soft” in their style name. See src/USER-FEP/README for
more details. There are auxiliary tools for using this package in
<p>Contents: Dozens of pair, bond, angle, dihedral, and improper styles
that are optimized for Intel CPUs and the Intel Xeon Phi (in offload
mode). All of them have an “intel” in their style name. <a class="reference internal" href="accelerate_intel.html"><span class="doc">Section accelerate intel</span></a> gives details of what hardware
and compilers are required on your system, and how to build and use
this package. Also see src/USER-INTEL/README for more details. See
the KOKKOS, OPT, and USER-OMP packages, which also have CPU and
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li class="toctree-l2"><a class="reference internal" href="#overview-of-running-lammps-from-python">11.1. Overview of running LAMMPS from Python</a></li>
<li class="toctree-l2"><a class="reference internal" href="#overview-of-using-python-from-a-lammps-script">11.2. Overview of using Python from a LAMMPS script</a></li>
<li class="toctree-l2"><a class="reference internal" href="#building-lammps-as-a-shared-library">11.3. Building LAMMPS as a shared library</a></li>
<li class="toctree-l2"><a class="reference internal" href="#installing-the-python-wrapper-into-python">11.4. Installing the Python wrapper into Python</a></li>
<li class="toctree-l2"><a class="reference internal" href="#extending-python-with-mpi-to-run-in-parallel">11.5. Extending Python with MPI to run in parallel</a></li>
<li class="toctree-l2"><a class="reference internal" href="#testing-the-python-lammps-interface">11.6. Testing the Python-LAMMPS interface</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#test-lammps-and-python-in-serial">11.6.1. <strong>Test LAMMPS and Python in serial:</strong></a></li>
<li class="toctree-l3"><a class="reference internal" href="#test-lammps-and-python-in-parallel">11.6.2. <strong>Test LAMMPS and Python in parallel:</strong></a></li>
<li class="toctree-l2"><a class="reference internal" href="#using-lammps-from-python">11.7. Using LAMMPS from Python</a></li>
<li class="toctree-l2"><a class="reference internal" href="#example-python-scripts-that-use-lammps">11.8. Example Python scripts that use LAMMPS</a></li>
<p>LAMMPS can work together with Python in two ways. First, Python can
wrap LAMMPS through the <a class="reference internal" href="Section_howto.html#howto-19"><span class="std std-ref">LAMMPS library interface</span></a>, so that a Python script can
create one or more instances of LAMMPS and launch one or more
simulations. In Python lingo, this is “extending” Python with LAMMPS.</p>
<p>Second, LAMMPS can use the Python interpreter, so that a LAMMPS input
script can invoke Python code, and pass information back-and-forth
between the input script and Python functions you write. The Python
code can also callback to LAMMPS to query or change its attributes.
In Python lingo, this is “embedding” Python in LAMMPS.</p>
<p>This section describes how to do both.</p>
<ul class="simple">
<li>11.1 <a class="reference internal" href="#py-1"><span class="std std-ref">Overview of running LAMMPS from Python</span></a></li>
<li>11.2 <a class="reference internal" href="#py-2"><span class="std std-ref">Overview of using Python from a LAMMPS script</span></a></li>
<li>11.3 <a class="reference internal" href="#py-3"><span class="std std-ref">Building LAMMPS as a shared library</span></a></li>
<li>11.4 <a class="reference internal" href="#py-4"><span class="std std-ref">Installing the Python wrapper into Python</span></a></li>
<li>11.5 <a class="reference internal" href="#py-5"><span class="std std-ref">Extending Python with MPI to run in parallel</span></a></li>
<li>11.6 <a class="reference internal" href="#py-6"><span class="std std-ref">Testing the Python-LAMMPS interface</span></a></li>
<li>11.7 <a class="reference internal" href="#py-7"><span class="std std-ref">Using LAMMPS from Python</span></a></li>
<li>11.8 <a class="reference internal" href="#py-8"><span class="std std-ref">Example Python scripts that use LAMMPS</span></a></li>
</ul>
<p>If you are not familiar with it, <a class="reference external" href="http://www.python.org">Python</a> is a
powerful scripting and programming language which can essentially do
anything that faster, lower-level languages like C or C++ can do, but
typically with much fewer lines of code. When used in embedded mode,
Python can perform operations that the simplistic LAMMPS input script
syntax cannot. Python can be also be used as a “glue” language to
drive a program through its library interface, or to hook multiple
pieces of software together, such as a simulation package plus a
visualization package, or to run a coupled multiscale or multiphysics
model.</p>
-<p>See <a class="reference internal" href="Section_howto.html#howto-10"><span class="std std-ref">Section_howto 10</span></a> of the manual and
+<p>See <a class="reference internal" href="Section_howto.html#howto-10"><span class="std std-ref">Section 6.10</span></a> of the manual and
the couple directory of the distribution for more ideas about coupling
LAMMPS to other codes. See <a class="reference internal" href="Section_howto.html#howto-19"><span class="std std-ref">Section_howto 19</span></a> for a description of the LAMMPS
library interface provided in src/library.cpp and src/library.h, and
how to extend it for your needs. As described below, that interface
is what is exposed to Python either when calling LAMMPS from Python or
when calling Python from a LAMMPS input script and then calling back
to LAMMPS from Python code. The library interface is designed to be
easy to add functions to. Thus the Python interface to LAMMPS is also
easy to extend as well.</p>
<p>If you create interesting Python scripts that run LAMMPS or
interesting Python functions that can be called from a LAMMPS input
script, that you think would be useful to other users, please <a class="reference external" href="http://lammps.sandia.gov/authors.html">email them to the developers</a>. We can
-<p>If an error occurs, carefully go thru the steps in <a class="reference internal" href="Section_start.html#start-5"><span class="std std-ref">Section_start 5</span></a> and above about building a shared
+<p>If an error occurs, carefully go thru the steps in <a class="reference internal" href="Section_start.html#start-5"><span class="std std-ref">Section 2.5</span></a> and above about building a shared
library and about insuring Python can find the necessary two files
extract_fix(), and extract_variable() methods return values or
pointers to data structures internal to LAMMPS.</p>
<p>For extract_global() see the src/library.cpp file for the list of
valid names. New names could easily be added. A double or integer is
returned. You need to specify the appropriate data type via the type
argument.</p>
<p>For extract_atom(), a pointer to internal LAMMPS atom-based data is
returned, which you can use via normal Python subscripting. See the
extract() method in the src/atom.cpp file for a list of valid names.
Again, new names could easily be added. A pointer to a vector of
doubles or integers, or a pointer to an array of doubles (double **)
or integers (int **) is returned. You need to specify the appropriate
data type via the type argument.</p>
<p>For extract_compute() and extract_fix(), the global, per-atom, or
local data calulated by the compute or fix can be accessed. What is
returned depends on whether the compute or fix calculates a scalar or
vector or array. For a scalar, a single double value is returned. If
the compute or fix calculates a vector or array, a pointer to the
internal LAMMPS data is returned, which you can use via normal Python
subscripting. The one exception is that for a fix that calculates a
global vector or array, a single double value from the vector or array
is returned, indexed by I (vector) or I and J (array). I,J are
zero-based indices. The I,J arguments can be left out if not needed.
-See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section_howto 15</span></a> of the manual for a
+See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section 6.15</span></a> of the manual for a
discussion of global, per-atom, and local data, and of scalar, vector,
and array data types. See the doc pages for individual
<a class="reference internal" href="compute.html"><span class="doc">computes</span></a> and <a class="reference internal" href="fix.html"><span class="doc">fixes</span></a> for a description of what
they calculate and store.</p>
<p>For extract_variable(), an <a class="reference internal" href="variable.html"><span class="doc">equal-style or atom-style variable</span></a> is evaluated and its result returned.</p>
<p>For equal-style variables a single double value is returned and the
group argument is ignored. For atom-style variables, a vector of
doubles is returned, one value per atom, which you can use via normal
Python subscripting. The values will be zero for atoms not in the
specified group.</p>
<p>The get_natoms() method returns the total number of atoms in the
simulation, as an int.</p>
<p>The gather_atoms() method returns a ctypes vector of ints or doubles
as specified by type, of length count*natoms, for the property of all
the atoms in the simulation specified by name, ordered by count and
then by atom ID. The vector can be used via normal Python
subscripting. If atom IDs are not consecutively ordered within
LAMMPS, a None is returned as indication of an error.</p>
<p>Note that the data structure gather_atoms(“x”) returns is different
from the data structure returned by extract_atom(“x”) in four ways.
(1) Gather_atoms() returns a vector which you index as x[i];
extract_atom() returns an array which you index as x[i][j]. (2)
Gather_atoms() orders the atoms by atom ID while extract_atom() does
not. (3) Gathert_atoms() returns a list of all atoms in the
simulation; extract_atoms() returns just the atoms local to each
processor. (4) Finally, the gather_atoms() data structure is a copy
of the atom coords stored internally in LAMMPS, whereas extract_atom()
returns an array that effectively points directly to the internal
data. This means you can change values inside LAMMPS from Python by
assigning a new values to the extract_atom() array. To do this with
the gather_atoms() vector, you need to change values in the vector,
then invoke the scatter_atoms() method.</p>
<p>The scatter_atoms() method takes a vector of ints or doubles as
specified by type, of length count*natoms, for the property of all the
atoms in the simulation specified by name, ordered by bount and then
by atom ID. It uses the vector of data to overwrite the corresponding
properties for each atom inside LAMMPS. This requires LAMMPS to have
its “map” option enabled; see the <a class="reference internal" href="atom_modify.html"><span class="doc">atom_modify</span></a>
command for details. If it is not, or if atom IDs are not
consecutively ordered, no coordinates are reset.</p>
<p>The array of coordinates passed to scatter_atoms() must be a ctypes
vector of ints or doubles, allocated and initialized something like
this:</p>
<pre class="literal-block">
from ctypes import *
natoms = lmp.get_natoms()
n3 = 3*natoms
x = (n3*c_double)()
x[0] = x coord of atom with ID 1
x[1] = y coord of atom with ID 1
x[2] = z coord of atom with ID 1
x[3] = x coord of atom with ID 2
...
x[n3-1] = z coord of atom with ID natoms
lmp.scatter_coords("x",1,3,x)
</pre>
<p>Alternatively, you can just change values in the vector returned by
gather_atoms(“x”,1,3), since it is a ctypes vector of doubles.</p>
<hr class="docutils" />
<p>As noted above, these Python class methods correspond one-to-one with
the functions in the LAMMPS library interface in src/library.cpp and
library.h. This means you can extend the Python wrapper via the
following steps:</p>
<ul class="simple">
<li>Add a new interface function to src/library.cpp and
src/library.h.</li>
<li>Rebuild LAMMPS as a shared library.</li>
<li>Add a wrapper method to python/lammps.py for this interface
function.</li>
<li>You should now be able to invoke the new interface function from a
<span id="py-8"></span><h2>11.8. Example Python scripts that use LAMMPS</h2>
<p>These are the Python scripts included as demos in the python/examples
directory of the LAMMPS distribution, to illustrate the kinds of
things that are possible when Python wraps LAMMPS. If you create your
own scripts, send them to us and we can include them in the LAMMPS
distribution.</p>
<table border="1" class="docutils">
<colgroup>
<col width="56%" />
<col width="44%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>trivial.py</td>
<td>read/run a LAMMPS input script thru Python</td>
</tr>
<tr class="row-even"><td>demo.py</td>
<td>invoke various LAMMPS library interface routines</td>
</tr>
<tr class="row-odd"><td>simple.py</td>
<td>run in parallel</td>
</tr>
<tr class="row-even"><td>similar to examples/COUPLE/simple/simple.cpp</td>
<td>split.py</td>
</tr>
<tr class="row-odd"><td>same as simple.py but running in parallel on a subset of procs</td>
<td>gui.py</td>
</tr>
<tr class="row-even"><td>GUI go/stop/temperature-slider to control LAMMPS</td>
<td>plot.py</td>
</tr>
<tr class="row-odd"><td>real-time temeperature plot with GnuPlot via Pizza.py</td>
<td>viz_tool.py</td>
</tr>
<tr class="row-even"><td>real-time viz via some viz package</td>
<td>vizplotgui_tool.py</td>
</tr>
<tr class="row-odd"><td>combination of viz_tool.py and plot.py and gui.py</td>
<td> </td>
</tr>
</tbody>
</table>
<hr class="docutils" />
<p>For the viz_tool.py and vizplotgui_tool.py commands, replace “tool”
with “gl” or “atomeye” or “pymol” or “vmd”, depending on what
visualization package you have installed.</p>
<p>Note that for GL, you need to be able to run the Pizza.py GL tool,
which is included in the pizza sub-directory. See the <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py doc pages</a> for more info:</p>
<p>Note that for AtomEye, you need version 3, and there is a line in the
scripts that specifies the path and name of the executable. See the
AtomEye WWW pages <a class="reference external" href="http://mt.seas.upenn.edu/Archive/Graphics/A">here</a> or <a class="reference external" href="http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html">here</a> for more details:</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li class="toctree-l3"><a class="reference internal" href="#additional-requirement-for-using-a-shared-library">2.5.3. <strong>Additional requirement for using a shared library:</strong></a></li>
<li class="toctree-l3"><a class="reference internal" href="#calling-the-lammps-library">2.5.4. <strong>Calling the LAMMPS library:</strong></a></li>
<span id="start-1"></span><h2>2.1. What’s in the LAMMPS distribution</h2>
<p>When you download a LAMMPS tarball you will need to unzip and untar
the downloaded file with the following commands, after placing the
tarball in an appropriate directory.</p>
<pre class="literal-block">
gunzip lammps*.tar.gz
tar xvf lammps*.tar
</pre>
<p>This will create a LAMMPS directory containing two files and several
sub-directories:</p>
<table border="1" class="docutils">
<colgroup>
<col width="21%" />
<col width="79%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>README</td>
<td>text file</td>
</tr>
<tr class="row-even"><td>LICENSE</td>
<td>the GNU General Public License (GPL)</td>
</tr>
<tr class="row-odd"><td>bench</td>
<td>benchmark problems</td>
</tr>
<tr class="row-even"><td>doc</td>
<td>documentation</td>
</tr>
<tr class="row-odd"><td>examples</td>
<td>simple test problems</td>
</tr>
<tr class="row-even"><td>potentials</td>
<td>embedded atom method (EAM) potential files</td>
</tr>
<tr class="row-odd"><td>src</td>
<td>source files</td>
</tr>
<tr class="row-even"><td>tools</td>
<td>pre- and post-processing tools</td>
</tr>
</tbody>
</table>
<p>Note that the <a class="reference external" href="http://lammps.sandia.gov/download.html">download page</a> also has links to download
Windows exectubles and installers, as well as pre-built executables
for a few specific Linux distributions. It also has instructions for
how to download/install LAMMPS for Macs (via Homebrew), and to
download and update LAMMPS from SVN and Git repositories, which gives
you the same files that are in the download tarball.</p>
<p>The Windows and Linux executables for serial or parallel only include
certain packages and bug-fixes/upgrades listed on <a class="reference external" href="http://lammps.sandia.gov/bug.html">this page</a> up to a certain date, as
stated on the download page. If you want an executable with
non-included packages or that is more current, then you’ll need to
build LAMMPS yourself, as discussed in the next section.</p>
<p>Skip to the <a class="reference internal" href="#start-6"><span class="std std-ref">Running LAMMPS</span></a> sections for info on how to
launch a LAMMPS Windows executable on a Windows box.</p>
<hr class="docutils" />
</div>
<div class="section" id="making-lammps">
<span id="start-2"></span><h2>2.2. Making LAMMPS</h2>
<p>This section has the following sub-sections:</p>
<ul class="simple">
<li><a class="reference internal" href="#start-2-1"><span class="std std-ref">Read this first</span></a></li>
<li><a class="reference internal" href="#start-2-2"><span class="std std-ref">Steps to build a LAMMPS executable</span></a></li>
<li><a class="reference internal" href="#start-2-3"><span class="std std-ref">Common errors that can occur when making LAMMPS</span></a></li>
This gives preference to a file you have created/edited and put in
src/MAKE/MINE.</p>
<p>Note that on a multi-processor or multi-core platform you can launch a
parallel make, by using the “-j” switch with the make command, which
will build LAMMPS more quickly.</p>
<p>If you get no errors and an executable like lmp_mpi or lmp_g++_serial
or lmp_mac is produced, then you’re done; it’s your lucky day.</p>
<p>Note that by default only a few of LAMMPS optional packages are
installed. To build LAMMPS with optional packages, see <a class="reference internal" href="#start-3"><span class="std std-ref">this section</span></a> below.</p>
<p><strong>Step 1</strong></p>
<p>If Step 0 did not work, you will need to create a low-level Makefile
for your machine, like Makefile.foo. You should make a copy of an
existing Makefile.* in src/MAKE or one of its sub-directories as a
starting point. The only portions of the file you need to edit are
the first line, the “compiler/linker settings” section, and the
“LAMMPS-specific settings” section. When it works, put the edited
file in src/MAKE/MINE and it will not be altered by any future LAMMPS
updates.</p>
<p><strong>Step 2</strong></p>
<p>Change the first line of Makefile.foo to list the word “foo” after the
“#”, and whatever other options it will set. This is the line you
will see if you just type “make”.</p>
<p><strong>Step 3</strong></p>
<p>The “compiler/linker settings” section lists compiler and linker
settings for your C++ compiler, including optimization flags. You can
use g++, the open-source GNU compiler, which is available on all Unix
systems. You can also use mpicxx which will typically be available if
MPI is installed on your system, though you should check which actual
compiler it wraps. Vendor compilers often produce faster code. On
boxes with Intel CPUs, we suggest using the Intel icc compiler, which
can be downloaded from <a class="reference external" href="http://www.intel.com/software/products/noncom">Intel’s compiler site</a>.</p>
<p>If building a C++ code on your machine requires additional libraries,
then you should list them as part of the LIB variable. You should
not need to do this if you use mpicxx.</p>
<p>The DEPFLAGS setting is what triggers the C++ compiler to create a
dependency list for a source file. This speeds re-compilation when
source (*.cpp) or header (*.h) files are edited. Some compilers do
not support dependency file creation, or may use a different switch
than -D. GNU g++ and Intel icc works with -D. If your compiler can’t
create dependency files, then you’ll need to create a Makefile.foo
patterned after Makefile.storm, which uses different rules that do not
involve dependency files. Note that when you build LAMMPS for the
first time on a new platform, a long list of *.d files will be printed
out rapidly. This is not an error; it is the Makefile doing its
normal creation of dependencies.</p>
<p><strong>Step 4</strong></p>
<p>The “system-specific settings” section has several parts. Note that
if you change any -D setting in this section, you should do a full
re-compile, after typing “make clean” (which will describe different
clean options).</p>
<p>The LMP_INC variable is used to include options that turn on ifdefs
within the LAMMPS code. The options that are currently recogized are:</p>
<ul class="simple">
<li>-DLAMMPS_GZIP</li>
<li>-DLAMMPS_JPEG</li>
<li>-DLAMMPS_PNG</li>
<li>-DLAMMPS_FFMPEG</li>
<li>-DLAMMPS_MEMALIGN</li>
<li>-DLAMMPS_XDR</li>
<li>-DLAMMPS_SMALLBIG</li>
<li>-DLAMMPS_BIGBIG</li>
<li>-DLAMMPS_SMALLSMALL</li>
<li>-DLAMMPS_LONGLONG_TO_LONG</li>
<li>-DLAMMPS_EXCEPTIONS</li>
<li>-DPACK_ARRAY</li>
<li>-DPACK_POINTER</li>
<li>-DPACK_MEMCPY</li>
</ul>
<p>The read_data and dump commands will read/write gzipped files if you
compile with -DLAMMPS_GZIP. It requires that your machine supports
the “popen()” function in the standard runtime library and that a gzip
executable can be found by LAMMPS during a run.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">on some clusters with high-speed networks, using the fork()
library calls (required by popen()) can interfere with the fast
communication library and lead to simulations using compressed output
or input to hang or crash. For selected operations, compressed file
I/O is also available using a compression library instead, which are
provided in the COMPRESS package. From more details about compiling
LAMMPS with packages, please see below.</p>
</div>
<p>If you use -DLAMMPS_JPEG, the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a> command
will be able to write out JPEG image files. For JPEG files, you must
also link LAMMPS with a JPEG library, as described below. If you use
-DLAMMPS_PNG, the <a class="reference internal" href="dump.html"><span class="doc">dump image</span></a> command will be able to write
out PNG image files. For PNG files, you must also link LAMMPS with a
PNG library, as described below. If neither of those two defines are
used, LAMMPS will only be able to write out uncompressed PPM image
files.</p>
<p>If you use -DLAMMPS_FFMPEG, the <a class="reference internal" href="dump_image.html"><span class="doc">dump movie</span></a> command
will be available to support on-the-fly generation of rendered movies
the need to store intermediate image files. It requires that your
machines supports the “popen” function in the standard runtime library
and that an FFmpeg executable can be found by LAMMPS during the run.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Similar to the note above, this option can conflict with
high-speed networks, because it uses popen().</p>
</div>
<p>Using -DLAMMPS_MEMALIGN=<bytes> enables the use of the
posix_memalign() call instead of malloc() when large chunks or memory
are allocated by LAMMPS. This can help to make more efficient use of
vector instructions of modern CPUS, since dynamically allocated memory
has to be aligned on larger than default byte boundaries (e.g. 16
bytes instead of 8 bytes on x86 type platforms) for optimal
performance.</p>
<p>If you use -DLAMMPS_XDR, the build will include XDR compatibility
files for doing particle dumps in XTC format. This is only necessary
if your platform does have its own XDR files available. See the
Restrictions section of the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command for details.</p>
<p>Use at most one of the -DLAMMPS_SMALLBIG, -DLAMMPS_BIGBIG,
-DLAMMPS_SMALLSMALL settings. The default is -DLAMMPS_SMALLBIG. These
settings refer to use of 4-byte (small) vs 8-byte (big) integers
within LAMMPS, as specified in src/lmptype.h. The only reason to use
the BIGBIG setting is to enable simulation of huge molecular systems
(which store bond topology info) with more than 2 billion atoms, or to
track the image flags of moving atoms that wrap around a periodic box
more than 512 times. Normally, the only reason to use SMALLSMALL is
if your machine does not support 64-bit integers, though you can use
SMALLSMALL setting if you are running in serial or on a desktop
machine or small cluster where you will never run large systems or for
long time (more than 2 billion atoms, more than 2 billion timesteps).
See the <a class="reference internal" href="#start-2-4"><span class="std std-ref">Additional build tips</span></a> section below for more
details on these settings.</p>
<p>Note that the USER-ATC package is not currently compatible with
-DLAMMPS_BIGBIG. Also the GPU package requires the lib/gpu library to
be compiled with the same setting, or the link will fail.</p>
<p>The -DLAMMPS_LONGLONG_TO_LONG setting may be needed if your system or
MPI version does not recognize “long long” data types. In this case a
“long” data type is likely already 64-bits, in which case this setting
will convert to that data type.</p>
<p>The -DLAMMPS_EXCEPTIONS setting can be used to activate alternative
versions of error handling inside of LAMMPS. This is useful when
external codes drive LAMMPS as a library. Using this option, LAMMPS
errors do not kill the caller. Instead, the call stack is unwound and
control returns to the caller. The library interface provides the
lammps_has_error() and lammps_get_last_error_message() functions to
detect and find out more about a LAMMPS error.</p>
<p>Using one of the -DPACK_ARRAY, -DPACK_POINTER, and -DPACK_MEMCPY
options can make for faster parallel FFTs (in the PPPM solver) on some
platforms. The -DPACK_ARRAY setting is the default. See the
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command for info about PPPM. See
Step 6 below for info about building LAMMPS with an FFT library.</p>
<p><strong>Step 5</strong></p>
<p>The 3 MPI variables are used to specify an MPI library to build LAMMPS
with. Note that you do not need to set these if you use the MPI
compiler mpicxx for your CC and LINK setting in the section above.
The MPI wrapper knows where to find the needed files.</p>
<p>If you want LAMMPS to run in parallel, you must have an MPI library
installed on your platform. If MPI is installed on your system in the
usual place (under /usr/local), you also may not need to specify these
3 variables, assuming /usr/local is in your path. On some large
parallel machines which use “modules” for their compile/link
environements, you may simply need to include the correct module in
your build environment, before building LAMMPS. Or the parallel
machine may have a vendor-provided MPI which the compiler has no
trouble finding.</p>
<p>Failing this, these 3 variables can be used to specify where the mpi.h
file (MPI_INC) and the MPI library file (MPI_PATH) are found and the
name of the library file (MPI_LIB).</p>
<p>If you are installing MPI yourself, we recommend Argonne’s MPICH2
or OpenMPI. MPICH can be downloaded from the <a class="reference external" href="http://www.mcs.anl.gov/research/projects/mpich2/">Argonne MPI site</a>. OpenMPI can
be downloaded from the <a class="reference external" href="http://www.open-mpi.org">OpenMPI site</a>.
Other MPI packages should also work. If you are running on a big
parallel platform, your system people or the vendor should have
already installed a version of MPI, which is likely to be faster
than a self-installed MPICH or OpenMPI, so find out how to build
and link with it. If you use MPICH or OpenMPI, you will have to
configure and build it for your platform. The MPI configure script
should have compiler options to enable you to use the same compiler
you are using for the LAMMPS build, which can avoid problems that can
arise when linking LAMMPS to the MPI library.</p>
<p>If you just want to run LAMMPS on a single processor, you can use the
dummy MPI library provided in src/STUBS, since you don’t need a true
MPI library installed on your system. See src/MAKE/Makefile.serial
for how to specify the 3 MPI variables in this case. You will also
need to build the STUBS library for your platform before making LAMMPS
itself. Note that if you are building with src/MAKE/Makefile.serial,
e.g. by typing “make serial”, then the STUBS library is built for you.</p>
<p>To build the STUBS library from the src directory, type “make
mpi-stubs”, or from the src/STUBS dir, type “make”. This should
create a libmpi_stubs.a file suitable for linking to LAMMPS. If the
build fails, you will need to edit the STUBS/Makefile for your
platform.</p>
<p>The file STUBS/mpi.c provides a CPU timer function called MPI_Wtime()
that calls gettimeofday() . If your system doesn’t support
gettimeofday() , you’ll need to insert code to call another timer.
Note that the ANSI-standard function clock() rolls over after an hour
or so, and is therefore insufficient for timing long LAMMPS
simulations.</p>
<p><strong>Step 6</strong></p>
<p>The 3 FFT variables allow you to specify an FFT library which LAMMPS
uses (for performing 1d FFTs) when running the particle-particle
particle-mesh (PPPM) option for long-range Coulombics via the
ACML, and T3E. For backward compatability, using -DFFT_FFTW will use
the FFTW2 library. Using -DFFT_NONE will use the KISS library
described above.</p>
<p>You may also need to set the FFT_INC, FFT_PATH, and FFT_LIB variables,
so the compiler and linker can find the needed FFT header and library
files. Note that on some large parallel machines which use “modules”
for their compile/link environements, you may simply need to include
the correct module in your build environment. Or the parallel machine
may have a vendor-provided FFT library which the compiler has no
trouble finding.</p>
<p>FFTW is a fast, portable library that should also work on any
platform. You can download it from
<a class="reference external" href="http://www.fftw.org">www.fftw.org</a>. Both the legacy version 2.1.X and
the newer 3.X versions are supported as -DFFT_FFTW2 or -DFFT_FFTW3.
Building FFTW for your box should be as simple as ./configure; make.
Note that on some platforms FFTW2 has been pre-installed, and uses
renamed files indicating the precision it was compiled with,
e.g. sfftw.h, or dfftw.h instead of fftw.h. In this case, you can
specify an additional define variable for FFT_INC called -DFFTW_SIZE,
which will select the correct include file. In this case, for FFT_LIB
you must also manually specify the correct library, namely -lsfftw or
-ldfftw.</p>
<p>The FFT_INC variable also allows for a -DFFT_SINGLE setting that will
use single-precision FFTs with PPPM, which can speed-up long-range
calulations, particularly in parallel or on GPUs. Fourier transform
and related PPPM operations are somewhat insensitive to floating point
truncation errors and thus do not always need to be performed in
double precision. Using the -DFFT_SINGLE setting trades off a little
accuracy for reduced memory use and parallel communication costs for
transposing 3d FFT data. Note that single precision FFTs have only
been tested with the FFTW3, FFTW2, MKL, and KISS FFT options.</p>
<p><strong>Step 7</strong></p>
<p>The 3 JPG variables allow you to specify a JPEG and/or PNG library
which LAMMPS uses when writing out JPEG or PNG files via the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a> command. These can be left blank if you do not
use the -DLAMMPS_JPEG or -DLAMMPS_PNG switches discussed above in Step
4, since in that case JPEG/PNG output will be disabled.</p>
<p>A standard JPEG library usually goes by the name libjpeg.a or
libjpeg.so and has an associated header file jpeglib.h. Whichever
JPEG library you have on your platform, you’ll need to set the
appropriate JPG_INC, JPG_PATH, and JPG_LIB variables, so that the
compiler and linker can find it.</p>
<p>A standard PNG library usually goes by the name libpng.a or libpng.so
and has an associated header file png.h. Whichever PNG library you
have on your platform, you’ll need to set the appropriate JPG_INC,
JPG_PATH, and JPG_LIB variables, so that the compiler and linker can
find it.</p>
<p>As before, if these header and library files are in the usual place on
your machine, you may not need to set these variables.</p>
<p><strong>Step 8</strong></p>
<p>Note that by default only a few of LAMMPS optional packages are
installed. To build LAMMPS with optional packages, see <a class="reference internal" href="#start-3"><span class="std std-ref">this section</span></a> below, before proceeding to Step 9.</p>
<p><strong>Step 9</strong></p>
<p>That’s it. Once you have a correct Makefile.foo, and you have
pre-built any other needed libraries (e.g. MPI, FFT, etc) all you need
to do from the src directory is type something like this:</p>
<p>You can make LAMMPS for multiple platforms from the same src
directory. Each target creates its own object sub-directory called
Obj_target where it stores the system-specific *.o files.</p>
<ol class="arabic simple" start="2">
<li>Cleaning up.</li>
</ol>
<p>Typing “make clean-all” or “make clean-machine” will delete *.o object
files created when LAMMPS is built, for either all builds or for a
particular machine.</p>
<p>(3) Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or
-DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL</p>
<p>As explained above, any of these 3 settings can be specified on the
LMP_INC line in your low-level src/MAKE/Makefile.foo.</p>
<p>The default is -DLAMMPS_SMALLBIG which allows for systems with up to
2^63 atoms and 2^63 timesteps (about 9e18). The atom limit is for
atomic systems which do not store bond topology info and thus do not
require atom IDs. If you use atom IDs for atomic systems (which is
the default) or if you use a molecular model, which stores bond
topology info and thus requires atom IDs, the limit is 2^31 atoms
(about 2 billion). This is because the IDs are stored in 32-bit
integers.</p>
<p>Likewise, with this setting, the 3 image flags for each atom (see the
<a class="reference internal" href="dump.html"><span class="doc">dump</span></a> doc page for a discussion) are stored in a 32-bit
integer, which means the atoms can only wrap around a periodic box (in
each dimension) at most 512 times. If atoms move through the periodic
box more than this many times, the image flags will “roll over”,
e.g. from 511 to -512, which can cause diagnostics like the
mean-squared displacement, as calculated by the <a class="reference internal" href="compute_msd.html"><span class="doc">compute msd</span></a> command, to be faulty.</p>
<p>To allow for larger atomic systems with atom IDs or larger molecular
systems or larger image flags, compile with -DLAMMPS_BIGBIG. This
stores atom IDs and image flags in 64-bit integers. This enables
atomic or molecular systems with atom IDS of up to 2^63 atoms (about
9e18). And image flags will not “roll over” until they reach 2^20 =
1048576.</p>
<p>If your system does not support 8-byte integers, you will need to
compile with the -DLAMMPS_SMALLSMALL setting. This will restrict the
total number of atoms (for atomic or molecular systems) and timesteps
to 2^31 (about 2 billion). Image flags will roll over at 2^9 = 512.</p>
<p>Note that in src/lmptype.h there are definitions of all these data
types as well as the MPI data types associated with them. The MPI
types need to be consistent with the associated C data types, or else
LAMMPS will generate a run-time error. As far as we know, the
settings defined in src/lmptype.h are portable and work on every
current system.</p>
<p>In all cases, the size of problem that can be run on a per-processor
basis is limited by 4-byte integer storage to 2^31 atoms per processor
(about 2 billion). This should not normally be a limitation since such
a problem would have a huge per-processor memory footprint due to
neighbor lists and would run very slowly in terms of CPU secs/timestep.</p>
<hr class="docutils" />
<p id="start-2-5"><a href="#id9"><span class="problematic" id="id10">**</span></a><em>Building for a Mac:</em>**</p>
<p>OS X is BSD Unix, so it should just work. See the
src/MAKE/MACHINES/Makefile.mac and Makefile.mac_mpi files.</p>
<hr class="docutils" />
<p id="start-2-6"><a href="#id11"><span class="problematic" id="id12">**</span></a><em>Building for Windows:</em>**</p>
<p>The LAMMPS download page has an option to download both a serial and
parallel pre-built Windows executable. See the <a class="reference internal" href="#start-6"><span class="std std-ref">Running LAMMPS</span></a> section for instructions on running these executables
on a Windows box.</p>
<p>The pre-built executables hosted on the <a class="reference external" href="http://lammps.sandia.gov/download.html">LAMMPS download page</a> are built with a subset
of the available packages; see the download page for the list. These
are single executable files. No examples or documentation in
included. You will need to download the full source code package to
obtain those.</p>
<p>As an alternative, you can download “daily builds” (and some older
<p>The source code for LAMMPS is structured as a set of core files which
are always included, plus optional packages. Packages are groups of
files that enable a specific set of features. For example, force
fields for molecular systems or granular systems are in packages.</p>
<p><a class="reference internal" href="Section_packages.html"><span class="doc">Section packages</span></a> in the manual has details
about all the packages, including specific instructions for building
LAMMPS with each package, which are covered in a more general manner
below.</p>
<p>You can see the list of all packages by typing “make package” from
within the src directory of the LAMMPS distribution. This also lists
various make commands that can be used to manipulate packages.</p>
<p>If you use a command in a LAMMPS input script that is part of a
package, you must have built LAMMPS with that package, else you will
get an error that the style is invalid or the command is unknown.
Every command’s doc page specfies if it is part of a package. You can
also type</p>
<pre class="literal-block">
lmp_machine -h
</pre>
<p>to run your executable with the optional <a class="reference internal" href="#start-7"><span class="std std-ref">-h command-line switch</span></a> for “help”, which will simply list the styles and
commands known to your executable, and immediately exit.</p>
<p>There are two kinds of packages in LAMMPS, standard and user packages.
More information about the contents of standard and user packages is
-given in <a class="reference internal" href="Section_packages.html"><span class="doc">Section_packages</span></a> of the manual. The
+given in <a class="reference internal" href="Section_packages.html"><span class="doc">Section 4</span></a> of the manual. The
difference between standard and user packages is as follows:</p>
<p>Standard packages, such as molecule or kspace, are supported by the
LAMMPS developers and are written in a syntax and style consistent
with the rest of LAMMPS. This means we will answer questions about
them, debug and fix them if necessary, and keep them compatible with
future changes to LAMMPS.</p>
<p>User packages, such as user-atc or user-omp, have been contributed by
users, and always begin with the user prefix. If they are a single
command (single file), they are typically in the user-misc package.
Otherwise, they are a a set of files grouped together which add a
specific functionality to the code.</p>
<p>User packages don’t necessarily meet the requirements of the standard
packages. If you have problems using a feature provided in a user
package, you may need to contact the contributor directly to get help.
Information on how to submit additions you make to LAMMPS as single
files or either a standard or user-contributed package are given in
<a class="reference internal" href="Section_modify.html#mod-15"><span class="std std-ref">this section</span></a> of the documentation.</p>
no-user”, “make yes-lib”, “make no-lib”, “make yes-all”, or “make
no-all” to include/exclude various sets of packages. Type “make
package” to see all of the package-related make options.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Inclusion/exclusion of a package works by simply moving files
back and forth between the main src directory and sub-directories with
the package name (e.g. src/KSPACE, src/USER-ATC), so that the files
are seen or not seen when LAMMPS is built. After you have included or
excluded a package, you must re-build LAMMPS.</p>
</div>
<p>Additional package-related make options exist to help manage LAMMPS
files that exist in both the src directory and in package
sub-directories. You do not normally need to use these commands
unless you are editing LAMMPS files or have downloaded a patch from
the LAMMPS WWW site.</p>
<p>Typing “make package-update” or “make pu” will overwrite src files
with files from the package sub-directories if the package has been
included. It should be used after a patch is installed, since patches
only update the files in the package sub-directory, but not the src
files. Typing “make package-overwrite” will overwrite files in the
package sub-directories with src files.</p>
<p>Typing “make package-status” or “make ps” will show which packages are
currently included. For those that are included, it will list any
files that are different in the src directory and package
sub-directory. Typing “make package-diff” lists all differences
between these files. Again, type “make package” to see all of the
package-related make options.</p>
<hr class="docutils" />
<p id="start-3-3"><a href="#id17"><span class="problematic" id="id18">**</span></a><em>Packages that require extra libraries:</em>**</p>
<p>A few of the standard and user packages require additional auxiliary
libraries. Many of them are provided with LAMMPS, in which case they
must be compiled first, before LAMMPS is built, if you wish to include
that package. If you get a LAMMPS build error about a missing
library, this is likely the reason. See the
-<a class="reference internal" href="Section_packages.html"><span class="doc">Section_packages</span></a> doc page for a list of
+<a class="reference internal" href="Section_packages.html"><span class="doc">Section 4</span></a> doc page for a list of
packages that have these kinds of auxiliary libraries.</p>
<p>The lib directory in the distribution has sub-directories with package
names that correspond to the needed auxiliary libs, e.g. lib/gpu.
Each sub-directory has a README file that gives more details. Code
for most of the auxiliary libraries is included in that directory.
Examples are the USER-ATC and MEAM packages.</p>
<p>A few of the lib sub-directories do not include code, but do include
instructions (and sometimes scripts) that automate the process of
downloading the auxiliary library and installing it so LAMMPS can link
to it. Examples are the KIM, VORONOI, USER-MOLFILE, and USER-SMD
packages.</p>
<p>The lib/python directory (for the PYTHON package) contains only a
choice of Makefile.lammps.* files. This is because no auxiliary code
or libraries are needed, only the Python library and other system libs
that should already available on your system. However, the
Makefile.lammps file is needed to tell LAMMPS which libs to use and
where to find them.</p>
<p>For libraries with provided code, the sub-directory README file
(e.g. lib/atc/README) has instructions on how to build that library.
This information is also summarized in <a class="reference internal" href="Section_packages.html"><span class="doc">Section packages</span></a>. Typically this is done by typing
<p>The Makefile.lammps file will typically be a copy of one of the
Makefile.lammps.* files in the library directory.</p>
<p>Note that you must insure that the settings in Makefile.lammps are
appropriate for your system. If they are not, the LAMMPS build may
fail. To fix this, you can edit or create a new Makefile.lammps.*
file for your system, and copy it to Makefile.lammps.</p>
<p>As explained in the lib/package/README files, the settings in
Makefile.lammps are used to specify additional system libraries and
their locations so that LAMMPS can build with the auxiliary library.
For example, if the MEAM package is used, the auxiliary library
consists of F90 code, built with a Fortran complier. To link that
library with LAMMPS (a C++ code) via whatever C++ compiler LAMMPS is
built with, typically requires additional Fortran-to-C libraries be
included in the link. Another example are the BLAS and LAPACK
libraries needed to use the USER-ATC or USER-AWPMD packages.</p>
<p>For libraries without provided code, the sub-directory README file has
information on where to download the library and how to build it,
e.g. lib/voronoi/README and lib/smd/README. The README files also
describe how you must either (a) create soft links, via the “ln”
command, in those directories to point to where you built or installed
the packages, or (b) check or edit the Makefile.lammps file in the
same directory to provide that information.</p>
<p>Some of the sub-directories, e.g. lib/voronoi, also have an install.py
script which can be used to automate the process of
downloading/building/installing the auxiliary library, and setting the
needed soft links. Type “python install.py” for further instructions.</p>
<p>As with the sub-directories containing library code, if the soft links
or settings in the lib/package/Makefile.lammps files are not correct,
the LAMMPS build will typically fail.</p>
<hr class="docutils" />
<p id="start-3-4"><a href="#id19"><span class="problematic" id="id20">**</span></a><em>Packages that require Makefile.machine settings</em>**</p>
<p>A few packages require specific settings in Makefile.machine, to
either build or use the package effectively. These are the
USER-INTEL, KOKKOS, USER-OMP, and OPT packages, used for accelerating
code performance on CPUs or other hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section acclerate</span></a>.</p>
<p>A summary of what Makefile.machine changes are needed for each of
these packages is given in <a class="reference internal" href="Section_packages.html"><span class="doc">Section packages</span></a>.
The details are given on the doc pages that describe each of these
<p>You can also look at the following machine Makefiles in
src/MAKE/OPTIONS, which include the changes. Note that the USER-INTEL
and KOKKOS packages allow for settings that build LAMMPS for different
hardware. The USER-INTEL package builds for CPU and the Xeon Phi, the
KOKKOS package builds for OpenMP, GPUs (Cuda), and the Xeon Phi.</p>
<ul class="simple">
<li>Makefile.intel_cpu</li>
<li>Makefile.intel_phi</li>
<li>Makefile.kokkos_omp</li>
<li>Makefile.kokkos_cuda</li>
<li>Makefile.kokkos_phi</li>
<li>Makefile.omp</li>
<li>Makefile.opt</li>
</ul>
<p>Also note that the Make.py tool, described in the next <a class="reference internal" href="#start-4"><span class="std std-ref">Section 2.4</span></a> can automatically add the needed info to an existing
machine Makefile, using simple command-line arguments.</p>
relocation R_X86_64_32 against '__pthread_key_create' can not be used
when making a shared object; recompile with -fPIC
../../lib/colvars/libcolvars.a: error adding symbols: Bad value
</pre>
<p>As an example, here is how to build and install the <a class="reference external" href="http://www-unix.mcs.anl.gov/mpi">MPICH library</a>, a popular open-source version of MPI, distributed by
Argonne National Labs, as a shared library in the default
<h3>2.5.4. <strong>Calling the LAMMPS library:</strong></h3>
<p>Either flavor of library (static or shared) allows one or more LAMMPS
objects to be instantiated from the calling program.</p>
<p>When used from a C++ program, all of LAMMPS is wrapped in a LAMMPS_NS
namespace; you can safely use any of its classes and methods from
within the calling code, as needed.</p>
<p>When used from a C or Fortran program or a scripting language like
Python, the library has a simple function-style interface, provided in
src/library.cpp and src/library.h.</p>
<p>See the sample codes in examples/COUPLE/simple for examples of C++ and
C and Fortran codes that invoke LAMMPS thru its library interface.
There are other examples as well in the COUPLE directory which are
-discussed in <a class="reference internal" href="Section_howto.html#howto-10"><span class="std std-ref">Section_howto 10</span></a> of the
-manual. See <a class="reference internal" href="Section_python.html"><span class="doc">Section_python</span></a> of the manual for a
+discussed in <a class="reference internal" href="Section_howto.html#howto-10"><span class="std std-ref">Section 6.10</span></a> of the
+manual. See <a class="reference internal" href="Section_python.html"><span class="doc">Section 11</span></a> of the manual for a
description of the Python wrapper provided with LAMMPS that operates
through the LAMMPS library interface.</p>
<p>The files src/library.cpp and library.h define the C-style API for
using LAMMPS as a library. See <a class="reference internal" href="Section_howto.html#howto-19"><span class="std std-ref">Section_howto 19</span></a> of the manual for a description of the
interface and how to extend it for your needs.</p>
<p>Explicitly enable or disable KOKKOS support, as provided by the KOKKOS
package. Even if LAMMPS is built with this package, as described
above in <a class="reference internal" href="#start-3"><span class="std std-ref">Section 2.3</span></a>, this switch must be set to enable
running with the KOKKOS-enabled styles the package provides. If the
switch is not set (the default), LAMMPS will operate as if the KOKKOS
package were not installed; i.e. you can run standard LAMMPS or with
the GPU or USER-OMP packages, for testing or benchmarking purposes.</p>
<p>Additional optional keyword/value pairs can be specified which
determine how Kokkos will use the underlying hardware on your
platform. These settings apply to each MPI task you launch via the
“mpirun” or “mpiexec” command. You may choose to run one or more MPI
tasks per physical node. Note that if you are running on a desktop
machine, you typically have one physical node. On a cluster or
supercomputer there may be dozens or 1000s of physical nodes.</p>
<p>Either the full word or an abbreviation can be used for the keywords.
Note that the keywords do not use a leading minus sign. I.e. the
keyword is “t”, not “-t”. Also note that each of the keywords has a
default setting. Example of when to use these options and what
settings to use on different platforms is given in <a class="reference internal" href="Section_accelerate.html#acc-3"><span class="std std-ref">Section 5.8</span></a>.</p>
<p>Use variants of various styles if they exist. The specified style can
be <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, <em>opt</em>, or <em>hybrid</em>. These
refer to optional packages that LAMMPS can be built with, as described
above in <a class="reference internal" href="#start-3"><span class="std std-ref">Section 2.3</span></a>. The “gpu” style corresponds to the
GPU package, the “intel” style to the USER-INTEL package, the “kk”
style to the KOKKOS package, the “opt” style to the OPT package, and
the “omp” style to the USER-OMP package. The hybrid style is the only
style that accepts arguments. It allows for two packages to be
specified. The first package specified is the default and will be used
if it is available. If no style is available for the first package,
the style for the second package will be used if available. For
example, “-suffix hybrid intel omp” will use styles from the
USER-INTEL package if they are installed and available, but styles for
the USER-OMP package otherwise.</p>
<p>Along with the “-package” command-line switch, this is a convenient
mechanism for invoking accelerator packages and their options without
having to edit an input script.</p>
<p>As an example, all of the packages provide a <a class="reference internal" href="pair_lj.html"><span class="doc">pair_style lj/cut</span></a> variant, with style names lj/cut/gpu,
lj/cut/intel, lj/cut/kk, lj/cut/omp, and lj/cut/opt. A variant style
can be specified explicitly in your input script, e.g. pair_style
lj/cut/gpu. If the -suffix switch is used the specified suffix
(gpu,intel,kk,omp,opt) is automatically appended whenever your input
script command creates a new <a class="reference internal" href="atom_style.html"><span class="doc">atom</span></a>,
<a class="reference internal" href="run_style.html"><span class="doc">run</span></a> style. If the variant version does not exist,
the standard version is created.</p>
<p>For the GPU package, using this command-line switch also invokes the
default GPU settings, as if the command “package gpu 1” were used at
the top of your input script. These settings can be changed by using
the “-package gpu” command-line switch or the <a class="reference internal" href="package.html"><span class="doc">package gpu</span></a> command in your script.</p>
<p>For the USER-INTEL package, using this command-line switch also
invokes the default USER-INTEL settings, as if the command “package
intel 1” were used at the top of your input script. These settings
can be changed by using the “-package intel” command-line switch or
the <a class="reference internal" href="package.html"><span class="doc">package intel</span></a> command in your script. If the
USER-OMP package is also installed, the hybrid style with “intel omp”
arguments can be used to make the omp suffix a second choice, if a
requested style is not available in the USER-INTEL package. It will
also invoke the default USER-OMP settings, as if the command “package
omp 0” were used at the top of your input script. These settings can
be changed by using the “-package omp” command-line switch or the
<a class="reference internal" href="package.html"><span class="doc">package omp</span></a> command in your script.</p>
<p>For the KOKKOS package, using this command-line switch also invokes
the default KOKKOS settings, as if the command “package kokkos” were
used at the top of your input script. These settings can be changed
by using the “-package kokkos” command-line switch or the <a class="reference internal" href="package.html"><span class="doc">package kokkos</span></a> command in your script.</p>
<p>For the OMP package, using this command-line switch also invokes the
default OMP settings, as if the command “package omp 0” were used at
the top of your input script. These settings can be changed by using
the “-package omp” command-line switch or the <a class="reference internal" href="package.html"><span class="doc">package omp</span></a> command in your script.</p>
<p>The <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command can also be used within an input
script to set a suffix, or to turn off or back on any suffix setting
<p>Specify a variable that will be defined for substitution purposes when
the input script is read. This switch can be used multiple times to
define multiple variables. “Name” is the variable name which can be a
single character (referenced as $x in the input script) or a full
string (referenced as ${abc}). An <a class="reference internal" href="variable.html"><span class="doc">index-style variable</span></a> will be created and populated with the
subsequent values, e.g. a set of filenames. Using this command-line
option is equivalent to putting the line “variable name index value1
value2 ...” at the beginning of the input script. Defining an index
variable as a command-line argument overrides any setting for the same
index variable in the input script, since index variables cannot be
re-defined. See the <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command for more info on
defining index and other kinds of variables and <a class="reference internal" href="Section_commands.html#cmd-2"><span class="std std-ref">this section</span></a> for more info on using variables
in input scripts.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Currently, the command-line parser looks for arguments that
start with “-” to indicate new switches. Thus you cannot specify
multiple variable values if any of they start with a “-”, e.g. a
negative numeric value. It is OK if the first value1 starts with a
“-”, since it is automatically skipped.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Note that if the “-sf gpu” switch is used, it also issues a default
<a class="reference internal" href="package.html"><span class="doc">package gpu 1</span></a> command, which sets the number of
GPUs/node to 1.</p>
<p>Using the “-pk” switch explicitly allows for setting of the number of
GPUs/node to use and additional options. Its syntax is the same as
same as the “package gpu” command. See the <a class="reference internal" href="package.html"><span class="doc">package</span></a>
command doc page for details, including the default values used for
all its options if it is not specified.</p>
<p>Note that the default for the <a class="reference internal" href="package.html"><span class="doc">package gpu</span></a> command is to
set the Newton flag to “off” pairwise interactions. It does not
affect the setting for bonded interactions (LAMMPS default is “on”).
The “off” setting for pairwise interaction is currently required for
GPU package pair styles.</p>
<p><strong>Or run with the GPU package by editing an input script:</strong></p>
<p>The discussion above for the mpirun/mpiexec command, MPI tasks/node,
and use of multiple MPI tasks/GPU is the same.</p>
<p>Use the <a class="reference internal" href="suffix.html"><span class="doc">suffix gpu</span></a> command, or you can explicitly add an
“gpu” suffix to individual styles in your input script, e.g.</p>
<pre class="literal-block">
pair_style lj/cut/gpu 2.5
</pre>
<p>You must also use the <a class="reference internal" href="package.html"><span class="doc">package gpu</span></a> command to enable the
GPU package, unless the “-sf gpu” or “-pk gpu” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switches</span></a> were used. It specifies the
number of GPUs/node to use, as well as other options.</p>
<p><strong>Speed-ups to expect:</strong></p>
<p>The performance of a GPU versus a multi-core CPU is a function of your
hardware, which pair style is used, the number of atoms/GPU, and the
precision used on the GPU (double, single, mixed).</p>
<p>See the <a class="reference external" href="http://lammps.sandia.gov/bench.html">Benchmark page</a> of the
LAMMPS web site for performance of the GPU package on various
hardware, including the Titan HPC platform at ORNL.</p>
<p>You should also experiment with how many MPI tasks per GPU to use to
give the best performance for your problem and machine. This is also
a function of the problem size and the pair style being using.
Likewise, you should experiment with the precision setting for the GPU
library to see if single or mixed precision will give accurate
results, since they will typically be faster.</p>
<p><strong>Guidelines for best performance:</strong></p>
<ul class="simple">
<li>Using multiple MPI tasks per GPU will often give the best performance,
as allowed my most multi-core CPU/GPU configurations.</li>
<li>If the number of particles per MPI task is small (e.g. 100s of
particles), it can be more efficient to run with fewer MPI tasks per
GPU, even if you do not use all the cores on the compute node.</li>
<li>The <a class="reference internal" href="package.html"><span class="doc">package gpu</span></a> command has several options for tuning
performance. Neighbor lists can be built on the GPU or CPU. Force
calculations can be dynamically balanced across the CPU cores and
GPUs. GPU-specific settings can be made which can be optimized
for different hardware. See the <a class="reference internal" href="package.html"><span class="doc">packakge</span></a> command
doc page for details.</li>
<li>As described by the <a class="reference internal" href="package.html"><span class="doc">package gpu</span></a> command, GPU
accelerated pair styles can perform computations asynchronously with
CPU computations. The “Pair” time reported by LAMMPS will be the
maximum of the time required to complete the CPU pair style
computations and the time required to complete the GPU pair style
computations. Any time spent for GPU-enabled pair styles for
computations that run simultaneously with <a class="reference internal" href="bond_style.html"><span class="doc">bond</span></a>,
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p><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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<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>
</ul>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
atom_style atomic
atom_style bond
atom_style full
atom_style body nparticle 2 10
atom_style hybrid charge bond
atom_style hybrid charge body nparticle 2 5
atom_style template myMols
</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Define what style of atoms to use in a simulation. This determines
what attributes are associated with the atoms. This command must be
used before a simulation is setup via a <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>,
<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
+<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+simpler entities that body particles. See <a class="reference internal" href="Section_howto.html#howto-14"><span class="std std-ref">Section 6.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
+<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 10.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
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
<pre class="literal-block">
delete_bonds all stats
delete_bonds all bond 0 remove
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<p>The style <em>p</em> means the box is periodic, so that particles interact
across the boundary, and they can exit one end of the box and re-enter
the other end. A periodic dimension can change in size due to
constant pressure boundary conditions or box deformation (see the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> and <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> commands). The <em>p</em>
style must be applied to both faces of a dimension.</p>
<p>The styles <em>f</em>, <em>s</em>, and <em>m</em> mean the box is non-periodic, so that
particles do not interact across the boundary and do not move from one
side of the box to the other.</p>
<p>For style <em>f</em>, the position of the face is fixed. If an atom moves
outside the face it will be deleted on the next timestep that
reneighboring occurs. This will typically generate an error unless
you have set the <a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify lost</span></a> option to
allow for lost atoms.</p>
<p>For style <em>s</em>, the position of the face is set so as to encompass the
atoms in that dimension (shrink-wrapping), no matter how far they
move.</p>
<p>For style <em>m</em>, shrink-wrapping occurs, but is bounded by the value
specified in the data or restart file or set by the
<a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> command. For example, if the upper z
face has a value of 50.0 in the data file, the face will always be
positioned at 50.0 or above, even if the maximum z-extent of all the
atoms becomes less than 50.0. This can be useful if you start a
simulation with an empty box or if you wish to leave room on one side
of the box, e.g. for atoms to evaporate from a surface.</p>
<p>For triclinic (non-orthogonal) simulation boxes, if the 2nd dimension
of a tilt factor (e.g. y for xy) is periodic, then the periodicity is
enforced with the tilt factor offset. If the 1st dimension is
shrink-wrapped, then the shrink wrapping is applied to the tilted box
face, to encompass the atoms. E.g. for a positive xy tilt, the xlo
and xhi faces of the box are planes tilting in the +y direction as y
increases. These tilted planes are shrink-wrapped around the atoms to
determine the x extent of the box.</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
+<p>See <a class="reference internal" href="Section_howto.html#howto-12"><span class="std std-ref">Section 6.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>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This command cannot be used after the simulation box is defined by a
<a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> or <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> command or
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command. See the
<a class="reference internal" href="change_box.html"><span class="doc">change_box</span></a> command for how to change the simulation
box boundaries after it has been defined.</p>
<p>For 2d simulations, the z dimension must be periodic.</p>
</div>
<div class="section" id="related-commands">
<h2>Related commands</h2>
<p>See the <a class="reference internal" href="thermo_modify.html"><span class="doc">thermo_modify</span></a> command for a discussion
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>
<p>The size and shape of the initial simulation box are 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.
The size and shape may be altered by subsequent runs, e.g. by use of
the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> or <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> commands.
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 also determine whether the
simulation box is orthogonal or triclinic and their doc pages explain
the meaning of the xy,xz,yz tilt factors.</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
+<p>See <a class="reference internal" href="Section_howto.html#howto-12"><span class="std std-ref">Section 6.12</span></a> of the doc pages
for a geometric description of triclinic boxes, as defined by LAMMPS,
and how to transform these parameters to and from other commonly used
triclinic representations.</p>
<p>The keywords used in this command are applied sequentially to the
simulation box and the atoms in it, in the order specified.</p>
<p>Before the sequence of keywords are invoked, the current box
size/shape is stored, in case a <em>remap</em> keyword is used to map the
atom coordinates from a previously stored box size/shape to the
current one.</p>
<p>After all the keywords have been processed, any shrink-wrap boundary
conditions are invoked (see the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command)
which may change simulation box boundaries, and atoms are migrated to
new owning processors.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">This means that you cannot use the change_box command to enlarge
a shrink-wrapped box, e.g. to make room to insert more atoms via the
<a class="reference internal" href="create_atoms.html"><span class="doc">create_atoms</span></a> command, because the simulation box
will be re-shrink-wrapped before the change_box command completes.
Instead you could do something like this, assuming the simulation box
is non-periodic and atoms extend from 0 to 20 in all dimensions:</p>
</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>
<pre class="literal-block">
change_box all x scale 1.1 y volume z volume
</pre>
<p>The <em>volume</em> style changes the associated dimension so that the
overall box volume is unchanged relative to its value before the
preceding keyword was invoked.</p>
<p>If the following command is used, then the z box length will shrink by
the same 1.1 factor the x box length was increased by:</p>
<pre class="literal-block">
change_box all x scale 1.1 z volume
</pre>
<p>If the following command is used, then the y,z box lengths will each
shrink by sqrt(1.1) to keep the volume constant. In this case, the
y,z box lengths shrink so as to keep their relative aspect ratio
constant:</p>
<pre class="literal-block">
change_box all"x scale 1.1 y volume z volume
</pre>
<p>If the following command is used, then the final box will be a factor
of 10% larger in x and y, and a factor of 21% smaller in z, so as to
keep the volume constant:</p>
<pre class="literal-block">
change_box all x scale 1.1 z volume y scale 1.1 z volume
</pre>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For solids or liquids, when one dimension of the box is
expanded, it may be physically undesirable to hold the other 2 box
lengths constant since that implies a density change. For solids,
adjusting the other dimensions via the <em>volume</em> style may make
physical sense (just as for a liquid), but may not be correct for
materials and potentials whose Poisson ratio is not 0.5.</p>
</div>
<p>For the <em>scale</em> and <em>volume</em> styles, the box length is expanded or
compressed around its mid point.</p>
<hr class="docutils" />
<p>For the <em>xy</em>, <em>xz</em>, and <em>yz</em> parameters, this is the meaning of their
styles and values. Note that changing the tilt factors of a triclinic
box does not change its volume.</p>
<p>For style <em>final</em>, the final tilt factor is specified. The value
can be in lattice or box distance units. See the discussion of the
units keyword below.</p>
<p>For style <em>delta</em>, a plus or minus change in the tilt factor is
specified. The value can be in lattice or box distance units. See
the discussion of the units keyword below.</p>
<p>All of these styles change the xy, xz, yz tilt factors. In LAMMPS,
tilt factors (xy,xz,yz) for triclinic boxes are required to be no 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 equivalent. Any tilt factor specified by this command
must be within these limits.</p>
<hr class="docutils" />
<p>The <em>boundary</em> keyword takes arguments that have exactly the same
meaning as they do for the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command. In each
dimension, a single letter assigns the same style to both the lower
and upper face of the box. Two letters assigns the first style to the
lower face and the second style to the upper face.</p>
<p>The style <em>p</em> means the box is periodic; the other styles mean
non-periodic. For style <em>f</em>, the position of the face is fixed. For
style <em>s</em>, the position of the face is set so as to encompass the
atoms in that dimension (shrink-wrapping), no matter how far they
move. For style <em>m</em>, shrink-wrapping occurs, but is bounded by the
current box edge in that dimension, so that the box will become no
smaller. See the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command for more
explanation of these style options.</p>
<p>Note that the “boundary” command itself can only be used before the
simulation box is defined via a <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> or
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>.
+comm_modift mode multi cutoff/multi 1 10.0 cutoff/multi 2*4 15.0
+comm_modify vel yes
+comm_modify mode single cutoff 5.0 vel yes
+comm_modify cutoff/multi * 0.0
+</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>This command sets parameters that affect the 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>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">These options apply to the currently defined comm style. When
you specify a <a class="reference internal" href="comm_style.html"><span class="doc">comm_style</span></a> command, all communication
settings are restored to their default values, including those
previously reset by a comm_modify command. Thus if your input script
specifies a comm_style command, you should use the comm_modify command
after it.</p>
</div>
<p>The <em>mode</em> keyword determines whether a single or multiple cutoff
distances are used to determine which atoms to communicate.</p>
<p>The default mode is <em>single</em> which means each processor acquires
information for ghost atoms that are within a single distance from its
sub-domain. The distance is by default the maximum of the neighbor
cutoff across all atom type pairs.</p>
<p>For many systems this is an efficient algorithm, but for systems with
widely varying cutoffs for different type pairs, the <em>multi</em> mode can
be faster. In this case, each atom type is assigned its own distance
cutoff for communication purposes, and fewer atoms will be
communicated. See the <a class="reference internal" href="neighbor.html"><span class="doc">neighbor multi</span></a> command for a
neighbor list construction option that may also be beneficial for
simulations of this kind.</p>
<p>The <em>cutoff</em> keyword allows you to extend the ghost cutoff distance
for communication mode <em>single</em>, which is the distance from the borders
of a processor’s sub-domain at which ghost atoms are acquired from other
processors. By default the ghost cutoff = neighbor cutoff = pairwise
force cutoff + neighbor skin. See the <a class="reference internal" href="neighbor.html"><span class="doc">neighbor</span></a> command
for more information about the skin distance. If the specified Rcut is
greater than the neighbor cutoff, then extra ghost atoms will be acquired.
If the provided cutoff is smaller, the provided value will be ignored
and the ghost cutoff is set to the neighbor cutoff. Specifying a
cutoff value of 0.0 will reset any previous value to the default.</p>
<p>The <em>cutoff/multi</em> option is equivalent to <em>cutoff</em>, but applies to
communication mode <em>multi</em> instead. Since in this case the communication
cutoffs are determined per atom type, a type specifier is needed and
cutoff for one or multiple types can be extended. Also ranges of types
using the usual asterisk notation can be given.</p>
<p>These are simulation scenarios in which it may be useful or even
necessary to set a ghost cutoff > neighbor cutoff:</p>
<ul class="simple">
<li>a single polymer chain with bond interactions, but no pairwise interactions</li>
<li>bonded interactions (e.g. dihedrals) extend further than the pairwise cutoff</li>
<li>ghost atoms beyond the pairwise cutoff are needed for some computation</li>
</ul>
<p>In the first scenario, a pairwise potential is not defined. Thus the
pairwise neighbor cutoff will be 0.0. But ghost atoms are still
needed for computing bond, angle, etc interactions between atoms on
different processors, or when the interaction straddles a periodic
boundary.</p>
<p>The appropriate ghost cutoff depends on the <a class="reference internal" href="newton.html"><span class="doc">newton bond</span></a>
setting. For newton bond <em>off</em>, the distance needs to be the furthest
distance between any two atoms in the bond, angle, etc. E.g. the
distance between 1-4 atoms in a dihedral. For newton bond <em>on</em>, the
distance between the central atom in the bond, angle, etc and any
other atom is sufficient. E.g. the distance between 2-4 atoms in a
dihedral.</p>
<p>In the second scenario, a pairwise potential is defined, but its
neighbor cutoff is not sufficiently long enough to enable bond, angle,
etc terms to be computed. As in the previous scenario, an appropriate
ghost cutoff should be set.</p>
<p>In the last scenario, a <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="pair_style.html"><span class="doc">pairwise potential</span></a> needs to calculate with ghost
atoms beyond the normal pairwise cutoff for some computation it
performs (e.g. locate neighbors of ghost atoms in a multibody pair
potential). Setting the ghost cutoff appropriately can insure it will
find the needed atoms.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">In these scenarios, if you do not set the ghost cutoff long
enough, and if there is only one processor in a periodic dimension
(e.g. you are running in serial), then LAMMPS may “find” the atom it
is looking for (e.g. the partner atom in a bond), that is on the far
side of the simulation box, across a periodic boundary. This will
typically lead to bad dynamics (i.e. the bond length is now the
simulation box length). To detect if this is happening, see 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 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>Defines a computation that calculates the local lattice structure
according to the formulation given in <a class="reference internal" href="#ackland"><span class="std std-ref">(Ackland)</span></a>.</p>
<p>In contrast to the <a class="reference internal" href="compute_centro_atom.html"><span class="doc">centro-symmetry parameter</span></a> this method is stable against
temperature boost, because it is based not on the distance between
particles but the angles. Therefore statistical fluctuations are
averaged out a little more. A comparison with the Common Neighbor
Analysis metric is made in the paper.</p>
<p>The result is a number which is mapped to the following different
lattice structures:</p>
<ul class="simple">
<li>0 = UNKNOWN</li>
<li>1 = BCC</li>
<li>2 = FCC</li>
<li>3 = HCP</li>
<li>4 = ICO</li>
</ul>
<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 or to have multiple compute/dump commands, each of
which computes this quantity.-</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
+<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section 6.15</span></a> for an overview of
LAMMPS output options.</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 per-atom vector values will be unitless since they are 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 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>
+explained below. See <a class="reference internal" href="Section_howto.html#howto-14"><span class="std std-ref">Section 6.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>.
<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
+<p>See <a class="reference internal" href="Section_howto.html#howto-23"><span class="std std-ref">Section 6.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
+<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section 6.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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using 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 the per-atom damage for each atom
in a group. This is a quantity relevant for <a class="reference internal" href="pair_peri.html"><span class="doc">Peridynamics models</span></a>. See <a class="reference external" href="PDF/PDLammps_overview.pdf">this document</a>
for an overview of LAMMPS commands for Peridynamics modeling.</p>
<p>The “damage” of a Peridymaics particles is based on the bond breakage
between the particle and its neighbors. If all the bonds are broken
the particle is considered to be fully damaged.</p>
<p>See the <a class="reference external" href="http://www.sandia.gov/~mlparks/papers/PDLAMMPS.pdf">PDLAMMPS user guide</a> for a formal
definition of “damage” and more details about Peridynamics as it is
implemented in LAMMPS.</p>
<p>This command can be used with all the Peridynamic pair styles.</p>
<p>The damage value 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
+<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section 6.15</span></a> for an overview of
LAMMPS output options.</p>
<p>The per-atom vector values are unitlesss numbers (damage) >= 0.0.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This compute is part of the PERI 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 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>This compute requires that line segment particles atoms store a length
and orientation and angular velocity as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style line</span></a> command.</p>
<p>This compute requires that triangular particles atoms store a size and
shape and quaternion orientation and angular momentum as defined by
the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style tri</span></a> command.</p>
<p>All particles in the group must be finite-size. They cannot be point
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using 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 rotational kinetic energy of
a collection of rigid bodies, as defined by one of the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a> command variants.</p>
<p>The rotational energy of each rigid body is computed as 1/2 I Wbody^2,
where I is the inertia tensor for the rigid body, and Wbody is its
angular velocity vector. Both I and Wbody are in the frame of
reference of the rigid body, i.e. I is diagonalized.</p>
<p>The <em>fix-ID</em> should be the ID of one of the <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a>
commands which defines the rigid bodies. The group specified in the
compute command is ignored. The rotational energy of all the rigid
bodies defined by the fix rigid command in included in the
calculation.</p>
<p><strong>Output info:</strong></p>
<p>This compute calculates a global scalar (the summed rotational energy
of all the rigid bodies). This value can be used by any command that
uses a global scalar value from a compute as input. See
-<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section_howto 15</span></a> for an overview of
+<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section 6.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 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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>Define a computation that flags an “event” if any particle in the
group has moved a distance greater than the specified threshold
distance when compared to a previously stored reference state
(i.e. the previous event). This compute is typically used in
conjunction with the <a class="reference internal" href="prd.html"><span class="doc">prd</span></a> and <a class="reference internal" href="tad.html"><span class="doc">tad</span></a> commands,
to detect if a transition
to a new minimum energy basin has occurred.</p>
<p>This value calculated by the compute is equal to 0 if no particle has
moved far enough, and equal to 1 if one or more particles have moved
further than the threshold distance.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If the system is undergoing significant center-of-mass motion,
due to thermal motion, an external force, or an initial net momentum,
then this compute will not be able to distinguish that motion from
local atom displacements and may generate “false postives.”</p>
</div>
<p><strong>Output info:</strong></p>
<p>This compute calculates a global scalar (the flag). 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
+input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section 6.15</span></a> for an
overview of LAMMPS output options.</p>
<p>The scalar value calculated by this compute is “intensive”. The
scalar value will be a 0 or 1 as explained above.</p>
</div>
<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
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using 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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>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>
command, as shown in the following example:</p>
</div>
<pre class="literal-block">
compute effTemp all temp/eff
thermo_style custom step etotal pe ke temp press
thermo_modify temp effTemp
</pre>
<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
+<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section 6.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
+input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section 6.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>Define a computation that calculates the per-atom internal energy
for each atom in a group.</p>
<p>The internal energy is the energy associated with the internal degrees
of freedom of a mesoscopic particles, e.g. a Smooth-Particle
Hydrodynamics particle.</p>
<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
+<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section 6.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-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>Define a computation that calculates the per-atom mesoscopic density
for each atom in a group.</p>
<p>The mesoscopic density is the mass density of a mesoscopic particle,
calculated by kernel function interpolation using “pair style
sph/rhosum”.</p>
<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 mesoscopic density 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
+<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section 6.15</span></a> for an overview of
LAMMPS output options.</p>
<p>The per-atom vector values will be in mass/volume <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>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
+<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section 6.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>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
in the last 2 columns of thermo output:</p>
<pre class="literal-block">
compute peratom all pe/atom
compute pe all reduce sum c_peratom
thermo_style custom step temp etotal press pe c_pe
</pre>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The per-atom energy does not any Lennard-Jones tail corrections
invoked by the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify tail yes</span></a> command, since
those are global contributions to the system energy.</p>
</div>
<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
+<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section 6.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>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>
</ul>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
compute 1 all pressure thermo_temp
compute 1 all pressure NULL pair bond
</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<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>
<pre class="literal-block">
compute thermo_press all pressure thermo_temp
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using 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
<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 “*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 compute reduce 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>
<pre class="literal-block">
compute myPress all stress/atom NULL
compute 2 all reduce min myPress[*]
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 “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 “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 “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>
<pre class="literal-block">
compute 1 all property/local batom1 batom2
compute 2 all bond/local dist
compute 3 all reduce max c_1[1] c_1[2] c_2 replace 1 3 replace 2 3
<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>
+compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section 6.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>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 which outputs the contact radius, i.e., the
radius used to prevent particles from penetrating each other. The
contact radius is used only to prevent particles belonging to
different physical bodies from penetrating each other. It is used by
the contact pair styles, e.g., smd/hertz and smd/tri_surface.</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>The value of the contact radius will be 0.0 for particles not in the
specified compute group.</p>
<p><strong>Output info:</strong></p>
<p>This compute calculates a per-particle vector, which can be accessed by
any command that uses per-particle 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
+<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section 6.15</span></a> for an overview of
LAMMPS output options.</p>
<p>The per-particle vector values will be in distance <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-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>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>Define a computation that returns the number of neighbor particles
inside of the smoothing kernel radius for particles interacting via
the updated Lagrangian SPH pair style.</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, which can be accessed by
any command that uses per-particle 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
+See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section 6.15</span></a> for an overview of
LAMMPS output options.</p>
<p>The per-particle values will be given dimentionless, see <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-SMD package. It is only enabled if
LAMMPS was built with that package. 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. This compute
can only be used for particles which interact with the updated
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using 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 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. This compute
can only be used for particles which interact with the updated
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using 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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<li>ID, group-ID are documented in <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command</li>
<li>temp/cs = style name of this compute command</li>
<li>group1 = group-ID of either cores or shells</li>
<li>group2 = group-ID of either shells or cores</li>
</ul>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
compute oxygen_c-s all temp/cs O_core O_shell
compute core_shells all temp/cs cores shells
</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<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
+<a class="reference internal" href="Section_howto.html#howto-25"><span class="std std-ref">Section 6.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>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 = dimensionality of the simulation, N = number of atoms in the
group, k = Boltzmann constant, and T = temperature. The calculation
of KE excludes the x, y, or z dimensions if xflag, yflag, or zflag =
0. The dim parameter is adjusted to give the correct number of
degrees of freedom.</p>
<p>A kinetic energy tensor, stored as a 6-element vector, is also
calculated by this compute for use in the calculation 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>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>The removal of velocity components by this fix is essentially
computing the temperature after a “bias” has been removed from the
velocity of the atoms. 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 thermal velocity will be
performed, and the bias will be added back in. 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>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>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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 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>
+compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section 6.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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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
+<p>See <a class="reference internal" href="Section_howto.html#howto-12"><span class="std std-ref">Section 6.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>.
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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>[...]</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The following coefficients must be defined for each dihedral type via the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy)</li>
<li>d (+1 or -1)</li>
<li>n (integer >= 0)</li>
</ul>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Here are important points to take note of when defining LAMMPS
dihedral coefficients for the harmonic style, so that they are
compatible with how harmonic dihedrals are defined by other force
fields:</p>
</div>
<ul class="simple">
<li>The LAMMPS convention is that the trans position = 180 degrees, while
in some force fields trans = 0 degrees.</li>
<li>Some force fields reverse the sign convention on <em>d</em>.</li>
<li>Some force fields let <em>n</em> be positive or negative which corresponds to
<em>d</em> = 1 or -1 for the harmonic style.</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This coarse-grain dihedral potential is described in <a class="reference internal" href="#guo"><span class="std std-ref">(Guo)</span></a>.
For dihedral angles in the helical region, the energy function is
represented by a standard potential consisting of three minima, one
corresponding to the trans (t) state and the other to gauche states
(g+ and g-). The paper describes how the A,B,C parameters are chosen
so as to balance secondary (largely driven by local interactions) and
tertiary structure (driven by long-range interactions).</p>
<p>The following coefficients must be defined for each dihedral type via the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>A (energy)</li>
<li>B (energy)</li>
<li>C (energy)</li>
</ul>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using 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
possible attributes = index, c_ID, c_ID[I], f_ID, f_ID[I]
index = enumeration of local values
c_ID = local vector calculated by a compute with ID
c_ID[I] = Ith column of local array calculated by a compute with ID, I can include wildcard (see below)
f_ID = local vector calculated by a fix with ID
f_ID[I] = Ith column of local array calculated by a fix with ID, I can include wildcard (see below)
</pre>
<pre class="literal-block">
<em>custom</em> or <em>custom/gz</em> or <em>custom/mpiio</em> args = list of atom attributes
possible attributes = id, mol, proc, procp1, type, element, mass,
x, y, z, xs, ys, zs, xu, yu, zu,
xsu, ysu, zsu, ix, iy, iz,
vx, vy, vz, fx, fy, fz,
q, mux, muy, muz, mu,
radius, diameter, omegax, omegay, omegaz,
angmomx, angmomy, angmomz, tqx, tqy, tqz,
c_ID, c_ID[N], f_ID, f_ID[N], v_name
</pre>
<pre class="literal-block">
id = atom ID
mol = molecule ID
proc = ID of processor that owns atom
procp1 = ID+1 of processor that owns atom
type = atom type
element = name of atom element, as defined by <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command
mass = atom mass
x,y,z = unscaled atom coordinates
xs,ys,zs = scaled atom coordinates
xu,yu,zu = unwrapped atom coordinates
xsu,ysu,zsu = scaled unwrapped atom coordinates
ix,iy,iz = box image that the atom is in
vx,vy,vz = atom velocities
fx,fy,fz = forces on atoms
q = atom charge
mux,muy,muz = orientation of dipole moment of atom
mu = magnitude of dipole moment of atom
radius,diameter = radius,diameter of spherical particle
omegax,omegay,omegaz = angular velocity of spherical particle
angmomx,angmomy,angmomz = angular momentum of aspherical particle
tqx,tqy,tqz = torque on finite-size particles
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
d_name = per-atom floating point vector with name, managed by fix property/atom
i_name = per-atom integer vector with name, managed by fix property/atom
</pre>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
dump myDump all atom 100 dump.atom
dump myDump all atom/mpiio 100 dump.atom.mpiio
dump myDump all atom/gz 100 dump.atom.gz
dump 2 subgroup atom 50 dump.run.bin
dump 2 subgroup atom 50 dump.run.mpiio.bin
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>where xlo,xhi are the maximum extents of the simulation box in the
x-dimension, and similarly for y and z. The “xx yy zz” represent 6
characters that encode the style of boundary for each of the 6
simulation box boundaries (xlo,xhi and ylo,yhi and zlo,zhi). Each of
the 6 characters is either p = periodic, f = fixed, s = shrink wrap,
or m = shrink wrapped with a minimum value. See the
<a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command for details.</p>
<p>For triclinic simulation boxes (non-orthogonal), an orthogonal
bounding box which encloses the triclinic simulation box is output,
along with the 3 tilt factors (xy, xz, yz) of the triclinic box,
formatted as follows:</p>
<pre class="literal-block">
ITEM: BOX BOUNDS xy xz yz xx yy zz
xlo_bound xhi_bound xy
ylo_bound yhi_bound xz
zlo_bound zhi_bound yz
</pre>
<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 “*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>
<pre class="literal-block">
compute myPress all stress/atom NULL
dump 2 all custom 100 tmp.dump id myPress[*]
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
the distance and energy of each bond:</p>
<pre class="literal-block">
compute 1 all property/local batom1 batom2 btype
compute 2 all bond/local dist eng
dump 1 all local 1000 tmp.dump index c_1[1] c_1[2] c_1[3] c_2[1] c_2[2]
</pre>
<hr class="docutils" />
<p>This section explains the atom attributes that can be specified as
part of the <em>custom</em> and <em>cfg</em> styles.</p>
<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
+<p>See <a class="reference internal" href="Section_modify.html"><span class="doc">Section 10</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>.
<li>group-ID = ID of the group of atoms to be dumped</li>
<li>style = <em>custom/vtk</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>custom/vtk</em> args = list of atom attributes
possible attributes = id, mol, proc, procp1, type, element, mass,
x, y, z, xs, ys, zs, xu, yu, zu,
xsu, ysu, zsu, ix, iy, iz,
vx, vy, vz, fx, fy, fz,
q, mux, muy, muz, mu,
radius, diameter, omegax, omegay, omegaz,
angmomx, angmomy, angmomz, tqx, tqy, tqz,
spin, eradius, ervel, erforce,
c_ID, c_ID[N], f_ID, f_ID[N], v_name
</pre>
<pre class="literal-block">
id = atom ID
mol = molecule ID
proc = ID of processor that owns atom
procp1 = ID+1 of processor that owns atom
type = atom type
element = name of atom element, as defined by <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command
mass = atom mass
x,y,z = unscaled atom coordinates
xs,ys,zs = scaled atom coordinates
xu,yu,zu = unwrapped atom coordinates
xsu,ysu,zsu = scaled unwrapped atom coordinates
ix,iy,iz = box image that the atom is in
vx,vy,vz = atom velocities
fx,fy,fz = forces on atoms
q = atom charge
mux,muy,muz = orientation of dipole moment of atom
mu = magnitude of dipole moment of atom
radius,diameter = radius,diameter of spherical particle
omegax,omegay,omegaz = angular velocity of spherical particle
angmomx,angmomy,angmomz = angular momentum of aspherical particle
tqx,tqy,tqz = torque on finite-size particles
c_ID = per-atom vector calculated by a compute with ID
c_ID[N] = Nth column of per-atom array calculated by a compute with ID
f_ID = per-atom vector calculated by a fix with ID
f_ID[N] = Nth 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>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
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
<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
+<p>See <a class="reference internal" href="Section_modify.html"><span class="doc">Section 10</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>group-ID = ID of the group of atoms to be imaged</li>
<li>style = <em>image</em> or <em>movie</em> = style of dump command (other styles <em>atom</em> or <em>cfg</em> or <em>dcd</em> or <em>xtc</em> or <em>xyz</em> or <em>local</em> or <em>custom</em> are discussed on the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> doc page)</li>
<li>N = dump every this many timesteps</li>
<li>file = name of file to write image to</li>
<li>color = atom attribute that determines color of each atom</li>
<li>diameter = atom attribute that determines size of each atom</li>
<li>zero or more keyword/value pairs may be appended</li>
<li>keyword = <em>atom</em> or <em>adiam</em> or <em>bond</em> or <em>line</em> or <em>tri</em> or <em>body</em> or <em>fix</em> or <em>size</em> or <em>view</em> or <em>center</em> or <em>up</em> or <em>zoom</em> or <em>persp</em> or <em>box</em> or <em>axes</em> or <em>subbox</em> or <em>shiny</em> or <em>ssao</em></li>
</ul>
<pre class="literal-block">
<em>atom</em> = yes/no = do or do not draw atoms
<em>adiam</em> size = numeric value for atom diameter (distance units)
<em>bond</em> values = color width = color and width of bonds
color = <em>atom</em> or <em>type</em> or <em>none</em>
width = number or <em>atom</em> or <em>type</em> or <em>none</em>
number = numeric value for bond width (distance units)
<em>line</em> = color width
color = <em>type</em>
width = numeric value for line width (distance units)
<em>tri</em> = color tflag width
color = <em>type</em>
tflag = 1 for just triangle, 2 for just tri edges, 3 for both
width = numeric value for tringle edge width (distance units)
<em>body</em> = color bflag1 bflag2
color = <em>type</em>
bflag1,bflag2 = 2 numeric flags to affect how bodies are drawn
<em>fix</em> = fixID color fflag1 fflag2
fixID = ID of fix that generates objects to dray
color = <em>type</em>
fflag1,fflag2 = 2 numeric flags to affect how fix objects are drawn
<em>size</em> values = width height = size of images
width = width of image in # of pixels
height = height of image in # of pixels
<em>view</em> values = theta phi = view of simulation box
theta = view angle from +z axis (degrees)
phi = azimuthal view angle (degrees)
theta or phi can be a variable (see below)
<em>center</em> values = flag Cx Cy Cz = center point of image
flag = "s" for static, "d" for dynamic
Cx,Cy,Cz = center point of image as fraction of box dimension (0.5 = center of box)
Cx,Cy,Cz can be variables (see below)
<em>up</em> values = Ux Uy Uz = direction that is "up" in image
Ux,Uy,Uz = components of up vector
Ux,Uy,Uz can be variables (see below)
<em>zoom</em> value = zfactor = size that simulation box appears in image
zfactor = scale image size by factor > 1 to enlarge, factor < 1 to shrink
zfactor can be a variable (see below)
<em>persp</em> value = pfactor = amount of "perspective" in image
<p>If <em>type</em> is specified for the <em>diameter</em> setting then the diameter of
each atom is determined by its atom type. By default all types have
diameter 1.0. This mapping can be changed by the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify adiam</span></a> command.</p>
<p>If <em>element</em> is specified for the <em>color</em> and/or <em>diameter</em> setting,
then the color and/or diameter of each atom is determined by which
element it is, which in turn is specified by the element-to-type
mapping specified by the “dump_modify element” command. By default
every atom type is C (carbon). Every element has a color and diameter
associated with it, which is the same as the colors and sizes used by
the <a class="reference external" href="http://mt.seas.upenn.edu/Archive/Graphics/A">AtomEye</a> visualization package.</p>
<p>If other atom attributes are used for the <em>color</em> or <em>diameter</em>
settings, they are interpreted in the following way.</p>
<p>If “vx”, for example, is used as the <em>color</em> setting, then the color
of the atom will depend on the x-component of its velocity. The
association of a per-atom value with a specific color is determined by
a “color map”, which can be specified via the
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command. The basic idea is that the
atom-attribute will be within a range of values, and every value
within the range is mapped to a specific color. Depending on how the
color map is defined, that mapping can take place via interpolation so
that a value of -3.2 is halfway between “red” and “blue”, or
discretely so that the value of -3.2 is “orange”.</p>
<p>If “vx”, for example, is used as the <em>diameter</em> setting, then the atom
will be rendered using the x-component of its velocity as the
diameter. If the per-atom value <= 0.0, them the atom will not be
drawn. Note that finite-size spherical particles, as defined by
<a class="reference internal" href="atom_style.html"><span class="doc">atom_style sphere</span></a> define a per-particle radius or
diameter, which can be used as the <em>diameter</em> setting.</p>
<hr class="docutils" />
<p>The various kewords listed above control how the image is rendered.
As listed below, all of the keywords have defaults, most of which you
will likely not need to change. The <a class="reference internal" href="dump_modify.html"><span class="doc">dump modify</span></a>
also has options specific to the dump image style, particularly for
assigning colors to atoms, bonds, and other image features.</p>
<hr class="docutils" />
<p>The <em>atom</em> keyword allow you to turn off the drawing of all atoms, if
the specified value is <em>no</em>. Note that this will not turn off the
drawing of particles that are represented as lines, triangles, or
bodies, as discussed below. These particles can be drawn separately
if the <em>line</em>, <em>tri</em>, or <em>body</em> keywords are used.</p>
<p>The <em>adiam</em> keyword allows you to override the <em>diameter</em> setting to
set a single numeric <em>size</em>. All atoms will be drawn with that
diameter, e.g. 1.5, which is in whatever distance <a class="reference internal" href="units.html"><span class="doc">units</span></a>
the input script defines, e.g. Angstroms.</p>
<hr class="docutils" />
<p>The <em>bond</em> keyword allows to you to alter how bonds are drawn. A bond
is only drawn if both atoms in the bond are being drawn due to being
in the specified group and due to other selection criteria
(e.g. region, threshhold settings of the
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command). By default, bonds are drawn
if they are defined in the input data file as read by the
<a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command. Using <em>none</em> for both the bond
<em>color</em> and <em>width</em> value will turn off the drawing of all bonds.</p>
<p>If <em>atom</em> is specified for the bond <em>color</em> value, then each bond is
drawn in 2 halves, with the color of each half being the color of the
atom at that end of the bond.</p>
<p>If <em>type</em> is specified for the <em>color</em> value, then the color of each
bond is determined by its bond type. By default the mapping of bond
types to colors is as follows:</p>
<ul class="simple">
<li>type 1 = red</li>
<li>type 2 = green</li>
<li>type 3 = blue</li>
<li>type 4 = yellow</li>
<li>type 5 = aqua</li>
<li>type 6 = cyan</li>
</ul>
<p>and repeats itself for bond types > 6. This mapping can be changed by
the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify bcolor</span></a> command.</p>
<p>The bond <em>width</em> value can be a numeric value or <em>atom</em> or <em>type</em> (or
<em>none</em> as indicated above).</p>
<p>If a numeric value is specified, then all bonds will be drawn as
cylinders with that diameter, e.g. 1.0, which is in whatever distance
<a class="reference internal" href="units.html"><span class="doc">units</span></a> the input script defines, e.g. Angstroms.</p>
<p>If <em>atom</em> is specified for the <em>width</em> value, then each bond
will be drawn with a width corresponding to the minimum diameter
of the 2 atoms in the bond.</p>
<p>If <em>type</em> is specified for the <em>width</em> value then the diameter of each
bond is determined by its bond type. By default all types have
diameter 0.5. This mapping can be changed by the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify bdiam</span></a> command.</p>
<hr class="docutils" />
<p>The <em>line</em> keyword can be used when <a class="reference internal" href="atom_style.html"><span class="doc">atom_style line</span></a>
is used to define particles as line segments, and will draw them as
lines. If this keyword is not used, such particles will be drawn as
spheres, the same as if they were regular atoms. The only setting
currently allowed for the <em>color</em> value is <em>type</em>, which will color
the lines according to the atom type of the particle. By default the
mapping of types to colors is as follows:</p>
<ul class="simple">
<li>type 1 = red</li>
<li>type 2 = green</li>
<li>type 3 = blue</li>
<li>type 4 = yellow</li>
<li>type 5 = aqua</li>
<li>type 6 = cyan</li>
</ul>
<p>and repeats itself for types > 6. There is not yet an option to
change this via the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command.</p>
<p>The line <em>width</em> can only be a numeric value, which specifies that all
lines will be drawn as cylinders with that diameter, e.g. 1.0, which
is in whatever distance <a class="reference internal" href="units.html"><span class="doc">units</span></a> the input script defines,
e.g. Angstroms.</p>
<hr class="docutils" />
<p>The <em>tri</em> keyword can be used when <a class="reference internal" href="atom_style.html"><span class="doc">atom_style tri</span></a> is
used to define particles as triangles, and will draw them as triangles
or edges (3 lines) or both, depending on the setting for <em>tflag</em>. If
edges are drawn, the <em>width</em> setting determines the diameters of the
line segments. If this keyword is not used, triangle particles will
be drawn as spheres, the same as if they were regular atoms. The only
setting currently allowed for the <em>color</em> value is <em>type</em>, which will
color the triangles according to the atom type of the particle. By
default the mapping of types to colors is as follows:</p>
<ul class="simple">
<li>type 1 = red</li>
<li>type 2 = green</li>
<li>type 3 = blue</li>
<li>type 4 = yellow</li>
<li>type 5 = aqua</li>
<li>type 6 = cyan</li>
</ul>
<p>and repeats itself for types > 6. There is not yet an option to
change this via the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command.</p>
<hr class="docutils" />
<p>The <em>body</em> keyword can be used when <a class="reference internal" href="atom_style.html"><span class="doc">atom_style body</span></a>
is used to define body particles with internal state
(e.g. sub-particles), and will drawn them in a manner specific to the
body style. If this keyword is not used, such particles will be drawn
as spheres, the same as if they were regular atoms.</p>
<p>The <a class="reference internal" href="body.html"><span class="doc">body</span></a> doc page descibes the body styles LAMMPS
currently supports, and provides more details as to the kind of body
particles they represent and how they are drawn by this dump image
command. For all the body styles, individual atoms can be either a
body particle or a usual point (non-body) particle. Non-body
particles will be drawn the same way they would be as a regular atom.
The <em>bflag1</em> and <em>bflag2</em> settings are numerical values which are
passed to the body style to affect how the drawing of a body particle
is done. See the <a class="reference internal" href="body.html"><span class="doc">body</span></a> doc page for a description of what
these parameters mean for each body style.</p>
<p>The only setting currently allowed for the <em>color</em> value is <em>type</em>,
which will color the body particles according to the atom type of the
particle. By default the mapping of types to colors is as follows:</p>
<ul class="simple">
<li>type 1 = red</li>
<li>type 2 = green</li>
<li>type 3 = blue</li>
<li>type 4 = yellow</li>
<li>type 5 = aqua</li>
<li>type 6 = cyan</li>
</ul>
<p>and repeats itself for types > 6. There is not yet an option to
change this via the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command.</p>
<hr class="docutils" />
<p>The <em>fix</em> keyword can be used with a <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> that produces
objects to be drawn. An example is the <span class="xref doc">fix surface/global</span> command which can draw lines
or triangles for 2d/3d simulations.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Aug 2016 - The fix surface/global command is not yet added to
LAMMPS.</p>
</div>
<p>The <em>fflag1</em> and <em>fflag2</em> settings are numerical values which are
passed to the fix to affect how the drawing of its objects is done.
See the individual fix doc page for a description of what these
parameters mean for a particular fix.</p>
<p>The only setting currently allowed for the <em>color</em> value is <em>type</em>,
which will color the fix objects according to their type. By default
the mapping of types to colors is as follows:</p>
<ul class="simple">
<li>type 1 = red</li>
<li>type 2 = green</li>
<li>type 3 = blue</li>
<li>type 4 = yellow</li>
<li>type 5 = aqua</li>
<li>type 6 = cyan</li>
</ul>
<p>and repeats itself for types > 6. There is not yet an option to
change this via the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command.</p>
<hr class="docutils" />
<p>The <em>size</em> keyword sets the width and height of the created images,
i.e. the number of pixels in each direction.</p>
<hr class="docutils" />
<p>The <em>view</em>, <em>center</em>, <em>up</em>, <em>zoom</em>, and <em>persp</em> values determine how
3d simulation space is mapped to the 2d plane of the image. Basically
they control how the simulation box appears in the image.</p>
<p>All of the <em>view</em>, <em>center</em>, <em>up</em>, <em>zoom</em>, and <em>persp</em> values can be
specified as numeric quantities, whose meaning is explained below.
Any of them can also be specified as an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a>, by using v_name as the value, where “name” is
the variable name. In this case the variable will be evaluated on the
timestep each image is created to create a new value. If the
equal-style variable is time-dependent, this is a means of changing
the way the simulation box appears from image to image, effectively
doing a pan or fly-by view of your simulation.</p>
<p>The <em>view</em> keyword determines the viewpoint from which the simulation
box is viewed, looking towards the <em>center</em> point. The <em>theta</em> value
is the vertical angle from the +z axis, and must be an angle from 0 to
180 degrees. The <em>phi</em> value is an azimuthal angle around the z axis
and can be positive or negative. A value of 0.0 is a view along the
+x axis, towards the <em>center</em> point. If <em>theta</em> or <em>phi</em> are
specified via variables, then the variable values should be in
degrees.</p>
<p>The <em>center</em> keyword determines the point in simulation space that
will be at the center of the image. <em>Cx</em>, <em>Cy</em>, and <em>Cz</em> are
speficied as fractions of the box dimensions, so that (0.5,0.5,0.5) is
the center of the simulation box. These values do not have to be
between 0.0 and 1.0, if you want the simulation box to be offset from
the center of the image. Note, however, that if you choose strange
values for <em>Cx</em>, <em>Cy</em>, or <em>Cz</em> you may get a blank image. Internally,
<em>Cx</em>, <em>Cy</em>, and <em>Cz</em> are converted into a point in simulation space.
If <em>flag</em> is set to “s” for static, then this conversion is done once,
at the time the dump command is issued. If <em>flag</em> is set to “d” for
dynamic then the conversion is performed every time a new image is
created. If the box size or shape is changing, this will adjust the
center point in simulation space.</p>
<p>The <em>up</em> keyword determines what direction in simulation space will be
“up” in the image. Internally it is stored as a vector that is in the
plane perpendicular to the view vector implied by the <em>theta</em> and
<em>pni</em> values, and which is also in the plane defined by the view
vector and user-specified up vector. Thus this internal vector is
computed from the user-specified <em>up</em> vector as</p>
<pre class="literal-block">
up_internal = view cross (up cross view)
</pre>
<p>This means the only restriction on the specified <em>up</em> vector is that
it cannot be parallel to the <em>view</em> vector, implied by the <em>theta</em> and
<em>phi</em> values.</p>
<p>The <em>zoom</em> keyword scales the size of the simulation box as it appears
in the image. The default <em>zfactor</em> value of 1 should display an
image mostly filled by the atoms in the simulation box. A <em>zfactor</em> >
1 will make the simulation box larger; a <em>zfactor</em> < 1 will make it
smaller. <em>Zfactor</em> must be a value > 0.0.</p>
<p>The <em>persp</em> keyword determines how much depth perspective is present
in the image. Depth perspective makes lines that are parallel in
simulation space appear non-parallel in the image. A <em>pfactor</em> value
of 0.0 means that parallel lines will meet at infininty (1.0/pfactor),
which is an orthographic rendering with no persepctive. A <em>pfactor</em>
value between 0.0 and 1.0 will introduce more perspective. A <em>pfactor</em>
value > 1 will create a highly skewed image with a large amount of
perspective.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The <em>persp</em> keyword is not yet supported as an option.</p>
</div>
<hr class="docutils" />
<p>The <em>box</em> keyword determines if and how the simulation box boundaries
are rendered as thin cylinders in the image. If <em>no</em> is set, then the
box boundaries are not drawn and the <em>diam</em> setting is ignored. If
<em>yes</em> is set, the 12 edges of the box are drawn, with a diameter that
is a fraction of the shortest box length in x,y,z (for 3d) or x,y (for
2d). The color of the box boundaries can be set with the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify boxcolor</span></a> command.</p>
<p>The <em>axes</em> keyword determines if and how the coordinate axes are
rendered as thin cylinders in the image. If <em>no</em> is set, then the
axes are not drawn and the <em>length</em> and <em>diam</em> settings are ignored.
If <em>yes</em> is set, 3 thin cylinders are drawn to represent the x,y,z
axes in colors red,green,blue. The origin of these cylinders will be
offset from the lower left corner of the box by 10%. The <em>length</em>
setting determines how long the cylinders will be as a fraction of the
respective box lengths. The <em>diam</em> setting determines their thickness
as a fraction of the shortest box length in x,y,z (for 3d) or x,y (for
2d).</p>
<p>The <em>subbox</em> keyword determines if and how processor sub-domain
boundaries are rendered as thin cylinders in the image. If <em>no</em> is
set (default), then the sub-domain boundaries are not drawn and the
<em>diam</em> setting is ignored. If <em>yes</em> is set, the 12 edges of each
processor sub-domain are drawn, with a diameter that is a fraction of
the shortest box length in x,y,z (for 3d) or x,y (for 2d). The color
of the sub-domain boundaries can be set with the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify boxcolor</span></a> command.</p>
<hr class="docutils" />
<p>The <em>shiny</em> keyword determines how shiny the objects rendered in the
image will appear. The <em>sfactor</em> value must be a value 0.0 <=
<em>sfactor</em> <= 1.0, where <em>sfactor</em> = 1 is a highly reflective surface
and <em>sfactor</em> = 0 is a rough non-shiny surface.</p>
<p>The <em>ssao</em> keyword turns on/off a screen space ambient occlusion
(SSAO) model for depth shading. If <em>yes</em> is set, then atoms further
away from the viewer are darkened via a randomized process, which is
perceived as depth. The calculation of this effect can increase the
cost of computing the image by roughly 2x. The strength of the effect
can be scaled by the <em>dfactor</em> parameter. If <em>no</em> is set, no depth
shading is performed.</p>
<hr class="docutils" />
<p>A series of JPEG, PNG, or PPM images can be converted into a movie
file and then played as a movie using commonly available tools. Using
dump style <em>movie</em> automates this step and avoids the intermediate
step of writing (many) image snapshot file. But LAMMPS has to be
compiled with -DLAMMPS_FFMPEG and an FFmpeg executable have to be
installed.</p>
<p>To manually convert JPEG, PNG or PPM files into an animated GIF or
MPEG or other movie file you can use:</p>
<ul class="simple">
<li><ol class="first loweralpha">
<li>Use the ImageMagick convert program.</li>
</ol>
</li>
</ul>
<pre class="literal-block">
% convert *.jpg foo.gif
% convert -loop 1 *.ppm foo.mpg
</pre>
<p>Animated GIF files from ImageMagick are unoptimized. You can use a
program like gifsicle to optimize and massively shrink them.
MPEG files created by ImageMagick are in MPEG-1 format with rather
inefficient compression and low quality.</p>
<ul class="simple">
<li><ol class="first loweralpha" start="2">
<li>Use QuickTime.</li>
</ol>
</li>
</ul>
<p>Select “Open Image Sequence” under the File menu Load the images into
QuickTime to animate them Select “Export” under the File menu Save the
movie as a QuickTime movie (*.mov) or in another format. QuickTime
can generate very high quality and efficiently compressed movie
files. Some of the supported formats require to buy a license and some
are not readable on all platforms until specific runtime libraries are
installed.</p>
<ul class="simple">
<li><ol class="first loweralpha" start="3">
<li>Use FFmpeg</li>
</ol>
</li>
</ul>
<p>FFmpeg is a command line tool that is available on many platforms and
allows extremely flexible encoding and decoding of movies.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>.
<p>Change or adapt one or more specific simulation attributes or settings
over time as a simulation runs. Pair potential and K-space and atom
attributes which can be varied by this fix are discussed below. Many
other fixes can also be used to time-vary simulation parameters,
e.g. the “fix deform” command will change the simulation box
size/shape and the “fix move” command will change atom positions and
velocities in a prescribed manner. Also note that many commands allow
variables as arguments for specific parameters, if described in that
manner on their doc pages. An equal-style variable can calculate a
time-dependent quantity, so this is another way to vary a simulation
parameter over time.</p>
<p>If <em>N</em> is specified as 0, the specified attributes are only changed
once, before the simulation begins. This is all that is needed if the
associated variables are not time-dependent. If <em>N</em> > 0, then changes
are made every <em>N</em> steps during the simulation, presumably with a
variable that is time-dependent.</p>
<p>Depending on the value of the <em>reset</em> keyword, attributes changed by
this fix will or will not be reset back to their original values at
the end of a simulation. Even if <em>reset</em> is specified as <em>yes</em>, a
restart file written during a simulation will contain the modified
settings.</p>
<p>If the <em>scale</em> keyword is set to <em>no</em>, then the value the parameter is
set to will be whatever the variable generates. If the <em>scale</em>
keyword is set to <em>yes</em>, then the value of the altered parameter will
be the initial value of that parameter multiplied by whatever the
variable generates. I.e. the variable is now a “scale factor” applied
in (presumably) a time-varying fashion to the parameter.</p>
<p>Note that whether scale is <em>no</em> or <em>yes</em>, internally, the parameters
themselves are actually altered by this fix. Make sure you use the
<em>reset yes</em> option if you want the parameters to be restored to their
initial values after the run.</p>
<hr class="docutils" />
<p>The <em>pair</em> keyword enables various parameters of potentials defined by
the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> command to be changed, if the pair
style supports it. Note that the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> and
<a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> commands must be used in the usual manner
to specify these parameters initially; the fix adapt command simply
overrides the parameters.</p>
<p>The <em>pstyle</em> argument is the name of the pair style. If <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid or hybrid/overlay</span></a> is used, <em>pstyle</em> should be
a sub-style name. If there are multiple sub-styles using the same
pair style, then <em>pstyle</em> should be specified as “style:N” where N is
which instance of the pair style you wish to adapt, e.g. the first,
second, etc. For example, <em>pstyle</em> could be specified as “soft” or
“lubricate” or “lj/cut:1” or “lj/cut:2”. The <em>pparam</em> argument is the
name of the parameter to change. This is the current list of pair
styles and parameters that can be varied by this fix. See the doc
pages for individual pair styles and their energy formulas for the
<p class="last">It is easy to add new potentials and their parameters to this
list. All it typically takes is adding an extract() method to the
pair_*.cpp file associated with the potential.</p>
</div>
<p>Some parameters are global settings for the pair style, e.g. the
viscosity setting “mu” for <a class="reference internal" href="pair_lubricate.html"><span class="doc">pair_style lubricate</span></a>.
For <a class="reference internal" href="pair_kim.html"><span class="doc">pair_kim</span></a>, all free parameters supported by the
KIM Model are available (e.g., PARAM_FREE_sigmas provided by the
LennardJones612_Universal__MO_826355984548_001 Model). If the free
parameter corresponds to an array, then the particular array element
to be adapted must be specified (e.g., “PARAM_FREE_sigmas:10”, to
adapt the tenth entry of the sigmas array).
Other parameters apply to atom type pairs within the pair style,
e.g. the prefactor “a” for <a class="reference internal" href="pair_soft.html"><span class="doc">pair_style soft</span></a>.</p>
<p>Note that for many of the potentials, the parameter that can be varied
is effectively a prefactor on the entire energy expression for the
potential, e.g. the lj/cut epsilon. The parameters listed as “scale”
are exactly that, since the energy expression for the
<a class="reference internal" href="pair_coul.html"><span class="doc">coul/cut</span></a> potential (for example) has no labeled
prefactor in its formula. To apply an effective prefactor to some
potentials, multiple parameters need to be altered. For example, the
<a class="reference internal" href="pair_buck.html"><span class="doc">Buckingham potential</span></a> needs both the A and C terms
altered together. To scale the Buckingham potential, you should thus
list the pair style twice, once for A and once for C.</p>
<p>If a type pair parameter is specified, the <em>I</em> and <em>J</em> settings should
be specified to indicate which type pairs to apply it to. If a global
parameter is specified, the <em>I</em> and <em>J</em> settings still need to be
specified, but are ignored.</p>
<p>Similar to the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff command</span></a>, I and J can be
specified in one of two ways. Explicit numeric values can be used for
each, as in the 1st example above. I <= J is required. LAMMPS sets
the coefficients for the symmetric J,I interaction to the same values.</p>
<p>A wild-card asterisk can be used in place of or in conjunction with
the I,J arguments to set the coefficients for multiple pairs of atom
-types. This takes the form “*” or “<em>n” or “n</em>” or “m*n”. If N = the
+types. This takes the form “*” or “*n” or “n*” or “m*n”. If N = the
number of atom types, then an asterisk with no numeric values means
all types from 1 to N. A leading asterisk means all types from 1 to n
(inclusive). A trailing asterisk means all types from n to N
(inclusive). A middle asterisk means all types from m to n
(inclusive). Note that only type pairs with I <= J are considered; if
asterisks imply type pairs where J < I, they are ignored.</p>
<p>IMPROTANT NOTE: If <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid or hybrid/overlay</span></a> is being used, then the <em>pstyle</em> will
be a sub-style name. You must specify I,J arguments that correspond
to type pair values defined (via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a>
command) for that sub-style.</p>
<p>The <em>v_name</em> argument for keyword <em>pair</em> is the name of an
<a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> which will be evaluated each time
this fix is invoked to set the parameter to a new value. It should be
specified as v_name, where name is the variable name. Equal-style
variables can specify formulas with various mathematical functions,
and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command keywords for the
simulation box parameters and timestep and elapsed time. Thus it is
easy to specify parameters that change as a function of time or span
consecutive runs in a continuous fashion. For the latter, see the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command and the
<em>elaplong</em> keyword of <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> for
details.</p>
<p>For example, these commands would change the prefactor coefficient of
the <a class="reference internal" href="pair_soft.html"><span class="doc">pair_style soft</span></a> potential from 10.0 to 30.0 in a
linear fashion over the course of a simulation:</p>
<p>The <em>kspace</em> keyword used the specified variable as a scale factor on
the energy, forces, virial calculated by whatever K-Space solver is
defined by the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command. If the
variable has a value of 1.0, then the solver is unaltered.</p>
<p>The <em>kspace</em> keyword works this way whether the <em>scale</em> keyword
is set to <em>no</em> or <em>yes</em>.</p>
<hr class="docutils" />
<p>The <em>atom</em> keyword enables various atom properties to be changed. The
<em>aparam</em> argument is the name of the parameter to change. This is the
current list of atom parameters that can be varied by this fix:</p>
<ul class="simple">
<li>charge = charge on particle</li>
<li>diameter = diameter of particle</li>
</ul>
<p>The <em>v_name</em> argument of the <em>atom</em> keyword is the name of an
<a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> which will be evaluated each time
this fix is invoked to set the parameter to a new value. It should be
specified as v_name, where name is the variable name. See the
discussion above describing the formulas associated with equal-style
variables. The new value is assigned to the corresponding attribute
for all atoms in the fix group.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The <em>atom</em> keyword works this way whether the <em>scale</em> keyword is
set to <em>no</em> or <em>yes</em>. I.e. the use of scale yes is not yet supported
by the <em>atom</em> keyword.</p>
</div>
<p>If the atom parameter is <em>diameter</em> and per-atom density and per-atom
mass are defined for particles (e.g. <a class="reference internal" href="atom_style.html"><span class="doc">atom_style granular</span></a>), then the mass of each particle is also
changed when the diameter changes (density is assumed to stay
constant).</p>
<p>For example, these commands would shrink the diameter of all granular
particles in the “center” group from 1.0 to 0.1 in a linear fashion
-<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.
This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
<p>For <a class="reference internal" href="run_style.html"><span class="doc">rRESPA time integration</span></a>, this fix changes
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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
+<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
+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
+<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
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
function of time will change as</p>
<pre class="literal-block">
L(t) = L0 (1 + erate*dt)
</pre>
<p>where dt is the elapsed time (in time units). Thus if <em>erate</em> R is
specified as 0.1 and time units are picoseconds, this means the box
length will increase by 10% of its original length every picosecond.
I.e. strain after 1 psec = 0.1, strain after 2 psec = 0.2, etc. R =
-0.01 means the box length will shrink by 1% of its original length
every picosecond. Note that for an “engineering” rate the change is
based on the original box length, so running with R = 1 for 10
picoseconds expands the box length by a factor of 11 (strain of 10),
which is different that what the <em>trate</em> style would induce.</p>
<p>The <em>trate</em> style changes a dimension of the box at a “constant true
strain rate”. Note that this is not an “engineering strain rate”, as
the other styles are. Rather, for a “true” rate, the rate of change
is constant, which means the box dimension changes non-linearly with
time from its initial to final value. 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.</p>
<p>The box length L as a function of time will change as</p>
<pre class="literal-block">
L(t) = L0 exp(trate*dt)
</pre>
<p>where dt is the elapsed time (in time units). Thus if <em>trate</em> R is
specified as ln(1.1) and time units are picoseconds, this means the
box length will increase by 10% of its current (not original) length
every picosecond. I.e. strain after 1 psec = 0.1, strain after 2 psec
= 0.21, etc. R = ln(2) or ln(3) means the box length will double or
triple every picosecond. R = ln(0.99) means the box length will
shrink by 1% of its current length every picosecond. Note that for a
“true” rate the change is continuous and based on the current length,
so running with R = ln(2) for 10 picoseconds does not expand the box
length by a factor of 11 as it would with <em>erate</em>, but by a factor of
1024 since the box length will double every picosecond.</p>
<p>Note that to change the volume (or cross-sectional area) of the
simulation box at a constant rate, you can change multiple dimensions
via <em>erate</em> or <em>trate</em>. E.g. to double the box volume in a picosecond
picosecond, you could set “x erate M”, “y erate M”, “z erate M”, with
M = pow(2,1/3) - 1 = 0.26, since if each box dimension grows by 26%,
the box volume doubles. Or you could set “x trate M”, “y trate M”, “z
trate M”, with M = ln(1.26) = 0.231, and the box volume would double
every picosecond.</p>
<p>The <em>volume</em> style changes the specified dimension in such a way that
the box volume remains constant while other box dimensions are changed
explicitly via the styles discussed above. For example, “x scale 1.1
y scale 1.1 z volume” will shrink the z box length as the x,y box
lengths increase, to keep the volume constant (product of x,y,z
lengths). If “x scale 1.1 z volume” is specified and parameter <em>y</em> is
unspecified, then the z box length will shrink as x increases to keep
the product of x,z lengths constant. If “x scale 1.1 y volume z
volume” is specified, then both the y,z box lengths will shrink as x
increases to keep the volume constant (product of x,y,z lengths). In
this case, the y,z box lengths shrink so as to keep their relative
aspect ratio constant.</p>
<p>For solids or liquids, note that when one dimension of the box is
expanded via fix deform (i.e. tensile strain), it may be physically
undesirable to hold the other 2 box lengths constant (unspecified by
fix deform) since that implies a density change. Using the <em>volume</em>
style for those 2 dimensions to keep the box volume constant may make
more physical sense, but may also not be correct for materials and
potentials whose Poisson ratio is not 0.5. An alternative is to use
<a class="reference internal" href="fix_nh.html"><span class="doc">fix npt aniso</span></a> with zero applied pressure on those 2
dimensions, so that they respond to the tensile strain dynamically.</p>
<p>The <em>wiggle</em> style oscillates the specified box length dimension
sinusoidally with the specified amplitude and period. I.e. the box
length L as a function of time is given by</p>
<pre class="literal-block">
L(t) = L0 + A sin(2*pi t/Tp)
</pre>
<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
fix 2 all deform 1 x variable v_displace v_rate remap v
</pre>
<p>For the <em>scale</em>, <em>vel</em>, <em>erate</em>, <em>trate</em>, <em>volume</em>, <em>wiggle</em>, and
<em>variable</em> styles, the box length is expanded or compressed around its
mid point.</p>
<hr class="docutils" />
<p>For the <em>xy</em>, <em>xz</em>, and <em>yz</em> parameters, this is the meaning of their
styles and values. Note that changing the tilt factors of a triclinic
box does not change its volume.</p>
<p>The <em>final</em>, <em>delta</em>, <em>vel</em>, and <em>erate</em> styles all change the shear
strain at a “constant engineering shear strain rate”. This means the
tilt factor changes linearly with time from its initial to final
value.</p>
<p>For style <em>final</em>, the final tilt factor is specified. The value
can be in lattice or box distance units. See the discussion of the
units keyword below.</p>
<p>For style <em>delta</em>, a plus or minus change in the tilt factor is
specified. The value can be in lattice or box distance units. See
the discussion of the units keyword below.</p>
<p>For style <em>vel</em>, a velocity at which the tilt factor changes is
specified in units of distance/time. This is effectively an
“engineering shear strain rate”, where rate = V/L0 and L0 is the
initial box length perpendicular to the direction of shear. The
distance can be in lattice or box distance units. See the discussion
of the units keyword below. For example, if the initial tilt factor
is 5 Angstroms, and the V is 10 Angstroms/psec, then after 1 psec, the
tilt factor will be 15 Angstroms. After 2 psec, it will be 25
Angstroms.</p>
<p>The <em>erate</em> style changes a tilt factor at a “constant engineering
shear strain rate”. The units of the specified shear 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). Shear strain is unitless and is
defined as offset/length, where length is the box length perpendicular
to the shear direction (e.g. y box length for xy deformation) and
offset is the displacement distance in the shear direction (e.g. x
direction for xy deformation) from the unstrained orientation.</p>
<p>The tilt factor T as a function of time will change as</p>
<pre class="literal-block">
T(t) = T0 + L0*erate*dt
</pre>
<p>where T0 is the initial tilt factor, L0 is the original length of the
box perpendicular to the shear direction (e.g. y box length for xy
deformation), and dt is the elapsed time (in time units). Thus if
<em>erate</em> R is specified as 0.1 and time units are picoseconds, this
means the shear strain will increase by 0.1 every picosecond. I.e. if
the xy shear strain was initially 0.0, then strain after 1 psec = 0.1,
strain after 2 psec = 0.2, etc. Thus the tilt factor would be 0.0 at
time 0, 0.1*ybox at 1 psec, 0.2*ybox at 2 psec, etc, where ybox is the
original y box length. R = 1 or 2 means the tilt factor will increase
by 1 or 2 every picosecond. R = -0.01 means a decrease in shear
strain by 0.01 every picosecond.</p>
<p>The <em>trate</em> style changes a tilt factor at a “constant true shear
strain rate”. Note that this is not an “engineering shear strain
rate”, as the other styles are. Rather, for a “true” rate, the rate
of change is constant, which means the tilt factor changes
non-linearly with time from its initial to final value. The units of
the specified shear 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). Shear strain is unitless and is defined as offset/length,
where length is the box length perpendicular to the shear direction
(e.g. y box length for xy deformation) and offset is the displacement
distance in the shear direction (e.g. x direction for xy deformation)
from the unstrained orientation.</p>
<p>The tilt factor T as a function of time will change as</p>
<pre class="literal-block">
T(t) = T0 exp(trate*dt)
</pre>
<p>where T0 is the initial tilt factor and dt is the elapsed time (in
time units). Thus if <em>trate</em> R is specified as ln(1.1) and time units
are picoseconds, this means the shear strain or tilt factor will
increase by 10% every picosecond. I.e. if the xy shear strain was
initially 0.1, then strain after 1 psec = 0.11, strain after 2 psec =
0.121, etc. R = ln(2) or ln(3) means the tilt factor will double or
triple every picosecond. R = ln(0.99) means the tilt factor will
shrink by 1% every picosecond. Note that the change is continuous, so
running with R = ln(2) for 10 picoseconds does not change the tilt
factor by a factor of 10, but by a factor of 1024 since it doubles
every picosecond. Note that the initial tilt factor must be non-zero
to use the <em>trate</em> option.</p>
<p>Note that shear strain is defined as the tilt factor divided by the
perpendicular box length. The <em>erate</em> and <em>trate</em> styles control the
tilt factor, but assume the perpendicular box length remains constant.
If this is not the case (e.g. it changes due to another fix deform
parameter), then this effect on the shear strain is ignored.</p>
<p>The <em>wiggle</em> style oscillates the specified tilt factor sinusoidally
with the specified amplitude and period. I.e. the tilt factor T as a
function of time is given by</p>
<pre class="literal-block">
T(t) = T0 + A sin(2*pi t/Tp)
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<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>.
-<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>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
+<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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 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
+<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<li>ID, group are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>gravity = style name of this fix command</li>
<li>magnitude = size of acceleration (force/mass units)</li>
<li>magnitude can be a variable (see below)</li>
<li>style = <em>chute</em> or <em>spherical</em> or <em>gradient</em> or <em>vector</em></li>
</ul>
<pre class="literal-block">
<em>chute</em> args = angle
angle = angle in +x away from -z or -y axis in 3d/2d (in degrees)
angle can be a variable (see below)
<em>spherical</em> args = phi theta
phi = azimuthal angle from +x axis (in degrees)
theta = angle from +z or +y axis in 3d/2d (in degrees)
phi or theta can be a variable (see below)
<em>vector</em> args = x y z
x y z = vector direction to apply the acceleration
x or y or z can be a variable (see below)
</pre>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
fix 1 all gravity 1.0 chute 24.0
fix 1 all gravity v_increase chute 24.0
fix 1 all gravity 1.0 spherical 0.0 -180.0
fix 1 all gravity 10.0 spherical v_phi v_theta
fix 1 all gravity 100.0 vector 1 1 0
</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<hr class="docutils" />
<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>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>.
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<hr class="docutils" />
<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>.
<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>The inter-replica forces for the other replicas are unchanged from the
first equation.</p>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<hr class="docutils" />
<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>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>Perform constant NPH integration to update position, velocity,
orientation, and angular velocity each timestep for aspherical or
ellipsoidal particles in the group using a Nose/Hoover pressure
barostat. P is pressure; H is enthalpy. This creates a system
trajectory consistent with the isenthalpic ensemble.</p>
<p>This fix differs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> command, which assumes
point particles and only updates their position and velocity.</p>
<p>Additional parameters affecting the barostat are specified by keywords
and values documented with the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> command. See,
for example, discussion of the <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
NPH 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>
<pre class="literal-block">
compute fix-ID_temp all temp/asphere
compute fix-ID_press all pressure fix-ID_temp
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>Perform constant NPH integration to update position, velocity, and
angular velocity each timestep for finite-size spherical particles in
the group using a Nose/Hoover pressure barostat. P is pressure; H is
enthalpy. This creates a system trajectory consistent with the
isenthalpic ensemble.</p>
<p>This fix differs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> command, which assumes
point particles and only updates their position and velocity.</p>
<p>Additional parameters affecting the barostat are specified by keywords
and values documented with the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> command. See,
for example, discussion of the <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
NPH 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>
<pre class="literal-block">
compute fix-ID_temp all temp/sphere
compute fix-ID_press all pressure fix-ID_temp
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<hr class="docutils" />
<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the values of E0, V0, and P0, as well as 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>
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 *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>
<pre class="literal-block">
compute fix-ID_temp all temp/asphere
compute fix-ID_press all pressure fix-ID_temp
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the state of the Nose/Hoover thermostat and 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 thermostatting and
barostatting to the system’s potential energy as part of
<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>
<pre class="literal-block">
compute fix-ID_temp all temp/body
compute fix-ID_press all pressure fix-ID_temp
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the state of the Nose/Hoover thermostat and 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 thermostatting and
barostatting to the system’s potential energy as part of
<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>
<pre class="literal-block">
compute fix-ID_temp all temp/sphere
compute fix-ID_press all pressure fix-ID_temp
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>This fix writes the state of the Nose/Hoover thermostat and 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 thermostatting and
barostatting to the system’s potential energy as 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>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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<p>Perform constant NVE integration to update position, velocity,
orientation, and angular velocity for aspherical 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><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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<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>.
<p>Perform constant NVE integration to update position, velocity,
orientation, and angular velocity for line segment 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"><span class="doc">Section_howto 14</span></a> of the manual for an overview of
-using line segment particles.</p>
+<a class="reference internal" href="Section_howto.html#howto-14"><span class="std std-ref">Section 6.14</span></a> of the manual for an
+overview of using line segment 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>
<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="#paquay"><span class="std std-ref">(Paquay)</span></a>. V is volume; E is energy. This way,
+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>
<pre class="literal-block">
variable R equal "ramp(5.0,3.0)"
fix shrink_sphere all nve/manifold/rattle 1e-4 10 sphere v_R
</pre>
<p>In this case, the manifold parameter will change in time according to
the variable. This is not a problem for the time integrator as long
as the change of the manifold is slow with respect to the dynamics of
the particles. Note that if the manifold has to exert work on the
particles because of these changes, the total energy might not be
conserved.</p>
<hr class="docutils" />
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<hr class="docutils" />
<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>.
<p>Perform constant NVE integration to update position, velocity,
orientation, and angular momentum for triangular 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"><span class="doc">Section_howto 14</span></a> of the manual for an overview of
-using triangular particles.</p>
+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 6.14</span></a> of the manual for an
+overview of using triangular 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>
<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>Perform constant NVT 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. V is volume; T is temperature. This creates a system
trajectory consistent with the canonical ensemble.</p>
<p>This fix differs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</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 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/asphere”, as if this command
had been issued:</p>
<pre class="literal-block">
compute fix-ID_temp group-ID temp/asphere
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<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>Perform constant NVT integration to update position, velocity,
orientation, and angular velocity each timestep for body
particles 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 fix differs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</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 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/body”, as if this command
had been issued:</p>
<pre class="literal-block">
compute fix-ID_temp group-ID temp/body
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<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
been issued:</p>
<pre class="literal-block">
compute fix-ID_temp group-ID temp/deform
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<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/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>Perform constant NVT integration to update position, velocity, and
angular velocity each timestep for finite-size spherical particles 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 fix differs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</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 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/sphere”, as if this command
had been issued:</p>
<pre class="literal-block">
compute fix-ID_temp group-ID temp/sphere
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<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>. 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>.
<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>.
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<hr class="docutils" />
<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
<p>where <em>itype</em> is the atom type from 1 to Ntypes, <em>chi</em> denotes the
electronegativity in eV, <em>eta</em> denotes the self-Coulomb
potential in eV, and <em>gamma</em> denotes the valence orbital
exponent. Note that these 3 quantities are also in the ReaxFF
potential file, except that eta is defined here as twice the eta value
in the ReaxFF file. Note that unlike the rest of LAMMPS, the units
of this fix are hard-coded to be A, eV, and electronic charge.</p>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<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>style = <em>rigid</em> or <em>rigid/nve</em> or <em>rigid/nvt</em> or <em>rigid/npt</em> or <em>rigid/nph</em> or <em>rigid/small</em> or <em>rigid/nve/small</em> or <em>rigid/nvt/small</em> or <em>rigid/npt/small</em> or <em>rigid/nph/small</em></li>
<li>bodystyle = <em>single</em> or <em>molecule</em> or <em>group</em></li>
</ul>
<pre class="literal-block">
<em>single</em> args = none
<em>molecule</em> args = none
<em>group</em> args = N groupID1 groupID2 ...
N = # of groups
groupID1, groupID2, ... = list of N group IDs
</pre>
<ul class="simple">
<li>zero or more keyword/value pairs may be appended</li>
<li>keyword = <em>langevin</em> or <em>temp</em> or <em>iso</em> or <em>aniso</em> or <em>x</em> or <em>y</em> or <em>z</em> or <em>couple</em> or <em>tparam</em> or <em>pchain</em> or <em>dilate</em> or <em>force</em> or <em>torque</em> or <em>infile</em></li>
Tstart,Tstop = desired temperature at start/stop of run (temperature units)
Tdamp = temperature damping parameter (time units)
seed = random number seed to use for white noise (positive integer)
<em>temp</em> values = Tstart Tstop Tdamp
Tstart,Tstop = desired temperature at start/stop of run (temperature units)
Tdamp = temperature damping parameter (time units)
<em>iso</em> or <em>aniso</em> values = Pstart Pstop Pdamp
Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
Pdamp = pressure damping parameter (time units)
<em>x</em> or <em>y</em> or <em>z</em> values = Pstart Pstop Pdamp
Pstart,Pstop = external stress tensor component at start/end of run (pressure units)
Pdamp = stress damping parameter (time units)
<em>couple</em> = <em>none</em> or <em>xyz</em> or <em>xy</em> or <em>yz</em> or <em>xz</em>
<em>tparam</em> values = Tchain Titer Torder
Tchain = length of Nose/Hoover thermostat chain
Titer = number of thermostat iterations performed
Torder = 3 or 5 = Yoshida-Suzuki integration parameters
<em>pchain</em> values = Pchain
Pchain = length of the Nose/Hoover thermostat chain coupled with the barostat
<em>dilate</em> value = dilate-group-ID
dilate-group-ID = only dilate atoms in this group due to barostat volume changes
<em>force</em> values = M xflag yflag zflag
M = which rigid body from 1-Nbody (see asterisk form below)
xflag,yflag,zflag = off/on if component of center-of-mass force is active
<em>torque</em> values = M xflag yflag zflag
M = which rigid body from 1-Nbody (see asterisk form below)
xflag,yflag,zflag = off/on if component of center-of-mass torque is active
<em>infile</em> filename
filename = file with per-body values of mass, center-of-mass, moments of inertia
<em>mol</em> value = template-ID
template-ID = ID of molecule template specified in a separate <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command
</pre>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
fix 1 clump rigid single
fix 1 clump rigid/small molecule
fix 1 clump rigid single force 1 off off on langevin 1.0 1.0 1.0 428984
<p>Treat one or more sets of atoms as independent rigid bodies. This
means that each timestep the total force and torque on each rigid body
is computed as the sum of the forces and torques on its constituent
particles. The coordinates, velocities, and orientations of the atoms
in each body are then updated so that the body moves and rotates as a
single entity.</p>
<p>Examples of large rigid bodies are a colloidal particle, or portions
of a biomolecule such as a protein.</p>
<p>Example of small rigid bodies are patchy nanoparticles, such as those
modeled in <a class="reference internal" href="pair_gran.html#zhang"><span class="std std-ref">this paper</span></a> by Sharon Glotzer’s group, clumps of
granular particles, lipid molecules consiting of one or more point
dipoles connected to other spheroids or ellipsoids, irregular
particles built from line segments (2d) or triangles (3d), and
coarse-grain models of nano or colloidal particles consisting of a
small number of constituent particles. Note that the <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command can also be used to rigidify small
molecules of 2, 3, or 4 atoms, e.g. water molecules. That fix treats
the constituent atoms as point masses.</p>
<p>These fixes also update the positions and velocities of the atoms in
each rigid body via time integration, in the NVE, NVT, NPT, or NPH
ensemble, as described below.</p>
<p>There are two main variants of this fix, fix rigid and fix
rigid/small. The NVE/NVT/NPT/NHT versions belong to one of the two
variants, as their style names indicate.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Not all of the <em>bodystyle</em> options and keyword/value options are
available for both the <em>rigid</em> and <em>rigid/small</em> variants. See
details below.</p>
</div>
<p>The <em>rigid</em> styles are typically the best choice for a system with a
small number of large rigid bodies, each of which can extend across
the domain of many processors. It operates by creating a single
global list of rigid bodies, which all processors contribute to.
MPI_Allreduce operations are performed each timestep to sum the
contributions from each processor to the force and torque on all the
bodies. This operation will not scale well in parallel if large
numbers of rigid bodies are simulated.</p>
<p>The <em>rigid/small</em> styles are typically best for a system with a large
number of small rigid bodies. Each body is assigned to the atom
closest to the geometrical center of the body. The fix operates using
local lists of rigid bodies owned by each processor and information is
exchanged and summed via local communication between neighboring
processors when ghost atom info is accumlated.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">To use the <em>rigid/small</em> styles the ghost atom cutoff must be
large enough to span the distance between the atom that owns the body
and every other atom in the body. This distance value is printed out
when the rigid bodies are defined. If the
<a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> cutoff plus neighbor skin does not span
this distance, then you should use the <a class="reference internal" href="comm_modify.html"><span class="doc">comm_modify cutoff</span></a> command with a setting epsilon larger than
the distance.</p>
</div>
<p>Which of the two variants is faster for a particular problem is hard
to predict. The best way to decide is to perform a short test run.
Both variants should give identical numerical answers for short runs.
Long runs should give statistically similar results, but round-off
differences may accumulate to produce divergent trajectories.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">You should not update the atoms in rigid bodies via other
time-integration fixes (e.g. <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a>, <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>, <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a>), or you will be integrating
their motion more than once each timestep. When performing a hybrid
simulation with some atoms in rigid bodies, and some not, a separate
time integration fix like <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> or <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> should be used for the non-rigid particles.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">These fixes are overkill if you simply want to hold a collection
of atoms stationary or have them move with a constant velocity. A
simpler way to hold atoms stationary is to not include those atoms in
your time integration fix. E.g. use “fix 1 mobile nve” instead of
“fix 1 all nve”, where “mobile” is the group of atoms that you want to
move. You can move atoms with a constant velocity by assigning them
an initial velocity (via the <a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> command),
setting the force on them to 0.0 (via the <a class="reference internal" href="fix_setforce.html"><span class="doc">fix setforce</span></a> command), and integrating them as usual
(e.g. via the <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> command).</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The aggregate properties of each rigid body are calculated one
time at the start of the first simulation run after these fixes are
specified. The properties include the position and velocity of the
center-of-mass of the body, its moments of inertia, and its angular
momentum. This is done using the properties of the constituent atoms
of the body at that point in time (or see the <em>infile</em> keyword
option). Thereafter, changing properties of individual atoms in the
body will have no effect on a rigid body’s dynamics, unless they
affect the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> interactions that individual
particles are part of. For example, you might think you could
displace the atoms in a body or add a large velocity to each atom in a
body to make it move in a desired direction before a 2nd run is
performed, using the <a class="reference internal" href="set.html"><span class="doc">set</span></a> or
command. But these commands will not affect the internal attributes
of the body, and the position and velocity of individual atoms in the
body will be reset when time integration starts.</p>
</div>
<hr class="docutils" />
<p>Each rigid body must have two or more atoms. An atom can belong to at
most one rigid body. Which atoms are in which bodies can be defined
via several options.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">With the <em>rigid/small</em> styles, which require that <em>bodystyle</em> be
specified as <em>molecule</em>, you can define a system that has no rigid
bodies initially. This is useful when you are using the <em>mol</em> keyword
in conjunction with another fix that is adding rigid bodies on-the-fly
as molecules, such as <a class="reference internal" href="fix_deposit.html"><span class="doc">fix deposit</span></a> or <a class="reference internal" href="fix_pour.html"><span class="doc">fix pour</span></a>.</p>
</div>
<p>For bodystyle <em>single</em> the entire fix group of atoms is treated as one
rigid body. This option is only allowed for the <em>rigid</em> styles.</p>
<p>For bodystyle <em>molecule</em>, each set of atoms in the fix group with a
different molecule ID is treated as a rigid body. This option is
allowed for both the <em>rigid</em> and <em>rigid/small</em> styles. Note that
atoms with a molecule ID = 0 will be treated as a single rigid body.
For a system with atomic solvent (typically this is atoms with
molecule ID = 0) surrounding rigid bodies, this may not be what you
want. Thus you should be careful to use a fix group that only
includes atoms you want to be part of rigid bodies.</p>
<p>For bodystyle <em>group</em>, each of the listed groups is treated as a
separate rigid body. Only atoms that are also in the fix group are
included in each rigid body. This option is only allowed for the
<em>rigid</em> styles.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">To compute the initial center-of-mass position and other
properties of each rigid body, the image flags for each atom in the
body are used to “unwrap” the atom coordinates. Thus you must insure
that these image flags are consistent so that the unwrapping creates a
valid rigid body (one where the atoms are close together),
particularly if the atoms in a single rigid body straddle a periodic
boundary. This means the input data file or restart file must define
the image flags for each atom consistently or that you have used the
<a class="reference internal" href="set.html"><span class="doc">set</span></a> command to specify them correctly. If a dimension is
non-periodic then the image flag of each atom must be 0 in that
dimension, else an error is generated.</p>
</div>
<p>The <em>force</em> and <em>torque</em> keywords discussed next are only allowed for
the <em>rigid</em> styles.</p>
<p>By default, each rigid body is acted on by other atoms which induce an
external force and torque on its center of mass, causing it to
translate and rotate. Components of the external center-of-mass force
and torque can be turned off by the <em>force</em> and <em>torque</em> keywords.
This may be useful if you wish a body to rotate but not translate, or
vice versa, or if you wish it to rotate or translate continuously
unaffected by interactions with other particles. Note that if you
expect a rigid body not to move or rotate by using these keywords, you
must insure its initial center-of-mass translational or angular
velocity is 0.0. Otherwise the initial translational or angular
momentum the body has will persist.</p>
<p>An xflag, yflag, or zflag set to <em>off</em> means turn off the component of
force of torque in that dimension. A setting of <em>on</em> means turn on
the component, which is the default. Which rigid body(s) the settings
apply to is determined by the first argument of the <em>force</em> and
<em>torque</em> keywords. It can be an integer M from 1 to Nbody, where
Nbody is the number of rigid bodies defined. A wild-card asterisk can
be used in place of, or in conjunction with, the M argument to set the
flags for multiple rigid bodies. This takes the form “*” or “*n” or
“n*” or “m*n”. If N = the number of rigid bodies, then an asterisk
with no numeric values means all bodies from 1 to N. A leading
asterisk means all bodies from 1 to n (inclusive). A trailing
asterisk means all bodies from n to N (inclusive). A middle asterisk
means all types from m to n (inclusive). Note that you can use the
<em>force</em> or <em>torque</em> keywords as many times as you like. If a
particular rigid body has its component flags set multiple times, the
settings from the final keyword are used.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For computational efficiency, you may wish to turn off pairwise
and bond interactions within each rigid body, as they no longer
contribute to the motion. The <a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify exclude</span></a> and <a class="reference internal" href="delete_bonds.html"><span class="doc">delete_bonds</span></a>
commands are used to do this. If the rigid bodies have strongly
overalapping atoms, you may need to turn off these interactions to
avoid numerical problems due to large equal/opposite intra-body forces
swamping the contribution of small inter-body forces.</p>
</div>
<p>For computational efficiency, you should typically define one fix
rigid or fix rigid/small command which includes all the desired rigid
bodies. LAMMPS will allow multiple rigid fixes to be defined, but it
is more expensive.</p>
<hr class="docutils" />
<p>The constituent particles within a rigid body can be point particles
(the default in LAMMPS) or finite-size particles, such as spheres or
ellipsoids or line segments or triangles. See the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style sphere and ellipsoid and line and tri</span></a> commands for more
details on these kinds of particles. Finite-size particles contribute
differently to the moment of inertia of a rigid body than do point
particles. Finite-size particles can also experience torque (e.g. due
to <a class="reference internal" href="pair_gran.html"><span class="doc">frictional granular interactions</span></a>) and have an
orientation. These contributions are accounted for by these fixes.</p>
<p>Forces between particles within a body do not contribute to the
external force or torque on the body. Thus for computational
efficiency, you may wish to turn off pairwise and bond interactions
between particles within each rigid body. The <a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify exclude</span></a> and <a class="reference internal" href="delete_bonds.html"><span class="doc">delete_bonds</span></a>
commands are used to do this. For finite-size particles this also
means the particles can be highly overlapped when creating the rigid
body.</p>
<hr class="docutils" />
<p>The <em>rigid</em>, <em>rigid/nve</em>, <em>rigid/small</em>, and <em>rigid/small/nve</em> styles
perform constant NVE time integration. They are referred to below as
the 4 NVE rigid styles. The only difference is that the <em>rigid</em> and
<em>rigid/small</em> styles use an integration technique based on Richardson
iterations. The <em>rigid/nve</em> and <em>rigid/small/nve</em> styles uses the
methods described in the paper by <a class="reference internal" href="#miller"><span class="std std-ref">Miller</span></a>, which are thought
to provide better energy conservation than an iterative approach.</p>
<p>The <em>rigid/nvt</em> and <em>rigid/nvt/small</em> styles performs constant NVT
integration using a Nose/Hoover thermostat with chains as described
originally in <a class="reference internal" href="#hoover"><span class="std std-ref">(Hoover)</span></a> and <a class="reference internal" href="#martyna"><span class="std std-ref">(Martyna)</span></a>, which
thermostats both the translational and rotational degrees of freedom
of the rigid bodies. They are referred to below as the 2 NVT rigid
styles. The rigid-body algorithm used by <em>rigid/nvt</em> is described in
the paper by <a class="reference internal" href="#kamberaj"><span class="std std-ref">Kamberaj</span></a>.</p>
<p>The <em>rigid/npt</em>, <em>rigid/nph</em>, <em>rigid/npt/small</em>, and <em>rigid/nph/small</em>
styles perform constant NPT or NPH integration using a Nose/Hoover
barostat with chains. They are referred to below as the 4 NPT and NPH
rigid styles. For the NPT case, the same Nose/Hoover thermostat is
also used as with <em>rigid/nvt</em> and <em>rigid/nvt/small</em>.</p>
<p>The barostat parameters are specified using one or more of the <em>iso</em>,
<em>aniso</em>, <em>x</em>, <em>y</em>, <em>z</em> and <em>couple</em> keywords. These keywords give you
the ability to specify 3 diagonal components of the external stress
tensor, and to couple these components together so that the dimensions
they represent are varied together during a constant-pressure
simulation. The effects of these keywords are similar to those
defined in <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt/nph</span></a></p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Currently the <em>rigid/npt</em>, <em>rigid/nph</em>, <em>rigid/npt/small</em>, and
<em>rigid/nph/small</em> styles do not support triclinic (non-orthongonal)
boxes.</p>
</div>
<p>The target pressures for each of the 6 components of the stress tensor
can be specified independently via the <em>x</em>, <em>y</em>, <em>z</em> keywords, which
correspond to the 3 simulation box dimensions. For each component,
the external pressure or tensor component at each timestep is a ramped
value during the run from <em>Pstart</em> to <em>Pstop</em>. If a target pressure is
specified for a component, then the corresponding box dimension will
change during a simulation. For example, if the <em>y</em> keyword is used,
the y-box length will change. A box dimension will not change if that
component is not specified, although you have the option to change
that dimension via the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> command.</p>
<p>For all barostat keywords, the <em>Pdamp</em> parameter operates like the
<em>Tdamp</em> parameter, determining the time scale on which pressure is
relaxed. For example, a value of 10.0 means to relax the pressure in
a timespan of (roughly) 10 time units (e.g. tau or fmsec or psec - see
the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command).</p>
<p>Regardless of what atoms are in the fix group (the only atoms which
are time integrated), a global pressure or stress tensor is computed
for all atoms. Similarly, when the size of the simulation box is
changed, all atoms are re-scaled to new positions, unless the keyword
<em>dilate</em> is specified with a <em>dilate-group-ID</em> for a group that
represents a subset of the atoms. This can be useful, for example, to
leave the coordinates of atoms in a solid substrate unchanged and
controlling the pressure of a surrounding fluid. Another example is a
system consisting of rigid bodies and point particles where the
barostat is only coupled with the rigid bodies. This option should be
used with care, since it can be unphysical to dilate some atoms and
not others, because it can introduce large, instantaneous
displacements between a pair of atoms (one dilated, one not) that are
far from the dilation origin.</p>
<p>The <em>couple</em> keyword allows two or three of the diagonal components of
the pressure tensor to be “coupled” together. The value specified
with the keyword determines which are coupled. For example, <em>xz</em>
means the <em>Pxx</em> and <em>Pzz</em> components of the stress tensor are coupled.
<em>Xyz</em> means all 3 diagonal components are coupled. Coupling means two
things: the instantaneous stress will be computed as an average of the
corresponding diagonal components, and the coupled box dimensions will
be changed together in lockstep, meaning coupled dimensions will be
dilated or contracted by the same percentage every timestep. The
<em>Pstart</em>, <em>Pstop</em>, <em>Pdamp</em> parameters for any coupled dimensions must
be identical. <em>Couple xyz</em> can be used for a 2d simulation; the <em>z</em>
dimension is simply ignored.</p>
<p>The <em>iso</em> and <em>aniso</em> keywords are simply shortcuts that are
equivalent to specifying several other keywords together.</p>
<p>The keyword <em>iso</em> means couple all 3 diagonal components together when
pressure is computed (hydrostatic pressure), and dilate/contract the
dimensions together. Using “iso Pstart Pstop Pdamp” is the same as
<p>The keyword/value option pairs are used in the following ways.</p>
<p>The <em>langevin</em> and <em>temp</em> and <em>tparam</em> keywords perform thermostatting
of the rigid bodies, altering both their translational and rotational
degrees of freedom. What is meant by “temperature” of a collection of
rigid bodies and how it can be monitored via the fix output is
discussed below.</p>
<p>The <em>langevin</em> keyword applies a Langevin thermostat to the constant
NVE time integration performed by any of the 4 NVE rigid styles:
<em>rigid</em>, <em>rigid/nve</em>, <em>rigid/small</em>, <em>rigid/small/nve</em>. It cannot be
used with the 2 NVT rigid styles: <em>rigid/nvt</em>, <em>rigid/small/nvt</em>. The
desired temperature at each timestep is a ramped value during the run
from <em>Tstart</em> to <em>Tstop</em>. The <em>Tdamp</em> parameter is specified in time
units and determines how rapidly the temperature is relaxed. For
example, a value of 100.0 means to relax the temperature in a timespan
of (roughly) 100 time units (tau or fmsec or psec - see the
<a class="reference internal" href="units.html"><span class="doc">units</span></a> command). The random # <em>seed</em> must be a positive
integer.</p>
<p>The way that Langevin thermostatting operates is explained on the <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> doc page. If you wish to simply viscously
damp the rotational motion without thermostatting, you can set
<em>Tstart</em> and <em>Tstop</em> to 0.0, which means only the viscous drag term in
the Langevin thermostat will be applied. See the discussion on the
<a class="reference internal" href="fix_viscous.html"><span class="doc">fix viscous</span></a> doc page for details.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When the <em>langevin</em> keyword is used with fix rigid versus fix
rigid/small, different dynamics will result for parallel runs. This
is because of the way random numbers are used in the two cases. The
dynamics for the two cases should be statistically similar, but will
not be identical, even for a single timestep.</p>
</div>
<p>The <em>temp</em> and <em>tparam</em> keywords apply a Nose/Hoover thermostat to the
NVT time integration performed by the 2 NVT rigid styles. They cannot
be used with the 4 NVE rigid styles. The desired temperature at each
timestep is a ramped value during the run from <em>Tstart</em> to <em>Tstop</em>.
The <em>Tdamp</em> parameter is specified in time units and determines how
rapidly the temperature is relaxed. For example, a value of 100.0
means to relax the temperature in a timespan of (roughly) 100 time
units (tau or fmsec or psec - see the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command).</p>
<p>Nose/Hoover chains are used in conjunction with this thermostat. The
<em>tparam</em> keyword can optionally be used to change the chain settings
used. <em>Tchain</em> is the number of thermostats in the Nose Hoover chain.
This value, along with <em>Tdamp</em> can be varied to dampen undesirable
oscillations in temperature that can occur in a simulation. As a rule
of thumb, increasing the chain length should lead to smaller
oscillations. The keyword <em>pchain</em> specifies the number of
thermostats in the chain thermostatting the barostat degrees of
freedom.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">There are alternate ways to thermostat a system of rigid bodies.
You can use <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> to treat the individual
particles in the rigid bodies as effectively immersed in an implicit
solvent, e.g. a Brownian dynamics model. For hybrid systems with both
rigid bodies and solvent particles, you can thermostat only the
solvent particles that surround one or more rigid bodies by
appropriate choice of groups in the compute and fix commands for
temperature and thermostatting. The solvent interactions with the
rigid bodies should then effectively thermostat the rigid body
temperature as well without use of the Langevin or Nose/Hoover options
associated with the fix rigid commands.</p>
</div>
<hr class="docutils" />
<p>The <em>mol</em> keyword can only be used with the <em>rigid/small</em> styles. It
must be used when other commands, such as <a class="reference internal" href="fix_deposit.html"><span class="doc">fix deposit</span></a> or <a class="reference internal" href="fix_pour.html"><span class="doc">fix pour</span></a>, add rigid
bodies on-the-fly during a simulation. You specify a <em>template-ID</em>
previously defined using the <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command, which
reads a file that defines the molecule. You must use the same
<em>template-ID</em> that the other fix which is adding rigid bodies uses.
The coordinates, atom types, atom diameters, center-of-mass, and
moments of inertia can be specified in the molecule file. See the
<a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command for details. The only settings
required to be in this file are the coordinates and types of atoms in
the molecule, in which case the molecule command calculates the other
quantities itself.</p>
<p>Note that these other fixes create new rigid bodies, in addition to
those defined initially by this fix via the <em>bodystyle</em> setting.</p>
<p>Also note that when using the <em>mol</em> keyword, extra restart information
about all rigid bodies is written out whenever a restart file is
written out. See the NOTE in the next section for details.</p>
<hr class="docutils" />
<p>The <em>infile</em> keyword allows a file of rigid body attributes to be read
in from a file, rather then having LAMMPS compute them. There are 5
such attributes: the total mass of the rigid body, its center-of-mass
position, its 6 moments of inertia, its center-of-mass velocity, and
the 3 image flags of the center-of-mass position. For rigid bodies
consisting of point particles or non-overlapping finite-size
particles, LAMMPS can compute these values accurately. However, for
rigid bodies consisting of finite-size particles which overlap each
other, LAMMPS will ignore the overlaps when computing these 4
attributes. The amount of error this induces depends on the amount of
overlap. To avoid this issue, the values can be pre-computed
(e.g. using Monte Carlo integration).</p>
<p>The format of the file is as follows. Note that the file does not
have to list attributes for every rigid body integrated by fix rigid.
Only bodies which the file specifies will have their computed
attributes overridden. The file can contain initial blank lines or
comment lines starting with “#” which are ignored. The first
non-blank, non-comment line should list N = the number of lines to
follow. The N successive lines contain the following information:</p>
<p>The rigid body IDs are all positive integers. For the <em>single</em>
bodystyle, only an ID of 1 can be used. For the <em>group</em> bodystyle,
IDs from 1 to Ng can be used where Ng is the number of specified
groups. For the <em>molecule</em> bodystyle, use the molecule ID for the
atoms in a specific rigid body as the rigid body ID.</p>
<p>The masstotal and center-of-mass coordinates (xcm,ycm,zcm) are
self-explanatory. The center-of-mass should be consistent with what
is calculated for the position of the rigid body with all its atoms
unwrapped by their respective image flags. If this produces a
center-of-mass that is outside the simulation box, LAMMPS wraps it
back into the box.</p>
<p>The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
values consistent with the current orientation of the rigid body
around its center of mass. The values are with respect to the
simulation box XYZ axes, not with respect to the prinicpal axes of the
rigid body itself. LAMMPS performs the latter calculation internally.</p>
<p>The (vxcm,vycm,vzcm) values are the velocity of the center of mass.
The (lx,ly,lz) values are the angular momentum of the body. The
(vxcm,vycm,vzcm) and (lx,ly,lz) values can simply be set to 0 if you
wish the body to have no initial motion.</p>
<p>The (ixcm,iycm,izcm) values are the image flags of the center of mass
of the body. For periodic dimensions, they specify which image of the
simulation box the body is considered to be in. An image of 0 means
it is inside the box as defined. A value of 2 means add 2 box lengths
to get the true value. A value of -1 means subtract 1 box length to
get the true value. LAMMPS updates these flags as the rigid bodies
cross periodic boundaries during the simulation.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you use the <em>infile</em> or <em>mol</em> keywords and write restart
files during a simulation, then each time a restart file is written,
the fix also write an auxiliary restart file with the name
rfile.rigid, where “rfile” is the name of the restart file,
e.g. tmp.restart.10000 and tmp.restart.10000.rigid. This auxiliary
file is in the same format described above. Thus it can be used in a
new input script that restarts the run and re-specifies a rigid fix
using an <em>infile</em> keyword and the appropriate filename. Note that the
auxiliary file will contain one line for every rigid body, even if the
original file only listed a subset of the rigid bodies.</p>
</div>
<hr class="docutils" />
<p>If you use a <a class="reference internal" href="compute.html"><span class="doc">temperature compute</span></a> with a group that
includes particles in rigid bodies, the degrees-of-freedom removed by
each rigid body are accounted for in the temperature (and pressure)
computation, but only if the temperature group includes all the
particles in a particular rigid body.</p>
<p>A 3d rigid body has 6 degrees of freedom (3 translational, 3
rotational), except for a collection of point particles lying on a
straight line, which has only 5, e.g a dimer. A 2d rigid body has 3
degrees of freedom (2 translational, 1 rotational).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">You may wish to explicitly subtract additional
degrees-of-freedom if you use the <em>force</em> and <em>torque</em> keywords to
eliminate certain motions of one or more rigid bodies. LAMMPS does
not do this automatically.</p>
</div>
<p>The rigid body contribution to the pressure of the system (virial) is
also accounted for by this fix.</p>
<hr class="docutils" />
<p>If your simlulation is a hybrid model with a mixture of rigid bodies
and non-rigid particles (e.g. solvent) there are several ways these
rigid fixes can be used in tandem with <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a>, <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>, <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a>, and <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a>.</p>
<p>If you wish to perform NVE dynamics (no thermostatting or
barostatting), use one of 4 NVE rigid styles to integrate the rigid
bodies, and <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> to integrate the non-rigid
particles.</p>
<p>If you wish to perform NVT dynamics (thermostatting, but no
barostatting), you can use one of the 2 NVT rigid styles for the rigid
bodies, and any thermostatting fix for the non-rigid particles (<a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>, <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a>, <a class="reference internal" href="fix_temp_berendsen.html"><span class="doc">fix temp/berendsen</span></a>). You can also use one of the
4 NVE rigid styles for the rigid bodies and thermostat them using <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> on the group that contains all the
particles in the rigid bodies. The net force added by <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> to each rigid body effectively thermostats
its translational center-of-mass motion. Not sure how well it does at
thermostatting its rotational motion.</p>
<p>If you with to perform NPT or NPH dynamics (barostatting), you cannot
use both <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> and the NPT or NPH rigid styles. This
is because there can only be one fix which monitors the global
pressure and changes the simulation box dimensions. So you have 3
choices:</p>
<ul class="simple">
<li>Use one of the 4 NPT or NPH styles for the rigid bodies. Use the
<em>dilate</em> all option so that it will dilate the positions of the
non-rigid particles as well. Use <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> (or any other
thermostat) for the non-rigid particles.</li>
<li>Use <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> for the group of non-rigid particles. Use
the <em>dilate</em> all option so that it will dilate the center-of-mass
positions of the rigid bodies as well. Use one of the 4 NVE or 2 NVT
rigid styles for the rigid bodies.</li>
<li>Use <a class="reference internal" href="fix_press_berendsen.html"><span class="doc">fix press/berendsen</span></a> to compute the
pressure and change the box dimensions. Use one of the 4 NVE or 2 NVT
rigid styles for the rigid bodies. Use <a class="reference external" href="fix_nh.thml">fix nvt</a> (or any
other thermostat) for the non-rigid particles.</li>
</ul>
<p>In all case, the rigid bodies and non-rigid particles both contribute
to the global pressure and the box is scaled the same by any of the
barostatting fixes.</p>
<p>You could even use the 2nd and 3rd options for a non-hybrid simulation
consisting of only rigid bodies, assuming you give <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> an empty group, though it’s an odd thing to do. The
barostatting fixes (<a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> and <a class="reference internal" href="fix_press_berendsen.html"><span class="doc">fix press/berensen</span></a>) will monitor the pressure
and change the box dimensions, but not time integrate any particles.
The integration of the rigid bodies will be performed by fix
rigid/nvt.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<hr class="docutils" />
<p><strong>Restart, fix_modify, output, run start/stop, minimize info:</strong></p>
<p>No information about the 4 NVE rigid styles is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. The exception is if the <em>infile</em> or
<em>mol</em> keyword is used, in which case an auxiliary file is written out
with rigid body information each time a restart file is written, as
explained above for the <em>infile</em> keyword. For the 2 NVT rigid styles,
the state of the Nose/Hoover thermostat is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. Ditto for the 4 NPT and NPH rigid styles, and
the state of the Nose/Hoover barostat. See the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for info on how to re-specify
a fix in an input script that reads a restart file, so that the
operation of the fix continues in an uninterrupted fashion.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by the 6
NVT, NPT, NPH rigid styles to add the energy change induced by the
thermostatting to the system’s potential energy as part of
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> and <em>press</em> options are
supported by the 4 NPT and NPH rigid styles to change the computes
used to calculate the instantaneous pressure tensor. Note that the 2
NVT rigid fixes do not use any external compute to compute
instantaneous temperature.</p>
<p>The 2 NVE rigid fixes compute a global scalar which can be accessed by
various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar
value calculated by these fixes is “intensive”. The scalar is the
current temperature of the collection of rigid bodies. This is
averaged over all rigid bodies and their translational and rotational
degrees of freedom. The translational energy of a rigid body is 1/2 m
v^2, where m = total mass of the body and v = the velocity of its
center of mass. The rotational energy of a rigid body is 1/2 I w^2,
where I = the moment of inertia tensor of the body and w = its angular
velocity. Degrees of freedom constrained by the <em>force</em> and <em>torque</em>
keywords are removed from this calculation, but only for the <em>rigid</em>
and <em>rigid/nve</em> fixes.</p>
<p>The 6 NVT, NPT, NPH rigid fixes compute a global scalar which can be
accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>.
The scalar value calculated by these fixes is “extensive”. The scalar
is the cumulative energy change due to the thermostatting and
barostatting the fix performs.</p>
<p>All of the <em>rigid</em> styles (not the <em>rigid/small</em> styles) compute a
global array of values which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. Similar information about the
bodies defined by the <em>rigid/small</em> styles can be accessed via the
<p>These fixes are all part of the RIGID package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Assigning a temperature via the <a class="reference internal" href="velocity.html"><span class="doc">velocity create</span></a>
command to a system with <a class="reference internal" href="#"><span class="doc">rigid bodies</span></a> may not have
the desired outcome for two reasons. First, the velocity command can
be invoked before the rigid-body fix is invoked or initialized and the
number of adjusted degrees of freedom (DOFs) is known. Thus it is not
possible to compute the target temperature correctly. Second, the
assigned velocities may be partially canceled when constraints are
first enforced, leading to a different temperature than desired. A
workaround for this is to perform a <a class="reference internal" href="run.html"><span class="doc">run 0</span></a> command, which
insures all DOFs are accounted for properly, and then rescale the
temperature to the desired value before performing a simulation. For
<span class="n">run</span> <span class="mi">0</span> <span class="c1"># temperature may not be 300K</span>
<span class="n">velocity</span> <span class="nb">all</span> <span class="n">scale</span> <span class="mf">300.0</span> <span class="c1"># now it should be</span>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<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
+<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
<p class="last">The fix rattle command modifies forces and velocities and thus
should be defined after all other integration fixes in your input
script. If you define other fixes that modify velocities or forces
after fix rattle operates, then fix rattle will not take them into
account and the overall time integration will typically not satisfy
the RATTLE constraints. You can check whether the constraints work
correctly by setting the value of RATTLE_DEBUG in src/fix_rattle.cpp
to 1 and recompiling LAMMPS.</p>
</div>
<hr class="docutils" />
<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>.
<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>.
-<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>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>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>wall/reflect = style name of this fix command</li>
<li>one or more face/arg pairs may be appended</li>
<li>face = <em>xlo</em> or <em>xhi</em> or <em>ylo</em> or <em>yhi</em> or <em>zlo</em> or <em>zhi</em></li>
</ul>
<pre class="literal-block">
<em>xlo</em>,<em>ylo</em>,<em>zlo</em> arg = EDGE or constant or variable
EDGE = current lo edge of simulation box
constant = number like 0.0 or -30.0 (distance units)
variable = <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> like v_x or v_wiggle
<em>xhi</em>,<em>yhi</em>,<em>zhi</em> arg = EDGE or constant or variable
EDGE = current hi edge of simulation box
constant = number like 50.0 or 100.3 (distance units)
variable = <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> like v_x or v_wiggle
</pre>
<ul class="simple">
<li>zero or more keyword/value pairs may be appended</li>
<li>keyword = <em>units</em></li>
</ul>
<pre class="literal-block">
<em>units</em> value = <em>lattice</em> or <em>box</em>
<em>lattice</em> = the wall position is defined in lattice units
<em>box</em> = the wall position is defined in simulation box units
</pre>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
fix xwalls all wall/reflect xlo EDGE xhi EDGE
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>The ramp(lo,hi) function adjusts the wall position linearly from lo to
hi over the course of a run. The vdisplace(c0,velocity) function does
something similar using the equation position = c0 + velocity*delta,
where delta is the elapsed time.</p>
<p>The swiggle(c0,A,period) function causes the wall position to
oscillate sinusoidally according to this equation, where omega = 2 PI
/ period:</p>
<pre class="literal-block">
position = c0 + A sin(omega*delta)
</pre>
<p>The cwiggle(c0,A,period) function causes the wall position to
oscillate sinusoidally according to this equation, which will have an
initial wall velocity of 0.0, and thus may impose a gentler
perturbation on the particles:</p>
<pre class="literal-block">
position = c0 + A (1 - cos(omega*delta))
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<hr class="docutils" />
<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>.
+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>.
<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>
<pre class="literal-block">
compute 1 all pe/atom
compute 2 all reduce sum c_1
thermo_style custom step temp pe c_2
run 0
</pre>
<pre class="literal-block">
variable eatom atom "c_1 > -3.0"
group hienergy variable eatom
</pre>
<p>Note that these lines</p>
<pre class="literal-block">
compute 2 all reduce sum c_1
thermo_style custom step temp pe c_2
run 0
</pre>
<p>are necessary to insure that the “eatom” variable is current when the
group command invokes it. Because the eatom variable computes the
per-atom energy via the pe/atom compute, it will only be current if a
run has been performed which evaluated pairwise energies, and the
pe/atom compute was actually invoked during the run. Printing the
thermodyanmic info for compute 2 insures that this is the case, since
it sums the pe/atom compute values (in the reduce compute) to output
them to the screen. 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 on insuring that
variables are current when they are evaluated between runs.</p>
<p>The <em>include</em> style with its arg <em>molecule</em> adds atoms to a group that
have the same molecule ID as atoms already in the group. The molecule
ID = 0 is ignored in this operation, since it is assumed to flag
isolated atoms that are not part of molecules. An example of where
this operation is useful is if the <em>region</em> style has been used
previously to add atoms to a group that are within a geometric region.
If molecules straddle the region boundary, then atoms outside the
region that are part of molecules with atoms inside the region will
not be in the group. Using the group command a 2nd time with <em>include
molecule</em> will add those atoms that are outside the region to the
group.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The <em>include molecule</em> operation is relatively expensive in a
parallel sense. This is because it requires communication of relevant
molecule IDs between all the processors and each processor to loop
over its atoms once per processor, to compare its atoms to the list of
molecule IDs from every other processor. Hence it scales as N, rather
than N/P as most of the group operations do, where N is the number of
atoms, and P is the number of processors.</p>
</div>
<p>The <em>subtract</em> style takes a list of two or more existing group names
as arguments. All atoms that belong to the 1st group, but not to any
of the other groups are added to the specified group.</p>
<p>The <em>union</em> style takes a list of one or more existing group names as
arguments. All atoms that belong to any of the listed groups are
added to the specified group.</p>
<p>The <em>intersect</em> style takes a list of two or more existing group names
as arguments. Atoms that belong to every one of the listed groups are
added to the specified group.</p>
<hr class="docutils" />
<p>The <em>dynamic</em> style flags an existing or new group as dynamic. This
means atoms will be (re)assigned to the group periodically as a
simulation runs. This is in contrast to static groups where atoms are
permanently assigned to the group. The way the assignment occurs is
as follows. Only atoms in the group specified as the parent group via
the parent-ID are assigned to the dynamic group before the following
conditions are applied. If the <em>region</em> keyword is used, atoms not in
the specified region are removed from the dynamic group. If the <em>var</em>
keyword is used, the variable name must be an atom-style or
atomfile-style variable. The variable is evaluated and atoms whose
per-atom values are 0.0, are removed from the dynamic group.</p>
<p>The assignment of atoms to a dynamic group is done at the beginning of
each run and on every timestep that is a multiple of <em>N</em>, which is the
argument for the <em>every</em> keyword (N = 1 is the default). For an
energy minimization, via the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command, an
-assignement is made at the beginning of the minimization, but not
+assignment is made at the beginning of the minimization, but not
during the iterations of the minimizer.</p>
<p>The point in the timestep at which atoms are assigned to a dynamic
group is after the initial stage of velocity Verlet time integration
has been performed, and before neighbor lists or forces are computed.
This is the point in the timestep where atom positions have just
changed due to the time integration, so the region criterion should be
accurate, if applied.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If the <em>region</em> keyword is used to determine what atoms are in
the dynamic group, atoms can move outside of the simulation box
between reneighboring events. Thus if you want to include all atoms
on the left side of the simulation box, you probably want to set the
left boundary of the region to be outside the simulation box by some
reasonable amount (e.g. up to the cutoff of the potential), else they
may be excluded from the dynamic region.</p>
</div>
<p>Here is an example of using a dynamic group to shrink the set of atoms
being integrated by using a spherical region with a variable radius
(shrinking from 18 to 5 over the course of the run). This could be
used to model a quench of the system, freezing atoms outside the
shrinking sphere, then converting the remaining atoms to a static
group and running further.</p>
<pre class="literal-block">
variable nsteps equal 5000
variable rad equal 18-(step/v_nsteps)*(18-5)
region ss sphere 20 20 0 v_rad
group mobile dynamic all region ss
fix 1 mobile nve
run ${nsteps}
group mobile static
run ${nsteps}
</pre>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">All fixes and computes take a group ID as an argument, but they
do not all allow for use of a dynamic group. If you get an error
message that this is not allowed, but feel that it should be for the
fix or compute in question, then please post your reasoning to the
LAMMPS mail list and we can change it.</p>
</div>
<p>The <em>static</em> style removes the setting for a dynamic group, converting
it to a static group (the default). The atoms in the static group are
those currently in the dynamic group.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>There can be no more than 32 groups defined at one time, including
“all”.</p>
<p>The parent group of a dynamic group cannot itself be a dynamic group.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using 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>
<p>The Boolean expressions for the if and elif keywords have a C-like
syntax. Note that each expression is a single argument within the if
command. Thus if you want to include spaces in the expression for
clarity, you must enclose the entire expression in quotes.</p>
<p>An expression is built out of numbers (which start with a digit or
period or minus sign) or strings (which start with a letter and can
contain alphanumeric characters or underscores):</p>
<pre class="literal-block">
0.2, 100, 1.0e20, -15.4, etc
InP, myString, a123, ab_23_cd, etc
</pre>
<p>and Boolean operators:</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<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)
</pre>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
kspace_style pppm 1.0e-4
kspace_style pppm/cg 1.0e-5 1.0e-6
kspace style msm 1.0e-4
kspace_style none
</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>.
commands. The replica-specific names of these files can be specified
as in the discussion above for the <em>each</em> file-style. Also see the
section below for how a NEB calculation can produce restart files, so
that a long calculation can be restarted if needed.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">None of the <em>file-style</em> settings change the initial
configuration of any atom in the first replica. The first replica
must thus be in the correct initial configuration at the time the neb
command is issued.</p>
</div>
<hr class="docutils" />
<p>A NEB calculation proceeds in two stages, each of which is a
minimization procedure, performed via damped dynamics. To enable
this, you must first define a damped dynamics
<a class="reference internal" href="min_style.html"><span class="doc">min_style</span></a>, such as <em>quickmin</em> or <em>fire</em>. The <em>cg</em>,
<em>sd</em>, and <em>hftn</em> styles cannot be used, since they perform iterative
line searches in their inner loop, which cannot be easily synchronized
across multiple replicas.</p>
<p>The minimizer tolerances for energy and force are set by <em>etol</em> and
<em>ftol</em>, the same as for the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command.</p>
<p>A non-zero <em>etol</em> means that the NEB calculation will terminate if the
energy criterion is met by every replica. The energies being compared
to <em>etol</em> do not include any contribution from the inter-replica
forces, since these are non-conservative. A non-zero <em>ftol</em> means
that the NEB calculation will terminate if the force criterion is met
by every replica. The forces being compared to <em>ftol</em> include the
inter-replica forces between an atom and its images in adjacent
replicas.</p>
<p>The maximum number of iterations in each stage is set by <em>N1</em> and
<em>N2</em>. These are effectively timestep counts since each iteration of
damped dynamics is like a single timestep in a dynamics
<a class="reference internal" href="run.html"><span class="doc">run</span></a>. During both stages, the potential energy of each
replica and its normalized distance along the reaction path (reaction
coordinate RD) will be printed to the screen and log file every
<em>Nevery</em> timesteps. The RD is 0 and 1 for the first and last replica.
For intermediate replicas, it is the cumulative distance (normalized
by the total cumulative distance) between adjacent replicas, where
“distance” is defined as the length of the 3N-vector of differences in
atomic coordinates, where N is the number of NEB atoms involved in the
transition. These outputs allow you to monitor NEB’s progress in
finding a good energy barrier. <em>N1</em> and <em>N2</em> must both be multiples
of <em>Nevery</em>.</p>
<p>In the first stage of NEB, the set of replicas should converge toward
the minimum energy path (MEP) of conformational states that transition
over the barrier. The MEP for a barrier is defined as a sequence of
3N-dimensional states that cross the barrier at its saddle point, each
of which has a potential energy gradient parallel to the MEP itself.
The replica states will also be roughly equally spaced along the MEP
due to the inter-replica spring force added by the <a class="reference internal" href="fix_neb.html"><span class="doc">fix neb</span></a> command.</p>
<p>In the second stage of NEB, the replica with the highest energy
is selected and the inter-replica forces on it are converted to a
force that drives its atom coordinates to the top or saddle point of
the barrier, via the barrier-climbing calculation described in
<a class="reference internal" href="#henkelman2"><span class="std std-ref">(Henkelman2)</span></a>. As before, the other replicas rearrange
themselves along the MEP so as to be roughly equally spaced.</p>
<p>When both stages are complete, if the NEB calculation was successful,
one of the replicas should be an atomic configuration at the top or
saddle point of the barrier, the potential energies for the set of
replicas should represent the energy profile of the barrier along the
MEP, and the configurations of the replicas should be a sequence of
configurations along the MEP.</p>
<hr class="docutils" />
<p>A few other settings in your input script are required or advised to
perform a NEB calculation. See the NOTE about the choice of timestep
at the beginning of this doc page.</p>
<p>An atom map must be defined which it is not by default for <a class="reference internal" href="atom_style.html"><span class="doc">atom_style atomic</span></a> problems. The <a class="reference internal" href="atom_modify.html"><span class="doc">atom_modify map</span></a> command can be used to do this.</p>
<p>The “atom_modify sort 0 0.0” command should be used to turn off atom
sorting.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">This sorting restriction will be removed in a future version of
NEB in LAMMPS.</p>
</div>
<p>The minimizers in LAMMPS operate on all atoms in your system, even
non-NEB atoms, as defined above. To prevent non-NEB atoms from moving
during the minimization, you should use the <a class="reference internal" href="fix_setforce.html"><span class="doc">fix setforce</span></a> command to set the force on each of those
atoms to 0.0. This is not required, and may not even be desired in
some cases, but if those atoms move too far (e.g. because the initial
state of your system was not well-minimized), it can cause problems
for the NEB procedure.</p>
<p>The damped dynamics <a class="reference internal" href="min_style.html"><span class="doc">minimizers</span></a>, such as <em>quickmin</em>
and <em>fire</em>), adjust the position and velocity of the atoms via an
Euler integration step. Thus you must define an appropriate
<a class="reference internal" href="timestep.html"><span class="doc">timestep</span></a> to use with NEB. As mentioned above, NEB
will often converge more quickly if you use a timestep about 10x
larger than you would normally use for dynamics simulations.</p>
<hr class="docutils" />
<p>Each file read by the neb command containing atomic coordinates used
to initialize one or more replicas must be formatted as follows.</p>
<p>The file can be ASCII text or a gzipped text file (detected by a .gz
suffix). The file can contain initial blank lines or comment lines
starting with “#” which are ignored. The first non-blank, non-comment
line should list N = the number of lines to follow. The N successive
<p>The fields are the the atom ID, followed by the x,y,z coordinates.
The lines can be listed in any order. Additional trailing information
on the line is OK, such as a comment.</p>
<p>Note that for a typical NEB calculation you do not need to specify
initial coordinates for very many atoms to produce differing starting
and final replicas whose intermediate replicas will converge to the
energy barrier. Typically only new coordinates for atoms
geometrically near the barrier need be specified.</p>
<p>Also note there is no requirement that the atoms in the file
correspond to the NEB atoms in the group defined by the <a class="reference internal" href="fix_neb.html"><span class="doc">fix neb</span></a> command. Not every NEB atom need be in the file,
and non-NEB atoms can be listed in the file.</p>
<hr class="docutils" />
<p>Four kinds of output can be generated during a NEB calculation: energy
barrier 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
contains a line of output, printed once every <em>Nevery</em> timesteps. It
contains the timestep, the maximum force per replica, the maximum
force per atom (in any replica), potential gradients in the initial,</p>
<blockquote>
<div>final, and climbing replicas,</div></blockquote>
<p>the forward and backward energy barriers,
the total reaction coordinate (RDT), and
the normalized reaction coordinate and potential energy of each replica.</p>
<p>The “maximum force per replica” is
the two-norm of the 3N-length force vector for the atoms in each
replica, maximized across replicas, which is what the <em>ftol</em> setting
is checking against. In this case, N is all the atoms in each
replica. The “maximum force per atom” is the maximum force component
of any atom in any replica. The potential gradients are the two-norm
of the 3N-length force vector solely due to the interaction potential i.e.
without adding in inter-replica forces. Note that inter-replica forces
are zero in the initial and final replicas, and only affect
the direction in the climbing replica. For this reason, the “maximum
force per replica” is often equal to the potential gradient in the
climbing replica. In the first stage of NEB, there is no climbing
replica, and so the potential gradient in the highest energy replica
is reported, since this replica will become the climbing replica
in the second stage of NEB.</p>
<p>The “reaction coordinate” (RD) for each
replica is the two-norm of the 3N-length vector of distances between
its atoms and the preceding replica’s atoms, added to the RD of the
preceding replica. The RD of the first replica RD1 = 0.0;
the RD of the final replica RDN = RDT, the total reaction coordinate.
The normalized RDs are divided by RDT,
so that they form a monotonically increasing sequence
from zero to one. When computing RD, N only includes the atoms
being operated on by the fix neb command.</p>
<p>The forward (reverse) energy barrier is the potential energy of the highest
replica minus the energy of the first (last) replica.</p>
<p>When running on multiple partitions, LAMMPS produces additional log
files for each partition, e.g. log.lammps.0, log.lammps.1, etc. For a
NEB calculation, these contain the thermodynamic output for each
replica.</p>
<p>If <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> commands in the input script define a filename
that includes a <em>universe</em> or <em>uloop</em> style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>,
then one dump file (per dump command) will be created for each
replica. At the end of the NEB calculation, the final snapshot in
each file will contain the sequence of snapshots that transition the
system over the energy barrier. Earlier snapshots will show the
convergence of the replicas to the MEP.</p>
<p>Likewise, <a class="reference internal" href="restart.html"><span class="doc">restart</span></a> filenames can be specified with a
<em>universe</em> or <em>uloop</em> style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>, to generate
restart files for each replica. These may be useful if the NEB
calculation fails to converge properly to the MEP, and you wish to
restart the calculation from an intermediate point with altered
parameters.</p>
<p>There are 2 Python scripts provided in the tools/python directory,
neb_combine.py and neb_final.py, which are useful in analyzing output
from a NEB calculation. Assume a NEB simulation with M replicas, and
the NEB atoms labelled with a specific atom type.</p>
<p>The neb_combine.py script extracts atom coords for the NEB atoms from
all M dump files and creates a single dump file where each snapshot
contains the NEB atoms from all the replicas and one copy of non-NEB
atoms from the first replica (presumed to be identical in other
replicas). This can be visualized/animated to see how the NEB atoms
relax as the NEB calculation proceeds.</p>
<p>The neb_final.py script extracts the final snapshot from each of the M
dump files to create a single dump file with M snapshots. This can be
visualized to watch the system make its transition over the energy
barrier.</p>
<p>To illustrate, here are images from the final snapshot produced by the
neb_combine.py script run on the dump files produced by the two
example input scripts in examples/neb. Click on them to see a larger
image.</p>
<a class=""
data-lightbox="group-default"
href="_images/hop1.jpg"
title=""
data-title=""
><img src="_images/hop1.jpg"
class=""
width="25%"
height="auto"
alt=""/>
</a><a class=""
data-lightbox="group-default"
href="_images/hop2.jpg"
title=""
data-title=""
><img src="_images/hop2.jpg"
class=""
width="25%"
height="auto"
alt=""/>
</a></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
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using 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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>By default, all three terms are included. For the <em>airebo</em> style, if
the two optional flag arguments to the pair_style command are
included, the LJ and torsional terms can be turned off. Note that
both or neither of the flags must be included. If both of the LJ an
torsional terms are turned off, it becomes the 2nd-generation REBO
potential, with a small caveat on the spline fitting procedure
mentioned below. This can be specified directly as pair_style <em>rebo</em>
with no additional arguments.</p>
<p>The detailed formulas for this potential are given in
<a class="reference internal" href="#stuart"><span class="std std-ref">(Stuart)</span></a>; here we provide only a brief description.</p>
<p>The E_REBO term has the same functional form as the hydrocarbon REBO
potential developed in <a class="reference internal" href="#brenner"><span class="std std-ref">(Brenner)</span></a>. The coefficients for
E_REBO in AIREBO are essentially the same as Brenner’s potential, but
a few fitted spline values are slightly different. For most cases the
E_REBO term in AIREBO will produce the same energies, forces and
statistical averages as the original REBO potential from which it was
derived. The E_REBO term in the AIREBO potential gives the model its
reactive capabilities and only describes short-ranged C-C, C-H and H-H
interactions (r < 2 Angstroms). These interactions have strong
coordination-dependence through a bond order parameter, which adjusts
the attraction between the I,J atoms based on the position of other
nearby atoms and thus has 3- and 4-body dependence.</p>
<p>The E_LJ term adds longer-ranged interactions (2 < r < cutoff) using a
form similar to the standard <a class="reference internal" href="pair_lj.html"><span class="doc">Lennard Jones potential</span></a>.
The E_LJ term in AIREBO contains a series of switching functions so
that the short-ranged LJ repulsion (1/r^12) does not interfere with
the energetics captured by the E_REBO term. The extent of the E_LJ
interactions is determined by the <em>cutoff</em> argument to the pair_style
command which is a scale factor. For each type pair (C-C, C-H, H-H)
the cutoff is obtained by multiplying the scale factor by the sigma
value defined in the potential file for that type pair. In the
standard AIREBO potential, sigma_CC = 3.4 Angstroms, so with a scale
factor of 3.0 (the argument in pair_style), the resulting E_LJ cutoff
would be 10.2 Angstroms.</p>
<p>The E_TORSION term is an explicit 4-body potential that describes
various dihedral angle preferences in hydrocarbon configurations.</p>
<hr class="docutils" />
<p>Only a single pair_coeff command is used with the <em>airebo</em>, <em>airebo</em>
or <em>rebo</em> style which specifies an AIREBO or AIREBO-M potential file
with parameters for C and H. Note that the <em>rebo</em> style in LAMMPS
uses the same AIREBO-formatted potential file. These are mapped to
LAMMPS atom types by specifying N additional arguments after the
filename in the pair_coeff command, where N is the number of LAMMPS
atom types:</p>
<ul class="simple">
<li>filename</li>
<li>N element names = mapping of AIREBO elements to atom types</li>
</ul>
<p>See the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> doc page for alternate ways
to specify the path for the potential file.</p>
<p>As an example, if your LAMMPS simulation has 4 atom types and you want
the 1st 3 to be C, and the 4th to be H, you would use the following
pair_coeff command:</p>
<pre class="literal-block">
pair_coeff * * CH.airebo C C C H
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>These pair styles do not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>These styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option
for the energy of the exp() and 1/r^6 portion of the pair interaction.</p>
<p>The <em>buck/coul/long</em> pair style supports the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option to tabulate the
short-range portion of the long-range Coulombic interaction.</p>
<p>These styles support the pair_modify tail option for adding long-range
tail corrections to energy and pressure for the A,C terms in the
pair interaction.</p>
<p>These styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>These styles can only be used via the <em>pair</em> keyword of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the <em>inner</em>,
<em>middle</em>, <em>outer</em> keywords.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The <em>buck/coul/long</em> style is part of the KSPACE package. The
<em>buck/coul/long/cs</em> style is part of the CORESHELL package. They are
only enabled if LAMMPS was built with that package (which it is by
default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The second coefficient, rho, must be greater than zero.</p>
<p>The latter 2 coefficients are optional. If not specified, the global
Buckingham and Coulombic cutoffs specified in the pair_style command
are used. If only one cutoff is specified, it is used as the cutoff
for both Buckingham and Coulombic interactions for this type pair. If
both coefficients are specified, they are used as the Buckingham and
Coulombic cutoffs for this type pair. Note that if you are using
<em>flag_buck</em> set to <em>long</em>, you cannot specify a Buckingham cutoff for
an atom type pair, since only one global Buckingham cutoff is allowed.
Similarly, if you are using <em>flag_coul</em> set to <em>long</em>, you cannot
specify a Coulombic cutoff for an atom type pair, since only one
global Coulombic cutoff is allowed.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the exp() and 1/r^6 portion of the pair
interaction, assuming <em>flag_buck</em> is <em>cut</em>.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the Buckingham portion of the pair
interaction.</p>
<p>This pair style supports the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table and
table/disp options since they can tabulate the short-range portion of
the long-range Coulombic and dispersion interactions.</p>
<p>This pair style write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style supports the use of the <em>inner</em>, <em>middle</em>, and <em>outer</em>
keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command, meaning the
pairwise forces can be partitioned by distance at different levels of
the rRESPA hierarchy. See the <a class="reference internal" href="run_style.html"><span class="doc">run_style</span></a> command for
details.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This style is part of the KSPACE package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info. Note that
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>style = <em>lj/charmm/coul/charmm</em> or <em>lj/charmm/coul/charmm/implicit</em> or <em>lj/charmm/coul/long</em> or <em>lj/charmm/coul/msm</em></li>
<li>args = list of arguments for a particular style</li>
<p>Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum at 2^(1/6)
sigma.</p>
<p>The latter 2 coefficients are optional. If they are specified, they
are used in the LJ formula between 2 atoms of these types which are
also first and fourth atoms in any dihedral. No cutoffs are specified
because this CHARMM force field does not allow varying cutoffs for
individual atom pairs; all pairs use the global cutoff(s) specified in
the pair_style command.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<em>polar</em> value = <em>polar_on</em> or <em>polar_off</em> = whether or not to include atomic polarization
</pre>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
pair_style comb
pair_coeff * * ../potentials/ffield.comb Si
pair_coeff * * ../potentials/ffield.comb Hf Si O
</pre>
<pre class="literal-block">
pair_style comb3 polar_off
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
use the following pair_coeff command:</p>
<pre class="literal-block">
pair_coeff * * ../potentials/ffield.comb Si Hf O Si
</pre>
<p>The first two arguments must be * * so as to span all LAMMPS atom
types. The first and last Si arguments map LAMMPS atom types 1 and 4
to the Si element in the <em>ffield.comb</em> file. The second Hf argument
maps LAMMPS atom type 2 to the Hf element, and the third O argument
maps LAMMPS atom type 3 to the O 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>comb</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>For style <em>comb</em>, the provided potential file <em>ffield.comb</em> contains
all currently-available 2nd generation COMB parameterizations: for Si,
Cu, Hf, Ti, O, their oxides and Zr, Zn and U metals. For style
<em>comb3</em>, the potential file <em>ffield.comb3</em> contains all
currently-available 3rd generation COMB paramterizations: O, Cu, N, C,
H, Ti, Zn and Zr. The status of the optimization of the compounds, for
example Cu<sub>2</sub>O, TiN and hydrocarbons, are given in the
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
<pre class="literal-block">
pair_style hybrid/overlay coul/streitz 12.0 wolf 0.31 eam/alloy
pair_coeff * * coul/streitz AlO.streitz Al O
pair_coeff * * eam/alloy AlO.eam.alloy Al O
fix 1 all qeq/slater 1 12.0 1.0e-6 100 coul/streitz
</pre>
<p>The keyword <em>wolf</em> in the coul/streitz command denotes computing
Coulombic interactions via Wolf summation. An additional damping
parameter is required for the Wolf summation, as described for the
coul/wolf potential above. Alternatively, Coulombic interactions can
be computed via an Ewald summation. 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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
cutoff = global cutoff for Buckingham (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
</pre>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
pair_style born/coul/long/cs 10.0 8.0
pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51
</pre>
<pre class="literal-block">
pair_style buck/coul/long/cs 10.0
pair_style buck/coul/long/cs 10.0 8.0
pair_coeff * * 100.0 1.5 200.0
pair_coeff 1 1 100.0 1.5 200.0 9.0
</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<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
+<a class="reference internal" href="Section_howto.html#howto-25"><span class="std std-ref">Section 6.25</span></a> of the manual for an
overview of the model as implemented in LAMMPS.</p>
<p>These pair styles are identical to the <a class="reference internal" href="pair_born.html"><span class="doc">pair_style born/coul/long</span></a> and <a class="reference internal" href="pair_buck.html"><span class="doc">pair_style buck/coul/long</span></a> styles, except they correctly treat the
special case where the distance between two charged core and shell
atoms in the same core/shell pair approach r = 0.0. This needs
special treatment when a long-range solver for Coulombic interactions
is also used, i.e. via the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command.</p>
<p>More specifically, the short-range Coulomb interaction between a core
and its shell should be turned off using the
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command by setting the 1-2 weight
to 0.0, which works because the core and shell atoms are bonded to
each other. This induces a long-range correction approximation which
fails at small distances (~< 10e-8). Therefore, the Coulomb term which
is used to calculate the correction factor is extended by a minimal
distance (r_min = 1.0-6) when the interaction between a core/shell
<p>where C is an energy-conversion constant, Qi and Qj are the charges on
the core and shell, epsilon is the dielectric constant and r_min is the
minimal distance.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>These pair styles are part of the CORESHELL package. They are only
enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where qi and qj are the charges on the two particles, pi and pj are
the dipole moment vectors of the two particles, r is their separation
distance, and the vector r = Ri - Rj is the separation vector between
the two particles. Note that Eqq and Fqq are simply Coulombic energy
and force, Fij = -Fji as symmetric forces, and Tij != -Tji since the
torques do not act symmetrically. These formulas are discussed in
<a class="reference internal" href="pair_gayberne.html#allen"><span class="std std-ref">(Allen)</span></a> and in <a class="reference internal" href="#toukmaji"><span class="std std-ref">(Toukmaji)</span></a>.</p>
<p>Style <em>lj/sf/dipole/sf</em> computes “shifted-force” interactions between
pairs of particles that each have a charge and/or a point dipole
moment. In general, a shifted-force potential is a (sligthly) modified
potential containing extra terms that make both the energy and its
derivative go to zero at the cutoff distance; this removes
(cutoff-related) problems in energy conservation and any numerical
instability in the equations of motion <a class="reference internal" href="pair_gayberne.html#allen"><span class="std std-ref">(Allen)</span></a>. Shifted-force
interactions for the Lennard-Jones (E_LJ), charge-charge (Eqq),
charge-dipole (Eqp), dipole-charge (Epq) and dipole-dipole (Epp)
potentials are computed by these formulas for the energy (E), force
(F), and torque (T) between particles I and J:</p>
<p>where epsilon and sigma are the standard LJ parameters, r_c is the
cutoff, qi and qj are the charges on the two particles, pi and pj are
the dipole moment vectors of the two particles, r is their separation
distance, and the vector r = Ri - Rj is the separation vector between
the two particles. Note that Eqq and Fqq are simply Coulombic energy
and force, Fij = -Fji as symmetric forces, and Tij != -Tji since the
torques do not act symmetrically. The shifted-force formula for the
Lennard-Jones potential is reported in <a class="reference internal" href="#stoddard"><span class="std std-ref">(Stoddard)</span></a>. The
original (unshifted) formulas for the electrostatic potentials, forces
and torques can be found in <a class="reference internal" href="#price"><span class="std std-ref">(Price)</span></a>. The shifted-force
electrostatic potentials have been obtained by applying equation 5.13
of <a class="reference internal" href="pair_gayberne.html#allen"><span class="std std-ref">(Allen)</span></a>. The formulas for the corresponding forces and
torques have been obtained by applying the ‘chain rule’ as in appendix
C.3 of <a class="reference internal" href="pair_gayberne.html#allen"><span class="std std-ref">(Allen)</span></a>.</p>
<p>If one cutoff is specified in the pair_style command, it is used for
both the LJ and Coulombic (q,p) terms. If two cutoffs are specified,
they are used as cutoffs for the LJ and Coulombic (q,p) terms
interactions as discussed in <a class="reference internal" href="#toukmaji"><span class="std std-ref">(Toukmaji)</span></a>. Dipole-dipole,
dipole-charge, and charge-charge interactions are all supported, along
with the standard 12/6 Lennard-Jones interactions, which are computed
with a cutoff. A <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> must be defined to
use this pair style. Currently, only <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style ewald/disp</span></a> support long-range point-dipole
interactions.</p>
<p>Style <em>lj/long/dipole/long</em> also computes point-dipole interactions as
discussed in <a class="reference internal" href="#toukmaji"><span class="std std-ref">(Toukmaji)</span></a>. Long-range dipole-dipole,
dipole-charge, and charge-charge interactions are all supported, along
with the standard 12/6 Lennard-Jones interactions. LJ interactions
can be cutoff or long-ranged.</p>
<p>For style <em>lj/long/dipole/long</em>, if <em>flag_lj</em> is set to <em>long</em>, no
cutoff is used on the LJ 1/r^6 dispersion term. The long-range
portion is calculated by using the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style ewald_disp</span></a> command. The specified LJ cutoff then
determines which portion of the LJ interactions are computed directly
by the pair potential versus which part is computed in reciprocal
space via the Kspace style. If <em>flag_lj</em> is set to <em>cut</em>, the LJ
interactions are simply cutoff, as with <a class="reference internal" href="pair_lj.html"><span class="doc">pair_style lj/cut</span></a>. If <em>flag_lj</em> is set to <em>off</em>, LJ interactions
are not computed at all.</p>
<p>If <em>flag_coul</em> is set to <em>long</em>, no cutoff is used on the Coulombic or
dipole interactions. The long-range portion is calculated by using
<em>ewald_disp</em> of the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command. If
<em>flag_coul</em> is set to <em>off</em>, Coulombic and dipole interactions are not
computed at all.</p>
<p>Atoms with dipole moments should be integrated using the <a class="reference internal" href="fix_nve_sphere.html"><span class="doc">fix nve/sphere update dipole</span></a> or the <a class="reference internal" href="fix_nvt_sphere.html"><span class="doc">fix nvt/sphere update dipole</span></a> command to rotate the
dipole moments. The <em>omega</em> option on the <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> command can be used to thermostat the
rotational motion. The <a class="reference internal" href="compute_temp_sphere.html"><span class="doc">compute temp/sphere</span></a>
command can be used to monitor the temperature, since it includes
rotational degrees of freedom. The <a class="reference internal" href="atom_style.html"><span class="doc">atom_style hybrid dipole sphere</span></a> command should be used since
it defines the point dipoles and their rotational state.
The magnitude and orientation of the dipole moment for each particle
can be defined by the <a class="reference internal" href="set.html"><span class="doc">set</span></a> command or in the “Atoms” section
of the data file read in by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<p>The latter 2 coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distances for this pair style can be mixed. The default
mix value is <em>geometric</em>. See the “pair_modify” command for details.</p>
<p>For atom type pairs I,J and I != J, the A, sigma, d1, and d2
coefficients and cutoff distance for this pair style can be mixed. A
is an energy value mixed like a LJ epsilon. D1 and d2 are distance
values and are mixed like sigma. The default mix value is
<em>geometric</em>. See the “pair_modify” command for details.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the Lennard-Jones portion of the pair
interaction; such energy goes to zero at the cutoff by construction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>The <em>lj/cut/dipole/cut</em>, <em>lj/cut/dipole/long</em>, and
<em>lj/long/dipole/long</em> styles are part of the DIPOLE package. They are
only enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The <em>lj/sf/dipole/sf</em> style is part of the USER-MISC package. It is
only enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Using dipole pair styles with <em>electron</em> <a class="reference internal" href="units.html"><span class="doc">units</span></a> is not
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>Tstart,Tstop = desired temperature at start/end of run (temperature units)</li>
<li>cutoff = global cutoff for DPD interactions (distance units)</li>
<li>seed = random # seed (positive integer)</li>
</ul>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
pair_style dpd 1.0 2.5 34387
pair_coeff * * 3.0 1.0
pair_coeff 1 1 3.0 1.0 1.0
</pre>
<pre class="literal-block">
pair_style dpd/tstat 1.0 1.0 2.5 34387
pair_coeff * * 1.0
pair_coeff 1 1 1.0 1.0
</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<li>style = <em>eam</em> or <em>eam/alloy</em> or <em>eam/cd</em> or <em>eam/fs</em></li>
</ul>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
pair_style eam
pair_coeff * * cuu3
pair_coeff 1*3 1*3 niu3.eam
</pre>
<pre class="literal-block">
pair_style eam/alloy
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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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 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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
<pre class="literal-block">
compute gauss all pair gauss
variable occ equal c_gauss[1]
thermo_style custom step temp epair v_occ
</pre>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>In both equations the first parenthesized term is the normal force
between the two particles and the second parenthesized term is the
tangential force. The normal force has 2 terms, a contact force and a
damping force. The tangential force also has 2 terms: a shear force
and a damping force. The shear force is a “history” effect that
accounts for the tangential displacement between the particles for the
duration of the time they are in contact. This term is included in
pair styles <em>hooke/history</em> and <em>hertz/history</em>, but is not included
in pair style <em>hooke</em>. The tangential damping force term is included
in all three pair styles if <em>dampflag</em> is set to 1; it is not included
if <em>dampflag</em> is set to 0.</p>
<p>The other quantities in the equations are as follows:</p>
<ul class="simple">
<li>delta = d - r = overlap distance of 2 particles</li>
<li>Kn = elastic constant for normal contact</li>
<li>Kt = elastic constant for tangential contact</li>
<li>gamma_n = viscoelastic damping constant for normal contact</li>
<li>gamma_t = viscoelastic damping constant for tangential contact</li>
<li>m_eff = Mi Mj / (Mi + Mj) = effective mass of 2 particles of mass Mi and Mj</li>
<li>Delta St = tangential displacement vector between 2 particles which is truncated to satisfy a frictional yield criterion</li>
<li>n_ij = unit vector along the line connecting the centers of the 2 particles</li>
<li>Vn = normal component of the relative velocity of the 2 particles</li>
<li>Vt = tangential component of the relative velocity of the 2 particles</li>
</ul>
<p>The Kn, Kt, gamma_n, and gamma_t coefficients are specified as
parameters to the pair_style command. If a NULL is used for Kt, then
a default value is used where Kt = 2/7 Kn. If a NULL is used for
gamma_t, then a default value is used where gamma_t = 1/2 gamma_n.</p>
<p>The interpretation and units for these 4 coefficients are different in
the Hookean versus Hertzian equations.</p>
<p>The Hookean model is one where the normal push-back force for two
overlapping particles is a linear function of the overlap distance.
Thus the specified Kn is in units of (force/distance). Note that this
push-back force is independent of absolute particle size (in the
monodisperse case) and of the relative sizes of the two particles (in
the polydisperse case). This model also applies to the other terms in
the force equation so that the specified gamma_n is in units of
(1/time), Kt is in units of (force/distance), and gamma_t is in units
of (1/time).</p>
<p>The Hertzian model is one where the normal push-back force for two
overlapping particles is proportional to the area of overlap of the
two particles, and is thus a non-linear function of overlap distance.
Thus Kn has units of force per area and is thus specified in units of
(pressure). The effects of absolute particle size (monodispersity)
and relative size (polydispersity) are captured in the radii-dependent
pre-factors. When these pre-factors are carried through to the other
terms in the force equation it means that the specified gamma_n is in
units of (1/(time*distance)), Kt is in units of (pressure), and
gamma_t is in units of (1/(time*distance)).</p>
<p>Note that in the Hookean case, Kn can be thought of as a linear spring
constant with units of force/distance. In the Hertzian case, Kn is
like a non-linear spring constant with units of force/area or
pressure, and as shown in the <a class="reference internal" href="#zhang"><span class="std std-ref">(Zhang)</span></a> paper, Kn = 4G /
(3(1-nu)) where nu = the Poisson ratio, G = shear modulus = E /
(2(1+nu)), and E = Young’s modulus. Similarly, Kt = 4G / (2-nu).
(NOTE: in an earlier version of the manual, we incorrectly stated that
Kt = 8G / (2-nu).)</p>
<p>Thus in the Hertzian case Kn and Kt can be set to values that
corresponds to properties of the material being modeled. This is also
true in the Hookean case, except that a spring constant must be chosen
that is appropriate for the absolute size of particles in the model.
Since relative particle sizes are not accounted for, the Hookean
styles may not be a suitable model for polydisperse systems.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">In versions of LAMMPS before 9Jan09, the equation for Hertzian
interactions did not include the sqrt(RiRj/Ri+Rj) term and thus was
not as accurate for polydisperse systems. For monodisperse systems,
sqrt(RiRj/Ri+Rj) is a constant factor that effectively scales all 4
coefficients: Kn, Kt, gamma_n, gamma_t. Thus you can set the values
of these 4 coefficients appropriately in the current code to reproduce
the results of a previous Hertzian monodisperse calculation. For
example, for the common case of a monodisperse system with particles
of diameter 1, all 4 of these coefficients should now be set 2x larger
than they were previously.</p>
</div>
<p>Xmu is also specified in the pair_style command and is the upper limit
of the tangential force through the Coulomb criterion Ft = xmu*Fn,
where Ft and Fn are the total tangential and normal force components
in the formulas above. Thus in the Hookean case, the tangential force
between 2 particles grows according to a tangential spring and
dash-pot model until Ft/Fn = xmu and is then held at Ft = Fn*xmu until
the particles lose contact. In the Hertzian case, a similar analogy
holds, though the spring is no longer linear.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Normally, xmu should be specified as a fractional value between
0.0 and 1.0, however LAMMPS allows large values (up to 1.0e4) to allow
for modeling of systems which can sustain very large tangential
forces.</p>
</div>
<p>The effective mass <em>m_eff</em> is given by the formula above for two
isolated particles. If either particle is part of a rigid body, its
mass is replaced by the mass of the rigid body in the formula above.
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>For granular styles there are no additional coefficients to set for
each pair of atom types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command.
All settings are global and are made via the pair_style command.
However you must still use the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> for all
pairs of granular atom types. For example the command</p>
<pre class="literal-block">
pair_coeff * *
</pre>
<p>should be used if all atoms in the simulation interact via a granular
potential (i.e. one of the pair styles above is used). If a granular
potential is used as a sub-style of <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid</span></a>, then specific atom types can be used in the
pair_coeff command to determine which atoms interact via a granular
potential.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>These pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so a pair_style command does not need to be
specified in an input script that reads a restart file.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
<p>The single() function of these pair styles returns 0.0 for the energy
of a pairwise interaction, since energy is not conserved in these
dissipative potentials. It also returns only the normal component of
the pairwise interaction force. However, the single() function also
calculates 10 extra pairwise quantities. The first 3 are the
components of the tangential force between particles I and J, acting
on particle I. The 4th is the magnitude of this tangential force.
The next 3 (5-7) are the components of the relative velocity in the
normal direction (along the line joining the 2 sphere centers). The
last 3 (8-10) the components of the relative velocity in the
tangential direction.</p>
<p>These extra quantites can be accessed by the <a class="reference internal" href="compute_pair_local.html"><span class="doc">compute pair/local</span></a> command, as <em>p1</em>, <em>p2</em>, ...,
<em>p10</em>.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>All the granular pair styles are part of the GRANULAR package. It is
only enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>These pair styles require that atoms store torque and angular velocity
(omega) as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a>. They also
require a per-particle radius is stored. The <em>sphere</em> atom style does
all of this.</p>
<p>This pair style requires you to use the <a class="reference internal" href="comm_modify.html"><span class="doc">comm_modify vel yes</span></a> command so that velocites are stored by ghost
atoms.</p>
<p>These pair styles will not restart exactly when using the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command, though they should provide
statistically similar results. This is because the forces they
compute depend on atom velocities. See the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for more details.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum at 2^(1/6)
sigma.</p>
<p>The last 2 coefficients are optional inner and outer cutoffs for style
<em>lj/gromacs</em>. If not specified, the global <em>inner</em> and <em>outer</em> values
are used.</p>
<p>The last 2 coefficients cannot be used with style
<em>lj/gromacs/coul/gromacs</em> because this force field does not allow
varying cutoffs for individual atom pairs; all pairs use the global
cutoff(s) specified in the pair_style command.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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 “*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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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 lj/cut/coul/long special lj 0.0 0.0 0.5
pair_modify pair lj/cut/coul/long special coul 0.0 0.0 0.83333333
pair_modify pair lj/charmm/coul/long special lj/coul 0.0 0.0 0.0
</pre>
<p>Here is an example for mixing Tersoff with OPLS/AA based on
a data file that defines bonds for all atoms where for the
Tersoff part of the system the force constants for the bonded
interactions have been set to 0. Note the global settings are
effectively <em>lj/coul 0.0 0.0 0.5</em> as required for OPLS/AA:</p>
<pre class="literal-block">
special_bonds lj/coul 1e-20 1e-20 0.5
pair_hybrid tersoff lj/cut/coul/long 12.0
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 “* *” 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
sequences would implement that model:</p>
<pre class="literal-block">
pair_style hybrid tersoff
pair_coeff * * tersoff SiC.tersoff C C
pair_coeff 1 2 none
</pre>
<pre class="literal-block">
pair_style tersoff
pair_coeff * * SiC.tersoff C C
neigh_modify exclude type 1 2
</pre>
<p>Either way, only neighbor lists with 1-1 or 2-2 interactions would be
passed to the Tersoff potential, which means it would compute no
3-body interactions containing both type 1 and 2 atoms.</p>
<p>Here is another example, using hybrid/overlay, to use 2 many-body
potentials together, in an overlapping manner. Imagine you have CNT
(C atoms) on a Si surface. You want to use Tersoff for Si/Si and Si/C
interactions, and AIREBO for C/C interactions. Si atoms are type 1; C
atoms are type 2. Something like this will work:</p>
<pre class="literal-block">
pair_style hybrid/overlay tersoff airebo 3.0
pair_coeff * * tersoff SiC.tersoff.custom Si C
pair_coeff * * airebo CH.airebo NULL C
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>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>where rho_i is the density at atom I, theta_jik is the angle between
atoms J, I, and K centered on atom I. The five functions Phi, U, rho,
f, and g are represented by cubic splines.</p>
<p>The cutoffs and the coefficients for these spline functions are listed
in a parameter file which is specified by the
<a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command. Parameter files for different
elements are included in the “potentials” directory of the LAMMPS
distribution and have a ”.meam.spline” file suffix. All of these
files are parameterized in terms of LAMMPS <a class="reference internal" href="units.html"><span class="doc">metal units</span></a>.</p>
<p>Note that unlike for other potentials, cutoffs for spline-based MEAM
potentials are not set in the pair_style or pair_coeff command; they
are specified in the potential files themselves.</p>
<p>Unlike the EAM pair style, which retrieves the atomic mass from the
potential file, the spline-based MEAM potentials do not include mass
information; thus you need to use the <a class="reference internal" href="mass.html"><span class="doc">mass</span></a> command to
specify it.</p>
<p>Only a single pair_coeff command is used with the <em>meam/spline</em> style
which specifies a potential file with parameters for all needed
elements. These are mapped to LAMMPS atom types by specifying N
additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:</p>
<ul class="simple">
<li>filename</li>
<li>N element names = mapping of spline-based MEAM elements to atom types</li>
</ul>
<p>See the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> doc page for alternate ways
to specify the path for the potential file.</p>
<p>As an example, imagine the Ti.meam.spline file has values for Ti. If
your LAMMPS simulation has 3 atoms types and they are all to be
treated with this potentials, you would use the following pair_coeff
command:</p>
<pre class="literal-block">
pair_coeff * * Ti.meam.spline Ti Ti Ti
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>where <em>theta_0</em> is the equilibrium value of the angle and <em>K</em> is a
prefactor. Note that the usual 1/2 factor is included in <em>K</em>. The form
of the potential is identical to that used in angle_style <em>harmonic</em>,
but in this case, the atoms do not need to be explicitly bonded.</p>
<p>Only a single pair_coeff command is used with this style which
specifies a potential file with parameters for specified elements.
These are mapped to LAMMPS atom types by specifying N additional
arguments after the filename in the pair_coeff command, where N is the
number of LAMMPS atom types:</p>
<ul class="simple">
<li>filename</li>
<li>N element names = mapping of elements to atom types</li>
</ul>
<p>See the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> doc page for alternate ways
to specify the path for the potential file.</p>
<p>As an example, imagine a file SiC.nb3b.harmonic has potential values
for Si and C. If your LAMMPS simulation has 4 atoms 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>
<pre class="literal-block">
pair_coeff * * SiC.nb3b.harmonic Si Si Si C
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<li>zero or more keyword/value pairs may be appended</li>
</ul>
<pre class="literal-block">
keyword = <em>checkqeq</em> or <em>lgvdw</em> or <em>safezone</em> or <em>mincap</em>
<em>checkqeq</em> value = <em>yes</em> or <em>no</em> = whether or not to require qeq/reax fix
<em>lgvdw</em> value = <em>yes</em> or <em>no</em> = whether or not to use a low gradient vdW correction
<em>safezone</em> = factor used for array allocation
<em>mincap</em> = minimum size for array allocation
</pre>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
pair_style reax/c NULL
pair_style reax/c controlfile checkqeq no
pair_style reax/c NULL lgvdw yes
pair_style reax/c NULL safezone 1.6 mincap 100
pair_coeff * * ffield.reax C H O N
</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<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,
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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<li>cutoff = global cutoff for interactions (distance units)</li>
</ul>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
pair_style resquared 10.0
pair_coeff * * 1.0 1.0 1.7 3.4 3.4 1.0 1.0 1.0
</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<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>.
-<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>.
<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>The last coefficient is optional. If not specified, the global soft
cutoff is used.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The syntax for <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> with a single A
coeff is different in the current version of LAMMPS than in older
versions which took two values, Astart and Astop, to ramp between
them. This functionality is now available in a more general form
through the <a class="reference internal" href="fix_adapt.html"><span class="doc">fix adapt</span></a> command, as explained below.
Note that if you use an old input script and specify Astart and Astop
without a cutoff, then LAMMPS will interpret that as A and a cutoff,
which is probabably not what you want.</p>
</div>
<p>The <a class="reference internal" href="fix_adapt.html"><span class="doc">fix adapt</span></a> command can be used to vary A for one
or more pair types over the course of a simulation, in which case
pair_coeff settings for A must still be specified, but will be
overridden. For example these commands will vary the prefactor A for
all pairwise interactions from 0.0 at the beginning to 30.0 at the end
of a run:</p>
<pre class="literal-block">
variable prefactor equal ramp(0,30)
fix 1 all adapt 1 pair soft a * * v_prefactor
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>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>.
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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<li>style = <em>lookup</em> or <em>linear</em> or <em>spline</em> or <em>bitmap</em> = method of interpolation</li>
<li>N = use N values in <em>lookup</em>, <em>linear</em>, <em>spline</em> tables</li>
<li>N = use 2^N values in <em>bitmap</em> tables</li>
<li>zero or more keywords may be appended</li>
<li>keyword = <em>ewald</em> or <em>pppm</em> or <em>msm</em> or <em>dispersion</em> or <em>tip4p</em></li>
</ul>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
pair_style table linear 1000
pair_style table linear 1000 pppm
pair_style table bitmap 12
pair_coeff * 3 morse.table ENTRY1
pair_coeff * 3 morse.table ENTRY1 7.0
</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>Style <em>table</em> creates interpolation tables from potential energy and
force values listed in a file(s) as a function of distance. When
performing dynamics or minimation, the interpolation tables are used
to evaluate energy and forces for pairwise interactions between
particles, similar to how analytic formulas are used for other pair
styles.</p>
<p>The interpolation tables are created as a pre-computation by fitting
cubic splines to the file values and interpolating energy and force
values at each of <em>N</em> distances. During a simulation, the tables are
used to interpolate energy and force values as needed for each pair of
particles separated by a distance <em>R</em>. The interpolation is done in
one of 4 styles: <em>lookup</em>, <em>linear</em>, <em>spline</em>, or <em>bitmap</em>.</p>
<p>For the <em>lookup</em> style, the distance <em>R</em> is used to find the nearest
table entry, which is the energy or force.</p>
<p>For the <em>linear</em> style, the distance <em>R</em> is used to find the 2
surrounding table values from which an energy or force is computed by
linear interpolation.</p>
<p>For the <em>spline</em> style, a cubic spline coefficients are computed and
stored for each of the <em>N</em> values in the table, one set of splines for
energy, another for force. Note that these splines are different than
the ones used to pre-compute the <em>N</em> values. Those splines were fit
to the <em>Nfile</em> values in the tabulated file, where often <em>Nfile</em> <
<em>N</em>. The distance <em>R</em> is used to find the appropriate set of spline
coefficients which are used to evaluate a cubic polynomial which
computes the energy or force.</p>
<p>For the <em>bitmap</em> style, the specified <em>N</em> is used to create
interpolation tables that are 2^N in length. The distance <em>R</em> is used
to index into the table via a fast bit-mapping technique due to
<a class="reference internal" href="pair_table_rx.html#wolff"><span class="std std-ref">(Wolff)</span></a>, and a linear interpolation is performed between
adjacent table values.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above.</p>
<ul class="simple">
<li>filename</li>
<li>keyword</li>
<li>cutoff (distance units)</li>
</ul>
<p>The filename specifies a file containing tabulated energy and force
values. The keyword specifies a section of the file. The cutoff is
an optional coefficient. If not specified, the outer cutoff in the
table itself (see below) will be used to build an interpolation table
that extend to the largest tabulated distance. If specified, only
file values up to the cutoff are used to create the interpolation
table. The format of this file is described below.</p>
<p>If your tabulated potential(s) are designed to be used as the
short-range part of one of the long-range solvers specified by the
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command, then you must use one or
more of the optional keywords listed above for the pair_style command.
These are <em>ewald</em> or <em>pppm</em> or <em>msm</em> or <em>dispersion</em> or <em>tip4p</em>. This
is so LAMMPS can insure the short-range potential and long-range
solver are compatible with each other, as it does for other
short-range pair styles, such as <a class="reference internal" href="pair_lj.html"><span class="doc">pair_style lj/cut/coul/long</span></a>. Note that it is up to you to insure
the tabulated values for each pair of atom types has the correct
functional form to be compatible with the matching long-range solver.</p>
<hr class="docutils" />
<p>Here are some guidelines for using the pair_style table command to
best effect:</p>
<ul class="simple">
<li>Vary the number of table points; you may need to use more than you think
to get good resolution.</li>
<li>Always use the <a class="reference internal" href="pair_write.html"><span class="doc">pair_write</span></a> command to produce a plot
of what the final interpolated potential looks like. This can show up
interpolation “features” you may not like.</li>
<li>Start with the linear style; it’s the style least likely to have problems.</li>
<li>Use <em>N</em> in the pair_style command equal to the “N” in the tabulation
file, and use the “RSQ” or “BITMAP” parameter, so additional interpolation
is not needed. See discussion below.</li>
<li>Make sure that your tabulated forces and tabulated energies are
consistent (dE/dr = -F) over the entire range of r values. LAMMPS
will warn if this is not the case.</li>
<li>Use as large an inner cutoff as possible. This avoids fitting splines
to very steep parts of the potential.</li>
</ul>
<hr class="docutils" />
<p>The format of a tabulated file is a series of one or more sections,
defined as follows (without the parenthesized comments):</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># Morse potential for Fe (one or more comment or blank lines)</span>
</pre></div>
</div>
<pre class="literal-block">
MORSE_FE (keyword is first text on line)
N 500 R 1.0 10.0 (N, R, RSQ, BITMAP, FPRIME parameters)
(blank)
1 1.0 25.5 102.34 (index, r, energy, force)
2 1.02 23.4 98.5
...
500 10.0 0.001 0.003
</pre>
<p>A section begins with a non-blank line whose 1st character is not a
“#”; blank lines or lines starting with “#” can be used as comments
between sections. The first line begins with a keyword which
identifies the section. The line can contain additional text, but the
initial text must match the argument specified in the pair_coeff
command. The next line lists (in any order) one or more parameters
for the table. Each parameter is a keyword followed by one or more
numeric values.</p>
<p>The parameter “N” is required and its value is the number of table
entries that follow. Note that this may be different than the <em>N</em>
specified in the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style table</span></a> command. Let
Ntable = <em>N</em> in the pair_style command, and Nfile = “N” in the
tabulated file. What LAMMPS does is a preliminary interpolation by
creating splines using the Nfile tabulated values as nodal points. It
uses these to interpolate energy and force values at Ntable different
points. The resulting tables of length Ntable are then used as
described above, when computing energy and force for individual pair
distances. This means that if you want the interpolation tables of
length Ntable to match exactly what is in the tabulated file (with
effectively no preliminary interpolation), you should set Ntable =
Nfile, and use the “RSQ” or “BITMAP” parameter. This is because the
internal table abscissa is always RSQ (separation distance squared),
for efficient lookup.</p>
<p>All other parameters are optional. If “R” or “RSQ” or “BITMAP” does
not appear, then the distances in each line of the table are used
as-is to perform spline interpolation. In this case, the table values
can be spaced in <em>r</em> uniformly or however you wish to position table
values in regions of large gradients.</p>
<p>If used, the parameters “R” or “RSQ” are followed by 2 values <em>rlo</em>
and <em>rhi</em>. If specified, the distance associated with each energy and
force value is computed from these 2 values (at high accuracy), rather
than using the (low-accuracy) value listed in each line of the table.
The distance values in the table file are ignored in this case.
For “R”, distances uniformly spaced between <em>rlo</em> and <em>rhi</em> are
computed; for “RSQ”, squared distances uniformly spaced between
<em>rlo*rlo</em> and <em>rhi*rhi</em> are computed.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you use “R” or “RSQ”, the tabulated distance values in the
file are effectively ignored, and replaced by new values as described
in the previous paragraph. If the distance value in the table is not
very close to the new value (i.e. round-off difference), then you will
be assingning energy/force values to a different distance, which is
probably not what you want. LAMMPS will warn if this is occurring.</p>
</div>
<p>If used, the parameter “BITMAP” is also followed by 2 values <em>rlo</em> and
<em>rhi</em>. These values, along with the “N” value determine the ordering
of the N lines that follow and what distance is associated with each.
This ordering is complex, so it is not documented here, since this
file is typically produced by the <a class="reference internal" href="pair_write.html"><span class="doc">pair_write</span></a> command
with its <em>bitmap</em> option. When the table is in BITMAP format, the “N”
parameter in the file must be equal to 2^M where M is the value
specified in the pair_style command. Also, a cutoff parameter cannot
be used as an optional 3rd argument in the pair_coeff command; the
entire table extent as specified in the file must be used.</p>
<p>If used, the parameter “FPRIME” is followed by 2 values <em>fplo</em> and
<em>fphi</em> which are the derivative of the force at the innermost and
outermost distances listed in the table. These values are needed by
the spline construction routines. If not specified by the “FPRIME”
parameter, they are estimated (less accurately) by the first 2 and
last 2 force values in the table. This parameter is not used by
BITMAP tables.</p>
<p>Following a blank line, the next N lines list the tabulated values.
On each line, the 1st value is the index from 1 to N, the 2nd value is
r (in distance units), the 3rd value is the energy (in energy units),
and the 4th is the force (in force units). The r values must increase
from one line to the next (unless the BITMAP parameter is specified).</p>
<p>Note that one file can contain many sections, each with a tabulated
potential. LAMMPS reads the file section by section until it finds
one that matches the specified keyword.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>style = <em>tersoff</em> or <em>tersoff/table</em> or <em>tersoff/gpu</em> or <em>tersoff/omp</em> or <em>tersoff/table/omp</em></p>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
pair_style tersoff
pair_coeff * * Si.tersoff Si
pair_coeff * * SiC.tersoff Si C Si
</pre>
<pre class="literal-block">
pair_style tersoff/table
pair_coeff * * SiCGe.tersoff Si(D)
</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>Only a single pair_coeff command is used with the <em>tersoff/mod</em> style
which specifies a Tersoff/MOD potential file with parameters for all
needed elements. These are mapped to LAMMPS atom types by specifying
N additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:</p>
<ul class="simple">
<li>filename</li>
<li>N element names = mapping of Tersoff/MOD elements to atom types</li>
</ul>
<p>As an example, imagine the Si.tersoff_mod file has Tersoff values for Si.
If your LAMMPS simulation has 3 Si atoms types, you would use the following
pair_coeff command:</p>
<pre class="literal-block">
pair_coeff * * Si.tersoff_mod Si Si Si
</pre>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
<li>style = <em>thole</em> or <em>lj/cut/thole/long</em> or <em>lj/cut/thole/long/omp</em></li>
<li>args = list of arguments for a particular style</li>
</ul>
<pre class="literal-block">
<em>thole</em> args = damp cutoff
damp = global damping parameter
cutoff = global cutoff (distance units)
<em>lj/cut/thole/long</em> or <em>lj/cut/thole/long/omp</em> args = damp cutoff (cutoff2)
damp = global damping parameter
cutoff = global cutoff for LJ (and Thole if only 1 arg) (distance units)
cutoff2 = global cutoff for Thole (optional) (distance units)
</pre>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
pair_style hybrid/overlay ... thole 2.6 12.0
pair_coeff 1 1 thole 1.0
pair_coeff 1 2 thole 1.0 2.6 10.0
pair_coeff * 2 thole 1.0 2.6
</pre>
<pre class="literal-block">
pair_style lj/cut/thole/long 2.6 12.0
</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
specify parameters for all permutations of the two elements
interacting in three-body configurations. Thus for 3 elements, 27
entries would be required, etc.</p>
<p>Depending on the particular version of the Vashishta potential,
the values of these parameters may be keyed to the identities of
zero, one, two, or three elements.
In order to make the input file format unambiguous, general,
and simple to code,
LAMMPS uses a slightly confusing method for specifying parameters.
All parameters are divided into two classes: two-body and three-body.
Two-body and three-body parameters are handled differently,
as described below.
The two-body parameters are H, eta, lambda1, D, lambda4, W, rc, gamma, and r0.
They appear in the above formulae with two subscripts.
The parameters Zi and Zj are also classified as two-body parameters,
even though they only have 1 subscript.
The three-body parameters are B, C, costheta0.
They appear in the above formulae with three subscripts.
Two-body and three-body parameters are handled differently,
as described below.</p>
<p>The first element in each entry is the center atom
in a three-body interaction, while the second and third elements
are two neighbor atoms. Three-body parameters for a central atom I
and two neighbors J and K are taken from the IJK entry.
Note that even though three-body parameters do not depend on the order of
J and K, LAMMPS stores three-body parameters for both IJK and IKJ.
The user must ensure that these values are equal.
Two-body parameters for an atom I interacting with atom J are taken from
the IJJ entry, where the 2nd and 3rd
elements are the same. Thus the two-body parameters
for Si interacting with C come from the SiCC entry. Note that even
though two-body parameters (except possibly gamma and r0 in U3)
do not depend on the order of the two elements,
LAMMPS will get the Si-C value from the SiCC entry
and the C-Si value from the CSiSi entry. The user must ensure
that these values are equal. Two-body parameters appearing
in entries where the 2nd and 3rd elements are different are
stored but never used. It is good practice to enter zero for
these values. Note that the three-body function U3 above
contains the two-body parameters gamma and r0. So U3 for a
central C atom bonded to an Si atom and a second C atom
will take three-body parameters from the CSiC entry, but
two-body parameters from the CCC and CSiSi entries.</p>
<hr class="docutils" />
<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using 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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+switch; see <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">Section 2.7</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
+<a class="reference internal" href="Section_howto.html#howto-5"><span class="std std-ref">Section 6.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
run is as follows:</p>
<pre class="literal-block">
while (time remains):
dephase for n_dephase*t_dephase steps
until (event occurs on some replica):
run dynamics for t_event steps
quench
check for uncorrelated event on any replica
until (no correlated event occurs):
run dynamics for t_correlate steps
quench
check for correlated event on this replica
event replica shares state with all replicas
</pre>
<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>zero or more keyword/arg pairs may be appended</li>
<li>keyword = <em>add</em> or <em>offset</em> or <em>shift</em> or <em>extra/atom/types</em> or <em>extra/bond/types</em> or <em>extra/angle/types</em> or <em>extra/dihedral/types</em> or <em>extra/improper/types</em> or <em>group</em> or <em>nocoeff</em> or <em>fix</em></li>
</ul>
<pre class="literal-block">
<em>add</em> arg = <em>append</em> or <em>Nstart</em> or <em>merge</em>
append = add new atoms with IDs appended to current IDs
Nstart = add new atoms with IDs starting with Nstart
merge = add new atoms with their IDs unchanged
<em>offset</em> args = toff boff aoff doff ioff
toff = offset to add to atom types
boff = offset to add to bond types
aoff = offset to add to angle types
doff = offset to add to dihedral types
ioff = offset to add to improper types
<em>shift</em> args = Sx Sy Sz
Sx,Sy,Sz = distance to shift atoms when adding to system (distance units)
<em>extra/atom/types</em> arg = # of extra atom types
<em>extra/bond/types</em> arg = # of extra bond types
<em>extra/angle/types</em> arg = # of extra angle types
<em>extra/dihedral/types</em> arg = # of extra dihedral types
<em>extra/improper/types</em> arg = # of extra improper types
<p>Read in a data file containing information LAMMPS needs to run a
simulation. The file can be ASCII text or a gzipped text file
(detected by a .gz suffix). This is one of 3 ways to specify initial
atom coordinates; see the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> and
<a class="reference internal" href="create_atoms.html"><span class="doc">create_atoms</span></a> commands for alternative methods.
Also see the explanation of the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-restart command-line switch</span></a> which can convert a restart file to
a data file.</p>
<p>This command can be used multiple times to add new atoms and their
properties to an existing system by using the <em>add</em>, <em>offset</em>, and
<em>shift</em> keywords. See more details below, which includes the use case
for the <em>extra</em> keywords.</p>
<p>The <em>group</em> keyword adds all the atoms in the data file to the
specified group-ID. The group will be created if it does not already
exist. This is useful if you are reading multiple data files and wish
to put sets of atoms into different groups so they can be operated on
later. E.g. a group of added atoms can be moved to new positions via
the <a class="reference internal" href="displace_atoms.html"><span class="doc">displace_atoms</span></a> command. Note that atoms
read from the data file are also always added to the “all” group. The
<a class="reference internal" href="group.html"><span class="doc">group</span></a> command discusses atom groups, as used in LAMMPS.</p>
<p>The <em>nocoeff</em> keyword tells read_data to ignore force field parameters.
The various Coeff sections are still read and have to have the correct
number of lines, but they are not applied. This also allows to read a
data file without having any pair, bond, angle, dihedral or improper
styles defined, or to read a data file for a different force field.</p>
<p>The use of the <em>fix</em> keyword is discussed below.</p>
<hr class="docutils" />
<p><strong>Reading multiple data files</strong></p>
<p>The read_data command can be used multiple times with the same or
different data files to build up a complex system from components
contained in individual data files. For example one data file could
contain fluid in a confined domain; a second could contain wall atoms,
and the second file could be read a third time to create a wall on the
other side of the fluid. The third set of atoms could be rotated to
an opposing direction using the <a class="reference internal" href="displace_atoms.html"><span class="doc">displace_atoms</span></a>
command, after the third read_data command is used.</p>
<p>The <em>add</em>, <em>offset</em>, <em>shift</em>, <em>extra</em>, and <em>group</em> keywords are
useful in this context.</p>
<p>If a simulation box does not yet exist, the <em>add</em> keyword
cannot be used; the read_data command is being used for the first
time. If a simulation box does exist, due to using the
<a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> command, or a previous read_data command,
then the <em>add</em> keyword must be used.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The simulation box size (xlo to xhi, ylo to yhi, zlo to zhi) in
the new data file will be merged with the existing simulation box to
create a large enough box in each dimension to contain both the
existing and new atoms. Each box dimension never shrinks due to this
merge operation, it only stays the same or grows. Care must be used if
you are growing the existing simulation box in a periodic dimension.
If there are existing atoms with bonds that straddle that periodic
boundary, then the atoms may become far apart if the box size grows.
This will separate the atoms in the bond, which can lead to “lost”
bond atoms or bad dynamics.</p>
</div>
<p>The three choices for the <em>add</em> argument affect how the IDs of atoms
in the data file are treated. If <em>append</em> is specified, atoms in the
data file are added to the current system, with their atom IDs reset
so that an atomID = M in the data file becomes atomID = N+M, where N
is the largest atom ID in the current system. This rule is applied to
all occurrences of atom IDs in the data file, e.g. in the Velocity or
Bonds section. If <em>Nstart</em> is specified, then <em>Nstart</em> is a numeric
value is given, e.g. 1000, so that an atomID = M in the data file
becomes atomID = 1000+M. If <em>merge</em> is specified, the data file atoms
are added to the current system without changing their IDs. They are
assumed to merge (without duplication) with the currently defined
atoms. It is up to you to insure there are no multiply defined atom
IDs, as LAMMPS only performs an incomplete check that this is the case
by insuring the resulting max atomID >= the number of atoms.</p>
<p>The <em>offset</em> and <em>shift</em> keywords can only be used if the <em>add</em>
keyword is also specified.</p>
<p>The <em>offset</em> keyword adds the specified offset values to the atom
types, bond types, angle types, dihedral types, and improper types as
they are read from the data file. E.g. if <em>toff</em> = 2, and the file
uses atom types 1,2,3, then the added atoms will have atom types
3,4,5. These offsets apply to all occurrences of types in the data
file, e.g. for the Atoms or Masses or Pair Coeffs or Bond Coeffs
sections. This makes it easy to use atoms and molecules and their
attributes from a data file in different simulations, where you want
their types (atom, bond, angle, etc) to be different depending on what
other types already exist. All five offset values must be specified,
but individual values will be ignored if the data file does not use
that attribute (e.g. no bonds).</p>
<p>The <em>shift</em> keyword can be used to specify an (Sx, Sy, Sz)
displacement applied to the coordinates of each atom. Sz must be 0.0
for a 2d simulation. This is a mechanism for adding structured
collections of atoms at different locations within the simulation box,
to build up a complex geometry. It is up to you to insure atoms do
not end up overlapping unphysically which would lead to bad dynamics.
Note that the <a class="reference internal" href="displace_atoms.html"><span class="doc">displace_atoms</span></a> command can be used
to move a subset of atoms after they have been read from a data file.
Likewise, the <a class="reference internal" href="delete_atoms.html"><span class="doc">delete_atoms</span></a> command can be used to
remove overlapping atoms. Note that the shift values (Sx, Sy, Sz) are
also added to the simulation box information (xlo, xhi, ylo, yhi, zlo,
zhi) in the data file to shift its boundaries. E.g. xlo_new = xlo +
Sx, xhi_new = xhi + Sx.</p>
<p>The <em>extra</em> keywords can only be used the first time the read_data
command is used. They are useful if you intend to add new atom, bond,
angle, etc types later with additional read_data commands. This is
because the maximum number of allowed atom, bond, angle, etc types is
set by LAMMPS when the system is first initialized. If you do not use
the <em>extra</em> keywords, then the number of these types will be limited
to what appears in the first data file you read. For example, if the
first data file is a solid substrate of Si, it will likely specify a
single atom type. If you read a second data file with a different
material (water molecules) that sit on top of the substrate, you will
want to use different atom types for those atoms. You can only do
this if you set the <em>extra/atom/types</em> keyword to a sufficiently large
value when reading the substrate data file. Note that use of the
<em>extra</em> keywords also allows each data file to contain sections like
Masses or Pair Coeffs or Bond Coeffs which are sized appropriately for
the number of types in that data file. If the <em>offset</em> keyword is
used appropriately when each data file is read, the values in those
sections will be stored correctly in the larger data structures
allocated by the use of the <em>extra</em> keywords. E.g. the substrate file
can list mass and pair coefficients for type 1 silicon atoms. The
water file can list mass and pair coeffcients for type 1 and type 2
hydrogen and oxygen atoms. Use of the <em>extra</em> and <em>offset</em> keywords
will store those mass and pair coefficient values appropriately in
data structures that allow for 3 atom types (Si, H, O). Of course,
you would still need to specify coefficients for H/Si and O/Si
interactions in your input script to have a complete pairwise
interaction model.</p>
<p>An alternative to using the <em>extra</em> keywords with the read_data
command, is to use the <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> command to
initialize the simulation box and all the various type limits you need
via its <em>extra</em> keywords. Then use the read_data command one or more
times to populate the system with atoms, bonds, angles, etc, using the
<em>offset</em> keyword if desired to alter types used in the various data
files you read.</p>
<hr class="docutils" />
<p><strong>Format of a data file</strong></p>
<p>The structure of the data file is important, though many settings and
sections are optional or can come in any order. See the examples
directory for sample data files for different problems.</p>
<p>A data file has a header and a body. The header appears first. The
first line of the header is always skipped; it typically contains a
description of the file. Then lines are read one at a time. Lines
can have a trailing comment starting with ‘#’ that is ignored. If the
line is blank (only whitespace after comment is deleted), it is
skipped. If the line contains a header keyword, the corresponding
value(s) is read from the line. If it doesn’t contain a header
keyword, the line begins the body of the file.</p>
<p>The body of the file contains zero or more sections. The first line
of a section has only a keyword. This line can have a trailing
comment starting with ‘#’ that is either ignored or can be used to
check for a style match, as described below. The next line is
skipped. The remaining lines of the section contain values. The
number of lines depends on the section keyword as described below.
Zero or more blank lines can be used between sections. Sections can
appear in any order, with a few exceptions as noted below.</p>
<p>The keyword <em>fix</em> can be used one or more times. Each usage specifies
a fix that will be used to process a specific portion of the data
file. Any header line containing <em>header-string</em> and any section with
a name containing <em>section-string</em> will be passed to the specified
fix. See the <a class="reference internal" href="fix_property_atom.html"><span class="doc">fix property/atom</span></a> command for
an example of a fix that operates in this manner. The doc page for
the fix defines the syntax of the header line(s) and section(s) that
it reads from the data file. Note that the <em>header-string</em> can be
specified as NULL, in which case no header lines are passed to the
fix. This means that it can infer the length of its Section from
standard header settings, such as the number of atoms.</p>
<p>The formatting of individual lines in the data file (indentation,
spacing between words and numbers) is not important except that header
and section keywords (e.g. atoms, xlo xhi, Masses, Bond Coeffs) must
be capitalized as shown and can’t have extra white space between their
words - e.g. two spaces or a tab between the 2 words in “xlo xhi” or
the 2 words in “Bond Coeffs”, is not valid.</p>
<hr class="docutils" />
<p><strong>Format of the header of a data file</strong></p>
<p>These are the recognized header keywords. Header lines can come in
any order. The value(s) are read from the beginning of the line.
Thus the keyword <em>atoms</em> should be in a line like “1000 atoms”; the
keyword <em>ylo yhi</em> should be in a line like “-10.0 10.0 ylo yhi”; the
keyword <em>xy xz yz</em> should be in a line like “0.0 5.0 6.0 xy xz yz”.
All these settings have a default value of 0, except the lo/hi box
size defaults are -0.5 and 0.5. A line need only appear if the value
is different than the default.</p>
<ul class="simple">
<li><em>atoms</em> = # of atoms in system</li>
<li><em>bonds</em> = # of bonds in system</li>
<li><em>angles</em> = # of angles in system</li>
<li><em>dihedrals</em> = # of dihedrals in system</li>
<li><em>impropers</em> = # of impropers in system</li>
<li><em>atom types</em> = # of atom types in system</li>
<li><em>bond types</em> = # of bond types in system</li>
<li><em>angle types</em> = # of angle types in system</li>
<li><em>dihedral types</em> = # of dihedral types in system</li>
<li><em>improper types</em> = # of improper types in system</li>
<li><em>extra bond per atom</em> = leave space for this many new bonds per atom</li>
<li><em>extra angle per atom</em> = leave space for this many new angles per atom</li>
<li><em>extra dihedral per atom</em> = leave space for this many new dihedrals per atom</li>
<li><em>extra improper per atom</em> = leave space for this many new impropers per atom</li>
<li><em>extra special per atom</em> = leave space for this many new special bonds per atom</li>
<li><em>ellipsoids</em> = # of ellipsoids in system</li>
<li><em>lines</em> = # of line segments in system</li>
<li><em>triangles</em> = # of triangles in system</li>
<li><em>bodies</em> = # of bodies in system</li>
<li><em>xlo xhi</em> = simulation box boundaries in x dimension</li>
<li><em>ylo yhi</em> = simulation box boundaries in y dimension</li>
<li><em>zlo zhi</em> = simulation box boundaries in z dimension</li>
<p>If the <em>xy xz yz</em> line does not appear, LAMMPS will set up an
axis-aligned (orthogonal) simulation box. If the line does appear,
LAMMPS creates a non-orthogonal simulation domain shaped as a
parallelepiped with triclinic symmetry. The parallelepiped has its
“origin” at (xlo,ylo,zlo) and is defined by 3 edge vectors starting
from the origin given by A = (xhi-xlo,0,0); B = (xy,yhi-ylo,0); C =
(xz,yz,zhi-zlo). <em>Xy,xz,yz</em> can be 0.0 or positive or negative values
and are called “tilt factors” because they are the amount of
displacement applied to faces of an originally orthogonal box to
transform it into the parallelepiped.</p>
<p>By default, the tilt factors (xy,xz,yz) can not skew the box more than
half the distance of the corresponding parallel box length. For
example, if xlo = 2 and xhi = 12, then the x box length is 10 and the
xy tilt factor must be between -5 and 5. Similarly, both xz and yz
must be between -(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is not
a limitation, since if the maximum tilt factor is 5 (as in this
example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
... are all geometrically equivalent. If you wish to define a box
with tilt factors that exceed these limits, you can use the <a class="reference internal" href="box.html"><span class="doc">box tilt</span></a> command, with a setting of <em>large</em>; a setting of
<em>small</em> is the default.</p>
-<p>See <a class="reference internal" href="Section_howto.html#howto-12"><span class="std std-ref">Section_howto 12</span></a> of the doc pages
+<p>See <a class="reference internal" href="Section_howto.html#howto-12"><span class="std std-ref">Section 6.12</span></a> of the doc pages
for a geometric description of triclinic boxes, as defined by LAMMPS,
and how to transform these parameters to and from other commonly used
triclinic representations.</p>
<p>When a triclinic system is used, the simulation domain should normally
be periodic in the dimension that the tilt is applied to, which is
given by the second dimension of the tilt factor (e.g. y for xy tilt).
This is so that pairs of atoms interacting across that boundary will
have one of them shifted by the tilt factor. Periodicity is set by
the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command. For example, if the xy tilt
factor is non-zero, then the y dimension should be periodic.
Similarly, the z dimension should be periodic if xz or yz is non-zero.
LAMMPS does not require this periodicity, but you may lose atoms if
this is not the case.</p>
<p>Also note that if your simulation will tilt the box, e.g. via the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> command, the simulation box must be setup to
be triclinic, even if the tilt factors are initially 0.0. You can
also change an orthogonal box to a triclinic box or vice versa by
using the <a class="reference internal" href="change_box.html"><span class="doc">change box</span></a> command with its <em>ortho</em> and
<em>triclinic</em> options.</p>
<p>For 2d simulations, the <em>zlo zhi</em> values should be set to bound the z
coords for atoms that appear in the file; the default of -0.5 0.5 is
valid if all z coords are 0.0. For 2d triclinic simulations, the xz
and yz tilt factors must be 0.0.</p>
<p>If the system is periodic (in a dimension), then atom coordinates can
be outside the bounds (in that dimension); they will be remapped (in a
periodic sense) back inside the box. Note that if the <em>add</em> option is
being used to add atoms to a simulation box that already exists, this
periodic remapping will be performed using simulation box bounds that
are the union of the existing box and the box boundaries in the new
data file.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If the system is non-periodic (in a dimension), then all atoms
in the data file must have coordinates (in that dimension) that are
“greater than or equal to” the lo value and “less than or equal to”
the hi value. If the non-periodic dimension is of style “fixed” (see
the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command), then the atom coords must be
strictly “less than” the hi value, due to the way LAMMPS assign atoms
to processors. Note that you should not make the lo/hi values
radically smaller/larger than the extent of the atoms. For example,
if your atoms extend from 0 to 50, you should not specify the box
bounds as -10000 and 10000. This is because LAMMPS uses the specified
box size to layout the 3d grid of processors. A huge (mostly empty)
box will be sub-optimal for performance when using “fixed” boundary
conditions (see the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command). When using
“shrink-wrap” boundary conditions (see the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a>
command), a huge (mostly empty) box may cause a parallel simulation to
lose atoms when LAMMPS shrink-wraps the box around the atoms. The
read_data command will generate an error in this case.</p>
</div>
<p>The “extra bond per atom” setting (angle, dihedral, improper) is only
needed if new bonds (angles, dihedrals, impropers) will be added to
the system when a simulation runs, e.g. by using the <a class="reference internal" href="fix_bond_create.html"><span class="doc">fix bond/create</span></a> command. This will pre-allocate
space in LAMMPS data structures for storing the new bonds (angles,
dihedrals, impropers).</p>
<p>The “extra special per atom” setting is typically only needed if new
bonds/angles/etc will be added to the system, e.g. by using the <a class="reference internal" href="fix_bond_create.html"><span class="doc">fix bond/create</span></a> command. Or if entire new molecules
will be added to the system, e.g. by using the <a class="reference internal" href="fix_deposit.html"><span class="doc">fix deposit</span></a> or <a class="reference internal" href="fix_pour.html"><span class="doc">fix pour</span></a> commands, which
will have more special 1-2,1-3,1-4 neighbors than any other molecules
defined in the data file. Using this setting will pre-allocate space
in the LAMMPS data structures for storing these neighbors. See the
pages for more discussion of 1-2,1-3,1-4 neighbors.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">All of the “extra” settings are only used if they appear in the
first data file read; see the description of the <em>add</em> keyword above
for reading multiple data files. If they appear in later data files,
they are ignored.</p>
</div>
<p>The “ellipsoids” and “lines” and “triangles” and “bodies” settings are
only used with <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid or line or tri or body</span></a> and specify how many of the atoms are
finite-size ellipsoids or lines or triangles or bodies; the remainder
are point particles. See the discussion of ellipsoidflag and the
<em>Ellipsoids</em> section below. See the discussion of lineflag and the
<em>Lines</em> section below. See the discussion of triangleflag and the
<em>Triangles</em> section below. See the discussion of bodyflag and the
<em>Bodies</em> section below.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For <a class="reference internal" href="atom_style.html"><span class="doc">atom_style template</span></a>, the molecular
topology (bonds,angles,etc) is contained in the molecule templates
read-in by the <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command. This means you
cannot set the <em>bonds</em>, <em>angles</em>, etc header keywords in the data
file, nor can you define <em>Bonds</em>, <em>Angles</em>, etc sections as discussed
below. You can set the <em>bond types</em>, <em>angle types</em>, etc header
keywords, though it is not necessary. If specified, they must match
the maximum values defined in any of the template molecules.</p>
</div>
<hr class="docutils" />
<p><strong>Format of the body of a data file</strong></p>
<p>These are the section keywords for the body of the file.</p>
<p>Atom lines specify the (x,y,z) coordinates of atoms. These can be
inside or outside the simulation box. When the data file is read,
LAMMPS wraps coordinates outside the box back into the box for
dimensions that are periodic. As discussed above, if an atom is
outside the box in a non-periodic dimension, it will be lost.</p>
<p>LAMMPS always stores atom coordinates as values which are inside the
simulation box. It also stores 3 flags which indicate which image of
the simulation box (in each dimension) the atom would be in if its
coordinates were unwrapped across periodic boundaries. An image flag
of 0 means the atom is still inside the box when unwrapped. A value
of 2 means add 2 box lengths to get the unwrapped coordinate. A value
of -1 means subtract 1 box length to get the unwrapped coordinate.
LAMMPS updates these flags as atoms cross periodic boundaries during
the simulation. The <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command can output atom atom
coordinates in wrapped or unwrapped form, as well as the 3 image
flags.</p>
<p>In the data file, atom lines (all lines or none of them) can
optionally list 3 trailing integer values (nx,ny,nz), which are used
to initialize the atom’s image flags. If nx,ny,nz values are not
listed in the data file, LAMMPS initializes them to 0. Note that the
image flags are immediately updated if an atom’s coordinates need to
wrapped back into the simulation box.</p>
<p>It is only important to set image flags correctly in a data file if a
simulation model relies on unwrapped coordinates for some calculation;
otherwise they can be left unspecified. Examples of LAMMPS commands
that use unwrapped coordinates internally are as follows:</p>
<ul class="simple">
<li>Atoms in a rigid body (see <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a>, <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid/small</span></a>) must have consistent image flags, so that
when the atoms are unwrapped, they are near each other, i.e. as a
single body.</li>
<li>If the <a class="reference internal" href="replicate.html"><span class="doc">replicate</span></a> command is used to generate a larger
system, image flags must be consistent for bonded atoms when the bond
crosses a periodic boundary. I.e. the values of the image flags
should be different by 1 (in the appropriate dimension) for the two
atoms in such a bond.</li>
<li>If you plan to <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> image flags and perform post-analysis
that will unwrap atom coordinates, it may be important that a
continued run (restarted from a data file) begins with image flags
that are consistent with the previous run.</li>
</ul>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If your system is an infinite periodic crystal with bonds then
it is impossible to have fully consistent image flags. This is because
some bonds will cross periodic boundaries and connect two atoms with the
same image flag.</p>
</div>
<p>Atom velocities and other atom quantities not defined above are set to
0.0 when the <em>Atoms</em> section is read. Velocities can be set later by
a <em>Velocities</em> section in the data file or by a
<a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> or <a class="reference internal" href="set.html"><span class="doc">set</span></a> command in the input
script.</p>
<hr class="docutils" />
<p><em>Bodies</em> section:</p>
<ul class="simple">
<li>one or more lines per body</li>
<li>first line syntax: atom-ID Ninteger Ndouble</li>
</ul>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">Ninteger</span> <span class="o">=</span> <span class="c1"># of integer quantities for this particle</span>
<span class="n">Ndouble</span> <span class="o">=</span> <span class="c1"># of floating-point quantities for this particle</span>
</pre></div>
</div>
<ul class="simple">
<li>0 or more integer lines with total of Ninteger values</li>
<li>0 or more double lines with total of Ndouble values</li>
<p>The <em>Ellipsoids</em> section must appear if <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a> is used and any atoms are listed in the
<em>Atoms</em> section with an ellipsoidflag = 1. The number of ellipsoids
should be specified in the header section via the “ellipsoids”
keyword.</p>
<p>The 3 shape values specify the 3 diameters or aspect ratios of a
finite-size ellipsoidal particle, when it is oriented along the 3
coordinate axes. They must all be non-zero values.</p>
<p>The values <em>quatw</em>, <em>quati</em>, <em>quatj</em>, and <em>quatk</em> set the orientation
of the atom as a quaternion (4-vector). Note that the shape
attributes specify the aspect ratios of an ellipsoidal particle, which
is oriented by default with its x-axis along the simulation box’s
x-axis, and similarly for y and z. If this body is rotated (via the
right-hand rule) by an angle theta around a unit vector (a,b,c), then
the quaternion that represents its new orientation is given by
(cos(theta/2), a*sin(theta/2), b*sin(theta/2), c*sin(theta/2)). These
4 components are quatw, quati, quatj, and quatk as specified above.
LAMMPS normalizes each atom’s quaternion in case (a,b,c) is not
specified as a unit vector.</p>
<p>The <em>Ellipsoids</em> section must appear after the <em>Atoms</em> section.</p>
<hr class="docutils" />
<p><em>EndBondTorsion Coeffs</em> section:</p>
<ul class="simple">
<li>one line per dihedral type</li>
<li>line syntax: ID coeffs</li>
</ul>
<pre class="literal-block">
ID = dihedral type (1-N)
coeffs = list of coeffs (see class 2 section of <a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a>)
<p>The ordering of the 4 atoms determines the definition of the improper
angle used in the formula for each <a class="reference internal" href="improper_style.html"><span class="doc">improper style</span></a>. See the doc pages for individual styles
for details.</p>
<p>The <em>Impropers</em> section must appear after the <em>Atoms</em> section. All
values in this section must be integers (1, not 1.0).</p>
<p>The number and meaning of the coefficients are specific to the defined
pair style. See the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> and
<a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> commands for details. Since pair
coefficients for types I != J are not specified, these will be
generated automatically by the pair style’s mixing rule. See the
individual pair_style doc pages and the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify mix</span></a> command for details. Pair coefficients can also
be set via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command in the input
script.</p>
<hr class="docutils" />
<p><em>PairIJ Coeffs</em> section:</p>
<ul class="simple">
<li>one line per pair of atom types for all I,J with I <= J</li>
<p>This section must have N*(N+1)/2 lines where N = # of atom types. The
number and meaning of the coefficients are specific to the defined
pair style. See the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> and
<a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> commands for details. Since pair
coefficients for types I != J are all specified, these values will
turn off the default mixing rule defined by the pair style. See the
individual pair_style doc pages and the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify mix</span></a> command for details. Pair coefficients can also
be set via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command in the input
<p>The <em>Triangles</em> section must appear if <a class="reference internal" href="atom_style.html"><span class="doc">atom_style tri</span></a> is used and any atoms are listed in the <em>Atoms</em>
section with a triangleflag = 1. The number of lines should be
specified in the header section via the “triangles” keyword.</p>
<p>The 3 corner points are the corner points of the triangle. The
ordering of the 3 points should be such that using a right-hand rule
to go from point1 to point2 to point3 gives an “outward” normal vector
to the face of the triangle. I.e. normal = (c2-c1) x (c3-c1). This
orientation may be important for defining some interactions.</p>
<p>The <em>Triangles</em> section must appear after the <em>Atoms</em> section.</p>
<hr class="docutils" />
<p><em>Velocities</em> section:</p>
<ul class="simple">
<li>one line per atom</li>
<li>line syntax: depends on atom style</li>
</ul>
<table border="1" class="docutils">
<colgroup>
<col width="42%" />
<col width="58%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>all styles except those listed</td>
<p>Translational velocities can also be set by the
<a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> command in the input script.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>To read gzipped data files, you must compile LAMMPS with the
-DLAMMPS_GZIP option - see the <a class="reference internal" href="Section_start.html#start-2"><span class="std std-ref">Making LAMMPS</span></a> section of the documentation.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
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>.
<li>style = <em>delete</em> or <em>block</em> or <em>cone</em> or <em>cylinder</em> or <em>plane</em> or <em>prism</em> or <em>sphere</em> or <em>union</em> or <em>intersect</em></li>
</ul>
<pre class="literal-block">
<em>delete</em> = no args
<em>block</em> args = xlo xhi ylo yhi zlo zhi
xlo,xhi,ylo,yhi,zlo,zhi = bounds of block in all dimensions (distance units)
<em>cone</em> args = dim c1 c2 radlo radhi lo hi
dim = <em>x</em> or <em>y</em> or <em>z</em> = axis of cone
c1,c2 = coords of cone axis in other 2 dimensions (distance units)
radlo,radhi = cone radii at lo and hi end (distance units)
lo,hi = bounds of cone in dim (distance units)
<em>cylinder</em> args = dim c1 c2 radius lo hi
dim = <em>x</em> or <em>y</em> or <em>z</em> = axis of cylinder
c1,c2 = coords of cylinder axis in other 2 dimensions (distance units)
radius = cylinder radius (distance units)
radius can be a variable (see below)
lo,hi = bounds of cylinder in dim (distance units)
<em>plane</em> args = px py pz nx ny nz
px,py,pz = point on the plane (distance units)
nx,ny,nz = direction normal to plane (distance units)
xlo,xhi,ylo,yhi,zlo,zhi = bounds of untilted prism (distance units)
xy = distance to tilt y in x direction (distance units)
xz = distance to tilt z in x direction (distance units)
yz = distance to tilt z in y direction (distance units)
<em>sphere</em> args = x y z radius
x,y,z = center of sphere (distance units)
radius = radius of sphere (distance units)
radius can be a variable (see below)
<em>union</em> args = N reg-ID1 reg-ID2 ...
N = # of regions to follow, must be 2 or greater
reg-ID1,reg-ID2, ... = IDs of regions to join together
<em>intersect</em> args = N reg-ID1 reg-ID2 ...
N = # of regions to follow, must be 2 or greater
reg-ID1,reg-ID2, ... = IDs of regions to intersect
</pre>
<ul class="simple">
<li>zero or more keyword/arg pairs may be appended</li>
<li>keyword = <em>side</em> or <em>units</em> or <em>move</em> or <em>rotate</em></li>
</ul>
<pre class="literal-block">
<em>side</em> value = <em>in</em> or <em>out</em>
<em>in</em> = the region is inside the specified geometry
<em>out</em> = the region is outside the specified geometry
<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
<em>move</em> args = v_x v_y v_z
v_x,v_y,v_z = equal-style variables for x,y,z displacement of region over time
<em>rotate</em> args = v_theta Px Py Pz Rx Ry Rz
v_theta = equal-style variable for rotaton of region over time (in radians)
Px,Py,Pz = origin for axis of rotation (distance units)
Rx,Ry,Rz = axis of rotation vector
</pre>
<ul class="simple">
<li>accelerated styles (with same args) = <em>block/kk</em></li>
</ul>
</div>
<div class="section" id="examples">
<h2>Examples</h2>
<pre class="literal-block">
region 1 block -3.0 5.0 INF 10.0 INF INF
region 2 sphere 0.0 0.0 0.0 5 side out
region void cylinder y 2 3 5 -5.0 EDGE units box
region 1 prism 0 10 0 10 0 10 2 0 0
region outside union 4 side1 side2 side3 side4
region 2 sphere 0.0 0.0 0.0 5 side out move v_left v_up NULL
</pre>
</div>
<div class="section" id="description">
<h2>Description</h2>
<p>This command defines a geometric region of space. Various other
commands use regions. For example, the region can be filled with
atoms via the <a class="reference internal" href="create_atoms.html"><span class="doc">create_atoms</span></a> command. Or a bounding
box around the region, can be used to define the simulation box via
the <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> command. Or the atoms in the region
can be identified as a group via the <a class="reference internal" href="group.html"><span class="doc">group</span></a> command, or
deleted via the <a class="reference internal" href="delete_atoms.html"><span class="doc">delete_atoms</span></a> command. Or the
surface of the region can be used as a boundary wall via the <a class="reference internal" href="fix_wall_region.html"><span class="doc">fix wall/region</span></a> command.</p>
<p>Commands which use regions typically test whether an atom’s position
is contained in the region or not. For this purpose, coordinates
exactly on the region boundary are considered to be interior to the
region. This means, for example, for a spherical region, an atom on
the sphere surface would be part of the region if the sphere were
defined with the <em>side in</em> keyword, but would not be part of the
region if it were defined using the <em>side out</em> keyword. See more
details on the <em>side</em> keyword below.</p>
<p>Normally, regions in LAMMPS are “static”, meaning their geometric
extent does not change with time. If the <em>move</em> or <em>rotate</em> keyword
is used, as described below, the region becomes “dynamic”, meaning
it’s location or orientation changes with time. This may be useful,
for example, when thermostatting a region, via the compute temp/region
command, or when the fix wall/region command uses a region surface as
a bounding wall on particle motion, i.e. a rotating container.</p>
<p>The <em>delete</em> style removes the named region. Since there is little
overhead to defining extra regions, there is normally no need to do
this, unless you are defining and discarding large numbers of regions
in your input script.</p>
<p>The lo/hi values for <em>block</em> or <em>cone</em> or <em>cylinder</em> or <em>prism</em> styles
can be specified as EDGE or INF. EDGE means they extend all the way
to the global simulation box boundary. Note that this is the current
box boundary; if the box changes size during a simulation, the region
does not. INF means a large negative or positive number (1.0e20), so
it should encompass the simulation box even if it changes size. If a
region is defined before the simulation box has been created (via
<a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a> or <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> or
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands), then an EDGE or INF
parameter cannot be used. For a <em>prism</em> region, a non-zero tilt
factor in any pair of dimensions cannot be used if both the lo/hi
values in either of those dimensions are INF. E.g. if the xy tilt is
non-zero, then xlo and xhi cannot both be INF, nor can ylo and yhi.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Regions in LAMMPS do not get wrapped across periodic boundaries,
as specified by the <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> command. For example, a
spherical region that is defined so that it overlaps a periodic
boundary is not treated as 2 half-spheres, one on either side of the
simulation box.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Regions in LAMMPS are always 3d geometric objects, regardless of
whether the <a class="reference internal" href="dimension.html"><span class="doc">dimension</span></a> of a simulation is 2d or 3d.
Thus when using regions in a 2d simulation, you should be careful to
define the region so that its intersection with the 2d x-y plane of
the simulation has the 2d geometric extent you want.</p>
</div>
<p>For style <em>cone</em>, an axis-aligned cone is defined which is like a
<em>cylinder</em> except that two different radii (one at each end) can be
defined. Either of the radii (but not both) can be 0.0.</p>
<p>For style <em>cone</em> and <em>cylinder</em>, the c1,c2 params are coordinates in
the 2 other dimensions besides the cylinder axis dimension. For dim =
x, c1/c2 = y/z; for dim = y, c1/c2 = x/z; for dim = z, c1/c2 = x/y.
Thus the third example above specifies a cylinder with its axis in the
y-direction located at x = 2.0 and z = 3.0, with a radius of 5.0, and
extending in the y-direction from -5.0 to the upper box boundary.</p>
<p>For style <em>plane</em>, a plane is defined which contain the point
(px,py,pz) and has a normal vector (nx,ny,nz). The normal vector does
not have to be of unit length. The “inside” of the plane is the
half-space in the direction of the normal vector; see the discussion
of the <em>side</em> option below.</p>
<p>For style <em>prism</em>, a parallelepiped is defined (it’s too hard to spell
parallelepiped in an input script!). The parallelepiped has its
“origin” at (xlo,ylo,zlo) and is defined by 3 edge vectors starting
from the origin given by A = (xhi-xlo,0,0); B = (xy,yhi-ylo,0); C =
(xz,yz,zhi-zlo). <em>Xy,xz,yz</em> can be 0.0 or positive or negative values
and are called “tilt factors” because they are the amount of
displacement applied to faces of an originally orthogonal box to
transform it into the parallelepiped.</p>
<p>A prism region that will be used with the <a class="reference internal" href="create_box.html"><span class="doc">create_box</span></a>
command to define a triclinic simulation box must have tilt factors
(xy,xz,yz) that do not skew the box more than half the distance of
corresponding the parallel box length. For example, if xlo = 2 and
xhi = 12, then the x box length is 10 and the xy tilt factor must be
between -5 and 5. Similarly, both xz and yz must be between
-(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is not a limitation,
since if the maximum tilt factor is 5 (as in this example), then
configurations with tilt = ..., -15, -5, 5, 15, 25, ... are all
geometrically equivalent.</p>
<p>The <em>radius</em> value for style <em>sphere</em> and <em>cylinder</em> can be specified
as an equal-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>. If the value is a
variable, it should be specified as v_name, where name is the variable
name. In this case, the variable will be evaluated each timestep, and
its value used to determine the radius of the region.</p>
<p>Equal-style variables can specify formulas with various mathematical
functions, and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent radius.</p>
-<p>See <a class="reference internal" href="Section_howto.html#howto-12"><span class="std std-ref">Section_howto 12</span></a> of the doc pages
+<p>See <a class="reference internal" href="Section_howto.html#howto-12"><span class="std std-ref">Section 6.12</span></a> of the doc pages
for a geometric description of triclinic boxes, as defined by LAMMPS,
and how to transform these parameters to and from other commonly used
triclinic representations.</p>
<p>The <em>union</em> style creates a region consisting of the volume of all the
listed regions combined. The <em>intersect</em> style creates a region
consisting of the volume that is common to all the listed regions.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The <em>union</em> and <em>intersect</em> regions operate by invoking methods
from their list of sub-regions. Thus you cannot delete the
sub-regions after defining the <em>union</em> or <em>intersection</em> region.</p>
</div>
<hr class="docutils" />
<p>The <em>side</em> keyword determines whether the region is considered to be
inside or outside of the specified geometry. Using this keyword in
conjunction with <em>union</em> and <em>intersect</em> regions, complex geometries
can be built up. For example, if the interior of two spheres were
each defined as regions, and a <em>union</em> style with <em>side</em> = out was
constructed listing the region-IDs of the 2 spheres, the resulting
region would be all the volume in the simulation box that was outside
both of the spheres.</p>
<p>The <em>units</em> keyword determines the meaning of the distance units used
to define the region for any argument above listed as having distance
units. It also affects the scaling of the velocity vector specfied
with the <em>vel</em> keyword, the amplitude vector specified with the
<em>wiggle</em> keyword, and the rotation point specified with the <em>rotate</em>
keyword, since they each involve a distance metric.</p>
<p>A <em>box</em> value selects standard distance units as defined by the
<a class="reference internal" href="units.html"><span class="doc">units</span></a> command, e.g. Angstroms for units = real or metal.
A <em>lattice</em> value means the distance units are in lattice spacings.
The <a class="reference internal" href="lattice.html"><span class="doc">lattice</span></a> command must have been previously used to
define the lattice spacings which are used as follows:</p>
<ul class="simple">
<li>For style <em>block</em>, the lattice spacing in dimension x is applied to
xlo and xhi, similarly the spacings in dimensions y,z are applied to
ylo/yhi and zlo/zhi.</li>
<li>For style <em>cone</em>, the lattice spacing in argument <em>dim</em> is applied to
lo and hi. The spacings in the two radial dimensions are applied to
c1 and c2. The two cone radii are scaled by the lattice
spacing in the dimension corresponding to c1.</li>
<li>For style <em>cylinder</em>, the lattice spacing in argument <em>dim</em> is applied
to lo and hi. The spacings in the two radial dimensions are applied
to c1 and c2. The cylinder radius is scaled by the lattice
spacing in the dimension corresponding to c1.</li>
<li>For style <em>plane</em>, the lattice spacing in dimension x is applied to
px and nx, similarly the spacings in dimensions y,z are applied to
py/ny and pz/nz.</li>
<li>For style <em>prism</em>, the lattice spacing in dimension x is applied to
xlo and xhi, similarly for ylo/yhi and zlo/zhi. The lattice spacing
in dimension x is applied to xy and xz, and the spacing in dimension y
to yz.</li>
<li>For style <em>sphere</em>, the lattice spacing in dimensions x,y,z are
applied to the sphere center x,y,z. The spacing in dimension x is
applied to the sphere radius.</li>
</ul>
<hr class="docutils" />
<p>If the <em>move</em> or <em>rotate</em> keywords are used, the region is “dynamic”,
meaning its location or orientation changes with time. These keywords
cannot be used with a <em>union</em> or <em>intersect</em> style region. Instead,
the keywords should be used to make the individual sub-regions of the
<em>union</em> or <em>intersect</em> region dynamic. Normally, each sub-region
should be “dynamic” in the same manner (e.g. rotate around the same
point), though this is not a requirement.</p>
<p>The <em>move</em> keyword allows one or more <a class="reference internal" href="variable.html"><span class="doc">equal-style variables</span></a> to be used to specify the x,y,z displacement
of the region, typically as a function of time. A variable is
specified as v_name, where name is the variable name. Any of the
three variables can be specified as NULL, in which case no
displacement is calculated in that dimension.</p>
<p>Note that equal-style variables can specify formulas with various
mathematical functions, and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a>
command keywords for the simulation box parameters and timestep and
elapsed time. Thus it is easy to specify a region displacement that
change as a function of time or spans consecutive runs in a continuous
fashion. For the latter, see the <em>start</em> and <em>stop</em> keywords of the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command and the <em>elaplong</em> keyword of <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> for details.</p>
<p>For example, these commands would displace a region from its initial
position, in the positive x direction, effectively at a constant
<p>The <em>rotate</em> keyword rotates the region around a rotation axis <em>R</em> =
(Rx,Ry,Rz) that goes thru a point <em>P</em> = (Px,Py,Pz). The rotation
angle is calculated, presumably as a function of time, by a variable
specified as v_theta, where theta is the variable name. The variable
should generate its result in radians. The direction of rotation for
the region around the rotation axis is consistent with the right-hand
rule: if your right-hand thumb points along <em>R</em>, then your fingers
wrap around the axis in the direction of rotation.</p>
<p>The <em>move</em> and <em>rotate</em> keywords can be used together. In this case,
the displacement specified by the <em>move</em> keyword is applied to the <em>P</em>
point of the <em>rotate</em> keyword.</p>
<hr class="docutils" />
<p>Styles with a <em>kk</em> suffix are functionally the same as the
corresponding style without the suffix. They have been optimized to
run faster, depending on your available hardware, as discussed in
-<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual. The
+<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.</p>
<p>The code using the region (such as a fix or compute) must also be supported
by Kokkos or no acceleration will occur. Currently, only <em>block</em> style
regions are supported by Kokkos.</p>
<p>These accelerated styles are part of the Kokkos package. They are
only enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
-<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>A prism cannot be of 0.0 thickness in any dimension; use a small z
thickness for 2d simulations. For 2d simulations, the xz and yz
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
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>.
<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.0 by default; see the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-plog and -pscreen command-line switches</span></a> 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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>
+<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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.
+see the <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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
+<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section 5</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>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using 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 tempering or replica exchange simulation using multiple
replicas (ensembles) of a system. Two or more replicas must be used.</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
+switch; see <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">Section 2.7</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. You will simply not get the performance speed-up you
would see with one or more physical processors per replica. See <a class="reference internal" href="Section_howto.html#howto-5"><span class="std std-ref">this section</span></a> of the manual for further
discussion.</p>
<p>Each replica’s temperature is controlled at a different value by a fix
with <em>fix-ID</em> that controls temperature. Most thermostat fix styles
(with and without included time integration) are supported. The command
will print an error message and abort, if the chosen fix is unsupported.
The desired temperature is specified by <em>temp</em>, which is typically a
variable previously set in the input script, so that each partition is
assigned a different temperature. See the <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>
command for more details. For example:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span>variable t world 300.0 310.0 320.0 330.0
fix myfix all nvt temp $t $t 100.0
temper 100000 100 $t myfix 3847 58382
</pre></div>
</div>
<p>would define 4 temperatures, and assign one of them to the thermostat
used by each replica, and to the temper command.</p>
<p>As the tempering simulation runs for <em>N</em> timesteps, a temperature swap
between adjacent ensembles will be attempted every <em>M</em> timesteps. If
<em>seed1</em> is 0, then the swap attempts will alternate between odd and
even pairings. If <em>seed1</em> is non-zero then it is used as a seed in a
random number generator to randomly choose an odd or even pairing each
time. Each attempted swap of temperatures is either accepted or
rejected based on a Boltzmann-weighted Metropolis criterion which uses
<em>seed2</em> in the random number generator.</p>
<p>As a tempering run proceeds, multiple log files and screen output
files are created, one per replica. By default these files are named
log.lammps.M and screen.M where M is the replica number from 0 to N-1,
with N = # of replicas. See the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">section on command-line switches</span></a> for info on how to change these
names.</p>
<p>The main screen and log file (log.lammps) will list information about
which temperature is assigned to each replica at each thermodynamic
output timestep. E.g. for a simulation with 16 replicas:</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>
+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 2.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>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>.