<li class="toctree-l2"><a class="reference internal" href="#general-strategies">5.2. General strategies</a></li>
<li class="toctree-l2"><a class="reference internal" href="#packages-with-optimized-styles">5.3. Packages with optimized styles</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#comparison-of-various-accelerator-packages">5.4. Comparison of various accelerator packages</a><ul>
+<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>
<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 either the USER-CUDA or GPU packages</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 (USER-CUDA, GPU, KOKKOS with Cuda),
-including settings to build the needed auxiliary USER-CUDA and GPU
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<a class="reference internal" href="if.html"><span class="doc">if</span></a>, and <a class="reference internal" href="python.html"><span class="doc">python</span></a> commands for examples.</p>
<p>A “#” or “$” character that is between quotes will not be treated as a
comment indicator in (2) or substituted for as a variable in (3).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If the argument is itself a command that requires a quoted
argument (e.g. using a <a class="reference internal" href="print.html"><span class="doc">print</span></a> command as part of an
<a class="reference internal" href="if.html"><span class="doc">if</span></a> or <a class="reference internal" href="run.html"><span class="doc">run every</span></a> command), then single, double, or
triple quotes can be nested in the usual manner. See the doc pages
for those commands for examples. Only one of level of nesting is
allowed, but that should be sufficient for most use cases.</p>
<p>This section describes the structure of a typical LAMMPS input script.
The “examples” directory in the LAMMPS distribution contains many
sample input scripts; the corresponding problems are discussed in
<a class="reference internal" href="Section_example.html"><span class="doc">Section_example</span></a>, and animated on the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>.</p>
<p>A LAMMPS input script typically has 4 parts:</p>
<ol class="arabic simple">
<li>Initialization</li>
<li>Atom definition</li>
<li>Settings</li>
<li>Run a simulation</li>
</ol>
<p>The last 2 parts can be repeated as many times as desired. I.e. run a
simulation, change some settings, run some more, etc. Each of the 4
parts is now described in more detail. Remember that almost all the
commands need only be used if a non-default value is desired.</p>
<ol class="arabic simple">
<li>Initialization</li>
</ol>
<p>Set parameters that need to be defined before atoms are created or
read-in from a file.</p>
<p>The relevant commands are <a class="reference internal" href="units.html"><span class="doc">units</span></a>,
<p>Output options are set by the <a class="reference internal" href="thermo.html"><span class="doc">thermo</span></a>, <a class="reference internal" href="dump.html"><span class="doc">dump</span></a>,
and <a class="reference internal" href="restart.html"><span class="doc">restart</span></a> commands.</p>
<ol class="arabic simple" start="4">
<li>Run a simulation</li>
</ol>
<p>A molecular dynamics simulation is run using the <a class="reference internal" href="run.html"><span class="doc">run</span></a>
command. Energy minimization (molecular statics) is performed using
the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command. A parallel tempering
(replica-exchange) simulation can be run using the
<p>This section lists all LAMMPS commands alphabetically, with a separate
listing below of styles within certain commands. The <a class="reference internal" href="#cmd-4"><span class="std std-ref">previous section</span></a> lists the same commands, grouped by category. Note
that some style options for some commands are part of specific LAMMPS
packages, which means they cannot be used unless the package was
included when LAMMPS was built. Not all packages are included in a
default LAMMPS build. These dependencies are listed as Restrictions
<p>See the <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command for one-line descriptions of
each style or click on the style itself for a full description. Some
of the styles have accelerated versions, which can be used if LAMMPS
is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
-letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
+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: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
+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: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
+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: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.</p>
+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: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.</p>
+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: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.</p>
+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: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.</p>
+letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The LAMMPS distribution includes an examples sub-directory with many
sample problems. Many are 2d models that run quickly are are
straightforward to visualize, requiring at most a couple of minutes to
run on a desktop machine. Each problem has an input script (in.*) and
produces a log file (log.*) when it runs. Some use a data file
(data.*) of initial coordinates as additional input. A few sample log
file run on different machines and different numbers of processors are
included in the directories to compare your answers to. E.g. a log
file like log.date.crack.foo.P means the “crack” example was run on P
processors of machine “foo” on that date (i.e. with that version of
LAMMPS).</p>
<p>Many of the input files have commented-out lines for creating dump
files and image files.</p>
<p>If you uncomment the <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> command in the input script, a
text dump file will be produced, which can be animated by various
<a class="reference external" href="http://lammps.sandia.gov/viz.html">visualization programs</a>. It can
also be animated using the xmovie tool described in the <a class="reference internal" href="Section_tools.html"><span class="doc">Additional Tools</span></a> section of the LAMMPS documentation.</p>
<p>If you uncomment the <a class="reference internal" href="dump.html"><span class="doc">dump image</span></a> command in the input
script, and assuming you have built LAMMPS with a JPG library, JPG
snapshot images will be produced when the simulation runs. They can
be quickly post-processed into a movie using commands described on the
<span class="n">cp</span> <span class="o">../../</span><span class="n">src</span><span class="o">/</span><span class="n">lmp_linux</span> <span class="o">.</span> <span class="c1"># copy LAMMPS executable to this dir</span>
<span class="n">lmp_linux</span> <span class="o">-</span><span class="ow">in</span> <span class="ow">in</span><span class="o">.</span><span class="n">indent</span> <span class="c1"># run the problem</span>
</pre></div>
</div>
<p>Running the simulation produces the files <em>dump.indent</em> and
<em>log.lammps</em>. You can visualize the dump file of snapshots with a
variety of 3rd-party tools highlighted on the
<a class="reference external" href="http://lammps.sandia.gov/viz.html">Visualization</a> page of the LAMMPS
web site.</p>
<p>If you uncomment the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a> line(s) in the input
script a series of JPG images will be produced by the run (assuming
you built LAMMPS with JPG support; see <a class="reference internal" href="Section_start.html"><span class="doc">Section start 2.2</span></a> for details). These can be viewed
individually or turned into a movie or animated by tools like
ImageMagick or QuickTime or various Windows-based tools. See the
<a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a> doc page for more details. E.g. this
Imagemagick command would create a GIF file suitable for viewing in a
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>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-CUDA, USER-INTEL, USER-OMP
-packages, which also provide optimizations for the same range of
-hardware.</p>
+use this package. See the GPU, OPT, USER-INTEL, USER-OMP packages,
+which also provide optimizations for the same range of hardware.</p>
<p>Building with the KOKKOS package requires choosing which of 3 hardware
options you are optimizing for: CPU acceleration via OpenMP, GPU
acceleration, or Intel Xeon Phi. (You can build multiple times to
create LAMMPS executables for different hardware.) It also requires a
C++11 compatible compiler. For GPUs, the NVIDIA “nvcc” compiler is
used, and an appopriate KOKKOS_ARCH setting should be made in your
Makefile.machine for your GPU hardware and NVIDIA software.</p>
<p>The simplest way to do this is to use Makefile.kokkos_cuda or
Makefile.kokkos_omp or Makefile.kokkos_phi in src/MAKE/OPTIONS, via
“make kokkos_cuda” or “make kokkos_omp” or “make kokkos_phi”. (Check
the KOKKOS_ARCH setting in Makefile.kokkos_cuda), Or, as illustrated
below, you can use the Make.py script with its “-kokkos” option to
choose which hardware to build for. Type “python src/Make.py -h
-kokkos” to see the details. If these methods do not work on your
system, you will need to read the <a class="reference internal" href="accelerate_kokkos.html"><span class="doc">Section accelerate kokkos</span></a> doc page for details of what
Makefile.machine settings are needed.</p>
<p>To install via make or Make.py for each of 3 hardware options:</p>
<span class="n">make</span> <span class="n">kokkos_omp</span> <span class="c1"># for CPUs with OpenMP</span>
<span class="n">make</span> <span class="n">kokkos_cuda</span> <span class="c1"># for GPUs, check the KOKKOS_ARCH setting in Makefile.kokkos_cuda</span>
<span class="n">make</span> <span class="n">kokkos_phi</span> <span class="c1"># for Xeon Phis</span>
</pre></div>
</div>
<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 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-l3"><a class="reference internal" href="#additional-requirement-for-using-a-shared-library">2.5.3. <strong>Additional requirement for using a shared library:</strong></a></li>
<li class="toctree-l3"><a class="reference internal" href="#calling-the-lammps-library">2.5.4. <strong>Calling the LAMMPS library:</strong></a></li>
<p>This will create a LAMMPS directory containing two files and several
sub-directories:</p>
<table border="1" class="docutils">
<colgroup>
<col width="21%" />
<col width="79%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>README</td>
<td>text file</td>
</tr>
<tr class="row-even"><td>LICENSE</td>
<td>the GNU General Public License (GPL)</td>
</tr>
<tr class="row-odd"><td>bench</td>
<td>benchmark problems</td>
</tr>
<tr class="row-even"><td>doc</td>
<td>documentation</td>
</tr>
<tr class="row-odd"><td>examples</td>
<td>simple test problems</td>
</tr>
<tr class="row-even"><td>potentials</td>
<td>embedded atom method (EAM) potential files</td>
</tr>
<tr class="row-odd"><td>src</td>
<td>source files</td>
</tr>
<tr class="row-even"><td>tools</td>
<td>pre- and post-processing tools</td>
</tr>
</tbody>
</table>
<p>Note that the <a class="reference external" href="http://lammps.sandia.gov/download.html">download page</a> also has links to download
Windows exectubles and installers, as well as pre-built executables
for a few specific Linux distributions. It also has instructions for
how to download/install LAMMPS for Macs (via Homebrew), and to
download and update LAMMPS from SVN and Git repositories, which gives
you the same files that are in the download tarball.</p>
<p>The Windows and Linux executables for serial or parallel only include
certain packages and bug-fixes/upgrades listed on <a class="reference external" href="http://lammps.sandia.gov/bug.html">this page</a> up to a certain date, as
stated on the download page. If you want an executable with
non-included packages or that is more current, then you’ll need to
build LAMMPS yourself, as discussed in the next section.</p>
<p>Skip to the <a class="reference internal" href="#start-6"><span class="std std-ref">Running LAMMPS</span></a> sections for info on how to
launch a LAMMPS Windows executable on a Windows box.</p>
<hr class="docutils" />
</div>
<div class="section" id="making-lammps">
<span id="start-2"></span><h2>2.2. Making LAMMPS</h2>
<p>This section has the following sub-sections:</p>
<ul class="simple">
<li><a class="reference internal" href="#start-2-1"><span class="std std-ref">Read this first</span></a></li>
<li><a class="reference internal" href="#start-2-2"><span class="std std-ref">Steps to build a LAMMPS executable</span></a></li>
<li><a class="reference internal" href="#start-2-3"><span class="std std-ref">Common errors that can occur when making LAMMPS</span></a></li>
This gives preference to a file you have created/edited and put in
src/MAKE/MINE.</p>
<p>Note that on a multi-processor or multi-core platform you can launch a
parallel make, by using the “-j” switch with the make command, which
will build LAMMPS more quickly.</p>
<p>If you get no errors and an executable like lmp_mpi or lmp_g++_serial
or lmp_mac is produced, then you’re done; it’s your lucky day.</p>
<p>Note that by default only a few of LAMMPS optional packages are
installed. To build LAMMPS with optional packages, see <a class="reference internal" href="#start-3"><span class="std std-ref">this section</span></a> below.</p>
<p><strong>Step 1</strong></p>
<p>If Step 0 did not work, you will need to create a low-level Makefile
for your machine, like Makefile.foo. You should make a copy of an
existing Makefile.* in src/MAKE or one of its sub-directories as a
starting point. The only portions of the file you need to edit are
the first line, the “compiler/linker settings” section, and the
“LAMMPS-specific settings” section. When it works, put the edited
file in src/MAKE/MINE and it will not be altered by any future LAMMPS
updates.</p>
<p><strong>Step 2</strong></p>
<p>Change the first line of Makefile.foo to list the word “foo” after the
“#”, and whatever other options it will set. This is the line you
will see if you just type “make”.</p>
<p><strong>Step 3</strong></p>
<p>The “compiler/linker settings” section lists compiler and linker
settings for your C++ compiler, including optimization flags. You can
use g++, the open-source GNU compiler, which is available on all Unix
systems. You can also use mpicxx which will typically be available if
MPI is installed on your system, though you should check which actual
compiler it wraps. Vendor compilers often produce faster code. On
boxes with Intel CPUs, we suggest using the Intel icc compiler, which
can be downloaded from <a class="reference external" href="http://www.intel.com/software/products/noncom">Intel’s compiler site</a>.</p>
<p>If building a C++ code on your machine requires additional libraries,
then you should list them as part of the LIB variable. You should
not need to do this if you use mpicxx.</p>
<p>The DEPFLAGS setting is what triggers the C++ compiler to create a
dependency list for a source file. This speeds re-compilation when
source (<em>.cpp) or header (</em>.h) files are edited. Some compilers do
not support dependency file creation, or may use a different switch
than -D. GNU g++ and Intel icc works with -D. If your compiler can’t
create dependency files, then you’ll need to create a Makefile.foo
patterned after Makefile.storm, which uses different rules that do not
involve dependency files. Note that when you build LAMMPS for the
first time on a new platform, a long list of <a href="#id5"><span class="problematic" id="id6">*</span></a>.d files will be printed
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>-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 two packages, USER-ATC and USER-CUDA are 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>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>Using one of the -DPACK_ARRAY, -DPACK_POINTER, and -DPACK_MEMCPY
options can make for faster parallel FFTs (in the PPPM solver) on some
platforms. The -DPACK_ARRAY setting is the default. See the
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command for info about PPPM. See
Step 6 below for info about building LAMMPS with an FFT library.</p>
<p><strong>Step 5</strong></p>
<p>The 3 MPI variables are used to specify an MPI library to build LAMMPS
with. Note that you do not need to set these if you use the MPI
compiler mpicxx for your CC and LINK setting in the section above.
The MPI wrapper knows where to find the needed files.</p>
<p>If you want LAMMPS to run in parallel, you must have an MPI library
installed on your platform. If MPI is installed on your system in the
usual place (under /usr/local), you also may not need to specify these
3 variables, assuming /usr/local is in your path. On some large
parallel machines which use “modules” for their compile/link
environements, you may simply need to include the correct module in
your build environment, before building LAMMPS. Or the parallel
machine may have a vendor-provided MPI which the compiler has no
trouble finding.</p>
<p>Failing this, these 3 variables can be used to specify where the mpi.h
file (MPI_INC) and the MPI library file (MPI_PATH) are found and the
name of the library file (MPI_LIB).</p>
<p>If you are installing MPI yourself, we recommend Argonne’s MPICH2
or OpenMPI. MPICH can be downloaded from the <a class="reference external" href="http://www.mcs.anl.gov/research/projects/mpich2/">Argonne MPI site</a>. OpenMPI can
be downloaded from the <a class="reference external" href="http://www.open-mpi.org">OpenMPI site</a>.
Other MPI packages should also work. If you are running on a big
parallel platform, your system people or the vendor should have
already installed a version of MPI, which is likely to be faster
than a self-installed MPICH or OpenMPI, so find out how to build
and link with it. If you use MPICH or OpenMPI, you will have to
configure and build it for your platform. The MPI configure script
should have compiler options to enable you to use the same compiler
you are using for the LAMMPS build, which can avoid problems that can
arise when linking LAMMPS to the MPI library.</p>
<p>If you just want to run LAMMPS on a single processor, you can use the
dummy MPI library provided in src/STUBS, since you don’t need a true
MPI library installed on your system. See src/MAKE/Makefile.serial
for how to specify the 3 MPI variables in this case. You will also
need to build the STUBS library for your platform before making LAMMPS
itself. Note that if you are building with src/MAKE/Makefile.serial,
e.g. by typing “make serial”, then the STUBS library is built for you.</p>
<p>To build the STUBS library from the src directory, type “make
mpi-stubs”, or from the src/STUBS dir, type “make”. This should
create a libmpi_stubs.a file suitable for linking to LAMMPS. If the
build fails, you will need to edit the STUBS/Makefile for your
platform.</p>
<p>The file STUBS/mpi.c provides a CPU timer function called MPI_Wtime()
that calls gettimeofday() . If your system doesn’t support
gettimeofday() , you’ll need to insert code to call another timer.
Note that the ANSI-standard function clock() rolls over after an hour
or so, and is therefore insufficient for timing long LAMMPS
simulations.</p>
<p><strong>Step 6</strong></p>
<p>The 3 FFT variables allow you to specify an FFT library which LAMMPS
uses (for performing 1d FFTs) when running the particle-particle
particle-mesh (PPPM) option for long-range Coulombics via the
ACML, and T3E. For backward compatability, using -DFFT_FFTW will use
the FFTW2 library. Using -DFFT_NONE will use the KISS library
described above.</p>
<p>You may also need to set the FFT_INC, FFT_PATH, and FFT_LIB variables,
so the compiler and linker can find the needed FFT header and library
files. Note that on some large parallel machines which use “modules”
for their compile/link environements, you may simply need to include
the correct module in your build environment. Or the parallel machine
may have a vendor-provided FFT library which the compiler has no
trouble finding.</p>
<p>FFTW is a fast, portable library that should also work on any
platform. You can download it from
<a class="reference external" href="http://www.fftw.org">www.fftw.org</a>. Both the legacy version 2.1.X and
the newer 3.X versions are supported as -DFFT_FFTW2 or -DFFT_FFTW3.
Building FFTW for your box should be as simple as ./configure; make.
Note that on some platforms FFTW2 has been pre-installed, and uses
renamed files indicating the precision it was compiled with,
e.g. sfftw.h, or dfftw.h instead of fftw.h. In this case, you can
specify an additional define variable for FFT_INC called -DFFTW_SIZE,
which will select the correct include file. In this case, for FFT_LIB
you must also manually specify the correct library, namely -lsfftw or
-ldfftw.</p>
<p>The FFT_INC variable also allows for a -DFFT_SINGLE setting that will
use single-precision FFTs with PPPM, which can speed-up long-range
calulations, particularly in parallel or on GPUs. Fourier transform
and related PPPM operations are somewhat insensitive to floating point
truncation errors and thus do not always need to be performed in
double precision. Using the -DFFT_SINGLE setting trades off a little
accuracy for reduced memory use and parallel communication costs for
transposing 3d FFT data. Note that single precision FFTs have only
been tested with the FFTW3, FFTW2, MKL, and KISS FFT options.</p>
<p><strong>Step 7</strong></p>
<p>The 3 JPG variables allow you to specify a JPEG and/or PNG library
which LAMMPS uses when writing out JPEG or PNG files via the <a class="reference internal" href="dump_image.html"><span class="doc">dump image</span></a> command. These can be left blank if you do not
use the -DLAMMPS_JPEG or -DLAMMPS_PNG switches discussed above in Step
4, since in that case JPEG/PNG output will be disabled.</p>
<p>A standard JPEG library usually goes by the name libjpeg.a or
libjpeg.so and has an associated header file jpeglib.h. Whichever
JPEG library you have on your platform, you’ll need to set the
appropriate JPG_INC, JPG_PATH, and JPG_LIB variables, so that the
compiler and linker can find it.</p>
<p>A standard PNG library usually goes by the name libpng.a or libpng.so
and has an associated header file png.h. Whichever PNG library you
have on your platform, you’ll need to set the appropriate JPG_INC,
JPG_PATH, and JPG_LIB variables, so that the compiler and linker can
find it.</p>
<p>As before, if these header and library files are in the usual place on
your machine, you may not need to set these variables.</p>
<p><strong>Step 8</strong></p>
<p>Note that by default only a few of LAMMPS optional packages are
installed. To build LAMMPS with optional packages, see <a class="reference internal" href="#start-3"><span class="std std-ref">this section</span></a> below, before proceeding to Step 9.</p>
<p><strong>Step 9</strong></p>
<p>That’s it. Once you have a correct Makefile.foo, and you have
pre-built any other needed libraries (e.g. MPI, FFT, etc) all you need
to do from the src directory is type something like this:</p>
<p>You can make LAMMPS for multiple platforms from the same src
directory. Each target creates its own object sub-directory called
Obj_target where it stores the system-specific <a href="#id11"><span class="problematic" id="id12">*</span></a>.o files.</p>
<ol class="arabic simple" start="2">
<li>Cleaning up.</li>
</ol>
<p>Typing “make clean-all” or “make clean-machine” will delete <a href="#id13"><span class="problematic" id="id14">*</span></a>.o object
files created when LAMMPS is built, for either all builds or for a
particular machine.</p>
<p>(3) Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or
-DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL</p>
<p>As explained above, any of these 3 settings can be specified on the
LMP_INC line in your low-level src/MAKE/Makefile.foo.</p>
<p>The default is -DLAMMPS_SMALLBIG which allows for systems with up to
2^63 atoms and 2^63 timesteps (about 9e18). The atom limit is for
atomic systems which do not store bond topology info and thus do not
require atom IDs. If you use atom IDs for atomic systems (which is
the default) or if you use a molecular model, which stores bond
topology info and thus requires atom IDs, the limit is 2^31 atoms
(about 2 billion). This is because the IDs are stored in 32-bit
integers.</p>
<p>Likewise, with this setting, the 3 image flags for each atom (see the
<a class="reference internal" href="dump.html"><span class="doc">dump</span></a> doc page for a discussion) are stored in a 32-bit
integer, which means the atoms can only wrap around a periodic box (in
each dimension) at most 512 times. If atoms move through the periodic
box more than this many times, the image flags will “roll over”,
e.g. from 511 to -512, which can cause diagnostics like the
mean-squared displacement, as calculated by the <a class="reference internal" href="compute_msd.html"><span class="doc">compute msd</span></a> command, to be faulty.</p>
<p>To allow for larger atomic systems with atom IDs or larger molecular
systems or larger image flags, compile with -DLAMMPS_BIGBIG. This
stores atom IDs and image flags in 64-bit integers. This enables
atomic or molecular systems with atom IDS of up to 2^63 atoms (about
9e18). And image flags will not “roll over” until they reach 2^20 =
1048576.</p>
<p>If your system does not support 8-byte integers, you will need to
compile with the -DLAMMPS_SMALLSMALL setting. This will restrict the
total number of atoms (for atomic or molecular systems) and timesteps
to 2^31 (about 2 billion). Image flags will roll over at 2^9 = 512.</p>
<p>Note that in src/lmptype.h there are definitions of all these data
types as well as the MPI data types associated with them. The MPI
types need to be consistent with the associated C data types, or else
LAMMPS will generate a run-time error. As far as we know, the
settings defined in src/lmptype.h are portable and work on every
current system.</p>
<p>In all cases, the size of problem that can be run on a per-processor
basis is limited by 4-byte integer storage to 2^31 atoms per processor
(about 2 billion). This should not normally be a limitation since such
a problem would have a huge per-processor memory footprint due to
neighbor lists and would run very slowly in terms of CPU secs/timestep.</p>
<hr class="docutils" />
<p id="start-2-5"><a href="#id15"><span class="problematic" id="id16">**</span></a><em>Building for a Mac:</em>**</p>
<p>OS X is BSD Unix, so it should just work. See the
src/MAKE/MACHINES/Makefile.mac and Makefile.mac_mpi files.</p>
<hr class="docutils" />
<p id="start-2-6"><a href="#id17"><span class="problematic" id="id18">**</span></a><em>Building for Windows:</em>**</p>
<p>The LAMMPS download page has an option to download both a serial and
parallel pre-built Windows executable. See the <a class="reference internal" href="#start-6"><span class="std std-ref">Running LAMMPS</span></a> section for instructions on running these executables
on a Windows box.</p>
<p>The pre-built executables hosted on the <a class="reference external" href="http://lammps.sandia.gov/download.html">LAMMPS download page</a> are built with a subset
of the available packages; see the download page for the list. These
are single executable files. No examples or documentation in
included. You will need to download the full source code package to
obtain those.</p>
<p>As an alternative, you can download “daily builds” (and some older
<p>to run your executable with the optional <a class="reference internal" href="#start-7"><span class="std std-ref">-h command-line switch</span></a> for “help”, which will simply list the styles and
commands known to your executable, and immediately exit.</p>
<p>There are two kinds of packages in LAMMPS, standard and user packages.
More information about the contents of standard and user packages is
given in <a class="reference internal" href="Section_packages.html"><span class="doc">Section_packages</span></a> of the manual. The
difference between standard and user packages is as follows:</p>
<p>Standard packages, such as molecule or kspace, are supported by the
LAMMPS developers and are written in a syntax and style consistent
with the rest of LAMMPS. This means we will answer questions about
them, debug and fix them if necessary, and keep them compatible with
future changes to LAMMPS.</p>
<p>User packages, such as user-atc or user-omp, have been contributed by
users, and always begin with the user prefix. If they are a single
command (single file), they are typically in the user-misc package.
Otherwise, they are a a set of files grouped together which add a
specific functionality to the code.</p>
<p>User packages don’t necessarily meet the requirements of the standard
packages. If you have problems using a feature provided in a user
package, you may need to contact the contributor directly to get help.
Information on how to submit additions you make to LAMMPS as single
files or either a standard or user-contributed package are given in
<a class="reference internal" href="Section_modify.html#mod-15"><span class="std std-ref">this section</span></a> of the documentation.</p>
no-user”, “make yes-lib”, “make no-lib”, “make yes-all”, or “make
no-all” to include/exclude various sets of packages. Type “make
package” to see all of the package-related make options.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Inclusion/exclusion of a package works by simply moving files
back and forth between the main src directory and sub-directories with
the package name (e.g. src/KSPACE, src/USER-ATC), so that the files
are seen or not seen when LAMMPS is built. After you have included or
excluded a package, you must re-build LAMMPS.</p>
</div>
<p>Additional package-related make options exist to help manage LAMMPS
files that exist in both the src directory and in package
sub-directories. You do not normally need to use these commands
unless you are editing LAMMPS files or have downloaded a patch from
the LAMMPS WWW site.</p>
<p>Typing “make package-update” or “make pu” will overwrite src files
with files from the package sub-directories if the package has been
included. It should be used after a patch is installed, since patches
only update the files in the package sub-directory, but not the src
files. Typing “make package-overwrite” will overwrite files in the
package sub-directories with src files.</p>
<p>Typing “make package-status” or “make ps” will show which packages are
currently included. For those that are included, it will list any
files that are different in the src directory and package
sub-directory. Typing “make package-diff” lists all differences
between these files. Again, type “make package” to see all of the
package-related make options.</p>
<hr class="docutils" />
<p id="start-3-3"><a href="#id23"><span class="problematic" id="id24">**</span></a><em>Packages that require extra libraries:</em>**</p>
<p>A few of the standard and user packages require additional auxiliary
libraries. Many of them are provided with LAMMPS, in which case they
must be compiled first, before LAMMPS is built, if you wish to include
that package. If you get a LAMMPS build error about a missing
library, this is likely the reason. See the
<a class="reference internal" href="Section_packages.html"><span class="doc">Section_packages</span></a> doc page for a list of
packages that have these kinds of auxiliary libraries.</p>
<p>The lib directory in the distribution has sub-directories with package
names that correspond to the needed auxiliary libs, e.g. lib/gpu.
Each sub-directory has a README file that gives more details. Code
for most of the auxiliary libraries is included in that directory.
Examples are the USER-ATC and MEAM packages.</p>
<p>A few of the lib sub-directories do not include code, but do include
instructions (and sometimes scripts) that automate the process of
downloading the auxiliary library and installing it so LAMMPS can link
to it. Examples are the KIM, VORONOI, USER-MOLFILE, and USER-SMD
packages.</p>
<p>The lib/python directory (for the PYTHON package) contains only a
choice of Makefile.lammps.* files. This is because no auxiliary code
or libraries are needed, only the Python library and other system libs
that should already available on your system. However, the
Makefile.lammps file is needed to tell LAMMPS which libs to use and
where to find them.</p>
<p>For libraries with provided code, the sub-directory README file
(e.g. lib/atc/README) has instructions on how to build that library.
This information is also summarized in <a class="reference internal" href="Section_packages.html"><span class="doc">Section packages</span></a>. Typically this is done by typing
<p>The Makefile.lammps file will typically be a copy of one of the
Makefile.lammps.* files in the library directory.</p>
<p>Note that you must insure that the settings in Makefile.lammps are
appropriate for your system. If they are not, the LAMMPS build may
fail. To fix this, you can edit or create a new Makefile.lammps.*
file for your system, and copy it to Makefile.lammps.</p>
<p>As explained in the lib/package/README files, the settings in
Makefile.lammps are used to specify additional system libraries and
their locations so that LAMMPS can build with the auxiliary library.
For example, if the MEAM package is used, the auxiliary library
consists of F90 code, built with a Fortran complier. To link that
library with LAMMPS (a C++ code) via whatever C++ compiler LAMMPS is
built with, typically requires additional Fortran-to-C libraries be
included in the link. Another example are the BLAS and LAPACK
libraries needed to use the USER-ATC or USER-AWPMD packages.</p>
<p>For libraries without provided code, the sub-directory README file has
information on where to download the library and how to build it,
e.g. lib/voronoi/README and lib/smd/README. The README files also
describe how you must either (a) create soft links, via the “ln”
command, in those directories to point to where you built or installed
the packages, or (b) check or edit the Makefile.lammps file in the
same directory to provide that information.</p>
<p>Some of the sub-directories, e.g. lib/voronoi, also have an install.py
script which can be used to automate the process of
downloading/building/installing the auxiliary library, and setting the
needed soft links. Type “python install.py” for further instructions.</p>
<p>As with the sub-directories containing library code, if the soft links
or settings in the lib/package/Makefile.lammps files are not correct,
the LAMMPS build will typically fail.</p>
<hr class="docutils" />
<p id="start-3-4"><a href="#id25"><span class="problematic" id="id26">**</span></a><em>Packages that require Makefile.machine settings</em>**</p>
<p>A few packages require specific settings in Makefile.machine, to
either build or use the package effectively. These are the
USER-INTEL, KOKKOS, USER-OMP, and OPT packages, used for accelerating
code performance on CPUs or other hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section acclerate</span></a>.</p>
<p>A summary of what Makefile.machine changes are needed for each of
these packages is given in <a class="reference internal" href="Section_packages.html"><span class="doc">Section packages</span></a>.
The details are given on the doc pages that describe each of these
<p>You can also look at the following machine Makefiles in
src/MAKE/OPTIONS, which include the changes. Note that the USER-INTEL
and KOKKOS packages allow for settings that build LAMMPS for different
hardware. The USER-INTEL package builds for CPU and the Xeon Phi, the
KOKKOS package builds for OpenMP, GPUs (Cuda), and the Xeon Phi.</p>
<ul class="simple">
<li>Makefile.intel_cpu</li>
<li>Makefile.intel_phi</li>
<li>Makefile.kokkos_omp</li>
<li>Makefile.kokkos_cuda</li>
<li>Makefile.kokkos_phi</li>
<li>Makefile.omp</li>
<li>Makefile.opt</li>
</ul>
<p>Also note that the Make.py tool, described in the next <a class="reference internal" href="#start-4"><span class="std std-ref">Section 2.4</span></a> can automatically add the needed info to an existing
machine Makefile, using simple command-line arguments.</p>
relocation R_X86_64_32 against `__pthread_key_create' can not be used
when making a shared object; recompile with -fPIC
../../lib/colvars/libcolvars.a: error adding symbols: Bad value
</pre></div>
</div>
<p>As an example, here is how to build and install the <a class="reference external" href="http://www-unix.mcs.anl.gov/mpi">MPICH library</a>, a popular open-source version of MPI, distributed by
Argonne National Labs, as a shared library in the default
<h3>2.5.4. <strong>Calling the LAMMPS library:</strong></h3>
<p>Either flavor of library (static or shared) allows one or more LAMMPS
objects to be instantiated from the calling program.</p>
<p>When used from a C++ program, all of LAMMPS is wrapped in a LAMMPS_NS
namespace; you can safely use any of its classes and methods from
within the calling code, as needed.</p>
<p>When used from a C or Fortran program or a scripting language like
Python, the library has a simple function-style interface, provided in
src/library.cpp and src/library.h.</p>
<p>See the sample codes in examples/COUPLE/simple for examples of C++ and
C and Fortran codes that invoke LAMMPS thru its library interface.
There are other examples as well in the COUPLE directory which are
discussed in <a class="reference internal" href="Section_howto.html#howto-10"><span class="std std-ref">Section_howto 10</span></a> of the
manual. See <a class="reference internal" href="Section_python.html"><span class="doc">Section_python</span></a> of the manual for a
description of the Python wrapper provided with LAMMPS that operates
through the LAMMPS library interface.</p>
<p>The files src/library.cpp and library.h define the C-style API for
using LAMMPS as a library. See <a class="reference internal" href="Section_howto.html#howto-19"><span class="std std-ref">Section_howto 19</span></a> of the manual for a description of the
interface and how to extend it for your needs.</p>
<p>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 “cuda” style corresponds to the USER-CUDA
-package, the “gpu” style 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>
+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/cuda,
-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 (cuda,gpu,intel,kk,omp,opt) is automatically appended
-<a class="reference internal" href="compute.html"><span class="doc">compute</span></a>, or <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>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
+(cuda,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>.
* style = *angle* or *atomic* or *body* or *bond* or *charge* or *dipole* or *dpd* or *electron* or *ellipsoid* or *full* or *line* or *meso* or *molecular* or *peri* or *smd* or *sphere* or *tri* or *template* or *hybrid*
.. parsed-literal::
args = none for any style except the following
*body* args = bstyle bstyle-args
bstyle = style of body particles
bstyle-args = additional arguments specific to the bstyle
see the :doc:`body <body>` doc page for details
*template* args = template-ID
template-ID = ID of molecule template specified in a separate :doc:`molecule <molecule>` command
*hybrid* args = list of one or more sub-styles, each with their args
-* accelerated styles (with same args) = *angle/cuda* or *angle/kk* or *atomic/cuda* or *atomic/kk* or *bond/kk* or *charge/cuda* or *charge/kk* or *full/cuda* or *full/kk* or *molecular/kk*
+* accelerated styles (with same args) = *angle/kk* or *atomic/kk* or *bond/kk* or *charge/kk* or *full/kk* or *molecular/kk*
Examples
""""""""
.. parsed-literal::
atom_style atomic
atom_style bond
atom_style full
- atom_style full/cuda
atom_style body nparticle 2 10
atom_style hybrid charge bond
atom_style hybrid charge body nparticle 2 5
atom_style template myMols
Description
"""""""""""
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 :doc:`read_data <read_data>`,
:doc:`read_restart <read_restart>`, or :doc:`create_box <create_box>`
command.
.. note::
Many of the atom styles discussed here are only enabled if
LAMMPS was built with a specific package, as listed below in the
Restrictions section.
Once a style is assigned, it cannot be changed, so use a style general
enough to encompass all attributes. E.g. with style *bond*\ , angular
terms cannot be used or added later to the model. It is OK to use a
style more general than needed, though it may be slightly inefficient.
The choice of style affects what quantities are stored by each atom,
what quantities are communicated between processors to enable forces
to be computed, and what quantities are listed in the data file read
by the :doc:`read_data <read_data>` command.
These are the additional attributes of each style and the typical
kinds of physical systems they are used to model. All styles store
coordinates, velocities, atom IDs and types. See the
:doc:`read_data <read_data>`, :doc:`create_atoms <create_atoms>`, and
:doc:`set <set>` commands for info on how to set these various
compute ID group-ID temp/partial xflag yflag zflag
* ID, group-ID are documented in :doc:`compute <compute>` command
* temp/partial = style name of this compute command
* xflag,yflag,zflag = 0/1 for whether to exclude/include this dimension
Examples
""""""""
.. parsed-literal::
compute newT flow temp/partial 1 1 0
Description
"""""""""""
Define a computation that calculates the temperature of a group of
atoms, after excluding one or more velocity components. A compute of
this style can be used by any command that computes a temperature,
e.g. :doc:`thermo_modify <thermo_modify>`, :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix npt <fix_nh>`, etc.
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.
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.
The number of atoms contributing to the temperature is assumed to be
constant for the duration of the run; use the *dynamic* option of the
:doc:`compute_modify <compute_modify>` command if this is not the case.
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 :doc:`fix nvt <fix_nh>`, :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix temp/berendsen <fix_temp_berendsen>`, and :doc:`fix langevin <fix_langevin>`.
This compute subtracts out degrees-of-freedom due to fixes that
constrain molecular motion, such as :doc:`fix shake <fix_shake>` and
:doc:`fix rigid <fix_rigid>`. 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
*extra* option of the :doc:`compute_modify <compute_modify>` command.
See :ref:`this howto section <howto_16>` of the manual for
a discussion of different ways to compute temperature and perform
thermostatting.
----------
-Styles with a *cuda*\ , *gpu*\ , *intel*\ , *kk*\ , *omp*\ , or *opt* suffix are
+Styles with a *gpu*\ , *intel*\ , *kk*\ , *omp*\ , or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in :doc:`Section_accelerate <Section_accelerate>`
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
-These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the :ref:`Making LAMMPS <start_3>` section for more info.
+These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the :ref:`Making LAMMPS <start_3>` section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :ref:`-suffix command-line switch <start_7>` when you invoke LAMMPS, or you can
use the :doc:`suffix <suffix>` command in your input script.
See :doc:`Section_accelerate <Section_accelerate>` of the manual for
more instructions on how to use the accelerated styles effectively.
----------
**Output info:**
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 :ref:`this section <howto_15>` for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "intensive". The
vector values are "extensive".
The scalar value will be in temperature :doc:`units <units>`. The
vector values will be in energy :doc:`units <units>`.
fix ID group-ID deform N parameter args ... keyword value ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* deform = style name of this fix command
* N = perform box deformation every this many timesteps
* one or more parameter/arg pairs may be appended
.. parsed-literal::
parameter = *x* or *y* or *z* or *xy* or *xz* or *yz*
*x*\ , *y*\ , *z* args = style value(s)
style = *final* or *delta* or *scale* or *vel* or *erate* or *trate* or *volume* or *wiggle* or *variable*
*final* values = lo hi
lo hi = box boundaries at end of run (distance units)
*delta* values = dlo dhi
dlo dhi = change in box boundaries at end of run (distance units)
*scale* values = factor
factor = multiplicative factor for change in box length at end of run
*vel* value = V
V = change box length at this velocity (distance/time units),
effectively an engineering strain rate
*erate* value = R
R = engineering strain rate (1/time units)
*trate* value = R
R = true strain rate (1/time units)
*volume* value = none = adjust this dim to preserve volume of system
*wiggle* values = A Tp
A = amplitude of oscillation (distance units)
Tp = period of oscillation (time units)
*variable* 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
*xy*\ , *xz*\ , *yz* args = style value
style = *final* or *delta* or *vel* or *erate* or *trate* or *wiggle*
*final* value = tilt
tilt = tilt factor at end of run (distance units)
*delta* value = dtilt
dtilt = change in tilt factor at end of run (distance units)
*vel* value = V
V = change tilt factor at this velocity (distance/time units),
effectively an engineering shear strain rate
*erate* value = R
R = engineering shear strain rate (1/time units)
*trate* value = R
R = true shear strain rate (1/time units)
*wiggle* values = A Tp
A = amplitude of oscillation (distance units)
Tp = period of oscillation (time units)
*variable* 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
* zero or more keyword/value pairs may be appended
* keyword = *remap* or *flip* or *units*
.. parsed-literal::
*remap* value = *x* or *v* or *none*
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
*flip* value = *yes* or *no*
allow or disallow box flips when it becomes highly skewed
*units* value = *lattice* or *box*
lattice = distances are defined in lattice units
box = distances are defined in simulation box units
Examples
""""""""
.. parsed-literal::
fix 1 all deform 1 x final 0.0 9.0 z final 0.0 5.0 units box
fix 1 all deform 1 x trate 0.1 y volume z volume
fix 1 all deform 1 xy erate 0.001 remap v
fix 1 all deform 10 y delta -0.5 0.5 xz vel 1.0
Description
"""""""""""
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 :doc:`fix nvt/sllod <fix_nvt_sllod>` and :doc:`compute temp/deform <compute_temp_deform>` commands for more details.
For the *x*\ , *y*\ , *z* parameters, the associated dimension cannot be
shrink-wrapped. For the *xy*\ , *yz*\ , *xz* 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 :doc:`fix npt <fix_nh>` or :doc:`fix nph <fix_nh>` command.
The size and shape of the simulation box at the beginning of the
simulation run were either specified by the
:doc:`create_box <create_box>` or :doc:`read_data <read_data>` or
:doc:`read_restart <read_restart>` 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 :doc:`create_box <create_box>`, :doc:`read data <read_data>`, and :doc:`read_restart <read_restart>` 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.
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.
----------
For the *x*\ , *y*\ , and *z* parameters, this is the meaning of their
styles and values.
The *final*\ , *delta*\ , *scale*\ , *vel*\ , and *erate* 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.
For style *final*\ , the final lo and hi box boundaries of a dimension
are specified. The values can be in lattice or box distance units.
See the discussion of the units keyword below.
For style *delta*\ , plus or minus changes in the lo/hi box boundaries
of a dimension are specified. The values can be in lattice or box
distance units. See the discussion of the units keyword below.
For style *scale*\ , a multiplicative factor to apply to the box length
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.
For style *vel*\ , 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.
The *erate* 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 :doc:`units <units>` 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
.. parsed-literal::
L(t) = L0 (1 + erate*dt)
where dt is the elapsed time (in time units). Thus if *erate* 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 *trate* style would induce.
The *trate* 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 :doc:`units <units>` 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
.. parsed-literal::
L(t) = L0 exp(trate*dt)
where dt is the elapsed time (in time units). Thus if *trate* 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 *erate*\ , but by a factor of
1024 since the box length will double every picosecond.
Note that to change the volume (or cross-sectional area) of the
simulation box at a constant rate, you can change multiple dimensions
via *erate* or *trate*\ . 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.
The *volume* 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 *y* 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.
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 *volume*
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
:doc:`fix npt aniso <fix_nh>` with zero applied pressure on those 2
dimensions, so that they respond to the tensile strain dynamically.
The *wiggle* 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
.. parsed-literal::
L(t) = L0 + A sin(2*pi t/Tp)
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.
The *variable* style changes the specified box length dimension by
evaluating a variable, which presumably is a function of time. The
variable with *name1* must be an :doc:`equal-style variable <variable>`
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 *units* keyword below. The formula associated with
variable *name1* 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.
The variable *name2* must also be an :doc:`equal-style variable <variable>` and should calculate the rate of box length
change, in units of distance/time, i.e. the time-derivative of the
*name1* 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.
Here is an example of using the *variable* style to perform the same
box deformation as the *wiggle* style formula listed above, where we
fix 2 all deform 1 xy variable v_displace v_rate remap v
----------
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 *flip* keyword below, to allow this bound to
be exceeded, if desired.
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.
To obey this constraint and allow for large shear deformations to be
applied via the *xy*\ , *xz*\ , or *yz* parameters, the following
algorithm is used. If *prd* 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.
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.
----------
Each time the box size or shape is changed, the *remap* keyword
determines whether atom positions are remapped to the new box. If
*remap* is set to *x* (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 *remap* is set to *v*\ ,
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 *remap* is set to
*none*\ , then neither of these remappings take place.
Conceptually, setting *remap* to *x* 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 *remap* to *v* 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.
.. note::
When non-equilibrium MD (NEMD) simulations are performed using
this fix, the option "remap v" should normally be used. This is
because :doc:`fix nvt/sllod <fix_nvt_sllod>` 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 *remap* setting
is not consistent with fix nvt/sllod.
.. note::
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 :doc:`fix nvt/sllod <fix_nvt_sllod>` or :doc:`fix lavgevin <doc/fix_langevin>`
(with a bias provided by :doc:`compute temp/deform <compute_temp_deform>`), 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 :doc:`fix ave/chunk <fix_ave_chunk>`, :doc:`compute temp/deform <compute_temp_deform>`, and :doc:`compute temp/profile <compute_temp_profile>` commands. One way to induce
atoms to stream consistent with the box deformation is to give them an
initial velocity profile, via the :doc:`velocity ramp <velocity>`
command, that matches the box deformation rate. This also typically
helps the system come to equilibrium more quickly, even if a
thermostat is used.
.. note::
If a :doc:`fix rigid <fix_rigid>` is defined for rigid bodies, and
*remap* is set to *x*\ , 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 *remap* is set to *v*\ , since :doc:`fix nvt/sllod <fix_nvt_sllod>` 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 :doc:`fix nvt/sllod <fix_nvt_sllod>`.
The *flip* keyword allows the tilt factors for a triclinic box to
exceed half the distance of the parallel box length, as discussed
above. If the *flip* value is set to *yes*\ , the bound is enforced by
flipping the box when it is exceeded. If the *flip* value is set to
*no*\ , 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.
The *units* keyword determines the meaning of the distance units used
to define various arguments. A *box* value selects standard distance
units as defined by the :doc:`units <units>` command, e.g. Angstroms for
units = real or metal. A *lattice* value means the distance units are
in lattice spacings. The :doc:`lattice <lattice>` command must have
been previously used to define the lattice spacing. Note that the
units choice also affects the *vel* style parameters since it is
defined in terms of distance/time. Also note that the units keyword
does not affect the *variable* style. You should use the *xlat*\ ,
*ylat*\ , *zlat* keywords of the :doc:`thermo_style <thermo_style>`
command if you want to include lattice spacings in a variable formula.
----------
-Styles with a *cuda*\ , *gpu*\ , *intel*\ , *kk*\ , *omp*\ , or *opt* suffix are
+Styles with a *gpu*\ , *intel*\ , *kk*\ , *omp*\ , or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in :doc:`Section_accelerate <Section_accelerate>`
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
-These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the :ref:`Making LAMMPS <start_3>` section for more info.
+These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the :ref:`Making LAMMPS <start_3>` section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :ref:`-suffix command-line switch <start_7>` when you invoke LAMMPS, or you can
use the :doc:`suffix <suffix>` command in your input script.
See :doc:`Section_accelerate <Section_accelerate>` of the manual for
more instructions on how to use the accelerated styles effectively.
Restart, fix_modify, output, run start/stop, minimize info
* ID, group-ID are documented in :doc:`fix <fix>` command
* style_name = *nvt* or *npt* or *nph*
* one or more keyword/value pairs may be appended
.. parsed-literal::
keyword = *temp* or *iso* or *aniso* or *tri* or *x* or *y* or *z* or *xy* or *yz* or *xz* or *couple* or *tchain* or *pchain* or *mtk* or *tloop* or *ploop* or *nreset* or *drag* or *dilate* or *scalexy* or *scaleyz* or *scalexz* or *flip* or *fixedpoint* or *update*
*temp* values = Tstart Tstop Tdamp
Tstart,Tstop = external temperature at start/end of run
Tdamp = temperature damping parameter (time units)
*iso* or *aniso* or *tri* values = Pstart Pstop Pdamp
Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
Pdamp = pressure damping parameter (time units)
*x* or *y* or *z* or *xy* or *yz* or *xz* values = Pstart Pstop Pdamp
Pstart,Pstop = external stress tensor component at start/end of run (pressure units)
Pdamp = stress damping parameter (time units)
*couple* = *none* or *xyz* or *xy* or *yz* or *xz*
*tchain* value = N
N = length of thermostat chain (1 = single thermostat)
*pchain* values = N
N length of thermostat chain on barostat (0 = no thermostat)
*mtk* value = *yes* or *no* = add in MTK adjustment term or not
*tloop* value = M
M = number of sub-cycles to perform on thermostat
*ploop* value = M
M = number of sub-cycles to perform on barostat thermostat
*nreset* value = reset reference cell every this many timesteps
*drag* value = Df
Df = drag factor added to barostat/thermostat (0.0 = no drag)
*dilate* value = dilate-group-ID
dilate-group-ID = only dilate atoms in this group due to barostat volume changes
*scalexy* value = *yes* or *no* = scale xy with ly
*scaleyz* value = *yes* or *no* = scale yz with lz
*scalexz* value = *yes* or *no* = scale xz with lz
*flip* value = *yes* or *no* = allow or disallow box flips when it becomes highly skewed
*fixedpoint* values = x y z
x,y,z = perform barostat dilation/contraction around this point (distance units)
*update* value = *dipole* update dipole orientation (only for sphere variants)
Examples
""""""""
.. parsed-literal::
fix 1 all nvt temp 300.0 300.0 100.0
fix 1 water npt temp 300.0 300.0 100.0 iso 0.0 0.0 1000.0
* ID, group-ID are documented in :doc:`fix <fix>` command
.. parsed-literal::
one or more keyword value pairs may be appended
keyword = *temp* or *iso* or *aniso* or *tri* or *x* or *y* or *z* or *couple* or *tchain* or *pchain* or *mtk* or *tloop* or *ploop* or *nreset* or *drag* or *dilate* or *scaleyz* or *scalexz* or *scalexy*
*temp* values = Value1 Value2 Tdamp
Value1, Value2 = Nose-Hoover target temperatures, ignored by Hugoniostat
Tdamp = temperature damping parameter (time units)
*iso* or *aniso* or *tri* values = Pstart Pstop Pdamp
Pstart,Pstop = scalar external pressures, must be equal (pressure units)
Pdamp = pressure damping parameter (time units)
*x* or *y* or *z* or *xy* or *yz* or *xz* values = Pstart Pstop Pdamp
Pstart,Pstop = external stress tensor components, must be equal (pressure units)
Pdamp = stress damping parameter (time units)
*couple* = *none* or *xyz* or *xy* or *yz* or *xz*
*tchain* value = length of thermostat chain (1 = single thermostat)
*pchain* values = length of thermostat chain on barostat (0 = no thermostat)
*mtk* value = *yes* or *no* = add in MTK adjustment term or not
*tloop* value = number of sub-cycles to perform on thermostat
*ploop* value = number of sub-cycles to perform on barostat thermostat
*nreset* value = reset reference cell every this many timesteps
*drag* value = drag factor added to barostat/thermostat (0.0 = no drag)
*dilate* value = *all* or *partial*
*scaleyz* value = *yes* or *no* = scale yz with lz
*scalexz* value = *yes* or *no* = scale xz with lz
*scalexy* value = *yes* or *no* = scale xy with ly
Examples
""""""""
.. parsed-literal::
fix myhug all nphug temp 1.0 1.0 10.0 z 40.0 40.0 70.0
fix myhug all nphug temp 1.0 1.0 10.0 iso 40.0 40.0 70.0 drag 200.0 tchain 1 pchain 0
Description
"""""""""""
This command is a variant of the Nose-Hoover
:doc:`fix npt <fix_nh>` fix style.
It performs time integration of the Hugoniostat equations
of motion developed by Ravelo et al. :ref:`(Ravelo) <Ravelo>`.
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.
The compression can be performed
either
hydrostatically (using keyword *iso*\ , *aniso*\ , or *tri*\ ) or uniaxially
(using keywords *x*\ , *y*\ , or *z*\ ). 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).
This leads to the following additional restrictions on the keywords:
* One and only one of the following keywords should be used: *iso*\ , *aniso*\ , *tri*\ , *x*\ , *y*\ , *z*
* The specified initial and final target pressures must be the same.
* The keywords *xy*\ , *xz*\ , *yz* may not be used.
* The only admissible value for the couple keyword is *xyz*\ , which has the same effect as keyword *iso*
* The *temp* keyword must be used to specify the time constant for kinetic energy relaxation, but initial and final target temperature values are ignored.
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:
.. image:: Eqs/fix_nphug.jpg
:align: center
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.
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 *e0*\ ,
*v0*\ , and *p0* described below.
----------
.. note::
Unlike the :doc:`fix temp/berendsen <fix_temp_berendsen>` 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 :doc:`fix nve <fix_nve>` 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 :doc:`fix langevin <fix_nh>` or :doc:`fix temp/rescale <fix_temp_rescale>` commands.
----------
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:
fix ID group-ID style bodystyle args keyword values ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* style = *rigid* or *rigid/nve* or *rigid/nvt* or *rigid/npt* or *rigid/nph* or *rigid/small* or *rigid/nve/small* or *rigid/nvt/small* or *rigid/npt/small* or *rigid/nph/small*
* bodystyle = *single* or *molecule* or *group*
.. parsed-literal::
*single* args = none
*molecule* args = none
*group* args = N groupID1 groupID2 ...
N = # of groups
groupID1, groupID2, ... = list of N group IDs
* zero or more keyword/value pairs may be appended
* keyword = *langevin* or *temp* or *iso* or *aniso* or *x* or *y* or *z* or *couple* or *tparam* or *pchain* or *dilate* or *force* or *torque* or *infile*
.. parsed-literal::
*langevin* values = Tstart Tstop Tperiod seed
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)
*temp* values = Tstart Tstop Tdamp
Tstart,Tstop = desired temperature at start/stop of run (temperature units)
Tdamp = temperature damping parameter (time units)
*iso* or *aniso* values = Pstart Pstop Pdamp
Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
Pdamp = pressure damping parameter (time units)
*x* or *y* or *z* values = Pstart Pstop Pdamp
Pstart,Pstop = external stress tensor component at start/end of run (pressure units)
Pdamp = stress damping parameter (time units)
*couple* = *none* or *xyz* or *xy* or *yz* or *xz*
*tparam* 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
*pchain* values = Pchain
Pchain = length of the Nose/Hoover thermostat chain coupled with the barostat
*dilate* value = dilate-group-ID
dilate-group-ID = only dilate atoms in this group due to barostat volume changes
*force* 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
*torque* 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
*infile* filename
filename = file with per-body values of mass, center-of-mass, moments of inertia
*mol* value = template-ID
template-ID = ID of molecule template specified in a separate :doc:`molecule <molecule>` command
Examples
""""""""
.. parsed-literal::
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
* style = *none* or *ewald* or *ewald/disp* or *ewald/omp* or *pppm* or *pppm/cg* or *pppm/disp* or *pppm/tip4p* or *pppm/stagger* or *pppm/disp/tip4p* or *pppm/gpu* or *pppm/omp* or *pppm/cg/omp* or *pppm/tip4p/omp* or *msm* or *msm/cg* or *msm/omp* or *msm/cg/omp*
.. parsed-literal::
*none* value = none
*ewald* value = accuracy
accuracy = desired relative error in forces
*ewald/disp* value = accuracy
accuracy = desired relative error in forces
*ewald/omp* value = accuracy
accuracy = desired relative error in forces
*pppm* value = accuracy
accuracy = desired relative error in forces
*pppm/cg* value = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units)
*pppm/disp* value = accuracy
accuracy = desired relative error in forces
*pppm/tip4p* value = accuracy
accuracy = desired relative error in forces
*pppm/disp/tip4p* value = accuracy
accuracy = desired relative error in forces
*pppm/gpu* value = accuracy
accuracy = desired relative error in forces
*pppm/omp* value = accuracy
accuracy = desired relative error in forces
*pppm/cg/omp* value = accuracy
accuracy = desired relative error in forces
*pppm/tip4p/omp* value = accuracy
accuracy = desired relative error in forces
*pppm/stagger* value = accuracy
accuracy = desired relative error in forces
*msm* value = accuracy
accuracy = desired relative error in forces
*msm/cg* value = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units)
*msm/omp* value = accuracy
accuracy = desired relative error in forces
*msm/cg/omp* value = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units)
Examples
""""""""
.. parsed-literal::
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
Description
"""""""""""
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.
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.
Note that using a long-range solver requires use of a matching :doc:`pair style <pair>` 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:
+----------------------+-----------------------+
| Pair style | KSpace style |
+----------------------+-----------------------+
| coul/long | ewald or pppm |
+----------------------+-----------------------+
| coul/msm | msm |
+----------------------+-----------------------+
| lj/long or buck/long | disp (for dispersion) |
+----------------------+-----------------------+
| tip4p/long | tip4p |
+----------------------+-----------------------+
----------
The *ewald* style performs a standard Ewald summation as described in
any solid-state physics text.
The *ewald/disp* style adds a long-range dispersion sum option for
1/r^6 potentials and is useful for simulation of interfaces
:ref:`(Veld) <Veld>`. It also performs standard Coulombic Ewald summations,
but in a more efficient manner than the *ewald* 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 *ewald/disp* style can also be used with point-dipoles
:ref:`(Toukmaji) <Toukmaji>` and is currently the only kspace solver in
LAMMPS with this capability.
----------
The *pppm* style invokes a particle-particle particle-mesh solver
:ref:`(Hockney) <Hockney>` 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) :ref:`(Darden) <Darden>` 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
choice :ref:`(Pollock) <Pollock>`.
The *pppm/cg* style is identical to the *pppm* style except that it
has an optimization for systems where most particles are uncharged.
Similarly the *msm/cg* style implements the same optimization for *msm*\ .
The optional *smallq* argument defines the cutoff for the absolute
charge value which determines whether a particle is considered charged
or not. Its default value is 1.0e-5.
The *pppm/tip4p* style is identical to the *pppm* style except that it
adds a charge at the massless 4th site in each TIP4P water molecule.
It should be used with :doc:`pair styles <pair_style>` with a
*tip4p/long* in their style name.
The *pppm/stagger* style 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
for a given mesh size. Or a coarser mesh can be used for the same
target accuracy, which saves CPU time. However, there is a trade-off
since FFTs on two meshes are now performed which increases the
compuation required. See :ref:`(Cerutti) <Cerutti>`, :ref:`(Neelov) <Neelov>`,
and :ref:`(Hockney) <Hockney>` for details of the method.
For high relative accuracy, using staggered PPPM allows the mesh size
to be reduced by a factor of 2 in each dimension as compared to
regular PPPM (for the same target accuracy). This can give up to a 4x
speedup in the KSpace time (8x less mesh points, 2x more expensive).
However, for low relative accuracy, the staggered PPPM mesh size may
be essentially the same as for regular PPPM, which means the method
will be up to 2x slower in the KSpace time (simply 2x more expensive).
For more details and timings, see
:doc:`Section_accelerate <Section_accelerate>`.
.. note::
Using *pppm/stagger* may not give the same increase in the
accuracy of energy and pressure as it does in forces, so some caution
must be used if energy and/or pressure are quantities of interest,
such as when using a barostat.
----------
The *pppm/disp* and *pppm/disp/tip4p* styles add a mesh-based long-range
dispersion sum option for 1/r^6 potentials :ref:`(Isele-Holder) <Isele-Holder>`,
similar to the *ewald/disp* 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.
For these styles, you will possibly want to adjust the default choice of
parameters by using the :doc:`kspace_modify <kspace_modify>` command.
This can be done by either choosing the Ewald and grid parameters, or
by specifying separate accuracies for the real and kspace
calculations. When not making any settings, the simulation will stop with
an error message. Further information on the influence of the parameters
and how to choose them is described in :ref:`(Isele-Holder) <Isele-Holder>`,
:ref:`(Isele-Holder2) <Isele-Holder2>` and the
:ref:`How-To <howto_24>` discussion.
----------
.. note::
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 :ref:`this section <start_2_4>` of the manual. MSM does not
currently support the -DFFT_SINGLE compiler switch.
----------
The *msm* style invokes a multi-level summation method MSM solver,
:ref:`(Hardy) <Hardy>` or :ref:`(Hardy2) <Hardy2>`, 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.
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.
Currently calculation of the full pressure tensor in MSM is expensive.
Using the :doc:`kspace_modify <kspace_modify>` *pressure/scalar yes*
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.
----------
The specified *accuracy* 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.
The accuracy setting is used in conjunction with the pairwise cutoff
to determine the number of K-space vectors for style *ewald* or the
grid size for style *pppm* or *msm*\ .
Note that style *pppm* 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
:doc:`kspace_modify slab <kspace_modify>` 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
:doc:`kspace_modify <kspace_modify>` *mesh* command to manually set the
PPPM grid size to this value.
RMS force errors in real space for *ewald* and *pppm* are estimated
using equation 18 of :ref:`(Kolafa) <Kolafa>`, which is also referenced as
equation 9 of :ref:`(Petersen) <Petersen>`. RMS force errors in K-space for
*ewald* are estimated using equation 11 of :ref:`(Petersen) <Petersen>`,
which is similar to equation 32 of :ref:`(Kolafa) <Kolafa>`. RMS force
errors in K-space for *pppm* are estimated using equation 38 of
:ref:`(Deserno) <Deserno>`. RMS force errors for *msm* are estimated
using ideas from chapter 3 of :ref:`(Hardy) <Hardy>`, with equation 3.197
of particular note. When using *msm* with non-periodic boundary
conditions, it is expected that the error estimation will be too
pessimistic. RMS force errors for dipoles when using *ewald/disp*
are estimated using equations 33 and 46 of :ref:`(Wang) <Wang>`.
See the :doc:`kspace_modify <kspace_modify>` command for additional
options of the K-space solvers that can be set, including a *force*
option for setting an absoulte RMS error in forces, as opposed to a
relative RMS error.
----------
-Styles with a *cuda*\ , *gpu*\ , *intel*\ , *kk*\ , *omp*\ , or *opt* suffix are
+Styles with a *gpu*\ , *intel*\ , *kk*\ , *omp*\ , or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in :doc:`Section_accelerate <Section_accelerate>`
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
More specifically, the *pppm/gpu* 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 *pppm/gpu* 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.
-These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
+These accelerated styles are part of the GPU, USER-INTEL,
KOKKOS, USER-OMP, and OPT packages respectively. They are only
enabled if LAMMPS was built with those packages. See the :ref:`Making LAMMPS <start_3>` section for more info.
See :doc:`Section_accelerate <Section_accelerate>` of the manual for
more instructions on how to use the accelerated styles effectively.
Restrictions
""""""""""""
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.
-The *ewald/disp*\ , *ewald*\ , *pppm*\ , and *msm* styles support
-non-orthogonal (triclinic symmetry) simulation boxes. However, triclinic
-simulation cells may not yet be supported by suffix versions of these
-styles (such as *pppm/cuda*\ ).
+The *ewald/disp*\ , *ewald*\ , *pppm*\ , and *msm* styles support
+non-orthogonal (triclinic symmetry) simulation boxes. However,
+triclinic simulation cells may not yet be supported by suffix versions
+of these styles.
All of the kspace styles are part of the KSPACE package. They are
only enabled if LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info. Note that
the KSPACE package is installed by default.
For MSM, a simulation must be 3d and one can use any combination of
periodic, non-periodic, or shrink-wrapped boundaries (specified using
the :doc:`boundary <boundary>` command).
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 :doc:`kspace_modify <kspace_modify>`,
in which case the xy dimensions must be periodic and the z dimension must be
Styles *brownian* and *brownain/poly* compute Brownian forces and
torques on finite-size spherical particles. The former requires
monodisperse spherical particles; the latter allows for polydisperse
spherical particles.
These pair styles are designed to be used with either the :doc:`pair_style lubricate <pair_lubricate>` or :doc:`pair_style lubricateU <pair_lubricateU>` commands to provide thermostatting
when dissipative lubrication forces are acting. Thus the parameters
*mu*\ , *flaglog*\ , *flagfld*\ , *cutinner*\ , and *cutoff* should be
specified consistent with the settings in the lubrication pair styles.
For details, refer to either of the lubrication pair styles.
The *t_target* setting is used to specify the target temperature of
the system. The random number *seed* is used to generate random
numbers for the thermostatting procedure.
The *flagHI* and *flagVF* settings are optional. Neither should be
used, or both must be defined.
----------
The following coefficients must be defined for each pair of atoms
types via the :doc:`pair_coeff <pair_coeff>` command as in the examples
above, or in the data file or restart files read by the
:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
commands, or by mixing as described below:
* cutinner (distance units)
* cutoff (distance units)
The two coefficients are optional. If neither is specified, the two
cutoffs specified in the pair_style command are used. Otherwise both
must be specified.
----------
-Styles with a *cuda*\ , *gpu*\ , *intel*\ , *kk*\ , *omp*\ , or *opt* suffix are
+Styles with a *gpu*\ , *intel*\ , *kk*\ , *omp*\ , or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in :doc:`this section <Section_accelerate>` of
the manual. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
-These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the :ref:`Making LAMMPS <start_3>` section for more info.
+These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the :ref:`Making LAMMPS <start_3>` section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :ref:`-suffix command-line switch <start_7>` when you invoke LAMMPS, or you can
use the :doc:`suffix <suffix>` command in your input script.
See :doc:`this section <Section_accelerate>` of the manual for more
instructions on how to use the accelerated styles effectively.
* style = *lj/cut* or *lj/cut/coul/cut* or *lj/cut/coul/debye* or *lj/cut/coul/dsf* or *lj/cut/coul/long* or *lj/cut/coul/long/cs* or *lj/cut/coul/msm* or *lj/cut/tip4p/long*
* args = list of arguments for a particular style
.. parsed-literal::
*lj/cut* args = cutoff
cutoff = global cutoff for Lennard Jones interactions (distance units)
*lj/cut/coul/cut* args = cutoff (cutoff2)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
*lj/cut/coul/debye* args = kappa cutoff (cutoff2)
kappa = inverse of the Debye length (inverse distance units)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
* style = *lj/cut/soft* or *lj/cut/coul/cut/soft* or *lj/cut/coul/long/soft* or *lj/cut/tip4p/long/soft* or *lj/charmm/coul/long/soft* or *coul/cut/soft* or *coul/long/soft* or *tip4p/long/soft*
* args = list of arguments for a particular style
.. parsed-literal::
*lj/cut/soft* args = n alpha_lj cutoff
n, alpha_LJ = parameters of soft-core potential
cutoff = global cutoff for Lennard-Jones interactions (distance units)
*lj/cut/coul/cut/soft* 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)
*lj/cut/coul/long/soft* 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)
-<p>No additional compile/link flags are needed in Makefile.machine.</p>
-<p>Note that if you change the USER-CUDA library precision (discussed
-above) and rebuild the USER-CUDA library, then you also need to
-re-install the USER-CUDA package and re-build LAMMPS, so that all
-affected files are re-compiled and linked to the new USER-CUDA
-library.</p>
-<p><strong>Run with the USER-CUDA package from the command line:</strong></p>
-<p>The mpirun or mpiexec command sets the total number of MPI tasks used
-by LAMMPS (one or multiple per compute node) and the number of MPI
-tasks used per node. E.g. the mpirun command in MPICH does this via
-its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.</p>
-<p>When using the USER-CUDA package, you must use exactly one MPI task
-per physical GPU.</p>
-<p>You must use the “-c on” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> to enable the USER-CUDA package.
-The “-c on” switch also issues a default <a class="reference internal" href="package.html"><span class="doc">package cuda 1</span></a>
-command which sets various USER-CUDA options to default values, as
-discussed on the <a class="reference internal" href="package.html"><span class="doc">package</span></a> command doc page.</p>
-<p>The syntax for the “-pk” switch is the same as same as the “package
-cuda” 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 cuda</span></a> command is
-to set the Newton flag to “off” for both pairwise and bonded
-interactions. This typically gives fastest performance. If the
-<a class="reference internal" href="newton.html"><span class="doc">newton</span></a> command is used in the input script, it can
-override these defaults.</p>
-<p><strong>Or run with the USER-CUDA package by editing an input script:</strong></p>
-<p>The discussion above for the mpirun/mpiexec command and the requirement
-of one MPI task per GPU is the same.</p>
-<p>You must still use the “-c on” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> to enable the USER-CUDA package.</p>
-<p>Use the <a class="reference internal" href="suffix.html"><span class="doc">suffix cuda</span></a> command, or you can explicitly add a
-“cuda” suffix to individual styles in your input script, e.g.</p>
-<p>You only need to use the <a class="reference internal" href="package.html"><span class="doc">package cuda</span></a> command if you
-wish to change any of its option defaults, including the number of
-GPUs/node (default = 1), as set by the “-c on” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>.</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 USER-CUDA package on different
-hardware.</p>
-<p><strong>Guidelines for best performance:</strong></p>
-<ul class="simple">
-<li>The USER-CUDA package offers more speed-up relative to CPU performance
-when the number of atoms per GPU is large, e.g. on the order of tens
-or hundreds of 1000s.</li>
-<li>As noted above, this package will continue to run a simulation
-entirely on the GPU(s) (except for inter-processor MPI communication),
-for multiple timesteps, until a CPU calculation is required, either by
-a fix or compute that is non-GPU-ized, or until output is performed
-(thermo or dump snapshot or restart file). The less often this
-occurs, the faster your simulation will run.</li>
- Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
respectively. Or the effect of the “-pk” or “-sf” switches can be
duplicated by adding the <a class="reference internal" href="package.html"><span class="doc">package kokkos</span></a> or <a class="reference internal" href="suffix.html"><span class="doc">suffix kk</span></a> commands respectively to your input script.</p>
<p>Or you can follow these steps:</p>
<p>CPU-only (run all-MPI or with OpenMP threading):</p>
<p>KOKKOS_DEVICE sets the parallelization method used for Kokkos code
(within LAMMPS). KOKKOS_DEVICES=OpenMP means that OpenMP will be
used. KOKKOS_DEVICES=Pthreads means that pthreads will be used.
KOKKOS_DEVICES=Cuda means an NVIDIA GPU running CUDA will be used.</p>
<p>If KOKKOS_DEVICES=Cuda, then the lo-level Makefile in the src/MAKE
directory must use “nvcc” as its compiler, via its CC setting. For
best performance its CCFLAGS setting should use -O3 and have a
KOKKOS_ARCH setting that matches the compute capability of your NVIDIA
hardware and software installation, e.g. KOKKOS_ARCH=Kepler30. Note
the minimal required compute capability is 2.0, but this will give
signicantly reduced performance compared to Kepler generation GPUs
with compute capability 3.x. For the LINK setting, “nvcc” should not
be used; instead use g++ or another compiler suitable for linking C++
applications. Often you will want to use your MPI compiler wrapper
for this setting (i.e. mpicxx). Finally, the lo-level Makefile must
also have a “Compilation rule” for creating <a href="#id1"><span class="problematic" id="id2">*</span></a>.o files from <a href="#id3"><span class="problematic" id="id4">*</span></a>.cu files.
See src/Makefile.cuda for an example of a lo-level Makefile with all
of these settings.</p>
<p>KOKKOS_USE_TPLS=hwloc binds threads to hardware cores, so they do not
migrate during a simulation. KOKKOS_USE_TPLS=hwloc should always be
used if running with KOKKOS_DEVICES=Pthreads for pthreads. It is not
necessary for KOKKOS_DEVICES=OpenMP for OpenMP, because OpenMP
provides alternative methods via environment variables for binding
threads to hardware cores. More info on binding threads to cores is
given in <span class="xref std std-ref">this section</span>.</p>
<p>KOKKOS_ARCH=KNC enables compiler switches needed when compling for an
Intel Phi processor.</p>
<p>KOKKOS_USE_TPLS=librt enables use of a more accurate timer mechanism
on most Unix platforms. This library is not available on all
platforms.</p>
<p>KOKKOS_DEBUG is only useful when developing a Kokkos-enabled style
within LAMMPS. KOKKOS_DEBUG=yes enables printing of run-time
debugging information that can be useful. It also enables runtime
bounds checking on Kokkos data structures.</p>
<p>KOKKOS_CUDA_OPTIONS are additional options for CUDA.</p>
<p>For more information on Kokkos see the Kokkos programmers’ guide here:
/lib/kokkos/doc/Kokkos_PG.pdf.</p>
<p><strong>Run with the KOKKOS package from the command line:</strong></p>
<p>The mpirun or mpiexec command sets the total number of MPI tasks used
by LAMMPS (one or multiple per compute node) and the number of MPI
tasks used per node. E.g. the mpirun command in MPICH does this via
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.</p>
<p>When using KOKKOS built with host=OMP, you need to choose how many
OpenMP threads per MPI task will be used (via the “-k” command-line
switch discussed below). Note that the product of MPI tasks * OpenMP
threads/task should not exceed the physical number of cores (on a
node), otherwise performance will suffer.</p>
<p>When using the KOKKOS package built with device=CUDA, you must use
exactly one MPI task per physical GPU.</p>
<p>When using the KOKKOS package built with host=MIC for Intel Xeon Phi
coprocessor support you need to insure there are one or more MPI tasks
per coprocessor, and choose the number of coprocessor threads to use
per MPI task (via the “-k” command-line switch discussed below). The
product of MPI tasks * coprocessor threads/task should not exceed the
maximum number of threads the coproprocessor is designed to run,
otherwise performance will suffer. This value is 240 for current
generation Xeon Phi(TM) chips, which is 60 physical cores * 4
threads/core. Note that with the KOKKOS package you do not need to
specify how many Phi coprocessors there are per node; each
coprocessors is simply treated as running some number of MPI tasks.</p>
<p>You must use the “-k on” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> to enable the KOKKOS package. It
takes additional arguments for hardware settings appropriate to your
system. Those arguments are <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">documented here</span></a>. The two most commonly used
which will automatically append “kk” to styles that support it. Use
the “-pk kokkos” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> if
you wish to change any of the default <a class="reference internal" href="package.html"><span class="doc">package kokkos</span></a>
optionns set by the “-k on” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>.</p>
<p>Note that the default for the <a class="reference internal" href="package.html"><span class="doc">package kokkos</span></a> command is
to use “full” neighbor lists and set the Newton flag to “off” for both
pairwise and bonded interactions. This typically gives fastest
performance. If the <a class="reference internal" href="newton.html"><span class="doc">newton</span></a> command is used in the input
script, it can override the Newton flag defaults.</p>
<p>However, when running in MPI-only mode with 1 thread per MPI task, it
will typically be faster to use “half” neighbor lists and set the
Newton flag to “on”, just as is the case for non-accelerated pair
styles. You can do this with the “-pk” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>.</p>
<p><strong>Or run with the KOKKOS package by editing an input script:</strong></p>
<p>The discussion above for the mpirun/mpiexec command and setting
appropriate thread and GPU values for host=OMP or host=MIC or
device=CUDA are the same.</p>
<p>You must still use the “-k on” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> to enable the KOKKOS package, and
specify its additional arguments for hardware options appopriate to
your system, as documented above.</p>
<p>Use the <a class="reference internal" href="suffix.html"><span class="doc">suffix kk</span></a> command, or you can explicitly add a
“kk” suffix to individual styles in your input script, e.g.</p>
<p>The performance of KOKKOS running in different modes is a function of
your hardware, which KOKKOS-enable styles are used, and the problem
size.</p>
<p>Generally speaking, the following rules of thumb apply:</p>
<ul class="simple">
<li>When running on CPUs only, with a single thread per MPI task,
performance of a KOKKOS style is somewhere between the standard
(un-accelerated) styles (MPI-only mode), and those provided by the
USER-OMP package. However the difference between all 3 is small (less
than 20%).</li>
<li>When running on CPUs only, with multiple threads per MPI task,
performance of a KOKKOS style is a bit slower than the USER-OMP
package.</li>
-<li>When running on GPUs, KOKKOS is typically faster than the USER-CUDA
-and GPU packages.</li>
+<li>When running large number of atoms per GPU, KOKKOS is typically faster
+than the GPU package.</li>
<li>When running on Intel Xeon Phi, KOKKOS is not as fast as
the USER-INTEL package, which is optimized for that hardware.</li>
</ul>
<p>See the <a class="reference external" href="http://lammps.sandia.gov/bench.html">Benchmark page</a> of the
LAMMPS web site for performance of the KOKKOS package on different
hardware.</p>
<p><strong>Guidelines for best performance:</strong></p>
<p>Here are guidline for using the KOKKOS package on the different
hardware configurations listed above.</p>
<p>Many of the guidelines use the <a class="reference internal" href="package.html"><span class="doc">package kokkos</span></a> command
See its doc page for details and default settings. Experimenting with
its options can provide a speed-up for specific calculations.</p>
<p><strong>Running on a multi-core CPU:</strong></p>
<p>If N is the number of physical cores/node, then the number of MPI
tasks/node * number of threads/task should not exceed N, and should
typically equal N. Note that the default threads/task is 1, as set by
the “t” keyword of the “-k” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>. If you do not change this, no
additional parallelism (beyond MPI) will be invoked on the host
CPU(s).</p>
<p>You can compare the performance running in different modes:</p>
<ul class="simple">
<li>run with 1 MPI task/node and N threads/task</li>
<li>run with N MPI tasks/node and 1 thread/task</li>
<li>run with settings in between these extremes</li>
</ul>
<p>Examples of mpirun commands in these modes are shown above.</p>
<p>When using KOKKOS to perform multi-threading, it is important for
performance to bind both MPI tasks to physical cores, and threads to
physical cores, so they do not migrate during a simulation.</p>
<p>If you are not certain MPI tasks are being bound (check the defaults
for your MPI installation), binding can be forced with these flags:</p>
<p>For binding threads with the KOKKOS OMP option, use thread affinity
environment variables to force binding. With OpenMP 3.1 (gcc 4.7 or
later, intel 12 or later) setting the environment variable
OMP_PROC_BIND=true should be sufficient. For binding threads with the
KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option, as
discussed in <a class="reference internal" href="Section_start.html#start-3-4"><span class="std std-ref">Section 2.3.4</span></a> of the
manual.</p>
<p><strong>Running on GPUs:</strong></p>
<p>Insure the -arch setting in the machine makefile you are using,
e.g. src/MAKE/Makefile.cuda, is correct for your GPU hardware/software
(see <a class="reference internal" href="Section_start.html#start-3-4"><span class="std std-ref">this section</span></a> of the manual for
details).</p>
<p>The -np setting of the mpirun command should set the number of MPI
tasks/node to be equal to the # of physical GPUs on the node.</p>
<p>Use the “-k” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> to
specify the number of GPUs per node, and the number of threads per MPI
task. As above for multi-core CPUs (and no GPU), if N is the number
of physical cores/node, then the number of MPI tasks/node * number of
threads/task should not exceed N. With one GPU (and one MPI task) it
may be faster to use less than all the available cores, by setting
threads/task to a smaller value. This is because using all the cores
on a dual-socket node will incur extra cost to copy memory from the
2nd socket to the GPU.</p>
<p>Examples of mpirun commands that follow these rules are shown above.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When using a GPU, you will achieve the best performance if your
input script does not use any fix or compute styles which are not yet
Kokkos-enabled. This allows data to stay on the GPU for multiple
timesteps, without being copied back to the host CPU. Invoking a
non-Kokkos fix or compute, or performing I/O for
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo</span></a> or <a class="reference internal" href="dump.html"><span class="doc">dump</span></a> output will cause data
to be copied back to the CPU.</p>
</div>
<p>You cannot yet assign multiple MPI tasks to the same GPU with the
KOKKOS package. We plan to support this in the future, similar to the
GPU package in LAMMPS.</p>
<p>You cannot yet use both the host (multi-threaded) and device (GPU)
together to compute pairwise interactions with the KOKKOS package. We
hope to support this in the future, similar to the GPU package in
LAMMPS.</p>
<p><strong>Running on an Intel Phi:</strong></p>
<p>Kokkos only uses Intel Phi processors in their “native” mode, i.e.
not hosted by a CPU.</p>
<p>As illustrated above, build LAMMPS with OMP=yes (the default) and
MIC=yes. The latter insures code is correctly compiled for the Intel
Phi. The OMP setting means OpenMP will be used for parallelization on
the Phi, which is currently the best option within Kokkos. In the
future, other options may be added.</p>
<p>Current-generation Intel Phi chips have either 61 or 57 cores. One
core should be excluded for running the OS, leaving 60 or 56 cores.
Each core is hyperthreaded, so there are effectively N = 240 (4*60) or
N = 224 (4*56) cores to run on.</p>
<p>The -np setting of the mpirun command sets the number of MPI
tasks/node. The “-k on t Nt” command-line switch sets the number of
threads/task as Nt. The product of these 2 values should be N, i.e.
240 or 224. Also, the number of threads/task should be a multiple of
4 so that logical threads from more than one MPI task do not run on
the same physical core.</p>
<p>Examples of mpirun commands that follow these rules are shown above.</p>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>As noted above, if using GPUs, the number of MPI tasks per compute
node should equal to the number of GPUs per compute node. In the
future Kokkos will support assigning multiple MPI tasks to a single
GPU.</p>
<p>Currently Kokkos does not support AMD GPUs due to limits in the
available backend programming models. Specifically, Kokkos requires
extensive C++ support from the Kernel language. This is expected to
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where Ea is the angle term, Ebb is a bond-bond term, and Eba is a
bond-angle term. Theta0 is the equilibrium angle and r1 and r2 are
the equilibrium bond lengths.</p>
<p>See <a class="reference internal" href="#angle-sun"><span class="std std-ref">(Sun)</span></a> for a description of the COMPASS class2 force field.</p>
<p>Coefficients for the Ea, Ebb, and Eba formulas must be defined for
each angle type via the <a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in
the example above, or in the data file or restart files read by the
<p>These are the 4 coefficients for the Ea formula:</p>
<ul class="simple">
<li>theta0 (degrees)</li>
<li>K2 (energy/radian^2)</li>
<li>K3 (energy/radian^3)</li>
<li>K4 (energy/radian^4)</li>
</ul>
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of the various K are in per-radian.</p>
<p>For the Ebb formula, each line in a <a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a>
command in the input script lists 4 coefficients, the first of which
is “bb” to indicate they are BondBond coefficients. In a data file,
these coefficients should be listed under a “BondBond Coeffs” heading
and you must leave out the “bb”, i.e. only list 3 coefficients after
the angle type.</p>
<ul class="simple">
<li>bb</li>
<li>M (energy/distance^2)</li>
<li>r1 (distance)</li>
<li>r2 (distance)</li>
</ul>
<p>For the Eba formula, each line in a <a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a>
command in the input script lists 5 coefficients, the first of which
is “ba” to indicate they are BondAngle coefficients. In a data file,
these coefficients should be listed under a “BondAngle Coeffs” heading
and you must leave out the “ba”, i.e. only list 4 coefficients after
the angle type.</p>
<ul class="simple">
<li>ba</li>
<li>N1 (energy/distance^2)</li>
<li>N2 (energy/distance^2)</li>
<li>r1 (distance)</li>
<li>r2 (distance)</li>
</ul>
<p>The theta0 value in the Eba formula is not specified, since it is the
same value from the Ea formula.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the CLASS2
package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where theta0 is the equilibrium value of the angle, and K is a
prefactor. Note that the usual 1/2 factor is included in K.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy)</li>
<li>theta0 (degrees)</li>
</ul>
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
internally.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where C, B and n are coefficients defined for each angle type.</p>
<p>See <a class="reference internal" href="#cosine-mayo"><span class="std std-ref">(Mayo)</span></a> for a description of the DREIDING force field</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>C (energy)</li>
<li>B = 1 or -1</li>
<li>n = 1, 2, 3, 4, 5 or 6 for periodicity</li>
</ul>
<p>Note that the prefactor C is specified and not the overall force
constant K = C / n^2. When B = 1, it leads to a minimum for the
linear geometry. When B = -1, it leads to a maximum for the linear
geometry.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where theta0 is the equilibrium angle. The potential is bounded
between -Umin and zero. In the neighborhood of the minimum E=- Umin +
Umin/4(theta-theta0)^2 hence the spring constant is umin/2.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>umin (energy)</li>
<li>theta (angle)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where Umin, theta, and a are defined for each angle type.</p>
<p>The potential is bounded between [-Umin:0] and the minimum is
located at the angle theta0. The a parameter can be both positive or
negative and is used to control the spring constant at the
equilibrium.</p>
<p>The spring constant is given by k = A exp(A) Umin / [2 (Exp(a)-1)].
For a > 3, k/Umin = a/2 to better than 5% relative error. For negative
values of the a parameter, the spring constant is essentially zero,
and anharmonic terms takes over. The potential is furthermore well
behaved in the limit a -> 0, where it has been implemented to linear
order in a for a < 0.001. In this limit the potential reduces to the
cosineshifted potential.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>umin (energy)</li>
<li>theta (angle)</li>
<li>A (real number)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where theta0 is the equilibrium value of the angle, and K is a
prefactor. Note that the usual 1/2 factor is included in K.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy)</li>
<li>theta0 (degrees)</li>
</ul>
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
internally.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where F_i and F_j are applied on atoms i and j, respectively.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy)</li>
<li>gamma0 (degrees)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-6"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-2-3"><span class="std std-ref">Making LAMMPS</span></a>
section for more info on packages.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">In the “Angles” section of the data file, the atom ID ‘j’
corresponding to the dipole to restrain must come before the atom ID
of the reference atom ‘i’. A third atom ID ‘k’ must also be provided,
although ‘k’ is just a ‘dummy’ atom which can be any atom; it may be
useful to choose a convention (e.g., ‘k’=’i’) and adhere to it. For
example, if ID=1 for the dipolar atom to restrain, and ID=2 for the
reference atom, the corresponding line in the “Angles” section of the
data file would read: X X 1 2 2</p>
</div>
<p>The “newton” command for intramolecular interactions must be “on”
(which is the default).</p>
<p>This angle style should not be used with SHAKE.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy)</li>
<li>C0 (real)</li>
<li>C1 (real)</li>
<li>C2 (real)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy)</li>
<li>c (real)</li>
<li>n (real)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where theta0 is the equilibrium value of the angle, and K is a
prefactor. Note that the usual 1/2 factor is included in K.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy/radian^2)</li>
<li>theta0 (degrees)</li>
</ul>
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<blockquote>
<div>none</div></blockquote>
<p>This angle style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where theta0 is the equilibrium value of the angle, and K is a
prefactor. Note that the usual 1/2 factor is included in K.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><span class="doc">angle_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>theta0 (degrees)</li>
<li>K2 (energy/radian^2)</li>
<li>K3 (energy/radian^3)</li>
<li>K4 (energy/radian^4)</li>
</ul>
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<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/cuda</em> or <em>angle/kk</em> or <em>atomic/cuda</em> or <em>atomic/kk</em> or <em>bond/kk</em> or <em>charge/cuda</em> or <em>charge/kk</em> or <em>full/cuda</em> or <em>full/kk</em> or <em>molecular/kk</em></li>
+<li>accelerated styles (with same args) = <em>angle/kk</em> or <em>atomic/kk</em> or <em>bond/kk</em> or <em>charge/kk</em> or <em>full/kk</em> or <em>molecular/kk</em></li>
<p class="last">It is possible to add some attributes, such as a molecule ID, to
atom styles that do not have them via the <a class="reference internal" href="fix_property_atom.html"><span class="doc">fix property/atom</span></a> command. This command also
allows new custom attributes consisting of extra integer or
floating-point values to be added to atoms. See the <a class="reference internal" href="fix_property_atom.html"><span class="doc">fix property/atom</span></a> doc page for examples of cases
where this is useful and details on how to initialize, access, and
output the custom values.</p>
</div>
<p>All of the above styles define point particles, except the <em>sphere</em>,
<em>ellipsoid</em>, <em>electron</em>, <em>peri</em>, <em>wavepacket</em>, <em>line</em>, <em>tri</em>, and
<em>body</em> styles, which define finite-size particles. See <a class="reference internal" href="Section_howto.html#howto-14"><span class="std std-ref">Section_howto 14</span></a> for an overview of using finite-size
particle models with LAMMPS.</p>
<p>All of the point-particle styles assign mass to particles on a
per-type basis, using the <a class="reference internal" href="mass.html"><span class="doc">mass</span></a> command, The finite-size
particle styles assign mass to individual particles on a per-particle
basis.</p>
<p>For the <em>sphere</em> style, the particles are spheres and each stores a
per-particle diameter and mass. If the diameter > 0.0, the particle
is a finite-size sphere. If the diameter = 0.0, it is a point
particle.</p>
<p>For the <em>ellipsoid</em> style, the particles are ellipsoids and each
stores a flag which indicates whether it is a finite-size ellipsoid or
a point particle. If it is an ellipsoid, it also stores a shape
vector with the 3 diamters of the ellipsoid and a quaternion 4-vector
with its orientation.</p>
<p>For the <em>dipole</em> style, a point dipole is defined for each point
particle. Note that if you wish the particles to be finite-size
spheres as in a Stockmayer potential for a dipolar fluid, so that the
particles can rotate due to dipole-dipole interactions, then you need
to use atom_style hybrid sphere dipole, which will assign both a
diameter and dipole moment to each particle.</p>
<p>For the <em>electron</em> style, the particles representing electrons are 3d
Gaussians with a specified position and bandwidth or uncertainty in
position, which is represented by the eradius = electron size.</p>
<p>For the <em>peri</em> style, the particles are spherical and each stores a
per-particle mass and volume.</p>
<p>The <em>dpd</em> style is for dissipative particle dynamics (DPD) particles
which store the particle internal temperature (dpdTheta), internal
conductive energy (uCond) and internal mechanical energy (uMech).</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>cuda</em> or <em>kk</em> suffix are functionally the same as the
+<p>Styles with a <em>kk</em> suffix are functionally the same as the
corresponding style without the suffix. They have been optimized to
run faster, depending on your available hardware, as discussed in
<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.</p>
<p>Note that other acceleration packages in LAMMPS, specifically the GPU,
USER-INTEL, USER-OMP, and OPT packages do not use accelerated atom
styles.</p>
-<p>The accelerated styles are part of the USER-CUDA and KOKKOS packages
-respectively. They are only enabled if LAMMPS was built with those
-packages. See the <a 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 accelerated styles are part of the KOKKOS package. They are only
+enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This command cannot be used after the simulation box is defined by a
<p>Many of the styles listed above are only enabled if LAMMPS was built
with a specific package, as listed below. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The <em>angle</em>, <em>bond</em>, <em>full</em>, <em>molecular</em>, and <em>template</em> styles are
part of the MOLECULE package.</p>
<p>The <em>line</em> and <em>tri</em> styles are part of the ASPHERE package.</p>
<p>The <em>body</em> style is part of the BODY package.</p>
<p>The <em>dipole</em> style is part of the DIPOLE package.</p>
<p>The <em>peri</em> style is part of the PERI package for Peridynamics.</p>
<p>The <em>electron</em> style is part of the USER-EFF package for <a class="reference internal" href="pair_eff.html"><span class="doc">electronic force fields</span></a>.</p>
<p>The <em>dpd</em> style is part of the USER-DPD package for dissipative
particle dynamics (DPD).</p>
<p>The <em>meso</em> style is part of the USER-SPH package for smoothed particle
hydrodyanmics (SPH). See <a class="reference external" href="USER/sph/SPH_LAMMPS_userguide.pdf">this PDF guide</a> to using SPH in LAMMPS.</p>
<p>The <em>wavepacket</em> style is part of the USER-AWPMD package for the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the CLASS2
package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>to define a finite extensible nonlinear elastic (FENE) potential
<a class="reference internal" href="#fene-kremer"><span class="std std-ref">(Kremer)</span></a>, used for bead-spring polymer models. The first
term is attractive, the 2nd Lennard-Jones term is repulsive. The
first term extends to R0, the maximum extent of the bond. The 2nd
term is cutoff at 2^(1/6) sigma, the minimum of the LJ potential.</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy/distance^2)</li>
<li>R0 (distance)</li>
<li>epsilon (energy)</li>
<li>sigma (distance)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
<p>You typically should specify <a class="reference external" href="special_bonds.html"">special_bonds fene</a>
or <a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds lj/coul 0 1 1</span></a> to use this bond
style. LAMMPS will issue a warning it that’s not the case.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>to define a finite extensible nonlinear elastic (FENE) potential
<a class="reference internal" href="#feneexpand-kremer"><span class="std std-ref">(Kremer)</span></a>, used for bead-spring polymer models. The first
term is attractive, the 2nd Lennard-Jones term is repulsive.</p>
<p>The <em>fene/expand</em> bond style is similar to <em>fene</em> except that an extra
shift factor of delta (positive or negative) is added to <em>r</em> to
effectively change the bead size of the bonded atoms. The first term
now extends to R0 + delta and the 2nd term is cutoff at 2^(1/6) sigma
+ delta.</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy/distance^2)</li>
<li>R0 (distance)</li>
<li>epsilon (energy)</li>
<li>sigma (distance)</li>
<li>delta (distance)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
<p>You typically should specify <a class="reference external" href="special_bonds.html"">special_bonds fene</a>
or <a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds lj/coul 0 1 1</span></a> to use this bond
style. LAMMPS will issue a warning it that’s not the case.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where r0 is the equilibrium bond distance. Note that the usual 1/2
factor is included in K.</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy/distance^2)</li>
<li>r0 (distance)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where r0 is the equilibrium bond distance, and rc the critical distance.
The potential is -Umin at r0 and zero at rc. The spring constant is
k = Umin / [ 2 (r0-rc)^2].</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>Umin (energy)</li>
<li>r0 (distance)</li>
<li>rc (distance)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where r0 is the equilibrium bond distance, and rc the critical distance.
The bond potential is zero for distances r > rc. The potential is -Umin
at r0 and zero at rc. The spring constant is k = Umin / [ 2 (r0-rc)^2].</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>Umin (energy)</li>
<li>r0 (distance)</li>
<li>rc (distance)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where r0 is the equilibrium bond distance, alpha is a stiffness
parameter, and D determines the depth of the potential well.</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>D (energy)</li>
<li>alpha (inverse distance)</li>
<li>r0 (distance)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>to define an anharmonic spring <a class="reference internal" href="#rector"><span class="std std-ref">(Rector)</span></a> of equilibrium
length r0 and maximum extension lamda.</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>epsilon (energy)</li>
<li>r0 (distance)</li>
<li>lamda (distance)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>to define a bond that can be broken as the simulation proceeds (e.g.
due to a polymer being stretched). The sigma and epsilon used in the
LJ portion of the formula are both set equal to 1.0 by LAMMPS.</p>
<p>The following coefficients must be defined for each bond type via the
<a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy/distance^4)</li>
<li>B1 (distance)</li>
<li>B2 (distance)</li>
<li>Rc (distance)</li>
<li>U0 (energy)</li>
</ul>
<p>This potential was constructed to mimic the FENE bond potential for
coarse-grained polymer chains. When monomers with sigma = epsilon =
1.0 are used, the following choice of parameters gives a quartic
potential that looks nearly like the FENE potential: K = 1200, B1 =
-0.55, B2 = 0.25, Rc = 1.3, and U0 = 34.6878. Different parameters
can be specified using the <a class="reference internal" href="bond_coeff.html"><span class="doc">bond_coeff</span></a> command, but
you will need to choose them carefully so they form a suitable bond
potential.</p>
<p>Rc is the cutoff length at which the bond potential goes smoothly to a
local maximum. If a bond length ever becomes > Rc, LAMMPS “breaks”
the bond, which means two things. First, the bond potential is turned
off by setting its type to 0, and is no longer computed. Second, a
pairwise interaction between the two atoms is turned on, since they
are no longer bonded.</p>
<p>LAMMPS does the second task via a computational sleight-of-hand. It
subtracts the pairwise interaction as part of the bond computation.
When the bond breaks, the subtraction stops. For this to work, the
pairwise interaction must always be computed by the
<a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> command, whether the bond is broken or
not. This means that <a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> must be set
to 1,1,1, as indicated as a restriction below.</p>
<p>Note that when bonds are dumped to a file via the <a class="reference internal" href="dump.html"><span class="doc">dump local</span></a> command, bonds with type 0 are not included. The
<a class="reference internal" href="delete_bonds.html"><span class="doc">delete_bonds</span></a> command can also be used to query the
status of broken bonds or permanently delete them, e.g.:</p>
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
<p>The <em>quartic</em> style requires that <a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a>
parameters be set to 1,1,1. Three- and four-body interactions (angle,
dihedral, etc) cannot be used with <em>quartic</em> bonds.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This bond style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>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,
and kspace (long-range) energy. 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. See the doc pages for <a class="reference internal" href="fix.html"><span class="doc">individual fixes</span></a> for
details. The <em>thermo</em> option of the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command determines whether these
contributions are added into the computed potential energy. If no
keywords are specified the default is <em>yes</em>. If any keywords are
specified, the default is <em>no</em>.</p>
<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>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
-functionally the same as the corresponding style without the suffix.
-They have been optimized to run faster, depending on your available
-hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
-<p>You can specify the accelerated styles explicitly in your input script
-by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
-use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
-<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
-more instructions on how to use the accelerated styles effectively.</p>
-<hr class="docutils" />
<p><strong>Output info:</strong></p>
<p>This compute calculates a global scalar (the 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>.
<li>ID, group-ID are documented in <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command</li>
<li>pressure = style name of this compute command</li>
<li>temp-ID = ID of compute that calculates temperature, can be NULL if not needed</li>
<li>zero or more keywords may be appended</li>
<li>keyword = <em>ke</em> or <em>pair</em> or <em>bond</em> or <em>angle</em> or <em>dihedral</em> or <em>improper</em> or <em>kspace</em> or <em>fix</em> or <em>virial</em></li>
<p>Define a computation that calculates the pressure of the entire system
of atoms. The specified group must be “all”. See the <a class="reference internal" href="compute_stress_atom.html"><span class="doc">compute stress/atom</span></a> command if you want per-atom
pressure (stress). These per-atom values could be summed for a group
of atoms via the <a class="reference internal" href="compute_reduce.html"><span class="doc">compute reduce</span></a> command.</p>
<p>If no extra keywords are listed, the entire equations above are
calculated. This includes a kinetic energy (temperature) term and the
virial as the sum of pair, bond, angle, dihedral, improper, kspace
(long-range), and fix contributions to the force on each atom. If any
extra keywords are listed, then only those components are summed to
compute temperature or ke and/or the virial. The <em>virial</em> keyword
means include all terms except the kinetic energy <em>ke</em>.</p>
<p>Details of how LAMMPS computes the virial efficiently for the entire
system, including the effects of periodic boundary conditions is
discussed in <a class="reference internal" href="compute_stress_atom.html#thompson"><span class="std std-ref">(Thompson)</span></a>.</p>
<p>The temperature and kinetic energy tensor is not calculated by this
compute, but rather by the temperature compute specified with the
command. If the kinetic energy is not included in the pressure, than
the temperature compute is not used and can be specified as NULL.
Normally the temperature compute used by compute pressure should
calculate the temperature of all atoms for consistency with the virial
term, but any compute style that calculates temperature can be used,
e.g. one that excludes frozen atoms or other degrees of freedom.</p>
<p>Note that if desired the specified temperature compute can be one that
subtracts off a bias to calculate a temperature using only the thermal
velocity of the atoms, e.g. by subtracting a background streaming
velocity. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias.</p>
<p>Also note that the N in the first formula above is really
degrees-of-freedom divided by d = dimensionality, where the DOF value
is calcluated by the temperature compute. See the various <a class="reference internal" href="compute.html"><span class="doc">compute temperature</span></a> styles for details.</p>
<p>A compute of this style with the ID of “thermo_press” is created when
LAMMPS starts up, as if this command were in the input script:</p>
<p>where “thermo_temp” is the ID of a similarly defined compute of style
“temp”. See the “thermo_style” command for more details.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<hr class="docutils" />
<p><strong>Output info:</strong></p>
<p>This compute calculates a global scalar (the pressure) and a global
vector of length 6 (pressure tensor), which can be accessed by indices
1-6. These values can be used by any command that uses global scalar
or vector values from a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">this section</span></a> for an overview of LAMMPS output
options.</p>
<p>The scalar and vector values calculated by this compute are
“intensive”. The scalar and vector values will be in pressure
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<hr class="docutils" />
<p><strong>Output info:</strong></p>
<p>This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
vector values from a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">this section</span></a> for an overview of LAMMPS output
options.</p>
<p>The scalar value calculated by this compute is “intensive”. The
vector values are “extensive”.</p>
<p>The scalar value will be in temperature <a class="reference internal" href="units.html"><span class="doc">units</span></a>. The
vector values will be in energy <a class="reference internal" href="units.html"><span class="doc">units</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<hr class="docutils" />
<p><strong>Output info:</strong></p>
<p>This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
vector values from a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">this section</span></a> for an overview of LAMMPS output
options.</p>
<p>The scalar value calculated by this compute is “intensive”. The
vector values are “extensive”.</p>
<p>The scalar value will be in temperature <a class="reference internal" href="units.html"><span class="doc">units</span></a>. The
vector values will be in energy <a class="reference internal" href="units.html"><span class="doc">units</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>See <a class="reference internal" href="#dihedral-mackerell"><span class="std std-ref">(MacKerell)</span></a> for a description of the CHARMM
force field. This dihedral style can also be used for the AMBER force
field (see comment on weighting factors below). See
<a class="reference internal" href="#dihedral-cornell"><span class="std std-ref">(Cornell)</span></a> for a description of the AMBER force
field.</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>K (energy)</li>
<li>n (integer >= 0)</li>
<li>d (integer value of degrees)</li>
<li>weighting factor (0.0 to 1.0)</li>
</ul>
<p>The weighting factor is applied to pairwise interaction between the
1st and 4th atoms in the dihedral, which are computed by a CHARMM
<a class="reference internal" href="pair_charmm.html"><span class="doc">pair_style</span></a> with epsilon and sigma values specified
with a <a class="reference internal" href="pair_charmm.html"><span class="doc">pair_coeff</span></a> command. Note that this
weighting factor is unrelated to the weighting 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.</p>
<p>For CHARMM force fields, the special_bonds 1-4 weighting factor should
be set to 0.0. This is because the pair styles that contain “charmm”
(e.g. <a class="reference internal" href="pair_charmm.html"><span class="doc">pair_style lj/charmm/coul/long</span></a>) define extra
1-4 interaction coefficients that are used by this dihedral style to
compute those interactions explicitly. This means that if any of the
weighting factors defined as dihedral coefficients (4th coeff above)
are non-zero, then you must use a charmm pair style. Note that if you
do not set the special_bonds 1-4 weighting factor to 0.0 (which is the
default) then 1-4 interactions in dihedrals will be computed twice,
once by the pair routine and once by the dihedral routine, which is
probably not what you want.</p>
<p>For AMBER force fields, the special_bonds 1-4 weighting factor should
be set to the AMBER defaults (1/2 and 5/6) and all the dihedral
weighting factors (4th coeff above) should be set to 0.0. In this
case, you can use any pair style you wish, since the dihedral does not
need any 1-4 information.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where Ed is the dihedral term, Embt is a middle-bond-torsion term,
Eebt is an end-bond-torsion term, Eat is an angle-torsion term, Eaat
is an angle-angle-torsion term, and Ebb13 is a bond-bond-13 term.</p>
<p>Theta1 and theta2 are equilibrium angles and r1 r2 r3 are equilibrium
bond lengths.</p>
<p>See <a class="reference internal" href="#dihedral-sun"><span class="std std-ref">(Sun)</span></a> for a description of the COMPASS class2 force field.</p>
<p>Coefficients for the Ed, Embt, Eebt, Eat, Eaat, and Ebb13 formulas
must be defined for each dihedral type via the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command as in the example above,
<p>These are the 6 coefficients for the Ed formula:</p>
<ul class="simple">
<li>K1 (energy)</li>
<li>phi1 (degrees)</li>
<li>K2 (energy)</li>
<li>phi2 (degrees)</li>
<li>K3 (energy)</li>
<li>phi3 (degrees)</li>
</ul>
<p>For the Embt formula, each line in a
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command in the input script lists
5 coefficients, the first of which is “mbt” to indicate they are
MiddleBondTorsion coefficients. In a data file, these coefficients
should be listed under a “MiddleBondTorsion Coeffs” heading and you
must leave out the “mbt”, i.e. only list 4 coefficients after the
dihedral type.</p>
<ul class="simple">
<li>mbt</li>
<li>A1 (energy/distance)</li>
<li>A2 (energy/distance)</li>
<li>A3 (energy/distance)</li>
<li>r2 (distance)</li>
</ul>
<p>For the Eebt formula, each line in a
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command in the input script lists
9 coefficients, the first of which is “ebt” to indicate they are
EndBondTorsion coefficients. In a data file, these coefficients
should be listed under a “EndBondTorsion Coeffs” heading and you must
leave out the “ebt”, i.e. only list 8 coefficients after the dihedral
type.</p>
<ul class="simple">
<li>ebt</li>
<li>B1 (energy/distance)</li>
<li>B2 (energy/distance)</li>
<li>B3 (energy/distance)</li>
<li>C1 (energy/distance)</li>
<li>C2 (energy/distance)</li>
<li>C3 (energy/distance)</li>
<li>r1 (distance)</li>
<li>r3 (distance)</li>
</ul>
<p>For the Eat formula, each line in a
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command in the input script lists
9 coefficients, the first of which is “at” to indicate they are
AngleTorsion coefficients. In a data file, these coefficients should
be listed under a “AngleTorsion Coeffs” heading and you must leave out
the “at”, i.e. only list 8 coefficients after the dihedral type.</p>
<ul class="simple">
<li>at</li>
<li>D1 (energy/radian)</li>
<li>D2 (energy/radian)</li>
<li>D3 (energy/radian)</li>
<li>E1 (energy/radian)</li>
<li>E2 (energy/radian)</li>
<li>E3 (energy/radian)</li>
<li>theta1 (degrees)</li>
<li>theta2 (degrees)</li>
</ul>
<p>Theta1 and theta2 are specified in degrees, but LAMMPS converts them
to radians internally; hence the units of D and E are in
energy/radian.</p>
<p>For the Eaat formula, each line in a
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command in the input script lists
4 coefficients, the first of which is “aat” to indicate they are
AngleAngleTorsion coefficients. In a data file, these coefficients
should be listed under a “AngleAngleTorsion Coeffs” heading and you
must leave out the “aat”, i.e. only list 3 coefficients after the
dihedral type.</p>
<ul class="simple">
<li>aat</li>
<li>M (energy/radian^2)</li>
<li>theta1 (degrees)</li>
<li>theta2 (degrees)</li>
</ul>
<p>Theta1 and theta2 are specified in degrees, but LAMMPS converts them
to radians internally; hence the units of M are in energy/radian^2.</p>
<p>For the Ebb13 formula, each line in a
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command in the input script lists
4 coefficients, the first of which is “bb13” to indicate they are
BondBond13 coefficients. In a data file, these coefficients should be
listed under a “BondBond13 Coeffs” heading and you must leave out the
“bb13”, i.e. only list 3 coefficients after the dihedral type.</p>
<ul class="simple">
<li>bb13</li>
<li>N (energy/distance^2)</li>
<li>r1 (distance)</li>
<li>r3 (distance)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
CLASS2 package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The following coefficients must be defined for each dihedral type via the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>m (integer >=1)</li>
<li>K1 (energy)</li>
<li>n1 (integer >= 0)</li>
<li>d1 (degrees)</li>
<li></li>
<li>Km (energy)</li>
<li>nm (integer >= 0)</li>
<li>dm (degrees)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The following coefficients must be defined for each dihedral type via the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K (energy)</li>
<li>d (+1 or -1)</li>
<li>n (integer >= 0)</li>
</ul>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Here are important points to take note of when defining LAMMPS
dihedral coefficients for the harmonic style, so that they are
compatible with how harmonic dihedrals are defined by other force
fields:</p>
</div>
<ul class="simple">
<li>The LAMMPS convention is that the trans position = 180 degrees, while
in some force fields trans = 0 degrees.</li>
<li>Some force fields reverse the sign convention on <em>d</em>.</li>
<li>Some force fields let <em>n</em> be positive or negative which corresponds to
<em>d</em> = 1 or -1 for the harmonic style.</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>This coarse-grain dihedral potential is described in <a class="reference internal" href="#guo"><span class="std std-ref">(Guo)</span></a>.
For dihedral angles in the helical region, the energy function is
represented by a standard potential consisting of three minima, one
corresponding to the trans (t) state and the other to gauche states
(g+ and g-). The paper describes how the A,B,C parameters are chosen
so as to balance secondary (largely driven by local interactions) and
tertiary structure (driven by long-range interactions).</p>
<p>The following coefficients must be defined for each dihedral type via the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>A (energy)</li>
<li>B (energy)</li>
<li>C (energy)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The following coefficients must be defined for each dihedral type via the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>A1 (energy)</li>
<li>A2 (energy)</li>
<li>A3 (energy)</li>
<li>A4 (energy)</li>
<li>A5 (energy)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The following coefficients must be defined for each dihedral type via the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>n (integer >=1)</li>
<li>A1 (energy)</li>
<li>A2 (energy)</li>
<li>...</li>
<li>An (energy)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Note that the usual 1/2 factor is not included in the K values.</p>
<p>This dihedral potential is used in the OPLS force field and is
described in <a class="reference internal" href="#watkins"><span class="std std-ref">(Watkins)</span></a>.</p>
<p>The following coefficients must be defined for each dihedral type via the
<a class="reference internal" href="dihedral_coeff.html"><span class="doc">dihedral_coeff</span></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a>
or <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> commands:</p>
<ul class="simple">
<li>K1 (energy)</li>
<li>K2 (energy)</li>
<li>K3 (energy)</li>
<li>K4 (energy)</li>
</ul>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-6"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This dihedral style can only be used if LAMMPS was built with the
USER-MISC package. See the <span class="xref std std-ref">Making LAMMPS</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>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 <em>cuda</em> suffix are functionally the same as the
-corresponding style without the suffix. They have been optimized to
-run faster, depending on your available hardware, as discussed in
+<p>Styles with a uffix are functionally the same as the corresponding
+style without the suffix. They have been optimized to run faster,
+depending on your available hardware, as discussed in
<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.</p>
-<p>These accelerated styles are part of the USER-CUDA 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>These accelerated styles are part of the ackage. They are only
+enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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>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>.
<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 <em>cuda</em> suffix are functionally the same as the
-corresponding style without the suffix. They have been optimized to
-run faster, depending on your available hardware, as discussed in
+<p>Styles with a uffix are functionally the same as the corresponding
+style without the suffix. They have been optimized to run faster,
+depending on your available hardware, as discussed in
<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.</p>
-<p>These accelerated styles are part of the USER-CUDA 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>These accelerated styles are part of the ackage. They are only
+enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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.</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
<p>where L0 is its initial length. If the amplitude A is a positive
number the box initially expands, then contracts, etc. If A is
negative then the box initially contracts, then expands, etc. The
amplitude can be in lattice or box distance units. See the discussion
of the units keyword below.</p>
<p>The <em>variable</em> style changes the specified box length dimension by
evaluating a variable, which presumably is a function of time. The
variable with <em>name1</em> must be an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a>
and should calculate a change in box length in units of distance.
Note that this distance is in box units, not lattice units; see the
discussion of the <em>units</em> keyword below. The formula associated with
variable <em>name1</em> can reference the current timestep. Note that it
should return the “change” in box length, not the absolute box length.
This means it should evaluate to 0.0 when invoked on the initial
timestep of the run following the definition of fix deform. It should
evaluate to a value > 0.0 to dilate the box at future times, or a
value < 0.0 to compress the box.</p>
<p>The variable <em>name2</em> must also be an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> and should calculate the rate of box length
change, in units of distance/time, i.e. the time-derivative of the
<em>name1</em> variable. This quantity is used internally by LAMMPS to reset
atom velocities when they cross periodic boundaries. It is computed
internally for the other styles, but you must provide it when using an
arbitrary variable.</p>
<p>Here is an example of using the <em>variable</em> style to perform the same
box deformation as the <em>wiggle</em> style formula listed above, where we
<p>where T0 is its initial value. If the amplitude A is a positive
number the tilt factor initially becomes more positive, then more
negative, etc. If A is negative then the tilt factor initially
becomes more negative, then more positive, etc. The amplitude can be
in lattice or box distance units. See the discussion of the units
keyword below.</p>
<p>The <em>variable</em> style changes the specified tilt factor by evaluating a
variable, which presumably is a function of time. The variable with
<em>name1</em> must be an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> and should
calculate a change in tilt in units of distance. Note that this
distance is in box units, not lattice units; see the discussion of the
<em>units</em> keyword below. The formula associated with variable <em>name1</em>
can reference the current timestep. Note that it should return the
“change” in tilt factor, not the absolute tilt factor. This means it
should evaluate to 0.0 when invoked on the initial timestep of the run
following the definition of fix deform.</p>
<p>The variable <em>name2</em> must also be an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> and should calculate the rate of tilt change,
in units of distance/time, i.e. the time-derivative of the <em>name1</em>
variable. This quantity is used internally by LAMMPS to reset atom
velocities when they cross periodic boundaries. It is computed
internally for the other styles, but you must provide it when using an
arbitrary variable.</p>
<p>Here is an example of using the <em>variable</em> style to perform the same
box deformation as the <em>wiggle</em> style formula listed above, where we
<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 <span class="xref doc">fix lavgevin</span>
(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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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>.
<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 <em>cuda</em> suffix are functionally the same as the
-corresponding style without the suffix. They have been optimized to
-run faster, depending on your available hardware, as discussed in
+<p>Styles with a uffix are functionally the same as the corresponding
+style without the suffix. They have been optimized to run faster,
+depending on your available hardware, as discussed in
<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.</p>
-<p>These accelerated styles are part of the USER-CUDA 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>These accelerated styles are part of the ackage. They are only
+enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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>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 <em>cuda</em> suffix are functionally the same as the
-corresponding style without the suffix. They have been optimized to
-run faster, depending on your available hardware, as discussed in
+<p>Styles with a uffix are functionally the same as the corresponding
+style without the suffix. They have been optimized to run faster,
+depending on your available hardware, as discussed in
<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.</p>
-<p>These accelerated styles are part of the USER-CUDA 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>These accelerated styles are part of the ackage. They are only
+enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>This fix computes a global 3-vector of forces, which can be accessed
by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. This is the
total force on the group of atoms before the forces on individual
atoms are changed by the fix. The vector values calculated by this
fix are “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the GRANULAR package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>There can only be a single freeze fix defined. This is because other
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
template-ID = ID of molecule template specified in a separate <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command
<em>shake</em> value = fix-ID
fix-ID = ID of <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command
<em>region</em> value = region-ID
region-ID = ID of region where MC moves are allowed
<em>maxangle</em> value = maximum molecular rotation angle (degrees)
<em>pressure</em> value = pressure of the gas reservoir (pressure units)
<em>fugacity_coeff</em> value = fugacity coefficient of the gas reservoir (unitless)
<em>full_energy</em> = compute the entire system energy when performing MC moves
<em>charge</em> value = charge of inserted atoms (charge units)
<em>group</em> value = group-ID
group-ID = group-ID for inserted atoms (string)
<em>grouptype</em> values = type group-ID
type = atom type (int)
group-ID = group-ID for inserted atoms (string)
<em>intra_energy</em> value = intramolecular energy (energy units)
<em>tfac_insert</em> value = scale up/down temperature of inserted atoms (unitless)
<p>This fix performs grand canonical Monte Carlo (GCMC) exchanges of
atoms or molecules of the given type with an imaginary ideal gas reservoir at
the specified T and chemical potential (mu) as discussed in
<a class="reference internal" href="fix_ti_spring.html#frenkel"><span class="std std-ref">(Frenkel)</span></a>. If used with the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command,
simulations in the grand canonical ensemble (muVT, constant chemical
potential, constant volume, and constant temperature) can be
performed. Specific uses include computing isotherms in microporous
materials, or computing vapor-liquid coexistence curves.</p>
<p>Every N timesteps the fix attempts a number of GCMC exchanges (insertions
or deletions) of gas atoms or molecules of
the given type between the simulation cell and the imaginary
reservoir. It also attempts a number of Monte Carlo
moves (translations and molecule rotations) of gas of the given type
within the simulation cell or region. The average number of
attempted GCMC exchanges is X. The average number of attempted MC moves is M.
M should typically be chosen to be
approximately equal to the expected number of gas atoms or molecules
of the given type within the simulation cell or region,
which will result in roughly one
MC translation per atom or molecule per MC cycle.</p>
<p>For MC moves of molecular gasses, rotations and translations are each
attempted with 50% probability. For MC moves of atomic gasses,
translations are attempted 100% of the time. For MC exchanges of
either molecular or atomic gasses, deletions and insertions are each
attempted with 50% probability.</p>
<p>All inserted particles are always assigned to two groups: the default group
“all” and the group specified in the fix gcmc command (which can also
be “all”). In addition, particles are also added to any groups specified
by the <em>group</em> and <em>grouptype</em> keywords.
If inserted particles are individual atoms, they are
assigned the atom type given by the type argument. If they are molecules,
the type argument has no effect and must be set to zero. Instead,
the type of each atom in the inserted molecule is specified
in the file read by the <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command.</p>
<p>This fix cannot be used to perform MC insertions of gas atoms or
molecules other than the exchanged type, but MC deletions,
translations, and rotations can be performed on any atom/molecule in
the fix group. All atoms in the simulation cell can be moved using
regular time integration translations, e.g. via
<a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>, resulting in a hybrid GCMC+MD simulation. A
smaller-than-usual timestep size may be needed when running such a
hybrid simulation, especially if the inserted molecules are not well
equilibrated.</p>
<p>This command may optionally use the <em>region</em> keyword to define an
exchange and move volume. The specified region must have been
previously defined with a <a class="reference internal" href="region.html"><span class="doc">region</span></a> command. It must be
defined with side = <em>in</em>. Insertion attempts occur only within the
specified region. For non-rectangular regions, random trial
points are generated within the rectangular bounding box until a point is found
that lies inside the region. If no valid point is generated after 1000 trials,
no insertion is performed, but it is counted as an attempted insertion.
Move and deletion attempt candidates are selected
from gas atoms or molecules within the region. If there are no candidates,
no move or deletion is performed, but it is counted as an attempt move
or deletion. If an attempted move places the atom or molecule center-of-mass outside
the specified region, a new attempted move is generated. This process is repeated
until the atom or molecule center-of-mass is inside the specified region.</p>
<p>If used with <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>, the temperature of the imaginary
reservoir, T, should be set to be equivalent to the target temperature
used in fix nvt. Otherwise, the imaginary reservoir
will not be in thermal equilibrium with the simulation cell. Also,
it is important that the temperature used by fix nvt be dynamic,
<p>Note that neighbor lists are re-built every timestep that this fix is
invoked, so you should not set N to be too small. However, periodic
rebuilds are necessary in order to avoid dangerous rebuilds and missed
interactions. Specifically, avoid performing so many MC translations
per timestep that atoms can move beyond the neighbor list skin
distance. See the <a class="reference internal" href="neighbor.html"><span class="doc">neighbor</span></a> command for details.</p>
<p>When an atom or molecule is to be inserted, its
coordinates are chosen at a random position within the current
simulation cell or region, and new atom velocities are randomly chosen from
the specified temperature distribution given by T. The effective
temperature for new atom velocities can be increased or decreased
using the optional keyword <em>tfac_insert</em> (see below). Relative
coordinates for atoms in a molecule are taken from the template
molecule provided by the user. The center of mass of the molecule
is placed at the insertion point. The orientation of the molecule
is chosen at random by rotating about this point.</p>
<p>Individual atoms are inserted, unless the <em>mol</em> keyword is used. It
specifies a <em>template-ID</em> previously defined using the
<a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command, which reads a file that defines the
molecule. The coordinates, atom types, charges, etc, as well as any
bond/angle/etc and special neighbor information for the molecule can
be specified in the molecule file. See the <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a>
command for details. The only settings required to be in this file
are the coordinates and types of atoms in the molecule.</p>
<p>When not using the <em>mol</em> keyword, you should ensure you do not delete
atoms that are bonded to other atoms, or LAMMPS will
soon generate an error when it tries to find bonded neighbors. LAMMPS will
warn you if any of the atoms eligible for deletion have a non-zero
molecule ID, but does not check for this at the time of deletion.</p>
<p>If you wish to insert molecules via the <em>mol</em> keyword, that will have
their bonds or angles constrained via SHAKE, use the <em>shake</em> keyword,
specifying as its value the ID of a separate <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command which also appears in your input script.</p>
<p>Optionally, users may specify the maximum rotation angle for
molecular rotations using the <em>maxangle</em> keyword and specifying
the angle in degrees. Rotations are performed by generating a random
point on the unit sphere and a random rotation angle on the
range [0,maxangle). The molecule is then rotated by that angle about an
axis passing through the molecule center of mass. The axis is parallel
to the unit vector defined by the point on the unit sphere.
The same procedure is used for randomly rotating molecules when they
are inserted, except that the maximum angle is 360 degrees.</p>
<p>Note that fix GCMC does not use configurational bias
MC or any other kind of sampling of intramolecular degrees of freedom.
Inserted molecules can have different orientations, but they will all
have the same intramolecular configuration,
which was specified in the molecule command input.</p>
<p>For atomic gasses, inserted atoms have the specified atom type, but
deleted atoms are any atoms that have been inserted or that belong
to the user-specified fix group. For molecular gasses, exchanged
molecules use the same atom types as in the template molecule
supplied by the user. In both cases, exchanged
atoms/molecules are assigned to two groups: the default group “all”
and the group specified in the fix gcmc command (which can also be
“all”).</p>
<p>The gas reservoir pressure can be specified using the <em>pressure</em>
keyword, in which case the user-specified chemical potential is
ignored. For non-ideal gas reservoirs, the user may also specify the
fugacity coefficient using the <em>fugacity_coeff</em> keyword.</p>
<p>The <em>full_energy</em> option means that fix GCMC will compute the total
potential energy of the entire simulated system. The total system
energy before and after the proposed GCMC move is then used in the
Metropolis criterion to determine whether or not to accept the
proposed GCMC move. By default, this option is off, in which case
only partial energies are computed to determine the difference in
energy that would be caused by the proposed GCMC move.</p>
<p>The <em>full_energy</em> option is needed for systems with complicated
potential energy calculations, including the following:</p>
<ul class="simple">
<li>long-range electrostatics (kspace)</li>
<li>many-body pair styles</li>
<li>hybrid pair styles</li>
<li>eam pair styles</li>
<li>triclinic systems</li>
<li>need to include potential energy contributions from other fixes</li>
</ul>
<p>In these cases, LAMMPS will automatically apply the <em>full_energy</em>
keyword and issue a warning message.</p>
<p>When the <em>mol</em> keyword is used, the <em>full_energy</em> option also includes
the intramolecular energy of inserted and deleted molecules. If this
is not desired, the <em>intra_energy</em> keyword can be used to define an
amount of energy that is subtracted from the final energy when a molecule
is inserted, and added to the initial energy when a molecule is
deleted. For molecules that have a non-zero intramolecular energy, this
will ensure roughly the same behavior whether or not the <em>full_energy</em>
option is used.</p>
<p>Inserted atoms and molecules are assigned random velocities based on the
specified temperature T. Because the relative velocity of
all atoms in the molecule is zero, this may result in inserted molecules
that are systematically too cold. In addition, the intramolecular potential
energy of the inserted molecule may cause the kinetic energy
of the molecule to quickly increase or decrease after insertion.
The <em>tfac_insert</em> keyword allows the user to counteract these effects
by changing the temperature used to assign velocities to
inserted atoms and molecules by a constant factor. For a
particular application, some experimentation may be required
to find a value of <em>tfac_insert</em> that results in inserted molecules that
equilibrate quickly to the correct temperature.</p>
<p>Some fixes have an associated potential energy. Examples of such fixes
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>This fix writes the state of the fix to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. This includes information about the random
number generator seed, the next timestep for MC exchanges, etc. See
the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for info on how to
re-specify a fix in an input script that reads a restart file, so that
the operation of the fix continues in an uninterrupted fashion.</p>
<p>None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options are relevant to this
fix.</p>
<p>This fix computes a global vector of length 8, which can be accessed
by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The vector
values are the following global cumulative quantities:</p>
<ul class="simple">
<li>1 = translation attempts</li>
<li>2 = translation successes</li>
<li>3 = insertion attempts</li>
<li>4 = insertion successes</li>
<li>5 = deletion attempts</li>
<li>6 = deletion successes</li>
<li>7 = rotation attempts</li>
<li>8 = rotation successes</li>
</ul>
<p>The vector values calculated by this fix are “extensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the MC package. It is only enabled if LAMMPS was
built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Do not set “neigh_modify once yes” or else this fix will never be
called. Reneighboring is required.</p>
<p>Can be run in parallel, but aspects of the GCMC part will not scale
well in parallel. Only usable for 3D simulations.</p>
<p>Note that very lengthy simulations involving insertions/deletions of
billions of gas molecules may run out of atom or molecule IDs and
trigger an error, so it is better to run multiple shorter-duration
simulations. Likewise, very large molecules have not been tested
and may turn out to be problematic.</p>
<p>Use of multiple fix gcmc commands in the same input script can be
problematic if using a template molecule. The issue is that the
user-referenced template molecule in the second fix gcmc command
may no longer exist since it might have been deleted by the first
fix gcmc command. An existing template molecule will need to be
referenced by the user for each subsequent fix gcmc command.</p>
+<p>Because molecule insertion does not work in combination with
+fix rigid, simulataneous use of fix rigid or fix rigid/small
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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>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>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>
+<p>Apply a Langevin thermostat as described in <a class="reference internal" href="#schneider"><span class="std std-ref">(Schneider)</span></a>
to a group of 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 class="reference internal" href="#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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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>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> 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>
<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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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>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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>This fix writes the state of the Nose/Hoover barostat to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> and <em>press</em> options are
supported by this fix. You can use them to assign a
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> you have defined to this fix which will be used
in its thermostatting or barostatting procedure. If you do this, note
that the kinetic energy derived from the compute temperature should be
consistent with the virial term computed using all atoms for the
pressure. LAMMPS will warn you if you choose to compute temperature
on a subset of atoms.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change induced by Nose/Hoover barostatting to
the system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes the same global scalar and global vector of
quantities as does the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> command.</p>
<p>This fix can ramp its target pressure over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the BODY package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires that atoms store torque and angular momementum and a
quaternion as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style body</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>nph/sphere = style name of this fix command</li>
<li>additional barostat related keyword/value pairs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nph</span></a> command can be appended</li>
<p>See the <a class="reference internal" href="compute_temp_sphere.html"><span class="doc">compute temp/sphere</span></a> and <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + “temp” or fix_ID
+ underscore + “press”, and the group for the new computes is “all”
since pressure is computed for the entire system.</p>
<p>Note that these are NOT the computes used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>
and <em>thermo_press</em>. This means you can change the attributes of this
fix’s temperature or pressure via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
or pressure during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> or
<em>thermo_press</em> will have no effect on this fix.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
can be used to define the values of E0, V0, and P0. Note the
the values for <em>e0</em> and <em>v0</em> are extensive, and so must correspond
to the total energy and volume of the entire system, not energy and
volume per atom. If any of these quantities are not specified, then the
instantaneous value in the system at the start of the simulation is used.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> and <em>press</em> options are
supported by these fixes. You can use them to assign a
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> you have defined to this fix which will be used
in its thermostatting or barostatting procedure, as described above.
If you do this, note that the kinetic energy derived from the compute
temperature should be consistent with the virial term computed using
all atoms for the pressure. LAMMPS will warn you if you choose to
compute temperature on a subset of atoms.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by these
fixes to add the energy change induced by Nose/Hoover thermostatting
and barostatting to the system’s potential energy as part of
<a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>. Either way, this energy is <em>not</em>
included in the definition of internal energy E when calculating the value
of Delta in the above equation.</p>
<p>These fixes compute a global scalar and a global vector of quantities,
which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar value calculated by
these fixes is “extensive”; the vector values are “intensive”.</p>
<p>The scalar is the cumulative energy change due to the fix.</p>
<p>The vector stores three quantities unique to this fix (Delta, Us, and up),
followed by all the internal Nose/Hoover thermostat and barostat
variables defined for <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a>. Delta is the deviation
of the temperature from the target temperature, given by the above equation.
Us and up are the shock and particle velocity corresponding to a steady
shock calculated from the RH conditions. They have units of distance/time.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix style is part of the SHOCK package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>All the usual restrictions for <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> apply,
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>npt/asphere = style name of this fix command</li>
<li>additional thermostat and barostat related keyword/value pairs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command can be appended</li>
<p>Perform constant NPT integration to update position, velocity,
orientation, and angular velocity each timestep for aspherical or
ellipsoidal particles in the group using a Nose/Hoover temperature
thermostat and Nose/Hoover pressure barostat. P is pressure; T is
temperature. This creates a system trajectory consistent with the
isothermal-isobaric ensemble.</p>
<p>This fix differs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command, which
assumes point particles and only updates their position and velocity.</p>
<p>The thermostat is applied to both the translational and rotational
degrees of freedom for the aspherical particles, assuming a compute is
used which calculates a temperature that includes the rotational
degrees of freedom (see below). The translational degrees of freedom
can also have a bias velocity removed from them before thermostatting
takes place; see the description below.</p>
<p>Additional parameters affecting the thermostat and barostat are
specified by keywords and values documented with the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command. See, for example, discussion of the <em>temp</em>,
<em>iso</em>, <em>aniso</em>, and <em>dilate</em> keywords.</p>
<p>The particles in the fix group are the only ones whose velocities and
positions are updated by the velocity/position update portion of the
NPT integration.</p>
<p>Regardless of what particles are in the fix group, a global pressure is
computed for all particles. Similarly, when the size of the simulation
box is changed, all particles are re-scaled to new positions, unless the
keyword <em>dilate</em> is specified with a value of <em>partial</em>, in which case
only the particles in the fix group are re-scaled. The latter can be
useful for leaving the coordinates of particles in a solid substrate
unchanged and controlling the pressure of a surrounding fluid.</p>
<hr class="docutils" />
<p>This fix computes a temperature and pressure each timestep. To do
this, the fix creates its own computes of style “temp/asphere” and
“pressure”, as if these commands had been issued:</p>
<p>See the <a class="reference internal" href="compute_temp_asphere.html"><span class="doc">compute temp/asphere</span></a> and <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + “temp” or fix_ID
+ underscore + “press”, and the group for the new computes is “all”
since pressure is computed for the entire system.</p>
<p>Note that these are NOT the computes used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>
and <em>thermo_press</em>. This means you can change the attributes of this
fix’s temperature or pressure via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
or pressure during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> or
<em>thermo_press</em> will have no effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>This fix computes the same global scalar and global vector of
quantities as does the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command.</p>
<p>This fix can ramp its target temperature and pressure over multiple
runs, using the <em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a>
command. See the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do
this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the ASPHERE package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires that atoms store torque and angular momementum and a
quaternion as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a>
command.</p>
<p>All particles in the group must be finite-size. They cannot be point
particles, but they can be aspherical or spherical as defined by their
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>npt/body = style name of this fix command</li>
<li>additional thermostat and barostat related keyword/value pairs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command can be appended</li>
<p>Perform constant NPT integration to update position, velocity,
orientation, and angular velocity each timestep for body
particles in the group using a Nose/Hoover temperature
thermostat and Nose/Hoover pressure barostat. P is pressure; T is
temperature. This creates a system trajectory consistent with the
isothermal-isobaric ensemble.</p>
<p>This fix differs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command, which
assumes point particles and only updates their position and velocity.</p>
<p>The thermostat is applied to both the translational and rotational
degrees of freedom for the body particles, assuming a compute is
used which calculates a temperature that includes the rotational
degrees of freedom (see below). The translational degrees of freedom
can also have a bias velocity removed from them before thermostatting
takes place; see the description below.</p>
<p>Additional parameters affecting the thermostat and barostat are
specified by keywords and values documented with the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command. See, for example, discussion of the <em>temp</em>,
<em>iso</em>, <em>aniso</em>, and <em>dilate</em> keywords.</p>
<p>The particles in the fix group are the only ones whose velocities and
positions are updated by the velocity/position update portion of the
NPT integration.</p>
<p>Regardless of what particles are in the fix group, a global pressure is
computed for all particles. Similarly, when the size of the simulation
box is changed, all particles are re-scaled to new positions, unless the
keyword <em>dilate</em> is specified with a value of <em>partial</em>, in which case
only the particles in the fix group are re-scaled. The latter can be
useful for leaving the coordinates of particles in a solid substrate
unchanged and controlling the pressure of a surrounding fluid.</p>
<hr class="docutils" />
<p>This fix computes a temperature and pressure each timestep. To do
this, the fix creates its own computes of style “temp/body” and
“pressure”, as if these commands had been issued:</p>
<p>See the <a class="reference internal" href="compute_temp_body.html"><span class="doc">compute temp/body</span></a> and <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + “temp” or fix_ID
+ underscore + “press”, and the group for the new computes is “all”
since pressure is computed for the entire system.</p>
<p>Note that these are NOT the computes used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>
and <em>thermo_press</em>. This means you can change the attributes of this
fix’s temperature or pressure via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
or pressure during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> or
<em>thermo_press</em> will have no effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>This fix computes the same global scalar and global vector of
quantities as does the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command.</p>
<p>This fix can ramp its target temperature and pressure over multiple
runs, using the <em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a>
command. See the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do
this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the BODY package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires that atoms store torque and angular momementum and a
quaternion as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style body</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>npt/sphere = style name of this fix command</li>
<li>additional thermostat and barostat related keyword/value pairs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command can be appended</li>
<p>Perform constant NPT integration to update position, velocity, and
angular velocity each timestep for finite-sizex spherical particles in
the group using a Nose/Hoover temperature thermostat and Nose/Hoover
pressure barostat. P is pressure; T is temperature. This creates a
system trajectory consistent with the isothermal-isobaric ensemble.</p>
<p>This fix differs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command, which
assumes point particles and only updates their position and velocity.</p>
<p>The thermostat is applied to both the translational and rotational
degrees of freedom for the spherical particles, assuming a compute is
used which calculates a temperature that includes the rotational
degrees of freedom (see below). The translational degrees of freedom
can also have a bias velocity removed from them before thermostatting
takes place; see the description below.</p>
<p>Additional parameters affecting the thermostat and barostat are
specified by keywords and values documented with the <a class="reference internal" href="fix_nh.html"><span class="doc">fix npt</span></a> command. See, for example, discussion of the <em>temp</em>,
<em>iso</em>, <em>aniso</em>, and <em>dilate</em> keywords.</p>
<p>The particles in the fix group are the only ones whose velocities and
positions are updated by the velocity/position update portion of the
NPT integration.</p>
<p>Regardless of what particles are in the fix group, a global pressure is
computed for all particles. Similarly, when the size of the simulation
box is changed, all particles are re-scaled to new positions, unless the
keyword <em>dilate</em> is specified with a value of <em>partial</em>, in which case
only the particles in the fix group are re-scaled. The latter can be
useful for leaving the coordinates of particles in a solid substrate
unchanged and controlling the pressure of a surrounding fluid.</p>
<hr class="docutils" />
<p>This fix computes a temperature and pressure each timestep. To do
this, the fix creates its own computes of style “temp/sphere” and
“pressure”, as if these commands had been issued:</p>
<p>See the <a class="reference internal" href="compute_temp_sphere.html"><span class="doc">compute temp/sphere</span></a> and <a class="reference internal" href="compute_pressure.html"><span class="doc">compute pressure</span></a> commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + “temp” or fix_ID
+ underscore + “press”, and the group for the new computes is “all”
since pressure is computed for the entire system.</p>
<p>Note that these are NOT the computes used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>
and <em>thermo_press</em>. This means you can change the attributes of this
fix’s temperature or pressure via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
or pressure during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> or
<em>thermo_press</em> will have no effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Perform constant NVE integration to update position and velocity for
atoms in the group each timestep. V is volume; E is energy. This
creates a system trajectory consistent with the microcanonical
ensemble.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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>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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the ASPHERE package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires that atoms store torque and angular momementum and a
quaternion as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a>
command.</p>
<p>All particles in the group must be finite-size. They cannot be point
particles, but they can be aspherical or spherical as defined by their
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<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>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>nvt/asphere = style name of this fix command</li>
<li>additional thermostat related keyword/value pairs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command can be appended</li>
<p>See the <a class="reference internal" href="compute_temp_asphere.html"><span class="doc">compute temp/asphere</span></a> command for
details. Note that the ID of the new compute is the fix-ID +
underscore + “temp”, and the group for the new compute is the same as
the fix group.</p>
<p>Note that this is NOT the compute used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>.
This means you can change the attributes of this fix’s temperature
(e.g. its degrees-of-freedom) via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> will have no
effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>This fix writes the state of the Nose/Hoover thermostat to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to assign a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> you have
defined to this fix which will be used in its thermostatting
procedure.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change induced by Nose/Hoover thermostatting to
the system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes the same global scalar and global vector of
quantities as does the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command.</p>
<p>This fix can ramp its target temperature over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the ASPHERE package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires that atoms store torque and angular momementum and a
quaternion as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a>
command.</p>
<p>All particles in the group must be finite-size. They cannot be point
particles, but they can be aspherical or spherical as defined by their
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>nvt/body = style name of this fix command</li>
<li>additional thermostat related keyword/value pairs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command can be appended</li>
<p>See the <a class="reference internal" href="compute_temp_body.html"><span class="doc">compute temp/body</span></a> command for
details. Note that the ID of the new compute is the fix-ID +
underscore + “temp”, and the group for the new compute is the same as
the fix group.</p>
<p>Note that this is NOT the compute used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>.
This means you can change the attributes of this fix’s temperature
(e.g. its degrees-of-freedom) via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> will have no
effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>This fix writes the state of the Nose/Hoover thermostat to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. See the <a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a>
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to assign a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> you have
defined to this fix which will be used in its thermostatting
procedure.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change induced by Nose/Hoover thermostatting to
the system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes the same global scalar and global vector of
quantities as does the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command.</p>
<p>This fix can ramp its target temperature over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the BODY package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This fix requires that atoms store torque and angular momementum and a
quaternion as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style body</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>nvt/sllod = style name of this fix command</li>
<li>additional thermostat related keyword/value pairs from the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command can be appended</li>
<p>Perform constant NVT integration to update positions and velocities
each timestep for atoms in the group using a Nose/Hoover temperature
thermostat. V is volume; T is temperature. This creates a system
trajectory consistent with the canonical ensemble.</p>
<p>This thermostat is used for a simulation box that is changing size
and/or shape, for example in a non-equilibrium MD (NEMD) simulation.
The size/shape change is induced by use of the <a class="reference internal" href="fix_deform.html"><span class="doc">fix deform</span></a> command, so each point in the simulation box
can be thought of as having a “streaming” velocity. This
position-dependent streaming velocity is subtracted from each atom’s
actual velocity to yield a thermal velocity which is used for
temperature computation and thermostatting. For example, if the box
is being sheared in x, relative to y, then points at the bottom of the
box (low y) have a small x velocity, while points at the top of the
box (hi y) have a large x velocity. These velocities do not
contribute to the thermal “temperature” of the atom.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last"><a class="reference internal" href="fix_deform.html"><span class="doc">Fix deform</span></a> has an option for remapping either
atom coordinates or velocities to the changing simulation box. To use
fix nvt/sllod, fix deform should NOT remap atom positions, because fix
nvt/sllod adjusts the atom positions and velocities to create a
velocity profile that matches the changing box size/shape. Fix deform
SHOULD remap atom velocities when atoms cross periodic boundaries
since that is consistent with maintaining the velocity profile created
by fix nvt/sllod. LAMMPS will give an error if this setting is not
consistent.</p>
</div>
<p>The SLLOD equations of motion, originally proposed by Hoover and Ladd
(see <a class="reference internal" href="#evans"><span class="std std-ref">(Evans and Morriss)</span></a>), were proven to be equivalent to
Newton’s equations of motion for shear flow by <a class="reference internal" href="#evans"><span class="std std-ref">(Evans and Morriss)</span></a>. They were later shown to generate the desired
velocity gradient and the correct production of work by stresses for
all forms of homogeneous flow by <a class="reference internal" href="#daivis"><span class="std std-ref">(Daivis and Todd)</span></a>. As
implemented in LAMMPS, they are coupled to a Nose/Hoover chain
thermostat in a velocity Verlet formulation, closely following the
implementation used for the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command.</p>
<p>Additional parameters affecting the thermostat are specified by
keywords and values documented with the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>
command. See, for example, discussion of the <em>temp</em> and <em>drag</em>
keywords.</p>
<p>This fix computes a temperature each timestep. To do this, the fix
creates its own compute of style “temp/deform”, as if this command had
<p>See the <a class="reference internal" href="compute_temp_deform.html"><span class="doc">compute temp/deform</span></a> command for
details. Note that the ID of the new compute is the fix-ID +
underscore + “temp”, and the group for the new compute is the same as
the fix group.</p>
<p>Note that this is NOT the compute used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>.
This means you can change the attributes of this fix’s temperature
(e.g. its degrees-of-freedom) via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> will have no
effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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>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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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>.
<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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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 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>.
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> command</li>
<li>style = <em>rigid</em> or <em>rigid/nve</em> or <em>rigid/nvt</em> or <em>rigid/npt</em> or <em>rigid/nph</em> or <em>rigid/small</em> or <em>rigid/nve/small</em> or <em>rigid/nvt/small</em> or <em>rigid/npt/small</em> or <em>rigid/nph/small</em></li>
<li>bodystyle = <em>single</em> or <em>molecule</em> or <em>group</em></li>
</ul>
<pre class="literal-block">
<em>single</em> args = none
<em>molecule</em> args = none
<em>group</em> args = N groupID1 groupID2 ...
N = # of groups
groupID1, groupID2, ... = list of N group IDs
</pre>
<ul class="simple">
<li>zero or more keyword/value pairs may be appended</li>
<li>keyword = <em>langevin</em> or <em>temp</em> or <em>iso</em> or <em>aniso</em> or <em>x</em> or <em>y</em> or <em>z</em> or <em>couple</em> or <em>tparam</em> or <em>pchain</em> or <em>dilate</em> or <em>force</em> or <em>torque</em> or <em>infile</em></li>
Tstart,Tstop = desired temperature at start/stop of run (temperature units)
Tdamp = temperature damping parameter (time units)
seed = random number seed to use for white noise (positive integer)
<em>temp</em> values = Tstart Tstop Tdamp
Tstart,Tstop = desired temperature at start/stop of run (temperature units)
Tdamp = temperature damping parameter (time units)
<em>iso</em> or <em>aniso</em> values = Pstart Pstop Pdamp
Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
Pdamp = pressure damping parameter (time units)
<em>x</em> or <em>y</em> or <em>z</em> values = Pstart Pstop Pdamp
Pstart,Pstop = external stress tensor component at start/end of run (pressure units)
Pdamp = stress damping parameter (time units)
<em>couple</em> = <em>none</em> or <em>xyz</em> or <em>xy</em> or <em>yz</em> or <em>xz</em>
<em>tparam</em> values = Tchain Titer Torder
Tchain = length of Nose/Hoover thermostat chain
Titer = number of thermostat iterations performed
Torder = 3 or 5 = Yoshida-Suzuki integration parameters
<em>pchain</em> values = Pchain
Pchain = length of the Nose/Hoover thermostat chain coupled with the barostat
<em>dilate</em> value = dilate-group-ID
dilate-group-ID = only dilate atoms in this group due to barostat volume changes
<em>force</em> values = M xflag yflag zflag
M = which rigid body from 1-Nbody (see asterisk form below)
xflag,yflag,zflag = off/on if component of center-of-mass force is active
<em>torque</em> values = M xflag yflag zflag
M = which rigid body from 1-Nbody (see asterisk form below)
xflag,yflag,zflag = off/on if component of center-of-mass torque is active
<em>infile</em> filename
filename = file with per-body values of mass, center-of-mass, moments of inertia
<em>mol</em> value = template-ID
template-ID = ID of molecule template specified in a separate <a class="reference internal" href="molecule.html"><span class="doc">molecule</span></a> command
<p>Treat one or more sets of atoms as independent rigid bodies. This
means that each timestep the total force and torque on each rigid body
is computed as the sum of the forces and torques on its constituent
particles. The coordinates, velocities, and orientations of the atoms
in each body are then updated so that the body moves and rotates as a
single entity.</p>
<p>Examples of large rigid bodies are a colloidal particle, or portions
of a biomolecule such as a protein.</p>
<p>Example of small rigid bodies are patchy nanoparticles, such as those
modeled in <a class="reference internal" href="pair_gran.html#zhang"><span class="std std-ref">this paper</span></a> by Sharon Glotzer’s group, clumps of
granular particles, lipid molecules consiting of one or more point
dipoles connected to other spheroids or ellipsoids, irregular
particles built from line segments (2d) or triangles (3d), and
coarse-grain models of nano or colloidal particles consisting of a
small number of constituent particles. Note that the <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> command can also be used to rigidify small
molecules of 2, 3, or 4 atoms, e.g. water molecules. That fix treats
the constituent atoms as point masses.</p>
<p>These fixes also update the positions and velocities of the atoms in
each rigid body via time integration, in the NVE, NVT, NPT, or NPH
ensemble, as described below.</p>
<p>There are two main variants of this fix, fix rigid and fix
rigid/small. The NVE/NVT/NPT/NHT versions belong to one of the two
variants, as their style names indicate.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Not all of the <em>bodystyle</em> options and keyword/value options are
available for both the <em>rigid</em> and <em>rigid/small</em> variants. See
details below.</p>
</div>
<p>The <em>rigid</em> variant is 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> variant is 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 <em>rigid/small</em> 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 this fix is
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
effect 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 or 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 fix rigid/small, which requires bodystyle <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, 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 fix rigid and its
sub-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 fix rigid and fix rigid/small, and their sub-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 fix
rigid and its sub-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
fix rigid and its sub-styles.</p>
<p>By default, each rigid body is acted on by other atoms which induce an
external force and torque on its center of mass, causing it to
translate and rotate. Components of the external center-of-mass force
and torque can be turned off by the <em>force</em> and <em>torque</em> keywords.
This may be useful if you wish a body to rotate but not translate, or
vice versa, or if you wish it to rotate or translate continuously
unaffected by interactions with other particles. Note that if you
expect a rigid body not to move or rotate by using these keywords, you
must insure its initial center-of-mass translational or angular
velocity is 0.0. Otherwise the initial translational or angular
momentum the body has will persist.</p>
<p>An xflag, yflag, or zflag set to <em>off</em> means turn off the component of
force of torque in that dimension. A setting of <em>on</em> means turn on
the component, which is the default. Which rigid body(s) the settings
apply to is determined by the first argument of the <em>force</em> and
<em>torque</em> keywords. It can be an integer M from 1 to Nbody, where
Nbody is the number of rigid bodies defined. A wild-card asterisk can
be used in place of, or in conjunction with, the M argument to set the
flags for multiple rigid bodies. This takes the form “*” or “<em>n” or
“n</em>” or “m*n”. If N = the number of rigid bodies, then an asterisk
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> and <em>rigid/small</em> and <em>rigid/nve</em> styles perform constant
NVE time integration. 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> style 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. 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> and <em>rigid/nph</em> (and their /small counterparts) styles
perform constant NPT or NPH integration using a Nose/Hoover barostat
with chains. For the NPT case, the same Nose/Hoover thermostat is also
used as with <em>rigid/nvt</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> and <em>rigid/nph</em> (and their /small
counterparts) 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 either the <em>rigid</em> or <em>rigid/small</em>
or <em>rigid/nve</em> styles. It cannot be used with the <em>rigid/nvt</em> style.
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 <em>rigid/nvt</em> style. They cannot
be used with the <em>rigid</em> or <em>rigid/small</em> or <em>rigid/nve</em> 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
<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 fix rigid or fix rigid/nve 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 fix rigid/nvt 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 fix rigid
or fix rigid/nve 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 fix rigid/npt (or the nph
variants). 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 fix rigid/npt 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 fix rigid/nvt 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 fix rigid/nvt 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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>No information about the <em>rigid</em> and <em>rigid/small</em> and <em>rigid/nve</em>
fixes are 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 style <em>rigid/nvt</em> 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>. 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
rigid/nvt fix to add the energy change induced by the 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>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 rigid/npt and rigid/nph fixes to change the computes used
to calculate the instantaneous pressure tensor. Note that the rigid/nvt fix
does not use any external compute to compute instantaneous temperature.</p>
<p>The <em>rigid</em> and <em>rigid/small</em> and <em>rigid/nve</em> 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 <em>rigid/nvt</em>, <em>rigid/npt</em>, and <em>rigid/nph</em> 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> fixes except <em>rigid/small</em> compute a global array
of values which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The number of rows in the
array is equal to the number of rigid bodies. The number of columns
is 15. Thus for each rigid body, 15 values are stored: the xyz coords
of the center of mass (COM), the xyz components of the COM velocity,
the xyz components of the force acting on the COM, the xyz components
of the torque acting on the COM, and the xyz image flags of the COM.</p>
<p>The center of mass (COM) for each body is similar to unwrapped
coordinates written to a dump file. It will always be inside (or
slightly outside) the simulation box. The image flags have the same
meaning as image flags for atom positions (see the “dump” command).
This means you can calculate the unwrapped COM by applying the image
flags to the COM, the same as when unwrapped coordinates are written
to a dump file.</p>
<p>The force and torque values in the array are not affected by the
<em>force</em> and <em>torque</em> keywords in the fix rigid command; they reflect
values before any changes are made by those keywords.</p>
<p>The ordering of the rigid bodies (by row in the array) is as follows.
For the <em>single</em> keyword there is just one rigid body. For the
<em>molecule</em> keyword, the bodies are ordered by ascending molecule ID.
For the <em>group</em> keyword, the list of group IDs determines the ordering
of bodies.</p>
<p>The array values calculated by these fixes are “intensive”, meaning
they are independent of the number of atoms in the simulation.</p>
<p>No parameter of these fixes can be used with the <em>start/stop</em> keywords
of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. These fixes are not invoked during
<p>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 <em>cuda</em> or <em>kk</em> suffix are functionally the same as the
+<p>Styles with a r <em>kk</em> suffix are functionally the same as the
corresponding style without the suffix. They have been optimized to
run faster, depending on your available hardware, as discussed in
<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.</p>
<p>The region keyword is also supported by Kokkos, but a Kokkos-enabled
-region must be used. See the region <a class="reference internal" href="region.html"><span class="doc">region</span></a> command for more
-information.</p>
-<p>These accelerated styles are part of the USER-CUDA or Kokkos package. They are
+region must be used. See the region <a class="reference internal" href="region.html"><span class="doc">region</span></a> command for
+more information.</p>
+<p>These accelerated styles are part of the r Kokkos package. They are
only enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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.</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 <em>cuda</em> suffix are functionally the same as the
-corresponding style without the suffix. They have been optimized to
-run faster, depending on your available hardware, as discussed in
+<p>Styles with a uffix are functionally the same as the corresponding
+style without the suffix. They have been optimized to run faster,
+depending on your available hardware, as discussed in
<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.</p>
-<p>These accelerated styles are part of the USER-CUDA 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>These accelerated styles are part of the ackage. They are only
+enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<hr class="docutils" />
<p><strong>RATTLE:</strong></p>
<p>The velocity constraints lead to a linear system of equations which
can be solved analytically. The implementation of the algorithm in
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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>.
<p><em>Tstart</em> can be specified as an equal-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>.
In this case, the <em>Tstop</em> setting is ignored. If the value is a
variable, it should be specified as v_name, where name is the variable
name. In this case, the variable will be evaluated each timestep, and
its value used to determine the target temperature.</p>
<p>Equal-style variables can specify formulas with various mathematical
functions, and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent temperature.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Unlike the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command which performs
Nose/Hoover thermostatting AND time integration, this fix does NOT
perform time integration. It only modifies velocities to effect
thermostatting. Thus you must use a separate time integration fix,
like <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> to actually update the positions of atoms
using the modified velocities. Likewise, this fix should not normally
be used on atoms that also have their temperature controlled by
another fix - e.g. by <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> or <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> commands.</p>
</div>
<p>See <a class="reference internal" href="Section_howto.html#howto-16"><span class="std std-ref">this howto section</span></a> of the manual for
a discussion of different ways to compute temperature and perform
thermostatting.</p>
<p>This fix computes a temperature each timestep. To do this, the fix
creates its own compute of style “temp”, as if this command had been
<p>See the <a class="reference internal" href="compute_temp.html"><span class="doc">compute temp</span></a> command for details. Note
that the ID of the new compute is the fix-ID + underscore + “temp”,
and the group for the new compute is the same as the fix group.</p>
<p>Note that this is NOT the compute used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>.
This means you can change the attributes of this fix’s temperature
(e.g. its degrees-of-freedom) via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> will have no
effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
-<hr class="docutils" />
-<p>Styles with a <em>cuda</em> suffix are functionally the same as the
-corresponding style without the suffix. They have been optimized to
-run faster, depending on your available hardware, as discussed in
-<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual. The
-accelerated styles take the same arguments and should produce the same
-results, except for round-off and precision issues.</p>
-<p>These accelerated styles are part of the USER-CUDA package. They are
-only enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
-<p>You can specify the accelerated styles explicitly in your input script
-by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
-use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
-<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
-more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to assign a temperature <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>
you have defined to this fix which will be used in its thermostatting
procedure, as described above. For consistency, the group used by
this fix and by the compute should be the same.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change implied by a velocity rescaling to the
system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
cummulative energy change due to this fix. The scalar value
calculated by this fix is “extensive”.</p>
<p>This fix can ramp its target temperature over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix can be used with dynamic groups as defined by the
<a class="reference internal" href="group.html"><span class="doc">group</span></a> command. Likewise it can be used with groups to
which atoms are added or deleted over time, e.g. a deposition
simulation. However, the conservation properties of the thermostat
and barostat are defined for systems with a static set of atoms. You
may observe odd behavior if the atoms in a group vary dramatically
over time or the atom count becomes very small.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Reset the temperature of a group of atoms by explicitly rescaling
their velocities.</p>
<p>The rescaling is applied to only the translational degrees of freedom
for the particles, which is an important consideration if finite-size
particles which have rotational degrees of freedom are being
thermostatted with this fix. The translational degrees of freedom can
also have a bias velocity removed from them before thermostatting
takes place; see the description below.</p>
<p>Rescaling is performed every N timesteps. The target temperature is a
ramped value between the <em>Tstart</em> and <em>Tstop</em> temperatures at the
beginning and end of the run.</p>
<p><em>Tstart</em> can be specified as an equal-style <a class="reference internal" href="variable.html"><span class="doc">variable</span></a>.
In this case, the <em>Tstop</em> setting is ignored. If the value is a
variable, it should be specified as v_name, where name is the variable
name. In this case, the variable will be evaluated each timestep, and
its value used to determine the target temperature.</p>
<p>Equal-style variables can specify formulas with various mathematical
functions, and include <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent temperature.</p>
<p>Rescaling is only performed if the difference between the current and
desired temperatures is greater than the <em>window</em> value. The amount
of rescaling that is applied is a <em>fraction</em> (from 0.0 to 1.0) of the
difference between the actual and desired temperature. E.g. if
<em>fraction</em> = 1.0, the temperature is reset to exactly the desired
value.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Unlike the <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> command which performs
Nose/Hoover thermostatting AND time integration, this fix does NOT
perform time integration. It only modifies velocities to effect
thermostatting. Thus you must use a separate time integration fix,
like <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> to actually update the positions of atoms
using the modified velocities. Likewise, this fix should not normally
be used on atoms that also have their temperature controlled by
another fix - e.g. by <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a> or <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> commands.</p>
</div>
<p>See <a class="reference internal" href="Section_howto.html#howto-16"><span class="std std-ref">this howto section</span></a> of the manual for
a discussion of different ways to compute temperature and perform
thermostatting.</p>
<p>This fix computes a temperature each timestep. To do this, the fix
creates its own compute of style “temp”, as if one of this command had
<p>See the <a class="reference internal" href="compute_temp.html"><span class="doc">compute temp</span></a> for details. Note that the
ID of the new compute is the fix-ID + underscore + “temp”, and the
group for the new compute is the same as the fix group.</p>
<p>Note that this is NOT the compute used by thermodynamic output (see
the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command) with ID = <em>thermo_temp</em>.
This means you can change the attributes of this fix’s temperature
(e.g. its degrees-of-freedom) via the
<a class="reference internal" href="compute_modify.html"><span class="doc">compute_modify</span></a> command or print this temperature
during thermodynamic output via the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command using the appropriate compute-ID.
It also means that changing attributes of <em>thermo_temp</em> will have no
effect on this fix.</p>
<p>Like other fixes that perform thermostatting, this fix can be used
with <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> that calculate a temperature
after removing a “bias” from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual <a class="reference internal" href="compute.html"><span class="doc">compute commands</span></a> to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.</p>
-<hr class="docutils" />
-<p>Styles with a <em>cuda</em> suffix are functionally the same as the
-corresponding style without the suffix. They have been optimized to
-run faster, depending on your available hardware, as discussed in
-<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual. The
-accelerated styles take the same arguments and should produce the same
-results, except for round-off and precision issues.</p>
-<p>These accelerated styles are part of the USER-CUDA package. They are
-only enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
-<p>You can specify the accelerated styles explicitly in your input script
-by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
-use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
-<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
-more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>temp</em> option is supported by this
fix. You can use it to assign a temperature <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>
you have defined to this fix which will be used in its thermostatting
procedure, as described above. For consistency, the group used by
this fix and by the compute should be the same.</p>
<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
fix to add the energy change implied by a velocity rescaling to the
system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
cummulative energy change due to this fix. The scalar value
calculated by this fix is “extensive”.</p>
<p>This fix can ramp its target temperature over multiple runs, using the
<em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. See the
<a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do this.</p>
<p>This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Add a viscous damping force to atoms in the group that is proportional
to the velocity of the atom. The added force can be thought of as a
frictional interaction with implicit solvent, i.e. the no-slip Stokes
drag on a spherical particle. In granular simulations this can be
useful for draining the kinetic energy from the system in a controlled
fashion. If used without additional thermostatting (to add kinetic
energy to the system), it has the effect of slowly (or rapidly)
freezing the system; hence it can also be used as a simple energy
minimization technique.</p>
<p>The damping force F is given by F = - gamma * velocity. The larger
the coefficient, the faster the kinetic energy is reduced. If the
optional keyword <em>scale</em> is used, gamma can scaled up or down by the
specified factor for atoms of that type. It can be used multiple
times to adjust gamma for several atom types.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">You should specify gamma in force/velocity units. This is not
the same as mass/time units, at least for some of the LAMMPS
<a class="reference internal" href="units.html"><span class="doc">units</span></a> options like “real” or “metal” that are not
self-consistent.</p>
</div>
<p>In a Brownian dynamics context, gamma = Kb T / D, where Kb =
Boltzmann’s constant, T = temperature, and D = particle diffusion
coefficient. D can be written as Kb T / (3 pi eta d), where eta =
dynamic viscosity of the frictional fluid and d = diameter of
particle. This means gamma = 3 pi eta d, and thus is proportional to
the viscosity of the fluid and the particle diameter.</p>
<p>In the current implementation, rather than have the user specify a
viscosity, gamma is specified directly in force/velocity units. If
needed, gamma can be adjusted for atoms of different sizes
(i.e. sigma) by using the <em>scale</em> keyword.</p>
<p>Note that Brownian dynamics models also typically include a randomized
force term to thermostat the system at a chosen temperature. The <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> command does this. It has the same
viscous damping term as fix viscous and adds a random force to each
atom. The random force term is proportional to the sqrt of the chosen
thermostatting temperature. Thus if you use fix langevin with a
target T = 0, its random force term is zero, and you are essentially
performing the same operation as fix viscous. Also note that the
gamma of fix viscous is related to the damping parameter of <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a>, however the former is specified in units
of force/velocity and the latter in units of time, so that it can more
easily be used as a thermostat.</p>
-<hr class="docutils" />
-<p>Styles with a <em>cuda</em> suffix are functionally the same as the
-corresponding style without the suffix. They have been optimized to
-run faster, depending on your available hardware, as discussed in
-<a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual. The
-accelerated styles take the same arguments and should produce the same
-results, except for round-off and precision issues.</p>
-<p>These accelerated styles are part of the USER-CUDA package. They are
-only enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
-<p>You can specify the accelerated styles explicitly in your input script
-by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
-use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
-<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
-more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. No parameter of this fix can
be used with the <em>start/stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command.</p>
<p>The forces due to this fix are imposed during an energy minimization,
invoked by the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command. This fix should only
be used with damped dynamics minimizers that allow for
non-conservative forces. See the <a class="reference internal" href="min_style.html"><span class="doc">min_style</span></a> command
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Bound the simulation with one or more walls which reflect particles
in the specified group when they attempt to move thru them.</p>
<p>Reflection means that if an atom moves outside the wall on a timestep
by a distance delta (e.g. due to <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a>), then it is
put back inside the face by the same delta, and the sign of the
corresponding component of its velocity is flipped.</p>
<p>When used in conjunction with <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> and <a class="reference internal" href="run_style.html"><span class="doc">run_style verlet</span></a>, the resultant time-integration algorithm is
equivalent to the primitive splitting algorithm (PSA) described by
<a class="reference internal" href="#bond"><span class="std std-ref">Bond</span></a>. Because each reflection event divides
the corresponding timestep asymmetrically, energy conservation is only
satisfied to O(dt), rather than to O(dt^2) as it would be for
velocity-Verlet integration without reflective walls.</p>
<p>Up to 6 walls or faces can be specified in a single command: <em>xlo</em>,
<em>xhi</em>, <em>ylo</em>, <em>yhi</em>, <em>zlo</em>, <em>zhi</em>. A <em>lo</em> face reflects particles
that move to a coordinate less than the wall position, back in the
<em>hi</em> direction. A <em>hi</em> face reflects particles that move to a
coordinate higher than the wall position, back in the <em>lo</em> direction.</p>
<p>The position of each wall can be specified in one of 3 ways: as the
EDGE of the simulation box, as a constant value, or as a variable. If
EDGE is used, then the corresponding boundary of the current
simulation box is used. If a numeric constant is specified then the
wall is placed at that position in the appropriate dimension (x, y, or
z). In both the EDGE and constant cases, the wall will never move.
If the wall position is a variable, it should be specified as v_name,
where name is an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a> name. In this
case the variable is evaluated each timestep and the result becomes
the current position of the reflecting wall. Equal-style variables
can specify formulas with various mathematical functions, and include
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a> command keywords for the simulation
box parameters and timestep and elapsed time. Thus it is easy to
specify a time-dependent wall position.</p>
<p>The <em>units</em> keyword determines the meaning of the distance units used
to define a wall position, but only when a numeric constant or
variable is used. It is not relevant when EDGE is used to specify a
face position. In the variable case, the variable is assumed to
produce a value compatible with the <em>units</em> setting you specify.</p>
<p>A <em>box</em> value selects standard distance units as defined by the
<a class="reference internal" href="units.html"><span class="doc">units</span></a> command, e.g. Angstroms for units = real or metal.
A <em>lattice</em> value means the distance units are in lattice spacings.
The <a class="reference internal" href="lattice.html"><span class="doc">lattice</span></a> command must have been previously used to
define the lattice spacings.</p>
<hr class="docutils" />
<p>Here are examples of variable definitions that move the wall position
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>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>.
<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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This improper style can only be used if LAMMPS was built with the
CLASS2 package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>X0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This improper style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This improper style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>X0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This improper style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where K is a prefactor, theta is the angle formed by the atoms
specified by (i,j,k,l) indices and theta0 its equilibrium value.</p>
<p>If the 4 atoms in an improper quadruplet (listed in the data file read
by the <a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command) are ordered i,j,k,l then
<a href="#id1"><span class="problematic" id="id2">theta_</span></a><em>ijl</em> is the angle between atoms i,j and l, <a href="#id3"><span class="problematic" id="id4">theta_</span></a><em>ijk</em> is the
angle between atoms i,j and k, <a href="#id5"><span class="problematic" id="id6">theta_</span></a><em>kjl</em> is the angle between atoms
j,k, and l.</p>
<p>The “ring” improper style implements the improper potential introduced
by Destree et al., in Equation (9) of <a class="reference internal" href="#destree"><span class="std std-ref">(Destree)</span></a>. This
potential does not affect small amplitude vibrations but is used in an
ad-hoc way to prevent the onset of accidentially large amplitude
fluctuations leading to the occurrence of a planar conformation of the
three bonds i-j, j-k and j-l, an intermediate conformation toward the
chiral inversion of a methine carbon. In the “Impropers” section of
data file four atoms: i, j, k and l are specified with i,j and l lying
on the backbone of the chain and k specifying the chirality of j.</p>
<p>The following coefficients must be defined for each improper type via
the <a class="reference internal" href="improper_coeff.html"><span class="doc">improper_coeff</span></a> command as in the example
above, or in the data file or restart files read by the
<p>theta0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This improper style can only be used if LAMMPS was built with the
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>If omega0 = 0 the potential term has a minimum for the planar
structure. Otherwise it has two minima at +/- omega0, with a barrier
in between.</p>
<p>See <a class="reference internal" href="#umbrella-mayo"><span class="std std-ref">(Mayo)</span></a> for a description of the DREIDING force field.</p>
<p>The following coefficients must be defined for each improper type via
the <a class="reference internal" href="improper_coeff.html"><span class="doc">improper_coeff</span></a> command as in the example
above, or in the data file or restart files read by the
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This improper style can only be used if LAMMPS was built with the
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<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/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/omp</em> value = accuracy
accuracy = desired relative error in forces
<em>pppm/cg/omp</em> value = accuracy
accuracy = desired relative error in forces
<em>pppm/tip4p/omp</em> value = accuracy
accuracy = desired relative error in forces
<em>pppm/stagger</em> value = accuracy
accuracy = desired relative error in forces
<em>msm</em> value = accuracy
accuracy = desired relative error in forces
<em>msm/cg</em> value = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units)
<em>msm/omp</em> value = accuracy
accuracy = desired relative error in forces
<em>msm/cg/omp</em> value = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units)
<p>Define a long-range solver for LAMMPS to use each timestep to compute
long-range Coulombic interactions or long-range 1/r^6 interactions.
Most of the long-range solvers perform their computation in K-space,
hence the name of this command.</p>
<p>When such a solver is used in conjunction with an appropriate pair
style, the cutoff for Coulombic or 1/r^N interactions is effectively
infinite. If the Coulombic case, this means each charge in the system
interacts with charges in an infinite array of periodic images of the
simulation domain.</p>
<p>Note that using a long-range solver requires use of a matching <span class="xref doc">pair style</span> 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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>More specifically, the <em>pppm/gpu</em> style performs charge assignment and
force interpolation calculations on the GPU. These processes are
performed either in single or double precision, depending on whether
the -DFFT_SINGLE setting was specified in your lo-level Makefile, as
discussed above. The FFTs themselves are still calculated on the CPU.
If <em>pppm/gpu</em> is used with a GPU-enabled pair style, part of the PPPM
calculation can be performed concurrently on the GPU while other
calculations for non-bonded and bonded force calculation are performed
on the CPU.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
+<p>These accelerated styles are part of the GPU, USER-INTEL,
KOKKOS, USER-OMP, and OPT packages respectively. They are only
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>Note that the long-range electrostatic solvers in LAMMPS assume conducting
metal (tinfoil) boundary conditions for both charge and dipole
interactions. Vacuum boundary conditions are not currently supported.</p>
<p>The <em>ewald/disp</em>, <em>ewald</em>, <em>pppm</em>, and <em>msm</em> styles support
-non-orthogonal (triclinic symmetry) simulation boxes. However, triclinic
-simulation cells may not yet be supported by suffix versions of these
-styles (such as <em>pppm/cuda</em>).</p>
+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
Built with <a href="http://sphinx-doc.org/">Sphinx</a> 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>cuda</em> or <em>gpu</em> or <em>intel</em> or <em>kokkos</em> or <em>omp</em></li>
+<li>style = <em>gpu</em> or <em>intel</em> or <em>kokkos</em> or <em>omp</em></li>
<li>args = arguments specific to the style</li>
</ul>
<pre class="literal-block">
-<em>cuda</em> args = Ngpu keyword value ...
- Ngpu = # of GPUs per node
- zero or more keyword/value pairs may be appended
- keywords = <em>newton</em> or <em>gpuID</em> or <em>timing</em> or <em>test</em> or <em>thread</em>
- <em>newton</em> = <em>off</em> or <em>on</em>
- off = set Newton pairwise and bonded flags off (default)
- on = set Newton pairwise and bonded flags on
- <em>gpuID</em> values = gpu1 .. gpuN
- gpu1 .. gpuN = IDs of the Ngpu GPUs to use
- <em>timing</em> values = none
- <em>test</em> values = id
- id = atom-ID of a test particle
- <em>thread</em> = auto or tpa or bpa
- auto = test whether tpa or bpa is faster
- tpa = one thread per atom
- bpa = one block per atom
<em>gpu</em> args = Ngpu keyword value ...
Ngpu = # of GPUs per node
zero or more keyword/value pairs may be appended
keywords = <em>neigh</em> or <em>newton</em> or <em>binsize</em> or <em>split</em> or <em>gpuID</em> or <em>tpa</em> or <em>device</em> or <em>blocksize</em>
<em>neigh</em> value = <em>yes</em> or <em>no</em>
yes = neighbor list build on GPU (default)
no = neighbor list build on CPU
<em>newton</em> = <em>off</em> or <em>on</em>
off = set Newton pairwise flag off (default and required)
on = set Newton pairwise flag on (currently not allowed)
<em>binsize</em> value = size
size = bin size for neighbor list construction (distance units)
<em>split</em> = fraction
fraction = fraction of atoms assigned to GPU (default = 1.0)
<em>gpuID</em> values = first last
first = ID of first GPU to be used on each node
last = ID of last GPU to be used on each node
<em>tpa</em> value = Nthreads
Nthreads = # of GPU threads used per atom
<em>device</em> value = device_type
device_type = <em>kepler</em> or <em>fermi</em> or <em>cypress</em> or <em>generic</em>
<em>blocksize</em> value = size
size = thread block size for pair force computation
<em>intel</em> args = NPhi keyword value ...
Nphi = # of coprocessors per node
zero or more keyword/value pairs may be appended
keywords = <em>omp</em> or <em>mode</em> or <em>balance</em> or <em>ghost</em> or <em>tpc</em> or <em>tptask</em> or <em>no_affinity</em>
<em>omp</em> value = Nthreads
Nthreads = number of OpenMP threads to use on CPU (default = 0)
<em>mode</em> value = <em>single</em> or <em>mixed</em> or <em>double</em>
single = perform force calculations in single precision
mixed = perform force calculations in mixed precision
double = perform force calculations in double precision
<em>balance</em> value = split
split = fraction of work to offload to coprocessor, -1 for dynamic
<em>ghost</em> value = <em>yes</em> or <em>no</em>
yes = include ghost atoms for offload
no = do not include ghost atoms for offload
<em>tpc</em> value = Ntpc
Ntpc = max number of coprocessor threads per coprocessor core (default = 4)
<em>tptask</em> value = Ntptask
Ntptask = max number of coprocessor threads per MPI task (default = 240)
<em>no_affinity</em> values = none
<em>kokkos</em> args = keyword value ...
zero or more keyword/value pairs may be appended
keywords = <em>neigh</em> or <em>newton</em> or <em>binsize</em> or <em>comm</em> or <em>comm/exchange</em> or <em>comm/forward</em>
<em>neigh</em> value = <em>full</em> or <em>half</em> or <em>n2</em> or <em>full/cluster</em>
full = full neighbor list
half = half neighbor list built in thread-safe manner
n2 = non-binning neighbor list build, O(N^2) algorithm
full/cluster = full neighbor list with clustered groups of atoms
<em>newton</em> = <em>off</em> or <em>on</em>
off = set Newton pairwise and bonded flags off (default)
on = set Newton pairwise and bonded flags on
<em>binsize</em> value = size
size = bin size for neighbor list construction (distance units)
<em>comm</em> value = <em>no</em> or <em>host</em> or <em>device</em>
use value for both comm/exchange and comm/forward
<em>comm/exchange</em> value = <em>no</em> or <em>host</em> or <em>device</em>
<em>comm/forward</em> value = <em>no</em> or <em>host</em> or <em>device</em>
no = perform communication pack/unpack in non-KOKKOS mode
host = perform pack/unpack on host (e.g. with OpenMP threading)
device = perform pack/unpack on device (e.g. on GPU)
<em>omp</em> args = Nthreads keyword value ...
Nthread = # of OpenMP threads to associate with each MPI process
zero or more keyword/value pairs may be appended
keywords = <em>neigh</em>
<em>neigh</em> value = <em>yes</em> or <em>no</em>
<p>This command invokes package-specific settings for the various
accelerator packages available in LAMMPS. Currently the following
-packages use settings from this command: USER-CUDA, GPU, USER-INTEL,
-KOKKOS, and USER-OMP.</p>
+packages use settings from this command: GPU, USER-INTEL, KOKKOS, and
+USER-OMP.</p>
<p>If this command is specified in an input script, it must be near the
top of the script, before the simulation box has been defined. This
is because it specifies settings that the accelerator packages use in
their intialization, before a simultion is defined.</p>
<p>This command can also be specified from the command-line when
launching LAMMPS, using the “-pk” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>. The syntax is exactly the same as
when used in an input script.</p>
<p>Note that all of the accelerator packages require the package command
to be specified (except the OPT package), if the package is to be used
in a simulation (LAMMPS can be built with an accelerator package
without using it in a particular simulation). However, in all cases,
a default version of the command is typically invoked by other
accelerator settings.</p>
-<p>The USER-CUDA and KOKKOS packages require a “-c on” or “-k on”
-<a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> respectively, which
-invokes a “package cuda” or “package kokkos” command with default
-settings.</p>
+<p>The KOKKOS package requires a “-k on” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> respectively, which invokes a
+“package kokkos” command with default settings.</p>
<p>For the GPU, USER-INTEL, and USER-OMP packages, if a “-sf gpu” or “-sf
is used to auto-append accelerator suffixes to various styles in the
input script, then those switches also invoke a “package gpu”,
“package intel”, or “package omp” command with default settings.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">A package command for a particular style can be invoked multiple
times when a simulation is setup, e.g. by the “-c on”, “-k on”, “-sf”,
and “-pk” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switches</span></a>, and by
using this command in an input script. Each time it is used all of
the style options are set, either to default values or to specified
settings. I.e. settings from previous invocations do not persist
across multiple invocations.</p>
</div>
<p>See the <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section Accelerate</span></a> section of the
manual for more details about using the various accelerator packages
for speeding up LAMMPS simulations.</p>
<hr class="docutils" />
-<p>The <em>cuda</em> style invokes settings associated with the use of the
-USER-CUDA package.</p>
-<p>The <em>Ngpus</em> argument sets the number of GPUs per node. There must be
-exactly one MPI task per GPU, as set by the mpirun or mpiexec command.</p>
-<p>Optional keyword/value pairs can also be specified. Each has a
-default value as listed below.</p>
-<p>The <em>newton</em> keyword sets the Newton flags for pairwise and bonded
-interactions to <em>off</em> or <em>on</em>, the same as the <a class="reference internal" href="newton.html"><span class="doc">newton</span></a>
-command allows. The default is <em>off</em> because this will almost always
-give better performance for the USER-CUDA package. This means
-more computation is done, but less communication.</p>
-<p>The <em>gpuID</em> keyword allows selection of which GPUs on each node will
-be used for a simulation. GPU IDs range from 0 to N-1 where N is the
-physical number of GPUs/node. An ID is specified for each of the
-Ngpus being used. For example if you have three GPUs on a machine,
-one of which is used for the X-Server (the GPU with the ID 1) while
-the others (with IDs 0 and 2) are used for computations you would
<p>In this case, all CPU cores and GPU devices on the nodes would be
utilized. Each GPU device would be shared by 4 CPU cores. The CPU
cores would perform force calculations for some fraction of the
particles at the same time the GPUs performed force calculation for
the other particles.</p>
<p>The <em>gpuID</em> keyword allows selection of which GPUs on each node will
be used for a simulation. The <em>first</em> and <em>last</em> values specify the
GPU IDs to use (from 0 to Ngpu-1). By default, first = 0 and last =
Ngpu-1, so that all GPUs are used, assuming Ngpu is set to the number
of physical GPUs. If you only wish to use a subset, set Ngpu to a
smaller number and first/last to a sub-range of the available GPUs.</p>
<p>The <em>tpa</em> keyword sets the number of GPU thread per atom used to
perform force calculations. With a default value of 1, the number of
threads will be chosen based on the pair style, however, the value can
be set explicitly with this keyword to fine-tune performance. For
large cutoffs or with a small number of particles per GPU, increasing
the value can improve performance. The number of threads per atom must
be a power of 2 and currently cannot be greater than 32.</p>
<p>The <em>device</em> keyword can be used to tune parameters optimized for a
specific accelerator, when using OpenCL. For CUDA, the <em>device</em>
keyword is ignored. Currently, the device type is limited to NVIDIA
Kepler, NVIDIA Fermi, AMD Cypress, or a generic device. More devices
may be added later. The default device type can be specified when
building LAMMPS with the GPU library, via settings in the
lib/gpu/Makefile that is used.</p>
<p>The <em>blocksize</em> keyword allows you to tweak the number of threads used
per thread block. This number should be a multiple of 32 (for GPUs)
and its maximum depends on the specific GPU hardware. Typical choices
are 64, 128, or 256. A larger blocksize increases occupancy of
individual GPU cores, but reduces the total number of thread blocks,
thus may lead to load imbalance.</p>
<hr class="docutils" />
<p>The <em>intel</em> style invokes settings associated with the use of the
USER-INTEL package. All of its settings, except the <em>omp</em> and <em>mode</em>
keywords, are ignored if LAMMPS was not built with Xeon Phi
coprocessor support. All of its settings, including the <em>omp</em> and
<em>mode</em> keyword are applicable if LAMMPS was built with coprocessor
support.</p>
<p>The <em>Nphi</em> argument sets the number of coprocessors per node.
This can be set to any value, including 0, if LAMMPS was not
built with coprocessor support.</p>
<p>Optional keyword/value pairs can also be specified. Each has a
default value as listed below.</p>
<p>The <em>omp</em> keyword determines the number of OpenMP threads allocated
for each MPI task when any portion of the interactions computed by a
USER-INTEL pair style are run on the CPU. This can be the case even
if LAMMPS was built with coprocessor support; see the <em>balance</em>
keyword discussion below. If you are running with less MPI tasks/node
than there are CPUs, it can be advantageous to use OpenMP threading on
the CPUs.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The <em>omp</em> keyword has nothing to do with coprocessor threads on
the Xeon Phi; see the <em>tpc</em> and <em>tptask</em> keywords below for a
discussion of coprocessor threads.</p>
</div>
<p>The <em>Nthread</em> value for the <em>omp</em> keyword sets the number of OpenMP
threads allocated for each MPI task. Setting <em>Nthread</em> = 0 (the
default) instructs LAMMPS to use whatever value is the default for the
given OpenMP environment. This is usually determined via the
<em>OMP_NUM_THREADS</em> environment variable or the compiler runtime, which
is usually a value of 1.</p>
<p>For more details, including examples of how to set the OMP_NUM_THREADS
environment variable, see the discussion of the <em>Nthreads</em> setting on
this doc page for the “package omp” command. Nthreads is a required
argument for the USER-OMP package. Its meaning is exactly the same
for the USER-INTEL pacakge.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you build LAMMPS with both the USER-INTEL and USER-OMP
packages, be aware that both packages allow setting of the <em>Nthreads</em>
value via their package commands, but there is only a single global
<em>Nthreads</em> value used by OpenMP. Thus if both package commands are
invoked, you should insure the two values are consistent. If they are
not, the last one invoked will take precedence, for both packages.
Also note that if the “-sf hybrid intel omp” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> is used, it invokes a “package
intel” command, followed by a “package omp” command, both with a
setting of <em>Nthreads</em> = 0.</p>
</div>
<p>The <em>mode</em> keyword determines the precision mode to use for
computing pair style forces, either on the CPU or on the coprocessor,
when using a USER-INTEL supported <a class="reference internal" href="pair_style.html"><span class="doc">pair style</span></a>. It
can take a value of <em>single</em>, <em>mixed</em> which is the default, or
<em>double</em>. <em>Single</em> means single precision is used for the entire
force calculation. <em>Mixed</em> means forces between a pair of atoms are
computed in single precision, but accumulated and stored in double
precision, including storage of forces, torques, energies, and virial
quantities. <em>Double</em> means double precision is used for the entire
force calculation.</p>
<p>The <em>balance</em> keyword sets the fraction of <a class="reference internal" href="pair_style.html"><span class="doc">pair style</span></a> work offloaded to the coprocessor for split
values between 0.0 and 1.0 inclusive. While this fraction of work is
running on the coprocessor, other calculations will run on the host,
including neighbor and pair calculations that are not offloaded, as
well as angle, bond, dihedral, kspace, and some MPI communications.
If <em>split</em> is set to -1, the fraction of work is dynamically adjusted
automatically throughout the run. This typically give performance
within 5 to 10 percent of the optimal fixed fraction.</p>
<p>The <em>ghost</em> keyword determines whether or not ghost atoms, i.e. atoms
at the boundaries of proessor sub-domains, are offloaded for neighbor
and force calculations. When the value = “no”, ghost atoms are not
offloaded. This option can reduce the amount of data transfer with
the coprocessor and can also overlap MPI communication of forces with
computation on the coprocessor when the <a class="reference internal" href="newton.html"><span class="doc">newton pair</span></a>
setting is “on”. When the value = “yes”, ghost atoms are offloaded.
In some cases this can provide better performance, especially if the
<em>balance</em> fraction is high.</p>
<p>The <em>tpc</em> keyword sets the max # of coprocessor threads <em>Ntpc</em> that
will run on each core of the coprocessor. The default value = 4,
which is the number of hardware threads per core supported by the
current generation Xeon Phi chips.</p>
<p>The <em>tptask</em> keyword sets the max # of coprocessor threads (Ntptask*
assigned to each MPI task. The default value = 240, which is the
total # of threads an entire current generation Xeon Phi chip can run
(240 = 60 cores * 4 threads/core). This means each MPI task assigned
to the Phi will enough threads for the chip to run the max allowed,
even if only 1 MPI task is assigned. If 8 MPI tasks are assigned to
the Phi, each will run with 30 threads. If you wish to limit the
number of threads per MPI task, set <em>tptask</em> to a smaller value.
E.g. for <em>tptask</em> = 16, if 8 MPI tasks are assigned, each will run
with 16 threads, for a total of 128.</p>
<p>Note that the default settings for <em>tpc</em> and <em>tptask</em> are fine for
most problems, regardless of how many MPI tasks you assign to a Phi.</p>
<p>The <em>no_affinity</em> keyword will turn off automatic setting of core
affinity for MPI tasks and OpenMP threads on the host when using
offload to a coprocessor. Affinity settings are used when possible
to prevent MPI tasks and OpenMP threads from being on separate NUMA
domains and to prevent offload threads from interfering with other
processes/threads used for LAMMPS.</p>
<hr class="docutils" />
<p>The <em>kokkos</em> style invokes settings associated with the use of the
KOKKOS package.</p>
<p>All of the settings are optional keyword/value pairs. Each has a
default value as listed below.</p>
<p>The <em>neigh</em> keyword determines how neighbor lists are built. A value
of <em>half</em> uses a thread-safe variant of half-neighbor lists,
the same as used by most pair styles in LAMMPS. A value of
<em>n2</em> uses an O(N^2) algorithm to build the neighbor list without
binning, where N = # of atoms on a processor. It is typically slower
than the other methods, which use binning.</p>
<p>A value of <em>full</em> uses a full neighbor lists and is the default. This
performs twice as much computation as the <em>half</em> option, however that
is often a win because it is thread-safe and doesn’t require atomic
operations in the calculation of pair forces. For that reason, <em>full</em>
is the default setting. However, when running in MPI-only mode with 1
thread per MPI task, <em>half</em> neighbor lists will typically be faster,
just as it is for non-accelerated pair styles.</p>
<p>A value of <em>full/cluster</em> is an experimental neighbor style, where
particles interact with all particles within a small cluster, if at
least one of the clusters particles is within the neighbor cutoff
range. This potentially allows for better vectorization on
architectures such as the Intel Phi. If also reduces the size of the
neighbor list by roughly a factor of the cluster size, thus reducing
the total memory footprint considerably.</p>
<p>The <em>newton</em> keyword sets the Newton flags for pairwise and bonded
interactions to <em>off</em> or <em>on</em>, the same as the <a class="reference internal" href="newton.html"><span class="doc">newton</span></a>
command allows. The default is <em>off</em> because this will almost always
give better performance for the KOKKOS package. This means more
computation is done, but less communication. However, when running in
MPI-only mode with 1 thread per MPI task, a value of <em>on</em> will
typically be faster, just as it is for non-accelerated pair styles.</p>
<p>The <em>binsize</em> keyword sets the size of bins used to bin atoms in
neighbor list builds. The same value can be set by the <a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify binsize</span></a> command. Making it an option in the
package kokkos command allows it to be set from the command line. The
default value is 0.0, which means the LAMMPS default will be used,
which is bins = 1/2 the size of the pairwise cutoff + neighbor skin
distance. This is fine when neighbor lists are built on the CPU. For
GPU builds, a 2x larger binsize equal to the pairwise cutoff +
neighbor skin, is often faster, which can be set by this keyword.
Note that if you use a longer-than-usual pairwise cutoff, e.g. to
allow for a smaller fraction of KSpace work with a <a class="reference internal" href="kspace_style.html"><span class="doc">long-range Coulombic solver</span></a> because the GPU is faster at
performing pairwise interactions, then this rule of thumb may give too
large a binsize.</p>
<p>The <em>comm</em> and <em>comm/exchange</em> and <em>comm/forward</em> keywords determine
whether the host or device performs the packing and unpacking of data
when communicating per-atom data between processors. “Exchange”
communication happens only on timesteps that neighbor lists are
rebuilt. The data is only for atoms that migrate to new processors.
“Forward” communication happens every timestep. The data is for atom
coordinates and any other atom properties that needs to be updated for
ghost atoms owned by each processor.</p>
<p>The <em>comm</em> keyword is simply a short-cut to set the same value
for both the <em>comm/exchange</em> and <em>comm/forward</em> keywords.</p>
<p>The value options for all 3 keywords are <em>no</em> or <em>host</em> or <em>device</em>.
A value of <em>no</em> means to use the standard non-KOKKOS method of
packing/unpacking data for the communication. A value of <em>host</em> means
to use the host, typically a multi-core CPU, and perform the
packing/unpacking in parallel with threads. A value of <em>device</em> means
to use the device, typically a GPU, to perform the packing/unpacking
operation.</p>
<p>The optimal choice for these keywords depends on the input script and
the hardware used. The <em>no</em> value is useful for verifying that the
Kokkos-based <em>host</em> and <em>device</em> values are working correctly. It may
also be the fastest choice when using Kokkos styles in MPI-only mode
(i.e. with a thread count of 1).</p>
<p>When running on CPUs or Xeon Phi, the <em>host</em> and <em>device</em> values work
identically. When using GPUs, the <em>device</em> value will typically be
optimal if all of your styles used in your input script are supported
by the KOKKOS package. In this case data can stay on the GPU for many
timesteps without being moved between the host and GPU, if you use the
<em>device</em> value. This requires that your MPI is able to access GPU
memory directly. Currently that is true for OpenMPI 1.8 (or later
versions), Mvapich2 1.9 (or later), and CrayMPI. If your script uses
styles (e.g. fixes) which are not yet supported by the KOKKOS package,
then data has to be move between the host and device anyway, so it is
typically faster to let the host handle communication, by using the
<em>host</em> value. Using <em>host</em> instead of <em>no</em> will enable use of
multiple threads to pack/unpack communicated data.</p>
<hr class="docutils" />
<p>The <em>omp</em> style invokes settings associated with the use of the
USER-OMP package.</p>
<p>The <em>Nthread</em> argument sets the number of OpenMP threads allocated for
each MPI task. For example, if your system has nodes with dual
quad-core processors, it has a total of 8 cores per node. You could
use two MPI tasks per node (e.g. using the -ppn option of the mpirun
command in MPICH or -npernode in OpenMPI), and set <em>Nthreads</em> = 4.
This would use all 8 cores on each node. Note that the product of MPI
tasks * threads/task should not exceed the physical number of cores
(on a node), otherwise performance will suffer.</p>
<p>Setting <em>Nthread</em> = 0 instructs LAMMPS to use whatever value is the
default for the given OpenMP environment. This is usually determined
via the <em>OMP_NUM_THREADS</em> environment variable or the compiler
runtime. Note that in most cases the default for OpenMP capable
compilers is to use one thread for each available CPU core when
<em>OMP_NUM_THREADS</em> is not explicitly set, which can lead to poor
performance.</p>
<p>Here are examples of how to set the environment variable when
-<p>The cuda style of this command can only be invoked if LAMMPS was built
-with the USER-CUDA package. See the <a 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 gpu style of this command can only be invoked if LAMMPS was built
with the GPU package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The intel style of this command can only be invoked if LAMMPS was
built with the USER-INTEL package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The kk style of this command can only be invoked if LAMMPS was built
with the KOKKOS package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The omp style of this command can only be invoked if LAMMPS was built
with the USER-OMP package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
-<p>For the USER-CUDA package, the default is Ngpu = 1 and the option
-defaults are newton = off, gpuID = 0 to Ngpu-1, timing = not enabled,
-test = not enabled, and thread = auto. These settings are made
-automatically by the required “-c on” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>. You can change them bu using the
-package cuda command in your input script or via the “-pk cuda”
<p>For the GPU package, the default is Ngpu = 1 and the option defaults
are neigh = yes, newton = off, binsize = 0.0, split = 1.0, gpuID = 0
to Ngpu-1, tpa = 1, and device = not used. These settings are made
automatically if the “-sf gpu” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> is used. If it is not used, you
must invoke the package gpu command in your input script or via the
240. The default ghost option is determined by the pair style being
used. This value is output to the screen in the offload report at the
end of each run. Note that all of these settings, except “omp” and
“mode”, are ignored if LAMMPS was not built with Xeon Phi coprocessor
support. These settings are made automatically if the “-sf intel”
<a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> is used. If it is
not used, you must invoke the package intel command in your input
script or or via the “-pk intel” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>.</p>
<p>For the KOKKOS package, the option defaults neigh = full, newton =
off, binsize = 0.0, and comm = device. These settings are made
automatically by the required “-k on” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>. You can change them bu using the
package kokkos command in your input script or via the “-pk kokkos”
<p>For the OMP package, the default is Nthreads = 0 and the option
defaults are neigh = yes. These settings are made automatically if
the “-sf omp” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a> is
used. If it is not used, you must invoke the package omp command in
your input script or via the “-pk omp” <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">command-line switch</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Style <em>adp</em> computes pairwise interactions for metals and metal alloys
using the angular dependent potential (ADP) of <a class="reference internal" href="#mishin"><span class="std std-ref">(Mishin)</span></a>,
which is a generalization of the <a class="reference internal" href="pair_eam.html"><span class="doc">embedded atom method (EAM) potential</span></a>. The LAMMPS implementation is discussed in
<a class="reference internal" href="#singh"><span class="std std-ref">(Singh)</span></a>. The total energy Ei of an atom I is given by</p>
Nelements). The tabulated values for each phi function are listed as
r*phi (in units of eV-Angstroms), since they are for atom pairs, the
same as for <a class="reference internal" href="pair_eam.html"><span class="doc">other EAM files</span></a>.</p>
<p>After the phi(r) arrays, each of the u(r) arrays are listed in the
same order with the same assumptions of symmetry. Directly following
the u(r), the w(r) arrays are listed. Note that phi(r) is the only
array tabulated with a scaling by r.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, no special mixing rules are needed, since
the ADP potential files specify alloy interactions explicitly.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in tabulated potential files.
Thus, you need to re-specify the pair_style and pair_coeff commands in
an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The first three C arguments map LAMMPS atom types 1,2,3 to the C
element in the AIREBO file. The final H argument maps LAMMPS atom
type 4 to the H element in the SW file. If a mapping value is
specified as NULL, the mapping is not performed. This can be used
when a <em>airebo</em> potential is used as part of the <em>hybrid</em> pair style.
The NULL values are placeholders for atom types that will be used with
other potentials.</p>
<p>The parameters/coefficients for the AIREBO potentials are listed in
the CH.airebo file to agree with the original <a class="reference internal" href="#stuart"><span class="std std-ref">(Stuart)</span></a>
paper. Thus the parameters are specific to this potential and the way
it was fit, so modifying the file should be done cautiously.</p>
<p>Similarly the parameters/coefficients for the AIREBO-M potentials are
listed in the CH.airebo-m file to agree with the <a class="reference internal" href="#oconnor"><span class="std std-ref">(O’Connor)</span></a>
paper. Thus the parameters are specific to this potential and the way
it was fit, so modifying the file should be done cautiously. The
AIREBO-M Morse potentials were parameterized using a cutoff of
3.0 (sigma). Modifying this cutoff may impact simulation accuracy.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>These pair styles do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
mix, shift, table, and tail options.</p>
<p>These pair styles do not write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The last coefficient is optional. If not specified, the global cutoff
Rc is used.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, coeffiecients must be specified.
No default mixing rules are used.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift
option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>These pair styles do not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>These styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option
for the energy of the exp(), 1/r^6, and 1/r^8 portion of the pair
interaction.</p>
<p>The <em>born/coul/long</em> pair style supports the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option ti tabulate the
short-range portion of the long-range Coulombic interaction.</p>
<p>These styles support the pair_modify tail option for adding long-range
tail corrections to energy and pressure.</p>
<p>Thess styles writes thei information to binary <a class="reference internal" href="restart.html"><span class="doc">restart</span></a>
files, so pair_style and pair_coeff commands do not need to be
specified in an input script that reads a restart file.</p>
<p>These styles can only be used via the <em>pair</em> keyword of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the <em>inner</em>,
<em>middle</em>, <em>outer</em> keywords.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The <em>born/coul/long</em> style is part of the KSPACE package. It is only
enabled if LAMMPS was built with that package (which it is by
default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Styles <em>brownian</em> and <em>brownain/poly</em> compute Brownian forces and
torques on finite-size spherical particles. The former requires
monodisperse spherical particles; the latter allows for polydisperse
spherical particles.</p>
<p>These pair styles are designed to be used with either the <a class="reference internal" href="pair_lubricate.html"><span class="doc">pair_style lubricate</span></a> or <a class="reference internal" href="pair_lubricateU.html"><span class="doc">pair_style lubricateU</span></a> commands to provide thermostatting
when dissipative lubrication forces are acting. Thus the parameters
<em>mu</em>, <em>flaglog</em>, <em>flagfld</em>, <em>cutinner</em>, and <em>cutoff</em> should be
specified consistent with the settings in the lubrication pair styles.
For details, refer to either of the lubrication pair styles.</p>
<p>The <em>t_target</em> setting is used to specify the target temperature of
the system. The random number <em>seed</em> is used to generate random
numbers for the thermostatting procedure.</p>
<p>The <em>flagHI</em> and <em>flagVF</em> settings are optional. Neither should be
used, or both must be defined.</p>
<hr class="docutils" />
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<p>The two coefficients are optional. If neither is specified, the two
cutoffs specified in the pair_style command are used. Otherwise both
must be specified.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">this section</span></a> of
the manual. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">this section</span></a> of the manual for more
instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the two cutoff distances for this
pair style can be mixed. The default mix value is <em>geometric</em>. See
the “pair_modify” command for details.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using 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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>These pair styles do not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>These styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option
for the energy of the exp() and 1/r^6 portion of the pair interaction.</p>
<p>The <em>buck/coul/long</em> pair style supports the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option to tabulate the
short-range portion of the long-range Coulombic interaction.</p>
<p>These styles support the pair_modify tail option for adding long-range
tail corrections to energy and pressure for the A,C terms in the
pair interaction.</p>
<p>These styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>These styles can only be used via the <em>pair</em> keyword of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the <em>inner</em>,
<em>middle</em>, <em>outer</em> keywords.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The <em>buck/coul/long</em> style is part of the KSPACE package. The
<em>buck/coul/long/cs</em> style is part of the CORESHELL package. They are
only enabled if LAMMPS was built with that package (which it is by
default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The second coefficient, rho, must be greater than zero.</p>
<p>The latter 2 coefficients are optional. If not specified, the global
Buckingham and Coulombic cutoffs specified in the pair_style command
are used. If only one cutoff is specified, it is used as the cutoff
for both Buckingham and Coulombic interactions for this type pair. If
both coefficients are specified, they are used as the Buckingham and
Coulombic cutoffs for this type pair. Note that if you are using
<em>flag_buck</em> set to <em>long</em>, you cannot specify a Buckingham cutoff for
an atom type pair, since only one global Buckingham cutoff is allowed.
Similarly, if you are using <em>flag_coul</em> set to <em>long</em>, you cannot
specify a Coulombic cutoff for an atom type pair, since only one
global Coulombic cutoff is allowed.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the exp() and 1/r^6 portion of the pair
interaction, assuming <em>flag_buck</em> is <em>cut</em>.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the Buckingham portion of the pair
interaction.</p>
<p>This pair style supports the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table and
table/disp options since they can tabulate the short-range portion of
the long-range Coulombic and dispersion interactions.</p>
<p>This pair style write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style supports the use of the <em>inner</em>, <em>middle</em>, and <em>outer</em>
keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command, meaning the
pairwise forces can be partitioned by distance at different levels of
the rRESPA hierarchy. See the <a class="reference internal" href="run_style.html"><span class="doc">run_style</span></a> command for
details.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This style is part of the KSPACE package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info. Note that
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>style = <em>lj/charmm/coul/charmm</em> or <em>lj/charmm/coul/charmm/implicit</em> or <em>lj/charmm/coul/long</em> or <em>lj/charmm/coul/msm</em></li>
<li>args = list of arguments for a particular style</li>
<p>Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum at 2^(1/6)
sigma.</p>
<p>The latter 2 coefficients are optional. If they are specified, they
are used in the LJ formula between 2 atoms of these types which are
also first and fourth atoms in any dihedral. No cutoffs are specified
because this CHARMM force field does not allow varying cutoffs for
individual atom pairs; all pairs use the global cutoff(s) specified in
the pair_style command.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
corrections to energy and pressure, since the Lennard-Jones portion of
the pair interaction is smoothed to 0.0 at the cutoff.</p>
<p>All of the lj/charmm pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.</p>
<p>The lj/charmm/coul/long pair style supports the use of the <em>inner</em>,
<em>middle</em>, and <em>outer</em> keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a>
command, meaning the pairwise forces can be partitioned by distance at
different levels of the rRESPA hierarchy. The other styles only
support the <em>pair</em> keyword of run_style respa. See the
<a class="reference internal" href="run_style.html"><span class="doc">run_style</span></a> command for details.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The <em>lj/charmm/coul/charmm</em> and <em>lj/charmm/coul/charmm/implicit</em>
styles are part of the MOLECULE package. The <em>lj/charmm/coul/long</em>
style is part of the KSPACE package. They are only enabled if LAMMPS
was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info. Note that
the MOLECULE and KSPACE packages are installed by default.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The <em>lj/class2/coul/cut</em> and <em>lj/class2/coul/long</em> styles add a
Coulombic term as described for the <a class="reference internal" href="pair_lj.html"><span class="doc">lj/cut</span></a> pair styles.</p>
<p>See <a class="reference internal" href="#pair-sun"><span class="std std-ref">(Sun)</span></a> for a description of the COMPASS class2 force field.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<p>The latter 2 coefficients are optional. If not specified, the global
class 2 and Coulombic cutoffs are used. If only one cutoff is
specified, it is used as the cutoff for both class 2 and Coulombic
interactions for this type pair. If both coefficients are specified,
they are used as the class 2 and Coulombic cutoffs for this type pair.
You cannot specify 2 cutoffs for style <em>lj/class2</em>, since it has no
Coulombic terms.</p>
<p>For <em>lj/class2/coul/long</em> only the class 2 cutoff can be specified
since a Coulombic cutoff cannot be specified for an individual I,J
type pair. All type pairs use the same global Coulombic cutoff
specified in the pair_style command.</p>
<hr class="docutils" />
<p>If the pair_coeff command is not used to define coefficients for a
particular I != J type pair, the mixing rule for epsilon and sigma for
all class2 potentials is to use the <em>sixthpower</em> formulas documented
by the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> command. The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify mix</span></a> setting is thus ignored for class2 potentials
for epsilon and sigma. However it is still followed for mixing the
cutoff distance.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/class2 pair styles can be mixed.
Epsilon and sigma are always mixed with the value <em>sixthpower</em>. The
cutoff distance is mixed by whatever option is set by the pair_modify
command (default = geometric). See the “pair_modify” command for
details.</p>
<p>All of the lj/class2 pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option for the energy of the
Lennard-Jones portion of the pair interaction.</p>
<p>The <em>lj/class2/coul/long</em> pair style does not support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option since a tabulation
capability has not yet been added to this potential.</p>
<p>All of the lj/class2 pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> tail option for adding a long-range
tail correction to the energy and pressure of the Lennard-Jones
portion of the pair interaction.</p>
<p>All of the lj/class2 pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.</p>
<p>All of the lj/class2 pair styles can only be used via the <em>pair</em>
keyword of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not
support the <em>inner</em>, <em>middle</em>, <em>outer</em> keywords.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>These styles are part of the CLASS2 package. They are only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>with A_ss set appropriately, which results from letting both particle
sizes go to zero.</p>
<p>When used in combination with <a class="reference internal" href="#"><span class="doc">pair_style yukawa/colloid</span></a>, the two terms become the so-called
DLVO potential, which combines electrostatic repulsion and van der
Waals attraction.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>This style is part of the COLLOID package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Normally, this pair style should be used with finite-size particles
which have a diameter, e.g. see the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style sphere</span></a> command. However, this is not a requirement,
since the only definition of particle size is via the pair_coeff
parameters for each type. In other words, the physical radius of the
particle is ignored. Thus you should insure that the d1,d2 parameters
you specify are consistent with the physical size of the particles of
that type.</p>
<p>Per-particle polydispersity is not yet supported by this pair style;
only per-type polydispersity is enabled via the pair_coeff parameters.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Style <em>comb</em> computes the second-generation variable charge COMB
(Charge-Optimized Many-Body) potential. Style <em>comb3</em> computes the
third-generation COMB potential. These COMB potentials are described
in <a class="reference internal" href="#comb"><span class="std std-ref">(COMB)</span></a> and <a class="reference internal" href="#comb3"><span class="std std-ref">(COMB3)</span></a>. Briefly, the total energy
<em>E<sub>T</sub></em> of a system of atoms is given by</p>
<p>where <em>E<sub>i</sub><sup>self</sup></em> is the self-energy of atom <em>i</em>
(including atomic ionization energies and electron affinities),
<em>E<sub>ij</sub><sup>short</sup></em> is the bond-order potential between
atoms <em>i</em> and <em>j</em>,
<em>E<sub>ij</sub><sup>Coul</sup></em> is the Coulomb interactions,
<em>E<sup>polar</sup></em> is the polarization term for organic systems
(style <em>comb3</em> only),
<em>E<sup>vdW</sup></em> is the van der Waals energy (style <em>comb3</em> only),
<em>E<sup>barr</sup></em> is a charge barrier function, and
<em>E<sup>corr</sup></em> are angular correction terms.</p>
<p>The COMB potentials (styles <em>comb</em> and <em>comb3</em>) are variable charge
potentials. The equilibrium charge on each atom is calculated by the
electronegativity equalization (QEq) method. See <a class="reference internal" href="pair_smtbq.html#rick"><span class="std std-ref">Rick</span></a> for
further details. This is implemented by the <a class="reference internal" href="fix_qeq_comb.html"><span class="doc">fix qeq/comb</span></a> command, which should normally be
specified in the input script when running a model with the COMB
potential. The <a class="reference internal" href="fix_qeq_comb.html"><span class="doc">fix qeq/comb</span></a> command has options
that determine how often charge equilibration is performed, its
convergence criterion, and which atoms are included in the
calculation.</p>
<p>Only a single pair_coeff command is used with the <em>comb</em> and <em>comb3</em>
styles which specifies the COMB potential file with parameters for all
needed elements. These are mapped to LAMMPS atom types by specifying
N additional arguments after the potential file in the pair_coeff
command, where N is the number of LAMMPS atom types.</p>
<p>For example, if your LAMMPS simulation of a Si/SiO<sub>2</sub>/
HfO<sub>2</sub> interface has 4 atom types, and you want the 1st and
last to be Si, the 2nd to be Hf, and the 3rd to be O, and you would
<p>For style <em>comb3</em>, in addition to ffield.comb3, a special parameter
file, <em>lib.comb3</em>, that is exclusively used for C/O/H systems, will be
automatically loaded if carbon atom is detected in LAMMPS input
structure. This file must be in your working directory or in the
directory pointed to by the environment variable LAMMPS_POTENTIALS, as
described on the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command doc page.</p>
<p>Keyword <em>polar</em> indicates whether the force field includes
the atomic polarization. Since the equilibration of the polarization
has not yet been implemented, it can only set polar_off at present.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">You can not use potential file <em>ffield.comb</em> with style <em>comb3</em>,
nor file <em>ffield.comb3</em> with style <em>comb</em>.</p>
</div>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.</p>
<p>These pair styles does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>These pair styles do not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style, pair_coeff, and <a class="reference internal" href="fix_qeq_comb.html"><span class="doc">fix qeq/comb</span></a> commands in an input script that reads a
restart file.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where <em>alpha</em> is the damping parameter, and erc() and erfc() are
error-fuction and complementary error-function terms. This potential
is essentially a short-range, spherically-truncated,
charge-neutralized, shifted, pairwise <em>1/r</em> summation. With a
manipulation of adding and substracting a self term (for i = j) to the
first and second term on the right-hand-side, respectively, and a
small enough <em>alpha</em> damping parameter, the second term shrinks and
the potential becomes a rapidly-converging real-space summation. With
a long enough cutoff and small enough alpha parameter, the energy and
forces calcluated by the Wolf summation method approach those of the
Ewald sum. So it is a means of getting effective long-range
interactions with a short-range potential.</p>
<hr class="docutils" />
<p>Style <em>coul/streitz</em> is the Coulomb pair interaction defined as part
of the Streitz-Mintmire potential, as described in <a class="reference internal" href="#streitz"><span class="std std-ref">this paper</span></a>, in which charge distribution about an atom is modeled
as a Slater 1<em>s</em> orbital. More details can be found in the referenced
paper. To fully reproduce the published Streitz-Mintmire potential,
which is a variable charge potential, style <em>coul/streitz</em> must be
used with <a class="reference internal" href="pair_eam.html"><span class="doc">pair_style eam/alloy</span></a> (or some other
short-range potential that has been parameterized appropriately) via
the <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid/overlay</span></a> command. Likewise,
charge equilibration must be performed via the <a class="reference internal" href="fix_qeq.html"><span class="doc">fix qeq/slater</span></a> command. For example:</p>
<p>Keyword <em>ewald</em> does not need a damping parameter, but a
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> must be defined, which can be style
<em>ewald</em> or <em>pppm</em>. The Ewald method was used in Streitz and
Mintmire’s original paper, but a Wolf summation offers a speed-up in
some cases.</p>
<p>For the fix qeq/slater command, the <em>qfile</em> can be a filename that
contains QEq parameters as discussed on the <a class="reference internal" href="fix_qeq.html"><span class="doc">fix qeq</span></a>
command doc page. Alternatively <em>qfile</em> can be replaced by
“coul/streitz”, in which case the fix will extract QEq parameters from
the coul/streitz pair style itself.</p>
<p>See the examples/strietz directory for an example input script that
uses the Streitz-Mintmire potential. The potentials directory has the
AlO.eam.alloy and AlO.streitz potential files used by the example.</p>
<p>Note that the Streiz-Mintmire potential is generally used for oxides,
but there is no conceptual problem with extending it to nitrides and
carbides (such as SiC, TiN). Pair coul/strietz used by itself or with
any other pair style such as EAM, MEAM, Tersoff, or LJ in
hybrid/overlay mode. To do this, you would need to provide a
Streitz-Mintmire parameterizaion for the material being modeled.</p>
<hr class="docutils" />
<p>Styles <em>coul/long</em> and <em>coul/msm</em> compute the same Coulombic
interactions as style <em>coul/cut</em> except that an additional damping
factor is applied so it can be used in conjunction with the
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command and its <em>ewald</em> or <em>pppm</em>
option. The Coulombic cutoff specified for this style means that
pairwise interactions within this distance are computed directly;
interactions outside that distance are computed in reciprocal space.</p>
<p>Style <em>coul/long/cs</em> is identical to <em>coul/long</em> except that a term is
added for the <a class="reference internal" href="Section_howto.html#howto-25"><span class="std std-ref">core/shell model</span></a> to allow
charges on core and shell particles to be separated by r = 0.0.</p>
<p>Styles <em>tip4p/cut</em> and <em>tip4p/long</em> implement the coulomb part of
the TIP4P water model of <a class="reference internal" href="pair_lj.html#jorgensen"><span class="std std-ref">(Jorgensen)</span></a>, which introduces
a massless site located a short distance away from the oxygen atom
along the bisector of the HOH angle. The atomic types of the oxygen and
hydrogen atoms, the bond and angle types for OH and HOH interactions,
and the distance to the massless charge site are specified as
pair_style arguments. Style <em>tip4p/cut</em> uses a global cutoff for
Coulomb interactions; style <em>tip4p/long</em> is for use with a long-range
Coulombic solver (Ewald or PPPM).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For each TIP4P water molecule in your system, the atom IDs for
the O and 2 H atoms must be consecutive, with the O atom first. This
is to enable LAMMPS to “find” the 2 H atoms associated with each O
atom. For example, if the atom ID of an O atom in a TIP4P water
molecule is 500, then its 2 H atoms must have IDs 501 and 502.</p>
</div>
<p>See the <a class="reference internal" href="Section_howto.html#howto-8"><span class="std std-ref">howto section</span></a> for more
information on how to use the TIP4P pair styles and lists of
parameters to set. Note that the neighobr list cutoff for Coulomb
interactions is effectively extended by a distance 2*qdist when using
the TIP4P pair style, to account for the offset distance of the
fictitious charges on O atoms in water molecules. Thus it is
typically best in an efficiency sense to use a LJ cutoff >= Coulomb
cutoff + 2*qdist, to shrink the size of the neighbor list. This leads
to slightly larger cost for the long-range calculation, so you can
test the trade-off for your model.</p>
<hr class="docutils" />
<p>Note that these potentials are designed to be combined with other pair
potentials via the <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid/overlay</span></a>
command. This is because they have no repulsive core. Hence if they
are used by themselves, there will be no repulsion to keep two
oppositely charged particles from moving arbitrarily close to each
other.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<p>For <em>coul/cut</em> and <em>coul/debye</em>, the cutoff coefficient is optional.
If it is not used (as in some of the examples above), the default
global value specified in the pair_style command is used.</p>
<p>For <em>coul/long</em> and <em>coul/msm</em> no cutoff can be specified for an
individual I,J type pair via the pair_coeff command. All type pairs
use the same global Coulombic cutoff specified in the pair_style
command.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the cutoff distance for the
<em>coul/cut</em> style can be mixed. The default mix value is <em>geometric</em>.
See the “pair_modify” command for details.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option is not relevant
for these pair styles.</p>
<p>The <em>coul/long</em> style supports the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
table option for tabulation of the short-range portion of the
long-range Coulombic interaction.</p>
<p>These pair styles do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>These pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>The <em>coul/long</em>, <em>coul/msm</em> and <em>tip4p/long</em> styles are part of the
KSPACE package. The <em>coul/long/cs</em> style is part of the CORESHELL
package. They are only enabled if LAMMPS was built with that package
(which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where 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> 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 dipole</span></a> command should be used since it defines the
point dipoles and their rotational state. The magnitude of the dipole
moment for each type of particle can be defined by the
<span class="xref doc">dipole</span> command or in the “Dipoles” 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. Their initial
orientation can be defined by the <a class="reference internal" href="set.html"><span class="doc">set dipole</span></a> command or in
the “Atoms” section of the data file.</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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distances for this pair style can be mixed. The default
mix value is <em>geometric</em>. See the “pair_modify” command for details.</p>
<p>For atom type pairs I,J and I != J, the A, sigma, d1, and d2
coefficients and cutoff distance for this pair style can be mixed. A
is an energy value mixed like a LJ epsilon. D1 and d2 are distance
values and are mixed like sigma. The default mix value is
<em>geometric</em>. See the “pair_modify” command for details.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the Lennard-Jones portion of the pair
interaction; such energy goes to zero at the cutoff by construction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>The <em>lj/cut/dipole/cut</em>, <em>lj/cut/dipole/long</em>, and
<em>lj/long/dipole/long</em> styles are part of the DIPOLE package. They are
only enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The <em>lj/sf/dipole/sf</em> style is part of the USER-MISC package. It is
only enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Using dipole pair styles with <em>electron</em> <a class="reference internal" href="units.html"><span class="doc">units</span></a> is not
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Style <em>dpd</em> computes a force field for dissipative particle dynamics
(DPD) following the exposition in <a class="reference internal" href="#groot"><span class="std std-ref">(Groot)</span></a>.</p>
<p>Style <em>dpd/tstat</em> invokes a DPD thermostat on pairwise interactions,
which is equivalent to the non-conservative portion of the DPD force
field. This pair-wise thermostat can be used in conjunction with any
<a class="reference internal" href="pair_style.html"><span class="doc">pair style</span></a>, and in leiu of per-particle thermostats
like <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> or ensemble thermostats like
Nose Hoover as implemented by <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt</span></a>. To use
<em>dpd/tstat</em> as a thermostat for another pair style, use the <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid/overlay</span></a> command to compute both the desired
pair interaction and the thermostat for each pair of particles.</p>
<p>For style <em>dpd</em>, the force on atom I due to atom J is given as a sum
<p>The last coefficient is optional. If not specified, the global DPD
cutoff is used. Note that sigma is set equal to sqrt(2 T gamma),
where T is the temperature set by the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a>
command so it does not need to be specified.</p>
<p>For style <em>dpd/tstat</em>, the coefficiencts defined for each pair of
atoms types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command is the same,
except that A is not included.</p>
<p>The GPU-accelerated versions of these styles are implemented based on
the work of <a class="reference internal" href="#afshar"><span class="std std-ref">(Afshar)</span></a> and <a class="reference internal" href="#phillips"><span class="std std-ref">(Phillips)</span></a>.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you are modeling DPD polymer chains, you may want to use the
<a class="reference internal" href="pair_srp.html"><span class="doc">pair_style srp</span></a> command in conjuction with these pair
styles. It is a soft segmental repulsive potential (SRP) that can
prevent DPD polymer chains from crossing each other.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The virial calculation for pressure when using this pair style
includes all the components of force listed above, including the
random force.</p>
</div>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>These pair styles do not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>These pair styles do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the pair interaction. Note that as
discussed above, the energy due to the conservative Fc term is already
shifted to be 0.0 at the cutoff distance Rc.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for these pair styles.</p>
<p>These pair style do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>These pair styles writes their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file. Note
that the user-specified random number seed is stored in the restart
file, so when a simulation is restarted, each processor will
re-initialize its random number generator the same way it did
initially. This means the random forces will be random, but will not
be the same as they would have been if the original simulation had
continued past the restart time.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
<p>The <em>dpd/tstat</em> style can ramp its target temperature over multiple
runs, using the <em>start</em> and <em>stop</em> keywords of the <a class="reference internal" href="run.html"><span class="doc">run</span></a>
command. See the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command for details of how to do
this.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The default frequency for rebuilding neighbor lists is every 10 steps
(see the <a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify</span></a> command). This may be too
infrequent for style <em>dpd</em> simulations since particles move rapidly
and can overlap by large amounts. If this setting yields a non-zero
number of “dangerous” reneighborings (printed at the end of a
simulation), you should experiment with forcing reneighboring more
often and see if system energies/trajectories change.</p>
<p>These pair styles requires you to use the <a class="reference internal" href="comm_modify.html"><span class="doc">comm_modify vel yes</span></a> command so that velocites are stored by ghost
atoms.</p>
<p>These pair styles will not restart exactly when using the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command, though they should provide
statistically similar results. This is because the forces they
compute depend on atom velocities. See the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for more details.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accerlate</span></a> of the manual for more
instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above with the individual styles. You never need to specify
a pair_coeff command with I != J arguments for the eam styles.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>The eam pair styles do not write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in tabulated potential files.
Thus, you need to re-specify the pair_style and pair_coeff commands in
an input script that reads a restart file.</p>
<p>The eam pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
<p>All of these styles except the <em>eam/cd</em> style are part of the MANYBODY
package. They are only enabled if LAMMPS was built with that package
(which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The <em>eam/cd</em> style is part of the USER-MISC package and also requires
the MANYBODY package. It is only enabled if LAMMPS was built with
those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
specify EDIP parameters for all permutations of the two elements
interacting in three-body configurations. Thus for 3 elements, 27
entries would be required, etc.</p>
<p>At the moment, only a single element parametrization is
implemented. However, the author is not aware of other
multi-element EDIP parametrizations. If you know any and
you are interest in that, please contact the author of
the EDIP package.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The lines in the file can be in any order; LAMMPS extracts the info it
needs.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This style is part of the MANYBODY package. It is only enabled if
LAMMPS was built with that package (which it is by default).</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The global cutoff (r_c) specified in the pair_style command is used.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the “-suffix command-line
switch7_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the Gauss-potential portion of the pair
interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table and tail options are not
relevant for these pair styles.</p>
<p>These pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
<p>The <em>gauss</em> pair style tallies an “occupancy” count of how many Gaussian-well
sites have an atom within the distance at which the force is a maximum
= sqrt(0.5/b). This quantity can be accessed via the <a class="reference internal" href="compute_pair.html"><span class="doc">compute pair</span></a> command as a vector of values of length 1.</p>
<p>To print this quantity to the log file (with a descriptive column
heading) the following commands could be included in an input script:</p>
<p>The <em>gauss/cut</em> style is part of the “user-misc” package. It is only
enabled if LAMMPS is build with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making of LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The variable names utilized as potential parameters are for the most
part taken from <a class="reference internal" href="pair_resquared.html#everaers"><span class="std std-ref">(Everaers)</span></a> in order to be consistent with
the <a class="reference internal" href="pair_resquared.html"><span class="doc">RE-squared pair potential</span></a>. Details on the
<p>More details of the Gay-Berne formulation are given in the references
listed below and in <a class="reference external" href="PDF/pair_gayberne_extra.pdf">this supplementary document</a>.</p>
<p>Use of this pair style requires the NVE, NVT, or NPT fixes with the
<em>asphere</em> extension (e.g. <a class="reference internal" href="fix_nve_asphere.html"><span class="doc">fix nve/asphere</span></a>) in
order to integrate particle rotation. Additionally, <a class="reference internal" href="atom_style.html"><span class="doc">atom_style ellipsoid</span></a> should be used since it defines the
rotational state and the size and shape of each ellipsoidal particle.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<li>epsilon_i_a = relative well depth of type I for side-to-side interactions</li>
<li>epsilon_i_b = relative well depth of type I for face-to-face interactions</li>
<li>epsilon_i_c = relative well depth of type I for end-to-end interactions</li>
<li>epsilon_j_a = relative well depth of type J for side-to-side interactions</li>
<li>epsilon_j_b = relative well depth of type J for face-to-face interactions</li>
<li>epsilon_j_c = relative well depth of type J for end-to-end interactions</li>
<li>cutoff (distance units)</li>
</ul>
<p>The last coefficient is optional. If not specified, the global
cutoff specified in the pair_style command is used.</p>
<p>It is typical with the Gay-Berne potential to define <em>sigma</em> as the
minimum of the 3 shape diameters of the particles involved in an I,I
interaction, though this is not required. Note that this is a
different meaning for <em>sigma</em> than the <a class="reference internal" href="pair_resquared.html"><span class="doc">pair_style resquared</span></a> potential uses.</p>
<p>The epsilon_i and epsilon_j coefficients are actually defined for atom
types, not for pairs of atom types. Thus, in a series of pair_coeff
commands, they only need to be specified once for each atom type.</p>
<p>Specifically, if any of epsilon_i_a, epsilon_i_b, epsilon_i_c are
non-zero, the three values are assigned to atom type I. If all the
epsilon_i values are zero, they are ignored. If any of epsilon_j_a,
epsilon_j_b, epsilon_j_c are non-zero, the three values are assigned
to atom type J. If all three epsilon_j values are zero, they are
ignored. Thus the typical way to define the epsilon_i and epsilon_j
coefficients is to list their values in “pair_coeff I J” commands when
I = J, but set them to 0.0 when I != J. If you do list them when I !=
J, you should insure they are consistent with their values in other
pair_coeff commands, since only the last setting will be in effect.</p>
<p>Note that if this potential is being used as a sub-style of
<a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid</span></a>, and there is no “pair_coeff I I”
setting made for Gay-Berne for a particular type I (because I-I
interactions are computed by another hybrid pair potential), then you
still need to insure the epsilon a,b,c coefficients are assigned to
that type. e.g. in a “pair_coeff I J” command.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If the epsilon a = b = c for an atom type, and if the shape of
the particle itself is spherical, meaning its 3 shape parameters are
all the same, then the particle is treated as an LJ sphere by the
Gay-Berne potential. This is significant because if two LJ spheres
interact, then the simple Lennard-Jones formula is used to compute
their interaction energy/force using the specified epsilon and sigma
as the standard LJ parameters. This is much cheaper to compute than
the full Gay-Berne formula. To treat the particle as a LJ sphere with
sigma = D, you should normally set epsilon a = b = c = 1.0, set the
pair_coeff sigma = D, and also set the 3 shape parameters for the
particle to D. The one exception is that if the 3 shape parameters
are set to 0.0, which is a valid way in LAMMPS to specify a point
particle, then the Gay-Berne potential will treat that as shape
parameters of 1.0 (i.e. a LJ particle with sigma = 1), since it
requires finite-size particles. In this case you should still set the
pair_coeff sigma to 1.0 as well.</p>
</div>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the Lennard-Jones portion of the pair
interaction, but only for sphere-sphere interactions. There is no
shifting performed for ellipsoidal interactions due to the anisotropic
dependence of the interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>The <em>gayberne</em> style is part of the ASPHERE package. It is only
enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>These pair style require that atoms store torque and a quaternion to
represent their orientation, as defined by the
<a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a>. It also require they store a per-type
<span class="xref doc">shape</span>. The particles cannot store a per-particle
diameter.</p>
<p>This pair style requires that atoms be ellipsoids as defined by the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>should be used if all atoms in the simulation interact via a granular
potential (i.e. one of the pair styles above is used). If a granular
potential is used as a sub-style of <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid</span></a>, then specific atom types can be used in the
pair_coeff command to determine which atoms interact via a granular
potential.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>These pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so a pair_style command does not need to be
specified in an input script that reads a restart file.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
<p>The single() function of these pair styles returns 0.0 for the energy
of a pairwise interaction, since energy is not conserved in these
dissipative potentials. It also returns only the normal component of
the pairwise interaction force. However, the single() function also
calculates 4 extra pairwise quantities. The first 3 are the
components of the tangential force between particles I and J, acting
on particle I. <em>P4</em> is the magnitude of this tangential force. 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>p3</em>,
<em>p4</em>.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<blockquote>
<div>none</div></blockquote>
<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 <em>intel</em>, <em>kk</em>, with a <em>cuda</em>, <em>gpu</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
corrections to energy and pressure, since there are no corrections for
a potential that goes to 0.0 at the cutoff.</p>
<p>All of the GROMACS pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.</p>
<p>All of the GROMACS pair styles can only be used via the <em>pair</em>
keyword of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not
support the <em>inner</em>, <em>middle</em>, <em>outer</em> keywords.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>These 3-body interactions can be defined for pairs of acceptor and
donor atoms, based on atom types. For each donor/acceptor atom pair,
the 3rd atom in the interaction is a hydrogen permanently bonded to
the donor atom, e.g. in a bond list read in from a data file via the
<a class="reference internal" href="read_data.html"><span class="doc">read_data</span></a> command. The atom types of possible
hydrogen atoms for each donor/acceptor type pair are specified by the
<a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command (see below).</p>
<p>Style <em>hbond/dreiding/lj</em> is the original DREIDING potential of
<a class="reference internal" href="#pair-mayo"><span class="std std-ref">(Mayo)</span></a>. It uses a LJ 12/10 functional for the Donor-Acceptor
interactions. To match the results in the original paper, use n = 4.</p>
<p>Style <em>hbond/dreiding/morse</em> is an improved version using a Morse
potential for the Donor-Acceptor interactions. <a class="reference internal" href="#liu"><span class="std std-ref">(Liu)</span></a> showed
that the Morse form gives improved results for Dendrimer simulations,
when n = 2.</p>
<p>See this <a class="reference internal" href="Section_howto.html#howto-4"><span class="std std-ref">howto section</span></a> of the manual for
more information on the DREIDING forcefield.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Because the Dreiding hydrogen bond potential is only one portion
of an overall force field which typically includes other pairwise
interactions, it is common to use it as a sub-style in a <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid/overlay</span></a> command, where another pair style
provides the repulsive core interaction between pairs of atoms, e.g. a
1/r^12 Lennard-Jones repulsion.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When using the hbond/dreiding pair styles with <a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid/overlay</span></a>, you should explicitly define pair
interactions between the donor atom and acceptor atoms, (as well as
between these atoms and ALL other atoms in your system). Whenever
<a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid/overlay</span></a> is used, ordinary mixing
rules are not applied to atoms like the donor and acceptor atoms
because they are typically referenced in multiple pair styles.
Neglecting to do this can cause difficult-to-detect physics problems.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">In the original Dreiding force field paper 1-4 non-bonded
interactions ARE allowed. If this is desired for your model, use the
special_bonds command (e.g. “special_bonds lj 0.0 0.0 1.0”) to turn
these interactions on.</p>
</div>
<hr class="docutils" />
<p>The following coefficients must be defined for pairs of eligible
donor/acceptor types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as
in the examples above.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Unlike other pair styles and their associated
<a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> commands, you do not need to specify
pair_coeff settings for all possible I,J type pairs. Only I,J type
pairs for atoms which act as joint donors/acceptors need to be
specified; all other type pairs are assumed to be inactive.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">A <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command can be speficied multiple
times for the same donor/acceptor type pair. This enables multiple
hydrogen types to be assigned to the same donor/acceptor type pair.
For other pair_styles, if the pair_coeff command is re-used for the
same I.J type pair, the settings for that type pair are overwritten.
For the hydrogen bond potentials this is not the case; the settings
are cummulative. This means the only way to turn off a previous
setting, is to re-use the pair_style command and start over.</p>
</div>
<p>For the <em>hbond/dreiding/lj</em> style the list of coefficients is as
follows:</p>
<ul class="simple">
<li>K = hydrogen atom type = 1 to Ntypes</li>
<li>donor flag = <em>i</em> or <em>j</em></li>
<li>epsilon (energy units)</li>
<li>sigma (distance units)</li>
<li>n = exponent in formula above</li>
<li>distance cutoff Rin (distance units)</li>
<li>distance cutoff Rout (distance units)</li>
<li>angle cutoff (degrees)</li>
</ul>
<p>For the <em>hbond/dreiding/morse</em> style the list of coefficients is as
follows:</p>
<ul class="simple">
<li>K = hydrogen atom type = 1 to Ntypes</li>
<li>donor flag = <em>i</em> or <em>j</em></li>
<li>D0 (energy units)</li>
<li>alpha (1/distance units)</li>
<li>r0 (distance units)</li>
<li>n = exponent in formula above</li>
<li>distance cutoff Rin (distance units)</li>
<li>distance cutoff Rout (distance units)</li>
<li>angle cutoff (degrees)</li>
</ul>
<p>A single hydrogen atom type K can be specified, or a wild-card
asterisk can be used in place of or in conjunction with the K
arguments to select multiple types as hydrogens. This takes the form
“*” or “<em>n” or “n</em>” or “m*n”. See the <a class="reference external" href="pair_coeff">pair_coeff</a> command
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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>These pair styles do not support mixing. You must explicitly identify
each donor/acceptor type pair.</p>
<p>These styles do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift
option for the energy of the interactions.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant for
these pair styles.</p>
<p>These pair styles do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>These pair styles do not write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands need to be
re-specified in an input script that reads a restart file.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>If an assignment to <em>none</em> is made in a simulation with the
<em>hybrid/overlay</em> pair style, it wipes out all previous assignments of
that atom type pair to sub-styles.</p>
<p>Note that you may need to use an <a class="reference internal" href="atom_style.html"><span class="doc">atom_style</span></a> hybrid
command in your input script, if atoms in the simulation will need
attributes from several atom styles, due to using multiple pair
potentials.</p>
<hr class="docutils" />
<p>Different force fields (e.g. CHARMM vs AMBER) may have different rules
for applying weightings that change the strength of pairwise
interactions bewteen pairs of atoms that are also 1-2, 1-3, and 1-4
neighbors in the molecular bond topology, as normally set by the
<a class="reference internal" href="special_bonds.html"><span class="doc">special_bonds</span></a> command. Different weights can be
assigned to different pair hybrid sub-styles via the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify special</span></a> command. This allows multiple force fields
to be used in a model of a hybrid system, however, there is no consistent
approach to determine parameters automatically for the interactions
between the two force fields, this is only recommended when particles
described by the different force fields do not mix.</p>
<p>Here is an example for mixing CHARMM and AMBER: The global <em>amber</em>
setting sets the 1-4 interactions to non-zero scaling factors and
<p>See the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> doc page for details on
the specific syntax, requirements and restrictions.</p>
<hr class="docutils" />
<p>The potential energy contribution to the overall system due to an
individual sub-style can be accessed and output via the <a class="reference internal" href="compute_pair.html"><span class="doc">compute pair</span></a> command.</p>
<hr class="docutils" />
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Several of the potentials defined via the pair_style command in
LAMMPS are really many-body potentials, such as Tersoff, AIREBO, MEAM,
ReaxFF, etc. The way to think about using these potentials in a
hybrid setting is as follows.</p>
</div>
<p>A subset of atom types is assigned to the many-body potential with a
single <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command, using “* <a href="#id1"><span class="problematic" id="id2">*</span></a>” to include
all types and the NULL keywords described above to exclude specific
types not assigned to that potential. If types 1,3,4 were assigned in
that way (but not type 2), this means that all many-body interactions
between all atoms of types 1,3,4 will be computed by that potential.
Pair_style hybrid allows interactions between type pairs 2-2, 1-2,
2-3, 2-4 to be specified for computation by other pair styles. You
could even add a second interaction for 1-1 to be computed by another
pair style, assuming pair_style hybrid/overlay is used.</p>
<p>But you should not, as a general rule, attempt to exclude the
many-body interactions for some subset of the type pairs within the
set of 1,3,4 interactions, e.g. exclude 1-1 or 1-3 interactions. That
is not conceptually well-defined for many-body interactions, since the
potential will typically calculate energies and foces for small groups
of atoms, e.g. 3 or 4 atoms, using the neighbor lists of the atoms to
find the additional atoms in the group. It is typically non-physical
to think of excluding an interaction between a particular pair of
atoms when the potential computes 3-body or 4-body interactions.</p>
<p>However, you can still use the pair_coeff none setting or the
<a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify exclude</span></a> command to exclude certain
type pairs from the neighbor list that will be passed to a manybody
sub-style. This will alter the calculations made by a many-body
potential, since it builds its list of 3-body, 4-body, etc
interactions from the pair list. You will need to think carefully as
to whether it produces a physically meaningful result for your model.</p>
<p>For example, imagine you have two atom types in your model, type 1 for
atoms in one surface, and type 2 for atoms in the other, and you wish
to use a Tersoff potential to compute interactions within each
surface, but not between surfaces. Then either of these two command
<p>Note that to prevent the Tersoff potential from computing C/C
interactions, you would need to modify the SiC.tersoff file to turn
off C/C interaction, i.e. by setting the appropriate coefficients to
0.0.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual.</p>
-<p>Since the <em>hybrid</em> and <em>hybrid/overlay</em> styles delegate computation
-to the individual sub-styles, the suffix versions of the <em>hybrid</em>
-and <em>hybrid/overlay</em> styles are used to propagate the corresponding
-suffix to all sub-styles, if those versions exist. Otherwise the
+<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 USER-CUDA, GPU,
+<p>The individual accelerated sub-styles are part of the GPU,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the
<a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
shift, table, and tail options for an I,J pair interaction, if the
associated sub-style supports it.</p>
<p>For the hybrid pair styles, the list of sub-styles and their
respective settings are written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so a <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> command does
not need to specified in an input script that reads a restart file.
However, the coefficient information is not stored in the restart
file. Thus, pair_coeff commands need to be re-specified in the
restart input script.</p>
<p>These pair styles support the use of the <em>inner</em>, <em>middle</em>, and
<em>outer</em> keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command, if
their sub-styles do.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>When using a long-range Coulombic solver (via the
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command) with a hybrid pair_style,
one or more sub-styles will be of the “long” variety,
e.g. <em>lj/cut/coul/long</em> or <em>buck/coul/long</em>. You must insure that the
short-range Coulombic cutoff used by each of these long pair styles is
the same or else LAMMPS will generate an error.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/cut pair styles can be mixed.
The default mix value is <em>geometric</em>. See the “pair_modify” command
for details.</p>
<p>All of the <em>lj/cut</em> pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option for the energy of the
Lennard-Jones portion of the pair interaction.</p>
<p>The <em>lj/cut/coul/long</em> and <em>lj/cut/tip4p/long</em> pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option since they can tabulate
the short-range portion of the long-range Coulombic interaction.</p>
<p>All of the <em>lj/cut</em> pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> tail option for adding a long-range
tail correction to the energy and pressure for the Lennard-Jones
portion of the pair interaction.</p>
<p>All of the <em>lj/cut</em> pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.</p>
<p>The <em>lj/cut</em> and <em>lj/cut/coul/long</em> pair styles support the use of the
<em>inner</em>, <em>middle</em>, and <em>outer</em> keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command, meaning the pairwise forces can be
partitioned by distance at different levels of the rRESPA hierarchy.
The other styles only support the <em>pair</em> keyword of run_style respa.
See the <a class="reference internal" href="run_style.html"><span class="doc">run_style</span></a> command for details.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>The <em>lj/cut/coul/long</em> and <em>lj/cut/tip4p/long</em> styles are part of the
KSPACE package. The <em>lj/cut/tip4p/cut</em> style is part of the MOLECULE
package. These styles are only enabled if LAMMPS was built with those
packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section
for more info. Note that the KSPACE and MOLECULE packages are
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The last coefficient is optional. If not specified, the global LJ
cutoff specified in the pair_style command is used.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for adding a long-range tail correction to the energy and
pressure of the pair interaction.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style supports the use of the <em>inner</em>, <em>middle</em>, and <em>outer</em>
keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command, meaning the
pairwise forces can be partitioned by distance at different levels of
the rRESPA hierarchy. See the <a class="reference internal" href="run_style.html"><span class="doc">run_style</span></a> command for
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum, which is
located at rmin = 2^(1/6)*sigma. In the above example, sigma =
0.8908987, so rmin = 1.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
corrections to energy and pressure, since there are no corrections for
a potential that goes to 0.0 at the cutoff.</p>
<p>The lj/cubic pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.</p>
<p>The lj/cubic pair style can only be used via the <em>pair</em>
keyword of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not
support the <em>inner</em>, <em>middle</em>, <em>outer</em> keywords.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The delta values can be positive or negative. The last coefficient is
optional. If not specified, the global LJ cutoff is used.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for adding a long-range tail correction to the energy and
pressure of the pair interaction.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where C is an energy-conversion constant, Qi and Qj are the charges on
the 2 atoms, epsilon is the dielectric constant which can be set by
the <a class="reference internal" href="dielectric.html"><span class="doc">dielectric</span></a> command, and Rc is the cutoff. If
one cutoff is specified in the pair_style command, it is used for both
the LJ and Coulombic terms. If two cutoffs are specified, they are
used as cutoffs for the LJ and Coulombic terms respectively.</p>
<p>The purpose of this pair style is to capture long-range interactions
resulting from both attractive 1/r^6 Lennard-Jones and Coulombic 1/r
interactions. This is done by use of the <em>flag_lj</em> and <em>flag_coul</em>
settings. The <a class="reference internal" href="#veld"><span class="std std-ref">In ‘t Veld</span></a> paper has more details on when it is
appropriate to include long-range 1/r^6 interactions, using this
potential.</p>
<p>Style <em>lj/long/tip4p/long</em> implements the TIP4P water model of
<a class="reference internal" href="pair_lj.html#jorgensen"><span class="std std-ref">(Jorgensen)</span></a>, which introduces a massless site located a
short distance away from the oxygen atom along the bisector of the HOH
angle. The atomic types of the oxygen and hydrogen atoms, the bond
and angle types for OH and HOH interactions, and the distance to the
massless charge site are specified as pair_style arguments.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For each TIP4P water molecule in your system, the atom IDs for
the O and 2 H atoms must be consecutive, with the O atom first. This
is to enable LAMMPS to “find” the 2 H atoms associated with each O
atom. For example, if the atom ID of an O atom in a TIP4P water
molecule is 500, then its 2 H atoms must have IDs 501 and 502.</p>
</div>
<p>See the <a class="reference internal" href="Section_howto.html#howto-8"><span class="std std-ref">howto section</span></a> for more
information on how to use the TIP4P pair style. Note that the
neighobr list cutoff for Coulomb interactions is effectively extended
by a distance 2*qdist when using the TIP4P pair style, to account for
the offset distance of the fictitious charges on O atoms in water
molecules. Thus it is typically best in an efficiency sense to use a
LJ cutoff >= Coulomb cutoff + 2*qdist, to shrink the size of the
neighbor list. This leads to slightly larger cost for the long-range
calculation, so you can test the trade-off for your model.</p>
<p>If <em>flag_lj</em> is set to <em>long</em>, no cutoff is used on the LJ 1/r^6
dispersion term. The long-range portion can be calculated by using
the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style ewald/disp or pppm/disp</span></a> commands.
The specified LJ cutoff then determines which portion of the LJ
interactions are computed directly by the pair potential versus which
part is computed in reciprocal space via the Kspace style. If
<em>flag_lj</em> is set to <em>cut</em>, the LJ interactions are simply cutoff, as
with <a class="reference internal" href="pair_lj.html"><span class="doc">pair_style lj/cut</span></a>.</p>
<p>If <em>flag_coul</em> is set to <em>long</em>, no cutoff is used on the Coulombic
interactions. The long-range portion can calculated by using any of
several <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command options such as
<em>pppm</em> or <em>ewald</em>. Note that if <em>flag_lj</em> is also set to long, then
the <em>ewald/disp</em> or <em>pppm/disp</em> Kspace style needs to be used to
perform the long-range calculations for both the LJ and Coulombic
interactions. If <em>flag_coul</em> is set to <em>off</em>, Coulombic interactions
are not computed.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above, or in the data file or restart files read by the
<p>Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum at 2^(1/6)
sigma.</p>
<p>The latter 2 coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair.</p>
<p>Note that if you are using <em>flag_lj</em> set to <em>long</em>, you
cannot specify a LJ cutoff for an atom type pair, since only one
global LJ cutoff is allowed. Similarly, if you are using <em>flag_coul</em>
set to <em>long</em>, you cannot specify a Coulombic cutoff for an atom type
pair, since only one global Coulombic cutoff is allowed.</p>
<p>For <em>lj/long/tip4p/long</em> only the LJ cutoff can be specified
since a Coulombic cutoff cannot be specified for an individual I,J
type pair. All type pairs use the same global Coulombic cutoff
specified in the pair_style command.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/long pair styles can be mixed.
The default mix value is <em>geometric</em>. See the “pair_modify” command
for details.</p>
<p>These pair styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift
option for the energy of the Lennard-Jones portion of the pair
interaction, assuming <em>flag_lj</em> is <em>cut</em>.</p>
<p>These pair styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table and
table/disp options since they can tabulate the short-range portion of
the long-range Coulombic and dispersion interactions.</p>
<p>Thes pair styles do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding a long-range tail correction to the
Lennard-Jones portion of the energy and pressure.</p>
<p>These pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>The pair lj/long/coul/long styles support the use of the <em>inner</em>,
<em>middle</em>, and <em>outer</em> keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a>
command, meaning the pairwise forces can be partitioned by distance at
different levels of the rRESPA hierarchy. See the
<a class="reference internal" href="run_style.html"><span class="doc">run_style</span></a> command for details.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>These styles are part of the KSPACE package. They are only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info. Note that
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The last coefficient is optional. If not specified, the global
LJ cutoff specified in the pair_style command is used.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma
coefficients and cutoff distance for this pair style can be mixed.
Rin is a cutoff value and is mixed like the cutoff. The
default mix value is <em>geometric</em>. See the “pair_modify” command for
details.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option is not relevant for
this pair style, since the pair interaction goes to 0.0 at the cutoff.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure, since the energy of the pair interaction is smoothed to 0.0
at the cutoff.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>This pair style is part of the USER-MISC package. It is only enabled
if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The last 2 coefficients are optional inner and outer cutoffs. If not
specified, the global values for Rin and Rc are used.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure, since the energy of the pair interaction is smoothed to 0.0
at the cutoff.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The last coefficient is optional. If not specified, the global value
for Rc is used.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance can be mixed. The default mix value is geometric.
See the “pair_modify” command for details.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant for
this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure, since the energy of the pair interaction is smoothed to 0.0
at the cutoff.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li>style = <em>lj/cut/soft</em> or <em>lj/cut/coul/cut/soft</em> or <em>lj/cut/coul/long/soft</em> or <em>lj/cut/tip4p/long/soft</em> or <em>lj/charmm/coul/long/soft</em> or <em>coul/cut/soft</em> or <em>coul/long/soft</em> or <em>tip4p/long/soft</em></li>
<li>args = list of arguments for a particular style</li>
</ul>
<pre class="literal-block">
<em>lj/cut/soft</em> args = n alpha_lj cutoff
n, alpha_LJ = parameters of soft-core potential
cutoff = global cutoff for Lennard-Jones interactions (distance units)
<em>lj/cut/coul/cut/soft</em> args = n alpha_LJ alpha_C cutoff (cutoff2)
n, alpha_LJ, alpha_C = parameters of soft-core potential
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
<em>lj/cut/coul/long/soft</em> args = n alpha_LJ alpha_C cutoff
n, alpha_LJ, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
<li>lambda (activation parameter between 0 and 1)</li>
<li>cutoff1 (distance units)</li>
<li>cutoff2 (distance units)</li>
</ul>
<p>The latter two coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair. You cannot specify 2 cutoffs for style <em>lj/cut/soft</em>,
since it has no Coulombic terms. For the <em>coul/cut/soft</em> and
<em>coul/long/soft</em> only lambda and the optional cutoff2 are to be
specified.</p>
<p>Style <em>lj/cut/tip4p/long/soft</em> implements a soft-core version of the
TIP4P water model. The usage of this pair style is documented in the
<a class="reference internal" href="pair_lj.html"><span class="doc">pair_lj</span></a> styles. The soft-core version introduces the
lambda parameter to the list of arguments, after epsilon and sigma in
the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command. The paratemers n, alpha_LJ
and alpha_C are set in the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> command,
before the cutoffs.</p>
<p>Style <em>lj/charmm/coul/long/soft</em> implements a soft-core version of the
CHARMM version of LJ interactions with an additional switching
function S(r) that ramps the energy and force smoothly to zero between
an inner and outer cutoff. The usage of this pair style is documented
in the <a class="reference internal" href="pair_charmm.html"><span class="doc">pair_charmm</span></a> styles. The soft-core version
introduces the lambda parameter to the list of arguments, after
epsilon and sigma in the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command (and
before the optional eps14 and sigma14). The paratemers n,
alpha_LJ and alpha_C are set in the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a>
command, before the cutoffs.</p>
<p>The <em>coul/cut/soft</em>, <em>coul/long/soft</em> and <em>tip4p/long/soft</em> substyles
are designed to be combined with other pair potentials via the
<a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_style hybrid/overlay</span></a> command. This is because
they have no repulsive core. Hence, if used by themselves, there will
be no repulsion to keep two oppositely charged particles from
overlapping each other. In this case, if lambda = 1, a singularity may
occur. These substyles are suitable to represent charges embedded in
the Lennard-Jones radius of another site (for example hydrogen atoms
in several water models).</p>
<p>NOTES: When using the core-softed Coulomb potentials with long-range
solvers (<em>coul/long/soft</em>, <em>lj/cut/coul/long/soft</em>, etc.) in a free
energy calculation in which sites holding electrostatic charges are
being created or anihilated (using <a class="reference internal" href="fix_adapt_fep.html"><span class="doc">fix adapt/fep</span></a>
and <a class="reference internal" href="compute_fep.html"><span class="doc">compute fep</span></a>) it is important to adapt both the
lambda activation parameter (from 0 to 1, or the reverse) and the
value of the charge (from 0 to its final value, or the reverse). This
ensures that long-range electrostatic terms (kspace) are correct. It
is not necessary to use core-softed Coulomb potentials if the van der
Waals site is present during the free-energy route, thus avoiding
overlap of the charges. Examples are provided in the LAMMPS source
directory tree, under examples/USER/fep.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for this pair style can be mixed.
The default mix value is <em>geometric</em>. See the “pair_modify” command
for details.</p>
<p>These pair styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift
option for the energy of the Lennard-Jones portion of the pair
interaction.</p>
<p>These pair styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> tail
option for adding a long-range tail correction to the energy and
pressure for the Lennard-Jones portion of the pair interaction.</p>
<p>These pair styles write information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>To avoid division by zero do not set sigma = 0; use the lambda
parameter instead to activate/deactivate interactions, or use
epsilon = 0 and sigma = 1. Alternatively, when sites do not
interact though the Lennard-Jones term the <em>coul/long/soft</em> or
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Styles <em>lubricate</em> and <em>lubricate/poly</em> compute hydrodynamic
interactions between mono-disperse finite-size spherical particles in
a pairwise fashion. The interactions have 2 components. The first is
Ball-Melrose lubrication terms via the formulas in <a class="reference internal" href="pair_lubricateU.html#ball"><span class="std std-ref">(Ball and Melrose)</span></a></p>
<p>where U represents the velocities and angular velocities of the
particles, U^<em>infty</em> represents the velocity and the angular velocity
of the undisturbed fluid, and E^<em>infty</em> represents the rate of strain
tensor of the undisturbed fluid with viscosity <em>mu</em>. Again, note that
this is dynamic viscosity which has units of mass/distance/time, not
kinematic viscosity. Volume fraction corrections to R_FU are included
as long as <em>flagVF</em> is set to 1 (default).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When using the FLD terms, these pair styles are designed to be
used with explicit time integration and a correspondingly small
timestep. Thus either <a class="reference internal" href="fix_nve_sphere.html"><span class="doc">fix nve/sphere</span></a> or <a class="reference internal" href="fix_nve_asphere.html"><span class="doc">fix nve/asphere</span></a> should be used for time integration.
To perform implicit FLD, see the <a class="reference internal" href="pair_lubricateU.html"><span class="doc">pair_style lubricateU</span></a> command.</p>
<p>The two coefficients are optional. If neither is specified, the two
cutoffs specified in the pair_style command are used. Otherwise both
must be specified.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">this section</span></a> of
the manual. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">this section</span></a> of the manual for more
instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the two cutoff distances for this
pair style can be mixed. The default mix value is <em>geometric</em>. See
the “pair_modify” command for details.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>These styles are part of the COLLOID package. They are only enabled
if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-2-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Only spherical monodisperse particles are allowed for pair_style
lubricate.</p>
<p>Only spherical particles are allowed for pair_style lubricate/poly.</p>
<p>These pair styles will not restart exactly when using the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command, though they should provide
statistically similar results. This is because the forces they
compute depend on atom velocities. See the
<a class="reference internal" href="read_restart.html"><span class="doc">read_restart</span></a> command for more details.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The <em>meam/spline</em> style computes pairwise interactions for metals
using a variant of modified embedded-atom method (MEAM) potentials
<a class="reference internal" href="pair_meam_sw_spline.html#lenosky"><span class="std std-ref">(Lenosky)</span></a>. The total energy E is given by</p>
<p>The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The three Ti arguments map LAMMPS atom types 1,2,3 to the Ti element
in the potential file. If a mapping value is specified as NULL, the
mapping is not performed. This can be used when a <em>meam/spline</em>
potential is used as part of the <em>hybrid</em> pair style. The NULL values
are placeholders for atom types that will be used with other
potentials.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The <em>meam/spline</em> style currently supports only single-element
MEAM potentials. It may be extended for alloy systems in the future.</p>
</div>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>The current version of this pair style does not support multiple
element types or mixing. It has been designed for pure elements only.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>The <em>meam/spline</em> pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in an external
potential parameter file. Thus, you need to re-specify the pair_style
and pair_coeff commands in an input script that reads a restart file.</p>
<p>The <em>meam/spline</em> pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The syntax of the pair_style and pair_coeff commands are the same for
the <em>morse</em> and <em>morse/smooth/linear</em> styles.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>None of these pair styles support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>All of these pair styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table options is not relevant for
the Morse pair styles.</p>
<p>None of these pair styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>All of these pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
<p>The <em>morse/smooth/linear</em> pair style is only enabled if LAMMPS was
built with the USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The first three Si arguments map LAMMPS atom types 1,2,3 to the Si
element in the potential file. The final C argument maps LAMMPS atom
type 4 to the C element in the potential file. If a mapping value is
specified as NULL, the mapping is not performed. This can be used
when the potential is used as part of the <em>hybrid</em> pair style. The
NULL values are placeholders for atom types that will be used with
other potentials. An example of a pair_coeff command for use with the
<em>hybrid</em> pair style is:</p>
<p>pair_coeff * * nb3b/harmonic MgOH.nb3b.harmonic Mg O H</p>
<p>Three-body nonbonded harmonic files in the <em>potentials</em> directory of
the LAMMPS distribution have a ”.nb3b.harmonic” suffix. Lines that
are not blank or comments (starting with #) define parameters for a
triplet of elements.</p>
<p>Each entry has six arguments. The first three are atom types as
referenced in the LAMMPS input file. The first argument specifies the
central atom. The fourth argument indicates the <em>K</em> parameter. The
fifth argument indicates <em>theta_0</em>. The sixth argument indicates a
separation cutoff in Angstroms.</p>
<p>For a given entry, if the second and third arguments are identical,
then the entry is for a cutoff for the distance between types 1 and 2
(values for <em>K</em> and <em>theta_0</em> are irrelevant in this case).</p>
<p>For a given entry, if the first three arguments are all different,
then the entry is for the <em>K</em> and <em>theta_0</em> parameters (the cutoff in
this case is irrelevant).</p>
<p>It is <em>not</em> required that the potential file contain entries for all
of the elements listed in the pair_coeff command. It can also contain
entries for additional elements not being used in a particular
simulation; LAMMPS ignores those entries.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This pair style can only be used if LAMMPS was built with the MANYBODY
package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info on packages.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>These pair styles do not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>All of the <em>nm</em> pair styles supports the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option for the energy of the pair
interaction.</p>
<p>The <em>nm/cut/coul/long</em> pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option since they can tabulate
the short-range portion of the long-range Coulombic interaction.</p>
<p>All of the <em>nm</em> pair styles support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding a long-range tail correction to the energy and
pressure for the NM portion of the pair interaction.</p>
<p>All of the <em>nm</em> pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>All of the <em>nm</em> pair styles can only be used via the <em>pair</em> keyword of
the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>These pair styles are part of the MISC package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The peridynamic pair styles implement material models that can be used
at the mescscopic and macroscopic scales. See <a class="reference external" href="PDF/PDLammps_overview.pdf">this document</a> for an overview of LAMMPS commands
for Peridynamics modeling.</p>
<p>Style <em>peri/pmb</em> implements the Peridynamic bond-based prototype
microelastic brittle (PMB) model.</p>
<p>Style <em>peri/lps</em> implements the Peridynamic state-based linear
peridynamic solid (LPS) model.</p>
<p>Style <em>peri/ves</em> implements the Peridynamic state-based linear
peridynamic viscoelastic solid (VES) model.</p>
<p>Style <em>peri/eps</em> implements the Peridynamic state-based elastic-plastic
solid (EPS) model.</p>
<p>The canonical papers on Peridynamics are <a class="reference internal" href="#silling2000"><span class="std std-ref">(Silling 2000)</span></a>
and <a class="reference internal" href="#silling2007"><span class="std std-ref">(Silling 2007)</span></a>. The implementation of Peridynamics
in LAMMPS is described in <a class="reference internal" href="#parks"><span class="std std-ref">(Parks)</span></a>. Also see the <a class="reference external" href="http://www.sandia.gov/~mlparks/papers/PDLAMMPS.pdf">PDLAMMPS user guide</a> for
more details about its implementation.</p>
<p>The peridynamic VES and EPS models in PDLAMMPS were implemented by
R. Rahman and J. T. Foster at University of Texas at San Antonio. The
original VES formulation is described in “(Mitchell2011)” and the
original EPS formulation is in “(Mitchell2011a)”. Additional PDF docs
that describe the VES and EPS implementations are include in the
LAMMPS distro in <a class="reference external" href="PDF/PDLammps_VES.pdf">doc/PDF/PDLammps_VES.pdf</a> and
<a class="reference external" href="PDF/PDLammps_EPS.pdf">doc/PDF/PDLammps_EPS.pdf</a>. For questions
regarding the VES and EPS models in LAMMPS you can contact R. Rahman
(rezwanur.rahman at utsa.edu).</p>
<p>The following coefficients must be defined for each pair of atom types
via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples above,
<p>C is the effectively a spring constant for Peridynamic bonds, the
horizon is a cutoff distance for truncating interactions, and s00 and
alpha are used as a bond breaking criteria. The units of c are such
that c/distance = stiffness/volume^2, where stiffness is
energy/distance^2 and volume is distance^3. See the users guide for
more details.</p>
<p>For the <em>peri/lps</em> style:</p>
<ul class="simple">
<li>K (force/area units)</li>
<li>G (force/area units)</li>
<li>horizon (distance units)</li>
<li>s00 (unitless)</li>
<li>alpha (unitless)</li>
</ul>
<p>K is the bulk modulus and G is the shear modulus. The horizon is a
cutoff distance for truncating interactions, and s00 and alpha are
used as a bond breaking criteria. See the users guide for more
details.</p>
<p>For the <em>peri/ves</em> style:</p>
<ul class="simple">
<li>K (force/area units)</li>
<li>G (force/area units)</li>
<li>horizon (distance units)</li>
<li>s00 (unitless)</li>
<li>alpha (unitless)</li>
<li>m_lambdai (unitless)</li>
<li>m_taubi (unitless)</li>
</ul>
<p>K is the bulk modulus and G is the shear modulus. The horizon is a
cutoff distance for truncating interactions, and s00 and alpha are
used as a bond breaking criteria. m_lambdai and m_taubi are the
viscoelastic relaxation parameter and time constant,
respectively. m_lambdai varies within zero to one. For very small
values of m_lambdai the viscoelsatic model responds very similar to a
linear elastic model. For details please see the description in
“(Mtchell2011)”.</p>
<p>For the <em>peri/eps</em> style:</p>
<p>K (force/area units)
G (force/area units)
horizon (distance units)
s00 (unitless)
alpha (unitless)
m_yield_stress (force/area units)</p>
<p>K is the bulk modulus and G is the shear modulus. The horizon is a
cutoff distance and s00 and alpha are used as a bond breaking
criteria. m_yield_stress is the yield stress of the material. For
details please see the description in “(Mtchell2011a)”.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>These pair styles do not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.</p>
<p>These pair styles do not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table and tail options are not
relevant for these pair styles.</p>
<p>These pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>These pair styles can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. They do not support the
<p>All of these styles are part of the PERI package. They are only
enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the Lennard-Jones portion of the pair
interaction, but only for sphere-sphere interactions. There is no
shifting performed for ellipsoidal interactions due to the anisotropic
dependence of the interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<em>inner</em>, <em>middle</em>, <em>outer</em> keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style command</span></a>.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This style is part of the ASPHERE package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This pair style requires that atoms be ellipsoids as defined by the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum. The prefactors
are chosen so that the potential minimum is at -epsilon.</p>
<p>The latter 2 coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair.</p>
<p>For <em>lj/sdk/coul/long</em> only the LJ cutoff can be specified since a
Coulombic cutoff cannot be specified for an individual I,J type pair.
All type pairs use the same global Coulombic cutoff specified in the
pair_style command.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em> or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em> or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP, and OPT packages respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP, and OPT packages respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<hr class="docutils" />
<p><strong>Mixing, shift, table, tail correction, restart, and rRESPA info</strong>:</p>
<p>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/sdk pair styles <em>cannot</em> be mixed,
since different pairs may have different exponents. So all parameters
for all pairs have to be specified explicitly through the “pair_coeff”
command. Defining then in a data file is also not supported, due to
limitations of that file format.</p>
<p>All of the lj/sdk pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> shift option for the energy of the
Lennard-Jones portion of the pair interaction.</p>
<p>The <em>lj/sdk/coul/long</em> pair styles support the
<a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option since they can tabulate
the short-range portion of the long-range Coulombic interaction.</p>
<p>All of the lj/sdk pair styles write their information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.</p>
<p>The lj/sdk and lj/cut/coul/long pair styles do not support
the use of the <em>inner</em>, <em>middle</em>, and <em>outer</em> keywords of the <a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>All of the lj/sdk pair styles are part of the USER-CG-CMM package.
The <em>lj/sdk/coul/long</em> style also requires the KSPACE package to be
built (which is enabled by default). They are only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>It is useful for pushing apart overlapping atoms, since it does not
blow up as r goes to 0. A is a pre-factor that can be made to vary in
time from the start to the end of the run (see discussion below),
e.g. to start with a very soft potential and slowly harden the
interactions over time. Rc is the cutoff. See the <a class="reference internal" href="fix_nve_limit.html"><span class="doc">fix nve/limit</span></a> command for another way to push apart
overlapping atoms.</p>
<p>The following coefficients must be defined for each pair of atom types
via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples above,
<p>Note that a formula defined by an <a class="reference internal" href="variable.html"><span class="doc">equal-style variable</span></a>
can use the current timestep, elapsed time in the current run, elapsed
time since the beginning of a series of runs, as well as access other
variables.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the A coefficient and cutoff
distance for this pair style can be mixed. A is always mixed via a
<em>geometric</em> rule. The cutoff is mixed according to the pair_modify
mix value. The default mix value is <em>geometric</em>. See the
“pair_modify” command for details.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option, since the pair interaction goes to 0.0 at the cutoff.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table and tail options are not
relevant for this pair style.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>When using the USER-INTEL package with this style, there is an
additional 5 to 10 percent performance improvement when the
Stillinger-Weber parameters p and q are set to 4 and 0 respectively.
These parameters are common for modeling silicon and water.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Style <em>table</em> creates interpolation tables from potential energy and
force values listed in a file(s) as a function of distance. When
performing dynamics or minimation, the interpolation tables are used
to evaluate energy and forces for pairwise interactions between
particles, similar to how analytic formulas are used for other pair
styles.</p>
<p>The interpolation tables are created as a pre-computation by fitting
cubic splines to the file values and interpolating energy and force
values at each of <em>N</em> distances. During a simulation, the tables are
used to interpolate energy and force values as needed for each pair of
particles separated by a distance <em>R</em>. The interpolation is done in
one of 4 styles: <em>lookup</em>, <em>linear</em>, <em>spline</em>, or <em>bitmap</em>.</p>
<p>For the <em>lookup</em> style, the distance <em>R</em> is used to find the nearest
table entry, which is the energy or force.</p>
<p>For the <em>linear</em> style, the distance <em>R</em> is used to find the 2
surrounding table values from which an energy or force is computed by
linear interpolation.</p>
<p>For the <em>spline</em> style, a cubic spline coefficients are computed and
stored for each of the <em>N</em> values in the table, one set of splines for
energy, another for force. Note that these splines are different than
the ones used to pre-compute the <em>N</em> values. Those splines were fit
to the <em>Nfile</em> values in the tabulated file, where often <em>Nfile</em> <
<em>N</em>. The distance <em>R</em> is used to find the appropriate set of spline
coefficients which are used to evaluate a cubic polynomial which
computes the energy or force.</p>
<p>For the <em>bitmap</em> style, the specified <em>N</em> is used to create
interpolation tables that are 2^N in length. The distance <em>R</em> is used
to index into the table via a fast bit-mapping technique due to
<a class="reference internal" href="#wolff"><span class="std std-ref">(Wolff)</span></a>, and a linear interpolation is performed between
adjacent table values.</p>
<p>The following coefficients must be defined for each pair of atoms
types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
above.</p>
<ul class="simple">
<li>filename</li>
<li>keyword</li>
<li>cutoff (distance units)</li>
</ul>
<p>The filename specifies a file containing tabulated energy and force
values. The keyword specifies a section of the file. The cutoff is
an optional coefficient. If not specified, the outer cutoff in the
table itself (see below) will be used to build an interpolation table
that extend to the largest tabulated distance. If specified, only
file values up to the cutoff are used to create the interpolation
table. The format of this file is described below.</p>
<p>If your tabulated potential(s) are designed to be used as the
short-range part of one of the long-range solvers specified by the
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command, then you must use one or
more of the optional keywords listed above for the pair_style command.
These are <em>ewald</em> or <em>pppm</em> or <em>msm</em> or <em>dispersion</em> or <em>tip4p</em>. This
is so LAMMPS can insure the short-range potential and long-range
solver are compatible with each other, as it does for other
short-range pair styles, such as <a class="reference internal" href="pair_lj.html"><span class="doc">pair_style lj/cut/coul/long</span></a>. Note that it is up to you to insure
the tabulated values for each pair of atom types has the correct
functional form to be compatible with the matching long-range solver.</p>
<hr class="docutils" />
<p>Here are some guidelines for using the pair_style table command to
best effect:</p>
<ul class="simple">
<li>Vary the number of table points; you may need to use more than you think
to get good resolution.</li>
<li>Always use the <a class="reference internal" href="pair_write.html"><span class="doc">pair_write</span></a> command to produce a plot
of what the final interpolated potential looks like. This can show up
interpolation “features” you may not like.</li>
<li>Start with the linear style; it’s the style least likely to have problems.</li>
<li>Use <em>N</em> in the pair_style command equal to the “N” in the tabulation
file, and use the “RSQ” or “BITMAP” parameter, so additional interpolation
is not needed. See discussion below.</li>
<li>Make sure that your tabulated forces and tabulated energies are
consistent (dE/dr = -F) over the entire range of r values. LAMMPS
will warn if this is not the case.</li>
<li>Use as large an inner cutoff as possible. This avoids fitting splines
to very steep parts of the potential.</li>
</ul>
<hr class="docutils" />
<p>The format of a tabulated file is a series of one or more sections,
defined as follows (without the parenthesized comments):</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># Morse potential for Fe (one or more comment or blank lines)</span>
<p>A section begins with a non-blank line whose 1st character is not a
“#”; blank lines or lines starting with “#” can be used as comments
between sections. The first line begins with a keyword which
identifies the section. The line can contain additional text, but the
initial text must match the argument specified in the pair_coeff
command. The next line lists (in any order) one or more parameters
for the table. Each parameter is a keyword followed by one or more
numeric values.</p>
<p>The parameter “N” is required and its value is the number of table
entries that follow. Note that this may be different than the <em>N</em>
specified in the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style table</span></a> command. Let
Ntable = <em>N</em> in the pair_style command, and Nfile = “N” in the
tabulated file. What LAMMPS does is a preliminary interpolation by
creating splines using the Nfile tabulated values as nodal points. It
uses these to interpolate energy and force values at Ntable different
points. The resulting tables of length Ntable are then used as
described above, when computing energy and force for individual pair
distances. This means that if you want the interpolation tables of
length Ntable to match exactly what is in the tabulated file (with
effectively no preliminary interpolation), you should set Ntable =
Nfile, and use the “RSQ” or “BITMAP” parameter. This is because the
internal table abscissa is always RSQ (separation distance squared),
for efficient lookup.</p>
<p>All other parameters are optional. If “R” or “RSQ” or “BITMAP” does
not appear, then the distances in each line of the table are used
as-is to perform spline interpolation. In this case, the table values
can be spaced in <em>r</em> uniformly or however you wish to position table
values in regions of large gradients.</p>
<p>If used, the parameters “R” or “RSQ” are followed by 2 values <em>rlo</em>
and <em>rhi</em>. If specified, the distance associated with each energy and
force value is computed from these 2 values (at high accuracy), rather
than using the (low-accuracy) value listed in each line of the table.
The distance values in the table file are ignored in this case.
For “R”, distances uniformly spaced between <em>rlo</em> and <em>rhi</em> are
computed; for “RSQ”, squared distances uniformly spaced between
<em>rlo*rlo</em> and <em>rhi*rhi</em> are computed.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you use “R” or “RSQ”, the tabulated distance values in the
file are effectively ignored, and replaced by new values as described
in the previous paragraph. If the distance value in the table is not
very close to the new value (i.e. round-off difference), then you will
be assingning energy/force values to a different distance, which is
probably not what you want. LAMMPS will warn if this is occurring.</p>
</div>
<p>If used, the parameter “BITMAP” is also followed by 2 values <em>rlo</em> and
<em>rhi</em>. These values, along with the “N” value determine the ordering
of the N lines that follow and what distance is associated with each.
This ordering is complex, so it is not documented here, since this
file is typically produced by the <a class="reference internal" href="pair_write.html"><span class="doc">pair_write</span></a> command
with its <em>bitmap</em> option. When the table is in BITMAP format, the “N”
parameter in the file must be equal to 2^M where M is the value
specified in the pair_style command. Also, a cutoff parameter cannot
be used as an optional 3rd argument in the pair_coeff command; the
entire table extent as specified in the file must be used.</p>
<p>If used, the parameter “FPRIME” is followed by 2 values <em>fplo</em> and
<em>fphi</em> which are the derivative of the force at the innermost and
outermost distances listed in the table. These values are needed by
the spline construction routines. If not specified by the “FPRIME”
parameter, they are estimated (less accurately) by the first 2 and
last 2 force values in the table. This parameter is not used by
BITMAP tables.</p>
<p>Following a blank line, the next N lines list the tabulated values.
On each line, the 1st value is the index from 1 to N, the 2nd value is
r (in distance units), the 3rd value is the energy (in energy units),
and the 4th is the force (in force units). The r values must increase
from one line to the next (unless the BITMAP parameter is specified).</p>
<p>Note that one file can contain many sections, each with a tabulated
potential. LAMMPS reads the file section by section until it finds
one that matches the specified keyword.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<p>style = <em>tersoff</em> or <em>tersoff/table</em> or <em>tersoff/cuda</em> or <em>tersoff/gpu</em> or <em>tersoff/omp</em> or <em>tersoff/table/omp</em></p>
+<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>
<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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The three Si arguments map LAMMPS atom types 1,2,3 to the Si element
in the Tersoff/MOD file. If a mapping value is specified as NULL, the
mapping is not performed. This can be used when a <em>tersoff/mod</em>
potential is used as part of the <em>hybrid</em> pair style. The NULL values
are placeholders for atom types that will be used with other
potentials.</p>
<p>Tersoff/MOD file in the <em>potentials</em> directory of the LAMMPS
distribution have a ”.tersoff.mod” suffix. Lines that are not blank
or comments (starting with #) define parameters for a triplet of
elements. The parameters in a single entry correspond to coefficients
in the formula above:</p>
<ul class="simple">
<li>element 1 (the center atom in a 3-body interaction)</li>
<li>element 2 (the atom bonded to the center atom)</li>
<li>element 3 (the atom influencing the 1-2 bond in a bond-order sense)</li>
<li>beta</li>
<li>alpha</li>
<li>h</li>
<li>eta</li>
<li>beta_ters = 1 (dummy parameter)</li>
<li>lambda2 (1/distance units)</li>
<li>B (energy units)</li>
<li>R (distance units)</li>
<li>D (distance units)</li>
<li>lambda1 (1/distance units)</li>
<li>A (energy units)</li>
<li>n</li>
<li>c1</li>
<li>c2</li>
<li>c3</li>
<li>c4</li>
<li>c5</li>
</ul>
<p>The n, eta, lambda2, B, lambda1, and A parameters are only used for
two-body interactions. The beta, alpha, c1, c2, c3, c4, c5, h
parameters are only used for three-body interactions. The R and D
parameters are used for both two-body and three-body interactions. The
non-annotated parameters are unitless.</p>
<p>The Tersoff/MOD potential file must contain entries for all the elements
listed in the pair_coeff command. It can also contain entries for
additional elements not being used in a particular simulation; LAMMPS
ignores those entries.</p>
<p>For a single-element simulation, only a single entry is required
(e.g. SiSiSi). As annotated above, the first element in the entry is
the center atom in a three-body interaction and it is bonded to the
2nd atom and the bond is influenced by the 3rd atom. Thus an entry
for SiSiSi means Si bonded to a Si with another Si atom influencing the bond.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Tersoff_2 parameters R and S must be converted to the LAMMPS
parameters R and D (R is different in both forms), using the following
relations: R=(R’+S’)/2 and D=(S’-R’)/2, where the primes indicate the
Tersoff_2 parameters.</p>
<p>In the potentials directory, the file SiCGe.tersoff provides the
LAMMPS parameters for Tersoff’s various versions of Si, as well as his
alloy parameters for Si, C, and Ge. This file can be used for pure Si,
(three different versions), pure C, pure Ge, binary SiC, and binary
SiGe. LAMMPS will generate an error if this file is used with any
combination involving C and Ge, since there are no entries for the GeC
interactions (Tersoff did not publish parameters for this
cross-interaction.) Tersoff files are also provided for the SiC alloy
(SiC.tersoff) and the GaN (GaN.tersoff) alloys.</p>
<p>Many thanks to Rutuparna Narulkar, David Farrell, and Xiaowang Zhou
for helping clarify how Tersoff parameters for alloys have been
defined in various papers. Also thanks to Ram Devanathan for
providing the base ZBL implementation.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The <em>thole</em> pair styles are meant to be used with force fields that
include explicit polarization through Drude dipoles. This link
describes how to use the <a class="reference internal" href="tutorial_drude.html"><span class="doc">thermalized Drude oscillator model</span></a> in LAMMPS and polarizable models in LAMMPS
are discussed in <a class="reference internal" href="Section_howto.html#howto-25"><span class="std std-ref">this Section</span></a>.</p>
<p>The <em>thole</em> pair style should be used as a sub-style within in the
<a class="reference internal" href="pair_hybrid.html"><span class="doc">pair_hybrid/overlay</span></a> command, in conjunction with a
main pair style including Coulomb interactions, i.e. any pair style
containing <em>coul/cut</em> or <em>coul/long</em> in its style name.</p>
<p>The <em>lj/cut/thole/long</em> pair style is equivalent to, but more convenient that
the frequent combination <em>hybrid/overlay lj/cut/coul/long cutoff thole damp
cutoff2</em>. It is not only a shorthand for this pair_style combination, but
it also allows for mixing pair coefficients instead of listing them all.
The <em>lj/cut/thole/long</em> pair style is also a bit faster because it avoids an
overlay and can benefit from OMP acceleration. Moreover, it uses a more
precise approximation of the direct Coulomb interaction at short range similar
to <span class="xref doc">coul/long/cs</span>, 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
+<a class="reference internal" href="#noskov"><span class="std std-ref">(Noskov)</span></a> of the dipole screening scheme originally proposed
+by <a class="reference internal" href="#thole"><span class="std std-ref">Thole</span></a>. The scaling coefficient <span class="math">\(s_{ij}\)</span> is determined
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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p><strong>Mixing</strong>:</p>
<p>The <em>thole</em> pair style does not support mixing. Thus, coefficients
for all I,J pairs must be specified explicitly.</p>
<p>The <em>lj/cut/thole/long</em> pair style does support mixing. Mixed coefficients
<p>These pair styles are part of the USER-DRUDE package. They are only
enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This pair_style should currently not be used with the <a class="reference internal" href="dihedral_charmm.html"><span class="doc">charmm dihedral style</span></a> if the latter has non-zero 1-4 weighting
factors. This is because the <em>thole</em> pair style does not know which
pairs are 1-4 partners of which dihedrals.</p>
<p>The <em>lj/cut/thole/long</em> pair style should be used with a <a class="reference internal" href="kspace_style.html"><span class="doc">Kspace solver</span></a>
like PPPM or Ewald, which is only enabled if LAMMPS was built with the kspace
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
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>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The last coefficient is optional. If not specified, the global yukawa
cutoff is used.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The last coefficient is optional. If not specified, the global
yukawa/colloid cutoff is used.</p>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
option for the energy of the pair interaction.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant
for this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure.</p>
<p>This pair style writes its information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
<p>This style is part of the COLLOID package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>This pair style requires that atoms be finite-size spheres with a
diameter, as defined by the <a class="reference internal" href="atom_style.html"><span class="doc">atom_style sphere</span></a>
command.</p>
<p>Per-particle polydispersity is not yet supported by this pair style;
per-type polydispersity is allowed. This means all particles of the
same type must have the same diameter. Each type can have a different
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where e is the electron charge, epsilon_0 is the electrical
permittivity of vacuum, and Z_i and Z_j are the nuclear charges of the
two atoms. The switching function S(r) is identical to that used by
<a class="reference internal" href="pair_gromacs.html"><span class="doc">pair_style lj/gromacs</span></a>. Here, the inner and outer
cutoff are the same for all pairs of atom types.</p>
<p>The following coefficients must be defined for each pair of atom types
via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples above,
or in the LAMMPS data file.</p>
<ul class="simple">
<li>Z_i (atomic number for first atom type, e.g. 13.0 for aluminum)</li>
<li>Z_j (ditto for second atom type)</li>
</ul>
<p>The values of Z_i and Z_j are normally equal to the atomic
numbers of the two atom types. Thus, the user may optionally
specify only the coefficients for each I==I pair, and rely
on the obvious mixing rule for cross interactions (see below).
Note that when I==I it is required that Z_i == Z_j. When used
with <a class="reference internal" href="pair_hybrid.html"><span class="doc">hybrid/overlay</span></a> and pairs are assigned
to more than one sub-style, the mixing rule is not used and
each pair of types interacting with the ZBL sub-style must
be included in a pair_coeff command.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The numerical values of the exponential decay constants in the
screening function depend on the unit of distance. In the above
equation they are given for units of angstroms. LAMMPS will
automatically convert these values to the distance unit of the
specified LAMMPS <a class="reference internal" href="units.html"><span class="doc">units</span></a> setting. The values of Z should
always be given as multiples of a proton’s charge, e.g. 29.0 for
copper.</p>
</div>
<hr class="docutils" />
-<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
+<p>Styles with a <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
-<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively. They are only
-enabled if LAMMPS was built with those packages. See the <a 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 accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively. They are only enabled if
+LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><span class="doc">Section_accelerate</span></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, the Z_i and Z_j coefficients
can be mixed by taking Z_i and Z_j from the values specified for
I == I and J == J cases. When used
with <a class="reference internal" href="pair_hybrid.html"><span class="doc">hybrid/overlay</span></a> and pairs are assigned
to more than one sub-style, the mixing rule is not used and
each pair of types interacting with the ZBL sub-style
must be included in a pair_coeff command.
The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> mix option has no effect on
the mixing behavior</p>
<p>The ZBL pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
shift option, since the ZBL interaction is already smoothed to 0.0 at
the cutoff.</p>
<p>The <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a> table option is not relevant for
this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><span class="doc">pair_modify</span></a>
tail option for adding long-range tail corrections to energy and
pressure, since there are no corrections for a potential that goes to
0.0 at the cutoff.</p>
<p>This pair style does not write information to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>, so pair_style and pair_coeff commands must be
specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><span class="doc">run_style respa</span></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<li>style = <em>off</em> or <em>on</em> or <em>cuda</em> or <em>gpu</em> or <em>intel</em> or <em>kk</em> or <em>omp</em> or <em>opt</em> or <em>hybrid</em></li>
+<li>style = <em>off</em> or <em>on</em> or <em>gpu</em> or <em>intel</em> or <em>kk</em> or <em>omp</em> or <em>opt</em> or <em>hybrid</em></li>
<li>args = for hybrid style, default suffix to be used and alternative suffix</li>
<p>This command allows you to use variants of various styles if they
exist. In that respect it operates the same as the <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-suffix command-line switch</span></a>. It also has options
to turn off or back on any suffix setting made via the command line.</p>
-<p>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 in <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">this section of the manual</span></a>. The “cuda” style corresponds to
-the USER-CUDA package, the “gpu” style to the GPU package, the “intel”
-style to the USER-INTEL package, the “kk” style to the KOKKOS package,
-the “omp” style to the USER-OMP package, and the “opt” style to the
-OPT package.</p>
+<p>The specified style can be <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 in <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">this section of the manual</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 “omp” style to the USER-OMP package,
+and the “opt” style to the OPT package.</p>
<p>These are the variants these packages provide:</p>
<ul class="simple">
-<li>USER-CUDA = a collection of atom, pair, fix, compute, and intergrate
-styles, optimized to run on one or more NVIDIA GPUs</li>
<li>GPU = a handful of pair styles and the PPPM kspace_style, optimized to
run on one or more GPUs or multicore CPU/GPU nodes</li>
<li>USER-INTEL = a collection of pair styles and neighbor routines
optimized to run in single, mixed, or double precision on CPUs and
Intel(R) Xeon Phi(TM) coprocessors.</li>
<li>KOKKOS = a collection of atom, pair, and fix styles optimized to run
using the Kokkos library on various kinds of hardware, including GPUs
via Cuda and many-core chips via OpenMP or threading.</li>
<li>USER-OMP = a collection of pair, bond, angle, dihedral, improper,
kspace, compute, and fix styles with support for OpenMP
multi-threading</li>
<li>OPT = a handful of pair styles, cache-optimized for faster CPU
performance</li>
<li>HYBRID = a combination of two packages can be specified (see below)</li>
</ul>
<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/opt, lj/cut/omp,
-lj/cut/gpu, lj/cut/intel, lj/cut/cuda, or lj/cut/kk. A variant styles
+lj/cut/gpu, lj/cut/intel, or lj/cut/kk. A variant styles
can be specified explicitly in your input script, e.g. pair_style
lj/cut/gpu. If the suffix command is used with the appropriate style,
you do not need to modify your input script. The specified suffix
-(opt,omp,gpu,intel,cuda,kk) is automatically appended whenever your
+(opt,omp,gpu,intel,kk) 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>,
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.